ログベースの一般的な増分チェックポイント

要約: この記事は、Alibaba の開発エンジニアであり、Apache Flink コントリビューターである Yu Hangxiang の、Flink Forward Asia 2022 のコアテクノロジーセッションでの共有をもとに編集されたものです。この記事の内容は主に次の 4 つの部分に分かれています。

チェックポイントパフォーマンス最適化ロード
変更ログのメカニズム分析
変更ログのパフォーマンステスト
概要と計画

1.チェックポイント性能最適化ロード

1.1 チェックポイントの概要

ご存知のとおり、Flink はステートフルな分散コンピューティングエンジンです。Flink ではステートは非常に重要な概念です。Flink では、ステートとチェックポイントメカニズムは切り離せません。したがって、チェックポイントに関する Flink の最適化プロセスについて説明する前に、チェックポイントがなぜそれほど重要なのかを見てみましょう。チェックポイントは具体的に何をするのですか?

チェックポイントの概念はなじみのないものではなく、さまざまなシステムに登場しています。その主な目的は、障害を許容し、障害後もアプリケーションが正常に実行できることを保証することです。長期にわたるアプリケーションシステムでは障害は避けられず、ストリームコンピューティングシステムではデータ処理の遅延が非常に重要な指標となります。障害発生後にアプリケーションをいかに早く復旧させ、最新のデータに追いつくかは、ストリームコンピューティングシステムが注力すべき問題です。キャパシティメカニズムに基づく障害回復と比較して、チェックポイントメカニズムは軽量で使いやすくなります。

さらに、多くの企業は、障害回復後のデータの一貫性に対してより高い要件を提示しています。Flink のチェックポイントメカニズムは、1 回限りのセマンティクスをサポートしており、Source が再生をサポートし、Sink がトランザクションをサポートすると、エンドツーエンドの 1 回限りのセマンティクスを実現できます。チェックポイントとリカバリのパフォーマンスがある程度最適化されると、アプリケーションは実際に障害がないかのように長時間実行できるようになります。

Flink はチェックポイントメカニズムに基づいてどのようにそれを行うのでしょうか?

ジョブの実行中、Flink のステートフルオペレーターは状態を通じて複数のイベント間の情報を記録し、Flink は定期的にチェックポイントを実行してこれらの状態を保持し、グローバルに整合性のあるスナップショットをリモートストレージにアップロードします。 Flink は永続状態データをローカルにダウンロードし、ローカル状態データ構造を再構築します。ソースが再生をサポートしている場合、パイプライン全体が最後に記録された位置から再生され、ジョブは正常に実行を開始します。

これら 2 つのパートでの説明に基づいて、Checkpoint は軽量と高速フェイルオーバーという 2 つの重要な目標を中心に設計する必要があることがわかります。

1.2 軽量かつ高速なチェックポイント

上記 2 つの設計目標に基づいて、Flink は Checkpoint で多くの最適化を行っており、Checkpoint メトリクスを組み合わせてこれらの最適化の効果を確認できます。

バージョン 0.9 では、Flink は軽量の非同期スナップショットアルゴリズムを導入しました。このアルゴリズムには 2 つの核心点があります。

1 つはジョブの粒度で、バリアはグラフ内の特別なレコードとして渡され、オペレーターがバリアを受け取ったときにチェックポイントが実行されます。
次に、オペレーターの粒度に応じて、チェックポイントの実行ステップが同期フェーズと非同期フェーズに分割され、ファイルのアップロードなどのより重い操作は非同期フェーズに配置されます。

メトリクスでは、チェックポイントのエンドツーエンドの時間消費が複数の期間に分割されていることがわかります。チェックポイントのパフォーマンスの問題が発生した場合、最初に確認するのは、同期フェーズの時間消費と同期フェーズの時間消費です。非同期フェーズ。その後登場したさまざまなテクノロジーは、主にこの 2 つの段階の最適化を目的としています。

バージョン 1.0 では、Flink は RocksDB StateBackend をサポートしており、これにより大規模な状態のジョブがより安定しますが、大規模な状態のチェックポイントがボトルネックになっています。状態が増加するにつれて、完全なチェックポイントのデータサイズがわかります。つまり、完全なチェックポイントのデータ量が大幅に増加し、チェックポイントの非同期部分の時間の大幅な増加につながります。

