AWS 기술 블로그

AWS MediaLive, AWS MediaPackage기반 라이브 스트리밍 워크플로 Observability 확보하기

AWS에서 제공하는 다양한 미디어 서비스를 활용하면 비지니스에 필요한 라이브/온디맨드 비디오 워크플로를 손쉽게 구축하고 자연스럽게 운영 서비스의 높은 내구성과 이중화를 달성할 수 있습니다. 이로 인해 사용자는 서비스 성능 유지 및 상태에 집중할 수 있게 되는 데, 여기서 빼놓을 수 없는 부분이 바로 모니터링입니다. 특히 스포츠 중계와 같이 시청자 트래픽이 몰리는 시점에 화면의 끊김 현상과 같은 좋지 않은 경험은 벌금, 수익 또는 평판 손상으로 이어질 수 있기 때문에 라이브 비디오 스트리밍에서 모니터링과 로그 분석은 더욱 중요한 요소입니다.

이번 게시글에서는 사용자가 AWS MediaLive, AWS MediaPackage를 사용하여 라이브 스트리밍 워크플로를 구축하였을 때, 워크플로의 주요 지표를 모니터링하고 로그를 분석하여 observability를 확보하는 방법을 학습합니다. Amazon CloudWatch의 지표를 이용해 라이브 스트리밍 워크플로 모니터링을 위한 통합 대시보드를 구성하고 AWS MediaLive, AWS MediaPackage 각 서비스의 로그 분석을 위해 Amazon CloudWatch 및 AWS CloudTrail 로그를 활용합니다. 마지막으로 라이브 스트리밍 워크플로 상 문제가 발생할 경우, 실시간 대응할 수 있는 이벤트 기반 알람을 설정하는 방법을 설명합니다.

솔루션 개요

라이브 스트리밍은 일반적으로 수집, 처리, 저장, 전송의 단계로 나뉘어져 있습니다. 각 단계를 아래 AWS 미디어 서비스를 활용하여 구성할 수 있습니다.

  1. Source(수집): URL_PULL, RTMP_PUSH, RTMP_PULL, RTP_PUSH, 그리고 MediaConnect, Elemental Link 디바이스와 같은 다양한 방법을 통해 스트리밍 비디오를 전달하며 이는 이중화 되어 전달됩니다.
  2. AWS Elemental MediaLive(처리): 브로드캐스트 수준의 동영상 처리 서비스로 동영상을 실시간 인코딩하여 라이브 소스를 고품질 스트림으로 압축합니다.
  3. AWS Elemental MediaPackage(저장): 오리지네이션 서비스로 MediaLive로부터 스트림을 가져와서 실시간으로 패키징하고(JITP, Just-In-Time Packaging), 컨텐츠 암호화 기능을 제공합니다.
  4. Amazon CloudFront(전달): CDN(Content Delivery Network)서비스로 낮은 레이턴시와 높은 전송 스피드로 컨텐츠를 전달합니다.

시간이 지날수록 사용자는 각 미디어 워크플로의 상태를 지표, 로그와 같은 형태로 모니터링하고 필요 시 알람을 받고자 하는 요구사항이 있을 수 있습니다. 각 서비스에서 제공되는 기본 지표는 서비스 별 분산돼 있어서 문제의 원인이 명확하지 않을 때 원인 파악에 오랜 시간이 소요되는 등의 근본적인 문제에 직면할 수 있습니다. 아래 단계를 통해 각 서비스에서 제공하는 지표를 통합하고 이벤트 기반 알람을 받을 수 있는 모니터링 시스템을 구성해보겠습니다.

솔루션 구축 단계

단계 요약

  • 단계 1 : Amazon CloudWatch 지표를 사용하여 대시보드 구성
  • 단계 2 : Amazon CloudWatch 로그 활용하기
  • 단계 3 : AWS CloudTrail 로그 활용하기
  • 단계 4: Amazon CloudWatch에서 이벤트 기반 알람을 설정합니다.

사전 준비사항

솔루션을 배포하기 위해서는 아래와 같은 사항을 준비 해야 합니다.

  • AWS 계정
  • 미디어 워크로드
  • 운영중인 워크로드가 없을 경우, 간편 구축을 위한 ‘CloudFormation 템플릿으로 구성 참고

