自動スケーリング、自動修復、イメージ更新を使用して MIG で Confidential Space ワークロードをデプロイする

1. 概要

Confidential Space（CS）は、センシティブデータを処理するための安全で証明された暗号化環境を提供します。スタンドアロン VM インスタンスに依存すると、手動オーケストレーションではミッションクリティカルなサービスに必要なスケーラビリティが不足するため、運用上のオーバーヘッドが発生します。自動オーケストレーションがないと、フリート全体で同期ローリングアップデートを実行したり、新しい OS イメージをデプロイしたりすることが技術的に困難になり、ダウンタイムが発生しやすくなります。

この Codelab では、マネージドインスタンスグループ（MIG）に Confidential Space ワークロードをデプロイする方法について説明します。また、ヘルスチェックを使用した自動修復、CPU 使用率に基づく自動スケーリング、OS イメージとワークロードの両方のローリングアップデートを有効にする方法についても説明します。

この Codelab で説明するプロセスは、ミッションクリティカルな長時間実行デプロイ用の本番環境に対応した安全な Confidential Space を設定するのに役立ちます。

学習内容

Confidential Space 用の特殊なインスタンステンプレートを作成する方法。
Google Compute Engine の使用方法、MIG とインスタンスグループの構成方法
自動修復用のファイアウォールルールとヘルスチェックを作成する方法。
テンプレートとヘルスチェックを使用してゾーン MIG を構成する方法。
MIG の自動スケーリングを設定する方法。
ワークロードイメージと Confidential Space の新しい OS イメージリリースの両方について、MIG でスクリプトを使用して OS イメージのワンクリックアップデートを設定する方法

必要なもの

課金を有効にした Google Cloud プロジェクト
テキストエディタ、Docker デプロイ、Bash スクリプトの知識
gcloud コマンドラインツールがインストールされ、認証されていること。
Compute Engine、Confidential Space、IAM、Confidential VMs、コンテナ技術、リモートリポジトリ、サービスアカウント、Cloud Run、Cloud Scheduler の基本的な知識
Confidential Space ワークロードコンテナイメージがすでにビルドされ、Artifact Registry に push されていること。

2. MIG を使用した Confidential Space の仕組み

マネージドインスタンスグループ（MIG）を使用して Confidential Space ワークロードをデプロイすると、安全なアプリケーションがより堅牢でスケーラブルになり、運用が容易になります。

本番環境サービスのセキュリティと運用上のニーズは、2 つのコンポーネント間で論理的に分割されます。Confidential Space は、高信頼実行環境（TEE）と呼ばれる高度に分離された暗号化された証明済みの環境でワークロードを実行することで、必要なセキュリティを提供します。一方、MIG は、Kubernetes と同様に、安全なアプリケーションを大規模に実行するために必要な運用機能を提供します。MIG は、単一の VM でミッションクリティカルなワークロードを実行する際に発生するリスクを排除します。単一の VM は、処理速度が遅くなる可能性や障害が発生する可能性があります。この組み合わせにより、データ保護とシステムの信頼性の両方が確保されます。このソリューションでは、ワークロードがプール内の複数の VM で実行されるため、高可用性 と自動修復 が保証されます。1 つの VM で障害が発生した場合でも、ロードバランシングと残りのインスタンスの存在により、サービスは完全に機能します。

さらに、MIG は構成可能なヘルスチェックを利用して、VM の運用ステータスを常にモニタリングします。インスタンスが異常な状態であることが判明した場合、MIG は自動的に新しい正常な VM に置き換えるため、継続的な運用が保証されます。

MIG は、自動スケーリング機能により、ユーザーに効果的なスケーラビリティを提供します。この機能により、手動操作なしで容量を自動的に管理できます。また、使用状況に基づいて容量を柔軟に追加または削除する必要がある場合にも対応できます。

最後に、MIG ではローリングアップデートによりダウンタイムなしのアップデートが可能になります。主なメリットは、基盤となる Confidential Space OS イメージまたはアプリケーションのコンテナイメージ（あるいはその両方）を「ワンクリックアップグレード」できることです。サービスダウンタイムは発生しません。MIG は、古いインスタンスを更新されたイメージを実行する新しいインスタンスに段階的に置き換えることで、この変更を管理し、デプロイ全体で常に可用性を確保します。このタイプの段階的なアップグレードをサポートするには、アプリケーションに下位互換性が必要になる場合があります。

3. Cloud リソースの設定

始める前に

