マルチAZ構成とは？失敗しない3つの設計判断軸と実務ポイント

マルチAZ構成では、同等の機能を持ったサーバーを複数リージョンへ分散配置させることになります。サーバーが複数あることで、1台構成のときには問題にならなかったことが課題になってきます。

マルチAZ構成を組む時の最も大きな課題は「データの整合性」です。システムの特性にもよりますが、WEBサーバーなど同等の機能を持ったサービス間では同じデータを保持する必要があります。

データの整合性を確保しつつ、最適なコストで環境構築するためには、次のようなデータの整合性について考慮する必要があります。

・データベース
・セッション情報
・画像等の静的ファイル
・プログラムファイル
・ログ

以降で、各データの整合性についての考慮点を説明していきます。

ユーザーのログイン情報など、一時的な情報をセッション情報といいます。セッション情報は、読み書き頻度が高いため、WEBサーバー内のメモリに保存されることが多くあります。

セッション情報をメモリ上に保存している場合、WEBサーバーが1台の時は問題無く動作しますが、複数台になると都合が悪い自体が発生します。ログイン時に作成されたセッション情報はログアウトまで参照され続けなければなりません。しかしながら、ログイン時と次の遷移で別のサーバー上で処理が行われた場合、セッション情報が存在せずにログイン状態が維持されない事態が発生します。

それを回避するためには大きく分けて二つの方法があります。

・ELBで振り分けサーバーの固定を行う（StickySession）
・ElastiCacheなどインメモリのデータベースを使う

画像などの静的コンテンツの共有方法も検討する必要があります。静的コンテンツが増えるタイミングは2つ考えられます。

・WEBサービスの利用者がアップロード
・管理者がアップロード

複数のWEBサーバー間で同じコンテンツを参照する必要があります。しかも、サービス利用者がアップロードする可能性があるので、参照だけでなく更新も同時に行えることが重要です。

AWSでは、ファイル共有サービスとして「Amazon Elastic File System（EFS）」が用意されています。EFSはEC2とNFSマウントが可能です。EFSを利用することで、WEBサーバー間で同一ファイルの参照・更新を行うことが可能です。

ただし、NFSマウントは、あまり性能が良くない。という課題があります。そのため、頻繁に読み書きが発生するファイルを保存する場合は注意が必要です。特に、プログラムファイルやログファイルはトラブルになることが多くあります。

プログラムをEFS上に置いた場合、アクセスが増えてくると性能の問題を引き起こすケースがあります。そのため、EFS以外の方法でファイル共有を検討する必要があります。

通常、プログラムを更新するのは管理者のみです。プログラムを更新する場合はマスタとなるサーバーを更新し、他のサーバーには自動同期させる。という運用ルールを決めることで、対応が可能です。マスタとなるサーバーで更新されたプログラムは、「lsyncd」等のミドルウェアを使い、自動的に他のWEBサーバーに反映させます。

他にも手動ですべてのWEBサーバーのコンテンツを更新する方法や、git等を使ってデプロイする方法も考えられるので、自社に合ったやり方を選択しましょう。

ログファイルの保存も検討が必要です。通常は、WEBサーバー自体に保存しておいても問題はありません。しかしながら、AutoScaling等を利用する場合は、サーバーの縮退とともにログも削除されてしまいます。それでは都合が悪い場合は、ログの保存場所も検討しましょう。

ログファイルにもよりますが、アクセスログなどは高頻度の読み書きが発生します。EFSなどに出力してしまうと、性能の問題を引き起こします。そのため、CloudWatchLogsやAmazon S3へ保存する方法がおススメです。