CMAF (Common Media Application Format)

CMAF는 비디오 스트림을 여러 장치에서 저렴하고 쉽게 전달할 수 있도록 Microsoft 및 Apple에서 MPEG 형식으로 정의한 표준화 된 새로운 미디어 스트리밍 형식입니다.

오늘날 거의 모든 스트리밍 비디오가 표준화 된 인코딩 기술을 사용하여 압축되지만 “비디오의 경우 H.264 또는 H.265(HEVC)이고 오디오의 경우 AAC로 압축하고 있습니다.” Container는 이러한 파일에 Timing 정보를 추가하고 기타 meta data를 추가할 수 있습니다. 그리고 이러한 Container는 표준화 되지 않았습니다.

Apple의 HTTP Live Streaming(HLS) 프로토콜은 데이터를 MPEG-2 TS로 래핑하거나 캡슐화합니다. MPEG-DASH는 MPEG-4 Container(ISOBMFF)를 사용합니다.

결국, 재생할 실제 미디어는 동일한 포맷으로 되어 있지만 이런 캡슐화 포맷을 사용하면 다른 포맷을 만들어야 합니다.

OTT 서비스 제공 업체들은 비디오를 스트리밍 하기전에 이 작업을 수행해야 합니다. 그리고 이런 작업을 통해 생성된 파일을 저장해야 합니다. 즉, 사용자에게 HLS, DASH 서비스를 제공하기 위해 추가 비용이 발생하며, 이런 시스템을 구축하고 운영하는데 있어서 복잡성이 증가합니다.

CMAF는 표준화된 Container 또는 캡슐화 형식을 만들어 이 문제를 해결합니다.

기존에는 위의 그림 처럼 Encryption/Container가 나눠져 있었습니다. HLS, MPEG-DASH를 제공하기 위해서는 물리 파일이 2벌이 필요했습니다. CMAF를 통해 아래의 그림처럼 협의 되었습니다.

