Zhihu におけるマルチクラウド キャッシュの進化

1. マルチクラウドキャッシュの背景

1. マルチクラウドアーキテクチャ

Zhihu は現在、主に次の 3 つの考慮事項に基づいて、マルチクラウド アーキテクチャを採用しています。

• サービスがより活発になります。これは、特定のコンピュータルームが不可抗力に遭遇し、サービスを提供できなくなった場合に、業務が完全に中断されることを防ぐためです。
• 容量拡張。一つのコンピュータ室の収容能力の上限は1万台であり、Zhihuの現在のサーバー規模は1万台を超えています。
• コストを削減し、効率を高めます。同じクラウド サービスでも、クラウド ベンダーによって価格が異なります。比較的低価格で高品質なサービスをご利用いただければ幸いです。

Zhihu には現在 5 ～ 6 のデータセンターと 2 つのコア コンピューター ルームがあります。 1 つはオンライン コンピューター ルームで、コメント、回答、推奨事項などのサービスを Zhihu メイン サイトのユーザーに直接展開します。もう 1 つはオフライン コンピュータ ルームです。ここでは主に、共通データ プラットフォーム、オフライン ストレージ、OLAP エンジンなどのオフライン コンピューティング関連サービスを展開します。 2 つのコンピューター ルームは専用回線を介して通信するため、専用回線は非常に重要です。

コンピュータ室の専用回線が安定しているかどうかを測る重要な指標の一つは、コンピュータ室のトラフィックです。一般的に、サービス間の通話はデータセンターのトラフィックをほとんど使用しないため、データセンター内の専用回線トラフィックには影響しません。ただし、私たちのアルゴリズムのシナリオでは、コンピューター ルームの専用回線全体を直接占有するという非常に特殊な状況があります。これは次に紹介する推奨/検索モデルのオンラインシナリオです。

2. 推奨/検索モデルのオンラインシナリオ

私たちのモデルの出力は、大規模な分散コンピューティングのためのオフライン コンピュータ ルームの機械学習プラットフォームと Spark クラスターに依存しており、モデルは最終的にオフライン HDFS に書き込まれます。モデルがオンラインになると、推論サービス コンテナーには数百または数千のコンテナーが含まれる場合があります。同時に HDFS からモデルをプルすると、専用回線間のトラフィックが大量に発生し、次の 2 つの問題が発生します。

• トラフィック過多により専用回線が利用できなくなり、専用回線の帯域がそのまま占有されてしまいます。
• 同時実行性が高すぎる場合、DN ホット ノードが表示されます。高い同時実行性で HDFS をプルする場合、同じモデル ファイルがプルされるため、HDFS で DataNode ホット ノードの問題が発生する可能性があります。

3. 複数の HDFS クラスタ ソリューション

当初、このモデルを立ち上げる際の問題に対する私たちの解決策は非常にシンプルで、マルチ HDFS クラスター ソリューションでした。これまでのオフライン HDFS から直接プルするのと比較して、モデルが生成された時点でオフライン コピー タスクを使用してモデルをオンライン HDFS にコピーし、プル時にオンライン HDFS から直接モデルを読み取ります。これには 2 つの利点があります。

• 専用線トラフィック問題を解決しました。オフラインコピータスクは、モデルが専用ラインを 1 回だけ通過することと同等です。また、オフラインコピータスクは定期的に実行されるタスクであるため、多数のタスクがまとめてコピーされるのではなく、キューにコピーされるため、この専用回線のトラフィックを制御することができます。
• ファイルのコピーを追加すると、ホットスポットの問題が解決しました。オンライン HDFS は、DataNode のホット ノード問題を解決するためにファイル レプリカを追加します。

ただし、このアプローチにはいくつかの欠点もあります。

• 複数の HDFS クラスターを維持するのは困難です。オンライン HDFS とオフライン HDFS の両方があります。
• 新しいオフライン コピー タスクが導入され、ファイル ビューを維持することが困難になりました。オンライン HDFS とオフライン HDFS のファイルビューは異なるサービスであるため、使用するのは非常に面倒です。
• 新しい HDFS クラスターを作成し、ファイルのレプリカを追加すると、ストレージ コストが急増します。

2. 自社開発部品段階

次に、3 番目の反復バージョンである、独自に開発したコンポーネント UnionStore を紹介します。

1. 自社開発コンポーネント - UnionStore

