Netflix가 Druid를 실시간 이해에 사용하여 고품질 체험을 보장하는 방법

작성자
인사이트캠퍼스
작성일
2020-04-13 12:57
조회
85

How Netflix uses Druid for Real-time Insights to Ensure a High-Quality Experience

Netflix가 Druid를 실시간 이해에 사용하여 고품질 체험을 보장하는 방법


* 이 기사는 Netflix TechBlog에 작성된 Ben Sykes의 글을 번역하였습니다.

혁신적인 기술 업데이트를 지속적으로 추진하는 동시에 지속적으로 우수한 Netflix 환경을 보장하는 것은 쉬운 일이 아니다. 업데이트가 사용자를 해치지 않는지, 우리가 의도하는 실제로 주목할만한 개선들을 하고 있다는 것을 어떻게 확신할 수 있는가?

우리는 재생 장치의 실시간 로그를 이벤트의 소스로 사용하여, 사용자의 기기가 검색 및 재생을 얼마나 원활하게 처리하는지 이해하고 정량화하기 위해 측정을 도출한다.


일단 우리가 이런 측정값이 있으면, 우리는 그것들을 데이터베이스에 입력한다. 모든 측정값에는 사용되는 기기의 종류 (예를 들어 스마트 TV, 아이패드, 안드로이드 폰 등) 에 대한 익명화된 세부 정보가 태그된다. 이를 통해 우리는 기기를 분류하고 다양한 측면에 따라 데이터를 볼 수 있다. 이것은 차례로 우리가 앱의 버전, 특정 유형의 장치 또는 특정 국가와 같이 특정 그룹에만 영향을 미칠 수 있는 문제를 분리할 수 있게 한다.

이 집계된 데이터는 대시보드 또는 임시 쿼리를 통해 즉시 쿼리할 수 있다. 매트릭스는 또한 새로운 버전이 재생에 영향을 미치거나 일부 사용자 또는 장치를 검색하는 경우와 같이 알람 신호에 대해 지속적으로 점검한다. 이러한 점검은 가능한 신속하게 문제를 해결할 수 있는 담당 팀에게 알리기 위해 사용된다.

이 데이터가 초당 200만 건이 넘는 이벤트에 도달하기 때문에, 신속하게 쿼리할 수 있는 데이터베이스에 데이터를 저장하는 것은 쉽지 않다. 우리는 데이터가 문제를 분리하는데 유용할 수 있도록 충분한 차원성이 필요하므로 우리는 매일 1150억 개 이상의 행을 생성한다. Netflix에서 우리는 Apache Druid를 활용하여 규모에 맞게 이 문제를 해결한다.

Druid

"Apache Druid는 고성능 실시간 분석 데이터베이스이다. 그것은 빠른 쿼리와 수집이 정말로 중요한 작업 흐름을 위해 고안되었다. Druid는 즉각적인 데이터 가시성, 임시 쿼리, 운영 분석 및 높은 동시 처리 능력이 탁월하다." — druid.io

높은 카디널리티 및 빠른 쿼리 요구 사항으로 이벤트 데이터의 높은 수집 속도와 함께, Druid가 우리의 사용 사례와 매우 어울린다.

Druid는 관계형 데이터베이스가 아니지만 일부 개념은 전송할 수 있다. 우리는 테이블대신 데이터 소스를 가지고 있다. 관계형 데이터베이스와 마찬가지로, 이것들은 열로 표현되는 데이터의 논리적 그룹이다. 관계형 데이터베이스와는 달리 조인의 개념이 없다. 따라서 필터링하거나 그룹화하려는 열이 각 데이터 소스에 포함되도록 해야 한다.

데이터 소스에는 세 등급의 열이 있다. - 시간, 차원 및 매트릭스

Druid의 모든 것은 시간에 의해 결정된다. 각 데이터 소스에는 기본 파티션 메커니즘인 타임스탬프 열이 있다. 치수는 필터링, 쿼리 또는 그룹화에 사용할 수 있는 값이다. 매트릭스는 집계할 수 있는 값이며 거의 항상 숫자다.

