Ray を使用してクラウドネイティブ シナリオで分散システムを迅速に構築する方法

1. 分散システムの複雑さ

1. AutoMLの事例

例から始めましょう。上の写真は、自動分散機械学習サービスを構築するために最近構築した AutoML の例です。

図中の点線のボックスは自動機械学習サービスです。このサービスには次の役割があります: proxy は、AutoML クラスター全体でサービス エントリを提供する役割を担う常駐サービスです。さまざまな AutoML タスクに応じて、小さなボックスにトレーニング クラスターを作成します。小さなボックスには、トレーナーとワーカーの 2 つの役割があります。トレーナーはコーディネーターに似た役割で、完全な AutoML タスクを調整し、調整プロセス中に継続的にワーカーを作成して、AutoML 計算全体を完了します。

AutoML サービスはクラスター外部のクライアントを介してアクセスされ、AutoML に必要なモデルとデータの組み合わせがプロキシに送信されます。プロキシはユーザーのリクエストに基づいてトレーナーを作成します。もちろん、このプロセスでは、トレーナーの Pod またはプロセスを作成するために、K8S を通じてリソースを管理する必要があります。トレーナーは、クライアント側でモデルとデータを解析して必要なワーカーの数を計算し、K8S を通じて対応するワーカーを作成して、トレーニング タスク全体を開始します。

各ワーカーがトレーニングを完了すると、トレーナーは結果を収集し、AutoML タスク全体が完了したかどうかを確認し、最後に結果をプロキシに返します。結果を返すと、トレーナーとワーカーは破棄されます。

これは比較的完成度の高い AutoML サービスです。その特徴は、クラウド ネイティブ、マルチロール、高い弾力性、動的、ステートフル、頻繁な通信です。高い弾力性は主にプロキシとトレーナーの 2 つの役割に反映され、どちらも実行時に継続的にリソースを適用します。

2. テクノロジースタック分析

次に、このケースをクラウドネイティブ環境で実装する場合に考慮すべき点について説明します。以下の分析は2つの側面から行われます。

テクノロジースタックの観点から、現在のアプリケーションシナリオが AI であると仮定すると、主なプログラミング言語は Python です。まず、プロキシ、トレーナー、ワーカーのロールを含む単一のアプリケーションを開発する必要があります。モノリシック アプリケーションの作成では、次の点に留意します。

• スケジュールに関しては、モノリシック アプリケーション全体を構築するために、asyncio コルーチン管理プロセスのイベント ループが選択されます。
• 通信に関しては、プロキシ、トレーナー、ワーカー間で渡す必要があるフィールドなど、さまざまなコンポーネント間の通信プロトコルを定義するために protobuf を使用し、gRPC を介して通信プロセス全体を完了することを選択します。
• ストレージに関しては、アプリケーションのメモリ構造とビジネス ロジックの設計役割を考慮する必要があります。ビジネスロジックが複雑な場合は、RocksDB などのローカルストレージを導入する必要があります。より複雑な状況では、HDFS などのリモート分散ストレージを導入する必要があります。
• デプロイメントの観点では、分散システムをデプロイするためには、Docker を考慮し、各コンポーネントのランタイム環境をカスタマイズし、Kubernetes を理解し、Kubernetes 環境でこれらのアプリケーションのインスタンスを作成する方法を知る必要があります。より複雑なケースでは、途中で何らかの弾力性のあるプロセスが必要な場合は、分散システム全体の構築を支援するために K8s 標準オペレーターを開発する必要があります。
• 監視に関しては、システムが稼働した後、監視システムに接続する必要があります。一般的に、システムの監視性と保守性を実現し、本番環境の要件を満たすために、Grafana + Prometheus の組み合わせが選択されます。

3. プログラミング言語分析

プログラミング言語の観点から、上記の分散システムを実装するには、次のプログラミング言語を適用する必要があります。

