[レポート] The State of The Art – AWS / EC2 Networking #AWSSummit

丹内です。AWS Summit ２日目 D会場(Advanced Tech Track)で行われたセッションに参加してきました。

セッション概要

Speaker: Kevin Miller (Director, Software Development, EC2 Networking, Amazon Web Services, Inc.)

多くのアプリケーションは、ネットワーク I/O バウンドです。 これには、共通のデータベースを使ったアプリケーションや、サービスベースのアーキテクチャが含まれます。 しかし、オペレーティングシステムとアプリケーションは、多くの場合、高いパフォーマンスを実現するためにチューニングされてはいません。 本セッションでは、ネットワークのパフォーマンス低下につながる隠れた問題を明らかにし、可能な限り最高のネットワークパフォーマンスを得るためにそれらを克服する方法をご紹介します。 その他、最新のユースケースを含む AWS のネットワーク設計に関する最新情報も合わせてご紹介します。

TCPの性能改善について

• チューニングによって１３７％まで性能向上が期待できる
  • この数字は今回の発表用に行った実験からの数値
• TCPは多くの通信の基礎になっており、アプリケーションの性能改善に寄与する幅が大きい
• この発表での説明や実験は、JackとJillという2台のサーバが様々な状況でTCP通信を行うという想定
• TCPの性能に影響を与える様々なパラメータ
  • 帯域幅遅延積
  • TTT
  • 初期輻輳ウィンドウ
  • パケロス。実験によると、1%の喪失でも50%の速さのロスになってしまう
• 様々なツールで診断が可能
  • netstat
  • ss -ite。ソケットレベルでの診断。多くの情報を得られる
  • brendangregg/perf-tools。Linuxカーネルレベルでの分析ができる

チューニング

• Linuxの輻輳制御アルゴリズムを変える。デフォルトははCUBICだが、illinoisなど他にも幾つかある
• 再送タイマー(パケロスしたとみなす時間)を変える。過大/過小ではない適切な値に設定する必要がある
• キューイング。どうしても遅れるのでキューしないとバッファが溢れる
• tc qdiscコマンドでキューストラテジを確認とアルゴリズムの有効化

EC2拡張NW機能

• NW性能向上、CPU利用率低下、遅延低下、ネットワークジッター低下の効果が得られる
• 特定のファミリでドライバから利用可能
• MTUが8949バイトまで利用可能。　普通は1448まで
• MTUのチューニングを行う。

応用

• JackとJillのAmazon linuxがランダムビットを送る

実験1

• HTTPSで0.2%の損失が合ったとして、スループットへの影響を減らしたい。
• パケロスはtcコマンドでシミュレーション
• 全てデフォで損失なし->0.2%損失で帯域が4163Mbps->1469Mbps, 28秒から72秒
• これまでやった内容(初期輻輳ウィンドの増加、サーバ側TCPバッファを倍増、Illinois)で結果が変わる
  • Illinoisで3486Mbps28秒、性能が137%向上

実験2

• Jack-Jillが大容量データ転送、高RTTパス　例えば隣国など
• スループットの最大化を目指す
• デフォで2164Mbps 30.4sだったのがIllinois/クライアント-サーババッファ/AQMで性能が32%向上

実験3

• 大容量データ転送、低RTT。同じデータセンター内を想定
• するオーうっとの最大化と転送時間の最小化を目指す
• デフォで1500バイトMTUだと8866Mbps 74s

実験4

• トランザクションレートの高いHTTP
• 遅延の最小化を目指す
• デフォで2580 195ms
• Illinois 初期輻輳 186ms 4.2%向上

まとめ

• NWはブラックボックスという人が多いが、みんあLinuxツールを使って調べることができる
• 性能調整で性能を伸ばすことができる
• テスト、測定、変更では、NWを理解してすすめる

感想

AWSに特有の技術というより、AWSの性能を最大限引き出すために必要な一般的な知識、という印象を受けました。 具体的なトラブルシューティングの過程の説明に、AWSの機能を使ってこうする　という実践的な内容で、とてもおもしろかったです。