企業は本当にマルチクラウドの準備ができているのでしょうか?

大企業のほとんどは複数のクラウドを使用しており、すべての開発、データ サイエンス、シャドー IT 作業を単一のパブリック クラウドに集中させるために必要なガバナンスのレベルは高くなっています。グローバル企業や大企業が「マルチクラウド化」を戦略的に重要と認識している理由はいくつかあります。

1. マルチクラウドの複雑さを簡単に処理

IT リーダーは、安全で堅牢なクラウド インフラストラクチャを構築することの複雑さを十分に認識しています。当然、複数のクラウドを組み合わせると、これらの複雑さはさらに増大します。企業は、すべての問題に一度に取り組むことを避けるよう努めるべきです。

複数のクラウドにまたがる運用は、ガバナンス、技術的専門知識、および統合が必要となるため複雑です。

IT チームには、2 番目のプロバイダーで新しい機能やより優れた機能を探すのではなく、可能な限りプライマリ クラウド プロバイダーを活用することが推奨されます。パブリック クラウドには万能のアプローチは存在せず、1 つのプロバイダーではニーズの 40% ～ 60% しか満たせないことを受け入れてください。

他の IT リーダーは、マルチクラウドがどのように進化しているか、また初期の複雑さにどのように対処するかについて、実践的な見解を共有しました。ビッグデータ コンサルタントの Travis Campbell 氏は、マルチクラウドの使用について次のような見解を示しています。

ここでは、「マルチクラウド」を実施しながらも、実際には事業部門ごとに単一のクラウドとして扱っている企業が特別なケースとなります。たとえば、財務部門は Cloud X にアプリケーションを置いている一方で、エンジニアリング部門は Cloud Y にデプロイしており、作業とデータが重複することはありません。難しい問題もなく曇り空です。

したがって、すでにさまざまな目的で複数のクラウドを個別に運用している企業にとって、次のステップはこれらのクラウド間でのアプリケーション統合、データ統合、またはサービス オーケストレーションになります。ここから困難が始まります。ゆっくり慎重に進めるのが最善です。

2. マルチクラウドアーキテクチャのメリットを主張する

他のITリーダーも同様の意見を表明した。多くの人が、今日のマルチクラウドのサポートは容易ではなく、IT リーダーはマルチクラウド アーキテクチャを承認する前に強力なビジネス上の根拠を特定する必要があると指摘しました。

Edgevana の CEO 兼創設者である Mark Thiele 氏が、マルチクラウド アーキテクチャから得られる多くの戦略的メリットについて説明します。 「価格、市場投入までのスピード、独自の技術的機能、価値の向上、イノベーション、パフォーマンスの向上など、1 つ以上の重要な価値を顧客に提供できる場合は、マルチクラウドを使用します。」

Palo Alto Strategy Group のエグゼクティブテクノロジスト、Mike D. Kail 氏も同意しています。 「マルチクラウドを検討する主な理由は、クラウド サービス プロバイダーが、最初の導入時に使用されていたサービスよりも大幅に優れたサービスを提供している場合です」と彼は述べています。 「人工知能と機械学習のための TensorFlow はその一例です。」

以下に手順を示します。

多くの企業は 1 つのプラットフォームを主な焦点として選択しますが、ビジネス上のメリットに応じて特定のニーズとソリューションに対応する企業もあります。 IT リーダーは、戦略、サポート、プロセスの観点から、マルチクラウドへのアプローチ方法を定義する必要があります。他のプラットフォームが導入される場合でも、そのアプローチに一貫性を持たせるためのフレームワークと構造が存在します。 「クラウドの無秩序な拡大」が原因では必ず災害につながるので、そうならないようにしてください。

HPE の金融サービス担当チーフテクノロジスト、クリス・イビットソン氏は、企業はパブリッククラウドとプライベートクラウドの両方で俊敏性を求めていると語った。 「パブリック クラウド プロバイダーと提携する場合でも、ハイブリッド クラウド モデルを採用する場合でも、プライベート クラウド機能と複数のパブリック クラウド プロバイダーを組み合わせて活用することで、俊敏性と変化のスピードを実現できます。ほとんどの企業がすでに何らかの形でハイブリッド クラウドを導入していますが、現在はマルチクラウドに重点が移っています。」

その結果、IT 部門は特定のビジネスまたは技術ニーズをサポートするために、2 番目のクラウド サービス プロバイダーを導入する場合があります。このような場合、IT リーダーは、各クラウドがどのビジネスとユースケースに対応するか、また各クラウドが提供するサービスとテクノロジーは何かを定義する必要があります。

もちろん、他にもいくつか理由があります。

• 大企業は、特に企業固有のサービス レベルと価格を交渉したいと考えているため、単一のクラウド サービス プロバイダーへの依存を避けようとします。
• データ主権とコンプライアンスでは、多くの場合、データを居住国に保存すること、暗号化とデータ セキュリティに関する特定の要件、さらには許容されるクラウド サービス プロバイダーに関する特定の要件が求められます。
• M&A を希望する企業は、サポート構造を簡素化するために、複数のクラウド サービス プロバイダーとサポート モデルをターゲットにすることがよくあります。
• IT には、特に大規模に展開する場合に特定の技術的機能が必要であり、あるクラウド サービス プロバイダーに展開すると、他のプロバイダーよりも戦略的なビジネス上の利点が得られる可能性があります。
• IT 部門がパブリック クラウド上で実行される市販のアプリケーションを自己管理することを選択した場合、パブリック クラウドとは異なる開発標準を採用することになります。業界固有のアプリケーションやその他のニッチなアプリケーションは、単一のクラウド サービス プロバイダー上で構造とサポート モデルを提供できます。

