Cloud SQL で高可用性とスケーラビリティを実現するためのベスト プラクティス

※この投稿は米国時間 2025 年 3 月 4 日に、Google Cloud blog に投稿されたものの抄訳です。

PostgreSQL、MySQL、SQL Server のワークロード向けの Google Cloud のフルマネージド データベース サービスである Cloud SQL は、選択したエディションに応じて、強力な可用性 SLA を提供します。Enterprise エディションの場合、メンテナンスを除き 99.95% の SLA、Enterprise Plus の場合、メンテナンスを含め 99.99% の SLA です。さらに、Cloud SQL は、ビジネスの継続性を確保し、ダウンタイムを最小限に抑えるために、特にミッション クリティカルなデータベースにおいて不可欠な、高可用性とスケーラビリティを備えた多数の機能を提供します。

これらの機能は、データベースのデプロイに関する一般的な課題の解決に役立ちます。

1. 読み取り / 書き込みが統合されたインスタンス: 読み取りと書き込みの両方に単一のインスタンスを使用すると、単一障害点が発生します。プライマリ インスタンスがダウンすると、読み取りと書き込みの両方のオペレーションに影響が出ます。ストレージがいっぱいで自動スケーリングが無効になっている場合、フェイルオーバーも役に立ちません。

2. メンテナンス中のダウンタイム: 計画メンテナンスは、ビジネス オペレーションを中断させる可能性があります。

3. 時間のかかるスケーリング: 計画されたワークロードの急増に合わせてインスタンス サイズを手動でスケーリングするには、綿密な計画が必要で、時間がかかります。

4. 複雑なクロスリージョンの障害復旧: クロスリージョン DR の設定と管理には、フェイルオーバー後の手動による構成と接続文字列の更新が必要です。

このブログでは、Cloud SQL の高可用性とスケーラビリティの機能を使用して、ビジネス継続性を確保する取り組みの効果を最大化する方法と、Cloud SQL Enterprise Plus の機能を使用して、ワークロードの急増、予期せぬ機能停止、読み取りのスケーリングのニーズに対応できる復元性に優れたデータベース アーキテクチャを構築する方法について説明します。

高可用性かつ堅牢なデータベースの設計

まずはスタンバイ インスタンスに自動的にフェイルオーバーする Cloud SQL の高可用性機能を使用するのが良いでしょう。ですがこれだけでは不十分です。ストレージの容量不足、リージョンの停止、フェイルオーバーの問題などのシナリオでは、依然として中断が発生する可能性があります。読み取りワークロードと書き込みワークロードを分離することは、より堅牢なアーキテクチャを構築するために不可欠です。

ベスト プラクティスのアプローチは、Cloud SQL リードレプリカを実装し、高可用性を確保することです。読み取りトラフィックは専用のリードレプリカ インスタンスに転送し、書き込みオペレーションはプライマリ インスタンスで処理します。特定の要件に応じて、プライマリ、リードレプリカ、またはその両方で高可用性を実現できます。このようにワークロードを分離することでプライマリが本番環境トラフィックを予測可能な形で処理できるようになり、ダウンタイムが発生してもリードレプリカを介して中断することなく読み取りオペレーションを継続することができます。

以下は、リードレプリカを実装し、高可用性が実現されているリージョン アーキテクチャのサンプルです。

このアーキテクチャは、複数のゾーンにまたがるリージョンにデプロイできるほか、障害復旧や地理的に分散した読み取りアクセスのために、リージョンを超えて拡張することも可能です。可用性の高いプライマリ インスタンスと、3 つのアベイラビリティ ゾーンにまたがる可用性の高いリードレプリカを使用したリージョン デプロイでは、ゾーン障害に対する復元力を確保できます。2 つのゾーンに障害が発生しても、フェイルオーバーを行い、読み取りと書き込みの両方のオペレーションでデータベースにアクセスできるようになります。クロスリージョン リードレプリカは、これをさらに強化し、リージョンの DR 機能を提供します。

Cloud SQL Enterprise Plus の機能

Cloud SQL Enterprise Plus は、パフォーマンスと可用性において大きなメリットを提供します。

