{"id":"IL-0496","org":"Ably","date":"2020-06-11","docs":["https://aphyr.com/posts/294-jepsen-cassandra#Counters"],"title":{"en":"Ably's Cassandra hit 100% CPU in every region and queries timed out globally, and the load returned on two more evenings","ko":"전역 복제 Cassandra 클러스터에서 모든 리전의 인스턴스 CPU 가 100% 로 치솟아 쿼리가 타임아웃됐고, 같은 부하가 이틀 저녁 더 찾아왔다"},"domain":["database"],"impact":{"scope":"Ably's primary realtime messaging service: operations that need a Cassandra lookup, such as the first use of an application in a given location and the persistence of some access tokens, failed","users":"some customers were significantly affected","region":"all regions"},"review":{"written_by":"session","reviewed_at":null,"reviewed_by":null},"lessons":{"en":"Ably says theory and practice are different things at scale. Counter columns, which in theory should behave like a CRDT with the performance of Cassandra's regular storage, put two orders of magnitude more load on the instances, and further research showed they are not even eventually consistent. Besides the theoretical concerns, a design has to account for load, capacity, what happens when capacity is exceeded and how peer systems react when a service does not respond as expected. Ably's conclusion is not to use Cassandra counter columns.","ko":"Ably 가 얻은 교훈은 이론과 실제가 다르다는 것이었다. 규모가 커지면 이론적인 고려 말고도 부하, 용량, 용량을 넘었을 때 벌어지는 일, 서비스가 예상대로 응답하지 않을 때 이웃 시스템이 어떻게 반응하는지를 따져야 한다. 모든 시스템은 아래 층 시스템 위에 만들어지고, 그 시스템들의 설계에도 이론과 실제 사이의 절충이 있어 언젠가는 예상하지 못한 동작이 나온다. Ably 는 Cassandra 카운터 컬럼을 쓰지 말라고 결론지었다."},"related":[],"sources":[{"url":"https://ably.com/blog/cassandra-counter-columns-nice-in-theory-hazardous-in-practice","kind":"blog","archived":"https://web.archive.org/web/20260615104805/https://ably.com/blog/cassandra-counter-columns-nice-in-theory-hazardous-in-practice"}],"summary":{"en":"Ably uses a globally distributed and replicated Cassandra cluster for persistent storage of messages and some message metadata, and also for other entities. About two years before the incidents, Ably adopted Cassandra counter columns to get an O(1) count of certain partitions, as part of a sharding strategy for records about push device registrations; counting the cells of a partition with a query is O(N). Counter columns can only exist in tables made entirely of counter columns, a counter table can never be deleted, and counter updates are not idempotent. Ably accepted these limits because it only needed approximate counts, and expected counters, which can be built as a CRDT, to perform like Cassandra's regular storage model.\n\nIn early 2020, over three evenings, Cassandra instances in every region were pinned at 100% CPU and queries timed out; the first two episodes ended by themselves after about 10 minutes. Scaling the cluster horizontally and vertically did not stop the spikes. Instrumentation added after the second episode showed a huge number of requests for one operation on one customer account, whose fleet of set-top boxes re-registered at the same time every day. Each request made several Cassandra upserts and one update to a counter table. Any query that took more than a few seconds was retried, which turned into many millions of requests once load crossed a threshold, and a bug elsewhere in Ably's system let this request skip the rate limiting that applies to every external API request. Applying rate limiting stopped the disruption.\n\nAbly then looked at why the load before the retries had degraded Cassandra so much. The team suspected the counter column, because other requests that did not touch it had never caused comparable load, even at much higher rates. Ably redesigned the Cassandra layout for that data and changed the sharding strategy so that it used no counter columns, and deployed the change a few days later. Removing the counter column operation cut the load on the Cassandra instances by two orders of magnitude.","ko":"Ably 는 메시지와 일부 메시지 메타데이터를 전 세계에 분산되고 복제된 Cassandra 클러스터에 저장한다. 푸시 기기 등록 기록의 샤딩 전략에서는 파티션 크기를 상수 시간에 세려고 카운터 컬럼을 썼고, 이 기능은 약 2년 동안 운영에서 쓰였다. 카운터 컬럼은 카운터 컬럼만 있는 테이블에만 둘 수 있고, 한 번 만든 카운터 테이블은 지울 수 없으며, 카운터 갱신은 멱등이 아니다. Ably 는 근사치면 충분하다고 보고 이 제약을 받아들였다.\n\n2020년 초 사흘 저녁에 걸쳐 리전마다 Cassandra 인스턴스 여러 대의 CPU 가 100% 로 치솟고 전 세계에서 쿼리가 타임아웃됐다. 첫날은 21:22에 시작해 21:32에 가라앉았고, 다음 날 같은 시각에 다시 일어나 10분 만에 가라앉았다. 팀은 노드를 늘리고 노드 크기를 키웠지만 효과가 거의 없었다. 세 번째 날 API 층에 넣은 계측으로, 고객 계정 하나에서 한 가지 작업 요청이 대량으로 들어온 것을 찾았다. 요청마다 Cassandra 쿼리 여러 개와 카운터 테이블 갱신 하나가 따랐다. 몇 초 넘게 걸리는 쿼리를 다시 보내는 공격적인 재시도 때문에, 부하가 어느 선을 넘자 요청이 수백만 건으로 불었다. 다른 곳의 버그로 이 요청에는 외부 API 요청마다 걸리는 속도 제한이 걸리지 않았다. 이 고객의 애플리케이션은 매일 같은 시각에 다시 등록하는 셋톱박스 기기를 많이 두고 있었다.\n\n팀은 이 요청에 속도 제한을 걸어 장애를 멈췄다. 재시도로 불어나기 전의 부하가 왜 Cassandra 응답 시간을 그렇게 떨어뜨렸는지는 여전히 남은 질문이었다. 카운터 컬럼을 쓰지 않는 다른 요청은 훨씬 높은 비율에서도 이런 부하를 만들지 않았으므로 팀은 카운터 컬럼을 원인으로 의심했다. 팀은 그 데이터의 Cassandra 레이아웃을 다시 설계해 카운터 컬럼을 전혀 쓰지 않는 샤딩 전략으로 바꿨다. 며칠 뒤 이 변경을 배포하자 Cassandra 인스턴스의 부하가 100분의 1 수준으로 줄었다. Ably 는 이후 조사에서 카운터 컬럼이 최종 일관성조차 보장하지 않는다는 자료를 확인했다."},"trigger":{"en":"A customer application with a large fleet of set-top box devices was programmed to re-register with Ably at the same time every day. A bug elsewhere in Ably's system meant that the rate limiting applied to every external API request was not applied to this request, and any query that took more than a few seconds was retried.","ko":"매일 같은 시각에 다시 등록하도록 프로그램된 셋톱박스 기기를 많이 둔 고객 계정 하나가 한 가지 작업 요청을 대량으로 보냈다. 몇 초 넘게 걸리는 쿼리를 다시 보내는 공격적인 재시도와, 이 요청에만 외부 API 속도 제한이 걸리지 않던 버그 때문에 요청 수백만 건이 Cassandra 층까지 닿았다."},"severity":"unknown","symptoms":["database-overloaded","intermittent-timeouts"],"timeline":{"detected_after":null,"resolved_after":null},"date_kind":"published","detection":{"en":"Production alarms reported that Cassandra queries were timing out for a large fraction of queries globally.","ko":"21:22에 운영 알람이 전 세계에서 Cassandra 쿼리의 상당 부분이 타임아웃된다고 알렸다."},"components":["database"],"root_cause":"capacity","remediation":[{"text":{"en":"Applied rate limiting to the request that had been reaching Cassandra without it","ko":"대량으로 들어오던 그 요청에 속도 제한을 걸어 Cassandra 장애를 멈췄다."}},{"text":{"en":"Redesigned the Cassandra layout and sharding strategy for that data so it no longer used counter columns","ko":"그 데이터의 Cassandra 레이아웃을 다시 설계하고 카운터 컬럼을 전혀 쓰지 않도록 샤딩 전략을 바꿔 며칠 뒤 배포했다. Cassandra 인스턴스의 부하가 100분의 1 수준으로 줄었다."}}],"action_items":[],"contributing":["retry-storm","assumption-unverified"],"recurrence_of":null,"symptoms_text":{"en":"Production alarms told Ably that Cassandra queries were timing out for a large fraction of queries globally. Multiple Cassandra instances in each region were pinned at 100% CPU, every production cluster was affected, and the disruption reached Ably's primary realtime messaging service. The first episode started at 21:22.\n\nMost message processing at Ably does not touch Cassandra, but some operations do database lookups, for example the first use of an application in a given location and the persistence of some access tokens. These operations failed, and some customers were significantly affected. The statistics on inbound requests showed no spike in any single request type, so it was not even clear that external load was the cause.\n\nRedirecting traffic would not help, because every region and every cluster was affected, and Cassandra clusters cannot be scaled in real time. Just as the team was about to scale Cassandra anyway, the load subsided at 21:32 and service returned to normal. Over the next day the team ran updates and repairs and went through statistics without finding a problem, then scaled the cluster horizontally and vertically. Exactly 24 hours after the first episode the same 100% CPU spike came back in all regions with no visible demand spike, and again subsided after 10 minutes.\n\nIn the following 24 hours the team added instrumentation to the API layer that sits on top of Cassandra, prepared to capture DTrace logs from affected instances, and scaled vertically again to the largest instance and volume sizes available. When the load came back at 21:22, the cluster did not quite max out, and the new data showed a huge number of requests for a single operation on a single customer account.","ko":"운영 알람이 전 세계에서 Cassandra 쿼리의 상당 부분이 타임아웃된다고 알렸다. 리전마다 Cassandra 인스턴스 여러 대의 CPU 가 100% 에 붙어 있었고 운영 클러스터 전부가 영향을 받았다.\n\n장애는 Ably 의 주력 실시간 메시징 서비스에 영향을 줬다. 메시지 처리 대부분은 Cassandra 를 거치지 않지만, 어떤 위치에서 애플리케이션을 처음 쓸 때나 일부 액세스 토큰을 저장할 때처럼 데이터베이스 조회가 필요한 작업은 실패했다. 이 실패로 일부 고객이 크게 영향을 받았다.\n\n첫 장애는 21:22에 갑자기 시작해 21:32에 똑같이 갑자기 가라앉았다. 정확히 24시간 뒤 같은 일이 다시 일어났고 10분 뒤 가라앉았다. 그다음 날 21:22에 부하가 또 왔다.\n\n팀은 먼저 트래픽을 다른 곳으로 돌려 피할 수 있는지 봤지만, 모든 리전과 모든 클러스터의 Cassandra 층이 영향을 받고 있어 소용이 없었다. 들어오는 요청 통계에서는 특정 요청 종류가 치솟은 흔적이 없었다. 트래픽의 출처를 막을 방법이 보이지 않았고, 외부 부하가 원인인지도 분명하지 않았다.\n\n첫 장애 뒤 하루 동안 팀은 업데이트와 repair 를 돌리고 통계를 뒤졌지만 뚜렷한 증거를 찾지 못했다. 노드를 늘리고 노드 크기도 키웠지만 두 번째 장애가 그대로 왔고, 이때도 지표에서 수요 급증은 보이지 않았다. 다음 24시간 동안 팀은 Cassandra 위의 API 층에 계측을 더하고 영향받는 인스턴스에서 DTrace 로그를 받을 준비를 했다. 클러스터도 쓸 수 있는 가장 큰 인스턴스와 볼륨으로 다시 키웠다. 세 번째 부하 때 클러스터는 완전히 포화되지는 않았다."},"updated_at":"2026-11-14T12:34:14.099079Z","url":"https://benchlet.com/incidentlib/app/cases/IL-0496","org_slug":"ably"}