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

그래프

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

사례2건

2건 중 1~2번째

  1. 증상

    2025년 10월 20일 07시 6분 UTC에 모니터링 시스템이 IAD 리전, 즉 US-East 의 여러 PubNub 서비스에서 오류가 늘었다는 알림을 냈다. 일부 고객은 오류율과 지연이 오르는 것을 겪었다.

    촉발

    IAD 리전에서 클라우드 사업자인 AWS 에 광범위한 인프라 장애가 났다.

    원인
    구성 요소
    –
    기여 요인
    감지

    07시 6분 UTC에 모니터링 시스템이 IAD 리전의 여러 서비스에서 오류가 늘었다는 알림을 냈다.

    조치
    • 리전 장애 조치 절차를 시작해 새 연결을 다른 리전으로 돌렸다.
    • 이미 맺어진 연결을 손으로 초기화했다.
    • Presence 트래픽을 EU-Central 의 Frankfurt 로 돌렸다.
    • 다른 리전에 인프라를 더 띄워 옮겨 온 트래픽을 받아 냈다.
    • US-West 에 두 번째 저하가 오자 US-East 리전을 다시 떼어 냈다.
    • US-West 의 로드 밸런서 용량을 늘렸다.
    • 사업자가 복구를 알린 뒤 US-East 의 안정을 확인하고 23시 48분까지 트래픽 재분배를 마쳤다.
    후속 조치
    • 모든 운영 서비스의 리전 장애 조치 절차를 한곳에 모아, 바로 찾아 쓸 수 있고 빠진 단계가 없게 한다.
    • 새 서비스의 절차 문서에 빠진 곳을 메워, 운영에 완전히 들이기 전에 장애 조치 준비를 마친다.
    • 장애 중 복구를 어렵게 한 인벤토리 도구와 DNS 이름 해석 문제를 포함해 내부 도구의 문제를 살펴 고친다.
  2. 증상

    Twingate 서비스로 가는 인증과 인가 요청 일부에서 오류율이 올라갔다. 처음에는 여러 GKE 클러스터 가운데 하나에서 이상 동작이 보였다.

    촉발

    GKE 클러스터 하나에서 이상 동작이 보이자 시스템 전체를 지키려고 그 클러스터의 디플로이먼트를 미리 줄였고, 트래픽이 평소 부하가 가벼운 다른 클러스터로 옮겨 갔다.

    원인
    구성 요소
    기여 요인
    감지

    사고 초기에 엔지니어들이 GKE 클러스터 하나에서 이상 동작을 관찰했다.

    조치
    • 앞서 디플로이먼트를 줄였던 클러스터에 용량을 다시 넣어 리전 사이의 트래픽을 다시 나눴고, 오류율과 재시도가 가라앉았다.
    후속 조치
    • 예상하지 못한 타임아웃과 클러스터 업데이트의 영향이 왜 생겼는지 클라우드 사업자와 계속 함께 조사한다.
    • HPA 설정을 고쳐 모든 리전의 디플로이먼트 레플리카 수를 같게 맞췄다.
    • 클러스터 노드 오토스케일러의 최대 노드 수를 늘려 확장할 여유를 키웠다.
    • HPA 가 더 빨리 확장하도록 설정했다.
내 클러스터에도 있는지 확인하기

이 2건에서 가장 많이 나오는 구성 요소: 클라우드 로드 밸런서, 클러스터 오토스케일러. kubegap 은 Claude Code 나 Codex 에서 쿠버네티스 클러스터를 읽기만 하며 이런 틈을 점검합니다. 점검 항목의 근거는 이 라이브러리와 같은 공개 보고서입니다.

원인별1