장애 발생 1시간 전에 나타나는 징후들

장애 발생 전 나타나는 결정적 징후와 예방 전략

장애 발생 1시간 전에 나타나는 징후들

운영 경력이 길어질수록 한 가지 사실을 깨닫게 됩니다.

대부분의 장애는 갑자기 발생하지 않습니다.

사용자 입장에서는 서비스가 어느 순간 느려지거나 접속이 되지 않는 것처럼 보이지만, 실제 시스템 내부에서는 수십 분 전부터 다양한 경고 신호가 나타나고 있습니다. 문제는 많은 팀이 이러한 신호를 놓친다는 점입니다.

실제로 제가 운영했던 자동화 플랫폼에서도 장애 발생 후 로그를 분석해 보면 “왜 그때는 몰랐을까?” 싶은 징후들이 이미 나타나 있었던 경우가 많았습니다.

Queue 증가, 처리량 감소, 데이터베이스 응답 지연, 외부 API 장애, Thread Pool 포화 등은 대부분 장애가 발생하기 최소 30분에서 1시간 전부터 시작됩니다.

이번 글에서는 운영자가 반드시 확인해야 할 대표적인 장애 전조 증상과 이를 활용한 예방 전략을 정리해 보겠습니다.

장애는 이벤트가 아니라 과정이다

많은 사람들이 장애를 하나의 사건으로 생각합니다.

하지만 실제로 장애는 과정에 가깝습니다.

예를 들어 오전 11시에 서비스가 중단되었다고 가정해 보겠습니다.

운영팀은 11시에 장애가 발생했다고 생각하지만 실제 데이터를 살펴보면 다음과 같은 흐름이 나타나는 경우가 많습니다.

• 오전 10시 00분: 외부 API 응답시간 증가
• 오전 10시 15분: Thread Pool 사용률 상승
• 오전 10시 25분: 응답시간 증가
• 오전 10시 40분: Queue 증가 시작
• 오전 10시 50분: Error Rate 증가
• 오전 11시 00분: 사용자 체감 장애 발생

즉 장애는 갑자기 찾아오는 것이 아니라 여러 단계의 경고를 거쳐 발생합니다.

좋은 운영팀은 장애를 해결하는 팀이 아니라 이러한 과정을 조기에 발견하는 팀입니다.

첫 번째 징후: 응답시간(P99)이 미세하게 증가한다

가장 먼저 나타나는 신호 중 하나는 응답시간 증가입니다.

특히 평균 응답시간보다 P95, P99 응답시간을 보는 것이 중요합니다.

평균값은 문제를 숨길 수 있기 때문입니다.

예를 들어 대부분 요청은 정상 처리되지만 일부 요청만 비정상적으로 느려지고 있는 상황에서는 평균값이 크게 변하지 않을 수 있습니다.

하지만 P99 그래프는 즉시 반응합니다.

운영 현장에서 P99 응답시간이 평소보다 20~30% 증가하기 시작한다면 반드시 원인을 확인해야 합니다.

이 시점은 아직 사용자 불만이 발생하지 않은 경우가 많기 때문에 가장 대응하기 좋은 시기입니다.

두 번째 징후: 처리량은 유지되는데 리소스 사용량이 증가한다

장애 직전에 자주 나타나는 현상 중 하나는 처리량은 그대로인데 CPU나 메모리 사용량만 증가하는 경우입니다.

예를 들어 평소 초당 1,000건을 처리하던 시스템이 있습니다.

그런데 동일한 처리량을 유지하면서 CPU 사용률이 40%에서 75%까지 상승했다면 효율이 떨어지고 있다는 의미입니다.

주요 원인은 다음과 같습니다.

• 비효율적인 코드 배포
• 데이터베이스 쿼리 성능 저하
• 캐시 적중률 감소
• 외부 서비스 응답 지연

이러한 변화는 장애 발생 1시간 전부터 자주 관찰됩니다.

세 번째 징후: Queue 증가보다 먼저 나타나는 Throughput Gap

많은 운영자가 Queue 길이를 중요하게 생각합니다.

물론 중요한 지표입니다.

하지만 Queue는 이미 문제가 발생한 이후 나타나는 결과에 가깝습니다.

더 중요한 것은 Throughput Gap입니다.

Throughput Gap은 유입량과 처리량의 차이를 의미합니다.

예를 들어

• 초당 유입량 1,200건
• 초당 처리량 1,180건

이라면 지금은 문제없어 보입니다.

