Bài viết này được viết bởi Adrian Hornsby (Kỹ sư Phát triển Hệ thống Chính) và Marcia Villalba (Chuyên gia phát triển sản phẩm chính) của AWS.

AWS Lambda gồm hơn 80 dịch vụ hoạt động cùng nhau để cung cấp dịch vụ tính toán serverless cho khách hàng. Under the hood, nhiều trong các dịch vụ này được xây dựng trên các instance của Amazon Elastic Compute Cloud (Amazon EC2), được cung cấp trong các Khu vực Khả dụng. Tuy nhiên, AWS Lambda là một dịch vụ khu vực. Điều này có nghĩa là khách hàng sử dụng dịch vụ Lambda ở cấp độ khu vực và các dịch vụ của nó được thiết kế để đảm bảo độ tin cậy cao trong trường hợp xảy ra sự cố với các Khu vực Khả dụng bên dưới.

Bài đăng blog này sẽ thảo luận về cách một dịch vụ khu vực như Lambda tận dụng Khu vực Khả dụng và tính ổn định tĩnh để đạt được mục tiêu độ tin cậy cao, và cho thấy cách đội ngũ Lambda xác minh tính ổn định tĩnh của dịch vụ của họ bằng AWS Fault Injection Simulator (AWS FIS). Nó cũng cung cấp một giải pháp sử dụng các dịch vụ và công cụ của AWS để đạt được chiến lược bền vững của Lambda, bao gồm sử dụng FIS, Amazon CloudWatch và Amazon Route 53 Application Recovery Controller (Route 53 ARC).

Vai trò của Availability Zones

Availability Zones là các khu vực cô lập vật lý của một Khu vực AWS, được thiết kế để hoạt động nhưng cũng độc lập khi gặp sự cố. Chúng được phân tách bởi một khoảng cách đáng kể nhau, lên đến 100 km (60 dặm), để ngăn ngừa sự cố liên quan, nhưng đủ gần để sử dụng đồng bộ hóa sao lưu với độ trễ đơn vị mili giây.

Khách hàng và dịch vụ AWS đã sử dụng Availability Zones trong nhiều năm để xây dựng các ứng dụng có tính sẵn sàng cao, có khả năng chống lỗi và có khả năng mở rộng. Đặc biệt, các dịch vụ Khu vực AWS như AWS Lambda, Amazon DynamoDB, Amazon Simple Queue Service (Amazon SQS), và Amazon Simple Storage Service (Amazon S3), đã đạt được cam kết sẵn sàng cao bằng cách phân tán nhiều bản sao độc lập của dịch vụ của họ trên nhiều Availability Zones. Nó sử dụng các nguyên tắc độc lập và dự phòng của Availability Zones để tối đa hóa sẵn sàng tổng thể của dịch vụ đó.

Mỗi bản sao được gọi là bản sao của khu vực. Hệ thống được thiết kế sao cho bất kỳ bản sao nào cũng có thể bị lỗi bất kỳ lúc nào. Khi một bản sao bị lỗi, nó có thể được loại bỏ tạm thời khỏi hệ thống cho đến khi mọi thứ hoạt động như mong đợi trở lại. Khi điều đó xảy ra, tải được chia sẻ giữa các bản sao của các khu vực còn lại.

Thiết kế để xử lý lỗi

Một bài học mà chúng tôi học được tại AWS khi xây dựng các dịch vụ là khi xảy ra sự cố với một Availability Zone, nên không dựa vào các hoạt động của mặt phẳng điều khiển để khắc phục sự cố. Một hoạt động của mặt phẳng điều khiển có thể là cung cấp thêm năng lực trong một Availability Zone không bị ảnh hưởng bởi sự cố.

Nguyên tắc này được gọi là tính ổn định tĩnh, và mô tả khả năng của một hệ thống để giữ nguyên trạng thái ổn định ban đầu của nó (hoặc hành vi) ngay cả khi bị tác động bởi các sự kiện gây rối mà không cần phải thực hiện bất kỳ thay đổi nào. Một dịch vụ tĩnh ổn định nên có ít phụ thuộc nhất có thể vào quá trình khôi phục của nó.

