Amazon Kinesis Data Analytics アプリケーションが再起動するのはなぜですか?

最終更新日: 2022 年 3 月 2 日

タスクが失敗すると、Apache Flink アプリケーションは失敗したタスクと影響を受ける他のタスクを再起動し、ジョブを通常の状態にします。

この状態を生じさせるいくつかの原因と、それぞれのトラブルシューティングの手順を次に示します。

• NullPointer Exception や DataCast タイプなどのコードエラーは、タスクマネージャーで生成され、ジョブマネージャーにバブルアップされます。その後、アプリケーションは最新のチェックポイントから再起動されます。アプリケーションで未処理の例外を理由とするアプリケーションの再起動を検出するには、downtime などの Amazon CloudWatch メトリクスを確認します。このメトリクスは、再起動期間中はゼロ以外の値を表示します。この状態の原因を特定するには、アプリケーションログに対してクエリを実行して、アプリケーションの状態の [RUNNING] から [FAILED] への変更がないかを確認します。詳細については、「Analyze errors: Application task-related failures」(エラーの分析: アプリケーションタスク関連のエラー) を参照してください。
• メモリ不足の例外が発生すると、タスクマネージャーは正常なハートビート信号をジョブマネージャーに送信できず、アプリケーションが再起動します。この場合、アプリケーションログに TimeoutException、FlinkException、RemoteTransportException などのエラーが表示されることがあります。CPU またはメモリリソースの負荷が原因となってアプリケーションが過負荷になっていないか確認します。
  
  • CloudWatch メトリクスの fullRestarts と downtimeの値がゼロではないことを確認してください。
  • cpuUtilization と heapMemoryUtilization のメトリクスに異常なスパイクがないか確認します。
  • アプリケーションコードに未処理の例外がないか確認します。
  • チェックポイントとセーブポイントの障害をチェックします。CloudWatch メトリクスの numOFFailedCheckpoints、lastCheckpointSize、および lastCheckpointDuration をモニタリングして、スパイクや安定的な増加がないかを確認します。
    この問題を解決するには、以下の操作をお試しください。
  • アプリケーションのデバッグログを有効にすると、アプリケーションリソースの消費量が多くなる可能性があります。問題を調査する場合にのみデバッグログを一時的に有効にすることで、ログ記録の量を減らすことができます。
  • Apache Flink ダッシュボードで TaskManager スレッドダンプを分析します。例えば、CPU 負荷の高いプロセスをスレッドダンプから特定できます。
  • スタックトレースを数回サンプリングして作成された Flame グラフを確認します。Flame グラフを使用すると、アプリケーションの全体的なヘルスを視覚化し、CPU リソースを最も多く消費しているメソッドを特定し、特定のメソッドの実行につながったスタックに対する一連の呼び出しを特定できます。off-CPU Flame グラフを使用して、ブロックされた呼び出しをチェックします。

• アプリケーションによるソースまたはシンクのプロビジョニングが不十分である場合、Kinesis Data Streams などのストリーミングサービスの読み書き時にアプリケーションでスロットリングエラーが発生することがあります。この状態は、最終的にアプリケーションのクラッシュにつながる可能性があります。WriteProvisionedThroughputExceeded や ReadProvisionedThroughputExceeded などの CloudWatch メトリクスを使用して、ソースとシンクのスループットをチェックします。シャードの数を増やして、データ量に合わせてデータストリームをスケールアップすることを検討してください。
• FlinkKinesisProducer は Kinesis Producer Library (KPL) を使用して、Flink ストリームから Kinesis Data Stream にデータを格納します。タイムアウトなどのエラーは KPL で障害を引き起こし、最終的に Flink アプリケーションの再起動につながる可能性があります。このような場合、バッファリング時間が長くなり、再試行回数が増えることがあります。レコードの有効期限が切れないように、RecordMaxBufferedTime、RecordTtl、および RequestTimeout といった KPL の設定を調整できます。また、ErrorsByCode、RetriesPerRecord、UserRecordsPending などの重要な KPL メトリクスをモニタリングします。アプリケーションが再起動中であることをこれらのメトリクスが示唆している場合は、CloudWatch Logs Insights のフィルターを使用して、再起動を生じさせたエラーの正確な原因を把握します。
• すべてのエラーがアプリケーションの即時の再起動につながるわけではないことに注意してください。例えば、アプリケーションコードにエラーがあると、DAG ワークフローエラーが発生することがあります。この場合、アプリケーションの有向非巡回グラフ (DAG) は作成されません。アプリケーションはシャットダウンし、即時に再起動するわけではありません。また、「access denied」(アクセスが拒否されました) というエラーが発生しても、即時にアプリケーションが再起動するわけではありません。

それでも問題が解決しない場合は、AWS Support に問い合わせて、次の情報を提供してください。

• アプリケーション ARN
• アプリケーションのソースとシンクに関する情報
• アプリケーションの CloudWatch ログ
• 発行時刻 (UTC)
• Flink ダッシュボードからの関連するスレッドダンプ