メインコンテンツまでスキップ

GCP に BYOC-I をデプロイ

このページでは、GCP Virtual Private Cloud (VPC) に BYOC agent を使用して Bring-Your-Own-Cloud (BYOC) データプレーンをデプロイする方法を説明します。

📘注意

  • Zilliz BYOC は現在 General Availability で利用可能です。アクセス方法および実装の詳細については、Zilliz Cloud support にお問い合わせください。

  • このガイドでは、GCP コンソール上で必要なリソースを段階的に作成する方法を示します。Terraform スクリプトを使用してインフラストラクチャをプロビジョニングしたい場合は、Terraform Provider を参照してください。

前提条件​

以下を確認してください。

  • あなたが BYOC-I organization の所有者であること。

  • Required permissions に記載されている権限が付与されていること。

適用可能な VPC リージョン​

次の表は、Zilliz Cloud BYOC ソリューションがサポートする Google Cloud Platform (GCP) リージョンを示しています。Zilliz Cloud コンソール上にご利用のクラウドリージョンが見つからない場合は、support@zilliz.com までお問い合わせください。

大陸

リージョン

場所

北米

us-west1

米国オレゴン

us-east4

米国バージニア

us-central1

米国アイオワ

ヨーロッパ

europe-west3

ドイツ、フランクフルト

アジア

asia-southeast1

シンガポール

手順​

ステップ 1: デプロイ環境を準備する​

デプロイ環境とは、Terraform 構成ファイルを実行して BYOC-I プロジェクトのデータプレーンをデプロイするように構成されたローカルマシン、仮想マシン (GCE)、または CI/CD パイプラインのことです。このステップでは、以下を行う必要があります。

  • GCP 認証情報（GCP service account または access key）を構成する。

    GCP 認証情報の構成方法の詳細については、こちらのドキュメントを参照してください。

  • 最新の Terraform バイナリをインストールする。

    Terraform のインストール方法の詳細については、こちらのドキュメントを参照してください。

ステップ 2: プロジェクトを作成する​

BYOC-I organization 内で Create Project ボタンをクリックしてデプロイを開始します。表示されたダイアログボックスで Zilliz BYOC Project Name を設定し、Create and Next をクリックします。

このステップの最後にプロジェクトが作成され、Deploy Data Plane ダイアログボックスにリダイレクトされます。

TU8UwHbqjh7ZXRb7dDLcxd4ynQh

ステップ 3: データプレーンを準備する​

1

Data Plane Name と Cloud Region を設定し、Next をクリックします。

Cancel をクリックするとデータプレーンのデプロイを停止します。ただし、上記で作成したプロジェクトは引き続き利用可能です。プロジェクト内ではいつでもデータプレーンのデプロイを開始でき、1 つのプロジェクトに複数のデータプレーンを追加できます。

LMSYw1erBhDRh6bN0QUc17VDndb

2

GCP Private Service Connect (PSC) を有効にするかどうかを決定します。

このオプションを使用すると、現在のプロジェクト内の cluster へのプライベート接続が可能になります。このオプションを有効にした場合、プライベート接続のために Private Service Connect Endpoint を作成する必要があります。詳細については、Prepare for Cluster Connection を参照してください。

3

Architecture で、アプリケーションに一致するアーキテクチャタイプを選択します。

これにより、使用する Zilliz BYOC イメージのアーキテクチャタイプが決まります。利用可能なオプションは X86 と ARM です。

4

