Infrastructure as Code について

こんにちは。プロアクシアコンサルティングでオープンソリューション事業部に所属しています Y.T です。
今日は、Infrastructure as Code (IaC)について紹介したいと思います。

これまでの経歴について

コンピューターに携わり始めた当初は開発を中心に担当しており、サーバーアプリケーションの開発などに従事しておりました。それ以外には、Amazon Web Service (AWS) のサーバーレスアーキテクチャーなどを利用した IoT 機器からのデータ収集や、データの見える化などの開発にも携わっておりました。

開発以外では、インフラ構築や運用など色々な業務を担当したのちに、顧客サービスのインフラ管理を担当をしていました。この業務では、顧客が構築依頼したサービスを提供していく中で、必要になってくるインフラ管理や運用管理などの作業について、顧客と担当範囲を設定して支援を実施するような作業を担当しておりました。

Infrastructure as Code (IaC) とのかかわりは、どのようなきっかですか

運用担当をしていた当時に、インシデントが発生したサービスの調査を担当したことがきっかけでした。

サービスで障害は発生した場合、問題の原因としては大きく分けてアプリケーション側の問題とインフラ側の問題が考えられます。
運用を担当していましたので、調査を実施する範囲としてはインフラ側の問題有無の確認を担当することになるのですが、その際に確認事項の一つとして実行環境の設定と導入時の環境設定で相違がないか確認する作業があります。

環境確認を実施するためには、導入時に設定された環境定義書と、実行環境から取り出したパラメータシートなどの定義を突合せる必要があるのですが、多くのサーバやアプリケーションで構成されている場合は、大量の項目を確認する必要が発生します。
このため、より効率的に環境確認を行うための方法を確認したことが、IaC を学習することになったきっかけです。

IaC について教えてください

ドキュメント(コード)を元として、システムやサービスを動かす基盤(OS やミドルウェア)を作る考え方とかサービスのことを指します。

従来、OS やミドルウェアなどのインフラ環境の構築は手作業によって設定してきましたが、大量の環境を構築する場合など、非常に手間がかかり多くのコストが発生します。
また、人手で実施することでどうしても人為的なミスが発生する場合もございました。

IaC では、インフラ構成管理ツールを利用してコードを記述することで設定作業を自動化することを行います。これにより、一度コードを作成すれば実行するだけで環境を構築することができるので、同一構成のサーバを複数台構築する際などには、ミスなく短時間で作業を実施することができます。

インフラ構成管理ツールについて教えてください

インフラ構成管理ツールには色々な種類があり、対応している管理対象やコードを記載するの言語が異なります。有名な物では Chef、Puppet 、Ansible などがあります。

Chef、Puppet はエージェント型の構成管理ツールで、管理対象マシンの中で起動する専用エージェントが、中央サーバーにアクセスしてコードを取得した後に、エージェントがマシン内の設定を更新します。
Ansible はエージェントレスモデルで、Ansible がセットアップされている管理サーバからネットワーク経由で接続できれば管理対象マシンで事前準備する必要なく利用することができます。

最近ではクラウド環境をメインで利用することが増えてきていますので、それぞれのクラウド環境に適したツールが準備されています。
AWS であれば AWS CloudFormation や AWS Cloud Development Kit (CDK)、 Azure であれば Azure Resource Manager(ARM) テンプレートや Azure Automation Desired State Configuration (DSC) などがあります。

どのようなお客様向けのサービスですか

IaC はエンドユーザのための技術と言うよりも、開発者や運用者のための技術です。
そのため、自社でサービスを運用しているお客様や、新たに立ち上げようとするお客様に対して有効なサービスです。

IaC を導入することでお客様にはどのようなメリットがありますか

IaC のメリットというのはインフラをドキュメントに記述するので変更管理が行いやすい点と、複雑なデプロイ作業を簡易に実行できることで工数を削減できる点があります。

変更管理については、1種類のドキュメントで複数のサービスとミドルウェアの設定が管理できるようになるので、現在サービスの状態の見通しがよくなります。

工数削減については、環境構築作業を自動化することで、開発者や運用者が今まで取られていた作業時間を削減でき、他の作業が実施できるようになります。

AWS などのクラウドサービスでは IaC を用いることでデプロイを簡単に行なえますし、GitHub Action などを併用すれば CI/CD の一環として GitHub にソースコードを Push したタイミングで自動でデプロイやテストを行うことができます。

IaC を導入する際に気を付けなければならいことは何でしょうか

導入するメリットの一つである工数削減については、IaC を利用する環境によってかなり変動するので注意が必要です。

IaC はあくまでサービスを動かす環境を構築するための技術であって、IaC 自体が直接利益を生み出すサービスではありません。このため、導入するために発生するコストと導入後に自動化できることで削減できる工数を比較して、事前に導入価値があることを評価しておく必要があります。

例えば、同一構成のサーバ環境を定期的に提供するようなサービスを実施している環境であれば、一度作成したコードを何度も活用できるので、効率的で大きく工数削減ができます。
反対に、毎回環境や構成の異なる多種のサーバ環境を構築するような場合であれば、それぞれのサーバ環境に合わせたコードを事前に準備する必要があるため、初期工数が大きくなり容易に工数削減につなげれなくなります。

また、IaC を導入する場合に、どの範囲までを自動化するかを判断するのも重要になります。

最近のクラウド環境などでは、API を利用して環境構築することが当たり前になっていますが、物理サーバなどでは IaC に対応していない機能もまだ多くあります。
このため、IaC を導入する際にはどこまでをコードを作成して自動化していくのか、どこからは今まで通り手動で対応するのかなど、利用頻度、自動化の難易度、必要工数などを合わせて検討する必要があります。

どのような実例、実績がありますか

AWS のサーバレスアーキテクチャ構成で、AWS CDK と Azure DevOps を利用してデプロイの自動化実現するための環境構築作業を担当したり、Azure の Azure Resource Manager (ARM) テンプレートを用いて、サービスのパラメータ管理を実現した実績があります。

それ以外では、直接 IaC の環境を構築する作業ではありませんが、自分で利用する端末で複数の環境設定を管理しなくてはいけない時に、PowerShell DSC を利用して環境の切り替えを行なうなど、利用環境に合わせたインフラ構成管理ツールを利用して運用工数の削減を実現してきてました。