스트리밍 미디어 렌즈로 보는 미디어 스트리밍 모범 사례

AWS Well-Architected는 고객이 아키텍처를 평가하고 확장 가능한 디자인을 구현하는 일관된 방법을 제공합니다. 사용자는 운영 우수성, 보안, 안정성, 성능 효율성, 비용 최적화 및 지속 가능성이라는 6개의 원칙에 기반하여 아키텍처를 평가하고 워크로드의 기술적 위험을 평가하고 식별할 수 있습니다.

이번 글에서 말씀드릴 Streaming Media Lens는 고객이 스트리밍 미디어 워크로드를 설계하고 배포하는 과정에서 일반적인 워크로드 시나리오를 탐색하여 AWS Well-Architected Framework를 미디어 스트리밍 솔루션에 적용하고자 하는 고객에게 도움을 드리는 데 초점을 맞추고 있습니다.

개요

AWS Well-Architected Framework의 Streaming Media Lens는 사용자의 요구사항 에 적합한 아키텍쳐 디자인 및 사전 준비사항에 대한 의사 결정을 내릴 수 있는 가이드를 제공하고 있습니다. 이는 AWS가 미디어 스트리밍 솔루션을 AWS에서 구축한 고객들로부터 배운 내용에 기반하고 있습니다. 다음 글을 통해 Well-Architected Framework를 구성하는 데, 필요한 각 원칙의 모범 사례 및 고려사항에 대한 내용을 확인해보도록 하겠습니다.

6개 원칙과 정의

운영 우수성 : 미디어 워크로드 운영 효율성 달성
예) 시스템 모니터링, 콘텐츠 자동 수집 및 처리, 콘텐츠 배포 전략
보안 : 미디어 콘텐츠, 고객 정보, 시스템 프로세스 및 인프라를 무단 공격으로부터 보호
예) 콘텐츠 저장 및 전송 시 암호화
안정성 : 올바르고 일관되게 의도된 기능을 수행하는지 결정
예) 장애 시나리오에서 복구할 수 있는 디자인, , 단일 지점 장애를 피하기 위한 중복성 제공
성능 효율성: 요구사항을 충족하는 효율적인 컴퓨팅 자원 사용
예) 모든 크기의 스트리밍 이벤트의 성능 기준을 충족
비용 최적화: 불필요한 지출을 피하고 워크로드 전반의 비용을 추적하여 비용을 최적화
예) 비용 효율적인 디자인을 구축하여 비지니스 ROI를 극대화
지속 가능성: 필요한 자원을 최소화하여 에너지 소비를 줄이고 효율성을 높임
*Streaming Media Lens에서는 지속 가능성에 대한 내용은 포함하고 있지 않습니다.

원칙 1: 운영 우수성

클라우드에서 운영 우수성을 달성하기 위해선 1) 준비, 2) 운영 영역을 고려해야 합니다.

준비

미디어 스트리밍 워크플로 구축에 있어 준비 단계는 매우 중요합니다. 철저한 준비를 통해 운영 이슈를 방지할 수 있으며, 운영 단계가 아닌 디자인 단계에서 수정하는 것은 비용적으로도 효율적입니다. 대표적으로 부하 테스트를 통해 가변적인 스트리밍 이벤트를 사전에 대비하고 인프라 디자인의 안정성을 확보할 수 있습니다. 오리진 서버의 TPS를 예측할 수 있는 계산식을 제공하고 있으나, 고객이 보유한 사용량 예측 툴, 지표를 사용하는 것을 권장합니다. 아래는 HLS, DASH 각 스트림에 대한 TPS 계산법입니다.

스트리밍 프로토콜	조건 예시	TPS 계산식
HLS	기본 스트림 세그먼트 수: 3 세그먼트 길이: 6CHR(Cache Hit Ratio): 95% 시청자 수: 10	시청자 수 * (2 x (기본 스트림 세그먼트 수) / (세그먼트 길이)) x (1-(CHR)) = 0.5 TPS
DASH		시청자 수 * (4 / (세그먼트 길이)) x (1-(CHR)) = 0.33 TPS

[고려사항]

AWS는 매우 큰 스트리밍 이벤트를 처리할 수 있지만 추가 리소스를 사용하고자 하는 경우, Service Quotas에서 신청하거나 Support를 활용할 수 있습니다.
라이브 이벤트와 같이 즉각적인 지원이 필요한 경우, AWS인프라 이벤트 관리 혹은 엘리멘탈 미디어 이벤트 관리 이용을 고려할 수 있습니다.

운영

