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

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

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

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

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

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

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

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

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

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

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

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

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

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

Sources:

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

Read More

OCA(Open Connect Appliance)에서 100Gbps 서비스

본 글은 Netflix Tech 블로그의 내용을 번역한 내용입니다. (관심 있는 부분만…) 원문: https://medium.com/netflix-techblog/serving-100-gbps-from-an-open-connect-appliance-cdb51dda3b99

2015년 여름, Netflix Open Connect CDN팀은 NVM Express(NVMe) 스토리지 기반의 단일 FreeBSD OCA에서 100Gbps 속도로 서비스 할 수 있도록 100GbE 네트워크 인터페이스 기술을 활용하는 프로젝트를 수행하기로 결정 했습니다.

Fake NUMA(Non-uniform Memory)

OCA의 경우 대부분의 콘텐츠는 디스크에서 제공되며 인기있는 타이틀 10–20%만 메모리에서 제공됩니다. 초기의 NVMe 프로토타입은 디스크 대역폭 문제로 인해 제한적이었습니다. 그래서 인기 있는 콘텐츠만 제공하는 형태로 테스트 서버에서 실험을 시작했고 모든 콘텐츠가 메모리에 저장되어 디스크 병목 현상이 발생하지 않았습니다. 의외로 성능은 40Gbps로 제한된 CPU에서 22Gbps로 떨어졌습니다.

pmcstat과 Frame graph를 사용하여 매우 기본적인 프로파일링을 수행했습니다. 수행 결과 lock contention에 문제가 있다는 의심이 들었습니다. 그래서 DTrace기반의 lockstat으로 프로파일링을 수행했습니다. Lockstat의 결과 Inactive page queue에 대한 lock에 CPU waiting time이 많이 소요되는 것을 확인했습니다. 왜 메모리상에서 Serving을 하는데 성능이 더 나빠졌을까요?

Netflix OCA는 비동기 sendfile() 시스템 호출을 통해 Nginx를 사용하여 Large 미디어 파일을 제공합니다.

sendfile() call flow 여기서 문제는 Inactive queue가 NUMA별 단일 목록으로 구성되고 single mutex lock으로 보호된다는 점입니다.

NUMA Netflix가 생각해낸 해결책은 “Fake NUMA”입니다. 시스템에 거짓으로 2개의 CPU마다 하나의 Fake NUMA가 있다고 합니다. 이 작업후에 lock contention이 거의 사라졌으며, 52Gbps로 서비스 할 수 있었습니다. (PCIe Gen3 x8 slot)

Pbufs

FreeBSD는 “buf”구조를 사용하여 디스크 I/O를 관리 합니다. Bufs는 시스템 부팅시 정적으로 할당되며 single mutex로 보호됩니다. Netflix의 문제는 sendfile() 시스템 호출이 VM paging system을 사용하여 메모리에 없을 때 디스크에서 파일을 읽는 것입니다. 결국 모든 디스크 I/O는 pbuf mutex에 제약을 받았습니다.

Global pbuf mutex에 대한 lock contention 문제가 있었고, 이를 해결하기 위해 스왑 파티션이 아닌 파일기반으로 페이징을 처리하는 vnod pager를 수정하여 일반 커널 영역의 확장자를 사용하도록 변경했습니다. 이 변경으로 인해 잠금 경합이 제거되고 성능이 70Gbps로 향상 되었습니다.

Mbuf Page Arrays

FreeBSD의 mbuf는 네트워크 스택의 핵심입니다. 모든 패킷은 하나 이상의 mbuf로 구성됩니다. 대량의 트래픽을 처리하기 위해서 사용하는 sendfile() system call은 mbuf내에 있는 4k page를 wrapping합니다.

여기에서의 단점은 많은 mbuf가 함께 연결된다는 것입니다. sendfile을 통과하는 1MB의 요청은 256개의 VM page를 참조할 수 있으며, 각 VM page는 mbuf로 wrapping되어 연결 됩니다.

전송되는 mbuf의 수를 줄이기 위해 동일한 mbuf에서 동일한 유형의 여러 페이지를 전달 할 수 있도록 mbuf를 확장하기로 결정했습니다. sendfile을 위해 최대 24페이지를 전송 할 수 있는 mbuf를 설계했습니다. 그 결과 7Gbps의 성능이 향상 되었습니다. 위의 작업으로 인해 FreeBSD TCP 스택을 사용하여 90Gbps에서 100% TLS 트래픽을 제공 할 수 있게 되었습니다. 그러나 RACK, BBR과 같은 고급 TCP 알고리즘을 사용할 경우 목표에 미치지 못한다는 사실을 발견했고 TCP 코드 최적화에 대한 작업을 계속 진행중입니다.

