ネットワークの遅延

ネットワークの遅延

 企業活動を行うたいめには、ITサービスの利用が不可欠となりました。これは、ネットワークインフラが充実したのが大きな要因です。

クラウド時代を迎え、ネットワークに繋がっていない端末は、非常に少なくなりました。ますます、ネットワークの重要性が高まってきます。

 ここで問題になってきているのが、ネットワークの遅延の問題です。本ページでは、この点について詳しく解説します。

1.データが伝わる速度 (電気通信)

 データの伝達は、電気によって運ばれています。電気の速度は、毎秒約30万キロメートルと非常に高速です。

 1秒間の伝達距離は、地球の7回り半に相当します。

伝送ロスがないとすると、
 東京から札幌まで、約1,200km(直線でなくケーブル道)の距離となりますので、約4.0msで到達することになります。

区間 距離(ケーブル道)
【km】
伝達時間
【ms】
伝達時間
(往復)
【ms】
東京-札幌1,2004.08.0
東京-博多1,1003.77.4
東京-大阪  5201.73.4



日本国内の場合、上記のように短時間となりますが、
東京-ニューヨークですと、直線距離では、約10,900kmとなり、海底ケーブル、地形を考慮するとケーブル長は、20%増しとすると、約13,100kmとなります

区間 距離(ケーブル道)
【km】
伝達時間
【ms】
伝達時間
(往復)
【ms】
東京-ニューヨーク13,10043.787.4



 日本国内の通信と比べ、10倍以上になりますので、システム構築では遅延を意識する必要があります。

<参考:光ファイバーについて>
 電気と同じスピードで伝達されるのが、「光」です。ITインフラとして、光ファイバーが導入されるようになりました。

 光ファイバーは、

① 電気ではないので、電磁誘導を受けない。
② 広帯域の容量を確保できる。
等のメリットがあり、急速に導入され、今では、自宅まで光回線を引く時代になりました。


2.ネットワークの遅延の実際

 伝送損失が0であれば、日本国内は非常に短い伝達時間となりますが、実際には、間に、伝送装置、ルータ等が入りますので、ネットワークの遅延が発生します。

 次の図は、東京~大阪間で、中継装置が無い例を示しています。

ネットワークの遅延【理想系】

実際は、東京~大阪間で多くの機器を経由しています。

東京から、大阪までの、traceroute の実行例を示します。

traceroute to 大阪(from 東京), 30 hops max, 60 byte packets

1内部機器 0.419 ms 0.890 ms 1.057 ms
2内部機器 0.315 ms 0.346 ms 0.397 ms
3内部機器(Router) 1.282 ms 1.348 ms 1.389 ms
4ISP-A 機器 6.087 ms 6.108 ms 6.137 ms
5ISP-A 機器 4.854 ms 4.899 ms 4.930 ms
6ISP-A 機器 14.589 ms 14.993 ms 13.080 ms
7ISP-B(IX)機器 6.707 ms 6.660 ms 6.674 ms
8ISP-C 機器 6.756 ms 6.806 ms 6.670 ms
9ISP-C 機器 6.801 ms 6.712 ms 6.440 ms
10ISP-C 機器 20.302 ms 18.833 ms 18.378 ms
11ISP-C 機器 13.324 ms 13.991 ms 13.098 ms
12ISP-C 機器 13.767 ms 14.407 ms 13.776 ms
13ISP-C 機器 13.807 ms 14.031 ms 13.523 ms
14Server 13.901 ms 13.341 ms 13.349 ms

構成のイメージ図を次に示します。ISP:インターネットサービスプロバイダ

ネットワークの遅延(イメージ)

実際のシステムは、図のように、沢山の機器を経由します。
この構成(サンプル)で、東京の機器から、大阪のサーバへのping値は、

 東京~大阪機器へのping値  11.2 ms(平均値)

でした。

同様に、東京から、札幌までの、traceroute の実行例を示します。

traceroute to 札幌(from 東京), 30 hops max, 60 byte packets