라이브 스트리밍에서 컴포넌트 간의 관계를 알고 시그널을 추적하는 것은 이슈를 대응하는 데 있어 매우 중요한 요소입니다. 미디어 워크플로의 실시간 상태를 보여주는 시각화 된 자료를 활용하거나 지표를 나타내는 대시보드를 통해 모니터링하고 특정 임계 값에 도달할 경우, 알람을 보내는 방법 등을 활용하여 문제 해결을 가속화할 수 있습니다. 대표적인 서비스로 Amazon CloudWatch, AWS CloudTrail, Amazon SNS가 있으며, ‘AWS MediaLive, AWS MediaPackage기반 라이브 스트리밍 워크플로 Observability 확보하기’ 기술 블로그를 통해 손쉽게 운영 상태를 모니터링하고 알림을 받는 아키텍처를 구성할 수 있습니다

원칙 2: 보안

클라우드에서의 보안을 달성하기 위해서는 1) 접근 제어, 2) 위협 탐지, 3) 인프라 보호, 4) 데이터 보호, 5) 대응 5가지 영역을 고려해야 합니다.

접근 제어

스트리밍 미디어 워크로드에서는 많은 양의 오디오, 비디오를 시청자에게 전달하게 되는 데, 그 중에는 상업적으로 민감하고 높은 가치를 지닌 콘텐츠들이 포함됩니다. 따라서 모바일, 데스크톱, 스마트TV, 웹 등을 통해 콘텐츠에 접근을 하는 모든 경우에 인증/인가 절차를 도입하고 사용자의 구독 여부에 따라 컨텐츠 제공을 제어할 필요가 있습니다.

[AWS에서 Amazon Cognito를 IdP(ID제공자)로 사용할 수 있습니다.]

이를 통해 사용자는 Amazon Simple Storage Service (Amazon S3), AWS Element MediaPackage, AWS Elemental MediaStore, Amazon Elastic Compute Cloud (Amazon EC2)기반 서비스에서 제공되는 컨텐츠로의 접근을 제어할 수 있습니다.
Amazon Cognito를 사용하면 Active Directory Federation Services , Okta와 같은 SAML 제공자, Auth0과 같은 OIDC 제공자 및 Google, Twitter 또는 Facebook과 같은 다른 공용 ID 제공자와 ID 풀을 연합할 수 있습니다.
Amazon API Gateway 혹은 AWS AppSync와 같은 서비스와 통합하여 리소스 접근을 중앙 관리하고 접근을 허용, 거절하는 로직을 추가 작성하는 방법이 있습니다.

[Amazon CloudFront를 유용하게 활용할 수 있습니다.]

Amazon CloudFront는 서명된 URL 및 서명된 쿠키를 통해 콘텐츠 원본에 대한 접근을 제어할 수 있고 이를 통해 인증된 사용자의 악의적인 작업으로부터 데이터를 보호할 수 있습니다.
TLS를 통해 전송된 CDN에 의해 주입된 비밀 헤더를 확인하여 무단 오리진 액세스로부터 콘텐츠 오리진을 보호할 수 있습니다.
AWS Elemental MediaStore를 오리진으로 사용할 경우, 사용자-에이전트 헤더 값이 IAM Policy Conditions와 함께 공유 암호 값으로 설정된 경우에만 컨테이너에 대한 요청을 수락하도록 설정할 수 있습니다. 자세한 내용은 링크를 확인하세요.
Amazon S3로부터 VOD콘텐츠를 제공하는 경우, Amazon CloudFront의 오리진 액세스 제어(OAC)와오리진 액세스 ID(OAI)기능을 사용하여 S3로 직접 콘텐츠를 요청하는 것을 방지할 수 있습니다. 자세한 내용은 링크를 통해 확인하세요.
AWS Elemental MediaPackage를 사용하는 경우, CDN 인증을 통해 사용자가 오리진의 콘텐츠에 직접 접속하기 위해 CDN을 우회하는 경우를 방지할 수 있습니다

위협 탐지

자격 증명 공유, 손상 혹은 유출로 인해 콘텐츠에 대한 무단 액세스가 발생할 수 있고 이는 서비스의 품질 저하 및 운영 이슈로 이어질 수 있습니다. 따라서 클라이언트 및 인프라 로깅을 사용하여 콘텐츠 접근을 분석하고 필요시 대응할 수 있습니다.

[로그 수집 활성화]

Amazon CloudFront로그에서 요청자의 지리적 위치, IP, 혹은 쿼리 스트링 정보로 표시된 웹 요청 정보(아래 예시의 빨간색 정보)를 확인할 수 있습니다.
https://d111111adcdef8.cloudfront.net/images/image.jpg?color=red&size=large
S3 서버 액세스 로깅을 활성화하여 버킷에 수행된 모든 요청에 대한 상세 레코드를 확인할 수 있습니다.
AWS Elemental MediaLive의 채널 인코더 로그를 활성화하여 채널 별 상세 로그를 확인할 수 있습니다.
AWS Elemental MediaPackage의 액세스 로깅을 활성화하여 상세 송/수신 로그를 확인할 수 있습니다.

