사례33건

33건 중 13~17번째

1. IL-0374 DigitalOcean 내부 서비스 디스커버리가 전 리전에서 멈춰 생성, 이벤트 처리, 제어판과 API 관리가 실패했다

   DigitalOcean2024

   증상

   2024년 8월 5일 16:30 UTC 부터 DigitalOcean 의 모든 리전에서 이벤트 처리가 실패해 Droplet 이벤트가 실패했고, 리소스 생성과 Cloud Control Panel, API 를 통한 관리가 멈췄다. Droplet 같은 기존 고객 리소스는 계속 온라인이었고 접근할 수 있었다.

   서비스 중단클러스터·노드 생성 정체

   촉발

   새 데이터센터를 더하는 데이터스토어 클러스터 롤아웃에서 잘못된 복제 설정이 배포됐다. 이 설정은 키가 하나도 없는 새 데이터센터에 데이터스토어의 모든 키 소유권 100%를 줬다.

   원인

   설정 변경

   구성 요소

   코디네이션 키-값 저장소서비스 디스커버리데이터베이스 복제

   기여 요인

   과도한 영향 범위

   감지

   16:35 UTC 에 서비스 디스커버리를 쓸 수 없다는 첫 보고가 내부에서 올라왔다. 데이터스토어 클러스터 롤아웃이 시작되고 5분 뒤였다.

   조치

   • 17:16 UTC 에 복제 설정 변경을 되돌리고, 데이터스토어 소유자가 된 리전에 되돌린 설정을 적용했다.
   • 18:25 UTC 부터 되돌린 설정을 알아채거나 적용하지 못한 리전을 찾아, 엔지니어가 그 리전의 노드에 직접 설정을 적용하고 데이터스토어 repair 를 돌렸다.
   • 남은 실패 이벤트를 정리하고, 아직 타임아웃되지 않은 대기 이벤트를 처리했다.

   후속 조치

   • 이런 확장 유지보수는 선언한 유지보수 시간 안에 하고, 고객 영향 가능성은 상태 페이지의 유지보수 공지로 알린다.
   • 이런 배포의 절차 문서를 현재 요구 사항에 맞게 고치고, 새 배포의 단계마다 할 일과 기대하는 결과를 분명하게 적는다.
   • 이번에 손으로 한 과정을 자동화해 사람의 실수 가능성을 줄인다.
   • 여러 팀이 내부 데이터스토어의 현재 토폴로지가 알맞은지, 그리고 내부 서비스 디스커버리의 가용성을 지키도록 리전 단위로 나누거나 여러 계층으로 구성할 방법이 있는지 검토한다.

   사례 보기
2. 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에 어떤 영향을 주는지 이해하는 것이 중요했다.

   사례 보기
