Cách Amazon Search ứng dụng Chaos Engineering xử lý hơn 84 nghìn yêu cầu mỗi giây

Cùng khám phá cách Amazon Search kết hợp giữa công nghệ và văn hóa để trao quyền cho các builder team của mình, đảm bảo khả năng phục hồi (resilience) của nền tảng thông qua Chaos Engineering.

Đây là câu chuyện về Kỹ thuật hỗn loạn (Chaos engineering) và cách các dịch vụ phân phối ở quy mô cao (hỗ trợ cho Search trên Amazon.com) sử dụng nó để đảm bảo rằng tất cả khách hàng có thể tìm kiếm danh mục mở rộng của Amazon bất cứ khi nào họ cần. Chaos Engineering cho phép các team thử nghiệm các lỗi hoặc sự cố tải để hiểu rõ hơn về việc ứng dụng của họ sẽ phản ứng ra sao và do đó cải thiện khả năng phục hồi. Và đây cũng là câu chuyện về DevOps và cách một nhóm chuyên về khả năng phục hồi có thể tạo ra công nghệ và thúc đẩy các thay đổi giúp nhiều nhóm tham gia vào Search có thể dễ dàng chạy các thử nghiệm Chaos trên nhiều dịch vụ hỗ trợ Search.

Nếu bạn đang muốn triển khai Chaos Engineering để cải thiện khả năng phục hồi, đang tìm cách tạo ra một mô hình trao quyền hiệu quả cho builder team hoặc cả hai, chúng ta hãy tiếp tục.

DevOps

DevOps là một chủ đề lớn và tôi không thể trình bày hết ở đây. Tôi thực sự thích định nghĩa mà một đồng nghiệp đã viết về DevOps.

DevOps là một cách tiếp cận giải quyết vấn đề mang tính cộng tác. Nó coi trọng tinh thần đồng đội và giao tiếp, phản hồi và lặp lại nhanh chóng cũng như loại bỏ xung đột hoặc lãng phí thông qua tự động hóa.

Bạn có thể đã nghe nói về tất cả các công cụ được sử dụng trong DevOps như Kubernetes, Terraform và GitLab, nhưng các công cụ này không phải là nơi thích hợp để khơi chuyện. DevOps là về văn hóa. Hãy xem định nghĩa ở trên: Hợp tác, làm việc nhóm, giao tiếp – đây đều là một phần của văn hóa. Sau đó, các công cụ tự động hóa sẽ cho phép văn hóa hoàn thành phần việc của mình.

DevOps rất lớn, vì vậy ở đây tôi sẽ chỉ tập trung vào các khái niệm DevOps chính được minh họa trong câu chuyện về cách Amazon Search áp dụng Chaos Engineering:

• Trao quyền cho các team: DevOps nuôi dưỡng một văn hóa nơi các nhóm được trao quyền thử nghiệm những ý tưởng mới và học hỏi từ cả thành công và thất bại.
• Tính sở hữu và trách nhiệm: Trong DevOps, các nhóm ‘sở hữu’ các dịch vụ mà họ xây dựng và chịu trách nhiệm đảm bảo kết quả phù hợp. Trao quyền là điều kiện tiên quyết cho vấn đề này, vì nhóm cần có khả năng hiểu cách sử dụng dịch vụ của họ và có thể thực hiện các thay đổi mà họ thấy phù hợp.
• Phá vỡ các bức tường: Động lực đằng sau “DevOps” là phá bỏ các rào cản truyền thống thường tồn tại giữa các team phát triển và vận hành. Bằng cách thúc đẩy sự hợp tác và các mục tiêu chung, DevOps hướng tới việc loại bỏ các rào cản và tạo ra một quy trình làm việc hợp lý và hiệu quả hơn.
• Cho phép các nhóm làm được nhiều việc hơn: Đây là lúc mà tự động hóa và các công cụ có thể đóng vai trò chính. Nhưng cơ cấu tổ chức và trách nhiệm cũng rất quan trọng ở đây. Một nhóm tách khỏi nhóm phát triển và vận hành dịch vụ cho họ không phải là lý tưởng (xem phần “phá bỏ những bức tường” ở trên) mà tốt hơn là nên có một nhóm chuyên về development và giảm bớt gánh nặng không phân biệt (undifferentiated heavy lifting) trong việc vận hành dịch vụ. Gánh nặng không phân biệt ở đây là tất cả những công việc khó khăn (“heavy lifting”) cần thiết để hoàn thành một nhiệm vụ (chẳng hạn như triển khai và vận hành một dịch vụ) nhưng không có sự khác biệt đáng kể giữa các dịch vụ (“undifferentiated”). Đây là thuật ngữ được Jeff Bezos đưa ra vào năm 2006, đại ý nói về tất cả những việc nhọc nhằn mà các công ty đang làm nhưng chẳng tạo giá trị gì cho sứ mệnh của nó. Nếu mỗi team dịch vụ phải tự mình làm công việc này thì thật lãng phí. Việc có một nhóm tạo ra các công cụ và quy trình thực hiện phần lớn công việc nặng nề này sẽ giúp loại bỏ gánh nặng cho các nhóm dịch vụ!

