本人確認のJumio、AWSでリアルタイム特徴量ストアを刷新　P95で16.9msの低遅延と年12万ドルの削減を達成

要点

• 本人確認サービスのJumioが、AWSを活用したリアルタイム特徴量ストアの構築事例を公開した。

• Amazon Kinesis Data Streams、Apache Flink、Amazon SageMaker Feature Storeによるストリーミング設計を採用した。

• 不正検知に求められる100ミリ秒未満の要件に対し、95パーセンタイル（P95）で16.9ミリ秒の低遅延を達成した。

• 特徴量の一元化とインメモリストアの活用により、手動実装を自動化し、年間約12万ドルの運用コストを削減した。

• 本人確認および不正検知プラットフォームを提供する米Jumio（ジュミオ）が、AWS上に構築したリアルタイム特徴量ストア（機械学習モデルの推論に必要なデータを一元管理・配信する基盤）のアーキテクチャを、2026年8月18日付のAWS Machine Learning Blogで明らかにした。同社はAmazon SageMaker Feature StoreやAmazon Managed Service for Apache Flinkを導入し、不正検知モデルへの特徴量供給を高速化した。従来の分散管理や手動実装に伴う課題を解決し、厳格なリアルタイム要件を満たしながら大幅なコスト削減を実現したという。

データの重複と手動再実装が開発の足かせに

Jumioのサービスでは不正検知の即時性と精度が重視されるが、以前はチームごとにオフライン特徴量ストアを個別運用していたため、データの重複や定義の不一致が生じていた。また、オフラインで検証した特徴量を本番コード（JavaやPython）へ手作業で再実装しており、適用までに数週間を要する上にバグの原因にもなっていた。さらに、審査長期化による遅延イベントの処理や、上流モデル出力への即時アクセスも困難だった。これらを解決するため、100ミリ秒未満の低遅延配信、柔軟なスキーマ拡張、イベント時間に基づく特徴量生成、モデル再学習用の準リアルタイム取り込み、そして開発プロセスの自動化を満たす統合基盤が求められていた。

リアルタイムとオフラインを統合したストリーミング設計

新基盤はストリーミングファーストの設計で、米国東部、欧州、アジアパシフィックの3つのAWSリージョンに展開されている。
リアルタイム系統では、Amazon Kinesis Data StreamsからのイベントをAmazon Managed Service for Apache Flinkで即座に変換・加工し、Amazon SageMaker Feature Storeへ直接書き込む。同ストア内では、頻繁に参照される最新データをAmazon ElastiCache for Valkeyによるインメモリストア（Hotデータ）で保持して低遅延化を図り、参照頻度の低いデータ（Coldデータ）は標準ストアに格納する階層化戦略をとった。
一方、モデル学習や分析を担うオフライン系統では、Flinkの出力をAmazon Data Firehose経由でAmazon S3へ転送し、AWS LambdaとAmazon EMR Serverlessを連携させてApache Iceberg形式のテーブルを更新する。これにより、Amazon Athenaなどから準リアルタイムにデータへアクセスできる構成を整えた。

16.9ミリ秒の応答速度を達成、年間12万ドルのコストを削減

性能面では、不正検知のSLA（サービス品質保証）である100ミリ秒未満を大幅にクリアした。実測におけるレスポンス時間の95パーセンタイル（P95）は16.9ミリ秒を記録し、中央値（P50）は読み取りが8.44ミリ秒、書き込みが18.6ミリ秒となった。
運用面でも、数週間を要していた本番適用が自動化・一元化され、遅延イベントの処理や上流モデルへのリアルタイムアクセスが可能になった。さらに、SageMaker Feature Storeのインメモリストアを活用した最適化により、以前の分散型ストア運用と比較して年間約12万ドルの運用コスト削減を達成したと報告されている。

技術選定の評価とパイプラインの監視

技術選定において同社は各要素の長短を評価している。SageMaker Feature Storeは運用の手間を抑えて低遅延を実現できる一方、最適化を怠るとコスト要因になり得る。Apache Flinkは突発的な高トラフィックでも強力な処理が可能な反面、学習コストや運用難易度が高い。また、多様なAWSサービスの連携は高拡張性と堅牢性をもたらすが、統合の複雑さやAWSの専門知識が求められる点を考慮したとしている。
安定運用のために監視体制も構築されており、KinesisからFeature Storeまでの各区間レイテンシ、FlinkのKPU（Kinesis Processing Unit）使用率やバックプレッシャー時間、Feature Storeの読み書き遅延やタイムアウト率、FirehoseのS3配信成功率などが常時トラッキングされている。