バニッシュ・スタンダードでインフラを担当していますTmaと申します。
前回は「コスト削減の軌跡 Part1」と題しまして、コスト削減のアプローチについて書かせていただきました。
今回は弊社で具体的に行った施策について書かせていただきます。
Reserved Instance, Savings Planを利用する
インフラもアプリケーションも変更がないコスト削減といえばこれをおいてはないですね。
弊社で利用している ECS(Fargate), RDS, OpenSearch Service, ElastiCacheなどはReserved Instance(以下RI)やSavings Plans(以下SP)を契約しています。
システムは何も変えずに契約形態を変えるだけで簡単にお得になるとの見方もあるのですが、細かい契約形態や、契約後も定期的に見直しを行っていくなどの堅実な運用が求められます。
支払い方法に関しては前払をすればさらにお得になるのは違いないのですが、特定の月にAWSコストが増加する状況を会社の予算編成的に許容できるかという部分が大きいです。
この辺りは会社の方針とすり合わせになるので、システムの変更はありませんが、この辺の調整事の方が場合によっては大変かもしれませんね。
さて、一番頭を悩ませるのがどの程度のボリューム感で契約するかという点です。
未来は予測できないので無駄のない、全ての稼働リソースをカバーした完璧な契約は結ぶことは当たり前ですができません。
この先システムの需要は増えるのか、減るのか。システム改修で増減する可能性もあります。
Compute Savings PlanならばFargateだけでなく、EC2やLambdaの利用量までカバーしてくれますし、RDSなら正規化という概念があって、ある程度インスタンスサイズに柔軟性があります。多少予想がブレてもなんとかなることも多いです。
反対にOpenSeach ServiceやElastiCacheはインスタンスタイプ固定なので、購入したRIが使い回しができないこともしばしばあります。
この辺りはある程度予測が外れるリスクを許容しつつ、弊社ではクォーター毎にRI, Savings Planの契約を見直すようにしています。
購入を四半期毎に分散することで、予測とのブレを吸収するようにしています。
それでもRIを契約することでお得になる損益分岐点に達せずに無駄になってしまったこともなくはないですが、トータルで見れば大変コスト削減に寄与しています。
Fargate Spotを利用する
契約つながりでもう一つ、「Fargate Spot」についてです。
こちらはインフラも若干変更しています。
ご存知の通り「Fargate Spot」はいつ落ちても文句は言えない代物なので、落ちてもそんなに痛くない開発環境やステージング環境で積極的に利用しています。
設定もECSのCapacity Providerを変更するだけで済むので、非常にお手軽です。
本番での利用をやや躊躇する理由として大きいのは、Fargate Spotのリソースが確保できなかった時に困るという点があります。
Capacity Providerを駆使しても「Fargate Spot」が確保できなかった場合に「Fargate」を利用するように自動的にはできないという事です。
このような理由から、弊社の場合は例えばキューを処理するような、ある程度の処理遅延が許容されるような箇所で「Fargate Spot」を利用しており、特にキューを処理する箇所について積極的に利用しています。同じ構成で、Capacity Providerの設定だけが異なる、「Fargate」と「Fargate Spot」で動作する二つのECSサービスを作成し、普段は「Fargate Spot」で動作させています。「Fargate Spot」が落ちた場合はEvent Bridgeで検知した上で、「Fargate」のサービスに切り替える方式をとっています。
ちなみにFargateに限らず、Graviton化を進めているのですが、今の所Fargate SpotにはArmがきていないのが辛いところです。
まとめ
今回はインフラもアプリケーションも変更しないコスト削減ということで、主に契約形態に関わる部分に関する内容についてお届けしました。
次回Part3ではインフラを積極的に変更してコスト削減を行った事例をご紹介できればと思います。
Discussion