IaCから見るインフラ開発とソフトウェア開発の歴史

システム管理自動化時代

(1993)CFEngine
(2005)puppet
(2006)AWS EC2でプログラマブルにインフラ構築できるようになった
→(2008)puppetのようなCF手法をIaCとよぼう
chef
→chefの広まり＝IaCの言葉の広まり

ソフトウェア開発プラクティス統合時代

(2008)アジャイルの始まり(Agile Infrastructure and Operations)
(2009)devOpsの広まり
→目的が変わってくる(ソフトウェア開発のプラクティスをシステム管理に応用するため)
(2011)テスト駆動開発の始まり(Test-Driven Infrastructure with Chef)

対象環境スコープ超増加時代

IaaSの普及(aws, azure, gcp...)
kubernetes(所感：この時期になると、むしろIaC以外は少数派、IaCが標準)
ansible
terraform
ディザスタリカバリもIaCに
(＝災害などによる被害からの回復措置、あるいは被害を最小限に抑えるための予防措置のこと)

現在のIaC

クラウドの普及により、今までのオンプレで起こり得なかった問題が多発
- わざわざ物理マシンを調達しなくて良くなった

問題点

サーバスプロール
- サーバが気軽に簡単に建てれるようになった
- サーバの乱立、各サーバのちょっとした設定差異
- 構成ドリフトが発生
構成ドリフト
- 設定差異を埋める必要がでてきた
- 暫定対応を重ねる
  - やむを得ず一時的な対応をしたが戻し忘れる
  - 設定対応者のスキルにより、オペレーションに若干の違いがでる
- スノーフレークサーバ・オートメーション恐怖症が発生
スノーフレークサーバ
- サーバ毎に設定が完全に異なる
- 設定把握できなくなる
- 脆弱なインフラに突き進んでく
オートメーション恐怖症
- 設定が異なるサーバに対し、自動化ツールを使うことが怖い
  - 設定が把握できてないので、結果が予測不能
  - 設定の調査コストが異常に高いのでおっくう
システム疲労
- 時間の経過とともにシステムが壊れていく
- 変更しないことにより発生

問題点ざっくりまとめ

サーバラクに建てれるようになった
→変更管理ができない
→変更はしなければいけない
→地雷踏んで終わり

発生原因

インフラのリードタイムコストが減った
ビジネス要求の変化にインフラ側も迅速に対応する必要性
- 深堀
↑は従来インフラ技術ではついていけない

解決策

IaCを学ぼう
- サーバガンガン立てて、変更ガンガンやる
- 変更をきっちり管理する必要
- 変更管理をするためのIaC

IaCが目指すインフラ

簡単に再現
- 人的コスト最小限に再構築可能
- スノーフレーク化減少に寄与できるため
- 簡単な再構築なら、変更してもすぐ戻せるので気がラク
使い捨てにできる
- 現状のIaaSなら可能だが。。。
  - 捨てた場合、システムの設計によっては影響するかも。
- システムが動き続けれるように設計すべき
- 致命的な障害発生時は捨ててから考えれるようにできる
統一的
- 構成ドリフトをなくそう
- 自動化ツールを使えるようにしよう
反復可能
- 構築手順をスクリプト化しよう
変化に耐えれる
- IaaSは、載せるシステムが「すべての部分が変更しやすく設計されている」という前提で設計されている
- 載せるシステム(ソフト、インフラ)は変更可能に、単純に設計しなければならない
- ひんぱんに変更する習慣をつけ、変更にたえれるか日々チェックする

IaCの実現方式

定義ファイル
- テキストで管理
  - puppetのマニフェスト
  - chefのレシピ
  - terrformのhcl
  - k8sのyaml
自己記述システムとプロセス
- ドキュメントは必要であったときのみ、最小限
  - スキトラ時・スクリプト読めない人に対する説明資料
- 手順はスクリプトを読もう
  - 実行可能なドキュメントの作成を
バージョン管理
- トレーサビリティ
- ロールバック
- 相関関係管理
- 可視性
- アクショナビリティ(コミット契機でビルド、デプロイ、テスト...)
継続的テスト
- スクリプト変更が契機
  - テスタビリティの向上
  - テスタビリティの向上につとめれば自然と疎結合になってく
  - 変更により、すぐテスト結果が発生する
  - 変更への心理的安全性向上

アンチフラジャイル

システムを鍛えて(=変更しまくって)強くしていこう！
- 自動化しての変更だけじゃたりない
- システム設計の中心(=コアドメイン)は「人間」

総括

インフラが変化の制約だった
クラウドで変化の制約なくなった
インフラの変化に対応していくことも意識しよう

IaCに対するスピーカの所感

IaC自体はエンジニアリング行う者の前提知識、当たり前
IaC時代が終わっても、IaCのプラクティスは使えるものばかり。生き続けるはず。
IaC is dead. Long live IaC!

質疑応答タイムでおもったこと

IaCを使うことを目的とするな！
- でも、「おもしろそうだからやってみる」においてのフィードバックの価値は結構でかいよ
アンチパターン
- chef,puppetのテストをそのままserverspecに流用する
- 再利用できるためにnginxのパラメータをすべてコード化、モジュールに
IaC疲れ
- IaCが目的になっちゃってる
- 単純にIaCが流行ってきて、昔のコードが負債化してるだけ？
- 色々なツールが巷にあるけど、シェルスクリプトとかでもいい
- とりあえずなんか有名どころ触ってみて考えよう
- 導入コストは高めなのはしょうがない、導入コストは覚悟して
- やりすぎず、ちっちゃくコツコツと
IaCのロードマップはない、IaCスコープはでかすぎる
- 新しいシステムを
  - awsとterraformでhelloworldくらいがてっとりばやそう
- 既存のシステムを
  - ちっちゃなスクリプトを書いてく→IaC疲れの改善にも