番組で説明した資料はこちらで公開しています。

Cloud OnAir では、各回 Google Cloud のエンジニアがトピックを設け、Google Cloud の最新情報を解説しています。過去の番組、説明資料、さらには視聴者からの質問と回答はこちらよりご覧いただけます。 最新の情報を得るためにもまずはご登録をお願いします。
ラベル: ,

ラベル:

下りトラフィックと上りトラフィックの伝送
同様に、GCP はお客様のアプリケーションからエンドユーザーへのトラフィック（下りトラフィック）を Google ネットワーク経由で伝送し、エンドユーザーが世界のどこにいても、エンドユーザーに最も近い POP から送出します。これにより、こうした下りトラフィックのほとんどは 1 ホップでエンドユーザーの ISP に送信され、宛先に到達します。そのおかげでネットワークの混雑が最小限に抑えられ、パフォーマンスが最大化されます。

私たちは Google ネットワークを、高い冗長性を持つように設計しました。アプリケーションの高い可用性を確保するためです。Google ネットワーク上のどの 2 地点間でも、少なくとも 3 つの独立した経路（N+2 の冗長性）があります。そのため、2 地点間の特定の経路が途絶したとしても、トラフィックは確実に流れ続けます。

つまり、Premium Tier ではファイバー ケーブルが 1 本切れてもトラフィックは影響を受けません。ファイバー ケーブルが 2 本同時に切れても、多くの場合、お客様のアプリケーションに対するトラフィックの送受信は中断せずに継続されます。

GCP のお客様は、Premium Tier のもう 1 つの機能であるグローバル負荷分散も幅広く利用できます。管理が容易な 1 つのエニーキャスト IPv4 または IPv6 仮想 IP（VIP）を利用できるだけでなく、複数リージョンにまたがるシームレスなスケーリングに加え、他のリージョンへのオーバーフローやフェイルオーバーも可能です。



Premium Tier では、Google 検索、Gmail、YouTube といったサービスや、Google のお客様である The Home Depot、Spotify、Evernote などのサービスと同じネットワークを利用できます。

「現時点では、homedepot.com の 75 % が Google Cloud から提供されています。私たちは、複数リージョンにまたがって運用することで高い可用性を確保したいと考えました。Google のグローバル ネットワークは、Google Cloud を選択する理由となる最も強力な機能の 1 つです。」
— Ravi Yeddula 氏、The Home Depot のプラットフォーム アーキテクチャ & アプリケーション開発担当シニア ディレクター

Standard Tier の導入

新しい Standard Tier は、他の主要パブリック クラウドに匹敵するネットワーク品質を、Premium Tier よりも安い料金で提供します。

なぜ Standard Tier のほうが安いのでしょうか。GCP からの下りトラフィックは、Google ネットワークではなくパブリック インターネットに送信され、ISP を経由してエンドユーザーに送信されるからです。


下りトラフィックと上りトラフィックの伝送

同様に、エンドユーザーから GCP への上りトラフィックについては、GCP の宛先があるリージョン内でのみ Google ネットワークで伝送されます。エンドユーザーのトラフィックが異なるリージョンから送信された場合は、そのトラフィックはまず ISP とパブリック インターネットを経由して、GCP の宛先があるリージョンに送信されます。

Standard Tier のネットワーク パフォーマンスと可用性は、Premium Tier に比べると低くなります。GCP とGCP に最も近い POP の間の短いホップでのみ、お客様の下りおよび上りトラフィックは Google ネットワークで伝送されます。そのため、Standard Tier のパフォーマンス、可用性、冗長性といった特性は、お客様のトラフィックを伝送する ISP のネットワークとインターネットに依存します。場合によっては、Premium Tier と比べて頻繁にネットワークの混雑や停止に見舞われるかもしれません。ただし、その頻度は他の主要パブリック クラウドと同等のレベルです。

Standard Tier では、新しいリージョナル クラウド負荷分散サービスなど、リージョナル ネットワーク サービスのみが提供されます。負荷分散仮想 IP（VIP）は他のパブリック クラウド サービスと同様にリージョナルです。マルチリージョンで負荷分散を行う必要がある場合、Premium Tier で利用できるグローバル負荷分散と比べて管理が複雑になります。



