マルチクラウド展開にまつわる既成概念を覆すより
データ転送では、特に長距離の場合にレイテンシ（遅延）が問題になることがありますが、現在はすべてのクラウド・プロバイダーがそれぞれの物理インフラストラクチャを互いの近くに配置（専門用語では「コロケーション」）しているため、これはさほど問題となりません。この近接性（場合によっては同一コロケーション施設内の別の部屋）は、クラウド間のレイテンシがミリ秒単位であることを意味します。それに加え、クラウド・データセンター・リージョンは世界中で増加しており、クラウド・リージョン間の距離は縮まっています。
という事で、レイテンシ(遅延)について、まとめてみてみます。

■ Agenda

　レイテンシ(遅延)とスループット(帯域幅)
　レイテンシと TCP の動作
　帯域幅遅延積(Bandwidth-Delay Product)
　 TCP Window Size の調整とチューニング
　クラウドサービスでの考慮
　レイテンシ(遅延)の机上計算
　ネットワーク・パフォーマンスの測定方法
　必要レイテンシ(遅延)値の事前策定
　参考情報

■ レイテンシ(遅延)とスループット(帯域幅)

レイテンシとスループットは、2つのネットワークのパフォーマンス測定値です。

　・ レイテンシ: 転送要求から応答を受信するまでの応答時間
　・ スループット: 一定時間内に転送できるデータの量

TCP通信では、レイテンシが大きくなると比例してスループットは低下し、通信の完了が大きく影響を受けます。

・参考: ネットワーク遅延対策技術

・イメージ

※ 分かりやすくするためのイメージです。TCP/IP - TCP 3ウェイハンドシェイク、ウィンドウサイズの折衝等は割愛しています。詳しくはこちらも参考ください

　・参考: TCP window size の仕組み
　　　　 TCP Window Control / Flow Control

■ レイテンシと TCP の動作

TCP では、送信側が高速で受信側が低速な場合のオーバーランを防ぐため、ウィンドウ処理という仕組みが使用されます。
この仕組みでは、受信側のウィンドウが更新されるのを送信側が待つことなく送信できるデータ量を受信側から取り寄せます。
この TCP ウィンドウを使用することで、送信側システムと受信側システムはメモリを効率的に使用できます。
また、TCP ウィンドウサイズは、受信バッファサイズ、TCP ソケットバッファーサイズとも呼ばれます。
TCP 接続の一括転送のパフォーマンスの制限は次の式で表されます。

式

Throughput = Window Size / Round Trip Time(RTT)のレイテンシ

・参考: 問題: レイテンシと TCP の動作
　　　応用情報技術者過去問題
　　　ビット？バイト？データ量の表し方

ウィンドウ・サイズ=64 KB, レイテンシ=1ms の時のスループットは次のようになります。

Window Size=64KB, RTT=1msの場合

64 KB / 1 ms  = (64 KB) / (1/1000 s)
              = 64000 KB/s
              =    64 MB/s 
              =   512 Mbps

ということで、TCPを用いるアプリケーションの最大スループットは、往復の遅延時間（RTT: Round Trip Time）の影響をうけるため、ウィンドウサイズが 64Kバイトの場合のTCP最大スループットの理論値は以下のとおりです。

※ MByte は1,000 KByte とする。
・参考: ネットワーク遅延と高速化

■ 帯域幅遅延積(Bandwidth-Delay Product)

帯域幅遅延積は、ネットワーク帯域幅とネットワークを通過するデータの往復時間の積です。
帯域幅遅延積以上の値に設定すると、ネットワーク帯域幅を最適に利用できるように、大量のデータが送信されます。
これは、TCP ウィンドウサイズが小さく帯域幅に余裕があり十分なスループットがでない場合、一度に送信するデータ量を増やせばこの問題を解決できます。
ネットワークの帯域幅が増加するとケーブル（ネットワーク）を流れるデータ量が増加します。
また、ケーブルが長くなるほどデータの受信確認に要する時間も長くなります。
この関係を帯域幅遅延積（Bandwidth-Delay Product: BDP）といいます。
BDP は帯域幅とラウンドトリップ時間（RTT）の積で、パイプにできるだけ多くのデータ量を流すために最適な送信ビット数が得られます。
これは以下の式で表されます。

帯域幅遅延積の計算式

BDP（bit）= 帯域幅（bit/秒）× RTT（秒）

たとえば、ネットワークの帯域幅が 100Mbps (100,000,000bps)で、往復時間が 5ms の場合、送受信バッファは少なくとも (100*10ˆ6) * (5/10ˆ3)ビット、すなわち約 62.5KBになります。

スループット=100Mbps, レイテンシ=5ms の場合

  100,000,000 bits        1 Bytes        5 ms
