6/15/2018

Netflix Metacat : 큰 데이터를 발견하고 의미있게 만들기

Written by Giljae Joo (주길재) in Metacat, Netflix with 댓글 없음

대부분 기업에는 다양한 데이터 형식으로 된 많은 양의 데이터와 수많은 데이터 소스가 있습니다. 그리고 데이터 소스로 부터 데이터를 분석합니다. Netflix의 데이터웨어하우스는 Amazon S3, Druid, Elasticsearch, Redshift, Snowflake 및 MySQL에 저장된 많은 양의 데이터 세트로 구성됩니다. 그리고 Spark, Presto, Pig/Hive를 이용하여 데이터 세트를 처리합니다.

Netflix는 다양한 데이터 소스를 “단일” 데이터웨어 하우스로 상호 운용하기 위해서 Metacat을 구축했습니다. 본 글에서는 데이터를 쉽게 찾고, 처리/관리하기 위한 메타 데이터 서비스인 Metacat을 만들게된 이유에 대해서 기술합니다.

목표

Netflix의 빅데이터 플랫폼의 핵심 아키텍처에는 세가지 주요 서비스가 존재합니다.

실행 서비스(Genie)
메타 데이터 서비스
이벤트 서비스

Netflix가 플랫폼을 구축할때, Pig를 ETL언어로 Hive를 ad-hoc 쿼리 언어로 채택했습니다. Pig는 기본적으로 메타 데이터 시스템을 가지고 있지 않기 때문에 두 시스템간에 상호 운용될 수 있는 시스템을 구축하는것이 이상적이었다고 합니다.

그래서 모든 데이터 저장소를 위한 federated metadata access layer 역할을 하는 Metacat이 탄생했습니다. Metacat은 세가지 주요 목표를 제공합니다.

메타 데이터 시스템 통합뷰
데이터 세트에 대한 메타데이터용 통합 API
데이터 세트에 대한 사용자 메타 데이터 저장소와 임의의 비즈니스

크고 분산된 형태의 데이터세트를 가지고 있는 다른 회사들도 Netflix와 비슷한 어려움을 겪었고 Apache “Atlas”, Twitter “Data Abstraction Layer”, Linkedin “WhereHows”는 유사한 문제를 해결하기 위해 작성되어졌습니다.

Metacat

Metacat은 다양한 데이터 저장소의 메타 데이터에 접근할 수 있는 Federation 서비스 입니다.

데이터 세트에 대한 비즈니스 및 사용자 정의 메타 데이터만 직접 저장하고 전체 검색을 위해 Elasticsearch에 데이터 세트에 대한 모든 정보를 기재합니다.

다음은 Metacat에서 제공하는 기능입니다.

데이터 추상화 및 상호 운용성
비즈니스 및 사용자 정의 메타 데이터 저장소
데이터 검색
데이터 변경에 대한 감사 및 알림
Hive 메타 스토어 최적화

데이터 추상화 및 상호 운용성

Pig, Spark, Presto/Hive와 같은 여러 Query 엔진은 Netflix에서 데이터 처리 및 사용하는데에 활용됩니다. 이 부분에 공통 추상화 계층을 도입함으로써 데이터 세트를 서로 다른 엔진에서 상호 교환적으로 접근 할 수 있습니다.

Hive 에서 데이터를 읽는 Pig 스크립트는 Pig 유형의 Hive열 테이블을 읽을 수 있습니다. 하나의 데이터 저장소에서 다른 데이터 저장소로의 데이터 이동을 위해 Metacat은 대상 테이블의 데이터 형식을 사용하여 대상 데이터 저장소에 새 테이블을 생성하는 것을 도와줌으로써 프로세스를 쉽게 만들 수 있습니다.

Metacat thrift 서비스는 Spark/Presto와의 손쉬운 통합을 위해 Hive Thread 인터페이스를 지원합니다. 이를 통해 모든 메타 데이터 변경 사항을 하나의 시스템으로 전달 할 수 있게됩니다.

비즈니스 및 사용자 정의 메타 데이터

Metacat은 스토리지에 데이터 세트에 대한 추가 비즈니스 및 사용자 정의 메타 데이터를 저장합니다. 현재의 비즈니스 메타 데이터를 사용하여 다른 유즈케이스와의 연결정보, 구성정보, 메트릭(Hive/S3 파티션 및 테이블) 및 테이블 TTL을 저장합니다.

사용자 정의 메타 데이터는 사용자가 자신의 용도로 설정 할 수 있는 자유 형식의 메타 데이터 입니다. 비즈니스 메타 데이터는 논리적/물리적 메타 데이터로 분류 됩니다. 테이블과 같은 논리적 구조에 대한 비즈니스 메타 데이터는 논리적 메타 데이터로 분류됩니다.

데이터 분류 및 ETL 처리 표준화를 위해 메타 데이터를 사용하게되고 테이블 소유자는 비즈니스 메타 데이터의 테이블에 대한 감사 정보를 제공 할 수 있습니다.테이블 속성(열 기본값과 유효성 검사 규칙)을 제공할 수 도 있습니다. 테이블이나 파티션에 저장된 실제 데이터에 대한 메타 데이터는 물리적 메타 데이터로 분류됩니다.