したがって、バージョン 1.3 では、Flink は RockDB ベースの増分チェックポイントをサポートします。このメカニズムでは、State Backend は非同期フェーズで増分ファイルをアップロードするだけで済みます。これにより、Checkpoint によって非同期フェーズでアップロードされるファイルの量が大幅に削減され、Checkpoint の非同期時間の消費が短縮されます。

通常、メトリクスで非同期フェーズに時間がかかりすぎ、フルチェックポイントデータサイズが大きい場合は、まずこの構成を有効にすることを検討します。有効にすると、チェックポイントされたデータサイズを通じて増分部分のサイズを確認できます。

では、同期フェーズにかかる時間をさらに短縮することはできるのでしょうか?

実際の運用では、先ほどのアルゴリズムでは、通常、同期フェーズで時間がかかる部分はアライメント期間、つまりアライメント時間です。たとえば、ジョブの途中のオペレータは複数の上流オペレータから入力を受け取る可能性がありますが、前述のアルゴリズムでは、Exactly-once セマンティクスを保証するために、オペレータがオペレータによるリンクの処理が遅すぎるため、チェックポイント全体を完了できない可能性があります。このとき、アライメント時間は長くなります。したがって、1.11 では、Flink は Unaligned Checkpoint をサポートし、1.13 では、この関数は Production Ready 状態になりました。

この機能を有効にすると、単一のバリアが特定のオペレーターに到達すると、それを出力バッファーの最後に直接渡すことができ、同時にステートバックエンド層のチェックポイントを直接トリガーし、その前に入力バッファーを受け入れることができます。最後のバリアとリモートに保存された出力バッファ内のインフレートデータ。復元時には、この部分のデータも追加で復元され、入力バッファー内のデータがオペレーターに再生されます。この方法は、同期調整時間を短縮するだけでなく、1 回限りのセマンティック保証も提供します。

この時点で、Flink UI で Unaligned Checkpoint が true に設定されており、保持されるインフライトデータが大幅に増加していることがわかります。

ただし、Unaligned Checkpoint を開くと、追加のインフライトデータを保存する必要があるため、スペースが拡大するという問題が発生します。スペースのこの部分のオーバーヘッドを削減する方法はありますか? 同時に、チェックポイントメトリクスには、開始遅延という別のインジケーターがあります。この指標は、バリアの作成からオペレーターの到着までの時間です。ジョブ全体のバリアの流れをさらに加速して、バリアが特定のオペレーターに早く到達して、チェックポイントをより早くトリガーできるようにする方法はありますか? ?

この問題を解決するために、1.14 でバッファデブローティングメカニズムが導入されました。この機能は、ネットワークトラフィックの状況を検出してネットワークバッファのサイズを動的に調整できるため、Aligned Checkpoint のトリガーが高速化され、Unaligned Checkpoint の余分なスペースのオーバーヘッドが削減されます。

上記のテクノロジーにより、チェックポイントの同期時間消費と非同期時間消費を最適化でき、Unaligned Checkpoint とバッファデブローティングメカニズムを組み合わせることで、比較的少ないコストで同期フェーズの時間消費を大幅に削減できます。

それでは、非同期フェーズの時間消費にはさらに改善の余地があるのでしょうか? 1.15 では、共通の増分チェックポイントである Changelog StateBackend が導入され、この機能は 1.16 で Production Ready 状態に達し、この共有の主役となります。

2. 変更ログのメカニズム分析

2.1 RocksDB の増分チェックポイントメカニズム

まず、先ほど述べたように、RocksDB に基づく増分チェックポイントメカニズムは、非同期フェーズでアップロードされるファイルの量を削減できますが、チェックポイントプロセスの速度と安定性を根本的に保証することはできません。なぜ？

まずはその仕組みをおさらいしてみましょう。書き込みプロセスでは、レコードはまず RocksDB メモリデータ構造、つまり MemTable に書き込まれます。その後、MemTable がいっぱいになると ImmuTable MemTable になります。しきい値に達すると、ImmuTable MemTable がディスクにフラッシュされて SST ファイルが形成されます。

