Cách Netflix phát trực tiếp tới 100 triệu thiết bị trong 60 giây
How Netflix Live Streams to 100 Million Devices in 60 Seconds
Netflix thành công trong việc stream nội dung đến 100 triệu thiết bị chỉ trong vòng một phút, minh chứng cho những thách thức và giải pháp trong việc phân phối nội dung thời gian thực ở quy mô khổng lồ. Khả năng này đóng vai trò then chốt cho hoạt động toàn cầu của họ, đòi hỏi sự ổn định cao và độ trễ thấp. Các developer có thể học hỏi từ cách Netflix xây dựng hệ thống phân tán (distributed systems), tối ưu hóa mạng lưới (network optimization) và sử dụng mạng phân phối nội dung (CDNs) để xây dựng các ứng dụng có tính sẵn sàng cao (high availability) và hiệu suất mạnh mẽ cho lượng lớn người dùng.
Trong bài viết này, chúng ta sẽ xem xét kiến trúc của hệ thống này và những thách thức mà Netflix phải đối mặt khi xây dựng nó.
Hầu hết các nhóm chọn nhà cung cấp tìm kiếm bằng cách chạy một vài truy vấn thử nghiệm và hy vọng mọi thứ sẽ ổn – đây là công thức dẫn đến ảo giác và lỗi không thể đoán trước. Hướng dẫn kỹ thuật này từ You.com cung cấp cho bạn quyền truy cập vào một framework chính xác để đánh giá tìm kiếm và truy xuất AI.
Bạn sẽ nhận được gì:
Một framework bốn giai đoạn để đánh giá tìm kiếm AI
Cách xây dựng một bộ truy vấn vàng dự đoán hiệu suất thực tế
Các chỉ số và mã để đo lường độ chính xác
Chuyển từ “trông có vẻ ổn” sang chất lượng đã được chứng minh.
Netflix Live Origin là một máy chủ được xây dựng tùy chỉnh, nằm giữa các pipeline phát trực tiếp trên đám mây và Open Connect, Mạng phân phối nội dung (CDN) của Netflix. Nó hoạt động như một điểm kiểm soát chất lượng quyết định phân đoạn video nào sẽ được phân phối đến hàng triệu người xem trên toàn thế giới.
Khi Netflix lần đầu tiên giới thiệu phát trực tiếp, họ cần một hệ thống có thể xử lý những thách thức độc đáo của việc phân phối video thời gian thực. Không giống như Video theo yêu cầu (VOD), nơi nội dung được chuẩn bị trước, phát trực tiếp hoạt động dưới áp lực thời gian. Mọi phân đoạn video phải được mã hóa, đóng gói và phân phối đến người xem trong vòng vài giây. Live Origin được thiết kế đặc biệt để đáp ứng những yêu cầu này.
Trong bài viết này, chúng ta sẽ xem xét kiến trúc của hệ thống này và những thách thức mà Netflix đã đối mặt khi xây dựng nó.
Tuyên bố miễn trừ trách nhiệm: Bài viết này dựa trên các chi tiết được chia sẻ công khai từ Đội ngũ Kỹ thuật Netflix. Vui lòng bình luận nếu bạn nhận thấy bất kỳ điểm không chính xác nào.
Hệ thống Hoạt động như thế nào
Live Origin hoạt động như một dịch vụ microservice đa người dùng trên các instance Amazon EC2. Mô hình giao tiếp khá đơn giản:
Packager, bộ phận chuẩn bị các phân đoạn video để phân phối, gửi các phân đoạn này đến Origin bằng yêu cầu HTTP PUT.
Các node Open Connect truy xuất các phân đoạn này bằng yêu cầu HTTP GET. URL được sử dụng cho yêu cầu PUT khớp với URL được sử dụng cho yêu cầu GET, tạo ra một mô hình lưu trữ và truy xuất đơn giản.
Xem sơ đồ bên dưới:
Netflix đã đưa ra một vài quyết định về kiến trúc định hình cách thức hoạt động của Live Origin.
Thứ nhất, họ đạt được độ tin cậy thông qua các quy trình phát trực tiếp theo khu vực dự phòng. Thay vì dựa vào một quy trình mã hóa duy nhất, Netflix chạy đồng thời hai quy trình độc lập. Mỗi quy trình hoạt động trong một khu vực đám mây khác nhau với bộ mã hóa, bộ đóng gói và nguồn cấp video riêng.
Thứ hai, Netflix áp dụng thiết kế manifest với các mẫu phân đoạn và thời lượng phân đoạn không đổi. Thay vì liên tục cập nhật tệp manifest để liệt kê các phân đoạn khả dụng, họ sử dụng một mẫu dự đoán được, trong đó mỗi phân đoạn có thời lượng cố định là 2 giây. Lựa chọn thiết kế này cho phép Origin dự đoán chính xác thời điểm các phân đoạn sẽ được xuất bản.
Nhận thức về Nhiều Quy trình và Lựa chọn Thông minh
Các luồng video trực tiếp chắc chắn sẽ chứa lỗi do tính chất khó đoán của nguồn cấp video trực tiếp và các thời hạn xuất bản thời gian thực nghiêm ngặt. Các vấn đề phổ biến bao gồm các phân đoạn ngắn với các khung hình video bị thiếu hoặc mẫu âm thanh, các phân đoạn hoàn toàn bị thiếu và sự gián đoạn về thời gian khi dấu thời gian giải mã không chính xác.
Chạy hai quy trình độc lập giúp giảm đáng kể khả năng cả hai quy trình cùng tạo ra các phân đoạn bị lỗi. Bởi vì các quy trình sử dụng các khu vực đám mây, bộ mã hóa và nguồn video khác nhau, khi một quy trình tạo ra phân đoạn bị lỗi, quy trình còn lại thường tạo ra phân đoạn tốt.
Live Origin tận dụng vị trí của mình trong luồng phân phối để đưa ra các quyết định thông minh. Khi Open Connect yêu cầu một phân đoạn, Origin sẽ kiểm tra các ứng cử viên từ cả hai quy trình theo một thứ tự định trước và chọn cái hợp lệ đầu tiên. Để phát hiện lỗi, Packager thực hiện kiểm tra phương tiện nhẹ và bao gồm thông tin lỗi dưới dạng siêu dữ liệu khi xuất bản các phân đoạn cho Origin. Trong trường hợp hiếm hoi khi cả hai quy trình đều có các phân đoạn bị lỗi, thông tin này sẽ được chuyển tiếp xuống hạ nguồn để các client có thể xử lý lỗi một cách phù hợp.
Không có bot họp xâm phạm (Được tài trợ)
Bạn đã bao giờ tham dự một cuộc họp mà một bot ngẫu nhiên tham gia và đột nhiên mọi người đều bị phân tâm?
Granola hoạt động khác biệt.
Không có bot họp. Không có gì tham gia cuộc gọi của bạn.
Granola ghi âm trực tiếp từ âm thanh của thiết bị bạn (trên máy tính hoặc điện thoại của bạn). Nó hoạt động với mọi công cụ họp: Zoom, Google Meet, Microsoft team... và thậm chí cả các cuộc trò chuyện trực tiếp.
Bạn tập trung và ghi chú như bình thường.
Granola lặng lẽ ghi âm và nâng cao các phần quan trọng ở chế độ nền.
Và nếu bạn muốn cẩn thận hoặc tuân thủ hơn, bạn luôn có thể gửi một email xin phép nhanh trước - tự động thông báo việc bạn sử dụng Granola.
Hãy thử Granola trong cuộc họp tiếp theo của bạn và xem nó dễ dàng hơn bao nhiêu để bạn luôn tập trung.
Nhận một tháng miễn phí cho bất kỳ gói trả phí nào bằng cách sử dụng mã BYTEBYTEGO
Tối ưu hóa cho Open Connect
Khi dự án Live bắt đầu, Open Connect được tối ưu hóa cao cho việc phân phối VOD. Netflix đã dành nhiều năm để điều chỉnh nginx (một máy chủ web) và hệ điều hành cơ bản cho trường hợp sử dụng này. Không giống như các CDN truyền thống điền vào bộ nhớ đệm theo yêu cầu, Open Connect đặt trước các tài sản VOD trên các máy chủ được lựa chọn cẩn thận gọi là Open Connect Appliances (OCA).
Phát trực tiếp không hoàn toàn phù hợp với mô hình này, vì vậy Netflix đã mở rộng chức năng bộ nhớ đệm proxy của nginx. Họ đã thực hiện một số tối ưu hóa để giảm lưu lượng truy cập không cần thiết và cải thiện hiệu suất.
Các node Open Connect nhận các mẫu phân đoạn giống như được cung cấp cho các client. Sử dụng thông tin mẫu, OCA có thể xác định phạm vi phân đoạn hợp pháp cho bất kỳ sự kiện nào tại bất kỳ thời điểm nào. Điều này cho phép chúng từ chối ngay lập tức các yêu cầu cho các phân đoạn nằm ngoài phạm vi này, ngăn chặn các yêu cầu không cần thiết đi qua mạng đến Origin.
Khi một phân đoạn chưa có sẵn và Origin nhận được yêu cầu cho nó, Origin sẽ trả về mã trạng thái 404 (Không tìm thấy tệp) cùng với chính sách hết hạn. Open Connect có thể lưu trữ phản hồi 404 này cho đến ngay trước khi phân đoạn dự kiến sẽ được xuất bản. Điều này ngăn chặn các yêu cầu thất bại lặp đi lặp lại.
Netflix đã triển khai một tối ưu hóa thông minh cho các yêu cầu ở rìa luồng trực tiếp (live edge), là phần mới nhất của luồng. Khi một yêu cầu đến cho phân đoạn tiếp theo sắp được xuất bản, thay vì trả về một 404 khác sẽ lan truyền ngược qua mạng đến client, Origin sẽ giữ yêu cầu đó mở. Một khi phân đoạn được xuất bản, Origin sẽ ngay lập tức phản hồi yêu cầu đang chờ xử lý. Điều này làm giảm đáng kể lưu lượng mạng cho các yêu cầu đến sớm một chút.
Để hỗ trợ chức năng này, Netflix đã thêm bộ nhớ đệm theo mili giây vào nginx. Kiểm soát bộ nhớ đệm HTTP tiêu chuẩn chỉ hoạt động ở độ chi tiết giây, quá thô khi các phân đoạn được tạo mỗi 2 giây.
Truyền siêu dữ liệu qua HTTP Headers
Netflix sử dụng các tiêu đề HTTP tùy chỉnh để giao tiếp các sự kiện truyền phát theo cách có khả năng mở rộng cao. Đường ống truyền phát trực tiếp cung cấp thông báo cho Origin, nơi chèn chúng dưới dạng tiêu đề HTTP vào các phân đoạn được tạo tại thời điểm đó. Các tiêu đề này là tích lũy, nghĩa là chúng duy trì cho các phân đoạn tiếp theo.
Bất cứ khi nào một phân đoạn đến OCA, thông tin thông báo sẽ được trích xuất từ tiêu đề phản hồi và lưu trữ trong bộ nhớ bằng ID sự kiện làm khóa. Khi OCA phục vụ một phân đoạn cho máy khách, nó sẽ đính kèm dữ liệu thông báo mới nhất vào phản hồi. Hệ thống này đảm bảo rằng, bất kể người xem đang ở đâu trong luồng, họ đều nhận được dữ liệu thông báo mới nhất. Các thông báo thậm chí có thể được truyền trên các phản hồi không cung cấp phân đoạn mới.
Cách tiếp cận này cho phép Netflix giao tiếp thông tin như tạm dừng quảng cáo, cảnh báo nội dung hoặc cập nhật sự kiện trực tiếp tới hàng triệu thiết bị một cách hiệu quả và độc lập với vị trí phát lại của chúng.
Vô hiệu hóa Cache và Che giấu Origin
Netflix đã xây dựng một hệ thống vô hiệu hóa có thể xóa tất cả nội dung liên quan đến một sự kiện bằng cách thay đổi số phiên bản được sử dụng trong các khóa cache. Điều này đặc biệt hữu ích trong quá trình thử nghiệm trước sự kiện, cho phép mạng quay trở lại trạng thái ban đầu giữa các lần thử nghiệm.
Mỗi phân đoạn được xuất bản bởi Live Origin bao gồm siêu dữ liệu về đường ống mã hóa nào đã tạo ra nó và nó đến từ vùng nào. Hệ thống vô hiệu hóa nâng cao tính đến các biến thể này. Netflix có thể vô hiệu hóa một phạm vi số phân đoạn cụ thể, nhưng chỉ khi chúng đến từ một bộ mã hóa cụ thể hoặc từ một bộ mã hóa cụ thể trong một khu vực cụ thể.
Kết hợp với khả năng vô hiệu hóa cache này, Live Origin hỗ trợ che giấu đường ống mã hóa có chọn lọc. Tính năng này cho phép các nhóm vận hành loại trừ các phân đoạn có vấn đề khỏi một đường ống cụ thể khi phục vụ cho Open Connect. Khi các phân đoạn xấu được phát hiện trong một sự kiện trực tiếp, hệ thống này bảo vệ hàng triệu người xem bằng cách ẩn nội dung có vấn đề, đặc biệt quan trọng trong cửa sổ phát lại DVR khi người xem có thể tua lại phần đó của luồng.
Sự tiến hóa của Kiến trúc Lưu trữ
Netflix ban đầu sử dụng AWS S3 để lưu trữ Live Origin, tương tự như cơ sở hạ tầng VOD của họ. Điều này hoạt động tốt cho các sự kiện có lưu lượng truy cập thấp, nhưng khi họ mở rộng, họ nhận thấy rằng truyền phát trực tiếp có các yêu cầu riêng biệt và khác biệt đáng kể so với nội dung theo yêu cầu.
Mặc dù S3 đáp ứng các đảm bảo thời gian hoạt động đã nêu của nó, nhưng ngân sách thử lại nghiêm ngặt 2 giây vốn có của các sự kiện trực tiếp có nghĩa là bất kỳ sự chậm trễ nào cũng trở thành vấn đề. Trong truyền phát trực tiếp, mọi thao tác ghi đều rất quan trọng và nhạy cảm về thời gian. Các yêu cầu gần giống với cơ sở dữ liệu toàn cầu, có độ trễ thấp và tính khả dụng cao hơn là lưu trữ đối tượng.
Netflix đã thiết lập năm yêu cầu chính cho hệ thống lưu trữ mới.
Đầu tiên, họ cần tính khả dụng ghi cực kỳ cao trong một khu vực AWS duy nhất với khả năng sao chép có độ trễ thấp sang các khu vực khác. Bất kỳ thao tác ghi bị lỗi nào trong vòng 500 mili giây đều được coi là lỗi.
Thứ hai, hệ thống cần xử lý thông lượng ghi cao với hàng trăm megabyte sao chép trên các khu vực.
Thứ ba, nó phải hỗ trợ hiệu quả các thao tác ghi lớn tích lũy tới hàng nghìn khóa cho mỗi phân vùng.
Thứ tư, họ cần tính nhất quán mạnh mẽ trong cùng một khu vực để đạt được độ trễ đọc dưới một giây.
Thứ năm, trong các tình huống xấu nhất liên quan đến các trường hợp biên của Open Connect, hệ thống có thể cần xử lý gigabyte thông lượng đọc mà không ảnh hưởng đến các thao tác ghi.
Netflix trước đây đã xây dựng một Trừu tượng Lưu trữ Khóa-Giá trị (Key-Value Storage Abstraction) sử dụng Apache Cassandra để cung cấp lưu trữ theo phân đoạn cho các giá trị lớn. Trừu tượng này ban đầu được xây dựng để hỗ trợ lưu trò chơi trên đám mây, nhưng trường hợp sử dụng Live sẽ đẩy giới hạn của nó về tính khả dụng ghi, kích thước phân vùng tích lũy và thông lượng đọc.
Giải pháp chia các tải trọng lớn thành các phân đoạn có thể được thử lại độc lập. Kết hợp với mô hình nhất quán local-quorum của Apache Cassandra, cho phép tính khả dụng ghi ngay cả khi một Vùng khả dụng bị lỗi, và một công cụ lưu trữ Cây hợp nhất dạng nhật ký (Log-Structured Merge Tree) được tối ưu hóa cho việc ghi, Netflix có thể đáp ứng bốn yêu cầu đầu tiên.
Hiệu suất đã được cải thiện đáng kể. Độ trễ trung vị giảm từ 113 mili giây xuống còn 25 mili giây, và độ trễ phân vị thứ 99 cải thiện từ 267 mili giây xuống còn 129 mili giây. Giải pháp mới này tốn kém hơn, nhưng việc giảm thiểu chi phí không phải là mục tiêu chính.
Tuy nhiên, việc xử lý trường hợp lỗi của Origin Storm đòi hỏi thêm công sức. Trong kịch bản này, hàng chục bộ nhớ đệm hàng đầu của Open Connect có thể đồng thời yêu cầu nhiều phân đoạn video lớn. Các tính toán cho thấy thông lượng đọc trong trường hợp xấu nhất có thể đạt 100 gigabit mỗi giây trở lên.
Netflix có thể phản hồi các yêu cầu đọc với tốc độ đường truyền mạng từ Apache Cassandra, nhưng quan sát thấy hiệu suất ghi đồng thời bị suy giảm không thể chấp nhận được. Để giải quyết vấn đề này, họ đã giới thiệu bộ nhớ đệm ghi trực tiếp (write-through caching) bằng EVCache, hệ thống bộ nhớ đệm phân tán của họ dựa trên Memcached. Điều này cho phép hầu hết các yêu cầu đọc được phục vụ từ một bộ nhớ đệm có khả năng mở rộng cao, cho phép thông lượng 200 gigabit mỗi giây trở lên mà không ảnh hưởng đến đường dẫn ghi.
Trong kiến trúc cuối cùng, Live Origin ghi và đọc từ KeyValue, hệ thống quản lý bộ nhớ đệm ghi trực tiếp sang EVCache và triển khai một giao thức phân đoạn trải rộng các giá trị lớn trên cụm lưu trữ Apache Cassandra. Hầu hết tải đọc được xử lý từ bộ nhớ đệm, chỉ những trường hợp bỏ lỡ bộ nhớ đệm mới ghi vào lớp lưu trữ. Sự kết hợp này đã đáp ứng thành công các nhu cầu khắt khe của Live Origin trong hơn một năm.
Khả năng mở rộng và Ưu tiên yêu cầu
Nền tảng phát trực tiếp của Netflix xử lý một lượng lớn các bản truyền phát đa dạng cho mỗi sự kiện trực tiếp. Sự phức tạp này đến từ việc hỗ trợ nhiều định dạng mã hóa video với nhiều cấp độ chất lượng khác nhau, nhiều tùy chọn âm thanh trên các ngôn ngữ và định dạng, và các phiên bản nội dung khác nhau như luồng có hoặc không có quảng cáo. Trong sự kiện chiến đấu giữa Tyson và Paul năm 2024, Netflix đã chứng kiến kỷ lục cao nhất với 65 triệu lượt stream đồng thời.
Netflix đã chọn xây dựng một hệ thống origin có khả năng mở rộng cao thay vì dựa vào các origin shield truyền thống để kiểm soát tính nhất quán của bộ đệm tốt hơn và kiến trúc hệ thống đơn giản hơn. Live Origin kết nối trực tiếp với các nút Open Connect hàng đầu được phân phối về mặt địa lý trên nhiều địa điểm. Để giảm thiểu tải cho origin, chỉ các nút được chỉ định cho mỗi bản truyền phát tại mỗi địa điểm mới có thể lấy trực tiếp từ origin.
Xem sơ đồ bên dưới:
Tác giả: ByteByteGo