NIKKEI TECHNOLOGY AND CAREER

次世代AWS EBSボリュームタイプ gp3 のレイテンシを計測してみた

こんにちは。API・バックエンド/SREチームの清水です。2021年4月入社の新卒1年目です。 普段は、APIサービスの開発、インフラ監視や障害の調査などに関わっています。

今回のエントリでは、2020年12月に新しくAWSが発表したEBSボリュームタイプ gp3 について、IOのレイテンシやスループットの観点から性能調査を行ったので、gp2 との比較を行いながら紹介します。

gp3ボリュームとは

gp3は、AWSが提供するEBSと呼ばれるデータを保存するためのブロックストレージサービスの一種です。 様々な種類(ボリュームタイプ)が提供されており、通常、計算資源であるEC2と合わせて使います [1]

ここでのgpとは、General Purposeの略で、汎用で利用されるSSDボリュームであることを示しています。 この汎用SSDボリュームとしては、gp2 と gp3 が選択できます。 他にも、IOPSが保証されているSSDベースの io1 や io2、HDDベースの st1 と sc1 があります。

このうち、gp3 ボリュームは最新世代の汎用SSDボリュームです。gp2 の次世代にあたり、コスト上も有利とされています。 これについてAWSは、以下のように述べています [1]

ストレージ容量に関係なくパフォーマンスをプロビジョニングできる一方、既存の gp2 ボリュームよりも GB あたり最大 20% 低い料金を実現しています。

具体的には、gp3 では、容量によらず、3000 IOPS125 MiB/秒のスループットがベースラインパフォーマンス (基本性能) として保証されています。より大きな性能が要求されることが予想される場合は、追加料金により性能を拡張することもできます [1]

一方 gp2 は、ベースラインパフォーマンスが容量によって決定される仕組みです。このため、IO性能を確保するために、余分に容量を確保せざるを得ず、コストが嵩む場合もあります。また、巨大なIOが要求されたときは、バーストと呼ばれる操作により性能が拡張されますが、バーストバランスと呼ばれる「性能の貯金」を切り崩す形で行われ、使い果たすと性能が劣化することもあります。

これについての詳しい説明は、汎用ボリューム (gp2)で確認することができます。

以下の図は、gp2 と gp3 のベースラインでのIOPS性能です。概ね1000GiBまでは、gp3のほうがベースラインが高くなります。

EBSボリュームのベースラインパフォーマンス

なお、上記のグラフについては、Amazon EBS ボリュームの種類を参考に作成しました。

調査の背景

日経では、これまで主に gp2 のボリュームを利用してきました。現在、これまで述べたコスト削減の観点から gp3 の導入を始めています。

そんな中、社内で運用しているElasticsearchクラスターのEBSボリュームを gp3 に変更したところ、利用しているサービスのレイテンシがわずかに上昇する現象が見られました。以下の図のように、切り替え時点 (図中縦線から右側) から若干の増大が見られます。

Elasticsearchにおけるレイテンシの増大

社外でも、gp3 のレイテンシが gp2 よりも大きくなる場合があることが一部で報告されています [2]

このため、レイテンシ増大の原因を特定するべく、gp2と gp3 のIO性能を比較することとしました。

性能調査の概要

IOの性能調査では、実際に負荷を発生させてレイテンシやIOPS、スループットを計測しました。 負荷の内容(ワークロード)に対するストレージの特性の傾向を観察するため、いくつかの負荷状況を用意して検証しています。

ここでは、IO負荷計測ツールとして広く利用されている fio [3] を利用して、ディスクのレイテンシを計測します。 これは、AWSが公式に提示しているEBSボリュームのベンチマークでも利用されています。 負荷の内容としては、IOされるブロックサイズの大小、同時に同じIO負荷を実行するスレッド数(並列度)の大小の組み合わせで4パターン用意しました。 この他に、EBS暗号化の有無によっても性能差が発生するか検証を行いました。

また参考までに、Elastic社が公式に提供している Rallyを利用した、レイテンシ計測も行いました。このツールは、Elasticsearchの負荷を実際に発生させ、サービスタイムやレイテンシを計測することができます。今回は、Elasticsearchを gp2 と gp3 の双方に用意し、これに対してRallyを実行しています。ただし、Elasticsearchは、基本的にファイルシステムのキャッシュをかなり活用しているため、本エントリでは、参考値として扱います。

前提条件

今回の性能調査では、1台のEC2に対し、gp2 、gp3 の各ボリュームをマウントして行いました。 まず、EC2インスタンスの仕様は以下です。

  • EC2インスタンスタイプ: r5.large
  • OS: Amazon Linux 2