このプロセスは SST 圧縮をトリガーする可能性があり、レベルコンパクションメカニズムの下では、マルチレイヤーのカスケード圧縮をトリガーして、さらに多数の新しいファイルを生成する可能性があります。図に示すように、黄色でマークされた新しいファイルと古いファイルが全量の SST を形成します。

Checkpoint の同期プロセスでは、先ほどのプロセスと同様に、MemTable の Flush が最初に強制的にトリガーされ、SST の Compaction がトリガーされる可能性があります。その後、ローカルのチェックポイントが実行されます。これは実際にはハードリンクプロセスであり、比較的軽量です。Checkpoint の非同期プロセスでは、ファイルの増分部分がリモートストレージにアップロードされ、一部のメタ情報が書き込まれます。

このプロセスの問題点:

まず第一に、Flush はマルチレベルのレベル圧縮をトリガーし、さらに多数のファイルが再アップロードされる原因となる可能性があります。

次に、データ量がしきい値に達したときだけでなく、チェックポイントの同期フェーズでも MemTable を強制的にフラッシュします。大規模なジョブでは、複数のタスクが圧縮とファイルのアップロードを同時にトリガーするため、リソースとチェックポイントの時間の消費がチェックポイントサイクルとともに変動します。

最後に、チェックポイントのエンドツーエンドの消費時間は、最長のリンクによって異なります。大規模なジョブの場合、タスクの非同期時間が長いため、各チェックポイントに時間がかかる可能性があり、最終的にチェックポイントが長く不安定になります。

したがって、私たちは Changelog メカニズムを導入しました。その目的は、安定した高速なチェックポイントをさらに提供することです。

まず、圧縮によって RocksDB にアップロードされるファイルの量が不安定になるため、チェックポイントの時間が急激に増加する原因になりますが、Changelog を有効にすると、チェックポイントの時間が急激に増加する状況を大幅に軽減できます。同時に、実稼働環境では、CPU とネットワーク帯域幅が Checkpoint によって定期的に変動することが時々わかります。これは通常、チェックポイントが複数のタスクの圧縮をトリガーし、同時に多数のファイルを再アップロードする必要があり、ジョブ自体の安定性や他のジョブの安定性にさえ影響を与える可能性があるためです。変更ログを使用すると、この状況を改善できます。

次に、Changelog は比較的固定された増分をアップロードすることで、非同期部分の時間のかかる部分を大幅に削減し、状態量が多い場合でもチェックポイントを 2 秒/1 秒未満のレベルで完了できるようにします。

チェックポイントが高速化するとどのようなメリットがあるのでしょうか?

1 つはエンドツーエンドの遅延が小さいことです。トランザクションシンクの送信はチェックポイントの完了に依存し、チェックポイントが速く完了するほど、シンクのデータはより新しくなります。もう 1 つは、データの回復が少ないことです。フェイルオーバーの場合、最新のチェックポイントが回復され、そのポイント以降のデータが回復されることがわかっています。チェックポイントが高速になると、データの回復が少なくなります。

もちろん、Changelog はスペースのオーバーヘッドや回復に時間がかかるオーバーヘッドなどの追加のオーバーヘッドをもたらしますが、全体的にこれらのオーバーヘッドは制御可能であり、それがもたらす利点と比較すると、オーバーヘッドは比較的小さいため、後で実験に合格します。さらに説明します。

Changelog はどのようにしてこれらの改善を達成したのでしょうか?

実際、Changelog メカニズムは DB の Checkpoint + WAL メカニズムに非常に似ているため、Changelog メカニズムを紹介する前に、DB の同様のメカニズムを見てみましょう。

障害から迅速に復旧するために、通常、DB では WAL 機能が有効になっています。この機能を有効にしてDBにデータを書き込むと、レコードが操作ログの形でディスクのWAL構造に書き込まれ、その後メモリのデータ構造が更新され、メモリとディスクが更新されます。同時に同期されます。WAL はシーケンシャルに書き込まれるため、このプロセスは非常に高速です。チェックポイントがトリガーされると、DB はローカルで完全なスナップショットを取得し、完了後に履歴の WAL 切り捨てを削除します。障害から回復する場合、まず DB がチェックポイントから再構築され、WAL が DB に再生されることで、障害前の状態に復元されます。

