決済不正判定を37ミリ秒に収めるLakebase構成

Databricksは、カード決済の不正判定をFastAPIとReactのDatabricksアプリで実装し、モデルサービングとLakebaseを組み合わせた遅延測定を公開しました。

今回のブログ記事で語られていること

処理は二段階です。まずCatBoostモデルが取引を採点し、続いてLakebaseから日次上限、国際取引の許可、居住国などのプロフィールを読み、業務ルールで最終判定します。モデルが承認しても利用者が設定した上限や国際取引条件で拒否でき、統計的リスクと明示的な利用者設定を分けています。プロフィール変更は許可リストにある列だけを更新し、次の決済から反映します。キャッシュ無効化やモデル再配備を待ちません。

モデルサービングは経路最適化を有効にし、OAuthを使うデータプレーンのクエリ経路で呼び出します。Lakebaseでは3〜10接続のThreadedConnectionPoolを使い、毎回のTCP/TLS接続による20〜50ミリ秒の負担を避けます。OAuthトークンが変わったときは二重チェック付きロックで新しい接続プールを作り、旧接続プールを30秒後に閉じて処理中の問い合わせを守ります。モデルコンテナ側も別の接続プールとバックグラウンドのトークン更新を持ち、BINをキーに平均取引額、越境比率、チャージバック、24時間頻度などを読みます。

CPUのSmallエンドポイント、単一Azureリージョンで5千件を逐次実行した結果、特徴量参照はp50 8.9ms、p95 13.9ms、推論はp50 0.4ms、全往復はp50 27.2ms、p95 37.3msでした。これは同時実行負荷試験ではなく、各層の遅延を分解する測定です。Lakebaseの自動スケーリングとゼロへの縮退は費用を抑えますが、休止後のコールドスタートや急増時の挙動をこの数値だけで判断できません。経路最適化、接続プール、トークンローテーション、層別計測を一体で設計した点が実務上の要点です。

今回のブログ記事が関係する人

低遅延の不正検知、推薦、与信などをDatabricks上で構築するML、アプリ、データベース、SRE担当者に関係します。

結局、今回のブログ記事をどう読むべきか

自社の同時実行数、ネットワーク、リージョン、コールドスタートを含めてp50/p95/p99を測ります。トークン更新、接続プール枯渇、DB scale-up、モデル失敗時に業務ルールがどのように判定するかも決めます。