Khách hàng ngày nay có kỳ vọng cao đối với các trang web và ứng dụng web. Họ mong đợi các trang web và ứng dụng luôn sẵn sàng và khi chúng không hoạt động, điều này trở thành tin tức quan trọng. Hãy tưởng tượng một ứng dụng mạng xã hội bị ngừng hoạt động trong một giờ hoặc lâu hơn. Các công ty sẽ gửi những người giỏi nhất của họ để sửa lỗi càng sớm càng tốt. Họ cũng sẽ gửi thông báo cho người dùng để giải thích về sự cố xảy ra và cách họ sẽ tránh nó trong tương lai. Bên trong, họ sẽ tiến hành nhiều cuộc tổng kết và phân tích sau sự cố để củng cố hệ thống và cơ sở hạ tầng của họ và thực hiện cam kết với người dùng.
Và điều này chỉ đúng cho các ứng dụng mạng xã hội. Các trang web và ứng dụng tài chính gắn bó mật thiết với cuộc sống cá nhân của khách hàng, ảnh hưởng đến khả năng họ truy cập và sử dụng tài chính của họ. Khách hàng ngày càng thực hiện các giao dịch tài chính trực tuyến từ việc thanh toán, giao dịch cổ phiếu, chuyển tiền đến tài khoản, vv. Do đó, khách hàng ngày càng kỳ vọng rằng các ứng dụng tài chính sẽ luôn sẵn sàng. Mọi sự cố về sự sẵn sàng của các ứng dụng này không chỉ ảnh hưởng đến sự hài lòng của khách hàng mà còn ảnh hưởng đến sự tin tưởng, danh tiếng và uy tín của tổ chức tài chính.
Làm thế nào để đảm bảo rằng các ứng dụng tài chính luôn sẵn sàng cho khách hàng?
Thay đổi là không thể tránh khỏi đối với hệ thống trực tuyến
Các doanh nghiệp trong lĩnh vực tài chính và cả các lĩnh vực khác ngày càng xây dựng các hệ thống “luôn hoạt động” để cung cấp sự sẵn sàng 24/7 cho khách hàng của họ. Những hệ thống này cần được cập nhật liên tục để thêm tính năng mới, cập nhật công nghệ, vv. Thay đổi hệ thống đang hoạt động luôn đi kèm với rủi ro của việc xảy ra sự cố. Các sự cố này có thể xuất phát từ lỗi hệ thống hoặc lỗi ứng dụng/đặc tính chức năng. Có các chiến lược khác nhau để giảm thiểu rủi ro của các sự cố khác nhau cho các hệ thống “luôn hoạt động”.
Triển khai Blue-Green
Triển khai Blue-Green là một kỹ thuật phổ biến để triển khai phiên bản mới của phần mềm mà không ảnh hưởng đến lưu lượng trực tuyến hiện tại. Trong phương pháp này, tạo hai ngăn xếp cơ sở hạ tầng; một gọi là Blue và một gọi là Green. Tại bất kỳ thời điểm nào, một trong những ngăn xếp đang phục vụ lưu lượng trực tuyến trong khi ngăn xếp còn lại đang trống rỗng. Cơ sở hạ tầng ngăn xếp trống rỗng có thể tắt khi không sử dụng để tránh lãng phí tài nguyên. Trong quá trình cập nhật, phiên bản mới được triển khai trên ngăn xếp trống rỗng. Khi tất cả kiểm tra hoàn tất, lưu lượng được mở cho ngăn xếp trống rỗng, ngăn xếp trống rỗng trở nên hoạt động và ngăn xếp hoạt động trở nên trống rỗng.
Triển khai Canary
Triển khai Canary là một kỹ thuật mà lưu lượng được giới hạn dần dần đến phiên bản mới của phần mềm. Lợi ích của phương pháp này là tác động của bất kỳ vấn đề nào thấp hơn so với việc mở toàn bộ lưu lượng đến phiên bản mới. Khi phiên bản mới được kiểm tra và không có vấn đề nào phát hiện, sau đó phiên bản mới được triển khai cho các máy chủ còn lại dựa trên một cơ chế trượt dần.
Triển khai Canary là một trong những phương pháp tốt nhất cho việc nâng cấp hệ thống “luôn hoạt động” nơi cả hai phiên bản - cũ và mới - có thể hoạt động song song mà không gây tác động phụ. Điều này đòi hỏi kiểm tra end-to-end để đảm bảo phiên bản mới không gặp vấn đề gì. Nó cũng cho phép mở lưu lượng cho một phần dân số người dùng nhỏ trước khi tăng dần. Trong trường hợp xảy ra vấn đề gì, điều này cho phép quay lại phiên bản trước đó một cách nhanh chóng.
Dịch vụ AWS
AWS cung cấp một bộ dịch vụ phong phú có thể được sử dụng để triển khai Blue-Green và Canary Deployments.
- Route 53: Dịch vụ quản lý DNS cung cấp khả năng định tuyến và kiểm tra tình trạng sức khỏe.
- ALB: Trạm cân bằng ứng dụng phân phối lưu lượng đến nhiều mục tiêu - như các trường hợp EC2 - ở nhiều khu vực khả dụng.
- ECS: Dịch vụ quản lý Container Elastic cho phép chạy và mở rộng các ứng dụng được đóng gói trong Docker một cách dễ dàng.
- EC2: Dịch vụ máy tính Elastic cung cấp khả năng tính toán có thể mở rộng trên AWS.
- ASG: Một nhóm Tự động Mở rộng chứa một bộ sưu tập các trường hợp EC2 có các đặc điểm tương tự và được coi là một nhóm hợp lý cho mục đích tỷ lệ và quản lý trường hợp.
Triển khai Canary bằng cách sử dụng dịch vụ AWS
Có nhiều cách để triển khai Canary bằng cách sử dụng các dịch vụ AWS. Các kỹ thuật này có thể được sử dụng cho các ngăn xếp ALB/ECS hoặc các ngăn xếp ALB/ASG. Triển khai Canary cũng có thể được thực hiện bằng cách tạo một ngăn xếp hoặc bằng cách tạo hai ngăn xếp.
Phương pháp 1 Ngăn xếp: Triển khai Canary bằng cách sử dụng Dịch vụ AWS
Trong phương pháp này, có một ngăn xếp ALB/ECS đang phục vụ lưu lượng trực tuyến. Phiên bản mới của phần mềm được triển khai bằng cách tăng kích thước của ASG hoặc bằng cách gắn thêm một ASG khác. Khi phiên bản mới được kiểm tra và không có vấn đề nào được phát hiện, sau đó phiên bản mới được triển khai trên các trường hợp còn lại dựa trên một cơ chế trượt dần.
Xem xét phương pháp này trong đó kích thước ngăn xếp nhỏ hơn và SLA (Dịch vụ Mức độ Dịch vụ) cho quay lại lớn hơn. Lưu ý rằng phương pháp này không cung cấp kiểm soát đối với việc chỉ định tỷ lệ lưu lượng cho phiên bản mới. ALB định tuyến lưu lượng đến tất cả các trường hợp EC2. Trong ví dụ trên, khi tạo một trường hợp mới, vì có 4 trường hợp, 25% lưu lượng sẽ được đưa vào phiên bản mới.
Ngoài ra, quá trình quay lại sau khi phát hành đầy đủ có thể mất thời gian lâu hơn so với mong muốn. Để quay lại, lặp lại quy trình trên cho phiên bản trước đó của phần mềm. Thời gian cần thiết để quay lại phụ thuộc vào số trường hợp và thời gian khởi động của mỗi trường hợp.
Một biến thể khác của phương pháp này là sử dụng hai ASG và thêm trường hợp mới vào ASG thứ hai. Xem biểu đồ dưới đây:
Xem xét phương pháp này trong đó kích thước ngăn xếp lớn hơn và SLA (Dịch vụ Mức độ Dịch vụ) cho quay lại lớn hơn. Phương pháp này không cung cấp kiểm soát đối với việc chỉ định tỷ lệ lưu lượng cho phiên bản mới. ALB định tuyến lưu lượng đến tất cả các trường hợp EC2.
Quá trình quay lại dễ dàng hơn khi cả hai ASG đang phục vụ lưu lượng thay vì sau khi thu nhỏ phiên bản cũ hơn. Chỉ cần thu nhỏ ASG có phiên bản V2 về 0. Điều này sẽ chấm dứt tất cả các trường hợp có phiên bản V2. Tuy nhiên, sau khi phát hành đầy đủ, quay lại có thể mất thời gian lâu hơn. Để quay lại, lặp lại quy trình trước đó cho phiên bản trước đó của phần mềm. Thời gian cần thiết để quay lại phụ thuộc vào số lượng trường hợp và thời gian khởi động của mỗi trường hợp.
Phương pháp 2 Ngăn xếp: Triển khai Canary bằng cách sử dụng Dịch vụ AWS
Trong phương pháp này, thiết lập hai ngăn xếp song song của ALB/ECS. Sử dụng chính sách trọng lượng của Route53 để gửi lưu lượng đến cả hai hoặc cả hai ngăn xếp. Theo mặc định, 100% lưu lượng được phục vụ bởi một ngăn xếp (ví dụ, Blue). Phiên bản mới của phần mềm được triển khai trên ngăn xếp không hoạt động (trong trường hợp này, Green). Tất cả kiểm tra và kiểm tra sức khỏe được chạy trên ngăn xếp Green trước khi định tuyến bất kỳ lưu lượng nào. Khi mọi thứ ổn định, một phần nhỏ lưu lượng (ví dụ, 10%) được mở ra ngăn xếp Green bằng cách thay đổi trọng lượng của bản ghi Route53.
Xem biểu đồ dưới đây:
Khi cả hai ngăn xếp đều phục vụ lưu lượng, dễ dàng so sánh tình trạng sức khỏe, thời gian phản hồi và tỷ lệ lỗi của mỗi ngăn xếp một cách tự động và quyết định tăng hoặc giảm lưu lượng đến ngăn xếp mới. Nếu mọi thứ đều diễn ra tốt, hãy từ từ tăng lưu lượng đến ngăn xếp mới cho đến khi nó đạt 100%. Điều này cho phép bạn thực hiện việc triển khai và thay đổi lưu lượng một cách an toàn và kiểm soát được sự chuyển đổi sang phiên bản mới của phần mềm hoặc hạ tầng mà không gây ra tác động tiêu cực đối với trải nghiệm của người dùng.
Xem biểu đồ dưới đây:
Lợi ích của phương pháp này là:
- Kiểm soát hoàn toàn về tỷ lệ.
- Không ảnh hưởng đến sức khỏe của ngăn xếp hiện tại.
- Dễ dàng và nhanh chóng quay lại; thời gian cần thiết để chuyển lưu lượng phụ thuộc vào giá trị TTL được cấu hình cho bộ ghi Route 53.
- Xem xét phương pháp này cho các hệ thống quan trọng đối với doanh nghiệp với ngưỡng chịu rủi ro thấp, vì phương pháp này cung cấp tùy chọn quay lại nhanh nhất.
Tóm lại
Tổng kết lại, trước khi đưa ra quyết định về chiến lược triển khai, đánh giá sự chịu rủi ro của hệ thống của bạn, xác định các rủi ro đối với hệ thống đang hoạt động và chọn chiến lược phù hợp nhất cho hệ thống của bạn. Dưới đây là một số hướng dẫn tổng quan có thể hữu ích để làm cho hệ thống trở nên bền vững hơn.
Có một cơ chế kiểm tra sức khỏe mạnh mẽ: Đảm bảo rằng bạn có một hệ thống kiểm tra sức khỏe mạnh mẽ để theo dõi tình trạng của hệ thống và ứng dụng. Điều này giúp phát hiện sớm các vấn đề và sự cố, cho phép bạn can thiệp kịp thời.
Thêm các bộ theo dõi thông minh và thông báo: Sử dụng các hệ thống giám sát thông minh và cảnh báo để theo dõi hiệu suất của hệ thống, lưu lượng và các vấn đề khác. Điều này giúp bạn biết trước về các vấn đề tiềm ẩn và có thể ứng phó với chúng trước khi chúng trở nên nghiêm trọng.
Đánh giá sự chịu rủi ro của từng phiên bản và chuẩn bị các phương án fallback: Xác định mức độ chịu rủi ro cho mỗi phiên bản hoặc cập nhật và chuẩn bị các phương án fallback (quay lại phiên bản trước) trong trường hợp xảy ra sự cố.
Quyết định về chiến lược triển khai phù hợp nhất cho hệ thống của bạn: Chọn chiến lược triển khai phù hợp nhất cho hệ thống của bạn, ví dụ: Blue-Green Deployment hoặc Canary Deployment, dựa trên tính đặc thù và yêu cầu của hệ thống.
Sử dụng kiểm tra tự động, xác thực tự động và luồng công việc tự động: Tự động hóa các giai đoạn của quy trình triển khai để giảm thiểu sai sót con người và đảm bảo tính nhất quán và đáng tin cậy trong việc triển khai.
Thêm thông tin thông minh để tự động quay lại: Cân nhắc việc sử dụng thông tin thông minh trong quá trình quay lại tự động, giúp việc quay lại trở nên hiệu quả và nhanh chóng.
Tách riêng phát hành cơ sở hạ tầng (nâng cấp JDK, nâng cấp Framework) khỏi các phát hành chức năng (các tính năng mới, cải tiến, thay đổi logic): Điều này giúp quản lý rủi ro và triển khai một cách riêng rẽ cho từng loại phát hành.
Có một kế hoạch phát hành toàn diện: Chuẩn bị kế hoạch phát hành chi tiết, bao gồm việc thông báo cho người dùng về sự cố đang xảy ra và về cách triển khai sẽ ảnh hưởng đến họ.
Tất cả những điều này là quan trọng để đảm bảo tính ổn định và sẵn sàng của hệ thống và ứng dụng của bạn trong quá trình triển khai và quản lý.
Bình luận