Kiến trúc private ingest cho sports OTT: Thiết kế workflow live streaming ổn định trên AWS

Cách chúng tôi xây dựng kiến trúc private ingest cho sports OTT bằng hardware encoder, AWS Direct Connect, VPC-based ingest và multi-layer redundancy để vận hành hệ thống multi-channel live sports streaming ổn định trên cloud.

Kiến trúc private ingest cho sports OTT là gì?

Kiến trúc private ingest cho sports OTT là mô hình truyền tín hiệu live từ hệ thống broadcast lên nền tảng OTT cloud thông qua private network path thay vì public internet.

Kiến trúc này thường bao gồm:

• Hardware encoder
• Private connectivity như AWS Direct Connect
• VPC-based ingest
• MediaLive input endpoint
• Redundant network path
• Multi-layer failover

Mục tiêu chính của kiến trúc private ingest cho sports OTT là:

• giảm packet loss
• tăng độ ổn định ingest
• kiểm soát routing
• tối ưu live streaming reliability
• hạn chế ảnh hưởng từ Internet congestion

Mô hình này đặc biệt phù hợp với:

• live sports streaming
• multi-channel OTT
• broadcast-grade streaming workflow
• sự kiện thể thao quy mô lớn

Live sports bắt đầu từ ingest ổn định

Trong nhiều dự án OTT, câu chuyện thường bắt đầu từ các thành phần như packaging, CDN, player SDK hoặc analytics. Tuy nhiên, với streaming thể thao trực tiếp, câu hỏi quan trọng nhất lại nằm ở giai đoạn sớm hơn rất nhiều trong chuỗi xử lý: làm thế nào để đưa tín hiệu broadcast live lên cloud một cách ổn định, liên tục và có đủ khả năng kiểm soát để phục vụ một sự kiện thực tế?

Nói cách khác, live workflow thực sự bắt đầu ngay từ nguồn broadcast.

Streaming thể thao có mức độ chấp nhận gián đoạn gần như bằng không. Chỉ vài giây mất tín hiệu cũng có thể ảnh hưởng trực tiếp đến trải nghiệm người xem. Dù tốc độ khởi chạy video nhanh là một yếu tố quan trọng, điều kiện tiên quyết vẫn là luồng contribution từ nguồn phải ổn định.

Trong dự án này, chúng tôi cần truyền đồng thời trên nhiều kênh live từ thiết bị broadcast lên một nền tảng OTT trên cloud. Điều này đòi hỏi hệ thống ingest phải hoạt động liên tục, đáng tin cậy và có khả năng kiểm soát tốt trong suốt thời gian diễn ra sự kiện.

Tuy nhiên, workflow video ban đầu được thiết kế cho môi trường broadcast truyền thống, không phải cho một hệ thống OTT vận hành trên cloud. Điều này tạo ra khoảng cách giữa đầu ra broadcast và cơ chế ingest trên cloud.

Để giải quyết vấn đề đó, chúng tôi cần xây dựng một “cầu nối” giữa hai môi trường: chuyển đổi và đưa tín hiệu broadcast vào cloud theo cách ổn định, có kiểm soát và phù hợp với kiến trúc OTT hiện đại.

Yêu cầu và ràng buộc của dự án

Để xây dựng một hệ thống streaming nói chung và sports streaming nói riêng, ổn định trên cloud, chúng tôi cần xác định rõ các yêu cầu cả về mặt kỹ thuật lẫn vận hành.

Những yêu cầu này không chỉ đến từ trải nghiệm người dùng cuối mà còn từ đặc thù của hệ thống broadcast hiện có.

1. Live streaming thể thao đa kênh

Hệ thống cần hỗ trợ nhiều kênh live đồng thời, với tổng cộng 5 kênh hoạt động song song.

Điều này yêu cầu kiến trúc ingest và xử lý phải có khả năng scale theo số lượng luồng mà không ảnh hưởng đến độ ổn định của từng kênh.

2. Ingest live ổn định từ thiết bị broadcast

Luồng video đầu vào từ thiết bị broadcast phải được truyền liên tục và không gián đoạn. Đây là yêu cầu quan trọng nhất, vì ingest là điểm bắt đầu của toàn bộ live workflow. Nếu ingest không ổn định, toàn bộ pipeline phía sau sẽ bị ảnh hưởng.

Trong thực tế, tín hiệu từ broadcast equipment thường ổn định trong môi trường nội bộ. Tuy nhiên, khi đưa tín hiệu này ra ngoài để ingest vào cloud, hệ thống phải đối mặt với nhiều yếu tố như network jitter, packet loss hoặc sai lệch trong cấu hình mạng.

Vì vậy, hệ thống ingest cần được thiết kế để giảm thiểu các rủi ro này. Điều đó bao gồm việc lựa chọn giao thức phù hợp, cấu hình buffer hợp lý và đảm bảo đường truyền có tính ổn định cao.

Ngoài ra, khả năng phát hiện sớm và xử lý nhanh khi xảy ra input loss cũng là một phần quan trọng trong yêu cầu vận hành.

3. Tối ưu thời gian bắt đầu phát video cho người xem

Thời gian bắt đầu phát video cần được tối ưu để mang lại trải nghiệm tốt cho người dùng.

