最初から始めましょう。以前のクライアントの 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 と組み合わせて使用してさらなる自動化を作成することで、同様のソリューションを構築できます。
免責事項: 提供されるすべてのリソースの一部はインターネットからのものです。お客様の著作権またはその他の権利および利益の侵害がある場合は、詳細な理由を説明し、著作権または権利および利益の証拠を提出して、電子メール [email protected] に送信してください。 できるだけ早く対応させていただきます。
Copyright© 2022 湘ICP备2022001581号-3