技術を知る：パブリッククラウド環境におけるデータベースの冗長化構成の構築方法
PostgreSQLインサイド

データベースをクラウドリフトする際には、クラウド特有の要素を考慮し、可用性と信頼性を確保する必要があります。本記事では、クラウド環境の例としてMicrosoft Azureを利用したデータベースの冗長化構成を取り上げ、クラウド特有の構築ポイント、構成例、および障害発生時の対応について説明します。

オンプレミス環境では、サーバー、ストレージ、ネットワーク機器といったハードウェアに加え、OS、ハイパーバイザー、仮想化ソフトウェアなどの全ての要素を自社で調達・構築・管理する必要があります。
一方、クラウド環境では、ハードウェアの調達、設置、設定といった物理的な作業は不要となり、仮想環境の基盤もクラウド事業者が管理します。この変化に伴い、クラウドサービスではクラウド事業者と利用者の間に「責任分界点」が設定され、インフラ基盤の責任範囲が明確に定められるようになりました。そのため、Azureなどのクラウド環境でシステムを構築する場合、この責任分界点を意識し、以下の2点に対応することが重要になります。

サービスレベルアグリーメント（SLA）

Azureは、ネットワークやストレージなどの可用性が担保された状態で提供されています。これらの稼働率やAzureの各サービスの可用性についてはSLAが公開されており、要件定義時に確認しておく必要があります。これを踏まえ、ネットワークやストレージなどの監視タイムアウト時間を調整するといった、各種タイムアウトの設定を検討することが推奨されます。

可用性ゾーン

Azureは、リージョン内に複数の可用性ゾーン（Availability Zone、以降AZ）を提供しています。AZは物理的に分離されたデータセンターであり、異なるAZにリソースを配置することで、単一障害点の回避に役立ちます。特に高可用性と事業継続性が求められるシステムでは、AZ障害時にもシステムを稼働させ続けるために、同一リージョン内の別のAZにデータベースを配置（複製）する、いわゆるマルチAZ構成が推奨されます。AZを適切に活用することで障害耐性が向上し、サービスの信頼性を高めることができます。

ここでは、データベースとしてFujitsu Enterprise Postgres（以降Enterprise Postgres）を利用する場合について説明します。Enterprise Postgresはエンタープライズ環境における可用性向上のため、データベース多重化機能を搭載しています。この機能の管理は、Mirroring Controller（以降MC）と呼ばれる機構が行います。

データベース多重化における重要な要件の一つに、スプリットブレインの防止があります。スプリットブレインとは、データベースサーバー間のネットワークで異常が発生し、互いのサーバーの状態を把握できなくなることで、両方のデータベースサーバーが同時にプライマリサーバーとして動作してしまう状態を指します。この状態になると、それぞれのサーバーが独立してデータの書き込みを受け付けるため、データの不整合や矛盾が発生し、システムの信頼性を損なうおそれがあります。そのため、データベース多重化機能には、データベースサーバーが相互の状態を正確に判断できない場合に、第三者としてデータベースサーバーの状態を客観的に判断し、必要に応じて異常なデータベースサーバーを隔離する機能が備わっています。この機能をインストールしたサーバーを「裁定サーバー」と呼びます。裁定サーバーを利用することで、異常なサーバーをシステムから隔離（フェンシング）し、スプリットブレインを防止できます。

データベース多重化機能が検知可能な異常としては、他にもOSやサーバーのダウンおよび無応答、データベースプロセスのダウンおよび無応答、ディスク障害、ネットワーク異常、ストリーミングレプリケーション異常が挙げられます。これを踏まえ、Enterprise Postgresを利用したマルチAZ構成の例を紹介します。

構成例

図1は、裁定サーバーをデータベースとは異なるAZに配置した、3つのAZを利用した構成の例です。この構成により、データベースが存在するAZで障害が発生した場合でも、裁定サーバーによる監視・制御が実行でき、スプリットブレインを防止できます。なお、裁定サーバーの可用性を確保するために、裁定サーバーの冗長化を推奨します。

図1：裁定サーバーを別AZに配置する構成

