Scaling Time Series Data Storage — Part II

https://medium.com/netflix-techblog/scaling-time-series-data-storage-part-ii-d67939655586

Part2 에서는 아키텍처 한계를 탐구하고, 진화를 위해 다음 단계를 우리가 어떤 설계를 할것인지 설명한다.

Breaking Point

Part1 의 아키텍처는 유형(전체보기 vs 프리뷰)과 age(얼마나 오랫동안 봤는지)에 상관없이 동일한 데이터로 취급
영상 프리뷰가 날이 갈수록 많이 사용(사용하는 디바이스가 늘어서)되는데, 데이터센터에 잠재적으로 영향을 줄까봐 미리보기는 항상 뒷전(지연됨)이었음
카산드라 클러스터를 확장 해야 하는데 클러스터 사이즈가 이미 한계에 다다랐다.
최대한 빨리 뭔가 해야 한다!!
Rethinking Our Design
우리의 접근 방식을 재고해야 했고, 적어도 5배 이상 확장을 위한 디자인이 어려웠다.
Part1 의 아키텍처를 재사용할 수 있는 패턴은 이미 있으나 이걸론 부족함
새로운 패턴과 기술이 필요하다!!
Analysis
데이터 세트의 access 패턴 분석해 봄
- 전체보기 (Full title plays)
- 미리보기 (Video preview plays)
- 언어 설정 (어떤 언어로 자막 설정을 하는지)
각 카테고리 마다 다른 패턴을 발견함
대부분의 access 는 최근 데이터에서 발생 (age가 높아질수록 Level of detail 이 낮아짐)
이러한 insight 와 데이터를 토대로, 어떤 데이터가 오랫 동안 필요한지 고민해봄.
Storage Inefficiency
미리보기 & 언어 정보를 위해서는, 파트너는 최신 정보만 필요하다.
미리보기에 대해 고객은 피드백이 없는편이라(긍정적 혹은 부정적), 파트너에서는 미리보기를 관심을 안줌(필터링 됨)
고객이 시청한 타이틀에 동일한 자막 언어를 설정하는것을 발견 했다.(당연한거 아닌가ㅋㅋ)
시청기록과 함께 동일한 언어 설정을 저장 하는데 많은 데이터 중복이 발생 한다.
Client Complexity
클라이언트 라이브러리에서 caller 가 특정 데이터와 특정 기간과 같은 부분적인 데이터만 필요하더라.
다음의 정보를 지정하여 검색 가능
- Video Type (전체보기 or 미리보기)
- Time Range (기간)
- Level of detail (전체 or 요약)
- 자막 / 더빙 포함 여부
대개의 경우 백앤드에서 전체 데이터를 조회 후, 클라이언트에서 필터링 하더라. (불필요한 데이터 전송)
큰 데이터를 보는것은 결국 성능을 크게 나쁘게 한다. 읽기 latency의 99th percentile 에 큰 영향을 줌
Redesign
Goal 은 예측 가능한 5배 이상 scale 이 가능한 설계. (합리적인 비용)
위의 문제점을 분석해서 재설계 했다. 가이드라인은 다음과 같다.
Data Category
Shard by data type
꼭 필요한 요소로만 데이터 필드를 줄임
Data Age
Shard by age of data. 최근 데이터는 TTL 이후 expire.
히스토리 성 데이터는 요약해서, archive cluster 로 대체
Performance
Read 병렬화 (최근 및 히스토리 데이터를 통합한 추상화 제공)
Cluster Sharding
이전에는 type/age/level of detail 등 모든 데이터를 통합해서 하나의 클러스터 집어 넣었음
이제는 type/age/level of detail 를 클러스터 shard 함
이것은 서로 다른 성장률을 보이는 각 데이터셋을 분리(decouples)하고, read latency 가 향상 됨
Storage Efficiency
매우 짧은 미리보기는 고객의 컨텐츠에 대한 관심이 아니기 때문에 저장 안한다.
현재는 초기 언어 설정은 저장함. 고객은 단일 언어 설정만 저장하기 때문에 저장 용량 절약 (과거에는 타이틀 별로 저장)
미리보기, 언어 설정은 TTL이 낮기 때문에 expire time 을 아주 낮게 함
Part1 에 소개된 live and compressed technique 기술 적용 (최근 데이터는 압축 안함, 오래된것은 압축함)
이는 클러스터 스토리지 비용 절감 및 access time 성능 향상
표참조
- Type 별로 스토리지 shard - 전체보기, 미리보기, 언어 설정을 위한 별도의 클러스터 있음
- 전체보기는 age 단위로 shard.
- historical 는 요약 보기만 저장함
  Data Flows
  
  Writes
