Incident Library

IL-0322 GitLab · 2026-06-11databasegcp

GitLab.com 의 모든 주요 서비스에서 HTTP 503 오류가 두 차례 쏟아졌다가 저절로 멎었다

2026-06-11 https://gitlab.com 의 모든 주요 서비스가 06:16~06:22 UTC 와 07:03~07:12 UTC 두 차례 HTTP 503 오류를 냈다. 오류는 넓은 범위에서 끊겼다 이어지기를 반복했다. 영향은 06:12 에 시작됐다. 06:16 에 Pingdom 알림이 이를 잡았고 06:17 에 Severity 1 로 올라갔다. 두 번 모두 5~10분 안에 저절로 회복했다.

원인은 us-east1-b 존의 GCP 스토리지 장애였고, 이 장애가 주 데이터베이스 노드가 쓰는 디스크에 영향을 줬다. 디스크 IO 가 떨어지자 주 노드에서 IO 큐 깊이가 치솟고 LWLock 경합, 복제 지연, pgBouncer 연결 풀 포화가 뒤따랐다. Postgres 와 Redis 로 가는 호출이 막혀 요청이 60초 Rack 제한에 걸려 타임아웃됐다. 주 데이터베이스로 가는 트래픽은 모두 주 노드 하나를 거쳤다. 애플리케이션의 데이터베이스 부하 분산은 주 노드가 응답하지 않을 때 요청을 덜어 내거나 다른 곳으로 보내지 못했다. 그래서 요청이 빨리 실패하지 않고 Rack 타임아웃까지 쌓였다. 장애 조치는 사람이 판단해야 했고 미리 정한 기준이 없었다.

팀은 데이터베이스 운영 전문가에게 장애를 에스컬레이션하고 배포를 멈췄다. 08:13 에 주 노드의 디스크 IO 큐 깊이 급증 두 번을 찾아 GCP TAM 에 연락했고, 08:56 에 GCP 지원 케이스를 열었다. 12:15 에 클라우드 제공자 장애가 원인으로 확인됐다. 12:29 에 us-east1-d 의 04 노드로 Patroni 주 노드 전환을 준비했지만 실행하지는 않았다. 서비스는 07:25 부터 안정적이었고, 15:19 에 장애를 멈춰 두고 3시간 동안 검토해 재발이 없음을 확인한 뒤 해결로 처리했다.

심각도
sev1
영향 범위
Web, frontend, API, git, websockets, web-pages and CI runners on https://gitlab.com returned HTTP 503 errors during 06:16-06:22 and 07:03-07:12 UTC
영향 사용자
All external customers and users of https://gitlab.com
지역
GCP us-east1-b (zone of the degraded disk)
감지까지
4m
복구까지
1h

증상

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분 안에 저절로 회복했다.

요청은 60초 Rack 제한에 걸려 타임아웃됐다. Redis 와 Postgres 로 가는 네트워크 호출이 막혀 있었다. HAProxy 5xx 오류는 06:18~06:20 과 07:06~07:08 에 가장 많았다.

주 데이터베이스 인스턴스 patroni-main-v17-01-db-gprd 의 디스크 IO 큐 깊이가 06:16 에 약 219, 07:00~07:02 에 약 353 에서 405 로 치솟아 오류 구간과 겹쳤다. 같은 구간에 LWLock 경합, pg_wait_sampling_buffer_mapping, 복제 지연, sync 와 async pgBouncer 풀 포화가 함께 튀었다.

첫 번째 구간이 지난 뒤 팀은 일시적인 외부 네트워크 문제로 판단하고 06:30 에 상태를 Monitoring 으로 바꿨다. 07:03 에 두 번째 구간이 시작되고 07:10 에 sync 와 async 풀 모두에서 pgBouncer 풀 포화가 보이자 상태를 Investigating 으로 되돌리고 데이터베이스 운영 tier2 로 에스컬레이션했다. Cloudflare 데이터로 DDoS 와 느린 쿼리는 일찍 배제했고, 장애 전에 이상한 요청량도 없었다.

증상 서비스 중단간헐적 타임아웃커넥션 풀 고갈잠금 경합과 교착복제 지연

원인

원인 클라우드 제공자 장애

구성 요소 데이터베이스클라우드 블록 스토리지
기여 요인 단일 장애점한계 경보 부재런북 부재
촉발
us-east1-b 존의 GCP 스토리지 장애로 주 데이터베이스 노드가 쓰는 디스크의 스토리지 IO 성능이 떨어졌다.

감지

06:16:12 UTC 에 Pingdom 알림이 장애를 알렸다. 영향은 06:12 에 시작됐으므로 감지까지 약 4분이 걸렸다. 사용자에게 보이는 503 은 알림이 잡았지만, 먼저 나타난 신호인 디스크 IO 포화, pgBouncer 풀 포화, LWLock 경합에는 알림이 없었다.

조치

후속 조치

교훈

디스크 하나가 나빠진 것만으로 GitLab.com 전체가 멈췄다. 데이터베이스 부하 분산이 빨리 실패하지 않아 요청이 60초 Rack 타임아웃까지 쌓였다. 빨리 실패하지 않는 문제는 이전 장애 #18269 에서 얻은 교훈과 겹쳤다. 장애 조치 기준이 미리 정해져 있지 않아 문제가 다시 날지 몰라 지켜보고 기다리는 데 많은 시간을 썼다. 클라우드 제공자 장애가 넓게 퍼진 상황이라 어느 존이 정상인지 미리 확인할 수도 없었다. 끊겼다 저절로 회복하는 장애에서는 장애 상태를 언제 Fixing 이나 Monitoring 으로 옮길지 정하기 어려웠다.

출처

참고 문서

관련 사례

내 클러스터에도 있는지 확인하기

kubegap 은 Claude Code 나 Codex 에서 쿠버네티스 클러스터를 읽기만 하며 이 사례와 같은 상태를 점검합니다. 이 사례의 구성 요소: 데이터베이스, 클라우드 블록 스토리지. 점검 항목의 근거는 이 사례 같은 공개 보고서입니다.

kubegap 열기

AI 도구와 스크립트용

API 는 키가 필요 없습니다. MCP 서버는 search_incidents, get_incident, list_incidents, get_topic, vocab 도구를 내놓습니다. 사용법은 API 와 MCP.