EC2 Windows Server のディスクIO性能を2倍にしてみた【記憶域スペースと記憶域プール】

記事タイトルとURLをコピーする

クラウドインテグレーション部 技術1課 宮形 です。 2021年12月入社となります。転職活動のときに、サーバーワークスのBLOGは何度も閲覧しておりました。

まさか入社1か月を待たずに自分で執筆できるとは思いませんでした。 おそるべしスピード感サーバーワークス!

前職で Windows Server や Azure、Office365、Intune といったMicrosoft製品を取り扱っていたので AWSでも役立つ情報を発信できないかと思い、Windows Server 「記憶域スペースと記憶域プール」の検証を行うことにしました。

経緯

過去経験でAWSではありませんでしたが「記憶域スペースと記憶域プール」に助けられたことがありましたので紹介したいと思います。

対象者

  • Windows Server ご利用者
  • EC2のディスク性能に不満を抱えている方

検証内容の説明

先に検証結果となりますが、EC2 Windows Server の「記憶域スペースと記憶域プール」(以下:記憶域スペースと記)を用いることで、約2倍のIOPSを出せる結果となりました。検証環境での結果となりますので、皆様の環境で同じ結果になる保障はありません。ご了承ください。

「記憶域スペース」は、Windows Server のデスクトップに出てくる「サーバー マネージャー」の左メニューバー「ファイルサービスと記憶域サービス」から利用します。『これってどういう時に使うんだろう?』と思っていた人は多いのではないでしょうか?私もその一人でした。

f:id:swx-miyagata:20211215114119p:plain

AWSのEC2を使ってみると「オンプレミスのサーバーと比較してディスクIOが遅い」と感じたことはありませんでしょうか? これには EC2が利用する仮想ディスク EBS (Elastic Block Store の略称) 毎にきめられるIOPS上限が影響している可能性があります。 EBSを作成する際に下記の図にようにIOPS上限が表示されます。

f:id:swx-miyagata:20211215114251p:plain

このIOPS上限を上げるためには、ざっくり言うとEBSのサイズ(GiB)を大きくする必要があります。当社の先輩が、過去ブログでこの点を説明しておりますのでご参照ください。

blog.serverworks.co.jp

高いIOPSを出したいが、むやみにディスクサイズを大きくしてしまうとAWS利用料が高額になってしまいます。 ディスクサイズは小さく抑えて、高いIOPSを出したい場合はどうすればよいのか?ということが課題になります。

今回検証する Windows Server 「記憶域スペース」でAWS利用料を抑えつつ、高いIOPSが出せないか試したいと思います。

「記憶域スペース」には Windows Server のディスク管理を効率化する機能がいくつか提供されています。このうちの 「記憶域プール」では、複数ディスクを仮想的ひとつのディスクプールとし、データ保持の設定によって 物理サーバーでいうところのRAIDのような使い方ができます。RAIDには、RAID-0、RAID-1、RAID-5、RAID-10 などレベルがあります。 この中でディスクIO性能が一番高いとされる RAID-0 ストライプ をサーバー内で構築することで、EC2のディスク性能が改善するか試してみるのが今回の検証内容となります。 f:id:swx-miyagata:20211215135527p:plain

なお、RAID-0はデータ保護機能が全く無いので、物理サーバーでは通常選択しないと思います。AWS の仮想ディスクになる EBS は、クラウド側でデータが多重保管されており、 何もしなくても対障害性を有しているので、RAID-0 ストライプを選択してもこの点は心配無用となります。 Amazon EBS(EC2 ブロックストレージボリューム)| AWS

検証結果

実際にやってみた結果をご説明します。 検証環境で、2台のEC2を作成します。1台目はEBSを1個アサイン、2台目はEBSを5個アサインし「記憶域プール」でRAID-0に設定します。 2台のEC2で同じベンチマークツールを用いて、アサインしたEBSのIOPS性能を比較します。

東京リージョン、サイズ t3.midium、OS Windows Server 2019 のEC2インスタンスを2つ作成します。 t3.midium はEBS最適化利用が有効なインスタンスとなります。当社過去ブログで「EBS最適化」を説明していますのでご参照ください。 blog.serverworks.co.jp

f:id:swx-miyagata:20211215115125p:plain

続けて、2台のEC2インスタンスにそれぞれ下記のようにEBSをアタッチします。どちらも結果的に容量は同じとなりますので AWS利用料に大きな差はありません。(EBSの利用料はボリューム・サイズの他に、使ったIO量によっても課金されます) 2台目のEC2の方がIOPSの合計が高くなることに注目します。

