사례2건

2건 중 1~2번째

1. IL-0310 Aurora PostgreSQL 의 수동 장애 조치가 스스로 되돌아가 원래 writer 가 남고 백엔드의 쓰기 쿼리가 실패했다

   Hightouch2025

   증상

   인스턴스 크기를 키우려고 Aurora 클러스터에서 장애 조치를 실행했다. 새 writer 로 올라가던 instance #2 는 잠깐 승격됐다가 곧 되돌아갔고, 원래 writer 인 instance #1 이 primary 로 남았다. AWS 콘솔에서는 클러스터가 모두 정상으로 보였지만 백엔드 서비스는 쓰기 쿼리를 실행하지 못했다.

   장애 조치 실패쓰기 거부

   촉발

   2025-10-20 us-east-1 AWS 장애 뒤 밀린 이벤트를 처리하며 작은 Postgres 인스턴스가 한계에 몰리자, Hightouch 는 10월 23일 예약된 점검 시간 없이 Aurora 인스턴스 크기를 키우는 작업을 했다. 크기를 키운 reader 를 writer 로 올리려고 16:39 EDT 에 장애 조치를 실행했다.

   원인

   소프트웨어 결함

   구성 요소

   데이터베이스데이터베이스 장애 조치 관리자

   기여 요인

   스테이징 불일치

   감지

   장애 조치를 실행한 뒤 AWS 콘솔 페이지를 새로 고치자 원래 writer 인 instance #1 이 여전히 primary 로 보였고, 백엔드 서비스가 쓰기 쿼리를 실행하지 못했다. 팀은 Datadog 에서 인스턴스마다 쿼리를 지켜보고 있었고 RDS 의 데이터베이스 로그를 받아 볼 수 있었기 때문에, writer 가 잠깐 바뀌었다가 돌아간 것을 찾아낼 수 있었다.

   조치

   • 백엔드 서비스를 재시작해 쓰기 오류를 없애고 정상 동작을 되찾았다.
   • 데이터베이스에 쓰는 서비스를 모두 스케일 다운했다.
   • 동시 쓰기가 없는 상태에서 장애 조치를 다시 실행해 성공했고, us-east-1 클러스터의 크기를 키웠다.

   후속 조치

   • 내부 플레이북에 의도한 장애 조치 전에 쓰기 서비스를 먼저 멈추는 단계를 넣었다.
   • writer 로 표시되는 인스턴스가 예상치 않게 바뀌는 것을 잡는 모니터링을 더했다.

   교훈

   믿을 만한 서비스에서 하는 마이그레이션이라도 목표 상태, 처음 상태, 그 중간 어느 상태로든 끝날 수 있다. 그러므로 트래픽을 다른 곳으로 돌리고 의존 서비스의 짧은 중단을 견딜 준비를 해 둔다. writer 가 잠깐 바뀐 일은 인스턴스별 쿼리 모니터링과 데이터베이스 로그가 있어서 찾을 수 있었다. 큰 분산 시스템에서는 구성 요소 하나가 시스템에 미치는 영향을 격리해 두면 가동 시간과 유지 보수 모두에 도움이 된다. 스테이징의 부하 시험은 운영 환경을 그대로 재현하지 못했고, 이번 레이스 컨디션을 일으킨 조건도 재현하지 못했다.

   사례 보기
2. IL-0241 데이터베이스 shard 하나가 primary 를 뽑지 못해 Stripe API 요청 대부분이 두 차례 실패했다

   Stripe2019

   증상

   2019년 7월 10일 16:35 UTC 에 데이터베이스 클러스터의 primary 노드가 고장 났고, 1분 뒤 자동 모니터링이 선출 실패를 잡아 알림을 보냈다. Stripe API 요청 대부분이 실패하기 시작했다.

   오류율 상승장애 조치 실패쓰기 거부간헐적 타임아웃노드 CPU 고부하

   촉발

   16:35 UTC 에 데이터베이스 클러스터의 primary 노드가 고장 났다. 그 shard 에는 멈춘 노드가 여럿 있어 석 달 전 마이너 버전 업그레이드로 들어온 장애 조치 결함이 드러났다. 두 번째 장애는 선출 프로토콜을 이전 마이너 버전으로 되돌린 변경 때문에 일어났다.

   원인

   소프트웨어 결함

   구성 요소

   데이터베이스데이터베이스 장애 조치 관리자

   기여 요인

   늦게 드러난 변경모니터링 사각지대과도한 영향 범위수동 조치 악화미검증 가정장애 중첩

   감지

   첫 장애는 자동 모니터링이 1분 안에 선출 실패를 잡았고, 16:36 UTC 에 팀이 알림을 받아 대응을 시작했다. 두 번째 장애는 21:14 UTC 에 클러스터의 shard 몇 개를 사용할 수 없다는 자동 알림으로 알았다.

   조치

   • 17:00 UTC 에 데이터베이스 클러스터의 모든 노드를 재시작해 새 primary 선출을 성공시켰다. 17:02 에 Stripe API 가 완전히 복구됐다.
   • 22:34 UTC 에 운영 설정을 고쳐 새로 배포하고 데이터베이스 클러스터의 노드를 재시작해 영향받은 shard 를 되살렸다.
   • 클러스터가 정상인지 확인한 뒤 사용자가 직접 보낸 API 요청에 필요한 서비스부터 트래픽을 다시 올렸다. 22:47 UTC 에 완전히 복구됐다.

   후속 조치

   • 노드가 복제 지연 지표를 보내지 않으면 알리는 모니터링을 더했다.
   • shard 가 데이터베이스 장애 조치 시스템의 이 선출 결함을 일으킬 수 있는 상태에 들어가면 알리는 모니터링을 더했다.
   • 이 결함을 고치는 수정을 데이터베이스 메인테이너와 함께 만든다.
   • 특정 클러스터로 가는 작업이 실패하면 끊어 내는 서킷 브레이커를 더 넣는다. 이번 사고의 클러스터도 대상이다.
   • shard 하나가 고장 나도 그 영향을 가두는 장애 격리 기법을 더 도입한다.
   • 실패한 요청을 거듭 재시도하는 클라이언트가 쓰는 자원을 제한한다.
   • 장애 대응 중 운영자가 설정을 빠르게 바꿀 때 더 안전하게 할 수 있도록 절차와 도구를 더 만든다.

   사례 보기

원인별1