Incident Library
적용된 필터 구성 요소CDN 과 엣지 네트워크증상오류율 상승기여 요인과도한 영향 범위모두 풀기검색어 없이 필터만 적용한 목록입니다. 최근 사례부터입니다.
추천 필터 검색하면 검색어에서 찾은 분류 값이 여기에 나옵니다.

그래프

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

사례3건

3건 중 1~3번째

  1. 증상

    2024년 10월 4일, 16일, 21일에 Sentry 의 이벤트 수집에서 오류가 늘었다. 수집 리전 하나에 밀린 트래픽이 쌓였고, 그 리전에서 빠져나간 트래픽을 받은 다른 리전에도 트래픽이 밀려 쌓이면서 트래픽이 거부됐다.

    촉발

    세 사고는 계기가 각각 달랐지만, 세 번 모두 수집 리전 하나에서 밀린 트래픽이 늘어나면서 시작했다.

    원인
    구성 요소
    기여 요인
    후속 조치
    • 연쇄 장애의 가능성을 줄이려고 엣지 리전을 더 작게 더 많이 만들었다. 남아메리카에 첫 리전을 열고, 북아메리카와 유럽에는 하나씩이던 리전을 둘로 늘려 모두 세 리전을 더했다.
    • 오토스케일링 규칙이 원래의 CPU 부하 지표보다 더 강한 신호를 잡도록 바꿨다.
    • iowait 때문에 요청이 밀릴 때 축소가 일어나지 않도록 축소 속도를 낮췄다.
    • 오토스케일링 규칙과 민감도를 더 다듬을 수 있도록 엣지가 내는 지표를 개선한다.
  2. 증상

    2019-02-12 오전 12시 10분 ET에 모니터링 시스템이 CDN 원본 서버군의 정상 노드 수가 안전한 수준 아래로 떨어졌다고 당번 엔지니어에게 알렸다. static.squarespace.com과 static1.squarespace.com 도메인이 영향을 받아 일부 사이트가 이미지, 스크립트, 스타일시트를 불러오지 못했다.

    촉발

    2019-02-11 오후 10시 30분 ET에 한 엔지니어가 Squarespace CDN 원본 서버군 전체에 유지보수 작업을 시작했다. 엔지니어는 작업을 멈췄다고 생각했지만 작업은 백그라운드에서 계속 돌았고, 2019-02-12 오전 12시 10분에 CDN 원본 서비스 장애를 일으켰다.

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

    2019-02-12 오전 12시 10분 ET에 모니터링 시스템이 CDN 원본 서버군의 정상 노드 수가 안전한 수준 아래로 떨어졌다고 당번 엔지니어에게 알렸다. 알림은 서버군이 핵심 가용성 기준 아래로 떨어진 뒤에야 왔고, 고객 영향이 크다는 것은 나중에야 분명해졌다.

    조치
    • 오전 2시 15분 ET까지 추가 복구 조치로 CDN 원본 서버군 일부를 되살렸고, 2시 20분에 서비스가 정상으로 돌아왔다.
    후속 조치
    • 장애 대응 플레이북을 고쳐 이 서버군에 영향을 주는 문제 대부분을 빨리 해결할 점검과 조치를 넣는다. 첫 점검에서 고객 영향을 판단하고 인시던트 커맨더를 바로 부르게 한다.
    • CDN 협력사와 원본 서비스의 문제가 고객에게 주는 영향을 더 빨리 판단할 수 있도록 외부 모니터링을 개선한다.
    • 엔지니어가 유지보수 명령을 내리는 방식의 운영 정책을 고치고 안전장치를 더한다. 그런 명령이 작업할 수 있는 서버군의 범위를 제한한다.
    • 사람이 직접 하는 유지보수 작업이 필요한 경우를 줄인다.
    • 독립된 장애 도메인을 만들고, 상태가 나쁜 부분을 피해 요청을 자동으로 보내도록 해 인프라의 복원력을 높인다.
  3. 증상

    2018년 7월 17일 12시 17분 PDT 부터 Google Cloud App Engine, HTTP(S) 로드 밸런서, TCP/SSL Proxy 로드 밸런서를 쓰는 고객의 요청이 502 응답 코드나 연결 재설정으로 실패했다. 오류 비율은 32분 동안 33% 에서 87% 사이를 오갔다.

    촉발

    두 번째 계층 GFE 코드에는 아직 쓰지 않던 새 기능이 들어가 있었고, 이 기능에 버그가 있었다. 운영 환경의 설정 변경이 이 버그를 간헐적으로 건드렸고, 버그는 GFE 를 재시작시켰다.

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

    12시 19분에 자동 모니터링이 Google 엔지니어링 팀에 알림을 보냈다. 엔지니어는 장애가 시작되고 3분 안에 알림을 받고 바로 조사를 시작했다.

    조치
    • 12시 44분 PDT 에 원인을 찾고 문제의 설정 변경을 곧바로 되돌렸다. 영향받은 GFE 들이 재시작을 멈추고 모두 서비스에 돌아오자 트래픽이 평소 수준과 동작을 되찾았다.
    후속 조치
    • 아직 쓰지 않는 기능을 꺼 두는 안전장치를 더한다.
    • 작업을 재시작시킬 수 있는 잠재 버그가 운영 바이너리에 남을 위험을 줄이도록 GFE 테스트 스택을 더 단단하게 만든다.
    • 장애가 미치는 범위를 줄이도록 GFE 풀의 샤드끼리 더 격리한다.
    • 진단을 빠르게 하도록 GFE 풀의 모든 설정 변경을 한곳에 모은 대시보드를 만들어, 엔지니어가 문제를 일으킨 변경을 쉽게 보고 대조해 찾아내게 한다.
내 클러스터에도 있는지 확인하기

이 3건에서 가장 많이 나오는 구성 요소: CDN 과 엣지 네트워크, 자동 용량 관리 시스템. kubegap 은 Claude Code 나 Codex 에서 쿠버네티스 클러스터를 읽기만 하며 이런 틈을 점검합니다. 점검 항목의 근거는 이 라이브러리와 같은 공개 보고서입니다.

원인별3