2.Thiết kế kiến trúc có khả năng phục hồi trên AWS

Bài viết này tập trung vào cách thiết kế kiến trúc AWS có khả năng phục hồi, có thể mở rộng và dễ bảo trì. Nội dung chính bao gồm kiến trúc nhiều tầng, microservice, kiến trúc hướng sự kiện, cách sử dụng các dịch vụ như Amazon SQS, Amazon SNS, Amazon EventBridge, AWS Lambda, Amazon ECS, Amazon EKS và AWS Fargate để xây dựng hệ thống liên kết lỏng lẻo.

Bên cạnh đó, bài viết cũng trình bày các chiến lược mở rộng hệ thống, lựa chọn công nghệ điện toán, lưu trữ, mạng và cơ sở dữ liệu phù hợp với từng yêu cầu workload. Phần sau tập trung vào kiến trúc có tính sẵn sàng cao và khả năng chịu lỗi, bao gồm triển khai trên nhiều Availability Zone, sử dụng Elastic Load Balancing, Auto Scaling, Amazon RDS Multi-AZ, Route 53, chiến lược sao lưu, khôi phục sau thảm họa và cách giảm thiểu điểm lỗi đơn.

Nói ngắn gọn, đây là phần giúp bạn thiết kế hệ thống AWS sao cho khi lưu lượng tăng, một thành phần bị lỗi, hoặc thậm chí một khu vực gặp sự cố, hệ thống vẫn có cơ hội đứng vững thay vì “ngã một cái là cả nhà cùng ngã”.

Mục lục

  1. Thiết kế kiến trúc có khả năng mở rộng và liên kết lỏng lẻo
  2. Thiết kế kiến trúc có tính sẵn sàng cao và khả năng chịu lỗi

2.1. Thiết kế kiến trúc có khả năng mở rộng và liên kết lỏng lẻo

Thiết kế kiến trúc hướng sự kiện, microservice và nhiều tầng dựa trên yêu cầu

Việc này liên quan đến việc chọn mẫu kiến trúc phù hợp dựa trên nhu cầu cụ thể của ứng dụng. Dưới đây là phân tích từng loại kiến trúc:

Kiến trúc nhiều tầng

Kiến trúc nhiều tầng là cách tiếp cận truyền thống, chia ứng dụng thành các lớp riêng biệt, thường gồm tầng trình bày (UI), tầng logic ứng dụng (business logic) và tầng lưu trữ dữ liệu.

Mặc dù kiến trúc nhiều tầng không mặc định là “liên kết lỏng lẻo”, nhưng nếu được thiết kế cẩn thận, chúng ta vẫn có thể giảm thiểu sự phụ thuộc giữa các tầng. Nói dễ hiểu, các tầng vẫn làm việc chung với nhau, nhưng không nên “dính nhau như keo 502”.

Các dịch vụ AWS thường dùng trong kiến trúc nhiều tầng bao gồm:

  • Tầng trình bày: Amazon S3 để lưu trữ website tĩnh, Amazon CloudFront để làm CDN, và Elastic Load Balancing (ELB) để phân phối lưu lượng.
  • Tầng ứng dụng: Amazon EC2, AWS Elastic Beanstalk, Amazon ECS hoặc Amazon EKS cho các ứng dụng container hóa.
  • Tầng dữ liệu: Amazon RDS, Amazon DynamoDB và Amazon S3.

Kiến trúc microservice

Kiến trúc microservice chia một ứng dụng thành các dịch vụ nhỏ, độc lập và giao tiếp với nhau qua mạng. Cách tiếp cận này thúc đẩy liên kết lỏng lẻo, vì thay đổi ở một dịch vụ không nhất thiết yêu cầu thay đổi ở các dịch vụ khác.

Các dịch vụ AWS thường dùng trong kiến trúc microservice bao gồm:

  • Amazon API Gateway: Quản lý yêu cầu API và định tuyến chúng đến các microservice phù hợp.
  • AWS Lambda: Cung cấp điện toán phi máy chủ để chạy từng hàm riêng lẻ, thường được dùng để triển khai microservice.
  • Amazon ECS/EKS: Điều phối container để triển khai và quản lý microservice.
  • Amazon SQS/SNS: Cung cấp dịch vụ nhắn tin cho giao tiếp bất đồng bộ giữa các microservice.

Kiến trúc hướng sự kiện

Kiến trúc hướng sự kiện sử dụng sự kiện để kích hoạt hành động ở các phần khác nhau của hệ thống. Các dịch vụ giao tiếp bằng cách tạo và tiêu thụ sự kiện, thay vì giao tiếp trực tiếp theo kiểu điểm-đến-điểm.

Cách này giúp cải thiện đáng kể liên kết lỏng lẻo và khả năng mở rộng. Nói vui một chút, thay vì dịch vụ A phải gọi thẳng dịch vụ B và đứng chờ, dịch vụ A chỉ cần “phát tín hiệu”, còn ai cần thì tự xử lý.

