Incident Library

IL-0212 Slack · 2022-02-22database

캐시 적중률이 떨어지며 채널 멤버십 Vitess 키스페이스가 과부하에 빠져 많은 사용자가 Slack 에 접속하지 못했다

Slack 클라이언트는 새 세션을 시작할 때 부팅 과정에서 채널 목록, 설정, 최근 대화를 서버에서 가져와 캐시하고, 부팅하지 못하면 쓸 수 없다. Slack 은 데이터를 MySQL 수평 확장 시스템인 Vitess 에 두고, 자주 쓰는 데이터는 Memcached 캐시 계층에서 읽는다. Mcrouter 는 정상 memcached 호스트 목록으로 만든 설정을 받아 일관 해싱으로 캐시 요청을 보낸다. 캐시 제어 계층인 Mcrib 는 서비스 디스커버리 시스템 Consul 을 지켜보다가 빠진 memcached 인스턴스를 예비 인스턴스로 바꾸고 다시 들어온 인스턴스는 비운 뒤 활성으로 올린다. Consul 에이전트가 내려가면 노드와 그 위의 서비스가 서비스 카탈로그에서 빠진다.

2월 22일 Consul 에이전트 업그레이드를 비율 단위로 롤아웃하는 단계에서 전체 에이전트의 25% 를 차례로 재시작했다. 앞 주의 25% 단계 두 번은 문제가 없었지만, 이번에는 하루 최대 트래픽과 겹쳤다. memcached 노드가 차례로 빠졌다 들어오며 Mcrib 가 빈 노드를 올리고 다시 들어온 노드를 비웠고, 캐시 적중률이 떨어졌다. 클라이언트 부팅 중 그룹 DM 멤버 목록은 사용자 기준으로 샤딩한 키스페이스에서 모든 샤드를 조회하는 scatter query 로 읽었는데, 평소에는 채널 ID 로 오래 캐시되어 문제가 없었다. 캐시가 비자 이 쿼리가 폭증해 키스페이스가 과부하에 빠졌고, 쿼리가 타임아웃되어 캐시를 채우지 못하는 연쇄 장애가 이어졌다. 클라이언트 재시도도 부하를 보탰다. 이전 방식보다 빠르고 효율적으로 캐시 설정을 고치는 Mcrib 가 캐시 계층의 교체를 늘려 장애를 키웠다.

대응 팀은 Consul 재시작을 멈췄고, 클라이언트 부팅 요청에 속도 제한을 걸어 이미 부팅한 사용자의 서비스를 지켰다. 제한을 한 번에 너무 많이 풀었다가 부하가 다시 올라 제한을 되돌리고 작은 폭으로 풀었다. 쿼리는 memcached 에 없는 데이터만 Vitess 에서 읽게 바꿨고, 그룹 DM 데이터는 바뀌지 않으므로 Vitess 프라이머리뿐 아니라 복제본에서도 읽게 했다. 캐시가 다시 차며 적중률이 오르고 데이터베이스 부하가 내려갔고, 부팅 속도 제한을 천천히 정상 수준까지 올려 서비스를 완전히 되살렸다.

심각도
–
영향 범위
Slack client boot: many users could not connect to Slack, and requests from users with booted clients also failed until boot requests were throttled
영향 사용자
many Slack users, including internal users
지역
–
감지까지
–
복구까지
–

증상

2022년 2월 22일 태평양 시간 오전 6시 직후 Slack 에 접속하지 못한다는 사용자 티켓과 내부 사용자의 문제 보고가 들어왔고, 여러 엔지니어링 팀에 호출과 알림이 거의 동시에 왔다. 많은 사용자가 Slack 에 접속하지 못했다. 클라이언트는 부팅 과정에서 채널 목록, 설정, 최근 대화를 서버에서 가져오는데, 부팅하지 못하면 Slack 은 오류 페이지를 보였다.

가장 크게 영향받은 API 작업은 클라이언트 부팅이었다. 부팅 요청은 평소보다 훨씬 오래 걸리고 자주 실패했으며, 느린 요청이 데이터베이스 계층의 자원을 바닥내 이미 부팅한 사용자의 요청까지 실패하게 만들었다.

