翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
# 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 をコピーします。
# Amazon SNS Event Fork Pipelines サンプルアプリケーションをデプロイしてテストする
イベント駆動型アプリケーションの開発を加速するには、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 の仕組み](sns-fork-pipeline-as-subscriber.md#how-sns-fork-works)」を参照してください。
このページでは、 AWS マネジメントコンソール を使用して AWS Event Fork Pipelines サンプルアプリケーションをデプロイおよびテストする方法を示します。
**重要**
AWS Event Fork Pipelines サンプルアプリケーションのデプロイが完了した後に不要なコストが発生しないようにするには、その CloudFormation スタックを削除します。詳細については、「AWS CloudFormation ユーザーガイド」**の「[CloudFormation コンソールのスタックを削除](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/cfn-console-delete-stack.html)」を参照してください。
# AWS Event Fork Pipelines ユースケースの例
次のシナリオでは、Event Fork Pipelines を使用する AWS イベント駆動型のサーバーレス e コマースアプリケーションについて説明します。この[例の e コマースアプリケーションを](https://serverlessrepo.aws.amazon.com/applications/arn:aws:serverlessrepo:us-east-1:077246666028:applications~fork-example-ecommerce-checkout-api) で使用し、 AWS Serverless Application Repository AWS Lambda コンソール AWS アカウント を使用して にデプロイできます。ここでテストしてGitHub でソースコードを調べることができます。
![\[AWS のサービスを統合するサーバーレス e コマースアプリケーションのアーキテクチャ。e コマースのユーザーによる API Gateway 経由での注文の実行から、注文の保存、検索分析、再生などのさまざまな処理パイプラインまでのフローを示しています。Amazon SNS、Lambda、Amazon SQS、DynamoDB、Kibana を介してイベントが管理され、分析されることを示しています。\]](http://docs.aws.amazon.com/ja_jp/sns/latest/dg/images/sns-fork-example-use-case.png)
この e コマースアプリケーションは、API Gateway によってホストされ、 AWS Lambda 関数 によってバックアップされた RESTful API を通じて購入者からの注文を受け取ります`CheckoutApiBackendFunction`。この関数は、すべての受注を `CheckoutEventsTopic` という名前の Amazon SNS トピックに発行します。このトピックでは、これらの受注を 4 つの異なるパイプラインにファンアウトします。
最初のパイプラインは、e コマースアプリケーションの所有者によって設計および実装された通常のチェックアウト処理パイプラインです。このパイプラインには、受信したすべての注文をバッファ`CheckoutQueue`する Amazon SQS キュー、これらの注文を処理するためにキューをポーリング`CheckoutFunction`する という名前の AWS Lambda 関数、およびすべての注文を安全に保存する DynamoDB テーブル`CheckoutTable`があります。
## AWS Event Fork Pipelines の適用
e コマースアプリケーションのコンポーネントは、主要ビジネスロジックを処理します。ただし、e コマースアプリケーションの所有者は以下にも対処する必要があります。
+ **コンプライアンス** - 安全な、圧縮されたバックアップの保管時の暗号化と機密情報のサニタイズ
+ **レジリエンス** - フルフィルメントプロセスの中断が発生した場合の最新の注文の再生
+ **検索可能性** - 受注に対する分析の実行とメトリクスの生成
このイベント処理ロジックを実装する代わりに、アプリケーション所有者は AWS Event Fork Pipelines を `CheckoutEventsTopic` Amazon SNS トピックにサブスクライブできます。
+ [イベントのストレージおよびバックアップパイプライン](sns-fork-pipeline-as-subscriber.md#sns-fork-event-storage-and-backup-pipeline) は、データを変換して、クレジットカードの詳細の削除、データの 60 秒間のバッファ処理、GZIP を使用した圧縮、Amazon S3 のデフォルトのカスタマーマネージドキーを使用した暗号化を行うように設定されています。このキーは によって管理 AWS され、 AWS Key Management Service () を利用しますAWS KMS。
詳細については、「*Amazon Data Firehose デベロッパーガイド*」の「[送信先の Amazon S3 の選択](https://docs.aws.amazon.com/firehose/latest/dev/create-destination.html#create-destination-s3)」、「[Amazon Data Firehose データ送信](https://docs.aws.amazon.com/firehose/latest/dev/data-transformation.html)」、および「[設定](https://docs.aws.amazon.com/firehose/latest/dev/create-configure.html) 」を参照してください。
+ [イベントの検索および分析パイプライン](sns-fork-pipeline-as-subscriber.md#sns-fork-event-search-and-analytics-pipeline) には、30 秒間のインデックス再試行期間、検索ドメインでインデックスの作成に失敗した注文を保存するためのバケット、およびインデックスを作成した注文のセットを制限するためのフィルターポリシーが設定されています。
詳細については、「*Amazon Data Firehose デベロッパーガイド*」の「[宛先の OpenSearch Service の選択](https://docs.aws.amazon.com/firehose/latest/dev/create-destination.html#create-destination-elasticsearch)」を参照してください。
+ [イベントの再生パイプライン](sns-fork-pipeline-as-subscriber.md#sns-fork-event-replay-pipeline) には、e コマースアプリケーションの所有者によって設計および実装された通常の注文処理パイプラインの Amazon SQS キュー部分が設定されています。
詳細については、『*Amazon Simple Queue Service デベロッパーガイド*』の「[キーの名前と URL](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/sqs-general-identifiers.html#queue-name-url)」を参照してください。
次の JSON フィルターポリシーは、イベントの検索および分析パイプラインの設定で設定されます。これは、合計金額が 100 USD 以上の受注とのみ一致します。詳細については、「[Amazon SNS メッセージフィルター処理](sns-message-filtering.md)」を参照してください。
```
{
"amount": [{ "numeric": [ ">=", 100 ] }]
}
```
AWS Event Fork Pipelines パターンを使用すると、e コマースアプリケーションの所有者は、イベント処理の差別化ロジックのコーディングに従うことが多い開発オーバーヘッドを回避できます。代わりに、 AWS Event Fork Pipelines を から直接 AWS Serverless Application Repository にデプロイできます AWS アカウント。
# ステップ 1: サンプル Amazon SNS アプリケーションをデプロイする
1. [AWS Lambda コンソール](https://console.aws.amazon.com/lambda/) にサインインします。
1. ナビゲーションパネルで [**関数**] を選択し、[**関数の作成**] を選択します。
1. [**関数の作成**] ページで、次の操作を実行します。
1. [**サーバーレスアプリケーションリポジトリ**の参照]、**[パブリックアプリケーション]**、**[カスタム IAM ロールまたはリソースポリシーを作成するアプリケーションの表示] を選択します**。
1. `fork-example-ecommerce-checkout-api` を検索し、このアプリケーションを選択します。
1. [**fork-example-ecommerce-checkout-api**] ページで、以下の操作を行います。
1. [**アプリケーション設定**] セクションで、[**アプリケーション名**] に名前 (`fork-example-ecommerce-my-app` など) を入力します。
**注記**
リソースを後で簡単に見つけられるように、プレフィックス `fork-example-ecommerce` を保持します。
名前は、デプロイごとに一意にする必要があります。アプリケーション名を再利用すると、デプロイは (新しいスタックを作成するのではなく) 以前にデプロイされた CloudFormation スタックのみを更新します。
1. (オプション) アプリケーションの Lambda 関数の実行のためも以下の **LogLevel** 設定のいずれかを入力します。
+ `DEBUG`
+ `ERROR`
+ `INFO` (デフォルト)
+ `WARNING`
1. [**このアプリケーションがカスタム IAM ロール、リソースポリシーを作成し、ネストされたアプリケーションをデプロイすることを承認します**] を選択して、ページの下部にある [**デプロイ**] を選択します。
[**fork-example-ecommerce-*my-app* のデプロイステータス**] ページで、Lambdaが [**アプリケーションをデプロイ中**] ステータスを表示します。
**リソース**セクションで、スタックの作成 CloudFormation を開始し、各リソースの **CREATE\$1IN\$1PROGRESS** ステータスを表示します。プロセスが完了すると、 は **CREATE\$1COMPLETE** ステータス CloudFormation を表示します。
**注記**
すべてのリソースがデプロイされるまで 20～30 分かかる場合があります。
デプロイが完了すると、Lambda によって [**アプリケーションはデプロイ済みです**] ステータスが表示されます。
# ステップ 2: SNS にリンクされたサンプルアプリケーションを実行する
1. AWS Lambda コンソールのナビゲーションパネルで、**アプリケーション**を選択します。
1. [**アプリケーション**] ページの検索フィールドで、`serverlessrepo-fork-example-ecommerce-my-app` を検索し、そのアプリケーションを選択します。
1. [**リソース**] セクションで、以下の操作を行います。
1. タイプが **ApiGateway RestApi** であるリソースを見つけるには、すべてのリソースを [**タイプ**] (`ServerlessRestApi` など) でソートし、リソースを展開します。
1. 2 つのネストされたリソース (**ApiGateway デプロイ**タイプと **ApiGateway ステージ**タイプ) が表示されます。
1. リンク [**Prod API エンドポイント**] をコピーし、これに `/checkout` を付加します。次に例を示します。
```
https://abcdefghij.execute-api.us-east-2.amazonaws.com/Prod/checkout
```
1. 次の JSON を `test_event.json` という名前のファイルにコピーします。
```
{
"id": 15311,
"date": "2019-03-25T23:41:11-08:00",
"status": "confirmed",
"customer": {
"id": 65144,
"quantity": 2,
"price": 25.00,
"subtotal": 50.00
}]
}
```
1. API エンドポイントに HTTPS リクエストを送信するには、`curl` コマンドを実行してサンプルイベントペイロードを入力として渡します。次に例を示します。
```
curl -d "$(cat test_event.json)" https://abcdefghij.execute-api.us-east-2.amazonaws.com/Prod/checkout
```
API は、次の空のレスポンスを返し、実行が成功したことを示します。
```
{ }
```
# ステップ 3: Amazon SNS アプリケーションとパイプラインのパフォーマンスを検証する
## ステップ 1: サンプルのチェックアウトパイプラインの実行を検証する
1. [Amazon DynamoDB コンソール](https://console.aws.amazon.com/dynamodb/)にサインインします。
1. ナビゲーションパネルで、[**テーブル**] を選択します。
1. `serverlessrepo-fork-example` を検索して `CheckoutTable` を選択します。
1. テーブルの詳細ページで [**項目**] を選択し、作成済みの項目を選択します。
保存済みの属性が表示されます。
## ステップ 2: イベントのストレージおよびバックアップパイプラインの実行を検証する
1. [[Amazon S3 コンソール](https://console.aws.amazon.com/s3/)] にサインインします。
1. ナビゲーションパネルで [**バケット**] を選択します。
1. `serverlessrepo-fork-example` を検索して、`CheckoutBucket` を選択します。
1. `.gz` を拡張子とするファイルが見つかるまで、ディレクトリ階層を移動します。
1. ファイルをダウンロードするには、[**アクション**]、[**開く**] の順に選択します。
1. パイプラインには、コンプライアンスの理由でクレジットカード情報をサニタイズする Lambda 関数が設定されています。
保存済みの JSON ペイロードにクレジットカード情報が含まれていないことを確認するために、ファイルを解凍します。
## ステップ 3: イベントの検索および分析パイプラインの実行を検証する
1. [OpenSearch Service コンソール](https://console.aws.amazon.com/aos/)にサインインします。
1. ナビゲーションパネルの [**My domains**] で、`serverl-analyt` というプレフィックスが付いたドメインを選択します。
1. パイプラインには、数値一致条件を設定する Amazon SNS サブスクリプションフィルターポリシーが設定されています。
金額が 100 USD を超える注文を参照するためにイベントのインデックスが作成されていることを確認するには、[**serverl-analyt-*abcdefgh1ijk***] ページで、[**インデックス**]、[**checkout\$1events**] の順に選択します。
## ステップ 4: イベントの再生パイプラインの実行を検証する
1. [Amazon SQS コンソール](https://console.aws.amazon.com/sqs/)にサインインします。
1. キューのリストで、`serverlessrepo-fork-example` を検索して `ReplayQueue` を選択します。
1. **[メッセージの送信と受信]** を選択します。
1. **[Send and receive messages in fork-example-ecommerce-*my-app*...ReplayP-ReplayQueue-*123ABCD4E5F6*]** (fork-example-ecommerce-my-app...ReplayP-ReplayQueue-123ABCD4E5F6 のメッセージの表示/削除) ダイアログボックスで、**[Poll for messages]** (メッセージのポーリング) を選択します。
1. イベントがキューに入っていることを確認するには、キューに表示されているメッセージの横にある [**詳細**] を選択します。
# ステップ 4: 復旧のために問題をシミュレートしてイベントを再生する
## ステップ 1: シミュレートした問題を有効にして別の API リクエストを送信する
1. [AWS Lambda コンソール](https://console.aws.amazon.com/lambda/) にサインインします。
1. ナビゲーションパネルで [**関数**] を選択します。
1. `serverlessrepo-fork-example` を検索して `CheckoutFunction` を選択します。
1. [**fork-example-ecommerce-*my-app*-CheckoutFunction-*ABCDEF*...**] ページの [**環境変数**] セクションで、**BUG\$1ENABLED** 変数を **true** に設定して [**保存**] を選択します。
1. 次の JSON を `test_event_2.json` という名前のファイルにコピーします。
```
{
"id": 9917,
"date": "2019-03-26T21:11:10-08:00",
"status": "confirmed",
"customer": {
"id": 56999,
"quantity": 1,
"price": 75.00,
"subtotal": 75.00
}]
}
```
1. API エンドポイントに HTTPS リクエストを送信するには、`curl` コマンドを実行してサンプルイベントペイロードを入力として渡します。次に例を示します。
```
curl -d "$(cat test_event_2.json)" https://abcdefghij.execute-api.us-east-2.amazonaws.com/Prod/checkout
```
API は、次の空のレスポンスを返し、実行が成功したことを示します。
```
{ }
```
## ステップ 2: シミュレートしたデータの破損を検証する
1. [Amazon DynamoDB コンソール](https://console.aws.amazon.com/dynamodb/)にサインインします。
1. ナビゲーションパネルで、[**テーブル**] を選択します。
1. `serverlessrepo-fork-example` を検索して `CheckoutTable` を選択します。
1. テーブルの詳細ページで [**項目**] を選択し、作成済みの項目を選択します。
保存済みの属性が表示されます。一部の属性は [**CORRUPTED\$1**] とマークされています。
## ステップ 3: シミュレートした問題を無効にする
1. [AWS Lambda コンソール](https://console.aws.amazon.com/lambda/) にサインインします。
1. ナビゲーションパネルで [**関数**] を選択します。
1. `serverlessrepo-fork-example` を検索して `CheckoutFunction` を選択します。
1. [**fork-example-ecommerce-*my-app*-CheckoutFunction-*ABCDEF*...**] ページの [**環境変数**] セクションで、**BUG\$1ENABLED** 変数を **false** に設定して [**保存**] を選択します。
## ステップ 4: 再生を有効にして問題から復旧する
1. AWS Lambda コンソールのナビゲーションパネルで、**関数**を選択します。
1. `serverlessrepo-fork-example` を検索して `ReplayFunction` を選択します。
1. [**Designer**] セクションを展開して [**SQS**] タイルを選択し、次に [**SQS**] セクションで [**有効**] を選択します。
**注記**
Amazon SQS のイベントソーストリガーが有効になるまで約 1 分かかります。
1. [**保存**] を選択します。
1. 復旧された属性を表示するには、Amazon DynamoDB コンソールに戻ります。
1. 再生を無効にするには、 AWS Lambda コンソールに戻り、 の Amazon SQS イベントソーストリガーを無効にします`ReplayFunction`。
# AWS Event Fork Pipelines を 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 の仕組み](sns-fork-pipeline-as-subscriber.md#how-sns-fork-works)」を参照してください。
このセクションでは、 を使用してパイプライン AWS マネジメントコンソール をデプロイし、 AWS Event Fork Pipelines を Amazon SNS トピックにサブスクライブする方法について説明します。開始する前に、[Amazon SNS トピック](sns-create-topic.md)を作成します。
パイプラインを構成するリソースを削除するには、 AWS Lambda コンソールの の**アプリケーション**ページでパイプラインを見つけ、**SAM テンプレートセクション**を展開し、**CloudFormation スタック**を選択し、**その他のアクション**、**スタックの削除**を選択します。
# イベントのストレージとバックアップパイプラインを Amazon SNS にデプロイしてサブスクライブする
| |
| --- |
| イベントのアーカイブと分析のために、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)」を参照してください。 |
このページでは、[イベントのストレージおよびバックアップパイプライン](sns-fork-pipeline-as-subscriber.md#sns-fork-event-storage-and-backup-pipeline)をデプロイして Amazon SNS トピックにサブスクライブする方法を説明します。このプロセスは、パイプラインに関連付けられた AWS SAM テンプレートを自動的に CloudFormation スタックに変換し、スタックを にデプロイします AWS アカウント。また、このプロセスでは、イベントのストレージおよびバックアップパイプラインを構成する、以下のようなリソースのセットを作成して設定します。
+ Amazon SQS キュー
+ Lambda function
+ Firehose 配信ストリーム
+ Amazon S3 バックアップバケット
Amazon S3 バケットを送信先としてストリームを設定する方法の詳細については、「*Amazon Data Firehose API リファレンス*」の「`[S3DestinationConfiguration](https://docs.aws.amazon.com/firehose/latest/APIReference/API_S3DestinationConfiguration.html)`」を参照してください。
イベントの変換、イベントバッファ処理の設定、イベント圧縮の設定、およびイベント暗号化の設定の詳細については、「*Amazon Data Firehose デベロッパーガイド*」の「[配信ストリームの作成](https://docs.aws.amazon.com/firehose/latest/dev/basic-create.html)」を参照してください。
イベントのフィルター処理の詳細については、このガイドの「[Amazon SNS サブスクリプションフィルターポリシー](sns-subscription-filter-policies.md)」を参照してください。
1. [AWS Lambda コンソール](https://console.aws.amazon.com/lambda/) にサインインします。
1. ナビゲーションパネルで [**関数**] を選択し、[**関数の作成**] を選択します。
1. [**関数の作成**] ページで、次の操作を実行します。
1. [**サーバーレスアプリケーションリポジトリ**の参照]、**[パブリックアプリケーション]**、**[カスタム IAM ロールまたはリソースポリシーを作成するアプリケーションの表示] を選択します**。
1. `fork-event-storage-backup-pipeline` を検索し、このアプリケーションを選択します。
1. [**fork-event-storage-backup-pipeline**] ページで、以下の操作を行います。
1. [**アプリケーション設定**] セクションで、[**アプリケーション名**] に名前 (`my-app-backup` など) を入力します。
**注記**
名前は、デプロイごとに一意にする必要があります。アプリケーション名を再利用すると、デプロイは (新しいスタックを作成するのではなく) 以前にデプロイされた CloudFormation スタックのみを更新します。
1. (オプション) **[BucketArn]** に、着信イベントのロード先となる Amazon S3 バケットの ARN を入力します。値を入力しない場合、 AWS アカウントに新しい Amazon S3 バケットが作成されます。
1. (オプション) [**DataTransformationFunctionArn**] に、着信イベントを変換する Lambda 関数の ARN を入力します。値を入力しないと、データ変換は無効になります。
1. (オプション) アプリケーションの Lambda 関数の実行のためも以下の **LogLevel** 設定のいずれかを入力します。
+ `DEBUG`
+ `ERROR`
+ `INFO` (デフォルト)
+ `WARNING`
1. [**TopicArn**] に、このフォークパイプラインのインスタンスをサブスクライブする Amazon SNS トピックの ARN を入力します。
1. (オプション) [**StreamBufferingIntervalInSeconds**] および [**StreamBufferingSizeInMBs**] に、着信イベントのバッファ処理を設定するための値を入力します。値を入力しないと、300 秒と 5 MB が使用されます。
1. (オプション) 着信イベントを圧縮する形式として次の [**StreamCompressionFormat**] 設定のいずれかを入力します。
+ `GZIP`
+ `SNAPPY`
+ `UNCOMPRESSED` (デフォルト)
+ `ZIP`
1. (オプション) **[StreamPrefix]** に、Amazon S3 バックアップバケットに保存されているファイルを指定するための文字列プレフィックスを入力します。値を入力しないと、プレフィックスは使用されません。
1. (オプション) [**SubscriptionFilterPolicy**] に、着信イベントをフィルター処理するために使用する Amazon SNS サブスクリプションフィルターポリシーを JSON 形式で入力します。フィルターポリシーは、OpenSearch Service インデックスでインデックスを作成するイベントを決定します。値を入力しないと、フィルター処理は使用されません (すべてのイベントにインデックスが作成されます)。
1. (オプション)**SubscriptionFilterPolicyScope** には、文字列 `MessageBody` または `MessageAttributes` を入力して、ペイロードベースまたは属性ベースのメッセージフィルタリングを有効にします。
1. [**I acknowledge that this app creates custom IAM roles, resource policies and deploys nested applications.**] を選択して、[**デプロイ**] を選択します。
[***my-app* のデプロイステータス**] ページに、Lambda によって **[Your application is being deployed**] ステータスが表示されます。
**リソース**セクションで、スタックの作成 CloudFormation を開始し、各リソースの **CREATE\$1IN\$1PROGRESS** ステータスを表示します。プロセスが完了すると、 は **CREATE\$1COMPLETE** ステータス CloudFormation を表示します。
デプロイが完了すると、Lambda によって [**アプリケーションはデプロイ済みです**] ステータスが表示されます。
Amazon SNS トピックに発行されたメッセージは、イベントのストレージおよびバックアップパイプラインによってプロビジョニングされた Amazon S3 バックアップバケットに自動的に保存されます。
# イベントの検索および分析パイプラインを Amazon SNS にデプロイしてサブスクライブする
| |
| --- |
| イベントのアーカイブと分析のために、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)」を参照してください。 |
このページでは、[イベントの検索および分析パイプライン](sns-fork-pipeline-as-subscriber.md#sns-fork-event-search-and-analytics-pipeline)をデプロイして Amazon SNS トピックにサブスクライブする方法を示します。このプロセスは、パイプラインに関連付けられた AWS SAM テンプレートを自動的に CloudFormation スタックに変換し、スタックを にデプロイします AWS アカウント。また、このプロセスでは、イベントの検索および分析パイプラインを構成する、以下のようなリソースのセットを作成して設定します。
+ Amazon SQS キュー
+ Lambda function
+ Firehose 配信ストリーム
+ Amazon OpenSearch Service ドメイン
+ Amazon S3 配信不能バケット
インデックスを送信先としてストリームを設定する方法の詳細については、「*Amazon Data Firehose API リファレンス*」の「`[ElasticsearchDestinationConfiguration](https://docs.aws.amazon.com/firehose/latest/APIReference/API_ElasticsearchDestinationConfiguration.html)`」を参照してください。
イベントの変換、イベントバッファ処理の設定、イベント圧縮の設定、およびイベント暗号化の設定の詳細については、「*Amazon Data Firehose デベロッパーガイド*」の「[配信ストリームの作成](https://docs.aws.amazon.com/firehose/latest/dev/basic-create.html)」を参照してください。
イベントのフィルター処理の詳細については、このガイドの「[Amazon SNS サブスクリプションフィルターポリシー](sns-subscription-filter-policies.md)」を参照してください。
1. [AWS Lambda コンソール](https://console.aws.amazon.com/lambda/) にサインインします。
1. ナビゲーションパネルで [**関数**] を選択し、[**関数の作成**] を選択します。
1. [**関数の作成**] ページで、次の操作を実行します。
1. [**サーバーレスアプリケーションリポジトリ**の参照]、**[パブリックアプリケーション]**、**[カスタム IAM ロールまたはリソースポリシーを作成するアプリケーションの表示] を選択します**。
1. `fork-event-search-analytics-pipeline` を検索し、このアプリケーションを選択します。
1. [**fork-event-search-analytics-pipeline**] ページで、以下の操作を行います。
1. [**アプリケーション設定**] セクションで、[**アプリケーション名**] に名前 (`my-app-search` など) を入力します。
**注記**
名前は、デプロイごとに一意にする必要があります。アプリケーション名を再利用すると、デプロイは (新しいスタックを作成するのではなく) 以前にデプロイされた CloudFormation スタックのみを更新します。
1. (オプション) **[DataTransformationFunctionArn**] に、着信イベントの変換に使用する Lambda 関数の ARN を入力します。値を入力しないと、データ変換は無効になります。
1. (オプション) アプリケーションの Lambda 関数の実行のためも以下の **LogLevel** 設定のいずれかを入力します。
+ `DEBUG`
+ `ERROR`
+ `INFO` (デフォルト)
+ `WARNING`
1. (オプション) **[SearchDomainArn]** に、OpenSearch Service ドメインの ARN を入力します。このドメインは、必要なコンピューティングおよびストレージ機能を設定するクラスターです。値を入力しないと、新しいドメインがデフォルト設定で作成されます。
1. [**TopicArn**] に、このフォークパイプラインのインスタンスをサブスクライブする Amazon SNS トピックの ARN を入力します。
1. **[SearchIndexName]** に、イベントの検索と分析用の OpenSearch Service インデックスの名前を入力します。
**注記**
インデックス名には、次の制限が適用されます。
大文字を含めることはできません
次の文字を含めることはできません: `\ / * ? " < > | ` , #`
次の文字で始めることはできません: `- + _`
次の形式にすることはできません: `. ..`
80 文字より長くすることはできません
255 バイトより長くすることはできません
コロンを含めることはできません (OpenSearch Service 7.0 から)
1. (オプション) OpenSearch Service インデックスのローテーション期間に、以下の **[SearchIndexRotationPeriod]** 設定のいずれかを入力します。
+ `NoRotation` (デフォルト)
+ `OneDay`
+ `OneHour`
+ `OneMonth`
+ `OneWeek`
インデックスのローテーションでは、インデックス名にタイムスタンプを付加し、古いデータの有効期限切れをわかりやすくします。
1. **[SearchTypeName]** に、インデックスでイベントを整理するための OpenSearch Service タイプの名前を入力します。
**注記**
OpenSearch Service タイプ名には任意の文字 (null バイトを除く) を含めることができますが、先頭に `_` を使用することはできません。
OpenSearch Service 6.x では、インデックスあたり 1 つのタイプのみが存在できます。別のタイプが既にある既存のインデックスに新しいタイプを指定すると、Firehose はランタイムエラーを返します。
1. (オプション) [**StreamBufferingIntervalInSeconds**] および [**StreamBufferingSizeInMBs**] に、着信イベントのバッファ処理を設定するための値を入力します。値を入力しないと、300 秒と 5 MB が使用されます。
1. (オプション) 着信イベントを圧縮する形式として次の [**StreamCompressionFormat**] 設定のいずれかを入力します。
+ `GZIP`
+ `SNAPPY`
+ `UNCOMPRESSED` (デフォルト)
+ `ZIP`
1. (オプション) **[StreamPrefix]** に、Amazon S3 配信不能バケットに保存されているファイルを指定するための文字列プレフィックスを入力します。値を入力しないと、プレフィックスは使用されません。
1. (オプション) **[StreamRetryDurationInSecons]** に、Firehose が OpenSearch Service インデックスでイベントのインデックスを作成できない場合の再試行期間を入力します。値を入力しないと、300 秒が使用されます。
1. (オプション) [**SubscriptionFilterPolicy**] に、着信イベントをフィルター処理するために使用する Amazon SNS サブスクリプションフィルターポリシーを JSON 形式で入力します。フィルターポリシーは、OpenSearch Service インデックスでインデックスを作成するイベントを決定します。値を入力しないと、フィルター処理は使用されません (すべてのイベントにインデックスが作成されます)。
1. [**I acknowledge that this app creates custom IAM roles, resource policies and deploys nested applications.**] を選択して、[**デプロイ**] を選択します。
[***my-app-search* のデプロイステータス**] ページに、Lambda によって [**Your application is being deployed**] ステータスが表示されます。
**リソース**セクションで、スタックの作成 CloudFormation を開始し、各リソースの **CREATE\$1IN\$1PROGRESS** ステータスを表示します。プロセスが完了すると、 は **CREATE\$1COMPLETE** ステータス CloudFormation を表示します。
デプロイが完了すると、Lambda によって [**アプリケーションはデプロイ済みです**] ステータスが表示されます。
Amazon SNS トピックに発行されたメッセージは、イベントの検索および分析パイプラインによってプロビジョニングされた OpenSearch Service インデックスで自動的にインデックスが作成されます。パイプラインでイベントのインデックスを作成できない場合、イベントは Amazon S3 配信不能バケットに保存されます。
# Amazon SNS 統合によるイベントの再生パイプラインのデプロイ
このページでは、[[イベントの再生パイプライン](sns-fork-pipeline-as-subscriber.md#sns-fork-event-replay-pipeline)] をデプロイして Amazon SNS トピックにサブスクライブする方法を示します。このプロセスは、パイプラインに関連付けられた AWS SAM テンプレートを自動的に CloudFormation スタックに変換し、スタックを にデプロイします AWS アカウント。また、このプロセスでは、イベントの再生パイプラインを構成する Amazon SQS キューや Lambda 関数などのリソースのセットを作成して設定します。
イベントのフィルター処理の詳細については、このガイドの「[Amazon SNS サブスクリプションフィルターポリシー](sns-subscription-filter-policies.md)」を参照してください。
1. [AWS Lambda コンソール](https://console.aws.amazon.com/lambda/) にサインインします。
1. ナビゲーションパネルで [**関数**] を選択し、[**関数の作成**] を選択します。
1. [**関数の作成**] ページで、次の操作を実行します。
1. [**サーバーレスアプリケーションリポジトリ**の参照]、**[パブリックアプリケーション]**、**[カスタム IAM ロールまたはリソースポリシーを作成するアプリケーションの表示] を選択します**。
1. `fork-event-replay-pipeline` を検索し、このアプリケーションを選択します。
1. [**fork-event-replay-pipeline**] ページで、以下の操作を行います。
1. [**アプリケーション設定**] セクションで、[**アプリケーション名**] に名前 (`my-app-replay` など) を入力します。
**注記**
名前は、デプロイごとに一意にする必要があります。アプリケーション名を再利用すると、デプロイは (新しいスタックを作成するのではなく) 以前にデプロイされた CloudFormation スタックのみを更新します。
1. (オプション) アプリケーションの Lambda 関数の実行のためも以下の **LogLevel** 設定のいずれかを入力します。
+ `DEBUG`
+ `ERROR`
+ `INFO` (デフォルト)
+ `WARNING`
1. (オプション) [**ReplayQueueRetentionPeriodInSeconds**] に、Amazon SQS 再生キューでメッセージを保持する時間を秒単位で入力します。値を入力しないと、1,209,600 秒 (14 日間) が使用されます。
1. [**TopicArn**] に、このフォークパイプラインのインスタンスをサブスクライブする Amazon SNS トピックの ARN を入力します。
1. [**DestinationQueueName**] に、Lambda 再生関数がメッセージを転送する先の Amazon SQS キューの名前を入力します。
1. (オプション) [**SubscriptionFilterPolicy**] に、着信イベントをフィルター処理するために使用する Amazon SNS サブスクリプションフィルターポリシーを JSON 形式で入力します。フィルターポリシーは、再生用にバッファ処理するイベントを決定します。値を入力しないと、フィルター処理は使用されません (すべてのイベントが再生用にバッファ処理されます)。
1. [**I acknowledge that this app creates custom IAM roles, resource policies and deploys nested applications.**] を選択して、[**デプロイ**] を選択します。
[***my-app-replay* のデプロイステータス**] ページで、Lambda によって [**Your application is being deployed**] ステータスが表示されます。
**リソース**セクションで、スタックの作成 CloudFormation を開始し、各リソースの **CREATE\$1IN\$1PROGRESS** ステータスを表示します。プロセスが完了すると、 は **CREATE\$1COMPLETE** ステータス CloudFormation を表示します。
デプロイが完了すると、Lambda によって [**アプリケーションはデプロイ済みです**] ステータスが表示されます。
Amazon SNS トピックに発行されたメッセージは、イベントの再生パイプラインによってプロビジョニングされた Amazon SQS キューで自動的に再生用にバッファ処理されます。
**注記**
再生は、デフォルトでは無効になります。再生を有効にするには、Lambda コンソールで関数のページに移動し、[**Designer**] セクションを展開して [**SQS**] タイルを選択します。次に [**SQS**] セクションで [**有効**] を選択します。