조인을 기능을 제거하고, 데이터가 타임스탬프로에 의해 결정된다고 가정함으로써, Druid는 데이터 소스를 수조 개의 행으로 확장하고 10밀리초 내에 쿼리 응답 시간을 달성할 수 있도록 데이터를 저장, 배포 및 쿼리하는 방법에 있어 몇 가지 최적화 할 수 있다.

이러한 수준의 확장성을 달성하기 위해 Druid는 저장된 데이터를 시간 청크로 나눈다. 시간 청크의 지속시간은 구성 가능하다. 데이터 및 사용 사례에 따라 적절한 기간을 선택할 수 있다. 우리의 데이터와 사용 사례에서, 우리는 1시간 분량의 청크를 사용한다. 시간 청크 내의 데이터는 하나 이상의 세그먼트에 저장된다. 각 세그먼트는 타임스탬프 키 열에 의해 결정된 대로 시간 청크 내에 속하는 모든 데이터 행을 보관한다. 세그먼트 크기는 행 수에 상한 또는 세그먼트 파일의 총 크기가 되도록 구성할 수 있다.



데이터를 쿼리할 때 Druid는 쿼리 범위 내의 시간 청크에 세그먼트를 보유한 클러스터의 모든 노드로 쿼리를 전송한다. 각 노드는 중간 결과를 쿼리 브로커 노드로 다시 보내기 전에 보유하고 있는 데이터에서 쿼리를 병렬로 처리한다. 브로커는 최종 병합 및 집계를 수행한 후 결과 집합을 클라이언트로 다시 전송한다.


Ingestion

이 데이터베이스에 대한 삽입은 실시간으로 이루어진다. 개별 레코드가 데이터 소스에 삽입되는 대신 이벤트(우리의 경우 매트릭스)를 Kafka 스트림에서 읽는다. 우리는 데이터 소스당 1개의 주제를 사용한다. 드루이드 내에서는 실시간 노드(중간 관리자)에 분산되어 있는 복수의 인덱싱 작업자를 생성하는 Kafka Indexing Tasks을 사용한다.

이러한 인덱서들은 각각 주제를 구독하고 스트림에서 발생한 자신의 이벤트를 읽는다. 인덱서는 수집 사양에 따라 이벤트 메시지에서 값을 추출하고 생성된 행을 메모리에 누적한다. 행이 생성되자마자 쿼리할 수 있다. 인덱서가 여전히 세그먼트를 채우는 시간 청크로 도착하는 쿼리는 인덱서 자체에서 제공될 것이다. 인덱싱 태스크는 기본적으로 2개의 작업, 즉 수집 및 필드링 쿼리를 수행하고 있으므로 쿼리 작업을보다 최적화 된 방식으로 오프로드하려면 적시에 데이터를 히스토리 노드로 내보내는 것이 중요하다.

Druid는 데이터를 수집할 때 데이터를 롤업하여 저장해야 하는 원시 데이터의 양을 최소화할 수 있다. 롤업은 요약 또는 사전 집계의 한 형태다. 경우에 따라 데이터를 롤업하여 저장해야 하는 데이터의 크기를 획기적으로 줄일 수 있으며, 잠재적으로 규모별 행 수를 줄일 수 있다. 그러나 이러한 스토리지 절감은 비용이 발생한다. 즉, 개별 이벤트를 쿼리할 수 있는 기능이 손실되고 미리 정의된 쿼리 단위로만 쿼리할 수 있다. 우리는 1분 쿼리 단위를 선택했다.

수집 중에, 행의 차원이 동일하고 타임스탬프가 동일한 분(우리의 쿼리 단위) 내에 있으면 행이 롤업된다. 이것은 행이 모든 메트릭 값을 합산하고 카운터를 증분함으로써 결합됨을 의미하므로 우리는 이 행의 값에 얼마나 많은 이벤트가 기여했는지 알 수 있다. 이러한 형태의 롤업은 데이터베이스의 행 수를 크게 줄일 수 있으므로 작업 및 집계할 행이 적기 때문에 쿼리 속도를 높일 수 있다.

