AWS Elemental Live Streaming (MediaLive & MediaPackage)

Live Streaming 필수 요소

  1. 미디어 입력
    • 시청하기에 적절하게 쪼개져 있지 않고, 고해상도일 수 있다.
  2. 변환 & 저장
    • MediaLive : 고해상도의 입력신호를 적합한 화질로 변환
      • HTTP Live Streaming 이라는 프로토콜로 변환되게 됨
    • MediaStore : 저장
      • 심플한 Live Workload에 적합
      • S3와 같은 storage이지만, Cache Layer를 통해 쓰기, 읽기 지연을 최소화
    • MediaPackage : 저장
      • DRM
      • Live Streaming -> DASH + HLS + MSS (여러 디바이스에서 재생 가능)
  3. 전송
    • CloudFront : 실시간 데이터를 안정적이고 좀 더 빠르게 클라이언트가 재생할 수 있게 함
  4. 재생 & 소비

MediaPackage

  • MediaLive의 목적지로 존재하기 때문에 가장 먼저 생성
  • Input A, B의 주소로 프로세싱된 스트림을 보내게 됨
  • 사용자가 재생할 수 있는 엔드포인트(HLS, CMAF, DASH)는 직접 생성해줘야 함
  • Packager Settings
    • 영상을 몇 초 단위로 쪼갤지, 재생 목록에는 몇 초 단위를 유지할지

MediaLive

  • 채널 먼저 생성하지 않고, 입력(Input A, B)을 먼저 생성
    • Event 기반, Time 기반으로 입력을 switing하는 기능이 제공 (일정 Tab)
    • 특정 시간에는 특정 인풋으로 스트림, 다른 시간에는 다른 인풋으로 맵핑 가능
  • Input Type
    • RTP : UDP 기반, 전용망(Direct Connect, MediaConnect)
    • RTMP : TCP 기반, Public망
      • Push : 영상을 밀어넣거나 (OBS - 웹캡 to RTMP)
      • Pull : 미디어 서버에서 가져오거나
    • HLS, MP4 : S3의 입력 소스를 기반으로, VOD를 라이브 신호처럼 송출할 때 사용 (VOD to Live)
    • MediaConnect : 리전간 스트리밍 전송 서비스
  • 채널 생성
    • 템플릿 : 해상도, 비트레이트, 프레임레이트가 사전설정된 템플릿
    • 이중화(인풋 2개, 출력 2개) : 가용성 보장하기 위해
    • 코덱 (압축) : 아래로 갈수록 압축률 높다 (압축률 높을수록 CPU자원이 많이 사용되므로 비쌈)
    • ABR (Adaptive Bit Rate): 플레이어의 네트워크 bandwidth에 따라 자동으로 해상도가 변환되는 기능 (ex> 유튜브 auto 해상도 - 쪼개진 영상 시간이 지났을 때)
    • 파이프라인 == input
  • m3u8
    • 사파리에서는 바로 재생
    • 크롬에서는 HLS 확장 프로그램 설치

AWS

고가용성, 내결함성

  • 고가용성 : 전체 시스템에 대하여, 사람이 개입하지 않아도 시스템이 항상 작동하고 액세스 가능, 가동 중지를 최소화하도록 보장하는 것

    • 시스템을 1분이라도 사용할 수 없으면 비즈니스에 중대한 손상
    • ELB : 지연 시간이 길거나 서버가 과다 사용되는 경우 이를 알리는 트리거로 동작
    • EIP : 인스턴스가 실패하더라도 클라이언트가 애플리케이션에 액세스할 수 있도록 고정 IP
    • Route 53 : 단순 라우팅, 지연 시간에 따른 라우팅, 상태확인, DNS 장애 조치, 지리 위치 라우팅 지원
    • Auto Scaling
    • CloudWatch
    • 여러 AZ
  • 내결함성 : 시스템의 일부 구성요소에 장애가 있어도 시스템이 계속 작동할 수 있는 기능 (애플리케이션 관점)

    • SQS : 내결함성 애플리케이션의 백본으로 사용, 안정적인 분산 메시징 시스템, 대기열 항시 사용 가능
    • S3 : 내구성과 결함성이 뛰어난 데이터 스토리지. 리전 내 여러 시설에서 각 디바이스의 모든 데이터를 중복 저장
    • RDS : 자동 백업, 스냅샷, 여러 가용 역역 지점
  • 탄력성 : 용량 요구사항에 대해 신경쓰지 않고 자동화된 확장 및 축소

    • 트래픽 급증 시 웹 서버 수 증가
    • 트래픽이 줄어들 때 데이터베이스 쓰기 용량 감소 (IOPS : Input/Output Opereations Per Second)
    • 아키텍쳐 전반에 걸친 일상적인 수요 변동 처리
    • 시간 기반 탄력성 : 리소스가 사용되지 않을 때 리소스 끄기
    • 볼륨 기반 탄력성 : 수용 강도에 맞게 규모 조정

