그래프
사례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 으로 옮길지 정하기 어려웠다.
- 증상
2025년 10월 20일 07시 6분 UTC에 모니터링 시스템이 IAD 리전, 즉 US-East 의 여러 PubNub 서비스에서 오류가 늘었다는 알림을 냈다. 일부 고객은 오류율과 지연이 오르는 것을 겪었다.
- 촉발
IAD 리전에서 클라우드 사업자인 AWS 에 광범위한 인프라 장애가 났다.
- 원인
- 구성 요소
- –
- 기여 요인
- 감지
07시 6분 UTC에 모니터링 시스템이 IAD 리전의 여러 서비스에서 오류가 늘었다는 알림을 냈다.
- 조치
- 리전 장애 조치 절차를 시작해 새 연결을 다른 리전으로 돌렸다.
- 이미 맺어진 연결을 손으로 초기화했다.
- Presence 트래픽을 EU-Central 의 Frankfurt 로 돌렸다.
- 다른 리전에 인프라를 더 띄워 옮겨 온 트래픽을 받아 냈다.
- US-West 에 두 번째 저하가 오자 US-East 리전을 다시 떼어 냈다.
- US-West 의 로드 밸런서 용량을 늘렸다.
- 사업자가 복구를 알린 뒤 US-East 의 안정을 확인하고 23시 48분까지 트래픽 재분배를 마쳤다.
- 후속 조치
- 모든 운영 서비스의 리전 장애 조치 절차를 한곳에 모아, 바로 찾아 쓸 수 있고 빠진 단계가 없게 한다.
- 새 서비스의 절차 문서에 빠진 곳을 메워, 운영에 완전히 들이기 전에 장애 조치 준비를 마친다.
- 장애 중 복구를 어렵게 한 인벤토리 도구와 DNS 이름 해석 문제를 포함해 내부 도구의 문제를 살펴 고친다.
이 2건에서 가장 많이 나오는 구성 요소: 클라우드 블록 스토리지, 데이터베이스. kubegap 은 Claude Code 나 Codex 에서 쿠버네티스 클러스터를 읽기만 하며 이런 틈을 점검합니다. 점검 항목의 근거는 이 라이브러리와 같은 공개 보고서입니다.