Ổn định tĩnh bằng Vùng sẵn sàng

Tại Amazon, các dịch vụ chúng tôi xây dựng phải đáp ứng các mục tiêu về tính sẵn sàng cực cao. Điều này có nghĩa là chúng tôi cần cẩn thận cân nhắc về những yếu tố phụ thuộc mà hệ thống của chúng tôi tạo ra. Chúng tôi thiết kế hệ thống để duy trì khả năng phục hồi ngay cả khi những yếu tố phụ thuộc đó bị suy yếu. Trong bài viết này, chúng tôi sẽ định nghĩa mô hình ổn định tĩnh mà chúng tôi sử dụng để đạt được mức độ phục hồi này. Chúng tôi sẽ chỉ cho bạn cách chúng tôi áp dụng khái niệm này cho Vùng sẵn sàng, một khối dựng cơ sở hạ tầng quan trọng trong AWS và do đó, là một yếu tố phụ thuộc nền tảng mà tất cả các dịch vụ của chúng tôi được xây dựng dựa trên.

Trong thiết kế ổn định tĩnh, hệ thống tổng thể tiếp tục hoạt động ngay cả khi yếu tố phụ thuộc trở nên suy yếu. Có thể là hệ thống không thấy bất kỳ thông tin cập nhật nào (chẳng hạn như những nội dung mới, đã bị xóa hoặc đã được sửa đổi) mà yếu tố phụ thuộc được cho là đã được cung cấp. Tuy nhiên, mọi việc hệ thống đang thực hiện trước khi yếu tố phụ thuộc trở nên suy yếu vẫn tiếp tục hoạt động mặc dù yếu tố phụ thuộc bị suy yếu. Chúng tôi sẽ mô tả cách thức chúng tôi xây dựng Amazon Elastic Compute Cloud (EC2) để mang tính ổn định tĩnh. Sau đó, chúng tôi sẽ cung cấp hai kiến trúc ví dụ về ổn định tĩnh mà chúng tôi thấy là hữu ích trong việc xây dựng các hệ thống khu vực có tính sẵn sàng cao trên Vùng sẵn sàng.

Cuối cùng, chúng tôi sẽ đi sâu hơn vào một số triết lý thiết kế phía sau Amazon EC2, bao gồm cả cách mà hệ thống được thiết kế kiến trúc để cung cấp tính độc lập của Vùng sẵn sàng ở cấp độ phần mềm. Ngoài ra, chúng tôi sẽ thảo luận về một vài sự đánh đổi đi kèm với việc xây dựng dịch vụ khi lựa chọn kiến trúc này.

Trong phần này, chúng tôi sẽ giới thiệu hai mô hình cấp cao mà chúng tôi sử dụng trong AWS để thiết kế các hệ thống có tính sẵn sàng cao bằng cách tận dụng sự ổn định tĩnh. Mỗi mô hình có thể áp dụng cho tập hợp các tình huống riêng, nhưng cả hai đều tận dụng sự trừu tượng của Vùng sẵn sàng.

Trong trường hợp suy yếu Vùng sẵn sàng, kiến trúc được thể hiện trong sơ đồ trước không yêu cầu thực hiện thao tác gì. Các phiên bản EC2 trong Vùng sẵn sàng bị suy yếu sẽ bắt đầu không vượt qua kiểm tra tình trạng và Cân bằng tải ứng dụng sẽ chuyển lưu lượng truy cập khỏi các phiên bản này. Trên thực tế, dịch vụ Elastic Load Balancing được thiết kế theo nguyên tắc này. Nó đã cung cấp đủ khả năng cân bằng tải để chịu đựng sự suy yếu của Vùng sẵn sàng mà không cần phải mở rộng quy mô.

Chúng tôi cũng sử dụng mô hình này ngay cả khi không có dịch vụ HTTPS hoặc cân bằng tải. Ví dụ: Nhóm các phiên bản EC2 xử lý tin nhắn từ hàng đợi Amazon Simple Queue Service (SQS) cũng có thể thực hiện theo mô hình này. Các phiên bản được triển khai trong Auto Scaling group trên nhiều Vùng sẵn sàng, được cung cấp vượt mức một cách thích hợp. Trong trường hợp Vùng sẵn sàng bị suy yếu, dịch vụ sẽ không làm gì cả. Các phiên bản đã suy yếu dừng thực hiện tác vụ và các phiên bản khác sẽ thực hiện tác vụ đó.

