フェニックスサーバー

2012年7月10日

ある日業務に関する認定サービスを開始する空想をしました。認定評価は、私と同僚が企業のデータセンターに現れ、野球バット、チェーンソー、ピストル水鉄砲で重要な本番用サーバーを調べ回ることでした。評価はこの操作チームがアプリケーションをすべて再び稼働させるのにかかる時間を基準とします。

これはばかげた空想かもしれませんが、ここには知恵の欠片があります。野球バットは使わないほうがいいにしても、サーバーを定期的にバーチャルに燃やすのは良い考えです。サーバーが不死鳥のように、定期的に灰から蘇るべきです。[1]

フェニックスサーバーを使用する主な利点は、構成のドリフトを回避することです。システム構成にアドホックな変更があり、記録されません。ドリフトはスノーフレークスサーバーにつながる通りなので、大きな雪かき機なしに行くべきではありません。

ドリフトに対抗する方法の1つは、既知の基準構成でサーバーを自動的に再同期するソフトウェアを使用することです。PuppetやChefなどのツールにはその機能があり、定義された構成を自動的に再適用します。[2]制限は、このような構成を再適用することで、ツールが制御しているエリアでのみドリフトを特定できるという点です。これらのエリア以外の構成ドリフトは修正されません。しかし、フェニックスは一から始めます。そのため、ソース構成からあらゆるドリフトを拾い上げます。

これは、構成を再適用することが役に立たないという意味ではありません。通常はサーバーを燃やすよりも速く、混乱が少ないからです。しかし、これらの両方の戦略を使用してスノーフレークを排除することが不可欠です。

さらなる詳しい情報

Netflixには、システムの回復力をテストするためにサーバーをランダムに燃やすChaos Monkeyがあります。

注意

1: 私の同僚Kornelis Sietsmaは、社内ディスカッションリストで「フェニックスサーバー」という用語を考案しました。

2: これらのツールはフェニックスサーバーの構築にも優れています。