Các dịch vụ AWS thường dùng trong kiến trúc hướng sự kiện bao gồm:

  • Amazon SQS (Simple Queue Service): Dịch vụ hàng đợi tin nhắn giúp tách rời producer và consumer.
  • Amazon SNS (Simple Notification Service): Dịch vụ nhắn tin pub/sub để phát sự kiện đến nhiều subscriber.
  • Amazon EventBridge: Event bus phi máy chủ giúp xây dựng ứng dụng hướng sự kiện dễ hơn.
  • AWS Lambda: Được dùng để xử lý sự kiện.

Xác định chiến lược mở rộng cho các thành phần được sử dụng trong thiết kế kiến trúc

Mở rộng là khả năng của một hệ thống trong việc xử lý tải tăng lên. Có hai loại mở rộng chính:

Mở rộng theo chiều dọc (scale up)

Mở rộng theo chiều dọc là tăng tài nguyên của một phiên bản đơn lẻ, chẳng hạn như CPU, bộ nhớ hoặc lưu trữ.

Cách này có giới hạn, vì luôn có kích thước tối đa cho một phiên bản đơn lẻ. Trong AWS, điều này thường có nghĩa là chọn loại phiên bản EC2 lớn hơn.

Mở rộng theo chiều ngang (scale out)

Mở rộng theo chiều ngang là thêm nhiều phiên bản hơn để xử lý tải. Cách này nhìn chung được ưu tiên cho ứng dụng đám mây, vì nó cung cấp khả năng chịu lỗi và khả năng mở rộng tốt hơn.

AWS cung cấp một số dịch vụ để hỗ trợ mở rộng theo chiều ngang:

  • Elastic Load Balancing (ELB): Phân phối lưu lượng qua nhiều phiên bản.
  • Auto Scaling: Tự động thêm hoặc xóa phiên bản dựa trên nhu cầu.
  • Amazon ECS/EKS: Điều phối container trên nhiều phiên bản.

Chiến lược mở rộng cho các thành phần khác nhau

Điện toán (EC2, Lambda, container): Sử dụng Auto Scaling để tự động điều chỉnh số lượng phiên bản dựa trên các chỉ số như mức sử dụng CPU, mức sử dụng bộ nhớ hoặc số lượng yêu cầu.

Cơ sở dữ liệu (RDS, DynamoDB):

  • RDS: Hỗ trợ read replica để mở rộng thao tác đọc. Bạn cũng có thể scale up kích thước phiên bản để tăng hiệu năng.
  • DynamoDB: Tự động mở rộng dựa trên dung lượng provisioned hoặc on-demand.

Hàng đợi tin nhắn (SQS): SQS tự động mở rộng để xử lý mọi khối lượng tin nhắn.

Bộ nhớ đệm (ElastiCache): Có thể mở rộng bằng cách thêm nhiều cache node hơn hoặc chọn loại cache node lớn hơn.

Các điểm cân nhắc chính khi thiết kế kiến trúc có khả năng mở rộng và liên kết lỏng lẻo

  • Liên kết lỏng lẻo: Giảm thiểu phụ thuộc giữa các thành phần để cải thiện tính linh hoạt và khả năng phục hồi.
  • Không lưu trạng thái: Thiết kế các thành phần stateless bất cứ khi nào có thể, vì điều này giúp mở rộng theo chiều ngang dễ hơn.
  • Tự động hóa: Sử dụng công cụ tự động hóa như Auto Scaling và CloudFormation để quản lý hạ tầng và triển khai.
  • Giám sát: Triển khai giám sát và ghi log mạnh để theo dõi hiệu năng và xác định điểm nghẽn.

Xác định các dịch vụ AWS cần thiết để đạt liên kết lỏng lẻo dựa trên yêu cầu

Liên kết lỏng lẻo nghĩa là các thành phần của hệ thống độc lập với nhau. Khi một thành phần thay đổi, tác động đến các thành phần khác sẽ được giảm thiểu. Điều này có thể đạt được thông qua nhiều kỹ thuật và dịch vụ AWS.

Hàng đợi tin nhắn (Amazon SQS – Simple Queue Service): SQS cho phép ứng dụng giao tiếp bất đồng bộ bằng cách gửi tin nhắn vào hàng đợi. Điều này tách rời bên gửi và bên nhận, vì chúng không cần online cùng lúc. Nếu bên nhận chưa khả dụng, tin nhắn sẽ được lưu trong hàng đợi cho đến khi bên nhận sẵn sàng xử lý.

Topic và Subscription (Amazon SNS – Simple Notification Service): SNS cho phép nhắn tin theo mô hình publish/subscribe. Publisher gửi tin nhắn đến một topic, và nhiều subscriber có thể nhận thông báo. Điều này tách rời publisher khỏi subscriber, giúp kiến trúc hướng sự kiện linh hoạt và có khả năng mở rộng hơn.

