Fluid combined with JindoFS

1. Fluid とは

Fluid は、オープンソースの Kubernetes ネイティブな分散データセットオーケストレーションおよびアクセラレーションエンジンであり、主にクラウドネイティブシナリオにおけるデータ集約型アプリケーション（ビッグデータアプリケーションや AI アプリケーションなど）にサービスを提供する。Kubernetes サービスが提供するデータ層の抽象化を通じて、HDFS、OSS、Ceph などのストレージソース間でデータを柔軟かつ効率的に移動、コピー、追放、変換、管理できる。データは流体のように、上位レイヤーの Kubernetes で動作するクラウドネイティブアプリケーションとストレージ間を自由に流れる。具体的なデータ操作はユーザーに対して透過的である。ユーザーは、リモートデータへのアクセス効率、データソース管理の利便性、Kubernetes の運用およびスケジューリング判断について気にする必要がなくなる。ユーザーは、抽象化されたデータに Kubernetes ネイティブのデータボリュームとして直接アクセスするだけでよく、残りのタスクと低レイヤーの詳細はすべて Fluid が処理する。Fluid プロジェクトは現在、データセットオーケストレーションとアプリケーションオーケストレーションという 2 つの重要なシナリオに焦点を当てている。データセットオーケストレーションでは、指定したデータセットのデータを特定の特性を持つ Kubernetes ノードにキャッシュできる。一方、アプリケーションオーケストレーションでは、指定したアプリケーションを、指定したデータセットが既に保存されているノード、または保存可能なノードにスケジュールする。この 2 つを組み合わせることで、データセットとアプリケーションの両方の要件を考慮してノードリソースをスケジュールする協調オーケストレーションシナリオを形成できる。

次に、Fluid における Dataset の概念を紹介する。Dataset とは、ビッグデータの Spark や AI シナリオの TensorFlow など、コンピューティングエンジンが利用できる論理的に関連付けられたデータの集合である。データセットのインテリジェントな活用とスケジューリングは、業界において中核的な価値を創造する。データセット管理には、セキュリティ、バージョン管理、データアクセラレーションなど、多次元の側面がある。

データアクセラレーションを基盤としたデータセット管理のサポートを提供することが目標である。データセットの上に、Runtime のような実行エンジンを定義し、データセットのセキュリティ、バージョン管理、データアクセラレーションの機能を実現する。Runtime は一連のライフサイクルインターフェイスを定義しており、これらを実装することでデータセットの管理とアクセラレーションをサポートできる。現在、Fluid では AlluxioRuntime と JindoRuntime の 2 種類の Runtime がサポートされている。Fluid の目標は、AI およびビッグデータ向けクラウドネイティブアプリケーションに効率的で便利なデータ抽象化レイヤーを提供し、ストレージからデータを抽象化して以下の機能を実現することである：

1. データアフィニティスケジューリングと分散キャッシュエンジンによるアクセラレーションを通じて、データとコンピューティングの統合を実現し、コンピューティングからデータへのアクセスを高速化する。

2. データはストレージから独立して管理され、Kubernetes 名前空間を通じてリソースを分離することで、データのセキュリティ隔離を実現する。

3. 異なるストレージからのデータを組み合わせて操作することで、ストレージ間の差異によるデータサイロの影響を解消する機会を提供する。

2. JindoRuntime とは

Fluid の JindoRuntime を理解するために、まず JindoFS から紹介する。JindoFS は JindoRuntime のエンジンレイヤーである。

