こんにちは!
最近、ようやく資格を取得しようかと考えている今日この頃。。。
本日は。Well-Architected フレームワークのコスト最適化の柱をもとに
Fargateを活用している際のコスト削減方法について記載したいと思います。
なんだかんだ言ってFargateって高いんですよね。。。
それを解消する一つの手段になれば
祝!)
2024/9/6 Graviton-basedのSpotインスタンス対応
https://aws.amazon.com/jp/about-aws/whats-new/2024/09/amazon-ecs-graviton-based-spot-compute-fargate/
ARM アーキテクチャを利用したアプリケーションでも利用することができるようになりました!
この記事の目的
Fargate Spotを理解して活用してもらう。
Fargateを利用する際のコスト削減方法について
ぱっと思いつくFargateを活用した際のコスト削減方法には下記があります。
- Savings Plansの活用
- Fargate Spotの活用
- 試験環境もしくは利用する時間が決まっている場合は定期的に停止する
それぞれの削減率
Savings Plans
東京リージョンで3年前払いを行うと47% Off
Fargate Spot
東京リージョンで通常オンデマンドの60 ~ 70% off
(時価)
システムの停止
単純に24h起動し続ける状態に対して
毎日12時間利用されるシステムだと50% off
平日8時間利用だと79% off
(システムの稼働時間による)
さらに
もうこの時点だけでも、Fargate Spotいいやん!ってなりますよね。
なんと、Savings Plansでは24h/365dの料金がかかるのですがFargate Spotはオンデマンドと同じく従量課金。
つまり、システムの停止と合わせるとさらにコストを下げることができます。
Fargate Spotの割引率が70%として、平日8時間利用のパターンだと
なんと、単純に24h起動し続ける状態に対して93%もコストを下げることができます!
なので、ぜひともFargate Spotを利用してもらいたい。
でも、Fargate Spotは制限もあるのでそちらはしっかり理解してもらいたい。
では、今回の本題のFargate Spot
Fargate Spotとは
AWS内の使用されていないクラウドリソースを用いることで通常の3~4割程度の料金で利用できる
(空きリソースの状況により値段が変わるため、割引率が低いこともあるが、見る限り3~4割程度の料金で利用できている)
ただし、一時的な空きリソースを利用しているため
本来の目的で必要になった場合、クラウドリソースが回収されてサービスの停止が発生する。
(停止後にまた別の空いているリソースがあれば自動的にまたFargate Spotで軌道を行う。)
Fargatgeの停止が発生するためシステムダウンが発生するように見受けられるが
タスク単位でクラウドリソースが分かれているため複数のタスクを起動していればすべてのタスクが同じタイミングで落ちるわけではない。
(天文学的な確率もしくはFargate Spotで利用できる空きリソースがない場合は除く)
空きリソースを利用する前提のため
すべての空きリソースがない場合においてはFargate Spotでは起動することができない。
また、通常のFargateとFargate Spotを混在させることも可能で、最低限の起動が必要なタスク数を通常で確保し
余力部分などをSpotで軌道しておくことなども可能
Fargate Spotの停止
一時的な空きリソースのため、クラウドリソースが回収されるタイミングでタスクの停止が発生。
その際に急に落ちるのではなく、事前にタスクに対してSIGTERMのシグナルが送信され規定時間後にタスクが終了します。
※タスクが落ちる前にSIGTERMが送信される時間はタスク定義のstopTImeoutで設定可能(最大2分、デフォルト30秒)
ECS ServiceがSIGTERMをうけると、ただ落ちるのを待つのではなくFargate Spotで追加起動が可能な空きリソースがあるかどうかの判断を行い起動が可能な場合はFargate Spotで追加タスクの起動することによりタスクが落ちてもすぐリカバリーを開始。
また、ALB(Targate Group)に接続されている場合は、SIGTERMを受けたタイミングでTargate Groupより該当のタスクを切り離しにかかります。
上記流れによりFargate Spotが落ちた場合においても素早く次のインスタンスが起動するのですが、SIGTERMを受けたタイミングでALBからのトラフィックのバランシング対象から外れるため追加のインスタンスが正常に起動してヘルスチェックが通るまでは1台減の状態が発生します。そのためFargate Spotを利用した場合は1台落ちても問題ないようなシステム構成を構築をおこない、タスクの起動時間が1台落ちている時間(インパクトがある時間)と直結するため起動時間が短くなるようなコンテナイメージの作成をお勧めします。
(ここはいずれコンテナのベストプラクティスで話す予定)
Fargate Spotを活用する際の注意点
Fargate Spotを活用する際に注意しなければいけないのは、本来の目的で必要になった場合、クラウドリソースが回収されてサービスの停止される点です。そのため以下を注意して設計をしましょう。
- アプリケーションとして正常時でも落ちる前提で設計が必要(長時間処理を行うバッチ処理などは向かない)
- ALB側の設定でDeregistration delayの設定があり、タスク定義のstopTimeoutより短い場合は、正常に処理が終わる前に切り離してしまう恐れがあるのでDeregistration delayの設定はstopTimeoutより長く設定
Fargate Spotを利用する
Fargate Spotをどのように活用したらいいかは下記をお勧めします。
開発環境をすべてFargate Spot
開発メンバーの要望により複数のサーバ(タスク)をいくつも立てる必要が出てきます。
それにより開発環境では一番高額になることが多々あります。(DBは共通の使うけどサーバ側は別々にしたいなど)
開発環境においては、メンバーがFargateSpotであることを理解していればいいのですべてFargate Spotに変えましょう。かなりの削減が可能です。
本番環境は余剰分をFargate Stop
本番環境でタスクが勝手に落ちるのは運用メンバーからしてみたら気持ちいいものではありません。
なので、設定する場合は落ちてもパフォーマンスに影響しない範囲で設定することをお勧めします。
冗長構成で2台にしているけど実際は1台で十分処理できる場合は1台Spotなど
また、一時的に落ちてもビジネス・システム影響がほとんどないものに関しては
すべてSpotで対応するのもありだと思います。