• Python は必須であり、アプリケーションの内部ロジックを実装するために使用されます。
• Protobuf は、proto 言語を通じてアプリケーションの通信プロトコルを定義し、codegen を通じてさまざまな言語で SDK ライブラリを生成し、gRPC 通信アクセスを実装します。
• Docker は、Dockerfile を通じてアプリケーション内の各コンポーネントの差別化された要件を定義します。たとえば、ワーカーには GPU を実行できる Python 環境が必要になる場合や、Python 環境のバージョンと依存パッケージをカスタマイズする必要がある場合、またはライブラリやオペレーティング システムのバージョンなど、よりネイティブな環境をカスタマイズする必要がある場合があります。
• より複雑な分散システムの場合、Go ではネイティブ操作とメンテナンスの大規模な開発も必要になります。たとえば、私たちの場合、K8s オペレーターを開発する必要があり、オペレーターのビジネス ロジックは Go 言語で記述する必要があります。
• YAML、ネイティブデプロイメントでは、YAML コードが頻繁に使用されます。コンテナ仕様、ポッド仕様、その他のラベルなど、システム内の最終的なデプロイメントのパラメータは、YAML 形式でカスタマイズする必要があります。

上記は、従来の考え方で分散システムを実装する際に考慮する必要があるテクノロジースタックとプログラミング言語です。

4. 分散システムの一般的な機能

クラウドネイティブ環境全体における分散システムの構築は非常に複雑であることがわかります。しかし、分析してみると、開発および保守が必要なロジックの多くは一般的な分散システム ロジックであり、実際のビジネス ロジックとは直接関係がないことがわかります。たとえば、前述の AutoML のケースでは、ビジネス開発者やシステム開発者は AutoML 自体のロジックに重点を置きます。では、システムまたはビジネスの研究開発チームがビジネス ロジック自体に集中できるように、分散システムの一般的な機能をすべて解決できるシステムはあるのでしょうか? Ray はこの問題を解決するために作成されました。

2. レイの紹介

Ray を使用して分散システムを構築する方法について説明する前に、まず Ray について簡単に紹介しましょう。

1. レイについて

まず、GitHub 上の Ray のスター数の推移を見ると、2016 年半ばのオープンソース化から現在までに 2 つのマイルストーンを経験しています。左上の写真の赤い線は、レイの星番号の履歴データです。 2021年、レイの星の数はフリンクを超えました。 2023年5月には、カフカを超えるという新たなマイルストーンを達成しました。現時点では、Sparkの星の数とはまだ一定の距離があります。星の数から見ると、レイは非常に急速に成長しました。

右上は、Google の PATHWAYS 論文のスクリーンショットです。 PATHWAYS は実際には、Google 内で次世代 AI のインフラストラクチャとして認識されています。この論文では Ray が何度も言及されており、Ray が実際にこのインフラストラクチャにおける分散コンピューティング フレームワークになる可能性が非常に高いと考えられています。

中央右には、最近よく知られるようになった大手言語モデル企業であるOpenAIの情報があります。今年、OpenAI は GPT3.5 と GPT4 の分散トレーニングの詳細をいくつか公開しました。基盤となるレイヤーでも、Ray を使用して分散システム全体を構築します。

左下は、2022年にRayコミュニティがビッグデータ分野で行った作業です。クラウド リソースを使用してデータを並べ替え、シャッフル機能を適用します。このソートシステムは世界記録を破り、初めて 1 TB あたり 1 ドル未満のコスト (0.97 ドル) を達成しました。

右下の画像は、オフライン バッチ推論に関する Ray コミュニティによる最近の作業を示しています。 Ray を他の既存のソリューションと比較し、Ray を通じてデータを処理し、トレーニング システムにデータを提供するパイプライン プロセスを実装します。 Sparkと比較すると、スループットは2〜3倍高くなります。

上記の情報を通じて、Ray について高度な理解を得ることができます。

2. レイとは何か

Ray は、カリフォルニア大学バークレー校の RISELab 研究所が開始したオープン ソース プロジェクトです。 RISELab 研究所は業界では非常によく知られており、Spark もこの研究所から生まれました。

Ray は汎用分散コンピューティング エンジンです。その汎用性により、新世代のコンピューティング技術施設となる可能性があります。分散分野では、Ray のエコシステム全体により、AI 分野での統一されたプログラミング フレームワークになる可能性がさらに高まります。この部分については、後ほどオープンソース エコシステムのセクションでさらに詳しく説明します。

3. ユニバーサル分散プログラミングAPI

レイの多才さはどこにあるのでしょうか?実際、Ray Core の API を見ると、Ray の設計思想は、任意のコンピューティング モードをバインドするのではなく、スタンドアロン プログラミングで基本概念を配布することであることがわかります。

API の設計から、Ray はビッグデータ システムではないことがわかります。特に、Ray Core レイヤーにはビッグデータ関連の演算子はありません。代わりに、スタンドアロン プログラミングの基本概念に基づいて配布されます。