Docker

도커는 컨테이너 기반 오픈소스 가상화 플랫폼이며,
라이브러리, 시스템 도구, 코드, 런타임을 포함한 소프트웨어를 컨테이너로 패키징시키는 것이다.

로컬 PC, AWS, GCP, Azure 등 환경에 관계없이 빠르게 배포 및 테스트할 수 있다.

Container 가상화

VM:container

  • Virtual Machine 가상화
    • Hypervisor 위에 Guest OS가 구동
    • 별도의 VM과 OS를 필요로 하기 때문에 자원의 비효율성(용량, 메모리)
  • Container 가상화
    • Docker 엔진을 통해 각 App이 OS 자원을 직접 사용 (앱 실행에 필요한 자원만 사용)
    • 별도의 OS 없이 Docker 엔진 공유 (가벼움)

Docker image

이미지는 컨테이너 실행에 필요한 파일과 설정값을 포함하고 있는 것이다. 즉, 컨테이너는 이미지를 실행한 상태이다.

Docker Container

컨테이너란 격리된 공간에서 프로세스가 동작하는 기술이다. 컨테이너는 프로세스를 격리하는 방식이기 때문에 기존 가상화 기술에 비해 가볍고 빠르다.

Docker cacheing

한번 이미지를 빌드한 뒤 dockerfile에 동일한 명령어가 있으면 이전의 빌드에서 사용했던 캐시를 사용한다. build할 때 using Cache log가 나오는 것을 확인할 수 있다. 캐시가 필요하지 않다면 --no-cache 옵션을 추가하면 된다.

Dockerfile

  • FROM절 : 컨테이너의 원형(틀) 역할을 할 도커 이미지(OS)를 정의한다.
  • COPY절 : 쉘 스크립트 파일을 도커 컨테이너 안의 /usr/local/bin에 복사하기 위하여 정의한다.
  • RUN절 : 도커 컨테이너 안에서 명령을 수행하기 위함. 여기까지 도커 빌드 과정에서 실행되며 그 결과로 새로운 이미지가 만들어진다.
  • CMD절 : 완성된 이미지를 도커 컨테이너로 실행하기 전에 먼저 실행할 명령을 정의한다.

코드로 관리하는 인프라(IaC)와 불변 인프라(Immutable Infrastructure)

  • IaC : 서버를 어떻게 구성할 것인지, 어떤 라이브러리와 도구를 설치할지를 코드로 정의하고 Chef나 Ansible 같은 프로비저닝 도구로 서버를 구축
    • stable 버전을 install하는 코드를 실행하는 예시를 들면, stable 버전은 자주 변하기 때문에 항상 같은 결과를 보장하지 않는 단점이 있음
  • 불변 인프라(Immutable Infrastructure) : 어떤 시점의 서버 상태를 저장해 복제할 수 있게 하는 개념
    • 서버에 변경을 원할 때는 새로운 서버를 구축하고 그 상태를 이미지로 저장한 다음, 해당 이미지를 복제
  • 도커를 사용하면 IaC와 불변 인프라의 개념을 간단하고 낮은 비용으로 실현할 수 있음
    • 인프라 구성이 Dockerfile로 관리되므로 IaC는 도커의 대원칙
    • 컨테이너형 가상화 기술 사용을 통해, 기존 컨테이너를 빠르게 폐기하고 새롭게 구축 가능 (불변 인프라)

Container Orchestration

  • 도커 컴포즈를 단일 서버를 넘어 여러 서버에 걸쳐 있는 여러 컨테이너를 관리할 수 있도록 한것이 도커 스웜(Docker Swarm)이다.
  • 도커 스웜은 컨테이너 증가, 감소는 물론, 노드의 리소스를 효율적으로 활용하기 위해 컨테이너 배치 및 로드 밸런싱 등의 기능을 갖춤
  • 배포 시 롤링 업데이트가 가능 (오래된 컨테이너와 새로운 컨테이너를 단계적으로 서비스에 교체 투입하는 것)
  • 이렇게 여러 서버에 걸쳐 있는 여러 컨테이너를 관리하는 기법은 컨테이너 오케스트레이션이라고 한다.
  • 컨테이너 오케스트레이션의 표준은 쿠버네티스(k8s)이다.

