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

by Ryoma Fujiwara

Slide 1

Slide 1 text

©MNTSQ, Ltd. 2025/9/4 時間軸から考えるTerraformを使う理由と留意点 Forkwell Library #105 登壇資料藤原涼馬

Slide 2

Slide 2 text

©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 技術リードそのほかほか色々

Slide 3

Slide 3 text

©MNTSQ, Ltd. 3 この本を書きました

Slide 4

Slide 4 text

©MNTSQ, Ltd. 4 なぜ今、Terraformを推すのか？

Slide 5

Slide 5 text

©MNTSQ, Ltd. 5 なぜ今、Terraformを推すのか？なぜ IaC、なぜTerraformなのか？を説明するには、ある程度流れ(歴史?)を追う必要がある

Slide 6

Slide 6 text

©MNTSQ, Ltd. 6 1. IaCに至るまでの流れ 2. Terraformの登場と推す理由 3. Terraformを使う上での注意点目次

Slide 7

Slide 7 text

©MNTSQ, Ltd. 7 IaC、Terraformに至る流れを見てみるパブリッククラウド以前パブリッククラウド以後マルチクラウド

Slide 8

Slide 8 text

©MNTSQ, Ltd. 8 IaC、Terraformに至る流れを見てみるパブリッククラウド以前パブリッククラウド以後マルチクラウド

Slide 9

Slide 9 text

©MNTSQ, Ltd. 9 アプリケーション実装の管理パブリッククラウド以前コーディングアプリケーションはソースコードを記述して実装する

Slide 10

Slide 10 text

©MNTSQ, Ltd. 10 アプリケーション実装の管理パブリッククラウド以前コーディングソースコード管理アプリケーションはソースコードを記述して実装するソースコードはソースコードリポジトリで管理する

Slide 11

Slide 11 text

©MNTSQ, Ltd. 11 アプリケーション実装の管理パブリッククラウド以前コーディングソースコード管理 CI/CD アプリケーションはソースコードを記述して実装するソースコードはソースコードリポジトリで管理する継続的インテグレーション/ 継続的デプロイ・デリバリのパイプラインをコード定義し、アプリケーションをリリースする

Slide 12

Slide 12 text

©MNTSQ, Ltd. 12 アプリケーション実装の管理パブリッククラウド以前コーディングソースコード管理 CI/CD アプリケーションはソースコードを記述して実装するソースコードはソースコードリポジトリで管理する継続的インテグレーション/ 継続的デプロイ・デリバリのパイプラインをコード定義し、アプリケーションをリリースするパブリッククラウド以前でも、他に色々あったはず...

Slide 13

Slide 13 text

©MNTSQ, Ltd. 13 アプリケーション実装の管理パブリッククラウド以前コーディングソースコード管理 CI/CD アプリケーションはソースコードを記述して実装するソースコードはソースコードリポジトリで管理する継続的インテグレーション/ 継続的デプロイ・デリバリのパイプラインをコード定義し、アプリケーションをリリースするパブリッククラウド以前でも、他に色々あったはず... パブリッククラウド以前からアプリケーションの世界では、かなりの範囲をソースコードベースで管理することが可能だった

Slide 14

Slide 14 text

©MNTSQ, Ltd. 14 アプリケーション実装の管理パブリッククラウド以前コーディングソースコード管理 CI/CD アプリケーションはソースコードを記述して実装するソースコードはソースコードリポジトリで管理する継続的インテグレーション/ 継続的デプロイ・デリバリのパイプラインをコード定義し、アプリケーションをリリースするパブリッククラウド以前でも、他に色々あったはず... パブリッククラウド以前からアプリケーションの世界では、かなりの範囲をソースコードベースで管理することが可能だった ITインフラストラクチャの管理は？

Slide 15

Slide 15 text

©MNTSQ, Ltd. 15 ITインフラストラクチャの管理パブリッククラウド以前構成管理システムを構成するインフラストラクチャの要素、用途を管理する

Slide 16

Slide 16 text

©MNTSQ, Ltd. 16 ITインフラストラクチャの管理パブリッククラウド以前構成管理パラメータ管理システムを構成するインフラストラクチャの要素、用途を管理する個別要素の設定内容を管理

Slide 17

Slide 17 text

