「支払う」をタップした直後の数ミリ秒間に起きていること

レジの前に立ち、カードをタッチします。小さなローディング画面がコンマ数秒ほど表示された後、「承認されました」と表示されます。あるいは、承認されないこともあります。

そのわずかな間に、この請求があなた自身によるものか、それとも6か月前のデータ漏洩でカード番号を盗んだ他人によるものかを、何かが判断しなければなりません。その「何か」は、あなたの支出パターン、1日の利用限度額、海外での購入を許可しているかどうかなど、あなたに関する情報を把握している必要があります。しかも、あなたが気づかないほど一瞬で、それらすべてを行う必要があります。

このブログ記事では、Databricks上でその「何か」を構築するとどうなるかをご紹介します。2つのプラットフォーム機能を組み合わせたサンプルアプリケーションである「retail-app」（FastAPIバックエンド、Reactフロントエンド、Databricks Appとしてデプロイ）を例に説明します。

• ルート最適化に対応したModel Serving：デプロイされたモデルへのより高速なネットワークパスを提供します。
• Lakebase：モデルが予測時に必要とするプロファイルデータや特徴量データのためのマネージドPostgresです。オートスケーリング機能を備えているため、データベースが新たなボトルネックになることなく、需要に合わせて拡張できます。

完全なリポジトリはGitHubで公開されています。フォークしてご自身のワークスペースにデプロイし、実際に「支払う」ボタンをタップしてみてください。

フロー：トランザクション時に実際に起きていること

コードを見る前に、1回の決済の流れをシンプルに説明します。2つのチェックが順番に実行されます。まずモデルが請求をスコアリングし、次にアプリがプロファイルルールをチェックします。どちらか一方でも満たさない場合、トランザクションは拒否されます。

結果にかかわらずレイテンシの数値を取得したいため、まずモデルが実行されます。次に、プロファイルのルックアップ（1日の支出上限、海外トランザクションの切り替え、居住国）が行われ、いくつかのif文に渡されます。レスポンスにはすべてのステップの所要時間が含まれているため、ミリ秒単位でどこに時間がかかったかを正確に把握できます。

プロファイルの更新（1日の限度額の変更、海外トランザクションの切り替えなど）は、別の処理として行われます。データベースに変更を保存すると、次回の決済からそれが適用されます。再デプロイやキャッシュの無効化は必要ありません。

ルート最適化：ネットワークパスが重要な理由

モデルがDatabricks Model Servingの背後にデプロイされている場合、アプリケーションと推論コンテナの間にネットワークホップが発生します。バッチワークロードであれば、リクエストあたり数ミリ秒の追加は問題になりません。しかし、決済体験においては、その数ミリ秒がすべてを左右します。

ルート最適化は、そのネットワークパスを短縮します。エンドポイントでルート最適化を有効にすると、Databricks Model Servingは推論リクエストのネットワークパスを改善し、クライアントとモデル間のより高速で直接的な通信を実現します。この最適化されたルーティングにより、最適化されていないエンドポイントと比較して、より高い1秒あたりのクエリ数（QPS）が実現し、アプリケーションのレイテンシがより安定し、低減されます。

ルート最適化はエンドポイントの作成時に有効にし、パーソナルアクセストークンではなくOAuthを使用してデータプレーンフロー経由でクエリを実行します。同じ計算リソースでより低いレイテンシと高いスループットを得られるため、インタラクティブな不正利用スコアリングのユースケースに最適です。

サンプルアプリでは、エンドポイントはfraud-detection-lakebaseと呼ばれます。以下は、定数とそれを呼び出す関数です。

注目すべき点がいくつかあります。

• **serving_endpoints_data_plane.query**：これはデータプレーンのクエリパスであり、ルート最適化で使用されるものです。Databricks SDKがバックグラウンドでOAuthトークンの交換を処理します。
• **asyncio.to_thread**：SDKのクエリメソッドは同期処理です。to_threadでラップすることで、モデルの実行中もFastAPIのイベントループを解放した状態に保ちます。
• **dataframe_records**：ペイロードは辞書のリスト（1行につき1つ）です。不正利用スコアリングでは、一度に1つのトランザクションを送信します。

