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

組織は、変更可能と変更不可能という2つのアプローチでインフラストラクチャーを管理できます。変更不可能インフラストラクチャーは、サーバーを変更するのではなく、サーバーを完全に置き換えます。変更可能なインフラストラクチャーは、更新、パッチ、構成変更を実稼働サーバーに直接適用することで、適切なサーバーを変更します。

変更可能なインフラストラクチャーは主に既存のサーバーを変更するため、より効率的であるように見えます。ただし、多くの場合、変更不可能インフラストラクチャーがより実用的で望ましいものになります。

まず、クラウド・コンピューティングとコンテナ化により、デプロイメント速度が劇的に変化しました。組織は、物理サーバーで必要だった数時間ではなく、数分で仮想マシン（VM）とコンテナを置き換えることができるようになりました。インフラストラクチャー・オートメーション・ツールは、新しいサーバーとIT参考情報をプロビジョニングおよび構成し、統一的な変更を大規模に適用できます。

第2に、変更不可能インフラストラクチャーは、変更が蓄積するにつれてシステムが意図した状態から徐々に乖離してしまう、変更可能なインフラストラクチャーに共通する主要な特徴である構成ドリフトを大幅に削減できます。構成ドリフトは、ネットワークの問題によりデプロイメント・プロセスが中断され、更新の部分的または失敗が生じる場合に特に一般的です。このドリフトは、性能の低下、セキュリティーの脆弱性、コンプライアンス違反につながる可能性があります。

例えば、100台の本番環境サーバーにセキュリティー更新プログラムをデプロイする場合、オートメーションは更新プログラムがプリインストールされた100台の新しいサーバーを作成し、それらを個別に検証できます。検証が完了すると、トラフィックをリダイレクトし、古いサーバーを廃止することができます。これらはすべて、ダウンタイムなしで数分以内に行われます。

変更不可能インフラストラクチャーは、3段階のワークフローに従って、新しい参考情報のプロビジョニング、デプロイ、必要に応じた即時の復旧を可能にします。

このワークフローは、ライフサイクル全体を通じて、サーバー、コンテナ、VM、機能、またはその他のインフラストラクチャー・リソースに適用されます。

プロビジョニングでは、インフラストラクチャーをコードとして使う（IaC）という新しいITインフラストラクチャー・コンポーネントが自動的に作成されます。IaCとは、宣言型のテンプレートまたはコードを使用して、意図したインフラストラクチャーの状態を定義する手法です。

変更不可能環境を更新するために、チームはSSH（安全なリモート・サーバー・アクセスのためのネットワーク・プロトコル）を使用して既存の参考情報を変更するのではなく、定義された設定を使用してまったく新しい参考情報を作成します。

インフラストラクチャーのすべての変更はGitなどのバージョン管理システムに文書化され、テストと再現が可能になります。

一般的なプロビジョニング・ツールには、次のものがあります。

• Terraform：HashiCorp社のInfrastructure-as-Codeプラットフォームは、宣言型のHCL構文と状態ファイルを使用して変更を追跡し、APIを通じてAWS、Google Cloud、Azure、オンプレミス環境全体のインフラストラクチャーをプロビジョニングおよび管理します。

• Docker：主にLinuxシステムですが、WindowsやmacOS上でも、階層化ファイル・システムとOSレベルの仮想化に基づく軽量のコンテナ イメージを構築し、従来のVMよりも高速な展開を可能にします。

• Packer：単一のJSONまたはHCL構成から複数のクラウド・プロバイダーとプラットフォーム（AWS用AMI、VMwareテンプレート、Dockerコンテナ）の同一のマシン・イメージを同時に作成するHashiCorp社のツールです。

• AWS CloudFormation：ロールバックとドリフトの検知が組み込まれたAWSリソースをプロビジョニングするための、JSON/YAMLテンプレートに基づくAWSネイティブなツールです。

• Pulmi：ドメイン固有言語の代わりに使い慣れたプログラミング言語（Python、TypeScript、Go）を使用するIaCプラットフォーム。開発者はループや条件付きなどの標準プログラミング構造を使用できます。

PuppetとChefはもともと、サーバーを適切に更新する変更可能なインフラストラクチャー用に設計されていたことに言及する価値がありますが、現在では一部のチームはこれらを不変アプローチと並行して適応させています。

変更不可能インフラストラクチャーでのデプロイメントは不可分であり、完全に成功するか、まったく発生しません。このアプローチは、自動テスト、迅速な反復、信頼性の高いデプロイメントを重視するDevOpsプラクティスおよび継続的統合パイプラインと一致しています。

オートメーション・ツールは、新しいバージョンの参考情報をデプロイし、トラフィックをそこにリダイレクトして、古いバージョンを廃止します。導入中に問題が発生した場合でも、古いリソースはそのまま稼働し続けるため、ダウンタイムや依存関係のリスクがなくなります。

一般的なデプロイメントおよびオーケストレーション・ツールには、次のようなものがあります。

• Kubernetes：自己修復、自動スケーリング、マシンのクラスター全体のローリング更新を通じて、クラウドネイティブのコンテナ化されたアプリケーションを大規模に管理するオープンソースのコンテナ・オーケストレーション・プラットフォームです。

• Jenkins：ビルド、テスト、デプロイメント・パイプラインをカスタマイズするための広範なプラグイン・エコシステム（1,800以上のプラグイン）を使用して、ビルド、テスト、デプロイメントを自動化するサーバーベースのCI/CDパイプラインです。