하지만 시간이 지나면 Queue는 반드시 증가하게 됩니다.

따라서 Queue보다 먼저 Throughput Gap을 모니터링하면 장애를 훨씬 빨리 발견할 수 있습니다.

네 번째 징후: 데이터베이스 커넥션 풀이 포화되기 시작한다

실제 장애 원인의 상당수는 데이터베이스에서 시작됩니다.

특히 Connection Pool 사용률은 매우 중요한 선행 지표입니다.

많은 서비스가 데이터베이스 CPU는 확인하지만 커넥션 상태는 놓치는 경우가 있습니다.

그러나 커넥션 풀이 80~90% 수준에 도달하면 응답 지연이 발생하기 시작합니다.

이후 애플리케이션 스레드가 대기 상태에 들어가고 전체 처리 성능이 감소하게 됩니다.

운영 환경에서는 다음 항목을 함께 확인하는 것이 좋습니다.

• 활성 커넥션 수
• 대기 커넥션 수
• 평균 쿼리 시간
• Slow Query 발생 건수

특히 Slow Query가 갑자기 증가한다면 장애 가능성을 매우 높게 봐야 합니다.

다섯 번째 징후: Retry 작업이 증가한다

Retry Rate는 생각보다 강력한 조기 경고 신호입니다.

많은 운영팀이 에러율만 모니터링하지만 Retry 증가가 에러보다 먼저 나타나는 경우가 많습니다.

예를 들어 외부 API가 느려지기 시작하면 요청이 실패하기 전에 재시도가 증가합니다.

이 시점에서 원인을 파악하면 사용자 영향 없이 문제를 해결할 수 있습니다.

하지만 Retry 증가를 무시하면 결국 Queue 증가와 에러 증가로 이어집니다.

여섯 번째 징후: Error Rate가 아닌 Error Pattern의 변화

장애는 반드시 에러율 증가로 시작되지 않습니다.

실제 운영에서는 에러의 종류가 먼저 바뀌는 경우가 많습니다.

예를 들어 평소에는 없던 다음과 같은 에러가 발생하기 시작합니다.

• Connection Timeout
• Read Timeout
• Thread Exhausted
• Circuit Breaker Open
• Database Lock Wait Timeout

에러 건수 자체보다 에러 패턴의 변화가 더 중요한 이유가 여기에 있습니다.

장애 1시간 전에 반드시 확인해야 할 대시보드

운영자가 매일 확인해야 하는 핵심 항목은 다음과 같습니다.

1. P99 응답시간
2. Error Rate
3. Retry Rate
4. Queue Depth
5. Throughput Gap
6. Consumer Lag
7. Database Connection Pool
8. CPU Saturation
9. Thread Pool Utilization
10. External API Latency

이 지표들을 한 화면에서 볼 수 있다면 대부분의 장애는 사용자에게 영향을 주기 전에 발견할 수 있습니다.

실제로 효과가 있었던 대응 방법

제가 가장 효과를 봤던 방법은 임계치 기반 알림보다 변화율 기반 알림을 사용하는 것이었습니다.

예를 들어 CPU 사용률이 80%를 넘을 때 알림을 보내는 것이 아니라,

“최근 10분 동안 CPU 사용률이 30% 이상 증가”

같은 조건으로 알림을 설정하는 것입니다.

장애는 절대적인 수치보다 변화 속도에서 시작되는 경우가 많기 때문입니다.

이를 적용한 이후 장애를 사전에 발견하는 비율이 눈에 띄게 높아졌습니다.

결론

장애는 예고 없이 발생하지 않습니다.

응답시간 증가, 처리량 감소, Retry 증가, 커넥션 풀 포화, Queue 증가 같은 신호들이 순차적으로 나타난 뒤 최종적으로 사용자 장애로 이어집니다.

문제는 이러한 신호가 너무 작아서 쉽게 지나칠 수 있다는 점입니다.

그래서 운영자의 역할은 장애가 발생한 후 대응하는 것이 아니라, 장애 발생 1시간 전에 이미 나타난 징후를 발견하는 것입니다.

결국 안정적인 시스템은 뛰어난 장애 복구 능력으로 만들어지는 것이 아니라 작은 이상 신호를 놓치지 않는 관찰력에서 시작됩니다. 장애를 줄이고 싶다면 장애 로그보다 먼저 장애의 전조 증상을 기록하고 분석하는 습관부터 만들어 보시기 바랍니다.