Hiểu và lựa chọn các resiliency patterns trên cloud

Việc lựa chọn các resillency patterns để đạt được mục tiêu về khả năng phục hồi của bạn có thể là một việc cần nhiều cân nhắc. Việc thiết kế khả năng phục hồi trên cloud thường cần đánh giá nhiều yếu tố trước khi có thể quyết định kiến trúc tối ưu nhất cho từng loại ứng dụng và dịch vụ. Một tổ chức có nhiều ứng dụng với mức độ nghiêm trọng khác nhau và mỗi ứng dụng của họ có những nhu cầu khác nhau về khả năng phục hồi, độ phức tạp và chi phí. Họ có nhiều sự lựa chọn để thiết kế ứng dụng để có khả năng phục hồi sau thảm hoạ và tối ưu chi phí, nhưng lựa chọn nào sẽ phù hợp với nhu cầu của họ nhất ?

Để giúp trả lời câu hỏi này, chúng ta sẽ thảo luận về năm mô hình xây dựng khả năng phục hồi trong Hình 1 và những đánh đổi cần cân nhắc khi triển khai chúng: 1) độ phức tạp của thiết kế, 2) chi phí để thực hiện, 3) công sức khi vận hành, 4) công sức cho vấn đề bảo mật, và 5) tác động đến môi trường. Điều này sẽ giúp bạn đạt được các mức độ phục hồi khác nhau và đưa ra quyết định về kiến ​​trúc phù hợp nhất.

Hình 1. Các mô hình xây dựng khả năng phục hồi và các yếu tố cần cân nhắc 

Khả năng phục hồi là gì? Tại sao nó quan trọng?

AWS Well-Architected Framework  định nghĩa khả năng phục hồi là có “khả năng phục hồi khi hệ thống bị quá tải (nhiều yêu cầu dịch vụ hơn), các cuộc tấn công (tình cờ thông qua một lỗi hoặc cố ý ) và lỗi của bất kỳ thành phần nào trong các thành phần của kiến trúc ứng dụng và dịch vụ.

Để đáp ứng các yêu cầu về khả năng phục hồi của doanh nghiệp, hãy xem xét các yếu tố cốt lõi sau khi bạn thiết kế ứng dụng và dịch vụ của mình:

  • Độ phức tạp của thiết kế – Thông thường, ứng dụng và dịch vụ của bạn càng trở nên phức tạp, thì các yêu cầu về khả năng phục hồi của bạn càng phức tạp. Mỗi thành phần ứng dụng và dịch vụ riêng lẻ phải có khả năng phục hồi và bạn sẽ cần loại bỏ các điểm thất bại đơn lẻ trên các yếu tố con người, quy trình và công nghệ.
  • Chi phí để thực hiện – Chi phí thường tăng lên đáng kể khi bạn triển khai khả năng phục hồi cao hơn vì có các thành phần phần mềm và cơ sở hạ tầng mới để vận hành.
  • Công sức cho việc vận hành – Việc triển khai và hỗ trợ các hệ thống có khả năng phục hồi cao đòi hỏi các quy trình hoạt động phức tạp hơn và các kỹ năng kỹ thuật tiên tiến. Trước khi bạn quyết định triển khai khả năng phục hồi cao hơn, hãy đánh giá năng lực hoạt động của bạn để xác nhận rằng bạn thuần thục quy trình và có đủ kỹ năng cần thiết.
  • Công sức cho việc bảo mật – Độ phức tạp về bảo mật ít tương quan trực tiếp với khả năng phục hồi. Tuy nhiên, nhìn chung có nhiều thành phần hơn để bảo mật cho các hệ thống có khả năng phục hồi cao.  AWS Security best practices có thể giúp khách hàng đạt được các mục tiêu bảo mật của họ cho các triển khai phức tạp như vậy.
  • Tác động đến môi trường – Việc tăng cường triển khai các hệ thống có khả năng phục hồi có thể làm tăng mức tiêu thụ tài nguyên trên cloud của bạn. Tuy nhiên, bạn có thể sử dụng các biện pháp đánh đổi như approximate computing và thời gian phản hồi chậm hơn để giảm mức tiêu thụ tài nguyên.

P1 – Multi-AZ

P1 là một mẫu kiến trúc dựa trên cloud (Hình 2) giới thiệu các Availability Zones (AZs) vào kiến trúc của bạn để tăng khả năng phục hồi của hệ thống. Mẫu P1 sử dụng kiến trúc Đa AZ trong đó các ứng dụng hoạt động ở nhiều AZ trong một Region AWS. Điều này cho phép ứng dụng của bạn chịu được các tác động ở mức AZ.