Google Cloud プロジェクトを設定します。Google Cloud プロジェクトの作成の詳細については、「最初の Google プロジェクトを設定して操作する」Codelab をご覧ください。プロジェクト ID の取得方法、プロジェクト名やプロジェクト番号との違いについては、プロジェクトの作成と管理をご覧ください。
プロジェクトの課金を有効にします。
Google プロジェクトの Cloud Shell で、必要なプロジェクト環境変数を次のように設定します。

export  CURRENT_PROJECT_ID=<Google Cloud project id of current project>

プロジェクト で Confidential Computing API と次の API を有効にします。

gcloud config set project $CURRENT_PROJECT_ID
gcloud services enable \
cloudapis.googleapis.com \
container.googleapis.com \
artifactregistry.googleapis.com \
confidentialcomputing.googleapis.com \
compute.googleapis.com \
logging.googleapis.com \
run.googleapis.com \
cloudscheduler.googleapis.com

Google Cloud プロジェクトの Cloud Shell で、Confidential Space Codelab Github リポジトリのクローンを作成し、次のコマンドを使用して、この Codelab を完了するために必要な適切なスクリプトを取得します。

git clone https://github.com/GoogleCloudPlatform/confidential-space.git

ディレクトリをインスタンスグループ Codelab のスクリプトディレクトリに変更します。

cd confidential-space/codelabs/mig_cs_codelab/scripts

config_env.sh のプロジェクト ID 行を、選択したプロジェクトの ID を反映するように更新します。
既存の変数を設定します。これらの変数を使用してリソース名をオーバーライドします。

既存の Cloud リソース名を使用して、次の変数を設定できます。変数が設定されている場合は、プロジェクトの対応する既存の Cloud リソースが使用されます。設定されていない場合、Cloud リソース名は config_env.sh スクリプトから取得されます。

config_env.sh スクリプトを実行して、このプロジェクトの残りの変数名を、リソース名のプロジェクト ID に基づく値に設定します。

source config_env.sh

プロジェクトの権限を追加します。権限は、IAM ロールの付与のウェブページの手順に沿って追加できます。

このプロジェクトには次の権限が必要です。

Artifact Registry 書き込み
Cloud Scheduler 管理者
Compute サービスエージェント
Confidential Computing ワークロードユーザー
ログ書き込み
Cloud Run デベロッパー
Cloud Run 起動元

gcloud config set project $CURRENT_PROJECT_ID

# Add Artifact Registry Writer role
gcloud projects add-iam-policy-binding $CURRENT_PROJECT_ID --member="serviceAccount:${CURRENT_WORKLOAD_SERVICE_ACCOUNT}" --role='roles/artifactregistry.writer'

# Add Confidential Space Workload Userd
gcloud projects add-iam-policy-binding $CURRENT_PROJECT_ID --member="serviceAccount:${CURRENT_WORKLOAD_SERVICE_ACCOUNT}" --role='roles/confidentialcomputing.workloadUser'

# Add Logging Log Writer
gcloud projects add-iam-policy-binding $CURRENT_PROJECT_ID --member="serviceAccount:${CURRENT_WORKLOAD_SERVICE_ACCOUNT}" --role='roles/logging.logWriter'

# Add Cloud Run Developer
gcloud projects add-iam-policy-binding $CURRENT_PROJECT_ID --member="serviceAccount:${CURRENT_WORKLOAD_SERVICE_ACCOUNT}" --role='roles/run.developer'

# Add Cloud Run Invoker
gcloud projects add-iam-policy-binding $CURRENT_PROJECT_ID --member="serviceAccount:${CURRENT_WORKLOAD_SERVICE_ACCOUNT}" --role='roles/run.invoker'


# Add Cloud Scheduler Admin
gcloud projects add-iam-policy-binding $CURRENT_PROJECT_ID --member="serviceAccount:${CURRENT_WORKLOAD_SERVICE_ACCOUNT}" --role='roles/cloudscheduler.admin'

test_workload.py を確認します。

ソースコードを確認してワークロードの出力を確認します。ワークロードの現在のバージョンが出力されるだけです。
ワークロードを CS に初めて push して出力を確認すると、「version A」と出力されます。

4. ワークロードの設定

まず、この Codelab で使用するワークロードの Docker イメージを作成する必要があります。ワークロードは、現在実行中のワークロードのバージョンを出力する簡単なスクリプトです。ワークロードが開始されたことを出力し、ワークロードのバージョンを出力して 5 秒間スリープし、ワークロードが終了したことを出力します。