ハイブリッドおよびマルチクラウド アーキテクチャは、特にエッジ コンピューティング、安全なアプリケーション、リアルタイム分析の面で技術的な利点も提供します。

3. マルチクラウドを使用する前にクラウドサポートモデルを確認する

企業がマルチクラウド アーキテクチャをサポートする理由はいくつかありますが、IT リーダーは財務分析を実行し、クラウド運用モデルを見直すことを強くお勧めします。

企業は、次のような質問を自問してみるとよいでしょう。「マルチクラウド アーキテクチャの導入と運用の複雑さよりもメリットの方が大きいでしょうか。短期的および長期的な財務上の影響はありますか。」

Nutanix のカスタマーサクセス担当財務副社長の Steven Kaplan 氏も同意しています。彼は次のようにアドバイスしています。「あらゆる重要な IT 決定と同様に、最も戦略的に意味のある最善のソリューションを選択するだけでなく、次のステップの根拠と財務ベンチマークを提供するためにも、徹底的な財務分析を実施する必要があります。」

正当な理由がある場合、IT 部門はサービス モデルと専門知識を単一のクラウドから複数のクラウドに拡張することを検討する必要があります。フェザーストン氏は、クラウド コンピューティングはテクノロジーよりも、人、プロセス、文化に関係するものであると指摘しました。 「企業はまず1つのプラットフォームの基盤を築き、他のプラットフォームで成長するためのフレームワークを提供することで、組織内のこうした大きな変化を乗り越えるよう努めるべきだ」と同氏は述べた。 「基本的には、雲を所定の位置に置き、そこから外側に向かって作業を進めていきます。」

コード ツールとしてのインフラストラクチャから始めることをお勧めします。これらは何らかの形のインフラストラクチャの自動化と構成をサポートしており、クラウド ガバナンスの全範囲に対応しているわけではありませんが、プログラム可能でバージョン管理されたインフラストラクチャを備えることが重要です。

4. マルチクラウドアーキテクチャをサポートするためにDevOpsを採用する

堅牢な devsecops プラクティス、特にアプリケーションのデプロイのための CI/CD、インフラストラクチャのプロビジョニングと構成のための Infrastructure as Code、AIops を含む監視機能は、マルチクラウド アーキテクチャの実装とサポートの両方に不可欠です。

ただし、すべての DevOps テクノロジーや DevOps プラクティスが通用するわけではありません。一部のテクノロジーは、他のテクノロジーよりもマルチクラウド戦略に適しています。 1 つのアプローチは、AWS CloudFormation、Azure Resource Manager、Google Cloud Deployment Manager などのクラウド サービス プロバイダーの独自ツール (マルチクラウド サポートを提供しているものも含む) を避けることです。企業の IT チームは、デプロイメントの頻度に重点を置く DevOps 文化を、デプロイメントの俊敏性も含めたものに拡張する必要もあります。

インフラストラクチャ・アズ・コードは、構成のドリフトを軽減するための必須条件である必要があり、セキュリティは最初から設計する必要があります。 Terraform のようなツールは確かに役立ちますが、複数のクラウドにまたがるセキュリティ ソリューションも重要です。

多くの IT リーダーは、宣言型、エージェントレス、マスターレスの構成ツールである Terraform をマルチクラウド アーキテクチャに推奨しています。推奨されるアーキテクチャでは、Terraform と Packer、Docker、Kubernetes を組み合わせて、構成、サーバー テンプレート、オーケストレーションをサポートします。

ただし、マルチクラウド対応ツールを選択しても、実装がマルチクラウド対応になるわけではありません。 Featherston は Terraform を推奨していますが、免責事項があります。 「私が注意したいのは、AWS は複数のプラットフォームで使用されている共通言語であるが、AWS を構築するコードは Azure を構築するコードではないということを顧客に理解してもらうことです」と同氏は説明した。 「チームが共通の言語でコーディングできるという利点がありますが、トレードオフとして、すべてのプラットフォーム機能が利用できない可能性があります。」

マルチクラウドのニーズを満たすには、コードとしてのインフラストラクチャに加えて、次のツール、プラクティス、ガバナンスが推奨されます。

• アプリケーションと個々の仮想マシンの自動化とオーケストレーション
• アイデンティティ管理やデータ保護/暗号化などのセキュリティ
• 監査とSLAメトリックを含むポリシーガバナンスとコンプライアンス
• インフラストラクチャ（コンピューティングインスタンス、ストレージ、ネットワークなど）とアプリケーションのパフォーマンス監視
• リソースの最適化と請求額の見積りによるコスト管理

5. マルチクラウドの未来に備える

今日、複数のパブリック クラウドを導入するのは複雑ですが、ほとんどの企業がマルチクラウド アーキテクチャをサポートし、クラウド間でアプリケーションを統合するだろうというのが IT リーダーの共通認識です。歴史を振り返ると、企業は Linux と Windows、.NET と Java、Oracle と Microsoft SQL データベースなどをサポートする必要がありました。

今後 3 ～ 5 年でマルチクラウドが進化し、より多くのワークロードがデフォルトで基盤となるクラウド プロバイダーから設計および抽象化されるようになると予想されます。人工知能、機械学習、分析など、さまざまなクラウド プロバイダーが実現できる高度な機能に重点が置かれます。

マルチクラウド アーキテクチャは維持が難しく、コストもかかります。企業は、単一のクラウド プロバイダーに対しては戦略的に、マルチクラウド運用に対しては戦術的に対応する必要があります。また、インフラストラクチャ層で同じワークロードに対して複数のクラウドを実行することは絶対に避けてください。

一度構築すればどこでも実行できるというのは、私たち全員が目指していることであり、マルチクラウドの成功にはまだまだ希望が残っています。