はじめに
これは手抜き記事です。動画見て面白かったのでそれを日本語に起こしただけ。個人的にあ、これはただの宣伝だな、と思ったところは省いてます。
元動画はこちら
Life of a photon through global load balancing (Networking End to End)
字幕起こし
前置き
多くの人にとって、宇宙で最も大きな謎の1つは、Googleが世界で1秒未満で何十億もの猫の画像結果を返す方法です。そこで、私たちがどうやってそれを実現しているのかを説明するために、友人のユーリをここに連れてきました。
インターネットにはこうした検索を高速化するための最適化手法がたくさんありますが、Googleのグローバルアーキテクチャには独自の「秘伝のタレ」があり、それを使うことであなたが知る速度と精度を実現することができます。これにより、多くの顧客や企業は、そのパフォーマンスを独自のニーズに活用する方法を求められます。
Googleにおけるグローバルネットワークの仕組み
さて、Googleは過去20年間、世界で最大かつ最速の光ファイバーネットワークの1つを構築し、Google CloudとGoogle独自のサービスを支えてきました(独自のサービスとは、GmailやYouTubeなどを指します)。そして、このネットワークは過去6年間で15倍に成長し、毎秒600兆ものビットを陸上や海上を通すことによって、1日10億人以上のユーザーにサービスを提供しています。
このネットワークを構築するために、Googleは長年の研究を行わなければなりませんでした。その驚くべき技術的成果の一部は、ホワイトペーパーとしてコミュニティに還元しています。
しかし、私たちは自分自身に先んじています。このテクノロジーの大きさを理解するには、まずスコープを小さくして、Googleのネットワークを介して実行される単一の光子の観点からインターネットがどのように機能するかを見てみましょう。まず、最新の猫ファッションのトレンドを提供する最新のECサイトをGoogleクラウドに作成したとします。また、シンガポールには、新しいサイトをテストし、デバイスから猫の冬服を購入するリクエストを送信するユーザーがいます。
ECサイトを例に用いたリクエストの流れ
ユーザーが持つデバイスからのリクエストはまず最初にISP到達し、宛先がGoogleサーバーであることを認識します。さらに、探せる範囲で最も近いGoogleフロントエンドサーバー(GFE)にリクエストを送信します。これらのGFEは、Googleのグローバルネットワークの端に位置し、複数の拠点を持っています。どうしてでしょうか。それは、リオデジャネイロ、チューリッヒ、シンガポールなど、世界中に存在するユーザーに対してできるだけ近くから情報を提供できるようにするためです。
この時点から、Googleの技術的な「魔法」が通信を引き継ぎます。リクエストが最初に行うことは、Google Cloudのソフトウェア定義のグローバルロードバランサーにぶつかることです。このロードバランサーは、HTTP/HTTPSトラフィックをバックエンドに分散して、スケーラブルな方法で負荷を管理および分散する役割を果たします。最良のシナリオでは、シンガポールデータセンターで実行されているVMにソフトウェアをデプロイしました。この場合、リクエストが処理され、データがユーザーに返されます。
しかし、シンガポールに最も近いバックエンドインスタンスグループが利用できない、もしくはこの地域にVMをまだデプロイしていないとしましょう。このときユーザーのリクエストは、米国東部地域に置かれた実行中の他のVMにシームレスに送信されます。グローバルL7ロードバランサーの優れている点は、開発者が手を煩わせることなく、世界中の異なる地域にルーティングできることです。そして、設定はUIで数回クリックするだけです。バックエンドがダウンした場合でも通信の向き先が指定できる単一のエニーキャストIPを提供します。
Googleが持つグローバルロードバランサーの仕組み
L7ロードバランサーにこれを行わせることができるのは、すべての負荷分散がハードウェアではなくソフトウェアで実行されるからです。バックエンドのセットから重み付けされた選択を実行し、正常に表示されないか接続が飽和しているバックエンドをスキップします。これは、リージョンアルゴリズムによるウォーターフォールと呼ばれますこれについては、他の動画シリーズ「Get Cooking in Cloud」で詳細に説明します。これらのGFEを介してトラフィックがプロキシされ、私達の「猫Webサーバー」を実行している選択されたバックエンドにクエリが転送されます。
現在、シンガポールのユーザーがUS-EastのVMからデータをリクエストするシナリオでは、GFEはアジア太平洋地域から米国までの海底光ファイバーケーブルを介してリクエストを送信し、Google Cloudのさまざまな地域を接続します。これらのファイバーネットワークは、数千キロメートルにも及ぶリージョン間を接続します。日常生活においてケーブルの上を通過していたとしても気づかないと思いますが、これらのケーブルは地下にあり、線路に沿って、電柱を越えて、ときには山脈を越えることもあります。速度について疑問がある場合、光子は光ファイバの速度で移動します。そして、その速度で、私たちの光子は、ネットワーク全体で毎秒200万枚以上の写真と8000のYouTubeビデオを運ぶことができます。
次にどうなるかはもう少し待ってください。L7ロードバランサーが持っているエニーキャストIPには、関連する転送ルールが付属しています。この転送ルールは、トラフィックをターゲットプロキシに転送します。この時点でターゲットプロキシはクライアントセッションを終端します。ホストおよびパスルールなどのURLマップの構成があり、トラフィックは米国東部リージョンのVM上の正しいバックエンドサービスにルーティングされます。
バックエンドサーバーは、各バックエンドの容量と正常性をチェックし、最も利用可能で正常なバックエンドにトラフィックを送信します。次に、ショッピングデータを送り返します。GFEは応答をキャッシュし、ユーザーに転送します。
そして、これは、バックエンドが過負荷または不健康な場合でも、ユーザーに最も近いGoogle Cloudのグローカルに広がる領域から選択することにより、待ち時間を最適化する方法です。また、Google CDNによる負荷分散を活用し、ユーザーの近くでコンテンツをキャッシュすることも可能です。
大陸を超える通信の信号の扱い
ここで話を少し戻します。コンテンツがバックエンドからユーザーに送り返されるときに何が起こるかについてもう少し詳細に議論しなければ、私たちは失望するでしょう。応答がVMからGFEに返されると、光伝送機器に接続されているサーバーから光子が送信されます。これらは、赤外線レーザーを使用して、ファイバーネットワークを介して信号を送信します。典型的なケーブルには、数百本の光ファイバーがあり、それぞれが人間の髪の毛の直径のガラスでできています。そして、テラバイト容量の信号を送信できます。その後、光子は外部のケーブルに束ねられたGoogleデータセンターのファイバーを離れます。
しかし、私たちは必然的に問題に直面します。光子がケーブルを伝わると、減衰と呼ばれる強度が減少します。たとえば、Googleの研究論文の1つにおいて、光信号が3,200キロメートルを通過するときに何が起こるかを実証しました。グラフを見ると、信号の相対電力レベルが減少していることがわかります。それでは、何千キロも離れた地域間で、どのようにして光子を行き来させるのでしょうか？
この減衰を抑えるために、ケーブルに沿って光増幅器を配置し、何百ものケーブルを経路上に配置します。増幅器は長距離にわたって信号を増加させるため、光子は目的地に到達できます。
光子の旅は最終的にシンガポールに戻ります。地下に敷かれたファイバーケーブルに沿って移動し、空中に張り巡らされ、途中で増幅されました。そのすべてはわずか数ミリ秒で起こります。現在、当社のファイバーネットワークは5大陸のGoogle Cloud地域に接続しています。過去10年間、Googleは購入とリースを組み合わせることで、世界中にファイバーネットワークを拡大してきました。しかし、これはほんの始まりに過ぎません。私たちの将来のクラウド地域をサポートするために、開発中の多くのものがあります。
