레이블이 Database인 게시물을 표시합니다. 모든 게시물 표시
레이블이 Database인 게시물을 표시합니다. 모든 게시물 표시

2/12/2019

Netflix 미디어 데이터베이스

Netflix의 목표는 전 세계 수백만 회원의 재생 시작 시간을 최소화하는 것이다. 이를 위해서 ISO BMFF의 Header 크기에 대한 통계량(최소값, 최대값, 중간값, 평균값등)을 수집해야 한다.

Netflix의 Transcoding Pipeline은 방대한 콘텐츠 카탈로그를 서비스하며 모든 콘텐츠에 대해 다양한 코덱+품질 조합을 생성한다.

과거에는 비트 스트림 헤더 정보를 클롤링하는 일회성 스크립트를 작성해야만 데이터를 분석할 수 있었고 이러한 접근 방식에는 확장성이 없었다.

본 글에서는 Netflix의 Media Data Base 시스템에 대해서 소개하고자 한다.

왜 미디어 전용 데이터 베이스가 필요한가?

의미있는 개인화 및 효율적인 스트리밍은 최종 사용자가 서비스를 정의하는 주요 요소이다.

이러한 경험을 제공하기 위해서는 복잡한 비즈니스 워크 플로우가 필요하다.


위 그림처럼 아트워크상의 이미지 및 타이틀은 사용자가 관련 영화를 찾는데 도움이 된다. Netflix에서는 콘텐츠를 처리하는 단계에서 디지털 상품 Asset을 합성하는데 도움이되는 시스템을 개발해야 하는 상황이 있었다. 예를 들어서 소스 비디오 Asset에서 자동으로 추출 된 의미 있는 원시적인 이미지 및 비디오 클립을 제공하는 부분이다. 이는 콘텐츠에서 매력적인 디지털 미디어 자산을 창출하는 출발점이 될 수 있다고 생각했다. 이런 기능을 제공하게되면 사용자가 관련 프로그램 및 영화를 찾는데 큰 도움이 될 수 있다.

위의 그림처럼 콘텐츠 추천 시스템은 최종 사용자의 취향에 맞게 개인화 된 항목을 보여준다. Netflix 카탈로그에 있는 콘텐츠의 작고 효과적인 기능 표현은 매우 중요하다. 이러한 표현은 미디어 파일(오디오, 텍스트, 비디오)과 메타 데이터(장르 태그, 개요)를 기반으로 학습하는 기계 학습 모델을 구축하여 얻을 수 있다.

마지막으로 Netflix에서 수집 된 콘텐츠의 품질에 대한 높은 기준을 유지하는 것이 최종 사용자의 경험을 위해서는 필수적이다. 아래의 이미지는 이런 사례중 하나를 보여준다.

아래의 이미지는 Western Classical 장르의 비디오 프레임에 해당되고 이 경우 카메라가 동영상에 표시되고 있다. 카메라의 존재를 감지하는 자동화 된 분석 시스템을 갖는 것은 매우 바람직하다.


다음 그림의 경우, 자막은 영상에서 표시한 텍스트 위에 놓여지면 읽기가 어려울 수 있다. 자막의 타이밍 및 위치에 대한 지식과 함께 영상내 텍스트 검출 알고리즘을 사용하여 이 문제를 자동으로 해결 할 수 있다.


위와같은 분석 중 많은 부분을 계산하기 위한 비용은 매우 비싸다. 서로 다른 유즈 케이스를 처리할때 동일한 계산을 반복하는것도 매우 비효율적이기 떄문에 미디어의 타임라인과 관련된 모든 분석을 위한 보편적인 저장소 역할을 할 수 있는 데이터 시스템이 필요했다. 즉, 미디어 데이터베이스가 필요하다.

미디어 데이터베이스의 특징