Amazon Search

Nếu bạn từng mua sắm trên Amazon.com hoặc bất kỳ trang Amazon nào trên toàn thế giới, bạn có thể đã sử dụng Search để tìm thấy những gì bạn muốn. Tìm kiếm chủ đề như Chaos Engineering trả về hơn 1.000 kết quả (Hình 1) và sau đó, Amazon Search cho phép bạn tinh chỉnh tìm kiếm đó theo nhiều thông số khác nhau như ngôn ngữ, định dạng sách hoặc ngày phát hành.

Hơn 1.000 kết quả là rất nhiều và Search chịu trách nhiệm cung cấp nhanh chóng các kết quả từ danh mục gồm nhiều triệu sản phẩm cho hơn 300 triệu khách hàng đang hoạt động. Vào Prime Day 2022, Amazon Search đã phục vụ 84.000 yêu cầu mỗi giây. Đó là quy mô khủng khiếp. Các nguyên tắc tôi sẽ chia sẻ với bạn ở đây có tác dụng kích hoạt khả năng phục hồi ở quy mô đó, nhưng chúng cũng hoạt động ở bất kỳ quy mô nào mà hệ thống của bạn chạy.

Amazon Search bao gồm hơn 40 dịch vụ backend, thuộc sở hữu của các builder team khác nhau (còn được gọi là các nhóm two-pizza). Nhóm two-pizza cũng là thuật ngữ Jeff Bezos đưa ra, đại ý là số lượng thành viên mỗi nhóm cần tối ưu sao cho ăn chỉ vừa đủ 2 cái pizza. Mỗi nhóm có quyền sở hữu dịch vụ (hoặc các dịch vụ) của mình, từ thiết kế và thực thi đến triển khai và vận hành. Vì vậy, ta có thể thấy các hoạt động DevOps đang nổi lên trong câu chuyện. Khi nhóm sở hữu cả hoạt động phát triển và vận hành, đó là một cách để áp dụng văn hóa ‘sở hữu và trách nhiệm’, cũng như ‘phá bỏ các bức tường giữa phát triển và vận hành’. Các builder team của Amazon có thể sở hữu việc triển khai và vận hành nhờ có một nhóm công cụ xây dựng (builder tool) trên toàn Amazon tạo ra công cụ và quy trình, loại bỏ các undifferentiated heavy lifting và ‘cho phép các nhóm làm được nhiều việc hơn’. Một nhóm chuyên biệt (Builder tools) cho phép các nhóm two-pizza làm được nhiều việc hơn. Chúng ta sẽ thấy tiếng vang của cách tiếp cận này sau khi nói về cách Search áp dụng Chaos Engineering.

Chaos Engineering (Kỹ thuật hỗn loạn)

Kỹ thuật hỗn loạn là quy tắc thử nghiệm trên một hệ thống nhằm xây dựng niềm tin vào khả năng của hệ thống trong việc chống chọi với các điều kiện hỗn loạn trong môi trường production. – Nguyên tắc của Chaos Engineering.

Một số người cảm thấy khó chịu với thuật ngữ “hỗn loạn” (chaos), nhưng điều quan trọng cần biết là Chaos Engineering không nhằm mục đích tạo ra hỗn loạn. Thay vào đó, đó là việc bảo vệ các ứng dụng của bạn khỏi sự hỗn loạn đang tồn tại trên production bằng cách đưa chúng vào tình trạng hỗn loạn một cách có kiểm soát. Bạn áp dụng phương pháp khoa học, tạo ra giả thuyết. Giả thuyết này dựa trên cách bạn đã thiết kế ứng dụng của mình để có khả năng phục hồi trước các sự kiện cụ thể như lỗi hoặc sự cố tải. Sau đó, bạn chạy một thử nghiệm bằng cách mô phỏng các sự kiện đó và quan sát cách ứng dụng của bạn hoạt động, kiểm tra giả thuyết. Điều này sẽ cho bạn biết ứng dụng của bạn có hoạt động tốt trước những sự kiện đó hay không hoặc bạn có thể cải thiện nó ở đâu.

