Để phát trực tiếp ổn định cho hàng chục triệu người, đội kỹ thuật cần chuẩn bị dư công suất và bảo vệ đường dẫn phân phối video. Họ cũng phải kiểm thử toàn bộ hành trình người dùng và đặt ngân sách độ trễ cho từng yêu cầu. JioHotstar đã áp dụng các nguyên tắc này khi phục vụ 32 triệu người xem đồng thời trong trận chung kết Indian Premier League năm 2023.
Trong một trận đấu được phát trực tiếp, chênh lệch vài giây cũng đủ phá hỏng trải nghiệm. Người xem sẽ không hài lòng nếu nghe hàng xóm reo mừng hoặc thất vọng trước khi tình huống tương ứng xuất hiện trên màn hình của mình.
Năm 2023, Ashutosh Agrawal cùng đội ngũ kỹ thuật JioHotstar, khi đó còn mang tên JioCinema, chuẩn bị cho trận chung kết giải cricket Indian Premier League. Theo bài viết của The New Stack, trận đấu đạt mức kỷ lục vào thời điểm đó với 32 triệu người xem đồng thời. Quá trình chuẩn bị cho thấy cách thiết kế hệ thống khi lưu lượng thực tế khó dự đoán.
Chuẩn bị cho mức tải cao hơn dự báo
JioHotstar kiểm thử hệ thống ở mức gần gấp đôi công suất dự kiến. Đội ngũ cũng ưu tiên tuyệt đối đường dẫn phân phối video. Với trận chung kết năm 2023, họ chuẩn bị cho khoảng 50 đến 75 triệu người xem, dù lưu lượng thực tế đạt 32 triệu.
Ashutosh đã làm việc với nền tảng phát trực tiếp phía máy chủ từ năm 2018. Theo kinh nghiệm của ông, diễn biến của cricket không thể được dự đoán chắc chắn. Vì vậy, hạ tầng không thể chỉ được thiết kế theo một kịch bản lưu lượng cố định.
Theo The New Stack, phần công suất dự phòng giúp hệ thống hấp thụ các đợt tăng lưu lượng mà không để yêu cầu dồn thành hàng chờ. Các thành phần khác có thể bị cắt giảm khi cần, nhưng mọi bộ phận trên đường đưa video đến người xem phải tiếp tục hoạt động. Nếu đường dẫn này hỏng, nền tảng không thể cung cấp chức năng cốt lõi.
Cách phân chia ưu tiên đó cũng phù hợp với nguyên tắc thiết kế hạ tầng phục vụ khối lượng tính toán lớn: xác định rõ thành phần trực tiếp duy trì trải nghiệm và thành phần có thể suy giảm tạm thời.
Nút thắt có thể xuất hiện trước khi video được phát
Nút thắt của nền tảng phát trực tiếp không nhất thiết nằm ở khâu phân phối video. Với JioHotstar, quá trình đăng nhập và xác thực bằng tin nhắn chứa mã dùng một lần có thể chịu tải cao trước khi hệ thống trả về địa chỉ phát video.
Theo lời Ashutosh được The New Stack dẫn lại, gửi lượng lớn tin nhắn trên toàn Ấn Độ trong thời gian ngắn là một bài toán riêng. Đỉnh tải của một số hệ thống xuất hiện ngay trong ngày đầu tiên, không phải ở trận chung kết. Khi đó, nhiều người dùng mới hoặc những người chưa đăng nhập trong 360 ngày cùng truy cập trong khoảng 5 đến 10 phút đầu.
Đội ngũ chủ động mở rộng các hệ thống trọng yếu như xác thực. Những đối tác cung cấp dịch vụ phải trải qua kiểm thử tải nghiêm ngặt. Nếu một đối tác không đáp ứng cam kết về độ trễ trong sự kiện, hệ thống chuyển ngay lưu lượng sang đối tác tiếp theo trong thứ tự dự phòng.
Danh sách kiểm tra gồm 200 điểm
JioHotstar sử dụng danh sách gồm 200 điểm để rà soát hệ thống, cơ sở dữ liệu, đối tác và cấu hình mạng trước trận đấu. Danh sách này kiểm tra cả phiên bản phần mềm, lịch bảo trì, thành phần phụ thuộc, phương án dự phòng và thời gian chờ giữa các lớp dịch vụ.
Theo The New Stack, phạm vi rà soát kéo dài từ thời gian chờ giữa bộ cân bằng tải với dịch vụ, giữa dịch vụ với máy chủ ứng dụng, giữa máy chủ ứng dụng với cơ sở dữ liệu, cho tới mạng phân phối nội dung.
Nhiều mục trong danh sách bắt nguồn từ sự cố thật. Ashutosh kể rằng một dịch vụ từng cấu hình sai thời gian duy trì kết nối. Khi lưu lượng đạt đỉnh, dịch vụ loại bỏ kết nối thay vì tái sử dụng chúng. Bộ cân bằng tải sau đó gặp sự cố vì không xử lý nổi số yêu cầu. Tình huống này trở thành một điểm bắt buộc phải kiểm tra ở mùa giải tiếp theo.
Mỗi lập trình viên hoặc người phụ trách dịch vụ phải chỉ ra các điểm có thể hỏng và ghi lại phương án giảm thiểu.
Thiết kế lối vào khi mọi đối tác đều gặp sự cố
Kế hoạch dự phòng cần tính đến trường hợp mọi nhà cung cấp SMS phục vụ xác thực cùng ngừng hoạt động, không chỉ trường hợp một đối tác riêng lẻ gặp lỗi. Với dịch vụ xác thực, mục tiêu là duy trì một lối vào tạm thời để người xem không bị khóa hoàn toàn ở bên ngoài.
Theo The New Stack, một phương án là cho phép xem miễn phí trong 5 hoặc 10 phút mà chưa cần xác thực. Phương án khác là cấp mã truy cập tạm thời rồi thực hiện xác thực sau. Những biện pháp này cần được đội sản phẩm và đội kỹ thuật thiết kế từ trước thay vì ứng biến khi sự kiện đang diễn ra.
Nhóm phải xem xét từng điểm hỏng, xác định hệ thống sẽ suy giảm theo cách nào và bảo đảm người xem vẫn có đường vào dịch vụ. Không có một giải pháp duy nhất phù hợp với mọi điểm hỏng.
Ba tầng kiểm thử trước sự kiện
JioHotstar kiểm thử theo ba tầng: từng dịch vụ riêng lẻ, nhiều hệ thống kết nối với nhau và toàn bộ hành vi của người dùng. Cách tiếp cận này giúp phát hiện những giới hạn công suất chỉ xuất hiện khi nhiều thành phần cùng xử lý một hành trình thực tế.
- Kiểm thử theo chiều dọc được chạy trên từng hệ thống và dịch vụ để xác nhận mỗi thành phần có thể tự mở rộng. Nhóm cũng áp dụng cách kiểm thử này cho đối tác tin nhắn, thư điện tử, quảng cáo và các bên được tích hợp vào hoặc ở gần đường dẫn trọng yếu.
- Trong kiểm thử tải nhiều hệ thống, các cụm dịch vụ được vận hành cùng nhau. Một dịch vụ có thể mở rộng tốt khi đứng riêng nhưng bộc lộ vấn đề sau khi kết nối với các thành phần phụ thuộc. Kiểm thử phát video có thể bao gồm hệ thống nội dung, phân tích dữ liệu và cân bằng tải cho mạng phân phối nội dung.
- Mô phỏng đầy đủ hành vi người dùng tái hiện cách người xem sử dụng ứng dụng di động hoặc trang web, sau đó đo ảnh hưởng lên toàn bộ hệ thống liên quan.
Ashutosh cho biết mô phỏng người dùng thực tế từng giúp đội ngũ phát hiện các vấn đề trọng yếu. Hệ thống nội dung có thể được gọi từ trang danh sách, trang chi tiết và nơi lấy dữ liệu phát video. Nếu một nhóm bỏ sót lượng yêu cầu hội tụ từ nhiều điểm, vấn đề công suất chỉ xuất hiện trong mô phỏng đầy đủ chứ không lộ ra khi kiểm thử riêng từng dịch vụ.
Đặt ngân sách độ trễ cho từng loại yêu cầu
JioHotstar đặt ngân sách phía máy chủ ở mức 10 đến 15 mili giây cho thao tác tra cứu có độ phức tạp không đổi và 40 đến 50 mili giây cho yêu cầu phức tạp hơn. Khi một thành phần trọng yếu vượt 50 mili giây, đội ngũ xem xét chuyển bớt công việc sang xử lý không đồng bộ.
Theo số liệu Ashutosh chia sẻ với The New Stack, mức 10 đến 15 mili giây áp dụng cho hệ thống hoàn toàn do nội bộ vận hành. Hệ thống này không gọi dịch vụ bên thứ ba. Ngân sách chỉ tính thời gian phía máy chủ, chưa bao gồm mạng.
Ngân sách độ trễ cho nội dung và đường dẫn phát
Ngân sách 40 đến 50 mili giây áp dụng cho trường hợp cần nhiều lần gọi cơ sở dữ liệu hoặc gọi một bên thứ ba. Sau khi cộng độ trễ từ thiết bị, mạng, đường truyền giữa mạng phân phối nội dung và máy chủ gốc cùng chặng cuối, người dùng cảm nhận mức trễ từ 60 đến 100 mili giây.
Ngân sách nghiêm ngặt nhất dành cho giao diện lập trình nằm giữa thao tác người xem chọn video và thời điểm video bắt đầu phát. Nếu bước này lỗi, người dùng có thể thử lại hoặc đóng rồi mở ứng dụng, khiến giao diện đó phải chịu thêm tải.
Phản hồi này cũng khó lưu vào bộ nhớ đệm vì mỗi yêu cầu phải cân bằng tải giữa các mạng phân phối nội dung và kiểm tra xác thực theo thời gian thực. Theo Ashutosh, ngay cả khi phải gọi bên thứ ba, thao tác đó vẫn chịu giới hạn ngắt mạch chỉ 5 hoặc 10 mili giây. Thất bại nhanh rồi phục hồi được ưu tiên hơn việc chờ một kết quả chính xác đến quá muộn.
Lưu vào bộ nhớ đệm theo từng thành phần
Không phải toàn bộ phản hồi đều có thể được lưu vào bộ nhớ đệm. JioHotstar tách bố cục khỏi nội dung cá nhân hóa, lưu riêng những phần có thể tái sử dụng rồi kết hợp chúng khi trả kết quả cho người xem.
Ngân sách phản hồi tạo cơ sở để đánh giá từng dịch vụ: phần nào có thể tối ưu, tải nào có thể chuyển khỏi hệ thống trực tiếp, dữ liệu nào có thể chuẩn bị trước và nội dung nào có thể được lưu thêm vào bộ nhớ đệm.
Đăng nhập không thể được lưu sẵn. Tuy nhiên, theo The New Stack, ngay khi người dùng tới trang chủ, đội ngũ cố gắng lưu phản hồi của nhiều phần trên trang. Cá nhân hóa làm bài toán phức tạp hơn. Vì vậy, bố cục và nội dung được lưu riêng rồi kết hợp khi trả kết quả. Cách chia nhỏ này giúp duy trì thời gian phản hồi thấp.
Ba bài học dành cho đội ngũ kỹ thuật
JioHotstar rút ra ba bài học chính. Đội ngũ cần thống nhất nguyên tắc ưu tiên trong toàn tổ chức và giảm độ trễ phía máy chủ thay vì mặc nhiên chấp nhận mức 100 mili giây. Họ cũng phải xác định và củng cố toàn bộ đường dẫn trọng yếu tới trải nghiệm người dùng.
Cách áp dụng ba bài học
- Thống nhất nguyên tắc ưu tiên trong toàn tổ chức, bao gồm lãnh đạo và đội ngũ thực thi. Sự thống nhất này định hướng quyết định trước, trong và sau sự kiện. Nếu các bên theo đuổi những nguyên tắc xung đột, quá trình ra quyết định sẽ trở thành nút thắt.
- Không nên mặc nhiên chấp nhận phản hồi phía máy chủ ở mức 100 mili giây. Ashutosh cho rằng công nghệ và năng lực tính toán đã cải thiện đáng kể, còn độ trễ phía máy chủ nằm trong phạm vi đội kỹ thuật có thể kiểm soát.
- Xác định và củng cố đường dẫn trọng yếu ở cấp độ chi tiết, không chỉ trên sơ đồ hệ thống cấp cao. Chẳng hạn, một lệnh gửi dữ liệu phân tích theo cách đồng bộ không nên nằm trên đường dẫn trực tiếp tới trải nghiệm người dùng. Điều này áp dụng khi lệnh đó không phải thành phần phụ thuộc có mức ưu tiên cao nhất. Đôi khi đội ngũ phải từ chối một yêu cầu hoặc thiết kế lại một phần kiến trúc.
Kinh nghiệm từ hệ thống phục vụ 32 triệu người xem đồng thời cho thấy khả năng mở rộng không chỉ đến từ việc bổ sung máy chủ cho hạ tầng phục vụ khối lượng tính toán lớn. Nó phụ thuộc vào ưu tiên rõ ràng, công suất dự phòng, kiểm thử sát hành vi thực tế, giới hạn độ trễ cụ thể và phương án suy giảm được thiết kế trước.
Nếu đang chuẩn bị cho một đợt lưu lượng lớn, hãy bắt đầu bằng việc vẽ lại đường dẫn trọng yếu và kiểm tra từng điểm có thể khiến người dùng không nhận được dịch vụ.