なぜこれら 2 つのメカニズムが必要なのでしょうか? まず、WAL と比較すると、チェックポイント操作が比較的重いため、頻繁かつきめ細かいスナップショットを実現できませんが、順次書き込まれる WAL は実現できます。第 2 に、WAL には大きなスペース拡大の問題があり、リカバリ中に追加の再生オーバーヘッドが必要になるため、定期的なチェックポイントによってこの部分のオーバーヘッドを削減できます。

2.2 変更ログ増分チェックポイントの用語

DB のメカニズムに基づいて、Changelog のいくつかの概念を拡張できます。状態テーブルは、RocksDB などのオペレーターのローカル状態データの読み取り/書き込み構造であり、上図の左側の DB データ構造に似ています。

状態変更ログは、追加専用ログの形式で保存される状態レコードです。DSTL は変更ログ部分のストレージコンポーネントであり、これら 2 つの部分は左の図の WAL 構造に似ています。マテリアライゼーションは状態テーブルの永続化プロセスであり、定期的にトリガーされ、上図の左側のチェックポイントのプロセスと同様に、成功後に変更ログを通過します。

したがって、簡単に言うと、Changelog は追加の DSTL を通じて増分を継続的にアップロードし、マテリアライゼーションを使用して状態テーブルの完全なスナップショットを定期的に更新するプロセスを完了します。

2.3 変更ログ増分チェックポイントのコアメカニズム

その中心的な仕組みのいくつかを詳しく見てみましょう。まず、ジョブの粒度に関しては、以前と同様に、エンドツーエンドのプロセス全体が Flink Checkpoint のメカニズムの下で完了します。演算子の粒度で、3 つのリンクを通じてプロセス全体を確認することもできます。

読み取り/書き込みリンクでは、新しく書き込まれたレコードは状態変更ログの形式で DSTL と状態テーブルに書き込まれ、読み取り時にのみ状態テーブルから読み取られます。
チェックポイントリンクには、次の 4 つの主要な部分があります。

1 つは、ジョブの実行中、変更ログ部分が DSTL によってリモートストレージに定期的かつ継続的にアップロードされることです。
次に、Flink Checkpoint がトリガーされると、Changelog 部分が直接アップロードされます。
3 つ目は、マテリアライゼーションが定期的にトリガーされると同時に、完了後に履歴変更ログが切り捨てられることです。
第四に、JM は上記 3 つのプロセスに基づいて、取得したマテリアライゼーション部分と変更ログ部分から構成されるハンドルをメタ情報に保存します。

リカバリリンクでは、まず状態テーブルが復元されます。これには、リモートエンドからのファイルのダウンロードと状態テーブルの再構築が含まれます。次に、リモートエンドから変更ログ部分をダウンロードして再生します。

この仕組みにより、チェックポイントの処理が非常にスムーズになります。各タスクは定期的にマテリアライゼーションをトリガーして全量のデータを保持し、ジョブが実行されて Flink チェックポイントがトリガーされると、比較的小さな増分データがアップロードされます。

このメカニズムでは、各タスクの具体化プロセスは比較的独立しており、チェックポイントによってアップロードされるデータの量には影響しません。したがって、状態テーブルの特定のメカニズムは増分チェックポイントプロセスから切り離され、チェックポイントプロセスは非常に安定し、速い、速い。

また、リカバリ中に、各タスクは最新のマテリアライゼーションに基づいて状態テーブルを構築し、マテリアライゼーションとその最新のチェックポイントの間の変更ログ履歴を再生します。

Checkpoint が高速かつ安定するにつれて、Changelog にはいくつかのオーバーヘッドが発生します。主に次の 3 つの側面に分けられます。

