OCI Tokyo–Osaka間のネットワーク性能検証手順

はじめに

別リージョンにある2台のBaseDB間で、DRGのリモート・ピアリングを経由したプライベート通信を検証する際の手順を記す
BaseDBとしているのは、他の検証用を兼ねたインスタンスである為である
確認対象は、到達性、RTT、TCPの実効スループット、である。

検証日時は 2026-09-18 UTC。
測定値はこの時点・この2台・この負荷条件での観測値であり、OCIサービスの帯域保証値ではない。

OCIのリモートVCNピアリングでは、異なるリージョンのVCN間をプライベートIPで通信でき、インターネットやオンプレミス網を経由しない。
必要な要素は、各VCNにアタッチしたDRG、各DRGのRemote Peering Connection（RPC）、両者の接続、ルート・セキュリティルールである。Oracle公式ドキュメント

対象環境

項目	Tokyo	Osaka
リージョン	Japan East (ap-tokyo-1)	Japan Central (ap-osaka-1)
OCIサービス	Oracle Base Database Service（DBCS）	Oracle Base Database Service（DBCS）
DBシステム・シェイプ	VM.Standard3.Flex	VM.Standard3.Flex
ノード構成	単一ノード	単一ノード
CPU	1 OCPU（OS上では2 vCPU）	1 OCPU（OS上では2 vCPU）
メモリ	16 GB	16 GB
VNIC帯域	1 Gbps	1 Gbps
プライベートIP	10.90.0.85	10.100.10.105
サブネットCIDR	10.90.0.0/24	10.100.10.0/24
OS	Oracle Linux 8 系	Oracle Linux 8 系

VM.Standard3.Flex は、BaseDBの公式仕様では1 OCPUあたり16 GBメモリ、最大ネットワーク帯域は1 OCPUあたり1 Gbpsである。
この環境は1 OCPUなので、各BaseDBのVNIC帯域上限は1 Gbpsとなる。BaseDBのDBシステム仕様 Compute Shapes

構成図

図中のBaseDBサービス種別、シェイプ、CPU、メモリ、VNIC帯域、プライベートIP、サブネットCIDRは実測環境の値である。

検証方法

用語の説明

• RTT（Round-Trip Time）: パケットを送って応答が戻るまでの往復時間。値が小さいほど、通信を開始して応答を受け取るまでの待ち時間が短い。
• mdev（mean deviation）: Linuxのpingが表示するRTTのばらつき。小さいほど、測定中の遅延が安定していたことを示す。
• 実効スループット: 実際にTCPで受信できたデータ量を1秒あたりに換算した値。回線やVNICの上限、TCP制御、OS負荷を含むエンドツーエンドの結果である。
• 受信転送量: 30秒の測定中に受信側へ届いたデータ量。表記はGiB（1 GiB = 2^30 byte）に統一する。iperf3のGBytes表示もこの単位として扱う。

1. RTTとパケットロス

双方から相手のプライベートIPへ20回pingを実行した。

# Tokyo -> Osaka
ping -c 20 -W 3 10.100.10.105

# Osaka -> Tokyo
ping -c 20 -W 3 10.90.0.85

方向	送信/受信	ロス	RTT min / avg / max	mdev
Tokyo -> Osaka	20 / 20	0%	8.312 / 8.361 / 8.452 ms	0.120 ms
Osaka -> Tokyo	20 / 20	0%	8.532 / 8.598 / 8.696 ms	0.104 ms

応答末尾は以下のとおり。

# Tokyo -> Osaka
20 packets transmitted, 20 received, 0% packet loss
rtt min/avg/max/mdev = 8.312/8.361/8.452/0.120 ms

# Osaka -> Tokyo
20 packets transmitted, 20 received, 0% packet loss
rtt min/avg/max/mdev = 8.532/8.598/8.696/0.104 ms

2. TCP実効スループット

無償のiperf3 3.5を両BaseDBに一時インストールし、TCP/5201で30秒間測定した。単一TCPストリームと4並列TCPストリームを、両方向で各1回実施している。

初回はTCP/5201がホストのiptablesでREJECTされ、iperf3は次の応答となった。

error - unable to connect to server: No route to host

そこでOCIセキュリティルールは変更せず、測定時だけ受信側ホストに相手のプライベートIP /32 からのTCP/5201を許可した。

# Tokyoを受信側にする場合（Osakaだけを許可）
sudo iptables -I INPUT 1 -p tcp -s 10.100.10.105/32 --dport 5201 \
  -m comment --comment netperf-temporary -j ACCEPT

