사례5건

5건 중 1~5번째

1. IL-0403 mybinder.org 의 prod hub 가 실제로는 넘지 않은 파드 quota 를 넘었다는 오류 때문에 새 파드를 만들지 못했다

   Binder Project2022

   증상

   2022년 6월 2일 10:00 CET 부터 mybinder.org 가 새 파드를 하나도 띄우지 못했다. 21:00 에 사용자가 Matrix 채널에 Binder 장애를 알렸고, 팀원이 살펴보니 몇 시간째 파드가 뜨지 않고 있었다.

   배포 실패서비스 중단

   원인

   소프트웨어 결함

   구성 요소

   GKE 컨트롤 플레인

   기여 요인

   모니터링 사각지대

   감지

   21:00 에 사용자가 Matrix 채널에 Binder 장애를 알렸고, 팀은 이 채널에서 소식을 받았다. 이를 본 팀원이 확인해 보니 몇 시간째 파드가 뜨지 않고 있었다. 큰 장애를 알아채기까지 11시간이 걸렸다.

   조치

   • 21:24 에 gke-resource-quotas 를 지웠고, 곧바로 배포가 파드를 다시 만들 수 있게 돼 launch 성공률이 금방 100%로 돌아왔다.

   후속 조치

   • 가동 시간 감시와 알림 문제를 이슈 https://github.com/jupyterhub/mybinder.org-deploy/issues/611 에서 다룬다.

   교훈

   Binder 에 큰 장애가 났다는 것을 알아채기까지 11시간이 걸렸다. resource quota 객체를 지우자 시스템이 아주 빨리 바로잡혔고, 지울 객체를 알고 나면 고치는 일은 비교적 간단했다. 변경할 기술과 권한을 가진 팀원이 현지 시각 밤 11시에 마침 컴퓨터 앞에 있었던 것은 운이었다.

   사례 보기
2. IL-0505 GKE 에서 kubectl logs 가 모든 파드에서 실패해 mybinder.org 사용자에게 빌드 로그가 가지 않았다

   Binder Project2019

   증상

   kubectl logs -f <pod> 가 모든 파드에서 실패했다. mybinder.org 는 파드 로그로 빌드 로그를 전달하므로 사용자가 새 빌드의 로그를 보지 못했다. 빌드 자체는 정상으로 돌았다.

   모니터링 중단배포 실패

   원인

   클라우드 제공자 장애

   구성 요소

   GKE 컨트롤 플레인쿠버네티스 API 서버

   기여 요인

   디버그 접근 제한

   조치

   • API 서버 로그가 가리킨 노드 gke-prod-a-users-b921bb88-rd5d 를 cordon 하고, 비면 풀에서 빼기로 했다.
   • rd5d 노드를 drain 해 풀에서 빼자 kubectl logs 가 돌아오고 모두 정상으로 동작했다.

   후속 조치

   • kubectl logs 가 동작하는지 시험하고 동작하지 않으면 알림을 보낸다.
   • API 서버 로그를 받는 명령을 SRE 가이드에 넣는다.
   • 의심스러운 네트워크 상태를 알아보는 방법을 SRE 가이드에 적는다.

   교훈

   kubectl logs 가 안 되고 클러스터 전체를 업그레이드하는 동안에도 실행 성공률은 97.5% 아래로 떨어지지 않았다. 문제 노드를 빼자 모두 돌아왔다. 원인이 쿠버네티스 마스터나 GKE 서비스 자체의 버그로 보여서 찾기가 아주 어려웠다. 노드를 의심했을 때 kubectl describe node gke-prod-a-users-b921bb88-rd5d 를 받아 두었으면 정상 노드와 비교할 수 있었다. 노드 주소 목록에서 ExternalIP 와 InternalIP 가 빠진 것은 이 문제의 직접 증상으로 보이고 앞으로 진단에 쓸 수 있다.

   사례 보기
