AWSのモブコスト分析をやってみた

はじめに

こんにちは、SREチームの植松です。

2月に開催されたAWSコスト削減天下一武道会のLTにて、コスト削減は全員で取り組む必要があり、そのための方法として「モブコスト分析」が重要であると述べられていました。

エムオーテックスでもモブコスト分析をやってみたところ、コスト最適化のアイデアを活発に議論できましたので、実施レポートを共有したいと思います。

はじめに
モブコスト分析とは
モブコスト分析の実施
実施結果
- Lambda
- S3
- DynamoDB
ふりかえり・感想
おわりに

モブコスト分析とは

天下一武道会の発表資料を引用させていただきます。

資料の40Pにある通り、「みんなで請求書やCost and Usage Reports(CUR)のコストデータを眺めながら、最適化できそうなところをディスカッションする」というのがモブコスト分析の大まかな内容です。

Elephant in the room(重大な問題≒コストが高いサービス)と向き合うこと、アーキテクチャ見直しを意識することも重要だと述べられておりまして、これらを意識して分析会を実施しました。

100社のコスト診断から見えてきた、コスト削減の王道とケモノ道 - Speaker Deck

モブコスト分析の実施

参加メンバー集め

社内のチャットやMTG等でモブコスト分析に興味がある人を募集したところ、私を含めて10名集まりました。メンバーの内訳としてはアプリケーションチーム5名、SREチーム5名でした。

分析に使用したデータ

過去記事にもあります通り、CURを有効化しているのでそれをベースに分析会の場で見てもらうためのダッシュボードを準備しました。

LANSCOPE エンドポイントマネージャークラウド版(以下、クラウド版)の本番環境で、大きなコストを占めているS3、Lambda、DynamoDB、API Gatewayなどについて、リソース名(ぼかしています）と使用タイプ別のピボットテーブルを作成しました。

また、CURではAPI Gatewayのコストは分かりますがリソースパス別の利用量まではわかりません。以下のようなクエリをAthenaで実行して、各APIの実行回数を集計した資料も準備しました。

SELECT
  apiid,
  resourcepath,
  count(resourcepath)
FROM
  your_table_name -- ここを適切なテーブル名に変更してください
WHERE
  date BETWEEN date '2024-01-01' -- 日付は適切な範囲に変更してください
  AND date '2024-01-02' -- 日付は適切な範囲に変更してください
GROUP BY
  apiid,
  resourcepath

また、アプリケーションチーム小沼さんに作成いただいた「機能別のコストダッシュボード」も使用しました。

実施内容

60分の枠をとって、ざっくり以下のように会を進めました。

[5分] モブコスト分析についての説明
天下一武道会の発表資料を交えて簡単に説明しました。
[5分] 対応済みのコスト最適化施策について説明
メンバー間の認識ずれをなくして円滑にディスカッションするため、対応済みの施策を説明しました。説明したのは大まかに以下3つです。
・本番環境のインスタンスに割り当たるように、RIは購入済みであること
・Savings Plansも購入していること
・対応済みの最適化施策の内容
スプレッドシートで施策を一元管理しているため、スムーズに共有できました。
[5分] クラウド版のコスト状況の説明
クラウド版の本番環境、開発環境で1月あたりどの程度コストがかかっているかであったり、各環境でコストが高いサービスは何かについて説明しました。
[40分] モブコスト分析
ピボットテーブルやダッシュボードを交えて本番環境でコストが高いサービス、リソースを中心に見ていきました。共同編集可能なテキストにコストが高いリソース一覧を記載し、全員がメモや気になったことを残せるようにしました。
[5分] 感想戦
モブコスト分析をやってみての感想や、2回目3回目の分析会をやってみたいかなどを会話しました。

実施結果

出てきたコスト最適化のアイデアを以下に抜粋します。アプリケーションチームのメンバーが多かったのでアーキテクチャ改修が必要なものが多かったです。

Lambda

コストが高くてGraviton対応がまだのLambda関数があるので、置き換えるだけで月1000$以上最適化できそう。
メモリ割り当てが多い関数があり、見直す余地がありそう。
コストと性能（処理時間）のバランスをとったメモリ割り当てをレコメンドしてくれるAWS Lambda Power Tuningというツールがある。
Lambdaカスタムランタイムでnative-imageを使うことで、コスト最適化できそう

S3

オブジェクトサイズが小さく、かなり頻繁にアクセス(GET、HEAD)されるバケットがある。
このようなバケットは別のサービス(DynamoDBやElastiCache)にすればコスト最適化できそう。
オブジェクトサイズが大きく、頻繁にアクセスされるバケットはCloudFrontに置き換えた方が良さそう。

DynamoDB

ストレージ料金 > アクセス料金のテーブルがあり、低頻度アクセスに変えた方が良さそう。
ピボットテーブルを作っていたおかげで、このようなテーブルを簡単に発見できました。
低頻度アクセスに変更してもなお、ストレージ料金 > アクセス料金のテーブルがある。
テーブルデータをS3にエクスポートしてAthenaでアクセス・・・といったようなアーキテクチャ変更でコスト最適化できそう。
複数のテーブルに分割して保持しているデータがある。
分割テーブル数が多くなってくるとメトリクスやアラームコストも倍増するのでテーブルを統合するか、
先述のS3->Athenaのような構成にすることで最適化できそう。