クラウドの基礎

コンテナと Kubernetesで扱った Kubernetes は、何もない空間には浮いていません。 その下には必ず、マシン・ネットワーク・課金の主体があります。それがクラウドです。

この章では GCP を題材にしますが、名前が違うだけで考え方はどのクラウドでも同じです。 新人に求められるのは基盤を設計することではなく、自分の権限がなぜ足りないのか、 そのお金がどこから出ているのかを説明できることです。

なぜクラウドなのか

「サーバーを買わなくていい」は結論の半分

よく言われるのは「機材を買わなくていい」「初期費用がかからない」です。 それは事実ですが、本質はそこではありません。

クラウドの本質は、インフラがAPI で操作できるようになったことです。

# サーバーが1台増える。所要時間30秒
gcloud compute instances create worker-01 --machine-type=e2-medium
 
# 消える。所要時間30秒
gcloud compute instances delete worker-01

これがなぜ効くのか。API で作れるということは、次がすべて可能になるということです。

つまりクラウドとは「安いレンタルサーバー」ではなく、 インフラをソフトウェアとして扱えるようにする仕組みです。

作れるということは、消し忘れられるということ

同じ理由で、事故も起きます。

30秒で作れるものは、30秒で忘れられます。 誰も使っていないのに課金され続けるリソースは、どの現場にも必ずあります。 この章の後半で扱うコストの話は、すべてこの裏返しです。

プロジェクト — すべての境界

GCP でリソースを作るときは、必ずどれかのプロジェクトの中に作ります。 プロジェクトは単なるフォルダ分けではなく、3つの境界を同時に持つ単位です。

組織 (example.com)
└── フォルダ (プロダクトA)
    ├── プロジェクト  myapp-dev       ← 開発。壊してよい
    ├── プロジェクト  myapp-staging   ← 本番と同じ構成で検証
    └── プロジェクト  myapp-prod      ← 本番。触れる人を絞る

環境はプロジェクトごと分ける

dev / staging / prod を1つのプロジェクトの中で名前だけ変えて共存させる構成は、 小さく始めるときは楽ですが、実務ではまず採りません。理由は3つです。

1. 権限を分けられない — 開発者に dev の権限を渡すと、prod も触れてしまう
2. コストを分けられない — 請求が混ざり、どの環境が高いのか分からない
3. 事故が波及する — 検証中の設定変更やクォータ超過が本番に届く

プロジェクトを分ければ、この3つが設定ではなく構造として分離されます。

IAM — 誰が、何を、どこで

IAM（Identity and Access Management）は、権限の仕組みです。 覚えることは1つだけで、権限は必ず3点セットで決まります。

プリンシパル（誰が） × ロール（何をしてよいか） × リソース（どこで）

この3つのどれか1つでも欠けたり、ズレていたりすると権限エラーになります。 逆に言えば、権限エラーの原因は必ずこの3つのどれかです。

プリンシパル（誰が）

ロール（何をしてよいか）

roles/editor は「プロジェクト内のほぼ全部を書き換えられる」権限です。 一見便利ですが、これを配るとIAM を分けている意味がなくなります。

リソース（どこで）と継承

IAM は階層で継承されます。上で付けた権限は下にすべて効きます。

組織         ← ここで付けると全プロジェクトに効く（事故ると影響が大きい）
 └ フォルダ
    └ プロジェクト   ← 実務でよく使う粒度
       └ 個別リソース（バケット、Spanner インスタンスなど）  ← 最も絞れる

下で拒否しても、上で許可されていれば通ります。 「バケット単位では付けていないのに読めてしまう」時は、たいてい上位に権限が付いています。

サービスアカウントとは何か

プログラム自身のアカウントです。人間のアカウントとは別物として扱います。

人間のアカウント        サービスアカウント
you@example.com        api@myapp-prod.iam.gserviceaccount.com
  パスワード + MFA         鍵、または実行環境に紐づく身元
  退職したら消える         サービスが動く限り存在する

GKE の Pod や Cloud Run のサービスには、このサービスアカウントが紐づきます。 アプリが Spanner を読めるかどうかは、あなたの権限ではなく、 そのサービスアカウントの権限で決まります。

最小権限

「とりあえず動かすために roles/editor を付ける」は、実務で最も多い妥協です。 そして一度動いてしまうと、誰も権限を削りに戻りません。

正しい順番はこうです。

# 1. まず必要そうな最小のロールだけ付ける
gcloud projects add-iam-policy-binding myapp-dev \
  --member="serviceAccount:api@myapp-dev.iam.gserviceaccount.com" \
  --role="roles/spanner.databaseReader"
 
# 2. 動かす。足りなければエラーメッセージに不足している権限名が出る
#    PERMISSION_DENIED: spanner.databases.write
 
# 3. その権限を含むロールだけを足す

エラーメッセージには足りない権限の正確な名前が書いてあります。 それを読んで足すのが、最短かつ最小の道です。

