사례3건
3건 중 1~3번째
- 증상
2026년 10월 6일 13시 30분 UTC부터 CircleCI 의 워크플로 조율 서비스가 느려져 일부 파이프라인과 잡이 이따금 조금씩 늦게 시작했다. 15시 30분부터는 지연이 계속 이어졌고 일부 잡이 실패하기 시작했다.
- 촉발
10월 6일 12시 40분쯤 데이터베이스의 가장 큰 테이블 몇 개에서 돌던 정기 유지 보수 작업인 anti-wraparound autovacuum 이 평소 작업량과 겹치면서, 데이터베이스가 트랜잭션 로그를 보관 처리하는 속도보다 빠르게 로그를 썼다.
- 원인
- 구성 요소
- 기여 요인
- 감지
10시 2분부터 모니터링이 조율 서비스의 오류 알림을 짧게 여러 번 냈지만 매번 저절로 풀렸다. 13시 35분에 여러 다른 서비스의 관련 알림과 함께 다시 울렸고, 14시 30분쯤 알림이 다시 울리자 더 조사한 뒤 14시 54분에 장애를 선언했다. 트랜잭션 로그 볼륨이 얼마나 찼는지와 보관 처리가 얼마나 밀렸는지를 보는 알림은 없었다. 상태 페이지에는 15시 58분에 공지를 올렸고 16시 20분에 주요 장애로 올렸다.
- 조치
- anti-wraparound autovacuum 이 빨리 끝나도록 설정을 바꿨다. 이 작업은 취소하면 데이터베이스가 자동으로 다시 시작하기 때문이었다.
- 트랜잭션 로그 볼륨이 거의 차자 데이터베이스가 읽기 전용이 되지 않도록 로그를 여유 공간이 많은 데이터베이스의 주 저장 볼륨으로 옮겼다. 옮기는 동안 데이터베이스가 50분 동안 내려갔다.
- 유지 보수 작업이 더 시작되지 않도록 데이터베이스 파라미터 몇 가지를 조사해 바꿨다.
- 18시 19분에 쓰기마다 저장소를 기다리는 시간을 줄이는 데이터베이스 설정을 바꿔 처리 속도를 되살렸다.
- 밀린 작업을 빨리 처리하려고 잡을 실행 플릿에 넘기는 시스템에 데이터베이스와 서버 용량을 더했다.
- 후속 조치
- 트랜잭션 로그 볼륨이 얼마나 찼는지와 보관 처리가 얼마나 밀렸는지에 알림을 건다.
- 이 두 상태를 일으키는 데이터베이스 유지 보수 작업에도 알림을 걸어 더 일찍 대응한다.
- 시끄럽거나 지나치게 민감한 알림이 실제 문제를 가리지 않도록 모든 알림을 다시 살핀다.
- 데이터베이스의 autovacuum 이 얼마나 자주, 얼마나 공격적으로 도는지를 조정한다.
- 큰 테이블들의 크기를 시간에 따라 추적해 안전한 한계 안에 두게 한다.
- 트랜잭션 로그 하나에 모든 쓰기가 몰리는 병목을 없앤다. 서비스를 각자 트랜잭션 로그를 가진 여러 데이터베이스 인스턴스로 나누는 방법과, 쓰기를 여러 노드에 나누는 분산 데이터베이스로 옮기는 방법을 검토한다.
- 다른 시스템들이 재시도 끝에 포기하지 않고 조율 서비스가 회복할 때까지 기다리도록 동작을 바꾼다.
- 긴 장애 동안 상태 페이지 공지가 구체적인 영향과 시각을 더 일찍 담도록 지침을 고친다.
- 교훈
CircleCI 는 여러 알림이 함께 울린 것을 더 일찍 알아챘어야 했다고 밝혔다. 모니터링은 느려진 것을 잡았지만 트랜잭션 로그 볼륨이 찬 정도와 보관 처리가 밀린 정도에는 알림이 없었다. 조율 서비스의 모든 쓰기가 데이터베이스 하나와 트랜잭션 로그 하나를 거치기 때문에, 그 로그가 밀리자 모든 파이프라인, 워크플로, 잡이 함께 느려졌다. 일부 잡은 다른 시스템들이 재시도 끝에 포기해서 실패했다. 고객들은 초기 상태 페이지 공지에 세부 내용이 부족했다고 알려 왔다.
- 증상
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-03-31 02:58 UTC 에 두 데이터센터의 sessionstore 서비스가 500 오류를 내기 시작했고 편집이 실패했다. 03:03 에 세션 손실을 알리는 MediaWikiEditFailures 가 critical 로 울렸고, 03:04 에 SessionStoreErrorRateHigh 가 호출을 보냈다.
- 촉발
세션 쓰기가 늘어 저장 장치를 채웠다. 쓰기가 늘어난 배경에는 세션을 높은 비율로 덮어쓰는 비정상적인 워크로드가 있었고, 이 워크로드는 SUL3 롤아웃과 시기가 강하게 겹쳤다.
- 원인
- 구성 요소
- 기여 요인
- 감지
03:04 UTC 에 SessionStoreErrorRateHigh 가 높은 5xx 비율로 울려 batphone 으로 호출이 나갔고, 그 1분 앞서 03:03 에 MediaWikiEditFailures 가 critical 로 울렸다. Cassandra 노드의 디스크 사용률이나 증가 속도에는 자동 알림이 없었다. 사용자 신고도 task T390512 로 들어왔다.
- 조치
- 03:36 UTC 에 스토리지를 지우고 Cassandra 를 재시작해 편집이 다시 들어오게 했다. 모든 세션이 사라졌고, 편집 비율은 03:40 무렵 평소 수준으로 돌아왔다.
- 후속 조치
- 디스크 사용률 추세가 비정상적으로 오르면 호출한다.
- sessionstore 의 저장 용량을 늘린다.
- sessionstore 에 네임스페이스 구분을 둔다.
- sessionstore 워크로드의 관측성을 높인다.
- sessionstore Cassandra 의 저장 공간이 빠르게 늘어난 원인을 찾는다.
- Cassandra 오류율에 호출하지 않는 알림을 둘지 검토한다.
- Cassandra 노드가 down 상태가 되면 호출이나 알림을 보낼지 검토한다.
- 교훈
노드 장애는 디스크 공간이 모자라서 났고, 그 전의 저장 증가 속도로 장애 시점을 내다볼 수 있었다. 노드가 죽기 한참 전에 높은 저장 사용률을 알렸다면 영향이 생기기 전에 막을 기회가 있었다. 5xx 비율로 호출한 것은 맞았다. 다만 Cassandra 노드가 치명적인 수만큼 죽었다는 알림이 따로 있었다면 대응하는 엔지니어에게 상황을 더 잘 알려 줬을 것이다. 지나치게 넉넉하다고 여긴 클러스터도 비정상적인 워크로드가 생기면 감당할 수 없이 빠르게 찰 수 있다. 디스크가 고갈됐을 때 스토리지를 비우는 완화책도 서비스를 흔든다. 그래도 편집이 계속 멈추는 것보다는 영향이 작다. sessionstore 쓰기 비율이 오른 데 워크로드 변화와 SUL3 마이그레이션 같은 요인이 어떻게 얽혔는지는 지금도 파악하기 어렵다.
이 3건에서 가장 많이 나오는 구성 요소: 데이터베이스, PostgreSQL vacuum. kubegap 은 Claude Code 나 Codex 에서 쿠버네티스 클러스터를 읽기만 하며 이런 틈을 점검합니다. 점검 항목의 근거는 이 라이브러리와 같은 공개 보고서입니다.
원인별2
용량 한계2건
클라우드 제공자 장애1건
- 구성 요소
- 조직