ETL처리는 작업 완료시 데이터에 대한 메트릭을 저장하고 나중에 유효성 검사에 사용됩니다. 동일한 측정 항목을 사용하여 데이터의 비용과 공간을 분석할 수 있습니다. 두 테이블이 동일한 위치를 가리킬 수 있는 경우에는 두 테이블이 동일한 실제 메타 데이터를 가질 수 있지만 다른 논리 메타 데이터도 가질 수 있기 때문에 논리적 vs 물리적 메타 데이터를 구별하는 것이 중요합니다.

데이터 검색

데이터 소비자로서 다양한 데이터 세트를 쉽게 찾고 발견 할 수 있어야 합니다. Metacat은 Elasticsearch에 스키마 메타 데이터 및 비즈니스/사용자 정의 메타 데이터를 게시하여 데이터웨어 하우스의 정보를 전체 텍스트로 검색할 수 있도록 해줍니다. 또한 Big Data Portal SQL 편집기에서 자동 제안 및 자동 완성 기능을 사용할 수 있습니다. 데이터 세트를 카탈로그로 구성하면 소비자가 정보를 탐색하는 데 도움이 됩니다. 태그는 조직 및 주제 영역을 기반으로 데이터를 분류하는데 사용되고 데이터 수명주기 관리를 위한 테이블 식별도 가능합니다.

데이터 변경 알림 및 감사

Metacat은 데이터 저장소의 중앙 게이트웨이로써 메타 데이터 변경 및 데이터 업데이트를 캡쳐합니다. 테이블 및 파티션 변경에 대한 푸시 알림 시스템도 제공합니다. 현재 Netflix는 이 매커니즘을 사용하여 분석을 위해 자체 데이터 파이프 라인(Keystone)에 이벤트를 게시하여 데이터 사용 및 추세를 분석 합니다. 또한 Amazon SNS에도 게시하고 있습니다. Netflix의 경우 데이터 기반 아키텍처를 이벤트 중심 아키텍처로 발전시키고 있습니다. SNS에 이벤트를 게시하면 데이터 플랫폼의 다른 시스템이 이러한 메터 데이터 또는 데이터 변경 사항에 적절하게 대응 할 수 있습니다. 예를 들어 테이블을 삭제하면 S3 웨어 하우스 관리자 서비스가 이벤트를 구독하고 S3의 데이터를 적절하게 정리할 수 있습니다.

Hive 메타스토어 최적화

RDS를 기반으로 하는 Hive 메타스토어는 부하가 높으면 성능이 떨어집니다. Netflix는 메타 스토어 API를 사용하여 파티션을 작성하고 읽는데 많은 문제를 발견했습니다. 그리고 해당 API를 더이상 사용하지 않기로 결정합니다. 대신 파티션 읽기 및 쓰기를 위해 백업된 RDS와 직접 연동하는 Hive Connection을 개선했습니다.

Next Steps

Netflix는 Metacat을 구축하는데 많은 노력을 기울였습니다. 그러나 더욱더 데이터웨어 하우스 환경을 향상시키기 위해 계속해서 작업해야 하는 몇 가지 추가 기능이 존재합니다.

테이블 히스토리를 제공하기 위한 스키마 및 메타 데이터 버전 관리 (특정 컬럼에 대한 메타 데이터 변경 사항을 추적하거나 시간 경과에 따라 테이블 크기 경향을 볼 수 있도록…)
테이블 액세스 빈도과 같은 메타 데이터를 Metacat에 집계하고 테이블의 중요도 순위를 지정하는데 활용하기 위한 데이터 계보 서비스
Elasticsearch 및 Kafka와 같은 데이터 저장소에 대한 지원 추가
Pluggble metadata validation — 비즈니스 및 사용자 정의 메타 데이터는 자유 형식이기에 메타 데이터의 무결성을 유지하려면 유효성 검증이 필요합니다. Metacat은 메타 데이터를 저장하기 전에 실행할 수 있는 유효성 검증 전략을 통합 할 수 있는 Pluggable metadata 아키텍처를 수립해야 합니다.

Sources:

https://github.com/Netflix/metacat
https://medium.com/netflix-techblog/metacat-making-big-data-discoverable-and-meaningful-at-netflix-56fb36a53520

대체 코드?

Written by Giljae Joo (주길재) in 생각 with 댓글 없음

동아비즈니스에서 흥미로운 주제를 발견했다. 바로 익숙하면서도 새로운 “대체 코드의 힘” 일반적인 사람들은 익숙하면서도 낯선 것에 끌린다.

너무 익숙하면 진부하다 여기고, 낯설기만 하면 이질감이 느껴지기 때문이다. 익숙하면서도 새로운 것을 만들려면 기존 시스템의 일부를 새로운 것으로 대체해야 한다. 아래는 이런 대체 코드에 대한 사례이다.

