インフラをコードで

なぜ Infrastructure as Code が必要なのか

「手動で作ったインフラは”雪の結晶”。二度と同じものは作れない。」 ——Yuki

手動インフラ管理の問題点

クラウドコンソールで手動でリソースを作成・設定する方法には、多くの問題があります。

1. 再現性がない

「前回どういう設定でDB作ったっけ？」
「ネットワーク設定のパラメータ何だったかな...」
「あの時のファイアウォールルール、スクショ撮ってないな...」

2. ドリフト（設定のずれ）

本番環境: DB のメモリ = 8GB（誰かがコンソールで変更）
ステージング環境: DB のメモリ = 2GB（元の設定のまま）
→ テスト環境と本番環境で挙動が異なる

3. 変更履歴がない

• 誰がいつ何を変更したかわからない
• 問題が起きても原因を追跡できない
• 変更を元に戻す手段がない

4. 属人化

「インフラの設定は田中さんしか知らない」
→ 田中さんが休んだら誰も対応できない

Infrastructure as Code（IaC）とは

インフラの構成をコードファイルとして記述し、そのコードを実行することでインフラを自動構築する手法です。

IaC ツールの比較

ShimaLinkではTerraformを使います。マルチクラウド対応で、将来のプロバイダー変更にも柔軟に対応できるからです。

IaC のワークフロー

1. コードを書く（main.tf）
    ↓
2. プランを確認する（terraform plan）
    ↓ 「何が作られ/変更されるか」が表示される
3. 適用する（terraform apply）
    ↓ 実際にインフラが構築される
4. Gitにコミットする
    ↓ 変更履歴が記録される

Yuki: 「IaCのいいところは、terraform plan で実際に何が起きるか事前に確認できること。“やってみないとわからない”がなくなるんだ。」

ポイント

• 手動インフラ管理は再現性・追跡性・共有性に欠ける
• IaCはインフラの構成をコードとして管理する手法
• コードなのでGitでバージョン管理、レビュー、共有が可能
• Terraformはマルチクラウド対応の業界標準IaCツール
• plan で事前確認、apply で適用、という安全なワークフロー

Terraform の基本 — HCL、プロバイダー、リソース

「Terraformは”インフラの設計図”を書くツール。設計図通りにクラウドを自動構築してくれる。」 ——Yuki

HCL（HashiCorp Configuration Language）

TerraformはHCLという独自の言語でインフラを定義します。JSONのように宣言的で、読みやすいのが特徴です。

# これがHCLの基本構文
resource "リソースタイプ" "名前" {
  設定項目 = "値"
}

Terraform プロジェクトの構成

shimalink-infra/
├── main.tf          # メインのリソース定義
├── variables.tf     # 変数の定義
├── outputs.tf       # 出力値の定義
├── terraform.tfvars # 変数の値（Git管理しない場合もある）
└── providers.tf     # プロバイダーの設定

プロバイダーの設定

プロバイダーはTerraformとクラウドを接続するプラグインです。

# providers.tf
terraform {
  required_providers {
    google = {
      source  = "hashicorp/google"
      version = "~> 5.0"
    }
  }
}

provider "google" {
  project = var.project_id
  region  = "asia-northeast1"
}

リソースの定義

ShimaLinkのインフラをTerraformで定義してみましょう。

# main.tf

# Cloud Run サービス
resource "google_cloud_run_v2_service" "shimalink_web" {
  name     = "shimalink-web"
  location = "asia-northeast1"

  template {
    containers {
      image = "asia-northeast1-docker.pkg.dev/shimalink/repo/web:latest"

      ports {
        container_port = 3000
      }

      env {
        name  = "NODE_ENV"
        value = "production"
      }

      env {
        name = "DATABASE_URL"
        value_source {
          secret_key_ref {
            secret  = google_secret_manager_secret.db_url.secret_id
            version = "latest"
          }
        }
      }

      resources {
        limits = {
          cpu    = "1"
          memory = "512Mi"
        }
      }
    }

    scaling {
      min_instance_count = 1
      max_instance_count = 10
    }
  }
}

# Cloud SQL データベース
resource "google_sql_database_instance" "shimalink_db" {
  name             = "shimalink-db"
  database_version = "POSTGRES_15"
  region           = "asia-northeast1"

  settings {
    tier = "db-f1-micro"

    backup_configuration {
      enabled    = true
      start_time = "03:00"
    }
  }

  deletion_protection = true
}

