SREの髙木です。
長引く円安の影響によるAWSのコスト増加に頭を抱える方が少なくないかと思います。
例に漏れず弊社も悩まされており、SREがコスト削減に取り組んでいます。
今回はコスト削減に取り組んだ事例をご紹介します。
コスト削減に取り組む際に意識したこと
1.会社の利益に貢献するという意識でポジティブに取り組む
「コスト削減」という言葉にネガティブな印象を受ける方もいらっしゃるかもしれません。
しかし、コスト削減は会社の利益向上に直結する活動です。
コスト削減活動を通して会社に貢献しているという意識でポジティブに取り組みました。
2.余計なものを削ぎ落とし必要なものは残す
コストを大きく削減しようとするあまり、お客様にご迷惑をおかけしたり従業員の利便性を損なっては元も子もありません。
必要なものは残しつつ不要なものだけを削ぎ落としていきます。*1
3.周囲の協力を得るためにコスト効果を説明する
開発者や非エンジニアの協力が必要になることもあります。
具体的にどの程度の削減効果を得られるのか説明することで、協力を得やすくなります。
また、コスト削減活動に巻き込むことを通じて開発者や非エンジニアのコスト意識を高め、不要なコストの発生を抑制することも期待できます。
事例紹介
まずは現状を把握する
毎日/毎週/毎月など定期的にBillingやCost Explorerでコストを確認します。
Cost Explorerではさまざまな条件を指定し、複数の観点でコストを見ることができます。
基本的にはまずDimensionでサービス毎/アカウント毎/リソース毎などの条件で内訳を出し、そこから特定のサービス/アカウント/リソース等に絞り込みながらコスト構造を深掘りしていきました。
不要なリソースを削除する
多くの組織において、以下のようなリソースが多かれ少なかれ存在するのではないでしょうか？
- 検証目的などで一時的な利用のために作ったあと、一時的な利用が終了しても削除されずに放置されているリソース
- 新しい環境へ移行したり新しい仕組みに置き換えて不要になったが、削除されずに残っている古いリソース
- 何に使っているのか分からないリソース（名前から用途が推測できない、リソースの作成者が退職している、等の理由）
このようなリソースが存在することで不要なコストが発生するだけでなく、認知負荷が高まり混乱を招くこともあります。
いわゆる割れ窓理論で、このようなリソースを放置し続けると今後も放置されるリソースが生まれ続けることが懸念されます。
1~3いずれの場合も最初に行ったことは地道な検索と聞き込みです。
ドキュメントやSlackを検索したり知見がありそうな人にヒアリングし、削除できると判断したら削除しました。
ドキュメントとSlackを検索しても情報が見つからず、誰も知見がない場合は対象のリソースCloudWatchのメトリクスやCloudTrailのログを見て、リソースが使用された痕跡があるか確認します。
ALBやCloudFrontなど、ログを出力できるサービスであればログも確認します。
今後は定期的にBillingやCost Explorerを確認してコストの変動をキャッチアップすることに加えて、Cost Anomaly Detectionの検出条件を精緻化しコストの異常を素早くキャッチアップできるようにしようと考えています。
AWS Compute Optimizerを活用しプロビジョニング量を最適化する
AWS Compute Optimizerを有効にすると、リソースのプロビジョニング量が過剰あるいは過小であるかを自動で分析してくれます。
過剰あるいは過小と判定されたリソースについては、最適化するための推奨事項が提案されます。
お客様や従業員への影響が小さくコスト効果が大きいものを順次対応していきました。
スポットインスタンスの利用率を増加させる
スポットインスタンスは、AWSデータセンター側の余剰キャパシティを使用してEC2インスタンスを大幅な割引価格で使用できる代わりに、AWSデータセンター側でキャパシティが不足したタイミングで停止するEC2インスタンスです。
開発環境ではそこまで大きな問題にはならないだろうと考えました。
一部の開発者にスポットインスタンスの利用を提案したところ、ありがたいことに快諾してくれました。
開発者にスポットインスタンスの性質を説明したうえで、開発環境が稼働しているEC2インスタンスをスポットインスタンスに変更しました。
スポットインスタンスに変更してから2ヶ月程度経過した時点で、開発者が困っているという声は0件です。
前述のAWS Compute Optimizerの推奨事項の対応と開発環境のスポットインスタンス化により、EC2インスタンスの費用を10%程度削減できました。
Reserved Instance(RI), Savings Plans(SP)の使用率とカバー率を上げる
RIとSPは、AWSへ料金の支払い額を事前にコミット（契約）することで従量課金のAWSサービスを割引価格で利用できるサービスです。
Cost Explorerで、現在契約しているRIとSPの使用率に加えて追加契約の推奨事項が提示されます。
基本的に推奨事項に従って契約しました。
ただし、推奨事項はあくまでも過去の利用状況に基づいた内容であることに注意してください。
いつ頃にどのようにリソースが変化しているか将来の計画を確認したうえで、RI/SPを契約した場合と契約しない場合のコストを計算し、「将来のこの時期にこのリソースが変更・削除されるならRIを購入せずにオンデマンドインスタンスを利用する方が安いので、推奨事項に表示されているが契約しない」という判断をしたケースもありました。
なお、RIとSPでは契約期間と支払い方法に複数の選択肢があります。 *2
- 契約期間
- 1年または3年
- 支払い方法
- 全額前払い
- 契約期間内に発生する金額を全て一括で払う
- 一部前払い
- 契約期間内に発生する金額のうち半分を一括で払い、残りの半分を毎月分割で支払う
- 前払いなし
- 契約期間内に発生する金額を1ヶ月単位で分割し毎月支払う
- 全額前払い
契約期間が長いほど割引率が高く、また前払いする金額が多いほど割引率が高くなります。
つまり3年分を全額前払いで契約するのが最安です。
ただし、AWSの円建ての支払い金額は請求時点の為替で決まるため、為替が円高に振れた場合には前払いなしの方が安くなる可能性があります。
また、キャッシュフロー的に前払いを許容できないケースもあるでしょう。
為替変動リスクへの対応方針やキャッシュフローの事情は会社によって異なるかと思いますので、会社の方針に合わせて契約期間と支払い方法を選択しましょう。
インスタンスの利用状況は変動しますので、一度RI/SPを契約した後も定期的に使用率とカバー率を確認しています。
インスタンスタイプをGravitonに変更する
RIの期限切れが近づいたタイミングに合わせて、ダウンタイムの発生が許容できるAuroraとRDSのインスタンス（主に開発環境のインスタンス）をIntelからGravitonに変更することを計画しました。
EC2やEKSの場合は、CPUアーキテクチャが変わることによるアプリケーション動作への影響を確認する必要がありますが、マネージドサービスであるAuroraとRDSではアプリケーションの変更が不要です。
インスタンスタイプにもよりますが、IntelからGravitonに変更することでインスタンスのコストを約10%削減できました。
一例としてAurora MySQLをt3.mediumからt4g.mediumに変更すると、オンデマンドインスタンスのコストがUSD 0.125/hourからUSD 0.113に下がります。*3
開発環境を利用時間外に停止する
Instance Schedulerを使用してEC2インスタンスとRDSインスタンスの開発環境を夜間停止しています。
2024/3時点では、よりシンプルなEventBridge Schedulerが登場しており、将来的にEventBridge Schedulerに置き換えたいと考えています。
今後の展望
直近はシステムのアーキテクチャを大きく変えずに実行可能な施策が中心でした。
今後も定期的にBillingやCost Explorerをチェックし、削減余地を探り続けます。
弊社は2021年7月にOisixのECサイトのインフラをAWSに移行しましたが、クラウドに最適化されたシステムへのリプレースは道半ばです。
中長期的にはクラウドに最適化されたアーキテクチャへリプレースすることでコスト最適化を目指しています。
おわりに
「これを行えば確実にコストを大幅に削減できる」という銀の弾丸はありません。
コストに対するオーナーシップを持って定期的にコスト状況を確認し、余剰を見つけて削減のための打ち手を考えて実行する、ということを地道に行うことが大切です。
宣伝
最後に宣伝です！
オイシックス・ラ・大地ではエンジニアの方を募集しています。
最近エンジニア採用サイトが公開されました。
興味がある方は、エンジニア採用サイトからお気軽にお問い合わせください。
いきなり選考に応募する前にカジュアル面談という形でお話しすることも可能です。
どうぞよろしくお願いいたします。
engineer-recruit.oisixradaichi.co.jp