CloudFormation 템플릿으로 구성

  1. CloudFormation 템플릿 링크에 접속하고 첫번째 화면에서 Next를 클릭합니다.
  2. Stack name을 입력하고 이외 별도의 설정없이 Next를 두번 클릭합니다.
  3. 페이지 하단에 IAM관련 문구에 체크를 표시하고 Submit을 클릭합니다.
  4. 아래와 같은 Resource가 생성되는 것을 확인합니다.*해당 템플릿은 실습에 필요한 AWS MediaLive, AWS MediaPackage 리소스를 자동 구성합니다.
  5. 검색창에 MediaLive를 검색하고 AWS Elemental MediaLive콘솔에 접속하여 아래와 같은 Channel이 구성된 것을 확인합니다.
  6. Channel Name을 클릭한 후 우측 상단의 Start를 클릭하여 pipelines running되는 것을 확인합니다.
  7. 검색창에 MediaPackage를 검색하고 AWS Elemental MediaPackage 콘솔에 접속하여 생성된 channel ID (my-mediapackage-channel)을 클릭합니다.
  8. Preview버튼을 클릭하여 영상이 출력되는 것을 확인합니다.

축하합니다! 실습을 위한 사전 준비를 완료하였습니다.

단계 1 : Amazon CloudWatch 지표를 사용하여 대시보드 구성

Amazon CloudWatch는 미디어 서비스에서 수신한 원시 데이터를 수집하여 실시간으로 읽기 쉬운 지표로 변환하고 이를 15개월 동안 보관합니다. 사용자는 네트워크 입력/출력, 비디오 프레임 속도, 손실된 프레임 등 중요 미디어 서비스 지표를 모니터링할 수 있고 대시보드에 그래프로 표시하여 observability를 구성할 수 있습니다. 아래 구성을 통해 MediaLive와 MediaPackage의 주요 지표를 선택하여 대시보드를 구성합니다.

  1. AWS Management Console → Amazon CloudWatch에서 Dashboards를 클릭합니다.
  2. Create dashboard를 클릭하고 Dashboard name에 ‘LiveStreamingDashboard’ 입력
  3. 생성 후 보이는 콘솔의 우측 ‘+’ 를 클릭하여 Widget type을 선택합니다.

MediaLive 지표 구성

AWS Elemental MediaLive 대시보드 구성에 사용할 지표는 아래와 같습니다.

  1. MediaLive Channel section 구성 (Widget type: Text)
    – 아래 예시처럼 대시보드를 구분하기 위한 필요 문구를 작성하고 ‘Create widget’을 클릭합니다.
  2. Pipeline0, Pipeline1 각각에 대한 네트워크 입/출력 지표 (Widget type: Line → Metrics → MediaLive → ChannelId, Pipeline)
    – NetworkIn: AWS Elemental MediaLive가 수신한 push 및 pull에 대한 트래픽입니다. 장기간에 걸친 평균 트래픽 속도를 캡처하도록 설정하다가 기간을 짧은 시간으로 변경하면 정상 속도와의 편차를 쉽게 찾아내거나 채널의 버스트 정도에 대한 정보를 수집할 수 있습니다.
    – NetworkOut: AWS Elemental MediaLive로부터 트래픽이 빠져나가는 비율입니다. 미디어 출력, HTTP GET 요청, NTP, DNS 트래픽이 포함됩니다.우리는 MediaLive의 각 파이프라인별 지표를 구분하고자 합니다. 따라서 먼저 Pipeline0에 대한 NetworkIn, NetworkOut을 선택하고 ‘Create widget’을 클릭합니다.이어서 동일한 방법으로 Pipeline1에 대한 지표를 생성하면 아래와 같은 화면을 볼 수 있습니다. 대시보드의 구성은 섹션별로 드래그&드랍하는 형식으로 변경합니다.아래와 같이 Widget의 명칭을 변경합니다.
  3. InputVideoFrameRate (Pipeline0, Pipeline1 모두 선택)(Widget type: Line → Metrics → MediaLive → ActiveInputFailoverLabel, ChannelId, Pipeline)
    – 파이프라인별 입력 프레임을 모니터링합니다. 입력 프레임의 count가 안정적이지 않으면 소스에 문제가 있는지 또는 업스트림 시스템과 AWS Elemental MediaLive 사이의 네트워크에 문제가 있는지 조사할 필요가 있습니다.
  4. ActiveOutputs(Pipeline0, Pipeline1 모두 선택)(Widget type: Bar → Metrics → MediaLive → ChannelId, OutputGroupName, Pipeline)
    – 대상에 성공적으로 기록된 출력 수입니다. 데이터 포인트가 없다는 것은 채널에서 출력 오디오가 생성되지 않았다는 뜻이며 아직 시작 중이거나 초기 입력을 기다리고 있을 수 있습니다.

