Triển khai máy chủ an toàn với canary test

• Bài chia sẻ kinh nghiệm triển khai canary trong môi trường Kubernetes do anh Kim Tae-ho của VCNC, đơn vị vận hành Tada, viết.

• Tên gọi triển khai canary bắt nguồn từ việc các thợ mỏ xưa mang theo chim hoàng yến trong lồng để phát hiện rò rỉ khí độc trong hầm mỏ.

• Khi nâng major version của Spring Boot, phiên bản của các thư viện phụ thuộc cũng bị thay đổi bắt buộc, nên nhóm đã thử triển khai canary để giảm thiểu các vấn đề hiệu năng hoặc sự cố chưa được kiểm thử có thể phát sinh từ đó.

• Việc triển khai trên Kubernetes sử dụng trình quản lý gói Helm; đơn vị gói của Helm được gọi là "chart", và khi cài chart vào cụm Kubernetes thì một release sẽ được tạo ra.

• Nhóm đã tạo chart/release dành cho canary, đồng thời thêm annotation vào Ingress controller để chỉ một tỷ lệ request được chỉ định đi tới canary Ingress.

Các bài toán tiếp theo

• Khi có vấn đề xảy ra ở canary release, rất khó xác định nguyên nhân là do thay đổi của canary hay là vấn đề vốn đã tồn tại, nên cần một cách như dựng nhóm đối chứng với cùng tỷ lệ và so sánh metric.

• Vì một phần request được gửi sang canary mà không phụ thuộc vào người dùng, nên dù canary có vấn đề thì việc retry request đôi khi vẫn thành công do phiên bản cũ xử lý; tuy nhiên xét trên toàn cục, tỷ lệ người dùng gặp phải vấn đề của canary có thể tăng lên, nên nếu route sang canary theo từng nhóm người dùng (tương tự sticky handling ở LB) thì việc kiểm soát có vẻ sẽ tốt hơn.