コードとしてのインフラストラクチャー（IaC）とは

IaCはインフラストラクチャーをソフトウェアとして扱います。チームはIaCを使用して、アプリケーション・コードに使用するのと同じプラクティスを使用してインフラストラクチャーのバージョン管理、テスト、デプロイを行います。

このアプローチにより、チームは煩雑でエラーが発生しやすい、従来の手動による構成を回避できます。手動による構成では、個々のサーバーのセットアップ、コンソール・ベースの管理、および文書化されていない変更が含まれることがよくあります。

代わりに、チームは、必要なリソース（サーバー、ネットワーク、データベース、セキュリティ－・ポリシー）とそれらの構成方法を指定する構成ファイルでインフラストラクチャー要件を定義します。これらのファイルはバージョン管理システムに保存され、追跡、レビュー、ロールバック機能を提供します。

IaCは、コードとオートメーションを使用してITインフラストラクチャーをライフサイクル全体にわたって管理する、インフラストラクチャー・オートメーションの広範な実践における重要な要素です。IaCを使用すると、開発者はアプリケーションを開発、テスト、またはデプロイするたびにインフラストラクチャ－・コンポーネントを手動でプロビジョニングする必要がなくなります。このオートメーションにより、組織はコストを管理し、リスクを軽減し、新しいビジネス・チャンスに迅速に対応できるようになります。

組織がクラウドネイティブ・アーキテクチャーを採用するにつれて、IaCの重要性がますます高まります。IT環境は現在、複数のクラウド、数千のコンテナ、分散マイクロサービスにまたがっています。かつては少数のサーバーを管理していた手動プロセスでは、チームが毎日頻繁にアプリケーションをデプロイし、インフラストラクチャーを常にプロビジョニング、拡張、廃止するこれらのアーキテクチャーには対応できません。

IaCは、次の3つの重要な方法でこれらの複雑な環境を管理するのに役立ちます。

• 大規模な運用：複数の環境にまたがる数千のサーバー、コンテナ、クラウド・リソースを構成および保守します。
  
  
• デプロイメント・サイクルの加速：時間のかかる手動設定なしで、需要に合わせてインフラストラクチャーを即座に拡張します。
  
  
• 一貫性の確保：セキュリティーの脆弱性、コンプライアンス違反、サービス停止につながる人為的ミスや構成ドリフトを排除します。

たとえば、ブラック・フライデーに向けた準備をしている小売企業は、数時間以内に100～1,000台のサーバーを拡張する必要があるかもしれません。IaCを使用すると、このスケーリングは、事前定義されたテンプレートに基づいて、オンプレミスとクラウド・インフラストラクチャー全体で自動的に行われます。この拡張機能により、新しい各サーバーが同一のセキュリティーとコンプライアンス構成を維持することが可能になります。

IBM Institute for Business Valueによると、経営幹部の65％が、IaCなどのオートメーション・テクノロジーによってITチームの生産性が向上していると報告しています。

IaCは、反復可能なワークフローと自動化されたツールを組み合わせます。ワークフロー（書き込み、バージョン、プロビジョニング、デプロイ）は、チームがインフラ要件からデプロイされたリソースに移行する方法を定義します。このツール（構成ファイル、バージョン管理システム、自動化エンジン）は、インフラストラクチャーを定義、追跡、作成するためのメカニズムを提供します。

これらの要素を組み合わせることで、インフラストラクチャー管理は、手動でエラーが発生しやすいプロセスから、自動化された反復可能な機能に変わります。チームは、ソフトウェアと同様に独自のバージョンでインフラストラクチャをコードとして作成し、オンデマンドで同一の環境をデプロイします。

IaCワークフローは、次の4つの段階に従います。

開発者は、Java™やPythonでアプリケーション・コードを作成するのと同様に、HCL、YAML、JSONなどの言語を使用してIaCスクリプトを作成します。チームは、必要なリソースとその構成方法を指定するインフラストラクチャー定義を作成します。多くの場合、これらのファイルは、エラー・チェック機能やオートコンプリート機能を備えた統合開発環境（IDE）で作成されます。

コードは、GitやGitHubなどのバージョン管理システム（ソース管理またはソースコード・リポジトリーとも呼ばれる）に保管されます。バージョン管理は変更を追跡し、代替バージョンを維持し、問題が発生したときにチームが以前のバージョンに戻ることを可能にします。

