こんにちは、CSM課の城です。
テレワークが続く中、あれやこれやと家電やらモニターやら机やらと買い揃え、ついに仕事部屋を確保することに成功しました。 歓喜に明け暮れております。 さておき、掲題のお話に入ります。
どんなシステムを利用する際もシステムのパフォーマンスの不足や障害検知のため、モニタリングや監視をするかと思います。 これはAWSのマネージドサービスを利用する際も同様です。 とあるシステムにてAmazon FSx for Windows File Serverを利用しているのですが、パフォーマンス特性やどのように監視運用をすべきか、検討した内容を共有したいと思います。
1. Amazon FSx for Windows File Serverのパフォーマンスについて
1.1 コンポーネントとパフォーマンス特性
まずはドキュメントに記載の下図をごらんください。
ファイルシステムへはENIを経由してアクセスします。 このENIの背後にはWindowsファイルサーバーがあり、ファイルサーバーにはインメモリキャッシュを備えています。 ファイルサーバーの背後にストレージボリューム、または、ディスクが配置されています。
上記のコンポーネントに対応するパフォーマンス特性、及び、それぞれの特性を決定する要素は下表となります。
パフォーマンス特性 | 説明 | パフォーマンス特性を決定する要素 |
ネットワークパフォーマンス | クライアントとファイルサーバー間のリクエストのスループット/ IOPS | Throughput capacity |
ファイルサーバーのインメモリキャッシュサイズ | インメモリキャッシュサイズ | Throughput capacity |
ディスクI/Oパフォーマンス | ファイルサーバーとストレージボリューム間のリクエストのスループット/ IOPS | Throughput capacity Storage capacity |
1.2 ベースラインパフォーマンスとバーストパフォーマンス
Amazon FSx for Windows File Serverはバーストパフォーマンスを持っています。 これはベースラインレベルのパフォーマンスを提供しながら、そのベースラインレベルを超えてバーストする機能となります。 詳細は後述しますが、バーストパフォーマンスを持っているという点を考慮して設計を実施し運用することで、過剰な性能を避け、コストを最適化することが可能になります。
1.3 具体的なパフォーマンス特性を求める
ドキュメントに記載の下表のとおり、各パフォーマンス特性を求めることができます。
【Throughput capacityから求められるパフォーマンス特性】
【Storage capacityから求められるパフォーマンス特性】
ディスクI/Oパフォーマンスについては、上表で算出したどちらか低い方となるので、Storage capacityを少量に設定している場合などは注意が必要です。 ちなみにStorage capacityのSSDの性能については、ベースライン性能だそうです。
例えば、次の構成の場合を考えてみます。 ストレージタイプ: SSD Throughput capacity: 16 MB/s Storage capacity: 100 GiB
Throughput capacityから求められるパフォーマンス特性は下記となります。
- ネットワークスループット(MB/s): ベースライン 16 , バースト 600
- ネットワークIOPS: ベースライン 数千 , バースト 数万
- インメモリキャッシュサイズ(GB): 1
- ディスクスループット(MB/s): ベースライン 16 , バースト 260
- ディスクIOPS: ベースライン 数百から数千 , バースト 数万
次にStorage capacityから求められるパフォーマンス特性は次のとおりです。
- ベースラインディスクスループット(MB/s): 750 × 100GiB/1024GiB ≒ 73.24
- ベースラインディスクIOPS: 3,000 × 100GiB/1024GiB ≒ 292
このようになるので、ディスクスループットについてはベースラインが16MB/s、ディスクIOPSについてはベースラインが292IOPSとなります。
また、バーストパフォーマンスについて、「ネットワークI/OとディスクI/O一定期間高速にバーストする機能」との記載がありますが、一定期間というのがどのくらいの期間なのかはドキュメントに記載されておらず、詳細は不明です。 ただ、2019年3月時点の資料と少し古いのですが、下記リンク先のBlack Beltセミナーの資料に「1日当たり30分のバーストクレジットが供給され、ベースラインパフォーマンスを下回っている期間は追加のバーストクレジットが供給される」とありましたので、参考にはなるかと思います。
2. 監視運用について
前項にてパフォーマンスについては確認しましたので、それをもとに監視運用を考えてみます。 ネットワークスループット単体がボトルネックとなるというのは考えづらいので、基本的には下記3項目を監視すればよいと考えます。
- ディスクの空きストレージ容量
- ディスクスループット
- ディスクIOPS
こちらについて、CloudWatchで監視、SNSで通知するパターンを考えてみます。
2.1 対象メトリクスについて
では実際何を監視対象のメトリクスにするかですが、Amazon FSx for Windows File Serverのダッシュボードには予めこちらのメトリクスが用意されています。
マネジメントコンソールにてAmazon FSxのダッシュボードから[File systems]の画面に遷移し、[File system name]または[File system ID]をクリックします。
[Monitoring]をクリックすると、 Free storage capacity、Total throughput (bytes/sec)、Total IOPS (operations/sec)のグラフが表示されます。
ここからCloudWatch alarmを作っていくわけですが、お薦めは[Create CloudWatch alarm]をクリックするのではなく、次の方法で作成となります。 各グラフの右上にある...が縦に並んだマークをクリックし、[メトリクスで表示]をクリックします。
ここからはそれぞれのメトリクスについて説明していきます。
2.2 FreeStorageCapacity
FreeStorageCapacityについてはメトリクスそのものが取得できるので、メトリクスを選択肢、[統計]をプルダウンから最小に変更、[アラームの作成(ベルのマーク)]をクリックします。
アラーム条件について[以下 <=しきい値]([より低い]でもOK)を選択、しきい値を入力し、[次へ]をクリックします。
Bytesでの指定になるのですが、今回はざっくり5,000,000,000としています。 利用の特性やしきい値のアラート後にストレージ容量の拡張オペレーションをするのにどれくらい余裕が必要かといったことを加味して決めるのがいいでしょう。 その他の設定についてはアラームを実行するデータポイント(何回のデータポイントのうち、何回条件該当で発報)の設定や欠落データがあった際の処理の方法を設定できます。 こちらについては、今回はデフォルトのままとしています。
SNSトピックを設定します。 既存のものの利用、もしくは、[新しいトピックの作成]、[通知を受け取るEメールエンドポイント]にメールアドレスを入力し、[トピックの作成]をクリックします。
[次へ]をクリックします。
[アラーム名]を設定し、[次へ]をクリックします。
内容を確認し、[アラームの作成]をクリックします。
おっと、SNSのConfirmを忘れていました。
SubscriptionのConfirmを実施しないとSNSからの通知を受信することができません。 SNSトピックを作成すると、登録したメールアドレスに「AWS Notification - Subscription Confirmation」という件名でメールが届きます。 本文中のConfirm subscriptionをクリックします。
SubscriptionのConfirmができました。
CloudWatchの画面を更新すると、状態がOKとなりました。これで空き容量が約5GBを下回ると登録したメールアドレスに通知がきます。
2.3 Total throughput (bytes/sec)、Total IOPS (operations/sec)
Total throughput (bytes/sec)についてはこの方法でメトリクスを表示させると、Total throughput (bytes/sec)すなわち、DataReadBytes、DataWriteBytesの1分間の合計を60秒で割ったものがあるので、こちらを監視対象とします。 同様にTotal IOPS (operations/sec)についても、DataReadOperations、DataWriteOperations、MetadataOperationsの1分間の合計を60秒で割ったものとなります。 ※ほぼ同じ内容となるのでTotal throughputのみ、画像を掲載します。
同様に[アラームの作成(ベルのマーク)]をクリックします。
ディスクスループット、IOPSの閾値については、システムのストレージの使い方により、設定の仕方が変わってきます。 今回私が運用するシステムとしては、読み取りはあまり発生しない、書き込みについてもスパイクが無く常に一定量を書き込み続けるような動作になるので、ベースラインスループット、IOPSを閾値とし、データポイント3回中3回超過したら、というような設定としました。 ※こちらのサンプルFSxの設定とは異なりますが、1.3項の例と合わせてThroughput capacityが16MB/sを想定した設定となっています。
通知、アラーム名の設定をして、CloudWatch Alarmを作成します。(画像省略)
CloudWatch Alarm、及び、通知の設定をすることが出来ました。
さいごに
Amazon FSx for Windows File Serverについては先日のアップデートの前まではThroughput capacityやStorage capacityを変更することが出来なかったため、大きめに作ることが多かったと思いますが、変更することが出来るようになったため、パフォーマンス監視をきちんとすることで、過大な設定を避けコスト最適化することが出来ます。 より使いやすくなったAmazon FSx for Windows File Serverを利用してみてはいかがでしょうか。
どなたかの助けになれば幸いです。
【参考資料、画像引用元】 https://docs.aws.amazon.com/fsx/latest/WindowsGuide/performance.html https://docs.aws.amazon.com/fsx/latest/WindowsGuide/monitoring-cloudwatch.html https://docs.aws.amazon.com/fsx/latest/WindowsGuide/how_to_use_metrics.html
城 航太 (記事一覧)
営業部カスタマーサクセス課・課長
AWSへの移行、AWSアカウントセキュリティ、ネットワーク広く浅くといった感じです。最近はAmazon WorkSpacesやAmazon AppStream2.0が好きです。APN Ambassador 2019,2020