本記事はこちらのブログを参考にしています。
翻訳にはアリババクラウドのModelStudio(Qwen)を使用しております。
クラウドネットワーキングにおけるレイテンシの理解と改善方法
以前の記事で議論したように、暗号通貨取引所は通常クラウド上で運用されています。Alibaba Cloudなどのクラウドプロバイダーは、インフラをリージョンに整理し、さらにそれを可用性ゾーン（AZs）に細分化しています。AZは、それぞれ専用のネットワークインフラを持つ隔離されたデータセンター群です。最も難しいレイテンシの課題の一つは、最終区間のレイテンシ（last-mile latency）を改善することです。これは、基盤となる多くのネットワークがクラウドプロバイダーによって抽象化されているためです。スイッチ、ルータ、物理的な経路から成るアンダーレイネットワークは事実上見えない状態になっています。この記事では、クラウドネットワークにおけるレイテンシがどこで発生するか、どのように測定するか、そしてその改善戦略について解説します。具体的には、以下の3つのシナリオに焦点を当てます。
- 自分のワークロードからの取引所へのレイテンシ
- Alibaba Cloud内の自分のワークロード間のレイテンシ
- 外部データセンターから自分のワークロードが配置されているAZへのレイテンシ
取引所へのレイテンシの測定
まず最初のシナリオとして、自分のワークロードから取引所へのレイテンシを測定する方法を見ていきましょう。
マッチングエンジンへの近接性
最低限のレイテンシを達成するには、インフラが取引所のマッチングエンジンにできるだけ物理的に近い場所に配置されている必要があります。これには適切なリージョンを選択するだけでなく、取引所がホストされている正確な可用性ゾーン（AZ）を特定することも含まれます。ただし、これが思っているよりも複雑である場合があります。特にロードバランサーが関与すると、問題が難しくなります。
取引所との接続とロードバランサー
前回の記事で述べたように、コロケーションのセットアップがない場合、パブリックインターネットを通じて取引を行うことになります。WebSocketを介して取引所に接続するための典型的なアーキテクチャは次のようになるかもしれません：
ここで重要な課題が生じます。DNSプロバイダーがリクエストを任意のロードバランサーにルーティングする可能性があり、必ずしも自分のワークロードと同じAZにあるロードバランサーに接続されるとは限りません。たとえロードバランサーのIPアドレスをpingで確認でき（例えばtracerouteのようなツールを使用して識別できた場合）、それが1ミリ秒のレイテンシを示したとしても、それが近接性を保証するものではありません。クラウドプロバイダーはしばしばクロスゾーンロードバランシングを採用しており、あなたの実際のWebSocketリクエストがロードバランサーAからAZ Bのバックエンドサーバーにルーティングされる可能性があります。これにより隠れたレイテンシが追加されます。
そのため、pingが低いレイテンシを報告していても、実際の通信経路はより複雑で最適ではない場合があります。
CDNの役割
さらに問題を複雑にする要因として、多くのDNSレコードがAlibaba Cloud独自のCDNを含むコンテンツ配信ネットワーク（CDN）に解決されることがあります。CDNは世界中のエッジノードを使用して静的コンテンツの配信を高速化しますが、実際の取引データを処理することはありません。例えば、ヨーロッパから香港ベースの取引所に接続する場合、リクエストが最初にヨーロッパのCDNノードにルーティングされることがあります。しかし、実際の取引処理は依然として香港で行われるため、数百ミリ秒のレイテンシが追加される可能性があります。より正確なネットワークレイテンシを把握するためには、より精密なツールが必要です。
タイムスタンプに基づくレイテンシ測定
前述の通り、pingのような標準的なツールは最も近い可視エンドポイントまでのネットワークの往復時間を測定するだけで、取引所内部での処理遅延やクラウド内のクロスゾーンルーティング、取引所のマッチングエンジンの実際の位置は考慮されません。より有用な洞察を得るために、アプリケーション全体のエンドツーエンドレイテンシを測定することが効果的です。これは、取引所がデータパケットを生成してからそれがシステムに到着するまでの時間間隔を指します。多くの取引所は市場データにタイムスタンプを含めており、データが生成された時刻を示しています。これをシステム上の到着時刻と比較することで、現実のレイテンシをかなり正確に推定できます。
分散システムにおける時計同期は非常に複雑なトピックです。異なるデバイス間でタイムスタンプを比較することは常に概算に過ぎません。幸い、Alibaba CloudのElastic Compute Service (ECS)インスタンスは、共有の内部NTP（Network Time Protocol）ソースと同期しています。もし取引所とワークロードの両方がAlibaba Cloud上でホストされている場合、測定結果はある程度信頼できますが、時計のずれによる誤差は常に存在します。Alibaba Cloudでの時計同期に関する詳細情報は、NTPドキュメントをご覧ください。
アプリケーションレイテンシの測定方法の例として、このブログのために作成した小さなPythonツールticktracerを紹介します。このツールは、Wireshark（libpcap経由）を使用してネットワークパケットをキャプチャし、パケット内のタイムスタンプと到着時刻を比較することで、半リアルタイムのレイテンシ分析を提供します。
Alibaba Cloud内でのレイテンシ測定
ワークロードがAlibaba Cloud内の異なるインスタンス、VPC、またはAZ間で通信する場合、AZ間およびAZ内のレイテンシを測定することが重要です。この目的のために、Alibaba CloudはNetwork Intelligence Service (NIS)を提供しています。
- NISコンソールにアクセスします。
- Cloud Network Performanceダッシュボードに移動します。
- 調査したいリージョンを選択します。
AZペア間のレイテンシを示すレイテンシ行列が表示されます。セルにカーソルを合わせると、現在のレイテンシ値が表示されます。「Display Latency」をクリックすると、行列全体にわたってデフォルトでレイテンシ値が表示されます。
これにより、デプロイメント内で高レイテンシのパスを簡単に特定できます。
外部ロケーションからのAlibaba Cloudへのレイテンシ測定
すべての取引所がAlibaba Cloud上でホストされているわけではありません。インフラが複数のクラウドプロバイダーや物理的なデータセンター