なぜインフラコードのモジュール化は難しいのか - アプリケーションコードとの本質的な違いから考える

by Gosuke Miyashita

Slide 1

Slide 1 text

YAPC::Fukuoka 2025 なぜインフラコードのモジュール化は難しいのかアプリケーションコードと本質的な違いから考える

Slide 2

Slide 2 text

YAPC::Fukuoka 2025 宮下剛輔合同会社Serverspec Operations代表社員フリーランスソフトウェアエンジニア　mizzy.org / 　mizzy / 　gosukenator YAPC 10年ぶり11回目参加 13年ぶり8回目トーク（前夜祭、LTソン含む）

Slide 3

Slide 3 text

YAPC::Fukuoka 2025 Infrastructure as Code関連主な著作（雑誌）

Slide 4

Slide 4 text

YAPC::Fukuoka 2025 Infrastructure as Code関連主な著作（書籍・論文）

Slide 5

Slide 5 text

YAPC::Fukuoka 2025 本発表趣旨 ● インフラコードモジュール化難しい ○ アプリケーションコードと同じ感覚でうまくいかない ○ 適切なモジュール化/モジュールを活用した運用が難しい ● なぜ難しいか、そ理由を言語化したい ○ 既存資料で十分に語られていない ● 難しさとどう向き合うべきかを考える ○ 難しさ理由がわかれ、向き合い方も見えてくるで ● 具体的なIaCツールとしてTerraformを扱います ● 多く考え方他 IaCツールにも適用できますが、すべてに当てまると限りません

Slide 6

Slide 6 text

YAPC::Fukuoka 2025 モジュールという用語について ● こ発表で、役割や責務でまとまった単位を総称して「モジュール」と呼びます ● 言語やツールごとにライブラリ、パッケージ、チャート（例: Kubernetes Helm）など呼び方異なりますが、議論を単純化するために共通語としてモジュールという言葉を用います ● ファイルやディレクトリに分割することも広義モジュール化として扱います

Slide 7

Slide 7 text

YAPC::Fukuoka 2025 Table of contents 01 02 04 05 03 06 インフラコードモジュール化難しさ利用しかた抽象化目的記述対象設計へ影響難しさとどう向き合うか状態を記述するインフラコード vs 処理を記述するアプリケーションコード構成パターン化 vs 処理カプセル化ホワイトボックス的利用 vs ブラックボックス的利用内部構造可視性 vs 抽象性・階層化

Slide 8

Slide 8 text

YAPC::Fukuoka 2025 インフラコードモジュール化難しさ 01

Slide 9

Slide 9 text

YAPC::Fukuoka 2025 Terraformモジュールに関する街声

Slide 10

Slide 10 text

YAPC::Fukuoka 2025 Terraformモジュール具体的な問題点 ● インフラコード固有でない問題（本発表で扱わない） ○ メンテされない ○ 互換性を壊す ● インフラコードで顕著な問題 ○ まとめすぎ ○ 細分化しすぎ ○ アプリケーションコードで悪い設計とされる ○ しかしインフラコードで有名モジュールでさえまかり通っている

Slide 11

Slide 11 text

YAPC::Fukuoka 2025 まとめすぎ

Slide 12

Slide 12 text

YAPC::Fukuoka 2025 まとめすぎ ● ひとつモジュールで扱うリソースが多すぎる ● 具体例: terraform-aws-vpcモジュール* * https://github.com/terraform-aws-modules/terraform-aws-vpc

Slide 13

Slide 13 text

YAPC::Fukuoka 2025 terraform-aws-vpcモジュール ● 定義されている変数 236個 ○ すべてオプショナル ● 扱っているリソースタイプ種類 32種類 ○ main.tf: 27種類 ○ vpc-ﬂow-logs.tf: 5種類（VPC Flow Logs関連リソース） ● 最小構成 4種類/4個リソース ● 最大構成 32種類/118個リソース本スライド数字 v6.4.0（2025年10月時点最新版）も

Slide 14

Slide 14 text

YAPC::Fukuoka 2025 terraform-aws-vpcモジュールで扱うリソースタイプ aws_cloudwatch_log_group aws_customer_gateway aws_db_subnet_group aws_default_network_acl aws_default_route_table aws_default_security_group aws_default_vpc aws_egress_only_internet_gateway aws_eip aws_elasticache_subnet_group aws_ﬂow_log aws_iam_policy aws_iam_role aws_iam_role_policy_attachment aws_internet_gateway aws_nat_gateway aws_network_acl aws_network_acl_rule aws_redshift_subnet_group aws_route aws_route_table aws_route_table_association aws_subnet aws_vpc aws_vpc_block_public_access_exclusion aws_vpc_block_public_access_options aws_vpc_dhcp_options aws_vpc_dhcp_options_association aws_vpc_ipv4_cidr_block_association aws_vpn_gateway aws_vpn_gateway_attachment aws_vpn_gateway_route_propagation

