사례10건

10건 중 6~10번째

1. IL-0229 손상된 SmartEdge 데이터 파일을 받은 bunny.net 의 전 세계 DNS 서버가 크래시를 되풀이해 플랫폼 대부분이 2시간 넘게 멈췄다.

   bunny.net2021

   증상

   2021-06-22 UTC 8:25 에 업데이트를 내보내고 몇 분 만에 전 세계에 있는 100대 가까운 bunny.net DNS 서버가 거의 모두 죽었다. bunny.net 은 트래픽의 60% 넘게 잃었고, 수백 Gbit 의 처리량이 사라졌으며, 750,000개가 넘는 웹사이트가 영향을 받았다.

   컨테이너 재시작 반복DNS 조회 실패서비스 중단요청 오라우팅부하 불균형

   촉발

   2021-06-22 UTC 8:25 에 최적화 데이터베이스의 다운로드 크기를 줄이려는 업데이트가 손상된 파일을 Edge Storage 에 올렸다. DNS 서버가 이 파일을 읽자 BinaryPack 직렬화 라이브러리가 stack overflow 예외를 일으켰고, 예외 처리를 건너뛴 채 DNS 프로세스가 종료됐다.

   원인

   배포 결함

   구성 요소

   DNS 서버와 레코드CDN 과 엣지 네트워크오브젝트 스토리지

   기여 요인

   순환 의존단일 장애점자동화 증폭롤백 무효수동 조치 악화

   감지

   팀은 무슨 일인지 알아채는 데 시간이 걸렸다. 업데이트 10분 뒤에야 DNS 서버가 다시 시작했다가 죽기를 되풀이하고 있고, 이 상태로는 되살릴 방법이 없다는 것을 알았다.

   조치

   • UTC 8:45 에 SmartEdge 시스템을 끄는 업데이트를 DNS 노드에 손으로 배포했다. 하지만 손상된 GeoDNS 데이터베이스 때문에 요청이 Madrid 로 몰렸다.
   • 9:40 무렵 임시 조치로 모든 요청을 가장 큰 리전인 Frankfurt 로 보내는 라우팅 업데이트를 준비해 DNS 서버 몇 대에 손으로 배포했다. 트래픽의 상당 부분이 돌아왔다.
   • 자체 시스템을 쓰지 않으려고 배포 시스템과 파일을 모두 외부 클라우드 스토리지 서비스로 옮겼다.
   • 10:15 에 배포 시스템과 DNS 소프트웨어를 새 스토리지에 연결하도록 바꾸고 배포했다. 10:30 에 트래픽이 돌아왔지만 잘못된 GeoDNS 데이터베이스 버전 때문에 요청은 여전히 Madrid 로 갔다.
   • 10:45 에 외부 서비스를 거쳐 데이터베이스를 동기화하고 최신 파일 세트를 배포해 서비스를 되살렸다. 11:00 에 상황이 안정되기 시작했다.

   후속 조치

   • 긴급 수정으로 BinaryPack 라이브러리를 단계적으로 걷어 낸다.
   • 앞으로 쓰는 외부 라이브러리를 더 폭넓게 시험한다.
   • 내부 API 를 외부의 독립 서비스로 완전히 옮긴다. 그 서비스가 내려가면 업데이트를 못 하지만, bunny.net 시스템이 내려가도 무너지는 인프라에 갇히지 않고 빠르게 대응할 수 있다.
   • 중요하지 않다고 본 소프트웨어 하나가 여러 클러스터에 걸친 단일 장애 지점이 되지 않게 하는 방법을 조사한다.
   • DNS 시스템이 모든 백업 데이터의 로컬 사본을 갖추고 장애를 자동으로 감지하게 해, 시스템끼리 최대한 독립시키고 장애가 연쇄로 번지지 않게 한다.

   교훈

   bunny.net 은 내부 인프라의 핵심 부분까지 모든 시스템이 서로 기대도록 설계했다. 그 때문에 손상된 파일 하나가 여러 겹의 이중화를 무너뜨리고 복구할 길까지 막았다. 자체 인프라를 자기 생태계 안에 지으면 한 곳의 장애가 연쇄로 번질 수 있다. 업데이트는 카나리 방식으로 잘게 배포하려 했지만, 중요하지 않다고 본 소프트웨어 하나가 여러 클러스터에 동시에 걸친 단일 장애 지점이 됐다. 급하게 고치는 동안 오타와 실수가 늘었고, 결국 침착하게 모든 것을 다시 확인한 뒤의 마지막 배포로 복구했다.

   사례 보기