[데이터 쿼리]

Amazon Athena를 사용하여 Amazon S3에 수집된 데이터를 쿼리할 수 있습니다.
예) 제공범위가 아닌 리전에서 서비스 요청이 들어오는 경우
AWS CloudTrail Lake를 사용하여 리전, 계정 단위의 활동 로그를 쉽게 쿼리할 수 있습니다

[워터마킹]

단순 콘텐츠에 대해서는 이미지 오버레이 형태의 워터마킹 방법을 적용하여 추적합니다.
대규모 이용자를 대상으로 하는 경우, 세션 기반 워터마킹 방법을 적용하여 추적합니다.

인프라 보호

스트리밍 미디어의 인프라 보호는 데이터의 수집 및 업로드, DRM 서비스 및 클라이언트를 포함하여 모든 자원을 예기치 않은 또는 불법적인 액세스 또는 잠재적인 취약점으로 부터 보호하는 것을 의미합니다.

[전송 및 업로드 시 보호]

TLS를 사용하여 게시자와 소비자 엔드포인트 간에 콘텐츠가 가로채지는 것을 방지합니다.
AWS Global Accelerator와 같은 에니캐스트 네트워크를 사용하여 공개 네트워크 경로에서의 글로벌 연결성을 간소화합니다.
AWS Direct Connect 및 Direct Connect Gateway를 사용하여 네트워크를 AWS 리전에 연결하고 AWS 벡본을 통해 통신함으로써 콘텐츠 소스와 클라우드 인프라 간의 공개 네트워크 경로를 우회합니다.
AWS PrivateLink를 사용하여 AWS를 사용하는 파트너와 작업할 때 연결성을 확립합니다.
AWS Snowball Edge를 사용하여 대량의 데이터를 AWS 클라우드로 전송합니다.

[콘텐츠 오리진 보호]

AWS Shield를 사용하여 Amazon CloudFront 및 Amazon Route53와 같은 AWS리소스를 분산 서비스 거부 (DDoS) 공격으로부터 보호할 수 있습니다. AWS Shield는 기본 무료로 제공됩니다.
AWS Shield Advanced를 사용하여 SYN/UDP flood, reflection attack과 같은 주요 인프라(레이어3 및4) 공격으로부터 Elastic Load Balancing, Amazon EC2 및 AWS Global Accelerator와 같은 서비스 위에 구축된 리소스를 보호합니다.
DDoS공격이 콘텐츠 원본에 영향을 미치는 가능성을 최소화하기 위해 CDN의 IP주소 범위를 지정하여 신뢰할 수 있는 클라이언트 IP주소만 허용하도록 제한합니다.
AWS Elemental MediaLive, AWS Elemental MediaPackage 혹은 EC2에서 호스트 하는 서비스의 경우, 보안 그룹(Security group)을 사용하여 유입 트래픽의 범위를 제한해야 합니다.
AWS Application Load Balancer나 Amazon CloudFront를 사용하는 경우, AWS WAF(Web Application Firewall)를 사용하여 알려진 IP 주소에서 오는 요청을 검증할 수 있습니다. AWS WAF를 사용하면 IP 주소, HTTP 헤더 및 본문 또는 사용자 정의 URI를 기준으로 웹 트래픽을 필터링하는 규칙을 생성할 수 있습니다.

데이터 보호

Clear Key 콘텐츠 암호화 및 DRM 시스템은 일반적인 콘텐츠 보호 체계입니다. 둘 다 콘텐츠를 암호화하기 위해 AES-128을 사용하지만 키가 관리되고 전달되는 방식이 다릅니다. Clear Key 구현은 DRM 시스템보다 간단하며 대부분의 적용 사례에서 적절합니다.

[Clear Key 암호화]

AWS에서는 Clear Key 암호화를 위해AWS Key Management Service (AWS KMS)키를 생성하고 데이터 키를 생성하여 암호화를 적용합니다. 이 데이터 키는 Amazon S3 또는 Amazon DynamoDB와 같은 지속적이고 확장 가능한 레이어에 저장됩니다. 데이터 키에 대한 접근은 Amazon Cognito 및 AWS Identity and Access Management (IAM) 정책을 사용하여 대상 그룹에게 부여됩니다.

[DRM 시스템]