JindoFS は、Alibaba Cloud が OSS 向けに独自開発したビッグデータストレージ最適化エンジンである。Hadoop ファイルシステムインターフェイスと完全に互換性があり、より柔軟で効率的なコンピューティングストレージソリューションを提供する。現在、Alibaba Cloud EMR のすべてのコンピューティングサービスとエンジン（Spark、Flink、Hive、MapReduce、Presto、Impala など）での動作が検証済みである。JindoFS には、ブロックストレージモードとキャッシュモードの 2 つの使用方法がある。ブロックストレージモードでは、ファイル内容をデータブロック形式で OSS に保存し、ローカルではデータバックアップを使用してキャッシュを高速化できる。ローカル名前空間サービスがメタデータを管理し、ローカルメタデータとブロックデータを通じてファイルデータを構築する。キャッシュモードはファイルを OSS に保存する。このモードは既存の OSS ファイルシステムと互換性があり、ユーザーは OSS を通じて元のディレクトリ構造とファイルにアクセスできる。同時に、このモードはデータとメタデータのキャッシュを提供し、ユーザーのデータ読み書きパフォーマンスを加速する。このモードを使用するユーザーはデータを OSS に移行する必要がなく、既存の OSS 上のデータとシームレスに連携できる。メタデータ同期については、さまざまなニーズに応じて異なる同期戦略を選択できる。

Fluid においても、JindoRuntime は JindoFS のキャッシュモードを使用してリモートファイルにアクセスし、キャッシュする。他の環境で JindoFS を単独使用して OSS にアクセスする場合は、JindoFS SDK をダウンロードし、使用ドキュメントに従ってデプロイできる。JindoRuntime は、Alibaba Cloud EMR チームが開発した JindoFS 分散システムから派生したものであり、データセットのデータ管理とキャッシュをサポートする実行エンジンの実装である。Fluid は JindoRuntime を管理およびスケジュールして、データセットの可視化、弾力的スケーリング、データ移行、コンピューティングアクセラレーションなどを実現する。Fluid での JindoRuntime の使用およびデプロイプロセスはシンプルで、ネイティブな Kubernetes 環境と互換性があり、すぐに使い始めることができる。オブジェクトストレージの機能と深く連携し、ネイティブフレームワークを使用してパフォーマンスを最適化し、パスワードフリーやチェックサム検証などのクラウドベースのデータセキュリティ機能をサポートしている。

3. JindoRuntime の利点

JindoRuntime は、Alibaba Cloud OSS オブジェクトストレージサービスへのアクセスおよびキャッシュ機能を提供し、FUSE の POSIX ファイルシステムインターフェイスを使用して、OSS 上の大量のファイルをローカルディスクのように簡単に利用できる。以下の特徴を備えている：

1. 優れたパフォーマンス

・OSS の読み書きにおける優れたパフォーマンス：OSS との組み合わせにより読み書き効率と安定性を向上させ、ネイティブレイヤーを通じて OSS へのアクセスインターフェイスを最適化し、コールドデータアクセスのパフォーマンスを改善する。特に小規模ファイルの読み書きに優れている。

・豊富な分散キャッシュ戦略：テラバイト級の大規模ファイルキャッシュ、メタデータキャッシュ戦略などをサポートする。大規模 AI トレーニングやデータレイクシナリオにおいて際立ったパフォーマンス上の優位性を発揮する。

2. 安全で信頼性が高い

・認証セキュリティ：Alibaba Cloud 上で STS パスワードフリーアクセスと Kubernetes ネイティブのキー暗号化をサポートする。

・データセキュリティ：チェックサム検証、クライアントデータ暗号化などのセキュリティポリシーにより、クラウド上のデータセキュリティとユーザー情報を保護する。

3. 使いやすい

・ネイティブな Kubernetes 環境をサポートし、カスタムリソース定義を使用してデータボリュームの概念と連携する。デプロイプロセスはシンプルで、すぐに使い始めることができる。

4. 軽量

・低レイヤーは C++ コードをベースにしており、全体的な構造は軽量で、各種 OSS アクセスインターフェイスのオーバーヘッドも小さい。

4. JindoRuntime のパフォーマンス

Kubernetes クラスター上で ImageNet データセットを使用し、Arena で ResNet-50 モデルをトレーニングする。JindoFS ベースの JindoRuntime のパフォーマンスは、ローカルキャッシュが有効な場合、オープンソースの ossfs を大幅に上回り、トレーニング時間が 76% 短縮される。このテストシナリオについては、以降の記事で詳しく説明する。