1内部機器 0.435 ms 0.878 ms 1.068 ms
2内部機器 0.298 ms 0.361 ms 0.414 ms
3内部機器(Router) 1.481 ms 1.573 ms 1.657 ms
4ISP-A 機器 3.011 ms 4.064 ms 4.102 ms
5ISP-A 機器 2.223 ms 2.276 ms 2.295 ms
6ISP-A 機器 12.224 ms 12.371 ms 11.147 ms
7ISP-B(IX)機器 3.012 ms 2.983 ms 3.211 ms
8ISP-C 機器 22.285 ms 22.222 ms 21.573 ms
9ISP-C 機器 19.989 ms 20.022 ms 22.447 ms
10ISP-C 機器 22.387 ms 22.327 ms 21.826 ms
11ISP-C 機器 21.858 ms 21.889 ms 19.727 ms
12Server 22.722 ms 27.268 ms 22.729 ms

上記の場合、通過する機器は、11個でした。

この構成で、東京の機器から、札幌のサーバへのping値は、

 東京~札幌機器へのping値 22.4 ms(平均値)

でした。

同様に、東京から、アメリカ東海岸の機器までの、tracerouteの実行例を示します。

traceroute to 米国機器(from東京), 30 hops max, 60 byte packets

1内部機器 7.718 ms  7.908 ms  8.100 ms
2内部機器 0.423 ms  0.478 ms  0.542 ms
3内部機器(Router) 1.469 ms  1.550 ms  1.632 ms
4ISP-A 3.481 ms  3.610 ms  4.281 ms
5ISP-A 2.379 ms  2.416 ms  2.452 ms
6ISP-A 3.594 ms  3.694 ms  3.810 ms
7ISP-B 4.429 ms  3.605 ms  3.997 ms
8ISP-B 3.358 ms  3.168 ms  3.146 ms
9ISP-C 84.676 ms  86.218 ms  84.874 ms
10ISP-C 159.183 ms  136.427 ms  136.960 ms
11ISP-C 145.412 ms  142.274 ms  165.360 ms
12ISP-C 154.366 ms  151.744 ms  143.483 ms
13ISP-D 208.072 ms  210.515 ms  219.707 ms
14ISP-D 217.582 ms  227.867 ms  205.651 ms
15* * *   

この構成で、東京の機器から、米国のサーバへのping値は、
 東京~米国機器へのping値 202 ms(平均値)
でした。

距離、伝送時間(ロス無:電気、光の速度)、ping値を示します。

区間 距離 電気の伝送時間
【ms】
電気の伝送時間
(往復)
【ms】
ping値
【ms】
東京-札幌1,2004.08.022.4
東京-大阪  5201.73.411.2
東京-アメリカ13,10043.787.4202


3.ネットワークの遅延の実験(網内遅延を疑似発生)

 前述のとおり、距離が遠くなるとかなりの遅延が発生します。
 それでは、遅延が大きくなると体感としては、どのように感じるのでしょうか。

 疑似ネットワークにより、遅延を強制的に発生させ、その時のファイルのダウンロード時間を測定しました。

 詳しくは、次のリンク先をご参照下さい。

ネットワークの遅延の実験 へリンク

4.アプリケーションの遅延(体感)(1)【APの種類】

 これまで、伝送速度の遅延を説明してきましたが、実際にアプリケーションを利用した体感は、アプリケーションの種類によって、遅延値が影響する場合と、影響が少ない場合があります。 

 一般的に、ファイル容量の小さなデータへのアクセス(Webアクセス等)については、遅延の許容が大きいのですが、大きなファイルを扱うアプリケーション(ファイル共有等)は、遅延の影響を受け易いと言えます。

 特に遅延の大きい海外と通信の場合、大きなファイルを取り扱うアプリケーションには、WAN高速化装置の導入を行わないと人間が操作するには耐えられない程、遅延の影響を受けます。

 国内でも、ISPの伝送路の組み方によると、遠回りをして接続されている場合があります。

