残高が少なくなったときのアラームひとつでは、EFSを十分に監視できません。余力が尽きそうとはわかっても、なぜ減っているか、いつ尽きるか、利用者に影響が出ているかはわかりません。
役立つEFSダッシュボードは、容量、需要、アプリへの影響をつなげます。
状況をつかむ五つのメトリクス
BurstCreditBalanceは、Bursting Throughputで残っているクレジット量を示します。MeteredIOBytesは、EFSのスループット計算に用いる計測I/Oを表します。PermittedThroughputは、現在ファイルシステムに許可されているスループットを示します。TotalIOBytesは、読み取り・書き込み・メタデータの指標と合わせて、実際に行われた処理を示します。PercentIOLimitは、General PurposeモードのI/O上限にどれだけ近いかを示します。
ひとつのグラフより、指標同士の関係が大事です。計測した需要が許可性能に繰り返し近づき、同時に残高が下がるなら、一時的な余力を使っています。
ダッシュボードを、段階的に作る
第1層:残された余力
グラフにするのは BurstCreditBalance です。最低30日間を見ます。短い期間では緩やかな減少が隠れます。統計値は最小値を使って各期間の底を捉え、さらに長期のグラフで傾向も確認します。
第2層:需要と許可性能
グラフにするのは MeteredIOBytes および PermittedThroughput を、期間と単位をそろえて比較します。AWSによると、計測スループットが許可スループットに達すると、現在使える性能をすべて消費している状態です。
第3層:負荷の内訳
データの読み取り、書き込み、メタデータ操作を分けます。小さなメタデータ操作中心の負荷と、連続的なデータ転送では、総バイト数が似ていても挙動が違うことがあります。
第4層:サービスへの影響
リクエスト遅延、タイムアウト率、ワーカーの飽和、ホストのI/O待ちを加えます。インフラ指標は、利用者に見える影響と結び付けてこそ運用に役立ちます。
ゼロだけでなく、減り方にアラームを
固定の低残高アラームも必要ですが、最後の防波堤です。複数段階の警告と継続的な減少を使えば、もっと早く気付けます。たとえば:
- 環境に合った残り余力のしきい値を下回ったら警告する。
- 複数の評価期間で残高が下がり続けたら、対応段階を上げる。
- 計測値が許可スループットに近いままなら通知する。
- 遅延やタイムアウトの増加と突き合わせ、容量不足のリスクと進行中の障害を見分ける。
共通の残高しきい値はありません。意味は消費速度によって変わるからです。大きな残高でも高負荷なら数時間分かもしれず、小さな残高でも静かなシステムなら安定している場合があります。
アラームを、運用上の判断につなげる
手順書には次の問いを残します。一時的な需要か。Standardの保存容量が減ったか。デプロイでメタデータ処理が増えたか。予測不能ならElasticが合うか。安定して必要量がわかるならProvisionedが適切か。
判断の背景がなければ、不確実さをダッシュボードから担当者に移すだけです。よい可観測性は、ページャーが鳴る前に容量モデルを見えるようにします。


クラウド / システム