누적된 행의 수가 특정 임계값에 도달하거나 세그먼트가 너무 오랫동안 열려 있으면 해당 행은 세그먼트 파일에 기록되고 딥 스토리지로 오프로드된다. 그런 다음, 인덱서는 코디네이터에게 세그먼트가 준비되었음을 알려 코디네이터가 하나 이상의 히스토리 노드를 로드하도록 한다. 세그먼트가 히스토리 노드에 성공적으로 로드되면 인덱서에서 언로드되고 해당 데이터를 대상으로 하는 쿼리는 이제 히스토리 노드에서 제공된다.

Data Management

치수의 카디널리티가 증가함에 따라 같은 분 내에 동일한 이벤트가 발생할 가능성은 감소한다. 카디널리티를 관리하고, 따라서 롤업하는 것은 좋은 쿼리 성능을 얻는 강력한 수단이다.

우리가 필요로 하는 수집 속도를 달성하기 위해, 우리는 많은 인덱서 인스턴스를 실행한다. 인덱싱 작업에서 동일한 행을 결합하는 롤업에서도 모두 동일한 작업 인스턴스에서 동일한 행을 얻을 가능성은 매우 낮다. 이를 극복하고 가능한 최상의 롤업 달성을 위해, 우리는 특정 시간 청크에 대한 모든 세그먼트가 히스토리 노드에 전달된 후 태스크가

실행되도록 작업을 스케줄한다.

이 스케줄된 압축 태스크는 딥 스토리지에서 시간 청크에 대한 모든 세그먼트를 가져와 맵/삭감 작업을 통해 세그먼트를 재생성하고 완벽한 롤업을 달성한다. 그런 다음 새 세그먼트는 덜 롤업된 원래 세그먼트를 교체하고 대체하는 히스토리 노드에 의해 로드되고 발행된다. 우리는 이 추가적인 압축 작업을 함으로써 행 수가 약 2배 향상됐다.

주어진 시간 청크에 대한 모든 이벤트가 언제 수신되었는지 아는 것은 사소한 일이 아니다. Kafka 토픽에 대한 늦게 도착한 데이터가 있을 수도 있고, 인덱서들이 세그먼트를 히스토 노드로 넘겨주는 데 시간이 걸릴 수도 있다. 이 문제를 해결하기 위해 우리는 몇 가지 제한을 적용하고 압축을 실행하기 전에 점검을 수행한다.

첫째로, 우리는 매우 늦게 도착한 모든 데이터를 삭제한다. 우리는 이것이 너무 오래되어서 실시간 시스템에 유용하지 않다고 생각한다. 이것은 데이터가 얼마나 늦을 수 있는지에 대한 제한을 정한다. 둘째로, 압축 작업은 지연과 함께 스케줄링되며, 이는 세그먼트가 정상적인 흐름으로 히스토리 노드로 오프로드될 수 있는 충분한 시간을 제공한다. 마지막으로, 주어진 시간 청크에 대해 스케줄링된 압축 작업이 시작되면, 세그먼트 메타데이터를 쿼리하여 아직 작성 중이거나 전달 중인 관련 세그먼트가 있는지 확인하고 있다면 몇 분 후에 다시 시도한다. 이렇게 하면 모든 데이터가 압축 작업에 의해 처리된다.

이런 조치들이 없다면, 때때로 데이터가 손실될 수 있다. 압축이 시작되었을 때 여전히 쓰여지고 있던 세그먼트는 상위 버전을 가진 새로 압축된 세그먼트로 덮어쓰게 될 것이다. 이로 인해 아직 전달이 완료되지 않은 세그먼트에 포함된 데이터가 효과적으로 삭제된다.

Querying

Druid는 Druid SQL 및 네이티브 쿼리라는 두 가지 쿼리 언어를 지원한다. 후드 아래에서 Druid SQL 쿼리는 네이티브 쿼리로 변환된다. 네이티브 쿼리는 JSON으로 REST 엔드포인트에 제출되며 우리가 사용하는 주요 메커니즘이다.

