【レポート】ネットワークパフォーマンス : 全てのパケットを精査する #reinvent #NET401
re:Intent2017のセッション「NET401 - Network Performance: Making Every Packet Count」のレポートです。
スピーカーはMike Furr(Principal Software Engineer, Amazon)です。
本セッションはネットワーク(主にTCP)のボトルネックを解明し、ベストパフォーマンスを発揮するための手法を解説します。
- TCPは優れた仕組みを持つ
- SSH、HTTP、*SQL、SMTPの下のレイヤーで動作
- ストリーミングデリバリ、フロー制御
- TCPのコネクション
- 3Wayハンドシェイク
- 送信データの制限 送信側、受信側それぞれの制限がある
- 送信遅延積
- 受信ウィンドウ
受信ウィンドウで受信可能なデータを通知
受信ウィンドウサイズの調節。Linuxカーネルパラメータの例 - 輻輳ウィンドウ ウィンドウは輻輳アルゴリズムによって管理され、パケットロス、レイテンシ、帯域幅が関係する
- 初期の輻輳ウィンドウは3
- 16に増やす例(Linux iproute2では
initcwnd
) - パケットロスによるTCPスループットへの影響
- TCPの再送でパケットロスの様子がわかる
netstat -s
ユーティリティーのretransmit
ss
ユーティリティでネットワークソケットの状況を確認 Send-Q、cubic、rto、cwnd、retrans辺りをチェックtcpretrans
で再送をリアルタイムに監視 作者のBrendan GreggはNetflixのエンジニア
- 輻輳アルゴリズム
- 再送タイマー 短すぎても、長すぎても良くない
- 再送タイマー(
rto_min
)を短くする例 - キューのアクティブな管理 ここではキューをfq_codelに変更
- MTU MTUを大きくすることでオーバーヘッドの小さい、効率の良い通信に
- EC2拡張ネットワーキング
やってみた
所感
チューニング項目自体は一般的なTCPのチューニングがAWS環境でも有効なことがわかりますね。仮説と検証を繰り返す地道なところですが、AWSのネットワークリソースをより効率良く利用するために大事なポイントだと思います。皆さんのネットワークパフォーマンスの改善に役立つと嬉しいです。