Tuy nhiên, mục tiêu này chỉ có thể đạt được nếu luồng ingest đầu vào ổn định và không bị ảnh hưởng bởi jitter hoặc packet loss. Nói cách khác, trải nghiệm playback của người xem phụ thuộc rất nhiều vào độ ổn định của contribution feed ngay từ đầu.

4. Contribution dựa trên hardware encoder

Do nguồn tín hiệu broadcast được xuất qua HDMI, hệ thống cần sử dụng hardware encoder để chuyển đổi tín hiệu sang định dạng IP phù hợp, ví dụ như RTMP hoặc RTP.

Encoder trở thành một thành phần quan trọng trong việc đảm bảo chất lượng và tính ổn định của luồng video.

Encoder chịu trách nhiệm encode video/audio với các thông số như bitrate, resolution, frame rate, GOP structure và keyframe interval. Tất cả các thông số này đều ảnh hưởng trực tiếp đến chất lượng và độ ổn định của luồng ingest.

Ngoài ra, encoder cũng đóng vai trò như một “edge device” trong hệ thống, nơi có thể cấu hình retry logic, stream buffering và endpoint failover.

Vì vậy, việc lựa chọn và cấu hình encoder không chỉ là bài toán thiết bị, mà là một phần của thiết kế hạ tầng tổng thể. Một encoder được cấu hình tốt sẽ giúp giảm áp lực cho network và downstream processing. Ngược lại, một encoder cấu hình sai có thể gây ra sự không ổn định cho toàn bộ hệ thống live.

5. Kết nối private lên cloud

Luồng ingest không thể phụ thuộc hoàn toàn vào public internet. Thay vào đó, hệ thống cần sử dụng private connectivity để đảm bảo routing ổn định, giảm rủi ro packet loss và tăng khả năng kiểm soát đường truyền.

Cụ thể, các hardware encoder tại phía on-premise sẽ push luồng video RTMP qua mạng nội bộ, đi qua firewall và router, sau đó được định tuyến qua AWS Direct Connect để vào AWS.

Từ đó, traffic đi qua Direct Connect Gateway và Virtual Private Gateway để vào VPC, nơi các ingest endpoint của AWS Elemental MediaLive được triển khai trong private subnets.

Cách tiếp cận này giúp đảm bảo toàn bộ đường ingest, từ encoder đến MediaLive channel, diễn ra trên một network path có thể kiểm soát. Hệ thống tránh được các biến động của Internet như route changes, congestion hoặc packet loss không thể dự đoán.

Ngoài ra, việc sử dụng private connectivity cũng giúp đơn giản hóa thiết kế security, bao gồm firewall rules và security groups, đồng thời tăng khả năng quan sát và troubleshooting trong quá trình vận hành live.

6. Chuẩn bị encoder dự phòng

Ngoài 5 encoder hoạt động chính, hệ thống cần chuẩn bị thêm 2 encoder dự phòng.

Điều này cho phép thay thế nhanh chóng khi xảy ra sự cố phần cứng hoặc lỗi cấu hình trong quá trình live.

7. Khả năng quan sát hệ thống trong thời gian diễn ra sự kiện live

Trong các sự kiện live, đội vận hành cần có khả năng quan sát toàn bộ hệ thống, từ encoder, network cho đến ingest endpoint.

Việc này bao gồm monitoring, alerting và khả năng troubleshooting nhanh khi có sự cố xảy ra. Với live sports, khả năng phát hiện sớm vấn đề và phản ứng nhanh là yếu tố rất quan trọng để giảm thiểu ảnh hưởng đến người xem.

Kiến trúc tổng quan

Kiến trúc tổng thể được chia thành hai phần chính:

1. On-premise site
2. AWS Cloud site

Luồng xử lý bắt đầu từ hệ thống broadcast tại on-premise, sau đó được encode thành IP stream, truyền qua private connectivity và ingest vào AWS Elemental MediaLive thông qua VPC input.

Phía on-premise

Phía on-premise đóng vai trò là điểm bắt đầu của toàn bộ live workflow. Đây là nơi tiếp nhận nguồn tín hiệu broadcast và chuẩn bị luồng video trước khi ingest lên cloud.

Kiến trúc được thiết kế để chuyển đổi tín hiệu từ môi trường broadcast truyền thống sang OTT/IP-based workflow một cách ổn định và có thể kiểm soát.

Luồng xử lý tại on-premise bao gồm các thành phần chính sau.

Thiết bị broadcast

Thiết bị broadcast cung cấp nguồn tín hiệu live từ hệ thống production/broadcast hiện có. Đây là nguồn video gốc cho các kênh thể thao được phân phối lên OTT platform.

Hardware encoder

Hardware encoder nhận tín hiệu HDMI từ thiết bị broadcast và thực hiện encode sang IP stream.

Trong kiến trúc này, encoder được cấu hình để push luồng RTMP lên cloud ingest endpoint thông qua private network path.

Firewall / Edge Security Gateway

Firewall hoặc Edge Security Gateway kiểm soát security policy, filtering và network traffic trước khi stream đi vào hệ thống private connectivity.

Thành phần này giúp giới hạn các kết nối được phép và hỗ trợ monitoring/troubleshooting trong quá trình live.

Router kết nối private / Carrier router

Router kết nối private hoặc carrier router đóng vai trò kết nối giữa hệ thống on-premise và private network path đi tới AWS.

Từ đây, traffic được định tuyến vào đường truyền chuyên dụng thay vì đi qua public internet.