具体的にどのように配布するのでしょうか？スタンドアロン プログラミングでは、関数とクラスという 2 つのコア概念がよく使用されます。オブジェクト指向プログラミング言語では、基本的にこれら 2 つの概念を中心にコードが開発されます。 Ray では、これら 2 つの基本概念は分散されており、分散システムのタスクとアクターに対応します。

4. 一般的な分散プログラミングAPI: ステートレスコンピューティングユニットタスク

まず、タスクについて説明します。タスクはスタンドアロン プログラミングにおける分散機能であり、ステートレスなコンピューティング ユニットです。

上の写真は一例です。 CPU を集中的に使用する操作である、heavy_compute と呼ばれる関数があります。たとえば、単一のマシンで 10,000 回操作する必要がある場合、単一のコアでは、左側のコード、つまり単純な for ループが使用されます。マルチコア機能を使用する必要がある場合は、マルチスレッドまたはマルチプロセスを使用する必要があります。 Ray では、複数のマシンの機能を活用して機能を分散したい場合、全体のプロセスは非常にシンプルで、右の図に示すように 3 つのステップのみが必要です。

• まず、スタンドアロン関数にデコレータ (@ray.remote) を追加して、関数がリモートで実行できることを示します。
• 次に、関数を呼び出すときに、.remote と必要なパラメータを追加して、関数がリモート ノードのプロセスで実行されるようにスケジュールされるようにします。
• 最後に、ray.get を通じて最終的な計算結果を取得できます。

分散プロセス全体が非常に単純であり、プログラミング フレームワークとプロセス全体がスタンドアロン プログラミングの習慣を崩していないことがわかります。これは Ray のコア API 全体の中核機能でもあり、プログラマーに最大限の利便性を提供します。

5. 一般的な分散プログラミングAPI: 分散オブジェクト

Ray におけるオブジェクトの概念を見てみましょう。オブジェクトについて説明する理由は、Ray が別のノードに対して Heavy_compute 関数を実行し、結果を返すことができる理由を全員に理解してもらうためです。これは、Ray の基盤となる分散オブジェクト ストアに依存します。全体のプロセスは上の図の左側に示されています。

ノード 1 で、heavy_compute 関数を実行します。この関数は、Ray の基盤となるスケジューリング システムを介してリモートを使用してノード 2 にスケジュールされます。ノード 2 はこの関数を実行し、実行後に結果をローカル オブジェクト ストアに格納します。オブジェクト ストアは Ray のコア コンポーネントです。最終結果は、Ray の基盤となるオブジェクト ストア間のオブジェクト転送を通じて呼び出し元に返されます。

プロセス全体から、heavy_compute.remote は最終結果ではなく ObjectRef を返します。 ObjectRef は、分散型 future であり、最終結果が ray.get を通じて取得できることを除いて、スタンドアロン プログラミングの future に似ています。

Ray の分散オブジェクト ストアは、Ray の分散 API 全体の設計を完全にサポートするコア コンポーネントです。その特徴は次のとおりです。

• 複数ノード間のオブジェクト転送を実現できます。
• 同じノード内の設計は共有メモリに基づいています。これを踏まえると、分散システムのオンライン転送が単一のマシン上の 2 つのプロセス間で行われる場合、理論的にはゼロ コピーの効果を実現できます。
• Ray オブジェクト ストアには、比較的完全な自動ガベージ コレクション メカニズムがあり、分散システムの操作中に ObjectRef がシステム内で参照されなくなると、そのオブジェクトの GC がトリガーされることが保証されます。
• オブジェクト ストアにはオブジェクト スピル機能があり、メモリ内のオブジェクトを自動的にディスクにスピルできるため、分散システム全体のストレージ容量を拡張するという目的を達成できます。

6. 一般的な分散プログラミングAPI: ステートフルコンピューティングユニットアクター

タスクとオブジェクトについては上記で説明しました。次にActorを紹介します。アクターも非常にシンプルで、スタンドアロン プログラミングのクラス概念の分散実装です。

左の図は、ステートフル コンピューティング ユニットである Counter クラスを示しています。右図のように分布しています。

• まず、デコレータを追加して、リモートでデプロイできるアクターに変換します。
• .remote を通じて、アクターがスケジュールおよびデプロイされ、クラスが別のマシンの別のノードでインスタンス化されます。
• 呼び出し方はTaskと同じです。この Actor のメソッドを直接呼び出し、.remote を通じてリモート呼び出しを実装できます。

