マルチテナントSaaSユースケースの機械学習推論をスケーリングする方法

この投稿は、Zendeskのシニアスタッフ機械学習エンジニアであるSowmyaManusaniと共同執筆しています。

のZendesk は、シンプルさを基盤として、すべての人のためのサポート、販売、カスタマーエンゲージメントソフトウェアを構築するSaaS企業です。 これは、世界中の170,000万社を超える企業が数億人の顧客に効率的にサービスを提供できるようにすることで成功しています。 Zendcaeskの機械学習チームは、カスタマーエクスペリエンスチームを強化して最高の成果を達成する責任があります。 Zendeskは、データと人の力を組み合わせることで、手作業を自動化することで顧客の生産性を高めるインテリジェントな製品を提供します。

Zendeskは2015年からML製品を構築してきました。 回答ボット, 満足度予測, コンテンツキュー, 推奨されるマクロ、 などなど。 過去数年間、特にNLPでのディープラーニングの成長に伴い、ワークフローを自動化し、エージェントがZendeskソリューションで顧客をサポートするのを支援する多くの機会がありました。 Zendeskは現在、TensorFlowとPyTorchを使用してディープラーニングモデルを構築しています。

Zendeskのような顧客は、Amazon Web Services（AWS）上で成功した大規模なサービスとしてのソフトウェア（SaaS）ビジネスを構築してきました。 SaaSビジネスモデルを成功させるための重要な推進力は、アプリケーションとインフラストラクチャにマルチテナンシーを適用する機能です。 これにより、アプリケーションをXNUMX回だけ構築する必要があるため、コストと運用効率が向上しますが、何度でも使用でき、インフラストラクチャを共有できます。 多くのお客様が、コンピューティング、ストレージ、データベースからネットワーキングに至るまで、スタックのすべてのレイヤーでAWS上に安全で費用対効果の高いマルチテナントシステムを構築していることを確認しています。現在、お客様はそれを機械学習（ML）に適用する必要があります。 ）。

モデルの再利用とハイパーパーソナライズの間の難しいトレードオフを行う

SaaSビジネスのマルチテナンシーとは、通常、単一のアプリケーションが多くのユーザー（SaaSの顧客）間で再利用されることを意味します。 これにより、コスト効率が向上し、運用オーバーヘッドが削減されます。 ただし、機械学習モデルは、正確な予測を行うために、高度な特異性（ハイパーパーソナライズ）にパーソナライズする必要がある場合があります。 つまり、モデルに特異性がある場合、「一度構築して何度も使用する」というSaaSパラダイムをMLに常に適用できるとは限りません。 たとえば、カスタマーサポートプラットフォームのユースケースを考えてみましょう。 ユーザーがサポートチケットに含める言語は、ライドシェアの問題（「ライドに時間がかかりすぎた」）か、衣類の購入の問題（「洗濯時の変色」）かによって異なります。 このユースケースでは、最善の修復アクションを予測する精度を向上させるために、ビジネスドメインまたは業界に固有のデータセットで自然言語処理（NLP）モデルをトレーニングする必要がある場合があります。 Zendeskは、ソリューションでMLを活用しようとすると、まさにこの課題に直面します。 彼らは、それぞれが特定の顧客に合わせて調整された、高度にカスタマイズされた何千ものMLモデルを作成する必要がありました。 何千ものモデルをコスト効率よくデプロイするというこの課題を解決するために、ZendeskはAmazonSageMakerを利用しました。

この投稿では、の新しい機能のいくつかを使用する方法を示します アマゾンセージメーカー、フルマネージドの機械学習サービス。マルチテナントML推論機能を構築します。 また、MLモデルでハイパーパーソナライズをサポートできることと、SageMakerマルチモデルエンドポイントを使用したインフラストラクチャの費用対効果の高い共有使用との間に幸せな媒体を導入することで、Zendeskが同じ結果を達成した実際の例を共有します（ MME）。

SageMakerマルチモデルエンドポイント