Slide 15

Slide 15 text

YAPC::Fukuoka 2025 VPC コア機能と関連が薄いリソースタイプ ● VPC Flow Logs関連 ○ aws_iam_policy ○ aws_iam_role ○ aws_iam_role_policy_attachment ○ aws_cloudwatch_log_group ● VPN関連 ○ aws_customer_gateway ○ aws_vpn_gateway ○ aws_vpn_gateway_route_propagation ● 特定サービス用サブネットグループ ○ aws_db_subnet_group ○ aws_elasticache_subnet_group ○ aws_redshift_subnet_group

Slide 16

Slide 16 text

YAPC::Fukuoka 2025 236個変数がすべてオプショナル ● リソース設定が全部変数化されている ● ど変数をどように設定すれ自分が望む構成になるか把握するが困難

Slide 17

Slide 17 text

YAPC::Fukuoka 2025 1542行 main.tf ● 全体像把握が不可能 ● メンテナンス性が低い

Slide 18

Slide 18 text

YAPC::Fukuoka 2025 terraform-aws-vpcモジュール問題 ● まとめすぎ ○ VPC関連であれなんでも詰め込む ○ 機能的な関連性でなく、分類的な関連性でまとめている ○ コア機能と周辺機能が混在 ■ Flow Logs、VPN、サブネットグループなど ● 結果として生じる問題 ○ 236個変数：内部構造がそまま露出 ○ 1542行 main.tf：全体像把握が不可能

Slide 19

Slide 19 text

YAPC::Fukuoka 2025 細分化しすぎ

Slide 20

Slide 20 text

YAPC::Fukuoka 2025 細分化しすぎ ● モジュールが過度に細分化されていて、ひとつモジュールが扱うリソースが少なすぎる ● 具体例: terraform-google-networkモジュール* * https://github.com/terraform-google-modules/terraform-google-network

Slide 21

Slide 21 text

YAPC::Fukuoka 2025 terraform-google-networkモジュール ● terraform-aws-vpcモジュールと対照的にサブモジュールに細かく分割されている ● main.tfが呼んでいるサブモジュール ○ modules/vpc ○ modules/subnet ○ modules/route ○ modules/ﬁrewall-rules

Slide 22

Slide 22 text

YAPC::Fukuoka 2025 サブモジュールで扱うリソース種類 ● modules/vpc: 2種類 ○ google_compute_network ○ google_compute_shared_vpc_host_project ● modules/subnets: 1種類 ○ google_compute_subnetwork ● modules/routes: 1種類 ○ google_compute_route ● modules/ﬁrewall-rules: 1種類 ○ google_compute_ﬁrewall

Slide 23

Slide 23 text

YAPC::Fukuoka 2025 過度な細分化 ● 各サブモジュールが1〜2種類リソースしか扱っていない ● VPC、サブネット、ルート、ファイアウォール密接に関連 ○ 通常セットで設計・管理するリソース群 ○ これらを分離することで、かえって全体像が把握しにくくなっている

Slide 24

Slide 24 text

YAPC::Fukuoka 2025 terraform-google-networkモジュール問題 ● 細分化しすぎ ○ 過度に細分化：各サブモジュールが1〜2種類リソースみ ○ 本来一緒に管理すべきリソース分離 ■ VPC、サブネット、ルート、ファイアウォール ● 結果として生じる問題 ○ 本来一緒にあるべきリソースが分離され、全体像が把握しにくくなる

Slide 25

Slide 25 text

YAPC::Fukuoka 2025 多段構成による問題悪化

Slide 26

Slide 26 text

YAPC::Fukuoka 2025 多段構成による問題悪化 ● terraform-google-network 2段階構成 ○ メインモジュール → サブモジュール ○ 既に「細分化しすぎ」と「まとめすぎ」が同時に存在 ■ 細分化しすぎ：サブモジュールが過度に分割されている ■ まとめすぎ：メインから呼れないサブモジュールも含まれる ● さらに階層が深くなる例も存在 ○ 3段階以上構成 ○ 問題がより複雑化・深刻化

Slide 27

Slide 27 text

