Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
ベストな Terraform ディレクトリ構成を考察してみた
Search
Haruka Sakihara
August 25, 2022
Technology
16
6.6k
ベストな Terraform ディレクトリ構成を考察してみた
22/8/25 HashiTalks:Japanにて発表
Haruka Sakihara
August 25, 2022
Tweet
Share
More Decks by Haruka Sakihara
See All by Haruka Sakihara
初めてのGoogle Cloud by AWS出身者
harukasakihara
1
790
気軽に作ろう!自作AWS CDKコンストラクタ
harukasakihara
3
480
ECSサービスとEC2 AutoScalingの使い心地がほぼ同じな件(???)
harukasakihara
0
530
そのCIは本当に役に立ってますか?~ 高品質なCIプロセスを実現する設計術 ~
harukasakihara
10
2.5k
意外と難しい?エンジンアップグレードとIaCの両立
harukasakihara
4
730
未経験エンジニアがアウトプット駆動で自らのキャリアと生きる道を切り開くまで
harukasakihara
9
5.1k
AWS CDKで作るCloudWatch Dashboard
harukasakihara
4
2.5k
セキュアなTerraformの使い方 ~ 機密情報をコードに含めず環境構築するにはどうしたらいいの?
harukasakihara
21
9k
AssumePolicyの意外なハマりどころ
harukasakihara
1
1.9k
Other Decks in Technology
See All in Technology
Clineを含めたAIエージェントを 大規模組織に導入し、投資対効果を考える / Introducing AI agents into your organization
i35_267
4
1.3k
_第3回__AIxIoTビジネス共創ラボ紹介資料_20250617.pdf
iotcomjpadmin
0
140
監視のこれまでとこれから/sakura monitoring seminar 2025
fujiwara3
10
2.8k
LinkX_GitHubを基点にした_AI時代のプロジェクトマネジメント.pdf
iotcomjpadmin
0
160
[TechNight #90-1] 本当に使える?ZDMの新機能を実践検証してみた
oracle4engineer
PRO
3
140
本部長の代わりに提案書レビュー! KDDI営業が毎日使うAIエージェント「A-BOSS」開発秘話
minorun365
PRO
14
2.3k
知識を整理して未来を作る 〜SKDとAI協業への助走〜
yosh1995
0
130
Amazon S3標準/ S3 Tables/S3 Express One Zoneを使ったログ分析
shigeruoda
2
380
AIエージェントの継続的改善のためオブザーバビリティ
pharma_x_tech
6
1.4k
VCpp Link and Library - C++ breaktime 2025 Summer
harukasao
0
220
(非公式) AWS Summit Japan と 海浜幕張 の歩き方 2025年版
coosuke
PRO
1
320
米国国防総省のDevSecOpsライフサイクルをAWSのセキュリティサービスとOSSで実現
syoshie
2
780
Featured
See All Featured
The MySQL Ecosystem @ GitHub 2015
samlambert
251
13k
Raft: Consensus for Rubyists
vanstee
140
7k
Automating Front-end Workflow
addyosmani
1370
200k
Sharpening the Axe: The Primacy of Toolmaking
bcantrill
43
2.4k
The Pragmatic Product Professional
lauravandoore
35
6.7k
Navigating Team Friction
lara
187
15k
Learning to Love Humans: Emotional Interface Design
aarron
273
40k
Site-Speed That Sticks
csswizardry
10
650
個人開発の失敗を避けるイケてる考え方 / tips for indie hackers
panda_program
107
19k
Embracing the Ebb and Flow
colly
86
4.7k
Improving Core Web Vitals using Speculation Rules API
sergeychernyshev
16
940
Let's Do A Bunch of Simple Stuff to Make Websites Faster
chriscoyier
507
140k
Transcript
ベストなTerraformディレクトリ構成を 考察してみた Thursday, August 25, 2022 Haruka Sakihara
自己紹介 Haruka Sakihara • アクセンチュア株式会社 テクノロジーコンサルティング本部所属 • 普段はクラウドインフラ構築の支援をしております • アプリケーション……プライベートだとGo,
仕事だ と少しPython • インフラ……ほとんどAWS Twitter:@saki_engineer GitHub: @saki-engineering
Terraformのディレクトリ構成、 迷いませんか?
Terraformコードのディレクトリ構成パターン Terraformのディレクトリ構成は様々なパターンが考えられますが、ここでは以下2パターンについ て考察していきたいと思います。 パターン1のディレクトリ構成 パターン2のディレクトリ構成 stg、prdのような環境ごとに ディレクトリを分ける構成 DB, EC2インスタンスのような リソースごとにディレクトリを分ける構成
パターン1: 環境ごとにディレクトリを分ける構成 ある環境を表すIaCコードを1カ所(envs/xxx)にまとめる方式です。複数環境から利用されるコードは モジュール化してmodules配下に配置することもあります。 modules配下 複数環境から使われる 共通モジュールを配置 envs配下 各環境内で必要な リソース定義を記述
(共通モジュール呼び出しもあり) envs/stg直下 module “db” { source = “../../modules/db” } module “ec2” { source = “../../modules/ec2” } module “network” { source = “../../modules/network” }
パターン2: リソースごとにディレクトリを分ける構成 一方こちらはまずリソースごとに最上位ディレクトリを切り、その中に各環境ごとのリソース定義を 記述する方式です。 db配下 各環境ごとのDB設定を記述 ec2/stg直下 resource “aws_instance“ “my_server”
{ // stg用の設定 } network/stg直下 resource “aws_vpc“ “my_vpc” { // stg用の設定 } db/stg直下 resource “aws_db_instance“ “my_db” { // stg用の設定 } ec2配下 各環境ごとのインスタンス設定を記述 network配下 各環境ごとのネットワーク設定を記述
ディレクトリ構成の比較 本セッションでは、「環境ごとにディレクトリを切るパターン」「リソースごとにディレクトリを切 るパターン」それぞれを3つの観点から比較していきます。 パターン2のディレクトリ構成 パターン1のディレクトリ構成 コンセプト apply 回数 tfstate ファイルの
大きさ 同時作業 可能数 環境ごとに ディレクトリを切る リソースごとに ディレクトリを切る
ディレクトリ構成の比較 本セッションでは、「環境ごとにディレクトリを切るパターン」「リソースごとにディレクトリを切 るパターン」それぞれを3つの観点から比較していきます。 パターン2のディレクトリ構成 パターン1のディレクトリ構成 コンセプト apply 回数 tfstate ファイルの
大きさ 同時作業 可能数 環境ごとに ディレクトリを切る リソースごとに ディレクトリを切る
apply回数での比較 パターン1構成の場合、stg環境構築の際に必要なterraform applyの回数は1回で済みます。 一方パターン2構成の場合、stg環境関連リソースのコードを含んだディレクトリの数だけterraform applyが必要です。 パターン1のディレクトリ構成 パターン2のディレクトリ構成 stg環境構築のためには、 envs/stg直下での terraform
apply 1回で済む これら3つすべてで terraform applyを実行 する必要がある (ただし、スクリプトや OSS(Atlantis)を導入することで まとめてapplyも実現可能)
ディレクトリ構成の比較 パターン1の構成だとapplyは1度で済みます。パターン2では複数回のapplyが必要ですが、それをカ バーするスクリプトやOSSを活用することでデメリットをカバーすることができます。 パターン2のディレクトリ構成 パターン1のディレクトリ構成 コンセプト apply 回数 tfstate ファイルの
大きさ 同時作業 可能数 環境ごとに ディレクトリを切る 1回で済む リソースごとに ディレクトリを切る 複数回必要 (スクリプトや Atlantis使用なら 1回で済む) 〇 △
ディレクトリ構成の比較 次に、「生成されるstateファイル」という観点で比較していきます。 パターン2のディレクトリ構成 パターン1のディレクトリ構成 コンセプト apply 回数 tfstate ファイルの 大きさ
同時作業 可能数 環境ごとに ディレクトリを切る 1回で済む リソースごとに ディレクトリを切る 複数回必要 (スクリプトや Atlantis使用なら 1回で済む) 〇 △
tfstateファイルの比較 実際にリソース作成が行われて実環境の構成が変化した際には、Terraformはその変更内容をtfstate ファイル中に書き込み反映させる作業を行います。 AWS Cloud Availability Zone a Availability Zone
b tfstateファイル • AZ-aにEC2インスタンスが2→3個 • AZ-bにEC2インスタンスが2個 .tfファイル • AZ-aにEC2インスタンスが3個 • AZ-bにEC2インスタンスが2個 1. terraform applyの実行 3. リソース作成 2. 差分の検知 4. リソース作成 結果の反映 同内容
tfstateファイルの比較 applyコマンドを実行するディレクトリというのは、tfstateファイルが管理するコード範囲とイコー ルになります。そのため、ディレクトリを細かく区切るということはtfstateファイルを区切るとい うことと同一であり、planやapplyの速度に影響を及ぼします。 stg環境用の tfstateファイルができ る stg環境にあるDB用の tfstateファイルができ る
stg環境にあるインスタンス 用の tfstateファイルができる stg環境にあるNW用の tfstateファイルができ る パターン1のディレクトリ構成 パターン2のディレクトリ構成
tfstateファイルの比較 applyコマンドを実行するディレクトリというのは、tfstateファイルが管理するコード範囲とイコー ルになります。そのため、ディレクトリを細かく区切るということはtfstateファイルを区切るとい うことと同一であり、planやapplyの速度に影響を及ぼします。 stg環境用の tfstateファイルができ る stg環境にあるDB用の tfstateファイルができ る
stg環境にあるインスタンス 用の tfstateファイルができる stg環境にあるNW用の tfstateファイルができ る DBのみの変更の場合でも、 他リソース情報を含んだ このtfstateファイルを扱う必要がある DBのみの変更の場合は、 このtfstateのみ扱えばよい パターン1のディレクトリ構成 パターン2のディレクトリ構成
ディレクトリ構成の比較 パターン1の構成よりもパターン2の構成のほうが、tfstateファイルを細かく区切ることができるた め、plan/applyの高速化が見込めます。 パターン2のディレクトリ構成 パターン1のディレクトリ構成 コンセプト apply 回数 tfstate ファイルの
大きさ 同時作業 可能数 環境ごとに ディレクトリを切る 1回で済む 大きくなるため plan/apply速度が 落ちる リソースごとに ディレクトリを切る 複数回必要 (スクリプトや Atlantis使用なら 1回で済む) 小さく済むため plan/apply速度も速い 〇 × △ 〇
ディレクトリ構成の比較まとめ 最後に、「複数人の開発者がいるチームでTerraformのコードを扱う際に、同時作業がどれだけ可能 になるか」という観点で比較していきます。 パターン2のディレクトリ構成 パターン1のディレクトリ構成 コンセプト apply 回数 tfstate ファイルの
大きさ 同時作業 可能数 環境ごとに ディレクトリを切る 1回で済む 大きくなるため plan/apply速度が 落ちる リソースごとに ディレクトリを切る 複数回必要 (スクリプトや Atlantis使用なら 1回で済む) 小さく済むため plan/apply速度も速い 〇 × △ 〇
同時作業数の比較 – パターン1構成の場合 最上位ディレクトリを環境ごとに切る場合には、envs/stg直下とenvs/prd直下にそれぞれstateファ イルが生成されることになります。そのため、ある環境内にあるリソースの変更はすべて同時に plan/applyされることになります。 …stg用のstate …prd用のstate stateファイル構成 リソース変更の際に参照されるstateファイル
2つのリソース変更を吸収する 1つのstateが
同時作業数の比較 – パターン1構成の場合 リソースごとにディレクトリを切る場合には、各環境・各リソースごとにstateが生成されます。そ のため、異なるリソースの変更は異なるstateを用いてplan/applyが実行されます。 …db/stg用のstate …db/prd用のstate …ec2/prd用のstate …ec2/stg用のstate …network/prd用のstate
…network/stg用のstate dbの変更はこのstateが吸収 インスタンスの変更は このstateが吸収 stateファイル構成 リソース変更の際に参照されるstateファイル
同時作業数の比較 Terraformにおいて、あるコードが同じstateファイルに属しているというのは「plan/applyが同時 に行われる」というだけでなく、Lock機能によって並列作業可能なapply数が制限されるということ も意味します。 envs stg ……ステージング環境用の コードを格納 prd ……本番環境用の
コードを格納 stg環境用のstateファイルができる prd環境用のstateファイルができる 1つの同じstateファイルに属しているコードは…… • まとめてplan/applyが行われる • このコードに対して複数個同時に applyができないように、Lockがかかる
(余談)planの並行作業 Terraformで複数個のplanを同時並行して行うと、どれか一つのapplyが行われるとその他のplan結 果が正しくないものになるという問題があります。 AWS Cloud Terraformコード インスタンス1個 PR1 PR2 実環境
Terraformコード インスタンス3個 plan結果 インスタンス+1個 plan結果 インスタンス-1個 plan実行 plan実行 AWS Cloud apply実行 plan結果 インスタンス+1個 OutDated!
ディレクトリ構成の比較まとめ Tfstateファイルを細かく区切ることで、apply時にかかるロックの範囲をも細かく区切ることができ ます。結果、同時作業可能数がパターン2のほうが多くなることとなります。 パターン2のディレクトリ構成 パターン1のディレクトリ構成 コンセプト apply 回数 tfstate ファイルの
大きさ 同時作業 可能数 環境ごとに ディレクトリを切る 1回で済む 大きくなるため plan/apply速度が 落ちる 同環境内では 別作業を同時に できない リソースごとに ディレクトリを切る 複数回必要 (スクリプトや Atlantis使用なら 1回で済む) 小さく済むため plan/apply速度も速い 同環境内でも リソースが別なら 同時に作業可能 〇 × × △ 〇 〇
ディレクトリ構成の比較まとめ 従来なら考えずらかったパターン2のディレクトリ構成も、複数人で使用するワークフロー構築・ Atlantisの使用前提で考えると十分メリットがある構成と言えると思います。 パターン2のディレクトリ構成 パターン1のディレクトリ構成 コンセプト apply 回数 tfstate ファイルの
大きさ 同時作業 可能数 環境ごとに ディレクトリを切る 1回で済む 大きくなるため plan/apply速度が 落ちる 同環境内では 別作業を同時に できない リソースごとに ディレクトリを切る 複数回必要 (スクリプトや Atlantis使用なら 1回で済む) 小さく済むため plan/apply速度も速い 同環境内でも リソースが別なら 同時に作業可能 〇 × × △ 〇 〇
Thank You ご意見、ご質問ありましたらお気軽にご連絡下さい
[email protected]
Haruka Sakihara(崎原 晴香)