SLA 99,9%: 보기 좋은 숫자 속에 숨을 수 있는 장애

전체 지표는 초록색인데 결제 수단 하나는 누구에게도 작동하지 않습니다. SLA 가용성을 정확하게 계산해도 이런 일은 일어날 수 있습니다. 드문 결제 수단은 평균에 거의 영향을 주지 않기 때문입니다. 쓸모 있는 SLA는 이 퍼센트가 누구의 문제를 측정하는지, 어떤 이벤트가 포함되는지, 그리고 월말이 되기 전에 팀이 무엇을 하는지에 대한 질문에서 시작합니다.

분모가 누구를 가리고 있는지 확인하라

한 측정 구간에 대상 요청이 100 000건 있었다고 해 봅시다. 주요 결제 수단에서는 99 900건이 기술적으로 성공했습니다. 두 번째 수단에는 요청 100건이 들어왔고 모두 기술 오류로 끝났습니다. 전체 가용성은 99,9%, 두 번째 수단의 가용성은 0%입니다. 이것은 별도의 가상 예시이며 실제 서비스 데이터가 아닙니다.

이런 리포트는 전체 공식을 정확히 따르면서도 비즈니스에는 부족할 수 있습니다. 결제 수단, 국가, 통화, 특정 라우트처럼 중요한 세그먼트를 미리 정해 두세요. 표본이 작을 때는 영향받은 거래 건수와 오류가 이어진 순서를 보여 주세요. 소수점 여러 자리의 퍼센트는 실제로는 없는 정밀함이 있는 듯한 인상을 줍니다.

담당자 없는 세분화를 수백 개씩 추가하지는 마세요. 팀이 실제로 다른 결정을 내리게 되는 것만 고르세요. 예를 들어 특정 연동을 점검하거나, 고객센터에 미리 알리거나, 허용 범위 안에서 고객에게 제시하는 흐름을 일시적으로 바꾸는 경우입니다. 지표에는 명확한 수신자가 있어야 합니다.

먼저 세 가지 개념을 구분하라

SLI는 측정하는 지표, SLO는 그 목표값, SLA는 합의와 위반 시의 결과를 정한 것입니다. Google SRE는 지연 시간의 분포에도 주목합니다. 평균값은 아주 느린 응답의 작은 비중을 가릴 수 있습니다. 출처: Google SRE, Service Level Objectives.

결제 연동에 대해서는 세 구간을 따로 정의하세요. 요청 전송부터 API 응답까지, 거래 생성부터 선택한 최종 상태까지, 이벤트 발생부터 우리 시스템이 알림을 받을 때까지입니다. 구간마다 지연의 원인이 다릅니다. 사용자가 은행 앱에서 인증하는 데 쓰는 시간은 인프라 처리 시간과 분리해서 보여 주어야 합니다.

가용성에도 분모가 필요하다

시간 기준으로 정의하면, 예외 없이 전체 기간을 반영했을 때 가상의 30일 기준 99,9%는 43,2분의 비가용 시간에 해당합니다. 요청 기준으로 정의하면 같은 퍼센트가 다른 의미가 됩니다. 대상 요청 100 000건 중 허용되는 실패 예산은 100건입니다. 트래픽 데이터 없이 한 방식을 다른 방식으로 환산할 수는 없습니다. 피크 시간의 10분 장애가 야간의 1시간보다 더 많은 거래에 영향을 줄 수 있습니다.

Google SRE Workbook은 많은 지표를 대상이 되는 성공 이벤트와 집계 대상 전체 이벤트의 비율로 만들 것을 제안합니다. 이 접근의 실무적 가치는 분자, 분모, 임계값을 명시적으로 정의한다는 데 있습니다. 출처: Google SRE Workbook, Implementing SLOs.

기술적 가용성 관점에서는 정상적으로 처리된 은행의 거절도 서비스의 성공 응답으로 볼 수 있습니다. 결제 전환 관점에서는 성공이 아닙니다. 리포트에서 이 지표들을 미리 분리하세요. 타임아웃을 어떻게 집계할지도 합의해 두어야 합니다. 느린 요청이 소요 시간이 기록되기 전에 표본에서 빠지면, 바로 장애 중에 지연 그래프가 좋아 보일 수 있습니다.

