Databricksでの高QPSモデルサービングのベストプラクティス

顧客は、ミリ秒単位でレンダリングされるレコメンデーション、決済が完了する前にブロックされる不正請求、ユーザーが瞬時に感じられる検索結果など、あらゆるやり取りにおいて即時の応答を期待しています。大規模な環境でこれらのエクスペリエンスを提供するには、持続的かつ不均一な負荷の下でも高速で安定しており、予測可能であり続けるモデルサービングシステムが必要です。

トラフィックが毎秒数万から数十万のリクエストに増加するにつれて、多くのチームが同じ一連の課題に直面します。レイテンシーが不安定になり、インフラストラクチャのコストが増加し、需要の急増や減少に対応するためにシステムには絶え間ないチューニングが必要になります。また、より多くのコンポーネントが連携されるにつれて障害の診断はより困難になり、チームはモデルの改善から遠ざかり、代わりに本番運用システムの稼働維持に集中することになります。

この記事では、Databricksのモデルサービングが高いQPSのリアルタイムワークロードをサポートする仕組みと、本番運用で低レイテンシー、高スループット、予測可能なパフォーマンスを達成するために適用できる具体的なベストプラクティスについて解説します。

Databricks モデルサービング: 高 QPS ワークロードに対応する、シンプルでスケーラブルなサービス

Databricks Model Servingは、Databricks lakehouse内にフルマネージドでスケーラブルなサービングインフラストラクチャを直接提供します。モデルレジストリにある既存のモデルを取得してデプロイするだけで、高 QPS トラフィック向けに最適化された、拡張性の高いマネージドインフラストラクチャ上で REST エンドポイントを取得できます。

Databricks Model Servingは、ミッションクリティカルな高QPSワークロード向けに最適化されています。

• リアルタイム適応エンジン – 各モデルのワークロードに適応し、同じハードウェアでより高いスループットとリソース使用率を実現する、自己最適化型のモデルサーバーです。
• 完全水平スケーラブルアーキテクチャ – 推論サーバー、認証レイヤー、プロキシ、レートリミッターはすべて、独立してスケールアウトするように設計されており、システムが非常に高いリクエスト量を維持できるようになっています。
• 高速なエラスティックスケーリング – 推論サーバーは、オーバープロビジョニングすることなく、突然のトラフィックの急増または減少に適応して、スケールアップおよびスケールダウンできます。
• Native Feature Store Integration: Databricks Feature ServingはModel Servingとシームレスに統合されており、特徴量とモデルを1つの完全なアプリケーションとしてまとめてデプロイできます。
• レイクハウスネイティブ: お客様は、本番運用機械学習システムの特徴量、トレーニング、MLFlowによるMLOps、サービング、リアルタイムモニタリングを1つの統合スタックで一元管理でき、運用上の複雑さの軽減とデプロイの迅速化につながります。

Databricks Model Servingは、リアルタイムアプリケーションに必要な信頼性と拡張性をもって、私たちのチームが機械学習モデルをデプロイできるよう支援します。ハードウェア使用率を最大化しながら、高 QPS ワークロードを処理するように設計されています。それに加えて、Databricksは、このようなワークロードに必要な超高速なルックアップを備えたSOTAのフィーチャーストアソリューションを提供します。これらの機能により、当社の機械学習エンジニアは、モデルのパフォーマンスの改良やユーザーエクスペリエンスの向上といった、重要なことに集中できます。— Bojan Babic、リサーチエンジニア、You.com

モデルサービングで高いQPSパフォーマンスを達成するためのベストプラクティス

この基盤を構築した上で、次のステップは、特にトラフィックの増加に応じて、エンドポイント、モデル、クライアントアプリケーションを最適化し、一貫して高throughputと低レイテンシーを実現することです。以下のベストプラクティスは、毎日数百万から数十億の推論を実行する実際の顧客のデプロイをサポートするものです。

詳細については、ベストプラクティスガイドをご覧ください。

ベストプラクティス1：ルート最適化エンドポイントを使用して遅延を削減する

高スループット/QPSと低レイテンシを確保するために、ネットワークレイヤーを最適化するための重要な第一歩です。モデルサービングは、ルートが最適化されたエンドポイントを通じてこれを行います。エンドポイントでルート最適化を有効にすると、Databricks Model Servingが推論リクエストのネットワークとルーティングを最適化し、クライアントとモデル間の通信がより高速かつ直接的になります。これにより、リクエストがモデルに到達するまでにかかる時間が大幅に短縮され、推奨システム、検索、不正検知などの低遅延アプリケーションに特に役立ちます。

ベストプラクティス 2: モデルを最適化し、エンドポイントを効率化する

高スループットのシナリオでは、モデルの複雑さを軽減し、サービングエンドポイントから処理をオフロードし、適切な同時実行ターゲットを選択することで、エンドポイントを必要なコンピュート量だけで大量のリクエスト量に対応できるよう拡張できます。これにより、エンドポイントはコスト効率が高く、かつパフォーマンス目標を達成するためにスケールすることができます。

• モデルのサイズと複雑さ: より小型でシンプルなモデルは、一般的に推論時間が短縮され、QPSが向上します。モデルが大きい場合は、モデルの量子化やプルーニングなどのテクニックを検討してください。
• 前処理と後処理: 複雑な前処理と後処理のステップは、可能な限りサービングエンドポイントからオフロードします。これにより、モデルサービングendpointが推論という重要なステップのみを実行することが保証されます。
• スケーリング: 想定されるQPSとレイテンシーの要件に基づいて、プロビジョニングされた同時実行数の上限を設定します。これにより、エンドポイントがベースラインの負荷を処理するのに十分であり、最大値でピーク時の需要に対応できることが保証されます。

Databricks Model Servingを使用すると、パーソナライゼーションやレコメンデーションのような高いQPSのワークロードをリアルタイムで処理できます。これにより、私たちのブランドは、数百万人の読者にオーダーメイドのコンテンツ体験を届けるために必要なスケールとスピードを得ることができます。— オスカー・セルマ、コンデナスト社、データサイエンスおよび製品アナリティクス担当SVP

ベストプラクティス3: クライアントサイドのコードを最適化する

クライアントサイドのコードを最適化することで、リクエストが迅速に処理され、endpointのコンピュートインスタンスが完全に利用されるようになります。これにより、QPS throughputの向上、コストの削減、レイテンシの低減につながります。

• 接続プーリング: クライアント側で接続プーリングを使用して、各リクエストで新しい接続を確立するオーバーヘッドを削減します。Databricks SDKは常に接続のベストプラクティスを使用しますが、独自のクライアントを使用する必要がある場合は、接続管理戦略に注意してください。
• ペイロードサイズ：ネットワーク転送時間を最小限に抑えるため、リクエストとレスポンスのペイロードをできるだけ小さく保ちます。
• クライアント側のバッチ処理: アプリケーションが1回の呼び出しで複数のリクエストを送信できる場合は、クライアント側でバッチ処理を有効にします。これにより、予測ごとのオーバーヘッドを大幅に削減できます。

Databricks モデルサービングエンドポイント呼び出し時にリクエストをバッチ処理

無料トライアル

• Databricksモデルサービングをお試しください！機械学習モデルをREST APIとしてデプロイを開始します。
• さらに詳しく: カスタムモデルサービングについては、Databricks ドキュメントをご覧ください。
• 高QPSガイド: Databricks Model Servingでの高QPSサービングについては、ベストプラクティスガイドをご確認ください。

(このブログ記事はAI翻訳ツールを使用して翻訳されています) 原文記事