機械学習による予測を自動的にスケールする方法

※この投稿は米国時間 2020 年 12 月 18 日に、Google Cloud blog に投稿されたものの抄訳です。

これまでのデータ サイエンス分野での大きな問題の一つは、試験運用版段階を通過できないモデルが多数あることでした。データ サイエンス分野が成長を遂げ、成熟するにつれて、プロジェクトの開発速度と再現性を向上させる MLOps プロセスとツールが出現しました。データ サイエンス分野はまだ成長の途上ではありますが、これまで以上に多くのモデルが本番環境にまで到達するようになりました。

これは、自分のモデルが本番環境でどうスケールするかという、データ サイエンティストの次なる疑問へとつながります。本ブログ投稿では、マネージド予測サービスである Google Cloud の AI Platform Prediction を使用して、推論ワークロードのスケーリングに関する問題に対応する方法をご紹介します。

推論ワークロード

機械学習プロジェクトには、トレーニングと推論という 2 つの主要なワークロードがあります。トレーニングはデータサンプルから学習することでモデルを構築するプロセスで、推論は構築されたモデルを使用して、新しいデータで予測を行うプロセスです。

通常、トレーニング ワークロードは長時間実行されるだけでなく、散発的にも実行されます。フィードフォワード ニューラル ネットワークを使用している場合、トレーニング ワークロードには、データを経由し、重みとバイアスを更新して、エラーを最小限に抑える複数のフォワードパスとバックワード パスが含まれます。このプロセスで作成されたモデルが本番環境で多く使用される場合と、新しいデータでモデルを再トレーニングするために、新たなトレーニング ワークロードが頻繫に開始される場合があります。

一方、推論ワークロードは、大量の小規模トランザクションで構成されます。推論演算は、基本的にニューラル ネットワーク経由のフォワードパスです。入力で始まり、各レイヤを経由して行列乗算を実行し、出力を生成します。このワークロードの特性は、推論が本番環境のアプリケーションで使用される仕組みと高い相関性があります。たとえば、ある e コマースサイトにおいては、商品カタログに対するリクエストごとにおすすめの商品情報を提供するための推論演算が開始されます。そのため、e コマース トラフィックに応じて処理されるトラフィックが増減します。

コストとレイテンシのバランスを保つ

推論ワークロードの重要な課題は、コストとレイテンシのバランス調整です。本番環境ワークロードでスムーズなユーザー エクスペリエンスを実現するためには、レイテンシを 100 ミリ秒未満に抑えることが一般的な要件とされています。また、アプリケーションの使用量が予期せず急増することがあっても、レイテンシの要件は変わることはありません。

レイテンシの要件を常に満たすために、多くのノードをプロビジョニングするという考えは魅力的です。オーバープロビジョニングのデメリットとして、多くのノードが最大限利用されず、不要なコストがかかってしまうことが挙げられます。

一方、アンダープロビジョニングではコストが削減されますが、サーバーが過負荷になるためにレイテンシ ターゲットを逃すことがあります。さらに、タイムアウトやドロップされたパケットが発生した場合、エラーになる恐れがあります。

多くの組織が複数のアプリケーションで機械学習を使用していることを考慮すると、さらにやっかいな問題となります。アプリケーションごとに使用状況プロファイルが異なり、さらにアプリケーションごとに独自のパフォーマンス特性の別々のモデルを使用している場合があります。たとえば、このドキュメントで、自然言語、レコメンデーション、コンピュータ ビジョンに対して提供されているモデルの多様なリソース要件について Facebook が記述しています。

AI Platform Prediction サービス

AI Platform Prediction サービスを利用すると、トレーニング済み機械学習モデルをクラウドに簡単にホストでき、このモデルのスケーリングを自動で行えます。ユーザーはホストされるモデルと入力データを併用して予測を行うことができます。このサービスは、タイムリーな推定が必要となる場合のオンライン予測と、大規模なジョブを一括して処理する場合のバッチ予測の両方に対応します。

