ウェブ広告のインフラについて(第5回) LinuxのTCP再送アルゴリズムとモバイルネットワークの相性の悪さ

だいぶ間が開いてしまいましたが、重い腰が上がったので5回目です。
今回はAWSなど従量制パブリッククラウドサービスを利用していて、なおかつパケ死寸前の同業他社のインフラ担当にはかなり耳寄りな話です。
内容自体は去年に社内勉強会で話したことと同じです。
その時のスライドも公開します。

さて、昨今ウェブ広告業界においてはスマホやタブレットを含むモバイルネットワークやワイヤレス通信(3G/4G/WiFi)の利用者がPCを逆転しそうなペースで増加しています。(個人的にまだ逆転したとは聞いてない)
最近では自宅でも固定回線を持たないユーザもかなり増えていますね。
固定回線で利用するPCとは異なり、特にモバイルネットワーク通信のRTTは激しく揺らぎます。
このRTTの揺らぎが、例によってLinuxのTCPスタックと激しく相性が悪く、非効率的な再送やNW機器の高負荷の原因になってしまいます。

とりあえず細かいウンチクはスライドみてください(手抜き)

雑にまとめるの以下のとおりです。

  • 移動中(電車)のユーザ数が日々の生活で眺めていてもとても多い。広告インフラ屋としてはこの人ら全員ユーザに見える
  • 都心はモバイルネットワーク網が発達している、といっても所詮ワイヤレスなためRTTの揺らぎがでかい
  • 広告配信ではRTTの揺らぎに対して、RTOの最適化が通信が短い間で終了するため補正ができない
  • 通信相手が消え去っても、多めに設定された上限値まで律儀に再送を実行する
  • キャリア側のルータの挙動が結局どうなってるのか読めない
  • 誤クリックによりユーザがBackを押した時のブラウザとOSの挙動も読めない
  • 参考だけど最低200msに設定されているのは、その下にNagleアルゴリズムがあるから

等あり、通信とサーバのコストを考慮して、再送回数を思い切って減らすことにしました。
最近はもうちょっと減らしてもいいかなと思っていたりもします。

echo 5 > sys/net/ipv4/tcp_orphan_retries

自社の場合は、当時でフロント側のnginxサーバ1台で1分間のTCP再送回数が2000回くらい減りました。
再送間隔を倍にしていった上で、5回であきらめることをどう評価するかは環境次第です。
上記の参照した値はnetstat -stで取得できる値です。
あくまでもパケット数が減るだけであって、bpsで見る総量はあまり減りませんが、確実に効果はあります。

また私事ですが、グループアワードとかやってるグループ会社が嫌で今の会社に転職したのですが、グループアワードとかやってる別のグループ会社に買収されてしまったので、広告系インフラエントリーも残り数回になるかもしれません。