Việc trao quyền cho các nhóm bao gồm việc trao cho họ quyền tự chủ để tạo và chạy các thử nghiệm hỗn loạn trên các dịch vụ của họ.

The Search Resilience Team (Nhóm phục hồi tìm kiếm)

Search Resilience Team là một nhóm two-pizza trong tổ chức Search, có nhiệm vụ cải thiện và thúc đẩy khả năng phục hồi của dịch vụ Amazon Search. Họ kết hợp mọi thứ tôi đã nói ở trên: DevOps + Amazon Search + Chaos Engineering. Điều đó nói lên rằng, họ không nhất thiết phải mô tả mình là một nhóm DevOps, mà thích tự gọi mình là một tổ chức tối ưu vận hành và quản lý độ tin cậy website (operational excellence and site reliability engineering organization). Nhưng cũng giống như nhóm builder tool của Amazon hoạt động như một nhóm chuyên biệt ‘cho phép các nhóm làm được nhiều việc hơn’ trên toàn bộ Amazon, Search Resilience Team hoạt động như một nhóm chuyên biệt trong Search, ‘cho phép các nhóm làm được nhiều việc hơn’ trong hơn 40 nhóm two-pizza sở hữu dịch vụ trong tổ chức Search.

Hãy nhớ rằng mô hình DevOps không có nhóm Search Resilience tạo ra cũng như sở hữu các thử nghiệm hỗn loạn cho các nhóm dịch vụ của họ. Thay vào đó, họ cần tạo ra một quy trình có thể mở rộng và công nghệ đằng sau quy trình đó để giúp các nhóm dịch vụ đó tạo, sở hữu và chạy các thử nghiệm hỗn loạn dễ dàng hơn, ngay cả trong môi trường production. Để thực hiện điều này, nhóm Search Resilience đã tạo ra Amazon Search Chaos Orchestrator.

Amazon Search Chaos Orchestrator (Bộ điều phối hỗn loạn Amazon Search)

Search Resilience team đã có nhiều mục tiêu cụ thể trong việc tạo ra bộ điều phối hỗn loạn. Tuy nhiên, mục tiêu chung là tạo ra một hệ thống giúp các nhóm Search two-pizza dễ dàng hơn trong việc tạo và chạy các thử nghiệm hỗn loạn với các dịch vụ mà họ sở hữu. Hình 2. hiển thị tổng quan về bộ điều phối.

Lưu ý tôi đã tạo chú thích để bạn không thể bỏ lỡ AWS Fault Injection Simulator (AWS FIS). AWS FIS là một dịch vụ được quản lý cho phép bạn thực hiện các thử nghiệm tiêm lỗi (fault injection) trên các ứng dụng được lưu trữ trên AWS và do đó, đây là một lựa chọn đương nhiên khi tạo và chạy các thử nghiệm hỗn loạn trên các dịch vụ Search, tất cả đều được lưu trữ trên AWS bằng dịch vụ AWS như Amazon S3, Amazon API Gateway, Amazon DynamoDB, Amazon EC2, Amazon ECS,… FIS là thứ mà bất kỳ ai chạy trên AWS đều có thể sử dụng. Search Resilience team muốn giúp các nhóm Search sử dụng FIS dễ dàng nhất có thể mà không cần mỗi nhóm phải xây dựng các hoạt động tích hợp và chi phí chung giống nhau.

Họ muốn triển khai các yêu cầu dành riêng cho Search nên mỗi nhóm không phải tự thực hiện. Ví dụ: xem trong Hình 2 trong đó có dòng chữ “Quy trình thực hiện thử nghiệm hỗn loạn”. Bằng cách biến thử nghiệm hỗn loạn thành một phần của quy trình làm việc, họ có thể thêm các bước dành riêng cho Search tiền và hậu thử nghiệm. Ví dụ, các bước tiền thử nghiệm sẽ kiểm tra xem thử nghiệm có vượt qua trong môi trường tiền production hay không trước khi chạy chúng trong môi trường production, đồng thời kiểm tra xem không có sự kiện nào tác động đến khách hàng đang diễn ra trước khi chạy thử nghiệm. Hậu thử nghiệm, quy trình sẽ kiểm tra xem các thang đo (metric) có bị ảnh hưởng bất lợi hay không.

