高可用性を確保する為のデザイン パターン   

本デザイン パターンのユースケース

ほとんどのワークロードで可用性を考慮した設計は重要ですが、求められる要件はワークロードによって異なるため、ワークロードのアーキテクチャを考える上で、そのワークロードがどのレベルの可用性を実現する必要があるかを考えることが重要となります。Google Cloud では可用性を高めるためのソリューションをいくつか提供しており、これらを適切に採用し、各ワークロードに適した構成を選択すること可能です。

本節では自然災害によるリージョンやゾーン障害などを前提にした高可用性設計について、 Compute Engine などによるアプリケーション サーバと DB を組み合わせた一般的な ウェブサービスのワークロードを想定したアーキテクチャについて解説します。また、 Google Cloud の各ソリューションの網羅的な高可用性構成の解説については対象外のため、必要に応じてそれぞれのソリューションのドキュメントを参照ください。

Google Cloud において可用性を高めるには、ゾーンとリージョン、グローバル リソースの違いを意識する必要があります。各リージョンには 1 つ以上のゾーンがあり、ほとんどのリージョンには 3 つ以上のゾーンがあります。たとえば、asia-northeast1 リージョンは東京に位置し、asia-northeast1-a 、 asia-northeast1-b 、 asia-northeast1-c の 3 つのゾーンがあります。

仮想マシン インスタンスやゾーン永続ディスクなど、特定のゾーンに閉じたリソースはゾーンリソースと呼ばれます。静的外部 IP アドレスなど、同じリージョン内であれば、ゾーンをまたいで使用できるリソースは、リージョンリソースと呼ばれます。グローバル リソースは、場所を問わずすべての他のリソースで使用できるリソースです。詳細は リージョンとゾーン | Compute Engine ドキュメント など、利用しようとするサービスのページを確認してください。

また、Compute Engine のメンテナンス イベントでは、ホスト メンテナンスと呼ばれるホストカーネルのアップグレード、ハードウェアの修理またはアップグレードのような通常 VM の再起動を伴うような作業が行われますが、インスタンス 可用性ポリシーでこのようなメンテナンス イベントが発生した場合は、デフォルトでインスタンスをライブ マイグレーションするように構成されており、このようなメンテナンス イベントにおいても VM を再起動する事なく稼働を続ける事が可能です。

参考ドキュメント : アーキテクチャ フレームワーク | 信頼性

信頼性の要件を定義する

高可用性を確保する為の構成を検討する際は、まず最初に各ワークロードにそれぞれどのレベルの可用性が求められるかを特定することが重要となります。この要件定義は、障害発生時に許容可能なビジネスへの影響の分析から着手します。この分析で主要な指標は以下の 2 つです。

• 復旧時間目標（ RTO ）
  アプリケーションがオフラインである状態が許容される最大時間です。通常、この値はサービスレベル契約（SLA）の一部として定義されます。

• 復旧時点目標（ RPO ）
  重大なインシデントが原因でアプリケーションからデータが失われている状態が許容される最大時間です。この指標はデータの用途によって異なります。たとえば、頻繁に変更されるユーザーデータの場合、 RPO はわずか数分になる可能性があります。対照的に、重要度が低く、変更頻度が低いデータの場合、 RPO は数時間になることもあります（この指標は、失われたデータの量や質ではなく時間の長さのみを表します）。

RTO と RPO の値が小さいと構成の複雑性が増す傾向にあるため、それに伴う管理コストも同様の曲線を描きます。高可用性のアプリケーションを維持するには、地理的に離れた 2 つのデータセンターへの分散やレプリケーションなどを実施したりすることが求められるためです。また、 RTO と RPO にビジネス上求められる要件を正しく把握し、必要以上に要件を厳しくしすぎて複雑な構成を採用したり、コストを上げすぎないことが信頼性の要件を定義する上で重要なことの一つです。

参考ドキュメント : 障害復旧計画ガイド

