빌드업웍스
서버가 아니라 데이터베이스가 원인이었습니다
고객사가 지목한 원인은 실제 원인이 아니었습니다. 지표로 확인해 진짜 원인을 찾았습니다.
99.9%45분간 포화
장애 분석장애 당일 15:30~17:30 · 전일·전전일 동시간대 대비 · CloudWatch 지표
- 01 지목된 원인을 뒤집었습니다 의심 세션은 원인이 아니었습니다. 지표가 그렇게 말했습니다.
- 02 증상과 원인을 분리 서버 CPU 급등은 결과였고, 진짜 원인은 DB였습니다.
- 03 읽기 전용 분석 조회만으로 찾았습니다. 인프라 변경 0건, 서비스 영향 0.
THE PROBLEM DB가 느려지자 앱이 응답을 기다리며 쌓였습니다. 앱 CPU는 그 결과였습니다 — 여기서 서버를 키웠다면 돈만 쓰고 재발했을 것입니다.
어떤 상황이었나
먼저 눈에 띈 것은 애플리케이션 서버의 CPU였습니다. 플랫폼팀은 누적 수치가 압도적으로 큰 세션 하나를 원인으로 지목했습니다. 합리적인 의심이었지만, 지표는 다른 이야기를 하고 있었습니다.
증상 눈에 띈 곳 — 애플리케이션 서버
원인 실제 원인 — 데이터베이스
WHAT WE DID
무엇을 했나
- 1 건드리지 않고 봤습니다
읽기 전용 조회만. 장애가 끝난 시스템을 또 흔들 이유가 없습니다.
- 2 부하를 쪼갰습니다
장애 시간대만 떼어 대기 유형별·호스트별·쿼리별로 나눠 봤습니다.
- 3 지목된 원인을 걷어냈습니다
의심 세션의 실제 기여도는 무시할 수준. 진짜 원인은 다른 곳에 있었습니다.
진짜 원인은 소수의 비효율 쿼리였습니다. 서버를 키웠다면 돈만 쓰고 재발했을 것입니다.
지목된 원인
누적값이 커 보였을 뿐, 장애 시간대 실제 기여도는 무시 가능한 수준이었습니다
진짜 원인
소수의 비효율 쿼리가 높은 동시성으로 실행되며 연산 자원을 채웠습니다
남긴 것
촉발 원인은 앱 측 데이터가 필요해 확정하지 않고 확인 요청으로 남겼습니다
GOOD FIT
우리 회사도 해당될까요?
해당되는 항목을 눌러보세요. 많이 켜질수록 이 사례와 비슷한 상황입니다.
0/3 항목을 눌러 확인해 보세요.
맞지 않는 경우도 있습니다 — 먼저 말씀드립니다
효과가 제한적인 경우
- 지표 보관 기간이 지난 장애 — 되돌려 볼 데이터가 없습니다
- 촉발 원인이 애플리케이션 코드 쪽에 있는 경우 — 인프라 지표만으로는 확정되지 않습니다
이런 경우엔 권하지 않습니다
- "일단 서버를 키워달라"는 요청에는 먼저 원인부터 보자고 말씀드립니다 — 원인이 쿼리면 키워도 다시 옵니다.
- 지표 보관 기간이 지난 장애는 추정만 가능합니다. 추정을 원인으로 보고드리지 않습니다.
- 범위
- 전부 읽기 전용 조회. 분석 과정에서 인프라에 어떠한 변경도 하지 않았습니다.
- 고객사 공수
- 애플리케이션 쪽 요청량 데이터는 고객사 확인이 필요했습니다 — 저희 지표만으로는 촉발 원인이 확정되지 않아 그대로 말씀드렸습니다.
이 사례가 실증하는 약속 — 모니터링
게시 · 검토 · 전 사례 익명(계약 조건) · 원인 규명 가능 여부는 남아 있는 지표에 따라 달라지며, 모든 장애의 원인을 찾을 수 있다고 보장하지 않습니다.