JumioがAWS上にリアルタイム特徴量ストアを構築、P95 16.9msを達成

背景と課題

Jumioは本人確認サービスを提供する企業で、不正検知のために機械学習モデルをリアルタイムで運用している。従来はチームごとにオフライン特徴量ストアを持ち、特徴量定義が不統一だった。また、オフラインで学習した特徴量を本番コードへ手動で実装するため、手間やバグのリスクが生じていた。

さらに、不正検知では100ミリ秒未満の応答が求められるが、遅延が課題だった。特定のイベントは数週間遅れて到着することもあり、遅延イベントへの対応も必要だった。これらの問題を解決するため、中央集約型のリアルタイム特徴量ストアを構築した。

アーキテクチャの概要

採用されたのはストリーミングファーストの構成だ。イベントはAmazon Kinesis Data Streamsに入り、Apache Flinkが処理して特徴量を抽出し、Amazon SageMaker Feature Storeに書き込む。ホットデータはAmazon ElastiCache for Valkeyによるインメモリストアで高速に読み出し、コールドデータは標準ストアに保持する。

並行して、オフライン用のパイプラインも構築された。Firehose経由でS3に届いたデータは、Amazon EMRで処理され、Apache Icebergテーブルに格納される。これにより、モデルの再学習や分析用のバックフィルも可能になる。デプロイは自動化され、チーム間の連携もスムーズになった。

性能と成果

実際の性能指標では、読み込みレイテンシのP50が8.44ミリ秒、書き込みレイテンシのP50が18.6ミリ秒、95パーセンタイルの応答時間は16.9ミリ秒を記録した。不正検知のSLAである100ミリ秒未満を余裕で満たしている。

また、従来の分散した特徴量ストアと比べて、約12万ドルの年間運用コスト削減を達成した。特徴量の一元管理により、モデル開発の迅速化や精度向上にも寄与している。

設計上のポイント

このアーキテクチャの選択にあたっては、データベースやフレームワークのトレードオフを評価している。Amazon SageMaker Feature Storeはマネージドサービスであるため運用負荷が低いが、ストレージ最適化をしないとコストが高くなる可能性がある。Apache Flinkは複雑なイベント処理に強いが、学習曲線が高く運用複雑度も増す。

監視面では、Flinkアプリケーションの遅延やKPU使用率、Feature StoreのPUT/GETリクエスト数などを追跡している。また、データの鮮度や配信成功率も監視し、潜在的な劣化を防ぐ。基盤となる原則は、ストリーミングファースト、一元化された特徴量定義、層別ストレージ、監視、そしてクロスファンクショナルなコラボレーションだ。