YAPC::Fukuoka 2025 多段構成例 : terraform-google-project-factory* ● 3段階モジュール階層 ○ Level 1（メインモジュール）: 複数サブモジュールを呼び出し ○ Level 2（core_project_factory）: プロジェクトコア機能を管理 ○ Level 3（project_services）: API有効化とサービスアイデンティティ管理 * https://github.com/terraform-google-modules/terraform-google-project-factory

Slide 28

Slide 28 text

YAPC::Fukuoka 2025 terraform-google-project-factory 問題点 ● まとめすぎ ○ プロジェクト作成コア機能とオプショナルな機能が混在 ○ Shared VPC、Storage、Budgetなど多様なリソースを含む ● 細分化しすぎ ○ core_project_factoryがproject_servicesに依存 ○ 一緒にいるべきもが階層で分断されている ● 「まとめすぎ」と「細分化しすぎ」が同時に存在 ○ 結果として全体像把握が困難になり、依存関係追跡も複雑化

Slide 29

Slide 29 text

YAPC::Fukuoka 2025 多段構成による問題悪化 ● 2段構成から既に問題が発生 ○ terraform-google-network: 「まとめすぎ」と「細分化しすぎ」が同時に存在 ○ 全体像把握が困難 ● 3段構成以上でさらに複雑化・深刻化 ○ terraform-google-project-factory: 複数階層に問題が広がる ○ 全体像把握と依存関係追跡がより困難 ● 階層が深くなるほど、内部構造可視性が損なわれる

Slide 30

Slide 30 text

YAPC::Fukuoka 2025 凝集度と結合度

Slide 31

Slide 31 text

YAPC::Fukuoka 2025 凝集度* ● 偶発的凝集（最悪、凝集度が低い） ● 論理的凝集 ● 時間的凝集 ● 手続き的凝集 ● 通信的凝集 ● 逐次的凝集 ● 機能的凝集（最良、凝集度が高い） *Yourdon, E., & Constantine, L. L. (1979). Structured Design: Fundamentals of a Discipline of Computer Program and Systems Design. Prentice-Hall.

Slide 32

Slide 32 text

YAPC::Fukuoka 2025 結合度* ● 内容結合（最悪、結合度が高い） ● 共通結合 ● 外部結合 ● 制御結合 ● スタンプ結合 ● データ結合 ● メッセージ結合（最良、結合度が低い） *Yourdon, E., & Constantine, L. L. (1979). Structured Design: Fundamentals of a Discipline of Computer Program and Systems Design. Prentice-Hall.

Slide 33

Slide 33 text

YAPC::Fukuoka 2025 凝集度と結合度で見た問題 ● まとめすぎ ○ terraform-aws-vpcモジュール関連しそうなリソースをひとつモジュールにまとめている ○ 凝集度が低い状態（論理的凝集） ● 細分化しすぎ ○ terraform-google-networkモジュールリソースが過度に細分化されている ○ 親モジュールが変数で子モジュール構成を制御する必要がある ○ 結合度が高い状態（制御結合） ● 多段構成による問題悪化 ○ terraform-google-project-factoryモジュール ○ 凝集度低さ・結合度高さが同時に存在し、さらに複雑化

Slide 34

Slide 34 text

YAPC::Fukuoka 2025 コナーセンス

Slide 35

Slide 35 text

YAPC::Fukuoka 2025 コナーセンス * ● 2つモジュール間変更に関する依存関係 ● 一方変更が他方対応する変更を必要とする ● 構造化設計におけるモジュール結合よりも詳細なモデル ○ 知識共有され方を詳細に分類 ○ 静的コナーセンス: コンパイル時関係 ○ 動的コナーセンス: 実行時関係 *Page-Jones, M. (1996). What Every Programmer Should Know About Object-Oriented Design. Dorset House.

Slide 36

Slide 36 text

YAPC::Fukuoka 2025 コナーセンス ● 静的コナーセンス ○ CoN (Name) - 名前一致 ○ CoT (Type) - 型一致 ○ CoM (Meaning) - 値意味一致 ○ CoP (Position) - 位置一致 ○ CoA (Algorithm) - アルゴリズム一致 ● 動的コナーセンス（静的より強い結合） ○ CoE (Execution) - 実行順序 ○ CoT (Timing) - タイミング ○ CoV (Value) - 値 ○ CoI (Identity) - 同一性

Slide 37

Slide 37 text

YAPC::Fukuoka 2025 コナーセンスで分析限界 ● コナーセンスで分析を試みたが... ○ terraform-aws-vpc: 静的コナーセンス(CoN, CoT)が極端に多い ○ terraform-google-network: 基本的な静的コナーセンス(CoN, CoT) ● こケースで凝集度・結合度概念方が問題本質を捉えやすい ○ コナーセンス依存関係詳細な分類に有効 ○ しかし構造的な問題（論理的凝集など）説明に凝集度方が直感的

