クラウド時代のシステム冗長化
パブリッククラウド、プライベートクラウド、ベアメタル、VPS、オンプレミス、ハイブリットクラウドと多数の用語や定義が流布していますが、コンピュータがどこかで確実に稼働していることは変わりません。
図4は、IDCジャパン社から発表された国内データセンターにおけるサーバー設置台数です。台数にして250万台の規模があり、事業者DCと企業内DCが拮抗しているのが分かります（「DC外とはマシンルームなどの独立した部屋ではなく、オフィススペースや店舗のバックヤードなどに設置」とのことです（涙））。
ここで示された数字がすべてではありませんが、システム冗長化を必要とするコンピュータの台数規模が理解できます。仮に10％がシステム冗長化を必要とするコンピュータ規模としても25万台以上になります。これだけの台数がパブリッククラウドやオンプレミスを問わず日夜稼働している計算になります。
続いて、システム冗長化の基本理解を深めることを目的として、古くから利用される冗長化を考慮したシステム設計手法についてみていきましょう（図5）。
この設計例では、VRRPv2などIPマルチキャストを用いたHA（High Availability）構成のシステム冗長化の手法を用いています。基礎理解を深めるため物理構成から冗長化メカニズム、さらにHA構成図までを抽象化して示しました。詳しくは記述していませんが、スイッチは冗長化のためMLAG: Multi-Chassis Link-Aggregationなどが用いられているとします。 ルータ、サーバ、NASはいずれも二台一組のActive／Standby構成です。
比較的小規模でも古くから用いられる設計手法なので、なじみ深い方も多いかと思います。動作するアプリケーションやサービスによっては異なるアプローチが取られますが、そこはご留意ください。
続いて、古くから用いられる冗長化を考慮したシステム設計手法をパブリッククラウドで実現する際の留意点についてみていきましょう。すでにご存じの方も多いかと思われますが、Amazon Web Services, Google Compute, Microsoft Azureなど一部のパブリッククラウドでは「Unicast Only」トラフィック制限があるため、VRRPv2などIPマルチキャストを用いたHA（High Availability）構成のシステム冗長化の手法ではなく、「独自のデザインパターン」（設計テクニック）が利用されています。
パブリッククラウド内部においてトラフィック制限がかかっているため、図6のように古くから用いられる冗長化を考慮したシステム設計手法を利用することはできません（注：IPマルチキャストなどにトラフィック制限をかけていないパブリッククラウドやプライベートクラウドであれば、こういったことはありません）。
「Unicast Only」トラフィック制限のかかった一部のパブリッククラウドでは、システム冗長化する場合には、独自のAPIや機能と連携したHAメカニズムやクラウド事業者が用意したILB（Internal Load Balancer）などが用いられます。
古くからシステムエンジニアをされ、システム冗長化の耐障害性設計をされている方々はすでにお気づきかと思いますが、これらクラウド事業者から提供されるHAメカニズムやILB（Internal Load Balancer）など独自機能を利用する場合、それ自体が単一障害点（SPOF: Single Point of Failure）です。SLAなどによりそれら機能の耐障害性は示されますが、図7のように独自機能に強く依存した設計を取った際にはサービス停止もしくはシステムの全停止という可能性もあります。これは遠隔地の第三者にプラットフォームを預託する際に、昔から言われて続けている課題の一つです。
これらを踏まえて企業の業務システムなどでコンピュータ資源を継続的に利用するというユーザ観点から考えたとき、古くから利用される冗長化を考慮したシステムの継続的な利用方法の選択肢は図8のようになります。
現状維持から積極的なパブリッククラウドの利用まで、前述の図4. 国内データセンターにおけるサーバー設置台数という統計数値からも、納得いただける内容かと思います。
これらを踏まえて中長期的にコンピュータ資源をうまく活用するための現在とこれからを見ていきましょう。
