CLOUD NAVIクラウドとは?からクラウドを支える技術や関連用語まで解説

基礎知識

クラウドとオンプレミスの可用性の考え方の違いとは

2019年10月7日
クラウドとオンプレミスの可用性の考え方の違いとは

デジタルトランスフォーメーション(DX)を推進していく上で、システム構築の際にクラウドの利用を第1に検討することは、もはや必須となっています。2019年現在、こうした「クラウドファースト」の考え方が浸透しつつあり、ビジネスにおいて重要な役割を持つ基幹システムですらも、クラウド上に構築される例が増えてきました。

2018年に経産省から発表された「政府情報システムにおけるクラウド サービスの利用に係る基本方針」では、クラウドを利用するメリットとして「効率性」「セキュリティ水準」「技術革新対応力」「柔軟性」「可用性」の5つが挙げられています。基幹システムのような、業務上クリティカルなシステムを停止せず使い続けるには、この中でも特に「可用性」を高くする設計が重要です。

本記事をご覧いただいた方向けに、おすすめの記事をまとめました。こちらもあわせてご確認ください。

【まとめ】オンプレミスからクラウドに移行すると「可用性」はどう変わる?

まとめ記事

【まとめ】オンプレミスからクラウドに移行すると「可用性」はどう変わる?

2021年8月25日

可用性の定義とは

可用性(availability)とは、情報セキュリティの3要素であるConfidentiality(機密性)、Integrity(保全性)、Availability(可用性)のうちの1つで、「システムが動き続けることができる能力」を指します。

可用性は、一般的に「稼働率」という数値で表されます。これは動作可能時間(MTBF)を動作可能時間(MTBF)と動作不能時間(MTTR)を合計した値で割ったものです。例えば、1カ月(744時間)に1時間だけ停止するシステムがあるとします。

このシステムの稼働率は、

動作不能時間=1時間
動作可能時間=744時間-1時間=743時間
稼働率=743時間/(743時間+1時間)=0.9987

という式で表され、99.87%となります。

クラウドでは、ハードウェアをユーザー自身で管理しないため忘れがちですが、クラウドといえどもネットワークの向こう側には、クラウドベンダーが管理しているハードウェアが存在しています。そのため、どうしてもハードウェアの故障やメンテナンスによるサービスの中断が発生する可能性があります。

とはいえ、オンプレミスと比較するとクラウドにおけるサービスの中断は最小限であり、ハードウェア故障からの復旧の早さも含めて非常に可用性の高いシステムを構築することができます。

オンプレミスとクラウドにおける要素ごとの可用性の考え方

ハードウェアが存在する以上、故障は避けることはできません。そこで、故障が起こらないようにするのではなく、故障は発生するという前提で故障時にもサービス全体に影響しないようにシステムを設計することが可用性を高くする基本です。そのためには、止まってしまうとサービスが利用できなくなる「単一障害点(Single Point Of Failure(SPoF))」を無くす、あるいは少なくすることが重要です。

オンプレミスでは、ハードウェアや回線を冗長化して障害時に切り替えるという運用を行います。例えば、インターネットに接続する回線が1本しかない場合、回線障害が発生するとすべてのサービスにアクセスできなくなってしまいますが、予備の回線を用意しておけば、正常な回線に経路を切り替えることで障害の影響を最小限に抑えられます。

それに対して、クラウドではインフラ部分を管理するクラウドベンダーが内部的に冗長性を確保しており、ユーザーが特別な意識しなくても、一定の可用性を確保できるケースが多くなっています。

ここでは、「サーバー」「ストレージ」「ネットワーク」「電源」というハードウェアの4つの要素に対して、オンプレミスとクラウドでどのように冗長化が行われているかを解説します。

サーバーの可用性

サービスの可用性を高めるためには、まずはサービス提供の土台となるサーバーの冗長化が必要です。サーバーが故障した場合でもシステムが停止しないように、あるいは短時間で復旧できるような構成が理想的です。

オンプレミスでは、サーバーの予備機を用意し、障害時に切り替える運用が一般的です。これには2台のサーバーでクラスターを組み、障害時には運用系から待機系に自動的に切り替える「ホットスタンバイ」や運用系サーバーと同じサーバーを停止状態で用意しておき、障害時に待機系を起動して切り替える「コールドスタンバイ」といった手法があります。