Docker Network Mode

  1. bridge
    • docker 기본 네트워크 방식
    • 각 컨테이너마다 고유한 network namespace 영역이 생성
    • docker daemon을 실행하면 docker0라는 bridge가 생성되며 해당 bridge에 container들의 인터페이스들이 하나씩 binding되는 구조
  2. host
    • 컨테이너가 독립적인 네트워크 영역을 갖지 않고 host와 네트워크를 함께 사용
    • docker run --net=host httpd web01 과 같이 생성
    • 컨테이너의 ip와 인터페이스 정보는 host의 네트워크 정보와 동일
    • host옵션으로 생성된 컨테이너는 bridge를 사용하지 않으므로 docker0에 바인딩되지 않는다.
  3. container
    • 기존 존재하는 다른 컨테이너의 network 환경을 공유
  4. none
    • 격리된 네트워크 영역을 가지지만, 인터페이스가 없는 상태로 컨테이너 생성
    • bridge에도 연결되지 않은 상태이며, 이 상태로는 외부 통신 불가
    • 인터페이스를 직접 커스터마이징하기 위한 옵션

쿠버네티스

  • 2014년 구글에서 처음 개발
  • 컨테이너 여러 개를 한 번에 관리하는 기술은 Container Orchestration이라고 명명됨
  • CNCF (CLoud Native Computing Foundation, 클라우드 기술 표준형을 개발하는 재단)에서 쿠버네티스를 중심 프로젝트로 편성
  • 그 결과, 쿠버네티스는 Container Orchestration의 표준이 됨.

분산 시스템

  • 보안이 어려움
  • loosely coupled(구조적으로 개선이 어려운 문제)
  • 즉시성을 요하는 분야에서 어려울 수 있다.
  • 위 단점을 극복하기 위해 edge computing이 많이 이용된다. edge computing은 cloud computing과 상호 보완적.

쿠버네티스

  • k8s 최소 관리 단위 : pod (pod에는 여러 개의 컨테이너가 들어있다)
  • kubelet을 통해 kubernetes master가 각 서비스를 관리한다.
  • service는 동일한 pod를 여러 개 실행시킨 것
  • k8s는 서비스에 대해 대표 접속 ip를 부여한다. 대표로 받은 요청을 각 pod의 고유 ip로 분산함
  • pod가 비정상이 되면 k8s에 삭제되고 새로 생성 / 요청 수가 늘어나면 pod 추가 생성 (auto scaling)
  • etcd : 각 서비스와 pod의 구성 정보, 상태 데이터를 저장하는 곳

과정

  1. devops가 container / pod / service의 구성 정보를 전달
  2. k8s manager가 각 노드의 용량에 맞게 pod를 분산 배포 (resource scaling)
  3. 컨테이너 pod service 구성 정보 & 접속 정보 저장
  4. 요청이 들어오면 proxy를 통해 대표 주소로 받은 요청을 서비스에 속한 pod로 포워딩함

Ingress Controller

  • Ingress
  • 인그레스는 클러스터 내 서비스에 대한 외부 접근(HTTP, HTTPS request)을 관리하는 규칙의 모음
  • 인그레스는 로드 밸런싱, SSL 인증서 처리 및 도메인 기반의 가상 호스팅을 제공할 수 있음
  • 인그레스는 인그레스 컨트롤러를 조건으로 필요로 하며, 인그레스 리소스만 생성한다면 효과가 없음
    • 쿠버네티스는 AWS, GCE, Nginx ingress controller를 지원하고 있음

'Docker & k8s' 카테고리의 다른 글

[K8S] 2. Kubernetes Commands  (0) 2022.02.03
[K8S] 1. Kubernetes Core Component  (0) 2022.02.03
도커란? (Docker)  (0) 2020.12.17
도커 컨테이너 한꺼번에 종료  (0) 2020.11.28
How to fix docker error processing tar file  (0) 2020.11.13

AWS MediaConvert를 이용하여 영상을 스트리밍할 때 HLS 프로토콜이 사용된다.

애플에서 개발한 HLS 프로토콜의 특징에 대해서 간단히 정리해보았다.

