イミュータブルサーバー
2013年6月13日
自動化された構成ツール(CFEngine、Puppet、Chefなど)を使用すると、サーバーの構成方法を指定し、新規および既存のマシンをコンプライアンスに準拠させることができます。これにより、脆弱なSnowflakeServersの問題を回避できます。このようなツールは、必要に応じて削除および再構築できるPhoenixServersを作成できます。イミュータブルサーバーはこのアプローチの論理的な結論であり、一度デプロイされると変更されることはなく、新しい更新されたインスタンスに置き換えられるだけです。
自動化された構成ツールは、通常、ConfigurationSynchronizationで使用されます。ここでは、サーバーを潜在的に長時間実行し、繰り返し構成を適用して、最新の仕様に合致させます。理論的には、サーバーは無限に実行されることが許され、完全に整合性があり、最新の状態に保たれます。実際には、サーバーの構成を完全に管理することは不可能であるため、構成ドリフトと、実行中のサーバーへの予期しない変更の可能性が大きくなります。
ここでPhoenixServerが役立ちます。

ベースイメージからサーバーを頻繁に破棄して再構築することにより、サーバーの要素の100%が既知の状態にリセットされます。詳細な構成仕様を指定および維持するために途方もない時間を費やす必要はありません。
フェニックスを使用するようになると、構成管理の焦点はベースイメージの管理に移ります。修正、変更、更新は、実行中のシステムではなく、ベースイメージに適用されます。新しい更新が必要になるたびに、ベースインスタンスを変更し、自動化されたテストハーネスを実行します。これらの手順をパスしたときにのみ、新しいサーバーを作成します。
したがって、フェニックスサーバーの完全な状態は、ベースイメージ+自動化された構成管理+データ[1]の組み合わせから構築され、自動化された構成でサーバーの100%を管理するという圧力が軽減されます。
しかし、短い寿命の間、サーバー上で構成管理の更新を継続できますが、そうする価値は低くなります。実際、実行中のシステムに変更を加えるとリスクが生じるため、そうしないことには大きな価値があります。
これは、イミュータブルサーバー[2]に自然とつながります。

十分にテストされたベースイメージからサーバーインスタンスをスピンアップしたら、構成管理ツールを実行しないでください。これにより、インスタンスへのテストされていない変更の可能性が生じるためです。必要な変更はすべてベースイメージに加え、テストしてからロールアウトします。変更のないサーバーは削除して置き換えられます。
これが馴染みのあるように聞こえるなら、それは継続的インテグレーションと継続的デリバリーの実践に従っているためです。ソフトウェアの継続的デリバリーでは、特定のバージョンのアプリケーションをデプロイ可能なアーティファクトに一度だけコンパイルし、すべての環境で一貫して構築されたアプリケーションをデプロイおよび実行していることを知っている方が安全です。イミュータブルサーバーでは、ベースイメージに各変更を加え、そのイメージから作成されたすべてのインスタンスが一貫していることを知ることができます。
サーバーロールのインスタンス間の主な違いは、サーバーの外部から取得する必要がある構成設定です。たとえば、ほとんどの仮想化およびクラウドプラットフォームでは、新しいインスタンスをプロビジョニングするときにメタデータ値を設定する方法を提供しており、実行中のサーバーで読み取ることができます。新しいサーバーは、Zookeeperなどの中央レジストリから構成値を取得することもできます。
イミュータブルサーバーでは、インスタンスごとの構成項目の数と範囲を最小限に抑え、可能な場合は自動化されたテストを通じてこれらの変更を実行することをお勧めします。
データの処理
サーバーが使い捨ての場合、その上に存在するデータは多くの場合使い捨てではありません。フェニックスまたはイミュータブルサーバーを実装する際には、サーバーが破棄および作成されるときに永続化する必要があるデータ、および追加のサーバーを追加してスケーリングするためにレプリケートする必要があるデータを検討する必要があります。
実行時に必要ないが価値のあるデータは、インスタンスから送信できます。たとえば、ログファイルを中央のsyslogサーバーに送信します。NFSなどの共有ファイルシステムにより、サーバーでファイルを利用できるようになり、SAN上に存在する可能性があります。クラウドプラットフォームは一般的に、古いサーバーが破棄されたときに新しいサーバーインスタンスにアタッチできる、またはクラスターをスケーリングするときにレプリカに迅速に複製してアタッチできる、AWS EBSボリュームなどのマウント可能なストレージデバイスを提供します。多くの場合、AmazonのRDSデータベースサービスなど、他の人が維持するサービスに責任を委ねることができます。
参考資料
Netflixは、ImmutableServerパターンを使用する最前線に立ってきましたが、彼らがその用語を使用したことは認識していません。彼らは、AmazonのAWSクラウドで使用するためのAMIインスタンスを管理するために開発したAminatorツールをオープンソース化し、このパターンを使用する方法が経験とともにどのように進化してきたかについてブログに投稿しました。興味深いことに、新しいインスタンスをインスタンス化する速度は、自動スケーリングと復旧に役立つため、彼らにとって重要な推進力となっています。
注記
1: データには、データベースファイルやその他のアプリケーションで管理されるデータ、ランタイム状態、ログファイルなどの他のランタイムで生成されるデータ、および外部から提供される構成など、さまざまなものが含まれます。
2: 同僚のBen Butler-Coleが、Thoughtworksの内部メーリングリストでこのパターンに「イミュータブルサーバー」という用語を考案しました。