장애 감지를 위한 지표와 알림 조건 정리
커머스 서비스를 운영하면서 HTTP 오류율과 응답 시간, 서버·DB의 상태를 함께 봤습니다. 배포 이후와 트래픽이 몰리는 이벤트에서는 평소와 달라진 구간을 확인해야 했습니다.
지표를 수집하는 것과 담당자에게 알림을 보내는 것은 다른 문제였습니다. 일시적인 변동까지 모두 호출로 이어지면 중요한 알림을 구분하기 어려워, 사용자 영향과 긴급도를 기준으로 조건을 살펴봐야 했습니다.
사용자에게 나타난 증상
HTTP 5xx 비율과 응답 시간은 요청이 정상적으로 처리되는지 볼 수 있는 단서였습니다. 주문·결제처럼 결과가 중요한 기능은 HTTP 상태 외에 실제 처리 결과도 함께 봐야 합니다. 응답 코드가 성공이어도 업무 처리가 실패할 수 있기 때문입니다.
비율을 볼 때는 분모인 요청량도 확인해야 합니다. 요청이 적은 시간대의 실패 한 건과 트래픽이 많은 시간대의 실패 비율은 다르게 해석해야 합니다. 집계 시간과 최소 요청량에 따라 같은 숫자의 의미도 달라집니다.
평균과 느린 요청의 분포
평균 외에 P95·P99 같은 분위수도 확인했습니다. 평균만 보면 일부 느린 요청이 어느 정도의 사용자에게 영향을 주는지 알기 어렵습니다.
그렇다고 느린 요청이 평균에 영향을 주지 않는 것은 아닙니다. 설명용으로 100건 중 98건이 50ms이고 2건이 30초라면 평균은 649ms입니다. 느린 요청 때문에 평균도 크게 바뀝니다. 평균과 분위수는 서로 다른 정보를 주므로 요청량·실패·타임아웃과 함께 보는 것이 맞습니다.
특정 API나 처리 결과를 나눠 보지 않으면 서로 다른 요청이 한 분포에 섞일 수도 있습니다. 전체 응답 시간의 변화와 문제가 있는 요청 종류를 이어서 확인해야 합니다.
자원 지표와 원인 조사
CPU와 메모리, DB 연결 풀, 큐 적재량은 원인을 좁히는 데 도움이 됐습니다. 하지만 CPU가 높다는 이유만으로 사용자 장애를 확정할 수는 없습니다. 반대로 CPU가 낮아도 외부 호출을 기다리느라 응답이 느려질 수 있습니다.
DB 연결 풀의 대기나 큐의 오래된 메시지처럼 장애가 커지기 전에 볼 수 있는 상태도 있습니다. 이런 지표를 모두 같은 긴급도로 취급하기보다, 서비스 영향과 증가 추세를 함께 확인할 필요가 있습니다.
알림 조건과 전달 대상
즉시 대응할 문제와 업무 중 조사할 문제, 대시보드에서 추세를 볼 항목을 구분했습니다. Slack으로 상태를 공유하더라도, 긴급한 알림을 누가 확인하고 이어받는지까지 정해져 있어야 합니다.
등급 이름만으로 대응 시간을 고정할 수는 없습니다. 같은 오류율이라도 영향을 받는 기능과 사용자 범위, 지속 시간에 따라 다릅니다. 팀이 합의한 기준과 담당 경로에 맞춰야 합니다.
짧은 변동이 반복 호출로 이어지지 않도록 지속 조건을 두거나, 같은 문제의 알림을 묶는 방법도 사용할 수 있습니다. 다만 알림을 줄였을 때 실제 장애 감지가 늦어지지 않는지 함께 확인해야 합니다.
알림에서 조사로 이어지는 정보
알림에는 대상 서비스와 발생 시각, 영향을 받은 기능, 확인할 대시보드·로그가 연결돼 있으면 좋습니다. “에러가 늘었다”는 메시지를 받고 처음부터 검색하는 시간을 줄일 수 있습니다.
로그의 오류 코드는 원인을 조사할 단서입니다. 예를 들어 결제 연동의 타임아웃이 늘었다면 상대 시스템의 상태뿐 아니라 네트워크와 우리 쪽 연결 설정·대기 상태도 확인해야 합니다. 오류 이름만으로 원인을 확정하지 않습니다.
운영에서는 알림을 보낸 뒤의 과정도 중요했습니다. 누가 확인했는지, 어떤 조치를 했는지, 복구 뒤 어떤 기준으로 정상 상태를 판단했는지가 이어져야 다음 대응에서도 같은 조건을 검토할 수 있습니다.