사례9건

9건 중 4~8번째

1. IL-0099 메모리 상한 없이 8GB 만 보장한 프로필 때문에 워크숍 중 사용자 파드가 서로를 축출해 서버 시작이 15분을 넘고 커널이 죽었다.

   2i2c2025

   증상

   2025년 5월 12일 20:15 EEST 에 Freshdesk 지원 티켓이 들어왔다. 워크숍 중 사용자 서버가 시작하는 데 15분 넘게 걸리고 커널이 죽는다는 내용이었다. 같은 허브를 다른 용도로 쓰던 강사들도 영향을 받았다.

   파드 축출

   촉발

   워크숍 사용자들이 메모리 상한이 없는 프로필로 보장량 8GB 보다 많은 메모리를 꾸준히 썼다.

   원인

   용량 한계

   구성 요소

   컨테이너 메모리 한도노드 풀

   기여 요인

   리소스 요청과 한도 미설정

   감지

   커뮤니티가 Freshdesk 지원 티켓으로 알렸다. 티켓은 20:15 에 열렸고 20:49 에 #support-freshdesk 슬랙 채널로 팀에 전달됐으며, 20:57 에 첫 엔지니어가 확인했다.

   조치

   • 5월 12일 21:05 에 helm 롤아웃과 허브 재배포를 했고 상황이 일부 나아졌다.
   • 5월 13일 15:51 에 medium 프로필을 열었고, 그 메모리 보장량을 올려 오버커밋을 줄였다.
   • 17:15 에 30명 워크숍을 위해 노드 15개를 미리 띄웠다.
   • 5월 14일 워크숍 전에 작은 노드용 프로필의 메모리 보장량과 상한을 같게 맞춰 명시적인 메모리 상한을 두는 변경을 배포했다.

   후속 조치

   • 장애 보고서를 쓴다.
   • 내부 회고를 열어 이번 장애에서 배울 점을 정리한다.

   교훈

   메모리 상한 없이 보장량만 둔 프로필에서는 노드를 나눠 쓰는 사용자끼리 서로를 축출할 수 있다. 메모리 보장량과 상한을 같게 두면 한 사용자의 메모리 급증이 같은 노드의 다른 사용자에게 번지지 않는다. 이번에는 로그에 뚜렷한 오류가 없었고 원인은 프로필 설정에 있었다. 워크숍 직전에는 프로필 구조를 바꾸지 않고 노드를 미리 띄우는 쪽으로 대응했다.

   사례 보기
2. IL-0070 dask-gateway로 워커를 대량으로 띄우자 노드가 1분 만에 100대 늘었고, Prometheus가 메모리를 거의 다 쓰던 코어 노드에서 hub 파드를 비롯한 중요한 파드들이 축출되거나 재시작됐다

   2i2c2023

   증상

   2023년 2월 1일 leap 클러스터의 prod 허브에서 노드가 대량으로 늘었고, hub 파드가 알 수 없는 이유로 재시작됐다. 사용자 지원 티켓도 들어왔다.

   파드 축출파드 Pending

   촉발

   한 사용자의 dask-gateway 작업이 1분 사이에 dask-worker 노드를 100대쯤 늘렸고, Prometheus 는 노드 200대쯤의 지표 내보내기 대상을 수집하기 시작했다.

   원인

   용량 한계

   구성 요소

   Prometheus노드 풀

   기여 요인

   여유 용량 부재과도한 영향 범위모니터링 사각지대

   감지

   2i2c Freshdesk에 들어온 사용자 지원 티켓 414로 드러났다. 이후 엔지니어가 Grafana와 클러스터의 노드, event를 살폈다. 조사 내용은 같은 날 UTC+1 기준 저녁 8시에서 9시 사이에 이슈에 정리됐다.

   후속 조치

   • basehub에서 hub와 proxy 파드의 CPU와 메모리 요청을 넉넉히 설정한다. 이슈 #2127이다.
   • Grafana의 OOMKiller 대시보드가 제대로 동작하게 고친다. 이슈 #2213이다.
   • LEAP 클라우드 인프라를 공유 노드 구성으로 옮긴다. 이슈 #2209다.
   • ingress-nginx와 Prometheus의 리소스 요청과 한도를 고친다. Prometheus 서버는 메모리 요청을 한도와 같게 맞춘다. 이슈 #2324다.
   • Prometheus가 daskhub 워커 파드를 수집하도록 넣은 설정이 필요한지 다시 본다. 이슈 #2366이다.

   교훈

   Prometheus 서버처럼 메모리를 많이 쓰는 파드가 요청보다 훨씬 많이 쓰면 같은 노드의 중요한 파드가 축출된다. 노드가 한꺼번에 100대 늘면 Prometheus가 수집할 대상도 함께 늘어난다. hub와 proxy처럼 중요한 파드는 실제 사용량보다 요청을 넉넉히 잡아야 축출과 CPU 부족을 피할 수 있다. 쿠버네티스 event는 60분이 지나면 사라지므로, OOMKill 여부를 나중에 확인하려면 따로 기록해 두어야 한다.

   사례 보기
