사례2건
2건 중 1~2번째
- 증상
2월 9일 데이터 가용성 문제일 수 있다는 첫 티켓이 들어왔다. 2월 10일 상태 페이지는 쿼리 문제를 조사 중이며 최근 데이터 일부가 쿼리 응답에 나오지 않는다고 알렸다.
- 촉발
2월 9일 아주 큰 파티션의 압축을 개선하려는 코드 변경을 prod101-us-east-1 에 배포했다.
- 원인
- 구성 요소
- 기여 요인
- 감지
2월 9일 데이터 가용성 문제일 수 있다는 첫 티켓이 들어와 조사를 시작했다. 2월 10일 티켓이 더 들어온 뒤 근본 원인을 찾았다.
- 조치
- 2월 10일 압축 변경을 롤백해 더 번지지 않게 했다.
- 최근 데이터를 클러스터의 쓰기를 모두 기록한 Kafka 로그에서 먼저 되살렸다.
- 2월 17일 과거 데이터를 더 효율적으로 복원하도록 복원 절차를 고쳤다.
- 과거 데이터를 TSM 스냅숏에서 복원했다.
- 실시간 쓰기와 쿼리를 방해하지 않도록 클러스터를 켠 채로 조금씩 복원했다.
- 후속 조치
- 압축기처럼 중요한 스토리지 구성 요소를 바꾸는 변경의 테스트 범위를 넓히고, 운영 규모의 작업량을 더 잘 반영하는 테스트 시나리오를 더한다.
- 압축 과정의 안전장치를 강화해 실패를 찾아내고 안전하게 처리하게 한다.
- 대규모 복원 중에 TTBR 이 높아지거나 쿼리가 느려질 가능성을 줄이도록 복원 작업 흐름과 운영 절차를 검토한다.
- 클러스터 전체 복원이 빨라지도록 백업과 복원 전략을 다시 본다.
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 에서 쿠버네티스 클러스터를 읽기만 하며 이런 틈을 점검합니다. 점검 항목의 근거는 이 라이브러리와 같은 공개 보고서입니다.