開閉ボタン
ユーザーメニュー
ユーザーメニューコンテンツ
ログイン

  • 会員限定
  • 2020/08/04

Infrastructure as Code(IaC)とは何か?ツールは何を使う?どう構築すべき?

DX(デジタルトランスフォーメーション)の必要性が叫ばれる中、日本企業はITシステムはどうあるべきかを抜本的に考える局面を迎えている。ここでは、日々変化の激しいビジネス環境に、柔軟かつ迅速に対応できるシステムインフラを実現する「Infrastructure as Code(IaC:アイエーシー、コードとしてのインフラストラクチャ)」について、基礎的な概念とともに、どんなメリットがあるのか、またTerraform、Ansible、Serverspecなどによる具体的な構築方法を含めて解説していこう。

BFT デジタルイノベーション部 部長代理 呉 珍喆

BFT デジタルイノベーション部 部長代理 呉 珍喆

韓国生まれの韓国育ち、就職で来日し、小規模貿易会社の情報システムを担当したのち、システムインフラに強みを持つBFTに入社。データベースを中心にメガバンクを含む多くのエンタープライズシステム構築プロジェクトに従事したあとは、システムインフラ全体のプロジェクトリーダとしてさまざまな業種のシステム構築を支援。近年は企業システムのデジタル化に向けたアドバイスや提案支援を実施しつつ、Webメディアを中心に執筆活動にも力を入れている。

BFT
東京、名古屋にてシステムインフラの強みを活かした基盤構築自動化サービスやIT技術の教育サービスなどを展開している。
https://www.bfts.co.jp/biz

画像
IaCとは何か?構築・設定・試験・Code管理では何が用いられるのかを具体的に解説する


Infrastructure as Codeとは何か?

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

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

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

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

画像
銀行機能の変化

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

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

画像
システムインフラの変化

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


クラウドとInfrastructure as Codeの関係

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

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

画像
リソースプールの確保

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

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

画像
イニシャルコストの推移。カットオーバー(N)までに大きな山がそびえる

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

画像
1度導入してしまえば、そのあとは大きなメリットを享受できる

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

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

画像
カットオーバー(N)の後もコスト削減効果が見込める

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

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

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

開発総論 ジャンルのトピックス

開発総論 ジャンルのIT導入支援情報

PR

ビジネス+IT 会員登録で、会員限定コンテンツやメルマガを購読可能、スペシャルセミナーにもご招待!