当社が独自に開発したマルチクラウド キャッシュ コンポーネントは、UnionStore と呼ばれます。名前が示すように、これは HDFS とオブジェクト ストレージを組み合わせてオブジェクト ストレージへのアクセス インターフェイスを提供する共同ストレージを意味します。ワークフローは次のとおりです。モデルは機械学習プラットフォームと Spark を介して出力され、最終的に HDFS に書き込まれます。読み取り時には、オブジェクト ストレージ プロトコルを通じて UnionStore にリクエストが送信されます。ファイルの読み取り要求を受信すると、UnionStore はオブジェクト ストレージにファイルが存在するかどうかを確認します。そうであれば、ファイルを直接ユーザーに返します。そうでない場合は、オフライン HDFS からファイルを読み取り、オブジェクト ストレージにアップロードし、最終的にオブジェクト ストレージからユーザーに返します。

2. UnionStoreの利点

UnionStore の利点は次のとおりです。

• オブジェクト ストレージ プロトコルを提供します。
• 自動キャッシュ メカニズムは、スケジュールされたコピー タスクに代わるものです。最初にオブジェクト ストレージと HDFS 内のファイルの一貫性をチェックし、次にオブジェクト ストレージにキャッシュされているかどうかを確認する自動キャッシュ メカニズムを備えています。元のスケジュールされたコピー タスクを置き換えます。
• ファイル表示に関する問題を修正しました。 UnionStore のファイル ビューはオフライン HDFS に大きく依存しているため、ファイル ビューの不一致の問題は発生しません。
• 保管コストの削減。 HDFS クラスターを停止し、オブジェクト ストレージに置き換えて、ストレージ コストを削減しました。
• HDFS を読み取るための POSIX ソリューションを提供します。

これはUnionStoreの最初の使用シナリオです。 UnionStore はオブジェクト ストレージ アクセス メソッドを提供します。また、1 つのことも可能です。ユーザーは s3fs-fuse を使用して UnionStore を POSIX ローカル ディレクトリにマウントし、ローカル ディレクトリから直接トレーニング データを読み取ることができるため、機械学習プラットフォームのサポートが向上します。

このソリューションは、発売されるとすぐにユーザーから好評を博しました。当時、HDFS をマウントする方法は 2 つありました。 1 つ目は Hadoop コミュニティが提供する HDFS マウント ローカル ディレクトリ方式で、もう 1 つは Go 言語で記述された HDFS マウント方式です。しかし、どちらの解決策も再試行しても十分ではありません。 s3fs-fuse の再試行の方が優れているため、s3fs-fuse を選択しました。

3. UnionStoreのデメリット

UnionStoreは2年間、芝湖で営業しています。初期段階では問題はありませんでした。しかし、モデルの規模が拡大し続けるにつれて、次のような問題が徐々に発生しました。

• メタデータは HDFS に大きく依存します。 HDFS がジッタすると、頻繁に更新する必要がある一部のモデル ファイルが影響を受けて更新できなくなり、UnionStore が使用できなくなることがあります。
• ファイルのキャッシュ時にユーザー リクエストが停止し、ファイルのコールド リードが遅くなります。ファイルをキャッシュするときに、UnionStore はチェックを実行し、ユーザーの要求をブロックして、コールド リード ファイルが非常に遅くなる原因になります。
• オブジェクト ストレージにはパフォーマンスの問題があり、読み取り速度が遅くなります。シングルスレッドの読み取り速度が非常に遅いだけでなく、オブジェクト ストレージ全体に帯域幅があります。一般的に、クラウドベンダーが信頼できる場合、約 1 TB の帯域幅を提供できます。そうしないと、数百 GB しか提供できず、明らかにニーズを満たすことができません。
• S3 ヒューズ コンポーネントは HDFS メタデータ要求を増幅し、パフォーマンスにかなりの影響を及ぼします。

上記の欠点により、2 つの選択肢が残ります。最初の選択肢は、UnionStore を継続的に反復して、社内のニーズを満たすようにすることです。 2 番目のオプションは、UnionStore の使用シナリオを置き換える適切なオープン ソース ソリューションを見つけることです。人的資源の貴重さを考慮して、私たちは 2 番目の選択肢を選択し、適切なオープン ソース ソリューションを探しました。

オープンソース ソリューションでは、2 つの使用シナリオを解決する必要があります。 1 つ目は、モデル読み取り高速化シナリオであり、オブジェクト ストレージ プロトコルの提供が必要です。 2 つ目は、モデル トレーニングの高速化シナリオであり、ローカル ディレクトリにアクセスする方法を提供する必要があります。

アルクシオフェーズ

私たちは多くのオープンソース ソリューションを調査し、多くの内部キャッシュ コンポーネントも検討しましたが、Alluxio だけが私たちのニーズを満たすことができることがわかりました。 Alluxio には次の利点があります。

