こんにちは。クルーズ株式会社CTOの鈴木です。
以前の投稿で「AWS Auto Scaling によるインスタンス管理に切り替えた話」をしましたが、今回はもう一歩踏み込んで、時間帯や負荷見合いでインスタンス台数を変動させ、その変動分のインスタンスをスポットインスタンスを使うことでトータルでインフラコストをもっと下げられないかを検討した際の話をしたいと思います。
SHOPLISTで採用しているAWS の各種インスタンスの購入方法
SHOPLISTでは現在主に以下の3パターンのインスタンスの買い方をしています
1.Compute Savings Plans
・現在主に利用している契約。
・主にEC2の購入で年数回に分けて購入。
・計上は前払費用として資産化し、それを毎月に分けて償却。
2.コンバーティブルRI契約(全額前払/前払無し)
・Savings Plansができる前に契約していたEC2に適応していた契約。
・現在は主にElastiCacheの契約として利用。
・インスタンスの世代の発表を予測し1年で買うか3年で買うかを判断。
・計上は前払費用として資産化し、それを毎月に分けて償却。
3.オンデマンド契約
・Savings Plans 更新時に将来的に削減が見込まれるのでその契約から外れたインスタンス分。
・季節需要やセール需要で一時的にしか稼働しない変動インスタンス分。
今回は「季節需要やセール需要で一時的にしか稼働しない変動インスタンス分」について、本当に必要な需要量をもっと突き詰めて考えると需要のある時間外が限定されるので、ここの部分をスポットインスタンスを利用することでAWSのコストを落とせないかを検討しました。
今回実施したコスト削減のシナリオ
基本的には下記3つを組み合わせてコストを下げるシナリオを立てて進めました。
①需要量によって変動分のサーバの運転時間を時間単位で減らすことによって運転時間を減らす。
②変動分のサーバのタイプ、時間当たりの単価の安いをオンデマンドからスポットインスタンスにすることで、時間当たりの単価を落とす。
③Webインスタンスをオンデマンドおよびスポット契約ともに、AMDインスタンスをさいようすることで、サーバ単価自体を落とす。
スポットインスタンスは、AWSもWebページでアナウンスがあるとおり、AWSクラウド内のEC2の余剰キャパシティを使うことにより、オンデマンド契約の料金として比較して最大で90%の割引を受けられる契約です。
一方、余剰キャパシティを利用している分、空きキャパシティが不足した場合、新規受付が中断されたり、最悪の場合稼働中のスポットインスタンスが中断され、回収され稼働台数が減るリスクがあります。
一応仕様上2分前に通知が来るようですが、現状2分で新規インスタンスの起動完了は難しく余剰台数を増やすことで回避する設計をしました。
例えば、今まで6台のCompute Savings Plansで動いていたサーバで、うち3台が24時間稼働、残り3台がピーク時間帯のみ運転する仕様の場合、以下のような台数構成で構築をしました
・Compute Savings Plans … 3台
・オンデマンドインスタンス(ピーク時間帯のみ稼働) … 2台
・スポットインスタンス(ピーク時間帯のみ稼働) … 2台
変動分全台をスポットインスタンスにするよりは削減効果は少ないものの、そもそも稼働していない分のコスト削減ができるので今よりコストが下がるのと、そもそもWebインスタンス全体をAMDインスタンスを利用することで微々たるものですがコストダウンを図ります。
結論
Auto Scalingの対象インスタンスで見ると、今までのCompute Savings Plansのみの場合と比較して約2割~3割の削減が実現できました。
2割~3割としているのは、そもそも今まで手動で増強/縮退運転をしていたにしても季節変動やセール影響での台数変動はあり、単純に前月比や前年同月比で削減効果を比較できないためですが、確実にコストの削減はできています。
今後の課題
現状Web、画像周りについてはAuto ScalingやManaged Service を使うことでコストの削減が着実に進んできているのですが、一方でDBインスタンスは柔軟にスケーリング運用できておらず、かつ元々のインスタンスサイズが大きいためコストの削減が一向にできていない状況となっており、コスト上の今後の大きな課題はDBインスタンスの費用を以下に減らすかにあります。
こちらはDBインスタンス側でどうこうするというよりも、まずはプログラムの作りを見直し、DBのスレーブサーバ台数を減らすことがもっともう効果的だと考えており、プログラムの見直しにより削減を進めたいと考えています。