ここ数年、日本企業でもクラウドコンピューティングの利用が拡大しています。特に2020年は新型コロナウイルスの影響もあり、クラウドへのシフトが一気に進んだと言われています。

その一方で、クラウドサービスの提供ベンダーの淘汰・再編も一段落しつつあります。現在、IaaSで世界シェアのトップを走るのがAmazon、それを猛烈に追い上げているのがMicrosoft、少し遅れてGoogleという構図になっています。この3強体制が、ほぼ定着したと言って良いでしょう。データセンターは規模の経済が働く分野であり、先行する3強体制に今から追いつくのは、もはや現実的ではなくなりました。「メガクラウド」時代の到来です。

その一方で、ビジネスのクラウド依存が高まるにつれ、ひとつのクラウドサービスに頼り切ることのリスクも表面化してきました。そこで、近年注目を集めているのが「マルチクラウド」です。「マルチクラウド」とは、その名の通り、複数のクラウドサービスと契約して、システムを分散あるいはバックアップするという、クラウド利用の新しい形態です。

マルチクラウドには、主に3つの目的・利点があります。

1）障害のリスクを分散し、可用性を向上させる。
2）ベンダーロックインの回避。
3）クラウド事業者の特長に合わせた適材適所での活用。

それぞれについて詳しく見て行きましょう。

リスク分散と可用性の向上

クラウドの可用性はそもそも高くない 
ビジネスのクラウドへの依存度が高いほど、クラウドサービスが停止した場合の影響も大きくなります。
2019年に起きたAWSの大規模障害では、日本でも多くの企業が影響を受けましたし、2020年12月にはGoogleのサービスが世界規模で停止し、数十分間とはいえ多くの地域でまったくサービスを使えない状況が生まれました。このような世界的なニュースになる大規模な障害以外にも、クラウドの障害はたびたび起きています。クラウドサービスの信頼性（可用性）は、そもそもそれほど高くは無いのです。 クラウド上のインフラを提供するIaaSなどのサービスでは、「クラウドの可用性」を示すSLA（Service Level Agreement）が規定する稼働率の値は、その重要性に見合うほどの数値には達していません。クラウド各社のSLAは、だいたい99.9%～99.99%といったところですが、99.99%の場合、年間で53分弱、システムを利用できない可能性があります。

オンプレミスのシステムの場合には、メンテナンス時間は自社で決めることができますし、メインフレームであれば稼働率は99.9999%（年間ダウンタイム：32秒弱）と言われます。それでも安心・満足できない場合（銀行のオンラインシステムなど）は、まったく同じ構成を持つシステムを東京と大阪に冗長化して設置するといったことが行われます。ここまで行えば、事実上稼働率は100%と言えるでしょう。オンプレミスでは、（お金はかかりますが）自社で可用性をある程度コントロールできるのです。

リスクを回避するためにはユーザー側の対応が必要 
クラウドサービスの可用性が高くないことは契約に明示されていますし、ユーザー側もそれを理解した上で使いこなす必要があります。クラウド上でのシステムの可用性について責任を持つのは（オンプレミスでもそうですが）本来ユーザー側なのです。

オンプレミスからクラウドへシステムを移行する際のプロセスとして、「リフト＆シフト」という手順があります。まずはクラウド上に仮想マシンを立ち上げて、そこにオンプレミスのシステムを移行させて稼働させるのが「リフト」です。しかし、このままではクラウドサービスに障害が起きた場合の回避策はとられていません。本来、クラウド上で可用性を担保するためには、「クラウドは止まるものだ」という認識の元でリスクを回避するシステム構築を行う必要があります。これがクラウドネイティブへの「シフト」です。ここまでをセットで行う事で、「リフト＆シフト」が完成するのです。

最初の選択肢は同じクラウドサービス内でのフェイルオーバー 
多くのクラウドサービスでは、自社のクラウド内でバックアップ用のシステムを運用できるようになっています。その際、気をつけなければならないのは、「本番システムとバックアップのシステムを同じ場所に置かない」ことです。AWSなどでは、データセンターの運用単位に「リージョン」と「アベイラビリティゾーン（AZ）」があります。リージョンは、東京、米国東部、シンガポールなど、データセンターが物理的に立地している場所です。そして、1つのリージョンは複数のAZに分割されています。AZ同士は互いに論理的に分割されており、ひとつのAZがダウンしても他のAZには影響が及ばないようになっています。

このため、クラウド上のシステムを構築する際にまず考えるべきことは、本番システムのAZに障害が起きた時に他のAZにフェイルオーバーするような仕組み（「マルチAZ」）を作ることです。しかし、自然災害などの場合にはリージョン全体が影響を受ける可能性がありますので、そのリスクを回避しなければならない場合にはマルチリージョンでの障害対策を視野に入れる必要があります。

しかしそれでも、先日のGoogleのように世界規模で障害が発生した場合には逃げ場がないということになります。そこで、障害対策としてのマルチクラウドが注目されているのです。

ベンダーロックインの回避

ベンダーロックインとは、コンピュータ業界では昔から指摘されている問題で、システム導入時に特定のベンダーの製品を導入すると、プログラムや周辺機器が他社のシステムには流用できず、同じベンダーの製品を使い続けるしかなくなることを指します。ベンダーにとっては顧客囲い込みのための重要な戦略ですが、顧客側から見れば割高なシステムを押しつけられるリスクが付きまといます。顧客側はベンダーロックインの回避を望んでおり、近年オープンソースソフトウェアの利用が盛んなのも、ベンダーロックインの回避が目的の一つであるとされています。

クラウドサービスでも状況は似ており、ひとつのベンダーから乗り換えられないことは、コスト的なデメリットや前項のような可用性の面でのリスクにも繋がります。

クラウド事業者の特長に合わせた適材適所での活用

クラウドベンダー間で提供されているサービスは、似たようなものからまったく違うものまで、さまざまで、提供時期にも違いがあります。すぐにでも使いたいサービスがある場合に、そのベンダーではまだ提供されていない場合、企業の競争力に影響する場合もあります。ここにも、マルチクラウドのメリットがあります。

技術的課題の克服

これまで見てきたように、マルチクラウドにはメリットが多いことはわかっていました。しかし、ことはそう簡単ではありません。たとえば、ひとつのクラウドベンダー上で稼働している仮想マシンを他社のクラウド上で動かそうとする場合には、管理ツールや実装技術の違いから、高いハードルが存在していたのです。

それが、近年徐々に解消されつつあり、本格的なマルチクラウド時代がやってこようとしているのです。本コラムの次回では、技術的課題の克服について解説してまいります。

マルチクラウドコラム第2回目はこちらからご覧ください。

マルチクラウドを可能にした技術　～コンテナとKubernetes

マルチクラウドの運用・管理でお困りではないでしょうか？

WEBサーバーを運用しているクラウドサービスに加えて、各種の業務用アプリケーションを運用している別のクラウドサービスなど、社内に複数のプロバイダーが提供するクラウドサービスが導入されていて、その運用・管理にお困りではないでしょうか？

マルチクラウドの運用ならばミツイワにおまかせください。
ミツイワの「マルチクラウド運用サービス」では、NIFCLOUDやAWSなどのクラウドサービスを安全・快適にお使いいただくための各種サービスを充実させております。24時間365日の監視を実装した基本サービスに加え、各社によって差のあるサービスを補完する機能や、運用負荷軽減に不可欠なオンサイトサポートなど豊富な機能をメニューから選択してご利用いただけます。