# Infrastructure as Codeとは

サーバーやネットワークなどのインフラの構成を設定ファイルに記述し、その記述をもとに構築ツールが環境を構築・変更する進め方です。同じ構成を反復して構築でき、設定ファイルの版管理を併用すると、引き継ぎや監査の際に変更の履歴を追跡できます。

## Infrastructure as Codeとは

IaC（Infrastructure as Code）は、インフラの構成を機械が解釈できる形式の設定ファイルに記述し、構築用のツールがその記述に従って環境を構築・変更する進め方です。対象はサーバー、ネットワーク、データベース、アクセス権限などです。たとえばHashiCorp社が提供する構築ツールTerraform用のファイルに、どの性能のサーバーを何台用意し、どの通信を許可するかを記述し、変更の履歴とともに保管します。

クラウドの管理画面から手作業で設定する方法や、手順書を参照して人が操作する方法に対し、IaCは設定ファイル自体をツールが解釈して実行する点が異なります。手順書は更新されなければ実態と乖離しますが、Terraformなどのツールはファイルに記述した設定と実環境の差を検出できます。

![手順書は人が参照して実環境を操作するだけだが、設定ファイルはTerraformなどの構築ツールが解釈して実環境に適用し、実環境との差も検出できることを示す図](https://media.marketing.kdotdev-tunnel.org/glossary-infrastructure-as-code-ab530ca1ca8be603aa16587bcc0e20efb6ff1a591ea4098e7d4fd1f062f9f335.png)

建築の比喩では職人の記憶に依存して増改築を反復した家と、図面から同じ家を何棟でも建築できる状態との相違に近いです。

同じ構成を反復して構築するには、必要な権限と入力する値を確認し、構築ツールと関連するプログラムの版を管理して再現性を確保します。また、利用するクラウドのサービスが継続して提供されていることが前提です。

Terraformで[版を管理する対象](https://developer.hashicorp.com/terraform/language/expressions/version-constraints)は次の3種類です。

- Terraform本体のプログラム
- クラウドごとの操作を担う追加のプログラムであるプロバイダー
- 複数の構成で共通して使用する設定の集合であるモジュール

## なぜ必要か

クラウドの環境は管理画面から手作業でも構築できます。記録と引き継ぎが不足していると、担当者の退職や異動の後に、どの設定が何のためにあるのかを確認できない場合があります。本番と同じ構成の検証環境の用意、障害で消失した環境の再構築、担当者や管理部門の交代のいずれでも、最初の作業が構成の調査になります。

![記録のない手作業の環境では引き継ぎや再構築の作業が構成の調査から開始し、設定ファイルがある環境ではファイルの確認から開始できることを示す対比](https://media.marketing.kdotdev-tunnel.org/glossary-infrastructure-as-code-1fc6336528e14ab0b067ac938177dd6a2ce99f7468aad8b5fe95a47e501c7a0e.png)

スクリプトと手作業を併用する従来の構築では、作成者と実行者が異なることも多く、スクリプトや手順書が十分に更新されない場合、[新規の環境を一貫して再現することが困難です](https://docs.aws.amazon.com/whitepapers/latest/introduction-devops-aws/infrastructure-as-code.html)。IaCはこの状態への対策です。構成の記録を担当者の記憶や手順書から設定ファイルへ移管し、設定ファイルを構成の基準にします。

## 効果

- 本番と同じ設定ファイルから検証環境を用意でき、本番で初めて判明する設定の差が減少する
- 設定ファイルを版管理し変更者を記録する運用にすれば、いつ誰が何を変更したかを障害調査や監査で追跡できる
- 変更の内容を適用前に第三者が確認でき、設定の誤りによる停止や情報漏えいを防止しやすくなる
- 担当者や管理部門が交代する際に、構成の説明を設定ファイルの形で継承できる
- 障害や誤削除でサーバーやネットワークが消失しても、設定ファイルから構成を再構築できる。業務データは別のバックアップから復元する

[IaCの利点](https://docs.cloud.google.com/docs/terraform/iac-overview)には同じ構成の環境を反復して構築できることと、変更の監査や切り戻しができることも含まれます。

![1つの設定ファイルへの変更を適用前に第三者が確認し、同じ設定ファイルから検証環境と本番環境を構築することを示す図](https://media.marketing.kdotdev-tunnel.org/glossary-infrastructure-as-code-fcbba0ea96d1282315b39fbc5bb57ed5bfc3d0d714f56658d42ad842862bf0e9.png)

## コストとリスク

- 設定ファイルの整備とツールの習得に初期の工数がかかる。既存の環境を後から移行する場合はさらに増加する
- 設定ファイルを読み書きできる担当者が必要になる。担当者が1人だけだとその人の不在時に誰も構成を変更できない状態になる
- 小規模な設定変更でもファイルの修正、変更内容の確認、適用という手順が毎回必要になる。急ぎの対応では管理画面から直接変更される傾向がある
- 管理画面で直接変更すると設定ファイルと実環境が乖離する。乖離を放置したまま適用すると[意図しない削除や再作成が起こりうる](https://developer.hashicorp.com/terraform/tutorials/state/resource-drift)
- Terraformは管理対象と実環境の対応を状態ファイルという別のファイルに記録して追跡する。この状態ファイルにはパスワードなどの秘密情報が平文で含まれることがあり、含まれる場合は[保管場所の暗号化と閲覧者の制限が推奨されている](https://developer.hashicorp.com/terraform/language/manage-sensitive-data)
- 1回の適用で多数の設定を変更できるため、確認が不十分だった場合の影響範囲も広範になる
- 構築ツールの提供元が利用条件を変更する場合がある。利用条件の変更による構成管理の継続や費用への影響を事前に確認する

![管理画面で直接変更すると設定ファイルと実環境が乖離し、そのまま適用すると意図しない削除や再作成が起こりうることを示す連鎖](https://media.marketing.kdotdev-tunnel.org/glossary-infrastructure-as-code-4d17dc43137f22cc1c4c0dfa15cb26e7c04c34ad6dff3abeff3ba561cdf97f00.png)

## どのようなシステムならIaCで構成を管理すべきか

次のいずれかに該当するなら、構成を設定ファイルで管理するほうが安全です。

- 本番環境と検証環境のように環境が複数ある
- 構成の変更が継続的に発生する
- 担当者の交代や、障害時の再構築がありうる

構成が設定ファイルにあるかどうかで、担当者の交代や引き継ぎにかかる工数が大幅に変化します。

![環境が複数ある、構成の変更が継続する、担当者の交代や再構築がありうるのいずれかに該当すれば構成を設定ファイルで管理し、どれにも該当しなければ設定内容の資料で十分であることを示す判断の流れ](https://media.marketing.kdotdev-tunnel.org/glossary-infrastructure-as-code-157a88fdcc775d57a3c8a55d202d6f14d4e5f6bf116e2059affe1f92732bcd35.png)

設定ファイルで管理する場合は、設定ファイル以外に次の項目も記録して管理します。

- 各環境の設定ファイル一式と、適用の手順、必要な権限、ツールの版
- 状態ファイルの保管場所と、そのアクセス権を保有する担当者
- 状態ファイルに秘密情報が含まれるか、含まれる場合の暗号化と閲覧者の制限
- 設定ファイルで管理していない手作業の設定の一覧

設定ファイルの有効性を確認するには、設定ファイルから検証環境を新規に構築し、さらに本番環境との差分と、設定ファイルで管理していない設定を一覧で確認します。新規の構築に成功しただけでは本番と一致している証明になりません。

## 手作業で構築された環境を引き継いだら構成の管理をIaCへ移行すべきか

全体を一括で移行せず、変更の多い部分と再構築の可能性が高い部分から段階的に移行するのが現実的です。全体の移行では設定の対象を1つずつ実環境と比較して確認する作業が必要になり、その間も通常の変更は継続します。

既存の環境から設定ファイルを生成する機能は、[Terraform](https://developer.hashicorp.com/terraform/language/import)と、AWS（Amazon Web Services）の構築ツールである[AWS CloudFormation](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/generate-IaC.html)の両方にあります。生成されたファイルは名前の付け方、重複、不要な設定を確認し、保守できる形に整理します。

工数の見積もりには設定の対象の数だけでなく、対象同士の依存関係、手作業の変更の量、ツールが対応する範囲を調査する必要があります。

移行を開始する前に、管理画面からの直接変更を原則禁止する運用を決定します。禁止しないまま移行すると移行した部分から順に実環境との乖離が生じます。

廃止や全面的な再構築が近いシステムでは全面移行の優先度は低下しますが、廃止までの期間も障害時の復旧手順と保守の担当者は確保します。

![廃止や全面的な再構築が近くなければ直接変更を原則禁止してから、変更の多い部分と再構築の可能性が高い部分を先に移行して残りを後で移行し、近ければ復旧手順と担当者を確保する順序を示す図](https://media.marketing.kdotdev-tunnel.org/glossary-infrastructure-as-code-8b4122f61fdaf665c755897c024214aec7d5c7abf1bf5baf0c6c78229169f2a5.png)

## IaCを採用しなくてもよいシステム

次のようなシステムや環境では、IaCを採用しなくても大きな支障はありません。

- 一度きりの検証で、同じ環境を再び構築する予定も監査の必要もない環境
- 業務アプリをインターネット経由で利用するサービスの設定だけで完結し、自社で管理するインフラがほとんどないシステム
- 環境が1つで構成の変更がほとんどなく、担当者の交代や再構築も想定しておらず、変更の記録を資料で管理できている小規模なシステム

## よくある誤解

### IaCで管理していれば環境の構成はいつでも再現できる

設定ファイルの外で行った変更は再現されません。管理画面での直接変更、適用の途中に手作業で実施する修正、ファイルに含めていない外部サービスの設定が混在していると、ファイルから構築した環境は本番と一致しません。変更のたびと一定の間隔で、実環境との差分をツールで確認します。それとは別に、設定ファイルから環境を実際に構築できるかを、復旧の訓練として定期的に検証します。

![設定ファイルに記録していない直接変更、手作業の修正、外部サービスの設定は、設定ファイルから構築した環境では再現されないことを示す図](https://media.marketing.kdotdev-tunnel.org/glossary-infrastructure-as-code-d184f2a44215f82a67916bf8bc40e61944f8b47ec23d86e6c023d1229aa3f9fd.png)