사례16건

16건 중 1~5번째

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-0544 Wasabi 전 리전의 S3 와 사용자 서비스에 이틀에 걸쳐 세 차례 장애가 났다

   Wasabi2024

   증상

   2024년 8월 6일 10:32 UTC 부터 Wasabi 전 리전에서 S3 와 사용자 서비스에 오류가 났다. 상태 페이지에는 10:56 UTC 에 Web Console 로그인 문제와 Wasabi 리전의 오류를 조사한다는 글이 올라왔다.

   서비스 중단장애 조치 실패간헐적 타임아웃

   촉발

   2024년 8월 6일 10:32 UTC 에 큐 서비스가 가득 찬 상태가 됐다.

   원인

   용량 한계

   구성 요소

   메시지 브로커인메모리 캐시데이터베이스

   기여 요인

   –

   조치

   • 운영팀이 데이터베이스에 남은 오래된 연결을 정리하려고 주 데이터베이스를 재시작했고, 동시에 큐 서비스의 큐를 비웠다. 이 조치로는 데이터베이스가 완전히 돌아오지 않았다.
   • 보조 데이터베이스 인스턴스를 주 인스턴스로 승격했고, 11:20 UTC 에 S3 서비스가 다시 정상이 됐다.
   • 8월 6일 13:17 UTC 부터 13:23 UTC 까지 큐 서비스 라이브러리를 데이터베이스에 완전히 반영하려고 데이터베이스를 한 번 더 재시작했다.
   • 8월 7일 두 번째 사건에서 원래의 주 데이터베이스를 다시 운영에 올려 사용자 서비스의 타임아웃을 풀었다.
   • 8월 7일 세 번째 사건에서 자동화 서비스가 보지 못하던 자동화 클러스터를 다시 만들어 배포했고, S3 서비스가 완전히 돌아왔다.

   사례 보기
