사례2건
2건 중 1~2번째
- 증상
2025-01-15 09:55 CET 무렵부터 11:36 CET까지 데이터베이스 장애로 Magic Pages의 고객 웹사이트가 영향을 받았다. 노드 세 대로 된 MySQL 클러스터에서 내려간 노드를 다시 붙이려 하자 데이터베이스 서버가 메타데이터 정보가 없다는 모호한 오류를 냈다.
- 촉발
그날 앞서 MySQL 클러스터의 세 노드 중 하나가 내려갔고, 창업자가 그 노드를 클러스터에 다시 붙이려 했다.
- 원인
- 구성 요소
- 기여 요인
- 조치
- PVC 프로비저닝 문제를 풀려고 스토리지 서버를 재시작했다. 재시작은 몇 초 만에 끝났다.
- 스토리지가 돌아온 뒤 클러스터 메타데이터를 다시 만들 수 있도록 MySQL 노드들이 복원되고 서로 동기화되기를 약 45분 기다렸다.
- 깨진 클러스터 메타데이터를 정리했다.
- 데이터베이스 노드로 트래픽을 보내는 MySQL Router를 다시 배포했다.
- 후속 조치
- 스토리지 시스템의 상태 모니터링을 강화한다.
- MySQL Router의 장애 조치 절차를 개선한다.
- 상태 페이지가 믿을 만한 정보를 보이도록 문제를 조사하고 고친다.
- 교훈
고가용성 구성 덕분에 데이터는 잃지 않았고 첫 노드 장애도 클러스터가 문제없이 넘겼다. 하지만 중복 구성인데도 클러스터 메타데이터가 단일 장애 지점이었다. PVC 상태를 더 잘 모니터링했다면 비슷한 문제를 막을 수 있었고, 45분 걸린 복구는 더 줄일 여지가 있다. 상태 페이지는 고객 사이트 실패를 감지하도록 설정했는데도 이 장애를 바로 알아채지 못했다.
IL-0506UC Berkeley DataHub 의 JupyterHub sqlite 데이터베이스가 빈 데이터베이스로 덮어써져 로그인이 실패하고 홈 디렉터리가 비어 보이고 다른 사용자로 로그인되는 문제가 났다UC Berkeley2017- 증상
새벽 1시쯤 DataHub 에 로그인하려는 사용자가 프록시 오류를 받았다. hub 파드는 떠 있었지만 로그가 sqlite 오류로 가득했다.
- 촉발
엔지니어가 앞서 난 400 오류를 디버깅하려고 hub 파드 안에서 sqlite3 를 다시 열고, 데이터베이스를 ATTACH 하지 않은 채 .save jupyterhub.sqlite 를 실행했다. 이 명령이 JupyterHub 데이터베이스 파일을 빈 데이터베이스로 덮어썼다.
- 원인
- 구성 요소
- 기여 요인
- 감지
새벽 1시쯤 DataHub 가 다운됐다는 신고가 들어왔다. 1:12 에는 한 사용자가 로그인은 되지만 노트북이 모두 사라졌다고 알렸다.
- 조치
- hub 파드의 replicas 를 0으로 줄여 hub 를 내렸다.
- 쿠버네티스 PVC 를 사용자 id 와 다시 짝지어 JupyterHub sqlite 데이터베이스를 다시 만들었다. PVC 이름에 정리된 사용자 이름과 사용자 id 가 들어 있어서 할 수 있었다.
- 처음 넣은 가짜 cookie_id 값을 null 로 바꾸고, sqlite 파일을 DataHub 에 다시 붙였다.
- 모든 사용자를 로그아웃시키려고 hub 파드의 /srv/jupyterhub/jupyterhub_cookie_secret 을 바꿨다. 끝 근처 한 글자를 바꿨을 때는 효과가 없었고, 앞쪽 한 글자를 바꾸고 재시작하자 모두 로그아웃됐다.
- 사용자 파드를 모두 지워 모든 사용자를 확실히 로그아웃시켰다.
- 모든 사용자의 cookie_id 를 채우는 스크립트를 돌렸고, 메모리에 남은 오래된 캐시를 없애려고 hub 를 재시작한 뒤 사용자 파드를 다시 모두 지웠다.
- 이름에 '.' 이 들어간 새 사용자를 지우고, 이름에 '-' 가 있는 모든 사용자의 '-' 를 '.' 으로 바꾸는 스크립트를 돌렸다.
- 후속 조치
- JupyterHub 가 cookie secret 의 일정 길이만 쓰고 나머지를 버려서, 로그아웃시키려고 값을 바꿀 때 혼란이 생긴다는 문제를 JupyterHub 에 보고한다.
- users 테이블의 cookie_id 열에 UNIQUE 와 NOT NULL 제약을 두자고 JupyterHub 에 제안한다.
- 데이터베이스가 지워져도 파드와 PVC 이름이 그대로 남도록, 이름에 사용자 id 대신 사용자 이름 해시를 쓰는 기능을 KubeSpawner 에 요청한다.
- 사용자 테이블의 id 를 Google 인증이 주는 'id' 와 같게 두어, 처음 로그인한 때와 상관없이 사용자 id 가 바뀌지 않게 하는 기능을 OAuthenticator 에 요청한다.
- 관리형 MySQL 서비스인 Google Cloud SQL 로 옮긴다.
- 데이터베이스를 정기적으로 백업하고 그 백업을 시험한다.
- 해야 할 일과 하지 말아야 할 일을 담은 운영 FAQ 를 쓰기 시작한다.
- 모니터링과 호출 체계를 개선한다.
- 에스컬레이션 절차를 분명하게 문서로 남긴다.
이 2건에서 가장 많이 나오는 구성 요소: 데이터베이스, 영구 볼륨과 스테이트풀셋. kubegap 은 Claude Code 나 Codex 에서 쿠버네티스 클러스터를 읽기만 하며 이런 틈을 점검합니다. 점검 항목의 근거는 이 라이브러리와 같은 공개 보고서입니다.