サイバーエージェント流クラウドコスト 削減施策「みんなで 金 塊堀太郎」 株式会社サイバーエージェント CTO統括室 黒崎 優太 (@kuro_m 88 ) Japan FinOps Meetup 

ࠇ࡚ ༏ଠ גࣜձࣾαΠόʔΤʔδΣϯτ CTO౷ׅࣨ @kurochan @kuro_m88 גࣜձࣾAbemaTV Business Development Headquarters 

インターネットゼミ / おうちkubernetes • 社内ゼミ制度でデータセンタでネットワーク(AS 63790 )を運 用 • 最近はGo ConferenceのWi-Fi提供も 

「みんなで 金 塊堀太郎」とは 

サイバーエージェントの「あした会議」 • なんでこんな(へんな)名前の施策がうまれたのかの説明から🙇 • サイバーエージェントの未来(あした)に繋がる提案をする会議 • 執 行 役員がチームを組成し、チーム対抗で社 長 が審査をして得点を競う 

2023年の「あした会議」での提案 • 最終的に全社施策として決議された 

2023年の「あした会議」での提案 • (当時の)メディア事業管轄での「 金 塊堀太郎」という施策を全社展開 • 「システムコストを削減しつつ、削減額を技術投資にあてよう」という意図の施策 • 施策名は「マグロ漁船 一 発乗り太郎」と「 金 塊堀太郎」で悩んだらしい • → 「"みんなで" 金 塊堀太郎」としてサイバーエージェントグループ全体に展開 • ポジティブにやるノリを全社展開する • のちに派 生 (?)で「開発 生 産性あげ太郎」などの施策も 生 まれた Slack絵 文 字 

グループ社内での事例を集めてほめる • 役員含めた全体への共有を通して 見 えづらい貢献を賞賛する • さらなる貢献意欲を 高 めてもらい、 自 発的に取り組む雰囲気を醸成 

グループ社内での事例を集めてほめる • 四半期の技術施策共有会での例 

ワードの普及の様 子 

???「 金 塊を埋めて掘り起こせば評価されるの？」 

???「 金 塊を埋めて掘り起こせば評価されるの？」 • さすがにわざとそんなことをする社員はいないが、 純粋な評価制度として 見 ると破綻している🙅 • この施策がなくても各 自 取り組んでもいるし… • ポイントは「 見 えづらい貢献への光当て」「貢献意欲の醸成」 • 厳密な効果測定は本施策の 目 的ではない • 元々XXしていれば…論もあるが、ポジティブに解決する🙌 • ネガティブにやるよりポジティブにやる 方 が楽しく続けられる • 普段なら優先度が下がりがちなものも、全社施策である 大 義名分を 生 かして実 行 してもらう 

削減事例 

コスト削減効果 • 具体的な数字は公表できないものの、 少なくとも2024年の半年で億単位の削減効果💰💰💰 • どんな削減事例があったのか紹介します https://developers.cyberagent.co.jp/blog/archives/ 8 

トップダウンでやれる系 • 契約の 見 直しなど、上流でできるもの • 個別の契約交渉などは触れません🙊 • 各部署の負担なく進められるし全体にインパクトする • インパクトはあるが既にそこそこ取り組まれていることが多い 

利 用 量を確約する • AWSのSaving Plans(SP), Google CloudのCommitted Use Discounts(CUD) など • コンピュートインスタンスやマネージドサービスの利 用 量を 1〜3年程度確約することで割引を得る • 確約期間が 長 かったり、インスタンス種別の縛りがあると割引率が 高 まる • 確約より実際の使 用 量を下回る(ミスコミット)すると差額は請求される • 全体の利 用 量をみてコミットしつつ、 大口 利 用 部署の意向をヒアリングすることで いくらかコミット率をさらに 高 めることは可能(やりすぎ注意🔥) 

いっぺんにコミットしない 3 y 3 y 1 y 3 y 1 y 1 y 3 y 3 y 3 y 3 y 3 y 3 y 3 3 y 3 y まとめ買い 分割買い 20 2 5 20 2 8 20 3 1 20 2 5 20 2 6 20 2 7 20 2 8 20 2 9 20 3 0 20 3 1 20 3 2 まとめ買いすると買い替え周期が 長 いため、利 用 予測のミスや事業計画の起動修正に追従しずらい😱 時期をズラして複数分割して買うことで、 長 期割引のメリットを享受しつつ、意思決定の頻度を増やせる🤗 

