Google ACE: Compute Engine と仮想マシンオペレーション — 学習ガイド
こちらの一部です: Google Associate Cloud Engineer — 学習ガイド. 検証済みの解答で練習: Google試験ハブ, または時間制限付き模擬試験に挑戦: ExamRoll.io.
ストレージ、イメージ、パフォーマンス
永続ディスク
- タイプ: 低コストでシーケンシャルスループットを実現する Standard (HDD)、汎用向けの Balanced (pd-balanced)、高 IOPS/低レイテンシ向けの SSD (pd-ssd)、高性能ティアで IOPS とスループットをプロビジョニングする Extreme (pd-extreme)。Regional PD は、ゾーン間で同期レプリケーションを提供し、可用性を高めます。
- Standard、Balanced、SSD のパフォーマンスはディスクサイズに応じてスケールします。ピーク時の IOPS/スループットを満たすように事前にサイズ設定するか、Extreme を使用して明示的にプロビジョニングします。
- 読み取り専用のマルチアタッチにより、多くの VM 間でデータセットを共有できます。アクセスとキャッシュレイヤーを適宜調整してください。
Local SSD
- エフェメラルで、ホストに直接アタッチされ、非常に高い IOPS/低レイテンシを実現します。データは停止/終了/移行時に失われます。スクラッチ、キャッシュ、レプリケートされたデータレイヤーに使用します。アプリケーションレベルのレプリケーションまたはチェックポイントを確保してください。
スナップショットとイメージ
- スナップショットは、永続ディスクの増分形式のポイントインタイムバックアップです。Resource Manager または gcloud でスケジュールして RPO を満たします。クロスリージョンストレージは DR をサポートします。
- イメージは、ブートディスクと構成をキャプチャします。強化され、パッチ管理されたイメージパイプラインを維持します。ゴールデンイメージ内でゲストエージェント(ロギング/モニタリング用)を検証してください。
- 復元パターン: 迅速な復旧のために、ベースイメージを小さく保ち、残りは起動スクリプトや cloud-init を通じて構成します。これにより、ドリフトが減少し、更新が加速します。
ディスクの選択: トレードオフと障害モード
- ディスクのプロビジョニングが不足すると、アプリケーションのスループットが抑制されます。過剰なプロビジョニングはコストの無駄になります。実際の I/O 特性を測定し、マージンを持たせてピーク時のニーズを満たす最小のディスクを選択します。
- データベースには、Regional PD と pd-ssd/pd-extreme を検討します。fsync の動作とキューの深さを検証してください。レプリケートされていない限り、永続的な状態を保持するために Local SSD を使用するのは避けてください。
アクセス、セキュリティ、ネットワーキング、特殊なワークロード
Linux と Windows の管理
- Linux SSH: OS Login を使用して SSH 認証を一元化し、アクセスをアイデンティティに紐付けることを推奨します。compute.osLogin または compute.osAdminLogin は個人ではなくグループに付与します。
- Windows RDP: コンソールまたは gcloud 経由で Windows の認証情報を設定します。ファイアウォールルールで、信頼できる IP からの TCP 3389 のみを許可するようにします。パブリックへの公開を避けるために IAP TCP 転送を使用します。
- シリアルコンソール: 緊急アクセスパスとして有効にします。ブートのデバッグには
gcloud compute connect-to-serial-portを使用します。IAM でアクセスを制限し、監査します。
SSH、OS Login、キー管理
- メタデータ
enable-oslogin=TRUEを使用して、プロジェクトまたはインスタンスレベルで OS Login を有効にします。ユーザーは自身の Google アカウントに SSH 公開鍵を追加します。IAM がロールベースのアクセスを制御します。 - sudo/root 権限には
compute.osAdminLoginを使用します。OS Login を使用する場合は、ドリフトを防ぐためにプロジェクト全体の SSH キーを無効にします。
メタデータ、起動スクリプト、cloud-init
- メタデータサーバーは、インスタンス/プロジェクトのデータとサービスアカウントのトークンを提供します。適切にスコープが設定されたトークンのみを使用し、シークレットをハードコードしないでください。
- 起動スクリプトと cloud-init: エージェントのブートストラップ、構成の取得、サービスの登録を行います。スクリプトはべき等にし、診断のためにログをシリアルコンソールに書き込みます。
- インスタンスごとのメタデータはテンプレートの設定を上書きできます。構成のずれを避けるために慎重に使用してください。
サービスアカウントとスコープ
- ワークロードごとに専用のサービスアカウントを割り当て、必要なリソース(例: 特定のバケットに対する storage.objectCreator)に対して最小権限の IAM ロールを付与します。
- 広範な Cloud API スコープは、IAM がアクセスを厳密に制御している場合にのみ使用します。それ以外の場合は、スコープを最小限の API に制限します。
ネットワーキングとアドレス
- NIC は内部 IP のみ、または外部 IP を持つことができます。アウトバウンドおよび管理者アクセスには、Cloud NAT または IAP を備えたプライベート VM を使用することを推奨します。
- ライセンスサーバーのような安定したエンドポイントには、静的内部 IP を予約します。エフェメラルアドレスへの依存は避けてください。
- 外部 HTTP(S) Load Balancing はエッジで TLS を終端します。バックエンドの MIG には、マネージド証明書とヘルスチェックを使用します。バックエンドの準備完了状態を、ヘルスチェックと MIG の初期遅延と一致させてください。
特殊なワークロードと分離
- Shielded VMs: セキュアブート、vTPM、整合性モニタリングによりルートキットを軽減します。互換性のないドライバが必要な場合を除き、デフォルトで有効にします。
- Confidential VMs: AMD SEV によるメモリ暗号化が使用中のデータを保護します。一般的にパフォーマンスへのオーバーヘッドは最小限ですが、レイテンシに敏感なアプリでは検証してください。
- Sole-tenant nodes: コンプライアンス、ノイジーネイバーからの分離、ライセンスアフィニティのための専用物理ホスト。キャパシティの断片化と高コストを計画に含める必要があります。
トラブルシューティングと復旧オペレーション
一般的な診断
- 接続性:ファイアウォール ルール、サービス アカウントの権限、ルートを確認します。Network Intelligence Center の接続性テストを使用します。
- 起動に関する問題:シリアル コンソールのログを調査し、スクリーンショットを取得し、起動スクリプトの出力を確認します。署名なしドライバが起動をブロックしている場合は、セキュアブートを一時的に無効にしてから、問題を修正します。
- アクセス ロックアウト:OS Login での SSH の問題については、IAM ロールと、ユーザー アカウントにキーが存在することを確認します。緊急アクセス (break-glass) として、シリアル コンソールを使用してユーザーを追加します。
- ディスクの破損:ブートディスクをデタッチし、レスキュー VM にアタッチして、ファイルシステムを修復し、認証情報をローテーションし、修正後にイメージをキャプチャします。
MIG とロードバランサーの動作
- 過剰プロビジョニング:インスタンスのウォームアップに時間がかかる場合は、MIG の初期遅延とオートスケーラーのクールダウン期間を増やします。そうしないと、アプリの初期化中に 4xx/5xx エラーが原因でスケールアウトする可能性があります。
- 自動修復ループ:ヘルス エンドポイントのセマンティクスと依存関係の準備状況を確認します。起動時の依存関係をずらすか、リトライを追加します。
復旧パターン
- テンプレートまたはイメージからインスタンスを再作成します。イミュータブルなパターンは MTTR を削減します。
- 最新の成功したスナップショットからデータを復元します。ビジネス要件に照らして RPO/RTO を検証します。
- リージョン障害の場合は、リージョン MIG とクロスリージョン スナップショット レプリケーションを使用して、別のゾーンまたはリージョンにフェイルオーバーします。
運用上のセーフガード
- 重要なキャパシティのための予約。予約の消費と割り当てに関するモニタリングベースのアラートを使用します。
- 監査とロギング:重要なサービスに対して、管理者アクティビティ ログとデータアクセス ログを有効にします。OS Login とサービス アカウントを介してアクセスを帰属させます。
短い例
- 静的内部 IP を予約する:
undefined
- プロジェクト レベルで OS Login を有効にする:
undefined
- HTTP ヘルスチェックを作成し、自動修復機能を持つ MIG にアタッチする:
undefined
undefined
実践的な問題シナリオ
Northwind Analytics は、レイテンシの影響を受けやすい API を Compute Engine で実行しています。インシデントとして、デプロイ中の頻繁な過剰プロビジョニング、管理者間での時折の SSH アクセスの混乱、そして 10.0.3.21 で到達可能でなければならないライセンス付きテレメトリサーバーの問題が報告されています。目標は、スケーリングを安定させ、アクセスを強化し、ライセンス エンドポイントの安定性を確保することです。
アプローチ
- 適切なサイズのカスタム マシンタイプと起動時のブートストラップ処理を含むインスタンス テンプレートを作成する
- 理由:テンプレートはイミュータビリティ(不変性)を強制します。カスタムの 6 vCPU/20 GB RAM の構成は、測定された P95 の CPU とメモリに一致し、ライセンス費用を増加させる余分なコアを回避します。起動スクリプトは、ヘルスチェックに合格した後にのみ API をロードバランサーに登録するため、ウォームアップの影響を軽減します。
- 外部 HTTP(S) Load Balancer の背後にリージョン マネージド インスタンス グループをデプロイする
- 理由:リージョン MIG は、ゾーン障害への耐性のためにインスタンスを複数のゾーンに分散させます。HTTP(S) ロードバランサーはエッジで TLS を終端し、インスタンスごとのヘルスチェックを実行して、準備ができたバックエンドにのみトラフィックを送信します。
- クールダウン期間付きの CPU ベースのオートスケーリングと、現実的な初期遅延を持つ自動修復を設定する
- 理由:CPU はこの API の飽和状態と強い相関があります。90 秒のクールダウン期間は、一時的なスパイクによるスラッシングを防ぎます。200 秒の初期遅延は、コンテナのウォームアップと JIT に合わせて調整されており、オートスケーラーがコールドスタートをキャパシティ不足と解釈するのを防ぎます。
- ヘルスチェックを調整し、アプリケーションレベルの /healthz を追加する
- 理由:依存関係(キャッシュ、DB 接続)を検証する HTTP ヘルスチェックは、グレーな障害を検出します。10 秒間隔と 3 回の異常しきい値を使用することで、検出速度と誤検知のリスクのバランスを取ります。
- OS Login を有効にし、IAM グループに管理者アクセス権を付与する
- 理由:OS Login は SSH の認可と帰属を一元管理します。管理者は自身の Google アカウントに SSH 公開鍵を追加します。オンコール グループに compute.osAdminLogin を付与することで、監査証跡を維持しながら sudo 権限を提供します。これにより、VM ごとのキーの不整合がなくなります。
- ライセンスサーバーの静的内部 IP を予約し、小規模な専用 VM にアタッチする
- 理由:10.0.3.21 を予約することで、アドレスが利用可能であることが保証され、誤った再利用を防ぎます。ライセンス VM の NIC に割り当てることで、依存するアプリは設定変更が不要になります。ファイアウォール ルールは、許可された送信元サブネットのみにスコープを限定します。
- 最小権限の IAM を持つ専用のサービス アカウントを API テンプレートに割り当てる
- 理由:最小権限の原則は、影響範囲(ブラスト ラディウス)を縮小します。サービス アカウントには、必要なロール(特定のシークレットや Pub/Sub トピックへの読み取りアクセスなど)のみが付与されます。テンプレートを使用することで、すべてのインスタンスが正しいアイデンティティを継承することが保証されます。
- Shielded VM でインスタンスを強化し、シリアル コンソールによる緊急アクセスを強制する
- 理由:セキュアブートと整合性モニタリングは、カーネル/ブートローダーの改ざんを軽減します。IAM でシリアル コンソールへのアクセスを制限し、監査のためにアクセスをログに記録します。SSH が失敗した場合の復旧用に保持しておきます。
- ステートフル ディスクのスナップショット スケジュールを実装し、復元をテストする
- 理由:API はステートレスですが、ライセンスサーバーと設定ディスクのスナップショット スケジュールを構築して RPO を満たします。定期的な復元テストにより、ツールとランブックを検証します。
- 検証とデプロイ
- 理由:MIG のローリング アップデート設定を使用したブルー/グリーンまたはカナリア アップデートは、リスクを低減します。モニタリング ダッシュボードにより、デプロイ中のインスタンス数の安定化、管理者アクセスの帰属の改善、および 10.0.3.21 への途切れない到達可能性を確認します。
← リソース階層、IAM、請求管理 · すべてのドメイン · コンテナ、アプリケーションホスティング、サーバーレスプラットフォーム →
これらの問題を練習する → · ExamRoll.ioで時間制限付き練習 →
Pass the whole exam — not just this question
You found this answer. Get every verified question and explanation in one place, and save hours of prep. Free to start.
試験に合格する →