3. IL-0308 RevenueCat 이 Aurora PostgreSQL 10 에서 14 새 클러스터로 넘어간 직후 쿼리가 극도로 느려져 대시보드와 SDK 엔드포인트가 세 시간 넘게 실패했다

   RevenueCat2022

   증상

   2022년 11월 23일 9:39 UTC 에 트래픽 전부가 새 Aurora PostgreSQL 14.x 클러스터로 넘어갔고, 지연이 나빠져 인프라 팀이 조사를 시작했다. 9:54 UTC 에는 쿼리가 평소보다 훨씬 오래 걸리면서 데이터베이스 연결을 모두 차지하고 있었다.

   데이터베이스 과부하지연 시간 증가서비스 중단커넥션 풀 고갈

   촉발

   복제를 이용해 Aurora PostgreSQL 10.x 클러스터에서 새 14.x 클러스터로 트래픽을 넘겼다. 그런데 가장 큰 테이블 하나의 vacuum 이 전환 전에 끝나지 않아, 새 클러스터의 가장 큰 테이블들에 ANALYZE 가 돌지 않은 상태였다.

   원인

   업그레이드로 깨진 호환성

   구성 요소

   데이터베이스PostgreSQL vacuum데이터베이스 복제데이터베이스 프록시와 커넥션 풀러쿼리 플래너와 테이블 통계

   기여 요인

   스테이징 불일치미검증 가정자동화 증폭모니터링 사각지대

   감지

   9:39 UTC 에 트래픽 전부가 새 클러스터로 넘어갔을 때 지연이 나빠 보였고, 인프라 팀이 바로 조사를 시작했다.

   조치

   • 9:54 UTC 에 쿼리가 데이터베이스 연결을 너무 오래 잡지 않도록 데이터베이스 사용자에 statement timeout 을 걸었다.
   • 9:58 UTC 에 로드 밸런서에서 트래픽의 90% 에 503 을 보내 부하를 덜고 시스템이 회복할 여유를 만들었다.
   • 10:00 UTC 무렵부터 오래 걸리는 쿼리에 EXPLAIN 을 돌려 보고, 해만 끼치고 필요 없는 인덱스를 지우기 시작했다.
   • 트래픽을 100% 로 되돌리는 동안 Apple 웹훅을 잠시 받지 않았다.
   • New Relic 이 느린 쿼리마다 돌리는 EXPLAIN 쿼리를 없애려고 New Relic 을 끈 새 릴리스를 냈다.
   • 12:00 UTC 무렵부터 가장 큰 테이블들에 손으로 ANALYZE 를 돌렸다.
   • 미리 준비해 둔 스크립트로 영향받은 시퀀스 값을 자동으로 올려 기본 키 중복을 풀었다.
   • 전환 몇 분 뒤 통합 이벤트 발송 작업이 이벤트 테이블을 갱신하지 못하는 것을 잡고 발송 작업을 손으로 멈췄다.
   • 발송되었지만 데이터베이스에 기록되지 않은 웹훅을 만일에 대비해 다시 보냈다.
   • 13:33 UTC 에 통합 이벤트 발송, ETL, 웹 서버 밖의 작업을 모두 되살렸다.

   후속 조치

   • 사업에 중요한 시기에는 변경 동결을 두는 것을 검토한다.
   • 백엔드 장애 때 SDK 가 얼마나 믿을 만하게 동작하는지 더 잘 알린다.
   • 개발자 대시보드와 기술 담당자에게 보내는 직접 이메일을 써서 유지보수와 장애를 고객에게 더 잘 알린다.
   • 사전 연습에서 트래픽 일부를 재생해 전환 당일과 더 비슷한 조건을 만든다. 이번 연습은 쓰기 트래픽을 재생하지 않았다.
   • API 를 빠르고 안정적으로 유지하려고 비용이 큰 작업을 최대한 비동기로 옮기는 데 더 투자한다.
   • 테이블 인덱스를 다시 검토한다. 쓰이지 않는 인덱스가 있고, 데이터베이스가 쿼리에 그 인덱스를 고르면 성능이 떨어질 수 있다.
   • 데이터베이스 대시보드에서 엔드포인트와 시스템별 부하를 더 잘 보여 줘 부하가 어디서 오는지 빨리 찾게 한다. 이번에는 Apple 웹훅 부하가 복구를 막는다는 것을 아는 데 너무 오래 걸렸다.
   • 장애 중에 고객 지원과 고객 커뮤니케이션 담당을 불러 소통을 맡긴다.

   교훈

   RevenueCat 은 처음부터 롤백했으면 더 나았다고 돌아봤다. 사전 연습에서는 데이터 일관성과 쿼리 성능만 보고 쓰기 트래픽을 재생하지 않았다. 쓰기는 인덱스가 얽히지 않아 읽기보다 단순하다고 여겼기 때문이다. 복제를 멈추고 평소처럼 쓰기를 해 봤다면 문제를 찾을 수 있었다. 시퀀스 상태가 복제되지 않는다는 한계를 놓치고 상태도 함께 복제된다고 가정했다. 사전 연습 때는 새 클러스터가 오래 떠 있어 vacuum 과 통계가 이미 끝나 있었기 때문에 ANALYZE 가 없는 문제를 보지 못했다. 시기로는 추수감사절과 블랙 프라이데이 전에 끝내려 했지만, 미국 지원팀 일부가 이미 휴가 중인 민감한 때였으므로 그다음 주로 미뤘어야 했다고 밝혔다.

   사례 보기
