사례4건
4건 중 1~4번째
- 증상
2021년 5월 seek.com.au 에서 구직 검색을 하던 일부 사용자가 오류를 받았고, 장애는 16분 이어졌다. SEEK 는 검색 트래픽을 처리하던 피어링 연결을 Transit Gateway 로 옮기던 중이었고, 검색이 동작하지 않는다는 것을 꽤 빨리 알아챘다.
- 촉발
SEEK 는 VPC 피어링 연결에서 Transit Gateway 로 옮기는 절차의 둘째 단계로 첫 VPC 의 라우팅 테이블만 Transit Gateway 를 쓰게 바꿨다. 이 상태에서는 VPC A 에서 나가는 패킷은 피어링 연결로, VPC B 에서 나가는 패킷은 Transit Gateway 로 가서 오가는 경로가 달라졌다.
- 원인
- 구성 요소
- 기여 요인
- 감지
마이그레이션 도중 SEEK 는 검색이 동작하지 않는다는 것을 꽤 빨리 알아챘다.
- 조치
- 검색이 동작하지 않는 것을 보고 피어링 연결에서 Transit Gateway 로 옮기던 마이그레이션을 롤백했다.
- 후속 조치
- SEEK 환경의 EC2 인스턴스 MTU 를 8500 으로 낮춰 8500 바이트보다 큰 패킷을 보내지 않게 한다. Amazon Linux 2 에서는 네트워크 인터페이스가 올라올 때마다 인터페이스 이름을 인자로 받아 실행되는 /sbin/ifup-local 스크립트를 두어 인스턴스의 기본 MTU 를 8500 으로 덮어쓴다.
- 교훈
SEEK 는 피어링 연결과 Transit Gateway 의 MTU 가 다르다는 중요한 정보를 마이그레이션 전에 알지 못했다. Transit Gateway 가 큰 패킷을 알리지 않고 버린다는 사실은 AWS 의 Transit Gateway 할당량 문서에 적혀 있었지만, SEEK 는 이것이 할당량이라기보다 더 찾기 쉬운 곳에 있어야 할 기본 정보라고 봤다. SEEK 는 이 장애로 MTU, MSS, AWS 관리형 네트워크 장비의 세부 동작을 많이 배웠다. 장애에서 얼마나 배우는지는 장애의 심각도보다 근본 원인을 이해하려는 호기심과 의지에 달려 있다고 보았다.
- 증상
2021-12-07 PST 오전 7시 33분부터 us-east-1 에서 새 인스턴스를 띄우거나 기존 인스턴스를 조회하는 EC2 API 의 오류율과 지연이 늘었다. AWS 운영팀은 혼잡이 시작되자 곧바로 실시간 모니터링 데이터를 볼 수 없었다.
- 촉발
PST 오전 7시 30분에 주 AWS 네트워크에서 도는 한 AWS 서비스의 용량을 늘리는 자동 작업이, 내부 네트워크 안의 많은 클라이언트에서 예상하지 못한 동작을 일으켰다. 연결 시도가 한꺼번에 몰려 내부 네트워크와 주 네트워크 사이의 네트워크 장비가 감당하지 못했다.
- 원인
- 구성 요소
- 기여 요인
- 감지
혼잡이 시작되자 운영팀의 실시간 모니터링 데이터가 곧바로 끊겼다. 운영자는 로그를 보고 상황을 파악했고, 처음에는 내부 DNS 오류가 늘어난 것을 찾았다.
- 조치
- 내부 DNS 트래픽을 혼잡한 네트워크 경로에서 옮겼다. PST 오전 9시 28분에 이 작업을 마치자 DNS 해석 오류가 완전히 회복됐지만 혼잡은 남았다.
- 내부 네트워크의 트래픽을 가장 많이 내는 출처를 찾아 전용 네트워크 장비로 분리했다.
- 네트워크 트래픽이 많은 서비스 일부를 껐다. PST 오후 12시 35분에는 EventBridge 이벤트 전달도 껐다.
- 네트워크 용량을 늘렸다. 혼잡은 오후 1시 34분에 크게 나아졌고 오후 2시 22분에 모든 네트워크 장비가 회복됐다.
- 이번 일을 촉발한 확장 작업을 즉시 껐다.
- 후속 조치
- 모든 개선 조치를 배포할 때까지 이번 일을 촉발한 확장 작업을 다시 켜지 않는다.
- 네트워크 클라이언트가 혼잡에서 제대로 back-off 하지 못하게 한 잠재 문제를 고치는 수정을 만들어 2주 안에 배포한다.
- 비슷한 혼잡이 다시 생겨도 영향받을 수 있는 네트워크 장비를 보호하도록 네트워크 설정을 추가한다. 이 설정은 이미 배포했다.
- 내부 네트워크를 쓸 수 없을 때도 API Gateway 서버가 정상으로 남게 하는 완화책을 만들고, 비슷한 일이 생겼을 때 더 빨리 복구하도록 서버 교체 과정을 개선한다.
- 서비스 영향을 더 쉽게 알아볼 수 있는 새 Service Health Dashboard 를 내년 초에 내놓는다.
- 고객과의 소통이 늦어지지 않도록 여러 AWS 리전에서 동시에 도는 새 구조의 지원 시스템을 내놓는다.
- 증상
미주 지역 오전에 외부 모니터링 서비스가 오류율이 조금씩 오르고 있다며 호출했다. 조사를 막 시작했을 때 사내 대시보드와 알림 서비스까지 먹통이 됐다.
- 촉발
연휴 동안 트래픽이 낮다가 연휴 뒤 첫 월요일에 클라이언트 캐시가 비어 평소보다 많은 데이터를 내려받으면서 트래픽이 하룻밤 새 크게 늘었다. 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 에 밝지도 않았다.
이 4건에서 가장 많이 나오는 구성 요소: 트랜짓 게이트웨이와 네트워크 연결 장비, 자동 용량 관리 시스템. kubegap 은 Claude Code 나 Codex 에서 쿠버네티스 클러스터를 읽기만 하며 이런 틈을 점검합니다. 점검 항목의 근거는 이 라이브러리와 같은 공개 보고서입니다.