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

사례2건

2건 중 1~2번째

  1. 증상

    2025-03-05 01:00 UTC 무렵부터 일부 고객의 LKE 클러스터가 IP ACL 을 켠 상태에서 오토스케일링에 실패했고, 서비스 장애로 이어졌다.

    촉발

    가장 최근에 배포한 LKE 소프트웨어 릴리스에 결함이 있었다.

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

    고객 쪽 문제는 01:00 UTC 무렵 시작됐고, 상태 페이지의 첫 조사 공지는 06:49 UTC 에 올라왔다.

    조치
    • 임시 조치로 게이트웨이 파드를 재시작했지만 잠깐만 효과가 있었다.
    • 문제가 된 소프트웨어 릴리스를 롤백했고, 15:00 UTC 무렵 영향받은 모든 클러스터에서 롤백을 마쳤다.
    후속 조치
    • 근본 원인을 계속 조사하고 알맞은 재발 방지 조치를 한다.
    교훈

    결함은 IP ACL 을 켠 클러스터에서만 문제를 일으켰고, autoscaler 가 노드를 추가하려 할 때 드러났다. 게이트웨이 파드 재시작은 효과가 오래가지 않았고, 릴리스를 롤백하자 장애가 끝났다.

  2. 증상

    2024-04-22 CET 8:45 부터 Hugging Face Hub 가 불안정해졌고, 9:30 에는 응답하지 않았다. 대부분의 사용자에게 Hub 웹사이트가 느려지거나 아예 열리지 않았다.

    촉발

    *_info_cache 컬렉션을 쓰는 무거운 API 요청이 갑자기 늘었다. 첫 장애 직전에는 https://huggingface.co/api/datasets/lighteval/mmlu/revision/main 호출이 크게 늘었고, 4월 23일 밤에는 https://huggingface.co/api/models/sentence-transformers/all-mpnet-base-v2/revision/main 요청이 늘었다.

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

    장애는 4월 22일 8:45 부터 Hub 가 불안정해지다가 9:30 에 응답하지 않으면서 드러났다. MongoDB Atlas 지표에서 읽기 전용 노드 두 대가 계속 재시작하는 것이 보였다. 24일 10:03 에는 팀이 수상한 지표를 보고 Hub 가 다시 멈추기 전에 rate limit 을 걸었다. 근본 원인은 URL 별 요청 수 그래프를 새로 만든 뒤에 찾았다.

    조치
    • Java/* user-agent 를 단 요청을 모두 막는 방화벽 규칙을 넣었다.
    • Hub 의 quicksearch 기능을 껐다.
    • MongoDB Atlas 클러스터를 손으로 tier 2 에서 tier 3 으로 올렸다.
    • AWS WAF 로 유지보수 모드를 켜 503 페이지를 띄우고 들어오는 트래픽을 막았다.
    • Hub 파드를 모두 0 으로 줄였다가 다시 올렸다.
    • 아주 엄격한 rate limit 을 걸었다.
    • 요청에 타임아웃을 넣고, 오래 걸리거나 응답 본문이 큰 데이터베이스 쿼리를 다시 짰다.
    후속 조치
    • 요청마다 평소 완료 시간에 맞춘 타임아웃을 넣었다.
    • 장애 중 오래 걸리거나 응답 본문이 큰 요청을 찾아 최적화하고, 잘못 설계된 데이터베이스 쿼리를 다시 짰다.
    • 쓰지 않는 오래된 인덱스를 지워 데이터베이스를 정리했다.
    • 장애 중 새 대시보드와 모니터링 지표를 만들었다.
    • *_info_cache 를 Redis 로 옮긴다.
    • 클라이언트가 요청을 취소하면 데이터베이스 요청도 취소할 수 있게 한다.
    교훈

    Hub 팀은 모든 차트를 봐도 답이 없을 때 URL 별 요청 수라는 새 그래프를 만들어서야 원인을 찾았다. 클라이언트가 떠난 뒤에도 서버가 데이터베이스 요청을 계속 돌리면, 서비스가 느려졌을 때 사용자가 누르는 새로고침이 부하를 몇 배로 키운다. 무거운 요청 몇 가지가 데이터베이스 전체를 흔들 수 있으므로 요청별 타임아웃과 취소가 필요하다. 팀은 이번 일로 어떤 지표를 더 가까이 봐야 장애를 미리 막을 수 있는지 알게 됐다. 원인을 찾는 데 2-3일이 걸렸고, 관계없는 장애가 동시에 겹쳐 복구가 더 힘들었다.

내 클러스터에도 있는지 확인하기

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

원인별1