✔️

GCP(GKE)のコスト削減でやった事サマリー

2024/12/14に公開

こんにちは。
GMOメディアで子供向けプログラミング教室の紹介サイト「コエテコ」の開発を担当しているエンジニアです。

https://coeteco.jp

現在、コエテコはGCP(GKE)上でRailsを用いて稼働しています。

3Q(10月~12月末)のシステムに関する課題として、コスト削減を掲げ、もう一人のエンジニアと共に取り組んでいます。また、途中からチームに加わったインターンの方も一緒に作業に参加してくれています。

サービス開発を進める中で、インフラコスト削減に向けて取り組んだ具体的な事例をいくつかピックアップしてご紹介させていただければと思います!

よろしくお願いします!


各リソース毎の利用金額を確認

まず、そもそも何に一番コストが掛かってしまっているのかを確認します。
GCPではCloudBillingレポートでそのあたり詳しく見れます。
(下記は公式ドキュメントから借りた画像です)

SKU別で見たりすると分かりやすい。

ComputeEngine利用料の削減

↓のコストが目についたので削減します。

Compute Engineと記載されていますが、これはGKEのノード利用料です(参考ドキュメント

SKU番号やSKU名でググると色々情報が得られます。

SKU名
E2 Instance Core running in Japan
SKU-ID
EAED-8A05-843B

検索すると下記のような情報がヒットします。

コエテコではメモリを増やしたカスタムマシンタイプでノードを立てています。
GEKはスタンダードモードでの運用です。

つまり、稼働しているノード数を抑えられればコストも下げられます。
ノードプールの設定や状態を見てみると、スケール台数のmaxが12で稼働台数が概ね11前後で推移。結構ギリギリです。

考えたアプローチとしてはざっくりと3つ。

  1. podが実際に消費しているリソース量を見ながらリクエスト値を調整して、効率的にノードを利用出来るように調整する
  2. アプリケーションのコードを効率化してリソース消費量や処理の時間を短くする
  3. 不要なバッチや常駐のデプロイメントなどを削除する

現状のコエテコは不要だと思われるバッチなどがちらほらとあったり、テスト環境を動かしているpodが常駐するような仕組みになっていたりして、上記3つ目が一番サクッとコストを落とせるかなと判断し、これを実施しました。

まずはクーロンジョブを整理して、不要なものをすべて削除しました。
次に24時間、土日も稼働しているテスト環境のpodを必要な時にだけ起動するよう対応を入れました。

通常時はテスト環境podのデプロイメントのreplicaseを0で設定しておき、GitHubActionsから1に設定出来るようにしておき、日付が変わる段階でバッチによってまたreplicaseが0に戻されるというやり方です。もう一人のエンジニアが爆速でスクリプト組んでくれました。

アクセスをフックにしてテスト環境が立ち上がるとか、CloudRunでホストするようにするとか色々考えましたが、とりあえず上記が一番パッと実装できそうだったのでこれを採用しました。

上記の変更でノードの起動数が7前後に落ち着くようになりました。
これでComputeEngineの費用も下がります!

リクエスト値の調整までやりたかったのですが、こちらはまだ未実施です。
CloudMonitoringなどでダッシュボードを作りつつスパイクなども考慮しつつ実直に調整していく予定です。

ログルーターの書き込みコストを減らす

次に気になったのが下記です。これを減らします。

こちらもSKU名やIDで検索すると色々情報が出てきます。

SKU名
Log Storage cost
SKU-ID
143F-A1B0-E0BE

名前的にはログの容量に対する課金のように感じますが、こちらログルーターが_Defaultというバケットにログをシンク(≒書き込む)際のコストです。

ログエントリに対する諸々の仕組みとしはこちらに分かりやすくまとまっています。

料金を見てみるとこれが結構高い。
https://cloud.google.com/stackdriver/pricing?hl=ja#logs-pricing-summary

従量課金は$0.50/GiBでプロジェクトごとに最初の50GiBが無料のライン。
コエテコでは月の初めの方に割とすぐ無料枠を使い切っており、その後コストが積み上がっていました。

出来る対応としては、書き込まれるログを絞るというアプローチ。

課金対象はGCPがデフォルトのログストレージとして用意している_Defaultバケットへのシンク。下記画像のシンク設定です。

これのフィルタや除外フィルタを調整して不要な書き込みを減らして行きます。
以下のようなマトリクスエクスプローラーを組めばどんなリソースのログ書き込みが多いか特定したり出来ます!

このコスト結構高く、コエテコテスト環境の場合はE2インスタンス利用料よりも高額でした。

除外はしたくないけどシンク量は抑えたいみたいなケースではサンプル関数を設定して割合でシンクさせる事も可能です。コエテコでは本番環境でこの関数を利用しています。

ArtifactRegistryの転送量の削減

次に気になったのはこれ

これもSKU名やSKU-IDでググると色々情報が得られます。

SKU名
Artifact Registry Network Internet Egress AsiaPacfic to AsiaPacfic
SKU-ID
2CB3-644D-F192

上記のSKUはGoogleCloudの外側で発生するトラフィックに対する課金です。
https://cloud.google.com/artifact-registry/pricing?hl=ja

この場合はプレミアムティアのインターネットデータ転送としてコストが計算されます。
https://cloud.google.com/vpc/network-pricing#internet_egress

CI/CDやローカルPCからのイメージのプル、プッシュなどがこれに該当します。
デプロイプロセスに無駄があったりするとこちらの料金が上がります。

デプロイプロセスの改善やイメージサイズの削減をおこなった所こちらが改善されました。
このあたりインターンの方がまるっと綺麗にしてくれました。

また、ArtifactRegistryは転送量だけではなくデータ容量も課金対象です。
それが下記SKUになります。

クリーンナップポリシーを設定するとここの削減に繋がります。
https://cloud.google.com/artifact-registry/docs/repositories/cleanup-policy?hl=ja#create

その他

CloudStorageのコスト削減

ストレージクラスをアクセス頻度などに応じて最適化しました。
また、バケットに応じたライフサイクルの設定も行いました。
https://cloud.google.com/storage/docs/lifecycle?hl=ja

停止サービスの省力化

もし、運用停止中のサービスがあればしっかりとサーバーを止めます。
少し寂しい気持ちになりますが思い切って止めましょう。

いつの日かの為にDBのバックアップは忘れずに!
https://cloud.google.com/sql/docs/mysql/backup-recovery/backups?hl=ja

まとめ

効果

しっかりと減りました!!
現時点では概ね30パーセント減程になっています。

  • 本番環境のコスト推移

  • テスト環境のコスト推移

※ コエテコでは他にも色々GCPのプロジェクト持っていますが割愛します

今後の展望

  • 確約利用割引を利用する
  • CDN利用料を下げる

雑感

削減すればするほどより細かいところが気になってきますね。
サービス規模(pvやuu)あたりのコストを他サービスと比較みたら良い気づきが得られるかもしれない。

GMOメディアテックブログ

Discussion