5
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

More than 3 years have passed since last update.

INTECAdvent Calendar 2020

Day 21

AWS/Azureのストレージ性能を、ファイル共有も含めてベンチマークで比較する

Last updated at Posted at 2020-12-20

はじめに

新しいPCを買ったり、自作PCを組み立てたら、ベンチマークを計測したくなりますよね。(え?自分だけ?)
クラウドでボチッと気軽に作成できるサーバも、性能が気になるところです。そこそこ大きいデータファイルを保存するために、AWSAzureストレージ性能についてスペックなどを調べましたが、目安となる数字はあるものの、実際のところどうなんだ?と思ってしまいました。

そんなわけで、ベンチマークを計測してみました。ローカルディスクのほか、別サーバでWindowsファイル共有した場合や、ファイル共有サービスも計測してみました。

必要なときに取り出せればいいファイルだったらS3などで安価に「保管」しておけばよいですが、オンラインで処理するファイルは高速にアクセスしたいですし、複数サーバからアクセスする場合も気になります。(データサイズが大きいと、コストも問題になりますけど・・・今回は性能にフォーカスします)

計測方法

CrystalDiskMark

ベンチマークは、「CrystalDiskMark」を使用して計測しました。(今回はWindowsベースで検討していたのでWindows寄りになっていますが、Linux系でも参考になることも多いと思います)
以前の記事 で自作したマイPCを計測してみると、以下のような結果でした。(うーん、快適)
image.png
SEQ1M」はシーケンシャルアクセス、「RND4K」はランダムアクセスで、それぞれ「Read」「Write」の速度を計測します。Q8T1などは、マルチキューやマルチスレッドの動作を表します。
※CrystalDiskMarkは、5回計測して一番良い値を結果としています。
※CrystalDiskMarkのベンチマークについてもう少し詳しく知りたい方は、「CrystalDiskMark」でHDDやSSDの速度を測定する方法!速度の目安とは? のような解説サイトもご覧ください。

補足(注意点)

計測は、2020年9~10月頃に実施したものです。
5回計測を何セットか行い、一番良いものを結果とした場合もあります。
計測する度に結果に変動もあったので、実際の環境によって結果は異なると思います。
今回の計測では、継続的な負荷は考慮していません。計測時間は数分~10分程度なので、バーストが有効な状態と考えられます。(AWSのバーストについては下記参照)
https://docs.aws.amazon.com/ja_jp/AWSEC2/latest/UserGuide/ebs-volume-types.html
AWSのは東京リージョン、Azureは東日本リージョンを使用しました。

計測結果

それでは早速、計測結果です。
計測結果の数値には、比較しやすいように背景色のバーがつけてあります。
SEQ1M500 MB/sRND4K50 MB/sバーがMAXになりますので、それを超えると違いはわかりませんが、まあMAXならかなり速いということです)
画面の解像度によっては見づらいかもしれませんので、その場合は画像を拡大してご覧ください。

[AWS] EBS(ローカルHDD)

スループット最適化HDD (st1)で計測した結果はこちらです。
image.png
st1は、ディスク容量が大きいほどスループット性能が高くなるので、シーケンシャルアクセスのSEQ1Mの結果が良いです。ただし、2000GB程度で頭打ちになるようですが。EBS作成時に表示されるベースラインスループットが「79 MB/s」でも、バーストが効いて500 MB/s以上出ていますね。(EBSは条件を満たすとバーストして性能が上がります)
RND4Kも容量を増やせば少し良くなりますが、HDDなのでランダムアクセス性能はあまり高くないですね。
EC2のインスタンスタイプをm5.xlargeに上げてみても、特に影響は無い
ようです。

[AWS] EBS(ローカルSSD)

汎用SSD (gp2)、**プロビジョンドIOPS SSD (io2)**で計測した結果はこちらです。
image.png
SSDの場合は、HDDに比べて全体的にRND4Kが良くなり、ランダムアクセス性能が高いことがわかります。しかし、料金の安いHDD (st1)と比べて、SEQ1Mの結果が良くない場合もあるので注意が必要です。
**汎用SSD (gp2)**では、ディスク容量によってIOPS性能が決まります。IOPSは主にランダムアクセスに影響する値ですが、容量を増やせばRND4KだけでなくSEQ1Mの値も良くなります。ですが、1000GBから2000GBに増やしても、RND4KのQ32T16の値が良くなるくらいで、それ以外は頭打ちになってしまうようです。
プロビジョンドIOPS SSD (io2)では、ディスク容量とは別にIOPS値を指定できます。IOPSを上げればRND4Kも良くなります。(どこが頭打ちまでかは調査していませんけど・・・) SEQ1Mの値は、2000 IOPSくらいまで上げればHDD (st1)に近い値になり、そこで頭打ちのようです。(SEQ1MのQ1T1の値は、HDD (st1)より若干低いです)
HDDと同様に、EC2のインスタンスタイプをm5.xlargeに上げてみても、特に影響は無い
ようです。

