次のシナリオでは、AWS Event Fork Pipelines を使用するイベント駆動型のサーバーレス e コマースアプリケーションについて説明します。この e コマースアプリケーション例
この e コマースアプリケーションでは、API Gateway でホストされ、AWS Lambda 関数 CheckoutApiBackendFunction
で支援された RESTful API を通じて購入者から注文を受けます。この関数は、すべての受注を CheckoutEventsTopic
という名前の Amazon SNS トピックに発行します。このトピックでは、これらの受注を 4 つの異なるパイプラインにファンアウトします。
最初のパイプラインは、e コマースアプリケーションの所有者によって設計および実装された通常のチェックアウト処理パイプラインです。このパイプラインには、すべての受注をバッファ処理する Amazon SQS CheckoutQueue
キュー 、キューをポーリングしてこれらの注文を処理する、CheckoutFunction
という名前の AWS Lambda 関数、およびすべての受注を安全に保存する DynamoDB テーブル CheckoutTable
があります。
AWS Event Fork Pipelines を適用する
e コマースアプリケーションのコンポーネントは、主要ビジネスロジックを処理します。ただし、e コマースアプリケーションの所有者は以下にも対処する必要があります。
-
コンプライアンス - 安全な、圧縮されたバックアップの保管時の暗号化と機密情報のサニタイズ
-
レジリエンス - フルフィルメントプロセスの中断が発生した場合の最新の注文の再生
-
検索可能性 - 受注に対する分析の実行とメトリクスの生成
このイベント処理ロジックを実装する代わりに、アプリケーション所有者は AWS Event Fork Pipelines を CheckoutEventsTopic
Amazon SNS トピックにサブスクライブできます。
-
イベントのストレージおよびバックアップパイプライン は、データを変換して、クレジットカードの詳細の削除、データの 60 秒間のバッファ処理、GZIP を使用した圧縮、Amazon S3 のデフォルトのカスタマーマネージドキーを使用した暗号化を行うように設定されています。このキーは、AWS によって管理され、AWS Key Management Service (AWS KMS) により動作します。
詳細については、「Amazon Data Firehose デベロッパーガイド」の「送信先の Amazon S3 の選択」、「Amazon Data Firehose データ送信」、および「設定 」を参照してください。
-
イベントの検索および分析パイプライン には、30 秒間のインデックス再試行期間、検索ドメインでインデックスの作成に失敗した注文を保存するためのバケット、およびインデックスを作成した注文のセットを制限するためのフィルターポリシーが設定されています。
詳細については、「Amazon Data Firehose デベロッパーガイド」の「宛先の OpenSearch Service の選択」を参照してください。
-
イベントの再生パイプライン には、e コマースアプリケーションの所有者によって設計および実装された通常の注文処理パイプラインの Amazon SQS キュー部分が設定されています。
詳細については、『Amazon Simple Queue Service デベロッパーガイド』の「キーの名前と URL」を参照してください。
次の JSON フィルターポリシーは、イベントの検索および分析パイプラインの設定で設定されます。これは、合計金額が 100 USD 以上の受注とのみ一致します。詳細については、「Amazon SNS メッセージフィルター処理」を参照してください。
{
"amount": [{ "numeric": [ ">=", 100 ] }]
}
AWS Event Fork Pipelines パターンを使用すると、e コマースアプリケーションの所有者は、イベント処理用の差別化につながらないロジックのコーディングに伴いがちな開発オーバーヘッドを回避できます。代わりに、所有者は AWS Event Fork Pipelines を AWS Serverless Application Repository から AWS アカウント 内に直接デプロイできます。