WEB問題集
ある開発者が gcloud CLI で Compute Engine の Linux VM を作成し、初回起動時に Nginx を自動インストールしたいと考えています。再現性のある自動化を実現するために、最も適した手法はどれですか。
正解：C
正解の根拠
Compute Engine の起動スクリプトはインスタンス起動時に自動実行され、メタデータ startup-script に直接記述するか startup-script-url で Cloud Storage 上のファイルを参照させることができます。gcloud compute instances create コマンドの --metadata オプションで指定すれば、作成と同時に Nginx を自動インストールする再現性のある自動化が可能となります。
サービス比較
| 項目 | 正解 (startup-script) | 不正解 (SSH 手動) |
|---|---|---|
| 再現性 | 高い、コード化可能 | 低い、手作業依存 |
| 自動化 | 作成時に自動実行 | 毎回手動操作が必要 |
不正解の理由
- A: SSH での手動インストールは再現性がなく、複数 VM のスケール時に運用負荷が大きい構成です
- B: シリアルコンソールはデバッグ用途であり、自動プロビジョニングの標準手段ではありません
- D: gcloud compute ssh の逐次実行は手動操作であり、IaC の原則に反する運用となります
ある企業は標準化された OS 設定とアプリケーションを含む VM テンプレートを社内で共有したいと考えています。同じ構成の VM を多数デプロイする場合、最も効率的な方法はどれですか。
正解：A
正解の根拠
Compute Engine のカスタムイメージは、設定済み VM のブートディスクから作成できる再利用可能なテンプレートです。共通プロジェクトに格納して IAM で他プロジェクトに共有することで、組織内の標準化された VM 構成を高速にデプロイできます。起動時間も短く、構成ドリフトを防止する効果もあります。
サービス比較
| 項目 | 正解 (カスタムイメージ) | 不正解 (毎回スクリプト) |
|---|---|---|
| 起動時間 | 短い | インストール分長い |
| 標準化 | イメージで一貫 | スクリプト差異リスク |
不正解の理由
- B: 毎回パッケージインストールは起動時間が長くなり、パッケージリポジトリ障害の影響も受けます
- C: Cloud Storage 経由の手動復元は Compute Engine の標準フローではなく、自動化に不向きです
- D: クローン操作はテンプレート化の代替にならず、組織全体での共有や IAM 管理が困難となります
参考：カスタムイメージの作成
ある開発チームは GKE で本番ワークロードを稼働させる予定です。ノード管理の運用負荷を最小化し、Google が推奨するセキュリティ強化を自動適用したい場合、最適なクラスタモードはどれですか。
正解：B
正解の根拠
GKE Autopilot はノードのプロビジョニング、スケーリング、アップグレード、セキュリティ強化を Google が自動管理するモードです。ユーザーは Pod 単位で課金され、Workload Identity やノード自動修復などのベストプラクティスがデフォルト適用されるため、運用負荷を最小化して本番ワークロードを稼働できます。
サービス比較
| 項目 | 正解 (Autopilot) | 不正解 (Standard) |
|---|---|---|
| ノード管理 | Google が自動 | ユーザーが管理 |
| 課金単位 | Pod のリソース | ノードの VM |
不正解の理由
- A: Standard クラスタはノードプール管理やアップグレードをユーザーが担う必要があり運用負荷が増えます
- C: MIG 上の自前 Kubernetes はマスター運用も自前となり、最も運用負荷が大きい選択肢です
- D: Cloud Run はサーバーレスコンテナでありフル Kubernetes API を提供しないため要件不一致です
ある企業がコンテナ化された Web API を Cloud Run にデプロイし、リビジョン間で段階的にトラフィックを移行したいと考えています。コマンドで 80% を旧、20% を新リビジョンに割り当てる適切な操作はどれですか。
正解：D
正解の根拠
Cloud Run は複数リビジョンを保持し、gcloud run services update-traffic の --to-revisions オプションでリビジョン単位の重み比率を指定できます。例えば旧=80, 新=20 と指定することで、段階的なカナリアリリースやブルーグリーンデプロイを単一サービス内で完結させることが可能です。
サービス比較
| 項目 | 正解 (update-traffic) | 不正解 (Cloud DNS) |
|---|---|---|
| 制御粒度 | リビジョン単位 | DNS TTL に依存 |
| 切替速度 | 即時反映 | DNS 伝播待ち |
不正解の理由
- A: latest 固定のロードバランサ重み付けは Cloud Run のネイティブ機能を活かさず構成が複雑化します
- C: DNS による切替は TTL の影響でクライアントごとの切替タイミングが揃わず精密制御に不向きです
- B: App Engine の traffic split は別サービスの機能であり、Cloud Run とは独立した制御となります
ある開発者が Python の小規模なイベント駆動処理を Pub/Sub メッセージ受信時に実行したいと考えています。最も運用負荷が低く、関数単位でデプロイできる Google Cloud のサービスはどれですか。
正解：B
正解の根拠
Cloud Functions は関数単位でデプロイ可能なサーバーレスコンピュートで、Pub/Sub トピックをイベントトリガーとして直接指定できます。メッセージ受信時に自動的に関数が起動し、スケーリングや課金もイベント単位となるため、小規模なイベント駆動処理に最適です。インフラ管理は不要です。
サービス比較
| 項目 | 正解 (Cloud Functions) | 不正解 (Compute Engine) |
|---|---|---|
| 起動モデル | イベント駆動 | 常時起動 |
| 課金単位 | 実行時間ベース | VM 稼働時間 |
不正解の理由
- A: 常時起動 VM はアイドル時間にも課金され、小規模なイベント駆動処理には過剰な構成となります
- C: GKE Pod の自前構築はクラスタ運用が必要で、関数単位のデプロイ要件と比較して負荷が高いです
- D: App Engine Flexible は VM ベースで関数単位の細粒度デプロイには不向きな選択肢です