Đối với một dịch vụ Khu vực như AWS Lambda, điều này có nghĩa là khả năng còn lại trong các Availability Zones khỏe mạnh có thể hấp thụ lưu lượng từ một Availability Zone có thể bị ảnh hưởng mà không cần phải mở rộng. Điều này ngụ ý về việc quá cấu hình tài nguyên trong tất cả các Availability Zones. Việc có khả năng dư thừa tài nguyên được tiên đoán sẵn giúp Lambda đạt được tính ổn định tĩnh. Đó là một sự đánh đổi giữa chi phí của việc quá cấu hình tài nguyên và khả năng sẵn có của dịch vụ. Vì AWS Lambda cam kết đem lại tính khả dụng cao cho khách hàng của mình, với cam kết dịch vụ thời gian hoạt động hàng tháng là 99,95%, sự đánh đổi đó hướng tới tính khả dụng của dịch vụ.

Cách chuẩn bị cho sự cố

Chuẩn bị cho sự cố ở Availability Zone là khó khăn vì các triệu chứng và quy mô tác động có thể khác nhau rộng rãi. Một Availability Zone có thể bị giới hạn phần nào hoặc không thể truy cập hoàn toàn, và tất cả những thứ nằm giữa hai trường hợp này. Nguyên nhân gây ra sự cố có thể là cắt cáp quang, sự cố về điện, quá nhiệt, sự cố phần cứng, vấn đề về mạng, vấn đề về khả năng chứa, và các tình huống bất ngờ khác. Trong khi những điều này xảy ra, chúng xảy ra hiếm khi. Các loại sự cố phổ biến nhất là triển khai không tốt và cấu hình không tốt.

Trong khi một số sự cố này có thể khó khăn để suy luận hoặc tái hiện, các triệu chứng thông thường bao gồm sự gián đoạn kết nối, độ trễ tăng, lưu lượng tăng do cơn bão thử lại, CPU và sử dụng bộ nhớ tăng và I / O chậm.

Tại AWS, chúng tôi đã học cách mong đợi những điều bất ngờ và lập kế hoạch cho sự cố. Điều này có nghĩa là tiêm các lỗi vào hệ thống để tái hiện một số triệu chứng thông thường của các vấn đề ở Availability Zone, sau đó quan sát cách hệ thống phản hồi và thực hiện cải tiến. Ngoài ra, việc tiêm lỗi vào hệ thống giúp phát hiện những điểm mù trong giám sát và cảnh báo tiềm ẩn và tạo cơ hội cho các nhóm thực hành và cải tiến phản ứng của họ đối với các sự kiện với mục tiêu giảm thời gian khôi phục.

Làm thế nào Lambda kiểm thử phản ứng của mình đối với sự cố vùng khả dụng bị ảnh hưởng

Phương pháp của Lambda để đảm bảo khả năng chống chọi với sự cố của Availability Zone là dựa trên tính ổn định tĩnh và hệ thống tự động. Con người chậm hơn máy móc trong việc phát hiện vấn đề và giải quyết chúng. Do đó, Lambda phải đảm bảo rằng các dịch vụ của mình có thể phát hiện vấn đề trong một bản sao khu vực và khắc phục tự động trong vòng vài phút mà không cần can thiệp của nhà vận hành. Sự khắc phục tự động này được thực hiện bằng cách dịch chuyển lưu lượng khách hàng từ Availability Zone bị ảnh hưởng sang các Availability Zone khác, và được gọi là di tản Availability Zone.

