こんにちは。スタディプラス SREグループの水口です。
この記事では当社が2023年上半期にAWSコストを削減した取り組みを紹介します。
2022年から円安が続いており、当社のAWSコストにも大きな影響を与えています。この課題は優先順位の高いものとして認識されていました。断続的な改善を続けており、特に2023年3月から6月にかけて、より重点的に取り組みました。その結果、前年度と同様の利用状況の月と比較してAWSコストを約3割削減できました。
また、為替レートの差を考慮しなくても大幅なAWSコストの削減に成功しています。2022年1月には米ドル対円相場が110円台であったことを思い出すと、当時の為替レートは夢のようなものだったと感じますね。
この記事では2023年上半期のコスト最適化策に焦点を絞って紹介します。
- 基本方針
- Aurora I/O-Optimized
- マシンリソースの効率的な利用
- CloudFront Security Saving Bundleの導入
- S3バケット・オブジェクトの整理
- EKSで利用しているApplication Load Balancerの集約
- Amazon CloudWatch + Datadog
- パフォーマンスチューニングや不要な機能の削除
- AWSコスト削減施策を行ってきた感想と今後について
基本方針
費用対効果の高いリソースに優先的に手を入れる
AWSコストを効果的に改善するために、費用対効果の高い領域に重点的に取り組むことを意識しました。具体的には、AWS Cost Explorerを活用して月次のコストを振り返り、支配的な要因を把握するよう心がけています。変化がある場合には原因を特定して対策を講じます。
サービスの信頼性を損なわない
コスト削減は重要ですが、サービスの信頼性を損なわないような対策を重視しています。例えば、EC2やRDSのインスタンスサイズを極端に削減するなど、サービスの信頼性を脅かすような変更は避けています。
Aurora I/O-Optimized
2023年5月にAurora I/O-Optimizedという新しいストレージ構成がリリースされました。この新構成ではインスタンス料金とストレージ料金は増加しますが、一方でストレージのI/Oに対する費用が発生しません。*1
I/Oに対する課金が懸念されていた当社にとって、この新機能は望んでいたものであり、大幅なコスト削減が期待できると判断し、すぐに検証を行い設定を導入しました。
スタディプラスは通常、4月から8月にかけてリクエスト数が増加する傾向にあります。6月上旬に設定を有効化した結果、RDS料金は5月よりも低くなりました。例年通り6月は5月よりも多くのリクエストが発生していたこともあり、コスト削減の効果が得られたと判断しています。
マシンリソースの効率的な利用
EC2コスト削減の成果
EC2コスト削減においても大きな成果を上げることができました。後述しますが、スポットインスタンス導入の結果、Saving Plansが断続的に余るタイミングが出てきたので、今年のSaving Plans更新時に再計算をしてこの対応は区切りを迎えそうです。
EKS Nodeにスポットインスタンスを利用する
当社では古くからあるサービスをEC2からEKSに移行し、新しいサービスも既存のEKSクラスターにデプロイしています。
中断耐性がない処理を行うコンテナには使えませんが、中断を許容できるPodについては配置先Nodeをスポットインスタンスにすることで大幅なコスト削減が実現できました。
EC2スポットインスタンスは公式サイトによると オンデマンドインスタンスに比べ最大90%低い価格で購入 できるとされており、今回のEC2コスト削減において重要な要素となっています。スポットリクエストのページから確認したところ、当社の場合は少なくとも65%以上のコストを削減できていました。
スポットインスタンスの利用に適しているサービスの性質については、AWS re:Postにも詳細が記載されています。
EKS Nodeのリソースの効率化
EKS Nodeのリソースを効率的に利用してNode数(= EC2インスタンス数)を減らすため、以下のような取り組みを行いました。
EKSで利用しているログルーターの変更
本番環境ではEC2を利用していた時代からログルーティングにはFluentdを使用していましたが、EKSへの移行後はリソース効率の低さに悩まされていました。そこでリソース効率を向上させるため、より軽量で効率の良いFluent Bitへ移行しました。
移行の結果は期待通りであり、EKSの本番環境においてNode数を減らすことに成功しました。
Pod配置戦略とNodeのEC2インスタンスファミリーの最適化
EKSクラスタのNode数を削減するための取り組みとして、PodのリソースとNodeのインスタンスサイズの最適化を行いました。さらにNodeのEC2インスタンスファミリーをより最新のものに変更することで、マシンリソースの効率化しました。
バッチ処理基盤をEC2からEKSに載せ替える
バックグラウンドで実行するバッチ処理基盤用(Sidekiq)において、エンキューが最も多い時間帯を基準にした台数のEC2が稼働していました。このため、利用者が少ない時間帯にはマシンリソースが大量に余ってしまうという課題が生じていました。
そこで、SidekiqをEKSに載せ替え、KEDAを利用してSidekiqのキューの状況を参照してSidekiqのPod数をオートスケーリングできるように改善しました。
この変更により、エンキューが少ない時間帯には過剰なPodが配備されなくなり、起動しているEC2の数を減らすことに成功しました。
また、SidekiqのEKS移行に関しては別にブログ記事も書いておりますので、よろしければご覧ください。
CloudFront Security Saving Bundleの導入
CloudFront Security Savings Bundleは、向こう1年間の月の最低使用量を確約することで一定の割引が得られるサービスです。WAFにも割引が適用される点も魅力的です。
2021年にリリースされ、さまざまな企業のテックブログにもその効果が書かれているサービスですが、当社では適用が漏れておりました。サービスが成長してくるとCloudFront料金は馬鹿にならないため、利用しておくべきサービスでした。
導入に際して、過去のCloudFrontの使用状況を元にコミットすべき最低使用量がサジェストされます。結果に違和感がなかったためサジェスト通りの使用量をコミットしました。大学入試シーズンに適用したため直接の比較はできませんが、Cost Explorerのデータから大幅なコスト削減が実現できていることを確認できました。
S3バケット・オブジェクトの整理
会社の10年以上の歴史の中で、使われないにもかかわらず整理されずに残っていたS3バケット・オブジェクトが存在していました。これらのオブジェクトが社内ポリシー上も保存の必要がないことを調査し、削除作業を進めました。また、調査の過程でライフサイクルルールが設定されていないS3バケットも一部見つかりましたので、ライフサイクルルールの整備も行っています。既存のルールについても見直しを予定しています。
調査にあたって、以下2つの機能が有用でしたのでご紹介します。
S3 Storage Lens
オブジェクトストレージの使用状況やアクティビティの傾向をOrganization全体で可視化できる機能です。すべてのS3バケットの使用状況を確認するダッシュボードを作成し、そこから整理すべきS3バケットを特定しました。ストレージクラス分析
S3バケットごとに設定するもので、ストレージへのアクセスパターンを分析し、オブジェクトを適切なストレージクラスに移行するタイミングをサジェストしてくれる機能です。今後もライフサイクルルールの見直しに活用していく予定です。
不要なファイルが蓄積されていたため、これらの施策により想定以上にコストを削減できました。
EKSで利用しているApplication Load Balancerの集約
改善前のEKSクラスタでは1つのIngressに対して1つのApplication Load Balancer(ALB)が作成される状態で、分ける意味がなくてもALBが別に作成され乱立する状況でした。
ALBは起動するだけでも料金が発生してしまいます。そのため、AWS Load Balancer ControllerのIngressGroup機能を利用して、集約できる範囲でALBをまとめるアプローチを取りました。この施策によりコストの削減ができました。
Amazon CloudWatch + Datadog
DatadogではAmazon Web Services Integrationsを用いておりましたが、例えば利用していないリージョンのメトリクスを取得しているなど整備されていない箇所がありました。そこで、明らかに使っていないリージョンやサービスのメトリクスを取得しないようにしました。
Datadogを使用してきた中で手が回りきっていなかった部分でしたが、DatadogのCloudWatchからのメトリクス取得範囲を減らすことで、CloudWatchの料金を50%削減できました。
パフォーマンスチューニングや不要な機能の削除
サーバーグループのメンバーと協力して、DBのパフォーマンス改善に取り組みました。特にリクエスト数が多くなる受験シーズンの直前にパフォーマンスを向上させることができたため、今年の費用削減に期待しています。
改善内容は大まかに分類すると以下の通りです。
- DBパフォーマンス改善 (N+1改善、キャッシュ活用)
- 利用していない不要な機能の削除
- 設計見直し
特にDBパフォーマンス改善に関しては、サーバーグループの青山さんがブログ記事を書いているので、詳細を知りたい方はぜひご覧ください。
AWSコスト削減施策を行ってきた感想と今後について
スタディプラスのAWSコスト削減施策を振り返ると、以下のようなパターンがありました。
- 利用するだけでお得になる機能や料金体系の活用
- 当社で本来不要だったサービスや機能の無効化
- アプリケーション（主にDB周り）のパフォーマンス改善
- インフラの設計変更
基本方針で述べたとおり、AWSコスト削減については、費用対効果が高い施策(1.)から優先的に実施するのが良いと感じます。
普段からやっていてよかったこととしては、月例でAWSコストを振り返る時間を設けていたことです。AuroraのI/O課金に課題があることを認識できていたため、2023年5月にリリースされた「Aurora I/O-Optimized」は渡りに船とばかりに検証して、すぐに導入できました。Cost Explorerを用いたAWSコストの振り返り・分析は今後も続けていきたいです。
また、DBバージョンなどのバージョンアップを普段から行えていたことで新機能を試すことができたため、改善のフットワークの軽さに繋がりました。
当社のインフラは改善の余地が多く残されているため、引き続き改善に取り組んでいく予定です。コスト削減と同時に、パフォーマンス向上や効率的なリソース利用にも注力して、より良いインフラ環境を実現していきます。
【宣伝】 Podcastのご紹介
スタディプラスでは所属エンジニアが出演するStudyplus Engineering Podcastを配信しており、私も定期的にホストを務めております。第18回ではVPoE大石をゲストに当社の採用活動に関するお話をしました。是非聞いてみてください。
*1:以前のAurora Standardでは、I/Oに対して0.24USD/100万リクエストの費用がかかりました。詳細はこちらを参照してください https://aws.amazon.com/jp/rds/aurora/pricing/
