ディスカッション |マルチクラウドは罠であり、まったく役に立たないのでしょうか?

「曇り」は、クライアントとの会話でよく聞かれる言葉です。私たちはクラウドに依存しないことを望んでおり、ベンダーロックインを回避する必要があります。複数のクラウド プロバイダー間でワークロードをシームレスに移動できるようにしたいと考えています。もう一度言いますが、マルチクラウドは罠です。 Amazon データセンターでワークロードを実行することにあまり熱心ではない少数の大手小売業者を満足させることを除けば、あらゆる規模のエンタープライズ組織にとってマルチクラウドが優先されるべき理由はあまり思いつきません。

一見すると、マルチクラウド戦略は素晴らしいアイデアのように思えるかもしれませんが、不必要な制約が生じ、逆効果になることがあります。ほとんどの人にとって、それは結局、解決するよりも多くの問題を生み出す気を散らすものになってしまうのです。現在、「マルチクラウド」という場合、複数のベンダーのプラットフォーム上で同じサービスを実行したり、複数のプロバイダー間でスムーズに移動できるようにアプリケーションを設計したりするという考えを意味します。ここで言っているのは、各クラウド プロバイダーの最高のサービスを活用する、あるいはプロバイダー間でより高レベルの付加価値サービスを使用するという概念ではありません。

[[244610]]

マルチクラウドはさまざまな理由で注目されていますが、災害復旧、ベンダー ロックイン、価格設定などに分類できます。これらの各ポイントについて詳しく説明し、マルチクラウドが実際に役立つ場所について説明します。

災害復旧

マルチクラウドは、災害復旧を実現する手段として高く評価されています。災害復旧について議論する際には、クラウド プロバイダーがどのように機能するかを明確に理解することが重要です。 AWS、GCP、Azure などのパブリック クラウド プロバイダーには、リージョンと可用性ゾーンの概念があります (Azure は、可用性ゾーンがよいアイデアであることを苦い経験から学んだため、最近になって特定のリージョンに可用性ゾーンを導入しました)。リージョンとは、特定の地理的領域内にあるデータセンターの集合です。可用性ゾーンは、リージョン内の 1 つ以上のデータセンターです。各アベイラビリティ ゾーンは専用のネットワーク接続と電源バックアップ システムによって分離されており、リージョン内のアベイラビリティ ゾーンは低遅延リンクによって接続されています。可用性ゾーンは、同じ建物内（独立したコンピューティング、電源、冷却など）にある場合もあれば、完全に別々で、数百マイル離れた場所にある場合もあります。

地域全体に影響を及ぼすような障害は稀です。これが起こると、通常はインターネットの半分がダウンすることを意味するため、注目度の高い出来事となります。アベイラビリティ ゾーン自体は地理的にある程度分離されているため、地域全体を壊滅させる自然災害は、基本的にバージニア州を隕石が破壊するのと同等です。ゾーン障害のより一般的な原因は、構成エラーやその他の操作エラーです。稀ではありますが、実際に起こります。ただし、リージョンは高度に分離されており、プロバイダーは複数のリージョンでの障害を回避するために、時間差をつけてメンテナンスを実行します。

これは、複数の地域での障害が不可能であると言っているのではありません (隕石が米国本土の半分を破壊したり、奇妙な連鎖障害が発生するのと同じ意味で)。一部のバックボーン インフラストラクチャ サービスは複数のリージョンにまたがっている場合があり、大規模なインシデントが発生する可能性があります。複数のクラウド プロバイダーを使用することは、単一のプロバイダーによるマルチリージョン戦略よりも明らかに安全ですが、コストがかかります。災害復旧は非​​常に複雑なテーマであり、十分に理解されていないと思います。実際のところ、クラウド ポータビリティはそれらのコストを最小限に抑えるのにほとんど役立たないと思います。 Google や Amazon のような規模で運用しない限り、強力な災害復旧戦略を策定するために複数のクラウドを用意する必要はありません。結局のところ、Amazon は世界最大の小売業者の 1 つなので、災害復旧戦略が Amazon の戦略と一致していれば、おそらくかなり良い状態にあると言えるでしょう。

