性能条件を満たすネットワーク機器を選定する際に,スループットをカタログ上のbps(bit per second)やpps(packet per second)といった数値で単純に判断してはいけない。そもそも,カタログ・スペック値は,特定の条件下のもので,実際の利用シーンで同じ性能が出ないことはよくある。基本的に,カタログ値はある程度割り引いて見なくてはいけない。

 さらに,機器のスペックは実際のトラフィック発生条件に照らし合わせて,もう一歩踏み込んで判断する必要がある。bps やppsは,機器のスループットを示す数値の一つに過ぎない。時間的な範囲や物理的な範囲をきめ細かく考慮しなければ,性能不足やトラブルを引き起こすことがある。

 時間的な範囲とはスループットをbpsやppsなど秒単位の値だけでなく,ミリ秒~数十ミリ秒といった短い時間の単位におけるピーク特性まで考えておくことを指す。平均した通信では性能条件を満たすが,ピーク特性では満たしていないといったことが現実によくある。もう一つの物理的な範囲とは,機器のポート単位,機器単位,インバウンド/アウトバウンド別などが挙げられる。ポート単位では性能条件を満たすが,機器全体では満たしていないといったことだ。

瞬間的なピーク特性を見逃してはいけない

 時間的な範囲について,ファイアウォール製品で実際に起こったトラブル例をもとに説明しよう。100Mbpsの通信インタフェースを備えた監視用PCを接続し,百数十台の機器に対してファイアウォール越しにpingのポーリングを行って死活監視を行おうとした。すると,監視対象機器が正常に稼働しているにもかかわらず,半数近いpingパケットがロストしてしまうという事象が発生した。

 ファイアウォール製品のポート・スピードも当然100Mbpsに対応していたが,実はポート単位のパケット数スループットに最大20ppms(1ミリ秒当たり20パケット)という性能限界があった。pingの転送量は1秒平均で見ると100Mbits以下であったが,数ミリ秒単位の時間に大量のpingパケットが流れたため,1ミリ秒当たり20パケットという限界を超過した分のパケットがロストしたのである。

図1●秒単位で見たときには許容範囲内でも,実際には許容値を超えている例
図1●秒単位で見たときには許容範囲内でも,実際には許容値を超えている例

 上記は比較的レアな事例であるが,例えば回線品目の選定において,平均して1秒間に1Mbitsの通信量であっても,実際には最初の0.5秒間に1Mbits,後の0.5秒間に0Mbitsといった具合にトラフィックが偏って発生してしまい,1Mbpsの回線では耐えられないということはよくある(図1)。0.5秒では0.5Mbitsしか処理できないためだ。この例で性能を満足させるためには2Mbps以上の回線を選択する必要がある。

ポート単位の性能条件だけを見ていてはいけない

 次に物理的な範囲について説明しよう。まず,ポート単位の性能条件はクリアしていても,機器全体で見たときのトータル・パケット数などが機器諸元を上回ってしまい,必要な性能が得られないというのはありがちなケースだ。

 具体的には,インバウンド/アウトバウンドの性能に関する見誤りがある。機器単位のスループットが400Mbpsのルーターに対して,300Mbps全二重の回線を接続してしまうことがある。機器側のスペックは,上り・下りの区別が無くトータルで400Mbpsである。300Mbps全二重回線では上り・下りを合わせて最大で600Mbps相当のトラフィック量になるため機器単位のスペックが不足する。

 似たようなケースとしてはIDS(Intrusion Detection System)などを接続するためのミラーポートの帯域が不足するトラブルがある。例えば100Mbps全二重の上り・下り両方の通信をミラーポートに流すと,最大で200Mbpsの下りトラフィックがミラーポートに発生する。ミラーポートのリンク・スピードが100Mbpsであった場合,当然のことながら性能が不足してしまう。

リソースの偏りを考慮せずに設計してはいけない

 また,帯域制御装置などでクラス/パーティションといったリソースを見積もる際,リソースの制限を複数台の分散処理で回避することがある。そのときは,完全に各機器に公平に回線を収容できず,ある程度偏りが生じる可能性などを考慮せずに設計してはいけない。実際に設定を行う際,1台当たりのリソース上限を上回ってしまう危険がある。

 特に冗長構成の縮退時に片方の系にトラフィックが集中する場合は問題だ。帯域制御レベルを通常時と同様に保証する場合は,必要となるクラスなどが倍程度必要となる。初期段階に行う機器構成の見積もり時には見落とさないように注意したい。

 いずれにせよ,機器構成を選定するに当たって,性能やリソースを見誤ると,機器の変更・追加以外に根本的な解決策がなくなり,プロジェクトに与えるインパクトが非常に大きくなる。設計は慎重に行いたい。

大高 篤志
NTTデータ 法人システム事業本部 社会基盤開発事業部 トレーディングシステム部 課長 シニアITスペシャリスト(ネットワーク)
1988年,株式会社NTTデータに入社。以来,商品取引業界システム開発をはじめ,テレコム業界を中心にデータウエアハウス,コールセンター,ビリング,財務分析など多様な業務アプリケーション開発でプロジェクト・マネジメントを実施。その後,基盤技術系支援部隊のマネージャを経て,近年では仮想化技術を応用したマイグレーション案件,証券業界向けのネットワーク構築などを手掛ける。