翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。

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

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

イベント駆動型アプリケーションの開発を高速化するには、 AWS Event Fork Pipelines を搭載したイベント処理パイプラインを Amazon SNS トピックにサブスクライブできます。 AWS Event Fork Pipelines はAWS 、Serverless Application Model (AWS SAM) に基づくオープンソースのネストされたアプリケーションのスイートです。このモデルは、AWS Event Fork Pipelines スイートから直接 AWS アカウントにデプロイできます (カスタム IAM ロールまたはリソースポリシーを作成するアプリを表示を選択）。

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

AWS Event Fork Pipelines の仕組み

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

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

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

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

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

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

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

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

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

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

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

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

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

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

このパイプラインは、Amazon SQSトピックによって配信されるイベントをAmazon SNSキューと、キューからイベントをポーリングして通常のイベント処理パイプラインに再処理する 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 のサブスクライブ Amazon SNS 。

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

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

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 テンプレートの他の場所でMySNSTopic定義されているAWS::SNS::Topicリソース を参照します。詳細については、『AWS CloudFormation ユーザーガイド』の「組み込み関数リファレンス」を参照してください。