また、信頼性の要件の一環として、自然災害等の大規模災害などによるリージョンの障害を前提とするかどうかも重要となります。例えば後述するマルチゾーン ウォーム スタンバイの構成パターンでは、リージョン内の異なるゾーンにリソースを配置する事になり、物理インフラストラクチャやハードウェア や ソフトウェアで障害が発生した場合に、短い時間でワークロードを復旧することができますが、大規模災害時にリージョンで障害が発生した際にはワークロードを復旧することができません。この場合、マルチリージョンのストレージ ロケーションにスナップショットを取得するバックアップ ＆ リストアと組み合わせることで、リージョンで障害が発生した際にも別のリージョンでワークロードを復元し、ワークロードの稼働を継続させることが可能となります。ただし、この場合リージョンの障害に備えるための追加のコストが必要となるため、コストとビジネス上要求される信頼性要件のバランスを最適化する必要があります。

RTO や RPO 、大規模災害の考慮などの具体的な整理の方法は本稿では省略しますが、 IPA が公開している非機能要求グレードなどを参考にして整理するのも良いでしょう。

信頼性の要件を満たすことの出来るソリューション、構成パターンを選択する

可用性を高める構成パターンを決める場合は、整理した信頼性の要件に基づき以下の表を参照して検討するのが良いでしょう。また、前述の通りゾーン障害からの短時間の復旧のためにマルチゾーン ウォーム スタンバイの構成と、リージョンの障害からの復旧のためにバックアップ ＆ リストアの構成を組合わせて構成することも可能ですが、あくまで RTO と RPO に関してはぞれぞれの定義となるため注意が必要です。

※1 記載の時間については構成、運用体制などにより変動する為、あくまで目安です。

※2 リージョン永続ディスクに保管されたデータのみ、書き込み前のデータについてはデータが失われます。

以下それぞれの構成パターンについて考慮点やアーキテクチャなどを解説します。 ※ 未記載の構成パターンについては今後追加予定です。

マルチゾーン ウォーム スタンバイ

マルチゾーン ウォーム スタンバイとは、Compute Engine 上に構築したワークロードなどに対し、ゾーン障害が発生した際に HA クラスタ ソフトウェアでフェイルオーバーを管理し、別ゾーンのウォーム スタンバイのインスタンスにて処理を引き継ぐ構成で、主にステートフルなデータベース サービス（MySQL 、 Postgres など）向けの HA ソリューションを構築する際など用いられる構成です。Compute Engine で利用可能な HA クラスタ ソフトウェアとしては、次のようなソリューションが使用できます。

• ClusterLabs, Pacemaker

• Red Hat, GOOGLE CLOUD PLATFORM での RED HAT HIGH AVAILABILITY クラスターの設定

• Windows Server フェイルオーバー クラスタリングの実行

• NEC, Cluster Pro

また、Google Cloud 上でこの構成を検討する際には以下が考慮点となります。

• マルチゾーン構成の採用
  Google Cloud において、各ゾーンは 1 つ以上のクラスタ内でホストされ、クラスタごとに、独立したソフトウェア インフラストラクチャ、電源、冷却、ネットワーク、セキュリティ インフラストラクチャがあり、コンピューティング リソースとストレージ リソースのプールが含まれています。リージョン内の異なるゾーンにウォーム スタンバイを配置する事により、この物理インフラストラクチャやハードウェア ソフトウェアで障害が発生した場合に、正常稼働している他のゾーンで処理を引き継ぐことが可能となります。また、マルチゾーン構成を採用する際は単一障害点が存在しないよう、片方のゾーン障害の際に、もう片方のゾーンで必要なリソースにアクセス出来るよう、必要に応じて冗長構成を採用する必要があります。具体的な指針としては、リージョナルリソースであれば単一ゾーンの障害の際に影響を受けることはない為、特別な考慮は不要ですが、 Compute Engine のインスタンスなど、ゾーンリソースはマルチゾーンへ冗長配置するなど、考慮が必要となります。
  
  参考ドキュメント : ゾーンとクラスタ、ゾーンとリージョン、グローバル リソース

