社内でAWSのモブコスト分析会を実施した〜AWSコスト削減 天下一武道会 観戦〜

背景

第1回 AWSコスト削減 天下一武道会 でモブコスト分析というのが紹介されていたので、社内の月1開催のインフラ勉強会(※)の中で実施しました。

※ゆるやか成長スタートアップの小さなEnabling SRE的活動の記事で紹介しています

改めて開催に感謝するとともに、タイトルにネームバリューをもらいつつ敬意を払い観戦としました。（？）

該当スライド部分のリンク

来季にコスト削減を改めてやる必要はあり、ネタ出しにちょうどよいというのもありました。（後回しになっていたIPv4パブリックIP課金対応とか諸々やります…）

結論

（詳細は文末のふりかえりにて）

• やってよかったです。想定通りアーキテクチャ寄りの話に発散し、インフラメンバーではスルーしてしまいがちな部分について議論できました
• 会議体、ファシリテーションは難しさを感じましたが、トライすることが大事

実施内容

1時間枠任意参加でしたが、テーマにそそられたのか全員参加してました。リモートと会議室の併用。

真のコスト削減はインフラ担当者だけではなく、全エンジニアの集合知を結集したときに実現できるとのことで、先日の勉強会のあおりを受けて実施します。（FY24でコスト削減の期間取る予定でもあるのでネタだしも兼ねます）

予定表の前置き（+内容の↓のドキュメントのリンクを張ってます）

• モブコスト分析とは 10min
  • 先述のスライドを紹介
• コスト削減のtips 10min
  • ここに細かい事例のスライドがある https://jawsug-sre.connpass.com/event/270152/presentation/
  • その中でも全体感としてはAWSのスライドが良いので会の中で紹介https://drive.google.com/file/d/1HFDXjkC5OGTYGQXHXdKJK3Tx--j9x-Yo/view
• 社内情報の補足 10min
  • 既存のSP/RIの購入状況
    • （すべて前払いなし。SPは7割くらい、RIはメインのDBのみで割と工夫の余地はある）
  • AWSアカウントの全体感
• モブコスト分析 30min
  • 発言を促すために全員から意気込みをもらう
  • ワイガヤ感で行きたいので、ドライバーを誰かに渡す
  • メモ役を誰か一人作る
  • 心得
    • でかいコストから中心に見ていく
    • SP RIの活用の余地を探す
    • 夜間停止できないか考える

会のアンケートは別途Googleフォームで回答をもらいました

実施結果

他メンバーの意気込み紹介

※インフラ担当は自分が主で、それに加えもともと担当していたマネージャーの2人です
マネージャーはそこそこコスト削減施策やってきましたが、自分はあまりやってないので分かってるようで分かってなかったりする。

ソリューションアーキテクトアソシエイトを持ってる人もいつつ、勤続年数に伴うドメイン知識の理解度も含めレベルはまちまち。

• コスト削減のきっかけを掴みたい
• （会社としてもエンジニアとしても）売上を上げるよりコストを下げるほうが簡単だと思うので取り組みたい
• やりつくした感ある（担当していたマネージャーより）
• コストの感覚を身に着けたい
• 大切な取り組み（CTOより）
• コストの観点からシステムを見るとなにか分かるかも

出た内容

会の中では大きいコストから見ていくということで、AWSアカウント毎で一番コストが掛かっているメインのシステムがあるアカウントにフォーカスが行き、そのアカウントの中でも、DynamoDB、RDSについて掘り下げました。

• RI / SP
  • 最近は資金に余裕があるので一括前払いも可能。割引率を整理したうえで検討したい。（CTOより）
• DynamoDB
  • ストレージのコストが大きい。読み込みはかなり少ない
    • IoTデータの保持期間(1年)がコストに影響しそう
    • 保持期間を超えたものはメインのシステムでは参照できなくなりデータ基盤から集計値を参照することになる
    • 1年から短くすることはできないか
    • メインシステムから必要なときにデータ基盤から読み込むことはできないか
• RDS
  • AuroraではなくをRDSを使う選択肢はあるか
  • データを削減する余地を探す
    • （Aurora:StorageIOUsageを保存容量と勘違いしミスリードしてしまった）
  • DBインスタンスを結合しても良さそう
  • ステージング環境の起動時間を見直す
  • ステージング環境のデータ量を見直す

参加メンバーからのコメント（抜粋）

• 発言しやすい内容で良かった
  • （逆に今までの勉強会は発言しにくい内容だったのでこれは反省）
• AWSのコスト確認の仕方が分かったので勉強になりました
  新機能のリリース等で以前はベストプラクティスでも現在は違ってくる等あると思うので、定期的にリソースの見直しはするべきだと感じました。
  特に固定費の削減は早いタイミングであるほど有効なので、今後も意識して行こうと思います
• 現在のコストを知った。これが高いのか安いのか分からない。どんなときにコストが増減するか気になります
• システム構成見直しも含めた議論になるとなお良かったと思います
• 事前にインフラメンバーで準備してからやるのもありだったのではないでしょうか

※各コメントは社内でコメント返しをしています

アンケート結果

難易度は2,3がボリュームゾーンならちょうどよいのだろうか。。
社内のアンケートなので次回参加の温度感は参考指標です。

ふりかえり

• 勉強会に参加し熱量が高い状態で、するっと開催したのは良い。
  • 限られた時間の中でどういう時間配分 & 内容でやるかは改善の余地がありそう。
  • コスト意識をインフラメンバーが手放し、全メンバーで意識を持ってもらうという観点では今回の開催がベストな気がする
  • 消化不良感はあるので次回開催をどういう形でやるかというのは悩みどころだけど、前半パートなくなるし、同じ形でもう1回やれば良いような気もする。最終的には出た案を自分が精査していったりするので案出しはなるべく巻き込んでやりたい。
    • そもそも全メンバーを任意でも集めてどれくらいの時間をかけてやるのかというのは悩ましい
• ドライバーとメモを別の人に渡したのは良かった。意気込みを開始前に発言してもらったことで全員でワイガヤ感出しながらやれた気がする。
  • リモート（自分含む何人か）と会議室（ドライバー含むなんにんか）だったけど、いい感じだった。多分ナビゲーターとドライバーのどちらかはリモート側にいないとリモートがおいていかれる気がする
  • スキル、ドメイン知識がバラバラなこともありアーキテクチャの話になりやすく、趣旨通りの議論ができた
• Aurora:StorageIOUsageを保存容量と勘違いしミスリードしてしまったのは反省。項目を確認するところまでモブでやるか、ある程度回答できる状態でやるかどちらかが良いかも。
• ナビゲーターのスキルにテンポ感が依存するところがあるので悩ましいところ
  • ドメイン知識の部分も参加者の中でまちまちなところで補足しながらやったりする難しさもある
  • どの項目をどこまで掘り下げるか。アカウント単位>サービスにするか逆にするか。途中で入れ替えるのか。
  • 全体コストの3-5割見るというのが仮目標とするとそれに合わせて配分するのもありかも。改めて確認したら今回見た内容で3割は満たせていた模様
  • 理解を深めるという意味でははじめからメインシステムのみに絞るのも手かもしれないが、サブシステム作ってるメンバーもいるので悩ましさはある。