作成: 更新:

「Infrastructure as Codeのこれまでとこれから」参加まとめ

infrastructureCIdevopsIaCIaaS

(forkwellさん主催) Infra Study Meetup #1
mizzy氏の「Infrastructure as Codeのこれまでとこれから」
https://www.youtube.com/watch?v=m1mm9VngA8g&t=8s ※動画です

上記インプットに、IaC初心者目線でIaCの歴史と概要を総括しました。

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疲れの改善にも