前書き
従来の可変サーバーインフラストラクチャでは、サーバーは継続的に更新および変更されます。 この種のインフラストラクチャを扱うエンジニアと管理者は、サーバーにSSHで接続し、パッケージを手動でアップグレードまたはダウングレードし、サーバーごとに構成ファイルを調整し、新しいコードを既存のサーバーに直接展開できます。 つまり、これらのサーバーは変更可能です。作成後に変更できます。 可変サーバーで構成されるインフラストラクチャは、それ自体が可変、従来型、または（軽par的に）職人技と呼ばれます。
immutable infrastructureは、サーバーが展開された後にサーバーが変更されることのないもう1つのインフラストラクチャパラダイムです。 何らかの方法で更新、修正、または修正が必要な場合、適切な変更を加えた共通イメージから構築された新しいサーバーがプロビジョニングされ、古いサーバーが置き換えられます。 検証後、それらは使用され、古いものは廃止されます。
不変のインフラストラクチャの利点には、インフラストラクチャの一貫性と信頼性の向上、およびよりシンプルで予測可能な展開プロセスが含まれます。 構成のドリフトやスノーフレークサーバーなどの可変インフラストラクチャで一般的な問題を軽減または完全に防止します。 ただし、多くの場合、効率的に使用するには、包括的な展開の自動化、クラウドコンピューティング環境での高速サーバープロビジョニング、ログなどのステートフルデータまたは一時データを処理するソリューションが含まれます。
この記事の残りの部分では：
-
可変インフラストラクチャと不変インフラストラクチャの概念的および実際的な違いを説明する
-
不変のインフラストラクチャを使用する利点を説明し、合併症を文脈化する
-
実装の詳細および不変のインフラストラクチャに必要なコンポーネントの概要を提供します
可変インフラストラクチャと不変インフラストラクチャの違い
可変インフラストラクチャと不変インフラストラクチャの最も基本的な違いは、中央のポリシーにあります。前者のコンポーネントは、展開後に変更されるように設計されています。後者のコンポーネントは変更されないままで、最終的に交換されるように設計されています。 このチュートリアルでは、サーバーとしてこれらのコンポーネントに焦点を当てていますが、コンテナなど、同じ高レベルの概念を適用する不変のインフラストラクチャを実装する他の方法があります。
さらに詳しく説明すると、サーバーベースの可変インフラストラクチャと不変インフラストラクチャには実用的および概念的な違いがあります。
概念的に言えば、2種類のインフラストラクチャは、サーバーの処理方法に対するアプローチが大きく異なります（例： 作成、維持、更新、破棄）。 これは一般的に「ペット対牛」の類推で説明されます。
実際には、可変インフラストラクチャは、仮想化やクラウドコンピューティングなどの不変のインフラストラクチャを実用的かつ実用的にするコアテクノロジーよりも前の、はるかに古いインフラストラクチャパラダイムです。 この履歴を知ることは、2つの概念の違いと、現代のインフラストラクチャでどちらか一方を使用することの意味を文脈化するのに役立ちます。
次の2つのセクションでは、これらの違いについて詳しく説明します。
実用的な違い：クラウドを採用する
仮想化とクラウドコンピューティングが可能になり、広く利用可能になる前は、サーバーインフラストラクチャは物理サーバーを中心としていました。 これらの物理サーバーは、作成に費用と時間がかかりました。新しいハードウェアを注文し、マシンを構成してから、coloまたは同様の場所にインストールするのに時間がかかるため、初期セットアップには数日または数週間かかる場合があります。
可変インフラストラクチャの起源はここにあります。 サーバーの交換コストが非常に高かったため、ダウンタイムをできるだけ少なくして、実行中のサーバーをできるだけ長く使用し続けることが最も実用的でした。 これは、通常の展開と更新のために多くのインプレース変更があったことを意味しましたが、何かがうまくいかなかったときのアドホックな修正、微調整、およびパッチもありました。 頻繁に手動で変更を行うと、サーバーの複製が難しくなり、各サーバーがインフラストラクチャ全体の一意かつ脆弱なコンポーネントになる可能性があります。
virtualization and on-demand/cloud computingの出現は、サーバーアーキテクチャのターニングポイントを表しています。 仮想サーバーは大規模であっても安価であり、数日または数週間ではなく数分で作成および破棄できました。 これにより、configuration managementまたはcloud APIsを使用して新しいサーバーを迅速、プログラム、および自動でプロビジョニングするなど、新しい展開ワークフローとサーバー管理手法が初めて可能になりました。 新しい仮想サーバーを作成する速度と低コストは、不変性の原則を実用的にするものです。
従来の可変インフラストラクチャは、物理サーバーの使用が管理の可能性を決定するときに最初に開発され、技術が時間とともに向上するにつれて開発を続けました。 展開後にサーバーを変更するというパラダイムは、現代のインフラストラクチャでは依然として一般的です。 対照的に、不変のインフラストラクチャは、クラウドコンピューティングの仮想サーバーなどのアーキテクチャコンポーネントの高速プロビジョニングのために、仮想化ベースのテクノロジーに依存するように最初から設計されました。
概念的な違い：ペットと牛、雪片とフェニックス
クラウドコンピューティングが進化した根本的な概念上の変更点は、サーバーを使い捨てと見なせるようになったことです。 物理サーバーの破棄と交換を検討することは非常に非現実的ですが、仮想サーバーを使用することは可能であるだけでなく、簡単かつ効率的です。
従来の可変インフラストラクチャのサーバーは、かけがえのないユニークなシステムであり、常に稼働し続ける必要がありました。 このように、彼らはペットのようなものでした。類のないものであり、手に負えない傾向がありました。 負けると壊滅的です。 一方、不変のインフラストラクチャ内のサーバーは使い捨てであり、自動化ツールを使用して簡単に複製または拡張できます。 このように、彼らは牛のようなものです。個体がユニークでも不可欠でもない群れの多くの1つです。
最初にペットを適用したRandy Biasを引用すると、 クラウドコンピューティングに類似した牛：
従来のやり方では、サーバーをペットのように扱います。たとえば、メールサーバーのボブです。 ボブがダウンした場合、それはすべてデッキにあります。 CEOはメールを受け取ることができず、世界の終わりです。 新しい方法では、群れの牛のようにサーバーに番号が付けられます。 たとえば、www001からwww100まで。 1台のサーバーがダウンすると、サーバーは取り外され、射撃され、その場で交換されます。
サーバーの処理方法の違いの影響を示す別の同様の方法は、スノーフレークサーバーとフェニックスサーバーの概念を使用することです。
Snowflake serversはペットに似ています。 それらは手作業で管理され、頻繁に更新され、適切に調整されたサーバーであり、独自の環境につながります。 Phoenix serversは牛に似ています。 これらは常にゼロから構築されるサーバーであり、自動化された手順を使用して簡単に再作成（または「灰から立ち上がる」）できます。
不変のインフラストラクチャは、ほぼすべてが牛またはフェニックスサーバーで構成されていますが、可変インフラストラクチャでは、一部（または多く）のペットまたはスノーフレークサーバーを使用できます。 次のセクションでは、両方の意味について説明します。
不変のインフラストラクチャの利点
不変のインフラストラクチャの利点を理解するには、可変インフラストラクチャの欠点を文脈化する必要があります。
可変インフラストラクチャ内のサーバーは、構成のずれに苦しむ可能性があります。文書化されていない場合、即興の変更により、サーバーの構成は相互に、およびレビュー、承認、および最初に展開された構成からますます分岐します。 ますますスノーフレークに似たこれらのサーバーは、再現や交換が難しく、スケーリングや問題からの回復などを困難にします。 問題を複製してデバッグすることでさえ、実稼働環境と一致するステージング環境を作成するのが難しいため、困難になります。
サーバーのさまざまな構成の重要性または必要性は、多くの手動での修正を行った後は明確にならないため、そのいずれかを更新または変更すると、意図しない副作用が生じる可能性があります。 最良の場合であっても、既存のシステムに変更を加えることは機能することが保証されていません。つまり、これに依存する展開は失敗したり、サーバーを不明な状態にしたりします。
これを念頭に置いて、不変のインフラストラクチャを使用する主な利点は、展開の単純さ、信頼性、および一貫性です。これらはすべて、最終的に多くの一般的な問題点と障害点を最小化または排除します。
既知の良好なサーバー状態と少ない展開エラー
不変のインフラストラクチャでのすべての展開は、検証およびバージョン管理されたイメージに基づいて新しいサーバーをプロビジョニングすることにより実行されます。 その結果、これらの展開はサーバーの以前の状態に依存せず、そのために失敗することはありません-または部分的にしか完了しません。
新しいサーバーをプロビジョニングすると、使用する前にテストでき、ロードバランサーの更新など、新しいサーバーを使用できるようにするために、実際の展開プロセスを1つの更新に減らすことができます。 つまり、デプロイメントはatomicになります。正常に完了するか、何も変更されません。
これにより、展開の信頼性が大幅に向上し、インフラストラクチャ内のすべてのサーバーの状態が常に把握されるようになります。 さらに、このプロセスにより、blue-green deploymentまたはrolling releasesの実装が容易になり、ダウンタイムが発生しなくなります。
構成ドリフトまたはスノーフレークサーバーなし
不変のインフラストラクチャの構成変更はすべて、更新されたイメージをドキュメントでバージョン管理にチェックインし、自動化された統合展開プロセスを使用して、そのイメージで交換サーバーを展開することで実装されます。 サーバーへのシェルアクセスは完全に制限される場合があります。
これにより、スノーフレークサーバーと構成のずれのリスクを排除することにより、複雑なセットアップや再現が難しいセットアップを防ぎます。 これにより、エラーのリスクが高く、ダウンタイムや意図しない動作を引き起こす、あまり理解されていない本番サーバーを変更する必要がある状況も回避できます。
一貫したステージング環境と簡単な水平スケーリング
すべてのサーバーが同じ作成プロセスを使用するため、デプロイメントのエッジケースはありません。 これにより、本番環境の複製が簡単になるため、面倒なステージング環境や一貫性のないステージング環境が防止されます。また、インフラストラクチャに同一のサーバーをシームレスに追加できるため、horizontal scalingが簡素化されます。
単純なロールバックおよび回復プロセス
バージョン管理を使用してイメージ履歴を保持することも、生産の問題の処理に役立ちます。 新しいイメージを展開するために使用されるのと同じプロセスを使用して、古いバージョンにロールバックすることもできます。
不変のインフラストラクチャ実装の詳細
不変のインフラストラクチャには、特に従来の可変インフラストラクチャと比較して、実装の詳細にいくつかの要件とニュアンスがあります。
不変の主要な原則を遵守するだけで、自動化、ツール、またはソフトウェア設計の原則に関係なく、不変のインフラストラクチャを実装することは技術的に可能です。 ただし、大規模な実用性のために、以下のコンポーネント（おおまかに優先順位順）を強くお勧めします。
-
Servers in a cloud computing environment、または別の仮想化環境（like containers、ただし、以下の他のいくつかの要件が変更されます）。 ここで重要なのは、カスタムイメージからの高速プロビジョニングと、APIなどを介した作成と破棄の自動管理を備えたインスタンスを分離することです。
-
Full automation of your entire deployment pipeline、理想的には作成後の画像検証を含みます。 この自動化を設定すると、このインフラストラクチャを実装するための初期費用が大幅に増加しますが、1回限りの費用であり、すぐに償却されます。
-
service-oriented architecture。インフラストラクチャを、ネットワークを介して通信するモジュール式の論理的に離散したユニットに分割します。 これにより、similarly service-orientedであるクラウドコンピューティングの製品を最大限に活用できます（例： IaaS、PaaS）。
-
不変のサーバーを含むstateless, volatile application layer。 ここにあるものはすべて、データを失うことなく（ステートレス）、いつでも迅速に破棄および再構築できます（揮発性）。
-
以下を含むpersistent data layer：
-
Centralized loggingには、バージョンやGit commit SHAを介したイメージの識別など、サーバーの展開に関する追加の詳細が含まれます。 このインフラストラクチャではサーバーは使い捨て（および頻繁に廃棄）されるため、ログおよびメトリックを外部に保存すると、シェルアクセスが制限されている場合やサーバーが破壊された後でもデバッグできます。
-
データベースおよびDBaaS/cloud databasesやobject or block storage（クラウド提供または自己管理）などの他のステートフルデータまたはエフェメラルデータの場合はExternal data stores。 サーバーが揮発性の場合、ローカルストレージに依存できないため、そのデータを別の場所に保存する必要があります。
-
-
Dedication from engineering and operations teamsは、協力してアプローチにコミットします。 最終製品のすべての単純さのために、不変のインフラストラクチャには多くの可動部分があり、誰もそのすべてを知らないでしょう。 さらに、このインフラストラクチャ内での作業のいくつかの側面は、デバッグやシェルアクセスなしの1回限りのタスクの実行など、人々の快適ゾーンの外にある場合があります。
これらの各コンポーネントを実装するには、さまざまな方法があります。 どちらを選択するかは、主に個人の好みと親しみやすさ、および有料サービスに依存するよりも自分で構築するインフラストラクチャの量に依存します。
CI/CD toolsは、デプロイメントパイプラインの自動化を開始するのに適した場所です。 ComposeはDBaaSソリューションのオプションです。 rsyslogとELKは、集中ログの一般的な選択肢です。実稼働環境のサーバーをランダムに強制終了するNetflix’s Chaos Monkeyは、最終的なセットアップのための実際の試行です。
結論
この記事では、不変のインフラストラクチャとは何か、それと古いスタイルの可変インフラストラクチャの概念的および実際的な違い、それを使用する利点、その実装の詳細について説明しました。
不変のインフラストラクチャへの移行を検討する必要があるかどうか、またはいつ検討する必要があるかを知ることは困難な場合があり、明確に定義されたカットオフまたは変曲点はありません。 始める方法の1つは、この記事で推奨されている設計管理の一部を実装することです。これは、大部分が変更可能な環境で作業している場合でも構成管理などです。 これにより、将来、不変性への移行が容易になります。
上記のコンポーネントのほとんどを備えたインフラストラクチャがあり、スケーリングの問題に直面したり、展開プロセスの不格好さに不満を感じている場合は、不変性がインフラストラクチャをどのように改善できるかを評価する良い機会になります。