WEB問題集
金融サービスの開発チームは、複数の本番 Cloud SQL for PostgreSQL インスタンスを開発・ステージング・本番の各環境に再現性高く払い出したいと考えています。インフラ構成はバージョン管理し、プルリクエスト承認後に CI/CD パイプラインで自動適用したい要件があります。今後のインフラ追加にも備え、運用負荷を最小化したい場合、最も適切な手法はどれですか。
正解：D
正解の根拠
Terraform は宣言的な Infrastructure as Code（IaC）ツールであり、Cloud SQL のリソース定義をコードとして Git で管理できます。Cloud Build と組み合わせれば、プルリクエスト承認をトリガにして自動で plan と apply を実行でき、再現性と監査性を両立できます。
| 手法 | 再現性 | 監査性 | 適用性 |
|---|---|---|---|
| Terraform + Cloud Build | 高 | 高（Git 履歴） | 自動 |
| gcloud 手動 | 低 | 履歴のみ | 手動 |
| コンソール手動 | 低 | 無 | 手動 |
不正解の理由
- A：Deployment Manager は非推奨化が進み、kubectl は無関係なツールです。
- B：手動コマンドは抜け漏れが発生しやすく、再現性が低下します。
- C：画面操作はバージョン管理対象外で、変更追跡が不可能となります。
運用チームは複数の Cloud SQL for MySQL インスタンスを管理しており、スキーマ変更が増えてきました。テーブル変更を Git のブランチ単位で履歴管理し、レビュー後に自動適用したい要件があります。リリース時の安全性として、誤った場合のロールバックも自動化したい場合、最も推奨される構成はどれですか。
正解：D
正解の根拠
Liquibase はチェンジセット単位でスキーマ変更を管理でき、適用済みバージョンを DATABASECHANGELOG テーブルで追跡します。Cloud Build に組み込めば、PR マージ後に update コマンドを自動実行し、問題発生時には rollback コマンドで前バージョンへ戻せます。
| 項目 | Liquibase | アプリ内 DDL |
|---|---|---|
| 履歴管理 | changelog で自動 | 無し |
| ロールバック | 標準サポート | 独自実装 |
| レビュー | PR で容易 | 困難 |
不正解の理由
- A：アプリ内 DDL は同時実行で競合し、変更履歴も残りません。
- B：同じファイルを再実行しても変更履歴管理ツールとは異なります。
- C：手動運用は監査が困難で、ヒューマンエラーのリスクが高まります。
参考：https://cloud.google.com/architecture/database-schema-management-using-liquibase
SaaS プロダクトを運用するチームは、Cloud SQL の CPU 使用率が業務時間に急増する事象を観測しています。CPU が 80% を超えた際にオンコール担当に通知し、さらに 90% を超え 5 分間継続した場合のみエスカレーションを発生させたいと考えています。最小の管理コストで実現する方法はどれですか。
正解：C
正解の根拠
Cloud Monitoring のアラートポリシーは Cloud SQL の CPU 使用率メトリクス（database/cpu/utilization）を直接参照でき、複数の条件としきい値を設定可能です。通知チャネルとして PagerDuty・Slack・メールなどを連携でき、追加実装なしで段階的な通知が実現します。
| 方式 | 運用負荷 | 遅延 |
|---|---|---|
| Cloud Monitoring アラート | 低 | 数十秒 |
| 独自スクリプト | 高 | 不安定 |
| BigQuery クエリ | 中 | 1時間以上 |
不正解の理由
- A：自前実装は障害時に通知自体も停止する単一障害点になります。
- B：BigQuery 経由は遅延が大きく、リアルタイム通知に不向きです。
- D：ログベース指標は CPU メトリクスではなくログ事象向けの仕組みです。
EC サイトを運営する企業の DBA は、Cloud SQL for PostgreSQL のクエリ遅延を分析する必要があります。トップ N の遅いクエリと正規化されたクエリパターン、待機イベントを GUI で確認したいと考えています。アプリケーションコードに追加実装を入れず、最も適切なツールはどれですか。
正解：B
正解の根拠
Query Insights は Cloud SQL マネージドサービスに統合された性能分析機能で、正規化済みクエリのトップ N、実行プラン、待機イベント、エンドツーエンドのアプリラベル別集計をコンソールから確認できます。エージェント追加導入は不要です。
| ツール | 対象 | 導入の手間 |
|---|---|---|
| Query Insights | SQL クエリ性能 | 有効化のみ |
| Cloud Trace | 分散トレース | 計装が必要 |
| Cloud Profiler | アプリの CPU | 計装が必要 |
不正解の理由
- A：Cloud Trace はアプリ計装が必要で、DB 単独分析には不向きです。
- C：Cloud Profiler はアプリプロセス用で Cloud SQL を直接見られません。
- D：pgbadger は導入や定期処理が必要で運用負荷が高くなります。
参考：https://cloud.google.com/sql/docs/postgres/using-query-insights
運用責任者は、社内サービスの可用性目標として「月間 99.9% の成功応答率」を SLO として定義したいと考えています。SLO を継続的に測定し、エラーバジェットを使い切った際にリリース凍結を判断できる仕組みを最小コストで実現したい場合、最も適切な方法はどれですか。
正解：D
正解の根拠
Cloud Monitoring のサービス監視（Services）機能では、SLI を定義し、SLO の目標値、コンプライアンス期間、バーンレートを統合的に管理できます。バーンレートアラートを使えばエラーバジェット消費速度に応じた早期検知が可能となり、追加実装不要で運用に組み込めます。
| 方式 | リアルタイム性 | バーンレート |
|---|---|---|
| Monitoring SLO | 高 | 標準機能 |
| 月末手動集計 | 低 | 不可 |
不正解の理由
- A：バックアップ成否は SLI に直結せず、ユーザー体験を反映しません。
- B：Excel 手作業はリアルタイム性に欠け、自動化されません。
- C：月末集計ではバジェット枯渇を早期検知できません。
参考：https://cloud.google.com/stackdriver/docs/solutions/slo-monitoring