3. Rayを使用して分散システムを迅速に構築する

上記では、Ray のいくつかの中心となる概念を紹介しています。次に、先ほど述べたケースを見て、Ray を使用してこの分散システムを構築する方法を見てみましょう。

1. AutoML サービス - Ray クラスターのデプロイ

Ray は、2 つの方法でデプロイできるクラスター化されたサービスです。

• 1 つ目は、ワンクリック クラウド展開です。 ray up コマンドを使用していくつかの構成を入力すると、主要なクラウドベンダーや標準の Kubernetes 環境、Hadoop Yarn 環境にワンクリックでデプロイできます。展開が完了すると、クラウド リソースを自動的かつ柔軟にスケジュールし、コンピューティング ランタイムに基づいて自動スケーリングを実行できるため、クラウド リソースを最大限に活用して分散システム全体のコンピューティングを完了できます。
• 2つ目はカスタム展開です。非標準環境の場合は、カスタム展開が必要です。 ray start コマンドを使用して、ヘッドノードとワーカーノードをそれぞれ起動し、手動ネットワークを完了できます。

2. AutoMLサービス

Ray クラスターができたので、前の AutoML アーキテクチャ図に戻りましょう。ここでRayシステムが追加されました。 Kubernetes+Ray を使用してこの分散システムをどのように実装するのでしょうか?

ユーザーの観点から見ると、K8s リソースは実際には見えなくなります。先ほどの紹介で、Ray の Actor と Task を使用して、システム全体でどれがステートフル コンピューティング ユニットでどれがステートレス コンピューティング ユニットであるかを分析し、それらを分散するという実装のアイデアは、誰でも簡単に思いつくと思います。

• プロキシとトレーナーは、Ray Actors を使用して実装する必要がある 2 つのステートフル コンピューティング ユニットです。
• 作業者はタスクを完了すると終了するため、ステータスはありません。 Ray's Task を使用して実装されます。
• クライアントは Ray クラスターの外部にあるため、Ray のクライアント ツールを使用して Ray クラスター サービス全体にアクセスできます。

以下は、上記のアーキテクチャ図で、サービス システム全体が右から左にどのように実装されるかを簡単に説明したものです。

3. AutoML サービス - ワーカー (Ray タスク)

ワーカーはタスクなので、関数をカプセル化する必要があります。関数 train_and_evaluate の主なロジックは、モデル、トレーニング データ セット、テスト データ セットを取得して、単一のマシンのトレーニングと評価を完了することです。上記は単一のマシンの計算に抽象化されています。次に、ray.remote を使用してそれをタスクに変換します。

4. AutoML サービス - トレーナー (Ray Actor)

トレーナーは、複数のワーカーをスケジュールし、異なるワーカーに異なるタスクを割り当て、結果を収集して、単一の AutoML リクエストの計算プロセスを完了する必要があります。

まず、Trainer ビジネス ロジック全体をカプセル化する Trainer クラスがあります。次に、ray.remote を使用して Actor に変換します。 Trainer の train メソッドは、2 層のループを通じて複数のワーカーのスケジュールを実装します。実際には、上で実装したワーカーの train_and_evaluate 関数のリモート実行です。このようにして、分散システムで並行コンピューティングを実現できます。同時計算が完了すると、Trainer は結果を収集し、プロキシに返します。

5. AutoML サービス - プロキシ (Ray Actor)

プロキシは外部サービスのエントリ ポイントであり、次の 2 つの機能を定義します。

• 1つはdo_auto_mlです。ユーザー リクエストがこの関数にディスパッチされると、Trainer Actor のデプロイがトリガーされ、Actor の train メソッドが呼び出されて AutoML 計算全体がトリガーされます。
• もう 1 つは get_result で、Ray クライアントが計算結果を照会できるようにします。

ここで注目すべき点は、プロキシを展開するときに、サービス検出の名前を設定する必要があることです。

6. AutoML サービス - クライアント

Ray Client でアクセスすると、クライアントを取得した AutoML ユーザーは、まず ray.get_actor を介して上記のアクター名を渡すことでプロキシ ハンドルを取得し、次にプロキシ ハンドルを介してプロキシ メソッドを呼び出して AutoML アクセスを実現し、最後にプロキシの get_result を呼び出して最終的な計算結果を取得できます。

7. AutoML サービス - カスタマイズされたリソース

次に、詳細をいくつか説明します。

最初の詳細はリソースのカスタマイズです。