데이터베이스 시스템 일부에 평소보다 큰 부하가 걸렸다. 사용자 기준으로 샤딩한 채널 멤버십 Vitess 키스페이스에 심한 과부하가 걸렸고, 부하의 상당 부분은 사용자별 그룹 DM 대화 목록을 조회하는 쿼리였다. 이 쿼리는 캐시 계층 뒤에 있었으므로 대응 팀은 캐시에 문제가 있다고 봤다.

사용자 기준으로 샤딩한 테이블에서 그룹 DM 의 멤버를 찾으려면 키스페이스의 모든 샤드에 scatter query 를 보내야 했다. 캐시의 상당 부분이 비자 거의 모든 사용자가 모든 샤드를 조회해야 했고, 읽기 부하는 캐시 미스 비율보다 가파르게 늘었다. 채널 멤버십 테이블 쿼리 대부분이 타임아웃되어 캐시를 다시 채울 수 없었다.

대응 팀은 초기에 문제를 촉발한 Consul 에이전트 재시작 작업을 멈췄다. 그때는 재시작이 장애와 관련 있다고 의심하지 않았고, 이미 연쇄 장애 상태라 멈춰도 달라지지 않았다. 클라이언트의 자동 재시도는 지수 백오프와 지터를 썼지만 여전히 부하를 보탰다.

부팅 요청에 엄격한 제한을 걸자 오류가 줄고 이미 부팅한 사용자의 Slack 은 비교적 정상에 가깝게 동작했다. 처음 제한을 너무 크게 풀자 데이터베이스 부하가 다시 감당할 수 없는 수준으로 오르고 실패한 요청이 늘었다.

증상 데이터베이스 과부하오류율 상승지연 시간 증가

원인

원인 용량 한계

구성 요소 데이터베이스인메모리 캐시서비스 디스커버리
기여 요인 데워진 캐시에 기댄 구조비효율적인 쿼리자동화 증폭재시도 폭주피크 시간 변경
촉발
2월 22일 Consul 에이전트 업그레이드를 비율 단위로 롤아웃하는 단계에서 전체 에이전트의 25% 를 차례로 재시작했다. memcached 노드의 에이전트가 재시작될 때마다 캐시 제어 계층인 Mcrib 가 그 노드를 비어 있는 예비 노드로 바꾸거나 다시 들어온 노드를 비웠고, 하루 중 트래픽이 가장 많은 시간에 캐시 적중률이 떨어졌다.

감지

태평양 시간 오전 6시 직후 Slack 에 접속하지 못한다는 사용자 티켓, 내부 사용자의 문제 제기, 여러 엔지니어링 팀의 호출과 알림이 거의 동시에 들어왔다.

조치

후속 조치

교훈

Slack 은 성능 병목, 연쇄 장애, 데워진 캐시에 기대는 구조, 촉발 요인이 된 변경이 장애에서 자주 보이는 패턴이라고 봤다. 이번 장애는 여러 시스템의 경계를 넘는 상호작용이었고 그중 일부 시스템은 최근에 바뀌었다. 큰 소프트웨어 시스템에서 복잡성과 변경은 피할 수 없고, 그만큼 시스템이 예측하지 못한 방식으로 움직일 위험도 커진다.

Mcrib 는 틀리거나 비효율적이어서가 아니라 오히려 빠르고 효율적이어서 장애를 키웠다. 빠진 memcached 인스턴스를 더 빨리 찾아 설정을 고치면서 캐시 계층의 교체가 늘었고, 더 나은 구성 요소가 전체 시스템을 덜 안전하게 만들었다. 캐시 노드에 짧은 네트워크 단절이 생겨도 같은 연쇄 장애가 날 수 있다는 위험도 드러났다. 연쇄 장애에 빠진 시스템은 부하를 크게 줄이거나 용량을 늘리는 외부 개입 없이는 안정 상태로 돌아오지 않는다.

출처

관련 사례

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

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

kubegap 열기

AI 도구와 스크립트용

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