AWS Simple Queue Service (SQS) は信頼性が高くスケーラブルなメッセージングソリューションを提供し、AWS Lambda はサーバーレスコンピューティング機能を提供します。これら 2 つのサービスを組み合わせることで、強力なイベント駆動型アーキテクチャが可能になります。このブログ記事では、SQS と Lambda の統合について詳しく見ていき、メッセージの消費と処理の背後にある仕組みを理解します。メッセージを個別またはバッチで処理するための利用可能なオプションを詳しく説明し、各アプローチの利点と考慮事項を強調します。さらに、バッチサイズ、バッチウィンドウ、最大同時実行数、キューの可視性タイムアウトなど、Lambda イベント ソース マッピングと SQS の重要な構成についても説明します。私たちオンクラウドAIこの記事を参考にして、SQS と Lambda の統合の威力を理解してください。
SQSとLambdaの統合を理解する
SQS と Lambda は、スケーラブルなイベント駆動型アーキテクチャを構築するための強力な統合を提供します。 Lambda イベント ソース マッピングを使用すると、SQS キューからのメッセージを非同期的に処理し、コンポーネントを分離して、信頼性の高いメッセージ配信を確保できます。 Lambda 関数は SQS キューをサブスクライブする場合、ポーリング メカニズムを使用してメッセージが到着するまで待機します。 Lambda はメッセージをバッチで処理します。 Lambda はバッチごとに関数を 1 回トリガーします。キューにさらに多くのメッセージがある場合、Lambda は 1,000 個の同時関数に拡張でき、1 分あたり最大 60 個の関数を追加できます。処理が正常に完了すると、Lambda はキューからメッセージを自動的に削除します。
Lambda を使用して SQS からのメッセージを消費する
SQS を使用すると、メッセージを個別またはバッチで処理できます。 Lambda イベント ソース マッピングは、標準の SQS キューの場合は最大 10,000 件のメッセージまたは 6 MB までの単一のバッチを含む、より大きなバッチをサポートします。対照的に、SDK では各 API 呼び出しを最大 10 件のメッセージに制限します。これは、SQS からメッセージを消費するときに、可能な限り Lambda イベント ソース マッピングを使用する必要がある理由の 1 つです。
メッセージを個別に処理すると、処理が高速になり、エラー処理が簡単になるという利点があります。ただし、バッチ処理の方が適切な状況もあります。バッチ処理は、より高いスループットや効率性が必要な場合、またはコストの最適化が重要な場合に役立ちます。
単一のメッセージの処理
Lambda で個々の SQS メッセージを使用するのは比較的簡単で、各メッセージは Lambda 関数の実行をトリガーする独立したイベントとして扱われます。メッセージ処理中に発生する可能性のある例外やエラーをキャッチするために、適切なエラー処理を実装することは依然として重要です。 Lambda 関数がメッセージを正常に処理すると、Lambda はキューからメッセージを自動的に削除します。ただし、関数の実行中にエラーが発生した場合、メッセージはキューに返され、さらに処理されるか再試行されます。これにより、エラーが発生した場合でもメッセージが失われず、失敗したメッセージを適切に処理および再処理できるようになります。
バッチメッセージの処理
Lambda が SQS キューからのメッセージのバッチを処理する場合、メッセージはキュー内に残りますが、キューの可視性タイムアウトに基づいて一時的に非表示になります (これについてはこのブログ投稿で後ほど詳しく説明します)。 Lambda 関数がメッセージのバッチを正常に処理すると、Lambda はキューからメッセージを自動的に削除します。ただし、関数がメッセージのバッチ処理中にエラーに遭遇した場合、そのバッチ内のすべてのメッセージがキューに再表示され、再び表示されるようになります。
メッセージが複数回処理されないようにするには、いくつかのオプションがあります。まず、イベントソースマッピングを構成して、バッチアイテムの失敗の報告関数応答で。これにより、関数コード内で失敗したメッセージを処理および追跡することができ、バッチを処理するときに推奨されるアプローチとなります。あるいは、DeleteMessage という Amazon SQS API アクションを使用して、Lambda 関数がメッセージを正常に処理したときにキューからメッセージを明示的に削除することもできます。この API 操作を使用して、メッセージが誤って再処理されないようにすることができます。
ReportBatchItemFailures 機能を利用して部分的に失敗したメッセージを返す方法の例を 2 つ示します。これにより、関数がメッセージを複数回処理することがなくなります。私は、batchItemFailures 関数の応答を構築し、Middy ミドルウェアを使用して、これを実行する方法を説明します。
注目すべき構成
Lambdaイベントソースマッピング
バッチサイズ
バッチサイズ（ バッチサイズ) 構成によって、各バッチで Lambda 関数に送信されるレコードの数が決まります。標準キューの場合、バッチ サイズを最大 10,000 レコードに設定できます。ただし、レコードがいくつ設定されていても、バッチ サイズの合計は 6 MB を超えないことに注意することが重要です。
バッチ処理ウィンドウ
バッチウィンドウ（ 最大バッチウィンドウ（秒）) 設定は、Lambda 関数を呼び出す前にレコードを収集する最大時間 (秒単位) を決定します。この構成は標準キューにのみ適用されることに注意してください。
同時接続の最大数
最大同時実行数（ スケーリング構成) 機能を使用すると、イベント ソース マッピングの同時呼び出しの最大数を設定できるようになり、Lambda で保持された同時実行性を使用するときに過剰な制限によって発生していた以前の問題が解消されます。この機能を使用すると、特に同じ機能を持つ複数のイベント ソース マッピングを使用する場合に、同時実行をより適切に制御できます。
SQS設定
キューの可視性タイムアウト
SQS の可視性タイムアウト ( 可視性タイムアウト) は、メッセージがコンシューマーによって取得された後、キュー内で非表示のままになる時間を決定する設定です。コンシューマーがキューからメッセージを受信すると、可視性タイムアウト期間中、そのメッセージは一時的に他のコンシューマーに対して非表示になります。 0 秒を超えるバッチ ウィンドウを選択した場合は、キューの可視性タイムアウト内での処理時間の増加を考慮する必要があります。可視性タイムアウトは、関数のタイムアウトの少なくとも6倍にバッチウィンドウを加えた値に設定することをお勧めします（ 最大バッチウィンドウ（秒）） 価値。これにより、Lambda 関数が各イベント バッチを処理し、スロットリング エラーによって発生する可能性のある再試行を処理するのに十分な時間を確保できるようになります。たとえば、関数のタイムアウトが 30 秒で、バッチ ウィンドウが 20 秒の場合。これにより、(30 x 6) + 20 = 200 秒に設定されます。
デッドレターキュー (DLQ)
Lambda がメッセージを処理できない場合、メッセージは再試行のためにキューに返されます。ただし、メッセージがキューに複数回追加され、不要な Lambda リソースが消費されるのを防ぐには、デッドレターキュー (DLQ) を指定して、失敗したメッセージをそのキューに送信することをお勧めします。失敗したメッセージの再試行回数を制御するには、最大受信数DLQ の値。メッセージが最大受信回数を超えて再キューに入れられると、そのメッセージは DLQ に移動されます。この方法により、メイン キューで処理せずに、これらの失敗したメッセージを後で処理できるようになります。
結論は
要約すると、SQS と Lambda の統合により、イベント駆動型アーキテクチャを構築するための強力でスケーラブルなソリューションが提供されます。イベント ソース マッピングを活用し、バッチ処理を構成し、デッドレター キューや可視性タイムアウトなどの注目すべき機能を利用することで、信頼性の高いメッセージ処理を保証し、リソース使用率を最適化できます。この統合を採用することで、分散システムの潜在能力を最大限に活用し、簡単に拡張できる回復力のあるアプリケーションを作成できます。
オンクラウドAIAWS エージェントとして、Amazon クラウド サービスの提供、Amazon クラウド サーバーの AWS 支払いのサポート、AWS 移行、AWS 運用保守ホスティングなどのサービスを提供します。関連するニーズがございましたら、お問い合わせください。オンクラウドAI。
