Incident Library

IL-0294 CircleCI · 2021-05-21databasegcpaws

CircleCI 의 VM 정리 대기열에서 컨슈머가 사라져 Docker 와 machine 작업이 12시간 가까이 늦어지거나 막혔다

CircleCI 는 2021-05-20 정기 유지보수로 RabbitMQ 를 3.8.9 에서 3.8.16 으로 올렸다. 팀은 변경 기록에서 호환되지 않는 변경을 확인했다. 변경 기록에는 메시지를 받고 ack 하지 않는 컨슈머에 기본 15분 ack 타임아웃을 거는 변경이 CircleCI 가 쓰지 않는 quorum queue 에만 해당한다고 적혀 있었다. 실제로 이 변경은 모든 큐 종류에 적용됐다. 일부 메시지가 ack 타임아웃에 걸리면서 그 컨슈머의 RabbitMQ 채널이 닫혔다. 특정 리전의 VM 을 비동기로 정리하는 대기열의 컨슈머는 이렇게 시간이 지나며 줄어 결국 0 이 됐다. 그래서 VM 이 지워지지 않았다. 이 원인은 5월 24일에야 밝혀졌다.

5월 21일 02:31 에 VM destroyer 대기열에 컨슈머가 없다는 알림을 받고 파드를 재시작해 정상으로 돌렸다. 그러나 03:10 에 다시 컨슈머가 빠지기 시작한 것은 알아채지 못했다. 10:11 의 대기열 적체 알림은 한 번만 울리고 온콜을 호출하지 않았다. 13:00 에 작업 시작 지연 호출이 왔고, 시스템은 GCP CPU 쿼터에 걸려 VM 을 띄우지 못했다. 13:23 에 장애를 선언하고 13:26 에 Google Cloud 에 쿼터 증설 티켓을 열었다. 크립토마이닝 남용을 원인으로 보고 마이닝 작업을 지웠지만 효과가 없었고, 자동 재시도가 쿼터를 바닥낸 주된 원인으로 드러났다. 14:13 에 Linux machine 작업이 작업 대기열에 들어오지 못하게 막았고, Docker executor 와 VM 서비스가 묶여 있어 Docker 작업도 느려졌다. 14:37 에 GCP 가 쿼터를 늘렸지만 시스템은 스스로 회복하지 못했다. 엔지니어는 오래된 VM 을 손으로 지우기 시작했다. 16:25 에 VM 을 지우는 대기열에 컨슈머가 없음을 확인해 VM 서비스 배포를 리셋했고, 17:22 에 일부 워크플로를 취소해 자원을 비웠다.

대기열이 빠지던 18:05 무렵 RDS 데이터베이스의 Burst Balance 가 바닥나 IO 가 크게 줄고 연결이 타임아웃됐다. 재부팅은 효과가 없었고, 18:20 에 RDS 인스턴스를 키우며 VM 프로비저닝 서비스를 줄여 연결이 몰리지 않게 했다. GP2 크레딧이 다시 바닥나자 remote-docker 작업을 막았다. 18:50 에 다시 GCP API 쿼터에 걸렸고, 19:00 에 프로비저닝 서비스를 줄였지만 burst balance 는 계속 빠르게 줄었다. 19:15 에 데이터베이스를 한 번 더 키워 19:45 에 안정됐지만 VM 프로비저닝 시간이 다시 늘었다. 시스템은 VM 을 만들고 쿼터 때문에 지우지 못하는 순환에 빠졌다. 21:00 에 엔지니어는 VM 을 만들고 지우는 파드를 모두 줄였다. 21:57 에 remote-docker 작업을 프로비저닝 대기열에 넣지 않는 새 분배 백엔드를 배포했고, 22:21 에 프로비저닝 시스템을 줄여 대기열이 빠질 여유를 만들었다. 22:36 부터 두 시간 동안 구성 요소를 하나씩 다시 올렸고, 00:39 에 모두 돌아오며 완화용 코드 변경을 되돌렸다. 장애는 5월 22일 01:18 에 해결됐다. 대응에는 EMEA 와 NA 의 인력이 참여했고 APAC 인력까지 부를 뻔했다. 이후 RabbitMQ 쪽은 이 타임아웃이 모든 큐 종류에 적용된다고 확인했고, 다음 릴리스에서 타임아웃을 늘리고 설정 문서를 보강하겠다고 답했다.

