テラフォーム

テラフォームとは？

Terraform は、HashiCorp社開発の Infrastructure as Code（IaC）ツールで、AWS、Azure、GCP といった複数のクラウドプロバイダーのリソース（サーバー、ネットワーク、ストレージなど）を、統一的なコード言語で定義・管理できます。テラフォーム専用の記述言語「HCL（HashiCorp Configuration Language）」を使い、「こういったインフラが欲しい」という設定をテキストファイルに書き、terraform apply コマンド一つで環境が自動構築される仕組みです。

ひとことで言うと： 「AWS のここにこのサーバーが欲しい」を、Word ではなくコード（テキスト）で書き、ボタンを押すだけで自動で構築される。同じコードを実行すれば同じ環境が再現される。

ポイントまとめ：

何をするものか： マルチクラウド対応のインフラコード化ツール
なぜ必要か： クラウドインフラの構築・変更を安全かつ効率的に自動化するため
誰が使うか： DevOps エンジニア、インフラエンジニア、ソフトウェア開発チーム

なぜ重要か

Terraform が登場する前、クラウドインフラの構築は、AWS コンソール（Web UI）で「ここをクリック、ここに値を入力」という手作業が必要でした。複雑な環境構築には数日かかり、手作業ミスのリスクも高かった。

Terraform を導入することで、以下が実現されます。

まず、構築の自動化と再現性です。同じコードを実行すれば、環境が完全に再現されます。「本番環境と開発環境で微妙に設定が違う」という問題が起きません。

次に、マルチクラウド対応です。Terraform は AWS、Azure、GCP など複数のプロバイダーに対応しています。「AWS から GCP に移行したい」という場合、プロバイダー部分のコードを変更するだけで、同じリソースを別クラウドで再構築できます。ベンダーロックイン（特定ベンダーへの依存）を大幅に低減できます。

また、インフラ変更の透明性が向上します。設定変更は全てギットにコミットされ、「いつ誰が何を変更したか」が記録に残ります。プルリクエストによるコードレビューも可能になり、本番反映前に変更内容をチェックできます。

さらに、スケーリング（環境拡張）が簡単です。「サーバーを3台から5台に増やしたい」という変更も、コードでパラメータを変更し terraform apply するだけで完了します。

仕組みをわかりやすく解説

Terraform の基本的なワークフローは、以下の通りです。

1. コード記述

まず、HCL（Terraform 専用言語）で、インフラ構成を記述します。例：

provider "aws" {
  region = "ap-northeast-1"
}

resource "aws_instance" "web_server" {
  ami           = "ami-12345678"
  instance_type = "t2.micro"
}

このコードは「AWS の東京リージョンに、t2.micro スペックのサーバーを 1 台建てる」という意味です。

2. 計画立案（plan）

terraform plan コマンドを実行すると、Terraform が「現在の状態」と「コード指定の状態」の差分を計算し、「何を追加・変更・削除するのか」を表示します。

実行前に確認できるため、予期しない変更を防げます。

3. 適用（apply）

terraform apply コマンドを実行すると、計画したリソース変更が実施されます。クラウドプロバイダーへの API 呼び出しが自動実行され、サーバーやネットワーク設定が実際に作成・更新されます。

4. 状態管理

Terraform は「現在のインフラ状態」を terraform.tfstate というファイルに記録します。次回 plan を実行する時、このファイルとコードの差分から、「何が変わったのか」を判定します。

主要機能の比較

Terraform の特徴：

マルチクラウド対応：AWS、Azure、GCP、その他 100+ のプロバイダーに対応。単一の言語で複数クラウドを管理できます。
宣言型：「こういった状態にしたい」を記述するため、可読性が高い。
豊富なプロバイダー：Kubernetes、Docker、GitHub、DataDog など、インフラ周辺のあらゆるサービスに対応。
モジュール化：よく使う設定をモジュール化し、再利用できます。