• 高性能なデータ キャッシュ機能。オブジェクトストレージのパフォーマンスが低いという問題を解決できます。キャッシュは透過的であり、ビジネス関係者は変更を加えることなく直接オンラインにアクセスできます。透過的なキャッシュ機能は非常に重要です。以前は他のマルチクラウド キャッシュ コンポーネントもいくつかありましたが、キャッシュは透過的ではなく、読み取る前に書き込む必要がありました。しかし、データは HDFS に保存されていたため、ニーズを満たすことができませんでした。
• アクセスインターフェースは非常に豊富です。ローカル ファイル アクセス メソッドとオブジェクト ストレージ プロトコルを提供できる Alluxio fuse を提供します。
• 豊富な UFS サポート。 HDFS とオブジェクト ストレージの両方をマウントできます。

これら 3 つのポイントは私たちのニーズを満たすのに十分ですが、さらに次の 3 つの機能も提供します。

• メタデータ キャッシュ。これにより、NameNode の負荷が効果的に軽減されます。
• アドホック クエリ シナリオを高速化します。アドホック クエリ シナリオに対する加速適応性は非常に優れています。私たちは社内で主なアドホック シナリオ クエリとして Spark と Presto を使用しており、Alluxio コミュニティには私たちが学ぶべき事例が数多くあります。
• コミュニティは活発です。モデルがオンラインになると、コミュニティからのさまざまな解決策を参照できるようになり、問題が発生したときにコミュニティにサポートを求めることもできます。コミュニティは私たちに多くの援助を与えてくれます。

調査を通じて機能がニーズを満たしていることを確認した後、それを使用してモデルを立ち上げました。

1. モデル読み取り加速シナリオ

最初のシナリオは、モデル読み取り加速シナリオです。次に、クライアントの選択、パフォーマンス テスト、展開とチューニング、オンライン効果の 4 つの側面を紹介します。

（1）クライアントの選択 - S3プロキシ

次の理由から、モデルの読み取りシナリオを高速化するために Alluxio S3 Proxy を選択しました。

• 現在ユーザーが使用している UnionStore オブジェクト ストレージ プロトコルは、当然ながら S3 Proxy と互換性があります。
• 単一のユーザー コンテナーで使用できるリソースは比較的小さいため、Alluxio fuse は除外されます。これは、Alluxio fuse がローカル キャッシュに大きく依存し、ローカル メタデータ キャッシュが比較的大きなディスクとメモリを消費するためです。
• ユーザーがファイルを読み取るための言語は、Python、Java、Golang の 3 つです。 Zhihu は当初 Python を使用してメインサイト プログラムを作成し、その後 Golang と Java に切り替えたため、Alluxio Java クライアントも Java 言語のみをサポートしているためここでは除外されます。

（２）Alluxio S3 Proxyパフォーマンステスト

Alluxio S3 Proxy で、HDFS、UnionStore、Alluxio を比較する一連のパフォーマンス テストを実施しました。ファイルのホット リード時に、Alluxio のパフォーマンスが他の 2 つのコンポーネントのパフォーマンスをはるかに上回っていることがわかりました。 100GB のファイルをホット リードするのに必要な時間は、UnionStore の 1/7 に過ぎませんでした。この加速効果は非常に明白です。

（３）展開方法

以下の理由により、K8S デプロイメントではなくベアメタル デプロイメントを選択しました。

• ワーカーはディスクに大きく依存します。他のアプリケーションとディスクを共有すると、ワーカー自体のパフォーマンスに影響が出る可能性があります。
• ワーカーはデータを非常に速く読み取るため、ネットワーク カードがすぐにいっぱいになり、他のサービスに影響を与える可能性があります。 K8S デプロイを行う場合、Worker と同じ K8S ノードに他のサービスがデプロイされていると、ノードのネットワーク カード リソースが占有され、他のサービスを呼び出すことができなくなります。
• ベアメタル マシンは S3 プロキシとワーカーが混在してデプロイされるため、ショートサーキット読み取りの設定が容易になります。当然のことながら、ショートサーキット読み取りをサポートします。
• Zhihu は Ansible 上に構築された独自のビッグデータ運用・保守プラットフォームを持っているため、K8S には運用・保守上の利点はあまりありません。

ここでの展開方法は S3 プロキシであり、最終的にドメイン名はユーザー アクセス用の DNS プロキシを通じて提供されます。

（4）展開とチューニング

モデル読み取りシナリオの最適化は、モデル読み取りシナリオの特性と組み合わせて実行する必要があります。モデル読み取りシナリオには、次の 3 つの特徴があります。

• 高い同時実行性。 1 つのモデル ファイルがオンラインの場合、トラフィックは 1 秒あたり 1 TB に達する可能性があります。
• すぐに期限切れになりました。モデル ファイルは短期間のみ使用され、読み取られた後は期限切れとみなされます。
• キャッシュ侵入。データ生成からデータ読み取りまでの時間間隔は数秒と短いため、事前に予熱することは基本的に不可能です。

