Photo by Michael Longmire on Unsplash
こんにちは。並河(@namikawa)です。
最近は、朝晩がずいぶん冷え込んできまして、まだ秋かと思いきや既に冬に突入しそうな雰囲気です。どちらもラーメンが美味しいことに変わりはありませんが。
そして、このテックブログはメンバーで持ち回りにしているのですが、今回から2巡目になります。開設してから約4ヶ月。思ったより早いw
さて、今回のエントリではAWSのコスト削減の話をしようかと思います。
弊社で稼働させているプロダクト・サービスの基盤は、基本的にAWSを採用しており、コスト感でいうと、AWSだけで月額数百万円くらいの規模感です。
おかげさまでサービスの伸長に伴い、この1年くらいで特にこれらの基盤コストも伸びてきているので、コスト削減の取り組みをぼちぼちしていかねば、というところで、いくつかの切り口で施策に取り組んできました。
ストレージやDBの利用の仕方の工夫など、プロダクトの特性に応じた施策も行ってきたのですが、このエントリでは、AWSのコスト削減の王道の1つである Savings Plans / Reserved Instances にスコープを絞ろうかと思います。
Savings Plans / Reserved Instances に関する情報は、インターネット上にもたくさんあるかと思うのですが、複数のサービスをAWSで運用している企業が、こんなことを考えながら買ったよ、っていう1つの事例として見てもらえればと思います。
Savings Plans と Reserved Instances
まず Savings Plans (以降、SP) と Reserved Instances (以降、RI) は何ぞや？という話ですが、どちらも特定のリソースに対して、事前に一定期間の使用量をコミットすることで、ディスカウントを受けることのできる仕組み・サービスです。
厳密には、(ゾーンを指定した)RIの方はその名の通りリザーブド(予約)されます。
クラウドサービスも裏側では無限のリソースがあるわけではないはずなので、(あまり見かけないですが) 時には場合により特定のリソースが枯渇することもあるでしょう。そんな時が来た際に困らないよう事前にキャパシティを確保しておく。それがRIです。(ディスカウント的にも恩恵を受けられる。)
SP も RI も条件が多岐に渡り複雑になっているため、私も理解するのに苦労しました。
以下のクラスメソッドさんのエントリが上記の違いなども含めてよくまとまっているかと思いますので、ここで紹介させていただきます。
SP/RIの検討と購入
購入前に、以下に記載されていることを中心に検討・整理を行ってから、購入を行いました。
不要なリソースの整理
まずは基本的なことですが、リソースの棚卸しです。
EC2やRDS等のインスタンスのリストを作り、各サービスの担当者にヒアリングを行い、SP/RIで対象となるEC2やRDSのインスタンスで本当に必要なのかどうかをチェックしていきます。たくさんインスタンスがあると、その中で実は使っていませんでした、とか、必要なんだけど今はシャットダウンさせておいても大丈夫です、などのリソースが出てくるので、そういった不要なリソースの整理を行います。
インスタンスサイズ・ファミリーの見直し
次に、必要な各インスタンスのリソースの過不足を確認します。
CloudWatch等で負荷状況やリソース利用状況を確認し、インスタンスタイプが適切かどうかを見直します。過剰にリソースが割当たっている場合はスケールダウン、不足している場合はスペックアップする感じ。
あと、RIや、SPでも EC2 Instance Savings Plans を使う場合は、インスタンスファミリーも固定されることになるので、古い世代のインスタンスファミリーなどを利用している場合は、新しい世代への変更等も検討・必要に応じて変更を行います。
ここまでの整理で、必要なインスタンスがどういうインスタンスタイプで動いているのかのリストが完成したかと思います。
SPとRIのどちらを買うのか
結論、弊社では両方とも買いました。色々考え方はあると思いますが、以下のような棲み分けです。
RI
- RDSやAuroraは、RIにしか対応しないので、これらのリソースはRIにて購入。
- 弊社内で一部既存システムのリプレースプロジェクトが走っている関係で、既存システム(近未来にリプレースされるもの)に基本的に変更が行われない想定のものは、RIで購入した。
- インスタンスファミリー、リージョン、ゾーンなどが固定されるが、一番割引率が良かった気がする。
SP
- 上記RIの購入条件にあてはまらないものは、基本的にSPを購入。
- SPは3種類あるが、基本的に Compute Savings Plans で購入。
- インスタンスファミリーが縛られないのと、Fargate や Lambda にも適用されるため。
どのくらい買うのか
最もディスカウントの恩恵を受けるためには、稼働している全インスタンスをSP/RIの対象とする買い方ですが、何かの弾みで不要になったり、上記のシステムリプレースでの対象リソースも、段階的に不要になっていくケースなどもあります。
弊社では、社内での開発スケジュールを勘案して、購入対象ごとに微妙に変化させていますが、割合的には、およそ7〜8割くらいのリソースを対象に購入しました。
どのアカウントで買うのか
弊社では、各プロダクトごとにAWSアカウントを分離しているため、AWS Organizations でアカウント管理を行っています。
で、SPやRIを各アカウントごとに分けて買うのか、という部分ですが、SP/RIは、Organizations 内で共有することができるので、弊社では、マスターアカウント(管理アカウント)で一括購入しています。
マスターアカウントで購入すると、そこにリンクさせているメンバーアカウントに共有・適用させることができます。尚、各メンバーごとに共有させない設定をすることもできます。
ちなみに、マスターアカウントで購入すると、どういった形で他アカウントにSPやRIが適用されるのかというと、AWSの方に質問させてもらったところ、基本的には Organizations 内で、最も課金額(リソースの使用量？)の大きなアカウントから順に、稼働しているオンデマンドインスタンスから適用されていくようです。
(各プロダクトごとに管理会計なんかを行っていると、後で請求書ベースで計算し直さないといけなかったりするので、そこまで考慮すると少しやっかい、というか面倒臭いかもしれません...)
いざ購入！
購入は AWSコスト管理 のページから購入します。
何をどのくらい買うかは、SP/RIともに上記ページの左サイドのメニューにある「推奨事項」のリンク先で、このタイプをこのくらい買えばいいよ！って教えてくれるので、そこを参考に検討します。
先ほども記載した通り、弊社では、推奨事項の数字の(各項目ごとに割合は違いますが)およそ7〜8割くらいの数値感で購入しました。
尚、RIを購入する際は、同じインスタンスファミリータイプであれば、複数のインスタンスタイプのRIを合算して適用することができるので、そのインスタンスファミリーで購入可能なRIで最も小さなインスタンスタイプのRIを購入するようにします。
↑の説明はわかりづらいと思うのですが、例えば t3.medium のRIを2つ購入したい場合、購入するRIは t3.nano を 16個購入することになります。
こういう買い方をすることで、将来的に t3.medium の2インスタンスを、t3.large 1インスタンスに統合したくなった場合でも、購入したRIを継続して適用可能になります。
上記の具体的な計算は正規化係数に基づいて行われていますので、詳細は下記AWSのドキュメントを参照してみてください。
あと、気をつけないといけないのは、(弊社もそうだったのですが) RIなどを一気に購入しようとすると、クォータ(購入上限)に引っかかったりしますので、事前に計算できる場合は、緩和申請しておきましょう・・・。
購入後のモニタリング
SP/RIの購入後に、きちんと適用されているかどうか、については、AWSコスト管理 の「使用状況レポート」から確認できるので、たまにウォッチしておくと良いと思います。
上記は一例ですが、こんな感じで使用率を日単位で確認することができます。
・・・はい、という感じで、弊社ではこんなことを考えて、SPやRIを購入しました、というログのご紹介でした。
SPやRIについては、先のことを見据えた上で、うまく利用できれば、数十％といった費用削減が可能なので、今後も活用していこうと思っています。あと、その前段で各種リソースの棚卸しや見直しのきっかけにもなるので、意外とこちらも重要かとは思うので、定期的にやっていこうと考えています。
最後に、弊社では一緒に開発を行っていただけるエンジニアを絶賛大募集しておりますので、少しでも気になれば、カジュアルにお話ししましょうー。疑問・質問などございましたら、お手数ですが (@namikawa) まで気軽にDM等いただければと思います。
それでは！=͟͟͞͞(๑•̀=͟͟͞͞(๑•̀д•́=͟͟͞͞(๑•̀д•́๑)=͟͟͞͞(๑•̀д•́
