Eコマース企業がリアルタイム商品レコメンデーションシステムを構築しています。SageMakerエンドポイントでの推論には「ユーザーの直近30分のクリック履歴・閲覧カテゴリ・カート内商品数」などの最新特徴量（フィーチャー）

Question

Eコマース企業がリアルタイム商品レコメンデーションシステムを構築しています。SageMakerエンドポイントでの推論には「ユーザーの直近30分のクリック履歴・閲覧カテゴリ・カート内商品数」などの最新特徴量（フィーチャー）が必要であり、これらは複数のマイクロサービスから毎秒更新されます。さらに、レコメンデーションモデル・検索ランキングモデル・価格最適化モデルの3つが同じ特徴量セットを共有利用する必要があります。推論レイテンシの要件はp99で20ms以内です。推論時の特徴量取得アーキテクチャとして最も適切なものはどれですか？

Accepted Answer

正解: SageMaker Feature StoreのOnline Storeに特徴量を書き込み、各モデルの推論時にGetRecord APIを呼び出して最新特徴量を低レイテンシで取得する。Feature Groupを定義して3モデルから共有利用する。正解：
SageMaker Feature StoreのOnline Storeに特徴量を書き込み、各モデルの推論時にGetRecord APIを呼び出して最新特徴量を低レイテンシで取得する。Feature Groupを定義して3モデルから共有利用する。

SageMaker Feature StoreのOnline Storeはインメモリベースの高速ストアで、GetRecord APIによる1桁ミリ秒台の低レイテンシアクセスが可能です。特徴量はFeature Groupという単位でスキーマ定義・バージョン管理され、複数のモデルや推論サービスから標準化されたAPIで共有利用できます。また同じFeature GroupはOffline Store（S3）とも連携しており、トレーニング時とサービング時で同一の特徴量定義を利用することでTrain-Serving Skew（訓練・推論間での特徴量計算のずれ）を防止できます。

選択肢Aは、inference.py内でリアルタイムに特徴量を計算するアプローチは推論レイテンシの増加・特徴量定義の重複・モデル間での一貫性欠如（Train-Serving Skew）を招き、複数モデルからの共有利用にも対応できません。

選択肢Cは、S3へのアクセスは通常数十〜数百msかかり、p99 20ms以内の要件を満たせません。毎リクエストのファイルダウンロードは実用的ではありません。

選択肢Dは、ElastiCacheも低レイテンシアクセスは可能ですが、ML特有のFeature Groupスキーマ管理・バージョニング・Offline Store連携・SageMakerとのネイティブ統合がなく、独自構築のコストとMLOps運用負荷が増大します。

Answer

各モデルのSageMakerエンドポイントのinference.pyに特徴量計算ロジックを直接組み込み、推論リクエスト時にAmazon DynamoDBから生データを取得してリアルタイムで特徴量を計算する — inference.py内でリアルタイムに特徴量を計算するアプローチは推論レイテンシの増加・特徴量定義の重複・モデル間での一貫性欠如（Train-Serving Skew）を招き、複数モデルからの共有利用にも対応できません。

Answer

特徴量をAmazon S3のCSVファイルに保存し、各推論リクエスト時にBoto3でS3からファイルをダウンロードして使用する — S3へのアクセスは通常数十〜数百msかかり、p99 20ms以内の要件を満たせません。毎リクエストのファイルダウンロードは実用的ではありません。

Answer

特徴量をAmazon ElastiCache for Redisに保存し、推論時にRedisから直接取得する独自の特徴量管理システムをゼロから構築する — ElastiCacheも低レイテンシアクセスは可能ですが、ML特有のFeature Groupスキーマ管理・バージョニング・Offline Store連携・SageMakerとのネイティブ統合がなく、独自構築のコストとMLOps運用負荷が増大します。

解説

解説