Incident Library

IL-0362 PagerDuty · 2013-04-13awsnetworking

PagerDuty 의 알림 발송이 18분 동안 멈추고 API 가 500 을 냈다

PagerDuty 의 인프라는 AWS 두 곳과 Linode 한 곳, 세 데이터센터에 있었다. PagerDuty 는 AWS 리전 하나를 데이터센터 하나로 보았고, 세 데이터센터를 서로 의존하지 않고 물리적으로 떨어지게 골랐다. 지난 1년 동안 데이터센터 하나가 통째로 나가거나 네트워크에서 갈라져도 버티도록 소프트웨어를 다시 설계했지만, 데이터센터 둘이 한꺼번에 나가는 경우는 설계에 들어 있지 않았다. 나중에 알고 보니 AWS 의 두 데이터센터가 같은 피어링 지점을 쓰고 있었다.

AWS 에 따르면 2013-04-13 태평양 시간 7:57 에 북부 캘리포니아의 피어링 지점이 나빠지며 연결 문제가 시작됐다. 8:11 에 당직 엔지니어가 알림 발송 시스템 노드 하나의 문제로 호출을 받았고, 8:13 에 노드를 되살리려 했지만 실패했다. 8:18 에 모니터링이 알림 제공자 여러 곳의 실패를 감지했고, 알림은 대부분 나갔지만 지연과 오류율이 올랐다. 8:31 에 Sev-2 를 선언했다. 8:35 에 네트워크 지연이 높아 알림 발송 시스템이 쿼럼을 이루지 못해 알림을 전혀 보내지 못하게 됐고, Sev-1 을 선언했다. 장애 동안 실패한 coordinator 프로세스 대부분을 손으로 재시작했고, 8:53 에 알림 발송 시스템이 쿼럼을 이뤄 쌓인 알림을 모두 처리하기 시작했다. AWS 에 따르면 피어링 지점의 연결 문제는 9:23 에 끝났다.

사후 분석에서 coordinator 서비스의 잘못된 설정이 빠른 복구를 막았다는 것도 드러났다. 알림은 8:35 부터 8:53 까지 18분 동안 나가지 않았지만, events API 는 그동안에도 이벤트를 받았다.

심각도
sev1
영향 범위
Notifications were delayed and then not dispatched for 18 minutes between 8:35am and 8:53am Pacific Time; API endpoints returned 500 errors; the events API kept accepting events
영향 사용자
–
지역
two AWS regions sharing a peering point in Northern California
감지까지
14m
복구까지
56m

증상

2013-04-13 태평양 시간 8:11 에 PagerDuty 당직 엔지니어가 알림 발송 시스템의 노드 하나에 문제가 있다는 호출을 받았다. 8:13 에 그 노드를 되살리려 했지만 실패했다.

8:18 에 모니터링 시스템이 연결 문제 때문에 알림 제공자 여러 곳에서 실패가 나는 것을 감지했다. 이때까지 알림은 대부분 나갔지만 지연과 오류율이 올랐다. 고객은 알림이 늦게 오고 API 엔드포인트가 500 을 내는 것을 겪었다.

8:31 에 Sev-2 를 선언하고 엔지니어를 더 불렀다. 8:35 에 네트워크 지연이 높아 알림 발송 시스템이 쿼럼을 이루지 못하면서 알림을 전혀 보내지 못하게 됐고, Sev-1 을 선언했다. 8:35 부터 8:53 까지 18분 동안 알림이 나가지 않았지만 events API 는 그동안에도 이벤트를 받았다.

증상 지연 시간 증가오류율 상승간헐적 연결 실패

원인

원인 클라우드 제공자 장애

구성 요소 트랜짓 게이트웨이와 네트워크 연결 장비코디네이션 키-값 저장소
기여 요인 단일 장애점미검증 가정모니터링 사각지대
촉발
PagerDuty 가 쓰는 AWS 리전 두 곳이 함께 쓰던 북부 캘리포니아의 피어링 지점이 나빠졌다. AWS 에 따르면 연결 문제는 태평양 시간 7:57 에 시작됐다.

감지

8:11 에 당직 엔지니어가 알림 발송 시스템 노드 하나의 문제로 호출을 받았다. 8:18 에 모니터링 시스템이 연결 문제 때문에 알림 제공자 여러 곳에서 실패가 나는 것을 감지했다.

조치

후속 조치

교훈

서로 의존하지 않고 물리적으로 떨어지게 고른 데이터센터 셋 가운데 둘이 같은 피어링 지점을 쓰고 있었고, 그 지점 하나가 나빠지자 두 데이터센터가 함께 오프라인이 됐다. 데이터센터 하나를 잃는 것은 견디게 설계했지만 둘을 함께 잃는 경우는 설계에 없었다. 일부 시스템에는 디버깅할 로그가 부족했고, 호스트 사이 연결을 볼 수단도 부족했다. 모든 엔지니어가 Cassandra 와 ZooKeeper 에 밝지도 않았다.

출처

관련 사례

내 클러스터에도 있는지 확인하기

kubegap 은 Claude Code 나 Codex 에서 쿠버네티스 클러스터를 읽기만 하며 이 사례와 같은 상태를 점검합니다. 이 사례의 구성 요소: 트랜짓 게이트웨이와 네트워크 연결 장비, 코디네이션 키-값 저장소. 점검 항목의 근거는 이 사례 같은 공개 보고서입니다.

kubegap 열기

AI 도구와 스크립트용

API 는 키가 필요 없습니다. MCP 서버는 search_incidents, get_incident, list_incidents, get_topic, vocab 도구를 내놓습니다. 사용법은 API 와 MCP.