사례3건

3건 중 1~3번째

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-0257 한꺼번에 몰린 요청에 API Gateway 태스크가 모두 OOM 으로 종료돼 canva.com 이 약 50분 동안 열리지 않았다

   Canva2024

   증상

   2024년 11월 12일 8:47 AM UTC 에 편집기 새 버전을 배포한 뒤, 아시아의 많은 사용자에게 편집기의 객체 패널이 끝없이 로딩 상태로 남았다. 9:08 AM UTC 부터는 canva.com 자체가 열리지 않았다.

   서비스 중단OOMKilled지연 시간 증가패킷 손실

   촉발

   2024년 11월 12일 8:47 AM UTC 에 Canva 편집기 새 버전이 배포돼 클라이언트들이 새 정적 자산을 받기 시작했다. 같은 시각 Cloudflare 의 싱가포르와 애슈번 사이 경로에서 패킷이 손실돼 JavaScript 파일 하나의 전송이 20분 동안 끝나지 않았다.

   원인

   의존성 장애

   구성 요소

   CDN 과 엣지 네트워크API 게이트웨이Amazon ECS

   기여 요인

   장애 중첩모니터링 사각지대재시도 폭주자동화 증폭미패치 알려진 버그

   조치

   • 임시 Cloudflare 방화벽 규칙을 넣어 CDN 에서 모든 트래픽을 막고, 새 API Gateway 태스크가 요청을 받지 않은 상태에서 뜨게 했다.
   • canva.com 을 상태 페이지로 돌려 사용자에게 장애 중임을 알렸다.
   • 엄격한 속도 제한을 건 오스트레일리아 사용자부터 시작해 canva.com 트래픽을 조금씩 되살렸다.

   후속 조치

   • 트래픽을 세밀하게 돌리고 막은 뒤 단계적으로 다시 늘리는 내부 런북을 만든다.
   • canva.com 을 쓸 수 없을 때 사용자에게 더 자세한 오류 페이지를 보여 준다.
   • API Gateway 의 기본 태스크 수와 태스크 하나에 주는 메모리를 늘린다.
   • 비슷한 트래픽 패턴에서 실패할 위험을 줄이는 부하 차단 규칙을 API Gateway 에 더한다.
   • API Gateway 에 정기 부하 테스트를 들인다.
   • 텔레메트리 라이브러리의 스레드 잠금 버그를 고치는 패치를 배포한다.
   • 텔레메트리 라이브러리의 마이크로벤치마크 테스트에 스레드 경합을 일으킨 코드 경로의 멀티스레드 테스트를 더한다.
   • 페이지 자산 카나리 릴리스에서 JavaScript 오류율에 더해 페이지 로드 완료 이벤트를 보조 지표로 본다.
   • 카나리에 롤아웃 단계를 하나 더 두어 단계적 배포 중 문제를 찾을 시간을 늘리는 실험을 한다.
   • 사용자 요청이 자산을 너무 오래 기다리지 않도록 자산 받기에 타임아웃을 둔다.
   • Cloudflare 와 함께 이번 사고에서 여러 시스템이 어떻게 얽혀 작용했는지 자세히 파악한다.

   사례 보기
3. IL-0446 ECS 서비스에 배포한 직후 요청의 20% 쯤이 ALB 의 5XX 를 받았고, 오류는 ap-northeast-1d 에서만 나는 것처럼 보였다

   ITANDI2020

   증상

   운영 ECS 에 배포한 직후 ALB 의 HTTPCode_ELB_5XX_Count 가 갑자기 치솟았다. 분당 1만 건쯤 요청을 받는 서비스에서 요청의 20% 쯤이 5XX 를 받았고, 같은 때 타깃 연결 오류도 났다.

   오류율 상승

   촉발

   CircleCI 와 Terraform 으로 운영 ECS 에 배포해 ECS 태스크가 다시 만들어졌고, 그 시점에 ELB 와 백엔드 사이의 통신이 불안정해졌다.

   원인

   클라우드 제공자 장애

   구성 요소

   클라우드 로드 밸런서Amazon ECS

   기여 요인

   –

   감지

   팀은 운영 ECS 에 배포한 직후 ALB 의 HTTPCode_ELB_5XX_Count 가 갑자기 치솟은 것을 보고 알았다.

   조치

   • ECS 태스크를 가장 먼저 재시작했지만 복구되지 않았다.
   • ELB 의 서브넷 가운데 1d 를 같은 1d 의 다른 서브넷으로 바꿨다. dig 로 ELB 이름을 조회해 IP 가 바뀐 것을 확인했지만 해결되지 않았다.
   • ECS 서비스 설정을 바꿔 ECS 태스크 15개 가운데 1d 에서 돌던 6개를 1a 와 1c 로 옮겼지만 해결되지 않았다.
   • 1d 에서 도는 ECS 태스크가 없어진 뒤 ELB 에서 1d 서브넷을 뺐지만 복구되지 않았다.
   • 배포로 ECS 태스크가 무거워져 ELB 와 백엔드 사이에 타임아웃이 났을 가능성을 보고 ELB 의 유휴 타임아웃 설정을 바꿨지만 복구되지 않았다.
   • ECS 태스크를 배포 전으로 되돌렸지만 복구되지 않았다.
   • VPC, 서브넷, 백엔드, SecurityGroup 이 옛 ELB 와 똑같은 새 ELB 를 만들었다.
   • ECS 서비스 하나에 ELB 여러 개를 붙일 수 있으므로 ECS 서비스에 새 ELB 를 함께 붙였다.
   • 서비스의 호스트 존에 옛 ELB 를 가리키는 레코드와 같은 레코드를 새 ELB 쪽으로 하나 더 만들었다. 두 레코드에 가중치를 줘서 트래픽의 1/10 만 새 ELB 로 보냈다.
   • 새 ELB 에서 ELB_5XX 가 하나도 나오지 않아 옛 ELB 에 문제가 있다고 보고 가중치를 새 쪽 10, 옛 쪽 0 으로 바꿨다.

   교훈

   네트워크 구성상 있을 수 없는 그래프가 보이면 AWS 쪽도 의심해 봐야 한다.

   사례 보기

원인별3