また、EBSは以下のような仕様で用意しました。 なお、gp2 は、実際には2000秒まで3000 IOPSにバーストされます。これにより、IOPS性能がgp3のベースラインと同等になります。また、gp3については、スループット性能を128MiB/sでプロビジョンしました。これは、100GiBの容量を持つgp2ボリュームが、バーストしたときの最大性能と同じくするためです。

リージョンはEC2、EBSともにap-northeast-1dを利用しています。また、fioによる調査では、ボリュームの暗号化・非暗号化の影響についても調査しました。まずは、暗号化ボリュームを基本として各種レイテンシ等を計測、次いで、非暗号化ボリュームでも同様の計測を行いました。

ボリュームタイプ 容量 スループット設定 IOPS設定 フォーマット デバイス名 マウントポイント
gp2 100 GiB - (最大 128MiB/s) 300 (最大 3000) xfs /dev/sdb /home/ec2-user/gp2
gp3 100 GiB 128MiB/s 3000 xfs /dev/sdc /home/ec2-user/gp3

参考までに、この設定での東京リージョンにおけるコストは、gp2 が 約 12.00 USD/月に対し、gp3 が 約 9.74 USD/月と安価になっています。

fioを使ったディスクレイテンシの計測

負荷計測ツール fio では様々なパラメータを変更して、負荷状況を作り出すことができます。例えば、IOのブロックサイズについても、単調に同じ負荷を与え続けるだけではなく、ブロックサイズごとに割合を指定して負荷を与えるパラメータも存在します。この詳細は、公式ドキュメントのjob-file-parametersに詳しく説明されています。

ディスクへの負荷内容の定義

fioでは、負荷の内容をジョブファイルとして定義して、実行することができます。これらの実行は、gp2、gp3 のボリュームをマウントしたディレクトリに対して行いました。

本エントリでは、負荷の内容に従って、以下の4パターンのジョブを作成しました。なお、アクセス方式はシーケンシャルアクセスで、読み書きは同時に計測します。また、本エントリでは、同時実行スレッド数は並列度と呼ぶこととします。

並列度 ブロックサイズ 補足
2 16K ブロックサイズが小さく、並列度が少ない
2 256K ブロックサイズが大きく、並列度が少ない
16 16K ブロックサイズが小さく、並列度が多い
16 256K ブロックサイズが大きく、並列度が多い

以下が今回用いたものと同じジョブ定義です。ブロックサイズはbs、並列度はnumjobsで指定します。試験対象となるディレクトリは、directoryに指定します。今回は、gp2を/home/ec2-user/gp2、gp3を/home/ec2-user/gp3にマウントするため、設定項目にこれらのパスを指定しています。また、バッファを回避するため、ダイレクトIOモードを指定しています。これはdirect=1により指定できます。

試験の都合上、並列度ごとにファイルを分けています。したがって、定義中のnumjobsが16のものも用意しています。まずは、これらのIO状況におけるレイテンシを計測しました。

[global]
size=128m
filename=fio-bench
direct=1
directory=/home/ec2-user/gp2

[Sequential-ReadWrite-16k]
rw=readwrite
bs=16k
numjobs=2
group_reporting
stonewall

[Sequential-ReadWrite-256k]
rw=readwrite
bs=256k
numjobs=2
group_reporting
stonewall

計測結果のIOPS・スループット性能の比較

はじめに、暗号化ボリュームに対しての負荷を実行しました。基本的な性能として、IOPSやスループットの性能を観察します。 IOPSについては読み書きの合算値としています。

これらの調査の結果として、gp2 と gp3の両者ではIOPSやスループット上の性能差はほとんど見られないことがわかりました。また、ワークロードの内容によっては、IOPS性能の上限に達したために、スループットの性能が発揮できなかったと考えられる場合や、いずれの性能も上限値を達成できなかったと考えられる場合も観察されました。

IOPS

3000 IOPSを達成できた箇所を赤字で示します。いずれのボリュームタイプでも、ブロックサイズが小さく、並列度が大きいときに3000 IOPSを達成しました。一方で、1000程度や550程度に留まったケースも見受けられました。

この結果から、ワークロードの内容によっては、いずれのボリュームタイプも規定どおりのIOPS性能を発揮できないことがあることがわかります。

並列度 IOブロックサイズ gp2 (回/s) gp3 (回/s)
2 16K 2706 2878
2 256K 1024 1024
16 16K 3068 3068
16 256K 545 546

スループット

スループットは、今回の設定では各ボリュームタイプも 128.0 MB/s が上限となります。上限値を達成できた場合を赤字で示します。 以下の結果を見ると、ブロックサイズが小さい場合 で、スループットが大幅に上限値を下回っている場合が存在しました。

したがって、IOPSと同様に、負荷によっては上限までのスループット性能が発揮できない場合があることがわかります。

読み込み

並列度 IOブロックサイズ gp2 (MB/s) gp3 (MB/s)
2 16K 21.94 23.34
2 256K 137.98 137.98
16 16K 24.60 24.60
16 256K 70.02 70.03

