Google Cloud コスト削減振り返り (2023年〜2024年)

:::note warn
この記事は、[Supershipグループ Advent Calendar 2024](https://qiita.com/advent-calendar/2024/supership)の 9日目の記事になります。
:::

# はじめに
Supershipで広告配信データ基盤関連の開発をしている @yu-imamura です。

2023年1月にかけて当データ基盤はオンプレミスからGoogle Cloud (GCP)へ移行しました。
移行後に実施したコスト最適化の施策と効果を振り返りたいと思います。

# 背景
[広告配信データ基盤をクラウド移行した話][1] に記した通り、広告配信データ基盤はLift and Shift戦略でGCP移行をしました。
Lift (基盤移行) が完了し、現在は Shift (クラウド最適化) をするための道半ばです。

Lift 直後は移行前のオンプレミス設計を踏襲しているものが残っており、ワークロード設計がクラウドに最適化されていませんでした。
Hadoop系資産が持ち越されており _Dataprocを主軸にしたデータ基盤_ となっているのが現状です。

以下のコストが比重として大きく、最適化を進める必要がありました。

- Compute Engine: Hive, Sparkワークロードの計算コスト
- Cloud Storage: Hiveテーブルのストレージ

図は直近8月のサービス別コストです。
Compute EngineとCloud Storageが大半を占めているのがわかります。

![スクリーンショット 2024-12-06 22.11.38.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/608815/ff6bcd34-4e67-309d-99c9-b089ae2f91f0.png)


# コスト削減効果
移行直後の2023年1月のコストから継続的にコスト削減施策を実行した結果、2024年8月時点では以下のような削減効果になりました。

**2024年8月コスト / 2023年1月コスト = 60%**

つまり40%のコスト削減に成功しました。

![スクリーンショット 2024-12-06 23.08.57.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/608815/29a18cf1-76b0-953b-35e5-17257112e728.png)

# 効果のあった施策
実施したコスト削減施策の中でも特に効果の高かった施策を何点か紹介します。

## できるだけBigQuery化
当チームのETLパイプラインはクエリベースです。
身も蓋もないですが、これらのクエリベースのHiveジョブを **BigQueryに移植するだけ** で効率が大きく改善する傾向があります。

以下のような移行の障壁はもちろんあります。

- Hiveテーブルと互換するBigQueryテーブルを用意してETLの入力にする
- Hive UDFをBigQuery UDFなどにリプレースする

しかし、我々の基盤においてはやる価値があると判断してShift戦略に採用しています。

既にBigQuery化が進んでいる部分としてDataprocクラスタを常設し、Prestoを使ったクエリのユースケースの一部はBigQuery移行が完了しています。
これにより既存のDataprocクラスタのコストを削減することに成功し、 **6%のコスト削減** に貢献しました。

## Dataprocクラスタサイズ調整
Dataprocクラスタのワーカーノードは2種類あります。

- プライマリワーカー: オンデマンド価格で購入されるGCEインスタンス
- セカンダリワーカー: 低価格で購入できるがGoogleのキャパシティに応じて強制的に停止されるGCEインスタンス [参考][2]

一般的にプライマリワーカーとセカンダリワーカーの比率は **50:50** が推奨されます。

![スクリーンショット 2024-12-06 23.10.59.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/608815/8e15fb5f-bcce-7228-f1f1-0e865ca3a8f8.png)

しかし、当チームではかなりセカンダリーワーカーの比率をかなり高めに設定しています。

プライマリワーカーとセカンダリワーカーの比率は **20:80** くらいを目安に運用しています。
Google側の都合で停止される可能性が上がるためジョブの失敗確率は上がることがあります。

![スクリーンショット 2024-12-06 23.11.08.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/608815/daea38a6-8fbb-1540-0e4d-118c622ea33f.png)

**安定性とコストを天秤にかけてコストを取る** 判断をしています。
ジョブがたまに失敗してもComposerから自動で再実行をスケジューリングするため運用上の負担は軽減されています。

今回のコスト削減の多くはこのワーカー比率やmachine-typeの調整を重ねることで実現しました。

# 日々の取り組み
一回限りのコスト削減施策であれば開発者個人でも達成はできます。
しかし継続的にコスト削減を実施していくためには仕組みや習慣なくしては実現できません。

以下のようなアプローチを減ることが継続的改善につながりました。

- 組織的に取り組む
- ワークロードの性能特性を理解する

## 組織的に取り組む
コストを意識した組織活動が必須です。
開発者各自の良心だけに依存しているだけでは安定的なコスト削減は実現できません。

- 必ずコスト削減を組織の目標として設定する
- 定例の場で必ず直近30日のコスト変動を追跡する
- 月初には前月のコスト変動要因を説明可能とできるように振り返りを設ける

書いてみると当たり前ではありますが、コスト削減はこうした組織活動を下支えとして結実します。

## ワークロードの性能特性を理解する
コストのダッシュボードをこまめに確認することは、削減のモチベーション獲得や効果確認のために必要です。
しかし削減の施策そのものはワークロードに対する理解なくしては成立しません。

ワークロードに対する理解を育む洞察は以下のような活動の中で得ることができました。

- メトリクスを採取しリソースの利用効率の無駄を把握する
- 分散データ処理の最適化プラクティスが適用できる箇所を探しつつける
    - 読み込むデータ量をできる限り減らす
    - 分散処理におけるデータの偏りを減らす
    - etc.

# まとめ
これまではLift直後の設計をベースにコスト最適化を進めました。
これによってGoogle Cloudのコストは60%にまで削減することができました。
「 _もうさすがにコスト削減の手札はすべて切った_ 」と思ってもワークロードへの洞察が進むこととで新たな改善のきっかけを得ることも度々ありました。

今後はより大幅なコスト削減を目指してBigQuery移行を推進します。

:::note
**最後に宣伝です。**

Supershipではプロダクト開発やサービス開発に関わる人を絶賛募集しております。
ご興味がある方は以下リンクよりご確認ください。
[Supership 採用サイト](https://supership.jp/recruit/)
是非ともよろしくお願いします。
:::

[1]: https://qiita.com/yu-imamura/items/a94abb7a611849260a66
[2]: https://cloud.google.com/dataproc/docs/concepts/compute/secondary-vms