ワークフロー実行基盤をFargateからEC2へ変更したらコストもパフォーマンスも改善できて幸せになった話 - ZOZO TECH BLOG

はじめに こんにちは、ブランドソリューション開発本部バックエンド部SREブロックの小林（@mirai_kobaaaaaa）です。普段はWEARやFAANSというサービスのSREとして開発、運用に携わっています。 WEARではAmazon Elastic Kubernetes Service（以下、EKSと呼ぶ）を用いて複数システムのインフラ基盤を構築・運用しています。その中の1つとして、ワークフロー処理の実行基盤が存在しています。 本記事では、そのワークフロー実行基盤が抱えていた課題と、それらをどのように解決したのかを紹介します。また、付随して得られたメリットについても紹介いたします。 目次 はじめに 目次 WEARにおけるワークフロー ワークフロー処理内容 ワークフロー実行基盤の構成 ワークフロー実行基盤の課題 コスト内訳の調査 過剰なPodスペック Fargate実行時間の増大 ワーク

[utsuidai]

ウチもほぼ同じ状態…EC2化を目論んでいる。

[integrated1453]

同じコンテナイメージを何度も繰り返し取得する場合はEC2の方がイメージキャッシュが効くので速度もコストも圧倒的に改善できるという事例、素晴らしい。ここはFargateの欠点なんですよね〜

[snaka72]

良い記事

[iselegant]

EKSonFargate→EKSonEC2に変更したお話。自分達のビジネス特性に併せてちゃんと技術選定していて良いと思う。

[shodai]

“最終的に選ばれたのは、EKS on FargateからEKS on EC2へのリプレイスでした。ワーカーノードとしてEC2を使用することで、イメージキャッシュを用いたイメージダウンロード時間の削減が期待できます”

[for-my-internet-demo]

イメージキャッシュ一応ロードマップではwipだった記憶。まあでもec2のが何かと話が早い

[dkfj]

詳しく解説して、すごくよい記事。個人的な見解としては、AWSの利用料が管理するメンバーの人件費を優に超えるのであれば、EC2タイプを検討すると良い。そうでないのであれば、AWSコストの削減より管理の楽さを選ぶ

[el-condor]

やっぱFargateはイメージキャッシュ無効と単価が気になる、という話かな。Fargateの使い方は、実は難しいな。最初はFargateで組んでおいて負荷が見積もれたら適切なEC2にするのが良いだろうか。