私たちは、次の 3 つの特性に基づいてターゲットを絞った最適化を実行しました。

• 同時実行性が高いという問題に対処するため、ファイルのキャッシュされたコピーの数に上限はありません。基本的に、各ワーカーはファイルをキャッシュし、各ファイルはクライアントが読み取れるように各ワーカーに存在します。また、トラフィックを節約するために、短絡読み取り用のワーカーとプロキシを混在させます。
• 有効期限が短いという問題に関しては、有効期限が短いことは私たちにとって不利ではなく、むしろ有利です。つまり、クラスターのストレージ容量は非常に小さくて済み、ワーカーは高性能なディスクを完全に使用できるということです。現在、NVME ディスクを使用しており、コストは制御可能です。
• キャッシュ侵入問題は、実際には解決が非常に困難です。最終的に、いくつかのコードを変更し、いくつかのファイル予熱戦略を独自に開発し、リアルタイム予熱を実行しました。

次に、それぞれのチューニング戦略について詳しく説明します。

• チューニング1: ショートサーキット読み取り

左の図は短絡読み取りがない場合の状況を示しています。ユーザーが S3 プロキシにファイルの読み取りを要求すると、2 層のネットワークを通過します。ネットワークの最初の層はユーザーから S3 プロキシまでであり、ネットワークの 2 番目の層は S3 プロキシからワーカーまでです。最後に、Worker はディスク上のファイルを読み取ります。この場合、ネットワーク カードの消費量は非常に大きくなります。

右の図はショート回路の読み取り状況を示しています。ユーザーが S3 プロキシを要求すると、S3 プロキシはワーカーを経由せずにディスク上のデータを直接読み取ります。これは、S3 プロキシとワーカー間のトラフィックを節約することと同じです。当社のオンラインテストによれば、トラフィックを約 30% ～ 50% 節約できます。

• チューニング2: リアルタイムファイル予熱戦略

簡単に言えば、リアルタイムのファイル事前加熱戦略は、分散負荷機能を S3 プロキシに統合することです。 S3 プロキシはダウンロード要求を受け入れると、ファイルをブロックに分割し、各ファイル ブロックを異なるワーカーに送信して同時キャッシュを行います。これを行う利点は、ファイルをダウンロードするときに、先頭部分がキャッシュされずダウンロードが非常に遅くなる可能性があるが、後続のファイルを読み取るときに、他のワーカーがすでにファイルをキャッシュしている可能性があるため、速度はキャッシュをヒットするのとほぼ同じになる可能性があることです。ファイルが大きくなるほど、この高速化戦略の効果は顕著になります。 10GB のファイルなど、大きなファイルを読み取る場合、読み取り速度はコールド リードよりも 2 ～ 5 倍速くなります。 100GBであれば基本的にはホットリードと同じです。

2 番目の利点は、後の順序のファイル ブロックが事前にキャッシュされているため、UFS トラフィックを節約できることです。オンラインデータ検証によると、UFSトラフィックを2〜3倍節約できます。

リアルタイム予熱戦略の効果を見てみましょう。次の図は、そのラインの実際のスクリーンショットです。その中の各線分は、モデルの読み取り要求を表します。線分が長くなるほど、モデルの読み取りにかかる時間が長くなり、読み取り速度が遅くなります。

フェーズ 1 では UnionStore を使用した読み取り効果を示し、フェーズ 2 では S3 Proxy を直接使用した読み取り効果を示します。全体的な読み取り時間が約半分に短縮されたことがわかりますが、いくつかのスパイクがあり、一部のリクエストの読み取りが非常に遅い可能性があることを示しています。これは、Alluxio のパフォーマンスがファイルのコールド リード時に大幅に低下するためです。

フェーズ 3 では、リアルタイム予熱戦略が開始された後の読み取り効果を示します。基本的にすべてのスパイクが消え、全体的なファイルの読み取り速度も向上していることがわかります。予熱効果はとても良いです。

• チューニング3: メタデータキャッシュ

3 番目の最適化戦略は、特定のメタデータ キャッシュを実行することです。これは 3 つの段階に分かれています。上の写真も、実際にオンライン上のスクリーンショットです。フェーズ 1 では、UnionStore を使用してデータを読み取りますが、これは非常に低速です。フェーズ 2 では、S3 プロキシを使用してデータを読み取るため、時間が短縮され、速度がほぼ 2 倍になります。フェーズ 3 では、メタデータ キャッシュを 1 分間使用するため、初期の UnionStore と比較して速度が数十倍向上します。

