Chạy trên ba nền tảng đám mây cùng lúc: Khi nào nên và khi nào không?

Trong thế giới tài chính, nơi mỗi giây ngừng hoạt động có thể gây thiệt hại hàng triệu đô la, việc đảm bảo hệ thống luôn sẵn sàng là bài toán sống còn. Form3 — công ty cung cấp nền tảng thanh toán dưới dạng dịch vụ — đã trải qua một hành trình chuyển đổi kiến trúc đáng chú ý, từ một nhà cung cấp đám mây duy nhất đến mô hình đa đám mây ba vùng hoạt động song song (triple active multi-cloud).

Ross McFarlane và Kevin Holditch đã chia sẻ chi tiết về quá trình này, bao gồm cả những bài học xương máu và câu hỏi quan trọng: khi nào thì kiến trúc phức tạp như vậy thực sự cần thiết?

Từ một đám mây đến ba đám mây cùng lúc

Form3 khởi đầu với hạ tầng đám mây đơn giản, đặt trọn niềm tin vào một nhà cung cấp duy nhất. Tuy nhiên, khi khách hàng là các ngân hàng và tổ chức tài chính lớn, yêu cầu về tính sẵn sàng cao và tuân thủ quy định ngày càng khắt khe. Việc phụ thuộc vào một nhà cung cấp đám mây đồng nghĩa với rủi ro tập trung — một sự cố kéo dài ở nhà cung cấp đó có thể làm tê liệt toàn bộ dịch vụ thanh toán.

Giải pháp mà Form3 lựa chọn không chỉ là đa đám mây đơn thuần, mà là ba vùng hoạt động đồng thời (active-active-active). Điều này có nghĩa là cả ba môi trường đám mây đều xử lý giao dịch theo thời gian thực, chứ không phải mô hình chính — phụ với một môi trường chỉ chờ sẵn để dự phòng.

"Chúng tôi không xây dựng hệ thống dự phòng. Chúng tôi xây dựng ba hệ thống chính, mỗi hệ thống đều có khả năng gánh vác toàn bộ tải nếu cần." — Ross McFarlane

Kết nối liên đám mây: Bài toán hạ tầng hóc búa

Một trong những thách thức kỹ thuật lớn nhất là kết nối mạng giữa các đám mây. Mỗi nhà cung cấp có cách quản lý mạng riêng, địa chỉ IP riêng và mô hình bảo mật riêng. Form3 đã phải xây dựng lớp mạng riêng ảo (overlay network) để đảm bảo lưu lượng giữa các đám mây vừa bảo mật, vừa ổn định, vừa có độ trễ thấp.

Các yếu tố then chốt bao gồm:

• Định tuyến động giữa các vùng để tự động chuyển hướng lưu lượng khi một đám mây gặp sự cố
• Mã hóa đầu cuối cho mọi kết nối liên đám mây, đáp ứng tiêu chuẩn bảo mật tài chính
• Giám sát tập trung để theo dõi sức khỏe mạng xuyên suốt cả ba môi trường
• Tự động hóa cấu hình nhằm giảm thiểu sai sót do con người khi vận hành thủ công

Đối với độc giả Việt Nam đang làm việc với hạ tầng đám mây, bài học ở đây rất rõ ràng: kết nối liên đám mây không chỉ là vấn đề kỹ thuật mà còn là vấn đề quy trình vận hành và tự động hóa. Nếu không có công cụ quản lý cấu hình nhất quán, việc vận hành đa đám mây sẽ nhanh chóng trở thành cơn ác mộng.

Cơ sở dữ liệu phân tán: CockroachDB và NATS

Để duy trì tính nhất quán dữ liệu trên ba đám mây, Form3 sử dụng CockroachDB — cơ sở dữ liệu phân tán được thiết kế cho môi trường đa vùng. CockroachDB cho phép dữ liệu được nhân bản đồng bộ giữa các đám mây, đảm bảo rằng ngay cả khi một vùng gặp sự cố, dữ liệu vẫn không bị mất và giao dịch vẫn tiếp tục.

Bên cạnh đó, NATS đóng vai trò hệ thống nhắn tin phân tán, giúp các dịch vụ giao tiếp với nhau xuyên qua ranh giới đám mây. Kiến trúc này cho phép Form3 xử lý hàng triệu giao dịch mỗi ngày mà vẫn duy trì được tính nhất quán cuối cùng (eventual consistency) và độ trễ thấp.

Điểm đáng lưu ý là việc lựa chọn công nghệ phải đi kèm với hiểu biết sâu sắc về mô hình nhất quán và hành vi khi có sự cố phân vùng mạng. Đây là những khái niệm không hề đơn giản, đòi hỏi đội ngũ kỹ thuật phải được đào tạo bài bản.

Toán tử Kubernetes tùy chỉnh: Tự động hóa vận hành

