企業ネットワークでは至る所で動画が利用されるようになり、リアルタイムのパフォーマンスがかつてないほど重視されている。しかし現在もネットワークパフォーマンスが低いという問題は起きている――パケットロス、ジッター、バッファリング等の問題やネットワークが非常に複雑化してきていることが原因だ。

リアルタイムのトラフィックをどうするかについてはさまざまな要素があるが、1つにはユーザー側が遅延をどの程度許容できるかというものがある。たとえばゲーマーやミュージシャン、プロセス制御に関する特定分野の人など、リアルタイムインタラクションを扱う人々は4ミリ秒を超えるレイテンシーには耐えられないかもしれない。ビデオ会議や音声会議では、20ミリ秒程度であれば音声が聞き取りづらくなるとか動画のバッファリングが始まることなく済ませられる可能性がある。

「アプリケーションによって提供する機能は異なります。レイテンシーに対する許容度もさまざまだということです」。3月下旬、フロリダ州オーランドで開催された展示会「Enterprise Connect 2023」の席で米NetCraftsmenのネットワーク構築コンサルタント、Terry Slattery（テリー・スラットリー）氏が語った。「ネットワーク上に何のトラフィックがあるか、どこへ向かっているか、背後にあるアプリケーションの要件がどのようなものかを把握していなくてはなりません」

以下、パフォーマンスが低い場合に最もよく見られるネットワーク問題の上位6つと解決策について見てみよう。

01エラー率が十分に低くなく、パケットロスが発生

パケットロスはさまざまな要因で発生する。例としてはDuplex（全二重・半二重）の不一致、光ファイバーの（端面の）汚れ、光スプリッターが良くないことによる光損失、ケーブルの挟み込み、長い配線、設定ミス、スイッチに差し込むモジュールを間違えるなどがある。

Slattery氏は、1 Gbpsの光回線によるキャンパスリンクで毎日少数のエラーが発生していた例を挙げた。数か月の間にエラーの量は徐々に増えていく。この傾向が続けば深刻なパケットロスが発生していただろう。調査の結果、原因はパッチコードの不良であることが分かった。修理するとエラーは出なくなった。

「エラー率は非常に小さくてもTCPベースのアプリケーションに大きな影響を与えます」と氏。「1 Gbpsのリンクで1000マイル（約1609 km）以上もトラフィックを運ぶような場合には、エラー率を非常に低く保つ必要があります」

02ネットワークの輻輳

輻輳によってパケットロスが発生することもある。ネットワーク機器は通常、バッファを利用してパケットバーストを吸収しているが、バッファに格納できるパケット数には上限がある。上限を超えればパケットは失われる。こうした輻輳はネットワークではよくあることだ。

「バーストトラフィックによる輻輳はどんなに優れたネットワークでも起こり得ます」と氏。「高速リンクでもごく短時間の輻輳が発生する可能性があります。まれではありますが、アプリケーションには影響を及ぼします」

原因のひとつはリンク速度の不一致で、10GbEのリンクを1Gbのリンクに接続しているような場合だ。あるいはサーバーと接続しているリンクでオーバーサブスクリプションが発生する場合もある。解決策としては、QoSを利用してトラフィックの性質ごとに優先順位をつけることが有効だ。アプリケーションはさまざまな種類のトラフィックを生成しているが、特定の種類のトラフィックによって問題が発生することがある。QoSによる優先順位付けではパケットをキューに入れ、特定のキューを先に通過させる。これは輻輳の原因となっているトラフィックにのみ適用するのが良い。

例として、T3回線を利用しているリモートの拠点でアプリケーションの動作が遅いという苦情がユーザーから上がった事例について考えてみよう。トラフィックの50%は3つのWebサイトから来ていることがわかった。そのうちごく一部はCDN（コンテンツ配信ネットワーク）からの正当なトラフィックだが、ほとんどは音楽ステーションやNetflixのダウンロードなどの娯楽サイトから来ている。こうした不正なアプリケーションやサイトのトラフィックの優先度を低く設定したものの、問題はまだ解決しない。デフォルト設定ではパケット当たり64バッファとなっているが、１つか2つのQoSキューで256に増やした。Slattery氏によると、これをして良いのはネットワーク上の数個のキューのみで、さもなければバッファリングが多くなりすぎて全体のパフォーマンスが下がってしまうという。

