Amazon CloudWatch Events を使用したサーバーレスパイプラインの構築

AWS サーバーレスヒーローである Forrest Brazeal 氏によるゲスト投稿。Forrest 氏は、Trek10, Inc. のシニアクラウドアーキテクトであり、Trek10 の Think FaaS サーバーレスポッドキャストのホストを務めており、サーバーレスコミュニティのワークショップやイベントで定期的に講演を行っています。

イベントとサーバーレスは、ベイクドビーンズとバーベキューのようにいつも一緒です。サーバーレスという考え方は、ビジネス上の価値を提供するコードやコンフィギュレーションに焦点を当てます。それは結局のところ、外の世界で起こることに対応する構造化データである、イベントを扱うことを意味します。ポーリング中にリソースを消費する長時間実行されるサーバータスクを維持するのではなく、イベントトリガーに応答してのみ機能するサーバーレスアプリケーションを作成することができます。

AWS でイベントを操作する際には、たくさんの選択肢があります。Amazon Kinesis Data Streams、Amazon Simple Notification Service (SNS)、Amazon Simple Queue Service (SQS) などであり、要件によります。最近では、名前に「イベント」という言葉が付いたサービスを頻繁に使用しています。Amazon CloudWatch Events です。

CloudWatch Events: サーバーレスイベント処理における穴場

最初は、CloudWatch は Lambda ログを収集し、スケジュールに従って機能を実行できるサービスと理解していました。ところが、CloudWatch Events では、CloudWatch API を使用して独自のカスタムイベントを発行することもできます。SNS と同様の料金と配信保証があり、ターゲットとして多数の AWS のサービスをサポートしています。

何よりも、イベントバスをプロビジョニングする必要さえありません。CloudWatch コンソールの中にあるからです。ここで、boto3 AWS SDK for Python を使用して、イベントを発行することができます。


import boto3
cw = boto3.client('cloudwatch')
cw.put_events(
    Entries=[
        {
            'Source': 'my.app.event',
            'DetailType': 'MY_EVENT_TYPE',
            'Detail': '{"my_data":"As a JSON string"}'
        }
    ]
)

つまり、CloudWatch Events が、任意の数のコンシューマーをサポートする完全マネージド型のイベントパイプを提供してくれるので、必要な種類の JSON 文字列を削除することができます。そして、これはサーバーレスアプリケーションを構築するうえで非常に便利です。

イベント駆動型アーキテクチャの動作

私は、毎日 Trek10 で顧客向けのクラウドネイティブソリューションを構築しています。そうした中で、レガシーシステムをサーバーレスに移行したり、ダウンストリームの統合を容易にしたりするための強力な方法として、イベント駆動型アーキテクチャを頻繁に使用しています。以下は、私が気に入っているパターンのほんの一例です。
• レガシーデータベースの絞殺
• イベントソースアプリケーションの設計

レガシーデータベースの絞殺

「絞殺パターン」は、ユーザーを新しいインターフェースに徐々に移行しながら、ラッパー API の背後にレガシーシステムを隠します。Trek10 は、以前これについて書いています。変化をイベントとしてクラウドにストリーミングすることは、レガシーデータベースから負荷を取り除きながら、レポート作成と分析のユースケースを開くための素晴らしい方法です。次の図は、レガシーデータベースのイベントへの書き込みを示しています。

このパターンは、他の方法でも機能します。CloudWatch Events に新しいデータを書き込み、それを最新のデータソースに取り込んで、データを私のレガシーシステムに同期させる 2 番目のコンシューマーを作成することができます。

イベントソースアプリケーションの設計

イベントソーシングとは、単にシステムの状態の変化をイベントとして扱い、それらを別のダウンストリームアプリケーションによって消費される可能性がある元帳またはバスに発行することを意味します。

CloudWatch Events を集中型バスとして使用すると、以下のイベント検証フロー図に示すように、サニタイズされたイベントの記録を利用できるようになります。

