사례2건
2건 중 1~2번째
- 증상
2026-06-11 06:16 UTC 에 Pingdom 알림이 https://gitlab.com 의 HTTP 503 오류를 알렸다. 웹, 프런트엔드, API, git, 웹소켓, web-pages, CI 러너가 06:16~06:22 UTC 와 07:03~07:12 UTC 두 차례 503 을 냈다. 오류는 여러 서비스에 걸쳐 끊겼다 이어지기를 반복했고, 매번 5~10분 안에 저절로 회복했다.
- 촉발
us-east1-b 존의 GCP 스토리지 장애로 주 데이터베이스 노드가 쓰는 디스크의 스토리지 IO 성능이 떨어졌다.
- 원인
- 구성 요소
- 기여 요인
- 감지
06:16:12 UTC 에 Pingdom 알림이 장애를 알렸다. 영향은 06:12 에 시작됐으므로 감지까지 약 4분이 걸렸다. 사용자에게 보이는 503 은 알림이 잡았지만, 먼저 나타난 신호인 디스크 IO 포화, pgBouncer 풀 포화, LWLock 경합에는 알림이 없었다.
- 조치
- 두 번째 구간이 데이터베이스와 연결 계층을 가리키자 07:11 UTC 에 데이터베이스 운영 tier2 로 장애를 에스컬레이션했다. 데이터베이스 전문가가 LWLock 경합, pg_wait_sampling_buffer_mapping 급증, 복제 지연을 깊이 진단했다.
- 배포를 멈췄다.
- 08:13 UTC 에 GCP TAM 에 연락하고 08:56 에 GCP 지원 케이스를 열었다. 클라우드 제공자가 스토리지 장애를 확인해 줬다.
- 다시 나빠지면 바로 실행할 수 있게 us-east1-d 의 04 노드로 Patroni 주 노드 전환을 준비했다. 쓰기 처리량에 줄 영향도 따져 두었지만 실행하지는 않았다.
- GCP 쪽 문제가 가라앉은 것으로 보이자 15:19 UTC 에 장애를 멈춰 두고 3시간 동안 지켜봤고, 재발이 없음을 확인한 뒤 해결로 처리했다.
- 후속 조치
- Patroni 주 데이터베이스 노드에 디스크 IO 포화와 큐 깊이 알림을 넣는다.
- 명시적인 실행 기준을 담은 Patroni 주 노드 전환 런북을 쓴다.
- 끊겼다 저절로 회복하는 장애에서 장애 상태를 언제 바꿀지 지침을 분명히 한다.
- 디스크 IO 가 떨어지는 동안 자동으로 장애 조치했어야 했는지 검토한다.
- Cells 는 장기적으로 영향 범위를 줄이도록 설계됐다. 그와 별도로 디스크 하나가 GitLab.com 전체를 멈추지 않도록 단기 완화책을 마련한다.
- 주 노드가 응답하지 않을 때 애플리케이션의 데이터베이스 부하 분산이 요청을 덜어 내거나 다른 곳으로 보내, 요청이 60초 Rack 타임아웃까지 쌓이지 않고 빨리 실패하게 한다.
- pgBouncer 풀 포화와 LWLock 경합이 전면 장애보다 먼저 튀었으므로, 이 둘을 먼저 나타나는 신호로 보고 알림을 걸지 검토한다.
- 교훈
디스크 하나가 나빠진 것만으로 GitLab.com 전체가 멈췄다. 데이터베이스 부하 분산이 빨리 실패하지 않아 요청이 60초 Rack 타임아웃까지 쌓였다. 빨리 실패하지 않는 문제는 이전 장애 #18269 에서 얻은 교훈과 겹쳤다. 장애 조치 기준이 미리 정해져 있지 않아 문제가 다시 날지 몰라 지켜보고 기다리는 데 많은 시간을 썼다. 클라우드 제공자 장애가 넓게 퍼진 상황이라 어느 존이 정상인지 미리 확인할 수도 없었다. 끊겼다 저절로 회복하는 장애에서는 장애 상태를 언제 Fixing 이나 Monitoring 으로 옮길지 정하기 어려웠다.
- 증상
2017년 1월 12일 14:09 UTC 에 한 운영 리전의 클릭·오픈 트래킹 서비스와 주 MongoDB 클러스터에서 알림이 울렸다. 대부분의 읽기를 맡는 MongoDB secondary 서버가 높은 부하 때문에 요청을 제때 처리하지 못했고, 트래킹 서비스의 오류도 여기서 왔다.
- 촉발
전날 낸 MongoDB 설정 변경 몇 건과 거의 같은 때부터 MongoDB secondary 서버로 들어오는 연결이 서서히 늘었다. 이 변경을 롤백하는 과정에서 사람의 실수로 API 와 SMTP 서비스가 읽기를 primary 로 보내게 됐다.
- 원인
- 구성 요소
- 기여 요인
- 감지
14:09 UTC 에 클릭·오픈 트래킹 서비스와 주 MongoDB 클러스터의 알림이 울려 엔지니어들이 대응을 시작했다.
- 조치
- 전날 낸 MongoDB 설정 변경을 15:15 UTC 부터 새 pull request 여러 개로 롤백했다. 이 과정에서 사람의 실수로 API 와 SMTP 서비스의 읽기를 primary 로 옮기는 변경이 함께 들어갔다.
- 더 많은 연결을 감당하도록 MongoDB 서버 크기를 키웠다.
- 근본 원인을 찾는 동안 서버를 안정시키려고 서버 단에 연결 한도를 넣었다. 서버 크기 조정과 함께 이 조치로 이 리전 API 가 평소 처리량의 약 75% 를 처리했다.
- 20:28 UTC 부터 서비스가 MongoDB primary 서버에 열 수 있는 연결 수에 한도를 두는 변경을 배포했다.
- 읽기에 secondary 서버를 우선하는 설정을 다시 배포했다. 20:35 UTC 에 이 리전 서비스가 정상으로 돌아왔다.
- 후속 조치
- 그동안 한 리전에서만 돌던 트래킹 인프라를 독립된 두 리전에서 운영한다.
- 이 데이터베이스를 쓰는 모든 서비스에 열 수 있는 연결 수의 한도를 둬서, 서비스 하나가 다른 서비스에 주는 피해를 줄인다.
- 주 MongoDB 클러스터 크기를 영구히 키우고, 같은 변경을 다른 데이터센터에도 적용한다.
- 하위 서비스가 실패해도 클릭 리디렉션은 제대로 동작하도록 트래킹 서비스를 고친다.
이 2건에서 가장 많이 나오는 구성 요소: 데이터베이스, 클라우드 블록 스토리지. kubegap 은 Claude Code 나 Codex 에서 쿠버네티스 클러스터를 읽기만 하며 이런 틈을 점검합니다. 점검 항목의 근거는 이 라이브러리와 같은 공개 보고서입니다.