CMAF를 사용하는 경우 Chunked Transfer가 핵심 기술이 되고 LL HLS를 사용하는 경우 Chunked Transfer가 핵심은 아니긴 합니다. 아래 장표를 보고나서... 이 자료는 CMAF 기반의 Low Latency 구성이구나를 깨달았습니다.
실제 사용자 환경은 정말 다양하고 품질도 천차만별이라 Low Latency 라이브 서비스를 어떻게 구현할 것인지의 고민이 많을 수 밖에 없습니다. Trade-off 장표가 그런 고민들을 일목 요연하게 보여줍니다.
AWS Document를 뒤져봐도 Low Latency HLS에 대해서는 이렇다할 내용이 없는 것 같습니다. 규격상 몇 가지 걸리는 부분들이 있고 CloudFront에 대해서도 고민이 되는 부분인데 조금 더 검색력을 높여 구글신, ChatGPT와 함께 골머리 싸봐야겠습니다.
일단 문서의 모든 내용을 이해한 것이 아니라 찾아보고 공부할 것들이 많이 있다. 실제 하드웨어의 스펙도 실무에서 쓰는 것과 다른 부분이 많기 때문에 어떤 항목들에 대한 튜닝과 개선을 통해 넷플릭스 만큼은 아니더라도 대역폭을 더 적은 자원을 소모하면서 뽑아낼 것인가에 대한 연구는 해볼만할 것 같다.
FreeBSD의 기술행사인 EuroBSDCon 2022에서 발표된 넷플릭스의 프레젠테이션 자료는 아래와 같다.
AWS의 CDN 제품인 CloudFront는 원본 서버에서 제공하는 기본 오브젝트를 지정할 수 있는 기능을 제공하고 있습니다. 보통은 원본 서버에서 사용하는 웹 서버에서 기본 오브젝트를 지정하는 경우가 많지만 S3 등 다른 제품을 함께 사용할 때는 기본 오브젝트를 지정할 수 있는 방법이 없기 때문에 파일명을 지정할 수 있는 기능이 필요합니다.
기본 루트 오브젝트 설정 Set Default Root Object
CloudFront Distribution의 기본 설정 탭에서 기본 루트 오브젝트를 설정할 수 있습니다. Distribution 목록에서 작업하려는 Dist ID를 선택하여 상세 화면으로 진입합니다. 상단 탭중 첫번째 탭인 General 탭으로 이동합니다. Settings 섹션의 `Edit` 버튼을 눌러 상세 설정 화면으로 진입해 봅니다.
Edit 화면의 중간 정도를 살펴보면 `Default root object - optional` 항목을 찾으실 수 있습니다. 이곳에 지정된 파일 이름이 CloudFront를 통해 접근시 사용되는 기본적인 파일 이름이 됩니다. 가령 www.iamnopd.com 이라는 도메인이 있다고 가정했을 때, 브라우저에 www.iamnopd.com 만 입력해도 알아서 index.html 을 찾아 사용자 브라우저로 응답을 하게 되는 거죠.
다양한 경로에 대한 기본 오브젝트 설정
그런데 문제가 있습니다. `Default root object`에 지정한 파일 이름은 진짜, 레알, 루트 경로에 대한 요청에 대해서만 적용되는 한계가 있습니다. 가령 원본이 S3 버킷이라고 했을 때, 버킷의 최상위 경로에도 index.html 이 있고, 버킷에 생성되어 있는 api 폴더의 하위에도 index.html 이 있다고 해봅시다.
원본의 서로 다른 경로를 특정 사용자 Path의 루트로 바인딩 하기 위해서는 (아시겠지만) 아래와 같이 동일 원본을 Origin Path만 분기하여 등록하면 됩니다. 이 구성과 Default root object 의 조합은 /api 경로에 대해서 적용되지 않는다는 상황으로 이해하지면 될 것 같습니다. 그러면 어떻게 하면 될까요?
CloudFront Function을 이용한 경로 조작
S3에서 뭔가를 하면 되지 않을까? 하고 생각했을지도 모르지만 그것보다는 CloudFront Function을 쓰면 간단하게 구현할 수 있습니다. 아시겠지만 Lambda@Edge를 쓰는 것보다 CloudFront Function을 쓰는 것이 사용도 간편하고(=기능이 다소 적고) 비용도 저렴합니다. 묻지도 따지지도 말고 바로 코드를 보겠습니다.
function handler(event) {
var pathFrom = /^\/api$/g
var pathTo = '/api/index.html'
var pathDecided = '';
var request = event.request;
pathDecided = request.uri;
if (pathDecided.match(pathFrom) != null) {
pathDecided = pathDecided.replace(pathFrom, pathTo);
}
request.uri = pathDecided;
return request;
}
코드는 무척 간단합니다. 간단한 Regex 를 이용하여 들어온 URI (request.uri)를 단순히 문자열 비교한 후에 실제로 원본이 받게될 URI 를 변경해서 return 해주는 코드입니다. 요청량이 많아도 크게 부담스러운 금액이 나오지는 않을것 같습니다. 간단하지만 Default root object가 단일 경로에 대해서만 적용되는 제약을 회피(?)하는 방법을 살펴봤습니다 :-)
테스트도 참 쉽죠? 원하는 결과를 테스트를 통해 얻었다면, 만든 함수를 적용하고자 하는 Distribution의 Behavior의 Viewer Request 함수로 지정하면 됩니다. 끝!
CDN 의 핵심은 두가지입니다. 하나는 캐싱을 통한 사용자와 서버간의 거리 단축이고, 다른 하나는 사용자와 캐싱 서버 (=엣지 서버) 간의 거리를 줄여 불확실한 구간을 최소화 하는 것입니다. 이 두가지는 표현이 조금 다르고 추구하는 바가 달라보이기는 하지만 결국 <사용자의 지연 Latency 를 최소화 한다> 라는 공통된 목적을 가지고 있습니다.
때문에 많은 CDN 벤더들은 계층형 캐시를 사용할 수 있는 방법을 제공하고 있습니다. AWS 에서 CloudFront 제품의 기능으로 새롭게 출시한 Origin Shild 도 계층형 캐시 기능이라고 보면 거의 맞습니다. 이름에서 느껴지는 것처럼 원본 (=Origin Server) 입장에서 봤을 때 제한적인 IP 에서만 접근이 이루어진다는 보안 관점의 효과를 제외하면 2차 캐시라고 봐도 무방합니다.
AWS CloudFront 가 제공하는 계층형 캐시
AWS 의 CloudFront 는 컴퓨팅 자원들과는 조금 다른 리전을 기반으로 합니다. Edge Location 이라고 불리우는 이 리전들은 CloudFront 엣지 서버들과 Route53 의 자원들을 중심으로 일부 제품 기능을 수행하는 서버들이 위치한 리전입니다. CloudFront 로 일컫어지는 AWS 의 CDN 제품을 생각해보면 사용자로부터 1-hop 거리에 있는 캐시 서버가 동작하고 있는 리전이기도 합니다.
일반적으로 이러한 Child Cache 서버들은 댓수가 많기 때문에 상대적으로 캐시 효율이 떨어질 수 있습니다. 캐시의 기본은 요청을 집중시키는 것이기 때문에 넓은 지역에 퍼져 사용자들로부터 적은 지연을 확보하는 것과 반비례 관계에 있습니다. 이를 보완하기 위해 AWS 의 CloudFront 가 제공하는 것이 REC, Regional Edge Cache 로 불리우는 상위 캐시 레이어입니다.
출처 : AWS CloudFront 제품 소개 페이지
AWS 에서 종종 봤을 위의 그림을 보면 Edge Location, 즉 사용자 접점의 캐시가 배치된 리전은 가능한 넓은 지역에 퍼져 있는 것을 볼 수 있습니다. 반면 오렌지색 원으로 표현된 Regional Edge Cache, 즉 상위 레이어의 캐시 혹은 2차 캐시는 특정 지역 (=보통 컴퓨팅 리전과 일치합니다) 에만 배치되어 있는 것을 볼 수 있습니다.
일반적으로 Edge Location 에 비하여 REC 의 서버들은 스토리지 공간이나 컴퓨팅 파워가 더 우수한 것으로 알려져 있습니다. 요청들이 원본 서버로 전달되기 전에 한번 거쳐가는 레이어이기 때문에 더 여유로운 장비를 배치하는 것이 당연합니다. 이처럼 계층형 캐시를 제공함으로써 CloudFront 는 1) 원본으로 전달되는 요청을 줄이고, 2) AWS 네트워크 내에서 가능한 트랜잭션을 처리함으로써 사용자 입장에서 더 좋은 컨텐츠 전송 지연 경험을 해주도록 설계가 되어 있습니다.
Origin Shield 도 REC다!?
이러한 CloudFront 의 구성에서 Origin Shield 는 어떤 차이를 가지고 있는걸까요? 결론을 먼저 이야기하면 Origin Shiled 도 REC 의 일부입니다. REC 는 앞서 보신 그림에서 나타난 것처럼 Edge Location 보다는 Pop이 적지만 여전히 여러 곳에 퍼져 있습니다. 이들 중 원본 서버에서 가까운 혹은 선호하는 REC 리전을 지정해 줌으로써 1) 사용자는 자신에게서 가까운 Edge Location 으로 접근, 2) Edge Location 은 캐시 효율을 위해 REC 에 접근, 3) REC 는 (도메인에 따라) Origin Shield 역할로 지정된 REC 에 다시 한 번 접근함으로써 캐시 효율을 높이고 원본 서버에게 제한적인 대역에서의 접근을 보장할 수 있게 됩니다.
결국 Origin Shield 도 REC 라는 것이 여기에서의 한줄 요약입니다. 당연히 캐시 효율은 높아질 수 있고 원본에서는 접근하는 대역을 제한 함으로써 보안적인 효용을 얻을 수 있게 됩니다. 사실 REC 는 사용자가 사용 유무를 제어할 수 없다는 것이 한계였고, 상황에 따라서는 (보통은 no-store 성격의 컨텐츠 전송시) Edge Location 이 REC 를 경유하지 않는 경우가 발생하곤 했습니다만 Origin Shield 를 이용할 경우 지정된 REC 를 언제든 경유한다는 장점이 생기게 됩니다.
AWS Elemental 의 예이지만 일반 캐시도 다르지 않습니다
비용 계산은 어떻게 될까?
그렇다면 비용 계산은 어떻게 되는 걸까요? AWS 를 사용하면 참 편리하고 좋은 것들이 많지만 늘 걱정되는게 비용이기 때문에 비용은 확실하게 확인하고 넘어갈 필요가 있습니다. Origin Shiled 는 기본적으로 REC 이기 때문에 기존의 REC 의 가격 정책과 마찬가지로 과금을 안하는 것이 기본입니다. 다만, REC 가 요청량, 전송량 모두에 대해 별도 과금이 없는 것과 달리 Origin Shield 경유시 요청량에 대한 과금이 발생합니다. (전송량 단위의 과금은 없습니다)
AWS 의 가격 테이블을 확인해보면 어떤 리전에 위치한 REC 를 사용하는가에 따라 위의 테이블에 나온 것과 같은 요청량 기반의 과금을 하게 됩니다. 테이블에 나와 있는 가격은 1만개의 요청당 요금이기 때문에 사용중인 도메인에서 발생하는 원본으로의 요청이 얼마나 되는가가 과금에 영향을 주게 됩니다.
여기서 또 중요하게 봐야 할 비용 관련 부분은 Origin Shield 로 지정된 리전이 2차 캐시 레이어로 활용되었는가? 하는 부분입니다. 앞서 언급드린 것처럼 Origin Shield 리전도 REC 이기 때문에, Edge Location 이 직접 Origin Shield 로 지정된 리전을 접근한 경우는 증분 레이어 Incremental Layer 로 인정하지 않아 과금되지 않습니다. 다만 다른 REC 를 경유해서 Origin Shield 로 지정된 리전에 접근했을 경우만 증분 레이어로 보고, 요청량을 카운트하여 과금하게 됩니다
아따 복잡하다...
위의 설명에 나온 것처럼 1) 동적인 컨텐츠, 2) 캐시 컨텐츠 유무에 따라 과금 요청량 카운트는 또 달라집니다. 동적인 컨텐츠는 캐시되지 않기 때문에 언제나 Origin Shield 를 경유해서 원본으로 전송됩니다. 이 요청들은 모두 과금 대상 요청이 됩니다. 반면 캐시 가능한 컨텐츠의 계산은 조금 다릅니다. <캐시 가능한 요청수 x (1-캐시히트율) x REC 에서 Origin Shield 를 통해 원본으로 전송된 비율 x Origin Shield 과금 기준> 계산을 통해 과금 대상 요청량을 산정하게 됩니다.
언제 쓰는게 유리할까?
AWS 는 과금 정책이 늘 복잡합니다. 이번에 공개된 CloudFront 의 Origin Shield 역시 마찬가지입니다. 그렇지만 CDN 좀 써본 분이라면 아시겠습니다만 2차 캐시의 효과는 요청량이 어느정도 된다면 가성비가 훌륭한편에 속합니다. CloudFront 에서도 2차 캐시를 잘 활용하고 싶다면 Origin Shield 를 써야할 것 같은데, 과연 언제 쓰는게 유리한걸까요?
첫번째 케이스로 실제 비용 청구를 따져보긴 힘들겠지만, 사용자의 경험 관점에서 1) 원본 서버가 위치한 지역에 대다수의 사용자가 위치해있고, 2) 일부 해당 지역외 사용자들이 서비스를 종종 이용할 때가 비용을 적게 들이면서도 효과를 볼 수 있는 대표적인 사례가 될 것 같습니다. 1) 에 해당하는 사용자들은 대부분 Origin Shield 레이어를 증분 레이어로 쓰지 않을거라 비용 추가 부담이 적을 겁니다. 2)에 대당하는 사용자들은 약간의 비용 기여(?)를 하겠지만 REC - Origin 구간의 네트워크에서 발생하는 불확실성을 줄여준고 캐시 효율을 높이는 관점에서 사용에 대한 의미가 있을거라 생각합니다.
이런 대표적인 시나리오에서는 확실히 써주는 것이 좋을거라 봅니다만 그 외의 케이스들에서는 일부 트래픽의 적용 등을 통해 검증이 필요합니다. 아시겠지만 모든 케이스에 두루 적용되는 솔루션은 현실 세계에서는 거의 없기 때문이겠지요. 새롭게 런칭된 AWS CloudFront 의 Origin Shield 기능을 통해 사용자 경험을 향상시키는 계기를 만들어 보시기 바랍니다.
Facebook 에서 CDN 과 관련한 이야기를 나눌 그룹을 만들어 운영하고 있습니다. 여러 CDN 벤더의 엔지니어들이 참여하고 계시기 때문에 많은 인사이트와 흥미로운 지식들을 얻어가실 수 있습니다.