メタデータ キャッシュを有効にした後は、ファイルの不整合が発生する可能性があるため、メタデータの同期に特別な注意を払う必要があります。そのため、ファイルの使用仕様もいくつか策定しました。たとえば、新しいファイルを追加するときは、できるだけ新しいディレクトリに書き込み、バージョン番号の形式で管理し、古いファイルを追加したり上書きしたりしないようにユーザーに依頼します。業務履歴から残っているタスクの古いファイルを変更する必要がある場合には、特別な方法も提供しています。 S3 プロキシのコードの一部を変更し、ユーザーがメタデータを更新するための特別なコマンドを追加しました。

• チューニング4: S3プロキシ速度制限

S3 プロキシの速度制限の目的は、ワーカーとビジネス コンテナを保護し、ネットワーク カードが完全に使用されるのを防ぐことです。 S3 Proxy は最大速度が 1.6 GB と非常に高速であるため、ネットワーク カードを大量に消費します。そのため、Worker とビジネス コンテナのネットワーク カードを保護する必要があります。ここでは2つの速度制限を設定しました。 1 つ目は、S3 プロキシ プロセスにグローバルな速度制限を設定し、ワーカー ネットワーク カードを保護できるようにすることです。 2 つ目は、ビジネス コンテナが配置されている K8S ノードを保護し、このノードのネットワーク カード全体が十分に使用されないようにするために、単一の接続の速度を制限することです。この機能はコミュニティに貢献され、バージョン 2.9.0 以降がリリースされました。

下の図は、モデル読み取りの高速化による全体的な効果を示しています。速度が数十倍ほど向上していることがわかります。もちろん、ここでの数十回は、Alluxio クラスターが非常にアイドル状態であるためです。実際のオンライン結果は、UnionStore と Alluxio の速度は同じですが、Alluxio は UnionStore のリソースの半分しか使用しないため、コストを 50% 節約することになります。

2. モデルトレーニングの加速シナリオ

2 番目のシナリオはモデル トレーニングの高速化シナリオであり、これもクライアントの選択、パフォーマンス テスト、展開とチューニング、オンライン効果という 4 つの側面から紹介されています。

（１）クライアントの選択 - Alluxio fuse

クライアントが Alluxio Fuse を選択した理由は次の通りです。

• ユーザーは現在 s3f3-fuse を使用していますが、これは Alluxio fuse に置き換えることができます。
• モデル トレーニング フレームワークは、ローカル ディレクトリを適切にサポートします。たとえば、Tensorflow や PyTorch などのモデル トレーニング フレームワークは、ローカル ディレクトリを最もよくサポートします。 S3 などの他のものもサポートしている可能性がありますが、ローカル ディレクトリほどではないため、Alluxio fuse を選択します。
• GPU マシンは、ボトルネックがメモリ、ディスク、CPU ではなく GPU にあるという点で特殊です。メモリ、ディスク、CPU は比較的アイドル状態です。 Alluxio fuse は、これらのアイドル リソースを最大限に活用して、ローカル データ キャッシュとメタデータ キャッシュを実行できます。

（２）アルクシオヒューズ性能試験

クライアントを選択した後、パフォーマンステストを実行します。テストでは公式のデフォルト構成を使用します。公式のデフォルト設定との違いは 2 つあります。 1 つは、特定のカーネル メタデータ キャッシュが有効になっていること、もう 1 つは、カーネル メタデータ キャッシュを使用するため、コンテナーの合計メモリが非常に大きいことです。

テストベンチマークとしてローカルディスクを使用し、テスト結果は次のとおりです。ローカル ディスクのシーケンシャル読み取り速度は 1800 MB/S、ランダム読み取り速度は 1000 MB/S です。 fuse が 1G の実際のファイルを連続的に読み取ると、速度は 1700 MB/S に達し、これは基本的にローカル ディスクのパフォーマンスの 90% に達します。これは非常に高いパフォーマンスです。 fuse が 100 GB のファイルを連続して読み取ると、パフォーマンスが急激に低下します。これは、以前のコンテナのメモリが 40 GB であり、100 GB のファイルをキャッシュするのに十分なページ キャッシュがないためです。ただし、1GB および 10GB のファイルの場合はキャッシュ ヒットが十分にあるため、パフォーマンスは半分に低下します。

fuse のランダム読み取りパフォーマンスは 450 MB/S と比較的低いですが、モデル トレーニングのニーズを満たすことができ、全体的には期待どおりです。

（３）展開とチューニング

モデルトレーニングシナリオのチューニングは、その特性と組み合わせて実行する必要があります。モデルトレーニングシナリオには、次の 3 つの特徴もあります。

• 十分なリソース。 GPU マシンでは、GPU 以外のリソースは比較的アイドル状態です。
• エクスクルーシブ。 GPU マシンはモデルトレーニングタスクのみを実行します。他のサービスと混在することはありません。トレーニング タスクを実行していない場合はアイドル状態になります。
• ファイルのスナップショット。トレーニング データはファイル スナップショットの形式で整理され、頻繁に更新されないため、メタデータの一貫性に対する要件は比較的低くなります。

