Amazon Elastic Compute Cloud (Amazon EC2) で 1 0 0 G b E が リ リ ー ス さ れ た の で 試 し て み た 株式会社スカイアーチネットワークス 福島 厚 17th September 2019 

⾃⼰紹介 名 前 ： 福島 厚 所 属 ： 株式会社スカイアーチネットワークス ⽣ 年 ⽉ ⽇ ： １９７２年４⽉１２⽇（⼦年の牡⽺座） 家 族 ： 既婚⼦供2⼈ t w i t t e r ： @NullPointerExp 

Motivation（動機） 

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

おーっすげー!! 

がちょっと気になる 

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

https://youtu.be/89fYOo1V2pA AWS re:Invent 2017: How Netflix Tunes Amazon EC2 Instances for Performance (CMP325) 

「例えば、4チャネルのPCI Express (PCIe) Gen 2 ス ロットにデュアル 10 GbE ネットワークインターフェー スカードが接続されていたとする。カードの最⼤帯域 幅は、2 × 10 GbE = 20 Gbps、スロットの最⼤帯域幅 は、4 × 4 Gbps = 16 Gbps となる。そのため、両ポー トのネットワークスループットは、 PCIe Gen2 の帯域 幅によって制限され、両者を同時に回線の最⾼速で動 かすことはできない (私は実際の場⾯でもこれをみたこ とがある)。」(P.513) 

他にボトルネックになるところは無いだろうか？ 

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 

例えばメモリ DDR4-2666 だとすると⼤体チャンネルあたり170Gbps。 100Gbps だと半分以上を占有する。 例えば CPU MTU9001だとするとざっくり150万パケット。0.67us で1パケット処理する必要がある。3GHz の CPUだと⼤ 体2000サイクル程度で処理する必要がある。 

利⽤できるインスタンスタイプ 

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

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

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

気になるお値段は？ 

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

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

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

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

やってみる！ 

測定環境 リージョン 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 デフォルト) 

1プロセスで-Pオプションで多重化 1 - 2 0 ス ト リ ー ム を 測 定 

0 5 10 15 20 25 30 1 2 3 4 5 6 7 8 9 10 送信 受信 

⼤体６ストリーム・25Gbps 付近で頭打ちになる 

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

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 

特定CPUで%System が 100%になっていることが確認できた。 C P U の 性 能 限 界 と 思 わ れ る 。 

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

仕⽅がないので複数プロセスを利⽤することに した。各プロセス１ストリームとして３０プロ セ ス ３ ０ ス ト リ ー ム ま で 測 定 

/proc/interruputを⾒るとRSSが有効になって いる様に⾒受けられるので、複数プロセッサで の 処 理 が 恐 ら く 効 果 的 な は ず ※ Accelerated RSSやData Direct I/Oなど他の⾼速化 テクノロジが有効かは不明 

キャッシュの有効利⽤という観点からもL1/L2 キャッシュがコア毎にあるので、プロセッサ単 位 に 分 割 し た ⽅ が 有 利 

No content

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 

出るときはほぼ １００Gbps 出るが⼤体２０プ ロセス程度で頭打ちになり80−１００Gbps の 間 で 値 が ば ら け る 。 

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

厳密にはパケットキャプチャを採取して確認す る必要があるが、毎秒10GB/約150万パケット を 確 認 す る の は ち ょ っ と ⾟ い 

Placement Group 

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

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

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 

今回の様に連続してバースト転送する様なユー スケースでは低レイテンシのメリットがあまり ⾒ 受 け ら な か っ た 。 

Lessons(学び) 

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

課 題 

• 搭載プロセッサ数や通信可能帯域が増えた結 果、パケットキャプチャや、CPU性能の様 に採取される性能データが増えているので、 これまでと異なる調査⼿法、データの表現⽅ 法が必要と感じた。 • また、プロセッサカウンタや bcc など利⽤ 可能な指標およびツールが増えているのでこ れらを有効に利⽤してより的確な分析ができ る様にしたい。 

と こ ろ で 

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