障害時に切り替えるのではなく、常にサーバーを複数台稼動させておき、ロードバランサーを用いて分散処理させる方法もあります。この方法の場合、複数台のサーバーを使うためシステム全体の処理能力が高くなるというメリットもありますが、逆にシステムの性能が要求に対して過剰となってしまうこともあり、注意が必要です。また、ロードバランサー自体が新たな単一障害点(SPoF)とならないよう、考慮しなければなりません。

クラウドでは、サーバーは仮想化されているため、自動フェイルオーバーが可能です。これは仮想サーバーが動作している物理サーバーが停止した場合、自動的にほかの物理サーバー上で仮想サーバーを再起動する機能です。自動フェイルオーバーが利用できる場合、ユーザーは物理サーバーの故障について一切考慮する必要はありません。ただし、クラウドベンダーによっては、自動フェイルオーバーの機能を提供していない場合もあるため、ベンダー選定時にはこうした機能の有無も選定基準に含めるべきでしょう。

ニフクラでは、サーバー1台から物理機器障害時に自動でフェイルオーバーし、約5分で再起動する自動フェイルオーバー機能(HA機能)が適用されます。

ストレージの可用性

ストレージは、故障時にサービスが停止するだけにとどまらず、重要なデータの喪失という危険性も孕むため、冗長化が特に重要な部分です。

オンプレミスでは、RAIDを利用してサーバー内でストレージを冗長化するのが一般的です。その場合、RAIDを管理するコントローラーが単一障害点(SPoF)になってしまうため、1台のサーバー内にコントローラーを複数搭載して信頼性を上げるという構成がよく採用されます。

ストレージを格納する筐体自体を二重化し、ソフトウェアによって筐体間でデータをミラーリングするという構成もあります。ミラーリングを実現するためには、「リモート・アドバンスト・コピー」や「PRIMECLUSTER GDS」などのソフトウェアが利用されています。

ニフクラのディスクは、内部でRAID6相当の冗長化が行われています。そのため、ユーザーがサーバー内であらためてRAIDを組む必要はなく、ストレージのメンテナンス時も無停止で利用できるようになっています。

ネットワークの可用性

オンプレミスでは、ネットワークの経路を構成する個々の要素を冗長化し、障害時には経路を切り替えるのが一般的です。このような冗長化を実現するため、「サーバーでは複数のNICを束ねて利用する」「ネットワークでは複数の転送経路を確保する」「複数のルーターで仮想的なルーターを構築する」といった対策がなされています。また、データセンターとインターネットを接続する上位のキャリア回線も複数の系統を用意する必要があります。

クラウドでは、ネットワークはクラウド事業者によって冗長化されており、通常ユーザーが意識する必要はありません。

電源の可用性

電源が断たれるとハードウェアは停止してしまいますから、複数の電源を確保することはとても重要です。オンプレミスでは、サーバーの電源ユニットを冗長化することはもちろんサーバーラックに2系統の電源を引き込み、それぞれの電源ユニットに給電する構成を取ります。こうすることで、電源ユニットの故障だけでなく、万が一の停電にも備えることができます。しかし、そのためにはラックに複数系統の電源が引き込まれていなければならないため、データセンターによっては実現できない場合もあり、注意が必要です。また、停電に備えた緊急用の自家発電設備を備えているかといった点も、データセンターを選定する際の重要な基準となります。

クラウドでは、当然ベンダーの管理下にある部分のため、ユーザーが電源について意識する必要はありません。

高可用性のシステムを作るために

可用性の高いシステムを作る基本は、単一障害点(SPoF)となる箇所を無くすことです。しかし、システムを構成するさまざまなリソースをすべて冗長化しなければならないため、単純計算でコストは2倍以上に膨れ上がってしまいます。また、障害時の切り替えや復旧時の切り戻しなど、運用手順も複雑になりがちです。

その点、クラウドサービスを利用すれば、サービスの基盤部分の冗長性をベンダーに任せられるため、オンプレミスと比較して低コストで高可用性を実現しやすく、ユーザーは自社サービスの運用に集中できます。ただし、サーバーが再起動した場合など、クラウド環境ならではの復旧プロセスが存在する場合があるため、手放しで運用できるわけではありません。「障害時に自分達が何をしなければならないのか」を把握しておくことは重要です。

インフラをクラウドベンダーに任せていると忘れがちですが、「クラウドならば停止しない」「トラブルが起きない」ということはありません。クラウドも基盤がハードウェア上で動いている以上、障害は起こりうるものです。しかし、クラウドであれば、オンプレミスに比べて障害の影響を最小限にするシステムを実現しやすいのは間違いありません。「障害はいつか起こるのでそれにどう備えるか」を意識してシステムを設計することが大切です。

PageTop