Như trong Hình 2, Example Corp triển khai các ứng dụng dành cho nhân viên nội bộ của họ bằng cách sử dụng mẫu P1. Những ứng dụng này có tác động kinh doanh thấp và do đó có yêu cầu thấp hơn về khả năng phục hồi.

Example Corp triển khai các ứng dụng này trên Amazon Elastic Compute Cloud (Amazon EC2), sử dụng kiểm tra tình trạng để tự động phát hiện lỗi. Nếu một AZ không thành công, Amazon EC2 sẽ nhắc nhóm Amazon EC2 Auto Scaling tạo lại ứng dụng của họ trong một AZ khác không bị ảnh hưởng.

Hình 2. Mẫu triển khai trên nhiều AZ (P1)

Trade-offs

P1 là tiêu tốn ít công sức nhất, nhưng điều này đi kèm với chi phí khôi phục ứng dụng. Nếu AZ ngừng hoạt động, nó sẽ làm gián đoạn quyền truy cập của người dùng cuối vào ứng dụng trong khi các tài nguyên mới đang được khởi tạo lại trong một AZ mới. Đây được gọi là bi-modal behavior.

P2 – Multi-AZ với static stability

P2 sử dụng nhiều AZ trong một Region để tăng khả năng phục hồi, nhưng nó sử dụng tính ổn định tĩnh để ngăn chặn hành vi hai phương thức. P2 sử dụng hệ thống static stability, hệ thống này vẫn ổn định và hoạt động ở chế độ 1 AZ bất kể những thay đổi đối với môi trường hoạt động của chúng.

Như trong Hình 3, Example Corp có một trang web hướng tới khách hàng có khả năng chịu thời gian downtime thấp hơn. Bất kỳ lúc nào trang web không hoạt động đều dẫn đến mất doanh thu. Do đó, trang web yêu cầu hai máy chủ EC2 được cung cấp trong hai AZ. Bằng cách này, nếu một AZ bị sự cố, trang web có thể tiếp tục hoạt động và không yêu cầu Example Corp phát hiện lỗi hoặc khởi chạy cơ sở hạ tầng mới.

Hình 3. Kiến trúc static stability với nhiều AZ (P2)

Trade-offs

P2 phải được cân nhắc với những lo ngại về chi phí. P1 ít tốn kém hơn vì nó cần ít tài nguyên tính toán hơn và dựa vào việc khởi chạy các máy chủ mới trong trường hợp bị lỗi. Tuy nhiên, hành vi của P1 có thể ảnh hưởng đến khách hàng của bạn trong các sự kiện quy mô lớn.

Bạn có thể tiến xa hơn và triển khai khối lượng công việc của mình tới ba AZ trên toàn Khu vực. Điều này sẽ làm giảm chi phí liên quan đến việc cung cấp quá mức vì bạn chỉ phải tạo ba máy chủ so với bốn máy như khi triển khai trên 2 AZ.

P3 – Application portfolio distribution

Mẫu P3 sử dụng Nhiều Region để tăng khả năng phục hồi . Nó phân phối các ứng dụng quan trọng khác nhau trong nhiều Region.

Example Corp cung cấp các dịch vụ ngân hàng như kiểm tra số dư tín dụng cho người tiêu dùng trên nhiều kênh kỹ thuật số. Những dịch vụ này có sẵn cho người tiêu dùng thông qua ứng dụng di động, trung tâm liên hệ và các ứng dụng dựa trên web. Nếu ứng dụng di động triển khai trên một Region xảy ra sự cố, khách hàng vẫn có thể truy cập dịch vụ thông qua các kênh khác được triển khai tại Region khác. Rất hiếm khi xảy ra gián đoạn ở mức Region, nhưng việc triển khai mô hình này đảm bảo người dùng của bạn vẫn có quyền truy cập vào các dịch vụ quan trọng của doanh nghiệp trong thời gian gián đoạn.

Ảnh 4. Mô hình phân phối danh mục ứng dụng (P3)

Trade-offs

Việc vận hành một danh mục ứng dụng trải dài trên nhiều Region đòi hỏi phải lập kế hoạch và tốn công sức quản lý hoạt động đáng kể. Các chức năng biệt lập có thể phụ thuộc vào các hệ thống chung bên dưới và các nguồn dữ liệu được triển khai trong một Region duy nhất. Do đó, các sự cố xảy ra trên toàn Region có thể vẫn gây ra gián đoạn; tuy nhiên, phạm vi thiệt hại sẽ giảm đi đáng kể.

