ハイブリッドクラウドアプリケーション統合を成功させる方法

ハイブリッド クラウド環境では、すべてのアプリケーションが適切に連携して動作することを保証することが困難な場合があります。業界の専門家が、人々がこのプロセスについて考えるのを手助けします。

クラウド コンピューティングを導入している企業の多くがハイブリッド クラウドを採用していることがますます明らかになっています。アプリケーションがパブリック クラウドとデータ センターの間、さらにはパブリック クラウドを超えて移動する場合は、ますます複雑化するアプリケーション統合のタスクを管理する方法を理解することが重要です。

まず、ハイブリッド クラウド アプリケーション統合の複雑さを理解し、各変更要因が統合にどのように影響するか、またツールの調整と特定の統合の問題に焦点を当てます。

今日のほぼすべてのアプリケーションは、異なるコンポーネントから構築され、異なるシステムで読み込まれ、実行されます。ほとんどのプログラムは他のアプリケーションとデータを交換する必要もあります。この種のアプリケーションは、エンタープライズ IT がまさにワークフローのネットワークであることを意味します。これは、20 年前にサービス指向アーキテクチャ (SOA) の原動力となったビジョンです。 SOA は単純ではありませんが、仮想ホストと動的なアプリケーション スケーリングの世界では、その設計上の問題は単純に見えます。

アプリケーション統合とは、アプリケーション間のコンポーネントとワークフローを接続するプロセスです。現在、従来のデータ センター ホスティングにはこれを実現するメカニズムが存在するため、ハイブリッド クラウドにおいて組織が重点を置く必要があるのは、これらのメカニズムをどのように適応させるかということです。

ほとんどの企業は、アプリケーション統合戦略を完全に刷新することを望んでいません。生産性、アプリケーションライフサイクル管理、セキュリティ、コンプライアンスへの影響は大きくなります。適応の概念に焦点を当て、次に適応する必要があるものをカタログ化します。

ハイブリッド クラウドの導入は、アプリケーション ワークフローに 4 つの異なる影響を及ぼします。

（1）特定のアプリケーション/コンポーネントはデータセンター外でホストされており、異なるセキュリティ、コンプライアンス、ネットワーク接続の制御と機能が適用されます。

（２）場合によっては、クラウドアプリケーションは、クラウドプロバイダー内でも同様に実装されるのではなく、データセンター内に存在しないクラウドホスティングサービスを使用することがあります。これらの違いは、ワークフローの統合とコンポーネントのモビリティに影響します。

（3）アプリケーション/コンポーネントは動的に移動できるため、ワークフローはそれらに従う必要があり、異なる接続/セキュリティゾーン間を移動できます。

（4）クラウドコンピューティングでは、ワークロードに合わせて容量を動的にスケーリングするという概念が導入されていますが、これはクラウド以外の展開ではほとんど利用できません。

[[209577]]

ハイブリッド クラウド アプリケーションの統合を成功させるには、まずハイブリッド クラウド環境を設計し、次にそれぞれに対処するツールを適応/採用して、これらの影響要因に適応することが最も効果的です。組織が取る手順は、上記のリストにある特定の要因をターゲットにしている可能性がありますが、アジャイルなハイブリッド クラウド環境によってもたらされるシステム リスクを最小限に抑えるためには、それらの手順を実行する必要があります。

ハイブリッド クラウド アプリケーションの統合を成功させるための最初のステップは、すべてのホスティング プラットフォーム/プロバイダーにわたって統一されたアプリケーション展開および接続モデルを作成することです。これは、「ホスティング」を、あらゆるクラウドまたはデータセンターのリソースにマッピングできる抽象化として定義することを意味します。

ハイブリッド クラウド統合における最大の間違いは、過度に専門化することです。組織は、ハイブリッド クラウド全体で共通のネットワーク接続モデルを確立し、アプリケーション/コンポーネントを展開するための標準化されたホスティング モデルを定義する必要があります。

接続モデルの問題は、すべてのアプリケーションとコンポーネントをホストできる仮想プライベート ネットワークを作成することによってのみ解決できます。ますます多くの企業が、接続コアとしてソフトウェア定義ネットワークまたは仮想ネットワークを採用しています。適切なソフトウェア定義ネットワークまたはソフトウェア定義広域ネットワーク モデルを採用すれば、クラウドでもデータ センターでも、すべてを接続できます。オープンな統合接続に代わるものはないため、基本的なクラウド ネットワーキング ツール (OpenStack の Neutron など) は、企業の仮想ネットワーキングを作成するのではなく、補完するために使用するのに最適であることを企業が認識することが重要です。

適切な接続モデルを導入すると、標準化された展開環境により、単一のツールキットを使用してワークフローを簡単に統合できるようになります。 DevOps と Infrastructure as Code (IaC) ツールはどちらも標準的なデプロイメント プロセスをサポートしており、そのサポートは時間の経過とともに向上します。

この手順を実行すると、ハイブリッド クラウド統合に関連する特別な問題が大幅に軽減され、場合によっては問題がなくなることもあります。ただし、重要なホスティング仕様である IAC のツールと機能について、すべてのユーザーが理解しているわけではありません。

最後に、DevOps ソリューションのイベント処理属性を確認します。その強力な機能は、運用ライフサイクルの管理に役立ちます。

2 番目のステップは、セキュリティ、コンプライアンス、および適用要件に基づいて、アプリケーション/コンポーネントの「スコープ」を定義することです。すべてのアプリケーションのすべてのコンポーネントをハイブリッド クラウドで実行することを望む組織はほとんどありません。アプリケーション/コンポーネントがパブリック クラウドでのみ利用可能な Web サービスに依存している場合、その主な範囲はこのクラウドになります。内部監査のコンプライアンス ルールをクラウド内の一部の場所でのみ満たすことができる場合、その場所がクラウドの範囲となります。これらのスコープは、アプリケーションを展開して接続する運用ソフトウェアで適用され、実行可能な場所/実行する必要がある場所でのみ実行されるようにする必要があります。

ツールとポリシーを通じてスコープ制限を実装することは難しくなく、特別なツールも必要ありません。クラウド プロバイダーとデータ センター環境の特定の制限に注意する必要があり、ある程度の計画とレビューが必要ですが、アプリケーションをスコープ別にグループ化すると、潜在的なフェイルオーバーやクラウド バーストの問題を検出できるため便利です。組織は、さまざまなスコープに合わせて専門的なツールとプラクティスを調整できれば、統合と管理が容易になることもわかります。

3 番目のステップは、ロード可能な各アプリケーション/コンポーネントをフロントエンドとして負荷分散機能に関連付けることです。作業分散にはスケーラビリティが求められるため、アプリケーション統合で使用されるワークフロー接続は、スケーラブルなコンポーネントではなくロード バランサに接続する必要があります。このタスクには、負荷分散、アプリケーション配信制御、「レイヤー 3 スイッチング」などのテクノロジが使用されてきました。

ハイブリッド クラウド アプリケーションを統合する場合、ワークフローの分散をサポートし、拡張または終了手順によってワークフローが中断されたり、データの望ましくない迂回が生じたりしないようにするために、組織ではコンポーネント拡張時に実装オプションをできるだけ少なくすることが重要です。

長期的には、ハイブリッド クラウドが主流のモデルになるにつれて、ハイブリッド クラウドの統合が標準になるでしょう。組織が経験を積むのが早ければ早いほど、結果は良くなります。