※このストーリーは、noteで発信した記事を転載しています。

こんにちは！
カンリーのSREで秩序をもたらす活動をしている本間です。荒れ放題だったGoogle Cloudにキツすぎない秩序をもたらしたので、その際にどんな取り組みをしたのかご紹介していきたいと思います。

Google Cloudはデフォルトの権限が比較的緩い設定になっているため、弊社のように気付いたら混沌としていることが多いんじゃないかと思います。同じような状況の方々に少しでも参考になれば幸いです！

目次

1. １．秩序が必要になった理由
2. ２．秩序をもたらすためにやったこと
3. ２−１．不要なプロジェクト/リソースの削除
4. ２−２．必要なリソースをTerraformにimportする
5. ２−３．用途ごとにフォルダ分けし、プロジェクトを移動
6. ３．今後の展望
7. ４．さいごに

１．秩序が必要になった理由

Google Cloudを使って新しくプロジェクトを立ち上げようとした際、プロジェクトリストを見たら「My First Project」や「xxx02」という謎の連番がついたものなど、用途不明プロジェクトが乱立していることに気付いたのがきっかけだったと思います。

その後よくよく他の部分も見ていくと、

• 用途不明な制限ゆるゆるのAPIキー（そして消すと動かなくなるサービスが出てくる）
• 謎に強い権限を持った管理用アカウント
• 「請求先アカウント」というデフォルトの名前の請求先が複数あり、設定されているクレジットカードが微妙に違う

などなど、ツッコミどころ満載で「駄目だこいつ…早く何とかしないと…」と焦りを感じ、このタイミングで整備していくこととなりました。

ちなみに、こんな状況になっていた背景として、まずGoogle Cloudのデフォルト設定で組織（ドメイン）内のユーザーに「プロジェクト作成者」の権限が付与されることを知らなかったことがあげられます。

また、弊社のプロダクトではGoogle Business Profile APIを利用している関係上、立ち上げの早い段階でGoogle Cloudを使う機会があったことも関係しそうです。スピード優先で開発が進められ、検証用として作ったものがそのまま残っていたり、とりあえずで作ったAPIキーがそのまま本番環境に乗ったり、そんな背景もあったと思います。

２．秩序をもたらすためにやったこと

まず目的を明確にし、どこまでをゴールとするか決めました。

……とキレイにスタートできれば良かったのですが、実際はそうはいかず…！
当時のSREチームはこの件にフルコミットできる余裕がなく、Google Cloudに知見のあった業務委託の方にまずは最低限として以下のことを進めていただきました。

• 組織（ドメイン）から「プロジェクト作成者」「請求先アカウント作成者」のIAMロールを削除
• SREのグループ（メーリス）にのみ上記のロールを付与
• Terraformで管理できるようサービスアカウント等を整備し、こちらにも上記のロールを付与

この対応によりこれ以上不要なプロジェクトが作成されなくなり、秩序をもたらす準備が整いました。
ここから一度期間が空いてしまったのですが、改めて動き出した際には「ガバナンスを効かせた上でプロダクト作りを素早く立ち上げられる仕組みを作る」という目標を掲げ、進めていきました。

次に取った対応は、手順含めてもう少し詳細に紹介していきます。

1. 不要なプロジェクト/リソースの削除
2. 必要なリソースをTerraformにimportする
3. 用途ごとにフォルダ分けし、プロジェクトを移動

２−１．不要なプロジェクト/リソースの削除

まずはどんなリソースがどのくらいあるのか把握するところから始めます。リソースの把握にはsearch-all-resourcesコマンドが便利です。

コマンド実行前に、認証情報を取得します（Google Cloud CLIのインストールが必要です）

gcloud auth login

次のコマンドで、リソースリストをcsvで取得します。
--formatオプションでcsvを指定しpbcopyも実行しているので、スプレッドシートを開いてそのままペースト→展開することができます。

gcloud asset search-all-resources \
  --scope=<SCOPE> \
  --order-by='assetType, name' \
  --format="csv(assetType,createTime,displayName,location,name,organization,parentAssetType,parentFullResourceName,project,updateTime)" | pbcopy

