AWS re:Invent 2021 - Amazon IVS로 11번가 라이브커머스 플랫폼 구축

 

 

강연자: AWS 솔루션 아키텍트 이승민 님, 11번가 플랫폼 엔지니어 조현수 님.

 

 

AWS IVS?

• 완전관리형 interactive 라이브 영상 서비스.
  트위치와 동일한 기술 기반 - 10년에 걸쳐 구축한 라이브 스트리밍 기술이 활용되고 있다고 함
• AWS IVS로 라이브 스트리밍을 전송하고, SDK로 플레이어를 구현하면 된다.
  • 방송 송출 / 플레이어 사이의 모든 작업을 담당하는 것.

Interactive의 의미란?

 

라이브 스트리밍의 사용자 경험은 크게 두 가지로 나뉜다.

• Lean back: 콘텐츠 시청이 전부임. 따라서 콘텐츠의 품질이 사용자 경험의 중요한 가치.
• Lean forward: 스마트폰 등의 디바이스로 콘텐츠에 적극적으로 참여하는 것. Interactive을 의미함.
  • 예시의 경우 참가자들와 점수를 공유하는 리더보드, 오버레이 ui, emoji / 짧은 메시지로 소셜 인터렉션, 투표 기능 등
    다양한 사용자 참여형 기능을 제공한다.

 

Lean back의 경우 Latency가 크게 중요한 이슈는 아님. 사용자가 참여하는 것이 아니기 때문.

• 딜레이가 상대적으로 민감한 스포츠 경기조차도 6초 정도의 딜레이는 사용자 경험에 큰 지장을 주지 않음.

상호작용이 있는 라이브 스트리밍이나 게임의 경우... low latency가 중요함.

 

 

AWS IVS는 stream 수집, transcoding, stream 전송, player sdk를 통한 재생까지 latency를 낮추도록 최적화했음.
(송출 쪽의 최적화도 필요하지만)

• 대략적으로 5초 ~ 3초 정도의 latency 제공.

 

 

상호작용 자체를 위한 사용자 인터페이스는 아무래도 서비스 제공자가 직접 구현해야 할 필요가 있음.
직접 구현하는 과정을 지원하기 위해 Timed Metadata API를 제공함.

• 특정 타이밍에 맞는 메타데이터를 의미함.
• 예컨대 예시에서는 IVS가 영상을 처리하는 과정에서 6개의 segment로 분리했다.
  • putMetaData api를 통해서 1KB 미만의 데이터를 payload로 보낼 수 있다.

위의 예시처럼 "문제+답변" 정보를 메타데이터에 포함한 뒤, 플레이어에서 이 메타데이터를 받으면 퀴즈 구현이 가능하다.

• 영상 안에 메타데이터가 들어 있는 만큼 싱크 문제는 없고
• 지연시간 때문에 사용자가 서로 다른 메타데이터를 경험하는 일은 없게 된다.

 

 

미국과 유럽에 3개 region에는 IVS Console, Stream 제어와 생성을 위한 Control plane이 있는 것이고

영상 수집과 시청을 위한 인프라는 별도의 글로벌 인프라를 사용하고 있다. 따라서 어느 리전에서건 동일한 품질을 제공하고 있다고 함.

 

 

 

 

 

https://ivs.rocks/ 에서 자세한 내용 확인 가능. 공식 docs, 서비스 품질 상태도 확인이 가능함.

 

---

11번가의 사용사례

Live 11 : 11번가의 라이브커머스. 누적시청자 5000만

 

 

• 실시간 방송 조정: 쿠폰, 공지사항, 방송연동 상품과 같이 관리자가 실시간으로 조정 가능한 영역
• 실시간 채팅, 하트 클릭 효과
• 실시간 통계

 

아키텍처

• 여러 영상매체로부터 RTMP로 영상을 수신받는다.
• Ingest: 영상데이터를 받는 모듈
• Transcode: 받은 영상을 여러 bitrate 화질 영상으로 생성함 (1080, 720, 480...) (ABR)
• 클라이언트는 hls 프로토콜로 영상 요청. 스트리밍 데이터는 CDN으로 빠르게 받을 수 있다.

AWS IVS 선택 이유

• Ultra Low Latency. 5초 미만의 지연으로 판매자와 구매자 간 소통이 편리하다고 생각했음.
• IVS Player - 다양한 디바이스를 지원하고 있음. 비즈니스 개발에 초점을 맞추기 쉬웠다.

