Infrastructure As Code（インフラストラクチャ・アズ・コード）

プラクティス

インフラストラクチャ・アズ・コードは、いくつかのプラクティスに基づいています。

• 定義ファイルの使用：すべての構成は、シェルスクリプト、Ansible Playbook、Chefレシピ、Puppetマニフェストなどの実行可能な構成定義ファイルで定義します。サーバーにログインしてその場で調整することは決してありません。そのような変更はスノーフレークサーバーを作成するリスクがあり、永続的な定義として機能するコードを開発する際にのみ行う必要があります。これは、コードによる更新の適用が高速でなければならないことを意味します。幸いなことに、コンピュータはコードを高速に実行できるため、人間がタイプするよりも速く、数百台ものサーバーをプロビジョニングできます。
• 自己文書化されたシステムとプロセス：人間が実行するためのドキュメントにある指示ではなく、コードはより正確で一貫して実行されます。必要に応じて、このコードから他の人間が読めるドキュメントを生成できます。
• すべてのものをバージョン管理：このコードをすべてソース管理下に置いてください。これにより、すべての構成とすべての変更が監査のために記録され、問題の診断に役立つ再現性のあるビルドを作成できます。
• システムとプロセスを継続的にテスト：テストにより、コンピュータはインフラストラクチャ構成における多くのエラーを迅速に検出できます。最新のソフトウェアシステムと同様に、インフラストラクチャコードのデプロイメントパイプラインを設定して、インフラストラクチャの変更の継続的デリバリーを実践できます。
• バッチ処理ではなく、小さな変更：インフラストラクチャの更新が大きくなるほど、エラーが含まれる可能性が高くなり、特に複数のエラーが相互作用している場合は、そのエラーを検出することが難しくなります。小さな更新は、エラーを見つけやすく、元に戻しやすくなります。インフラストラクチャを変更するときは、頻度を上げると難易度が下がります。
• サービスを継続的に利用可能に維持：システムは、アップグレードや修正のためにダウンタイムを許容できなくなっています。ブルーグリーンデプロイメントやパラレルチェンジなどの手法を使用すると、可用性を失うことなく小さな更新を実行できます。

メリット

これらすべてにより、新しいサーバーを簡単に起動し、新しい構成に置き換えられたり、負荷が減少したりしたときに安全にサーバーを廃棄することで、動的なインフラストラクチャを活用できます。新しいサーバーを作成することは、必要な数のサーバーインスタンスを作成するためのスクリプトを実行するだけです。このアプローチは、フェニックスサーバーやイミュータブルサーバーに適しています。

コードを使用してサーバー構成を定義するということは、サーバー間の整合性が高まることを意味します。手動プロビジョニングでは、不正確な指示の異なる解釈（エラーは言うまでもなく）によって、わずかに異なる構成のスノーフレークが発生し、デバッグが困難な厄介な障害につながることがよくあります。このような困難は、一貫性のない監視によって悪化することが多く、ここでもコードを使用することで、監視も一貫したものになります。

最も重要なことは、構成コードを使用することで変更がより安全になり、アプリケーションやシステムソフトウェアのアップグレードのリスクを軽減できることです。障害をより迅速に発見して修正でき、最悪の場合でも、変更を最後の正常な構成に戻すことができます。

インフラストラクチャをバージョン管理されたコードとして定義することは、コンプライアンスと監査に役立ちます。構成に対するすべての変更をログに記録でき、記録の誤りの影響を受けません。

マイクロサービスを本格的に採用する場合、インフラストラクチャ・アズ・コードは必要な機能となり、サーバーの数が増えるにつれて、これらすべての重要性は増します。インフラストラクチャ・アズ・コードの手法は、サーバーの構成と、サーバー間のやり取りの方法を指定する両方において、大規模なサーバークラスターを効果的に管理するために拡張できます。