Incident Library

IL-0500 2i2c · 2022-10-31kubernetesdatabase

UToronto JupyterHub 의 데이터베이스 디스크가 가득 차서 로그인과 서버 시작이 500 오류로 실패했다

UToronto JupyterHub 는 2i2c 가 관리하는 허브 가운데 유일하게 hub 로그를 hub 데이터베이스와 같은 디스크에 두었다. 이 설정은 마이그레이션 때 예전 UToronto 설정을 그대로 옮긴 것이었고, 그 커밋 메시지도 바람직하지 않다고 적어 두었다. 2i2c 는 이렇게 둔 이유가 로깅에 Azure 를 전혀 쓰지 않는다는 점과 분석용으로 자세한 로그를 남겨 두려 한 데 있었을 것으로 봤다. 태평양 시간으로 2022년 10월 31일 오후 6:27 에 용량 10G 의 디스크가 가득 찼고, 데이터베이스 작업이 실패하면서 로그인과 서버 시작이 500 오류를 냈다.

오후 7:13 에 사용자가 지원 메일로 알렸고 오후 8:33 에 문제를 접수했다. 엔지니어는 hub 파드 안에서 로그 파일을 /tmp/jupyterhub.log.gz 로 압축해 크기를 10분의 1로 줄였다. 디스크가 가득 차 제자리에서 압축할 수 없었고, 나중에 분석에 쓸 수도 있어서 지우지 않았다. JupyterHub 프로세스가 원래 파일을 열어 두고 있어서 공간을 되찾으려면 재시작해야 했다. 그래서 압축 파일을 먼저 로컬로 복사했다. 같은 재시작에 맞춰 PVC hub-db-dir 를 10G 에서 60G 로 늘렸다. 오후 8:59 에 hub 파드를 재시작하자 서비스가 돌아왔고, 오후 10:01 에 압축 로그를 hub 디스크로 되돌려 놓았다. 영향 시간은 2시간 33분이었다.

심각도
–
영향 범위
UToronto JupyterHub: new logins and server starts failed with 500 errors; users already logged in kept working
영향 사용자
UToronto JupyterHub users who were not already logged in
지역
–
감지까지
46m
복구까지
2h 33m

증상

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

hub 파드 로그에는 [E 2022-11-01 03:39:39.905 JupyterHub base:97] Rolling back session due to database error 줄과 함께 SQLAlchemy 트레이스백이 남았고, 마지막 줄은 sqlite3.OperationalError: database or disk is full 이었다.

태평양 시간 오후 6:27 에 디스크가 가득 찼고 그 뒤로 새 로그인이 하나도 성공하지 못했다. 이 시각은 나중에 Grafana 로그에서 마지막으로 성공한 로그인을 보고 정했다. 운영팀은 오후 7:13 에 지원 메일을 받았고 오후 8:33 에 문제를 접수했다.

엔지니어는 설정을 보고 hub 로그가 hub 데이터베이스와 같은 디스크에 쌓이고 있다는 것을 알았다. 커다란 로그 파일을 지워도 JupyterHub 프로세스가 그 파일을 열어 두고 있어서 공간이 돌아오지 않았다. 공간을 되찾으려면 hub 프로세스를 재시작해야 했다.

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

원인

원인 용량 한계

구성 요소 데이터베이스영구 볼륨과 스테이트풀셋JupyterHub
기여 요인 한계 경보 부재
촉발
hub 로그가 hub 의 sqlite 데이터베이스와 같은 10G 디스크에 쌓였고, 아주 커진 로그 파일이 디스크를 다 채웠다.

감지

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

조치

후속 조치

교훈

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

출처

참고 문서

관련 사례

내 클러스터에도 있는지 확인하기

kubegap 은 Claude Code 나 Codex 에서 쿠버네티스 클러스터를 읽기만 하며 이 사례와 같은 상태를 점검합니다. 이 사례의 구성 요소: 데이터베이스, 영구 볼륨과 스테이트풀셋, JupyterHub. 점검 항목의 근거는 이 사례 같은 공개 보고서입니다.

kubegap 열기

AI 도구와 스크립트용

API 는 키가 필요 없습니다. MCP 서버는 search_incidents, get_incident, list_incidents, get_topic, vocab 도구를 내놓습니다. 사용법은 API 와 MCP.