例:富山-松本間は、直線距離では、85km程度ですが、
実際の伝送路が、富山~大阪~松本 と 大阪の機器を経由している場合もあります。

 この地域で、ファイルサーバを共有するシステムを構築した際、レスポンスが遅いとの苦情を受け、別の伝送路のネットワークを利用して問題を解決したことがあります。

 Webのアクセスについては、それ程苦情がなかったにも関わらず、ファイルサーバについては、遅延の影響を受けました。

 このように、利用するアプリケーションにより、遅延の影響が違いますので、
「遅延が何ms以下であるので、ストレスが無い。」とは言い切れません。

 使用されるアプリケーションにより、遅延の許容範囲を考慮する必要があります

5.アプリケーションの遅延(体感)(2)【システム構成】

 以下の図は、一般的な、企業内ネットワークの構成です。

アプリケーションの遅延【システム構成】

 このような構成では、遅延の発生要因は複数考えられます。
・ネットワーク
・ネットワーク(地域網)
・FW(ファイアーウォール)
・サーバ
・その他経由する機器
のどれも全体のスループット(赤矢印)に影響します。

 これまで、ネットワークの遅延は、回線帯域が狭いことが原因のほとんどでした。
 ブロードバンドが普及し、狭帯域のネットワークから広帯域のネットワークにどんどん移行されています。
 帯域に余裕がある場合でも、遅延は発生することがあります。

 遅延がある=帯域が狭い だけではありません。

 単なる死活監視(ping試験)では、FW(ファイアウォール)を経由した試験ができません。
 その場合、もっと上位レイヤ(アプリケーションに近いレベル)からの試験が有効です。

  「FW超え試験」にリンク

機器のconfig設定が誤っている場合も遅延が発生することがあります。また、冗長化構成を取られた機器の中の1つが不具合の場合にも遅延が発生します。


6.アプリケーションの遅延(体感)(3)【サーバインフラ】

 サーバインフラの違いによっても、アプリケーションの遅延(体感)が違います。

 次の構成において、ロケーションが異なるクラウドサービス上に、WEBサーバを構築しました。

ネットワークの遅延(サーバインフラ)

EEC(End to End Checker)

それぞれのサーバに対して、
 ・ping試験
 ・80ポート試験
 ・WGET試験(0バイトの情報を入手)
を東京事務所より行った試験結果です。【値は平均値】

試験内容関西クラウドセンタ
【ms】
北海道クラウドセンタ
【ms】
ping11.2(10.1)22.6(21.6)
80port13.7(10.3)22.8(19.2)
wget250.6(221.2)58.7(46.4)

(  )内は、ミニマム値



次に示すグラフは、2015年9月17日(木)のEECの出力結果です。

グラフの凡例は、
青:速い、緑:少し遅い、紫:遅い、赤:timeout
を表します。

1時間に100回試験をし、100回とも速ければ、青色のみになります。
50回が速く、50回が少し遅い場合は、半分が青色、半分が緑色となります。
青、緑、紫、赤で、100%表示としています。

今回の表示の閾値は次の通りです。

速い 青  45.000 ~ 145.000 (ms)  (間隔:100.000 ms)
少し遅い 緑 145.000 ~ 245.000 (ms)  (間隔:100.000 ms)
遅い 紫 245.000 ~   

関西クラウドセンタ
ネットワークの遅延【wget 関西】

北海道クラウドセンタ
ネットワークの遅延【wget 北海道】

なんと、距離の遠い北海道クラウドセンタのWEBのアクセスの方が速い結果となりました。

関西クラウドセンタの方が、距離も近く、ping値も小さいにも関わらず、wegt(アプリケーション試験)において、遅延値が逆転しています。

同じベンダのクラウドサービスですが、クラウドを構成している共通機器の状況により、wgetのレスポンス値に違いが生じていると考えられます。

以上から分かることは、単に、ping値を試験しただけでは、実際の体感が分らないことを意味しています。

体感値を知るには、できるだけアプリケーションに近いレベルの試験が必要なことが分かります。