Để thực hiện điều này, Lambda xây dựng một công cụ để phát hiện sự cố và thực hiện di tản Availability Zone khi cần thiết. Công cụ này so sánh thống kê các chỉ số giữa các Availability Zone khác nhau và các EC2 instance để xác định Availability Zone bị không ổn định. Nếu phát hiện một Availability Zone gặp sự cố, công cụ sẽ tự động bắt đầu quá trình di tản khỏi Availability Zone bị ảnh hưởng. Sự tự động này giảm thời gian đến hành động đầu tiên từ 30 phút xuống dưới 3 phút.

AWS Lambda sử dụng AWS FIS như thế nào

Để đảm bảo rằng việc tự động hoạt động như mong đợi, Lambda thực hiện nhiều loại kiểm tra, bao gồm kiểm tra lỗi vùng khả dụng trong môi trường sản xuất của họ. Mục tiêu chính của các kiểm tra này là xác minh dịch vụ tĩnh và ổn định trong trường hợp có sự cố vùng khả dụng và xác minh rằng việc di dời khỏi Vùng khả dụng có thể được kích hoạt thành công. Lợi ích của việc thực hiện kiểm tra tự động là các nhóm có thể lặp lại nó thường xuyên và không cần kỹ năng đặc biệt. Chỉ cần một nhấp chuột là đủ để khởi chạy kiểm tra.

Để thực hiện các kiểm tra này, Lambda sử dụng AWS FIS để tiêm lỗi vào đại đội lớn các instance EC2 của họ. Họ sử dụng AWS FIS với sự hỗ trợ của AWS System Manager (SSM) agent và bộ lọc tài nguyên để nhắm mục tiêu đại đội EC2 instance của họ ở một vùng khả dụng cụ thể. Đây là một phương pháp linh hoạt có thể tiêm lỗi tài nguyên, chẳng hạn như quá tải CPU và bộ nhớ và lỗi mạng, chẳng hạn như độ trễ, mất kết nối hoặc thả gói tin.

Việc tiêm mất kết nối hoặc độ trễ là rất quan trọng, vì những triệu chứng này có thể ảnh hưởng nghiêm trọng đến hiệu suất ứng dụng và mạng. Thực sự, độ trễ và mất kết nối, ngay cả ở số lượng nhỏ, có thể tạo ra sự không hiệu quả và ngăn ứng dụng hoạt động tốt nhất của nó. Đối với Lambda, khả năng phát hiện độ trễ hoặc mất kết nối tăng là rất quan trọng để họ có thể giải quyết sự cố trước khi nó ảnh hưởng đến khách hàng.

Làm thế nào để phục hồi ứng dụng của bạn nhanh chóng sau khi có sự cố xảy ra với Availability Zone

Bạn có thể xây dựng một giải pháp tương tự để phục hồi nhanh chóng ứng dụng của bạn khi có sự cố xảy ra với một Availability Zone. Giải pháp này phải có cơ chế sơ tán khẩn cấp khỏi Availability Zone bị ảnh hưởng, một hệ thống giám sát cho phép bạn phát hiện khi một bản sao khu vực bị ảnh hưởng và một cách để kiểm tra tính ổn định tĩnh của hệ thống của bạn. AWS cung cấp nhiều công cụ và dịch vụ có thể giúp bạn xây dựng giải pháp này để đạt được chiến lược đàn hồi của Lambda.

Để thực hiện sơ tán Availability Zone, bạn có thể sử dụng tính năng zonal shift mới từ Route 53 ARC, đang trong phiên bản xem trước vào thời điểm viết bài. zonal shift cho phép bạn sơ tán một Availability Zone cho các ứng dụng sử dụng Elastic Load Balancing. Nếu bạn phát hiện ra một bản sao khu vực bị ảnh hưởng hoặc không khỏe mạnh, bạn có thể sử dụng zonal shift để sơ tán Availability Zone trong một khoảng thời gian, trong khi sự cố được sửa.