Kiến trúc hướng sự kiện (Amazon EventBridge): EventBridge là event bus phi máy chủ, giúp dễ xây dựng ứng dụng hướng sự kiện ở quy mô lớn. Nó nhận sự kiện từ nhiều nguồn khác nhau, bao gồm dịch vụ AWS, ứng dụng tùy chỉnh và ứng dụng SaaS, sau đó định tuyến chúng đến các target như hàm AWS Lambda hoặc hàng đợi Amazon SQS. Điều này giúp các hệ thống được tách rời tốt hơn và phản hồi nhanh hơn.

API và API Gateway (Amazon API Gateway): API Gateway hoạt động như “cửa trước” để ứng dụng truy cập dịch vụ backend. Nó tách rời frontend khỏi backend bằng cách cung cấp một giao diện nhất quán. Nhờ đó, dịch vụ backend có thể phát triển độc lập mà không ảnh hưởng nhiều đến frontend.

Microservices: Mặc dù microservice không phải là một dịch vụ AWS cụ thể, đây là mẫu kiến trúc thúc đẩy mạnh mẽ liên kết lỏng lẻo. Mỗi microservice là một đơn vị chức năng nhỏ, độc lập và giao tiếp với các microservice khác thông qua API. AWS cung cấp nhiều dịch vụ để hỗ trợ microservice, chẳng hạn như Amazon ECS, Amazon EKS và AWS Lambda.

Xác định khi nào nên sử dụng container

Container cung cấp một cách nhẹ và linh hoạt để đóng gói cũng như chạy ứng dụng. Chúng đặc biệt hữu ích trong các kịch bản sau:

  • Cần tính di động của ứng dụng: Container có thể chạy nhất quán trên nhiều môi trường khác nhau, chẳng hạn như phát triển, kiểm thử và sản xuất.
  • Đang triển khai microservice: Container rất phù hợp để triển khai và quản lý microservice.
  • Cần môi trường runtime nhất quán: Container bảo đảm ứng dụng có cùng dependency và cấu hình, bất kể hạ tầng bên dưới là gì.
  • Cần tối ưu mức sử dụng tài nguyên: Container chia sẻ kernel của hệ điều hành host, giúp chúng hiệu quả hơn máy ảo.

AWS cung cấp một số dịch vụ container:

Amazon ECS (Elastic Container Service): Dịch vụ điều phối container được quản lý hoàn toàn, hỗ trợ Docker container.

Amazon EKS (Elastic Kubernetes Service): Dịch vụ Kubernetes được quản lý, giúp dễ dàng chạy Kubernetes trên AWS.

AWS Fargate: Công cụ điện toán phi máy chủ cho container, loại bỏ nhu cầu quản lý phiên bản EC2.

Xác định khi nào nên sử dụng công nghệ và mẫu phi máy chủ

Điện toán phi máy chủ cho phép bạn chạy mã mà không cần cung cấp hoặc quản lý máy chủ. Điều này mang lại một số lợi ích:

  • Tự động mở rộng: Các dịch vụ phi máy chủ tự động mở rộng dựa trên nhu cầu.
  • Tính phí theo mức sử dụng: Bạn chỉ trả tiền cho thời gian điện toán mà bạn thực sự tiêu thụ.
  • Giảm chi phí vận hành: Bạn không cần quản lý máy chủ, hệ điều hành hoặc việc vá lỗi.

Các dịch vụ và mẫu phi máy chủ AWS chính bao gồm:

AWS Lambda: Dịch vụ điện toán cho phép bạn chạy mã mà không cần cung cấp hoặc quản lý máy chủ. Hàm Lambda được kích hoạt bởi sự kiện từ nhiều nguồn khác nhau.

Amazon API Gateway: Như đã đề cập trước đó, API Gateway có thể được dùng để tạo API phi máy chủ kích hoạt hàm Lambda.

Amazon S3 (Simple Storage Service): Lưu trữ đối tượng có thể được dùng để lưu nội dung website tĩnh hoặc kích hoạt hàm Lambda khi upload object.

Kiến trúc hướng sự kiện: Serverless phù hợp tự nhiên với kiến trúc hướng sự kiện, nơi hàm Lambda được kích hoạt bởi sự kiện từ các dịch vụ như S3, DynamoDB và SNS.

Các điểm cân nhắc chính cho liên kết lỏng lẻo, container và serverless

  • Đánh đổi: Mặc dù liên kết lỏng lẻo mang lại nhiều lợi ích, nó có thể làm tăng độ phức tạp trong giao tiếp giữa các dịch vụ và truy vết phân tán.
  • Giám sát và khả năng quan sát: Điều rất quan trọng là phải có công cụ giám sát và quan sát mạnh để hiểu hành vi của các hệ thống phân tán.
  • Tối ưu chi phí: Mặc dù serverless có thể hiệu quả về chi phí, bạn vẫn cần hiểu mô hình giá và tối ưu mã về hiệu năng.

Đề xuất công nghệ điện toán, lưu trữ, mạng và cơ sở dữ liệu phù hợp dựa trên yêu cầu