SageMakerマルチモデルエンドポイントを使用すると、XNUMXつ以上のインスタンスを含む可能性のある単一の推論エンドポイントの背後に複数のモデルをデプロイできます。 各インスタンスは、メモリとCPU容量まで複数のモデルをロードして提供するように設計されています。 このアーキテクチャにより、SaaSビジネスは、複数のモデルをホストするための直線的に増加するコストを削減し、アプリケーションスタックの他の場所に適用されるマルチテナンシーモデルと一致するインフラストラクチャの再利用を実現できます。

次の図は、SageMakerマルチモデルエンドポイントのアーキテクチャを示しています。

SageMakerマルチモデルエンドポイントは、からモデルを動的にロードします Amazon シンプル ストレージ サービス （Amazon S3）エンドポイントが最初に作成されたときにすべてのモデルをダウンロードする代わりに、呼び出されたとき。 その結果、モデルへの最初の呼び出しでは、低いレイテンシで完了する後続の推論よりも高い推論レイテンシが発生する可能性があります。 呼び出されたときにモデルがすでにコンテナにロードされている場合、ダウンロードステップはスキップされ、モデルは低レイテンシで推論を返します。 たとえば、XNUMX日に数回しか使用されないモデルがあるとします。 頻繁にアクセスされるモデルはメモリに保持され、一貫して低いレイテンシで呼び出されますが、オンデマンドで自動的にロードされます。

ZendeskがSageMakerMMEを使用して、SuggestedMacrosML機能を使用して費用効果の高いハイパースケールMLデプロイメントを実現する方法を詳しく見ていきましょう。

Zendeskがハイパーパーソナライズされたモデルを構築した理由

Zendeskの顧客は、サポートチケットのセマンティクスが異なるさまざまな業界にグローバルに広がっています。 したがって、顧客に最高のサービスを提供するには、顧客固有のサポートチケットデータでトレーニングされたパーソナライズされたモデルを構築して、インテントやマクロなどを正しく識別する必要があります。

2021年XNUMX月に、彼らは新しいNLPML機能であるSuggestedMacrosをリリースしました。これは、何千もの顧客固有のモデル予測に基づいてマクロ（事前定義されたアクション）を推奨します。 ZendeskのMLチームは、顧客ごとのチケットコンテンツとマクロの以前の履歴からトレーニングされたTensorFlowベースのNLP分類モデルを構築しました。 これらのモデルが利用可能であるため、エージェントがチケットを表示するたびにマクロ予測が推奨されます（次のスクリーンショットを参照）。これにより、エージェントは顧客に迅速にサービスを提供できます。 マクロは顧客に固有であるため、Zendeskは正確な予測を提供するために顧客固有のモデルを必要とします。

Zendeskが提案するマクロの内部

推奨されるマクロモデルは、サイズが約7〜15MBのNLPベースのニューラルネットです。 主な課題は、費用対効果が高く、信頼性が高く、スケーラブルなソリューションを使用して、これらのモデルを何千も生産することです。

各モデルには異なるトラフィックパターンがあり、100秒あたり最低XNUMXリクエスト、XNUMX秒あたり数百リクエストのピークがあり、モデルがメモリで利用可能な場合、モデルレイテンシは約XNUMXミリ秒でXNUMX日あたり数百万の予測を提供します。 SageMakerエンドポイントは複数のAWSリージョンにデプロイされ、エンドポイントごとにXNUMX分あたり数千のリクエストを処理します。

SageMakerは、単一のエンドポイントで複数のモデルをホストする機能を備えており、顧客ごとに単一モデルのエンドポイントをデプロイする場合と比較して、Zendeskがデプロイメントのオーバーヘッドを削減し、費用効果の高いソリューションを作成するのに役立ちました。 ここでのトレードオフは、モデルごとの管理の制御が少ないことです。 ただし、これはZendeskがAWSと協力してマルチモデルエンドポイントを改善している分野です。