書き込み

並列度 IOブロックサイズ gp2 (MB/s) gp3 (MB/s)
2 16K 21.36 22.73
2 256K 124.16 124.16
16 16K 24.50 24.50
16 256K 69.88 69.90

レイテンシ値の比較 (50パーセンタイル)

より良好な結果を得た方について赤字で示します。結果を見ると、読み込みの場合で、gp3 のレイテンシが大きくなる傾向が見受けられました。特に、ブロックサイズが大きく並列度が小さい場合を除いて、gp3がわずかに不利な結果となっています。

一方で、書き込みに関しては、いずれの場合でも gp3 のレイテンシが小さくなる結果となりました。特に、並列度が小さく、ブロックサイズが大きい場合においては、gp2よりも高速となっています。

また、同じ並列度でブロックサイズを変化させたとき、gp3 はレイテンシの増大が小さく抑えられている場合がありました。例えば、読み込み・並列度2で、ブロックサイズを16Kから256Kに変化させた場合に注目してみます。gp2 では、418μs → 932μsと500μs近くレイテンシが増大したのに対し、gp3 は280μs以下の増加に留まっています。

読み込み

並列度 IOブロックサイズ gp2 (μs) gp3 (μs)
2 16K 418 470
2 256K 932 748
16 16K 5024 5088
16 256K 30336 30592

書き込み

並列度 IOブロックサイズ gp2 (μs) gp3 (μs)
2 16K 1032 860
2 256K 2416 1800
16 16K 5600 5536
16 256K 31872 31616

レイテンシ値の比較 (90パーセンタイル)

同様に、90パーセンタイル値も観察しました。こちらも、より良好な結果を得た方について赤字で示します。読み込みで並列度が低い場合に着目すると、gp3のレイテンシが比較的大きくなる傾向が観察できました。特に、並列度が小さくブロックサイズが大きいとき、1000μs近く遅い結果となっています。一方で、書き込みでは、基本的に、gp3 のほうが良好な結果となりましたが、やはり読み込みと同様に、レイテンシが大きくなるケースが存在するようです。

また、50パーセンタイル値と比較すると、gp3 はレイテンシに大きいばらつきが生じる可能性があることもわかりました。特に、並列度2・ブロックサイズ256Kでの読み込み時に着目した場合では、gp2は、932μs → 2896μsと約2000μs程度の変化であったのに対し、gp3は、748μs → 3824μsと約3000μs程度変化し、比較的大きな変動が観察されました。

読み込み

並列度 IOブロックサイズ gp2 (μs) gp3 (μs)
2 16K 494 740
2 256K 2896 3824
16 16K 5344 5472
16 256K 31360 31360

書き込み

並列度 IOブロックサイズ gp2 (μs) gp3 (μs)
2 16K 1208 1096
2 256K 3184 4640
16 16K 5984 5920
16 256K 33024 32384

非暗号化ボリュームとの比較

最後に、暗号化ボリュームと同じ方法で、非暗号化ボリュームでも同様のレイテンシ計測を行いました。gp2 と gp3 で読み込み時の50パーセンタイル値のレイテンシを比較してみると、gp3 では、暗号化・非暗号化による影響は大きくないと考えられます。一方で、gp2 では並列度が小さい場合、特にブロックサイズも小さい場合で、暗号化によるレイテンシへの影響が観察されました。従って、gp2 では、ストレージ暗号化によって、レイテンシ値が影響を受けることがあるかもしれません。

  • gp2
並列度 IOブロックサイズ 暗号化 (μs) 非暗号化 (μs)
2 16K 418 278
2 256K 932 732
16 16K 5024 5088
16 256K 30336 30336
  • gp3
並列度 IOブロックサイズ 暗号化 (μs) 非暗号化 (μs)
2 16K 470 462
2 256K 748 724
16 16K 5088 5088
16 256K 30592 30592

結果と考察

これらの比較を踏まえると、gp3 には以下の特性があることが考えられます。

  • 負荷の内容により、平均的なレイテンシが gp2 より大きくなる可能性がある
  • 書き込みについては、平均的に高速な書き込みを期待できる
  • 読み書きが遅くなるオペレーションが発生する可能性がある (特に並列度が小さい場合)
  • 暗号化の有無によるレイテンシ値への影響は、gp2より小さい

Elasticsearch Rallyを使ったベンチマーク

Elasticsearchでの実際の負荷におけるレイテンシの計測も行いました。Rallyは、Elastic社が中心となって開発しているElasticsearchのOSSのベンチマークツールです [4]。 実際のデータ操作やクエリ操作等の擬似的に行い、サービスタイムやレイテンシを含む、様々な指標を得ることができます。 負荷試験はTrackという形で定義され、いくつか標準の定義も提供されています。また、このTrackは、Taskと呼ばれるクエリ操作などの負荷試験のタスクが含まれています。更に、これらのTaskはchallengeというセットにまとめられています。

