Incident Library
적용된 필터 원인클라우드 제공자 장애구성 요소메시지 브로커증상오류율 상승모두 풀기검색어 없이 필터만 적용한 목록입니다. 최근 사례부터입니다.
추천 필터 검색하면 검색어에서 찾은 분류 값이 여기에 나옵니다.

그래프

  • 원인
  • 구성 요소
  • 증상
  • 기여 요인
  • 사례

사례2건

2건 중 1~2번째

  1. 증상

    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. 증상

    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 앙상블을 따로 둬야 한다는 것이 이 장애에서 가장 분명한 할 일이었다. 운영 모니터링을 더 갖췄다면 더 빨리 복구할 수 있었다.

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

이 2건에서 가장 많이 나오는 구성 요소: 메시지 브로커, 코디네이션 키-값 저장소. kubegap 은 Claude Code 나 Codex 에서 쿠버네티스 클러스터를 읽기만 하며 이런 틈을 점검합니다. 점검 항목의 근거는 이 라이브러리와 같은 공개 보고서입니다.

원인별1