年末だし大掃除しよう！AWSコスト削減術ご紹介

こんにちは！@_a0iです！この記事はスタディサプリProduct Team Advent Calendar 2024　9日目の記事です！

スタディサプリProduct Team - Qiita Advent Calendar 2024 - Qiita

年末といえば大掃除、大掃除といえばコスト削減！ということで私たちスタディサプリ小中高のSRE主導で行ったAWSコスト削減術を6つご紹介します。

コスト削減術① 付与可能な全てのリソースにタグをつける

AWSのコスト削減に大いに役立つツールの1つが「Cost Explorer」です。しかし、Cost Explorerを活用しようとしても、リソースの属性が不明確で分析が進まないことが多々ありました。

AWSを利用している人数が少なければそこまで困らないと思いますが、ある程度の規模の人数やチームが利用し始めると途端に「誰が何をどれくらい使っているかわからない」ということが発生します。

そこで役立つのが「タグ」です。AWSリソースにメタデータを付与するための「タグ」機能は、コスト管理にも活用できます。タグをコスト配分タグとして有効化すれば、Cost Explorerでフィルタリングやグルーピングに利用できるようになります。

私たちSREチームはコストの全体像を把握していますが、各チームが「何の目的で」どのサービスをどの程度利用しているのか、詳細までは把握できていません。

そのため、利用料が適切かどうか・コスト削減の余地があるかどうかは各開発チームに相談することになります。

そこで「Owner」タグを各開発チームのリソースに付与することで、コストの異常検知の問い合わせ先やコスト削減の相談先を探しやすくしました。

ではどうやって全てのリソースにタグを付与したのか？

「タグを付与した方が良いのはわかっているが、タグがついていないリソースが多くてつけられない...」私もそう思っていました。

この課題をどのように解決したのか、実現方法をご紹介します。

残念ながら、気合いと仲間の協力で実現しました。身もふたもない回答ですみません。

とはいえUIを利用して手動で...というわけではなく、私たちはTerraformを利用してリソースを管理していることもあり、以下のようにdefault_tagsを利用しました。

provider "aws" {
  default_tags {
    tags = {
      Product     = local.product
      Environment = local.environment
      Service     = local.service
      Owner       = local.owner
    }
  }
}

Terraform AWS Providerのdefault_tagsは、v4までは直感的でない挙動が多く、タグ付与の妨げとなることがありました。しかし、2023年にリリースされたTerraform AWS Provider v5での機能強化により、default_tagsが大幅に使いやすくなりました。これにより、Terraformでインフラストラクチャを管理している場合、コスト分析のためのタグ付与が以前よりも容易になったと言えるでしょう。

私たちは各マイクロサービスと環境ごとに専用のworking directoryを作成し、それぞれにAWSプロバイダーを定義しています。この構造により、各working directoryでOwner、サービス、および環境が一意に定まるため、 default_tagsを使うことで効率よくタグをつけることに成功しました。

また、PRの作成や更新を契機にTerraformのplan結果をConftestでチェックし、AWSリソースにOwnerタグとServiceタグが付いているかをチェックしています。これにより、Ownerタグが付いていない状態でリソースの追加や変更を試みると、CIが失敗するため、タグの付け忘れを防ぐことができます。

コスト削減術②　S3 Intelligent Tieringの有効活用

S3 Intelligent-Tiering は、データのアクセスパターンが変化したときに、パフォーマンスへの影響や運用上のオーバーヘッドを発生させることなく、ストレージコストを自動的に削減できる唯一のクラウドストレージクラスです。（中略）S3 Intelligent-Tiering は、オブジェクトのサイズまたは保持期間にかかわらず、不明な、変化する、または予測できないアクセスパターンがあるデータのための理想的なストレージクラスです。（AWS公式ドキュメントより

スタディサプリ小中高のS3事情も、一般的なアプリケーションと同様に、すべてのObjectが同じ頻度で参照されるわけではありません。Objectへのアクセス頻度はObjectの属性によって異なります。これまで、適切なストレージクラスを選択すればコスト削減が可能であると理解はしていました。しかし、Objectへのアクセス頻度が違うという特性がある都合上、分析やストレージクラスの変更には手間をとれず、これまではS3のストレージクラスとしてStandardしか利用していませんでした。S3 Intelligent-Tieringでは各Objectの分析の手間を0にできると聞き、昨年末から年始にかけて導入してみました。

その結果、私たちの環境では、S3 Intelligent-Tieringの追加コストであるモニタリング費を含めても、S3のストレージ容量にかかる費用をおよそ半額に抑えることができました。

コスト削減術③ Karpenter + Spot Instanceの導入でEC2インスタンス料金を削減

Spot Instanceは非常に安価な一方で、突然インスタンスが中断されるリスクがあります。私たちのアプリケーションの多くはAmazon EKS上で稼働していますが、ノードのスケーリングを担うKarpenterを活用することで、Spot Instanceを動的に選択し、効率的に起動しています。そのおかげでEC2インスタンスが非常に安くすんでいます。ただインスタンスシャットダウン時に問題が起きないようアプリケーション側でGraceful Shutdownを正しく実装できていることなど、お使いの環境によって適正はあるので注意してください。

詳しくは以下のブログをご覧ください！

blog.studysapuri.jp