ブログからの引用です。ブログはこちら
今回はアーキテクチャパターンとかリファクタリングで有名なMartin Fowler氏のブログであげられていた "InfrastructureAsCode"(原文はこちらを勝手に解釈して意訳してみましたという内容です。
さっそくいきましょう。
意訳
インフラストラクチャーアズコードというのはコンピューティングやネットワークをソフトウェアシステム同じように扱えるようにソースコードを通じて定義するアプローチである。こうしたコードは可監査性やビルドの再現可能性を実現するために管理され、テストの方法や、継続的デリバリーの実現のやり方に依存する。これはクラウドコンピューティングプラットフォームを扱う方法としてここ数十年行われてきた方法だし、これからのコンピューティングインフラストラクチャーを扱う主要な方法である。
私(Fowler氏)は、鉄器時代に育って、当時は新しいサーバーアプリケーションをリリースすることが、それを実行する物理的なハードウェアを新しく探すことを意味していて、アプリケーションに必要なものをハードウェアがサポートできるように、設定し、そのハードウェアにアプリケーションをデプロイしていた。ハードウェアがたいて高価でしかも入り組んでいたことを考えると、たいて数ヶ月かかるような話だった。でも、今私たちはクラウド時代を生きている。そこでは数秒で新しいサーバーを立てることが出来るし、インターネット接続やクレジットカードも必要ない。これこそがダイナミックインフラストラクチャーでコマンドを使ってサーバーを作って（たいてい仮想環境上だけど、実環境上にだってできる。）、プロビジョニングし、廃棄することができる。しかも物理的にその場所にいくことせずに。
Practices
インフラストラクチャーアズコードには何個か実践方法がある。
- 定義ファイルを使う: 全ての設定は実行可能な設定定義ファイル上に定義される。例えば、ShellスクリプトとかAnsibleのプレイブックとかChefのレシピとか、Puppetのマニフェストとか。時間がない時にサーバーにログインし、急いで調整する必要がある。こうしたリスクからSnowflakeサーバーが作られ、最新の定義通りにコードが動くようになるまでだけ使われる 。これはアップデートはすぐに行わなければいけないことを意味する。幸いにもコンピューターはコードをすぐに実行して、人がタイプするよりも速い速度数百のサーバーにプロビジョニングしてくれる。
- Self-documented systemsとプロセス:。 人間が手順書を見ながら実行するよりコードの方がより正確で堅実に実行できる。もし必要なら、こうしたコードから人が読むことのできるドキュメントをつくることもできる
- 全てをバージョン管理しよう: 全てのコードをソース管理下におくこと。この方法で全ての設定と全ての変更は管理するために記録され、ビルドの再現可能性を実現し、問題の分析に役に立つ。
- 継続的にシステムとプロセスをテスト: テストをすることでインフラの設定における多くの不具合を早期に発見することができる。モダンなソフトウェアシステムにおいて、インフラストラクチャーコードに対するデプロイメントパイプラインをセットアップすることができ、インフラストラクチャーの変更における継続的デリバリーを実践することができる。
- バッチなんかより小さな変更: インフラストラクチャーの変更が大きければ大きいほど、その変更には不具合を埋め込む可能性が高く、その不具合を見つけることが難しくなる。特に複数の不具合がお互いに関係し合っている場合なんかはやばい。小さな変更であれば不具合は簡単に見つけられ、簡単にやり直すことができる。インフラストラクチャーを変更する時には頻度は困難さを減らすを参照のこと
- 継続的にサービスを利用可能にする: システムはだんだんと更新や修正の余裕がなくなってくる。ブルーグリーンデプロイメントや並行変更のテクニックによって可用性を失わずに小さな変更ができる。
Benefit
こうした方法によって新しいサーバー簡単に立ち上げたり、新しい設定に変更されたりロード負荷が減った際に安全にサーバーを配置したりする動的インフラストラクチャーの利点を得ることが出来る。新しいサーバーをつくる時、必要なスクリプトを実行するだけで必要なだけサーバーのインスタンスを作ることが出来る。このアプローチはフェニックスサーバーやイミュータブルサーバーと相性がいい。
サーバーの設定の定義にコードを用いることはサーバー間の一貫性が優れていることを意味する。手動でのプロビジョニングは曖昧で(しかもミスのあるかもしれない）手順書の解釈が微妙な設定の不具合をもつスノーフレークを作ってしまう。そしてこの不具合は奇妙でトリッキーでデバッグが難しい。こうした難しさは一貫性のないモニタリングによってさらに悪い状況をもたらすが、コードを利用することでモニタリングの一貫性を守ることができる。
一番大事なことだが、設定コードを利用することは変更を安全にし、アプリケーションやシステムソフトウェアの更新をリスクの少ないものにする。不具合は素早く見つけて修正することができるし、どんなに最悪な場合でも直近の正常に動いていた設定に戻すことが出来る。
インフラストラクチャーはコンプライアンスと点検で補助しながらバージョン管理されたコードとして定義しよう。全ての設定に対する変更はログに残り、記録を保持する上でのミスの影響を受けない。
もし真剣にマイクロサービスの適用をしようとしているなら、多くのサーバーを取り扱う必要性が増えていくにつれ、こうしたインフラストラクチャーアズコードを構築することは必要不可欠な技術になる。インフラストラクチャーアズコードの技術はサーバーの大きなクラスターを管理することにおいて、サーバーを設定したり、どのように相互作用するかを特定するという点で効果的である。
Further Reading
同僚のKief Morrisがthe last year working on a bookで述べている。この本は現在製品化の最終段階でインフラストラクチャーアズコードを詳細に述べている。ここであげた実践方法は直接この本で述べられている。
Acknowledgments
（ここはそのまま引用します。）
Ananthapadmanabhan Ranganathan, Danilo Sato, Ketan Padegaonkar, Piyush Srivastava, Rafael Gomes, Ranjan D Sakalley, Sina Jahangirizadeh, and Srivatsa Katta discussed drafts of this post on our internal mailing list
感想
このインフラストラクチャーアズコードは最近のインフラ運用を考える上でもう欠かせないというか知らなくてはならない概念だなと思います。もうね。インフラの環境構築で1ヶ月かけるなんてやってられないわけで。しかもインフラだって新しい技術がどんどん出てきている中で、変化しないわけがない。じゃあ安全に変更しやすいようにしようというのは至極全う？な考え。
ただ実際のシステムインフラのなかではまだまだ導入できていない所が多い気がしていて、その背景には、技術の変化についていけてなかったり、概念知っていても実際にどうやって実現するか知らなかったりというのがあるのかなと。