開発プロセス・方法論

IaC

（いんふらすとらくちゃあずこーど／Infrastructure as Code）

一言でいうと

インフラの構成をコードで定義し、適用と変更を再現可能にする実践です。手作業で作った環境は同じ手順を踏んでも差が出る、という前提から始まります。

考え方は構成管理ツールの普及とともに広まりましたが、名前のついた実践として整理されたのは2010年代です。Martin Fowlerは2016年3月にこの語を解説し、Kief Morrisの書籍を基本文献として挙げています。

クラウドを使う組織では前提として語られることが増えました。ただし実際には、一部の環境だけがコード化されている状態も珍しくありません。

手作業で構築した環境は、同じ手順を踏んだつもりでも差が出ます。誰がいつ何を変えたかも追えません。障害のたびに構成を調べ直すことになり、環境を増やすほど負担が増えます。

構成をコードにすると、変更の履歴がバージョン管理に残り、レビューの対象になります。同じ定義から同じ環境を作れるため、検証環境と本番の差も小さくなります。

宣言的な定義ファイルで、あるべき構成を記述します。適用はツールが差分を計算して行い、人は差分を確認してから承認します。定義はアプリケーションのコードと同じくバージョン管理に置き、変更はレビューを通します。

運用に入ると、コードと実際の環境がずれる問題が出ます。手作業の変更を許すかどうかを決め、検知する仕組みを用意してください。

クラウド環境の運用が一定の規模にあることを示します。ただし、ツール名が並んでいるだけで、実際には一部の環境しかコード化されていない組織もあります。

検索条件には、この語ではなくツール名を使います。要件に書く場合も、TerraformやCloudFormationといった具体名のほうが引けます。

自社側では、本番環境のどこまでがコード化されているか、手作業の変更をどう扱っているかを確認します。ここが曖昧なまま求人票に書けば、入社後の食い違いにつながります。候補者には、コードと実環境がずれたときの対処を聞きます。検知の仕組みまで答えられる人は、運用まで担当しています。