Từ 13% lỗi trong dịp Black Friday giảm xuống không có sự cố nào xảy ra với hệ thống: Chúng tôi đã tiết kiệm được 60% chi phí máy chủ nhờ vào việc triển khai dựa trên công nghệ containerization.

Năm ngoái, giao diện phân tích địa chỉ của chúng tôi đã trực tiếp nổ tung - 13% yêu cầu báo cáo 429, hậu trường dịch vụ khách hàng nhận được hơn 300 khiếu nại từ các thương gia, 3 hậu trường liên kết trục quay 24 giờ mới mang giá trị cao nhất qua. Vào thời điểm đó, dịch vụ của chúng tôi vẫn chạy trên hai máy chủ đám mây với cấu hình cố định, khả năng mở rộng hoàn toàn dựa vào việc thay đổi cấu hình thủ công, chờ đợi các thực例 mới lên cao điểm lưu lượng đều đã qua.

Trước tiên, hãy giải thích cho bạn rõ ràng xem container hóa triển khai (containerized deployment) là gì.

Nói một cách đơn giản, đó là việc gói toàn bộ mã nguồn, thư viện phụ thuộc và tệp cấu hình của bạn thành một “container” tiêu chuẩn có kích thước từ vài MB đến vài trăm MB, sao cho môi trường chạy ứng dụng luôn nhất quán 100% dù được thực hiện trên máy chủ nào. Kích thước của hình ảnh dịch vụ giải quyết địa chỉ mà chúng tôi đã gói ban đầu là...187MBViệc kéo và khởi động toàn bộ quá trình không quá 10 giây.

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

• Tự động mở rộng và thu hẹp quy mô thực sự rất hữu ích: Trong dịp Black Friday năm nay, lưu lượng truy cập tăng gấp 3 lần, hệ thống tự động khởi động 27 instance container, và sau khi đạt đỉnh thì tự động giảm xuống còn 3 instance. Quá trình này diễn ra hoàn toàn mà không cần can thiệp thủ công, và tỷ lệ lỗi giảm xuống dưới 0,1%.
• Lỗi do sự không nhất quán về môi trường đã được khắc phục hoàn toàn: Những vấn đề “huyền bí” trước đây hoạt động bình thường trên máy cục bộ nhưng lại gặp sự cố ngay khi được đưa lên hệ thống trực tuyến, chiếm tới 40% tổng số lỗi của chúng tôi, đã không còn xuất hiện nữa sau khi chúng tôi chuyển sang sử dụng các container.
• Chi phí máy chủ giảm một nửa: Trước đây, chúng tôi phải thuê 8 máy chủ cao cấp để đối phó với lượng công việc đỉnh điểm, nhưng tỷ lệ sử dụng thực tế chỉ đạt 15%. Giờ đây, chúng tôi chỉ trả tiền theo lượng sử dụng thực tế, và tổng chi phí máy chủ hàng năm đã giảm đi 60%.

Đừng chỉ nhìn vào những mặt tích cực, chúng ta đã gặp không ít rắc rối với những điểm yếu này.

Khi mới bắt đầu sử dụng container, chúng tôi để tiện lợi đã lưu toàn bộ nhật ký và các tệp tạm thời bên trong container. Kết quả là, khi một instance bị tự động hủy, toàn bộ dữ liệu nhật ký trong vòng 3 ngày bị mất hết, và việc khôi phục dữ liệu mất tận hai ngày trời. Một lần khác, do chứa quá nhiều phụ thuộc không cần thiết trong hình ảnh (image), thời gian khởi động tăng từ 10 giây lên thành 2 phút. Khi lượng lưu lượng đột ngột tăng cao, chúng tôi không kịp mở rộng dung lượng, suýt nữa lại xảy ra sự cố.

Điều dễ bị bỏ qua nhất chính là vấn đề quyền truy cập: ban đầu chúng tôi đã cho phép container sử dụng quyền root, sau đó chúng bị các chương trình khai thác mỏ lợi dụng để chiếm dụng 30% tài nguyên CPU, và mãi một tuần sau chúng tôi mới phát hiện ra điều này qua hệ thống giám sát.

Hãy suy nghị kỹ lưỡng xem bạn có thực sự nên sử dụng nó hay không.

Nếu bạn là một nhóm nhỏ gồm vài người và đang phát triển những công cụ nội bộ với lượng truy cập ổn định, chỉ có khoảng 1-2 dịch vụ, thì thực sự không cần phải mất công sức để tự xây dựng hệ thống. Cách đơn giản và tiết kiệm nhất là thuê một máy chủ để vận hành chúng.

Nhưng nếu lưu lượng truy cập dịch vụ của bạn thay đổi thất thường, bạn cần thường xuyên triển khai và cập nhật, môi trường phát triển của các thành viên trong nhóm thường xuyên xung đột với nhau, hoặc bạn đang lo lắng về việc lãng phí tài nguyên máy chủ không được sử dụng, thì việc triển khai dựa trên container chắc chắn đáng để bạn dành một tuần thời gian để thử nghiệm.

3 lời khuyên cụ thể dành cho người mới bắt đầu

• Đừng vội vàng xử lý các cluster K8S ngay từ đầu; hãy thử sử dụng Docker Compose để triển khai ứng dụng trên một máy duy nhất trước. Hãy làm rõ các quy trình liên quan đến việc đóng gói, chạy ứng dụng, và gắn kết các file nhật ký (logs). Chúng tôi cũng đã làm như vậy trong 3 tháng vừa qua, và phương pháp đó hoàn toàn đủ hiệu quả.
• Lần đầu tiên tạo ra hình ảnh (image) thì áp dụng nguyên tắc “tối giản hóa tối đa”, chỉ cài đặt những phần phụ thuộc cần thiết cho việc chạy chương trình. Sử dụng hình ảnh cơ sở Alpine có thể giúp giảm kích thước hình ảnh xuống hơn một nửa.
• Mọi dữ liệu và log được tạo ra phải được gắn vào volume lưu trữ bên ngoài container; tuyệt đối không được lưu trữ bên trong container. Điều này được ghi rõ ở phần đầu tiên của quy trình hoạt động của đội bạn.

Câu hỏi thường gặp và trả lời

Câu hỏi: Trong nhóm của chúng tôi không ai hiểu về các container, liệu chi phí học hỏi có cao không?
Trả lời: Về mặt sử dụng cơ bản, bạn chỉ cần dành 2 ngày để đọc tài liệu hướng dẫn của nhà phát triển để có thể vận hành được dịch vụ đầu tiên. Những thiết lập phức tạp hơn như cấu hình cluster có thể học sau, khi bạn thực sự cần chúng.

Câu hỏi: Việc chuyển đổi các dịch vụ hiện có sang môi trường container có phải sẽ rất phức tạp không?
Trả lời: Chúng tôi đã di chuyển toàn bộ 3 dịch vụ backend của mình trong vòng một tuần, và phần lớn thời gian được dành để sắp xếp các phụ thuộc (dependencies). Thời gian thực sự dành để viết Dockerfile chỉ chưa đầy một ngày.