t1.micro と t2.micro のパフォーマンス比較

t1.micro vs t2.micro

先日 t1.micro から t2.micro への移行に関する記事を掲載しましたが、移行前に簡単なパフォーマンス比較を行ったデータに関しても掲載します。

はじめに

超巨大な台風8号が近づく中、瞬間最大風速75mってどんだけ?と思う今日この頃、皆様いかがおすごしでしょうか?
ちなみに、風速と感覚と被害 - いさぼうネット によれば、50mで「たいていの木造家屋が倒れる。樹木は根こそぎになる」、60mだと「鉄塔が曲がることがある」 とのこと。

恐ろしや。
 

前回の記事 EC2のt1.microをt2.microへ移行する の中で t2.micro のパフォーマンスに関して 「別記事で書こうと思います」 と書きましたが、今回簡単ですが t1.micro との比較した結果に関して載せてみます。

ディスクを Magnetic(Standard) のままにした場合だけでなく、SSD(General Purpose) に変更した場合の結果に関しても記載します。
テスト回数をそれほどこなしていないのである程度のブレはある可能性がありますが、移行を検討する場合の参考にはなるかと思います。

※写真は IM FREE から ( Women's Track and Field by wwarby )

環境

計測した環境を以下に示します。

t1.microt2.micro
OSAmazon Linux (3.10.42-52.145.amzn1.x86_64)
メモリ613MB1GB
ディスクMagneticMagnetic / SSD(General Purpose)

テスト方法

パフォーマンステストには Apache JMeter を利用しました。
100クライアントが同時アクセスした場合を想定したテストになります。

JMeter のテスト計画は以下のような感じで作成。
シナリオに沿ったリクエストではなく、適当にサンプリングしたページにリクエストを投げ続けるというテストになっています。

  • スレッドグループ : 100
  • Ramp-Up期間 : 1秒
  • ループ回数 : 100
  • 総リクエスト数 : 20000

テストするインスタンスは、他からのリクエストの影響等を受けないように、テスト用のインスタンスを別に立ててテストを行っています。

テスト結果

t1.micro

t1.micro result

t2.micro (Magnetic)

t2.micro result

t2.micro (SSD(General Purpose))

t1.micro(ssd) result

比較表

スループットの比較表は以下になります。

比率(%)はt1.microを100(%)とした場合の値です。

t1.microt2.micro
(Magnetic)
t2.micro
(SSD)
スループット295.3357.9368.8
パフォーマンス比(%)100(%)121.2(%)124.9(%)

CloudWatchによるCPU使用率

CloudWatch で CPU使用率 をモニタした結果も示します。

CPU使用率が上がっているのは GC 発生によるものです。

t1.micro では CPU使用率が100%になっていたのが、t2.microにおいては少なくとも現状はそうなる事がなくなったようです。
CPUがバースト可能となった事が影響しているものと思われます。

Average

EC2-CPUUtilization Average

Maximum

EC2-CPUUtilization Maximum

まとめ

弊社サイトに関しては、上記の通り、t1.microから t2.micro に移行する事でパフォーマンスも向上する結果となりました。

通常のWebサイトの場合には、CPUパワーよりもメモリが増強された事やネットワーク (I/O) パフォーマンスが Very Low から Moderate になった事の方が効いてくる気がします。

また、上記 CloudWatch の結果からわかるように、JavaのGCの影響でCPU使用率が上昇しスローダウンが発生しているような環境では、t2インスタンスに変更するメリットはより大きいといえるでしょう。
この辺りはバースト可能である点も活きているものと思われます。

EC2インスタンスにも当たり・外れがある

ご存知かとは思いますが、AWSではインスタンスにも当たり・外れがあります。
このテストを行った際にも t1インスタンスでスループットが 150強/s しか出ない場合がありました ( 上記 295.3/s と比べて 60%程度のパフォーマンス )。

※上記テストでは最も良い&悪いテスト結果 ( インスタンス ) は除外したので、ある程度妥当な比較結果になっているのではないかと思うのですが、こういった要因に左右される事も踏まえて参考にして頂ければと思います。

クラウドも所詮物理サーバの集合なので、古い世代のコンピュータに当たってしまった場合には、最新世代のコンピュータが割り当てられた場合に比べてパフォーマンスが落ちてしまうといった事があるようです。

このような場合、

$ cat /proc/cpuinfo

としてCPU情報を確認し、サーバの世代を確認。
古い世代の場合には、新たな世代の物理サーバが割り当てられるまでEC2インスタンスのstop/launch を繰り返すという手も考えられますが、最新CPUだったものが古い世代に戻ってしまう事も考えられます。
適当なところでの妥協は必要でしょう。

インスタンスを作り直すメリット

時間が経過する事で旧世代のサーバは徐々に新世代のサーバに置き換っていきます。

もし、現状実行中のインスタンスが大分前に起動したものであれば、インスタンスを作り直す事で(今よりも)新世代の物理サーバ上で実行される可能性は高くなると考えて間違いないでしょう。
今までは考えた事がなかったのですが、今回のパフォーマンス検証を行う上でこの点に関して改めて気づかされました。

現状、一旦起動したインスタンスは問題ない限り長期間起動しっぱなしという場合、一定間隔 ( 数か月 ) でインスタンスを作り直す作業をスケジュール化するという事も、パフォーマンスを改善するための有効な手段となりうるかもしれません。
古いCPUに割り当てられる可能性もありますが、確率としては逆になる可能性が高いですし、そうならなくとも動きの早いクラウドの世界、色々と気づく事もあるのではないかと思います。


今回のような新たなインスタンスタイプの提供といったイベントは、パフォーマンスを検討するよい機会になるのではないかと思います。t1.micro から t2.micro への移行に限らず、利用している環境を見直してみてはいかがでしょうか。