• マネージド インスタンス グループの活用
  ステートレスなウェブサイト フロントエンドやアプリケーション サーバなどに関しては、マネージド インスタンス グループ（ MIG ）を採用することで、高可用性だけではなく、スケーラビリティやインスタンス テンプレートの利用による運用負荷の軽減など、様々なメリットが有るため、可能な限り採用を検討することをおすすめします。
  
  参考ドキュメント : フローティング IP アドレスのおすすめの方法

  • 内部 TCP / UDP 負荷分散を使用したフェイルオーバー
    稼働系、待機系のインスタンスを内部 TCP / UDP 負荷分散のバックエンドとしてマネージド インスタンス グループに配置し、ヘルスチェック機能で稼働系を識別し、内部 TCP / UDP 負荷分散 IP アドレスを仮想 IP アドレスとして使用することにより稼働系を切り替えることが可能となります。

  • ルート API 呼び出しを使用したフェイルオーバー
    フローティング IP 相当の IP として、ネットワークの有効なサブネットの外にある IP を IP 転送を有効にした VM に設定し、稼働系インスタンスをその IP への VPC ネットワーク内の静的ルートのネクストホップとして設定し、フェイルオーバーの際にはこの静的ルートのネクストホップを待機系インスタンスに再設定することで稼働系を切り替えます。

  • Cloud DNS の限定公開ゾーンなどを利用したフェイルオーバー
    この構成ではフローティング IP を利用せず、 Cloud DNS の限定公開ゾーン等に作成した A レコードを稼働系のインスタンスの IP アドレスに設定し、フェイルオーバーの際に待機系インスタンスの IP へ変更することで稼働系の切り替えを実現します。ただし、この実装においては接続元となるアプリケーション サーバの DNS キャッシュの無効化や対象の A レコードの TTL を数秒など短期間程にすることで短い時間での切り替えを実現するなどの考慮が必要となります。
    
    参考ドキュメント : 限定公開ゾーンの作成

• スプリットブレインを防ぐことが可能な構成を採用する
  Google Cloud における HA クラスタ構成でも、オンプレミス環境での同構成と同様に、ゾーンのネットワーク コンポーネントの障害などで稼働系と待機系のネットワークが分断されてしまい、同一資源に複数のインスタンスがアクセスすることでデータの不整合を引き起こしてしまうスプリットブレインと呼ばれる現象が発生してしまう事があります。これを防ぐためにオンプレミス環境では、共有ディスクのロックステータスによるスプリットブレインを防止する構成を採用することが多いですが、 Google Cloud ではこの方式が採用できないため、代替構成として別のゾーンに配置したクォーラム デバイス ノードを利用した投票メカニズム等を検討する必要があります。以下は HA クラスタ ソフトウェアと代表的なスプリットブレイン防止する方法の例です。

  • Pacemaker ： Corosync を併用し、別ゾーンへクォーラム デバイスを構成する

  • Red Hat High Availability ： フェンスデバイスの利用

  • Windows Server フェイルオーバー クラスタリング ： ファイル共有監視の利用

  • Cluster Pro ： Ping 方式または HTTP 方式の利用

本構成におけるアンチパターンについて以下にて補足します。

• シングルゾーンのウォーム スタンバイ構成
  前述の通り、マルチゾーンのウォーム スタンバイ構成を採用することで、ゾーンのインフラストラクチャ等で障害が発生した場合に、正常稼働している他のゾーンで処理を引き継ぐことが可能となりますが、同一のゾーンに稼働系と待機系のインスタンスを配置してしまうと、これらの障害の際に同時に影響を受けてしまい、ワークロードを復旧する事が出来ないため、特別な要件が無い限りマルチゾーンでのウォーム スタンバイ構成を採用するのが良いでしょう。
  また、シングルゾーンの構成が必要な場合は、待機系インスタンス分の追加コストが発生するウォーム スタンバイ構成以外にも、可用性ポリシーのインスタンスの再起動動作として、インスタンスがクラッシュまたは停止した場合にインスタンスを自動的に再起動する構成にしたり、マネージド インスタンス グループを構成することで、アプリケーション ベースのヘルスチェックを使用する自動修復ポリシーを設定することも可能ですので、こちらもご検討下さい。

• スプリットブレインに対する対策が採用されていない構成
  マルチゾーンでのウォーム スタンバイ構成を採用する場合に懸念となるのが、ネットワーク機器の障害などによるスプリットブレインの発生と、それに伴うデータの不整合の発生です。こちらに関しては、前述の各 HA クラスタ ソフトウェアのスプリットブレインを防止するための構成を採用することで回避可能となるため、可能な限りこちらを採用することを推奨します。