ベンダーロックイン

ベンダー ロックインとそれに伴う恐怖、不確実性、疑念 (FUD) は、マルチクラウド戦略を推奨するもう一つの一般的な理由です。ボー・リドンは、自身の記事「ビール代を無駄にしないで」の中で、このことを述べています。

クラウド、DevOps、サーバーレス。これらはすべて、共通のニーズを商品としてパッケージ化するために作成されたトレンドと市場です。それらは完璧な解決策ではないかもしれません。はい、結局「閉じ込められてしまう」可能性があります。しかし、そのリスクを負う価値はあると思います。思ったほど悪くはないよ。ティム・オライリーはそれをうまくまとめました。

ロックインは、あなたが完全なコントロールを持っているからではなく、他の人があなたのサービスから利益を得るから起こります。

私たちはサービスから利益を得ているため、閉じ込められています。まず、サービスから最大限の価値を得ていることを意味します。そして、消費者グループとして、私たちはそれ以上のものを楽しんでいます。これらのプロバイダーは、私たちが享受できる価値を継続的に提供するために全力を尽くします。これにより収益の成長が促進されました。 O'Reilly 氏が指摘しているように、プロバイダーが実際に制御できるのは、あなたが思っているほど多くありません。彼らは、市場の最大のセグメントに利益をもたらすと信じるシステムを構築します。彼らは、私たち（市場参加者）が注目するものに焦点を当てるでしょう。

競争ももう一つの重要な要素です。 AWS のような強力なプロバイダーであっても、競合するクラウドプロバイダーは数多く存在します。競合他社は市場のギャップと認識しているものに対して差別化されたソリューションを提供しようとしますが、基本的なニーズも満たす必要があります。そのため、これらのプロバイダーが提供する共有サービスが非常に多くあります。これらすべては我々にとって有利です。私たちは提供されたものを最大限に活用すべきです。はい、あるプロバイダーから別のプロバイダーに移行するには依然としてコストがかかりますが、それらのコストは実際にはオンプレミスからクラウドに移行するコストよりもはるかに低いと思います。実際にクラウドを導入すると、柔軟性が得られます。

多くの企業がベンダー ロックインを回避するために行っている精神的な取り組みや、マルチクラウドの多くの「理由」を目にすると、いつも驚かされます。企業が、差別化に何の役にも立たないものに多額の資金を費やすのは不可解だ。

これにはいくつかの理由があると思います。まず、ボーが指摘するように、私たちは自分の能力を過大評価し、コストを過小評価する傾向があります。このため、自社で構築するか、外注するかについて誤った判断を下すことになりました。これは、消費者が自分たちが部分的に作成した製品に不釣り合いに高い価値を置くという事実を指すイケア効果とも密接に関係しています。第二に、企業組織における権力と影響力が、特に製品志向で IT からビジネスへと移行するにつれて、これは IT 運用部門が制御と地位を維持するための新たな試みだと私は考えています。

クラウドに依存しないことは、重要な決定を推進するほど重要な目標ではありません。クラウドに依存しないことを出発点とすると、クラウドのメリットを十分に享受する能力が大幅に制限されます。コンピュータをレンタルするだけです。 Pivotal Cloud Foundry や Red Hat OpenShift などのプラットフォームは、すべての主要なプライベート クラウドとパブリック クラウドで実行できると主張していますが、そのためには、各クラウド プラットフォームの差別化された機能をすべて抽出するための抽象化レイヤーが本質的に必要になります。ロックインを回避するために差別化機能を抽出すれば、価値も抽出されます。結局、プロバイダーによって「ロックアウト」されてしまい、基本的にはサービスの価値を十分に享受できなくなることになります。抽象化によってシステムが共通インターフェースに簡素化されるかどうかは分かりません。もしそうなら、差別化されたプロバイダーの機能をどのように活用し、クラウドに依存しないままでいられるかは不明です。そうでなければ、その価値が何なのか、あるいはどのようにして真のマルチクラウドを実現できるのかが不明です。