3. IL-0367 Central US 의 Azure Storage 가 VM 디스크 요청을 거부해 VM 과 그 위의 SQL Database, Cosmos DB 가 멈췄다

   Microsoft Azure2024

   증상

   Central US 리전에서 VM 가용성이 떨어졌고, 그 VM 에 기대는 여러 Azure 서비스에서 연결 실패와 서비스 관리 작업 실패가 났다. 서비스 모니터링은 7월 18일 22:06 UTC 에 VM 가용성 하락을 잡았고, 22:14 UTC 에 Cosmos DB, SQL DB, SQL DB Managed Instance 의 가용성 하락을 잡았다.

   스토리지 연결 끊김서비스 중단오류율 상승장애 조치 실패오래된 엔드포인트 라우팅

   촉발

   일상적인 VM 호스트 변경에 맞춰 스토리지 허용 목록을 새로 만들 때, 목록을 만드는 서버가 네트워크 설정이 바뀐 인프라 파일 서버 일부에 접근하지 못했다. 그래서 VM 호스트 주소 범위 일부가 빠진 목록이 Central US 의 모든 스토리지 스케일 유닛에 배포됐다.

   원인

   설정 변경

   구성 요소

   클라우드 블록 스토리지데이터베이스데이터베이스 장애 조치 관리자

   기여 요인

   안전하지 않은 실패 동작단계적 배포 부재과도한 영향 범위모니터링 사각지대

   감지

   허용 목록이 Central US 에 배포되는 동안 서비스 모니터링이 VM 가용성 하락을 잡았고, 엔지니어링 팀이 투입됐다. VM 가용성 하락을 잡은 시각은 22:06 UTC 로, 고객 영향이 시작되고 26분 뒤였다. SQL 모니터링은 SQL 을 쓸 수 없게 된 지 1분 안에 비정상 노드와 로그인 실패를 잡았고, 22:14 UTC 에는 모니터링이 Cosmos DB, SQL DB, SQL DB Managed Instance 의 가용성 하락을 잡았다.

   조치

   • 원인을 확인한 뒤 허용 목록 갱신 워크플로를 전 세계에서 멈췄다.
   • 23:27 UTC 에 Central US 리전의 모든 배포를 멈췄다.
   • 23:35 UTC 에 모든 리전의 컴퓨트 증설 배포를 멈췄다.
   • Central US 리전의 모든 스토리지 스케일 유닛의 설정을 고쳐 7월 19일 02:55 UTC 에 스토리지 가용성을 되살렸다.
   • 장애 1시간 안에 자동 장애 조치 정책이 있는 SQL 데이터베이스의 장애 조치를 시작했다. geo-secondary 를 새 프라이머리로 올리고 장애 조치 그룹 엔드포인트가 새 프라이머리를 가리키게 했다.
   • SQL 게이트웨이 노드를 재시작해 캐시를 새로 고치고, 연결이 올바른 노드로 가게 했다.
   • 끝나지 않은 SQL 장애 조치를 강제로 완료했다.
   • 영향이 시작된 직후, Central US 에 쓰기 리전이 있는 다중 리전 액티브-패시브 계정을 위해 Cosmos DB 컨트롤 플레인의 장애 조치를 시작했다. 이어 고객 계정을 다른 리전으로 장애 조치했다.
   • 일부 계정에서는 고객이 Azure 포털에서 시작한 "graceful switch region" 작업이 Microsoft 가 시작한 서비스 관리 장애 조치를 막고 있었다. 이런 계정에서는 그 작업을 취소했다.
   • 일부 계정은 오래 도는 컨트롤 작업이 서비스 메타데이터에 잠금을 잡고 있어 장애 조치가 끝나지 않았다. 이런 계정은 그 잠금을 지워 장애 조치를 강제로 완료했다.
   • 장애 조치와 함께, 비정상으로 표시된 Cosmos DB 파티션을 고치는 작업을 따로 진행했다. 이 작업으로 Central US 단일 리전 계정의 가용성을 09:41 UTC 까지 99.9% 넘게 되살렸고, 19:30 UTC 쯤 모든 데이터베이스의 영향을 완화했다.
   • 08:51 UTC 부터는 백엔드 노드 수리가 진행되는 대로, Microsoft 가 장애 조치했던 Cosmos DB 계정을 Central US 로 되돌렸다. Central US 를 먼저 읽기 리전으로 추가했고, 쓰기 리전을 다시 Central US 로 옮길지는 고객이 정하게 했다.

   후속 조치

   • 허용 목록을 만드는 워크플로가 원본 정보가 빠진 것을 알아채면 멈추게 고친다.
   • 스토리지 요청이 허용 목록 검사에서 거부되면 알림을 보낸다.
   • 허용 목록 배포를 가용 영역과 스토리지 종류에 따라 차례로 진행하고, 배포 기간을 24시간으로 늘린다.
   • 허용 목록 배포 워크플로에 VM 상태 확인을 더하고, 이상이 보이면 배포를 자동으로 멈춘다.
   • Microsoft 가 SQL 장애 조치 그룹의 장애 조치를 시작하는 정책을 다시 검토하고, 고객이 장애 조치를 직접 관리하라는 권고를 다시 알린다.
   • Cosmos DB 페일백 워크플로를 고친다. 이 워크플로 때문에 MongoDB API 계정 일부에서 특정 버전의 MongoDB 드라이버가 모든 리전에 연결하지 못했다.
   • 프라이빗 엔드포인트가 있는 Cosmos DB 계정이 페일백 뒤 Central US 에 연결하지 못하던 문제를 고쳐, Microsoft 가 페일백을 다시 하지 않아도 되게 한다.
   • 스토리지 데이터 플레인 방화벽이 잘못된 허용 목록 배포를 알아채고 마지막으로 정상이던 상태를 계속 쓰게 한다.
   • Azure NetApp Files 의 여러 모니터 로직을 고쳐 영향을 주는 이벤트를 제때 잡고 알맞게 분류하게 한다.
   • Azure NetApp Files 의 여러 서비스 지표를 더 모니터링해 비슷한 문제를 잡고 관련 이벤트를 더 빨리 서로 연결해 보게 한다.
   • SQL 이 쓰는 Service Fabric 클러스터 위치 변경 알림 메커니즘이 부하가 클 때도 믿을 만하게 동작하게 한다.
   • SQL 지역 장애 조치 워크플로를 견고하게 만들어 장애 조치가 끝까지 완료되게 한다.
   • Cosmos DB 장애 조치의 5%를 늦춘 문제를 없앤다.
   • Azure DevOps 의 모든 고객 메타데이터를 알맞은 지리 영역으로 옮겨, 한 장애가 여러 지리 영역에 걸쳐 영향을 주지 않게 한다.
   • Azure NetApp Files 의 리전 사이 읽기와 쓰기를 분리해, 이런 종류의 문제가 한 리전 안에서 끝나게 한다.
   • Azure NetApp Files 가 저장소에 둔 사용률 데이터에 덜 기대도록 캐시를 쓰는 방안을 검토한다.
   • Cosmos DB 다중 리전 액티브-패시브 계정에 파티션 단위 자동 장애 조치를 넣어, 영향받은 파티션을 자동으로 처리하게 한다.
   • SQL 과 Cosmos DB 를 위해 Azure Virtual Machines 가 Resilient Ephemeral OS disk 개선을 진행해, 스토리지 장애에도 VM 이 더 잘 버티게 한다.

   사례 보기
