2026-09-04 SRE Tech Talk #15 怠惰なTerraform / Lazy Terraform

https://3-shake.connpass.com/event/402777/ で話した内容

Transcript

1. 怠惰なTerraform / Lazy Terraform 2026-09-04 SRE Tech Talk #15 すずきまさし Copyright © 3-shake, Inc. All Rights Reserved.
2. おまえだれよ • • • すずきまさし/masasuzu/@masasuz 株式会社スリーシェイクSreake事業部シニアアーキテクト クラウドインフラなんでも屋さんをしてます ◦ お客様の外部から ▪ 設計、運用、構築等の技術支援を行います。 ◦ お客様の内部から ▪ インフラチームの一員として内製化支援も行います。 • 得意領域 ◦ AWS ▪ AWS Community Builder Cloud Operation Since 2024~2026 ▪ 2026 Japan All AWS Certifications Engineers ◦ Google Cloud ▪ Google Cloud Partner Top Engineer 2026 ◦ Terraform Copyright © 3-shake, Inc. All Rights Reserved. 2
3. 怠惰 - Lazy • • • • プログラマの三大美徳の 1つ ◦ 怠惰、短期、傲慢 Perl開発者ラリー・ウォールの言葉 全体として必要となる労力を減らすためには努力をおしまないこと あとからめんどくさくなるなるものは先回りして実装整備して、あとあとの面倒を減らす Copyright © 3-shake, Inc. All Rights Reserved. 3
4. 怠惰にTerraformを使いたいでござる
5. 怠惰と横着 • • • • 人間楽をしたいんですよ。 ◦ 私は楽して暮らしたいです。 気をつけたいのは怠惰のために減らすのは眼の前の労力でなく、全体の労力 ◦ 眼の前だけ減らすのは横着であとから利子付きで返済が求められます ◦ トイルが襲ってくるのです 怠惰は先払い、横着は後払い ◦ ただし、必ずしも先払いが正解とは限らないのは留意したい 横着はその場で書けてしまうが、痛みが出るのは先の話なのが厄介なところ Copyright © 3-shake, Inc. All Rights Reserved. 5
6. 怠惰になるためにのコスト • • 項目 項目 Copyright © 3-shake, Inc. All Rights Reserved. 6
7. 01 まず、機械に見つけさせる Copyright © 3-shake, Inc. All Rights Reserved. 7
8. apply で初めて落ちるミスを先に潰す(TFLint) resource "aws_instance" "main" { instance_type = "t1.2xlarge" # invalid type } 無効なインスタンスタイプを指定しています。 validate も plan も 通ります。apply で初めて落ちます。めんどくさいですね。 tflintで事前にわかるものはわかるようにしておく その他以下のものも検出してくれます • 非推奨構文 • 宣言まわりの不備 ◦ 未使用変数 https://github.com/terraform-linters/tflint Copyright © 3-shake, Inc. All Rights Reserved. 8
9. セキュリティ観点の設定ミスを事前に防ぐ(trivy config) セキュリティの指摘も後からされるのはめんどくさいですね。 trivy config(旧tfsec) で先に潰せるものは潰しておきます 以下のものも検出してくれます • S3のパブリックアクセスブロックが有効になってない • S3 の暗号化に CMK を使っていない • Security Groupで0.0.0.0/0が空いている https://github.com/aquasecurity/trivy Copyright © 3-shake, Inc. All Rights Reserved. 9
10. 楽するためにローカルでフックをしかける • • • • git pushしたあとにCIに指摘されて直すのめんどくさいですよ ね。 言われる前に先に気付ける。修正できる仕組みにしておきま す pre-commitを仕掛けることでコミット前に各種チェックを仕掛 けることができます ◦ pre-commit-terraform: https://github.com/antonbabenko/pre-commit-terraf orm ▪ fmt, terraform-docs, trivy configなどをgit pre commit hookに仕掛けてくれます ◦ Coding AgentのHooksでpre-commit runを発火する ようにすれば設定使い回せるはず VS CodeならformatOnSaveでfmtを実行させるようにすると 手動変更のときに楽になります Copyright © 3-shake, Inc. All Rights Reserved. "[terraform]": { "editor.defaultFormatter": "hashicorp.terraform", "editor.formatOnSave": true, "editor.formatOnSaveMode": "file" }, "[terraform-vars]": { "editor.defaultFormatter": "hashicorp.terraform", "editor.formatOnSave": true, "editor.formatOnSaveMode": "file" } 10
11. 人間に見せる前に、機械に見せる • • • • レビューする側もされる側も楽したいのです。機械が見れるところは機械が見てほしい pre-commitは設定されていないと動かないのでゲートにはできないです。 ◦ 最終的にはCIで担保します fmtに関しては指摘されても直すだけなので、そのまま CIにコミットさせます 機械が決定論的にチェックできるものは全部任せて、人間は設計と意図の議論に集中できます Copyright © 3-shake, Inc. All Rights Reserved. 11
12. 02 規約、設計で先回りする Copyright © 3-shake, Inc. All Rights Reserved. 12
13. リソース名を考えたくない resource "aws_lb" "main" {} # そのタイプで唯一なら main resource "aws_instance" "main" { # 複数リソースあるならmapのキー名をつける for_each = var.instances } resource "aws_db_instance" "primary" {} # 複数リソース使いたい特別なときだけ名前付けする resource "aws_db_instance" "replica" {} • • • コンソール上に見えるリソースの名前ではなく、 Terraformの管理上のリソース IDの話です。 基本的にはmainを使用する ◦ 上のレイヤー、モジュールやアプリで名前がついているのでその中で改めて名前をつける必要があ まりない(と感じてます) ただし HashiCorp 公式は main を使えとは言っていません ◦ 言っているのは Google Cloud と AWS のガイダンス Copyright © 3-shake, Inc. All Rights Reserved. 13
14. タグも書きたくない • default_tags(AWS)、default_labels(Google Cloud)をprovierブロックで指定しておけば、設定できるリ ソースに関してはデフォルトでタグ、ラベルを設定してくれます。 provider "google" { project = var.project region = var.region default_labels = { project = var.project managedBy = “Terraform” } } Copyright © 3-shake, Inc. All Rights Reserved. 14
15. ファイル配置も考えたくない • • 基本形 ◦ main.tf ◦ variables.tf ◦ outputs.tf ◦ providers.tf リソースが増えてくるとリソースごとに分けたくなりますが、複数ファイルを見ると見通しが悪くなる +そこま で規模が大きいなら State分割した方がよいかも Copyright © 3-shake, Inc. All Rights Reserved. 15
16. READMEを書きたくない • • • 先述してますが、 terraform-docsでインターフェースドキュメントの自動生成を任せられます TF_DOCSブロックの外に StateやModuleでやることの説明を書きます あとで質問されるよりドキュメントを先に書いたほうがめんどくささが少ないです ◦ 怠惰なので先回りします <!-- BEGIN_TF_DOCS --> <!-- END_TF_DOCS --> Copyright © 3-shake, Inc. All Rights Reserved. 16
17. Stateが大きくなりすぎるとつらい • • • 例えばVPCは一度作ると変更頻度はそんなに高くありません。 ◦ 一方ワークロードに関連するリソースは頻繁に変わりうります ◦ これが同じ state にあると、毎回 変更がないVPC まで巻き込みます。 規模が小さいうちは良いですが大きくなると 1つの変更の影響範囲が広くなります ◦ plan/applyの実行速度が遅くなります ◦ コードの見通しも悪くなります 規模がそれなりに大きくなることを見越しているなら先回りして state分割しておくとよいです Copyright © 3-shake, Inc. All Rights Reserved. 17
18. state分割の観点     変更頻度・ライフサイク ル ステートフル /レス 責任境界 規模・パフォーマンス ステートフルなデータベースと、 ステートレスなワークロードを分 離します。 インフラチーム、開発チームな ど、管理・運用する組織の境界 に合わせます。 planの実行に数分かかるようで あれば、分割を検討する余地が あります。 NetworkとWorkloadなど変更頻 度、ライフサイクルは違うものを まず考えます。  ただし、分けすぎると複雑性を生みます • state間の依存関係が複雑化するリスク • applyの実行順序管理が複雑化するリスク Copyright © 3-shake, Inc. All Rights Reserved. 18
19. 個人的にはこの分け方にすることが多い • • • • Network(VPC, Subnet, Route) Database(RDS, ElastiCache) ◦ 取り回しによっては Workloadに含めるときもある Workload(ALB, ECS, Security Group) Monitoring Copyright © 3-shake, Inc. All Rights Reserved. 19
20. 03 記述量を減らす(Terragrunt) Copyright © 3-shake, Inc. All Rights Reserved. 20
21. provider と backend を毎回書きたくない # root.hcl に1回だけ書く remote_state { backend = "s3" config = { key = "${path_relative_to_include()}/terraform.tfstate" } } generate "provider" { path = "provider.tf" ... } • • • 素の Terraform では backend に変数が使えません。それゆえに毎回ベタに書かないとなりません ◦ Terragruntを使うといい感じに自動生成してくれ、記述量が減ります ◦ OpenTofuなら、、、 dependency + run --all で、apply の順序も手で管理しなくて済みます ◦ 実行順をよしなに判断してくれます Terragruntは便利なのですが、説明するには 30分くらい語れるのでまたの機会に Copyright © 3-shake, Inc. All Rights Reserved. 21
22. 環境ごとにディレクトリをコピーしたくない • • • 素直に書くと環境 *Stateの掛け算でディレクトリが増殖します 環境追加するごとにコピペして、差分箇所を修正する形になります Terragrunt Stacks使うことでunitとenvの組み合わせで Stateを増やせるので組み合わせ起きない Copyright © 3-shake, Inc. All Rights Reserved. 22
23. 04 まとめ Copyright © 3-shake, Inc. All Rights Reserved. 23
24. 怠惰は先払い、横着は後払い • • • グラフ画像はイメージです (Claudeさん作) 何も根拠はないですが、感覚値としては合ってる気がします 逆に言うと後払い利率が低いものであれば横着がより正しい場面もある Copyright © 3-shake, Inc. All Rights Reserved. 24
25. まとめ • • • 怠惰は全体の労力を減らすこと。目の前の労力を減らすのは横着です ◦ 後払いで痛い目見ます 決定論的なレビューの指摘は機械に任せられます。 fmt → validate → tflint → trivy config ◦ 怠惰な人間は設計レビューに集中します 機械に強制できるのは形の揃え方まで。その先はチームが決める規約です ある程度の規模が見えてるなら State分割を最初から視野に入れるとよいです terragruntを使うと怠惰の極みになります • 各トピックに関してざっくりしか話していないので細かいところはブログに書きます • • Copyright © 3-shake, Inc. All Rights Reserved. 25
26. 怠惰にTerraformを使いたいでござる