アーキテクチャ

ネットワークアーキテクチャ考 (31) フルリモートワークとインターネット速度事情とコンピューティングの分散

Miya Kohno
2020年8月11日

インターネットがあってよかった

未曾有のパンデミックで、切ない日々が続いています。ディジタル化を推進する立場からすると、本格的なディジタル化が加速されることは歓迎すべきですが、同時に、失われしものの大きさにも気付かされます。

本社開発部門に押しかけて「この機能の実装コミットしてくれなければ日本に帰れない」と直談判して、実装にこぎつけた思い出。国際カンファレンスや標準化ミーティングでの「みんなで同じ釜の飯を食う」感覚。一つになったと思った世界が、一気に分断されてしまいました。

でも、インターネットがあってよかった！それでもインターネットは今日も動いている。ネットワークオペレータの方々には感謝しかありません。早くこの状況が落ち着いて、大切だったものは復活し、不要だったものは切り捨てられると良いと思います。

ネット速度改善プロジェクト

という訳で、我々の職場もフルリモートになりました。そこで改めて自宅のインターネット速度を測定してみると、な、な、何と5-8Mbpsしか出ていません。

それまでも勿論、毎日のようにテレカンファレンスはしていましたが、ISDN —> ASDL時代からの連続だったこともあり、さほど気にしていませんでした。しかし、最近のAIR (Cisco Annual Internet Report) の発表 [*1] で、「日本ではブロードバンド回線速度の平均が既に86.5Mbpsで2023年には183.2Mbpsに達し、コネクティッドホームは年率23％で成長すると予測されます…」などとご説明しながら、自宅のあまりの惨状に愕然とせざるを得ない状況となりました。

そこで一念発起しまして、下記を実行。

・PPPoEからIPoEに変更

・フレッツマンションタイプの配線をVDSL方式から光配線方式に変更

・古いHubを撤去

と、箇条書きで書くとたった3行ですが、これには涙涙の物語があります。

まず、IPoEにする、ということは、ISPとVNE事業者と回線事業者へと、業者のdis-aggregationが起こります（契約窓口はISP）。で、IPoEへの切替え作業が発生する訳ですが、切替作業の時間が読めません（VNE事業者とワークフロー連携ができていないのだと思います）。

指定された日の夜に、もう良いかと思ってルータからPPPoE 設定を外したら、やはり繋がらなくなりました。PPPoE 設定を入れ直して、サポートセンターにいつ切替わるかを問合わせるのですが、これが大変。まず電話がつながりにくいし、やっとつながっても自動応答で、住所・電話・生年月日・ユーザIDなどを延々と告げ、それを音声認識で認識されたものを人工音声で延々と聞かされ、正しいか、正しくなければ再入力という非生産的な時間をやり過ごした後にようやっとオペレータにつながると、IPoEにいつ切替わるかを訊きたいだけなのに、使っているWi-Fiルータの機種とか、ルータのランプの状態とか、モードの設定状態とか、端末が何で何台つながっているか、とかをおそらくマニュアル通りに訊かれます。いやいやいや、つながらない訳ではなくて、、と言ってみるものの、サポートセンターの多くの人は、PPPoEとIPoEが何か、ということをたぶん理解しておられません。ブチ切れそうになりながら不毛な時間を過ごし、何度か担当者も変わって、ようやく、作業終わったら連絡もらえる、と言う約束を取り付けるも、実際に切り替わったのは、指定されていた日の3日後でした。その他にも、回線事業者の方は契約者が夫名義になっているため、「契約者の妻」からの問合せなんてマトモに相手にして貰えない、などなど。くー、思い出すだけで涙出る。

ともあれ、めでたく300Mbpsを超えることができました！！！やった！！！

しかし、本題はここからです！

意気揚々と家族に、「ね、ね、速くなったでしょう？」と訊いたところ、「そうかなぁ」「別にあまり変わらない」と言うつれない返事でがっくり。そう言われてみれば確かに、体感的に顕著な変化は感じられません。

それもそのはず、TCPやHTTP/2にはフローコントロールがあります。HTTP/2ではフローの多重化、アプリケーションレベルのAPI提供など、制御の仕組みは大きく進化していますが、輻輳制御や紛失時再送を行う限り、基本的なところは変わりません。

ここからは基礎のおさらい。Ackを受信するまで次のデータを送れないと言う「待ち」状態が発生すると、当然スループットが低下します。これを避けるためには、ウィンドウサイズを十分大きくして、Ackを待っている間もデータを送信し続けられるようにする必要があります。

TCPのウィンドウサイズは2バイトなので、基本は最大64Kバイト。Round Trip Time(RTT)を100msecとすると、

65,536 x 8 (bits) / 0.1 (sec) = 5,242,880 (bps)

つまり、どんなに回線速度が速くなろうと、RTTが100msecの場合は、スループットは5.24 Mbps留まり、と言う計算です！！！！

Window scale option [*2] を使えば、ウィンドウサイズを64Kバイト以上に増やすことはできますが、その分メモリを消費しますし、紛失時再送の負荷も高くなります。モバイル・ファーストな今日この頃は、帯域は増えるといえどもパケット紛失を避けることができません。そのため、ウィンドウサイズを無闇に大きくできるものでもありません。

やはり効果的なのは、RTTを小さくすることです。RTTが10分の1になれば、スループット10倍になります。

簡易的にpingでRTTを計測すると、cisco.comサーバは約150msec。先週108回目のミーティングがリモートで開催されたIETF（ietf.org）のサーバが約130msec、WebExも約110msec。やはり海を越えると100msec越えてしまう。。

しかしGoogle、あと意外にMIT（マサチューセッツ工科大学）はRTT小さい。

分散キャッシュが行き渡っているのでしょう。MITはCDNを使っているようです。確かにMITのWeb Site、体感的にサクサク感あります。

データ中心アーキテクチャの重要性！

ということで、改めまして、コンピューティングの分散、エッジコンピューティング、重要です！

またEnd to End Flow Controlは素晴らしい仕組みですが（最初に勉強した時は心底感動しました）、クライアント – サーバー型ではなくデータを生成し受け取るというパラダイムにおいては、コネクション中心ではなく、データやコンテンツを中心に考える、データ中心アーキテクチャ（Data Intensive Architecture ）が重要です。これまでもそのように話していましたが、実体験すると説得力が違う :)。

また、フローコントロール必要な場合は、アプリケーションがどうコントロールするか、という観点も重要です。どんなにブロードバンドが速くなっても、せっかく5G/Wi-Fi6が普及しても、このままのアーキテクチャでは、多くの場合価値が半減してしまいます！

なお、RTPなどVoIP/Streamingは、UDPを使っておりフローコントロールはないため、ひとまずこの問題はありません。ヤマハのSyncroom [*3] などは、やはり遅延は最小化する必要がありますが、回線速度の向上がある程度は直接QoE向上に結びつくと思われます。このパンデミックで、オーケストラやアンサンブルなどの演奏活動も以前のようにはできなくなっているので、このようなリモートアンサンブルの可能性にはとても興味がありますが、これを書き出すと長くなってしまうので、また別の機会に。

[*1] シスコが予測する「2023年のインターネット」

Cisco Annual Internet Report (2018-2023)