【正解】B
【0からの解説】
①前提知識：BigQuery は大量データを集計・分析するためのデータウェアハウスで、1 件ずつのキー検索をミリ秒単位で大量にさばく「オンライン サービング」用途には向きません。そこで Google Cloud には、ML 用の特徴量を管理・提供するマネージドサービスとして Vertex AI Feature Store（現 Agent Platform Feature Store）があります。現行の Feature Store は BigQuery のテーブル（またはビュー）をそのままデータソースとして登録し、「特徴ビュー（feature view）」を介してオンライン ストアへ同期します。オンライン ストアは Bigtable オンライン サービングを基盤とし、エンティティ ID（ここではユーザー ID）をキーにした低レイテンシの読み取りを提供し、ノード数の自動スケーリングにも対応しています。モデルはリクエスト時に FetchFeatureValues API を呼び出して、そのユーザーの特徴量をまとめて取得します。
②要件の整理：(1) 数百の特徴量をリクエスト時に低レイテンシで取得、(2) 特徴量の元データは BigQuery にあり、ストリーミング Dataflow で頻繁に更新、(3) 100 ms の SLA を守る、(4) 自動スケーリング、(5) 運用のオーバーヘッドを最小限に。
③正解の理由：Feature Store は BigQuery をデータソースとして直接使えるため、既存の BigQuery 上の特徴量テーブル（Dataflow が更新しているもの）をそのまま登録し、オンライン ストアへ同期（Bigtable オンライン サービングではスケジュール同期に加え継続的な同期も可能）できます。サービング基盤は Google が管理し、自動スケーリングも構成でき、取得は FetchFeatureValues API の 1 回の呼び出しで済みます。キャッシュの整合性管理やインフラのサイジングを自前で行う必要がないため、「低レイテンシ」「自動スケーリング」「運用オーバーヘッド最小」のすべてを満たします。なお、旧来の Optimized オンライン サービングは非推奨となっており、Google は Bigtable オンライン サービングへの移行を推奨しています。
【誤りの選択肢】
A：BigQueryReadClient（BigQuery Storage Read API）は、テーブルの大量データを高スループットで一括読み出しするための API です。ユーザー ID を指定した 1 件単位の高速なポイント ルックアップを行う仕組みではなく、セッション作成のオーバーヘッドもあるため、リクエストごとに呼び出すと 100 ms の SLA を満たせません。根本原因である「BigQuery をオンライン サービングに使っている」点が解消されません。
C：Memorystore for Redis は低レイテンシの読み取りは実現できますが、Dataflow パイプラインへの書き込みコンポーネントの追加・保守、キー設計、TTL や整合性の管理、インスタンスのサイジングやスケーリングなどを自前で設計・運用する必要があります。マネージドの Feature Store と比べて運用のオーバーヘッドが大きく、「運用のオーバーヘッドを最小限に」という条件に反します。
D：BI Engine は BI ツールやダッシュボードからの分析 SQL を高速化するためのインメモリ分析エンジンです。リクエストごとに大量の同時ポイント ルックアップを処理する用途向けではなく、クエリの起動やジョブ処理のオーバーヘッドも残るため、オンライン推論用の特徴量サービング レイヤとしては不適切です。
【参考】
Gemini Enterprise Agent Platform の Feature Store についてオンライン サービングのタイプオンライン ストアから特徴をサービングする