사례2건

2건 중 1~2번째

1. IL-0327 워크플로 데이터베이스를 blue/green 으로 업그레이드한 뒤 워크플로 시작과 취소가 지연되고 실패했다

   CircleCI2025

   증상

   blue/green 전환은 22:08 UTC 에 끝났다. 22:17 에 워크플로 서비스의 지연이 커졌고, 10분 재시도를 다 쓴 작업이 버려지며 오류가 났다. 고객은 워크플로와 작업을 시작하거나 취소할 때 지연과 실패를 겪었고 UI 에서 워크플로를 보기 어려웠다.

   지연 시간 증가오류율 상승데이터베이스 과부하

   촉발

   22:00 UTC 무렵 워크플로를 맡는 서비스의 데이터베이스를 blue/green 배포로 업그레이드했고, 22:08 에 전환이 끝났다.

   원인

   배포 결함

   구성 요소

   데이터베이스쿼리 플래너와 테이블 통계

   기여 요인

   –

   감지

   22:17 UTC 에 워크플로 서비스의 지연이 커지고 10분 재시도를 다 쓴 작업이 버려지며 오류가 나는 것을 확인했다.

   조치

   • 22:30 UTC 에 모든 워크플로 파드가 올바른 데이터베이스에 연결하도록 파드를 재시작했다.
   • 22:41 에 새 데이터베이스의 모든 쿼리가 디스크에서 읽히는 것을 보고 곧바로 데이터베이스 크기를 키우고 업무에 꼭 필요하지 않은 데이터베이스 작업을 껐다.
   • 23:00 에 통계 테이블을 다시 만드는 동안 데이터베이스가 회복할 여유를 주려고 워크플로 서비스를 파드 하나로 줄였다.
   • 23:19 에 옛 데이터베이스의 쓰기를 다시 켜고 옛 데이터베이스를 다시 주 데이터베이스로 되돌리기로 했다. 이 작업은 23:29 에 끝났다.

   후속 조치

   • blue/green 데이터베이스 배포 절차에서 메이저 버전이 바뀔 때마다 analyze 절차를 돌리도록 바꿨다.
   • 부하가 걸린 데이터베이스에서 analyze 명령을 돌려도 성능이 더 나빠지지 않는다는 것을 시험으로 확인했다. 앞으로 복구할 때 참고하도록 이 결과를 적어 둔다.
   • 다음 마이그레이션 전에 자동 테스트와 수동 확인 지점을 절차 곳곳에 더해 blue/green 전환 전에 문제를 찾아 해결한다.

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

   CircleCI2021

   증상

   2021-05-21 13:00 UTC 에 CircleCI 엔지니어가 작업 시작이 지나치게 늦어진다는 첫 호출을 받았다. Docker, Machine executor, remote Docker 작업이 늦어지거나 막혔고, 시스템이 GCP 의 CPU 쿼터에 걸려 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 에 작업 시작 지연 호출을 받고서야 본격적으로 조사를 시작했다.

   조치

   • 14:13 에 Linux machine 작업이 작업 대기열에 아예 들어오지 못하게 손으로 막았다.
   • 13:26 에 Google Cloud 에 쿼터 증설 티켓을 열었고 14:37 에 GCP 가 쿼터를 늘렸다. 시스템은 그 뒤에도 스스로 회복하지 못했다.
   • 오래된 VM 을 손으로 지우는 계획을 세우고 지우기 시작했다.
   • 17:22 에 자원을 비우고 멈춘 플랫폼을 다시 움직이려고 일부 워크플로를 취소했다.
   • 16:25 에 VM 을 지우는 대기열에 컨슈머가 없음을 확인하고 대기열과의 연결을 되살리려고 VM 서비스 배포를 리셋했다. 대기열이 빠지기 시작했다.
   • Burst Balance 가 바닥난 RDS 데이터베이스를 재부팅해도 효과가 없자 18:20 에 인스턴스를 키워 메모리와 CPU, burst balance 를 늘렸다. 데이터베이스가 돌아오는 동안 VM 프로비저닝 서비스를 줄여 연결이 몰리지 않게 했고, 19:15 에 한 번 더 키웠다.
   • VM 프로비저닝 서비스를 줄이고, vm-create 대기열을 키우던 remote-docker 작업이 실행되지 않게 막아 부하를 덜었다.
   • 21:00 에 새 VM 을 만들고 오래된 VM 을 지우는 파드를 모두 줄여 VM 을 만들고 지우지 못하는 순환을 끊었다.
   • 21:57 에 remote-docker 작업을 프로비저닝 대기열에 넣지 않는 새 분배 백엔드를 배포했고, 22:21 에 프로비저닝 시스템을 줄여 대기열이 빠질 여유를 만들었다.
   • 22:36 부터 두 시간 동안 프로비저닝과 분배 시스템의 구성 요소를 하나씩 안정성을 확인하며 다시 올렸고, 00:39 에 모두 돌아오자 완화용 코드 변경을 되돌렸다.

   후속 조치

   • VM 프로비저닝이 부하 변화에 더 잘 버티고 thundering herd 에서 회복하도록 고친다.
   • VM 프로비저닝을 분리해 그 실패가 Docker 작업에 영향을 주지 않게 한다.
   • RabbitMQ 와 운영 대기열들의 관측성을 점검하고 보강한다.
   • 요청을 묶어 보내 GCP API 요청 한도에 걸리지 않게 한다.
   • 오래 이어지는 장애에 맞게 장애 대응 방식을 보강한다.

   사례 보기

원인별2