Amazon SageMakerのマルチモデルエンドポイントを使用して、Veriffがデプロイ時間を80％削減する方法

Amazon SageMakerのマルチモデルエンドポイントを使い、Veriffがデプロイ時間を80％短縮する方法

デデリフは、金融サービス、FinTech、暗号通貨、ゲーム、モビリティ、オンラインマーケットプレイスなど、革新的な成長志向の組織のアイデンティティー認証プラットフォームのパートナーです。彼らはAIパワーの自動化と人間のフィードバック、深い洞察、専門知識を組み合わせた先進的な技術を提供しています。

Veriffは、顧客の旅の中で関連するすべての瞬間において、ユーザーのアイデンティティーと個人属性の信頼性を確保するための確立済みのインフラを提供しています。Bolt、Deel、Monese、Starship、Super Awesome、Trustpilot、Wiseなどの顧客からの信頼を得ています。

AIパワーのソリューションであるVeriffは、コスト効率的な方法で数十の機械学習（ML）モデルを作成および実行する必要があります。これらのモデルには、軽量なツリーベースのモデルから、低レイテンシーを達成しユーザーエクスペリエンスを向上させるためにGPU上で実行する必要のある深層学習コンピュータビジョンモデルまでさまざまなものがございます。現在、Veriffは自社の提供する製品をさらに追加し、顧客向けにハイパーカスタマイズされたソリューションを目指しています。異なる顧客に対して異なるモデルを提供することは、スケーラブルなモデル提供ソリューションの必要性を増加させています。

• RAGアプリケーションデザインにおける実用的な考慮事項
• 「2Dから3Dへ：アラインドジオメトリックプライオリティを用いたテキストから3D生成の一貫性向上」
• オラクルは、AIとクラウドを基盤とした未来のビジョンを明らかにしました

この記事では、Veriffがコストと開発時間を削減するために、Amazon SageMakerを使ってモデルデプロイメントワークフローを標準化した方法をご紹介します。

インフラストラクチャと開発の課題

Veriffのバックエンドアーキテクチャは、AWSインフラストラクチャ上でホストされるさまざまなKubernetesクラスタ上で実行されるマイクロサービスパターンに基づいています。このアプローチは、おおよそすべての企業サービスに初めて使用され、高価なコンピュータビジョンMLモデルを実行するマイクロサービスも含まれていました。

これらのモデルの一部は、GPUインスタンス上での展開が必要でした。GPUバックドインスタンスタイプのコストが比較的高いという事実を認識していたVeriffは、同じGPUのリソースを異なるサービスレプリカ間で共有するためのカスタムソリューションをKubernetes上に開発しました。通常、1つのGPUには、複数のVeriffのコンピュータビジョンモデルをメモリに保持するのに十分なVRAMがあります。

このソリューションによりGPUのコストは軽減されましたが、データサイエンティストは事前にモデルがどれくらいのGPUメモリが必要かを示す必要がありました。さらに、デマンドパターンに応じてGPUインスタンスを手動でプロビジョニングするため、DevOpsには運用上の負担が生じました。これにより過剰なインスタンスが確保され、最適なコストプロファイルとは言えない結果となりました。

GPUプロビジョニングに加えて、このセットアップではデータサイエンティストがモデルの各々にREST APIのラッパーを構築する必要がありました。これは、他の企業のサービスが消費するための汎用のインターフェースを提供し、モデルデータの前処理と後処理をカプセル化するために必要でした。これらのAPIには本番向けのコードが必要であり、データサイエンティストにとってはモデルのプロダクション化が難しいものとなりました。

Veriffのデータサイエンスプラットフォームチームは、このアプローチに対する代替案を模索しました。主な目的は、よりシンプルなデプロイメントパイプラインを提供することにより、企業のデータサイエンティストが研究から本番への移行をスムーズに行えるよう支援することでした。第二の目的は、GPUインスタンスのプロビジョニングの運用コストを削減することでした。

ソリューション概要

Veriffは、次の2つの問題を解決する新しいソリューションを求めていました：

• 簡単にMLモデルのREST APIラッパーを作成できるようにする
• プロビジョニングされたGPUインスタンスの容量を最適化し、可能であれば自動化すること