fuse プロセスをデプロイするには DeamonSet を使用します。ホスト パスを使用して、キャッシュ データ ディレクトリをレイヤーごとにマウントし、モデル トレーニング コンテナーに提供して使用します。

• Fuse 自体は CSI デプロイメント方式を提供していますが、主に以下の考慮事項に基づいてこれを選択しませんでした。まず、GPU マシンの古い問題があります。ほとんどの場合、それらは非常にアイドル状態であるため、Alluxio fuse はアイドル状態のディスク、メモリ、CPU を最大限に活用するための超大容量のファット コンテナーを提供できます。
• 2 つ目は、トレーニング データが高度に重複していることです。分散トレーニング中、すべてのノードが同じデータを読み取る場合があります。 CSI を使用すると、同じ GPU マシン上で複数の fuse プロセスが開始され、同じファイルの複数のコピーがキャッシュされ、ディスク領域が浪費される可能性があります。
• 3つ目は、GPUマシンの排他性であり、ヒューズプロセスリソースの解放を考慮する必要がないことです。トレーニング コンテナが終了した場合でも、解放する必要がなく、長時間実行できます。
• 最も重要な点は、DeamonSet とホスト パスを組み合わせることでマウント ポイントのリカバリを簡単に実現できることです。このように、ヒューズ プロセスが終了した後にファイルの読み取りに失敗しても、ユーザーが再試行を設定している限り、再度プルアップすることができます。

次に、fuse と組み合わせて Alluxio クラスター全体をデプロイする方法を見てみましょう。私たちは小規模なクラスターと大量のクライアントのアプローチを採用しています。名前が示すように、Alluxio クラスターは実際には非常に小さいです。 Raft プロトコルをサポートするマスター ノードは 3 つとワーカー ノードは 3 つしかありませんが、数 PB の NVME ストレージを含む、数百台の GPU マシン (ここでは約 100 ～ 300 台の GPU マシン) をサポートしています。 GPU マシンには数百の fuse プロセスが展開されています。各ヒューズ プロセスには、ローカル キャッシュ用に 10 TB の NVME があります。つまり、Alluxio クラスターは実際にはデータ分散という 1 つのことだけを実行します。パフォーマンス保証などのその他のことは、ヒューズプロセスに完全に引き継がれ、ローカルで完了します。

最後に、Alluxio を調整しましょう。チューニング項目は非常にシンプルです。いくつかの変更を加えただけで、残りは公式の設定です。

• 最初のステップは、ローカル キャッシュ ページのサイズを適切に増やすことです。公式のローカルキャッシュページは小さすぎるため（デフォルトは 1MB）、大きなファイルを読み取るときにパフォーマンスが非常に低下するため、16MB に変更しました。
• 2 番目は、カーネル メタデータ キャッシュを有効にすることです。これまでのテスト結果から、カーネル メタデータ キャッシュを有効にするとパフォーマンスが 2 倍になることがわかります。
• 3 番目の推奨事項は、短いカーネル メタデータ キャッシュ時間と長いメタデータ同期時間を組み合わせて、各ヒューズが基本的に同じファイル バージョンを読み取ることができるようにすることです。
• 4 番目は、ヒューズ プロセスが誤って再起動するのを防ぐためにマウント ポイントの回復を実装することです。コンテナ内に fuse をデプロイし、コンテナ内にストレージを実装すると、多くの奇妙な問題が発生することがわかりました。自動回復の手段があれば、安定性が大幅に向上します。

（３）モデルトレーニングの加速効果

実際の加速効果から判断すると、モデルトレーニングの全体的な速度が 60% 向上しました。当初はトレーニングに 10 日間必要だったモデルが、わずか 6 日間で完了できるようになりました。さらに、モデルをトレーニングする際のデータの読み取り速度も2.5倍に向上しました。

3. 補足シーン

私たちの内部には、さらに興味深いシナリオもあります。それは、ビッグデータの運用と保守のシナリオであり、これも私たちの補足シナリオです。

（１）ビッグデータコンポーネントのリリースと起動（最適化前）

まず、ビッグデータ コンポーネントのリリースと起動のプロセスを紹介します。たとえば、ビッグデータ コンポーネントを起動する場合、ユーザー開発者はまず自分のタスクを GitLab に送信します。マージコードリクエストを受信すると、GitLab は CI Web Hook を呼び出してユーザーを自動的にビルドおよびパッケージ化し、バイナリパッケージを Kosmos にアップロードします。ここでの Kosmos は、当社の内部パッケージ管理サービスです。バイナリ パッケージを受け取った後、Kosmos はそれをオブジェクト ストレージに転送します。これが公開プロセスです。