2. IL-0220 연휴 뒤 첫 업무일에 AWS Transit Gateway 가 패킷을 버려 Slack 웹 계층이 포화되고 Slack 을 한동안 쓸 수 없었다.

   Slack2021

   증상

   미주 지역 오전에 외부 모니터링 서비스가 오류율이 조금씩 오르고 있다며 호출했다. 조사를 막 시작했을 때 사내 대시보드와 알림 서비스까지 먹통이 됐다.

   오류율 상승모니터링 중단패킷 손실서비스 중단노드 증설 실패파일 디스크립터 고갈클라우드 API 호출 한도 소진

   촉발

   연휴 동안 트래픽이 낮다가 연휴 뒤 첫 월요일에 클라이언트 캐시가 비어 평소보다 많은 데이터를 내려받으면서 트래픽이 하룻밤 새 크게 늘었다. Slack 의 VPC 들을 잇는 AWS Transit Gateway 하나가 이 증가를 따라 충분히 빨리 늘지 못해 과부하가 걸리고 패킷을 버렸다.

   원인

   클라우드 제공자 장애

   구성 요소

   트랜짓 게이트웨이와 네트워크 연결 장비자동 용량 관리 시스템

   기여 요인

   순환 의존자동화 증폭

   감지

   미주 지역 오전에 외부 모니터링 서비스가 오류율이 오르고 있다며 호출했다. 조사 초기에 대시보드와 알림 서비스가 멈춰, 그 뒤로는 내부 콘솔, 상태 페이지, 명령줄 도구, 로그와 지표 백엔드 직접 조회로 상황을 봤다. TGW 의 패킷 드롭은 AWS 내부 모니터링이 AWS 엔지니어에게 알렸다.

   조치

   • 조사를 돕고 서빙 용량을 지키려고 웹 계층의 자동 축소를 껐다.
   • 일부 대응자가 프로비저닝을 끝내지 못한 채 오토스케일링 그룹 크기 한도를 채우던 고장 난 인스턴스를 정리했다.
   • provision-service 를 고쳐 PST 오전 8시 15분쯤 다시 돌게 했고, 그때부터 정상 인스턴스가 서비스에 들어오기 시작했다.
   • AWS 엔지니어가 내부 모니터링으로 패킷 드롭을 알아채고 Slack 의 TGW 용량을 손으로 늘렸다. PST 오전 10시 40분에 모든 가용 영역에 반영되자 네트워크가 정상으로 돌아왔다.

   후속 조치

   • AWS 가 사고 후속 절차로 초당 패킷 수가 크게 늘 때의 TGW 스케일링 알고리즘을 검토한다.
   • 다음 연휴 시즌이 끝날 무렵 TGW 를 미리 증설해 달라고 요청하도록 Slack 리마인더를 걸어 둔다.
   • 대시보드 서비스 인스턴스를 데이터베이스와 같은 VPC 에서 돌려 TGW 의존을 없앤다.
   • provision-service 를 정기적으로 부하 테스트해 남은 확장 문제가 없는지 확인한다.
   • 큰 네트워크 장애 같은 극단적인 상황에서도 provision-service 가 다시 과부하되지 않도록 헬스 체크와 오토스케일링 설정을 다시 검토한다.

   교훈

   모니터링은 사용자 서비스가 정상인지 아는 수단이자 진단의 핵심 도구다. 그래서 Slack 은 모니터링 도구를 Slack 인프라에서 최대한 떼어 두려 했다. 그런데 대시보드와 알림 서비스가 백엔드 데이터베이스와 다른 VPC 에 있어 TGW 에 의존했고, 가장 필요한 순간에 함께 멈췄다. provision-service 는 예전에 부하 테스트를 했지만 이번 증설은 그때의 규모를 넘었다.

   사례 보기
3. IL-0534 US-EAST-1 의 Amazon S3 가 몇 시간 동안 요청을 처리하지 못했고 S3 에 기대는 AWS 서비스도 함께 멈췄다

   Amazon Web Services2017

   증상

   2017-02-28 오전 Northern Virginia 의 US-EAST-1 리전에서 Amazon S3 가 요청을 처리하지 못했다. GET, LIST, PUT, DELETE 요청이 모두 실패했다.

   서비스 중단

   촉발

   S3 팀원 한 명이 S3 청구 시스템이 예상보다 느린 문제를 디버깅하고 있었다. 이 팀원은 PST 오전 9:37 에 정해진 플레이북대로 청구 과정이 쓰는 하위 시스템의 서버 몇 대를 빼는 명령을 실행했다. 명령의 입력 하나가 잘못 들어가 의도보다 훨씬 많은 서버가 빠졌다.

   원인

   운영 실수

   구성 요소

   오브젝트 스토리지클라우드 블록 스토리지서버리스 함수 플랫폼

   기여 요인

   파괴적 변경 보호 장치 부재과도한 영향 범위순환 의존

   조치

   • 인덱스 하위 시스템을 먼저 재시작했다. PST 오후 12:26 에 GET, LIST, DELETE 요청을 처리할 만큼 용량이 올라왔고, 오후 1:18 에 완전히 회복했다.
   • 인덱스 하위 시스템이 동작하자 배치 하위 시스템을 회복시켰고, PST 오후 1:54 에 회복을 마쳐 S3 가 정상으로 돌아왔다.

   후속 조치

   • 용량을 빼는 도구가 용량을 더 천천히 빼도록 고쳤다.
   • 어떤 하위 시스템이든 필요한 최소 용량 밑으로 떨어지게 하는 용량 제거를 막는 안전장치를 더했다.
   • 다른 운영 도구에도 비슷한 안전 점검이 있는지 감사한다.
   • 핵심 S3 하위 시스템의 회복 시간을 줄인다. 그해 후반에 계획했던 인덱스 하위 시스템의 추가 분할 작업도 앞당겨 바로 시작한다.
   • AWS Service Health Dashboard 의 관리 콘솔이 여러 AWS 리전에서 돌도록 바꿨다.

   사례 보기
