Chúng tôi đã giải quyết được lỗi xảy ra trong sự kiện khuyến mãi lớn 429 bằng cách sử dụng cổng Kubernetes, đồng thời tiết kiệm được 30% chi phí vận hành máy chủ.

Tháng trước, trong dịp Black Friday, nhóm của chúng tôi suýt nữa thì gặp rất nhiều rắc rối:13% yêu cầu giải quyết địa chỉ người dùng bị từ chối ngay lập tức với mã lỗi 429.Sau khi kiểm tra hậu cần trong nửa ngày, họ phát hiện ra rằng các quy tắc kiểm soát lưu lượng được thiết lập riêng biệt cho từng microservice trước đó quá nghiêm ngặt. Do đó, lưu lượng truy cập vào mô-đun truy vấn logistics đã tăng gấp ba lần, và các nguồn lực còn lại không thể được sử dụng được.

Trước đây, chúng tôi luôn nghĩ rằng Kubernetes Gateway là một thành phần phức tạp chỉ được sử dụng bởi các công ty lớn, cho đến khi chúng tôi gặp phải vấn đề và buộc phải triển khai nó. Quá trình triển khai chỉ mất chưa đầy một tuần, và kết quả lại tốt hơn nhiều so với những gì chúng tôi dự đoán.

Kubernetes Gateway là gì?

Nói một cách đơn giản, đây chính là lối vào truy cập chung cho toàn bộ cụm Kubernetes của bạn; mọi yêu cầu từ bên ngoài đều được chuyển đến đây trước, sau đó mới được chuyển tiếp đến các dịch vụ backend tương ứng. Phiên bản mở nguồn mà chúng tôi sử dụng chỉ cần một máy chủ duy nhất đã có thể xử lý được 12.000 yêu cầu mỗi giây, vì vậy các nhóm nhỏ không cần phải lo lắng về các hạn chế về hiệu năng.

Ba lợi ích thực sự mà chúng tôi nhận được

Điều đầu tiên là trực quan nhất: các quy tắc giới hạn dòng cuối cùng không phải là riêng biệt cho mỗi dịch vụ. Trước đó, chúng ta phải thay đổi ngưỡng giới hạn lưu lượng của bảy hoặc tám vi dịch vụ, thay đổi một cái sẽ xảy ra vấn đề, bây giờ trực tiếp ở tầng cổng làm giới hạn lưu lượng động, tài nguyên máy chủ trống có thể tự động nghiêng cho các mô-đun lưu lượng cao, lần Giáng sinh này thúc đẩy 429 báo lỗi của chúng ta trực tiếp giảm xuống 0.

Thứ hai là việc tiết kiệm chi phí. Trước đây, để đối phó với lượng lưu lượng cao nhất, chúng tôi đã bổ sung thêm 2 máy chủ dự phòng cho mỗi trong 3 dịch vụ cốt lõi, nhưng phần lớn thời gian tỷ lệ sử dụng tài nguyên chỉ đạt 20%. Giờ đây, vì hệ thống gateway có thể tự động phân bổ tải, chúng tôi đã thu hẹp quy mô máy chủ xuống còn 6 chiếc, và tính toán thấy chi phí sử dụng dịch vụ đám mây giảm đi 30% mỗi tháng.

Điểm thứ ba là không cần phải yêu cầu bộ phận phía sau hệ thống thay đổi lại các logic chung như xử lý xuyên miền (cross-domain) và xác thực (authentication) nhiều lần. Trước đây, mỗi khi có dịch vụ mới được triển khai, bộ phận phía sau hệ thống lại phải viết lại mã xác thực JWT. Nhưng bây giờ, chỉ cần thiết lập một quy tắc tại tầng gateway là xong. Nhờ đó, chúng tôi – ba người trong bộ phận phía sau hệ thống – có thể dành thêm ít nhất nửa ngày mỗi tuần để viết mã phục vụ cho các nhu cầu kinh doanh.

Đừng chỉ nghe những lợi ích mà nói, chúng ta đã từng gặp phải 2 rắc rối lớn vì những điều này.