4. IL-0311 주 PostgreSQL 데이터베이스가 트랜잭션 ID wraparound 보호로 읽기 전용이 되어 웹사이트와 백엔드 서비스가 멈췄다

   BattleMetrics2022

   증상

   2022-03-27 3:23 UTC 에 계정, 서버, 플레이어 정보를 담는 주 PostgreSQL 데이터베이스가 쓰기를 받지 않았다. 처음 보인 증상은 사용자가 웹사이트를 불러오지 못하는 것이었다.

   쓰기 거부서비스 중단

   촉발

   플레이어 식별자 테이블의 인덱스가 알 수 없는 이유로 손상돼 vacuum 작업이 모두 오류로 끝났다. 로그로 보아 손상은 약 한 달 전인 2022-02-26 에 생긴 것으로 추정했고, 그동안 트랜잭션 ID 가 계속 쌓여 2022-03-27 에 wraparound 보호가 작동했다.

   원인

   데이터 손상

   구성 요소

   데이터베이스PostgreSQL vacuum데이터베이스 복제데이터베이스 백업과 스냅숏

   기여 요인

   모니터링 사각지대장애 중첩여유 용량 부재

   감지

   처음 들어온 것은 웹사이트를 불러오지 못한다는 사용자 신고였다. 팀은 30분쯤 전에 작동한 DDoS 방어 탓으로 보았다가, RCON 업데이트와 쿼리가 실패하는 것을 보고 더 살펴본 끝에 주 데이터베이스가 쓰기를 받지 않는 것을 찾았다.

   조치

   • 데이터베이스를 내리고 single-user mode 로 들어가 손상된 인덱스를 지운 뒤 데이터베이스를 다시 올렸다.
   • vacuum 을 다시 돌렸고, 이번에는 성공해 데이터베이스가 다시 쓰기를 받았다.
   • 지운 플레이어 식별자 인덱스를 약 두 시간에 걸쳐 다시 만들었다.
   • 데이터베이스가 돌아온 뒤 쿼리 워커를 모두 멈추고 RCON 업데이트를 우선했다.
   • 인덱스가 돌아오자 서비스가 새 Postgres primary 를 가리키게 했다.
   • replica 를 더 부트스트랩해 하나 올라올 때마다 primary 부하를 덜었고, 16:30 UTC 에 RCON 업데이트를 따라잡았다.
   • RCON 업데이트가 늦어지지 않게 쿼리를 제한해서 다시 돌렸고, 쿼리의 우선순위는 서버의 현재 접속 인원과 순위로 매겼다.

   후속 조치

   • Postgres 로그의 오류를 모니터링한다.
   • 트랜잭션 ID 를 모니터링하고 알림을 건다.
   • 물리 복제에 더해 논리 replica 를 둔다.
   • 장애에서 더 빨리 복구하도록 더 빠른 네트워크를 갖춘다.

   교훈

   BattleMetrics 는 Postgres 의 트랜잭션 ID 크기를 확인하는 헬스 체크를 두지 않은 것을 결정적인 실수로 보았다. 인덱스 손상은 사이트 성능에 영향이 없어 한 달 동안 드러나지 않았고, 그동안 vacuum 이 계속 실패하며 데이터베이스가 wraparound 에 다가갔다. 손상은 replica 에도 복제돼 있어 장애 조치가 소용없었고, 백업 서버와 내려받기용 백업도 같은 손상을 안고 있었다. 오류 문구와 달리 wraparound 보호에 들어간 서버에서도 single-user mode 없이 전체 vacuum 을 돌릴 수 있었다.

   사례 보기