純粋なクラウドネイティブ実装では、Ray がない場合、リソースのカスタマイズは YAML に書き込まれます。たとえば、トレーニングに必要な GPU の数や、コンピューティング ノードに必要な CPU の数など、これらはすべて YAML コンテナ仕様でカスタマイズされます。

Ray は、完全に気付かないコード化された構成という別のオプションを提供します。ユーザーは、実行時または Ray のタスクやアクターのデコレータでパラメータを追加し、Ray システムのスケジューリング機能を使用して対応するリソースを割り当てることができるため、分散システム全体のリソースをカスタマイズするという目的を達成できます。

GPU、CPU、メモリのサポートに加えて、Ray のリソース カスタマイズではカスタム リソースを挿入することもできます。 Ray のスケジューリングには、リソース グループやアフィニティ スケジューリング、アンチアフィニティ スケジューリングなどの高度な機能もいくつかあり、現在サポートされています。

8. AutoML サービス — ランタイム環境

2 番目の詳細はランタイム環境です。

分散システムでは、分散システムのさまざまなコンポーネントが環境に対して異なる要件を持つことがよくあります。従来の考え方だと、環境をイメージに固めて、Dockerfile を通じて環境をカスタマイズする必要がありました。

Ray は、より柔軟なオプションを実装します。このオプションもコード化されており、実行時にタスクまたはアクターを作成する前に、指定されたコンピューティング ユニットのランタイム環境をいつでもカスタマイズできます。上図では、ワーカーのタスクにruntime_envを設定し、専用のPythonバージョンをカスタマイズし、そのバージョンにいくつかのpipパッケージをインストールすることで、Python向けの分離環境のカスタマイズが完了します。このとき、Ray クラスターはタスクを作成する前に環境を準備し、その環境でタスクが実行されるようにスケジュールします。

Ray のランタイム環境はプラグインベースで設計されています。ユーザーはニーズに応じてさまざまなプラグインを実装できます。 Ray は、Pip、Conda、Container などのいくつかのプラグインをネイティブにサポートしています。環境に関連している限り、コード依存関係だけでなく、プラグインを通じて実装できるデータ依存関係も可​​能です。

実行環境の観点から見ると、右下の図は、Python を例にとると、分離のサポートには次の次元があることを示しています。1 つ目はプロセス レベルの分離、2 つ目は仮想環境レベルの分離、3 つ目は Conda レベルの分離、最後はコンテナー レベルの分離です。

孤立という点では、右から左へ、弱いものから強いものへです。プロセスの分離は非常に弱く、コンテナの分離はより強力です。

ユーザー エクスペリエンスの観点から見ると、環境のカスタマイズに関しては、コンテナーの方が重く、プロセスの方が軽量です。

そのため、Ray では、ユーザーは自分の環境カスタマイズのニーズに応じて、カスタマイズする環境の粒度を選択できます。完全なコンテナ レベルの分離が必要な人もいれば、プロセス レベルの分離のみが必要な人もいます。ニーズに合わせてお選びいただけます。

9. AutoML サービス - 運用と監視

3 番目の詳細は、操作、保守、監視です。

Ray は Ray Dashboard を提供します。 Ray ダッシュボードは、Ray ノード、Ray アクターなど、Ray クラスター全体のさまざまなディメンション情報の公開を実現します。さらに、クラスター内にはログとイベントがあります。たとえば、Actor のメソッドが異常に実行された場合、Ray はイベントを通じてダッシュボードにスタックを収集するため、問題をすばやく特定するのに便利です。さらに、プロファイリング ツールもあります。 Ray ダッシュボードはフレーム グラフをサポートしており、ワンクリックで任意のアクターまたはタスクのプロセス ステータスまたはスタックを確認することもできます。

Ray ダッシュボードに加えて、Ray はブラック スクリーンの Ray State Client も提供しており、これを使用してクラスター全体のステータスを照会することもできます。

監視に関しては、Ray は Metrics フレームワークを統合します。ユーザーは Ray のメトリック インターフェースを直接呼び出してメトリックを書き込んだ後、Ray ダッシュボードに iframe の形式で Grafana を埋め込んで簡単な監視を行うことができます。

10. レイの建築

以下は Ray のアーキテクチャの紹介です。 Ray のアーキテクチャは多くのビッグ データ システムに似ており、マスター ノード (ヘッド ノード) とその他はワーカー ノードです。

