사례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 으로 옮길지 정하기 어려웠다.
- 증상
#production 채널에 Redis 클라이언트 오류 알림이 먼저 오고, 이어서 여러 서비스의 Error SLO 위반 알림이 잇따랐다. Sidekiq 작업을 쓰는 모든 서비스가 30분 동안 완전히 멈췄고 Web 과 API 요청에서도 500 오류가 늘었다.
- 촉발
primary 였던 redis-sidekiq-03-db-gprd 가 GCP 호스트 오류로 실패했고, 이 VM 은 리셋되어 다른 노드로 옮겨졌다.
- 원인
- 구성 요소
- 기여 요인
- 감지
#production 채널에 여러 알림이 왔다. Redis 클라이언트 오류 알림부터 시작해 Webservice & API LoadBalancer 와 Puma 를 포함한 여러 서비스의 Error SLO 위반 알림으로 번졌다.
- 조치
- primary 를 뽑을 만큼 노드가 없다는 것을 확인한 뒤 실패한 노드를 재시작했다.
- 후속 조치
- Sentinel 서비스가 꺼지면 알림을 보낸다.
- 머지 리퀘스트가 Redis Sidekiq 장애 뒤에 스스로 회복하도록 고친다.
- 교훈
꺼진 Sentinel 노드를 알림으로 잡았다면 장애 조치에 필요한 쿼럼을 만들 노드 수를 미리 확보해 이 장애를 아예 막을 수 있었다. 너무 시끄럽다는 이유로 알림을 지운 것이 꺼진 노드를 쿼럼 문제 전에 잡을 기회를 줄였을 수 있다. 복구가 몇 시간 길게 이어진 것은 머지 리퀘스트가 Redis Sidekiq 장애에서 스스로 회복하지 못했기 때문이다.
이 2건에서 가장 많이 나오는 구성 요소: 클라우드 블록 스토리지, 인메모리 캐시. kubegap 은 Claude Code 나 Codex 에서 쿠버네티스 클러스터를 읽기만 하며 이런 틈을 점검합니다. 점검 항목의 근거는 이 라이브러리와 같은 공개 보고서입니다.