ハイブリッド クラウドの実現: F5、Azure、Azure Stack

今日では、多くの IT 部門は、従来の静的な社内データ センターから、より動的なクラウド中心のアーキテクチャに移行し、俊敏性、柔軟性、拡張性を高めながら運用コストを削減するよう、リーダーシップ グループからプレッシャーを受けています。 パブリッククラウドとプライベートクラウドにはそれぞれ長所と短所があるため、約71%¹企業の多くは、多くのデメリットを相殺しながら、より多くのメリットを享受するためにハイブリッド モデルを導入しています。 しかし、これらの組織のほとんどは、非同種のクラウド インフラストラクチャとapplicationサービスを採用しているため、これらの展開の設計と保守を担当する部門横断的なチームの複雑さが大幅に増大します。

2 つ (またはそれ以上) の異なるクラウド環境をリンクしてハイブリッド クラウドを構築すると、俊敏性、柔軟性、拡張性の観点からメリットがあるだけでなく、実装がはるかに困難 (または不可能) なさまざまな特殊なユース ケースも実現できるようになります。 おそらく最も一般的なものは次のとおりです。

重要なapplicationsのダウンタイムを防ぐために、プライベート クラウドの可用性が高く、地理的に冗長化されたバックアップを確立して維持することは非常にコストがかかり、単一のプライベート クラウドを実行するために必要な投資の 2 倍になる可能性があります。 物理的なハードウェアが 2 倍必要になるだけでなく、地理的に離れた場所に、独自の電源、冷却装置、人員を備えた別のデータ センターが必要になります。

あるいは、HA 環境と DR 環境を、わずかなコストでパブリック クラウドに収容することもできます。 applicationデータはプライベート クラウドからバックアップされるたびに保存されますが、実際のapplicationとネットワーク リソースは、災害やプライベート クラウドの障害など、必要になるまで休止状態になります。 必要に応じて、これらのapplicationsとリソースは保存されたデータを使用して起動および運用され、applicationの可用性とビジネスの継続性が確保されます。

プライベート クラウドで新しいapplicationを開発すると、パブリック クラウドよりも大幅にコストがかかる可能性があります。 ワークロードを実行するには先行の資本投資が必要であり、それが現在の市場で機能するか採用されるかは保証されません。 これらの理由から、企業は「失敗は早く、失敗は安く」というモットーに従い、パブリック クラウドのオンデマンド容量を使用して、新しいアプリを本番環境で開発、テスト、実行しています。 運用上健全であると判断されたり、ユーザーに広く採用されたりしたら、アプリをプライベート クラウドに移行できます。長期的には、より安全で運用コストも低くなる可能性があります。 あるいは、パブリック クラウドにとどまり、より安価な予約インスタンスなどを使用して、より長期的かつコスト効率の高い環境に展開することもできます。

クラウド バーストは、最も望ましいハイブリッド クラウド機能とみなされることも多いですが、実際に実装するのはおそらく最も難しく、多くのハイブリッド クラウド戦略の目玉となることがよくあります。 クラウド バーストでは、applicationは主にプライベート クラウドで実行されます。 需要が容量を超えると、追加のリクエストは、レンタルされたインフラストラクチャ上のパブリック クラウドで実行されている正確なレプリカにリダイレクトされます。 ただし、これは一時的な状態であり、短期間に発生する予期しないトラフィックの急増に対処するために設計されています。 トラフィック量が多い期間が続くようになると、企業はプライベート クラウドの容量を拡大できます。

クラウド バースト用のハイブリッド クラウド環境を構成することは、本質的に困難で複雑です。 2 つの環境間の相乗関係と、エンド ユーザーのエクスペリエンスにほとんど影響を与えずにリダイレクトが自律的かつシームレスに行われるようにするためのフェイルセーフ オーケストレーションが必要です。 applicationsの実行とサポートに使用されるインフラストラクチャ、サービス、ツールが環境ごとに異なる場合、構成と管理を担当するチームにとって困難はさらに増大します。