• フローティング IP の代替構成としてエイリアス IP の利用
  フローティング IP の代替構成の選択肢としてエイリアス IP の利用も可能ですが、マルチゾーンの HA のデプロイには、1 つのゾーンに障害が発生した場合に、エイリアス IP を別のゾーンのインスタンスに再割り振りするには時間がかかる可能性があるため、前述の別の方法を採用することを推奨します。

アーキテクチャの解説

マルチゾーン ウォーム スタンバイ について、様々な構成要素の組み合わせが可能となりますが、本項では以下の OS / MW を利用し、DB サーバの HA クラスタ構成を中心にした、一般的な ウェブサービスのワークロードのサンプル アーキテクチャと各構成要素の解説を行います。なお、各構成要素の解説については本構成における考慮点の解説のみを行うため、概要や詳細などはそれぞれ記載した参考リンクや他のデザイン パターンの解説を参照ください。

• CentOS 8

• Pacemaker + Corosync

• MySQL 8

• Apache + php-fpm

本構成におけるポイントとサンプル アーキテクチャ図は以下となります。

• フロントエンドに関しては、ゾーン障害においても別のゾーンのインスタンスで処理を継続、必要に応じたオートスケーリングが可能なリージョン マネージド インスタンス グループを採用

• DB インスタンスに関しては、リージョン永続ディスクを利用した HA クラスタ構成を採用し、ゾーン障害の際にも処理が引き継げる構成を採用

また、 D ~ H の部分についてはマネージド サービスである Cloud SQL を利用する事が可能です。この場合のサンプル アーキテクチャ図は以下となります。

アルファベット記号に応じたサンプル アーキテクチャの各要素について、以下に解説を記載します。なお、ここでは本構成における特記事項のみの解説を行うため、詳細については各参照ドキュメントを参照ください。

A. 外部 HTTP(S) 負荷分散（External Load Balancing）
外部からの通信を負荷状況や障害発生状況に合わせて、適切に稼働しているバックエンド サービスに振り分けます。本構成ではバックエンド サービスとしてリージョン内の複数のゾーンにインスタンスを分散配置するリージョン マネージド インスタンス グループを採用する為、ゾーン障害発生時にも稼働が続いているインスタンスへ通信を振り分けます。また、外部 HTTP(S) 負荷分散自体もグローバル リソースの為、特別な構成を行うことなく、ゾーンやリージョンの障害の影響を受けずにサービス稼働を継続させることが可能です。

参考ドキュメント : 外部 HTTP(S) 負荷分散の概要

B. VPC ネットワーク（ VPC Network ）
Google Cloud では、 VPC を構成することにより、選択したリージョン内に共通のネットワークである、サブネットを構成することが可能で、このネットワークを利用し、マネージド インスタンス グループや Compute Engine のインスタンスなどを展開することが可能です。また、関連ルート、ファイアウォール ルールを含む VPC ネットワークはグローバル リソースの為、ゾーンやリージョンの障害の影響を受けることはありません。

参考ドキュメント : VPC ネットワークの概要

C. リージョン マネージド インスタンス グループ （Regional Managed Instance Group）
リージョン マネージド インスタンス グループを使用すると、アプリケーションを 1 つのゾーンに制限することや、異なるゾーンで複数のインスタンス グループを管理することなく、アプリケーションの負荷を複数のゾーンに分散できます。複数のゾーンを使用することで、ゾーン障害の発生時にも、アプリケーションは同じリージョンの別のゾーンで実行しているインスタンスからトラフィックの処理を続行する事が可能です。 また、 リージョン マネージド インスタンス グループを利用することで、ゾーン障害に対応可能な高可用性だけではなく、自動修復、Updater 機能を使用したアップデートのロールアウトによる運用負荷の軽減、負荷に応じた自動スケーリングの構成など様々なメリットがあります。

参考ドキュメント : リージョン MIG を使用したインスタンスの分散

D. 内部 TCP / UDP 負荷分散 （Internal Load Balancing）
本構成ではフローティング IP の代替構成として、内部 TCP / UDP 負荷分散を使用したHA クラスタ構成を採用し、フロントエンド インスタンスから DB インスタンスへの接続は内部 TCP / UDP 負荷分散の IP を利用します。また、内部 TCP / UDP 負荷分散では 3306 / TCP ポートへのヘルスチェックを構成し、 MySQL のインスタンスが稼働しているインスタンスへ通信を振り分けます。

