사례1건

1건 중 1~1번째

1. IL-0496 전역 복제 Cassandra 클러스터에서 모든 리전의 인스턴스 CPU 가 100% 로 치솟아 쿼리가 타임아웃됐고, 같은 부하가 이틀 저녁 더 찾아왔다

   Ably2020

   증상

   운영 알람이 전 세계에서 Cassandra 쿼리의 상당 부분이 타임아웃된다고 알렸다. 리전마다 Cassandra 인스턴스 여러 대의 CPU 가 100% 에 붙어 있었고 운영 클러스터 전부가 영향을 받았다.

   데이터베이스 과부하간헐적 타임아웃

   촉발

   매일 같은 시각에 다시 등록하도록 프로그램된 셋톱박스 기기를 많이 둔 고객 계정 하나가 한 가지 작업 요청을 대량으로 보냈다. 몇 초 넘게 걸리는 쿼리를 다시 보내는 공격적인 재시도와, 이 요청에만 외부 API 속도 제한이 걸리지 않던 버그 때문에 요청 수백만 건이 Cassandra 층까지 닿았다.

   원인

   용량 한계

   구성 요소

   데이터베이스

   기여 요인

   재시도 폭주미검증 가정

   감지

   21:22에 운영 알람이 전 세계에서 Cassandra 쿼리의 상당 부분이 타임아웃된다고 알렸다.

   조치

   • 대량으로 들어오던 그 요청에 속도 제한을 걸어 Cassandra 장애를 멈췄다.
   • 그 데이터의 Cassandra 레이아웃을 다시 설계하고 카운터 컬럼을 전혀 쓰지 않도록 샤딩 전략을 바꿔 며칠 뒤 배포했다. Cassandra 인스턴스의 부하가 100분의 1 수준으로 줄었다.

   교훈

   Ably 가 얻은 교훈은 이론과 실제가 다르다는 것이었다. 규모가 커지면 이론적인 고려 말고도 부하, 용량, 용량을 넘었을 때 벌어지는 일, 서비스가 예상대로 응답하지 않을 때 이웃 시스템이 어떻게 반응하는지를 따져야 한다. 모든 시스템은 아래 층 시스템 위에 만들어지고, 그 시스템들의 설계에도 이론과 실제 사이의 절충이 있어 언젠가는 예상하지 못한 동작이 나온다. Ably 는 Cassandra 카운터 컬럼을 쓰지 말라고 결론지었다.

   사례 보기

원인별1