マルチクラウドネットワーキングは本当に魔法なのか？
急速に進化するクラウドコンピューティングの分野で、マルチクラウドネットワーキングへの関心が再び高まっています。これまで包括的なマルチクラウドソリューションを提供していなかったベンダーによる最近の買収は、マルチクラウドの複雑さへの対応を支援する、合理化されたソリューションに対するお客さまの需要が高まっていることを示しています。
しかし、こうした関心の再燃の一方で、市場の多くのプレイヤーによる取り組みはやや近視眼的であり、お客さまが直面する複雑さを軽減する真の機会を逃していることが、ますます明らかになっています。
ネットワークは基盤だが、限界がある
クラウドコンピューティングが進化を続ける中、マルチクラウドネットワーキングは今や、企業がテクノロジーを検討するうえで最重要課題の1つとなりつつあります。従来のデータセンターの枠を超えたコンピューティング機能がリモートエッジ施設や物理的な支社・支店にまで広がったことで、物理環境とクラウド環境の関係には新たなパラダイムが求められています。さらに、コンテナ化、マイクロサービス、APIの登場により、アプリケーションの分散化と動的な変化が進み、従来のネットワークアーキテクチャに新たな課題が生じています。現在では、大規模なサーバーファームを必要とせず、高度に分散した拠点全体にアプリケーションを展開できます。
現在提供されているマルチクラウドネットワーキングソリューションの大半は、主にネットワークトランスポート層に重点を置いています。現在のネットワークはアプリケーションを認識しません。そもそも、そのような目的で設計されていないためです。また、ネットワークは主にサイト間（南北方向）の接続を想定して設計されており、単一のクラウドまたは物理サイト内のクラスターを越えて拡大する、アプリケーションサービス間の東西方向の接続には対応できません。そのため、企業が大規模な合併や買収を行い、ネットワークルーティングテーブルに保存された異なるIPアドレスを同じインフラストラクチャで使用する必要が生じると、必然的にIPアドレスの重複という問題に直面し、運用の複雑さが増します。
従来型ネットワークは、単なる「ダムパイプ」と見なされることが多く、運用上の大きな負担と非効率性を生み出し、俊敏性の高い組織の開発チームを妨げています。多くの企業は、まずネットワークからこうした問題を解決しようとしますが、やがてこのアプローチの限界に直面します。
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）局は、最新のアプリケーションアーキテクチャに対応するには、新たなパラダイムが必要だと認識しました。Distributed Cloud Servicesを活用することで、AREはOpenShiftとEKSの間でワークロードを容易に移行し、マルチクラウド環境の柔軟性と俊敏性を取り入れました。インフラストラクチャ責任者のNeil Smith氏は、次のように述べています。「マルチクラウド環境は今後も定着していくでしょう。F5を活用すれば、方向転換を図り、この移行を支える包括的なサービスとソリューションを備えた、コンテナ化されたKubernetes環境のメリットを生かすことができます」
これらの成功事例は、マルチクラウドネットワーキングが、アプリケーションを中心に据え、セキュリティを重視するアプローチへと移行していることを示しています。既存の基盤ネットワークインフラを補完しながら、アプリケーションのニーズとセキュリティ要件を優先することで、企業は複雑なマルチクラウド環境にも確信を持って効率的に対応できます。「魔法」ではなく、セキュアなマルチクラウドネットワーキングこそが、最新のアプリケーションアーキテクチャを基盤とする組織によるその力の活用を支援し、デジタル時代のイノベーションと成功を後押しします。
著者について
関連するブログ記事
F5 Application Study Tool：OpenTelemetryによるF5 BIG-IP環境の監視
F5の新しいオープンソースツールは、BIG-IP環境を詳細に可視化し、データを追跡するとともに、強力でカスタマイズ可能なインサイトを得るための基盤を提供します。
F5 BIG-IPでAI防御を実現
F5 BIG-IP Advanced WAF、BIG-IP APM、BIG-IP SSL Orchestratorが、生成AIアプリ向けに包括的なセキュリティソリューションを提供する仕組みをご覧ください。
F5 Advanced WAFによるGraphQL APIの保護
ここ数年、多くの組織がデジタルトランスフォーメーションを進めており、COVID-19のパンデミックによってその動きは加速しています。
アプリケーションサービスの現状 通信業界版：リーダーとしての台頭
通信ネットワークが進化し、さまざまな業界の幅広いユースケースに対応するなか、通信業界の回答者がテクノロジーリーダーとしての存在感を高めていることがわかります。
デジタルトランスフォーメーションは、単なるペーパーレス化ではない
デジタルトランスフォーメーションは、単なるペーパーレス化ではありません。真のモダナイゼーションにアプリケーションアーキテクチャとセキュリティの再構築が必要な理由を、F5ブログでご覧ください。
やめましょう。もう本当にやめましょう。HTTPSはHTTPより高速ではありません。
もうやめましょう。HTTPSはHTTPより高速ではありません。プロトコルのパフォーマンスに関する微妙な違いと、暗号化トラフィックを適切に最適化する方法については、F5ブログをご覧ください。