Let big data and AI embrace an important puzzle of cloud origin

コンテナ化による効率的なデプロイとアジャイルな反復、およびクラウドコンピューティングのリソースコストと弾力性における固有の優位性により、Kubernetes に代表されるクラウドネイティブオーケストレーションフレームワークは、ますます多くの AI およびビッグデータアプリケーションを惹きつけています。しかし、Cloud Native Computing Foundation (CNCF) のランドスケープには、これらのデータ集約型アプリケーションがクラウドネイティブシナリオで効率的、安全、かつ便利にデータにアクセスできるようにするネイティブコンポーネントが不足していました。


クラウドネイティブシナリオでビッグデータおよび AI アプリケーションを効率的に実行する方法は、理論的意義と応用価値の両面を備えた重要な課題です。この問題を解決するには、アプリケーションの協調オーケストレーション、スケジューリング最適化、データキャッシングなど、一連の理論的・技術的課題に取り組む必要があります。一方で、この問題の解決は、広範なクラウドサービスシナリオでのビッグデータと AI の応用を効果的に推進できます。関連する問題を体系的に解決するため、学界と産業界が密接に連携して取り組んできました。南京大学 PASALab の顧栄准研究員、Alibaba Cloud コンテナサービスの車陽シニアテクニカルエキスパート、および Alluxio プロジェクトの創設メンバーである範斌博士が、Fluid オープンソース協力プロジェクトの立ち上げを共同で推進しました。

Fluid とは

Fluid はオープンソースのクラウドネイティブインフラストラクチャプロジェクトです。コンピューティングとストレージの分離を背景に、Fluid の目標は、AI とビッグデータのクラウドネイティブアプリケーションに対して効率的かつ便利なデータ抽象化レイヤーを提供することです。データをストレージから抽象化することで、以下を実現します。

データアフィニティスケジューリングと分散キャッシュエンジンによるアクセラレーションにより、データとコンピューティングの融合を実現し、データへのアクセスを高速化します。
データはストレージから独立して管理され、Kubernetes 名前空間によるリソース分離によりデータセキュリティの分離を実現します。
異なるストレージからのデータを組み合わせてコンピューティングに利用することで、ストレージ間の差異によるデータアイランド現象を打破する機会が生まれます。

Kubernetes サービスが提供するデータ層の抽象化を通じて、データは HDFS、OSS、Ceph などのストレージソースと、Kubernetes 上層のクラウドネイティブアプリケーションとの間で、流体のように柔軟かつ効率的に移動、複製、追放、変換、管理されます。具体的なデータ操作はユーザーに対して透過的であり、ユーザーはリモートデータへのアクセス効率、データソース管理の利便性、Kubernetes の運用とスケジューリングの判断について心配する必要がなくなります。ユーザーは Kubernetes ネイティブなデータボリュームとして、抽象化されたデータに直接アクセスするだけでよく、残りのタスクと基盤の詳細はすべて Fluid が処理します。


Fluid プロジェクトは現在、データセットオーケストレーションとアプリケーションオーケストレーションという 2 つの重要なシナリオに焦点を当てています。データセットオーケストレーションは、指定データセットのデータを特定の特性を持つ Kubernetes ノードにキャッシュできます。一方、アプリケーションオーケストレーションは、アプリケーションを指定データセットを格納できるノード、または格納しているノードにスケジュールします。この 2 つを組み合わせて協調オーケストレーションシナリオを構成することもできます。つまり、データセットとアプリケーションの要件を同時に考慮したノードリソーススケジューリングを行います。

クラウドネイティブに Fluid が必要な理由

クラウドネイティブ環境と従来のビッグデータ処理フレームワークの間には、設計思想とメカニズムに根本的な違いがあります。Google の GFS、MapReduce、BigTable という 3 本の論文に深く影響を受けた Hadoop ビッグデータエコシステムは、誕生以来「データを動かすのではなくコンピューティングを動かす」という考え方を信奉し、実践してきました。そのため、Spark、Hive、MapReduce に代表されるデータ集約型コンピューティングフレームワークとそのアプリケーションは、データ転送を削減するためにデータローカリティアーキテクチャをより重視して設計されています。しかし時代の変化に伴い、リソース拡張の柔軟性と利用コストを考慮して、より新しいクラウドネイティブ環境ではコンピューティングとストレージの分離アーキテクチャが主流になっています。そのため、クラウドネイティブ環境には Fluid のようなコンポーネントが必要とされています。ビッグデータフレームワークがクラウドネイティブを受け入れることで生じるデータローカリティの不足を補うためです。

さらに、クラウドネイティブ環境では、アプリケーションは通常ステートレスなマイクロサービス方式でデプロイされ、データ処理を中心に設計されていません。一方、データ集約型フレームワークとアプリケーションは、通常データの抽象化を中心に、関連するコンピューティング操作とタスクの割り当て実行を行います。データ集約型フレームワークをクラウドネイティブ環境に統合する際には、Fluid のようなデータ抽象化中心のスケジューリングおよび割り当てフレームワークも連携する必要があります。

Kubernetes におけるアプリケーションデータのインテリジェントな感知とスケジューリング最適化の不足、および Alluxio などのデータオーケストレーションエンジンがクラウドネイティブインフラストラクチャ層を直接制御するのが難しいという制約に対し、Fluid はデータとアプリケーションの協調オーケストレーション、インテリジェントな感知、共同最適化といった一連の革新的手法を提案し、クラウドネイティブシナリオにおけるデータ集約型アプリケーションの効率的なサポートプラットフォームを形成しています。**
具体的な構成は以下の図の通りです。

デモ
クラウドでの AI モデルトレーニングの速度を Fluid で向上させる方法を紹介するビデオデモを提供しています。このデモでは、同じ ResNet50 テストコードを使用した場合、Fluid によるアクセラレーションはネイティブな ossfs 直接アクセスと比較して、1 秒あたりのトレーニング速度と総トレーニング時間の両面で明らかな優位性を示し、トレーニング時間を 69% 短縮できます。

ビデオデモ

Fluid をすぐに体験する

Fluid は Kubernetes v1.14 以上で実行する必要があり、CSI ストレージのサポートが必要です。Fluid Operator のデプロイと管理は、Kubernetes プラットフォーム上のパッケージ管理ツール Helm v3 を通じて実現されます。Fluid を実行する前に、Helm が Kubernetes クラスターに正しくインストールされていることを確認してください。ドキュメントを参照して Fluid のインストールと使用方法を確認できます。