{"id":"IL-0297","org":"Mezmo","date":"2019-05-15","docs":[],"title":{"en":"Mezmo users could not sign in and log indexing lagged after the auth cache's Redis servers were OOM killed","ko":"Mezmo 의 인증 캐시 Redis 서버가 OOM 으로 죽고 다시 뜨지 못해 로그인이 막히고 로그 색인이 늦어졌다"},"domain":["database"],"impact":{"scope":"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","users":"unknown","region":"unknown"},"review":{"written_by":"session","reviewed_at":null,"reviewed_by":null},"lessons":{"en":"Mezmo took from the incident that deep instrumentation, tracing and observability across the platform matter more as features scale up.","ko":"Mezmo 는 기능을 늘려 갈수록 플랫폼 전반에 깊은 계측과 트레이싱, 관측성이 필요하다는 목표를 다시 확인했다."},"related":[],"sources":[{"url":"https://status.mezmo.com/incidents/lyyjmgr8dxz4","kind":"official-status","archived":null}],"summary":{"en":"A tool that tracks batches of logs was not sized for a traffic spike and overwhelmed the Redis servers of Mezmo's authentication cache until they failed. The Redis servers were OOM killed and left pid files that blocked automatic restarts, so Redis kept rebooting. Logs and their metadata backed up in the process queue until they overwhelmed the log processing nodes, and the failover from Redis to MongoDB sent so many authentication requests that MongoDB failed as well, so users could not sign in or reach their logs. The postmortem, signed by the LogDNA team, says the batch tracking instrumentation worked as intended and that the traffic increase was just enough to push the pipeline over the edge.\n\nThe first fix resized specific parts of the cluster to take a much higher load. By 18:26 UTC on 15 May the root cause had been identified and a fix deployed, and the incident was resolved at 00:12 UTC on 16 May.","ko":"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 에 해결로 닫았다. 분석에서는 배치 추적 계측 자체는 의도대로 동작했다고 봤다. 평소에도 색인 지연은 가끔 생겼지만 금방 풀렸다. 이번에는 늘어난 트래픽이 시스템의 한계를 넘어선 드문 경우였다. 처음 조치로 클러스터의 특정 부분을 키워 훨씬 큰 트래픽을 견디게 했다."},"trigger":{"en":"A traffic spike that the tool tracking batches of logs was not sized to handle.","ko":"로그 배치를 추적하는 도구가 트래픽 급증을 감당할 크기가 아니어서 인증 캐시의 Redis 서버를 무너뜨렸다."},"severity":"unknown","symptoms":["service-unavailable","oom-killed","database-overloaded","throughput-degraded"],"timeline":{"detected_after":null,"resolved_after":null},"date_kind":"incident","detection":{"en":"Alerts and customer reports in the early morning hours triggered the escalation procedure and woke the on-call engineers.","ko":"이른 아침에 알림과 고객 신고가 들어와 에스컬레이션 절차가 시작됐고 온콜 담당자가 호출됐다."},"components":["cache","database"],"root_cause":"capacity","remediation":[{"text":{"en":"Resized specific parts of the cluster to handle a much higher load","ko":"클러스터의 특정 부분을 키워 훨씬 큰 트래픽을 견디게 했다."}}],"action_items":[{"text":{"en":"Retool the batch tracking system to reduce its direct impact on the Redis clusters","ko":"배치 추적 시스템을 다시 만들어 Redis 클러스터에 주는 직접 부담을 줄인다."}},{"text":{"en":"Add observability instrumentation around the batch tracking feature set","ko":"배치 추적 기능 전반의 관측용 계측을 늘린다."}},{"text":{"en":"Improve monitoring for Redis","ko":"Redis 모니터링을 강화한다."}},{"text":{"en":"Remove the bottlenecks in the pipeline that were involved in this incident","ko":"이 장애에 얽힌 파이프라인의 병목을 없앤다."}}],"contributing":["warm-cache-dependency"],"recurrence_of":null,"symptoms_text":{"en":"On 15 May 2019, alerts and customer reports showed that the Mezmo web application did not let users sign in, and the status page reported an indexing delay: incoming logs reached live tail and search late.\n\nNone of the Redis servers of the small, distributed, disk-backed cache that stores and looks up authentication information were running. They had been OOM killed and had left pid files behind, which prevented automatic restarts, and Redis went into a reboot loop. When Redis fails the applications fall back to MongoDB, but the volume of authentication requests took MongoDB down too, and the application could not be reached at all to retrieve logs.","ko":"이른 아침에 알림과 고객 신고가 들어와 온콜이 호출됐다. 웹 애플리케이션에서 사용자가 로그인할 수 없었고, 상태 페이지는 2019-05-15 16:59 UTC 에 색인 지연으로 들어오는 로그가 live tail 과 search 에 늦게 나타난다고 알렸다.\n\n인증 정보를 저장하고 조회하는 디스크 기반 캐시의 Redis 서버가 하나도 돌고 있지 않았다. 서버들은 OOM 으로 죽으면서 pid 파일을 남겼고, 이 파일 때문에 자동 재시작이 막혔다. Redis 가 스스로 회복하려 했지만 남은 파일 때문에 재부팅을 반복했다.\n\n장애는 다른 곳으로 번졌다. 로그와 메타데이터가 처리 대기열에 쌓여 로그 처리 노드가 감당하지 못했다. Redis 가 실패하면 애플리케이션은 MongoDB 로 넘어가게 되어 있었지만, 인증 요청이 너무 많아 MongoDB 까지 쓰러졌다. 결국 사용자는 애플리케이션에 들어가 로그를 볼 수 없게 됐다."},"updated_at":"2026-11-14T12:33:55.180407Z","url":"https://benchlet.com/incidentlib/app/cases/IL-0297","org_slug":"mezmo"}