DRM 시스템은 Apple FairPlay, Google Widevine 또는 Microsoft PlayReady와 같은 시스템으로 구현됩니다. AWS Media Services에서 DRM 시스템은 Secure Packager and Encoder Key Exchange (SPEKE) API를 통해 구현됩니다. SPEKE는 키 공급자가 키 자료 및 메타데이터를 교환하기 위한 오픈 표준 프록시 인터페이스를 제공합니다.

*MediaConvert DRM구현 및 MediaPackage DRM 구현을 통해 DRM 구현 방법을 확인하실 수 있습니다.

대응

올바른 예방 및 탐지 대책이 있더라도 조직은 여전히 보안 사건 대응 및 완화 프로세스를 수립해야 합니다. 로깅, 이벤트 기반 처리, 모니터링, 게임 데이와 같은 프로세스 외에도 불법적인 콘텐츠 재 배포 및 지적 재산 침해에 대한 대응 계획도 수립해야 합니다. AWS 이용목적제한방침에 따르면 사용자는 불법적이거나 해로운, 사기적인, 침해적이거나 불쾌한 콘텐츠를 AWS 서비스를 통해 전송, 저장, 표시, 배포 또는 제공할 수 없습니다. AWS 서비스를 통해 콘텐츠가 불법적으로 배포되고 있다고 의심될 경우, AWS 지원팀에 연락하고 AWS의 신고 절차를 따르는 단계가 포함되어야 합니다.

원칙 3: 안정성

클라우드에서의 안정성을 달성하기 위해선 1) 워크로드 아키텍쳐, 2) 변경 관리, 3) 장애 관리 3가지 영역을 고려해야 합니다.
*Foundations 역시 안정성을 위한 영역 중에 하나이지만 스트리밍 미디어 렌즈 에는 포함되지 않아 다루지 않습니다.

워크로드 아키텍쳐

고가용성 미디어 스트리밍 워크플로우를 위해서는 전체 구성 요소에서 중복성을 고려한 설계가 중요합니다. 라이브와 VOD 각 워크플로의 고가용성 디자인에 대해 알아보겠습니다.

[고가용성 라이브 워크로드 디자인]

비디오를 수집하는 경로와 AWS Cloud로 전송하는 과정에서 중복성을 갖춘 네트워크 경로를 구축하여 단일지점장애를 피하고 고객 경험을 유지하는 것이 좋습니다. 예를 들어, 아래 예시는 좌측의 Source A와 Source B는 중복 입력되는 메자닌(Mezzanine) 소스입니다. 또한, 각 Contribution Encoder(기여 인코더)는 두 개의 기여 피드 세트를 출력하며, 이들은 동일한 SMPTE 2022-7 호환 네트워크 패킷 스트림(동일한 색상 화살표 라인으로 표시)을 갖습니다. 이를 통해 별도의 네트워크 경로를 통해 전송이 가능하며, 한 경로의 패킷이 손실되더라도 두 번째 스트림의 패킷을 사용하여 데이터를 복구할 수 있습니다.

비디오 수집의 경우, AWS Direct Connect를 사용해서 전용 네트워크 경로를 제공받거나 AWS Elemental MediaConnect Flows를 사용하여 안정적으로 라이브 비디오를 전송하고 네트워크 패킷 레벨에서 SMPTE 2022-7 사양을 준수하는 장애 조치를 제공할 수 있습니다.

AWS Elemental MediaLive의 ‘표준 채널(Standard channel)’을 사용하면 2개의 중복 인코딩 파이프라인이 각각 하나의 (AZ)에서 구성되고, 이를 통해 스트림 무결성을 유지하면서 장애 상황에서 실시간 전환이 가능하게 구성할 수 있습니다.

배포의 경우, 고가용성, 성능 및 지리적 커버리지를 위해 멀티 CDN전략을 사용하는 것이 좋습니다. 이를 통해 지리적 위치와 사용 가능한 용량에 따라 트래픽을 분산시킬 수 있으며, 하나 이상의 CDN PoP에서 장애 또는 과다 구독(over-subscription)에 대한 보호도 제공합니다. 각 CDN에서 실시간 QoS 데이터(오류율, 버퍼율, 대기 시간 등)를 수집하여 고객에게 최상의 전달 경로를 결정하고 성능, 비용, 다른 비지니스 고려사항에 따라 CDN에 트래픽을 할당할 수 있습니다.

[고가용성 VOD 워크로드 디자인]
안정성 있는 VOD 디자인을 위해 두 가지 접근법이 있습니다.

