Sharing data sets across Kubernetes Namespaces

Fluid とは

クラウドネイティブアーキテクチャを通じて AI やビッグデータなどのタスクを実行すると、コンピューティングリソースの弾力性を活用できる一方で、コンピューティングとストレージの分離アーキテクチャによるデータアクセス遅延や、リモートからのデータ取得に伴う高い帯域幅オーバーヘッドという課題にも直面します。特に GPU ディープラーニングトレーニングのシナリオでは、大量のトレーニングデータを反復的にリモート読み取りするため、GPU コンピューティング効率が著しく低下します。

一方、Kubernetes は異種ストレージサービスのアクセスと管理に対して標準インターフェイス (CSI、Container Storage Interface) のみを提供しており、コンテナクラスタ内でアプリケーションがデータをどのように活用し、管理するかまでは定義していません。トレーニングタスクを実行する際、データサイエンティストにはデータセットのバージョン管理、アクセス権限制御、データセットの前処理、異種データ読み取りの高速化などの機能が必要です。しかし、Kubernetes にはこのような標準ソリューションが存在せず、これがクラウドネイティブコンテナコミュニティで不足している重要な機能の一つです。

Fluid は「計算タスクがデータを活用するプロセス」を抽象化し、エラスティックデータセット Dataset の概念を提唱して、Kubernetes 上で第一級オブジェクトとして実装しています。Fluid はエラスティックデータセット Dataset を中心に、データセット管理 (CRUD 操作)、権限制御、アクセス高速化を実現するデータオーケストレーションシステムを構築しています。

Fluid には Dataset と Runtime という 2 つのコアコンセプトがあります。

・ Dataset とはデータセットを指し、Spark、TensorFlow、PyTorch などの計算エンジンが使用する、論理的に関連するデータの集合です。
・ Runtime とは分散キャッシュを提供するシステムを指します。現在、Fluid がサポートするランタイムタイプには JuiceFS、Alluxio、JindoFS、GooseFS があります。Alluxio と JindoFS は代表的な分散キャッシングエンジンで、JuiceFS は分散キャッシュ機能を備えた分散ファイルシステムです。これらのキャッシュシステムは、Kubernetes クラスタ内のノード上のストレージリソース (メモリやディスクなど) を、リモートストレージシステムのコンピューティング側キャッシュとして活用します。

なぜ Fluid は名前空間を超えた共有をサポートする必要があるのか

初期の Fluid は、デフォルトで 1 つの Dataset が 1 つの Runtime を専有するモードをサポートしており、Dataset 専用のキャッシュクラスタによる高速化と理解できます。データセットの特性 (単一ファイルサイズ、ファイル数、クライアント数など) に応じたカスタマイズと最適化が可能で、専用キャッシュシステムにより最高のパフォーマンスと安定性を提供し、相互干渉もありません。しかし、データセットごとに個別のキャッシュシステムを配備する必要があるため、ハードウェアリソースの浪費と運用管理の複雑化を招きます。本質的にこのモードはシングルテナント型アーキテクチャであり、データアクセスのスループットとレイテンシに厳しい要件があるシナリオに適しています。

Fluid の利用が深まるにつれて、異なるニーズも生まれてきました。たとえば、複数のデータサイエンティストが異なる名前空間でデータ集約型ジョブを作成し、同じデータセットにアクセスするケースです。各名前空間ごとにキャッシュシステムを再デプロイしてキャッシュをウォームアップすると、データ冗長性の増加とジョブ起動の遅延を招きます。

この時点で、リソース節約と運用簡素化のため、名前空間を超えたデータセットアクセスの必要性が生じました。クロス名前空間要件は本質的にマルチテナント型アーキテクチャを求めています。すなわち、クラスタ管理者が Runtime をストレージのルートディレクトリに向け、複数のデータサイエンティストが異なる名前空間で複数の Dataset を作成して同じ Runtime を共有します。さらに進めて、管理者は各名前空間のデータサイエンティストにサブディレクトリと異なる読み書き権限を設定することも可能です。

すべてのアーキテクチャ選択には万能な解決策はなく、すべてトレードオフです。本記事では AlluxioRuntime を例に、Fluid を使った Runtime 共有の方法を紹介します。

使用例：

ユーザー A が Kubernetes の development 名前空間で spark データセットをウォームアップしたとします。ユーザー B も別の production 名前空間から spark データセットにアクセスする必要があります。Fluid を使えば、ユーザー B は production 名前空間からウォームアップ済みのキャッシュデータにアクセスでき、再ウォームアップは不要です。これにより、ユーザーの手間を簡素化できます。一度のウォームアップで済み、異なる名前空間のユーザーもメリットを得られます。

1. 本例の実行前に、インストールドキュメントを参照してインストールを完了してください (現在、本機能は master ブランチに存在します)。そして、Fluid の各コンポーネントが正常に動作していることを確認してください。

2. development 名前空間を作成します。

3. development 名前空間に Dataset と AlluxioRuntime を作成します。

4. データセットのステータスを確認します。

5. development 名前空間に Pod を作成し、データセットにアクセスします。

6. アプリケーションがデータセット経由でアクセスできるデータを確認し、コピーを実行します。1.4 GB のデータ (7 ファイル) のコピーに 3 分 16 秒かかったことが確認できます。

7. データロードを通じて、指定したデータセットのサブディレクトリを読み込みます。

8. データロードのステータスを確認します。

9. キャッシュ効果を確認します。データの 38.4% がキャッシュされていることが確認できます。

10. 再度 1.4 GB のデータをコピーすると、わずか 0.8 秒で完了します。アクセス速度は前の 245 倍に向上しています。

11. production 名前空間を作成します。

12. production 名前空間配下で

13. データセットを表示すると、production 名前空間配下の spark データセットが確認でき、データキャッシュが既に完了しています。

14. production 名前空間に Pod を作成します。

まとめ：

上記の例では、Fluid を使った名前空間を超えたデータセット共有の方法を示しました。今後は Serverless Kubernetes でもクロス名前空間データセットアクセスをサポートする予定で、ユーザー体験に違いはありません。
さらに、Dataset のサブディレクトリを Dataset として使用できる Sub Dataset 機能もサポート予定です。同じキャッシュを異なるデータサイエンティストに適した形で活用できるようになります。ご期待ください。