Azure プロフェッショナルのための Google Cloud Platform: ネットワーキング

2017 年 7 月 18 日更新

Azure と Google がそれぞれのクラウド環境で提供しているネットワーキング サービスを、比べてみましょう。ネットワーキング サービスにより、仮想マシン、その他のクラウド サービス、およびオンプレミス サーバー間を接続することができます。

仮想ネットワーク

ネットワークとサブネットワーク

Azure と Cloud Platform はどちらも、分離された仮想ネットワークを提供しています。Azure VNet はリージョン リソースであり、Cloud Platform VPC ネットワークはグローバル リソースです。Azure と Cloud Platform では両方とも、所定のサブスクリプションまたはプロジェクト内に複数のネットワークを作成できます。また、それらのネットワークを 1 つ以上のサブネットワークにさらに分割できます。また、仮想ネットワーク内にデプロイされた VM は、それらが置かれているサブネットワークに関係なく、追加構成なしでお互いに通信できます。

Azure では、サブネットに VM やサービスがまだ含まれていない場合にのみ、サブネットの IP 範囲を縮小または拡大できます。一方、Cloud Platform では、サブネット内の VM に影響を及ぼすことなく、サブネットの IP 範囲を拡大できます。ただし、サブネットを作成した後や、サブネットの IP 範囲を拡大した後に、サブネットを縮小することはできません。

Cloud Platform を使用して、同じ Cloud 組織内にグループ化されているプロジェクト全体で仮想ネットワークを共有することもできます。 この機能は、共有 VPC ネットワーキングと呼ばれています。共有 VPC を使用して、Cloud 組織の管理者は、単一の共有仮想ネットワーク、および対応するネットワーキング リソースを使用するための権限を複数のプロジェクトに割り当てることができます。共有 VPC の詳細については、共有 VPC ネットワークの概要をご覧ください。 Azure では、共有 VPC に相当する機能は提供されていません。

ネットワーク インターフェースと IP アドレス

大まかに言うと、VPC ネットワークと Azure VNet は同様の方法で IP アドレスを処理しています。起動時に、すべての VM にはプライベート内部 IP が設定されています。オプションで、外部 IP を VM に関連付けることができます。この IP は動的にすることも、静的にすることもできます。ただし、詳細に説明すると、各サービスはわずかに異なります。

Azure

Azure はネットワーク インターフェース(NIC)とすべての IP アドレスタイプをリソースとして処理します。パブリック IP アドレス リソースは、特定の VM に関連付けられた NIC リソースに関連付けられます。Azure は、マシンタイプに応じて、1 台のマシンにつき最大 32 台の NIC をサポートします。各 NIC は最大で 50 個の IP 構成をサポートし、それぞれが 1 つのパブリック IP アドレスと 1 つのプライベート IP アドレスをサポートできます。

デフォルトで、パブリック IP アドレスはエフェメラルです。NIC リソースからパブリック IP アドレス リソースを分離すると、パブリック IP アドレス リソースは存続しますが、IP アドレス自体は削除されます。パブリック IP アドレス リソースを新しい VM に関連付けると、新しい IP アドレスはそのリソースに関連付けられます。

VM のプライベート IP アドレスもエフェメラルです。VM を停止またはデコミッションすると、VM によってそのプライベート IP アドレスが削除されます。VM を再起動すると、新しい IP アドレスが取得されます。

パブリックまたはプライベート IP アドレスは静的に設定することもできます。 IP アドレスが静的な場合、NIC から IP アドレス リソースが分離されても、IP アドレスは存続します。

Compute Engine

Compute Engine では、NIC は別個のリソースとしては扱われません。 指定した VM インスタンスに直接関連付けられます。Compute Engine VM インスタンスは、マシンのタイプに応じて、最大で 8 個の NIC をサポートします。 各 NIC は 1 つの外部 IP アドレスと、1 つの内部 IP アドレスをサポートしています。

Azure の場合と同様に、Compute Engine は各 VM インスタンスに内部 IP アドレスを設定します。また、エフェメラルまたは静的な外部 IP アドレスを追加できます。内部 IP アドレスとエフェメラル外部 IP アドレスは両方とも、別個のリソースではなく、VM インスタンスの一部として含まれています。 ただし、外部 IP アドレスをエフェメラルから静的に変換すると、そのアドレスは独立したリソースになり、VM から切り離せるようになります。