Netflix는 참 대단한 회사입니다. 어디까지 성능을 끌어올릴지가 궁금하네요.

Read More

Netflix, 그들의 콘텐츠 서비스 방식 (Netflix and Fill)

본 글은 넷플릭스의 Tech블로그의 내용과 개인적인 의견을 포함하여 작성했습니다. (참조: https://medium.com/netflix-techblog/netflix-and-fill-c43a32b490c0)

새로운 콘텐츠가 출시 되면 CP(Content Provider)로부터 넷플릭스내의 콘텐츠 운영팀으로 Digital Asset이 전달 됩니다.

이 과정에서 Netflix Platform에 통합하기 위해 필수적인 품질관리, 인코딩등 다양한 유형의 처리 및 개선이 이루어집니다. 이 단계가 끝나면 관련 Digital Asset (Bitrate, Caption)이 다시 패키징되어 Amazon S3에 배포 됩니다.

배포 준비가 된 S3의 콘텐츠는 콘텐츠 운영팀에 의해 metadata flag가 지정되며, 이 시점에서 Open Connect 시스템이 인계받아 OCA(Open Connect Appliance)에 콘텐츠를 배포하기 시작합니다.

Proactive Caching

Netflix의 Open Connect와 다른 CDN과의 가장 큰 차이점은 Proactive Caching입니다. 사용자들이 시청할 시간과 시청 시간을 높은 정확성으로 예측할 수 있기 때문에 구성 가능한 시간대 동안 non-peak bandwidth를 사용하여 예측한 콘텐츠를 OCA에 다운로드 할 수 있습니다. 다른 CDN은 이것이 불가능하고 범용적인 Delivery Service를 제공해야 하므로, LRU기반의 Caching을 선호하지요. CDN 사업자가 콘텐츠를 예측할 필요는 없으니까요. 그들은 미디어 사업자가 아니니까요.

OCA Clusters

Netflix의 Fill pattern이 어떻게 동작하는지 이해하려면 OCA가 IX에 위치하거나 ISP 네트워크에 포함되어 있는지 여부에 상관없이 OCA 클러스터를 구성하는 방법을 이해해야 합니다.

OCA는 manifest cluster로 그룹화 됩니다. 각 manifest 클러스터는 적절한 콘텐츠 영역(콘텐츠를 스트리밍 할 것으로 예상되는 국가 그룹), 인기도 피드(이전 데이터를 기준으로 간략하게 정렬된 콘텐츠 목록)로 구성되고 보유해야 하는 콘텐츠의 수를 표시합니다. Netflix는 국가, 지역 또는 기타 선정 기준에 따라 독립적으로 인기 순위를 계산합니다.

Fill cluster는 shared content영역과 인기 피드가 있는 manifest cluster의 그룹입니다. 각각의 fill cluster는 Open Connect 운영팀에 의해 fill escalation policies와 fill master의 수로 구성됩니다.

아래의 다이어그램은 동일한 Fill cluster내의 manifest cluster의 예를 설명합니다.

Fill Source Manifests

OCA들은 네트워크내의 다른 OCA에 대한 정보, 콘텐츠, 인기도등을 저장하지 않습니다. 모든 정보는 AWS Control Plain에 집계되고 저장 됩니다. OCA는 주기적으로 Control Plain과 통신하여 Cluster 멤버들에게 storing하고 serving해야 할 콘텐츠 목록이 포함된 manifest 파일을 요청합니다. AWS Control Plain은 여러 고수준 요소를 고려하여 ranked list를 다운로드 할 수 있는 location을 response합니다.

• Title(Content) availability — Does the fill source have the requested title(content) stored?
• Fill health — Can the fill source take on additional fill traffic?
• A calculated route cost — Described in the next section. (아래 섹션에서 설명)

Calculating the Least Expensive Fill Source

S3(Origin)에서 모든 OCA에 직접 콘텐츠를 배포하는 것은 시간과 비용면에서 비효율적이므로 계층화된 접근법을 사용 합니다. Open Connect의 목표는 가장 효율적인 경로를 사용하여 콘텐츠를 전달하도록 하는 것입니다.

Least expensive fill source를 계산하기 위하여 각 OCA의 네트워크 상태 및 구성 매개변수를 고려합니다.

• BGP path attributes and physical location (latitude / longitude)
• Fill master (number per fill cluster)
• Fill escalation policies

Fill escalation policies는 다음과 같이 정의합니다.

1. OCA가 콘텐츠를 다운로드 하기 위해 갈 수 있는 hop 수와 대기시간
2. OCA가 정의된 hop 이상으로 전체 Open Connect 네트워크로 이동 할 수 있는지 여부와 대기시간
3. OCA가 S3(Origin)으로 갈 수 있는 여부와 대기시간

Control Plain은 Master로 지정된 OCA를 선택합니다. Master에 적용되는 fill escalation policies는 일반적으로 콘텐츠를 가져와서 non-master와 로컬로 공유하기 위한 지연시간을 줄여 최대한 멀리 도달 할 수 있게 합니다.

경로 계산에 대한 모든 입력이 주어지면, fill source 작업은 다음과 같이 작동합니다.

1. Peer fill — Available OCAs within the same manifest cluster or the same subnet
2. Tier fill — Available OCAs outside the manifest cluster configuration
3. Cache fill — Direct download from S3

Example Scenario

Fill master OCA가 S3로 부터 콘텐츠 다운로드를 완료 한 후 Control Plain에 콘텐츠가 저장되었음을 보고 합니다.

그 다음 다른 OCA가 Control Plain과 통신하여 해당 콘텐츠의 fill source 요청을 보내면 Fill master에서 fill option이 제공됩니다.

두 번째 계층의 OCA가 다운로드를 완료하면 상태를 보고하고 다른 OCA는 해당 콘텐츠에 대한 fill source 작업을 수행 합니다. 이 작업은 fill window내에서 계속 반복됩니다.

더 이상 필요없는 콘텐츠는 delete manifest에 저장되고 일정 기간 후에 삭제됩니다.

Netflix 사용자가 스트리밍을 시작하면 이 시간대의 fill source 작업이 끝나고, fill window가 다른 시간대로 이동하면서 fill source pattern이 계속 진행 됩니다. (Netflix는 글로벌 서비스이기에 각 지역별로 네트워크 유휴 시간대가 다름)

Challenges

Netflix는 항상 fill process를 개선하고 있습니다. Open Connect 운영팀에서는 내부 툴을 사용하여 Fill traffic을 지속적으로 모니터링합니다. member들에게 서비스를 제공해야하는 catalog의 임계값 비율을 포함하지 않는 OCA에 대한 alert이 설정되고 모니터링 됩니다. 이 경우에는 다음 Fill process 전에 해당 문제를 해결합니다. 신속하게 배포해야 하는 새로운 콘텐츠나 기타 수정 사항에 대해 주기적으로 fast-track fill을 수행 할 수 있습니다. 기본적으로 이러한 fill pattern을 사용하면서 배포 시간 및 프로세싱 시간을 줄입니다.

Netflix는 190개국에서 운영되고 있으며 전 세계 여러 ISP 네트워크에 수천 개의 장비가 내장되어 있기에 ISP에 대한 대역폭 비용을 최소화 하면서 OCA에 최신 콘텐츠를 빨리 얻을 수 있도록 하는데에 집중하고 있습니다.

끝으로

Netflix가 일반적인 Caching(LRU, NRU)방식이 아닌 Proactive caching 방식을 택한 이유는 그들이 가지고 있는 Network를 온전히 서비스를 위해서 사용하기 위함으로 보여진다. NRU, LRU는 Proactive caching에 비해 Miss가 발생할 확률이 존재하기에 이러한 대역폭도 서비스적인 측면에서는 아깝다는 그들의 집착이 보여진다. Netflix는 일반 CDN업체가 아닌 미디어 사업자이기에 가능한 얘기가 아닐까? 결국 그들의 생각은 OCP는 비교적 저렴한 x86기반의 하드웨어를 쓰고 네트워크를 최대한 활용하여 가성비 있는 Open Connect를 운영하고 그 남는 비용으로 콘텐츠를 제작하겠다 아닐까?

관련된 내용은 아래의 링크를 참조

• https://www.youtube.com/watch?v=KtSBbsSwq-g
• https://johannesbergsummit.com/wp-content/uploads/sites/6/2014/11/Monday_8_David-Fullagar.pdf

Read More