このドキュメントでは、 Google Cloud上の MySQL デプロイメントにおいて高可用性（HA）を実現するアーキテクチャについて説明します。HA は、基盤となるインフラストラクチャの障害に対するシステムの復元性を表します。このドキュメントで取り上げる HA は、単一のクラウド リージョン内にある MySQL クラスタの可用性に対処します。
このドキュメントは、システム全体の稼働時間を改善し、MySQL データ層の信頼性を向上させる方法を必要としているデータベース管理者、クラウド アーキテクト、DevOps エンジニアを対象としています。このドキュメントは、Compute Engine で MySQL を実行している場合を対象としています。このドキュメントでは、Cloud SQL for MySQL を使用する場合は想定していません。
リクエストまたはトランザクションを処理するのに永続的な状態を必要とするシステムやアプリケーションでは、データクエリまたはミューテーションのリクエストを適切に処理するには、データ永続レイヤが使用可能である必要があります。アプリケーションがリクエストの処理を目的として、データ階層とやり取りする必要がある場合、データ階層のダウンタイムにより、アプリケーションが必要なタスクを実行できなくなります。
システムのシステム サービスレベル目標（SLO）によっては、より高いレベルの可用性を実現するアーキテクチャ トポロジが必要になる場合があります。HA の実現方法はいくつかありますが、アプリケーションにすばやくアクセスできるように冗長なインフラストラクチャをプロビジョニングする方法が一般的です。
このドキュメントでは、次のトピックについて説明します。
- HA データベースのコンセプトの理解に役立つ用語を定義します。
- HA MySQL トポロジの複数のオプションを解説します。
- 各オプションで検討すべき事項を把握するのに役立つコンテキスト情報を提供します。
用語
いくつかの用語や概念は、業界標準であり、本ドキュメントの範囲外の目的を理解するためにも役立ちます。
レプリケーション。書き込みトランザクション（INSERT、UPDATE または DELETE）が確実にキャプチャ、ログ記録され、トポロジ内のすべてのデータベース ノードに順次適用されるプロセス。
同期レプリケーション。プライマリ データベースとレプリカ データベースの両方に同時に書き込むことでリアルタイムのデータ整合性を確保する、データ レプリケーション方法。
準同期レプリケーション。プライマリ データベースと少なくとも 1 つのレプリカ データベースの両方に同時に書き込むことで限定的なデータ整合性を確保する、データ レプリケーション方法。
非同期レプリケーション。プライマリの更新とレプリカの更新の間の遅延を許容し、即時の整合性よりもパフォーマンスを優先するデータ レプリケーション方法。
ソースノード。データベースへの書き込みはすべて、ソースノードに転送する必要があります。ソースノードは、永続的なデータを最新の状態で読み取ります。
レプリカノード。ソース データベース ノードのオンライン コピー。変更は、ソースノードからレプリカノードにほぼ同期的に複製されます。レプリカノードからの読み取りでは、レプリケーション ラグのため、データが若干遅れる可能性があるので注意してください。
レプリケーション ラグ。トランザクションがソースノードに適用されたときとレプリカに適用されたときの差を表す時間計測。
稼働時間。リソースが動作し、リクエストへのレスポンスの提供ができている時間の割合。
障害検出。インフラストラクチャ障害が発生したことを特定するプロセス。
フェイルオーバー。スタンバイ インフラストラクチャ（この場合はレプリカノード）をプライマリ インフラストラクチャ（ソースノード）に昇格させるプロセス。
目標復旧時間（RTO）。フェイルオーバー プロセスを実行する際に、ビジネスの観点からデータ階層がオフラインであることが許容される実際の経過時間。
目標復旧時点（RPO）。フェイルオーバー プロセスを実行する際に、ビジネスの観点からデータの損失が許容される実際の経過時間。
フォールバック。フェイルオーバーが発生した後に以前のソースノードを復元するプロセス。
自己修復。オペレーターによる人的な外部アクションなしで問題を解決するシステムの能力。
ネットワーク パーティション。トポロジ内の 2 つのノード（ソースノードとレプリカノードなど）が、ネットワーク経由で相互に通信できない状態。
スプリット ブレイン。2 つのノードが同時に自身をソースノードであると認識している場合に発生する状態。
ノードグループ。サービスを提供するコンピューティング リソースタスクのセット。このドキュメントでは、データ パーシステンス層にあるサービスを意味します。
監視ノードまたはクォーラム ノード。スプリット ブレイン状態が発生した場合にノードグループの処理を決定する際に役立つ個別のコンピューティング リソース。
ソースまたはリーダー選出。監視ノードを含むピアアウェア ノードのグループが、どのノードをソースノードとすべきかを決定するプロセス。
ノードグループ。サービスを提供するコンピューティング リソースタスクのセット。このドキュメントでは、データ パーシステンス層にあるサービスを意味します。
ホット スタンバイ。別のソースノードのクロースコピーを表すノード。最小限のダウンタイムで新しいソースノードになります。
HA アーキテクチャを検討すべき場合
HA アーキテクチャは、データ層のダウンタイムに対する保護を強化します。ダウンタイムの許容範囲と、さまざまなアーキテクチャのそれぞれのトレードオフを理解することは、お客様のビジネス ユースケースに適したオプションを選択するために最も重要です。
HA のトポロジは、ワークロードとサービスの信頼性要件を満たすため、データ層の稼働率を高める場合に使用します。ある程度のダウンタイムを許容できる環境で HA トポロジを使用すると、不要なコストと複雑性が生じます。たとえば、開発環境やテスト環境の場合、データベース層に高可用性が必要になることはまずありません。
HA の要件を検討する
HA を提供するにはコンピューティング インフラストラクチャとストレージのコストが少なくとも 2 倍になることが予想されるため、コストは重要な検討事項です。このコストを、ダウンタイム発生時に想定される財務的影響と照らし合わせて徹底的に評価することが重要です。使用可能な MySQL HA オプションを評価する際には、次のことを検討してください。
- データ層に依存するサービスや顧客は何（誰）か。
- 運用予算はどのくらいか。
- データ永続層のダウンタイムが発生した場合のビジネスに対するコストはどのくらいか。
- プロセスをどのように自動化する必要があるか。
- どの程度の可用性を実現したいか（99.5%、99.9%、99.99%）。
- どれだけ早くフェイルオーバーする必要があるか。RTO と RPO はどのくらいか。
以下は復旧時間に寄与するものであり、RTO と RPO を確立する際はこれらを考慮する必要があります。
- 停止の検出
- セカンダリ仮想マシン（VM）インスタンスの準備状況
- レプリケーション タイプとバックアップの頻度
- ストレージのフェイルオーバー
- データベースの復旧時間
- アプリケーションの復旧時間
MySQL HA アーキテクチャ
最も基本的なレベルでは、データ層の HA は次の要素で構成されます。
- ソースノードの障害が発生したことを識別するメカニズム。
- レプリカノードがソースノードに昇格されるフェイルオーバーを実行するプロセス。
- アプリケーションのリクエストが新しいソースノードに到達するようにクエリ ルーティングを変更するプロセス。
- ソースノードとレプリカノードを使用して元のトポロジにフォールバックする方法（必要な場合）。
このドキュメントでは、次の 3 つの HA アーキテクチャについて説明します。
これらの各アーキテクチャは、インフラストラクチャの障害だけでなく、万が一のゾーン停止時のダウンタイムを最小限に抑えるためにも役立ちます。これらのアーキテクチャをドメイン ネーム システム（DNS）の変更と組み合わせてマルチリージョン HA を提供し、リージョン サービスの中断を防ぎます。ただしこのドキュメントでは、ゾーンの停止について説明します。
リージョン Persistent Disk を使用する HA
データ層の HA は常になんらかのデータ レプリケーションに依存します。最も単純なレプリケーションは、ユーザーが管理する必要がないレプリケーションです。
Compute Engine のリージョン Persistent Disk ストレージ オプションを使用すると、リージョン内の 2 つのゾーン間で同期データ レプリケーションを行うブロック ストレージ デバイスをプロビジョニングできます。リージョン Persistent Disk は、Compute Engine に HA サービスを実装するための強力な基盤を備えています。
次の図は、リージョン Persistent Disk を使用した HA のアーキテクチャを示しています。
インフラストラクチャの障害やゾーンの停止が原因でソースノードの VM インスタンスが使用できなくなった場合、リージョン Persistent Disk を同じリージョン内のバックアップ ゾーンにある VM インスタンスに強制的にアタッチできます。
このタスクを実行するには、次のいずれかを行う必要があります。
- 共有リージョン Persistent Disk にアクセスできるバックアップ ゾーンで別の VM インスタンスを起動します。
- バックアップ ゾーン内でホット スタンバイ VM インスタンスを維持します。ホット スタンバイ VM インスタンスは、使用中のインスタンスと同一の、実行中の VM インスタンスです。リージョン Persistent Disk をアタッチした後、データベース エンジンを起動できます。
データサービスの停止が迅速に特定されれば、強制アタッチ操作は通常 1 分以内に完了します。つまり、分単位の RTO を達成でき、RPO はゼロになります。
障害を検知して通信するために必要な追加のダウンタイムや、手動でフェイルオーバーを実行するために必要なダウンタイムを許容できるのであれば、プロセスを自動化する必要はありません。
RTO の許容範囲が低い場合は、検出とフェイルオーバーのプロセスを自動化します。このアーキテクチャを自動化すると、フェイルオーバーとフォールバックのプロセスに検討を要する複数のエッジプロセスがあるため、システムはさらに複雑になります。このアーキテクチャの完全に自動化された実装の詳細については、Cloud SQL 高可用性構成をご覧ください。
メリット
リージョン Persistent Disk を使用して HA を実現することには複数のメリットがあります。それらは次のような機能によりもたらされます。
このアーキテクチャは、ソースサーバー ゾーンのインフラストラクチャの障害、単一ゾーンのブロック ストレージの劣化、ゾーン全体の停止など、複数の障害モードに対して同時に保護を提供します。
リージョン Persistent Disk は、 Google Cloudによってフルマネージドされたブロックレベルのデータ レプリケーションを継続的かつ同期的に提供するため、アプリケーション レイヤやデータベース レイヤのレプリケーションは必要ありません。リージョン Persistent Disk が自動的にエラーと遅延を検出し、レプリケーション モードを切り替え、1 つのゾーンにのみ複製されたデータの状態に追い付きます。
プライマリ ゾーン内のストレージに問題が発生した場合、リージョン Persistent Disk は自動的にセカンダリ ゾーンからの読み取りを行います。このオペレーションで読み取りレイテンシが増加する場合がありますが、手動による対策を行わずにアプリケーションを運用できます。
考慮事項
このアーキテクチャの制限は、このトポロジの単一リージョンの特性と、リージョン Persistent Disk に固有の次のような制約に関連しています。
- リージョン Persistent Disk は 1 つのデータベースにのみマウントできます。スタンバイ データベースの VM インスタンスが実行されていても、そのインスタンスをデータベース読み取りの処理に使用することはできません。ただし、Google Cloud Hyperdisk の Balanced High Availability をマルチライター モードで使用すると、複数のインスタンスが同じディスクに対して読み取りと書き込みを行うことができます。Hyperdisk の詳細については、Hyperdisk についてをご覧ください。
- このアーキテクチャの基盤となるテクノロジーでは、同じリージョン内のゾーン間のレプリケーションのみが許可されます。そのため、このアーキテクチャのみを使用する場合、リージョン フェイルオーバーは使用できません。
- ゾーン Persistent Disk と比較して、リージョン Persistent Disk の書き込みスループットは半減されます。スループット上限が必要な許容範囲内にあるようにします。
- リージョンの Persistent Disk の書き込みレイテンシは、ゾーンの Persistent Disk よりわずかに高くなります。ワークロードをテストして、書き込みパフォーマンスが要件に対して許容できるかどうかを確認することをおすすめします。
- 障害イベントとその後のカットオーバーの間に、リージョン Persistent Disk をスタンバイ ゾーンの VM に強制的にアタッチする必要があります。強制アタッチ操作は通常 1 分以内に実行されるため、RTO を評価する際には、この時間を考慮する必要があります。
- RTO の推定は、リージョン Persistent Disk の強制アタッチと、VM ファイル システムによるホットアタッチされたディスクの検出にかかる時間を考慮する必要があります。
ホット スタンバイと監視ノードを使用する HA
自動フェイルオーバーが必要な場合は、別のアーキテクチャが必要です。1 つのオプションとして、少なくとも 2 つのデータベース ノードのグループをデプロイしてデータベースの非同期レプリケーションを構成し、監視ノードを起動して、ソースノードの選出中にクォーラムに到達できるようにします。
ソース データベース ノードは書き込みトランザクションを実行し、読み取りクエリを処理します。データベース レプリケーション プロセスは、オンラインのホット スタンバイ レプリカノードに変更を送信します。
監視ノードは小さな仮想マシンとして機能できるため、グループの過半数が確実にソースノードの選出に参加できるようにする低コストのメカニズムを提供します。
グループノードは、他のグループノードのステータスを継続的に評価します。これらのステータス チェックが数秒ごとに消費するシグナルはハートビートと呼ばれ、他のグループノードの健全性の評価に使用されます。ホット スタンバイのフェイルオーバーを開始できるよう、異常なソース データベース ノードを迅速に特定する必要があるため、データベース ノードをタイムリーに評価することが重要です。
ノードグループ クォーラムは、そのクラスタが適切に起動または実行を継続するために、アクティブなクラスタ メンバーに含まれている必要がある投票要素の数によって決まります。ソース データベース ノードの選出時にノードグループがクォーラムに到達するには、グループ内のノードの過半数が参加する必要があります。スプリット ブレイン状態時の対策として、多数決要件はネットワークが分割された場合に、2 つの投票グループが同時に投票するのに十分なノードを確保できないようにします。
グループの過半数は（n+1）/2 ノードから構成され、n はグループ内のノードの総数です。たとえば、グループ内にノードが 3 つある場合、ソースノードの選出のために 2 つ以上のノードが動作している必要があります。グループ内にノードが 5 つある場合は、少なくとも 3 つのノードが必要です。
ノードグループのサブグループ間の通信を妨げるネットワーク パーティションがある場合、グループのサイズは奇数の数のノードに調整されます。グループが偶数の場合、両方のサブグループが過半数を下回っている可能性が高くなります。グループサイズが奇数の場合は、いずれか 1 つのサブグループが過半数を上回るか、どのグループも過半数を下回っている可能性が高くなります。
次の図は、健全なノードグループと劣化したノードグループを比較したものです。
この図は、2 つのノードグループ（機能ノードグループと劣化ノードグループ）を示しています。完全に機能する健全なノードグループには、3 つのグループ メンバーがあります。この状態では、ソースおよびレプリカ データベース ノードは想定される目的を提供します。このノードグループに必要なクォーラムは 2 つのノードです。
劣化したノードグループは、インフラストラクチャの障害によりソースノードのハートビートが送信されなくなった状態を示します。この状態は、ソース データベース ノード インスタンスの障害の結果である可能性があります。またはソースノードが実行中である可能性があります。または、ネットワーク パーティションにより、ソースノードとグループ内の他のノード間の通信が妨げられる場合があります。
原因にかかわらず、その結果レプリカノードと監視ノードの両方がソースノードが正常な状態ではないと判断します。この時点で、グループの過半数がソースノードの選出を行い、ホット スタンバイ ノードがプライマリ ノードになるべきだと判断し、フェイルオーバーを開始します。
次の図は、監視ノード アーキテクチャにおけるデータベース トランザクション、レプリケーション、ハートビート フローを示しています。
上の図では、この HA アーキテクチャは、ホットスタンバイ レプリカノードを利用して、フェイルオーバー発生時に本番環境の書き込み処理をすぐに開始します。フェイルオーバーのメカニズム（ソースノード プロモーションなど）は、グループ内のデータベース ノードによって実行されます。
このアーキテクチャを実装するには、次の 2 つのプロジェクトを検討します。
- MySQL のグループ レプリケーションは、MySQL のオープンソース プラグインであり、HA トポロジの作成を容易にします。
- Galera クラスタと Percona XtraDB クラスタは、高可用性を実現可能なその他のオープンソース オプションです。
利点
ホット スタンバイ アーキテクチャには、可動部分がほとんどなく、デプロイが容易で、利点がいくつかあります。
- 低コストの監視ノードを 1 つ追加するだけで、完全に自動化されたフェイルオーバーが提供されます。
- このアーキテクチャは、長期的なインフラストラクチャの障害や一時的な障害（システムの再起動によるものなど）に効果的に対処できます。
- 一定程度のレプリケーションのレイテンシを関連付けることにより、マルチリージョンの HA を実現できます。
考慮事項
フェイルオーバーは自動的に行われます。ただし、その他に次の運用タスクを行う必要があります。
- ソースノードとレプリカノード間のレプリケーションを管理します。
- 監視ノードを管理します。
- ロードバランサを使用して接続ルーティングをデプロイし管理する必要があります。
- このドキュメントの範囲外であるアプリケーション ロジックへの変更を行うことなく、読み取りノードをレプリカノードにダイレクトできません。
オーケストレーターと ProxySQL を使用する HA
オープンソース コンポーネントのオーケストレーターと ProxySQL を組み合わせることで、停止状態を検出し、影響を受けたソースノードから新しく昇格したレプリカへトラフィックを自動的にフェイルオーバーするアーキテクチャを実現できます。
さらに、クエリを適切な読み取りまたは読み取り / 書き込みノードに透過的に転送して、定常状態のデータ層のパフォーマンスを向上させることができます。
オーケストレーターは、オープンソースの MySQL レプリケーション トポロジ マネージャーとフェイルオーバー ソリューションです。ソフトウェアにより、複雑なレプリケーション トポロジの検出、クエリ、リファクタリングが可能になり、信頼性の高い障害検出、インテリジェントな復旧、プロモーションを実現できます。
ProxySQL は、MySQL のオープンソースの高性能かつ可用性の高いデータベース プロトコル対応プロキシです。ProxySQL は、何十万ものバックエンド サーバーで何百万もの接続に対応できます。
次の図は、オーケストレーターと ProxySQL を組み合わせたアーキテクチャを示しています。
このアーキテクチャにおいて、前記の図で示されているように、データベースバインドされたトラフィックは内部ロードバランサによって冗長 ProxySQL インスタンスにルーティングされます。これらのインスタンスは、ProxySQL 構成に基づいて、書き込みまたは読み取り対応データベース インスタンスにトラフィックをルーティングします。
オーケストレーターは、次の障害検出と復旧ステップを行います。
- オーケストレーターは、ソースデータベース ノードが使用できないと判断します。
- すべてのレプリカノードに対してクエリが行われ、ソースノードのステータスに関するセカンド オピニオンが提供されます。
- レプリカが、ソースは使用できないという一貫した評価を提供する場合、フェイルオーバーが進行されます。
- トポロジで定義されているように、昇格したノードがフェイルオーバー時に新しいソースノードになります。
- フェイルオーバーが完了すると、オーケストレーターはトポロジに応じて、適切な数の新しいレプリケーション ノードがプロビジョニングされるように支援します。
ゾーン A のソース データベースと代替ゾーンのデータベース レプリカとの間の継続的なレプリケーションにより、レプリカをソースにルーティングしたレプリカが最新の状態に保たれます。オーケストレーターは、ハートビートを継続的に送信することで、ソース データベースとレプリカ データベースの正常性をチェックします。オーケストレーター アプリケーション状態は、別の Cloud SQL データベースに保持されます。トポロジの変更が必要な場合は、オーケストレーターからデータベースにコマンドを送信することもできます。
フェイルオーバーが完了すると、ProxySQL は新しいソースノードとレプリカノードにトラフィックを適切にルーティングします。サービスは、ロードバランサの IP アドレスを使用して引き続きデータ階層に対処します。仮想 IP アドレスは、以前のソースノードから新しいソースノードにシームレスに切り替わります。
利点
アーキテクチャ コンポーネントと自動化には、次のような利点があります。
- このアーキテクチャで使用するソフトウェアは、レプリケーション トポロジグラフやクエリ トラフィックの可視性など、さまざまなオブザーバビリティ機能を提供します。
- ProxySQL とオーケストレーターが連携して、レプリカの自動プロモーションとフェイルオーバーを提供します。
- レプリカのプロモーション ポリシーは、すべて構成可能です。他の HA 構成とは異なり、フェイルオーバーが必要になった場合に特定のレプリカノードをソースに昇格させることもできます。
- フェイルオーバー後、新しいレプリカはトポロジに従って宣言的にプロビジョニングされます。
- ProxySQL では、構成されたポリシーに基づいて読み取り / 書き込みリクエストを適切なレプリカノードとソースノードに透過的にルーティングするため、追加的な負荷分散のメリットを得られます。
考慮事項
このアーキテクチャでは、運用上の責務が増加します。また、次の点を考慮し、追加のホスティング費用が発生します。
- オーケストレーターと ProxySQL の両方をデプロイして維持する必要があります。
- オーケストレーターは、状態を維持するための独立したデータベースを必要とします。
- HA 用にオーケストレーターと ProxySQL の両方を設定する必要があるため、構成とデプロイがさらに複雑になります。
また、オーケストレーターはマルチソース レプリケーションをサポートしておらず、あらゆる種類の並列レプリケーションをサポートしていないため、Galera や Percona XtraDB などのクラスタリング ソフトウェアと組み合わせることはできません。現在の制限事項については、オーケストレーターに関するよくある質問をご覧ください。
次のステップ
- Cloud SQL 高可用性構成の詳細を確認する。
- リージョン永続ディスクを使用した高可用性オプションについて学習する。
- MySQL のグループ レプリケーションのドキュメントを確認する。
- Galera クラスタまたは関連する Percona XtraDB クラスタについて確認する。
- オーケストレーターのドキュメントを確認する。
- ProxySQL について学習する。
- Cloud アーキテクチャ センターで、リファレンス アーキテクチャ、図、ベスト プラクティスを確認する。