構成同期化

自動化された構成ツール（CFEngine、Puppet、Chefなど）を使用すると、サーバーの構成要素を記述するレシピを提供することで、SnowflakeServerを回避できます。構成同期化は、これらの仕様を定期的なスケジュールで、または変更時に、サーバーのライフサイクル全体を通じて継続的に適用します。ツール外部でサーバーに変更を加えた場合、次回サーバーが同期されたときに、中央で指定された構成にロールバックされます。構成変更が必要な場合は、構成仕様（レシピ、マニフェスト、または特定の構成ツールが呼ぶもの）で行われ、インフラストラクチャ全体にあるすべての関連サーバーに適用されます。

理論的には、サーバーが作成された後は、構成同期化によってサーバーが最新の状態に保たれ、アップグレードとパッチが適用され、潜在的に長いライフタイムにわたって構成ドリフトが防止されます。

しかし実際には、現在の自動化された構成管理ツールを使用してサーバーを完全に一貫性のある状態に維持することは実現可能ではなく、時間の経過とともに構成同期化は不一致につながります。[1]

自動化ツールによって管理されるサーバー構成の各要素は、レシピまたはマニフェストの作成、テスト、および保守に作業が必要です。これらのツールを使用して、一般的なサーバーのすべての要素を管理しようとするのは、単に妥当ではありません。それらの数は多すぎます。そして、指定する要素が増えるごとに、それらの間の潜在的な相互作用、統合、および依存関係により、作業量は非線形に増加します。

ソフトウェアパッケージは、さらに多くのパッケージに依存する可能性があるため、特に困難です。yum、apt-get、gemsなどのツールは、依存関係を自動的に解決し、リポジトリからインストールします。そのため、システム上の多数のパッケージは暗黙的にのみ管理されており、予告なしに変更される可能性があります。インストールされているソフトウェアパッケージのバージョンと依存関係をマイクロマネジメントできますが、関係するパッケージの数からすると、これは手に負えない作業です。

サーバーに存在させたいものを管理するのが困難な場合、存在させたくないものを管理することは、事実上無限の数があるため、さらに困難です。現在の構成管理ツールでは、検出された場合に削除する必要がある各ファイル、パッケージ、またはその他の要素を明示的にリストする必要があります。これは、一部のサーバーに手動で追加のものが追加され、一貫性のない予期しない動作が発生することを意味します。

実際には、自動化された構成ツールを使用しているユーザーは、サーバーの構成可能サーフェスエリアの100％を指定しなくても十分にうまく機能しています。チームは、自動化された構成に80/20ルールを適用し、注意力の80％（または95％に近い）を、特定のニーズに最も関連するシステムの20％（または5％）の定義に集中し、残りをベースOSによってインストールされたデフォルトに任せます。そのため、システムの大部分は自動化された構成の対象外であり、一般的にこれは機能します。残念ながら、機能しない場合（自動化ツールによって管理されていないシステムの一部が問題を引き起こす場合）、その影響は予期せず、追跡が困難になる可能性があります。

この問題は、サーバーのライフスパンが長くなるにつれて、そして変更の頻度が高まるにつれて悪化します。サーバーが稼働している時間が長くなると、特に新しいサーバーと比べて、他のサーバーから逸脱する可能性が高くなります。

この問題により、一部の人はPhoenixServerを使用するようになります。サーバーのライフスパンを短くし、ベースイメージから新しいサーバーを頻繁に再構築することで、構成ドリフトの可能性を小さく抑え、実際に必要な以上のサーバー構成を管理ツールで指定するオーバーヘッドを回避します。フェニックスサーバーを論理的な結論に導くとImmutableServerになり、ライフスパン中にサーバーに加えられた変更を回避します。