# Lambda のイベントソースマッピング問題のトラブルシューティング
<a name="troubleshooting-event-source-mapping"></a>

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

**注記**  
このセクションでは、Amazon SQS イベントソースを例として使用しますが、Lambda 関数用にメッセージをキューに入れるその他のイベントソースマッピングに原則が適用されます。

## スロットリングの特定と管理
<a name="esm-throttling"></a>

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 メトリクスで確認できます。

![\[デバッグオペレーションの図 10\]](http://docs.aws.amazon.com/ja_jp/lambda/latest/dg/images/debugging-ops-figure-10.png)


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

CloudWatch アラームでスロットリングを検出し、関数のスロットリングメトリクスが 0 より大きいときはいつでもアラームを設定できます。スロットリング問題を特定したら、いくつかの解決方法があります。
+ このリージョンの AWS サポートに同時実行数の増加をリクエストします。
+ 関数内のパフォーマンスの問題を特定して処理速度を向上させ、それによってスループットを向上させます。
+ 呼び出しごとに多くのメッセージが処理されるように、関数のバッチサイズを増やします。

## 処理関数のエラー
<a name="esm-processing-function"></a>

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

![\[デバッグオペレーションの図 11\]](http://docs.aws.amazon.com/ja_jp/lambda/latest/dg/images/debugging-ops-figure-11.png)


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

![\[デバッグオペレーションの図 12\]](http://docs.aws.amazon.com/ja_jp/lambda/latest/dg/images/debugging-ops-figure-12.png)


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

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

![\[デバッグオペレーションの図 13\]](http://docs.aws.amazon.com/ja_jp/lambda/latest/dg/images/debugging-ops-figure-13.png)


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

## バックプレッシャーの特定と処理
<a name="esm-backpressure"></a>

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

バックプレッシャーを解決する手順は、ワークロードによって異なります。主な目的が Lambda 関数による処理能力およびスループットの向上の場合、次のような方法がいくつかあります。
+ AWS サポートから特定のリージョンの同時実行数の増加をリクエストします。
+ 呼び出しごとに多くのメッセージが処理されるように、関数のバッチサイズを増やします。