Chúng tôi đã tiết kiệm được 38% chi phí xử lý lưu lượng nhờ sử dụng cổng thông tin dựa trên nền tảng đám mây, nhưng suýt nữa đã làm hỏng hệ thống phân phối sản phẩm tươi sống ở châu Âu trong dịp Black Friday.

Cuộc họp tổng kết chiến dịch giảm giá lớn vào thứ Sáu đen tuần trước vừa mới kết thúc, và đội ngũ phát triển hệ thống phân phối thực phẩm tươi châu Âu gồm 3 người của chúng tôi vẫn còn cảm thấy lo lắng: vào ngày bán hàng trước, 17% yêu cầu dịch vụ lưu trữ thực phẩm trong điều kiện lạnh đã bị từ chối ngay lập tức (kết quả là 429 trường hợp), số lượng khiếu nại từ người dùng tăng gấp ba lần, suýt nữa làm hỏng toàn bộ kế hoạch chiến dịch giảm giá hàng năm mà chúng tôi đã chuẩn bị trong ba tháng.

Vấn đề nằm ở việc chúng tôi đã sử dụng một gateway API truyền thống trong suốt hai năm: Chúng tôi đã đặt một ngưỡng giới hạn lưu lượng chung cho hai giao diện cốt lõi là giải pháp địa chỉ và đặt lịch chuỗi lạnh. Vào ngày Black Friday, lượng yêu cầu giải pháp địa chỉ tăng vọt, chiếm hết ngưỡng giới hạn của gateway, khiến các yêu cầu đặt lịch sau đó không thể được xử lý. Trước đây, tôi luôn nghĩ rằng việc thay đổi gateway chỉ cần thiết cho các nhóm lớn, nhưng sau khi gặp sự cố này, tôi mới nhận ra rằng gateway dạng cloud-native có thể là lựa chọn có giá trị hơn về mặt tỷ lệ giá cả so với hiệu quả đối với các nhóm nhỏ.

Cloud-native gateway là gì?

Nói một cách đơn giản: Đây là điểm vào lưu lượng hoạt động trong cụm K8s, bạn không cần phải thuê máy chủ riêng để triển khai nó.Bạn chỉ cần quan tâm đến các quy tắc định tuyến và chiến lược giới hạn lưu lượng (throttling strategies), còn những vấn đề liên quan đến tính linh hoạt của nguồn lực và nâng cấp vận hành bảo trì (operations and maintenance upgrades) đều do nhà cung cấp dịch vụ đám mây (cloud provider) xử lý.Chúng ta đang sử dụng phiên bản hiện tại, trong đó mỗi instance có thể xử lý tới 20.000 yêu cầu mỗi giây, và không cần phải lập kế hoạch dung lượng trước.

Sau khi thực hiện, chúng ta nhận được ba khoản lợi nhuận thực tế.

Sau sự cố xảy ra vào ngày bán hàng trước, chúng tôi đã mất 3 ngày để chuyển sang sử dụng gateway dựa trên nền tảng cloud-native. Trong ngày diễn ra sự kiện Black Friday, không còn xảy ra bất kỳ trường hợp nào liên quan đến việc giới hạn lưu lượng dữ liệu (throttling) gây ra những lỗi không mong muốn nữa. Ngoài ra, còn có ba lợi ích nữa vượt qua kỳ vọng của chúng tôi:

• Chi phí giảm trực tiếp: trước đây chúng tôi thuê hai máy chủ 4 lõi 8G để chạy cổng truyền thống, cộng thêm một người vận hành và bảo trì dành 8 giờ mỗi tháng để nâng cấp phiên bản, tính ra chi phí hàng tháng là 1200 euro, bây giờ cổng đám mây tự nhiên trả tiền theo số lượng cuộc gọi, mỗi tháng chỉ chi phí 740 euro,Tiết kiệm trực tiếp 38% chi phí xử lý lưu lượng dữ liệu
• Chiến lược giới hạn lưu lượng cuối cùng cũng được hiểu rõ rồi: Trước đây, các gateway chỉ có thể thiết lập ngưỡng giới hạn lưu lượng cho toàn bộ các giao diện, nhưng bây giờ chúng ta có thể thiết lập quy tắc riêng biệt cho từng scénario kinh doanh – ví dụ, giao diện giải quyết địa chỉ chỉ được phép chấp nhận tối đa 5000 yêu cầu mỗi giây. Ngay cả khi nó bị tấn công dồn dập, điều đó cũng không ảnh hưởng đến các quá trình thanh toán hay đặt lịch tiếp theo.
• Thời gian thực hiện giao thức handshake HTTPS đã giảm đi một nửa: Trước đây, chứng chỉ SSL của chúng tôi được lưu trữ trên máy chủ gateway riêng, dẫn đến độ trễ trong quá trình handshake lên đến 200ms đối với người dùng ở các khu vực khác nhau ở Châu Âu. Giờ đây, nhà cung cấp dịch vụ đám mây đã lưu trữ chứng chỉ trên các node edge, giúp giảm độ trễ trong quá trình handshake xuống dưới 80ms đối với hầu hết các yêu cầu.

Đừng vội lên xe, chúng ta đã từng gặp phải hai trường hợp tương tự như vậy rồi.