클러스터에 대한 대부분의 쿼리는 대시보드 및 알림 시스템과 같은 사용자 정의 내부 도구에 의해 생성된다. 이러한 시스템은 원래 내부적으로 개발된 오픈 소스의 시계열 데이터베이스인 Atlas와 함께 작동하도록 설계되었다. 이와 같이, 이러한 도구는 아틀라스 스택 쿼리 언어를 사용한다.

Druid의 쿼리 채택을 가속화하고, 기존 도구를 재사용 가능하게 하기 위해, Atlas 쿼리를 취하고, Druid 쿼리로 다시 쓰고, 쿼리를 발행하고, 결과를 Atlas의 결과로 재포맷하는 변환 계층을 추가했다. 이 추상화 계층은 기존 도구를 그대로 사용할 수 있게 하고 사용자가 Druid 데이터저장소의 데이터에 액세스할 수 있도록 추가 학습 곡선을 만들지 않는다.

Tuning for Scale

클러스터 노드의 구성을 조정하는 동안, 우리는 각 주어진 구성에 대한 응답 시간과 쿼리 처리량의 벤치마크를 얻기 위해 반복 가능하고 예측 가능한 일련의 쿼리를 높은 속도로 실행했다. 쿼리는 쿼리 성능의 개선 또는 퇴행을 확인하기 위해 클러스터의 일부를 분리하도록 설계되었다.

예를 들어, 우리는 가장 최근의 데이터에 대한 표적 쿼리를 실행하여 중간 관리자만 쿼리를 받았다. 마찬가지로 더 긴 기간 동안 오래된 데이터만 캐싱 구성을 테스트하기 위해 히스토리 노드만 쿼리할 수 있다. 그리고 매우 높은 카디널리티 차원에 의해 그룹화된 쿼리로 결과 병합이 어떻게 영향을 받았는지 다시 한 번 확인한다. 우리는 쿼리 성능에 만족할 때까지 이러한 벤치마크를 계속 수정하고 실행했다.

이러한 테스트에서 우리는 버퍼 크기, 스레드 수, 쿼리 큐 길이 및 쿼리 캐시에 할당된 메모리를 조정하는 것이 쿼리 성능에 효과적인 영향을 미친다는 것을 발견했다. 그러나 잘 정리되지 않은 세그먼트를 가져다가 완벽한 롤업으로 다시 압축하는 작업의 도입은 쿼리 성능에 더 큰 영향을 미친다.

우리는 또한 히스토리 노드에서 캐시를 활성화하는 것이 매우 유익했던 반면, 브로커 노드에서 캐시를 활성화하는 것은 훨씬 덜 유익하다는 것을 발견했다. 브로커에게 캐시를 사용하지 않을 정도로 말이다. 그것은 우리의 사용 사례 때문일 수도 있지만, 우리가 하는 거의 모든 쿼리는 브로커의 캐시를 놓친다. 왜냐하면 쿼리는 거의 가장 최신의 데이터를 포함하기 때문인데, 그것은 항상 도착하는 것처럼 어떤 캐시에도 들어 있지 않을 것이기 때문이다.

Summary

우리의 사용 사례와 데이터 속도를 위해 튜닝과 조정을 여러 번 반복한 끝에, Druid는 우리가 처음에 기대했던 것만큼 능력이 있다는 것이 증명되었다.

우리는 능력 있고 사용 가능한 시스템에 도달할 수 있었지만, 아직 해야 할 일이 더 많다. 쿼리의 수와 복잡성과 마찬가지로 우리의 수집과 부피는 끊임없이 증가하고 있다. 이 상세한 데이터의 가치는 더 많은 팀에 의해 실현되기 때문에, 우리는 종종 더 많은 측정 기준과 치수를 추가하여 시스템이 더 열심히 작동하도록 한다. 우리는 쿼리 성능을 조정하기 위해 계속해서 감시하고 조율해야 한다.

우리는 현재 초당 200만 건 이상의 이벤트를 수집하고 있으며, 사용자들이 서비스를 어떻게 경험하고 있는지에 대한 자세한 정보를 얻기 위해 1조 5천억 건 이상의 행을 쿼리를 조회하고 있다. 이 모든 것이 지속적인 혁신을 가능하게 하는 동시에 고품질의 Netflix 환경을 유지하는 데 도움이 된다.

