728x90

GS네오텍에서 잘 정리해둔 자료가 있어서 읽어보았습니다. 
시장의 싸움은 CMAF와 LL HLS로 압축된 느낌이고 (WebRTC 등은 다른 용도로)
각각은 대부분의 CDN 벤더가 잘 처리해주고 있는 것처럼 생각됩니다.

AWS의 예제로 CloudFront를 사용하는 시나리오가 설명되어 있는데 
다른 특별한 구성이 필요해 보이지는 않는 느낌입니다. 
다만, 내용은 CMAF에 대해서만 염두하고 있는 느낌이고
LL HLS에 대해서는 시험이나 고려되지 않은 것 같습니다. 

https://www.slideshare.net/awskorea/low-latency-live-service-implementation-with-aws

 

AWS 를 활용한 저지연 라이브 (Low Latency Live) 서비스 구현 - 류재춘 컨설턴트/에반젤리스트, GS Neo…

라이브 방송의 성장과 더불어 최근 저지연 라이브 (Low Latency Live) 에 대한 관심이 높아지고 있습니다. 본 강연에서는 Low Latency Live 관련 기술적인 배경과 Latency를 줄이는 원리에 대한 설명을 하고,

www.slideshare.net

 

CMAF를 사용하는 경우 Chunked Transfer가 핵심 기술이 되고
LL HLS를 사용하는 경우 Chunked Transfer가 핵심은 아니긴 합니다. 
아래 장표를 보고나서... 이 자료는 CMAF 기반의 Low Latency 구성이구나를 깨달았습니다. 

 

실제 사용자 환경은 정말 다양하고 품질도 천차만별이라
Low Latency 라이브 서비스를 어떻게 구현할 것인지의 고민이 많을 수 밖에 없습니다.
Trade-off 장표가 그런 고민들을 일목 요연하게 보여줍니다. 

 


AWS Document를 뒤져봐도 Low Latency HLS에 대해서는 이렇다할 내용이 없는 것 같습니다. 
규격상 몇 가지 걸리는 부분들이 있고 CloudFront에 대해서도 고민이 되는 부분인데
조금 더 검색력을 높여 구글신, ChatGPT와 함께 골머리 싸봐야겠습니다.

(추가)
ChatGPT 만세... AWS Elemental MediaPackage가 LLHLS를 지원하네요
셋업해서 한번 시험해 봐야겠습니다!

728x90
728x90

지난주 후반부, 한국 뿐만 아니라 전세계가 시끌시끌했습니다. 
사실상의 서버측 로깅 표준으로 자리잡힌 log4j 로깅 모듈의 보안 취약점이 발견되었고
공격방법이 인터넷에 고개되면서 Zero Day Vulnerability 가 발생했기 때문입니다.

대략 이런 흐름! (출처 : CloudFlare Blog)

 

취약점을 간단히 요약하자면,
"로그로 기록되어야 하는 문자열에 악의적인 내용을 집어넣어 원격지에서 서버의 코드, 명령을 실행할 수 있는 취약점이 있었음"
입니다.

취약점을 통해 외부에 노출되지 않은 LDAP 서버 등으로 악의적인 코드가 담긴 자바 클래스를 전송하고 
log4j 를 통해 이 클래스를 메모리에 로딩하는 방식으로 서버에 침투하게 됩니다. 
이번 취약점은 오래전 SSL 프로토콜의 취약점으로 명성을 날렸던 하트블리드(heartbleed)급으로 알려졌습니다.

패스틀리 블로그의 이 정리가 가장 깔끔하고 명료합니다!


취약점에 대한 대응은 크게 두가지 방식으로 진행되었습니다. 
1. 취약점이 패치된 log4j 가 배포되기 전까지는 코드 인젝션이 발생할 수 있는 JNDI 의 옵션을 끈다
2. 취약점 패치 버전 (2.15.0+) 가 배포된 후에는 새로운 log4j 로 교체한다

이런 대응이 여러 회사의 개발조직 중심으로 대응되는 동안 
물들어올때 노를 저어야 한다는 것을 잘 알고 있는 클라우드 벤더들은 
열심히 관련된 포스팅을 날리며 자사의 보안 솔루션들을 홍보하기 시작했습니다. 

클라우드 플레어

 

아카마이

 

패스틀리

 

아마존

 


간만에 글로벌 초대형 급의 취약점으로 주말이 시끌시끌 했습니다. 
아직까지 취약점은 현재 진행형이기 때문에 두눈 부릅뜨고
log4j 를 쓰는 곳이 없는지 살펴봐야 하겠습니다!

728x90
728x90

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 이 있다고 해봅시다.

아마도 여러분이 기대하는 것은 www.iamnopd.com  접근시에도 index.html 을 읽어들이고 www.iamnopd.com/api  접근시에도 index.html 을 읽어들여 사용자에게 제공되는 시나리오였을겁니다. 하지만 첫번째 케이스와 달리 두번째 api 경로에 대한 접근은 index.html 을 알아서 패칭해오지 않습니다. 반드시 www.iamnopd.com/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 함수로 지정하면 됩니다. 끝!

 

 

 

 

