本記事は『マルチクラウドネットワークの教科書 耐障害性と冗長性を実現するデザインパターン』（宮川亮）の「Chapter 1 一般論としてのマルチクラウド」から一部を抜粋したものです。掲載にあたって編集しています。
クラウドサービスの選定理由
日本におけるクラウドサービスの本格展開から10年以上経過し、ITシステムにおいてクラウド利用がファーストチョイスとなって久しい現在、どのクラウドを選ぶべきか、という疑問は簡単で難しいと筆者は考えます。
「簡単」というのは、例えば「クラウド 選定基準」などのワードで検索をかければさまざまな切り口が提示されますが、どの観点も「差があるというほど違いがあるか？」という話になります。AWS、Azure、Google Cloudといった主要なクラウドサービスであればどれを選んでも十分な水準です。
例えば価格。確かに現時点で想定する利用用途や規模で想定のリソース利用量を見積もり、価格表に当てはめれば各クラウドで金額の差はつくでしょうが、それが近い将来も同じ差のままなのか、そもそも利用量の見積もりは正しいのか、といくらでも疑問が出てきます。
「性能やキャパシティが十分なのか」という点を取り上げても、自社システムの利用規模がクラウドが提供する最高水準の性能やキャパシティを超えるものなのかと問えば、ほとんどすべての方は首を横に振るでしょう。業界標準、統制への対応などを取っても、見たことも聞いたこともない規格にまでクラウドは準拠していますし、契約条件なども各クラウドで大きく差がつくようなものではありません。
ガバメントクラウドの調達対象に各社並んで選定されているのを見ればわかるように、どのクラウドも高い水準にありどれを選んでも正解なのですから、簡単な問題です。
一方で「難しい」というのは、「差がつかないからこそどうやって選べばいいのかわからない」という意味です。自社システムにどのクラウドを選定するのかと経営陣に問われて「どれを選んでも大差ないです」と答えるわけにはいきません。
では、すでにクラウドを使っている企業・組織は一体何を基準に選定したのでしょうか。筆者の経験からは「最もシェアが高い有名なサービスを選んだ」が最多のケースだと思われます。身もふたもないお話ですが、これが真実だと思います。
シェアが高ければ情報が多く馴染みやすいですし、扱えるITベンダーも多くなり支援が受けやすくなります。サードパーティ製のソフトウェアの動作環境保証も優先的に行われるでしょうし、コスト面でも有利になると想定できます。クラウドは未知の新技術でありどこまで使い続けられるか明確ではなかった訳ですから、まずはトップシェアのサービスを選んでおけば間違いは少ないはずなのです。では、これ以外の選択理由はどのようなものがあるでしょうか。
どうしても使いたいサービスがある
各クラウドでサービスに差がほとんどない、と言っても違いはあります。過去、日本企業のクラウド選択に大きな影響を与えたのは「西日本にリージョンがあるかどうか」です。オフィススイート製品、データベースなど「指名買い」が起こりやすい製品群がクラウドサービス化し、サポートや価格面で有利な条件が示されて特定のクラウドが選好されることもあります。本書執筆時点での「指名買い」の筆頭はAIサービスでしょうか。意外なほど各クラウドベンダー間に得手不得手があるようで、競争が激しくなりそうです。
クラウドベンダーとの関係性
自社とクラウドベンダーとの関係性の強弱でサービスが選定されることがあります。前項と類似しますが、使用しているOSやミドルウェアが特定のクラウドで有利な条件をもっている、過去の取引実績により得られる支援が大きい、トップ同士が仲が良い、などです。そもそもITシステム分野を本業とし法人営業力の強いクラウドベンダーはこのような「巻き返し」が得意であるようです。
政治的な理由・経営判断
もう1つ特徴的なのは、比喩的な意味での政治的判断です。AWSはオンライン小売業を祖業としていて、多くの企業と取引があると同時に競合関係にもあります。例えば小売り・流通業の企業がAWSとわだかまりなく取引ができるかというと、難しいこともあるでしょう。元々がITシステムが本業であるほかのクラウドはそのような関係性にはならず、取引が受け入れられやすくなります。
本項では、いくつかあるクラウドサービスがどのような理由でITシステムの基盤として採用されるのかの例を見てきました。次の項では、クラウドが未利用の段階からクラウドサービスへの「リフトアンドシフト」を経てマルチクラウド利用に至るまでの道のりをご紹介したいと思います。
システム分散
クラウドは利用までの障壁が低く、契約を解除して支払いを止めれば利用停止も容易です。ですが、クラウドで作られたシステムはそうではありません。一度作られて稼働が始まればビジネスの一部として不可欠な機能を担うでしょうし、構築までに投じたコストの償却という意味でも重い存在の資産となります。その稼働基盤となるクラウドも同様に捨てられない存在となります。
その状況で、例えば別のシステムで新しい機能が必要になったり、開発の都合で新しいクラウドを利用したくなったりすれば、必然的に複数のクラウドを併用するマルチクラウドになります。
複数のクラウドを利用するにあたり技術習得や開発、セキュリティや統制に合わせたルール、制度化などのハードルが発生しますが、一度それを乗り越えてマルチクラウドに進んでしまえば、さらに活用の幅は増え、利用するクラウドも増えてきます。取引先、接続先がシステム更改する際のリプレース先の基盤は自社が使っていないクラウドだったならば、また新しいクラウドの利用を検討することになります。各社の方針に任されていたクラウド利用が、グループ会社全体の特定クラウド利用の方針に寄せられていくことなども考えられます。
長く運用を続けていると、あるクラウドで大規模な障害が発生することがあります。一部でも自社システムの機能が損なわれていればもちろん、取引先やライバル企業への影響、直接的な影響は全くなくても社会的な影響があり大きく報道されるだけで、自社システムへの点検指示が下りてきます。
影響がなかったのは備えが適切だったからなのか、単に幸運だっただけなのか。実行に移すか否かは別として、新たな要件が発生しその実装を検討することになります。障害が直撃してビジネスに多大な損害が出ていれば、再発防止策としてマルチクラウドへの積極的なシステム分散が議論されるでしょう。
逆に、クラウド利用の縮小もあるでしょう。マルチクラウドのコストや運用負荷に見合わないメリットが問題にされたり、撤退したビジネスにひも付くシステムの基盤が不要になったりすることもあるでしょう。ITベンダーとの取引の結果で利用クラウドを絞り込むことがあるかもしれません。また、利用していたサービスからクラウドが撤退してしまい、泣く泣く移行を強いられることもあるでしょう。
いわばこれが「クラウドジャーニー」ならぬ「マルチクラウドジャーニー」です。ネットワーク基盤はこれに寄り添い、ときにはこれを先導するように、技術面、運用面での準備を怠らないようにしなければならないと筆者は考えます。
マルチクラウドジャーニーの段階
オンプレミス基盤のみ、クラウド未利用の段階
クラウドの利活用を開始する前の段階です。
本部・本社にリソースが集中していれば建物内に閉じたLANにITリソースが集約され、昨今の情勢に合わせてリモート接続機能が追加されているのが典型的なネットワーク構成です。情報収集やオフィスソフトウェアを始めとしたSaaSの利用、取引先との接続のためにインターネット接続回線とファイアウォールを備えることも一般的です。店舗や事業拠点、工場などを本部・本社から離れた地域に展開していれば自社でWAN網を構築・維持しているケースもあるでしょう。
サンプルとして、東京に本社とデータセンター、大阪に支社、全国主要都市にオフィスを構える事業会社を例にして、ネットワーク構成を示してみます。
シングルクラウド利用の段階
全くクラウドサービスを利用していなかった段階から、クラウドベンダーの選定を行い利用を始めれば「シングルクラウド」の段階となります。情報システム部や事業部門、あるいは経営層からの発案でクラウドの利用が検討されます。ウェブや書籍、技術イベントでの情報収集から始まり、クラウドやSIerなどのITベンダーからの営業や提案を受け、検証・試験的な利用からスタートすることが考えられます。
検証を終えて本格的に利用が始まれば、クラウド利用のルールや統制などが整備され、一部のシステムを移行していく流れになります。リフトアンドシフトの「リフト」の始まりです。「リフト」は検証の構成を踏襲して、シングルクラウドでVPC内の仮想サーバーを利用して構築されるケースが多いでしょう。
「リフト」の実績が積み上がり始めると、加速をつけてクラウドが利用されていきます。ノウハウの共有とルール整備が進みクラウドファーストの理念が広まってくれば、組織内に完全にクラウドが定着したと言えるでしょう。
複数のクラウドを個別に利用する段階
特定のクラウドが備える優れたサービスを利用したり、外部システム側の指定などのため散発的に異なるクラウドを利用したりするプロジェクトが発生した段階です。
クラウド利用開始以前ならばあれやこれやと理由をつけてクラウド利用を拒絶していたところですが、この段階では、異なるクラウドの利用も受け入れられることになります。また、特定のクラウドから革新的なサービスが提供されれば一気にその傾向は強まります。例として、本書執筆時点で大変な盛り上がりを見せている生成AIのようなサービスは、それが得意な特定のクラウドサービスを新たに利用開始する理由になるでしょう。このようなことを繰り返しながら、複数のクラウドを併用してITシステムを維持、発展させていくのが徐々に当たり前になります。
複数のクラウドをシステム内の一部機能で併用する段階
異なる複数のクラウドの利用が一般化し、新規システム開発や更改などのタイミングで相互に連携し合うシステムが複数のクラウドに分散配置されるようになります。
最初に使い始めたクラウドがデフォルトに位置付けられながらも、要件に最適だと判断されれば異なるクラウドを利用することをためらうことがありません。複数のクラウドの存在を前提にしたルールや規約が定められるでしょう。また、徐々にリフトアンドシフトの「シフト」も進み始め、クラウド上での稼働を前提にした「クラウドネイティブ」なシステムの実装が進むこともあるかもしれません。
組織内に多数の構築・運用の事例ができノウハウが積み上がります。クラウドの恩恵を受けてシステムの効率化、高機能化も実現しますが、運用期間が長くなると障害やメンテナンスなどの制約も意識されるようになってきます。そうなると、次の段階です。
複数のクラウドに同等の機能を実装して併用する段階
クラウドでは年間に1件程度、社会的な影響が大きくWebやSNSだけではなく一般ニュースや新聞紙上を騒がせるレベルの大障害が発生します。自社システムが被害を受けたならばもちろんのこと、それを免れたところで「クラウドの大規模障害への備えは十分なのか」と顧客や経営層、株主などから問いかけられることになります。
大規模障害の原因を追究すれば、クラウド上のシステムの可用性向上を実現するためには特定のクラウドに依存しては危険であるという結論に至ります。特定サービスに依存する「ベンダーロックイン」を警戒する必要性も相まって、複数クラウドにシステムを等しく分散させることが検討されます。幸い、リフトアンドシフトの「シフト」の到達点の1つに「特定のクラウドに縛られないシステム構成」があります。アーキテクチャを刷新してマイクロサービス化し、コンテナ技術によりクラウドの差異を吸収する、というストーリーがわかりやすいでしょう。
まとめ
各組織のクラウド活用の現状がどの段階であるか、理想の状態がどの段階なのか、というのはそれぞれの組織の業界や業務の特性、システムの規模、IT予算などのリソースなどによってさまざまであるはずです。クラウドを一切利用しないのも極端ですが、クラウドの活用度合いが高ければ高いほど良いとも限りません。その組織にとって程よいレベルがあって、それを模索しながらITシステムが変化し続けていくことが「その組織のマルチクラウドジャーニー」であるはずです。
