Amazon SNS イベントの AWS Event Fork Pipelines へのファンアウト

Amazon SNS で構築したイベント駆動型アプリケーションで受信者サービスを使用し、発行者サービスでトリガーされたイベントに応答して自動的に作業を実行できます。このアーキテクチャパターンにより、サービスの再利用性、相互運用性、およびスケーラビリティを高めることができます。ただし、イベントのストレージ、バックアップ、検索、分析、再生などの一般的なイベント処理要件に対応するパイプラインにイベント処理を分岐させることは多大な労力を要する場合があります。

イベント駆動型アプリケーションの開発を迅速化するために、AWS Event Fork Pipelines による、イベント処理パイプラインを Amazon SNS トピックへサブスクライブできます。AWSEvent Fork Pipelines は、AWS サーバーレスアプリケーションモデル (AWS SAM) に基づいた、オープンソースのネストされたアプリケーションのスイートであり、AWS Event Fork Pipelines スイート ([カスタム IAM ロールまたはリソースポリシーを作成するアプリを表示する] を選択) から AWS アカウントへ直接デプロイできます。

AWS Event Fork Pipelines のユースケースについては、「Amazon SNS Event Fork Pipelines サンプルアプリケーションをデプロイしてテストする」を参照してください。

AWS Event Fork Pipelines の仕組み

AWS Event Fork Pipelines は、サーバーレスな設計パターンです。ただし、AWS SAM に基づいてネストされたサーバーレスアプリケーションのスイートでもあります (これを AWS Serverless Application Repository (AWS SAR) から AWS アカウント に直接デプロイしてイベント駆動型のプラットフォームを強化できます)。アーキテクチャの必要に応じて、これらのネストされたアプリケーションを個別にデプロイできます。

次の図は、3 つのネストされたアプリケーションで補完された AWS Event Fork Pipelines アプリケーションを示しています。アーキテクチャの必要に応じて、AWS SAR の AWS Event Fork Pipelines スイートから任意のパイプラインを個別にデプロイできます。

各パイプラインは、同じ Amazon SNS トピックにサブスクライブされるため、このトピックに発行された複数のイベントを並列処理できます。各パイプラインは独立しており、独自のサブスクリプションフィルターポリシーを設定できます。これにより、パイプラインでは、トピックに発行されたすべてのイベントではなく、関心のあるイベントのサブセットに絞って処理できます。

イベントのストレージおよびバックアップパイプライン

次の図は、イベントのストレージおよびバックアップパイプラインを示しています。このパイプラインを Amazon SNS トピックにサブスクライブして、システムを通過するイベントを自動的にバックアップできます。

このパイプラインは、Amazon SNS トピックから配信されたイベントをバッファ処理する Amazon SQS キュー、これらのイベントをキューで自動的にポーリングしてストリーム内にプッシュする AWS Lambda 関数、およびストリームでロードされたイベントを永続的にバックアップする Amazon S3 バケットで構成されます。

Firehose ストリームの動作を微調整するには、イベントをバケット内にロードする前に、イベントをバッファ処理、変換、および圧縮するようにストリームを設定できます。イベントがロードされたら、Amazon Athena で標準の SQL クエリを使用し、バケットに対してクエリを実行できます。既存の Amazon S3 バケットを再利用したり、新しいバケットを作成したりするようにパイプラインを設定することもできます。

イベントの検索および分析パイプライン

次の図は、イベントの検索および分析パイプラインを示しています。このパイプラインを Amazon SNS トピックにサブスクライブして、システムを通過するイベントを検索ドメインでインデックス付けし、これらのイベントに対して分析を実行できます。

このパイプラインは、Amazon SNS トピックから配信されたイベントをバッファ処理する Amazon SQS キュー、キューのイベントをポーリングしてストリーム内にプッシュする AWS Lambda 関数、Firehose ストリームでロードされたイベントにインデックス付けする Amazon OpenSearch Service ドメイン、および検索ドメインでインデックス付けできないデッドレターイベントを保存する Amazon S3 バケットで構成されます。

Firehose ストリームについてイベントのバッファ処理、変換、および圧縮を微調整するには、このパイプラインを設定できます。

パイプラインで AWS アカウント アカウント内の既存の OpenSearch ドメインを再利用するか、新しいドメインを作成するかを設定することもできます。イベントは検索ドメインでインデックス付けされるため、Kibana を使用してイベントに対して分析を実行し、リアルタイムでビジュアルダッシュボードを更新できます。

イベントの再生パイプライン

次の図は、イベントの再生パイプラインを示しています。過去 14 日間にシステムで処理されたイベントを記録するには (プラットフォームを障害から復旧する必要がある場合など)、このパイプラインを Amazon SNS トピックにサブスクライブしてイベントを再処理できます。

このパイプラインは、Amazon SNS トピックから配信されたイベントをバッファ処理する Amazon SQS キューと、キューのイベントをポーリングして通常のイベント処理パイプライン (トピックにサブスクライブ済み) 内に再ルーティングする AWS Lambda 関数で構成されます。

AWS Event Fork Pipelines のデプロイ

AWS Event Fork Pipelines スイート ([カスタム IAM ロールまたはリソースポリシーを作成するアプリケーションを表示する] を選択) が AWS Serverless Application Repository でパブリックアプリケーションのグループとして使用可能であり、ここで AWS Lambda コンソールを使用して手動でスイートをデプロイしてテストできます。AWS Lambda コンソールを使用したパイプラインのデプロイについては、「Amazon SNS トピックに AWS Event Fork Pipelines をサブスクライブする」を参照してください。

本稼働シナリオでは、AWS Event Fork Pipelines をアプリケーション全体の AWS SAM テンプレート内に埋め込むことをお勧めします。これをネストされたアプリケーション機能を使用して行うには、AWS SAM テンプレートにリソース AWS::Serverless::Application を追加し、ネストされたアプリケーションの AWS SAR ApplicationId と SemanticVersion を参照します。

例えば、AWS SAM テンプレートの Resources セクションに次の YAML スニペットを追加することで、イベントのストレージおよびバックアップパイプラインを、ネストされたアプリケーションとして使用できます。

Backup:   
    Type: AWS::Serverless::Application
  Properties:
    Location:
      ApplicationId: arn:aws:serverlessrepo:us-east-2:123456789012:applications/fork-event-storage-backup-pipeline
      SemanticVersion: 1.0.0
    Parameters: 
      #The ARN of the Amazon SNS topic whose messages should be backed up to the Amazon S3 bucket.
      TopicArn: !Ref MySNSTopic

パラメータ値を指定するときに、AWS CloudFormation 組み込み関数を使用してテンプレート内の他のリソースを参照できます。例えば、上の YAML スニペットで、TopicArn パラメータは、AWS SAM テンプレート内に定義されている AWS::SNS::Topic リソース MySNSTopic を参照します。詳細については、『AWS CloudFormation ユーザーガイド』の「組み込み関数リファレンス」を参照してください。