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

사례2건

2건 중 1~2번째

  1. 증상

    2023-12-04 19:50 US/Pacific 부터 us-central1 의 Cloud Bigtable 고객이 지연 증가와 낮은 수준의 연결 오류를 겪었다. 데이터플레인 요청의 약 0.06% 가 영향을 받았고, 자동 모니터링이 23:35 에 처음 잡아냈다.

    촉발

    Cloud Bigtable 서버를 돌리는 머신에 들어간 변경 하나 때문에 격리가 실패했다.

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

    2023-12-04 23:35 US/Pacific 에 자동 모니터링이 처음 잡아냈고 엔지니어가 바로 조사를 시작했다.

    조치
    • 12월 5일 14:40 에 영향받은 머신 일부에서 트래픽 일부를 다른 곳으로 돌려 영향을 일부 줄였다.
    • 격리 문제를 일으킨 변경을 찾아 롤백했고, 12월 6일 03:55 에 지연이 완전히 풀렸다.
    후속 조치
    • 같은 장애가 다시 나지 않도록 통제 장치를 둔다.
  2. 증상

    us-central1 에서 새로 만든 VM 은 네트워크가 동작하기까지 오래 기다려야 했고, 라이브 마이그레이션된 VM 은 마이그레이션 뒤 오래 연결을 잃었다. us-central1 을 오가는 리전 간 트래픽에서 패킷 손실이 났다. 기존 VM 중 마이그레이션되지 않고 상태도 바뀌지 않은 VM 은 직접 영향을 받지 않았다.

    촉발

    관리 플레인의 동작 변경이 us-central1 에 배포됐다. 이 변경은 로드 밸런서 백엔드로 쓰는 GCP Instance Group 과 Network Endpoint Group 의 API 업데이트 처리를 더 잘 분리하려는 것이었다. 이 리전의 큰 워크로드 규모 때문에 가상 네트워크 라우터 컨트롤 플레인의 메모리가 예상 밖으로 늘었다.

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

    엔지니어들은 10월 4일 미국 태평양 시간 21:45 에 us-central1 가상 네트워크 컨트롤 플레인이 느리다는 알림을 받았고, 10월 5일 02:11 에 가상 네트워크 라우터 컨트롤러가 메모리를 다 써서 실패한다는 알림을 받았다. 03:08 부터는 네트워크 텔레메트리가 us-central1 을 오가는 리전 간 패킷 손실을 보여 주었다.

    조치
    • 컨트롤러에 메모리를 더 할당하는 변경을 배포했고, 이 변경은 미국 태평양 시간 05:27 부터 운영 환경에 닿았다. 08:15 에 리전 안 패킷 손실이 가라앉았다.
    • 08:52 에 관리 플레인 변경의 롤백을 시작해 09:35 에 us-central1 에서 마쳤고, 이때 메모리 부족이 모두 멈췄다.
    • 업데이트를 받지 않던 라우터 몇 대를 손으로 재시작했다. 이 재시작으로 패킷 손실이 더 생기지는 않았다.
    후속 조치
    • 메모리 위험과 예상 밖의 메모리 증가를 미리 알리는 알림을 만든다.
    • 엔지니어가 메모리를 훨씬 빨리 다시 할당할 수 있도록 배포 설정을 다시 짠다.
    • API 조정 작업의 기존 관행과 안전장치를 다시 평가하고 새 관행과 안전장치를 만든다.
    • 관리 플레인 변경을 여러 팀이 더 잘 볼 수 있게 해 장애와 더 빨리 연결 짓게 한다.
    • 리전 단위 API 변경 때문에 리전 전체의 메모리가 한꺼번에 바닥나는 일이 줄도록 배포 구성을 바꾼다.
    • 트래픽 라우터와 컨트롤러의 메모리를 최적화해 불필요한 부담을 없앤다.
내 클러스터에도 있는지 확인하기

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

원인별1