関連するソリューション
マネージドサービス（運用・保守）
サイバー・セキュリティ・ソリューション（CSS）部
エバンジェリスト 松岡 政之
こんにちは。
サイバー・セキュリティ・ソリューション
部エバンジェリストの松岡です。
梅雨空が続く中毎日雨雨雨で気分が落ち込みそうですが、皆様いかがお過ごしでしょうか。
私は時々出社する日もありますが基本引きこもりの日々が続いております。
在宅勤務中にパソコンが壊れてしまうなど思いがけないトラブル等もありましたがあまり代わり映えしない日々を送っております。
もともと引きこもり気質なのであまり苦ではなくオンライン上でいろいろ楽しんでいますけどね！
さて、本題に入ります。
今回は、少し今更感はありますが今年の
3
月
26
日に発表された
FSx for Windows File Server
の
HDD
ストレージオプションを簡単に検証してみたいと思います。
最初に、通常
SSD
を利用する
FSx for Windows File Server
で
HDD
オプションを選択することで何が嬉しいのかというと、ずばり容量当たりの料金です。
SSD
の場合、東京リージョンシングル
AZ
で
1GB
あたり月額
0.156
ドルなのに対して
HDD
だと月額
0.016
ドルと
10
倍近く金額が異なります。ただ、
1
点注意が必要なのは
SSD
だと
32GiB
から容量を選択できますが、
HDD
だと
2000GiB
以上でないとファイルシステムを払い出すことができません。
205GiB
以下の容量で十分な場合は
HDD
を選んでしまうとかえって高くなってしまいますのでご注意ください。
それでは早速
FSx for Windows File Server
でファイルシステムを作成したいと思います。
しかしその前に、
FSx for Windows File Server
を利用するためには
Active Directory
（以下
AD
）が必須になります。
ここで使用する
AD
について、昨年
6
月
24
日に
AWS Managed AD
以外の
AD
（オンプレミス等に構築された
AD
）でも利用できるようになりました。この変更によって、
FSx for Windows File Server
を利用するためには
AWS Managed AD
の料金も支払う必要性があった従来と比べるとかなりハードルが低くなったかと思います。
さて、今回の検証では手元にすぐに使える
AD
がないためまずは
AWS Managed AD
を作成します。
画像にも表示されていますが、作成にはかなり時間がかかるのでお茶でも飲みながらゆっくり待ちましょう。
∧＿∧
( ´
･
ω
･
)
(
つ旦
O
と＿
)
＿
)
AD
の作成が完了したら次は
FSx
ファイルシステムの作成です。まずは
SSD
です。
ファイルシステムの作成時はセキュリティグループを指定する必要がありますが、このセキュリティグループとファイルシステムをマウントするインスタンスに割り当てるセキュリティグループ同士が通信できるように設定する必要がある点ご注意ください。
こちらの作成も
AWS Managed AD
と同じくらい時間がかかるので完了までまったりとお待ちください。
ファイルシステムが完成したら今度は EC2 インスタンスに移ります。スループットは一番小さい 8MB/s で作成しています。ちなみに 8MB/s に設定したからといって 8MB/s しか出ないわけではなく、 EC2 インスタンスの T シリーズの CPU のように利用帯域が少ないときにクレジットを蓄積し、利用帯域が増えた際にクレジットを消費してブーストする機能があるので 8MB/s で設定してもネットワークは最大 600MB/s 、ディスクは最大 260MB/s まで出ます。
次に、最初に作成した AWS Managed AD に参加した Windows のインスタンスで作成したファイルシステムをマウントします。
それではマウントしたファイルシステムのディスクベンチマークをとってみましょう。
比較のために同じサブネット内の別の Windows Server の EBS の gp2 ディスクをファイル共有してマウントしたもののベンチマークも載せます。
この二つを比較すると、意外にもシーケンシャルは読み書きともに gp2 ディスクより高速です。一方、ランダムについては gp2 の共有ディスクに比べて遅くなっています。
念のため、
FSx for Windows File Server
のファイルシステムのスループットがボトルネックになっていないことを確認するため
16MB/s
の場合も確認します。
今年の
6
月
1
日に
FSx for Windows File Server
のストレージ容量とスループットを変更することができるようになりました。今までは容量やスループットを変更するためにはファイルシステムを作り直す必要があったためこのアップデートによりかなり柔軟性が高まりました。
早速この新機能を使ってスループットを拡張してみました。
そして同様にベンチマークを実行します。
スループットが
8MB/s
のものと比較してほぼ変わらないので、
8MB/s
でもスループットがボトルネックになっていないことがわかります。そのため、
HDD
のファイルシステムも
8MB/s
とします。
というわけで、今回のメインである
HDD
のファイルシステムを作成します。
そしてしばらく待つと作成が完了します。
作成出来たら SSD の場合と同じく EC2 インスタンスからマウントします。
それではこちらもベンチマークを実行します。
シーケンシャルについては意外にも SSD と大差ありません。バックアップや動画など大きなファイルの置き場としては SSD のファイルシステムと比べてもそん色なく利用できるかと思います。一方、ランダムについては案の定 SSD の性能の半分を割っています。 HDD は SSD と異なり機械的な動作によるシークタイムがどうしても発生して遅くなってしまうためしかたありません。そのため、データベースなど細かいアクセスが頻発するような用途には向かないかもしれません。
さて、今回のまとめです。
今回は
FSx for Windows File Server
のディスクの違いによるパフォーマンスの差異について検証してみました。
シーケンシャル性能については意外にも
SSD
と
HDD
で性能の差はほとんどありませんでした。さらに意外なのは、他インスタンスの
SSD
のドライブを共有したものより
FSx for Windows File Server
の方がシーケンシャル性能は高いということです。さすがに
AWS
の方もファイルサーバとしての用途を想定してるためかこのあたりのチューニングには素直に感心します。
一方、ランダム性能についてはほぼ想定通りの性能でした。あえて言うと、
FSx for Windows File System
の
SSD
ファイルシステムが
EBS
を共有したものに比べて思ったより性能が出ていなかったことが少し意外でした。
FSx for Windows File System
は
SMB
でしか接続できないので何がボトルネックになっているかの検証は困難ですが、
RTT
の違いによる
SMB
のオーバーヘッドがより濃く出たのかもしれません。これは私の勝手な予想ですが。
FSx for Windows File Server
の
HDD
ファイルシステムは
SSD
に比べると非常に安価ですが、安価な分パフォーマンスで劣る部分もあります。そのため、安いからといって飛びつくと思ったようなパフォーマンスが出なかったりするかもしれません。
もちろん使い方によっては
HDD
ファイルシステムでも十分なパフォーマンスを発揮できる場面もあるので、用途がばっちりかみ合えばかなりのコスト削減が見込めます。
この二つをうまく使い分けて最適なコストとパフォーマンスのバランスを追求していきたいですね。
それではよいクラウドライフを！
当サイトの内容、テキスト、画像等の転載・転記・使用する場合は問い合わせよりご連絡下さい。
エバンジェリストによるコラムやセミナー情報、
IDグループからのお知らせなどをメルマガでお届けしています。
