意訳: InfrastructureAsCode

<p>ブログからの引用です。ブログは<a href="http://mohiblog.com/technology/infrastructureascode/">こちら</a> </p>

<p>今回はアーキテクチャパターンとかリファクタリングで有名なMartin Fowler氏のブログであげられていた "InfrastructureAsCode"(原文は<a href="http://martinfowler.com/bliki/InfrastructureAsCode.html">こちら</a>を勝手に解釈して意訳してみましたという内容です。</p>

<ol>
	<li><a href="#a1">意訳</a></li>
	<li><a href="#a2">感想</a></li>
</ol>
<p>さっそくいきましょう。</p>
<h4 id="a1">意訳</h4>


<p>インフラストラクチャーアズコードというのはコンピューティングやネットワークをソフトウェアシステム同じように扱えるようにソースコードを通じて定義するアプローチである。こうしたコードは可監査性や<a href="http://martinfowler.com/bliki/ReproducibleBuild.html">ビルドの再現可能性</a>を実現するために管理され、テストの方法や、<a href="http://martinfowler.com/bliki/ContinuousDelivery.html">継続的デリバリー</a>の実現のやり方に依存する。これは<a href="">クラウドコンピューティング</a>プラットフォームを扱う方法としてここ数十年行われてきた方法だし、これからのコンピューティングインフラストラクチャーを扱う主要な方法である。</p>

<img style="display:block; margin-left:auto; margin-right:auto;" src="http://mohiblog.com/wp-content/uploads/2016/03/NewImage.png" alt="NewImage" title="NewImage.png" border="0" width="380" height="171" />

<p>私(Fowler氏)は、<a href="https://www.thoughtworks.com/insights/blog/infrastructure-code-iron-age-cloud-age">鉄器時代</a>に育って、当時は新しいサーバーアプリケーションをリリースすることが、それを実行する物理的なハードウェアを新しく探すことを意味していて、アプリケーションに必要なものをハードウェアがサポートできるように、設定し、そのハードウェアにアプリケーションをデプロイしていた。ハードウェアがたいて高価でしかも入り組んでいたことを考えると、たいて数ヶ月かかるような話だった。でも、今私たちはクラウド時代を生きている。そこでは数秒で新しいサーバーを立てることが出来るし、インターネット接続やクレジットカードも必要ない。これこそが<strong>ダイナミックインフラストラクチャー</strong>でコマンドを使ってサーバーを作って（たいてい仮想環境上だけど、実環境上にだってできる。）、プロビジョニングし、廃棄することができる。しかも物理的にその場所にいくことせずに。</p>

<h5>Practices</h5>

<p>インフラストラクチャーアズコードには何個か実践方法がある。</p>

<ul>
	<li><strong>定義ファイルを使う:</strong>　全ての設定は実行可能な設定定義ファイル上に定義される。例えば、ShellスクリプトとかAnsibleのプレイブックとかChefのレシピとか、Puppetのマニフェストとか。時間がない時にサーバーにログインし、急いで調整する必要がある。こうしたリスクから<a href="http://martinfowler.com/bliki/SnowflakeServer.html">Snowflakeサーバー</a>が作られ、最新の定義通りにコードが動くようになるまでだけ使われる
。これはアップデートはすぐに行わなければいけないことを意味する。幸いにもコンピューターはコードをすぐに実行して、人がタイプするよりも速い速度数百のサーバーにプロビジョニングしてくれる。</li>
	<li><strong>Self-documented systemsとプロセス:。</strong> 人間が手順書を見ながら実行するよりコードの方がより正確で堅実に実行できる。もし必要なら、こうしたコードから人が読むことのできるドキュメントをつくることもできる</li>
	<li><strong>全てをバージョン管理しよう: </strong>全てのコードをソース管理下におくこと。この方法で全ての設定と全ての変更は管理するために記録され、<a href="http://martinfowler.com/bliki/ReproducibleBuild.html">ビルドの再現可能性</a>を実現し、問題の分析に役に立つ。</li>
	<li><strong>継続的にシステムとプロセスをテスト: </strong>テストをすることでインフラの設定における多くの不具合を早期に発見することができる。モダンなソフトウェアシステムにおいて、<a href="http://martinfowler.com/bliki/DeploymentPipeline.html">インフラストラクチャーコードに対するデプロイメントパイプライン</a>をセットアップすることができ、インフラストラクチャーの変更における<a href="http://martinfowler.com/bliki/ContinuousDelivery.html">継続的デリバリー</a>を実践することができる。</li>
	<li><strong>バッチなんかより小さな変更: </strong>インフラストラクチャーの変更が大きければ大きいほど、その変更には不具合を埋め込む可能性が高く、その不具合を見つけることが難しくなる。特に複数の不具合がお互いに関係し合っている場合なんかはやばい。小さな変更であれば不具合は簡単に見つけられ、簡単にやり直すことができる。インフラストラクチャーを変更する時には<a href="http://martinfowler.com/bliki/FrequencyReducesDifficulty.html">頻度は困難さを減らす</a>を参照のこと</li>
	<li><strong>継続的にサービスを利用可能にする: </strong>システムはだんだんと更新や修正の余裕がなくなってくる。<a href="http://martinfowler.com/bliki/BlueGreenDeployment.html">ブルーグリーンデプロイメント</a>や<a href="http://martinfowler.com/bliki/ParallelChange.html">並行変更</a>のテクニックによって可用性を失わずに小さな変更ができる。</li>
</ul>

<h5>Benefit</h5>

<p>こうした方法によって新しいサーバー簡単に立ち上げたり、新しい設定に変更されたりロード負荷が減った際に安全にサーバーを配置したりする動的インフラストラクチャーの利点を得ることが出来る。新しいサーバーをつくる時、必要なスクリプトを実行するだけで必要なだけサーバーのインスタンスを作ることが出来る。このアプローチは<a href="http://martinfowler.com/bliki/PhoenixServer.html">フェニックスサーバー</a>や<a href="http://martinfowler.com/bliki/ImmutableServer.html">イミュータブルサーバー</a>と相性がいい。</p>


<p>サーバーの設定の定義にコードを用いることはサーバー間の一貫性が優れていることを意味する。手動でのプロビジョニングは曖昧で(しかもミスのあるかもしれない）手順書の解釈が微妙な設定の不具合をもつスノーフレークを作ってしまう。そしてこの不具合は奇妙でトリッキーでデバッグが難しい。こうした難しさは一貫性のないモニタリングによってさらに悪い状況をもたらすが、コードを利用することでモニタリングの一貫性を守ることができる。</p>

<p>一番大事なことだが、設定コードを利用することは変更を安全にし、アプリケーションやシステムソフトウェアの更新をリスクの少ないものにする。不具合は素早く見つけて修正することができるし、どんなに最悪な場合でも直近の正常に動いていた設定に戻すことが出来る。</p>

<p>インフラストラクチャーはコンプライアンスと点検で補助しながらバージョン管理されたコードとして定義しよう。全ての設定に対する変更はログに残り、記録を保持する上でのミスの影響を受けない。</p>

<p>もし真剣に<a href="http://martinfowler.com/microservices/">マイクロサービス</a>の適用をしようとしているなら、多くのサーバーを取り扱う必要性が増えていくにつれ、こうしたインフラストラクチャーアズコードを構築することは必要不可欠な技術になる。インフラストラクチャーアズコードの技術はサーバーの大きなクラスターを管理することにおいて、サーバーを設定したり、どのように相互作用するかを特定するという点で効果的である。</p>

<h5>Further Reading</h5>
<p>同僚の<a href="http://kief.com/">Kief Morris</a>が<a href="http://www.amazon.com/gp/product/1491924357?ie=UTF8&tag=martinfowlerc-20&linkCode=as2&camp=1789&creative=9325&creativeASIN=1491924357">the last year working on a book</a>で述べている。この本は現在製品化の最終段階でインフラストラクチャーアズコードを詳細に述べている。ここであげた実践方法は直接この本で述べられている。</p>

<h5>Acknowledgments</h5>
<p>（ここはそのまま引用します。）</p>
<blockquote>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</blockquote>

<h4 id="a1">感想</h4>
<p>このインフラストラクチャーアズコードは最近のインフラ運用を考える上でもう欠かせないというか知らなくてはならない概念だなと思います。もうね。インフラの環境構築で1ヶ月かけるなんてやってられないわけで。しかもインフラだって新しい技術がどんどん出てきている中で、変化しないわけがない。じゃあ安全に変更しやすいようにしようというのは至極全う？な考え。<br />
ただ実際のシステムインフラのなかではまだまだ導入できていない所が多い気がしていて、その背景には、技術の変化についていけてなかったり、概念知っていても実際にどうやって実現するか知らなかったりというのがあるのかなと。</p>