レジの前に立ち、カードをタップすると、半秒も経たないうちに「承認」または「拒否」が表示されます。その間に、システムはこの取引が本当にあなたのものか、それとも6ヶ月前のデータ漏洩でカード番号を盗まれた誰かのものかを判断しなければなりません。そのためには、あなたの支出パターン、1日の限度額、海外取引の許可設定などを瞬時に把握する必要があります。このブログ記事では、Databricks上でそのようなシステムを構築する方法を、サンプルアプリケーション（retail-app）を通して解説します。
このアプリケーションはFastAPIバックエンドとReactフロントエンドで構成され、Databricks Appとしてデプロイされます。二つのプラットフォーム機能を組み合わせています：ルート最適化を備えたModel Servingと、プロファイルや特徴量データを格納するマネージドPostgresであるLakebaseです。コードはGitHubで公開されており、自分のワークスペースにフォークしてデプロイし、実際に「支払い」を試すことができます。
取引の流れは次の通りです。まずモデルが取引をスコアリングし、次にアプリがプロファイルルール（1日の上限、国際取引の可否、居住国）をチェックします。どちらかが拒否できます。モデルが先に実行されるのは、結果に関わらずレイテンシデータを取得するためです。応答には各ステップのタイミングが含まれ、ミリ秒の内訳がわかります。プロファイルの更新（限度額変更など）は別の操作で、データベースに保存され、次回の取引から即座に反映されます。再デプロイやキャッシュ無効化は不要です。
ルート最適化はレイテンシ低減に重要です。モデルがDatabricks Model Servingにデプロイされると、アプリケーションと推論コンテナの間にネットワークホップが発生します。バッチ処理では数ミリ秒は問題になりませんが、チェックアウト体験では致命的です。ルート最適化はネットワークパスを短縮し、推論リクエストの通信をより高速かつ直接的にします。サンプルアプリでは、エンドポイント fraud-detection-lakebase をデータプレーン経由でOAuthを使ってクエリします。
Lakebaseはモデルが必要とするデータを提供します。不正検知モデルは取引単体だけでなく、カードの先頭6桁（BIN）をキーに顧客の履歴特徴量（平均取引額、クロスボーダー比率、チャージバック率、過去24時間の取引速度）を検索します。これらの特徴量は Lakebase の customer_features テーブルに格納されています。バックエンドも同じテーブルをプロファイルデータの読み取りに使用します。読み取り時はコネクションプールから接続を借り、パラメータ化されたSELECTを実行し、finallyブロックで返却します。書き込み時は、UIでユーザーが変更した項目のみを許可リストに基づいて動的UPDATE文を構築し、即座に反映されます。
コネクションプーリングとOAuthトークンローテーションはレイテンシ安定化に貢献します。各取引で少なくとも2回Lakebaseにアクセスするため、毎回新規接続では20～50ミリ秒のオーバーヘッドが生じます。プールは数本の接続を開いたまま保持し、ほとんどのリクエストは即座に接続を取得できます。LakebaseはOAuth認証を使用するため、アプリはサービスプリンシパル資格情報からアクセストークンを取得し、クライアントIDをPostgresユーザー名、トークンをパスワードとして使用します。トークンが期限切れになると、プール内の接続は再利用できなくなるため、サンプルコードでは二重チェックロッキングを用いて安全にプールを再構築し、古いプールの切断を30秒遅らせることで、実行中のクエリを完了させます。
モデルコンテナ内部も独自のLakebase接続プールを維持し、バックグラウンドでトークンをリフレッシュします。モデルは fraud_probability、fraud_flag、および内部タイミング（lookup_ms、inference_ms、total_ms）を返し、バックエンドがそれらをフロントエンドのレイテンシウォーターフォールにマッピングします。ビジネスルールはモデルスコアリング後に実行され、取引額が1日上限を超えていないか、国際取引が無効の場合に居住国と一致するかを確認します。どちらのルールもモデルの承認を覆すことができ、モデルは統計的リスクを、プロファイルはユーザー設定を処理します。
Lakebaseは自動スケーリングとゼロスケールをサポートします。本番環境では、Postgresインスタンスはモデルコンテナとバックエンドの両方からのクエリを処理する必要があります。ベンチマークでは、安定負荷時の検索時間はp50からp75で一桁ミリ秒、p95での13.9ミリ秒の跳ね上がりはコネクションプールの入れ替わりやスケールアップイベントによるもので、チェックアウトのレイテンシ予算内に収まります。ゼロスケールを有効にすると、取引がない時間は課金されません。
エンドツーエンドのレイテンシ内訳：model_call_msはサービス呼び出し全体の壁時計時間、model_lookup_msとmodel_inference_msはモデルコンテナ内の計測、business_logic_msはプロファイル読み取りとルール評価です。バックエンドの壁時計時間とモデル合計時間の差がネットワークオーバーヘッドであり、ルート最適化が特に効果を発揮する部分です。UIではモデル推論、特徴量検索、ビジネスロジックのレイテンシが表示され、ルート最適化の効果を一目で確認できます。
このサンプルアプリケーションは、ルート最適化、Lakebaseの自動スケーリング、コネクションプーリング、OAuthトークンローテーションを組み合わせることで、ミリ秒単位のリアルタイム不正検知を実現し、高可用性と低コストを両立する方法を示しています。