SageMakerのマルチモデル機能の100つは、モデルの遅延読み込みです。つまり、モデルは、初めて呼び出されたときにメモリに読み込まれます。 これは、メモリ使用率を最適化するためです。 ただし、最初のロードで応答時間のスパイクが発生します。これは、コールドスタートの問題と見なすことができます。 提案されたマクロの場合、これは課題でした。 ただし、Zendeskは、SageMakerエンドポイントプロビジョニングの上にプリロード機能を実装して、本番トラフィックを処理する前にモデルをメモリにロードすることで、これを克服しました。 次に、MMEは使用頻度の低いモデルをメモリからアンロードするため、すべてのモデルで一貫した低レイテンシを実現し、「ノイズの多いネイバー」が他のあまりアクティブでないモデルに影響を与えないようにするために、ZendeskはAWSと協力して、投稿で後述する新機能を追加し、より明示的なモデルごとの管理。 さらに、暫定的なソリューションとして、ZendeskはMMEフリートのサイズを適切に設定して、アンロードするモデルの数を最小限に抑えています。 これにより、Zendeskは、約90ミリ秒という低遅延ですべての顧客に予測を提供し、専用のエンドポイントと比較してXNUMX％のコスト削減を実現できます。

正しいサイズのMMEで、Zendeskは負荷テスト中に、MMEの背後にある小さなインスタンス（水平スケーリングのバイアス）の数が多い方が、大きなメモリインスタンス（垂直スケーリング）の数が少ないよりも良い選択であることを確認しました。 Zendeskは、単一の大容量メモリインスタンスにビンパッキングするモデルが多すぎる（この場合は500 TensorFlowモデルを超える）と、ボトルネックになる可能性のあるインスタンスのリソースがメモリだけではないため、うまく機能しないことを確認しました。 具体的には、TensorFlowがモデルごとに複数のスレッド（合計インスタンスvCPUの3つ）を生成することを確認しました。そのため、単一のインスタンスに500を超えるモデルをロードすると、インスタンスで生成できるスレッドの最大数でカーネルレベルの制限に違反しました。 XNUMX秒あたりの一意のモデル呼び出し率が マルチモデルサーバー （MMS）単一のインスタンスでは、インスタンスをブラウンアウトすることなく安全に処理できます。 これは、ますます小さなインスタンスを使用することで解決された別の問題でした。

あらゆる実稼働アプリケーションの重要なコンポーネントである可観測性の観点から、 アマゾンクラウドウォッチ 呼び出し、CPU、メモリ使用率などのメトリック、およびメモリにロードされたモデル、モデルのロード時間、モデルのロード待機時間、モデルのキャッシュヒットなどのマルチモデル固有のメトリックは有益です。 具体的には、モデルのレイテンシーの内訳は、Zendeskがコールドスタートの問題とその影響を理解するのに役立ちました。

MME自動スケーリングの内部

次の図に示すように、各マルチモデルエンドポイントの背後には、モデルホスティングインスタンスがあります。 これらのインスタンスは、モデルへのトラフィックパターンに基づいて、メモリとの間で複数のモデルをロードおよび削除します。

SageMakerは、モデルの推論リクエストを、キャッシュされたモデルコピーからリクエストが処理されるように、モデルがすでにロードされているインスタンスにルーティングし続けます（次の図を参照してください。これは、最初の予測リクエストとキャッシュされた予測リクエストのリクエストパスを示しています。道）。 ただし、モデルが多くの呼び出しリクエストを受信し、マルチモデルエンドポイントに追加のインスタンスがある場合、SageMakerは増加に対応するために一部のリクエストを別のインスタンスにルーティングします。 SageMakerで自動化されたモデルスケーリングを利用するには、次のことを確認してください。 インスタンスの自動スケーリングの設定 追加のインスタンス容量をプロビジョニングします。 カスタムパラメーターまたはXNUMX分あたりの呼び出し数（推奨）を使用してエンドポイントレベルのスケーリングポリシーを設定し、エンドポイントフリートにインスタンスを追加します。

MMEに最適なユースケース