トレーニング済みモデルをデプロイするには、基本的に関連するモデル アーティファクトのパッケージである「モデル」の作成から始めます。次にこのモデル内に「バージョン」を作成します。これは、モデルファイルと、マシンタイプ、フレームワーク、リージョン、スケーリングなどの構成オプションからなります。フレームワーク、データ処理、依存関係をより詳細に管理するため、このサービスとカスタム コンテナの併用も可能です。

このサービスを使用して予測を行うには、REST API、コマンドライン、クライアント ライブラリを利用できます。オンライン予測では、プロジェクト、モデル、バージョンを指定し、それをドキュメントの記述どおりにフォーマットされた一連のインスタンスで渡します。

スケーリング オプションの概要

バージョンを定義する場合、manualScaling.nodes オプションによって、使用する予測ノードの数を指定できます。ノードの数を手動で設定することで、ノードは予測を提供しているかどうかにかかわらず、常時実行されます。別の構成で新しいモデル バージョンを作成することで、ノード数を調整できます。

自動スケーリングを行うようにサービスを構成することもできます。このサービスでは、トラフィックが増加するとノードの数が増え、トラフィックが減少するとノードの数が減ります。autoScaling.minNodes オプションによって自動スケーリングをオンに設定できます。autoScaling.maxNodes でノードの最大数を設定することも可能です。こうした設定は、指定した制約内でノードの数を調整することで、サービスの使用率を上げ、コストを削減するために重要なものです。

ゾーンのいずれかでサービスが停止した場合に対応するため、マルチゾーン スケーリングでゾーン間の継続的可用性が実現できます。少なくとも 1 つのノードで自動スケーリングを使用するか、2 つ以上のノードで手動スケーリングを使用すると、指定されたリージョンのゾーン間にノードが自動的に配布されます。

GPU のサポート

モデル バージョンを定義する場合には、マシンタイプと、GPU アクセラレータ（省略可能）を指定する必要があります。各仮想マシン インスタンスは、接続している GPU に演算をオフロードできます。これで、パフォーマンスが大幅に改善することがあります。Google Cloud でサポートされている GPU の詳細については、こちらのブログ投稿: NVIDIA T4、P100、V100 の利用によるコスト削減とスループットの向上をご覧ください。

AI Platform Prediction サービスでは、自動スケーリング機能のため、GPU のサポートが導入されたばかりです。このサービスは、スケールアップまたはスケールダウンが必要かどうか判断するため、CPU 使用率と GPU 使用率の両方を確認します。

自動スケーリングの仕組み

オンライン予測サービスでは、レイテンシの増大を最小限に抑えつつ、最大数のリクエストを処理できるように、使用するノード数をスケールします。そのために、サービスは次の処理を行います。

• 予測リクエストが実行されてからノードを割り振る（ノード数は、モデル バージョンで minNodes オプションを設定することで指定できます）。

• モデル バージョンのデプロイが必要になった場合（トラフィックの増加など）、すみやかに自動的にスケールアップする。

• モデル バージョンのデプロイが不要になった場合（トラフィックの減少など）は自動的にスケールダウンし、コストを抑える。

• 処理するリクエストがない場合でも、リクエストの処理がいつでもできるよう、少なくともノードの最小数（モデル バージョンの minNodes オプションで指定）を確保しておく。

現在では、予測サービスは CPU 使用率と GPU デューティ サイクルの 2 つの指標に基づき、自動スケーリングに対応しています。どちらの指標もモデルごとの平均使用率で測定されます。ユーザーはこの 2 つの指標のターゲット値を CreateVersion API に指定できます（以下の例をご覧ください）。ターゲット フィールドには、指定された指標のターゲット値を指定します。実際の指標が特定の期間、ターゲットから逸脱すると、ノードカウントを調整して実際の指標に合わせます。

新しいモデルで CPU 自動スケーリングを有効にする方法

CPU 指標に基づいた自動スケーリングによってバージョンを作成する例を以下に示します。この例では、CPU 使用率のターゲットは 60%、最小ノード数が 1、最大ノード数が 3 に設定されています。実際の CPU 使用率が 60% を超過すると、ノードカウントが（最大 3 まで）増加します。実際の CPU 使用率が特定の期間 60% を下回ると、ノードカウントが（最低 1 まで）減少します。指標にターゲット値が設定されていない場合、デフォルト値の 60% に設定されます。

