いま知っておくべきWebサービスのための高速ネットワーク技術（後編）：ボトルネックの解決が新たなボトルネックを顕在化（1/2 ページ）
前編に続き、10GbEやInfinibandといった高速ネットワーク技術のパフォーマンスを探るとともに、次世代Webサービス構築にどのように適用できるのかを考察していきます。
より身近になってきた高速ネットワーク技術
2012年8月に「いま知っておくべきWebサービスのための高速ネットワーク技術（前編）」を公開してから、6カ月が経ちました。この場をお借りして、読者の皆さまに遅筆をお詫び申し上げます。
この間、比較的高価だった10ギガビットイーサネット（GbE）Network Interface Card（NIC）やスイッチが、さらに手の届く価格帯まで近づいてきたことを踏まえて、後編をお送りします。
【関連記事】
いま知っておくべきWebサービスのための高速ネットワーク技術（前編）
http://www.atmarkit.co.jp/ait/articles/1208/01/news146.html
高速データ転送性能を理解する
いままで使っていた1000BASE-TXでは、ネットワーク接続がボトルネックとなっており、ディスクやメモリの帯域や速度が気になることはなかったでしょう。しかし10/40GbE、Infiniband FDR 56Gbit/sなどの高速ネットワーク技術を導入することによって、これらのバランスが一気に崩れていきます。
この点をしっかりと理解するために、ここでは高速ネットワーク技術について実用的な計測方法を踏まえて解説します。
この実測環境では、サーバのメモリ上に構成したRAMDISKに対して、高速ネットワーク経由でファイルの読み書きを行っています（図1）。
具体的には、1/10/40GbEとInfiniband FDR 56Gbit/sの2種類のネットワークを用いて、
- TCP/IP越しにHTTP接続してデータを取得するモデル
- TCP/IPを用いず、RDMA（Remote Memory Direct Access）によるInfiniband接続経由でデータを送信するモデル
の2つで実測を行いました。TCP/IP環境ではthttpdとwgetを、RDMA環境ではlibrdmacmに付属されるrcopyを計測に使っています。
結果としては、1/10/40/56Gbit/sと、ネットワーク帯域が増加するにつれて実効転送容量が増えています（図2）。前編での性能評価はあくまでパケット処理能力を調べるために行いましたが、実際にアプリケーション越しで送受信を行うと、データ転送は低下します。
ここでは、1333MHz DDR3 DIMM（DRAM）を使ったRAMDISK上でデータを読み書きすることで、ディスクによるボトルネックも排除しています。これにより高速ネットワーク接続の純粋な性能が分かります。
実測結果の中でも興味深いのが、Infiniband環境のRDMAデータ転送性能です。10/40GbEに比べても桁違いに性能が高く、また同じFDR 56Gbit/s IP over Infiniband接続に比べても性能向上が見てとれます。RDMAデータ転送では余計なTCP/IP処理などが省かれるため、より効率的にデータ転送が可能になることが分かります。
データ転送計測の手順を以下にまとめていますので、興味がある方はぜひお試しください。
サーバとクライアントにおける事前設定 SERVER# mount tmpfs /ram -t tmpfs ; cd /ram SERVER# dd if=/dev/zero of=/ram/DATA bs=1G count=15 CLIENT# mount tmpfs /ram -t tmpfs ; cd /ram 1) Ethernet TCP/IP データ転送計測の手順 SERVER# taskset 1 thttpd -d /ram CLIENT# taskset 1 time wget http://X.X.X.X/DATA 2) InfiniBand RDMA データ転送計測の手順 SERVER# taskset 1 rcopy CLIENT# taskset 1 time rcopy /ram/DATA X.X.X.X:/ram/DATA
簡易的な実測結果ではありますが、自らが構築するシステムに必要なデータ転送容量はどれぐらいであり、最適な高速ネットワークはどれかを選ぶ指標としてお使いいただければと思います。
高速ネットワーク技術を理解する
次に、高速ネットワークの接続方法について見ていきましょう。
1000BASE-TXではおなじみの「RJ-45コネクタ」ですが、10/40GbEやInfiniband接続では使われていません。SFP+やQSFP+といった大型コネクタに太いメタルケーブルや光ファイバーを接続して高速データ転送を可能にしています（写真1）。
10GbEと40GbEには、互換性を保つ意味で「QSFP+-to-SFP+アダプタ」も用意されており、高い運用性が担保されているといえるでしょう。
Infiniband QDR 40Gbit/sやFDR 56Gbit/s接続も基本的には、QSFPによるコネクタが採用されています。ただし、QDR 40Gbit/s InfinibandケーブルをFDR 56Gbit/sのケーブルとして利用できない点には注意が必要です。
なお、メラノックス（Mellanox）のInfiniband HCA（Host Channel Adapter）/NIC兼用アダプタ（写真2）に限った話ですが、このアダプタでは、1枚で10/40GbEとQDR 40Gbit/s FDR 56Gbit/sを切り替えながら使うことができます。前述のデータ転送計測にもこの機能を用い、まったく同じ測定環境で、10Gbit/sから56Gbit/sまで、イーサネットとInfinibandを切り替えて計測しました。
イーサネット／Infiniband接続の切り替え方法は以下のとおりです。基本的には、アダプタを搭載したOS上からカード設定を書き換えることによって実現します。この機能を実現するために、メラノックスのアダプタ向けドライバにはもともとイーサネットとInfiniband双方のカーネルモジュールが搭載されていますので、切り替えにはさほど手間取りません。
# connectx_port_config ※アダプタが現在有効になっている接続形態を表示する ConnectX PCI devices : |----------------------------| | 1 0000:01:00.0 | |----------------------------| Before port change: eth eth
|----------------------------| ※アダプタに設定したい接続形態を選択できる | Possible port modes: | | 1: Infiniband | | 2: Ethernet | | 3: AutoSense | |----------------------------| Select mode for port 1 (1,2,3):
次に、アダプタの接続確認の手順を見ていきましょう。イーサネットとInfinibandではコマンドが異なる点に注意が必要です。
# ibstatus ※Infiniband HCA接続確認の手順
Infiniband device 'mlx4_0' port 1 status:
default gid: fe80:0000:0000:0000:0002:c903:0034:2121
base lid: 0x3
sm lid: 0x4
state: 4: ACTIVE
phys state: 5: LinkUp
rate: 56 Gb/sec (4X FDR)
link_layer: InfiniBand
# ethtool eth3 ※40G Ethernet NIC接続確認の手順
:
Speed: 40000Mb/s
# ethtool eth3 ※10G Ethernet NIC接続確認の手順
:
Speed: 10000Mb/s
10/40G イーサネット NICの接続確認に使っている「ethtool」はLinux kernel 3.7-rc7の最新版を使っています。旧来のethtoolでは40GbEが正しく表示できない点にも注意が必要です。
さらに重要なのが、PCI Express接続確認です。Infiniband FDR 56Gbit/s HCAではPCI Express 3.0が使われており、BIOS設定やOSレベルでこれが正しく動作していなければ、データ転送性能に大きく影響を及ぼします。具体的には、最新版「pciutils」に付属するlspciコマンドを用いてアダプタ単位でのリンク状況を見ます。PCI Express 3.0で接続したInfiniband HCAが「Speed 8GT/s, Width x8」などと見えていれば、正常に動作しています。
# lspci -vv
01:00.0 Network controller: Mellanox Technologies MT27500 Family [ConnectX-3]
Subsystem: Mellanox Technologies Device 0050
:
LnkCap: Port #8, Speed 8GT/s, Width x8, ASPM L0s, Latency L0 unlimited, L1 unlimited
:
LnkSta: Speed 8GT/s, Width x8, TrErr- Train- SlotClk+ DLActive- BWMgmt- ABWMgmt-
イーサネットとInfinibandのアダプタ単位でデータ転送状況を確認したい場合には、「vnstat」や「ibdatacounters」を用いるとよいでしょう。ただし、vnstatはイーサネットとInfinibandの双方に対応していますが、ibdatacountersはInfinibandにのみ対応しています。
# vnstat -i eth3 -l Monitoring eth0... (press CTRL-C to stop) rx: 7.91 Gbit/s 523266 p/s tx: 9.82 Mbit/s 28584 p/s # ibdatacounters # Port counters: Lid 3 port 1 (CapMask: 0x1400) PortRcvData:.........................4294967295 PortRcvPkts:.........................29113741 :
自らが構築する高速ネットワーク環境に最適なツールやコマンドを用いることで、安定したシステム運用が可能となるでしょう。
パケット処理の限界を理解する
多くの場合、高速ネットワーク技術を論じる時には、データ転送容量にのみ視点が行ってしまいがちです。しかしWebサービスを考えた時、今後も増大するモバイル端末からの細かいパケットを処理するための性能も重要になってくるでしょう。
ただ、現在のところインターネット上から直接Infiniband接続環境へパケットが到達することはありませんので、ここではイーサネットのパケット処理限界について見ていきます。
今回の実測ではOSとパケットドライバ、さらに10/40GbEの違いを簡略化して調べています。いずれの計測も、外部のトラフィック生成機器から、MTUサイズ64バイトの細かいパケットを大量に受け、それをどれだけ取りこぼしなく受信できていたかを計測しています。OS環境としては、netmapと呼ばれる高速パケット処理ドライバを組み込んだFreeBSDとLinuxを10/40GbEで比較しました（図3）。
ここから読み解ける結果として、「OSや10/40GbEの違いにかかわりなく、3〜4Mpps（Million Packet/sec）付近に処理限界が偏っている」という点が推測されました。計測環境および計測方法によっても変化があるかとは思いますが、「おおよそ、これぐらいが限界」というアタリを付けるには十分な実測結果ではないかと思います。
Copyright © ITmedia, Inc. All Rights Reserved.