クラウドプロバイダーの選び方

クラウドプロバイダーを選択するときは、ブランド認知度、セキュリティ、ストレージ機能などの項目を確認できます。しかし、クラウドプロバイダーは、他のプロバイダーと同じようにネットワークに依存しており、すべてが同じように作成または構成されているわけではありません。

一般に、クラウドを検討している人にとっては、エンドユーザーの場所とそれらにサービスを提供するクラウドの場所を一致させることが重要です。また、クラウドプロバイダーを初めて使用するときは、パフォーマンスのベースラインを継続的に目指す必要があります。これにより、パフォーマンスの問題が発生した場合に役立ちます。

主要なクラウドプロバイダーにはそれぞれ複数の拠点があるため、データやアプリをオフィスからクラウドに移動することによるネットワークへの影響を考慮することが重要です。この影響を説明するために、上位3つのプロバイダーの簡単な比較を設定しました。

テスト、テスト

大手3社のカバーを確認するために、いくつかのテストを行いました。 AWS、Azure、Google Cloudの3つの最大のパブリッククラウドプロバイダー向けに、北西のプレゼンスポイント（正確な場所はプロバイダーによって異なります）にSaaSCRMデモシステムをセットアップしました。その後、結果が出るのを待ちましたが、確かに興味深いものでした。

ロサンゼルスからのテスト

下のこの図は、ロサンゼルスから北西部の主要プロバイダーから最も近い場所へのネットワークトラフィックを示しています。北西部を拠点とするCRMでは、明確な勝者はありません。 GoogleとAWSは隣接するオレゴン州にあり、Azureは北カリフォルニアのそれらからわずかな距離にあります。ここでは、AWSが勝つ可能性がありますが、すべてが1か月の間に極端な変動を示します（ここでは低いほど良いです）。物理的な距離の違いは、Webリクエストの追加のネットワーク時間として完全には現れません（参考までに、クロスカントリートラフィックの場合は40ミリ秒かかります）。最も可能性が高いのはルーティングの変更です。

ロサンゼルス→北西部| AWS | Azure | Google

アトランタからのテスト

この次の例は、アトランタベースのモニターから北西のプレゼンスポイントまたはアベイラビリティーゾーンまでの3つのプロバイダーのネットワークルートを示しています。 AWSは最も遅いクラウドプロバイダーですが、3つすべてが1か月のウィンドウ全体で変動を経験します。合成ユーザーとサーバー間の物理的な分離がはるかに長いため、ネットワーク速度のわずかな変動を無視できます。ただし、AWSが平均1.5秒の追加レイテンシーに悩まされていることは明らかです。原因はさまざまですが、Webリクエストに最大2秒の余分な時間がかかると、ユーザーのフラストレーションのレベルが高くなる可能性があります。また、観察されたスパイクにはある程度の一貫性が見られ、トラフィックがルートと毎日の渋滞の問題を共有している可能性があることを示しています。

シアトルを拠点とする展開は、アトランタを拠点とする企業にとっておそらく理想的でも一般的でもないことを覚えておくことが重要です。しかし、シリコンバレー地域から非常に多くのスタートアップが出てきているため、毎日使用する多くのSaaSアプリがこの長距離の往復を行っている可能性があります。

アトランタ→北西部| AWS | Azure | Google

ニューヨークからのテスト

以下の最後の例は、ニューヨークゾーンから北西ベースのCRMまでのネットワークパスに沿ったネットワークパフォーマンスを示しています。 AWSは、依然として3つのプロバイダーの中で最も遅い応答時間を示しています。 GoogleとAzureは一貫して高速ですが、1月下旬に発生した1つの輻輳の問題を除けば。時間の経過とともに、インターネットはこのトラフィックの多くを全国で同様にルーティングすると想定できるため、AWSのファイアウォールの背後をルーティングすることが追加の遅延の原因である可能性があることを示す良い兆候があります。

ニューヨーク→北西部| AWS | Azure | Google

クラウドテストで見つかったもの

サンプルサイズは大きくなく、テストデプロイメントは最新のアプリの複雑さに合わせてカスタマイズされていませんが、結果から、クラウドデプロイメントを計画する際にロケーション調査を行うことがいかに重要であるかがわかりました。マップを取得して、サービスとアプリがクラウド内にあるときに配置される場所を確認します。次に、それらをそれらのアプリやサービスのユーザーがいる場所と一致させます。

国の真ん中でのピアリング契約やファイアウォールの背後での追加のルーティングなど、AWS側が高速応答を提供できないように見える原因となる可能性のある理由はいくつかあります。明らかなことは、エンドユーザーがどこにいるかによってパフォーマンスが異なることです。この事実を認識することは、パフォーマンスに関してより良い決定につながります。

クラウドプロバイダーのテストは私たちの唯一の目的ではありませんが、どのクラウドアプリでもAppNetaのツールを使用して私たちが行った（そして必要な）可視性を得ることができます。この種のネットワークインサイトは、ユーザーが速度低下や停止を訴え、パフォーマンス低下の根本原因を特定する必要がある日を節約する可能性があります。