PCF や Red Hat を厳しく批判するつもりはありませんが、大手クラウド プロバイダーがプラットフォームのバンドル解除と、よりコモディティ化された方法での再バンドルを継続しているため、これらのマルチクラウド プラットフォームのセールス ポイントは低下し始めています。 Kubernetes やコンテナが登場する前の時代、PaaS (Platform as a Service) の全盛期には、プロバイダーは説得力のあるストーリーを語っていました。現在、コンテナ、Kubernetes、特に Google の GKE や GKE On-Prem などのシステム (および他のプロバイダーの同様のサービス) の人気が高まっているため、そのストーリーを売り込むのはますます難しくなっています。興味深いことに、最近発表された Knative は、Pivo​​tal や Red Hat などとの緊密な連携により開発されており、Kubernetes の勢いを利用して、企業によるサーバーレス コンピューティングの導入から何らかの価値を獲得するための取り組みであると思われます。

しかし、誰かがこれらのマルチクラウド プラットフォームをサービスとして実行する必要があり、ここに問題があります。この責任は多くの場合、運用チームまたは共有サービス チームに移管され、ベンダーとのサービス契約に基づいて複数のクラウドで運用する必要が生じます。

マルチクラウドを展開するには、複数のクラウド プラットフォームに関する専門知識が必要です。 PaaS では、開発者向けにこの部分を抽象化しますが、運用および保守担当者に委譲します。さらに、複数のプラットフォームを認証することによるセキュリティとコンプライアンスへの影響についてはまだ検討していません。クラウドへの移行を始めたばかりの企業にとって、これは現状を大きく混乱させる可能性があります。誇大宣伝を乗り越えれば、マルチクラウドの本当の意味を理解できるようになります。

顧客向けの PaaS を管理せずに PaaS を実行することは、今日では単純に機能しません。これはどの企業にとっても戦略的ではありません。また、Pivo​​tal や Red Hat などの企業は主にサービスから収益を得ていることも指摘しておきたいと思います。これらのプラットフォームは、プロフェッショナル サービスの収益を促進するのに役立ちます。

一般的に、非戦略的なシステムに対するベンダー ロックインによる企業へのリスクは低いです。データベースにデータを保存することを例に挙げます。 Amazon DynamoDB、Google Cloud Datastore、Azure Cosmos DB のいずれの場合でも、NoSQL、リレーショナル データベース、ANSI 準拠の SQL、独自のデータベースなどの技術的な違いがあるかもしれませんが、基本的にはすべてデータのインポートとエクスポートを行います。これらのデータベース間でデータを移動するには技術的な作業が必要になる場合がありますが、それは克服できないものではなく、データベースを使用することで得られるメリットはこのコストをはるかに上回ります。ベンダー ロックインは、コア戦略システムに依存している場合にのみ問題になります。このようなシステムは、実際のビジネス ロジックを実行したり、会社のビジネスをサポートする重要な要素となる場合があります。 Joel Spolsky 氏は、「コアビジネス機能であれば、ぜひ自社で実行してください。コアビジネス機能と目標を選択し、社内で実行してください」と述べています。 https://www.joelonsoftware.com/2001/10/14/in-defense-of-not-invented-here-syndrome/ を参照してください。

価格

マルチクラウドをサポートする理由の中で、価格競争力は最も弱いものです。実際、コモディティ化が進むにつれて、すべてのサプライヤーは誰が最も低コストであるかを競い合うようになります。プロバイダーによっては、あるプロバイダーにはより多く支出し、他のプロバイダーにはより少なく支出することになります。マルチクラウドの価格裁定取引は非常に非現実的です。さらに、数量割引は考慮されません。 AWS と GCP を比較した記事で述べたように、クラウド プロバイダーを選択する際には、リソースをどこに投資したいかが重要になります。

価格設定の固定化（サプライヤーがあなたを固定化して価格を上げる）という側面はまったく意味をなさない。まず、規模の経済はそうやっては機能しません。クラウドに移行すると、あるプロバイダーから別のプロバイダーに切り替えるコストはオンプレミスの場合よりもはるかに低くなるため、プロバイダーにとって最善の利益にはなりません。彼らは市場で最大のシェアを獲得するために必要な措置を講じ、競争力によって Infrastructure as a Service (IaaS) のコストが引き下げられるでしょう。競争環境と市場シェア獲得のための戦いにより、価格設定が収束する可能性があります。クラウド プロバイダーが利益率を高めたい場合、サービスとしてのソフトウェア (SaaS) と付加価値サービスに移行する必要があります。