©MNTSQ, Ltd. 17 ITインフラストラクチャの管理パブリッククラウド以前構成管理パラメータ管理作業手順書システムを構成するインフラストラクチャの要素、用途を管理する個別要素の設定内容を管理構成要素の作業内容別に作業手順書を作成

Slide 18

Slide 18 text

©MNTSQ, Ltd. 18 ITインフラストラクチャの管理パブリッククラウド以前構成管理パラメータ管理作業手順書システムを構成するインフラストラクチャの要素、用途を管理する個別要素の設定内容を管理構成要素の作業内容別に作業手順書を作成これを完全に否定するものではないが、課題は存在する

Slide 19

Slide 19 text

©MNTSQ, Ltd. 19 スプレッドシートでの管理の課題構成管理の課題構成管理実際の構成パラメータ管理

Slide 20

Slide 20 text

©MNTSQ, Ltd. 20 スプレッドシートでの管理の課題構成管理の課題構成管理実際の構成パラメータ管理コストをそれなりにかけないと差分がどんどん大きくなりがち構成変更、設定変更の頻度が高いほどそうなる

Slide 21

Slide 21 text

©MNTSQ, Ltd. 21 各種作業手順書の問題作業手順の課題作業手順書 (手順書の数) = 　　　　(構成要素の数) x (実施する作業種別)

Slide 22

Slide 22 text

©MNTSQ, Ltd. 22 各種作業手順書の問題作業手順の課題作業手順書システム規模準備・管理コスト

Slide 23

Slide 23 text

©MNTSQ, Ltd. 23 各種作業手順書の問題作業手順の課題作業手順書システム規模準備・管理コスト構成要素が増えるごとに対象の手順書は増加 ≒ 管理コストが構成要素に比例して増える

Slide 24

Slide 24 text

©MNTSQ, Ltd. 24 各種作業手順書の問題作業手順の課題作業手順書システム規模準備・管理コスト構成要素が増えるごとに対象の手順書は増加 ≒ 管理コストが構成要素に比例して増える比例して増えるのは好ましくない

Slide 25

Slide 25 text

©MNTSQ, Ltd. 25 システム規模 vs ITインフラストラクチャの準備・管理コスト旧来の方法論の課題(特に手順書) システム規模準備・管理コストシステム規模準備・管理コストシステム規模準備・管理コスト約束された破滅手順書ベース延長線の理想本当の理想

Slide 26

Slide 26 text

©MNTSQ, Ltd. 26 システム規模 vs ITインフラストラクチャの準備・管理コスト旧来の方法論の課題(特に手順書) システム規模準備・管理コストシステム規模準備・管理コストシステム規模準備・管理コスト約束された破滅手順書ベース延長線の理想本当の理想単純に古い方法をそのまま続けた場合はこちら

Slide 27

Slide 27 text

©MNTSQ, Ltd. 27 システム規模 vs ITインフラストラクチャの準備・管理コスト旧来の方法論の課題(特に手順書) システム規模準備・管理コストシステム規模準備・管理コストシステム規模準備・管理コスト約束された破滅手順書ベース延長線の理想本当の理想できれば右側に寄せていきたい

Slide 28

Slide 28 text

©MNTSQ, Ltd. 28 システム規模 vs ITインフラストラクチャの準備・管理コスト旧来の方法論の課題(特に手順書) システム規模準備・管理コストシステム規模準備・管理コストシステム規模準備・管理コスト約束された破滅手順書ベース延長線の理想本当の理想できれば右側に寄せていきたいなぜそれでもパブリッククラウド以前では成立したのか？

Slide 29

Slide 29 text

©MNTSQ, Ltd. 29 構成を変更するボトルネックが存在したハードウェア選定と購買ラッキング・キッティング配線等引き回しソフトウェアセットアップ想定される作業内容の例

Slide 30

Slide 30 text

©MNTSQ, Ltd. 30 構成を変更するボトルネックが存在したハードウェア選定と購買ラッキング・キッティング配線等引き回しソフトウェアセットアップ想定される作業内容の例作業スケジュールを決めて、データセンターの入館申請を出して、作業手順書を定めて......と時間と手間のかかる作業とコミュニケーションが大量に発生していた

Slide 31

Slide 31 text