Có một số yêu cầu dành riêng cho Search khác được các nhóm thực hiện dễ dàng hơn bằng cách sử dụng bộ điều phối hỗn loạn. Những mục tiêu này được thể hiện trong Hình 3.

Mở rộng quy mô trên hơn 40 dịch vụ Tìm kiếm

Chỉ bằng cách loại bỏ những Undifferentiated heavy lifting, Search Orchestrator sẽ giúp đạt được mục tiêu này. Ngoài ra, Search Resilience team đã tạo giao diện người dùng UX bằng đồ họa để làm cho nó dễ sử dụng. Bạn có thể thấy API Gateway trong Hình 2 ở trên thể hiện hai API. Các nhóm có thể tự do gọi các API này theo chương trình hoặc họ có thể sử dụng UX đồ họa để gọi các API này. Bạn có thể thấy trong Hình 4, đây không phải là UX “đẹp nhất” từ trước đến nay nhưng nó cung cấp cho các nhóm Search tất cả chức năng mà họ cần để xác định và chạy các thử nghiệm hỗn loạn. Điều này cũng phù hợp với Agile và DevOps, nơi chúng tôi chỉ dành nỗ lực cho những thứ quan trọng.

Lên lịch

AWS FIS ghi lại hướng dẫn về cách lên lịch thử nghiệm bằng Amazon EventBridge Scheduler. Nhưng hãy nhớ rằng, chúng ta muốn loại bỏ những công việc không có sự khác biệt. Vì vậy, tính năng này chỉ được tích hợp sẵn trong bộ điều phối và các nhóm Search có thể sử dụng nó. Lưu ý trong Hình 2 rằng Search Resilience team đã đi theo một lộ trình hơi khác, sử dụng Amazon DynamoDb để lưu trữ lịch trình và EventBridge thực sự gọi hàm Lambda để đọc lịch trình và khởi động quá trình chạy thử nghiệm.

Chạy với triển khai

Tương tự như lập lịch, bất kỳ ai sử dụng FIS đều có thể chạy nó với quy trình triển khai của họ. Ví dụ: đây là cách tích hợp nó từ AWS CodePipeline. Nhưng một lần nữa, để tiết kiệm công sức cho nhóm two-pizza, tại sao không làm cho nó hoạt động với quy trình của nhóm. Ngoài ra, Search sử dụng công cụ nội bộ của Amazon cho quy trình và triển khai, do đó, bộ điều phối sẽ đảm nhận việc tích hợp với công cụ này.

Guardrail sử dụng SLO nhất quán

Có rất nhiều thứ cần làm rõ ở đây. Các guardrail (rào chắn) đầu tiên – đây là những thứ PHẢI CÓ cho các thí nghiệm hỗn loạn. Guardrail là những điều kiện bạn xác định cho biết thử nghiệm sẽ gây ra tác động không mong muốn, vì vậy khi những điều kiện này xảy ra, thử nghiệm phải được dừng và khôi phục. Tất nhiên, AWS FIS cho phép bạn xác định các điều kiện dừng dưới dạng guardrail — bạn có thể thấy những điều kiện đó ở phía bên phải của Hình 2. Vậy Search Chaos Orchestrator cung cấp thêm lợi ích gì ở đây? Đó là nơi SLO xuất hiện.

Mục tiêu cấp độ dịch vụ, hay SLO (Service Level Objective), chỉ đơn giản là các mục tiêu trông giống như thế này: Trong khoảng thời gian 28 ngày, chúng ta sẽ phân phối 99,9% yêu cầu có độ trễ dưới 1000 mili giây. Search Resilience team không chỉ xây dựng bộ điều phối thử nghiệm hỗn loạn mà còn xây dựng hệ thống theo dõi định nghĩa SLO. Hệ thống này cho phép các nhóm xác định SLO cho dịch vụ của họ và sau đó giám sát các SLO đó, theo dõi khi dịch vụ không tuân thủ. Search Chaos Orchestrator tích hợp với điều này và sử dụng các SLO này làm rào chắn cho các thử nghiệm do các nhóm dịch vụ vận hành. Ngoài việc dừng thử nghiệm, bộ điều phối còn thông báo cho chủ sở hữu dịch vụ và cắt phiếu theo dõi khi guardrail bị vi phạm.

Dây Andon

