クラウド / システム
最も大きな数値をうたうモードが、最適とは限りません。負荷の形に合った容量モデルで、費用と障害の起こり方をチームが理解して運用できるものを選びます。
Amazon EFSには現在、Elastic、Provisioned、Burstingのスループットモードがあります。それぞれ解決する課題が違います。
Bursting：保存データ量に応じた性能
Standardのデータ量と性能要求が連動し、繁忙時間の後に十分な回復時間があるなら、Burstingは自然な選択肢です。簡潔で経済的な反面、小さなファイルシステムのベースラインは意外なほど低くなります。
保存容量と性能要求が本当に一緒に増える場合に選びます。たまったクレジットを恒常的な容量とは考えないこと。下がり続ける BurstCreditBalance は、負荷と供給が釣り合っていない証拠です。
Elastic：利用状況に応じた性能
Elastic Throughputは負荷に合わせて自動的に伸び、バーストクレジットを使いません。AWSは突発的で予測しにくい負荷、特に平均がピークに比べて小さい負荷に推奨しています。クレジット枯渇という障害要因をなくし、容量計画の手間を減らせます。
代わりに気を付けるのは費用です。従量課金なので、大量のI/Oや管理されないI/Oで支出が増えます。監視するのは MeteredIOBytesです。予算を設け、想定外の需要を調べます。自動で伸びるから管理不要、とはなりません。
Provisioned：明確な要求量に応じた性能
Provisioned Throughputは、保存容量と切り離して必要な性能を指定できます。必要量がわかり、継続的な負荷や平均とピークの差が小さい負荷に向きます。予測可能性が利点で、適切に設定し見直すことが責任です。
少なすぎれば容量不足、多すぎれば無駄な費用になります。確保する量を判断できるだけの、安定した測定値があるときに向いています。
実際に選ぶときの目安
- Burstingを選ぶ場合 保存容量が性能要求のよい目安になり、閑散時にクレジットが回復し、残高の監視が日常運用に組み込まれているとき。
- Elasticを選ぶ場合 需要が不規則で、ピークを予測しにくいか、従量課金を受け入れてでもクレジット枯渇を避けたいとき。
- Provisionedを選ぶ場合 性能要求が把握でき、比較的継続しており、保存データ量とは独立しているとき。
移行は、測りながら
変更前に、基準となるメトリクス、平均とピークの要求量、クレジットの推移、アプリの遅延を記録します。変更後は同じ指標と費用を比較します。Provisionedへの切り替えや変更後にはAWSが定める一時的な制限もあるため、手順書に時間の制約を含めます。
ひと言で選ぶなら
データ量から需要が読めるならBursting。活動量が読めないならElasticが運用上は安心。必要量が安定して測れるならProvisionedで明示的に確保する。どれを選んでも、制約となるリソースを見えるようにしましょう。