Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Amazon Elastic Compute Cloud (Amazon EC2) で 100 GbE がリリースされたので試してみた

Amazon Elastic Compute Cloud (Amazon EC2) で 100 GbE がリリースされたので試してみた

2019年9月17日 第5回 NW-JAWS で発表した資料です。

90171e1fc9b773439274e660025769a7?s=128

Atsushi Fukushima

September 17, 2019
Tweet

Transcript

  1. Amazon Elastic Compute Cloud (Amazon EC2) で 1 0 0

    G b E が リ リ ー ス さ れ た の で 試 し て み た 株式会社スカイアーチネットワークス 福島 厚 17th September 2019
  2. ⾃⼰紹介 名 前 : 福島 厚 所 属 : 株式会社スカイアーチネットワークス

    ⽣ 年 ⽉ ⽇ : 1972年4⽉12⽇(⼦年の牡⽺座) 家 族 : 既婚⼦供2⼈ t w i t t e r : @NullPointerExp
  3. Motivation(動機)

  4. https://youtu.be/mDNHK-SzXEM AWS re:Invent 2018 - Monday Night Live with Peter

    DeSantis
  5. おーっすげー!!

  6. がちょっと気になる

  7. 原著は2013年発⾏ とちょっと古い

  8. https://youtu.be/89fYOo1V2pA AWS re:Invent 2017: How Netflix Tunes Amazon EC2 Instances

    for Performance (CMP325)
  9. 「例えば、4チャネルのPCI Express (PCIe) Gen 2 ス ロットにデュアル 10 GbE ネットワークインターフェー

    スカードが接続されていたとする。カードの最⼤帯域 幅は、2 × 10 GbE = 20 Gbps、スロットの最⼤帯域幅 は、4 × 4 Gbps = 16 Gbps となる。そのため、両ポー トのネットワークスループットは、 PCIe Gen2 の帯域 幅によって制限され、両者を同時に回線の最⾼速で動 かすことはできない (私は実際の場⾯でもこれをみたこ とがある)。」(P.513)
  10. 他にボトルネックになるところは無いだろうか?

  11. USE メソッド • U t i l i z a

    t i o n ( 使 ⽤ 率 ) • S a t u r a t i o n ( 飽 和 ) • E r r o r s ( エ ラ ー ) http://www.brendangregg.com/usemethod.html
  12. 例えばメモリ DDR4-2666 だとすると⼤体チャンネルあたり170Gbps。 100Gbps だと半分以上を占有する。 例えば CPU MTU9001だとするとざっくり150万パケット。0.67us で1パケット処理する必要がある。3GHz の

    CPUだと⼤ 体2000サイクル程度で処理する必要がある。
  13. 利⽤できるインスタンスタイプ

  14. https://aws.amazon.com/jp/ec2/instance-types/

  15. https://aws.amazon.com/jp/ec2/instance-types/

  16. https://aws.amazon.com/jp/ec2/instance-types/

  17. 気になるお値段は?

  18. ★ https://aws.amazon.com/jp/ec2/pricing/on-demand/

  19. ⼤体1時間500円ぐらい 対向で使って1時間1000円ぐらい 2−3時間の検証なら2−3000円で実施できそう

  20. ⼤体新橋のサウナ⼀回分 それならお⼩遣いでなんとかなりそう

  21. 実機を買うと100万円以上の出費

  22. やってみる!

  23. 測定環境 リージョン us-west-2 (オレゴン) AZ us-west-2b (単⼀AZ) インスタンス タイプ c5n.18xlarge

    CPU Intel(R) Xeon(R) Platinum 8124M CPU @ 3.00GHz OS Amazon Linux 2 測定ツール iperf 3 MTU 9001 (OS デフォルト)
  24. 1プロセスで-Pオプションで多重化 1 - 2 0 ス ト リ ー ム

    を 測 定
  25. 0 5 10 15 20 25 30 1 2 3

    4 5 6 7 8 9 10 送信 受信
  26. ⼤体6ストリーム・25Gbps 付近で頭打ちになる

  27. 性能情報を確認してみると

  28. 0 20 40 60 80 100 120 2019-09-12 05:37:13 UTC

    2019-09-12 05:37:14 UTC 2019-09-12 05:37:15 UTC 2019-09-12 05:37:16 UTC 2019-09-12 05:37:17 UTC 2019-09-12 05:37:18 UTC 2019-09-12 05:37:19 UTC 2019-09-12 05:37:20 UTC 2019-09-12 05:37:21 UTC 2019-09-12 05:37:22 UTC 2019-09-12 05:37:13 UTC 2019-09-12 05:37:14 UTC 2019-09-12 05:37:15 UTC 2019-09-12 05:37:16 UTC 2019-09-12 05:37:17 UTC 2019-09-12 05:37:18 UTC 2019-09-12 05:37:19 UTC 2019-09-12 05:37:20 UTC 2019-09-12 05:37:21 UTC 2019-09-12 05:37:22 UTC 2019-09-12 05:37:13 UTC 2019-09-12 05:37:14 UTC 2019-09-12 05:37:15 UTC 2019-09-12 05:37:16 UTC 2019-09-12 05:37:17 UTC 2019-09-12 05:37:18 UTC 2019-09-12 05:37:19 UTC 2019-09-12 05:37:20 UTC 2019-09-12 05:37:21 UTC 2019-09-12 05:37:22 UTC 2019-09-12 05:37:13 UTC 2019-09-12 05:37:14 UTC 2019-09-12 05:37:15 UTC 2019-09-12 05:37:16 UTC 2019-09-12 05:37:17 UTC 2019-09-12 05:37:18 UTC 2019-09-12 05:37:19 UTC 2019-09-12 05:37:20 UTC 2019-09-12 05:37:21 UTC 2019-09-12 05:37:22 UTC 2019-09-12 05:37:13 UTC 2019-09-12 05:37:14 UTC 2019-09-12 05:37:15 UTC 2019-09-12 05:37:16 UTC 2019-09-12 05:37:17 UTC 2019-09-12 05:37:18 UTC 2019-09-12 05:37:19 UTC 2019-09-12 05:37:20 UTC 2019-09-12 05:37:21 UTC 2019-09-12 05:37:22 UTC 2019-09-12 05:37:13 UTC 2019-09-12 05:37:14 UTC 2019-09-12 05:37:15 UTC 2019-09-12 05:37:16 UTC 2019-09-12 05:37:17 UTC 2019-09-12 05:37:18 UTC 2019-09-12 05:37:19 UTC 2019-09-12 05:37:20 UTC 2019-09-12 05:37:21 UTC 2019-09-12 05:37:22 UTC %idle %iowait %nice %steal %system %user all cpu0 cpu1 cpu10 cpu11 cpu12 cpu13 cpu14 cpu15 cpu16 cpu17 cpu18 cpu19 cpu2 cpu20 cpu21 cpu22 cpu23 cpu24 cpu25 cpu26 cpu27
  29. 特定CPUで%System が 100%になっていることが確認できた。 C P U の 性 能 限

    界 と 思 わ れ る 。
  30. そもそも iperf3 は単⼀プロセス/スレッドで多 重化しているので処理が特定 CPU に偏る。

  31. 仕⽅がないので複数プロセスを利⽤することに した。各プロセス1ストリームとして30プロ セ ス 3 0 ス ト リ ー

    ム ま で 測 定
  32. /proc/interruputを⾒るとRSSが有効になって いる様に⾒受けられるので、複数プロセッサで の 処 理 が 恐 ら く 効

    果 的 な は ず ※ Accelerated RSSやData Direct I/Oなど他の⾼速化 テクノロジが有効かは不明
  33. キャッシュの有効利⽤という観点からもL1/L2 キャッシュがコア毎にあるので、プロセッサ単 位 に 分 割 し た ⽅ が

    有 利
  34. None
  35. 0 20 40 60 80 100 120 1 2 3

    4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 e35329ba 87e4a23c 93b64963
  36. 出るときはほぼ 100Gbps 出るが⼤体20プ ロセス程度で頭打ちになり80−100Gbps の 間 で 値 が ば

    ら け る 。
  37. おそらくウィンドウスケールや流量調整・輻輳 制御などの関係でTCPが帯域を使い切らないよ うに程よく調整しているためと思われる。 また各ソケットが協調して輻輳制御しているわ けではないのでそれぞれが個別に計算した結果 ⼀⻫に流量調整すると全体としてのスループッ ト が 下 が

    る 可 能 性 が あ る 。
  38. 厳密にはパケットキャプチャを採取して確認す る必要があるが、毎秒10GB/約150万パケット を 確 認 す る の は ち

    ょ っ と ⾟ い
  39. Placement Group

  40. • クラスタープレイスメントグループ • 低レイテンシ • 同⼀AZ内に配置 • シングルフローで 10 Gbps

    • 2つのインスタンス間の通信の最⼤速度は遅い⽅の速度になる。 • パーティションプレイスメントグループ • 異なるパーティションに配置 • 耐障害性の向上 • スプレッドプレイスメントグループ • 異なるラックに配置 • 耐障害性の向上 https://docs.aws.amazon.com/AWSEC2/latest/WindowsGuide/placement-groups.html
  41. • クラスタープレイスメントグループ • 低レイテンシ • 同⼀AZ内に配置 • シングルフローで 10 Gbps

    • 2つのインスタンス間の通信の最⼤速度は遅い⽅の速度になる。 • パーティションプレイスメントグループ • 異なるパーティションに配置 • 耐障害性の向上 • スプレッドプレイスメントグループ • 異なるラックに配置 • 耐障害性の向上 https://docs.aws.amazon.com/AWSEC2/latest/WindowsGuide/placement-groups.html
  42. 0 10 20 30 40 50 60 70 80 90

    100 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 766cd482 14b0fd5f 0940f98e
  43. 今回の様に連続してバースト転送する様なユー スケースでは低レイテンシのメリットがあまり ⾒ 受 け ら な か っ た

  44. Lessons(学び)

  45. • 100Gbpsの様な⾼速ネットワークを使⽤す る場合はマルチプロセス、マルチスレッドを 利⽤して複数のプロセッサに処理を分散する 必要がある。 • TCPを複数ストリーム並列に分散する場合は、 輻輳制御、流量制御によって帯域上限付近で は必ずしも全開の性能が出るわけではない。 場合によっては他のプロトコルの利⽤も検討

    する。
  46. 課 題

  47. • 搭載プロセッサ数や通信可能帯域が増えた結 果、パケットキャプチャや、CPU性能の様 に採取される性能データが増えているので、 これまでと異なる調査⼿法、データの表現⽅ 法が必要と感じた。 • また、プロセッサカウンタや bcc など利⽤

    可能な指標およびツールが増えているのでこ れらを有効に利⽤してより的確な分析ができ る様にしたい。
  48. と こ ろ で

  49. これアップデートされないんでしょうか?