세계대전 이후 이탈리아는 물자가 부족한 상황이 지속되었고 수많은 가죽업체가 도산하는 열악한 상황이었다. 1947년 구찌는 가죽이 아닌 일본산 대나무를 손잡이로 활용한 Bamboo Bag을 내놓았다. 처음 뱀부백은 부드러운 돼지 피혁으로 제작한 가방에 대나무를 가열하여 구부린 손잡이를 부착한 작은 사이즈의 핸드백이었다. 대나무를 손잡이로 사용한 뱀부백은 가죽이 아닌 재료들을 핸드백에 어떻게 사용해야 하는지를 보여준 대표적인 사례라고 할 수 있다.

대체코드가 가장 많이 활용되는 분야는 광고이다. 사람들의 이목을 끌기 위해 “절반은 새롭고 절반은 익숙”해야 하는 원칙이 있기 때문이다. 위의 그림은 이제석씨가 디자인한 살충제 광고이다. 폭스바겐 비틀이 뒤집혀 있는 광고를 보면 살충제 성능이 엄청난 것처럼 보여진다. 일반적으로 흔히 말하는 창의성은 전부 새롭게 구성된 것이 아니다. “일부는 익숙하게 일부는 새롭게”라는 명제를 현실에 구현한 것이다.

다양한 장치를 지원하는 REST API에 대해 고찰

Written by Giljae Joo (주길재) in Netflix, REST with 댓글 없음

“REST API는 일반적인 요청을 처리하는데 뛰어나며, 다수의 개발자가 API를 쉽게 사용할 수 있도록 하는 일련의 규칙을 수립합니다.”

위 모델에서는 모든 사람들이 규칙을 알고 있으면 엄청나게 강력해집니다. API 공급자는 일련의 규칙을 설정하고 API 소비자는 원하는 것을 얻으려면 공급자가 설정한 규칙을 준수해야 합니다.

그러나 점점 규모가 커지고 사람들이 디지털 콘텐츠 및 서비스를 사용하는 방식이 늘어나고 있는 상황에서는 위 단일 모델 원칙이 부족할 수 있습니다.

Netflix의 예를 들어 볼까요?

Netflix는 현재 게임 콘솔, 모바일, TV, 블루레이 플레이어, Tablet, PC 및 비디오를 스트리밍 할 수 있는 거의 모든 디바이스(약 800개 이상)에서 사용할 수 있습니다.

디바이스의 폭이 넓어지기 때문에 전체의 기능 변화를 관리하기가 어려워지는 잠재적인 문제가 발생합니다.

예를 들어 Google의 REST API는 일반적인 방식으로 디바이스의 요청을 처리 할 수 있지만, 그 중 어느것도 디바이스에 맞춰서 최적화하지 않았습니다. REST API가 데이터를 세부적으로 표현하는 리소스에 초점을 맞추기 때문입니다.

각 디바이스간의 차이점은 여러가지 경우가 존재합니다. 다음은 1:1 맞춤형 모델의 경우 지원하기 어려운 다기종 디바이스 기기간의 차이입니다.

서로 다른 디바이스는 서로 다른 메모리 용량을 가지고 있음
일부 디바이스는 고유하거나 독점적인 형식 혹은 전달 방법이 필요할 수 있음
일부 디바이스는 더 Depth가 깊은 형태의 계층적 문서 모델로 성능이 향상될 수 있음
디바이스마다 다른 화면 크기를 지니고 있기에 어떤 데이터가 필요한지에 영향을 줄 수 있음
서로 다른 디바이스는 서로 다른 사용자 상호 작용 모델을 허용하며 메타 데이터 필드, 전달 방법, 상호 작용 모델등에 영향을 줄 수 있음

iPhone과 TV의 차이점과 다른 사용자 경험을 제공하는 방법과 TV에 투영되는 XBox와 Wii는 하드웨어 제약 조건과 상호 작용하는 방식이 서로 다르고 제약 조건을 지원하기 위해 서로 다른 API가 필요할 수 있습니다. 800가지가 넘는 다양한 디바이스 유형을 고려할 경우 분산해서 제공하는 방안이 압도적입니다. 그리고 더 많은 제조사가 디바이스를 계속 혁신함에 따라 편차가 커질 여지가 존재합니다.

이러한 기기의 차이 때문에 Netflix UI팀은 각 기기별 사용자에게 더 나은 서비스를 제공하기 위해 REST API를 Redesign하기로 결정 합니다.

위에서 언급한 것처럼 기존의 OSFA(One-size-fits-all) REST API 접근 방식에 제한 사항이 존재합니다. Netflix의 스트리밍 서비스는 800개 이상의 서로 다른 기기에서 사용할 수 있으며, 거의 모든 기기가 비공개 API로 부터 콘텐츠를 수신합니다. Netflix의 경우 OSFA API를 사용하여 다양한 기기를 지원하는 것은 성공했지만 API팀, UI팀 또는 Netflix 스트리밍 고객에게 적합하지 않음을 깨달았습니다.

새롭게 디자인 된 API의 핵심은 800개 이상의 기기 유형에서 다양한 차이가 있다는 사실을 수용한 점입니다. Netflix가 2008년 부터 사용한 REST API를 포함한 대부분의 API는 일반적인 방식으로 기기의 요청을 처리하여 서버쪽 구현을 보다 효율적으로 만듭니다. 이 접근법에는 충분한 이유가 있는데, API 팀이 OSFA API를 제공하면 모든 사람이 따라야 하는 규칙을 설정하기 때문에 광범위한 API사용자와 확고한 관계를 유지할 수 있기 때문입니다.