쓰기는 최신 클러스터로 이동
필터 기능 - 미리보기 저장 여부, 자막 / 더빙 설정이 이전과 바뀌었을때에만 저장
Reads
최신 데이터에 대한 요청은 최신 클러스터로 바로 감. 요청이 많아지면 병렬 처리가 활성화 됨
Last few days of viewing data
최신의 전체보기 영상은 Recent 클러스터에서만 읽음
LIVE and COMPRESSED tables 병렬 수행
Part1 에서 설명한 것처럼 전체보기, 미리보기 LIVE 레코드 수가 threshold 를 초과하면 COMPRESSED table 로 이관 (동일한 key)
언어 설정도 병렬 읽기 가능
Last few months of full title
Recent and Past 클러스터를 병렬 읽기 함
Summarized viewing data
Recent, Past and Historical 클러스터 병렬 읽기 및 데이터 조합 필요
예를 들어, Historical 클러스터에는 멤버 보기에 대한 몇년간 데이터는 없으므로, Recent and Past 데이터를 참조함
Data Rotation
전체 보기의 경우 다른 age 클러스터 간 레코드 이동이 비동기적으로 발생
예를 들어 멤버 보기를 Recent로 수행 했는데, 오래된 레코드면 Past 로 옮기기 위해 queued 함
작업 수행시 Past에 있던 COMPRESSED table 과 결합하여, 새 버전 table 이 생기고, 기존꺼는 삭제
만약 새 버전 COMPRESSED 레코드가 크기가 threshold를 초과하면 chunked 됨. (병렬로 여러 청크로 쪼개짐)
그림 참조
Past -> Historical 이동도 유사하다.
Performance Tuning
LIVE and COMPRESSED records 는 table 을 분리하여 저장하고, 튜닝을 별도 설정
LIVE table 의 update 는 자주 일어남 반면에 viewing records 는 빈도수 적음
- compactions 은 자주 발생
- gc_grace_secnods 는 짧음. (delete expire 설정)
Read repair 와 full column family repair 자주 발생
- 일관성 유지를 위한 작업들
COMPRESSED tables 은 수동으로 대응. update 중에 일관성 맞춰줌. Read repair 등 안해도 됨
Caching Layer Changes
카산드라는 병렬로 큰 청크 데이터를 읽기 때문에, 캐시 레이어를 갖는것에 큰 이점이 있음
EVCache 레이어 아키텍처는 백앤드 스토리지 아키텍처와 유사하게 만듦
캐시 히트율 99% 이며, 카산드라의 읽기 요청을 최소화 함
이미지 참고
한가지 다른점은 Summary 캐시는 전체 보기에 대한 요약정보를 저장함
따라서 Summary 를 작성하기 위해 3 개의 table 을 조합하는 작업은 안해도 됨
Migration: Preliminary Results
현재 모든 변경점에서 반이상은 마이그레이션 됨.
중간 결과와 교훈
data type 기반으로 샤딩된 카산드라 클러스터의 성능(compactions, GC, latency)이 크게 개선 됨
전체 보기에 대한 여유 공간이 많이 생김 (적어도 5배 이상 scale 가능)
적극적인 데이터 압축 및 TTL 설정으로 상당한 비용 절감
Re-architecture 은 이전버전과 호환됨. 구 API 과 신 API 모두 사용 가능하며, 클라이언트 변경없이 서버의 변경 사항을 쉽게 배포 가능. 또한 time 기반으로 마이그리에션이 편해졌음
Conclusion
우리는 LIVE and compressed의 병렬 읽기로 진화했고, time-series data 패턴을 팀내에서 재사용 하게 됨
LIVE and compressed 패턴을 확장하여 여러 요구사항을 처리할수 있게 됨

Pyohwan / english-study

Scaling Time Series Data Storage — Part II #8

Breaking Point

Rethinking Our Design

Analysis

Storage Inefficiency

Client Complexity

Redesign

Data Category

Data Age

Performance

Cluster Sharding

Storage Efficiency

Data Flows

Writes

Reads

Last few days of viewing data

Last few months of full title

Summarized viewing data

Data Rotation

Performance Tuning

Caching Layer Changes

Migration: Preliminary Results

중간 결과와 교훈

Conclusion