州の無限の成長

アプリケーションが古い状態情報を適切に処理しないと、情報が継続的に蓄積され、アプリケーションのパフォーマンスや安定性の問題が発生します。このセクションでは、この状態の症状とトラブルシューティングの手順について説明します。

症状

この状態では、次の症状が発生する可能性があります。

• lastCheckpointDuration 指標は徐々に増加しているか、急上昇しています。

• lastCheckpointSize 指標は徐々に増加しているか、急上昇しています。

原因と解決策

次のような状況では、アプリケーションに状態データが蓄積される可能性があります。

• アプリケーションが必要以上に長く状態データを保持している。

• アプリケーションがウィンドウクエリを使用していて、時間が長すぎる。

• ステートデータに TTL を設定していません。詳細については、Apache Flink ドキュメントの「ステート存続可能時間 (TTL)」を参照してください。

• Apache Beam バージョン 2.25.0 以降に依存するアプリケーションを実行している。主要な実験と価値を拡張することで、 BeamApplicationProperties新しいバージョンの読み取りトランスフォームをオプトアウトできます。use_deprecated_read詳細については、Apache Beam Documentation を参照してください。

アプリケーションがステートサイズの拡大に直面することがありますが、これは長期的には持続不可能です（結局、Flink アプリケーションは無期限に実行されます）。場合によっては、アプリケーションがデータをそのままの状態で保存していて、古い情報を適切にエージングアウトしていないことが原因であることもあります。しかし、Flink が提供できることに対して、単に理不尽な期待が寄せられることもあります。アプリケーションでは、数日から数週間に及ぶ長い時間枠にわたってアグリゲーションを使用することがあります。インクリメンタル・アグリゲーションが可能な場合を除き、Flink AggregateFunctionsはウィンドウ全体のイベントをそのままの状態に保つ必要があります。

さらに、プロセス関数を使用してカスタムオペレータを実装する場合、アプリケーションはビジネスロジックで不要になったデータを状態から削除する必要があります。その場合、state を使うと、 time-to-live処理時間に基づいてデータを自動的にエージングアウトさせることができます。Apache Flink のマネージドサービスはインクリメンタルチェックポイントを使用しているため、ステート ttl は 「RocksDB コンパクション」に基づいています。ステートサイズ (チェックポイントサイズで示される) が実際に減少するのを確認できるのは、コンパクション操作が行われた後だけです。特に 200 MB 未満のチェックポイントサイズでは、ステートの有効期限が切れることによってチェックポイントのサイズが減少することはほとんどありません。ただし、セーブポイントは古いデータを含まない状態のクリーンコピーに基づいているため、Apache Flink 用 Managed Serviceでスナップショットをトリガーして、古い状態を強制的に削除できます。

デバッグ目的では、チェックポイントのサイズが実際に減少または安定することをより迅速に検証する (そして ROCKSBS でのコンパクションの影響を避ける) ために、インクリメンタルチェックポイントを無効にするのが理にかなっています。ただし、これにはサービスチームへのチケットが必要です。