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

사례2건

2건 중 1~2번째

  1. 증상

    2021년 11월 16일 09:35 PT 부터 Google External Proxy Load Balancing, 줄여서 GCLB 를 쓰는 고객의 HTTP/S 요청이 Google 404 오류를 받았다. 전역 GCLB 로드 밸런서가 서비스하는 엔드포인트 대부분이 웹 페이지 대신 404 오류 페이지를 냈다.

    촉발

    고객 설정 규칙을 GCLB 로 전파하는 설정 파이프라인에 경쟁 상태가 있었다. 이 경쟁 상태를 없애는 패치 A 가 아직 배포되지 않은 클러스터에서 경쟁 상태가 실제로 일어나, 손상된 설정 파일이 GCLB 로 올라갔다.

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

    09:50 PT 에 자동 알림이 엔지니어들에게 울렸고, 같은 시각 고객 지원 요청도 들어오기 시작했다.

    조치
    • 09:50 PT 부터 마지막으로 정상이던 설정으로 롤백했고, 10:08 PT 에 롤백이 끝나 404 오류가 멈췄다.
    • 재발 위험을 피하려고 고객이 요청하는 GCLB 설정 변경을 멈췄다. 이 때문에 10:04 PT 부터 11:28 PT 까지 고객은 로드 밸런싱 설정을 바꿀 수 없었다.
    • 변경을 멈춘 동안 재발을 막는 수정을 검증했고, 서비스를 안전하게 다시 열 수 있도록 감독과 모니터링을 더했다.
    • 11:28 PT 에 고객 설정 배포를 다시 열었고 서비스가 정상으로 돌아왔다.
    후속 조치
    • 비슷한 문제를 훨씬 빨리 알려 주는 알림을 곧바로 더했다.
    • 설정을 적용하기 전에 설정이 올바른지 자동으로 검사하는 안전장치를 강화한다.
    • 이런 문제를 격리하고 해결하는 방식을 개선하려고 이미 계획해 둔 아키텍처 변경을 앞당긴다.
  2. 증상

    2017-02-28 오전 Northern Virginia 의 US-EAST-1 리전에서 Amazon S3 가 요청을 처리하지 못했다. GET, LIST, PUT, DELETE 요청이 모두 실패했다.

    촉발

    S3 팀원 한 명이 S3 청구 시스템이 예상보다 느린 문제를 디버깅하고 있었다. 이 팀원은 PST 오전 9:37 에 정해진 플레이북대로 청구 과정이 쓰는 하위 시스템의 서버 몇 대를 빼는 명령을 실행했다. 명령의 입력 하나가 잘못 들어가 의도보다 훨씬 많은 서버가 빠졌다.

    원인
    구성 요소
    기여 요인
    조치
    • 인덱스 하위 시스템을 먼저 재시작했다. PST 오후 12:26 에 GET, LIST, DELETE 요청을 처리할 만큼 용량이 올라왔고, 오후 1:18 에 완전히 회복했다.
    • 인덱스 하위 시스템이 동작하자 배치 하위 시스템을 회복시켰고, PST 오후 1:54 에 회복을 마쳐 S3 가 정상으로 돌아왔다.
    후속 조치
    • 용량을 빼는 도구가 용량을 더 천천히 빼도록 고쳤다.
    • 어떤 하위 시스템이든 필요한 최소 용량 밑으로 떨어지게 하는 용량 제거를 막는 안전장치를 더했다.
    • 다른 운영 도구에도 비슷한 안전 점검이 있는지 감사한다.
    • 핵심 S3 하위 시스템의 회복 시간을 줄인다. 그해 후반에 계획했던 인덱스 하위 시스템의 추가 분할 작업도 앞당겨 바로 시작한다.
    • AWS Service Health Dashboard 의 관리 콘솔이 여러 AWS 리전에서 돌도록 바꿨다.
내 클러스터에도 있는지 확인하기

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

원인별2