Hố đầu tiên là thiết lập thời gian hết mặc định cho hố quá. Ngày đầu tiên chúng tôi phát hiện ra có 5% yêu cầu phân tích địa chỉ vượt thời gian, kiểm tra nửa ngày mới phát hiện ra thời gian vượt thời gian mặc định của cổng là 30s, nhưng bản thân dịch vụ phân tích địa chỉ của chúng tôi dài nhất sẽ chạy 40s, thay đổi quy tắc ngay lập tức sẽ khôi phục, trước khi trực tuyến nhất định phải kiểm tra ngưỡng vượt thời gian đối với giao diện kinh doanh của mình từng cái.

Lỗi thứ hai là đừng cố gắng tích hợp tất cả các tính năng ngay từ đầu. Ban đầu, chúng tôi muốn bật tất cả các tính năng như ghi nhật ký, giới hạn lưu lượng, WAF, và phát hành dần dần (gray release) cùng lúc, nhưng do lỗi trong cấu hình, toàn bộ hệ thống bị ngắt hoạt động trong 20 phút. Sau đó, chúng tôi chỉ bật các tính năng định tuyến và giới hạn lưu lượng trước, vận hành chúng trong 3 ngày để đảm bảo ổn định trước khi từ từ thêm các tính năng khác, và kể từ đó không còn gặp vấn đề gì nữa.

Liệu có nên sử dụng nó không? Tiêu chí đánh giá mà chúng tôi đưa ra rất đơn giản.

Trường hợp thích hợp:

• Số lượng microservice của bạn đã vượt quá 5, và mỗi lần bạn thay đổi cấu hình chung, bạn cần phải điều chỉnh nhiều nơi khác nhau.
• Thường xuyên gặp phải các đỉnh điểm lưu lượng truy cập, và không thể sắp xếp nguồn lực một cách linh hoạt giữa các dịch vụ khác nhau.
• Đội ngũ phát triển phía sau (back-end) chỉ có ít hơn 5 người, và chúng tôi không muốn lãng phí thời gian vào việc viết lại các logic chung một cách lặp đi lặp lại.

Trường hợp không nên can thiệp:

• Bạn chỉ có 2 microservice, lưu lượng truy cập luôn ổn định, và hiện tại việc sử dụng NGINX để chuyển tiếp lưu lượng không gặp bất kỳ vấn đề gì.
• Không ai trong cả nhóm hiểu rõ về kiến thức cơ bản của Kubernetes; đừng cố gắng theo đuổi những công nghệ mới một cách mù quáng.

Đây là 2 lời khuyên thực sự hữu ích dành cho những nhóm nhỏ mới bắt đầu làm việc:

Không cần phải mất thời gian suy nghĩ nhiều về việc lựa chọn công cụ; những nhóm nhỏ có thể sử dụng trực tiếp các công cụ mở nguồn như APISIX hoặc Kong. Các tài liệu hướng dẫn đi kèm rất đầy đủ, và khi gặp vấn đề, bạn chỉ cần tìm kiếm trên mạng là thường sẽ tìm thấy giải pháp. Không cần phải mua phiên bản thương mại; phiên bản miễn phí đã có đủ chức năng cần thiết.

Trước khi triển khai, hãy chuyển 10% lưu lượng truy cập để thử nghiệm trong vòng 24 giờ, tập trung quan sát xem có tình trạng quá thời gian hoặc yêu cầu bị chặn nhầm không. Nếu không có vấn đề gì, sau đó mới chuyển toàn bộ lưu lượng truy cập. Đừng vội vàng chuyển hết lưu lượng ngay từ đầu.

Cuối cùng, xin trả lời một câu hỏi mà mọi người thường đặt: Trước đây, không ai trong chúng tôi từng nghiên cứu về gateway cụ thể cho 3 hệ thống backend này. Chúng tôi chỉ mất 2 ngày để xây dựng nó dựa trên tài liệu chính thức, và nó thực sự không phức tạp như bạn nghĩ đâu.