3. IL-0096 GCP europe-west2-b 존의 자원이 바닥나 이 존 하나에 묶인 GKE 노드 풀이 늘어나지 못했고, LIS 허브의 사용자 서버가 6시간 30분 동안 뜨지 않았다.

   2i2c2022

   증상

   2022년 11월 14일 LIS 허브 사용자가 "backoff after failed scale-up" 오류를 보고했다. 사용자 서버가 뜨지 않았고 노드 풀이 늘어나지 않았다.

   노드 증설 실패파드 Pending서비스 중단

   촉발

   영국 시각 오전 10시에 Google Cloud europe-west2 리전의 B 존에서 할당할 자원이 바닥났다.

   원인

   클라우드 제공자 장애

   구성 요소

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

   기여 요인

   단일 장애점온콜 호출 미전달

   감지

   사용자가 "backoff after failed scale-up" 오류를 보고하면서 장애가 드러났다. 영향은 태평양 시각 02:00 에 시작됐고, 인시던트는 3시간 40분 뒤인 05:40 에 열렸다.

   조치

   • GCP 콘솔에서 해당 노드 풀을 고쳐, 자원이 남아 있던 같은 리전의 A 존과 C 존에도 노드를 만들 수 있게 했다.

   후속 조치

   • 다음 둘 중 하나를 한다. 블랙 프라이데이 행사가 끝나면 노드 풀을 다시 B 존으로만 묶거나, 클러스터와 NFS 를 A 존으로 옮긴다.
   • 리전 단위 NFS 를 쓸 수 있는 엔터프라이즈 요금제를 알아본다. 비용은 더 든다.
   • PagerDuty 알림이 언제나 엔지니어에게 닿도록 한다.

   교훈

   엔지니어 한 명이 인시던트 지휘, 공지, 디버깅을 오랫동안 혼자 맡았다. 팀이 함께 나서서 이 엔지니어를 더 많이 도울 수 있었다. 호출 알림이 대응 엔지니어에게 닿지 않아 이 문제가 더 커졌다. "backoff after failed scale-up" 은 보통 쿼터 문제지만 이번에는 쿼터를 올려도 소용이 없었다. 원인은 로그의 ZONE_RESOURCE_POOL_EXHAUSTED 오류에서 드러났다.

   사례 보기
