EKS on EC2 のための Savings Plans + Spot Instance 活用戦略

こんにちは。Infrastructure Squad の @irotoris です。今日は Wantedly, Inc. における AWS の Savings Plans と Spot Instance の活用について記したいと思います。

Wantedly, Inc. のコンピューティングリソース事情として、ほぼ全てのアプリケーションが Amazon EKS で稼働しているため、実質的に「EKS Node をどう Savings Plans と Spot Instance で構成して運用していくか」という話になります。

目次

• Savings Plans (SPs) とは
• Spot Instance とは
• EKS on EC2 を使う
• EKS Node で SPs と Spot をどう使うか
• SPs / Spot 利用状況をモニタリングする
• おまけ: 最近は Spot Instance 料金が上昇トレンド？

Savings Plans (SPs)とは

1年、または3年間で利用するコンピューティングリソースをコミットメントすることで、割引を得られる仕組みです。この仕組みにはさらに

• EC2 Savings Plans: EC2 リージョンのインスタンスファミリーに対して割引
• Compute Savings Plans: EC2、Fargate、Lambda に対して割引
• SageMaker Savings Plans: SageMaker に対して割引（この記事は EKS Node の話なので割愛）

の3種類が存在します。Compute Savings Plans は EC2 Savings Plans よりも柔軟にコンピューティングリソースを指定できますが、割引率は EC2 Savings Plans のほうが高いです。

支払い方式も「月毎支払い」「一部前払い」「全額前払い」の3つがあり、順に割引率が高くなります。

SPs を購入すると、購入対象の起動している OnDemand インスタンスに対して自動的に割引が適用されます。EC2 インスタンスに対して設定がいらないのが嬉しいところです。

類似の割引サービスに Reserved Instance という仕組みがありますが、Savings Plans のほうが後発で、柔軟にコンピューティングリソースを指定でき、コスト管理がしやすくなっています。

Savings Plans は長いので、以下 SPs と書きます。ちなみに正式な略称はないらしいです。

Spot Instance とは

AWS側のコンピューティングキャパシティの都合で停止（中断）される可能性があるかわりに、オンデマンド料金に比べて単価が安いインスタンスです。料金や中断の頻度はインスタンスファミリーやタイミングによりけりです。Spot Instance Adviser というページで、インスタンスタイプごとにオンデマンド比較での費用節減率や、中断の頻度が確認できます。

Spot Instance を EKS や EC2 で使う場合は、EKS Node や EC2 の設定でキャパシティタイプを Spot 変更する必要があります。

EKS on EC2 を使う

Wantedly, Inc. の EKS 事情を書いておきます。弊社では EKS node には Fargate ではなく、EC2 を使っています。

EKS on EC2 になっているのは上記ブログにある通り、EKS が出る前から Kubernetes を AWS で構築していたので歴史的経緯といえばそれまでですが、いくつか EKS on EC2 のメリットがあるなと思ったので記しておきます。

EC2 はインスタンスファミリーを自分でコントロールできる

最近の EC2 インスタンスタイプは CPU 世代ごとに新しいものが出ている印象です。Fargate は x86 / Arm のような CPU アーキテクチャは選択可能ですが、EC2 のようにインスタンスファミリーを指定することはできません。つまり Fargate の裏でどの世代の CPU で動くか、そしてそれがいつ変更されるかはわかりません。

一方インスタンスタイプファミリーを指定することで、ある程度 CPU 性能の変化や、最新インスタンスへの変更の影響とタイミングを制御することができます。実際に m5 -> m6i へ変更したとき、カタログスペック上では「15%のCPU性能向上」となっていましたが、実際に変更したら CPU Based な HPA による Pod のスケールアウトも 10% 程度少なくなりました。

もし Fargate の裏側で CPU の性能向上が知らない間に行われた場合、「なぜか Pod のスケールアウト頻度が減った」という謎事象だけが残ります。問題にならなければよいですが、知らない変更をトリガーに問題が発生した場合は結構困ります。

EC2 だと BatchJob 実行で Node のイメージキャッシュが効いて嬉しい

Kuberentes だと CronJob や Argo Workflow などの定期実行ジョブをよく使うことになると思いますが、Fargate の場合だと毎回コンテナイメージの Pull が走ってしまいます。このコンテナイメージの Pull にかかるコストは NAT Gateway の金銭的なコストの他にも、バッチ起動時間にも影響を与えます。

EC2 の場合は一度 Pull したイメージはその Node に保持されるので、2回目以降で同一 Node の Job 実行はコンテナイメージが Skip されます。そのため金銭的にも Job の起動時間的にも嬉しいです。弊クラスタでは BatchJob 専用の Managed Node Group を作っており、BatchJob 実行が Web / API server に影響しないように Node を分離しつつ、 Node 内のイメージキャッシュを有効活用できるようにしています。

EC2 のほうが SPs 割引率が高くてお得