• GitHubアクション：GitHubリポジトリに組み込まれたイベント駆動型のCI/CDプラットフォームです。外部サーバーを必要とせず、コードのコミット、プルリクエスト、スケジュールによってトリガーされます。

• Ansible（Red Hat）：主に構成管理ツールですが、デプロイメントにも使用されます。エージェントレスなオートメーションにYAMLプレイブックを使用し、PuppetやChefとは異なり、管理対象ノードにソフトウェアをインストールする必要がありません。

変更不可能インフラストラクチャーのサーバーは一時的に置き換えられるため、永続データは外部に保管する必要があります。組織は、cloud databases、block storage、またはobject storageサービスを使用して、交換するサーバーとは別にデータを維持します。

新しいサーバーがオンラインになると、これらの外部ストレージ・システムを通じて既存のデータに再接続します。構成とメタデータは、多くの場合、Gitなどのバージョン管理システムに保存されます。

更新のたびに新しいインスタンスが作成され、ロールバックのためにクリーンなイメージが維持されます。プロビジョニングとデプロイと同じオートメーション・ツールで、以前のバージョンを数分で復元できます。チームは、変更されたサーバーのデバッグやトラブルシューティングを行うのではなく、以前のイメージを再デプロイするため、構成管理の変更が失敗した場合に従来必要とされていた検出作業が大幅に削減されます。

変更不可能インフラストラクチャーのメリットは、主にデプロイメント・プロセスに関連しており、不変性によってデプロイメントがよりシンプルになり、一貫性が高まります。

変更不可能インフラストラクチャーは、アトミック・デプロイメントを通じて、更新が完全に成功するかまったく成功しないサーバー状態を排除します。

変更可能なインフラストラクチャーは、管理者に完全に認識されていない特性により、予測不可能な「中間」状態につながる部分的な更新を危険にさらします。この状況では、トラブルシューティングが困難になり、セキュリティー・リスクが増大する可能性があります。

変更不可能インフラストラクチャーであれば、そのような状態の可能性が排除されます。更新が失敗した場合でも、サーバーは十分に文書化された状態のままです。成功すると、新しいサーバーは完全に構成され、テストされ、到着します。

変更不可能インフラストラクチャーは、迅速な水平スケーリング、つまり、1台の大型マシンではなく、多数の小型マシンをネットワークに追加することで需要を満たす方法を可能にします。水平スケーリングされたシステムは耐障害性が高く、ワークロードを分散することで処理のボトルネックを軽減できます。

このアプローチは、ネットワーク・トラフィックを複数のサーバーに分散して性能を向上させるロード・バランサーを使用することで実現されます。NginxやAmazonのAWS Elastic Load Balancing（ELB）などのツールは、アルゴリズムを使用して、特定の瞬間にユーザー・リクエストを最も効率的なサーバーに割り当てることで、この慣行をサポートしています。

このロード・バランシングとコンテナ・オーケストレーションの組み合わせにより、再現可能なテンプレートを備えた変更不可能インフラストラクチャーが、緊急時に複数の同一のサーバーを立ち上げるために不可欠なものになります。この設定は、ホリデー・ショッピングやチケット販売期間など、ネットワークが大規模なトラフィックの急増を予想する場合に特に役立ちます。また、異なる時間帯や重なり合う時間帯にトラフィックのピークが発生する世界的な地域全体で調整を行う際にも役立ちます。

変更不可能インフラストラクチャーは、予測不可能な「スノーフレーク状態」（更新失敗後に未知の構成を持つサーバー）を排除し、すべての変更の完全な監査証跡を維持することで、セキュリティーを強化します。

各サーバーはそれを記述したソース・イメージ・ファイルに正確に準拠するため、不正なソフトウェアのインストールや特権昇格などのセキュリティーの脆弱性を特定し、セキュリティー監査を実行することが容易になります。バージョン管理システムは、システムに対して行われた各変更を、誰が、いつ、どのような理由で行ったかなど追跡します。この変更不可能な履歴により、より迅速なフォレンジック分析とインシデント対応が可能になります。チームは侵害された構成を即座に特定し、必要に応じて既知の良好な状態にロールバックできます。

また、変更不可能インフラストラクチャーにより、セキュア・シェル（SSH）ログインを使用してサーバーを編集する必要もなくなるため、ネットワーク全体の攻撃対象領域が軽減されます。

不変性には、主にデータ・ストレージに関する、従来の変更可能なインフラストラクチャーと比較したトレードオフもあります。

変更可能なインフラストラクチャーでは、サーバーがクリティカルなアプリケーション・データをローカル・ディスクに書き込む可能性があるため、そのサーバーとディスクを削除して交換することは危険であり、またはシステムの破壊につながる可能性があります。したがって、変更不可能インフラストラクチャーでは、データを外部に保管する必要があり、システムの複雑さがさらに増します。

この方法では、クラウド・データベース、ブロック・ストレージ、オブジェクト・ストレージなどの外部データ・ストレージを使用できます。新しい仮想マシンがオンラインになると、この外部ストレージを通じて既存のデータとシームレスに再接続できます。組織は通常、構成とメタデータをGitなどのバージョン管理システムで保持します。

ただし、変更不可能インフラストラクチャーの真の「不変性」については議論されることがあります。この制限は、外部に保管されているネットワーク・ユーザー・データが一定の流動状態にあるため、既知の状態と比較できないためです。