내용들을 입력하고 우측 상단의 Save버튼을 클릭하여 대시보드를 저장합니다. 혹은 Autosave:Off를 클릭하고 Autosave:On으로 변경하여 만일의 경우에 손실을 방지할 수 있습니다.

입력되면 아래와 같은 대시보드를 구성할 수 있습니다. MediaLive Channel 생성 시 Channel Class를 Standard로 구성할 경우, 2개의 인코더 파이프라인(pipeline0, pipeline1)이 생성됩니다. 위와 같은 방법으로 각 파이프라인별 네트워크 입/출력과 같은 지표를 세분화하여 모니터링하면 더 나은 observability를 확보할 수 있습니다.

MediaPackage 지표 구성

AWS Elemental MediaPackage 대시보드 구성에 사용할 지표는 아래와 같습니다.

  1. MediaPackage section 구성 (Widget type: Text)
    – 아래 예시처럼 대시보드를 구분하기 위한 필요 문구를 작성하고 ‘Create widget’을 클릭합니다
  2. IngressBytes (2개 채널 선택)
    (Widget type: Line → Metrics → MediaPackage → Ingest Endpoint per Channel)
    – 입력 요청에 대해 AWS Elemental MediaPackage가 수신하는 콘텐츠의 바이트 수입니다.
  3. IngressResponseTime (2개 채널 선택)
    (Widget type: Line → Metrics → MediaPackage → Ingest Endpoint per Channel)
    – AWS Elemental MediaPackage가 각 입력 요청을 처리하는 데 걸리는 시간입니다. 지정된 간격 동안 요청을 수신하지 않으면 데이터가 제공되지 않습니다.
  4. EgressRequestCount (Widget type: Number → MediaPackage → Per Origin Endpoint)
    – AWS Elemental MediaPackage가 수신하는 콘텐츠 요청 수입니다.
  5. EgressBytes (Widget type: Number → MediaPackage → Per Origin Endpoint)
    – 각 요청에 대해 AWS Elemental MediaPackage가 성공적으로 보낸 바이트 수입니다.
  6. EgressResponseTime (Widget type: Number → MediaPackage → Per Origin Endpoint)
    – AWS Elemental MediaPackage가 각 출력 요청을 처리하는 데 걸리는 시간입니다.

내용들을 입력하고 우측 상단의 Save버튼을 클릭하여 대시보드를 저장합니다. 혹은 Autosave:Off를 클릭하고 Autosave:On으로 변경하여 만일의 경우에 손실을 방지할 수 있습니다.

AWS Elemental MediaPackage 지표를 구성하면 기존 AWS Elemental MediaLive 지표와 함께 아래와 같은 대시보드를 구성할 수 있습니다.

*아래 구성은 사용자마다 다를 수 있으며 네트워크 상태에 따라 지표가 다르게 보일 수 있습니다.

대시보드를 구성함으로써 사용자는 채널별 MediaLive 및 MediaPackage 상태를 파이프라인 혹은 엔드포인트별로 모니터링 할 수 있습니다. 이를 통해 담당자는 구간 별 이슈 및 특이 사항을 손쉽게 감지할 수 있으며, 신속하게 의사 결정을 내릴 수 있습니다.

단계 2 : CloudWatch 로그 활용하기

AWS Elemental MediaLive와 AWS Elemental MediaPackage는 각자 다른 방법으로 유용한 로그를 제공합니다.

AWS Elemental MediaLive 로그

