コスト最適化 by オーナーシップ ～俺たちはQuick Winで満足しない～ 日本マイクロソフト シニアクラウドソリューションアーキテクト 真壁 徹

Azureのコスト最適化に関する参考情報、ツールは日々拡充 コスト最適化のクイック リンク - Microsoft Azure Well-Architected Framework | Microsoft Learn FinOps のドキュメント - Microsoft Cost Management | Microsoft Learn コストに関する推奨事項 - Azure Advisor | Microsoft Learn

しかし • 紹介しても、あまり活用されていない印象 • では一般論やツールからいったん離れ、個人的な経験をまとめてみよう • うまくいかないパターン • コスト最適化に効くツボ • 誰が主体的に進めるべきか • 生々しい話で心に火がつけば、何かが起きるかもしれない

お伝えしたいこと  Quick Winの落とし穴  オーナーシップがコスト最適化の肝  コスト最適化を文化にするために

Quick Winの落とし穴

よく見る コスト最適化の流れ 初期 （クラウドでの新規 開発、移行） 購入レート最適化 リソース最適化 • コスト最適化より、性能 や信頼性が重視される • 落ち着くと、コストが課 題になる • 短期で結果を出すため に、予約割引が選択さ れやすい • 不要なリソースの削減や 停止 • よりコストを下げられる サービスや機能への移行 • アーキテクチャの見直し Quick Win!!

しかし Quick Winで満足してしまうことも 初期 （クラウドでの新規 開発、移行） 購入レート最適化 リソース最適化 • コスト最適化より、性能 や信頼性が重視される • 落ち着くと、コストが課 題になる • 短期で結果を出すため に、予約割引が選択さ れやすい • 不要なリソースの削減や 停止 • よりコストを下げられる サービスや機能への移行 • アーキテクチャの見直し ひとまず満足 やらなくても いっか

期待していた流れ（仮想マシンの例） CPU利用率: 10% 8CPU VM 従量課金 ¥40,000/月 CPU利用率: 10% 8CPU VM 1年予約割引後 ¥30,000/月 1年予約 割引 CPU利用率: 40% 2CPU VM 1年予約割引後 ¥7,000/月 サイズ 最適化 ※価格はイメージです

現実 CPU利用率: 10% 8CPU VM 従量課金 ¥40,000/月 CPU利用率: 10% 8CPU VM 1年予約割引後 ¥30,000/月 1年予約 割引 CPU利用率: 40% 2CPU VM 1年予約割引後 ¥7,000/月 サイズ 最適化 ※価格はイメージです • 再起動、再構成したくない • サイズを変えて問題がおき たら誰が責任とるのか？ • 作った人は、もういない ひとまず満足!! チーム縮小 時は流れ

購入レート最適化を初手にすると おきがちな副作用  トラブルの種を放置してしまう  再起動や再構成からの回復など、変化に強い実装の必要性に気づく機会を逸する  パッチ適用やアップデートなど、メンテナンスイベントのたびに問題が起きがち  テクノロジーリフレッシュに追従できない  予約割引を適用した時点で塩漬けムードが漂い、チームは縮小しメンバーは入れ替わる  何をするにも、常に「慣れていないメンバーによるビッグバンアプローチ」  バージョンアップなど定期的に予想されるイベントでもテスト、作業コストがかさむ （クラウド化のコストメリットを吹き飛ばすテスト、作業コストになる事案も）  予約割引が優先事項、縛りになってしまう  クラウドの本質的価値は「使いたいときに、使った分だけ支払えばいい」  「このサービスや機能は、使わなくてもよかった」と後から気づくことも、よくある  予約割引が無駄になるのでリソース最適化をしない、という本末転倒な事案も

ならば順番を入れ替え、継続的にしてみよう 初期 （クラウドでの新規 開発、移行） リソース最適化 • コスト最適化より、性能 や信頼性が重視される • コスト最適化の仕上げ • 予約割引の適用範囲と 購入量の決定、見直し • 不要なリソースの削減や 停止 • よりコストを下げられる サービスや機能への移行 • アーキテクチャの見直し 購入レート最適化

