Section 2 — 基礎編：DB の運用管理

📘 対象: 全員（必読） ゴール: 接続管理、監視、バックアップ・リカバリ、コスト最適化、自動化の基本概念を理解する。

1. DB 接続とアクセス管理

接続管理の基本要件

• 誰が: ユーザー or サービスアカウント
• どこから: VPC内 / インターネット / オンプレ
• どうやって: パスワード認証 / IAM DB認証 / 証明書認証
• 何ができるか: 読み取り / 書き込み / 管理操作

Cloud SQL のアクセスフロー

┌─ App / User ─┐                           ┌──────────────┐
│ (Service Acct │── ① IAM トークン取得 ────│   IAM        │
│  + Workload   │                           └──────────────┘
│  Identity)    │
└───────────────┘
       │
       │ ② Auth Proxy 起動 (トークン渡す)
       ↓
┌─────────────┐                            ┌──────────────┐
│ Auth Proxy  │── ③ TLS + IAM 認証 ──────│ Cloud SQL    │
│ (sidecar)   │                            └──────────────┘
└─────────────┘

IAM DB 認証 のメリット

• パスワード管理不要
• 監査ログ統合
• 短命トークン（自動取得・ローテーション）
• サービスアカウントとの統合

DB ユーザー管理（標準的なベストプラクティス）

• DB のスーパーユーザー（root, postgres）を直接使わない
• アプリ用ユーザー、運用者用ユーザー、参照用ユーザーを分離
• 最小権限の原則：必要な権限のみ付与
• 定期ローテーション：パスワードまたは IAM ベースで自動化

2. 監視 (Monitoring) の基礎

Cloud Monitoring の階層

Cloud Monitoring
├─ メトリクス (Metrics)        — 数値時系列データ
├─ ダッシュボード (Dashboards) — メトリクス可視化
├─ アラート (Alerting)          — 閾値超過で通知
├─ アップタイムチェック         — 外部からのヘルスチェック
└─ Uptime SLO/SLA               — 信頼性目標管理

DB バイタル（必ず監視すべき項目）

Cloud Logging の利用

• DB のクエリログ、エラーログ、監査ログを集約
• Slow Query Log → スロークエリ検出
• Audit Log → 監査要件対応（IAM 操作、設定変更）

3. アラート設計の基本

良いアラートの 3 条件

1. アクション可能 — 通知を受けたら明確な対応がある
2. 誤検知が少ない — 一時的なスパイクで鳴らない
3. 重要度がある — クリティカル / 警告を区別

アラート設計テンプレート

条件: メトリクス [CPU 利用率] が
      [80%] を超えた状態で
      [5分間] 継続したとき
通知: Slack #db-alerts チャンネル + PagerDuty
重要度: 警告 (Warning)

推奨アラート（Cloud SQL の場合）

4. バックアップとリカバリの基本

バックアップの種類

Cloud SQL のバックアップ概要

• 自動バックアップ: 1日1回（指定時間帯）、デフォルト7日保持、最大365日
• オンデマンドバックアップ: 手動取得、最大99件保持
• PITR: バックアップ + binary log を有効化、最大35日復旧可能
• エクスポート: Cloud Storage へ mysqldump / pg_dump 形式で保存

RPO / RTO の理解と要件マッピング

バックアップ戦略の例

日次自動バックアップ + PITR
   ↓
週次オンデマンドバックアップ（長期保管）
   ↓
月次エクスポート → Cloud Storage Archive クラス
   ↓
データレジデンシー必要時 → クロスリージョン バックアップ

5. スロークエリとインデックス

スロークエリ調査の標準手順

1. Query Insights または slow query log で遅いクエリ特定
2. EXPLAIN ANALYZE で実行計画確認
3. インデックス不足 / フルスキャン / JOIN戦略 を分析
4. インデックス追加 / クエリ書き換え で改善
5. 改善後に 再度メトリクス確認

インデックス設計の原則

• WHERE / ORDER BY / JOIN ON で使われるカラム にインデックス
• 複合インデックスは 最も絞り込める順 に列を並べる
• インデックスの数 ≠ 多いほど良い（書き込みコストが上がる）
• 未使用インデックスは削除 （Query Insights / pg_stat_user_indexes で検出）

ロック競合の調査

• PostgreSQL: pg_locks / pg_stat_activity でロック状態を確認
• MySQL: INFORMATION_SCHEMA.INNODB_TRX / SHOW ENGINE INNODB STATUS
• デッドロック: ログ確認 + アプリのトランザクション順序見直し

6. クォータと制限

よく問われるクォータ

クォータが上限に近づいたら

• Cloud Monitoring でメトリクスを監視
• 上限に近づいたら Quotas ページで増加リクエスト

7. リソース競合の調査

よくある競合シナリオ

8. メンテナンスウィンドウとアップグレード

メンテナンスウィンドウ

• DB のパッチ適用や再起動が行われる時間帯
• 業務影響の少ない時間帯（深夜・週末）を指定
• 通知（事前メール）で予告

Cloud SQL のメンテナンス通知

• メンテナンス前 1 週間 に通知メール
• 任意でメンテナンスをリスケ 可能

メジャーアップグレード

事前準備（必須）

• メジャーアップグレード前にバックアップ
• テスト環境で動作確認
• アプリのドライバ・ライブラリ互換性確認

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

• IAM DB 認証のメリットを 3 つ言える
• Cloud SQL の必須監視メトリクス 7 種類を挙げられる
• アラート設計の 3 条件を言える
• バックアップ 4 種類を区別できる
• PITR の仕組みを説明できる
• RPO / RTO の意味を説明できる
• スロークエリ調査の標準手順を言える
• インデックス設計の 4 原則を言える
• リソース競合の 5 パターンを区別できる
• メジャーアップグレードの 3 パターンを比較できる