AWS Elemental MediaLive는 활동에 대한 상세 정보를 포함한 채널 로그를 생산하며, 이 로그는 활동에 대한 순차적인 설명을 제공합니다. 대시보드에서 보이는 지표가 충분한 정보를 제공하지 못할 때 유용하게 사용할 수 있습니다. 기본으로 제공되는 as-run 로그 외에 encoder log를 enable하여 풍부한 로그를 제공받을 수 있습니다. 채널이 idle 상태인지 확인하고 Log level을 변경합니다.

Channel 선택 → Start 상태라면 Stop으로 변경 → Edit Channel → General settings → Channel logging의 Log level변경 (여기서는 INFO로 변경합니다.)

Log를 활성화 한 후에는 CloudWatch → Logs → Log groups에서 확인하거나 아래 방법처럼 MediaLive 콘솔에서 직접 접속할 수 있습니다. Log level변경 후에는 바로 log가 보이지 않을 수 있기 때문에 channel을 Stop하고 Start를 실행하면 빠르게 로그를 확인할 수 있습니다.

아래 그림과 같이 JSON 포맷으로 구성된 로그를 확인할 수 있으며, 1) Probing input media 2) Found Master Manifest(m3u8파일의 경로를 확인) 3) Bitrate 와 같은 로그를 통해 파이프라인 별 활동 로그와 특정 시점에 발생한 이벤트를 확인할 수 있습니다.

AWS Elemental MediaPackage 로그

AWS Elemental MediaPackage는 채널 또는 패키징 그룹에 전송된 요청에 대한 자세한 정보를 캡처하는 액세스 로깅(Access logging)을 제공합니다. 로그에는 요청을 받은 시간, 클라이언트의 IP 주소, 지연 시간, 요청 경로 및 서버 응답과 같은 정보가 포함되어 있습니다. 옵션으로 제공되는 기능이므로 추가로 활성화 해줘야 합니다. MediaPackage Channels 선택 → Edit → Enable Ingress/Egress access logs → Update → 업데이트 후, Settings탭에 들어가서 Enabled된 것을 확인

활성화 후에는 각 Log group name을 클릭해서 Ingress/Egress logs를 확인할 수 있습니다.추가적으로 CloudWatch → Logs Insights → Select log groups → /aws/MediaPackage/EgressAccessLogs를 선택하여 접속합니다. → 원하는 시간대의 LogStream을 클릭하고 아래와 같이 timestamp 별 내역을 상세 조회할 수 있습니다.
*활성화 후, 수집까지의 시간이 걸리므로 5분정도의 여유를 두고 확인하면 좋습니다.

단계 3 : AWS CloudTrail 로그 활용하기

AWS CloudTrail를 사용하여 자격 증명을 갖춘 사용자 혹은 역할이 서비스를 수행하였는 지에 대한 레코드를 제공받을 수 있습니다. Trail을 생성하지 않아도 AWS CloudTrail → Event History에서 최근 이벤트에 대한 로그를 확인할 수 있습니다. 여기에는 콘솔 혹은 API호출을 한 내역들이 포함됩니다. AWS CloudTrail에 수집된 정보를 활용하여 AWS Elemental MediaLive, AWS Elemental MediaPackage에 ‘요청한 사용자는 누구인지’, ‘요청자의 IP는 무엇인지’, ‘언제 이 요청이 수행되었는지’ 와 같은 정보를 확인할 수 있습니다.

Event History에서 확인하기

사용자는 Event History에서 Event source 혹은 User name별 필터링하여 모니터링할 수 있습니다. 예를 들어 AWS MediaPackage의 상세 이력이 궁금하다면 Lookup attributes를 EventSource로 두고 mediapackage.amazonaws.com를 검색하여 세부 조회가 가능합니다.

위의 예시에서 ConfigureLogs를 클릭하면 아래와 같이 Event record에서 상세한 로그를 확인할 수 있습니다.

AWS CloudTrail Lake에서 확인하기

