Section 2 — 応用編：高度な運用判断とコスト/性能最適化

🔧 対象: 中堅以上 ゴール: 性能診断・スケーリング・自動化・コスト最適化の判断ができる。

1. Query Insights の活用

Query Insights とは

Cloud SQL / AlloyDB に統合された クエリ性能可視化機能。「top SQL」「実行計画」「ロック」「待機時間」を時系列で分析可能。

試験で問われる典型問題

Index Advisor（AlloyDB の自動推奨）

• AlloyDB が ワークロードを観測 → 推奨インデックス を提示
• Cloud SQL for PostgreSQL にも段階的に展開中
• 開発者は提示された CREATE INDEX を実行するだけ

2. スケーリング戦略

スケールアップ vs スケールアウト

Cloud SQL のスケーリング選択肢

AlloyDB のスケーリング

• Read Pool に読み取り専用ノードを追加（自動分散）
• Primary は垂直スケール（最大 128 vCPU）

Spanner のスケーリング

• Processing Units (PU) をオンラインで増減可能
• アプリ無停止でスケール
• スケーリング目安: CPU > 65% でスケールアウト推奨

Bigtable のスケーリング

• オートスケーリング（CPU 利用率・ストレージ利用率で自動）
• ノード追加で性能線形向上（10K QPS/node）
• ※ ノード追加直後は タブレット分散に時間がかかる（数十分）

3. レプリケーション戦略

Cloud SQL のレプリケーション

1. 同期スタンバイ（HA）

[Primary] ─同期─> [Standby]
   (zone-a)        (zone-b)
※ アプリは Primary のみに接続
※ Primary 障害時、Standby が自動昇格

2. リードレプリカ（非同期）

[Primary] ─非同期─> [Read Replica 1]
                  ─> [Read Replica 2]
                  ─> [Read Replica 3]
※ 同一リージョンまたは別リージョン
※ 読み取り専用、アプリはレプリカで読み取りを分散
※ 障害時は手動昇格（プロモート）

3. クロスリージョン リードレプリカ（DR）

• 別リージョンに非同期レプリカを配置
• リージョン障害時に手動昇格して別リージョンで運用継続

AlloyDB のレプリケーション

• Secondary Cluster（クロスリージョン）— 読み取り + DR

Spanner のレプリケーション

• Regional: 同一リージョン内で 3 レプリカ
• Multi-regional: 複数リージョンで Paxos 同期、自動フェイルオーバー

4. コスト最適化の実践

コスト軸の見える化

主要コスト要素

Committed Use Discount (CUD)

• Cloud SQL / AlloyDB / Spanner で対応
• 1年 or 3年契約で 20〜60% 割引
• 安定ワークロードに最適

コスト削減 Tips

5. クエリ最適化の実践

PostgreSQL での最適化チェックリスト

• EXPLAIN (ANALYZE, BUFFERS) で実行計画確認
• Seq Scan が大きなテーブルで発生 → インデックス追加
• Nested Loop が大量行で発生 → Hash Join に切り替えるためのインデックス
• Index Only Scan を狙う（INCLUDE 句）
• VACUUM / ANALYZE が動いているか確認
• autovacuum の閾値が適切か

MySQL での最適化チェックリスト

• EXPLAIN で実行計画
• インデックスが使われているか（type=ALL は要注意）
• 複合インデックス の順序が正しいか（左端優先）
• innodb_buffer_pool_size が十分か
• slow_query_log で遅いクエリを抽出

N+1 問題（アプリ起因の最適化）

NG: ループ内で SELECT
for u in users:
    SELECT * FROM orders WHERE user_id = u.id  ← N回実行

OK: JOIN または IN 句
SELECT * FROM users u
JOIN orders o ON o.user_id = u.id

6. 自動化の実装パターン

スケジュールタスクの実行

Cloud Scheduler (cron 形式)
   ↓ 起動
Cloud Workflows / Cloud Functions
   ↓ 実行
Cloud SQL API / pg_dump / gcloud sql ...

自動化シナリオの例

シナリオ 1: 日次バックアップエクスポート

Cloud Scheduler (毎日 02:00)
   ↓
Cloud Functions
   ↓ gcloud sql export sql
Cloud SQL → Cloud Storage (GCS)
   ↓
GCS ライフサイクル → 30日後 Archive クラスへ

シナリオ 2: 月次インデックス再構築

Cloud Scheduler (毎月 1 日)
   ↓
Cloud Workflows
   ↓
Cloud SQL: pgRepack / online schema change ツール

シナリオ 3: メンテナンス通知 → Slack

Cloud SQL メンテナンス通知 (Email)
   ↓ (Gmail Filter or Pub/Sub)
Cloud Functions
   ↓
Slack Webhook

7. SLA / SLO の運用

概念

• SLA (Service Level Agreement): クラウド事業者が保証する稼働率（Google が保証）
• SLI (Service Level Indicator): 自分が測定する指標（例: 5xx エラー率）
• SLO (Service Level Objective): SLI に対する内部目標（例: 99.9%）
• Error Budget: SLO に対する許容ダウンタイム

Cloud Monitoring SLO の活用

• カスタム SLO を定義（例: クエリ p99 < 100ms を 99.9%）
• Error Budget が枯渇しそうなら 新規リリースを停止

8. パッチ管理とメジャーバージョンアップ

Cloud SQL メジャーバージョンアップの推奨手順

1. 現行バージョンの End-of-Life スケジュール確認
        ↓
2. テスト環境にレプリカを作成し、新バージョンにアップグレード
        ↓
3. アプリ互換性テスト（特に CRUD と SQL 関数）
        ↓
4. 本番リードレプリカでアップグレード（1 つだけ）
        ↓
5. メンテナンスウィンドウで本番プライマリにインプレース実行
   または DMS で新バージョンへ移行
        ↓
6. 監視（CPU/メモリ/エラー）強化、ロールバック準備

マイナーバージョンの自動適用

• マイナーバージョン は 自動アップグレード（メンテナンスウィンドウで適用）
• 顧客は 延期 or 即時実行 を選択可能

9. データ保持と削除

データ保持の管理

• 法令要件：金融は7年、医療はHIPAA基準で20年など
• GDPR: ユーザーの削除要求への対応（90日以内など）
• アーカイブ: Cloud Storage のライフサイクルで安価保管へ

Cloud SQL のデータ保持機能

Spanner Backup

• 最大 1 年（365日）保持
• 別リージョンへコピー可能

10. クォータ管理と上限引き上げ

主要クォータ管理ポイント

11. このセクションのチェックリスト

• Query Insights で top SQL と実行計画を見られる
• スケールアップとスケールアウトの使い分けができる
• Cloud SQL の 3 つのレプリケーション戦略を区別できる
• CUD のメリットと条件を説明できる
• PostgreSQL / MySQL のクエリ最適化アプローチを言える
• N+1 問題を識別できる
• Cloud Scheduler + Workflows で自動化が組める
• SLA / SLI / SLO / Error Budget を区別できる
• メジャーバージョンアップの推奨手順を言える
• データ保持の法令要件を踏まえた戦略を組める