こんにちは、AWSグループの長友です。
（あだ名：アミーゴ ← 呼ばれてない）
先日、他ベンダーさんのイベントにご招待をいただきまして、名古屋で発表してきました。
味噌カツが美味しかったです。あと夜のイベントも...。
また行きたいです。
今日は当日お話しした内容から、Terraformを触る中で、現場で実際に踏んだ地雷 と、そこから得た学びをまとめます。
これからTerraformを始める冒険者の方のために
これからTerraformを始める冒険者の方のために、そして既にTerraformを触っている熟練冒険者の方は「あるある…」って頷いてもらえたらうれしいです。
先に結論：Terraform標準化・三大教訓
いきなり結論からいきます。私の学びはこの3つです！
- ディレクトリは冷蔵庫： 整理しないと腐る（定期的に整理整頓）
- モジュールはレンタカー感覚で： 使い回し前提でメンテコストを減らす
- stateは命： 人の記憶に頼るな、適切な管理が全ての土台
……これだけ覚えて別の記事を読んでください
（ナガトモ・期末テストに出します）。
Terraformを書いたら動いた。だがそれは地獄の始まりだった...。
Terraformを触り始めたとき、だいたいこう思いません？
「とりあえず全部 main.tf に書けばいいよね」
最初は動くんです。planも通るしapplyも成功する。
「あ、理解した（してない）」の瞬間。
でも現実はこう。
「git diff が真っ赤。どこ修正したか分からん。誰が変更加えたんだ…？」
（※ 実は私）
インフラ管理は“動く”だけじゃ不十分なんですよね。
単一ファイル詰め込みは、最初は楽。でもチーム開発に入った瞬間に破綻します。
こんな↑悲劇映画の幕が上がる前に立ち止まって考えてみてください！
みんな違ってみんないい（のか？）——ディレクトリ統制が崩れる瞬間
Terraformって、ディレクトリ構成の自由度が高すぎます。
結果、チームが分かれるとこうなります。
知識共有もメンテも困難に。
「みんなちがってみんないい」…じゃないんですよね、たぶん。
ディレクトリは冷蔵庫、整理しないと腐る
私の中で一番しっくり来た例えがこれ。
- 整理された冷蔵庫： どこに何があるか一目瞭然／腐らない／料理が速い
- ぐちゃぐちゃ冷蔵庫： 何があるか不明／気づいたら腐る／探してる間に心が折れる
Terraformも同じで、最初から仕切りを作る＋定期リファクタが必要です。
規模に応じた分割戦略（仕切りを増やせばいいわけでもない）
小規模なら、シンプルでOK。過度な分割は逆効果です。
逆に大規模では、責任範囲が曖昧だとコンフリクト祭りが始まります。
ポイント
- 小規模： 1段構成でOK。迷わないのが正義
- 大規模： 棚ごとに分割して、責任範囲を明確に
- 万能モジュールは闇鍋: 詰め込みすぎは地獄
次の地雷はモジュール設計
便利そうに見えて、やりがちな例をご紹介します。
これで何が起きるかというと、
- 変更影響がデカすぎる
- 再利用性が落ちる
- テストが複雑
- 見通しが悪い
でプロジェクトが破綻します。
単一責任の原則は、ほんと大事で「モジュールは小さく、目的を明確に」が正義です。
車を作るか、レンタカーを借りるか
内部モジュールとパブリックモジュールに関しては、車を当てはめるとシックリきます。
内部モジュール＝マイカーは、カスタム性があり、自由ですが整備は自分でやらないといけません。これに対して、パブリックモジュール＝レンタカーは、すぐ使えるけど、制約があります。
アプリケーション開発の場合も、全部自作すると、愛着は湧くけど手間も増えます。一方で、パブリックモジュールはうまく使うと運用が軽くなるので、可能なら活用がおすすめです。
ただし：パブリックモジュールは「選んで使え！」を強調したいです。
メンテされてないモジュールは、普通に危ないです。
- 最終更新が2年前
- Issue放置
- 古いTerraformバージョン前提
ブラインドインストールせずに、更新頻度／コミュニティ／ドキュメントは必ずチェックしましょう。
State管理は生命線
最後に、State 管理の話をします。キーワードは、
「ローカルに置くな！Gitにコミットするな！」
Terraformの state（terraform.tfstate）は、インフラの現状が詰まった命のファイルです。
しかもセンシティブな情報が入ることもあります。
適切に管理しないと、チーム全体の作業に大きな影響を与えます。
NGなStateの運用例
- ローカル保存している
- Gitにコミットしている
- チームで共有されない
Stateは、S3や、コストをかけることができるなら、HCP Terraform（旧Terraform Cloud）を利用し、適切な権限管理をしましょう。
State分割戦略：「正解は“人が迷わない単位”】【環境別／サービス別／レイヤー別】
では、Stateはどこで分けるべきか？ よくある分割はこの3つです。
- 環境別（dev/stg/prod）： シンプルでオペミスが起きにくい
- サービス別： State肥大化を抑え、衝突しにくい
- レイヤー別： ネットワーク層／アプリ層などで責任分界点を明確に
ブログや記事を見ると「これが正解！」って流派が分かれますが、結局のところ現場の人が迷わない単位が正解だと思います。
まとめ: IaCは「コード」より「運用設計」が命
Terraformは Infrastructure as Code。でも Infrastructure as Teamwork にしないと壊れます。
ここまでをまとめます。
- 環境分離： backend設定は必ず環境ごとに分ける
- 追跡可能性： 「壊した本人が分からない環境」より怖いものはない
- 自動化： CI/CD経由で安全性を確保する
最後にもう一度！三大教訓。
- ディレクトリは冷蔵庫（腐らせない）
- モジュールはレンタカー感覚（メンテコスト減）
- stateは命（人の記憶に頼らない）
このキーワードを踏まえて、Terraformを IaF（Infrastructure as Fun） に！
ここまで読んでいただきありがとうございました！