Tương tự như với ví dụ về mô hình hoạt động chủ động-chủ động không trạng thái, khi Vùng sẵn sàng chứa nút chính bị suy yếu, dịch vụ có trạng thái sẽ không làm gì với cơ sở hạ tầng. Đối với các dịch vụ sử dụng Amazon RDS, RDS sẽ quản lý việc chuyển đổi dự phòng và trỏ lại tên DNS sang nút chính mới trong Vùng sẵn sàng đang hoạt động. Mô hình này cũng áp dụng cho các thiết lập chủ động-dự phòng khác, ngay cả khi các thiết lập đó không sử dụng cơ sở dữ liệu quan hệ. Cụ thể, chúng tôi áp dụng mô hình này cho các hệ thống có kiến trúc cụm chứa nút chỉ huy. Chúng tôi triển khai các cụm này trên các Vùng sẵn sàng và chọn nút chỉ huy mới từ một ứng viên dự phòng thay vì khởi chạy một thay thế “vừa đúng lúc”.

Điểm chung của hai mô hình này là cả hai đều đã cung cấp khả năng cần thiết trong trường hợp suy yếu Vùng sẵn sàng trước bất kỳ suy yếu thực tế nào. Trong cả hai trường hợp này, dịch vụ đều không sử dụng bất kỳ yếu tố phụ thuộc mặt phẳng điều khiển có chủ ý nào, chẳng hạn như cung cấp cơ sở hạ tầng mới hoặc thực hiện sửa đổi, để đáp lại khi Vùng sẵn sàng bị suy yếu.

Phần cuối cùng của bài viết này sẽ đi sâu hơn một cấp vào các kiến trúc Vùng sẵn sàng phục hồi, bao gồm một số cách mà trong đó, chúng tôi tuân theo nguyên tắc độc lập của Vùng sẵn sàng trong Amazon EC2. Việc nắm được một số khái niệm này rất hữu ích khi chúng tôi xây dựng một dịch vụ không chỉ cần có tính sẵn sàng cao mà còn cần cung cấp cơ sở hạ tầng để các dịch vụ khác cũng có thể ở trạng thái sẵn sàng cao. Amazon EC2, với tư cách là nhà cung cấp cơ sở hạ tầng AWS cấp thấp, là cơ sở hạ tầng mà các ứng dụng có thể sử dụng để có tính sẵn sàng cao. Đôi khi các hệ thống khác cũng muốn áp dụng chiến lược đó.

Chúng tôi tuân theo nguyên tắc độc lập của Vùng sẵn sàng trong Amazon EC2 ở các hoạt động triển khai của mình. Trong Amazon EC2, phần mềm được triển khai đến máy chủ vật lý lưu trữ các phiên bản EC2, thiết bị biên, trình phân giải DNS, các thành phần mặt phẳng điều khiển trong đường dẫn khởi chạy của phiên bản EC2 và nhiều thành phần khác mà phiên bản EC2 phụ thuộc vào. Những triển khai này tuân theo lịch triển khai vùng. Điều này có nghĩa là hai Vùng sẵn sàng trong cùng một Khu vực sẽ nhận được một triển khai nhất định vào các ngày khác nhau. Trên AWS, chúng tôi sử dụng triển khai theo từng giai đoạn. Ví dụ: Chúng tôi tuân theo biện pháp tốt nhất (bất kể loại dịch vụ mà chúng tôi triển khai tới) của lần đầu tiên triển khai một hộp và sau đó là 1/N máy chủ, v.v.. Tuy nhiên, trong trường hợp cụ thể của các dịch vụ như dịch vụ trong Amazon EC2, việc triển khai của chúng tôi tiến thêm một bước và được điều chỉnh có chủ ý theo ranh giới của Vùng sẵn sàng. Theo cách đó, sự cố khi triển khai chỉ ảnh hưởng đến một Vùng sẵn sàng và sẽ được quay lui cũng như khắc phục. Sự cố sẽ không ảnh hưởng đến các Vùng sẵn sàng khác, các vùng khác tiếp tục hoạt động như bình thường.

Một cách khác mà chúng tôi sử dụng nguyên tắc Vùng sẵn sàng độc lập khi xây dựng trong Amazon EC2 là thiết kế để tất cả các luồng gói đều ở trong Vùng sẵn sàng thay vì vượt qua ranh giới. Điểm thứ hai này—khi lưu lượng truy cập mạng được giữ cục bộ với Vùng sẵn sàng—đáng để khám phá chi tiết hơn. Đây là minh họa thú vị về cách chúng tôi suy nghĩ khác biệt khi xây dựng hệ thống mang tính khu vực, có tính sẵn sàng cao, là khách hàng của Vùng sẵn sàng độc lập (nghĩa là hệ thống sử dụng đảm bảo về tính độc lập của Vùng sẵn sàng làm nền tảng để xây dựng dịch vụ có tính sẵn sàng cao), trái ngược với thời điểm chúng tôi cung cấp cơ sở hạ tầng độc lập của Vùng sẵn sàng cho những hệ thống khác sẽ cho phép Vùng sẵn sàng được xây dựng để có tính sẵn sàng cao.

