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
890
なぜ今、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
時間軸から考えるTerraformを使う理由と留意点
fufuhu
16
5.1k
Rancher と Terraform
fufuhu
2
650
偶発性を好奇心で味方にする
fufuhu
2
750
Harvesterという選択肢 (RancherJP Online Meetup #05)
fufuhu
1
210
個人検証アカウントの管理どんな感じでやってますか_JAWSUGランチ共有会発表資料
fufuhu
3
1.1k
AWS OrganizationsとIAM Identity Center, Terraformを連携した権限管理
fufuhu
5
10k
過去のセキュリティ系セッション振り返り
fufuhu
2
590
heyにおけるCI/CDの現状と課題
fufuhu
3
1.2k
heyにおけるSREの大切さ~マルチプロダクト運用の「楽しさ」と「難しさ」および今後の展望~
fufuhu
3
10k
Other Decks in Programming
See All in Programming
ABEMAモバイルアプリが Kotlin Multiplatformと歩んだ5年 ─ 導入と運用、成功と課題 / iOSDC 2025
akkyie
0
310
階層構造を表現するデータ構造とリファクタリング 〜1年で10倍成長したプロダクトの変化と課題〜
yuhisatoxxx
3
860
SpecKitでどこまでできる? コストはどれくらい?
leveragestech
0
440
猫と暮らすネットワークカメラ生活🐈 ~Vision frameworkでペットを愛でよう~ / iOSDC Japan 2025
yutailang0119
0
210
10年もののAPIサーバーにおけるCI/CDの改善の奮闘
mbook
0
680
AIエージェント時代における TypeScriptスキーマ駆動開発の新たな役割
bicstone
4
1.2k
ててべんす独演会〜Flowの全てを語ります〜
tbsten
1
220
CSC305 Lecture 04
javiergs
PRO
0
230
CSC305 Lecture 02
javiergs
PRO
1
260
高度なUI/UXこそHotwireで作ろう Kaigi on Rails 2025
naofumi
4
3k
Let's Write a Train Tracking Algorithm
twocentstudios
0
220
NetworkXとGNNで学ぶグラフデータ分析入門〜複雑な関係性を解き明かすPythonの力〜
mhrtech
3
940
Featured
See All Featured
The Power of CSS Pseudo Elements
geoffreycrofte
79
6k
The Web Performance Landscape in 2024 [PerfNow 2024]
tammyeverts
9
840
Design and Strategy: How to Deal with People Who Don’t "Get" Design
morganepeng
132
19k
Producing Creativity
orderedlist
PRO
347
40k
BBQ
matthewcrist
89
9.8k
ReactJS: Keep Simple. Everything can be a component!
pedronauck
667
120k
Into the Great Unknown - MozCon
thekraken
40
2.1k
Thoughts on Productivity
jonyablonski
70
4.8k
What's in a price? How to price your products and services
michaelherold
246
12k
Designing for Performance
lara
610
69k
How STYLIGHT went responsive
nonsquared
100
5.8k
Speed Design
sergeychernyshev
32
1.1k
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