モデル自体はfraud_probability、fraud_flag、そして（極めて重要な）モデル独自の内部処理時間であるlookup_ms（モデルコンテナ内での特徴量ルックアップの所要時間）、inference_ms（CatBoostの予測）、およびtotal_msを返します。バックエンドはこれらをマッピングし、フロントエンドでレイテンシのウォーターフォール図を表示できるようにします。

したがって、UIでレイテンシの内訳（「Model Inference: 45ms」の下に「Feature Lookup: 8ms」がネストされている状態）が表示される場合、それらは各レイヤーで測定され、1つのレスポンスにまとめられた数値です。

設定方法の詳細については、以下を参照してください：ルート最適化 · ルート最適化されたエンドポイントへのクエリ実行

Lakebase：モデルが必要とするデータのためのPostgres

不正利用モデルは、トランザクションだけを単独で見るわけではありません。クレジットカードの最初の6桁（BIN）をルックアップキーとして使用し、顧客の過去の特徴量（平均取引額、国境を越えた取引の割合、チャージバック率、過去24時間の取引頻度）を検索します。これらの特徴量は、customer_featuresという名前のLakebase Postgresテーブルに格納されています。

これは、バックエンドがプロファイルデータ（名前、1日の限度額、海外取引の切り替え）を読み取るのと同じテーブルです。1つのテーブルに対して2つの読み取り元が存在します。モデルコンテナは推論用の特徴量を読み取り、FastAPIアプリはビジネスルール用のプロファイルフィールドを読み取ります。

読み取り側では、バックエンドがプールから接続を借用し、user_idによるパラメータ化されたSELECTを実行し、finallyブロックで接続を返却します。シンプルなpsycopg2ですが、すべてのトランザクションで実行されるため、この借用と返却のルールが重要になります。クエリはユーザー入力に対してパラメータ化されたプレースホルダーを使用するため、ルックアップキーがSQLに直接結合されることはありません。

書き込み側では、ユーザーがUIで1日の限度額を変更したり、海外トランザクションを切り替えたりすると、バックエンドは編集可能な列の許可リストから動的なUPDATEを構築します。そのリストにあるフィールドのみが書き込まれるため、クライアントが任意の列名を注入することはできません。書き込みはautocommit = Trueで実行されるため、変更はすぐに反映されます。バッチのフラッシュやキャッシュの無効化を待つことなく、次のトランザクションで更新された限度額が即座に適用されます。

接続プールとOAuthトークンのローテーション

このアプリのすべてのトランザクションは、Lakebaseに少なくとも2回アクセスします。1回はモデルコンテナ内での特徴量ルックアップのため、もう1回はバックエンドでのプロファイルチェックのためです。毎回新しい接続を開くと、リクエストごとにTCPハンドシェイクとTLSネゴシエーションが発生し、呼び出しごとに20〜50ミリ秒のオーバーヘッドが容易に追加されてしまいます。接続プールを使用すると、いくつかの接続を開いた状態で待機させることができるため、ほとんどのリクエストは接続を取得してすぐに実行できます。

実際の動作は以下のようになります。すべてのデータベース操作は、同じ「借用、クエリ、返却」のパターンに従います。

コネクションを取得し、クエリを実行し、エラーが発生した場合でも常に返却されるように finally ブロック内でコネクションを返却します。アプリ内のすべての読み取りと書き込みは、これと同じパターンに従います。

プール自体は3〜10個のコネクションを持つ psycopg2.pool.ThreadedConnectionPool です。しかし、LakebaseはOAuth経由で認証するため、プールの構築方法が興味深い部分です。アプリはサービスプリンシパルの資格情報をアクセストークンと交換し、クライアントIDをPostgresのユーザー名として、トークンをパスワードとして使用します。有効期限の長いデータベースパスワードは不要です。

つまり、トークンの期限が切れた場合、プールされたコネクションで古いパスワードを使い続けることはできません。次のクエリで失敗してしまうからです。そのため、_ensure_pool はトークンが変更されたかどうかを確認し、変更されている場合は新しいプールを構築します：

ほとんどの場合、高速なパスが実行されます。プールが存在し、トークンが変更されていなければ、すぐに処理を返します。トークンがローテーション（更新）されると、ダブルチェックロッキングによって2つのスレッドが同時にプールを再構築するのを防ぎます。また、古いプールを閉じる際の30秒のタイマーにより、実行中のクエリがコネクション消失前に完了するための時間を確保できます。

