Amazon Managed Service for Apache Flink アプリケーションが再起動する理由を知りたいです。

解決策

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

この問題のいくつかの原因および、トラブルシューティング手順を次に示します。

コードエラー

NullPointerException や DataCast タイプなどのコードエラーは、タスクマネージャーで生成され、最終的にジョブマネージャーで発生します。その後、アプリケーションは最新のチェックポイントから再起動されます。アプリケーション内の未処理の例外によるアプリケーションの再起動を検出するには、ダウンタイムなどの Amazon CloudWatch メトリクスを確認します。このメトリクスは、再起動期間中はゼロ以外の値を表示します。原因を特定するには、アプリケーションログで、アプリケーションのステータスが RUNNING から FAILED に変化しているかどうかを調べます。詳細については、「エラーの分析: アプリケーションタスク関連の障害」を参照してください。

メモリ不足例外

メモリ不足の例外が発生すると、タスクマネージャーは正常なハートビートシグナルをジョブマネージャーに送信できず、アプリケーションが再起動します。この場合、アプリケーションログに TimeoutException、FlinkException、RemoteTransportException などのエラーが発生することがあります。

CPU またはメモリリソースの負荷が原因でアプリケーションが過負荷になっていないか確認します。

• CloudWatch の fullRestarts および downtime メトリクスの値がゼロでないことを確認します。
• cpuUtilization および heapMemoryUtilization メトリクスを確認して、異常なスパイクがないかどうかを確認します。
• アプリケーションコードに未処理の例外がないか確認します。
• チェックポイントとセーブポイントの障害を確認します。CloudWatch メトリクス numOFFailedCheckpoints、lastCheckpointSize、lastCheckpointDuration を監視し、急増や継続的な増加がないかを確認します。

急増と継続的な増加を解決するには、次のタスクを実行します。

• アプリケーションのデバッグログを有効にした場合、アプリケーションのリソース使用率が高くなる可能性があります。ログの量を減らすには、問題を調査するときのみデバッグログを一時的に有効にします。
• Apache Flink ダッシュボードで TaskManager スレッドダンプを分析します。たとえば、スレッドダンプから CPU を大量に消費するプロセスを特定できます。
• 作成されたフレームグラフを確認するには、スタックトレースを数回サンプリングします。ブロックされたコールを確認するには、オフ CPU フレームグラフを使用します。フレームグラフの詳細については、Apache Flink のウェブサイトで「フレームグラフ」を参照してください。

スロットリングエラー

アプリケーションでソースまたはシンクのプロビジョニングが不足している場合、アプリケーションが Kinesis Data Streams などのストリーミングサービスに読み書きするときに、スロットリングエラーが発生する可能性があります。この問題により、アプリケーションがクラッシュする可能性があります。ソースとシンクのスループットを確認するには、WriteProvisionedThroughputExceeded や ReadProvisionedThroughputExceeded などの CloudWatch メトリクスを使用します。データ量に対応するには、シャードの数を増やし、データストリームをスケールアップします。

タイムアウトエラー

FlinkKinesisProducer は、Kinesis Producer Library (KPL) を使用して Flink ストリームのデータを Kinesis データストリームに入れます。タイムアウトエラーにより KPL に障害が発生し、Flink アプリケーションが再起動する可能性があります。この場合、バッファ時間と再試行回数が増加する可能性があります。KPL の RecordMaxBufferedTime、RecordTtl、RequestTimeout 設定を変更すると、レコードの期限切れを防止できます。詳細については、GitHub のウェブサイトで default_config.properties を参照してください。ErrorsByCode、RetriesPerRecord、UserRecordsPending などの重要な KPL メトリクスも監視します。これらのメトリクスがアプリケーションが再起動したことを示した場合、CloudWatch Logs Insights のフィルターを使用して、アプリケーションが再起動した原因となった障害を把握します。

すべてのエラーがアプリケーションの即時再起動の要因ではないことに注意してください。たとえば、アプリケーションコードにエラーがあると、有向非巡回グラフ (DAG) ワークフローエラーが発生する可能性があります。この場合、アプリケーションの DAG は作成されません。アプリケーションはシャットダウンし、すぐには再起動しません。アクセス拒否エラーが発生した場合も、アプリケーションはすぐには再起動しません。

それでも問題が解決しない場合は、AWS サポートに連絡し、次の情報を提供してください。

• アプリケーション ARN
• アプリケーションのソースとシンクに関する情報
• アプリケーションの CloudWatch Logs
• 問題の発生時間 (UTC)
• Apache Flink ダッシュボードからの関連するスレッドダンプ

関連情報

アプリケーションが再起動します