미디어 데이터베이스는 다양한 형식의 미디어에 대한 분석 데이터가 들어있다. 여기에는 오디오, 비디오, 이미지 및 텍스트가 포함된다. 미디어 타임라인에서 임의의 쿼리를 처리할 때 사용된다. 예를 들어서 오디오 트랙의 타임라인에서 음악이 포함된 부분에 대한 시간 간격 또는 텍스트가 포함된 비디오의 비디오 프레임 목록 또는 자막 파일의 시간 간격 집합이 그것이다. 다음과 같은 사항이 미디어 데이터베이스의 중요한 특징이다.

  1. 구조화 된 데이터와의 유사성: 스키마가 있는 데이터는 기계 기반 처리가 가능하기에 분석이 가능하다. Netflix의 경우 스키마를 통해 데이터 검색 및 마이닝 기회를 제공하는 데이터를 색인할 수 있다.
  2. 효율적인 미디어 타임라인 모델링: 비디오 프레임에서 이벤트 기반에 이르기까지 다양한 유형의 미디어 타임라인 데이터를 서비스하는 기능은 미디어 데이터베이스의 기본 특성이다.
  3. 시공간 쿼리 기능: 미디어 데이터베이스는 미디어 데이터의 공간적(e.g. 이미지의 일부) 특성외에 시간적(e.g. 오디오 트랙의 시간 간격) 특성을 기본적으로 지원하며 이러한 부분에서 꽤 괜찮은 쿼리 기능을 제공한다. 예를 들어서, 미디어 데이터베이스를 사용하면 비디오 프레임내의 연속 시퀀스에 비디오 프레임의 특정 공간 영역(e.g. 왼쪽 상단 모서리)에 텍스트가 포함되어 있는지 쉽게 확인 할 수 있다. 이러한 쿼리를 비디오에 있는 텍스트와 자막 사이의 충돌을 탐지 하는데 유용하다.
  4. 다중 소유: 잘 설계된 미디어 데이터베이스는 복수의 어플리케이션으로부터 복수의 분석 데이터를 지원하기 위한 플랫폼으로써 사용될 수 있다. 이 부분이 구조화되어 있으면 임의의 데이터를 저장할 수 있고 해당 데이터가 미디어 리소스의 특정 시간 간격에도 연관 될 수 있을 경우에는 효율적인 쿼리 기능에 활용 될 수 있다.
  5. 확장성: 확장 가능한 마이크로 서비스 기반 모델은 필수적이다. 시스템은 다양한 시나리오에서 가용성 및 일관선과 관련된 문제를 해결해야 한다.

Netflix 미디어 데이터베이스 소개

Netflix는 위에서 소개된 내용을 통해 미디어 타임라인의 시공간 쿼리에 대규모로 응답이 가능한 미디어 타임라인과 관련된 분석을 위한 NMDB를 만들었다. Netflix 카탈로고는 다양한 형식의 많은 미디어 자산으로 구성되고 정적 자산의 경우 이미지가 포함되며 재생 가능한 자산의 경우 오디오, 텍스트 및 비디오가 포함된다. 위에서 설명한 것처럼 수많은 비즈니스 어플리케이션이 이러한 자산과 관련된 정보를 얻을 수 있다. NMDB의 주요 목표는 어플리케이션에서 필요한 필수 데이터를 제공하는 것이다. NMDB는 다양한 Netflix 미디어 처리 시스템의 백본을 형성하는 데이터 시스템인 것이다.

References

  • https://medium.com/netflix-techblog/the-netflix-media-database-nmdb-9bf8e6d0944d


9/17/2018

MSA(마이크로 서비스 아키텍처)에서 단일 데이터베이스를 분리해야 하는 이유

기존 Monolithic 서비스를 분해하여 Micro Service 아키텍처를 사용할 경우 데이터베이스에 중점을 두는 것이 중요합니다. 어플리케이션과 연계된 데이터베이스를 여러개의 작은 데이터베이스로 분할하는 확실한 전략이 필요합니다.

즉, 기존에 사용하던 Monolithic의 통합 데이터베이스를 분리해야 합니다.

마이크로 서비스 아키텍처는 각 마이크로 서비스가 자체 도메인 데이터가 있는 별도의 데이터베이스를 가지도록 설계해야 합니다. 이렇게 해야 마이크로 서비스를 독립적으로 배포하거나 확장 할 수 있기 때문입니다.

