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

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

Transcript

1. Amazon Elastic Compute Cloud (Amazon EC2) で 1 0 0 G b E が リ リ ー ス さ れ た の で 試 し て み た 株式会社スカイアーチネットワークス 福島 厚 17th September 2019
2. ⾃⼰紹介 名 前 ： 福島 厚 所 属 ： 株式会社スカイアーチネットワークス ⽣ 年 ⽉ ⽇ ： １９７２年４⽉１２⽇（⼦年の牡⽺座） 家 族 ： 既婚⼦供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. ⼤体１時間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. ⼤体６ストリーム・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. 仕⽅がないので複数プロセスを利⽤することに した。各プロセス１ストリームとして３０プロ セ ス ３ ０ ス ト リ ー ム ま で 測 定
32. /proc/interruputを⾒るとRSSが有効になって いる様に⾒受けられるので、複数プロセッサで の 処 理 が 恐 ら く 効 果 的 な は ず ※ Accelerated RSSやData Direct I/Oなど他の⾼速化 テクノロジが有効かは不明
33. キャッシュの有効利⽤という観点からもL1/L2 キャッシュがコア毎にあるので、プロセッサ単 位 に 分 割 し た ⽅ が 有 利
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. 出るときはほぼ １００Gbps 出るが⼤体２０プ ロセス程度で頭打ちになり80−１００Gbps の 間 で 値 が ば ら け る 。
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. これアップデートされないんでしょうか？