AWSでよく使われる冗長化構成の例を紹介｜データベースサーバーを冗長化する方法とは？

システム障害は日常的に発生している

 近年では、大手サービスで発生したシステム障害がニュースに取り上げられることも多くなってきました。サイトの規模に関わらずシステム障害は日常的に発生しています。 障害でウェブサイトが停止してしまう事態を避けるために、システムを冗長化して対策を取りましょう。 もし決済サービスであればユーザーは障害の間支払いできず、信頼を大きく損ねてしまうことがあります。また、ECサイトであれば障害でウェブサイトが停止している間は売上がゼロになってしまうでしょう。 このようにシステム障害がビジネスに与える影響は非常に大きい物となります。

どんな時にサーバーは止まってしまうのか

何らかの原因でサーバーが止まってしまうという事態は、実は簡単に発生します。 サーバーとは、例えるならば大きなパソコンのようなものです。そのため、部品の一部に故障や不具合が出れば電源が切れてしまいます。 また、地震や火災といった災害で停電が発生すれば、サーバーの電源が落ちることもあるでしょう。電源が正常でも、プログラムの不具合が原因で突如サーバーがフリーズしてしまう事も考えられます。 さらに、インターネットに接続しているサーバーであれば、外部からサイバー攻撃されて停止することも考えられます。 サーバー自体には問題がなくても、アクセスが急増したせいで回線容量が不足してしまうことでサーバーに繋がらなくなることもあります。 意外なところでは、間違ってシャットダウンしてしまったという人的ミス（オペレーションミス）も考えられます。つまり、どんなことでもサーバーが止まる原因になり得るということです。

AWSを使っていれば安心という訳ではない

上記のようなトラブルについて、AWSのようなクラウドサービスならサーバーは落ちないという訳ではありません。 実は、AWS本体にも小さな障害はよく発生しています。 障害以外にも、EC2インスタンスが強制的に再起動されたり、RDSでデータベースのバックアップが完了するまでの間データベースにアクセスできなくなるなどといった事態は日常的に起こります。

冗長化とは何か

「冗長化」とは、同じ役割をもつ機械を複数用意して、システムの一部に障害が発生しても全体が止まることがないようにする事です。 例えばウェブサーバーが1台だけしかない場合、エラーなどでサーバーが止まってしまえばウェブサイトは停止してしまいます。 この時、ウェブサーバーが2台あれば、何らかの原因で片方が停止してしまっても、残った1台の方を動作させることでウェブサイトを止めることなくサービス提供を続けられます。

冗長化とコスト

前述のように、ウェブサーバーを冗長化すればウェブサイト停止を避けられますが、そのためにはサーバーをもう1台準備する必要があります。 すべての機器の予備を用意すると、サーバー費用も倍になってしまう事になります。 そのため、現時点で何台ものサーバーを使ってシステムを動作させている場合は、機器の費用が大幅にアップしてしまう覚悟が必要です。 AWSであればインスタンスの数を増やす事になります。サーバー実機を増やすよりも手軽ですが、やはりコストは増加してしまいます。

最初に決めておく事

システムを停止できる時間（ダウンタイム）がどれだけ許されるのかを決定しましょう。どんな事があっても絶対止まらないサーバーが理想ですが、それを実現しようとするとコストもどんどん高くなってしまいます。 「24時間ノンストップなのか」「定期的にメンテナンスのために停止できるのか」または「停止可能であればどれくらいの時間停止を許容できるのか」など、条件次第で冗長化の手法も変わります。 それに伴って、かかる手間やコストも大きく変わってきますので、ダウンタイムをしっかりと決めることが重要です。

単一障害点をなくす

冗長化構成を考えるにあたり重視するポイントは、「単一障害点」を無くすことです。「単一障害点」とは、その部分が停止すると全体が停止してしまう部分です。 例として、ウェブサーバーが2台、データベースサーバーが1台（冗長化されていない）の場合を考えてみましょう。 ウェブサーバーは予備があるため、一方が停止してもウェブサイトは継続できます。しかし、データベースサーバーに障害が発生してしまうと、予備がないためウェブサイトは停止してしまう事になります。 この場合は、データベースサーバーが単一障害点となっています。