HLS(HTTP 라이브 스트리밍)

  • HLS는 비디오 파일을 다운로드할 수 있는 HTTP 파일 조각으로 나누고 HTTP 프로토콜을 이용해 전송
  • 클라이언트는 이러한 HTTP 파일을 로드한 후 비디오로 재생
  • 모든 인터넷 장치가 HTTP를 지원하기 때문에 간단하게 실행 가능
  • HLS 스트리밍은 재생에 지장을 주지 않고 네트워크 상태에 따라 비디오 품질을 높이거나 낮출 수 있다.
  • 미디어 파일을 한 번에 모두 보내는 대신 한 번에 조금씩 지속적으로 사용자 장치에 보냄
  1. 서버
    • 인코딩 : 비디오 포맷 재설정 -> 모든 장치가 데이터를 인식하도록
    • 조각화 : 비디오는 몇 초 길이(10초 정도)의 세그먼트로 쪼개짐
      • 세그먼트로 나누고, 세그먼트의 인덱스 파일(m3u8)을 만들어 세그먼트의 순서를 기록
      • HLS는 480p, 720p, 1080p 등 다양한 품질로 여러 세트 세그먼트 복제
  2. 배포
    • 일반적으로 CDN을 사용하여 여러 지역으로 배포. 스트리밍을 캐시하여 클라이언트에 더 신속히 전송 가능
  3. 클라이언트
    • 인덱스 파일(m3u8)을 참조하여 비디오를 순서대로 조합하고 필요에 따라 품질을 높이거나 낮춤

Api Gateway

  • Security
  • Mediation
  • Traffic Management

기능

  1. Routing
    • 모바일과 PC 중 적절히 라우팅
    • Monolithic -> MSA 할 때 많이 사용
      • 마이그레이션 할 때 중요하게 사용
      • 마이그레이션 중 따로 뺀 api도 동작해야하기 때문
  2. Quota (할당량)
  3. Authentication (인증)
  4. Authorization (특정 권한 가진 사람만 접근)
  5. API Cache (반복 요청에 대해 API 게이트웨이의 캐시로부터 바로 반환)
  6. Logging - 로그 파일이 한 곳에 모임
  7. 모니터링
  8. 로드 밸런서와 다른 부분? : Mediation (중재)
    • 백엔드 api가 바뀌었을 때 클라이언트의 요청을 바꿔주는 기능
    • 클라이언트가 원하지 않는 속성을 지워주는 기능
    • 각 단계별(4단계)로 원하는 조건을 수행하도록 함
  9. json to xml, xml to json 가능
  10. gRPC (내부에서는 빠르게, 외부에는 API Gateway를 거쳐서 필요한 형식 json 등으로)
  11. API Gateway는 k8s와 통합이 시작되고 있음
    • 백엔드 서비스가 k8s 형식으로 배포될 때, 입구에서 API Gateway가 하나씩 던져주는 식으로 작동
  12. HTTP API vs REST API
    • HTTP API : 가격이 100만 건당 $0.90 ~ $1.00으로 싸지만, Validation, WAF, API Caching, loging 등을 지원하지 않음
    • REST API : 100만 건당 $1.51 ~ $3.50, HTTP API보다 다양한 기능을 제공
  13. WebSocket API - 요청을 받고 응답하는 REST API와는 다르게 클라이언트와 백엔드 간 양방향 통신 지원
    • 채팅, 알림, 실시간 대시보드에 사용됨
    • 3개의 기본 RouteKey를 가진다.
      1. $connect : 클라이언트가 연결을 요청했을 때
      2. $disconnect : 클라이언트가 연결을 끊었을 때
      3. $default : 클라이언트가 별도의 SelectionExpression을 지정하지 않았을 때

API Gateway vs ALB

  1. 확장성
    • API Gateway : 10000 RPS(requests per second) 가 제한
    • ALB : 제한 없음
  2. 신뢰성 및 가용성
    • API Gateway : 사용자가 관리할 필요 X
    • ALB : 사용자가 region 당 2개 이상의 AZ를 지정할 필요가 있음
  3. 타 서비스와 통합
    • API Gateway : Lambda 함수 이외에 DynamoDB, SQS, S3 등 HTTP 기반 서비스와 모두 통합 가능
    • ALB : Lambda, EC2, ECS, Cognito
  4. Routing
    • API Gateway : 경로 기반 라우팅 (클라이언트 요청 url 기반)
    • ALB : 규칙 기반 라우팅 (url 기반 + 요청자 host name, IP address, HTTP header, Request Type 등)
  5. 비용
    • API Gateway : 수신한 요청에 대해서만 부과
      • HTTP API : 100만 건당 $0.90 ~ $1.00
      • REST API : 100만 건당 $1.51 ~ $3.50
      • WebSockets : 100만 건당 $0.80 ~ $1.00, 연결 분당 0.25
    • ALB : 시간당 + 리소스 사용량당
      • 시간당 $0.0225
      • LCU(로드밸런서 용량 단위) 시간당 $0.008 - 참고

+ Recent posts