Incident Library

IL-0217 Honeycomb · 2023-07-25databaseaws

스키마 캐시가 데워지지 않아 주 MySQL 데이터베이스가 내부 교착에 빠지고 Honeycomb 전체가 68분 동안 멈췄다

Honeycomb 은 RDS 위에 여러 MySQL 데이터베이스를 두며, 그중 주 데이터베이스에 사용자 계정, 권한, 데이터 스키마가 있다. 스키마 캐시가 이 데이터베이스를 보호하고, 캐시는 저장소와 쿼리 엔진인 Retriever 가 데이터셋마다 마지막으로 데이터를 받은 시각을 기록해야 데워진다. 2023년 7월 24일 밤 미묘한 버그를 피하려고 Retriever 클러스터를 바꿨는데, 이 전환은 여러 번 해 본 안전한 작업이었다. 몇 시간 뒤 수집 서비스 Shepherd 의 SLO 에러 버짓이 천천히 소진됐고, 아침에 엔지니어들은 전환 뒤 Retriever 의 타임스탬프 기록이 끊겨 수집 캐시가 망가진 것을 찾았다.

팀은 기능 플래그로 쓰기만 다른 클러스터로 되돌렸지만 고쳐지지 않았다. 플래그 구현의 버그 때문에 멈추라는 지시를 받은 호스트는 플래그를 되돌려도 다시 시도하지 않았고 재부팅해야만 쓰기가 옮겨 갔다. 이 결함은 늘 있었지만 잦은 배포가 호스트를 재시작하며 가렸다. 조사를 방해하지 않으려고 배포를 멈췄으므로 이번에는 재시작이 우연히 플래그를 되살리는 일도 없었다. 이번 플래그 전환이 시스템을 버티게 하던 남은 쓰기마저 멈췄다. 캐시가 거의 멈추자 주 데이터베이스의 읽기가 치솟았고, 평범한 쓰기 몇 건이 MySQL 내부의 드문 경쟁 상태를 건드려 교착이 생긴 것으로 보였다. Retriever 클러스터를 재시작하는 명령이 준비되기 직전에 데이터베이스가 멈추고 연결이 바닥나 7월 25일 1:40 p.m. UTC 에 전체 시스템이 멈췄다.

팀은 캐시 없이 수집을 다시 올리면 또 무너진다는 것을 알았으므로 데이터베이스부터 살리기로 했다. 서킷 브레이커로 모든 Shepherd 트래픽을 5xx 오류로 거부했고, 완전히 잠긴 데이터베이스 호스트 대신 복제본으로 페일오버했다. 지난 일 때문에 페일오버가 오래 성능을 떨어뜨릴 것이라고 믿어 이 결정이 늦어졌다. 지난 하루 동안 트래픽이 있던 모든 스키마의 마지막 쓰기 시각을 지금으로 바꿔 캐시를 통째로 다시 읽게 했다. 이 때문에 데이터가 얼마나 최신인지 보여 주는 화면 일부에 틀린 값이 들어갔다. 서킷 브레이커를 풀어 수집을 되살렸고, 데이터베이스 오류로 내부 점검에 실패한 호스트를 다시 재시작해 쿼리 용량을 되찾았다. 2:48 p.m. UTC 까지의 장애 동안 새 데이터는 수집되지 않았고, 사용자가 따로 버퍼링하지 않은 데이터는 영영 사라졌다.

심각도
–
영향 범위
Total Honeycomb outage of all user-facing components from 1:40 p.m. to 2:48 p.m. UTC: no data could be ingested, processed or accessed, alerting and querying were affected, and data not buffered by senders was lost
영향 사용자
all Honeycomb users
지역
–
감지까지
–
복구까지
1h 8m

증상

2023년 7월 24일 밤 저장소와 쿼리 엔진인 Retriever 의 클러스터를 바꾼 지 몇 시간 뒤 수집 서비스 Shepherd 의 내부 SLO 에러 버짓이 천천히 소진되기 시작했다. 엔지니어들은 소진이 느리고 들쭉날쭉하며 뚜렷한 설명이 없어서 아침에 조사해도 되는 작은 문제라고 판단했다.

