GCPのリソース階層について

はじめに

GCPにはリソース階層というものがあります。
私がしょっぱなで躓いたところです。
前提として階層の関係性と役割を理解していないと、GCPまわりのドキュメントが何も理解できませんでした…。
「最低限この理解があれば先の勉強に進むことができた」レベル感でリソース階層についてまとめてみました。

階層構造の全貌

階層構造を図で表すとこのようになります。

大きい枠組みとして組織ノードがあり、配下にはフォルダがあります。
フォルダではフォルダ自体をまとめることも可能です。
フォルダの配下にはプロジェクトがあり、各リソースはプロジェクトに紐づいている形になります。
下層から見ていくと理解がしやすいかなと思いますので、まずはリソースからまとめていきます。

リソース

リソースとは、GCPでシステムを構築していく際に使用するサービスのことです。
具体的には、サーバを使用したいときに使うGoogle Compute Engine、ストレージを使用したいときに使うGoogle Cloud Storageなどのことです。

このようなGCPサービスのことをリソースと呼びます。
（AWSでもリソースっていいますね'ω'）

リソースは、1つのプロジェクトに属します。

プロジェクト

GCPにて構築するシステムの単位です。
プロジェクトを使用することで、システムごとに管理することが可能です。

具体的な管理内容の例として、以下のものがあります。

• 請求の管理
  ◦プロジェクト単位で請求が発生します。
  ◦発生した費用の請求先アカウントを指定できます。
• ユーザの管理
  ◦プロジェクトごとにオーナーとユーザの作成を行い、管理することが可能です。

プロジェクト自体は以下の形式で管理します。

「名前・プロジェクトID・プロジェクト番号」

• 名前
  ◦任意
• プロジェクトID
  ◦永続的かつ不変なGCP全体で一意
  ◦基本的に自動割り当て
  　　　 ◦ただし自分でも決められる
• プロジェクト番号
  ◦固有
  プロジェクトはフォルダに属します。

フォルダ

部署、部門、チーム、アプリケーションなどの単位でプロジェクトをまとめることが可能です。
複数のフォルダをフォルダをで管理することも可能です。
フォルダを活用するメリットには以下のようなものがあります。

メリット

• チームの管理権限を付与することで各チーム独立して対応・作業が可能
• フォルダ内のリソースはそのフォルダのIAMポリシーを継承

デメリット

• IAMポリシーの継承範囲を見誤るとミスオペの原因に、、、

フォルダは、フォルダもしくは組織ノードに属します。

組織ノード

階層の最上位で、プロジェクトをまとめて管理することが可能です。
リソースの使用状況の確認とポリシーの適用を一元的に行うことができます。
G Siiteドメインがある場合、GCPプロジェクトは自動的に組織ノードに属します。
そうではない場合はGoogle Cloud Identityを使用して作成が可能です。
組織ノードで付与したIAMポリシーは自動ですべてのプロジェクトに継承されますので気を付けましょう！

最後に

階層構造によって管理を行うのは、GCPとAWSの大きく異なる部分かなと思います。
階層構造の理解ありきでGCPは話が進んでいくことがありうるイメージなので、まずは階層の全体像をつかむ必要があると感じました。

※本記事は2023年12月時点の内容です。