なぜ今、Terraformの本を書いたのか？ - 著者陣に聞く！『Terraformではじめる実践IaC』登壇資料

著者陣に聞く！『Terraformではじめる実践IaC』
https://findy.connpass.com/event/361185/

の登壇資料です。

Transcript

1. ©MNTSQ, Ltd. 2025/8/5 なぜ今、Terraformの本を書いたのか？ ~現場の壁とその乗り越え方~ 著者陣に聞く!『Terraformで始める実践IaC』登壇資料 藤原 涼馬
2. ©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移行) 全社セキュリティの改善 マルチテナント移行 監視・モニタリング改善 セキュリティ改善 新規サービスのインフラ構築・運用 病理画像変換・ アノテーションシステム開発 薬局向け診断要約サービス 医療情報の構造化研究開発
3. 自己紹介 • 伊藤 太斉 (@kaedemalu) ◦ Future Architect株式会社 Technology Innovation Group ◦ メディアユニット インフラリーダー/セキュリティマネージャー • 職歴 ◦ 2018~ 株式会社アピリッツ (Webエンジニア) ◦ 2019~ 現職 ▪ アパレル、小売、製造業などのシステムのインフラ設計、構築、技術コンサルを担当 ▪ 現在は新聞社向けのシステムのインフラ領域をリーディング • コミュニティ ◦ GCPUG Shonan ◦
4. ©MNTSQ, Ltd. 4 書き始めの経緯
5. ©MNTSQ, Ltd. 5 書き始めの経緯
6. ©MNTSQ, Ltd. 6 結果
7. ©MNTSQ, Ltd. 7 本日のテーマ なぜ今、Terraformの本を書いたのか？
8. ©MNTSQ, Ltd. 8 本日のテーマ なぜ今、Terraformの本を書いたのか？
9. ©MNTSQ, Ltd. 9 なぜ今、Terraformの本を書いたのか？ なぜ今、Terraformを使わないのか？（反語) Why not you use Terraform now?
10. ©MNTSQ, Ltd. 10 なぜ今、Terraformの本を書いたのか？ なぜ今、Terraformを使わないのか？（反語) Why not you use Terraform now? なぜ IaC、なぜTerraformなのか？ を説明するには、ある程度流れ(歴史?)を追う必要がある
11. ©MNTSQ, Ltd. 11 IaC、Terraformに至る流れを見てみる パブリッククラウド以前 パブリッククラウド以後 マルチクラウド
12. ©MNTSQ, Ltd. 12 IaC、Terraformに至る流れを見てみる パブリッククラウド以前 パブリッククラウド以後 マルチクラウド
13. ©MNTSQ, Ltd. 13 • (当然だが)この頃からアプリケーションコードはコードベースで 管理されていた ◦ バージョン管理の仕組みの利用も一般的 • ITインフラストラクチャ管理は...？ パブリッククラウド以前
14. ©MNTSQ, Ltd. 14 • (当然だが)この頃からアプリケーションコードはコードベースで 管理されていた ◦ バージョン管理の仕組みの利用も一般的 • ITインフラストラクチャ管理は...？ パブリッククラウド以前
15. ©MNTSQ, Ltd. 15 パブリッククラウド以前のITインフラストラクチャ管理 スプレッドシートでの構成管理 構成要素ごとの各種作業手順書 (スプレッドシート管理)
16. ©MNTSQ, Ltd. 16 パブリッククラウド以前のITインフラストラクチャ管理 スプレッドシートでの構成管理 構成要素ごとの各種作業手順書 (スプレッドシート管理) これを完全に否定するものではないが、 課題は存在する
17. ©MNTSQ, Ltd. 17 スプレッドシートでの構成管理の課題 スプレッドシートでの構成管理 実際の構成
18. ©MNTSQ, Ltd. 18 スプレッドシートでの構成管理の課題 スプレッドシートでの構成管理 実際の構成 コストをそれなりにかけないと差分がどんどん大きくなりがち 構成変更の頻度が高いほどそうなる
19. ©MNTSQ, Ltd. 19 構成要素ごとの各種作業手順書の問題 構成要素ごとの各種作業手順書 (スプレッドシート管理) システム規模 準備・管理コスト
20. ©MNTSQ, Ltd. 20 構成要素ごとの各種作業手順書の問題 構成要素ごとの各種作業手順書 (スプレッドシート管理) システム規模 準備・管理コスト 構成要素が増えるごとに対象の手順書は増加 ≒ 管理コストが構成要素に比例して増える
21. ©MNTSQ, Ltd. 21 物理作業という圧倒的なボトルネックが存在したことや、 それに伴うシステム構成の単純化への圧力が確実に存在することで 構成管理や作業手順書の手間、コストは致命的な問題にはなってなかった 大変ではあるが、物理的な部分での課題が存在した ハードウェア選定と購買 ラッキング・キッティング 各種配線等引き回し
22. ©MNTSQ, Ltd. 22 IaC、Terraformに至る流れを見てみる パブリッククラウド以前 パブリッククラウド以後 マルチクラウド
23. ©MNTSQ, Ltd. 23 パブリッククラウド以後
24. ©MNTSQ, Ltd. 24 ほとんどの物理的作業から解放された GUIから操作するだけでシステムを構成できる パブリッククラウド以後
25. ©MNTSQ, Ltd. 25 ほとんどの物理的作業から解放された GUIから操作するだけでシステムを構成できる パブリッククラウド以後 マネージドサービスなどもフル活用すればあっという間に 大規模な構成を持ったシステムを構成できてしまう
26. ©MNTSQ, Ltd. 26 物理作業のボトルネックが消失した結果として一気にシステム構成が複雑化しやすくなったた(それが良いことか悪いことなのかはさておき) パブリッククラウドが広まることによるシステム構造の複雑化 パブリッククラウド以前のシステム パブリッククラウド以後のシステム
27. ©MNTSQ, Ltd. 27 物理作業のボトルネックが消失した結果として一気にシステム構成が複雑化しやすくなったた(それが良いことか悪いことなのかはさておき) パブリッククラウドが広まることによるシステム構造の複雑化 パブリッククラウド以前のシステム パブリッククラウド以後のシステム
28. ©MNTSQ, Ltd. 28 物理作業のボトルネックが消失した結果として一気にシステム構成が複雑化しやすくなったた(それが良いことか悪いことなのかはさておき) パブリッククラウドが広まることによるシステム構造の複雑化 パブリッククラウド以前のシステム パブリッククラウド以後のシステム クラウド以前の手法のみでは管理コストが爆発してしまう (もちろん一定程度はこういった管理は必要ではある)
29. ©MNTSQ, Ltd. 29 物理作業のボトルネックが消失した結果として一気にシステム構成が複雑化しやすくなったた(それが良いことか悪いことなのかはさておき) パブリッククラウドが広まることによるシステム構造の複雑化 パブリッククラウド以前のシステム パブリッククラウド以後のシステム 構成に複雑なクラウド以前の手法のみでは管理コストが爆発してしまう (もちろん一定程度はこういった管理は必要ではある) どうする？ 