オートメーション・エンジンは構成ファイルを読み取り、指定されたインフラストラクチャー・リソースをプロビジョニングします。この段階では、コードを実際のインフラストラクチャーに変換します。つまり、仮想マシン（VM）の作成、ネットワークの構成、データベースのセットアップ、セキュリティ－・グループの確立などが行われます。プロビジョニング・プロセスはべき等性があるため、重複したリソースを作成することなく複数回実行できます。

チームはスクリプトを実行してさまざまな環境にインフラストラクチャーをデプロイし、IaCは環境間で一貫した構成を確保するのに役立ちます。スクリプトの一貫性は、アプリケーションに対するソフトウェアの変更が本番環境に自動的にリリースされる継続的デプロイメントを使用する場合に最も役立ちます。

自動化ツールは、コードを通じてインフラストラクチャーを定義、追跡、作成するメカニズムを提供します。

構成ファイルはインフラストラクチャーを定義します。HCL、JSON、YAML、またはドメイン固有の言語で記述できます。これらのファイルは、必要なインフラストラクチャー（サーバーの数、規模、ネットワーク設定）を正確に説明する青写真であり、オートメーション・ツールが読み取って実行できる形式で構成されています。

これらのファイルはチームにとって信頼できる唯一の情報源となり、複数の環境間での一貫性を確保するのに役立ちます。チームが資産を追加するにつれて、更新、再利用、新しいインストール用の変更が可能です。

バージョン管理システムは、各ファイルの履歴を保管します。元のコードと、何が、誰によって、いつ変更されたかを含む変更を追跡します。この追跡により、チームは変更を理解し、削除を回復し、問題が発生したときにロールバックすることができます。

バージョン管理により、組織はインフラストラクチャーをモジュールに分割し、オートメーションを通じてそれらを結合することができます。このモジュール式アプローチは、重複を減らし、スクリプトのテストと再利用を容易にしながら、複雑な環境の構築、更新、バージョン管理に役立ちます。

オートメーション・エンジンは、事前に定義されたコードを使用してプロビジョニングと構成を自動化します。そこでは、構成ファイル内のインフラストラクチャーの定義を実行し、コードをサーバー、ネットワーク、データベースなどの実際のITリソースに変換します。

一部のエンジンは、AWS CloudFormation、Azure Resource Manager、Google Cloudデプロイメント・マネージャーなど、クラウドに特化したものです。その他、Terraform、OpenTofu（Terraformのオープンソース・フォーク)、Pulumi（Pythonなどの汎用プログラミング言語を使用）など、すべてのクラウドで実行されるものもあります。

これらのオートメーション・エンジンは、リソースとワークロードを大規模に調整するために、Kubernetesなどのオーケストレーション・ツールと組み合わせられることがよくあります。

IaCツールは、多くの場合アプリケーション・プログラミング・インターフェース（API）を介してクラウド・プラットフォームと統合されます。これらのAPI接続により、IaCツールはクラウド・サービスと直接通信し、コンソールによる手動操作ではなくプログラムでリソースを作成および管理できるようになります。

IaCには、信頼性を確保するための標準的なソフトウェア開発プラクティスも組み込まれています。自動テストは、デプロイメントの前にインフラストラクチャー構成を検証し、機能停止やセキュリティー脆弱性の原因となる可能性のあるエラーを特定するのに役立ちます。一部のバージョン管理システムでは、コードの変更が発生すると、これらのテストが自動的にトリガーされるため、すべての変更が本番環境に導入される前に確実に検証されるようになります。

IaCを実装する場合、組織は主に、インフラストラクチャーを定義する方法（宣言的または命令的）と、デプロイメント後にインフラストラクチャーを変更できるかどうか（変更可能または不変）の2つの選択を行います。

宣言的アプローチと命令的アプローチは、インフラストラクチャー・コードの記述方法が異なります。

宣言的アプローチは、機能的アプローチや宣言的IaCとも呼ばれ、最も一般的な方法です。ユーザーが希望の状態（「この仕様のサーバーが3台必要です」）を説明すると、IaCが実装を行います。リソースを作成し、必要なソフトウェアをインストールし、相互依存関係を解決し、バージョン管理を自動的に管理します。