Sơ đồ sau minh họa dịch vụ bên ngoài có tính sẵn sàng cao, được thể hiện bằng màu cam, phụ thuộc vào một dịch vụ nội bộ khác, được thể hiện bằng màu lục. Thiết kế đơn giản sẽ coi cả hai dịch vụ này là khách hàng của Vùng sẵn sàng EC2 độc lập. Mỗi dịch vụ màu cam và màu lục đứng sau một Cân bằng tải ứng dụng và mỗi dịch vụ đều có một nhóm máy chủ phụ trợ được cung cấp đầy đủ trải rộng trên ba Vùng sẵn sàng. Một dịch vụ khu vực có tính sẵn sàng cao sẽ gọi một dịch vụ khu vực có tính sẵn sàng cao khác. Đây là một thiết kế đơn giản và phù hợp đối với nhiều dịch vụ mà chúng tôi đã xây dựng.

Tuy nhiên, giả sử rằng dịch vụ màu lục là dịch vụ nền tảng. Nghĩa là, giả sử dịch vụ không chỉ nhằm hướng đến tính sẵn sàng cao mà còn để phục vụ với tư cách một khối dựng để cung cấp tính độc lập của Vùng sẵn sàng. Trong trường hợp đó, chúng tôi có thể thiết kế dịch vụ thành ba phiên bản dịch vụ cục bộ vùng, theo đó chúng tôi tuân theo các biện pháp triển khai nhận biết Vùng sẵn sàng. Sơ đồ sau minh họa thiết kế trong đó dịch vụ khu vực có tính sẵn sàng cao gọi là dịch vụ vùng có tính sẵn sàng cao.

Lý do tại sao chúng tôi thiết kế các dịch vụ khối dựng thành Vùng sẵn sàng độc lập đến từ số học đơn giản. Giả sử Vùng sẵn sàng bị suy yếu. Đối với các lỗi đen trắng, Cân bằng tải ứng dụng sẽ tự động chuyển khỏi các nút bị ảnh hưởng. Tuy nhiên, không phải tất cả các lỗi đều rõ ràng. Có thể có các lỗi xám, chẳng hạn như lỗi trong phần mềm, mà cân bằng tải sẽ không thể phát hiện khi kiểm tra tình trạng và xử lý hết.

Trong ví dụ trước, khi một dịch vụ khu vực có tính sẵn sàng cao gọi một dịch vụ khu vực có tính sẵn sàng cao khác, nếu yêu cầu được gửi qua hệ thống thì với một số giả định đơn giản hóa, cơ hội để yêu cầu này tránh Vùng sẵn sàng bị suy yếu là 2/3 * 2/3 = 4/9. Nghĩa là, tỷ lệ tránh xảy ra sự kiện này của yêu cầu thậm chí còn tệ hơn 50/50. Ngược lại, nếu chúng tôi xây dựng dịch vụ màu lục thành dịch vụ vùng như trong ví dụ hiện tại, thì các máy chủ trong dịch vụ màu cam có thể gọi điểm cuối màu lục trong cùng một Vùng sẵn sàng. Với kiến trúc này, cơ hội tránh Vùng sẵn sàng bị suy yếu là 2/3. Nếu N dịch vụ là một phần của đường dẫn cuộc gọi này, thì các con số này sẽ tổng quát hóa thành (2/3)^N đối với N dịch vụ khu vực so với hằng số còn lại là 2/3 đối với N dịch vụ vùng.

Vì lý do này, chúng tôi đã xây dựng cổng NAT Amazon EC2 dưới dạng dịch vụ vùng. Cổng NAT là một tính năng của Amazon EC2 cho phép lưu lượng truy cập internet đi từ mạng con riêng và không xuất hiện dưới dạng cổng toàn VPC, khu vực mà dưới dạng tài nguyên vùng do khách hàng khởi tạo riêng theo Vùng sẵn sàng như được thể hiện trong sơ đồ sau. Cổng NAT nằm trong đường dẫn kết nối internet cho VPC và do đó, là một phần thuộc mặt phẳng dữ liệu của bất kỳ phiên bản EC2 nào trong VPC đó. Nếu có sự suy yếu kết nối trong một Vùng sẵn sàng, chúng tôi muốn giữ sự suy yếu trong Vùng sẵn sàng đó, thay vì lan rộng đến các vùng khác. Cuối cùng, chúng tôi muốn khách hàng đã xây dựng kiến trúc tương tự như vừa được đề cập trong bài viết này (nghĩa là, bằng cách cung cấp một nhóm trên ba Vùng sẵn sàng với bất kỳ hai khu vực nào cũng có đủ khả năng để mang toàn bộ tải) biết rằng các Vùng sẵn sàng còn lại sẽ hoàn toàn không bị ảnh hưởng bởi bất cứ điều gì đang diễn ra bên trong Vùng sẵn sàng bị suy yếu. Cách duy nhất để chúng tôi thực hiện điều này là đảm bảo rằng tất cả các thành phần nền tảng—giống như cổng NAT—thực sự nằm trong Vùng sẵn sàng.