이런 규칙은 효과적이긴 하지만 OSFA의 문제점은 API 소비자가 아닌 API 제공업체가 편리하게 사용할 수 있다는 점입니다. 따라서 OSFA는 이러한 기기의 차이점을 무시합니다.

Netflix의 새로운 모델은 OSFA 패러다임을 없애고, 각 기기의 차이점을 동등하게 지원하면서 포용하도록 설계되었습니다. 이를 위해서 API 개발 플랫폼을 통해 각 UI팀은 사용자 정의를 만들 수 있습니다. 이렇게 하므로써, Request/Response 모델은 각 팀의 UI에 맞게 최적화 될 수 있습니다.

많은 OSFA 구현에서 API는 아래의 형태로 제공됩니다.

위의 그림은 Netflix 환경을 시작하기 위해 PS3에 필요한 여러 요청을 대략적으로 보여줍니다. 다른 UI는 OSFA REST API에 대해 유사한 상호 작용 세트를 갖게 됩니다. 이는 API에서 모두 동일한 규칙을 준수해야 한다는 것을 의미합니다. REST API내부에는 콘텐츠 수집, 준비 및 전달을 수행하는 엔진이 존재합니다.

Google의 새 API는 OSFA API 모델에서 전체 API의 관리 기능을 손상시키지 않으면서 세분화 맞춤 설정이 가능하게 하는 모델로 이전 되었습니다. 다음 그림은 수정된 아키텍처를 보여줍니다.

이 새로운 모델에서 UI는 사용자 요청에 대해 단일 지점을 만듭니다. 그 이후 사용자 요청에 대해 구문을 분석하고 Java API를 호출하는 처리기로 하부 API 제공 서비스를 호출합니다.

“클라이언트 코드”는 디바이스내에 있는 모든 코드를 의미합니다.

“서버 코드”는 서버에 존재하는 코드로 정의됩니다.

이 의미는 REST API의 경우에 경계를 나누는 기준이며, API 소비자와 API 제공자를 의미합니다.

Netflix의 경우 서버 코드에 많은 부분을 밀어 넣고 있습니다. 디바이스의 모든 코드는 클라이언트 코드로 간주되지만, 일부 클라이언트 코드는 서버에 위치합니다.

클라이언트 코드는 서버에 있는 전용 클라이언트 어댑터에 요청을 하게 됩니다.어댑터는 필요없는 필드 제거, 오류 처리 및 재시도, 응답 형식, 헤더 필드등의 정보를 처리합니다. 이 모든 처리는 특정 UI에 대한 사용자 정의입니다. 아래의 그림을 확인하세요.

위의 변화는 두 가지 측면이 있습니다.

첫째, 네트워크를 통해 진행되는 Request를 서버에서 처리하기 때문에 디바이스와 서버간의 효율적인 상호 작용이 가능합니다. 네트워크 비용은 트랜잭션 중 가장 비싸기 때문에 네트워크 요청 수를 줄이면 성능이 향상됩니다.

둘째, 최적화 된 어댑터를 구축해서 클라이언트 요청을 최종적으로 처리합니다.

이 접근 방식의 단점은 A/B 테스트 및 Multiple 테스트를 위해 더 많은 기기를 추가하고

더 많은 UI를 추가 할 경우 모든 개별 프로파일을 지원하는데 필요한 무수한 어댑터가 존재한다는 점입니다.

위에서 언급한 것처럼 일부 클라이언트 코드를 서버로 보내고 API를 제공하면 UI팀이 (API팀의 개입없이) 자체 어댑터 코드를 만들고 수정할 수 있으므로 개발 과정에서 훨씬 더 민첩할 수 있습니다. 이 들은 더 이상 규칙을 지시하거나 개발을 위한 병목이 되는 서버팀에 구속되지 않습니다. API 혁신은 UI팀에게 달려있게 됩니다.

UI팀이 HTML5, CSS3, JavaScript등의 기술에 더욱 숙련되어 있다는 점이 단점이긴 합니다.

이제는 서버측 기술을 배워야 합니다. 또 다른 문제는 UI팀이 서버 측 어댑터를 구현하기 때문에 리소스 집약적인 무한 루프 또는 기타 프로세스를 통해 API 서버를 중단시킬 가능성이 존재한다는 점입니다. 이를 보완하기 위해서 Netflix의 경우 Scrubbing Engine을 개발 하고 있습니다.

즉, OSFA 세계에서 장치의 코드는 서버를 쉽게 DDOS할 수 있으며, 서버에서 실행되는 경우 잠재적으로 더 큰 문제를 유발할 수 있습니다.

