みなさん。こんばんは。初登場のフレンチブルドッグDXです。略してフレブルDXと申します。これから、どうぞよろしくお願いします。
誰でもよく使うEC2とEBSについて何を選んでどうチューニングすれば良いのか？困ることが多いので調べてみました。調べて分かったことをお伝えしていこうと思います。
EC2のパフォーマンス（CPU編）
EC2上でのパフォーマンスに影響を与える要因は色々あるかと思いますが、
まず一つ目としてCPUが考えられます。もし、T系のインスタンスを使っていれば、 EC2インスタンスの「CPUクレジットが足りない！」ことが可能性として考えられます。 確認方法としては、インスタンス詳細の「モニタリング」から、「CPUクレジット残高」で調べることができます。CPUクレジットとは何か？ご存じない方は過去コラムを参照→こちら。
また、インスタンスタイプによって複数のCPUが記載されているケースがあります。以下の例では、M5インスタンスで確認していますが、プロセッサでは「Skylake 8175M」と「Cascade Lake 8259CL）の2つが確認できますよね。R5も同様です。もしかして、同じインスタンスタイプでもインスタンスによってCPUが違うことがある・・・？
こちら、lscpuコマンドで真偽を確かめてみました。
お手軽ベンチマークは以下です。Amazon Linuxで試す場合の手順を示します。
$ curl -s https://packagecloud.io/install/repositories/akopytov/sysbench/script.rpm.sh | sudo bash
$ sudo yum -y install sysbench
$ sysbench cpu run
赤枠で囲った“events per second” の値に着目してみます。値が大きいほど速いんです。そしてなんと、スコアに差が出ましたよ。CPUはインスタンスを再起動すると変わることがあり得ます。
再起動を繰り返すと希望のCPUに出会えることがあったり・・・・？？（ここは、実証できていません。フレブルDX君の想像です）。やってみてベンチマークを比較した方がいらっしゃればぜひ教えてください。
EC2のパフォーマンス（ネットワーク帯域幅編）
DBとかAP系のミドル全部盛りじゃないと、あまりEC2のCPU/メモリそんな消費しないよね。
いつもスカスカじゃない、なのにお客様から処理が遅い、何とか速く改善できないのといわれるあなた！そんな時はNW帯域幅を疑ってみよう!
例えば 1秒間に合計で100MbyteのデータをEC2に対して送信していれば、その帯域の計算は
100[Mbyte] * 8[bit/byte] = 800[Mbit]
帯域としては800Mbpsとなります。この計算値がEC2のネットワーク帯域幅以下であることが推奨されます。
例として m5.16xlarge インスタンスは 64 vCPUs あります。リージョン内の別のインスタンスへのトラフィックは、使用可能な全帯域幅（20 Gbps）を利用できます。ただし、異なるリージョンの別のインスタンスへのトラフィックは、使用可能な帯域幅（10 Gbps）の 50% しか利用できません。
インスタンスの帯域幅を CloudWatch メトリクス でモニタリングしてみましょう！ インスタンスのネットワーク帯域幅と送受信されたパケットをモニタリングできます。 以下はLinuxのメトリクス名で記載をしております。Windowsだとメトリクス名が異なるので注意が必要です。
ネットワーク帯域がボトルネックになっている場合は上記のカスタムメトリクスで顕著にでます。
パラメータストアで下記な感じで登録します。
“ethtool”: { “interface_include”: [ “eth0” ], “metrics_include”: [ “rx_packets”, “tx_packets”, “bw_in_allowance_exceeded”, “bw_out_allowance_exceeded”, “conntrack_allowance_exceeded”, “linklocal_allowance_exceeded”, “pps_allowance_exceeded”
EC2ネットワーク帯域幅がボトルネックになっているのがわかったら？？⇒N系インスタンスに変更すべき？
ここはネットワーク帯域幅の課題とイコールではなく、各環境に依存することはもちろんですが、M5系に変更することで改善した経験があります。（※あくまでフレブルDXの経験です。。。）
EC2のパフォーマンス （EBS編）
Amazon EBS では複数のボリュームタイプが提供されておりパフォーマンス特性と料金が異なります。ここでは、みなさんも利用される機会の多いgp2、gp3について紹介します。
gp2 の I/O 性能はボリュームの割当サイズにより変動します。ベースラインパフォーマンスは 1 GiB あたり 3 IOPS で、最小値は 100 IOPS、最大値は 16000 IOPS です。例えば 100 GiB のボリュームでは 300 IOPS がベースライン (最低保障) 性能となります。
gp3 は最新世代の汎用 SSD ボリュームです。gp3 には I/O クレジットおよびバーストパフォーマンスの概念はありません。割当サイズによらず、ベースライン性能は 3,000 IOPS と 125 MiB/秒のスループットです。 追加でIOPSが必要になった際は、ボリュームの変更画面から追加でIOPSを設定することができます。 追加で課金が発生しますが、最大 16,000 IOPS および 1,000 MiBps に拡張できます。 また、 既存の gp2 ボリュームよりも GB あたり最大 20% 低い料金で利用することができます。
そもそもIOPSとは？IOPSの「IO」とは、インプットとアウトプットの頭文字を取ったものでデータの「書き込み」と「読み込み」を示しています。
1秒あたりの入出力操作数を表す測定単位のことを意味します。操作はKiB単位で計測することができます。
汎用 SSD ( gp3) についての更なるおすすめ
gp3 はチューニングの自由度が高く、I/O クレジットのような複雑な概念がありません。1 GB あたりの利用料金も gp3 のほうが 20% 安く利用できです。また割当容量が少ないボリュームの場合は、gp2 と比較して高いベースライン性能の恩恵を受けることが可能です。
※EC2 インスタンスタイプによる上限があります。EC2 のインスタンスタイプごとに Amazon EBS 専用の帯域幅が定められており、IOPS、スループットの上限が決まります。 gp3 や io2 ボリュームで高い性能を確保たとしても、インスタンスタイプごとの上限がネックとなり、性能を確保できないケースがあります 。
gp2からgp3への変更（オンライン）はどうやればできる？
現行リリースされているEC2インスタンスでこちらなら対応OK！
加えて、制約事項のうち「 gp2 から gp3 への変更」という操作に関係しそうな部分として以下があります。詳細はこちら。
・マルチアタッチが有効な EBS ボリュームでは不可
・ボリュームの変更でリクエストできる集計ストレージの最大数にはクォータ制限あり
・ボリュームが 2016 年 11 月 3 日 23:40 (UTC) 以前にアタッチされていた場合は、Elastic Volumes サポートを初期化する必要がある
・ボリュームサイズを小さくすることはできない
実際のパフォーマンスはどうでしょうか。CloudWatch を使用して、EBS ボリュームのステータスをモニタリングできます。また、モニタリングで得られたデータを使用して、ボリュームが提供する IOPS の平均数と平均スループットを求めることができます。
次の数式を使用して、EBS ボリュームが提供する IOPS の平均数を計算します。
実際の平均 IOPS (I/O 操作数/秒) = (Sum(VolumeReadOps) + Sum(VolumeWriteOps) ) ÷ ( Period – Sum(VolumeIdleTime) )
以上、フレブルDXがお届けしました。
