背景
オンライン推論で最もありがちなボトルネックは「特徴量の取得」です。
モデル自体は Triton Inference Server 上で GPU が回してくれるので数ミリ秒ですが、特徴量を Aurora や S3 から直接取ろうとすると 100ms〜秒単位になることも珍しくありません。
この遅延が積み重なるとユーザー体験を大きく損ないます。
そこで Feast + Redis を使って「オンライン特徴量ストア」を構築すると、5ms 以内での特徴量取得が可能になります。
実務での落とし穴と回避策
1. Redis のメモリ設計
Redis はインメモリ型なので「どの特徴量をキャッシュするか」が死活問題です。
- 全特徴量を載せるとすぐにメモリが枯渇する
- 一方で不足すると Aurora へのフェイルオーバーが発生して遅延が跳ね上がる
👉 解決策としては
- アクセス頻度の高い特徴量だけをオンラインに載せる
- Aurora などのオフラインストアと TTL（有効期限）をうまく組み合わせる
のが現実的です。
2. TTL 設定の難しさ
特徴量の鮮度はユースケース次第で大きく変わります。
- レコメンド用の「直近の購入履歴」は数分単位で更新したい
- 与信スコアのような「年収」「職業」などの静的特徴量は1日〜1週間に1回で十分
👉 Feast では TTL を特徴量ごとに細かく設定できるので、鮮度が必要なものだけ Redis に短期キャッシュ、それ以外は Aurora に任せるのが運用の肝です。
3. 書き込みレイテンシと一貫性
リアルタイムに流れてくるイベント（Kafka や Kinesis）を Flink / Spark で処理し、Redis に即座に書き込むフローを組むと、Redis には最新値があるが Aurora に反映されていない、という「一貫性のズレ」が発生します。
👉 これを避けるには
- Flink から Redis と Aurora に二重書き込みを行う
- もしくは Aurora に書き込み → Debezium で CDC（Change Data Capture）し、Redis に同期する
といった設計が有効です。
4. Redis 運用の現実
AWS では ElastiCache for Redis を選ぶのが一般的ですが、スケーリング戦略を誤ると課金が跳ねます。
- 単純なスケールアップは高コスト
- スケールアウトはシャーディング設計が必要
👉 最初は 3〜5ノードのクラスタ構成から始め、キー分布を監視しながら調整すると安定します。
まとめ
- Feast + Redis を使えばオンライン特徴量取得を 5ms 以内に抑えられる
- ただし メモリ設計・TTL・一貫性・スケーリングが実運用での落とし穴
- Aurora（永続ストア）と組み合わせ、ユースケースごとに特徴量を分離するのがベストプラクティス
💡この仕組みをしっかり設計しておくと、Django API から gRPC 経由で呼び出す際にも安定して「低遅延 × 高スループット」でモデル推論が実現できます。