2つのAZで構成する場合は、裁定サーバーの代わりに、各データベースサーバー内で裁定処理を行う「裁定コマンド」の利用をご検討ください。詳細は、以下のオンラインマニュアルを参照してください。

• Fujitsu Enterprise Postgres 17 クラスタ運用ガイド（データベース多重化編）

ここまでは構成について説明しました。次の章では、Azure環境における障害対応について、注意すべきポイントや具体的な手順などを説明します。

クラウド環境への移行におけるシステム障害対策では、クラウドならではの特徴を考慮する必要があります。特にAzureのようなパブリッククラウド環境では、インフラの物理的な構成がブラックボックス化されているため、オンプレミス環境のように詳細な原因究明や切り分けが困難になる場合があります。そのため、Azure環境では、従来のシステム運用における「信頼性」「可用性」「保守性」の考え方をクラウドの特性に合わせて見直し、クラウド固有のリスクを考慮・検証した上で、システム全体の安定稼働を確保する必要があります。

本章では、Azure環境におけるデータベースの障害対応について、クラウドならではの視点で 対策を解説します。以下に、AZの障害が発生した場合のスプリットブレインを防止する 仕組みと、フェンシング方法について解説します。

3.1 スプリットブレインを防止する仕組み

スプリットブレインは、例えば、データベースのフェイルオーバー後に、意図せず元のデータベースサーバー（プライマリ）が再起動されたり、遮断されていたネットワークが復旧したりした場合などに発生しやすくなります。そのため、フェイルオーバー時に確実にフェンシングを実行することが、スプリットブレイン防止の重要なポイントです。データベース多重化機能には、フェイルオーバー時に障害が発生したデータベースサーバーをフェンシングする仕組みが備わっています。

以下に、AZ#1でAZ障害が発生した場合を例に、その仕組みを説明します。

1. 異常検知：AZ#2のMCが、AZ#1のデータベースサーバーに対する死活監視で異常を検知
2. 裁定依頼：AZ#2のMCから裁定サーバーへ、AZ#1のデータベースサーバーの状態確認を依頼
3. 裁定：裁定サーバーがAZ#1のデータベースサーバーの状態を確認し、正常/異常を判断
4. フェンシング：裁定サーバーがAZ#1のデータベースサーバーを異常と判断した場合、フェンシングを実行
5. 自動縮退：フェンシング成功で、自動縮退が実行され、スタンバイ側のデータベースがプライマリに昇格。フェンシング失敗で、自動縮退は中断

図2：AZ#1に障害が発生した場合

AZ#2でAZ障害が発生した場合も、同様の流れでフェンシングを実行できます。
なお、フェンシング処理については、システム要件に応じて適切なフェンシング方法を決定し、コマンドを作成する必要があります。このコマンドを「フェンシングコマンド」と呼びます。具体的な内容については、以下で例を用いて解説します。

3.2 フェンシング方法

クラウド環境におけるフェンシングとしては、データベースのフェンシングとネットワークのフェンシングという2つの手法が考えられます。

データベースのフェンシング

データベースのフェンシングでは、対象のデータベースサーバーを特定し、停止または隔離するなどの手法が考えられます。クラウド環境におけるデータベースの停止や切り離しの手段については、事前に検討・検証が必要です。具体的な手順は以下のとおりです。

ネットワークのフェンシング

ネットワークのフェンシングにおいては、切り離すべきネットワーク範囲の検討が重要です。障害時には、そのネットワークを隔離します。例えば、AZへのアクセスにロードバランサーを利用している場合、ロードバランサーの設定を変更し、障害が発生したAZへのトラフィックを遮断する、といった手法が考えられます。このように、障害が発生したAZへのデータ流入を防ぐことで、正常なAZのみで業務を継続させることが可能になります。

おわりに

本記事では、Azure環境におけるデータベースの可用性を最大限に高めるための冗長化構成と設計指針について解説しました。クラウド環境において、冗長化はビジネス継続性を担保するための不可欠な要素であり、障害発生時には確実なフェンシングを行い、サービスを継続することが重要です。
本記事が、Azure上でEnterprise Postgresをご活用いただく上で、システム構築のヒントとなれば幸いです。

2025年5月12日公開

本コンテンツに関するお問い合わせ