【ITニュース解説】From Messy to Modular: A Better Way to Write Production-Ready Terraform - Part 1

システム開発において、サーバーやネットワークといったインフラ環境をコードで管理する「Infrastructure as Code（IaC）」は、非常に重要な考え方である。特に「Terraform（テラフォーム）」は、クラウドサービス上にインフラを構築するための有力なツールの一つとして広く使われている。しかし、Terraformを使い始めたばかりの段階では、すべての設定を一つの大きなファイルに書きがちで、これが後々大きな問題を引き起こすことがある。この記事では、そうした「ごちゃごちゃした状態」から脱却し、より効率的で管理しやすいTerraformの使い方、特に「モジュールパターン」と「環境ごとの設定管理」に焦点を当てて解説する。

まず、なぜ一つの巨大な設定ファイルが問題なのかについて考える。プロジェクトが小さく、インフラの構成もシンプルなうちは、一つのmain.tfファイルに全ての情報を記述しても機能する。しかし、開発環境、ステージング環境、本番環境といったように、複数の環境を構築する必要が出てくると、同じようなコードを何度もコピー＆ペーストすることになりがちである。例えば、Kubernetesクラスターを立ち上げる際に、クラスター本体、それを動かすサーバー群、ネットワーク設定、アクセス権限などを全て一つのファイルに記述すると、そのファイルはすぐに数百、数千行にも膨れ上がる。このような巨大なファイルの問題点はいくつかある。第一に、コードの重複が避けられないこと。新しい環境を作るたびに同じコードをコピーするため、どこかに間違いがあった場合、全てのコピーされた箇所を修正する必要がある。第二に、コードが複雑で理解しにくいこと。どこに何が書かれているのかを見つけるのが難しくなり、設定全体を把握するのに時間がかかる。第三に、変更が全体に与える影響（ブラスト半径）が大きいこと。小さなミスが、関連する全ての環境に影響を及ぼし、システム全体を停止させるリスクを高めてしまう。

これらの問題を解決するために、「モジュールパターン」が導入される。Terraformにおける「モジュール」とは、一連のTerraform設定をひとまとめにした、自己完結型のパッケージのことである。これはプログラミング言語における「関数」や「サブルーチン」のようなものと考えると理解しやすい。モジュールは特定の入力を受け取り（変数）、定義された一連のアクション（リソースの作成）を実行し、結果として特定の出力（アウトプット）を提供する。例えば、AWSのEKS（Elastic Kubernetes Service）クラスターを構築する場合、クラスター本体、IAM（Identity and Access Management）ロールとポリシー、ノードグループ（クラスターを構成するサーバー群）といった、複雑で多数のリソースが必要となる。これら一連のリソース群を一つのEKSクラスターモジュールとしてまとめることで、必要な時にそのモジュールを呼び出すだけで、最小限の記述でEKSクラスターを構築できるようになる。これにより、コードの再利用性が高まり、管理が格段に楽になる。

具体的には、プロジェクトの構造を次のように整理することが推奨される。terraform-project/というルートディレクトリの下に、再利用可能なモジュールを格納するmodules/ディレクトリと、各環境の設定を記述するenvironments/ディレクトリを配置する。modules/aws-eks-cluster/の中には、モジュールの本体となるmain.tf、モジュールが受け取る入力値を定義するvariables.tf、モジュールが提供する出力値を定義するoutputs.tfを置く。このように、モジュールを明確に分割することで、特定の機能やリソース群の定義が独立し、他の部分に影響を与えることなく開発やメンテナンスが可能になる。

モジュール自体ができたとして、次に重要となるのが、開発環境や本番環境といった、環境ごとに異なる設定値（例：サーバーのサイズや数など）をどのように管理するかである。これにはいくつかの方法があるが、より良い管理方法へと進化させていくことが求められる。

