先日、AWSからSavings Plansというとても良さそうなサービスの発表がありました。
https://aws.amazon.com/jp/blogs/news/new-savings-plans-for-aws-compute-services/
早速、クラスメソッドさんやserverworksさんが解説記事も書かれていて、大変参考になります。
https://dev.classmethod.jp/cloud/aws/new-savings-plans-for-compute/
http://blog.serverworks.co.jp/tech/2019/11/11/sp-vs-ri/
ただ、このSavings Plan、とても良さそうなものには見えるんだけど、カバー範囲が広くて複雑で、
「結局、これまでやってきたEC2のReserved Instance購入オペレーションはどうすればいいの？ どんどん切り替えていくべきなの？？」
って所が、１番気になるんだけど、そこに対しての明確な解が良く分からないままに、自分の会社でのRI更新のタイミングが訪れたので、↑に対する答えを求めて自分なりに調べてみたのでまとめてみます。
それぞれがどんなものなの？ってのは、ここでは解説しませんので、上記に紹介したリンクを始め、公式ドキュメントや各種関連記事等をご覧いただければと。
なお、この記事は、2019/11/28 時点での私個人での調査結果/判断で、
認識違いもあるかもしれませんので、皆様の組織での最終決定にあたっては、ご自身のユースケースに照らし合わせて改めてご確認ください。
また、こんな視点が漏れてるよ！みたいのがあったらご指摘いただけると嬉しいです。
tl;dr
- Convertible RIは、Compute Savings Planへの移行一択
- Standard RIは、EC2 Instance Savings Plansへの移行 or そのままStandard RI。
- (状況によっては、Compute Savings Planに切り替えちゃうのもあり)
以下、このような結論に至った理由を記載していきます。
Convertible RI
Compute Savings Planに移行すべき理由
- 割引率はConvertible RIとCompute Savings Planで同じ。
- 機能面の大きな違いとして、Compute Savings Planでは、
Automatically applies pricing to any instance familyというのがあり、instance familyを移動した時、自動的にコミット金額の割り当てを行ってくれるが、Convertible RIでは自分でオペレーションして、instance familyの切り替えを行わなければならない。
この２つを考慮すると、切り替えないという選択肢は無いかなと思う。
あえて、Compute Savings Planの穴を探すとすると、Convertible RIのinstance family変更時、金額が追加になった場合は、その差額はAWS側で計算されて支請いが発生するのに対して、Compute Savings Planでは、自分で差額を計算したり、Cost Explorerとにらめっこしながら、追加分を購入しないといけない所かな〜と思う。
が、これもRIの交換という手間を省けるというCompute Savings Planのメリットと総合して考えると、移行をためらう理由にはならないでしょう。
Standard RI
EC2 Instance Savings Plansへの移行 or そのままStandard RI
- Convertible RI vs Compute Savings Planでは、後者に切り替えることで、instance familyの変更時に、透過的に適用先が切り替わってくれるようになるという、決定的な差が存在したけれど、Standard RIとEC2 Instance Savings Plansの間では、これといった機能差は無いように思える。
- 違いとしては、購入の単位が、Standard RIではfamily内でのコア数、EC2 Instance Savings Plansではfamily内での１時間あたりの利用料金ということになるくらい？
- 特に差がないのであれば、新しいものに乗っかっていく方がいいかな、、？というのはあるけど、私が今いる会社でのユースケースを考えると、EC2 instanceとRIが1対1で紐づくことが多いので、Standard RIの方式の方がマッピングがしやすそうと感じる。
- Standard RIでは、ちょっと前にRIの予約購入機能なるものが発表されて、RIが切れたタイミングに合わせて買う！みたいな作業をしなくて良くなった。
書き出してみると、現状では、従来通りのStandard RIで更新してしまう方がやや優位かもしれない、、？ ただ、AWSの進化を考えると、新しい流れに乗っておいた方が今後新たなメリットを色々と享受出来る可能性もあり、決定打にかけるかな〜という感じ。
Compute Savings Planにしちゃう！？
これは、Savings Planを調べながら、改めて自分たちのRI運用を考えながら思ったこと。
Convertible RIではなく、 Standard RIを使っている人のほとんどは、割引率の大きさを理由として挙げると思う。Compute Savings PlanはConvertible RI相当の割引率なので、切り替えると、そのメリットは失われる。
ただ、サービス規模が拡大して、EC2 instanceが増えるにつれて、Standard RIでは以下のようなデメリットが発生していて、何らかの改善は必要とずっと感じていた。 (同様の問題を抱えている人は多いはず？)
- 複雑化していく一方のStandard RIの購入運用
- 複雑化しすぎて、書い漏れ等が発生して、RIのコストメリットを最大限に享受できない
- せっかく新しいinstance typeが発表されて、技術的には大したコストをかけずに切り替えることもできるのに、RIの制限で切り替えることが出来ないちょっとした残念な気持ち
- RIの更新タイミングと、instance family変更のタイミングを合わせないといけないという調整の手間
Convertible RIへの切り替えはこれらの問題への大きな解決策となるかもしれない。
仮にConvertible RIを導入しても、RI変換の手間は発生するので、割引率を超えるほどのメリットがあるか？、、というと、微妙な所があった。それが、先に書いた通り、Compute Savings Planでは、適用するinstance familyの切り替えは透過的に行ってくれるようになる！これによって、全てをCompute Savings Planにしちゃえば、今後のオペレーションは定期的にCost Explorerをチェックし、RIの買い漏れを発見したら、何も考えずに、コミット金額を超えてon-demandになっている分のCompute Savings Plan買い増すだけという、相当に単純なオペレーションに集約することができそう。
ということで、Compute Savings Planに切り替えちゃうか否かは、
割引率の低下 vs RIの買い漏れ等による余剰な支払い、複雑なRIオペレーションの削減
を天秤にかけて、エイやで決める！という感じになるのかな〜と想像したのでした。
または、変更の可能性がない独立したコンポーネントで、金額のでかい部分 (e.g. 巨大の自前hadoop cluster) だけはスタンダードRI or EC2 Instance Savings Plansを使って、それ以外の部分をCompute Savings Planへ！という合いの子というのもありかもしれません。
ただ、AWS Cost Managementの画面を見ると、"Savings Plan" と "Reservations"で項目が分かれていて、それぞれでレポートが表示されるようなので、運用考えると、統一しちゃった方がいいのかもしれないけど、実際に購入して使い始めみないと分からない。。
以上、Savings Planのことを調べつつ、RI運用について思うことをツラツラと書いてみました。
事実を誤認している所や、何か考慮足りない部分などありましたら、ご指摘いただけると嬉しいです！
皆さま、良いRI or Savings Plan 生活を！！