Chuyển đổi kiến trúc Backend cho ứng dụng Streaming: Từ điểm lỗi đơn nhất đến Serverless trên AWS

Trong bối cảnh phát triển ứng dụng streaming quy mô lớn, việc duy trì tính sẵn sàng cao và khả năng mở rộng là thách thức lớn đối với các kỹ sư backend. Tại hội nghị InfoQ Dev Summit Munich, Daniele Frasca — kỹ sư kiến trúc đang làm việc tại ProSiebenSat.1 Media cho nền tảng streaming Joyn — đã chia sẻ câu chuyện chuyển đổi kiến trúc ấn tượng của họ. Từ một hệ thống đơn điểm lỗi (single point of failure) thường xuyên gặp sự cố, nhóm nhỏ chỉ có hai thành viên đã thành công trong việc xây dựng lại hệ thống dựa trên các dịch vụ serverless của AWS, mang lại khả năng phục hồi và hiệu suất vượt trội.

Kiến trúc Backend cho ứng dụng Streaming

Thách thức từ kiến trúc cũ

Joyn là một ứng dụng streaming phục vụ hàng triệu người dùng tại khu vực DACH (Đức, Áo, Thụy Sĩ). Ban đầu, kiến trúc backend của họ khá đơn giản: một worker tiêu thụ tin nhắn từ Kafka, xử lý và lưu vào cơ sở dữ liệu, cùng một API GraphQL phục vụ frontend. Tuy nhiên, mô hình này nhanh chóng bộc lộ các điểm yếu khi lượng người dùng tăng đột biến.

Mọi thứ bắt đầu "trên đống lửa" khi cơ sở dữ liệu đơn node (single-node) không thể chịu tải, thiếu bộ nhớ đệm (cache) và dữ liệu không nhất quán giữa các dịch vụ. Thời gian triển khai (deployment) kéo dài tới 1,5 giờ, và mọi spike lưu lượng truy cập đều có thể khiến hệ thống sụp đổ hoàn toàn. Frasca nhận định rằng vấn đề không nằm ở code (technical debt), mà ở kiến trúc không phát triển theo quy mô kinh doanh.

Đảm bảo nhất quán dữ liệu với mẫu Hub and Spoke

Một trong những vấn đề lớn nhất mà nhóm đối mặt là sự không nhất quán của dữ liệu. Các microservice khác nhau đăng ký cùng một chủ đề Kafka nhưng thực hiện các xác nhận và chuyển đổi dữ liệu khác nhau, dẫn đến việc người dùng có thể thấy video ở trang này nhưng biến mất ở trang khác.

Giải pháp được áp dụng là mẫu kiến trúc Hub and Spoke (hay còn gọi là Bus Mesh). Trong mô hình này:

• Kafka đóng vai trò là trung tâm sự kiện của công ty (Event Store).
• AWS EventBridge Pipe đóng vai trò trung gian, nhận tin nhắn từ Kafka để thực hiện xác thực, chuyển đổi và làm sạch dữ liệu.
• EventBridge đóng vai trò là "Spoke", phân phối tin nhắn đến các dịch vụ nội bộ.

Mẫu này giúp mỗi dịch vụ chỉ giao tiếp với EventBridge thông qua một giao diện duy nhất, ẩn chi tiết về các hạ tầng bên dưới như SQS hay SNS. Nó cũng giải quyết vấn đề "nguồn sự thật duy nhất" (single source of truth) bằng cách đảm bảo mọi dữ liệu đều đi qua quy trình chuẩn hóa trước khi được phân phối.

Tuy nhiên, một thách thức kỹ thuật nảy sinh: Kafka hỗ trợ tin nhắn lên tới 30-40MB (phổ biến trong streaming media), trong khi EventBridge chỉ giới hạn ở 256KB. Để giải quyết, nhóm sử dụng Claim Check Pattern:

1. EventBridge Pipe nhận tin nhắn lớn từ Kafka.
2. Lưu nội dung tin nhắn vào Amazon S3.
3. Chỉ gửi khóa (key) của S3 tới EventBridge.
4. Các dịch vụ tiêu thụ sẽ sử dụng key này để lấy dữ liệu đầy đủ từ S3 khi cần thiết.

