マルチクラウド導入における5つの課題とその解決方法

F5

最近では、技術ブログを読めば、マルチクラウドアーキテクチャを称賛する記事を目にしないことはほとんどありません。それには十分な理由があります。マルチクラウドには、コスト削減や信頼性の向上をはじめ、さまざまなメリットがあるためです。

しかし、マルチクラウド戦略には課題もあり、特にアプリケーションのデプロイは大きな課題です。マルチクラウドを安易に導入する前に、マルチクラウドアーキテクチャがデプロイ戦略に与える影響を評価し、そうした課題に対処する準備が整っていることを確認することが重要です。

この記事では、マルチクラウド環境における一般的なデプロイの課題と、その軽減に役立つヒントを紹介します。

課題1：プロビジョニング

複数のクラウドにアプリケーションをデプロイするには、事前に複数の環境をプロビジョニングする必要があります。

Infrastructure-as-Code（IaC）ツールは、このプロセスの効率化にある程度役立ちます。1つのIaCテンプレートを使用して、複数のクラウドを同じ方法でプロビジョニングできます。

ただし、この課題に対してIaCが支援できる範囲には限界があります。特定のクラウドベンダーが提供するIaCツールを使用する場合、他のクラウドとの互換性がほとんど、またはまったくない可能性があります。そのため、クラウドごとに異なるIaCツールが必要となり、IaCを使用する意義が一部損なわれることがあります。また、すべてのクラウドに対応するIaCツールがあったとしても、各クラウドでまったく同じテンプレートを使用することはできないため、構成を手動で調整しなければならない可能性があります。

IaCではマルチクラウドのプロビジョニングに関する課題を解決できない場合、基盤となるクラウドからワークロードを完全に抽象化するソリューションを使用する方が効果的です。これにより、クラウドごとに個別にプロビジョニングする必要がなくなります。

課題2：アプリケーションのデプロイ

プロビジョニングと同様に、複数のクラウドにインスタンスをデプロイする場合、アプリケーションの実際のデプロイプロセスが複雑になることがあります。クラウドごとに異なるデプロイプロセスが必要です。

サードパーティ製のリリース自動化ツールを使用して、利用する各クラウドにアプリケーションインスタンスを自動的にデプロイする方法もあります。これによりプロセスは簡素化されますが、IaCツールの場合と同様に、まったく同じ構成を各クラウドへのデプロイに使用することはできないため、手動での変更が必要になる可能性があります。

ここでも、ワークロードをホストするクラウドから抽象化し、複数のクラウドにわたって完全に一貫したデプロイプロセスを提供するソリューションは、マルチクラウドアーキテクチャにおけるデプロイの課題を軽減するうえで、リリース自動化ツールを上回る効果を発揮します。

課題3：負荷分散

複数のクラウドでアプリケーションの複数のインスタンスをホストする場合、各インスタンスが最適な量のトラフィックを処理していることをどのように確認すればよいでしょうか。一方のクラウドがアイドル状態のまま、もう一方のクラウドにトラフィックが集中しすぎるのを防ぐには、どうすればよいでしょうか。また、インスタンスを追加または削除すべきタイミングをどのように判断すればよいでしょうか。

これらは重要な問題です。マルチクラウドアーキテクチャ全体で負荷を適切に分散できなければ、パフォーマンスの問題やコストの無駄が生じる可能性があります。これは、マルチクラウドアーキテクチャが本来もたらすべき効果とは正反対です。

残念ながら、マルチクラウド環境では、これらの問いに答えるのは非常に困難です。クラウドベンダーは、他のプロバイダーのクラウドでも機能する負荷分散ソリューションを提供していないため、異なるクラウドやアプリケーションインスタンス間でトラフィックをどのように分散するかを判断するには、各クラウドを個別かつ慎重に監視する必要があります。

複数のクラウドに展開できる共通のネットワーキングおよび監視プラットフォームと、接続と負荷分散を自動化するApplication Delivery Networkを利用することで、こうした課題を回避し、マルチクラウド戦略が本来もたらすメリットを確実に享受できます。

課題4：エグレス

クラウドプロバイダーは貪欲です。ワークロードとデータを自社のクラウド内に永遠にとどめておきたいと考えています。データを外部に移動する、つまりデータエグレスを行うと、多額の料金が請求されます。

つまり、クラウド間でデータを頻繁に移動する必要があるマルチクラウドアーキテクチャでは、データ転送料金によってクラウドコンピューティングの利用料金が大幅に増加する可能性があります。

基本的な対策として、異なるクラウド間でデータを頻繁に移動する必要がないようにマルチクラウドアーキテクチャを設計することで、このリスクを軽減できます。たとえば、アプリケーションを配置するクラウドと、そのアプリケーションが取り込むデータをホストするクラウドを分けると、クラウド間で大量のデータ移動が必要になるため、このような構成は避けてください。

もう1つの有効な方法は、使用頻度の高いデータの一部を保存するApplication Delivery Networkを利用することです。Application Delivery Networkは、セキュリティとパフォーマンスに関するさまざまなメリットをもたらすだけでなく、あるクラウド上のアプリケーションが別のクラウドとの間でデータを移動する頻度を減らすことができます。代わりに、Application Delivery Network内のデータストアを利用できます。

課題5：監視

単一のクラウドで可視性を維持するだけでも容易ではありません。複数のクラウドが混在する環境では、稼働するすべてのサービスと構成を監視することは、極めて困難な作業になります。

マルチクラウド環境をサポートするよう設計されたアプリケーションパフォーマンス監視（APM）ツールは、この作業にある程度役立ちます。しかし、それだけでは十分ではありません。いずれかのアプリケーションで問題が発生していると思われる場合にはアラートが通知されますが、原因となっているクラウドを特定し、影響を受けている各クラウドに対応するツールを使用して問題を解決する必要があります。

別の方法として、基盤となる各クラウドからワークロードを抽象化し、1つの「論理クラウド」と1組のデプロイツールだけを監視できるようにすることもご検討ください。このアプローチにより、アプリケーションとインフラストラクチャの可視性を維持するために管理すべき構成要素を減らせます。

まとめ

マルチクラウドアーキテクチャにおけるアプリケーションデプロイの管理は、本質的に困難です。さまざまな自動化ツールを活用すれば、プロビジョニング、デプロイ、監視などのタスクを効率化できますが、手作業を完全になくすことはできません。

さまざまなツールでマルチクラウド展開の課題を解決しようとするよりも、マルチクラウドアーキテクチャ自体の設計方法を見直す方が効果的です。VoltMeshやVoltConsoleなどのソリューションを活用すれば、複数のクラウドにまたがるアプリケーションを一貫した方法で一元的に展開、接続できます。さらに、VolterraのグローバルなApplication Delivery Networkを活用して、ワークロードのパフォーマンスとセキュリティを最適化できます。

著者について

F5

F5のその他のブログ記事