すべての雲が同じではないと知っても、驚くべきことではありません。 それぞれ独自のインフラストラクチャ、ネットワークおよびapplicationサービス、開発者ツール、ユーザー インターフェイスを備えており、他のクラウド競合製品との差別化を図っています。 たとえば、Sharepoint、Exchange、SQL Server、またはその他の Microsoft テクノロジのユーザーにとっては、AWS や Google Cloud に移転するよりも、Microsoft Azure に移行する方がはるかに簡単です。 これらのプラットフォームとサービスの相違により、クラウド間の非互換性が生じ、ハイブリッド クラウド環境の開発作業が非常に困難になります。

ただし、Microsoft は、Azure と Azure Stack を通じてパブリック クラウド環境とプライベート クラウド環境の両方で同義のリソースとサービスを提供することで、ハイブリッド クラウドの作成をサポートする方向に大きく進歩しました。 最近発表されたばかりの Azure Stack は、社内データ センターの制御とセキュリティを備え、パブリック クラウドの多くの機能と利点をユーザーに提供します。

3 つの一般的な高レベルのハイブリッド クラウド モデルを比較し、この新しいアプローチを F5 の高度なapplicationサービスと組み合わせることで、ハイブリッド クラウドの開発と運用が大幅に簡素化されることを示します。

モデル 1 – 非均質クラウド プラットフォームとapplicationサービス

最初の例は、図 1 に示すように、パブリック クラウドの側面に Azure と Azure ネイティブapplicationサービスを使用し、プライベート クラウド コンポーネントに VMware と F5applicationサービスを活用するハイブリッド クラウド環境です。

環境間での一貫性が明らかに欠如しているため、このモデルは実装と運用が最も困難です。 前述の HA/DR の使用例では、applicationを各クラウドで同じように実行するように個別に構成する必要があります。 仮想マシン、API、基盤となるネットワーク リソースの違いを考慮すると、これは簡単な作業ではないと思われます。 これらの違いにより、各クラウドでアプリを運用するために必要な複雑な配管により、applicationの全体的な移植性が低下し、同様の結果を達成するために必要な作業が実質的に 2 倍になります。 さらに、各プラットフォームには独自のポータル インターフェイスと開発者/管理者ツールもあるため、このモデルはすぐに非常に複雑になります。

これはプラットフォームの違いを考慮しただけのことです。 異なるインターフェース、管理ツール、構成要件を持つ異なるapplicationサービスの影響が加わると、複雑さは飛躍的に増大します。 管理機能の不備だけが問題ではありません。機能の不一致により、applicationsを各クラウドで同じサービスで構成することができなくなり、さらなるリスクにさらされることになります。 たとえば、セキュリティ サービスが異なると、ファイアウォールのルールセットとポリシーも別々になります。 これにより、セキュリティ上の抜け穴が生じ、その後のサイバー攻撃の結果としてapplicationのダウンタイムや顧客データの損失が発生する可能性があります。

モデル 2 – 同種のapplicationサービスを備えた非同種のクラウド プラットフォーム

このセットアップはモデル 1 のセットアップと似ていますが、図 2 に示すように、各クラウド環境は F5applicationサービスによってサポートされます。

一貫したapplicationサービスにより、F5 のすべてのサービス、構成、ポリシーを単一の管理画面で環境全体に複製できるため、システム管理者の負担が軽減されます。 2 つの別個の機能、インターフェース、用語のセットを学習してバランスを取る代わりに、標準化された機能豊富なサービスのセットを 1 つ、ハイブリッド クラウド環境全体に展開できます。 また、これらのサービスはクラウドに依存しない (つまり、すべてのクラウドで同じように実行される) ため、クラウド ネイティブ サービスの使用に伴う可能性のあるベンダー ロックインの懸念がなくなります。 ただし、このモデルでは、異なるプラットフォーム インフラストラクチャに関連する問題には対処していないため、これを考慮する必要があります。

モデル 3 – 同種のクラウド プラットフォームとapplicationサービス

この最終モデルでは、図 3 に示すように、モデル 2 で説明した構成を採用し、VMware プライベート クラウドを Microsoft Azure Stack に置き換えることで、さらなる段階的な改善が図られます。