1 つは追加のストレージ領域のオーバーヘッドです。Changelog 部分は操作ログの形式で記述されることがわかっていますが、現時点では Merge メカニズムはなく、Truncate までに増加し続けるでしょう。そのため、Rocksdbなどの独自機構と比較すると、容量が大きくなるという問題が発生します。
リモートストレージのコストが比較的安いことは言及に値します。たとえば、Aliyun OSS の標準ストレージは約 0.12 元/GB/月です。リモートストレージのコストを少し上げる代わりに、リモートストレージのコストを少し増やすことを検討できます。安定して高速なチェックポイント。
2 つ目は追加の回復オーバーヘッドです。リカバリ中に状態テーブル部分のリカバリに加えて、変更ログ部分もダウンロードして再生する必要がありますが、追加のダウンロードと再生により時間がかかります。
3 つ目は、追加のパフォーマンスオーバーヘッドです。Changelog メカニズムでは追加の二重書き込みステップが導入されており、これはジョブの TPS の上限に影響します。ここで影響を受けるのはジョブの TPS 上限であり、毎日の操作のコアあたりの TPS から、変更ログはより高い値に達する可能性があることに注意してください。

後の実験では、全体的なオーバーヘッドが制御可能であることがわかります。

3. 変更ログのパフォーマンステスト

ここでは、3 つの実験を使用して Changelog メカニズムの安定性と実行パフォーマンスを検証し、空間増幅、回復パフォーマンス、および TPS 制限におけるオーバーヘッドを観察します。

3.1 変更ログ増分チェックポイントの使用

まず、Changelog の使用法を紹介し、実験における関連する基本構成を例とともに紹介します。

最初のパラメータは、Changelog を有効にすることです。Changelog を有効にするには、これを true に設定するだけです。1.16 では、このパラメータの互換性もサポートされています。
2つ目のパラメータは空間倍率をある程度制御できる実体化の間隔で、実験では3分に設定しました。
3 番目のパラメータは、変更ログ部分のストレージメディアです。本番環境では、これをファイルシステムに設定して、変更ログを DFS に保存できます。DFS は現在サポートされている唯一の変更ログストレージであり、将来的には他のストレージ形式の起動を検討します。。
4 番目のパラメーターは、DFS 上の変更ログのストレージパスです。これは、3 番目のパラメーターが [ファイルシステム] に設定されている場合に設定する必要があり、構成方法はチェックポイントパスと似ています。

3.2 ベンチマーク実験計画

テスト全体は 3 つの実験に分割され、RocksDB と Changelog がオンになっているときのジョブインジケーターを比較およびテストし、Changelog がジョブにもたらすメリットと追加のオーバーヘッドを観察し、オーバーヘッドの制御可能性を示します。

実験 A: 毎日の交通状況における、さまざまな状態サイズでの CP の安定性、速度、空間倍率の比較テスト。このうち、メモリフル状態のシーンとディスクストレージ後のシーンにそれぞれ対応する、シングル同時100MBと1.2GBの2つの設定を設定しました。

実験 B: 実験 A に基づいて、毎日のトラフィックの下でジョブ回復のパフォーマンスを比較およびテストする例外を手動で作成することによってフェールオーバーがトリガーされます。

実験 C: ジョブにバックプレッシャーを与え、バックプレッシャー下でのテストステータスオペレーターの TPS を比較して、TPS に対する変更ログの二重書き込みの影響を観察します。

ここでは主に値状態のテスト結果を記録します。また、ウィンドウ状態など、さまざまなタイプの状態とさまざまな演算子のパフォーマンスもテストしました。データのこの部分は、フォローアップのブログ投稿でさらに共有されます。

まず、Checkpoint の時間のグラフから Checkpoint の安定性を確認できます。

上の図からわかるように、RocksDB のチェックポイント期間は比較的不安定ですが、サブタスクの詳細と Rocksdb メトリックを開くと、この時間の長さがコンパクションに関連していることがさらにわかります。変更ログは比較的安定しており、増分を継続的にアップロードする方法により、変更ログのチェックポイントを非常に安定させることができます。

さらに、チェックポイント期間の変更がチェックポイントサイクルに関連していることがわかります。たとえば、4 つごとに長くなるのは、前述のチェックポイント同期フェーズ中に MemTable Flush がトリガーされ、LO 層がトリガーされるためです。 RocksDB のデフォルトは 4 ごとです。これにより、圧縮がトリガーされ、より多くのファイル更新が発生し、Rocksdb チェックポイントの不安定性がさらに悪化します。