オンラインプロセスを見てみましょう。開発者はビッグデータ運用保守プラットフォームをクリックして新しいバージョンを起動し、ビッグデータ運用保守プラットフォームはデプロイメントロジックを本番環境サーバーに配布します。実稼働環境サーバーはデプロイメント ロジックを実行します。途中でパッケージをダウンロードする必要がある場合は、Kosmos にダウンロードを要求します。ダウンロード要求を受信すると、Kosmos は要求をオブジェクト ストレージにリダイレクトします。このとき、本番環境サーバーはオブジェクト ストレージからバイナリ パッケージを直接取得します。プロセス全体が完璧です。唯一の欠陥は、オブジェクト ストレージがバイナリ パッケージをダウンロードするときに、次の 2 つの問題が発生することです。

• オブジェクト ストレージのダウンロード速度が遅く、バッチ展開に時間がかかります。シングルスレッド オブジェクト ストレージのダウンロード速度は 10 ～ 30 MB しかないため、DataNode をバッチでデプロイするときに非常に長い時間がかかります。 10,000 個の DataNode を例にとると、2 つの DataNode をローリング方式で再起動すると、それぞれのダウンロードに約 30 秒かかり、全体の展開時間は 48 時間以上になります。
• これをコンピュータ ルーム全体で使用すると、簡単にエクストラネット トラフィックが生成される可能性があります。これは、オブジェクト ストレージを 1 つだけ使用するためです。技術コンポーネントが同じコンピュータ ルームではなく別の場所に展開されている場合、外部ネットワーク トラフィックが生成され、コストがかなりかかります。

（２）ビッグデータコンポーネントのリリースと立ち上げ（最適化後）

このプロセスを最適化するために Alluxio を使用しましたが、プロセスは非常に簡単でした。 Alluxio は HDFS のマウントだけでなく、オブジェクト ストレージのマウントもサポートしているため、Kosmos で使用されるオブジェクト ストレージを Alluxio に直接マウントします。パッケージをダウンロードする場合、本番環境サーバーは S3 プロキシからバイナリ パッケージを直接要求します。 Alluxio からダウンロードされるため、下図に示すように、速度が非常に速くなります。最終打ち上げ後の効果を比較したグラフです。

図中の赤い円はオブジェクトストレージからのダウンロード速度を示しており、約 10 MB/S です。 Alluxio からのダウンロード速度は約 600 MB/S です。ここでの 600 MB/S は抑制中の状況です。前述の最適化ソリューション、つまり S3 プロキシが速度を制限することを考慮すると、速度は 600 MB/S に制限されますが、実際には最大 1600 MB/S に達する可能性があります。

IV.結論

最後に技術的な概要を示します。当社のマルチクラウド キャッシュの開発履歴を振り返ると、当初の総当たりによる読み取りから、その後の複数の HDFS クラスター、そして自社開発のコンポーネント UnionStore まで、どれも当社のニーズを満たすことができませんでした。最終的に、私たちはニーズを満たすために Alluxio を立ち上げました。

Alluxio はどのような改善をもたらしましたか?まず、パフォーマンスの面では、全体的に 2 ～ 5 倍のパフォーマンス向上が見られます。安定性の面では、HDFS への強い依存が排除されます。最後に、コストの面では、コストが約半分に削減されました。

将来的には、データ オーケストレーションや OLAP アクセラレーションのシナリオで Alluxio を使用する予定です。当社の人工知能シナリオの一部では小さなファイルの使用が必要なため、新世代アーキテクチャである Dora アーキテクチャに期待しています。

5. 議論と交流

1. Hive は Alluxio を使用して、ユーザーが作成した過去の Hive テーブルへの変更を最小限に抑えるにはどうすればよいでしょうか?

A: これは、Hive テーブルの場所を HDFS の先頭から Alluxio の先頭に変更したくないためだと思います。 OLAP エンジンはまだ高速化されていませんが、現在は代替ソリューションがあります。 Hive の MetaStore にいくつかの変更を加える可能性があります。コンピューティング エンジンが HDFS 上のパーティションを読み取るときに、それが Alluxio にキャッシュされている場合は、Hive MetaStore で直接変更し、HDFS プレフィックスを Alluxio プレフィックスに直接変更します。この方法では、Hive の場所を変更する必要はありません。

2. 先ほど述べたページ サイズが 1MB から 16MB に調整されました。これはどのように調整されましたか?なぜ32MBではないのですか?

回答: ビジネスでデータを読み取る場合、大きなファイルだけでなく小さなファイルも含まれます。この値が大きすぎると、小さなファイルが適切にサポートされなくなります。小さすぎると、大きなファイルをうまくサポートできません。そこで、実験経験に基づいて、比較的妥協した値を選択しました。