1. ハードウェアの強化: 最大 128 個の vCPU と 824 GB の RAM を備えた高性能ハードウェアでデータベースを実行します。

2. データ キャッシュ: データ キャッシュを有効にして読み取り速度を向上させます。

3. ダウンタイムがほぼゼロのオペレーション: メンテナンスのダウンタイムがほぼゼロで、インスタンス スケーリングのダウンタイムは 1 秒未満です。

4. 高度な障害復旧: クロスリージョンの DR レプリカへのフェイルオーバーと、古いプライマリの自動復元により、障害復旧を効率化します。アプリケーションは、フェイルオーバー後に新しいプライマリに自動的に割り当てられる同じ書き込みエンドポイントを使用して接続できます。

Enterprise Plus エディションは、前述の課題に対処します。

1. パフォーマンスの向上: コア対メモリの比率が高くなることで、データベースのパフォーマンスが向上します。

2. 読み取りの高速化: データ キャッシュにより、読み取り負荷が高いワークロードの読み取りパフォーマンスが向上します。リードキャッシュは、必要に応じてプライマリ、リードレプリカ、またはその両方で有効にできます。

3. 容易なスケーリング: 最小限のダウンタイム（1 秒未満）でインスタンスを迅速にスケーリングし、トラフィックの急増や計画されたイベントに対応できます。トラフィックが少ないときには、1 秒未満のダウンタイムでインスタンスをスケールダウンします。

4. 最小限のメンテナンス ダウンタイム: メンテナンスによるダウンタイムを 1 秒未満に短縮し、ビジネスの継続性を向上させます。

5. リージョン障害の処理: クロスリージョン DR レプリカに簡単にフェイルオーバーでき、元のリージョンが復旧すると、Cloud SQL が自動的にアーキテクチャを再構築します。これにより、障害復旧訓練の手間が減り、アプリケーションの可用性が確保されます。

6. IP アドレスの自動再指定: スイッチオーバーまたはフェイルオーバーの後に、書き込みエンドポイントを利用して現在のプライマリに自動的に接続するため、アプリケーション側で IP アドレスを変更する必要はありません。

これらのメリットをすぐに試せるよう、Cloud SQL Enterprise エディションから Enterprise Plus エディションへのアップグレード オプションが用意されており、ダウンタイムはほぼゼロです。

計画メンテナンスのベスト プラクティス

Cloud SQL Enterprise Plus では計画的メンテナンスのダウンタイムがほぼゼロですが、以下のベスト プラクティスを取り入れることで、ビジネスの継続性をさらに強化できます。

1. ステージング環境のテスト: 潜在的な問題を特定するために、メンテナンス タイミング機能を使用して、本番環境へのデプロイの少なくとも 1 週間前に、テスト / ステージング環境にメンテナンスをデプロイします。

2. リードレプリカのメンテナンス: プライマリ インスタンスの前にリードレプリカの 1 つにセルフサービス メンテナンスを適用して、読み取りと書き込みのダウンタイムが重ならないようにします。プライマリと他のレプリカは、その後すぐに更新するようにしてください。プライマリと他のすべてのレプリカで同じメンテナンス バージョンを維持することをおすすめします。

3. メンテナンスの時間枠: メンテナンスの時間枠を常にオフピーク時に設定し、メンテナンスの実行タイミングを制御します。

4. メンテナンス通知: メンテナンス通知を有効にすると、予定されているメンテナンスの少なくとも 1 週間前にメールが届きます。

5. メンテナンスのスケジュールの再設定: メンテナンス作業が重要な業務の期間と重複する場合は、メンテナンスのスケジュールの再設定機能を使用できます。

6. メンテナンス拒否期間: 重要な業務の期間中は、メンテナンス拒否期間機能を使用し、メンテナンスを最大 90 日間延期できます。

これらの戦略を組み合わせることで、Cloud SQL で高可用性とスケーラビリティを備えたデータベース ソリューションを構築し、ビジネスの継続性を確保してダウンタイムを最小限に抑えることができます。詳しくは、メンテナンスに関するよくある質問をご覧ください。

-データ マネジメント スペシャリスト、Arkapravo Banerjee