翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。 # Amazon SNS イベントを AWS Event Fork Pipelines にファンアウトする | | | --- | | イベントのアーカイブと分析のために、Amazon SNS は Amazon Data Firehose とのネイティブ統合の使用を推奨するようになりました。Firehose 配信ストリームを SNS トピックにサブスクライブできます。これにより、Amazon Simple Storage Service (Amazon S3) バケット、Amazon Redshift テーブル、Amazon OpenSearch Service (OpenSearch Service) などのアーカイブと分析エンドポイントへ通知を送信することができます。Firehose 配信ストリームで Amazon SNS を使用するのは、フルマネージド型のコードレスソリューションであり、 AWS Lambda 関数を使用する必要はありません。詳細については、「[Firehose 配信ストリームへのファンアウト](sns-firehose-as-subscriber.md)」を参照してください。 | Amazon SNS で構築したイベント駆動型アプリケーションで受信者サービスを使用し、発行者サービスでトリガーされたイベントに応答して自動的に作業を実行できます。このアーキテクチャパターンにより、サービスの再利用性、相互運用性、およびスケーラビリティを高めることができます。ただし、イベントのストレージ、バックアップ、検索、分析、再生などの一般的なイベント処理要件に対応するパイプラインにイベント処理を分岐させることは多大な労力を要する場合があります。 イベント駆動型アプリケーションの開発を加速するには、Event Fork Pipelines を搭載した AWS イベント処理パイプラインを Amazon SNS トピックにサブスクライブできます。 AWS Event Fork Pipelines は、[AWS Serverless Application Model](https://aws.amazon.com/serverless/sam/) (AWS SAM) に基づくオープンソースの[ネストされたアプリケーションの](https://docs.aws.amazon.com/serverless-application-model/latest/developerguide/serverless-sam-template-nested-applications.html)スイートです。[AWS Event Fork Pipelines スイート](https://serverlessrepo.aws.amazon.com/applications?query=aws-event-fork-pipelines) (**カスタム IAM ロールまたはリソースポリシーを作成する Show アプリケーション**を選択) から AWS アカウントに直接デプロイできます。 AWS Event Fork Pipelines のユースケースについては、「」を参照してください[Amazon SNS Event Fork Pipelines サンプルアプリケーションをデプロイしてテストする](sns-deploy-test-fork-pipelines-sample-application.md)。 **Topics** + [AWS Event Fork Pipelines の仕組み](#how-sns-fork-works) + [Event AWS Fork Pipelines のデプロイ](#deploying-sns-fork-pipelines) + [Amazon SNS Event Fork Pipelines サンプルアプリケーションをデプロイしてテストする](sns-deploy-test-fork-pipelines-sample-application.md) + [AWS Event Fork Pipelines を Amazon SNS トピックにサブスクライブする](sns-subscribe-event-fork-pipelines.md) ## AWS Event Fork Pipelines の仕組み AWS Event Fork Pipelines はサーバーレス設計パターンです。ただし、 AWS SAM に基づくネストされたサーバーレスアプリケーションのスイートでもあります (イベント駆動型プラットフォームを強化 AWS アカウント するために (AWS SAR) から AWS Serverless Application Repository に直接デプロイできます）。アーキテクチャの必要に応じて、これらのネストされたアプリケーションを個別にデプロイできます。 **Topics** + [イベントのストレージおよびバックアップパイプライン](#sns-fork-event-storage-and-backup-pipeline) + [イベントの検索および分析パイプライン](#sns-fork-event-search-and-analytics-pipeline) + [イベントの再生パイプライン](#sns-fork-event-replay-pipeline) 次の図は、3 つのネストされたアプリケーションで補完された AWS Event Fork Pipelines アプリケーションを示しています。アーキテクチャの必要に応じて、 AWS Event Fork Pipelines スイートから任意のパイプラインを AWS SAR に個別にデプロイできます。 ![AWS Event Fork Pipelines アーキテクチャは、Amazon SNS トピックからのイベントをフィルタリングし、イベントストレージとバックアップ、イベント検索と分析、イベント再生の 3 つの異なるパイプラインで処理する方法を示しています。これらのパイプラインは垂直に積み重ねられたボックスとして示され、それぞれが同じ Amazon SNS トピックからのイベントを並行して個別に処理します。](http://docs.aws.amazon.com/ja_jp/sns/latest/dg/images/sns-fork-pipeline-as-subscriber-how-it-works.png) 各パイプラインは、同じ Amazon SNS トピックにサブスクライブされるため、このトピックに発行された複数のイベントを並列処理できます。各パイプラインは独立しており、独自の[サブスクリプションフィルターポリシー](sns-subscription-filter-policies.md)を設定できます。これにより、パイプラインでは、トピックに発行されたすべてのイベントではなく、関心のあるイベントのサブセットに絞って処理できます。 **注記** 通常のイベント処理パイプライン (Amazon SNS トピックに既にサブスクライブされている可能性がある) と一緒に 3 つの AWS Event Fork Pipelines を配置するため、既存のワークロードで AWS Event Fork Pipelines を利用するために、現在のメッセージパブリッシャーの一部を変更する必要はありません。 ### イベントのストレージおよびバックアップパイプライン 次の図は、[イベントのストレージおよびバックアップパイプライン](https://serverlessrepo.aws.amazon.com/applications/arn:aws:serverlessrepo:us-east-1:077246666028:applications~fork-event-storage-backup-pipeline)を示しています。このパイプラインを Amazon SNS トピックにサブスクライブして、システムを通過するイベントを自動的にバックアップできます。 このパイプラインは、Amazon SNS トピックによって配信されるイベントをバッファする Amazon SQS Amazon SNS キュー、キュー内のこれらのイベントを自動的にポーリングしてストリームにプッシュする AWS Lambda 関数、およびストリームによってロードされたイベントを永続的にバックアップする Amazon S3 バケットで構成されます。 ![Fork-Event-Storage-Backup-Pipeline は、Amazon SNS トピックからのイベントを処理およびバックアップするように設計されています。フローは Amazon SNS トピックから始まり、そこからイベントが Amazon SQS キューにファンアウトされます。次に、これらのフィルタリングされたイベントは Lambda 関数によって処理され、Data Firehose に転送されます。Firehose ストリームがイベントのバッファリング、変換、圧縮を行い、それが Amazon S3 バックアップバケットにロードされます。最後に、Amazon Athena を使用して、保存されたデータをクエリできます。この図では、一連のアイコンと矢印を使用してサービス間のフローが示され、パイプラインの各コンポーネントには明確なラベルが付けられています。](http://docs.aws.amazon.com/ja_jp/sns/latest/dg/images/sns-fork-event-storage-and-backup-pipeline.png) Firehose ストリームの動作を微調整するには、イベントをバケット内にロードする前に、イベントをバッファ処理、変換、および圧縮するようにストリームを設定できます。イベントがロードされたら、Amazon Athena で標準の SQL クエリを使用し、バケットに対してクエリを実行できます。既存の Amazon S3 バケットを再利用したり、新しいバケットを作成したりするようにパイプラインを設定することもできます。 ### イベントの検索および分析パイプライン 次の図は、[イベントの検索および分析パイプライン](https://serverlessrepo.aws.amazon.com/applications/arn:aws:serverlessrepo:us-east-1:077246666028:applications~fork-event-search-analytics-pipeline)を示しています。このパイプラインを Amazon SNS トピックにサブスクライブして、システムを通過するイベントを検索ドメインでインデックス付けし、これらのイベントに対して分析を実行できます。 このパイプラインは、Amazon SNS トピックによって配信されるイベントをバッファする Amazon SQS Amazon SNS キュー、キューからイベントをポーリングしてストリームにプッシュする AWS Lambda 関数、Firehose ストリームによってロードされたイベントをインデックスする Amazon OpenSearch Service ドメイン、および検索ドメインでインデックス化できないデッドレターイベントを保存する Amazon S3 バケットで構成されます。 ![AWS アーキテクチャ内のイベント検索および分析パイプライン。左側から始まり、Amazon SNS トピックがすべてのイベントを受信します。次に、これらのイベントは「フィルタリングされたイベントをファンアウトする」を示す破線を経由して Amazon SQS キューに進みます。キューでは、イベントは Lambda 関数によって処理され、Data Firehose ストリームに転送されます。Data Firehose はイベントを 2 つの宛先に送信します。1 つのルートは Amazon Elasticsearch Service で、インデックスが作成されます。もう 1 つのルートでは、処理不能または「デッドレター」のイベントが Amazon S3 デッドレターバケットに送信されます。右端にある Elasticsearch Service からの出力は Kibana ダッシュボードにフィードされ、分析と視覚化に使用されます。フロー全体は水平に配置されており、各コンポーネントはデータフローの方向を示す線で接続されています。](http://docs.aws.amazon.com/ja_jp/sns/latest/dg/images/sns-fork-event-search-and-analytics-pipeline.png) Firehose ストリームについてイベントのバッファ処理、変換、および圧縮を微調整するには、このパイプラインを設定できます。 パイプラインが 内の既存の OpenSearch ドメインを再利用するか、新しいドメイン AWS アカウント を作成するかを設定することもできます。イベントは検索ドメインでインデックス付けされるため、Kibana を使用してイベントに対して分析を実行し、リアルタイムでビジュアルダッシュボードを更新できます。 ### イベントの再生パイプライン 次の図は、[イベントの再生パイプライン](https://serverlessrepo.aws.amazon.com/applications/arn:aws:serverlessrepo:us-east-1:077246666028:applications~fork-event-replay-pipeline)を示しています。過去 14 日間にシステムで処理されたイベントを記録するには (プラットフォームを障害から復旧する必要がある場合など)、このパイプラインを Amazon SNS トピックにサブスクライブしてイベントを再処理できます。 このパイプラインは、Amazon SQSトピックによって配信されるイベントをAmazon SNSキューと、キューからイベントをポーリングして通常のイベント処理パイプラインに再処理する AWS Lambda 関数で構成されます。この関数は、トピックにもサブスクライブされています。 ![イベントの再生パイプラインを示すフローチャートです。左から右に進みます。まず Amazon SNS トピックが、フィルタリングされたイベントを 2 つの並列プロセスに送信します。上部のフローは、通常のイベント処理パイプラインを示します。ここでは Amazon SQS キューがイベントを処理します。「fork-event-replay-pipeline」というラベルが付いた下部のフローには、Amazon SQS 再生キューが含まれています。イベントはここに一時的に保存されてから、Lambda 再生関数で処理されます。この Lambda 関数では、再生機能が有効か無効かに基づいて、イベントを通常のイベント処理パイプラインに再送信したり、再生のために保持したりできます。この図は、オペレータがイベント再生機能の有効化または無効化を制御できることも示しています。](http://docs.aws.amazon.com/ja_jp/sns/latest/dg/images/sns-fork-event-replay-pipeline.png) **注記** デフォルトでは、再生関数は無効になっており、イベントを再ルーティングしません。イベントを再処理する必要がある場合は、Amazon SQS 再生関数のイベントソースとして AWS Lambda 再生キューを有効にする必要があります。 ## Event AWS Fork Pipelines のデプロイ [AWS Event Fork Pipelines スイート](https://serverlessrepo.aws.amazon.com/applications?query=aws-event-fork-pipelines) (**カスタム IAM ロールまたはリソースポリシーを作成する Show アプリを選択**) は、 でパブリックアプリケーションのグループとして使用できます。ここから AWS Serverless Application Repository、 [AWS Lambda コンソール](https://console.aws.amazon.com/lambda/)を使用して手動でデプロイしてテストできます。 AWS Lambda コンソールを使用してパイプラインをデプロイする方法については、「」を参照してください[AWS Event Fork Pipelines を Amazon SNS トピックにサブスクライブする](sns-subscribe-event-fork-pipelines.md)。 本稼働シナリオでは、アプリケーション全体の SAM テンプレートに AWS Event Fork Pipelines AWS を埋め込むことをお勧めします。ネストされたアプリケーション機能を使用すると、リソースを AWS SAM テンプレートに追加`[AWS::Serverless::Application](https://docs.aws.amazon.com/serverless-application-model/latest/developerguide/serverless-sam-template.html#serverless-sam-template-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](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-properties-sns-topic.html)`リソース を参照します。詳細については、『*AWS CloudFormation ユーザーガイド*』の「[組み込み関数リファレンス](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/intrinsic-function-reference.html)」を参照してください。 **注記** AWS SAR アプリケーションの AWS Lambda コンソールページには、**SAM リソースとしてコピー**ボタンが含まれており、SAR アプリケーションをクリップボードにネストするために必要な YAML AWS をコピーします。