No history yet

モジュール設計の極意

モジュール設計の真価

Terraformの設定が大きくなるにつれて、単一の.tfファイルですべてを管理するのは現実的ではなくなります。コードは読みにくくなり、少しの変更が予期せぬ影響を及ぼすリスクも高まります。これは、すべての材料と調理器具を作業台にごちゃ混ぜに置いて料理をするようなものです。効率が悪く、ミスも起きやすくなります。

ここで登場するのがモジュールです。モジュールは、関連するリソース群を一つの論理的な単位としてカプセル化する仕組みです。適切に設計されたモジュールは、インフラの「部品」として機能し、再利用性と保守性を劇的に向上させます。これにより、複雑なインフラをまるでレゴブロックを組み立てるように、体系的かつ安全に構築できるようになります。

Terraformコードをモジュールに整理することは、クリーンで再利用可能、そして管理しやすい設定を維持するために不可欠です。

ルートと子の役割分担

Terraformの構成は、大きく2種類のモジュールから成り立ちます。terraform applyを実行する起点となる「ルートモジュール」と、そこから呼び出される再利用可能な「子モジュール」です。

ルートモジュール (Root Module) これは構成のエントリーポイントです。通常、productionやstagingといった環境ごとのディレクトリがルートモジュールとなり、その環境に必要なインフラ全体を定義します。ルートモジュールの主な役割は、子モジュールを組み合わせて、環境特有のパラメータ（例えば、インスタンスサイズやVPCのCIDRブロック）を渡すことです。

子モジュール (Child Module) これは、特定の機能を持つインフラ部品です。例えば、「VPC」「RDSデータベース」「ECSクラスタ」などがそれぞれ独立した子モジュールになります。子モジュールは自己完結しており、特定の環境に依存しないように設計されるべきです。これにより、様々なルートモジュールから再利用可能になります。

例えば、本番環境のルートモジュールにあるmain.tfは次のようになります。

# ./production/main.tf

module "vpc" {
  source = "../modules/vpc" # ローカルパスで子モジュールを指定

  cidr_block      = "10.0.0.0/16"
  environment     = "production"
  enable_nat_gateway = true
}

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

  vpc_id          = module.vpc.vpc_id
  instance_class  = "db.t3.large"
  allocated_storage = 100
}

この構成では、インフラの全体像がルートモジュールで一目瞭然となり、各部品の具体的な実装は子モジュールに隠蔽されています。これにより、コードの見通しが良くなり、管理が容易になります。

ソース管理とバージョニング

モジュールは再利用が前提のため、どこから読み込むかを指定するsource属性が重要です。ローカルパスでの指定は開発初期には便利ですが、チームでの利用や複数プロジェクトでの共有には向いていません。

実運用では、Gitリポジトリをsourceとして利用するのが一般的です。これにより、モジュールのバージョン管理が可能になります。ref属性を使って、特定のブランチ、コミットハッシュ、またはタグを指定できます。

module "vpc" {
  # Gitリポジトリとタグを指定してバージョンを固定
  source = "git@github.com:my-org/terraform-modules.git//vpc?ref=v1.2.0"

  cidr_block  = "10.0.0.0/16"
  environment = "production"
}

タグ（v1.2.0など）を使ってバージョンを固定することは、インフラの安定性を保つ上で極めて重要です。これにより、誰かがモジュールに破壊的な変更を加えても、既存の環境が意図せず影響を受けることを防げます。セマンティックバージョニングに従ってタグを管理することで、変更内容（新機能、バグ修正、破壊的変更）がバージョン番号から明確にわかるようになります。

また、Terraformのプライベートレジストリを利用すれば、モジュールの検索性やバージョン制約の管理がさらに容易になります。

インターフェースとしての変数と出力

優れたモジュールは、明確なインターフェースを持ちます。これは、プログラミング言語における関数の引数と戻り値に相当します。Terraformでは、入力変数が「引数」に、出力変数が「戻り値」の役割を果たします。

変数のカプセル化 (Encapsulation) モジュールを呼び出す側（ルートモジュール）は、モジュールの内部実装を知る必要はありません。知るべきなのは、どのような変数を渡せば、どのように振る舞いが変わるかだけです。これをと呼びます。

variables.tfファイルで変数を定義する際、description、type、そしてvalidationブロックをしっかり記述することが重要です。これにより、モジュールの使い方が明確になり、不正な値が渡されるのを防げます。

# ./modules/vpc/variables.tf

variable "cidr_block" {
  type        = string
  description = "VPCのCIDRブロック。"

  validation {
    # 正規表現でCIDR形式を検証
    condition     = can(cidrnet(var.cidr_block, 1))
    error_message = "有効なCIDRブロック表記（例: 10.0.0.0/16）を指定してください。"
  }
}

variable "environment" {
  type        = string
  description = "リソースに付与する環境タグ (e.g., 'production', 'staging')"
  default     = "development"
}

出力による情報公開の制御 モジュールが作成したリソースの情報（IDやIPアドレスなど）は、outputs.tfを通じて外部に公開されます。これもインターフェースの重要な一部です。

何を公開し、何を隠蔽するかを慎重に設計する必要があります。例えば、VPCモジュールは、作成したVPCのIDやサブネットのIDリストは公開すべきですが、ルートテーブルやNATゲートウェイの詳細な内部リソースまで公開する必要はないかもしれません。呼び出し側が必要とする最小限の情報だけを公開することで、モジュールの独立性を保ち、依存関係を疎に保つことができます。

# ./modules/vpc/outputs.tf

output "vpc_id" {
  value       = aws_vpc.main.id
  description = "作成されたVPCのID。"
}

output "public_subnet_ids" {
  value       = aws_subnet.public[*].id
  description = "パブリックサブネットのIDリスト。"
}

output "private_subnet_ids" {
  value       = aws_subnet.private[*].id
  description = "プライベートサブネットのIDリスト。"
}

このように定義された出力は、ルートモジュールから module.<MODULE_NAME>.<OUTPUT_NAME> という形式で参照できます。例えば、module.vpc.vpc_id のように使います。これにより、モジュール間で安全に情報を連携させることが可能になります。

モジュール設計は、単にコードを分割するだけでなく、再利用可能で堅牢、そして理解しやすいインフラコードを書くための設計思想です。これらの原則を適用することで、Terraformでのインフラ管理はより洗練されたものになります。

Quiz Questions 1/5

Terraformモジュールを使用する主な利点は何ですか？

Quiz Questions 2/5

terraform apply を実行する起点となる構成のエントリーポイントは、一般的に何と呼ばれますか？