Để thực hiện zonal shift , bạn phải phát hiện khi một bản sao khu vực không khỏe mạnh. Ứng dụng của bạn phải cung cấp tín hiệu về sức khỏe của mình cho mỗi Availability Zone. Có hai cách thông thường để bắt tín hiệu này. Trong trường hợp chủ động, bạn có thể sử dụng giám sát tổng hợp, cho phép bạn tạo các yêu cầu tổng hợp chống lại ứng dụng sản xuất của bạn để cung cấp một cái nhìn tổng thể hơn về trải nghiệm khách hàng. Hoặc trong trường hợp thụ động, bạn có thể kiểm tra các chỉ số như thời gian phản hồi, mã trạng thái HTTP và các chỉ số khác có thể giúp theo dõi các lỗi nghiêm trọng trong ứng dụng của bạn.

Amazon CloudWatch Synthetics cung cấp các canary, đó là các script chạy định kỳ và thực hiện các yêu cầu tổng hợp trên các điểm cuối và API của ứng dụng của bạn. Canary thực hiện các hành động tương tự như khách hàng và liên tục xác minh trải nghiệm của khách hàng. Bạn có thể tạo một canary cho mỗi bản sao vùng của ứng dụng của mình và giám sát kết quả một cách độc lập.

Với thông tin này, nếu trải nghiệm người dùng giảm sút ở một trong các bản sao, bạn có thể bắt đầu một sự di dời của vùng sẵn có bằng cách sử dụng zonal shift và giảm thiểu trải nghiệm xấu cho người dùng trong khi bạn tìm và sửa các nguyên nhân của sự cố.

Để đảm bảo rằng bạn có thể khôi phục thành công sau một sự cố, bạn phải kiểm tra giải pháp trước. Mà không có kiểm tra thì đó chỉ là một giả định. Để chứng minh hoặc bác bỏ giả định của bạn về khả năng hệ thống của bạn xử lý các sự kiện gây khó chịu như sự cố trong một Vùng có sẵn, bạn có thể sử dụng FIS.

Với FIS, bạn có thể tiêm lỗi đồng thời vào nhiều tài nguyên trong cùng một miền sự cố, chẳng hạn như các Vùng có sẵn. FIS hiện tích hợp với một số dịch vụ AWS bao gồm EC2, Amazon Elastic Kubernetes Service (Amazon EKS), Amazon Elastic Container Service (Amazon ECS), Amazon Relational Database Service (Amazon RDS), AWS Networking và CloudWatch.

Các trường hợp sử dụng điển hình để kiểm tra khả năng chịu đựng của một ứng dụng khi có sự cố với các Khu vực khả dụng là, ví dụ như chấm dứt tất cả các nguồn tính toán và cơ sở dữ liệu trong một Khu vực khả dụng cụ thể, chèn độ trễ hoặc mất gói tin, tăng tiêu thụ tài nguyên (CPU, bộ nhớ và I/O) trên các nguồn tính toán trong một Khu vực khả dụng cụ thể, hoặc ảnh hưởng đến giao tiếp mạng trong hoặc giữa các Khu vực khả dụng.

Để biết thêm thông tin và một ví dụ từng bước về cách khôi phục nhanh chóng khỏi sự cố ứng dụng trong một Khu vực khả dụng đơn và kiểm tra nó với AWS FIS, hãy đọc bài đăng trên blog này.

Kết luận

Bài viết này trình bày về sự ổn định tĩnh, một cơ chế được sử dụng bởi các dịch vụ AWS như Lambda để xây dựng các dịch vụ khu vực bền vững. Nó cũng thảo luận về cách AWS tận dụng các dịch vụ và cơ sở hạ tầng giống như khách hàng. Nó cho thấy cách Lambda sử dụng nhiều Khu vực Khả dụng và các dịch vụ như AWS FIS để xây dựng các dịch vụ có sẵn cao và cải thiện thời gian phục hồi của nó từ các lỗi không mong đợi chỉ trong vài phút mà không cần sự can thiệp của con người. Cuối cùng, nó cho thấy một giải pháp mà bạn có thể triển khai cho ứng dụng của mình để đạt được chiến lược bền vững của Lambda.