これから学ぶ人も、資格取得を目指す人も、最適なカリキュラムを選べます。
これから学ぶ人も、資格取得を目指す人も、最適なカリキュラムを選べます。
CTC 教育サービス
[IT研修]注目キーワード Python UiPath(RPA) 最新技術動向 Microsoft Azure Docker Kubernetes
今回は、2013年に公開された論文「B4: Experience with a globally-deployed software defined WAN (PDF)」をもとにして、「B4」と呼ばれる、Googleのデータセンター間を接続するグローバルネットワークについて解説を行います。
はじめに、Googleのグローバルネットワークの全体像を整理しておきます。図1は、2016年に公開された「Evolve or Die: High-Availability Design Principles Drawn from Google's Network Infrastructure」という論文からの抜粋です。
図1 Googleのグローバルネットワーク（論文より抜粋）
前回までに解説したように、各データセンターには、Closトポロジー型のクラスターネットワークが用意されています。図1のCAR（Cluster Aggregation Router）は、クラスターとグローバルネットワークを接続するためのスイッチで、B2、および、B4の2種類のグローバルネットワークに接続されています。まず、B2は、ISPを介してインターネットと相互接続するためのグローバルネットワークです。こちらは、他のネットワークとの相互接続性を確保するために、一般的なベンダー製品のネットワーク機器が使用されています。一方、B4は、データセンター内のアプリケーションが、相互にデータをやり取りするための内部ネットワークです。こちらは、データセンターネットワークと同様に、独自設計のネットワークスイッチをソフトウェアで制御する仕組みが実装されており、この後で説明するように、サイト間のネットワークトポロジーとアプリケーションの種類（トラフィックの優先度）に応じて通信経路を最適化する、トラフィックエンジニアリングの仕組みが導入されています。
B4のアーキテクチャーの全体像は、図2のようになります。少し複雑に見えますが、楕円形で囲まれた「OFA Switch」のかたまりが、図1のB4BR（B4 Boarder Router）に対応します。複数のスイッチが連携してルーターの機能を提供しており、内部的にパケットの負荷分散を行っていると考えてください。サイト間の接続においても、複数のファイバーケーブルのリンクにまたがった負荷分散が行われます。
図2 B4のアーキテクチャー（論文より抜粋）
また、BGPをご存知の方向けに補足すると、データセンター内のそれぞれのクラスターは独立したAS（Autonomous System）になっており、一方、クラスター間を接続するB4のWAN全体は、これらを相互接続する単一のASになります。そのため、B4からクラスターに対しては、eBGPで経路情報が伝達され、サイト間では、iBGPで経路情報が伝達されることになります。図2の各OFA SwitchではOpenFlowエージェントが動作しており、各サイトのOpenFlowコントローラーによって経路が制御されるのですが、上位のコントローラーからの指示がない場合は、デフォルトでSPF（Shortest Path Forwarding）による経路選択が行われます。この後で説明するトラフィックエンジニアリングの仕組みに何らかの問題が発生した場合は、通常のルーティング処理にフォールバックできるようになっているわけです。
続いて、B4のトラフィックエンジニアリングの仕組みを説明します。はじめに、複数のアプリケーションのトラフィックをいくつかのFG（フローグループ）に分類して、それぞれのグループの優先度を定義します。これは、それぞれのアプリケーションの開発者からのリクエストに応じて、静的な割り当てを行います。B4に流れるパケットは、すべて、Googleが開発したアプリケーションからのトラフィックなので、このような割り当てが可能になります。
次に、サイト間のネットワークトポロジーに基いて、2つのサイトを相互接続する複数の経路をオーバーレイ方式（IP Encapsulation）のトンネルとして定義します。図3(a)の例では、サイトAからサイトBに接続する際に、「A→B」という経路に加えて、サイトCを経由した「A→C→B」という経路が個別のトンネルとして定義されています。このようなトンネルは、図2の上部にある「Central TE Server」（トラフィックエンジニアリング・サーバー）が、各サイトのネットワークコントローラーから経路情報を収集して、動的に定義を行っていきます。この時、サイト間の物理的な帯域情報も収集することで、それぞれのトンネルが利用可能なネットワーク帯域も計算されます。
図3 トンネルグループの割り当て例（論文より抜粋）
そして最後に、TE Serverは、それぞれのフローグループに対して、複数のトンネルを割り当てます。この割り当ては、TG（トンネルグループ）と呼ばれ、アプリケーションからの帯域要求に応じて動的な割り当てが行われます。たとえば、図3(a)の例では、フローグループ「FG1」に属するアプリケーション群は、サイトAからサイトBに対して、合計で20Gbpsの帯域を要求しています。これに対して、「A→B」と「A→C→B」の2つのトンネルが割り当てられています。それぞれのトンネルは10Gbpsの帯域を持っているので、これら2つの経路を負荷分散して使用することで、要求通りの帯域が割り当てられることになります。
一方、フローグループ「FG2」は、サイトAからサイトCに対して、10GBpsの帯域を要求していますが、こちらには、「A→D→C」というトンネルが割り当てられています。このトンネルの帯域は5Gbpsですので、こちらは要求通りの割り当てにはなっていません。これは、FG1の方が、FG2よりも高い優先度を持っていることに起因します。
ここで、たとえば、FG1のアプリケーション群における帯域要求の合計が、10Gbpsに減少したとします。すると、TE Serverは、トンネルグループの設定を図3(b)に変更します。この場合、FG1の帯域要求は、「A→B」の経路だけで満たすことができますので、「A→C」の経路をFG2に割り当てることで、FG2の帯域要求も満たされるようになります。
このような、TE Serverが決定したトンネルグループの割り当て情報は、TE Serverから、各サイトのネットワークコントローラーに通知されます。そして、ネットワークコントローラー内のOpenFlowコントローラーは、OpenFlowプロトコルを用いて、各OFA Switchにおけるトンネルの設定やトンネルを経由したパケット転送の処理を行うという流れになります。サイト間の物理的な経路情報は、BGPによって収集するわけですが、その上に論理的なトンネルを構成することで、より柔軟な経路設計を行うという仕組みになっています。
ここまでの説明から分かるように、この仕組みにおいては、優先度の低いフローグループに対しては、必ずしも要求通りの帯域が割り当てられるとは限りません。それぞれのアプリケーションの開発者は、非同期のデータコピーなど、リアルタイム性が低く、一定量のパケットロスが受け入れ可能な通信に対しては、低い優先度を割り当てます。一方、リアルタイム性が高く、パケットロスが許容できない通信については、高い優先度を割り当てます。これにより、ネットワーク帯域の利用率を安全に高めることが可能になります。
一般に、ネットワーク回線のコスト効率を高める上では、回線の利用率を上げることが効果的ですが、単純に利用率を上げると、当然ながらパケットロスが発生する可能性も高くなります。先に説明したトラフィックエンジニアリングの仕組みでは、次の2つのことをうまく実現しているというわけです。
冒頭の論文には、ある特定の回線の利用率とパケットロスの発生率について、図4のグラフが掲載されています。(a)のグラフを見ると、継続的に100%近い利用率が実現されていることがわかります。また、(b)のグラフを見ると、高い優先度のパケットは全体の10%程度で、これらに対するパケットロスは、ほぼ0になっています。一方、低い優先度のパケットについては、一定量のパケットロスが継続的に発生しています。
図4 サイト間接続の利用率とパケットロス
今回は、Googleのグローバルネットワークの仕組みを紹介しました。最後に紹介したトラフィックエンジニアリングの効果を見ると、単純にすべてのパケットロスをゼロにするという過剰品質を求めるのではなく、パケットロスが許容される通信を明確に分離することで、回線全体の利用率を高めるという、合理的な発想が感じられます。ちなみに、一般的なWAN回線では、パケットロスを防止するために帯域に十分な余裕を持たせるため、回線の利用率は30～40%程度に留まっているとの説明が、冒頭の論文に記載されています。
次回は、このようなグローバルネットワークの信頼性に関する論文を紹介したいと思います。
Disclaimer：この記事は個人的なものです｡ここで述べられていることは私の個人的な意見に基づくものであり、私の雇用者には関係はありません｡
[IT研修]注目キーワード Python UiPath(RPA) 最新技術動向 Microsoft Azure Docker Kubernetes