Toàn bộ luồng RTMP contribution từ encoder được truyền qua một network path riêng biệt và có kiểm soát, giúp tăng tính ổn định cho ingest workflow trong các sự kiện live sports.

Phía AWS Cloud

AWS Direct Connect

AWS Direct Connect là điểm kết nối private giữa hệ thống on-premises và AWS.

Toàn bộ RTMP ingest traffic từ encoder được truyền qua Direct Connect thay vì Internet công cộng, giúp routing ổn định và predictable hơn.

Direct Connect Gateway

Direct Connect Gateway được sử dụng để kết nối AWS Direct Connect với VPC phía AWS.

Thành phần này đóng vai trò trung gian trong việc trao đổi routing giữa on-premise network và AWS network thông qua BGP.

Virtual Private Gateway

Virtual Private Gateway được attach vào VPC để nhận traffic từ Direct Connect Gateway.

Traffic từ CIDR subnet phía on-premise sẽ được propagate vào route table của VPC thông qua Virtual Private Gateway.

VPC Route Tables

Route table của private subnet được cấu hình để định tuyến traffic từ on-premises CIDR đi qua Virtual Private Gateway.

Điều này cho phép encoder phía on-premise có thể reach đến MediaLive ingest endpoint thông qua private network path.

Private subnets

Các ingest endpoints của AWS Elemental MediaLive được triển khai bên trong private subnet để đảm bảo ingest workflow không được expose ra Internet.

Security Groups

Security group của MediaLive input được cấu hình để chỉ allow RTMP traffic, TCP port 1935, từ CIDR subnet phía on-premise.

Điều này giúp giới hạn nguồn được phép push stream vào ingest endpoint và tăng khả năng kiểm soát security cho hệ thống.

MediaLive VPC Input Endpoints

MediaLive VPC Input Endpoints là điểm ingest chính nhận RTMP push stream từ hardware encoder phía on-premise.

Các endpoint này hoạt động hoàn toàn trong private network thông qua VPC input architecture.

MediaLive Channel / Media Output

Sau khi nhận ingest, MediaLive thực hiện xử lý live workflow như decoding, transcoding và output stream cho downstream OTT services.

Amazon CloudFront CDN

Amazon CloudFront CDN được sử dụng để phân phối nội dung đến người xem cuối cùng với khả năng mở rộng toàn cầu và tối ưu hóa độ trễ phát lại (playback latency).

Player / End users

Người xem truy cập nội dung live thông qua OTT player, nơi stream được phân phối từ CDN layer.

Với thiết kế này, toàn bộ ingest workflow từ encoder phía on-premise đến MediaLive input trên AWS được vận hành trong một kiến trúc private ingest cho sports OTT, có thể kiểm soát rõ ràng về routing, security và operational visibility.

Vì sao kiến trúc private ingest cho sports OTT cần private connectivity?

Trong nhiều trường hợp, ingest qua public internet thường là lựa chọn ban đầu, đặc biệt với các sự kiện nhỏ hoặc những môi trường không yêu cầu cao về độ ổn định.

Tuy nhiên, với streaming thể thao, ingest không còn là một bước truyền dữ liệu đơn thuần. Nó trở thành một phần của hệ thống broadcast, nơi mọi gián đoạn đều có thể ảnh hưởng trực tiếp đến trải nghiệm người xem.

Hạn chế lớn nhất của public internet không nằm ở băng thông, mà ở tính không thể dự đoán. Routing có thể thay đổi, congestion có thể xảy ra theo thời điểm, packet loss hoặc jitter cũng rất khó kiểm soát.

Với live sports, những yếu tố này tạo ra rủi ro không thể chấp nhận.

So sánh private connectivity và public internet cho live ingest

Để đảm bảo tính ổn định, chúng tôi sử dụng AWS Direct Connect để thiết lập một đường ingest private từ encoder on-premises lên cloud.

Cách tiếp cận này giúp xây dựng một network path có thể kiểm soát, với routing ổn định, latency nhất quán và khả năng quan sát rõ ràng, thay vì phụ thuộc vào một kết nối best-effort như public internet.

AWS Direct Connect

AWS Direct Connect thiết lập một đường truyền chuyên dụng, tốc độ cao, kết nối trực tiếp giữa trung tâm dữ liệu nội bộ, tức là on-premises, và hạ tầng AWS.

Đây là một kết nối riêng biệt, tách khỏi mạng Internet công cộng, nhằm mang lại khả năng truy cập vào các tài nguyên AWS với độ bảo mật cao, sự ổn định và độ trễ thấp.

Liên kết vật lý trực tiếp này giúp quá trình truyền tải dữ liệu trở nên tin cậy và hiệu quả hơn, đặc biệt phù hợp với các nhu cầu truyền dữ liệu quan trọng, khối lượng lớn hoặc các workload yêu cầu độ ổn định cao.

AWS Direct Connect cung cấp hai loại kết nối chính để thiết lập giao tiếp giữa môi trường on-premises và AWS Cloud:

1. Dedicated Connection
2. Hosted Connection

1. Dedicated Connection

Dedicated Connection là kết nối vật lý được cung cấp trực tiếp bởi AWS giữa trung tâm dữ liệu on-premises của doanh nghiệp và một AWS Direct Connect location.

Loại kết nối này phù hợp với các hệ thống yêu cầu băng thông lớn, độ ổn định cao và doanh nghiệp có khả năng đầu tư cũng như vận hành hạ tầng mạng chuyên dụng.

