コラム

こんにちは、クラウドCoEの西村です。
クラウドCoEを立ち上げてから早二年が経ちました。日々多くのサービスに触れ、技術力を向上させています。
私がこれまでに支援した全てのプロジェクトでAWS CloudFormationを活用しており、知見も溜まってきましたので、Infrastructure as Codeについて簡単に紹介させていただきます。

ということで、今回のBTC Tech Blogの内容は「Infrastructure as Codeを理解する」です。
Infrastructure as Code（以下、IaCと略します。）は、「OSやミドルウェアなどのインフラをコードとして管理する」ことを指し、数年前から注目され始めた手法です。

弊社技術ブログの大きなテーマは「DevOps」であり、この概念は短期間でデプロイサイクルをまわしていくために非常に重要になるものです。ビジネスが加速している昨今では、各システムがビジネスの成長に対して置いてけぼりにならないために短期間でのシステム構築・リリースや、短期間でのアプリケーションのデプロイが必要となっています。
短期間でのアプリケーションのデプロイについては別の記事でCI/CDとしてまとめる予定です。短期間でのシステム構築・リリースを可能にする手法がIaCであり、上手く活用すればインフラ構築・運用の自動化を進めていくことができます。

本記事ではIaCの全体像と、活用することによるメリット・デメリット、AWSでIaCを実現するためのサービスであるAWS CloudFormationについてまとめていきたいと思います。

IaCの概要

インフラのコード化

インフラをコード化するとはどういうことでしょうか。サーバを例にとって簡単に説明します。

かつて物理サーバというものがありました。（※今もあります。）物理サーバを利用する場合、LBやアプリケーション、DBを構築するために、まずサーバの調達から始める必要があります。調達には数か月かかり、実際のシステム構築までに時間がかかりすぎてしまうため、ビジネスのスピードについていけません。また、設定にも高度な技術力が必要です。
そこで、AWSをはじめとしたクラウドを利用することにします。IaaSからSaaSまで多種多様なサービスが提供され、マネジメントコンソールからこれらのサービスを利用することにより、システム構築にかかる時間を大幅に削減できます。物理サーバは仮想サーバに置き換わり、スペックや台数、はたまたアーキテクチャの変更など柔軟に対応できるようになりました。

めでたしめでたし。。。とはいきません。

クラウドを導入した場合でも、開発現場での悩みはまだまだあります。実際のシステム構築では、用途に応じて環境を複数用意することが多々あります。環境ごとにマネジメントコンソールから全く同じ設定でインフラを構築するには、高度な技術力と注意力が必要です。具体的には、システム構成設計書にアーキテクチャや設定パラメータの詳細を定義し、インフラに反映させます。
しかし、この管理方法では、パラメータの設定ミスやインフラ更新時の設計書への反映漏れなどのヒューマンエラーが発生し得ます。
この負担を軽減する解決策が「インフラをコード化して管理」することです。これにより、一度定義してしまえばミスなく簡単に一発でインフラを構築することが可能になります。

また、インフラをコードにより管理するときの前提となる重要な要素は「冪等性」を備えていることです。冪等性とは、ITインフラがどのような状態であっても、インフラ構築・運用のコードを実行したときは、常に同じシステム構成や運用になることを指します。

IaCの導入メリット

インフラをコード化することによって、どのようなメリットが得られるでしょうか。例えば以下のようなものが挙げられます。

• インフラのバージョン管理が可能
• インフラコードの共有・再利用が可能
• インフラ構築前にコードを事前検証可能

インフラコードの再利用により、一度作成したインフラを簡単に再現できます。また、誰かが作成したコードを利用することの可能となります。さらに、事前検証によって構成や設定パラメータの誤りを減らしたり、バージョン管理によって作成したことのある構成に巻き戻したりといったことも可能です。
最も効果を発揮するのは、同じ構成を複数面用意する必要がある場合で、全く同じ構成・設定の環境を手動で構築していくことは相当手間がかかります。
コード化することで前述のように様々なメリットが得られ、共同開発もスムーズに進められるようになります。では、IaCの導入はメリットしかないのでしょうか？
どうやらそうでもないようです。

IaCの導入にはデメリットもある？

この章では、インフラをコード化して管理することによるデメリットについて説明します。

ひしひしと感じるIaCの扱いづらさ

全パターンのインフラがコード化され、組織内でのコードの扱い方が定まっており、定義の内容も最適化されていればデメリットはほとんど感じないでしょう。それまでは以下のような扱いづらさを感じると思います。

• 初めて構築するインフラのコード作成には時間がかかる
• 簡単な設定変更に対しては適用にむしろ時間がかかる
• インフラをコード化するにあたって学習コストがかかる

IaCを導入することでインフラ構築にかかる時間を短縮できます！ということを、プロジェクトの中でお客様に説明することがあるかと思います。しかし、実際にはマネジメントコンソールから構築していくよりはるかに時間がかかります。確かに、作成済みのコードの再利用を上手に行い、設計書の類をコードに置き換えることで多少の工数削減にはなりますが、それらが難しい場合は余計に時間がかかってしまうのです。また、簡単な設定変更に対してはマネジメントコンソールから行った方が速いケースが多々あります。
さらに、コード化する際の定義方法や、インフラを展開するツールの扱い方など、学習コストもかかってきます。
コードがある程度整備され、エンジニアが定義方法を熟知し、社内での運用方法が確執してしまえば時間短縮になりますが、ほとんどの場合はそうはなりません。

IaC導入の目的を振り返る

では、結局IaCが導入した方が良いのか、しない方が良いのかという結論に入ります。

IaC導入の目的は、「IaCを活用することでエンジニアの労働生産性を向上し、より高次の作業に時間を割けるようにすること」です。

確かに体制が整うまでは工数が余計にかかってしまうかもしれません。しかし、エンジニアが安心して工事の作業を行うためには、インフラに欠陥があってはいけません。構成を何度も追加・変更するたびに不具合が発生する可能性は高まっていきます。アプリケーション開発におけるテストコードの作成と同じで、時間はかかってもセキュアな構成を維持するためには、やはりIaCは有効だと考えています。

さいごに

これまでInfrastructure as Codeの考え方について説明してきました。

実際のプロジェクトでは、インフラをコード化することに適したアーキテクチャかどうかを判断し、最適な方法で導入していってもらいたいです。

では、また次の記事でお会いしましょう。