マルチクラウド ネットワーキング戦略でクラウドの進化を乗り切る
マルチクラウド ネットワーキングは本当に魔法なのでしょうか?
急速に進化するクラウド コンピューティングの分野では、マルチクラウド ネットワーキングへの関心が再び高まっています。 これまで包括的なマルチクラウド ソリューションを提供していなかったベンダーによる最近の買収は、マルチクラウドの複雑さに対処するための合理化されたソリューションに対する顧客の需要の高まりを強調しています。
しかし、この復活のなか、市場の多くのプレーヤーの試みはいくぶん近視眼的であり、顧客が直面している複雑さを軽減する本当の機会を逃していることがますます明らかになっています。
ネットワークは基本的なものですが、制限があります
クラウド コンピューティングが進化し続けるにつれて、マルチクラウド ネットワーキングがエンタープライズ テクノロジーの検討事項の最前線に浮上しています。 従来のデータ センターを超えてリモート エッジ施設や物理的なブランチ オフィスにまでコンピューティング機能が拡大したことで、物理環境とクラウド環境の間に新たなパラダイムが生まれています。 コンテナ化、マイクロサービス、 APIの登場により、アプリケーションはますます分散化され、動的になり、従来のネットワーク アーキテクチャに新たな課題が生じています。 これらのアプリケーションは、大規模なサーバー ファームの必要性による制約を受けずに、高度に分散した場所に展開できるようになりました。
現在利用可能なマルチクラウド ネットワーキング ソリューションの大部分は、主にネットワーク トランスポート層に重点を置いています。 現在知られているネットワークはアプリケーションを認識しません。それはネットワークの本来の目的ではありません。 さらに、ネットワークは主にサイト間 (南北) 接続用に設計されており、単一のクラウドまたは物理サイト内のクラスターを超えて拡張される東西アプリ サービス接続の増加をサポートするようには設計されていません。 このため、企業が大規模な合併や買収を行うと、ネットワーク ルーティング テーブルに保存されている異なる IP アドレスが同じインフラストラクチャを共有する必要があり、必然的にIP の重複という課題に直面し、運用の複雑さが増すという問題が発生します。
従来のネットワークは「ダムパイプ」とみなされることが多く、運用上の大きなオーバーヘッドと非効率性を生み出し、非常に機敏な組織の開発チームの妨げとなります。 多くの人はネットワークから始めてこれらの問題を解決しようとしますが、このアプローチの欠点に気付くだけです。
Kubernetes のジレンマ
Kubernetes は、これらの分散コンテナ化されたエコシステムを調整し、大規模な俊敏性とスケーラビリティを実現するための重要なツールとして登場しました。 Kubernetes は、もともと Google によって開発されたオープンソースのコンテナ オーケストレーション プラットフォームであり、コンテナ化されたアプリケーションの展開と管理の事実上の標準として急速に採用されてきました。
Kubernetes は、コンテナ化されたアプリケーションの展開、スケーリング、管理を自動化するためのプラットフォームを提供します。 Kubernetes は、基盤となるインフラストラクチャを抽象化することで、開発者がインフラストラクチャ リソースの管理の複雑さに煩わされることなく、アプリケーションの構築とデプロイに集中できるようにします。 ただし、Kubernetes 自体 (少なくともオープンソースの形式では) には、ある程度の複雑さが伴います。 そのため、複雑さの一部を抽象化することを目的とした商用ディストリビューションが普及しています。
しかし、これで私たちは出発点に戻ります。 最も広く市販されているディストリビューションの 1 つである Red Hat OpenShift を例に挙げてみましょう。 OpenShift は、主にオンプレミスのデータセンターを中心に、エンタープライズ環境に広く導入されています。 これらの企業は、 AWSなどのクラウドにもサービス クラスターを展開しており、Amazon Elastic Kubernetes Service (EKS) を使用して、サービスを Red Hat OpenShift on AWS (ROSA) に統合したいと考えている可能性が高くなります。 統合できるように設計されていない個別のツール環境 — マルチクラウドの問題が再び頭をもたげています。
クラウド ネットワークのセキュリティ ギャップ
現在市場で入手可能なすべてのマルチクラウド ネットワーキング ソリューションは、高度なセグメンテーションからネイティブ ネットワーク ファイアウォール、サービス挿入機能まで、ある程度の固有のセキュリティをもたらします。 しかし、ここでも、アプリケーションの推進要因が欠けています。 これらのソリューションでは、複数のクラウドおよびエッジ サイトにまたがる分散アプリケーション サービスや API エンドポイントを侵害するビジネス ロジック攻撃を利用する悪意のある脅威に対応できません。 ネットワークは安全でありながら、サービス提供先のアプリケーションは攻撃に対して脆弱なままです。 企業は、分散ハイブリッドおよびマルチクラウド アプリケーション カタログ全体が保護されるように、複数のポイント セキュリティ ソリューションを導入し、セキュリティ チームによる膨大な量のガバナンスを適用する必要があります。
安全なマルチクラウド ネットワーキングの実現に向けて
ビデオ抜粋: Kyndryl と F5 による安全なマルチクラウド ネットワーキングの定義
先見性のある企業は課題に立ち向かい、状況を変えつつあります。 たとえば、 McGraw Hill を例に挙げてみましょう。 重要なアプリケーションをクラウドに移行する緊急の必要性に直面した McGraw Hill は、アプリケーションのニーズとセキュリティ要件を優先し、厳しい要求を満たすためにF5 Distributed Cloud Services を選択しました。 F5 を使用すると、オンプレミス ネットワークをあらゆるクラウド環境にシームレスに拡張し、あらゆるクラウドで一貫したアプリケーション レベルのセキュリティを確保できます。
同様に、スコットランド政府の農業および農村経済 (ARE) 局は、最新のアプリケーション アーキテクチャに対処するための新しいパラダイムの必要性を認識しました。 分散クラウド サービスを活用することで、マルチクラウド環境の柔軟性と俊敏性を実現し、OpenShift と EKS 間でワークロードを簡単に転送できます。 インフラストラクチャ責任者のニール・スミス氏は次のように述べています。「マルチクラウド環境は今後も存続するでしょう。 F5 を利用することで、この移行をサポートする完全なサービスとソリューションを備えたコンテナ化された Kubernetes 環境に移行し、そのメリットを活用できるようになります。」
これらの成功事例は、マルチクラウド ネットワーキングに対するアプリケーション中心かつセキュリティ重視のアプローチへの移行を例示しています。 アプリケーションのニーズとセキュリティ要件を優先しながら、既存の基盤となるネットワーク インフラストラクチャを補完することで、企業はマルチクラウド環境の複雑さに自信を持って効率的に対応できます。 「魔法」ではなく、安全なマルチクラウド ネットワーキングは、最新のアプリケーション アーキテクチャに基づいて構築された組織がその力を活用して、デジタル時代のイノベーションと成功を推進するのに役立ちます。