7.パケットキャプチャによる解析

 関西クラウドセンタのWWWサーバ、北海道クラウドセンタのWWWサーバにおける、

 wget [–spider オプション]の動作のパケットキャプチャを行いました。

 キャプチャの場所は、EECのNICで行っています。
 次の図は、各サイトへのアクセス状況の時間経過を示しています。

ネットワークの遅延:パケットキャプチャ

図をクリックすると拡大します。

パケットキャプチャの生データを次に示します。
実施日:2015年10月13日(火)
【北海道WWW】
①17:04:48.076115 IP EEC.36804 > 北海道WWW.http: Flags [S], seq 1925599048,
 win 14600, options [mss 1460,sackOK,TS val 3149424812 ecr 0,nop,wscale 7], length 0

②17:04:48.098702 IP 北海道WWW.http > EEC.36804: Flags [S.], seq 303900495, ack 1925599049,
 win 14480, options [mss 1300,sackOK,TS val 3268127821 ecr 3149424812,nop,wscale 6], length 0

③17:04:48.098727 IP EEC.36804 > 北海道WWW.http: Flags [.], ack 1,
 win 115, options [nop,nop,TS val 3149424834 ecr 3268127821], length 0

④17:04:48.098843 IP EEC.36804 > 北海道WWW.http: Flags [P.], seq 1:115, ack 1,
 win 115, options [nop,nop,TS val 3149424834 ecr 3268127821], length 114

⑤17:04:48.120529 IP 北海道WWW.http > EEC.36804: Flags [.], ack 115,
 win 227, options [nop,nop,TS val 3268127843 ecr 3149424834], length 0

⑥17:04:48.123100 IP 北海道WWW.http > EEC.36804: Flags [P.], seq 1:239, ack 115,
 win 227, options [nop,nop,TS val 3268127845 ecr 3149424834], length 238

⑦17:04:48.123113 IP EEC.36804 > 北海道WWW.http: Flags [.], ack 239,
 win 123, options [nop,nop,TS val 3149424859 ecr 3268127845], length 0

⑧17:04:48.123177 IP 北海道WWW.http > EEC.36804: Flags [F.], seq 239, ack 115,
 win 227, options [nop,nop,TS val 3268127845 ecr 3149424834], length 0

⑨17:04:48.123275 IP EEC.36804 > 北海道WWW.http: Flags [F.], seq 115, ack 240,
 win 123, options [nop,nop,TS val 3149424859 ecr 3268127845], length 0

⑩17:04:48.145099 IP 北海道WWW.http > EEC.36804: Flags [.], ack 116,
 win 227, options [nop,nop,TS val 3268127867 ecr 3149424859], length 0

【関西WWW】
①16:34:33.973846 IP EEC.48447 > 関西WWW.http: Flags [S], seq 243990028,
 win 14600, options [mss 1460,sackOK,TS val 3147610709 ecr 0,nop,wscale 7], length 0
②16:34:33.988993 IP 関西WWW.http > EEC.48447: Flags [S.], seq 671472849, ack 243990029,
 win 5792, options [mss 1300,sackOK,TS val 2548729406 ecr 3147610709,nop,wscale 7], length 0
③16:34:33.989016 IP EEC.48447 > 関西WWW.http: Flags [.], ack 1,
 win 115, options [nop,nop,TS val 3147610725 ecr 2548729406], length 0
④16:34:33.989131 IP EEC.48447 > 関西WWW.http: Flags [P.], seq 1:114, ack 1,
 win 115, options [nop,nop,TS val 3147610725 ecr 2548729406], length 113
16:34:34.004188 IP 関西WWW.http > EEC.48447: Flags [.], ack 114,
 win 46, options [nop,nop,TS val 2548729421 ecr 3147610725], length 0

⑤と⑥の間の差:253ms 

16:34:34.257345 IP 関西WWW.http > EEC.48447: Flags [P.], seq 1:241, ack 114,
 win 46, options [nop,nop,TS val 2548729674 ecr 3147610725], length 240
⑦16:34:34.257364 IP EEC.48447 > 関西WWW.http: Flags [.], ack 241,
 win 123, options [nop,nop,TS val 3147610993 ecr 2548729674], length 0