Không phải tất cả các giải pháp cổng dựa trên nền tảng đám mây (cloud-native gateways) đều có những ưu điểm; trong quá trình chuyển đổi sang nền tảng này, chúng tôi cũng gặp phải hai vấn đề nhỏ khiến chúng tôi suýt phải làm lại công việc:

Đầu tiên là vấn đề về sự chậm trễ khởi động lạnh. Vừa mới cắt xong ngày đầu tiên chúng tôi làm kiểm tra áp lực, phát hiện liên tục 10 phút không yêu cầu sau, sóng yêu cầu đầu tiên thời gian phản hồi đột nhiên tăng lên 300ms trên, sau đó mới biết các nhà sản xuất đám mây thực thể đàn hồi được khởi động theo yêu cầu, cần thiết để giao diện cốt lõi đặt thực thể tối thiểu dự phòng, nếu không thời gian rảnh rỗi đột nhiên đến lưu lượng rất dễ vượt thời gian.

Thứ hai là các hạn chế của các plugin tùy chỉnh. Trước đây, chúng tôi đã tự viết một plugin để xác thực chữ ký yêu cầu và chạy nó trên gateway truyền thống. Khi chuyển sang sử dụng gateway dạng cloud-native, chúng tôi mới phát hiện ra rằng gateway này chỉ hỗ trợ các plugin dạng WebAssembly. Chúng tôi đã mất hai ngày để sửa đổi mã nguồn để thích ứng. Nếu bạn có nhiều logic tùy chỉnh, tốt nhất là nên xem xét kỹ xem nhà cung cấp hỗ trợ những plugin nào trước khi triển khai.

Liệu có nên thay đổi không? Hãy xem hai tiêu chí đánh giá này trước đã.

Trường hợp bạn nên thay đổi:

• Đội ngũ phát triển có ít hơn 5 nhân viên lập trình phía sau nền tảng, và không có nhân viên chuyên trách vận hành hệ thống (OPS). Chúng tôi không muốn dành thời gian cho việc bảo trì hoặc nâng cấp các máy chủ gateway.
• Lưu lượng truy cập thay đổi lớn, ví dụ như trong các chương trình khuyến mãi lớn, lưu lượng có thể tăng từ 3 đến 10 lần so với bình thường. Chúng tôi không muốn trước đó phải thuê một số lượng lớn máy chủ để sử dụng trong thời gian không cần thiết, gây lãng phí tiền.

Trường hợp bạn không nên thay đổi:

• Yêu cầu về tuân thủ quy định rất nghiêm ngặt; toàn bộ lưu lượng truy cập phải đi qua các máy chủ mà bạn có thể kiểm soát trực tiếp, không được sử dụng các nút công cộng của các nhà cung cấp dịch vụ đám mây.
• Cổng gateway của bạn chứa rất nhiều logic tùy chỉnh đặc biệt mà các cổng gateway dạng cloud-native trên thị trường không hỗ trợ. Việc tự mình điều chỉnh chúng sẽ tốn kém hơn cả chi phí bảo trì cổng gateway đó.

Ba lời khuyên nhỏ dành cho người mới bắt đầu

• Không cần chuyển toàn bộ lưu lượng, hãy chuyển 10% lưu lượng đầu tiên sang gateway dựa trên nền tảng cloud-native trong một tuần để theo dõi xem có vấn đề gì không. Nếu không có vấn đề gì, sau đó mới từ từ chuyển toàn bộ lưu lượng. Ban đầu chúng tôi đã chuyển giao chỉ giao diện giải quyết địa chỉ trước, và chỉ khi chắc chắn không có vấn đề thì mới chuyển toàn bộ lưu lượng.
• Các giao diện trung tâm (core interfaces) nhất định phải được thiết lập với số lượng instance tối thiểu; đừng tiết kiệm tiền ở điểm đó. Hiện tại, chúng tôi đã dành riêng 2 instance thường trú cho mỗi giao diện là dịch vụ đặt hàng trong chuỗi lạnh (cold chain booking) và giao dịch thanh toán (payment), và từ đó không còn gặp phải vấn đề về thời gian khởi động chậm (cold start timeout) nữa.
• Bạn không cần phải mua phiên bản cao cấp nhất; đối với hầu hết các doanh nghiệp vừa và nhỏ, các tính năng của phiên bản cơ bản đã đủ sử dụng. Phiên bản cơ bản mà chúng tôi đang sử dụng hiện tại có thể xử lý lên đến 20.000 yêu cầu mỗi giây (QPS) mà không cần bổ sung chi phí.

Trả lời cho câu hỏi thường được đặt ra nhất bởi đội ngũ nội bộ: Liệu sản phẩm này có bị ràng buộc bởi các nhà cung cấp dịch vụ đám mây không?

Dự đoán của chúng tôi là: đối với một nhóm phát triển phần sau (backend) có ít hơn 10 người,Lợi ích về hiệu suất mà việc được các nhà cung cấp dịch vụ đám mây kết nối mang lại lớn hơn nhiều so với chi phí phải tự xây dựng tất cả các thành phần từ đầu.Đến khi thực sự cần phải thay đổi nhà cung cấp dịch vụ đám mây, bạn sẽ có đủ năng lực để thực hiện việc chuyển đổi. Đừng bận tâm về điều này lúc này.