コラム

CTC教育サービス・ホーム　＞　コラム　＞　グーグルのクラウドを支えるテクノロジー　＞　第75回　VPCネットワークを支える仮想ネットワーク基盤：Andromeda（パート3）

グーグルのクラウドを支えるテクノロジー

CTC 教育サービス

[IT研修]注目キーワード Python UiPath(RPA) 最新技術動向 Microsoft Azure Docker Kubernetes

第75回　VPCネットワークを支える仮想ネットワーク基盤：Andromeda（パート3） (中井悦司) 2020年2月

はじめに

　前回に引き続き、2018年に公開された論文「Andromeda: Performance, Isolation, and Velocity at Scale in Cloud Network Virtualization」を元にして、Google Cloud Platform（GCP）のVirtual Private Cloud（VPC）ネットワークを支える仮想ネットワーク基盤を紹介します。今回は、Andromedaによる性能向上を表すデータを紹介します。

データプレーンの性能向上

　はじめに、データプレーンの性能向上を表すデータとして、論文内で図1のグラフが紹介されています。これを見ると、Andromeda2.0の導入により、スループット、レイテンシー共に2倍以上の性能向上が実現されています。

fig01

図1 データプレーンの性能向上データ（論文より抜粋）

　Andromeda2.0における主要な変更として、OSのネットワークスタックをバイパスして、データプレーンにおけるパケット処理をすべてユーザースペースで実装するモデルに切り替えたことが説明されています。物理NICからのパケット受信については、専用に予約されたCPU coreが「busy-polling」を行う仕組みが採用されています。また、この段階では、VMの仮想NICとのパケットのやり取りは、VMM（仮想化ハイパーバイザー）が仲介していましたが、その後、Andromeda2.1では、メモリ・リングを介して、データプレーンが直接にパケットをやり取りするモデルに更新されました。さらに、Andromeda2.2では、Intel QuickData DMA Engineと呼ばれる機構を用いて、大きなパケットデータのコピーをCPUハードウェアにオフロードする機能が追加されました。
　OSレイヤーをバイパスすることでネットワーク処理の性能向上を図るというアイデアは、2010年にIntelが公開したDPDK（Data Plane Development Kit）により広く知られるようになりました。このアイデアが現実のサービスに有効活用できることが、実証された事例と言えるでしょう。

コントロールプレーンのスケーラビリティ

　Andromedaの特徴として、VMホスト上のフローテーブルで処理できないパケットは、外部のソフトウェアスイッチ（Hoverboard）に転送して、ルーティング処理を移譲するという仕組みがあります。これは、新しいVMを仮想ネットワークに接続する際や仮想ネットワークの構成変更を行う際に、準備にかかる時間を大きく短縮する効果があります。すべてのパケット転送処理をフローテーブルで行う「preprogrammedモデル」の場合、VMがn台あれば、単純計算で、n×n通りの組み合わせについての処理をフローテーブルに登録する必要があります。このため、Andromedaの導入以前は、1つの仮想ネットワークに接続できるVM数は2000台程度が限界で、新規VMの接続処理に3秒以上かかることもありました。
　一方、Hoverboardモデルの場合、VM接続直後のルーティング処理はHoverboradが持つ既存の設定に任せることができます。VM起動後に、優先度の高いパケットについては、フローテーブルにルーティング情報を登録してパケットの経路を最適化していくことができます。これにより、新規VMの接続処理にかかる時間は、中央値で184ミリ秒、99パーセンタイルでも576ミリ秒と大きく短縮されました。図2は、多数のVMを同時に新規接続したとして、仮想ネットワーク側の準備にかかる時間を示したものです。Preprogrammedモデルでは、VM数の増加に伴って処理時間が顕著に長くなりますが、Hoverboardモデルでは、そのような問題が発生しないことがわかります。

fig02

図2 PreprogrammedモデルとHoverboardモデルの性能比較

　また、Hoverboardモデルがうまく機能する前提として、仮想ネットワーク上のネットワーク通信の大部分は高速な処理を要さず、一部の優先度の高いパケットのみをホスト上のフローテーブルで処理することでユーザーが期待する性能要件を満たせるだろいうとう考え方があります。実際に仮想ネットワーク上の通信状況をモニタリングしたところ、次のような事実がわかったことが論文内で紹介されています。

(1) 84%のVMペアは通信を行わない（通信を行うVMペアは16%）
(2) 98%の通信は、20kbps以下の通信速度

　Preprogrammedモデルの場合、すべてのVMペアに対するルーティング情報を事前にフローテーブルに登録する必要があります。この場合、実際に使用されるルーティング情報はごく一部に限られるので、無駄が多い実装であることが(1)のデータからも理解できます。また、(2)のデータからは、たとえば、20kbpsの性能をHoverboradで実現できれば、ホスト上のフローテーブルは残りの2%のパケットの処理に専念できることがわかります。

次回予告

　今回は、2018年に公開された論文「Andromeda: Performance, Isolation, and Velocity at Scale in Cloud Network Virtualization」を元にして、GCPのVPCネットワークを支える仮想ネットワーク基盤であるAndromedaが、どのような性能向上を実現したかを紹介しました。次回は少し趣向を変えて、2003年の歴史的な論文を紹介したいと思います。

Disclaimer：この記事は個人的なものです｡ここで述べられていることは私の個人的な意見に基づくものであり、私の雇用者には関係はありません｡