⑧16:34:34.257370 IP 関西WWW.http > EEC.48447: Flags [F.], seq 241, ack 114,
 win 46, options [nop,nop,TS val 2548729674 ecr 3147610725], length 0
⑨16:34:34.257567 IP EEC.48447 > 関西WWW.http: Flags [F.], seq 114, ack 242,
 win 123, options [nop,nop,TS val 3147610993 ecr 2548729674], length 0
⑩16:34:34.273013 IP 関西WWW.http > EEC.48447: Flags [.], ack 115,
 win 46, options [nop,nop,TS val 2548729690 ecr 3147610993], length 0



各項目のレスポンスの内訳(単位:ms)

項目北海道CC関西CC
SYN(コネクション確率要求)2315
データ253
FIN(コネクション解放要求)2222



 SYN(コネクション確率要求)とFIN(コネクション解放要求)については、距離の相応した妥当なレスポンスだと考えられます。
 データの要求に対する応答がかなりの差となっています。


過去のデータの調査

関西CCにおける過去のデータを示します。特に利用側(クラウドを利用する側)では、WWWサーバの変更等は行っておりません。

2015年5月のデータ
ネットワークの遅延:クラウドセンタの5月のデータ
5月21日に大きな値の変化が出ています。
次のグラフは、5月21日のデータです。
ネットワークの遅延:クラウドセンタの5月21日のデータ
時間ごとの試験結果を次に示します。
ネットワークの遅延:時間ごとのレスポンス結果

 9時代のミニマム値は、32msでしたが、11時代には、230msと大きく変化しています。

 WEBアクセスでは、一概に、「200ms台=悪い」 ではありませんが、この数字が大きくなってくるとお客さまのストレスが高まってくると考えられます。

 今回の事例では、ユーザ側でのアプリケーションインフラ[ミドルウェア、Apache(WWW)の入れ替え等]の変更を行っていませんので、レスポンスの変化は、

・ミドルウェア
・アプリケーション
・クラウド基盤  
の 「クラウド基盤」に原因があることが推測されます。

8.WireSharkで表示した例

 「7.パケットキャプチャによる解析」の結果をWireSharkを用いて表示します。
 WireSharkを利用すると、遅延が生じたパケットを容易に探し出すと事可能です。
 (「7」と調査時間帯が異なります。

wiresharkの表示


 SYN(パケット確立要求)とFIN(パケット解放要求)の時間は、関西クラウドの方が短いですが、データ部の応答は関西の方が時間を要しているのが分ります。

 上記の例のように、遅延が発生している場合に、ある特定のパケットが遅れているかどうかを調べるのはとても有効です。

 下の図は、一般に見かけられるインターネット上のWEBサーバの構成です。

 レスポンスに問題がある場合、図の赤点線部分でパケットキャプチャを行い、WEBサーバに問題があるのか、DBサーバに問題があるのか切り分けが可能となります。

インターネット上のWEBサーバ構成

9.ネットワークの遅延(まとめ)

 これまで説明してきたとおり、システム設計においては、伝送路としての物理的なネットワークの遅延を考慮する必要があります。特に海外との通信には注意が必要です。
 また、利用するアプリケーションにより、システム設計に気を付けることが重要です。

 物理的な影響(距離)以外にも、アプリケーションを利用した体感は、
・クライアントとサーバの間で経由する機器
・アプリケーションの種類
・サーバ基盤
により、レスポンスが異なってきます。

 ITインフラは複雑、また、起業活動における生命線となっておりますので、安定したサービスの提供は益々重要となってきます。

 このような背景から、これまでのような機器の個別監視(死活監視等)から、「トータル監視(エンドユーザがストレス無く使えているかを見える化する)」が必要となってきます。

  トータル監視のページへ

  トータル監視の考え方で課題を解決した例(SalesForceの遅延)

  弊社保守サービス特徴

  お問合せ

  「アプリケーションの遅延」のページもご参照願います。

a:7251 t:29 y:14

最新の更新 RSS  Valid XHTML 1.0 Transitional