Terraformとは
Terraformは、HashiCorp社が開発したInfrastructure as Code（IaC）ツールです。HCL（HashiCorp Configuration Language）という宣言的な言語を使って、クラウドインフラをコードで定義・管理できます。
Terraformの素敵なところ
1. 他のアカウントのロールを簡単に引き受けることができる
マルチアカウント環境でのインフラ管理において、TerraformのAssumeRole機能は非常に強力です。
例えば、ドメイン管理アカウントがあってそのサブドメインを別のアカウントで使用したいとします。このとき、
provider "aws" {
region = var.aws_region
}
provider "aws" {
alias = "parent"
region = var.aws_parent_phz_region
assume_role {
role_arn = var.cross_account_role_arn
}
}
data "aws_route53_zone" "parent" {
provider = aws.parent
name = var.parent_domain
private_zone = false
}
resource "aws_route53_zone" "sub" {
name = var.sub_domain
tags = var.tags
}
resource "aws_route53_record" "delegate_ns" {
provider = aws.parent
zone_id = data.aws_route53_zone.parent.zone_id
name = var.sub_domain
type = "NS"
ttl = 300
records = aws_route53_zone.sub.name_servers
}
のように記述することで、providerの指定だけでAssumeRoleを実現できます。これによって、モジュール化をする際のレポジトリの切れ目の制約が少なくなり、より良い抽象化の手段が取りやすくなります。今回の場合だと、サブドメインを使用できるようにすることのみに注力したいので、これらはモジュールとしては単一のものとまとめておきたい状況でした。
2. applyの実行速度が速い
並列実行により高速化が可能
Terraformはリソースの依存関係グラフを分析し、独立したリソースを並列で作成できます。これが速度の秘訣です。DAGを解析して、トポロジカルソートの順番に処理を行うイメージです。
CloudFormationとの比較
| 項目 | Terraform | CloudFormation |
|---|---|---|
| 並列実行 | デフォルトで10並列、最大100以上も可能 | 順次実行が基本（安全性重視） |
| 50リソース作成 | 並列実行で高速 | 順番に作成するため時間がかかる |
| 大規模プロジェクト | 適切な最適化でパフォーマンス維持 | テンプレートの整理が必要 |
Terraformは設定を分析し並列実行可能な部分を見つけて同時に処理を開始します。一方、CloudFormationは安定性を重視した順次デプロイを行うため、大規模デプロイでは時間がかかる傾向があります。
高速化のためのTips
個人的に好きなTerraformデプロイの高速化の手段です。
1. 並列度の調整
# デフォルトは10並列
terraform apply -parallelism=30
並列度を上げることで、独立したリソースの作成を高速化できます。ただし、AWSのAPIレートリミットに注意が必要です。
2. 不要なチェックのスキップ
provider "aws" {
region = "ap-northeast-1"
skip_credentials_validation = true
skip_metadata_api_check = true
skip_region_validation = true
}
これらのチェックをスキップすることで初期化時間を約20%削減できます。
3. ターゲット指定による部分適用
terraform apply -target=aws_instance.example
全体を適用する必要がない場合、-targetフラグで対象を絞ることで大幅に時間を短縮できます。
4. ステートファイルの分割
大規模なインフラでは、ステートファイルを論理的に分割することが推奨されています。適切に分割することで操作時間を70〜90%削減できたという報告もあります。
注意点
Terraformが常に高速というわけではありません。パフォーマンスは以下の要因に依存します：
- リソース数（500以下なら最適化不要、5000以上は要設計見直し）
- リソース間の依存関係の複雑さ
- ネットワーク遅延
- プロバイダーAPIのレートリミット
3. HCL言語がIaCと相性が良い
Terraformが採用しているHCL（HashiCorp Configuration Language）は、Infrastructure as Codeのために設計された言語です。ここでは、AWS CDKとの比較を中心にHCLの利点を解説します。
HCLの特徴
宣言的かつ人間が読みやすい
resource "aws_instance" "web" {
ami = "ami-0c02fb55956c7d316"
instance_type = "t3.micro"
tags = {
Name = "WebServer"
Environment = "production"
}
}
HCLはインフラ定義に特化した言語であり、「何を作りたいか」を直感的に記述できます。
CDKとの比較：HCLを選ぶ理由
AWS CDKはTypeScript、Python、Javaなどの汎用プログラミング言語でインフラを定義できるツールです。一見便利に見えますが、HCLには独自の強みがあります。
1. シンプルさと学習コスト
| 観点 | HCL | CDK |
|---|---|---|
| 言語の複雑さ | インフラ定義に必要な機能のみ | 汎用言語の全機能が使える（使わなくてもいい機能も多い） |
| 概念の数 | resource, variable, output, module | construct, stack, app, context, bootstrapping... |
| 始めやすさ | tfファイルを書いてapplyするだけ | bootstrapプロセスが必要 |
CDKには「construct」「stack」「app」「bootstrapping」など多くの概念があり、規制の厳しい大規模環境では特にbootstrappingプロセスが複雑になります。一方、HCLは設定ファイルを書いてterraform applyするだけで始められます。
また、汎用言語は機能が多い分だけ人によって書き方のくせが出やすいです。一方で、Terraformコードは限られた構文なので、大体の場合はコードが似ます。他の方が書いたコードを理解しやすいというメリットは、IaCを実現する上でとても重要です。
2. planの見やすさ
terraform plan
# 出力例
+ aws_instance.web
ami: "ami-0c02fb55956c7d316"
instance_type: "t3.micro"
~ aws_security_group.web
ingress.0.from_port: 80 -> 443
Terraformのplanは変更内容が非常に明確です。CDKのdiffも同様の機能を持っていますが、Terraformの方が何が変わるかを直感的に把握しやすい気がします。
3. 既存リソースのインポート
# Terraformでの既存リソースインポート
terraform import aws_s3_bucket.existing_bucket my-existing-bucket
既存のAWSリソースをIaC管理下に置きたい場合、Terraformは強力なインポート機能を持っています。たくさんのデータソースがあり、既存インフラの参照も容易です。
CDKでは既存リソースのインポートは「参照して一部のプロパティを変更する」ことが目的であり、リソース自体をIaC管理下に置くのは本来の用途ではありません。全てのリソースをコードで管理するときに、既存リソースの存在が問題になることは多々あります。このようなときに簡単に問題を解決できるのはとても良いポイントです。
4. マルチクラウド対応
# AWSリソース
provider "aws" {
region = "ap-northeast-1"
}
resource "aws_s3_bucket" "data" {
bucket = "my-data-bucket"
}
# GCPリソース（同じHCL構文で記述可能）
provider "google" {
project = "my-project"
region = "asia-northeast1"
}
resource "google_storage_bucket" "backup" {
name = "my-backup-bucket"
location = "ASIA"
}
Terraformは同じHCL構文でAWS、GCP、Azureなど複数のクラウドを管理できます。CDKはAWS専用ツールであり、マルチクラウド環境では別のツールが必要になります。
5. ステート管理の明確さ
# Terraformのバックエンド設定
terraform {
backend "s3" {
bucket = "my-terraform-state"
key = "prod/terraform.tfstate"
region = "ap-northeast-1"
dynamodb_table = "terraform-locks"
encrypt = true
}
}
Terraformはterraform.tfstateファイルでインフラの状態を明示的に管理します。S3 + DynamoDBでリモートステート管理とロック機能を実現でき、チーム開発でも安心です。
CDKはCloudFormationのスタック状態に依存しており、状態管理が暗黙的です。Terraformの方がドリフト（実際の状態とコードの乖離）検出も明確に行えます。
CDKコードからCloudFormationスタックの変換についても、行間が多く理解するのが大変です。一方で、tfstateファイルはHCLからの変換が比較的読みやすいので、実際にデプロイされているリソースがわかりやすいです。
モジュールによる再利用性
# 公式モジュールの利用
module "vpc" {
source = "terraform-aws-modules/vpc/aws"
version = "5.0.0"
name = "my-vpc"
cidr = "10.0.0.0/16"
azs = ["ap-northeast-1a", "ap-northeast-1c", "ap-northeast-1d"]
private_subnets = ["10.0.1.0/24", "10.0.2.0/24", "10.0.3.0/24"]
public_subnets = ["10.0.101.0/24", "10.0.102.0/24", "10.0.103.0/24"]
enable_nat_gateway = true
}
Terraform Registryには多数の公式・コミュニティモジュールがあり、ベストプラクティスに基づいたインフラを素早く構築できます。
まとめ
本記事では、Terraformの3つの魅力を解説しました。
- クロスアカウントのAssumeRole: マルチアカウント環境を単一プロジェクトから安全に管理
- 高速な並列実行: 適切な最適化で、特に大規模環境でのデプロイを高速化
- HCL言語の生産性: IaC専用の宣言的言語により、シンプルさと可読性を両立。CDKと比較してもステート管理やインポート機能で優位性あり
もちろん、CDKやCloudFormationにもそれぞれの強みがあります。プロジェクトの要件に応じて適切なツールを選択することが重要ですが、IaCの第一歩としてTerraformは非常におすすめできるツールです。