マスターノードには GCS ロール (グローバル コントロール サービス) があります。 GCS は、Hadoop アーキテクチャの Yarn のリソース マネージャーと同様に、主にクラスター全体のリソースのスケジューリングとノード管理を担当します。

Ray のワーカー ノードは主に Raylet の役割を果たします。スタンドアロンのプロセス管理とスケジューリングに加えて、先ほど述べた分散オブジェクト ストアも Raylet プロセスに統合されている重要な機能です。

11. まとめ

上の写真は私たちが行った実験です。 Ray+ のクラウドネイティブ実装に加えて、同じロジックをクラウドネイティブな方法で実装するための一連のコードも作成しました。コードは上記画像の下の GitHub リポジトリに配置されています。ご興味があればぜひご覧ください。

実験評価結果は次のとおりです。

• 研究開発効率の面では、Ray+クラウドネイティブ開発と比較して、純粋なクラウドネイティブ開発に必要な時間が 15 人日から 2 人日に短縮されました。
• コードの観点から見ると、クラウドネイティブ アプローチでは 5 つのプログラミング言語でコードを記述する必要があり、ビジネスの複雑さが増すにつれて、コードの量はますます大きくなります。このケースは Ray を通じて 260 行の純粋な Python コードで実装されました。これは、Ray を使用して分散システムを開発すると非常に高速かつ効率的であることを証明しています。
• システム特性の観点から見ると、Ray は単一の言語で実装でき、主な機能は 1 つだけです。プログラミング全体は、アプリケーション中心のプログラミングの考え方に相当します。分散システム全体には 1 つの入り口しかなく、他の役割は Ray アクターとタスクを通じて実装されます。アプリケーション、運用と保守の展開、および構成が統合されています。クラウド ネイティブ アプローチでは、複数言語の実装、複数のプログラミング エントリ、アプリケーション、運用と保守の展開、および構成の分離が必要です。

4. Rayオープンソースエコシステム

最後に、Ray のオープンソースステータスを紹介します。

1. 活動

Ray の活動状況を見ると、2016 年にオープンソース化されて以来、着実に成長を続けていることがわかります。現在、コミュニティには 800 人以上の貢献者がおり、スターの数は 26,000 を超えています。

2. レイ中国コミュニティ

レイは中国に中国人コミュニティを持っており、これは長い間 Ant によって維持されています。

• 中国コミュニティの公式アカウントには、上の写真のQRコードをスキャンするとアクセスできます。公式アカウントでは、中国コミュニティの学生が書いた基本的な記事やアクティビティが頻繁に公開されます。
• 中国コミュニティのフォーラムには、いくつかの質問と回答、および技術的な共有があります。
• 中国コミュニティのコミュニケーション グループにより、Ray システム上のアプリケーションについて誰もが簡単にコミュニケーションできるようになります。

3. レイフォワード2023

中国ではレイフォワードが5回開催されており、アントは2023年7月2日に最新のレイフォワードを開催したばかりです。5回のレイフォワードからトレンドが感じられます。最初の 2 年間は、講演のほとんどを Ant とカリフォルニア大学バークレー校の RISELab 研究所の担当者が行いました。過去2年間で、ますます多くの国内企業がレイフォワードを訪れ、自社のトピックを共有してきました。今年はトピックが最も多くあります。

4. レイ 2.0 - レイ AIR

私が今言ったことは、Ray のコンセプトとケース全体の観点から見ると、実際には Ray の基盤となる Core の中核機能です。

Ray エコシステムは AI の分野で多大な努力を費やしてきました。上の写真は、Ray AIR (Ray AI Runtime) と呼ばれる Ray 2.0 の中核概念です。 Ray AIR の設計コンセプトは、データ処理、トレーニング、チューニング、サーブなど、AI パイプラインの各処理フローにさまざまな主流ツールを統合することです。

Ray を使用して AI パイプラインを構築する場合、データ処理に Spark を選択することも、Mars や Dask などの Python 科学計算ツールを選択したり、Ray のネイティブ Ray データセットを選択したりすることもできます。トレーニングに関しては、ビジネスニーズに応じて PyTorch や TensorFlow などのトレーニング フレームワークを選択できます。

Ray AIR は、拡張可能で統合された機械学習ツールセットとして位置付けられており、最終的にはユーザーが 1 つのスクリプトだけで AI パイプライン全体を構築するのに役立ちます。これは融合コンピューティングのアイデアです。