2022년 1월 AWS에서는 AWS CloudTrail Lake를 출시하였습니다. 이는 AWS CloudTrail 로그를 저장 및 분석하기 위한 완전 관리형 데이터 레이크로써 AWS의 여러 리전과 계정의 이벤트에 대해 수집, 저장, 최적화 및 쿼리 할 수 있도록 합니다. 기존에 사용자는 AWS CloudTrail 로그를 S3로 전송하고 이를 Amazon Athena를 통해 분석하는 방법을 사용했지만 이제 AWS CloudTrail Lake를 통해 통합된 환경에서 로그를 분석할 수 있습니다.

  1. AWS Management Console → CloudTrail → Lake → Create event data store를 클릭합니다.
  2. Name을 작성하고 Create를 클릭합니다.
  3. 생성 후에는 아래와 같이 Created event data store를 확인할 수 있습니다.
  4. Run query클릭합니다.
  5. SQL Query를 작성하고 Run합니다.
  6. Sample queries 탭에서 예시 쿼리문을 참조할 수 있습니다.

쿼리 예시

사용자는 최근 Stop 상태로 두었던 AWS Elemental MediaLive가 Start 상태로 변경된 것을 확인했습니다. 50명의 팀원 중, 누가 언제 Start를 하였는지 확인하고자 합니다.

Query1에 아래와 같이 코드를 입력하고 ‘Run’을 클릭합니다.
##Event data store ID##는 고유 ID를 입력합니다. (아래 그림에서 ID위치 확인)

SELECT eventID, eventName, eventSource, eventTime, userIdentity.arn AS user
FROM ##Event data store ID##
Where eventname = 'StartChannel'

결과로 사용자는 이벤트에 대한 시간, 사용자 정보를 비롯한 원하는 정보를 얻습니다.

단계 4 : Amazon CloudWatch 이벤트로 모니터링 강화

Amazon CloudWatch 이벤트와 통합하여 채널과 엔드포인트에 영향을 주는 특정 이벤트에 대한 알람을 받을 수 있습니다. 이를 통해 사용자는 운영 환경에서 발생하는 특이사항을 실시간으로 제공받을 수 있으며 신속한 대응이 가능합니다. 이 게시글에서는 Amazon Simple Notification Service (SNS) 를 통해 알람을 보내는 방법을 설명합니다.

구독 생성하

  1. AWS Management Console → Amazon Simple Notification Service (Amazon SNS) → Topics → Create topic을 클릭합니다.
  2. Type에서 ‘Standard’를 클릭하고 Name 필드를 입력한 뒤, ‘Create topic’을 클릭합니다.
  3. 콘솔 하단의 ‘Create Subscription’을 클릭합니다.
  4. Protocol의 드롭다운 목록에서 Email을 선택하고 Endpoint에 실제 사용하는 이메일 주소를 입력합니다.
  5. ‘Create subscription’을 클릭합니다.
  6. 입력한 이메일로 수신된 메일을 확인하고 ‘Confirm Subscription’을 클릭합니다.

Amazon CloudWatch 이벤트 생성

  1. AWS Management Console → CloudWatch → 좌측 Events → Rules를 클릭합니다.
  2. Create Rule을 클릭합니다.
  3. Name을 입력하고 Next를 클릭합니다.
  4. 화면을 아래로 드래그하여 Event pattern을 확인합니다.
  5. AWS service는 MediaLive, Event type은 State Change를 선택하고 Next를 클릭합니다.
    *위 예시 외에 MediaLive와 MediaPackage service에서 알림받을 수 있는 EventType과 각 설명은 아래와 같습니다.
    MediaLive

    • MediaLive Channel State Change: Pipeline의 시작/중지에 대한 알람
    • MediaLive Channel Alert: 네트워크 데이터를 수신하지 못할 때 알람
    • MediaLive Multiplex State Change: Multiplex를 위한 Pipeline의 시작/중지에 대한 알람
    • MediaLive Multiplex Alert: UDP input과 같은 데이터를 수신하지 못할 때 알람
    • MediaLive Channel Input Change: input이 스위치되어 변경이 발생했을 때 알람

    MediaPackage

    • MediaPackage Input Notification: 최대 입력 스트림 초과, 입력 스위치와 같은 ingest에 문제가 발생할 때 알람
    • MediaPackage Key Provider Notification: 엔드포인트에서 콘텐츠 암호화를 사용 중이고 키 제공자에게 연결할 수 없는 경우 알람
  1. Select a target은 SNS topic을 선택하고 Topic은 위에서 생성한 Topic을 선택합니다.
  2. 그 외 설정은 그대로 두고 Next를 클릭하고 최종 Create를 클릭합니다.