©MNTSQ, Ltd. 31 構成を変更するボトルネックが存在したハードウェア選定と購買ラッキング・キッティング配線等引き回しソフトウェアセットアップ想定される作業内容の例物理作業という圧倒的なボトルネックが存在したことや、それに伴うシステム構成の単純化への圧力が確実に存在することで構成管理や作業手順書の手間、コストは致命的な問題にはなってなかった

Slide 32

Slide 32 text

©MNTSQ, Ltd. 32 IaC、Terraformに至る流れを見てみるパブリッククラウド以前パブリッククラウド以後マルチクラウド

Slide 33

Slide 33 text

©MNTSQ, Ltd. 33 パブリッククラウド以後 Amazon Web Services

Slide 34

Slide 34 text

©MNTSQ, Ltd. 34 パブリッククラウド以後 Amazon Web Services Google Cloud

Slide 35

Slide 35 text

©MNTSQ, Ltd. 35 パブリッククラウド以後 Amazon Web Services Google Cloud Microsoft Azure

Slide 36

Slide 36 text

©MNTSQ, Ltd. 36 パブリッククラウド以後 Amazon Web Services Google Cloud Microsoft Azure Webブラウザから操作できるマネジメントコンソールを使った構築

Slide 37

Slide 37 text

©MNTSQ, Ltd. 37 パブリッククラウド以後 Amazon Web Services Google Cloud Microsoft Azure Webブラウザから操作できるマネジメントコンソールを使った構築 CSP提供のCLIツールを使った各種リソースの構築

Slide 38

Slide 38 text

©MNTSQ, Ltd. 38 パブリッククラウド以後 Amazon Web Services Google Cloud Microsoft Azure Webブラウザから操作できるマネジメントコンソールを使った構築 CSP提供のCLIツールを使った各種リソースの構築マネージドサービスなどもフル活用すればあっという間に大規模な構成を持ったシステムを構築できてしまう

Slide 39

Slide 39 text

©MNTSQ, Ltd. 39 パブリッククラウドが広まることによるシステム構造の複雑化パブリッククラウド以前

Slide 40

Slide 40 text

©MNTSQ, Ltd. 40 パブリッククラウドが広まることによるシステム構造の複雑化パブリッククラウド以前パブリッククラウド以後

Slide 41

Slide 41 text

©MNTSQ, Ltd. 41 パブリッククラウドが広まることによるシステム構造の複雑化パブリッククラウド以前パブリッククラウド以後物理作業を中心としたボトルネックが消失した結果として一気にシステム構成が複雑化しやすくなった (それが良いことか悪いことなのかはさておき)

Slide 42

Slide 42 text

©MNTSQ, Ltd. 42 パブリッククラウドが広まることによるシステム構造の複雑化パブリッククラウド以前パブリッククラウド以後物理作業を中心としたボトルネックが消失した結果として一気にシステム構成が複雑化しやすくなった (それが良いことか悪いことなのかはさておき)

Slide 43

Slide 43 text

©MNTSQ, Ltd. 43 パブリッククラウドが広まることによるシステム構造の複雑化パブリッククラウド以前パブリッククラウド以後物理作業を中心としたボトルネックが消失した結果として一気にシステム構成が複雑化しやすくなった (それが良いことか悪いことなのかはさておき) (手順書の数) = 　　　　(構成要素の数) x (実施する作業種別)

Slide 44

Slide 44 text

©MNTSQ, Ltd. 44 パブリッククラウドが広まることによるシステム構造の複雑化パブリッククラウド以前パブリッククラウド以後物理作業を中心としたボトルネックが消失した結果として一気にシステム構成が複雑化しやすくなった (それが良いことか悪いことなのかはさておき) (手順書の数) = 　　　　(構成要素の数) x (実施する作業種別)

Slide 45

Slide 45 text

©MNTSQ, Ltd. 45 パブリッククラウドが広まることによるシステム構造の複雑化パブリッククラウド以前パブリッククラウド以後物理作業を中心としたボトルネックが消失した結果として一気にシステム構成が複雑化しやすくなった (それが良いことか悪いことなのかはさておき) (手順書の数) = 　　　　(構成要素の数) x (実施する作業種別) クラウド以前の手法のみでは管理コストが爆発してしまう (もちろん一定程度はこういった管理は必要ではある)

Slide 46

Slide 46 text

