IL-0544 Wasabi · 2024-08-06database
Wasabi 전 리전의 S3 와 사용자 서비스에 이틀에 걸쳐 세 차례 장애가 났다
2024년 8월 6일 10:32 UTC 부터 8월 7일 20:40 UTC 사이에 Wasabi 전 리전의 S3 와 사용자 서비스에 세 차례 장애가 났다.
첫 번째는 8월 6일 10:32 UTC 에 큐 서비스가 가득 찬 상태가 되면서 시작됐다. 이 때문에 데이터베이스 캐시가 응답하지 않게 됐다. 운영팀은 데이터베이스에 남은 오래된 연결을 모두 정리하려고 주 데이터베이스를 재시작하면서 동시에 큐 서비스의 큐를 비웠다. 이 조치로 데이터베이스가 완전히 동작하는 상태로 돌아오지 않자 보조 데이터베이스 인스턴스를 주 인스턴스로 승격했고, 11:20 UTC 에 S3 서비스가 다시 정상이 됐다. 13:17 UTC 부터 13:23 UTC 까지 운영팀은 큐 서비스 라이브러리를 데이터베이스에 완전히 반영하려고 데이터베이스를 한 번 더 재시작했다.
두 번째는 8월 7일 02:55 UTC 부터 03:35 UTC 까지였다. 운영팀은 큐 서비스와 앞서 승격한 보조 데이터베이스 인스턴스에서 설정 문제를 찾았다. 이 설정 문제가 Web Console, WAC API, WACM 인터페이스 같은 사용자 서비스의 타임아웃을 일으키고 있었다. 운영팀이 원래의 주 데이터베이스를 다시 운영에 올리자 문제가 풀렸다. 이 사건에서 S3 서비스는 영향이 없었다.
세 번째는 8월 7일 20:30 UTC 부터 20:44 UTC 까지였다. 자동화 서비스가 자동화 클러스터 하나를 보지 못하면서 S3 vault 가 받아들이는 트래픽이 조금 줄었다. 운영팀이 이 클러스터를 다시 만들어 배포하자 S3 서비스가 완전히 돌아왔다.
- 심각도
- –
- 영향 범위
- S3 service (affected from 10:32 until it was fully operational again at 11:20 UTC on 6 August, and a small drop in accepted traffic on 7 August) and user services such as the Web Console, WAC API and WACM interface
- 영향 사용자
- –
- 지역
- All Wasabi regions: US-Central-1, US-East-1, US-East-2, US-West-1, CA-Central-1, EU-Central-1, EU-Central-2, EU-West-1, EU-West-2, AP-Northeast-1, AP-Northeast-2, AP-Southeast-1, AP-Southeast-2
- 감지까지
- –
- 복구까지
- 34h 8m
증상
2024년 8월 6일 10:32 UTC 부터 Wasabi 전 리전에서 S3 와 사용자 서비스에 오류가 났다. 상태 페이지에는 10:56 UTC 에 Web Console 로그인 문제와 Wasabi 리전의 오류를 조사한다는 글이 올라왔다.
첫 번째 사건에서는 큐 서비스가 가득 찬 상태가 되면서 데이터베이스 캐시가 응답하지 않았다. 운영팀이 주 데이터베이스를 재시작했지만 데이터베이스는 완전히 동작하는 상태로 돌아오지 않았다. S3 서비스는 보조 인스턴스를 승격한 뒤 11:20 UTC 에 다시 정상이 됐다.
두 번째 사건은 8월 7일 02:55 UTC 부터 03:35 UTC 까지였다. Web Console, WAC API, WACM 인터페이스 같은 사용자 서비스에서 타임아웃이 났고, S3 서비스에는 영향이 없었다.
세 번째 사건은 8월 7일 20:30 UTC 부터 20:44 UTC 까지였다. 자동화 서비스가 자동화 클러스터 하나를 보지 못하게 되면서 S3 vault 가 받아들이는 트래픽이 조금 줄었다.
상태 페이지는 영향 범위로 US-Central-1, US-East-1, US-East-2, US-West-1, CA-Central-1, EU-Central-1, EU-Central-2, EU-West-1, EU-West-2, AP-Northeast-1, AP-Northeast-2, AP-Southeast-1, AP-Southeast-2 와 Wasabi Management Console 을 적었다.
원인
- 촉발
- 2024년 8월 6일 10:32 UTC 에 큐 서비스가 가득 찬 상태가 됐다.
감지
–
조치
- 운영팀이 데이터베이스에 남은 오래된 연결을 정리하려고 주 데이터베이스를 재시작했고, 동시에 큐 서비스의 큐를 비웠다. 이 조치로는 데이터베이스가 완전히 돌아오지 않았다.
- 보조 데이터베이스 인스턴스를 주 인스턴스로 승격했고, 11:20 UTC 에 S3 서비스가 다시 정상이 됐다.
- 8월 6일 13:17 UTC 부터 13:23 UTC 까지 큐 서비스 라이브러리를 데이터베이스에 완전히 반영하려고 데이터베이스를 한 번 더 재시작했다.
- 8월 7일 두 번째 사건에서 원래의 주 데이터베이스를 다시 운영에 올려 사용자 서비스의 타임아웃을 풀었다.
- 8월 7일 세 번째 사건에서 자동화 서비스가 보지 못하던 자동화 클러스터를 다시 만들어 배포했고, S3 서비스가 완전히 돌아왔다.
후속 조치
–
교훈
–
출처
- https://status.wasabi.com/incidents/smpz7mhv0zkn · official-status
관련 사례
IL-0390PostHog US Cloud 의 Persons Postgres 데이터베이스 쓰기가 크게 느려져 이벤트와 persons 수집이 최대 2일 지연됐다PostHog · 2025같은 원인 · 공통 메시지 브로커, 데이터베이스
같은 원인 · 공통 인메모리 캐시, 데이터베이스
IL-0202갑자기 몰린 쿼리와 데이터베이스 쓰기로 Honeycomb 수집 호스트가 메모리 부족으로 죽었고, 쿠버네티스 CrashLoopBackOff 가 용량 회복을 막아 US1 이벤트 수집이 한 시간 넘게 불안정했다Honeycomb · 2023 · sev1같은 원인 · 공통 인메모리 캐시, 데이터베이스
IL-0386Google Cloud 로 옮긴 뒤 GKE 노드에서 Postgres 연결 타임아웃과 memcached i/o timeout 이 간헐적으로 튀었다incident.io · 2023같은 원인 · 공통 인메모리 캐시, 데이터베이스
같은 원인 · 공통 인메모리 캐시, 데이터베이스
같은 원인 · 공통 인메모리 캐시, 데이터베이스
같은 원인 · 공통 인메모리 캐시
같은 원인 · 공통 데이터베이스
같은 원인 · 공통 데이터베이스
같은 원인 · 공통 데이터베이스
IL-0290GitLab.com 의 Redis Sidekiq 클러스터에서 노드 여러 대가 메모리를 다 써 멈추고 쿼럼을 잃어, 웹과 Git 과 CI 전반에서 500 오류가 늘었다GitLab · 2026 · sev1같은 원인 · 공통 인메모리 캐시
같은 원인 · 공통 데이터베이스
같은 원인 · 공통 데이터베이스
같은 원인 · 공통 데이터베이스
IL-0288CDN77 의 ClickHouse 데이터 파이프라인에서 이중화된 인스턴스 세 곳의 ZooKeeperWait 가 수천 초로 치솟아 복제가 한 시간 넘게 느려졌다CDN77 · 2026같은 원인 · 공통 데이터베이스
같은 원인 · 공통 데이터베이스
IL-0305Intercom 의 PlanetScale 샤드 하나에서 복제본이 CPU 100% 로 주 데이터베이스를 따라가지 못해 받은편지함에 최대 2.2시간 전의 데이터가 보였다Intercom · 2026같은 원인 · 공통 데이터베이스
같은 원인 · 공통 인메모리 캐시
IL-0287Atlas 와 Cloud Manager 의 모니터링을 받치는 내부 데이터베이스 클러스터의 샤드 하나가 과부하되어 지표 수집과 클러스터 작업이 늦어졌다MongoDB · 2025같은 원인 · 공통 데이터베이스
같은 원인 · 공통 데이터베이스
IL-0067Redis 마스터의 50Mi 영구 볼륨이 가득 차 AOF 가 깨졌고, Redis 파드가 크래시 루프에 빠져 Klamm 운영 서비스가 멈췄다BC Government · 2025 · sev1같은 원인 · 공통 인메모리 캐시
같은 원인 · 공통 데이터베이스
IL-0298Wikimedia sessionstore 의 Cassandra 노드가 디스크가 가득 차 잇따라 죽고 쿼럼을 잃어 편집이 실패했다Wikimedia Foundation · 2025같은 원인 · 공통 데이터베이스
IL-0312max_connections 를 올리려고 재시작한 주 PostgreSQL 데이터베이스가 다시 올라오지 않아 Gadget 의 모든 앱 요청이 멈췄다Gadget · 2024같은 원인 · 공통 데이터베이스
같은 원인 · 공통 데이터베이스
같은 원인 · 공통 데이터베이스
IL-0110Grafana Agent 파드가 메모리를 많이 쓰던 노드에 Hangfire 파드가 함께 올라가 시스템 OOM 으로 CrashLoopBackOff 를 반복했고, 노드가 응답을 멈추고 NotReady 가 됐다.DFDS · 2024같은 원인 · 공통 데이터베이스
같은 원인 · 공통 데이터베이스
같은 원인 · 공통 데이터베이스
같은 원인 · 공통 데이터베이스
같은 원인 · 공통 데이터베이스
같은 원인 · 공통 인메모리 캐시
같은 원인 · 공통 데이터베이스
같은 원인 · 공통 데이터베이스
IL-0206GKE 파드 안의 Consul 에이전트가 메모리 급증으로 거듭 OOM kill 되어 Rails 파드가 데이터베이스 복제본을 찾지 못했고, 모든 쿼리가 primary 로 몰려 GitLab.com 이 느려졌다.GitLab · 2022같은 원인 · 공통 데이터베이스
같은 원인 · 공통 데이터베이스
같은 원인 · 공통 데이터베이스
같은 원인 · 공통 데이터베이스
IL-0384US-EAST-1 의 Amazon Kinesis Data Streams 에서 레코드 읽기와 쓰기가 하루 대부분 실패했다Amazon Web Services · 2020같은 원인 · 공통 메시지 브로커
IL-0496전역 복제 Cassandra 클러스터에서 모든 리전의 인스턴스 CPU 가 100% 로 치솟아 쿼리가 타임아웃됐고, 같은 부하가 이틀 저녁 더 찾아왔다Ably · 2020같은 원인 · 공통 데이터베이스
IL-0443Aurora MySQL reader 가 이유 없이 재시작한 뒤 writer 의 insert latency 가 7배쯤 오르고 replication lag 가 하루 넘게 이어졌다Repro · 2019같은 원인 · 공통 데이터베이스
IL-0037imagePullPolicy가 Always인 DaemonSet이 크래시 루프를 돌며 이미지를 계속 받아, NAT 세 대를 같이 쓰던 리전 전체가 이미지 레지스트리에서 429로 막혔다Datadog · 2019같은 원인 · 공통 데이터베이스
IL-0211Mandrill 의 PostgreSQL 샤드 하나가 트랜잭션 ID 랩어라운드를 막으려고 쓰기를 멈춰 약 40시간 동안 메일 발송이 줄었다Mailchimp · 2019같은 원인 · 공통 데이터베이스
IL-0064CPU 를 많이 쓰는 파드가 Google Cloud 노드 하나에 몰려 노드가 커널 패닉으로 죽었고, 다시 배치된 파드가 다음 노드를 또 죽이며 웹사이트와 API 가 멈췄다.Moonlight · 2019같은 원인 · 공통 데이터베이스
같은 원인 · 공통 데이터베이스
IL-0334RDS MySQL 의 bookmarks 테이블이 2TB 파일 크기 한도에 닿아 INSERT 가 실패하고 Instapaper 가 31시간 동안 멈췄다Instapaper · 2017같은 원인 · 공통 데이터베이스
IL-0333사양을 낮춘 RDS PostgreSQL 인스턴스가 피크 부하를 못 버텨 헬스 체크가 실패하고 Buildkite 대시보드가 몇 시간 동안 내려갔다Buildkite · 2016같은 원인 · 공통 데이터베이스
같은 원인 · 공통 인메모리 캐시
같은 원인 · 공통 인메모리 캐시
IL-0282US-East 리전의 DynamoDB 스토리지 서버들이 멤버십 정보를 받지 못해 스스로 요청 처리에서 빠지면서 고객 요청의 약 55% 가 실패했다Amazon Web Services · 2015같은 원인 · 공통 데이터베이스
IL-0275Kafka 브로커들이 네트워크 한계에 닿아 줄줄이 쓰러지면서 Parse.ly 의 데이터 처리가 멈추고 대시보드에 몇 시간 동안 새 데이터가 나오지 않았다Parse.ly · 2015같은 원인 · 공통 메시지 브로커
같은 원인 · 공통 데이터베이스
같은 원인 · 공통 데이터베이스
내 클러스터에도 있는지 확인하기
AI 도구와 스크립트용
- 이 사례의 JSON: https://incidentlib-api.benchlet.com/cases/IL-0544
- 가장 비슷한 사례들: https://incidentlib-api.benchlet.com/cases/IL-0544/similar
- MCP 서버(Streamable HTTP, 키 없음):
https://incidentlib-mcp.benchlet.com/mcp
API 는 키가 필요 없습니다. MCP 서버는 search_incidents, get_incident, list_incidents, get_topic, vocab 도구를 내놓습니다. 사용법은 API 와 MCP.