2. Hosted Connection

Hosted Connection là kết nối được cung cấp và quản lý bởi AWS Direct Connect Partner.

Khác với Dedicated Connection, nơi AWS cung cấp đường kết nối vật lý trực tiếp từ trung tâm dữ liệu on-premises đến AWS Direct Connect location, Hosted Connection sử dụng hạ tầng chia sẻ do Partner quản lý.

Partner chịu trách nhiệm về hạ tầng vật lý và việc cấp phát kết nối, trong khi doanh nghiệp truy cập các tài nguyên AWS Cloud thông qua kết nối được cung cấp bởi Partner.

Các đặc điểm chính của Hosted Connection

Chi phí đầu tư ban đầu thấp hơn

Hosted Connection giúp tối ưu chi phí đầu tư ban đầu vì phần hạ tầng được quản lý bởi AWS Direct Connect Partner.

Doanh nghiệp không cần tự triển khai phần cứng hoặc đầu tư lớn cho việc thiết lập kết nối vật lý chuyên dụng.

Khả năng mở rộng linh hoạt

Với Hosted Connection, doanh nghiệp có thể bắt đầu với mức băng thông nhỏ và nâng cấp theo nhu cầu sử dụng.

Tùy theo đơn vị đối tác và khu vực triển khai, băng thông có thể được cung cấp theo nhiều mức khác nhau, giúp doanh nghiệp lựa chọn cấu hình phù hợp với nhu cầu thực tế.

Dịch vụ được quản lý bởi các đối tác

Đối tác cung cấp dịch vụ sẽ đảm nhiệm việc provisioning và cấu hình kết nối ở phía hạ tầng mạng.

Điều này giúp giảm bớt gánh nặng vận hành cho đội ngũ kỹ thuật nội bộ.

Nhiều tùy chọn băng thông (bandwidth)

Hosted Connection cung cấp nhiều tùy chọn băng thông linh hoạt, thường từ 50 Mbps đến 10 Gbps, tùy thuộc vào đối tác và khu vực hỗ trợ.

Triển khai nhanh chóng

Do hạ tầng vật lý đã được đối tác chuẩn bị và quản lý sẵn, Hosted Connection thường có thể được triển khai nhanh hơn so với Dedicated Connection.

Điều này giúp rút ngắn thời gian đưa ứng dụng hoặc workload lên môi trường cloud.

Hướng dẫn tổng quan: Thiết lập AWS Direct Connect

Việc thiết lập AWS Direct Connect Hosted Connection thường bao gồm nhiều bước phối hợp giữa hạ tầng on-premises, AWS Direct Connect Partner và AWS.

Dưới đây là hướng dẫn tổng quan cho quy trình thiết lập.

Bước 1: Lựa chọn AWS Direct Connect Partner

Trước tiên, cần lựa chọn AWS Direct Connect Partner hỗ trợ connectivity tại region mục tiêu và phù hợp với yêu cầu về network cũng như business.

Có thể tham khảo danh sách AWS Direct Connect locations và các Partner được hỗ trợ trong tài liệu chính thức của AWS.

Bước 2: Yêu cầu tạo Hosted Connection

Sau khi lựa chọn bandwidth và Partner, cần gửi yêu cầu đến AWS Direct Connect Partner để provision Hosted Connection.

AWS Direct Connect Partner sẽ chuẩn bị hạ tầng cần thiết và thiết lập kết nối từ phía Partner đến AWS Direct Connect location.

Trong dự án này, chúng tôi sử dụng AWS Direct Connect Hosted Connection được cung cấp bởi NTT Communications tại Nhật Bản để thiết lập private connectivity giữa môi trường on-premises và AWS.

Tuy nhiên, tùy theo use case và khu vực triển khai, có thể sử dụng các AWS Direct Connect Partner khác.

Tổng quan kiến trúc kết nối NTT FIC

Kiến trúc kết nối thông qua NTT Flexible InterConnect, gọi tắt là NTT FIC, được chia thành hai phần chính:

1. Kết nối từ hệ thống enterprise/on-premise vào NTT Flexible InterConnect thông qua Arcstar Universal One
2. Kết nối từ FIC Router sang AWS thông qua AWS Direct Connect Private VIF

1. Kết nối từ enterprise/on-premise vào NTT FIC thông qua Arcstar Universal One

Để kết nối enterprise network vào FIC Router, phía NTT sử dụng Arcstar Universal One, gọi tắt là UNO, như một private L3 network path giữa customer site và Flexible InterConnect platform.

Các thành phần chính bao gồm:

• UNO routing group
• Primary/secondary connection
• BGP peering
• Customer ASN
• VPN / routing information
• Route advertisement giữa enterprise network và FIC Router

Xem chi tiết từ tài liệu chính thức của NTT: Connecting the FIC Router to Arcstar Universal One (UNO)

2. Kết nối từ FIC Router sang AWS thông qua AWS Direct Connect Private VIF

Phần kết nối từ FIC Router sang AWS bao gồm một số thành phần chính:

• AWS Direct Connect Hosted Connection
• Private Virtual Interface, gọi tắt là Private VIF
• BGP peering
• ASN configuration
• Direct Connect Gateway, gọi tắt là DXGW
• Virtual Private Gateway, gọi tắt là VGW

