BLOG

2020 年 12 月 17 日

AWS の可用性の向上例を見てみよう！～ 2. HA クラスターで行う可用性の向上～

前回の記事では、AWS 上で単体で行う可用性の向上例を紹介しました。今回は複数台のインスタンスを使用する、HA クラスターについて紹介します。本記事ではまず、HA クラスターがどのようなものであるかを紹介し、その後実際の構築例を 2 つ紹介していきます。そして最後に 2 つの構築例にそれぞれにどのような特徴があるかを比較していきます。
本記事で紹介する構成の詳しい構築方法はホワイトペーパーに記載してありますので、ぜひダウンロードしてみてください！

HA クラスターとは

はじめに HA クラスターについて紹介します。HA は High Availability の略で高可用性を意味し、クラスターは複数台のマシンをひとまとまりにしたシステムを表します。そのため、HA クラスターは、複数台のマシンを使い可用性を向上させたシステムを意味します。一般的な HA クラスターの構成は以下の図のようになります。

この図の構成では、2 台のマシンを使用した HA クラスターとなっています。片方のマシンでサービスを提供し、そのマシンに障害が発生した場合にもう片方のマシンにサービスを引き継ぎます。そして、障害の起きているマシンが復旧した場合は、サービスを元のマシンに戻します。この構成で、通常時にサービスを提供しているマシンは現用系、障害時にサービスを引き継ぐマシンは待機系と呼ばれます。また、このサービスを引き継ぐことをフェイルオーバー、サービスを元の現用系に戻すことをフェイルバックと言います。
このように、現用系と待機系の 2 台構成にすることで、ソフトウェアの障害だけでなくマシンの物理的な故障にも対応できます。さらに、既に起動しているマシンでサービスを起動するため、ダウンタイムを最小限にすることができます。今回はこの HA クラスターを、弊社製品である MIRACLE CLUSTERPRO X を使用して構築を行います。

MIRACLE CLUSTERPRO X とは

MIRACLE CLUSTERPRO X は、HA クラスターの構築を行うソフトウェアです（以降 MCPX とします）。前回の記事で紹介した Miracle FailSafe for CentOS は、単体の可用性向上を目的とした MCPX の派生製品となります。MCPX には次のような特徴があります。

Web UI で簡単に HA クラスターを構築することができる
Web UI で現在の状況の確認、フェイルオーバーやフェイルバックを行うことができる
カーネルパニックや物理的な故障、異常高負荷などのさまざまな障害を探知できる
障害時に自動で行う復旧動作を詳細に設定することができる

これらの特徴を活かし HA クラスターを構築することで、システムの可用性を最大限高めることが可能になります。

実際に HA クラスターの構築例を確認してみよう

それでは、AWS 上での HA クラスターの構築例を確認してみましょう。今回も前回と同様に、

CentOS 8
Apache HTTP Server
MariaDB
PHP

の LAMP 環境を構築します。LAMP 環境の構築の確認には、データベースにアクセスする簡単な PHP プログラムを使用します。
今回は HA クラスターを構成する 2 台のインスタンスを、異なるアベイラビリティゾーンに配置する Multi-AZ を行います。アベイラビリティゾーンは、第 1 回で紹介したようにそれぞれ独立したデータセンターとなっています。そのため、Multi-AZ 配置にすることで、データセンター単位の障害にも対応することが出来るようになります。今回は東京リージョン（ap-northeast-1）の、ゾーン A （ap-northeast-1a）とゾーン C（ap-northeast-1c）にインスタンスを 1 つずつ配置します。構築方法は 2 種類紹介しますが、大きな違いはデータベースの位置のみとなっています。

RDS を使用する共有方式

まずは、データベースに RDS という AWS 上のサービスを使用し、HA クラスターを構築する方法を紹介します。

RDS とは

RDS は、データベースサーバを提供する AWS 上のサービスです。AWS マネジメントコンソールから構築することができ、データベースサーバのパフォーマンスなどを容易に変更できるという特徴があります。RDS で使用可能な DB の種類は MariaDB, PostgreSQL などを含む 6 種類となっています。また、Multi-AZ 配置も可能となっており、データベースサーバ自体の可用性も高めることが可能です。

構成

それでは HA クラスター構成を確認していきましょう。構成は次の図のようになります。

この構成では、2 台の EC2 インスタンスをゾーン A とゾーン C にそれぞれ配置し、MCPX を使い HA クラスター構成にしています。データベースには RDS を使用しているため、インスタンスの上で動くアプリケーションは Apache, PHP となります。これらのアプリケーションは通常時、現用系のインスタンス上で実行されますが、現用系に障害が発生した場合はフェイルオーバーが行われ待機系で実行されます。RDS は独立したデータベースサーバのため、フェイルオーバーが行われても、待機系から再度接続するのみとなります。
フェイルオーバーが行われた場合、アプリケーションの動作しているサーバが変更されるため、サービスを提供するサーバの IP アドレスが変わってしまいます。そのままでは、利用者側がアクセスするサーバを変える必要がありますが、MCPX で仮想 IP というリソースを使うことにより解決することが出来ます。仮想 IP は実際には存在しない IP アドレスですが、宛先のインスタンスが MCPX によって自動で制御されることで、常にサービスを提供しているサーバにアクセスすることが可能となります。

