要約: この記事は、Flink Forward Asia 2022 データ統合セッションでのリアルタイム エンジンの研究開発エンジニアである Yuan Kui の共有を基に編集されたものです。この記事の内容は主に次の 4 つの部分に分かれています。
- Xiaohonshu のリアルタイム サービスはコストを削減し、効率を向上させます。
- フリンクとオフラインのハイブリッド練習
- 実際に遭遇した問題とその解決策
- 今後の展望
1. 小紅書リアルタイムサービスのコスト削減と効率化の背景
1.1 小紅書 Flink の利用シナリオの特徴
Xiaohongshu の Flink 機能には、次の 3 つの項目が含まれます。
-
まず、クラウドネイティブで複雑なマルチクラウド、国内および海外のアーキテクチャです。小紅書は創業以来、すべての技術システムをパブリッククラウド上に構築しており、本当の意味でのクラウドネイティブです。
当社は、AWS、Tencent Cloud、Huawei Cloud、Alibaba Cloud などの多くのクラウド ベンダーと協力してきました。長年の開発を経て、ビジネス データもさまざまなクラウド ベンダーに分散されました。クラウド ネイティブ自体は、リソースの分離と拡張が非常に簡単であるなど、当然の利点をもたらします。
-
2 番目に、データ統合リンクが長く、ピーク時にリソースが相互にプリエンプトされる現象が発生します。データ統合を例に挙げると、マルチクラウド アーキテクチャではデータがクラウド間で送信されることが多いため、データ統合タスクは重要かつ不可欠です。過去に Flink のデータ統合用に専用のクラスターを構築しましたが、データ統合タスクの増加に伴い、リソースのプリエンプションがますます多く発生しました。
Flink 統合タスクはすべてバッチ タスクであるため、そのほとんどが早朝に同時に集中的に実行され、一部のタスクはリソースを確保できないために失敗します。同時に、日中に実行されるバッチ タスクが比較的少なく、この時点ではリソースがアイドル状態であるため、リソース プール全体の全体的な使用率も比較的低くなります。
-
3 番目に、データ統合の高品質ジョブと低品質ジョブは Flink フロー モード エンジンによって実行されます。歴史的な理由がいくつかあり、1 つは初期の Flink バージョンのバッチ モード エンジンが成熟していないこと、もう 1 つはストリーム モードが比較的シンプルで高速であり、中間データの問題を考慮する必要がないことです。ストレージ。リソースが豊富な場合は、より良い選択です。
1.2 小紅書 Flink データ統合サービス
小紅書には、Hive から Clickhouse、Hive から Doris、Hive から MySQL、Mongo から Hive など、多くの種類の典型的なデータ統合があります。
上の図の右側は上の図です。データ ソースは Mongo ルックアップ結合を実行し、2 つのストリームに分割されてダウンストリームに書き込まれます。これは典型的な Flink データ統合タスクです。
1.3 コスト削減と効率向上のための一般的な環境要件
小紅樹の発展に伴い、インフラはますます完璧になり、リソースの使用はより標準化されました。過去の野蛮なリソース適用の時代は終わり、現在ではクラスターの CPU 使用率がますます注目されるようになりました。
これに関連して、Flink のリソース クラスターを見てみましょう。一方で、現在の Flink リソース クラスターは主に排他モードを採用しており、一部の小さなリソース プールではタスクが少ないため、リソースの断片化とリソースの無駄が発生しやすくなります。一方、Flink 統合タスクのクラスターは夜間にリソースのプリエンプションを備えていますが、日中はリソースがアイドル状態であるため使用できず、全体のリソース使用率が低くなります。
上記の 2 つの問題に対して、全体的なリソースの使用率を向上させる解決策は何でしょうか? 以下の2点に分けられます。
- まず、小規模クラスターを回避する方法についてです。小規模クラスターをマージし、K8s リソース クォータと連携してリソースを分離できます。さらに、コンテナ チームが提供するオフライン混合クラスターを使用する、より良いソリューションがあります。小規模クラスタのタスクをオフライン ハイブリッド クラスタに移行し、小規模クラスタのリソースを解放します。
- 2 番目に、ピーク時のリソースのプリエンプションを削減する方法です。プラットフォームの観点からは、リソースのスケジュールを最適化し、タスクの優先順位を調整できます。Flink エンジンの観点からは、バッチ モード エンジンの方がリソース要件が低いため、Flink のバッチ モード エンジンを推進できます。しかし、私たちの入り口は異なり、リソースの観点から考えています。
1.4 コスト削減と効率化の観点から見たFlinkストリームモード/バッチモードの比較
次に、Flink のストリーム モードとバッチ モードをリソースの観点から比較してみましょう。
Flink のフロー モード エンジンには、実行中にステージの概念がなく、データはパイプラインの形式で流れます。これには、プログラムが正常に実行できるように、すべてのオペレーターと同時リソースがリアルタイムで準備されている必要があります。バッチ モード エンジンの場合、タスクはいくつかのステージに分割されており、次のステージは前のステージが完了した後にのみ実行でき、一部のオペレーターと同時に取得されたリソースのみを実行できます。
別の観点から見ると、一部の集計タイプのバッチ タスクでは、ストリーム モードで実行すると必然的にステートとウォーターマークが導入され、より多くの CPU リソースとメモリ リソースが必要になります。バッチ モード エンジンでは、状態とウォーターマークは必要ありません。シャッフル中間データのみが必要です。これには大量のディスクも必要ですが、ディスクは CPU やメモリよりも安価です。
これは、リソースの観点から見たストリーム モードとバッチ モードの比較であり、バッチ タスクをストリーム モードからバッチ モードに切り替えて実行する場合の考慮事項でもあります。
2. フリンクとオフラインのハイブリッド演習
2.1 オフライン混合展開の K8s クラスター
まずオフラインミキシングとは何かを見てみましょう。一般に、企業には 2 種類のサービスがあります。1 つはオンライン サービスで、実行時間が長く、サービス トラフィックとリソース使用率が変動するという特徴があります。つまり、ユーザが多い日中はリソース利用率が高くトラフィックが多くなり、夜間にユーザが減るとリソース利用率も低下する。もう1つはオフライン作業です。一定期間のみ実行され、実行期間中のリソース使用率は非常に高く、通常は遅延の影響を受けません。実行が特定の時点より前に終了する限り、リソースはアイドル状態になります。
いわゆるオフライン ミキシングとは、リソースの全体的な使用率を向上させるために、オンライン サービスのアイドル状態のリソースをオフライン操作に使用することを指します。オフライン ビジネスの場合、リソース使用コストを大幅に削減できます。オフラインタスクの混在実行中は、オンラインサービスを保護する必要があり、オフラインサービスの動作に対してリソース抑制などの操作が行われる場合があります。
上の図は、オフライン ハイブリッド クラスターの概略図です。コンテナー チームは、各オンライン サービス クラスターのアイドル状態のリソースを収集して、リソース クラスターを形成します。ユーザーの観点からは、一部の仮想ノードしか見えませんが、実際には、各仮想ノードは 1 つ以上の実際のリソース ノードに対応します。ユーザーにとって、仮想クラスターの使用は実際の排他的クラスターの使用と同じです。唯一の違いは、仮想ノードのリソースが常に変化する可能性があることです。コンテナ チームがオフライン ハイブリッド クラスターを提供してくれました。たまたまオフライン タスクがあり、リソース使用率にプレッシャーがかかっていたため、意気投合しました。
2.2 オフラインミキシングに適したオフラインタスクの特徴
どのタスクが移行に適しているかについての主な考慮事項は、次の 3 つの特性です。
-
1 つ目は、オフライン混合クラスターではオフライン リソースが圧縮され、オフライン タスクの実行時間が長くなる可能性があるため、移行されるタスクは遅延に敏感でなければならないということです。
-
2つ目は、タスクには潮流の特性があり、リソースが空いたときに大量に実行されるオフラインタスクを選択して移行する必要があることです。一般に、オンライン サービスは夜間に比較的アイドル状態のリソースを持ちますが、オフライン タスクは夜間に集中して実行されるため、より適切です。
-
3 つ目はフォールト トレランスです。オフライン タスクのリソースが圧縮され、オフライン混合中にポッドが削除される可能性があるため、タスクには特定のフォールト トレランスが必要です。
2.3 オフラインミキシングに適したFlinkタスク
バッチタスクの場合、Pod が削除される可能性があるため、削除されると、他のノードでプルアップされたときにデータが再消費され、データの重複が発生する可能性があるため、冪等挿入をサポートするかどうかをシンク側で選択する必要があります。 Care 重複データのバッチタスク移行。バッチ モード エンジンの場合、すべてのオペレーターを可能な限り一緒にチェーンし、タスク移行のこの部分を選択する必要があります。オペレーターが一緒にチェーンされていない場合、中間データはディスク上に配置され、リソース ノードに対する要件が高くなるためです。オフライン混合クラスターのリソースは夜間は比較的アイドル状態であるため、夜間に大量に実行されるバッチ タスクの移行を選択するようにしてください。一般に、オフライン混合クラスターはアップストリーム タスクには適していませんが、ストリーミング タスクの一部をサポートできる日中アイドル状態のリソースがあるため、低品質のストリーミング タスクも移行することを選択します。これらのストリーミング タスクは、フェイルオーバーを許容できる場合、一定期間の遅延は許容されます。
2.4 Flink とオフラインの共同構築
まず、排他的ノードを持たない Flink 排他的クラスターをデプロイし、次にコンテナー チームが仮想ノードを排他的クラスターにデプロイします。仮想ノードの背後にはコントローラーと実際のリソース ノードがあり、タスクを送信するときは、タスクを仮想ノードに送信するだけで済み、デプロイメントによって仮想ノード上の JobManager Pod がプルアップされます。最後に、作成プロセスは、仮想ノードのコントローラーによってその背後にある実際のリソース ノードに送信され、実行されます。
Flink Native K8s メソッドを使用しているため、TaskManager は JobManager によってプルされます。この作成プロセスはデプロイメントのプロセスと同じであり、実行のために仮想ノードによって実際のリソース ノードに送信されます。つまり、最終的には、JobManager と TaskManager の Pod はすべてその背後にあるリソース ノード上で実行され、仮想ノード上には Pod のミラー イメージのみが存在します。Configmap、Service、Ingress などの K8s リソースの場合、そのソース データは ETCD に保存され、その一部のみを同期する必要があります。
このように、Flink 専用クラスターでは正常にタスクを投入でき、kubectl コマンドによる Pod の操作も正常に行えるようになり、私たちにとってオフライン仮想クラスターの使用は通常の Flink 専用クラスターを使用することと同じになります。もちろん、実装プロセスにはいくつかの問題があり、たとえば、JobManager と TaskManager が 2 つのクラスターに属し、それらの間でどのように通信するか、ログと監視指標をどのように収集するかなど、エンジニアリング実装上の問題がいくつかあります。ここでは詳細には触れません。
3. 実際に遭遇した問題とその解決策
最後の部分は、私たちが実際に遭遇したいくつかの問題についてです。ここでの質問は、クラウド ネイティブとして、私たちがクラウド ネイティブで遭遇したいくつかの問題と解決策にも焦点を当てています。
3.1 ホスト上に一時データファイルが残らないようにする
最初の疑問は、ホスト マシン上に一時データ ファイルが残らないようにする方法です。K8s コンテナー テクノロジを使用したことがある人なら誰でもこのような問題に遭遇するでしょうが、デフォルトではコンテナーが起動され、コンテナー内の一時データ ファイルは Docker ディスクに保存されます。一時データ ファイルが大きすぎると、Docker の実行の安定性に影響しますが、この時点で、コンテナに別のデータ ディスクをマウントし、一時データ ファイルをこのデータ ディスクに書き込むことで、影響を及ぼさないようにすることができます。 docker sex の実行安定性。
K8s では、データ ディスクは通常、hostPath ボリューム マウント方法でマウントされます。この方法の利点は、ホストのマウント ディレクトリを指定できることです。マウント方法は単純ですが、hostPath マウント方法は、ホストの一時ファイルのクリーニングに依存します。プログラム自体のロジック。ポッドが異常終了した場合 (たとえば、ポッドが OOM に遭遇して K8s によって強制終了された場合)、一時データ ファイルのクリーンアップ ロジックを実行する時間がなく、ポッドが終了した場合、一時データ ファイルはホスト マシン上に残ります。残りのファイルが増えてデータ ディスク全体を占有すると、タスクの動作の安定性に影響します。では、どうやってそれを解決したのでしょうか？
K8s には、Pod と同じライフサイクルを持つ emptyDir というマウント方法があります。したがって、Pod が正常に終了したか異常に終了したかに関係なく、終了後に emptyDir マウント ディレクトリ内の一時データ ファイルがクリーンアップされ、プログラムのクリーンアップ ロジックへの依存が軽減されます。
ここで注意すべき点の 1 つは、emptyDir ではマウント ディレクトリを指定できず、デフォルトで kubelet 作業ディレクトリがストレージに使用されることです。通常、このディレクトリはシステム ディスク内にあります。処理が行われない場合、一時ファイルがシステム ディスクに書き込まれると、システムの動作の安定性に影響を与える可能性があります。そのため、通常、起動時に kubelet の作業ディレクトリを別のデータ ディスクに変更する必要があります。 . .
3.2 クラウドネイティブシナリオにおけるバッチモードの OOM 問題
2 番目の質問は、クラウド ネイティブ シナリオにおけるバッチ モードの OOM 問題です。このタスクはストリーム モード エンジンでは非常にスムーズに実行されますが、バッチ モード エンジンに切り替えて実行すると、OOM の問題が頻繁に発生します。
このタスクには、チェーンの後に 2 つの演算子がまだあります。つまり、データ シャッフルが途中で実行され、シャッフル データを書き込むこの段階で OOM が発生します。上図の右上隅にある監視図から、2 つの段階が明確にわかります。最初の段階は、Shuffle データを書き込む段階です。場合によっては、ワークセットが急増します。コンテナーの制限を超えると、OOM が発生します。キルが発動します。
この場合、まず、Flink の WebUI からヒープ メモリの使用状況を観察します。現在、ヒープ メモリの使用状況は正常であり、GC 監視インターフェイスからも GC の状況が正常であることがわかります。次に、オフヒープ メモリにリークがある可能性があると考えられるため、Pod に入り、pmap コマンドを通じて RSS の使用状況を確認します。つまり、右下の写真では、RSS も正常であり、RSS はわずか 7G 程度であり、制限の 20G には達していません。つまり、アウトによって引き起こされたものではないことがわかります。ヒープメモリリーク。
答えはすでにここにあります。ワークセット インジケーターは、単純に RSS+ページ キャッシュとして理解できます。RSS は正常ですが、ワークセットが再び高騰しているため、OOM はページ キャッシュによって引き起こされていると疑うことができます。
この考え方に従って、マシン ノードにログインしてマシン ログを確認します。上の図に示すように、コール スタックが見つかり、ページ キャッシュの適用によって OOM が発生していることがわかります。実はクラウドディスクの性能が不足しており、シャッフルデータを瞬時に大量にページキャッシュに書き込むと、ディスクへのフラッシュが間に合わず、メモリの過剰使用が発生し、OOM Killが発生してしまいます。
一時的な解決策があります。ポッドの数を増やし、単一のポッドで処理されるデータの量を減らしてから、ポッドを別のマシン ノードに分散してマシン ノードへの負荷を軽減してみます。または、マシンのカーネルをアップグレードし、カーネル パラメーターを調整して電流を制限します。さらに、Flink エンジン自体から開始して、シャッフル データ ステージで電流を直接制限することもできます。
4. 今後の展望
小紅書が今後模索する方向性は主に以下の3つからなる。
- まず、バッチ モードでは深掘りが適用されます。私たちはユーザーを深く掘り下げ、バッチ モード エンジンの使用シナリオをさらに調査し、Flink のストリームとバッチの統合を真に推進したいと考えています。
- 次に、K8s のリソース クォータ機能を使用して、ビジネス側の複数の小さなクラスターをマージし、マシンのリソースの断片化の問題を軽減します。
- 3 番目に、サーバーレスはクラウド ネイティブ環境でバッチ モード エンジンを展開するための重要な目標ですが、強制的にサーバーレスとして展開すると、ポッドが強制終了された場合に中間データがクリーンアップされ、タスクの障害回復に影響します。このとき、リモート シャッフル サービス シャッフルの値が反映され、リモート シャッフル サービスを使用すると、ローカル ディスクへの部分的な依存を効果的に削減し、リソース使用率を向上させ、クラウド ネイティブ アーキテクチャを支援できます。