マルチクラウド展開の 5 つの課題 (およびその解決方法)
最近では、技術ブログを読んでいると、マルチクラウド アーキテクチャを称賛する記事が必ず見つかります。 それには十分な理由があります。マルチクラウドは、コスト削減から信頼性の向上まで、さまざまなメリットをもたらします。
しかし、マルチクラウド戦略には、特にアプリケーションの展開に関していくつかの課題もあります。 マルチクラウドの流行に乗る前に、マルチクラウド アーキテクチャが展開戦略にどのような影響を与えるかを評価し、それらの問題点に対処する準備ができていることを確認することが重要です。
この記事では、マルチクラウド環境における一般的な展開の課題と、それを軽減するためのヒントを紹介します。
課題1: プロビジョニング
複数のクラウドがある場合は、アプリケーションをデプロイする前に複数の環境をプロビジョニングする必要があります。
ある程度、Infrastructure-as-Code (IaC) ツールは、このプロセスを効率化するのに役立ちます。 1 つの IaC テンプレートを使用して、同じ方法で複数のクラウドをプロビジョニングできます。
ただし、この課題に対して IaC がどれだけ役立つかには限界があります。 特定のクラウド ベンダーが提供する IaC ツールを使用する場合、他のクラウドとの互換性がほとんどないか、まったくない可能性があります。 したがって、クラウドごとに異なる IaC ツールを使用する必要があるかもしれませんが、これは IaC の目的を部分的に無効にします。すべてのクラウドで機能する IaC ツールがある場合でも、各クラウドにまったく同じテンプレートを使用することはできないため、手動で構成を微調整する必要がある可能性があります。
IaC でマルチクラウド プロビジョニングの課題を解決できない場合は、基盤となるクラウドからワークロードを完全に抽象化するソリューションを使用する方がよいでしょう。 そうすれば、各クラウドを個別にプロビジョニングする必要がなくなります。
チャレンジ2: アプリケーションの展開
プロビジョニングと同様に、インスタンスを複数のクラウドにデプロイする場合、実際にアプリをデプロイするプロセスは複雑になる可能性があります。 クラウドごとに異なる展開プロセスが必要になります。
サードパーティのリリース自動化ツールを使用して、使用する各クラウドにアプリケーション インスタンスを自動的にデプロイすることもできます。 これによりプロセスは簡素化されますが、IaC ツールの場合と同様に、各クラウドにデプロイする際にまったく同じ構成を使用することはできないため、手動で変更を加える必要がある可能性があります。
ここでも、ワークロードをホストするクラウドから抽象化し、複数のクラウドにわたって完全に一貫したデプロイメント プロセスを提供するソリューションは、リリース自動化ツールよりもさらに進んで、マルチクラウド アーキテクチャのデプロイメントの課題を軽減します。
課題3: 負荷分散
複数のクラウド上でアプリケーションの複数のインスタンスをホストする場合、それぞれのインスタンスが理想的な量のトラフィックを処理していることをどのように確認しますか? 一方のクラウドがアイドル状態になっている間に、もう一方のクラウドに過剰なトラフィックが送信されるのを回避するにはどうすればよいでしょうか? インスタンスを追加または削除する必要があるかどうかはどのようにしてわかりますか?
これらは重要な質問です。 マルチクラウド アーキテクチャ全体で負荷を適切に分散できない場合、パフォーマンスの問題が発生し、お金が無駄になる可能性があります。これは、マルチクラウド アーキテクチャが提供すべきものとは正反対の結果です。
残念ながら、マルチクラウド環境ではこれらの質問に答えるのは非常に困難です。 クラウド ベンダー自体は他のプロバイダーのクラウドと連携する負荷分散ソリューションを提供していないため、異なるクラウドとアプリケーション インスタンス間のトラフィックのバランスをとる方法を決定するには、各クラウドを個別に注意深く監視する必要があります。
複数のクラウドに展開できる共通のネットワークおよび監視プラットフォームと、自動的に接続して負荷を分散するアプリケーション配信ネットワークを使用することで、これらの課題を回避し、マルチクラウド戦略が提供するはずのメリットを実際に享受できるようになります。
課題4: 退出
クラウドプロバイダーは貪欲です。 彼らは、あなたのワークロードとデータが永久にクラウド内に留まることを望んでいます。 データを移動する、つまりデータ送信を実行すると、かなりの料金が請求されます。
つまり、あるクラウドから別のクラウドにデータを頻繁に移動する必要があるマルチクラウド アーキテクチャでは、送信料金によりクラウド コンピューティングの料金が大幅に増加する可能性があります。
基本的なレベルでは、異なるクラウド間でデータを頻繁に移動する必要がないようにマルチクラウド アーキテクチャを設計することで、このリスクを軽減できます。 たとえば、アプリケーションが 1 つのクラウドに存在しているが、取り込む必要があるデータは別のクラウドでホストされているような状況は避けてください。このような状況では、クラウド間のデータ移動が大量に必要になります。
もう 1 つの役立つ戦略は、より頻繁に使用されるデータの一部を保存するアプリケーション配信ネットワークを使用することです。 アプリケーション配信ネットワークは、セキュリティとパフォーマンスに関するさまざまな利点を提供するだけでなく、あるクラウド内のアプリケーションが別のクラウドとの間でデータを移動する頻度を減らすことができます。 代わりに、アプリケーション配信ネットワーク内のデータ ストアを使用できます。
チャレンジ5: 監視
単一のクラウドへの可視性を維持するだけでも大変です。 複数のクラウドが混在している場合、稼働中のすべてのサービスと構成を監視することは、非常に膨大な作業になります。
マルチクラウド環境をサポートするように設計されたアプリケーション パフォーマンス モニタリング (APM) ツールは、このタスクに多少役立ちます。 しかし、それらはあなたをある程度までしか連れて行ってくれません。 アプリケーションの 1 つで問題が発生していると思われる場合は警告が表示されますが、どのクラウドが問題の原因であるかを特定し、影響を受ける各クラウドに関連付けられたツールを使用して問題を解決するのはユーザーの責任となります。
あるいは、基盤となるクラウドからワークロードを抽象化して、1 つの「論理クラウド」と 1 セットのデプロイメント ツールのみを監視できるようにすることも検討してください。 このアプローチにより、アプリケーションとインフラストラクチャの可視性を維持するために対処する必要がある可動部分の数が削減されます。
結論
マルチクラウド アーキテクチャでのアプリケーション展開の管理は、本質的に困難です。 さまざまな種類の自動化ツールは、プロビジョニング、展開、監視などのタスクを効率化するのに役立ちますが、手作業の必要性を完全に排除できるわけではありません。
さまざまなツールを使用してマルチクラウド展開の課題を解決しようとするのではなく、マルチクラウド アーキテクチャ自体の設計方法を変更する方が優れたアプローチです。 VoltMeshやVoltConsoleなどのソリューションを利用することで、複数のクラウドにわたってアプリケーションを一貫性のある集中的な方法で展開および接続できると同時に、Volterra のグローバル アプリケーション配信ネットワークを活用してワークロードのパフォーマンスとセキュリティを最適化できます。