AWSでよく使われる冗長化構成の例

ウェブサーバーを冗長化する

AWSで動作するウェブサイトであれば、最初にウェブサーバーの冗長化を考える事になります。 ウェブサーバーはアクセス状況の変化の影響を受けやすく、複雑なプログラムが動作する事からトラブルが発生しやすいサーバーです。 インターネットに直接接続されているため攻撃のターゲットとなりやすいといった性質もあります。

ロードバランサーを使用する

AWSで用意されているロードバランサー（ALB・ELB）を作成し、インターネットからのアクセスはすべてロードバランサーを経由するようにしましょう。 ロードバランサーはEC2インスタンスの負荷状況に応じて複数のウェブサーバーにアクセスを割り振ってくれます。 EC2で複数のウェブサーバー用インスタンスを起動し、ロードバランサーに関連付けます。仮にEC2インスタンスに障害が発生した場合は、自動的にロードバランサーから切断されます。

サーバー間のデータを同期する

ロードバランサーを用意して複数のウェブサーバーを動作させる場合、ファイルなどの内容を一致させる必要があります。 ウェブサーバー間のファイルを同期するにはいくつかの方法があります。代表的な方法はcronを使用して、定期的にrsyncコマンドを実行しファイルを同期する方法です。 ログインなどの機能でCookieを使用しているウェブサイトの場合は、ELBのスティッキーセッションを設定することで対応できます。 なお、サイトの規模によってはセッション情報をデータベースに格納する仕組みを取るほうが確実な場合もあります。 また、画像ファイルなどの静的リソースは、AWS S3などウェブサーバー外のサービスへ配置する事も検討してください。冗長化かつ負荷分散の構成にもなります。

データベースサーバーを冗長化する

データベースサーバーを冗長化する方法を紹介します。 データベースサーバーの冗長化に興味がある方は是非ご覧ください。

MySQLデータベースをレプリケーションする

MySQLが提供する機能でレプリカ（複製）を作成して冗長化構成を取る方法です。マスターサーバーのデータに加えられた変更をスレーブサーバーに転送する事で実現されます。 マスターサーバーに障害が発生した場合、スレーブサーバーをマスターへ昇格させる事でシステム停止を避けられます。

AWS RDSでMultiAZ配置を使う

AWSのデータベース専用サービスRDSで、MultiAZ配置を選択するだけで冗長化構成にする事ができます。障害が発生した際の切り替えや復旧もほぼ自動化されているため、おすすめの方法です。 RDSは、シングル構成で使用するとバックアップやセキュリティパッチの適用で短時間の停止が発生してしまう事もありますが、MultiAZ構成にしていればその心配も不要です。 アベイラビリティーゾーン（1つのデータセンターのようなものです）をまたいで複数のデータベースインスタンスが起動し、自動的に同期が行われます。 片方のインスタンスやアベイラビリティーゾーン全体に障害が発生しても、もうひとつのアベイラビリティーゾーンに自動的に切り替わるため、システム停止を避けられます。

WordPressの冗長化

冗長化したいサイトがWordPressで作成されている場合、Amazon Lightsailを使用するのも一つの選択肢となります。 EC2を使用する場合はゼロからのサーバーの構築となるためサーバー管理の知識が必須です。 Lightsailは、最初からWordPressに対応しているため、細かな設定不要で冗長化構成のWordPressサイトを用意する事ができます。

まとめ

 本記事では、AWSでシステムの冗長化構成を取る手法を紹介しました。 一言で「冗長化」といっても、単一機器の冗長化からシステム全体まで、範囲は非常に広いものとなります。 それぞれの部分でいくつもの手法・選択肢があり、システムの重要度や停止時間といった要件にあわせて選択していく事になります。 段階を追ってAWSで冗長化構成を組み、落ちないウェブサイトを目指しましょう。