モデル側：コンテナ内での特徴量ルックアップ

不正検知モデル自体（MLflow pyfuncとしてデプロイ）は、予測時に独自にLakebaseのルックアップを行います。カードのBINを抽出し、customer_features にクエリを実行し、特徴量ベクトルを組み立てて、CatBoostの推論を実行します。各ステップの所要時間が計測されます：

モデルコンテナは、Lakebaseへの独自の ThreadedConnectionPool（fraud_model.py 内の LakebaseConnectionPool クラス）を維持し、バックグラウンドでトークンを更新することで、長期間稼働するサービングインスタンス間でもプールが有効に保たれます。これはバックエンドと同じパターン（プール ＋ OAuthローテーション）ですが、FastAPIプロセスではなくモデルコンテナの内部で実行されます。

これらの lookup_ms と inference_ms の値は、サービングレスポンス、バックエンドを経由してフロントエンドに返されます。これにより、エンドツーエンドの可視性が得られます。モデルが内部の処理時間を報告し、バックエンドが独自の実時間を追加し、ユーザーはそのすべてを確認できます。

ビジネスルール：プロフィールチェック

モデルが取引をスコアリングした後、バックエンドはLakebaseから顧客のプロフィールを読み取り、2つのシンプルなルールを実行します。1つ目は、取引金額をユーザーの1日の利用限度額と比較します。金額が上限を超える場合、取引は拒否され、プロフィールの設定で上限を引き上げることができる旨のメッセージがユーザーに表示されます。2つ目は、ユーザーが海外取引を無効にしている場合、バックエンドは取引が行われた国がユーザーの居住国と一致するかどうかを確認します。一致しない場合は拒否されます。

どちらのルールも、モデルによる承認をオーバーライド（上書き）できます。モデルが問題ないと判断した取引であっても、ユーザーが1日500ドルの上限を設定しているために拒否されることがあります。これは意図的な設計です。モデルは統計的なリスクを処理し、プロフィールはユーザーの好みを処理します。どちらも同じLakebaseテーブルから読み取りますが、目的が異なります。

プロフィールルックアップとルールチェックに費やされた時間は business_logic_ms として追跡され、モデルの処理時間とともに返されるため、ビジネスロジックが各取引にどれだけのオーバーヘッドを追加しているかを正確に把握できます。

ゼロへのスケール（Scale-to-Zero）を備えたLakebaseのオートスケーリング：需要への対応

本番環境では、Postgresインスタンスはモデルコンテナの特徴量ルックアップおよびバックエンドのプロフィール読み取りの両方を処理する必要があり、ピーク時にはそれぞれ毎秒多数の処理が発生する可能性があります。Lakebaseはオートスケーリングを行い、設定された最小/最大範囲内でコンピュートを調整するため、午前3時にピーク時の容量に対して支払う必要がなく、正午にクエリがドロップすることもありません。

以下のベンチマーク結果において、p50からp75での一貫した1桁ミリ秒のルックアップ時間は、ウォームアップされたLakebaseインスタンスが安定した負荷の下で提供するパフォーマンスを反映しています。p95での急上昇（13.9ミリ秒）は、コネクションプールの入れ替わりや一時的なスケールアップイベントに典型的なもので、チェックアウトフローのレイテンシ予算内に十分に収まっており、まさにオートスケーリングがユーザーに影響を与える前に吸収するスパイクの典型例です。ゼロへのスケール（Scale-to-Zero）を有効にすると、取引が発生していないときは課金も停止します。

まとめ：エンドツーエンドのレイテンシ内訳

以下は、単一の取引における詳細なレイテンシの全体像です：

round_trip_ms と model_total_ms のギャップはネットワークオーバーヘッドであり、これこそがルート最適化が効果を発揮する部分です。backend_total_ms と model_call_ms のギャップはフレームワークのオーバーヘッド（シリアライズ、ルーティングなど）です。

アプリを実行して取引を送信すると、UIには主要な項目（モデル推論、特徴量ルックアップ、ビジネスロジック）が表示されます。これにより、ルート最適化による違いを簡単に確認したり、Lakebaseの特徴量ルックアップが、コールド状態のデータベース接続で予想される数百ミリ秒ではなく、1桁ミリ秒しか追加しないことを確認したりできます。

結果：実際の速度は？

