ACE クラウド ソリューションの正常な運用の確保

WEB問題集

ACE-OPS#1

Compute Engine でビジネスに不可欠なワークロードをホストしています。このワークロードのブートディスクのデータを定期的にバックアップしたいと考えています。災害時にはバックアップからの復元をできるだけ迅速に行う必要があります。また、コスト節約のため古いバックアップは自動的にクリーンアップしたいと考えています。Google 推奨プラクティスに従いたいと考えています。どうすべきですか?

ディスカッション 0

正解:B

スナップショットスケジュールは Compute Engine の標準機能で、定期的な自動バックアップと古いスナップショットの自動削除(保持期間設定)を一括で管理できます。

  • Google 推奨の公式手段であり、追加のサービスやコードを必要としない最小構成。
  • スナップショットは差分バックアップで効率的に保存され、復元も高速。
  • A/C/D は Cloud Function や cron、Cloud Task を使う実装で、管理の手間が増えスケジュール機能で代替可能。
ACE-OPS#2

複数の Google Cloud Platform(GCP)プロジェクトを管理しており、過去60日分のすべてのログにアクセスする必要があります。ログ内容を探索・迅速に分析したいと考えています。全プロジェクトの統合ログを取得するために Google 推奨プラクティスに従いたいと考えています。どうすべきですか?

ディスカッション 0

正解:B

ログを探索・SQL で迅速に分析したい場合、BigQuery が最適な宛先です。Logging Sink を使えば Google 推奨の統合方法で複数プロジェクトから一元集約できます。

  • BigQuery + テーブル有効期限: 60日経過したパーティションが自動削除され、要件を自動で満たす。
  • Cloud Storage は探索・分析用途には不向き(SQL で直接クエリしにくい)。
  • Cloud Scheduler 経由の自作スクリプトは Google 推奨の方法ではない(Sink を使うべき)。
  • A は単一プロジェクトのコンソール操作で、全プロジェクト統合には向かない。
ACE-OPS#3

マネージドインスタンスグループから、新しいインスタンスの作成に失敗したというアラートが上がりました。想定されるアプリケーショントラフィックを処理するために、テンプレートで指定された稼働インスタンス数を維持する必要があります。どうすべきですか?

ディスカッション 0

正解:C

MIG のインスタンス作成失敗の典型的な原因は、同名の永続ディスクが既に存在していることです(古いインスタンスが削除されたのにディスクが残っている状態)。

  • まず既存テンプレートの構文を確認し、既存の残存ディスクを削除する。
  • disks.autoDelete=true にすれば、インスタンス削除時にディスクも一緒に削除され、今後同じ問題が起きなくなる。
  • テンプレートの新規作成や名前変更は根本原因の対処にならない(同名ディスクが残存する限り失敗し続ける)。
ACE-OPS#4

本番アプリケーションをホストしている Compute Engine インスタンスがあります。インスタンスが 15分以上 CPU リソースの 90% を超えて消費した場合にメールで通知を受け取りたいと考えています。Google サービスを使用したいと考えています。どうすべきですか?

ディスカッション 0

正解:B

Compute Engine の CPU 使用率は Cloud Monitoring の標準指標としてデフォルトで取得されており、カスタムスクリプトやログベース指標を自作する必要はありません。

  • 15分以上 90% 超過という持続時間条件はアラートポリシーのトリガー設定で直接指定可能。
  • メール通知は通知チャネルに追加するだけで完了。
  • A はセルフホスト SMTP で運用負荷が高い。C/D はカスタム指標やログベース指標を自作する手間が無駄。
ACE-OPS#5

バックエンドデータベースとして Cloud Spanner を使用するアプリケーションがあります。このアプリケーションには予測可能なトラフィックパターンがあります。トラフィックに応じて Spanner ノード数を自動的にスケールアップ/ダウンしたいと考えています。どうすべきですか?

ディスカッション 0

正解:D

Cloud Spanner には組み込みのオートスケーラーがないため(※本問題の出題当時)、Webhook + Cloud Function で自動スケールを実装するのが Google 推奨のサーバーレスアプローチです。

  • アラートポリシーで CPU しきい値を監視 → Webhook 経由で Cloud Function を呼び出し → Spanner API でノード数を変更。
  • cron ベース(A)は予測可能パターン向けだが、実際の負荷に追従できない。
  • 人間介入(B/C)は自動化要件に反し、特に Google Support への依頼は不適切。

※ 現在は Spanner Autoscaler が公式機能として提供されていますが、試験の観点ではこの選択肢が正解です。