『家族アルバム みてね』（⁠⁠以下、みてね）ではサービスの拡大に合わせてAWSのコスト削減のために、2018年から5年間にわたってReserved Instances（以下、RI）とSavings Plans（以下、SPs）の活用をしています。

現在に至るまでの間、サービスやインフラの成長に合わせそれらの使い方を試行錯誤してきましたが、振り返ってみるとどのタイミングでも注意すべきポイントは共通していることがわかりました。

そこで今回の記事では、みてねでのRI/SPsの活用の歴史を振り返りながら、それぞれを購入する際に注意すべきポイントについて共有いたします。

RIとSPsとは

振り返りの前にまずは、RIとSPsの概要について紹介します。

RIとSPsはどちらも1年または3年の期間でAWSリソースの利用を予約することで、利用料金の割引といった恩恵を受けることができる料金モデルです。

RIにはスコープ（リージョナル・ゾーン）や、クラス（スタンダード・コンバーティブル）といった区分があります。また、SPsにはEC2 Instance Savings Plans・Compute Savings Plans・SageMaker Savings Plansといった区分があり、初めはどれを選んで良いかわからないかもしれません。

（ここではそれぞれの詳細な仕様までは立ち入りませんが）仕様が複雑であり特徴も異なるためどれを選択すべきかは利用目的によって異なります。このため一概にどれが良いとは言いにくいのですが、本記事が意思決定の参考になれば幸いです。

Amazon EC2におけるRIとSPsの活用の歴史

みてねのAmazon EC2(以下、EC2)におけるRIとSPs活用の歴史を振り返り、それぞれの時代で直面した課題や背景とともに、どのようにRIやSPsを導入しながらコスト効率化を進めてきたのかを順番にご紹介します。

オンデマンドインスタンス＋RI時代

みてねではサービス開始当初よりAWS OpsWorksを利用していたのですが、「⁠スポットインスタンスの利用が困難」という課題があり、オンデマンドインスタンスを全面的に利用していました。

このため、サービスの規模が拡大するにつれEC2のコストが課題となりコスト削減を目的としてRIを利用し始めました。

このときは利用開始直後ということでRIやSPsといった料金モデルに対しての知見も浅く、オンデマンドインスタンスの使用量に対してのRIのカバレッジ率を上げていけるように、購入量や内容の調整を行っていました。

オンデマンドインスタンス＋SPs時代

引き続きAWS OpsWorksを利用していたところ、2019年11月にSPsがリリースされました。SPsのリリース当初は、EC2 Instance Savings PlansとCompute Savings Plansの2種類のみのラインナップとなっており、Compute Savings Plansの対象となるサービスも少なかったのですが、それでもRIと比較して柔軟な料金モデルにメリットを感じました。よって、RIからSPsに全面的に乗り換えることにしました。

みてねではSPsリリースの翌月である2019年12月に初めてEC2 Instance Savings PlansとCompute Savings Plans両方の購入を行い、既に購入済みだったRIの期限切れを経て2020年中にSPsへの全面移行を完了することができました。

EC2 Instance Savings PlansとCompute Savings Plansの使い分けについてですが、みてねでは基本、割引率の高いEC2 Instance Savings Plansを優先的に利用しています。ただし、EC2 Instance Savings Plansはインスタンスファミリーやリージョンを購入時に決定しておく必要があり注意が必要です。

たとえば「主にC5インスタンスを使っていたのでそれに合わせてEC2 Instance Savings Plansを購入したが、ワークロードの変化に伴ってR5インスタンスを使うようになった」といったような場合です。

この場合インスタンスファミリーが変わってしまうのでEC2 Instance Savings Plansが適用対象外となり、割引を受けるどころか却って損をしてしまう可能性があります。ですので、このようなリスクの高い部分に関しては、インスタンスファミリーなどが変わっても柔軟に対応できるCompute Savings Plansを併用するようにしています。

余談ではありますが、SageMaker Savings Plansは2021年4月に後追いでリリースされたラインナップで、このときにはSPsの知見はある程度溜まっていました。このため、リリース後は使い方や料金モデルに迷うことなくSageMaker Savings Plansをシームレスに使い始め、すぐにAmazon SageMakerのコスト削減を実現することができました。これはSPsの基本的な料金モデルを理解しておけば、新たなメニューが拡充されてもすぐに使い始めることができると感じた印象的な出来事でした。

また、Compute Savings Plansも後追いでAWS FargateやAWS Lambdaが適用対象に含まれるようになり、一度料金モデルを理解しておけば後から使える場面が増えたことは嬉しい誤算でした。

スポットインスタンス＋SPs時代

2021年中旬に長年実施してきたサービスインフラの大改造が完了し、オーケストレーションツールをAWS OpsWorksからAmazon EKSに移行しました（詳細は弊社生島の 4年間のEKS移行の取り組みを振り返って にて詳しく説明しています⁠）⁠。これによって、オンデマンドインスタンスを中心とした構成だったのが一変し、スポットインスタンス中心の構成になりました。

スポットインスタンスにはRI/SPsは適用できないため、これに伴ってSPsの購入量は激減しました。実際にはある時点で一気に移行したわけではなく徐々に移行を進めていたため、そのペースに合わせて購入量を徐々に減らしていきました。