All Upfrontは最安か？ • AWSのSP, RIだと期間以外に 支 払い 方 法が3種類ある • No Upfront: 前払いなし (割引率: 低) • Partial Upfront: 一 部(半額)前払い (割引率: 中) • All Upfront: 全額前払い (割引率: 高 ) • 同じ期間コミットするわけだから、全額前払いするのがよさそうだが… 

為替変動リスクに注意⚠ • 為替変動は織り込むのが難しい • 1ドル150円の時に100ドル前払い: 15,000円(+15.3%) • 1ドル130円の時に100ドル前払い: 13,000円(-13.3%) • せっかく全額前払いをしたのに、為替変動によって割引効果が 薄まることも(その逆もあり) • 一 時的な現 金支 出も考慮が必要(キャッシュフロー) • Partial Upfrontの 方 が(上にも下にも)変動リスクを吸収しやすいかも…？ • 為替ヘッジの 手 段を持っている会社なら気にしないかも 近年のドル円為替レート 

ボトムアップでやれる系 • "みんなで" 金 塊堀太郎💪 • トップダウンでやろうにも 見 えないものは多い • 「不要ならば」減らせばいい、削除すればいい • 不要なのかどうかはメトリクス等だけではわからず、事業要件次第なことも多い • 実装 自 体に 手 を 入 れてチューニングが必要なもの • 事業要件 自 体に 手 を 入 れて許容範囲を広げるもの 

FinOps系SaaSを使ってみた事例 • ノードの負荷のメトリクスから最適なインスタンスサイズと 削減コストを提案してくれるSaaS ??? CPU: 30 %, Memory: 25 % ??? CPU: 25 %, Memory: 30 % node 1 ( 8 vCPU/ 1 6 GB) 📣 FinOps系 SaaS: 「 4 vCPU/ 8 GBのインスタンスにするとコストが半分になりますよ！」 📣 node 2 ( 8 vCPU/ 1 6 GB) 

FinOps系SaaSを使ってみた事例 • コンテナクラスタが主流なので、ホストの実使 用 率だけみてもわからない • Pod(コンテナ)のリソースの要求が過剰な場合、割り当て率としては 高 くなってしまう • Podの要求を定義している 人 (アプリ実装者)からするとスパイク等考慮して 余剰を持ちたい→余剰が積み重なってホストが暇になる • 単に減らすのではなくアプリケーションの性能特性に合わせたチューニングが肝要 CPU: 30 %, Memory: 25 % CPU: 25 %, Memory: 30 % node 1 ( 8 vCPU/ 1 6 GB) node 2 ( 8 vCPU/ 1 6 GB) Pod(req: 6 vCPU/ 4 GB) Pod(req: 1 vCPU/ 2 GB) Pod(req: 4 vCPU/ 4 GB) Pod(req: 2 vCPU/ 2 GB) 

実際の事例 • GCS不要データ削除 • ログのリテンション期間の 見 直し • Redis Cluster冗 長 構成 見 直し • RDSバックアップポリシー 見 直し • 古い監査ログのTier変更 • Auto Scalingチューニング • 実装のアルゴリズムチューニング • KinesisのシャードAuto Scaling • QAのテストケース削減 • BigQueryのクエリチューニング • Materialized View削除 • 動画のエンコードパラメータ調整 • 撤退コンポーネントの整理 • アクセスログフォーマット 見 直し • ベアメタルサーバ購 入 👈 • などなど 

ベアメタルサーバ購 入 🤔 • 100 %AWSだったものを プライベートクラウドとのハイブリットに • 単に購 入 というよりは 大 規模な改修 • コンピュートコストとトラフィックコストが 大 幅減 https://www.cyberagent.co.jp/way/list/detail/id= 7 

施策をやってみて 

施策 自 体も表彰 • サイバーエージェントグループのプロジェクトのひとつとして表彰された • エンジニアのコスト削減の取り組みがより広く知られるきっかけに 

The Frugal Architect • Amazon CTOが提唱した法則 • 次は倹約的(Frugal)な設計や実装が賞賛されるような 風 潮にしていきたい https://thefrugalarchitect.com/laws/ 

参考記事 • 「みんなで 金 塊堀太郎」という施策で億単位のコスト削減を達成 & 表彰されました | CyberAgent Developers Blog • https://developers.cyberagent.co.jp/blog/archives/ 47408 / 

おわり