Azure の場合とは異なり、VM インスタンスの内部 IP アドレスはインスタンスの存続期間中、予約されています。

Compute Engine の場合も、エイリアスとして IP アドレスの範囲を VM インスタンスのプライマリ IP アドレスに割り当てることができます。この機能を使用して、同じ VM インスタンスで実行されている別個のサービスに別個の IP を割り当てることができます。これは、コンテナ化に関連するユースケースの場合に、特に便利です。 また、サブネットのエイリアス IP を割り当てるために使用できるセカンダリ CIDR 範囲をサブネット内に設定できます。

IP タイプ Azure Cloud Platform
永続的な IP パブリック静的 IP 静的 IP
一時的な IP パブリック動的 IP エフェメラル IP
内部 IP プライベート IP 内部 IP

VM の移行

Azure は、基盤となるハードウェアが更新されたとき、または障害が発生したときに、VM の移行を自動的に処理します。通常、このプロセスはシームレスに行われますが、更新を有効にするには VM の再起動が必要になることがあります。まれなケースでは、Azure で VM を強制再起動しなければならないこともあります。

同様に、Cloud Platform にはライブ マイグレーションという機能があり、Cloud Platform は、ホスト ハードウェアのメンテナンスや交換が必要なときに、VM インスタンスの移行を自動かつ透過的に行います。 Azure の移行プロセスと同様に、通常、ライブ マイグレーションはシームレスに行われますが、まれに、VM インスタンスを再起動する必要が生じることがあります。 ライブ マイグレーションは、大部分のマシンタイプに関して、デフォルトで有効になっています。ただし、GPU が接続されているマシンでは、GPU がホスト ハードウェアに直接接続されているため、ライブ マイグレーションは使用できません。ライブ マイグレーション機能の詳細については、ブログ投稿をご覧ください。

ファイアウォール

Azure と Compute Engine では両方とも、ユーザーはネットワークに接続されたリソースへのトラフィックを選択的に許可および拒否するためのステートフル ファイアウォール ポリシーを構成できます。 どちらの環境でも、各仮想ネットワークはネットワーク外部からのすべての着信トラフィックをデフォルトでブロックします。 ルールを適用することで、特定のリソースに対するアクセスを許可できます。Azure では、各ルールはネットワーク セキュリティ グループ(NSG)として設定され、Compute Engine では、各ルールはファイアウォール ルールとして設定されます。

Cloud Platform と Azure のどちらも、タグを NSG またはファイアウォール ルールに関連付けることで、指定されたタグを使用するリソースにルールを適用できます。Azure では、特定のサブネットまたは NIC に関連付けることができる NSG は 1 つのみです。一方、Cloud Platform では、リソースに複数のファイアウォール ルールを適用し、ファイアウォールをより詳細に管理できます。

Azure では、VM レベルで適用可能なエンドポイント アクセス制御リスト(ACL)を作成し、ステートフルなファイアウォール ルールを設定することもできます。 Cloud Platform では、ステートレスなファイアウォール ルールはサポートされていません。

負荷分散

ロードバランサは、受信ネットワーク トラフィックを複数のインスタンスに分散します。 適切に構成された場合、ロードバランサはアプリケーションをフォールト トレラントにし、アプリケーションの可用性を高めます。

概要として、Azure と Cloud Platform の負荷分散コンポーネントは、以下のように対応しています。

コンポーネント Microsoft Azure Google Cloud Platform
HTTP 負荷分散 Application Gateway(クロスリージョン負荷分散用に Traffic Manager とペア設定可能) Compute Engine HTTP(S) ロードバランサ
TCP / UDP 負荷分散 Azure Load Balancer(インターネット接続ロードバランサ) ネットワーク ロードバランサ、TCP プロキシ ロードバランサ(クロスリージョン)
内部負荷分散 Azure Load Balancer(内部ロードバランサ) Compute Engine 内部ロードバランサ
SSL 負荷分散 Application Gateway(HTTPS トラフィック) Compute Engine HTTP(S) ロードバランサ(HTTPS トラフィック)、SSL プロキシ ロードバランサ(暗号化された非 HTTP トラフィック)

HTTP(S) 負荷分散

Azure と Compute Engine には、レイヤ 7 負荷分散が装備されており、レイヤ 4 負荷分散で実現できるルーティングよりも高度なルーティングを達成するために、アプリケーション層でクライアント リクエストを配信します。Azure は Application Gateway でこのサービスを提供し、Compute Engine はその HTTP(S) ロードバランサでこのサービスを提供しています。これらのサービスは互いに以下のように関連付けられます。