번역 - 핀인사이트 인턴연구원 김영현

원문 보러가기 > https://netflixtechblog.com/how-netflix-uses-druid-for-real-time-insights-to-ensure-a-high-quality-experience-19e1e8568d06

전체 0

전체 572
번호 썸네일 제목 작성자 작성일 추천 조회
공지사항 [공지사항] 코로나바이러스감영증-19 예방을 위한 강의장 방역 안내
[공지사항] 코로나바이러스감영증-19 예방을 위한 강의장 방역 안내
[공지사항] 코로나바이러스감영증-19 예방을 위한 강의장 방역 안내
인사이트캠퍼스 | 2020.03.05 | 추천 0 | 조회 758
인사이트캠퍼스 2020.03.05 0 758
공지사항
비밀글 파이썬으로 배우는 블록체인 구조와 이론 (위키북스)
finweb | 2019.07.05 | 추천 0 | 조회 14
finweb 2019.07.05 0 14
569 딥러닝을 활용한 금융 시계열 분석 - 2
딥러닝을 활용한 금융 시계열 분석 - 2
딥러닝을 활용한 금융 시계열 분석 - 2
인사이트캠퍼스 | 2020.05.25 | 추천 0 | 조회 35
인사이트캠퍼스 2020.05.25 0 35
568 퀀텀 컴퓨팅의 실용화 방안
퀀텀 컴퓨팅의 실용화 방안
퀀텀 컴퓨팅의 실용화 방안
인사이트캠퍼스 | 2020.05.18 | 추천 0 | 조회 90
인사이트캠퍼스 2020.05.18 0 90
567 딥러닝을 활용한 금융 시계열 분석 - 1
딥러닝을 활용한 금융 시계열 분석 - 1
딥러닝을 활용한 금융 시계열 분석 - 1
인사이트캠퍼스 | 2020.05.18 | 추천 0 | 조회 41
인사이트캠퍼스 2020.05.18 0 41
566 동적 자산 배분과 유니버셜 포트폴리오
동적 자산 배분과 유니버셜 포트폴리오
동적 자산 배분과 유니버셜 포트폴리오
인사이트캠퍼스 | 2020.05.14 | 추천 0 | 조회 124
인사이트캠퍼스 2020.05.14 0 124
565 2020년 최고의 인공지능 및 머신러닝 소프트웨어 및 프레임워크 Top 20
2020년 최고의 인공지능 및 머신러닝 소프트웨어 및 프레임워크 Top 20
2020년 최고의 인공지능 및 머신러닝 소프트웨어 및 프레임워크 Top 20
인사이트캠퍼스 | 2020.05.13 | 추천 0 | 조회 135
인사이트캠퍼스 2020.05.13 0 135
564 자주 묻는 머신러닝 인터뷰 질문 및 답변 50선
자주 묻는 머신러닝 인터뷰 질문 및 답변 50선
자주 묻는 머신러닝 인터뷰 질문 및 답변 50선
인사이트캠퍼스 | 2020.05.11 | 추천 0 | 조회 153
인사이트캠퍼스 2020.05.11 0 153
563 좋은 vs 나쁜 액티브 펀드 관리 : 3 가지 지표
좋은 vs 나쁜 액티브 펀드 관리 : 3 가지 지표
좋은 vs 나쁜 액티브 펀드 관리 : 3 가지 지표
인사이트캠퍼스 | 2020.05.06 | 추천 0 | 조회 131
인사이트캠퍼스 2020.05.06 0 131
562 그녀는 돈의 보스: 여성 온라인 투자의 4대 트렌드
그녀는 돈의 보스: 여성 온라인 투자의 4대 트렌드
그녀는 돈의 보스: 여성 온라인 투자의 4대 트렌드
인사이트캠퍼스 | 2020.05.06 | 추천 0 | 조회 113
인사이트캠퍼스 2020.05.06 0 113
561 변동성 측정의 이해
변동성 측정의 이해
변동성 측정의 이해
인사이트캠퍼스 | 2020.05.06 | 추천 0 | 조회 137
인사이트캠퍼스 2020.05.06 0 137
560 새로운 재료를 찾는 데 있어 최적화를 촉진하는 신경망
새로운 재료를 찾는 데 있어 최적화를 촉진하는 신경망
새로운 재료를 찾는 데 있어 최적화를 촉진하는 신경망
인사이트캠퍼스 | 2020.04.29 | 추천 0 | 조회 116
인사이트캠퍼스 2020.04.29 0 116
559 2020년 멋진 오픈 소스 소프트웨어 5개
2020년 멋진 오픈 소스 소프트웨어 5개
2020년 멋진 오픈 소스 소프트웨어 5개
인사이트캠퍼스 | 2020.04.29 | 추천 0 | 조회 133
인사이트캠퍼스 2020.04.29 0 133
558 AI가 속아 넘어갈 수 있을까?
AI가 속아 넘어갈 수 있을까?
AI가 속아 넘어갈 수 있을까?
인사이트캠퍼스 | 2020.04.29 | 추천 0 | 조회 74
인사이트캠퍼스 2020.04.29 0 74
557 블록체인이 채택되면서 협업이 새로운 경쟁인가?
블록체인이 채택되면서 협업이 새로운 경쟁인가?
블록체인이 채택되면서 협업이 새로운 경쟁인가?
인사이트캠퍼스 | 2020.04.29 | 추천 0 | 조회 84
인사이트캠퍼스 2020.04.29 0 84
556 간단한 전자 상거래 웹사이트 스크래핑
간단한 전자 상거래 웹사이트 스크래핑
간단한 전자 상거래 웹사이트 스크래핑
인사이트캠퍼스 | 2020.04.29 | 추천 0 | 조회 118
인사이트캠퍼스 2020.04.29 0 118
555 디지털 화폐 – CBDC를 발행하는 데에 무엇이 필요한가?
디지털 화폐 – CBDC를 발행하는 데에 무엇이 필요한가?
디지털 화폐 – CBDC를 발행하는 데에 무엇이 필요한가?
인사이트캠퍼스 | 2020.04.27 | 추천 0 | 조회 152
인사이트캠퍼스 2020.04.27 0 152
554 2020년 가장 해 볼만한 인공지능 및 머신러닝 프로젝트 20선
2020년 가장 해 볼만한 인공지능 및 머신러닝 프로젝트 20선
2020년 가장 해 볼만한 인공지능 및 머신러닝 프로젝트 20선
인사이트캠퍼스 | 2020.04.20 | 추천 0 | 조회 370
인사이트캠퍼스 2020.04.20 0 370
553 Netflix가 Druid를 실시간 이해에 사용하여 고품질 체험을 보장하는 방법
Netflix가 Druid를 실시간 이해에 사용하여 고품질 체험을 보장하는 방법
Netflix가 Druid를 실시간 이해에 사용하여 고품질 체험을 보장하는 방법
인사이트캠퍼스 | 2020.04.13 | 추천 0 | 조회 85
인사이트캠퍼스 2020.04.13 0 85
552 미디어 파이프를 사용한 모바일 장치의 실시간 3D 객체 탐지
미디어 파이프를 사용한 모바일 장치의 실시간 3D 객체 탐지
미디어 파이프를 사용한 모바일 장치의 실시간 3D 객체 탐지
인사이트캠퍼스 | 2020.04.09 | 추천 0 | 조회 61
인사이트캠퍼스 2020.04.09 0 61
551 Open Images V6 - 현지화된 서술 특성 제공
Open Images V6 - 현지화된 서술 특성 제공
Open Images V6 - 현지화된 서술 특성 제공
인사이트캠퍼스 | 2020.04.09 | 추천 0 | 조회 60
인사이트캠퍼스 2020.04.09 0 60
550 외형 변경, 자유 로밍 소프트 로봇 제작
외형 변경, 자유 로밍 소프트 로봇 제작
외형 변경, 자유 로밍 소프트 로봇 제작
인사이트캠퍼스 | 2020.04.09 | 추천 0 | 조회 47
인사이트캠퍼스 2020.04.09 0 47