何カ月も動いたEFSが、急に遅くなる理由

EFSの問題は、見えるようになるずっと前から存在することがあります。小さなファイルシステムが有限のクレジットを消費しながら、何週間も何カ月も正常に動く。アプリは健全、画面は緑、設計への信頼も高まる。やがて残高が尽き、同じ負荷が、はるかに低い持続可能性能の上限にぶつかります。

その時間差で、突然の障害に見えます。でも運用の観点では、突然ではありません。

隠れていた不均衡

Burstingでは、EFS Standardの保存容量に応じてベースラインが増えます。AWSの仕様は1 GiBあたり50 KiB/sで、最低1 MiB/sの計測スループットがあります。ベースライン未満ならクレジットがたまり、超えると消費します。

危険なのは、長期平均がベースラインを少し上回る負荷です。蓄積分が差額を埋めるので、すぐ障害にはなりません。でも残高は毎日減っていきます。

ストレージの呼び出しが遅くなると、ワーカーが待ちます。Linuxでは割り込み不能なI/O待ちもロードに数えるので、ストレージ不足が計算リソース不足に見えます。CPUが原因でなくても、キュー、ワーカープール、タイムアウトへと影響が広がります。

インスタンス追加で悪化する場合もあります。新しいワーカーが、同じ制限された共有ストレージへ、さらに要求するからです。ボトルネックは共有されたまま、同時実行だけが増えます。

長く動いたことで確認できるのは、その期間の需要、ベースライン、残高の組み合わせだけです。クレジットなしでも負荷を維持できる証明にはなりません。減り続ける BurstCreditBalance は、容量の細部ではなく、信頼性についての早期シグナルです。

負荷試験では短いピークだけでなく、定常状態も確認します。10分の試験でバースト上限が足りるとわかっても、数千時間かけてたまる不足についてはほとんどわかりません。

バースト容量はバッファーであり、容量計画ではありません。クレジット型サービスは、今ゼロより上かだけでなく、残高の方向と減る速さで評価します。前の記事では実際の障害を、次の記事ではCloudWatchでの具体的な監視設計を扱います。