3. IL-0504 mybinder.org 에서 사용자 파드가 지워지지 않고 쌓여 클러스터가 가득 차고 실행이 약 5시간 동안 실패했다

   Binder Project2018

   증상

   mybinder.org 의 실행 성공률이 0으로 떨어졌고 새 실행이 모두 실패했다. 다운타임 알림이 없어서, 문제는 4시간쯤 지나 gitter 에 이상하다는 신고가 올라온 뒤에야 알려졌다.

   서비스 중단파드 PendingAPI 조회 결과 불일치

   원인

   소프트웨어 결함

   구성 요소

   JupyterHub

   기여 요인

   한계 경보 부재

   감지

   18:30 무렵 시작된 실패를 22:48 에 gitter 에 올라온 신고로 알았다. 다운타임 알림이 아직 없었다.

   조치

   • 4시간보다 오래된 파드를 지웠다.
   • ipython-in-depth 처럼 가장 많이 쓰는 이미지의 파드는 더 공격적으로 정리했다.
   • 파드 600개쯤을 정리하고 Hub 파드를 재시작해 실행을 정상으로 돌렸다.
   • 파드가 몰려 새로 할당된 노드 몇 개를 cordon 해서 오토스케일러가 회수하게 했다.
   • 다음 날 아침 최대 수명을 넘긴 파드를 손으로 정리해 남은 노드 일부를 비웠고, 클러스터는 3개 노드로 줄었다.

   후속 조치

   • 다운타임 알림을 만든다.
   • 스케일 다운을 자동화한다.
   • 다운타임 복구 절차를 문서로 남긴다. 이번에는 잘 됐지만 팀원 모두가 그 절차를 아는 것은 아니었다.
   • pod reflector 가 실패할 때 파드를 지우지 못하는 버그를 고친다.
   • KubeSpawner 가 pod reflector 의 실패에 더 잘 견디게 한다.
   • event reflector 를 파드마다 하나씩 두지 않고 하나로 합친다. event reflector 는 KubeSpawner 의 큰 새 기능이었고 이번 실패와 관련이 있을 수 있지만 아직 분명하지 않다.
   • Hub 상태가 나빠 보이는 것을 자동으로 찾아 사람 손 없이 Hub 를 재시작하는 방법을 시도한다.

   교훈

   mybinder.org-deploy 의 scripts/delete-pods.py 스크립트로 오래된 파드를 한꺼번에 지울 수 있었고, 문제를 알고 나서는 몇 분 안에 클러스터가 정상으로 돌아왔다. KubeSpawner 의 pod reflector 가 이벤트를 받지 못해 Hub 를 재시작할 때까지 실행이 모두 실패했다. 여기에 pod reflector 가 시작을 알아채지 못한 파드를 처음부터 만들어지지 않은 것으로 보고 지우지 않는 버그가 겹쳤다. 다운타임 알림이 없어서 5시간 동안 알아채지 못했다. 클러스터 스케일 다운에는 노드를 cordon 하고 drain 하는 손 작업이 여러 단계 남아 있었다.

   사례 보기