3. Alluxio のパフォーマンスはコールド リード中に大幅に低下しますが、この問題は予熱によって解決されます。どうやって予熱するんですか？

A: たとえば、S3 プロキシから 512 MB のファイルを要求するユーザーがいるとします。次に、S3 プロキシはマスターからファイルのメタデータを取得し、各ブロックのサイズが 128 MB の 4 つのブロックがあることを示します。これら 4 つのブロックについては、ハッシュなどの特別なアルゴリズムを使用し、それらを異なるワーカーに送信してキャッシュします。読み取り時に、S3 プロキシは最初にダウンロードする場合があります。たとえば、ブロック 1 をダウンロードしますが、ブロック 1 はまだキャッシュされていない可能性があるため、UFS から直接読み取られてからユーザーに返されます。これにより、速度が遅くなる可能性があります。ブロック 2 を読み取るときに、キャッシュされている可能性があり、その場合、読み取りは非常に高速になります。その後、ブロック 3 と 4 を読み取るときに、それらがキャッシュされ、非常に速く読み取られる可能性があります。これが私たちのやり方です。ここでは、ファイルのブロック数が 1 より大きい必要があります。それ以外の場合は、ファイル自体が比較的小さいため、パフォーマンスが低くてもすぐに読み取ることができるため、高速化する必要はありません。

4. 先ほど、メタデータのキャッシュに Alluxio を使用することを説明しました。メタデータには具体的に何が含まれていますか?

回答: Alluxio のメタデータ キャッシュは 3 つの部分に分かれています。最初の部分は、マスターにキャッシュされるオブジェクト ストレージ メタデータなどの UFS メタデータです。 2 番目の部分は fuse で、これはクライアントのローカル メタデータ キャッシュです。これはかなりよくあることです。 Fuse はメモリを使用してマスターのメタデータを 1 回キャッシュします。 3 番目の部分はカーネル メタデータであり、これも fuse で共通です。これは、オペレーティング システムのローカル ディレクトリの状態をキャッシュするオペレーティング システム レベルのキャッシュです。

メタデータのキャッシュはパフォーマンスに大きな影響を与えます。メタデータのキャッシュが有効になっていない場合、たとえば、UFSメタデータをキャッシュしない場合、クライアントからのすべての要求がUFSに侵入し、パフォーマンスは非常に低くなります。特に、オブジェクトストレージを使用する場合、たとえば、ディレクトリをリストしたい場合、オブジェクトストレージリスティングディレクトリのパフォーマンスは非常に貧弱で、時には数秒かかる場合があります。

ここで1分のキャッシュタイムアウトを設定します。 1分間のメタデータキャッシュは実際には妥協点です。これは、ユーザーがファイルの変更をできるだけ早く感じると同時に、ある程度のキャッシュを実行できるようにするためです。メタデータの一貫性要件がそれほど厳格でない場合、実際に1時間、数時間、または数日に調整するか、手動で更新できます。これは、シーンに従ってのみ調整できます。

5。オブジェクトストレージは、モデルの起動とモデルトレーニングシナリオの両方で使用されます。クラウドまたはローカルオブジェクトストレージ上のオブジェクトストレージですか？すべての接続インターフェイスは、標準のS3プロトコルを使用して接続されていますか？

回答：クラウドベンダーからオブジェクトストレージサービスを直接購入します。独自のオブジェクトストレージをセットアップするのは高すぎるためです。

ここには2つのS3プロトコルが関係しています。一方では、UnionStore自体がS3プロトコルを外の世界に提供しています。このコンポーネントは私たちによって開発されています。一方、UnionStoreはS3プロトコルを使用して、クラウドベンダーから購入するオブジェクトストレージと対話します。

6.モデルトレーニングシナリオでは、GPUクラスターは最初は数百のノードで構成されていますが、Alluxioは3人のマスターと3人の労働者の小さなクラスター展開を使用しています。この小さなクラスターアーキテクチャは、ホットデータを引き出す容量と同時アクセス要件全体を満たすことができますか？

A：これは、Alluxioが現在持っている問題に関連して解決する必要があります。現在、クラスターからデータを読むと、ヒューズは非常に遅いです。これはAlluxioの欠陥です。約200MB/sの最高速度にしか到達できないため、ワーカーのネットワークカードから十分なデータを読み取ることができません。これについては、Alluxioコミュニティと何度も話し合いました。 Alluxioの次のバージョンはこの問題を解決し、楽しみにしています。また、当時のバージョンのアップグレードとアーキテクチャのアップグレードを行うこともできます。たとえば、労働者の拡大やビジネス部門と直接統合するなどです。