4. IL-0500 UToronto JupyterHub 의 데이터베이스 디스크가 가득 차서 로그인과 서버 시작이 500 오류로 실패했다

   2i2c2022

   증상

   UToronto JupyterHub 에서 새로 로그인하거나 서버를 시작하려는 사용자가 500 오류를 받았다. 이미 로그인해 있던 사용자는 계속 허브를 쓸 수 있었다.

   오류율 상승영구 볼륨 가득 참

   촉발

   hub 로그가 hub 의 sqlite 데이터베이스와 같은 10G 디스크에 쌓였고, 아주 커진 로그 파일이 디스크를 다 채웠다.

   원인

   용량 한계

   구성 요소

   데이터베이스영구 볼륨과 스테이트풀셋JupyterHub

   기여 요인

   한계 경보 부재

   감지

   경보가 없었다. 사용자가 오후 7:13 에 [email protected] 로 로그인이 안 된다는 메일을 보내 알게 됐다.

   조치

   • 디스크가 가득 차 로그 파일을 제자리에서 압축할 수 없어서, hub 파드 안에서 gzip < jupyterhub.log > /tmp/jupyterhub.log.gz 로 /tmp 에 압축했다.
   • 파드를 재시작하면 /tmp 의 압축 파일도 사라지므로 kubectl cp 로 압축 파일을 로컬에 먼저 복사했다.
   • 로그를 어떻게 할지 정할 시간을 벌려고 kubectl -n prod edit pvc hub-db-dir 로 hub 데이터베이스 디스크를 10G 에서 60G 로 늘렸다. 크기 조정에도 파드 재시작이 필요해서 로그를 복사한 뒤의 재시작 한 번으로 함께 반영했다.
   • hub 파드를 재시작했다. hub 가 더 큰 디스크로 다시 뜨면서 서비스가 돌아왔다.

   후속 조치

   • hub 로그를 hub 데이터베이스와 같은 디스크에 두지 않는다.
   • Grafana 에 JupyterHub 데이터베이스 디스크의 남은 공간을 보여 주는 그래프를 더한다.
   • 오류율이 오르면 경보를 보낸다. 이 작업은 진행 중이고 2i2c 의 4분기 목표다.

   교훈

   쿠버네티스의 동적 볼륨 크기 조정은 손을 많이 대지 않고도 바로 동작했다. 이 위험은 마이그레이션 때 이미 짚었지만 끝까지 챙기는 절차가 없었다. 2i2c 는 그 뒤로 절차가 많이 나아졌다고 적었다. 경보가 없어서 사람이 알려 줄 때까지 기다려야 했다.

   사례 보기
5. IL-0501 Azure 가 배포한 Ubuntu 18.04 업데이트로 UToronto AKS 클러스터의 모든 노드에서 네트워크가 끊겨 허브에 접속할 수 없었다

   2i2c2022

   증상

   jupyter.utoronto.ca 가 응답하지 않았고 사용자는 UToronto JupyterHub 에 아예 접속하지 못했다. 신고는 Freshdesk 티켓으로 들어왔다.

   서비스 중단노드 NotReady

   촉발

   Microsoft Azure 가 모든 Ubuntu 18.04 노드에 Ubuntu 업데이트를 자동으로 배포했고, 이 업데이트가 systemd 버그 1988119 를 드러내 노드의 네트워크를 끊었다.

   원인

   업그레이드로 깨진 호환성

   구성 요소

   노드 운영체제 이미지

   기여 요인

   디버그 접근 제한

   감지

   Freshdesk 티켓으로 jupyter.utoronto.ca 가 응답하지 않는다는 신고가 들어왔다.

   조치

   • 노드를 Azure Portal 의 VM 페이지에서 찾을 수 없어서, 재부팅 대신 클러스터의 쿠버네티스 버전과 노드 버전 업그레이드를 시작했다. 업그레이드가 옛 노드를 모두 내리고 새 노드로 바꾸면서 허브가 돌아왔다.

   후속 조치

   • 쿠버네티스 노드에 SSH 로 들어가는 방법을 문서로 남긴다.
   • Azure 공지를 알림으로 받아 볼 방법을 찾는다.

   교훈

   원인을 찾고 나서는 바로 복구할 수 있었다. 쿠버네티스 클러스터의 노드에 SSH 로 들어가는 방법이 문서로 없었다. 2i2c 는 클러스터 업그레이드를 아직 하지 않아 그 선택지가 남아 있었던 것과, 고객 쪽 담당자가 Azure 공지를 보고 알려 준 것이 운이 좋았다고 적었다.

   사례 보기

원인별4