マルチクラウド環境を可視化する方法

マルチクラウドは、企業にとっての進化のステップであり、単一のクラウド プラットフォームの開始段階からマルチクラウド サービスに移行するための「最初の」方法であると考えられることがよくあります。これを決定する要因はさまざまです。一部の企業では、ワークロードの多様性により、プラットフォーム固有の機能が必要になります。他の企業の場合、それは進化のプロセスであったり、合併や買収の結果であったりすることもあります。

[[227950]]

最近、企業が主要なクラウドファースト戦略としてマルチクラウドを選択する傾向が見られます。場合によっては、クラウド プラットフォーム ベンダーが自社の製品にさらなる粘着性を加え始めるにつれて、単一のベンダーへの依存を減らすことが理由となります。その他の場合、コストはワークロードの特性に基づいて最適化されます。どちらの面でも、ハードウェア プラットフォームをめぐる議論と似たような活発な議論が行われています。

マルチクラウド環境での運用を選択する理由が何であれ、ある程度の複雑さが生じ、慎重に管理しないと、マルチクラウド戦略で達成しようとしているコスト削減が損なわれ、パフォーマンスが低下する可能性があります。

これが可視性が極めて重要である理由です。しかし、マルチクラウドの導入と同様に、ビジネスの可視性を獲得するには、データ セットを変更する必要があります (ローカル ネットワークに加えて、WAN、インターネット、クラウド、SaaS プロバイダーの健全性とパフォーマンスを測定します)。この記事では、マルチクラウド展開に関連するいくつかの重要な用語を確認し、従来の可視性アプローチがクラウドに関しては不十分である理由を説明し、マルチクラウド運用の可視性を獲得するために必要なアプローチについて説明します。

ハイブリッドクラウドとマルチクラウド

ハイブリッド クラウドとは通常、既存の従来のデータ センターとクラウドから利用される一部のサービスとの組み合わせを指します。今日のほとんどのアプリケーションは、認証、支払い、物流など、1 つ以上の外部 API ベースのサービスを使用するハイブリッド型です。内部でホストされているアプリケーションが認証のために Azure AD または Okta を呼び出す場合、実質的にハイブリッド クラウドを実行していることになります。企業の Web サイトに PayPal または Visa の支払いウィジェットがある場合は、ハイブリッド クラウドを使用しています。

アプリケーションは構成サービスに細分化され、構造化された API 呼び出しを通じてのみ通信するため、各コンポーネントを個別にターゲットにして拡張できます。これにより、AWS のようなインフラストラクチャおよびプラットフォーム サービスが非常に魅力的になります。したがって、特定のコア資産と機能がまだ存在する場合でも、企業はステートレス コンポーネントを個別に拡張し、ユーザーに近いクラウドに配置することができます。

VMware はエンタープライズ クラウドの業界リーダーであり、Amazon との提携を通じて実用的なハイブリッド クラウド サービスを提供しています。 VMware Cloud on AWS を使用すると、企業は vSphere を通じてすべてを管理しながら、仮想マシンのワークロードと仮想ネットワークを Amazon クラウド プラットフォームに簡単に拡張できます。

一方、マルチクラウドとは、企業のオンプレミス データ センターを 2 つ以上のクラウド コンピューティング プロバイダーと組み合わせて使用​​することを指します。

マルチクラウドには、IaaS、PaaS、SaaS など、あらゆるタイプの外部クラウド プロビジョニングが含まれます。これは、それぞれ独自のオーケストレーション規則を持つ複数のベース プラットフォームを備えた、より複雑な環境です。ここでの目標は、コスト経済性と最適な組み合わせによってワークロードの配置を決定することです。経営の観点から見ると、企業は予測できない程度とペースの変化に対処しており、これは困難な場合があります。さらに、企業のコールフローにはさらに多くの組み合わせが含まれるようになり、パフォーマンスのチューニングとトラブルシューティングが特に複雑になっています。

マイクロサービス API

マイクロサービス アーキテクチャは長年にわたって人気があり、新しいアプリケーションの構築方法を根本的に変えてきました。 Uber は、主にマイクロサービス エコシステムで運営されている企業の良い例です。 Uber は、マッピング、支払い、通知、通話にサードパーティの API に依存しています。これらの各 API は、さらに他のバックエンド API に依存する場合があります。したがって、乗客が Uber に乗るたびに、自宅まで乗車するためには、複数の API フロー、クラウド コンピューティング サービス、およびネットワーク パスが適切に機能する必要があります。

