bởi Haresh Nandwani, Lewis Taylor, và Bonnie McClure | 03/02/2023 | trong Architecture, AWS Well-Architected, Regions | Permalink | Share
Bài đăng này ban đầu được xuất bản vào tháng 6 năm 2022 và hiện đã được cập nhật với nhiều thông tin hơn về cách xây dựng các mô hình linh hoạt một cách hiệu quả trên đám mây.
Thiết kế các khối công việc cho khả năng phục hồi trên đám mây thường cần đánh giá nhiều yếu tố trước khi họ có thể quyết định kiến trúc tối ưu nhất cho các khối công việc của họ.
Ví dụ Tập đoàn ngẫu nhiên nào đó có nhiều ứng dụng với mức độ quan trọng khác nhau, và mỗi ứng dụng của họ có nhu cầu khác nhau về khả năng phục hồi, tính phức tạp và chi phí. Họ có nhiều lựa chọn để thiết kế các khối công việc của họ cho khả năng phục hồi và chi phí, nhưng lựa chọn nào phù hợp nhất với nhu cầu của họ? Họ nên cân nhắc điều gì khi chọn các mô hình phù hợp nhất cho nhu cầu của các ứng dụng của họ?
Để giúp trả lời những câu hỏi này, chúng ta sẽ thảo luận về năm mô hình khả năng phục hồi trong Hình 1 và những cân nhắc khi triển khai chúng: 1) phức tạp trong thiết kế, 2) chi phí triển khai, 3) nỗ lực vận hành, 4) nỗ lực đảm bảo an toàn, và 5) tác động môi trường. Điều này sẽ giúp bạn đạt được các mức độ khả năng phục hồi khác nhau và đưa ra quyết định về kiến trúc phù hợp nhất cho nhu cầu của bạn. Mục đích của chúng tôi là cung cấp một cách tiếp cận tổng quát để cấu trúc hóa các cuộc thảo luận về các cân nhắc liên quan đến từng mô hình này. Để tìm hiểu sâu hơn về từng mô hình, hãy truy cập phần Đọc thêm ở cuối bài đăng này.
Lưu ý: các mô hình này không loại trừ lẫn nhau; bạn có thể quyết định triển khai một kết hợp của một hoặc nhiều mô hình.
Hình 1. Mô hình khả năng phục hồi và sự đánh đổi
Khả năng phục hồi là gì? Tại sao nó lại 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 bị căng thẳng bởi tải (nhiều yêu cầu dịch vụ hơn), tấn công (hoặc vô tình do lỗi hoặc cố ý do ý định) và sự cố của bất kỳ thành phần nào trong các thành phần khối công việc”.
Để đáp ứng các yêu cầu khả năng phục hồi kinh doanh, hãy cân nhắc các yếu tố cốt lõi sau khi thiết kế các tải làm việc của bạn:
- Phức tạp trong thiết kế – Sự gia tăng phức tạp hệ thống thường làm tăng các hành vi phát sinh của hệ thống đó. Mỗi thành phần khối công việc riêng lẻ phải có khả năng phục hồi, và bạn cần loại bỏ các điểm lỗi duy nhất trên các yếu tố con người, quy trình và công nghệ. Khách hàng nên cân nhắc các yêu cầu khả năng phục hồi của họ và quyết định liệu tăng phức tạp hệ thống có phải là một cách tiếp cận hiệu quả hay giữ hệ thống đơn giản và sử dụng kế hoạch khôi phục thảm họa (DR) sẽ phù hợp hơn.
- Chi phí triển khai – Chi phí thường tăng đáng kể khi bạn triển khai khả năng phục hồi cao hơn bởi vì có các thành phần phần mềm và hạ tầng mới để vận hành. Điều quan trọng là các chi phí đó phải được bù đắp bằng chi phí tiềm tàng của tổn thất trong tương lai.
- Nỗ lực vận hành – 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 vận hành phức tạp và kỹ năng kỹ thuật nâng cao. Ví dụ, khách hàng có thể cần cải thiện các quy trình vận hành của họ bằng cách sử dụng cách tiếp cận Operational Readiness Review (ORR). Trước khi quyết định triển khai khả năng phục hồi cao hơn, hãy đánh giá năng lực vận hành của bạn để xác nhận bạn có mức độ trưởng thành quy trình và kỹ năng được yêu cầu hay không.
- Nỗ lực đảm bảo an toàn – Tính phức tạp về bảo mật ít liên quan trực tiếp đến khả năng phục hồi. Tuy nhiên, thông thường có nhiều thành phần cần bảo đảm an toàn hơn đối với các hệ thống có khả năng phục hồi cao. Sử dụng các thực hành tốt nhất về bảo mật cho các triển khai trên đám mây có thể đạt được các mục tiêu bảo mật mà không làm tăng đáng kể tính phức tạp ngay cả khi vận hành trên quy mô triển khai lớn hơn.
- Tác động môi trường – Quy mô triển khai lớn hơn cho các hệ thống có khả năng phục hồi cao có thể làm tăng lượng tài nguyên đám mây mà bạn tiêu thụ. Tuy nhiên, bạn có thể sử dụng các cân nhắc như tính toán gần đúng và cố tình triển khai thời gian phản hồi chậm hơn để giảm mức tiêu thụ tài nguyên. Trụ cột Bền vững của Khung Kiến trúc Tốt của AWS mô tả các mô hình này và cung cấp hướng dẫn về các thực hành tốt nhất về bền vững.
Mô hình 1 (P1): Multi-AZ
P1 là một mô hình kiến trúc đám mây (Hình 2) giới thiệu các Availability Zones (AZs) Vùng Sẵn sàng (AZ) 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ô hình P1 sử dụng kiến trúc Multi-AZ trong đó các ứng dụng hoạt động trên nhiều AZ trong một Vùng AWS duy nhất. Điều này cho phép ứng dụng của bạn chịu đựng được các tác động cấp AZ.
Như được thể hiện trong Hình 2, Tập đoàn trong ví dụ này triển khai các ứng dụng nội bộ dành cho nhân viên của họ bằng cách sử dụng mô hình P1. Các ứng dụng này có tác động kinh doanh thấp và do đó có các yêu cầu khả năng phục hồi thấp hơn.
Tập đoàn này triển khai các ứng dụng có tác động kinh doanh thấp của họ là một Amazon Elastic Compute Cloud (Amazon EC2) Amazon Elastic Compute Cloud (Amazon EC2) instance được quản lý bởi một nhóm Auto Scaling. Amazon EC2 sử dụng các kiểm tra trạng thái để tự động phát hiện lỗi. Nếu một AZ bị lỗi, Amazon EC2 sẽ nhắc một Amazon EC2 Auto Scaling nhóm Auto Scaling Amazon EC2 để 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 Multi-AZ (P1)
Sự đánh đổi
P1 ở mức thấp trong một số danh mục và giảm thiểu sự gián đoạn đối với AZ lưu trữ ứng dụng, nhưng điều này đi kèm với chi phí là sự phục hồi của ứng dụng. Nếu một AZ bị lỗi, nó sẽ gây 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 cấp phát trong một AZ mới. Điều này được gọi là hành vi hai chế độ.
Mô hình 2 (P2): Multi-AZ với ổn định tĩnh
P2 sử dụng nhiều instance trên nhiều AZ trong một Vùng để tăng khả năng phục hồi. Mô hình này sử dụng sự ổn định tĩnh để ngăn chặn hành vi hai chế độ. Các hệ thống ổn định tĩnh vẫn ổn định và hoạt động ở một chế độ, bất kể các thay đổi trong môi trường hoạt động của chúng. Một lợi ích chính của hệ thống ổn định tĩnh trên AWS là nó giảm thiểu phức tạp của quá trình phục hồi trong trường hợp gián đoạn nhờ dung lượng tài nguyên được cung cấp trước. Bất kỳ tài nguyên nào cần thiết để duy trì hoạt động trong trường hợp gián đoạn, chẳng hạn như mất tài nguyên trong một AZ, đã tồn tại và các bảng điều khiển dịch vụ AWS không cần phải sẵn sàng để phục hồi thành công. Để tìm hiểu thêm về ổn định tĩnh, các bảng điều khiển dữ liệu và bảng điều khiển, hãy đọc bài viết về ổn định tĩnh sử dụng các Vùng Sẵn sàng trong Thư viện Nhà xây dựng .
Như được thể hiện trong Hình 3, Tập đoàn này có một trang web đối mặt với khách hàng có khả năng chịu đựng thời gian chết thấp hơn. Bất cứ lúc nào trang web bị lỗi, điều đó có thể dẫn đến mất doanh thu. Vì lý do đó, trang web yêu cầu hai instance EC2 được cung cấp trong hai AZ. Sử dụng các kiểm tra trạng thái, khi AZ bị suy giảm, trang web vẫn tiếp tục hoạt động khi Elastic Load Balancer chuyển hướng lưu lượng truy cập khỏi AZ bị ảnh hưởng. Để biết thêm về việc sử dụng kiểm tra trạng thái, hãy xem bài viết Triển khai kiểm tra trạng thái trong Thư viện Nhà xây dựng Amazon.
Hình 3. Multi-AZ với mẫu ổn định tĩnh (P2)
Sự đánh đổi
P2 giảm thiểu sự gián đoạn của AZ mà không gây ra thời gian chết cho khách hàng ứng dụng nhưng phải được cân nhắc với các mối quan tâm về chi phí. P1 có chi phí thấp hơn về mặt chi phí hạ tầng, vì nó cung cấp ít dung lượng tính toán hơn và dựa vào việc khởi chạy các instance mới trong trường hợp có lỗi. Tuy nhiên, hành vi hai chế độ của P1 có thể ảnh hưởng đến khách hàng của bạn trong các sự kiện lớn.
Việc triển khai P2 đòi hỏi ứng dụng của bạn phải hỗ trợ hoạt động phân tán trên nhiều instance. Nếu ứng dụng của bạn có thể hỗ trợ mô hình này, bạn có thể triển khai khối công việc của mình trên tất cả các AZ khả dụng (thường là 3 hoặc nhiều hơn) trên toàn Vùng. Điều này sẽ giảm chi phí liên quan đến việc cung cấp quá mức vì bạn chỉ cần cung cấp 150% dung lượng của mình trên ba AZ so với 200% trên hai AZ (như đã đề cập trong ví dụ trước đây của chúng tôi).
Mô hình 3 (P3): Phân phối danh mục ứng dụng
P3 sử dụng mô hình Multi-Vùng để tăng khả năng phục hồi chức năng, như được minh họa trong Hình 4. Nó phân phối các ứng dụng quan trọng khác nhau trên nhiều Region.
Tập đoàn này cung cấp 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ố. Các 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. Mỗi kênh kỹ thuật số được triển khai tại một Vùng riêng biệt, điều này giảm thiểu nguy cơ gián đoạn dịch vụ khu vực.
Ví dụ, một Vùng có ứng dụng di động của khách hàng có thể gặp sự gián đoạn khiến ứng dụng di động không khả dụng, nhưng khách hàng vẫn có thể truy cập dịch vụ ngân hàng trực tuyến được triển khai tại một Vùng khác. Sự gián đoạn dịch vụ khu vực là hiếm nhưng triển khai một mô hình như thế 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ụ kinh doanh quan trọng trong thời gian gián đoạn.
Hình 4. Mô hình phân bổ danh mục ứng dụng (P3)
Sự đánh đổi
P3 giảm thiểu khả năng một sự gián đoạn dịch vụ khu vực tác động đồng thời đến nhiều hệ thống. Vận hành một danh mục ứng dụng trải dài trên nhiều Vùng đòi hỏi kế hoạch và quản lý vận hành đáng kể. Các yếu tố chức năng riêng lẻ có thể phụ thuộc vào các hệ thống hạ nguồn và nguồn dữ liệu chung được triển khai tại một Vùng duy nhất. Do đó, các sự kiện toàn Vùng vẫn có thể gây ra gián đoạn, nhưng diện tích tác động nên được giảm bớt.
Mô hình 4 (P4): Triển khai Multi-AZ (DR Multi-Region)
Tập đoàn mẫu này vận hành một số dịch vụ quan trọng đối với doanh nghiệp có khả năng chịu đựng gián đoạn rất thấp, chẳng hạn như khả năng cho người tiêu dùng thực hiện thanh toán ngân hàng. Tập đoàn Ví dụ đã xem xét bốn mô hình phổ biến cho DR (như được định nghĩa trong Phục hồi Tải làm việc trên AWS: Khôi phục trên Đám mây) và quyết định sử dụng các mô hình con sau đây cho các ứng dụng đa khu vực của họ:
- Đèn chiếu sáng (Pilot Light) – Mô hình này dành cho các ứng dụng yêu cầu RTO/RPO từ 10s/phút trở xuống. Dữ liệu được nhân bản chủ động và hạ tầng ứng dụng được cấp phát sẵn tại DR Region. Tối ưu hóa chi phí là động lực chính ở đây, vì hạ tầng ứng dụng được giữ tắt và chỉ bật trong sự kiện khôi phục.
- Chờ hâm nóng (Warm Standby) – Mô hình này cải thiện đáng kể thời gian khôi phục so với đèn chiếu sáng bằng cách giữ cho các ứng dụng của bạn chạy trong DR Region nhưng với dung lượng giảm. Hạ tầng ứng dụng sẽ được mở rộng quy mô trong sự kiện DR, nhưng điều này thường có thể được tự động hóa với nỗ lực thủ công tối thiểu. Mô hình này có thể đạt được RTO/RPO trong vài phút nếu được triển khai chính xác.
Sự đánh đổi
P4 giảm thiểu sự gián đoạn đối với một dịch vụ khu vực đồng thời giảm chi phí giảm nhẹ. Các mô hình DR khu vực làm tăng phức tạp triển khai khi các thay đổi hạ tầng cần phải được đồng bộ hóa trên nhiều Vùng. Kiểm tra khả năng phục hồi cũng phức tạp hơn đáng kể và bao gồm mô phỏng các sự gián đoạn khu vực. Sử dụng Cơ sở hạ tầng dưới dạng Mã để tự động hóa triển khai có thể giúp giảm nhẹ các vấn đề này.
Mô hình 5 (P5): Multi-Region Vùng hoạt động-hoạt động
Như ví dụ, Các ứng dụng ngân hàng cốt lõi và Quản lý Quan hệ Khách hàng của Tập đoàn Ví dụ không có khả năng chịu đựng gián đoạn. Họ sử dụng mô hình P5 để triển khai các ứng dụng này vì nó có RTO thời gian thực và RPO gần như không mất dữ liệu. Họ chạy tải làm việc của mình đồng thời trên nhiều Vùng, cho phép họ phục vụ lưu lượng truy cập từ tất cả các Vùng cùng một lúc. Mô hình này không chỉ giảm thiểu nguy cơ gián đoạn khu vực mà còn giải quyết các yêu cầu không thể chịu đựng của họ (Hình 5).
Hình 5. Mẫu hoạt động chủ động-chủ động đa vùng (P5)
Sự đánh đổi
P5 giảm thiểu sự gián đoạn của dịch vụ khu vực và đầu tư chi phí và phức tạp bổ sung để đạt được RTO gần như bằng không. Các triển khai đa hoạt động 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 cần thiết. Nếu bạn triển khai mô hình này, bạn cần xem xét việc bạn đang giới thiệu sự nhân bản không đồng bộ cho dữ liệu trên nhiều Region Vùng và tác động của nó đối với tính nhất quán dữ liệu.
Vận hành mô hình này đòi hỏi mức độ trưởng thành quy trình rất cao, vì vậy chúng tôi khuyên khách hàng nên từ từ xây dựng theo hướng 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 khả năng phục hồi và các cân nhắc khi triển khai chúng. Trong nỗ lực giúp bạn tìm ra kiến trúc hiệu quả nhất cho trường hợp sử dụng của mình, chúng tôi đã minh họa cách Tập đoàn Ví dụ đã đánh giá các lựa chọn này và cách họ áp dụng chúng vào nhu cầu kinh doanh của mình.
Đọc thêm
AWS Study Group 