はじめに

こんにちは、23新卒として入社し、現在データ基盤部プラットフォームグループでSREをしている黄( @harris0n3ag1e )と申します。

本記事では、データ基盤部で開発・運用している、 内製ML推論基盤「Hekatoncheir」 の1つの構成要素である「Model Serving Platform」について紹介します。

全体の流れとして、機械学習サービス運用における課題と、その解決策としてのモデル共通推論基盤「Model Serving Platform」について説明した後、実サービスにおける導入効果と現状の課題点についてお話しします。

機械学習サービスの運用における課題

2024/09現在、Hekatoncheir基盤では20前後の機械学習サービスが運用されており、今後Hekatoncheir上で運用するサービスはさらに増加する予定です。

このようにHekatoncheirを活用したサービスが増加している中、運用において下記の課題点が表面化してきました。

機械学習サービスのリソース使用効率の改善が困難

Hekatoncheir上で運用されている機械学習サービスは、基本的に図のようにデータの前処理から後処理までを含めたモノシリックな実装になっています。

実際の機械学習サービスでは、推論処理はGPUで行い、前処理はCPUで行うなど、推論処理部分とその他の部分で負荷が集中する箇所に違いがあります。モノシリックな実装の場合、リソースの使用効率を上げるのが難しいという課題がありました。

共通化可能な実装の分散問題

前述の通り、Hekatoncheir上で運用されている機械学習サービスのほとんどは、1サーバごとにモノシリックな1つの実装があるという状態になっています。

そのため、パフォーマンス改善や安定化のための改善などを行う際に、サービスの実装・Kubernetesマニフェストが各サービスごとに分散しており、すべてのサービスに対して適用可能な改善をスピーディーに展開することが困難になっています。

Model Serving Platformとは

上述の課題を解消する為に、Hekatoncheirの１機能として「Model Serving Platform」と呼ばれるプラットフォームサービスを構築しました。Model Serving Platformは、推論処理のみを行うマイクロサービスをHekatoncheir上にデプロイするためのサービスです。モノリシックな構成で作成した機械学習サービスのモデル推論部分を下の図のようにマイクロサービスとして切り出すことによって、リソース設定の最適化と、運用負荷の軽減などのメリットを得ることを期待できます。

推論サーバーはModel Serving Platformによって管理されている為、サービス開発者は前後処理を行うAPIサーバーと機械学習モデルのみ用意することによって機械学習サービスを構成できます。運用チームは推論サーバーとModel Serving Platformに運用責任を持ち、開発者は機械学習モデルと、データの前後処理を行うAPIサーバーだけに対し責任を負うので、開発者・運用チーム間の責任範囲も明確化されます。

Model Serving Platformを利用することで下記の利点も期待できます:

• 機械学習モデルのデプロイの簡略化による開発者負荷の軽減
• 複数サービスにおいて同一モデルの共有が可能
• 推論サーバー構成の標準化による、高速化や安定化、セキュリティ対応などのサービス改善の横展開の容易化

Model Serving Platformの構成要素

この章では、Model Serving Platformを構成している要素について説明します。

共通推論サーバーとしてのTriton Inference Server

Model Serving Platformで推論サーバを提供するにあたって、下記の条件を満たす共通推論サーバーを用意する必要があります:

• Tensorflow、PyTorchなど複数の機械学習フレームワークに対応可能
• 機械学習モデルの推論において十分な性能が出せる

これらの要件に対応する為に、OSSの採用や推論サーバーの内製などの選択肢を検討しましたが、最終的にNVIDIA社がOSSとして提供している Triton Inference Server を共通推論サーバーとして選定しました。 Triton Inference Server を共通推論サーバーとして採用する決め手になった点は下記の通りです:

• 推論に特化したチューニングを行わなくても、十分なパフォーマンスを発揮できる。その為、今後機械学習サービスに対するリクエストが増加しても、十分な負荷が耐えられるので、サービスのスケーリングとコスト抑制につながる。
• Triton Client Libraries によって推論部分のコードを共通化することができ、同じコードで色んな種類の機械学習モデルの推論を実行できる
• 複数モデルに対応しており、同じサーバーで複数モデルを運用するなどリソースの有効活用が簡単に行える
• 推論サーバーとしての機能が充実しており、バッチ推論やモデルのウォーミングアップなども対応可能

デプロイを簡略化するカスタムリソース

推論部分をマイクロサービスとして切り出す為に、クラスター内部通信用の Service や、推論サーバー用の Deployment および HPA などのKubernetesリソースを整備する必要があります。しかし、これらのリソースを整備する為にはKubernetesの知見が必要であり、推論サーバーなデプロイに200行を超えるマニフェストを記述する必要があります。この問題によって推論サーバーのデプロイに時間がかかってしまい、機械学習サービスのリリースサイクルが低下につながります。

