IaC本輪読 1章「課題と原則」
会社でやっているIaC本の輪読メモ
1.1 なぜIaCなのか
- IT運用の仕事の課題
- 最新最良のツール・プラットフォームを導入しても日々のワークロードについていけない
- システムの抱える問題を修正する時間がない
- 自動化しようものなら、ポートフォリオが膨らみ破綻させないことだけに時間が費やされる
- 課題への立ち向かい方
- クラウドとオートメーションはツールは、インフラの変更の障壁を下げるが一貫性・信頼性を担保しない
- ツールの使い方・プロセス・慣習は人々が考える必要がある
- オートメーションが一般になる前のプロセス、構造、ガバナンスは適用できない(ITILv3的な？)
- クラウド・オートメーションの発展についていくためにInfrastrcture as Codeが必要
IaCとは何か
IaCはソフトウェア開発のプラクティスを、インフラのオートメーションに活かすアプローチ
- 現代のツールセットならインフラをソフトウェアとデータのように扱えることが前提
- プロビジョニング・構成・設定・変更を冪等なルーチンにする
- 変更は定義になり、検証を含む無人プロセスでロールアウトされる
IaCの目標
- ITインフラが変化の障害や制約になるのではなく、変化を支えて実現すること
- システム変更がストレスなく日常作業になること
- Toilからの解放
- ユーザが自らリソースを作成・管理できること
- 失敗を完全に防ぐのではなく、簡単スピーディーにHAできること
- クラウドプロバイダーとしてこれ難しいですよね、責任共有モデルとは...
- ビックバンではなく、継続的な改善・改良を実現すること
- 実装・テスト・計測でソリューションの効果が証明できるようになること
クラウドだけじゃないIaC クラウド、オンプレ仮想化だけでなく物理機器にも適用できる 従来手作業でプロビジョニングされてきたサーバは、サーバ構成ツールを使って、構成・設定・アップデートできる
ダイナミックインフラストラクチャが生み出した課題
サーバスプロール
サーバの数が増えすぎると、問題が発生してもすべてのシステムにフィクスを充てるのが難しくなる。サーバのバージョン・構成の違いのせいで、ソフトウェア・スクリプトの冪等が崩れる。 このサーバ間の不統一を構成ドリフトと呼ぶ。
構成ドリフト
- 誰かがESXiのドライバを変更すると、そのESXIは他のESXiと別物になる
- JIRAの新しいバージョンが、新しいJavaを必要とするが、Javaの横並びテストができずアップデートしていいか判断できない
違いがあるのは悪くないが、違いが管理できなくなった瞬間に悪
スノーフレークサーバ
スノーフレークサーバは、ネットワーク上の他のすべてのサーバと異なるサーバ
- Perl5.6を使っていたが、ツールの関係でPerl5.8に移行した。が、重要なアプリが5.8で動作しなかった
- そのアプリは共有ステージングを5.8にしたときには動作していたが、本番環境を5.8にしたらクラッシュした
- ステージングには5.8でも動作する特別なサーバが存在した
- 結果、ステージングには5.6を残し、本番でプリのたびに祈っていた
上記の反省をもとに、IaCの足掛かりを見つけた
- Infrastrcture.orgでIaCの前触れのような考えを知り
- 構成ツールで構成・設定し、バージョン管理システムで管理することで反復可能にした
このようなサーバを多くの運用が抱えていることが問題
- AIXやのような特定の特別なプラットフォームでしか動作しないものもある
- ただ、それがどのようなサーバであっても、自信をもって素早くし再構築できなければいけない
- 要件をみたさないサーバがあるなtら、代わりとなるサーバの構築や、再現可能なプロセスを作り上げる必要がある
オートメーション恐怖症
- オートメーションに自身が持てないのは、サーバに統一性がないから
- オートメーションの結果が怖いから、ツールに任せっぱなしにできない
- これは悪の循環なので、自分の恐怖に向き合い、無人実行する
- 優れたモニタリングと、自動テストの体制が確立すれば自身も生まれる
システム疲労
インフラが時間の経過の共に壊れていくこと(Heroku発祥)
- パッチあて
- ログファイルの成長によるディスク減
IaCの原則
簡単に再現できるシステム
インフラのあらゆる構成要素は、人手をかけずに確実に再構成できなければならない
- 人手をかけずとは、再構築の方法について判断をしなくてよいこと
- インフラに再現性が生まれると、変更を気軽に実行できるようになる
使い捨てにできるシステム
ダイナミックインフラのメリットは、リソースを簡単にCRUDできること
- インフラはいつも変化する前提でシステムを設計すること
- 変化に耐えうるようになれば、実行中のインフラに改良・修正を加えることも簡単になつ
鉄の時代(オンプレ)からクラウド時代での根本的な違い
- ハードウェアの信頼性が違う
- 信頼性の低いハードウェアの下で、確実に実行できるソフトウェアにシフトする
統一的なシステム
- インフラの中に同じようなサービスを提供する2つのサーバがある場合、それらのサーバはほぼ同じでないよイケナイ
- 不統一な部分があると、オートメーションが信頼できなくなる
- ただ、構成要素を変更する必要がある場合は(片方のサーバだけ大きなパーティションが必要)
- 両方のサーバが大きなパーティションを持つように変更する
- xl-file-serverのような新しいクラスを設定する
反復できるプロセス
再現可能原則に基づき、インフラに対するアクションは反復可能でなければならない
- ハードディスクのパーティション分割のように、１度限りに見えるタスクは自分でやる方が簡単に見える
- ただ、チームの同僚が自分と同じようにNTFSでフォーマットするとは限らない
- スクリプト実行できるタスクは、必ずスクリプトにしなければならない
絶えず変化するデザイン
- 鉄の時代のITでは、変更を実施するのは難しく、将来のニーズや状況を考慮に入れた設計を行う必要があった
- システムの使われ方を正確に予想できないため、過度に複雑なシステムが生まれる
- その結果、変更はより難しくなる
- クラウド時代のダイナミックインフラでは変更に悩まされない
- 変更管理しやすく設計されていれば
- 変更に対応できるようになるもっとも重要な手段は、頻繁な変更
- 変更が頻繁であてば、変更管理に適した習慣を身に着ける
プラクティス
定義ファイルの利用
定義ファイルの利用はIaCの基礎中の基礎のプラクティス
- 定義ファイルは、インフラ要素と構成・設定方法をしている巣
- 定義ファイルはプロビジョニングツールのインプットになる
- 定義・設定はDBに格納するよりも、テキストで保持する方がアクセスしやすい
自己記述システムとプロセス
- ドキュメントは変更管理からもれ、虚像になっていることが多い
- IaCでは、プロセスを実施sるための手順は、プロセスを実装するスクリプト・定義ファイルに書き込まれている
あらゆるものをバージョン管理する
VCSはコードとして管理されるインフラの中心的な構成要素。望ましい状態のインフラはVCSがもとになる
- トレーサビリティ
- くわえられた変更と変更者の履歴管理
- ロールバック
- 相関関係の管理
- スクリプト・構成がバージョン管理され、相関関係がタグで示されていると、複雑な問題の解決に役立つ
- 可視性
- VCSに変更がコミットされることで、チームが状況を把握しやすくなる。重大な見落としも気づきやすくなる。
- アクショナビリティ
- コミットをトリガに、してCI/CDしていく
継続的テストシステム、プロセス
インフラがソフトウェア開発から借用できるもっともの重要なプラクティスは自動テスト
- 既存の古いシステムのために自動テストをするのは難しい
- 開発中に継続してテストを事項すると、変更に対するフィードバックを素早く返せる
- フィードバックが早ければ、ひんぱんな変更への自信が生まれる
- オートメーションへの恐怖心が解消される
一斉変更ではなく小刻みな変更
大きな変更より、小さな変更が望ましい理由
- 小さな変更をテストして動かす方が、作業量が少ない
- おかしくなった時も原因がみつけやすい
- ロールバックも簡単
継続的にサービスを利用可能な状態に保つ
インフラで何が起きても、サービスが傾向できるようにする。サービスとデータをいつでも利用可能な状態にする
アンチフラジャイル：「堅牢」をこえて
堅牢なインフラは典型的な目標だが、IaCでは堅牢を超えてアンチフラジャイルを目指す
- エクササイズは筋肉を痛みつけるが、体はそれでつよくなる
- もやしっ子は弱い
- システムも絶えず変更にさらす方が、堅牢になっていく
- 対応する組織としても
アンチフラジャイルなITシステムの秘密の成分
- システム運用者は、システムを理解し継続的に変更を加えなければならない
- システムを変更できる人もまた、システムの一部
- ITシステムを継続的に改良するカギは構築・運用する人
- ニーズの変化に対応できるシステム設計の秘訣は、人を中心に据えて設計すること
まとめ
インフラチームの有能さは、変化する要件をどう処理するかでわかる
