この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。
本ブログはAWS re:Invent 2019のセッション『Cost optimization with containers and Spot』のレポートです。
セッション概要
Containerized applications, especially those using modern microservice architectural patterns, are often robust to interruption and unexpected termination of individual containers. For this reason, containerized applications are a good fit for Amazon EC2 Spot and AWS Fargate Spot. With minimal modifications, many containerized applications can run some or even all of their containers as-is on Spot at substantially lower cost. In this session, we discuss the design decisions and best practices for using Amazon EC2 Spot and AWS Fargate Spot with modern containerized applications.
コンテナ化されたアプリケーション、特に最新のマイクロサービスアーキテクチャのパターンを使用するアプリケーションは、コンテナの中断や予期しない終了に対して堅牢です。よって、コンテナ化されたアプリケーションはAmazon EC2 SpotやAWS Fargate Spotに適しています。コンテナ化されたアプリケーションの多くは、最小限の変更で、コンテナをそのままSpot上で低コストに実行できます。このセッションでは、最新のコンテナ化されたアプリケーションでAmazon EC2 SpotとAWS Fargate Spotを使用するための設計上の決定とベストプラクティスについて議論します。
動画＆スライド
レポート
アジェンダ
- コンテナとコンピューティングで使用できる支払いタイプ
- コンピューティングのコストとパフォーマンス
- コストパフォーマンスの最大化
- コスト最適化とオートスケーリング
- 過剰プロビジョニングのSpot利用
コスト最適化
- コストとパフォーマンスはトレードオフ
- 最小のコストで目標とするパフォーマンスを達成したい
AWSのコンテナサービスのオーケストレーションとコンピューティング
- オーケストレーション
- ESC（Amazon Elastic Container Service）
- EKS（Amazon Elastic Kubernetes Service）
- コンピューティングエンジン
- Amazon EC2
- Fargate
Amazon EC2 の支払いタイプ
- オンデマンド
- コンピューティングキャパシティを秒単位で課金
- スパイクのあるワークロードに向いている
- Saving Plans と Reserved Instance
- 長期的な利用をコミットすることで利用料を割り引き
- 安定した利用が想定されている場合に向いている
- Spot Instances
- 余っているEC2キャパシティを利用することで最大90%引き
- 停止が許容できる状態を持たないワークロードに向いている
Westen Degitalの例
スポットインスタンスについては節約とは考えないでください。 同じコストでどんなことができるかかんがえてください。
Westen Degitalでは、スポットインスタンスを利用することで、20日かかっていたジョブが8時間で終わるようになりました。
Fargateの支払いタイプ
- Fargate
- コンテナ実行を秒単位で課金
- 頻繁に必要なキャパシティが変わる場合に向いている
- [New!]Saving Plans
- 1年または3年の利用をコミットすることで利用料を割り引き
- 安定した利用が想定されている場合に向いている
- [New!]Fargate Spot
- 余っているキャパシティを利用することで最大70%引き
- 停止が許容できるワークロードに向いている
Amazon EC2 Spot と Fargate Spot
- Amazon EC2 Spot
- 予備のEC2キャパシティ
- オンデマンドと比較して最大90%引き
- 警告から2分後に停止する可能性がある
- AWS Fargate Spot
- 予備のコンピューティングキャパシティ
- オンデマンドと比較して最大70%引き
- 警告から2分後に停止する可能性がある
コンピューティングコストの構成
トータルコスト = コンピューティングユニットの数 x 利用時間 x 時間単価
コンピューティングユニットとは？
- EC2インスタンス
- Fargateタスク
コンピューティングパフォーマンスの構成
トータルパフォーマンス = コンピューティングユニットの数 x ユニットごとのパフォーマンス
パフォーマンス目標を達成しつつコストを最小化する
- ワークロードに対して、ベストなコストパフォーマンスのコンピューティングユニットを選択する
- パフォーマンス目標の達成にちょうど必要な数だけコンピューティングユニットを実行する
（1）コンピューティングユニットのコストパフォーマンスの最大化
- EC2 Instance
- task/podのvCpuとメモリをサイジング
- 支払いタイプを選択
- インスタンスタイプを選択
- Fargate Tasks/Pods
- task/podのvCpuとメモリをサイジング
- 支払いタイプを選択
(1)Spotを利用したコストパフォーマンスの最大化
Spotを100%利用するのに最適なケース - ETL（Extract, Transform, Load） - バッチプロセス - 開発・検証環境
(2)ちょうど必要な数だけコンピューティングユニットを実行する
オートスケーリングすることで、必要な数だけコンピューティングユニットを実行できます。
アクセス増加時にパフォーマンス不足となる可能性があるため、ふつう過剰にプロビジョニングして余裕をもたせます。しかし、そうすることで過剰なコストもかかります。
たとえば、2/3はオンデマンド、1/3はSpotを利用することで、コストを抑えつつアクセス増加に対応できます。
EC2 ASG利用における支払いタイプの分割
EC2 ASGは支払いタイプによって分割されるため、支払いタイプを混在させることができません。この問題を解決する新しい機能がECS Capacity Providersです。
ECS Capacity Providers
- ASGとECSクラスターをリンクする
- ECSをマネージドにスケーリングする
- タスクのスケーリングと終了を管理する
Capacity Providersによる過剰プロビジョニングのSpot利用
- それぞれのサービスで支払いタイプの混在が可能
- 独立してスケールする
ECSが複数のASGを管理できるようになりました。
感想
Planを使ったコンテナのコスト最適化のベストプラクティスのざくっとしたところを把握することができました。
細かい所の理解がまだまだ追いついていないので、弊社ブログを参考にしつつ検証してみたいと思います。