視点: ソフトウェア定義トラフィックエンジニアリング

本章を通して考えてきた問題は「利用可能なネットワークの帯域をエンドツーエンドフローの集合にどのように割り当てるか」というものだった。TCP の輻輳制御であれ、IntServ であれ、DiffServ であれ、この問題を考えるとき割り当てようとしている内部ネットワークの帯域は固定されていると仮定されていた: サイト A とサイト B を結ぶ 1 Gbps リンクはいつでも 1 Gbps で変化せず、考えてきたアルゴリズムは競合し合うユーザー間でその 1 Gbps をどのように共有すべきかを示すものだった。この仮定が成り立たなかったらどうなるだろうか？ 容量を「すぐに」追加できて、1 Gbps リンクを 10 Gbps リンクにアップグレードしたり、直接は結ばれていないサイトの間に新しいリンクを追加したりできたとしたら、どうするべきだろうか？

この条件設定は現実的なものであり、この話題はトラフィックエンジニアリング (traffic engineering) と呼ばれる。この用語はコンピューターネットワークが誕生して間もないころ、ネットワーク運用者がネットワークに流れるトラフィックの負荷を解析し、慢性的に負荷が高くなっているリンクに容量を追加するといったメンテナンスを定期的に行っていた時代から使われてきた。この時代、リンクに容量を追加する判断は軽々しく下せるものではなかった: 海底ケーブルの敷設や衛星の打ち上げが絡むために膨大な時間と資金が必要であり、観察された利用率のトレンドがノイズでないことを慎重に見極めなければならなかった。

しかし DWDM や MPLS といった技術の誕生により、光ファイバーケーブルを新たに敷設せずとも、追加の波長を有効化したり、サイト間で新たに回線を確立したりすることでトラフィックの調整が可能になった (前者のケースで、サイト同士が単一の光ファイバーケーブルで直接に接続されている必要はない。例えば、ボストンとサンフランシスコを結ぶ波長がシカゴとデンバーで ROADM を通っていたとしても、L2/L3 ネットワークにおけるトポロジーの視点から見るときボストンとサンフランシスコはダイレクトリンクで接続される)。これらの技術によってネットワークの変更が適用されるまでの時間 (time-to-availability) は大きく削減されたものの、ハードウェアの再設定には依然として人間の介入が必要であり、ここで「すぐに」は (数週間ではないにしても) 数日を意味する。結局、三枚複写の申込書を書かなければならない！

しかし、本書で何度も繰り返し見てきたように、適切なプログラム的インターフェースを提供できれば、問題の解決にソフトウェアが利用できるようになり、実用上の全ての場合で「すぐに」が本当の意味で「瞬時に」になり得る。これはクラウドプロバイダが自社のデータセンターを相互接続するために構築するプライベートバックボーンで行っていることである。例えば、Google は B4 と呼ばれるプライベート WAN の詳細を公開している。B4 は全体がホワイトボックススイッチと SDN から構成される。ノード間帯域の調整に波長の追加と除去を利用せず、ECMP (Equal-Cost Multipath) と呼ばれるテクニックを使ってエンドツーエンドのトンネルを動的に構築する。ECMP は第 4.4 節で説明した CSPF の代わりとなるテクニックであり、CSPF と同様の柔軟性を提供する。

その後、トラフィックエンジニアリングの制御プログラムが様々なアプリケーションクラスからの要求に従って適切にネットワークのプロビジョニング (設定) を行う。B4 には次の三つのクラスが存在する:

1. 可用性と耐久性を高めるためにリモートのデータセンターへユーザーデータをコピーする。
2. 分散データを利用する計算のためにリモートのストレージにアクセスする。
3. 複数のデータセンター間で状態を同期するために大規模なデータをプッシュする。

これらのクラスはデータ量に関して昇順、遅延に対する感度に関して降順、全体的な優先度に関して降順に並んでいる。例えば、ユーザーデータは B4 においてデータ量が最も少なく、最も遅延に敏感であり、最も高い優先度を持つ。

ネットワークの設定を中央で一括して行うことで、Google は回線の利用率を 100% 近くまで向上させたと報告している。これは SDN が標榜する利点の一つである。典型的な WAN 回線はトラフィックのバーストやリンク/スイッチの障害に備えて平均利用率が 30%-40% 程度となるようにプロビジョニングされるので、それと比べると二倍から三倍の効率が達成されている。リソースの割り当てをネットワーク全体で一括して制御できれば、ネットワークの利用率を理想的な最大値にずっと近づけることができる。なお、ネットワーク内のリンクのプロビジョニングはアプリケーションクラスという粗い種別に基づいて行われることに注目してほしい。B4 がある場合でも TCP の輻輳制御は接続ごとに実行され、ルーティングの判断は B4 トポロジーの上で行われる (余談: B4 はプライベート WAN なので、Google は BBR といった独自の輻輳制御アルゴリズムを好きに実行できる。そのとき他のアルゴリズムを採用するフローから不公平に帯域を奪うことを心配する必要はない)。

B4 のようなシステムから学べる教訓の一つは、トラフィックエンジニアリングと輻輳制御の境界 (およびトラフィックエンジニアリングとルーティングの境界) が曖昧になっている事実である。どれもリソースの割り当てという一般的な問題を解決するための仕組みであり、ある仕組みがカバーする範囲が細かく決まっているわけではない。簡単に言えば、層がハードウェアではなくソフトウェアで実装されるようになると層の境界は柔らかく (動かしやすく) なる。これは近年ますます標準となっている。