SRE가 해결하는 문제 [BLOCK_TYPE SECTION/STEP]
Site Reliability Engineering에 오신 것을 환영합니다
[BLOCK_TYPE SECTION/STEP]Site Reliability Engineering(SRE)은 2003년 Google에서 시작되었습니다. Ben Treynor Sloss는 작은 운영 팀을 맡아, 사람이 아닌 엔지니어가 프로덕션을 운영하도록 재구성했습니다. 그 결과는 대규모 인터넷 서비스 운영의 표준 모델이 되었습니다. [BLOCK_TYPE SECTION/STEP]
기존 운영 팀은 수동 작업으로 서비스를 유지했습니다. 서버를 재시작하고, 엔지니어를 호출하고, 런북을 작성하고, 그게 유지되길 바랐습니다. 이 모델은 규모가 커지면 무너집니다. 50명의 운영자가 5,000대의 서버를 수동으로 재시작할 수는 없습니다. 일정 규모를 넘어서면 수동 작업은 모든 생산적인 시간을 소모하는 세금이 됩니다. [BLOCK_TYPE SECTION/STEP]
SRE는 이 모델을 뒤집습니다. 시스템이 커질 때 더 많은 운영자를 고용하는 대신, SRE는 소프트웨어 엔지니어를 고용하고 이렇게 말합니다. 운영 작업을 대신 수행하는 코드를 작성하라고요. 여러분의 업무는 운영 문제에 소프트웨어 엔지니어링을 적용하는 것입니다. 여러분의 결과물은 수동 개입이 아니라 자동화, 모니터링, 그리고 설계된 신뢰성입니다.
SRE 관행을 이끄는 세 가지 기본 개념이 있습니다:
- Service Level Objectives (SLOs): 사전에 합의된 수치적 신뢰성 목표
- Error budgets: SLO의 역수이며, 위험 감수를 위해 사용됩니다
- Toil elimination: 시스템 규모에 따라 선형적으로 증가하는 모든 운영 작업은 제거되어야 합니다
이 세 가지 개념은 포스트모텀, 온콜 로테이션, 용량 계획, 모니터링, 릴리스 엔지니어링 등 모든 SRE 관행으로 이어집니다.
전통적인 Ops와 SRE 비교
규모 확장 시 전통적인 Ops가 실패하는 이유
ops 팀은 일반적으로 관리하는 시스템 수에 비례해 선형적으로 성장합니다. 서버가 두 배가 되면 운영자도 두 배가 됩니다. 이는 소규모 배포에서는 재정적으로 타당하지만, 규모가 커지면 재앙이 됩니다. 2차 함수 문제를 인력으로 해결할 수는 없습니다.
SRE는 엔지니어의 작업 시간을 최대 50%까지만 운영 업무에 할애하도록 제한합니다. 나머지 절반은 엔지니어링에 사용해야 합니다. 즉, 도구를 만들고, 프로세스를 자동화하며, 50%를 초래한 toil을 제거하는 데 집중해야 합니다. toil이 장기간 50%를 초과하면, 팀은 개발팀에 업무를 넘기거나 SRE를 추가로 채용해야 합니다. 이 50% 규칙은 SRE 팀이 지속적인 압박 속에서 전통적인 ops 팀으로 전락하는 것을 방지합니다.
실패 모드를 비교해 보겠습니다:
- 전통적인 ops: 사고가 늘어나면 수동 대응이 늘어나고, 예방 작업에 할애할 시간이 줄어들어 더 많은 사고가 발생합니다. 악순환입니다.
- SRE: 사고가 늘어나면 포스트모텀을 진행하고, 자동화 기회를 발견하여 다음 사고의 대응 시간을 줄입니다. 제대로 작동하면 선순환입니다.
SLI, SLO, SLA
운영 환경을 움직이는 세 글자
측정 없는 신뢰성은 연극일 뿐입니다. SRE는 신뢰성을 미리 합의하고 누구나 검증할 수 있는 숫자로 만듭니다.
서비스 수준 지표 (SLI): 서비스 동작을 측정하는 지표. 예시: 요청 지연 시간, 오류율, 처리량, 큐 깊이. SLI는 그래프로 표현할 수 있는 값입니다.
서비스 수준 목표 (SLO): SLI에 대한 목표 값 또는 범위. 예시: '28일 롤링 윈도우 기준으로 HTTP 요청의 99.9%가 성공한다.' SLO는 사용자와 자신에게 약속하는 수용 가능한 서비스 품질 수준입니다.
서비스 수준 계약 (SLA): 위반 시 재정적 페널티가 적용되는 계약상의 약속. 예시: '월간 가용성이 99.9% 미만으로 떨어지면 10%를 환불한다.' SLA는 법적으로 강제되는 약속입니다.
중요한 차이점: SLA는 항상 SLO보다 느슨해야 합니다. 내부적으로 99.9%를 목표로 하고 외부적으로 99.9%를 계약하면 여유가 전혀 없습니다. SRE는 일반적으로 SLO를 SLA보다 한 단계 더 엄격하게 설정합니다: 99.95% 목표, 99.9% 계약. 이 차이는 불가피한 나쁜 주간을 흡수합니다.
Toil 정의하기
Toil에 해당하는 작업
모든 운영 작업이 toil에 해당하는 것은 아닙니다. SRE는 toil을 정확히 정의합니다: 수동적이고, 반복적이며, 자동화할 수 있고, 전술적이며, 지속적인 가치가 없고, 서비스가 성장함에 따라 선형적으로 확장되는 작업입니다.
여섯 가지 속성이 모두 충족되어야 합니다. 일회성 데이터 마이그레이션은 수동적이지만 반복적이지 않으므로 toil에 해당하지 않습니다. 선임 엔지니어가 새로운 서비스 아키텍처를 설계하는 것은 전술적 결정이지만 지속적인 가치를 더하므로 toil에 해당하지 않습니다.
Toil에 해당하는 예시:
- 메모리 누수로 인한 서비스 크래시 후 수동으로 서비스 재시작하기
- 인시던트 트라이에이징 중 로그 조각을 채팅 채널에 붙여넣기
- 새 데이터베이스 프로비저닝을 위해 티켓 양식 작성하기
- 분기별 용량 보고서를 수작업으로 실행
- 일상적인 배포 요청을 하나씩 승인
50% 규칙은 toil을 SRE 근무 시간의 절반으로 제한합니다. 50%를 초과하면 팀은 책임을 제품 팀에 다시 넘기거나 엔지니어를 추가로 채용해야 하지만, 목표는 명확합니다. 인간의 개입 없이 동일한 작업을 수행하는 엔지니어링 시스템으로 대체하여 toil을 0으로 만드는 것입니다.
자동화는 단순히 시간을 절약하는 것 이상의 효과를 냅니다. 특정 유형의 인간 오류를 완전히 제거합니다. 데이터베이스를 프로비저닝하는 스크립트는 긴 교대 근무 후에도 단계를 잊지 않습니다.
Toil 감사 추론
팀은 시간이 어떻게 사용되는지 추적합니다. 지난 분기 시간 배분은 다음과 같습니다: 배포 30%, 장애 대응 25%, 용량 작업 20%, 기능 개발 15%, 제품 팀의 일회성 요청 10%.
온콜 위생
엔지니어, 페이지가 아닙니다
온콜은 실제 비용을 수반합니다. 수면이 방해받고 주말이 중단되며, 예측할 수 없는 문제로 인한 스트레스가 가중됩니다. SRE는 온콜을 지속 가능해야 하는 유한한 자원으로 취급하며, 가장 관심이 많은 사람이 감당하는 영웅적인 부담으로 여기지 않습니다.
건강한 온콜 로테이션은 다음과 같은 원칙을 따릅니다:
- 보상된 시간: 온콜 시간은 대체 휴가, 추가 수당 또는 이에 상응하는 혜택으로 매핑됩니다. 무상 온콜은 팀을 소진시킵니다.
- 합리적인 로테이션 깊이: 6인 팀이 primary와 secondary를 운영할 경우, 각 엔지니어는 3주에 한 번 교대합니다. 2인 로테이션은 경력을 파괴합니다.
- 페이지 볼륨 예산: Google SRE 북은 12시간 교대당 최대 2회의 페이징 이벤트를 권장합니다. 이를 초과하면 팀은 단순히 견디는 것이 아니라 알림 볼륨을 줄이는 데 엔지니어링 시간을 투자해야 합니다.
- 실행 가능한 알림만: 모든 페이지는 인간의 조치가 필요해야 합니다. 페이지가 무시되거나 자동화되거나 정상 운영 중에 반복적으로 발생한다면, 해당 페이지는 존재해서는 안 됩니다. 알림 피로는 신뢰성 결함입니다.
- Follow-the-sun 인계: 전 세계에 분산된 팀은 시간대 경계에서 교대를 인계하여, 시스템이 아침까지 기다릴 수 없는 경우가 아니라면 누구도 새벽 3시에 페이징을 받지 않도록 합니다.
Blameless Postmortems
How Outages Become Improvements
모든 중요한 인시던트는 포스트모텀을 작성합니다: 무슨 일이 일어났는지, 왜 일어났는지, 어떻게 해결했는지, 그리고 재발을 방지하기 위한 변경 사항을 분석한 문서입니다. 포스트모텀은 SRE에서 복리의 개념과 같습니다. 각각의 포스트모텀은 시스템에 영구적인 신뢰성을 더합니다.
Blameless이란 문서에서 실패의 원인을 개인이 아닌 시스템과 프로세스에 귀속시키는 것을 의미합니다. 엔지니어가 잘못된 명령을 실행했다면, 포스트모텀은 다음과 같이 질문합니다: 시스템이 왜 그 명령을 허용했는가? 왜 어떤 안전장치도 이를 막지 못했는가? 다음 엔지니어가 같은 실수를 하지 않도록 시스템, 문서 또는 도구에 어떤 변경이 필요한가?
Blamelessness는 단 하나의 이유로 존재합니다: 사람들은 처벌을 두려워할 때 실수를 숨깁니다. 숨겨진 실수는 다음 인시던트가 됩니다. Blameless 문화의 비용은 공개되지 않은 결함이 쌓이는 비용에 비하면 저렴합니다.
포스트모텀은 일반적으로 다음을 다룹니다:
- 요약(Summary): 인시던트와 영향에 대한 한 문단 설명
- 타임라인(Timeline): 타임스탬프가 포함된 분 단위 재구성
- 근본 원인 분석: 장애를 유발한 기술적·프로세스적 요인
- 감지: 팀이 사고를 인지한 경로와 소요 시간
- 해결: 서비스 복구를 위해 수행한 조치
- 교훈: 잘된 점과 그렇지 않은 점
- 액션 아이템: 구체적이고 담당자가 있으며 기한이 명시된 엔지니어링 작업
액션 아이템은 트래커에 등록됩니다. 다른 엔지니어링 작업과 동일하게 우선순위가 부여됩니다. 액션 아이템이 없는 포스트모텀은 단순한 이야기로 끝납니다. 실제로 달라지는 것은 없습니다.
네 가지 골든 시그널
모든 서비스가 측정해야 할 것
Google의 SRE 서적은 사용자 대면 서비스가 반드시 노출해야 하는 네 가지 신호를 제안합니다: 지연 시간, 트래픽, 오류, 포화도. 이 네 가지 신호는 사용자의 관점에서 서비스 상태를 설명합니다. 더 적은 신호로 모니터링하면 사각지대가 생기고, 수백 개의 메트릭으로 모니터링하면 팀이 알림 피로에 빠지게 됩니다.
지연 시간: 요청이 처리되는 데 걸리는 시간. 평균이 아닌 분포를 추적하세요. p50(중간값)은 일반적인 사용자 경험을 나타냅니다. p99는 최악의 1% 사용자 경험을 나타냅니다. 평균만 보면 긴 꼬리가 숨겨집니다. 예를 들어 중간값 50 ms, p99 5,000 ms인 서비스는 평균으로는 괜찮아 보이지만, 100명 중 1명의 사용자를 망가뜨립니다.
트래픽: 서비스에 대한 수요. 웹 서비스의 경우 초당 요청 수를 의미합니다. 스트리밍 서비스의 경우 동시 접속 수, 배치 작업의 경우 분당 처리된 항목 수를 의미합니다. 트래픽은 용량 결정과 연관되며, 워크로드 이상을 드러냅니다.
오류: 실패한 요청의 비율. 명시적 실패(HTTP 500), 암묵적 실패(HTTP 200이지만 데이터가 손상된 경우), 정책 실패(SLO를 충족하지 못할 정도로 느린 응답) 모두 포함됩니다. 이들을 구분하는 것이 중요합니다. 잘못된 페이로드가 포함된 200 응답은 정직한 500 응답보다 사용자에게 더 큰 피해를 줄 수 있습니다.
포화도(Saturation): 시스템이 얼마나 가득 차 있는지를 나타냅니다. CPU 사용률, 큐 깊이, 메모리 압력, 커넥션 풀 점유율 등이 해당합니다. 포화도는 미래 지연 시간을 예측하는 지표입니다. CPU가 95%인 시스템은 사용자 체감 지연 시간이 급증하기 직전의 여유가 거의 없습니다.
대부분의 SRE 알림은 이 네 가지 신호에서 파생됩니다. 증상 기반 알림(사용자가 문제를 인지할 때 알림)이 원인 기반 알림(CPU가 80%를 초과할 때 알림)보다 우수합니다. 네 가지 골든 시그널은 증상을 설명합니다.
SRE 커리어 경로
SRE 기술이 빛을 발하는 분야
SRE 커리어는 엔지니어가 가장 즐기는 분야에 따라 갈라집니다:
인프라 SRE: 다른 팀들이 실행하는 플랫폼을 구축합니다. Kubernetes, 서비스 메시, 내부 클라우드. 시스템 엔지니어링, 분산 시스템 이론, 플랫폼 설계가 핵심입니다. 대규모 회사에서는 한 명의 인프라 SRE가 수백 명의 제품 엔지니어를 지원할 수 있어 보상이 매우 높습니다.
임베디드 SRE: 제품 엔지니어링 팀과 협력하여 특정 서비스의 신뢰성을 향상시킵니다. 엔지니어와 코치의 역할을 동시에 수행합니다. 기술적 깊이만큼이나 강력한 커뮤니케이션과 코드 리뷰 능력이 중요합니다. 가르치는 것을 좋아하는 엔지니어에게 가장 적합한 경로입니다.
신뢰성 툴링: 관측 가능성 스택을 구축합니다: 모니터링, 알림, 대시보드, 포스트모텀 도구, 인시던트 관리 플랫폼. 프론트엔드와 데이터 엔지니어링 작업이 많습니다. 결과물은 다른 모든 팀에서 사용됩니다.
프로덕션 엔지니어링: Facebook/Meta에서 사용하는 용어로, 용량, 배포, 트래픽 관리를 담당하는 SRE를 의미합니다. 네트워킹과 시스템 작업이 많습니다.
보유할 만한 기술 자격증: Google Cloud Professional Cloud Architect, AWS Solutions Architect Professional, CNCF 자격증(Kubernetes Administrator, Kubernetes Application Developer)은 클라우드 네이티브 역량을 증명합니다. Linux Foundation 자격증은 시스템 깊이를 보여줍니다. 이 자격증들은 포트폴리오 작업을 대체할 수는 없지만, 리크루터 스크리닝을 통과하는 데 도움이 됩니다.
마무리
지금 알게 된 내용
사이트 신뢰성 엔지니어링은 Google이 확장 문제를 해결하기 위해 시작한 접근 방식으로, 현재는 업계 전반에서 널리 실천되는 분야로 성장했습니다. 지금까지 다룬 내용은 다음과 같습니다:
- 수동 운영에서 엔지니어링된 신뢰성으로의 전환
- SLI, SLO, SLA 그리고 오류 예산(error budget)이라는 역(逆) SLO 개념
- Toil의 정의, 50% 규칙, 그리고 엔지니어링 중심의 감소
- 지속 가능한 온콜 로테이션과 비난 없는 포스트모텀 관행
- 서비스 모니터링의 출발점으로서의 네 가지 골든 시그널
- SRE 커리어 트랙과 문을 열어주는 자격증
두 가지 아이디어가 가장 중요합니다. 신뢰성은 사전에 합의된 숫자입니다. 그리고 toil은 결함이지, 직무 설명이 아닙니다. 이 두 가지를 앞으로도 계속 기억한다면, 나머지 SRE 개념들은 자연스럽게 따라옵니다.
추천 자료: Google SRE Book (무료 온라인: sre.google/books/), 실습을 위한 SRE Workbook, 그리고 Charity Majors의 observability 관련 글. geometry-of 동반 레슨에서는 SRE 실무의 시각적 구조(지연 시간 분포, 오류 예산 원뿔, 의존성 그래프, 대시보드 레이아웃)에 대해 더 깊이 다룹니다.