Amazon SQS イベントソースマッピングの作成と管理
Lambda で Amazon SQS メッセージを処理するには、キューを適切に設定し、Lambda イベントソースマッピングを作成します。
Lambda で使用するキューの設定
既存の Amazon SQS キューがない場合は、Lambda 関数のイベントソースとして機能するキューを作成します。次に、Lambda 関数がイベントの各バッチを処理するのに十分な時間を確保できるようにキューを設定します。
関数がレコードの各バッチを処理する時間を確保するには、ソースキューの可視性タイムアウトを、関数の設定タイムアウトの少なくとも 6 倍に設定します。追加の時間は、関数が前のバッチの処理中にスロットリングされた場合に、Lambda が再試行することを可能にします。
デフォルトでは、Lambda がバッチを処理しているときにエラーが発生すると、そのバッチ内のすべてのメッセージがキューに戻ります。可視性タイムアウトの後、メッセージは再び Lambda に表示されるようになります。部分的なバッチレスポンスを使用するようにイベントソースマッピングを設定することで、失敗したメッセージのみがキューに戻るようにすることができます。さらに、関数が 1 つのメッセージの処理に複数回失敗する場合、Amazon SQS はそのメッセージをデッドレターキューに送信できます。ソースキューの再処理ポリシーで、maxReceiveCount を少なくとも 5 に設定することをお勧めします。これにより、Lambda は、失敗したメッセージをデッドレターキューに直接送信する前に再試行を数回行う機会を確保できます。
Lambda 実行ロールのアクセス許可の設定
AWSLambdaSQSQueueExecutionRole AWS マネージドポリシーには、Lambda が Amazon SQS キューから読み取るために必要なアクセス許可が含まれています。関数の実行ロールにこのマネージドポリシーを追加できます。
オプションで、暗号化されたキューを使用している場合は、実行ロールに次の権限を追加する必要もあります。
SQS イベントソースマッピングの作成
イベントソースマッピングを作成し、キューから Lambda 関数に項目を送信するように Lambda に通知します。1 つの関数で複数のキューの項目を処理するには、複数のイベントソースマッピングを作成します。Lambda がターゲットの関数を呼び出すと、このイベントには設定可能なバッチサイズまでの複数の項目が含まれている可能性があります。
Amazon SQS から読み取るように関数を設定するには、AWSLambdaSQSQueueExecutionRole AWS マネージドポリシーを実行ロールにアタッチします。次に、以下の手順を使用して、コンソールから SQS イベントソースマッピングを作成します。
アクセス許可を追加してトリガーを作成するには
Lambda コンソールの関数ページ
を開きます。 -
関数の名前を選択します。
-
[Configuration] (設定) タブを開き、次に [Permissions] (アクセス許可) をクリックします。
-
[実行ロール] で、実行ロールのリンクを選択します。このリンクを選択すると、IAM コンソールでロールが開きます。
-
[アクセス許可を追加]、[ポリシーをアタッチ] の順に選択します。
-
[検索] フィールドに
AWSLambdaSQSQueueExecutionRoleを入力します。実行ロールにポリシーを追加 これは、関数が Amazon SQS キューから読み取るために必要なアクセス許可を含む AWS 管理ポリシーです。このポリシーの詳細については、「AWS マネージドポリシーリファレンス」の「AWSLambdaSQSQueueExecutionRole」を参照してください。 -
Lambda コンソールの関数に戻ります。[関数の概要] で [トリガーを追加] をクリックします。
-
トリガーのタイプを選択します。
-
必須のオプションを設定し、[Add] (追加) を選択します。
Lambda は、Amazon SQS イベントソースに対して以下の設定オプションをサポートしています。
- SQS キュー
-
レコードの読み取り元である Amazon SQS キュー。
- トリガーの有効化
-
イベントソースマッピングのステータス。[Enable trigger] (トリガーの有効化) はデフォルトで選択されています。
- バッチサイズ
-
各バッチで関数に送信されるレコードの最大数。標準キューの場合、最大 10,000 レコードまで可能です。FIFO キューの場合、最大値は 10 です。バッチサイズが 10 を超える場合は、バッチウィンドウ (
MaximumBatchingWindowInSeconds) も 1 秒以上に設定する必要があります。関数のタイムアウト
は、バッチの項目すべてを処理するために十分な時間を確保できるように設定します。項目の処理に長時間かかる場合には、より少ないバッチサイズを選択します。バッチサイズを大きくするとワークロードの効率を向上させることができ、非常に高速になるか、多くのコストがかかります。関数で予約された同時実行数を設定すると、同時実行数を 5 以上に設定した場合に、Lambda が関数を呼び出したときにスロットリングエラーが発生する可能性が少なくなります。 Lambda は、イベントの合計サイズが同期呼び出しの呼び出しペイロードサイズのクォータ (6 MB) を超えない限り、バッチ内のすべてのレコードを単一の呼び出しで関数に渡します。Lambda と Amazon SQS の両方が、レコードごとにメタデータを生成します。この追加のメタデータは合計ペイロードサイズに計上され、1 つのバッチで送信されるレコードの総数が設定されたバッチサイズよりも少なくなる可能性があります。Amazon SQS が送信するメタデータフィールドは可変長にすることができます。Amazon SQS メタデータフィールドの詳細については、「Amazon Simple Queue Service API リファレンス」の「ReceiveMessage」API 操作のドキュメントを参照してください。
- バッチウィンドウ
-
関数を呼び出すまでのレコード収集の最大時間 (秒) です。これが適用されるのは標準キューのみです。
0 秒を超えるバッチウィンドウを使用している場合は、キューの可視性タイムアウトに処理時間の増加を考慮する必要があります。キューの可視性タイムアウトは、関数のタイムアウトの 6 倍に
MaximumBatchingWindowInSecondsの値を加えた時間に設定することをお勧めします。これによりスロットリングエラーが発生した場合に Lambda 関数がイベントの各バッチを処理し、再試行する時間が許容されます。メッセージが使用可能になると、Lambda はメッセージのバッチ処理を開始します。Lambda は、関数を 5 回同時に呼び出すことで、一度に 5 つのバッチの処理を開始します。メッセージがまだ利用可能な場合、Lambda は関数のインスタンスを 1 分あたり最大 300 インスタンスまで追加し、最大 1,000 インスタンスまで増やします。関数のスケーリングと同時実行の詳細について理解するには、「Lambda 関数のスケーリング」を参照してください。
より多くのメッセージを処理するには、Lambda 関数を最適化してスループットを向上させることができます。詳細については、「AWS Lambda が Amazon SQS 標準キューでどのようにスケールするかを理解する
」を参照してください。 - 最大同時実行数
-
イベントソースが呼び出せる同時関数の最大数。詳細については、「Amazon SQS イベントソースの最大同時実行数の設定」を参照してください。
- フィルター条件
-
フィルター条件を追加して、Lambda が処理のために関数に送信するイベントを制御します。詳細については、「Lambda のイベントフィルタリング」を参照してください。