4. IL-0402 GKE 노드가 고장 나 NodeLost 가 된 JupyterHub 파드가 hub DB 의 PVC 를 놓지 않아 mybinder.org 가 몇 시간 동안 새 사용자를 받지 못했다

   Binder Project2018

   증상

   2018년 3월 13일 07:28 CET 에 mybinder 의 launch 성공률이 몇 시간째 0인 것을 Grafana 대시보드에서 알아챘다. JupyterHub 가 새 사용자를 하나도 받지 못하고 있었다.

   서비스 중단노드 NotReady파드 Terminating 정체파드 ContainerCreating 정체

   원인

   unknown

   구성 요소

   영구 볼륨과 스테이트풀셋노드 풀

   기여 요인

   온콜 호출 미전달

   감지

   07:28 CET 에 mybinder 의 launch 성공률이 몇 시간째 0인 것을 Grafana 대시보드에서 알아챘다. Stackdriver 알림 메일은 오지 않았다. Stackdriver 메일은 스팸으로 분류되곤 했고 알림이 몇 시간 늦게 도착했다.

   조치

   • 07:33 에 상태가 나쁜 노드를 cordon 했다.
   • Unknown 상태의 hub 파드와 5시간째 ContainerCreating 이던 두 번째 hub 파드를 지워, 정상 노드에 다시 스케줄되는지 봤다.
   • GCP 웹 화면에서 노드 gke-prod-a-ssd-pool-32-134a959a-n2sk 를 손으로 reset 해 PVC 를 강제로 풀려고 했다. 08:05 에 새 hub 파드가 다른 노드에 떠 실행됐다.
   • 13:34 에 kubectl --namespace=prod delete pod <pod-name> --grace-period=0 --force 로 Unknown, NodeLost 상태 파드를 모두 강제 삭제했고, 그 파드에서 돌던 서비스들이 회복했다.

   후속 조치

   • 장애가 왜 시작됐는지 조사한다. 문제를 일으킨 파드가 있었는지, GCE 장애였는지 Stackdriver 로그와 Google Cloud 장애 공지를 살핀다.
   • Stackdriver 가 아닌 알림 서비스를 두어 이런 문제를 더 일찍 잡는다. 이 일은 지금 #365 에 막혀 있다.
   • PVC 가 풀리지 않았는지 확인하는 방법을 문서로 남겨, 다음에 이 문제를 빨리 알아볼 수 있게 한다.
   • 명령이 대부분 통하지 않을 때 노드를 손으로 재시작하는 방법을 문서로 남긴다.
   • Unknown 상태가 된 파드를 지우는 방법을 문서로 남긴다. 이 문서는 #512 에서 다룬다.

   교훈

   문제를 찾은 뒤에는 조치를 잘 기록했고, 필요에 따라 더 강한 조치로 빠르게 넘어가서 hub 가 멈춘 시간은 짧았다. 오류를 알아채기까지는 꽤 오래 걸렸다. Stackdriver 메일이 오지 않았는데, Stackdriver 메일은 스팸으로 분류되고 알림이 몇 시간 뒤에야 도착했다.

   사례 보기
5. IL-0503 GKE 노드의 메모리가 바닥나 mybinder.org 의 proxy 파드가 OOM 으로 죽고 새 서버 실행이 실패했다

   Binder Project2017

   증상

   mybinder.org 에서 새 서버를 실행하면 임시 사용자를 만들지 못했다는 오류가 떴다. 엔지니어가 마침 Grafana 를 보다가 그래프가 이상한 것을 보고 알아챘다.

   서비스 중단컨테이너 재시작 반복프로브 실패OOMKilled

   촉발

   GKE 노드 하나의 메모리가 바닥났다. 빌드에 메모리 제한이 없어서 빌드 컨테이너가 노드의 메모리를 다 썼을 가능성이 크다고 봤다.

   원인

   용량 한계

   구성 요소

   인그레스 컨트롤러컨테이너 메모리 한도JupyterHub

   기여 요인

   리소스 요청과 한도 미설정수동 조치 악화한계 경보 부재

   감지

   엔지니어가 마침 Grafana 를 보다가 그래프가 이상한 것을 보고 알아챘다.

   조치

   • 메모리가 바닥난 노드를 cordon 했다.
   • cordon 했던 노드를 다시 uncordon 했다.

   후속 조치

   • repo2docker 에서 빌드 파드가 쓸 수 있는 메모리를 제한한다.
   • jupyterhub 파드가 재시작해도 사용자 파드가 정리되지 않게 설정을 고친다.
   • 장애 대응 때 명령을 직접 실행할 사람 한 명을 정하고 터미널 공유도 고려한다. 클러스터 상태를 바꾸는 명령은 그 한 사람만 내리고, 다른 사람은 그 명령을 알고 있게 한다.
   • 클러스터에 문제가 생겼을 때 울리는 경보를 더 잘 갖춘다. 이번 장애는 jupyterhub 파드의 4xx 응답 수를 세는 경보로 잡을 수 있었다.

   사례 보기

원인별4