方法

本エントリでは、TrackとしてNOAA Trackを利用することにしました。challengeとしては、append-no-conflictsを利用します。なお、試験先のElasticsearchは、Docker Composeを用いて、ストレージが gp2、gp3 になるよう、それぞれ構築します。

各Elasticsearchに対し、負荷試験を走行させます。なお、Rallyの導入方法については、Installationを参照してください。

負荷試験は、以下のようなコマンドで実行できます。このうち、target-hostsで試験先のElasticsearchを指定します。この場合では、localhost:9203でElasticsearchが稼働しています。また、pipeline=benchmark-onlyは、自身でElasticsearchを構築して負荷試験する場合のみ利用するオプションです。同一EC2から、別々のEBSの性能を比較するため、このオプションを利用します。また、report-fileにより、結果をファイルに出力することもできます。

$ esrally race --track=noaa --challenge=append-no-conflicts \
--target-hosts=localhost:9203 --pipeline=benchmark-only \
--report-format=csv --report-file=~/es-benchmarks/gp3.csv

また、Rallyでは、LatencyService Timeというメトリクスが得られますが、本エントリでは、このうちの後者をレイテンシとして扱います。これは、前者のLatencyが、Elasticsearchが処理を受け付けるまでの待機時間を含んだ値であり、実際に内部の処理に要した時間はService Timeとして表現されているためです。

結果と考察

まずは、各負荷試験のレイテンシ値を示します。ここでは、50パーセンタイル値の比較を紹介します。なお、実際はより詳細な値が得られますが、本エントリでは、小数点以下2桁となるように丸めています。

以下の結果では、より良好な結果を得られた値を赤字で示します。いずれも検索を実行するElasticsearchのクエリですが、一つのTaskを除いて gp2 が有利な結果となりました。特にTaskによっては、40ms程度の差を生じているものも観察されました。

なお、gp3 が有利となった range_field_conjunction_small_range_big_term_query は、検索条件として、整数値の範囲 rangeが小さい一方、文字列一致 term でヒットする件数が多いような検索を実行しています。

今回の実験では、Elasticsearchのデータディレクトリを gp2 と gp3 で切り替えた以外、同一条件で実施しました。したがって、ワークロードの内容とEBSストレージの特性により、Elasticsearch上でのレイテンシに差異が発生することが示唆されます。ただし、Elasticsearchでは、ファイルキャッシュが活用されるため、単純にストレージの性能のみでレイテンシが増大・減少したとは言い切れないかもしれません。

Task gp2 (ms) gp3 (ms)
range_field_big_range 60.84 86.83
range_field_small_range 28.27 56.56
range_field_conjunction_big_range_small_term_query 32.14 32.24
range_field_conjunction_small_range_small_term_query 59.52 63.42
range_field_conjunction_small_range_big_term_query 270.14 241.06
range_field_conjunction_big_range_big_term_query 581.95 585.75
range_field_disjunction_small_range_small_term_query 89.18 94.04
range_field_disjunction_big_range_small_term_query 155.60 194.64

おわりに

本エントリでは、次世代EBSボリュームタイプ gp3 のレイテンシ計測について紹介しました。

ストレージの性能は、ワークロードの種類や内容によって大きく左右されます。今回は、非バッファなIOにより、gp3 のディスク特性を観察してみました。結果としては、IOの並列度やブロックサイズが小さくなるなど、負荷の状況によっては、gp2 よりレイテンシが大きくなることもあるようです。一方で、適切なIOを行うことで、gp2 よりも高速かつ安価に利用できる利点もあります。

また、本エントリでは触れませんでしたが、これらの実際のIOの状況や、ファイルキャッシュの状況を調査するには、eBPFを活用したiovisor/bccというツールも有用です。

本エントリを、皆様の開発にお役立ていただければ幸いです。

備考

このエントリは、2021年5月時点での調査結果に基づき作成しました。

参考文献

[1]: Amazon EBS ボリュームの種類, https://aws.amazon.com/jp/ebs/volume-types/ (accessed 27 April 2021).

[2]: Looking into performance of the new EBS gp3 volumes, https://silashansen.medium.com/looking-into-the-new-ebs-gp3-volumes-8eaaa8aff33e/ (accessed 6 May 2021).

[3]: fio - Flexible I/O tester rev. 3.26, https://fio.readthedocs.io/en/latest/fio_doc.html (accessed 27 April 2021).

[4]: Rally, https://github.com/elastic/rally (accessed 27 April 2021).

清水赳
ENGINEER清水赳

Entry

各種エントリーはこちらから

キャリア採用
Entry
新卒採用
Entry
短期インターン
Entry