また、推論サーバーごとにマニフェストを用意する場合、推論サーバーのデプロイの属人化や、共通の設定の横展開が煩雑になるなどの課題が生じます。

推論サーバーのデプロイの簡略化と、デプロイ構成の標準化を実現する為にカスタムリソースを利用しました。モデルパスやリソース設定など、モデルをデプロイするにあたって最低限必要な情報だけ渡せば推論サーバーをデプロイできるようカスタムリソースを定義してます。同時に、カスタムコントローラーを内製し、下記の図が示したように、推論サーバーのリソースの管理を自動化してます。

なお、推論サーバーのデプロイ環境を構築する手段として、 KServe の利用も選択肢にありましたが、 KServe を採用した場合、プラットフォームの構成が複雑になり、チーム規模的に運用負荷が高くなってしまうことが懸念されました。カスタムリソースとカスタムコントローラーを独自に用意する場合、最小限の構成でデプロイ環境を構築することができ、ユースケースに合わせてカスタマイズもしやすい為、最終的に KServe を利用するのではなく、内製する意思決定をしました。

性能評価

Model Serving Platformの導入効果を検証する為に、モノリシックな構成であった機械学習サービスの推論部分を、Model Serving Platformの推論サーバーに分離し、分離前後のサービスに対して負荷試験を実施しました。

このサービスでは、2つのTensorflowモデルを1台のGPU付きサーバーで運用しています。前後処理として、S3バケットからの画像の取得と、画像変換と推論結果から結果計算を行なっています。

実際の運用ではトラフィック量に応じてサーバーのオートスケーリングも実施していますが、本実験では、評価しやすいようにオートスケーリングを停止した上で実施しました。

負荷試験時のリソース設定

従来の構成

Model Serving Platform利用時

前後処理を行うAPIサーバー

推論サーバー

レスポンス時間比較

稼働中のサービスに対して同時接続300ユーザーの負荷を5分間継続し、その間の平均レスポンス時間を比較します。

推論サーバーをマイクロサービスに移行したことによって、性能悪化の懸念がありましたが、Model Serving Platform移行後、レスポンスタイムの悪化は見られず、移行前と比べて多少改善が見られました。

なお、負荷を上げ続けた結果、従来の構成では、同時接続ユーザー数が330前後からレイテンシーが大幅に悪化し始めましたが、Model Serving Platform移行後の構成では、同時接続数510ユーザー前後でもレイテンシーの悪化が見られず、スループットが改善されたことを確認できました。

リソース使用効率の比較

サービスに対して秒ごとに1接続ユーザーがの増加するペースで連続して負荷を増加させ、その時のサービスのソースの使用効率を比較します。 下記は、負荷試験を開始してから同時接続ユーザー数が400前後に到達した際のリソース使用量の推移です。赤線は各サーバーのリソース要求量を示しており、青線はリソース使用量の推移を表しています。

従来の構成でのリソース使用率の推移

Model Serving Platform利用時のリソース使用率の推移

前後処理を行うAPIサーバー側リソース使用率の推移

推論サーバー側リソース使用率の推移

Model Serving Platform利用時では、従来と比べてリソース利用量に余裕がありました。

その為、リソース設定を最適化すれば、従来の構成と比べてリソース要求を抑えることができ、インフラコストを抑制できることがわかりました。

また、従来のモノリシックの構成では、GPUの使用率に余裕があっても、CPUに負荷かかった場合、スケールアウトが必要になりますが、その際にGPUも確保されてしまい、不要なコストがかかってしまいます。Model Serving Platform利用時の構成では、前後処理とモデル推論部分は異なるサーバーにあるため、不要なリソースの確保を抑制することができます。

負荷試験を経て、Triton Inference ServerとModel Serving Platformの採用によって、サービスの性能とスループットが一定改善されたことと、リソース使用効率が大きく改善できたことを確認しました。

NVIDIA公式では、Triton Inference Serverを利用するにあたって、 ONNX形式あるいはTensorRT形式のモデルの利用 や、 Dynamic Batcher の利用などによって推論サーバーの性能を改善する方法を紹介しています。本効果検証ではこれらの手法を採用しておらず、これらのテクニックを使用するとさらなる性能改善が得られると思われます。

導入事例

Model Serving Platformは、 バーチャル警備員サービス の音声合成サーバーに導入済みです。また、 PocochaのAI審査 においても技術検証が終わり、導入を進めているところです。本記事では、Pococha AI審査サービスの新規案件における事例について紹介します。