Chọn đúng dịch vụ AWS cho ứng dụng là điều rất quan trọng để đạt khả năng mở rộng và liên kết lỏng lẻo. Dưới đây là cách tiếp cận theo từng nhóm công nghệ.

Điện toán

Amazon EC2 (Elastic Compute Cloud): Cung cấp máy chủ ảo trên đám mây với nhiều loại phiên bản được tối ưu cho các khối lượng công việc khác nhau, chẳng hạn như workload cần nhiều điện toán hoặc cần nhiều bộ nhớ. Có thể sử dụng Auto Scaling để tự động điều chỉnh số lượng phiên bản EC2 dựa trên nhu cầu.

AWS Lambda: Dịch vụ điện toán phi máy chủ cho phép bạn chạy mã mà không cần cung cấp hoặc quản lý máy chủ. Lambda tự động mở rộng và rất phù hợp cho ứng dụng hướng sự kiện cũng như microservice.

Amazon ECS (Elastic Container Service) và Amazon EKS (Elastic Kubernetes Service): Đây là các dịch vụ điều phối container, cho phép bạn chạy và quản lý Docker container ở quy mô lớn. ECS là dịch vụ điều phối container riêng của AWS, trong khi EKS cho phép bạn chạy Kubernetes trên AWS.

Lưu trữ

Amazon S3 (Simple Storage Service): Dịch vụ lưu trữ đối tượng để lưu và truy xuất bất kỳ lượng dữ liệu nào. S3 có khả năng mở rộng cao, bền vững và hiệu quả về chi phí, phù hợp với nhiều trường hợp sử dụng như sao lưu, lưu trữ phương tiện và data lake.

Amazon EBS (Elastic Block Storage): Cung cấp volume lưu trữ khối để sử dụng với phiên bản EC2. EBS cung cấp lưu trữ bền vững có thể gắn vào phiên bản EC2 như một ổ cứng ảo.

Amazon EFS (Elastic File System): Cung cấp hệ thống tệp mạng có thể được chia sẻ bởi nhiều phiên bản EC2. EFS phù hợp với các ứng dụng cần lưu trữ tệp dùng chung, chẳng hạn như hệ thống quản lý nội dung và ứng dụng web.

Mạng

Amazon VPC (Virtual Private Cloud): Cho phép bạn tạo mạng cô lập trong AWS Cloud. VPC giúp bạn kiểm soát cấu hình mạng, bao gồm dải địa chỉ IP, subnet và route table.

Elastic Load Balancing: Phân phối lưu lượng đến qua nhiều target, chẳng hạn như phiên bản EC2, container và địa chỉ IP. Cân bằng tải giúp cải thiện tính sẵn sàng và khả năng mở rộng của ứng dụng.

Amazon Route 53: Dịch vụ web DNS có tính sẵn sàng và khả năng mở rộng cao. Route 53 có thể được dùng để định tuyến lưu lượng đến ứng dụng dựa trên nhiều tiêu chí khác nhau, chẳng hạn như độ trễ, địa lý và health check.

Cơ sở dữ liệu

Amazon RDS (Relational Database Service): Dịch vụ cơ sở dữ liệu quan hệ được quản lý, hỗ trợ nhiều database engine khác nhau, bao gồm MySQL, PostgreSQL, Oracle, SQL Server và MariaDB. RDS giúp đơn giản hóa việc quản trị cơ sở dữ liệu và cung cấp sao lưu, vá lỗi cũng như mở rộng tự động.

Amazon DynamoDB: Dịch vụ cơ sở dữ liệu NoSQL cung cấp hiệu năng nhanh và có thể dự đoán ở mọi quy mô. DynamoDB phù hợp với các ứng dụng yêu cầu thông lượng cao và độ trễ thấp, chẳng hạn như game, mobile và ứng dụng web.

Amazon Aurora: Dịch vụ cơ sở dữ liệu quan hệ tương thích với MySQL và PostgreSQL, kết hợp hiệu năng và tính sẵn sàng của cơ sở dữ liệu cấp thương mại với sự đơn giản và hiệu quả chi phí của cơ sở dữ liệu mã nguồn mở.

Sử dụng các dịch vụ AWS chuyên biệt cho workload

AWS cung cấp một loạt dịch vụ được thiết kế cho các trường hợp sử dụng cụ thể. Sử dụng các dịch vụ chuyên biệt này có thể cải thiện đáng kể hiệu năng, khả năng mở rộng và hiệu quả chi phí.

Dưới đây là một số ví dụ:

Amazon SQS (Simple Queue Service): Dịch vụ hàng đợi tin nhắn cho phép bạn tách rời các thành phần ứng dụng. SQS cho phép bạn gửi, lưu trữ và nhận tin nhắn giữa các phần khác nhau của ứng dụng, từ đó cải thiện khả năng mở rộng và khả năng chịu lỗi.

