インフラのコード化（IaC）とは。手作業の構築をやめる理由

インフラのコード化（IaC：Infrastructure as Code）とは、クラウドのサーバー・ネットワーク・データベースなどの構成をファイルに書き、そのファイルから環境を作る方法です。手作業で画面を操作して構築するやり方をやめる理由は、構成の記録が残り、同じ環境を何度でも同じように作り直せるようになるためです。

インフラのコード化は、開発と運用を近づけるDevOpsの考え方とあわせて広まりました。この記事では、クラウドの構築と運用を担当する方や、委託先にどう頼むかを考える方に向けて、考え方と始め方を説明します。

手作業の構築で起きやすいこと

クラウドの管理画面は、操作すればすぐに資源ができるため、最初は手作業で構築されることが少なくありません。ただ、環境が大きくなり、担当者が入れ替わると、次のような問題が出てきます。

• どの設定を、いつ、誰が、なぜ変えたのかが分からない
• 本番の環境と検証の環境で、設定が少しずつ違ってしまう
• 障害や設定の誤りで環境を作り直すとき、元の設定を思い出せない
• 構成図や手順書が、実際の環境と合わなくなる

クラウドで起きる事故には、設定の誤りが原因になるものがあります。設定の誤りを防ぐ考え方は、クラウドの設定ミスによる情報漏えいと、防ぎ方にまとめていますが、手作業の構築を続ける限り、誤りに気づく手がかりそのものが残りにくくなります。

IaC で何が変わるか

IaC では、構成を書いたファイルが、環境の「正しい姿」になります。

AWS の CloudFormation の説明では、必要な資源をすべて書いたテンプレートを作ると、CloudFormation が資源の用意と設定を担う、とされています。テンプレートはテキストのファイルなので、開発者がソースコードの版を管理するのと同じように、テンプレートの差分を追えば、インフラの変更を追えます。変更を戻したいときは、前の版のテンプレートを使えます。テンプレートから作った資源のまとまり（スタック）は、まとめて消すこともできます。

出典：What is AWS CloudFormation?（AWS）

この性質から、IaC には次の利点があります。

構成を書いたファイルは、構成図と運用の記録を「生きた資料」にするための土台にもなります。

各クラウドの仕組み

3つのクラウドは、それぞれ IaC の仕組みを提供しています。

AWS：CloudFormation

上で説明したとおり、テンプレートに資源を書き、スタックとして作ります。

Azure：Bicep

Bicep は、Azure の資源を書くための言語で、作りたいインフラを Bicep のファイルに書き、開発のあいだ同じファイルを使って何度でも同じインフラを作れる、と Microsoft は説明しています。同じファイルを何度当てても同じ状態になる作りで、すでに書いたとおりの状態なら変更は起きません。当てる前に「what-if」という操作で、作る・変える・消す資源と、変わる設定を確かめられます。状態は Azure が保存するため、別に状態のファイルを管理する必要はない、とされています。

出典：What is Bicep?（Microsoft Learn）

Google Cloud：Infrastructure Manager

Infrastructure Manager は、Google Cloud の資源の作成と管理を自動にする管理型のサービスで、Terraform（HashiCorp の IaC の道具）の構成ファイルを、Google Cloud の中で実行します。構成ファイルはインフラの最終的な姿を書くもので、実行ごとのログ、使った構成、作った資源、状態のファイルが残ります。変更を当てる前に、どう変わるかを見るプレビューも作れます。

出典：Infrastructure Manager overview（Google Cloud）

Terraform は、AWS・Azure・Google Cloud のいずれにも使えるため、複数のクラウドを使う会社や、一つの書き方にそろえたい会社が選ぶことがあります。どの道具を選ぶかは、運用する人が慣れているか、ほかのシステムとそろえるかで決めます。

手で変えた設定は「ドリフト」になる

IaC を始めても、画面から手で設定を変えると、ファイルと実際の環境が食い違います。この食い違いを、ドリフトと呼びます。

AWS は、CloudFormation で作ったサーバーを EC2 の画面から直接変えるなど、CloudFormation の外での変更が起きうること、そうした変更はスタックの更新や削除を難しくすることを説明しています。CloudFormation のドリフトの検出は、テンプレートとパラメーターから期待される値と、いまの資源の値を比べ、違えばドリフトと判定します。資源が消されている場合も含みます。ただし、テンプレートやパラメーターで明示した値だけが比べる対象で、既定の値は対象外です。

出典：Detect unmanaged configuration changes to stacks and resources with drift detection（AWS）

ドリフトを防ぐには、道具だけでなく運用の決まりが要ります。

1. 本番の環境の変更は、コードの変更を通して行う
2. 障害の対応などで手で変えた場合は、あとでコードに戻す
3. ドリフトを定期的に確かめ、見つかったら原因を記録する
4. 画面から変更できる権限を、必要な人に絞る

4つ目の権限の絞り方は、最小権限の原則にもとづきます。

どこから始めるか

すでに手作業で作った環境がある場合、すべてを一度にコードへ書き直す必要はありません。

1. これから作る環境（新しい検証の環境など）から、コードで作る
2. 変更の多い部分（ネットワークの許可の設定、サーバーの台数など）をコードに移す
3. コードの変更を、ほかの人が確かめてから当てる流れを作る
4. 残りの部分を、変更の機会にあわせて少しずつ移す

委託先に構築を頼む場合は、成果物として「構成を書いたファイル」を受け取れるかを、契約の前に確かめておくと、後で別の会社に運用を引き継ぐときにも役立ちます。引き継ぎの考え方は、開発会社を替えるときの引き継ぎと、そろえておく資料で説明しています。

当社のご支援

当社がクラウドの環境を構築する場合は、構成を書いたファイルとして残し、お客様の手元にも記録が残る形をご提案しています。手作業で作られた環境のコード化や、ドリフトの確かめ方を含む運用の決まりづくりは、クラウドの構築と運用管理でお手伝いしています。いまの環境の状態を整理したい場合は、クラウドの自己診断（無料）もお使いいただけます。