Ray が導入される前は、パイプライン全体に複数のシステムが直列に接続されていました。 Ray の後には、オーケストレーションとスケジューリングを完了するための統合ランタイムが最下層にあります。

5. エコシステム

上の写真は古い写真で、主に Ray のエコシステムを示すために使用されました。主に 2 つのライブラリに分かれており、1 つは Ray のネイティブ ライブラリ、もう 1 つはサードパーティ ライブラリです。

• ネイティブ ライブラリには、Ray の強化学習ライブラリ RLlib と、広く使用されている Ray Serve が含まれます。
• サードパーティ ライブラリには、AI 処理フローでよく使用される前述のエンジンが含まれます。

6. エンタープライズアプリケーション

Ray のエンタープライズ アプリケーションは非常に広範囲にわたります。

先ほど述べた大規模言語モデルのシナリオにおける OpenAI に加えて、上の図には、長年 Ray を統合してきた企業がいくつかリストされています。全体的に見ると、海外での開発が多く、中国での開発は比較的少ないです。いくつかの伝統的な企業を含む多くの大手外国企業が、基盤となる分散システムの構築に Ray を使用しています。

7. 大規模モデルのトレーニング

上の図は、大規模モデルのトレーニング用に Ray を統合したいくつかのオープンソース フレームワークをまとめたものです。

• 最初のプロジェクトは、大規模モデルの並列トレーニングと提供のために Google とカリフォルニア大学バークレー校が共同で開発したフレームワーク「Alpa」です。このフレームワークは、GPU 管理とランタイム オーケストレーションに Ray Core を使用します。
• 2 番目のプロジェクトは Colossal-AI で、これも人気のある分散トレーニング フレームワークです。このフレームワークは、Ray Core の機能を、人間のフィードバックに基づく強化学習である RLHF プロセスに統合します。
• 3 番目のプロジェクトは trlX です。現在、Ray 機能も統合されており、Ray Train と Ray Tune が RLHF プロセスに統合されています。

8. 大規模モデルのトレーニング - Alpa on Ray

上の写真は、Alpa の詳細なアーキテクチャを示しています。レイは主に中間層にいることがわかります。 Alpha プロジェクトでは、レイヤー間およびレイヤー内の並列化を自動的に実現できます。全体的なイノベーションの観点から見ると、これは最先端の分散トレーニング フレームワークです。

9. 他のオープンソースプロジェクトとの統合

上の図は、AI に加えて Ray の機能を統合したオープンソース フレームワークを示しています。

• 最初のプロジェクトは GeaFlow (TuGraph とも呼ばれます) です。 TuGraph のフロー グラフ コンピューティング エンジンは、動的なリソース スケジューリングのために最下層に Ray Core を統合します。
• 2 番目のプロジェクトは、Ant が開発したオープンソースのプライバシー コンピューティング フレームワークである Incognito です。 Incognito は Ray Core の機能を大いに活用しており、現在は Ray プロジェクトの別のプロジェクトである Ray Fed も使用しています。 Ray Fed は、プライバシー コンピューティングの分野において、複数のパーティの異なるクラスター間でのデータ転送とスケジューリングを完了できます。
• 3 番目のプロジェクトは、Alibaba が開発したオープンソースの科学計算フレームワークである Mars です。分散型パンダと分散型 scikit-learn の機能を実現できます。このプロジェクトは、Ray Core の機能を統合するだけでなく、Ray Object Store の機能も深く統合し、パフォーマンスの面で優れた結果を達成しています。

5. 質疑応答

A1: Ray の現在の使用シナリオは何ですか?リアルタイム ストリーム コンピューティング シナリオをサポートしていますか?

Q: Ray の使用シナリオは実はかなり多岐にわたります。特に、Ant は、先ほど述べたフロー グラフ コンピューティング フレームワークである GeaFlow など、Ray をベースにした多くのフレームワークを構築しており、これは比較的大きな方向性です。さらに、先ほど述べたプライバシー コンピューティングも別の方向性です。これに加えて、Ant は社内に同様の機能を持つコンピューティング システムも持っており、これも Ray をベースに構築できます。 Ray API から、Ray が関数計算に非常に便利であることがわかります。さらに、科学計算やオンライン機械学習もあります。最近では、Ray をベースに検索およびプッシュ エンジンを構築できるかどうかも検討しています。