심각도
–
영향 범위
Docker, Machine executor (Windows, Mac, Arm, GPU) and remote Docker jobs delayed or blocked; macOS jobs slow
영향 사용자
CircleCI customers running these job types
지역
–
감지까지
–
복구까지
11h 48m

증상

2021-05-21 13:00 UTC 에 CircleCI 엔지니어가 작업 시작이 지나치게 늦어진다는 첫 호출을 받았다. Docker, Machine executor, remote Docker 작업이 늦어지거나 막혔고, 시스템이 GCP 의 CPU 쿼터에 걸려 VM 을 띄우지 못하고 있었다.

상태 페이지는 Machine executor 와 Remote Docker 작업이 queued 나 permanent not run 상태로 남거나 canceled 된다고 알렸다. macOS 작업은 느려질 수 있었다. 영향은 주로 Linux executor 에 있었고, Windows executor 는 간헐적으로 문제를 겪을 수 있었다. 일부 작업은 취소돼 사용자가 손으로 다시 돌려야 했고, 상태 페이지는 queued 에 멈춘 작업을 취소하고 다시 돌리라고 안내했다.

앞선 신호가 있었다. 02:31 에 VM destroyer 서비스 대기열 하나에 컨슈머가 없다는 알림이 와서 VM 서비스 Kubernetes 파드를 재시작했고 모두 정상으로 돌아왔다. 03:10 에 VM destroyer 서비스가 다시 대기열에서 컨슈머를 잃기 시작했지만 아무도 알아채지 못했다. 10:11 에 VM 을 지우는 대기열이 쌓인다는 알림이 울렸다. 그러나 이 알림은 임계값에 닿을 때 한 번만 알리고 대기열이 계속 늘어도 다시 알리지 않게 잘못 설정돼 있었고, 온콜도 호출하지 않았다.

엔지니어는 처음에 크립토마이닝 관련 플랫폼 남용이 늘어난 것을 원인으로 보고 마이닝 작업을 지우는 데 힘을 쏟았다. 고객 영향은 눈에 띄게 줄지 않았고 GCP 쿼터에 계속 걸리며 복구가 막혔다. 더 조사해 보니 자동 재시도가 GCP 쿼터를 바닥낸 주된 원인이었다.

대기열이 빠지기 시작한 뒤에는 RDS 데이터베이스가 버티지 못했다. 18:05 에 할당된 Burst Balance 를 모두 써서 IO 가 크게 줄었고 데이터베이스 연결이 타임아웃되며 끊겼다. 데이터베이스를 키운 뒤에도 GP2 크레딧이 바닥났다. 18:50 에는 다시 GCP API 쿼터에 걸렸고, 19:00 에 프로비저닝 서비스를 줄인 뒤에도 데이터베이스는 15분 만에 burst balance 의 약 30% 를 썼다.

결국 시스템은 VM 을 만들고 GCP 쿼터 때문에 지우지 못하는 순환에 빠졌고, 19:45 에 데이터베이스가 안정된 뒤에도 VM 프로비저닝 시간이 다시 늘었다.

증상 처리량 저하클라우드 API 호출 한도 소진데이터베이스 과부하

원인

원인 업그레이드로 깨진 호환성

구성 요소 메시지 브로커데이터베이스
기여 요인 늦게 드러난 변경초기 신호 무시재시도 폭주과도한 영향 범위장애 중첩
촉발
2021-05-20 08:37 UTC 에 RabbitMQ 를 3.8.9 에서 3.8.16 으로 올렸다. 3.8.15 에서 들어온 변경으로, 메시지를 받고 ack 하지 않는 컨슈머에 기본 15분 ack 타임아웃이 걸렸다. 변경 기록에는 quorum queue 에만 해당한다고 적혀 있었지만 실제로는 모든 큐 종류에 적용됐다.

감지

02:31 UTC 에 VM destroyer 서비스 대기열 하나에 컨슈머가 없다는 알림이 왔고, 파드를 재시작해 정상으로 돌렸다. 그 뒤 03:10 에 다시 컨슈머가 빠지기 시작한 것은 알아채지 못했다. 10:11 에 VM 을 지우는 대기열이 쌓인다는 알림이 울렸다. 이 알림은 임계값에 닿을 때 한 번만 알리게 잘못 설정돼 있었고 온콜을 호출하지 않았다. 엔지니어들은 13:00 에 작업 시작 지연 호출을 받고서야 본격적으로 조사를 시작했다.

조치

후속 조치

교훈

–

출처

관련 사례

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

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

kubegap 열기

AI 도구와 스크립트용

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