- JAWS DAYS 2014 に参加して Immutable Infrastructure セッションを聴いてきたのでまとめてみました
- 正直初めて聞いたので、認識違いがあるかもしれません
(最初に)まとめ
- インフラ環境構築の手順書を Chef 等に置き換えてソースコード管理をする
- ソースコード化により、バージョン管理・テストが容易になる
- 手順書(コード)からの環境構築が自動化できる
- 何度も同じ環境が作れる
- すでに動いている環境に手を加えない
- 必ず修正は手順書(コード)に行う
- 環境を更新したい場合は、修正した手順書から新規に構築し直す
- いらなくなったら削除する
Immutable Infrastructure とは
- サーバインフラの管理の仕方
- 一度構築したサーバの設定変更をしない
- サーバの状態管理を行わない
- 新しい環境が必要になったら新規に作成する
- 不要になったら破棄する
従来の考え方との違い
- 従来
- デプロイの際、動作中のサーバに対してソースコードの反映、設定の更新をする
- Immutable Inftastructure
- デプロイの際に、新規にサーバインフラを構築し、そこに新しいソースコードを適用
- 正しく動けば古い環境を破棄する
- 万が一新規に立ち上げたサーバが期待動作にならない場合、即座にロールバック可能
前提条件
- クラウド上の仮想サーバを使用していること(AWS 等)
- オンプレの物理サーバでできなくもないとは思うが…
- インフラ環境を使い捨てにするため何度も正しく構築できること
メリット
- AWS などの Auto Scaling と相性が良い
- いつでもだれでも同じ状態のサーバインフラの構築ができる
- だれでもできるためインフラ整備が特定の人に依存しない
- いつでもできるため運用中のサーバの故障にもすぐに対応できる
- すぐにロールバック可能
デメリット
- 不要となったサーバを破棄するため、ログの蓄積が大変
- DB 等に適用する方法が確立されていない
Infrastructure as Code
- Immutable Infrastructure を実現する上で重要
- 従来、Word, Excel 等で管理していたインフラ構築の手順書(ドキュメント)をソースコード(Chef 等)にして管理する
- ソースコードになるため、インフラ構築も自動化が可能になる
- 手動によるミスを無くすことが可能
メリット
- もちろん自動化
- デプロイも用意になる
- 数が多くても問題にならない
- ソースコードになっているため、インフラ環境が Git 等でバージョン管理できる
- 前のバージョンに戻すのも容易
- コードレビューができる
- さらにテストも容易になる
デメリット
- すでに運用中のサービスに改めて適用するには敷居が高い(気がする)
実現のために有用な技術
- Chef
- Puppet
- Docker
まとめ(再掲)
- インフラ環境構築の手順書を Chef 等に置き換えてソースコード管理をする
- ソースコード化により、バージョン管理・テストが容易になる
- 手順書(コード)からの環境構築が自動化できる
- 何度も同じ環境が作れる
- すでに動いている環境に手を加えない
- 必ず修正は手順書(コード)に行う
- 環境を更新したい場合は、修正した手順書から新規に構築し直す
- いらなくなったら削除する
参考
https://speakerdeck.com/naoya/immutable-infrastructure-number-jawsdays
http://www.slideshare.net/YukihikoSawanobori/jawsdays-infra