こちらの案件では、現在Hekatoncheir上で運用しているどのサービスよりも遥かに高い負荷の状況でリアルタイム推論を行う必要があります。

そこで、開発者チームと議論を行い、Triton Inference Serverを推論サーバーとして採用した、Model Serving Platformを本案件に導入する意思決定を行いました。さらなるスループットの向上を図るために、あらかじめTensorflowで作成されたSavedModel形式の機械学習モデルをONNX形式に変換した上で運用しました。

サービスの性能

サービスの性能を検証するために、運用前のサービスに対し、オートスケーリングを設定した上で負荷試験を実施しました。

上記は負荷試験の結果になります。オートスケーリングを設定したことのもありますが、レイテンシーは概ね許容範囲にありました。前段のAPIサーバーと推論サーバーの数がいずれも1である場合、耐えうる最大負荷は同時接続数250ユーザー前後でした。モデルをONNX形式に変換したことも性能向上に功を奏してると考えられますが、スケールアウトが発生しなくても十分な性能を出していました。

この検証結果から、想定されている最大負荷の中でも性能は問題なく、全体のコストも当初想定していたコストより大幅に下回っており、事業部と開発者側からも納得が行く結果を得られました。

開発者体験の改善

本案件においてModel Serving Platformを導入したことによって、開発者体験の面でも大きなメリットが得られました。

開発者としては、モデル推論部分をModel Serving Platformに任せれば良く、それによってAPIサーバーの開発、テストが容易になりました。そして、機械学習ライブラリおよびGPU推論に必要なCUDAやcuDNNなどのライブラリをイメージを含める必要もなくなり、APIサーバーの依存関係とコンテナイメージをメンテナンスする負担を軽減できました。加えて、docker imageのbuildの時間も10分の1ほどに大きく短縮されました。

また、推論部分とそれ以外の処理を違うサーバーに分けたことにより、サービスのボトルネックとリソースを多く使ってる部分の特定がより簡単になりました。本案件でも、負荷試験を実施した際のリソース使用量の推移に基づいて、サーバーのリソース設定の最適化とコストの抑制ができました。

課題点

上の章では実案件においてModel Serving Platformを導入にあたって得られたメリットについて紹介しましたが、現状のModel Serving Platformの課題点についても紹介しておきます。

Triton Inference Serverのイメージサイズが大きい

イメージサイズの問題は実際にGPUを使用する機械学習サービスにも存在している課題ですが、CUDAや機械学習ライブラリが必要な為、推論サーバーのイメージが大きくなります。例えば、NVIDIA公式が提供しているTriton Inference Serverのイメージ場合、23.10-py3のイメージサイズは6.34GBもあります。　
これによって、コンテナイメージのプルに時間がかかり、スケールアウトが発生した場合スケールアウト完了まで5分ほどかかる問題がありました。

一方、NVIDIA公式ではTensorflowあるいはPyTorchのみ入ってるTriton Inference Serverのイメージもあり、ONNX Runtimeのみのイメージも自作できるので、この問題の対策として、イメージに含める機械学習ライブラリを絞ることによってイメージサイズを多少絞ることが可能です。

なお、現状Model Serving Platformでは、DaemonSetを活用してイメージをプリロードする対策を講じています。この方法は推論でCPUのみ使用するケースでは有効ではありますが、GPUを使用場合やスケールアウトする場合など、ノードが新しく作られる場面でプリロードが間に合わない場合もあり、より良い改善策が必要だと考えられます。
GKE 1.30.1からは、 イメージをノードのセカンダリブートディスクにプリロードする手法 が利用可能になっており、今後はこちらの手法によってさらなる改善ができるか検証しようと思います。

モデルによってはTriton Inference Serverのイメージのカスタマイズが必要

こちらの問題は、上記のPococha AI審査サービスの新規案件でもありました。モデルによっては、onnxruntime-extensionsなどTriton公式イメージに含まれていないプラグインを使用する必要があります。その場合、Triton Inference Serverのイメージをベースに、プラグインが入ったイメージを別途用意するなどのカスタマイズが必要になります。

おわりに

本記事では、機械学習モデル共通推論基盤Model Serving Platformについて取り上げました。現状、コンテナイメージサイズなどの課題を抱えているものの、実サービスにおいてModel Serving Platformを導入することによって、性能改善と開発者負荷の軽減など大きなメリットを得られることを検証できました。

今後も継続的に基盤の改善をしつつ、実サービスにおけるModel Serving Platformの導入を推進してまいります。