PS3와 같은 기기는 네트워크를 통해 홈화면을 Load하는 단일 요청을 합니다. (이 코드는 PS3 UI팀에서 작성하고 지원)
Groovy Adapter가 PS3 요청을 받고 구문 분석을 합니다. (PS3 UI 팀)
Adapater는 하나의 요청을 Java API로 매핑 (PS3 UI 팀)
각 Java API는 요청에 필요한 콘텐츠를 제공하기 위해 종속 서비스를 호출
Java API에서 종속 서비스 사용이 불가능하거나 4xx, 5xx를 반환하면 Java API는 Adapter(API팀)에 폴백 및 오류 코드를 반환합니다.
Java API 트랜잭션이 성공적으로 완료되면 (API팀) 콘텐츠를 Adapter로 반환 합니다.
Adapter가 콘텐츠를 조작하고, 원하는 요소를 가져오거나 잘라내고 오류를 처리 (PS3 UI 팀)
Adapter는 PS3 홈 화면에 필요한 모든것을 포함하여 응답 형식을 지정합니다. (PS3 UI 팀)
클라이언트에게 Payload를 전달합니다. (PS3 UI 팀)
클라이언트가 구문을 분석하고 UI를 표현합니다. (PS3 UI 팀)

이 새로운 모델은 아직 초기 단계에 있으며, REST API를 사용하는 기기와 새로운 모델을 사용하는 기기로 현재 혼재되어 있습니다.

Source: https://medium.com/netflix-techblog/embracing-the-differences-inside-the-netflix-api-redesign-15fd8b3dc49d

Netflix Open Connect에서 인기 콘텐츠 관리 방법

Written by Giljae Joo (주길재) in Netflix, OCA, Open Connect with 댓글 없음

Netflix의 Open Connect 콘텐츠 딜리버리팀은 콘텐츠의 인기도를 예측하여 인프라 효율을 극대화 하려고 합니다. Content Delivery관점에서는 시청 횟수로 인기 콘텐츠를 판별합니다. 즉, 스트리밍된 총 바이트 수를 Asset의 크기(byte)로 나누어 계산합니다.

그럼, 콘텐츠와 CDN 최적화는 어떤 관계가 있을까요? 일반적으로 CDN에서는 짧은 네트워킹 경로를 통해 최대한 많은 콘텐츠를 제공하려고 합니다. 네트워크 대기시간을 줄임으로써 사용자들의 스트리밍 환경을 극대화 할 수 있기 때문입니다.

서버당 사용할 수 있는 디스크 공간이 제한되어 있으므로 모든 Edge Server에 모든 콘텐츠를 넣을 수가 없습니다. 따라서 가장 많이 사용되는 콘텐츠만 Cache하게 됩니다.

Netflix의 경우 많은 트래픽을 발생시키는 Edge에서 계층화된 인프라를 사용합니다. 100G를 처리하는 서버는 매우 인기있는 콘텐츠를 제공하는데 사용되고 대용량 스토리지(200TB+)는 Warm/Cold 콘텐츠를 제공하는데 사용됩니다.

이러한 계층 구조를 적절하게 구성하기 위해 인기도에 따라 콘텐츠의 순위를 관리할 필요가 있습니다.

매우 인기 있는 콘텐츠가 단일 서버에만 배포되는 경우 해당 서버의 최대 리소스를 사용할 수 있지만 다른 서버는 활용되지 못할 수 도 있습니다.

인기있는 파일은 디스크에서 읽어오는 것이 아니라 메모리에 위치해 있습니다. 메모리 최적화는 디스크 I/O가 병목현상의 원인이 될 가능성을 제거 합니다.
Netflix는 네트워크의 근접성을 기반으로 트래픽을 라우팅하기 떄문에 가장 인기 있는 콘텐츠도 Edge 네트워크에서 공유되고 확산됩니다. 따라서, 콘텐츠의 복사본을 보관합니다. Consistent Hashing은 클러스터내의 여러 서버에 콘텐츠를 할당하는데 사용됩니다. 일반적으로 해싱은 균형잡힌 클러스터를 생성하지만 모든 파일이 지정된 위치의 단일 서버에서 제공되는 경우 트래픽 분산에 문제가 생길 수 있습니다. 예를 들어서, 큰 바위더미들에게서 여러 곳으로 배포하려고 하면 무게가 모두 같지 않을 수 있는 가능성이 커집니다. 그러나 자갈더미와 같이 작은 돌멩이만 있다면 더 높은 확률로 가중치의 균형을 맞출 수 있습니다. 즉, 인기가 높은 콘텐츠(큰 암석)은 여러 복사본으로 배포하여 덜 인기 있는 콘텐츠(조약돌)로 분류 할 수 있습니다.

트래픽이 증가하면 각 서버는 전체 트래픽 수준에서 최고 사용률에 도달하도록 서버를 균등하고 균형있게 유지할 수 있습니다. 이를 통해 전체 클러스터에서 처리되는 트래픽양을 최대화 할 수 있습니다. 스마트TV, iOS에서 사용되는 프로필은 서로 다른 수준의 품질로 인코딩됩니다. 그리고 오디오 프로필과 자막을 여러 언어로 제공하기에 콘텐츠, 인코딩 프로필, 비트 전송률, 언어 기준으로 하나 이상의 파일을 Cache해야 합니다. 예를 들어 The Crown의 한 에피소드를 스트리밍하려면 1200개의 파일을 저장합니다.