Form3 đã phát triển các toán tử Kubernetes tùy chỉnh (custom Kubernetes operators) để tự động hóa việc triển khai, mở rộng và phục hồi dịch vụ trên cả ba đám mây. Những toán tử này đóng vai trò như những "nhạc trưởng" tự động, đảm bảo rằng trạng thái mong muốn của hệ thống luôn được duy trì, bất kể đám mây nào đang gặp vấn đề.

Các toán tử này xử lý:

• Tự động chuyển đổi lưu lượng khi phát hiện sự cố ở một vùng
• Mở rộng quy mô theo nhu cầu dựa trên tải thực tế của từng đám mây
• Phục hồi dịch vụ tự động mà không cần can thiệp thủ công
• Đồng bộ hóa cấu hình giữa các môi trường đám mây khác nhau

Khi nào KHÔNG nên chạy đa đám mây?

Đây có lẽ là phần quan trọng nhất trong chia sẻ của McFarlane và Holditch. Kiến trúc đa đám mây ba vùng mang lại khả năng phục hồi vượt trội, nhưng cái giá phải trả cũng không hề nhỏ:

• Chi phí vận hành tăng vọt: Bạn phải trả tiền cho ba môi trường đám mây cùng lúc, cùng với chi phí truyền dữ liệu giữa chúng
• Độ phức tạp kỹ thuật cao: Đội ngũ cần có chuyên môn sâu về nhiều nền tảng khác nhau
• Thời gian phát triển sản phẩm kéo dài: Mọi tính năng mới đều phải được kiểm thử trên ba môi trường
• Khó khăn trong tuyển dụng: Tìm kỹ sư thành thạo cả ba đám mây là thách thức không nhỏ

Theo hai diễn giả, đa đám mây chỉ thực sự cần thiết khi:

1. Yêu cầu pháp lý bắt buộc — ví dụ, quy định yêu cầu dữ liệu phải được lưu trữ ở nhiều khu vực địa lý
2. Khách hàng yêu cầu tính sẵn sàng cực cao — như trong lĩnh vực tài chính, nơi mỗi phút ngừng hoạt động đều tốn kém
3. Rủi ro tập trung quá lớn — khi sự cố của một nhà cung cấp đám mây có thể đe dọa sự tồn tại của doanh nghiệp
4. Quy mô đủ lớn — để chi phí vận hành đa đám mây trở nên hợp lý so với lợi ích thu được

"Đa đám mây không phải là đích đến cho mọi doanh nghiệp. Đó là một quyết định kiến trúc cần được cân nhắc kỹ lưỡng dựa trên yêu cầu kinh doanh thực tế." — Kevin Holditch

Khác biệt vùng miền trong phục hồi thảm họa

Một khía cạnh thú vị mà Form3 phải đối mặt là kỳ vọng khác nhau về phục hồi thảm họa giữa các thị trường tài chính:

• Anh: Yêu cầu nghiêm ngặt về thời gian phục hồi (RTO) và điểm phục hồi (RPO), với sự giám sát chặt chẽ từ cơ quan quản lý
• Châu Âu: Tập trung vào chủ quyền dữ liệu và tuân thủ GDPR, yêu cầu dữ liệu phải được lưu trữ trong lãnh thổ EU
• Mỹ: Nhấn mạnh vào khả năng chịu tải cao và tính liên tục trong điều kiện thị trường biến động mạnh

Điều này có nghĩa là Form3 không thể áp dụng một chiến lược phục hồi thảm họa duy nhất cho tất cả các vùng. Thay vào đó, họ phải thiết kế kiến trúc linh hoạt, có khả năng tùy chỉnh theo yêu cầu cụ thể của từng thị trường.

Bài học cho các đội ngũ kỹ thuật

Câu chuyện của Form3 mang lại nhiều bài học quý giá cho các đội ngũ kỹ thuật, đặc biệt là những ai đang cân nhắc chuyển đổi sang kiến trúc đa đám mây:

• Bắt đầu từ yêu cầu kinh doanh, không phải từ công nghệ. Đa đám mây chỉ có ý nghĩa khi giải quyết được vấn đề thực tế
• Đầu tư vào tự động hóa ngay từ đầu. Vận hành thủ công trên nhiều đám mây là công thức dẫn đến thảm họa
• Xây dựng văn hóa kỹ thuật vững mạnh. Kiến trúc phức tạp đòi hỏi đội ngũ có năng lực tương xứng
• Chấp nhận rằng không có giải pháp hoàn hảo. Mỗi lựa chọn kiến trúc đều có đánh đổi, và điều quan trọng là hiểu rõ những đánh đổi đó

Đối với các doanh nghiệp Việt Nam đang trong quá trình chuyển đổi số, bài học ở đây là hãy đánh giá nhu cầu thực tế trước khi lao vào những kiến trúc phức tạp. Đa đám mây có thể là giải pháp đúng đắn cho các tổ chức tài chính lớn, nhưng với phần lớn doanh nghiệp vừa và nhỏ, một kiến trúc đơn giản hơn nhưng được vận hành tốt có thể mang lại giá trị cao hơn nhiều.