Amazon SNS (Simple Notification Service): Dịch vụ nhắn tin pub/sub cho phép bạn gửi thông báo đến nhiều subscriber khác nhau, chẳng hạn như địa chỉ email, thiết bị di động và các dịch vụ AWS khác. SNS phù hợp để xây dựng kiến trúc hướng sự kiện và gửi thông báo theo thời gian thực.

AWS Step Functions: Dịch vụ điều phối phi máy chủ cho phép bạn phối hợp nhiều dịch vụ AWS thành các workflow phi máy chủ. Step Functions giúp đơn giản hóa việc phát triển ứng dụng phức tạp bằng cách cung cấp trình thiết kế workflow trực quan và khả năng xử lý lỗi tích hợp.

Amazon ElastiCache: Dịch vụ cache giúp cải thiện hiệu năng ứng dụng bằng cách lưu dữ liệu được truy cập thường xuyên trong bộ nhớ. ElastiCache hỗ trợ các caching engine như Redis và Memcached.

Bằng cách lựa chọn và tích hợp cẩn thận các dịch vụ này, bạn có thể tạo kiến trúc có khả năng mở rộng cao, liên kết lỏng lẻo và được tối ưu cho các yêu cầu workload cụ thể của mình.

Các điểm chính cần ghi nhớ

  • Liên kết lỏng lẻo: Thiết kế hệ thống trong đó các thành phần độc lập và giao tiếp thông qua giao diện được định nghĩa rõ ràng. Điều này cải thiện khả năng chịu lỗi và cho phép mở rộng cũng như triển khai độc lập.
  • Khả năng mở rộng: Thiết kế hệ thống có thể xử lý lưu lượng và khối lượng dữ liệu tăng lên. Điều này liên quan đến việc sử dụng các dịch vụ có thể tự động mở rộng dựa trên nhu cầu.
  • Dịch vụ chuyên biệt: Tận dụng các dịch vụ AWS được thiết kế cho các trường hợp sử dụng cụ thể để cải thiện hiệu năng, khả năng mở rộng và hiệu quả chi phí.

2.2. Thiết kế kiến trúc có tính sẵn sàng cao và/hoặc khả năng chịu lỗi

Xác định chiến lược tự động hóa để bảo đảm tính toàn vẹn của hạ tầng

Tự động hóa rất quan trọng để duy trì tính toàn vẹn của hạ tầng và bảo đảm việc triển khai diễn ra nhất quán. Nó giúp giảm lỗi do con người, cải thiện tốc độ và hiệu quả, đồng thời hỗ trợ khả năng tự phục hồi.

Các chiến lược tự động hóa chính bao gồm:

Infrastructure as Code (IaC): Sử dụng các công cụ như AWS CloudFormation, AWS CDK (Cloud Development Kit) hoặc Terraform để định nghĩa và quản lý hạ tầng thông qua mã. Điều này cho phép bạn kiểm soát phiên bản hạ tầng, tự động hóa triển khai và dễ dàng sao chép môi trường.

Quản lý cấu hình: Sử dụng các công cụ như AWS Systems Manager, Ansible hoặc Chef để tự động hóa cấu hình và quản lý máy chủ cũng như các tài nguyên khác. Điều này bảo đảm cấu hình nhất quán trên toàn hạ tầng và đơn giản hóa việc vá lỗi cũng như cập nhật.

Triển khai tự động: Sử dụng các dịch vụ như AWS CodeDeploy hoặc AWS CodePipeline để tự động hóa việc triển khai ứng dụng lên hạ tầng của bạn. Điều này giúp giảm thời gian triển khai và giảm thiểu rủi ro lỗi.

Giám sát và cảnh báo tự động: Sử dụng các dịch vụ như Amazon CloudWatch để giám sát sức khỏe và hiệu năng của hạ tầng cũng như ứng dụng. Bạn có thể thiết lập cảnh báo để được thông báo về các vấn đề tiềm ẩn và thực hiện hành động khắc phục kịp thời.

Khôi phục tự động: Triển khai các cơ chế khôi phục tự động, chẳng hạn như auto scaling và failover tự động, để bảo đảm ứng dụng có thể tự phục hồi sau lỗi. Đây là kiểu “té thì tự đứng dậy”, thay vì phải đợi người vận hành chạy vào cứu.

Xác định các dịch vụ AWS cần thiết để cung cấp kiến trúc có tính sẵn sàng cao và/hoặc khả năng chịu lỗi trên các AWS Region hoặc Availability Zone

AWS cung cấp nhiều dịch vụ có thể được sử dụng để xây dựng kiến trúc có tính sẵn sàng cao và khả năng chịu lỗi:

Availability Zones (AZs): Đây là các vị trí riêng biệt trong một AWS Region, được thiết kế để cô lập khỏi lỗi ở các AZ khác. Triển khai ứng dụng trên nhiều AZ giúp ứng dụng có thể tiếp tục hoạt động ngay cả khi một AZ bị lỗi.

Elastic Load Balancing (ELB): Phân phối lưu lượng đến qua nhiều phiên bản, từ đó cải thiện tính sẵn sàng và khả năng chịu lỗi. ELB có nhiều loại, bao gồm Application Load Balancer (ALB), Network Load Balancer (NLB) và Classic Load Balancer (CLB).