VOD 원본 안정성 – 작은 양의 컨텐츠를 출판하는 플랫폼의 경우, 새 컨텐츠를 출판하는 데 중단이 있을 수 있지만, 워크로드 장애 시, 시청자가 문제없이 컨텐츠를 재생할 수 있어야 한다는 비즈니스 목표가 존재합니다. 이 경우, 컨텐츠를 안전하게 여러 개의 원본 서비스에 복제하여 CDN이나 클라이언트 장치가 기본 엔드포인트에서 재생할 수 없을 때 대체 원본에서 재생하도록 구성합니다. 컨텐츠를 원본 서비스에서 복제하는 방법으로는 Amazon S3 Cross-Region Replication (CRR)을 이용할 수 있습니다.
VOD 처리 및 원본 안정성 – 애플리케이션 전체 기능이 중단되지 않아야 하는 경우입니다. 이는 데이터를 실시간으로 수집하고 신규 콘텐츠를 처리하는 모든 과정을 포함합니다. 다중 리전, Multi-CDN 전략을 통해 스트리밍 아키텍처가 두 개의 AWS 리전에서 운영되도록 하고 DNS 요청을 라우팅하는 데 사용할 수 있습니다. 관련 서비스는 AWS Elemental MediaConvert를 참조하세요.

변경 관리

AWS CloudFormation서비스를 사용하여 배포, 테스트, 롤백을 자동화하는 것을 권장합니다. AWS CloudFormation 서비스를 사용하면 인프라 상태가 코드로 표시되며 버전 관리가 가능하므로 팀이 정기적으로 작은 변경 사항을 수행하고 쉽게 과거 운영 환경으로 돌아갈 수 있습니다. 추가적으로 워크플로를 구성하는 구성 요소에 대한 일관된 네이밍 규칙을 생성하여 문제 해결을 쉽게 하실 수 있습니다. 예를 들어, 서비스 지역, AZ의 식별자로 구분하면 업데이트가 필요한 서비스 요소를 구별하기 용이합니다.
Amazon Route 53을 사용하여 가중치 기반 라우팅 정책(Weighted routing policy)을 통해 가중치를 설정한 여러 레코드 집합을 정의합니다. 이를 통해 멀티 CDN사용 시, 가중치 기반 라운드 로빈(round-robin)방식으로 부하를 분산할 수 있습니다. DNS 기반 구성은 구현하기 쉽고 네트워크 조건에 따라 주기적으로 변경할 수 있으며 CDN 장애의 충격 범위를 최소화하는 등의 이점이 있습니다. 하지만 DNS 변경이 즉각적으로 시스템에 반영되지 않을 수 있으며 일부 시스템은 TTL 이슈가 있을 수 있습니다. 따라서, 클라이언트 재생 버퍼가 작고 네트워크 저하가 즉각적인 영향을 미칠 수 있는 라이브 이벤트의 경우에는 CDN을 초기화할 때 동적 HTTP 기반 접근 방식을 권장합니다.

장애 관리

장애 상황에서 원인 분석은 오리진 컴포넌트에서 문제가 발생한 시나리오에서부터 시작해야 합니다. 업스트림 의존성이 높은 경우나 내부 서비스 장애로 인해 오리진에 문제가 발생할 수 있으며, 이를 방지하기 위해서 구성 요소 레벨에서 중복성을 갖추어 의존성을 낮출 수 있습니다.

[라이브 스트리밍 방안]

라이브 스트리밍에서는 빈번한 매니페스트 업데이트가 발생합니다. 원본에서 라이브 스트림 매니페스트가 일정 기간동안 수신되지 않을 경우, 플레이어가 재생을 다시 버퍼링하거나 완전히 중지하여 고객 경험을 손상시킬 수 있습니다. 4xx, 5xx 오류 및 높은 응답 대기 시간 외에도 오래된 라이브 매니페스트(stale manifest)에 대해 경고하도록 오리진 모니터링을 설계해야 합니다. 예를 들면 매니페스트가 2배 – 5배 세그먼트 크기(2초 세그먼트의 경우, 4 – 10초) 동안 변경되지 않았다면 건강한 오리진으로 요청을 재 라우팅하는 것을 고려할 수 있습니다.

AWS Elemental MediaStore를 라이브 스트리밍 원본으로 사용할 경우, 개체 수명 주기 정책 API(Object Lifecycle policy)를 통해 컨테이너에 임시 데이터 정책(Transient Data Policy)을 구성할 수 있습니다. 이 기능은 플레이어가 자동으로 기본 오리진에서 백업 오리진으로 전환할 수 있도록 최근 업데이트되지 않은 경우 오리진에서 HLS 매니페스트를 제거합니다.

[VOD 방안]

VOD자산에 자주 사용되는 일반적인 접근 방식은 CDN에서 제공하는 오리진 페일오버 로직을 사용하는 것입니다. 오리진 상태 점검 구현은 클라이언트에 투명하게 보여지며, 구현도 쉽습니다. 일반적으로 기본 오리진의 요청이 실패 코드로 응답하거나 너무 오래 걸릴 경우 트래픽을 대체 오리진으로 리디렉션하여 작동합니다.

