03_要点と暗記

Section 2 — 要点と暗記カード

🎯 全レベル向けチートシート。バックアップ/PITR の数値、運用判断パターンを暗記。


📋 バックアップ/PITR 早見表

項目 Cloud SQL AlloyDB Spanner Bigtable Firestore
自動バックアップ あり(日次) Continuous 手動 あり あり
PITR 最大 35日 35日 7日 バックアップから 7日(PITR)
バックアップ保持 7〜365日 1〜35日(Continuous) 1年 カスタム カスタム
クロスリージョン リードレプリカ Secondary Cluster Multi-region レプリケーション Multi-region
エクスポート形式 SQL/CSV SQL Avro CSV/SequenceFile Firestore export format

⏱️ RPO / RTO の典型パターン

業務 RPO 目安 RTO 目安 推奨構成
金融取引 0 数秒 Spanner Multi-region
EC 注文 数分 数十分 Cloud SQL HA + クロスリージョンレプリカ
コンテンツ管理 1時間 数時間 Cloud SQL HA + 日次バックアップ
分析・DWH 1日 数時間 バックアップ + 再実行
キャッシュ データ消失OK 数秒 Memorystore + 再構築

🔧 スケーリング判断

状況 スケール選択
読み取り重視、CPU 70%+ リードレプリカ追加
書き込み重視、CPU 80%+ マシンタイプアップ
接続数枯渇 コネクションプーラー導入
単一インスタンスで限界 Spanner / Bigtable へ移行検討
分析クエリが OLTP を圧迫 リードレプリカ分離 or BigQuery 連携

🚨 アラート閾値の目安

メトリクス 警告 致命的
CPU 利用率 70% (5分) 90% (5分)
メモリ利用率 85% 95%
ストレージ 75% 90%
アクティブ接続 max の 70% max の 90%
レプリ遅延 30s 120s
クエリ p99 SLO 超過 SLO の 2x
エラー率 1% 5%

💡 IAM ベストプラクティス

ベストプラクティス 理由
IAM DB 認証を使う PW 管理不要 + 監査統合 + ローテーション自動
SA を使う(人間アカウント直は不可) アプリ間で署名鍵共有を避ける
Workload Identity で GKE → SA キー鍵不要
最小権限 roles/cloudsql.client + database-specific role
MFA + Org Policy で人間アカウントを保護 コンソール経由の事故防止

📊 Query Insights / EXPLAIN フラッシュ

観点 アクション
Top SQL に CPU 集中 SQL EXPLAIN ANALYZE → インデックス検討
Wait Event: Lock 多発 アプリのトランザクション順序見直し
Wait Event: I/O 多発 ストレージ IOPS 不足 → プロビジョニング
Wait Event: CPU 多発 マシンタイプアップ
Index Advisor 推奨あり 推奨 SQL を作成(書き込み増加に注意)

💰 コスト削減 TOP 5

  1. Committed Use Discount (CUD) — 1年/3年 で 20-60%
  2. 開発環境を Zonal で運用 — HA コスト不要
  3. 未使用リードレプリカ削除
  4. PITR 保持期間を最低限に — ログ保管コスト削減
  5. アーカイブデータは BigQuery + 圧縮へ移動

🔄 自動化パターン

シナリオ 構成
日次バックアップエクスポート Scheduler → Functions → gcloud sql export → GCS
月次インデックス再構築 Scheduler → Workflows → SQL
メンテナンス通知 Slack Cloud SQL Email → Pub/Sub → Functions → Slack
メトリクスベースアラート Monitoring → Alert → PagerDuty/Slack

🚫 ひっかけパターン

問題 NG 回答 正解
「バックアップを長期保管したい」 自動バックアップ保持を延長 エクスポートして GCS Archive
「DB の権限を細かく制御したい」 DB ロール(CREATE ROLE) IAM DB 認証 + IAM ロール
「クエリが遅い」 マシンタイプアップ まず EXPLAIN + インデックス確認
「接続が増えすぎている」 max_connections 大幅増加 コネクションプーラー導入
「リードレプリカが遅延」 Primary をスケールアップ レプリカのリソース見直し + 不要負荷削減