Google Cloud の土台
リソース階層と請求
Google Cloud のリソースは組織、フォルダ、プロジェクトの階層に置かれ、上で設定した権限とポリシーは下に引き継がれます。プロジェクトは環境とアプリの単位で分け、請求先アカウントは階層の外から各プロジェクトに紐づけます。
Google Cloud のリソースは、組織、フォルダ、プロジェクトのどこかに属し、組織やフォルダに付けた IAM の権限と組織ポリシーは下のすべてに引き継がれます。料金を払う請求先アカウント (Cloud Billing アカウント) は階層の外にあり、プロジェクトごとに紐づけます。設計の問題で最初に決めるのは、プロジェクトをどの単位で分け、フォルダでどうまとめるかです。
上の層で付けた設定は、下のすべてに届く
これを継承と呼びます。開発フォルダで開発者のグループに Compute Engine の管理者ロールを付ければ、配下の全プロジェクトで VM を管理できます。プロジェクトは別のフォルダへ移せますが、親は常に 1 つです。継承の細かい規則は IAM の基本で扱います。
| 層 | 役割 | 作る条件と上限 |
|---|---|---|
| 組織 | 最上位。組織ポリシーと全社共通の権限を置く | Google Workspace か Cloud Identity のアカウントが必要。1 アカウントに 1 つ |
| フォルダ | 部門や環境ごとにプロジェクトをまとめる | 組織が必要。入れ子は 10 階層、1 つの親の直下に 300 個まで |
| プロジェクト | API の有効化、権限、割り当て、課金の単位 | 組織がなくても作れる |
| リソース | VM、バケット、データベースなどの実体 | 必ずどれかのプロジェクトに属する |
演習で使う個人のアカウントには組織がなく、フォルダも組織ポリシーも使えません。試験は組織がある前提なので、継承の動きは下のシミュレーターで確かめます。
参考: リソース階層 (公式)
プロジェクトは ID、名前、番号で識別される
gcloud やリソースの URL で使うのはプロジェクト ID です。
| 識別子 | 決め方 | 後から変更 | 一意性 |
|---|---|---|---|
| プロジェクト ID | 英小文字、数字、ハイフンで 6〜30 文字 | できない | 世界で一意。削除後も再利用できない |
| プロジェクト名 | 4〜30 文字の表示名 | できる | 重複してよい |
| プロジェクト番号 | 自動で振られる | できない | 一意 |
汎用の ID は埋まっているので、会社名-アプリ名-環境 の形で決めます。
請求先アカウントは階層の外にあり、支払いの権限を分けられる
紐づいたプロジェクトの利用料は、その請求先アカウントに積み上がります。プロジェクトのオーナーでも、請求先アカウントの管理者ロールがなければ支払い方法は変えられません。経理には請求先アカウントのロールだけを、開発者にはプロジェクトのロールだけを付けます。予算とアラートも請求先アカウントに設定し、プロジェクトやラベルで範囲を絞れます。学習用の環境を作るで設定したのがこれです。
プロジェクトはアプリと環境の組み合わせで分ける
本番と開発を 1 つのプロジェクトに置くと、開発者の権限が本番にも効きます。迷ったら「アプリごと、環境ごとに 1 プロジェクト」にし、ポリシーをまとめて付けたい単位でフォルダを作ります。本番フォルダに「外部 IP を持つ VM を禁止する」組織ポリシーを付ければ、本番のプロジェクトが増えても同じ制約がかかります。全社で本番だけを厳しくしたいなら、部門より先に環境でフォルダを切ります。ネットワークやログのように共有するものは専用のプロジェクトに置きます。Shared VPC は VPC の設計で扱います。
ラベルで費用を分け、タグでポリシーを分ける
ラベルはリソースに付けるキーと値の組で、1 つのリソースに 64 個まで付けられます。キーと値は 63 文字以内の英小文字、数字、アンダースコア、ハイフンです。ラベルは請求データに引き継がれるので、team=payments を付ければプロジェクトの中でもチームごとに費用を集計できます。ラベルはポリシーの条件に使えないので、「env=prod のリソースだけにファイアウォールルールを効かせる」ような条件にはタグを使います。
参考: ラベルの概要 (公式)
オンプレミスの設備投資 (CapEx) と違い、Google Cloud は使った分を月ごとに払う運用費 (OpEx) が基本で、部署ごとの費用がプロジェクトとラベルの単位で毎月見えます。試験のセクション 4.2 はこの移行を事業側の視点で問います。
試してみる
学習用の環境を作るで作ったプロジェクトを Cloud Shell から調べ、バケットにラベルを付けます。
PROJECT_ID=$(gcloud config get-value project)
# ID、名前、番号を確認する
gcloud projects describe "$PROJECT_ID"
# 親を表示する。組織がなければプロジェクト自身だけが出る
gcloud projects get-ancestors "$PROJECT_ID"
# 紐づいている請求先アカウントを確認する
gcloud billing projects describe "$PROJECT_ID"
# ラベル付きのバケットを作り、ラベルを書き換える
BUCKET="gs://${PROJECT_ID}-labels"
gcloud storage buckets create "$BUCKET" --location=us-central1 --labels=env=lab,team=study
gcloud storage buckets update "$BUCKET" --update-labels=team=pca
gcloud storage buckets describe "$BUCKET" --format="value(labels)"最後にバケットを削除します。
gcloud storage buckets delete "$BUCKET"試験で問われる判断
自作の例です。実際の試験問題ではありません。
- 「各部門が自分のプロジェクトを管理し、セキュリティチームは全プロジェクトを監査したい」なら、部門ごとのフォルダを作り、セキュリティチームのグループに組織レベルで閲覧系のロールを付けます。プロジェクトごとに付けると漏れが出ます。
- 「本番環境だけ外部 IP を持つ VM を禁止したい」なら、本番フォルダに組織ポリシーを付けます。本番と開発が同じプロジェクトなら、先に分けます。
- 「同じプロジェクト内の費用をチームごとに集計したい」なら、ラベルを付けて請求データで集計します。権限を分けないならプロジェクトの分け直しは過剰です。
- 「経理担当者に請求書を見せたいが、リソースは触らせたくない」なら、請求先アカウントのロールだけを付けます。プロジェクトの閲覧者ロールでは請求書は見られません。