参考ドキュメント : 内部 TCP / UDP 負荷分散の概要

E. 非マネージド インスタンス グループ （Unmanaged Instance Group）
内部 TCP / UDP 負荷分散の振り分け先として、マネージド インスタンス グループの設定が必要となりますが、前述のリージョン マネージド インスタンス グループの利用とは違い、 1 インスタンスのみを含むマネージド インスタンス グループをゾーンごとに 1 セットずつ構成することで単一のノードへ通信を振り分ける構成とし、HA クラスタの稼働系、待機系のインスタンスを構成します。
また、非マネージド インスタンス グループではマネージド インスタンス グループと違い、共通のインスタンス テンプレートを共有しない固有の VM として、通常の Compute Engine のインスタンス として構成した後に非マネージド インスタンス グループへ参加する手順となります。
なお、 MySQL のデータ保存に関しては後述のリージョン永続ディスクへ保存することでリージョン内のレプリケーションを行いますが、それぞれのインスタンスのブートディスクに関してはゾーン永続ディスクの利用で問題ありません。

参考ドキュメント : 非マネージド インスタンス グループ、非マネージド インスタンス グループの作成、 Google Compute Engine で MySQL をセットアップする方法 

F. Compute Engine - Quorum Server
このノードは Corosync のスプリットブレイン防止構成におけるクォーラム デバイスとして corosync-qnetd デーモンが実行され、HA クラスタの稼働系、待機系 と通信を行うことでネットワーク パーティションの検知とクォーラム ルール（多数決）による稼働インスタンスの決定を構成します。

参考ドキュメント : DRBD を使用した高可用性 MySQL 5.6 クラスタを Compute Engine にデプロイする

G. リージョン永続ディスク（Regional Persistent Disk）
リージョン永続ディスクを利用すると、同じリージョン内の 2 つのゾーン間でのデータの耐久性の高いストレージとレプリケーションを構成することが可能となり、両方のレプリカが使用可能な場合、両方のレプリカで書き込み内容が永続化されたときに、書き込みの確認応答が VM に返される為、同期の遅延などは通常発生しません。 また、ゾーン障害の際には、接続コマンドに --force-attach フラグを使用することにより、別のゾーンのインスタンスに接続することが可能です。 なお、リージョン永続ディスクはゾーン永続ディスクのパフォーマンス性能とは別定義となり、特にリージョン永続ディスクはインスタンスあたりの書き込みスループットが低くなるため、利用の際には注意が必要です。

参考ドキュメント : リージョン永続ディスク、リージョン永続ディスクのフェイルオーバー、 リージョン PD を使用した高可用性オプション

H. 永続ディスクのスナップショット（Persistent Disk Snapshot）
スケジュールによる定期的なスナップショットの作成により、ゾーン永続ディスクまたはリージョン永続ディスクからデータを定期的にバックアップすることが可能です。スナップショットのストレージ ロケーションとして、マルチリージョンや永続ディスク が配置されたリージョンとは別のリージョンへのバックアップの保管が可能であり、これによりリージョンの障害の際にもワークロードを別のリージョンで復元することが可能となります。加えて、HA クラスタ構成だけでは対応できないデータの破壊など、論理障害に対する備えにもなるため、可能な限りスケジュールによるスナップショットの定期作成を構成することを推奨します。
また、スナップショットでバックアップされるデータは永続ディスクに書き込みが完了しているデータのみとなるため、永続ディスクのスナップショットに関するベスト プラクティスを参考にアプリケーションのデータや、ディスク バッファをフラッシュしてファイル システムを同期した上でスナップショットの作成を行う事も検討ください。

参考ドキュメント : 永続ディスクのスナップショットの作成

I. Cloud SQL 高可用性構成
前述の通り HA クラスタ構成には複数のコンポーネントの組み合わせによる複雑な構成が必要となりますが、Cloud SQL HA 構成を採用することにより以下のようなメリットがあります。

• HA クラスタリング構成や、マルチリージョン バックアップについても事前定義されたマネージド サービスの機能を利用可能であり、複雑な構成を管理する必要がない。

