사례2건

2건 중 1~2번째

1. IL-0409 배치 작업이 몰려 AWS ENI 한도가 바닥나고 인증 서비스의 태스크가 0개로 줄어 AssemblyAI 의 Async API 와 LLM Gateway 가 25분 멈췄다

   AssemblyAI2026

   증상

   2026년 1월 29일 AssemblyAI 의 Async Transcription API 와 LLM Gateway 가 500 오류를 내며 25분 동안 멈췄다. 상태 페이지에는 17:54 UTC 에 첫 공지가 올라왔다.

   서비스 중단오류율 상승지연 시간 증가클라우드 API 호출 한도 소진

   촉발

   평소보다 많은 배치 전사 작업이 한꺼번에 들어왔다. 오토스케일링이 워커를 늘리다가 spot 인스턴스가 바닥나 on-demand 로 넘어갔고, 그다음 AWS 의 Elastic Network Interface 한도에 걸렸다.

   원인

   용량 한계

   구성 요소

   Amazon ECS

   기여 요인

   과도한 영향 범위모니터링 사각지대자동화 증폭초기 신호 무시

   조치

   • 쌓인 요청을 모두 처리했고, 처리 완료 시간이 정상으로 돌아왔다.

   후속 조치

   • ENI 사용률에 알림을 건다.
   • 인증 서비스를 전용 자원으로 떼어 낸다.
   • AWS API 를 마구 호출한 Lambda 함수를 고친다.
   • 중기적으로 모든 서비스를 완전한 다중 지역 구성으로 옮긴다.

   교훈

   AssemblyAI 는 ENI 사용률을 모니터링하지 않은 것과, 인증 서비스가 배치 워커와 자원을 함께 쓴 것을 실제 잘못으로 꼽았다. 한쪽에 몰린 트래픽이 다른 쪽이 쓸 자원을 빼앗았다. 장애 대응을 돕도록 만든 Lambda 함수가 오히려 복구를 막았다. AssemblyAI 는 이 장애를 막을 수 있었고, 경고 신호가 있었지만 그 신호들을 함께 놓고 보지 못했다고 밝혔다.

   사례 보기
2. IL-0383 PagerDuty 알림 파이프라인이 이틀 연속 장애를 겪어 이벤트를 받지 못하고 알림이 늦거나 가지 않았다

   PagerDuty2014sev1

   증상

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

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

   촉발

   6월 3일 Cassandra 클러스터의 노드 하나에서 repair 작업이 평소대로 시작됐고, 그때 걸린 높은 부하와 겹쳤다. 6월 4일에는 팀이 전날 미룬 repair 작업을 손으로 다시 시작했다.

   원인

   용량 한계

   구성 요소

   데이터베이스

   기여 요인

   여유 용량 부재과도한 영향 범위수동 조치 악화초기 신호 무시

   조치

   • 6월 3일 Cassandra 클러스터의 부하를 줄였다.
   • 6월 3일 부하를 줄이면서 repair 작업을 멈췄다.
   • 클러스터를 안정시키려고 일부 노드 사이의 통신을 끊었고, 그 뒤 정상으로 돌아왔다.
   • 6월 4일 알림 파이프라인에서 처리 중이던 데이터를 모두 지웠고, Cassandra 가 바로 회복했다.
   • 새로 비운 상태와 데이터를 맞추도록 일부 하위 시스템을 수동으로 손봤다.

   후속 조치

   • 기존 Cassandra 노드를 더 크고 빠른 서버로 수직 확장한다. 6월 4일 이후 이 작업은 이미 끝냈다.
   • Cassandra 클러스터를 여러 개로 나누고 작업량을 그 클러스터들에 나눠 싣는다. 부하와 사용 방식에 따라 클러스터를 나누는 작업이 진행 중이다.
   • 시스템 부하 기준을 정해 그 기준에 닿으면 기존 Cassandra 클러스터를 미리 수평 확장한다.
   • 기존 클러스터와 새 클러스터를 더 최근 버전의 Cassandra 로 업그레이드한다.
   • 높은 부하에서도 Cassandra 를 통제할 수 있도록 로드 셰딩 기법을 더 넣는다.
   • Cassandra 전문 인력을 사내에 더 둔다.

   교훈

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

   사례 보기

원인별1