Terraformモジュールはなぜ魔境化するのか¶
チェック¶
- [ ] 本文を確認した
- [ ] 概要を確認した
- [ ] タグを確認した
- [ ]
inbox/直下へ移行した
概要¶
Cloud Native Kaigi の採択セッション概要。
「コピペを減らす」善意で作った Terraform module が、大量の variable、複雑な count / dynamic、意図の見えない抽象化により、数か月後に誰も触りたくない状態になる問題を扱う。
主因は「テンプレートとしての共通化」と「コンポーネントとしてのカプセル化」を混同すること。
白箱テンプレートと黒箱コンポーネントを分けて設計する、という方針が提示されている。
本文¶
Terraform module は、重複削減のために導入されがち。 しかし「将来の変更を楽にする」つもりが、実際には「実装理解のための重いコンテキスト」を未来の利用者に強いているだけになることがある。
セッション概要では、魔境化の主因を次の混同として定義している。
- テンプレート、つまり共通化
- カプセル化、つまり隠蔽
ホワイトボックス・テンプレートでは、透過性を重視する。 クラウドの仕様を隠さず、利用者が生成される resource の構造や制約を理解できるようにする。 チーム内の繰り返しを減らすための共通化なら、過剰に black box 化しないほうがよい。
ブラックボックス・コンポーネントでは、異なるチームの利用者に対して「意図」だけを伝える。 内部実装を隠してもよいが、その代わり interface、責務、変更可能性、運用境界を明確にする必要がある。
資料の中核は、動的な topology 変更を module の内部に押し込めないこと。
count や dynamic を使ってあらゆるケースを吸収しようとすると、module の利用者は入力値の意味と生成される構成の両方を追う必要があり、認知負荷が上がる。
要点¶
- Terraform module の抽象化は、共通化と隠蔽を分けて考える。
- 白箱テンプレートはクラウド仕様を隠さず、透過性を重視する。
- 黒箱コンポーネントは意図と interface を安定させる。
count/dynamicで topology を過剰に可変にすると保守が難しくなる。- 抽象化はコピペ削減だけでなく、未来の変更理解コストで評価する。