사례5건
5건 중 1~5번째
- 증상
2024년 11월 30일 00:17 UTC 부터 Wasabi 의 모든 스토리지 리전에서 Wasabi Cloud Storage 와 Web Console 로 가는 클라이언트 연결 시도가 실패했고, 모든 API 호출이 HTTP 5XX 오류로 끝났다. 상태 페이지에는 00:20 UTC 에 전 리전의 네트워크 오류를 조사하고 있으며 Console 과 S3 서비스 접속이 오류를 낼 수 있다는 글이 올라왔다.
- 원인
- 구성 요소
- 기여 요인
- –
- 조치
- 엔지니어링팀과 운영팀이 내부 서버가 여러 데이터베이스 인스턴스로 요청을 나눠 보내도록 직접 설정해 서비스를 되살렸다.
- 서비스가 돌아온 뒤 내부 메시징 큐를 복구하고 클라이언트 요청을 제대로 처리하는 자동 작업을 다시 돌려 근본 원인을 바로잡는 작업을 했다.
- 증상
2020년 중반부터 세일 이벤트처럼 트래픽이 몰릴 때, 한 기능을 맡은 SQL Server DB 의 초당 배치 실행 수가 일정 임계값을 넘으면 애플리케이션에서 타임아웃 오류가 많이 났다. 여기서 배치는 SQL Server 에서 하나 이상의 쿼리를 묶은 단위다.
- 촉발
세일 이벤트나 럭키백 판매 이벤트로 트래픽이 늘어 초당 배치 실행 수가 일정 임계값을 넘었다.
- 원인
- 구성 요소
- 기여 요인
- –
- 조치
- 컴파일 대기로 블로킹을 일으킨 스토어드 프로시저 네 개의 실행 계획을 플랜 가이드로 고정했다.
- 장애 시간대에 통계가 한 번 이상 업데이트된 테이블을 뽑고, 트래픽이 늘 것으로 보이는 시간대에만 UPDATE STATISTICS tablename WITH NORECOMPUTE 로 그 테이블들의 통계 자동 업데이트를 껐다.
- 트래픽이 가라앉으면 WITH NORECOMPUTE 없이 UPDATE STATISTICS tablename 을 실행해 통계 자동 업데이트를 다시 켰다.
- 플랜 캐시 축출을 줄이려고 메모리에 올라간 데이터 캐시 가운데 용량이 큰 인덱스를 압축해 메모리를 더 효율적으로 쓰게 했다.
- 교훈
근본 원인을 찾지 못한 장애에서도 장애 중에 관찰된 현상 가운데 없애거나 줄일 수 있는 것을 골라 대책을 세우면 장애가 나지 않는 상태를 만들 수 있었다. 조사는 특이하게 변한 지표를 먼저 보고 가설을 세운 뒤 DMV 와 확장 이벤트로 파고들고, 장애 앞뒤 몇 초의 변화를 자세히 보는 순서로 했다.
- 증상
2017년 1월 24일 17:53 UTC 부터 Stack Exchange 네트워크가 약 5분 동안 읽기 전용으로 동작했다. 그 뒤 Stack Overflow 를 포함한 사이트 전체가 12분 동안 내려갔다.
- 촉발
주 SQL Server 인 NY-SQL02 에서 SQL Server 프로세스가 bugcheck 를 일으켰다.
- 원인
- 구성 요소
- 기여 요인
- 조치
- NY-SQL02 의 SQL 서비스를 재시작해 네트워크를 읽기 전용으로 되살렸다.
- SQL 상태를 점검한 뒤 사이트를 읽기·쓰기 모드로 되돌렸다.
- 메모리가 384GB 라서 메모리 덤프가 끝나기를 기다리지 않고 네트워크를 먼저 살렸다.
- NY-SQL02 를 운영에서 빼 메모리 시험을 포함한 점검에 들어갔다. 평소 부하는 모두 NY-SQL01 이 받게 했다.
- 이 기회에 SQL 클러스터를 2016 SP1 CU1 로 올렸다.
- 증상
2017년 1월 12일 14:09 UTC 에 한 운영 리전의 클릭·오픈 트래킹 서비스와 주 MongoDB 클러스터에서 알림이 울렸다. 대부분의 읽기를 맡는 MongoDB secondary 서버가 높은 부하 때문에 요청을 제때 처리하지 못했고, 트래킹 서비스의 오류도 여기서 왔다.
- 촉발
전날 낸 MongoDB 설정 변경 몇 건과 거의 같은 때부터 MongoDB secondary 서버로 들어오는 연결이 서서히 늘었다. 이 변경을 롤백하는 과정에서 사람의 실수로 API 와 SMTP 서비스가 읽기를 primary 로 보내게 됐다.
- 원인
- 구성 요소
- 기여 요인
- 감지
14:09 UTC 에 클릭·오픈 트래킹 서비스와 주 MongoDB 클러스터의 알림이 울려 엔지니어들이 대응을 시작했다.
- 조치
- 전날 낸 MongoDB 설정 변경을 15:15 UTC 부터 새 pull request 여러 개로 롤백했다. 이 과정에서 사람의 실수로 API 와 SMTP 서비스의 읽기를 primary 로 옮기는 변경이 함께 들어갔다.
- 더 많은 연결을 감당하도록 MongoDB 서버 크기를 키웠다.
- 근본 원인을 찾는 동안 서버를 안정시키려고 서버 단에 연결 한도를 넣었다. 서버 크기 조정과 함께 이 조치로 이 리전 API 가 평소 처리량의 약 75% 를 처리했다.
- 20:28 UTC 부터 서비스가 MongoDB primary 서버에 열 수 있는 연결 수에 한도를 두는 변경을 배포했다.
- 읽기에 secondary 서버를 우선하는 설정을 다시 배포했다. 20:35 UTC 에 이 리전 서비스가 정상으로 돌아왔다.
- 후속 조치
- 그동안 한 리전에서만 돌던 트래킹 인프라를 독립된 두 리전에서 운영한다.
- 이 데이터베이스를 쓰는 모든 서비스에 열 수 있는 연결 수의 한도를 둬서, 서비스 하나가 다른 서비스에 주는 피해를 줄인다.
- 주 MongoDB 클러스터 크기를 영구히 키우고, 같은 변경을 다른 데이터센터에도 적용한다.
- 하위 서비스가 실패해도 클릭 리디렉션은 제대로 동작하도록 트래킹 서비스를 고친다.
- 증상
2014년 7월 19일 토요일 오전 9시 30분 프로그램과 클립 메타데이터를 내주는 시스템의 데이터베이스 부하가 치솟아, 애플리케이션 서버로 가는 메타데이터 요청이 많이 실패하기 시작했다. BBC iPlayer, BBC iPlayer Radio, bbc.co.uk 다른 곳의 오디오·비디오 재생이 영향을 받았다.
- 원인
- 구성 요소
- 기여 요인
- 조치
- 가장 먼저 실패한 캐시 계층을 복구했다.
- 캐시 계층 실패가 되풀이되는 동안 홈페이지를 비상 모드로 여러 번 바꿨고, 캐시가 완전히 안정됐다고 확신할 때까지 비상 페이지를 띄워 뒀다.
- 메타데이터 시스템의 성능이 계속 나빠 토요일 오후부터 저녁까지 큰 복구 작업을 했다. 그동안 BBC iPlayer 는 사실상 쓸 수 없었다.
- 주말 남은 기간은 사이트 대부분이 거의 정상으로 도는 상태로 운영했다. 일요일 저녁 피크 시간에 서비스를 더 위험하게 하지 않으려고 완전 복구는 월요일 아침으로 미뤄 진행했다.
- 후속 조치
- 근본 원인을 완전히 이해했는지 확인하는 조사를 마치고, 이런 중단이 다시 일어날 가능성을 줄이는 조치를 넣는다.
이 5건에서 가장 많이 나오는 구성 요소: 데이터베이스, 메시지 브로커. kubegap 은 Claude Code 나 Codex 에서 쿠버네티스 클러스터를 읽기만 하며 이런 틈을 점검합니다. 점검 항목의 근거는 이 라이브러리와 같은 공개 보고서입니다.
원인별1
unknown5건
IL-0545Wasabi 전 리전에서 모든 API 호출이 HTTP 5XX 오류로 실패했다Wasabi2024IL-0441세일 이벤트 때 SQL Server 의 초당 배치 실행 수가 임계값을 넘으면 쿼리가 밀려 애플리케이션 타임아웃 오류가 쏟아졌다ZOZO2021IL-0335주 SQL Server 의 bugcheck 로 Stack Exchange 네트워크가 읽기 전용이 됐다가 12분 동안 내려갔다Stack Exchange2017IL-0387Mailgun 한 리전의 MongoDB 서버가 연결 증가로 과부하돼 트래킹, API, SMTP, 웹사이트에서 간헐적 타임아웃과 오류가 났다Mailgun2017IL-0393프로그램 메타데이터 데이터베이스의 부하가 치솟고 캐시 계층 풀 하나가 실패해 BBC iPlayer 와 재생이 오래 멈췄다BBC2014