Sau khi phía NTT hoàn tất việc provision và tạo Private VIF, engineer cần truy cập AWS Direct Connect Console để accept Virtual Interface trước khi kết nối BGP có thể hoạt động hoàn chỉnh.

Việc kiểm tra availability của hai đường VIF, primary và secondary, cũng là bước cần thực hiện trước khi đưa hệ thống vào vận hành.

Xem chi tiết từ tài liệu chính thức của NTT: Connecting the FIC Router to AWS (Private)

Lưu ý:

Sau khi phía NTT hoàn tất việc provision và tạo Private VIF, engineer cần truy cập AWS Direct Connect Console để accept Virtual Interface (VIF) trước khi kết nối BGP có thể hoạt động hoàn chỉnh AWS Portal Operations (Virtual Interface Approval)

Bước 3: Tạo Direct Connect Gateway

Sau khi Hosted Connection và Private VIF được chuẩn bị, bước tiếp theo là tạo Direct Connect Gateway trên AWS.

Các bước tổng quan như sau:

1. Truy cập AWS Direct Connect Console
2. Chọn Direct Connect gateways
3. Chọn Create Direct Connect gateway
4. Nhập các thông tin cần thiết
5. Tạo Direct Connect Gateway

Các thông tin cần cấu hình bao gồm:

• Name: tên giúp nhận diện Direct Connect Gateway
• Amazon side ASN: ASN cho phía Amazon trong BGP session

Amazon side ASN cần nằm trong range được AWS hỗ trợ, ví dụ từ 64,512 đến 65,534 hoặc từ 4,200,000,000 đến 4,294,967,294.

Bước 4: Tạo Virtual Private Gateway

Sau khi tạo Direct Connect Gateway, cần tạo Virtual Private Gateway để thêm vào VPC.

Các bước tổng quan như sau:

1. Truy cập AWS Management Console
2. Đi đến VPC
3. Chọn Virtual Private Gateways
4. Chọn Create Virtual Private Gateway
5. Nhập tên và ASN
6. Attach Virtual Private Gateway vào VPC cần sử dụng

ASN có thể sử dụng giá trị mặc định như 64512 hoặc một private ASN tùy theo thiết kế network.

Sau khi tạo xong Virtual Private Gateway, cần attach nó vào VPC nơi triển khai MediaLive VPC input.

Bước 5: Cập nhật route table của private subnet

Việc cập nhật route table giúp đảm bảo traffic giữa hạ tầng on-premises và các dịch vụ AWS được định tuyến thông qua AWS Direct Connect, thay vì đi qua public internet.

Các bước tổng quan như sau:

1. Truy cập Amazon VPC Console
2. Đi đến mục Route Tables
3. Xác định route table gắn với VPC hoặc private subnet cần sử dụng
4. Chọn Edit routes
5. Thêm route cho CIDR block của on-premises network
6. Chọn target là Virtual Private Gateway đã associate với Direct Connect

Ví dụ:

• Destination: CIDR block của on-premises network, ví dụ 192.168.0.0/16
• Target: Virtual Private Gateway liên kết với Direct Connect

Sau khi route table được cập nhật đúng, traffic giữa encoder network phía on-premise và private subnet trên AWS có thể đi qua Direct Connect path.

Lựa chọn encoder: Cầu nối giữa broadcast và OTT

Trên thị trường hiện có nhiều loại encoder khác nhau. Ở quy mô global, có thể kể đến các nhà cung cấp như ATEME với TITAN hoặc Kyrion, Harmonic, Haivision và VIDEON. Tại Nhật Bản, cũng có các nhà sản xuất như NTT Innovative Devices và Fujitsu.

Sau nhiều thử nghiệm thực tế với một số loại encoder để push stream lên nền tảng OTT, trong dự án này, chúng tôi lựa chọn VIDEON vì phù hợp nhất với các điều kiện kỹ thuật và vận hành của dự án.

Để đạt được chất lượng video tốt và ổn định trên màn hình TV 65 inch, cấu hình encode cần đáp ứng tối thiểu 1080p với bitrate từ khoảng 5.4 Mbps trở lên.

Encoder không chỉ đơn thuần là thiết bị chuyển đổi HDMI sang RTMP. Nó là một thành phần quan trọng trong contribution workflow, ảnh hưởng trực tiếp đến chất lượng video, độ ổn định của ingest và khả năng phục hồi khi có sự cố.

Kiến trúc VPC-based ingest trong sports OTT hoạt động như thế nào?

AWS Elemental MediaLive là dịch vụ live video processing trên AWS. Dịch vụ này cho phép nhận ingest từ nhiều nguồn khác nhau và encode/transcode thành các output phù hợp cho OTT streaming workflow.

Document chính thức từ AWS: How MediaLive works

Trong kiến trúc này, MediaLive đóng vai trò trung tâm của hệ thống live streaming. MediaLive tiếp nhận luồng RTMP từ hardware encoder, xử lý video theo profile cấu hình và phân phối output tới downstream services như MediaPackage, CDN hoặc player platform.

Do yêu cầu ingest private và ổn định cho live sports streaming, MediaLive được triển khai theo mô hình VPC-based ingest. Cách tiếp cận này giúp giữ toàn bộ contribution traffic nằm trong private network path thay vì đi qua public internet.

Hướng dẫn tổng quan: Thiết lập MediaLive VPC ingest

Bước 1: Tạo AWS Elemental MediaLive Input

