Bài viết này được viết bởi Ben Moses, Senior Solutions Architect, Enterprise.
AWS Serverless phù hợp với nhiều trường hợp sử dụng tự động hóa và vận hành IT, đặc biệt là để phản ứng với các sự kiện. Các sự kiện cơ sở hạ tầng là một cách hữu ích để hiểu được sức khỏe của cơ sở hạ tầng hỗ trợ ứng dụng và khách hàng của bạn và bài viết này xem xét cách sử dụng serverless để giúp tăng cường các sự kiện vận hành này.
Kịch bản được sử dụng trong bài viết này cho thấy làm thế nào một sự kiện cơ sở hạ tầng có thể được chặn lại trong thời gian thực, được bổ sung với thông tin bổ sung từ môi trường AWS và workloads của bạn, và được gửi đến một người tiêu dùng downstream với thông tin quý giá được thêm vào.
Ví dụ này tập trung vào các sự kiện thay đổi trạng thái Amazon EC2. Khái niệm này áp dụng cho bất kỳ loại sự kiện nào, ví dụ như các sự kiện được phát ra bởi các dịch vụ AWS khác đến Amazon CloudWatch Events. Những sự kiện này cũng có thể bao gồm các sự kiện được tạo ra bởi AWS Config và một số sự kiện của AWS CloudTrail, bao gồm CloudTrail Insights.
Mục đích là thêm thông tin và ngữ cảnh có giá trị hơn cho các sự kiện trong thời gian thực. Các nhà điều hành và người tiêu dùng downstream có thể nhận ra các mô hình mới nổi lên gần như trong thời gian thực.
Làm thế nào để xử lý vấn đề này hiện nay?
Hiện nay, các giải pháp hiện có thường lưu trữ các sự kiện cơ sở hạ tầng theo định dạng mà hệ thống nguồn phát sinh hoặc theo định dạng chuẩn mở hoặc độc quyền. Nhân viên và hệ thống vận hành sau đó phân tích các nhật ký này để hiểu các mô hình và hỗ trợ phân tích nguyên nhân gốc rễ. Dữ liệu này thường cần được bổ sung bởi các nguồn khác để cung cấp bối cảnh và ý nghĩa cho nó. Việc này được thực hiện bằng cách sử dụng dữ liệu CSV từ các hệ thống khác trong một hoạt động batch được lên lịch hoặc tích hợp với các công cụ doanh nghiệp khác.
Tình trạng cơ sở hạ tầng cloud của bạn thay đổi thường xuyên do tính đàn hồi và tính sẵn sàng của tài nguyên. Điều này có thể gây ra vấn đề về chất lượng dữ liệu của bạn khi sử dụng phương pháp lên lịch batch. Khi bạn đến để bổ sung một sự kiện cơ sở hạ tầng, trạng thái có thể đã thay đổi vào lúc lịch batch được lên kế hoạch chạy. Điều này dẫn đến khoảng trống hoặc sai sót trong dữ liệu, làm cho việc nhận diện xu hướng và bất thường khó khăn hơn đối với các nhà điều hành.
Một phương pháp tiếp cận Serverless
Ví dụ này sử dụng các dịch vụ không máy chủ và các khái niệm từ kiến trúc dựa trên sự kiện (EDA). Với kiến trúc này, bạn chỉ trả tiền khi sự kiện xảy ra và được bổ sung thông tin. Không cần bất kỳ công cụ bên thứ ba nào và các sự kiện của bạn được bổ sung thông tin gần như trong thời gian thực.
Sự kiện “Thay đổi trạng thái EC2” được bổ sung thông tin bằng cách lấy thẻ tên của instance, nếu có. Hành trình từ đầu đến cuối trông giống như sau:
- Trạng thái của một instance EC2 thay đổi (tức là tắt, khởi động lại).
- Một quy tắc Amazon EventBridge phù hợp với mẫu sự kiện kích hoạt một hành động đích để chạy một trạng thái máy AWS Step Functions.
- Máy trạng thái biến đổi đầu vào, thực hiện một cuộc gọi SDK API AWS bản địa đến dịch vụ EC2 để tìm thẻ tên và phát ra một sự kiện được bổ sung thông tin mới trở lại EventBridge.
- Một quy tắc EventBridge phù hợp với sự kiện được bổ sung thông tin kích hoạt một hành động để gửi một email qua Amazon SNS để mô phỏng một downstream consumer.
EventBridge là một bus sự kiện không máy chủ (serverless) có thể được sử dụng với kiến trúc dựa trên sự kiện trên AWS. Một quy tắc EventBridge được định nghĩa với một mẫu, và nếu một sự kiện phù hợp với mẫu đó, thì hành động mục tiêu của quy tắc được kích hoạt. Trong ví dụ này, quy tắc là:
JSON
{
“detail-type”: [“EC2 Instance State-change Notification”],
“source”: [“aws.ec2”]
}
Sự kiện thay đổi trạng thái EC2 trông giống như thế này:
JSON
{
“version”: “0”,
“id”: “672123fe-53aa-3b22-3b37-1fae26df2aff”,
“detail-type”: “EC2 Instance State-change Notification”,
“source”: “aws.ec2”,
“account”: “1234567890”,
“time”: “2022-08-17T18:25:01Z”,
“region”: “eu-west-1”,
“resources”: [
“arn:aws:ec2:eu-west-1:1234567890:instance/i-1234567890”
],
“detail”: {
“instance-id”: “i-0123456789”,
“state”: “running”
}
}
Xem các trường detail-type và source trong sự kiện. Chúng phù hợp với quy tắc và toàn bộ dữ liệu sự kiện này được chuyển tiếp đến thành phần tiếp theo của kiến trúc: state machine của Step Functions.
Step Functions sử dụng JSONPath để chọn, biến đổi và chuyển dữ liệu qua các trạng thái trong một state machine. Tính linh hoạt này có nghĩa là, trong ví dụ này, không cần tài nguyên tính toán như AWS Lambda. Điều này có thể đồng nghĩa với ít mã tùy chỉnh, chi phí thấp hơn và độ phức tạp ít hơn.
Step Functions Workflow Studio cho phép bạn thiết kế quy trình làm việc một cách trực quan. Đây là các hành động chính xảy ra khi state machine chạy sử dụng sự kiện thay đổi trạng thái EC2:
- Loại bỏ các ký tự gây vấn đề khỏi đầu vào
Các trạng thái Pass cho phép chúng ta chuyển đổi đầu vào và đầu ra. Trong kiến trúc này, trạng thái Pass được sử dụng để loại bỏ bất kỳ ký tự gây vấn đề nào từ sự kiện đầu vào, được biết là gây ra sự cố trong các bước tiếp theo, chẳng hạn như cuộc gọi API đến các dịch vụ.
Trong ví dụ này, các tham số cho cuộc gọi API được sử dụng trong Bước 2 yêu cầu ID của phiên bản EC2. Thông tin này có trong chi tiết của sự kiện ban đầu, nhưng hành động API không thể sử dụng bất cứ điều gì có dấu gạch ngang.
Để giải quyết vấn đề này, sử dụng Tham số JSONPath để hiệu quả viết lại thông tin này mà không có dấu gạch ngang. Điều này tạo ra một trường mới được đặt tên là instanceid, được gán giá trị từ chi tiết sự kiện ban đầu.
JSON
{
“instanceid.$”: “$.detail.instance-id”
}
- Lấy tên instance từ Tag
Nhiệm vụ “EC2: DescribeInstances” trong Step Functions là một ví dụ về tích hợp SDK nguyên bản với một dịch vụ AWS. Thao tác này mong đợi một tham số đơn cho API, đó là một mảng các ID của các instance EC2.
JSON
{
“InstanceIds.$”: “States.Array($.detail.refined.instanceid)”
}
Hàm States.Array() được sử dụng để bao gói instance ID từ trường được viết lại trong bước 1. Mảng có một thành viên này được truyền vào API EC2 Describe Instances.
Khi nhận được phản hồi từ API EC2 Describe Instances, nó được truyền vào một Result Selector. Mục đích của việc này là để trích xuất giá trị của thẻ “Name” nếu nó được trả về từ API EC2 Describe Instances.
Step Functions hỗ trợ việc sử dụng các biểu thức lọc JSONPath.
JSON
{
“instancename.$”: “$..Reservations[0].Instances[0].Tags[?(@.Key==Name)].Value”,
“instanceid.$”: “$.Reservations[0].Instances[0].InstanceId”
}
Để hiểu biểu thức lọc JSONPath nâng cao được sử dụng trong ví dụ này, hãy đọc bài viết trên blog này.
Nếu xảy ra lỗi với cuộc gọi API, hoặc biểu thức lọc không thể tìm thấy thẻ “Name” trên instance EC2, thì Step Functions cho phép bạn xử lý các lỗi này trong quy trình làm việc.
- Chuyển đổi tên instance thành chuỗi
Đầu ra từ trạng thái trước trả về một mảng, nhưng một EC2 instance chỉ có một thẻ “Name” duy nhất. Một trạng thái Pass được sử dụng một lần nữa, với một tham số như được thấy trong Bước 1. Biểu thức tham số này lấy phần tử đầu tiên từ mảng và lưu trữ nó trong một trường mới có tên là “instancename“.
JSON
{
“instancename.$”: “$.detail.refined.instancename[0]”,
“instanceid.$”: “$.detail.refined.instanceid”
}
Giống như các bước trước, instanceid được viết lại là một phần của đầu ra, và cả hai giá trị này được thêm vào đầu ra của trạng thái.
- Lấy tên mặc định từ Parameter Store
Nếu biểu thức lọc trong bộ chọn kết quả ở bước 2 thất bại vì bất kỳ lý do gì, thì xử lý lỗi của Step Functions sẽ chuyển đến đây.
Có thể xảy ra lỗi vì nhiều nguyên nhân khác nhau và với Step Functions, bạn có thể tách các xử lý lỗi riêng cho từng loại lỗi khác nhau. Trong ví dụ này, tất cả các lỗi được xử lý một cách đồng nhất bất kể nguyên nhân là do thiếu tag “Name” hoặc vấn đề về quyền hạn. Trong kiến trúc này, giá trị mặc định được sử dụng thay cho tên của instance. Trong ngữ cảnh của bạn, một phương pháp khác có thể phù hợp hơn.
Tên placeholder mặc định được lưu trữ dưới dạng giá trị tĩnh trong AWS Systems Manager Parameter Store. Hành động native Systems Manager: GetParameter trong Step Functions có thể truy xuất giá trị này trực tiếp. Một lợi thế của phương pháp này là tham số có thể được cập nhật bên ngoài mà không cần thay đổi bất kỳ điều gì trong state machine của Step Functions.
- Thêm ID trở lại vào dữ liệu đã tinh chế
Một trạng thái Pass được sử dụng để định dạng phản hồi từ API của Parameter Store và biểu thức tham số sau đó được sử dụng để thêm tên mặc định của instance vào kết quả đầu ra.
Cho dù việc thực thi luồng là đúng theo kế hoạch, hoặc gặp lỗi, bây giờ đã có một gói dữ liệu sẽ được bổ sung với tên instance.
- Phát ra sự kiện được cải thiện
Hành động SDK bản địa của EventBridge: PutEvents được sử dụng trong Step Functions để xây dựng và phát ra sự kiện được cải thiện.
JSON
{
“Entries”: [
{
“Detail”: {
“Message.$”: “$”
},
“DetailType”: “EnrichedEC2Event”,
“EventBusName”: “serverless-event-enrichment-ApplicationEventBus”,
“Source”: “custom.enriched.ec2”
}
]
}
DetailType và Source của sự kiện được cải thiện là các giá trị tùy chỉnh, được chỉ định trong bước cuối của máy trạng thái. Khi xem xét các schema cho sự kiện trong tổ chức của bạn, hãy lưu ý rằng tiền tố AWS được dành riêng cho các sự kiện dịch vụ AWS.
Bộ tải dữ liệu của sự kiện được cải thiện trông giống như thế này:
JSON
{
“version”: “0”,
“id”: “a80e378b-e9a7-8007-1f18-b947e6d72c4b”,
“detail-type”: “EnrichedEC2Event”,
“source”: “custom.enriched.ec2”,
“account”: “123456789”,
“time”: “2022-08-17T18:25:03Z”,
“region”: “eu-west-1”,
“resources”: [
“arn:aws:states:eu-west-1:123456789:stateMachine:EventEnrichmentStateMachine-2T5jFlCPOha1”,
“arn:aws:states:eu-west-1:123456789:execution:EventEnrichmentStateMachine-2T5jFlCPOha1:672123fe-53aa-3b22-3b37-1fae26df2aff_90821b68-ba92-2374-5015-8804c8da5769”
],
“detail”: {
“Message”: {
“version”: “0”,
“id”: “672123fe-53aa-3b22-3b37-1fae26df2aff”,
“detail-type”: “EC2 Instance State-change Notification”,
“source”: “aws.ec2”,
“account”: “123456789”,
“time”: “2022-08-17T18:25:01Z”,
“region”: “eu-west-1”,
“resources”: [
“arn:aws:ec2:eu-west-1:123456789:instance/i-123456789”
],
“detail”: {
“instance-id”: “i-123456789”,
“state”: “running”,
“refined”: {
“instancename”: “ec2-enrichment-demo-instance”,
“instanceid”: “i-123456789”
}
}
}
}
}
Tiêu thụ các sự kiện đã được tăng cường
Khi tăng cường dữ liệu sự kiện trong thời gian thực, các sự kiện chỉ có giá trị nếu chúng được tiêu thụ. Để sử dụng các sự kiện đã được tăng cường này, một dịch vụ tiêu thụ phải tạo và sở hữu một luật EventBridge mới trên bus ứng dụng tùy chỉnh. Trong kiến trúc này, một mẫu luật phù hợp là:
JSON
{
“detail-type”: [“EnrichedEC2Event”],
“source”: [“custom.enriched.ec2”]
}
Mục tiêu của luật phụ thuộc vào trường hợp sử dụng. Đối với các sự kiện hoạt động, các ứng dụng quản lý dịch vụ hoặc các dịch vụ tổng hợp nhật ký có thể là lựa chọn phù hợp nhất. Trong ví dụ này, luật có một chủ đề SNS làm mục tiêu. Khi SNS nhận được một tin nhắn, nó được gửi đến nhà điều hành qua email. Với EventBridge, các nhà tiêu thụ trong tương lai có thể thêm các luật của riêng họ để phù hợp với các sự kiện đã được tăng cường và thêm các hành động mục tiêu cụ thể để phù hợp với trường hợp sử dụng của họ.
Kết luận
Bài viết này chỉ ra cách tạo các quy tắc trong EventBridge để phản ứng với các sự kiện hoạt động từ các dịch vụ AWS. Những sự kiện này được định tuyến đến Step Functions, chạy một quy trình làm việc bao gồm các bước để làm giàu sự kiện, xử lý lỗi và phát ra sự kiện đã được làm giàu. Ví dụ cho thấy cách tiêu thụ các sự kiện đã được làm giàu, dẫn đến việc một nhà điều hành nhận được một email.
Ví dụ này có sẵn trên GitHub dưới dạng mẫu ứng dụng AWS Serverless Application Model (AWS SAM). Nó chứa hướng dẫn để triển khai, kiểm tra và sau đó loại bỏ tất cả các tài nguyên khi bạn đã hoàn thành.
Để biết thêm nguồn tài liệu học tập về serverless, truy cập Serverless Land.
AWS Study Group 