序章

従来の可変サーバーインフラストラクチャでは、サーバーは継続的に更新され、その場で変更されます。 この種のインフラストラクチャを使用するエンジニアと管理者は、サーバーにSSHで接続し、パッケージを手動でアップグレードまたはダウングレードし、サーバーごとに構成ファイルを微調整し、新しいコードを既存のサーバーに直接デプロイできます。 つまり、これらのサーバーは変更可能です。 作成後に変更できます。 可変サーバーで構成されるインフラストラクチャ自体は、可変、従来型、または(軽蔑的に)職人技と呼ぶことができます。

不変インフラストラクチャは、サーバーが展開された後にサーバーが変更されることのないもう1つのインフラストラクチャパラダイムです。 何らかの方法で何かを更新、修正、または変更する必要がある場合は、適切な変更を加えた共通のイメージから構築された新しいサーバーがプロビジョニングされ、古いサーバーが置き換えられます。 それらが検証された後、それらは使用され、古いものは廃止されます。

不変のインフラストラクチャの利点には、インフラストラクチャの一貫性と信頼性の向上、およびよりシンプルで予測可能な展開プロセスが含まれます。 構成のドリフトやスノーフレークサーバーなど、可変インフラストラクチャで一般的な問題を軽減または完全に防止します。 ただし、これを効率的に使用するには、包括的な展開の自動化、クラウドコンピューティング環境での高速サーバープロビジョニング、およびログなどのステートフルまたはエフェメラルデータを処理するためのソリューションが含まれることがよくあります。

この記事の残りの部分は次のようになります。

  • 可変インフラストラクチャと不変インフラストラクチャの概念的および実際的な違いを説明する
  • 不変のインフラストラクチャを使用する利点を説明し、複雑さを状況に応じて説明します
  • 不変のインフラストラクチャに必要な実装の詳細と必要なコンポーネントの概要を説明します

可変インフラストラクチャと不変インフラストラクチャの違い

可変インフラストラクチャと不変インフラストラクチャの最も基本的な違いは、それらの中心的なポリシーにあります。前者のコンポーネントは、展開後に変更されるように設計されています。 後者のコンポーネントは変更されないままで、最終的には交換されるように設計されています。 このチュートリアルでは、これらのコンポーネントをサーバーとして取り上げますが、コンテナーなど、同じ高レベルの概念を適用する不変のインフラストラクチャを実装する方法は他にもあります。

さらに深く掘り下げるために、サーバーベースの可変インフラストラクチャと不変インフラストラクチャの間には、実用的および概念的な違いがあります。

概念的に言えば、2種類のインフラストラクチャは、サーバーの処理方法が大きく異なります(例: 作成、維持、更新、破棄)。 これは一般的に「ペット対牛」の例えで説明されます。

実際には、可変インフラストラクチャは、仮想化やクラウドコンピューティングなど、不変インフラストラクチャを可能かつ実用的にするコアテクノロジーよりも前の、はるかに古いインフラストラクチャパラダイムです。 この歴史を知ることは、2つの概念の違いと、現代のインフラストラクチャでどちらか一方を使用することの意味を文脈化するのに役立ちます。

次の2つのセクションでは、これらの違いについて詳しく説明します。

実用的な違い:クラウドを採用する

仮想化とクラウドコンピューティングが可能になり、広く利用できるようになる前は、サーバーインフラストラクチャは物理サーバーを中心としていました。 これらの物理サーバーは、作成に費用と時間がかかりました。 新しいハードウェアを注文し、マシンを構成してから、 colo または同様の場所にインストールするのに時間がかかるため、初期セットアップには数日または数週間かかる場合があります。

可変インフラストラクチャの起源はここにあります。 サーバーの交換コストが非常に高かったため、ダウンタイムをできるだけ少なくして、実行していたサーバーをできるだけ長く使用し続けることが最も実用的でした。 これは、定期的な展開と更新だけでなく、問題が発生した場合のアドホックな修正、微調整、およびパッチについても、多くの変更が行われたことを意味します。 頻繁に手動で変更すると、サーバーの複製が困難になり、各サーバーがインフラストラクチャ全体のユニークで壊れやすいコンポーネントになる可能性があります。

仮想化とオンデマンド/クラウドコンピューティングの出現は、サーバーアーキテクチャのターニングポイントを表しています。 仮想サーバーは、大規模であっても安価であり、数日または数週間ではなく、数分で作成および破棄できました。 これにより、構成管理またはクラウドAPI を使用して新しいサーバーを迅速に、プログラムで、自動的にプロビジョニングするなど、新しい展開ワークフローとサーバー管理手法が初めて可能になりました。 新しい仮想サーバーを作成する速度と低コストが、不変性の原則を実用的なものにします。

従来の可変インフラストラクチャは、元々、物理サーバーの使用によって管理で何が可能かが決定されたときに開発され、テクノロジーが時間の経過とともに向上するにつれて開発が続けられました。 展開後にサーバーを変更するというパラダイムは、現代のインフラストラクチャでは依然として一般的です。 対照的に、不変のインフラストラクチャは、クラウドコンピューティングの仮想サーバーなどのアーキテクチャコンポーネントの高速プロビジョニングを仮想化ベースのテクノロジーに依存するように最初から設計されました。