最終的に、MLプラットフォームチームはSagemakerマルチモデルエンドポイント（MME）の使用を決定しました。この決定は、MMEがNVIDIAのTriton Inference Server（モデルをREST APIとしてラッピングするためのML専用サーバーで、Veriffは既にTritonを試験的に使用していました）をサポートしていること、さらにはシンプルなオートスケーリングポリシーによりGPUインスタンスの自動スケーリングをネイティブに管理できることが理由でした。

Veriffではステージングと本番の2つのMMEが作成されました。このアプローチにより、本番モデルに影響を与えることなく、テスト手順をステージング環境で実行できるようになりました。

SageMaker MMEs

SageMakerは、開発者やデータサイエンティストが迅速に機械学習モデルを構築、トレーニング、デプロイするための完全マネージドサービスです。SageMaker MME（Multi-Model Endpoints）は、大量のモデルをリアルタイム推論のためにデプロイするためのスケーラブルかつコスト効果の高いソリューションを提供します。MMEは共有のサービングコンテナと、すべてのモデルをホストするためにGPUなどのアクセラレートインスタンスを使用できるリソースのフリートを使用します。これにより、シングルモデルのエンドポイントを使用する場合に比べてエンドポイントの利用率を最大化することでホスティングコストを削減できます。また、SageMakerはメモリにモデルをロードし、トラフィックパターンに基づいてスケーリングしながらモデルの読み込みと削除を管理するため、デプロイメントのオーバーヘッドも削減します。さらに、全てのSageMakerのリアルタイムエンドポイントは、シャドウバリアント、自動スケーリング、Amazon CloudWatchとのネイティブ統合など、モデルの管理とモニタリングのための組み込み機能も利用できます（詳細は、CloudWatchメトリクスに関するマルチモデルエンドポイントの展開を参照）。

カスタムTritonアンサンブルモデル

VeriffがTriton Inference Serverを使用する理由はいくつかありますが、主な理由は以下の通りです：

• モデルアーティファクトファイルを標準のディレクトリ形式で配置することで、データサイエンティストがモデルからREST APIを構築できる（コード不要のソリューション）
• すべての主要なAIフレームワーク（PyTorch、Tensorflow、XGBoostなど）と互換性があります
• リクエストの動的バッチングなど、低レベルな最適化とサーバー最適化を提供します。動的バッチング

Tritonを使用すると、データサイェンティストはモデルをREST APIを構築するためにコードを書く必要がなくなるため、モデルの展開を簡単に行うことができます（Tritonは、必要に応じてPythonモデルもサポートしており、カスタム推論ロジックが必要な場合に使用できます）。これにより、モデルの展開時間が短縮され、データサイエンティストはモデルを構築するだけでなく、デプロイメントに時間を割くことができます。

Tritonのもう1つの重要な機能は、モデルアンサンブルを構築できることです。モデルアンサンブルは、チェーン状に連結された複数のモデルのグループです。これらのアンサンブルモデルは、単一のTritonモデルとして実行できます。Veriffは現在、Pythonモデル（前述のように）を使用して、各MLモデルに前処理と後処理のロジックをデプロイしています。これにより、本番環境でモデルを使用する際に、入力データやモデルの出力に不一致がないことを保証しています。

以下は、このワークロードの典型的なTritonモデルリポジトリの例です：

model.pyファイルには前処理と後処理のコードが含まれています。訓練済みのモデルの重みは、screen_detection_inferencerディレクトリの1バージョンのモデルにあります（この例ではONNX形式ですが、TensorFlowやPyTorch形式などでも構いません）。アンサンブルモデルの定義はscreen_detection_pipelineディレクトリにあり、各ステップ間の入力と出力を構成ファイルでマッピングします。

Pythonモデルを実行するために必要な追加の依存関係は、requirements.txtファイルに詳細化されており、Conda環境をビルドするためにconda-packされる必要があります（python_env.tar.gz）。詳細については、Pythonランタイムとライブラリの管理を参照してください。また、Pythonステップ用の構成ファイルは、EXECUTION_ENV_PATHディレクティブを使用してpython_env.tar.gzを指す必要があります。

