次のベスト プラクティスは、さまざまなシナリオで Vertex AI Feature Store（レガシー）を計画し、使用する際に役立ちます。このガイドはすべてを網羅しているわけではありません。
複数のエンティティを一緒に記述するモデルの特徴
一部の特徴は複数のエンティティ タイプに適用される場合があります。たとえば、商品ごとのクリック数をユーザー別に計算する計算値があるとします。この特徴は、商品とユーザーのペアを一緒に記述します。
この場合、共有される特徴をまとめるため、別のエンティティ タイプを作成することをおすすめします。product-user などのエンティティ タイプを作成して、共有される特徴を含めることができます。
エンティティ ID の場合は、個々のエンティティの ID（個々の商品やユーザーのエンティティ ID など）を連結します。ただし、ID は文字列にする必要があります。このような連結したエンティティ タイプは、複合エンティティ タイプと呼ばれます。
詳細については、エンティティ タイプの作成をご覧ください。
IAM ポリシーを使用して複数のチーム間のアクセスを制御する
IAM のロールとポリシーを使用して、ユーザー グループごとに異なるアクセスレベルを設定します。たとえば、ML 研究者、データ サイエンティスト、DevOps、サイト信頼性エンジニアはすべて同じ featurestore にアクセスする必要がありますが、アクセスレベルは異なる場合があります。DevOps ユーザーは featurestore を管理する権限を必要としますが、featurestore の内容にアクセスする必要はありません。
リソースレベルの IAM ポリシーを使用して、特定の featurestore またはエンティティ タイプへのアクセスを制限することもできます。
たとえば、組織に次のペルソナが存在するとします。各ペルソナには異なるレベルのアクセス権が必要であるため、ペルソナにはそれぞれ異なる IAM 事前定義ロールを割り当てます。独自のカスタムロールを作成して使用することもできます。
| ペルソナ | 説明 | 事前定義ロール |
|---|---|---|
| ML 研究者またはビジネス アナリスト | 特定のエンティティ タイプのデータのみを閲覧するユーザー | roles/aiplatform.featurestoreDataViewer（プロジェクト レベルまたはリソースレベルで付与可能） |
| データ サイエンティストまたはデータ エンジニア | 特定のエンティティ タイプのリソースを扱うユーザー。所有するリソースについて、他のプリンシパルにアクセス権を委任できます。 | roles/aiplatform.entityTypeOwner（プロジェクト レベルまたはリソースレベルで付与可能） |
| IT または DevOps | 特定の featurestore のパフォーマンスを維持、調整する必要があるが、データにアクセスする必要はないユーザー。 | roles/aiplatform.featurestoreInstanceCreator（プロジェクト レベルまたはリソースレベルで付与可能） |
| 自動化されたデータ インポート パイプライン | 特定のエンティティ タイプにデータを書き込むアプリケーション。 | roles/aiplatform.featurestoreDataWriter（プロジェクト レベルまたはリソースレベルで付与可能） |
| サイト信頼性エンジニア | プロジェクト内の特定の featurestore またはすべての featurestore を管理するユーザー | roles/aiplatform.featurestoreAdmin（プロジェクト レベルまたはリソースレベルで付与可能） |
| グローバル（任意の Vertex AI Feature Store（レガシー）ユーザー） | ユーザーが既存の機能を表示、検索できるようにします。必要な機能が見つかった場合は、機能のオーナーにアクセス権をリクエストできます。 Google Cloud コンソールのユーザーには、Vertex AI Feature Store（レガシー）のランディング ページ、インポート ジョブページ、バッチ サービング ジョブ ページを表示するためにこのロールも必要です。 |
プロジェクト レベルで roles/aiplatform.featurestoreResourceViewer ロールを付与します。 |
バッチ インポートを最適化するためにリソースをモニタリングして適宜調整する
バッチ インポート ジョブでは、ワーカーがデータの処理と書き込みを行う必要があります。このため、featurestore の CPU 使用率が増加し、オンライン サービングのパフォーマンスに影響が出る可能性があります。オンライン サービングのパフォーマンスの維持を優先する場合は、10 個のオンライン ノードごとに 1 ワーカーを使用することから始めます。インポート中、オンライン ストレージの CPU 使用率をモニタリングします。CPU 使用率が予想よりも低い場合は、以降のバッチ インポート ジョブではワーカー数を増やしてスループットを向上させます。CPU 使用率が予想よりも高い場合は、オンライン サービング ノードの数を増やして CPU 処理能力を上げるか、バッチ インポート ワーカー数を減らします。どちらを行っても CPU の使用率を下げることができます。
オンライン サービング ノード数を増やした場合、最新の状態にしてから Vertex AI Feature Store（レガシー）のパフォーマンスが最適化されるまで 15 分ほどかかります。
詳細については、featurestore を更新するおよび特徴値を一括インポートするをご覧ください。
featurestore のモニタリングの詳細については、Cloud Monitoring の指標をご覧ください。
過去のデータをバックフィルする場合は disableOnlineServing フィールドを使用する
バックフィルは過去の特徴値をインポートするプロセスで、最新の特徴値には影響しません。この場合、オンライン サービングを無効にできます。これにより、オンライン ストアに対する変更はすべてスキップされます。詳しくは、過去のデータのバックフィルをご覧ください。
自動スケーリングを使用して負荷変動時のコストを削減する
Vertex AI Feature Store（レガシー）を幅広く使用していて、トラフィック パターンの負荷が頻繁に変動する場合は、自動スケーリングを使用して費用を最適化します。自動スケーリングを使用すると、Vertex AI Feature Store（レガシー）は、多くのノード数を維持するのではなく、トラフィック パターンを確認し CPU 使用率に応じてノード数を自動的に調整できます。このオプションは、徐々に増減するトラフィック パターンに効果的です。
自動スケーリングの詳細については、スケーリング オプションをご覧ください。
リアルタイム サービング用のオンライン サービング ノードのパフォーマンスをテストする
オンライン サービング ノードのパフォーマンスをテストすることで、リアルタイムのオンライン サービング中に featurestore のパフォーマンスを確認できます。これらのテストは、QPS、レイテンシ、API などのさまざまなベンチマーク パラメータに基づいて実行できます。オンライン サービング ノードのパフォーマンスは、次のガイドラインに沿ってテストしてください。
同じリージョンから（できれば Compute Engine または Google Kubernetes Engine で）すべてのテスト クライアントを実行する: リージョン間のホップに起因するネットワーク レイテンシによる不一致を防ぎます。
SDK で gRPC API を使用する: gRPC API は REST API よりもパフォーマンスが優れています。REST API を使用する必要がある場合は、HTTP keep-alive オプションを有効にして HTTP 接続を再利用します。そうしないと、リクエストのたびに新しい HTTP 接続が作成され、レイテンシが増大します。
より長時間のテストを実行する: より正確な指標を算出するために、より長時間（15 分以上）で最低 5 QPS のテストを実行します。
「ウォームアップ」期間を設ける: 非アクティブな状態が一定時間続いた後にテストを開始すると、接続が再確立されるまでの間にレイテンシの増加がみられる可能性があります。初期のレイテンシの増加期間を考慮して、初期データの読み取りを無視する期間を「ウォームアップ期間」として指定できます。別の方法としては、少量の人工トラフィックを一定の速度で featurestore に送信し、接続をアクティブに保つこともできます。
必要に応じて自動スケーリングを有効にする: オンライン トラフィックが徐々に増減することが予想される場合は、自動スケーリングを有効にします。自動スケーリングを選択すると、Vertex AI は CPU 使用率に基づいてオンライン サービング ノードの数を自動的に変更します。
オンライン サービングの詳細については、オンライン サービングをご覧ください。オンライン サービング ノードの詳細については、オンライン サービング ノードをご覧ください。
バッチ サービングとバッチ エクスポート中のオフライン ストレージ コストを最適化する開始時間を指定する
バッチ サービング時およびバッチ エクスポート時におけるオフライン ストレージの費用を最適化するには、batchReadFeatureValues リクエストまたは exportFeatureValues リクエストで startTime を指定します。このリクエストは、指定された startTime に基づいて、使用可能な特徴データのサブセットに対してクエリを実行します。指定しなければ、リクエストは利用可能なすべての特徴データをクエリするため、オフライン ストレージの使用料が高くなります。
次のステップ
Vertex AI 上でカスタム トレーニングされた ML モデルを実装するための Vertex AI Feature Store（レガシー）のベスト プラクティスを確認する。