トップ > Compute Engine (GCE) > Compute Engineを徹底解説！（応用編）

Compute Engineを徹底解説！（応用編）

Compute Engine (GCE) Google Cloud 徹底解説シリーズ
記事タイトルとURLをコピーする

G-gen の杉村です。当記事では Google Cloud (旧称 GCP) の仮想マシンサービスである Compute Engine を徹底解説します。当記事は、先日公開した「 基本編 」に続く「応用編」です。

基本編の記事

Compute Engine の基礎的な内容については、以下「基本編」の記事をご参照ください。

blog.g-gen.co.jp

基本編に含まれている内容は、以下のとおりです。

  1. 概要
  2. ステート (状態)
  3. ネットワーク
  4. マシン ファミリー・マシンシリーズ・マシンタイプ
  5. リージョンとゾーン
  6. ストレージ
  7. 接続 (VM へのログイン)
  8. メンテナンスと障害対応
  9. バックアップとリストア
  10. Compute Engine の料金

当記事では「基本編」で紹介できなかった仕組みをご紹介します。

サービスアカウントとアクセススコープ

サービスアカウントのアタッチ

VM には サービスアカウント をアタッチすることができます。

サービスアカウントは、人ではなくプログラムが利用するアカウントです。プログラムが Google Cloud API へリクエストする際の認証・認可に用いられます。

サービスアカウントからは キー を発行でき、プログラムにこのキーを読み込ませることで認証に用いることができます。ただし、サービスアカウントキーはテキストファイル (通常は JSON) であるため、漏洩の危険性があります。可能であれば、できるだけ発行したくありませんし、VM 上に配置したくありません。

サービスアカウントとして認証したいプログラムを Compute Engine 上で動作させる場合、サービスアカウントキーを発行せず、VM に直接サービスアカウントを アタッチ できます。

VM 上で gcloud コマンドを実行したり公式クライアントライブラリ (Cloud SDK) が動作すると、VM にアタッチしたサービスアカウントの認証情報を 自動的に利用 してくれます。この仕組みを利用すれば、サービスアカウントキーを発行し、ファイルとして VM に配置する危険を冒す必要がありません。

アクセススコープ

アクセススコープ は Compute Engine VM に特有の設定です。

この設定は、サービスアカウントや IAM の仕組みが今ほど洗練されていなかった頃の名残です。