Trước tiên, cần tạo MediaLive input trong AWS Elemental MediaLive.

Các bước tổng quan như sau:

1. Truy cập AWS Management Console
2. Đi đến AWS Elemental MediaLive
3. Chọn Inputs
4. Chọn Create input
5. Nhập tên input
6. Chọn input type phù hợp

Trong dự án này, hệ thống sử dụng RTMP push từ encoder ở phía on-premise.

Các cấu hình quan trọng bao gồm:

• Input type: RTMP push
• Input network location: AWS
• Network mode: VPC
• Private subnet: subnet nơi đặt MediaLive input endpoint
• Security group: allow TCP port 1935 từ CIDR private IP range phía on-premise
• Role ARN: IAM role cho MediaLive input

Input destination

Khi tạo MediaLive input, có thể lựa chọn STANDARD_INPUT hoặc SINGLE_INPUT.

STANDARD_INPUT

Với STANDARD_INPUT, MediaLive sẽ tạo ra 2 ingest endpoints tương ứng với 2 pipeline riêng biệt.

Mỗi endpoint nằm ở subnet hoặc Availability Zone khác nhau để hỗ trợ redundancy và high availability.

Mô hình này phù hợp với workload live yêu cầu độ ổn định cao, nhưng chi phí cũng cao hơn do sử dụng dual pipeline architecture.

SINGLE_INPUT

Với SINGLE_INPUT, MediaLive chỉ tạo ra 1 ingest endpoint duy nhất.

Mô hình này không có redundancy cho ingest pipeline nhưng giúp tối ưu chi phí hơn so với STANDARD_INPUT.

Với live streaming thể thao, đặc biệt là các sự kiện quan trọng, STANDARD_INPUT thường phù hợp hơn vì hỗ trợ kiến trúc redundant ingest.

Bước 2: Tạo AWS Elemental MediaLive Channel

Sau khi hoàn tất MediaLive input và VPC ingest configuration, bước tiếp theo là tạo AWS Elemental MediaLive channel để xử lý live video workflow.

Ở bước này, engineer cần cấu hình các thành phần chính sau:

• Input source cho channel
• Channel class, ví dụ STANDARD hoặc SINGLE_PIPELINE
• Video/audio encoding profile
• Output group
• MediaPackage hoặc downstream destination
• Logging và monitoring settings
• IAM role cho MediaLive

Do cấu hình MediaLive channel có nhiều thành phần liên quan đến encoding profile, output workflow và pipeline behavior, engineer cần tham khảo tài liệu chính thức của AWS và điều chỉnh theo yêu cầu cụ thể của hệ thống.

Lưu ý quan trọng về Output Delivery trong VPC mode

Một điểm quan trọng cần lưu ý khi sử dụng MediaLive VPC mode là phần Output Delivery.

Nếu MediaLive output được triển khai trong private subnet và push stream tới một public endpoint như MediaPackage hoặc external CDN endpoint, traffic sẽ phải đi qua NAT Gateway để truy cập public service endpoint.

Điều này có thể phát sinh thêm chi phí NAT Gateway processing fee, đặc biệt đáng kể với workload live streaming có bandwidth lớn và hoạt động liên tục trong nhiều giờ.

Để tối ưu chi phí và đơn giản hóa network path, chúng tôi sử dụng giải pháp sau:

• Tạo Elastic IP public cho MediaLive output
• Đặt Output Delivery trong public subnet
• Gán Elastic IP trực tiếp cho Output Delivery interface

Với cách này, traffic output từ MediaLive tới MediaPackage sẽ được route trực tiếp thông qua Internet Gateway thay vì NAT Gateway.

Cách tiếp cận này mang lại một số lợi ích:

• Loại bỏ NAT Gateway processing cost
• Giảm thêm một network hop trong output path
• Dễ kiểm soát outbound IP cho downstream whitelist

Điểm quan trọng là mặc dù Output Delivery được đặt trong public subnet, traffic giữa MediaLive và các AWS managed services như MediaPackage vẫn đi bên trong AWS global network backbone, không đi ra public internet theo nghĩa truyền thống.

AWS cũng mô tả cơ chế hoạt động này trong tài liệu chính thức: AWS MediaLive VPC Output – How it works

Redundancy nhiều lớp trong kiến trúc private ingest cho sports OTT

Với hệ thống live sports OTT, redundancy không chỉ nằm ở một thành phần riêng lẻ. Redundancy cần được thiết kế xuyên suốt toàn bộ ingest path, từ encoder on-premise, network connectivity cho đến MediaLive pipeline trong AWS.

Redundancy cho encoder

Ở phía on-premise, hệ thống sử dụng:

• 5 hardware encoder hoạt động chính cho 5 live channels
• 2 hardware encoder dự phòng

Các encoder backup được chuẩn bị sẵn cấu hình để có thể thay thế nhanh chóng nếu một encoder chính gặp sự cố trong quá trình live event.

Điều này giúp giảm downtime và tránh ảnh hưởng đến luồng ingest đang hoạt động.

Trong vận hành thực tế, việc có backup encoder là chưa đủ. Quy trình failover và thay thế encoder cũng cần được rehearsal trước sự kiện live.

Redundancy cho network

Tầng network redundancy được triển khai thông qua AWS Direct Connect với:

• 1 đường Private VIF primary, hoạt động ở trạng thái active
• 1 đường Private VIF secondary, hoạt động ở trạng thái standby