©MNTSQ, Ltd. 46 アプリケーションコードの中身は変わったが、全体として大きな変化はない。アプリケーション観点だとパブリッククラウド以前・以後では...?

Slide 47

Slide 47 text

©MNTSQ, Ltd. 47 アプリケーション実装の管理パブリッククラウド以前コーディングソースコード管理 CI/CD アプリケーションはソースコードを記述して実装するソースコードはソースコードリポジトリで管理する継続的インテグレーション/ 継続的デプロイ・デリバリのパイプラインをコード定義し、アプリケーションをリリースするパブリッククラウド以前でも、他に色々あったはず...

Slide 48

Slide 48 text

©MNTSQ, Ltd. 48 アプリケーション実装の管理パブリッククラウド以前コーディングソースコード管理 CI/CD アプリケーションはソースコードを記述して実装するソースコードはソースコードリポジトリで管理する継続的インテグレーション/ 継続的デプロイ・デリバリのパイプラインをコード定義し、アプリケーションをリリースするパブリッククラウド以前でも、他に色々あったはず... これをインフラストラクチャ管理に持っていこう

Slide 49

Slide 49 text

©MNTSQ, Ltd. 49 ITインフラストラクチャ管理の管理パブリッククラウド以後コーディングソースコード管理 CI/CD アプリケーションはソースコードを記述して実装するソースコードはソースコードリポジトリで管理する継続的インテグレーション/ 継続的デプロイ・デリバリのパイプラインをコード定義し、アプリケーションをリリースするパブリッククラウド以前でも、他に色々あったはず...

Slide 50

Slide 50 text

©MNTSQ, Ltd. 50 ITインフラストラクチャ管理の管理パブリッククラウド以後コーディングソースコード管理 CI/CD インフラストラクチャ定義はコードで管理するソースコードはソースコードリポジトリで管理する継続的インテグレーション/ 継続的デプロイ・デリバリのパイプラインをコード定義し、アプリケーションをリリースするパブリッククラウド以前でも、他に色々あったはず... json YAML

Slide 51

Slide 51 text

©MNTSQ, Ltd. 51 ITインフラストラクチャ管理の管理パブリッククラウド以後コーディングソースコード管理 CI/CD インフラストラクチャ定義はコードで管理するソースコードはソースコードリポジトリで管理する継続的インテグレーション/ 継続的デプロイ・デリバリのパイプラインをコード定義し、アプリケーションをリリースするパブリッククラウド以前でも、他に色々あったはず... json YAML

Slide 52

Slide 52 text

©MNTSQ, Ltd. 52 ITインフラストラクチャ管理の管理パブリッククラウド以後コーディングソースコード管理 CI/CD インフラストラクチャ定義はコードで管理するソースコードはソースコードリポジトリで管理するインフラストラクチャの構成変更も選択肢が増えた json YAML

Slide 53

Slide 53 text

©MNTSQ, Ltd. 53 ITインフラストラクチャ管理の管理パブリッククラウド以後コーディングソースコード管理 CI/CD インフラストラクチャ定義はコードで管理するソースコードはソースコードリポジトリで管理するインフラストラクチャの構成変更も選択肢が増えた json YAML Infrastructure as Codeとそれを中心とした管理・運用プロセス

Slide 54

Slide 54 text

©MNTSQ, Ltd. 54 ● パブリッククラウドプロバイダーからIaCサービスが出てきた ○ AWS CloudFormation ○ Google Cloud Deployment Manager (→ Infrastructure Manager) ○ Azure Bicep インフラストラクチャをコードで管理(IaC; Infrastructure as Code)すればいいじゃない？パブリッククラウド以後

Slide 55

Slide 55 text

©MNTSQ, Ltd. 55 ● パブリッククラウドプロバイダーからIaCサービスが出てきた ○ AWS CloudFormation ○ Google Cloud Deployment Manager (→ Infrastructure Manager) ○ Azure Bicep インフラストラクチャをコードで管理(IaC; Infrastructure as Code)すればいいじゃない？パブリッククラウド以後インフラストラクチャをコードで管理する & 構成変更の手順を統一することで管理・運用コストの削減を狙った

Slide 56

Slide 56 text

©MNTSQ, Ltd. 56 そこまでCFnは使い込んでないのであくまでも例ですが CloudFormationの場合パブリッククラウド以後コーディングデプロイ aws cloudformation \ deploy 結果の確認