なぜリソース最適化を先に行うか  作ったシステムをよく理解しているチームの維持  鉄は熱いうちに、よくわかっている人が打つ  わかっている人でも場から離れれば、いろいろ忘れる

リソース最適化に効くツボ（経験にもとづく）  なんだかんだでライトサイジングが王道  VMやプラン、インスタンス、ストレージなどの過剰割り当てが無いか把握（Azure Advisorなどを活用）  適したサイズ、SKUへの変更  アプリケーションが無駄な割り当てをしてないかも確認（利用量に対して過剰なheap割り当てなど）  使わないログはためない  「誰かが取っておけって言ってたので」「誰も消していいって言ってないので」くらいの話が、まあまあ多い （「誰か」を探して要否を確認すると「あ、もう取らなくていいよ」と言われたりする）  フェーズに応じたログレベルを設定する （本番で DEBUG LEVEL そりゃ高い）  夜間や週末に開発、検証環境を止める  はじめは開発者から抵抗があるかもしれないが、いずれ慣れる （例外申請プロセスを作っても、あまり申請されないことも）  長く使われていない開発、検証環境は、いさぎよく消す

でも注意: 2回目は、ないかもしれない 初期 （クラウドでの新規 開発、移行） リソース最適化 • コスト最適化より、性能 や信頼性が重視される • コスト最適化の仕上げ • 予約割引の適用範囲と 購入量の決定、見直し • 不要なリソースの削減や 停止 • よりコストを下げられる サービスや機能への移行 • アーキテクチャの見直し 購入レート最適化 大満足!! チーム縮小

初回を大事にする  プロジェクト思考は根強く、簡単には変えられない  ライフサイクル全体をカバーするように技術チームを作るケースも増えてきたが、現在の企業ITにおいて主流とは まだ言えない印象  プロジェクトが終われば人は離れる、を改めて意識する  ならば初回は、コスト最適化までをプロジェクトとする  カットオーバー後にリソースの利用状況を把握し、コスト最適化に取り組むための十分な期間をとる  効果の大きいリソースを優先して最適化する  伸びしろ（削りしろ）がある初回のインパクトは大きい  負荷テストの省力化、自動化など最適化を支えるしくみまで整えられれば、2回目以降ですこぶる効く  「いっこQuick堂 Win」を狙う  カットオーバー直後のQuick Winより、少し遅れてやってくる大きな喜びを

オーナーシップが コスト最適化の肝

以降は、継続的、主体的に技術者が コスト最適化へ関与できる環境、状況を前提にした話です

“Everyone takes ownership” 誰もが所有権(オーナーシップ)を持つ - クラウド リソースの使用と最適化に関す る決定を分散化し、コスト、アップタイム、パフォーマンスを考慮するよう技術チー ムを促します。 FinOps とは - Microsoft Cost Management | Microsoft Learn ※「原則」より抜粋 誰もが -> 技術チームの誰もが ※期待が重い気もしますが

背景: コスト最適化のトレードオフ コスト 最適化 信頼性 セキュリ ティ 運用し やすさ 性能 • 回復力、冗長性が 下がる • 復旧テストと訓練が 不十分になる • 複雑さが上がる • 防御層、要素が減る • 攻撃面が広がる • 分離、独立度が下が る • リソースに余裕がなく 業務量の急増に追 従できない • 長期的な視点で性 能低下に気づき対応 できる人がいなくなる • すべきことをやらなくな る（テスト、改善、ド キュメント整備、教育、 自動化、etc） • 可観測性が下がる • メンテナンスが常に後 手に回る コスト最適化のトレードオフ - Microsoft Azure Well- Architected Framework | Microsoft Learn

トレードオフをふまえ いい塩梅に コスト最適化するには 技術者の力が必要 では、いかに促すか？