아침에 엔지니어들은 한 차트에서 이상을 찾았다. Retriever 가 필드나 데이터셋에 마지막으로 데이터가 들어온 시각을 기록하는 데이터베이스 호출이 클러스터 전환 뒤 갑자기 끊겨 있었다. 캐시는 이 기록으로 어떤 데이터셋 스키마를 새로 읽어 데워 둘지 정했으므로, 기록이 끊기자 수집 캐시가 제대로 돌지 않았다.

팀은 클러스터의 쓰기에 문제가 있다고 보고 기능 플래그로 쓰기만 다른 클러스터로 되돌렸지만 고쳐지지 않았다. 플래그를 바꾸면 멈추라는 지시를 받은 호스트는 플래그를 되돌려도 다시 시도하지 않았고, 전체 재부팅을 해야 쓰기가 옮겨 갔다.

캐시가 거의 멈추자 주 데이터베이스의 읽기가 치솟아 과부하가 걸렸다. 이어 평범한 쓰기 몇 건이 MySQL 내부의 드문 경쟁 상태를 건드린 것으로 보였고, 데이터베이스 스레드가 하나씩 잠기며 작업이 쌓였다.

Retriever 클러스터를 재시작하는 명령이 준비되기 직전에 데이터베이스가 멈추고 연결이 바닥났다. 서비스들은 필요한 정보를 얻지 못해 죽었고, 7월 25일 1:40 p.m. UTC 부터 2:48 p.m. UTC 까지 사용자용 구성 요소 전부에서 데이터를 처리하거나 볼 수 없었다. 데이터베이스 호스트는 완전히 잠겨 살릴 수 없었다. 잠긴 스레드에 닿는 작업은 모두 같은 잠금을 기다리며 멈췄다.

데워진 캐시 없이 수집을 다시 올리면 과부하나 데이터베이스 연결 포화로 다시 무너질 상황이었다. 예전에 읽기 복제본을 페일오버했을 때 성능이 좋지 않았으므로 팀은 주 데이터베이스의 페일오버도 비용이 클 것으로 봤다.

증상 지연 시간 증가데이터베이스 과부하잠금 경합과 교착서비스 중단

원인

원인 소프트웨어 결함

구성 요소 데이터베이스인메모리 캐시
기여 요인 데워진 캐시에 기댄 구조초기 신호 무시수동 조치 악화미검증 가정
촉발
7월 24일 밤 미묘한 버그를 피하려고 Retriever 클러스터 두 개 사이를 전환했다. 전환 뒤 Retriever 가 마지막 쓰기 시각 기록을 데이터베이스에 쓰지 않았고, 그 뒤 쓰기만 되돌리려고 기능 플래그를 바꾸자 남은 쓰기마저 완전히 멈췄다.

감지

Shepherd 의 내부 SLO 에러 버짓이 천천히 소진되는 것을 엔지니어들이 봤지만 작은 문제로 판단해 아침으로 미뤘다. 아침에 Retriever 의 데이터베이스 호출이 끊긴 차트를 찾아 성능 문제의 원인을 알았다.

조치

후속 조치

교훈

Honeycomb 은 기능 플래그, 잦은 배포, 장애 중 배포 중단, 지난 아차 사고에서 배운 것처럼 시스템을 안전하게 만드는 가장 믿는 관행들이 함께 이번 장애의 원인이 됐다고 봤다. 저마다 합리적인 결정들이 간접 의존 관계를 따라 예상하지 못하게 얽혔고, 환경 한쪽의 문제가 다른 쪽 서비스를 망가뜨렸다.

최근 여러 장애와 아차 사고에서 미묘한 버그를 피하려던 조치가 더 큰 예상 밖 장애로 이어진 일이 자주 있었다. 이런 드문 데이터베이스 잠김에는 페일오버가 가장 빠른 복구 방법이라는 것도 배웠다.

출처

관련 사례

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

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

kubegap 열기

AI 도구와 스크립트용

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