EFSのバーストクレジットが消費され始めるベースラインスループットの値は、CloudWatchメトリクスでは提供されていません。
今回はこのメトリクスをCloudWatchで可視化する方法を解説します。
バーストクレジット対策でベースラインスループットを調整
とあるバーストスループットのEFSで、バーストクレジットが0になってしまい、IO制限が発生するようになってしまいました。
EFSにはプログラムからのアクセスが定常的に発生しており、常にバーストクレジットが消費され続けている状態でした。
解決方法はいくつかありましたが、継続的なクレジットの消費を止めるために、ベースラインスループットを引き上げることにしました。
ベースラインスループットはEFSに保存されているデータ量によって決まるので、ダミーデータを追加します。
データ量を増やしたことにより「ベースラインスループット」が「発生しているIOスループット」を上回っている状態になったかを、CloudWatchで確認したかったのですが、残念ながらEFSのCloudWatchメトリクスではお目当てのメトリクスが提供されていません。
そこでMetric Mathを使って、標準で提供されているメトリクスから欲しいグラフを作成することにしました。
完成したグラフがこちらです。
グラフ化したメトリクスの設定は次のとおりです。
発生しているIOスループットのメトリクス化
発生しているIOスループットは、ファイルシステムメトリクスのMeteredIOBytesを使って算出します。
バーストクレジットの消費を計算するときに使うデータアクセス量は、書き込みについてそのまま測定値が使われますが、読み取りは測定値の1/3の値で計算されます。
この計算がされた状態のIOデータ量がMeteredIOBytesです。
スループットは1秒あたりのデータ転送量(B/s)です。
MeteredIOBytes(m1)(Byte)の統計を合計にし、それをPERIOD(m1)で取得した1データポイントあたりの期間(s)で割ることで、スループットのグラフを表示できます。
EFSのCloudWatchメトリクスの詳細は公式ドキュメントをご参照ください。
ベースラインスループットのメトリクス化
ベースラインスループットの算出にはファイルシステムストレージメトリクスのStorageBytesを使います。
ベースラインスループットの計算対象となるのは、標準ストレージクラスに保存されているデータのみです。
ファイルシステムストレージメトリクスのStorageClassがStandardのStorageBytesを選択してください。
ライフサイクルポリシーで、自動的にIAクラスにファイルを移動している場合、EFSに保存されているデータ総量が大きくても、ベースラインスループットは低いという状況も起こりえます。
また、今回のように、ダミーデータでデータ総量をかさ増しする場合、ライフサイクルポリシーによるストレージクラスの移動が有効のまま運用すると、いずれダミーデータが標準ストレージクラスでなくなってしまうのでご注意ください。
公式ドキュメントではベースラインスループットについて次のように記載があります。
With Bursting throughput, the base throughput is proportionate to the file system's size in the Standard storage class, at a rate of 50 KiBps per each GiB of storage.
1GiBごとに50KiBpsのベースラインスループットを獲得することになりますので、StorageBytesを使ってグラフ化するには次のような計算になります。
(50KiB/s * 1024byte / 1024byte / 1024byte / 1024byte)B/s * Standard StorageBytes(m2) = 50/1024/1024*m2
この式は、狙ったベースラインスループットに必要なダミーデータのサイズの計算にも利用できます。
CloudWatchグラフリンク
このグラフを表示するCloudWatch画面のURLテンプレートを用意しました。
__REGION__と__FILESYSTEM__をお手元の環境に置き換えてください。
https://__REGION__.console.aws.amazon.com/cloudwatch/home?region=__REGION__#metricsV2?graph=~(metrics~(~(~(expression~'50*2f1024*2f1024*2am2~label~'BaselineThroughput~id~'e1~stat~'Average~period~3600~region~'__REGION__))~(~(expression~'m1*2fPERIOD*28m1*29~label~'MeteredThroughput~id~'e2~period~3600~stat~'Average~region~'__REGION__))~(~'AWS*2fEFS~'MeteredIOBytes~'FileSystemId~'__FILESYSTEM__~(id~'m1~visible~false~stat~'Sum~region~'__REGION__))~(~'.~'StorageBytes~'StorageClass~'Standard~'FileSystemId~'__FILESYSTEM__~(id~'m2~visible~false~region~'__REGION__))~(~'.~'BurstCreditBalance~'FileSystemId~'__FILESYSTEM__~(id~'m3~yAxis~'right~region~'__REGION__)))~view~'timeSeries~stacked~false~region~'__REGION__~period~3600~stat~'Average~yAxis~(left~(min~0~label~'Bytes*2fSecond~showUnits~false)~right~(min~0))~title~'EFS*20BaselineThroughput~start~'-PT168H~end~'P0D)
EFSのモニタリング
バーストスループットのEFSを利用している場合は、BurstCreditBalanceの監視をして枯渇するまえに対策を考えましょう。
パフォーマンスが十分かを確認するためには今回のようにいくつかのメトリクスを組み合わせてグラフ化する必要があります。
公式ドキュメントにサンプルが記載されていますのでご確認ください。
上記のようなグラフを自分で作成しなくてもいいように、EFSのファイルシステム詳細画面のモニタリングタブにグラフが用意されています。
スループット上限に対して、実際にどれくらいのスループットが発生しているのかをみる「スループット利用率 (%)」などを確認できます。
なお、上記のとおりスループット利用率のグラフは、スループット上限に対しての利用率となります。
定常的なスループットがベースラインスループットを少し超えていて、少しずつバーストクレジットが減っていっている場面では、スループット利用率のグラフは安定しています。
私のようにスループット利用率だけを見てパフォーマンスに問題がないと思ってしまわないようにお気を付けください。
このほかにも、CloudWatchダッシュボードの自動ダッシュボードにもEFSのダッシュボードがありますので、モニタリング指標の参考にしてみてください。
まとめと注意点
今回紹介したグラフで、MeteredThroughputを下回っていたBaselineThroughputが上昇したことで、BurstCreditBalanceが溜まり始めたことがご確認いただけたと思います。
BaselineThroughputが上昇のタイミングでMeteredThroughputが跳ねているのは、EFSにダミーデータを書き込んだためです。
パフォーマンスモードがバーストスループットのEFSに、ダミーデータを書き込むときは、一時的にElasticスループットに変更してください。
バーストクレジットが0の状態でダミーデータを書き込むと、スループットが1MiB/sに制限されているため、IO待ちが発生してほとんどEFSにアクセスできない状態になってしまいます。
バーストスループット<->Elasticスループットのパフォーマンスモード切替はサービス影響なしで変更が可能です。
今回の事例は、発生しているIOスループットが一定で、かつ、1MiB/s以下(200KiB/s程度)のワークロードだったため、データ量の増加で対応しています。
一時的なバーストによってクレジットが足りなくなる場合や、スループット上限以上のパフォーマンスが必要な場合、定常的に高IOスループットが必要な場合は、利用するパフォーマンスモードやスループットモードの選定から検討が必要です。
本ブログでも解説記事があるのでご参照ください。
