사례2건

2건 중 1~2번째

1. IL-0095 엔지니어가 kubectl 이 다른 클러스터를 가리키는 줄 모르고 prod 네임스페이스를 지워 LEAP JupyterHub 가 약 1시간 동안 멈췄다.

   2i2c2025

   증상

   새 temple 클러스터에 허브를 배포하던 엔지니어가 NFS 문제를 만나 prod 네임스페이스를 지웠는데 삭제가 멈춘 채 끝나지 않았다. 파드 목록을 보니 다른 클러스터의 사용자 파드가 잔뜩 있었다.

   리소스 삭제서비스 중단

   촉발

   2i2c 엔지니어가 새 허브의 NFS 배포 버그를 우회하던 중, kubectl 이 LEAP 클러스터를 가리키고 있는 줄 모르고 prod 네임스페이스를 지웠다.

   원인

   운영 실수

   구성 요소

   영구 볼륨과 스테이트풀셋잡과 크론잡인그레스 컨트롤러Terraform

   기여 요인

   파괴적 변경 보호 장치 부재런북 부재

   감지

   네임스페이스를 지운 엔지니어가 삭제가 멈춘 것을 보고 파드 목록을 확인하다 다른 클러스터의 사용자 파드를 발견했고, 17:00 BST 에 장애를 선언했다. 모니터링 알림보다 먼저였다. 업타임 검사 실패 알림은 17:32 에 왔고 사용자의 404 제보는 17:37 에 들어왔다.

   조치

   • prod 네임스페이스에 남아 있던 사용자 파드 하나를 지워 멈춰 있던 네임스페이스 삭제를 끝냈다.
   • 재배포를 막고 있던 nfs-share-creator 잡을 종료했다.
   • 바뀐 NFS 서버 IP 주소로 prod 허브를 다시 배포했다.
   • 배포 도중 사용자가 서버를 띄우지 못하게 prod 인그레스를 지웠다.

   후속 조치

   • 장애 보고서를 쓴다.
   • "I deleted prod, what next?" 같은 상황에서 바로 볼 수 있는 짧은 장애 대응 문서를 쓴다.
   • jupyterhub-home-nfs 를 업그레이드하고 nfs-share-creator 잡을 없앤다.
   • deployer 시스템에 kubeconfig 컨텍스트가 중첩되는 것을 막는 보호 장치를 넣었다. 기본으로는 꺼져 있고 쓰는 사람이 켜야 동작한다.
   • 해당 엔지니어의 셸 설정을 바꿔 kubeconfig 컨텍스트를 더 쉽게 구분하게 했다.

   교훈

   쿠버네티스 리소스를 잃는 경우에 대비해 영구 스토리지를 Terraform 으로 따로 프로비저닝해 둔 설계 덕분에 사용자 데이터가 살아남았다. 반면 엔지니어에게 지금 어느 클러스터를 다루고 있는지 알려 주는 단서가 없었던 것이 실수로 이어졌다. 복구 방법을 알고 있어도 데이터 손실 위험을 확인해 줄 사람이 다른 시간대에 있어 재배포가 늦어졌다. NFS 배포의 순환 의존과 nfs-share-creator 잡도 복구를 늦췄다.

   사례 보기
2. 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 는 그 뒤로 절차가 많이 나아졌다고 적었다. 경보가 없어서 사람이 알려 줄 때까지 기다려야 했다.

   사례 보기

원인별2