What Is Terraform IaC? A Practical Guide¶
チェック¶
- [ ] 本文を確認した
- [ ] 概要を確認した
- [ ] タグを確認した
- [ ]
inbox/直下へ移行した
概要¶
Terraform を Infrastructure as Code の実践ツールとして説明しつつ、成熟したチームで state file と state lock が operational bottleneck になりやすいことを論じる記事。
HCL、provider、state、terraform init/plan/apply、multi-cloud provider ecosystem、Pulumi/CloudFormation/Ansible/OpenTofu との比較が整理される。
後半では Stategraph の宣伝として、file-based state の代わりに SQL-queryable structured state、resource-level locking、parallel execution を提供する backend replacement が提示されている。
本文¶
記事の出発点は、Terraform が IaC の default answer になった理由と、その一方で成熟したチームでは state model が限界になりやすいという問題意識。
Terraform は HCL による宣言的な infrastructure 定義、terraform plan による変更 preview、terraform apply による provisioning を提供する。
AWS、Azure、Google Cloud、Kubernetes、SaaS、on-premises などを provider 経由で扱えるため、multi-cloud や multi-provider の共通 workflow として広がった。
ただし、チーム規模が大きくなると、state file、state lock、複数 state file に分断された可視性が operational limit になる。
Infrastructure as Code¶
IaC は、compute instance、load balancer、DNS、network、database などの infrastructure を、manual console click や ad hoc CLI command ではなく code file で定義・管理する practice。
code が version control に入ることで、application code と同じように review できる。 dev、staging、production で同じ構成を再現しやすい。 configuration drift を減らせる。 手順書や個人の記憶に頼らず、declarative configuration を source of truth にできる。
Terraform はこの IaC model を多くのチームに使いやすくした tool として説明される。
Terraform IaC とは¶
Terraform IaC は、Terraform を使って infrastructure を宣言的な configuration file で定義し、provisioning と変更管理を行うこと。
Terraform configuration は HCL、HashiCorp Configuration Language をベースにした Terraform language で書く。 HCL は人間にも機械にも読みやすく、review や automation に向く。
Terraform の workflow はシンプル。
terraform init は working directory を初期化し、provider plugin を install する。
terraform plan は desired state と current state を比較し、変更予定を出す。
terraform apply は plan に基づき実際に resource を作成・変更・削除する。
現実の infrastructure が configuration と一致していれば、plan は no changes を返す。 この idempotent な性質により、同じ configuration を繰り返し実行しても不要な redeploy を避けられる。
Core concept: configuration、provider、state¶
Terraform を理解するには、configuration、provider、state の3つが重要。
configuration は intent を定義する。
.tf file に resource、input、output、module、data source を書き、どの infrastructure が存在すべきかを宣言する。
手順を書くのではなく、desired state を書く。
provider は Terraform と external API をつなぐ plugin。 AWS、Azure、Google Cloud、Kubernetes、GitHub、Datadog など、resource type は provider によって実装される。 Terraform Registry には多数の provider があり、記事では 6,000 以上とされている。 この provider ecosystem が、Terraform を単一 cloud の tool ではなく general infrastructure provisioning layer にしている。
state は configuration と real-world resource の対応を記録する。 Terraform は state を使って、何がすでに存在するか、どの resource がどの configuration に対応するか、何を変更・削除できるかを判断する。 state がなければ、Terraform は安全な plan を作れない。
local state は個人の実験では問題ないが、team workflow ではすぐ限界が出る。 共有 backend に state を置き、lock を使って同時 apply を防ぐ必要がある。
Terraform の利点¶
Terraform の利点は、cloud platform をまたいだ一貫した workflow。 AWS だけでなく、Azure、Google Cloud、Kubernetes、SaaS、on-premises を同じ plan/apply model で扱える。
HCL は review しやすく、module 化により再利用できる。 version control と Pull Request を使えば、infrastructure change を code review に載せられる。 declarative model により、dependency ordering は Terraform が計算するため、manual script より認知負荷が低い。
provider ecosystem と community が大きく、custom platform をゼロから作らずに既存 workflow に載せやすい。
代替ツールとの比較¶
記事では Terraform の代替として Pulumi、AWS CloudFormation、Ansible、OpenTofu が比較される。
Terraform は declarative HCL、multi-cloud provider ecosystem、成熟した shared infrastructure workflow が強み。
Pulumi は TypeScript、Python、Go、C#、Java などの general-purpose language で IaC を書ける。 application code に近い表現力が欲しい場合に向く。
AWS CloudFormation は AWS-native。 AWS resource を stack として model/provision する。 AWS only の組織では強いが、multi-cloud には向かない。
Ansible は provisioning tool というより、configuration management、software deployment、orchestration の印象が強い。 Terraform と置き換えるというより、組み合わせることが多い。
OpenTofu は HashiCorp の license change 後に生まれた Terraform fork。 Terraform configuration との互換性を維持しながら、open-source path を選びたいチームの選択肢。
Terraform がスケールしたときの限界¶
記事が最も強調する operational pain point は state contention。 Terraform は state を write する operation で lock を取る。 これは correctness を守るために必要だが、shared backend では state file 単位の serialization になる。
つまり、同じ state を使う apply があると、無関係な resource 変更でも lock 待ちになる。 安全性のための lock が、チームや pipeline が増えると queue になる。
もう一つの問題は visibility。 file-based state は、一つの stack の変更を見るには十分。 しかし、複数 environment、複数 state file に infrastructure が分散すると、全体でどんな resource が存在するか、resource 間 dependency は何か、変更の blast radius はどこまでかを見づらい。
state file は source of truth である一方、規模が大きくなると operational fragmentation の原因になる。
Stategraph の提案¶
後半は Stategraph の product framing。 Stategraph は Terraform そのものを置き換えるのではなく、backend layer を置き換える。 既存の Terraform CLI、provider、module、configuration file はそのまま使う。
狙いは、Terraform の強みを保ちながら、file-based state と state-level locking の限界を緩和すること。 Stategraph は PostgreSQL-backed structured data として state を扱い、SQL query 可能にする。 また、global state lock ではなく resource-level locking を提供し、unrelated resources の operation を parallel に進めやすくする。
記事では、traditional backend では VPC、Subnets、Security、RDS、ALB、ASG、Route53、CloudFront などが state lock 待ちになりやすい一方、Stategraph では subgraph/resource level で parallel に進むという対比が示されている。
読み替え¶
この記事は Stategraph の product blog なので、Terraform の限界の説明は Stategraph の価値提案に接続されている。 ただし、Terraform state contention と visibility fragmentation は実務でも起きる問題。
小規模では、S3 backend + lock で十分。 team や environment が増えたときに、state file の分割粒度、workspace、module、CI/CD concurrency、plan/apply の queue、state visibility をどう設計するかが重要になる。
Stategraph のような backend replacement を使うかどうかは別として、Terraform が壊れる箇所は provider や HCL より state 運用に出やすい、という点は覚えておく価値がある。
要点¶
- Terraform は HCL、provider、state によって IaC workflow を提供する。
terraform init、plan、applyが基本操作。- provider ecosystem が広く、multi-cloud や SaaS も同じ workflow で扱える。
- state は configuration と real infrastructure の対応を持つため、Terraform の安全性に必須。
- team workflow では remote backend と lock が必要になる。
- state lock は correctness を守るが、規模が大きくなると state file 単位の queue になる。
- 複数 state file に分散すると、全体 visibility と blast radius の把握が難しくなる。
- Pulumi、CloudFormation、Ansible、OpenTofu はそれぞれ違う前提の代替。
- Stategraph は Terraform backend を置き換え、resource-level locking と SQL-queryable state を提供するという提案。