Kinesis Data Streams トリガーが Lambda 関数を呼び出せないのはなぜですか?

簡単な説明

Lambda 関数のエラーは、多くの場合、以下が原因で発生します。

• Lambda 関数の実行ロールに十分なアクセス許可がないため。
• Kinesis データストリームへの受信データがないため。
• Kinesis データストリーム、Lambda 関数、または Lambda 実行ロールの再作成によって発生する非アクティブなイベントソースマッピング。
• Lambda 関数が実行上限を超え、Lambda 関数でタイムアウトエラーが発生したため。
• Lambda が同時実行数の制限を超えているため。Lambda の制限超過の詳細については、AWS Lambda の制限を参照してください。

Lambda 関数エラーがある場合、関数は呼び出されず、関数はバッチからのレコードを処理しません。Lambda は処理が成功するか、バッチの有効期限が切れるまで、エラーによりレコードのバッチ処理を再試行することがあります。Lambda 関数と Kinesis のエラーの詳細については、「AWS Lambda を Amazon Kinesis と使用する」を参照してください。

解決方法

Lambda 関数のトラブルシューティング

Lambda 関数が呼び出されない理由を特定するには、以下のステップを実行します。

1.    Lambda 関数の Sum として統計が設定された Amazon CloudWatch の Invocations メトリクスを確認します。Invocations メトリクスは、Lambda 関数が呼び出されたかどうかを確認するのに役立ちます。

2.    IteratorAge メトリクスを調べて、バッチの最後のレコードの経過日または処理が完了した日時を確認します。Lambda コンシューマーが呼び出せない場合、ストリームのイテレーターの期間が長くなります。

3.    Lambda 関数の CloudWatch Logs を確認します。ログは、.../aws/lambda/function_name 形式で名前が付けられています。関数エラーに対応するエントリを探します。例えば、Lambda の実行ロールのアクセス許可が原因でエラーが発生した場合は、AWS Identity and Access Management (IAM) ロールポリシーを変更します。

4.    IAM 実行ロールに CloudWatch にアクセスするための適切なアクセス許可があることを確認します。

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "logs:CreateLogGroup",
                "logs:CreateLogStream",
                "logs:PutLogEvents"
            ],
            "Resource": "*"
        }
    ]
}

5.    (オプション) アクセス許可エラーが発生した場合は、Lambda 関数ポリシーを更新して Kinesis Data Streams へのアクセスを許可します。

{
    "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 実行関数のタイムアウトに関連している場合は、より高速な処理に対応するようにタイムアウト値を増やします。
• Kinesis データストリームが AWS Key Management Service (AWS KMS) を使用して暗号化されている場合、コンシューマーとプロデューサーには適切なアクセス権限が必要です。Kinesis データストリームは、暗号化と復号化に使用される AWS KMS キーにアクセスできる必要があります。Kinesis データストリームからデータを正常に読み取るには、Lambda 関数の実行ロールに KMS キーへの読み取りアクセス権限も必要です。
• エラーが Lambda 関数の内部エラーによって発生する場合、このエラーはストリーム処理に問題があることを示しています。コントロールプレーン API スロットリングを回避するには、各ストリームのイベントソースマッピングを 4～5 個に制限します。
• エラーが Lambda 関数の内部エラーによって発生する場合、このエラーはストリーム処理に問題があることを示しています。各ストリームを 4～5 個のイベントソースマッピングに制限して、同じデータストリームを持つイベントソースマッピングが多すぎないようにします。同じストリームを持つイベントソースマッピングが複数あると、Kinesis および Amazon DynamoDB のコントロールプレーンの制限に違反する可能性があります。
• 接続タイムアウトエラーが発生する場合は、コード内で行われた API 呼び出しの前後にログ記録ステートメントを追加します。その後、関数が失敗し始めるコードの正確な行を特定できます。
• シャードが遅い、または停止している場合は、小さいバッチサイズで再試行するようにイベントソースマッピングを設定します。再試行回数を制限したり、古いレコードを破棄したりすることもできます。
• CloudWatch Logs に「memory used」というエラーメッセージが表示された場合は、Lambda 関数のメモリを増やします。
• Lambda 関数の最大タイムアウトを超えた場合は、クライアントライブラリとクライアントタイムアウトを変更します。Lambda コンテナの残りの時間に基づいてタイムアウトセッションを変更するには、context.GetRemainingTimeInMillis 関数を使用します。context.GetRemainingTimeInMillis 関数は、タイムアウトするまでの Lambda コンテナの残り時間を返します。
• Lambda 関数のコードからエラーを受け取った場合は、Lambda 関数が同じレコードを試行してスタックすることがあります。try-catch ブロックを使用して失敗したデータをキャッチし、Amazon SQS キューまたは Amazon SNS トピックを使用して記録します。また、処理ロジックを使用して Amazon SQS キューに Lambda トリガーを追加し、失敗したリクエストを個別に再試行することもできます。
• 手動で Lambda 関数を呼び出すように Amazon SQS デッドレターキュー (DLQ) をセットアップします。Lambda 関数を作成または更新するときに、DeadLetterConfig プロパティを設定します。DLQ の TargetArn として、Amazon Simple Queue Service (Amazon SQS) キューまたは Amazon Simple Notification Service (Amazon SNS) トピックを指定できます。次に、Lambda はイベントオブジェクトを書き込み、標準の再試行ポリシーが使い果たされた後、指定されたエンドポイントに Lambda 関数を呼び出します。
• AWS Lambda と AWS X-Ray を使用して 、Lambda アプリケーションのパフォーマンスの問題を検出、分析、最適化します。AWS X-Ray は Lambda サービスからメタデータを収集し、Lambda アプリケーションのパフォーマンスに影響を与える問題を示すグラフを生成します。例えば、呼び出しの実行に時間がかかる場合、AWS X-Ray を使用して問題を確認できます。

</ul

---