クラウド時代のHA（冗長化）

HAの具体的な導入方法

前ページで示したシステム構成例では、ステートレスにリクエストに応えることができます。また、共有ストレージを利用してセッション情報を共有しています。このため、各レイヤーごとにサーバー要素を容易に追加／削除できます。

例えば、ロード・バランサ（Linux LVS）に対するWebサーバー（nginx）の追加は、以下のように非常に簡単です。

設定例1: ロード・バランサへのWebサーバーの追加

Webサーバーをさらに追加／削除するには、以下のコマンドを実行します。

設定例2: Webサーバーの追加／削除

Webサーバー（nginx）の設定も、アプリケーション・サーバーのIPアドレスとポート番号を追加記述するだけです。

設定例3: Webサーバー（nginx）の設定

このWebシステムで唯一問題となるのは、データベース・サーバーです。SQLデータベースのクラスタ化やレプリケーションの設定は、少し複雑です。PostgreSQLでは、例えば、WAL（Write Ahead Logging、トランザクション・ログの先行書き込み）の設定、マスターDBからセカンダリDBに更新情報を伝える設定、障害発生時にセカンダリがマスターに昇格する設定、などを施します。これらの設定については割愛します（Linux HA関連資料を参照のこと）。

もちろん、上記のシステム構成例とは異なる類似の製品を使うことも可能です。例えば、ロード・バランサとして米F5 Networksのアプライアンス「BIG-IP」を、WebサーバーとしてApacheを、アプリケーション・サーバーとしてJettyベースのものを活用することなどが可能です。Webサーバーとアプリケーション・サーバーの間にHA用のプロキシを設置することも可能です。つまり、設定方法は無限に存在します。

スケール・アウト／スケール・イン

Webシステムは、システムを構成する個々の要素が冗長化されており、Webシステム自身がリクエストを各リソースに分散する方法を知っています。このため、スケール・アウト方式により、容易に性能を拡張できます。ボトルネックになっているレイヤーに、そのサーバーを追加するだけで済みます。

具体的には、性能面での問題が、HTMLのような静的ファイル処理の場合、Webサーバーを追加し、その内容をロード・バランサに反映します。アプリケーション層がボトルネックになっている場合は、アプリケーション・サーバーを追加し、Webサーバーやロード・バランサの設定を更新します。

スケール・アウトが可能なシステム環境では、物理サーバーのリプレースも容易です。必要な作業は、障害が発生したサーバーをシステムから取り除き、新規のサーバーを設定するだけです。この作業によるアプリケーションへの影響はありません。利用時間帯が異なる複数のアプリケーションを運営している場合は、それぞれのアプリケーションの稼働時間に応じてリソースを追加／削除する運用も可能です。

まとめ

ここまで解説してきたように、HAシステムは構成が複雑です。こうしたシステムを手作業で維持するのは非常に困難です。このため、システム・リソース同士の関係や設定を維持・管理するオーケストレーションを自動化できる運用管理ソフトの導入を推奨します。リソースやアプリケーション、サービスの追加／削除を容易に実現可能な仕組みが必要です。

例えば、モーフ・ラボが提供する「mCloudシリーズ」を活用することで、複雑なHAシステムの環境を簡素化することが可能になります。システムの監視・運用を自動化しつつ、開発者やテスト担当者といったクラウドの利用者からmCloudシリーズを直接利用することが可能です。これにより、スケール・アウト／スケール・インが容易になります。

何を使うにせよ、クラウドには、完全自動管理型の運用管理ソフトを推奨します。ユーザー管理、課金、利用者が自らプロビジョニングできる機能などを含んだソフトです。このようなソフトを導入すると、IT投資への回収が、より短期に実現できます。日々の運用作業を単純化することが可能になるため、本来の業務である開発作業にフォーカスできるようになります。