Premium Tier と Standard Tier のパフォーマンス比較

私たちは、Network Service Tiers のパフォーマンスの予備測定を Cedexis に委託しました。同社はインターネット ベースのパフォーマンス監視および最適化ツールを手がける企業です。

Cedexis による測定の結果は予想どおり、Premium Tier のほうが Standard Tier よりスループットが高く、レイテンシが低いというものでした。こちらの “Network Tiers” セクションで、測定結果を示すライブ ダッシュボードを見ることができます。同社はウェブ サイトで測定方法も説明しています。

Cedexis が作成した下のグラフは、Premium Tier と Standard Tier について、HTTP 負荷分散トラフィックのスループットの 50 パーセンタイル（中央値）を時系列で示しています。Standard Tier（青線）のスループットは平均 3,223 kbps、Premium Tier（緑線）は平均 5,401 kbps で、Premium Tier のスループットが Standard Tier の 1.7 倍弱となっています。



一般に、Premium Tier はどのパーセンタイルでも、Standard Tier よりかなり高いスループットを示します。

Premium Tier と Standard Tier の料金比較

Premium Tier と Standard Tier では新料金を導入します。新料金の詳細はこちらで確認できます。この新料金は、Network Service Tiers の正式リリース（GA）時に適用が開始されます。アルファおよびベータの段階では既存のインターネット下り料金が適用されます。

Network Service Tiers の新料金（GA 後）では、北米と欧州における下りトラフィック（GCP からインターネットへ）の料金は、Standard Tier のほうが Premium Tier よりも 24～33 % 安くなっています。この Standard Tier の料金は、他の主要パブリック クラウド プロバイダーのインターネット下りオプションよりも安価です（2017 年 7 月時点で公表されていた通常料金との比較）。上りトラフィックは Premium Tier、Standard Tier とも無料です。

また、Premium Tier の下りトラフィック料金は、トラフィックの送信先に基づく現行の算定方式から、送信元と送信先の両方に基づいた方式に変更されます。ネットワーク トラフィックのコストは、Google ネットワークでのトラフィックの伝送距離に左右されるからです。これに対し、Standard Tier の下りトラフィック料金は送信元に基づいて算定されます。Google ネットワークでの伝送距離があまりないからです。

適切な Tier の選択

強力な Premium Tier が、これまでどおりお客様のワークロードのデフォルト Tier です。以下に、お客様の要件に最適な Tier を選択するための決定木を示します。


アプリケーションに合わせた Tier の構成

万能のネットワーク技術は存在しません。また、Google Cloud 内のお客様のアプリケーションは通常、可用性やパフォーマンス、フットプリント、コストの要件がさまざまに異なります。きめ細かく管理したい場合はリソース レベル（インスタンス、インスタンス テンプレート、ロード バランサごと）で Tier を構成し、すべてのリソースにわたって同じ Tier を使用したい場合は包括的なプロジェクト レベルで Tier を構成します。



今すぐお試しあれ

「クラウドを利用するお客様はサービス レベルやコストの選択肢を求めています。サービスをビジネス要件に対応させることは、お客様が抱えるクラウドの最適化ニーズに応えることになります。Google は、Network Service Tiers のアルファ リリースにより、最適化ニーズへの対応を初めて行動に移したパブリック クラウド プロバイダーです。Premium Tier は品質の保証を必要とするお客様向け、Standard Tier はコストを抑える必要があるお客様や、グローバル ネットワーキング ニーズが限られているお客様向けです。」
— Dan Conde 氏、ESG のアナリスト

Network Service Tiers についてもっと知りたい方はウェブ サイトをご覧ください。そしてアルファ版にサインアップして、ぜひお試しください。フィードバックをお待ちしています。

* この投稿は米国時間 8 月 23 日、Cloud Networking の Product Manager である Prajakta Joshi によって投稿されたもの（投稿はこちら）の抄訳です。

- By Prajakta Joshi, Product Manager, Cloud Networking
ラベル:


「私たち WP Engine のデジタル エクスペリエンス プラットフォーム上で稼働する 50 万の WordPress サイトは、BBR のおかげで驚異的な速さでロードできるようになりました。Google のテストによれば、BBR のスループットはこれまでベストだった loss-based 輻輳制御の 2,700 倍に達し、キューイング遅延は 25 倍も下がっています。私たちが GCP のパートナーであり続ける理由の 1 つは、BBR のようなネットワーク イノベーションにあります。」 — Jason Cohen 氏、WP Engine の創業者兼 CTO