Lựa chọn này sẽ làm tăng chi phí do tính phức tạp tăng thêm. Đối với chúng tôi tại Amazon EC2, tính phức tạp bổ sung này xuất hiện dưới dạng quản lý các môi trường dịch vụ vùng, thay vì dịch vụ khu vực. Đối với khách hàng sử dụng cổng NAT, tính phức tạp bổ sung này xuất hiện dưới dạng có nhiều cổng NAT và bảng định tuyến để sử dụng trong các Vùng sẵn sàng khác nhau của VPC. Tính phức tạp bổ sung này là thích hợp vì bản thân cổng NAT đã là một dịch vụ nền tảng, một phần của mặt phẳng dữ liệu Amazon EC2 được cho là cung cấp các đảm bảo về tính sẵn sàng của vùng.

Chúng tôi còn cân nhắc đến một điểm nữa khi xây dựng các dịch vụ mang tính độc lập của Vùng sẵn sàng, đó là độ bền dữ liệu. Mặc dù mỗi kiến trúc vùng được mô tả ở trên đều cho thấy toàn bộ ngăn xếp có trong một Vùng sẵn sàng duy nhất, nhưng chúng tôi vẫn sao chép mọi trạng thái cứng trên nhiều Vùng sẵn sàng nhằm mục đích phục hồi sau thảm họa. Ví dụ: Chúng tôi thường lưu trữ các bản sao lưu cơ sở dữ liệu định kỳ trong Amazon S3 và duy trì các bản sao đọc của kho dữ liệu qua các ranh giới Vùng sẵn sàng. Hoạt động của Vùng sẵn sàng chính không cần đến những bản sao này. Thay vào đó, những bản sao này đảm bảo rằng chúng tôi lưu trữ dữ liệu quan trọng của khách hàng hoặc của doanh nghiệp ở nhiều vị trí.

Khi thiết kế kiến trúc hướng đến dịch vụ sẽ chạy trong AWS, chúng tôi đã học cách sử dụng một trong hai mô hình này hoặc kết hợp cả hai:

• Mô hình đơn giản hơn: khu vực-gọi đến-khu vực. Đây thường là lựa chọn phù hợp nhất cho các dịch vụ hướng ngoại và cũng phù hợp với hầu hết các dịch vụ nội bộ. Ví dụ: Khi xây dựng các dịch vụ ứng dụng cấp cao hơn trong AWS, chẳng hạn như Amazon API Gateway và các công nghệ không có máy chủ của AWS, chúng tôi sử dụng mô hình này để cung cấp tính sẵn sàng cao ngay cả khi Vùng sẵn sàng bị suy yếu.
• Mô hình phức tạp hơn: khu vực-gọi đến-vùng hoặc vùng-gọi đến-vùng. Khi thiết kế các thành phần bên trong và trong một số trường hợp là bên ngoài, mặt phẳng dữ liệu trong Amazon EC2 (ví dụ: các thiết bị mạng hoặc cơ sở hạ tầng khác nằm trực tiếp trong đường dẫn dữ liệu quan trọng), chúng tôi tuân theo mô hình tính độc lập của Vùng sẵn sàng và sử dụng các phiên bản nằm cố định trong Vùng sẵn sàng, để lưu lượng truy cập mạng vẫn nằm trong cùng một Vùng sẵn sàng. Mô hình này không chỉ giúp cô lập các yếu tố suy yếu trong Vùng sẵn sàng mà còn có các ưu điểm về chi phí lưu lượng truy cập mạng trong AWS.

Trong bài viết này, chúng tôi đã thảo luận về một số chiến lược đơn giản mà chúng tôi sử dụng tại AWS để tạo ra thành công các yếu tố phụ thuộc trên Vùng sẵn sàng. Chúng tôi rút ra được rằng điểm mấu chốt trong ổn định tĩnh chính là dự đoán suy yếu trước khi chúng xảy ra. Cho dù hệ thống chạy trên nhóm có thể mở rộng theo chiều ngang chủ động-chủ động hoặc cho dù đó là mô hình trạng thái, chủ động-dự phòng, chúng tôi đều có thể sử dụng Vùng sẵn sàng để hướng đến mục tiêu mức sẵn sàng cao. Chúng tôi triển khai các hệ thống sao cho tất cả khả năng cần thiết trong trường hợp xảy ra suy yếu đều đã được cung cấp đầy đủ và trong trạng thái sẵn sàng. Cuối cùng, chúng tôi đã xem xét kỹ hơn về cách bản thân Amazon EC2 sử dụng các khái niệm ổn định tĩnh để giữ các Vùng sẵn sàng độc lập với nhau.