원칙 4: 성능 효율성

클라우드에서의 성능 효율을 달성하기 위해선 1) 선택, 2) 검토, 3) 모니터링, 4) 트레이드 오프 4가지 영역을 고려해야 합니다.

선택

[오리진 선택]

워크로드의 성능을 최적화하는 오리진 접근법에는 패스스루 오리진(Pass-through Origin)과 동적 오리진(Dynamic Origin)이 존재합니다. 패스스루 오리진은 빠른 응답 시간과 낮은 비용으로 제공되는 고성능 HTTP 서버입니다. 인코더가 사전에 인코딩, 패키징, 암호화를 수행한 콘텐츠를 AWS Elemental MediaStore나 Amazon S3와 같은 오리진 서버에 전송하며 추가적인 미디어 처리 기능이 필요하지 않습니다. 그러나, 한개의 프로세싱 된 미디어로 다중 프로토콜 지원이 필요한 경우, 플레이어가 지원을 한다면 CMAF를 사용하는 것이 스토리지 비용, 속도 측면에서 유리합니다.

동적 오리진은 인코더가 하나의 형식으로 콘텐츠를 원본에 PUT하고 요청에 따라 동적으로 형식을 지정하여 제공하는 프로세스입니다. JITP라고도 하는 이 프로세스는 재생 장치에서 콘텐츠를 요청하면 라이브 비디오 스트림을 요청 장치와 호환되는 형식으로 매니페스트를 만듭니다. 대표적인 서비스는 AWS Elemental MediaPackage가 있습니다. 동적 오리진은 내부 버퍼를 사용하여 콘텐츠를 JITP 처리하기 때문에 패스스루 오리진과 비교했을 때 라이브 스트림 지연이 발생할 수 있습니다.

[속도 제어 모드 선택(Rate control mode)]

품질 기반 가변 비트 전송률(QVBR): Over the internet(OTT), VOD에 적합한 모드입니다. QVBR을 선택하면 인코더는 지정한 비디오 품질을 유지하기 위해 비디오의 각 부분에 사용할 올바른 비트 수를 가변적으로 결정합니다. 아래 예시 상황을 제외한 경우에 적합합니다.

고정 대역폭을 요구하여 일정한 비트율을 설정해야 하는 경우

계약상 또는 규정상의 요건으로 파일 전체 크기를 사용자 지정 사이즈보다 작게 유지하는 경우*QVBR 세팅 권장 사항

해상도	QVBR 품질 레벨	최대 비트 전송률
1080p(1920*1080)	9	6000000
720p(1280*720)	8 / 7	4000000 / 2000000
480p(852*480)	7	1000000

고정 비트 전송률(CBR): 비트 전송률을 일정하게 유지해야 하는 경우에만 CBR을 선택합니다. 예를 들어 제한된 고정 대역폭 네트워크를 통해 자산을 분산하는 경우 일정한 비트 전송률이 필요할 수 있습니다. CBR을 선택하면 인코더는 사용자가 비트 전송률에 설정한 값으로 파일 크기와 품질을 제한합니다. 인코더는 비디오의 모든 부분에 대해 동일한 수의 비트를 사용합니다. 즉, 일정한 품질을 보장하지는 않습니다.
가변 비트 전송률(VBR): 비트 전송률이 가변적이지만 전체 파일 크기를 지정해야 하는 경우 사용합니다. VBR을 사용하면 자산의 평균 비트 전송률을 지정합니다. 인코더는 더 많은 비트가 비디오의 복잡한 부분으로 이동하도록 비트를 할당합니다. 총 파일 크기(컨테이너, 패키징 및 오디오 데이터 제외)는 지정한 평균 비트 전송률(초)에 자산 길이(초)를 곱한 값으로 작동합니다.

[라이브 스트리밍 워크로드]

수집 단계에서 HEVC와 같은 효율적인 코덱을 사용하여 낮은 비용으로 최적 대역폭 사용과 개선된 성능을 달성할 수 있습니다.
AWS Direct Connect는 전용선을 통해 일관된 네트워크 경험을 제공하며 AWS에 지속적인 네트워크 경험(예. 가시성이 높은 라이브 이벤트)이 필요한 서비스에 권장됩니다.
RTMP와 같은 TCP 기반 프로토콜을 사용하는 경우 지연이 발생하고 비효율적일 수 있습니다. 따라서, 실시간 기여에는 RTP, RIST 또는 SRT와 같은 UDP 기반 안정성 있는 전송 프로토콜을 권장합니다.

[파일 기반 워크로드]

