Incident Library

IL-0383 PagerDuty · 2014-06-03database

PagerDuty 알림 파이프라인이 이틀 연속 장애를 겪어 이벤트를 받지 못하고 알림이 늦거나 가지 않았다

PagerDuty 알림 파이프라인은 NoSQL 데이터 저장소인 Cassandra 에 기댄다. 6월 3일 Cassandra 클러스터의 노드 하나에서 repair 작업이 평소대로 시작됐다. repair 는 저장된 데이터를 클러스터 전체에서 일관되게 맞추는 백그라운드 작업이고 Cassandra 에 큰 부담을 준다. 이 작업이 당시의 높은 부하와 겹쳐 클러스터의 성능이 심하게 떨어졌다. 팀은 클러스터의 부하를 줄이고 repair 작업을 멈췄다. 장애는 잠시 풀렸지만 클러스터는 여섯 시간 동안 안정과 불안정을 오갔고, 팀이 일부 노드 사이의 통신을 끊자 정상으로 돌아왔다. 이날 통합 API 로 보낸 이벤트의 약 3% 를 받지 못했고, 1% 에 못 미치는 알림이 늦게 전달됐다.

6월 4일 팀은 전날 미룬 repair 작업을 손으로 다시 시작했다. 꼭 필요하지 않은 시스템 부하를 많이 꺼 두었지만, repair 작업은 결국 전날 장애를 다시 불러왔고 피해는 훨씬 컸다. 이벤트의 14.9% 를 받지 못했고, 알림의 27.5% 는 아예 가지 않았고, 60.9% 는 5분 넘게 늦었다. 전날 절차를 되풀이해도 Cassandra 가 안정되지 않자, 팀은 알림 파이프라인에서 처리 중이던 데이터를 모두 지우는 “factory reset” 을 했다. Cassandra 는 바로 회복했고 서비스는 차츰 정상으로 돌아왔지만, 일부 하위 시스템은 새로 비운 상태와 데이터를 맞추려고 수동으로 손봐야 했다. 두 장애 모두 SEV-1 이었다.

PagerDuty 는 안정화 방법이 왜 듣지 않았는지 근본 원인 분석을 계속하고 있었다. 다만 클러스터 규모가 모자랐고, 부하와 사용 방식이 서로 다른 너무 많은 서비스가 한 클러스터를 나눠 쓰고 있었다는 것은 알고 있었다. 비슷한 문제를 최근에 보고 계획한 개선 일부를 이미 해 두었다. 나머지는 주로 효율을 따져 Cassandra 버전 업그레이드를 수직·수평 확장보다 먼저 하기로 순서를 정했는데, 그 순서대로 하기에는 시간이 모자랐다.

심각도
sev1
영향 범위
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
영향 사용자
PagerDuty customers
지역
–
감지까지
–
복구까지
–

증상

6월 3일 PagerDuty 알림 파이프라인의 성능이 떨어져 일부 알림이 늦게 갔다. 통합 API 로 보낸 이벤트의 약 3% 를 받지 못했고, 1% 에 못 미치는 일부 알림이 늦게 전달됐다.

알림 파이프라인이 쓰는 Cassandra 클러스터의 성능이 심하게 떨어졌다. 클러스터의 부하를 줄이고 repair 작업을 멈춘 뒤에도 클러스터는 여섯 시간 동안 안정과 불안정을 오갔다.

6월 4일 팀이 전날 미뤘던 repair 작업을 손으로 다시 시작하자 전날 장애가 다시 났고 피해는 훨씬 컸다. 통합 API 로 보낸 이벤트의 14.9% 를 받지 못했고, 알림의 27.5% 는 아예 가지 않았고, 60.9% 는 5분 넘게 늦었다.

팀은 먼저 전날 Cassandra 를 안정시킨 절차를 되풀이했지만 같은 결과가 나오지 않았다. 알림 파이프라인 성능을 안정시키려는 시도를 몇 번 더 했지만 소용없었다.

증상 데이터베이스 과부하오류율 상승지연 시간 증가

원인

원인 용량 한계

구성 요소 데이터베이스
기여 요인 여유 용량 부재과도한 영향 범위수동 조치 악화초기 신호 무시
촉발
6월 3일 Cassandra 클러스터의 노드 하나에서 repair 작업이 평소대로 시작됐고, 그때 걸린 높은 부하와 겹쳤다. 6월 4일에는 팀이 전날 미룬 repair 작업을 손으로 다시 시작했다.

감지

–

조치

후속 조치

교훈

PagerDuty 는 Cassandra 클러스터의 규모가 모자랐고, 부하와 사용 방식이 서로 다른 너무 많은 서비스가 한 클러스터를 나눠 쓰고 있었다고 밝혔다. 비슷한 문제를 보고 개선을 계획했지만 효율을 기준으로 버전 업그레이드를 먼저 하려 했고, 확장을 먼저 했어야 했다고 적었다.

출처

관련 사례

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

kubegap 은 Claude Code 나 Codex 에서 쿠버네티스 클러스터를 읽기만 하며 이 사례와 같은 상태를 점검합니다. 이 사례의 구성 요소: 데이터베이스. 점검 항목의 근거는 이 사례 같은 공개 보고서입니다.

kubegap 열기

AI 도구와 스크립트용

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