手続き型アプローチとしても知られる命令型アプローチでは、インフラストラクチャーのプロビジョニングのために、ユーザーがステップ・バイ・ステップの指示を書く必要があります。「まずサーバーを作成し、このソフトウェアをインストールし、次にこれらの設定を構成する」という正確な順序で指定されます。このアプローチでは、より多くの専門知識が必要となり、一貫性を維持することが困難になる可能性があります。

変更可能なインフラストラクチャーはプロビジョニング後に変更できますが、変更不可能なインフラストラクチャーはプロビジョニング後に変更できません。

変更可能なインフラストラクチャーでは、特定のアプリケーション要件や緊急のセキュリティー・パッチへの対処など、アドホックな変更に柔軟に対応できます。ただし、この柔軟性により一貫性が損なわれ、バージョン追跡が困難になる可能性があります。

ほとんどの組織は、変更不可能なインフラストラクチャーを選択します。サーバーまたは構成を変更するには、チームはインフラストラクチャー全体を新しいリソースに置き換える必要があります。

これは法外なことのように聞こえますが、実際には、いくつかの理由で有益である可能性があります。第一に、変更不可能なインフラストラクチャーでは、構成ドリフトが排除されます。ドリフトは変更可能なインフラストラクチャーでよくある問題で、手作業による変更が時間の経過とともに蓄積され、環境間で一貫性を維持することが困難になります。

第2に、変更不可能なインフラストラクチャーは、変更ごとに新しいバージョン管理されたインスタンスが作成されるため、信頼性の高いバージョン追跡およびロールバック機能を提供します。つまり、チームは以前の構成に即座に戻すことができます。

最後に、クラウドベースのIaCを使用すると、新しいインフラストラクチャーを迅速に、多くの場合数分以内にプロビジョニングできるため、すべてのインフラ・リソースを再プロビジョニングするという考えが、当初の考えよりもはるかに実用的になります。

IaCには、コードを使用してインフラストラクチャー管理を自動化することで、次のようなメリットがあります。

IaCは、インフラストラクチャーをソフトウェア開発の速度で動かすことができるため、DevOpsの実践には不可欠です。

IaCがないと、インフラストラクチャーのプロビジョニングがボトルネックになる可能性があります。コードは数分でデプロイされますが、インフラストラクチャーのセットアップに数時間から数日かかる場合があります。例えば、新しいデータベースを追加するには、インフラストラクチャ－・チームにチケットを発行する必要があり、そのために何日も待つはめになる場合があります。

IaCは、継続的統合と継続的デリバリー（CI/CD）をインフラストラクチャーのデプロイメントに適用することで、このギャップを解消します。インフラストラクチャー・コードとアプリケーション・コードは、異種のプロセスとしてではなく、並行して一緒にテスト、検証、デプロイできます。

実際には、インフラストラクチャー・コードがバージョン管理のアプリケーション・コードと一緒に存在することがよくあります。開発者が変更をコミットすると、CI/CDパイプラインは、IaCテンプレートを使用してテスト・インフラストラクチャーをプロビジョニングし、自動テストを実行し、同じテンプレートを使用して本番環境にデプロイできます。これにより、開発、テスト、ステージング、本番などのすべての環境で同一のインフラストラクチャー構成を実現できます。

主要なメリットは一貫性です。IaCがないと、テスト環境が本番環境と一致しない場合、環境ドリフトが発生し、デプロイメントの失敗を引き起こす可能性があります。IaCは、テスト環境と本番環境の両方が同じインフラストラクチャー定義を使用するため、テストで機能するものが本番環境でも機能することを確認するのに役立ちます。チームはプル・リクエストを通じてインフラストラクチャーの変更をレビューし、変更を追跡し、必要に応じてロールバックすることで、アプリケーション・コードと同じ厳密さでインフラストラクチャーを扱うことができます。

IaCツールは、インフラストラクチャーを作成およびデプロイするプロビジョニング・ツールと、デプロイ後のインフラストラクチャーを維持する構成管理ツールの、2つの主要なカテゴリーに分類されます。

すべてのクラウド上で実行される（複数のプロバイダー間で動作する）ツールもあれば、プラットフォーム固有のものもあります。

組織は通常、両方のカテゴリーからツールを組み合わせて、完全なIaCパイプラインを構築します。

プロビジョニング・ツールは、サーバー、ネットワーク、ストレージ・システムなどのインフラストラクチャ－・リソースを作成およびデプロイします。また、インフラストラクチャー・コンポーネントの初期セットアップと構成に重点を置き、インフラストラクチャー要件を実行可能なリソースに変換します。