Bạn có thấy nút lớn màu đỏ trong Hình 4 có nội dung “Dừng tất cả các thử nghiệm hỗn loạn tìm kiếm” không? Đó chính là dây Andon. Andon được Toyota sản xuất tại các nhà máy của họ, nơi “mỗi người được phép dừng dây chuyền sản xuất nếu họ phát hiện ra điều gì đó mà họ cho là có mối đe dọa đối với chất lượng xe”. Ở đây nó cho phép mọi người dừng tất cả các thử nghiệm nếu có bất kỳ rủi ro nào đối với trải nghiệm của khách hàng. Họ có thể sử dụng nút lớn màu đỏ hoặc lệnh CLI. Bạn có thể xem trong Hình 2 cách triển khai chức năng Andon bằng cách sử dụng chức năng điều kiện dừng được tích hợp trong FIS. Ngoài việc dừng tất cả các thử nghiệm đang chạy, Andon sẽ khiến kỹ sư Search Resilience đang phụ trách phải phân trang. Hầu hết các nhóm two-pizza trên Amazon đều có ít nhất một thành viên trực để xử lý sự cố 24/7, đây là một phần trong vận hành dịch vụ của DevOps.

Metric và thông tin chi tiết

AWS FIS hỗ trợ metric và ghi nhật ký. Bộ điều phối kỹ thuật hỗn loạn sử dụng chức năng đó và tổng hợp kết quả từ tất cả các nhóm Search để trình bày dưới dạng một báo cáo duy nhất.

Một thử nghiệm hỗn loạn trên Amazon Search

Amazon Search, giống như nhiều dịch vụ của Amazon, sử dụng đòn bẩy khẩn cấp (emergency lever) như một phần trong chiến lược phục hồi. Đòn bẩy khẩn cấp là một quá trình nhanh chóng cho phép hệ thống phục hồi sau căng thẳng hoặc tác động. Vì vậy, tất nhiên, Search muốn thử nghiệm để biết đòn bẩy khẩn cấp hoạt động như dự kiến hay không. Trong trường hợp này, một giả thuyết đơn giản hóa có thể như sau:

Khi tải tìm kiếm vượt quá [một giá trị nào đó] và lỗi cũng như độ trễ bắt đầu tăng lên (cụ thể metric nào và bao nhiêu), thì việc kích hoạt đòn bẩy khẩn cấp để tắt các dịch vụ không quan trọng sẽ giữ lỗi và độ trễ trong giới hạn có thể chấp nhận được (xác định các giới hạn này), lên tới [số lượng cụ thể] tải.

Đòn bẩy khẩn cấp cụ thể này sẽ vô hiệu hóa tất cả các dịch vụ không quan trọng, bảo tồn tài nguyên khi hệ thống bị ép, để các dịch vụ quan trọng vẫn khả dụng. Bạn có thể thấy điều này trong Hình 5. Bên trái là trải nghiệm Tìm kiếm thông thường. Bên phải là sau khi đã kéo cần gạt khẩn cấp. Chức năng quan trọng như tiêu đề, hình ảnh và giá được hiển thị, ngoài ra thì không còn gì khác. Tìm kiếm thà hiển thị trải nghiệm ở bên phải còn hơn là không trả lại bất kỳ kết quả nào. Đây là thực hành tốt nhất về khả năng phục hồi được gọi là xuống cấp nhẹ (graceful degradation).

Hình 5. Đòn bẩy khẩn cấp vô hiệu hóa các dịch vụ không quan trọng trong Search và mang lại trải nghiệm xuống cấp nhẹ cho khách hàng

Đối với thử nghiệm hỗn loạn, các sự kiện bao gồm sự kết hợp của việc thêm tải tổng hợp vào hệ thống và sau đó kéo đòn bẩy khẩn cấp. Bằng cách này, Search có thể tạo niềm tin rằng trong trường hợp xảy ra sự cố có lượng tải thực sự cao, đòn bẩy sẽ cho phép Search luôn sẵn sàng.

Kết

Chaos Engineering là phương pháp tuyệt vời để hiểu tốt hơn về khả năng phục hồi các dịch vụ của bạn. Và AWS FIS là một dịch vụ tuyệt vời để tạo và chạy các thử nghiệm hỗn loạn trên AWS. Các nhóm two-pizza trong Search có thể bắt đầu sử dụng FIS và chạy thử nghiệm một cách độc lập. Nhưng bằng cách áp dụng văn hóa DevOps tập trung vào việc ‘hỗ trợ các nhóm làm được nhiều việc hơn’, nhóm Search Resilience đã có thể làm cho quy trình này trở nên dễ dàng hơn nữa đối với các nhóm Search two-pizza và bổ sung nhiều tính năng có giá trị giúp kỹ thuật hỗn loạn trở nên hiệu quả hơn trên toàn bộ Search.

Nguồn: AWS Community