DevOps & Reliability

1. Overview

데브옵스 및 신뢰성 공학(DevOps & Reliability Engineering, DRE)은 개발자(Dev)가 코드를 짜고 운영자(Ops)에게 던져버리는 고전적인 장벽(Silo)을 부수고, 소프트웨어가 사용자에게 도달하기까지의 전 과정을 '자동화된 기계'로 만드는 시스템 역학을 다룹니다.

과거에는 사람이 새벽 3시에 서버에 접속해 명령어를 쳐서 배포했다면, 현대의 엔지니어링은 CI/CD 파이프라인을 통해 코드가 병합되는 순간 테스트부터 서버 교체까지 수 분 내에 끝냅니다. 학습자는 환경 불일치 문제를 해결하는 컨테이너(Docker)와, 수천 대의 서버를 손이 아닌 코드로 프로비저닝하는 IaC(Infrastructure as Code) 기술을 배웁니다. 나아가 구글의 SRE(Site Reliability Engineering) 철학을 바탕으로, 서비스 수준 목표(SLO)를 정하고 로그와 메트릭(Observability)에 근거해 장애를 예방 및 복구하는 신뢰성 통제 능력을 확보합니다.

2. Scope & Boundaries

In-Scope

• 지속적 통합/배포 (CI/CD): 빌드 파이프라인(Jenkins, GitHub Actions), 무중단 배포(Blue-Green, Canary) 전략.
• 인프라 자동화 (IaC): Terraform, Ansible을 이용한 선언적/명령적 인프라 프로비저닝과 형상 관리.
• 컨테이너 생태계 (Containerization): Docker 이미지 빌드, 불변 인프라(Immutable Infrastructure) 철학.
• 사이트 신뢰성 공학 (SRE): SLI(지표), SLO(목표), SLA(계약), 에러 예산(Error Budget), 관측 가능성(Observability: Log, Metric, Trace).

Out-of-Scope

• 쿠버네티스의 내부 네트워킹 및 CNI 동작 물리: 클라우드 네이티브의 심화 네트워크 구조 $\rightarrow$ 08-06. SDN & Virtual Networking 영역으로 위임.
• 소프트웨어 단위 테스트 코드 작성법: 모의 객체(Mock)를 이용한 비즈니스 로직 테스트 $\rightarrow$ 09-04. QA & Quality Assurance 영역으로 위임.

Boundaries

• DRE vs. QA (09-04): QA가 '내 코드가 논리적으로 맞는가?'를 따지는 로직의 무결성 검증이라면, DRE는 '그 코드가 100대의 서버에 안전하게 복사되고 죽지 않고 살아있는가?'를 챙기는 물리적 인프라의 파이프라인입니다.

3. Counterexample

• 가짜 데브옵스 (Fake DevOps Fallacy): 이름만 'DevOps 팀'을 만들고, 실제로는 예전의 시스템 관리자(SysAdmin)들처럼 개발자가 "서버 하나 만들어주세요" 하면 티켓을 받고 콘솔에 접속해 클릭으로 AWS 인스턴스를 수동 생성하는 행위. DevOps/SRE의 본질은 운영(Ops)을 수작업으로 하는 것이 아니라, **운영 문제를 소프트웨어 엔지니어링으로 해결(코딩)**하는 것입니다. 수작업이 반복된다면 그것은 데브옵스가 아니라 단순 노동입니다.
• 가용성 100%의 몽상 (100% Reliability Fallacy): "우리 시스템은 단 1초도 죽으면 안 돼!"라며 모든 배포를 한 달에 한 번으로 제한하는 보수적인 경영진. SRE에서는 100% 가용성은 불가능하며, 99.9%와 99.99% 사이의 트레이드오프(비용이 10배 증가)를 수치화합니다. 목표 가용성을 99.9%로 잡았다면, 한 달에 약 43분의 **에러 예산(Error Budget)**이 생기며, 이 예산을 소진하기 전까지는 하루에 100번이라도 과감하게 배포하는 속도전(Agility)을 즐기는 것이 SRE의 진정한 수학적 역학입니다.

4. Prerequisites

• 네트워크 인프라 및 가상화 (Basic): 로드 밸런싱, 포트, DNS, 도커(Docker)의 네임스페이스 격리 원리를 알아야 배포 환경을 이해할 수 있습니다. (03-03. Virtualization Physics)
• 리눅스 쉘 스크립팅 (Basic): 파이프라인 스크립트는 결국 리눅스 명령어의 집합이므로 운영체제 커널의 이해가 필요합니다. (02. SYSP)

5. Learning Map

6. Learning Topics

Basic

Core Topic 01: CI/CD 파이프라인 기초 (Continuous Integration/Deployment)

