Lambda のイベントソースマッピング問題のトラブルシューティング

イベントソースマッピングに関連する Lambda の問題は複数のサービス間でデバッグを伴うため、より複雑になる可能性があります。さらに、イベントソースの動作は、使用される正確なイベントソースによって異なる場合があります。このセクションではイベントソースマッピングに関連する一般的な問題が一覧表示され、問題を特定してトラブルシューティングする方法に関するガイダンスが記載されます。

スロットリングの特定と管理

Lambda では、関数またはアカウントの同時実行制限に達するとスロットリングが発生します。Amazon SQS キューからメッセージを読み取る Lambda 関数がある次の例を検討してください。この Lambda 関数は 30 秒の呼び出しをシミュレートし、バッチサイズは 1 です。関数は 30 秒ごとに 1 つのメッセージのみを処理することを意味します。

const doWork = (ms) => new Promise(resolve => setTimeout(resolve, ms))

exports.handler = async (event) => {
    await doWork(30000)

}

このように呼び出し時間が長くなると、メッセージは処理される速度よりも速くキューに到着し始めます。アカウントの予約されていない同時実行数が 100 の場合、Lambda は 100 に同時実行数をスケールアップし、スロットリングが発生します。このパターンは、関数の CloudWatch メトリクスで確認できます。

関数の CloudWatch メトリクスにはエラーが表示されませんが、[同時実行数] のグラフには 100 の最大同時実行数に達したことが示されています。その結果、[スロットル] グラフにはスロットリングの実施が示されます。

CloudWatch アラームでスロットリングを検出し、関数のスロットリングメトリクスが 0 より大きいときはいつでもアラームを設定できます。スロットリング問題を特定したら、いくつかの解決方法があります。

処理関数のエラー

処理関数がエラーをスローした場合、Lambda はメッセージを SQS キューに返します。大量のエラーを防ぐため、Lambda は関数のスケーリングを防止します。CloudWatch の次の SQS メトリクスは、キュー処理の問題を示します。

特に、最も古いメッセージの経過時間および表示されるメッセージ数の両方が増加していますが、メッセージは削除されません。キューは増加し続けていますが、メッセージは処理されていません。処理 Lambda 関数の CloudWatch メトリクスもまた、問題があることを示しています。

エラー数のメトリクスはゼロではなく増加していますが、同時実行は減少し、スロットリングは停止しています。エラーによって Lambda が関数のスケールアップを停止したことを示しています。関数の CloudWatch ログには、エラーのタイプの詳細が示されます。

エラーの原因となっている関数を特定し、エラーを見つけて解決すると、この問題を解決することができます。エラーを修正して新しい関数コードをデプロイすると、CloudWatch メトリクスに処理が復旧したことが示されます。

こちらでは、[エラー数] メトリクスがゼロに低下し、[成功率] メトリクスが 100% に戻ります。[同時実行数] グラフで示されるように、Lambda は関数のスケールアップを再開しています。

バックプレッシャーの特定と処理

イベントプロデューサーが SQS キューのメッセージを Lambda 関数が処理できる速度よりも速く常時生成する場合、バックプレッシャーが発生します。この場合、表示されるメッセージのおよその数と一緒に、SQS モニタリングでは最も古いメッセージの経過時間が直線的に増加していることが示されます。CloudWatch アラームを使用し、キューのバックプレッシャーを検出できます。

バックプレッシャーを解決する手順は、ワークロードによって異なります。主な目的が Lambda 関数による処理能力およびスループットの向上の場合、次のような方法がいくつかあります。