これは、IT 組織がこれまで対処したことのないレベルの複雑さです。すべてが正常に動作しているときは複雑さは明らかではありませんが、障害が発生した場合のトラブルシューティングは非常に複雑になります。

その良い例が、最近の AWS の障害です。インフラストラクチャの観点から見ると、AWS クラウド サービスの停電は最小限に抑えられ、システムの復旧時間もかなり短くなります。しかし、バックエンドのデータフローに AWS Direct Connect に依存していたアプリケーションは、最初のインシデント発生後も数時間にわたって障害が続きました。 Atlassian、Slack、Twilio などのこれらのアプリケーションやサービスの多くは、複数のクラウド プラットフォーム間の隠れた依存関係を考慮しなかったプロバイダーによって発見されました。

2017 年 3 月 2 日の障害は、Amazon の AWS 東部リージョン (アッシュバーン) の一部のサービスに影響を与え、AWS Direct Connect ユーザーにとってすぐに大きな問題となりました。 ThousandEyesは、240以上の重要なサービスが停止の影響を受けたことを明らかにした。

クラウド コンピューティングやインターネット全般における課題の 1 つは、可視性の欠如です。従来のネットワーク監視ツールの多くは、簡易ネットワーク管理プロトコル (SNMP)、フロー キャプチャ、パケット キャプチャなどのテクノロジに依存しています。これらすべてには、データセンターを構成するサーバー、スイッチ、ファイアウォール、ルーターへの一定レベルの特権アクセスが必要です。これらはいずれも IaaS または PaaS サービスでは利用できません。企業は Microsoft Azure 内で盗聴したり、Amazon のデータセンターから録画をストリーミングしたりすることはできません。その結果、企業はクラウド コンピューティングを目に見えないベールの後ろに隠されたブラック ボックスとして見るようになりました。

このアプローチは、単一のクラウド プラットフォームやハイブリッド クラウドでは機能しません。また、マルチクラウド インフラストラクチャでは機能しません。パスの組み合わせの数は、クラウド プラットフォームの数に応じて規則的に増加します。これらのパスにはそれぞれ予測できない要素が多数あります。したがって、企業に対するリスクは桁違いに増大します。では、これらのクラウド プラットフォームをブラック ボックスとして扱うことはできなくなりました。では、どのような選択肢があるのでしょうか?

クラウドコンピューティングにはカバーがない

一部のクラウド プロバイダーは独自のネットワーク可視性ソリューションを提供しています。たとえば、Microsoft Azure では、企業は ExpressRoute 接続を介して、ネットワークから Azure 内の仮想ネットワーク (VNet) までの企業ドメインを視覚化できます。ただし、これでは、外部依存関係を含む完全なエンドツーエンドの全体像がビジネスに提供されるわけではありません。もちろん、このソリューションは Azure に固有のものであり、他のクラウドや従来のデータ センターに関する情報は提供されません。マルチクラウド戦略では、ワークロードが移動すると、可視性ソリューションはリソースの場所に関係なくリソースを追跡する必要があります。

それで、これはどうすればできるのでしょうか?特別に計測されたアプリケーション呼び出しを使用して、アプリケーションの可用性と応答時間、およびそれらのアプリケーションの配信に使用される基盤となるネットワークとクラウド コンピューティング インフラストラクチャに関する洞察を得るアクティブ監視テクノロジがあります。これにはクラウド インフラストラクチャからの特権情報は必要ないため、クラウドやベンダーに依存しません。一般的に、これらはすべてリソースのターゲット URL です。

これは、インターネット対応のネットワーク監視を実行するソフトウェア エージェントの世界的な艦隊を運用している ThousandEyes が採用しているアプローチです。 ThousandEyes は、インターネット上の複数の視点から重要なサービスを監視し、アルゴリズムを使用してデータを相関させ、サービスへの影響を把握します。その結果、企業は、AWS Direct Connect に依存する 240 を超える重要なサービスが 2017 年 3 月 2 日の停止の影響を受けたことを突き止めることができました。

クラウドには安定した状態はありません。すべての IaaS および PaaS プロバイダーは DevOps と自動化ツールを多用しているため、変更は事前の通知なしに迅速に行われます。同時に、マルチスレッドのデプロイメントでは、Kubernetes などのコンテナ化および自動化サービスを使用して、ワークロードを主要なクラウド プラットフォームに移行することがよくあります。急速に変化する世界では、企業はアプリケーション配信パスの変更を反映し、アプリケーションの完全かつ安全なビューを提供するための継続的な可視性を必要としています。