{"id":"IL-0362","org":"PagerDuty","date":"2013-04-13","docs":[],"title":{"en":"PagerDuty could not dispatch notifications for 18 minutes when a peering point shared by two AWS regions degraded","ko":"PagerDuty 의 알림 발송이 18분 동안 멈추고 API 가 500 을 냈다"},"domain":["aws","networking"],"impact":{"scope":"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","users":"unknown","region":"two AWS regions sharing a peering point in Northern California"},"review":{"written_by":"session","reviewed_at":null,"reviewed_by":null},"lessons":{"en":"Datacenters chosen to be independent and physically separate can still share a network peering point, and a design built to survive the loss of one datacenter did not survive losing two at once.","ko":"서로 의존하지 않고 물리적으로 떨어지게 고른 데이터센터 셋 가운데 둘이 같은 피어링 지점을 쓰고 있었고, 그 지점 하나가 나빠지자 두 데이터센터가 함께 오프라인이 됐다. 데이터센터 하나를 잃는 것은 견디게 설계했지만 둘을 함께 잃는 경우는 설계에 없었다. 일부 시스템에는 디버깅할 로그가 부족했고, 호스트 사이 연결을 볼 수단도 부족했다. 모든 엔지니어가 Cassandra 와 ZooKeeper 에 밝지도 않았다."},"related":[],"sources":[{"url":"https://www.pagerduty.com/blog/outage-post-mortem-april-13-2013/","kind":"blog","archived":"https://web.archive.org/web/20250527001800/https://www.pagerduty.com/blog/outage-post-mortem-april-13-2013/"}],"summary":{"en":"PagerDuty ran in three datacenters, two AWS regions and one at Linode, and had spent a year rearchitecting its software to survive the loss of a whole datacenter, including a network partition, but not of two at once. The three were chosen to be physically separate with no dependency between them, yet two of them turned out to share a common peering point. On 13 April 2013 at 7:57am Pacific Time that peering point in Northern California began to degrade, and both AWS datacenters went offline, leaving PagerDuty with only the Linode datacenter.\n\nFrom 8:11 the on-call engineer was paged about a node of the notification dispatch system, and by 8:18 notifications showed higher latency and error rates. At 8:35 high network latency stopped the dispatch system from reaching quorum and no notifications went out until 8:53, when quorum returned and queued notifications were processed; the events API kept accepting events. Most failed coordinator processes were restarted by hand, and the post-mortem found that a misconfiguration of the coordinator service slowed recovery. AWS reported the peering point connectivity issue ended at 9:23. The analysis also found that some systems lacked the logging needed to debug them, that there was no good view of inter-host connectivity, and that not all engineers were current on Cassandra and ZooKeeper.","ko":"PagerDuty 의 인프라는 AWS 두 곳과 Linode 한 곳, 세 데이터센터에 있었다. PagerDuty 는 AWS 리전 하나를 데이터센터 하나로 보았고, 세 데이터센터를 서로 의존하지 않고 물리적으로 떨어지게 골랐다. 지난 1년 동안 데이터센터 하나가 통째로 나가거나 네트워크에서 갈라져도 버티도록 소프트웨어를 다시 설계했지만, 데이터센터 둘이 한꺼번에 나가는 경우는 설계에 들어 있지 않았다. 나중에 알고 보니 AWS 의 두 데이터센터가 같은 피어링 지점을 쓰고 있었다.\n\nAWS 에 따르면 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 에 끝났다.\n\n사후 분석에서 coordinator 서비스의 잘못된 설정이 빠른 복구를 막았다는 것도 드러났다. 알림은 8:35 부터 8:53 까지 18분 동안 나가지 않았지만, events API 는 그동안에도 이벤트를 받았다."},"trigger":{"en":"At 7:57am Pacific Time, according to AWS, a peering point in Northern California began to degrade, causing connectivity problems for the two AWS regions that PagerDuty used as two of its three datacenters.","ko":"PagerDuty 가 쓰는 AWS 리전 두 곳이 함께 쓰던 북부 캘리포니아의 피어링 지점이 나빠졌다. AWS 에 따르면 연결 문제는 태평양 시간 7:57 에 시작됐다."},"severity":"sev1","symptoms":["high-latency","high-error-rate","intermittent-connection-failures"],"timeline":{"detected_after":"14m","resolved_after":"56m"},"date_kind":"incident","detection":{"en":"The PagerDuty on-call engineer was paged at 8:11am about an issue with one node of the notification dispatch system, and at 8:18 monitoring detected multiple-provider failures for notifications.","ko":"8:11 에 당직 엔지니어가 알림 발송 시스템 노드 하나의 문제로 호출을 받았다. 8:18 에 모니터링 시스템이 연결 문제 때문에 알림 제공자 여러 곳에서 실패가 나는 것을 감지했다."},"components":["interconnect","coordination-store"],"root_cause":"cloud-provider","remediation":[{"text":{"en":"Restarted most of the failed coordinator processes by hand","ko":"장애 동안 실패한 coordinator 프로세스 대부분을 손으로 재시작했다."}},{"text":{"en":"The notification dispatch system reached quorum again and processed all queued notifications","ko":"8:53 에 알림 발송 시스템이 쿼럼을 이뤄 쌓여 있던 알림을 모두 처리하기 시작했다."}}],"action_items":[{"text":{"en":"Add more logging and aggregate logs into a single searchable source","ko":"일부 시스템의 문제를 디버깅할 로그가 부족했으므로, 로그를 더 남기고 검색하기 쉽게 한곳으로 모으기 시작했다."}},{"text":{"en":"Add a process watcher that restarts failed coordinator processes automatically","ko":"실패한 coordinator 같은 프로세스를 자동으로 재시작하는 프로세스 감시자를 둔다."}},{"text":{"en":"Build a dashboard that shows inter-host connectivity","ko":"호스트 사이 연결 상태를 보여 주는 대시보드를 만든다."}},{"text":{"en":"Train engineering staff on Cassandra and ZooKeeper","ko":"모든 엔지니어가 Cassandra 와 ZooKeeper 를 잘 알지는 못하므로, 두 기술을 교육하는 데 시간을 들인다."}},{"text":{"en":"Investigate moving off one of the AWS regions to a new hosting provider and datacenter that avoids a single point of failure","ko":"AWS 리전 하나에서 옮겨 가는 방안을 조사한다. 새 호스팅 사업자와 데이터센터를 고를 때 단일 장애 지점이 생기지 않도록 미리 따져 본다."}}],"contributing":["single-point-of-failure","assumption-unverified","monitoring-blind-spot"],"recurrence_of":null,"symptoms_text":{"en":"On Saturday 13 April 2013 at 8:11am Pacific Time, PagerDuty's on-call engineer was paged about one node of the notification dispatch system, and an attempt at 8:13 to bring the node back failed. Customers saw delayed notifications and 500 errors on PagerDuty's API endpoints.\n\nAt 8:18 PagerDuty's monitoring detected failures across multiple notification providers, caused by the connectivity problem; most notifications still went through but with higher latency and error rates. A Sev-2 was declared at 8:31 and more engineers were paged. At 8:35 the notification dispatch system lost the ability to dispatch at all because it could not establish quorum under the high network latency, and a Sev-1 was declared. The events API kept accepting events throughout.\n\nAt 8:53 the dispatch system reached quorum again and began processing the queued notifications, 18 minutes after dispatch stopped. Most of the coordinator processes that had failed were restarted by hand, and a misconfiguration of the coordinator service kept PagerDuty from recovering faster.","ko":"2013-04-13 태평양 시간 8:11 에 PagerDuty 당직 엔지니어가 알림 발송 시스템의 노드 하나에 문제가 있다는 호출을 받았다. 8:13 에 그 노드를 되살리려 했지만 실패했다.\n\n8:18 에 모니터링 시스템이 연결 문제 때문에 알림 제공자 여러 곳에서 실패가 나는 것을 감지했다. 이때까지 알림은 대부분 나갔지만 지연과 오류율이 올랐다. 고객은 알림이 늦게 오고 API 엔드포인트가 500 을 내는 것을 겪었다.\n\n8:31 에 Sev-2 를 선언하고 엔지니어를 더 불렀다. 8:35 에 네트워크 지연이 높아 알림 발송 시스템이 쿼럼을 이루지 못하면서 알림을 전혀 보내지 못하게 됐고, Sev-1 을 선언했다. 8:35 부터 8:53 까지 18분 동안 알림이 나가지 않았지만 events API 는 그동안에도 이벤트를 받았다."},"updated_at":"2026-11-14T12:34:01.513182Z","url":"https://benchlet.com/incidentlib/app/cases/IL-0362","org_slug":"pagerduty"}