WP Engine のような GCP のお客様は、BBR 導入によって自動的に 2 つのメリットを手にします。

  • GCP サービスからクラウド ユーザーへ : GCP のお客様が Cloud Bigtable や Cloud Spanner、Cloud Storage などの GCP サービスとやり取りするとき、GCP サービスからアプリケーションへのトラフィックは BBR を使って送られます。これは、データ アクセスの高速化を意味します。
  • Google Cloud からインターネット ユーザーへ : GCP のお客様がウェブ サイトのサービス提供や負荷分散のために Google Cloud Load Balancing や Google Cloud CDN を使うとき、コンテンツは BBR を使ってユーザーのブラウザに送られます。これは、ウェブ ページがサイトのユーザーのもとに速くダウンロードされることを意味します。

私たち Google はインターネットの高速化を長期的な目標として掲げ、これまでも TCP を高速化し、Chrome ブラウザや QUIC プロトコルを開発してきました。BBR はこれらに続く次のステップなのです。なお、BBR アルゴリズムを質の高いレベルで解説したドキュメント、BBR の詳細が記されたインターネット ドラフト、Linux TCP と QUIC のための BBR コードが用意されています。

BBR とは何か

BBR（Bottleneck Bandwidth and Round-trip propagation time）は、Google が開発した新しい輻輳制御アルゴリズムです。ネットワークに接続されたすべてのコンピュータ、携帯電話、タブレットで実行され、データの送信速度はこれによって決まります。

では、輻輳制御アルゴリズムが送信速度を左右するというのはどういうことでしょうか。

1980 年代の後半から、インターネットではスローダウンの兆候としてパケット ロスだけを頼りとする loss-based 輻輳制御が主として使われてきました。インターネット スイッチやルータの小さなバッファはインターネット リンクの低帯域幅にちょうど見合ったものだったので、この方法は長年にわたってうまく機能したのです。これらのバッファは、送信側のデータ送信速度が速くなりすぎた途端にいっぱいになってパケットを消失してしまう傾向がありました。

しかし、このような loss-based 輻輳制御は、今日の多種多様なネットワークでは問題があります。

  • バッファが浅い場合、パケット ロスは輻輳が起きる前に発生します。バッファが浅いコモディティ スイッチを使っている現代の高速長距離リンクで loss-based 輻輳制御を行うと、過剰反応を起こしてスループットがひどく落ちてしまうことがあります。一時的なトラフィックのバーストによりパケットが消失しているときでも（この種のパケット ロスは、リンクがほとんどアイドル状態でもよく起きます）、送信速度が半分になってしまうのです。
  • バッファが深い場合、輻輳はパケット ロスが起きる前に発生します。インターネットの末端では、loss-based 輻輳制御は悪名高いバッファブロート問題を引き起こします。多くのラスト ワンマイル リンクで使われている深いバッファを繰り返しいっぱいにしては、無駄に数秒間のキューイング遅延を発生させるのです。

私たちが必要としているのは、パケット ロスではなく実際の輻輳に対応するアルゴリズムです。BBR は輻輳制御を根本的に見直すことで、この課題に応えています。まったく新しいパラダイムを用いてゼロからスタートしているのです。

BBR は、どのくらいのペースでネットワークにデータを送り出すかを決めるにあたって、そのネットワークがどれくらいの速さでデータを送り届けているかを考慮します。一定のネットワーク接続におけるネットワークの転送速度とラウンドトリップ時間の最近の測定値を用いて、その接続の帯域幅の上限と最小のラウンドトリップ遅延の両方を含むモデルを構築します。BBR はこのモデルを用いて、データの送信速度とネットワークに流し込むデータ量の上限を常に制御します。

Google Cloud のお客様にとってのメリット

BBR の導入により、従来の輻輳制御アルゴリズムである CUBIC と比べて Google サービス間のスループットは向上し、レイテンシは低くなって、サービスが快適に使えるようになりました。

