クラウドと可用性(4) – クラウドに潜むSPOFの罠とは?

multi-region-ha-clustering
Pocket

>>第1回から読む

HAクラスターを構成するには、特定の部分に障害が発生した際にシステム全体が停止してしまう要素となるSPOF(単一障害点:Single Point of Failure)を避けることが大原則です。しかし、パブリッククラウドでは運用基盤が見えづらいだけに注意が必要です。稼働系ノードと同じホストサーバー、同じラック、同じネットワークスイッチの配下で待機系ノードを配置されてしまう可能性があり、それにより冗長化されていない要素ができると、いざという事態の可用性を担保することができません。データセンターや運用基盤を物理的に完全に分離した「リージョン」や「アベイラビリティゾーン」を利用する必要があります。

可用性確保のための大原則とは

システムを構成しているさまざまなコンポーネントは、未来永劫にわたって仕様どおりに安定して動き続けるわけではありません。形あるモノである以上、いつか必ず壊れます。定期的な保守をしっかり行っていればリスクを下げることはできますが、それでも数年にわたるライフサイクルの中で、絶対に壊れないと断言することはできません。

また、さまざまな機器にトラブルを引き起こす原因は、ハードウェアの物理的な破損や故障だけではありません。OSや組み込みソフトウェアなどに潜在している重大なバグに非常にレアなケースとして引っかかり、動作を止めてしまうこともあります。

では、重要なシステムの可用性をどうやって確保するのかというと、大原則となるのが「冗長化」です。障害が発生するとシステム全体を停止させたり、処理の信頼性を損なったりしてしまう重要なコンポーネントを2重化あるいはそれ以上に多重化しておくのです。万が一、どれかのコンポーネントに異常が起こった場合は、別のコンポーネントが処理を補ったり、代替したりします。これによってSPOFを回避することができます。

すでにお気づきと思いますが、HAクラスター構成もまさにこの大原則に沿うもので、重要サーバーを稼働系(本番系)と待機系に冗長化することで、SPOFを排除しています。ただし、システム全体の中で重要な役割を担っているコンポーネントは、サーバーだけではないということを忘れてはなりません。特にシステムをパブリッククラウドに移行した場合、インフラはほとんど見えなくなってしまうだけに注意が必要です。

クラウドの見えないインフラに潜むSPOFの“落とし穴”に要注意

ほとんどのパブリッククラウドは、1つのホストサーバー上で複数の企業のシステムを仮想化して同居させる、いわゆる「マルチテナント」の運用を行っています。そして通常の契約では、自社のシステムをどのホストサーバーで運用するのかを指定することはできません。そこに大きな“落とし穴”があるのです。

運が悪い場合、稼働系ノードを運用している同じホストサーバー上に待機系ノードが配置されてしまう場合があります。これではせっかくHAクラスター構成を実現していたとしても、ホストサーバーがダウンしてしまうと稼働系ノードと待機系ノードは共倒れとなり、まったく意味がありません。いつどのタイミングで、どこまでシステムが復旧するかは、クラウド事業者の手にゆだねられることになってしまいます。

同じホストサーバーへの同居は逃れたとしても安心はできません。稼働系ノードを運用しているホストサーバーと待機系ノードを運用しているホストサーバーが、同じラックに収められている可能性があるからです。この場合はラックがSPOFとなるため、そこに障害が発生すると、配下にある稼働系ノードと待機系ノードはやはり共倒れとなってしまいます。さらに複数のラックを束ねているネットワークスイッチ、ゲートウェイやルーター、データセンターの電源装置というように上位の階層を見ていった場合、同じ系統に稼働系ノードと待機系ノードが同居しており、なおかつ要所のコンポーネントが冗長化されていなかったとすれば、結局SPOFから逃れることはできません。

重ねていうと、パブリッククラウドの1ユーザーである企業にとってこうしたデータセンター基盤はブラックボックスであり、詳細な構成まで見渡すことはできません。

パブリッククラウドの「アベイラビリティゾーン」と「リージョン」を活用すべき

どうすればパブリッククラウドにおける隠れたSPOFを明に回避することができるでしょうか。最も手堅いのは、クラウド側で用意された「アベイラビリティゾーン」や「リージョン」を利用する方法です。

multi-region-ha-clustering

アベイラビリティゾーンとは、データセンター内のインフラを物理的に完全に分離した独立区画です。そしてリージョンは、地理的にも離れた場所にある独立したデータセンターを指します。パブリッククラウドの中には、こうしたアベイラビリティゾーンやリージョンを契約によって意図的に使い分けられるものがあります。

例えばAmazon Web Service(AWS)は、日本(東京)を含む12の地域にリージョンを展開しています。また、Microsoft Azureは日本を含む22の地域にリージョンを展開するとともに、日本国内でも東日本と西日本の2つのリージョンを有していることを強みとしています。すなわち、これらの2つ以上のリージョンをまたいだ複数の異なるアベイラビリティゾーンに稼働系ノードと待機系ノードを分散させたHAクラスター構成を組めば、ほぼすべてのSPOFを確実に避けることができます。

ここまで厳重な対策をとっておけば単なる可用性確保だけでなく、DR(ディザスターリカバリ:Disaster Recovery)やBCP(業務継続性計画:Business Continuity Planning)強化のための施策としても有効です。

 ご参考: Amazon Web ServiceとHAクラスター連携ソリューション


>>第1回から読む

共有ストレージ不要!
"SANLess Clusters"についてもっと詳しく

sanless-clusters banner


"SANLess Clusters"ソリューションを見る

SNSでもご購読できます。