概念の違い:ペットと牛、雪片とフェニックス

クラウドコンピューティングが進歩させた基本的な概念の変更は、サーバーを使い捨てと見なすことができるということでした。 物理サーバーの廃棄と交換を検討することは非常に非現実的ですが、仮想サーバーを使用すると、それが可能であるだけでなく、簡単かつ効率的に行うことができます。

従来の可変インフラストラクチャのサーバーは、常に実行し続ける必要のある、かけがえのない独自のシステムでした。 このように、彼らはペットのようでした:一種の、他に類を見ない、そして手で世話をされました。 1つを失うことは壊滅的である可能性があります。 一方、不変のインフラストラクチャ内のサーバーは使い捨てであり、自動化されたツールを使用して複製または拡張するのが簡単です。 このように、彼らは牛のようです:個人がユニークまたは不可欠ではない群れの多くの1つ。

ペットを最初に適用したRandyBiasと 牛のクラウドコンピューティングへのアナロジー:

古いやり方では、サーバーをペットのように扱います。たとえば、メールサーバーのBobです。 ボブが倒れた場合、それはすべてハンズオンデッキです。 CEOは彼の電子メールを受け取ることができず、それは世界の終わりです。 新しい方法では、サーバーは群れの牛のように番号が付けられます。 たとえば、www001からwww100です。 1台のサーバーがダウンすると、サーバーは取り戻され、撃たれ、回線上で交換されます。

サーバーの処理方法の違いの意味を説明するもう1つの同様の方法は、スノーフレークサーバーとフェニックスサーバーの概念を使用することです。

スノーフレークサーバーはペットに似ています。 これらは手作業で管理され、頻繁に更新され、適切な場所で調整されるサーバーであり、独自の環境をもたらします。 Phoenixサーバーは牛に似ています。 これらは常にゼロから構築され、自動化された手順で簡単に再作成(または「灰から立ち上がる」)できるサーバーです。

不変のインフラストラクチャは、ほぼ完全に牛またはフェニックスサーバーで構成されていますが、可変のインフラストラクチャでは、一部(または多く)のペットまたはスノーフレークサーバーが使用できます。 次のセクションでは、両方の影響について説明します。

不変のインフラストラクチャの利点

不変のインフラストラクチャの利点を理解するには、可変のインフラストラクチャの欠点をコンテキスト化する必要があります。

変更可能なインフラストラクチャ内のサーバーは、構成のドリフトに悩まされる可能性があります。これは、文書化されていない場合、即座の変更により、サーバーの構成が相互に、およびレビューされ、承認され、最初に展開された構成からますます分岐するようになります。 これらのますますスノーフレークのようなサーバーは、複製と交換が難しく、スケーリングや問題からの回復などが困難になっています。 問題を複製してデバッグすることでさえ、実稼働環境に一致するステージング環境を作成することが難しいため、困難になります。

サーバーのさまざまな構成の重要性または必要性は、多くの手動変更の後で不明確になるため、サーバーのいずれかを更新または変更すると、意図しない副作用が発生する可能性があります。 最良の場合でも、既存のシステムに変更を加えることが機能することは保証されていません。つまり、変更に依存する展開では、サーバーが失敗したり、不明な状態になるリスクがあります。

これを念頭に置いて、不変のインフラストラクチャを使用する主な利点は、展開の単純さ、信頼性、および一貫性です。これらはすべて、多くの一般的な問題点と障害点を最終的に最小化または排除します。

正常なサーバー状態と展開の失敗の減少

不変のインフラストラクチャでのすべての展開は、検証されバージョン管理されたイメージに基づいて新しいサーバーをプロビジョニングすることによって実行されます。 結果として、これらのデプロイメントはサーバーの以前の状態に依存せず、その結果、サーバーが原因で失敗することはなく、部分的にしか完了しません。

新しいサーバーがプロビジョニングされると、使用する前にテストできるため、ロードバランサーの更新など、実際の展開プロセスを1回の更新に減らして、新しいサーバーを利用できるようにします。 つまり、デプロイメントは atomic になります。正常に完了するか、何も変更されません。

これにより、展開の信頼性が大幅に向上し、インフラストラクチャ内のすべてのサーバーの状態が常に把握されるようになります。 さらに、このプロセスにより、青緑色の展開またはローリングリリースを簡単に実装できるため、ダウンタイムが発生しません。

構成のドリフトやスノーフレークサーバーはありません

不変のインフラストラクチャでのすべての構成変更は、更新されたイメージをドキュメントでバージョン管理にチェックインし、自動化された統合展開プロセスを使用して、そのイメージで置換サーバーを展開することによって実装されます。 サーバーへのシェルアクセスが完全に制限される場合があります。

これにより、スノーフレークサーバーと構成のずれのリスクが排除され、複雑なセットアップや再現が難しいセットアップが防止されます。 これにより、誰かが理解の不十分な本番サーバーを変更する必要が生じ、エラーが発生してダウンタイムや意図しない動作が発生するリスクが高くなることも防止されます。