P4 – Multi-AZ deployment (multi-Region disaster recovery)

Example Corp điều hành một số dịch vụ quan trọng trong kinh doanh, chẳng hạn như khả năng người tiêu dùng thanh toán qua ngân hàng, có khả năng bị gián đoạn rất thấp. Example Corp sử dụng các mẫu kiến trúc sau cho các ứng dụng này:

  • Pilot Light – Mẫu này hoạt động cho các ứng dụng yêu cầu RTO / RPO trong 10 phút. Dữ liệu được chủ động replicate và cơ sở hạ tầng ứng dụng được cung cấp trước trong Region khôi phục sau thảm họa (DR). Tối ưu hóa chi phí là động lực chính vì cơ sở hạ tầng ứng dụng được giữ ở trạng thái tắt và chỉ được bật khi cần khôi phục.
  • Warm Standby – Chiến lược này cải thiện thời gian khôi phục đáng kể so với pilot light bằng cách giữ cho các ứng dụng của bạn chạy trong Region DR nhưng với quy mô nhỏ hơn. Cơ sở hạ tầng ứng dụng sẽ được mở rộng trong sự kiện DR nhưng điều này thường có thể được tự động hóa ( một thế mạnh trên cloud ). Mô hình này có thể đạt được RTO / RPO trong vài phút nếu được triển khai đúng cách.

Tài liệu whitepaper về Disaster Recovery of Workloads on AWS: Recovery in the Cloud  ghi lại chi tiết các kiến trúc mẫu này.

Trade-offs

Các kiến trúc DR ở cấp Region làm tăng độ phức tạp khi triển khai vì các thay đổi về cơ sở hạ tầng cần được đồng bộ hóa giữa các Region. Thử nghiệm cũng phức tạp hơn đáng kể và nên bao gồm các tình huống như mất một Region và  định tuyến và quản lý lưu lượng. Sử dụng Cơ sở hạ tầng bằng Mã ( Infrastructure as code ) để tự động hóa việc triển khai có thể giúp giảm bớt những vấn đề này.

P5 – Multi-Region active-active

Hệ thống Core Banking của Example Corp và các ứng dụng Quản lý quan hệ khách hàng của họ không chấp nhận xảy ra bất kỳ gián đoạn nào, kể cả ở cấp độ Region . Họ sử dụng kiến trúc mẫu P5 để triển khai các ứng dụng này vì nó có RTO theo thời gian thực và RPO gần như bằng không. Bằng cách này, họ chạy ứng dụng và dịch vụ của mình đồng thời trong nhiều Region, điều này cho phép họ phục vụ lưu lượng truy cập từ tất cả các Region.

Ảnh 5. Multi-Region active-active pattern (P5)

Trade-offs

Các hệ ứng dụng active-active thường phức tạp vì chúng bao gồm nhiều ứng dụng cộng tác để cung cấp các dịch vụ kinh doanh. Nếu bạn triển khai kiến trúc mẫu này, bạn sẽ cần xem xét vấn đề bạn đang sử dụng bản sao không đồng bộ cho dữ liệu trên các Region và các ảnh hướng về vấn đề toàn vẹn dữ liệu.

Việc vận hành mô hình này yêu cầu mức độ hoàn thiện của quy trình rất cao, vì vậy chúng tôi khuyên khách hàng nên dần dần xây dựng theo mô hình này bằng cách bắt đầu với các mô hình triển khai được mô tả trước đó.

Kết luận

Trong bài đăng trên blog này, chúng tôi đã giới thiệu năm mô hình xây dựng khả năng phục hồi và những đánh đổi cần cân nhắc khi triển khai chúng. Chúng tôi đã cho bạn thấy cách Example Corp đánh giá các tùy chọn này và cách chúng áp dụng cho nhu cầu kinh doanh của họ để giúp bạn quyết định về kiến trúc hiệu quả nhất để triển khai.

Đọc thêm

Tìm kiếm thêm nội dung về kiến trúc?

AWS Architecture Center cung cấp các sơ đồ kiến trúc tham chiếu, các giải pháp kiến trúc đã được hiệu chỉnh, các phương pháp hay nhất được kiến trúc tốt nhất, các mẫu, biểu tượng và hơn thế nữa!


Bài được dịch từ bài viết trên AWS Blogs, bạn có thể xem bài viết gốc tại đây.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: