사례2건

2건 중 1~2번째

1. 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. IL-0205 Google Cloud us-east1 의 SSD 영구 디스크 재고가 바닥나 GKE 클러스터 오토스케일러가 프로덕션 노드를 늘리지 못했고, API 디플로이먼트가 파드를 띄울 용량을 얻지 못했다.

   GitLab2021

   증상

   2021-06-21 08:05 UTC 부터 API 의 Apdex 가 나빠지고 Rails 대기열이 늘어나는 추세가 보였다. Apdex 는 목표 시간 안에 끝난 요청의 비율로 사용자 만족도를 나타내는 지표다. 08:43 에 ahmad 가 Slack 에서 장애를 선언했고, 09:01 에 API 디플로이먼트가 비정상 상태이고, 노드를 늘려 파드 용량을 더할 수도 없다는 것을 확인했다.

   노드 증설 실패지연 시간 증가파드 Pending배포 실패

   촉발

   GitLab 이 운영하는 GCP us-east1 리전에서 SSD 재고가 바닥난 상태였는데, 사용자 트래픽이 늘어 API 서비스가 노드를 늘려야 했다.

   원인

   클라우드 제공자 장애

   구성 요소

   클러스터 오토스케일러노드 풀

   기여 요인

   모니터링 사각지대디버그 접근 제한장애 중첩

   감지

   로그를 한참 뒤져서 찾았다. 클러스터 오토스케일러 오류는 일부 노드가 백오프 상태라 확장할 수 없다고만 했고, 인스턴스 그룹 수준 오류도 ZONE_RESOURCE_POOL_EXHAUSTED 뿐이어서 어떤 자원이 바닥났는지 알 수 없었다. 결국 GCP 지원팀이 SSD 재고 부족을 알려 주었다. 탐지까지 22시간이 걸렸고, 팀은 자원 가용성 알림이 있었다면 탐지와 진단을 앞당길 수 있었다고 보았다.

   조치

   • 09:55 에 pd-standard 디스크를 쓰는 노드 풀을 하나 더 만들었다.
   • 10:37 에 새 노드 풀이 늘어나지 않자 API 부담을 덜려고 이 노드 풀을 세 존 모두에서 손으로 늘렸다.
   • 13:42 에 배포가 막혀 있고 다른 워크로드도 같은 영향을 받고 있어서 pd-standard 디스크를 쓰는 새 노드 풀들을 올리기로 했다.
   • 18:16 에 canary 시험에서 클러스터 오토스케일러가 새 노드 풀과 함께 동작하지 않자 프로덕션 배포를 막는다고 공지하고, 오토스케일러 문제로 Google 에 지원 케이스를 열었다.
   • 18:26 에 남은 워크로드의 노드 풀과 nodeSelector 를 바꾸는 인프라 작업을 시작했다.
   • pd-standard 노드 풀 위주로 하루 동안 운영하며 문제가 없는 것을 확인한 뒤 SSD 노드 풀을 정리해 없앴다.

   후속 조치

   • 쿠버네티스 서비스를 pd-standard 디스크로 옮겼다.
   • 자원 고갈 오류를 지표로 수집한다.

   교훈

   장애를 수습하는 도중 다른 버그를 만나 대응 전체가 느려졌다. 팀에는 클라우드 자원 가용성을 감시할 수단도, 자원을 미리 예약해 둘 수단도 없었다. 워크로드는 pd-ssd 대신 pd-standard 디스크에서도 문제없이 도는 것으로 보였다.

   사례 보기

원인별2