ex) 쿠폰 노출 시나리오

• admin 콘솔에서 '쿠폰 노출' 클릭
  • management api에서 '쿠폰 노출' 메시지를 kafka로 전송
  • message process 서버에서는 kafka 데이터를 받은 뒤, 필요할 경우 메시지를 가공하고 Redis로 publish
  • subscribe중인 모든 websocket에 메시지 전송
  • websocket에 연결된 클라이언트 방송화면에 쿠폰 노출
• admin 콘솔에서 '방송 효과' 기능: timed metadata 활용
  • 클라이언트가 hls로 영상을 내려받을 때, 파일 관련된 정보를 확인할 수 있도록 태그를 걸어두고 있다.
  • id3라는 특정 태그에 custom msg를 추가.
  • 클라이언트가 해당 영상 chunk를 송출할 때 custom message가 노출되는 식.
  • 영상의 특정 시점에 '마감 임박' 같은 특수효과를 제공하고 있음

ex) 실시간 채팅. 주문번호를 입력해 달라는 요청이 있을 경우, 단기간에 폭발적인 채팅 데이터가 전송될 수 있다.

• 채팅의 입력 처리와 전달 처리를 분리함. 채팅을 생성할 땐 http Message api를 사용하고, 채팅을 전달할 때는 websocket 양방향 통신을 활용함. 즉, 역할에 따른 리소스 분배
• 웹소켓의 과부하 방지를 위한 설계 = kafka에서 데이터를 받는 Message Process가 담당하고 있음. 부하가 기준치 이상일 경우 websocket으로 부하가 전달되지 않도록 조치함. (백프레셔 기능.)
  • 백프레셔? https://knight76.tistory.com/entry/spark-%EB%B0%B1%ED%94%84%EB%A0%88%EC%85%94Backpressure
• 채팅이 모든 시청자에게 broadcast되는 트래픽 경감.
  • ex) 1만명 입장 상황에서 메시지 입력 = 1만 명에게 broadcast 트래픽 발생. 채팅 개수가 많아질수록 트래픽이 비례해서 증가함.
  • message process 내에서 microConsumer를 두고, 동시간대에 발생하는 채팅을 묶어서 broadcast.
  • 동시간대에 발생하는 좋아요 개수도 마찬가지로 microConsumer에서 합산 count.

ex) 실시간 통계. admin console에서 현재 시청 수, 채팅 입력 개수 등을 실시간으로 확인할 수 있는 용도.

• kafka streams 기반 서버. message api나 websocket에서 kafka로 데이터가 들어오면, 상태 기반의 실시간 처리
• 상태 기반 = 이전에 발생했던 메시지를 참조해야 하는 경우.
  (누적시청수 같은 값은 이전에 처리한 값을 참조하는 방식으로 계산해서 실시간으로 보여줘야 함)
  • 누적 시청수를 로컬 상태저장소에 저장하고 관리하는 식으로 사용하고 있음.
  • 로컬 상태저장소는 kafka로 실시간 백업이 진행중. 서버 다운되더라도 다른 서버가 백업데이터 복구해서 유실을 막는다.

kafka streams 몇 가지 장점

1. kafka 신규버전 배포 시 kafka streams도 같이 배포됨 = 호환 보장. 유실이나 중복처리하지 않도록 보장하고 있음
2. high level API 기반의 DSL. 도메인 특화 언어를 지원하므로 코드가 간결하다.

핵심 아키텍처 요약

 

Live11의 모든 애플리케이션, 미들웨어, DB는 AWS에서 동작.

• kafka: AWS MSK
• Redis: AWS ElasticCache
• Aurora DB : 방송관련 정보 저장 / 관리용. Read 전용 replica 생성해서 DB 부하 분산중.
• kafka로 주고받는 메시지는 Avro 사용해서 Schema 유지
  • https://n-a-y-a.tistory.com/entry/하둡에코시스템-Apache-Avro-아파치-에이브로
  • Avro 형식의 메시지 schema 관리를 위한 schema 레지스트리 -> AWS Glue 사용.
    • Glue는 kafka 메시지 스키마를 등록하고 관리해주기 때문에, kafka에서 직접 메시지 스키마를 관리하지 않으므로 데이터 부하를 줄일 수 있다.
    • schema 버전관리를 지원하고 있음. producer / consumer 간 coupling 방지 가능.