Hai kết nối này hoạt động thông qua BGP peering giữa on-premise network và AWS Direct Connect Gateway.

Khi đường primary gặp sự cố, traffic có thể failover sang secondary path nhằm duy trì kết nối ingest tới AWS.

Ngoài ra, thiết kế network cũng cần lưu ý một số điểm quan trọng:

• Tránh overlap CIDR giữa on-premise và VPC
• Theo dõi trạng thái BGP session
• Monitoring route propagation và traffic flow
• Kiểm soát firewall/routing policy rõ ràng giữa các node

Redundancy cho media pipeline

Ở phía AWS, hệ thống sử dụng MediaLive với STANDARD_INPUT và STANDARD channel class.

Với cấu hình này:

• MediaLive tạo ra 2 ingest endpoints riêng biệt
• Mỗi endpoint tương ứng với một ingest pipeline hoặc ENI khác nhau
• Encoder có thể push stream đồng thời tới cả hai pipeline
• Nếu một pipeline hoặc Availability Zone gặp sự cố, MediaLive vẫn có thể tiếp tục xử lý và output stream từ pipeline còn lại

Thiết kế này giúp tăng tính ổn định cho ingest và encode pipeline, đặc biệt quan trọng với các workload live sports yêu cầu high availability liên tục trong suốt thời gian diễn ra sự kiện.

Kiểm thử trước khi launch

Sau khi hoàn tất toàn bộ cấu hình network, AWS Direct Connect, MediaLive input và encoder setup, bước tiếp theo là kiểm tra end-to-end connectivity trước khi đưa hệ thống vào vận hành thực tế.

Testing không chỉ nhằm xác nhận hệ thống “có chạy” hay không, mà còn để kiểm tra khả năng vận hành ổn định trong điều kiện gần giống với live event thực tế.

Kiểm thử kết nối network

Đầu tiên, chúng tôi kiểm tra khả năng reachability giữa on-premise encoder network và AWS VPC thông qua ICMP protocol.

Ở phía AWS, một EC2 instance được tạo trong private subnet, cùng route path với MediaLive ingest endpoint, để thực hiện các bài test network cơ bản.

Các bước kiểm tra bao gồm:

• Ping từ encoder hoặc on-premise network tới AWS private subnet
• Ping từ EC2 trong AWS VPC ngược lại CIDR phía on-premise
• Xác nhận route propagation từ Direct Connect Gateway và Virtual Private Gateway
• Kiểm tra firewall và security group rule

Việc này giúp xác nhận traffic đang đi đúng qua AWS Direct Connect thay vì public internet.

Sau khi ICMP connectivity hoạt động ổn định, bước tiếp theo là kiểm tra RTMP ingest path.

Hệ thống thực hiện test TCP port 1935 giữa encoder và MediaLive VPC input endpoint để xác nhận:

• RTMP port đã được allow đúng trong Security Group
• Firewall policy phía on-premise hoạt động chính xác
• Encoder có thể establish RTMP session tới MediaLive ingest endpoint

Sau khi network và RTMP connectivity được xác nhận, hệ thống tiếp tục thực hiện continuous streaming test để kiểm tra độ ổn định của ingest pipeline trước khi launch chính thức.

Kiểm thử độ ổn định của video và ingest

Continuous stream test

Push stream liên tục trong thời gian dài để kiểm tra tính ổn định của encoder, network path và MediaLive ingest pipeline dưới workload thực tế.

Bitrate stability

Theo dõi bitrate output từ encoder nhằm xác nhận stream không bị dao động bất thường, giảm bitrate đột ngột hoặc phát sinh jitter ảnh hưởng đến viewer experience.

Audio/video sync

Kiểm tra độ đồng bộ giữa audio và video trong suốt quá trình streaming để tránh hiện tượng lệch tiếng hoặc delay hình ảnh.

Input loss detection

Mô phỏng tình huống mất tín hiệu ingest để xác nhận MediaLive detect input loss đúng cách và hệ thống monitoring/alerting hoạt động chính xác.

Restart behavior

Thực hiện restart encoder hoặc restart ingest workflow để kiểm tra khả năng recovery và reconnect của hệ thống mà không gây ảnh hưởng lớn đến downstream streaming pipeline.

Encoder replacement test

Mô phỏng tình huống thay thế encoder chính bằng encoder backup trong lúc live để xác nhận quy trình failover vận hành đúng như thiết kế.

Backup encoder activation test

Kiểm tra khả năng kích hoạt encoder dự phòng và push stream vào MediaLive ingest endpoint trong trường hợp encoder chính gặp sự cố.

Các bài test này giúp đội vận hành đánh giá không chỉ tính ổn định của network path, mà còn khả năng xử lý các sự cố thực tế trước khi hệ thống phục vụ production live sports events.

Kiểm thử mức độ sẵn sàng vận hành

Ngoài network và video workflow, chúng tôi cũng thực hiện các bài kiểm tra liên quan đến vận hành thực tế trong ngày diễn ra sự kiện live.

Monitoring dashboard

Xác nhận các monitoring dashboard hiển thị đầy đủ trạng thái encoder, network connectivity, MediaLive input, bitrate và streaming health theo thời gian thực.

Alert notification

Kiểm tra cơ chế alert khi xảy ra sự cố như mất ingest, bitrate bất thường, encoder disconnect hoặc BGP session down để đảm bảo đội vận hành có thể phản ứng kịp thời.