Resource Settings では、以下を行う必要があります。

  1. Auto-scaling を有効または無効にして、プロジェクトのワークロードに基づき、定義された範囲内で GCE インスタンス数を Zilliz Cloud が自動的に調整できるようにし、効率的なリソース利用を確保します。

  2. Initial Project Size を構成します。

    BYOC プロジェクトでは、query node、index services、Milvus コンポーネント、および依存関係で異なる種類の GCE インスタンスを使用します。これらのサービスおよびコンポーネントごとに、インスタンスタイプと数を個別に設定できます。

    Auto-scaling が無効な場合は、各プロジェクトコンポーネントに必要な GCE インスタンス数を、対応する Count フィールドに指定するだけです。

    IHQ6wjryihsQS0b8ABEcVsAVn4f

    Auto-scaling を有効にすると、対応する Min および Max フィールドを設定することで、実際のプロジェクトワークロードに基づいて Zilliz Cloud が GCE インスタンス数を自動スケーリングするための範囲を指定する必要があります。

    OaihwHBQshYxlWbvRpucpKMXnfc

    リソース設定を容易にするために、事前定義された 4 つのプロジェクトサイズオプションがあります。次の表は、これらのプロジェクトサイズオプションと、そのプロジェクト内で作成可能な cluster 数、およびそれらの cluster に含められる entity 数の対応関係を示しています。

    サイズ

    最大 Cluster 数

    最大 Entity 数（百万）

    Performance-optimized CU

    Capacity-optimized CU

    Tiered-storage CU

    Small

    8 ～ 16 CU の cluster を 3 つ

    1600 万 - 3200 万

    6400 万 - 1 億 2800 万

    3 億 2000 万 - 6 億 4000 万

    Medium

    16 ～ 64 CU の cluster を 7 つ

    3200 万 - 1 億 2800 万

    1 億 2800 万 - 5 億 1200 万

    6 億 4000 万 - 26 億

    Large

    64 ～ 192 CU の cluster を 12 つ

    1 億 2800 万 - 3 億 8400 万

    5 億 1200 万 - 15 億

    26 億 - 77 億

    X-Large

    192 ～ 576 CU の cluster を 17 つ

    3 億 8400 万 - 12 億

    15 億 - 46 億

    77 億 - 230 億

    Initial Project Size で Custom を選択し、すべてのデータプレーンコンポーネントの GCE インスタンスタイプと数を調整することで、設定をカスタマイズすることもできます。希望する GCE インスタンスタイプが一覧にない場合は、追加のサポートについて Zilliz support にお問い合わせください。

  3. Tiered Query Node を有効にするかどうかを決定します。

    このオプションにより、tiered-storage cluster を作成できるかどうかが決まります。このオプションを選択すると、tiered query node のインスタンスタイプと数を設定できます。

    ZOTXbgWJgoPQbox8PyYcdlwDnqe

    📘注意

    • Project Size での選択は、Tiered Storage Node の設定には影響しません。

    • Auto-scaling が無効な場合、Default Query Node の数と Tiered Query Node の数の合計は正の整数である必要があります。

    • Auto-scaling が有効な場合、Default Query Node と Tiered Query Node の両方の Min 値の合計は正の整数である必要があります。

    • Tiered Storage が BYOC で利用可能になる前に作成された cluster については、Tiered Storage を手動で有効にできます。詳細については、Enable Tiered Storage for Exisiting Clusters を参照してください。

5

Next をクリックします。

ステップ 4: データプレーンをデプロイする​

ダイアログに表示される手順に従って、現在作成したプロジェクトのデータプレーンをデプロイします。

B6RbbG77do1gq7xqK1xc2BzAnYc

terraform apply を実行する際は、以下のようにコマンドの末尾に -var="gcp_project_id=xxx" を追加する必要がある点に注意してください。

shell
terraform apply \
  -var="dataplane_id=zilliz-byoc-gcp-us-west1-74xxxx" \
  -var="project_id=project-xxxxx" \
  -var="gcp_project_id=YOUR_GCP_PROJECT_ID"

上記 Terraform スクリプトの実行方法の詳細については、Zilliz Cloud BYOC-I Project Setup Guide を参照してください。

プロジェクトのデータプレーンをデプロイして cluster を作成した後は、直接 VPC アクセスまたは GCP PSC を通じてこれらの cluster に接続できます。詳細については、Prepare for Cluster Connection を参照してください。

データプレーンを管理する​

QT8cbuzztosfjUxLLUycQpvAnyg

Undeploy タグが付いたデータプレーン​

プロジェクトカードの右隅にあるステータスタグが Undeploy と表示されている場合、プロジェクトカード上の Deploy Data Plane ボタンをクリックしていつでも再度開くことができます。プロジェクト名の変更または削除を行うには、プロジェクトカード内の ... ボタンをクリックし、ドロップダウンメニューから Rename または Delete を選択します。

