7P by xguru 2020-07-13 | favorite | 댓글 2개

넷플릭스의 분산된 인프라 구조 및 "자유와 책임" 사내 문화때문에 효율화는 꽤 어려운 일이어서, 비용 투명성을 제공하고 효율화 관련 컨텍스트를 의사 결정자 가까이에 두기 위해 맞춤형 대시 보드를 개발했음.

이 "데이터 효율성 대시보드"를 만든 방법과 교훈들

* 넷플릭스의 데이터 플랫폼 환경 : 두가지로 분류가능
1. Data at Rest : Snowflake, S3, Hive, RDS, ElasticSearch, Cassandra, Druid
2. Data in Motion : Keystone, Flink, Mantis, Spark, Kafka, Presto

** 사용량 및 비용 가시성을 한눈에 보기 **
모든 플랫폼의 비용을 취합하는데, 각 비용을 의미있는 유닛들로 쪼갤수 있는 정보를 포함한 채로 취합
ㅤ→ 유닛 : 테이블, 인덱스, 컬럼 패밀리, 잡 등

이 비용 정보의 원천은 기본적으로 서비스 및 태그로 분류한 AWS 빌링정보에 의존하는데, 이것 만으로는 리소스/팀 별 구분이 불가능해서 다음과 같은 방법들을 이용

- EC2기반 플랫폼
ㅤ→ 병목현상을 일으키는 메트릭(bottlenec metric)들을 플랫폼 별로 정의
ㅤ→ 예를 들어, Kafka 는 네트웍에 바운드되지만, Spark 는 CPU와 메모리에 바운드.
ㅤ→ Atlas 와 플랫폼 로그, Rest API를 활용해서 각 리소스당 메트릭들을 구분하고 비용을 할당

- S3기반 플랫폼
ㅤ→ 각 리소스당 S3 Prefix 를 붙이고, 스토리지 가격 기준으로 리소스당 비용을 계산

- Dashboard View
Apache Druid 기반의 커스텀 대시보드를 사용해서 각 비용을 팀에 할당.
이 비용정보의 주요 고객은 엔지니어링 & 데이터팀. 그들이 해당 정보에 기반해서 액션 할수 있도록 제공
추가로, 엔지니어링 리더들에게는 더 높은 수준에서 볼수 있도록 제공.
유스케이스에 따라서 데이터 자원 단위 또는 조직 단위로 그룹화 해서 볼 수 있고, 스냅샷 및 시계열로 데이터 보는 것이 가능

** 자동화된 스토리지 추천 - Time to Live (TTL) **
일부 시나리오에서는 투명성 제공을 넘어서 최적화 권장 사항도 제공.
데이터 스토리지는 사용량도 많고, 비용 모멘텀(저장후 까먹어버리는 것 같은)이 많으므로,
데이터 사용량 패턴을 기반으로 최적의 스토리지 기간(TTL)을 결정하는 분석을 자동화.
S3의 빅데이터 웨어하우스용 테이블들에 대해서는 TTL 추천을 적용

- 비용 계산과 비즈니스 로직
가장 큰 S3 비용은 트랜잭션 테이블에서 발생하며, 일반적으로 날짜별로 파티셔닝
S3 억세스로그와 S3 prefix-to-table-partition 매핑을 이용하여 액세스할 날짜 파티션을 결정할수 있음.
지난 180일간의 액세스(읽기/쓰기) 활동을 보고 최대 Lookback(돌아보기) 일자를 확인.
이 Lookback 일자에 의해 해당 테이블의 TTL 값이 결정.
이 계산된 TTL을 기반으로 실현가능한 연간 절감액을 계산

- Dashboard View
데이터 오너들은 상세한 데이터 접근 패턴을 볼 수 있으며, TTL의 추천값 vs. 현재값을 보고, 가능한 비용 절감액도 확인 가능

** 커뮤니케이션과 사용자에게 알리기 **
데이터 비용을 확인 하는 것은 기술팀의 일상 업무가 되어서는 안됨. 특히나 의미없는 데이터 비용들이라면.
그래서 데이터 비용에 대한 인식을 높일수 있게 데이터 사용량이 많은 팀들에게만 이메일 푸시 알림 하는 기능을 개발.
또한 비용 절감 가능성이 있는 테이블에 대해서만 자동으로 TTL 권장 값을 보냄.
현재, 이런 이메일은 매월 전송되고 있음

** 교훈과 도전과제 **

1. 각 자산들의 메타 데이터를 식별하고 유지하는 것은 비용 할당에 중요함
ㅤ→ 이를 위해 Netflix Data Catalog (NDC) 라는 메타데이터 저장소를 구축
ㅤ→ 데이터 접근 및 검색이 쉬워져서 기존 데이터나 신규 데이터 어떤 것이든 관리가 가능
ㅤ→ NDC 를 비용 계산의 시작점으로 활용
2. 시간 추세 데이터는 도전적
ㅤ→ 추세 데이터는 스냅샷보다 유리 관리 부담이 훨씬 큼
ㅤ→ 데이터 불일치 및 처리 대기 시간 때문에 일관된 보기를 제공하는 것은 어려운 일
ㅤ→ 두가지의 과제를 해결 해야 했음
ㅤㅤ- 자원의 소유권 변경 : 스냅샷은 자동으로 소유권 변경사항이 반영 되어야 하고, 시계열 보기의 경우는 변경 사항 조차도 메타데이터에 반영이 필요
ㅤㅤ- 데이터 문제 발생시 상태 손실 : 자원의 메타데이터는 API를 통해서 다양한 소스에서 추출되다 보니 수집중 실패할 경우 상태가 손실. 이런 데이터 들은 일시적이므로 API추출만으로는 한계가 있음. Keystone 쪽으로 데이터를 펌핑하는 것 과 같은 대안을 찾아야 함

** 결론 **
고도로 분산된 데이터 플랫폼이 있다면, 이런 대시보드를 통해 피드백 루프를 생성하고 사용량 및 비용 컨텍스트를 통합하면 효율성을 크게 향상 시킬수 있음.
가능하다면 자동화된 추천을 통해서 효율성을 높이도록 해야함.
넷플릭스의 경우 데이터 보존 기간을 추천하는 것이 높은 ROI 를 보여줬음.
이 대쉬보드와 TTL 추천을 통해서 전체 데이터 웨어하우스의 저장 공간을 10% 이상 줄일 수 있었음.

추천 기능은 시청자만을 위한 것이 아니었군요.

좋네요. 실시간 모니터링 기계를 볼 수 있다면 불수의근도 움직일 수 있다는 연구를 어디선가 봤는데 갑자기 떠올랐습니다.