728x90
728x90

Cloud Platform 을 사용할 때 가장 조심해야 하는 것 중 하나가, 각 플랫폼이 가지고 있는 QoS (Quality of Service) 수치를 넘지 않도록 해야 한다는 것입니다. 물론, 이 수치는 Support Ticket 등을 통해 늘리는 것이 가능하지만 시간이 소요될 수 있기 때문에 이벤트 등 대규모 사용자가 몰리는 이벤트가 준비중이라면 미리 체크를 해두어야 합니다. 

CDN 제품인 AWS CloudFront 도 마찬가지인데요, 적용되고 있는 여러가지 제한 중 이벤트 트레픽에 대한 고려사항은 크게 1) 대역폭에 대한 Limit 과 2) 요청수에 대한 Limit 이 있습니다. AWS 공식 문서에서는 `할당량` 또는 `Quotas` 로 제품 문서에서 확인할 수 있는 내용입니다. 


대역폭과 전송량 제한

CloudFront 의 할당량 정책은 기본적으로 Distribution 당으로 적용됩니다. 참고로 시장 지배 사업자인 아카마이 Akamai 의 경우 Bucket 이라는 컨셉이 있고 CP Code 단위로 대역폭에 대한 관리만 하고 있습니다. 아카마이와 달리 CloudFront 의 경우 대역폭과 요청량의 두가지 제한이 있습니다. 

출처 : CloudFront 개발자 안내서

Distribution 을 `배포` 라고 표현하고 있는 부분은 늘 적응이 잘 안되네요. API 에서도 distid 등을 사용하니 Distribution 으로 인지하는 것이 편합니다. 공식 문서에 나온 것처럼 대역폭은 150Gbps 가 기본 제한이고 요청량은 250,000rps 가 기본 제한으로 들어가 있습니다. 바로 아래에 있는 `더 높은 할당량 요청`이 있는 이유는 조정이 가능하기 때문이겠죠? ^^

`더 높은 할당량 요청`을 누르면 Support 페이지로 넘어가고 `Service Limit Increase` 타입의 티켓을 열어 할당량을 높이는 방식입니다. 느낌이 오시겠지만 시간이 좀 걸릴 수 있는 부분이라 예측하지 못한 트레픽 Burst 가 아니고 계획된 이벤트라면 미리 할당량을 조정해 두시는 것이 정석입니다. 

 

할당량 초과는 어떻게 알 수 있을까?

CloudFront 에서는 위의 할당량이 초과 되었다 하더라도 알려주는 것은 없습니다. 요행히 CloudWatch 로 Distribution 의 에러 비율에 대한 알람을 걸어두었다면 메일을 통하여 한템포 늦게 인지할 수 있는 방법이 있긴 합니다. 다른 방법으로는 CloudFront 의 Monitoring 화면에서 사용자의 트레픽이 급격히 늘면서 5xx 에러가 증가했는지를 확인하는 방법이 있습니다.

후행적으로 확인하는 방법은 (이미 장애는 났고... 사용자는 영향을 받았고...) CloudFront 의 Access Log 를 통하는 방법이 있습니다. Access Log 의 필드중 2020년 12월 3일 기준으로 14번째 컬럼인 `x-edge-result-type` 이나 23번째 컬럼인 `x-edge-response-result-type` 의 값을 이용해서 확인할 수 있습니다. 

14번째 컬럼의 값
23번째 컬럼의 값

이 필드의 값으로 `LimitExceeded` 가 특히 할당량, Limit 초과에 대한 부분입니다. 문제는 LimitExceeded 가 어떤 Limit 을 초과한 것인지를 알려주지 않습니다. 알고 싶다면 <또> Support Ticket 을 열어야 합니다. 해보신 분들은 아시겠지만 Ticket 을 열면서 꼭 샘플 로그를 추출해서 제공해 주셔야 합니다. 


용량관리는 인프라에서 무척 중요한 부분입니다. 우리가 클라우드 서비스를 이용하는 이유중 하나는 그런 용량 관리로부터 조금이나마 자유롭고 싶어서 이지만, 결국 클라우드 서비스도 그들 입장에서는 용량관리를 해야만 합니다. 때문에 위와 같은 제한들이 존재하고 사용하고 있는 사업자의 숫자들을 기억해 둘 필요가 있습니다. 

> 참고 URL

 

할당량 - Amazon CloudFront

할당량 CloudFront에는 다음 할당량(이전에는 제한으로 지칭)이 적용됩니다. Lambda@Edge에는 기본 CloudFront 할당량에 추가하여 적용되는 특정한 할당량도 있습니다. 일반 할당량 엔터티 기본 할당량

docs.aws.amazon.com

 

표준 로그(액세스 로그) 구성 및 사용 - Amazon CloudFront

모든 이벤트에 대한 값이 있는 필드도 있고 재생, 중지, 일시 중지, 일시 중지 취소 및 탐색 이벤트에 대한 값만 있는 필드도 있습니다. 일반적으로 로그 파일에서 필드에 대해 하이픈(-)이 포함

docs.aws.amazon.com

 

728x90

+ Recent posts