Slide 38

Slide 38 text

YAPC::Fukuoka 2025 統合強度

Slide 39

Slide 39 text

YAPC::Fukuoka 2025 統合強度* ● 構造化設計モジュール結合とコナーセンス、両方エッセンスを取り入れた新しい統合モデル ● 境界を越えて共有される知識種類や性質に基づいて結合を評価 *Khononov, V. (2024). Balancing Coupling in Software Design. Addison-Wesley. (邦訳: ソフトウェア設計結合バランス, インプレス, 2025)

Slide 40

Slide 40 text

YAPC::Fukuoka 2025 統合強度 ● 侵入結合（Intrusive coupling） ○ 実装詳細へ依存 ○ 最も強い結合 ● 機能結合（Functional coupling） ○ ビジネスロジック共有 ● モデル結合（Model coupling） ○ データモデル共有 ● コントラクト結合（Contract coupling） ○ 統合専用インターフェース ○ 最も弱い結合

Slide 41

Slide 41 text

YAPC::Fukuoka 2025 統合強度で見た問題 ● terraform-aws-vpc（まとめすぎ） ○ 236個変数を公開し、内部モデルをそまま共有（モデル結合） ○ 浅いモジュール*：複雑性をカプセル化できていない ○ 漏れある抽象化 ● terraform-google-network（細分化しすぎ） ○ 機能結合: 親が変数で子構成を制御 ● terraform-google-project-factory（多段構成） ○ モデル結合と機能結合が複合的に存在 *Ousterhout, J. (2018). A Philosophy of Software Design. Yaknyam Press. 浅いモジュール：公開インターフェースと実装差が小さいモジュール

Slide 42

Slide 42 text

YAPC::Fukuoka 2025 01 インフラコードモジュール化難しさまとめ ● 有名なパブリックモジュールによく見られる凝集度・結合度問題 ○ 論理的凝集（terraform-aws-vpc） ○ 制御結合（terraform-google-network） ● 多段構成が問題をさらに悪化させる ○ 2段構成で論理的凝集・制御結合が発生しうる ○ 3段構成でこれら問題がより深刻化・複雑化 ● アプリケーションコードで悪い設計として認識される ○ インフラコードでこれがまかり通っている ● 次章以降で、なぜ論理的凝集・制御結合がインフラコードで起きやすいかを考える

Slide 43

Slide 43 text

YAPC::Fukuoka 2025 記述対象 02 状態を記述するインフラコード vs 処理を記述するアプリケーションコード

Slide 44

Slide 44 text

YAPC::Fukuoka 2025 なぜインフラコードで凝集度・結合度問題が起きやすいか ● 1章で見たような問題アプリケーションコードで悪い設計として認識される ● なぜインフラコードで「まかり通っている」か？ ● インフラコードとアプリケーションコード違いに起因してそう

Slide 45

Slide 45 text

YAPC::Fukuoka 2025 根本的な違い : 状態記述 vs 処理記述 ● インフラコード「状態」を記述する ○ リソース詳細が主眼 ● アプリケーションコード「処理」を記述する ○ 処理役割が主眼

Slide 46

Slide 46 text

YAPC::Fukuoka 2025 インフラコード : 状態を記述する

Slide 47

Slide 47 text

YAPC::Fukuoka 2025 アプリケーションコード : 処理を記述する

Slide 48

Slide 48 text

YAPC::Fukuoka 2025 特徴比較 : 記述内容 ● 「VPC」「パブリックサブネット」「プライベートサブネット」あるべき状態を宣言 ● リソース状態を宣言し、依存関係を記述するインフラコードアプリケーションコード ● 「ユーザー検索」 → 「認証」 → 「セッション生成」といった手順を記述 ● 処理流れと呼び出し関係を記述する

Slide 49

Slide 49 text

YAPC::Fukuoka 2025 特徴比較 : 関心事 ● VPCやサブネット設定内容（CIDRブロック、DNS設定、AZ、Nameタグなど） ● リソース詳細な設定内容が関心事インフラコードアプリケーションコード ● ユーザー検索、認証、セッション生成 ● 処理役割が関心事で、実装詳細関心外

Slide 50

Slide 50 text

