사례8건

8건 중 5~8번째

1. IL-0488 EBS 성능 저하 뒤 Kit의 RDS MySQL 쓰기 지연이 100배 넘게 늘어 Sidekiq 작업 처리가 느려졌다

   Kit2022

   증상

   2022-12-24 오전 5시 20분 EST에 MySQL 실행 중 스레드 수가 9에서 900으로 100배 뛰었다는 첫 호출이 왔다. 크리스마스이브 새벽이라 트래픽이 아주 적은 시간이었다.

   데이터베이스 과부하처리량 저하

   촉발

   스탠바이 서버의 EBS 중단으로 RDS가 replaceSecondaryHostAndVolumesTask를 실행해 스탠바이의 호스트와 볼륨을 교체했다. 새 볼륨은 프라이머리 볼륨의 스냅숏으로 다시 만들어져 AWS가 first touch penalty라고 부른 쓰기 지연이 있었고, 동기 복제 때문에 프라이머리의 쓰기 지연이 함께 늘었다.

   원인

   클라우드 제공자 장애

   구성 요소

   데이터베이스클라우드 블록 스토리지데이터베이스 복제

   기여 요인

   초기 신호 무시

   감지

   2022-12-24 오전 5시 20분 EST에 MySQL 실행 중 스레드 수 급증 알림이 당번 엔지니어를 호출했다. 원인이 된 EBS 성능 저하는 전날 밤 AWS RSS 피드 알림으로 Slack에 들어왔지만 그때는 넘어갔다.

   조치

   • RDS 인스턴스의 스토리지를 12.5TB에서 13.75TB로 늘렸다. 이 과정에서 RDS가 optimizing storage 상태를 거치며 EBS 볼륨을 옮겼고, 쓰기 지연이 1~2ms로 돌아왔다.

   교훈

   AWS Multi-AZ는 동기 복제로 데이터 정합성과 내구성을 지키지만, 모든 트랜잭션을 스탠바이에도 커밋해야 하므로 스탠바이의 EBS 볼륨이 나빠지면 쓰기 지연도 나빠진다. 데이터베이스가 클수록 이런 일에서 회복이 오래 걸린다. 단일 AZ였다면 이번 일은 영향이 없었겠지만, 영향을 받은 가용 영역에 서버가 있었다면 몇 시간 동안 멈췄을 것이다. 운영 RDS의 배치 방식을 정할 때는 이런 득실을 따져야 한다. RDS와 EBS가 어떻게 동작하고 Kit에 어떤 영향을 주는지 이해하는 것이 중요했다.

   사례 보기
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 요청 한도에 걸리지 않게 한다.
   • 오래 이어지는 장애에 맞게 장애 대응 방식을 보강한다.

   사례 보기
3. IL-0211 Mandrill 의 PostgreSQL 샤드 하나가 트랜잭션 ID 랩어라운드를 막으려고 쓰기를 멈춰 약 40시간 동안 메일 발송이 줄었다

   Mailchimp2019

   증상

   2019년 2월 4일 05:35 UTC 부터 Mandrill 이 대기열에 쌓인 메일의 80% 만 보냈다. 첫 예외는 일요일 밤에 로그에 남았지만 다른 시스템의 관계없는 예외에 묻혀 중앙 오류 보고에서 눈에 띄지 않았다.

   쓰기 거부처리량 저하부하 불균형노드 디스크 가득 참

   촉발

   Mandrill 의 키 해시 알고리즘이 shard4 에 쓰기를 더 많이 몰아 이 샤드의 autovacuum 이 밀렸거나 실패했고, 2019년 2월 4일 05:35 UTC 에 XID 가 상한에 닿아 데이터베이스가 안전 종료 모드로 들어갔다.

   원인

   용량 한계

   구성 요소

   데이터베이스PostgreSQL vacuum

   기여 요인

   초기 신호 무시한계 경보 부재잡음에 묻힌 신호재시도 폭주모니터링 사각지대

   감지

   첫 예외는 일요일 밤에 로그에 남았지만 다른 시스템의 관계없는 예외에 묻혀 중앙 오류 보고에서 늦게 발견됐다. 11:58 UTC 에 Mandrill 엔지니어가 조사를 시작했고, shard4 의 부하 급증을 쫓다가 12:56 UTC 에 랩어라운드를 찾았다.

   조치

   • 14:16 UTC 에 shard4 를 단일 사용자 모드로 띄우고 VACUUM 을 시작했다.
   • VACUUM 이 며칠 걸릴 것으로 보여 설정을 바꿔 속도를 높인 뒤 다시 시작했다.
   • VACUUM 이 도는 동안 데이터베이스 덤프와 복원을 시작했고, 속도를 높이려고 TB 단위인 Search 와 Url 테이블을 뺐다.
   • 실패한 작업과 로그로 디스크가 모자라자 Mandrill 앱 서버들의 스토리지 볼륨을 교체했다.
   • shard4 에 있던 작업 대기열 테이블을 살아 있는 다른 샤드로 옮겨 작업이 처리되게 하려 했다.
   • 잠긴 데이터베이스에서 테이블을 비우면 그 XID 가 풀린다는 것을 확인한 뒤 2월 5일 19:12 UTC 에 Search 와 Url 테이블을 비웠고, VACUUM 이 약 한 시간 뒤에 끝났다.
   • 21:36 UTC 에 밀린 메일 발송을 시작했다.
   • 22:40 UTC 에 XID 랩어라운드 알림을 새로 걸었다.

   교훈

   Mailchimp 는 대응을 늦춘 요인으로 다섯 가지를 들었다. Mandrill 시스템과 모니터링을 알고 접근할 수 있는 사람이 몇 명뿐이었다. Mandrill 의 로그 기록은 로컬에 쓸 수 있는 디스크에 기댔다. 잘못된 API 요청 로그와 실제 애플리케이션 오류를 구분하기 어려웠다. 작업 상태가 잘 보이지 않았다. 디스크 공간 문제로 원인 분석을 돕는 부분 배포가 위험했다. 잘된 점으로는 인시던트 지휘관을 중심으로 한 긴밀한 조율, 3시간 교대와 인수인계, 기록 담당과 기술 연락 담당 같은 역할 지정, 주기적인 요약과 결정 목록을 들었다. 화상 회의로 다시 모여 상황을 따져 본 것이 테이블을 비우는 해법으로 이어졌다. 대기 메일을 48시간 뒤에 지우는 기본 동작이 다가오자 더 과감한 방법을 검토하게 됐다. Mandrill 이 클라우드에서 돌아 스토리지를 빨리 늘릴 수 있었던 것은 운이었다. 지울 수 있는 데이터가 있었고 그 가운데 VACUUM 을 붙잡던 가장 큰 테이블이 있었던 것도 운이었다.

   사례 보기