機能 Application Gateway Compute Engine HTTP(S) ロードバランサ
HTTP 負荷分散
複数のリージョンにわたる、単一のグローバル IP × ○(IPv4 と IPv6 の両方)
クロスリージョン負荷分散 Traffic Manager(DNS ベース)とペア設定されている場合 ネイティブでサポート(IP ベース)
コンテンツ ベースの負荷分散
セッション アフィニティ ○(Cookie ベース) ○(Cookie ベースおよび IP ベース)
SSL の終了
エンドツーエンドの SSL
WebSocket のサポート
稼働状況のモニタリング
ロギング ○(現在はアルファ版)
負荷分散 ラウンドロビン CPU 使用率またはリクエスト/秒(RPS)
自動スケーリング ×

クロスリージョン HTTP(S) 負荷分散

Application Gateway と Compute Engine はいずれも、クロスリージョン HTTP(S) 負荷分散を実現する方法を提供しています。

Azure では、Azure の DNS ベースのトラフィック ルーティング サービスである Traffic Manager を複数の Application Gateway エンドポイントの前に配置することで、クロスリージョン HTTP(S) 負荷分散を構成できます。次に Traffic Manager は、ユーザーが選択したルーティング方法に従って、エンドユーザーに最も近い Application Gateway エンドポイントにトラフィックをルーティングします。

Application Gateway を使用する場合とは異なり、Compute Engine HTTP(S) 負荷分散では、クロスリージョン HTTP(S) 負荷分散はネイティブにサポートされます。HTTP(S) ロードバランサを構築するときは、単一のグローバル IP エントリ ポイントを保持するグローバル転送ルールを設定します。このルールにより、トラフィックはターゲット プロキシを経由して送信され、そのプロキシにより、トラフィックは関連するバックエンドに配信されます。HTTP(S) ロードバランサは、エンドユーザーに最も近いバックエンドにトラフィックを振り向けます。 ただし、Compute Engine のグローバル IP ベースの負荷分散には、次のようなパフォーマンス上の大きなメリットがあります。

  • IP ベースの負荷分散は負荷を認識します。CPU 使用率またはリクエスト/秒に基づいてトラフィックが分散されるように、Compute Engine のグローバル ロードバランサを構成できます。一方、DNS ベースの負荷分散は負荷を認識しないため、一般的なルーティング方法に基づいてトラフィックをルーティングする必要があります。
  • DNS ベースの負荷分散は、ISP の影響を受けます。DNS の変更を適用するには、変更を ISP レベルで記録する必要があります。ISP では数時間分の DNS レコードが一度にキャッシュに保存されることがよくあるため、タイミング良く DNS の変更が反映されない場合があります。その場合、過度に使用されている、または障害が発生しているバックエンド サービスにエンドユーザーがルーティングされる可能性があります。この潜在的な問題の原因を回避するには、グローバル IP ベースの負荷分散が役立ちます。

セッション アフィニティ

セッション アフィニティにより、特定のクライアントを特定のバックエンドにマッピングできます。これにより、サーバー側のリソースを節約できる可能性があります。

Application Gateway には Cookie ベースのセッション アフィニティが備わっており、これによって、クライアント側の Cookie に保存することで、特定のバックエンド VM にクライアントが関連付けられます。

Compute Engine の HTTP(S) ロードバランサにも Cookie ベースのアフィニティが備わっています。また、HTTP(S) ロードバランサには IP ベースのアフィニティも備わっており、これによって、特定のクライアント ID アドレスから同じ VM インスタンスにすべてのリクエストが転送されます。

スケーリング

Application Gateway では、ロードバランサの処理容量を超過した場合、手動で VM を追加する必要があります。一方、Compute Engine の HTTP(S) ロードバランサでは、ロードバランサの処理容量に基づいて VM インスタンスの自動スケーリングが行われるため、手動で調整せずに、トラフィックのオーバーフローを処理できます。この自動スケーリングは、事前に起動しなくても定期的に実行されます。詳細については、負荷分散とスケーリングをご覧ください。

TCP / UDP 負荷分散

