【要約】自前ウェブサイトを構築してみた Part4 - FARGATE_SPOT で 70% コスト削減 [Qiita_Trend] | Summary by TechDistill
> Source: Qiita_Trend
Execute Primary Source
// Problem
開発者はECS Fargateの運用コストに直面した。重要度の低い静的サイトへのコストが過剰であった。従来のFargate運用では、可用性を維持するために24時間稼働が必要であった。この構成では、リソースの利用効率が低いことが課題となっていた。コスト削減と可用性の維持を同時に達成する必要があった。
- ・静的サイト（Nginx）の月額コストが$5.19発生。
- ・24時間稼働によるコスト負担が重い。
- ・可用性を維持しつつコストを抑える必要がある。
- ・コスト削減と可用性の維持を同時に達成する必要があった。
// Approach
開発者はFARGATE_SPOTを導入した。Capacity Provider Strategyで可用性を確保する。AWSの余剰容量を活用した。コストを抑えつつ、中断リスクへの対策を講じる。これにより、コスト削減とサービスの継続性を両立させる。
- ・FARGATE_SPOTを優先（weight=100）に設定。
- ・FARGATEで最低1タスク（base=1）を確保。
- ・ステートレスなNginxのみを移行対象とした。
- ・Terraformを用いて設定をコード化した。
- ・中断時はFARGATEへ自動フェイルオーバーする。
// Result
開発者はコスト削減と可用性の両立を実現した。静的サイトのコストを大幅に低減した。これにより、インフラ全体の運用効率が向上した。今後は時間ベースのAuto Scalingによるさらなる最適化を計画している。
- ・静的サイトのコストを約70%削減（$5.19→$1.56）。
- ・ECS全体のコストを23%削減（$15.57→$11.94）。
- ・インフラ全体のコストを約6%抑制。
- ・中断時はFARGATEへ自動フェイルオーバーする。
- ・年間で約$43.56のコスト削減を見込む。
Senior Engineer Insight
> コストと可用性の両立を、baseとweightで合理的に解決している。ステートレスなワークロードを峻別する判断が実戦的だ。ただし、中断通知は2分前である。急激な負荷増への追従性には注意が必要だ。本番適用時は、再起動時間を考慮した設計が求められる。