また、ネットワークレポートでその他の種類の輻輳も見直すのが良いという。たとえばNetFlowを利用すれば、誰が何を使用しているかに加え、アクセスポイントやLAN/WANルーター、データセンター-企業ネットワーク間のボトルネックを明らかにすることができる。また、カナダのAppNeta、米NetBeez、米CatchPoint、米ThousandEyesなどが提供するアクティブパス テストの利用を推奨しているとした。

03バッファブロート

バッファブロートは過剰なバッファリングによって発生し、ジッターを引き起こす。音声や動画を再生するにはパケットの到着が遅すぎるという現象が現れ、TCPベースのアプリケーションの速度が低下する。実際の例では、大きなCADファイルをリモートのワークステーションに送信するのに時間がかかったというものがある。この企業ではストレージサーバーからL3スイッチまでのリンクを1 Gbpsから10 Gbpsにアップグレードしていたが、WANは1 Gbpsのままだった。リモート側の読み込み時間が長くなり、QoSでは問題が解決しない。調査の結果、スイッチへの入力は10 Gbps、出力は1 Gbpsになっていることがわかった。多くのパケットが失われていたのだ。このケースでの解決策は、エンドツーエンドで1 Gbpsのパスを構成することだった。これによって過剰なパケットロスを阻止することができた。

バッファフロートの検知方法としては、pingを長時間実行して平均応答時間を測れる状態にした上で大きなファイルの転送を開始するというものがある。応答時間が長くなっていくようならバッファフロートが起きている。解決策の1つはTCPソフトウェアをアクティブキュー管理が可能なものにアップグレードすることだ。

04レイテンシーが高い

レイテンシーは普通、片道1,000マイル（約1609 km）あたり10ミリ秒程度だ。アプリケーションの中にはお喋りなものがあり、バックグラウンドでは大量の通信が往復している。

「TCPウィンドウ スケーリングは有効ですが、時にはアプリケーション自体を書き換えておしゃべりを減らす必要があることもりあります」とSlattery氏。「レイテンシーを減らす簡単な方法の1つは、静的コンテンツにCDNを使うなどしてクライアントとデータの位置を近付けることです。Geo DNSを利用してクライアントを最も近いアプリケーションサーバーに誘導するのも良いでしょう」

05Wi-Fiの設計・実装が良くない

「だめなWi-Fiは作りやすいものです」と氏。「良いWi-Fiを作るのは簡単ではなく、専門家による電波環境調査を行い設計や実装の指針とする必要があります」

考慮すべき要素としては、ダクトやエレベーター、建物の鉄骨などの金属構造物による反射、他のWi-Fiノード (自社および近隣の所有物) との干渉などがある。アクセスポイントの適切な配置も必要だ。避けるべきポイントもある。反射面は信号に影響を与えるため、金属製の天井にアクセスポイントを設置してはならない。天井にアクセスポイントを設置している場合、壁に設置してもあまり機能しないため避けること。天井が高すぎて端末の高さに届くWi-Fi信号が弱い場合があるので注意すること。倉庫など、必要な場所では指向性アンテナを使用、壁に設置して通路の先へ信号を送ることが可能だ。

さらに、アクセスポイント間の干渉を避けるために正しい周波数帯を使用する必要もある。「5GHz帯と6GHz帯は2.4GHz帯よりもチャンネル数が多いので、相互の干渉を避けやすいでしょう」と話している。

06ネットワークが複雑化している

企業ネットワークといえば、かつてはLANに関するものだった。しかし現在では、WANやWeb、Wi-Fiもあり、Wi-Fiや衛星通信などを利用するエッジネットワーキングも台頭している。米Chetan Sharma Consultingのアナリスト、Chetan Sharma（チェタン・シャルマ）氏の予測では、2030年までにエッジエコノミーの市場規模は4兆1,000億ドル（547兆4,690億円）に達するという。ネットワーク管理に「大きな影響がある」と氏は述べている。

さらに、現在のネットワークの管理やトラブルシューティングではIoTセンサーやIoTデバイス、コンテナ化アプリケーションにも対応しなくてはならない。

「あるサービスに対して特定のデバイスが紐づけられているわけではないため、ネットワーク管理システムはサービスの可用性に関しては暗闇の中を飛んでいるようなものです」。米Alef EdgeのMike Mulica（マイク・ムリカ）CEOが述べている。「サービスとデバイスは分離が進んでいます。既存のネットワーク管理の仕組みを変え、さまざまなレイヤー、スタックをカバーしながらマルチクラウド環境の複数のドメイン間で調整ができる新しい仕組みを開発、実装する必要があります」

Top 6 network problems hindering real-time performance