技術解説
デジタルトランスフォーメーション（DX）の実現に欠かせない「Infrastructure as Code（IaC）」
2022年1月25日
「Infrastructure as Code（IaC）」とは、サーバーやネットワークをはじめとしたインフラの構成をプログラムのようにコード化し、その構築や管理を自動化する手法のことです。
「デジタルトランスフォーメーション（DX）」を推進していく上では、変化の激しいビジネス環境に対応できる開発体制が欠かせません。そして、これはソフトウェアだけに限定した話ではなく、インフラにも柔軟かつ迅速な提供が要求されるようになっています。こうした事情から、近年「Infrastructure as Code（以下IaC）」の必要性が高まってきているのです。
本記事では、IaCのメリットや導入のポイントを解説します。
Infrastructure as Code（IaC）とは
冒頭でも述べた通り、IaCとはネットワークの構成やサーバーの設定など、インフラを構成する要素をコード化し、その構築や管理を専用のソフトウェアによって自動化する手法です。
例えば、サーバーを構築する場合を考えてみましょう。サーバーを構築して運用を始めるまでには、ネットワークの設定・ミドルウェアのインストール・ユーザーアカウントの作成など、さまざまな作業が必要です。従来、こうした作業は構築手順書をもとに人間が手作業で行っていました。しかし、手作業では「手順が複雑で作業に時間がかかる」「人的な作業ミスが発生してしまう」「手順書が更新されておらず、実環境との間に差異ができてしまう」といった問題が避けられません。特に大規模なシステムでは、インフラの構成も複雑化するため、人間による手作業ではいずれ限界がやってきます。
そこで、人間による手作業をやめ、構成管理ツールによってコード化されたインフラを自動的に構築し、インフラがあるべき状態を維持するのがIaCです。IaCでは、コード化された設定を構成管理ツールが実行するため、同じ作業をミスなく何度でも再現できるのです。また、作業はツールが行うため、インフラの構築作業そのものを自動化することも可能です。
IaCのメリット
IaCを導入することによって、以下に挙げるようなメリットが得られます。
インフラ構築における工数の削減
IaCでは、構築をはじめとしたインフラの管理の自動化が可能となるため、工数を削減できます。また、インフラを構成するコード自体をバージョン管理すれば、変更履歴を明確にしたり、過去に実施した作業の確認や再現も可能です。
IaCでは、同じ環境を何度でも再現できるため、例えばCIを行う際に「テストが行われるクリーンな環境をテストごとに作成する」ようなことも手間をかけずに実現できます。また、同じコードからは同じ環境が作られるため、「開発環境では動くが本番ではなぜか動かない」といった環境の違いに起因する問題を回避することもできます。
コードの再利用による効率化
インフラを構成するコードは、適切な粒度で分割することで、効率よく再利用が可能となります。ネットワークの構成やベースとなるサーバーの設定などは、多くの環境に共通した「よくある構成」が存在します。こうした汎用的な環境を構築するコードは別のシステムでも再利用できるため、新規環境を構築する際にゼロからコードを書く必要はありません。つまり、動作実績のあるコードを流用することで、効率よくインフラを構築できるのです。
自動化による人的ミスの削減
IaCでは、これまで人間が手作業で行っていた作業をツールに任せられるため、人的なミスが発生する余地がありません。一般的に対象のシステムの規模が大きくなればなるほど、その構築・管理手順は複雑化します。つまり、人間が作業すればミスが起こる可能性も高まるということです。しかし、IaCであれば、システムの規模がいくら大きくなってもこうした問題は起こりません。IaCの導入は、単に作業者の手間を減らすだけでなく、システムの品質向上にも繋がるのです。
アジャイル開発やDevOpsの導入も効率化できる
繰り返しになりますが、アジャイル開発やDevOpsといった開発を高速化する手法を導入する上では、ソフトウェア開発と同時にインフラ構築の効率化も求められます。
その点、コードとソフトウェアによってインフラを制御するIaCは、DevOpsに必須と言えるGitなどのバージョン管理システムやCI/CDとも非常に相性がよい手法です。具体的な例を挙げると、IaCのコードをGitにコミットしたら、CI/CDがコードを実行し、サーバーの設定を自動的に変更するといった応用が考えられます。このような効率化もプロジェクト全体の工数削減や品質向上に繋がります。
IaC導入時に注意するポイント
メリットの大きいIaCですが、導入時にあたっては注意点も存在します。IaCは、インフラ構築や管理の効率化に有効であると説明しましたが、以下に挙げるような問題により、導入初期はむしろ工数が増大した・効率が下がったと感じることもあるかもしれません。
導入にかかる様々なコスト
IaCを実現する構成管理ツールには、複数の種類が存在します。ツールごとに設定の書き方やコマンドの実行の仕方はもちろん、ツールの発想そのものが異なるものもあります（宣言型と命令型、後述）。そのため、ツールの導入にあたっては、それぞれのツールの特長を理解した上でどのツールが要件に適しているのかを判断・選択しなくてはなりません。また、その上で選択したツールの記述方法やセオリーを学び、身に付ける必要があります。新しいツールに習熟しなければならないことは、インフラ担当者の負担となるかもしれません。
また、IaCによって管理されていない既存のシステムをIaCの管理下に置く場合は、既存のインフラ構築の手順書の内容をコード化する作業が発生します。この場合、コード化の手間に加えて、既存のインフラが正しくコードに置き換えられたかどうか（そのコードで本当に今のシステムと同じものが作れるか）のテストも必要となるでしょう。
IaCという仕組みそのものに慣れてツールに習熟することや既存システムの管理をIaC化することは、決して一朝一夕にはいきません。これは、IaCだけに限った話ではありませんが、新しい手法の導入には時間や手間といった決して少なくないコストがかかることを想定しておきましょう。
手作業よりも増大する作業量
IaCでは、仮に些細な変更であっても、それらをすべてコードとして表現しなければなりません。当然、書いたコードが意図通り動作するかのテストもあわせて必要となります。これは、つまり手作業ならば一瞬で終わる作業のためにコード化とテストの工数を取られてしまうことを意味します。特にツールに習熟していない導入初期においては、もどかしい・面倒と感じることも多いでしょう。また、繰り返し行う作業ならばともかく、一度実行したら二度と繰り返さないような作業の場合、単純に費用対効果で考えるとコード化にかかるコストが自動化による効率化に見合わない結果になり、投資したコストを回収できない可能性もあります。
しかし、インフラを再現するための情報がコードという形で保存されている事は、品質面においては大きなメリットとなります。短期的なコストや効率だけを見ると、IaCはそれほど魅力的ではないかもしれません。しかし、それだけで判断せずにIaCの実施はインフラの品質向上にも貢献しているという点を意識しましょう。
IaCを実現する構成管理ツールについて
インフラを構成するためのコードの書き方は、構成管理ツールごとに異なります。また構成管理ツールは、そのアプローチから大きく「命令型」と「宣言型」に分けられます。どちらも「システムをあるべき状態にする」ことを目的としている点では同じですが、そのための方法が異なるのです。
命令型とは、「システムがあるべき状態に到達するために必要な手続き」をコードとして記述する方式です。シェルスクリプトのようにコマンドを順次実行していく方式をイメージすると理解しやすいでしょう。
宣言型とは、「システムがあるべき状態」そのものを記述する方式です。「あるべき状態」を宣言さえすれば、そこへ到達するために必要な手続きやどう実現するかはツール側が決定してくれるのが特長です。
例として、「サーバーが3台欲しい」という場合を考えてみましょう。命令型のアプローチをするツールであれば「現在のインスタンス数を調べて、不足していたら不足分を起動し、過剰であれば3台になるまで削減する」というコードを書く必要があります。これに対して、宣言型のアプローチをするツールであれば「サーバーは3台起動していること」とさえ宣言すれば、追加や削除の必要性やサーバーを操作する具体的なコマンドはツールが判断し、実行してくれます。
なお、現在では宣言型のツールが主流となっています。宣言型のツールでは、設定の変更手順はツールが判断してくれるため、人間がインフラの現状を詳細に把握しなくてもよいというメリットがあります。
以下で代表的な構成管理ツールを簡単に紹介します。
Ansible
Ansibleは、米レッドハット社が開発するオープンソースの構成管理ツールです。Ansibleは、手続き型の構成管理ツールであり、Playbook（プレイブック）と呼ばれる設定ファイルに記述された手続きを順次実行していくという作りになっています。プレイブックは、YAMLという簡易なデータ記述言語で定義します。YAMLを採用しているため、プログラミングの知識や技能が無くても設定ファイルの作成・編集がしやすいのが特長です。
Chef
Chefは、米プログレス社が開発するオープンソースの構成管理ツールです。Chefは、宣言型の構成管理ツールであり、レシピやクックブックと呼ばれる設定ファイルに基づいて、自動的に処理を行います。宣言型のアプローチを行うため、Ansibleのプレイブックとは異なり、レシピには操作や手順ではなく、システムの個々の要素があるべき状態を定義します。
Chefの特長として、レシピをプログラミング言語「Ruby」の記法で書く点が挙げられます。Rubyでのプログラミングに慣れている人にとっては、馴染みやすいツールであると言えるでしょう。
Terraform
Terraformは、米ハシコープ社が開発するオープンソースの構成管理ツールです。TerraformもChefと同様、宣言型のアプローチを採用しています。Terraformでは、HashiCorp Configuration Language（HCL）と呼ばれる独自のドメイン特化言語（DSL）で設定を記述します（JSONも利用可能です）。
さいごに
ニフクラでは、DevOps環境を構築・提供する「ニフクラ DevOps with GitLab」を利用して、IaCを実現することが可能です。詳細については、クラウドデザインパターンの「Infrastructure as Code（IaC）パターン」をご確認ください。
加えて、各構成管理ツールからニフクラのインスタンスを構築したり、インフラストラクチャを操作したりするためのモジュールやプラグインも公開しています。Ansibleを用いた具体的な構築方法については、「Ansibleを使用してニフクラのインスタンスを構築する」で解説していますので、ご確認ください。
また、Terraformを用いた具体的な構築方法については、「ニフクラがTerraformに対応したので使ってみた【基礎編】」や「ニフクラがTerraformに対応したので使ってみた【応用編】」、「Terraformを利用してニフクラRDBのDBサーバーを作成する4つの方法」をご確認ください。さらに応用編として、「Terraform NIFCLOUD ProviderのNAS/Kubernetes Service Hatoba/サーバーセパレート機能を使ってみた」などの記事もありますので、こちらもあわせてご確認ください。
