사례5건

5건 중 1~5번째

1. IL-0410 AWS SQS Fair Queues 가 정상 메시지를 InvalidParameterValue 로 거부해 AssemblyAI US Async API 요청의 절반가량이 실패했다

   AssemblyAI2026

   증상

   2026년 9월 16일 20:04 UTC 부터 AssemblyAI 의 US Async API 에서 서버 오류가 늘었다. 정점에는 US 엔드포인트의 async 전사 요청 약 50% 가 실패했고, 성공한 요청 일부도 평소보다 오래 걸렸다.

   오류율 상승지연 시간 증가

   촉발

   AWS 쪽의 변경으로 SQS Fair Queues 가 메시지를 InvalidParameterValue 오류로 거부하기 시작했다. 거부된 메시지의 파라미터는 AssemblyAI 서비스가 몇 달 동안 보내던 것이었다. AWS 는 이것이 자기 서비스 쪽 문제라고 확인했고 그날 저녁 변경을 되돌렸다.

   원인

   클라우드 제공자 장애

   구성 요소

   메시지 브로커

   기여 요인

   –

   조치

   • 모든 서비스에서 Fair Queues 를 끄고 일반 SQS 큐로 되돌렸다. 첫 오류로부터 약 한 시간 뒤 정상 운영이 돌아왔다.

   후속 조치

   • 환경 변수에 있는 서비스 설정을 전역 feature flag 시스템으로 옮겨, 이번 같은 조치가 몇 분이 아니라 몇 초 안에 끝나게 한다.
   • 검토를 거친 break-glass 경로, 곧 긴급 배포용 우회 경로를 만들어 급한 수정은 꼭 필요하지 않은 CI 단계를 건너뛸 수 있게 한다.
   • 한 지역에서 제공업체의 의존 서비스가 나빠질 때 기능 단위의 완화 조치에만 기대지 않고 US 파이프라인을 두 번째 지역으로 넘길 수 있게 하는 작업을 우선한다.

   사례 보기
