はじめに
TiDBのようなShared NothingアーキテクチャのDBにおいて、ノード間通信のレイテンシは重要な要素です。
TiDB Cloud Dedicatedでは、デフォルトで3つのAvailability Zoneにまたがる冗長性を確保しています。ここで問題になるのがAZ間通信のレイテンシです。
本記事ではAWSのNetowork Managerの機能を利用して、様々なネットワーク通信のレイテンシを見ていきます。
AWS Network Manager Infrastructure Performance
AWSでは、わざわざEC2を起動してPingしなくとも、Network Managerでネットワークレイテンシを確認でき非常に便利です。これは Infrastructure Performanceと呼ばれる画面を利用します。
ここでは、AZ内、AZ間、Region間（東京 - 大阪）を見てみましょう。
なお、実際に確認してみたところ、ここで表示される数値はネットワークレベルのレイテンシで、実際のPingはこの数値よりレイテンシが高くなります。
AZ内通信レイテンシ
過去1週間の東京リージョン（apne1-{az1,az2,az4})ネットワークレイテンシを見てみます。
AZにより差はありますが、概ね0.1msのオーダーです。
AZ間通信レイテンシ
よくAZ間通信はだいたい1ms程度などと言われていますが、実際のところどうでしょうか。
この図を見るとAZ間といっても均一ではなく、どのAZ間かによって値が大きく異なることがわかります。特にapne1-az4との通信が遅く、最小値と最大値ではおよそ2.5倍の差があります。
ちなみに大阪リージョン(apne3-*)では、ここまでの違いはありません。大阪リージョンとオハイオ（use2-*) のAZ間レイテンシは下図です。
TiDBクラスタでは、RaftでTiKVノード間の冗長性を確保しています。仮に均等にRaftリーダーが散っているとして（実際デフォルトではそのようにリーダーのスケジューリングが行われています）、ホットスポットが生じないように均等にリーダーを利用するとすると、一番遅いAZ間通信レイテンシに律速されることになります。
もちろん耐障害性と性能のトレードオフではあるのですが、AZ間通信レイテンシを抑えるようにがんばってほしいものです。この状況はここ数ヶ月変わっていません。
リージョン間レイテンシ
東京 - 大阪間のレイテンシはだいたい8ms程度です。
まとめ
ここから、単一AZとAZ間通信のレイテンシは、6倍〜10倍程度の差があることがわかります。絶対値としては1-2ms程度でたいしたことがありませんが、数万〜数10万qpsを処理する分散データベースのようなシステムでは、影響も大きくなるのでまとめてみました。