Lambda@Edge とイベント駆動パターン

Lambda@Edgeを使用すると、中央のRegionではなく、世界中のCloudFront edge locations（エンドユーザーに近い場所）でLambda関数を実行できます。これにより、CDNレイヤーで追加レイテンシーをサブミリ秒に抑えながら、HTTPリクエストとレスポンスをカスタマイズできます。Lambda@Edge関数はグローバルにデプロイされ、CloudFrontのキャッシュヒットまたはキャッシュミスの各イベントで呼び出されるため、軽量なリクエスト操作に適しています。

Lambda@Edgeは、CloudFrontのリクエストライフサイクルにおける次の4つのポイントでトラフィックをインターセプトできます。

• Viewer Request：CloudFrontがビューワー（ユーザー）からリクエストを受信したとき、キャッシュを確認する前に実行されます
• Origin Request：CloudFrontがキャッシュミスをオリジンに転送するときに実行されます
• Origin Response：オリジンがレスポンスを返したとき、キャッシュする前に実行されます
• Viewer Response：CloudFrontがビューワーにレスポンスを返す前に実行されます

Lambda@Edgeには、通常のLambdaより厳しい制限があります。メモリは最大128 MB（ビューワーイベント）または1 GB（オリジンイベント）、タイムアウトは最大5秒（ビューワー）または30秒（オリジン）です。関数はus-east-1で作成し、CloudFront経由でエッジにデプロイする必要があります。VPC、環境変数、Lambda Layersはサポートされません。これらの制約から、Lambda@Edgeは重い処理ではなく、軽量な変換を目的として設計されています。

Lambda@Edgeは、A/Bテスト（Cookieに基づいてURLを別のオリジンパスに書き換える）、認証（オリジンに転送する前にエッジでJWTを検証する）、HTTPヘッダー操作（HSTS、CSP、X-Frame-Optionsなどのセキュリティヘッダーを追加する）、URL正規化（wwwありのURLをwwwなしにリダイレクトする、または末尾のスラッシュを強制する）、パーソナライゼーション（CloudFront-Viewer-Countryヘッダーのビューワーの国に基づいて異なるコンテンツを配信する）に適しています。

CloudFront Functionsは、ビューワーリクエストおよびビューワーレスポンスの段階でのみ実行される、超軽量なJavaScript関数です。実行時間の制限は2 msで、コストも大幅に低くなっています。URLの書き換え、ヘッダー操作、キャッシュキーの正規化などの単純なユースケースでは、より高速で安価なCloudFront FunctionsがLambda@Edgeより適しています。ネットワーク呼び出し、大きなペイロード、またはオリジンリクエスト／レスポンスのトリガーポイントへのアクセスが必要な場合は、Lambda@Edgeを使用します。

イベント駆動アーキテクチャは、発生した出来事を表すメッセージであるイベントを介してサービスを接続します。AWSでは、Lambdaが主要なイベントコンシューマーです。SQS、SNS、DynamoDB Streams、Kinesis、S3、EventBridgeなどからイベントを受信します。各イベントがLambdaの実行をトリガーするため、密結合することなく、システムが非同期かつ独立して反応できます。このパターンにより、疎結合、独立したスケーリング、障害分離を実現できます。

Lambdaは、SQSのイベントソースマッピングとして設定できます。Lambdaはキューをポーリングし、最大バッチサイズ分のメッセージ（Standardキューでは最大10,000件、FIFOでは10件）を取得して、1バッチにつき1回関数を呼び出します。関数が失敗すると、バッチ全体がキューに戻されます。呼び出し前により多くのメッセージを待機するバッチウィンドウを設定すると、スループットを向上できます。繰り返し失敗するメッセージには、送信元のSQSキューでDLQを使用してください。

DynamoDB Streamsは、アイテムレベルで発生するすべての変更（INSERT、MODIFY、REMOVE）を、順序付けられたイベントシーケンスとしてキャプチャします。Lambdaは、TRIM_HORIZON（最も古いレコードから開始）またはLATEST（最も新しいレコードから開始）を指定したイベントソースマッピングを使用して、ストリームから読み取ります。Lambdaはパーティション内の順序を維持してレコードを処理します。バッチに失敗すると、解決されるまで同じパーティションの後続処理がブロックされます。bisect on errorを使用して失敗したバッチを分割し、問題のあるレコードを特定してください。

LambdaはDynamoDB Streamsと同様にKinesisレコードを処理し、シャードごとに1つの同時実行を行います。主な設定項目には、parallelisation factor（1シャードあたり最大10件のLambda呼び出しを同時実行し、サブバッチを並列処理する）とenhanced fan-out（Lambdaコンシューマーにシャードあたり2 MB/sの専用スループットを提供する）があります。これらのオプションにより、シャード数を増やさずに、大量のストリームのスループットを大幅に向上できます。

Amazon EventBridgeは、AWSサービスとカスタムアプリケーションを接続するために推奨されるイベントバスです。イベントはバスに流れ込み、ルールによってパターンに基づいてフィルタリングされ、Lambda、SQS、Step Functionsなどのターゲットにルーティングされます。EventBridgeにより、イベントのプロデューサーとコンシューマーは完全に分離され、互いの存在を知る必要がありません。デフォルトのイベントバスはAWSサービスからのイベントを受信します。アプリケーションのイベントにはカスタムイベントバスを作成してください。

イベント駆動でよく使われるパターンがファンアウトです。1つのイベントによって、複数の処理パイプラインを並列に起動します。SNS topicに発行すると、複数のLambda関数サブスクリプションがそれぞれ独立して反応します。たとえば、注文発生イベントを、確認メールを送信するLambda、在庫を更新するLambda、倉庫に通知するLambdaへファンアウトできます。各コンシューマーは独立して個別にスケーリングされるため、1つのコンシューマーが他のコンシューマーをブロックすることはありません。

このレッスンで扱ったAWS Solutions Architect（SAA-C03）の概念について、理解度を確認しましょう。

このレッスンでは、Lambda@EdgeがCloudFront edge locationsで関数を実行し、認証、URLの書き換え、ヘッダー操作などのタスクに対応する4つのトリガーポイント（ビューワーリクエスト／レスポンス、オリジンリクエスト／レスポンス）を備えていること、CloudFront Functionsが単純なビューワー段階の変換に適した、より低コストかつ低レイテンシーの選択肢であること、そしてSQS、DynamoDB Streams、Kinesis、EventBridge、SNSファンアウトを使用したイベント駆動パターンにより、Lambdaがリアルタイムイベントに反応する疎結合アーキテクチャを実現できることを学びました。次はSQS StandardキューとFIFOキューについて学びます。