多国籍テック企業におけるネットワーク遅延の見落としと対策
米国SaaSに代表される多国籍テック企業ではCDNや往復削減が必須です。そうしないとアメリカと日本間で多くの通信が走り、遅くなってしまいます。西海岸から東京へのpingは100msぐらいです。
なぜ意外と気づかれないのか
開発はアメリカが主であることが多く、自分のラップトップでは問題を感じません。他の地域のメンバーはいちいち指摘しないことが多いですね。 静的コンテンツにCDNを利用しているのは当然だとしても、APIが漏れがちです。
影響範囲
日本の顧客や日本の法人はもちろん、他地域にも影響があります。米国と欧州は離れていますし、南米、中東、アフリカ、東南アジアも当然遠距離です。
米企業が顧客でも拠点は他国含めた多拠点であり影響が出ます。 そもそも米国は広く、西海岸と東海岸でもpingで60msぐらいかかります。サンフランシスコ〜ニューヨークの直線距離は約4,100kmです。東京からハノイより遠い。
また、多少歴史のある企業だと、エンドポイントを自前で運用していることがあります。そのためクラウドの進化に乗ることができていないことがあります。
AWSリージョン間通信の速度参考
通信往復の要素と往復を削減するには
2026年現在では以下のような要素が往復量を左右します。
- HTTP/3 (QUIC)
- TLS 1.3
- 鍵共有グループ
TCP（HTTP/1.1、HTTP/2） + TLS 1.2なら初回接続の往復(RTT)は基本3回です。内訳はTCPが1回, TLSが2回。 これを終えてからhttp通信が始まります。 日本国内同士なら1RTT 10msぐらいとすると30msで気にならないかもしれません。 これが50msなら150msとこれだけで知覚の壁を越えます。100msなら300msです。
TCP + TLS 1.3なら2 RTTで、TCPが1回、TLSが1回になります。
QUIC(HTTP/3) + TLS 1.3ならTLSが1回のみです。QUICとTLSのハンドシェイクが統合されています。
少しマニアックですが、鍵共有グループの選択によっても往復回数が変わることがあります。
例えば、FIPS対応などの理由でサーバー側が利用可能な鍵共有グループを制限している場合です。クライアントが最初のClientHelloで送信した鍵共有情報（key_share）がサーバーの要求と合致しない場合、HelloRetryRequestによって再送信を求められ、1 RTT増えることがあります。
ブラウザ側の挙動はサーバー運用者が直接制御できないため、主要なクライアントが最初から送信する鍵共有グループを考慮して、サーバー側の設定を決める必要があります。
CDNでRTTを短くする
CDNだと解決しやすい部分があります
TLS周りの初期往復時間の削減
CDNを利用していればTLSを解くのが近場のPOPまでですみ、初期の往復時間が削減できます。たとえ1 RTTでも効果的です。APIであっても前段に挟む価値があります。
ipv6化
日本ではコンシュマー向けの通信ではipv6のほうが速いことがあります。IETFは米国、インド、ドイツなどでも同様の傾向を報告しています。
APIをipv6化するのは手間がかかることがありますが、ここでもCDNを前段に挟むと簡単にエンドポイントをipv6化できます。
ちなみにCloudflare WARPをお使いの場合、ipv6アクセスならdedicated egress ipとは無関係に近くのデータセンターに通信できます。dedicated egress ipを各国分買うのは避けたいですね。
圧縮含むコンテンツ最適化
CDNはコンテンツデリバリーだけありBrotli / gzip / Zstd圧縮、Minifyなどもできます。APIならアプリ、プロキシサーバよりCDNに任せるほうが効果的だったり、改修が少なかったり、様々なフォーマットが使えたりするかもしれません。
キャッシュがなければPOPからオリジンまでの通信は残るとはいえ、それなりにCDNで解決できる部分はあります。
フロントエンドパフォーマンスチューニングは必須
今までの通り通信が発生するとオーバーヘッドがより大きくなるためパフォーマンス設計が重要です。
より優先度が上がる事項は
- キャッシュを活用しつつ、不要なリクエストを飛ばさないようにする
- preconnectで事前に接続する
- 直列呼び出しの並列化
マルチリージョンを意識すると多少優先度は上下するかもしれませんが基本的なパフォーマンス最適化がまずは大事でしょう。
測定して認識してみる
RUMが導入済みなら地域ごとに見てもらいましょう。違いが出ているはずです。まずは認識が大事ですね。devtoolの値を渡すのもよいでしょう。
大きめの公開サイトならCrUXも効果的です。Chrome ユーザーが実際にアクセスしたときの状況を反映したデータセットで、BigQuery版なら国といった軸で分析できます。
最後に
技術的な問題より、遅いとはっきり伝えるのが大事でしょう。遅いからビジネス上こうなると提案していきましょう。