{"id":"IL-0383","org":"PagerDuty","date":"2014-06-03","docs":[],"title":{"en":"PagerDuty's shared Cassandra cluster degraded during a repair, delaying notifications and losing incoming events","ko":"PagerDuty 알림 파이프라인이 이틀 연속 장애를 겪어 이벤트를 받지 못하고 알림이 늦거나 가지 않았다"},"domain":["database"],"impact":{"scope":"PagerDuty notification pipeline and integration API: on 3 June about 3% of events not received and a fraction of 1% of notifications delayed; on 4 June 14.9% of events not received, 27.5% of notifications not delivered and 60.9% delayed more than 5 minutes","users":"PagerDuty customers","region":"unknown"},"review":{"written_by":"session","reviewed_at":null,"reviewed_by":null},"lessons":{"en":"PagerDuty concluded that its Cassandra cluster was underscaled and shared by too many services with different load and usage patterns, and that the scaling work should have come before the planned Cassandra version upgrade.","ko":"PagerDuty 는 Cassandra 클러스터의 규모가 모자랐고, 부하와 사용 방식이 서로 다른 너무 많은 서비스가 한 클러스터를 나눠 쓰고 있었다고 밝혔다. 비슷한 문제를 보고 개선을 계획했지만 효율을 기준으로 버전 업그레이드를 먼저 하려 했고, 확장을 먼저 했어야 했다고 적었다."},"related":[],"sources":[{"url":"https://www.pagerduty.com/blog/outage-post-mortem-june-3rd-4th-2014/","kind":"blog","archived":"https://web.archive.org/web/20250524010006/https://www.pagerduty.com/blog/outage-post-mortem-june-3rd-4th-2014/"}],"summary":{"en":"PagerDuty's notification pipeline relies on the Cassandra datastore. On 3 June 2014 the background repair process, which keeps stored data consistent across the cluster and puts heavy strain on Cassandra, started normally on one node. Together with other high load at the time, the repair put the cluster into a heavily degraded state. The team reduced the load and stopped the repair, which helped only for a while: the cluster swung between stability and instability for six hours until the team cut communication between some of the nodes and normal operation came back.\n\nOn 4 June the team restarted the postponed repair by hand after turning off a substantial amount of optional load. The repair eventually brought the outage back, this time more damaging. Repeating the previous day's steps and several other attempts did not stabilise the pipeline, so the team carried out a \"factory reset\" that deleted all in-flight data in the notification pipeline. Cassandra recovered at once and service was restored gradually, although some downstream systems needed manual work to become consistent with the empty pipeline. The root cause analysis was still going on when PagerDuty wrote the post, but PagerDuty knew the cluster was underscaled and shared by too many services with different load and usage patterns. PagerDuty had noticed similar issues recently and planned fixes, but had put the Cassandra version upgrade ahead of the vertical and horizontal scaling and ran out of time; after 4 June the vertical scaling was completed and the split of the Cassandra clusters by workload was partly done.","ko":"PagerDuty 알림 파이프라인은 NoSQL 데이터 저장소인 Cassandra 에 기댄다. 6월 3일 Cassandra 클러스터의 노드 하나에서 repair 작업이 평소대로 시작됐다. repair 는 저장된 데이터를 클러스터 전체에서 일관되게 맞추는 백그라운드 작업이고 Cassandra 에 큰 부담을 준다. 이 작업이 당시의 높은 부하와 겹쳐 클러스터의 성능이 심하게 떨어졌다. 팀은 클러스터의 부하를 줄이고 repair 작업을 멈췄다. 장애는 잠시 풀렸지만 클러스터는 여섯 시간 동안 안정과 불안정을 오갔고, 팀이 일부 노드 사이의 통신을 끊자 정상으로 돌아왔다. 이날 통합 API 로 보낸 이벤트의 약 3% 를 받지 못했고, 1% 에 못 미치는 알림이 늦게 전달됐다.\n\n6월 4일 팀은 전날 미룬 repair 작업을 손으로 다시 시작했다. 꼭 필요하지 않은 시스템 부하를 많이 꺼 두었지만, repair 작업은 결국 전날 장애를 다시 불러왔고 피해는 훨씬 컸다. 이벤트의 14.9% 를 받지 못했고, 알림의 27.5% 는 아예 가지 않았고, 60.9% 는 5분 넘게 늦었다. 전날 절차를 되풀이해도 Cassandra 가 안정되지 않자, 팀은 알림 파이프라인에서 처리 중이던 데이터를 모두 지우는 “factory reset” 을 했다. Cassandra 는 바로 회복했고 서비스는 차츰 정상으로 돌아왔지만, 일부 하위 시스템은 새로 비운 상태와 데이터를 맞추려고 수동으로 손봐야 했다. 두 장애 모두 SEV-1 이었다.\n\nPagerDuty 는 안정화 방법이 왜 듣지 않았는지 근본 원인 분석을 계속하고 있었다. 다만 클러스터 규모가 모자랐고, 부하와 사용 방식이 서로 다른 너무 많은 서비스가 한 클러스터를 나눠 쓰고 있었다는 것은 알고 있었다. 비슷한 문제를 최근에 보고 계획한 개선 일부를 이미 해 두었다. 나머지는 주로 효율을 따져 Cassandra 버전 업그레이드를 수직·수평 확장보다 먼저 하기로 순서를 정했는데, 그 순서대로 하기에는 시간이 모자랐다."},"trigger":{"en":"On 3 June 2014 the Cassandra background repair process started its normal run on one node of the cluster while other high load was on the cluster; on 4 June the team restarted the postponed repair by hand.","ko":"6월 3일 Cassandra 클러스터의 노드 하나에서 repair 작업이 평소대로 시작됐고, 그때 걸린 높은 부하와 겹쳤다. 6월 4일에는 팀이 전날 미룬 repair 작업을 손으로 다시 시작했다."},"severity":"sev1","symptoms":["database-overloaded","high-error-rate","high-latency"],"timeline":{"detected_after":null,"resolved_after":null},"date_kind":"incident","detection":null,"components":["database"],"root_cause":"capacity","remediation":[{"text":{"en":"Reduced the load on the Cassandra cluster","ko":"6월 3일 Cassandra 클러스터의 부하를 줄였다."}},{"text":{"en":"Stopped the Cassandra repair process","ko":"6월 3일 부하를 줄이면서 repair 작업을 멈췄다."}},{"text":{"en":"Cut communication between some Cassandra nodes to stabilise the cluster","ko":"클러스터를 안정시키려고 일부 노드 사이의 통신을 끊었고, 그 뒤 정상으로 돌아왔다."}},{"text":{"en":"On 4 June, deleted all in-flight data in the notification pipeline in a \"factory reset\"","ko":"6월 4일 알림 파이프라인에서 처리 중이던 데이터를 모두 지웠고, Cassandra 가 바로 회복했다."}},{"text":{"en":"Brought downstream systems back into a consistent state with the emptied pipeline by hand","ko":"새로 비운 상태와 데이터를 맞추도록 일부 하위 시스템을 수동으로 손봤다."}}],"action_items":[{"text":{"en":"Scale the existing Cassandra nodes vertically to bigger, faster servers","ko":"기존 Cassandra 노드를 더 크고 빠른 서버로 수직 확장한다. 6월 4일 이후 이 작업은 이미 끝냈다."}},{"text":{"en":"Set up multiple Cassandra clusters and spread the workloads across them","ko":"Cassandra 클러스터를 여러 개로 나누고 작업량을 그 클러스터들에 나눠 싣는다. 부하와 사용 방식에 따라 클러스터를 나누는 작업이 진행 중이다."}},{"text":{"en":"Set system load thresholds at which the Cassandra clusters are scaled out horizontally ahead of need","ko":"시스템 부하 기준을 정해 그 기준에 닿으면 기존 Cassandra 클러스터를 미리 수평 확장한다."}},{"text":{"en":"Upgrade the current and new clusters to a more recent Cassandra version","ko":"기존 클러스터와 새 클러스터를 더 최근 버전의 Cassandra 로 업그레이드한다."}},{"text":{"en":"Add more load shedding techniques to control Cassandra under high load","ko":"높은 부하에서도 Cassandra 를 통제할 수 있도록 로드 셰딩 기법을 더 넣는다."}},{"text":{"en":"Bring more Cassandra expertise in-house","ko":"Cassandra 전문 인력을 사내에 더 둔다."}}],"contributing":["no-spare-capacity","blast-radius-too-wide","manual-action-worsened","early-signal-ignored"],"recurrence_of":null,"symptoms_text":{"en":"On 3 June 2014, PagerDuty's notification pipeline performed poorly and some notifications were delayed after the Cassandra cluster behind it became heavily degraded. About 3% of events sent to the integration API could not be received.\n\nReducing the load and stopping the Cassandra repair helped for a while, but the cluster then swung between stable and unstable periods for six hours until communication between some of the nodes was cut. A small number of notifications, a fraction of 1%, were delivered late that day.\n\nOn 4 June, after the postponed repair was restarted by hand, the outage came back and was much worse: 14.9% of events sent to the integrations API could not be received, 27.5% of notifications were never delivered and 60.9% of notifications were delayed by more than 5 minutes. Repeating the steps that had stabilised Cassandra the day before did not work this time, and several further attempts to stabilise the pipeline failed as well.","ko":"6월 3일 PagerDuty 알림 파이프라인의 성능이 떨어져 일부 알림이 늦게 갔다. 통합 API 로 보낸 이벤트의 약 3% 를 받지 못했고, 1% 에 못 미치는 일부 알림이 늦게 전달됐다.\n\n알림 파이프라인이 쓰는 Cassandra 클러스터의 성능이 심하게 떨어졌다. 클러스터의 부하를 줄이고 repair 작업을 멈춘 뒤에도 클러스터는 여섯 시간 동안 안정과 불안정을 오갔다.\n\n6월 4일 팀이 전날 미뤘던 repair 작업을 손으로 다시 시작하자 전날 장애가 다시 났고 피해는 훨씬 컸다. 통합 API 로 보낸 이벤트의 14.9% 를 받지 못했고, 알림의 27.5% 는 아예 가지 않았고, 60.9% 는 5분 넘게 늦었다.\n\n팀은 먼저 전날 Cassandra 를 안정시킨 절차를 되풀이했지만 같은 결과가 나오지 않았다. 알림 파이프라인 성능을 안정시키려는 시도를 몇 번 더 했지만 소용없었다."},"updated_at":"2026-11-14T12:34:03.458458Z","url":"https://benchlet.com/incidentlib/app/cases/IL-0383","org_slug":"pagerduty"}