WEB問題集
ある製造業の運用チームは、本番環境の Compute Engine VM について、起動ディスクの定期バックアップを毎日深夜 2 時に自動取得し、30 日間保持したいと考えています。運用負荷を最小限に抑えつつ、要件を満たす最も適切な方法はどれですか。
正解：A
正解の根拠
Persistent Disk のスナップショットスケジュールは、Google Cloud がネイティブに提供する機能で、頻度 (毎日・毎週・毎月)、開始時刻、保持期間をポリシーとして定義し、ディスクにアタッチするだけで自動取得が可能です。サーバーレスで運用負荷が低く、増分スナップショットによりコストも抑えられます。
サービス比較
| 項目 | スナップショットスケジュール | Cloud Functions + Scheduler |
|---|---|---|
| 運用負荷 | 低 (マネージド) | 中 (関数のメンテ要) |
| 保持管理 | ポリシー内蔵 | 自前実装 |
| 増分取得 | 標準対応 | API 呼び出し依存 |
不正解の理由
- B: Cloud Functions と Scheduler の自前実装は可能ですが、保持期間管理を自作する必要があり運用負荷が高いです
- C: dd コマンドはオンラインバックアップに不適で、整合性も担保されず推奨されません
- D: VM 内 Cron は VM 停止時に動作せず、イメージ作成は本来一時的な利用が想定されます
ある EC サイトの SRE チームは、Web フロントエンド層を構成するマネージドインスタンスグループ (MIG) の CPU 使用率が 60% を超えた場合にスケールアウトする構成を gcloud で設定したいと考えています。最も適切なコマンドはどれですか。
正解：C
正解の根拠
マネージドインスタンスグループの Auto Scaling 設定には gcloud compute instance-groups managed set-autoscaling コマンドを使用します。--target-cpu-utilization フラグで CPU 使用率の閾値を指定し、--min-num-replicas と --max-num-replicas でレプリカ数の範囲を制御します。
サービス比較
| 項目 | set-autoscaling | set-autohealing |
|---|---|---|
| 目的 | 負荷に応じたレプリカ数調整 | 異常 VM の自動置換 |
| トリガー | CPU 使用率や LB 利用率 | ヘルスチェック失敗 |
| 結果 | VM 追加 / 削除 | VM 再作成 |
不正解の理由
- A: target-pools はネットワーク負荷分散のレガシー機能で、MIG のスケーリング設定には使用されません
- B: instance-templates create はテンプレート作成コマンドで、Auto Scaling 設定とは別の操作です
- D: set-autohealing は異常な VM をヘルスチェック失敗時に再作成する自動修復機能で、スケーリングではありません
ある金融サービス企業は、Cloud SQL for PostgreSQL の本番インスタンスでレポート系の読み取りクエリが増加し、書き込み性能に影響を与え始めています。書き込み性能を維持しつつ読み取り負荷を分離する最適な構成はどれですか。
正解：A
正解の根拠
Cloud SQL のリードレプリカは、プライマリの変更を非同期にレプリケートする読み取り専用のインスタンスで、レポート系の読み取り負荷をプライマリから分離するための標準的な手段です。最大 10 レプリカまで作成でき、リージョン内・クロスリージョンの双方に配置可能です。
サービス比較
| 項目 | リードレプリカ | HA スタンバイ |
|---|---|---|
| 用途 | 読み取りスケール | フェイルオーバー |
| アクセス | 読み取り可能 | アクセス不可 |
| レプリケーション | 非同期 | 同期 |
不正解の理由
- C: 垂直スケールは一時的な緩和策で、読み取りと書き込みの競合自体は解消されません
- B: Cloud SQL Auth Proxy は接続認証用のコンポーネントで、性能分離の手段ではありません
- D: HA のスタンバイは同期レプリカですが、ユーザー接続不可で読み取りには使用できません
ある運用エンジニアは、Compute Engine の VM の CPU 使用率が 5 分間 80% を超えた場合に PagerDuty に通知するアラートを構成したいと考えています。Cloud Monitoring で最初に作成すべきリソースの組み合わせはどれですか。
正解：A
正解の根拠
Cloud Monitoring でアラートを構成するには、まず通知先となる Notification Channel (PagerDuty、メール、Slack 等) を登録し、次にメトリックの条件と通知先を結びつける Alerting Policy を作成します。CPU 使用率は compute.googleapis.com/instance/cpu/utilization メトリックを使用します。
サービス比較
| 項目 | Alerting Policy | Logs Explorer |
|---|---|---|
| 目的 | メトリック条件の監視と通知 | ログ検索と分析 |
| 通知 | あり | なし (ベース) |
| 対象 | メトリック・ログ・SLO | ログのみ |
不正解の理由
- D: Logs Explorer はログ検索ツールで、ログベースアラート以外の通知機能はそのままでは持ちません
- B: Cloud Trace は分散トレースを記録するサービスで、しきい値からアラート発火する機能はありません
- C: Cloud Profiler は CPU やヒープの統計を継続収集するツールで、通知用途ではありません
ある組織は、すべてのプロジェクトの Cloud Audit Logs を中央のセキュリティチームが分析するために、組織レベルで単一の BigQuery データセットへ集約したいと考えています。最も適切な構成はどれですか。
正解：A
正解の根拠
組織レベルの Log Sink (集約シンク) を作成し、includeChildren=true を指定すると、配下の全フォルダ・プロジェクトのログが単一の宛先に集約できます。宛先には BigQuery データセット、Cloud Storage バケット、Pub/Sub トピック、別の Logging バケットを指定可能で、運用負荷の低い標準的なパターンです。
サービス比較
| 項目 | 組織レベル Log Sink | プロジェクト個別 Sink |
|---|---|---|
| スコープ | 全プロジェクト一括 | プロジェクト単位 |
| 運用負荷 | 低 | 高 (個別管理) |
| 新規プロジェクト | 自動対象 | 都度設定 |
不正解の理由
- D: Pub/Sub への個別転送は冗長で、組織横断の集約には組織レベルの集約シンクが適切です
- B: Cloud Functions のポーリングは API クォータ消費が大きく、シンクの存在意義が失われます
- C: gcloud logging copy はバケット間コピーで、リアルタイムの集約配信には適しません