変更要約: Professional Cloud Architect 第4章を新規作成（ドメイン2「管理とプロビジョニング」後半: コンピュート/コンテナ構成＝マシンタイプ/MIG/テンプレート・GKE Autopilot/Standard/ノードプール・Cloud Run リビジョン/トラフィック分割・スポット VM/CUD/SUD、データ構成と運用監視＝Cloud SQL HA/リードレプリカ/Spanner・Cloud Storage ライフサイクル/均一アクセス・Cloud Monitoring/Logging/Trace・SLO/エラーバジェット）。
4.2データの構成と運用・監視
マネージドデータベース（Cloud SQL の高可用性構成・リードレプリカ、Spanner のスケール）の構成、Cloud Storage のライフサイクルとアクセス制御、そして Cloud Monitoring・Cloud Logging・アラートによる運用と、SLO に基づく信頼性管理を理解します。
データ層の構成と、稼働後の運用・監視は、システムの信頼性を左右します。マネージドサービスの可用性機能と、観測（Observability）を設計します。
4.2.1マネージドデータベースの構成
Cloud SQL では、高可用性（HA）構成（別ゾーンのスタンバイへ自動フェイルオーバー）で可用性を高め、読み取り負荷は リードレプリカで分散します。グローバルに伸ばすなら Spanner がノード追加でスケールします。ストレージは Cloud Storage の ライフサイクルルールで古いデータを安いクラスへ移行/削除し、均一バケットレベルアクセスで権限を簡潔・安全にします。「読み取りスケール＝リードレプリカ」「ゾーン障害に耐える DB＝Cloud SQL HA 構成」と結びます。
4.2.2運用・監視と信頼性
稼働後は Cloud Monitoring（メトリクス・ダッシュボード・アラート）と Cloud Logging（ログの収集・検索）で状態を観測します。信頼性は SLO（サービスレベル目標）と エラーバジェットで管理し、目標を超えて壊れそうならリリースを抑えるなどの判断をします。問題の追跡には Cloud Trace（分散トレース）も使います。「メトリクス監視/通知＝Cloud Monitoring」「ログ調査＝Cloud Logging」「信頼性の目標管理＝SLO/エラーバジェット」を押さえます。
「要件 → 手段」が頻出。例：「読み取り負荷を分散」＝リードレプリカ、「DB をゾーン障害に強く」＝Cloud SQL HA 構成、「古いデータを自動で安く」＝Cloud Storage ライフサイクル、「メトリクスで通知」＝Cloud Monitoring アラート、「原因をログで調査」＝Cloud Logging、「信頼性を定量管理」＝SLO/エラーバジェット。
混同に注意：
①HA 構成（可用性）とリードレプリカ（読み取りスケール）は目的が違う。
②Cloud Monitoring（メトリクス）と Cloud Logging（ログ）は役割が違う。
③SLO はユーザー視点の目標で、内部メトリクスそのものではない。
4.2.3この節のまとめ
- Cloud SQL は HA 構成で可用性、リードレプリカで読み取りスケール。グローバルは Spanner
- Cloud Storage はライフサイクル＋均一アクセスで運用を最適化
- 運用＝Cloud Monitoring(メトリクス/アラート)/Cloud Logging(ログ)、信頼性は SLO/エラーバジェット
進捗の記録にはログインが必要です。
理解度チェック
（軽い確認用）Q1. Cloud SQL をゾーン障害に強くし、自動フェイルオーバーさせたい。最も適した構成はどれですか？
Q2. データベースの読み取り負荷を分散して性能を上げたい。最も適した方法はどれですか？
Q3. メトリクスを監視し、しきい値超過で通知を受けたい。使うのはどれですか？
Q4. 障害の原因をログを検索して調査したい。最も適したサービスはどれですか？
Q5. サービスの信頼性を定量的な目標で管理し、超過しそうならリリースを抑えたい。使う考え方はどれですか？
Q6. Cloud Storage で古いデータを自動的に安いクラスへ移行・削除してコストを抑えたい。使うのはどれですか？