一貫したステージング環境と簡単な水平スケーリング

すべてのサーバーが同じ作成プロセスを使用するため、展開のエッジケースはありません。 これにより、本番環境の複製が簡単になり、面倒なステージング環境や一貫性のないステージング環境が防止されます。また、インフラストラクチャに同一のサーバーをシームレスに追加できるため、水平スケーリングが簡素化されます。

単純なロールバックおよびリカバリプロセス

バージョン管理を使用してイメージ履歴を保持することも、本番環境の問題の処理に役立ちます。 新しいイメージの展開に使用されるのと同じプロセスを使用して、古いバージョンにロールバックすることもできます。これにより、復元力が向上し、ダウンタイムを処理する際の回復時間が短縮されます。

不変のインフラストラクチャ実装の詳細

不変のインフラストラクチャには、特に従来の可変のインフラストラクチャと比較して、実装の詳細にいくつかの要件とニュアンスがあります。

不変性の主要な原則に従うだけで、自動化、ツール、またはソフトウェア設計の原則に依存しない不変のインフラストラクチャを実装することは技術的に可能です。 ただし、以下のコンポーネント(大まかに優先順位が高い)は、大規模な実用性のために強くお勧めします。

  • クラウドコンピューティング環境または別の仮想化環境(コンテナなど)のサーバー。ただし、以下の他の要件がいくつか変更されます)。 ここで重要なのは、カスタムイメージからの高速プロビジョニングと、APIなどを介した作成と破棄の自動管理を備えたインスタンスを分離することです。

  • デプロイメントパイプライン全体の完全自動化、理想的には作成後のイメージ検証を含みます。 この自動化を設定すると、このインフラストラクチャを実装するための初期費用が大幅に増加しますが、これは1回限りの費用であり、すぐに償却されます。

  • サービス指向アーキテクチャ。インフラストラクチャを、ネットワークを介して通信するモジュール式の論理的に個別のユニットに分離します。 これにより、同様にサービス指向であるクラウドコンピューティングの製品を最大限に活用できます(例: IaaS、PaaS)。

  • 不変サーバーを含むステートレスで揮発性のアプリケーション層。 ここにあるものはすべて、データを失うことなく(ステートレス)、いつでもすばやく破壊および再構築できます(揮発性)。

  • 永続データレイヤーには、次のものが含まれます。

    • 集中ログ。バージョンやGitコミットSHAを介したイメージの識別など、サーバーの展開に関する追加の詳細が含まれます。 サーバーはこのインフラストラクチャで使い捨て(および頻繁に廃棄)されるため、ログとメトリックを外部に保存すると、シェルアクセスが制限されている場合やサーバーが破棄された後でも、デバッグが可能になります。
    • データベースおよびDBaaS/クラウドデータベースオブジェクトまたはブロックストレージ(クラウド提供または自己管理)などのその他のステートフルまたはエフェメラルデータ用の外部データストア )。 サーバーが揮発性の場合、ローカルストレージに依存することはできないため、そのデータを別の場所に保存する必要があります。
  • エンジニアリングチームと運用チームからの献身が協力し、アプローチにコミットします。 最終製品を単純化するために、不変のインフラストラクチャには多くの可動部分があり、誰もそのすべてを知ることはできません。 さらに、このインフラストラクチャ内での作業のいくつかの側面は、デバッグやシェルアクセスなしでの1回限りのタスクの実行など、新しいものでも、人々の快適ゾーンの外でもかまいません。

これらの各コンポーネントを実装するには、さまざまな方法があります。 いずれかを選択するかどうかは、個人の好みと親しみやすさ、および有料サービスに依存するのではなく、自分で構築するインフラストラクチャの量に大きく依存します。

CI / CDツールは、デプロイメントパイプラインの自動化を開始するのに適した場所です。 構成はDBaaSソリューションのオプションです。 rsyslogおよびELKは、集中ログの一般的な選択肢です。 NetflixのChaosMonkeyは、実稼働環境のサーバーをランダムに強制終了します。これは、最終的なセットアップのための実際の試練です。

結論

この記事では、不変インフラストラクチャとは何か、それと古いスタイルの可変インフラストラクチャとの概念的および実際的な違い、それを使用する利点、およびその実装の詳細について説明しました。

不変のインフラストラクチャへの移行を検討すべきかどうか、いつ検討すべきかを知ることは困難な場合があり、明確に定義されたカットオフまたは変曲点はありません。 開始する1つの方法は、大部分が変更可能な環境で作業している場合でも、構成管理など、この記事で推奨されている設計手法のいくつかを実装することです。 これにより、将来的に不変性への移行が容易になります。

上記のほとんどのコンポーネントを備えたインフラストラクチャがあり、スケーリングの問題に直面したり、展開プロセスの不格好さに不満を感じたりする場合は、不変性がインフラストラクチャをどのように改善できるかを評価する良い機会です。

不変の実装について書いたいくつかの会社( Codeship Chef Koddi Fugue を含む)から詳細を学ぶことができますインフラストラクチャー。