Azure Machine Learning の計算リソース
Azure Machine Learningは、データセットの管理、機械学習モデルのトレーニング、バージョン管理、評価、そしてそれらのモデルを他の人が使用できるエンドポイントにデプロイするための強力なツールスイートです。しかし、これらのタスクの多くは生のコンピューティングパワーを要するので、Azure Machine Learning Studioで私たちが利用できるオプションを理解することが重要です。
Microsoftは現時点で以下のようなコンピュートの異なる種類を提供しています:
- 計算インスタンス
- 計算クラスター
- 推論クラスター
- アタッチされたコンピュート
- ローカルコンピュート
- Azure Container Instance
- Azure Kubernetes Service
それぞれの計算リソースは異なるニーズを満たし、異なる能力とコストプロファイルを持っています。一つ一つを見ていきましょう。
計算インスタンス
計算インスタンスは、主にクラウドでアプリケーションを実行するために使用される、事前に設定されたコンピュート環境です。例えば、Jupyter Notebooks、JupyterLab、VS Code、R Studioなどです。
計算インスタンスは、機械学習トレーニング操作を実行する際のコンピュートターゲットとしても使用できますが、_計算クラスター_でこれらの実験を実行したほうが一般的に良い経験が得られるでしょう。
計算インスタンスは、Azure Machine Learning Studioの計算セクション内の計算インスタンスタブから作成できますが、Azure ML Python SDKを介してコード上でも作成可能です。
計算インスタンスはCPUまたはGPUベースであり、Microsoftはさまざまなリソースプロファイルを提供しており、異なる価格帯でコンピューティングとストレージのニーズに対応しています。
Jupyterノートブックを実行している時に、より強力なCPUリソースやGPUにすることから大きく恩恵を受けることはあまりありません。なぜなら、その作業は繰り返し行われるもので、進捗の最大の障壁は私自身の考える速度だからです。しかし、計算インスタンスで真剣に数値計算を行う必要がある場合は、より大きなプロファイルから恩恵を受けるかもしれません。
計算インスタンスはアクティブなときにのみ課金されます(ただし、それで使用するノートブックやその他のリソースのストレージコストはかかります)。したがって、使い終わったら計算リソースを手動で非アクティブ化することを強くお勧めします。
また、特定の時間範囲内でチームに常にアクティブで利用可能であるようにしたい場合や、計算インスタンスの非アクティブ化を忘れがちな方のために、計算インスタンスを自動的にオン/オフするための_スケジュール_を設定することもできます。
請求のヒント:計算インスタンスを利用する時は、週の各日に自動的にオフになるようにスケジュールされた非アクティブ化時間を設定しておくことで、過剰なコストを避けましょう。
計算クラスター
計算クラスターは、Azure Machine Learningにおいて私が最も気にかけているコンピューティングリソースです。計算クラスターは、利用可能な作業に基づいて自動でスケールアップおよびダウンし、自動化されたMLランや大規模な機械学習タスクをすばやく実行するために使用できます。
計算インスタンスとは異なり、計算クラスターはJupyterノートブックをパワーするためには使用できませんが、モデルトレーニングにはよりよい選択です。
クラスターをプロビジョニングするときには、それがCPUかGPUかを指定し、クラスターノードごとの仮想マシンサイズを選択し、専用の仮想マシン、または低優先度の仮想マシンかを選びます。
低優先度の仮想マシンは、時間あたりのコストが大幅に安いですが、Azureは他のユーザーからの専用ジョブのタスクを実行するために、それらをプリエンプションすることがあります。あなたの機械学習ランが緊急でない場合、または主に一日のオフピーク使用時間にモデルトレーニングを行う場合、低優先度の使用を検討する価値があります。
コンピュートクラスターを作成する際には、次のようにクラスターにアクティブなノードの最小数と最大数も指定する必要があります:
選択したコンピュートリソースの階層と、Azureアカウントに割り当てられているコンピュートリソースの利用可能クオータ(サポートに連絡することで増やせます)に基づき、可能なノードの最大数は異なります。
請求のヒント:Azureがノードがオンの場合にのみコンピュートクラスターのために請求するため、必ずクラスターが使われていない時にオフラインになるようにノードの最小数を0に設定するように強く推奨します。そうすることで、タスクを待機しているアイドル状態のクラスターノードに請求されることがないようにします。
推論クラスター
推論クラスターは、パイプラインベースの推論シナリオに使用されるKubernetesクラスターです。
他のAzure計算リソースと同様に、推論クラスターはAzure Machine Learning Studioの計算ページの推論クラスタータブからプロビジョニングされます。
ここから、リソースの階層と場所を指定し、ノードの数と、クラスターが開発/テスト目的か、製造目的かを選択します。
これらのクラスターはAzure Machine Learning Studioの他のリソースよりもはるかに使用頻度が低く、明確なニーズがない限りは避けることをお勧めします。
アタッチされたコンピュート
アタッチされたコンピュートでは、Azure内の既存のコンピュートリソースをAzure Machine Learning Studioに接続できます。これにより、機械学習モデルのトレーニングに使用するコンピュートターゲットとして、既存の仮想マシン、Databricks、またはHD Insightsクラスターを利用できるようになります。
アタッチされたコンピュートは、すでにAzureにプロビジョニングされた仮想マシンやその他のリソースがあり、モデルトレーニング用にアイドル容量がありそうな場合には非常に意味があります。
しかし、これらのリソースが既に利用可能でない場合、Azure Machine Learning の計算クラスターを使ったほうが経済的にはるかに良いでしょう。
ローカルコンピュート
アタッチされたコンピュートの話題で、_ローカルコンピュート_がAzure Machine Learningの一部のタスクに対してオプションであると言及すべきです。
特定の機械学習スクリプトを実行し、メトリック、データセット、および訓練されたモデルのみをAzureに格納したい場合、Azure ML Python SDKを使用して自分のコンピュートリソース上で機械学習リソースをトレーニングすることができます。
同じように、Azure Machine Learning Studioのノートブックや計算インスタンス機能を使うよりも、Jupyterノートブック、JupyterLab、R Studio、およびVS CodeをAzureの外部で自分のコンピュートリソース上で実行することは十分に可能です。
しかしながら、現時点ではローカルコンピュートで実行できないAzure Machine Learningのタスクもたくさんあります。
Azure Container Instance
Azure Container Instance(ACI)は、トレーニング済みの機械学習モデルをコンテナ化されたエンドポイントとしてデプロイする方法です。
ACIをデプロイに使用することで、訓練されたモデルを低ボリュームの目的で容易にパッケージ化して、デプロイされたWebサービスエンドポイントとして使えます。
Azure Container Instancesはキーベースの認証または認証なしをサポートしており、ほとんどの開発、テスト、および低ボリュームのシナリオに適しています。
Azure Container Instancesの作成とデプロイには時間がかかり(約20分)常に実行されているため、オンデマンドでスケールアップおよびダウン可能な他の計算リソースよりもコストがかかることを覚えておいてください。
Azure Kubernetes Service
Azure Kubernetes Service(AKS)を使用すると、トレーニング済みの機械学習モデルをスケーラブルなノード数を持つKubernetesサービスにデプロイできます。
これにより、一度に多くのリクエストをサポートする必要のある高ボリュームのエンドポイントに対して、より動的にスケーラブルな機械学習エンドポイントを持ちます。
さらに、Azure Kubernetes Serviceでは、トークンが侵害された場合に備えて時間をかけて自動的にリフレッシュするトークンベースの認証を使用できます。これは結局、Azure Container Instancesが提供するキーベースのアプローチよりも良いセキュリティを提供します。
いつどの計算リソースを選ぶか?
それでは、どの計算リソースがあなたに適しているのでしょうか?
私のオススメは、可能な限りAzure Machine Learningで計算クラスターを使用し、コストをコントロールするために、クラスターの最小サイズを0ノードに設定することです。
デプロイについては、Azure Kubernetes Serviceが製品ワークフロー向けに、Azure Container Instancesが開発およびテスト向けに意図されているとはいえ、あまりリクエストが来ないと予想している場合は、コストコントロール目的でAzure Container Instancesの使用を試してみることを推奨します。
コストが重要な場合は、可能な限りローカルコンピュートでモデルトレーニングを行い、訓練されたモデルをAzureの外部でホストおよびデプロイする方法がよりコスト効率的である場合は、それを検討してください。
もしAzure Machine Learning Studio内のノートブックを使用するという場面に遭遇した場合、計算インスタンスも必要になるので、計算インスタンスが少なくとも一度は自動的にオフになるように週のどの日にでもスケジュールすることを忘れずに、課金に関するサプライズを避けてください。
私の典型的なアプローチは、計算クラスターを使用するとともに、モデルデプロイにはAzure Container Instancesを戦略的に使用することです。
機械学習モデルの訓練やデプロイにあたり、あなたやあなたのチームに何がうまく機能するか、ぜひ教えてください!
こちらの記事はdev.toの良い記事を日本人向けに翻訳しています。
https://dev.to/integerman/azure-machine-learning-compute-resources-3623