Incident Library

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 까지 쓰러졌다. 결국 사용자는 애플리케이션에 들어가 로그를 볼 수 없게 됐다.

증상 서비스 중단OOMKilled데이터베이스 과부하처리량 저하

원인

촉발
로그 배치를 추적하는 도구가 트래픽 급증을 감당할 크기가 아니어서 인증 캐시의 Redis 서버를 무너뜨렸다.

감지

이른 아침에 알림과 고객 신고가 들어와 에스컬레이션 절차가 시작됐고 온콜 담당자가 호출됐다.

조치

후속 조치

교훈

Mezmo 는 기능을 늘려 갈수록 플랫폼 전반에 깊은 계측과 트레이싱, 관측성이 필요하다는 목표를 다시 확인했다.

출처

관련 사례

내 클러스터에도 있는지 확인하기

kubegap 은 Claude Code 나 Codex 에서 쿠버네티스 클러스터를 읽기만 하며 이 사례와 같은 상태를 점검합니다. 이 사례의 구성 요소: 인메모리 캐시, 데이터베이스. 점검 항목의 근거는 이 사례 같은 공개 보고서입니다.

AI 도구와 스크립트용

API 는 키가 필요 없습니다. MCP 서버는 search_incidents, get_incident, list_incidents, get_topic, vocab 도구를 내놓습니다. 사용법은 API 와 MCP.