4. 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 프로세스를 일시 중지하고 재개할 수 있다는 것을 알았다.

   사례 보기
5. IL-0273 주 데이터센터의 전원이 잠깐 끊긴 뒤 Redis 클러스터가 돌아오지 않아 GitHub 가 2시간 6분 동안 HTTP 503 을 냈다

   GitHub2016

   증상

   2016년 1월 28일 00:23am UTC 에 여러 온콜 엔지니어에게 알림이 갔고, GitHub 가 HTTP 503 응답과 함께 유니콘 그림이 있는 오류 페이지를 내기 시작했다. 로드 밸런서와 프런트엔드 애플리케이션 서버 다수는 멀쩡했지만, 그 서버들이 요청을 처리하는 데 의존하는 시스템들에 닿을 수 없었다.

   서비스 중단

   촉발

   2016년 1월 28일 00:23am UTC 에 주 데이터센터에서 서버와 장비에 전원을 대는 시스템이 잠깐 끊겼고, 전체 서버의 25% 를 조금 넘는 서버와 여러 네트워크 장비가 재부팅됐다.

   원인

   의존성 장애

   구성 요소

   인메모리 캐시데이터센터 전력·냉각

   기여 요인

   미패치 알려진 버그단일 장애점자동 테스트 공백순환 의존

   감지

   서버에 닿을 수 없다는 알림과 Redis 연결 예외 급증 알림이 여러 온콜 엔지니어에게 갔다.

   조치

   • 현장 기술자와 함께 flea power 를 빼 완전히 꺼진 상태에서 서버를 다시 켜, 디스크가 다시 보이게 했다.
   • 영향받은 Redis 클러스터를 다른 하드웨어에 다시 만들기 시작했다.
   • Redis 클러스터 데이터를 대기 장비에 복원하고 Redis 서버 프로세스를 다시 올렸다.
   • 사이트 동작을 확인한 뒤 점검 페이지를 내리고 상태를 노란색으로 바꿨다.

   후속 조치

   • 전원이 다시 들어온 뒤 서버가 자기 드라이브를 보지 못하게 한 알려진 펌웨어 문제를 전체 서버에서 업데이트한다.
   • 새 펌웨어 업데이트가 나오면 도구가 팀에 이슈를 자동으로 열어, 변경 내역을 GitHub 환경과 대조해 검토하게 한다.
   • 애플리케이션 테스트에서 일부 외부 시스템이 없어도 애플리케이션 프로세스가 시작하는지 명시적으로 확인한다.
   • 백엔드 서비스가 꺼졌을 때 기능을 단계적으로 줄일 수 있도록 서킷 브레이커를 개선한다.
   • 새 서버 준비처럼 중요한 운영 작업을 맡는 내부 시스템의 가용성 요건을 사용자용 시스템과 같은 수준으로 다시 검토한다.
   • 팀 사이의 소통을 강화한다.
   • 모든 인원이 대응에 나서야 하는 상황의 에스컬레이션 방식을 미리 정해, 사고 조정자가 문서를 찾는 대신 복구를 관리하는 데 시간을 쓰게 한다.
   • 장애 동안 사용자에게 보내는 안내를 개선해, 무슨 일이 일어나는지와 다음 안내가 언제 올지 알 수 있게 한다.

   교훈

   복잡한 시스템은 구성 요소마다 의존을 이해해도 그 의존을 엄격하게 시험하지 않으면 새로운 방식으로 실패할 수 있다. 인프라의 큰 부분이 전원을 잃는 일을 완전히 막을 수는 없지만, 복구를 빠르고 믿을 만하게 하고 사용자 피해를 줄일 수는 있다. 예상하지 못한 장애에서 복구하는 데 필요한 내부 시스템은 복구 대상 시스템만큼 믿을 만해야 한다.

   사례 보기

원인별7