Incident Library
적용된 필터 증상프로브 실패기여 요인자동화 증폭조직Google Cloud모두 풀기검색어 없이 필터만 적용한 목록입니다. 최근 사례부터입니다.
추천 필터 검색하면 검색어에서 찾은 분류 값이 여기에 나옵니다.

그래프

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

사례1건

1건 중 1~1번째

  1. 증상

    2017년 4월 5일 01:13 부터 01:35 PDT 까지 22분 동안 Google Cloud HTTP(S) Load Balancer 로 들어온 요청의 25%가 실패했고, 클라이언트는 실패한 요청에 502 오류를 받았다. 최근에 구성을 바꾼 일부 로드 밸런서는 오류율이 100%였다.

    촉발

    구성 갱신을 맡은 master 서버의 복제본 하나가 Google 분산 파일 시스템에 접근하지 못해 최근 구성 파일을 읽지 못한 채 master 역할을 넘겨받았다. 새 master 의 첫 구성 시험이 실패하자 모든 로드 밸런서가 그 master 가 읽을 수 있던 한참 오래된 구성으로 되돌아갔다.

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

    01:22 PDT 에 Google 엔지니어가 호출을 받았다.

    조치
    • 01:34 에 구성 갱신 과정이 다른 master 서버를 쓰도록 바꿨고, 대부분의 서비스가 1분 안에 회복했다.
    • 근본 원인을 확인하는 동안 05:16 까지 HTTP(S) Load Balancer 구성 갱신을 멈췄다.
    후속 조치
    • master 서버가 몇 시간 넘게 지난 HTTP(S) Load Balancer 구성은 절대 배포하지 않도록 설정한다.
    • Google Frontend 서버가 몇 시간 넘게 지난 구성 파일을 읽어 들이지 않고 거부하게 한다.
    • 새 HTTP(S) Load Balancer 구성을 시험하는 과정을 개선해, 오래된 구성이 운영에 배포되기 전에 잡아낸다.
    • master 서버가 Google 분산 파일 시스템에서 파일을 읽다가 실패한 문제를 고친다.
    • 가비지 컬렉션이 많을 때 Google Frontend 의 헬스 체크가 실패하는 문제를 고친다.
내 클러스터에도 있는지 확인하기

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

원인별1