사례5건
5건 중 1~5번째
- 증상
2022년 4월 11일 13:17 UTC 에 고객과 Gitpod 직원들이 워크스페이스가 간헐적으로 응답하지 않는다고 알렸다. 4월 8일과 9일에 새 세대 워크스페이스 클러스터 ws39 를 모든 리전에 배포한 직후였다.
- 촉발
2022년 4월 8일과 9일에 새 세대 워크스페이스 클러스터 ws39 를 모든 리전에 배포한 것이 시작이었다.
- 원인
- 구성 요소
- 기여 요인
- 감지
2022년 4월 11일 13:17 UTC 에 고객과 Gitpod 직원들의 신고로 알았고, incident.io 연동으로 Slack 에 장애를 열었다. 4월 12일에도 고객과 직원의 신고로 알았고, 4월 17일에는 엔지니어들이 워크스페이스 노드의 CPU 부하가 오른 것을 보고 내부 장애를 열었다.
- 조치
- IO 제한 기능이 없어 워크스페이스 시작 트래픽을 이전 세대 클러스터 ws38 로 돌렸고, 4월 11일 15:37 UTC 에 마쳤다.
- t2d 대신 더 빠른 c2d 머신 유형과 로컬 SSD 를 쓰는 새 클러스터 ws39a 를 만들어 트래픽을 옮겼다.
- Let's Encrypt 속도 제한 문제를 풀고, Let's Encrypt 에 한도를 올려 달라고 요청했다.
- ws38 클러스터를 쓸 수 없어 EU XL 트래픽을 임시로 리전 EU 클러스터로 보내 워크스페이스를 다시 시작할 수 있게 했다. 그리고 망가진 ws-eu39xl 을 대신할 ws-eu39bxl 클러스터를 새로 만들었다.
- stopping 상태에 걸린 워크스페이스를 정리해 사용자가 다시 시작할 수 있게 했다.
- 4월 8일 배포 전처럼 1TB 부트 디스크를 단 노드로 ws40 을 만들어 디스크 IO 대역폭을 늘렸다.
- 모니터링으로 노드의 작업을 직접 살펴 과도한 CPU 시간을 쓰는 워크스페이스를 찾아 시스템에서 지웠다.
- 노드를 손으로 뒤지고 채굴 탐지 시스템을 함께 써서 부정 사용자를 찾아 Gitpod 사용을 막았다.
- ws38 세대에는 없던 ws-daemon 변경을 되돌려 CPU 제한을 다시 안정시켰고, 이 수정을 ws34 클러스터에 담아 배포했다.
- 새 ws34 배포에서 워크스페이스 포트로 가는 ACME HTTP 요청을 막아 Let's Encrypt 한도에 다시 걸리지 않게 했다.
- 워크스페이스 사이에 디스크 IO 를 공정하게 나누는 ws41xl 클러스터와 일반 리전용 ws41 클러스터를 만들어 트래픽을 단계적으로 옮겼다.
- 후속 조치
- 테스트 결과가 진행하면 안 되는 배포를 미리 걸러 내도록 테스트 자동화에 계속 투자한다.
- 새 클러스터로 트래픽 비율을 옮기는 간격을 배포마다 다르게 하고, 큰 배포일수록 단계 사이를 길게 둔다.
- 워크스페이스 클러스터 배포에 위험 평가 단계를 넣어 변경 묶음의 크기와 배포 속도를 정하고, 이 단계를 자동화하는 것을 목표로 한다.
- 팀 사이 의존이 롤백을 막지 않도록 팀끼리 주는 영향을 계속 줄인다.
- PR 을 머지하기 전에 하위 호환이 깨지는 변경을 찾는 리뷰 기준을 더하고, 그런 PR 은 나눠서 배포를 롤백하기 어려운 상황을 피한다.
- 장애 완화의 첫 수단으로 롤백을 권하도록 절차를 고쳤고, 이 과정을 자동화하는 방법을 논의한다.
- 상태 페이지의 워크스페이스 서비스가 장애를 주황이나 빨강으로 제대로 표시하도록 고쳤고, 플레이북도 그에 맞게 고쳤다.
- 장애 중 내부 소통을 Slack 채널 하나와 Google Meet 하나로 모으고, 장애 절차를 그에 맞게 고쳤다.
- 당번 체계를 다시 짜서 5월 9일부터 엔지니어링 인력의 10% 가 늘 당번을 맡고, 그 시간으로 관측성과 알림과 시스템 안정성을 개선한다.
- 교훈
4월 11일에 롤백을 결정했다면 가장 좋았다. 롤백하지 않고 수정을 계속 만들어 배포하면서 고객은 필요 이상으로 오래 성능 저하를 겪었고 일부는 데이터를 잃었다. 규모가 크고 바로 앞 배포와 가까운 변경을 너무 빨리 내보냈고, 테스트 결과가 배포를 막았어야 했다. 배포 묶음을 작게 하고 배포를 자주 한다는 원칙을 ws39 에서 지키지 못했고, 팀 사이 의존이 롤백을 어렵게 만들었다. 기여 요인 가운데 일부는 막을 수 있었다.
- 증상
5.44pm UTC 쯤 Google Container Registry 에서 이미지를 받을 때 cannot get manifest 오류가 많이 났다. 약 10분 뒤 사용자들이 워크스페이스를 시작할 수 없다고 보고했고, 이미 돌던 워크스페이스는 데이터를 잃었다.
- 원인
- 구성 요소
- 기여 요인
- 감지
5.44pm UTC 쯤 팀이 GCR 에서 이미지를 받을 때 cannot get manifest 오류율이 높아진 것을 알아챘다. 약 10분 뒤 사용자들이 워크스페이스를 시작할 수 없다고 보고했고, 당번 팀이 장애 대응을 시작했다.
- 조치
- GCR 연결 문제를 조사하는 동안 예방 조치로 werft 작업을 돌려 EU 와 US 에 새 워크스페이스 클러스터를 만들기 시작했다. 만드는 데 약 20분 걸렸다.
- 새 클러스터에 문제가 없음을 확인하고 트래픽을 새 클러스터로 돌렸다. 곧 워크스페이스가 시작됐고 사용자들이 Discord 에서 시작된다고 알려 왔다.
- 후속 조치
- 노드와 클러스터가 실패해도 남는 클라우드 사업자의 영구 볼륨에 사용자 데이터를 저장한다.
- 워크스페이스가 시작할 수 없는 상태가 되어도 사용자가 파일을 내려받을 수 있게 한다. 지금은 워크스페이스가 멈춰 있을 때만 내려받을 수 있다.
- 백업 절차 개선을 우선으로 진행한다.
- DNS 서버 하나에 기대지 않고 GCP 내부 DNS, Google 의 공개 DNS 8.8.8.8, Cloudflare 의 1.1.1.1 세 곳을 쓰도록 바꿨다. 하나에 문제가 나도 나머지에 연결할 수 있다.
- DNS 복원력을 높이는 작업을 더 진행한다.
- 여러 리전의 클러스터 지원을 늘린다. 지금은 US 와 EU 두 곳뿐이고, 나중에는 여러 클라우드를 쓰는 것도 계획한다.
IL-0172AWS 도쿄 리전 한 AZ 의 냉각 장애로 쿠버네티스 위에서 돌던 CockroachDB 노드 60대 중 6대가 22분 만에 죽었고, AZ 토폴로지 설정이 없어 일부 Range 가 정족수를 잃었다.Devsisters2021- 증상
2021년 2월 19일, DB 노드 한 대가 내려갔다는 에러 알람이 슬랙에 올라왔다. CockroachDB 는 노드 일부가 죽어도 견디도록 만든 분산 데이터베이스라서 데브옵스 엔지니어들은 처음에는 크게 걱정하지 않았다.
- 촉발
AWS 도쿄 리전 데이터센터의 냉각 시스템이 고장 나 그 범위에 있던 DB 서버들이 과열로 멈췄다.
- 원인
- 구성 요소
- 기여 요인
- 감지
회식 중에 DB 노드 한 대가 내려갔다는 에러 알람이 슬랙에 올라왔고, 이어서 다른 노드들의 장애 알람이 Ops 채널에 연달아 들어왔다.
- 조치
- INSERT INTO new_table SELECT * FROM old_table WHERE {unaffected_ranges} 같은 쿼리로 깨진 Range 를 뺀 데이터를 새 테이블로 옮겼다.
- Cockroach Labs 엔지니어와 화면을 공유하며 debug unsafe-remove-dead-replicas 명령을 실행해 사라진 Data Range 2개 중 하나를 살렸다.
- 남은 Data Range 하나는 1차 장애 때와 같은 방법으로 스토리지 레이어에서 직접 복원해 유저 데이터를 잃지 않고 복구했다.
- 후속 조치
- Locality 를 설정해 데이터를 여러 AZ 에 고르게 나눠 저장했다.
- 차트 한 벌에 배포할 AZ 마다 다른 values 파일을 쓰는 방식으로 Locality 를 설정했다.
- Locality 를 설정한 노드를 기존 클러스터에 넣고 모든 AZ 에 레플리카가 복제된 것을 확인한 뒤, Locality 가 없는 기존 노드를 클러스터에서 뺐다.
- 교훈
쿠키런: 킹덤 정도 규모의 게임에서 멀티 AZ 전략은 선택이 아니라 필수다. 분산 DB 라도 레플리카가 어느 AZ 에 놓이는지 정하지 않으면, AZ 하나가 죽을 때 동시에 잃는 노드 수가 안전 마진을 넘을 수 있다. 차트를 깔끔하게 만드는 것보다 반복적이더라도 확실하게 토폴로지를 설정하는 쪽이 낫다. 클라우드 업체를 믿기보다 스스로 할 수 있는 최대한의 대비를 해 두어야 한다.
IL-0196Redis Operator 로 레플리카를 늘리면서 메모리 한도를 낮추자 데이터를 가진 유일한 Redis 파드가 재시작됐고, Sentinel 이 빈 레플리카를 마스터로 올려 데이터가 모두 지워졌다.Palark2020- 증상
RedisFailover 리소스에 바뀐 설정을 적용하자 고객 웹사이트의 가장 큰 Redis 데이터베이스에서 데이터가 모두 사라졌다. 이 데이터베이스는 TTL 없이 영속 저장소로도 쓰였고, .rdb 스냅숏이 5 Gb 를 넘었다. 서비스가 멈췄고 백업에서 데이터를 복원해야 했다.
- 촉발
RedisFailover 리소스에서 Redis 레플리카 수를 1에서 2로 늘리면서, 같은 변경으로 컨테이너의 메모리 requests 와 limits 를 22 GB 에서 19 GB 로 낮췄다.
- 원인
- 구성 요소
- 기여 요인
- 조치
- 미리 준비해 둔 백업에서 Redis 데이터를 복원했다.
- 후속 조치
- 레디니스 프로브 문제를 Redis Operator 이슈로 올렸고, 개발자들에게서 받은 수정을 시험해 통과를 확인했다.
- 상황 분석을 마친 뒤 Spotahome Redis Operator 를 계속 쓸지 다시 검토한다.
- Redis 데이터베이스를 정리하고, 불필요한 키를 만든 애플리케이션 코드를 고친다.
- Redis 의 내장 클러스터링과 샤딩을 검토한다.
- 교훈
핵심 인프라를 쿠버네티스 오퍼레이터로 관리할 때는 그 오퍼레이터가 얼마나 성숙하고 검증됐는지 따져 봐야 한다. 레플리카 수와 리소스 값을 한 번에 바꾸면 롤링 업데이트가 예상하지 못한 순서로 파드를 재시작할 수 있다. 레디니스 프로브가 ping 만 보면 복제가 끝나지 않은 빈 인스턴스도 준비됐다고 판단한다. Redis 클러스터를 바꾸기 전에는 반드시 dump.rdb 파일을 백업해야 한다.
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 를 쓰기 시작한다.
- 모니터링과 호출 체계를 개선한다.
- 에스컬레이션 절차를 분명하게 문서로 남긴다.
이 5건에서 가장 많이 나오는 구성 요소: 데이터베이스, 영구 볼륨과 스테이트풀셋. kubegap 은 Claude Code 나 Codex 에서 쿠버네티스 클러스터를 읽기만 하며 이런 틈을 점검합니다. 점검 항목의 근거는 이 라이브러리와 같은 공개 보고서입니다.