この記事から得られる知識この記事を読むと、以下を "完全に理解" できます✌️Terraformのtfstateファイルを分割する目的と、分割パターンについて (AWS向け)Terraformのリポジトリやリモートバックエンドのディレクトリー構成の設計についてこの記事から得られる知識01. はじめに02. なぜ tfstate ファイルを分割するのか分割していない場合分割している場合03. tfstate ファイルの分割分割の境目状態の依存関係図依存関係図とは依存関係の表現▼ 依存関係の表現記法▼ 依存関係がない場合▼ 依存関係がある場合04. tfstate ファイルに基づくその他の設計リポジトリ 🏭 の設計リポジトリ分割ディレクトリー 📂 構成リモートバックエンド 🪣 の設計リモートバックエンド分割ディレクトリー構成05. 状態の依存関係の定義方法terraform_remote_stateブロックの場合terraform_remote_stateブロックによる依存状態の依存関係図リポジトリのディレクトリー構成リモートバックエンドのディレクトリー構成AWSリソース別のdataブロックの場合AWSリソース別のdataブロックによる依存状態の依存関係図リポジトリのディレクトリー構成リモートバックエンドのディレクトリー構成06. tfstate ファイルの分割パターンオススメな設計の一覧ディレクトリー構成との関係についてリポジトリの場合リモートバックエンドの場合07. 上層の分割 (必須)上層の分割についてプロバイダーのアカウント別 - ★★この分割方法について【プロバイダーアカウント別】状態の依存関係図【プロバイダーアカウント別】リポジトリのディレクトリー構成▼ 異なるリポジトリの場合▼ 同じリポジトリの場合【プロバイダーアカウント別】リモートバックエンドのディレクトリー構成▼ 異なるリモートバックエンドの場合▼ 同じリモートバックエンドの場合08. 下層の分割 (必須)下層の分割について実行環境別 - ★★この分割方法について【実行環境別】状態の依存関係図【実行環境別】リポジトリのディレクトリー構成▼ 異なるリポジトリの場合▼ 同じリポジトリの場合【実行環境別】リモートバックエンドのディレクトリー構成▼ 異なるリモートバックエンドの場合▼ 同じリモートバックエンド x AWSアカウント別に異なる実行環境の場合▼ 同じリモートバックエンド x 単一のAWSアカウント内に全ての実行環境の場合09. 中間層の分割 (任意)中間層の分割について同じテナントのプロダクト別この分割方法について【同じテナントのプロダクト別】状態の依存関係図【同じテナントのプロダクト別】リポジトリのディレクトリー構成▼ 異なるリポジトリの場合▼ 同じリポジトリの場合【同じテナントのプロダクト別】リモートバックエンドのディレクトリー構成▼ 異なるリモートバックエンドの場合▼ 同じリモートバックエンドの場合運用チーム責務範囲別 - ★この分割方法について【チーム別】状態の依存関係図【チーム別】リポジトリのディレクトリー構成▼ 異なるリポジトリの場合▼ 同じリポジトリの場合【チーム別】リモートバックエンドのディレクトリー構成▼ 異なるリモートバックエンドの場合▼ 同じリモートバックエンドの場合プロダクトのサブコンポーネント別 - ★この分割方法について【サブコンポーネント別】状態の依存関係図【サブコンポーネント別】リポジトリのディレクトリー構成▼ 異なるリポジトリの場合▼ 同じリポジトリの場合【サブコンポーネント別】リモートバックエンドのディレクトリー構成▼ 異なるリモートバックエンドの場合▼ 同じリモートバックエンドの場合AWSリソースの種類グループ別この分割方法について【種類グループ別】状態の依存関係図【種類グループ別】リポジトリのディレクトリー構成▼ 異なるリポジトリの場合▼ 同じリポジトリの場合【種類グループ別】リモートバックエンドのディレクトリー構成▼ 異なるリモートバックエンドの場合▼ 同じリモートバックエンドの場合AWSリソースの状態の変更頻度グループ別この分割方法について【変更頻度グループ別】状態の依存関係図【変更頻度グループ別】リポジトリのディレクトリー構成▼ 異なるリポジトリの場合▼ 同じリポジトリの場合【変更頻度グループ別】リモートバックエンドのディレクトリー構成▼ 異なるリモートバックエンドの場合▼ 同じリモートバックエンドの場合運用チーム責務範囲別 × プロダクトサブコンポーネント別 - ★この分割方法について【チーム別 × サブコンポーネント別】状態の依存関係図【チーム別 × サブコンポーネント別】リポジトリのディレクトリー構成▼ 異なるリポジトリの場合▼ 同じリポジトリの場合【チーム別 × サブコンポーネント別】リモートバックエンドのディレクトリー構成▼ 異なるリモートバックエンドの場合▼ 同じリモートバックエンドの場合10. おわりに謝辞01. はじめに前世でもう少し徳を積んでいれば、Mitchell Hashimoto として生まれることができたのに!!さて最近の業務で、全プロダクトの技術基盤開発チームに携わっており、チームが使っているTerraform🧑🏻‍🚀のリポジトリをリプレイスする作業を担当しました。このリポジトリでは単一のtfstateファイルが状態を持ち過ぎている課題を抱えていたため、課題に合った適切な分割パターンでリプレイスしました。今回は、この時に整理した分割パターン (AWS向け) を記事で解説しました。もちろん、GoogleCloudやAzureでも読み換えていただければ、同じように適用できます。知る限りの分割パターンを記載したところ、情報量がエグいことになってしまったため、気になる分割パターンだけ拾って帰っていただけるとハッピーです🙏それでは、もりもり布教していきます😗02. なぜ tfstate ファイルを分割するのか%%{init: { 'theme': "default", 'themeVariables': { 'commitLabelFontSize': '13px' }}}%%gitGraph commit id: "8c8e6" commit id: "0e3c3" branch feature/foo checkout feature/foo commit id: "4e9e8" commit id: "fooさんがApply" checkout main branch feature/bar commit id: "barさんがPlan" checkout main commit id: "e74d6" branch feature/baz commit id: "bazさんがPlan"分割していない場合そもそも、なぜtfstateファイルを分割する必要があるのでしょうか。tfstateファイルを分割しなかったと仮定します。様々なインフラコンポーネントを単一のtfstateファイルで状態を持つ場合、1回のterraformコマンド全てのコンポーネントの状態を操作できて楽です。ただし、複数の作業ブランチがある状況だと煩わしいことが起こります。各作業ブランチでインフラコンポーネントの状態を変更しかけていると、terraformコマンドでtargetオプションが必要になります。分割している場合その一方で、tfstateファイルをいい感じに分割したと仮定します。各作業ブランチでは、まるで暗黙的にtargetオプションがついたように、他の作業ブランチの影響を受けずにterraformコマンドを実行できます。よって、各tfstateファイルを操作できる管理者は互いに影響を受けずに、terraformコマンドの結果を得られるようになります。Terraform: Up & Running: Writing Infrastructure As CodeOrganizing With Multiple States - DevOps with Terraform - CloudCasts03. tfstate ファイルの分割分割の境目それでは、tfstateファイルの分割の境界はどのようにして見つければよいのでしょうか。これを見つけるコツは、他の状態にできるだけ依存しないリソースの関係に注目することだと考えています。ここでいう依存とは、tfstateファイルが他のtfstateファイルの状態を使用することです。tfstateファイルの分割パターンについては後述します。アーキテクチャの文脈では、他を使用することを『依存』と表現します。そのため便宜上、tfstateファイルでも同じ用語で表現することにしました。@tmknom さんが述べている通り、Terraformをよりよく設計するためには、『ソフトウェアの基礎知識』が必要です👍状態の依存関係図依存関係図とは分割したtfstateファイル間の状態の依存関係を表現した図です。プロバイダーのアカウントの状態をtfstateファイルで管理していることを想像してみてください。%%{init:{'theme':'default'}}%%flowchart TB subgraph AWSアカウント foo["tfstateファイル"] end似たものとしてterraform graphコマンドによるグラフがありますが、これはリソース間の依存関係図です。tfstateファイル間で相互に依存関係があるからといって、個別のリソース間で循環参照が起こってしまうというわけではないです。続いて、依存関係がある場合と無い場合で、どのような依存関係図になるかを紹介していきます。Command: graph | Terraform | HashiCorp Developer依存関係の表現▼ 依存関係の表現記法tfstateファイル間で状態の依存関係がある場合、これを図で表現すると分割の状況がわかりやすくなります。『依存』は、---> (波線矢印) で表現することとします。設定値の参照数が少ないほどよいです。依存関係がある場合については、後述します。アーキテクチャの文脈では、『依存』を---> (波線矢印) で表現します。そのため便宜上、tfstateファイルでも同じ記号で表現することにしました👍▼ 依存関係がない場合例えば、AWSリソースからなるプロダクトをいくつかのtfstateファイル (foo-tfstate、bar-tfstate) に分割したと仮定します。ここで仮定した状況では、 tfstate ファイル間に依存関係はないとします。そのため、想定される状態の依存関係図は以下の通りになります。tfstateファイル間に依存関係がない状況がベストです。---title: tfstateファイル間に依存関係はない---%%{init:{'theme':'default'}}%%flowchart TB subgraph AWSアカウント foo["foo-tfstate"] bar["bar-tfstate"] end▼ 依存関係がある場合同様に分割したと仮定します。ここで仮定した状況では、 foo-tfstate ➡︎ bar-tfstate の方向に依存しているとします。そのため、---> (波線矢印) を使用して、想定される状態の依存関係図は以下の通りになります。なお、依存方向は状況によって異なることをご容赦ください。---title: foo-tfstateファイルは、bar-tfstateファイルに依存---%%{init:{'theme':'default'}}%%flowchart TD subgraph AWSアカウント foo["foo-tfstate"] bar["bar-tfstate"] end foo -. 依存 .-> bar04. tfstate ファイルに基づくその他の設計リポジトリ 🏭 の設計リポジトリ分割ここまでで、tfstateファイル分割について簡単に紹介しました。リポジトリの分割は、tfstateファイル分割に基づいて設計しましょう。異なるリポジトリにtfstateファイルをおいた方がよい場合については、分割パターンで説明しています。🏭 foo-repository/├── backend.tf # fooコンポーネントの状態を持つ terraform.tfstate ファイルを指定する...🏭 bar-repository/├── backend.tf # barコンポーネントの状態を持つ terraform.tfstate ファイルを指定する...ディレクトリー 📂 構成リポジトリ内のディレクトリー構成も、tfstateファイル分割に基づいて設計しましょう。率直に言うと、Terraformのディレクトリー構成のパターンは無数にあります。そのため、基準なしにディレクトリー構成を考えると何でもありになってしまいます。その一方で、tfstateファイル分割に基づいて設計することにより、明確なディレクトリー構成パターンとして抽出可能になります。🏭 repository/├── 📂 foo/│ ├── backend.tf # fooコンポーネントの状態を持つ terraform.tfstate ファイルを指定する│ ...│└── 📂 bar/ ├── backend.tf # barコンポーネントの状態を持つ terraform.tfstate ファイルを指定する ...Terraformには、そのリポジトリ内だけでブロック (例：resource、data) のセットを使い回すことを目的とした、ローカルモジュールがあります。今回、これのディレクトリー構成は設計に含めていません。混同しやすいのですが、tfstateファイル分割に基づくディレクトリー構成とローカルモジュール内のそれは、全く別のテーマとして切り離して考えることができます👍リモートバックエンド 🪣 の設計リモートバックエンド分割本記事では、リモートバックエンドとしてAWS S3バケットを使用することを想定しています。リモートバックエンドの分割は、tfstateファイル分割に基づいて設計しましょう。異なるリモートバックエンドにtfstateファイルをおいた方がよい場合については、分割パターンで説明しています。🪣 foo-bucket/│└── terraform.tfstate # fooコンポーネントの状態を持つ🪣 bar-bucket/│└── terraform.tfstate # barコンポーネントの状態を持つディレクトリー構成リモートバックエンド内のディレクトリー構成も、tfstateファイル分割に基づいて設計しましょう。🪣 bucket/├── 📂 foo/│ └── terraform.tfstate # fooコンポーネントの状態を持つ│└── 📂 bar/ └── terraform.tfstate # barコンポーネントの状態を持つ05. 状態の依存関係の定義方法terraform_remote_stateブロックの場合terraform_remote_stateブロックによる依存terraform_remote_stateブロックには、以下のメリデメがあります。アーキテクチャ特性メリット ⭕️ デメリット × 可読性 - terraform_remote_stateブロックに加えてoutputブロックも実装が必要であり、outputブロックは依存先のAWSリソースが一見してわかりにくい。拡張性依存先のAWSリソースに関わらず、同じterraform_remote_stateブロックを使い回せる。 - 保守性 - 依存先と依存元の間でTerraformのバージョンに差がありすぎると、tfstateファイル間で互換性がなくなり、terraform_remote_stateブロックの処理が失敗する。本記事では、 terraform_remote_state ブロックを使用して、状態の依存関係を定義していきます。tfstateファイルが他のtfstateファイルに依存する方法として、後述のAWSリソース別のdataブロックがあります。The terraform_remote_state Data Source | Terraform | HashiCorp Developer状態の依存関係図例えば、AWSリソースからなるプロダクトをいくつかのtfstateファイル (foo-tfstate、bar-tfstate) に分割したと仮定します。ここで仮定した状況では、bar-tfstateファイルはVPCの状態を持っており、 foo-tfstate ファイルは bar-tfstate ファイルに依存しているとします。そのため、想定される状態の依存関係図は以下の通りになります。なお、依存方向は状況によって異なることをご容赦ください。---title: terraform_remote_stateブロックを使用した依存関係---%%{init:{'theme':'default'}}%%flowchart TD subgraph bucket foo["foo-tfstate"] bar["bar-tfstate"] end foo -. VPCの状態に依存 .-> barリポジトリのディレクトリー構成tfstateファイル分割に基づいて、リポジトリのディレクトリー構成例は以下の通りになります。ディレクトリーの設計方法は、分割パターンで説明しています。🏭 repository/├── 📂 foo/│ ├── backend.tf # fooコンポーネントの状態を持つ terraform.tfstate ファイルを指定する│ ├── remote_state.tf # terraform_remote_stateブロックを使用し、bar-tfstate ファイルに依存する│ ├── provider.tf│ ...│└── 📂 bar/ ├── backend.tf # barコンポーネントの状態を持つ terraform.tfstate ファイルを指定する ├── output.tf # 他の tfstate ファイルから依存される ├── provider.tf ...foo-tfstateファイルがbar-tfstateファイルに依存するために必要な実装は、以下の通りになります。# fooリソースの状態は、bar-tfstate ファイルで持つresource "example" "foo" { # fooリソースは、bar-tfstate ファイルのVPCに依存する vpc_id = data.terraform_remote_state.bar.outputs.bar_vpc_id ...}# VPCの状態は、bar-tfstate ファイルで持つdata "terraform_remote_state" "bar" { backend= "s3" config = { bucket = "bar-tfstate" key = "bar/terraform.tfstate" region = "ap-northeast-1" }}# VPCの状態は、bar-tfstate ファイルで持つoutput "bar_vpc_id" { value = aws_vpc.bar.id}resource "aws_vpc" "bar" { ...}リモートバックエンドのディレクトリー構成tfstateファイル分割に基づいて、リモートバックエンド内のディレクトリー構成例は以下の通りになります。🪣 bucket/├── 📂 foo│ └── terraform.tfstate # fooコンポーネントの状態を持つ│└── 📂 bar └── terraform.tfstate # barコンポーネントの状態を持つAWSリソース別のdataブロックの場合AWSリソース別のdataブロックによる依存dataブロックには、以下のメリデメがあります。アーキテクチャ特性メリット ⭕️ デメリット × 可読性依存先のAWSリソースがわかりやすい。 - 拡張性 - 依存先のAWSリソース別にdataブロックが必要である。保守性依存先と依存元の間でTerraformのバージョンに差があっても、tfstateファイル間で直接的に依存するわけではないため、バージョン差の影響を受けない。 - 今回は使用しませんが、依存関係の他の定義方法として、AWSリソース別のdataブロックがあります。これは、tfstateファイルが自身以外 (例：コンソール画面、他のtfstateファイル) で作成されたAWSリソースの状態に依存するために使用できます。terraform_remote_stateブロックとは異なり、直接的にはtfstateファイルに依存しません。dataブロックの場合は、実際のAWSリソースの状態に依存することにより、間接的にAWSリソースのtfstateファイルに依存することになります。Data Sources - Configuration Language | Terraform | HashiCorp Developer状態の依存関係図例えば、dataブロックも同様にして、AWSリソースからなるプロダクトをいくつかのtfstateファイル (foo-tfstate、bar-tfstate) に分割したと仮定します。ここで仮定した状況では、bar-tfstateファイルはVPCの状態を持っており、 foo-tfstate ファイルは bar-tfstate ファイルに依存しているとします。想定される状態の依存関係図は以下の通りになります。なお、依存方向は状況によって異なることをご容赦ください。---title: dataブロックを使用した依存関係---%%{init:{'theme':'default'}}%%flowchart TD subgraph bucket foo["foo-tfstate"] bar["bar-tfstate"] end foo -. VPCの状態に依存 .-> barリポジトリのディレクトリー構成ディレクトリー構成は、tfstateファイル分割に基づいて、以下の通りになります。🏭 repository/├── 📂 foo/│ ├── backend.tf # fooコンポーネントの状態を持つ terraform.tfstate ファイルを指定する│ ├── data.tf # dataブロックを使用し、bar-tfstate ファイルに依存する│ ├── provider.tf│ ...│└── 📂 bar/ ├── backend.tf # barコンポーネントの状態を持つ terraform.tfstate ファイルを指定する ├── provider.tf ...foo-tfstateファイルがbar-tfstateファイルに依存するために必要な実装は、以下の通りになります。# fooリソースの状態は、foo-tfstate ファイルで持つresource "example" "foo" { # fooリソースは、bar-tfstate ファイルのVPCに依存する vpc_id = data.aws_vpc.bar.id}# VPCの状態は、bar-tfstate ファイルで持つdata "aws_vpc" "bar" { filter { name = "tag:Name" values = [""] }}リモートバックエンドのディレクトリー構成tfstateファイル分割に基づいて、リモートバックエンド内のディレクトリー構成例は以下の通りになります。🪣 bucket/├── 📂 foo│ └── terraform.tfstate # fooコンポーネントの状態を持つ│└── 📂 bar └── terraform.tfstate # barコンポーネントの状態を持つ06. tfstate ファイルの分割パターンオススメな設計の一覧前述の通り、tfstateファイルの分割の境界は、『他の状態にできるだけ依存しないリソースの関係』から見つけることができます。分割しすぎると terraform_remote_stateブロック地獄になるため、細かすぎず粗すぎない適切な境界を見つけていきましょう。今回は、私が考える分割パターンをいくつか紹介します。全てが実用的なパターンというわけでないため、オススメするものを ★ としています。必須・任意 tfstate分割パターン大分類 tfstate分割パターン小分類オススメ対応するリポジトリ構成 🏭 対応するリモートバックエンド構成 🪣 必須上層プロバイダーのアカウント別 ★★ リポジトリ自体または上層ディレクトリーリモートバックエンド自体または上層ディレクトリー下層実行環境別 ★★ 下層ディレクトリー下層ディレクトリー任意中間層同じテナント内のプロダクト別中間層ディレクトリー中間層ディレクトリー運用チーム責務範囲別 ★ プロダクトのサブコンポーネント別 ★ AWSリソースの種類グループ別 AWSリソースの状態の変更頻度グループ別運用チーム責務範囲別プロダクトのサブコンポーネント別の組み合わせ ★ ディレクトリー構成との関係についてリポジトリの場合記事内のここで、リポジトリ内のディレクトリー構成はtfstateファイル分割に基づいて設計するべき、という説明をしました。tfstateファイルの分割パターンは、上層/下層/中間層の層に大別できます。これらの層は、以下の通りリポジトリ自体・ディレクトリー構成の設計方法に影響します。# リポジトリ自体を分割する場合🏭 上層/├── 📂 中間層/│ ├── 📂 下層/│ │ ├── backend.tfvars # 分割された terraform.tfstate ファイルを指定する│ │ ...│ │...# リポジトリ内のディレクトリを分割する場合🏭 リポジトリ/├── 📂 上層/│ ├── 📂 中間層/│ │ ├── 📂 下層/│ │ │ ├── backend.tfvars # 分割された terraform.tfstate ファイルを指定する│ │ │ ...│ │ │...リモートバックエンドの場合記事内のここで、リモートバックエンドのディレクトリ構成についても言及しました。これらの層は、以下の通りリモートバックエンド自体・ディレクトリー構成の設計方法に影響します。# リモートバックエンド自体を分割する場合🪣 上層/├── 📂 中間層/│ ├── 📂 下層/│ │ └── terraform.tfstate # 分割された状態を持つ│ ││ │...# リモートバックエンド内のディレクトリを分割する場合🪣 bucket/├── 📂 上層/│ ├── 📂 中間層/│ │ ├── 📂 下層/│ │ │ └── terraform.tfstate # 分割された状態を持つ│ │ ││ │ │...07. 上層の分割 (必須)上層の分割について上層の分割は必須です。Terraformに携わる管理者の数が少なくても採用した方がよいです。tfstateファイルをパターンに応じて分割し、これに基づいてディレクトリー・リモートバックエンドも設計しましょう。プロバイダーのアカウント別 - ★★この分割方法について上層分割の中でも、基本的な方法の1つです。プロバイダーのアカウント別にtfstateファイルを分割し、上層もこれに基づいて設計します。この分割方法により、各プロバイダーの管理者が互いに影響を受けずに、terraformコマンドの結果を得られるようになります。tfstateファイルで状態を管理せざるを得ない場合があります。例えば、Kubernetesのプロバイダーは、EKSと同じtfstateファイルで管理した方がよいです👍Terraform Registry【プロバイダーアカウント別】状態の依存関係図例えば、以下のプロバイダーを使用したい状況と仮定します。主要プロバイダー (AWS)アプリ/インフラ監視プロバイダー (Datadog)ジョブ監視プロバイダー (Healthchecks)インシデント管理プロバイダー (PagerDuty)ここで仮定した状況では、各プロバイダーの tfstate ファイル間で状態が相互に依存しているとします。AWSリソース間の相互依存ではないため、循環参照は起こりません。そのため、想定される状態の依存関係図は以下の通りになります。なお、依存方向は状況によって異なることをご容赦ください。---title: プロバイダーのアカウント別---%%{init:{'theme':'default'}}%%flowchart LR subgraph PagerDuty pagerDuty["tfstate"] end subgraph Healthchecks healthchecks["tfstate"] end subgraph Datadog datadog["tfstate"] end subgraph AWS aws["tfstate"] end aws -...-> datadog aws -...-> healthchecks aws -...-> pagerDuty datadog -...-> aws healthchecks -...-> aws pagerDuty -...-> aws【プロバイダーアカウント別】リポジトリのディレクトリー構成▼ 異なるリポジトリの場合プロバイダーアカウント別に分割したtfstateファイルを、異なるリポジトリで管理します。例えば、tfstateファイル分割に基づいて、リポジトリのディレクトリー構成例は以下の通りになります。前述の依存関係図の状況と仮定します。🏭 aws-repository/├── backend.tf # AWSの状態を持つ terraform.tfstate ファイルを指定する├── output.tf # 他の tfstate ファイルから依存される├── remote_state.tf # 他の tfstate ファイルに依存する├── provider.tf...🏭 datadog-repository/├── backend.tf # Datadogの状態を持つ terraform.tfstate ファイルを指定する├── output.tf # 他の tfstate ファイルから依存される├── remote_state.tf # 他の tfstate ファイルに依存する├── provider.tf...🏭 healthchecks-repository/├── backend.tf # Healthchecksの状態を持つ terraform.tfstate ファイルを指定する├── output.tf # 他の tfstate ファイルから依存される├── remote_state.tf # 他の tfstate ファイルに依存する├── provider.tf...🏭 pagerduty-repository/├── backend.tf # PagerDutyの状態を持つ terraform.tfstate ファイルを指定する├── output.tf # 他の tfstate ファイルから依存される├── remote_state.tf # 他の tfstate ファイルに依存する├── provider.tf...▼ 同じリポジトリの場合プロバイダーアカウント別に分割したtfstateファイルを、同じリポジトリで管理します。例えば、tfstateファイル分割に基づいて、リポジトリのディレクトリー構成例は以下の通りになります。前述の依存関係図の状況と仮定します。🏭 repository/├── 📂 aws/│ ├── backend.tf # AWSの状態を持つ terraform.tfstate ファイルを指定する│ ├── output.tf # 他の tfstate ファイルから依存される│ ├── remote_state.tf # 他の tfstate ファイルに依存する│ ├── provider.tf│ ...│├── 📂 datadog/│ ├── backend.tf # Datadogの状態を持つ terraform.tfstate ファイルを指定する│ ├── output.tf # 他の tfstate ファイルから依存される│ ├── remote_state.tf # 他の tfstate ファイルに依存する│ ├── provider.tf│ ...│├── 📂 healthchecks/│ ├── backend.tf # Healthchecksの状態を持つ terraform.tfstate ファイルを指定する│ ├── output.tf # 他の tfstate ファイルから依存される│ ├── remote_state.tf # 他の tfstate ファイルに依存する│ ├── provider.tf│ ...│└── 📂 pagerduty/ ├── backend.tf # PagerDutyの状態を持つ terraform.tfstate ファイルを指定する ├── output.tf # 他の tfstate ファイルから依存される ├── remote_state.tf # 他の tfstate ファイルに依存する ├── provider.tf ...【プロバイダーアカウント別】リモートバックエンドのディレクトリー構成▼ 異なるリモートバックエンドの場合プロバイダーアカウント別に分割したtfstateファイルを、異なるリモートバックエンドで管理します。例えば、tfstateファイル分割に基づいて、リモートバックエンド内のディレクトリー構成例は以下の通りになります。前述の依存関係図の状況と仮定します。🪣 aws-bucket/│└── terraform.tfstate # AWSの状態を持つ🪣 datadog-bucket/│└── terraform.tfstate # Datadogの状態を持つ🪣 healthchecks-bucket/│└── terraform.tfstate # Healthchecksの状態を持つ🪣 pagerduty-bucket/│└── terraform.tfstate # PagerDutyの状態を持つ▼ 同じリモートバックエンドの場合プロバイダーアカウント別に分割したtfstateファイルを、同じリモートバックエンドで管理します。例えば、tfstateファイル分割に基づいて、リモートバックエンド内のディレクトリー構成例は以下の通りになります。前述の依存関係図の状況と仮定します。🪣 bucket/├── 📂 aws│ └── terraform.tfstate # AWSの状態を持つ│├── 📂 datadog│ └── terraform.tfstate # Datadogの状態を持つ│├── 📂 healthchecks│ └── terraform.tfstate # Healthchecksの状態を持つ│└── 📂 pagerduty └── terraform.tfstate # PagerDutyの状態を持つ08. 下層の分割 (必須)下層の分割について下層の分割は必須です。Terraformに携わる管理者の数が少なくても採用した方がよいです。tfstateファイルをパターンに応じて分割し、これに基づいてディレクトリー・リモートバックエンドも設計しましょう。実行環境別 - ★★この分割方法について下層分割の中でも、基本的な方法の1つです。実行環境別にtfstateファイルを分割し、下層もこれに基づいて設計します。この分割方法により、各実行環境の管理者が互いに影響を受けずに、terraformコマンドの結果を得られるようになります。Terraform: Up & Running; Writing Infrastructure As CodeHow to manage Terraform state. A guide to file layout, isolation, and… | by Yevgeniy Brikman | Gruntwork【実行環境別】状態の依存関係図例えば、以下の実行環境を構築したい状況と仮定します。Tes環境 (検証環境)Stg環境 (ユーザー受け入れ環境)Prd環境 (本番環境)かつ、以下のプロバイダーを使用したい状況と仮定します。主要プロバイダー (AWS)アプリ/インフラ監視プロバイダー (Datadog)ジョブ監視プロバイダー (Healthchecks)インシデント管理プロバイダー (PagerDuty)ここで仮定した状況では、各実行環境の tfstate ファイルは他の実行環境には依存していないとします。そのため、想定される状態の依存関係図は以下の通りになります。なお、依存方向は状況によって異なることをご容赦ください。---title: 実行環境別---%%{init:{'theme':'default'}}%%flowchart LR subgraph PagerDuty pagerDuty["tfstate"] end subgraph Healthchecks healthchecks["tfstate"] end subgraph Datadog datadog["tfstate"] end subgraph AWS subgraph tes-bucket tes["tfstate"] end subgraph stg-bucket stg["tfstate"] end subgraph prd-bucket prd["tfstate"] end end tes -...-> datadog tes -...-> healthchecks tes -...-> pagerDuty datadog -...-> tes healthchecks -...-> tes pagerDuty -...-> tes【実行環境別】リポジトリのディレクトリー構成▼ 異なるリポジトリの場合プロバイダーアカウント別にtfstateファイルを分割することは必須としているため、その上でディレクトリー構成を考えます。例えば、tfstateファイル分割に基づいて、リポジトリのディレクトリー構成例は以下の通りになります。前述の依存関係図の状況と仮定します。🏭 aws-repository/├── output.tf # 他の tfstate ファイルから依存される├── remote_state.tf # 他の tfstate ファイルに依存する├── provider.tf├── 📂 tes/ # Tes環境│ ├── backend.tfvars # AWSのTes環境の状態を持つ terraform.tfstate ファイルを指定する│ ...│├── 📂 stg/ # Stg環境└── 📂 prd/ # Prd環境🏭 datadog-repository/├── output.tf # 他の tfstate ファイルから依存される├── remote_state.tf # 他の tfstate ファイルに依存する├── provider.tf├── 📂 tes/│ ├── backend.tfvars # DatadogのTes環境の状態を持つ terraform.tfstate ファイルを指定する│ ...│├── 📂 stg/└── 📂 prd/🏭 healthchecks-repository/├── output.tf # 他の tfstate ファイルから依存される├── remote_state.tf # 他の tfstate ファイルに依存する├── provider.tf├── 📂 tes/│ ├── backend.tfvars # HealthchecsのTes環境の状態を持つ terraform.tfstate ファイルを指定する│ ...│├── 📂 stg/└── 📂 prd/🏭 pagerduty-repository/├── output.tf # 他の tfstate ファイルから依存される├── remote_state.tf # 他の tfstate ファイルに依存する├── provider.tf├── 📂 tes/│ ├── backend.tfvars # PagerDutyのTes環境の状態を持つ terraform.tfstate ファイルを指定する│ ...│├── 📂 stg/└── 📂 prd/▼ 同じリポジトリの場合プロバイダーアカウント別にtfstateファイルを分割することは必須としているため、その上でディレクトリー構成を考えます。例えば、tfstateファイル分割に基づいて、リポジトリのディレクトリー構成例は以下の通りになります。前述の依存関係図の状況と仮定します。🏭 repository/├── 📂 aws/│ ├── output.tf # 他の tfstate ファイルから依存される│ ├── remote_state.tf # 他の tfstate ファイルに依存する│ ├── provider.tf│ ├── 📂 tes/ # Tes環境│ │ ├── backend.tfvars # AWSのTes環境の状態を持つ terraform.tfstate ファイルを指定する│ │ ...│ ││ ├── 📂 stg/ # Stg環境│ └── 📂 prd/ # Prd環境│├── 📂 datadog/│ ├── output.tf # 他の tfstate ファイルから依存される│ ├── remote_state.tf # 他の tfstate ファイルに依存する│ ├── provider.tf│ ├── 📂 tes/│ │ ├── backend.tfvars # DatadogのTes環境の状態を持つ terraform.tfstate ファイルを指定する│ │ ...│ ││ ├── 📂 stg/│ └── 📂 prd/│├── 📂 healthchecks/│ ├── output.tf # 他の tfstate ファイルから依存される│ ├── remote_state.tf # 他の tfstate ファイルに依存する│ ├── provider.tf│ ├── 📂 tes/│ │ ├── backend.tfvars # HealthchecksのTes環境の状態を持つ terraform.tfstate ファイルを指定する│ │ ...│ ││ ├── 📂 stg/│ └── 📂 prd/│└── 📂 pagerduty/ ├── output.tf # 他の tfstate ファイルから依存される ├── remote_state.tf # 他の tfstate ファイルに依存する ├── provider.tf ├── 📂 tes/ │ ├── backend.tfvars # PagerDutyのTes環境の状態を持つ terraform.tfstate ファイルを指定する │ ... │ ├── 📂 stg/ └── 📂 prd/【実行環境別】リモートバックエンドのディレクトリー構成▼ 異なるリモートバックエンドの場合実行環境別に分割したtfstateファイルを、異なるリモートバックエンドで管理します。tfstateファイル分割に基づいて、リモートバックエンド内のディレクトリー構成例は以下の通りになります。例えば、前述の依存関係図の状況と仮定します。🪣 tes-aws-bucket/│└── terraform.tfstate # AWSのTes環境の状態を持つ🪣 tes-datadog-bucket/│└── terraform.tfstate # DatadogのTes環境の状態を持つ🪣 tes-healthchecks-bucket/│└── terraform.tfstate # HealthchecksのTes環境の状態を持つ🪣 tes-pagerduty-bucket/│└── terraform.tfstate # PagerDutyのTes環境の状態を持つ▼ 同じリモートバックエンド x AWSアカウント別に異なる実行環境の場合プロバイダーアカウント別に分割したtfstateファイルを、同じリモートバックエンドで管理します。また、AWSアカウント別に異なる実行環境を作成していると仮定します。例えば、tfstateファイル分割に基づいて、リモートバックエンド内のディレクトリー構成例は以下の通りになります。前述の依存関係図の状況と仮定します。# Tes環境用バケットの場合🪣 tes-bucket/├── 📂 aws/│ └── terraform.tfstate # AWSのTes環境の状態を持つ│├── 📂 datadog/│ └── terraform.tfstate # DatadogのTes環境の状態を持つ│├── 📂 healthchecks/│ └── terraform.tfstate # HealthchecksのTes環境の状態を持つ│└── 📂 pagerduty/ └── terraform.tfstate # PagerDutyのTes環境の状態を持つ# Stg環境用バケットの場合🪣 stg-bucket/│...# Prd環境用バケットの場合🪣 prd-bucket/│...▼ 同じリモートバックエンド x 単一のAWSアカウント内に全ての実行環境の場合プロバイダーアカウント別に分割したtfstateファイルを、同じリモートバックエンドで管理します。また、単一のAWSアカウント内に全実行環境を作成しているとします。例えば、tfstateファイル分割に基づいて、リモートバックエンド内のディレクトリー構成例は以下の通りになります。前述の依存関係図の状況と仮定します。🪣 bucket/├── 📂 aws/│ ├── 📂 tes/ # Tes環境│ │ └── terraform.tfstate # AWSのTes環境の状態を持つ│ ││ ├── 📂 stg/ # Stg環境│ └── 📂 prd/ # Prd環境│├── 📂 datadog/│ ├── 📂 tes/│ │ └── terraform.tfstate # DatadogのTes環境の状態を持つ│ ││ ├── 📂 stg/│ └── 📂 prd/│├── 📂 healthchecks/│ ├── 📂 tes/│ │ └── terraform.tfstate # HealthchecksのTes環境の状態を持つ│ ││ ├── 📂 stg/│ └── 📂 prd/│└── 📂 pagerduty/ ├── 📂 tes/ │ └── terraform.tfstate # PagerDutyのTes環境の状態を持つ │ ├── 📂 stg/ └── 📂 prd/09. 中間層の分割 (任意)中間層の分割について中間層の分割は任意です。Terraformに携わる管理者が多くなるほど、効力を発揮します。同じテナントのプロダクト別この分割方法について同じテナント (例：同じAWSアカウントの同じVPC) 内に複数の小さなプロダクトがある場合、プロダクト別でtfstateファイルを分割し、中間層もこれに基づいて設計します。ここでいうプロダクトは、アプリを動かすプラットフォーム (例：EKS、ECS、AppRunner、EC2) とそれを取り巻くAWSリソースを指しています。この分割方法により、各プロダクトの管理者が互いに影響を受けずに、terraformコマンドの結果を得られるようになります。AWSの設計プラクティスとしてプロダクトごとにVPCを分けた方がよいため、この分割方法を採用することは少ないかもしれません。ただ現実として、各プロダクトの使用するIPアドレス数が少なく、またプロダクト別にVPCを分割するのが煩雑という現場はあります😭【同じテナントのプロダクト別】状態の依存関係図例えば、以下のプロダクトに分割した状況と仮定します。fooプロダクトbarプロダクト共有networkコンポーネント (例：VPC、Route53)ここで仮定した状況では、各プロダクトの tfstate ファイルの依存は一方向最終的に、共有networkコンポーネントの tfstate ファイルに依存しているとします。そのため、想定される状態の依存関係図は以下の通りになります。なお、依存方向は状況によって異なることをご容赦ください。---title: 同じテナントのプロダクト別---%%{init:{'theme':'default'}}%%flowchart TB subgraph AWS subgraph tes-bucket foo-product["foo-product-tfstate
(アプリを動かすプラットフォームのAWSリソース)"]-..->network bar-product["bar-product-tfstate
(アプリを動かすプラットフォームのAWSリソース)"]-..->network network["network-tfstate
(Route53, VPC)"] end subgraph stg-bucket stg["tfstate"] end subgraph prd-bucket prd["tfstate"] end end【同じテナントのプロダクト別】リポジトリのディレクトリー構成▼ 異なるリポジトリの場合この場合では、同じテナントのプロダクト別に分割したtfstateファイルを、異なるリポジトリで管理します。例えば、tfstateファイル分割に基づいて、リポジトリのディレクトリー構成例は以下の通りになります。前述の依存関係図の状況と仮定します。# fooプロダクトの tfstate ファイルのリポジトリ🏭 aws-foo-product-repository/├── provider.tf├── remote_state.tf # 他の tfstate ファイルに依存する├── 📂 tes/ # Tes環境│ ├── backend.tfvars # fooプロダクトの状態を持つ terraform.tfstate ファイルを指定する│ ...│├── 📂 stg/ # Stg環境│ ├── backend.tfvars # fooプロダクトの状態を持つ terraform.tfstate ファイルを指定する│ ...│└── 📂 prd/ # Prd環境 ├── backend.tfvars # fooプロダクトの状態を持つ terraform.tfstate ファイルを指定する ...# barプロダクトの tfstate ファイルのリポジトリ🏭 aws-bar-product-repository/├── provider.tf├── remote_state.tf # 他の tfstate ファイルに依存する├── 📂 tes/ # Tes環境│ ├── backend.tfvars # barプロダクトの状態を持つ terraform.tfstate ファイルを指定する│ ...│├── 📂 stg/ # Stg環境│ ├── backend.tfvars # barプロダクトの状態を持つ terraform.tfstate ファイルを指定する│ ...│└── 📂 prd/ # Prd環境 ├── backend.tfvars # barプロダクトの状態を持つ terraform.tfstate ファイルを指定する ...# 共有networkコンポーネントの tfstate ファイルのリポジトリ🏭 aws-network-repository/├── provider.tf├── output.tf # 他の tfstate ファイルから依存される├── route53.tf├── vpc.tf├── 📂 tes/ # Tes環境│ ├── backend.tfvars # networkコンポーネントの状態を持つ terraform.tfstate ファイルを指定する│ ...│├── 📂 stg/ # Stg環境│ ├── backend.tfvars # networkコンポーネントの状態を持つ terraform.tfstate ファイルを指定する│ ...│└── 📂 prd/ # Prd環境 ├── backend.tfvars # networkコンポーネントの状態を持つ terraform.tfstate ファイルを指定する ...▼ 同じリポジトリの場合この場合では、同じテナントのプロダクト別に分割したtfstateファイルを、同じリポジトリで管理します。例えば、tfstateファイル分割に基づいて、リポジトリのディレクトリー構成例は以下の通りになります。前述の依存関係図の状況と仮定します。🏭 aws-repository/├── 📂 foo-product/│ ├── provider.tf│ ├── remote_state.tf # 他の tfstate ファイルに依存する│ ├── 📂 tes/ # Tes環境│ │ ├── backend.tfvars # fooプロダクトの状態を持つ terraform.tfstate ファイルを指定する│ │ ...│ ││ ├── 📂 stg/ # Stg環境│ │ ├── backend.tfvars # fooプロダクトの状態を持つ terraform.tfstate ファイルを指定する│ │ ...│ ││ └── 📂 prd/ # Prd環境│ ├── backend.tfvars # fooプロダクトの状態を持つ terraform.tfstate ファイルを指定する│ ...│├── 📂 bar-product/│ ├── provider.tf│ ├── remote_state.tf # 他の tfstate ファイルに依存する│ ├── 📂 tes/ # Tes環境│ │ ├── backend.tfvars # barプロダクトの状態を持つ terraform.tfstate ファイルを指定する│ │ ...│ ││ ├── 📂 stg/ # Stg環境│ │ ├── backend.tfvars # barプロダクトの状態を持つ terraform.tfstate ファイルを指定する│ │ ...│ ││ └── 📂 prd/ # Prd環境│ ├── backend.tfvars # barプロダクトの状態を持つ terraform.tfstate ファイルを指定する│ ...│└── 📂 network ├── provider.tf ├── output.tf # 他の tfstate ファイルから依存される ├── route53.tf ├── vpc.tf ├── 📂 tes/ # Tes環境 │ ├── backend.tfvars # networkコンポーネントの状態を持つ terraform.tfstate ファイルを指定する │ ... │ ├── 📂 stg/ # Stg環境 │ ├── backend.tfvars # networkコンポーネントの状態を持つ terraform.tfstate ファイルを指定する │ ... │ └── 📂 prd/ # Prd環境 ├── backend.tfvars # networkコンポーネントの状態を持つ terraform.tfstate ファイルを指定する ...【同じテナントのプロダクト別】リモートバックエンドのディレクトリー構成▼ 異なるリモートバックエンドの場合同じテナントのプロダクト別の場合、異なるリモートバックエンドで管理するとバックエンドが増え過ぎてしまいます。そのため、これはお勧めしません。▼ 同じリモートバックエンドの場合この場合では、同じテナントのプロダクト別に分割したtfstateファイルを、異なるリモートバックエンドで管理します。例えば、tfstateファイル分割に基づいて、リモートバックエンド内のディレクトリー構成例は以下の通りになります。前述の依存関係図の状況と仮定します。# Tes環境用バケットの場合🪣 tes-bucket/├── 📂 foo-product│ └── terraform.tfstate # fooプロダクトの状態を持つ│├── 📂 bar-product│ └── terraform.tfstate # barプロダクトの状態を持つ│└── 📂 network └── terraform.tfstate # networkコンポーネントの状態を持つ# Stg環境用バケットの場合🪣 stg-bucket/│...# Prd環境用バケットの場合🪣 prd-bucket/│...運用チーム責務範囲別 - ★この分割方法について運用チーム (例：アプリチーム、インフラチーム) のAWSリソースの責務範囲別でtfstateファイルを分割し、中間層もこれに基づいて設計します。この分割方法により、各運用チームが互いに影響を受けずに、terraformコマンドの結果を得られるようになります。AWS CloudFormation best practices - AWS CloudFormationTerraform in Action (English Edition)AWSドキュメント・著名な書籍で紹介されています👀Terraformに携わるチームが複数ある非常に大規模なプロダクトほど効力を発揮します。実際に私も現在進行形で採用しており、非常に実用的と考えています。【チーム別】状態の依存関係図例えば、以下の運用チームに分割した状況と仮定します。frontendチーム (アプリのフロントエンド領域担当)backendチーム (アプリのバックエンド領域担当)sreチーム (インフラ領域担当)ここで仮定した状況では、各チームが管理する tfstate ファイル間で状態が相互に依存しているとします。AWSリソース間の相互依存ではないため、循環参照は起こりません。そのため、想定される状態の依存関係図は以下の通りになります。なお、依存方向は状況によって異なることをご容赦ください。---title: 運用チーム責務範囲別---%%{init:{'theme':'default'}}%%flowchart TB subgraph AWS subgraph tes-bucket frontend["frontend-team-tfstate
(CloudFront, S3, など)"] backend["backend-team-tfstate
(API Gateway, ElastiCache, RDS, SES, SNS, など)"] sre["sre-team-tfstate
(ALB, CloudWatch, EC2, ECS, EKS, IAM, VPC, など)"] frontend-..->sre backend-..->sre sre-..->frontend sre-..->backend end subgraph stg-bucket stg["tfstate"] end subgraph prd-bucket prd["tfstate"] end end【チーム別】リポジトリのディレクトリー構成▼ 異なるリポジトリの場合この場合では、運用チーム責務範囲別に分割したtfstateファイルを、同じリポジトリで管理します。例えば、tfstateファイル分割に基づいて、リポジトリのディレクトリー構成例は以下の通りになります。この例では、状態の依存関係図と同じ状況を仮定しています。🏭 aws-frontend-team-repository/ # frontendチーム├── provider.tf├── output.tf # 他の tfstate ファイルから依存される├── remote_state.tf # 他の tfstate ファイルに依存する├── cloudfront.tf├── s3.tf├── 📂 tes/ # Tes環境│ ├── backend.tfvars # frontendチームの状態を持つ terraform.tfstate ファイルを指定する│ ...│├── 📂 stg/ # Stg環境│ ├── backend.tfvars # frontendチームの状態を持つ terraform.tfstate ファイルを指定する│ ...│└── 📂 prd/ # Prd環境 ├── backend.tfvars # frontendチームの状態を持つ terraform.tfstate ファイルを指定する ...🏭 aws-backend-team-repository/ # backendチーム├── provider.tf├── output.tf # 他の tfstate ファイルから依存される├── remote_state.tf # 他の tfstate ファイルに依存する├── elasticache.tf├── ses.tf├── sns.tf├── rds.tf├── 📂 tes│ ├── backend.tfvars # backendチームの状態を持つ terraform.tfstate ファイルを指定する│ ...│├── 📂 stg│ ├── backend.tfvars # backendチームの状態を持つ terraform.tfstate ファイルを指定する│ ...│└── 📂 prd ├── backend.tfvars # backendチームの状態を持つ terraform.tfstate ファイルを指定する ...🏭 aws-sre-team-repository/ # sreチーム├── provider.tf├── output.tf # 他の tfstate ファイルから依存される├── remote_state.tf # 他の tfstate ファイルに依存する├── alb.tf├── cloudwatch.tf├── ec2.tf├── ecs.tf├── eks.tf├── iam.tf├── vpc.tf├── 📂 tes│ ├── backend.tfvars # sreチームの状態を持つ terraform.tfstate ファイルを指定する│ ...│├── 📂 stg│ ├── backend.tfvars # sreチームの状態を持つ terraform.tfstate ファイルを指定する│ ...│└── 📂 prd ├── backend.tfvars # sreチームの状態を持つ terraform.tfstate ファイルを指定する ...▼ 同じリポジトリの場合この場合では、運用チーム責務範囲別に分割したtfstateファイルを、異なるリポジトリで管理します。例えば、tfstateファイル分割に基づいて、リポジトリのディレクトリー構成例は以下の通りになります。この例では、状態の依存関係図と同じ状況を仮定しています。🏭 aws-repository/├── 📂 frontend-team # frontendチーム│ ├── provider.tf│ ├── output.tf # 他の tfstate ファイルから依存される│ ├── remote_state.tf # 他の tfstate ファイルに依存する│ ├── cloudfront.tf│ ├── s3.tf│ ├── 📂 tes/ # Tes環境│ │ ├── backend.tfvars # frontendチームの状態を持つ terraform.tfstate ファイルを指定する│ │ ...│ ││ ├── 📂 stg/ # Stg環境│ │ ├── backend.tfvars # frontendチームの状態を持つ terraform.tfstate ファイルを指定する│ │ ...│ ││ └── 📂 prd/ # Prd環境│ ├── backend.tfvars # frontendチームの状態を持つ terraform.tfstate ファイルを指定する│ ...│├── 📂 backend-team # backendチーム│ ├── provider.tf│ ├── output.tf # 他の tfstate ファイルから依存される│ ├── remote_state.tf # 他の tfstate ファイルに依存する│ ├── elasticache.tf│ ├── ses.tf│ ├── sns.tf│ ├── rds.tf│ ├── 📂 tes│ │ ├── backend.tfvars # backendチームの状態を持つ terraform.tfstate ファイルを指定する│ │ ...│ ││ ├── 📂 stg│ │ ├── backend.tfvars # backendチームの状態を持つ terraform.tfstate ファイルを指定する│ │ ...│ ││ └── 📂 prd│ ├── backend.tfvars # backendチームの状態を持つ terraform.tfstate ファイルを指定する│ ...│└── 📂 sre-team # sreチーム ├── provider.tf ├── output.tf # 他の tfstate ファイルから依存される ├── remote_state.tf # 他の tfstate ファイルに依存する ├── alb.tf ├── cloudwatch.tf ├── ec2.tf ├── ecs.tf ├── eks.tf ├── iam.tf ├── vpc.tf ├── 📂 tes │ ├── backend.tfvars # sreチームの状態を持つ terraform.tfstate ファイルを指定する │ ... │ ├── 📂 stg │ ├── backend.tfvars # sreチームの状態を持つ terraform.tfstate ファイルを指定する │ ... │ └── 📂 prd ├── backend.tfvars # sreチームの状態を持つ terraform.tfstate ファイルを指定する ...【チーム別】リモートバックエンドのディレクトリー構成▼ 異なるリモートバックエンドの場合運用チーム責務範囲別の場合、異なるリモートバックエンドで管理するとバックエンドが増え過ぎてしまいます。そのため、これはお勧めしません。▼ 同じリモートバックエンドの場合この場合では、プロバイダーアカウント別に分割したtfstateファイルを、異なるリモートバックエンドで管理します。例えば、tfstateファイル分割に基づいて、リモートバックエンド内のディレクトリー構成例は以下の通りになります。この例では、状態の依存関係図と同じ状況を仮定しています。# Tes環境用バケットの場合🪣 tes-bucket/├── 📂 frontend-team│ └── terraform.tfstate # frontendチームの状態を持つ│├── 📂 backend-team│ └── terraform.tfstate # backendチームの状態を持つ│└── 📂 sre-team └── terraform.tfstate # sreチームの状態を持つ# Stg環境用バケットの場合🪣 stg-bucket/│...# Prd環境用バケットの場合🪣 prd-bucket/│...プロダクトのサブコンポーネント別 - ★この分割方法についてプロダクトのサブコンポーネント (例：アプリ、ネットワーク、認証/認可、監視、など) 別でtfstateファイルを分割し、中間層もこれに基づいて設計します。この分割方法により、サブコンポーネントの管理者が互いに影響を受けずに、terraformコマンドの結果を得られるようになります。11 Things I wish I knew before working with Terraform – part 1Terraform organization — Part I : What if you split your components ? | by Amine Charot | Mediumコンポーネントは、分けようと思えばいくらでも細分化できてしまいます。細分化した数だけterraform_remote_stateブロック地獄になっていくため、適切な数 (3〜5個くらい) にしておくように注意が必要です。この分割方法は、後述のAWSリソースの種類グループとごっちゃになってしまう場合があるため、プロダクトのサブコンポーネントとして意識的に分割させる必要があります👍【サブコンポーネント別】状態の依存関係図例えば、以下のサブコンポーネントに分割した状況と仮定します。application (Web3層系)auth (認証/認可系)monitor (監視系)network (ネットワーク系)ここで仮定した状況では、各プロダクトの tfstate ファイルの依存は一方向最終的に、networkサブコンポーネントやauthサブコンポーネントの tfstate ファイルに依存しているとします。そのため、想定される状態の依存関係図は以下の通りになります。なお、依存方向は状況によって異なることをご容赦ください。---title: プロダクトのサブコンポーネント別---%%{init:{'theme':'default'}}%%flowchart TB subgraph AWS subgraph tes-bucket application["application-tfstate
Web3層と周辺AWSリソース
(ALB, APIGateway, CloudFront, EC2, ECS, EKS, RDS, S3, SNS, など)"] auth["auth-tfstate
(IAMなど)"] monitor["monitor-tfstate
(CloudWatch, など)"] network["network-tfstate
(Route53, VPC, など)"] application-..->network application-..->auth monitor-..->application end subgraph stg-bucket stg["tfstate"] end subgraph prd-bucket prd["tfstate"] end end【サブコンポーネント別】リポジトリのディレクトリー構成▼ 異なるリポジトリの場合プロダクトのサブコンポーネント別の分割パターンの場合、異なるリポジトリで管理するとリポジトリが増え過ぎてしまいます。そのため、これはお勧めしません。▼ 同じリポジトリの場合この場合では、プロダクトのサブコンポーネント別に分割したtfstateファイルを、同じリポジトリで管理します。例えば、tfstateファイル分割に基づいて、リポジトリのディレクトリー構成例は以下の通りになります。この例では、状態の依存関係図と同じ状況を仮定しています。🏭 aws-repository/├── 📂 application/│ ├── output.tf # 他の tfstate ファイルから依存される│ ├── remote_state.tf # 他の tfstate ファイルに依存する│ ├── provider.tf│ ├── alb.tf│ ├── cloudfront.tf│ ├── ec2.tf│ ├── ecs.tf│ ├── eks.tf│ ├── ses.tf│ ├── sns.tf│ ├── 📂 tes/ # Tes環境│ │ ├── backend.tfvars # applicationコンポーネントの状態を持つ terraform.tfstate ファイルを指定する│ │ ...│ ││ ├── 📂 stg/ # Stg環境│ │ ├── backend.tfvars # applicationコンポーネントの状態を持つ terraform.tfstate ファイルを指定する│ │ ...│ ││ └── 📂 prd/ # Prd環境│ ├── backend.tfvars # applicationコンポーネントの状態を持つ terraform.tfstate ファイルを指定する│ ...│├── 📂 auth/│ ├── provider.tf│ ├── output.tf # 他の tfstate ファイルから依存される│ ├── iam.tf│ ├── 📂 tes/ # Tes環境│ │ ├── backend.tfvars # authコンポーネントの状態を持つ terraform.tfstate ファイルを指定する│ │ ...│ ││ ├── 📂 stg/ # Stg環境│ │ ├── backend.tfvars # authコンポーネントの状態を持つ terraform.tfstate ファイルを指定する│ │ ...│ ││ └── 📂 prd/ # Prd環境│ ├── backend.tfvars # authコンポーネントの状態を持つ terraform.tfstate ファイルを指定する│ ...│├── 📂 monitor/│ ├── provider.tf│ ├── remote_state.tf # 他の tfstate ファイルに依存する│ ├── cloudwatch.tf│ ├── 📂 tes/ # Tes環境│ │ ├── backend.tfvars # monitorコンポーネントの状態を持つ terraform.tfstate ファイルを指定する│ │ ...│ ││ ├── 📂 stg/ # Stg環境│ │ ├── backend.tfvars # monitorコンポーネントの状態を持つ terraform.tfstate ファイルを指定する│ │ ...│ ││ └── 📂 prd/ # Prd環境│ ├── backend.tfvars # monitorコンポーネントの状態を持つ terraform.tfstate ファイルを指定する│ ...│└── 📂 network ├── provider.tf ├── output.tf # 他の tfstate ファイルから依存される ├── route53.tf ├── vpc.tf ├── 📂 tes/ # Tes環境 │ ├── backend.tfvars # networkコンポーネントの状態を持つ terraform.tfstate ファイルを指定する │ ... │ ├── 📂 stg/ # Stg環境 │ ├── backend.tfvars # networkコンポーネントの状態を持つ terraform.tfstate ファイルを指定する │ ... │ └── 📂 prd/ # Prd環境 ├── backend.tfvars # networkコンポーネントの状態を持つ terraform.tfstate ファイルを指定する ...【サブコンポーネント別】リモートバックエンドのディレクトリー構成▼ 異なるリモートバックエンドの場合プロダクトのサブコンポーネント別の分割パターンの場合、異なるリモートバックエンドで管理するとバックエンドが増え過ぎてしまいます。そのため、これはお勧めしません。▼ 同じリモートバックエンドの場合この場合では、プロダクトのサブコンポーネント別に分割したtfstateファイルを、異なるリモートバックエンドで管理します。例えば、tfstateファイル分割に基づいて、リモートバックエンド内のディレクトリー構成例は以下の通りになります。この例では、状態の依存関係図と同じ状況を仮定しています。# Tes環境用バケットの場合🪣 tes-bucket/├── 📂 application│ └── terraform.tfstate # applicationコンポーネントの状態を持つ│├── 📂 auth│ └── terraform.tfstate # authコンポーネントの状態を持つ│├── 📂 monitor│ └── terraform.tfstate # monitorコンポーネントの状態を持つ│└── 📂 network └── terraform.tfstate # networkコンポーネントの状態を持つ# Stg環境用バケットの場合🪣 stg-bucket/│...# Prd環境用バケットの場合🪣 prd-bucket/│...AWSリソースの種類グループ別この分割方法についてAWSリソースの種類グループ別でtfstateファイルを分割し、中間層もこれに基づいて設計します。この分割方法により、各AWSリソースの種類グループも管理者が互いに影響を受けずに、terraformコマンドの結果を得られるようになります。AWSリソースの種類グループは、分けようと思えばいくらでも細分化できてしまいます。細分化した数だけterraform_remote_stateブロック地獄になっていくため、適切な数 (3〜5個くらい) にしておくように注意が必要です。特にこの分割方法は、グループ数がどんどん増えていく可能性があります😇【種類グループ別】状態の依存関係図例えば、以下の種類グループに分割した状況と仮定します。application (Webサーバー、Appサーバー系)auth (認証/認可系)datastore (DBサーバー系)cicd (CI/CD系)monitor (監視系)network (ネットワーク系)ここで仮定した状況では、各プロダクトのtfstateファイルの依存は一方向最終的に、networkグループやauthグループの tfstate ファイルに依存しているとします。そのため、想定される状態の依存関係図は以下の通りになります。なお、依存方向は状況によって異なることをご容赦ください。---title: AWSリソースの種類グループ別---%%{init:{'theme':'default'}}%%flowchart TB subgraph AWS subgraph tes-bucket application["application-tfstate
例: ALB, API Gateway, CloudFront, EC2, ECS, EKS, SNS, など"] auth["auth-tfstate
例: IAM, など"] cicd["cicd-tfstate
例: Code3兄弟, など"] monitor["monitor-tfstate
例: CloudWatch, など"] network["network-tfstate
例: Route53, VPC, など"] datastore["datastore-tfstate
例: ElastiCache, RDS, S3, など"] application-....->auth application-..->datastore application-...->network cicd-..->application datastore-..->network monitor-..->application monitor-..->datastore end subgraph stg-bucket stg["tfstate"] end subgraph prd-bucket prd["tfstate"] end end【種類グループ別】リポジトリのディレクトリー構成▼ 異なるリポジトリの場合AWSリソースの種類グループ別の分割パターンの場合、異なるリポジトリで管理するとリポジトリが増え過ぎてしまいます。そのため、これはお勧めしません。▼ 同じリポジトリの場合この場合では、AWSリソースの種類グループ別に分割したtfstateファイルを、同じリポジトリで管理します。例えば、tfstateファイル分割に基づいて、リポジトリのディレクトリー構成例は以下の通りになります。この例では、状態の依存関係図と同じ状況を仮定しています。🏭 aws-repository/├── 📂 application/│ ├── provider.tf│ ├── remote_state.tf # 他の tfstate ファイルに依存する│ ├── output.tf # 他の tfstate ファイルから依存される│ ├── alb.tf│ ├── api_gateway.tf│ ├── cloudfront.tf│ ├── ec2.tf│ ├── ecs.tf│ ├── eks.tf│ ├── ses.tf│ ├── sns.tf│ ├── 📂 tes/ # Tes環境│ │ ├── backend.tfvars # applicationコンポーネントの状態を持つ terraform.tfstate ファイルを指定する│ │ ...│ ││ ├── 📂 stg/ # Stg環境│ │ ├── backend.tfvars # applicationコンポーネントの状態を持つ terraform.tfstate ファイルを指定する│ │ ...│ ││ └── 📂 prd/ # Prd環境│ ├── backend.tfvars # applicationコンポーネントの状態を持つ terraform.tfstate ファイルを指定する│ ...│├── 📂 auth/│ ├── provider.tf│ ├── output.tf # 他の tfstate ファイルから依存される│ ├── iam.tf│ ├── 📂 tes/ # Tes環境│ │ ├── backend.tfvars # authコンポーネントの状態を持つ terraform.tfstate ファイルを指定する│ │ ...│ ││ ├── 📂 stg/ # Stg環境│ │ ├── backend.tfvars # authコンポーネントの状態を持つ terraform.tfstate ファイルを指定する│ │ ...│ ││ └── 📂 prd/ # Prd環境│ ├── backend.tfvars # authコンポーネントの状態を持つ terraform.tfstate ファイルを指定する│ ...│├── 📂 cicd/│ ├── provider.tf│ ├── remote_state.tf # 他の tfstate ファイルに依存する│ ├── codebuild.tf│ ├── codecommit.tf│ ├── codedeploy.tf│ ├── 📂 tes/ # Tes環境│ │ ├── backend.tfvars # cicdコンポーネントの状態を持つ terraform.tfstate ファイルを指定する│ │ ...│ ││ ├── 📂 stg/ # Stg環境│ │ ├── backend.tfvars # cicdコンポーネントの状態を持つ terraform.tfstate ファイルを指定する│ │ ...│ ││ └── 📂 prd/ # Prd環境│ ├── backend.tfvars # cicdコンポーネントの状態を持つ terraform.tfstate ファイルを指定する│ ...│├── 📂 datastore/│ ├── provider.tf│ ├── output.tf # 他の tfstate ファイルから依存される│ ├── remote_state.tf # 他の tfstate ファイルに依存する│ ├── elasticache.tf│ ├── rds.tf│ ├── s3.tf│ ├── 📂 tes/ # Tes環境│ │ ├── backend.tfvars # datastoreコンポーネントの状態を持つ terraform.tfstate ファイルを指定する│ │ ...│ ││ ├── 📂 stg/ # Stg環境│ │ ├── backend.tfvars # datastoreコンポーネントの状態を持つ terraform.tfstate ファイルを指定する│ │ ...│ ││ └── 📂 prd/ # Prd環境│ ├── backend.tfvars # datastoreコンポーネントの状態を持つ terraform.tfstate ファイルを指定する│ ...│├── 📂 monitor/│ ├── provider.tf│ ├── remote_state.tf # 他の tfstate ファイルに依存する│ ├── cloudwatch.tf│ ├── 📂 tes/ # Tes環境│ │ ├── backend.tfvars # monitorコンポーネントの状態を持つ terraform.tfstate ファイルを指定する│ │ ...│ ││ ├── 📂 stg/ # Stg環境│ │ ├── backend.tfvars # monitorコンポーネントの状態を持つ terraform.tfstate ファイルを指定する│ │ ...│ ││ └── 📂 prd/ # Prd環境│ ├── backend.tfvars # monitorコンポーネントの状態を持つ terraform.tfstate ファイルを指定する│ ...│└── 📂 network ├── provider.tf ├── output.tf # 他の tfstate ファイルから参照できるように、outputブロックを定義する ├── route53.tf ├── vpc.tf ├── 📂 tes/ # Tes環境 │ ├── backend.tfvars # networkコンポーネントの状態を持つ terraform.tfstate ファイルを指定する │ ... │ ├── 📂 stg/ # Stg環境 │ ├── backend.tfvars # networkコンポーネントの状態を持つ terraform.tfstate ファイルを指定する │ ... │ └── 📂 prd/ # Prd環境 ├── backend.tfvars # networkコンポーネントの状態を持つ terraform.tfstate ファイルを指定する ...【種類グループ別】リモートバックエンドのディレクトリー構成▼ 異なるリモートバックエンドの場合AWSリソースの種類グループ別の分割パターンの場合、異なるリモートバックエンドで管理するとバックエンドが増え過ぎてしまいます。そのため、これはお勧めしません。▼ 同じリモートバックエンドの場合この場合では、AWSリソースの種類グループ別に分割したtfstateファイルを、異なるリモートバックエンドで管理します。例えば、tfstateファイル分割に基づいて、リモートバックエンド内のディレクトリー構成例は以下の通りになります。この例では、状態の依存関係図と同じ状況を仮定しています。# Tes環境用バケットの場合🪣 tes-bucket/├── 📂 application│ └── terraform.tfstate # applicationコンポーネントの状態を持つ│├── 📂 auth│ └── terraform.tfstate # authコンポーネントの状態を持つ│├── 📂 cicd│ └── terraform.tfstate # cicdコンポーネントの状態を持つ│├── 📂 datastore│ └── terraform.tfstate # datastoreコンポーネントの状態を持つ│├── 📂 monitor│ └── terraform.tfstate # monitorコンポーネントの状態を持つ│└── 📂 network └── terraform.tfstate # networkコンポーネントの状態を持つ# Stg環境用バケットの場合🪣 stg-bucket/│...# Prd環境用バケットの場合🪣 prd-bucket/│...AWSリソースの状態の変更頻度グループ別この分割方法についてAWSリソースの状態の変更頻度グループ別でtfstateファイルを分割し、中間層もこれに基づいて設計します。この分割方法により、各変更頻度グループの管理者が互いに影響を受けずに、terraformコマンドの結果を得られるようになります。oneplane comments on Best way to approach splitting up the state file【変更頻度グループ別】状態の依存関係図例えば、以下の変更頻度グループに分割した状況と仮定します。変更高頻度グループ変更中頻度グループ変更低頻度グループここで仮定した状況では、各プロダクトのtfstateファイルの依存は一方向最終的に、変更低頻度グループの tfstate ファイルに依存しているとします。そのため、想定される状態の依存関係図は以下の通りになります。なお、依存方向は状況によって異なることをご容赦ください。---title: AWSリソースの状態の変更頻度グループ別---%%{init:{'theme':'default'}}%%flowchart TB subgraph AWS subgraph tes-bucket high["high-freq-tfstate
例: API Gateway, CloudFront, CloudWatch, IAM"] middle["middle-freq-tfstate
例: ALB, EC2, ECS, EKS, ElastiCache, RDS, S3, SES, SNS"] low["low-freq-tfstate
例: Route53, VPC"] high-...->low middle-..->low end subgraph stg-bucket stg["tfstate"] end subgraph prd-bucket prd["tfstate"] end end【変更頻度グループ別】リポジトリのディレクトリー構成▼ 異なるリポジトリの場合AWSリソースの変更頻度グループ別の分割パターンの場合、異なるリポジトリで管理するとリポジトリが増え過ぎてしまいます。そのため、これはお勧めしません。▼ 同じリポジトリの場合この場合では、AWSリソースの変更頻度グループ別に分割したtfstateファイルを、同じリポジトリで管理します。例えば、tfstateファイル分割に基づいて、リポジトリのディレクトリー構成例は以下の通りになります。この例では、状態の依存関係図と同じ状況を仮定しています。🏭 aws-repository/├── 📂 high-freq # 高頻度変更グループ│ ├── provider.tf│ ├── remote_state.tf # 他の tfstate ファイルに依存する│ ├── api_gateway.tf│ ├── cloudfront.tf│ ├── cloudwatch.tf│ ├── ec2.tf│ ├── ecs.tf│ ├── eks.tf│ ├── iam.tf│ ├── 📂 tes/ # Tes環境│ │ ├── backend.tfvars # high-freqコンポーネントの状態を持つ terraform.tfstate ファイルを指定する│ │ ...│ ││ ├── 📂 stg/ # Stg環境│ │ ├── backend.tfvars # high-freqコンポーネントの状態を持つ terraform.tfstate ファイルを指定する│ │ ...│ ││ └── 📂 prd/ # Prd環境│ ├── backend.tfvars # high-freqコンポーネントの状態を持つ terraform.tfstate ファイルを指定する│ ...│├── 📂 low-freq # 低頻度変更グループ│ ├── provider.tf│ ├── output.tf # 他の tfstate ファイルから依存される│ ├── route53.tf│ ├── vpc.tf│ ├── 📂 tes│ │ ├── backend.tfvars # low-freqコンポーネントの状態を持つ terraform.tfstate ファイルを指定する│ │ ...│ ││ ├── 📂 stg│ │ ├── backend.tfvars # low-freqコンポーネントの状態を持つ terraform.tfstate ファイルを指定する│ │ ...│ ││ └── 📂 prd│ ├── backend.tfvars # low-freqコンポーネントの状態を持つ terraform.tfstate ファイルを指定する│ ...│└── 📂 middle-freq # 中頻度変更グループ (高頻度とも低頻度とも言えないリソース) ├── provider.tf ├── remote_state.tf # 他の tfstate ファイルに依存する ├── elasticache.tf ├── rds.tf ├── s3.tf ├── ses.tf ├── 📂 tes │ ├── backend.tfvars # middle-freqコンポーネントの状態を持つ terraform.tfstate ファイルを指定する │ ... │ ├── 📂 stg │ ├── backend.tfvars # middle-freqコンポーネントの状態を持つ terraform.tfstate ファイルを指定する │ ... │ └── 📂 prd ├── backend.tfvars # middle-freqコンポーネントの状態を持つ terraform.tfstate ファイルを指定する ...【変更頻度グループ別】リモートバックエンドのディレクトリー構成▼ 異なるリモートバックエンドの場合AWSリソースの変更頻度グループ別の分割パターンの場合、異なるリモートバックエンドで管理するとバックエンドが増え過ぎてしまいます。そのため、これはお勧めしません。▼ 同じリモートバックエンドの場合この場合では、AWSリソースの変更頻度グループ別に分割したtfstateファイルを、異なるリモートバックエンドで管理します。例えば、tfstateファイル分割に基づいて、リモートバックエンド内のディレクトリー構成例は以下の通りになります。この例では、状態の依存関係図と同じ状況を仮定しています。# Tes環境用バケットの場合🪣 tes-bucket/├── 📂 high-freq│ └── terraform.tfstate # high-freqコンポーネントの状態を持つ│├── 📂 middle-freq│ └── terraform.tfstate # middle-freqコンポーネントの状態を持つ│└── 📂 low-freq └── terraform.tfstate # low-freqコンポーネントの状態を持つ# Stg環境用バケットの場合🪣 stg-bucket/│...# Prd環境用バケットの場合🪣 prd-bucket/│...運用チーム責務範囲別 × プロダクトサブコンポーネント別 - ★この分割方法について運用チーム責務範囲別とプロダクトサブコンポーネント別を組み合わせてtfstateファイルを分割し、中間層もこれに基づいて設計します。この分割方法により、各運用チーム内のサブコンポーネントの管理者が互いに影響を受けずに、terraformコマンドの結果を得られるようになります。【チーム別 × サブコンポーネント別】状態の依存関係図以下の運用チームに分割した状況と仮定します。また、各運用チームでTerraformを変更できる管理者が相当数するため、プロダクトのサブコンポーネント別にも分割したとします。frontendチームapplicationmonitorbackendチームapplicationmonitorsreチームapplicationauthmonitornetworkここで仮定した状況では、各プロダクトのtfstateファイルの依存は一方向最終的に、sreチームの管理する tfstate ファイルに依存しているとします。そのため、想定される状態の依存関係図は以下の通りになります。なお、依存方向は状況によって異なることをご容赦ください。---title: 運用チーム責務範囲別 × プロダクトサブコンポーネント別---%%{init:{'theme':'default'}}%%flowchart TB subgraph AWS subgraph tes-bucket subgraph frontend-team frontendApplication["application-tfstate
(CloudFront, S3, など)"] frontendMonitor["monitor-tfstate
(CloudWatch, など)"] end subgraph backend-team backendApplication["application-tfstate
(API Gateway, ElastiCache, RDS, SES, SNS, など)"] backendMonitor["monitor-tfstate
(CloudWatch, など)"] end subgraph sre-team sreApplication["application-tfstate
Web3層と周辺AWSリソース
(ALB, EC2, ECS, EKS, SNS, など)"] auth["auth-tfstate
(IAM, など)"] sreMonitor["monitor-tfstate
(CloudWatch, など)"] network["network-tfstate
(Route53, VPC, など)"] end frontendApplication-...->network sreApplication-...->auth sreApplication-...->network backendApplication-...->auth backendApplication-...->network frontendMonitor-...->frontendApplication sreMonitor-...->sreApplication backendMonitor-...->backendApplication end subgraph stg-bucket stg["tfstate"] end subgraph prd-bucket prd["tfstate"] end end【チーム別 × サブコンポーネント別】リポジトリのディレクトリー構成▼ 異なるリポジトリの場合この場合では、運用チーム責務範囲別とプロダクトサブコンポーネント別を組み合わせて分割したtfstateファイルを、同じリポジトリで管理します。例えば、tfstateファイル分割に基づいて、リポジトリのディレクトリー構成例は以下の通りになります。この例では、状態の依存関係図と同じ状況を仮定しています。🏭 aws-frontend-team-repository/├── 📂 application/│ ├── provider.tf│ ├── output.tf # 他の tfstate ファイルから依存される│ ├── remote_state.tf # 他の tfstate ファイルに依存する│ ├── cloudfront.tf│ ├── ses.tf│ ├── 📂 tes/ # Tes環境│ │ ├── backend.tfvars # frontendチームが管理するapplicationコンポーネントの状態を持つ terraform.tfstate ファイルを指定する│ │ ...│ ││ ├── 📂 stg/ # Stg環境│ │ ├── backend.tfvars # frontendチームが管理するapplicationコンポーネントの状態を持つ terraform.tfstate ファイルを指定する│ │ ...│ ││ └── 📂 prd/ # Prd環境│ ├── backend.tfvars # frontendチームが管理するapplicationコンポーネントの状態を持つ terraform.tfstate ファイルを指定する│ ...│└── 📂 monitor/ ├── provider.tf ├── remote_state.tf # 他の tfstate ファイルに依存する ├── cloudwatch.tf ├── 📂 tes/ # Tes環境 │ ├── backend.tfvars # frontendチームが管理するmonitorコンポーネントの状態を持つ terraform.tfstate ファイルを指定する │ ... │ ├── 📂 stg/ # Stg環境 │ ├── backend.tfvars # frontendチームが管理するmonitorコンポーネントの状態を持つ terraform.tfstate ファイルを指定する │ ... │ └── 📂 prd/ # Prd環境 ├── backend.tfvars # frontendチームが管理するmonitorコンポーネントの状態を持つ terraform.tfstate ファイルを指定する ...🏭 aws-backend-team-repository/├── 📂 application/│ ├── provider.tf│ ├── output.tf # 他の tfstate ファイルから依存される│ ├── remote_state.tf # 他の tfstate ファイルに依存する│ ├── api_gateway.tf│ ├── elasticache.tf│ ├── rds.tf│ ├── ses.tf│ ├── sns.tf│ ├── 📂 tes/ # Tes環境│ │ ├── backend.tfvars # backendチームが管理するapplicationコンポーネントの状態を持つ terraform.tfstate ファイルを指定する│ │ ...│ ││ ├── 📂 stg/ # Stg環境│ │ ├── backend.tfvars # backendチームが管理するapplicationコンポーネントの状態を持つ terraform.tfstate ファイルを指定する│ │ ...│ ││ └── 📂 prd/ # Prd環境│ ├── backend.tfvars # backendチームが管理するapplicationコンポーネントの状態を持つ terraform.tfstate ファイルを指定する│ ...│└── 📂 monitor/ ├── provider.tf ├── remote_state.tf # 他の tfstate ファイルに依存する ├── cloudwatch.tf ├── 📂 tes/ # Tes環境 │ ├── backend.tfvars # backendチームが管理するmonitorコンポーネントの状態を持つ terraform.tfstate ファイルを指定する │ ... │ ├── 📂 stg/ # Stg環境 │ ├── backend.tfvars # backendチームが管理するmonitorコンポーネントの状態を持つ terraform.tfstate ファイルを指定する │ ... │ └── 📂 prd/ # Prd環境 ├── backend.tfvars # backendチームが管理するmonitorコンポーネントの状態を持つ terraform.tfstate ファイルを指定する ...🏭 aws-sre-team-repository/├── 📂 application/│ ├── provider.tf│ ├── output.tf # 他の tfstate ファイルから依存される│ ├── remote_state.tf # 他の tfstate ファイルに依存する│ ├── alb.tf│ ├── ec2.tf│ ├── ecs.tf│ ├── eks.tf│ ├── 📂 tes/ # Tes環境│ │ ├── backend.tfvars # sreチームが管理するapplicationコンポーネントの状態を持つ terraform.tfstate ファイルを指定する│ │ ...│ ││ ├── 📂 stg/ # Stg環境│ │ ├── backend.tfvars # sreチームが管理するapplicationコンポーネントの状態を持つ terraform.tfstate ファイルを指定する│ │ ...│ ││ └── 📂 prd/ # Prd環境│ ├── backend.tfvars # sreチームが管理するapplicationコンポーネントの状態を持つ terraform.tfstate ファイルを指定する│ ...│├── 📂 auth/│ ├── provider.tf│ ├── output.tf # 他の tfstate ファイルから依存される│ ├── iam.tf│ ├── 📂 tes/ # Tes環境│ │ ├── backend.tfvars # sreチームが管理するauthコンポーネントの状態を持つ terraform.tfstate ファイルを指定する│ │ ...│ ││ ├── 📂 stg/ # Stg環境│ │ ├── backend.tfvars # sreチームが管理するauthコンポーネントの状態を持つ terraform.tfstate ファイルを指定する│ │ ...│ ││ └── 📂 prd/ # Prd環境│ ├── backend.tfvars # sreチームが管理するauthコンポーネントの状態を持つ terraform.tfstate ファイルを指定する│ ...│├── 📂 monitor/│ ├── provider.tf│ ├── remote_state.tf # 他の tfstate ファイルに依存する│ ├── cloudwatch.tf│ ├── 📂 tes/ # Tes環境│ │ ├── backend.tfvars # sreチームが管理するmonitorコンポーネントの状態を持つ terraform.tfstate ファイルを指定する│ │ ...│ ││ ├── 📂 stg/ # Stg環境│ │ ├── backend.tfvars # sreチームが管理するmonitorコンポーネントの状態を持つ terraform.tfstate ファイルを指定する│ │ ...│ ││ └── 📂 prd/ # Prd環境│ ├── backend.tfvars # sreチームが管理するmonitorコンポーネントの状態を持つ terraform.tfstate ファイルを指定する│ ...│└── 📂 network ├── provider.tf ├── output.tf # 他の tfstate ファイルから依存される ├── route53.tf ├── vpc.tf ├── 📂 tes/ # Tes環境 │ ├── backend.tfvars # sreチームが管理するnetworkコンポーネントの状態を持つ terraform.tfstate ファイルを指定する │ ... │ ├── 📂 stg/ # Stg環境 │ ├── backend.tfvars # sreチームが管理するnetworkコンポーネントの状態を持つ terraform.tfstate ファイルを指定する │ ... │ └── 📂 prd/ # Prd環境 ├── backend.tfvars # sreチームが管理するnetworkコンポーネントの状態を持つ terraform.tfstate ファイルを指定する ...▼ 同じリポジトリの場合運用チーム責務範囲別とプロダクトサブコンポーネント別を組み合わせる分割パターンの場合、同じリポジトリで管理するとリポジトリが巨大になってしまいます。そのため、これはお勧めしません。【チーム別 × サブコンポーネント別】リモートバックエンドのディレクトリー構成▼ 異なるリモートバックエンドの場合運用チーム責務範囲別とプロダクトサブコンポーネント別を組み合わせる分割パターンの場合、異なるリモートバックエンドで管理するとバックエンドが増え過ぎてしまいます。そのため、これはお勧めしません。▼ 同じリモートバックエンドの場合この場合では、運用チーム責務範囲別とプロダクトサブコンポーネント別を組み合わせて分割したtfstateファイルを、異なるリモートバックエンドで管理します。例えば、tfstateファイル分割に基づいて、リモートバックエンド内のディレクトリー構成例は以下の通りになります。この例では、状態の依存関係図と同じ状況を仮定しています。# Tes環境用バケットの場合🪣 tes-bucket/├── 📂 frontend-team│ ├── 📂 application│ │ └── terraform.tfstate # frontendチームが管理するapplicationコンポーネントの状態を持つ│ ││ └── 📂 monitor│ └── terraform.tfstate # frontendチームが管理するmonitorコンポーネントの状態を持つ│├── 📂 backend-team│ ├── 📂 application│ │ └── terraform.tfstate # backendチームが管理するapplicationコンポーネントの状態を持つ│ ││ └── 📂 monitor│ └── terraform.tfstate # backendチームが管理するmonitorコンポーネントの状態を持つ│└── 📂 sre-team ├── 📂 application │ └── terraform.tfstate # sreチームが管理するapplicationコンポーネントの状態を持つ │ ├── 📂 auth │ └── terraform.tfstate # sreチームが管理するauthコンポーネントの状態を持つ │ ├── 📂 monitor │ └── terraform.tfstate # sreチームが管理するmonitorコンポーネントの状態を持つ │ └── 📂 network └── terraform.tfstate # sreチームが管理するnetworkコンポーネントの状態を持つ# Stg環境用バケットの場合🪣 stg-bucket/│...# Prd環境用バケットの場合🪣 prd-bucket/│...10. おわりにTerraformのtfstateファイルの分割パターンをもりもり布教しました。ぜひ採用してみたい分割パターンはあったでしょうか。Terraformの開発現場の具体的な要件は千差万別であり、特にtfstateファイル間の状態の依存関係は様々です。もし、この記事を参考に設計してくださる方は、分割パターンを現場に落とし込んで解釈いただけると幸いです🙇🏻‍「自分を信じても…信頼に足る仲間を信じても…誰にもわからない…」(お友達の@nwiizo, 2023, Terraform Modules で再利用できるので最高ではないでしょうか？)謝辞今回、Terraformの分割パターンの収集にあたり、以下の方々からの意見・実装方法も参考にさせていただきました。@kiyo_12_07 さん@masasuzu さん@tozastation さん(アルファベット順)この場で感謝申し上げます🙇🏻‍

【ArgoCD🐙️】KubernetesのマルチテナントパターンとArgoCDの実践テナント設計

【Terraform🧑‍🚀】tfstateファイル分割パターンとディレクトリー構成設計

【ArgoCD🐙】ArgoCDのマイクロサービスアーキテクチャと自動デプロイの仕組み

【Istio⛵️】Istioを安全にアップグレードするカナリア方式とその仕組み

【Istio⛵️】Istioのサービスメッシュとサイドカーインジェクションの仕組み

【Istio⛵️】Istioのサービス間通信を実現するサービスディスカバリーの仕組み