2. IL-0214 Kafka 브로커들이 JVM 힙을 다 써 클러스터 전체로 장애가 번지며 PagerDuty 미국 리전의 이벤트 수집과 알림이 멈추거나 늦어졌다

   PagerDuty2025

   증상

   2025년 8월 28일 03:53 UTC 에 PagerDuty 의 Kafka 에서 장애가 시작됐다. 처음 온 알림은 Kafka 브로커 하나의 고장을 가리켰지만, 곧 다른 브로커들도 메모리가 바닥났다. 미국 서비스 리전의 일부 고객은 새 이벤트가 처리되지 않거나 늦게 처리됐다.

   메모리 압박오류율 상승처리량 저하

   촉발

   API 키 사용 내역을 Kafka 토픽에 남기는 새 기능의 논리 오류로 API 요청마다 새 Kafka 프로듀서가 만들어졌다. 이 기능은 8월 21일 1% 에서 시작해 27일 5%, 같은 날 저녁 25%, 28일 75% 로 롤아웃됐다.

   원인

   배포 결함

   구성 요소

   메시지 브로커

   기여 요인

   모니터링 사각지대잡음에 묻힌 신호늦게 드러난 변경과도한 영향 범위

   감지

   03:53 UTC 에 장애가 시작되자 처음 온 알림은 Kafka 브로커 하나의 고장을 가리켰다. 두 번째 장애는 16:38 UTC 에 Kafka 성능이 다시 떨어지며 울린 알림으로 알았다. 핵심 API 오류를 알리는 중요한 알림은 웹훅 호출에 묻혔다.

   조치

   • 처음 알림이 브로커 하나의 고장을 가리켜 하드웨어 문제를 의심했고, 클러스터를 늘리고 그 브로커를 뺐다.
   • 원인을 조사할 여유를 얻으려고 Kafka 힙 크기를 두 배로 늘렸고, 이를 적용하려고 클러스터 전체를 롤링 재시작해 Kafka 를 안정시켰다.
   • 상태 페이지 자동 게시가 되지 않자 엔지니어링 팀을 더 부르고 백업 절차를 시작해 상태 페이지에 손으로 공지를 올렸다.
   • Kafka 가 돌아온 뒤 여러 애플리케이션을 손으로 복구했고, ksqlDB 스트림 관리 중 생긴 데이터 손실은 스크립트로 백필했다.
   • 두 번째 장애 때 당번 대응자가 힙 크기를 다시 두 배로 늘리고 롤링 재시작했다.
   • API 사용 기능의 롤아웃과 힙 증가 사이의 강한 상관관계를 찾아, 이 기능이 Kafka 메시지를 더는 보내지 않게 하는 풀 리퀘스트로 기능을 되돌렸다.

   후속 조치

   • 상태 페이지 자동 게시를 막은 의존을 없앴고, 손으로 공지하는 런북을 단순하게 고쳐 다시 냈다.
   • 플랫폼 일부가 망가져도 상태 공지가 빨리 나가도록 실전 연습을 평소 업무에 더 꾸준히 넣는다.
   • 힙, 가비지 컬렉션, 프로듀서와 컨슈머 상태 같은 JVM 과 Kafka 수준의 모니터링을 넓혀 가용성에 영향이 가기 전에 부하 신호를 드러낸다.
   • 서비스 의존 관계 지도를 보강해 대응 중에 연쇄 장애를 더 쉽게 따라가게 한다.
   • 고객 영향 지표 수집을 인시던트 작업 흐름에 자동으로 넣어 대응자가 영향 범위를 늘 볼 수 있게 한다.
   • 큰 롤아웃에 준비 점검표와 더 느린 증가 기간 같은 변경 관리 장치를 더 엄격하게 두고, 큰 장애 직후에는 특히 그렇게 한다.
   • 스트리밍 시스템의 복구 방법을 고쳐 장애가 길어질 가능성을 줄인다.
   • 상태 페이지 공지, 내부와 외부 동기화, 알림 같은 소통 작업을 자동화해 혼선을 줄이고 이해관계자가 같은 정보를 보게 한다.
   • 상태 페이지 장애 조치와 PD-on-PD 절차 같은 큰 장애 대응 흐름을 카오스 엔지니어링으로 매달 시험해 자동화에 덜 기댄다.
   • 인시던트 심각도 등급과 전담 소통 담당을 포함한 역할 정의를 더 분명히 해 혼란을 줄이고 대응을 빠르게 한다.

   교훈

   PagerDuty 는 연쇄 장애가 본래 예측하기 어렵고, 한 서비스의 작은 문제가 시스템 도표로는 보이지 않는 길로 다른 서비스에 번진다고 봤다. 관측성의 빈틈 때문에 대응자는 하위 시스템 여러 개가 망가질 때까지 처음 무너진 것을 보지 못했다. 사람은 의존 관계를 직선으로 생각하지만 운영 시스템은 그렇게 움직이지 않는다. 통화에 참여한 누구도 시스템 전체를 머릿속에 담고 있지 않아 의존 관계를 잇는 데 시간이 걸렸다. 새 기능은 안전하게 내려고 별도 배포 대신 설정으로 조금씩 켰는데, 이 때문에 장애와 변경을 바로 잇기 어려웠다. 이 기능은 잘 쓰지 않는 프레임워크와 라이브러리로 만들어서, 요청마다 프로듀서를 새로 만든다는 것이 코드에 드러나지 않았다. 여기에 Kafka 알림이 적었던 것이 겹쳐 점진적 롤아웃 절차가 있어도 장애를 막지 못했다. 중요한 알림이 우선순위 낮은 웹훅 알림에 묻혔고, 백업 절차로 상태 페이지에 공지하는 일처럼 일부 운영 절차는 더 자주 연습해야 했다. 미리 만들어 둔 백필 스크립트와, 처리를 일시 정지했다가 재개하는 런북은 완벽하지 않았지만 대응자에게 출발점을 줬다.

   사례 보기
