{"id":"IL-0212","org":"Slack","date":"2022-02-22","docs":[],"title":{"en":"Many Slack users could not connect because a Vitess keyspace for channel membership was overloaded by cache-miss queries","ko":"캐시 적중률이 떨어지며 채널 멤버십 Vitess 키스페이스가 과부하에 빠져 많은 사용자가 Slack 에 접속하지 못했다"},"domain":["database"],"impact":{"scope":"Slack client boot: many users could not connect to Slack, and requests from users with booted clients also failed until boot requests were throttled","users":"many Slack users, including internal users","region":"unknown"},"review":{"written_by":"session","reviewed_at":null,"reviewed_by":null},"lessons":{"en":"Slack describes performance bottlenecks, a cascading failure, dependence on a warm cache and a change as the trigger. Once the system had passed the tipping point, lower cache hit rates caused high database load that in turn kept the cache from filling, and a system in that state stays there until an outside intervention, a large cut in load or an increase in capacity, changes it. Mcrib contributed not by being wrong but by being faster than the old Consul lock scheme at replacing Memcached nodes, which increased churn in the cache tier. Client retries still added load despite backoff and jitter. A brief network partition of the cache nodes could set off the same failure, and the interaction between Consul and the caching architecture is now more widely understood.","ko":"Slack 은 성능 병목, 연쇄 장애, 데워진 캐시에 기대는 구조, 촉발 요인이 된 변경이 장애에서 자주 보이는 패턴이라고 봤다. 이번 장애는 여러 시스템의 경계를 넘는 상호작용이었고 그중 일부 시스템은 최근에 바뀌었다. 큰 소프트웨어 시스템에서 복잡성과 변경은 피할 수 없고, 그만큼 시스템이 예측하지 못한 방식으로 움직일 위험도 커진다.\n\nMcrib 는 틀리거나 비효율적이어서가 아니라 오히려 빠르고 효율적이어서 장애를 키웠다. 빠진 memcached 인스턴스를 더 빨리 찾아 설정을 고치면서 캐시 계층의 교체가 늘었고, 더 나은 구성 요소가 전체 시스템을 덜 안전하게 만들었다. 캐시 노드에 짧은 네트워크 단절이 생겨도 같은 연쇄 장애가 날 수 있다는 위험도 드러났다. 연쇄 장애에 빠진 시스템은 부하를 크게 줄이거나 용량을 늘리는 외부 개입 없이는 안정 상태로 돌아오지 않는다."},"related":[],"sources":[{"url":"https://slack.engineering/slacks-incident-on-2-22-22/","kind":"blog","archived":"https://web.archive.org/web/20261105011322/https://slack.engineering/slacks-incident-on-2-22-22/"}],"summary":{"en":"Slack stores its data in Vitess, a horizontal scaling system for MySQL with logical databases called keyspaces, and caches frequently used data in Memcached. Mcrouter routes cache requests by consistent hashing over a list of healthy Memcached hosts, and Mcrib, a fairly new control plane, generates that list from the Consul service catalog: when a Memcached instance disappears from Consul, Mcrib promotes a spare, and a node that rejoins is flushed before it serves again. During client boot Slack fetches the members of each GDM the user is in. That data was read from a keyspace sharded by user, so finding the members of one GDM meant a scatter query to every shard. The data is immutable and cached by channel ID with a long TTL, so the query was normally almost always served from the cache.\n\nOn 22 February a Consul agent upgrade step covered 25% of the fleet, after two 25% steps the week before had passed without trouble. As Memcached nodes were restarted one after another at the daily traffic peak, Mcrib kept replacing and flushing them and the cache hit rate fell. Because even one channel missing from the cache meant querying every shard, nearly every booting client now needed a query on every shard, and the keyspace was overwhelmed. Timed-out queries could not refill the cache, and client retries added load, so the system stayed in a cascading failure even after the Consul restarts were paused.\n\nResponders throttled client boot requests to cut the load on the datastores, which restored more normal service for users with booted clients. The query was changed to read from Vitess only the data missing from Memcached instead of every shard on each miss, and, because the data tolerates staleness, to read from replicas as well as primaries. The caches refilled, hit rates rose and database load fell, and the boot rate limit was raised slowly back to normal traffic levels until service was fully restored.","ko":"Slack 클라이언트는 새 세션을 시작할 때 부팅 과정에서 채널 목록, 설정, 최근 대화를 서버에서 가져와 캐시하고, 부팅하지 못하면 쓸 수 없다. Slack 은 데이터를 MySQL 수평 확장 시스템인 Vitess 에 두고, 자주 쓰는 데이터는 Memcached 캐시 계층에서 읽는다. Mcrouter 는 정상 memcached 호스트 목록으로 만든 설정을 받아 일관 해싱으로 캐시 요청을 보낸다. 캐시 제어 계층인 Mcrib 는 서비스 디스커버리 시스템 Consul 을 지켜보다가 빠진 memcached 인스턴스를 예비 인스턴스로 바꾸고 다시 들어온 인스턴스는 비운 뒤 활성으로 올린다. Consul 에이전트가 내려가면 노드와 그 위의 서비스가 서비스 카탈로그에서 빠진다.\n\n2월 22일 Consul 에이전트 업그레이드를 비율 단위로 롤아웃하는 단계에서 전체 에이전트의 25% 를 차례로 재시작했다. 앞 주의 25% 단계 두 번은 문제가 없었지만, 이번에는 하루 최대 트래픽과 겹쳤다. memcached 노드가 차례로 빠졌다 들어오며 Mcrib 가 빈 노드를 올리고 다시 들어온 노드를 비웠고, 캐시 적중률이 떨어졌다. 클라이언트 부팅 중 그룹 DM 멤버 목록은 사용자 기준으로 샤딩한 키스페이스에서 모든 샤드를 조회하는 scatter query 로 읽었는데, 평소에는 채널 ID 로 오래 캐시되어 문제가 없었다. 캐시가 비자 이 쿼리가 폭증해 키스페이스가 과부하에 빠졌고, 쿼리가 타임아웃되어 캐시를 채우지 못하는 연쇄 장애가 이어졌다. 클라이언트 재시도도 부하를 보탰다. 이전 방식보다 빠르고 효율적으로 캐시 설정을 고치는 Mcrib 가 캐시 계층의 교체를 늘려 장애를 키웠다.\n\n대응 팀은 Consul 재시작을 멈췄고, 클라이언트 부팅 요청에 속도 제한을 걸어 이미 부팅한 사용자의 서비스를 지켰다. 제한을 한 번에 너무 많이 풀었다가 부하가 다시 올라 제한을 되돌리고 작은 폭으로 풀었다. 쿼리는 memcached 에 없는 데이터만 Vitess 에서 읽게 바꿨고, 그룹 DM 데이터는 바뀌지 않으므로 Vitess 프라이머리뿐 아니라 복제본에서도 읽게 했다. 캐시가 다시 차며 적중률이 오르고 데이터베이스 부하가 내려갔고, 부팅 속도 제한을 천천히 정상 수준까지 올려 서비스를 완전히 되살렸다."},"trigger":{"en":"A percentage-based rollout step upgraded the Consul agent on 25% of the fleet, followed by a slow sequential restart of the agents. Each restart on a Memcached node removed it from the Consul service catalog, so Mcrib, the cache-tier control plane, replaced it with an empty spare or flushed it when it rejoined, and the cache hit rate dropped as Slack reached its daily peak traffic.","ko":"2월 22일 Consul 에이전트 업그레이드를 비율 단위로 롤아웃하는 단계에서 전체 에이전트의 25% 를 차례로 재시작했다. memcached 노드의 에이전트가 재시작될 때마다 캐시 제어 계층인 Mcrib 가 그 노드를 비어 있는 예비 노드로 바꾸거나 다시 들어온 노드를 비웠고, 하루 중 트래픽이 가장 많은 시간에 캐시 적중률이 떨어졌다."},"severity":"unknown","symptoms":["database-overloaded","high-error-rate","high-latency"],"timeline":{"detected_after":null,"resolved_after":null},"date_kind":"incident","detection":{"en":"User tickets about connection problems, reports from internal users and pages and alerts to several engineering teams arrived almost at the same time, just after 6 a.m. Pacific Time.","ko":"태평양 시간 오전 6시 직후 Slack 에 접속하지 못한다는 사용자 티켓, 내부 사용자의 문제 제기, 여러 엔지니어링 팀의 호출과 알림이 거의 동시에 들어왔다."},"components":["database","cache","service-discovery"],"root_cause":"capacity","remediation":[{"text":{"en":"Paused the Consul agent restart operation","ko":"대응 초기에 장애를 촉발한 Consul 에이전트 재시작 작업을 멈췄다. 그때는 재시작이 장애와 관련 있다고 의심하지 않았다."}},{"text":{"en":"Throttled client boot requests to reduce load on the database tier","ko":"느린 부팅 요청이 데이터베이스 자원을 바닥내 이미 부팅한 사용자의 요청까지 막자 클라이언트 부팅 요청에 엄격한 속도 제한을 걸었다."}},{"text":{"en":"Cut the client boot rate limit again after a too-large increase and then raised it in smaller steps","ko":"처음 제한을 너무 많이 풀어 데이터베이스 부하와 실패한 요청이 다시 늘자 부팅 속도 제한을 다시 낮췄고, 그 뒤로는 작은 폭으로 올렸다."}},{"text":{"en":"Changed the GDM membership query to read from Vitess only the data missing from Memcached","ko":"캐시 미스마다 모든 샤드를 읽던 쿼리를 memcached 에 없는 데이터만 Vitess 에서 읽도록 바꿨다."}},{"text":{"en":"Let the query read from replicas as well as Vitess primaries","ko":"그룹 DM 데이터는 바뀌지 않아 조금 오래된 값을 써도 되므로 쿼리가 Vitess 프라이머리뿐 아니라 복제본에서도 읽도록 바꿨다."}},{"text":{"en":"Raised the client boot rate limit slowly back to normal traffic levels as the caches refilled","ko":"캐시가 다시 차고 적중률이 오르자 데이터베이스 처리량을 최대로 유지하면서 클라이언트 부팅 속도 제한을 천천히 정상 트래픽 수준까지 올렸다."}}],"action_items":[{"text":{"en":"Change the process for Consul rollouts so upgrades do not trigger this failure mode again","ko":"Consul 롤아웃 절차를 바꿔 업그레이드 중에 같은 장애가 다시 촉발되지 않게 했다."}},{"text":{"en":"Change the Mcrib control loop so a brief network outage or partition of cache nodes does not set off the same cascading failure","ko":"캐시 노드에 짧은 네트워크 단절이 생겨도 같은 연쇄 장애가 나지 않도록 Mcrib 제어 루프의 해당 부분을 바꿔 배포한다."}},{"text":{"en":"Make the GDM membership query read from a table sharded by channel","ko":"문제가 된 scatter query 를 채널 기준으로 샤딩한 테이블에서 읽도록 바꿨다."}},{"text":{"en":"Check the other cache-fronted database queries for high-volume scatter queries","ko":"캐시 계층 뒤에 있는 다른 데이터베이스 쿼리를 분석해 비슷한 위험이 있는 대량 scatter query 가 있는지 찾는다."}},{"text":{"en":"Explore longer-term ways to make the caching tier more resilient","ko":"장기 프로젝트로 캐시 계층의 복원력을 높이는 다른 방법을 찾는다."}}],"contributing":["warm-cache-dependency","inefficient-query","automation-amplified","retry-storm","change-in-peak-hours"],"recurrence_of":null,"symptoms_text":{"en":"Just after 6 a.m. Pacific Time on 22 February 2022, user tickets about problems connecting to Slack, problems reported by internal users, and pages and alerts to several engineering teams all arrived at almost the same moment. Many users could not connect: the Slack client could not finish booting, the step that fetches channel lists, preferences and recent conversations, and showed an error page.\n\nResponders saw more load than usual on parts of the database system. One Vitess keyspace, which holds channel membership sharded by user, was severely overloaded, and a large share of its load came from a query that lists Group Direct Message (GDM) conversations by user. That query normally sits behind the Memcached cache tier, so the load suggested that something was wrong with the caches. Because the table was sharded by user, finding the members of a GDM took a scatter query to every shard, and with a large part of the cache empty nearly every user needed such a query to succeed on every shard. Most queries to the channel membership tables sharded by user were timing out, which also meant the cache could not be refilled.\n\nClient boot requests took much longer than usual and often failed, and these slow requests exhausted resources in the database tier, so requests from users whose clients had already booted failed too. Throttling client boot requests reduced the errors and gave users with booted clients more normal service. The first attempt to raise the boot limit went too far: database load rose past sustainable levels and failed requests climbed again, so the limit had to be cut and then raised in smaller steps.\n\nEarly on, responders paused the Consul agent restarts that were in progress, before anyone suspected them, but by then this made no difference. The database read load grew superlinearly with the share of cache misses, and client retries, even with exponential backoff and jitter, added to it, so the cache and database tiers stayed in a cascading failure until load was reduced and the query was changed.","ko":"2022년 2월 22일 태평양 시간 오전 6시 직후 Slack 에 접속하지 못한다는 사용자 티켓과 내부 사용자의 문제 보고가 들어왔고, 여러 엔지니어링 팀에 호출과 알림이 거의 동시에 왔다. 많은 사용자가 Slack 에 접속하지 못했다. 클라이언트는 부팅 과정에서 채널 목록, 설정, 최근 대화를 서버에서 가져오는데, 부팅하지 못하면 Slack 은 오류 페이지를 보였다.\n\n가장 크게 영향받은 API 작업은 클라이언트 부팅이었다. 부팅 요청은 평소보다 훨씬 오래 걸리고 자주 실패했으며, 느린 요청이 데이터베이스 계층의 자원을 바닥내 이미 부팅한 사용자의 요청까지 실패하게 만들었다.\n\n데이터베이스 시스템 일부에 평소보다 큰 부하가 걸렸다. 사용자 기준으로 샤딩한 채널 멤버십 Vitess 키스페이스에 심한 과부하가 걸렸고, 부하의 상당 부분은 사용자별 그룹 DM 대화 목록을 조회하는 쿼리였다. 이 쿼리는 캐시 계층 뒤에 있었으므로 대응 팀은 캐시에 문제가 있다고 봤다.\n\n사용자 기준으로 샤딩한 테이블에서 그룹 DM 의 멤버를 찾으려면 키스페이스의 모든 샤드에 scatter query 를 보내야 했다. 캐시의 상당 부분이 비자 거의 모든 사용자가 모든 샤드를 조회해야 했고, 읽기 부하는 캐시 미스 비율보다 가파르게 늘었다. 채널 멤버십 테이블 쿼리 대부분이 타임아웃되어 캐시를 다시 채울 수 없었다.\n\n대응 팀은 초기에 문제를 촉발한 Consul 에이전트 재시작 작업을 멈췄다. 그때는 재시작이 장애와 관련 있다고 의심하지 않았고, 이미 연쇄 장애 상태라 멈춰도 달라지지 않았다. 클라이언트의 자동 재시도는 지수 백오프와 지터를 썼지만 여전히 부하를 보탰다.\n\n부팅 요청에 엄격한 제한을 걸자 오류가 줄고 이미 부팅한 사용자의 Slack 은 비교적 정상에 가깝게 동작했다. 처음 제한을 너무 크게 풀자 데이터베이스 부하가 다시 감당할 수 없는 수준으로 오르고 실패한 요청이 늘었다."},"updated_at":"2026-11-14T05:53:41.980855Z","url":"https://benchlet.com/incidentlib/app/cases/IL-0212","org_slug":"slack"}