ここまで（クラウドと可用性）、クラウド上でシステムを稼働させる際の可用性について、オンプレとは異なる利用者の責任範囲や、HAクラスターというシステム障害の対策について学んできました。
ここで改めて、SPOF（単一障害点：Single Point of Failure）とは何か、またパブリッククラウドにおけるSPOFになり得る箇所はどういう点かを紹介いたします。そのうえで、パブリッククラウド上でのSPOF回避の具体策のひとつを提示します。
この記事を読むと、
- SPOFとは何かわかる
- クラウド環境におけるSPOFが何かわかる
- パブリッククラウドのSPOFの回避案がわかる
SPOFとは
SPOFとは、Single Point of Failure の略で、日本語で「単一障害点」と訳されます。そこに障害が発生するとシステム全体が停止してしまう箇所のことです。1つしかないネットワーク機器や経路、1つしかないサーバーのディスクや電源などがSPOFにあたります。
単純な例をあげてみます。家庭にある1つしかない無線LANルーターが故障してしまうと、家でwi-fiが利用できず、インターネット通信を利用するパソコン、ゲーム機器、スマート架電への通信機能が使えなくなってしまう、といった感じです。
これが、人々の生活を支える社会インフラであったり、大きな企業がもつ基幹系システムであった場合、日常生活上の不便や、事業活動の停止・停滞といった大きな影響に発展してしまう可能性があります。
よって、SPOFがないハードウェアやソフトウェアの選定、及びそのようなシステム設計を行うことが可用性を高める上で重要といえるでしょう。
SPOFを回避するために
システムを構成しているさまざまなコンポーネントは、未来永劫にわたって仕様どおりに安定して動き続けるわけではありません。形あるモノである以上、いつか必ず壊れます。定期的な保守をしっかり行っていればリスクを下げることはできますが、それでも数年にわたるライフサイクルの中で、絶対に壊れないと断言することはできません。
また、さまざまな機器にトラブルを引き起こす原因は、ハードウェアの物理的な破損や故障だけではありません。OSや組み込みソフトウェアなどに潜在している重大なバグに非常にレアなケースとして引っかかり、動作を止めてしまうこともあります。
では、重要なシステムの可用性をどうやって確保するのかというと、大原則となるのが「冗長化」です。障害が発生するとシステム全体を停止させたり、処理の信頼性を損なったりしてしまう重要なコンポーネントを2重化あるいはそれ以上に多重化しておくのです。万が一、どれかのコンポーネントに異常が起こった場合は、別のコンポーネントが処理を補ったり、代替したりします。これによってSPOFを回避することができます。
HAクラスター構成もまさにこの大原則に沿うもので、重要サーバーを稼働系（本番系）と待機系に冗長化することで、SPOFを排除しています。ただし、システム全体の中で重要な役割を担っているコンポーネントは、サーバーだけではないということを忘れてはなりません。特にシステムをパブリッククラウドに移行した場合、インフラはほとんど見えなくなってしまうだけに注意が必要です。
パブリッククラウドにおけるSPOFとは
ほとんどのパブリッククラウドは、1つのホストサーバー上で複数の企業のシステムを仮想化して同居させる、いわゆる「マルチテナント」の運用を行っています。そして通常の契約では、自社のシステムをどのホストサーバーで運用するのかを指定することはできません。そこに大きな“落とし穴”があるのです。
運が悪い場合、稼働系ノードを運用している同じホストサーバー上に待機系ノードが配置されてしまう場合があります。これではせっかくHAクラスター構成（冗長構成）を実現していたとしても、ホストサーバーがダウンしてしまうと稼働系ノードと待機系ノードは共倒れとなり、まったく意味がありません。いつどのタイミングで、どこまでシステムが復旧するかは、クラウド事業者の手にゆだねられることになってしまいます。
同じホストサーバーへの同居は逃れたとしても安心はできません。稼働系ノードを運用しているホストサーバーと待機系ノードを運用しているホストサーバーが、同じラックに収められている可能性があるからです。この場合はラックがSPOFとなるため、そこに障害が発生すると、配下にある稼働系ノードと待機系ノードはやはり共倒れとなってしまいます。さらに複数のラックを束ねているネットワークスイッチ、ゲートウェイやルーター、データセンターの電源装置というように上位の階層を見ていった場合、同じ系統に稼働系ノードと待機系ノードが同居しており、なおかつ要所のコンポーネントが冗長化されていなかったとすれば、結局SPOFから逃れることはできません。
重ねていうと、パブリッククラウドの1ユーザーである企業にとってこうしたデータセンター基盤はブラックボックスであり、詳細な構成まで見渡すことはできません。
パブリッククラウドでのSPOFの回避策
どうすればパブリッククラウドにおける隠れたSPOFを明確に回避することができるでしょうか。最も手堅いのは、クラウド側で用意された「アベイラビリティゾーン」や「リージョン」を利用する方法です。
アベイラビリティゾーンとは、データセンター内のインフラを物理的に完全に分離した独立区画です。そしてリージョンは、地理的にも離れた場所にある独立したデータセンターを指します。パブリッククラウドの中には、こうしたアベイラビリティゾーンやリージョンを契約によって意図的に使い分けられるものがあります。
Azureのリージョンとアベイラビリティゾーンの概念 出展：https://docs.microsoft.com/ja-jp/azure/availability-zones/az-overview
2022年1月現在、例えばAmazon Web Service（AWS）は、日本（東京・大阪）を含む26の地域にリージョンを展開しています。また、Microsoft Azureは日本（東日本・西日本）を含む60以上の地域にリージョンを展開しています。これらの２つ以上のリージョンをまたいだり、複数の異なるアベイラビリティゾーンに稼働系ノードと待機系ノードを分散させたHAクラスター構成を組めば、ほぼすべてのSPOFを確実に避けることができます。
ここまで厳重な対策をとっておけば単なる可用性確保だけでなく、DR（ディザスターリカバリ：Disaster Recovery）やBCP（業務継続性計画：Business Continuity Planning）強化のための施策としても有効です。
クラウド上のシステムにおけるSPOFを取り除き、障害に強いシステムを設計していくためにも、パブリッククラウド自体がもつ可用性機能を学ぶことをお勧めいたします。
人気の高いパブリッククラウドである、AWSとAzureに関して、リージョン、アベイラビリティゾーンや、Autorecoveryといった可用性機能について、その違いと活用イメージを学ぶことができます。ぜひ以下の記事を覗いてみてください。
クラウドと可用性について第1話から読む →http://sios.jp/bcp/bcblog/can-you-trust-availability-on-cloud/
