서비스 모니터링: SLI·SLO·알림 조건 계산하기

요청 성공률과 지연 지표를 계산하고 에러 예산을 배포 판단에 연결하는 가상 사례입니다.

그래프가 많아도 지금 사용자에게 문제가 있는지 답하지 못하면 운영 판단이 어렵습니다. 먼저 어떤 사용자 동작이 성공해야 하는지 정하고 그 동작의 성공률과 지연을 측정합니다. 아래 숫자는 실제 서비스 측정이 아닌 계산 예제입니다.

SLI·SLO·SLA 구분하기

SLI는 관찰하는 지표, SLO는 그 지표에 대한 목표입니다. SLA는 고객과의 서비스 약속으로 계약상 조건이 포함될 수 있으므로 내부 목표와 동일한 문서로 취급하지 않습니다.

가상의 검색 API에서 ‘유효한 요청 중 1초 이내 정상 결과를 반환한 비율’을 지표로 정할 수 있습니다. 무엇을 유효한 요청으로 볼지, 시간 초과와 취소를 어디에 포함할지 먼저 정의해야 숫자를 재현할 수 있습니다.

요청 기반 에러 예산 계산

관찰 기간에 대상 요청이 100,000개이고 목표가 99.9%라면 허용되는 나쁜 요청 수는 100,000 × (1 − 0.999) = 100개입니다. 실제 나쁜 요청이 80개라면 단순 계산으로 예산의 80%를 사용한 것입니다.

이는 요청 기반 예산이며 장애 시간 100초를 뜻하지 않습니다. 시간 기반 가용성과 혼합하지 않습니다. 같은 비율이라도 트래픽이 적은 시간과 많은 시간의 사용자 영향은 다를 수 있습니다.

대시보드에 먼저 넣을 질문

평균만 보면 일부 사용자의 긴 지연이 감춰질 수 있습니다. 반대로 표본이 매우 적은 구간의 비율만 보고 큰 장애로 판단하면 불필요한 알림이 늘어납니다.

알림에 행동을 붙이기

‘CPU 높음’이라는 제목만 보내기보다 영향받는 기능, 지속 시간, 확인할 대시보드, 대응 절차를 함께 제공합니다. 담당자가 당장 할 일이 없다면 호출 알림 대신 정기 점검 항목이 맞을 수 있습니다. 한 장애가 여러 경고를 연속 발생시키면 묶기와 중복 억제 조건을 검토합니다.

에러 예산이 빠르게 줄 때 배포를 보류할지, 특정 위험 변경만 중단할지 미리 합의합니다. 목표 숫자를 정했다고 자동으로 안정성이 좋아지는 것은 아닙니다. 배포 절차와 연결해 실제 결정에 사용해야 합니다.

예산 소진 속도를 계산해 알림 판단하기

목표 성공률이 99.9%이면 허용 실패 비율은 0.1%입니다. 관찰 구간에서 실패 비율이 1%라면 1% / 0.1% = 10으로 목표 대비 열 배 속도로 예산을 쓰는 상황입니다. 이는 가상 계산이며 그대로 적용할 운영 임계값은 아닙니다.

짧은 구간의 요청 10개 중 1개 실패와 10만 개 중 1만 개 실패는 비율은 같아도 영향과 확신이 다릅니다. 알림에는 비율의 분모와 지속 시간을 같이 사용합니다. 짧은 구간에서 급격한 악화를 잡고 긴 구간에서 지속성을 확인하는 방식도 검토할 수 있습니다.

실패가 줄었다고 바로 복구 알림을 보내기보다 정상 상태가 유지되는 시간을 정하면 알림이 켜졌다 꺼지는 현상을 줄일 수 있습니다. 담당자가 보고 바로 확인할 수 있도록 해당 API, 관찰 기간, 나쁜 요청 수, 전체 요청 수, 최근 배포 링크를 함께 제공합니다. 지표 정의를 바꾸면 과거와 비교하는 그래프도 그 변경점을 표시해야 합니다.

참고 자료

• Google SRE Workbook: SLO 구현
• Google SRE Workbook: SLO 기반 알림