30. ©MNTSQ, Ltd. 30 インフラストラクチャをコードで管理すればいいじゃない？
31. ©MNTSQ, Ltd. 31 • パブリッククラウドプロバイダーからIaCサービスが出てきた ◦ AWS CloudFormation ◦ Google Cloud Deployment Manager (→ Infrastructure Manager) ◦ Azure Bicep インフラストラクチャをコードで管理(IaC; Infrastructure as Code)すればいいじゃない？
32. ©MNTSQ, Ltd. 32 • パブリッククラウドプロバイダーからIaCサービスが出てきた ◦ AWS CloudFormation ◦ Google Cloud Deployment Manager (→ Infrastructure Manager) ◦ Azure Bicep インフラストラクチャをコードで管理(IaC; Infrastructure as Code)すればいいじゃない？ コードでインフラストラクチャを管理することで管理コストを下げることを狙った
33. ©MNTSQ, Ltd. 33 Infrastructure as Code コードでインフラストラクチャを管理することで 1. 実際の環境と構成管理の差分を最小化する 2. 構成要素ごとの構築手順を均一化する を目指した && 一定の成功をみた
34. ©MNTSQ, Ltd. 34 IaC、Terraformに至る流れを見てみる パブリッククラウド以前 パブリッククラウド以後 マルチクラウド
35. ©MNTSQ, Ltd. 35 一つのパブリッククラウドではなく複数のパブリッククラ ウドを組み合わせてサービスを提供することが珍しくない 単一のSaaSなどの提供で複数クラウドの機能を利用するのが珍しくなくなってきた
36. ©MNTSQ, Ltd. 36 • パブリッククラウドプロバイダーからIaCサービスが出てきた ◦ AWS CloudFormation ◦ Google Cloud Deployment Manager (→ Infrastructure Manager) ◦ Azure Bicep インフラストラクチャをコードで管理(IaC; Infrastructure as Code)すればいいじゃない？
37. ©MNTSQ, Ltd. 37 • パブリッククラウドプロバイダーからIaCサービスが出てきた ◦ AWS CloudFormation ◦ Google Cloud Deployment Manager (→ Infrastructure Manager) ◦ Azure Bicep インフラストラクチャをコードで管理(IaC; Infrastructure as Code)すればいいじゃない？ すべてを個別のパブリッククラウドプロバイダー提供のサービスを学習して記述するか？
38. ©MNTSQ, Ltd. 38 • パブリッククラウドプロバイダーからIaCサービスが出てきた ◦ AWS CloudFormation ◦ Google Cloud Deployment Manager (→ Infrastructure Manager) ◦ Azure Bicep インフラストラクチャをコードで管理(IaC; Infrastructure as Code)すればいいじゃない？ すべてを個別のパブリッククラウドプロバイダー提供のサービスを学習して記述するか？ 学習コストを考えると避けたい
39. ©MNTSQ, Ltd. 39 ということでTerraform
40. ©MNTSQ, Ltd. 40 • 特定のパブリッククラウドに閉じたものではない ◦ いわゆるメガクラウドには対応 ◦ メガクラウド以外のSaaSなどにも対応している(Datadog, PegerDuty, NewRelicなど) Terraformを使うべき理由
41. ©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に基づいており ...との記 述まである)
42. ©MNTSQ, Ltd. 42 • Hashicorp Configuration Language(HCL; HCL is the HashiCorp configuration language. )のできが良い ◦ HCL2 (Terraformだと0.12以降)に移行してから、かなり使い勝手が改善されている ▪ 逆にいうとそれ以前はそれなりに癖が強かった ◦ 宣言型と手続き型のミックスを絶妙なバランスで実現している点 ▪ 原則として宣言型 ▪ 手続き型的な側面はあるが、”手続きの類はあまり書いてくれるな”というメッセージは感じる • マルチクラウドでのインフラの構築・管理手順を定型化できる ◦ terraform init/plan/apply、どのクラウドでも基本は同じ 個人的なTerraformの良いポイント
43. ©MNTSQ, Ltd. 43 Terraformを利用する上での注意
44. ©MNTSQ, Ltd. 44 Terraformを利用する上での注意
45. ©MNTSQ, Ltd. 45 Terraformを利用する上での注意 コードを書く上での課題に似たようなところがある
46. ©MNTSQ, Ltd. 46 1. 環境差分の最小化 ◦ そもそもアーキテクチャレベルでコンポーネントの差分を最小にする ◦ スケールは違っても有無はことならないようにする 2. state分割の判断 ◦ terraform plan/applyの影響範囲はstate単位で分割される ◦ plan/apply時に自分が意図しない部分の変更などが起きることを考えると分割しておきたい ◦ 適切に分割しないとコードのマージなどの流れが複雑になりがち ◦ コードの変更頻度(≒ライフサイクル)と関係性が判断ポイント 3. モジュールのパラメータと引数の適切な管理 ◦ カプセル化 ◦ リモートステート参照などの際も効いてくる ◦ Platform Engineering的にガードレールを提供したりする場合には特に重要になる 4. リソースの命名規則 ◦ dataソースで参照したりする際に効いてくるので意識しましょう、ルール化しましょう 5. 個別クラウドの知識 ◦ “この設定って無停止で変更できるっけ?”といった知識、リソースごとの関係性の知識は必要 ◦ ただし、リソースごとの関係性をコードとして明示できる点はメリットと捉えることもできる(影響範囲の把握、学習効果など) 気をつけるポイント
47. ©MNTSQ, Ltd. 47 1. 環境差分の最小化 ◦ そもそもアーキテクチャレベルでコンポーネントの差分を最小にする ◦ スケールは違っても有無はことならないようにする 2. state分割の判断 ◦ terraform plan/applyの影響範囲はstate単位で分割される ◦ plan/apply時に自分が意図しない部分の変更などが起きることを考えると分割しておきたい ◦ 適切に分割しないとコードのマージなどの流れが複雑になりがち ◦ コードの変更頻度(≒ライフサイクル)と関係性が判断ポイント 3. モジュールのパラメータと引数の適切な管理 ◦ カプセル化 ◦ リモートステート参照などの際も効いてくる ◦ Platform Engineering的にガードレールを提供したりする場合には特に重要になる 4. リソースの命名規則 ◦ dataソースで参照したりする際に効いてくるので意識しましょう、ルール化しましょう 5. 個別クラウドの知識 ◦ “この設定って無停止で変更できるっけ?”といった知識、リソースごとの関係性の知識は必要 ◦ ただし、リソースごとの関係性をコードとして明示できる点はメリットと捉えることもできる(影響範囲の把握、学習効果など) 気をつけるポイント もう少し具体的な話はパネルディスカッション(or 懇親会)にて
48. ©MNTSQ, Ltd. 48 • マルチクラウド時代にIaCするならTerraformを1stチョイスとして検討してみましょう ◦ パブリッククラウドの公式IaCツールがTerraformなパターンも出てきています ◦ Datadog, PagerDuty, NewRelicなどの設定もコード管理できるようになります • Terraformで気をつけるポイント ◦ アプリケーションコードを書く際の課題とほぼ同じ まとめ