gcloud の使用:

curl の例:

version.json

GPU の使用

現在では、オンライン予測サービスは、予測スピードを大幅に向上可能な GPU に基づく予測に対応しています。今までは、ユーザーがモデルごとに GPU 数を手動で指定する必要がありました。この設定には次のようないくつかの制約があります。

• GPU 数を正確に見積もるため、ユーザーは 1 個の GPU が特定のマシンタイプに対して処理できる最大スループットを知っている必要がある。

• モデルのトラフィック パターンが時間の経過とともに変化する可能性があるので、元の GPU 数が最適でなくなる場合がある。たとえば、トラフィック量が多いとリソースが不足し、タイムアウトやリクエストのドロップが発生する可能性があります。一方トラフィック量が少ないと、リソースがアイドル状態になり、コストが増大する可能性があります。

こうした制約に対応するため、AI Platform Prediction サービスは GPU に基づく自動スケーリングを導入しました。

GPU 指標と CPU 指標の両方に基づいた自動スケーリングによってバージョンを作成する例を以下に示します。この例では、CPU 使用率のターゲットは 50%、GPU デューティ サイクルは 60%、最小ノード数が 1、最大ノード数が 3 に設定されています。特定の期間、実際の CPU 使用率が 60% を超過または GPU デューティ サイクルが 60% を超過すると、ノードカウントが（最大 3 まで）増加します。特定の期間、実際の CPU 使用率が 50% を下回る、または GPU デューティ サイクルが 60% を下回ると、ノードカウントが（最低 1 まで）減少します。指標にターゲット値が設定されていない場合、デフォルト値の 60% に設定されます。acceleratorConfig.count はノードごとの GPU の数です。

gcloud の例:

Curl の例:

version.json

自動スケーリングを使用する場合の注意点

オンライン予測の自動スケーリングは、費用を最小限に抑えながらさまざまな頻度の予測リクエストの処理に役立ちます。ただし、それがすべての状況に最適であるとは限りません。このサービスで、リクエスト トラフィックの急増に追いつけるほど高速にノードをオンラインにすることができない場合があります。GPU を使用できるようにこのサービスを構成済みの場合は、新しい GPU ノードをプロビジョニングするには CPU ノードよりも多く時間がかかることにもご注意ください。トラフィックが定期的に急増する場合や、アプリケーションが確実な低レイテンシを必要とする場合は、新しいマシンを早期に起動するためしきい値を低くする、minNodes を十分に大きい値に設定する、または手動スケーリングを使用することをご検討ください。

モデルを本番環境に導入する前に、負荷テストを行うことをおすすめします。負荷テストを使用すると、モデルが負荷に合わせて確実にスケールできるように、ノードの最小数としきい値を調整できます。ノードの最小数は、AI Platform Training と Prediction SLA の適用対象となるモデル バージョンに対して、2 以上を指定する必要があります。

AI Platform Prediction サービスには、CPU と GPU リソースの使用量だけでなく、特定期間内の予測数など、サービス リクエストに関するデフォルトの割り当てがあります。特定の制限の詳細については、こちらのドキュメントをご覧ください。この制限を更新する必要がある場合は、割り当ての増加をオンラインまたはサポート チャネル経由で申請できます。

まとめ

本ブログ投稿では、AI Platform Prediction サービスが、お客様のワークロードに合わせてシンプルかつ費用対効果の高い方法でスケールする方法についてご紹介しました。これで、オーバープロビジョニングなしで推論を加速するGPU の自動スケーリングを設定できるようになりました。

このサービスをご自分で使ってみるには、サンプル ノートブックでモデルをデプロイし、自動スケーリングを設定する方法をお試しください。AI Platform Prediction のドキュメントでも、このサービスと設定オプションの詳しい使用方法を解説しています。

-デベロッパー アドボカシー担当マネージャー Karl Weinmeister