💡

[AWS/EFS] 2022/11/28新機能のElastic Throughputの落とし穴

2022/12/18に公開約2,600字

こんにちは。Opt Fit CROの森田です。

つい先日、EFSの新機能で「Elastic Throughput」というものが追加されました。
https://aws.amazon.com/jp/about-aws/whats-new/2022/11/amazon-elastic-file-system-elastic-throughput/
EFS運用ご経験のある方であれば、字面からして待望の機能かと思うのですが、想定外の罠にハマってしまったポイントを記しておこうと思います。

背景

私たちはEFSを小容量(約3GBほど)で多数に分けて運用しています。
なるべくコストを小さくしたいため基本的にはバーストモードを使い、バーストクレジットが足りなくなったらプロビジョニングモードに変更してバーストクレジット回復を待つというテクニックを使っています。(過去記事参照 https://zenn.dev/optfit/articles/bc257d3eeef6a9

そんな状況に対して、バーストクレジットを消費することなく最低限のスループット値を動的に確保する「Elastic Throughput」という機能が追加されたため、よりコストが下がらないかという期待を込めて試してみました。

6日間で1,700ドル溶けてしまった

これまでの運用では、平常時スループット1MB・スパイク時5MBほどのため、プロビジョニングモードでは最大値である5MBに設定していました。
これが動的にスループット値変更されるとなれば、コストが1/5くらいになることが期待される…と思い込んでしまったのが運の尽きでした…
実際に試してしまったところ、6日間で1,700ドル溶けてしまっていたというサプライズが起きました💸 (従来は6日間で150ドルくらいなので約11倍)

何がおきたのか

AWSの人に聞いたところ、どうやらElastic Throughputではスループット上限値が変動するのではなく、あくまでもスループット上限値は固定の1GBであり、課金対象はスループット上限値ではなく実際のスループット使用量とのことでした。
Elastic Throughputでは1GBあたりの書き込みが0.07ドル、読み込みが0.04ドルとなっているようなので、今回の例では1EFSあたりの書き込み・削除が毎秒約0.2MB、読み込みが毎秒0.8MBであることから、6日間で31.10ドル/EFSの計算になります。
読み書きの激しい(といっても毎秒1.2MBですが)運用では上記の通り結構な課金がされてしまうので、バーストモードとプロビジョニングモードを組み合わせる方がリーズナブルということがわかりました。
勝手な思い込みは非常に危険ですね…

余談

EFS IAを利用したコスト削減アプローチ

EFSに関してググっていると、バーストとプロビジョニングを交互に入れ替えるアプローチの他、EFS IA(Infrequent Access: 低頻度アクセス)という仕様を利用したコスト削減アプローチもあります。
IAのデータは料金が1/13程度の激安になるという仕様があり、EFSのサイズが大きくなればなるほどバーストクレジットが消費されるか否かを決めるベースラインスループットも大きくなるため、ゴミデータをわざと置いておきバーストクレジット消費を防ぐという方法になります。
弊社のように小サイズのEFSを多数で運用するような状況に限られるかもしれませんが、机上の計算では料金が1/3程度に抑えられる想定です(未実施)。

計算例

前提

東京リージョンにて、1つのEFSに3GBのデータを常に更新維持で、

3GB * 0.36USD/GB,month = 1.08USD/month

がベースとして課金されることを考えます。

バースト&プロビジョニング運用の場合

CloudWatchメトリクスによれば、バーストモード510h → 5MBのプロビジョニングモード58.5hのため[1]、1ヶ月(=720h)あたりのプロビジョニング費用は、

7.2USD/MB,month * 5MB * 58.5h/(58.5h + 510h) = 3.70USD/month

合計で、

1.08 + 3.70 = 4.78USD/month

IAデータ運用の場合

CloudWatchメトリクスによれば、21GBのIAデータを置いておけばバーストクレジットが減らないため[1:1]

21GB * 0.0272USD/GB,month = 0.57USD/month

合計で、

1.08 + 0.57 = 1.65USD/month

料金1/3くらいになりそうですね。

まとめ

しっかり検証せず軽率に本番適用して失敗しました。
特に規模が大きめのシステムではレバレッジが掛かりマズイことになります。
どんなに良さげな説明が書かれていても実際に試さないといけないなと改めて思いました。
論より証拠。

関連記事

https://dev.classmethod.jp/articles/amazon-elastic-file-system-elastic-throughput/

https://qiita.com/Naoki_Ishihara/items/38258f1cf036c3d4ba1b

🔔採用情報

ジム施設向けDXソリューションGYMDXではエンジニアを積極採用中です。
ジュニア層のエンジニアからリーダー職まで幅広く募集しています。

2022年7月にプレシリーズAラウンドにて資金調達を実施しました。
https://prtimes.jp/main/html/rd/p/000000015.000055404.html

リードエンジニア

https://herp.careers/v1/optfit/GpvSeC-fA995

バックエンドエンジニア

https://herp.careers/v1/optfit/KsDmlZ1VhTmU

脚注
  1. 運用状況によって変わります ↩︎ ↩︎

Discussion

ログインするとコメントできます