EC2 新インスタンスタイプ R4 のネットワークパフォーマンスを調べてみた

EC2 新インスタンスタイプ R4 のネットワークパフォーマンスを調べてみた

Clock Icon2017.01.19

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

こんにちは、菊池です。

本日(2017/1/19)、re:Invent 2016で発表されたEC2の新しいインスタンスタイプ、R4が東京リージョンで利用可能になりました!

R4 インスタンスのネットワークパフォーマンス

利用可能になったインスタンスタイプのスペックは以下の通りです。

タイプ vCPU メモリ(GB) EBS最適化 ネットワークパフォーマンス
r4.large 2 15.25 最大 10 ギガビット
r4.xlarge 4 30.5 最大 10 ギガビット
r4.2xlarge 8 61 最大 10 ギガビット
r4.4xlarge 16 122 最大 10 ギガビット
r4.8xlarge 32 244 10 ギガビット
r4.16xlarge 64 488 20 ギガビット

注目したのは、r4.largeからr4.4xlargeのネットワークパフォーマンスにある、「最大 10 ギガビット」の表現です。公式ドキュメントによると以下のような記載があります。

R4 インスタンスサイズをより小さくすると、最大スループットは 10 Gbps になります。これらのインスタンスでは、ネットワーク I/O クレジットメカニズムを使用して、平均帯域幅使用率に基づいてインスタンスにネットワーク帯域幅を割り当てます。これらのインスタンスでは、ネットワークスループットがベースライン制限を下回るとクレジットを獲得し、ネットワークデータ転送を実行するときにこれらのクレジットを使用できます。

つまり、T2インスタンスのCPUパフォーマスや、汎用SSD(GP2)のEBSボリュームのようなバーストするパフォーマンスとなるようです。

今回、このネットワークパフォーマンスが実際にどのようなスループットとなるか測定してみました。

測定環境

以下のようにr4.large、r4.xlargeのインスタンスを同一のリージョン/AZ内に起動してインスタンス間のネットワークパフォーマンスを測定します。

インスタンススペックを分けたのは、同時にクレジットが枯渇してインスタンス単体のパフォーマンスがわからなくなるのを避けるためです。(r4.large側が先にクレジット枯渇する想定です)

r4-nw-01

AMIはどちらもAmazon Linuxの最新版を利用し、測定ツールにはiperfを使います。iperfの導入や使い方は以下の記事を参照ください。

r4.xlargeをサーバとして以下を実行します。

$ iperf -s -i 1

r4.largeをクライアントとして以下を実行します。

$ iperf -c {サーバ側IP} -i 1 -t {実行時間}

上記の結果を確認します。

結果

途中で数回のインターバルを入れながら測定しました。

  • 10分間(600秒)継続してベンチマーク
  • 1分(60秒)のインターバルを入れて再度、ベンチマーク
  • 5分(300秒)のインターバルを入れて再度、ベンチマーク

結果は以下のようになりました。

r4-nw-02

  • 測定開始直後はスペック通り、10Gbpsのスループットが発揮されています。
  • 測定開始180秒の時点で、スループットが約745Mbpsに低下しました。
  • 60秒のインターバル後、10Gbpsまでのバーストが5秒間可能になっています。
  • 300秒のインターバル後、10Gbpsまでのバーストが25秒間可能になっています。

結果から、r4.largeのインスタンスの場合、10Gbpsの最大スループットを発揮できるのは連続で3分間、クレジットが枯渇した際のベースラインスループットはおよそ745Mbpsと推測されます。

※ r4.xlargeはより大きいベースラインスループット/クレジットが割り当てられている想定

まとめ

R4シリーズから導入された、バーストするネットワークパフォーマンスについて調査してみました。

T2など、最大パフォーマンスが一定でないインスタンスタイプは敬遠されることもありますが、R4のネットワークパフォーマンスは最小のr4.largeでもベースラインで700Mbps以上が発揮されますので、実質的に問題になることは少ないかと思います。また、r3.largeがネットワークパフォーマンス"中"となっていたことや、10G以上を使えるインスタンスが8xlargeクラスのインスタンスに限られていたことを考慮すると大きなスペックアップと言えるでしょう。

現在、ネットワークパフォーマンスの要件で巨大なインスタンスを利用していたケースからの移行も検討できるかもしれません。

 

Share this article

facebook logohatena logotwitter logo

© Classmethod, Inc. All rights reserved.