5. JindoRuntime を素早く使用する方法

JindoRuntime の使用プロセスはシンプルである。基本的な Kubernetes と OSS 環境が準備できていれば、約 10 分で必要な JindoRuntime 環境をデプロイできる。以下の手順に従ってデプロイする。

1. 名前空間の作成

kubectl create ns fluid-system

2. fluid-0.5.0.tgz のダウンロード

3. Helm を使用した Fluid のインストール

helm install --set runtime.jindo.enabled=true fluid fluid-0.5.0.tgz

4. Fluid の実行状態の確認

csi-nodeplugin-fluid-xx の数は、Kubernetes クラスター内のノード数と一致している必要がある。

5. データセットと JindoRuntime の作成

データセットを作成する前に、OSS の fs.oss.accessKeyId と fs.oss.accessKeySecret の情報を保存するシークレットを作成し、平文での露出を防ぐことができる。Kubernetes は作成されたシークレットに暗号化を使用し、キーとシークレットの情報を mySecret.yaml ファイルに記入する。

resource.yaml ファイルを作成する。このファイルには 2 つの部分が 含まれる：

1. まず、データセットと UFS のデータセット情報を含み、データセット CRD オブジェクトを作成する。これはデータセットのソースを記述する。

2. 次に、JindoRuntime を作成する必要がある。これは JindoFS クラスターを起動してキャッシュサービスを提供することに相当する。

1. MountPoint：oss:/// は UFS をマウントするパスを示す。このパスにエンドポイント情報を含める必要はない。

2. Fs.oss.endpoint：OSS バケットのエンドポイント情報。パブリックアドレスまたはイントラネットアドレスのいずれかを指定できる。

3. Replicas：JindoFS クラスターを作成するワーカー数を示す。

4. Mediumtype：JindoFS は HDD/SSD/MEM のいずれかをサポートする。

5. Path：ストレージパス。一時的に 1 つのディスクのみをサポートする。MEM をキャッシュとして選択した場合でも、ログおよびその他のファイルを保存するためにディスクが 1 つ必要である。

6. Quota：最大キャッシュ容量。Gi 単位。

7. High：上位ウォーターマークサイズ / Low：下位ウォーターマークサイズ。

kubectl create -f resource.yaml

データセットの確認

6. アプリケーションコンテナの作成によるアクセラレーション効果の体験

アプリケーションコンテナを作成して JindoFS のアクセラレーションサービスを利用するか、機械学習ジョブをサブミットして関連機能を体験できる。

次に、このデータセットを使用するアプリケーションコンテナ (app.yaml) を作成する。同じデータに複数回アクセスし、アクセス時間を比較して JindoRuntime のアクセラレーション効果を示す。

kubectl を使用して作成を完了する

この時点でデータセットのキャッシュを確認すると、210 MB のデータがローカルにキャッシュされていることがわかる。

ページキャッシュなどの他の要因が結果に影響しないように、前のコンテナを削除し、同じアプリケーションを作成して同じファイルへのアクセスを試みる。この時点でファイルは既に JindoFS によってキャッシュされているため、2 回目のアクセスは 1 回目よりもはるかに短い時間で済むことがわかる。

kubectl delete -f app.yaml && kubectl create -f app.yaml

ファイルコピーの観測時間は 48 ms で、全体のコピー時間は 300 倍に短縮された。

7. 環境のクリーンアップ

1. アプリとアプリケーションコンテナの削除

2. JindoRuntime の削除

kubectl delete jindoruntime hadoop

3. データセットの削除

kubectl delete dataset hadoop

以上で、簡単な例を通じて Fluid 上での JindoFS の紹介、体験、理解が完了し、最後に環境をクリーンアップした。Fluid JindoRuntime のさらなる機能については、以降の記事で詳しく紹介する予定である。