• データベース プロビジョニング、ストレージ容量の管理など、構築、運用作業が自動化されている。

• バグの修正やセキュリティ パッチの反映などが自動反映される。

高可用性構成の Cloud SQL インスタンスはリージョン内のプライマリ ゾーンとセカンダリ ゾーンに配置され、各ゾーンの永続ディスクへの同期レプリケーションにより、プライマリ インスタンスへの書き込みのすべてがスタンバイ インスタンスにも反映されます。インスタンスまたはゾーンで障害が発生した場合、この構成によりダウンタイムが短縮され、クライアント アプリケーションで引き続きデータを使用できます。

参考ドキュメント : 高可用性構成の概要

J. プライベート サービス アクセス （Private Service Access）
VPC ネットワークでホストされている内部 IP アドレスでサービスを提供でき、プライベート サービス アクセスを使用すると、これらの内部 IP アドレスにアクセスできます。これは、VPC ネットワーク内の VM インスタンスから内部 IP アドレスで Cloud SQL のインスタンスに接続する際に利用可能です。

参考ドキュメント : プライベート サービス アクセス、プライベート サービス アクセスの有効化、プライベート サービス アクセスの構成

K. Cloud SQL インスタンスのバックアップ
Cloud SQL インスタンスの自動バックアップを構成することにより、定期的なバックアップを取得し、問題が発生しているインスタンスをバックアップから復元することができます。バックアップの保存先としてデフォルトでは冗長性を確保するためにバックアップ データを 2 つのリージョンに保存します。これにより、リージョンの障害が発生した場合でも別のリージョンでインスタンスを復元することが可能です。
また、バイナリログを有効にすることで、ポイントインタイム リカバリ（PITR）を使用することも可能です。ただし、ポイントインタイム リカバリではバイナリログが使用され、ログが作成される為、保存容量を使用します。バイナリログは、関連する自動バックアップによって自動的に削除されます。バイナリログによる予期しないストレージの問題を回避するには、バイナリログの使用時に合わせてストレージの自動増量を有効にすることをおすすめします。

参考ドキュメント : バックアップの概要、ポイントインタイム リカバリの構成方法 

そのほかの選択肢

• リージョン永続ディスク以外のデータ同期の方法
  本サンプル アーキテクチャではゾーン障害に備えた別ゾーンへのデータ同期はリージョン永続ディスクを利用した構成としていますが、 リージョン永続ディスク以外にも以下のようなデータ同期の方法を採用することが出来ますので、必要に応じて検討ください。

  • DRBD の利用
    Distributed Replicated Block Device（DRBD）を利用する事で、ネットワークを介したブロック デバイス レベルでのデータ同期を構成することが可能となり、Pacemakerと組み合わせる事で、レプリケーション構成の管理も含めた HA クラスタリングを構成することが可能です。
    
    参考ドキュメント : DRBD を使用した高可用性 MySQL 5.6 クラスタを Compute Engine にデプロイする

  • DB のレプリケーション機能の利用
    SQL Server AlwaysOn や MySQL Group Replication 等、利用する DB のレプリケーション機能を利用しデータ同期を構成することも可能です。この場合、HA クラスタリング構成も合わせて MW で実装、管理する事が可能なことが多く、単一ソリューションでのシンプルな構成を実現できるのもメリットとなります。
    
    参考ドキュメント : SQL Server AlwaysOn 可用性グループの構成、GCEとMySQLで実現する高可用性システム 

利点

この構成の主な利点は以下です。

• 本構成を採用することで、同一リージョン内で、可用性を高め、かつ運用も多くの範囲で自動化できます。多くの場合、インスタンスの自動リカバリー、 メンテナンスに対するライブマイグレーション、レプリケーションなどの運用の機能や監視の機能も提供されます。

• Compute Engine のインスタンスの SLA は >= 99.5% と定義されていますが、本構成を採用すると、 Instances in Multiple Zones に該当するため >= 99.99 % の SLA が適用されます。ただし、注意点として SLA は稼働を保証するものではない点、サービスにより異なる点、常に更新される点を考慮して、設計段階で要求仕様に合わせて確認してください。