YAPC::Fukuoka 2025 特徴比較 : 抽象化しやすさ ● リソース詳細な内容や依存関係が関心事 ● 抽象化して隠蔽すると実際設定内容や依存関係が見えなくなる ● 抽象化できる範囲が限定的インフラコードアプリケーションコード ● 実装詳細関心外 ● 抽象化して隠蔽しても、処理流れが理解できれよい ● 広い範囲で抽象化でき、実装詳細を隠蔽できる

Slide 51

Slide 51 text

YAPC::Fukuoka 2025 02 記述対象まとめ ● インフラコードとアプリケーションコード根本的な違い ○ インフラコード：状態を記述する ○ アプリケーションコード：処理を記述する ● こ違いが関心事違いを生む ○ インフラコード：リソース詳細な設定内容が関心事 ○ アプリケーションコード：処理が何をするかが関心事 ● 関心事違い抽象化しやすさに影響する ○ インフラコード：詳細を隠せない → 抽象化しにくい ○ アプリケーションコード：詳細を隠せる → 抽象化しやすい ● 次章以降で、こ違いが抽象化目的やモジュール利用しかたにどう影響するかを考える

Slide 52

Slide 52 text

YAPC::Fukuoka 2025 抽象化目的 03 構成パターン化 vs 処理カプセル化

Slide 53

Slide 53 text

YAPC::Fukuoka 2025 関心事違いが抽象化目的を決める ● 2章で見た関心事違い ○ インフラコード：リソース詳細な設定内容が関心事 ○ アプリケーションコード：処理が何をするかが関心事 ● 抽象化目的 ○ インフラコード：詳細が関心事 → 構成パターン化 ○ アプリケーションコード：処理が何をするかが関心事 → 処理カプセル化

Slide 54

Slide 54 text

YAPC::Fukuoka 2025 インフラコード抽象化目的 ● 詳細が関心事なで、実装詳細隠蔽できない ○ 設定詳細や依存関係見えている必要がある ○ なで抽象化しにくい ● で何ために抽象化するか？ ○ 構成パターンを再利用するため ■ 構成パターンをテンプレート化して使い回す ■ セキュリティベストプラクティスを組み込む ■ 組織標準設定を適用する ● 例：3-AZ構成 VPC ○ パブリックサブネット×3、プライベートサブネット×3、NATゲートウェイ×3 ○ こ「パターン」をすべて環境に適用したい

Slide 55

Slide 55 text

YAPC::Fukuoka 2025 インフラコード：抽象化例

Slide 56

Slide 56 text

YAPC::Fukuoka 2025 アプリケーションコード抽象化目的 ● 処理が何をするかが関心事なで、実装詳細隠蔽できる ○ なで抽象化しやすい ● 抽象化することで何が実現できるか？ ○ 本質的な処理に集中できる ○ 実装変更を容易にする ○ 変更影響範囲を限定する ○ コードを再利用可能にする

Slide 57

Slide 57 text

YAPC::Fukuoka 2025 アプリケーションコード：抽象化例

Slide 58

Slide 58 text

YAPC::Fukuoka 2025 03 抽象化目的まとめ ● 関心事違いが抽象化目的を決める ○ インフラコード：詳細が関心事 → 構成パターン化 ○ アプリケーションコード：処理が何をするかが関心事 → 処理カプセル化 ● インフラコード構成パターンを再利用する ○ 詳細を隠蔽できないため、パターンをテンプレート化して使い回す ○ セキュリティベストプラクティスや組織標準設定を適用する ● アプリケーションコード処理をカプセル化する ○ 詳細を隠蔽して、本質的な処理に集中できるようにする ○ 実装変更を容易にし、変更影響範囲を限定する ● 次章で、こ違いがモジュール利用しかたにどう影響するかを考える

Slide 59

Slide 59 text

YAPC::Fukuoka 2025 利用しかた 04 ホワイトボックス的利用 vs ブラックボックス的利用

Slide 60

Slide 60 text

YAPC::Fukuoka 2025 抽象化しやすさ違いが利用しかたに影響 ● 2章で見た関心事違い、抽象化しやすさも決める ○ インフラコード：詳細が関心事 → 詳細を隠せない ○ アプリケーションコード：処理が何をするかが関心事 → 詳細を隠せる ● 抽象化しやすさ違い、モジュール利用しかたに影響する ○ インフラコード：モジュール中身を理解して使う必要がある ○ アプリケーションコード：モジュール中身を知らなくても使える ● モジュール使い方 ○ インフラコード：ホワイトボックス的利用（中身を理解して使う） ○ アプリケーションコード：ブラックボックス的利用（中身を知らずに使える）

Slide 61

Slide 61 text