さらに、ほとんどのパブリック クラウド プロバイダーはボリューム ディスカウントを提供しています。たとえば、AWS では、EC2 に対して最大 75% の割引を提供するリザーブドインスタンスを提供しています。他の AWS サービスにはボリューム割引があり、Amazon は統合請求を使用して企業内のすべてのアカウントの使用量を組み合わせて合計価格を最小限に抑えます。 GCP では継続利用割引を提供しています。これは、請求月の大部分にわたって GCE インスタンスを実行すると自動的に割引が適用される割引です。また、インスタンスを置き換えるときに割引が適用されないように、部分的に使用されたインスタンスを 1 つのインスタンスに結合する、いわゆる推論インスタンスも実装します。最後に、GCP には、Amazon の予約インスタンスと同等のコミット利用割引もあります。リソースが複数のクラウドプロバイダーに分散されている場合、このような割引を享受することは難しくなります。

マルチクラウドが役立つ場面

はい、ほとんどの企業組織にとって、マルチクラウドは邪魔なもので、通常はそうなります。クラウドを検討し始めたばかりの企業にとって、マルチクラウドは意味がなく、本当に重要なことから注意をそらすだけです。それは物事を遅らせ、FUDの種を蒔くことになるでしょう。

一部の企業は、すべての卵を一つのバスケットに入れるリスクを回避するために、複数のプロバイダーのプラットフォームを同時に構築しようとしています。これは逆効果であり、実際には失敗するリスクを高めると思います。中小企業の場合は、サプライヤーを選び、製品化に取り組みます。可能な限りマネージド サービスを活用し、マルチクラウドを理由にマネージド サービスを活用しないようにしてください。大企業が複数のプロバイダーにまたがって構築することは不合理ではありませんが、制御された実験を通じて行う必要があります。これはクラウドの利点の 1 つです。多額の先行投資をすることなく、限定的な投資と実験を行うことができます。マルチクラウド PaaS 製品およびサービス契約に直面するときは、この点に留意してください。

しかし、それは曇りの場所がないという意味ではありません。物事は決して絶対的ではありません。複数の事業部門を持つ大企業にとって、マルチクラウドは不可欠です。これは、製品チーム、企業の IT インフラストラクチャ、そしてもちろん企業の合併や買収の成熟度の違いによる結果である可能性があります。マルチクラウドの主な価値は、各クラウドの長所を活用できることであり、これが私がマルチクラウドを支持する数少ない理由の 1 つだと考えています。これは、プロバイダーが上流へ移動するということになります。プロバイダーが付加価値サービスで差別化を図ろうとするにつれて、マルチクラウドがより意味を持ち始めます。第二に、データ主権の理由からマルチクラウドが必要になるかもしれませんが、リージョンとアベイラビリティゾーンが一般的になるにつれて、データ主権の問題は少なくなると思います。ただし、Google の Cloud Spanner などの一部のサービスでは、可用性ゾーンの粒度を省略して「グローバルに利用可能な」サービスとなる場合があるため、GDPR などの規制に対処するときはこの点に注意してください。最後に、コロケーション施設を複数のクラウド プロバイダーのプラットフォームに拡張する場合は複雑になりますが、コロケーション施設を持つ企業にとってハイブリッド クラウドは常に現実的な選択肢となります。

クラウドを使い始めたばかりであれば、マルチクラウド戦略について心配する必要はありません。それは、あなたの指針となる目標や、会社の中核となる決定や戦略的プロジェクトを推進するものであってはなりません。それは適切な場面ではありますが、多くの場合は無駄であり、本当に重要なことから注意をそらすだけです。

Tyler Treat 氏は、企業のクラウド ソフトウェア構築を支援する Real Kinetic のマネージング パートナーです。以前は Apcera で、クラウドネイティブ アプリケーション向けのオープンソースの高性能メッセージング システムである NATS の開発を担当していました。