5. IL-0240 인증 데이터베이스가 과부하에 걸려 Cloudflare API 와 대시보드가 6시간 33분 동안 실패하고 느려졌다

   Cloudflare2020

   증상

   14:43 UTC 에 네트워크 스위치 하나가 ping 에 응답하지 않는다는 알림이 울리기 시작했다. 장애 동안 API 쿼리 성공률이 한때 75%까지 떨어졌고, 대시보드는 평소보다 최대 80배 느려졌다.

   오류율 상승지연 시간 증가데이터베이스 과부하쓰기 거부패킷 손실

   촉발

   14:43 UTC 에 제어 플레인 데이터 센터의 네트워크 스위치 하나가 일부만 동작하는 상태에 빠졌다. LACP 와 BGP 는 계속 돌았지만 받은 패킷 일부를 전달하지 못했고, 스위치는 6분 뒤 스스로 회복했다.

   원인

   DNS·네트워크 장애

   구성 요소

   NIC·케이블·스위치 포트 링크코디네이션 키-값 저장소데이터베이스 장애 조치 관리자데이터베이스데이터베이스 복제

   기여 요인

   자동화 증폭여유 용량 부재수동 조치 악화

   감지

   14:43 UTC 에 스위치가 ping 에 응답하지 않는다는 알림이 울리기 시작했다. 그 뒤 엔지니어들이 주 인증 데이터베이스가 과부하에 걸린 것을 확인했다.

   조치

   • SSL 인증서를 엣지로 보내는 속도와 메일 발송 같은 기능을 줄여 주 인증 데이터베이스가 늘어난 부하를 감당할 여유를 만들었다.
   • 읽기 복제본으로 처리할 수 있는 API 트래픽을 손으로 보조 데이터 센터로 돌렸다. API 가용성이 크게 나아졌다.
   • 대시보드 사용자의 불편이 커지자 인증 호출을 모두 주 데이터 센터로 되돌렸고, 성능이 떨어진 상태에서도 최대한 버티도록 주 데이터베이스를 계속 손봤다.
   • 21:20 UTC 에 첫 데이터베이스 복제본이 다시 만들어지자마자 자동으로 서비스에 투입됐고, 성능이 정상으로 돌아왔다.
   • 줄였던 서비스를 모두 다시 올려 밀린 비동기 처리가 따라잡게 했고, 한동안 지켜본 뒤 장애 종료를 선언했다.

   후속 조치

   • 새 primary 를 승격하면 데이터베이스 복제본을 모두 다시 만들어야 하는 클러스터 관리 시스템의 제약을 고친다. Cloudflare 는 글을 쓸 무렵 이 결함을 이미 고쳤다고 밝혔다.
   • 트래픽을 다른 데이터 센터로 돌려야 할 때 유연하게 대응하지 못하는 사용자 세션 시스템을 다시 설계한다.
   • 자동 복구 조치의 설정 값을 다시 검토한다. 적어도 데이터베이스 하나에서는 복제본을 primary 로 승격하는 절차를 그렇게 빨리 시작하지 않도록 장애 직후 설정을 바꿨다.
   • 이 장애에 얽힌 시스템마다 자기가 의존하는 시스템의 고장을 더 잘 견디도록 계속 조정한다.

   교훈

   모든 시스템에 이중화가 있었지만, 고장 난 시스템들은 완전히 멈추지 않고 성능이 떨어진 채로 동작했다. 그래서 뒤이어 일어난 일들을 미리 모델링하고 예상하기가 훨씬 어려웠다. 1분 만에 복제본을 승격하는 자동 조치는 Cloudflare 가 자랑하던 기능이었지만, 적어도 데이터베이스 하나에서는 그 조치가 원래 문제보다 더 큰 피해를 낼 수 있었다. 대부분의 범용 클러스터 관리 시스템은 비잔틴 장애를 견디는 프로토콜을 쓰지 않고 RAFT 처럼 단순한 프로토콜을 쓴다. 드문 장애 유형에 약하다고 알려진 단순한 프로토콜이 구현과 디버깅이 어려운 복잡한 프로토콜보다 안전한 경우가 많다고 Cloudflare 는 보았다.

   사례 보기

원인별11