Lambda における実行に関する問題点のトラブルシューティング
Lambda ランタイムが関数コードを実行すると、このイベントは、すでに他のイベントを処理中の関数のインスタンスで処理されるか、必要に応じて新しいインスタンスが初期化されます。関数が初期化されている間に、ハンドラーコードでイベントが処理されているときに、または関数からレスポンスが返される (または返されない) ときに、エラーが発生する場合があります。
関数の実行エラーは、コード、関数の設定、ダウンストリームのリソース、またはアクセス許可の問題に起因する場合があります。関数を直接呼び出した場合は、Lambda からのレスポンスに関数エラーが表示されます。イベントソースマッピングまたは別のサービスを通じて関数を非同期的に呼び出した場合は、ログ、配信不能キュー、または障害発生時の送信先にエラーが表示されることがあります。エラー処理オプションと再試行の動作は、関数を呼び出した方法とエラーの種類によって異なります。
関数コードまたは Lambda ランタイムからエラーが返された場合、Lambda からのレスポンスのステータスコードは 200 OK です。レスポンス内にエラーが存在することは、X-Amz-Function-Error という名前のヘッダーで示されます。400 および 500 シリーズのステータスコードは、呼び出しエラー用に予約されています。
Lambda: 実行に時間がかかり過ぎています
問題: 関数の実行に時間がかかり過ぎる。
Lambda でコードを実行すると、ローカルマシンよりもはるかに長い時間がかかる場合は、その関数で使用できるメモリまたは処理能力が制限されている可能性があります。メモリと CPU の両方を増やすには、メモリを追加して関数を設定します。
Lambda: ログやトレースが表示されません
問題: ログが CloudWatch Logs に表示されない。
問題: トレースが AWS X-Ray に表示されない。
関数には、CloudWatch Logs および X-Ray を呼び出すためのアクセス許可が必要です。その実行ロールを更新してアクセス許可を付与します。ログと追跡を有効にするには、以下の管理ポリシーを追加します。
-
AWSLambdaBasicExecutionRole
-
AWSXRayDaemonWriteAccess
関数にアクセス許可を追加する場合は、そのコードや設定にも些細な更新を行います。これにより、(古い認証情報により実行中の) 関数のインスタンスが、強制的に停止され置き換えられます。
注記
関数の呼び出し後にログが表示されるまで、5～10 分かかることがあります。
Lambda: 関数のログの一部が表示されない
問題: 適切な権限があっても、CloudWatch Logs に関数ログが見つからない
AWS アカウント が CloudWatch Logs のクォータ制限に達すると、CloudWatch は関数のロギングを抑制します。この場合、関数によって出力されたログの一部が CloudWatch Logs に表示されない場合があります。
関数がログを出力する頻度が高すぎて Lambda で処理できない場合、ログ出力が CloudWatch Logs に表示されない可能性もあります。Lambda は、関数がログを生成する速度でログを CloudWatch に送信できない場合、関数の実行が遅くなるのを防ぐためにログをドロップします。ログ スループットが 1 つのログ ストリームで 2 MB/秒を超えると、ログ記録が正常に行われない可能性があります。
関数が JSON 形式のログを使用するように設定されている場合、Lambda はログを削除するとき CloudWatch Logs に logsDropped イベントを送信しようとします。ただし、CloudWatch は、関数のログから受け入れることができるデータ量を調整していると、ログを受け取れない場合があります。そのため、Lambda がログを削除したときにレコードが常に表示されるとは限りません。
AWS アカウント が CloudWatch Logs のクォータ制限に達しているかどうかを確認するには、次の手順を実行します。
-
Service Quotas コンソール
を開きます。 -
ナビゲーションペインで、[AWS services] (AWS のサービス) を選択します。
-
[AWS サービス] リストから、Amazon CloudWatch Logs を検索します。
-
[Service Quotas] リストで、
CreateLogGroup throttle limit in transactions per second、CreateLogStream throttle limit in transactions per secondおよびPutLogEvents throttle limit in transactions per secondクォータを選択して使用状況を表示します。
また、アカウントの使用率がこれらのクォータに指定した制限を超えたときに警告するように CloudWatch アラームを設定することもできます。詳しくは、「Create a CloudWatch alarm based on a static threshold」をご覧ください。
CloudWatch Logs のデフォルトのクォータ制限がユースケースに十分ではない場合は、クォータの引き上げをリクエストできます。
Lambda: 関数は実行が終了する前に返します
問題: (Node.js) コードの実行が終了する前に関数が戻る
AWS SDK を含む多くのライブラリは、非同期的に動作します。レスポンスを待つ必要があるネットワーク呼び出しや別のオペレーションを実行すると、ライブラリは、オペレーションの進行状況をバックグラウンドで追跡するプロミスと呼ばれるオブジェクトを返します。
プロミスがレスポンスに解決されるまで待つには、await キーワードを使用します。これにより、プロミスがレスポンスを含むオブジェクトに解決されるまで、ハンドラーコードの実行がブロックされます。レスポンス内のデータをコードで使用する必要がない場合は、プロミスをランタイムに直接返すことができます。
一部のライブラリはプロミスを返しませんが、これらはプロミスを返すコードでラップできます。詳細については、「Node.js の Lambda 関数ハンドラーの定義」を参照してください。
AWS SDK: バージョンと更新
問題: ランタイムに含まれている AWS SDK が最新バージョンではない
問題: ランタイムに含まれている AWS SDK が自動的に更新される
スクリプト言語のランタイムには AWS SDK が含まれており、定期的に最新バージョンに更新されます。各ランタイムの現行バージョンは、ランタイムページに表示されます。より新しいバージョンの AWS SDK を使用したり、関数を特定のバージョンにロックしたりするには、ライブラリを関数コードでバンドルするか、Lambda レイヤーを作成します。依存関係を持つデプロイパッケージの作成の詳細については、以下のトピックを参照してください。
Python: ライブラリが正しくロードされません
問題: (Python) 一部のライブラリがデプロイパッケージから正しくロードされない
C または C++ で記述された拡張モジュールを持つライブラリは、Lambda (Amazon Linux) と同じプロセッサアーキテクチャの環境でコンパイルする必要があります。詳細については、「Python Lambda 関数で .zip ファイルアーカイブを使用する」を参照してください。
Java: Java 11 から Java 17 への更新後、関数によるイベントの処理に時間がかかる
問題: (Java) Java 11 から Java 17 への更新後、関数によるイベントの処理に時間がかかる
JAVA_TOOL_OPTIONS パラメータを使用して、コンパイラを調整します。Java 17 以降の Java バージョンの Lambda ランタイムによって、デフォルトのコンパイラオプションが変更されます。この変更により、実行時間の短い関数のコールドスタートに要する時間は短縮されますが、計算負荷が高く、実行時間が長い関数については、変更前の動作のほうが適しています。Java 11 の動作に戻すには、-XX:-TieredCompilation に JAVA_TOOL_OPTIONS を設定します。JAVA_TOOL_OPTIONS パラメータの詳細については、「JAVA_TOOL_OPTIONS 環境変数について」をご参照ください。