# データベース
resource "google_sql_database" "shimalink" {
  name     = "shimalink"
  instance = google_sql_database_instance.shimalink_db.name
}

変数の定義

# variables.tf
variable "project_id" {
  description = "GCPプロジェクトID"
  type        = string
}

variable "environment" {
  description = "環境名（dev, staging, prod）"
  type        = string
  default     = "dev"
}

variable "db_tier" {
  description = "Cloud SQLのインスタンスタイプ"
  type        = string
  default     = "db-f1-micro"
}

# terraform.tfvars
project_id  = "shimalink-project"
environment = "prod"
db_tier     = "db-g1-small"

出力値

# outputs.tf
output "web_url" {
  description = "ShimaLink WebアプリのURL"
  value       = google_cloud_run_v2_service.shimalink_web.uri
}

output "db_connection" {
  description = "データベース接続名"
  value       = google_sql_database_instance.shimalink_db.connection_name
  sensitive   = true
}

基本コマンド

# プロバイダーをダウンロード
terraform init

# 実行プランを確認（何が作られるか）
terraform plan

# インフラを構築
terraform apply

# インフラを削除
terraform destroy

# 現在の状態を表示
terraform show

Yuki: 「terraform plan が一番大事なコマンドだよ。実際に変更を適用する前に、何が起きるかを確認できる。Pull Requestでもplan結果をレビューするのがベストプラクティスだ。」

ポイント

• HCLは宣言的な言語で、何を作るかを記述する（どう作るかはTerraformが判断）
• プロバイダーでクラウドとの接続を設定する
• リソースでクラウド上のインフラ（サーバー、DB等）を定義する
• 変数で環境ごとの値を柔軟に変えられる
• init → plan → apply の3ステップが基本ワークフロー

環境の管理 — dev、staging、production

「同じコードで、dev・staging・prodを作れる。それがIaCの真骨頂だよ。」 ——Yuki

なぜ複数の環境が必要か

dev → staging → production
 │       │          │
 │       │          └ 実ユーザーがアクセス
 │       └ 本番と同じ構成でテスト
 └ 自由に壊して試せる環境

Terraform Workspaces

Terraformのワークスペース機能で、同じコードから複数の環境を管理できます。

# ワークスペースの作成
terraform workspace new dev
terraform workspace new staging
terraform workspace new prod

# ワークスペースの切り替え
terraform workspace select prod

# 一覧
terraform workspace list

環境ごとの変数ファイル

shimalink-infra/
├── main.tf
├── variables.tf
├── outputs.tf
├── environments/
│   ├── dev.tfvars
│   ├── staging.tfvars
│   └── prod.tfvars

# environments/dev.tfvars
environment    = "dev"
db_tier        = "db-f1-micro"
min_instances  = 0
max_instances  = 2

# environments/prod.tfvars
environment    = "prod"
db_tier        = "db-g1-small"
min_instances  = 1
max_instances  = 10

# dev環境を構築
terraform apply -var-file=environments/dev.tfvars

# prod環境を構築
terraform apply -var-file=environments/prod.tfvars

環境ごとのリソース命名

# main.tf — 環境名をリソース名に含める
resource "google_cloud_run_v2_service" "shimalink_web" {
  name     = "shimalink-web-${var.environment}"
  location = "asia-northeast1"

  template {
    containers {
      image = var.web_image

      resources {
        limits = {
          cpu    = var.environment == "prod" ? "2" : "1"
          memory = var.environment == "prod" ? "1Gi" : "512Mi"
        }
      }
    }

    scaling {
      min_instance_count = var.min_instances
      max_instance_count = var.max_instances
    }
  }
}

モジュール化

同じリソースの組み合わせを再利用可能なモジュールにまとめます。

shimalink-infra/
├── modules/
│   ├── web-service/
│   │   ├── main.tf
│   │   ├── variables.tf
│   │   └── outputs.tf
│   └── database/
│       ├── main.tf
│       ├── variables.tf
│       └── outputs.tf
├── environments/
│   ├── dev/
│   │   └── main.tf
│   └── prod/
│       └── main.tf

# environments/prod/main.tf
module "web" {
  source = "../../modules/web-service"

  environment   = "prod"
  min_instances = 1
  max_instances = 10
  cpu           = "2"
  memory        = "1Gi"
}

module "database" {
  source = "../../modules/database"

  environment = "prod"
  tier        = "db-g1-small"
  backup      = true
}

環境間のプロモーション

コード変更
    ↓
terraform plan（dev.tfvars）→ terraform apply
    ↓ devで動作確認