実際の動作画面

それでは、実際の構成を確認してみましょう。HA クラスターの設定完了時は次の画像のようになります。

設定について、まずはグループの項目から説明します。このグループはフェイルオーバーグループと呼ばれるもので、その配下にある要素はグループリソースと呼ばれます。フェイルオーバーグループは、フェイルオーバーが行われるときの単位となり、グループ内の全てのグループリソースが待機系へと移されます。今回の場合は、グループ failover に含まれる、awsvip, exec-httpd, exec-php-fpm の 3 つのグループリソースが、フェイルオーバー時に待機系へと移されます。また、グループリソースは様々な動作を行う単位となっており、今回の 3 つのグループリソースはそれぞれ次のようなものになります。

リソース名	リソースの内容
awsazw	AWS のアベイラビリティゾーンの健全性を監視する
awsvipw	AWS の VPC 内で仮想的な IP アドレスを設定する
exec-httpd	Apache のサービスである httpd を実行する
exec-php-fpm	PHP を実行するためのサービスである php-fpm を実行する

このように、Web サーバに必要な要素をグループリソースとしてグループにまとめることで、必要な要素を一括でフェイルオーバーすることができるようになります。

次にモニタの項目について説明します。このモニタの項目の要素はモニタリソースと呼ばれ、様々な項目を監視するリソースとなっています。今回は次のようなモニタリソースを設定しています。

リソース名	リソースの内容
awsazw	AWS のアベイラビリティゾーンの健全性を監視する
awsvipw	awsvip によって仮想 IP が正常に設定されているかの監視を行う
psw-httpd	httpd が実行されているかをプロセス名の監視によって行う
psw-php-fpm	php-fpm が実行されているかをプロセス名の監視によって行う
userw	ユーザ空間のストールを監視する

このように、提供するサービスやシステムの環境に沿ったモニタリソースを設定することで、様々な障害を検知することができます。また、それぞれのモニタリソースに対して障害時の復旧動作を、詳細に設定することが出来ます。今回は実際に psw-php-fpm の復旧動作を、「psw-php-fpm が障害を検知した場合は exec-php-fpm を再起動。再起動を 3 回以上リトライした場合はフェイルオーバー」と設定しています。

それでは実際にクラスターの動作を確認してみましょう。クラスターを起動すると、以下の画像のような状態になります。グループリソースが全て起動し、モニタリソースもすべて正常となっています。

今回の環境では、rds01 の IP アドレスは 10.0.10.xxx、rds02 は 10.0.20.xxx となっており、仮想 IP は 10.1.0.1 に設定してあります。今の状態では rds01 側で awsvip リソースが起動しているため、仮想 IP にアクセスすると rds01 へと接続されます。実際に仮想 IP にアクセスすると、次の画像のように正常にテストページを確認することができます。

今回は例として、php-fpm をコマンドラインより終了させ、フェイルオーバーが自動で行われることを確認します。コマンドラインから php-fpm を終了させるコマンドを打つと、一時的に終了しますが、数秒経つと再び起動状態になります。これは MCPX が php-fpm のプロセスが消えたことを検知し、障害と判断して再起動という復旧動作を行ったためです。今回はリトライの最大回数を 3 回としているため、続けて php-fpm を終了させると、下の画像のようにフェイルオーバーが行われます。

先ほど説明したように、フェイルオーバーはグループ全体で行われるため、全てのリソースが rds02 へと移動しています。そのため、rds02 側で awsvip リソースが起動しており、仮想 IP にアクセスすると rds02 へと接続されます。仮想 IP にアクセスすると同じようにテストページが表示されますが、実際には提供しているサーバが rds01 から rds02 へと変わっています。

このようにして、サービスの利用者にほとんど気付かせることなく、継続してサービスを提供することが出来ます。
そして、現用系の復旧が完了した場合はフェイルバックを行うことで、再び現用系でサービスを稼働させることが可能になります。　

EBS を使用するミラー方式

次に、データベースのデータの保存に EBS を使用し、HA クラスターを構築する方法を紹介します。

EBS とは

EBS は、ブロックストレージを提供する AWS 上のサービスとなっています。EC2 インスタンスのストレージにはこの EBS が使われています。そのため、EBS は EC2 インスタンスにアタッチすることで、追加ストレージという形で使用できます。今回はアタッチした EBS を、データミラー用のストレージとして使用します。

構成

それでは HA クラスター構成を確認していきましょう。構成は次の図のようになります。

