사례2건

2건 중 1~2번째

1. IL-0270 인증용 ScyllaDB 클러스터가 과부하로 조회를 처리하지 못해 Discord 에서 약 50분 동안 접속과 로그인이 되지 않았다

   Discord2023

   증상

   2023년 11월 6일 10:52 AM PST 에 업그레이드 스크립트가 scylla-authentication 클러스터의 존 c 연결을 모두 비우자, 2xx 응답 비율로 재는 Discord 의 가용성이 곧바로 약 25% 로 떨어졌다. 사용자는 접속, 로그인, 메시지 읽기와 보내기를 거의 할 수 없었다. 첫 알림은 4분쯤 뒤인 10:56 AM 에 울렸다.

   서비스 중단데이터베이스 과부하지연 시간 증가

   촉발

   2023년 11월 6일 운영체제 업그레이드 절차가 scylla-authentication 클러스터의 존 b 를 마친 뒤, 10:52 AM 에 스크립트가 존 c 의 연결을 모두 비우고 업그레이드를 시작했다. 존 b 에는 디스크 성능이 떨어진 노드가 있었다.

   원인

   용량 한계

   구성 요소

   데이터베이스

   기여 요인

   여유 용량 부재장애 중첩데워진 캐시에 기댄 구조미검증 가정초기 신호 무시재시도 폭주

   감지

   첫 알림이 장애 시작 4분쯤 뒤인 10:56 AM 에 울렸지만, 팀은 그 전에 이미 사고 대응 통화를 열고 조사하고 있었다. 하위 서비스별 소요 시간 그래프가 인증 서비스를 가리켰고, 잠시 뒤 인증 알림이 울렸다.

   조치

   • 11:05 AM 에 인증 클러스터의 부하를 덜려고 입력 중 표시 이벤트와 메시지 읽음 표시를 껐다.
   • RAID 재구축이 끝나기를 기다려 11:41 AM 에 존 c 의 두 노드를 다시 올렸다.
   • 과부하였던 존 b 의 두 노드를 한 대씩 재시작했다.

   후속 조치

   • 사고 직후 scylla-authentication 클러스터를 두 배로 늘려 용량을 더했다.
   • scylla-authentication-b-2 를 성능이 떨어지지 않은 새 디스크로 다시 만들었다.
   • 전체 지연에는 드러나지 않을 만큼 약하지만 서비스 신뢰성에 위험이 될 수 있는 디스크 성능 저하를 찾아내는 방법을 만든다.
   • Scylla 클러스터의 컨트롤 플레인을 더 자동화하고 업그레이드 작업을 그곳으로 옮겨, 캐시 적중률 같은 클러스터 분석을 업그레이드 절차에 넣는다.
   • 복제 계수를 늘리거나 다른 리전에 핫 스탠바이 클러스터를 두는 방안을 검토해, 이 작고 중요한 클러스터의 이중화를 늘린다.

   교훈

   클러스터는 존 하나를 잃어도 견디게 설계했지만, 존 하나가 내려간 상태에서 다른 존의 노드 하나 성능이 떨어진 것만으로 이 정도 장애가 났다는 것은 클러스터의 용량이 부족했다는 뜻이다. 노드 재시작 전에 캐시 적중률이 일정 수준이 돼야 하는 것도 용량 부족의 신호다. 업그레이드 전 존 중단 시험은 계속 진행해도 안전하다는 잘못된 확신을 줬다. 이 작고 중요한 클러스터는 훨씬 큰 다른 클러스터들과 다르게 운영해야 한다.

   사례 보기