terraform plan（staging.tfvars）→ terraform apply
    ↓ stagingで最終テスト
terraform plan（prod.tfvars）→ terraform apply
    ↓ 本番リリース

Yuki: 「新しい県への展開もこれでできる。terraform apply -var-file=environments/kagoshima.tfvars とするだけで、鹿児島環境が8分で完成するんだ。」

ポイント

• dev、staging、productionの3環境を用意するのが標準的
• 同じTerraformコードで環境ごとの変数ファイルを切り替える
• リソース名に環境名を含めて衝突を防ぐ
• モジュール化で再利用可能なインフラ部品を作る
• 環境のプロモーション（dev → staging → prod）で安全にリリースする

ステート管理 — Terraform の心臓部

「ステートファイルはTerraformの記憶。これを失うと、Terraformは何を管理しているか忘れてしまう。」 ——Yuki

Terraform ステートとは

Terraformは、管理しているインフラの現在の状態を**ステートファイル（terraform.tfstate）**に記録します。

コード（main.tf）    ←→  ステート（terraform.tfstate）  ←→  実際のクラウドリソース
  「こうあるべき」          「こうなっている」                「実際の状態」

terraform plan は、コードとステートを比較して「何を変更する必要があるか」を計算します。

ステートの重要性

# ステートに記録される情報の例
{
  "resources": [
    {
      "type": "google_cloud_run_v2_service",
      "name": "shimalink_web",
      "instances": [
        {
          "attributes": {
            "id": "projects/shimalink/locations/asia-northeast1/services/shimalink-web",
            "uri": "https://shimalink-web-xxxxx.run.app"
          }
        }
      ]
    }
  ]
}

ローカルステート vs リモートステート

ローカルステート（デフォルト）

自分のPC
└── shimalink-infra/
    └── terraform.tfstate  ← 自分のPCにだけ存在

問題点:

• チームメンバーと共有できない
• PCが壊れたらステートが失われる
• 2人が同時に terraform apply すると競合する

リモートステート（推奨）

クラウドストレージ（GCS / S3）
└── terraform.tfstate  ← チーム全員がアクセス可能

開発者A ──→ リモートステート ←── 開発者B
              ↕ ロック機構
           同時書き込みを防止

リモートバックエンドの設定

# backend.tf — GCS（Google Cloud Storage）を使う場合
terraform {
  backend "gcs" {
    bucket = "shimalink-terraform-state"
    prefix = "prod"
  }
}

# backend.tf — S3（AWS）を使う場合
terraform {
  backend "s3" {
    bucket         = "shimalink-terraform-state"
    key            = "prod/terraform.tfstate"
    region         = "ap-northeast-1"
    dynamodb_table = "terraform-locks"
    encrypt        = true
  }
}

ステートロック

複数人が同時に terraform apply を実行すると、ステートが壊れる可能性があります。ロック機構がこれを防ぎます。

開発者A: terraform apply
  → ステートをロック ← 開発者Bはここでブロックされる
  → リソースを変更
  → ステートを更新
  → ロックを解放
  → 開発者Bが実行可能に

ステート操作コマンド

# ステートの内容を表示
terraform show

# 特定のリソースの詳細を表示
terraform state show google_cloud_run_v2_service.shimalink_web

# リソース一覧
terraform state list

# リソースをステートから除外（手動管理に移す）
terraform state rm google_cloud_run_v2_service.shimalink_web

# リソースをインポート（既存リソースをTerraform管理下に）
terraform import google_sql_database_instance.shimalink_db shimalink-db

ステート管理のベストプラクティス

.gitignore の設定

# Terraformのステートファイル
*.tfstate
*.tfstate.backup

# ローカルの変数値（機密情報を含む場合）
*.tfvars
!*.tfvars.example

# Terraformのローカルディレクトリ
.terraform/

Yuki: 「ステートファイルにはDBのパスワードなどの機密情報が含まれることがある。絶対にGitにコミットしないこと。リモートバックエンドに保存して、暗号化を有効にするのがセキュリティの鉄則だよ。」

ポイント

• ステートファイルはTerraformが管理するインフラの「記憶」
• チーム開発ではリモートバックエンド（GCS/S3）が必須
• ロック機構で同時操作の競合を防ぐ
• ステートファイルには機密情報が含まれるため、Gitにコミットしない
• terraform import で既存リソースをTerraform管理下に取り込める

$ terraform apply
...
Apply complete! Resources: 12 added, 0 changed, 0 destroyed.

所要時間: 8分23秒