IaaSはなぜダウンしないのか、ダウンしたらどうなるのか：Azureに学ぶ単一障害点による障害の回避方法（1/2 ページ）

クラウドサービスで物理障害が発生した場合、初期設定のままでは稼働中のサービスにダウンタイムが発生してしまう。高可用性を維持するために必要な設定についてAzureを例として解説する。

[Stuart Burns，TechTarget]

適切な設定をしないとダウンタイムが発生してしまう

　Microsoftの「Microsoft Azure」などのパブリッククラウドインフラで管理者が仮想マシンを作成すると、デフォルトの状態では、単一障害点によるダウンタイムに対する保護はないに等しい。クラウドの物理ノードで障害が発生すると、仮想マシンは別の物理ノードで再起動する。この動作をユーザーが制御することはできない。そのため、アプリケーションを導入する上で仮想マシンのワークロード（システム稼働状態）を保護することは欠かせない。

　企業がアプリケーションをクラウドに導入する前に、クラウドコンピューティングの高可用性について把握すべき問題がある。

　本稿では、MicrosoftのIaaS（Infrastructure as a Service）であるAzureを例として使用している。本稿は一般的な指針となることを目標としているが、インフラの詳細については各パブリッククラウドプロバイダーに確認してほしい。

併せて読みたいお薦め記事

「Microsoft Azure」についてもっと詳しく

• 徹底比較：Amazon、Azure、Google、IBMの機械学習機能　現時点の勝者はいるか
• クラウド3強はIoTでも勝者？ GoogleがAWSとAzureに対抗

可用性についてもう一度考えてみよう

• 「SLA」は分かるけど「SLO」とは？　IT発注するなら知りたい契約のこと
• 今日もまたコンピュータが動かない――その理由と対策

高可用性を実現するためのゾーン

　Azureのデザインを支えているのは、クラウドの概念だ。Azureで1つの場所と見なされている可用性ゾーンの実態は、地理的に比較的近場にある多数の物理データセンターである。そのため、クラウドへのアプリケーションの導入に取り組んでいる管理者は、大規模なサービス停止が発生したときに、同じゾーンの別のデータセンターにシステムをフェイルオーバーさせるように構成できる。

　各データセンターで運用されているクラスタは、ネットワークで接続された何千もの物理ノードを関連付けている。いずれかの物理ノードで障害が発生すると、そのノードでホストされている仮想マシンは同じクラスタ内の別の物理ノードで再起動する。パブリッククラウドコンピューティングでは、サイトごとに何百または何千ものクラスタが存在している。

　プライベートデータセンターのハイパーバイザーにパッチを適用する必要があるのと同様に、パブリッククラウドの物理ブレードサーバで実行しているハイパーバイザーにもパッチを適用しなければならない。これは、クラウドアプリケーションをホストする仮想マシンにとっては残念なことだろう。仮想マシンは年に数回ベースとなるハイパーバイザーのアップグレード中に移動しなければならない。管理者は、「Azure DNS」（DNSドメインのホスティングサービス）や「Azure Active Directory」（ディレクトリとIDの管理サービス）などのAzureサービス群にメンテナンスの作業が影響することを心配しなくてよい。だが、顧客のワークロードについては管理者が責任を負わなければならない。

　Azureは、「可用性セット」によって顧客が利用する仮想マシンのサービス停止に関する問題に対処している。可用性セットを使用すると、管理者は、異なるゾーンに配置されているフロントエンドWebサーバなど複数の仮想マシンを割り当てることができる。この分散型の性質がクラウドコンピューティングアーキテクチャで高可用性を実現している。というのも、フロントエンドサービスは、単一障害とサーバアップデートのどちらが発生した場合でも、要求を処理できるからだ。Microsoftは可用性セットを仮想マシンの論理グループと位置付けている。また可用性セットは、クラウドアプリケーションがどのように構成されているかという情報をMicrosoftに提供する役割も担っている。

　AzureでSLA（サービス品質保証）に記載の99.95％の稼働率を実現したいと考える管理者は、可用性を確保するためにこれらの可用性セットを使用しなければならない。クラウドコンピューティングの高可用性について管理者が理解すべき最大の教訓の1つは、ホスティングインフラに振り回されることなく、使いこなすことだ。管理者は、導入したクラウドアプリケーションの機能への影響が最小限で済むように単一ノードのフェイルオーバーを設計しなければならない。

　Azureでは、オンプレミスで管理されているITインフラとは異なる形でディスクが用意されている。ストレージノードでもアップグレードが必要になる。そのため、管理者が単一ノードと見なしているディスクは、実際のところ、Azureデータセンターのローカルで少なくとも3回複製されている。それから、冗長性のレベルを上げるには、膨大なコストがかかる。つまり、クラウドコンピューティングの可用性はタダでは手に入らないということだ。

　可用性セットでは、導入したクラウドアプリケーションについて「障害ドメイン」と「更新ドメイン」が考慮されている。障害ドメインは、局所的な停電など、単一の問題の影響を受ける可能性があるインフラアイテムのグループだ。一方の更新ドメインは、制御された状態でパッチを適用する、グループ化された仮想マシンで構成している。

　可用性セットは、クラウドでホストしているサービスが、要請を受けたときに、その役割を果たせるようにしている。

　特定の可用性セットに含まれる仮想マシンは、ネットワークの制御（どのサーバにトラフィックを流すか）についてロードバランサーに頼ることになる。Azureの負荷分散機能は、アクティブなサーバにトラフィックをルーティングする。障害が発生しているサーバやアップグレード中のサーバにトラフィックがルーティングすることはない。