YAPC::Fukuoka 2025 インフラコード：ホワイトボックス的利用 ● モジュール中身を理解して使う必要がある ○ どんなリソースが作られるか ○ どういう依存関係になるか ○ どんな設定が可能か ● モジュール全容が把握しやすい必要がある ○ コードを読め理解できる ○ ドキュメントで構成内容が把握できる ○ 要件に過不足ない構成（内容が推測しやすい） ○ 合意形成を通じた共通理解形成 ● パブリックなモジュールをそまま使う難しい ○ 要件に完全に合致するモジュール少ない ○ 組織内で管理されたモジュールを使うか、自作する

Slide 62

Slide 62 text

YAPC::Fukuoka 2025 インフラコード：モジュール中身

Slide 63

Slide 63 text

YAPC::Fukuoka 2025 アプリケーションコード：ブラックボックス的利用 ● モジュール中身を知らなくても使える ○ インターフェースだけわかれよい ○ 何をするかがわかれよい ○ どうやっているか知らなくてよい ● モジュール全容を把握する必要ない ○ インターフェースが安定していれよい ○ 内部実装知らなくてよい ○ 後方互換性が保たれていれよい ● パブリックなモジュールもそまま使えることが多い ○ インターフェースが明確に定義されている ○ 処理抽象化により汎用的な要件として利用できる

Slide 64

Slide 64 text

YAPC::Fukuoka 2025 アプリケーションコード：関数中身

Slide 65

Slide 65 text

YAPC::Fukuoka 2025 利用しかた違い ● モジュール中身を理解して使う必要がある ● モジュール全容が把握しやすい必要がある ● パブリックなモジュールをそまま使う難しいインフラコード：ホワイトボックス的利用アプリケーションコード：ブラックボックス的利用 ● モジュール中身を知らなくても使える ● モジュール全容を把握する必要ない ● パブリックなモジュールもそまま使えることが多い

Slide 66

Slide 66 text

YAPC::Fukuoka 2025 04 利用しかたまとめ ● 抽象化しやすさ違いがモジュール利用しかたに影響する ○ インフラコード：詳細把握が必要 ○ アプリケーションコード：詳細把握不要 ● モジュール利用しかた ○ インフラコード：ホワイトボックス的利用 ■ モジュール中身を理解して使う必要がある ■ パブリックなモジュールをそまま使う難しい ○ アプリケーションコード：ブラックボックス的利用 ■ モジュール中身を知らなくても使える ■ パブリックなモジュールもそまま使えることが多い ● こ違いモジュール設計に影響する

Slide 67

Slide 67 text

YAPC::Fukuoka 2025 設計へ影響 05 内部構造可視性 vs 抽象性・階層化

Slide 68

Slide 68 text

YAPC::Fukuoka 2025 利用しかた違いがモジュール設計に影響 ● 4章で見た利用しかた違い ○ インフラコード：ホワイトボックス的利用 ■ モジュール中身を理解して使う必要がある ○ アプリケーションコード：ブラックボックス的利用 ■ モジュール中身を知らなくても使える ● こ違いモジュール設計考え方に影響する ○ ホワイトボックス的利用 → 内部構造可視性を重視 ○ ブラックボックス的利用 → 抽象性・階層化を重視 ● インフラコードとアプリケーションコードで、設計優先順位が異なる

Slide 69

Slide 69 text

YAPC::Fukuoka 2025 インフラコード：内部構造可視性を重視 ● モジュール中身を理解する必要がある ○ → 内部構造が見えるように設計する ● 内部構造可視性を高めるため設計 ○ 内部構造が見えやすい粒度で分割する ○ 階層を深くしすぎない ○ 階層深さを統一する ● 抽象化しすぎると逆効果 ○ 何が作られるか見えなくなる ○ 依存関係が隠蔽される ○ 値定義と使用場所が離れ、実際設定が把握しにくい ○ 内部構造が見えなくなる

Slide 70

Slide 70 text

YAPC::Fukuoka 2025 アプリケーションコード：抽象性・階層化を重視 ● モジュール中身を知る必要がない ○ → 抽象化して詳細を隠す設計をする ● 抽象性を高めるため設計 ○ インターフェースを明確にする ○ 実装詳細を隠蔽する ○ 階層化して複雑さを管理する ● 抽象化が設計基本 ○ 処理流れが理解できれよい ○ 実装詳細変更可能 ○ モジュール独立性が高まる

Slide 71

Slide 71 text