最もシンプルな方法は、モジュールを呼び出す際に、必要な設定値を直接記述する「インライン引数」である。例えば、開発環境のmain.tfの中でEKSクラスターモジュールを呼び出し、その際にクラスター名やノードグループのインスタンスタイプなどを直接指定するやり方である。これは手軽だが、設定値がコードの中に埋め込まれるため、値の変更があった際にコード全体を見直す必要があり、読みづらさや管理のしにくさにつながる。

次に推奨されるのが、「.tfvarsファイル」を使った設定値の分離である。これは、設定値をコードとは別のファイルに記述する方法である。まず、各環境のディレクトリ（例：environments/dev/）内にvariables.tfファイルを作成し、その環境で利用する変数（例：ノードグループのインスタンスタイプなど）を定義する。次に、同じディレクトリにdev.tfvarsのようなファイルを作成し、そこで変数に具体的な値を割り当てる。これにより、設定値がコードから完全に分離され、開発環境はdev.tfvars、本番環境はprod.tfvarsといった形で、それぞれの環境に合わせた設定値を簡単に切り替えられるようになる。Terraformを実行する際には、terraform apply -var-file="dev.tfvars"のようにtfvarsファイルを指定することで、そのファイルに定義された設定値が適用される。この方法は、設定とロジックを明確に分けるため、管理が非常にしやすくなる。

さらに高度な管理方法として、「locals（ローカル変数）」の利用がある。localsは、Terraformの設定内で利用できる名前付き定数のようなもので、計算された値や共通の値を定義するのに便利である。例えば、クラスター名やリソースに付けるタグなど、環境ごとに一部だけが異なるが、ある程度のルールに基づいて生成したい値がある場合に有効である。environments/dev/locals.tfのようなファイルを作成し、そこで「環境名」や「プロジェクト名」といった基本となる値を定義し、それらを組み合わせて「クラスター名」のような派生する値を生成できる。また、共通で付けたいタグなどもlocalsで定義しておけば、一貫した命名規則やタグ付けを全ての環境で強制でき、管理上の統一性が保たれる。

最終的に推奨される構造は、これらの方法を組み合わせたものである。具体的には、環境ごとに変わる生の設定値（インスタンスサイズや数など）はdev.tfvarsのような.tfvarsファイルに記述し、環境間で共通して利用する命名規則や派生値（クラスター名、共通タグなど）はlocals.tfに定義する。そして、各環境のmain.tfファイルは、これらの.tfvarsとlocalsで定義された値を使って、モジュールをオーケストレート（調整・結合）する役割に徹する。この構造により、プロジェクトは以下のような構成となる。

terraform-project/ ├── modules/ │ └── aws-eks-cluster/ │ ├── main.tf （モジュールのロジック） │ ├── variables.tf （モジュールの入力定義） │ └── outputs.tf （モジュールの出力定義） └── environments/ └── dev/ ├── main.tf （環境ごとのモジュール呼び出しと調整） ├── variables.tf （環境が受け取る入力定義） ├── locals.tf （命名規則や共通値の定義） └── dev.tfvars （開発環境の具体的な設定値）

このアプローチは、各ファイルが明確な役割を持ち、責任範囲が分離されているため、プロジェクト全体の可読性が高く、変更や監査も容易になる。開発者は、各環境の設定ファイルを見れば、その環境がどのような構成になっているのかを素早く理解できる。これは、プロフェッショナルなインフラ管理を実現するための基盤となる重要なパターンである。

この記事で解説したモジュールパターンと変数管理の方法は、Terraformを使ったIaCをより堅牢でスケーラブルなものにするための第一歩である。これにより、複雑なインフラを効率的に構築し、複数の環境を矛盾なく管理する能力が格段に向上する。しかし、IaCにはまだ重要な考慮事項が残されている。特に、Terraformがインフラの状態を記録する「ステートファイル」の管理は非常に重要であり、次回はその詳細について解説される予定である。リモートステートバックエンドの利用や、よりDRY（Don't Repeat Yourself）な環境設定を実現する「Terragrunt」といったツールについても触れることとなるだろう。