ワークロードを作成する手順

create_workload.sh を実行してワークロードを作成します。このスクリプトは次の処理を行います。

ワークロードが公開されるプロジェクトが所有する Artifact Registry を作成します。
コードをビルドして Docker イメージにパッケージ化します。詳細については、関連する Dockerfile 構成をご覧ください。情報。
プロジェクトが所有する Artifact Registry に Docker イメージを公開します。
サービスアカウント <サービスアカウント名> に、Artifact Registry <Artifact Registry リポジトリ名> の読み取り権限を付与します。

5. インスタンステンプレートと MIG の設定

インスタンステンプレートを作成する手順

まず、インスタンステンプレート を作成する必要があります。このテンプレートは、マネージドインスタンスグループ（MIG）が Confidential Space 内でワークロードをプロビジョニングして実行するために使用する必須のブループリントです。

インスタンステンプレートは、すべての特殊なパラメータを定義するため不可欠です。

マシンタイプ: この例では、AMD SEV Confidential Computing テクノロジー（--confidential-compute-type=SEV）をサポートする Confidential VM マシンタイプ（n2d-standard-2 など）を使用します。
VM OS イメージ: confidential-space-images プロジェクトと confidential-space-debug イメージファミリーを使用して、最新の Confidential Space オペレーティングシステムイメージを pull します。
注: このガイドでは、トラブルシューティングを容易にするためにデバッグイメージを使用します。本番環境イメージとは異なり、デバッグバージョンでは、ワークロードが完了した後も VM が実行され、テスト用に SSH アクセスが許可されます。実際のセンシティブデータを使用する本番環境デプロイの場合は、本番環境イメージファミリーに切り替える必要があります。
ワークロード参照: メタデータの必須tee-image-reference 行には、Confidential Space VM が起動する特定のコンテナイメージ（アプリケーションワークロード）が含まれています。

この設定により、MIG によって作成されたすべての VM が、ワークロードを実行する準備ができた適切に構成された Confidential Space になります。

マネージドインスタンスグループを作成する手順

次のステップでは、定義したテンプレートを使用してマネージドインスタンスグループ（MIG） を作成します。MIG は、複数の同一の VM のデプロイ、管理、スケーリングを自動化するため不可欠です。

スクリプト create_launch_mig.sh は、次の 3 つの主な目標を達成します。

1. MIG を作成する

コマンド: gcloud compute instance-groups managed create ${CURRENT_MIG_NAME}
目的: このコマンドは、VM を管理するグループを作成します。
--size 3: MIG がワークロードの3 つのインスタンス を最初に作成して維持するように指定します。
--template ${TEMPLATE_NAME}: 重要なのは、以前に作成したインスタンステンプレートを参照することです 。これにより、3 つのインスタンスすべてが、特定の tee-image-reference ワークロードコンテナを実行する Confidential Space VM として構成されます。
--zone ${CURRENT_PROJECT_ZONE}: インスタンスのデプロイ場所を指定します。

**2. プロジェクト番号を取得する

コマンド: PROJECT_NUMBER=$(gcloud projects describe ${PROJECT_ID} --format="value(projectNumber)")
目的: スクリプトはプロジェクトの数値 ID を取得します。この番号は、サービスアカウントのロールと権限を作成する場合に必要になることがよくあります。特に Google マネージドサービスエージェントの場合に必要になります。

3. IAM 権限を付与する

