Realtime Compute for Apache Flink:チェックポイントおよびセーブポイントのタイムアウトの診断と防止

チェックポイントのフェーズ

Realtime Compute for Apache Flink は、ステート管理のために Chandy-Lamport アルゴリズムを採用しており、データ整合性および信頼性を確保します。すべてのチェックポイントおよびセーブポイントは、以下の 2 つのフェーズを経ます：

1. 同期フェーズ — システムは、オペレーター間でバリアが配置されるのを待機します。バリアは、オペレーター間で渡される特殊なタイプのデータレコードです。バリア配置に要する時間は、データレコードの到着遅延に比例します。

2. 非同期フェーズ — 各オペレーターは、そのローカルステートをリモートの永続ストレージシステムにアップロードします。アップロード時間は、ステートサイズに比例します。

ボトルネックフェーズの特定

バックプレッシャーを解消した後も、チェックポイントまたはセーブポイントが依然としてタイムアウトする場合は、以下のツールを使用して、ボトルネックが同期フェーズか非同期フェーズのどちらにあるかを特定します。

チェックポイント履歴 UI

O&M > デプロイメント に移動し、対象のデプロイメント名をクリックした後、ログ > チェックポイント > チェックポイント履歴 に進みます。このビューでは、デプロイメントレベル、オペレーターレベル、サブタスクレベルのメトリックを確認できます。

チェックポイントがタイムアウトしている、または進行中のオペレーターを特定し、以下のメトリックを確認します：

メトリック	説明
Sync Duration	同期フェーズに要した合計時間（オペレーターのステートスナップショット取得を含む）。
Alignment Duration	最初のチェックポイントバリアと最後のチェックポイントバリアの処理間の時間。値が高い場合、入力チャンネル間でのデータ分布が不均一である可能性があります。
Async Duration	リモートストレージへのステートアップロードに要した時間。
Checkpointed Data Size	チェックポイント実行時に書き込まれたステートデータの容量。

結果の解釈方法：

• Sync Duration または Alignment Duration が大きい場合 — ボトルネックは同期フェーズにあります。バリアがジョブグラフ内を遅く移動しており、これは残存するバックプレッシャーまたはチャンネルの偏りが原因である可能性があります。

• Async Duration または Checkpointed Data Size が大きい場合 — ボトルネックは非同期フェーズにあります。ステートが大きすぎて、タイムアウトウィンドウ内でアップロードできない状態です。

チェックポイントおよびセーブポイントのパフォーマンスチューニング

任意のチューニング手法を適用する前に、デプロイメントのランタイムパフォーマンスが期待通りであることを確認してください。ランタイムパフォーマンスが劣ると、チェックポイントの問題が悪化します。ランタイムパフォーマンスの最適化を完了した後、ボトルネックフェーズに応じて、以下の手法の 1 つ以上を適用します。

これらの手法は相互排他ではありません。両方のフェーズでボトルネックが発生している場合は、複数の手法を組み合わせて適用してください。

リファレンス

• 大規模ステートデプロイメントのパフォーマンスチューニング — 大規模なステートサイズが原因で発生する問題および全体的なチューニングワークフローについて説明します。

• SQL デプロイメントにおけるバックプレッシャー低減のためのステートサイズ制御 — Flink SQL オプティマイザーがステートフルオペレーターを選択する仕組み、および大規模データセットに対するステートフル計算のチューニング方法について説明します。

• DataStream API を使用したバックプレッシャー低減のためのステートサイズ制御 — DataStream API を用いた柔軟なステートサイズ管理について説明します。

• 起動およびスケーリング速度の向上 — チェックポイントまたはセーブポイントからデプロイメントを再起動する際、ステートデータはリモートストレージからダウンロードされ、ステートエンジンの復元に使用されます。このプロセスが効率ボトルネックとなることがあります。デプロイメントの起動およびスケーリング時のパフォーマンスボトルネックを特定・解消するためのガイダンスについては、本トピックをご参照ください。