高可用性とは、冗長化、自動フェイルオーバー、および障害の隔離を通じて、個々のコンポーネントが故障してもシステムが稼働し続け、アクセス可能な状態を維持するように設計するアーキテクチャ上の原則である。
すべてのコンポーネントが常に完璧に機能すると仮定するのではなく、高可用性アーキテクチャではコンポーネントの障害を明確に想定し、個々の要素が故障してもシステムが稼働し続けるよう設計されています。サーバーがダウンしたり、ネットワークスイッチが誤動作したり、ストレージコントローラが応答しなくなったりしても、システム全体は中断することなくユーザーへのサービスを提供し続けます。企業にとって、高可用性は単なる望ましい機能から基本的な要件へと進化しました。ビジネスに不可欠なシステムの多くは、たとえ短時間の停止であっても許容できないからです。
エンタープライズ運用において高可用性が重要な理由
組織がデジタルインフラへの依存度を高めるにつれ、システム停止がビジネスに与える影響は劇的に拡大しています。現在では、1時間のシステム停止が、数千ドルから数百万ドルに及ぶ収益の損失、顧客関係の悪化、業務の混乱を招くことになっています。IT部門がほぼ継続的な可用性を維持しなければならないというプレッシャーは、かつてないほど高まっています。高可用性アーキテクチャは、コンポーネントの障害によるサービス中断を軽減または排除することで、このプレッシャーに直接対処します。
高可用性は、重要なシステムの総所有コスト（TCO）の改善にもつながります。冗長性を導入すると、単一インスタンスのシステムに比べてインフラコストは増加しますが、ダウンタイムによる損失は、多くの場合、冗長化にかかるコストをはるかに上回ります。収益を生み出すシステムが1時間ダウンするだけで、何年にもわたる冗長インフラへの投資額を上回る損失が生じる可能性があります。こうした経済的な現実から、高可用性は多くの企業において、本番システムに求められる標準的な要件となっています。
高可用性と 災害復旧 の関係は、しばしば誤解されています。どちらもシステムの稼働を維持することを目的としていますが、対処する障害シナリオは異なります。高可用性は、単一拠点内での個々のコンポーネント障害に対する迅速なフェイルオーバーに重点を置いています。つまり、あるサーバーが障害を起こすと、トラフィックは自動的に別のサーバーに切り替わります。一方、災害復旧は、より広範な障害に対処します。データセンター全体が利用不能になった場合、運用を復旧拠点に移行させるものです。多くの企業では、多層防御による耐障害性を実現するために、両方のアプローチを導入しています。
高可用性アーキテクチャの仕組み
高可用性を実現するには、通常、複数のレイヤーで冗長性を確保する必要があります。単一のサーバーではなく、同じアプリケーションを実行する複数のサーバーをデプロイし、ロードバランサーが正常なサーバー間でトラフィックを分散させます。1台のサーバーに障害が発生した場合、ロードバランサーはそのサーバーへのトラフィックの送信を自動的に停止し、残りのサーバーがユーザーのリクエストを引き続き処理します。このアーキテクチャは、アプリケーション層の冗長性を拡張する上で、シンプルかつ効果的です。
ストレージの冗長性も同様に重要です。高可用性アーキテクチャでは、単一のストレージシステムの障害によってデータ損失や長時間のサービス停止が生じることは許容できません。これに対処するため、通常はRAID（Redundant Array of Independent Disks）構成が採用されます。これは、複数のドライブで冗長性を確保することで、単一のドライブが故障してもデータ損失やサービスの中断が生じないようにするものです。一部のシステムでは、ストレージシステム全体をミラーリングする、より高度なレプリケーションが実装されています。
ネットワークの冗長化により、ネットワーク接続における単一障害点が排除されます。サーバーをネットワークに接続するインターフェースを1つだけ用意するのではなく、システムには複数のインターフェースが設置され、それらが複数のネットワークスイッチに接続されます。1つのインターフェースやスイッチに障害が発生しても、残りの経路を通じてトラフィックは引き続き流れます。ネットワーク層の冗長化は高可用性を実現するための基本ですが、コンピューティングやストレージに注力するアプリケーションチームからは見過ごされがちです。
自動フェイルオーバー機能は、高可用性を実現する上で極めて重要です。システムはコンポーネントの障害を迅速に検出し、トラフィックやワークロードを正常なコンポーネントへ自動的に切り替える必要があります。この検知とフェイルオーバーは、人手による介入なしに行われなければなりません。IT担当者が手動で障害を検知し、対応しなければならないようでは、真の高可用性とは言えません。ヘルスチェック機能は、コンポーネントが応答し、正常に動作しているかを継続的に確認し、異常が検出された場合に自動フェイルオーバーを起動します。
高可用性導入における重要な考慮事項
効果的な高可用性アーキテクチャを設計するには、クリティカルパスや単一障害点を特定し、冗長化によってそれらを排除する必要があります。すべてのコンポーネントに同レベルの冗長性が必要というわけではありません。重要度の低いロギングサービスでは最小限の冗長性で済む一方、プライマリデータベースには最大限の冗長性が求められます。組織は、重要度に基づいて冗長化への投資の優先順位を決定すべきです。
高可用性テストは不可欠です。管理者は、実際にフェイルオーバーのシナリオをテストしてみると、システムが期待通りにフェイルオーバーしないことに気づくことがよくあります。ネットワーク構成が不完全であったり、フェイルオーバー手順が正しく機能しなかったり、あるいはアプリケーションの設計上、スムーズなフェイルオーバーが妨げられたりする場合があるからです。チームが意図的にコンポーネントを障害状態に陥らせてフェイルオーバーをテストする「意図的な障害注入」を含む定期的なテストを行うことで、高可用性アーキテクチャが実際に機能することを確実にすることができます。
高可用性への投資判断には、費用対効果分析を基にすべきです。99.999%の可用性（年間ダウンタイム約26秒）を実現するには、99.99%の可用性（年間ダウンタイム約52分）を実現する場合に比べて、コストが飛躍的に高くなります。組織は、ビジネスに実際に必要な可用性レベルを見極め、不必要なレベルまで過剰な設計を行うのではなく、そのレベルを目標とすべきです。
ステート管理は、高可用性アーキテクチャにおいてよく見られる課題です。ユーザーがサーバーに接続している最中にそのサーバーに障害が発生した場合、ユーザーのセッション状態はどこに保存されているのでしょうか。アプリケーションは、どのサーバーからもアクセス可能な共有場所にセッション状態を保存するか、他のサーバーに状態をレプリケートするか、あるいはサーバー障害時にユーザーがセッションを失うことを容認するかのいずれかを選択する必要があります。ステートレスなアプリケーション設計を採用することで、高可用性の実現が容易になることがよくあります。
高度な高可用性に関する概念
一部の組織では、地理的な高可用性を以下の方法で実現しています アクティブ-アクティブ型災害復旧 アーキテクチャを通じて地理的な高可用性を実現しており、この場合、冗長性は複数の拠点にまたがっています。従来の高可用性は通常、単一のデータセンター内で運用されますが、地理的冗長性のアプローチでは、拠点全体の障害に対処します。
高可用性とロードバランシングの関係を理解することは重要です。ロードバランサーは、トラフィックを複数のサーバーに分散させ、障害が発生したコンポーネントを検知するなど、高可用性アーキテクチャにおいて極めて重要な役割を果たします。ロードバランサーの配置と冗長性そのものが重要となります。単一のロードバランサーを単一障害点にしてはならないからです。
平均復旧時間を理解する 平均復旧時間 という指標を理解することは、組織が高可用性の実装を最適化する上で役立ちます。フェイルオーバーが自動で行われる場合、復旧時間は測定されないため、組織は復旧時間の最小化ではなく、コンポーネント障害発生時のパフォーマンスへの影響を最小限に抑えることに注力すべきです。