기존 Monolithic 서비스에는 단일 데이터베이스가 있고 데이터는 다른 컴포넌트간에 공유됩니다. 데이터가 단일 저장소에 관리되기 때문에 개발이 더 간단하다는 장점이 있지만, 데이터베이스 설계에는 여러 가지 문제가 존재합니다.


단일 데이터베이스 설계의 문제점

위의 그림처럼 Monolithic 데이터베이스를 사용하는 설계는 서비스 변경 사항을 독립적으로 배포 할 수 없도록 상호간의 밀접한 결합 방식을 통해 무능력하게 만듭니다. 동일한 데이터베이스에 엑세스하는 여러 서비스가 있는 경우 모든 서비스간에 스키마 변경 사항을 조정해야 합니다.(어디서 어떤 데이터를 사용하는지 알 수 없기에…) 변경 사항을 적용 할 때 추가 작업에 대한 지연이 발생할 가능성이 큽니다.

단일 데이터베이스를 수평 확장 할 수 있는 옵션만 있기에 어플리케이션 단에서 개별 서비스를 확장하는 것이 어렵습니다.

어플리케이션 성능을 향상 시키고자 할때, 단일 데이터 베이스를 사용하면 여러 개의 큰 테이블을 조인하여 필요한 데이터를 가져와야 하기에 데이터 검색이 어려워집니다.

그리고 가장 큰 문제는 모든 어플리케이션에서 관계형 데이터베이스만 사용하도록 제한하게 됩니다. No-SQL 데이터베이스가 특정 서비스에 더 적합할 수 있어도 제한으로 인해 사용할 수 없게 됩니다.

마이크로서비스 아키텍처에서 데이터를 처리하는 방법

각 마이크로 서비스는 자체 데이터베이스를 가지고 있어야 하며 해당 마이크로 서비스와 관련된 데이터를 모두 포함해야 합니다. 이렇게 하면 각 서비스를 독립적으로 배포 할 수 있습니다. 각 서비스마다 독립적인 데이터베이스를 소유할 수 있게 됩니다.


마이크로 서비스의 설계 사상은 도메인 기반이어야 하며 한정된 컨텍스트를 가져야 합니다. 데이터 우선 접근 방식보다 코드 우선 접근 방식을 따라야 합니다. 따라서 가장 먼저 모델을 설계해야 합니다. 이 작업은 새로운 요구 사항이나 프로젝트를 시작할 때 데이터베이스 테이블을 먼저 설계하는 전통적인 사고 방식과는 근본적으로 다른 접근법입니다. 항상 비즈니스 모델의 무결성을 유지하려고 노력해야 합니다.

데이터베이스를 디자인할때 어플리케이션 기능을 살펴보고 관계형 스키마 필요 여부를 결정해야 합니다. No-SQL에 대한 가능성도 열어 두어야 합니다.


데이터베이스는 각 마이크로 서비스에 대해 개별적으로 취급되어야 합니다. 다른 마이크로 서비스는 다른 마이크로 서비스의 데이터베이스 내부에 저장된 데이터를 직접 수정할 수 없습니다.

아래의 그림에서 Order Service는 가격 데이터베이스를 직접 업데이트 할 수 없으며 해당 마이크로서비스의 API를 통해서만 엑세스가 가능해야 합니다. 이를 통해 서로 다른 서비스간에 일관성을 유지할 수 있습니다.


이벤트 중심 아키텍처는 서로 다른 서비스간에 데이터 일관성을 유지하는 패턴입니다. 작업을 완료하고 시스템 리소스를 차지하기 위해 ACID 트랜잭션을 기다리는 대신 메세지를 대기열로 Offload하여 어플리케이션을 보다 유용하고 효율적으로 만들 수 있도록 고려 해야 합니다. 이는 서비스 간의 Loosely Coupled를 제공합니다.

Queue에 대한 메시지를 이벤트로 처리 될 수 있으며 Pub-Sub 모델을 사용할 수 있습니다.


Monolithic에서 마이크로서비스로의 여정중 데이터베이스 변경 사항을 처리하는 것은 쉽지 않지만, 꼭! 넘어야 하는 부분입니다.

Source: https://dzone.com/articles/breaking-the-monolithic-database-in-your-microserv