Auto Scaling: Tự động điều chỉnh số lượng phiên bản dựa trên nhu cầu, bảo đảm ứng dụng có thể xử lý tải lưu lượng thay đổi và khôi phục sau lỗi phiên bản.

Amazon S3 (Simple Storage Service): Cung cấp lưu trữ đối tượng có độ bền và tính sẵn sàng cao. S3 cung cấp nhiều lớp lưu trữ với các mức tính sẵn sàng và độ bền khác nhau.

Amazon RDS (Relational Database Service): Cung cấp cơ sở dữ liệu quan hệ được quản lý với các tính năng tính sẵn sàng cao và khả năng chịu lỗi tích hợp, chẳng hạn như triển khai Multi-AZ.

Amazon DynamoDB: Dịch vụ cơ sở dữ liệu NoSQL được quản lý hoàn toàn, cung cấp tính sẵn sàng cao và khả năng mở rộng.

Route 53: Dịch vụ DNS của AWS, có thể được dùng để định tuyến lưu lượng đến các phiên bản khỏe mạnh và thực hiện health check.

Chiến lược cho tính sẵn sàng cao và khả năng chịu lỗi

  • Dự phòng: Triển khai nhiều phiên bản của ứng dụng trên các AZ khác nhau.
  • Failover: Triển khai cơ chế tự động chuyển lưu lượng sang các phiên bản khỏe mạnh khi xảy ra lỗi.
  • Health Check: Thường xuyên giám sát sức khỏe của phiên bản và tự động loại bỏ phiên bản không khỏe khỏi dịch vụ.
  • Ứng dụng stateless: Thiết kế ứng dụng không lưu trạng thái phiên cục bộ, giúp dễ mở rộng và khôi phục sau lỗi hơn.
  • Sao chép dữ liệu: Sao chép dữ liệu qua nhiều AZ hoặc Region để bảo đảm dữ liệu vẫn khả dụng khi xảy ra lỗi.

Xác định chỉ số dựa trên yêu cầu kinh doanh để cung cấp giải pháp có tính sẵn sàng cao

Định nghĩa chỉ số rõ ràng là điều thiết yếu để đo lường thành công của các chiến lược tính sẵn sàng cao và khả năng chịu lỗi. Các chỉ số này nên dựa trên yêu cầu kinh doanh và thỏa thuận mức dịch vụ (SLA).

Các chỉ số chính bao gồm:

Mục tiêu thời gian khôi phục (RTO): Khoảng thời gian tối đa có thể chấp nhận để một ứng dụng không khả dụng sau khi xảy ra lỗi.

Mục tiêu điểm khôi phục (RPO): Lượng dữ liệu tối đa có thể chấp nhận bị mất trong trường hợp xảy ra lỗi.

Tính sẵn sàng: Phần trăm thời gian mà ứng dụng khả dụng để sử dụng.

Thời gian trung bình giữa các lần lỗi (MTBF): Thời gian trung bình giữa các lần lỗi của một hệ thống.

Thời gian trung bình để khôi phục (MTTR): Thời gian trung bình cần để khôi phục sau lỗi.

Triển khai thiết kế để giảm thiểu điểm lỗi đơn

Điểm lỗi đơn (SPOF) là bất kỳ thành phần nào mà khi nó lỗi có thể khiến toàn bộ hệ thống lỗi. Loại bỏ SPOF là điều rất quan trọng để xây dựng các hệ thống có tính sẵn sàng cao và khả năng chịu lỗi.

Dưới đây là một số chiến lược chính:

Dự phòng

Triển khai dự phòng ở mọi cấp trong kiến trúc. Điều này bao gồm:

Nhiều Availability Zone (AZ): Triển khai ứng dụng và dữ liệu của bạn trên nhiều AZ trong một AWS Region. AZ là các trung tâm dữ liệu tách biệt vật lý, có nguồn điện, hệ thống làm mát và mạng độc lập. Nếu một AZ bị lỗi, ứng dụng của bạn vẫn có thể tiếp tục chạy ở các AZ khác.

Cân bằng tải: Phân phối lưu lượng qua nhiều phiên bản ứng dụng bằng load balancer. Điều này bảo đảm nếu một phiên bản lỗi, lưu lượng sẽ tự động được chuyển hướng đến các phiên bản khỏe mạnh còn lại. AWS cung cấp nhiều loại load balancer khác nhau, bao gồm Application Load Balancer, Network Load Balancer và Classic Load Balancer.

Sao chép: Sao chép dữ liệu của bạn qua nhiều vị trí lưu trữ. Điều này bảo đảm nếu một vị trí lưu trữ bị lỗi, dữ liệu của bạn vẫn khả dụng. AWS cung cấp nhiều tùy chọn sao chép cho các dịch vụ lưu trữ khác nhau, chẳng hạn như sao chép liên vùng Amazon S3 và triển khai Amazon RDS Multi-AZ.

