5G MEC 往復遅延の分布をもう少し
さて、先行記事（実測編） では KDDI 5G MEC （その実体は AWS Wavelength インスタンス）相手に ping 往復遅延の Best case を示しました。
今回は計測したデータ全体の分布を見て、距離による影響や KDDI 閉域網とInternet 越しアクセスの差などを見たいと思います。
使用した計測データ
計測機器・計測環境などについては先行記事をご覧下さい。先行記事に示した環境のうち、今回は成績が良かった Smartphone を用いた ping RTT (Rount Trip Time) のデータを使います。
先行記事で示した結果は、大阪にある MEC つまり Wavelength インスタンスとの通信に関するものだけでした。Best case を示すことが目的だったので当然そうなります。しかし実際の計測は以下の四つのインスタンスを対象に行っていました。
- Wavelength instance （大阪）
- Wavelength instance （東京）
- （通常の）EC2 instance （大阪）
- （通常の）EC2 instance （東京）
以後、それぞれ WL-Osaka, WL-Tokyo, EC2-Osaka, EC2-Tokyo と略記します。
対象による差異
全体の傾向
まずは上記四つの対象ノードによる計測値の分布を見ます。（計測は京都から）
計測はある地点で ping を上記四つの対象に向けて 10 回飛ばして記録し、少し移動してまた10回飛ばして記録する、といった方法で行っています。ただし最初の一回目のレスポンスタイムはどうも不安定なようなので、今回のデータからは外しています。
グラフはこの「ある地点でのある対象から得た 9 つのレスポンスタイム」を、縦に並べて打点したものです。色は対象ノード、縦軸はレスポンスタイム、横軸ラベルは計測地点を示します。
見ての通り、教科書的というか Wavelength の方が EC2 より早く、また東京より大阪の方がより早くレスポンスが届いています。そしてこれは今回の偶発でしょうか、東京の EC2 インスタンス向けの通信がえらく遅滞していたようです。
詳細比較
細かく比較するために、グラフの下部を拡大します。EC2-Tokyo の大遅延な 6 打点がグラフの範囲外にあることに留意してください。
先に述べた、距離による遅延の違いや閉域網であることの優位性が、よく可視化されています。
- 大阪・東京で 10ms 程度の遅延差が RTT で生じる（端末は京都）
- 閉域網内か Internet 経由かでは、RTT 最良値では差が出ないが、最悪値では差が出る（閉域網内アクセスの方が安定度が高い）
WL-Osaka (大阪のMEC) に対するばらつき
やはり値が安定して良かった WL-Osaka つまり大阪の Wavelength インスタンスについては 13 回の計測を行っています。それらをざっと並べてみます。横軸ラベル3, 4, 5 は同一箇所で繰り返し計測していますが、それ以外は5−10mずつ移動して計測しました。
見ての通り、かなり安定しています。ただ、東京の EC2 インスタンス向けの時にあった「ときどきひどく遅くなる」現象が見られます。（今回の実験では 9 x 13 計測のうち 2 回）
先と同様に拡大します。遅延の大きな 2 データはグラフの上に消えて、見えていません。
平均や偏差といった数値に丸めてしまうと見えてこないミクロな傾向を感じて貰えればと思います。（大したデータ数ではありませんが、元データに興味のある方はリクエスト下さい。お渡しします。）
おわりに
これがとりあえず計測時点の、京都四条烏丸界隈での KDDI 5G MEC のレスポンスと、その安定度ということでしょうか。つまり条件を揃えれば、まあまあ20-30ms くらいが期待できそうです。私が ONS/ONES などでずっと聞いていた 5ms で返ってくる、といった「究極的なゴール」にはまだ距離感がありますが、まあ、そうなるんだなという実感を得るには充分な数字と思います。
例えば現時点の KDDI 5G は NSA つまり 4G/LTE 網の上に乗っています。これが SA になり、スライシングを含めた 5G らしい構造で伝送されれば、遅延・ばらつきともにかなり改善されるはずです。そして今回の結果は京都から大阪まで（四条烏丸から堂島？）の 50-60Km 程度、11 ホップを超えた数字です。これが例えば四条烏丸交差点に MEC が来たら、距離遅延はほぼゼロに、ホップ数もかなり減って、さて何ミリ秒短かくなるでしょう。そのようにして徐々にこの「究極的」な数字に近づくのだろうなと思えます。
まあ、そういう妄想はひとまずおいて
私が今回の実験で得たかったのは、まさに今回示したグラフでした。私は何にせよ、こういう具体的なデータと体感がないと、そこから先の考え事が出来ないのです。例えば今回のグラフを見ると、この 5G mobile の性質からは（この不安定さが完全に消せるとは思えないので）、最悪ケースを見て「これしか出来ない」と考えるのではなく、最良ケースに何かしら良いことがある応用を考えたくなります。
そう言えば先日ゲーム屋さんから「ロスト（や遅延）があれば過去データから線形補間して対応する。それでだいたい問題無い」と聞いて「ああなるほど！」と思ったものです。データが無い時はそれなりに。早くデータが届いたらよりリアルになる。良いじゃないですか。
（もちろん最悪値に合わせて設計しなければならないアプリケーションの方が多いのでしょうけど、まあそっちには今は興味が湧きません。）
今後の計画
今回は遅延、それも RTT だけを調べましたが、次はある程度まとまったデータを転送した場合の傾向を調べようと思います。それから、四条烏丸交差点近辺に機材を設置して長期計測をしたいと考えています。
片手間なのでなかなか進まないのですが。ボチボチと。皆さんも（KDDI に限らず）MEC について何か分かったらぜひ共有しましょう。情報発信お待ちしています。