Amazon S3파일에 업로드 시에는 Amazon S3 멀티파트 업로드 기능을 사용하십시오.
AWS 지역으로부터 지리적으로 먼 곳에서 콘텐츠를 업로드할 때는, Amazon S3 Transfer Acceleration을 사용하여AWS로의 연결성을 강화할 수 있습니다.
업로드 기간이 1주일 이상이 예상될 때는 AWS Snowball을 사용하는 것이 좋습니다.
온프레미스 인프라스트럭처 환경에서 Amazon S3에 접근하는 하이브리드 아키텍쳐의 경우, AWS Storage Gateway 및 AWS File Gateway를 사용하실 수 있습니다.
S3 수명 주기 관리를 통해서 파일 사용 빈도에 따라 비용 효율적인 티어로 이동할 수 있습니다.

검토 & 모니터링

Amazon CloudFront 모니터링 설정에서 CHR(캐시 히트율), 오리진 지연시간, 그리고 HTTP 에러율 지표를 활성화하고 모니터링 및 대응을 통해 고객 경험을 개선합니다.
CDN은 각 티어에서 LRU (최근에 사용한 캐싱) 전략을 사용함으로 특정 콘텐츠가 다음 요청에 캐싱된다는 보장이 없습니다. 따라서, 오리진에 Cache-Control header 세팅을 통해 원하는 캐싱 기한을 설정할 수 있습니다.
라이브 스트리밍 매니페스트는 빈번하게 변경되므로 세그먼트 길이의 절반 이상 기간 동안 캐싱할 경우, 오래된(stale) 매니페스트를 발생 시킬 수 있습니다.

VOD는 최대한 오랜 기간동안 캐시하는 것이 좋습니다.

시나리오	세그먼트 사이즈	매니페스트 업데이트 주기	세그먼트 캐시 컨트롤 헤더	매니페스트 캐시 컨트롤 헤더
LIVE	10초	10초	21,600초	5초 이하
VOD	10초	고정	86,400초	86,400초 혹은 최대치

캐시 무효화 기능을 사용하고 네거티브 캐싱(negative caching)의 기간은 최소화 합니다.
인프라 로깅 외에 고객의 실시간 데이터를 스트림 받아 모니터링하는 것을 권장합니다. Amazon Kinesis를 사용해서 고객 행동 지표를 스트리밍 받을 수 있고 Amazon CloudWatch에서 이상 징후를 모니터링 할 수 있습니다.

트레이드 오프

비용 대 성능: 고성능을 위한 인프라 운영 환경은 비용이 높아지는 단점이 있으며, 저비용 기반의 구성은 성능이 저하 되는 단점이 있습니다. 이러한 경우에는 비용과 성능을 균형있게 고려해야 합니다.
비디오 품질 대 대역폭: 고화질 비디오를 제공하려면 대역폭이 많이 필요하지만, 대역폭이 제한적인 경우에는 비디오 품질이 저하될 수 있습니다. 이러한 경우에는 자원 최적화와 인코딩 설정 조정 등의 방법을 사용해야 합니다.
지연시간 대 고객 경험: 생방송 중계의 경우, 3-12초의 지연시간이 발생할 수 있습니다. 이 외에도 스트리밍 플랫폼에서 디자인의 선택에 따라 3초에서 최대 90초까지 지연 시간이 발생할 수 있습니다. 이때 지연 시간 최소화를 위한 무리한 설정은 오히려 비디오 품질 저하, 버퍼율, 에러율과 같은 고객 경험과 관련된 크리티컬 한 이슈를 발생할 수도 있습니다.
인프라 대 클라이언트 데이터 수집: 인프라 로깅 및 모니터링은 전체 이미지 중 일부만 제공하며, 고객의 실시간 데이터를 수집하기 위해서는 추가적인 데이터 전송 비용이 발생할 수 있습니다. 하지만, 실제 사용자 데이터를 모니터링하고 로깅하여 분석을 위한 신규 워크로드를 구축하거나 서비스 성능을 개선하는 데 중요하게 사용될 수 있습니다.

원칙 5: 비용 최적화

클라우드에서의 비용 최적화를 달성하기 위해선 1) 클라우드 재정 관리 연습, 2) 지출 및 사용에 대한 인식, 3) 비용 효율적인 리소스 사용, 4) 수요 및 공급 리소스 관리, 5) 지속 최적화 5가지 영역을 고려해야 합니다.

*해당 글에서는 3) 비용 효율적인 리소스 사용, 5) 지속 최적화 영역만 다룹니다.

비용 효율적인 리소스 사용

