Kinesis データストリームトリガーが Lambda 関数を呼び出せないのはなぜですか?
Amazon Kinesis Data Streams を処理するためのイベントソースとして AWS Lambda を Amazon Kinesis データストリームと統合しましたが、関数が呼び出されません。
簡単な説明
Lambda 関数エラーの一般的な原因は以下のとおりです。
- Lambda 関数の実行ロールの権限が不十分
- Kinesis データストリームへの受信データなし
- Kinesis データストリーム、Lambda 関数、または Lambda 実行ロールの再作成によって非アクティブなイベントソースマッピングが発生した
- 最大実行時間を超えて Lambda 関数でタイムアウトエラーが発生する Lambda 関数
- Lambda は同時実行の制限を超えています
Lambda 関数エラーが発生した場合、関数は呼び出されません。また、関数はバッチのレコードを処理しません。エラーが発生すると、Lambda はプロセスが成功するか、バッチの有効期限が切れるまでレコードのバッチを再試行する可能性があります。Lambda 関数と Kinesis エラーの詳細については、「Amazon Kinesis で AWS Lambda を使用する」を参照してください。
解決策
Lambda 関数のトラブルシューティング
Lambda 関数が呼び出されない理由を特定するには、次の手順を実行します。
-
Lambda 関数の統計が Sum に設定されている Amazon CloudWatch のInvocationsメトリクスを確認します。呼び出し メトリクスは、Lambda 関数が呼び出されたかどうかを確認するのに役立ちます。
-
IteratorAge メトリックをチェックして、バッチの最後のレコードがどれくらい古いか、またはプロセスがいつ完了したかを確認します。Lambda コンシューマーが呼び出せなくなると、ストリームのイテレーターの経過時間が長くなります。
-
Lambda 関数の CloudWatch ログを確認します。ログにはそれらの名前に**.../aws/lambda/function_name** というフォーマットが使われています。関数エラーに対応するエントリを探します。たとえば、Lambda の AWS Identity and Access Management (IAM) ロールの権限が原因でエラーが発生した場合は、IAM ロールポリシーを変更します。
-
IAM ロールに CloudWatch にアクセスするための適切な権限があることを確認します。
{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "logs:CreateLogGroup", "logs:CreateLogStream", "logs:PutLogEvents" ], "Resource": "*" } ] }
-
(オプション) アクセス権限エラーが発生した場合は、Lambda 関数ポリシーを更新して Kinesis データストリームへのアクセス権を付与します。
{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "kinesis:DescribeStream", "kinesis:DescribeStreamSummary", "kinesis:GetRecords", "kinesis:GetShardIterator", "kinesis:ListShards", "kinesis:ListStreams", "kinesis:SubscribeToShard", "logs:CreateLogGroup", "logs:CreateLogStream", "logs:PutLogEvents" ], "Resource": "*" } ] }
**注:**AWSLambdaKinesisExecutionRole ポリシーには、これらの権限が含まれています。
その他のトラブルシューティング
その他のトラブルシューティングを実行するには、次のタスクを実行します。
Lambda 実行関数のタイムアウト
エラーが Lambda 実行関数のタイムアウトに関連している場合は、タイムアウト値を増やして処理を高速化します。
AWS KMS 暗号化データストリーム
AWS Key Management Service (AWS KMS) を使用して Kinesis データストリームを暗号化する場合、コンシューマーとプロデューサーには適切なアクセス権が必要です。Kinesis データストリームは、暗号化と復号化に使用される AWS KMS キーにアクセスできる必要があります。Kinesis データストリームからデータを正常に読み取るには、Lambda 関数の実行ロールに KMS キーへの読み取りアクセス権も必要です。
Lambda 関数の内部エラー
エラーの原因が Lambda 関数の内部エラーである場合は、ストリーム処理に問題があります。コントロールプレーン API スロットリングを回避するには、各ストリームを 4 ~ 5 個のイベントソースマッピングに制限します。これらの制限は、同じデータストリームでのイベントソースマッピングが多すぎるのを防ぐのに役立ちます。同じストリームで複数のイベントソースをマッピングすると、Kinesis と Amazon DynamoDB のコントロールプレーンの制限に違反する可能性があります。
接続タイムアウトエラー
接続タイムアウトエラーが発生した場合は、コード内で行われる API コールの前後にロギングステートメントを追加してください。次に、関数が失敗し始める正確なコード行を特定します。
シャードが遅い、または停止している
シャードが遅い、または停止しているシャードがある場合は、より小さいバッチサイズで再試行するようにイベントソースマッピングを設定します。再試行の回数を制限したり、古いレコードを破棄したりすることもできます。
「メモリ使用量」エラー
CloudWatch ログに「メモリ使用量」というエラーメッセージが表示される場合は、Lambda 関数のメモリを増やしてください。
最大タイムアウト超過
Lambda 関数の最大タイムアウトを超えた場合は、クライアントライブラリとクライアントタイムアウトを変更します。Lambda コンテナの残り時間に基づいてタイムアウトセッションを変更するには、context.GetRemainingTimeInMillis 関数を使用します。Context.getRemainingTimeInMillis 関数は、タイムアウトになるまでに Lambda コンテナに残っている時間を返します。
Lambda 関数コードエラー
Lambda 関数のコードからエラーを受け取った場合、Lambda 関数が同じレコードを試しても動かなくなる可能性があります。try-catch ブロックを使用して、失敗したデータをキャッチします。次に、Amazon Simple Queue Service (Amazon SQS) キューまたは Amazon Simple Notification Service (Amazon SNS) トピックを使用して記録します。また、処理ロジックを含む Lambda トリガーを Amazon SQS キューに追加して、失敗したリクエストを個別に再試行することもできます。
SQS DLQ
Amazon SQS デッドレターキュー (DLQ) を設定して Lambda 関数を手動で呼び出します。Lambda 関数を作成または更新するときに DeadletterConfig プロパティを設定します。DLQ の Target ARN として Amazon SQS キューまたは Amazon SNS トピックを指定できます。次に、Lambda はイベントオブジェクトを書き込み、標準の再試行ポリシーがすべて終了した後に Lambda 関数を指定のエンドポイントに呼び出します。
X-Ray 付き Lambda
Lambda と AWS X-Ray を組み合わせて使用すると、Lambda アプリケーションのパフォーマンスの問題を検出、分析、最適化できます。X-Ray は Lambda サービスからメタデータを収集し、Lambda アプリケーションのパフォーマンスに影響する問題を示すグラフを生成します。たとえば、実行に時間がかかる呼び出しがある場合は、AWS X-Ray を使用して問題を確認できます。
関連するコンテンツ
- 質問済み 1年前lg...
- 質問済み 18日前lg...
- 質問済み 1ヶ月前lg...
- 質問済み 1年前lg...
- AWS公式更新しました 6ヶ月前
- AWS公式更新しました 9ヶ月前