사례2건
2건 중 1~2번째
- 증상
2024년 8월 6일 10:32 UTC 부터 Wasabi 전 리전에서 S3 와 사용자 서비스에 오류가 났다. 상태 페이지에는 10:56 UTC 에 Web Console 로그인 문제와 Wasabi 리전의 오류를 조사한다는 글이 올라왔다.
- 촉발
2024년 8월 6일 10:32 UTC 에 큐 서비스가 가득 찬 상태가 됐다.
- 원인
- 구성 요소
- 기여 요인
- –
- 조치
- 운영팀이 데이터베이스에 남은 오래된 연결을 정리하려고 주 데이터베이스를 재시작했고, 동시에 큐 서비스의 큐를 비웠다. 이 조치로는 데이터베이스가 완전히 돌아오지 않았다.
- 보조 데이터베이스 인스턴스를 주 인스턴스로 승격했고, 11:20 UTC 에 S3 서비스가 다시 정상이 됐다.
- 8월 6일 13:17 UTC 부터 13:23 UTC 까지 큐 서비스 라이브러리를 데이터베이스에 완전히 반영하려고 데이터베이스를 한 번 더 재시작했다.
- 8월 7일 두 번째 사건에서 원래의 주 데이터베이스를 다시 운영에 올려 사용자 서비스의 타임아웃을 풀었다.
- 8월 7일 세 번째 사건에서 자동화 서비스가 보지 못하던 자동화 클러스터를 다시 만들어 배포했고, S3 서비스가 완전히 돌아왔다.
IL-0275Kafka 브로커들이 네트워크 한계에 닿아 줄줄이 쓰러지면서 Parse.ly 의 데이터 처리가 멈추고 대시보드에 몇 시간 동안 새 데이터가 나오지 않았다Parse.ly2015- 증상
2015년 3월 26일 목요일 밤, 첫 장애가 나자 PagerDuty 가 한밤중에 온콜 엔지니어를 깨웠다. Munin, Sentry, Pingdom 같은 모니터링 도구에서 장애 보고가 쏟아졌고, Graphite 그래프에도 장애가 보였다. 고객 사이트는 JavaScript 코드를 계속 불러왔지만 분석 데이터가 실시간 처리 스트림으로 흘러 들어오지 않았고, 대시보드에 새 데이터가 나오지 않았다.
- 촉발
2015년 3월 27일 금요일 데이터 양이 한계를 넘어 Kafka 브로커들이 운영체제 네트워크 한계에 닿았고, 한 대가 쓰러지자 나머지가 차례로 쓰러졌다. 그 뒤 클러스터를 넓히려고 넣은 새 브로커들이 잘못된 호스트 이름으로 들어왔다.
- 원인
- 구성 요소
- 기여 요인
- 감지
Munin, Sentry, Pingdom 같은 모니터링 도구에서 장애 보고가 쏟아졌고 Graphite 그래프에서도 확인했다. 첫 장애 때 PagerDuty 가 한밤중에 온콜 엔지니어를 깨웠다.
- 조치
- Kafka 클러스터를 넓히려고 노드를 몇 대 더했다.
- 새 Kafka 노드에 올바른 설정을 넣고 클러스터에 배포했다.
- Apache Storm 으로 하위 컨슈머 시스템을 모두 천천히 다시 켜고, 쌓인 데이터를 다시 처리했다.
- Amazon S3 에 보관한 원시 데이터로 모든 고객 계정에 데이터를 다시 채우기 시작했다.
- 교훈
호스트와 운영체제의 한계까지 생각하면 장애를 피할 수 있는 시스템은 없다. CPU 와 디스크 I/O 는 장비 상태를 잘 보여 주지만, 서서히 늘어나는 네트워크 사용률은 더 해롭고 지켜보기도 어렵다. CPU 는 100% 의 뜻이 분명하지만 네트워크 사용률 100% 는 대부분의 노드에서 뜻이 분명하지 않고, 특히 VM 이 호스트를 나눠 쓰는 클라우드에서 그렇다. 원시 데이터 보관을 웹 서버 로그, 일반 파일, Amazon S3 업로드처럼 단순한 방식으로 하고 실시간 처리 스트림과 완전히 떼어 둔 덕분에 Parse.ly 는 영구 데이터 손실을 걱정하지 않아도 됐다. 기계 한두 대가 아니라 서브시스템 전체가 꺼져 하위 시스템이 손쓸 수 없게 되는 연쇄 장애 상황을 더 깊이 생각해야 한다.
이 2건에서 가장 많이 나오는 구성 요소: 메시지 브로커, 인메모리 캐시. kubegap 은 Claude Code 나 Codex 에서 쿠버네티스 클러스터를 읽기만 하며 이런 틈을 점검합니다. 점검 항목의 근거는 이 라이브러리와 같은 공개 보고서입니다.