Azureに学ぶ単一障害点による障害の回避方法
IaaSはなぜダウンしないのか、ダウンしたらどうなるのか(1/2 ページ)
クラウドサービスで物理障害が発生した場合、初期設定のままでは稼働中のサービスにダウンタイムが発生してしまう。高可用性を維持するために必要な設定についてAzureを例として解説する。
Microsoftの「Microsoft Azure」などのパブリッククラウドインフラで管理者が仮想マシンを作成すると、デフォルトの状態では、単一障害点によるダウンタイムに対する保護はないに等しい。クラウドの物理ノードで障害が発生すると、仮想マシンは別の物理ノードで再起動する。この動作をユーザーが制御することはできない。そのため、アプリケーションを導入する上で仮想マシンのワークロード(システム稼働状態)を保護することは欠かせない。
企業がアプリケーションをクラウドに導入する前に、クラウドコンピューティングの高可用性について把握すべき問題がある。
本稿では、MicrosoftのIaaS(Infrastructure as a Service)であるAzureを例として使用している。本稿は一般的な指針となることを目標としているが、インフラの詳細については各パブリッククラウドプロバイダーに確認してほしい。
併せて読みたいお薦め記事
「Microsoft Azure」についてもっと詳しく
可用性についてもう一度考えてみよう
高可用性を実現するためのゾーン
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の負荷分散機能は、アクティブなサーバにトラフィックをルーティングする。障害が発生しているサーバやアップグレード中のサーバにトラフィックがルーティングすることはない。
Copyright © ITmedia, Inc. All Rights Reserved.
この記事の著者
関連記事
新着ホワイトペーパー PR
-
製品資料
[ファインディ株式会社] AI利用率だけでは説明できない成果 開発組織の競争力を生む「開発資本」とは? -
製品資料
[ニュータニックス・ジャパン合同会社] AI活用を成功へ導く、シンプルで費用対効果に優れたクラウド基盤とは? -
製品資料
[ニュータニックス・ジャパン合同会社] マネージドKubernetesには限界も――メリットをフル活用する新たな選択肢とは? -
技術文書・技術解説
[ニュータニックス・ジャパン合同会社] 決断の日が迫る「vSphere 8」サポート終了問題 考慮すべきリスクと選択肢は? -
製品資料
[サイバーソリューションズ株式会社] メール誤送信対策のルールが肥大化 苦しむ情シスはどうすれば救われるのか?
こんなメディアも見られています
TechTargetジャパンに関連する情報をお探しであれば、こちらのメディアもお役に立てるかもしれません。
ベンダーコンテンツ PR
From Informa TechTarget
SpecialPR
アクセスランキング
-
1
半数がブルーカラー転向を視野に? ベテランエンジニアを追い込む“54歳の壁”
-
2
「Wi-Fi 7」経由でWindowsが乗っ取られる? 最高権限奪取の恐怖
-
3
kintoneで実践 製造業のための「見積もり管理」改善のヒント
-
4
パッチなしで「今すぐサーバを落とせ」 Kiteworks異例警告の波紋
-
5
「IoT通信環境の構築・運用」に関するアンケート
-
6
祝10周年! 創業者も予想できなかったRaspberry Pi活用例
-
7
「企業におけるAI導入検討度とIT投資優先度」に関するアンケート
-
8
ネットアップ、クラウド時代を見据えてストレージ製品群を刷新
-
9
「VMware旧ライセンス」ユーザーに届いた“最後通告”が波紋を呼ぶ
-
10
鉄道とIT、老舗企業はスマホアプリでいかに息を吹き返したか
ホワイトペーパーランキング PR
-
1
家庭用Wi-Fiルーターの業務利用は危険? 避けるべき理由と具体的な対策
-
2
Microsoft 365のメールセキュリティ、3つの“死角”と追加で検討すべき対策とは
-
3
システムの保守がモダン化を阻む? 「変えない判断」から脱却する方法とは
-
4
AI駆動攻撃にどう対抗する? 超速の攻撃からエンドポイントを保護する方法
-
5
不審メールの経路や見せ方に変化? 2026年夏の3事例から見えた動向と対処方法
-
6
プログラミング不要で誰でも実現できる、ネットワーク運用管理の自動化とは
-
7
Linux初心者でも知らないとまずい「RHEL」「SLES」の違いとは?
-
8
東大教授と考える、AI時代の「データ主権」「信頼性」「ガバナンス」の在り方
-
9
「IT史に名を残すシステム障害」8選
-
10
最速72分でデータが流出? 最新の脅威トレンドや侵入手法から分かった防衛策
TechTargetジャパン SNS
インフォメーション
注目情報をチェック
TechTargetジャパンをフォロー