EC2 EBSボリュームタイプ GB IOPS(ベースライン/バースト)
1台目 汎用SSD(gp2) 100 300/3000
2台目 汎用SSD(gp2) 20 100/3000
汎用SSD(gp2) 20 100/3000
汎用SSD(gp2) 20 100/3000
汎用SSD(gp2) 20 100/3000
汎用SSD(gp2) 20 100/3000

f:id:swx-miyagata:20211215115841p:plain

100GBのEBSを1個アタッチした1台目のEC2では、従来の「コンピュータの管理」からディスクを 初期化・フォーマットしてDドライブを作ります。 f:id:swx-miyagata:20211215115907p:plain f:id:swx-miyagata:20211215115916p:plain

20GBのEBSを5個アタッチした2台目のEC2では、「サーバーマネージャー」より「記憶域スペース」を設定していきます。 記憶域のレイアウトに「Simple」を選択します。RAID-0 ストライプ 相当となりますので、20GB×5=100GB となり、有効容量は 1台目のEC2と同じです。

本ブログでは設定作業途中の画面ショットは省略しております。詳細な手順はMicrosoft Docs などをご参照ください。

記憶域スペースの概要 | Microsoft Docs

f:id:swx-miyagata:20211215120037p:plain f:id:swx-miyagata:20211215120107p:plain

実際に出来上がってみると、100GBから10GB ほど少ない約90GBになってしまいました。オーバーヘッド分を考慮しておく必要がありそうです。 f:id:swx-miyagata:20211215120124p:plain

では、昔からの定番ベンチマークツール CrystalDiskMark を使ってIOPSを計測します。先ずはツールのデフォルト設定で実行します。 (CrystalDiskMark 実行画面のブログ掲載はレギュレーションで許可されております https://crystalmark.info/ja/information/about/ )

  • デフォルト設定 f:id:swx-miyagata:20211215120724p:plain

「記憶域スペース」を利用して EBS のストライプとした 2台目のEC2では、1台目のEC2と比べて シーケンシャルRead・Write ともに約2倍のIOPSとなっています。ランダムRead・Writeは Q32T1 では2台目のEC2が 4倍以上高いIOPSになった反面、Q1T1では IOPSが低くなるという結果でした。

では、テストのスレッド数をあげてみるとどうなるか。

  • スレッド数×2 f:id:swx-miyagata:20211215120748p:plain

  • スレッド数×4 f:id:swx-miyagata:20211215120805p:plain

スレッド数を ×4 まであげると、すべてのテスト項目で「記憶域スペース」を利用した2台目のEC2の方がIOPSが高い結果となりました。

予想通り「記憶域スペース」を利用した方がIOPSが高くなりホッとしていますが、興味深いのは、すべての領域で「記憶域スペース」を利用した方が高いわけでは無いことです。「記憶域スペース」を管理しているのがOSになりますので、EC2のCPU性能によっても結果が変わってくるかもしれません。

まとめ

私の検証結果では Windows Server「記憶域スペース」を使うことで、EC2 のディスク性能をおおよそIOPS2倍まで改善させることができました。 なお、Linux Server ですと LVM (logical volume manager) という類似する機能もありますので、利用することで同様効果が期待できると思われます。

ここで欲が出て、「もっとEBSのサイズを小さくして数を増やせば、よりディスク性能が高くなるのでは?」と思ってしまいます。これには注意があります。EC2にアタッチできるEBSの数には上限があります。EC2のサイズによって異なりますが、全体で28個までという場合が多いです。 また、AWSのDocsには、EBSの数が8個を超えるとオーバーヘッドにより逆にパフォーマンスが悪化するという記載もあります。 インスタンスボリューム数の制限 - Amazon Elastic Compute Cloud

EBS単体ではバックアップ・リカバリが出来なくなるという運用面の考慮も必要です。実装される場合は デメリットを考慮して設計する必要があります。また、「記憶域スペース」はOS導入ディスク(通常 C:) では利用できません。

ご利用する用途やアプリケーションにより、システム全体のパフォーマンスは変動します。皆様のシステムで どれだけ改善効果が出るかは、事前にテストして計測することが望ましいです。テスト環境を簡単に短時間で作れるのも AWSの魅力のひとつです。皆様のシステムの性能改善、ランニング費用改善につながれば幸いです。

宮形純平(執筆記事の一覧)

エンタープライズクラウド部 ソリューションアーキテクト1課

好きなお酒は缶チューハイと本格焼酎