Checkpoint の実行パフォーマンスについては、State Size が増加するにつれて、Changelog を開いてからの Checkpoint の p99 所要時間は約 1 秒で安定するのに対し、Rocksdb の所要時間は 8 秒から 20 秒近くまで増加していることが道路からわかります。。これは、Changelog が固定増分を継続的にアップロードする方法により、チェックポイントがトリガーされたときの増分サイズが非常に安定して高速になるためです。

実験 A では、Changelog を開くと追加のスペースオーバーヘッドが発生し、これは Rocksdb の約 1.2 ～ 2 倍であり、メモリ内にある場合など、状態が小さくなり、状態が大きくなることがわかります。これは、RocksDB のマージメカニズムの方が、操作ログを記録する Changelog よりも総データ量を削減できるためです。特に、RocksDB は、状態がメモリ内にある場合にパフォーマンスが向上します。

この状況では、変更ログ部分のマージをサポートすることで、スペースのオーバーヘッドをさらに削減できます。しかし、現状に関する限り、前述したように、リモートストレージのコストは比較的安価であり、リモートストレージのコストがわずかに上昇しても、より安定した高速なチェックポイントと交換することを検討できます。

変更ログ部分のマージをサポートすることで、スペースのオーバーヘッドを削減できます。しかし、現在の状況に関する限り、リモートストレージのコストは比較的安価です。前述したように、より安定した高速なチェックポイントと引き換えに、リモートストレージのコストが若干増加することを考慮できます。

実験 B は主に追加の回復オーバーヘッドをテストします。Local Recovery が有効になっていない場合、変更ログを開くには Rocksdb と比較して約 40% 追加の時間がかかりますが、Local Recovery を有効にすると、両方のリカバリのオーバーヘッドはほぼ無視できます。同時に、Checkpoint のエンドツーエンドの時間消費の改善と組み合わせて、ジョブの全体的なフェイルオーバープロセスを考慮すると、変更ログを開いた後の処理が速くなります。

変更ログのリカバリのオーバーヘッドは主にどこから発生しますか? 以下の式からわかるように、追加のオーバーヘッドは主に変更ログ部分のダウンロードと再生によって発生します。ローカルリカバリを有効にすると、ダウンロード時間は消去され、再生時にわずかなオーバーヘッドが追加されるだけです。この部分はさらに最適化することができ、たとえば、リモート適用、つまりリモート事前マージの方法を通じて、実行時に変更ログ部分がステートテーブルファイルに継続的に適用されるため、再生する必要があるデータが削減されます。同時に、この方法ではリモートストレージのオーバーヘッドも削減できます。

しかし現時点では、オーバーヘッドへの影響はそれほど大きくなく、最も核となる最適化ポイントに焦点を当てて開発できるように、誰でもフィードバックを利用することができます。

実験 C では、ジョブにバックプレッシャーを与え、同時にチェックポイントとローカルリカバリを段階的に有効にして、制限 TPS に対する変更ログとローカルリカバリの影響を観察します。以下の図からわかるように、RocksDB と比較して二重書き込みのオーバーヘッドが追加されるため、Changelog の制限 TPS は約 10% ～ 20% 低下します。ただし、3 回の書き込みによるオーバーヘッドが追加されるため、ローカルリカバリをオンにすると、制限 TPS が約 5% 低下します。この部分のパフォーマンス向上は FLINK-30345 で完了しました。テストの詳細については、フォローアップのブログ投稿を参照してください。

4. まとめと計画

この共有は、まず Checkpoint の基本概念から始まり、多数の Checkpoint 最適化テクノロジとそれらの Flink UI への反映を紹介し、次に RocksDB Incremental Checkpoint メカニズムに存在する問題から始まり、Changelog の設計目標につながり、変更ログチェックポイントメカニズム。最後に、3 つの実験を通して、Changelog の利点とコストを直感的に感じ、Changelog の使用法についても紹介します。

将来的には、次の 3 つの方向で最適化していきます。

上記 3 つの問題に対するさらなるパフォーマンスの最適化。
Fault Tolerance 2.0 のメンバーとして、フォールトトレランスプロセス全体が軽量になり、使いやすくなります。
Table Store と組み合わせると、Table Store のデータの鮮度が向上します。

元のリンク

この記事は Alibaba Cloud のオリジナルのコンテンツであり、許可なく複製することはできません。