🧹

年末じゃなくてもGoogle Cloud プロジェクトの整理はしよう

sikeda107

2023/12/23に公開

はじめに

commmune Advent Calendar 2023 23日目は、
「年末じゃなくてもGoogle Cloud プロジェクトの整理はしよう」です！

みなさんは Google Cloud プロジェクトに上限数があることはご存知でしょうか？
（無限なわけはないと思いつつも、わたしは考えたこともなかったです）
きちんと整理をしておこないと突然の残りの弾数がすくないことに気づき、大変なことになるかもしれません🤯
Google Cloud プロジェクトの「仕様」と「整理でやったこと」についてご紹介します。

新規プロジェクト作成時の警告画面 ※画像は例です

Google Cloud Project の仕様

背景

先日、あたらしい Firebaseプロジェクトを作成しようとすると、画像のような警告が表示されました。このときは、画面にしたがって「上限の引き上げ」をリクエストすることで１日もたたずに上限の引き上げの承認が Google からおりたのでひとまず問題にはなりませんでした。

とはいえ、これまで気にもとめていなかったのでいくつか不安と疑問がでてきました。

Google Cloud プロジェクトと Firebase プロジェクトってどういうつながりなんだろうか？
上限数ってどうやって確認できるの？
上限の緩和申請って直接 Google でいいの？

疑問を解消するために、ドキュメントを読みつつサポートに問い合わせました。

疑問① Google Cloud プロジェクトと Firebase プロジェクトの関係性

同じものです。
「Firebase プロジェクトと Google Cloud の関係^[1]」にドンピシャで書いてありました。
Firebase プロジェクトを作成すると、Google Cloud プロジェクトが実際には作成され、firebase:enabled というラベルが自動的に付与されます。また、プロジェクトを削除すると両方のプロジェクトが削除されるそうです。
振り返るとドキュメントのとおり権限周りも共有しているので、納得感がありますね。

疑問② 上限数ってどうやって確認できるの？

疑問①で書いたとおり、プロジェクトの上限数は内部的に同じものなので共有されます。「作成できるプロジェクトの数を表示する^[2]」のよると、割り当ての中に残っているプロジェクト数が 30 個未満の場合にプロジェクト作成画面で警告が表示されるようです。

Cloud Monitoring で監視したい！と思ったのですが、現状そういったメトリクスは提供されていないそうです…（残念）
ただ、gcloud コマンドでプロジェクトの一覧は取得できるので、それから数の把握は一応できるようです。以下のコマンド例では、sys ではじまるApps Script プロジェクト^[4]を除いて取得しています。

gcloud projects list | Google Cloud CLI Documentation

e.g.) 
gcloud projects list --format="value(project_id)" | grep -v sys | wc -l

ちなみに、gcloud asset search-all-resources | Google Cloud CLI Documentation を使っても検索できるのでお好みでどうぞ！

疑問③ 上限の緩和申請って直接 Google でいいの？

請求代行サービスを使っている方もいるかと思いますが、その場合も申請先は直接 Google ^[5]になりそうでした。定常的にプロジェクトを作成している組織の場合は早めのうちにサポートや営業担当へ確認依頼を出しておいた方がいいと思います。
ところで、上限緩和申請って実際のところどこまで通るのか？ですが、これは Google 側で利用状況を確認して個別に設定されるとのことでした。そのため、ある組織ではここまで上限設定できるけど、ある組織では上限設定ができないといったことが起こりうるということです。

整理をはじめよう

1. プロジェクトのリストアップ

gcloud コマンドと jq コマンドをつかって csv ファイルとして出力します。後の仕分けのため、私はこれを Notion データベースに連携しました。

gcloud projects list --format=json | \
jq -r '.[] | [.name, .projectId, .projectNumber, .createTime, .labels.firebase, .parent.type, .parent.id] | @csv' \
> project-list.csv

2. プロジェクトの仕分け

以下の観点でプロジェクトの仕分けを行います

請求が発生しているか？
API の利用実績があるか？
プロジェクトはだれが作成したか？

請求が発生しているか？

Cloud Billing の Cost table^[6] を確認していきます。請求が発生しているものは、おそらくちゃんとつかわれているはずなので、一旦除外対象とします。請求はあるが、使っている認識のないプロジェクトがある場合は要チェックかもしれません。

APIの利用実績があるか？

Google Cloud Console の「APIs & Services^[7]」にアクセスして、Cloud API の利用状況を確認します。ここでなにも呼ばれていない場合は、プロジェクトが使われていない可能性が高いです。

プロジェクトはだれが作成したか？

Resource Manager の監査ログ^[8]を使って調べることができます。protoPayload.methodName="CreateProject" をCloud Logging で検索することで作成者のメールアドレスを principal_email として確認することができます。画面は組織レベルで Logs Explorer を使っているところです。

プロジェクトを作成すると、プロジェクトの roles/owner のロールが付与されます。IAM を確認して Onwer を持つ方がいたらその人が作成した可能性が高いです^[9]。今回は簡易的に Shell を作成して一括取得しました。

gcloud projects get-iam-policy | Google Cloud CLI Documentation

#!/bin/bash

PROJECTS=($(gcloud projects list --format="value(project_id)" | grep -v sys))
for PROJECT_ID in "${PROJECTS[@]}"; do
  MEMBER=$(gcloud projects get-iam-policy ${PROJECT_ID} --format=json | jq -r '.bindings[] | select(.role == "roles/owner") | .members | join(",")')
  echo "${PROJECT_ID},${MEMBER}"
done

3. APIの無効化とシャットダウン

プロジェクト作成者にヒアリングしたりしながら、使っていないAPIの無効化とシャットダウンを実施していきます。API はそれぞれの詳細から、「DISABLE API」で無効化することができます。不要な請求発生を防ぐためにも、使わないAPIは無効化しましょう！

4. フォルダを作成する

不要なプロジェクトを削除してスッキリしたあとは、フォルダを作成して整理をしていきます。こうすることで、新たに作成されたプロジェクトと整理済みのプロジェクトを判別しやすくなります。
フォルダのベストプラクティス^[10]はあると思いますが、まずは使っているのか使っていないのかを判別できるように分けておくことから始めるのがいいと思います。
たとえば…

社内向けは、「internal」
サービスは、「product」
開発環境は、「features」

さいごに

最終的に 10個以上のプロジェクトを削減することに成功しました🎉 これで少しは安心できるかなと思います。
本来ならばプロジェクト作成権限などを絞るべきところですが、過去の遺物などが放置されてしまっている可能性もあるので一度見直しをしてみることをおすすめします♫

脚注

コミューン株式会社Publication

コミューン株式会社のメンバーによる技術発信を行います。