Deploying タグが付いたデータプレーン​

デプロイ環境を準備し、表示されたコマンドを実行した後は、BYOC agent がアクティブになるまで待つ必要があります。プロジェクトカード上のステータスタグが Deploying と表示され、進捗率が表示されている間は、データプレーンの配置が完了するまでプロジェクト名の変更や削除はできません。

Running タグが付いたデータプレーン​

プロジェクトカード上のステータスタグが Running と表示されたら、そのプロジェクト内で cluster の作成を開始できます。実行中のプロジェクトの名前を変更または削除するには、プロジェクト内に cluster が存在しないことを確認してください。

テクニカルサポートアクセス​

トラブルシューティングおよび保守作業を支援するため、Zilliz Cloud はデフォルトでテクニカルサポートがプロジェクトのデータプレーンへアクセスできるようにしています。ガバナンスおよびセキュリティ要件を満たすために、これを無効にすることもできます。

次の手順では、Zilliz Cloud テクニカルサポートが特定された問題について連絡してきた際に、無効化した後で再びテクニカルサポートアクセスを有効にする方法を示します。

1

Zilliz Cloud がデータプレーン上の問題を特定し、あなたがテクニカルサポートアクセスを無効にしている場合、当社はそのことを通知し、テクニカルサポートアクセスを申請します。

2

対象のデータプレーンを見つけ、データプレーンカードの右下にある ... をクリックし、ドロップダウンリストから Technical Support Access をクリックします。

TKIEwRBp0hpQL5btdvwccQGKngZ

3

表示されたダイアログボックスで、Technical Support Access をオンにします。

SLmCwHdrNhJiw3bzf9kc5gB4nAb

4

すると、当社がアクセスを申請する理由と、Zilliz Cloud によって割り当てられた issue owner の ID に関する情報が表示されます。Expected Duration でアクセス期間を決定し、Description に任意の要件を入力できます。すべて設定したら、Save をクリックします。

D8X5w8TZQhkN51bpoqHc09o0nue

5

トラブルシューティング中にダイアログボックスを開くと、このアクセスの終了時刻が表示されます。テクニカルサポートアクセスは、有効期限が切れるか、あなたが明示的に無効化すると再び無効になります。

HL1OwXlTihXk9PbzvjbchIp0n3f

必要な権限​

このセクションでは、GCP に BYOC-I をデプロイするために必要な主要な権限をすべて確認できます。

必要な API​

GCP BYOC-I データプレーンをデプロイするには、顧客の GCP プロジェクトで以下の API を有効にする必要があります。

  • Cloud Resource Manager API: cloudresourcemanager.googleapis.com

  • Artifact Registry API: artifactregistry.googleapis.com

  • Compute Engine API: compute.googleapis.com

  • Kubernetes Engine API: container.googleapis.com

  • IAM API: iam.googleapis.com

  • Cloud Storage API: storage.googleapis.com

  • Service Usage API: serviceusage.googleapis.com

Terraform Runner の権限​

Terraform runner には、顧客の GCP プロジェクト内で networking、GKE、GCS、IAM、Private Service Connect、および一時的な booter VM リソースを作成するための十分な権限が必要です。

標準の Terraform 例では、Terraform runner に対して、対象の GCP プロジェクト上で以下のロールと同等の権限を付与してください。

  • roles/serviceusage.serviceUsageAdmin

  • roles/compute.networkAdmin

  • roles/compute.instanceAdmin.v1

  • roles/container.admin

  • roles/storage.admin

  • roles/iam.serviceAccountAdmin

  • roles/iam.roleAdmin

  • roles/resourcemanager.projectIamAdmin

  • roles/iam.serviceAccountUser

デフォルトでは、この例は vendor=zilliz-byoc の Resource Manager タグも有効にします。Resource Manager タグが有効な場合、Terraform runner にはさらに以下も必要です。

  • roles/resourcemanager.tagAdmin

  • roles/resourcemanager.tagUser

Terraform runner が Resource Manager タグを管理できない場合は、事前に作成されたタグ ID を vendor_tag_key_id と vendor_tag_value_id で指定するか、以下を設定してください。