<SCOPE>には以下の4つを指定することができます（参考）
（ORGANIZATION_IDを指定するとデータ量が非常に多くなるのでご注意ください）

• projects/<PROJECT_ID>：指定したプロジェクトのリソースを取得
• projects/<PROJECT_NUMBER>：指定したプロジェクトのリソースを取得
• folders/<FOLDER_ID>：指定したフォルダに属するプロジェクトのリソースを取得
• organizations/<ORGANIZATION_ID>：組織に属するすべてのリソースを取得

--queryパラメータを使用して検索結果をフィルタリングしたり、--asset-typesパラメータで特定のリソースタイプに絞り込んだりすることも可能です。

コマンド実行結果をスプレッドシートに展開したイメージは以下です。

弊社ではこのスプレッドシートに要/不要・コード化有無の列を追加し、1件1件精査していきました。

取得されるリソースの中には、プロジェクトを作成した際に自動で作成される_Default/_Requiredバケットや、`sys-`から始まるGASのプロジェクトも抽出されると思います。場合によってはこちらは除外して考えた方がいいかもしれません。

Google Cloudコンソールから見たときにどのリソースにあたるのかを見ながら要/不要を判断したい場合は、[IAM と 管理]から「アセットインベントリ」という機能を使うのがオススメです。プロジェクト内にどんなリソースがあるのか一覧で見ることができ、変更履歴を調べたりもできます。

２−２．必要なリソースをTerraformにimportする

コード化が必要になったリソースを、importブロックとfor_eachでまとめてひたすらimportしていきます。弊社では3,000近いリソースが対象となりました。

特にTipsがないため割愛させていただきますが、ここはひたすら頑張るのみでした…！

２−３．用途ごとにフォルダ分けし、プロジェクトを移動

Google Cloudではプロジェクトをフォルダで分けることができるので、用途や管轄チームにわけて管理することが可能です。また、今回は紹介しませんがフォルダごとに権限を振ることが可能です。

弊社では一旦以下の構成としました。

フォルダの階層をチームやプロダクトでもう1段階掘ることも考えましたが、組織やプロダクトが絶賛拡大中で先が見えづらい中なので、あまり厳密にし過ぎると運用がハードになるだろうということで、今はこのくらいで留めています。

各フォルダの役割は以下の通りです。
Workload：各プロダクトのワークロード用のフォルダ
Security：Audit Logなどを保管するセキュリティ監査用のフォルダ
Management：コスト管理用のプロジェクトなど、マネジメント領域用のフォルダ
Sandbox：検証用のフォルダ

また、前述の通りプロジェクト作成者の権限はSREかTerraform用サービスアカウントに限定しているため、野良プロジェクトは作られなくなり、コード化も促せるので管理がしやすくなっています。

以上の対応が完了したことで、キツすぎない秩序を作ることができました！🎉🎉🎉🎉🎉

何も対応できなかった期間もありつつ、初動から完了まで丸一年はかかっています。特にimportの数が多くて大変でしたが、Google Cloudに対する知見も増えたので取り組んで良かったと思います！

３．今後の展望

今回は大雑把にフォルダを分けてなるべくシンプルな構成に留めました。できることはまだまだありますが、最低限の秩序ができたことで一時の平穏が訪れています。

今後より一層エンジニアが増え、プロダクトが増えていった先には、この秩序だけでは足りないことが予想されます。そうなったら、各チーム毎にさらにフォルダをもう1階層作ったり、そのフォルダの管理者を各チームの管理者に委ねるなどの対応が必要になってくると思います。

また、弊社ではまだまだAWSの利用が大半なので、Google Cloudを使ったワークロードの事例を今後はもっと創出していきたいと考えています。

４．さいごに

今回はGoogle Cloudに秩序をもたせるためにやったことをご紹介しました！
今後もGoogle Cloudを活用し、SREチームのミッションである「イノベーションの加速と信頼されるサービス基盤の提供を両立させる」にコミットしていきたいと思います。

カンリーでは一緒に働く仲間を募集しています。
SREはもちろん、全職種で積極的に募集しております。
気になった方はぜひご連絡ください！