コマンド: gcloud projects add-iam-policy-binding --role="roles/compute.serviceAgent"
目的: このステップでは、ワークロードのサービスアカウント（${SERVICE_ACCOUNT）にCompute Engine サービスエージェント のロールを付与します。この権限は、サービスアカウントがプロジェクトの Compute Engine サービスの代行として動作できるようにするために重要です。これは、インスタンスの管理、ネットワークの設定、他の Google Cloud サービスとの連携など、MIG の自動機能で必要になることがよくあります。

create_launch_mig.sh を実行して、マネージドインスタンスグループを作成します。

6. 自動修復と自動スケーリングを有効にする手順

自動修復の設定

高可用性を確保するため、ワークロードが応答していることを確認します。アプリケーションがフリーズした場合、MIG は VM を置き換える必要があります。ソース IP 範囲のファイアウォールルールについては、このドキュメントで定義されています。

# 1. Create Health Check (TCP Port 22)
gcloud compute health-checks create tcp ${HEALTH_CHECK_NAME} \
  --port 22 \
  --check-interval 30s \
  --healthy-threshold 1 \
  --timeout 10s \
  --unhealthy-threshold 3 \
  --global

# 2. Allow Health Check Traffic (Firewall)
gcloud compute firewall-rules create allow-health-check \
    --allow tcp:22 \
    --source-ranges 130.211.0.0/22,35.191.0.0/16 \
    --network default \
    --project="${CURRENT_PROJECT_ID}" \ 

# 3. Apply to MIG
gcloud compute instance-groups managed update ${CURRENT_MIG_NAME} \
    --health-check ${HEALTH_CHECK_NAME} \
    --initial-delay 60 \
    --zone ${CURRENT_PROJECT_ZONE}

自動スケーリングの設定

トラフィックの急増に対応するため、グループが 1 ～ 5 個のインスタンスの間で自動的にスケーリングするように構成します。

gcloud compute instance-groups managed set-autoscaling ${CURRENT_MIG_NAME} \
    --max-num-replicas 5 \
    --target-cpu-utilization 0.80 \
    --cool-down-period 90 \
    --zone ${CURRENT_PROJECT_ZONE}

7. ワークロードの検証とイメージアップデートの設定

ワークロードを検証する

マネージドインスタンスグループ（MIG）が VM を起動したら、Confidential Space ワークロードが正しく実行されていることを確認する必要があります。

これは、Google Cloud コンソールまたはコマンドラインから行うことができます。

gcloud compute instance-groups managed list-instances ${CURRENT_MIG_NAME} \
    --zone ${CURRENT_PROJECT_ZONE}

特定のインスタンスのシリアルポート出力でワークロードのログを確認することもできます。

# Replace <INSTANCE_NAME> with one of the names from the previous command
gcloud compute instances get-serial-port-output <INSTANCE_NAME> \
    --zone ${CURRENT_PROJECT_ZONE} \
    --port 1

イメージアップデートの設定

本番環境では、マネージドインスタンスグループ（MIG）を定期的に更新して、次の 2 つの異なるシナリオに対応する必要があります。

ワークロードの更新: アプリケーションコードの新しいバージョンをリリースします（例: test_workload.py を v1 から v2 に更新する）。
インフラストラクチャの更新: Google が基盤となる Confidential Space OS のセキュリティパッチまたはアップデートをリリースします。少なくとも月に 1 回は最新の CS イメージを取得することが効果的な手法です。

インスタンステンプレートを動的イメージリンク （.../images/family/...）と動的コンテナタグ （:latest）で構成したため、1 回の「ローリング置換」オペレーションでこれらのシナリオの両方に対応できます。これにより、VM のフリートは常に最新のスタックを実行し、ダウンタイムが発生せず、わずかな変更ごとに新しいインスタンステンプレートを作成する必要がなくなります。

ローリング置換スクリプト

ディレクトリ update_images で、update_images_script.sh に移動します。このスクリプトはローリング置換をトリガーします。これにより、グループ内のすべての VM が段階的に破棄され、再作成されます。

#!/bin/bash

# Initialize the template
gcloud compute instance-groups managed set-instance-template "${CURRENT_MIG_NAME}" \
--template=projects/"${PROJECT_ID}"/global/instanceTemplates/"${TEMPLATE_NAME}" \
--zone="${CURRENT_PROJECT_ZONE}" \
--project="${PROJECT_ID}"

# Trigger the rolling replace
gcloud compute instance-groups managed rolling-action replace "${CURRENT_MIG_NAME}" \
    --version=template="${TEMPLATE_NAME}" \
    --project="${PROJECT_ID}" \
    --zone="${CURRENT_PROJECT_ZONE}" \
    --max-surge=1 \
    --max-unavailable=0

# Wait for the update to complete
gcloud compute instance-groups managed wait-until --version-target-reached "${CURRENT_MIG_NAME}" \
    --zone="${CURRENT_PROJECT_ZONE}" \
    --project="${PROJECT_ID}"

このスクリプトでは、再起動ではなく置換を使用できます。

再起動 は、マシンを再起動するだけです。既存の OS ディスクが保持されるため、新しい OS パッチは取得されません 。
置換は、VM を削除し、テンプレートから新しい VM を作成します。これにより、システムはファミリーから最新の Confidential Space OS イメージを検索し、レジストリから「最新」のコンテナイメージを pull します。

–max-surge=1: これにより、MIG はターゲットサイズを超える1 つの追加 VM を一時的に作成できます。新しい（更新された）VM を起動し、古い（期限切れの）VM を削除する前に、正常な状態になるまで待機します。

–max-unavailable=0: これにより、ダウンタイムがゼロになります。MIG は、置換を正常にサージしていない限り、マシンをオフラインにできない ことを示します。

ローリング再起動スクリプト

ディレクトリ update_images には、update_workload_image_script.sh という別のスクリプトもあります。このスクリプトはローリング再起動をトリガーします。これは、ワークロードを更新するためだけに使用される高速な方法です。Confidential Space は起動ごとにレジストリからコンテナイメージを pull するため、再起動するだけで、基盤となるホストを変更せずにアプリケーションを :latest バージョンに更新できます。

#!/bin/bash
# Reboots the existing VMs to refresh the container
gcloud compute instance-groups managed rolling-action restart "${CURRENT_MIG_NAME}" \
    --project="${PROJECT_ID}" \
    --zone="${CURRENT_PROJECT_ZONE}" \
    --max-surge=1 \
    --max-unavailable=0

# Wait for the update to complete
gcloud compute instance-groups managed wait-until --stable "${CURRENT_MIG_NAME}" \
    --zone="${CURRENT_PROJECT_ZONE}" \
    --project="${CURRENT_PROJECT_ID}"

更新されたワークロードを確認する

実際のアプリケーションリリースをシミュレートして、「ワンクリックアップグレード」をテストできます。ワークロードコードを変更して Artifact Registry に push し、MIG を更新して、新しいバージョンがダウンタイムなしで実行されていることを確認します。

ステップ 1: 新しいワークロードバージョンをデプロイする

まず、アプリケーションの「新しい」バージョンを作成する必要があります。

ローカルの test_workload.py ファイルを開きます。
バージョン出力ステートメントを print("Workload Version A") から print("Workload Version B") に変更します。
create_workload.sh を実行して、コンテナイメージを再ビルドして Artifact Registry に push します。同じタグ （:latest）に push します。

ステップ 2: ローリングアップデートを実行する

前のセクションで作成した更新スクリプトを実行します。これにより、MIG はすべての VM を置き換え、:latest に関連付けられた新しいコンテナハッシュを pull します。

# Run your update script
./update_images/update_images_script.sh

スクリプトが完了するまで待ちます。

ステップ 3: シリアルポートでアップデートを確認する

更新が完了したら、新しい VM で更新されたコードが実行されていることを確認します。

# Replace <INSTANCE_NAME> with one of the names from the previous command
gcloud compute instances get-serial-port-output <INSTANCE_NAME> \
    --zone ${CURRENT_PROJECT_ZONE} \
    --port 1

新しいインスタンスの名前を取得します。

gcloud compute instance-groups managed list-instances ${CURRENT_MIG_NAME} --zone ${CURRENT_PROJECT_ZONE}

ログを調べます。

# Replace <NEW_INSTANCE_NAME> with one of the names of the running VMs
gcloud compute instances get-serial-port-output <NEW_INSTANCE_NAME> \
    --zone ${CURRENT_PROJECT_ZONE} \
    --port 1

インスタンスが実行されたら、前の gcloud コマンドからインスタンス名を選択して、そのシリアルポートを表示します。

想定される出力: 更新されたログメッセージが表示され、デプロイが成功したことを確認できます。

... Workload Version B ...

ステップ 4: インフラストラクチャ構成を確認する（省略可）

メタデータを調べて、OS とワークロードの両方の動的アップデートを pull するようにインスタンステンプレートが正しく構成されていることを確認することもできます。

次のコマンドを実行して、動的コンテナ参照を表示します。

gcloud compute instance-templates describe ${TEMPLATE_NAME} \
    | grep -A 1 tee-image-reference

結果: コンテナイメージが :latest で終わっていることを確認します。

影響: テンプレートは特定のハッシュではなくタグを参照するため、ローリングアクションの置換ごとに、ステップ 1 で push した最新のコードが正常に pull されます。

（省略可）自動更新

手動更新はメジャーバージョンのリリースに便利ですが、多くの場合、フリートで最新のセキュリティパッチや定期的なデプロイビルドを自動的に取得したいと考えています。

更新スクリプトを Cloud Run ジョブにパッケージ化することで、「ローリング置換」プロセスを自動化できます。この Codelab では、15 分ごとにトリガーします。本番環境では、実行頻度を大幅に減らす必要があります。ユーザーのニーズに応じて、週単位または月単位で構成できます。

ステップ 1: アップデータースクリプトをコンテナ化する

まず、update_images_script.sh（gcloud ... ローリングアクションの置換ロジックを含む）を Docker コンテナにパッケージ化して、Cloud で実行できるようにする必要があります。

このコンテナをビルドして Artifact Registry に push するヘルパースクリプトを用意しました。

次のコマンドを実行します。

# Build and Push the "Updater" Container
# This packages your update logic into a docker image
./update_images/deploy_docker_script_image.sh

処理内容:

update_images/ ディレクトリから update_images_script.sh を取得します。
Google Cloud SDK とスクリプトを含む Docker イメージを作成します。
イメージを ${CURRENT_PROJECT_REGION}-docker.pkg.dev/${PROJECT_ID}/${REPOSITORY}/update-script:latest に push します。

ステップ 2: ジョブをデプロイしてスケジュールする

次に、このコンテナを定期的に実行するように Google Cloud に指示する必要があります。コンテナの実行には Cloud Run ジョブ を使用し、トリガーには Cloud Scheduler を使用します。

スケジューリング構成スクリプトを実行します。

# Create the Cloud Run Job and the Scheduler Trigger
./create_configs/create_schedule_job.sh

スクリプトの内容: このスクリプトは、次の 2 つの重要なアクションを実行します。

Cloud Run ジョブを作成する: push したコンテナを実行する mig-updater-job という名前のジョブを定義します。
スケジューラトリガーを作成する: Cloud Run ジョブ API を 15 分ごとに呼び出す Cloud Scheduler ジョブを設定します。

# (Snippet from create_schedule_job.sh for reference)
# The schedule is set to run every 15 minutes for testing purposes
gcloud scheduler jobs create http ${SCHEDULER_NAME} \
    --schedule "*/15 * * * *" \
    --uri "https://${CURRENT_PROJECT_REGION}-run.googleapis.com/apis/run.googleapis.com/v1/namespaces/${PROJECT_ID}/jobs/${JOB_NAME}:run" \
    --http-method POST \
    --oauth-service-account-email ${SERVICE_ACCOUNT}

ステップ 3: 自動化を確認する

15 分間待つ必要はありません。スケジューラを強制的にすぐに実行して、パイプラインを確認できます。

ジョブを強制的に実行する:

gcloud scheduler jobs run ${SCHEDULER_NAME} --location ${CURRENT_PROJECT_REGION}

実行を確認する: Cloud Run コンソール > [ジョブ] に移動します。新しい実行が開始されます。
MIG を確認する: gcloud compute instance-groups managed list-instances ${CURRENT_MIG_NAME} を実行します。ジョブがローリングアップデートをトリガーすると、インスタンスが RECREATING 状態になります。

15 分間待つ理由:この Codelab では、結果をすぐに確認できるように、スケジュールを */15 * * * * に設定しています。実際の本番環境では、これを毎日（午前 3 時の場合は 0 3 * * * など）または週単位で実行するように変更します。

8. クリーンアップ

クリーンアップスクリプト cleanup.sh を使用すると、この Codelab の一部として作成したリソースをクリーンアップできます。このクリーンアップでは、次のリソースが削除されます。

マネージドインスタンスグループ（${CURRENT_MIG_NAME}）とその基盤となる VM。
インスタンステンプレート（${TEMPLATE_NAME}）。
ヘルスチェックとファイアウォールルール（${HEALTH_CHECK_NAME}）。
Artifact Registry リポジトリ（${REPOSITORY}）。
サービスアカウント（このラボ専用のサービスアカウントを作成した場合）。

探索が完了したら、プロジェクトのシャットダウン（削除）の手順に沿ってプロジェクトを削除してください。

おめでとうございます！

これで、この Codelab は終了です。

マネージドインスタンスグループ（MIG）を使用して Confidential Space ワークロードを安全にスケーリングする方法を学習しました。障害から復旧するための自動修復 、トラフィックの急増に対応するための自動スケーリング を構成し、Confidential Space OS イメージとワークロードコンテナの両方でダウンタイムなしのアップデート を実行しました。

次のステップ

Confidential Space のその他の Codelab をご覧ください。

Confidential Space を使用して ML モデルと知的財産を保護する
マルチパーティコンピューティングと Confidential Space によってデジタルアセットをトランザクションする方法
Confidential Space を使用して機密データを分析する
クラウドプロバイダに保存されていない保護されたリソースで Confidential Space を使用する