事例: LinkedInのAzureコスト最適化を促すしくみ  LinkedInの社内システム”Costwiz”  Azure Advisorが提案するコスト最 適化の推奨事項を、対象リソースの オーナーに通知する  通知しても対応されない場合のエス カレーションや、サンドボックスサブス クリプションのリソースを自動で削除 する機能なども持つ Costwiz: Saving cost for LinkedIn enterprise on Azure

リソースの「実質的なオーナー」を特定する  リソースを減らす、止める、消すため には、リソースの状況を把握し手を 動かせる、「実質的なオーナー」の判 断が要る  実質的なオーナーを特定するのは意 外に難しい  サブスクリプション所有者など「代表者」とは限ら ない（そうではないほうが多い印象）  Costwizはプロビジョニングツールの 操作履歴、タグ、RBAC設定、アク ティビティログなどから、実質的なオー ナーを特定し、推奨事項を送る Costwiz: Saving cost for LinkedIn enterprise on Azure

Costwizの話で大事なところ  「よくできたツール」で終わらせるのは、もったないない事例  もっと大事なことがあります  大事なのは、実質的なオーナーの存在に目を向けたこと  対象リソースについて、技術的な判断ができ、手が動く人  実質的なオーナーを特定し、いかに促すかが重要  自動化するならCostwizのように特定するしくみを作り、直接通知を送る  通知はスルーされる可能性があるため、Costwizでは一定期間放置されると組織上のマネージャにエスカレーションされる （CostwizはLinkedInの組織構造データを参照し、エスカレーションしている）  自動化しないなら、サブスクリプション所有者など代表者が実質的なオーナーを把握していると仮定し、促進 を委任する  代表者に対し、Azure Advisor、Cost Managementなど「気づき、分析する」ためのツールのトレーニングや、促進を持続するしくみ が重要（しくみはITに限らない）

だがしかし

実質的なオーナーの中の 天使と悪魔がせめぎあう 天使  コスト削減への貢献はビジネスパーソンとし て当然  コスト最適化を文化にしていこう  モチベーションが、とかいちいち言うのは野 暮 悪魔  この前コスト1/10にしたのにボーナスすら出 なかったんだよね  コスト減らして得するのも評価されるのも自 分じゃないほかの誰かでしょ  こんなにもわかりやすいビジネスへの貢献が 評価されない環境ってどうなのよ  ま、得する人が頑張って  「リソース削減はリスクが高い」って言っとこ

コスト最適化を 文化にするために

もっと“Recognition”を  Recognition = 価値が正しく評価されること、認知されること  わたしが所属した/している米系企業では、よく使われる言葉  いい日本語が見つからなかったので、そのまま  コスト最適化に貢献した技術者へのRecognitionは、たいてい不十分  当然のこと、と貢献を過小評価しがち  現場の関係と雇用、評価関係の不一致も背景  せめて貢献者のマネージャーをCCに入れた感謝メールくらいは送りたい  定量化できて価値が明確、これほどビジネスに直接的な貢献はほかにあまりない  間接的に貢献者の評価を高める（所属組織や企業が違っても送るべき）  組織全体/横断で伝わる「貢献者表彰」も、影響が大きい  Recognitionがコスト最適化を持続する栄養となり、いずれ文化となる

みんなで考えましょう  では、Recognitionを行うオーナーは 誰でしょうか？  プロジェクトマネージャー？  プロダクトオーナー？  スコアカード/KPIの責任者？  サブスクリプション所有者？  テックリード？  得をした人？  そのほか？

コスト最適化欲が 高まってきましたか？

いい情報、ツールがあります コスト最適化のクイック リンク - Microsoft Azure Well-Architected Framework | Microsoft Learn FinOps のドキュメント - Microsoft Cost Management | Microsoft Learn コストに関する推奨事項 - Azure Advisor | Microsoft Learn

Thank you