그래프
사례2건
2건 중 1~2번째
- 증상
미주 지역 오전에 외부 모니터링 서비스가 오류율이 조금씩 오르고 있다며 호출했다. 조사를 막 시작했을 때 사내 대시보드와 알림 서비스까지 먹통이 됐다.
- 촉발
연휴 동안 트래픽이 낮다가 연휴 뒤 첫 월요일에 클라이언트 캐시가 비어 평소보다 많은 데이터를 내려받으면서 트래픽이 하룻밤 새 크게 늘었다. Slack 의 VPC 들을 잇는 AWS Transit Gateway 하나가 이 증가를 따라 충분히 빨리 늘지 못해 과부하가 걸리고 패킷을 버렸다.
- 원인
- 구성 요소
- 기여 요인
- 감지
미주 지역 오전에 외부 모니터링 서비스가 오류율이 오르고 있다며 호출했다. 조사 초기에 대시보드와 알림 서비스가 멈춰, 그 뒤로는 내부 콘솔, 상태 페이지, 명령줄 도구, 로그와 지표 백엔드 직접 조회로 상황을 봤다. TGW 의 패킷 드롭은 AWS 내부 모니터링이 AWS 엔지니어에게 알렸다.
- 조치
- 조사를 돕고 서빙 용량을 지키려고 웹 계층의 자동 축소를 껐다.
- 일부 대응자가 프로비저닝을 끝내지 못한 채 오토스케일링 그룹 크기 한도를 채우던 고장 난 인스턴스를 정리했다.
- provision-service 를 고쳐 PST 오전 8시 15분쯤 다시 돌게 했고, 그때부터 정상 인스턴스가 서비스에 들어오기 시작했다.
- AWS 엔지니어가 내부 모니터링으로 패킷 드롭을 알아채고 Slack 의 TGW 용량을 손으로 늘렸다. PST 오전 10시 40분에 모든 가용 영역에 반영되자 네트워크가 정상으로 돌아왔다.
- 후속 조치
- AWS 가 사고 후속 절차로 초당 패킷 수가 크게 늘 때의 TGW 스케일링 알고리즘을 검토한다.
- 다음 연휴 시즌이 끝날 무렵 TGW 를 미리 증설해 달라고 요청하도록 Slack 리마인더를 걸어 둔다.
- 대시보드 서비스 인스턴스를 데이터베이스와 같은 VPC 에서 돌려 TGW 의존을 없앤다.
- provision-service 를 정기적으로 부하 테스트해 남은 확장 문제가 없는지 확인한다.
- 큰 네트워크 장애 같은 극단적인 상황에서도 provision-service 가 다시 과부하되지 않도록 헬스 체크와 오토스케일링 설정을 다시 검토한다.
- 교훈
모니터링은 사용자 서비스가 정상인지 아는 수단이자 진단의 핵심 도구다. 그래서 Slack 은 모니터링 도구를 Slack 인프라에서 최대한 떼어 두려 했다. 그런데 대시보드와 알림 서비스가 백엔드 데이터베이스와 다른 VPC 에 있어 TGW 에 의존했고, 가장 필요한 순간에 함께 멈췄다. provision-service 는 예전에 부하 테스트를 했지만 이번 증설은 그때의 규모를 넘었다.
- 증상
2013-04-13 태평양 시간 8:11 에 PagerDuty 당직 엔지니어가 알림 발송 시스템의 노드 하나에 문제가 있다는 호출을 받았다. 8:13 에 그 노드를 되살리려 했지만 실패했다.
- 촉발
PagerDuty 가 쓰는 AWS 리전 두 곳이 함께 쓰던 북부 캘리포니아의 피어링 지점이 나빠졌다. AWS 에 따르면 연결 문제는 태평양 시간 7:57 에 시작됐다.
- 원인
- 구성 요소
- 기여 요인
- 감지
8:11 에 당직 엔지니어가 알림 발송 시스템 노드 하나의 문제로 호출을 받았다. 8:18 에 모니터링 시스템이 연결 문제 때문에 알림 제공자 여러 곳에서 실패가 나는 것을 감지했다.
- 조치
- 장애 동안 실패한 coordinator 프로세스 대부분을 손으로 재시작했다.
- 8:53 에 알림 발송 시스템이 쿼럼을 이뤄 쌓여 있던 알림을 모두 처리하기 시작했다.
- 후속 조치
- 일부 시스템의 문제를 디버깅할 로그가 부족했으므로, 로그를 더 남기고 검색하기 쉽게 한곳으로 모으기 시작했다.
- 실패한 coordinator 같은 프로세스를 자동으로 재시작하는 프로세스 감시자를 둔다.
- 호스트 사이 연결 상태를 보여 주는 대시보드를 만든다.
- 모든 엔지니어가 Cassandra 와 ZooKeeper 를 잘 알지는 못하므로, 두 기술을 교육하는 데 시간을 들인다.
- AWS 리전 하나에서 옮겨 가는 방안을 조사한다. 새 호스팅 사업자와 데이터센터를 고를 때 단일 장애 지점이 생기지 않도록 미리 따져 본다.
- 교훈
서로 의존하지 않고 물리적으로 떨어지게 고른 데이터센터 셋 가운데 둘이 같은 피어링 지점을 쓰고 있었고, 그 지점 하나가 나빠지자 두 데이터센터가 함께 오프라인이 됐다. 데이터센터 하나를 잃는 것은 견디게 설계했지만 둘을 함께 잃는 경우는 설계에 없었다. 일부 시스템에는 디버깅할 로그가 부족했고, 호스트 사이 연결을 볼 수단도 부족했다. 모든 엔지니어가 Cassandra 와 ZooKeeper 에 밝지도 않았다.
이 2건에서 가장 많이 나오는 구성 요소: 트랜짓 게이트웨이와 네트워크 연결 장비, 자동 용량 관리 시스템. kubegap 은 Claude Code 나 Codex 에서 쿠버네티스 클러스터를 읽기만 하며 이런 틈을 점검합니다. 점검 항목의 근거는 이 라이브러리와 같은 공개 보고서입니다.