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の本を書いたのか? - 著者陣に聞く!『Terraformではじめる...
Search
Ryoma Fujiwara
August 05, 2025
Programming
4
630
なぜ今、Terraformの本を書いたのか? - 著者陣に聞く!『Terraformではじめる実践IaC』登壇資料
著者陣に聞く!『Terraformではじめる実践IaC』
https://findy.connpass.com/event/361185/
の登壇資料です。
Ryoma Fujiwara
August 05, 2025
Tweet
Share
More Decks by Ryoma Fujiwara
See All by Ryoma Fujiwara
偶発性を好奇心で味方にする
fufuhu
2
670
Harvesterという選択肢 (RancherJP Online Meetup #05)
fufuhu
1
180
個人検証アカウントの管理どんな感じでやってますか_JAWSUGランチ共有会発表資料
fufuhu
3
1.1k
AWS OrganizationsとIAM Identity Center, Terraformを連携した権限管理
fufuhu
5
10k
過去のセキュリティ系セッション振り返り
fufuhu
2
580
heyにおけるCI/CDの現状と課題
fufuhu
3
1.2k
heyにおけるSREの大切さ~マルチプロダクト運用の「楽しさ」と「難しさ」および今後の展望~
fufuhu
3
10k
STORES決済におけるEC2からECS Fargateへの移行〜無停止要件も添えて〜
fufuhu
3
2.4k
Rancher Harvesterの紹介
fufuhu
4
1.8k
Other Decks in Programming
See All in Programming
書き捨てではなく継続開発可能なコードをAIコーディングエージェントで書くために意識していること
shuyakinjo
1
290
AHC051解法紹介
eijirou
0
610
Flutter로 Gemini와 MCP를 활용한 Agentic App 만들기 - 박제창 2025 I/O Extended Seoul
itsmedreamwalker
0
150
LLMOpsのパフォーマンスを支える技術と現場で実践した改善
po3rin
8
960
WebAssemblyインタプリタを書く ~Component Modelを添えて~
ruccho
1
880
マイコンでもRustのtestがしたい その2/KernelVM Tokyo 18
tnishinaga
2
2.3k
Langfuseと歩む生成AI活用推進
licux
3
290
The state patternの実践 個人開発で培ったpractice集
miyanokomiya
0
140
Go製CLIツールをnpmで配布するには
syumai
2
1.2k
MCP連携で加速するAI駆動開発/mcp integration accelerates ai-driven-development
bpstudy
0
310
Portapad紹介プレゼンテーション
gotoumakakeru
1
130
画像コンペでのベースラインモデルの育て方
tattaka
3
1.8k
Featured
See All Featured
The Straight Up "How To Draw Better" Workshop
denniskardys
236
140k
Producing Creativity
orderedlist
PRO
347
40k
Bootstrapping a Software Product
garrettdimon
PRO
307
110k
The Web Performance Landscape in 2024 [PerfNow 2024]
tammyeverts
9
770
Intergalactic Javascript Robots from Outer Space
tanoku
272
27k
Performance Is Good for Brains [We Love Speed 2024]
tammyeverts
10
1k
Exploring the Power of Turbo Streams & Action Cable | RailsConf2023
kevinliebholz
34
6k
Making Projects Easy
brettharned
117
6.3k
Responsive Adventures: Dirty Tricks From The Dark Corners of Front-End
smashingmag
251
21k
Thoughts on Productivity
jonyablonski
69
4.8k
Build your cross-platform service in a week with App Engine
jlugia
231
18k
Building an army of robots
kneath
306
45k
Transcript
©MNTSQ, Ltd. 2025/8/5 なぜ今、Terraformの本を書いたのか? ~現場の壁とその乗り越え方~ 著者陣に聞く!『Terraformで始める実践IaC』登壇資料 藤原 涼馬
©MNTSQ, Ltd. 2 自己紹介 藤原 涼馬 (@RyoMa_0923) MNTSQ株式会社 SREチームマネージャー 兼
セキュリティ推進室マネージャー 2011 情報科学 (生命情報工学分野)修了 2016 新日鉄ソリューションズ (現日鉄ソリューションズ) 研究開発センター 研究員 リクルートテクノロジーズ (現 リクルート) インフラエンジニア・SRE 2021 ヘイ(現 STORES) SRE 2023 MNTSQ SREチームマネージャー 兼 セキュリティ推進室マネージャー 主業 副業 やってたこと・成果物など APM(AppDynamics)製品国内導入 負荷試験コンサルティング・実施サービス担当 データベース(Oracle)パフォーマンスチューニング 各種プロジェクト実行支援 クラウドインフラアーキ標準化 イベント運営(Rancher JP/Cloud Native Days Tokyo) 新入社員研修講師 ID基盤のVMからコンテナ移行 STORES決済のインフラ立て直し(&Spring Boot移行) 全社セキュリティの改善 マルチテナント移行 監視・モニタリング改善 セキュリティ改善 新規サービスのインフラ構築・運用 病理画像変換・ アノテーションシステム開発 薬局向け診断要約サービス 医療情報の構造化研究開発
自己紹介 • 伊藤 太斉 (@kaedemalu) ◦ Future Architect株式会社 Technology Innovation
Group ◦ メディアユニット インフラリーダー/セキュリティマネージャー • 職歴 ◦ 2018~ 株式会社アピリッツ (Webエンジニア) ◦ 2019~ 現職 ▪ アパレル、小売、製造業などのシステムのインフラ設計、構築、技術コンサルを担当 ▪ 現在は新聞社向けのシステムのインフラ領域をリーディング • コミュニティ ◦ GCPUG Shonan ◦
©MNTSQ, Ltd. 4 書き始めの経緯
©MNTSQ, Ltd. 5 書き始めの経緯
©MNTSQ, Ltd. 6 結果
©MNTSQ, Ltd. 7 本日のテーマ なぜ今、Terraformの本を書いたのか?
©MNTSQ, Ltd. 8 本日のテーマ なぜ今、Terraformの本を書いたのか?
©MNTSQ, Ltd. 9 なぜ今、Terraformの本を書いたのか? なぜ今、Terraformを使わないのか?(反語) Why not you use Terraform
now?
©MNTSQ, Ltd. 10 なぜ今、Terraformの本を書いたのか? なぜ今、Terraformを使わないのか?(反語) Why not you use Terraform
now? なぜ IaC、なぜTerraformなのか? を説明するには、ある程度流れ(歴史?)を追う必要がある
©MNTSQ, Ltd. 11 IaC、Terraformに至る流れを見てみる パブリッククラウド以前 パブリッククラウド以後 マルチクラウド
©MNTSQ, Ltd. 12 IaC、Terraformに至る流れを見てみる パブリッククラウド以前 パブリッククラウド以後 マルチクラウド
©MNTSQ, Ltd. 13 • (当然だが)この頃からアプリケーションコードはコードベースで 管理されていた ◦ バージョン管理の仕組みの利用も一般的 • ITインフラストラクチャ管理は...?
パブリッククラウド以前
©MNTSQ, Ltd. 14 • (当然だが)この頃からアプリケーションコードはコードベースで 管理されていた ◦ バージョン管理の仕組みの利用も一般的 • ITインフラストラクチャ管理は...?
パブリッククラウド以前
©MNTSQ, Ltd. 15 パブリッククラウド以前のITインフラストラクチャ管理 スプレッドシートでの構成管理 構成要素ごとの各種作業手順書 (スプレッドシート管理)
©MNTSQ, Ltd. 16 パブリッククラウド以前のITインフラストラクチャ管理 スプレッドシートでの構成管理 構成要素ごとの各種作業手順書 (スプレッドシート管理) これを完全に否定するものではないが、 課題は存在する
©MNTSQ, Ltd. 17 スプレッドシートでの構成管理の課題 スプレッドシートでの構成管理 実際の構成
©MNTSQ, Ltd. 18 スプレッドシートでの構成管理の課題 スプレッドシートでの構成管理 実際の構成 コストをそれなりにかけないと差分がどんどん大きくなりがち 構成変更の頻度が高いほどそうなる
©MNTSQ, Ltd. 19 構成要素ごとの各種作業手順書の問題 構成要素ごとの各種作業手順書 (スプレッドシート管理) システム規模 準備・管理コスト
©MNTSQ, Ltd. 20 構成要素ごとの各種作業手順書の問題 構成要素ごとの各種作業手順書 (スプレッドシート管理) システム規模 準備・管理コスト 構成要素が増えるごとに対象の手順書は増加 ≒
管理コストが構成要素に比例して増える
©MNTSQ, Ltd. 21 物理作業という圧倒的なボトルネックが存在したことや、 それに伴うシステム構成の単純化への圧力が確実に存在することで 構成管理や作業手順書の手間、コストは致命的な問題にはなってなかった 大変ではあるが、物理的な部分での課題が存在した ハードウェア選定と購買 ラッキング・キッティング 各種配線等引き回し
©MNTSQ, Ltd. 22 IaC、Terraformに至る流れを見てみる パブリッククラウド以前 パブリッククラウド以後 マルチクラウド
©MNTSQ, Ltd. 23 パブリッククラウド以後
©MNTSQ, Ltd. 24 ほとんどの物理的作業から解放された GUIから操作するだけでシステムを構成できる パブリッククラウド以後
©MNTSQ, Ltd. 25 ほとんどの物理的作業から解放された GUIから操作するだけでシステムを構成できる パブリッククラウド以後 マネージドサービスなどもフル活用すればあっという間に 大規模な構成を持ったシステムを構成できてしまう
©MNTSQ, Ltd. 26 物理作業のボトルネックが消失した結果として一気にシステム構成が複雑化しやすくなったた(それが良いことか悪いことなのかはさておき) パブリッククラウドが広まることによるシステム構造の複雑化 パブリッククラウド以前のシステム パブリッククラウド以後のシステム
©MNTSQ, Ltd. 27 物理作業のボトルネックが消失した結果として一気にシステム構成が複雑化しやすくなったた(それが良いことか悪いことなのかはさておき) パブリッククラウドが広まることによるシステム構造の複雑化 パブリッククラウド以前のシステム パブリッククラウド以後のシステム
©MNTSQ, Ltd. 28 物理作業のボトルネックが消失した結果として一気にシステム構成が複雑化しやすくなったた(それが良いことか悪いことなのかはさておき) パブリッククラウドが広まることによるシステム構造の複雑化 パブリッククラウド以前のシステム パブリッククラウド以後のシステム クラウド以前の手法のみでは管理コストが爆発してしまう (もちろん一定程度はこういった管理は必要ではある)
©MNTSQ, Ltd. 29 物理作業のボトルネックが消失した結果として一気にシステム構成が複雑化しやすくなったた(それが良いことか悪いことなのかはさておき) パブリッククラウドが広まることによるシステム構造の複雑化 パブリッククラウド以前のシステム パブリッククラウド以後のシステム 構成に複雑なクラウド以前の手法のみでは管理コストが爆発してしまう (もちろん一定程度はこういった管理は必要ではある) どうする?
©MNTSQ, Ltd. 30 インフラストラクチャをコードで管理すればいいじゃない?
©MNTSQ, Ltd. 31 • パブリッククラウドプロバイダーからIaCサービスが出てきた ◦ AWS CloudFormation ◦ Google
Cloud Deployment Manager (→ Infrastructure Manager) ◦ Azure Bicep インフラストラクチャをコードで管理(IaC; Infrastructure as Code)すればいいじゃない?
©MNTSQ, Ltd. 32 • パブリッククラウドプロバイダーからIaCサービスが出てきた ◦ AWS CloudFormation ◦ Google
Cloud Deployment Manager (→ Infrastructure Manager) ◦ Azure Bicep インフラストラクチャをコードで管理(IaC; Infrastructure as Code)すればいいじゃない? コードでインフラストラクチャを管理することで管理コストを下げることを狙った
©MNTSQ, Ltd. 33 Infrastructure as Code コードでインフラストラクチャを管理することで 1. 実際の環境と構成管理の差分を最小化する 2.
構成要素ごとの構築手順を均一化する を目指した && 一定の成功をみた
©MNTSQ, Ltd. 34 IaC、Terraformに至る流れを見てみる パブリッククラウド以前 パブリッククラウド以後 マルチクラウド
©MNTSQ, Ltd. 35 一つのパブリッククラウドではなく複数のパブリッククラ ウドを組み合わせてサービスを提供することが珍しくない 単一のSaaSなどの提供で複数クラウドの機能を利用するのが珍しくなくなってきた
©MNTSQ, Ltd. 36 • パブリッククラウドプロバイダーからIaCサービスが出てきた ◦ AWS CloudFormation ◦ Google
Cloud Deployment Manager (→ Infrastructure Manager) ◦ Azure Bicep インフラストラクチャをコードで管理(IaC; Infrastructure as Code)すればいいじゃない?
©MNTSQ, Ltd. 37 • パブリッククラウドプロバイダーからIaCサービスが出てきた ◦ AWS CloudFormation ◦ Google
Cloud Deployment Manager (→ Infrastructure Manager) ◦ Azure Bicep インフラストラクチャをコードで管理(IaC; Infrastructure as Code)すればいいじゃない? すべてを個別のパブリッククラウドプロバイダー提供のサービスを学習して記述するか?
©MNTSQ, Ltd. 38 • パブリッククラウドプロバイダーからIaCサービスが出てきた ◦ AWS CloudFormation ◦ Google
Cloud Deployment Manager (→ Infrastructure Manager) ◦ Azure Bicep インフラストラクチャをコードで管理(IaC; Infrastructure as Code)すればいいじゃない? すべてを個別のパブリッククラウドプロバイダー提供のサービスを学習して記述するか? 学習コストを考えると避けたい
©MNTSQ, Ltd. 39 ということでTerraform
©MNTSQ, Ltd. 40 • 特定のパブリッククラウドに閉じたものではない ◦ いわゆるメガクラウドには対応 ◦ メガクラウド以外のSaaSなどにも対応している(Datadog, PegerDuty,
NewRelicなど) Terraformを使うべき理由
©MNTSQ, Ltd. 41 • 特定のパブリッククラウドに閉じたものではない ◦ いわゆるメガクラウドには対応 ◦ メガクラウド以外のSaaSなどにも対応している(Datadog, PegerDuty,
NewRelicなど) • メガクラウドでも実質的に1stチョイスとして公式に提示されているものがある Terraformを使うべき理由 Google Cloud Infrastructure Manager https://cloud.google.com/infrastructure-manager/docs/overview?hl=ja Deployment Manager(YAMLベースの独自 DSLによるIaCサービス)は 2025/12/31で終了、公式な乗り換え先として Terraformを使ってインフラストラ クチャを管理する Infrastructure Managerを提示 Oracle Cloud Infrastructure Resource Manager https://www.oracle.com/jp/cloud/cloud-native/resource-manager/ Terraformを使ってインフラストラクチャを管理する Resource Managerを提供 (一般的に使用されている オープンソースの業界標準である Terraformに基づいており ...との記 述まである)
©MNTSQ, Ltd. 42 • Hashicorp Configuration Language(HCL; HCL is the
HashiCorp configuration language. )のできが良い ◦ HCL2 (Terraformだと0.12以降)に移行してから、かなり使い勝手が改善されている ▪ 逆にいうとそれ以前はそれなりに癖が強かった ◦ 宣言型と手続き型のミックスを絶妙なバランスで実現している点 ▪ 原則として宣言型 ▪ 手続き型的な側面はあるが、”手続きの類はあまり書いてくれるな”というメッセージは感じる • マルチクラウドでのインフラの構築・管理手順を定型化できる ◦ terraform init/plan/apply、どのクラウドでも基本は同じ 個人的なTerraformの良いポイント
©MNTSQ, Ltd. 43 Terraformを利用する上での注意
©MNTSQ, Ltd. 44 Terraformを利用する上での注意
©MNTSQ, Ltd. 45 Terraformを利用する上での注意 コードを書く上での課題に似たようなところがある
©MNTSQ, Ltd. 46 1. 環境差分の最小化 ◦ そもそもアーキテクチャレベルでコンポーネントの差分を最小にする ◦ スケールは違っても有無はことならないようにする 2.
state分割の判断 ◦ terraform plan/applyの影響範囲はstate単位で分割される ◦ plan/apply時に自分が意図しない部分の変更などが起きることを考えると分割しておきたい ◦ 適切に分割しないとコードのマージなどの流れが複雑になりがち ◦ コードの変更頻度(≒ライフサイクル)と関係性が判断ポイント 3. モジュールのパラメータと引数の適切な管理 ◦ カプセル化 ◦ リモートステート参照などの際も効いてくる ◦ Platform Engineering的にガードレールを提供したりする場合には特に重要になる 4. リソースの命名規則 ◦ dataソースで参照したりする際に効いてくるので意識しましょう、ルール化しましょう 5. 個別クラウドの知識 ◦ “この設定って無停止で変更できるっけ?”といった知識、リソースごとの関係性の知識は必要 ◦ ただし、リソースごとの関係性をコードとして明示できる点はメリットと捉えることもできる(影響範囲の把握、学習効果など) 気をつけるポイント
©MNTSQ, Ltd. 47 1. 環境差分の最小化 ◦ そもそもアーキテクチャレベルでコンポーネントの差分を最小にする ◦ スケールは違っても有無はことならないようにする 2.
state分割の判断 ◦ terraform plan/applyの影響範囲はstate単位で分割される ◦ plan/apply時に自分が意図しない部分の変更などが起きることを考えると分割しておきたい ◦ 適切に分割しないとコードのマージなどの流れが複雑になりがち ◦ コードの変更頻度(≒ライフサイクル)と関係性が判断ポイント 3. モジュールのパラメータと引数の適切な管理 ◦ カプセル化 ◦ リモートステート参照などの際も効いてくる ◦ Platform Engineering的にガードレールを提供したりする場合には特に重要になる 4. リソースの命名規則 ◦ dataソースで参照したりする際に効いてくるので意識しましょう、ルール化しましょう 5. 個別クラウドの知識 ◦ “この設定って無停止で変更できるっけ?”といった知識、リソースごとの関係性の知識は必要 ◦ ただし、リソースごとの関係性をコードとして明示できる点はメリットと捉えることもできる(影響範囲の把握、学習効果など) 気をつけるポイント もう少し具体的な話はパネルディスカッション(or 懇親会)にて
©MNTSQ, Ltd. 48 • マルチクラウド時代にIaCするならTerraformを1stチョイスとして検討してみましょう ◦ パブリッククラウドの公式IaCツールがTerraformなパターンも出てきています ◦ Datadog, PagerDuty,
NewRelicなどの設定もコード管理できるようになります • Terraformで気をつけるポイント ◦ アプリケーションコードを書く際の課題とほぼ同じ まとめ
None