【レポート】ネットワークパフォーマンス : 全てのパケットを精査する #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のエンジニア
• 輻輳アルゴリズム
  • Linuxの輻輳制御アルゴリズムは様々。ネットワーク環境に適したアルゴリズムを選択
  • 輻輳アルゴリズムのチューニングカーネルパラメータでアルゴリズムを確認、輻輳アルゴリズム自体はカーネルモジュールで提供されるので、modprobeでロードする
  • BBR
• 再送タイマー 短すぎても、長すぎても良くない
• 再送タイマー(rto_min)を短くする例
• キューのアクティブな管理 ここではキューをfq_codelに変更
• MTU MTUを大きくすることでオーバーヘッドの小さい、効率の良い通信に
• EC2拡張ネットワーキング
  • 従来の仮想NICはハイパーバイザーの処理がオーバーヘッドになる
  • Intel 82559のSR-IOVで仮想化レイヤーをバイパス
  • ENAでさらに性能アップ

やってみた

• テスト要件
• 1つ目 : HTTPSで0.5%のロス
  • テスト要件 　- p90とp99ラインで2本のグラフ。0.5%lossでどうなる？ 　- デフォルトのCubicと比較しillinoisでは？ p90が75％Fasterに
  • BBRはさらに良い
  • BBRのロスなしと比較
  • そもそも、CubicとBBRの両方ロスなしも比較
• 2つ目 : 再送タイムアウトの調整
  • p50とp99.99の比較 Web APIなどでは99.99%も求められることがあるのでは
  • RTOを50にしたら改善した
• 3つ目 : 大量アクセス ゴールはレイテンシの最小化
  • こちらは、ウィンドウ数を増やしてスループットを改善
• まとめ

所感

チューニング項目自体は一般的なTCPのチューニングがAWS環境でも有効なことがわかりますね。仮説と検証を繰り返す地道なところですが、AWSのネットワークリソースをより効率良く利用するために大事なポイントだと思います。皆さんのネットワークパフォーマンスの改善に役立つと嬉しいです。