Auto Scaling: Tự động điều chỉnh số lượng phiên bản đang chạy ứng dụng dựa trên nhu cầu. Điều này bảo đảm bạn có đủ dung lượng để xử lý các đợt tăng lưu lượng và ứng dụng có thể tự động khôi phục sau lỗi phiên bản.

Ứng dụng stateless: Thiết kế ứng dụng của bạn theo hướng stateless. Điều này nghĩa là dữ liệu ứng dụng không được lưu trên chính các phiên bản, mà được lưu ở một kho dữ liệu riêng biệt. Cách này giúp dễ mở rộng và thay thế phiên bản mà không làm mất dữ liệu.

Triển khai chiến lược để bảo đảm độ bền và tính sẵn sàng của dữ liệu

Độ bền dữ liệu đề cập đến khả năng lưu trữ dữ liệu một cách đáng tin cậy trong dài hạn. Trong khi đó, tính sẵn sàng của dữ liệu đề cập đến khả năng truy cập dữ liệu khi cần.

Dưới đây là một số chiến lược chính:

Sao lưu: Thường xuyên sao lưu dữ liệu để bảo vệ khỏi mất dữ liệu do xóa nhầm, lỗi phần cứng hoặc các sự kiện khác. AWS cung cấp nhiều dịch vụ sao lưu khác nhau, chẳng hạn như AWS Backup và Amazon S3 lifecycle policy.

Snapshot: Tạo snapshot cho volume dữ liệu hoặc cơ sở dữ liệu. Snapshot là bản sao dữ liệu tại một thời điểm, có thể được dùng để khôi phục dữ liệu về trạng thái trước đó.

RAID (Redundant Array of Independent Disks): Sử dụng cấu hình RAID để cải thiện tính sẵn sàng và hiệu năng dữ liệu. AWS cung cấp nhiều tùy chọn RAID cho phiên bản Amazon EC2.

Dịch vụ lưu trữ có độ bền và tính sẵn sàng tích hợp: Sử dụng các dịch vụ lưu trữ AWS cung cấp độ bền và tính sẵn sàng tích hợp, chẳng hạn như Amazon S3, Amazon EBS và Amazon RDS. Các dịch vụ này được thiết kế để chịu lỗi và bảo đảm dữ liệu của bạn luôn khả dụng.

Chọn chiến lược DR phù hợp để đáp ứng yêu cầu kinh doanh

Lập kế hoạch khôi phục sau thảm họa (DR) liên quan đến việc chuẩn bị và khôi phục sau các gián đoạn lớn có thể ảnh hưởng đến hạ tầng CNTT của bạn.

AWS cung cấp nhiều chiến lược DR, mỗi chiến lược có mục tiêu thời gian khôi phục (RTO) và mục tiêu điểm khôi phục (RPO) khác nhau:

Backup and Restore: Đây là chiến lược DR đơn giản nhất. Bạn sao lưu dữ liệu và khôi phục dữ liệu sang một môi trường mới khi xảy ra thảm họa. Chiến lược này có RTO và RPO dài hơn so với các chiến lược khác.

Pilot Light: Trong chiến lược này, bạn duy trì một phiên bản tối thiểu của môi trường ở một Region khác. Môi trường này bao gồm các dịch vụ cốt lõi như cơ sở dữ liệu và mạng. Khi xảy ra thảm họa, bạn mở rộng môi trường pilot light lên đầy đủ công suất.

Warm Standby: Trong chiến lược này, bạn duy trì một phiên bản đầy đủ chức năng nhưng thu nhỏ của môi trường ở một Region khác. Môi trường này luôn chạy và sẵn sàng tiếp quản khi xảy ra thảm họa.

Multi-Region Active/Active: Trong chiến lược này, bạn chạy ứng dụng ở nhiều Region đồng thời. Lưu lượng được phân phối qua các Region, và nếu một Region lỗi, lưu lượng sẽ tự động được chuyển hướng đến các Region khác. Chiến lược này cung cấp RTO và RPO thấp nhất.

Sử dụng các dịch vụ AWS cải thiện độ tin cậy của ứng dụng legacy và ứng dụng không được xây dựng cho đám mây

Nhiều tổ chức có các ứng dụng hiện có vốn không được thiết kế cho đám mây. Di chuyển các ứng dụng này lên AWS có thể khó khăn, đặc biệt nếu việc thay đổi mã là khó hoặc không thể.

AWS cung cấp một số dịch vụ có thể giúp cải thiện độ tin cậy của các ứng dụng legacy này mà không yêu cầu sửa đổi mã đáng kể:

Amazon EC2 Auto Scaling: Dịch vụ này cho phép bạn tự động mở rộng số lượng phiên bản EC2 dựa trên nhu cầu hoặc health check. Nếu một phiên bản lỗi, Auto Scaling có thể tự động khởi chạy một phiên bản mới để thay thế, từ đó cải thiện tính sẵn sàng. Điều này hữu ích cho các ứng dụng legacy chưa có khả năng mở rộng tích hợp.