Fargate に適用できる SPs は Compute SPs ですが、前述の通り EC2 SPs のほうが割引率が高いです。リージョンやインスタンスタイプによって変わりますが、東京の m7g だと 7%ほど SPs のほうが割引率が高い（2023年9月時点）です。全体の規模が大きければそのコスト差額の絶対値は魅力的になります。

とりあえず思いつく EKS on EC2 のいいところを書きましたが、対する EKS on Fargate の管理コストの少なさは魅力なので、このへんの選択・付き合い方は千差万別だと思います。（予防線）

EKS Node で SPs と Spot をどう使うか

本番環境では EC2 SPs と Compute SPs を織り交ぜて1年間、全額前払い

通常 SPs と Spot では Spot のほうが安いことのほうが多いのですが、基本的に本番環境は可用性を高めたいため、現時点での本番環境においては Spot ではなく SPs を適用しています。ステートフルな Pod や長時間実行する機械学習バッチがそれなりに存在するため、Spot Instance の中断による影響を無視できません。

SPs は1年、または3年のコミットメントなので、コミットメント期間で絶対に使うと思える、定常的な本番環境のワークロード分を購入しています。また、今後コンピューティングのコスト削減を計画しているなら、その分少なめに購入します。逆に言うと定常的なコンピューティングの利用が見込めない、または突発的な需要の場合には SPs の利用は損するリスクが高いです。

Compute SPs よりも割引率が高い EC2 SPs の場合、インスタンスファミリーを指定して購入することになるため、m6g を購入したコミットメント期間中に m6g -> m7g といった基盤の変更をしてしまうと、m6g の支払いが無駄になってしまいます。そのため、弊社では3年ではなく 1年間のコミットメント で購入するようにして、全体的なインスタンスファミリーの変更は年1回をターゲットに運用しています。

とは言え1年のあいだ、本番環境で新しいインスタンスファミリーを全く利用・検証できないのは困ります。そのための保険として、インスタンスファミリーに限らず割引可能な Compute SPs を EC2 SPs と併用して購入しています。今年の購入割合としては EC2 SPs が 90%、残りの 10% が Compute SPs で構成しました。こうすることでインスタンスファミリー変更の検証を安く、やりやすくしています。

使う確度が高いものを買うので、支払いは 割引率の最も高い全額前払い を採用しています。ただ、支払いについてはキャッシュフロー管理の話にもなるので、会社のお財布事情（経理）とも相談したほうが良いです。

開発/ステージング環境では Spot Instance を使う

SPs は「定常的な本番環境のワークロード分を購入」しますが、開発環境やステージング環境では主に Spot Instance で構成しています。これはコスト効率が Spot のほうが高く、開発/ステージング環境ではキャパシティ回収時のインスタンス停止による影響が許容できるためです。

SPs / Spot 利用状況をモニタリングする

SPs 使用率アラート

SPs は前払いなので、購入した分を使えてない場合はその分払い損になります。そのため SPs は常に100 % が利用されていると嬉しいのでモニタリングしています。AWS Console で「Cost Management」から SPs の「使用状況レポート」から簡単に確認できます。

また AWS Console の「Billing Management」では SPs の使用率でアラートが設定可能です。アラートウィンドウも日、月、四半期、年と設定ができます。アラートが鳴ったら起動インスタンスに対して SPs が余ってる状態なので、開発環境で OnDemand インスタンスの割り当てを増やしたりしながら、コスト最適の運用を行っています。

Spot Instance 使用率アラート

Spot Instance は AWS 起因で利用量が変化するため、いつの間にか Spot Instance の割合が減っていて後から請求でびっくりしないようにモニタリングしています。具体的には、Spot と OnDemand の EC2 インスタンスの割合を Datadog でモニタリングしています。

実際、特定のインスタンスファミリーが枯渇して OnDemand インスタンスが急増したことがありました。このアラートをトリガーに、複数種類のインスタンスファミリーを EKS Managed Node Group で起動可能にするなどの改善を行っています。

おまけ: 最近は Spot Instance 料金が上昇トレンド？

今年の Savings Plans を計画していた時に、「Farewell to the Era of Cheap EC2 Spot Instances」というポストを見つけました。マクロ経済の変化によって、EC2 の Spot Instance 料金が上昇傾向だという内容です。リージョンやインスタンスファミリーによって状況は異なりますが、コスト観点で Spot と SPs の使い分けが今後変わるかもしれません。気になります 👀

ただし今のところ東京リージョンにおいては Spot Instance のほうが安いので、今後チームとしては本番環境でも安全に Spot Instance を使えるように改善して、よりコスト効率を上げていくことを考えています。

まとめ

EKS on EC2 で Savings Plans と Spot Instance を使ってコスト効率化している話を書きました。あんまり各社の Savings Plans 活用の話がインターネットに出てこない気がするので、参考になれば嬉しいです。