ステート管理は、Apache Flink のパフォーマンス、安定性、およびリソース使用率に影響を与える複雑かつ重要な問題です。このトピックでは、ステート管理の原則と戦略について説明します。また、Realtime Compute for Apache Flink の機能を使用して、大規模ステートデプロイのパフォーマンスと安定性を最適化する方法についても説明します。
ステートとは
Apache Flink は、データストリームのリアルタイム処理と分析のためのオープンソースフレームワークです。 Apache Flink の中核となる概念はステートであり、これは複数のイベントにわたって維持される情報を指します。コンピューターのメモリの役割と同様に、ステートを使用すると、オペレーターは無限ストリームを処理するときに履歴データを追跡できます。ステートは、キーと値のペア、またはリスト、配列、カスタムオブジェクトなどのより複雑なデータ型として保存できます。ステートデータへのアクセスと更新は、複雑なストリーム処理に不可欠です。
ステート管理は、Realtime Compute for Apache Flink の開発コンソールの重要な機能です。この機能により、システムはデプロイのチェックポイントを自動的に管理し、デプロイの可用性に影響を与えることなく、必要なストレージスペースを最小限に抑えることができます。また、この機能を使用すると、セーブポイントを効率的に管理し、デプロイ間で共有できます。これは、大規模ステートデプロイの A/B テストとアクティブ/スタンバイフェイルオーバーにとって非常に実用的な価値があります。
大規模なステートサイズによって発生する問題
大規模ステートデプロイの維持は困難です。ステートサイズが時間の経過とともに増加するにつれて、複数のパフォーマンスの問題が発生します。
バックプレッシャーとパフォーマンスの低下
バックプレッシャーは、I/O オーバーヘッドが特定のレベルに達したときに発生します。これにより、処理レイテンシが増加し、1 秒あたりのトランザクション数 (TPS) で測定されるスループットが低下します。
低いリソース使用率
ほとんどの場合、ステートフルオペレーターには大量のアイドル CPU リソースがあります。ステートサイズが大きいほど、リソースの無駄が大きくなります。
チェックポイントとセーブポイントのタイムアウト
ステートサイズが大きい場合、チェックポイントとセーブポイントはタイムアウトする可能性が高くなります。これにより、デプロイの再起動後にデータを再開するために必要な時間と、エンドツーエンドの Exactly-Once 処理のレイテンシが増加します。
起動とスケーリングの遅延
デプロイを開始またはスケーリングすると、各オペレーターはデプロイ全体のステートデータに基づいてローカルデータを回復する必要があります。このプロセスの消費時間は、ステートサイズに比例します。これにより、大規模ステートデプロイのサービス中断時間が長くなります。
大規模ステートデプロイのチューニングのワークフロー
前述の問題を防ぐために、次の手順を実行して、大規模ステートデプロイのステート管理を最適化します。
潜在的なボトルネックの特定
診断ツールを使用して、デプロイの現在の稼働状況を把握し、パフォーマンスのボトルネックが不適切なステート管理によって引き起こされているかどうかを判断します。診断ツールの使用方法については、デプロイのパフォーマンスの監視をご参照ください。
最新のエンジンバージョンの使用
Realtime Compute for Apache Flink は、Ververica Runtime (VVR) エンジンのステートモジュールを継続的に最適化しています。ほとんどの場合、最新のエンジンバージョンが最適なパフォーマンスを提供します。 VVR は、Apache Flink と完全に互換性のあるエンタープライズクラスのエンジンです。 VVR には GeminiStateBackend も搭載されており、ステートアクセス、チェックポイント、およびステートリカバリが大幅に容易になります。 GeminiStateBackend は、最適なパフォーマンスを確保するためにパラメーター構成を自動的に調整するため、手動構成は不要です。他の最適化を行う前に、最新の VVR バージョンを使用していることを確認してください。詳細については、GeminiStateBackend、GeminiStateBackend の構成、およびデプロイのエンジンバージョンのアップグレードをご参照ください。
問題ごとに異なるチューニング戦略を適用する
実行時のパフォーマンス低下 (バックプレッシャー)
この問題に対処するには、次の手順を実行します。SQL クエリを最適化し、Time-To-Live (TTL) を調整してステートデータを削減し、メモリ割り当てと並列度設定を調整してディスク上の I/O 操作を削減します。詳細については、SQL デプロイでのバックプレッシャーを軽減するためのステートサイズの制御とDatastream API を使用したバックプレッシャーを軽減するためのステートサイズの制御をご参照ください。
チェックポイントまたはセーブポイントのタイムアウト
この問題に対処するには、次の手順を実行します。実行時のパフォーマンスを最適化してバックプレッシャーを軽減し、同期フェーズのパフォーマンスを最適化し、並列度を調整して各サブタスクのステートサイズを削減し、ネイティブ形式のセーブポイントを使用して効率を向上させることを検討します。詳細については、チェックポイントとセーブポイントのタイムアウトの診断と防止をご参照ください。
起動とスケーリングの遅延
ローカルディスク容量が十分な場合は、ローカルリカバリ機能を有効にできます。また、GeminiStateBackend の遅延読み込みと遅延プルーニング機能を使用して、デプロイを迅速に開始およびスケーリングすることもできます。詳細については、起動とスケーリングの速度の向上をご参照ください。