IL-0024 Hugging Face · 2024-04-22ai-infra
2024년 4월 22일 CET 8:45 부터 24일 10:03 까지 Hugging Face Hub 에 긴 장애가 이어졌다. 그사이 Hub 는 세 번 크게 멈췄고, 대부분의 사용자에게 Hub 웹사이트가 느려지거나 열리지 않았다. Hub 는 MongoDB Atlas, Gitaly, AWS WAF 위에서 돈다.
원인은 일부 API 요청이 데이터베이스에 주는 부담이었다. https://huggingface.co/api/models/sentence-transformers/all-mpnet-base-v2/revision/main 을 호출하면 이 모델과 연결된 Space 300여 개의 목록이 함께 나왔고, 이 호출은 space_info_cache 컬렉션을 썼다. 이 URL 로 가는 트래픽 증가는 데이터베이스 네트워크 송신량 증가와 정확히 맞아떨어졌고, 송신량 증가는 여러 장애에 앞서 나타났다. 팀은 k6 로 가상 사용자 512명이 10분 동안 이 URL 을 호출하는 스크립트를 돌려 Hub 가 느려지거나 멈추는 것을 재현했다. 첫 장애는 이 URL 때문이 아니었고, 직전에 요청이 크게 늘어난 https://huggingface.co/api/datasets/lighteval/mmlu/revision/main 이 계기였다. 이 호출은 데이터베이스에 큰 부담을 준 세 컬렉션 중 하나인 datasets_info_cache 를 썼다.
상황을 더 나쁘게 만든 것은 Hub 의 NodeJS 코드였다. 사용자가 요청을 취소해도 Hub 는 데이터베이스 요청을 취소하지 않았다. 페이지가 느려 사용자가 새로고침하면, 이미 진행 중인 데이터베이스 요청은 응답을 받을 사람이 없어도 끝까지 돌았다. 그래서 같은 순간에 요청이 한꺼번에 몰리는 thundering herd 문제가 생겼다. 누군가 데이터베이스에 요청을 대량으로 보내는 것처럼 데이터베이스 상태가 좋지 않을 때는 처리되지 않은 요청이 계속 쌓여 결국 장애로 이어졌다.
팀은 MongoDB 클러스터 tier 를 올리고, Java user-agent 를 막고, quicksearch 기능을 끄고, 유지보수 모드로 트래픽을 막고, Hub 파드를 0 으로 줄이는 방식으로 매번 복구했다. 24일 10:03 에 아주 엄격한 rate limit 을 건 뒤로는 Hub 가 더 멈추지 않았다. 이후 요청마다 평소 완료 시간에 맞춘 타임아웃을 넣고, 오래 걸리거나 응답 본문이 큰 요청을 찾아 최적화했으며, 잘못 설계된 데이터베이스 쿼리를 다시 짰다. 같은 시기에 관계없는 시스템 장애가 겹쳐 복구가 더 어려웠다.
2024-04-22 CET 8:45 부터 Hugging Face Hub 가 불안정해졌고, 9:30 에는 응답하지 않았다. 대부분의 사용자에게 Hub 웹사이트가 느려지거나 아예 열리지 않았다.
MongoDB Atlas 지표를 보면 읽기 전용 노드 두 대가 내려가 계속 재시작하고 있었다. 클러스터는 한 번 자동으로 tier 1 에서 tier 2 로 커졌고, 팀은 이어서 손으로 tier 3 까지 올렸다. 내부 출처에서 Java/17 user-agent 를 단 트래픽이 치솟는 것이 보였다. 팀은 그 user-agent 를 막는 방화벽 규칙을 넣었지만, 부하만 줄었을 뿐 근본 문제는 그대로였다. 데이터베이스가 건강해 보인 뒤에도 Hub 는 불안정했다.
장애는 되풀이됐다. 4월 23일 21:30 에는 연결 수와 시스템 메모리가 급격히 늘면서 primary 가 OOM 으로 죽었다. 클러스터가 primary 를 바꿨지만 같은 일이 반복됐고, 결국 예전 primary 가 다시 primary 로 뽑혔다. 4월 24일 8:00 에도 같은 패턴으로 Hub 가 느려지고 응답하지 않았고, 10:03 에는 지표가 다시 수상하게 튀었다.
팀은 모든 차트와 그래프를 뒤져도 원인을 찾지 못했다. 데이터베이스 로그와 지표를 보면 *_info_cache 컬렉션이 지나치게 많이 쓰이고 있었다. 평균 지연 시간도 나빴고 네트워크 송신량은 매우 높았다. 원인은 URL 별 요청 수 그래프를 새로 만든 뒤에야 드러났고, 찾기까지 2-3일이 걸렸다.
장애는 4월 22일 8:45 부터 Hub 가 불안정해지다가 9:30 에 응답하지 않으면서 드러났다. MongoDB Atlas 지표에서 읽기 전용 노드 두 대가 계속 재시작하는 것이 보였다. 24일 10:03 에는 팀이 수상한 지표를 보고 Hub 가 다시 멈추기 전에 rate limit 을 걸었다. 근본 원인은 URL 별 요청 수 그래프를 새로 만든 뒤에 찾았다.
Hub 팀은 모든 차트를 봐도 답이 없을 때 URL 별 요청 수라는 새 그래프를 만들어서야 원인을 찾았다. 클라이언트가 떠난 뒤에도 서버가 데이터베이스 요청을 계속 돌리면, 서비스가 느려졌을 때 사용자가 누르는 새로고침이 부하를 몇 배로 키운다. 무거운 요청 몇 가지가 데이터베이스 전체를 흔들 수 있으므로 요청별 타임아웃과 취소가 필요하다. 팀은 이번 일로 어떤 지표를 더 가까이 봐야 장애를 미리 막을 수 있는지 알게 됐다. 원인을 찾는 데 2-3일이 걸렸고, 관계없는 장애가 동시에 겹쳐 복구가 더 힘들었다.
IL-0150 DynamoDB DNS 자동화의 경쟁 조건이 us-east-1 리전 엔드포인트의 DNS 레코드를 비워 DynamoDB 와 EC2 인스턴스 시작이 실패했고, 그 여파로 EKS, ECS, Fargate 의 컨테이너 시작과 클러스터 스케일링이 14시간 넘게 막혔다Amazon Web Services · 2025같은 원인 · 공통 애플리케이션 데이터베이스
같은 원인 · 공통 클러스터 오토스케일러
IL-0196 Redis Operator 로 레플리카를 늘리면서 메모리 한도를 낮추자 데이터를 가진 유일한 Redis 파드가 재시작됐고, Sentinel 이 빈 레플리카를 마스터로 올려 데이터가 모두 지워졌다.Palark · 2020같은 원인 · 공통 애플리케이션 데이터베이스
https://incidentlib-mcp.benchlet.com/mcpAPI 는 키가 필요 없습니다. MCP 서버는 search_incidents, get_incident, list_incidents, get_topic, vocab 도구를 내놓습니다. 사용법은 API 와 MCP.