--------------------  x  --------- x  ---------  =  62,500 bytes
   1 second               8 bits        1000

・参考
　- レイテンシと TCP の動作
　- 帯域幅遅延積の求め方

ということで、先ほどの表に帯域幅遅延積を加えると次のようになります。

最適なウィンドウサイズ, TCP Buffer Sizeの値は、それぞれのユーザーの状況によって異なりますが、システムのデータ送信が予期される経路の BDP（帯域遅延積）の最大値が 1 つの基準となります。
ネットワーク帯域幅をすべて使うようにするには、送信ウィンドウを帯域遅延積の2倍以上に設定します。

　・参考: HPCユーザが知っておきたいTCP/IPの話

■ TCP Window Size (TCP Buffer Size)の調整とチューニング

● Path MTU Discovery確認

TCP Buffer Size の調整の前に、Maximum Transmission Unit (MTU) と Path MTU Discovery (PMTUD)設定を確認しておきます。
MTU とは一回のデータ転送で送信可能なIPデータグラムの最大値、この値は固定もしくは Path MTU Discoveryによる自動検出により設定されます。
自動検出有効にするには送信元へICMP（type 3 code 4）でその最小 MTU値の情報を送信して、MTUサイズを自動修正させます。
ということで、MTUサイズ異なることによる接続がハングするという問題を回避するよう Firewall に ICMP（type 3 code 4）を許可する設定をしておきます。

・参考:
　- Path MTU Discovery
　- Window Size と MSS (≒MTU) との違い
　- ハングしている接続

● OS での TCP Buffer Size調整

まず、アプリケーションの TCP Buffer Size 調整の前にOSのTCP Buffer Sizeのリミッターを引き上げる必要があります。そして、OSの設定値を確認し、効果がありそうか調整を試みます。

・ Linux

・ net.core.rmem_max: 最大読取りソケット・バッファ・サイズを指定
・ net.core.wmem_max: 最大書込みソケット・バッファ・サイズを指定
・ net.ipv4.tcp_rmem: TCPソケットの 最小, デフォルト, 最大受信バッファ・サイズを指定
・ net.ipv4.tcp_wmem: TCPソケットの 最小, デフォルト, 最大送信バッファ・サイズを指定

・参考: システム・パフォーマンスを制御するパラメータ

・ Mac OSX

・ net.inet.tcp.autorcvbufmax
・ net.inet.tcp.autosndbufmax
・ net.inet.tcp.win_scale_factor
・ kern.ipc.maxsockbuf
・ net.systm.kctl.autorcvbufmax

・参考: Mac OSX Tuning

・ Windows

受信ウィンドウサイズを特定の値に設定するには、Windows のバージョンに固有のレジストリサブキーに TcpWindowSize 値を追加します。

・参考: Windows TCP 機能の説明

● Software での TCP Buffer Size調整

アプリケーション、ソフトウェアによって、TCP Buffer Sizeを調整してNWスループットを上げることができるものがあります。

・ファイル転送ソフトウェア

・ WinSCP
　「接続バッファサイズの最適化」をチェック
　　・参考: The Connection Page (Advanced Site Settings dialog)

・ SFTP
　　-B バッファサイズを指定 : デフォルト 32768 バイト
　　・参考: manページ — SFTP

・ SCP
　　High Performance SSH/SCP は、SSH バッファサイズを動的に大きくすることで、スループットを劇的に増やすことができます。
　　・参考: SSHの高速化

・ RCLONE
　　--buffer-size=SIZE: バッファ・サイズを指定して、ファイル転送を高速化します。
　　・参考: rclone.org

・ Oracle Database

　- TCPソケット・バッファ・サイズの設定
　- REDOデータ転送のネットワーク調整
　- パフォーマンスの最適化
　- 帯域幅遅延積の求め方
　- How to measure Network Latency for Oracle Data Guard Replication
　- Doc ID 2064368.1: Assessing and Tuning Network Performance for Data Guard and RMAN
　

● その他チューニングによるスループット高速化

スループット高速化するには、転送回数削減、転送サイズ縮小化などがあります。

　・ 転送回数削減: 並列処理、効率的プログラミング・アルゴリズムの使用、など
　・ 転送サイズ縮小化: データ圧縮、オーバーヘッド少ない暗号アルゴリズムの選択、など

・ファイルを分割して並列転送で高速化

ファイル転送でバッファ・サイズ指定できない場合や、効果が足りない場合、ファイルを分割して並列転送して転送時間を短縮します。
また、ファイル圧縮もできれば転送時間をより削減できます。

　・ scp の複数同時接続
　・大きなファイルを分割して送信し、そのあとで結合する方法
　・ Object Storageのマルチパート・アップロード
　・ Curl でマルチパート・アップロード