SageMakerマルチモデルエンドポイントは、共有サービングコンテナーを介してサーブでき、すべてのモデルに同時にアクセスする必要がない、多数の同様のモデルをホストするのに適しています。 MMEは、サイズと呼び出しの待ち時間が類似しているモデルに最適です。 モデルサイズの多少の変動は許容されます。 たとえば、Zendeskのモデルの範囲は10〜50 Mbで、これは正常に機能しますが、10、50、または100倍のサイズのバリエーションは適切ではありません。 モデルが大きくなると、十分なメモリスペースに対応するために、小さいモデルのロードとアンロードの数が増える可能性があり、その結果、エンドポイントでの遅延が増える可能性があります。 大規模なモデルのパフォーマンス特性の違いにより、CPUなどのリソースが不均一に消費され、インスタンス上の他のモデルに影響を与える可能性があります。

MMEは、共有コンテナーを使用して複数のモデルを読み込むため、同じMLフレームワークを使用するモデルを共同ホスティングするためにも設計されています。 したがって、モデルフリートにMLフレームワーク（PyTorchやTensorFlowなど）が混在している場合は、SageMaker専用エンドポイントまたはマルチコンテナーホスティングの方が適しています。 最後に、MMEは、頻繁に呼び出されるモデルを優先して、使用頻度の低いモデルをオフロードできるため、時折のコールドスタート遅延ペナルティを許容できるアプリケーションに適しています。 アクセス頻度の低いモデルのロングテールがある場合、マルチモデルエンドポイントはこのトラフィックを効率的に処理し、大幅なコスト削減を可能にします。

まとめ

この投稿では、SaaSとマルチテナンシーがMLにどのように関連しているか、SageMakerマルチモデルエンドポイントがML推論のマルチテナンシーとコスト効率をどのように実現するかを学びました。 Zendeskの顧客ごとのMLモデルのマルチテナントのユースケースと、SageMaker MMEで提案されたマクロ機能のために何千ものMLモデルをホストし、専用のエンドポイントと比較して推論で90％のコスト削減を達成した方法について学びました。 ハイパーパーソナライズのユースケースでは、数千のMLモデルが必要になる可能性があり、このユースケースではMMEが費用効果の高い選択肢です。 今後もMMEの機能を強化して、低レイテンシでモデルをホストできるようにし、パーソナライズされたモデルごとにさらにきめ細かく制御できるようにします。 MMEの使用を開始するには、を参照してください。 XNUMXつのエンドポイントの背後にあるXNUMXつのコンテナで複数のモデルをホストする.

---

著者について

サイードジャフリー AWSのシニアソリューションアーキテクトです。 彼は、中規模の組織から大企業、金融サービスからISVまで、さまざまな企業と協力して、クラウドでの安全で復元力のあるスケーラブルで高性能なアプリケーションの構築と運用を支援しています。

ソウミャ・マヌサニ Zendeskのシニアスタッフ機械学習エンジニアです。 彼女は、何千ものZendeskEnterpriseの顧客のエージェントの生産性の向上に焦点を当てたNLPベースの機械学習機能の生産化に取り組んでいます。 彼女は、何千ものパーソナライズされたモデルの自動トレーニングパイプラインを構築し、安全で復元力があり、スケーラブルで高性能なアプリケーションを使用してそれらを提供した経験があります。 自由時間には、パズルを解いたり、絵を描いたりするのが好きです。

サウラブ・トリカンデ はAmazonSageMakerInferenceのシニアプロダクトマネージャーです。 彼は顧客と協力し、機械学習をより利用しやすくすることに情熱を注いでいます。 余暇には、ハイキングを楽しんだり、革新的なテクノロジーについて学んだり、TechCrunchをフォローしたり、家族と過ごしたりしています。

ディープティ・ラガ は、AmazonSageMakerチームのソフトウェア開発エンジニアです。 彼女の現在の仕事は、機械学習モデルを効率的にホストする機能の構築に焦点を当てています。 余暇には、旅行、ハイキング、植物の栽培を楽しんでいます。

• コインスマート。 ヨーロッパで最高のビットコインと暗号通貨取引所。
• Platoblockchain。 Web3メタバースインテリジェンス。 知識の増幅。 出入り自由。
• CryptoHawk。 アルトコインレーダー。 無料トライアル。
• ソース：https：//aws.amazon.com/blogs/machine-learning/how-to-scale-machine-learning-inference-for-multi-tenant-saas-use-cases/