4. IL-0383 PagerDuty 알림 파이프라인이 이틀 연속 장애를 겪어 이벤트를 받지 못하고 알림이 늦거나 가지 않았다

   PagerDuty2014sev1

   증상

   6월 3일 PagerDuty 알림 파이프라인의 성능이 떨어져 일부 알림이 늦게 갔다. 통합 API 로 보낸 이벤트의 약 3% 를 받지 못했고, 1% 에 못 미치는 일부 알림이 늦게 전달됐다.

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

   촉발

   6월 3일 Cassandra 클러스터의 노드 하나에서 repair 작업이 평소대로 시작됐고, 그때 걸린 높은 부하와 겹쳤다. 6월 4일에는 팀이 전날 미룬 repair 작업을 손으로 다시 시작했다.

   원인

   용량 한계

   구성 요소

   데이터베이스

   기여 요인

   여유 용량 부재과도한 영향 범위수동 조치 악화초기 신호 무시

   조치

   • 6월 3일 Cassandra 클러스터의 부하를 줄였다.
   • 6월 3일 부하를 줄이면서 repair 작업을 멈췄다.
   • 클러스터를 안정시키려고 일부 노드 사이의 통신을 끊었고, 그 뒤 정상으로 돌아왔다.
   • 6월 4일 알림 파이프라인에서 처리 중이던 데이터를 모두 지웠고, Cassandra 가 바로 회복했다.
   • 새로 비운 상태와 데이터를 맞추도록 일부 하위 시스템을 수동으로 손봤다.

   후속 조치

   • 기존 Cassandra 노드를 더 크고 빠른 서버로 수직 확장한다. 6월 4일 이후 이 작업은 이미 끝냈다.
   • Cassandra 클러스터를 여러 개로 나누고 작업량을 그 클러스터들에 나눠 싣는다. 부하와 사용 방식에 따라 클러스터를 나누는 작업이 진행 중이다.
   • 시스템 부하 기준을 정해 그 기준에 닿으면 기존 Cassandra 클러스터를 미리 수평 확장한다.
   • 기존 클러스터와 새 클러스터를 더 최근 버전의 Cassandra 로 업그레이드한다.
   • 높은 부하에서도 Cassandra 를 통제할 수 있도록 로드 셰딩 기법을 더 넣는다.
   • Cassandra 전문 인력을 사내에 더 둔다.

   교훈

   PagerDuty 는 Cassandra 클러스터의 규모가 모자랐고, 부하와 사용 방식이 서로 다른 너무 많은 서비스가 한 클러스터를 나눠 쓰고 있었다고 밝혔다. 비슷한 문제를 보고 개선을 계획했지만 효율을 기준으로 버전 업그레이드를 먼저 하려 했고, 확장을 먼저 했어야 했다고 적었다.

   사례 보기

원인별4