モブコスト分析をやってみた感想と、コスト削減施策の振り返り〜SREが考えるコスト管理への取り組み方〜
本ブログには初めて寄稿させていただきます。中島です。
少し前までメディア統括本部 サービスリライアビリティグループ（SRG）で一緒に仕事をさせていただいており、現在はゲーム・エンターテイメント事業部（SGE）をメインとしてSREを行っております。
今日は今年話題になったモブコスト分析会の振り返りと、SREコスト削減への取り組み方をメインにゆるっとしたお話として読んでいただければと思います。
楽しいモブコスト分析会SREとして、できていなかった原因を直視するための分析をしてみるコスト削減におけるブロック要素についてSREが取り組むコスト管理のシンプルな原則「コスト削減と言われても、普段からやっているのですぐ削るところはない」おわりに
楽しいモブコスト分析会
モブコスト分析会とはAWSコスト削減 天下一武道会にて株式会社DELTA様の発表で提唱された概念です（それ以前には聞いたことがなかったように思います）。
端的に言えばみんなでシステムのDashboardを見ながらコストについてああでもないこうでもないと話す会です。
コストに関する作業は気付いたところから個別に行われることが多く、チーム全体での取り組み化するというアプローチには自分も非常に興味を持ち、さっそくいくつかのプロジェクトで実践してみました。
やってみた結果としては、コスト削減への取り組みを通じて参加したメンバーのシステムのアーキテクチャの理解の深堀りなどにもつながり、非常に意味のある取り組みではないかと思いました。会の中では必然的にコストが高くなっている部分に関するビジネス・バックエンド・インフラそれぞれの観点から深堀り議論がなされることになり、いち技術者としても満足度が高いです。
SREとして、できていなかった原因を直視するための分析をしてみる
さて、モブコスト分析会などでコスト削減できていなかった部分を見つけ出して、その解決に取り組むのはある意味とても楽しい作業です。
そこから一歩進み、コスト削減は実際には何が行われているかをこの機にもう少し言語化してみようと思いました。具体的には、
- モブコスト分析会に先立ち、既にやった作業も洗い出してリスト化する
- 既にやった作業とやれていなかった作業をあわせ、以下の分類を行う
- タスクの種類を分類
- アーキテクチャ変更
- オーバープロビジョニング
- 放置リソースの削除
- その他
- タスクができていなかったブロック要素を分析する
- 気づかなかった
- 工数に対する費用対効果が悪い/タスク優先度低い
- 調整が面倒
- etc…
を各所にお願いしてまとめ、どのようなタスクがどのように実行されているか可視化してみました。
複数のプロジェクトの内容を含むため内容を伏せますが、以下のような感じです。
図1) 既にやれていた作業の分析サンプル
図2) やれていなかった作業の分析サンプル
SRGなどグループ全体でこの取り組みを行えているわけではなく、現段階ではあくまで私個人の関わった複数プロジェクトの分析内容ではありますが、
できていることもできていないことも主に
- オーバープロビジョニングの整理
- 放置リソースの整理
が主体であることがわかってきました。
コスト削減におけるブロック要素について
コスト削減に関するブロック要素は要はすぐに着手できていない理由を示すものですが、単に気づいていなかったというものを除けばプロジェクトにより種々ご想像のつく内容があるかと思います。
- 調整が面倒
- 作業難易度・重要度に比して調整だけやたら大変の意
- 検証環境、社内環境などで顕著
- 気軽に落とせるはずだったが、関係者が増えうかつに作業できなくなってしまったり
- 求められるハードルが高い
- 性能面でのバッファ、検証の完璧性など。主にproductionで顕著
- 工数あたりの費用対効果が低い
- 削減の絶対額が低め
- 必要な工数がその時点での確保可能な工数に比して多すぎる等
- タスクの優先度が低く位置づけられてしまう
- プロジェクトで重要視するのは今はそこではないという理由
いずれにせよ、担当者がこれらのブロック要素を単独で突破するのはかなりのパワーが必要であることは想像に難くないでしょう。
だからこそ、トップダウンでコスト削減の号令が出されたときにこそコスト削減プロジェクトは動きがち、と言い換えることもできるかもしれません。
SREが取り組むコスト管理のシンプルな原則
さて、上記の分析をもとにした場合、平時のプロジェクトのコスト管理にはどう取り組めばよいでしょうか？
オーバープロビジョニングや放置リソースが無駄コストの主犯であり、改善する場合でも一度動き始めたものを変更するのは一定のパワーがいるということになれば、至ってシンプルに思えますね。
- オーバープロビジョニングをそもそもしない
改善した作業の多くの部分がオーバープロビジョニングなのであれば、そもそもオーバープロビジョニングの発生を抑制することを強く心がけるべきである、という結論が得られます。
作業が発生しなければ調整もない、あとからやるつもり→だいたいあとからやらない（やれない）、ということもない、工数より削減効果が少ないから費用はそのまま、ということにもならない。。。
コスト削減はまとめてやればよいものではなく、平時からほんの少し追加の労力をかけて適切な作業を積み重ねることで、あとで発生するコスト削減作業自体の発生を抑制することができます。
これはまさに技術的負債みたいなものですね。現代では雑にクラウドを使うと負債という概念ではなく直接キャッシュアウトが発生してしまいますが。
分析の結果上オーバープロビジョニングを取り扱っていますが、初期に専門知識をもって適切なシステム設計を行うことでアーキテクチャ変更が必要になるような構成をつくらない、ということも含まれるかと思います。
加えて、以下の要素でサポートしていくことが必要でしょう。
- 定期的な見直しの取り組み
- 放置リソースに対する対策の基本
- 前提条件の変更にきちんと対処すること
- 仮で使ったスペックをそのままにしない
- システムを引き渡したあとの状況をちゃんと確認する
- コストで殴るという決断をいつまでもそのままにしない
- 見落とし、気付かないことへの対策として、複数人でチェックができればベスト
- コスト適正化に積極的な文化の醸成（チーム＋プロジェクト）
- コストを気にしろと号令が出なくても動けること
- 有識者まかせからの脱却を目指す（見える化、民主化）
- Cost分析ツール（AWSならCostExplorer）の見方を広める
- リソース使用率を常にプロジェクトチームが確認する文化
これら定期的な見直しへの実施・文化の醸成において、モブコスト分析会のような取り組みを定期的に行うことはシンプルな施策でかなりの効果を得られるように思います。
「コスト削減と言われても、普段からやっているのですぐ削るところはない」
上記の分析を行った結果、自分の担当しているプロジェクトでは改めて「コスト削減と言われても、普段からやっているのですぐ削るところはない」を心がけるようになりました。
SREが取り組むべきアクションにはシステムの設計からSLI/SLOなど種々ありますが、SREがいることによって無駄のないコストスリムなシステムを継続して運用する、ということも十分に目標に掲げてよいものでしょう。
平時からコスト管理に関してプロジェクトの評価、チームの評価が得られる文化を醸成していき、胸を張ってSREが貢献していると言える形にしていきたいですね。
おわりに
インフラのコスト削減については往々にして、無駄遣いしていたところほどコストが削れて成果が出たように見えてしまいがちで、そのような発表も多いのは仕方ないところです。
「コスト削減と言われても、普段からやっているのですぐ削るところはない」で運用した結果も、いずれ発表できると嬉しく思います。また、そのような取り組みをまとめた発表会も面白そうですね。
みなさんの組織でコスト削減施策とそのブロック要素を分析したらどのような結果になるでしょうか。それにより、自分たちで効率よく行動していくための指針も変わってくるかと思います。もしもっと詳しいことに興味があれば、こっそり中島またはSRGのメンバーにお声がけください。ぜひ情報交換しましょう。
ここまでお読みいただきありがとうございました。