・効率的な暗号アルゴリズムの選択

暗号化にはオーバーヘッドが生じ、アルゴリズムにより異なります。
scp, sftp の場合 ssh -Q cipher で使用できる暗号方式を確認し、-c オプション: 暗号アルゴリズムを選択できます。

　・大容量ファイルのSCP転送を高速にする方法
　・次の暗号化オプションのどれがオーバーヘッド/コストを増加させるでしょうか？
　・ SSHの公開鍵暗号には「RSA」「DSA」「ECDSA」「EdDSA」のどれを使えばよいのか？

・圧縮による転送効率化

ファイル圧縮して転送サイズを縮小化し転送時間を削減します。
scp, sftpコマンドの場合 -C オプション, rsyncコマンドの場合 -z --compress でデータ圧縮して転送することもできます。

　・ zipsplit コマンド――ZIPファイルを分割する
　・大容量ファイルのSCP転送を高速にする方法

Oracle の場合、クエリー・パフォーマンスの改善, ネットワーク通信量の削減などの効果が得られます。

　・ Oracle Advanced Compression概要
　・ Oracle Advanced Compression ホワイトペーパー
　・徹底解説! データベース圧縮のすべて～検証結果・事例に基づくベストプラクティス～

・ SQL処理を分割並列処理とバルク処理で高速化

SQLを直列Loop処理するようなバッチ処理は、Loopプロシージャを複数に分割して並列処理して帯域幅を有効活用するのと、バルク処理で1回のフェッチで複数の行を取得し、複数行をすばやく処理して高速化します。

・処理イメージ

・参考:
　- BULK COLLECTとFORALLによるバルク処理
　- Linux Traffic Controlを使用してレイテンシーをシミュレートし、Oracle Databaseのフェッチ・サイズを調査する

■ クラウドサービスでの考慮

● クラウドサービス機能でのレイテンシー削減

各クラウド・プロバイダーでレイテンシを考慮するポイントは、作成するシステム構成図の各アイコン単位にノード・レイテンシがあると考えることができます。

(1) Availability Domain(AD)/Availability Zones(AZ)
複数ある AD もしくは AZ間は距離が離れているため、接続するAD/AZによりレイテンシは異なります。
　　・AWS東京リージョンと大阪リージョンのAZ間レイテンシを比較してみた
　　・OCI-Azure Interconnectを使用したネットワーク・レイテンシとベスト・プラクティス

また、クラウド・プロバイダによってはレイテンシーを削減するための AZ があります
　　・AWS Local Zones

(2) Gateway
各クラウド・プロバイダーの Gatewayは複数ある場合はそれぞれ追加されるレイテンシが異なる場合や高速化するための追加オプションがある場合があります。
　　・参考: Virtual Network Gateway Ultra Performance

(3) Cloud 専用ネットワーク接続
クラウド・プロバイダーによって、高速化するオプションがある場合があります。
　　・参考: ExpressRoute FastPath

(4) Compute
コンピュートのオプションで、高速化するオプションがある場合があります。
　　・参考: Azure: 高速ネットワークの概要
　　　　　 AWS: Enhanced networking on Linux

これらの考慮ポイントにより、Azure と Oracle Cloud Infrastructure(OCI)接続で、2ms未満のレイテンシを実現できます。

・参考: Oracle Interconnect for Azure を FastPathと高速ネットワークで相互接続して

■ レイテンシ(遅延)の机上計算

コンピュート間のレイテンシは、距離に比例します。
レイテンシに影響ある要素は、ワイヤー長(距離)と通過ノードです。
データセンター(Data Center: DC) 間を光ファイバー・ケーブルで接続されている場合、光ファイバーケーブルは、ユーザーとデータセンターの間で直接的につながっているわけではありません。ファイバー・ケーブル上の光は、その経路に沿ってノード(機器)を通過します。

　・参考: 光遅延計算

そのため、ワイヤー長は綺麗な直線ではなく迂回もされているため、ノード・レイテンシ含めると実際のレイテンシは、1.5 倍程度はありそうだと考えることができます。
実際に Oracle Cloud の Tokyo Region と Osaka Regionを Googleマップで距離を調べて机上計算してみてみます。

● 光ファイバーの速さ

光速は、1秒間に地球を7周半回ることができる速さで、単に「光速」と言うとき、真空中の光速を示します。
光ファイバー中は光は全反射を繰り返して伝搬するため、直線距離より伸びます。そのため、一般的な真空中の速度約30万Km/秒の 2/3 の約20万Km/秒の速度になります

　・参考:
　　- 光速
　　- 光遅延計算

● 机上計算