YAPC::Fukuoka 2025 インフラコード：階層化問題 ● 2段構成でも問題が発生 ○ 本来一緒に管理すべきリソースが分離される ○ 内部構造が見えにくくなる ● 3段構成以上でさらに深刻 ○ 「まとめすぎ」と「細分化しすぎ」が同時に存在 ○ 内部構造把握と依存関係追跡が困難 ● 階層深さが統一されていないとさらに問題 ○ あるモジュール 2段、別モジュール 3段、また別 4段 ○ 統一性なさが内部構造把握を困難にする ● インフラコードで階層化慎重に ○ 階層を深くするほど内部構造可視性が損なわれる ○ 階層深さを統一することも重要

Slide 72

Slide 72 text

YAPC::Fukuoka 2025 アプリケーションコード：階層化メリット ● 階層化複雑さを管理する有効な手段 ○ 適切に抽象化すれ、各層役割が明確になる ● 階層化による整理例（データベース操作） ○ ORM → database/sql → ドライバ ○ 各層が明確なインターフェースを提供し、実装詳細を隠蔽 ● 階層が深くても問題になりにくい ○ 各層インターフェースを理解すれよい ○ 実装詳細隠蔽されている ● インフラコードと対比 ○ 階層化が設計基本的な手法 ○ 深い階層も適切に設計すれ問題ない

Slide 73

Slide 73 text

YAPC::Fukuoka 2025 設計優先順位違い ● 内部構造が見えやすい粒度で分割する ● 階層を深くしすぎない ● 階層深さを統一するインフラコード：内部構造可視性を重視アプリケーションコード：抽象性・階層化を重視 ● インターフェースを明確にする ● 実装詳細を隠蔽する ● 階層化して複雑さを管理する

Slide 74

Slide 74 text

YAPC::Fukuoka 2025 05 設計へ影響まとめ ● 利用しかた違いが設計優先順位に影響する ○ インフラコード：ホワイトボックス的利用 ○ アプリケーションコード：ブラックボックス的利用 ● 設計優先順位が異なる ○ インフラコード：内部構造可視性を重視 ■ 内部構造が見えやすい粒度で分割する ■ 階層を深くしすぎない ■ 階層深さを統一する ○ アプリケーションコード：抽象性・階層化を重視 ■ インターフェースを明確にする ■ 実装詳細を隠蔽する ■ 階層化して複雑さを管理する ● こ違いがインフラコードモジュール化を難しくしている

Slide 75

Slide 75 text

YAPC::Fukuoka 2025 02-05章まとめ ● 記述対象違い ○ インフラコード：状態を記述 → 詳細が関心事 ○ アプリケーションコード：処理を記述 → 処理が何をするかが関心事 ● 抽象化目的違い ○ インフラコード：構成パターン化 ○ アプリケーションコード：処理カプセル化 ● 利用しかた違い ○ インフラコード：ホワイトボックス的利用 ○ アプリケーションコード：ブラックボックス的利用 ● 設計優先順位違い ○ インフラコード：内部構造可視性を重視 ○ アプリケーションコード：抽象性・階層化を重視 ● これら違いが、インフラコードモジュール化を難しくしている

Slide 76

Slide 76 text

YAPC::Fukuoka 2025 難しさとどう向き合うか 06

Slide 77

Slide 77 text

YAPC::Fukuoka 2025 難しさとどう向き合うか ● これまで見てきた難しさ ○ インフラコード詳細が関心事で抽象化しにくい ○ ホワイトボックス的利用が必要で、内部構造可視性を重視する必要がある ○ ブラックボックス的利用を前提としたアプリケーションコード感覚でモジュール化すると問題が起きる ● こ本質的な違いを理解した上で、向き合い方を考えてみます ● 基本的に Terraform 話になります

Slide 78

Slide 78 text

YAPC::Fukuoka 2025 向き合わない

Slide 79

Slide 79 text