Netflix의 경우 과거의 시청 패턴을 기반으로 미래의 시청 패턴을 예측합니다. 이를 수행하기 위한 가장 간단한 방법은 특정 날짜에 시청한 콘텐츠 회원을 보고 내일 동일한 콘텐츠를 볼 것이라 가정하는 것입니다. 그러나 현실은 쉽지 않습니다. 여러가지 변수가 존재하기에 콘텐츠 인기도는 변동될 수 있으며 이는 콘텐츠를 잘못 지정하는 사태가 발생할 수 있습니다. 콘텐츠 인기를 계산하는 모델은 여러가지가 존재합니다.

콘텐츠 타이틀 기준: 콘텐츠 타이틀과 관련된 모든 파일이 단일 그룹으로 순위가 지정 됩니다. 이는 단일 스트리밍 세션관 관련된 모든 파일(비디오, 오디오등 다중 프로필)이 단일 서버에 있음을 의미합니다. 이것의 단점은 인기 없는 프로필의 경우도 타이틀 기준이기에 저장해야 한다는 것입니다.
파일 기준: 모든 파일에 대해 인기도가 결정됨, 이 방법을 적용하면 같은 타이틀내에 존재하는 프로필 파일의 순위가 달라집니다. (인기있는 타이틀이라도 저화질은 안볼수 있기에…) 이 매커니즘은 Cache의 효율성을 크게 향상시킵니다.

Netflix의 경우 2016년도에 타이틀 기준에서 파일 기준으로 마이그레이션을 진행했고, 50% 수준의 스토리지 용량으로 동일한 Cache 효율성을 달성 했다고 합니다.

그럼, 새롭게 추가되는 콘텐츠 타이틀에 대해서는 어떻게 해야 하는것이냐?

Netflix의 경우 처음 출시되는 콘텐츠에 대해서 내부 및 외부 예측을 통해 인기도를 예측합니다. 물론, 이 부분의 정확하지 않기에 유기적인 예측으로 이를 정상화합니다.

Sources:

https://medium.com/netflix-techblog/content-popularity-for-open-connect-b86d56f613b

Kubernetes vs Mesos with Marathon (기술적 관점)

Written by Giljae Joo (주길재) in Kubernetes, Marathon, Mesos with 댓글 없음

이전 포스팅에서 Kubernetes와 Mesos에 대한 사업적 관점에서 비교를 했었습니다. 본 글에서는 기술적 관점에서의 비교글을 작성합니다.

Kubernetes

Kubernetes는 컨테이너 어플리케이션의 automating deployment, scaling 및 관리를 위한 오픈 소스 시스템입니다. Kubernetes의 아키텍처는 아래와 같습니다.

Kubernetes Cluster와 관련된 구성 요소들은 아래와 같습니다.

etcd: etcd는 분산 key-value store이고, Kubernetes에서는 Master Node의 API Server가 HTTP/JSON API를 이용하여 접근할 수 있는 구성 데이터를 저장하는 용도로 사용됩니다.
API Server: Master Node의 Hub입니다. 다양한 Component와의 인터페이스를 원할히 해주는 역할을 담당합니다.
Controller Manager: 작업에 대한 부하를 조절하여 클러스터의 상태를 좋게 유지하도록 합니다.
Scheduler: Workload를 적절히 Node에 배치합니다.
Kubelet: API Server로 부터 Pod의 specificatio을 전달 받아 Host에서 수행중인 Pod를 관리합니다.
Master: Kubernetes Node를 제어하는 역할을 수행
Node: Pods가 실행되는 Machine입니다.

다음은 Kubernetes와 관련된 일반적인 용어를 정리한 내용입니다.

Pods: Kubernetes는 Pod라는 그룹으로 Container를 배치하고 예약합니다. Pod의 Container는 동일한 Node에서 실행되며 리소스를 공유합니다. (e.g. File System, Kernel Namespace, IP address)
Deployments: Pod 그룹을 만들고 관리 할 수 있습니다. 수평적 확장이나 가용성 보장을 위해 사용됩니다.
Label: Object에 연결된 Key-Value 입니다. Label을 사용하여 여러 Object를 단일 세트로 검색하고 업데이트 할 수 있습니다.

Mesos + Marathon

Mesos는 Data Center에서 리소스를 동적으로 할당 하는 것을 목표로 하는 Distributed Kernel 이고, 리소스 공유 기능을 사용하는 수많은 Framework, Application Stack을 제공합니다. 각 Framework는 Scheduler와 Executor로 구성됩니다. Marathon은 Application 및 기타 Framework를 시작할 수 있는 Meta Framework입니다. Container Workload에 대한 확장 및 Self Healing 기능을 제공하는 Orchestration Platform 역할도 담당 할 수 있습니다. 아래 그림은 Mesos + Marathon의 아키텍처 입니다.

Mesos와 Marathone의 구성요소는 아래와 같습니다.

Mesos Master: Container 관리를 위한 Marathon, 대규모 데이터 처리를 위한 Spark와 NoSQL 데이터 베이스를 위한 Cassandra와 같은 Framework에서 Resource 공유를 가능하게 됩니다.
Mesos Slave: 사용 가능한 Resource를 Master에게 알려주는 Agent를 실행합니다.
Framework: Master가 Slave 노드에서 실행되는 Task를 전달 받을 수 있도록 Mesos Master에 등록됩니다.
Zookeeper: Cluster state를 Read/Write할 수 있는 가용성 높은 Naming Registry를 제공합니다.
Marathon Scheduler: Mesos Master로 부터 오퍼를 받아 Slave Node의 사용 가능한 CPU 및 Memory list를 제공합니다.
Docker Executor: Marathon Scheduler에서 작업을 받고 Slave Node에서 Container를 실행합니다.