また、購入時点で移行作業がどの程度進むか不明瞭だった場合は、あえてCompute Savings Plansを優先的に利用し、SPs購入後にスケジュールの変更があっても購入済みの枠が余ることがないように留意しました。

Amazon EKSへの移行完了後はすべてのEC2インスタンスがスポットインスタンスになったというわけではなく、できるだけ中断したくないワークロードの実行などいくつかの目的でオンデマンドインスタンスを並行利用しており、そこをカバーできるだけのSPsを引き続き購入しています。

ただし、Amazon EKSに移行したことでコンテナベースとなり、EC2インスタンスのどのファミリーを利用するかは流動的になりました。このため、現状はEC2 Instance Savings Plansを利用せず、Compute Savings Plansのみを利用するようにしています。

また、現状のオンデマンドインスタンス・スポットインスタンス・SPsそれぞれの使用量を示したグラフをご紹介します。グラフからEC2インスタンス全体のうち約95％がスポットインスタンスで運用されつつ、残りのオンデマンドインスタンスのうち約75％にSPsが適用されていることがわかります。結論としてSPsを更に買い足す余地がないレベルまで効率よく運用できており、大きなコスト削減を実現することができました。

Amazon AuroraとAmazon ElastiCacheにおけるRIの活用

みてねではAmazon Aurora(以下、Aurora)とAmazon ElastiCache（以下、ElastiCache）も利用しており、これらのサービスに合わせて用意されているAmazon RDS Reserved InstancesとAmazon ElastiCache Reserved Nodesも活用しています（ここではまとめてRIと呼びます⁠）⁠。

AuroraやElastiCacheはEC2とは違い流動的な要素が少ないため、購入に際して工夫したポイントはあまりなく、必要な分を愚直に購入しています。

ただし、RIの更新タイミングでAuroraやElastiCacheのソフトウェアバージョンアップ・インスタンスタイプの更新などを行うようにしており、メンテナンス時期を機械的に決定できるようにしています。これによって、メンテナンスのスケジュールが立てやすくなったことは非常に良かったと感じています。

RI/SPsの購入にあたってのポイント

最後にまとめとして、RI/SPsのそれぞれの購入にあたってどちらでも共通して得られた知見をいくつかご紹介します。

オートスケーリングに注意する

AWS Auto Scalingなど、何らかの形でオートスケーリングの機能を利用している方は多いと思います。このとき、サービスのピーク帯の数時間のみオートスケーリングによって起動するEC2インスタンスがいくつかあったとします。こういった状態で、RI/SPsの購入時に、オートスケーリングによって時々起動するインスタンスを計算に入れてしまうと、ほとんどの時間はRI/SPsが買いすぎで余っていることになり、最悪の場合では損をしてしまう可能性もあります。

こうならないためにも、EC2インスタンスを「常時起動しているもの」と「オートスケーリングによって時々起動するもの」の2つに分類し、前者をカバーするだけのRI/SPsを購入するようにしましょう。

あえて数回に分けて購入する

たとえば、RI/SPsを1年の期間で購入するとして、1回で必要な分すべてを購入すると次に購入数を調整できるのは1年後になります。これを2分割して、1回目の購入後の半年後に2回目の購入を実施すれば、半年に1回のペースで購入数の調整ができることになります。

購入回数を分割しすぎると管理コストは大きくなってしまいますが、買いすぎて余らせてしまったといった場合のダメージを最小限に抑えられるので、管理コストが許容できる範囲で分割数を決めるようにしましょう。

できるだけ正確なフォーキャストを立てるようにする

これはあたりまえではありますが、購入前にはできるだけ正確なフォーキャストを立てるようにしてください。購入後に「実はもう必要ないリソースだった」といったような話が出て、購入済みのRI/SPsが無駄になってしまった（それどころか損をしてしまった）という事故を防止するためです。

個人的に、正確なフォーキャストを立てるためには関連するメンバーとの綿密なコミュニケーションが重要と考えています。実際にAWSを利用するエンジニアはもちろん、POやPdMなど様々なロールのメンバーとコミュニケーションを取ると、フォーキャストの確度が高まっていくのでおすすめです。

また、数量に不安がある場合は少なく見積もると良いです。RI/SPs購入後に実際に少ないことがわかれば、その時点で買い足して調整すればリカバリができるためです。逆に多く見積もった場合、先程と同様に購入済みのRI/SPsが無駄になってしまう可能性があるので注意してください。

「推奨事項」を鵜呑みにしない

RI/SPsともに、AWSマネージメントコンソールから「推奨事項」を利用することで、適切な購入数をAWSに計算してもらうことが可能です。過去の使用状況を元に自動で算出されるのでもちろん参考になるデータではあるのですが、これだけを鵜呑みにしないようにしましょう。

あくまでも、自分たちのワークロードやフォーキャストに合わせて適切な計画を立てることがベストだと考えています。

最後に

RI/SPsの運用というと一見退屈な定形作業のようにも思えますが、振り返ってみるとさまざまな工夫ポイントがありやってみると意外とおもしろいかもしれません。一方でこういったノウハウは属人化しやすいため、明文化することでノウハウを共有していくことが大切だと考えています。

この記事が読んでくださった皆様の参考になれば幸いです。