Azure と Compute Engine の両方にレイヤ 4 負荷分散機能があり、ネットワーク トランスポート層で、クライアント リクエストをリージョン内で分配します。Azure では Azure ロードバランサを通じてこのサービスが提供され、Cloud Platform では Compute Engine ネットワーク ロードバランサを通じてこのサービスが提供されます。

これらのサービスは互いに以下のように関連付けられます。

機能 Azure ロードバランサ Compute Engine ネットワーク ロードバランサ
TCP / UDP 負荷分散
内部負荷分散
インターネット接続負荷分散
サポートされているアプリケーション層プロトコル すべて すべて
サポートされているエンドポイント Azure VM(Basic VM を除く)、Cloud Services 役割インスタンス ターゲット プール、ターゲット VM インスタンス、バックエンド サービス(内部負荷分散のみ)
稼働状況のモニタリング
デフォルトの負荷分散モード 5 タプル(送信元 IP と宛先 IP、送信元と宛先のポート、プロトコル タイプ) 5 タプル(送信元と宛先の IP、送信元と宛先のポート、プロトコル タイプ)
セッション アフィニティ モード 2 タプル(送信元と宛先の IP)、3 タプル(送信元と宛先の IP、ポート) 2 タプル(送信元と宛先の IP)、3 タプル(送信元と宛先の IP、プロトコル タイプ)

クロスリージョン TCP / UDP 負荷分散

Azure では、Traffic Manager を Azure ロードバランサの前に配置し、パブリック IP アドレスに動的にルーティングされるように構成することで、エンドユーザーのレイテンシを改善することができます。このように配置することで、単一の DNS 構成を使用して、ユーザーに最も近い VM にトラフィックをルーティングできます。

Compute Engine では、TCP プロキシ負荷分散または SSL プロキシ負荷分散を設定して、同様の結果を得ることができます。これらのサービスは、設計上、Compute Engine HTTP(S) ロードバランサと類似していますが、より広い範囲のアプリケーション層プロトコルをサポートしています。 HTTP(S) ロードバランサと同様に、両方のサービスでは、単一のグローバル IP アドレスを使用して、ユーザーに最も近い VM インスタンスにトラフィックを分配できます。

IP ベースの負荷分散では、負荷ベースのトラフィック分配や、より安定したパフォーマンスなど、DNS ベースの負荷分散よりもパフォーマンスが大幅に向上します。詳細については、クロスリージョン HTTP(S) 負荷分散をご覧ください。

料金

Azure Load Balancer の料金は、Azure 仮想マシンの料金に含まれています。

Application Gateway では、ゲートウェイごとに時間単位で課金され、ゲートウェイで処理されるトラフィックに対して別個の GB 単位で課金されます。

Compute Engine では、転送されるルールごとに時間単位で課金され、ロードバランサで処理されるトラフィックに対して別個の GB 単位で課金されます。

DNS

DNS サービスでは、人が読める形式のドメイン名が、サーバーがそれぞれのドメインを接続するための IP アドレスに翻訳されます。Azure DNS や Google Cloud DNS などのマネージド DNS では、クラウド内でスケーラブルなマネージド DNS を使用できます。

Azure DNS と Cloud DNS はよく似ています。どちらも非常に一般的な DNS レコードタイプをサポートし、さらにエニーキャスト ベースのサービスもサポートしています。現時点では、どちらのサービスも DNSSEC をサポートしていません。

接続

以下の表は、Azure と Cloud Platform の接続サービスを比較したものです。

機能 Azure Cloud Platform
VPC ピアリング VNet ピアリング VPC ネットワーク ピアリング
仮想プライベート ネットワーク Azure VPN ゲートウェイ Cloud VPN
キャリア パートナーを経由した専用プライベート接続 ExpressRoute なし
キャリア パートナーを経由した専用パブリック接続 なし Carrier Interconnect
専用の直接接続 なし ダイレクト ピアリング
CDN ピアリング なし CDN Interconnect

VPN

Azure と Cloud Platform はどちらも、仮想プライベート ネットワーク(VPN)サービスを使用できます。Azure では Azure VPN ゲートウェイが提供されており、Cloud Platform では Google Cloud VPN が Compute Engine の一部として提供されています。どちらのサービスでも、外部のネットワークから内部 Azure または Compute Engine 仮想ネットワークへのトンネルを作成し、そのトンネルを使ってセキュアな接続を確立します。