Mesosphere DCOS

Mesosphere Enterprise DC/OS는 Mesos Distributed Kernel을 활용하여 Container 및 대용량 데이터 관리 및 사용자 인터페이스, 모니터링 도구 및 기타 기능을 제공합니다. 아래의 그림은 DCOS의 아키텍처 입니다.

DCOS는 Package Management, Container Orchestration, Cluster Management 및 기타 구성 요소로 구성됩니다.

Kubernetes vs Mesos + Marathon

Application Definition

Kubernetes ** Application은 Pod, Deployment 및 Service의 조합을 사용하여 배포할 수 있습니다. Pod는 함께 배치된 Container Group이고 최소 배포 단위입니다. Deployment에는 여러 노드에 복제본이 존재할 수 있습니다. Service는 Container Workload의 “external face”이며 요청을 Round Robin 하기위해 DNS와 통합합니다.
Mesos + Marathon ** Application은 Marathon에 의해 예약된 작업으로 Node에서 실행됩니다. Mesos의 경우에는 Application은 Marathon, Cassandra, Spark등의 Framework이며, Marathon은 Container를 Slave Node에서 실행되는 Task로 예약합니다. Marathon 1.4에서는 Kubernetes와 같은 Pod 개념을 도입하였지만 Marathon Core내의 기능은 아닙니다.

Application Scalability Constructs

Kubernetes ** 각각의 Application 계층은 Pod로 정의되며 YAML을 사용하여 배포에 대해 선언적으로 표현합니다. 스케일링은 수동/자동으로 수행 할 수 있습니다.
Mesos + Marathon ** CLI or UI를 사용할 수 있고, JSON으로 정의하여 Docker Container의 저장소, 리소스, 인스턴스 수 및 실행할 명령을 지정할 수 있습니다. Marathon UI를 사용하여 스케일업을 수행 할 수 있고 Marathon Scheduler는 지정된 조건에 따라 Slave Node에 Container를 분배합니다.

High Availability

Kubernetes ** Pod를 Node간에 배포하여 HA를 제공합니다. Load Balance 서비스는 유해한 Pod를 탐지하여 제거 합니다. 다중 Master Node와 Worker Node는 kubectl과 client의 요청에 대해 Workload를 조정할 수 있습니다. etcd를 Clustering하고 API Server도 복제할 수 있습니다.
Mesos + Marathon ** Zookeeper를 사용하여 Mesos 및 Marathon의 HA를 지원합니다. Zookeeper는 Mesos와 Marathon의 leader를 선출하고 Clustering 상태를 유지하도록 도와줍니다.

Load Balancing

Kubernetes ** Pods는 Service를 통해서 expose 됩니다. load balancing에 대해서는 여기를 참조하세요
Mesos + Marathon ** Host port를 여러 Container port에 매핑하는 방식을 사용합니다

Auto Scaling

Kubernetes ** Scaling은 Deployments를 사용하여 선언적으로 정의합니다. resource metric기반의 Auto-scaling도 지원됩니다. Resource metric은 CPU, Memory 사용률과 Request, packet 및 Custom metric도 지원합니다.
Mesos + Marathon ** Marathon은 구동중인 Container의 Instance 개수를 지속적으로 모니터링합니다. Container중 하나가 fail나면 Marathon은 다른 Slave Node로 다시 Schedule합니다. Resource metric기반의 Auto-scaling은 지원하는 component를 통해서만 사용할 수 있습니다.

Application Upgrade and Rollback

Kubernetes ** Rolling-update와 recreate 전략을 deployment에 모두 지원합니다.
Mesos + Marathon ** Deployment를 사용하여 Rolling-update를 지원합니다.

Health Checks

Kubernetes ** liveness, readiness 두가지를 지원합니다.
Mesos + Marathon ** HTTP, TCP 및 기타 프로토콜등 여러 프로토콜에서 Health check 기능을 사용할 수 있습니다.

Storage

Kubernetes ** 두 개의 Storage API를 제공합니다. ** Individual storage backends (e.g NFS, AWS EBS, Ceph, Focker에 대한 추상화 지원) ** Storage resource request (다른 저장소의 리소스 요청에 대한 추상화 제공) ** Block 또는 File을 지원하는 여러 유형의 Persistent volume을 제공합니다. (e.g iSCSI, NFS, FC, Amazon Web Services, Google Cloud Platform, MS Azure) ** emptyDir volume은 비영구적이며 Container로 파일을 read/write할 수 있습니다.
Mesos + Marathon ** Local persistent volume(Beta version)은 MySQL와 같은 상태 저장 응용 프로그램에서 지원됩니다. ** Amazon EBS와 같은 외부 저장소 사용도 Beta version 입니다. ** 한번에 하나의 작업에만 Volume을 첨부 할 수 있기 때문에 외부 volume를 사용하는 Application은 단일 Instance로만 확장 할 수 있습니다.