Slide 57

Slide 57 text

©MNTSQ, Ltd. 57 そこまでCFnは使い込んでないのであくまでも例ですが CloudFormationの場合パブリッククラウド以後コーディングデプロイ aws cloudformation \ deploy 結果の確認複雑な作業手順書が、aws cloudformation deployコマンドに集約された＝作業手順を一定程度揃えることができた

Slide 58

Slide 58 text

©MNTSQ, Ltd. 58 ここまでのまとめパブリッククラウド以後 Infrastructure as Code(IaC) 旧来型の管理 IaCにより作業手順管理コストの低減、(部分的な)構成管理が実現することで管理コストの爆発は一定程度抑えることができた

Slide 59

Slide 59 text

Slide 60

Slide 60 text

Slide 61

Slide 61 text

©MNTSQ, Ltd. 61 ● パブリッククラウドプロバイダーからIaCサービスが出てきた ○ AWS CloudFormation ○ Google Cloud Deployment Manager (→ Infrastructure Manager) ○ Azure Bicep インフラストラクチャをコードで管理(IaC; Infrastructure as Code)すればいいじゃない？マルチクラウド

Slide 62

Slide 62 text

©MNTSQ, Ltd. 62 ● パブリッククラウドプロバイダーからIaCサービスが出てきた ○ AWS CloudFormation ○ Google Cloud Deployment Manager (→ Infrastructure Manager) ○ Azure Bicep インフラストラクチャをコードで管理(IaC; Infrastructure as Code)すればいいじゃない？マルチクラウドすべてを個別のパブリッククラウドプロバイダー提供のサービスを学習して記述するか？

Slide 63

Slide 63 text

©MNTSQ, Ltd. 63 ● パブリッククラウドプロバイダーからIaCサービスが出てきた ○ AWS CloudFormation ○ Google Cloud Deployment Manager (→ Infrastructure Manager) ○ Azure Bicep インフラストラクチャをコードで管理(IaC; Infrastructure as Code)すればいいじゃない？すべてを個別のパブリッククラウドプロバイダー提供のサービスを学習して記述するか？学習コストの問題

Slide 64

Slide 64 text

Slide 65

Slide 65 text

©MNTSQ, Ltd. 65 ● 特定のパブリッククラウドに閉じたものではない ○ いわゆるメガクラウドには対応 ○ メガクラウド以外のSaaSなどにも対応している(Datadog, PegerDuty, NewRelicなど) 複数のクラウドプロバイダーに対応したIaCツールとしてのTerraform マルチクラウド

Slide 66

Slide 66 text

©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に基づいており ...との記述まである)

Slide 67

Slide 67 text

©MNTSQ, Ltd. 67 ● Hashicorp Configuration Language(HCL; HCL is the HashiCorp configuration language. )のできが良い ○ HCL2 (Terraformだと0.12以降)に移行してから、かなり使い勝手が改善されている ■ 逆にいうとそれ以前はそれなりに癖が強かった ○ 宣言型と手続き型のミックスを絶妙なバランスで実現している点 ■ 原則として宣言型 ■ 手続き型的な側面はあるが、”手続きの類はあまり書いてくれるな”というメッセージは感じる ● マルチクラウドでのインフラの構築・管理手順を定型化できる ○ terraform init/plan/apply、どのクラウドでも基本は同じ個人的なTerraformの良いポイントこれをどのクラウドプロバイダでも同じ作業手順、プロセスで実現できる

Slide 68

Slide 68 text

Slide 69

Slide 69 text

©MNTSQ, Ltd. 69 ● 個別クラウドの知識からは逃げられない ● そもそものインフラ設計の悪さは覆せない ● 影響範囲の重要性(state分割の考慮) ● なんでもできるは何にもできない(module設計の注意点) ● 命名の重要性 ● state間の依存関係は一方向にする ● コード管理しない勇気(importしなくてもよくない?) Terraformを利用する上での注意

Slide 70

Slide 70 text

©MNTSQ, Ltd. 70 Terraformを使っても、個別のクラウドプロバイダー固有の知識習得からは逃れられません。個別クラウドの知識からは逃げられない Terraformを利用する上での注意個々のリソース間の関係性は？このパラメータ変更は無停止で行けるんだっけ？

Slide 71

Slide 71 text