Container는 CMAF로 통일 되었지만, 아직 Encryption 부분이 남아 있습니다. HLS의 경우 Encryption 알고리즘으로 AES-CBC를 채택하고 있고, MPEG-DASH의 경우 AES-CTR을 채택하고 있습니다. 이 부분이 2016년까지는 풀리지 않고 있었습니다. IBC 2017(http://www,unified-streaming.com/blog/looking-back-hot-topics-ibc-2017)에서 이 부분에 대해서 논의가 있었고, 내용은 아래와 같습니다.

• CMAF가 발표되었을 때, 통합 미디어 형식을 제공하겠다는 약속이 두 가지의 양립 불가능한 암호화 모드(AES-CTR, AES-CBC) 때문에 회의적이었음
• Apple은 CBC모드를 사용하고 Google, Microsoft는 CTR모드를 사용하기에 암호화 콘텐츠를 주요 DRM 시스템에서 다루기 위해서는 두 번 암호화해야 하는 필요가 있었음
• Google이 Widevine에 CBC 지원을 발표했고, Microsoft도 PlayReady 4.0으로 자사 제품에 CBC 지원을 통합함으로써 CMAF에서는 암호화된 미디어도 통일된 형식의 콘텐츠 제공이 가능

위의 논의 이후에 Microsoft가 2018년까지 CBC를 적용하겠다는 공지를 합니다. (https://www.microsoft.com/playready/newsroom/), 해당 링크의 PlayReady 4.0 supports CMAF interoperable format with AES-CBC and AES-CTR encryption 확인 하지만, 현실에 반영되기까지는 약간의 시간이 필요해보이네요. 그래도 미디어 사업자들의 오랜 염원이었던 부분이 스펙상으로는 해소된 느낌입니다.

Read More

Jmeter vs. Locust 무엇을 써야 할까?

본 글은 Apache Jmeter와 Locust에 대해서 비교한 글입니다.

Apache Jmeter와 Locust는 현재 개발자 사이에서 가장 많이 알려진 인기있는 성능 테스트 도구입니다.

Jmeter와 Locust 소개

Jmeter는 가장 먼저 출시된 성능 테스트 프레임워크중에 하나입니다. 순수 자바로 작성되었습니다. Jmeter는 Web 및 FTP 관련 어플리케이션의 부하 테스트를 수행할 목적으로 제작되었습니다.

그러나 현재에는 거의 모든 어플리케이션과 프로토콜을 테스트할 수 있기에 다양한 OS 플랫폼위에서 동작되는 어플리케이션을 테스트 할 수 있습니다.

Locust는 Python으로 작성된 성능 테스트 프레임워크입니다. 가장 큰 특징은 Python으로 성능 스크립트를 작성할 수 있다는 점입니다.

코드로 작성하여 테스트하는 기능외에도 Event 기반 구현 확장성이 뛰어나기에 Jmeter에 비해 빠르게 성장하는 커뮤니티를 보유하고 있습니다.

오픈소스 라이선스

Jmeter는 Apache에 의해 개발되었고 Apache License 2.0을 기반으로 하며, Locust는 커뮤니티 주도 개발로 이루어졌고 MID 라이센스를 기반으로 합니다.

두 가지 모두 오픈 소스이기에 사용상의 제약없이 자유롭게 사용할 수 있습니다.

로드 테스트 생성 및 유지 관리

성능 테스트를 하기 위한 단계는 생성, 실행, 분석이 존재합니다. 첫번째 단계가 가장 많은 시간을 소모하기에 이 부분에 대해서 비교를 하고자 합니다.

Jmeter에서 성능 테스트를 작성하는 가장 일반적인 방법은 GUI모드를 사용하는 것입니다. Jmeter GUI 모드는 한줄의 코드 작성없이 쉽게 테스트를 작성할 수 있는 Desktop Client를 제공합니다.

Jmeter는 직관적이고 경험이 없는 엔지니어 일지라도 큰 문제없이 기본적인 시나리오를 작성할 수 있도록 되어 있습니다. 그리고 비 GUI 모드에서 Java를 사용하여 코드를 작성할 수 있습니다.

하지만 Jmeter에서는 스크립트 구현의 복잡성(Jmeter가 GUI모드를 쓰도록 설계 되었기 때문에)과 스크립트 작성 방법에 대한 문서가 부족하기에 이 방법을 널리 사용하지는 않습니다.

반면, Locust는 모두 코딩으로 해결 해야 합니다. 성능 테스트 작성에 익숙해지기 위해서는 기본적인 Python 코딩 경험이 있어야 합니다.

Locust에서 작성된 스크립트는 명확해보이지만 거대하고 복잡한 테스트를 수행할 경우, 스크립트 작성 및 검토가 복잡할 수도 있습니다.

하지만, 코드로 모든 테스트를 수행하는 것은 큰 이점입니다. UI가 없어도 테스트를 쉽게 수정할 수 있기 때문입니다.

그리고 작성한 스크립트를 Git을 이용하여 공유하고 변경 사항을 관리하고 함께 작업할 수 있습니다.

테스트 스크립트를 유지 보수를 해야 한다면 코드 기반이 훨씬 더 빠르고 편리하다고 볼 수 있습니다.

지원 프로토콜

테스트에서 가장 이상적인 부분은 “가장 적은 테스트 툴을 사용하여 모든 것을 테스트 할 수 있어야 한다.”입니다.

서로 다른 프로토콜 테스트를 위해 다른 툴을 사용해야 한다면, 여기에 들어가는 시간과 관련 툴에 해박한 엔지니어 소싱등등의 문제가 나올 것 입니다.

JMeter에서는 기본 제공 함수 및 다른 플러그인을 모두 사용하여 한 곳에서 모든 것에 대한 성능 테스트 제작이 가능합니다.

Locust는 HTTP Web 기반 테스트를 위해 제작되었습니다. 그러나 기본 기능을 확장하고 Python을 사용하여 테스트할 수 있는 모든 것을 만들 수 가 있습니다.

즉, 원하는 모든 것을 테스트 할 수 있지만, 필요시 Custom 스크립트와 프로그래밍 경험이 있어야 합니다.

동시 사용자 수

성능 테스트 툴은 테스트 목표를 달성하기 위해 필요한 만큼의 Request를 실행할 수 있어야 합니다.

특정 상황에서는 수천 또는 수백만명의 사용자를 시뮬레이션해야 합니다.

각 도구가 실행할 수 있는 동시 사용자 수는 대부분 리소스를 기반으로 합니다. JMeter와 Locust는 리소스를 다루는 방법이 다릅니다.

JMeter는 각 사용자에 대해 별도의 Thread를 할당하는 Thread 기반 모델을 가지고 있습니다.

이러한 단계별 Thread 할당 방식은 할당될때마다 리소스를 필요로 하기에 JMeter는 한 대의 Worker에서 시뮬레이션 할 수 있는 사용자 수가 매우 제한적입니다.

일반적으로 스크립트가 단순하다면 하나의 Worker에서 Max 1,000개까지 Thread를 생성 할 수 있습니다.

Locust는 이벤트 및 비동기 접근 방식을 기반으로 합니다. Gevent 구현을 통해 Locust 프레임워크는 단일 시스템에서 수천 명의 동시 사용자를 시뮬레이션 할 수 있습니다.

아래는 JMeter와 Locust를 사용하여 50명의 사용자에 대해 동일한 테스트를 실행하여 리소스 사용량을 비교한 그림입니다.

동일한 시나리오에서 GUI 모드로 실행되는 JMeter는 Locust보다 30배 더 많은 메모리를 사용하고 있습니다.

Ramp-up에 대한 유연성

Flexible Ramp-up 기능은 어플리케이션의 사용 사례를 시뮬레이션 하는데에 매우 중요합니다.

예를 들어서, 테스트 중에 Spike-load를 작성하여 점진적 로드이외에 예기치 않은 Spike를 처리하는 방법을 확인할 수 있습니다.

JMeter와 Locust는 로드를 생성하는데 동일한 방법을 제공합니다. 성능 테스트 중에 사용할 사용자 수를 지정하고 이들이 얼마나 빨리 요청해야 하는지를 지정 할 수 있습니다.

JMeter에서는 지정된 필드의 “Thread Group” 컨트롤러에서 로드를 구성할 수 있습니다.

JMeter에서는 유연한 로드 구성을 위한 플러그인을 제공합니다. (Ultimate Thread Group)

이 부분이 JMeter가 지닌 장점중에 하나 입니다.

Script Recording

스크립트 레코딩은 기본적인 테스트 템플릿을 만드는 효율적인 방법입니다. JMeter에는 스크립트 레코딩 기능이 내장되어 있고, 브라우저내에서 스크립트를 레코딩할 수 있는 확장 플러그인도 제공합니다.

Locust는 이 기능이 존재하지 않습니다.

부하 테스트 모니터링

JMeter와 Locust는 모두 성능 테스트를 모니터링하고 결과를 분석 할 수 있는 내장 기능을 제공합니다.

JMeter에는 많은 내장 Listener가 존재하며 Custom Listener를 확장 할 수 있습니다. 다만 JMeter Listener는 많인 리소스를 요구합니다.

Locust는 기본 부하를 모니터링하는 유용한 모든 정보를 제공합니다. 스크립트를 수행하는 동안 Locust는 모든 모니터링 결과를 볼 수 있는 간단한 웹서버를 실행합니다.

JMeter와 비교하여 Locust 모니터링은 많은 리소스를 요구하지 않습니다.

결론, 둘 중 어느 도구가 효과적인지 정리하기가 쉽지 않습니다.

Python을 좋아하고 GUI보다 코드로써 작성하기 원하면 Locust로 진행하면 되고, 그렇지 않으면 JMeter가 더 나은 선택일 수 있습니다.

Locust는 기존 성능 도구의 특정 문제를 해결하기 위해 만들어졌습니다. Locust와 Python 코드 조합은 GUI 없이 유지 보수에 최소한의 시간을 할애하고 매우 느린 시스템에서도 수천 명의 테스트 사용자를 시뮬레이션 할 수 있습니다. JMeter는Python을 잘 모르거나 GUI를 선호할 경우에 너 다은 선택지가 될 것입니다.

어떤 툴이 적합할까요?

참조: https://dzone.com/articles/jmeter-vs-locust-what-to-use-when

Read More

Intelligent Caching and Packaging in an ABR Multi-format CDN

2012년에 나왔던 자료인거 같은데… 이전에 작성한 “Netflix, 그들의 콘텐츠 서비스 방식(Netflix and Fill)” 과 연관이 있어 보인다.

VOD를 처음 시작할때는 Caching이 필요하지 않았다. VOD가 초기 단계에 있었을 때 하나의 중앙 서버가 전체 노드를 지원했었고 콘텐츠는 SD 포맷으로만 제공 되었다. 한곳에서 콘텐츠를 관리했기에 Caching이 필요하지 않았다.

VOD가 많아짐에 따라 Caching이 필요하게 되었다. LRU는 지능형 Caching으로 진화했다.

Caching은 미래 행위를 예측하기 위해 과거 행위를 이용하려는 예측 활동이다. Caching은 삭제해야 할 콘텐츠를 결정하는 것이 중요하다. LRU는 사용 패턴에 관계없이 가장 오래동안 사용하지 않은 콘텐츠를 제거한다. Intelligent Caching은 전체 시청 시간을 기반으로 추가 조회 가능성에 대한 통계적 추론 기법을 가미한다.

이 장표를 소개할 시점의 CDN Caching 알고리즘의 주류는 LRU

예측 가능성을 향상 시키기 위해서는 동일한 콘텐츠에 대한 모든 스트림 요청이 동일한 edge streamer로 전달되어야 하며, Cluster Manager를 사용하여 콘텐츠 요청 경로를 지정해야 한다. Netflix의 경우 Control Plain으로 보면 될듯

동일한 Cache에서 같은 콘텐츠를 스트리밍하면 count가 증가하고 네트워크 사용률이 감소한다. 이렇게 되려면 Cluster Manager가 Edge를 Referring 해야 한다.

LRU caching은 콘텐츠 및 콘텐츠 위치, usage에 대한 정보가 없다. 즉, 가장 최근에 사용된 콘텐츠를 결정하고 나머지는 제거한다.

Intelligent caching은 Edge에 콘텐츠를 잘 갖다 놓고 여러 매개 변수를 사용하여 Edge에 저장된 Chunk의 실제 가치를 평가하기에 보다 효율적으로 동작한다.

Caching은 패키징 옵션의 영향을 받는다는 의미인데, 어떤 방식으로 패키징하고 Origin에 어떤 모양으로 담겨 있는지에 따라 Caching에 영향을 준다는 의미인듯…

Source: https://www.slideshare.net/briantarbox/2012-ncta-motorolaintelligent-caching-and-packaging-in-an-abr-multiformat-cdn-tarboxfinal

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

NGINX based vod packager 소개

 

일반적으로 NGINX Level에서는 HLS,DASH Streaming을 지원해준다. 이 부분은 굳이 NGINX가 아니더라도 Tomcat container와 같은 Application Server에서는 일반적으로 지원해주고 있다. (HTTP requst range 기반으로 작동되므로…)

하지만, Media Streaming을 위해서는 기본적인 Streamer 기능 외에 필요한 부분들이 있다. NGINX의 경우에는 이런 부분들을 3rd party 개발자분들이 module을 제작하여 Github를 통해 공개하고 있다.

NGINX에서 가장 유명한 VOD module은 nginx-rtmp-module이지만, 본 글에서는 nginx-vod-module에 대해서 다루고자 한다.

Features

• On-the-fly repackaging of MP4 files to DASH, HDS, HLS, MSS
• Working modes:
• Local: serve locally accessible files (local disk/NFS mounted)
• Remote: serve files accessible via HTTP using range requests
• Mapped: serve files according to a specification encoded in JSON format. The JSON can pulled from a remote server, or read from a local file
• Adaptive bitrate support
• Playlist support — mapped mode only
• Simulated live support (generating live stream from MP4 files) — mapped mode only
• Fallback support for file not found in local/mapped modes (useful in multi-datacenter environments)
• Video codecs: H264, H265 (DASH/HLS), VP9 (DASH)
• Audio codecs: AAC, MP3 (HLS/HDS/MSS), AC-3 (DASH/HLS), E-AC-3 (DASH/HLS), OPUS (DASH)
• Playback rate change — 0.5x up to 2x (requires libelcodec and libavfilter)
• Support for variable segment lengths — enabling the player to select the optimal bitrate fast, without the overhead of short segments for the whole duration of the video
• Clipping of MP4 files for progressive download playback
• Thumbnail capture (requires libavcodec)
• Decryption of CENC-encrypted MP4 files (it is possible to create such files with MP4Box)
• DASH: common encryption (CENC) support
• MSS: PlayReady encryption support
• HLS: Generation of I-frames playlist (EXT-X-I-FRAMES-ONLY)
• HLS: support for AES-128 / SAMPLE-AES encryption

생각외로 많은 기능을 제공해주고 있다. 물론 제약도 존재한다.

Limitations

• Track selection and playback rate change are not spported in progressive download
• I-frames playlist generation is not supported when encryption is enabled
• Tested on Linux only

Read More

HashiCorp사의 Consul, Consul Template 소개

HashiCorp에서 제공하는 Consul은 Service Discovery, Failure Detection, Multi Datacenter, KV Storage 기능을 제공합니다. HAproxy 혹은 Nginx와 같은 Software 기반의 Load Balancer를 Cloud 상에 구축한다고 가정해보면, 고려해야 할 사항은 아래와 같습니다.

• 부하량에 따라 LB가 Scale In/Out이 되어야 한다.
• 로드 밸런싱 대상이 되는 Backend 서비스가 Scale In/Out이 되면 LB의 Configuration이 실시간으로 변경되어야 하며, 각 LB에게 동기화가 되어야 한다.
• LB의 Health check가 수행되어야 한다.

이 정도로만 간추려봐도 LB하나를 도입하기 위해 해야할 일이 많아지게 됩니다. 분산 환경에서의 이러한 일을 처리하기 위해 예전에는 Apache Zookeeper를 이용하여 개발을 했었지만 이번에는 Consul을 이용해보기로 했습니다.

Apache Zookeeper와 HashiCorp의 Consul의 차이점은 아래와 같습니다.

Apache Zookeeper

• Written in Java
• Strongly consistent (CP)
• Zab protocol (Paxos like)
• Ensemble of servers
• Quorum needed (majority)
• Dataset must fit in memory

Zookeeper는 현재 많은 곳에서 활용되고 있지만, 몇가지 문제점을 지니고 있습니다.

Zookeeper : Problems

• Latency-dependent
• No multi datacenters support (very slow write)
• Client number limit (out of sockets)
• Designed to store data on the order of KB in size
• Possibly lost changes while reenabling watch
• TCP connection != service healthy (proxy)
• Change zk server is a problem

이러한 문제점들을 보완해서 나온 제품이 Consul입니다. Consul의 특징을 보시죠.

HashiCorp Consul

• Written in Go
• Service discovery
• Health checking
• Key / Value Store
• Multi datacenter support
• Agent / Server Concept
• Gossip protocol for all the nodes (discovery)
• Consensus protocol (Raft-based) for servers
• 3 consistency modes
• Access Control List (ACL)

Consul에서 제공하는 기능을 HAProxy에 적용을 해봤고 결과는 만족스럽습니다.

HAProxy는 GSLB or DNS RR로 상위 Client에서 접속을 시도하게 되게되고 이 경우 HAProxy를 HA구성(Active-Standby)을 해야 합니다.

HAProxy가 설치된 VM에 consul agent를 등록하고 별도의 config 파일을 만들어 HAProxy에 대해서 Health checking을 수행 합니다. LB 매커니즘이 Round Robin일 경우 HTTP로 health check를 하게되면 LB가 문제가 될 소지가 많기에, 저의 경우에는 별도의 script를 만들어서 health checking을 수행했습니다.

haproxy.cfg 파일을 중앙에서 관리하기 위해 haproxy.cfg.ctmpl 파일을 만들어 consul-template daemon을 구동합니다. haproxy.cfg.ctmpl내에 별도의 key를 만들어 이 정보를 Consul의 K/V store에서 관리 및 변경시 모든 node에 즉시 동기화가 됩니다.

이렇게 함으로써 HAProxy를 도입할때의 고려사항 중 일부가 해소가 되었습니다.

앞으로 남은 부분은 consul-ui에서 확인할 수 있는 alarm 및 기타 정보를 push 형태로 IaaS Management 쪽에 전달하는 부분만 보완하면 될 것 같습니다. consul-ui는 어디까지나 확인 용도이고 IaaS management tool과 Integration이 되어야 하기 때문입니다.

그동안 Zookeeper를 쓰면서 client number limit, TCP connection, store data design 부분에 대해서 고민이 있었는데, consul을 활용하면서 이런 부분이 어느정도 해소가 될 것으로 보여집니다.

관련하여 좋은 Tip이 있으면 같이 공유했으면 합니다.

Read More