AI に関して言えば、Ant 内で最も一般的に使用されている AI オンライン サービスは、1 つ以上のモデルまたは大規模なモデルを適用して推論サービスを提供する方法です。フェイルオーバーを含む外部リソースのオーケストレーションとスケジューリングの全プロセスで、Ray Serve を使用してオンライン サービスをサポートできます。 Ray は、AI データ処理、トレーニング、Ray Tune、最近の大規模モデル シーンなど、AI で広く使用されています。これらすべてにおいて、基盤となる分散シャーシを完成させるために Ray が使用されています。

A2: Ray はストレージとコンピューティングの分離をサポートしていますか?ノード 2 は計算を完了し、結果をローカル オブジェクト ストアに保存して、他のノードが結果を取得するのを待機します。すべての結果が得られるまで待ってからリリースする必要がありますか?

Q: はい。 Ray のネイティブ オブジェクト ストアに基づく場合、結果をノード 2 に配置する必要があります。配置後、ノード 2 が異常終了すると、データが失われる可能性があります。もちろん、ユーザーは Ray のネイティブ系統機能または独自のフェイルオーバー機能を通じて回復できます。データが失われないようにする必要がある場合は、高可用性を実現し、オブジェクト ストアを拡張する必要があります。現在、Ray オブジェクト ストアはコンピューティング エンジンの中間結果を格納するために使用されており、永続的に格納する必要はありません。

A3：レイはほとんどのシナリオでSparkを直接置き換えることができますか、それとも互いに対立していない2つはできますか？

Q：それらの間に対立はないと思います。 Rayの設計コンセプトから、ビッグデータシステムに対してベンチマークされていません。先ほど述べたように、Ray Ecosystem全体で、ユーザーはRayでSparkを実行することもできます。また、Ray On Sparkで作業するプロジェクトもあります。 Sparkには、データ処理の分野にコア機能があります。トレーニング前にシンプルなデータの前処理を行い、複雑なオペレーターを巻き込む必要がない場合は、Rayを直接使用できます。ただし、コンピューティングシナリオがより複雑で、ビッグデータ処理の傾向があり、より複雑なシャッフルロジックまたはより複雑な演算子を使用する場合でも、Sparkを処理してからRay Ecosystemに接続することができます。ユーザーは、独自のコンピューティングシナリオに基づいてテクノロジーを選択できます。

A4：両方とも俳優モデルと同様に、RayとAkkaの分散コンピューティングフレームワークを比較できますか？

Q：AkkaのAPIがどのように見えるかについて、私はそれほど深い印象を持っていません。 RayのAPIとはまったく異なるはずだと理解しています。レイは、主にプログラミングの観点に基づいており、タスクとアクターがあります。レイの俳優モデルの概念は、伝統的な俳優モデルとはわずかに異なります。レイの俳優はより分配されており、現在、単一のマシン上のスレッド間の相互作用をサポートしていません。

A5：レイはどのように障害を容認しますか？

Q：フォールトトレランスには2つの次元があると考えています。

最初の次元は、レイがタスクであろうと俳優であろうと、プロセスを提供するため、粗い粒度のプロセスレベルの断層トレランスです。タスク/俳優のフェールオーバーは、最初にタスク/アクターが配置されているプロセスを検出し、異常に終了したかどうかを特定します。これは分散システムの基本的な機能であり、RayのRayによって完全に実装されています。 2つ目は、プロセスディメンションのフェールオーバーです。タスク、特に俳優が異常に終了すると、レイは新しいインスタンスのために異常に排出されたエンティティを再スケジュールする責任があります。言い換えれば、粗粒の回復はレイによって完全に処理できます。

2番目の次元は、主にプロセスの状態に関するものです。 Rayは、実際には内部コンピューティングロジックを指定していません。バッチコンピューティング、AIトレーニング、または任意の機能を実行できます。レイは内部コードが何をしているのかわかりません。したがって、州の回復に関しては、現在のRayの主流の使用は、州の回復をユーザーのビジネスコードに任せることです。もちろん、ユーザーはRayインターフェイスを使用して、システムが再起動されたかどうか、何回再起動したかを知ることができます。ユーザーは、以前のステータスのチェックポイントを作成する必要があります。これらのステータスは、ストレージまたはRayの下部にあるオブジェクトストアに保存できます。

ユーザーは、さまざまなフェイルオーバー信頼性要件に基づいて特定の計画を立てることができます。しかし、一般的に、一般的な使用法は、粗粒のフェールオーバーがRayによって管理されており、Ray自体のアプリケーションによって細粒状態の回復が実行されることです。