Elastic Load Balancing (ELB): ELB phân phối lưu lượng đến qua nhiều phiên bản EC2, giúp cải thiện tính sẵn sàng và khả năng chịu lỗi. Nếu một phiên bản lỗi, ELB sẽ tự động ngừng gửi lưu lượng đến phiên bản đó. Điều này có lợi cho các ứng dụng legacy chưa có cơ chế cân bằng tải riêng.

Amazon Route 53: Đây là dịch vụ web DNS có tính sẵn sàng và khả năng mở rộng cao. Bạn có thể sử dụng Route 53 để định tuyến lưu lượng đến các phiên bản khỏe mạnh hoặc đến các Region khác khi xảy ra sự cố cấp Region. Điều này giúp cải thiện tính sẵn sàng của ứng dụng legacy bằng cách cung cấp khả năng DNS failover.

AWS Application Discovery Service: Dịch vụ này giúp bạn thu thập thông tin về máy chủ và ứng dụng on-premises, từ đó dễ lập kế hoạch di chuyển lên AWS hơn. Điều này hữu ích để hiểu các phụ thuộc và yêu cầu của ứng dụng legacy.

Sử dụng các dịch vụ AWS chuyên biệt cho workload

AWS cung cấp nhiều dịch vụ được thiết kế cho các loại workload cụ thể. Sử dụng các dịch vụ này có thể cải thiện đáng kể độ tin cậy, khả năng mở rộng và hiệu năng của ứng dụng:

Amazon S3 (Simple Storage Service): Đây là dịch vụ lưu trữ đối tượng có độ bền cao và khả năng mở rộng cao. S3 cung cấp nhiều lớp lưu trữ cho các trường hợp sử dụng khác nhau, bao gồm truy cập thường xuyên, truy cập không thường xuyên và lưu trữ dài hạn. S3 được thiết kế cho độ bền dữ liệu 99.999999999% (11 số 9), khiến nó rất phù hợp để lưu trữ dữ liệu quan trọng.

Amazon RDS (Relational Database Service): Đây là dịch vụ cơ sở dữ liệu được quản lý, hỗ trợ nhiều database engine khác nhau, bao gồm MySQL, PostgreSQL, Oracle, SQL Server và MariaDB. RDS cung cấp các tính năng như triển khai Multi-AZ cho tính sẵn sàng cao và read replica để cải thiện hiệu năng đọc.

Amazon DynamoDB: Đây là dịch vụ cơ sở dữ liệu NoSQL được quản lý hoàn toàn, cung cấp hiệu năng nhanh và có thể dự đoán với khả năng mở rộng liền mạch. DynamoDB phù hợp với các ứng dụng yêu cầu độ trễ thấp và thông lượng cao.

AWS Lambda: Đây là dịch vụ điện toán phi máy chủ cho phép bạn chạy mã mà không cần cung cấp hoặc quản lý máy chủ. Lambda tự động mở rộng mã của bạn dựa trên nhu cầu, giúp dịch vụ này có tính sẵn sàng cao và khả năng chịu lỗi.

Amazon SQS (Simple Queue Service): Đây là dịch vụ hàng đợi tin nhắn được quản lý hoàn toàn, cho phép bạn tách rời và mở rộng microservice, hệ thống phân tán và ứng dụng phi máy chủ. SQS giúp cải thiện độ tin cậy của ứng dụng bằng cách đệm tin nhắn và bảo đảm chúng được gửi ngay cả khi một số thành phần bị lỗi.

Các khái niệm chính khi thiết kế kiến trúc có tính sẵn sàng cao và khả năng chịu lỗi

Dự phòng: Điều này liên quan đến việc có nhiều bản sao tài nguyên của bạn, chẳng hạn như phiên bản EC2, cơ sở dữ liệu và dữ liệu. Dự phòng bảo đảm ứng dụng có thể tiếp tục hoạt động ngay cả khi một hoặc nhiều tài nguyên lỗi.

Availability Zones (AZs): Đây là các vị trí riêng biệt trong một AWS Region, được thiết kế để cô lập với nhau. Triển khai ứng dụng trên nhiều AZ có thể bảo vệ ứng dụng khỏi lỗi trong một AZ đơn lẻ.

Regions: Đây là các khu vực địa lý chứa nhiều AZ. Triển khai ứng dụng trên nhiều Region có thể bảo vệ ứng dụng khỏi sự cố cấp Region.

Failover: Đây là quá trình tự động chuyển sang một tài nguyên dự phòng khi xảy ra lỗi.

Mục tiêu thời gian khôi phục (RTO): Đây là khoảng thời gian tối đa có thể chấp nhận để một ứng dụng không khả dụng sau khi xảy ra lỗi.

Mục tiêu điểm khôi phục (RPO): Đây là lượng dữ liệu tối đa có thể chấp nhận bị mất trong trường hợp xảy ra lỗi.