いま知っておくべきWebサービスのための高速ネットワーク技術（後編）：ボトルネックの解決が新たなボトルネックを顕在化（2/2 ページ）

» 2013年02月01日 18時00分公開

[松本直人（さくらインターネット研究所　上級研究員），＠IT]

高速ネットワーク技術の適用領域

　ここまで、高速ネットワーク技術の特性について見てきました。これから高速ネットワーク技術を用いてWebサービスを構築する際の、現実的な解を探ってみましょう。

　まずは、次のようなシナリオが考えられます。インターネット経由のトラフィックは、従来どおりに1000BASE-TXや帯域を太くした10GbEで受け、データベースやストレージ、ファイルサーバなどの接続に10/40GbEやInfinibandを用いるというものです。

　特に、ストレージやデータベースを中心としたバックエンドネットワークでは、SSDなど高速な半導体ディスクの搭載によって、高速なネットワーク接続が求められつつあります。安定的なシステム構築・運用を実現していくという意味でも、やはり高速ネットワーク技術が必要なのです（図4）。

図4　高速ネットワークの適用シナリオ

　次に頭に浮かぶのは、「どの高速ネットワーク技術を選ぶべきか？」という疑問でしょう。

　その答えは、スイッチやアダプタの価格情勢といった市場を取り巻く環境や、システムエンジニアのスキルに合わせて変化していくことでしょう。今後のシステム構築・運用の選択肢を広げるという意味でも、システムエンジニアには多様な高速ネットワーク技術への理解度も求められていくことでしょう。

性能測定の注意点

　高速ネットワーク技術によって、いままで体験したことがなかった現象にも直面します。1000BASE-TXから10/40/56Gbit/sへと、一気に高速なネットワーク環境に移行することで、アプリケーションに内在していたボトルネックがあぶり出されてくるのです。ここではその一例を紹介しましょう。

　もっとも簡易なネットワーク性能測定を行う時に用いられるのが、nc（netcat）コマンドです。前述のさまざまな高速ネットワーク計測と同じく、この例でも、DRAM上にRAMDISK環境を構築してデータ転送を行い、ncで計測を行いました。

　しかし結果として、10/40/56Gbit/sとネットワーク帯域が変化しているにもかかわらず、その性能に頭打ちが見られています（図5）。現在、読者の皆さんが使っているWebサービス向けアプリケーションにも同様の問題が潜んでいる可能性もあります。計測や評価方法、そして問題解決には十分な注意が必要です。

図5　アプリケーションのボトルネックに遮られ、性能が出ない

SERVER#  nc -l 12345 | dd of=/ram/DATA               ※サーバ待ち受け側設定
CLIENT#  dd if=/dev/zero of=/ram/DATA bs=1G count=15 ※クライアント送信側設定
CLIENT# time dd if=/ram/DATA | nc X.X.X.X 12345

　特にシステムエンジニアが陥りやすい計測ミスとして、ディスク性能を忘れてしまうことが挙げられます（図6）。

　これは、考えてみれば至極当たり前のミスなのですが、いままでディスクがボトルネックとなっていることを感じずにシステムを運用してきたエンジニアが陥りやすいミスともいえます。イーサネットやInfinibandにより高速ネットワーク技術が普及し始め、SSDにより高速ストレージ技術も十分に広がりを見せようとしている時期には、これら基本をしっかりと押さえておくことが重要といえます。

図6　ネットワークとストレージの高速化に伴い、ディスクのボトルネックが顕在化する可能性も

　またシステムエンジニアが陥りやすい別のミスに、ネットワーク仮想化があります。一見すると、ネットワーク仮想化を活用すれば、無限に細分化された高速ネットワークを構築できるように思われがちですが、決してそうではありません。

　最近注目を集めるネットワーク仮想化技術である「VXLAN」を題材に見ていきましょう。VXLANではレイヤ2パケットをUDPでカプセル化することでネットワーク仮想化を実現します。このカプセル化による性能劣化が忘れられがちなミスの1つです（図7）。

　仮想化と名の付く技術は、常に性能劣化をトレードオフにしています。より高いネットワーク性能を欲しているWebサービスやそのバックエンドにおいては、ネットワーク仮想化を導入するか否かの決定は、しっかりと技術を理解した上で下すことが重要なのです。

図7　VXLAN利用時の性能計測例

※Linux 3.7-rc7におけるVXLAN設定例（抜粋）
# ip route add 224.0.0.0/4 dev eth3
# ip link set up dev eth3
# ip link add vxlan99 type vxlan id 5001 group 239.0.0.99 ttl 10 dev eth3
# ip addr add 1.2.3.1/24 dev vxlan99
# ip link set up dev vxlan99
# iperf -u -s -B 239.0.0.99 &
# taskset 1 time wget http://X.X.X.X/data

　性能測定に関する注意点の最後に、より詳しいアプリケーション検証方法についてのTipsを1つ共有したいと思います。

　Linuxの「perf」コマンドは、実行されたアプリケーションをCPU命令単位で細かく検証できるツールです。ここでは詳細については割愛しますが、自らが設計・構築したシステムにおけるボトルネックを取り除く時に、とても重要になるツールの1つとなるでしょう。