©MNTSQ, Ltd. 71 Terraformをつかってもインフラ設計の悪さは覆せませんスプレッドシートでの管理や表現が難しい構成は、Terraformでも難しいですそもそものインフラ設計の悪さは覆せない Terraformを利用する上での注意開発環境と本番環境で大きな構成要素の違い(要素の有無レベルで)が大量にあるみたいな話の問題はそうそう覆せませんスケールの違いなどについては比較的容易に対応できます

Slide 72

Slide 72 text

©MNTSQ, Ltd. 72 Terraformでの変更をする際にも個別のterraform plan/apply時の差分はなるべく小さくした方がいいでしょう影響範囲の重要性(state分割の考慮) Terraformを利用する上での注意 terraform planしたら隣の部署のリソース変更が大量に出るんだけど？ IAMポリシーの変更なのに、VPCのサブネットのrecreateが走るんだけど...

Slide 73

Slide 73 text

©MNTSQ, Ltd. 73 Terraformでの変更をする際にも個別のterraform plan/apply時の差分はなるべく小さくした方がいいでしょう影響範囲の重要性(state分割の考慮) Terraformを利用する上での注意 terraform planしたら隣の部署のリソース変更が大量に出るんだけど？ IAMポリシーの変更なのに、VPCのサブネットのrecreateが走るんだけど... terraformのstateは適切に分割することで、意識しなければいけない変更の範囲を小さく止めましょう関連性の薄いリソースは別stateに分ける (別stateで作成したリソースの情報が必要な場合はdataソースか、リモートステートを使う*。) 管理している組織が異なる場合はstateは分ける (コンウェイの法則的な形) *個人的には命名規則やリソースタグなどを駆使してdataソースで参照することを推奨

Slide 74

Slide 74 text

©MNTSQ, Ltd. 74 Terraformのモジュール設計時はなんでもできるものはモジュールとしての意味をなしません。モジュールの目的 1. 関連性の深いひとまとまりのリソース群をまとめて作成する 2. あまり詳しくない人でも安全にリソースのセットを作成できるようにする（いわゆるガードレール的な観点）なんでもできるは何にもできない(module設計の注意点) Terraformを利用する上での注意

Slide 75

Slide 75 text

©MNTSQ, Ltd. 75 Terraformのモジュール設計時はなんでもできるものはモジュールとしての意味をなしません。モジュールの目的 1. 関連性の深いひとまとまりのリソース群をまとめて作成する 2. あまり詳しくない人でも安全にリソースのセットを作成できるようにする（いわゆるガードレール的な観点）なんでもできるは何にもできない(module設計の注意点) Terraformを利用する上での注意特に後者の場合は、なんでもできてしまうとガードレールが意味をなしません moduleを作成する時は何をできないようにするか、引き算の思考で考えた方が良いです後から変更可能にすることも現在のTerraformでは比較的容易です (object typeのoptionや変数のdefaultなどの活用)

Slide 76

Slide 76 text

Slide 77

Slide 77 text

©MNTSQ, Ltd. 77 stateを跨った情報を取得する際にリソースの命名規則やリソースタグの規則は非常に重要です命名の重要性 Terraformを利用する上での注意秩序だったリソースの命名規則やリソースタグの規則は、 dataソースを使って参照する際にあなたを助けてくれます

Slide 78

Slide 78 text

©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に依存（循環的な依存関係の発生）

Slide 79

Slide 79 text

©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ですべて管理する判断もアリ

Slide 80

Slide 80 text

©MNTSQ, Ltd. 80 マネジメントコンソールやCLIを使って手動で作成したリソースをIaC管理に持ち込むにはどうしたら？コード管理しない勇気(importしなくてもよくない?) Terraformを利用する上での注意 IaC化の目的は変更手順の統一とそれにともなう変更安全性の確保が主変更が必要になったタイミングでのimportで良いと思います。 (importに際してはterraformerの利用や、importブロックと-generate-config-outオプションの組み合わせ利用とかを考えてもよい)

Slide 81

Slide 81 text

©MNTSQ, Ltd. 81 本セッションでは、以下の3つについて解説しました。 1. Terraformに至るまでの時間軸でみた技術的な経緯 2. Terraformがおすすめな理由 3. Terraformを継続的に使っていく上での注意点まとめ

Slide 82

Slide 82 text

No content