3. IL-0535 US-EAST-1 에서 AWS 내부용 Kinesis Data Streams 셀 하나가 느려져 CloudWatch Logs 와 이를 쓰는 여러 서비스의 지연과 오류가 늘었다

   Amazon Web Services2024

   증상

   2024-07-30 PDT 오후 2:45 부터 US-EAST-1 리전의 여러 AWS 서비스에서 지연과 오류율이 올랐다. CloudWatch Logs, Amazon Data Firehose, Amazon S3 이벤트를 게시하는 이벤트 프레임워크, Amazon ECS, AWS Lambda, Amazon Redshift, AWS Glue 가 영향을 받았다. 같은 리전의 다른 Kinesis Data Streams 셀로 가는 요청은 정상이었다.

   지연 시간 증가오류율 상승모니터링 중단프로브 실패

   촉발

   2024-07-30 PDT 오전 9:09 에 내부 Kinesis 셀 하나의 가용 영역 한 곳에서 정기 배포가 시작됐다. 이 셀에는 처리량이 아주 낮은 샤드가 아주 많았다. 배포가 호스트를 서비스에서 뺐다가 다시 넣자 셀 관리 시스템이 잘못 동작했다.

   원인

   소프트웨어 결함

   구성 요소

   메시지 브로커서버리스 함수 플랫폼오브젝트 스토리지

   기여 요인

   스테이징 불일치자동화 증폭

   조치

   • PDT 오후 4:25 에 덜 급한 내부 워크로드의 유입 스트림을 줄여 부하를 덜어 내는 변경을 배포했다. 셀 관리 시스템이 처리할 데이터가 줄어 오후 5:39 에 오류율과 지연이 나아지기 시작했다.
   • 보안 연결을 만드는 하위 시스템에 용량을 더해 셀 관리 시스템의 상태를 되살렸다. 오후 5:55 에 셀 관리 시스템이 Kinesis 요청 처리에 쓰는 보안 연결을 제대로 맺었다.
   • 오후 6:32 에 연결 프로비저닝을 더 나아지게 하려고 용량을 더 늘렸고, 오류율이 더 내려갔다.

   후속 조치

   • 장애 중에 한 변경을 US-EAST-1 에 그대로 남긴다. 데이터 플레인 연결을 만드는 용량을 늘리고, 부하를 덜어 내는 도구를 운영에 넣고, 연결 한도를 바꾼 것이 여기에 든다.
   • 새 Kinesis Data Streams 아키텍처의 셀이 있는 다른 모든 AWS 리전에도 같은 변경을 이미 적용했다.
   • 이번 장애를 일으킨 워크로드를 더 잘 다루도록 셀 관리 시스템을 더 고친다.

   사례 보기
4. IL-0384 US-EAST-1 의 Amazon Kinesis Data Streams 에서 레코드 읽기와 쓰기가 하루 대부분 실패했다

   Amazon Web Services2020

   증상

   2020년 11월 25일 5:15 AM PST 에 Kinesis 레코드를 넣고 가져오는 호출의 오류 알람이 울리기 시작했다. Kinesis 를 쓰는 CloudWatch, CloudWatch Events, EventBridge 도 같은 시각부터 오류와 지연을 보였다.

   오류율 상승지연 시간 증가모니터링 중단

   촉발

   2:44 AM PST 부터 3:47 AM PST 까지 Kinesis 프런트엔드 서버군에 비교적 작은 용량을 더했다. AWS 는 이것이 촉발 요인이었지만 근본 원인은 아니었다고 밝혔다.

   원인

   용량 한계

   구성 요소

   메시지 브로커서버리스 함수 플랫폼텔레메트리 에이전트

   기여 요인

   한계 미인지과도한 영향 범위순환 의존

   감지

   5:15 AM PST 에 Kinesis 레코드를 넣고 가져오는 호출의 오류 알람이 울리기 시작했고, 팀이 로그를 보기 시작했다.

   조치

   • 조심하려고 다른 오류를 조사하면서 새로 더한 프런트엔드 용량을 빼기 시작했다.
   • 재시작을 빠르게 하려고, 프런트엔드 서버가 시작할 때 이웃 프런트엔드 서버 대신 정본 메타데이터 저장소에서 바로 데이터를 받도록 설정을 넣기 시작했다.
   • 10:07 AM PST 부터 프런트엔드 서버를 다시 올리며 시간당 수백 대씩 천천히 트래픽을 더했다.
   • Cognito 팀은 장애 초기에 용량을 더해 Kinesis 호출을 버퍼링할 여유를 늘렸다.
   • 10:15 AM PST 에 Cognito 의 Kinesis 의존을 줄이는 변경을 배포하기 시작했고, 오류율이 내려가기 시작했다.
   • 10:36 AM PST 에 엔지니어들이 Lambda 함수 호출 호스트의 메모리 경합을 줄이는 조치를 해서 호출 오류가 풀렸다.
   • 의존이 적은 예비 도구로 Service Health Dashboard 에 게시하고, Personal Health Dashboard 로 영향받은 고객에게 직접 알리고, Service Health Dashboard 에 전역 배너 요약을 올려 고객에게 상황을 알렸다.

   후속 조치

   • CPU 와 메모리가 더 큰 서버로 옮겨 서버 수를 줄이고, 서버마다 서버군 안에서 통신하는 데 필요한 스레드 수를 줄인다.
   • 서비스의 스레드 사용량에 세밀한 알람을 더한다.
   • 운영체제 설정의 스레드 수 한도를 올리는 시험을 마친다.
   • 프런트엔드 서버군의 콜드 스타트 시간을 크게 줄이는 변경을 한다.
   • 프런트엔드 서버 캐시를 전용 서버군으로 옮긴다.
   • CloudWatch 같은 큰 AWS 서비스 몇 개를 따로 나눈 프런트엔드 서버군으로 옮긴다.
   • 백엔드에서 한 것처럼 프런트엔드 서버군의 셀 단위 분리를 크게 앞당긴다.
   • Cognito 웹 서버가 Kinesis API 오류를 겪어도 버퍼를 다 쓰지 않고 버티도록 고쳤다.
   • CloudWatch 로컬 지표 데이터 저장소에 지표 데이터 3시간 치를 보관해, CloudWatch 사용자와 AutoScaling 같은 서비스가 최근 지표를 바로 읽게 한다. US-EAST-1 에는 적용을 마쳤고 앞으로 몇 주 동안 전 세계에 배포한다.
   • 지원 엔지니어가 Service Health Dashboard 예비 게시 도구를 정기적으로 훈련받도록 지원 교육을 바꿨다.

   교훈

   프런트엔드 서버마다 유지할 스레드 수는 서버군의 서버 수에 비례하므로, 서버 수를 줄이면 스레드 수에 큰 여유가 생긴다. AWS 에 따르면 셀 단위 분리는 서비스 안에서 장애의 영향을 가두고, shard-map 캐시 같은 구성 요소가 이미 시험하고 운영해 본 범위 안에서 돌게 하는 방법이다. 프런트엔드 서버군의 셀 단위 분리는 진행 중이었지만 일이 커서 아직 끝나지 않았다. AWS 는 이 작업이 끝나면 앞으로 드러날 모르는 확장 한도에도 더 잘 대비할 수 있다고 봤다.

   사례 보기