アクセススコープ設定は、VM の内部からアクセス可能な Google Cloud API を制限する設定です。例えば Cloud Storage 読み取り専用スコープ (https://www.googleapis.com/auth/devstorage.read_only) を設定すると、VM の内部からは Cloud Storage バケットに対する読取オペレーションの API しか発行することができません。

この制限は サービスアカウントの持つ権限より優先 されます。つまり、ある VM のアクセススコープに Cloud Storage 読み取り専用スコープが設定されている場合、たとえ VM にアタッチされているサービスアカウントが Cloud Storage バケットに対する読み・書きの権限を持っていたとしても、その VM の内部からは書き込みオペレーションを実行することはできなくなります。

アクセススコープは、サービスアカウントの権限に「フタをする」ような挙動をすると考えれば分かりやすくなります。

以下の記事で、サービスアカウントとアクセススコープに関する挙動を検証・解説していますのでご参照ください。

blog.g-gen.co.jp

デフォルトのサービスアカウント

プロジェクトで Compute Engine の API を有効化すると、デフォルトのサービスアカウント が作成されます。

名称は、以下のようになります。

(プロジェクト番号)-compute@developer.gserviceaccount.com

このサービスアカウントには自動的に、プロジェクトレベルで 編集者 ロールが付与されます。これは強力な権限を持つロールですので、意図しないセキュリティリスクとなるおそれもあります。

このデフォルトの挙動を回避する方法を以下の記事でご紹介していますので、ご参照ください。

Compute Engine へのサーバー移行

オンプレミスの物理・仮想サーバーや AWS 等他のパブリッククラウドからサーバーを Google Cloud (GCP) に移行するには複数の方法があります。

代表的なものとして、ツールを使って複数サーバーを一括で移行しダウンタイムも抑えられる Migrate for Compute Engine や、仮想イメージファイルを VM イメージとしてインポートする 仮想ディスクのインポート 機能があります。以下の記事をご参照ください。

ロードバランシングと SSL/TLS

Compute Engine で動作するアプリケーションに対するロードバランシング (負荷分散) は、仮想ロードバランサーである Cloud Load Balancing を用います。

負荷分散対象の VM を後述の「マネージドグループ」でグルーピングして、 Cloud Load Balancing の下にぶら下げるイメージです。

負荷分散のイメージ

Cloud Load Balancing は配下の VM に定期的にヘルスチェックを行い、アンヘルシー (障害状態) となったインスタンスにはトラフィックを振り分けないようにするなどの対処を自動で行ってくれます。

Cloud Load Balancing にはいくつか種類があり、 TCP 通信を終端するタイプのロードバランサーでは SSL/TLS の終端 が可能です。そのうえで Cloud Load Balancing と VM の間は復号済みの HTTP で通信させることが可能です。この場合のロードバランサーから VM までの Google Cloud 内部通信は、自動で暗号化されます (ネットワーク レベルの自動暗号化) 。

Cloud Load Balancing の詳細は 公式ドキュメント をご参照ください。

インスタンスグループ

インスタンスグループとは

インスタンスグループ とは VM をグルーピングするリソースであり、以下の目的で使われます。

  • ロードバランシング (前述)
  • オートスケーリング
  • オートヒール
  • 自動アップデート ... 等

インスタンスグループには種類が 2 つ存在します。「 マネージドインスタンスグループ 」と「 アンマネージドインスタンスグループ 」です。

アンマネージドインスタンスグループ

アンマネージドインスタンスグループ (Unmanaged instance group) は VM を Cloud Load Balancing の配下に VM をぶら下げるためのインスタンスグループ です (日本語では非マネージドインスタンスグループとも呼称)。

後述のマネージドインスタンスグループ (MIG) とは対象的に、オートスケーリングやオートヒーリングは利用できません。

オートスケーリングやオートヒーリングを用いず、単純に構築した VM を Cloud Load Balancing に追加したい場合に、このアンマネージドインスタンスグループを用いることになります。

アンマネージドインスタンスグループは単一ゾーンの VM をグルーピングできますが、複数ゾーンにまたがることはできません。

マネージドインスタンスグループ (MIG)

マネージドインスタンスグループ (MIG) とは

マネージドインスタンスグループ は "同一で" "ステートレス" な VM をまとめるためのグループです。 Managed Instance Group を略して MIG とも呼ばれます。

MIG では オートスケーリング (autoscaling: 自動でインスタンスを増減する) 、　オートヒーリング (autohealing: 障害を起こしたインスタンスを自動で再作成) などを実現できます。

オートスケーリングとオートヒーリングは、 VM を イメージ (後述) から自動構築することで実現されます。

マネージドインスタンスグループのオートスケール

さきほど "同一で" "ステートレス" な VM 、と前述しました。 MIG において VM は同一のイメージから起動され、同じ起動シーケンスを経て、同じ状態の VM として起動されますので「 同一 (identical)」です。またインスタンスは都度、イメージから新しいものが起動されますので、可変のデータは外部データベース等に外だしする必要があります。これが VM が「 ステートレス (stateless: 状態を持たない) 」であるという言葉の意味です。

インスタンステンプレート

前述の通り、オートスケーリングとオートヒーリングは VM をイメージから都度、自動構築することで実現されます。

自動構築は インスタンステンプレート という、ユーザーが定義する設定に基づいて行われます。

インスタンステンプレートは以下のような設定値を持ち、自動構築するインスタンスの定義を保持します。

  • マシンタイプ
  • イメージ (パブリック/カスタム)
  • ラベル
  • スタートアップスクリプト
  • その他

パブリックイメージ と カスタムイメージ

インスタンステンプレートの持つ定義情報として イメージ (iamges) があります。

ここで言うイメージは 基本編 で解説したバックアップ用の「 マシンイメージ (Machine images)」とは 別物 であることに注意してください。

インスタンステンプレートで用いられるイメージは単に「 イメージ (images)」もしくは「 OS イメージ (OS images) 」または「 Compute Engine イメージ (Compute Engine image) 」と呼ばれます。

また、イメージには パブリックイメージ と カスタムイメージ が存在します。

前者のパブリックイメージは Google Cloud が標準で配布しているイメージです。普段 VM を構築するときに使う Debian や Windows Server のイメージがこれに当たります。

一方でカスタムイメージは、ユーザーがパブリックイメージをベースにして独自に作成するカスタムのイメージです。パブリックイメージをもとに構築した VM に独自のミドルウェアやアプリケーションをインストールして、そこから カスタムイメージを採取 します。

このカスタムイメージをインスタンステンプレートに設定することで、 MIG でオートスケーリングやオートヒーリングを利用することができるようになります。

その他の MIG

その他にも、 MIG には多用な機能があります。

  • リージョナル (Regional) / ゾーナル (Zonal) MIG : ゾーンをまたいだ可用性はリージョナル、インスタンス間のレイテンシ等を重視する場合はゾーナル
  • コンテナの利用 : VM が Container-optimized OS で構築され全 VM に所定の Docker コンテナが起動する
  • スポット VM: スポット VMで構成された MIG を作成可能 (参考)
  • ステートフル MIG : インスタンス名、 Persistent Disk 、IP アドレスなどを維持できるステートフルな MIG 。オートスケーリングはできないがオートヒーリングが可能
  • 自動アップデート : 新しいインスタンステンプレートをローリングアップデート/カナリアアップデートなどを用いてアップデートできる他、ロールバック等も可能

参考 : インスタンス グループ

オートスケーリング (Autoscaling)

オートスケーリングとは

オートスケーリング (Autoscaling) は、負荷状況に応じて VM が自動的にスケールアウト / スケールインする仕組みです。

前述の通り、オートスケーリングは MIG を用います。

スケールイン・スケールアウトの閾値は オートスケーリングポリシー により定義されます。例えば平均 CPU 使用率、秒あたりの HTTP リクエスト数、その他の Cloud Monitoring の指標 (メトリクス) などを閾値として定義できます。

これらの閾値が超えたとき/下回ったときにスケールアウト/スケールインするように設定が可能です。

なおオートスケーリングには VM の利用料の他に追加の料金は発生しません。

設定

前述の通りオートスケーリングではイメージから VM が構築され、スタートアップスクリプトに従って VM の初期化が行われます。初期化が終わる前に次のスケールイン・アウトが始まらないように クールダウン期間 を設定可能です (デフォルトで 60 秒) 。

また 10 分間の 安定化期間 が設定されており、スケールインの判断は過去 10 分間のピーク負荷を基準に行われます。

その他、設定の詳細は 公式ドキュメント をご参照ください。

運用

オートスケーリング/オートヒーリングはマシンのイメージから VM が新規構築されることで実現されます。これは、オートスケーリング/オートヒーリングを運用する場合はイメージのメンテナンスやアプリケーションデプロイの仕組みが必要であることを意味します。

  • アプリケーションをインストール済みのカスタムイメージを作成し、常に最新版のアプリが入っているようメンテナンスする
  • スタートアップスクリプト (後述) を設定してアプリや設定をダウンロードする

といった方法で VM にミドルウェア・アプリケーションがセットアップされるようにする必要があります。

オートスケーリング / オートヒーリングは非常に便利な仕組みではありますが、 OS / ミドルウェア / アプリケーションのアップデートに追従して イメージのメンテナンスをする 必要がある、という点に十分留意が必要です。

メタデータ

メタデータとは

VM は メタデータ と呼ばれる Key:Value ペアの定義情報を持ちます。

メタデータは プロジェクト単位 または VM 単位 で定義されます。プロジェクト単位で定義されたメタデータは、そのプロジェクト内の全ての VM に継承されます。

メタデータには全ての VM がデフォルトで持っている デフォルトメタデータ とユーザーが定義できる カスタムメタデータ があります。

デフォルトメタデータは「 VM の ID 」「プロジェクト名」「イメージ名」「 NIC の IP アドレス」など、 VM が Google Cloud リソースとして持っている定義情報を取得するために使うことができます。

一方のカスタムメタデータは、ユーザーが定義できます。スタートアップスクリプトを登録したり、特定の設定を有効にするために用います。

デフォルトメタデータ

デフォルトメタデータ は全ての VM が持つメタデータです。

多数の項目がありますので、詳細は ドキュメント をご参照ください。

以下は、デフォルトメタデータから取得可能な情報の一部抜粋です。

  • VM の所属するプロジェクト
  • VM の起動に使われたイメージ名
  • VM の NIC の IP アドレス
  • メンテナンスイベントの状況

デフォルトメタデータは VM の内部から http://metadata.google.internal/computeMetadata/v1/instance/ へHTTP リクエストを投げることで参照できます。

以下は Linux VM にて curl コマンドを実行して NIC の IP に関するメタデータをクエリする際のコマンドとレスポンスです。リクエストヘッダには Metadata-Flavor: Google を付与する必要があります。

$ curl -H "Metadata-Flavor: Google" http://metadata.google.internal/computeMetadata/v1/instance/network-interfaces/0/ip
10.146.0.60

カスタムメタデータ

一方の カスタムメタデータ は、ユーザーが定義できるメタデータです。以下のような用途で用います。

注意点

特にユーザーが自由に定義できるカスタムメタデータにおいて、センシティブな情報をメタデータに含ませてはいけません。

メタデータは機密情報を保持するようには設計されていないため、パスワード類、一時トークン類などをカスタムメタデータに含ませることは NG です。

スタートアップスクリプト / シャットダウンスクリプト

スタートアップスクリプト

スタートアップスクリプト は VM が起動するときに毎回実行されるスクリプトです。

これを指定することで VM 起動時にミドルウェアをセットアップしたり、データをダウンロードすることができます。オートスケーリングやオートヒーリングを利用する際には、ほぼ必須となる機能です。

スクリプトは Linux VM では root ユーザーで、 Windows VM では LocalSystem アカウントで実行されます。

前述の通り、スタートアップスクリプトはメタデータを使って設定します。例として以下のようにして、スタートアップスクリプトを指定できます。

  • Key : startup-script / Value : (スクリプト本文)
  • Keu : startup-script-url / Value : (Cloud Storage に格納したスクリプトへの URL)

上記は Linux VM の場合 です。 Windows VM の場合 はメタデータの指定方法が少し異なりますので、ドキュメントをご参照ください。

注意点として、スタートアップスクリプトは起動時に 毎回 実行されます。よって、スクリプトの処理は冪等である (何回実行されても同じ結果になる) 必要があります。もしくは、初回起動後はメタデータを削除してスタートアップスクリプトが実行されないようにするなど、工夫が必要です。

シャットダウンスクリプト

シャットダウンスクリプト は VM 停止時もしくは削除時に実行されるスクリプトです。

特にオートスケーリングを活用する場合に「インスタンスが削除される前にデータやログを退避する」などのユースケースで利用されます。またスポット VM がプリエンプト (中断) される前の停止前処理としても利用されます。

スクリプトは Linux VM では root ユーザーで、 Windows VM では System アカウントで実行されます。

ただし Compute Engine ではシャットダウンスクリプトの実行は「ベストエフォート」であり「完了を保証できないことがあります」とされています。このことから、シャットダウンスクリプトの失敗がクリティカルとなるようなシステム設計は避けるべきです。

シャットダウンスクリプトは以下のような際に実行されます。

  • Google Cloud コンソールや gcloud コマンドでインスタンスがシャットダウンされるとき
  • instances.delete / instances.stop の API リクエストで VM がシャットダウンするとき
  • スポット VM が中断されるとき
  • sudo shutdown や sudo reboot 等ゲスト OS のコマンドで停止 / 再起動されるとき

注意点として、コンソールやコマンドからの「再起動」にあたる instances.reset ではシャットダウンスクリプトは起動しません。

永続ディスクのパフォーマンス

IOPS とスループット

基本的な考え方

永続ディスクのパフォーマンスには、大きく分けて以下の考慮点があります。

  • IOPS
  • スループット

IOPS は一秒間あたりの読み書きの回数です。小さいデータのランダム IO が多く発生する処理では IOPS が主な観点となります。

一方の スループット は単位時間あたりの読み書きのボリュームです (Google Cloud では MB/sec で表記) 。シーケンシャルな読み書きが発生する処理や、 1 回あたりの読み書きサイズの大きい処理の場合に、スループットが重視されます。

性能の計算方法

ある VM にアタッチされたディスクに対する IOPS / スループット性能の上限は以下のように計算されます。

  • ベースライン性能 + ( GB あたりの性能上限 × インスタンスにアタッチされている全ディスクの合計 GB )

バランスディスクと SSD ディスクには ベースライン性能 があります。標準ディスクでは 0 として計算します。

ベースライン性能はディスクの種類によって決定されます。

ディスクの種類 ベースライン IOPS (インスタンスあたり)
バランスディスク 3,000
SSD ディスク 6,000

また GB あたりの性能上限 もディスクの種類によって決まっています。ディスクサイズが大きければ大きいほど GB あたりの性能上限は上がっていきます。

ディスク種別 読み取り IOPS / GB 書き込み IOPS / GB
ゾーン標準ディスク 0.75 1.5
ゾーンバランスディスク 6 6
ゾーン SSD ディスク 30 30

例えば 1,000 GB のゾーンバランスディスクの場合、読取・書込ともに 6,000 IOPS が上限です。

計算例

2つの 1,000 GB のゾーンバランスディスク (=計 2,000 GB) をアタッチしたインスタンスがあると、計算式は以下のようになります。

  • ベースライン性能 3,000 + (6 IOPS * 2000 GB) = 15,000 IOPS

ただし、この上限 IOPS は VM の マシンシリーズごと/vCPU コア数ごとの制限 を超えることはできません。

例えば e2-medium インスタンスの最大 IOPS は書込で 10,000、読取で 12,000 です。この場合は、小さい方が上限になります。

スループットにも同様に上限が設定されます。詳しくは ドキュメント を参照してください。

パフォーマンスの最適化

前述の通り、永続ディスクのパフォーマンスを律速する要素は以下があります。

  • 永続ディスクの種類 (標準 / バランス / SSD / エクストリーム) ごとの上限 IOPS / スループット
  • VM のマシンタイプ・ vCPU コア数ごとの上限 IOPS / スループット

ディスクを増やしても、マシンタイプ・コア数ごとの上限に当たっているとそれ以上は性能が上がりません。

ディスクのパフォーマンスが思うように出ない場合、 Cloud Monitoring を確認し、永続ディスクのパフォーマンスがどの要素で律速されているかを確認して、適切な対処を取る必要があります。

ログ管理

Compute Engine で動作するアプリケーションのログや、 OS のシステムログ類を管理するのに最も効率的な方法は Cloud Logging の利用です。

VM 内に Ops Agent をインストールすることで Cloud Logging に各種ログ類を送信することができます。

以下のドキュメントを参考にして Agent のセットアップとログ送出の設定が可能です。

フルマネージドの Cloud Logging へログを収集できる

ライセンス

ライセンスの基本

パブリッククラウドでサードパーティソフトウェアを使う場合には、ライセンスが問題になることが多くあります。

Google Cloud が配布しているイメージファイルや Google Cloud Marketplace で販売・配布されるソフトウェアについては、課金が Google Cloud と統合されており、難しい考慮なく利用可能な場合があります。

VM のゲスト OS 上にインストールするタイプのソフトウェアのライセンス体系等については、パブリッククラウド上での利用に制限や、ライセンス料金へ適応される係数などがあり、独特となっている場合がありますので そのソフトウェアベンダーや代理店に確認する のが原則です。

オンデマンドライセンス (PAYG)

OS 等のライセンスについては、原則的な第 1 選択肢は Google Cloud が公式で配布している プレミアムイメージ や Google Cloud Marketplace で配布されているイメージを利用することです。

Red Hat Enterprise Linux 、Windows Server 、 Microsoft SQL Server などはプレミアムイメージが配布されており、料金は時間課金で Google Cloud 利用料に追加課金されます。複雑な考慮が必要なく、シンプルに時間課金でライセンスを購入可能です。

このようなライセンス体系は オンデマンド 、 従量課金 、あるいは PAYG (Pay As You Go) と呼ばれます。

プレミアムイメージを使う他にも イメージのインポート や Migrate for Compute Engine などのツールを使ってインポートした仮想マシンにオンデマンドライセンスを付加することも 可能 です。

ライセンス持ち込み (BYOL)

第 2 選択肢としてはライセンスの持ち込みです。 Bring Your Own License の頭文字を取って BYOL と呼ばれます。

これは前述の通り、ライセンス発行者によりルールが異なりますので、ライセンス利用可否・体系・課金方法は、販売元へ確認となります。

参考 : ライセンスについて

Windows Server や SQL Server などの Microsoft ライセンスについて、第1選択肢としてはやはりオンデマンドライセンスが推奨されます。第2以降の選択肢として単一テナントノードを使ったライセンス持ち込みやソフトウェアアシュアランスによるライセンスモビリティを適用した持ち込みなどが考えられます。こちらも、詳細はドキュメントを参照するとともに、販売元に確認が必要です。

参考 : Microsoft ライセンス

単一テナントノード

単一テナントノードとは

単一テナンシー は、利用者が VM を作成する際、 Google Cloud の持つ一台の物理マシンを専有できる仕組みです。この機能で専有した物理マシンを 単一テナントノード と呼びます。

通常通りに VM を作成すると VM はマルチテナントノードの上で起動されます。マルチテナントノードでは、他の顧客の VM も同一マシンに載っている可能性があります。一方の単一テナントノードでは、自分のプロジェクトの VM だけでマシンを専有できます。

単一テナントノードは セキュリティ要件 ・ コンプライアンス要件 を満たすために利用する他、 ライセンス販売元の要件 を満たすためにも利用されます。その他にも VM 間の高い IOPS パフォーマンス が求められる場合にも用いられることがあります。

料金

単一テナントノードでは物理マシン単位でリソースを確保するため、ノード単位の料金がかかります。以下のドキュメントに料金が記載されています。永続ディスク等の料金は別途発生することも記載されていますので、十分ご注意ください。

参考 : 単一テナントノードの料金

GPU

Compute Engine の GPU

Compute Engine にはグラフィック処理や機械学習目的のため GPU をアタッチできます。

利用可能な GPU の種類等はドキュメントをご参照ください。

GPU をアタッチすると VM の料金とは別に、 GPU の利用料金が発生します。

ワーカー目的であれば、 スポット VM との組み合わせ でコストを節約することも可能です。

制限

GPU のアタッチには以下のような制限があります。

  • 共有コアマシンタイプ (E2 / N1 シリーズ) やメモリ最適化タイプ (M1 / M2 シリーズ) では利用できない
  • ライブマイグレーションができない
  • デバイスドライバが必要 (参考)

以下の公式ドキュメントも参考にしてください。

高度なセキュリティ

Shielded VM

Shielded VM とは VM が セキュアに起動することを担保する機能群 です。

Shielded VM 機能群を有効化すると、 VM が起動する際にブートローダー (bootloader : コンピュータ起動時に実行されるプログラム) とカーネル (OS の中核となるプログラム群) がチェックされ、ブートレベル / カーネルレベルのマルウェアやルートキット (rootkit : 攻撃者がコンピュータへの攻撃のために忍ばせておく悪意あるツールの総称) に汚染されていないことが確認されます。

Shielded VM は以下の 3 機能で構成されており、 VM ごとにオン / オフを設定できます。

No 機能名 デフォルト 説明
1 セキュアブート Off ブートコンポーネントのデジタル署名を検証し失敗時は停止する
2 vTPM On 仮想的な Trusted Platform Module (鍵や証明書生成などに使うチップ)
3 整合性モニタリング On 前回起動時とブートシーケンスが異なる場合、起動を失敗させる

セキュアブートはデフォルトではオフになっています。これは署名されていないドライバを使っている等の場合に対処するためです。問題ない場合はオンにすることができます。

vTPM と整合性モニタリングはセットで利用するものであり、前者をオンにしないと後者をオンにできません。デフォルトでは両方ともオンになっています。後者をオンにすると、毎回の起動時にブートシーケンスが前回と変化したかがチェックされ、変化があればブートプロセスが停止されます。そのため VM の起動シーケンスに影響を与える「カーネルの更新」「ドライバのインストール」等を行った場合、整合性検証が失敗し、 VM が起動しない場合があります。このような際は gcloud コマンド等で 明示的にベースラインを更新 する必要があります。

整合性チェックの失敗時は Cloud Monitoring に出力される earlyBootReportEvent lateBootReportEvent などの ログ が出力されます。

Confidential VM

Confidential Computing は Trusted Execution Environment (TEE) というハードウェアにより メモリ内のデータの暗号化を実現する機能 です。

コンピュータが扱うデータの暗号化は「保存中 (at-rest) 」「転送中 (in-transit もしくは in-flight) 」「処理中 (in-use) 」に分類されます。このうち、データ処理中の暗号化 (Encryption-in-use) を実現するのが Confidential Computing です。

なお Google Cloud において、保存中のデータの暗号化は デフォルトで実現 されていますし、転送中のデータの暗号化は HTTPS などで実現したり、あるいは Google Cloud 内部であれば 特定の通信はデフォルト で暗号化が実現されています。

Confidential VM は AMD Secure Encrypted Virtualization (SEV) を搭載した AMD EPYC プロセッサのマシンタイプ (N2D / C2D) でのみ利用可能なほか、 OS も限定されています。

Confidential VM を有効化すると暗号化 / 復号のオーバヘッドがかかりますが、ハードウェアでサポートされた処理のためパフォーマンス影響は 0 〜 6% 程度とされています。

Confidential VM を有効化するにはインスタンス構築時に Confidential Computing サービスを有効にするフラグをオンにするだけです。

VM Manager

VM の運用を自動化する VM Manager という機能があります。

同機能については、以下の記事でご紹介しています。

blog.g-gen.co.jp

杉村 勇馬 (記事一覧)

執行役員 CTO / クラウドソリューション部 部長

元警察官という経歴を持つ現 IT エンジニア。クラウド管理・運用やネットワークに知見。AWS 12資格、Google Cloud認定資格11資格。X (旧 Twitter) では Google Cloud や AWS のアップデート情報をつぶやいています。