# Osakaを受信側にする場合（Tokyoだけを許可）
sudo iptables -I INPUT 1 -p tcp -s 10.90.0.85/32 --dport 5201 \
  -m comment --comment netperf-temporary -j ACCEPT

受信側で1回だけサーバーを起動し、送信側からクライアントを実行した。

# 受信側
nohup iperf3 --server --one-off > /tmp/iperf3-server.txt 2>&1 &

# 送信側: 単一ストリーム
iperf3 --client <相手のプライベートIP> --time 30

# 送信側: 4並列ストリーム
iperf3 --client <相手のプライベートIP> --time 30 --parallel 4

測定結果

方向	TCPストリーム数	実効スループット（Gbit/s）	受信転送量（GiB）	測定時間
Osaka -> Tokyo	1	1.013	3.54	30.04秒
Osaka -> Tokyo	4	0.919	3.21	30.02秒
Tokyo -> Osaka	1	1.010	3.53	30.04秒
Tokyo -> Osaka	4	0.983	3.43	30.02秒

代表的な受信側のコマンド応答は次のとおり。

# Osaka -> Tokyo, 1 stream
[  5]   0.00-30.04  sec  3.54 GBytes  1.01 Gbits/sec  receiver

# Osaka -> Tokyo, 4 streams
[SUM]   0.00-30.02  sec  3.21 GBytes   919 Mbits/sec  receiver

# Tokyo -> Osaka, 1 stream
[  5]   0.00-30.04  sec  3.53 GBytes  1.01 Gbits/sec  receiver

# Tokyo -> Osaka, 4 streams
[SUM]   0.00-30.02  sec  3.43 GBytes   983 Mbits/sec  receiver

考察

• 20回pingは双方向でパケットロス0%、平均RTTは約8.4〜8.6 msだった。これは約0.0085秒の往復時間であり、今回のTokyo–Osaka間の小さなICMPパケットに対しては低く、安定した値といえる。
• mdevは0.104〜0.120 msだった。平均RTTに対して約1%程度の小さなばらつきであり、30秒未満のping測定中に大きな遅延変動は観測されなかった。ただし、pingはアプリケーションの応答時間や長時間の混雑を保証するものではない。
• TCPの持続スループットは、単一・4並列とも両方向で0.919〜1.013 Gbit/sだった。VM.Standard3.Flexは1 OCPUあたり最大1 Gbpsで、この環境は1 OCPUであるため、実測値は各BaseDBのVNIC帯域上限にほぼ到達している。Compute Shapes
• 単一ストリームの1.013 Gbit/sは、30秒計測の集計・丸めによるわずかな超過であり、1 Gbpsを超える帯域保証を意味しない。設計上は最大1 Gbpsとして扱う。
• 4並列化で総スループットは上がらなかった。この測定ではDRGの能力より前に、送受信するBaseDBの1 Gbps VNIC帯域が上限になったと考えられる。
• したがって、本結果はDRGやOCIバックボーン単体の性能上限ではなく、BaseDBの形状、VNIC帯域、OSのTCP設定、同時負荷、セキュリティ設定を含むエンドツーエンドの実測値である。

より高い帯域を確認する場合は、まずBaseDBの形状とネットワーク帯域仕様を確認し、十分な帯域を持つComputeインスタンスを両リージョンに配置して、複数回・時間帯を変えて測定するのがよい。

原状復帰/お片付け

測定後、両BaseDBで以下を実施した。

# 一時的に追加した、相手IP限定の許可ルールを削除
sudo iptables -D INPUT -p tcp -s <相手のプライベートIP>/32 --dport 5201 \
  -m comment --comment netperf-temporary -j ACCEPT

# 一時ログを削除
rm -f /tmp/iperf3-*-server-*.txt /tmp/iperf3-*-server-*.json

# 今回導入したパッケージを削除
sudo dnf -y remove iperf3 lksctp-tools

各ホストで確認した応答は次のとおりで、ツール、依存パッケージ、一時ルール、一時ログは残っていない。

IPERF3_ABSENT
package iperf3 is not installed
package lksctp-tools is not installed
FIREWALL_RULE_ABSENT
LOGS_ABSENT

まとめ

TokyoとOsakaのBaseDB間では、プライベートIPによる双方向通信を確認できた。RTTは平均約8.5 ms、TCP実効スループットは両方向で約1 Gbit/sだった。