時間軸から考えるTerraformを使う理由と留意点

Terraformではじめる実践IaC - Forkwell Library #105 https://forkwell.connpass.com/event/365048/
の登壇資料です。

Transcript

1. ©MNTSQ, Ltd. 2025/9/4 時間軸から考えるTerraformを使う理由と留意点 Forkwell Library #105 登壇資料 藤原 涼馬
2. ©MNTSQ, Ltd. 2 自己紹介(概要版) 藤原 涼馬 (@RyoMa_0923) MNTSQ株式会社 SREチームマネージャー 兼 セキュリティ推進室マネージャー 職歴 2011/4 2016/1 2021/5 2023/11 SIer 研究員 インフラSE インフラSE SRE 新卒エンジニア教育 SRE SRE 対外公開物 （寄稿・執筆など） 先行事例に学ぶKubernetes企業活用の現実(ITmedia) コンテナベースのCI/CD本番事例大解剖(ITmedia) マルチクラウド時代の最強コンビ RancherによるKubernetes活用 ガイド(ThinkIT) RancherによるKubernetes活用完全ガイド(共著, インプレス) Cloud Native Days Tokyo実行委員 Rancher JPコアメンバー SRENext 2022登壇 実践WAF (WEB+DB PRESS vol.123 特集3) STORES Tech Talk AWS Organization活用のリアル 主業 個人検証のアカウント、どんな感じでやってますか？ (JAWS UG東京 ランチ共有会) Harvesterという選択肢(Rancher JP Online meetup #5) 現場で活きる！ Datadog によるオブザーバビリティ 　実践のリアル (Datadog Live Tokyo 2025) Terraformではじめる実践IaC(オライリー) 複業 インフラSE 技術リードそ のほか ほか色々
3. ©MNTSQ, Ltd. 3 この本を書きました
4. ©MNTSQ, Ltd. 4 なぜ今、Terraformを推すのか？
5. ©MNTSQ, Ltd. 5 なぜ今、Terraformを推すのか？ なぜ IaC、なぜTerraformなのか？ を説明するには、ある程度流れ(歴史?)を追う必要がある
6. ©MNTSQ, Ltd. 6 1. IaCに至るまでの流れ 2. Terraformの登場と推す理由 3. Terraformを使う上での注意点 目次
7. ©MNTSQ, Ltd. 7 IaC、Terraformに至る流れを見てみる パブリッククラウド以前 パブリッククラウド以後 マルチクラウド
8. ©MNTSQ, Ltd. 8 IaC、Terraformに至る流れを見てみる パブリッククラウド以前 パブリッククラウド以後 マルチクラウド
9. ©MNTSQ, Ltd. 9 アプリケーション実装の管理 パブリッククラウド以前 コーディング アプリケーションはソース コードを記述して実装する
10. ©MNTSQ, Ltd. 10 アプリケーション実装の管理 パブリッククラウド以前 コーディング ソースコード管理 アプリケーションはソース コードを記述して実装する ソースコードはソースコード リポジトリで管理する
11. ©MNTSQ, Ltd. 11 アプリケーション実装の管理 パブリッククラウド以前 コーディング ソースコード管理 CI/CD アプリケーションはソース コードを記述して実装する ソースコードはソースコード リポジトリで管理する 継続的インテグレーション/ 継続的デプロイ・デリバリの パイプラインをコード定義 し、アプリケーションをリ リースする
12. ©MNTSQ, Ltd. 12 アプリケーション実装の管理 パブリッククラウド以前 コーディング ソースコード管理 CI/CD アプリケーションはソース コードを記述して実装する ソースコードはソースコード リポジトリで管理する 継続的インテグレーション/ 継続的デプロイ・デリバリの パイプラインをコード定義 し、アプリケーションをリ リースする パブリッククラ ウド以前でも、 他に色々あった はず...
13. ©MNTSQ, Ltd. 13 アプリケーション実装の管理 パブリッククラウド以前 コーディング ソースコード管理 CI/CD アプリケーションはソース コードを記述して実装する ソースコードはソースコード リポジトリで管理する 継続的インテグレーション/ 継続的デプロイ・デリバリの パイプラインをコード定義 し、アプリケーションをリ リースする パブリッククラ ウド以前でも、 他に色々あった はず... パブリッククラウド以前からアプリケーションの世界では、 かなりの範囲をソースコードベースで管理することが可能だった
14. ©MNTSQ, Ltd. 14 アプリケーション実装の管理 パブリッククラウド以前 コーディング ソースコード管理 CI/CD アプリケーションはソース コードを記述して実装する ソースコードはソースコード リポジトリで管理する 継続的インテグレーション/ 継続的デプロイ・デリバリの パイプラインをコード定義 し、アプリケーションをリ リースする パブリッククラ ウド以前でも、 他に色々あった はず... パブリッククラウド以前からアプリケーションの世界では、 かなりの範囲をソースコードベースで管理することが可能だった ITインフラストラクチャの管理は？
15. ©MNTSQ, Ltd. 15 ITインフラストラクチャの管理 パブリッククラウド以前 構成管理 システムを構成するインフラス トラクチャの要素、用途を管理 する
16. ©MNTSQ, Ltd. 16 ITインフラストラクチャの管理 パブリッククラウド以前 構成管理 パラメータ管理 システムを構成するインフラス トラクチャの要素、用途を管理 する 個別要素の設定内容を管理
17. ©MNTSQ, Ltd. 17 ITインフラストラクチャの管理 パブリッククラウド以前 構成管理 パラメータ管理 作業手順書 システムを構成するインフラス トラクチャの要素、用途を管理 する 個別要素の設定内容を管理 構成要素の作業内容別に 作業手順書を作成
18. ©MNTSQ, Ltd. 18 ITインフラストラクチャの管理 パブリッククラウド以前 構成管理 パラメータ管理 作業手順書 システムを構成するインフラス トラクチャの要素、用途を管理 する 個別要素の設定内容を管理 構成要素の作業内容別に 作業手順書を作成 これを完全に否定するものではないが、課題は存在する
19. ©MNTSQ, Ltd. 19 スプレッドシートでの管理の課題 構成管理の課題 構成管理 実際の構成 パラメータ管理
20. ©MNTSQ, Ltd. 20 スプレッドシートでの管理の課題 構成管理の課題 構成管理 実際の構成 パラメータ管理 コストをそれなりにかけないと差分がどんどん大きくなりがち 構成変更、設定変更の頻度が高いほどそうなる
21. ©MNTSQ, Ltd. 21 各種作業手順書の問題 作業手順の課題 作業手順書 (手順書の数) = 　　　　(構成要素の数) x (実施する作業種別)
22. ©MNTSQ, Ltd. 22 各種作業手順書の問題 作業手順の課題 作業手順書 システム規模 準備・管理コスト
23. ©MNTSQ, Ltd. 23 各種作業手順書の問題 作業手順の課題 作業手順書 システム規模 準備・管理コスト 構成要素が増えるごとに対象の手順書は増加 ≒ 管理コストが構成要素に比例して増える
24. ©MNTSQ, Ltd. 24 各種作業手順書の問題 作業手順の課題 作業手順書 システム規模 準備・管理コスト 構成要素が増えるごとに対象の手順書は増加 ≒ 管理コストが構成要素に比例して増える 比例して増えるのは好ましくない
25. ©MNTSQ, Ltd. 25 システム規模 vs ITインフラストラクチャの準備・管理コスト 旧来の方法論の課題(特に手順書) システム規模 準備・管理コスト システム規模 準備・管理コスト システム規模 準備・管理コスト 約束された破滅 手順書ベース延長線の理想 本当の理想
26. ©MNTSQ, Ltd. 26 システム規模 vs ITインフラストラクチャの準備・管理コスト 旧来の方法論の課題(特に手順書) システム規模 準備・管理コスト システム規模 準備・管理コスト システム規模 準備・管理コスト 約束された破滅 手順書ベース延長線の理想 本当の理想 単純に古い方法をそのまま続けた場合はこちら
27. ©MNTSQ, Ltd. 27 システム規模 vs ITインフラストラクチャの準備・管理コスト 旧来の方法論の課題(特に手順書) システム規模 準備・管理コスト システム規模 準備・管理コスト システム規模 準備・管理コスト 約束された破滅 手順書ベース延長線の理想 本当の理想 できれば右側に寄せていきたい
28. ©MNTSQ, Ltd. 28 システム規模 vs ITインフラストラクチャの準備・管理コスト 旧来の方法論の課題(特に手順書) システム規模 準備・管理コスト システム規模 準備・管理コスト システム規模 準備・管理コスト 約束された破滅 手順書ベース延長線の理想 本当の理想 できれば右側に寄せていきたい なぜそれでもパブリッククラウド以前では成立したのか？
29. ©MNTSQ, Ltd. 29 構成を変更するボトルネックが存在した ハードウェア選定と購買 ラッキング・キッティング 配線等引き回し ソフトウェアセットアップ 想定される作業内容の例
30. ©MNTSQ, Ltd. 30 構成を変更するボトルネックが存在した ハードウェア選定と購買 ラッキング・キッティング 配線等引き回し ソフトウェアセットアップ 想定される作業内容の例 作業スケジュールを決めて、データセンターの入館申請を出して、 作業手順書を定めて......と時間と手間のかかる作業とコミュニケーションが大量に発生していた
31. ©MNTSQ, Ltd. 31 構成を変更するボトルネックが存在した ハードウェア選定と購買 ラッキング・キッティング 配線等引き回し ソフトウェアセットアップ 想定される作業内容の例 物理作業という圧倒的なボトルネックが存在したことや、 それに伴うシステム構成の単純化への圧力が確実に存在することで 構成管理や作業手順書の手間、コストは致命的な問題にはなってなかった
32. ©MNTSQ, Ltd. 32 IaC、Terraformに至る流れを見てみる パブリッククラウド以前 パブリッククラウド以後 マルチクラウド
33. ©MNTSQ, Ltd. 33 パブリッククラウド以後 Amazon Web Services
34. ©MNTSQ, Ltd. 34 パブリッククラウド以後 Amazon Web Services Google Cloud
35. ©MNTSQ, Ltd. 35 パブリッククラウド以後 Amazon Web Services Google Cloud Microsoft Azure
36. ©MNTSQ, Ltd. 36 パブリッククラウド以後 Amazon Web Services Google Cloud Microsoft Azure Webブラウザから操作できるマネジメントコンソールを使った構築
37. ©MNTSQ, Ltd. 37 パブリッククラウド以後 Amazon Web Services Google Cloud Microsoft Azure Webブラウザから操作できるマネジメントコンソールを使った構築 CSP提供のCLIツールを使った各種リソースの構築
38. ©MNTSQ, Ltd. 38 パブリッククラウド以後 Amazon Web Services Google Cloud Microsoft Azure Webブラウザから操作できるマネジメントコンソールを使った構築 CSP提供のCLIツールを使った各種リソースの構築 マネージドサービスなどもフル活用すればあっという間に 大規模な構成を持ったシステムを構築できてしまう
39. ©MNTSQ, Ltd. 39 パブリッククラウドが広まることによるシステム構造の複雑化 パブリッククラウド以前
40. ©MNTSQ, Ltd. 40 パブリッククラウドが広まることによるシステム構造の複雑化 パブリッククラウド以前 パブリッククラウド以後
41. ©MNTSQ, Ltd. 41 パブリッククラウドが広まることによるシステム構造の複雑化 パブリッククラウド以前 パブリッククラウド以後 物理作業を中心としたボトルネックが消失した結果として 一気にシステム構成が複雑化しやすくなった (それが良いことか悪いことなのかはさておき)
42. ©MNTSQ, Ltd. 42 パブリッククラウドが広まることによるシステム構造の複雑化 パブリッククラウド以前 パブリッククラウド以後 物理作業を中心としたボトルネックが消失した結果として 一気にシステム構成が複雑化しやすくなった (それが良いことか悪いことなのかはさておき)
43. ©MNTSQ, Ltd. 43 パブリッククラウドが広まることによるシステム構造の複雑化 パブリッククラウド以前 パブリッククラウド以後 物理作業を中心としたボトルネックが消失した結果として 一気にシステム構成が複雑化しやすくなった (それが良いことか悪いことなのかはさておき) (手順書の数) = 　　　　(構成要素の数) x (実施する作業種別)
44. ©MNTSQ, Ltd. 44 パブリッククラウドが広まることによるシステム構造の複雑化 パブリッククラウド以前 パブリッククラウド以後 物理作業を中心としたボトルネックが消失した結果として 一気にシステム構成が複雑化しやすくなった (それが良いことか悪いことなのかはさておき) (手順書の数) = 　　　　(構成要素の数) x (実施する作業種別)
45. ©MNTSQ, Ltd. 45 パブリッククラウドが広まることによるシステム構造の複雑化 パブリッククラウド以前 パブリッククラウド以後 物理作業を中心としたボトルネックが消失した結果として 一気にシステム構成が複雑化しやすくなった (それが良いことか悪いことなのかはさておき) (手順書の数) = 　　　　(構成要素の数) x (実施する作業種別) クラウド以前の手法のみでは管理コストが爆発してしまう (もちろん一定程度はこういった管理は必要ではある)
46. ©MNTSQ, Ltd. 46 アプリケーションコードの中身は変わったが、全体として大きな変化はない。 アプリケーション観点だとパブリッククラウド以前・以後では...?
47. ©MNTSQ, Ltd. 47 アプリケーション実装の管理 パブリッククラウド以前 コーディング ソースコード管理 CI/CD アプリケーションはソース コードを記述して実装する ソースコードはソースコード リポジトリで管理する 継続的インテグレーション/ 継続的デプロイ・デリバリの パイプラインをコード定義 し、アプリケーションをリ リースする パブリッククラ ウド以前でも、 他に色々あった はず...
48. ©MNTSQ, Ltd. 48 アプリケーション実装の管理 パブリッククラウド以前 コーディング ソースコード管理 CI/CD アプリケーションはソース コードを記述して実装する ソースコードはソースコード リポジトリで管理する 継続的インテグレーション/ 継続的デプロイ・デリバリの パイプラインをコード定義 し、アプリケーションをリ リースする パブリッククラ ウド以前でも、 他に色々あった はず... これをインフラストラクチャ管理に持っていこう
49. ©MNTSQ, Ltd. 49 ITインフラストラクチャ管理の管理 パブリッククラウド以後 コーディング ソースコード管理 CI/CD アプリケーションはソース コードを記述して実装する ソースコードはソースコード リポジトリで管理する 継続的インテグレーション/ 継続的デプロイ・デリバリの パイプラインをコード定義 し、アプリケーションをリ リースする パブリッククラ ウド以前でも、 他に色々あった はず...
50. ©MNTSQ, Ltd. 50 ITインフラストラクチャ管理の管理 パブリッククラウド以後 コーディング ソースコード管理 CI/CD インフラストラクチャ定義 はコードで管理する ソースコードはソースコード リポジトリで管理する 継続的インテグレーション/ 継続的デプロイ・デリバリの パイプラインをコード定義 し、アプリケーションをリ リースする パブリッククラ ウド以前でも、 他に色々あった はず... json YAML
51. ©MNTSQ, Ltd. 51 ITインフラストラクチャ管理の管理 パブリッククラウド以後 コーディング ソースコード管理 CI/CD インフラストラクチャ定義 はコードで管理する ソースコードはソースコード リポジトリで管理する 継続的インテグレーション/ 継続的デプロイ・デリバリの パイプラインをコード定義 し、アプリケーションをリ リースする パブリッククラ ウド以前でも、 他に色々あった はず... json YAML
52. ©MNTSQ, Ltd. 52 ITインフラストラクチャ管理の管理 パブリッククラウド以後 コーディング ソースコード管理 CI/CD インフラストラクチャ定義 はコードで管理する ソースコードはソースコード リポジトリで管理する インフラストラクチャの構成 変更も選択肢が増えた json YAML
53. ©MNTSQ, Ltd. 53 ITインフラストラクチャ管理の管理 パブリッククラウド以後 コーディング ソースコード管理 CI/CD インフラストラクチャ定義 はコードで管理する ソースコードはソースコード リポジトリで管理する インフラストラクチャの構成 変更も選択肢が増えた json YAML Infrastructure as Codeとそれを中心とした管理・運用プロセス
54. ©MNTSQ, Ltd. 54 • パブリッククラウドプロバイダーからIaCサービスが出てきた ◦ AWS CloudFormation ◦ Google Cloud Deployment Manager (→ Infrastructure Manager) ◦ Azure Bicep インフラストラクチャをコードで管理(IaC; Infrastructure as Code)すればいいじゃない？ パブリッククラウド以後
55. ©MNTSQ, Ltd. 55 • パブリッククラウドプロバイダーからIaCサービスが出てきた ◦ AWS CloudFormation ◦ Google Cloud Deployment Manager (→ Infrastructure Manager) ◦ Azure Bicep インフラストラクチャをコードで管理(IaC; Infrastructure as Code)すればいいじゃない？ パブリッククラウド以後 インフラストラクチャを コードで管理する & 構成変更の手順を統一することで 管理・運用コストの削減を狙った
56. ©MNTSQ, Ltd. 56 そこまでCFnは使い込んでないのであくまでも例ですが CloudFormationの場合 パブリッククラウド以後 コーディング デプロイ aws cloudformation \ deploy 結果の確認
57. ©MNTSQ, Ltd. 57 そこまでCFnは使い込んでないのであくまでも例ですが CloudFormationの場合 パブリッククラウド以後 コーディング デプロイ aws cloudformation \ deploy 結果の確認 複雑な作業手順書が、aws cloudformation deployコマンドに集約された ＝ 作業手順を一定程度揃えることができた
58. ©MNTSQ, Ltd. 58 ここまでのまとめ パブリッククラウド以後 Infrastructure as Code(IaC) 旧来型の管理 IaCにより 作業手順管理コストの低減、(部分的な)構成管理が実現 することで管理コストの爆発は一定程度抑えることができた
59. ©MNTSQ, Ltd. 59 IaC、Terraformに至る流れを見てみる パブリッククラウド以前 パブリッククラウド以後 マルチクラウド
60. ©MNTSQ, Ltd. 60 一つのパブリッククラウドではなく複数のパブリッククラウドを 組み合わせてサービスを提供することが珍しくなっている 単一のSaaSなどの提供で複数クラウドの機能を利用するのが珍しくなくなってきた マルチクラウド
61. ©MNTSQ, Ltd. 61 • パブリッククラウドプロバイダーからIaCサービスが出てきた ◦ AWS CloudFormation ◦ Google Cloud Deployment Manager (→ Infrastructure Manager) ◦ Azure Bicep インフラストラクチャをコードで管理(IaC; Infrastructure as Code)すればいいじゃない？ マルチクラウド
62. ©MNTSQ, Ltd. 62 • パブリッククラウドプロバイダーからIaCサービスが出てきた ◦ AWS CloudFormation ◦ Google Cloud Deployment Manager (→ Infrastructure Manager) ◦ Azure Bicep インフラストラクチャをコードで管理(IaC; Infrastructure as Code)すればいいじゃない？ マルチクラウド すべてを個別のパブリッククラウドプロバイダー提供のサービスを学習して記述するか？
63. ©MNTSQ, Ltd. 63 • パブリッククラウドプロバイダーからIaCサービスが出てきた ◦ AWS CloudFormation ◦ Google Cloud Deployment Manager (→ Infrastructure Manager) ◦ Azure Bicep インフラストラクチャをコードで管理(IaC; Infrastructure as Code)すればいいじゃない？ すべてを個別のパブリッククラウドプロバイダー提供のサービスを学習して記述するか？ 学習コストの問題
64. ©MNTSQ, Ltd. 64 Terraform マルチクラウド
65. ©MNTSQ, Ltd. 65 • 特定のパブリッククラウドに閉じたものではない ◦ いわゆるメガクラウドには対応 ◦ メガクラウド以外のSaaSなどにも対応している(Datadog, PegerDuty, NewRelicなど) 複数のクラウドプロバイダーに対応したIaCツールとしてのTerraform マルチクラウド
66. ©MNTSQ, Ltd. 66 • 特定のパブリッククラウドに閉じたものではない ◦ いわゆるメガクラウドには対応 ◦ メガクラウド以外のSaaSなども対応している(Datadog, PegerDuty, NewRelicなど) • メガクラウドでも実質的に1stチョイスとして公式に提示されているものがある 複数のクラウドプロバイダーに対応したIaCツールとしての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に基づいており ...との記 述まである)
67. ©MNTSQ, Ltd. 67 • Hashicorp Configuration Language(HCL; HCL is the HashiCorp configuration language. )のできが良い ◦ HCL2 (Terraformだと0.12以降)に移行してから、かなり使い勝手が改善されている ▪ 逆にいうとそれ以前はそれなりに癖が強かった ◦ 宣言型と手続き型のミックスを絶妙なバランスで実現している点 ▪ 原則として宣言型 ▪ 手続き型的な側面はあるが、”手続きの類はあまり書いてくれるな”というメッセージは感じる • マルチクラウドでのインフラの構築・管理手順を定型化できる ◦ terraform init/plan/apply、どのクラウドでも基本は同じ 個人的なTerraformの良いポイント これをどのクラウドプロバイダでも 同じ作業手順、プロセスで実現できる
68. ©MNTSQ, Ltd. 68 Terraformを利用する上での注意
69. ©MNTSQ, Ltd. 69 • 個別クラウドの知識からは逃げられない • そもそものインフラ設計の悪さは覆せない • 影響範囲の重要性(state分割の考慮) • なんでもできるは何にもできない(module設計の注意点) • 命名の重要性 • state間の依存関係は一方向にする • コード管理しない勇気(importしなくてもよくない?) Terraformを利用する上での注意
70. ©MNTSQ, Ltd. 70 Terraformを使っても、個別のクラウドプロバイダー固有の知識習得からは逃れられません。 個別クラウドの知識からは逃げられない Terraformを利用する上での注意 個々のリソース間の関係性は？ このパラメータ変更は無停止で行けるんだっけ？
71. ©MNTSQ, Ltd. 71 Terraformをつかってもインフラ設計の悪さは覆せません スプレッドシートでの管理や表現が難しい構成は、Terraformでも難しいです そもそものインフラ設計の悪さは覆せない Terraformを利用する上での注意 開発環境と本番環境で大きな構成要素の違い(要素の有無レベルで)が大量にある みたいな話の問題はそうそう覆せません スケールの違いなどについては比較的容易に対応できます
72. ©MNTSQ, Ltd. 72 Terraformでの変更をする際にも個別のterraform plan/apply時の差分はなるべく小さくした方がいいでしょう 影響範囲の重要性(state分割の考慮) Terraformを利用する上での注意 terraform planしたら隣の部署のリソース変更が大量に出るんだけど？ IAMポリシーの変更なのに、VPCのサブネットのrecreateが走るんだけど...
73. ©MNTSQ, Ltd. 73 Terraformでの変更をする際にも個別のterraform plan/apply時の差分はなるべく小さくした方がいいでしょう 影響範囲の重要性(state分割の考慮) Terraformを利用する上での注意 terraform planしたら隣の部署のリソース変更が大量に出るんだけど？ IAMポリシーの変更なのに、VPCのサブネットのrecreateが走るんだけど... terraformのstateは適切に分割することで、意識しなければいけない変更の範囲を小さく止めましょう 関連性の薄いリソースは別stateに分ける (別stateで作成したリソースの情報が必要な場合はdataソースか、リモートステートを使う*。) 管理している組織が異なる場合はstateは分ける (コンウェイの法則的な形) *個人的には命名規則やリソースタグなどを駆使してdataソースで参照することを推奨
74. ©MNTSQ, Ltd. 74 Terraformのモジュール設計時はなんでもできるものはモジュールとしての意味をなしません。 モジュールの目的 1. 関連性の深いひとまとまりのリソース群をまとめて作成する 2. あまり詳しくない人でも安全にリソースのセットを作成できるようにする （いわゆるガードレール的な観点） なんでもできるは何にもできない(module設計の注意点) Terraformを利用する上での注意
75. ©MNTSQ, Ltd. 75 Terraformのモジュール設計時はなんでもできるものはモジュールとしての意味をなしません。 モジュールの目的 1. 関連性の深いひとまとまりのリソース群をまとめて作成する 2. あまり詳しくない人でも安全にリソースのセットを作成できるようにする （いわゆるガードレール的な観点） なんでもできるは何にもできない(module設計の注意点) Terraformを利用する上での注意 特に後者の場合は、 なんでもできてしまうとガードレールが意味をなしません moduleを作成する時は何をできないようにするか、引き算の思考で考えた方が良いです 後から変更可能にすることも現在のTerraformでは比較的容易です (object typeのoptionや変数のdefaultなどの活用)
76. ©MNTSQ, Ltd. 76 stateを跨った情報を取得する際にリソースの命名規則やリソースタグの規則は非常に重要です 命名の重要性 Terraformを利用する上での注意
77. ©MNTSQ, Ltd. 77 stateを跨った情報を取得する際にリソースの命名規則やリソースタグの規則は非常に重要です 命名の重要性 Terraformを利用する上での注意 秩序だったリソースの命名規則やリソースタグの規則は、 dataソースを使って参照する際にあなたを助けてくれます
78. ©MNTSQ, Ltd. 78 stateの依存関係は一方通行として循環などが発生しないようにする state間の依存関係は一方向にする Terraformを利用する上での注意 state A state B state C state D state E state A state B state C state D state E state B, C, Dはstate Aに依存 state Eはstate B, C, Dに依存 state B, C, Dはstate Aに依存 state Eはstate B, C, Dに依存 state Aはstate Eに依存 （循環的な依存関係の発生）
79. ©MNTSQ, Ltd. 79 stateの依存関係は一方通行として循環などが発生しないようにする state間の依存関係は一方向にする Terraformを利用する上での注意 state A state B state C state D state E state A state B state C state D state E state B, C, Dはstate Aに依存 state Eはstate B, C, Dに依存 state B, C, Dはstate Aに依存 state Eはstate B, C, Dに依存 state Aはstate Eに依存 （循環的な依存関係の発生） インフラの構築・管理を開始した初期には発生しづらいが、 一定期間以上経過してシステム規模が大規模化した際に発生しがち (-targetオプションの使用など)一旦の対応手段がないわけでもないが、確実に面倒を産むので コードレビューの際に特に見るべきポイントの一つはここだと思われる plan/apply時の影響範囲を気にしない覚悟を決めるか、 規模が大きくならない自信があるなら単独stateですべて管理する判断もアリ
80. ©MNTSQ, Ltd. 80 マネジメントコンソールやCLIを使って手動で作成したリソースをIaC管理に持ち込むにはどうしたら？ コード管理しない勇気(importしなくてもよくない?) Terraformを利用する上での注意 IaC化の目的は変更手順の統一とそれにともなう変更安全性の確保が主 変更が必要になったタイミングでのimportで良いと思います。 (importに際してはterraformerの利用や、importブロックと-generate-config-outオプションの組み合わせ利用とかを考えてもよい)
81. ©MNTSQ, Ltd. 81 本セッションでは、以下の3つについて解説しました。 1. Terraformに至るまでの時間軸でみた技術的な経緯 2. Terraformがおすすめな理由 3. Terraformを継続的に使っていく上での注意点 まとめ