Infrastructure as Codeとは何か？

　道路や信号などで構成される交通インフラ、発電所・送電装置などで構成される電力インフラのように、何らかのサービスやものを提供するにあたり、基盤となる物理的な「設備」＝「インフラ」が必要であることは明白だ。

　それが、コード（Code）としてのインフラと言われても、はてなマークしか浮かばないのも普通だろう。IaCとは、結論から言うと、「設備が存在しないわけではなく、抽象化されて、使う側としては意識しないもの」と言える。

　銀行を例に挙げてみよう。大昔の銀行は、預けた現物のお金をその銀行の金庫に保管し、そこから出し入れをしていた。しかし、現代の銀行は電算化されており、自身が口座を持つ金融機関に対応していれば、どんなATMでも預けることができ、それをどこのATMでも自由に引き出すことができる。

　さらにはフィンテックの台頭により、スマホ一つでさまざまなアプリから参照系処理（残高照会や履歴確認など）も更新系処理（振込／振替による資金移動、電子マネーチャージなど）も可能になっている。


　ここまでくると、もはやお金はスマホに表示された数字でしかなく、自分が預けた現物のお金がどこにあるのか知っている人も、知ろうとしている人もいないだろう。

　システムインフラでいうと、サーバやその他機器で構成される設備を個々に購入し、作り上げた物理的な構成から、仮想化技術を使った集約、そしてさらに雲の上にのせたクラウド環境と、銀行機能の発展のように使う側が設備そのものを意識する必要性が段々なくなってきた（※もちろん、ミッションクリティカルな環境下では、非機能要件として実物が存在する国や場所、それらの組み合わせなどを厳密に設計するケースも多い）。


　抽象化され、現物を意識しなくなり、目に見えない「リソース」と化したシステムインフラは、どのように構築し、制御・運用するのか？その答えの1つがIaCと言える。

クラウドとInfrastructure as Codeの関係

　抽象化されたシステムリソースを、それこそ「自由に、使いたいとき、使いたいだけ」使おうとすると、その分、大きなリソースのプールが必要となるだろう。それを自社内で用意しようとした場合、使う側は開発リソースの効率化が図れても、設備としてはそれらをカバーできる量を確保しなければならず、結果として初期コストやそれらの維持管理コストが膨らむ。

　その点で、クラウドはクラウドベンダーがそのリソースプールを確保しており、従量課金型でお金を支払うことになるので、相性が良いのは必然と言える。

Infrastructure as Codeによって得られるメリット

　システムを導入するにあたり、コストがかかるのは言うまでもない。以下のグラフを見ていただきたい。少しデフォルメしているものの、初期導入時のイニシャルコストとして、人（工数）としても物（HW/SW）としても大きな山がそびえ立つ。


　IaCは最初に導入するときにオーバーヘッドはかかるものの、一度確立すれば、設計／構築（試験）にかかる工数を削減できる。考えてみよう。システムは1つだけの環境で成り立たない。本番環境はもちろん、開発環境や試験環境も必要だ。それらをCode化し、その特徴である冪等性（何度実行しても同じ結果になる）を利用して同じような環境を次々と作ったり消したりできるとしたら？　サーバ台数や環境の数に左右されることなく、工数を削減することができるだろう。


　また、その過程はユニークなパラメータを調整したうえでCodeを実行するだけで、構築／設定／単体試験まで完結できるので、納期の短縮にも大きく寄与するだろう。

　上記のようなメリットはイニシャルコストだけに限らず、リリース後のメンテナンスや保守でも同じことが言え、ランニングコストの削減も期待できる。


　コストメリットを大きく取り上げたが、実は上記のような性質は品質向上へも大きく貢献する。どれだけ統制が取れたチームと言え、複数人で作業をする以上、人である以上、ミスは生じる。それは人間だから仕方ないわけだが、人間の手を介さずシステムが作れることはすなわち、ミスが生じるポイントも抑制できることを意味する。

　このようにIaCはコストと納期、そして品質に大きなメリットがあり、ビジネスのスピードに合わせて、すぐに作ったり壊したり、作り直したりできるので、変化を求められるビジネス環境において非常に魅力的なもので間違いないだろう。

【次ページ】Infrastructure as Codeを支えるツール