クラウド時代のHA（冗長化）
クラウド環境下において有効な、冗長化（HA: High Availability、高可用性）の基本コンセプトは、「Assumed Failure （障害発生を前提とする）」です。ITインフラは、何かしらのハードウエアに依存しています。一方、100％の稼働率を持つハードウエアはありません。つまり、ITインフラには、いつかは必ず障害が発生するのです。
企業がプライベート・クラウドを構築する場合や、パブリック・クラウド事業者がデータ・センター内にサービス提供用のクラウドを構築する場合、99.999%の稼働率を持った高価なハードウエアではなく、安価で汎用的なハードウエアを活用して冗長化構成を採用する時代になってきています。
HA構成が必要になる理由
ITサービスは、常にオンラインで、常に利用可能であることが求められます。クラウド・サービスも、例外ではありません。常識的に、どのようなアプリケーションであっても、いつでも、どこからでも、どの端末からでも、利用可能であることが求められます。
システム・ダウンは、生産性や売上の低下に直結します。このため、システム・ダウンは、何らかの方法で回避しなければなりません。また、システムは24時間稼働が必要です。インターネット・サービスのグローバル化が進むことにより、特にWeb 2.0系のアプリケーションは、世界のどこかで常にピーク時間を迎えているからです。
システムの利用者からすれば、HA（高可用性）とは「アプリケーションがいつでも利用可能なこと」を指しています。どのような仕組みで可用性を確保しているのかはどうでもよく、アプリケーションが利用可能であれば、すべて手作業で可用性を高めていようと、全自動で高めていよいうと、その手段は問われません。
逆に、システム管理者からすれば、高可用性を成り立たせるためには、HAシステムの中身の技術を厳格に制御し、運営する必要があります。
HAの種類
ITシステムに高い可用性を確保するためには、最適なシステム・デザインを選定する必要があります。許容可能なダウン・タイム、システムの複雑さ、必要なコストなどの各要素のバランスを保ちつつ、デザインしなければなりません。
大まかに、以下の3つを考えてHAシステムをデザインしなければなりません。
- 専用ハードウエアを利用する個所
- 汎用サーバーで構成する冗長化クラスタを利用する個所
- 上記2方法のコンビネーションを利用する個所
専用ハードウエアを用いてHAを実現することは、非常に高価な解決策です。99.999%以上の可用性を実現するハードウエアは、それ自体が高価で、保守費用も高価です。さらに、分散処理を前提としていないため、地理的に分散させることが困難です。
ただし、専用ハードウエアには、運用面において作業が単純化されているというメリットがあります。フェール・オーバーを前提とする冗長化クラスタと比べると、日々の運用管理コストを抑制できます。
一方、冗長化クラスタは、ハードウエア障害が発生することを前提に、安価な汎用サーバーを大量に使って構築します。クラスタを構成する個々のサーバーにおける障害発生率が高くなったとしても、SPOF（Single Point of Failure、単一障害点）を作らないことにより、システム全体としての障害発生率が下がればよい、という考え方に立脚しています。
例えば、MTBF（Mean Time Between Failures）が50万時間のサーバーが1000台あるとします。この場合、500時間（50万／1000）に1度（約3週間に1度）、いずれかのサーバーが故障します。このことを前提に、1000台のうち1台が故障してもシステムに影響を与えないようなシステム構成にすることが、何よりも重要です。
冗長化クラスタには、可用性を確保できることに加え、スケーラビリティ（拡張性）やメンテナンス性が高いとうアドバンテージがあります。例えば、システム全体に影響を与えることなく個々のサーバーを追加／削除できるため、アップ・グレードやパッチの適用などが容易です。
HAの構成を設計する際に重要なのは、システムの特性に応じて、それぞれ異なるHAデザインが存在する、ということです。SQLデータベースなど、分散化が比較的困難なサーバーは、専用のハードウエアの使用や、信頼性が高い数台のハードウエアを用いた冗長化が適しています（最近ではクラスタ構成で利用できるものもあります）。反対に、Webサーバーなど、簡単に分散化できるサーバーは、汎用サーバーによる構成が適しています。
障害を前提とした設計
安価なサーバーを活用した冗長化クラスタ型のHAを実現する場合、ハードウエアに障害が発生することが前提です。手動か自動かを問わず、傷害に対して迅速に対処できるようにしておかなければなりません。障害検知から修復までを自動化する解決策もあります。
故障する部位によって、修復方法はそれぞれ異なります（下記の表）。
テーブル1: クラスタ構成時の各要素のオプション
| 要素 | クラスタの実現方法 | 修復方法 |
|---|---|---|
| ストレージ | 複数のRAIDコントローラ 複数のディスク |
手作業で障害ディスクを取り換え コントローラにより自動修復 |
| データベース・サーバー | ホット／ワーム・バックアップ 複数のマスターDB構成 |
バックアップDBへの自動フェール・オーバー 正常なマスターDBへのルーティング |
| アプリケーション・サーバー | ロード・バランサの冗長化機能 | 障害マシンをクラスタから自動削除 代替マシンの作成 ロード・バランサの設定など |
| Webサーバー | 同上 | 同上 |
| ネットワーク・スイッチ | Fabricスイッチ | 障害機器の入れ替え システム全体は自動修復 |
HA構成時には、アプリケーション側も、冗長化構成で動作できるように調整する必要があります。例えば、Webアプリケーションの場合、HTTPというステートレスなプロトコルでありながら疑似的にセッションを維持する機能や、障害発生時にセッションを引き継ぐことで障害の影響がないようにする必要があります。
WebシステムのHA構成の顕著な例が、ロード・バランサ（負荷分散装置）です。ロード・バランサは、アプリケーションの死活監視を常時実施し、障害を検知すると同時に、そのサーバーへのリクエストを止め、代替サーバーで処理を継続します。