plaintext
enable_resource_manager_tags = false

Terraform によって作成される Service Account​

Terraform の例では、顧客側に 4 つの service account を作成します。

  • GKE node service account

  • Maintenance service account

  • Storage service account

  • Booter service account

GKE Node Service Account​

GKE node service account は、BYOC-I データプレーン用に作成される GKE node pool にアタッチされます。その権限は GKE node のランタイム動作のために付与されるものであり、cloud-agent やその他の Zilliz 管理の agent ワークロードのためではありません。

Terraform の例では、以下を付与します。

  • roles/container.defaultNodeServiceAccount。対象の BYOC-I GKE cluster に対して IAM 条件でスコープ設定されます。

  • roles/logging.logWriter。node レベルのログ書き込み用。

  • roles/monitoring.metricWriter。node レベルのメトリクス書き込み用。

この service account は、GKE node pool 上で node VM service account として構成されます。Zilliz はこの service account を偽装せず、BYOC-I agent もこれをアプリケーション ID として使用しません。

メンテナンス Service Account​

メンテナンス service account は、お客様側の service account であり、GKE にデプロイされた Agent service が、アップグレードやスケーリングなどのメンテナンス操作に使用します。Zilliz Cloud は、お客様が許可しない限り、この service account を impersonate することも、お客様の GKE にアクセスすることもありません。

Terraform の例では、この service account に以下を付与します。

  • container.clusters.get および container.clusters.update を含むカスタム cluster maintenance ロール。IAM condition により対象の BYOC-I GKE cluster にスコープされます。

  • container.operations.get および container.operations.list を含むカスタム operation viewer ロール。対象の GKE ロケーションにスコープされます。

  • resourcemanager.projects.get を含むカスタム project reader ロール。

  • GKE node service account に対する roles/iam.serviceAccountUser。これにより、メンテナンスワークフローは設定済みの node identity を使用して対象 node pool を操作できます。

Zilliz BYOC organization service account には、この maintenance service account に対してのみ roles/iam.serviceAccountTokenCreator が付与されます。GKE node、storage、または booter service account を impersonate する権限は付与されません。

enable_direct_mig_resize = true の場合、Terraform の例では、GKE 管理の instance group を直接リサイズするためのオプションのカスタムロールも maintenance service account に付与します。

  • compute.instanceGroupManagers.get

  • compute.instanceGroupManagers.update

  • compute.zoneOperations.get

このオプションロールは、IAM condition により対象 cluster の GKE 管理 instance group にスコープされます。

Storage Service Account​

storage service account は、GKE Workload Identity を通じて BYOC-I GCS bucket へのアクセスが必要な Kubernetes ワークロードで使用されます。

Terraform の例では、この service account に以下を付与します。

  • roles/storage.objectAdmin。IAM condition により BYOC-I GCS bucket にスコープされます。

  • roles/storage.bucketViewer。IAM condition により BYOC-I GCS bucket にスコープされます。

  • ブートストラップ中に使用される固定の BYOC-I Kubernetes service account に対する roles/iam.workloadIdentityUser。

  • 対象 GKE cluster の Workload Identity principal set に対する roles/iam.workloadIdentityUser。これにより、後で作成されるランタイム instance namespace と service account が storage identity を使用できます。

storage service account は、Zilliz BYOC organization service account によって直接 impersonate されることはありません。アクセスは、お客様の GKE cluster で実行されるワークロードからの GKE Workload Identity を介して仲介されます。

Booter VM 権限​

GCP BYOC-I は、プライベート GKE cluster に cloud-agent をインストールするために、短期間のみ存在する booter VM を使用します。booter VM は専用の booter service account を使用します。

booter service account には、以下を行うためのスコープ付き権限が付与されます。

  • GKE cluster の認証情報を取得する。

  • cloud-agent に必要な Kubernetes リソースを作成および更新する。

  • ブートストラップ中に rollout status と pod logs を読み取る。

  • ブートストラップ後に、設定された booter VM のみを削除する。

Resource Manager タグが有効な場合、booter の自己削除権限はさらに vendor=zilliz-byoc タグによって制限されます。

Contact Sales
Ctrl I