[AWS] インスタンスストア(NVMe:ローカル高速SSD)

NVMeは高速なローカルSSDで、インスタンスストアはEBSとは違って一時的なストレージです。特定のインスタンスタイプを選ぶとセットで付いてくるもので、容量も決まっています。
計測結果はこちらです。(最後の300GB*2は、用意された2つのディスクをRAIDでストライピングしています)
image.png
NVMeのRND4Kは全体的に非常に良い値で、EBSのSSDよりも高速です。ファイルサイズが小さいデータに頻繁にアクセスする際に有用です。
容量やインスタンスタイプによって差がありますが、SEQ1Mもかなり高速なものもあります。全般的にWriteよりもReadの方が2倍近く速いようです。

[AWS] Windowsファイル共有(EBS:HDD/SSD / インスタンスストア:NVMe)

続いては、m5.largeのEC2から、別のEC2のディスクをWindowsファイル共有して計測してみました。複数のEC2から共有ストレージとして使用するケースを想定しています。
AZが同一の場合AZが別の場合の2パターンで計測しています。計測結果はこちらです。
image.png
上にあるローカルでの結果と比較してみると、別サーバに接続するオーバーヘッドにより、速度が低下するケースが見られます。(もうちょっと比較しやすい表にすればよかった・・・)
SEQ1MもRND4Kも、全般的にQ8T1 / Q32T16ではほとんど変わりませんが、Q1T1では速度低下するケースがあります。特に別AZになると低下が大きく、Writeでは同一AZでも低下が見られます。Q1T1の結果が実際にどう影響するかは、アプリケーション等のディスクアクセス方法によると思います。
NVMeの場合は、RND4KのQ32T16でも低下が大きいですが、元が高速なのでそれでも速いですね。

[AWS] Amazon FSx for Windows File Server(HDD)

次は、自分でサーバを用意するのではなく、ファイル共有サービスのFSxに対して、m5.largeのEC2から計測してみました。
FSxは、シングルAZマルチAZ構成のパターンと、先ほどと同様にAZが同一の場合AZが別の場合のパターンで計測しました。また、スループットも何パターンか設定してみました。
HDDの場合の計測結果はこちらです。
image.png
結果としては、SEQ1MもRND4Kもあまり速くないですね。別AZの場合にQ1T1では速度低下するということは先ほどと同様です。(RND4Kは遅いせいか、あまり低下しないですが) マルチAZ構成にすると、SEQ1M Q1T1のWriteも低下するようです。
HDDの傾向としては、スループットを32 MB/s以上にしても性能はあまり上がらないようです。(ベースラインは確保されると思われますが)

[AWS] Amazon FSx for Windows File Server(SSD)

SSDの場合も同様に計測しました。計測結果はこちらです。
image.png
SSDの場合は性能はそこそこ良いですね。別AZやマルチAZ構成の傾向はHDDの場合と同様ですが、SSDの場合は、スループットを32 MB/s以上に上げていくと、性能が向上しました。さらにディスク容量を増やすことで、シングルAZしか試していませんがRND4K1 Q32T16の値も上がりました。
まあ、FSxのSSDは料金がお高いので、コストはよく調べておきましょう。

[Azure] データディスク(ローカルHDD)

さてここからはAzureの場合ですが、AWSに比べて簡易的に計測したので、計測のバリエーションは少ないです。
Azureの仮想マシンは、OS用のディスクに加えてデータディスクを追加することができますが、今回計測したのはデータディスクの方です。
ディスクには、ホストキャッシュというキャッシュの方式を設定することができ、これによってベンチマーク結果も大きく変わりました。ホストキャッシュは、「なし」「読み取り専用」「読み取り/書き込み」の3パターンがあります。
HDDの場合の計測結果はこちらです。
image.png
ホストキャッシュが「なし」の場合の性能は低いですが、キャッシュが効くと一気に速くなることがわかります。特にRND4Kは、HDDなのにNVMeのような速度が出ています。キャッシュが効いていない時は「なし」の速度になると思われるので、アプリケーション等の特性を考慮して判断する必要があります。
ディスク容量やサーバスペックのバリエーションは試してないのであしからず。。。

[Azure] データディスク(ローカルSSD)