IBMグループ企業のHashiCorp社のTerraformは、すべてのクラウドで実行でき、宣言型構成を使用して複数のプラットフォームにわたるインフラストラクチャーを管理するIaCツールです。

チームはHCL（HashiCorp構成言語）でインフラストラクチャーの定義を記述し、同じコードをAWS、Azure、Google Cloud、またはオンプレミスのデータセンターにデプロイできます。この移植性により、組織はベンダー・ロックインを回避し、それぞれの強みに基づいてクラウド・プロバイダーを組み合わせることができます。例えば、コンピューティングにはAWSを使用し、機械学習にはGoogle Cloudを使用することができます。

Terraformはまた、複数のプロバイダーにわたってリソースを同時にプロビジョニングすることで、デプロイメントを迅速化します。リソース間の依存関係を分析し、独立したリソースを並行して作成します。例えば、依存関係なしで10台のAWSサーバーと5つのAzureデータベースをデプロイする場合、Terraformは15のリソースを順番に作成するのではなく、一度にすべてを作成するため、デプロイメント時間が短縮されます。

AWS CloudFormationは、AWSインフラストラクチャー向けのAmazonのネイティブIaCソリューションです。チームは、JSON または YAML テンプレートを使用して、EC2インスタンスからRational Directory Serverデータベースに至るまで、アプリケーション・スタック全体を定義します。CloudFormationはリソースの依存関係を自動的に処理し、正しい順序で作成し、エラーが発生した場合にはロールバックします。

CloudFormationはAWSサービスのみに限定されていますが、AWSサービスとの深い統合と、新しいサービスへの即時サポートを提供します。AWSを導入している組織は、AWSの性能と主要な機能へのアクセスを好む場合があります。

Azure Resource Manager（ARM）は、Azureインフラストラクチャー向けのMicrosoftのネイティブIaCツールです。Azure限定ですが、プラットフォームとの深い統合が可能です。

組織は、ARMテンプレート（JSON形式）を使用してAzureリソースを定義、デプロイ、管理します。ARMには、セキュリティーのためロールベースのアクセス制御、組織のためのリソースのタグ付け、誤って削除されないようにするためのロック、リソースが正しい順序でデプロイされるようにするための依存関係マッピングなどの主要な機能が用意されています。

Google Cloud Deployment Managerは、YAMLまたはPythonのテンプレートを使用してGoogle CloudのデプロイメントをオーケストレーションするGoogleのネイティブIaCツールです。プラットフォーム固有ではありますが、データ用のCloud Storage、VM用のCompute Engine、データベース用のCloud SQLなど、複数のサービスにわたるリソースを作成および構成し、完全なスタックとして確実に連携できるようにします。

構成管理ツールは、プロビジョニング後のインフラストラクチャーを維持し、システムの適切な構成、パッチ適用、一貫性を維持するのに役立ちます。

Ansibleは、Red Hatのオートメーション・ツールで、ターゲット・システム上でエージェントを必要とせずに構成を管理します。言い換えれば、Ansibleは、管理するサーバーに特別なソフトウェアをインストールする必要がありません。SSHを使用してコマンドを実行することで直接接続します。

このエージェントレスなアプローチは、Ansibleがクラウド、オンプレミス、およびハイブリッド環境全体で動作することを意味します。チームは必要な状態を定義するYAMLプレイブックを作成します。Ansibleはシステムがそれらの状態に一致することを確認するのに役立ちます。DockerコンテナとKubernetesデプロイメントの管理のために人気があります。

Puppetは宣言型構成を使用して、クラウド、オンプレミス、データセンター環境にまたがる大規模なインフラストラクチャーを管理します。

数千台のサーバーを継続的にチェックして、定義された構成と一致していることを確認し、ドリフトを自動的に修正します。Puppetは、何がいつ変更されたかを示す詳細なレポートを生成するため、大規模なデプロイメントで効果的です。

Chefは「クックブック」と「レシピ」を使用して、クラウド、オンプレミス、ハイブリッドなど、あらゆる環境にわたるインフラストラクチャー構成を定義します。

組織はテスト・フレームワークとしてChefを使用することがよくあります。チームは、本番環境に移行する前に、テスト環境で構成を検証できます。問題を早期に発見するこのアプローチは、インフラストラクチャーの頻繁な更新や、強力なテスト・フレームワークを重視する組織で人気が高まる可能性があります。