5. IL-0588 AppOptics 와 Librato 의 메트릭 API 가 대부분의 데이터에 5xx 를 내고 Kafka 파티션이 리더 없이 오프라인으로 남았다

   AppOptics2018

   증상

   2018년 5월 31일 21:53 UTC 부터 AppOptics 와 Librato 의 메트릭 API 가 들어오는 메트릭 데이터 대부분에 5xx 를 냈다. AppOptics APM 이 보낸 APM 메트릭과 트레이스도 영향을 받았고, 알림 상당수가 늦게 나갔다.

   오류율 상승장애 조치 실패모니터링 중단

   촉발

   AWS US-East-1 리전의 가용 영역 하나에 난 전력 장애로 ZooKeeper 리더 노드를 잃었고, 그 가용 영역의 Kafka 브로커 여럿도 영향을 받았다.

   원인

   클라우드 제공자 장애

   구성 요소

   메시지 브로커코디네이션 키-값 저장소

   기여 요인

   단일 장애점과도한 영향 범위모니터링 사각지대

   조치

   • ZooKeeper 클러스터의 노드 하나를 손으로 재시작해 리더 선출을 일으켰고, 앙상블이 쿼럼을 되찾았다.
   • Kafka 브로커를 하나씩 차례로 재시작해 리더 없이 오프라인이던 파티션을 다시 온라인으로 올렸다.
   • 밀린 작업과 알림을 모두 처리하고 정상 운영으로 돌아갔다.

   후속 조치

   • Kafka 클러스터를 가용 영역 사이, 나아가 리전 사이에 더 잘 격리한다.
   • Kafka 클러스터끼리 ZooKeeper 앙상블을 같이 쓰지 않게 한다.
   • ZooKeeper 쿼럼이 돌아온 뒤 Kafka 가 사람 손 없이 파티션 리더를 되찾는지 게임데이에서 이 상황을 더 재현해 본다. 새 Kafka 버전에서 이 문제가 고쳐졌는지도 확인한다.
   • 복구에 따로 손이 필요한 하위 시스템을 더 일찍 알려 주는 점검을 더 넣었다.

   교훈

   여러 가용 영역에 서비스를 나눠 뒀지만 Kafka 와 ZooKeeper 가 이번처럼 실패하자 격리가 충분하지 않았다. Kafka 클러스터를 가용 영역과 리전 사이에 더 잘 격리하고 Kafka 클러스터마다 ZooKeeper 앙상블을 따로 둬야 한다는 것이 이 장애에서 가장 분명한 할 일이었다. 운영 모니터링을 더 갖췄다면 더 빨리 복구할 수 있었다.

   사례 보기

원인별4