モデルフォルダは、model_version.txtを使用してTAR形式で圧縮され、名前が変更される必要があります。最後に、<model_name>_<model_version>.tar.gzという名前のファイルが、MMEに接続されたAmazon Simple Storage Service（Amazon S3）バケットにコピーされ、SageMakerがモデルを検出して提供できるようになります。

モデルのバージョニングと継続的な展開

前のセクションで明らかになったように、Tritonモデルリポジトリの構築は簡単です。ただし、手動で実行すると手間がかかり、エラーが発生する可能性があります。これを克服するために、VeriffはMMEに展開するすべてのモデルを含むモノレポを構築しました。データサイエンティストはGitflowのようなアプローチで協力し、モノレポには次の機能があります：

• Pantsを使用して管理されています。
• BlackやMyPyなどのコード品質ツールがPantsを使用して適用されます。
• 各モデルに対してユニットテストが定義されており、モデルの出力が特定のモデル入力に対して期待される出力であるかを確認します。
• モデルの重みは、モデルリポジトリと一緒に保存されます。これらの重みは大きなバイナリファイルであるため、バージョン管理された形式でGitと同期するためにDVCが使用されています。

このモノレポは、継続的統合（CI）ツールと統合されています。リポジトリへの新しいプッシュや新しいモデルごとに、以下の手順が実行されます：

1. コード品質チェックをパスする。
2. モデルの重みをダウンロードする。
3. Conda環境をビルドする。
4. Conda環境を使用してTritonサーバーを起動し、ユニットテストで定義されたリクエストを処理する。
5. 最終的なモデルTARファイル（<model_name>_<model_version>.tar.gz）をビルドする。

これらの手順により、モデルが展開に必要な品質を持つことが保証されるため、リポジトリのブランチにプッシュするたびに、生成されたTARファイルはステージングS3バケットにコピーされます（別のCIステップで）。メインブランチにプッシュすると、モデルファイルが本番用S3バケットにコピーされます。次の図は、このCI/CDシステムを示しています。

コストと展開速度の利点

MMEの使用により、Veriffはモデルを本番環境に展開するためのモノレポアプローチを使用できます。要約すると、Veriffの新しいモデル展開ワークフローは、次の手順で行われます：

1. 新しいモデルまたはモデルバージョンを含むモノレポのブランチを作成する。
2. 開発マシンでユニットテストを定義して実行する。
3. モデルがステージング環境でテストされる準備ができたら、ブランチをプッシュする。
4. モデルが本番で使用される準備ができたら、ブランチをメインにマージする。

この新しいソリューションにより、Veriffでのモデルの展開は開発プロセスの簡単な一部になりました。新しいモデルの開発時間は、10日から平均2日に短縮されました。

SageMakerの管理されたインフラストラクチャのプロビジョニングと自動スケーリング機能により、Veriffは追加の利点を得ました。彼らはInvocationsPerInstance CloudWatchメトリックを使用してトラフィックパターンに応じてスケーリングし、信頼性を損なうことなくコストを節約しました。メトリックのための閾値値を定義するために、彼らはステージングエンドポイントで負荷テストを実施し、レイテンシとコストの最適なトレードオフを見つけました。

MMEに7つの本番モデルを展開し、支出を分析した結果、VeriffはオリジナルのKubernetesベースのソリューションに比べてGPUモデルサービングのコストを75％削減しました。運用コストも削減されました。なぜなら、手動でインスタンスをプロビジョニングする負担がDevOpsエンジニアから取り除かれたからです。

結論

この記事では、VeriffがKubernetes上での自己管理型モデル展開に代わってSagemaker MMEを選択した理由について説明しました。SageMakerは、異質な重い作業を引き受けることで、Veriffがモデルの開発時間を短縮し、エンジニアリングの効率を向上させ、ビジネスクリティカルな操作に必要なパフォーマンスを維持しながら、リアルタイムの推論のためのコストを劇的に低減することを可能にします。最後に、Veriffのシンプルで効果的なモデル展開CI/CDパイプラインとモデルのバージョニングメカニズムを紹介しました。これは、ソフトウェア開発のベストプラクティスとSageMaker MMEの組み合わせの参考実装として使用できます。SageMaker MMEを使用して複数のモデルをホスティングするコードサンプルは、GitHubで入手できます。

We will continue to update VoAGI; if you have any questions or suggestions, please contact us!