最初から始めましょう。以前のクライアントの 1 つで AWS クラウド エンジニアとしての私の役割では、サードパーティが EventBridge 経由で多くのイベントを AWS 環境に継続的に送信するイベント駆動型のアーキテクチャが使用されていました。各サードパーティに対して、さまざまな EventBridge ルールを備えたイベント バスを提供しました。
ここでの課題は、イベントの構造、つまりイベントがどのように組織されたかを追跡することでした。イベントは頻繁に更新され、物事を明確にするために多くの会議が開かれました。
2019 年末に、EventBridge Schema Discovery のおかげで問題の大部分が解決されました。イベント バスでこれを有効にすることで、受信したイベントに基づいてスキーマが自動的に生成されました。これにより、これらのスキーマからコード バインディングを生成できるようになり、オブジェクト指向環境では非常に役立ちました。
以下に、サードパーティの非常に基本的なイベントの例を示します。
{ "version": "0", "id": "ef21d5fc-a5ba-e2c6-fc4b-a8807455c64d", "detail-type": "orderType", "source": "com.company.A", "account": "xxx", "time": "2024-08-22T08:04:26Z", "region": "eu-west-1", "resources": [], "detail": { "orderId": 123456789, "customer": { "customerId": "C001", "name": "John Doe" }, "orderDate": "2024-08-22" } }
AWS は次のタイプのイベントのスキーマを発見しました:
AWS Toolkit for Visual Studio Code を使用すると、コード内でイベントを厳密に型指定されたオブジェクトとして簡単に表現できます。
以下は、コード バインディングの使用方法に関する非常に基本的な例です。
出力:
123456789 C001
これにより作業方法は改善されましたが、依然として問題が発生しました。時々、サードパーティがイベントに新しい属性を追加することがあります。 EventBridge はこれらの変更を検出しますが、開発者は新しいスキーマのコード バインディングを更新するのを忘れることがよくありました。私たちの実装は、新しい属性が追加されたときの破損を防ぐのに十分堅牢でしたが、その結果、利用していない新しいデータが発生しました。私たちは開発者がコード バインディングを時々更新することを忘れないよう頼らなければなりませんでしたが、これを管理するための明確なプロセスが用意されていませんでした。
コード バインディングが何か月も更新されないこともあり、場合によっては 2 人の開発者が同時に更新して、競合や重複作業が発生することもありました。
これをより適切に処理するために、サードパーティがイベントを更新し、新しいスキーマが検出されるたびに Jira チケットを自動的に作成するソリューションを構築することにしました。
このソリューションは、私の GitHub の CloudFormation で入手できます。 README を確認してください。
最初のステップは、新しいスキーマまたはスキーマ バージョンの更新が検出されるたびにトリガーされる EventBridge ルールをデフォルトのバス上に作成することでした。このイベントは、EventBridge パイプへの入力として機能するために SQS キューに送信されました。ここで、追加のフィルタリング (この例ではオプション) を追加し、Lambda 関数を使用してイベントを強化できます。
強化のために、boto3 を使用して description_schema を使用しました。
data = event[0]["input"]["detail"] try: response = client.describe_schema( RegistryName=data["RegistryName"], SchemaName=data["SchemaName"], SchemaVersion=data["Version"], ) except ClientError as e: raise e return_data = { "SchemaName": response["SchemaName"], "SchemaVersion": response["SchemaVersion"], "SchemaArn": response["SchemaArn"], "Content": json.loads(response["Content"]), }
データを強化した後、それを Step Function ワークフローに送信しました。このワークフローは、AWS が提供する AWS-CreateJiraIssue SSM オートメーションをトリガーし、Jira チケットを自動的に作成しました。
チケットには、スキーマ名、新しいスキーマのバージョン、スキーマの ARN などの詳細が含まれていました。 (必要に応じて、イベントの追加コンテンツも追加できます。)
+----------------+ +--------+ +-------------------------+ +----------------+ +-------------------------+ | EventBridge | ---> | SQS | ---> | EventBridge Pipe | ---> | Step Function | ---> | SSM Automation Document | | Rule | | | | (Filtering & Enrichment)| | | | | +----------------+ +--------+ +-------------------------+ +----------------+ +-------------------------+
このソリューションをデモしてみましょう。ここでは、オリジナルに基づいて更新されたイベントが表示されます。属性ステータスは新しいです。
{ "version": "0", "id": "dffbd38b-9258-d028-21f3-da0ba3c9e314", "detail-type": "orderType", "source": "com.company.A", "account": "xxx", "time": "2024-08-22T08:04:26Z", "region": "eu-west-1", "resources": [], "detail": { "orderId": 123456789, "status": "Completed", "customer": { "customerId": "C001", "name": "John Doe" }, "orderDate": "2024-08-22" } }
新しいスキーマが発見されます。これにより、ソリューション全体がトリガーされます。 Lambda がイベントを強化した後、その更新されたイベントは Step Function の入力として使用されます。
Step Function の入力イベントが強化され、次のようになります。
[ { "statusCode": 200, "data": { "SchemaName": "com.company.A@OrderType", "SchemaVersion": "2", "SchemaArn": "arn:aws:schemas:eu-west-1:xxx:schema/discovered-schemas/com.company.A@OrderType", "Content": { "openapi": "3.0.0", "info": { "version": "1.0.0", "title": "OrderType" }, "paths": {}, "components": { "schemas": { "AWSEvent": { "type": "object", "required": [ "detail-type", "resources", "detail", "id", "source", "time", "region", "version", "account" ], "x-amazon-events-detail-type": "orderType", "x-amazon-events-source": "com.company.A", "properties": { "detail": { "$ref": "#/components/schemas/OrderType" }, "account": { "type": "string" }, "detail-type": { "type": "string" }, "id": { "type": "string" }, "region": { "type": "string" }, "resources": { "type": "array", "items": { "type": "object" } }, "source": { "type": "string" }, "time": { "type": "string", "format": "date-time" }, "version": { "type": "string" } } }, "OrderType": { "type": "object", "required": [ "orderId", "orderDate", "customer", "status" ], "properties": { "customer": { "$ref": "#/components/schemas/Customer" }, "orderDate": { "type": "string", "format": "date" }, "orderId": { "type": "number" }, "status": { "type": "string" } } }, "Customer": { "type": "object", "required": [ "customerId", "name" ], "properties": { "customerId": { "type": "string" }, "name": { "type": "string" } } } } } } } } ]
Step Function ワークフローは、SSM 自動化をトリガーし、Jira チケットを作成します。
便宜上、チケットの内容を簡潔にまとめました。ただし、コンテンツは Step Function への入力としても送信されるため、チケットに含めることもできます。このようにして、チケット内の新しい属性やスキーマの変更について直接言及できます。
このソリューションは、まったく新しいイベントが検出されたときにもトリガーされ、新しいイベントのバージョン 1 が作成され、EventBridge ルールが起動されます。
このようにして、更新についての通知を受け取り、スプリントに更新をスケジュールすることができました。これは開発サイクルの加速につながります。
これがかなり特殊なケースであることは承知していますが、目的のイベントでトリガーするように EventBridge ルールを設定し、エンリッチメントと Step Functions を SSM と組み合わせて使用して、さらなる自動化を作成することで、同様のソリューションを構築できます。
以上が新しい EventBridge スキーマ検出のための自動化された Jira チケットの処理の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。
![[Web フロントエンド] Node.js クイック スタート](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