この構成でも同様に、2 台の EC2 インスタンスをゾーン A とゾーン C にそれぞれ配置し、MCPX を使用し HA クラスターを構成にしています。しかし、今回はデータベースサーバも EC2 インスタンス上で実行します。そのため、インスタンス上で動くアプリケーションは、Apache, PHP, MariaDB となります。EBS はデータベースのデータを保存するストレージとして使用され、インスタンスにアタッチされたそれぞれの EBS は MCPX によってミラーリングされます。そのため、フェイルオーバーが行われた際に待機系で MariaDB が実行されると、フェイルオーバー時点の最新のデータに再びアクセスすることが可能になります。IP アドレスに関しても RDS を使用した構成と同じように仮想 IP を使用することでアクセスが可能です。

簡単な構築方法・実際の動作画面

それでは、実際の構成を確認してみましょう。HA クラスターの設定完了時は次の画像のようになります。

グループの項目で RDS の設定と異なる点は、exec-mariadb と md というグループリソースが追加されていることです。それぞれのリソースは次のようなことを行います。

リソース名	リソースの内容
exec-mariadb	MariaDB-Server のサービスである mariadb を実行する
md	ミラーディスクの同期を行う

EBS による方式では、HA クラスターのインスタンス上でデータベースサーバを実行します。そのため、MariaDB を実行するために exec-mariadb が必要となります。また、それぞれの EC2 インスタンスの EBS の内容をミラーリングするためのリソースである md が必要となります。
次に、モニタリソースの項目で異なる点についてです。追加されているモニタリソースは次のような監視を行います。

リソース名	リソースの内容
mdnw1	ミラーリングを行うネットワークの監視を行う
mdw1	ミラーディスクのデータの状態などの監視を行う
psw-mariadb	mariadb が実行されているかをプロセス名の監視によって行う

mdnw1 と mdw1 は、ミラーリングが問題なく同行われているかについて監視するモニタリソースとなっています。また、mariadb が正常に実行されているか確認するモニタリソースも追加されています。

それでは実際にクラスターの動作画面を確認してみましょう。クラスターを起動すると以下の画像のような状態になります。

ミラーディスクの状態も Web UI から確認することが出来ます。現在は現用系である ebs01 でサービスが提供されているため、ディスクも ebs01 側が活性状態となっています。

サービスの利用者側から見た動作は RDS を使用した場合と同じなため、詳しくは説明しませんが、実際には常にディスクがミラーリングされています。

各方式の特徴

それでは、今回紹介した RDS を使用する共有方式と、EBS を使用するミラー方式の比較を行っていきましょう。比較は次の表の通りになります。

項目	RDS を使用する共有方式	EBS を使用するミラー方式
データベースサーバ	DB インスタンスが必要	HA クラスターを構成している EC2 インスタンス上で実行
同期	不要	必要
Multi-AZ	可能	HA クラスターを構成している EC2 インスタンスが Multi-AZ 配置の場合は、必然的に Multi-AZ 配置になる

まず、データベースサーバの項目についてですが、RDS は独立したデータベースサーバとなるため、それ専用の DB インスタンスが必要となります。その一方で、EBS を使用する方式では、HA クラスターを構成している EC2 インスタンス上でデータベースサーバを実行するため、新たに DB インスタンスは必要になりません。そのため、最低限必要なインスタンスの数は EBS を使用する方式のほうが少なくなります。しかし、RDS は独立した DB インスタンスのため、データベースサーバへの負荷が大きい場合に、データベースサーバのみの処理能力を容易に高めることが出来るなどの利点があります。
次に、同期の項目についてです。RDS は独立したデータベースサーバのため同期の必要はありませんが、EBS を使用する方式の場合はそれぞれの EBS 間でデータ同期する必要があります。これは、フェイルオーバー後も最新のデータで問題なく業務を継続できるようにするためです。EBS は同期の必要があるため、書き込み性能が RDS に比べて低下するという特徴があります。
最後に、Multi-AZ の項目についてです。RDS では作成時にオプションで Multi-AZ 構成にすることが可能です。また、EBS を使用する方式の場合でも、EC2 インスタンスが Multi-AZ 配置の場合は必然的に EBS も Multi-AZ 配置となります。これは、EBS は同じ AZ のインスタンスのみにしかアタッチ出来ないためです。
これらの比較結果から、RDS による方式は、データベースサーバに要求される性能が高い場合に向いていると考えられます。そして、EBS による方式は、データベースサーバへの書き込みが少なく、要求される性能が高くない場合などに向いていると考えられます。

まとめ・次回予告

今回は複数台のマシンを使用した HA クラスターの構築例について紹介しました。どちらの方法でも HA クラスターを構築することは可能ですが、データベースサーバに求められる性能によって選ぶことができます。今回紹介した例の構築方法は、記事の最後のホワイトペーパーに記載していますので、ぜひダウンロードしてみてください。
次回は Miracle FailSafe で行った単体インスタンスの可用性の向上を、より高める方法について紹介します。AWSのサービスを活用した高度な構成となっていますので、次回もぜひ楽しみにしてください！