権限エラーが出た時に見る順番

この節が実務で最も使います。 PERMISSION_DENIED や 403 を見たら、上から順に確認します。

# 0. まず、今どのプロジェクトで、誰として実行しているかを確認する
gcloud config list
gcloud auth list          # ACTIVE の行が今の身元
 
# 1. エラーメッセージから「不足している権限名」を読む
#    例) Permission 'storage.objects.get' denied on resource ...
 
# 2. その身元に、どのロールが付いているかを見る
gcloud projects get-iam-policy myapp-dev \
  --flatten="bindings[].members" \
  --filter="bindings.members:api@myapp-dev.iam.gserviceaccount.com" \
  --format="table(bindings.role)"
 
# 3. アプリの場合、実際に使われている身元を確認する
#    （自分の権限ではなく、サービスアカウントの権限で動いている）
kubectl get serviceaccount api -o yaml       # GKE の場合
gcloud run services describe api --format="value(spec.template.spec.serviceAccountName)"

チェックリストとしてはこうです。

特に6番は見落とされます。IAM の変更は即座に全体へ伝播するとは限らないので、 付与直後に失敗しても1〜2分待ってもう一度試してください。

ここで焦って roles/editor を付けてしまい、そのまま本番に残る—— というのが、権限が過剰になっていく典型的な経路です。

ネットワーク

構成要素

インターネット
     ↓
ロードバランサ（グローバル IP を持つのはここだけ）
     ↓
┌─────────── VPC ───────────────┐
│  サブネット (asia-northeast1)   │
│    GKE ノード / Cloud Run       │
│         ↓ 内部 IP のみ           │
│    Spanner / Cloud SQL          │  ← 外から直接は届かない
└────────────────────────────────┘

なぜ DB にグローバル IP を付けてはいけないか

「開発中に手元から繋ぎたいから」という理由で、 DB にグローバル IP を付けて 0.0.0.0/0 を許可する——これは最も危険な近道です。

理由は「危ないから」では足りません。具体的にはこうなります。

1. 公開した瞬間からスキャンされます。 インターネット上の全 IP は常時スキャンされており、 よく使うポート（5432、3306、6379 など）は数分以内に接続を試されます
2. 守りがパスワード1枚だけになります。 ネットワークの層が消えるので、 パスワードが漏れた、あるいは弱かった時点で終わりです
3. 脆弱性が出た時に即死します。 DB 本体に認証回避の脆弱性が見つかった時、 ネットワークで隔離されていれば猶予がありますが、公開していると猶予がありません
4. 気づけません。 攻撃者は壊すのではなく、静かに読んで出ていきます

正しいやり方は、内部 IP のままにして、経路の方を用意することです。

• アプリからは VPC 内の内部 IP で繋ぐ（そもそも外に出さない）
• 開発者が繋ぐ時は 踏み台・プロキシ・IAP トンネルを経由する
• ファイアウォールは送信元を絞る（0.0.0.0/0 は本番では書かない）

# 手元から Cloud SQL に繋ぐ。グローバル IP を付ける必要はない
cloud-sql-proxy myapp-prod:asia-northeast1:main-db
 
# IAP 経由で踏み台に入る（VM にグローバル IP は不要）
gcloud compute ssh bastion --tunnel-through-iap

コンピュートの選択肢

「マイクロサービスだから全部 GKE」は、判断を放棄した結果です。 選択肢はそれぞれ運用の重さと引き換えに自由度を得るという関係にあります。

判断軸

上から順に問い、最初に「はい」になったところで止まるのが実務的です。

1. 既存クラスタに載せる話か？ → 既に GKE があるなら GKE。運用は既に払っている
2. リクエストに応答するだけか？ → Cloud Run。運用コストが桁で違う
3. Pod 間の細かい制御、サイドカー、Operator、特殊なスケジューリングが要るか？ → GKE
4. OS レベルの制御や、コンテナ化できないものがあるか？ → Compute Engine

マネージドサービスを使うか、自前で立てるか

「Redis なら VM に立てれば安いのでは」——構築だけを見ればその通りです。 コストは構築ではなく、運用に出ます。

金額だけを比べると自前が勝ちます。しかし比べるべきは、 「そのサービスを3年間動かし続けるのに必要な人の時間」を含めた総額です。

判断の目安はこうです。

• その技術が自社の競争力そのものでないなら、マネージドを使う
• 深夜に起きて対応する覚悟が無いなら、マネージドを使う
• 自前にするのは、マネージドでは要件を満たせないと具体的に説明できる時だけ

インフラの費用比較で自前が安く見えるのは、たいてい人件費を数えていないからです。 エンジニアが月に数時間その面倒を見るだけで、多くのマネージドサービスの差額を上回ります。 「安い」と言うときは、何を数えていないのかを確認してください。

コストはどこで出るか

請求書が跳ねるのは、たいてい計算資源そのものではないところです。