YAPC::Fukuoka 2025 向き合わない ● 無理にモジュール化しない ○ シンプルに保つ ○ 必要になるまでモジュール化を避ける ● YAGNI (You Aren't Gonna Need It) ○ 本当に必要になってから考える ● 事例: バイセルテクノロジーズ* ○ 共通moduleを廃止してシンプルな構成に変更 ○ チーム全員がメンテナンスできることを優先 * https://tech.buysell-technologies.com/entry/modify_terrafrom_architecture

Slide 80

Slide 80 text

YAPC::Fukuoka 2025 ディレクトリ分割

Slide 81

Slide 81 text

YAPC::Fukuoka 2025 ディレクトリ分割 ● ディレクトリ分割も広義モジュール化 ● 機能的凝集を意識して分割する ○ 右図あくまでも一例 ○ 巷ベストプラクティスに囚われるな ● なるべくお互いに依存しないような形でわける ● 依存がある場合、変更少ないもに依存する ● Terraform ディレクトリ構成変更割と容易にできるで気軽にやる ○ import/moved/removedブロックやtfmigrate*を活用 ○ 安全に変更するため CI/CDワークフローを組む * https://github.com/minamijoyo/tfmigrate

Slide 82

Slide 82 text

YAPC::Fukuoka 2025 ファイル分割

Slide 83

Slide 83 text

YAPC::Fukuoka 2025 ファイル分割 ● ファイル分割も広義モジュール化 ● これも機能的凝集を意識する ○ 論理的凝集にしない ■ 例: security_groups.tfにセキュリティグループを詰め込む避ける ● main.tfというファイル名避ける ○ 機能を表す適切な名前にする ○ ただしひとつしかtfファイルがない場合 main.tfでも問題ない ○ そもそも状態を記述しているで、処理起点となるmainなエントリポイント存在しない ● Terraform ファイル構成を後からいくらでも変更できるで気軽にやる

Slide 84

Slide 84 text

YAPC::Fukuoka 2025 モジュール機能利用

Slide 85

Slide 85 text

YAPC::Fukuoka 2025 モジュール機能利用 ● これも機能的凝集を意識する ● 誤ったDRYに注意 ○ 表面的な類似性だけで共通化しない ● モジュール目的や内容が予測しやすい名前や構成にする ○ 例: ecsでなくecs_on_managed_instances ● 組織や機能に適したデフォルト設定を内部で定義する ○ 合意形成が重要 ● 階層を深くしすぎない、階層深さを統一する ● レベル分けするもあり ○ CDK L2, L3コンストラクトようなイメージ

Slide 86

Slide 86 text

YAPC::Fukuoka 2025 パブリックモジュール原則として利用しない

Slide 87

Slide 87 text

YAPC::Fukuoka 2025 パブリックモジュール原則として利用しない ● 汎用的すぎる ○ 論理的凝集になっていて機能的凝集になっていない ○ 共有される知識（変数）が多い ■ 大量変数を公開し、内部モデルをそまま共有（モデル結合） ■ 浅いモジュール：複雑性をカプセル化できていない ■ 境界を越えて共有される知識を削減できていない ■ 利用者認知負荷を増加 ● なぜインフラコードこれが起こるか ○ 詳細が関心事なで、抽象化できる範囲が限定的 ○ 汎用性を求めると、あらゆるケースに対応しようとする ■ 機能を詰め込む（論理的凝集） ■ 細分化しすぎる（制御結合） ■ 内部モデルをそまま大量変数として公開（モデル結合、漏れある抽象化）

Slide 88

Slide 88 text

YAPC::Fukuoka 2025 06 難しさとどう向き合うかまとめ ● 向き合わない ○ 無理にモジュール化しない、YAGNI ○ シンプルに保つことを優先 ● ディレクトリ分割・ファイル分割 ○ 論理的凝集でなく機能的凝集を意識 ● モジュール機能利用 ○ 論理的凝集でなく機能的凝集を意識 ○ 組織や機能に適したデフォルト設定を内部で定義する ○ 階層を深くしすぎない、階層深さを統一する ● パブリックモジュール原則として利用しない ○ 汎用的すぎて論理的凝集・制御結合になりやすく、内部モデルをそまま大量変数として露出している（モデル結合、漏れある抽象化） ○ 組織内で管理されたモジュールを使うか、自作する

Slide 89

Slide 89 text

YAPC::Fukuoka 2025 本発表まとめ ● インフラコードとアプリケーションコード本質的に異なる ○ インフラコード：状態を記述 → 詳細が関心事 → 構成パターン化 ○ アプリケーションコード：処理を記述 → 処理が何をするかが関心事 → 処理カプセル化 ● こ違いがモジュール化難しさを生む ○ インフラコード：内部構造可視性が必要（ホワイトボックス的利用） ○ アプリケーションコード：抽象化が可能（ブラックボックス的利用） ● 難しさを理解した上で、適切に向き合う ○ 無理にモジュール化しない（YAGNI） ○ 機能的凝集を意識する ○ 組織や機能に適したデフォルト設定を内部で定義する ○ 階層を深くしすぎない、階層深さを統一する ○ パブリックモジュール原則として使わず、組織内で管理する

Slide 90

Slide 90 text

YAPC::Fukuoka 2025 CREDITS: This presentation template was created by Slidesgo, and includes icons, infographics & images by Freepik Thank you mizzy.org mizzy gosukenator