Networking

Kubernetes ** 모든 Pod가 상호간에 통신할 수 있는 flat network model입니다. (overlay로 구현됨) ** 이 모델에는 두 개의 CIDR이 필요합니다. 하나는 Pod가 IP 주소를 얻고 다른 하나는 Service에서 사용됩니다.
Mesos + Marathon ** Host mode or Bridge mode로 구성 할 수 있습니다. * Host mode ** Host port는 Container에 의해 사용됩니다. 이로 인하여 Host에서 port 충돌이 발생할 수 있습니다. * Bridge mode ** Container port를 매핑하여 Host port에 연결됩니다. Host port는 배포시 동적으로 할당 될 수 있습니다.

Service Discovery

Kubernetes ** 환경 변수 혹은 DNS를 사용하여 찾을 수 있습니다. Pod가 실행될 때에 kubelet은 몇가지 환경 변수를 추가합니다. (e.g PSVCNAME_SERVICEHOST}, {SVCNAME_SERVICE_PORT}, Docker link 변수) ** DNS server는 addon으로 사용할 수 있습니다. 전체 Cluster에서 DNS를 사용하게 되면 Pod는 자동으로 부여하는 Service Name을 사용할 수 있습니다.
Mesos + Marathon ** Service는 IP, Port와 연결된 DNS 레코드를 통해 찾을 수 있습니다. ** Service는 Mesos-DNS에 의해 자동으로 DNS에 레코드에 할당됩니다. 선택적으로 명명된 VIP도 작성 할 수 있습니다. VIP를 통한 요청은 LB처리가 됩니다.

Performance and Scalability

Kubernetes ** 1.6 release에서 5000 node까지 확장됩니다. 여러 Cluster를 사용하면 5000 cluster 제한을 초과하여 사용할 수 있습니다.
Mesos + Marathon ** Mesos + Marathon 조합은 확장성이 뛰어납니다. Digital Ocean에 따르면 Mesos 및 Marathon Cluster는 10000 node로 확장됩니다.

Synopsis

Kubernetes ** On-premise SAN 및 Public Cloud를 포함한 다양한 Storage 옵션 제공 ** 이미 Google에서 대규모로 사용되고 있음 ** Container Orchestration 중에 가장 큰 규모의 커뮤니티를 가지고 있음
Mesos + Marathon ** Amazon EBS 및 외부 저장소는 Beta version ** 상용 업체에 의해 Control 됨 ** 소규모 커뮤니티

Mesos + Marathon 대비 Kubernetes의 단점

Kubernetes ** 단일 공급 업체가 없기에 사용에 대한 의사 결정이 복잡해 질 수 있음 (문제 발생시 누가 책임질 것인가?) ** Kubernetes는 Container Orchestration 전용으로 제작되었음 ** 5000 node cluster까지 확장되고, 그 이상을 사용하려면 여러 개의 Cluster가 필요
Mesos + Marathon ** 단일 공급 업체를 통해 버그 수정 및 패치를 제공 받음 (문제 발생시 책임짐) ** 2-tier 아키텍처를 사용하면 다른 Framework를 배포할 수 있음 ** Apple, Bloomberg, Netflix내의 일부 조직에서는 10000개 이상의 node를 통해 대규모로 Mesos를 사용중 (참고: Mesosphere 블로그) ** Kubernetes는 오픈 소스 프로젝트이고 많은 참여가 일어나고 있음 ** Load Balancing 및 DNS와 같은 Network 기능 제공 ** Logging/Monitoting
Kubernetes ** ELK, sysdig, cAdvisor, Heapster/Grafana/InfluxDB 와 같은 외부 도구 사용 가능
Mesos + Marathon ** 내부적으로 집계 가능한 Log를 제공하고 모니터링은 외부 도구를 사용 ** Auto-Scaling은 기본적으로 지원

무엇을 선택해야 할까?

Kubernetes와 Mesos + Marathon에 대한 관심도를 살펴보면 Kubernetes가 뉴스 기사, 웹 검색, 출판물 및 Github 대상 모든 측정 항목에서 70% 이상을 차지하고 있음을 알 수 있습니다.

Kubernetes는 Mesos + Marathon에 비해서 이점을 제공합니다.

폭넓은 DevOps 및 Container 커뮤니티
복잡한 어플리케이션 스택에 사용하기 유리하며 더 발전된 Scheduling option을 제공
Google에서 10년 이상의 경험을 바탕으로 제작됨

결론,

돈이 많고, 기술 내재화 하기도 싫고, 문제 발생시 책임 소재도 따지고 싶으면 Mesos + Marathon 을 선택, 그렇지 않다면 Kubernetes로 가는 것이 현실적으로 보여집니다.

다음 포스팅에서는 Kubernetes와 Amazon ECS를 비교해보도록 하겠습니다.

참고 자료:

https://thenewstack.io/a-brief-comparison-of-mesos-and-kubernetes/
https://platform9.com/blog/kubernetes-vs-mesos-marathon/
https://www.stratoscale.com/blog/kubernetes/kubernetes-vs-mesos-architects-perspective/

Giljae Joo (주길재)