Infrastructure as Code

Infrastructure as Code（IaC）とは

Infrastructure as Code（IaC）は、高レベルの記述的なコーディング言語を用いて、ITインフラストラクチャーのプロビジョニングを自動化します。この自動化により、開発者は、ソフトウェア・アプリケーションの開発、テスト、またはデプロイのたびに、サーバー、オペレーティング・システム、データベース接続、ストレージ、およびその他のインフラストラクチャー要素を手動でプロビジョニングおよび管理する必要がなくなります。

企業にとって1日に何百ものアプリケーションを本番環境にデプロイすることが珍しくない時代において、常にインフラストラクチャーが、開発者やユーザーの要求に応じて立ち上げられ、削減され、さらには規模の拡大や縮小が行われています。その中で企業は、インフラストラクチャーを自動化してコストを管理し、リスクを低減し、新たなビジネスチャンスや競争上の脅威に迅速に対応することが不可欠になっています。 IaCはこの自動化を可能にします。

IaCはまた、競争力のあるペースのソフトウェア・デリバリー・ライフサイクルに欠かせない、 DevOps の必須の手法でもあります。これにより、DevOpsチームは、ソースコードをバージョン管理するのと同様に、インフラストラクチャーを迅速に作成、バージョン管理、およびこれらのバージョンを追跡することができ、デプロイ時に深刻な問題を引き起こす可能性のあるIT環境間の不整合を回避することができます。

Sai Vennamが、以下の動画「Infrastructure as Codeとは」でIaCについて詳しく説明しています。

Infrastructure as a Codeのメリット

従来のITのプロビジョニングは、ハードウェアの物理的なセットアップ、オペレーティング・システム・ソフトウェアのインストールと構成、ミドルウェア、ネットワーク、ストレージなどへの接続などを専門の担当者が行う必要があり、時間とコストがかかるものでした。

仮想化とクラウド・ネイティブ開発は、物理的なハードウェア管理の問題を解消し、開発者が必要に応じて独自の仮想サーバーやコンテナをプロビジョニングすることを可能にします。しかし、仮想化インフラのプロビジョニングは、開発者のコーディングへの集中力を削ぎ、新しいデプロイメントのたびにプロビジョニング作業を繰り返さなければならず、環境の変化を追跡し、デプロイメントに影響を与える不整合を防ぐ簡単な方法も提供されていません。

Infrastructure as Code（IaC）は、開発者がスクリプトを実行することで、完全に文書化され、バージョン管理されたインフラを効果的に「オーダー」できるようにする最終的なステップです。そのメリットは、まさにご想像の通りです。

生産/市場投入までの時間を短縮：IaCの自動化により、開発、テスト、および本番のためのインフラストラクチャーのプロビジョニング（および必要に応じて本番インフラストラクチャーのスケール・アップやダウン）のプロセスが劇的に短縮されます。 IaCはすべてをコード化して文書化しているため、従来は時間のかかるプロセス（チケットの発行など）で管理されていたレガシー・インフラストラクチャーのプロビジョニングを自動化することもできます。
一貫性の改善（「構成のドリフト」を低減）： 構成ドリフトとは、そのアドホックな設定変更や更新により、開発環境、テスト環境、デプロイメント環境が不一致になってしまうことで発生します。その結果、デプロイメントの問題、セキュリティー上の脆弱性、厳格な法規制遵守の基準を満たす必要のあるアプリケーションやサービスの開発時のリスクなどが発生します。 IaCは常に同じ環境をプロビジョニングすることでドリフトを防ぎます。
より速く、より効率的な開発： プロビジョニングを簡素化し、インフラストラクチャーの一貫性を確保することで、IaCは自信を持ってソフトウェア・デリバリー・ライフサイクルのすべてのフェーズを加速することができます。開発者は、サンドボックスや継続的インテグレーション/継続的デプロイメント（CI/CD）環境を迅速にプロビジョニングすることができます。 QAは、完全に忠実なテスト環境を迅速にプロビジョニングできます。オペレーションは、セキュリティーやユーザーの受け入れテストのためのインフラストラクチャーを迅速にプロビジョニングすることができます。そして、そのコードがテストに合格すると、アプリケーションとその上で動作する本番インフラストラクチャーをワンステップでデプロイすることが可能になります。
チャーンからの保護： IaCを持たない企業では、効率性を最大化するために、プロビジョニングを少数の熟練したエンジニアやITスタッフに任せるのが一般的です。このような専門家が組織を離れてしまうと、プロセスの再構築は他の社員に委ねられる場合があります。 IaCは、プロビジョニング・インテリジェンスが常に組織内に存在することを保証します。
コスト削減とROIの向上： IaCは、インフラストラクチャーのプロビジョニングや拡張に必要な時間、労力、および専門的なスキルを大幅に削減するだけでなく、クラウド・コンピューティングの消費量ベースのコスト構造を最大限に活用することができます。また、開発者は配管に費やす時間を減らし、革新的でミッション・クリティカルなソフトウェア・ソリューションの開発に時間を割くことができます。

変更可能なインフラストラクチャーと変更不可能なインフラストラクチャー