ルート最適化された fraud-detection-lakebase エンドポイント（CPU、「Small」ワークロードサイズ、単一のAzureリージョン）に5,000件の連続リクエスト（並行数 = 1、呼び出し間に50ミリ秒の遅延）を送信し、モデルコンテナ内から呼び出し元のラウンドトリップまで、すべてのレイヤーでレイテンシを収集しました。目的は、競合下でのスループットを負荷テストすることではなく、リクエストごとのレイテンシの構造を分離し、各レイヤー（特徴量ルックアップ、推論、ネットワークオーバーヘッド）でミリ秒がどのように消費されているかを明らかにすることでした。これらの数値は、モデルエンドポイントを直接呼び出すベンチマークスクリプト（scripts/benchmark.py）から取得したものです。UIのレイテンシ内訳は、バックエンドルート全体を通じて計測された、異なる切り口（モデル推論、特徴量ルックアップ、ビジネスロジック）を示しています。

いくつかの注目すべき点があります。

• エンドツーエンドのラウンドトリップは、中央値で27 ms、p95で37 msです。これは、呼び出し元 → ルート最適化されたデータプレーン → モデルコンテナ → Lakebaseルックアップ → CatBoost推論 → レスポンスという、全工程をカバーしています。チェックアウトフローのレイテンシバジェット内に十分に収まっています。
• 特徴量ルックアップは、p50で一桁ミリ秒（8.9 ms）です。モデルからLakebaseへの接続プールが接続をウォーム状態に維持するため、ほとんどの読み取りでTLSハンドシェイクが完全にスキップされます。p95でも、ルックアップは14 ms未満に抑えられています。
• 推論は実質的にほぼゼロです。12個の特徴量ベクトルに対するCatBoost予測は、中央値で0.4 msです。モデルの処理時間の大半は特徴量ルックアップが占めており、予測自体によるものではありません。
• ネットワークオーバーヘッドは約17 msです。モデルコンテナが報告する時間と呼び出し元が認識する時間の差は、リクエストルーティング、シリアライズ、データプレーンホップなどのサービングインフラストラクチャによるものです。ルート最適化によりこれが一貫して維持され、p50からp95の差はわずか4 msです。

ご自身でお試しください：アプリをワークスペースにデプロイする

このアプリは、apxを使用し、Databricks App（FastAPIバックエンド、Reactフロントエンド）として構築されています。次のコマンドを使用してインストールします。

また、モデルサービングエンドポイントとLakebaseインスタンスがデプロイされているワークスペースに対して、Databricks CLI認証が設定されている必要があります。

ローカルで実行するには：

ワークスペースにデプロイするには：

主なファイル：

• src/retail_app/backend/router.py: トランザクションエンドポイント、不正検知、ビジネスルール
• src/retail_app/backend/postgres.py: Lakebase接続プール、プロファイルCRUD
• model_training/fraud_model.py: 特徴量ルックアップとCatBoostを備えたMLflow pyfunc
• app.yml: デプロイ設定（uvicornエントリーポイント、環境変数）

関連ドキュメント

• Model Serving：ルート最適化
• ルート最適化されたサービングエンドポイントのクエリ
• 本番環境向けにサービングエンドポイントを最適化する
• Lakebase (OLTP)
• Lakebaseの自動スケーリング
• Databricks Apps
• MLflowコードベースモデル
• 高QPSモデルサービングのベストプラクティス
• ソースコードのGitHubリポジトリ

不正検知スコアリング、パーソナライズ、ダイナミックプライシングなど、50ms未満のレイテンシ要件を持つリアルタイムのユースケースを、Databricks上でネイティブに構築できます。Model Servingのルート最適化とLakebaseにより、推論パスとデータパスが同一のガバナンスが効いたプラットフォーム上に配置されます。レイクハウスアーキテクチャではチェックアウトレベルのレイテンシを達成できないと以前に結論付けていた場合、ここでのベンチマーク数値（一桁ミリ秒の特徴量ルックアップを含む、エンドツーエンドの中央値27ms）は、再考に値するものです。リアルタイムのワークロードが「難しすぎる」リストに入ったままになっているなら、今こそそれを見直す絶好の機会です。ご自身のワークスペースにアプリをデプロイして、レイテンシのウォーターフォールを実際に確認し、LakebaseとDatabricks Model Servingを探索してみてください。

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