Cloud Platform でのトラフィックのルーティングでは、Google Cloud Router を使用して、Compute Engine ネットワークと Google 以外のネットワークの間で BGP ルートを動的に更新することができます。Azure では、Azure VPN ゲートウェイ サービスの一部として同様のルーティング サービスが用意されています。

仮想ネットワーク ピアリング

Azure と Cloud Platform はどちらも、1 つ以上の仮想ネットワークをピアリングする機能が備わっています。この機能は、Azure では VNet ピアリングと呼ばれ、Cloud Platform では VPC ネットワーク ピアリングと呼ばれています。 仮想ネットワーク ピアリングには外部 IP アドレスまたは VPN と比較して、以下のような利点があります。

  • パブリック IP ネットワーキングよりもレイテンシが小さい
  • サービス オーナーは、サービスが公衆インターネットに公開されるのを防ぎ、それに伴うリスクを回避できるため、セキュリティが強化される

Azure の VNet ピアリングは、Cloud Platform の VPC ネットワーク ピアリングと以下のように対応しています。

機能 Azure Cloud Platform
ローカルでの制限 ピアリングされたネットワークが同じリージョン内に入っている必要がある 制限なし
サポート対象のサービス VM、Cloud Services Compute Engine、App Engine フレキシブル環境
ネットワークあたりのピアリングされたネットワークの最大数 デフォルトで最大 10、必要に応じて最大 50 最大 25
IP アドレスの重複 サポート対象外 サポート対象外
推移的ピアリング サポート対象外 サポート対象外

ユニット間ピアリング

Azure では、異なるサブスクリプションに存在する VNet 間でピアリングを行えます。 同様に Cloud Platform でも、異なるプロジェクトまたは組織に存在する VPC ネットワーク間でピアリングを行えます。 プロジェクト間で VPC ネットワークのピアリングを行うために、指定した VPC ネットワークと共有 VPC ネットワークをピアリングできます。組織間で VPC ネットワークのピアリングを行うために、それらの組織内のプロジェクト内に存在する VPC ネットワークとピアリングできます。

専用の相互接続

場合によっては、オンプレミスとクラウド間の VPN によって、特定のワークロードに必要な速度やセキュリティが得られないことがあります。そのような場合、Azure と Google はどちらもパートナーと連携して、保証されたレベルの容量を持つネットワーク回線をユーザーがリースできるようにしています。

キャリア ピアリング

Azure では ExpressRoute が提供されます。これを使用してユーザーは、パートナーのキャリア施設を経由して、Azure にプライベートのリース回線をセットアップできます。各パートナーのロケーションによって、特定のリージョンにサービスが提供されます。

Google は、Cloud Interconnect と呼ばれる同等のサービスを提供しています。 ExpressRoute や Azure と同様に、Cloud Interconnect ではパートナー施設を経由して、Cloud Platform にリージョン用のリース回線をセットアップできます。 ただし、この回線ではパブリック ネットワークが使用されます。

ダイレクト ピアリング

キャリア ピアリングに加え、Cloud Platform では、サードパーティのパートナーではなく、Google のネットワークに直接接続することもできます。 Azure は、このサービスを提供していません。

コンテンツ配信ネットワーク(CDN)でのピアリング

コンテンツ配信ネットワーク(CDN)でのピアリングにより、ネットワーク エッジ ロケーションを経由して、クラウド内のリソースと CDN プロバイダを接続させることができます。Google は、CDN インターコネクト サービスを通じて、いくつかの CDN プロバイダに CDN ピアリングを提供しています。

Azure は、サービスとしての CDN ピアリングは提供していません。ただし、Azure には Azure CDN サービスの一部として Akamai や Verizon の CDN への専用接続が備わっています。

料金

Azure と Cloud Platform ではどちらも、VPN サービスに対して時間単位で課金されます。

Cloud Interconnect の場合、キャリア ピアリングの費用は回線をリースするパートナーによって設定されます。ExpressRoute の場合、Azure によって以下の 2 種類の課金モデルが用意されています。

  • データ無制限: 月額料金を支払い、無制限でデータを転送できます。
  • データ従量制: 月額料金は低額になりますが、ネットワーク下りの GB 単位でも課金されます。

Cloud Platform では、ダイレクト ピアリングに対する課金はありません。

キャリア ピアリングの場合と同様に、Cloud Platform の CDN ピアリングの費用はピアリングを行うパートナーによって設定されます。Cloud Platform では、CDN インターコネクトに対する課金はありません。

次のステップ

次へ: ストレージ