コラム

CTC教育サービス・ホーム　＞　コラム　＞　グーグルのクラウドを支えるテクノロジー　＞　第158回　サーバー内部のネットワーク処理速度の分析（パート2）

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

CTC 教育サービス

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

第158回　サーバー内部のネットワーク処理速度の分析（パート2） (中井悦司) 2023年9月

はじめに

　前回に続いて、2022年に公開された論文「Understanding Host Interconnect Congestion」を紹介します。この論文では、サーバー内部のネットワーク処理速度の分析を行っており、ネットワーク機器の性能が向上する中で、サーバー内部における、NIC（ネットワークインターフェースカード）とメモリー間のデータ転送が新たなボトルネックとなる可能性を指摘しています。今回は、この仮説を検証したベンチマーク結果を紹介します。

検証対象として想定されるボトルネック

　前回の記事で説明したように、この論文では、次の2つをNICとメモリー間のデータ転送のボトルネックと想定しています。

IOMMUによる仮想アドレスと物理アドレスの変換にかかる時間
データバスを経由したデータ書き込み処理がCPUと競合することで発生する遅延

　それぞれの検証結果を順に説明していきます。

IOMMUのボトルネックを検証したベンチマーク

　前回の記事で説明したように、IOMMUは、サーバー仮想化環境などで、仮想マシンにデバイスを接続する際に利用します。したがって多数の仮想マシンが稼働していると、それぞれの仮想マシンごとに物理アドレスと仮想アドレスの変換処理が必要になります。そのため、IOMMUのキャッシュ領域（IOTLB）を多数のプロセスが使用する形になり、キャッシュミスが発生して、処理が遅延する可能性が高くなります。
　この論文では、IOMMUを用いてネットワーク通信を行うプロセス数を増加させることで意図的にIOMMUのキャッシュミスを発生させて、パケットドロップが発生するかを検証しています。図1がその結果になります。

fig01

図1 IOMMUのボトルネックを検証したベンチマーク結果（論文より抜粋）

　ここでは、CPUの処理速度がボトルネックにならないように、1つのCPUコアで1つのプロセスを稼働させており、コア数がプロセス数に対応します。そのため、グラフの横軸がコア数になっています。
　まず、上段のグラフの赤いラインは、ネットワーク通信のスループット（サーバー全体での通信量）を表します。コア数を増やすにつれてスループットが増加していき、8コアの所で仕様上の最大値を達成していますが、その後は逆に減少しています。中段のグラフ（赤いライン）はパケットドロップの量、そして、下段のグラフは、IOMMUにおけるキャッシュミスの発生を表しており、これらを見ると、キャッシュミスに伴う処理遅延でパケットドロップが発生した結果、スループットが減少していると理解できます。青いラインは、IOMMUを使用しない（仮想化機能を使わない）場合の結果で、これからもIOMMUのキャッシュミスがパケットドロップの原因だとはっきりわかります。

データバスのボトルネックを検証したベンチマーク

　前回の記事で説明したように、NICが受け取ったパケットのデータは、PCIeカード上のデータバスを通じてメモリーに書き込まれます。データバスを経由したアクセスは、CPUによるメモリーアクセスでも使用されるため、大量のメモリーアクセスを行うプロセスが稼働していると、パケットデータの書き込みが遅延して、パケットドロップが発生する可能性があります。
　この論文では、メモリー帯域を計測するベンチマークを同時に実行することで、意図的にメモリーアクセスを発生させて、パケットドロップが発生するかを検証しています。図2がその結果になります。

fig02

図2 データバスのボトルネックを検証したベンチマーク結果（論文より抜粋）

　先ほどと同様に、1つのCPUコアで1つのベンチマークを稼働させており、コア数がベンチマークの実行数に対応します。上段のグラフは、棒グラフがメモリーへのアクセス量、折れ線グラフがネットワーク通信のスループットを表します。左の青いグラフはIOMMUを使用しない場合、右の赤いグラフはIOMMUを使用した場合に対応します。いずれの場合も、メモリーアクセスが増加すると、ネットワーク通信のスループットが減少することを示しています。そして、下段のグラフはパケットドロップの量を示しており、IOMMUを使用しない場合でも、メモリーへのアクセス量が増加すると、それに伴うパケットドロップが発生することを示しています。

サーバーアーキテクチャーの改善案

　これらの結果からわかるように、ネットワーク通信のボトルネックは、ネットワーク機器だけではなく、サーバー内部のアーキテクチャーによっても発生しています。ネットワーク機器の通信性能は、数年後には、現在の10倍に達すると予想されていますが、サーバー内部のボトルネックを解消しなければ、サーバーから見た通信性能はこれ以上の増加が望めないということになります。論文の中では、サーバーアーキテクチャーに関する、次のような改善案が提示されています。

IOMMUに代わる、より効率的なメモリー保護の仕組みを導入する
パケットドロップが発生した際は、CPUによるメモリーアクセスを制限する仕組みを導入する
データバスの帯域をデバイスとCPUに平等に振り分ける仕組みを導入する

　Googleのエンジニアは、これまでに、サーバーの通信性能を向上するために、新しい通信プロトコルの提案など、ソフトウェア的な改善に取り組んできましたが、ハードウェアレベルでの改善の必要性を示すという意味で興味深い論文と言えるでしょう。

次回予告

　2022年に公開された論文「Understanding Host Interconnect Congestion」に基づいて、ネットワーク通信におけるサーバー内部のボトルネックに関するベンチマーク結果を紹介しました。
　次回は、マイクロサービスアーキテクチャーのリファクタリングに関する話をお届けます。

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