IL-0297 Mezmo · 2019-05-15database
Mezmo 의 인증 캐시 Redis 서버가 OOM 으로 죽고 다시 뜨지 못해 로그인이 막히고 로그 색인이 늦어졌다
Mezmo 는 로그인을 포함한 인증 정보를 작지만 분산된 디스크 기반 캐시에 두고 조회한다. 이 캐시는 Redis 서버로 돌아간다. 로그 배치를 추적하는 도구가 트래픽 급증을 감당할 크기가 아니어서 Redis 서버가 버티지 못하고 OOM 으로 죽었다. 죽으면서 남긴 pid 파일 때문에 자동 재시작이 막혀 Redis 가 재부팅을 반복했고, 고객은 계정 데이터에 접근할 수 없었다. 로그와 메타데이터가 처리 대기열에 쌓여 로그 처리 노드가 감당하지 못했다. Redis 가 실패할 때 넘어가는 MongoDB 도 몰린 인증 요청에 쓰러지며 장애가 번졌다. 그 결과 사용자는 애플리케이션에 들어가 로그를 볼 수 없었고, 웹 앱과 Agent, REST API, 코드 라이브러리, Heroku, Syslog 를 통한 로그 수집이 영향을 받았다. 상태 페이지는 2019-05-15 16:59 UTC 에 색인 지연을 알렸고, 18:26 에 근본 원인을 찾아 수정을 배포했다고 알렸다. 22:24 에 모니터링 단계로 넘어갔고, 2019-05-16 00:12 에 해결로 닫았다. 분석에서는 배치 추적 계측 자체는 의도대로 동작했다고 봤다. 평소에도 색인 지연은 가끔 생겼지만 금방 풀렸다. 이번에는 늘어난 트래픽이 시스템의 한계를 넘어선 드문 경우였다. 처음 조치로 클러스터의 특정 부분을 키워 훨씬 큰 트래픽을 견디게 했다.
- 심각도
- –
- 영향 범위
- Sign-in and access to logs in the web application, log indexing for live tail and search, and log ingestion through the agent, REST API, code libraries, Heroku and syslog
- 영향 사용자
- –
- 지역
- –
- 감지까지
- –
- 복구까지
- –
증상
이른 아침에 알림과 고객 신고가 들어와 온콜이 호출됐다. 웹 애플리케이션에서 사용자가 로그인할 수 없었고, 상태 페이지는 2019-05-15 16:59 UTC 에 색인 지연으로 들어오는 로그가 live tail 과 search 에 늦게 나타난다고 알렸다.
인증 정보를 저장하고 조회하는 디스크 기반 캐시의 Redis 서버가 하나도 돌고 있지 않았다. 서버들은 OOM 으로 죽으면서 pid 파일을 남겼고, 이 파일 때문에 자동 재시작이 막혔다. Redis 가 스스로 회복하려 했지만 남은 파일 때문에 재부팅을 반복했다.
장애는 다른 곳으로 번졌다. 로그와 메타데이터가 처리 대기열에 쌓여 로그 처리 노드가 감당하지 못했다. Redis 가 실패하면 애플리케이션은 MongoDB 로 넘어가게 되어 있었지만, 인증 요청이 너무 많아 MongoDB 까지 쓰러졌다. 결국 사용자는 애플리케이션에 들어가 로그를 볼 수 없게 됐다.
원인
원인 용량 한계
- 촉발
- 로그 배치를 추적하는 도구가 트래픽 급증을 감당할 크기가 아니어서 인증 캐시의 Redis 서버를 무너뜨렸다.
감지
이른 아침에 알림과 고객 신고가 들어와 에스컬레이션 절차가 시작됐고 온콜 담당자가 호출됐다.
조치
- 클러스터의 특정 부분을 키워 훨씬 큰 트래픽을 견디게 했다.
후속 조치
- 배치 추적 시스템을 다시 만들어 Redis 클러스터에 주는 직접 부담을 줄인다.
- 배치 추적 기능 전반의 관측용 계측을 늘린다.
- Redis 모니터링을 강화한다.
- 이 장애에 얽힌 파이프라인의 병목을 없앤다.
교훈
Mezmo 는 기능을 늘려 갈수록 플랫폼 전반에 깊은 계측과 트레이싱, 관측성이 필요하다는 목표를 다시 확인했다.
출처
- https://status.mezmo.com/incidents/lyyjmgr8dxz4 · official-status
관련 사례
같은 원인 · 공통 데이터베이스, 인메모리 캐시
같은 원인 · 공통 데이터베이스, 인메모리 캐시
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-0390PostHog US Cloud 의 Persons Postgres 데이터베이스 쓰기가 크게 느려져 이벤트와 persons 수집이 최대 2일 지연됐다PostHog · 2025같은 원인 · 공통 데이터베이스
같은 원인 · 공통 인메모리 캐시
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-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같은 원인 · 공통 데이터베이스
같은 원인 · 공통 데이터베이스
같은 원인 · 공통 데이터베이스
내 클러스터에도 있는지 확인하기
AI 도구와 스크립트용
- 이 사례의 JSON: https://incidentlib-api.benchlet.com/cases/IL-0297
- 가장 비슷한 사례들: https://incidentlib-api.benchlet.com/cases/IL-0297/similar
- MCP 서버(Streamable HTTP, 키 없음):
https://incidentlib-mcp.benchlet.com/mcp
API 는 키가 필요 없습니다. MCP 서버는 search_incidents, get_incident, list_incidents, get_topic, vocab 도구를 내놓습니다. 사용법은 API 와 MCP.