28장 신뢰성을 숫자로 약속하는 방법

서비스가 안정적이라는 말은 사람마다 뜻이 다르다. 개발자는 프로세스가 거의 죽지 않는다는 뜻으로, 사용자는 필요한 순간에 작업이 끝난다는 뜻으로 말할 수 있다. 신뢰성을 논의하려면 먼저 사용자가 어떤 결과를 기대하는지 정해야 한다. 로그인, 검색, 결제, 파일 다운로드는 서로 다른 성공 조건과 허용 시간을 가질 수 있다.

SLI는 서비스 수준을 관찰하는 지표이고 SLO는 그 지표에 대해 정한 목표다. SLA는 서비스 수준과 관련한 계약상의 약속으로 구분해 이해할 수 있다. 이 책에서는 운영 목표를 다루며 법적 계약의 해석을 대신하지 않는다. 숫자의 이름보다 분모와 분자, 관찰 기간과 제외 조건을 명확히 적는 것이 중요하다.

성공 요청의 정의

“월간 성공률 99.9%”라고 적기 전에 무엇을 요청으로 셀지 정해야 한다. 사용자의 잘못된 입력까지 실패로 셀 것인지, 내부 건강 확인을 포함할 것인지, 지나치게 늦게 온 200 응답을 성공으로 볼 것인지 결정한다. 측정 지점에 따라 결과도 다르다. 서버 안에서 성공했지만 사용자에게 전달되지 않은 요청은 어떻게 볼 것인지 고민해야 한다.

시간 기반 가용성에서 30일을 기준으로 99.9%를 단순 계산하면 허용되지 않는 시간은 43.2분이다. 계산은 30 × 24 × 60 × 0.001이다. 그러나 요청 기반 성공률을 그대로 다운타임 분으로 환산하면 안 된다. 요청량이 시간마다 다르기 때문이다. 같은 퍼센트라도 무엇을 센 값인지에 따라 운영 의미가 달라진다.

Example objective, not a universal recommendation:

Window: rolling 30 days
Population: eligible search requests at the service edge
Good event: successful response within 800 milliseconds
Target: 99.5 percent good events

Document separately:
  exclusions
  measurement gaps
  low-traffic periods
  owner and review date

오류 예산을 쓰는 방식

목표를 100%보다 낮게 정하면 허용 가능한 실패의 범위를 계산할 수 있다. 이를 오류 예산으로 생각할 수 있다. 실패를 일부러 일으키라는 뜻이 아니라 신뢰성과 변경 속도 사이의 판단 기준을 마련하는 것이다. 목표를 계속 초과해 실패한다면 새 기능보다 안정화에 우선순위를 둘 근거가 된다.

예산이 얼마나 빨리 소진되는지도 중요하다. 한 달 목표에 비해 짧은 시간에 큰 비율의 실패가 발생하면 월말을 기다릴 수 없다. 소진 속도를 보는 알림은 긴 기간의 목표와 짧은 기간의 대응을 연결한다. 다만 트래픽이 적거나 측정이 끊기면 계산이 왜곡될 수 있으므로 자료의 신뢰성도 함께 확인한다.

모든 부품이 99.9%라면

독립적인 두 구성 요소가 모두 성공해야 하고 각각의 성공 확률이 99.9%라고 단순 가정하면 전체는 약 99.8001%다. 실제 시스템에서는 실패가 독립적이지 않거나 캐시와 재시도, 우회가 있으므로 이 계산을 그대로 보장값으로 쓰면 안 된다. 하지만 의존성이 늘면 실패 기회도 늘 수 있다는 직관을 준다.

병렬로 두 서버를 둔 경우도 공통 장애를 생각해야 한다. 같은 데이터베이스, 같은 인증 시스템, 같은 배포 실수에 함께 영향을 받는다면 독립적인 복제본이라는 가정이 깨진다. 구성도에서 공통으로 지나는 지점을 표시해 보자. 신뢰성 계산을 정교하게 하는 것보다 잘못된 독립성 가정을 발견하는 것이 더 큰 도움이 될 때가 많다.

복구 목표의 두 축

RTO는 복구에 허용하는 시간의 목표, RPO는 어느 시점까지의 데이터 손실을 허용할지에 관한 목표로 이해할 수 있다. 서비스가 빨리 살아나도 어제 이후의 주문을 잃으면 업무가 회복된 것이 아닐 수 있다. 반대로 데이터를 지켰더라도 복원에 며칠이 걸리면 필요한 운영을 못 한다. 둘은 별도의 설계 축이다.

목표를 정한 뒤에는 실제 복원 시험으로 확인한다. 백업을 찾고, 권한을 얻고, 환경을 준비하고, 데이터를 복원하고, 사용자 기능을 검증하는 전체 시간이 중요하다. 데이터 복사 시간만 재면 비상 상황의 준비 시간을 빠뜨린다. 담당자가 휴가 중인 경우에도 절차를 수행할 수 있는지 살펴보자.

장애 뒤에 남길 것

사후 분석에는 영향과 시간선, 직접 원인, 기여한 조건, 탐지와 대응에서 잘된 점과 부족한 점을 담는다. 개인의 실수 한 줄로 끝내면 같은 조건에서 다른 사람이 다시 실수할 수 있다. 잘못된 설정이 검사를 통과한 이유, 영향이 넓어진 이유, 복구가 늦어진 이유를 구조적으로 살핀다.

개선 항목은 작고 검증 가능하게 정한다. “주의한다”보다 “배포 전에 포트와 대상 서비스의 호환성을 자동 검사한다”가 실행 가능하다. 담당자와 기한, 완료 확인 방법도 필요하다. 장애 문서는 사건을 멋있게 설명하는 글이 아니라 다음 사건의 확률과 영향을 줄이는 작업 목록으로 이어져야 한다.