Runbook cho ngày diễn ra live event

Chuẩn bị và review runbook cho ngày live event, bao gồm các bước xử lý sự cố, kiểm tra hệ thống trước giờ live và quy trình failover.

Luồng escalation

Xác định rõ luồng escalation giữa các team liên quan như broadcast, network, cloud infrastructure và OTT operation để giảm thời gian xử lý khi có incident xảy ra.

Quy trình rollback

Thực hiện kiểm tra các phương án rollback hoặc chuyển sang backup workflow nếu hệ thống chính gặp lỗi trong quá trình live streaming.

Các bài test vận hành này giúp đảm bảo không chỉ hệ thống kỹ thuật hoạt động ổn định, mà còn quy trình operation cũng sẵn sàng cho production live sports events.

Những bài học vận hành rút ra

Sau khi hoàn thành quá trình triển khai và kiểm thử, điều chúng tôi nhận ra là một hệ thống live sports OTT ổn định không phụ thuộc vào duy nhất một công nghệ hay một service nào.

AWS Direct Connect giúp ingest path ổn định hơn, nhưng reliability thực tế chỉ đạt được khi toàn bộ workflow, từ encoder, network, MediaLive ingest cho đến monitoring và operation, được thiết kế đồng bộ.

Một điểm quan trọng khác là broadcast workflow và cloud infrastructure workflow có cách tiếp cận rất khác nhau.

Vì vậy, các khái niệm như feed, input, pipeline, endpoint hay channel cần được thống nhất ngay từ đầu để tránh khó khăn trong quá trình vận hành và troubleshooting live event.

Chúng tôi cũng nhận thấy rằng ingest path nên được quản lý như một production network thực thụ.

Các yếu tố như IP range, route table, security group, firewall policy, ownership và failover procedure đều cần được document rõ ràng, thay vì chỉ tồn tại dưới dạng “knowledge” của từng engineer.

Ngoài ra, redundancy chỉ thực sự có ý nghĩa khi được kiểm thử thực tế.

Backup encoder, secondary VIF hay MediaLive redundant input sẽ không mang lại nhiều giá trị nếu đội vận hành chưa từng rehearsal failover workflow trước ngày production.

Cuối cùng, VPC-based ingest mang lại khả năng kiểm soát và bảo mật tốt hơn, nhưng cũng yêu cầu network planning cẩn thận hơn rất nhiều, đặc biệt ở các phần CIDR design, route propagation và subnet architecture.

Kết luận

Xây dựng một sports OTT service không chỉ là bài toán phân phối video đến người xem cuối. Một phần quan trọng không kém là làm thế nào để đưa live source vào cloud một cách ổn định và đáng tin cậy.

Bằng cách thiết kế contribution path với hardware encoder, private connectivity, VPC-based ingest và multi-layer redundancy, chúng tôi đã xây dựng được nền tảng ổn định cho hệ thống multi-channel sports live streaming.

Trong kiến trúc private ingest cho sports OTT này, AWS Direct Connect giúp tạo ra network path có thể kiểm soát, MediaLive VPC input giúp ingest traffic nằm trong private network, còn redundancy ở nhiều lớp giúp hệ thống sẵn sàng hơn trước các sự cố trong quá trình live event.

Đối với live sports streaming, reliability không đến từ một thành phần đơn lẻ. Nó đến từ cách toàn bộ hệ thống được thiết kế, kiểm thử và vận hành như một production-grade workflow ngay từ đầu.

Khi nhu cầu live sports streaming ngày càng tăng, kiến trúc private ingest cho sports OTT đang trở thành một phần quan trọng trong hạ tầng OTT hiện đại. Việc kết hợp hardware encoder, AWS Direct Connect, MediaLive VPC ingest và multi-layer redundancy không chỉ giúp tăng độ ổn định cho ingest workflow mà còn tạo nền tảng vững chắc cho các hệ thống sports OTT quy mô lớn vận hành trên cloud.

Những câu hỏi thường gặp

Kiến trúc private ingest cho sports OTT khác gì ingest qua public internet?

Kiến trúc private ingest cho sports OTT sử dụng đường truyền riêng như AWS Direct Connect để đưa tín hiệu broadcast lên cloud thay vì đi qua public internet. Điều này giúp giảm packet loss và jitter và tăng khả năng kiểm soát routing cho live sports streaming.

Vì sao sports OTT cần VPC-based ingest?

VPC-based ingest giúp traffic ingest nằm hoàn toàn trong private network path, tăng security, giảm exposure ra Internet và cải thiện độ ổn định cho live streaming workflow.

AWS Direct Connect có bắt buộc cho sports OTT không?

Không bắt buộc, nhưng với các hệ thống sports OTT yêu cầu broadcast-grade reliability, AWS Direct Connect giúp tạo network path ổn định và predictable hơn so với public internet.

STANDARD_INPUT trong MediaLive có vai trò gì?

STANDARD_INPUT tạo hai ingest pipeline độc lập giúp MediaLive hỗ trợ redundancy và high availability cho live streaming workflow.

Hardware encoder có vai trò gì trong kiến trúc private ingest cho sports OTT?

Hardware encoder chuyển đổi tín hiệu broadcast HDMI hoặc SDI sang IP stream như RTMP hoặc RTP để ingest lên cloud OTT platform.