Terraform/Terragruntで実現する Feature Flag

CloudNative Days Summer 2025 LTにて発表させて頂いた資料です。

Transcript

1. Terraform/Terragruntで実現する Feature Flag DATUM STUDIO株式会社 志田 遼太郎 2025年5月23日 @CloudNative Days Summer 2025
2. 2 whoami DATUM STUDIO株式会社 データエンジニア 志田 遼太郎 普段は受託開発でデータ分析基盤を作ってます
3. Terraformとは
4. Terraformとは 様々なクラウドインフラを管理可能なIaCツール https://developer.hashicorp.com/terraform/intro
5. 5 Terraformとは IaC（Infrastructure as Code） • インフラ構成をコードで記述し、リリースする手法 • インフラリリース作業者/確認者は手作業でのインフ ラ構築から解放され、様々なメリットを享受できる ✓ 作業上のヒューマンエラーの軽減 ✓ 作業スピードの向上 ✓ 保守性の向上 クラウド、およびオンプレミスのリソースを、人間が読める構成ファイルで定義可能なIaCツール。 EC2での例 resource "aws_instance" ”this" { ami = "ami-123456" instance_type = "t3.micro" }
6. 6 Terraformとは IaC（Infrastructure as Code） • インフラ構成をコードで記述し、リリースする手法 • インフラリリース作業者/確認者は手作業でのインフ ラ構築から解放され、様々なメリットを享受できる ✓ 作業上のヒューマンエラーの軽減 ✓ 作業スピードの向上 ✓ 保守性の向上 クラウド、およびオンプレミスのリソースを、人間が読める構成ファイルで定義可能なIaCツール。 EC2での例 resource "aws_instance" ”this" { ami = "ami-123456" instance_type = "t3.micro" } うれしい
7. Terragruntとは
8. Terragruntとは Terraformを拡張するオーケストレーションツール https://terragrunt.gruntwork.io/
9. 9 Terragruntとは 依存関係を考慮した複数モジュールの一括実行 terraformを記述する上での重複コードの低減、モジュール間依存関係の管理、複数モジュールの一括実行 など、Terraform（および、OpenTofu）を拡張するツール GitHub Actions network 1 database 1 server 1 storage 1 Terraform Terragrunt network 2 database 2 server 2 terraform GitHub Actions network 1 database 1 server 1 storage 1 network 2 database 2 server 2 terragrunt → CI/CDで定義 → terragruntで定義 stack 1 stack 2 stack 3
10. 10 Terragruntとは 依存関係を考慮した複数モジュールの一括実行 terraformを記述する上での重複コードの低減、モジュール間依存関係の管理、複数モジュールの一括実行 など、Terraform（および、OpenTofu）を拡張するツール GitHub Actions network 1 database 1 server 1 storage 1 Terraform Terragrunt network 2 database 2 server 2 terraform GitHub Actions network 1 database 1 server 1 storage 1 network 2 database 2 server 2 terragrunt → CI/CDで定義 → terragruntで定義 stack 1 stack 2 stack 3 結構 うれしい
11. Feature Flagとは
12. Feature Flagとは コードの変更なしでシステムの動作を変更できる手法 https://martinfowler.com/articles/feature-toggles.html
13. 13 Feature Flag (Feature Toggle) とは 主な用途 • カナリアリリース • A/Bテスト • など… メリット • 実装の仕方によってはコードの変更なしで機能の切 り替えが可能 • CI/CDパイプライン側を変えなくて良い • 障害対応や切り戻しの観点で、取り扱いがしやすい コードの中で特定の機能を（動的に）有効化・無効化できる手法 var enable_new_function = false # これを動的に変更できる仕組みがあると嬉しい if( enable_new_function ){ return new_function(); } else { return old_function(); } 極限まで簡単にした例
14. 14 Feature Flag (Feature Toggle) とは 主な用途 • カナリアリリース • A/Bテスト • など… メリット • 実装の仕方によってはコードの変更なしで機能の切 り替えが可能 • CI/CDパイプライン側を変えなくて良い • 障害対応や切り戻しの観点で、取り扱いがしやすい コードの中で特定の機能を（動的に）有効化・無効化できる手法 var enable_new_function = false # これを動的に変更できる仕組みがあると嬉しい if( enable_new_function ){ return new_function(); } else { return old_function(); } 極限まで簡単にした例 うれしい
15. Feature Flagは ソフトウェア開発の文脈で提唱され発展したが・・・
16. Feature Flagは ソフトウェア開発の文脈で提唱され発展したが・・・ IaCの普及により、インフラにもFeature Flagの概念 が適用できるのでは？
17. 17 モチベーション インフラ機能追加の際 に、dev→stg→prdのよ うに、段階的に適用した い 設定変更時、何かあっ たらすぐに切り戻しをした い モジュール自体を個別 にバージョン管理し、利 用時にバージョンを動的 に指定したい 環境ごとの差分設定を コピペ少なめで簡単に 管理したい 追加機能ごとにprd適 用タイミングをずらしたい
18. 実装
19. 19 [パラメータレベル] 変数 + 三項演算子を利用したFeature Flag terraformは宣言型の言語なため、通常のプログラミング言語のように複雑な条件分岐はできないが、三項 演算子と呼ばれる記述で特定の変数の値に応じてセットするパラメータを変えることが可能 resource "aws_instance" ”this" { ami = "ami-123456" instance_type = var.env == “prd”? "t3.2xlarge”: “t3.micro” } ✓ リリース対象環境を示す変数 （var.env）の値に応じて instance_typeを変更することができる Terraform 別のリソースの値によっ て特定のパラメータの設 定値を変えたい・・・
20. 20 [リソースレベル] countを利用したFeature Flag 補足情報 • terraformは環境変数 （TF_VAR_flag_enable_ec2）を設定する ことで変数を与えられる terraformではcountという、設定することで同一リソースを指定数分繰り返し構築するパラメータがあり、こ れを利用することでFeature Flagとして機能する variable “flag_enable_ec2” { type = bool } resource "aws_instance" ”this" { count = var.flag_enable_ec2 == true ? 1 : 0 ami = "ami-123456" instance_type = "t3.2xlarge” } ✓ countパラメータはリソースをいくつ作成する かを制御でき、0が指定された場合はリソース を作成しない、という挙動をとる Terraform 環境変数を管理できるCI/CDツールであれば、コードを 変更することなくリリース対象リソースの制御が可能 環境や状況に応じて特 定リソースのリリース有 無を制御したい
21. 21 [リソースレベル] for_eachを利用したFeature Flag 補足情報 • csvやyamlからbucket_mapを生成する組み込 み関数が用意されており、人間に理解しやすい構 成を取ることが可能 terraformではfor_eachという、一部パラメータのみが異なる同一リソースを簡易に管理する機能があり、 パラメータ生成時にif文が使えるためこれを利用することでFeature Flagとして機能する resource "aws_s3_bucket" ”this" { for_each = { for item in var.bucket_map : item[“name”] => item if item[“env”] == var.env } bucket = each.value[“name”] } prd環境ではsample1, sample2というバケットが、 dev環境ではsample3というS3バケットが作られる Terraform 環境間差分を人間に理解しやすい形で管理でき、 コード本体の修正が不要 bucket_map = [ {“env” = “prd”, “name” = “sample1”}, {“env” = “prd”, “name” = “sample2”}, {“env” = “dev”, “name” = “sample3”}, ] 環境ごとのリソース差分 をコピペ少なめで簡単に 管理したい・・・
22. 22 [オーケストレーションレベル] featureブロックを利用したFeature Flag 補足情報 • 環境変数TG_FEATUREを設定することで外部か ら変数を与えられる terragruntの設定ファイルのレベルでFeature Flagを利用できる Terragrunt 環境変数を管理できるCI/CDツールであれば、コードを 変更することなくリリース対象リソースの制御が可能 terragruntを使ってもっ と柔軟にterraformを制 御したい・・・ featureブロック • terragruntはterraformの外での処理が可能 • 例えば、terraform実行前にシェルでコマンドを実行できる（before_hook） • これらのterragrunt独自機能に対するFeature Flagとして、featureブロックが用意されている ※コードは初見での分かりにくさと時間の都合で省略します
23. 23 [モジュールレベル] excludeブロックを利用したFeature Flag terragruntで定義するstackから、特定モジュールを一時的に外すことが可能 Terragrunt featureブランチで開発 を進めるから、一時的に CI/CDでterraformを実 行したくない・・・ excludeブロック • terragruntが定義するstackから、特定の条件の場合に特定のモジュールを除外する • 「特定の条件」を、featureブロックで記述可能 => 環境変数でstackからの除外を制御可能 • 特にCI/CDパイプラインにおいて効果を発揮し、リリースフローを担保しつつ柔軟な制御が可能（うれしい） ※コードは初見での分かりにくさと時間の都合で省略します network database server monitoring ✓ enable_monitoringフラグがtrueであればstackの要 素であるとみなされ、plan/applyが実行される ✓ フラグがfalseであればterraform実行対象にならない
24. 結び
25. 25 結び • クラウドインフラはIaC + CI/CDパイプラインで管理しよう！ • インフラ管理がコード化することにより、ソフトウェア開発で主に扱われてきた概念や手法を取り入れることが可能 • 扱う基盤やサービスレベルによっても状況は異なるはず ぼくのかんがえたさいきょうのデプロイ・リリースフローを作ろう！！
26. Appendix
27. 27 [パラメータレベル] 変数 + 三項演算子を利用したFeature Flag こんな時に・・ • 環境によって特定のリソースの特定のパラメータの設 定値を変えたい（※） • リソース定義の際の例外的な処理 • optionalなパラメータを、別の特定の値に応じて設 定する/しないを分岐するなど 補足情報 • 基本的なterraformの思想として、こういった環境 間差分のあるパラメータは外部から与える形にした ほうが良い（モジュールを関数と見立てた時、関数 に対する引数のイメージ） terraformは宣言型の言語なため、通常のプログラミング言語のように複雑な条件分岐はできないが、三項 演算子と呼ばれる記述で特定の変数の値に応じてセットするパラメータを変えることが可能 resource "aws_instance" ”this" { ami = "ami-123456" instance_type = var.env == “prd” ? "t3.2xlarge” : “t3.micro” } ✓ リリース対象環境を示す変数 （var.env）の値に応じて instance_typeを変更することができる Terraform
28. 28 [リソースレベル] countを利用したFeature Flag こんな時に・・ • 環境や状況に応じて特定リソースのリリース有無を 制御したい 補足情報 • terraformはモジュール呼び出し時の記述で変数 を与えることができるほか、環境変数（例だと TF_VAR_flag_enable_ec2）を設定するこ とで変数をセットできる terraformではcountという、設定することで同一リソースを指定数分繰り返し構築するパラメータがあり、こ れを利用することでFeature Flagとして機能する variable “flag_enable_ec2” { type = bool } resource "aws_instance" ”this" { count = var.flag_enable_ec2 == true ? 1 : 0 ami = "ami-123456" instance_type = "t3.2xlarge” } ✓ countパラメータはリソースをいくつ作成する かを制御でき、0が指定された場合はリソース を作成しない、という挙動をとる Terraform 環境変数を管理できるCI/CDツールであれば、コードを 変更することなくリリース対象リソースの制御が可能
29. 29 [リソースレベル] for_eachを利用したFeature Flag こんな時に・・ • 環境ごとの差分設定をコピペ少なめで簡単に管理 したい 補足情報 • csvやyamlからbucket_mapを生成する組み込 み関数が用意されており、人間に理解しやすい構 成を取ることが可能 terraformではfor_eachという、一部パラメータのみが異なる同一リソースを簡易に管理する機能があり、 パラメータ生成時にif文が使えるためこれを利用することでFeature Flagとして機能する resource "aws_s3_bucket" ”this" { for_each = { for item in var.bucket_map : item[“name”] => item if item[“env”] == var.env } bucket = each.value[“name”] } prd環境ではsample1, sample2というバケットが、 dev環境ではsample3というS3バケットが作られる Terraform 環境間差分を人間に理解しやすい形で管理でき、 コード本体の修正が不要 bucket_map = [ {“env” = “prd”, “name” = “sample1”}, {“env” = “prd”, “name” = “sample2”}, {“env” = “dev”, “name” = “sample3”}, ]
30. 30 [オーケストレーションレベル] featureを利用したFeature Flag 補足情報 • terragruntはtf実行前にコマンドを実行できる • 環境変数TG_FEATUREを設定することで外部 から変数を与えられる terragruntの設定ファイルのレベルでFeature Flagを利用できる feature "run_hook" { default = false } feature ”in" { default = false } terraform { before_hook "feature_flag" { commands = ["apply", "plan", "destroy"] execute = feature.run_hook.value ? <feature.inを書き換え るculrコマンドとか・・> : [“exit 0”] } } inputs = { tf_var = feature.in.value Terragrunt 環境変数を管理できるCI/CDツールであれば、コードを 変更することなくリリース対象リソースの制御が可能 terragruntを使ってもっ と柔軟にterraformを制 御したい・・・