この記事について
この記事のターゲット
- Fargateで使える割引サービスにどんなものがあるのか知りたい人
- Fargateでサービス運用始めてみたけど、もう少しお安く運用したい人
この記事で記載していないもの
- ECSとは、Fargateとは（基本を抑えている人向けです）
- 各手法の具体的な構築手順
- クラメソさんなどが詳しく解説されていますのでそちらを参照ください
- 最後に参考リンク貼っておきます
大前提
今回説明するのはAWSインフラ上におけるFargateコストカットの観点となりますが、
大前提として スペックダウンやスケールイン出来る余地があればまず先にそちらを検討しましょう。
「使わなくて良いリソースは使わない」のが一番確実な節約方法です。
CloudWatchなどでメトリクスを確認し、リソースを過剰に与えてないかチェックしてみましょう。
大方手は打ったけど更にお安く済ませる方法を検討したい時に
この記事を見て頂ければと思います。
まず最初にスペックダウン、スケールインを検討しよう！
Fargateで検討可能なコストカットの手段
結論から言います。AWS公式に使える手法としては下記の3つが選択肢です。
通常版Fargateと比較し、それぞれメリデメを簡単にまとめると下記の通りです。
| Graviton2化 | SavingsPlans | FargateSpot | |
|---|---|---|---|
| 概要 | コンテナをArmアーキテクチャで動かすことで割引を受ける | 利用料金を前払いすることで割引を受ける | AWSの空きリソースを間借りすることで割引を受ける |
| 可用性 | ◯ | ◯ | △ (中断される) |
| 見積難易度 | ◯ | △ (使用量を事前に見積る必要がある) |
◯ |
| 構築難易度 | △ (カスタムイメージの場合はArm対応化が必須) |
◯ | △ (中断に対するアプリ/インフラ設計が必要) |
| オトク度 | ◯ (約20%減) |
◎ (約20〜50%減) |
☆ (約70%減) |
それでは詳しく見ていきましょう。
Graviton2化
ECSコンテナのSoCをarmアーキテクチャで動作させる手法です。
ECSのタスク定義にてarmで動かすよう設定し、
armアーキテクチャに対応したDockerイメージを使うことで動作します。
カスタムイメージを使う場合はarm形式でビルドすることで使うことが可能です。
従来のx86アーキテクチャで動かすよりも 20%引になります。
2020年以前のライブラリやDockerイメージを使用している場合は
armに対応していないケースがあるので注意が必要ですが、
2023年現在はメンテナンスされているライブラリであれば大体対応しているので
導入における敷居はだいぶ下がったといえます。
メリット
- arm化に対応したイメージであればすぐに導入可能
デメリット
- カスタムイメージを使う場合、arm形式でイメージをビルドする必要がある
- arm互換のないライブラリやイメージを使用している場合は採択できない（ビルドが通らない）
こんな方・サービスにオススメ
- 最近のモダンなライブラリや20年以降の比較的新しいバージョンのフレームワークで開発している
- armに対応したDockerイメージをFargate上で稼働させている
SavingsPlans
あらかじめ決まった量のリソースの料金分を前払いすることで使用料金が割引になる方法です。
期間は1年または3年間、支払い形式は前払いなし・一部前払い・全額前払いから選択でき、
1年間より3年間、前払いなしより全額前払いの方が割引率が大きくなります。
23年現在、 最大で50%程度の割引を受けることが可能 です。
ただし利用できなかった分のリソースの払い戻しは原則出来ない為、
「どれぐらいのリソースを使うのか」を事前に見積りすることが重要になります。
メリット
- 購入さえしてしまえば自動適用される、アプリケーションコードやインフラの調整不要
デメリット
- 年間を通してどれだけ使うのかしっかりとした見積もりが必要になる
- リソース使用量の増減が大きかったり予測が難しいサービスには向かない
こんな方・サービスにオススメ
- サービス利用者が安定しており、リソースの最低使用量が年間を通じて見積もれるサービス
FargateSpot
AWS上で余っているリソースを使うことで使用料金が割引になる方法です。
「余っているリソース」というのが肝でAWS上のリソースが逼迫するなどを理由に
ある日突然、AWSからコンテナをキルされるリスクと常に隣り合わせであるため、
アプリケーションやインフラの設計を充分に考慮する必要があります。
その分、割引率も今回の手法の中では最大の割引率となっており、 圧巻の70%引です。
現在はCapacityProviderで通常版とSpot版の比率を簡単に調整出来る機能が提供されているので
APIコンテナなど冗長構成のインフラであれば比較的導入がしやすい方法かと思います。
アプリケーションやインフラの考慮点が増えるものの、
採用出来ればECSコストカットにおける最強のカードになり得る手法です。
メリット
- 70%引という選べる手法の中でも最大の割引率
デメリット
- アプリケーションまたはインフラ、またはその両方に対してコンテナ中断における設計または許容が必要
- Graviton2化との併用不可（x86アーキテクチャ限定）
こんな方・サービスにオススメ
- 並列数が3つ以上の冗長構成のインフラを運用している
- コンテナ中断におけるリスクが殆どない、または許容が出来るシステム
実際に使ってみた感想
今回ご紹介した手法の内、SavingsPlans以外は自分のチームで活用しているので簡単に感想を。
（※あくまで個人の感想なので参考程度に）
Graviton2化
- 一言で言うと 「実際の使用感は通常版(x86版)と何ら変わらない」 です
- 常駐稼働するQueueWorkerのシステムで運用中
- arm化したからリソース効率が上がった下がった等も特に感じない
- 厳密な計測はしていないので数%レベルでの差はあるかもしれない
- M系Mac上で動くことと、Fargate(Graviton2)上で動くことはほぼ同義と言って良さそう
- 今のところ、M1-Macで動いているのにFargate(Graviton2)だと動かないみたいなケースには出くわしていない
FargateSpot
- こちらも動作している間の 「実際の使用感は通常版(x86版)と何ら変わらない」 です
- 定期的に稼働するバッチ処理のシステムで運用中
- Spotコンテナがキルされたら通常版コンテナで起動するようにStepFunctionsでフローを組みリスクヘッジ
- そのため、再実行されても問題ないようアプリ側は結果整合性を担保出来る設計になっている
- 2週間ほど検証＆運用してみたが、その間にキルされた場面に出くわすことが無く（いい意味で）困惑
- Weeklyで2~3回ぐらい起きると思っていたので意外だった
- とはいえいつキルされてもおかしくないので過信はせず運用を継続する予定
まとめ
いかがだったでしょうか？
最近はFargateでアプリを構築するのも一般的になり、
アプリケーションエンジニアの運用負荷もだいぶ下がってきました。
そんな便利なFargateもひと工夫を入れることで更にお安く運用することができます。
運用改善を目指して、さらに一歩踏み出してみてみるのも良いかもしれません。
参考リンク