사례2건
2건 중 1~2번째
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일이 걸렸고, 관계없는 장애가 동시에 겹쳐 복구가 더 힘들었다.
IL-0123응답 버퍼를 재사용하지 않는 버그로 라우팅 계층 노드가 메모리 한도에 걸려 레디니스 검사에 실패했고, 트래픽이 몰리자 남은 노드가 모자라 모든 모델에서 요청 상당수가 502, 503 오류로 실패했다.OpenAI2023- 증상
2023년 11월 8일 태평양 시각 오전 5시 42분부터 7시 16분까지 OpenAI 로 가는 요청 상당수가 502 나 503 오류로 실패했다. 모든 모델과 API 엔드포인트에서 실패가 크게 늘었다.
- 촉발
그날 아침 completion 요청이 그전 어느 날보다 훨씬 많이 들어왔다.
- 원인
- 구성 요소
- 기여 요인
- 조치
- 들어오는 트래픽을 제한했다.
- 서비스를 한꺼번에 재배포했다.
- 트래픽을 천천히 다시 올렸다.
- 후속 조치
- 루프에서 responseBuffer 를 매번 새로 할당하던 코드를 버퍼를 미리 할당해 재사용하도록 고쳤다. 배포 뒤 메모리와 CPU 사용량이 모두 3배 개선됐다.
- 설정된 메모리 한도를 알맞은 수준으로 조정해 서비스에 여유 용량을 넉넉히 확보했다.
- 트래픽을 더 매끄럽게 덜어 낼 수 있도록 rate limit 제어를 여러 가지 넣었다.
- 추가 예방책으로 서비스 용량을 늘렸다.
- 메모리 동작 이상이 서비스 문제로 커지기 전에 잡아내도록 여러 알림을 바꾼다.
- 이 서비스에 오토스케일링을 설정한다. 용량을 늘리면 상위 서비스에 영향을 주던 문제를 바로잡았기 때문에 이제 설정할 수 있다.
이 2건에서 가장 많이 나오는 구성 요소: 클러스터 오토스케일러, 애플리케이션 데이터베이스. kubegap 은 Claude Code 나 Codex 에서 쿠버네티스 클러스터를 읽기만 하며 이런 틈을 점검합니다. 점검 항목의 근거는 이 라이브러리와 같은 공개 보고서입니다.