Infrastructure as Code（IaC）でインフラを自動化する際、またIaCソリューションを選択する際には、 変更可能な インフラストラクチャーと 変更不可能な インフラストラクチャーのどちらを確立するかの決定が重要になります。

変更可能なインフラストラクチャー とは、最初にプロビジョニングされた後に、変更や更新が可能なインフラのことです。変更可能なインフラストラクチャーでは、開発チームは、開発やアプリケーションの要件に合わせてサーバーを柔軟にカスタマイズしたり、緊急のセキュリティー問題に対応したりすることができます。しかし、これはIaCの主な利点である、デプロイメント間またはバージョン内での一貫性を維持する能力を損なうものであり、インフラストラクチャーのバージョン追跡をより困難にする可能性があります。

このような理由から、ほとんどのIaCは、最初にプロビジョニングされた後は変更できない 変更不可能なインフラストラクチャーとして実装されています。変更不可能なインフラストラクチャーを変更する必要がある場合は、新しいインフラに交換しなければなりません。特にIaCでは、クラウド上で新しいインフラストラクチャーをすぐに立ち上げることができるため、変更不可能なインフラストラクチャーは思ったよりもはるかに実現可能で実用的です。

変更不可能なインフラストラクチャーは、IaCをさらに論理的に進化させ、IaCを強固にすることで、IaCがもたらすメリットをさらに確実なものにします。これにより、構成のドリフトがほとんどなくなり、テスト環境とデプロイ環境の間で一貫性を保つことがさらに容易になります。また、インフラストラクチャーのバージョンを維持および追跡することもさらに容易になり、必要に応じて任意のバージョンに自信を持ってロールバックすることができます。

宣言型アプローチと命令型アプローチ

IaCソリューションを選択する際には、インフラストラクチャーの自動化に対する 宣言型 アプローチと 命令型 アプローチの違いを理解することも重要です。

多くの組織では、 宣言型 アプローチ（機能型アプローチとも呼ばれる）が最適です。宣言型アプローチでは、プロビジョニングしたいインフラストラクチャーの最終的な状態を指定すると、あとはIaCソフトウェアが、仮想マシン（VM）やコンテナの立ち上げ、必要なソフトウェアのインストールと構成、システムやソフトウェアの相互依存性の解決、バージョン管理などを行います。宣言型アプローチの最大の欠点は、設定と管理に熟練した管理者が必要で、これらの管理者は自分の好きなソリューションに特化していることが多いことです。

命令型 アプローチ（手続き型アプローチとも呼ばれる）では、特定のステップごとにインフラストラクチャーのプロビジョニングを行う自動化スクリプトを作成することができます。規模が大きくなると管理が大変になりますが、既存の管理スタッフにとっては理解しやすく、すでに導入している構成スクリプトを活用することができます。

宣言型アプローチと命令型アプローチの選択は、GPSを使うか、またはどこで曲がるかの指示を受けるのか、ということに似ています。 GPSでは、住所を入力すると、あとはGPSが最速のルートや渋滞回避をしてくれますが、なぜそのような選択をしたのかは、専門家に聞いてみないとわかりません。ターンバイターンの指示は個人的な経験に基づいています。提供者はルートとその選択理由を知っていますが、障害物に遭遇したり、ルートを最適化したい場合は、助けを求めるか、自分で作業をしなければなりません。

Infrastructure as Codeツール

オープン・ソースのIaCツールは数多くありますが、最も一般的に採用されているツールはAnsibleとTerraformです。

Ansibleとは

Ansible （ibm.com外部へのリンク）は、Red Hatがスポンサーを務めるオープン・ソースのコミュニティー・プロジェクトで、プロビジョニング、構成管理、およびアプリケーションのデプロイメントを自動化することを目的としています。宣言型の自動化ツールであるAnsibleは、「プレイブック」（構成言語YAMLで記述）を作成して、インフラストラクチャーの望ましい状態を指定し、プロビジョニングを行います。 Ansibleは、 Docker コンテナや Kubernetes のデプロイメントのプロビジョニングを自動化するための一般的な選択肢です。

Terraformとは

Terraform は、宣言型のプロビジョニングおよびインフラストラクチャー・オーケストレーション・ツールで、エンジニアは企業のクラウドベースおよびオンプレミスのインフラストラクチャーのあらゆる側面のプロビジョニングを自動化することができます。

Terraformは主要なクラウド・プロバイダーに対応しており、物理的なサーバーや DNSサーバー、またはデータベースの設置場所に関わらず、複数のプロバイダーのリソースを並行して構築することを自動化できます。また、あらゆる言語で書かれたアプリケーションを提供することができます。

Ansibleとは異なり、Terraformは構成管理機能を提供しませんが、構成管理ツール（Cloud Formationなど）と連携して、構成ファイルで記述された状態のインフラを自動的にプロビジョニングしたり、構成の変更に応じて必要に応じてプロビジョニングを自動的に変更したりします。

IaCツールの選択に関するさらに詳しい情報は、「Infrastructure as Code: Chef, Ansible, Puppet, or Terraform?」をご覧ください。