翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
# 際限のない状態の成長
アプリケーションが古い状態情報を適切に処理しないと、情報が継続的に蓄積され、アプリケーションのパフォーマンスや安定性の問題が発生します。このセクションでは、この状態の症状とトラブルシューティングの手順について説明します。
## 症状
この状態では、次の症状が発生する可能性があります。
+ `lastCheckpointDuration` 指標は徐々に増加しているか、急上昇しています。
+ `lastCheckpointSize` 指標は徐々に増加しているか、急上昇しています。
## 原因と解決策
次のような状況では、アプリケーションに状態データが蓄積される可能性があります。
+ アプリケーションが必要以上に長く状態データを保持している。
+ アプリケーションがウィンドウクエリを使用していて、時間が長すぎる。
+ ステートデータに TTL を設定していません。詳細については、「Apache Flink ドキュメント」の「[State Time-To-Live (TTL)](https://nightlies.apache.org/flink/flink-docs-release-1.18/docs/dev/datastream/fault-tolerance/state/#state-time-to-live-ttl)」を参照してください。
+ Apache Beam バージョン 2.25.0 以降に依存するアプリケーションを実行している。主要な実験と値 `use_deprecated_read` で「[BeamApplicationPropertiesを拡張](https://docs.aws.amazon.com/managed-flink/latest/java/examples-beam.html#examples-beam-configure)」することにより、新バージョンの読み取り変換を拒否することができます。詳細については、[Apache Beam Documentation](https://beam.apache.org/blog/beam-2.25.0/#highlights) を参照してください。
アプリケーションがステートサイズの拡大に直面することがありますが、これは長期的には持続不可能です（結局、Flink アプリケーションは無期限に実行されます）。場合によっては、アプリケーションがデータをそのままの状態で保存していて、古い情報を適切にエージングアウトしていないことが原因であることもあります。しかし、Flink が提供できることに対して、単に理不尽な期待が寄せられることもあります。アプリケーションでは、数日から数週間に及ぶ長い時間枠にわたってアグリゲーションを使用することがあります。インクリメンタルな集計が可能な「[AggregateFunctions](https://nightlies.apache.org/flink/flink-docs-stable/docs/dev/datastream/operators/windows/#aggregatefunction)」を使用しない限り、Flink はウィンドウ全体のイベントをそのままの状態に保つ必要があります。
さらに、プロセス関数を使用してカスタムオペレータを実装する場合、アプリケーションはビジネスロジックで不要になったデータを状態から削除する必要があります。その場合は、「[ステートの有効期間](https://nightlies.apache.org/flink/flink-docs-stable/docs/dev/datastream/fault-tolerance/state/#state-time-to-live-ttl)」を利用して、処理時間に基づいてデータを自動的にエージングアウトできます。Apache Flink のマネージドサービスはインクリメンタルチェックポイントを使用しているため、ステート ttl は 「[RocksDB コンパクション](https://github.com/facebook/rocksdb/wiki/Compaction)」に基づいています。ステートサイズ (チェックポイントサイズで示される) が実際に減少するのを確認できるのは、コンパクション操作が行われた後だけです。特に 200 MB 未満のチェックポイントサイズでは、ステートの有効期限が切れることによってチェックポイントのサイズが減少することはほとんどありません。ただし、セーブポイントは古いデータを含まない状態のクリーンコピーに基づいているため、Apache Flink 用 Managed Serviceでスナップショットをトリガーして、古い状態を強制的に削除できます。
デバッグ目的では、チェックポイントのサイズが実際に減少または安定することをより迅速に検証する (そして ROCKSBS でのコンパクションの影響を避ける) ために、インクリメンタルチェックポイントを無効にするのが理にかなっています。ただし、これにはサービスチームへのチケットが必要です。