SSDは、Standard SSDPremium SSDがあり、HDDと同様にホストキャッシュの設定ができます。
計測結果はこちらです。
image.png
SSDもホストキャッシュが効けば速いですね。
ホストキャッシュが「なし」の場合、全般的にStandard SSDよりもPremium SSDの方が良いケースが多いです。(一部逆転も見られますが) また、Premium SSDしか試していませんが、ディスク容量が大きい方が結果が良いケースも見られます。
「読み取り専用」では、VMサイズがD2_v4ではキャッシュによる伸びも少ないですが、D4_v4にすることでReadでは2倍近く結果が良くなり、D8s_v4ではさらに結果が良かったです。AWSのインスタンスタイプの違いとは異なり、VMサイズが結果的にディスク性能にも大きく影響する場合があるようです。
「読み取り/書き込み」を見ると、Premium SSDでキャッシュが効けば、全体的にパフォーマンスが良いですね。
ディスク容量を増やしても、結果が良くはならないようですね。

[Azure] Windowsファイル共有(データディスク:HDD / SSD)

Azureの場合も、別の仮想マシンに対してWindowsファイル共有して計測しました。
接続元VMサイズは、2パターン変えてみました。ディスク容量は128GBのみです。可用性オプションは特に設定していません。
計測結果はこちらです。
image.png
ファイル共有でもホストキャッシュが効いて速いようですが、SEQ1MのRead以外は、ローカルに比べて低下が大きいようです。
接続元をD2_v4からD4_v4にした方が、RND4K Q32T16やSEQ1MのWriteで結果が良くなりました。

[Azure] Azure Files(HDD / SSD)

ファイル共有サービスのAzure Filesも計測しました。
ストレージオプションとして、HDDの「クール」「ホット」「トランザクション最適化」、SSDの「Premium」があります。(HDDの違いは、主に冗長性オプションの違いです)
image.png
全体的にそこそこのパフォーマンスですね。
HDDの場合、どのオプションでも計測結果はほぼ同じです。ディスク容量によっても違いは無いようです。
SSDの場合は、ディスク容量を増やすことにより、主にRND4Kなどで結果が良くなりました。また、VMサイズをD4_v4に上げることで、主にSEQ1M Q8T1で結果が良くなりました。(Q1T1は逆に下がってしまいましたが)

まとめ

AWSの場合

  • ローカルストレージ
    • シーケンシャルアクセスを重視する場合は「スループット最適化HDD (st1)」
    • ランダムアクセスを重視する場合は「汎用SSD (gp2)」「プロビジョンドIOPS SSD (io2)」
      • gp2はディスク容量を増やすことで、シーケンシャル/ランダムアクセスの性能が上がる
      • io2はIOPSの設定値を上げることで、シーケンシャル/ランダムアクセスの性能が上がる
        • st1と同等のシーケンシャルアクセスに上げることも可能
    • 高速な一時ストレージは「インスタンスストア(NVMe)」
      • インスタンスタイプを選ぶとセットで付いてきて、容量も決まっている
      • 適切なストレージ性能のインスタンスタイプ(およびディスク容量)を選ぶ必要がある
  • Windowsファイル共有(別サーバへ接続)
    • 別サーバに接続するオーバーヘッドにより速度低下するため注意する
      • 特に別AZの場合はローカルに比べて速度低下が大きく、Writeでは同一AZでも低下する
    • 高速なストレージを使用すれば、ファイル共有でもそこそこ速い
  • ファイル共有サービス
    • FSxのHDDはあまり速くない(コストメリットはありそう)
    • FSxのSSDはスループットの設定値を上げることで速度が出る(コストは要注意)

Azureの場合

  • ローカルストレージ
    • ホストキャッシュの設定を有効にすることによって、計測結果は格段に良くなる場合がある
      • キャッシュが効かないとPremium SSDでもそれほど速くない
      • キャッシュが効く場合、計測する度に測定結果の変動が結構大きかったので注意
    • VMサイズがディスク性能に大きく影響する場合がある
  • Windowsファイル共有(別サーバへ接続)
    • ホストキャッシュが効けば、ファイル共有でもそこそこ速い
  • ファイル共有サービス
    • あまり高速な性能は期待できないが、データディスクのホストキャッシュ「なし」よりは速い
    • HDDは冗長オプションを変えても計測結果は変わらない
    • SSDの方がシーケンシャル/ランダムアクセスの性能がよい

おわりに

ベンチマークって性能を数値にしたものなので、戦闘力みたいでワクワクしますよね。
キャッシュとかバーストとか、その時々で性能が変わる要素もありますが、どのようなストレージを選択するかによって性能は全然違います。
今回はコストについてはほとんど触れていませんが、コストと相談しつつ、最適なストレージを選びましょう!

参考

CrystalDiskMark
「CrystalDiskMark」でHDDやSSDの速度を測定する方法!速度の目安とは?
Amazon EBS ボリュームの種類
Azure の仮想マシンのサイズ
【Azureディスク】VMのホストキャッシュ設定「読み取り専用」「読み取り/書き込み」の違い

5
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
5
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?