Infrastructure as Codeとは｜ビジネスサイドのための IT 用語集

 Infrastructure as CodeとはIaC（Infrastructure as Code）は、インフラの構成を機械が解釈できる形式の設定ファイルに記述し、構築用のツールがその記述に従って環境を構築・変更する進め方です。対象はサーバー、ネットワーク、データベース、アクセス権限などです。たとえばHashiCorp社が提供する構築ツールTerraform用のファイルに、どの性能のサーバーを何台用意し、どの通信を許可するかを記述し、変更の履歴とともに保管します。
クラウドの管理画面から手作業で設定する方法や、手順書を参照して人が操作する方法に対し、IaCは設定ファイル自体をツールが解釈して実行する点が異なります。手順書は更新されなければ実態と乖離しますが、Terraformなどのツールはファイルに記述した設定と実環境の差を検出できます。
建築の比喩では職人の記憶に依存して増改築を反復した家と、図面から同じ家を何棟でも建築できる状態との相違に近いです。
同じ構成を反復して構築するには、必要な権限と入力する値を確認し、構築ツールと関連するプログラムの版を管理して再現性を確保します。また、利用するクラウドのサービスが継続して提供されていることが前提です。
Terraformで版を管理する対象は次の3種類です。
Terraform本体のプログラム
クラウドごとの操作を担う追加のプログラムであるプロバイダー
複数の構成で共通して使用する設定の集合であるモジュール
 なぜ必要かクラウドの環境は管理画面から手作業でも構築できます。記録と引き継ぎが不足していると、担当者の退職や異動の後に、どの設定が何のためにあるのかを確認できない場合があります。本番と同じ構成の検証環境の用意、障害で消失した環境の再構築、担当者や管理部門の交代のいずれでも、最初の作業が構成の調査になります。
スクリプトと手作業を併用する従来の構築では、作成者と実行者が異なることも多く、スクリプトや手順書が十分に更新されない場合、新規の環境を一貫して再現することが困難です。IaCはこの状態への対策です。構成の記録を担当者の記憶や手順書から設定ファイルへ移管し、設定ファイルを構成の基準にします。
 効果本番と同じ設定ファイルから検証環境を用意でき、本番で初めて判明する設定の差が減少する
設定ファイルを版管理し変更者を記録する運用にすれば、いつ誰が何を変更したかを障害調査や監査で追跡できる
変更の内容を適用前に第三者が確認でき、設定の誤りによる停止や情報漏えいを防止しやすくなる
担当者や管理部門が交代する際に、構成の説明を設定ファイルの形で継承できる
障害や誤削除でサーバーやネットワークが消失しても、設定ファイルから構成を再構築できる。業務データは別のバックアップから復元する
IaCの利点には同じ構成の環境を反復して構築できることと、変更の監査や切り戻しができることも含まれます。
 コストとリスク設定ファイルの整備とツールの習得に初期の工数がかかる。既存の環境を後から移行する場合はさらに増加する
設定ファイルを読み書きできる担当者が必要になる。担当者が1人だけだとその人の不在時に誰も構成を変更できない状態になる
小規模な設定変更でもファイルの修正、変更内容の確認、適用という手順が毎回必要になる。急ぎの対応では管理画面から直接変更される傾向がある
管理画面で直接変更すると設定ファイルと実環境が乖離する。乖離を放置したまま適用すると意図しない削除や再作成が起こりうる
Terraformは管理対象と実環境の対応を状態ファイルという別のファイルに記録して追跡する。この状態ファイルにはパスワードなどの秘密情報が平文で含まれることがあり、含まれる場合は保管場所の暗号化と閲覧者の制限が推奨されている
1回の適用で多数の設定を変更できるため、確認が不十分だった場合の影響範囲も広範になる
構築ツールの提供元が利用条件を変更する場合がある。利用条件の変更による構成管理の継続や費用への影響を事前に確認する
 どのようなシステムならIaCで構成を管理すべきか次のいずれかに該当するなら、構成を設定ファイルで管理するほうが安全です。
本番環境と検証環境のように環境が複数ある
構成の変更が継続的に発生する
担当者の交代や、障害時の再構築がありうる
構成が設定ファイルにあるかどうかで、担当者の交代や引き継ぎにかかる工数が大幅に変化します。
設定ファイルで管理する場合は、設定ファイル以外に次の項目も記録して管理します。
各環境の設定ファイル一式と、適用の手順、必要な権限、ツールの版
状態ファイルの保管場所と、そのアクセス権を保有する担当者
状態ファイルに秘密情報が含まれるか、含まれる場合の暗号化と閲覧者の制限
設定ファイルで管理していない手作業の設定の一覧
設定ファイルの有効性を確認するには、設定ファイルから検証環境を新規に構築し、さらに本番環境との差分と、設定ファイルで管理していない設定を一覧で確認します。新規の構築に成功しただけでは本番と一致している証明になりません。
 手作業で構築された環境を引き継いだら構成の管理をIaCへ移行すべきか全体を一括で移行せず、変更の多い部分と再構築の可能性が高い部分から段階的に移行するのが現実的です。全体の移行では設定の対象を1つずつ実環境と比較して確認する作業が必要になり、その間も通常の変更は継続します。
既存の環境から設定ファイルを生成する機能は、Terraformと、AWS（Amazon Web Services）の構築ツールであるAWS CloudFormationの両方にあります。生成されたファイルは名前の付け方、重複、不要な設定を確認し、保守できる形に整理します。
工数の見積もりには設定の対象の数だけでなく、対象同士の依存関係、手作業の変更の量、ツールが対応する範囲を調査する必要があります。
移行を開始する前に、管理画面からの直接変更を原則禁止する運用を決定します。禁止しないまま移行すると移行した部分から順に実環境との乖離が生じます。
廃止や全面的な再構築が近いシステムでは全面移行の優先度は低下しますが、廃止までの期間も障害時の復旧手順と保守の担当者は確保します。
 IaCを採用しなくてもよいシステム次のようなシステムや環境では、IaCを採用しなくても大きな支障はありません。
一度きりの検証で、同じ環境を再び構築する予定も監査の必要もない環境
業務アプリをインターネット経由で利用するサービスの設定だけで完結し、自社で管理するインフラがほとんどないシステム
環境が1つで構成の変更がほとんどなく、担当者の交代や再構築も想定しておらず、変更の記録を資料で管理できている小規模なシステム
 よくある誤解 IaCで管理していれば環境の構成はいつでも再現できる設定ファイルの外で行った変更は再現されません。管理画面での直接変更、適用の途中に手作業で実施する修正、ファイルに含めていない外部サービスの設定が混在していると、ファイルから構築した環境は本番と一致しません。変更のたびと一定の間隔で、実環境との差分をツールで確認します。それとは別に、設定ファイルから環境を実際に構築できるかを、復旧の訓練として定期的に検証します。