クラウド時代のHA（冗長化）
HAシステムの構成要素
以下では、Webアプリケーション・システムの全要素をHA化した"フルHA"システムを例に挙げ、HAシステムの構成を詳細に解説します。Webアプリケーション・システムは、機能別に、以下の3つのブロックに分類できます。
- アプリケーション／サービス部: アプリケーションやサービスを実際に実行
- Webサーバー
- アプリケーション・サーバー
- データベース・サーバー
- メッセージング・サーバー（電子メール、SMS、キューイング・サーバーなど）
- 特殊サーバー（検索、分析サーバーなど）
- リソース部: アプリケーションやサービスの実行に必要なリソースを提供
- ストレージ・サーバー（SAN、NAS、オブジェクト・ストアなど）
- ネットワーク機器（ロード・バランサ、ファイア・ウォール、ルーター、スイッチなど）
- リソース・サーバー（物理サーバー、仮想サーバー（それを管理するハイパーバイザ）など）
- 監視／管理部: システムと連携する、監視、バックアップ、アラート系システム
- 監視／アラート・システム（nagios、Zabbix、icinga、SMSゲートウエイなど）
- 設定管理システム（puppet、chef、cfengineなど）
- クラウド管理システム（Eucalyptus、Open Nebula、cloud.com CloudStack、XenServerなど）
- バックアップ・システム
- インフラ／アプリケーション管理システム（mCloud Controller、RightScale、vCenterなど）
フルHA環境下では、これらの構成要素が、すべて必要になります。
特に、監視／管理部は、大規模インフラを合理的に管理するために必須です。例えば、第3回で紹介したPuppetのような設定管理システムを活用することで、数百から数千台ある仮想サーバーを簡単に管理できるようになります。
監視／管理部では、自動化が何よりも重要です。監視／管理の自動化によって、障害発生時や負荷増大時に、自動修復や、自動スケール・アウト／自動スケール・インなどによって、可用性やサービス・レベルを自動的に維持できます。
HAの具体的な構成方法
以下では、HAの具体的な構成方法として、ツールの設定方法を解説します。以下に示すシステム構成例は、単純なシステムではあるものの、実際に稼働する例です。あらゆるWebアプリケーション・システムの基盤として参考にできるものです。
- フロント・バランサ: Linux LVS
- Webサーバー: nginx
- アプリケーション・サーバー: Ruby on Rails上のMongrel
- データベース・サーバー: PostgreSQL
- プロセス監視: monit
- システム監視・アラート: icinga
- クラウド管理: Eucalyptus
HAの論理構成
図1は、典型的なWebシステムの階層を示したものです。それぞれの要素がどのように階層化され、どのように関連し合っているのかを示しています。すべての構成要素はメッシュ構成で結合され、冗長化されています。冗長化された構成要素は、同じデータ・センター内にあっても、地理的に離れた場所にあっても、どちらでも構いません。
|
|
| 図1: WebアプリケーションのHA構成（クリックで拡大） |
図1を見ると、1つのWebサーバーに障害が発生しても、ほかの2つがその代用として動き続けることが分かります。また、アプリケーション・サーバーを構成するクラスタに障害が発生した場合、残った2つの正常なクラスタが、そのリクエストを処理できることが分かります。
つまり、それぞれの冗長化されたサーバー要素は、分散することで、さらにその障害率を下げることができます。同じデータ・センター内であっても、電源系統、ネットワーク系統、消火システム系統などが異なる場所同士で冗長化を実現することで、ローカル障害の回避率を上げることができます。
それぞれの構成要素は、最低でも2つの異なったアベイラビリティ・ゾーン（アクティブ稼働しているサイト）で稼働させることを推奨します。特に、国境を越えたアベイラビリティ・ゾーンを利用することで、さらにその可用性を高められます。