• Why to Learn: 밤을 새워가며 수동으로 파일을 복사해서 서버에 올리다가 설정값을 빼먹고 장애를 내는 인재(Human Error)를 물리적으로 원천 차단하기 위함입니다.
• What to Learn:
  • Concepts: CI(지속적 통합), CD(지속적 제공/배포), 파이프라인(Pipeline).
  • Skills: Git Webhook 연동, 빌드-테스트-배포 스테이지(Stage) 설계, 무중단 배포(Blue-Green, Rolling Update).
  • Tools: GitHub Actions, Jenkins, GitLab CI.
  • Trade-offs: 버튼 하나로 코드가 서버에 올라가는 극강의 배포 속도 vs 파이프라인 스크립트 작성 및 CI 서버 유지보수에 들어가는 만만치 않은 데브옵스 엔지니어링 오버헤드.
• How to Learn:
  • 1단계: GitHub 저장소에 코드가 병합(Merge)되면, GitHub Actions가 트리거되어 npm install, npm test, docker build 순서로 실행되는 YAML 파일을 작성합니다.
  • 2단계: 신규 버전을 배포할 때 사용자가 접속 끊김을 겪지 않도록, V1 서버가 도는 상태에서 V2 서버를 띄우고 로드 밸런서가 트래픽을 V2로 한 번에 전환하는 Blue-Green 배포 물리를 시뮬레이션합니다.
• Implement: 특정 백엔드 애플리케이션에 대해, Push $\rightarrow$ Test $\rightarrow$ Build Image $\rightarrow$ Push to Registry까지 자동화된 GitHub Actions CI 파이프라인 구현체.

Recommended

Core Topic 02: 인프라의 코드화와 불변 인프라 (IaC & Immutable Infrastructure)

• Why to Learn: 클라우드 인프라(AWS, GCP 등)를 마우스로 클릭해서 만들면, 똑같은 서버를 다시 세팅할 때 기억력의 한계로 똑같이 만들 수 없는 재앙을 방지하기 위함입니다.
• What to Learn:
  • Concepts: IaC(Infrastructure as Code), 선언형(Declarative) vs 명령형(Imperative), 불변 인프라(Immutable Infrastructure).
  • Skills: Terraform 상태(State) 관리, 멱등성(Idempotency) 확보.
  • Tools: HashiCorp Terraform, Ansible, Docker.
  • Trade-offs: "서버 인스턴스 10대, DB 1대"를 코드로 적어두면 1초 만에 인프라가 붕어빵처럼 찍혀 나오는 놀라운 재현성 vs 팀원 누군가가 AWS 콘솔에서 직접 설정을 건드렸을 때 발생하는 상태 불일치(State Drift) 오류의 악몽.
• How to Learn:
  • 1단계: 서버에 접속해 패키지를 업데이트하는 짓을 멈추고(Mutable), 업데이트가 필요하면 아예 새 버전이 깔린 도커 이미지를 구워서 기존 서버를 부수고 새 서버로 통째로 갈아 끼우는 '불변 인프라' 철학을 실습합니다.
  • 2단계: Terraform 코드로 aws_instance 리소스를 정의하고 terraform apply를 실행합니다. त्यानंतर 코드를 수정해 인스턴스 개수를 3개로 늘렸을 때, 처음부터 3개를 띄우는 게 아니라 '기존 1개 + 추가 2개'로 현재 상태를 영리하게 맞추는 멱등성(Idempotency)의 원리를 분석합니다.
• Implement: AWS 기반의 VPC, 프라이빗 서브넷, EC2, RDS를 하나의 .tf 파일로 선언하여, 명령어 한 줄로 3티어 아키텍처 인프라 전체가 셋업되게 만든 Terraform 템플릿.

Practical

Core Topic 03: 관측 가능성과 원격 분석 (Observability)

• Why to Learn: 사용자가 "결제가 안 돼요!"라고 항의하기 전에, 서버 CPU가 튀거나 500 에러율이 치솟는 것을 그래프로 미리 보고 선제 타격하기 위해서입니다.
• What to Learn:
  • Concepts: 관측 가능성(Observability)의 3요소 (Metrics, Logs, Traces).
  • Skills: 시계열 데이터베이스 처리, 분산 트레이싱(Distributed Tracing), 알람(Alerting) 라우팅 정책.
  • Tools: Prometheus & Grafana (Metric), ELK/EFK Stack (Log), Jaeger (Trace).
  • Trade-offs: 시스템의 모든 숨소리를 수집하여 완벽한 가시성을 얻는 것 vs 그 수집된 로그와 메트릭 데이터를 보관하는 스토리지 비용이 배보다 배꼽이 더 커지는 모니터링 비용 역전.
• How to Learn:
  • 1단계: 마이크로서비스 환경에서 1번 서버 $\rightarrow$ 2번 서버 $\rightarrow$ 3번 서버를 거쳐 응답이 갈 때, 어디서 병목이 발생했는지 알 수 있도록 각 요청에 고유 ID(Trace ID)를 부여해 추적하는 분산 트레이싱 물리(Jaeger)를 구성합니다.
  • 2단계: Prometheus가 10초마다 각 서버를 찔러(Pull) CPU와 메모리 수치를 가져오고, Grafana 대시보드에서 '에러율이 5%를 넘으면 슬랙(Slack)으로 즉시 알람'을 쏘는 임계점(Threshold) 룰을 설정합니다.