競合ツールとしては CloudFormation（AWS専用）や Ansible などがありますが、Terraform は「マルチクラウド」「宣言型」の組み合わせで、現代的な選択肢として広く採用されています。

実際の活用シーン

新規 SaaS サービスの立ち上げ

スタートアップが新しい Web サービスを立ち上げる時、Terraform で「Web サーバー 5 台、データベース 1 台、ロードバランサー、CDN」といった構成をコードで定義します。数分で本番環境が立ち上がります。従来なら 1 週間かかった作業が 1 日で完了します。

マルチリージョンでのデプロイ

グローバルサービスを提供する場合、複数のクラウドリージョン（東京、ロンドン、シンガポールなど）に同じ環境をデプロイしたい。Terraform なら、リージョンパラメータを変更しコードを再実行するだけで、別リージョンに同じ環境が立ち上がります。

開発環境・ステージング環境・本番環境の同期

開発者がローカルの簡易版を作り、ステージングと本番は本格的な構成にしたい場合、Terraform でパラメータ化します。terraform.tfvars ファイルを環境ごとに変えるだけで、「開発環境はコンパクト、本番環境は高可用性」といった柔軟性が実現できます。

クラウドベンダー変更

「AWS に依存しすぎているので、GCP に一部移行したい」という場合、Terraform なら provider の部分を変更し、同じリソース定義を別プロバイダーで実行できます。ベンダーロックインを大幅に低減します。

メリットと注意点

Terraform の最大のメリットは、複雑なインフラ構築を自動化・再現可能にすることです。また、マルチクラウド対応により、ベンダー依存を減らせます。

ギットによる版管理が可能なため、「インフラも IaC 文化」を組織に定着させることができます。

さらに、plan コマンドで実行前の変更内容を確認できるため、予期しない副作用を防げます。

注意点としては、学習曲線があることです。HCL の文法は比較的簡単ですが、「Terraform の概念」（プロバイダー、リソース、状態管理）と「各クラウドプロバイダーの知識」（AWS で言えば VPC、セキュリティグループなど）の両方が必要です。

また、状態ファイル（terraform.tfstate）の管理が重要です。このファイルには機密情報（パスワード、API キー）が含まれる可能性があり、セキュアに保管・バックアップすることが不可欠です。

さらに、Terraform のバージョン管理も必要です。新しいバージョンでコードの書き方が変わることがあり、バージョン間の互換性注意が必要な場合があります。

また、複雑な条件分岐や複数ツールの連携が必要な場合、Terraform だけでは表現しきれないこともあります。その場合は、Ansible などと組み合わせることもあります。

よくある質問

Q: Terraform と CloudFormation（AWS 純正）どちらを使う？

A: 「AWS のみを使う組織なら CloudFormation」という選択肢もありますが、「将来マルチクラウドを考えるなら Terraform」がおすすめです。Terraform の方が汎用性が高く、学習投資も将来的に活きやすいです。

Q: 状態ファイル（terraform.tfstate）はどこに保管する？

A: ローカルディスクは危険です。Terraform Cloud や S3（暗号化有効）など、リモート状態ストレージを使うべきです。これにより、チーム全体で状態を共有でき、複数人での並行運用も安全になります。

Q: Terraform を使うなら、Ansible は不要？

A: 用途が異なります。Terraform は「インフラリソース」（サーバーそのもの）を管理します。Ansible は「サーバー内のソフトウェア設定」を管理します。複雑なシステムでは、「Terraform でサーバーを作成 → Ansible で設定」という組み合わせが標準的です。

Q: Terraform での大規模環境管理の課題は？

A: リソースが数百・数千になると、テラフォームファイルが巨大化・複雑化します。モジュール化と workspace（環境分離）を駆使し、管理性を保つ工夫が重要です。また、状態ファイルの競合を避けるため、リモート状態管理は必須になります。

テラフォーム