O'Reilly『Infrastructure as Code』読了
O'Reillyの『Infrastructure as Code』を読んだ。従来Ansibleの本、Chefの本といった各ツールの使い方にフォーカスした本はいくらか出ていたけれど、おそらく「Infrastructure as Code」の考え方や、システム運用への採用方法を包括してまとめた本は初めてということになるのかな。
ツールとプロセス
端的に内容を説明してしまうと、Infrastructure as Codeで使用するツールを
- ダイナミックインフラストラクチャプラットフォーム（AWS等パブリック、プライベート問わずプログラマブルな操作が可能なインフラプラットフォーム）
- インフラストラクチャ定義ツール（Terraformのような、構築するインフラ環境を定義するツール）
- サーバー構成ツール（Ansible、Chef等のサーバー内部の設定を定義するツール）
- インフラストラクチャサービス（モニタリング、サービスディスカバリ等の環境管理用のツール）
の4つに大きく分類して、
- インフラのプロビジョニング
- サーバーテンプレートの管理
- サーバーのアップデート、更新
- サーバーの破棄
といったライフサイクルを、各ツールを使ってどう管理するかを説いた本。後半で第10章をまるごと「インフラストラクチャのためのソフトウェア工学プラクティス」の説明に充てて、継続的インテグレーションやVCSの方法論を書いていたりして、DevOpsの名のもとにソフトウェア管理に対して導入されてきた手法を、インフラへも適用していくための本になっている。なのでサーバーを構築したらそれでおしまいではなくて、ダイナミックにサーバーが生成／廃棄される環境であれば、自動的にログは退避できるようにしておく必要があるだとか、システムマネジメント全体に焦点が当てられている。
ツールの使い方自体はドキュメントを読むなり、Qiitaを探るなりすればだいたいわかるんだけど、それをどう運用すれば効率的になるのか、より効果が得られるかという、プラクティスを知りたい思いが強かったので、大いに参考になった。
徹底的な自動化アプローチ
例えばプロビジョニングは「インフラストラクチャ定義ツール」でサーバーを構築し、その内部を「サーバー構成ツール」で設定するわけだけど、2つのツールを個別に手動実行するのではなくて、前者から後者へどう情報を受け渡して、自動的にプロビジョニングを済ませるかが肝になる。
Terraformであれば、EC2を立てた後に自動的にAnsibleを呼ぶようなことも機能でできるらしいけど、そういった連携の仕組みがツール自体に存在しなければ、構築したサーバーのIPアドレスやユーザーの情報を「サーバー構成ツール」へ渡す必要がある。1例として挙がっていたのが「構成レジストリ」と呼ばれる、サーバー情報を中央集権的に管理するツール。インフラストラクチャ定義ツールは立てたサーバーの情報をここに登録し、サーバー構成ツールが情報を引き出して、サーバー設定のデプロイを行う。具体的に「構成レジストリ」として使えるツールについてはそれほど言及がなかったけど、CygamesだとElasticsearchを使ってサーバー情報を管理しているという話を聞いたことがあって、実装としてはこれに近いのだと思う。
あるいはAnsibleなどを導入したときによく聞かれるのが、結局手動でサーバー構成を変更してしまって、Playbookと実情に乖離が出てしまうという問題（本書ではこれによる構成差異の発生を「構成ドリフト」と呼んでいる）。これに対してはイミュータブルなサーバー管理をするのが最も良いとされる。なぜなら構成ドリフトを起こしても、定期的にイチから生成したサーバーに置き換えられていれば、そのたびに構成ドリフトもリセットされるから。
この本全体で貫かれているのは、とかく徹底的な自動化と、ワークフローのパイプライン化を行なって、各タスクからシステム管理者の手動オペレーションをなくすということ。これによりシステム管理者はインフラ構築、変更の「門番」としての役割から解放され、問題への対応といったより生産的なタスクへ移ることができるし、システムの変更によりサービスに対して発生する影響も低減できるとしている。
自律的なオートメーションこそ、Infrastructure as Codeが確実に機能する秘訣である。チームがセキュリティを向上させる新しいウェブサーバーの設定オプションを見つけたら、それをオートメーションツールのなかに組み込む。チームは、もう1度そのことについて考えようとしなくても、現在及び将来のすべての関連サーバーにそれが適用されることを知っている。 (p.254)
共通言語として利用したい
先述した「構成ドリフト」のように、本書ではいくつかあまり聞き慣れない用語（構成ドリフトを起こしたサーバー群を「スノーフレークサーバー」と呼んだり、イミュータブルに何度も破棄されては生成されるサーバーを「フェニックスサーバー」と呼んだり）が使われているのだけど、アンチパターンやグッドプラクティスを共有認識にする上では、名前がついているほうが話が通じやすいので、この本の用語が共通言語になっていくとうれしいなと思ったり。そういえば、プラクティスに名前を付ける手法は『Fearless Change』でも使われていた。
で、結論としてとても良い本だとは思うのだけど、これを全部導入するとなるとなかなかにパワーが必要になる。特に、すでに手動でのサーバー管理を絶賛実施中の環境に対して導入する場合には、インフラに対する考え方自体を、秘伝のタレのように継ぎ足して使うものから、外部で管理している設定と常に同期して使うもの、すぐに破棄と生成のサイクルを回せるものへと変えていかなくてはならないので、組織的な協力が必要になってくる。しかも必要なのは一部ワークフローの自動化ではなく、徹底的な自動化、インフラ環境の自律的な動作。
まぁ、とはいえインフラパイプライン全体をいきなり用意して導入するのも難しいのは確かなので、まずは頻繁に変更が入る設定など、Infrastructure as Codeの恩恵が大きそうなところから始めてみるべきかと思う。少しずつでも確実にこれは実現していきたいなと思える本だった。
オライリージャパン
売り上げランキング: 25,983