Infrastructure as Code（IaC）とは

Infrastructure as Code（IaC）は、ハードウェアや手動のプロセスではなく、ソフトウェアや自動化されたプロセスによってインフラストラクチャを管理し、プロビジョニングする手法です。これにより、ソフトウェア開発者はコンピュート、ストレージ、ネットワークの要件に関する命令を記述して実行できるため、手作業で行うよりも迅速にプロビジョニングできます。反復的な IT プロセスを自動化するために使用される基本的なスクリプトとは異なり、Infrastructure as Code では、複雑なプロセスや汎用性と適応性の高いプロセスを管理できます。

IDC ホワイトペーパー：ネットワークの自動化：DX 戦略の欠けている要素

今すぐダウンロード

VMware Aria Automation

今すぐダウンロード

Infrastructure as Code が重要な理由

最新のクラウド環境では、Infrastructure as Code が、円滑な運用を確立するための重要な鍵となりつつあります。コンテナやマイクロサービスの台頭に伴い、少数の大規模なアプリケーションではなく、多数の小規模なアプリケーションに対して、インフラストラクチャを個別にプロビジョニングする必要が生じています。Infrastructure as Code は、このようなプロビジョニングを自動化してこの課題を解決できます。

また、IaC は、DevOps に必要な IT インフラストラクチャへの容易なアクセスを開発者に提供できるため、DevOps 環境で特に重要になります。インフラストラクチャや運用をアプリケーションコードやその他のコードと同様に扱うことで、継続的なモニタリングやバージョン管理といった DevOps のベストプラクティスが、インフラストラクチャを管理するコードにも適用されるようになります。

Infrastructure as Code と Platform as Code

Infrastructure as Code と Platform as Code（PaC）は、テクノロジースタックの異なるレイヤーに適用される類似の概念です。前述のとおり、IaC はインフラストラクチャレイヤーでコンピュート、ストレージ、ネットワークのプロビジョニングを処理します。これに対して PaC は、プラットフォームレイヤー（OS や開発ツールなど）を対象とし、アプリケーションのプラットフォームを開発者が定義して実行できるようにします。

IaC と PaC の大きな違いとしては、対象とするレイヤーが異なる以外に、実装方法も挙げられます。IaC は Kubernetes API 上のラッパーを作成することで実装され、PaC は Kubernetes API の拡張機能を作成することで実装されます。

Infrastructure as Code のメリット

Infrastructure as Code を実装すると、次のようなメリットが得られます。

DevOps のベストプラクティスを実装：インフラストラクチャをその他のコードと同じように扱うと、継続的なモニタリング、バージョン管理、自動テストなどの DevOps のベストプラクティスを適用して、シンプルな管理を実現できます。
開発者向けのセルフサービスを実現：IaC により、開発者は、リソースのプロビジョニングについて IT 部門に依存するのではなく、コンプライアンスに準拠した安全な方法で専用のインフラストラクチャをプロビジョニングできます。
スケーラビリティと迅速なプロビジョニングを提供：IaC がもたらす自動化により、手動では追い付かないリソースのスケールアップやスケールダウンが可能になります。特にコンテナ化された環境では、マイクロサービスにおいてサービスごとにインフラストラクチャを個別にプロビジョニングする必要があるため、手作業では対応が困難です。
再現性と一貫性を確保：インフラストラクチャのプロビジョニングに同じコードベースを使用することによって、数百、数千のアプリケーションで一貫性を確保できます。

Infrastructure as Code に関する考慮事項

Infrastructure as Code（IaC）は、コンテナ化された DevOps エンタープライズ環境では必須であり、デメリットはほとんどありません。ただし、潜在的な課題がいくつかあります。利用可能な Infrastructure as Code ツールは複雑であり、IT チームにとって追加のトレーニングが必要になる場合があります。インフラストラクチャ自動化についても、IaC 環境ではエラーがただちに拡散することになるため、バージョン管理とテストの重要性が高くなります。同様に、IaC は一般的に構成エラーを防止しますが、IT 管理者が IaC の標準テンプレート以外によってサーバ構成を変更するなどした場合には、反対に構成エラーを導入してしまう可能性があるため、IaC の標準を運用し、ポリシーを慎重に文書化する必要があります。

Infrastructure as Code がもたらすセキュリティ上のメリット

セキュリティに関しては、Infrastructure as Code には、ほかのタイプの自動化と同じ注意点があります。大規模にエラーが繰り返されて被害が拡大したり、セキュリティ上の問題が発生したりするのを避けるために、最初から適切に設定する必要があります。ただし、慎重に検討して設定すれば、セキュアな Infrastructure as Code により、人的ミスのリスクを最小限に抑え、セキュリティ上の考慮事項を開発プロセスに確実に組み込むことができます。

IaC は、手動のプロセスではなく自動化に依存するため、自動化によるセキュリティ上のメリットをすべて享受でき、構成エラーに関連するセキュリティ上の問題を回避できます。サーバやアプリケーションの一元管理により、環境全体で一貫性と安全性が確保されます。変更は手動ではなく、コードで定義する必要があるため、不正な変更を防止できます。実際、宣言型のセットアップでは、（コードを通じてではなく）直接行われた変更は、コードで定義された状態によって自動的に上書きされます。また、強力なバージョン管理機能により、変更（コードによる変更も含む）を簡単に元に戻すこともできます。

IaC 環境では、サーバの構成など、すべてがコードで定義され文書化されており、外部の監査人に情報を提供しやすいため、監査も容易です。