• Implement: 로컬 환경에 컨테이너로 Prometheus와 Grafana를 띄우고, 특정 앱의 HTTP 요청 수, 응답 지연 시간(Latency), 에러율을 시각화한 모니터링 대시보드 구축.

Advanced

Core Topic 04: 구글 SRE와 에러 예산 시스템 (SRE & Error Budgets)

• Why to Learn: "빨리 기능을 배포하려는 개발자"와 "장애를 막기 위해 배포를 막으려는 운영자" 사이의 감정적 싸움을 끝내고, 수학과 데이터로 시스템 신뢰성을 타협하기 위함입니다.
• What to Learn:
  • Concepts: SRE(Site Reliability Engineering), SLI(Service Level Indicator), SLO(Service Level Objective), SLA(Service Level Agreement).
  • Skills: 에러 예산(Error Budget) 산정 및 소진에 따른 배포 정책 수립(Freeze), 토일(Toil) 제거 맵핑.
  • Tools: SRE 워크샵 프레임워크.
  • Trade-offs: "99.99% 가용성"이라는 목표를 지키기 위해 에러 예산이 소진되었을 때 신규 기능 배포를 강제로 한 달간 전면 중단(Freeze)시키는 비즈니스 손실 vs 시스템 신뢰성 붕괴로 인한 브랜드 파괴 손실 간의 극단적 저울질.
• How to Learn:
  • 1단계: 어떤 지표를 볼 것인가(SLI: HTTP 200 응답 비율), 우리의 목표는 어디인가(SLO: 한 달간 99.9%), 고객에게 약속한 보상 기준은 무엇인가(SLA: 99.0% 미만 시 요금 환불)의 3단계 개념을 비즈니스 도메인에 적용합니다.
  • 2단계: 99.9% SLO를 가지면 한 달(43,200분) 중 약 43분의 '에러 예산'이 나옵니다. 장애가 나서 30분을 까먹고 남은 예산이 13분일 때, 위험한 아키텍처 마이그레이션을 이번 달에 진행할지 다음 달로 미룰지 결정하는 SRE 회의를 시뮬레이션합니다.
• Implement: 특정 사내 시스템 혹은 토이 프로젝트의 가용성 목표를 설정하고, SLI 도출부터 SLO 산정, 그리고 에러 예산 소진 시 대응 정책(Action Plan)까지 문서화한 SRE 헌장(Charter).

7. Terminology

8. References

Primary

• [P1] CS2023 - Software Engineering (SE) - DevOps and SRE
• [P5] SFIA - IT infrastructure (ITOP)

Secondary

• [Site Reliability Engineering] Betsy Beyer (Google) - SLA/SLO/SLI, Error Budgets, Toil
• [The DevOps Handbook] Gene Kim - Three Ways of DevOps, Telemetry

Industry

• [Observability Engineering] Charity Majors - Metrics, Logs, Traces
• Repo-Local ZK: 20_ZK/22_Permanent/10-learning/00-tech-cs/tech/ZK-devops-reliability.md

9. Final Checklist

Primary

• 개발팀은 '빠른 배포'를 원하고 운영팀은 '안정성'을 원해 충돌하는 사일로(Silo)를 깨부수고, 데브옵스(DevOps)가 어떻게 이 둘을 하나의 자동화된 파이프라인(CI/CD)으로 결합하는지 논증할 수 있는가?
• 가상 머신(VM)에 직접 접속해 환경을 손으로 세팅하던 야만 시대를 벗어나, 인프라를 코드(IaC)로 작성하고 도커(Docker) 컨테이너로 격리시켜 "내 컴퓨터에선 되는데?"라는 변명을 원천 차단할 수 있는가?

Secondary

• 구글의 SRE(Site Reliability Engineering) 철학을 도입하여, 고객과 약속한 가용성 99.9%(SLO)를 역산해 한 달에 허용 가능한 장애 시간(Error Budget) 43분을 산출하고 이를 기반으로 릴리즈 속도를 통제할 수 있는가?
• SRE 엔지니어가 수동으로 서버를 재시작하고 로그를 뒤지는 단순 반복 노동(Toil)을 극혐하며, 운영 작업을 모두 스크립트와 파이썬 코드로 치환해 버리는 '운영의 소프트웨어 공학화'를 렌더링할 수 있는가?

Industry

• 서버에 장애가 터졌을 때 CPU나 RAM의 1차원적 대시보드(Monitoring)만 쳐다보는 것을 넘어, 분산 추적(Trace), 로그(Log), 메트릭(Metric)의 삼위일체를 통해 시스템의 내장을 훤히 들여다보는 관찰 가능성(Observability)을 구축할 수 있는가?
• 마이크로서비스(MSA) 30개가 연쇄적으로 통신하는 환경에서 에러가 났을 때, Request ID를 탯줄처럼 매달고 다니며 어느 컨테이너 병목에서 지연이 터졌는지 집요하게 파헤치는 디버깅 파이프라인을 설계할 수 있는가?