생성된 이벤트는 MediaLive 채널 상태(State)가 변경(start, stop)될 때마다 이메일 알람을 전송합니다.

예시 검증하기

  1. AWS Management Console → MediaLive → Channels를 클릭합니다.
  2. Channel을 선택하고 ‘Stop’을 클릭합니다.
  3. 메일에 로그인하여 수신한 ‘AWS Notification Message’를 클릭합니다.
  4. “pipelines_running_count”:0,”state”:”STOPPED”와 같은 알림 내역을 확인할 수 있습니다.

모니터링 시스템 구성도

Amazon CloudWatch의 지표, 로그, 이벤트 기반 알람을 활용한 모니터링 시스템 구성도는 아래와 같습니다.

  1. AWS Elemental MediaLive, AWS Elemental MediaPackage의 실시간 지표를 Amazon CloudWatch 통합 대시보드로 구성
  2. Amazon CloudWatch Logs 및 Log Insight에서 리소스 상태 분석
  3. AWS CloudTrail EventHistory 활용 및 쿼리용 AWS CloudTrail Lake 구성
  4. Amazon CloudWatch Event와 Amazon SNS를 통합하여 이벤트 기반 알람 구성

리소스 정리하기

이 게시글에서 사용했던 리소스는 향후 불필요한 과금을 방지하기 위해 삭제하여야 합니다. CloudFormation 템플릿으로 구현한 경우, 몇가지 절차를 통해 삭제가 필요합니다.

  1. MediaLive Channel에 접속하여 Stop을 눌러 idle상태로 변경합니다.(실행 중일 경우, DELETE_FAILED됩니다.)
  2. AWS CloudFormation 에 접속하여 설치한 스택을 클릭하고 DELETE를 클릭합니다.
  3. Resources탭에서 모든 리소스가 삭제된 것을 확인합니다.
  4. CloudTrail Lake 삭제 시, Actionsà Change termination protection을 disable하고 삭제합니다.
  5. CloudWatch, SNS도 각 콘솔에 접속하여 삭제합니다.

결론

이 게시글에서는 AWS MediaLive, AWS MediaPackage기반 미디어 라이브 스트리밍 워크플로에서 지표, 로그, 알람 기능을 활용하여 운영 환경을 모니터링하고 observability를 확보하는 방법에 대해 소개했습니다. 기존 AWS MediaLive와 AWS MediaPackage의 경우, 각 서비스마다 console에 접속하여 제공되는 한정된 지표를 별도로 확인해야 했고 추가적인 정보는 산재된 로그에서 찾아내야 했습니다.

이제 사용자는 Amazon CloudWatch 지표를 사용하여 통합된 모니터링 대시보드를 구축하여 정보를 한 곳에서 확인할 수 있으며 Amazon CloudWatch 로그 그리고 이벤트 기반 알람을 활용하여 운영 안정성을 강화할 수 있습니다. 또한, AWS CloudTrail 로그 레코드 및 AWS CloudTrail Lake의 검색 기능을 통해 특정 문제의 원인 제공자 혹은 특정 시간의 계정 별 활동과 같은 중요 정보를 쉽게 얻을 수 있습니다.

결과적으로 사용자는 별도의 모니터링 솔루션을 구입하거나 많은 시간을 사용하지 않고도 기본으로 제공되는 정보를 활용하여 라이브 스트리밍 워크플로 observability를 확보할 수 있습니다.

TaeHoon Kyeong

TaeHoon Kyeong

Kyeong Tae-Hoon (Nick) is a solutions architect at AWS responsible for optimizing architecture for media and entertainment customers to achieve their desired business results. 경태훈(Nick) 솔루션즈 아키텍트는 미디어 및 엔터테인먼트 고객이 원하는 비즈니스 결과를 얻을 수 있도록 아키텍처를 최적화하는 역할을 담당하고 있습니다.