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

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

ほとんどのワークロードで可用性を考慮した設計は重要ですが、求められる要件はワークロードによって異なるため、ワークロードのアーキテクチャを考える上で、そのワークロードがどのレベルの可用性を実現する必要があるかを考えることが重要となります。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 と RPO の値が小さいほど(つまり、アプリケーションを中断状態から復旧する時間が急がれるほど)、アプリケーションの実行コストは高くなります。次のグラフは RTO / RPO に対するコストの割合を示しています。

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

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

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

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

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

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

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

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

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

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

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

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

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

アーキテクチャの解説

マルチゾーン ウォーム スタンバイ について、様々な構成要素の組み合わせが可能となりますが、本項では以下の OS / MW を利用し、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 構成を採用することにより以下のようなメリットがあります

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

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

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

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

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

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


そのほかの選択肢


利点

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


注意事項


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


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


参照ドキュメント


始める前に

MySQL 用インスタンス とリージョン永続ディスクの作成

database1 のセットアップと、MySQLのインストール

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

この設定により、クラスタを構成して、今後 3 つ目のノードをクォーラム デバイスとして追加するときに備えることができます

クラスタの起動

クラスタ リソースを管理するように Pacemaker を構成する

クォーラム デバイスを構成する

クラスタのステータス確認

クラスタ IP として内部ロードバランサを構成する

(Optional)MySQL への接続テスト

(Optional)Cloud SQL HA 構成の作成

アーキテクチャの解説で記載したとおり、 MySQL の部分を HA 構成の Cloud SQL にて行うことも可能です。その場合のサンプル コンフィグについて解説します

作成が成功すると、以下のように VPC からアクセス可能なインスタンスのPRIVATE_ADDRESS が表示されます

リージョン マネージド インスタンス グループの作成

外部 HTTP(S) 負荷分散の作成

また、以下コマンドで表示される予約された 外部 IP アドレスを記録します

動作確認

(Optional)スナップショットの作成

前述の通りスナップショットの作成を組み合わせることにより、リージョンの障害や論理障害に備えることが可能となります。必要に応じて以下のサンプル コマンドを参考にスナップショットの作成を構成ください
※ 以下の手順については永続ディスクへのデータ同期については十分考慮されていない可能性がある為、必要に応じて永続ディスクのスナップショットに関するベスト プラクティスを参照し、要件に応じた実装方法を検討ください

クリーンアップ

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

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

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