사례2건
2건 중 1~2번째
- 증상
2025-03-18 09:36, 사용자들이 운영과 비운영 환경 모두에서 파드가 종료되고 자동으로 다시 뜨지 않는다고 알렸다. 자동 인프라 알림도 함께 울렸고, 운영 서비스에 장애가 났다.
- 촉발
EKS 1.30 업그레이드 중 디스케줄러가 cordon 된 노드의 파드를 모두 한꺼번에 다시 스케줄하려 했다.
- 원인
- 구성 요소
- 기여 요인
- 감지
팀은 자동 인프라 알림과 사용자 보고로 장애를 알았다. 09:36 에 사용자들이 파드가 종료되고 다시 뜨지 않는다고 알렸다.
- 조치
- cordon 어노테이션을 지워 파드가 다시 스케줄되게 했다.
- 멈춘 1.30 노드를 지워 새로 만들어지게 했다.
- 1.30 노드 20대로 된 새 노드 그룹을 손으로 추가했다.
- 예전 1.29 노드를 모두 cordon 하고 drain 해 워크로드를 새 1.30 노드로 옮겼다.
- 후속 조치
- AWS 에 Production System Down 지원 요청을 올려 추가 안내를 받았다. 요청 번호는 174229643100496 이다.
- 비슷한 장애의 원인을 찾을 때 컨트롤 플레인 로그를 어떻게 조회하는지 AWS 지원팀에서 안내받았다.
- 용량이 갑자기 모자랄 때 새 노드 그룹을 급히 늘리는 런북을 쓴다.
- 오토스케일링 그룹과 쿠버네티스가 보는 노드가 어긋나면 울리는 알림을 만든다.
- 디스케줄러가 왜 cordon 된 노드에서 파드를 쫓아내는지 설정을 검토하고, 가능하면 고친다.
- Pending 파드 수가 갑자기 늘면 울리는 알림을 만든다.
- 교훈
이 글은 교훈 대신 후속 조치를 적었다. 조치를 보면 팀에는 비상용 노드 그룹을 급히 추가하는 문서화된 절차가 없었다. 오토스케일링 그룹과 쿠버네티스가 보는 노드가 어긋날 때 울리는 알림도, Pending 파드가 급증할 때 울리는 알림도 없었다. 팀은 디스케줄러가 cordon 된 노드를 어떻게 다루는지도 분명히 알지 못했다.
IL-0024무거운 API 요청이 MongoDB 에 과부하를 걸고 취소되지 않은 요청이 쌓여 Hugging Face Hub 가 사흘 동안 세 번 멈췄다Hugging Face2024- 증상
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 에서 쿠버네티스 클러스터를 읽기만 하며 이런 틈을 점검합니다. 점검 항목의 근거는 이 라이브러리와 같은 공개 보고서입니다.