• フェイルオーバーの条件や、前後の処理など、きめ細やかな設定が HA クラスタリング ソフトウェアにて実装可能です。

注意事項

• 前述の通り、マルチゾーン ウォーム スタンバイではリージョンの障害が発生した場合にはワークロードを復旧させる事が出来ません。この場合 マルチリージョン ロケーション や 別のリージョンの Cloud Storage へのスナップショットの作成による Backup & Restore にて、リージョンの障害が発生した際にワークロードを復旧させることが可能です。

• Cloud SQL を利用する際には、以下に注意する必要があります。

  • Cloud SQL では利用できない機能があるため、利用したい機能が利用可能か事前確認するのが良いでしょう。
    参考ドキュメント : Cloud SQL と標準 MySQL の機能の違い、Cloud SQL と標準 PostgreSQL の機能の違い、Cloud SQL で使用できない SQL Server の機能

  • Cloud SQL インスタンスでは、バグの修正、セキュリティ侵害の防止、アップグレードの実施のため更新が必要です。更新を適用すると、Cloud SQL でインスタンスが再起動され、サービスが中断される可能性があります。メンテナンス中、HA プライマリ インスタンスがスタンバイ インスタンスにフェイルオーバーすることはありません。ビジネスに対する影響を回避するため Cloud SQL メンテナンスウィンドウを設定し、メンテナンスの時間を事前に設定しましょう。また、バックアップなども業務要件に応じて設定すると良いでしょう。
    参考ドキュメント : Cloud SQL インスタンスでのメンテナンスの概要

このパターンで作成された事例

• Public

  • ポノス株式会社の導入事例： e スポーツ対応の対戦型ゲームを Compute Engine ベースで構築、レイテンシーの比較で最大 2 倍の差が採用の決め手

• Internal

  • ZIGExN : マイグレーション

  • Fuji Film : 社内ポータルサイト

関係するデザインパターン

• Dynamic site hosting Web

• ホスティング キャッシュ利用パターン

• SAP HANA on GCP の高可用性構成

参照ドキュメント

• 堅牢なシステムの設計 | Compute Engine ドキュメント

• インスタンス グループ | Compute Engine ドキュメント

• リージョン PD を使用した高可用性オプション | Compute Engine ドキュメント

• 高可用性構成の概要 | Cloud SQL for MySQL 

始める前に

• 事前準備として以下を実施します

  • Cloud Console のプロジェクト セレクタページで、プロジェクトを選択または作成します。

  • プロジェクトに対して課金が有効になっていることを確認します。
    参考ドキュメント : プロジェクトの課金設定を変更する

• Compute Engine API を有効にします。

• 次のテストを実施する事で、デプロイ済みクラスタの HA 機能をテストします

  • database1 インスタンスをシャットダウンして、マスター データベースが database2 インスタンスにフェイルオーバーするかどうかをテストします

  • database1 インスタンスを起動して、database1 がクラスタに正常に再参加できるかどうかを確認します

  • database2 インスタンスをシャットダウンして、マスター データベースが database1 インスタンスにフェイルオーバーするかどうかをテストします

  • database2 インスタンスを起動して、database2 がクラスタに正常に再参加できるかどうか、database1 インスタンスが引き続きマスターのロールを保持するかどうかを確認します

  • database1 をファイアウォール ルールで孤立させ、ネットワーク パーティション状態を作りだし、スプリット ブレインの問題をシミュレートします

クリーンアップ

注意: プロジェクトを削除すると、次のような影響があります。

プロジェクト内のすべてのものが削除されます。このチュートリアルで既存のプロジェクトを使用した場合、それを削除すると、そのプロジェクトで行った他の作業もすべて削除されます。

カスタム プロジェクト ID が失われます。このプロジェクトを作成したときに、将来使用するカスタム プロジェクト ID を作成した可能性があります。そのプロジェクト ID を使用した URL（たとえば、appspot.com）を保持するには、プロジェクト全体ではなくプロジェクト内の選択したリソースだけを削除します。

• Cloud Console でリソースの管理ページに移動します

• プロジェクト リストで、削除するプロジェクトを選択し、[削除] をクリックします

• ダイアログでプロジェクト ID を入力し、[シャットダウン] をクリックしてプロジェクトを削除します