2. IL-0333 사양을 낮춘 RDS PostgreSQL 인스턴스가 피크 부하를 못 버텨 헬스 체크가 실패하고 Buildkite 대시보드가 몇 시간 동안 내려갔다

   Buildkite2016

   증상

   2016년 8월 22일 17:21 UTC 부터 buildkite.com 에 아무도 로그인하지 못했고 빌드 로그와 문서도 볼 수 없었다. 빌드는 계속 돌았고 GitHub 와 Bitbucket 의 Pull Request 상태도 계속 갱신됐다.

   서비스 중단데이터베이스 과부하프로브 실패클라우드 API 호출 한도 소진

   촉발

   AWS 크레딧이 곧 떨어질 상황이라 비용을 줄이려고, 주말 유지 보수 시간에 m4.10xlarge Multi-AZ RDS PostgreSQL 데이터베이스를 r3.2xlarge 로 낮췄다. 연결 하나당 메모리를 줄이려고 중앙 pgbouncer 로도 옮겼다. 월요일 미국 피크 시간에 이 데이터베이스가 부하를 버티지 못했다.

   원인

   용량 한계

   구성 요소

   데이터베이스클라우드 로드 밸런서라이브니스·레디니스 프로브노드 런치 템플릿

   기여 요인

   미검증 가정의존성에 묶인 헬스 체크자동화 증폭순환 의존온콜 호출 미전달장애 중첩

   감지

   New Relic, Pingdom, Datadog, Calibre, CloudWatch 가 문제를 감지하면 PagerDuty 알림이 온콜 개발자에게 전화를 건다. 하지만 온콜 담당자의 PagerDuty 설정에서 "Immediately phone me" 규칙이 빠져 소리 없는 푸시 알림만 갔다. 에스컬레이션을 받을 다른 팀원들은 휴대폰을 무음으로 두어 아무도 깨지 않았다. 팀은 21:00 UTC 에 깨어 이메일, 트윗, Slack 메시지로 장애를 알았다.

   조치

   • Agent API 서버 일부를 빼서 대시보드 요청을 받는 ELB 에 연결해 buildkite.com 을 다시 올렸다. 데이터베이스가 여전히 부하에 눌려 있어 요청은 느렸다.
   • EC2 요청 한도에 걸린 뒤 Auto Scaling Group 의 헬스 체크를 EC2 헬스 체크로 바꾸고 원하는 서버 수를 고정했다.
   • AWS Console 이 여전히 문제가 있어 aws-cli 로 데이터베이스를 부하를 감당할 수 있는 인스턴스 유형으로 올렸다.
   • https://buildkite.com/_secret/version 을 참조하지 않는 새 AMI 를 만들고, 스스로 배포하는 문제를 고친 새 서버를 aws-cli 로 내보냈다.
   • 중앙 pgbouncer 서버를 없애고, 잘 동작하던 이전 구성대로 호스트마다 pgbouncer 를 다시 두었다.

   후속 조치

   • 다른 사용자에게 영향을 주지 않고 큰 인프라 변경 뒤 부하 시험을 하는 방법을 계획한다.
   • 헬스 체크가 애플리케이션에 닿기만 하면 "OK" 를 내도록 바꿨다. 이 요청에서는 더 이상 데이터베이스 연결을 확인하지 않는다.
   • 애플리케이션이 데이터베이스와 의존 서비스에 접속되는지 확인하는 헬스 체크 엔드포인트를 따로 두고 Pingdom 이 호출하게 하는 방안을 검토한다.
   • 최근 배포된 리비전을 S3 의 파일에 저장하고, 새로 뜬 서버가 스스로 배포할 때 그 파일을 참조하게 바꿨다.
   • 팀원 모두가 PagerDuty 전화가 실제로 오는지 수동으로 시험했다.
   • 모든 팀원의 설정이 맞는지 정기적으로 확인하는 회사 전체 시험을 할 수 있는지 알아본다.
   • 팀원이 온콜에 들어갈 때 PagerDuty 가 전화를 걸게 하거나, 모든 Notification Rules 에 "Immediately phone" 규칙을 두도록 요구하는 방안을 PagerDuty 에 문의한다.

   교훈

   AWS 크레딧을 미리 지켜봐야 짧은 기간에 큰 인프라 변경을 서두르지 않는다. 크레딧을 쓰는 동안 AWS Billing Reports 는 0달러 청구서를 보여 줘서 실제 비용을 알기 어렵다. 큰 인프라 변경 뒤에는 부하 시험을 해야 한다. 헬스 체크가 실제로 무엇을 확인해야 하는지 다시 생각해야 한다. 의존하는 서버에 모두 접속되는지 확인하던 헬스 체크는 ELB 의 모든 서버가 실패할 때 어떻게 되는지 고려하지 않았다. 새 서버가 배포할 리비전을 자기 서비스에 물어보는 방식은 쓰면 안 된다. 온콜에 들어가기 전에 모든 팀원의 PagerDuty 와 iPhone 설정이 맞는지 확인해야 한다. AWS 에서 서버가 계속 떴다 내려가면 헬스 체크와 오토스케일링 규칙을 멈춰 EC2 요청 한도에 걸리지 않게 해야 한다. 팀은 사후 분석을 쓰면서 AWS 에서 Auto Scaling 프로세스를 일시 중지하고 재개할 수 있다는 것을 알았다.

   사례 보기

원인별1