エキスパートに聞いた、マルチクラウドに関する 5 つのすべきこととすべきでないこと
Google Cloud Japan Team
※この投稿は米国時間 2021 年 8 月 19 日に、Google Cloud blog に投稿されたものの抄訳です。
技術者を熱くさせたければ、何人か集めてマルチクラウドを話題にしてみましょう。議論の種に困ることはないはずです。以前からこの注目の話題に真正面から取り組みたいと考えていた私は、先日、Duckbill Group の Corey Quinn 氏、Hashicorp の Armon Dadgar 氏、Gremlin の Tammy Bryant Butow 氏、VMware の James Watters 氏という 4 人の有識者と、マルチクラウドの重要性、考慮すべき重要なポイント、マルチクラウドを採用すべき（または採用すべきでない）理由について語り合いました。
この一連のディスカッションからは、5 つの重要な洞察が得られました。すでにマルチクラウドに着手している方、あるいはマルチクラウドを検討している方はぜひお読みください。
すべきこと: 適切な理由でマルチクラウドの運用を選択する
「Gartner が推奨しているから」という理由でマルチクラウド化を行うべきではない、と Corey Quinn 氏は訴えています。Armon Dadgar 氏は、マルチクラウドを始める前に、ビジネス上の価値を創出するプロセスに着目して「理由」を定義すべきだと言っています。Tammy Bryant Butow 氏によると、異なるパブリック クラウドのサービスを使用する理由として、たとえば各パブリック クラウドがそれぞれ差別化されたサービスを提供していることが挙げられます。Armon 氏はさらに、規制上の理由、既存の取引関係、合併や買収への対応も付け加えています。M&A が話題に上ったときには、Corey 氏は、別のクラウドを使用している会社を買収する場合、たいていコストがかさむうえ、整理統合も困難である点を指摘しました。動かずじっとしているほうが賢明かもしれません。
すべきでないこと: ワークロードまたはデータ ポータビリティをオーバー エンジニアリングする
さまざまなクラウド プロバイダの間でシームレスに動作するシステムを構築しようと考えていませんか？「ちょっと待ちなさい」と、有識者全員が口を揃えて言っています。Armon 氏は、「ワークフローやグローバル ネットワーク ルーティングをいくつか思い浮かべればわかるとおり、ツールチェーンやアーキテクチャの側面はマルチクラウドでも構わないが、ワークロードやデータを移動することは決して簡単ではない」と指摘しています。Corey 氏は、「一度書けば、どこでも動く」という理想を追い求めると、進捗が遅くなり、各プラットフォームの一部である固有の独自性が無視される恐れがあると言っています。こうした独自性として、具体的には、クラウドごとの ID 管理の粘着性、セキュリティ上の特性、ネットワーク機能を挙げています。さらに James 氏は、「データ グラビティはやはり強力であり、これを理由にマルチクラウドを頭から否定する人たちもいる」と言っています。
また Armon 氏は、「複数のパブリック クラウドを使用する場合は、各クラウドが提供するまったく異なる価値をうまく活用しなければならない」と言っています。できる限りネイティブ クラウド サービスを使用しましょう。そうすれば、有益なイノベーション、組み込みの復元力、実装されたベスト プラクティスといった利点が得られます。そのようなクラウドによってもたらされるワークロードの価値のほうが、シームレスなポータビリティの利点を上回る場合があります。
すべきこと: 関係者の異なる利益やニーズを認識する
James 氏は、「マルチクラウドについて多くの論争が起こるのは、各自がそれぞれ異なる見地から主張するからだ」と賢明にも指摘しています。背景が重要なのです。ある特定のクラウドの ID とアクセスの管理モデルに多大に投資しているインフラストラクチャ エンジニアにとって、マルチクラウドは扱いにくいように見えます。また、特定のクラウドにペタバイト規模のデータを保存しているデータ エンジニアから見ると、マルチクラウドは非現実的かもしれません。James 氏は、日々のすべての業務をマルチクラウドのローカルツールでこなしている多くの開発者にとって、マルチクラウドが当然の前提条件となっていることを強調しています。開発者の IDE や好みのコード フレームワークは、特定のクラウドに縛られているわけではありません。組織内のグループがそれぞれ異なる方向からマルチクラウドを目指していることを意識してください。これにより、マルチクラウドへの取り組み方が変わってくる可能性があります。
すべきでないこと: 独力で行う
Corey 氏は、何が成功し何が失敗したかを、先にマルチクラウドを試した人に尋ねることの重要性に言及しています。Tammy 氏は、実験やテストの結果の共有に関するベスト プラクティスを提供してくれました。知識を共有し、それをコミュニティの利益のために活用することが大切だと言っています。自分がしようとしていることを先に試した人がきっといるはずです。そうした人の意見を参考にすれば、よくある落とし穴を避けられます。アーキテクチャに関する選択をしてうまくいかなかった場合は、失敗を共有して、他の人が同じ過ちを犯さずに済むようにしましょう。
アナリストの調査レポートを読み、カンファレンスへの出席や動画を通して事例を収集しましょう。また、失敗を共有し他者の経験から学ぶための安全な場所を提供しているオンライン コミュニティに参加しましょう。
すべきこと: まずマルチリージョン デプロイのような手法を使用して試行する
複数のクラウドにまたがってシステムを運用できそうな場合、まず特定のクラウドでリージョンにまたがったシステムの運用を試してみることを Corey 氏は提案しています。「クラウド リージョンをまたいでシステムを適切に機能させるというのは決してあなどれるものではない」と彼は言います。その経験を通して、複数のクラウド プロバイダを利用した場合にさらに悪化すると考えられる、アーキテクチャ上または運用上の制約がどこに存在するかを明らかにすることができるからです。
マルチクラウドの最も標準的な定義は「異なるアプリケーションに対して異なるクラウドを使用すること」ですが、そうではなくて、ある 1 つのアプリケーションの基盤として複数のクラウドを使用しようとしている場合、この助言は非常に的を射ています。また、それ以外にも、分散システムの使用時にうまく機能しないサポート プロセスやツールチェーンの問題が表面化する可能性もあります。積極果敢にマルチクラウド アーキテクチャに飛び込む前に、まずマルチリージョン デプロイやカオス エンジニアリングから始めてください。
Google Cloud の出番
上記のことを実践しましょう。これらはいずれも貴重なアドバイスです。私はこれに、Google のお客様から学んだ以下の 3 つのことを付け加えます。
マルチクラウドを恐れない。マルチクラウドは、すでに皆さんが実践していることです。あらゆるニーズを単一のソースで満たしている人はいないでしょう。Corey 氏が言うように、皆さんはおそらくすでに、生産性向上ツール、ソースコード、クラウド インフラストラクチャに対してそれぞれ別々のクラウドを使っていることと思います。今後も、単一のアプリのために複数のプロバイダのソフトウェア サービスやアプリケーション サービスを使用することになるでしょう。また、皆さんのチームは長年にわたってそうした経験を積んできています。1 つのアプリケーションの背後で複数のインフラストラクチャ サービスを使用することに対しては誰もが不安を感じるはずです。レイテンシ、セキュリティ、ロジスティックに関する問題が生じる可能性があるため、これは当然のことです。チームがどのモデルを検討しているかを必ず把握してください。
Kubernetes などの適切な基礎コンポーネントを採用する。すべてのものを Kubernetes で実行できるでしょうか？答えはもちろん「ノー」であり、このようなことを試みるべきではありません。しかしこれは、Google のマルチクラウド API に対する取り組みに非常に近いことを言い表してもいます。企業は Kubernetes を使用して、複数のクラウドにわたる一貫したエクスペリエンスをストライプ化しています。これはコンテナをオーケストレートすることだけでなく、インフラストラクチャの管理とクラウドネイティブ サービスの管理を行うことでもあります。こうしたことに加えて、プロビジョニングや ID 連携のような領域など、複数のクラウドにわたる基礎的な一貫性が必要な他の側面も検討してみましょう。
Google Cloud を基盤として使用する。組織が自ら判断を下す必要がある、基本的な問題があります。それは、オンプレミスのテクノロジーと手法をクラウドに持ち込むのか、それともクラウドのテクノロジーと手法をオンプレミスに持ち込むのかということです。Google は、後者を選ぶべきであると心から信じています。マルチクラウドがクラウドの問題である以上、その取り組みもまたクラウドに根差しているべきです。Google が提供する Anthos は、Google Cloud とその他のクラウドにまたがる分散 Kubernetes フリートを構築および運用する手段です。オンプレミスのバックプレーンの代わりにクラウドベースのバックプレーンを使用することで、チームの負担を軽減できるうえ、スケーリングやセキュリティのマネージド サービスを活用したり、最新の手法をチームに導入したりすることも可能になります。
今回のディスカッションを通して、私たちはマルチクラウドについて多くを学ぶことができました。読者の皆さんもおそらくそうでしょう。そこで、この話題をさらに深く掘り下げるため、エキスパートの顔触れを一新して再度ディスカッションを行うことを予定しています。今後の情報にご注目ください。
-アウトバウンド プロダクト管理担当ディレクター Richard Seroter
