『家族アルバム みてね』
現在に至るまでの間、サービスやインフラの成長に合わせそれらの使い方を試行錯誤してきましたが、振り返ってみるとどのタイミングでも注意すべきポイントは共通していることがわかりました。
そこで今回の記事では、みてねでのRI/
RIとSPsとは
振り返りの前にまずは、RIとSPsの概要について紹介します。
RIとSPsはどちらも1年または3年の期間でAWSリソースの利用を予約することで、利用料金の割引といった恩恵を受けることができる料金モデルです。
RIにはスコープ
(ここではそれぞれの詳細な仕様までは立ち入りませんが)
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はインスタンスファミリーやリージョンを購入時に決定しておく必要があり注意が必要です。
たとえば
この場合インスタンスファミリーが変わってしまうので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に移行しました
スポットインスタンスにはRI/
また、購入時点で移行作業がどの程度進むか不明瞭だった場合は、あえてCompute Savings Plansを優先的に利用し、SPs購入後にスケジュールの変更があっても購入済みの枠が余ることがないように留意しました。
Amazon EKSへの移行完了後はすべてのEC2インスタンスがスポットインスタンスになったというわけではなく、できるだけ中断したくないワークロードの実行などいくつかの目的でオンデマンドインスタンスを並行利用しており、そこをカバーできるだけのSPsを引き続き購入しています。
ただし、Amazon EKSに移行したことでコンテナベースとなり、EC2インスタンスのどのファミリーを利用するかは流動的になりました。このため、現状はEC2 Instance Savings Plansを利用せず、Compute Savings Plansのみを利用するようにしています。
また、現状のオンデマンドインスタンス・
Amazon AuroraとAmazon ElastiCacheにおけるRIの活用
みてねではAmazon Aurora(以下、Aurora)とAmazon ElastiCache
AuroraやElastiCacheはEC2とは違い流動的な要素が少ないため、購入に際して工夫したポイントはあまりなく、必要な分を愚直に購入しています。
ただし、RIの更新タイミングでAuroraやElastiCacheのソフトウェアバージョンアップ・
RI/SPsの購入にあたってのポイント
最後にまとめとして、RI/
オートスケーリングに注意する
AWS Auto Scalingなど、何らかの形でオートスケーリングの機能を利用している方は多いと思います。このとき、サービスのピーク帯の数時間のみオートスケーリングによって起動するEC2インスタンスがいくつかあったとします。こういった状態で、RI/
こうならないためにも、EC2インスタンスを
あえて数回に分けて購入する
たとえば、RI/
購入回数を分割しすぎると管理コストは大きくなってしまいますが、買いすぎて余らせてしまったといった場合のダメージを最小限に抑えられるので、管理コストが許容できる範囲で分割数を決めるようにしましょう。
できるだけ正確なフォーキャストを立てるようにする
これはあたりまえではありますが、購入前にはできるだけ正確なフォーキャストを立てるようにしてください。購入後に
個人的に、正確なフォーキャストを立てるためには関連するメンバーとの綿密なコミュニケーションが重要と考えています。実際にAWSを利用するエンジニアはもちろん、POやPdMなど様々なロールのメンバーとコミュニケーションを取ると、フォーキャストの確度が高まっていくのでおすすめです。
また、数量に不安がある場合は少なく見積もると良いです。RI/
「推奨事項」を鵜呑みにしない
RI/
あくまでも、自分たちのワークロードやフォーキャストに合わせて適切な計画を立てることがベストだと考えています。
最後に
RI/
この記事が読んでくださった皆様の参考になれば幸いです。