시계열 워크로드를 위한 동적 재파티셔닝
Netflix의 TimeSeries Abstraction은 Cassandra를 이용해 페타바이트 규모의 시계열 데이터를 밀리초 단위로 처리하지만, 시간이 지날수록 커지는 광범위한 파티션이 지연시간과 타임아웃을 유발했다. 기존의 테이블 단위 재파티셔닝은 전체 데이터가 비슷한 문제를 보일 때는 효과적이지만, 일부 ID만 비정상적으로 커지는 경우에는 적합하지 않았다. 이를 해결하기 위해 Netflix는 읽기 경로에서 넓은 파티션을 감지하고, 해당 TimeSeries ID 단위로 비동기 분할한 뒤 읽기 요청을 자동으로 재라우팅하는 동적 파티셔닝 시스템을 구축했다. ## Cassandra와 넓은 파티션의 문제 - Cassandra는 높은 처리량, 낮은 지연시간, 비용 효율성, 운영 성숙도를 이유로 Netflix의 시계열 저장소로 사용된다. - 그러나 이벤트가 시간에 따라 누적되면 하나의 파티션이 지나치게 커질 수 있다. - 일반적인 읽기 지연은 수 밀리초 수준이지만, 넓은 파티션에서는 특히 데이터 끝부분에서 지연시간이 수 초까지 증가한다. - 이로 인해 요청 타임아웃, 높은 CPU 사용률, 가비지 컬렉션 일시정지, 스레드 큐 대기 등이 발생할 수 있다. - 단순히 Cassandra 클러스터를 확장하는 방식은 비용 문제를 해결하지 못하므로 데이터 배치 자체를 개선해야 한다. ## 기존 TimeSeries 파티셔닝 전략 - 데이터를 일정한 시간 단위의 개별 Time Slice로 나누어 파티션 크기를 제한한다. - 시간 기준으로 데이터를 효율적으로 조회하거나 삭제할 수 있으며, 대량의 tombstone을 처리해야 하는 부담도 줄어든다. - 데이터셋 생성 시 사용자가 예상 트래픽과 이벤트 특성을 입력한다. - 프로비저닝 파이프라인은 해당 입력을 바탕으로 Monte Carlo 시뮬레이션을 수행해 인프라와 파티션 설정을 결정한다. ## 사전 설정 방식의 한계 - 초기 단계에서는 실제 운영 트래픽을 정확히 예측하기 어렵다. - 시간이 지나면서 트래픽 패턴, 클라이언트 동작, 제품 요구사항이 변할 수 있다. - 일부 TimeSeries ID만 다른 ID보다 훨씬 많은 이벤트를 받는 데이터 이상치가 존재할 수 있다. - Time Slice마다 다른 파티션 전략을 적용할 수 있지만, 수천 개 데이터셋의 설정을 사람이 직접 조정하는 것은 지속 가능하지 않다. - 따라서 파티션 상태를 관찰하고 자동으로 조정하는 시스템이 필요하다. ## Time Slice 단위 재파티셔닝 - Cassandra의 `nodetool tablehistograms` 등 introspection API를 활용해 파티션 크기 분포를 관찰한다. - 너무 작은 파티션이 많은 과도한 분할(over-partitioning)과 지나치게 큰 파티션을 모두 탐지할 수 있다. - 예를 들어 파티션 크기가 10KB보다 작으면 읽기 증폭과 스레드 큐잉이 커질 수 있다. - 백그라운드 워커가 애플리케이션에 연결된 Time Slice의 파티션 히스토그램을 감시한다. - 파티션 크기가 설정된 목표 밀도에 미달하면 조정 계수를 계산하고, 이후 생성될 Time Slice의 `time_bucket` 간격을 변경한다. - 목표 파티션 크기는 워크로드에 따라 보통 2MiB~10MiB로 설정된다. - 이 방식은 읽기 지연시간과 타임아웃을 줄이는 데 효과가 있었지만, 테이블 전체가 비슷한 문제를 보일 때만 적합하다. - 특정 ID 몇 개만 넓은 경우에는 전체 테이블의 파티션 전략을 바꾸는 것이 불필요하거나 효과적이지 않다. ## 일부 ID만 문제가 될 때의 대응 - **아무것도 하지 않기** - 애플리케이션의 전체 지표에 영향이 없다면 문제를 감수하는 것이 합리적일 수 있다. - **부분 결과 반환** - 요청이 설정된 지연시간 SLO를 넘으면 진행 중인 요청을 중단한다. - 그때까지 수집한 데이터만 반환해, 전체 결과보다 빠른 응답을 우선하는 클라이언트에 적합하다. - **문제 ID 차단** - 테스트나 스팸 데이터처럼 시스템을 불안정하게 만드는 ID를 차단한다. - 다만 정상적이고 중요한 ID가 큰 경우에는 데이터 전체를 처리해야 하므로 이 방법을 사용할 수 없다. ## ID별 동적 파티셔닝 - 동적 파티셔닝은 테이블 전체가 아니라 특정 TimeSeries ID의 넓은 파티션만 자동으로 분할한다. - 비동기 파이프라인은 다음 세 단계로 구성된다. - **감지:** 읽기 경로에서 특정 파티션의 읽기 바이트 수를 추적하고, 임계치를 넘으면 넓은 파티션으로 판단한다. - **계획 및 분할:** 적절한 크기가 되도록 파티션 분할 작업을 계획하고 비동기적으로 실행한다. - **읽기 제공:** 분할이 완료되면 기존 요청 경로를 투명하게 새 파티션으로 재라우팅한다. - 읽기 작업 중 파티션에서 읽은 바이트가 설정된 한도를 초과하면 Kafka로 감지 이벤트를 발행한다. - 이벤트에는 데이터가 속한 Time Slice 테이블, 문제가 된 `time_series_id`, 기존 `time_bucket`, `event_bucket`, 해당 파티션의 쓰기 종료 여부(`immutable`), 버전 등의 정보가 포함된다. - 이 구조를 통해 정상적인 ID에는 영향을 주지 않으면서, 데이터량이 큰 특정 ID만 선택적으로 재구성할 수 있다. ## 실용적인 결론 - 데이터 전체의 분포가 바뀌었다면 Time Slice 단위 자동 재파티셔닝을 적용하는 것이 효율적이다. - 일부 ID만 비대해지는 경우에는 ID별 동적 파티셔닝이 더 적합하다. - 읽기량, 파티션 크기, 지연시간 SLO를 지속적으로 관찰하고 자동화된 감지·분할·재라우팅 체계를 마련하는 것이 핵심이다.
원문 읽기(새 탭에서 열림)