見落とされやすい3つ

Egress は特に直感に反します。 リージョンをまたぐ通信、 別プロジェクトへの通信、インターネットへの応答——これらは全部お金です。

同一ゾーン内           → 無料 or ごく安い
リージョン内の別ゾーン   → 少し課金
リージョンをまたぐ      → 課金
インターネットへ出る     → 最も高い（かつ、宛先の地域で単価が違う）

だから「アプリは東京、DB は米国」のような構成は、 遅いだけでなく、通信量に比例して課金され続けます。

存在するだけで課金されるもの

新人がやりがちな高額請求

自分で追えるようにする

# ラベルを付けておくと、請求を分解できる
gcloud compute instances create worker-01 \
  --labels=env=dev,team=backend,service=api

リソースにはラベルを付けます。 付けていないと、請求書を見ても「この2万円は誰のものか」が永久に分かりません。 予算アラートも合わせて設定し、閾値を超えたら気づける状態にしておきます。

本番を壊さないための作法

まず read-only で見る

いきなり変更を打たない。これだけで事故の大半は防げます。

# 見る（安全）
gcloud compute instances list
gcloud run services describe api
kubectl get deployment api -o yaml
 
# 変える（ここからは慎重に）
gcloud compute instances delete worker-01

--dry-run と差分確認

多くのツールには「実行せずに、何が起きるかだけ見る」手段があります。

kubectl apply -f deploy.yaml --dry-run=server   # サーバー側で検証だけする
kubectl diff -f deploy.yaml                     # 今の状態との差分を見る
terraform plan                                  # 適用前に変更内容を確認する

plan や diff の出力を読まずに apply するのは、目をつぶって運転するのと同じです。 「削除される予定のリソース」が混ざっていないかは、必ず確認してください。

環境の取り違えを構造で防ぐ

新人の事故で最も多いのがプロジェクトの切り替え忘れです。 「dev で試すつもりが prod だった」は、注意力では防げません。仕組みで防ぎます。

# 名前付きの設定を環境ごとに作る
gcloud config configurations create dev
gcloud config set project myapp-dev
 
gcloud config configurations create prod
gcloud config set project myapp-prod
 
# 切り替え
gcloud config configurations activate dev
 
# 今どこを向いているかを常に確認
gcloud config list
kubectl config current-context

さらに効くのは次の2つです。

• シェルのプロンプトに現在のプロジェクト / コンテキストを表示する（見えていれば間違えない）
• 危険なコマンドでは --project を明示する（設定に依存させない）

# 設定がどうなっていようと、対象が一意に決まる
gcloud compute instances delete worker-01 --project=myapp-dev

そして本番のプロジェクトに入った時は、最初に打つのを必ず確認系にする。 gcloud config list と gcloud auth list の2つです。

これは儀式ではありません。手が覚えている操作ほど、環境を確認せずに実行してしまうからです。 kubectl delete pod を dev の感覚で prod に打った事故は、どの現場にもあります。

実務の落とし穴まとめ

1. roles/editor で通す — 一度動くと誰も権限を削りに戻らない
2. 人間のアカウントでアプリを動かす — 退職で止まり、監査ログが意味を失う
3. アプリの権限を自分の権限で確かめる — 実際に動くのはサービスアカウント
4. DB にグローバル IP を付ける — 数分でスキャンされ、守りがパスワード1枚になる
5. 0.0.0.0/0 の一時ルール — 一時的なつもりのルールは閉じられない
6. 検証用の GKE クラスタとロードバランサの放置 — 請求が跳ねる代表格
7. 本番で debug ログ — 取り込み料と保存料の両方が効く
8. プロジェクトの切り替え忘れ — 注意力ではなく gcloud config とプロンプト表示で防ぐ

まとめ

• クラウドの本質は安さではなく、インフラを API とコードで扱えること
• プロジェクトは課金・権限・リソースの境界。環境はプロジェクトごと分ける
• IAM は プリンシパル × ロール × リソース。権限エラーの原因は必ずこの3つのどれか
• プログラムはサービスアカウントで動く。人間のアカウントで本番を触らない
• 権限エラーは プロジェクト → 実行者 → 不足権限名 → ロール → 階層 → 反映待ち の順で見る
• 外に出してよいのは原則ロードバランサだけ。DB は内部 IP のまま、経路を用意する
• コンピュートは運用の重さと自由度のトレードオフ。「全部 GKE」は判断ではない
• 自前構築のコストは構築ではなく運用に出る。人の時間を勘定に入れる
• 請求が跳ねるのは Egress・アイドル課金・ログ量。ラベルと予算アラートで追える状態にする
• 本番では read-only で見る → plan / diff を読む → --project を明示する

公式ドキュメント

迷ったら一次情報に戻ってください。

章末問題

次の章では、ここまで見た構成要素をコードとして管理する方法を扱います。 画面をクリックして作ったインフラは、再現も追跡もできません。