クラウドバーストの一般的な課題を克服する

クラウド バーストは一部の人々の期待通りには普及していませんが、多くの企業は依然としてこのハイブリッド クラウド アーキテクチャの使用に熱心です。潜在的な課題を恐れない企業にとって、考慮すべき重要な要素がいくつかあります。

ほとんどの企業は、パブリック クラウド インフラストラクチャとプライベート クラウド インフラストラクチャを使用してアプリケーションをホストしています。調査によると、IT リーダーの 85% がハイブリッド クラウドが理想的な運用環境であると信じており、半数はハイブリッド クラウドですべてのニーズを満たすことができると回答しています。

ただし、「ハイブリッド クラウド」という用語は、単純なパッシブな災害復旧 (DR) 環境から、複雑で冗長なアクティブ/アクティブ アプリケーションまで、さまざまなシナリオをカバーします。後者（同時にアクティブで負荷分散されたパブリック クラウド環境とプライベート クラウド環境）は、システム アーキテクトが両方の長所を活用し、両方の欠点を最小限に抑えることができるため、かつては理想的なクラウド運用モデルと考えられていました。

[[322689]]

クラウドバーストの課題

「クラウドバースト」は、この両方の長所を活かすアプローチを表す用語になりました。このモデルでは、プライベート クラウド インフラストラクチャがベースライン リソース要件を処理し、機密性の高いレガシー データベースとバックエンド システムをホストします。パブリック クラウド インフラストラクチャは、季節的な負荷のピーク、一時的な発生、Web フロントエンド システムの水平拡張などの問題を解決します。

クラウドバーストの壮大なビジョンは、コストの最適化にまで及びます。 「マルチクラウド アービトラージ」と呼ばれる概念では、企業は複数の IaaS プロバイダーとリアルタイムのコスト分析ソフトウェアを活用し、特定の時間に特定のワークロードに対して最も安価なプロバイダーにバーストを直接割り当てます。

クラウドバーストの課題に取り組む価値があるのはいつでしょうか?

クラウド バーストには、高度な設計専門知識と展開計画が必要です。努力が価値があるかどうかは、各ワークロードの固有の特性とアプリケーションのビジネス価値によって決まります。

バースト モードは、容量要件が大幅に変化する収益を生み出すアプリケーションに最適です。この場合、オンプレミスのシステムはベースラインのリソース ニーズを満たすことができ、低コストのクラウドベースのスポット インスタンスは、需要が急増したときにこれらのシステムをサポートできます。

残念ながら、よくあることですが、この「エレガントな」理論は、マルチクラウド インフラストラクチャとアプリケーション設計の厄介な現実に直面しています。その結果、クラウド バースト アーキテクチャを導入したい企業は増えているものの、実際に導入できる企業はごくわずかです。実際、懐疑論者は、雲の破裂は主に神話であると主張している。コンサルティング会社 Architecting IT は最近、導入を妨げることが多い 4 つの大きな課題を特定しました。

• ネットワーキング。パブリック クラウドとプライベート クラウド間で低遅延、高帯域幅、冗長接続を確立し、着信接続を最適な場所に自動的にルーティングします。
• セキュリティ。複数の環境にわたってユーザーとシステムに対して一貫したポリシーと制御を展開します。
• データの一貫性、または特にトランザクション負荷が高い期間に複数のサイト間でデータ ストレージを同期する問題。
• データ保護。これは、複数のソースからバックアップが提供される場合に、バックアップの一貫性を維持するという関連する問題です。

5 番目の課題として、デプロイメントの自動化とリソースの動的なスケーリングを追加します。これは、パブリック クラウド (主にコンピューティング インスタンスまたはコンテナー インスタンスですが、ストレージ I/O も含まれます) が一時的な需要の急増を処理する能力に関するものです。

これらは解決可能ではあるものの複雑な問題であり、多くの企業は、少なくとも複数のクラウドで実行できる新世代の分散アプリケーション モデルが実現するまでは、クラウド バーストは労力に見合わないという結論に至っています。まだ動じていない組織のために、クラウド バーストの課題に対処する方法を以下に示します。

ネットワークとセキュリティ

ネットワークとセキュリティは、クラウド バーストを使用するかどうかに関係なく、あらゆるハイブリッド環境で対処する必要があるため、最も基本的なクラウド バーストの課題です。幸いなことに、IT チームは、主要なクラウド プロバイダー、通信事業者、ISP、ホスティング プロバイダーなど、この分野で最も幅広いテクノロジーとサービスにアクセスできます。現在、プライベート クラウドとパブリック クラウドをリンクしてハイブリッド クラウドの接続性を向上させる安全な方法がいくつかあります。