※実行アプリケーションのCPU命令単位でのステータスを表示
CLIENT# perf stat taskset 1 time wget http://X.X.X.X/DATA
:
 Performance counter stats for 'taskset 1 time wget http://X.X.X.X/DATA':
  17122.081226 task-clock                #    0.809 CPUs utilized
           422 context-switches          #    0.000 M/sec
             2 CPU-migrations            #    0.000 M/sec
           691 page-faults               #    0.000 M/sec
68,279,781,096 cycles                    #    3.988 GHz                     [83.33%]
40,865,307,578 stalled-cycles-frontend   #   59.85% frontend cycles idle    [83.34%]
28,558,490,593 stalled-cycles-backend    #   41.83% backend  cycles idle    [66.67%]
53,293,401,540 instructions              #    0.78  insns per cycle
                                         #    0.77  stalled cycles per insn [83.33%]
 8,745,526,492 branches                  #  510.775 M/sec                   [83.33%]
    58,640,212 branch-misses             #    0.67% of all branches         [83.33%]
  21.163134198 seconds time elapsed

※実行アプリケーションのライブラリおよび命令セットなどを表示
# perf record taskset 1 time wget http://X.X.X.X/DATA
# perf report
Events: 18K cycles
    18.39%  wget  [kernel.kallsyms]  [k] copy_user_generic_string
     5.79%  wget  [kernel.kallsyms]  [k] memcpy
     2.21%  wget  [kernel.kallsyms]  [k] get_page_from_freelist
     2.05%  wget  [kernel.kallsyms]  [k] mark_page_accessed
     1.72%  wget  [kernel.kallsyms]  [k] put_page
     1.62%  wget  [ib_ipoib]         [k] ipoib_ib_handle_rx_wc
     :

　これら性能測定の注意点をしっかりと理解し、有効なツールやコマンドを用いて、システムのさらなる性能向上に向けた取り組みを1つ1つ進めていくことが、今後のシステムエンジニアには求められています。

「リアルタイムWeb」の可能性

　ここまでWebサービスのための高速ネットワーク技術について見てきました。十分に速くなったネットワークと十分に速くなったストレージ、そしてCPUやメモリを取り巻く環境が、今後どこへ向かっていくのでしょうか。

　筆者も研究課題として「リアルタイムWeb」を中心に、次世代Webサービスの可能性を探っているところです。残念ながら現段階においても、「これが次世代Webサービスのカタチだ！」という段階にまでは市場も技術も成熟していませんが、その一端を垣間見える技術をいくつか紹介し、後編を締めくくろうと思います。

より効率的な転送を可能にする「SPDY」、そしてリアルタイムWeb

　HTTP 2.0の標準化に向けた動向として、最近、Googleが提唱する「SPDY」の実装がしばしば話に出てくるようになりました。よりデータ転送効率の高いHTTPネットワークを構築することにより、多くのWebサービスでユーザーの利便性を向上するのが狙いです。

　前述の高速ネットワーク技術の実測でもお話ししたとおり、1台のサーバ当たりに収容可能なネットワーク接続数は、今後も増大していきます。そして、それでも収容が間に合わない場合には台数を増やし、並列化する流れは、今後も止まらないことでしょう。

画面1　SPDYを実装した「mod_spdy」

　このSPDYの例に見られるように、高速ネットワーク技術だけなく、アプリケーション、ストレージ、アルゴリズムなど多岐に渡り、ユーザー収容効率を突き詰めていく研究開発が続いていくことでしょう。

　より多くのユーザーを収容する従来のWebサービスの動きに加えて、リアルタイムに同報データ送受信を可能とするリアルタイムWeb技術の研究開発も進んできています。

　例えば「SocketStream」は“A fast, modular Node.js web framework dedicated to building single-page realtime apps”と銘打っており、従来の複雑なWebサービスフレームワークをより簡素化して、RealTime Webをサービスとして開発運用しやすい環境を整えつつあります（図8）。筆者も、これらの技術に注目しています。今後の発展が多いに期待できる分野の1つです。

図8　SocketStream

【関連記事】

次世代HTTP 2.0はSPDYの取り組みがベースに

http://www.atmarkit.co.jp/ait/articles/1208/31/news137.html

WebSocketで目指せ“リアルタイムWeb”！

http://www.atmarkit.co.jp/fcoding/articles/websocket/01/websocket01a.html

　今後もWebサービスを取り巻く環境は日進月歩で、次々に新しい技術やアイデアが生まれていくでしょう。それらを活用し、効率的にシステム構築・運用する基礎技術として、システムエンジニアには高速ネットワーク技術や高速ストレージ技術、ネットワーク仮想化技術など、多岐に渡るスキルが求められていくことでしょう。

　1つ1つの技術をしっかりと理解できる素地を作るべく、筆者も微力ながらお手伝いできればと思います。Webサービスのための高速ネットワーク技術（前編・後編）がその一助になれば幸いです。

前のページへ 1|2 　　　　　　

SpecialPR