Cách tiếp cận này tạo ra một API có khả năng mở rộng tự nhiên mà không cần xây dựng hay bảo trì một API phức tạp riêng biệt.

Tăng khả năng chịu lỗi với kiến trúc Cell-based

Sau khi giải quyết vấn đề dữ liệu, nhóm tập trung vào khả năng mở rộng và phục hồi (resiliency). Thay vì sử dụng một dịch vụ Lambda hay Fargate duy nhất để phục vụ toàn bộ lưu lượng, họ áp dụng Cell-based Architecture (Kiến trúc dựa trên ô).

Họ chia nhỏ lưu lượng dựa trên các tiêu chí như quốc gia (Đức, Áo, Thụy Sĩ), loại người dùng (trả phí/miễn phí) và nền tảng (iOS, Android, Web). Điều này giúp tăng giới hạn đồng thời của Lambda (ví dụ từ 1.000 lên 30.000 request/giây nếu có 30 ô) và quan trọng hơn là giảm bán kính ảnh hưởng (blast radius). Nếu một ô gặp sự cố, chỉ một nhóm nhỏ người dùng bị ảnh hưởng, thay vì toàn bộ hệ thống.

Đối với cơ sở dữ liệu, việc áp dụng kiến trúc này cho các dịch vụ như RDS hay Aurora rất tốn kém, nên nhóm đã tối ưu hóa bằng chiến lược Caching 3 lớp:

1. CloudFront: Cache ở biên cho các yêu cầu lặp lại.
2. In-memory Cache: Lưu trữ các khóa nóng (hotkeys) trong bộ nhớ của Lambda/Fargate.
3. Momento Cache: Một dịch vụ cache quản lý đặt trước cơ sở dữ liệu để xử lý các request bị lỡ (cache miss).

Nhờ đó, lượng truy cập trực tiếp vào cơ sở dữ liệu trong giờ cao điểm đã giảm xuống dưới 10%, cho phép sử dụng một cụm database nhỏ hơn và tiết kiệm chi phí đáng kể.

Tối ưu hóa chi phí cho kiến trúc Đa vùng (Multi-region)

Mục tiêu cuối cùng của Joyn là đạt được kiến trúc đa vùng active-active để đảm bảo tính sẵn sàng cao nhất. Tuy nhiên, chi phí là rào cản lớn. Frasca chia sẻ các chiến lược để làm cho multi-region trở nên "giá cả phải chăng" hơn:

• Chuyển từ API Gateway sang Application Load Balancer (ALB): Nhóm tiết kiệm được 90% chi phí ở quy mô lớn bằng cách chuyển sang ALB, dù phải tự xử lý CORS và nén dữ liệu trong code.
• Cân bằng giữa Fargate và Lambda: Thay vì chạy Fargate 24/7, họ chuyển đổi lưu lượng linh hoạt. Vào ban đêm (lưu lượng thấp), Lambda chịu trách nhiệm chính. Vào giờ cao điểm, Fargate được kích hoạt và Lambda đóng vai trò dự phòng cho các spike đột ngột. Điều này giúp tiết kiệm tới 60% chi phí tính toán.
• Tự động hóa: Hệ thống được thiết kế để tự phục hồi và chuyển đổi lưu lượng khi có sự cố mà không cần sự can thiệp của con người, giảm thiểu chi phí vận hành và thời gian xử lý sự cố.

Kết luận

Trong vòng một năm rưỡi, nhóm nhỏ của Joyn đã thành công trong việc chuyển đổi hoàn toàn backend từ một hệ thống mong manh sang kiến trúc serverless hiện đại trên AWS. Họ không chỉ giải quyết được các vấn đề về tính sẵn sàng và nhất quán dữ liệu mà còn giảm thiểu chi phí vận hành. Bài học lớn nhất là: đừng cố gắng làm mọi thứ một mình. Hãy ủy thác (delegate) các vấn đề hạ tầng cho các nhà cung cấp đám mây như AWS để đội ngũ kỹ thuật có thể tập trung hoàn toàn vào giá trị cốt lõi của sản phẩm.