1) Google Mapで距離計測
Oracle Cloud Region のデータセンターは所在が公開されていないため、FastConnect Location間の距離を Google Mapで計測してみます。
Oracle FastConnectのロケーションはここから確認できます。

・参考: Oracle FastConnectのロケーション

距離は約500Kmであることを確認できます。

2) 往復遅延時間(RTT)計算

RTT （Round Trip Time）の計算は次になります。

式

ワイヤー長(距離) / 光ファイバー速度 x 往復 = 往復遅延時間(RTT)

Google Mapの距離と光ファイバー速度から次のように計算できます。
　　・ワイヤー長(距離)= 500 Km
　　・光ファイバー速度 = 200,000 km/s

計算実行

500 km / 200,000 km/s x 2 = 0.005 (秒)
　　　　　　　　　　　　　　   = 5 (ms)

また、ここのWebから計算することもできます。

・参考: 光遅延計算

3) 迂回経路とノード・レイテンシー考慮
迂回経路とノード・レイテンシー考慮すると、1.5倍はありそうだと考えてみます。

迂回経路とノード・レイテンシー考慮

　5 ms x 1.5倍 = 7.5 ms

4) FastClnnect Location から Oracle Cloud Region間考慮
FastClnnect Location のデータ・センターから OCI Region間のレイテンシーを 1ms未満とすると、東京と大阪2つ合わせて、1 ~ 2 ms程度のレイテンシが追加されると考えられます。

FastConnect Location ~ OCI Region 間レイテンシー追加

　7.5 ms + 1 ms = 8.5 ms

● 確認

Oracle CloudでのRegion間レイテンシーは OCI コンソールで確認できます。
1) OCIコンソール
[ネットワーキング] > [リージョン間のレイテンシ]をクリック

2）リージョン間のレイテンシ画面
レイテンシを確認したいリージョン、Tokyo と Osakaを入力し、[Show]をクリック

結果は、8.1 ms で理想的な机上計算の結果となりました。

● サイト/リージョン間レイテンシ(遅延)情報

サイト間のレイテンシを公開しているプロバイダ
　・Azure ネットワークラウンドトリップ待ち時間統計
　・Equinix Latency Data
　・Megaport ネットワークレイテンシ
　・Oracle Cloud Public Cloud Regions

■ ネットワーク・パフォーマンスの測定

● レイテンシ(遅延)測定

クラウドでのネットワークレイテンシの測定より、
ネットワークのRTTレイテンシを測定するツールには ping、iperf、netperf などがありますが、すべてが同じように実装、構成されるわけではないため、ツールによって結果が異なる場合があります。ほとんどの場合、この質問に対する代表的な回答が得られるツールは、netperf であると考えられます。
ping は測定に ICMP パケットを使用し、nping、hping、TCPing などの ping をベースとするツールは TCP パケットを使用します。
レイテンシテストを実施する際に忘れてはならないのは、間隔やその他のツールの設定を記録、報告することです。特にレイテンシが低い場合は、間隔が大きな違いをもたらすからです。 pingの場合、 -i 0.001 オプションで間隔を netperfと同じ μs単位にすることができます。

また、Azure VM 間の RTT 測定に ICMP を使ってはいけないより、Virtual Machines の RTT 測定には、Datacenter 内のネットワーク高速化の仕組み上、TCP/UDP かつ、実際に到達できるポートに対する通信を利用する必要があります。

・実演デモ

How to measure network latency for Oracle Database applications in OCI (Doc ID 3008087.1)より、Oracle Databaseへのレイテンシ測定では、SQL と「set Timing on」を使用して RTT を測定することは不適切であり、よく知られたユーティリティ tnsping も使用すべきではありません。これらの方法はいずれも、RTT を正確に測定したり、必要な精度で測定したりすることはできません。

● スループット(帯域幅)測定

iperf3 は、TCP / UDP データストリーム（シングルスレッドまたはマルチスレッド）を作成し、伝送するネットワークのスループットを測定できるネットワークテストツールです。
一方のインスタンスをサーバー、もう一方のインスタンスをクライアントとして実行します。

・参考: ネットワークスループットを測定するためのツールの概要
・実演デモ

■ 必要レイテンシ(遅延)値の事前策定

コンピューターの距離により遅延、帯域が変わり、データ転送などの時間が変わることがあります。
tcコマンド(Traffic Control)を使用して、ネットワークのレイテンシ(遅延)とスループット(帯域幅)を制御してテストすることで、既存の処理に影響が出るか、どのくらいのネットワーク・パフォーマンスが必要か確認することができます。
ということで、tcコマンドで、遅延、帯域が制御できるか確認してみてみます。

・実演デモ

・参考: Linux Traffic Controlを使用してレイテンシーをシミュレートし、Oracle Databaseのフェッチ・サイズを調査する