사례3건
3건 중 1~3번째
- 증상
2021-01-16 23:38 UTC 부터 GitLab.com 의 오류가 급증했고 23:39 에 서비스 중단 알림이 여러 개 들어왔다. 데이터베이스 쓰기가 필요한 요청 일부가 5xx 오류를 받았다.
- 촉발
production#2648 변경을 진행하던 엔지니어가 23:36 UTC 에 모든 Patroni 노드에서 GCP 디스크 스냅샷을 동시에 시작했다. 이 스냅샷은 관련 파일시스템 변경에 앞선 안전 조치였다. 엔지니어는 스냅샷이 GCP API 로 뒤에서 처리돼 실행 중인 노드에 영향을 주지 않는다고 잘못 알고 있었다.
- 원인
- 구성 요소
- 기여 요인
- 감지
다운스트림 서비스의 영향을 알리는 알림이 한꺼번에 쏟아지면서 알아챘다. 23:38 UTC 에 오류 급증이 보였고 23:39 에 서비스 중단 알림이 여러 개 들어왔다. 감지까지 1~2분이 걸렸다.
- 조치
- 23:40 UTC 에 Patroni 가 patroni-06 의 락을 무효로 하고 장애 조치를 시작했고, 23:41 에 patroni-03 이 새 주 노드가 됐다.
- 예상보다 심한 성능 저하를 보고 세 존 가운데 두 존의 스냅샷을 취소했다.
- 후속 조치
- Patroni 와 Postgres 런북에 GCP 스냅샷의 모범 사례를 분명히 적는다.
- 변경 관리 검토자와 승인자가 쓸 점검 목록을 런북에 넣고 핸드북에서 가리킨다.
- IO 민감도 문제를 더 논의하려고 Google 과 통화 일정을 잡는다.
- 교훈
실행 중인 PG 리더 노드에서 GCP 스냅샷을 뜨지 않는다. 변경 요청 이슈 본문이 바뀌거나 내용이 더해지면, 기술 검토자는 관리자나 디렉터가 승인하기 전에 그 내용을 하나하나 검토한다. Datastores 팀은 운영 데이터베이스의 백업과 스냅샷이 어떻게 동작하는지 자세히 공유한다. 변경과 관련된 작업은 일정 초대에 잡힌 변경 시작 시각이 된 뒤에 시작한다.
- 증상
LINE Data Labs 의 로그 수집 Hadoop 클러스터에서 HA 구성의 HDFS NameNode 가 오전 9시쯤 가끔씩 failover 됐다. failover 의 직접 원인은 ZooKeeper Failover Controller 의 NameNode 헬스 체크가 60초 타임아웃에 걸린 것으로 보였다.
- 촉발
오전 9시쯤 NameNode 가 .Trash 디렉터리에 쌓인 삭제된 로그 데이터 파일을 지우는 작업을 시작했다. fs.trash.interval 이 4320 분이어서 .Trash 아래 파일은 3일 간격으로 지워지고 있었다.
- 원인
- 구성 요소
- 기여 요인
- 조치
- fs.trash.interval 을 4320 에서 1440 으로 바꿔 .Trash 디렉터리 아래 파일을 3일이 아니라 1일 간격으로 지우게 했다. .Trash 파일을 지울 때 FSNamesystem write lock 이 잡히는 시간을 줄이려는 조치였다.
- dfs.namenode.servicerpc-address.mycluster.nn1=mynamenode1:8040 과 dfs.namenode.servicerpc-address.mycluster.nn2=mynamenode2:8040 을 추가해 ZooKeeper Failover Controller 의 헬스 체크가 RPC Client Port 대신 Service RPC port 를 쓰게 했다.
- 증상
오전 8시 15분 EDT 무렵 주 MySQL 서버의 디스크 공간이 바닥나 메일 발송, API, 웹 화면이 지연됐다. 디스크 공간 알림을 알아챘을 때 MySQL 은 이미 제대로 동작하지 못하고 있었다.
- 원인
- 구성 요소
- 기여 요인
- –
- 감지
서버마다 디스크 공간을 감시해 알리는 시스템이 있었다. 이번에는 공간이 평소보다 훨씬 빨리 차서, 알림을 알아챘을 때 MySQL 은 이미 제대로 동작하지 못하고 있었다.
- 조치
- 로그를 지워 디스크 공간을 확보하려 했지만 쉽게 되지 않았다.
- 약 30분 뒤 두 번째 서버로 직접 장애 조치했고, 그 뒤 서비스가 정상으로 돌아왔다.
- 장애 조치 뒤 실패한 작업을 복구했다.
- 데이터베이스를 쓸 수 없는 동안 각 서버가 메일을 로컬 큐에 쌓아 두었다가 복구 뒤 보냈으므로 잃어버린 메일은 없었다.
- 후속 조치
- 가용성과 성능에 초점을 맞춰 클러스터를 업그레이드한다.
- 문제를 더 일찍 잡도록 알림을 조금 더 민감하게 바꾼다.
- 교훈
돌아보면 처음부터 바로 두 번째 서버로 장애 조치했어야 했다. 팀은 복제가 정상인지 먼저 확인하려다가 약 30분을 썼다.
이 3건에서 가장 많이 나오는 구성 요소: 데이터베이스 장애 조치 관리자, 데이터베이스. kubegap 은 Claude Code 나 Codex 에서 쿠버네티스 클러스터를 읽기만 하며 이런 틈을 점검합니다. 점검 항목의 근거는 이 라이브러리와 같은 공개 보고서입니다.