미디어 아카이빙을 위해 오브젝트 스토리지를 사용하여 높은 내구성을 확보합니다.
스토리지 생명주기 및 데이터 전송 관련 전략을 우선 순위에 두는 것을 권장합니다. 초기 단계에서는 Amazon S3 Analytics and Insights를 활용하여 자산에 대한 접근 패턴을 모니터링하고 비용 효율적인 Amazon S3 스토리지 티어에 이동하도록 설정합니다. 접근 패턴을 파악하지 못할 경우, Amazon S3 Intelligent Tiering 스토리지 클래스를 설정하시는 것을 권장합니다.
실시간 미디어 스트림은 데이터 전송 량 및 아웃바운드 비용이 발생하므로 리전 간 혹은 가용영역(AZ)간의 전송을 고려해야 합니다. 예를 들어 프로세싱이 발생하는 리전 및 AZ이 있다면 해당 리전 및 AZ에서 콘텐츠를 수집하여야 합니다. 아웃바운드 데이터의 경우, 오리진 서버와 클라이언트 간의 통신에서 데이터 아웃바운드가 발생하므로 Amazon CloudFront를 사용하는 것을 권장합니다.
프로세싱에 소요되는 시간 RTF(real-time factor)를 줄이기 위해서는 작은 단위로 작업(Job)을 나눠서 병렬로 처리할 수 있습니다. 예를 들어 I-프레임 경계에서 작업을 분할하고 해당 세그먼트를 처리한 다음 모든 하위 작업이 완료되면 함께 연결할 수 있습니다. 이때 EC2 스팟 인스턴스를 사용하는 전략을 생각해볼 수 있습니다.
AWS Elemental MediaLive를 사용할 때 single-pipeline을 사용하여 비용을 절감할 수 있습니다. 장기간 운영되는 채널의 경우, 채널 예약을 통해 할인된 요금을 제공 받으실 수 있습니다.
AWS Elemental MediaConvert의 Basic 요금 티어는 컴퓨팅 집약적인 기능을 사용하지 않아 비용을 절감할 수 있습니다. 대량 파일의 트랜스코딩이 필요한 경우, 예약된 트랜스코딩 슬롯을 구매하여 고정된 월간 비용으로 안정적인 트랜스코딩 용량을 제공받을 수도 있습니다.

지속 최적화

콘텐츠 전송은 스트리밍 콘텐츠를 사용자에게 제공하는 기업에게 비용을 최적화할 수 있는 가장 큰 영역입니다. 미디어 프로세싱과 압축에 초점을 두고 개선을 한다면 비디오 데이터 속도를 낮추면서도 인코더 최적화를 통해 품질을 유지하여 비용을 개선할 수 있습니다. 객관적 측정과 주관적 측정을 함께 사용하여 압축 효율을 지속 개선할 수 있습니다.

[객관적 측정 기법]

객관적 측정 기법은 객관적 측정 도구를 활용하여 압축 성능을 분석하는 기법입니다. 예를 들어, Peak Signal-to-Noise-Ratio (PSNR), Structural Similarity (SSIM), and Video Multi-Method Assessment Fusion (VMAF) 와 같은 측정 도구를 활용할 수 있습니다. 객관적 측정 도구를 사용하면 데이터 소스, 다양한 인코딩 작업 설정 값, 그리고 출력 결과에서 나온 여러 지표를 비교하고 조정할 수 있습니다.

[주관적 측정 기법]

주관적 측정 기법은 비디오 압축과 관련하여 객관적인 점수로 식별할 수 없는 실질적인 문제를 발견합니다. 실제 사용자의 시청 경험에 기반한 피드백을 받거나 아마존 메카니컬 터크(Amazon Mechanical Turk)를 통해 콘텐츠에 대한 주관적인 피드백을 받아볼 수 있습니다. 메카니컬 터크는 적은 비용으로 제3자의 재생 경험에 대한 귀중한 통찰력을 제공받을 수 있으며, 이는 워크로드를 개선하는 데 사용될 수 있습니다.

결론

이 게시글에서는 Streaming Media Lens에서 다루는 미디어 스트리밍 솔루션에 AWS Well-Architected Framework를 적용하는 방법에 대해서 다뤘습니다. 미디어 스트리밍 워크로드를 처음 클라우드에 구축하는 사용자의 경우, 미디어 산업에 대한 이해보다 클라우드에서의 미디어 워크로드를 어떻게 구축할지에 대한 어려움을 느낄 수 있습니다. 이 게시글을 통해 운영 우수성, 보안, 안정성, 성능 효율성, 비용 최적화의 각 부문에서 아키텍처를 평가하고 구축하는 방법을 안내 드렸습니다. 처음 클라우드 여정을 시작하는 사용자라도 일관된 방법을 통해 클라우드에서의 미디어 워크로드를 시작해볼 수 있습니다.

AWS 기술 블로그