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

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

Slide 60

Slide 60 text

©MNTSQ, Ltd. 60 一つのパブリッククラウドではなく複数のパブリッククラウドを 組み合わせてサービスを提供することが珍しくなっている 単一のSaaSなどの提供で複数クラウドの機能を利用するのが珍しくなくなってきた マルチクラウド

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

©MNTSQ, Ltd. 64 Terraform マルチクラウド

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

©MNTSQ, Ltd. 68 Terraformを利用する上での注意

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

©MNTSQ, Ltd. 76 stateを跨った情報を取得する際にリソースの命名規則やリソースタグの規則は非常に重要です 命名の重要性 Terraformを利用する上での注意

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