4. IL-0291 GitLab.com 의 redis-sidekiq Sentinel 이 쿼럼을 만들지 못해 Sidekiq 이 30분 동안 멈추고 500 오류가 늘었다

   GitLab2023

   증상

   #production 채널에 Redis 클라이언트 오류 알림이 먼저 오고, 이어서 여러 서비스의 Error SLO 위반 알림이 잇따랐다. Sidekiq 작업을 쓰는 모든 서비스가 30분 동안 완전히 멈췄고 Web 과 API 요청에서도 500 오류가 늘었다.

   장애 조치 실패오류율 상승

   촉발

   primary 였던 redis-sidekiq-03-db-gprd 가 GCP 호스트 오류로 실패했고, 이 VM 은 리셋되어 다른 노드로 옮겨졌다.

   원인

   클라우드 제공자 장애

   구성 요소

   인메모리 캐시데이터베이스 장애 조치 관리자

   기여 요인

   단일 장애점모니터링 사각지대

   감지

   #production 채널에 여러 알림이 왔다. Redis 클라이언트 오류 알림부터 시작해 Webservice & API LoadBalancer 와 Puma 를 포함한 여러 서비스의 Error SLO 위반 알림으로 번졌다.

   조치

   • primary 를 뽑을 만큼 노드가 없다는 것을 확인한 뒤 실패한 노드를 재시작했다.

   후속 조치

   • Sentinel 서비스가 꺼지면 알림을 보낸다.
   • 머지 리퀘스트가 Redis Sidekiq 장애 뒤에 스스로 회복하도록 고친다.

   교훈

   꺼진 Sentinel 노드를 알림으로 잡았다면 장애 조치에 필요한 쿼럼을 만들 노드 수를 미리 확보해 이 장애를 아예 막을 수 있었다. 너무 시끄럽다는 이유로 알림을 지운 것이 꺼진 노드를 쿼럼 문제 전에 잡을 기회를 줄였을 수 있다. 복구가 몇 시간 길게 이어진 것은 머지 리퀘스트가 Redis Sidekiq 장애에서 스스로 회복하지 못했기 때문이다.

   사례 보기
5. IL-0302 GitHub 의 공용 MySQL 클러스터 mysql1 이 최대 부하 시간대에 연결이 바닥나 쓰기 작업이 네 번 멈췄다

   GitHub2022

   증상

   2022년 3월 16일 14:09 UTC, 최대 부하 시간대에 mysql1 데이터베이스의 부하가 늘면서 데이터베이스 프록시가 최대 연결 수에 닿았다. GitHub 의 모든 쓰기 작업이 동작하지 않았다.

   쓰기 거부데이터베이스 과부하오류율 상승장애 조치 실패

   촉발

   최대 부하 시간대에 공용 MySQL 클러스터 mysql1 의 부하가 늘어 데이터베이스 프록시가 최대 연결 수에 닿았다.

   원인

   용량 한계

   구성 요소

   데이터베이스데이터베이스 프록시와 커넥션 풀러

   기여 요인

   비효율적인 쿼리피크 시간 변경수동 조치 악화과도한 영향 범위

   조치

   • 정상인 복제본으로 페일오버해 3월 16일 장애에서 복구했다.
   • 3월 17일 미리 한 페일오버 뒤 새 주 노드에 생긴 연결 문제를 풀려고 연결을 재설정했다.
   • 3월 17일 장애 중에 부하 패턴을 찾아 인덱스를 추가해 주된 성능 문제를 고쳤다.
   • 3월 22일 클라이언트 연결이 실패하자 다시 주 노드를 페일오버해 복구했다.
   • 3월 23일 같은 부하 특성으로 클라이언트 연결이 실패하자 다시 주 노드를 페일오버해 복구했다.
   • 3월 23일 부하를 줄이려고 웹훅 트래픽을 제한했다.

   후속 조치

   • 다른 대책을 더 찾는 동안 최대 부하 시간대에 웹훅 트래픽 제한을 계속 써서 같은 장애가 다시 나지 않게 한다.
   • 최대 부하 시간대의 mysql1 부하 패턴을 점검하고, 그 결과에 따라 성능 수정을 차례로 한다.
   • 부하를 줄이고 페일오버 시간을 줄이려고 mysql1 의 트래픽을 다른 데이터베이스로 옮긴다.
   • 변경 관리 절차를 검토한다. 특히 운영 환경에 부하가 높을 때의 모니터링과 변경을 살핀다.
   • 플랫폼 성장에 맞춰 데이터베이스 샤딩과 하드웨어 확장을 비롯한 인프라 확장을 이어 간다.

   사례 보기

원인별9