• 仮想プライベート クラウドは、標準の VPN プロトコル (通常は IPsec) と仮想ルーターを使用して、ローカル ネットワークをパブリック クラウド内の 1 つ以上のプライベート サブネットにリンクします。企業は、VPN を介して企業ネットワークをクラウド サブネットに拡張し、ルーター、NAT ゲートウェイ、インターネット ゲートウェイなどの仮想サービスを組み込むことでトラフィックを完全に制御できます。
• 専用回線 - クラウド プロバイダー サービス (AWS Direct Connect、Azure ExpressRoute、または Google、Oracle、IBM のサービスなど) を使用します。これらの製品は、顧客のプライベート クラウド ネットワークとパブリック クラウド ネットワーク間の専用の低遅延リンクを提供します。エンドポイントの場所の制限により、サービスは企業のデータセンターではなく、顧客のプライベートラックに接続できるコロケーションセンターで終了することがよくあります。
• 専用回線 - 通信会社、ISP、またはホスティング プロバイダーのサービスを使用します。これらはクラウドプロバイダーが提供するサービスに似ていますが、大手通信事業者との広範な相互接続を活用して、より多くの端末拠点を提供します。 AT&T NetBond や Equinix Cloud Exchange などのサービスも、すべての主要な IaaS および SaaS プロバイダーとインターフェイスするため、マルチクラウド相互接続の設計を簡素化します。

どちらのタイプの専用回線サービスでも、企業はネットワーク ルーティング、トラフィック管理、セキュリティ ポリシーを完全に制御できます。ただし、クラウド バーストの課題を克服するには、Direct Connect などのクラウド プロバイダー サービスが最適な選択肢です。これらのサービスは、クラウド プロバイダーのデータ センターで終了する光ファイバー回線に依存しているため、最高のパフォーマンスと最低の遅延を実現します。

データの一貫性と保護

クラウド ディザスタ リカバリの展開と同様に、クラウド バーストでは、オンプレミスからパブリック クラウド IaaS にアプリケーション コンポーネントを複製する必要があります。企業がクラウドに依存しないインフラストラクチャ・アズ・コード・システム（Terraform、Chef、Ansible、またはリソースと構成をプログラムでインスタンス化できる他のシステムなど）を完全に導入していない限り、企業は必要なインフラストラクチャ・リソースとネットワーク・トポロジを手動で構築する必要があります。デプロイされると、AWS CloudFormation や Google Cloud Deployment Manager などのクラウドプロバイダーのネイティブツールによって、他のクラウドリージョンのリソースを自動的にスケーリングまたは複製できるようになります。

企業は、アプリケーション アーキテクチャに応じて、さまざまな方法でデータ同期の問題に対処できます。

• データベースをオンプレミスに維持し、上記の専用回線を介して信頼性の高い高速ハイブリッド クラウド接続を確保します。この戦略は、負荷が増加するとフロントエンドとビジネス ロジック アプリケーション層が主なボトルネックになるため、レイテンシの影響を受けにくく、データベースに継続的にアクセスしないアプリケーションに適しています。
• 特にトランザクション データベースの負荷が大きいアプリケーションの場合、場所をまたいでデータベースを複製します。レプリケーションは本質的にデータの一貫性の問題を引き起こしますが、これらの問題は、Oracle や Microsoft SQL Server などのマルチサイト レプリケーションをサポートするデータベース システムによって解決されています。リアルタイムの一貫性を必要とするアプリケーションでは、Oracle RAC、GoldenGate、さまざまなサードパーティまたはオープンソース製品 (Qlik Replicate や SymmetricDS など) などのより高度なアプローチを使用する必要があります。

動的なリソース割り当て

ネットワーク プラミングとアプリケーション インフラストラクチャが確立されると、クラウド バーストの運用部分では、オンプレミス環境とクラウド環境の間でワークロードを動的に誘導してバランスをとることが必要になります。

ここで関係する主なツールは、ロード バランサ、アプリケーション配信コントローラ、仮想ネットワーク インターフェイスです。最新のロード バランサーには、予期しない状況に対応するための負荷重み付け係数、リソース/CPU 制限、フォールバック構成を指定するための十分な構成オプションがあります。 AWS Elastic Load Balancing、Google Cloud Load Balancer、Azure Load Balancer などのクラウド負荷分散サービスは、増加するトラフィックを処理するために容量を自動的に拡張します。

クラウド バーストのもう 1 つの課題は、動的な容量管理です。 Kubernetes はホスト上のコンテナのグループであるクラスターとポッドを自動的にスケーリングできるため、コンテナ化されたアプリケーションにはここで固有の利点があります。すべての主要なクラウド Kubernetes サービスには、クラスターの自動スケーリングが含まれています。

VM ホスト型アプリケーションの場合、主要なクラウド プラットフォームでは EC2 Auto Scaling や Azure Scale Set などのサービスを通じてインスタンス グループの自動スケーリングがサポートされていますが、容量管理はより複雑になります。これらのツールは、仮想 CPU 使用率、ネットワーク トラフィック、その他のメトリックなど、対応する監視サービスのポリシーに応答します。