検証機能により、アプリケーションの基準に一致するイベントだけが「有効」とタグ付けされ、ダウンストリームのコンシューマーが利用できるようになります。デフォルトのバスはたくさんのイベント (サービスログはここに入ることを忘れないください) を処理するので、気になるイベントだけに一致するルールを設定することが重要です。

CloudWatch Events は、インフラストラクチャをプロビジョニングまたは維持する必要なしで、フィルタを適用してコンシューマーをサブスクライブできる単一のバスを提供することによって、これらのパターンを単純化します。そして、これはほんの始まりに過ぎません。

ユースケース: CloudWatch Events を使用したマルチアカウントイベント処理

CloudWatch Events は、複数の AWS アカウントの接続を開始したときに最も興味深いものになります。転送するイベントを選択するためのフィルタリングルールを使用して、異なるアカウントの CloudWatch イベントバス間に信頼関係を設定するのは簡単です。

例として、AnyCompany という大企業のためのウィジェット処理システムを想像してください。AnyCompany には、それぞれ独自の AWS アカウントを使用する、さまざまな開発チームがあります。一部のサービスは、倉庫にチェックインしたり、全国を旅行したりするときに、ウィジェットに関する情報を生成しています。他のサービスは、レポートを実行したり新製品を革新するためにそのデータを必要とします。

サービス A が新しいウィジェットに関する情報を生成し、サービス B はウィジェットに関する集計をリアルタイムで表示したいとし、サービス C はレポート作成のためのウィジェットに関する履歴データを必要としているとします。完全なイベントフローは、次の図のようになります。

1.サービス A は、以下のイベント本文を使用して、AWS アカウントの CloudWatch Events に新しいウィジェットイベントを発行します。

{
            'Source': 'cwi.servicea',
            'DetailType': 'NEW_WIDGET',
            'Detail': '{"widget_id":"abc123"}'
}

2.フィルタリングルールは、cwi.servicea でタグ付けされたイベントを中心的なイベント処理アカウントに転送します。CloudFormation を使用して、以下のようにルールを定義します。

CentralForwardingRule:
    Type: AWS::Events::Rule
    Properties:
      Description: イベントを中心的なアカウントに送信するためのルール
      EventPattern:
        source:
          - cwi.servicea
      Targets:
        - Arn: !Sub arn:aws:events:${CENTRAL_ACCOUNT_REGION}:${CENTRAL_ACCOUNT_ID}:event-bus/default
          Id: CentralTarget
          RoleArn: <IAM ROLE WITH ACCESS TO PUT CW EVENTS>

3.イベントは、その基準に従って検証されます。

4.有効なイベントが、新しいソース valid.cw.servicea を使用して中心的なイベントのバスに再発行されます。無限ループを回避するために、個々のイベントは 1 回しか転送できないため、これは重要です。

5.フィルタリングルールは、有効なイベントをサービス B の AWS アカウントに転送し、そこで AWS AppSync API に接続されている DynamoDB テーブルを更新します。

6.2 番目のルールは、同じイベントをサービス C のアカウントに転送します。そこでイベントは、Amazon Athena を使用した分析のために Kinesis Data Firehose を介して Amazon S3 バケットに流れます。

ここで CloudWatch Events が提供するのは、主に「プラグアンドプレイ」サービスを使用しながら、将来のイノベーションのための柔軟性を開く、分離システムです。

クラウドを最大限に活用する

私が、CloudWatch Events を気に入っている最大の理由ですか? それは素晴らしいクラウドネイティブのサービスであるからです。必要なコードはほとんどなく、AWS のサービスの制限を監視する以外に運用上の責任はありません。使い始めるために何かをデプロイする必要すらありません。それでも、内部では、汗をかくこともなく複雑な分散アプリケーションをサポートできる強力な AWS のインフラストラクチャを使用しています。

これは、サーバーレスアプリケーションの観念的な理想に非常に近いです。イベント駆動型アプリケーションを作成するときはいつでも、CloudWatch Events が何を貢献できるかを必ず検討してください。

Amazon Web Services ブログ