|
表紙写真は北京国家会議センターで撮影されました。
この記事では、 HarborのOCI Artifact機能を使用して機械学習モデルファイルを保存、配布、管理する方法について説明します。また、Harborを使用してカスタムデータファイルタイプを管理する方法も学習できます。Harborプロジェクトのメンテナーは、Caiyunのエンジニアと協力して、次期Harbor 2.1リリースにArtifactサポートを追加しました。ぜひ詳細をご確認いただき、ご利用ください。
CaiCloudのオープンソースOCIベースレジストリ for ML/DL Model Bundle（ORMB）は、イメージリポジトリをベースとした機械学習モデル配信コンポーネントであり、企業がコンテナイメージのような機械学習モデルを管理するのに役立ちます。 バージョン管理機能を提供するだけでなく、OCI準拠のコンテナイメージリポジトリを活用して機械学習モデルを保存・配信します。Harbor 2.0を通じて複数のイメージリポジトリ間の同期を可能にし、より幅広いエンタープライズレベルのニーズに対応します。 著者 | Gao Ce プロジェクトアドレス: https://github.com/kleveross/ormb Dockerに代表されるコンテナ仮想化技術は、クラウドコンピューティングの主流となり、世界中の無数のソフトウェアエンジニアを魅了しています。Open Container Initiative（OCI）のおかげで、コンテナエコシステムはここ数年で急速に進化し、Docker ComposeやKata Containersといったプロジェクトが活発化し、Kubernetesはクラスタスケジューリングの分野で事実上の標準となりました。振り返ってみると、 Dockerに代表されるコンテナ仮想化技術が世界を席巻した最大の理由は、そのイメージ配布機能にあります。 アプリケーションのデプロイメントシナリオにおいて、Dockerは従来のアプリケーション配布の課題を効果的に解決しました。Docker は、「Build Once and Deploy Anywhere（一度ビルドしてどこにでもデプロイ）」機能を通じて、Java、NodeJS、Rustなどの様々な言語と様々な依存ライブラリを、OCI準拠のコンテナイメージにローカルで一括構築し、イメージリポジトリを用いて保存・配布することを可能にしました。 人工知能が徐々に従来のアプリケーションに取って代わり、企業の生産環境に実装されるにつれて、新しい機械学習やディープラーニングのシナリオに直面して、新しい配布機能が必要になるでしょうか?
従来のアプリケーションシナリオと比較すると、 機械学習のシナリオはある程度異なるため、配布機能に対する要件も異なります。 従来のアプリケーションシナリオでは、開発チームは通常、バイナリ実行可能プログラム、言語インタープリタを使用したスクリプトコード、または言語仮想マシンを使用したバイトコードを配布する必要があります。これらの反復オブジェクトはコードであり、同じバージョンのコードを複数回コンパイルした出力アーティファクトは一貫性を保ちます。 ただし、機械学習アプリケーションをデプロイする必要がある場合、通常はモデル推論サーバー(モデルサーバーとも呼ばれます) とデプロイするモデルが必要になります。 モデルサーバーは、機械学習アプリケーションにとって、Java WebアプリケーションにおけるTomcatのような存在です。機械学習モデル自体は、重みや構造といった情報の集合に過ぎず、直接サービスを提供することはできません。RESTfulまたはgRPCベースのサービスを提供するには、サーバーが必要です。このサーバーがモデルサーバーです。呼び出し元からのリクエストはまずモデルサーバーに到達し、モデルサーバーはモデルを用いて順方向計算を実行し、その結果を呼び出し元へのレスポンスとして返します。 下の図に示すように、クラウドネイティブ テクノロジを使用してモデル サービスを本番環境に展開する場合、最初は簡潔さと利便性を考慮して、モデル サーバーとモデル ファイルをイメージにパッケージ化し、イメージ配布機能を再利用してモデルを配布します。 ただし、このアプローチにはいくつかの問題があります。- まず、モデルサーバーは不変のインフラストラクチャであり、通常はインフラストラクチャチームによって保守されるか、オープンソースのモデルサーバーが使用されています。モデルサーバーは通常非常に重く、例えばNvidia Triton Inference Server 20.03のイメージは43レイヤーで、解凍後は6.3GBになります。そのため、モデルサーバーとモデルファイルをまとめてパッケージ化すると、 非常に大きな画像になりがちです。画像のP2P配信が広く実装されていない現状では、これはメンテナンスと配信を困難にしています。
- 第二に、 モデルは非常に頻繁に更新されます。このパッケージングプロセスを自動化できない場合、アルゴリズムエンジニアが常に関与する必要があり、全体的なコスト管理が困難になります。
- 最後に、ミラーはモデルのメタデータを保存できないため、このアプローチは水平方向にうまくスケールしません。モデルとバージョンの数が増えるにつれて、開発チームは複数のモデルとバージョンの管理に多大な課題に直面することになります。また、モデルのハイパーパラメータ、トレーニングメトリクス、ストレージ形式などのメタデータの不足は、この問題をさらに悪化させます。
規模が拡大するにつれて、モデルサーバー（Nvidia Triton Inference Server、ONNX Runtimeなど）を基盤となる「ランタイム」、つまり不変のインフラストラクチャとして扱い、モデルサーバーをDockerイメージとして配布できるようになります。モデルは実行時に実行されるスクリプトコードのようなもので、実行時にモデルサーバーコンテナにマウントできます。 上記のアイデアにより、モデル サーバーをモデル自体から分離できます。 インフラストラクチャ チームはモデル サーバー イメージの配布を担当し、アルゴリズム チームはモデルを配布するだけで済みます。
実際、機械学習シナリオにおけるモデルの配布は、多くのモデルリポジトリプロジェクトの重要な焦点となっています。 現在、業界で主流となっている先進的なソリューションには、モデル配布の問題を解決するための主なアプローチが2つあります。 最初のアプローチは、Caicloud Cleverの第一世代モデルリポジトリに代表されます。このリポジトリは独自のストレージを維持しています。ユーザーは、SDKまたはUIを介してモデルリポジトリにモデルをアップロードする必要があります。モデルがアップロードされると、モデルリポジトリはモデルとそのメタデータを独自に管理するストレージバックエンドに保存します。推論が必要な場合は、ユーザーはモデルリポジトリが提供するSDKまたはAPIを使用してモデルをダウンロードし、推論サービスを実行できます。 別のアプローチの例としては、ModelDBが挙げられます。この実装では、モデルリポジトリにはモデルそのものは保存されず、メタデータのみが保存されます。モデル自体は、サードパーティ製のオブジェクトストレージ（ MinIO 、 S3 など）を使用して実装されています。モデルの保存パスは、メタデータの一部としてモデルリポジトリによって管理されます。モデルをダウンロードする必要がある場合、ユーザーはサードパーティ製のオブジェクトストレージが提供するSDKまたはAPIを使用してダウンロードできます。 どちらのアプローチにも長所と短所があります。前者はモデルへのアクセス制御が優れていますが、モデルのアップロードとダウンロードに独自のSDKとAPIが必要になるため、ユーザーの学習曲線が長くなります。後者は、モデルファイルの保存に成熟したサードパーティ製ストレージを利用するため、学習曲線は低くなりますが、メタデータとモデルが分離されているため、ユーザーはモデルリポジトリをバイパスしてサードパーティ製ストレージSDKまたはAPIを介してモデルファイルを直接ダウンロードできるため、アクセス制御が非常に困難になります。 さらに、どちらの方法も、モデルのメタデータとモデルファイルの処理ロジックを処理するための独自の実装を構築する必要があります。 では、両方の実装の利点を組み合わせながら欠点を回避する設計ソリューションは存在するのでしょうか?
イメージリポジトリは、クラウドネイティブ時代において重要なインフラストラクチャであり、 コンテナイメージの標準化された配布機能を提供します。機械学習のシナリオにおいて、ユーザーがイメージリポジトリの機能を再利用してモデルを配布できるとしたらどうでしょうか。これは、データサイエンティストによる車輪の再発明を防ぐだけでなく、Docker pullやDocker pushと同様のユーザーエクスペリエンスを、ユーザーにとって最小限の学習曲線で提供することを可能にします。 このアイデアに導かれて、 ormb が誕生しました! ormb という名前は、既存のミラー リポジトリを使用してモデルとそのメタデータを配布することを目的とした、OCI ベースの ML/DL モデル バンドルのレジストリに由来しています。 次に、画像認識を例に、ORMB を使って機械学習モデルを配布する方法を紹介します。 この例では、Fashion MNISTを用いてシンプルなCNN画像認識モデルをローカルで学習し、ORMBを用いてリモートミラーリポジトリにプッシュします。次に、サーバー側でも同様にORMBを用いてモデルをプルダウンし、サードパーティのモデルサーバーを用いて公開します。最後に、RESTful APIを用いてこのサービスを呼び出し、結果を確認します。 以下はモデルトレーニングのコードです。トレーニング済みのモデルをSavedModelとして保存し、ormbの例でモデルを提供します。 次に、ローカルでトレーニングされたモデルをリモートミラーリポジトリにプッシュします。 Harbor を例にとると、Harbor ミラー リポジトリでは、このモデルのメタデータやその他の情報を確認できます。 その後、サーバーからモデルをダウンロードします。モデルのダウンロードプロセスは、ミラーリポジトリへのプッシュ方法と似ています。 次に、TFServing を使用してモデルを RESTful サービスとしてデプロイし、Fashion MNIST データセットのデータを使用して推論を実行します。 あるいは、Seldon Core を使用して、モデルサービスを Kubernetes クラスターに直接デプロイすることもできます。詳細については、ドキュメントをご覧ください。 アルゴリズム エンジニアがモデルの新しいバージョンを反復処理する場合、新しいバージョンをパッケージ化し、ormb を使用して新しいイメージをプルし、再デプロイすることができます。 ormb は、OCI 配布仕様に準拠する任意のイメージ リポジトリで使用できます。 つまり、 ormb は、パブリック クラウド上のイメージ リポジトリや Harbor などのオープンソース イメージ リポジトリ プロジェクトをサポートします。 HarborのWebhook機能を活用して、モデルサービスの継続的デプロイを実現することもできます。Harbor UIにWebhookを登録すると、Harborへのすべてのプッシュモデルリクエストイベントが、定義済みのHTTPエンドポイントに転送されます。その後、Webhook内に、新しいモデルに基づいてSeldonデプロイメントモデルサービスのバージョンを更新するなど、対応するデプロイロジックを実装することで、モデルサービスの継続的デプロイを実現できます。
つまり、ormbの設計目標は、機械学習シナリオのDockerとなり、機械学習モデルの分散化の問題を解決することです。 実装においては、ormbはOCI Artifacts、OCI Distribution Specific、Harborといった巨人たちの肩に立っています。 設計を紹介する前に、ユーザーがコンテナ イメージをダウンロードすると実際に何が起こるかを理解しましょう。 OCI 仕様に準拠するミラー リポジトリはすべて、OCI 配布仕様という同じ仕様に従います。 まず、Dockerはイメージリポジトリからイメージのマニフェストを要求します。 マニフェストはJSONファイルで、ConfigとLayersという2つの部分で定義されています。Config はJSONオブジェクトであり、LayersはJSONオブジェクトの配列です。 ご覧のとおり、ConfigとLayersの各オブジェクトは同じ構造を持ち、3つのフィールドが含まれています。 - digest: このオブジェクトの ID として理解できます。
- mediaType: このコンテンツの種類を示します。
コンテナイメージ構成には、固定の mediaType（application/vnd.oci.image.config.v1+json）が存在します。 以下に構成ファイルの構成例を示します。このファイルはコンテナイメージに関する構成情報を記録し、イメージのメタデータとして解釈できます。 通常、イメージリポジトリでは、UIに情報を表示したり、異なるオペレーティングシステム向けのビルドを区別したりするために使用されます。 コンテナイメージのレイヤーは、mediaTypeが application/vnd.oci.image.layer.v1.* （最も一般的なのは application /vnd.oci.image.layer.v1.tar+gzip）である複数のコンテンツレイヤーで構成されています。 ご存知のとおり、コンテナイメージはレイヤー構造になっており、各レイヤーはレイヤー内のオブジェクトに対応しています。 コンテナイメージのConfigとLayer内の各レイヤーは、イメージリポジトリにBlobとして保存され、そのダイジェストがキーとして使用されます。そのため、Dockerはイメージのマニフェストをリクエストした後、ダイジェストを使用して、ConfigとすべてのLayerを含むすべてのBlobを並列にダウンロードします。 ミラーリポジトリはモデルの配布をどのようにサポートする必要がありますか? 前述のように、イメージ リポジトリは、マニフェストと mediaType が application/vnd.oci.image.config.v1+json であるイメージ構成と、mediaType が application/vnd.oci.image.layer.v1.* であるレイヤーを定義することでイメージをサポートします。 クラウドネイティブ技術の拡大に伴い、コンテナイメージに加えて、Helm ChartsやCNABなど、イメージリポジトリのバージョン管理、分散、階層化ストレージ機能の再利用を目的とした様々なアーティファクトがコミュニティで登場しています。こうしたニーズに応えるために、OCI Artifactsが開発されました。 イメージリポジトリは、マニフェスト、構成、レイヤーを通じてイメージの保存と配布をサポートします。しかし、構成とレイヤーの種類と構造を定義することで、イメージリポジトリの機能を拡張し、他の種類のアーティファクトを保存および配布できるようになります。OCI Artifacts は、この目的のためのガイダンスを提供します。 イメージリポジトリは既にこの機能を備えているため、OCI Artifacts は仕様ではなく、イメージリポジトリの拡張性を活用して他の種類のアーティファクトをサポートする方法を開発者に説明するガイドです。 具体的には、モデルアーティファクトタイプのサポート設計に関して、モデル用の独自のConfig構造を定義し、mediaTypeは現在application/vnd.caicloud.model.config.v1alpha1+jsonに設定されています。設定例を以下に示します。 Layerers の場合、モデル ファイルをレイヤーに保存することが難しいため、現在の設計では、モデル ファイルを application/tar+gzip mediaType にアーカイブし、ミラー リポジトリにアップロードします。 したがって、ミラー リポジトリからモデルをダウンロードするプロセスを次の図に示します。 実装においては、Harbor チームと緊密に連携し、Harbor をデフォルトのミラー リポジトリとし、OCI Artifact サポートにおける Harbor のスケーラビリティに積極的に貢献しました。 ORMBはHarborの多くの機能を再利用できます。 例えば、Harborのレプリケーション機能を活用することで、ORMBはトレーニング環境や本番環境など、複数の環境にあるミラーリポジトリ間でモデルを同期できます。 また、モデルにWebhookを設定して、モデルのライフサイクル全体にわたってカスタム処理ロジックを追加することもできます。
Caiyunは現在、 ormb をオープンソース化しています。 このプロジェクトに基づき、Harborをベースとしたモデルリポジトリのオープンソース化を継続し、モデルフォーマット変換や自動モデル圧縮といった高度な機能を含む、より多くの機能を提供していきます。 同時に、クラウドネイティブの標準化されたアプローチを用いて機械学習シナリオにおけるモデル配布の課題を解決するために、業界からの支援も期待しています。 クラウドネイティブ機械学習インフラの構築に積極的に参加し、 より包括的なモデル構成仕様を共同で開発することで、より多くのシナリオのニーズに対応できるパートナーを切望しています。コミュニティへのオープンソース貢献に関しては、CaiCloudは常にオープンガバナンスモデルに対してオープンな姿勢を維持しており、ベンダー中立的な立場でORMBの運用と管理を積極的に推進していきます。 さらに、ORMBとそのミラーリポジトリをベースに、 2020年後半にはCaiyunクラウドベースAIプラットフォーム「Clever」のコミュニティ版をリリースする予定です。これにより、オープンソースコミュニティアプローチを通じてCleverの推論機能を維持し、ユーザーのエンドツーエンドの推論ニーズに対応します。開発プラットフォームと推論プラットフォームをつなぐ主要コンポーネントであるORMBとモデルリポジトリは、私たちの第一歩です。開発者の皆様にはぜひお試しいただき、ご活用いただければ幸いです。
| 