【正解】A
【0からの解説】
①前提知識：Cloud SQL のリードレプリカは、プライマリ インスタンスのデータを非同期で複製した読み取り専用のインスタンスです。eコマースのように読み取り（商品の閲覧・検索など）が大半を占めるワークロードでは、読み取りクエリをリードレプリカに振り分ける（オフロードする）ことで、プライマリの負荷を下げて書き込み処理に余裕を持たせることができます。リードレプリカは稼働中のプライマリを停止せずに追加でき、Enterprise Plus エディションでは複数のレプリカを 1 つのエンドポイントで扱える読み取りプールも利用できます。また、高可用性（HA）構成（リージョン インスタンス）を有効にすると、プライマリのゾーン障害時にスタンバイへ自動フェイルオーバーされ、ダウンタイムを最小化できます。
②要件と制約語の整理：(1) 急成長中でピーク時に性能問題がある＝負荷に耐えるスケーラビリティ、(2)「ダウンタイムを最小限に抑えつつ」。
③正解の理由：A は、リードレプリカによる水平スケーリング（スケールアウト）で読み取り負荷を分散してピーク時の性能問題に対処し、さらに自動フェイルオーバー（HA 構成）とフェイルオーバー手順の定期的なテストで、障害時のダウンタイムも最小化します。リードレプリカの追加自体はプライマリの再起動を伴わないため、導入時のダウンタイムもありません。急成長を続けるワークロードにも、レプリカの追加で継続的に対応できます。
【誤りの選択肢】
B：垂直スケーリング（マシンタイプの変更）は性能向上に有効ですが、Cloud SQL Enterprise エディションではマシンタイプの変更にインスタンスの再起動が必要で、ダウンタイムが発生します（Enterprise Plus エディションではほぼゼロのダウンタイムで変更できますが、問題文にはエディションの指定がありません）。また、単一インスタンスを大きくし続ける方法にはマシンサイズの上限があり、急成長するワークロードへの継続的な対応や可用性の向上にはつながりません。
C：ストレージ サイズを増やすと（Cloud SQL では容量に応じてディスクのスループット・IOPS も増えますが）、ピーク時の CPU やクエリ処理の負荷そのものは解決しません。クライアント側キャッシュはアプリケーションの改修が必要で、キャッシュの整合性管理も必要になり、データベース層の負荷対策としては部分的です。
D：MySQL から PostgreSQL への移行は、異なるデータベース エンジン間の移行（スキーマ・クエリ・アプリの改修を伴う異種移行）になり、大きな工数と移行時のダウンタイムのリスクを伴います。エンジンを変えるだけでピーク時の性能問題が解決する根拠もなく、要件に合いません。
【参考】
Cloud SQL でのレプリケーションについて | Cloud SQL for MySQL高可用性について | Cloud SQL for MySQL読み取りプールについて | Cloud SQL for MySQL