평균 시간만으로는 부족한 이유

가상의 요청 1 000건을 보겠습니다. 980건은 0,2초 만에, 나머지 20건은 10초 만에 끝났습니다. 평균은 0,396초입니다. 꽤 안정적인 숫자처럼 보이지만 20명의 사용자는 눈에 띄게 기다려야 했습니다. 최근접 순위 방식으로 계산하면 여기서 p95는 0,2초, p99는 10초입니다.

p99 백분위수는 선택한 표본에서 관측치의 약 99%에 대한 경계를 나타냅니다. 최대 시간을 정하는 것도, 다음 요청의 결과를 보장하는 것도 아닙니다. 표본 크기와 측정 구간을 항상 함께 보여 주세요. 드문 결제 수단에서는 거래 수가 적어 높은 백분위수가 불안정해집니다. 그 옆에 느린 건의 절대 건수를 함께 두는 편이 더 유용합니다.

서버별이나 일별 p99를 평균 내어 전체 p99를 구하지 마세요. Prometheus는 이미 계산된 분위수를 이런 식으로 집계할 수 없다고 분명히 경고합니다. 히스토그램은 구조 요건을 지키면 분포를 합칠 수 있게 해 줍니다. 출처: Prometheus, Histograms and summaries.

계약상의 한 달은 당직자에게 너무 길다

계약 이행 리포트와 즉시 분석이 필요한 신호를 분리하세요. 월간 수치는 계약 평가에 필요합니다. 운영자에게 중요한 것은 최근 오류, 대기 중인 결제 건수, 가장 오래된 미확정 거래의 경과 시간입니다. 내부 임계값은 자체 관측치와 감내 가능한 손실에 맞춰 정하고, 근거 없는 보편적 기준을 업계 표준인 것처럼 내세우지 마세요.

PG사에 문의할 때는 비식별화된 식별자, 시간대를 포함한 정확한 구간, 기대한 결과, 실제 코드, 영향받은 트래픽 규모를 보관하세요. 예시를 어떻게 골랐는지도 밝히세요. 문제 결제 다섯 건은 진단에 유용하지만, 전체 건수가 없으면 규모를 판단할 수 없습니다.

관측치를 잃었을 때의 조치도 따로 정하세요. 카운터가 갱신을 멈췄다면 오류율 0%는 복구를 선언할 근거가 되지 못합니다. 독립된 로그와 작업 대기열을 대조하세요. 필요한 고객 단계가 실제로 복구됐음을 확인하고, 쌓여 있던 결과 불명 건을 정리한 뒤에 장애를 종료하는 것이 합리적입니다. API가 응답한다고 해서 장애 중 요청에 무슨 일이 있었는지 설명되지는 않습니다.

계약 전에 정해 두어야 할 것

• 거래와 측정 범위: 특정 API, 결제 수단, 지역, 결과 상태.
• 계산 구간, 시간대, 데이터 출처, 최소 관측 건수.
• 오류, 타임아웃, 재시도, 제외 이벤트의 집계 규칙.
• 실제 프로세스에 맞춰 합의한 지연 시간과 가용성의 임계값.
• 통지, 에스컬레이션, 증빙 제출, 위반 심사의 절차.

계약에서 일부 원인을 제외하더라도 사용자 관점의 전체 장애 지표는 남겨 두세요. 외부 참여자에게 문제가 생겨도 고객은 기다려야 합니다. 법적 책임의 배분과 고객 경험의 진단은 서로 다른 과제이며, 둘 다 동시에 보여야 합니다.

다음 리뷰에서는 가장 문제가 많은 결제 수단을 골라 요청부터 고객 결과까지의 경로를 재구성하세요. 그 경로를 SLA가 실제로 다루는 범위와 비교하세요. 둘 사이의 차이가 어떤 관측이나 계약 조건을 먼저 다듬어야 하는지 알려 줄 것입니다.