たとえば YouTube の場合、BBR でネットワークの帯域幅をより効果的に判定、利用するようになったことから、ネットワーク スループットが 4 % も向上しました。また、BBR はネットワーク キューを短く保つので、ラウンドトリップ時間が 33 % も短縮しています。これは、レイテンシに敏感なウェブ ブラウズやチャット、ゲームなどのアプリケーションでは応答が速くなり、遅延が短縮されることを意味します。さらに、パケット ロスに過剰反応しなくなったことで、再バッファリングまでの平均時間が 11 % 長くなっています。これらは全体として、デスクトップやモバイルを問わず、世界中のあらゆるユーザーに大幅な改善をもたらします。

Google は動画再生のユーザー エクスペリエンスを向上させることに長い間こだわり続けてきました。YouTube はすでに高度に最適化されているだけに、こうした数字は特に注目すべきものです。しかも、イテレーションとチューニングを継続して行えばさらに良い結果が得られることが、実験から明らかになっています。




BBR は根本的な部分の改善であり、そのメリットは Google や YouTube にとどまりません。いくつかの合成マイクロベンチマークから、BBR から得られるメリット（必ずしも一般的に注目されるほどの規模ではない）の本質が明らかになっています。

  • スループットの向上 : BBR は、高速長距離リンクでは大幅なスループットの向上を実現します。10 ギガビット イーサネット リンクを備え、パケット ロス率 1 % でラウンドトリップ時間が 100m 秒のパス（たとえばシカゴとベルリン間）にデータを送出するサーバー クラスのコンピュータについて考えてみましょう。この場合、BBR のスループットは、現時点でベストの loss-based 輻輳制御である CUBIC の 2,700 倍になります（CUBIC の 3.3 Mbps に対し、BBR は 9,100 Mbps を超えます）。このようにパケット ロスに強いため、単一の BBR 接続だけでパケット ロスのあるパスをフルに活用できます。この特徴は、単一の接続を使い、使用率の上限を使い切るために複数の TCP 接続を開設するような策を弄する必要がない HTTP/2 には特に合っています。最終的には、高速バックボーンのトラフィックがさらに速くなり、帯域幅が大幅に広がるため、ウェブ ページ、動画、その他のデータのダウンロード時間が短縮されます。
  • レイテンシの低減 : BBR は、ユーザーとインターネットを結ぶラスト ワンマイル ネットワークのレイテンシを大幅に低減します。帯域幅が 10M ビット、ラウンドトリップ時間が 40m 秒の典型的なラスト ワンマイル リンクと、1,000 パケットの典型的なボトルネック バッファについて考えてみましょう。このような環境では、BBR のキューイング遅延は CUBIC の 25 分の 1 に短縮されます（CUBIC の平均ラウンドトリップ時間が 1,090m 秒なのに対し、BBR ではわずか 43m 秒です）。BBR はキューを短縮し、動画閲覧やソフトウェア ダウンロード時のラスト ワンマイル リンクのキューイング遅延を短縮します。そのぶん、ウェブ サーフィン、ビデオ会議、ゲームの応答性は良くなります。このようなバッファブロート抑制能力を考えると、BBR という名前は、“Bottleneck Bandwidth and Round-trip propagation time” だけでなく “BufferBloat Resillience” の略だと言うこともできるでしょう。

GCP では Espresso、Jupiter、Andromeda、gRPC、Maglev、Cloud Bigtable、Cloud Spanner などの Google テクノロジーを絶えず発展させ、強化しています。オープンソースの TCP BBR は、業界をリードするパフォーマンスを生み出した Google の最新イノベーションの一例にすぎません。

ディスカッションに参加したり、最新の BBR 関連ニュースをフォローしたり、BBR に関するトークの動画を見たり、オープンソース BBR の開発やテストに協力したい方は、bbr-dev の公開メール グループにぜひご参加ください。

* この投稿は米国時間 7 月 20 日、Neal Cardwell（Senior Staff Software Engineer）、Yuchung Cheng（Senior Staff Software Engineer）、C. Stephen Gunn（Senior Staff Site Reliability Engineer）、Soheil Hassas Yeganeh（Senior Software Engineer）、Van Jacobson（Research Scientist）、Amin Vahdat（Google Fellow）によって投稿されたもの（投稿はこちら）の抄訳です。
ラベル: