Habrに関する多くの記事で、サーバーを「ペット」と「牛」に分けることが言及されています。 この用語は、オープンソースの活動家であり、CouchDBの共著者であるNoah Slaterの興味深い記事から引用したものです。 英語の「牛」、「産業畜産で飼育された動物」の良い翻訳を作成できなかったので、カットの下に大きな猫と猫の翻訳があります。 とても大きい。
私は、2011年にEngine Yardが買収したOrchestra：PHP PaaSを作成した開発者の1人でした。 クライアントの多くは、従来のホスティングを使用する前にPaaSを初めて使用しました。 FTP経由でファイルをアップロードし、リモート設定を編集する習慣がありました。 gitやThe Twelve-Factor Appのようなサイトの人気にもかかわらず、これらのプラクティスは今でも一般的です。 このようなアプローチの普及は、多くの商用PHPプロジェクトが非常に古く、そのような展開シナリオを暗示しているという事実によっても支持されました。
どんなに馬鹿げていても、従来のシステム管理は物理サーバーでの作業に焦点を合わせていました。 新しいマシンをクラスターに追加する場合、最初に購入し、オフィスで構成してから、インストールのためにデータセンターに移送するだけです。 星の不利な位置でのこのような操作には数週間かかる場合があります。 また、このマシンで将来何かが発生した場合は、SSHで修正するためにあらゆる努力をする必要があります。 星の位置が再び幸運でない場合は、直接データセンターに行き、その場で鉄片を処理する必要があります。
それが私が私のサーバーで働いた方法です。 歯のシステム管理を試みたばかりで、すべてのサーバーにペットのようなクールな名前が付けられていたときのことを今でも覚えています。 ダグラス・ホフスタッターの本のキャラクターで「ゴーデル、エッシャー、バッハ：この無限の花輪」と呼びました。 「Turtle」はhttpdを使用するメインのApacheサーバーで、「Achilles」はリバースプロキシモードでSquidに、「Crab」はMySQLを、「Genie」はSMTPゲートでした。 各車には、マルチカラーのASCIIアートと本からの引用を含む修正されたmotdが含まれていました。
私は自分のプロジェクトの展開をどのように部分に分割したかを非常に誇りに思っていました。 私はそれぞれの車を愛で大事にしました。 それらに更新プログラムをインストールし、管理ビジネスで必要な構成、テスト、およびその他の多くのことを実行しました。 問題が発生した場合は、それらを処理し、稼働状態に戻し、実行したすべての手順を注意深く記録しました。 致命的な故障が発生した場合、これらのレコードを使用してそれらを最初から復元できます。 新しいサーバーのインストールに数週間かかる場合、非常に大きな注意を払ってそれらを扱います。
クラウドシステムでは、これはまったくそうではありません。
類推を検索する
仮想化の出現により、ハードウェアを操作してどこかに行く必要がなくなりました。 実際、多くの場合、最も簡単な解決策は、管理コンソールから障害のあるサーバーを単純に特定することです。 その後、サーバーイメージディレクトリから再起動します。 今では数分ではなく、数分かかります。
これを可能にするために、ほとんどのクラウドプロバイダーソリューションは、「共有なし」アーキテクチャ、ステートレスファイルシステム、自動繰り返し展開などの概念に基づいています。 ただし、ホスティングに従来のアプローチを使用している場合、これらの概念はすべて制限が厳しすぎるように見えるかもしれません。 長い間、アプローチの違いをクライアントに説明する最善の方法を見つけようとして苦しみました。 実用的な観点から、新しい方法が優れている理由を正当化することは最も困難でした。
しかし、ある時点で、Massimoから次のことが紹介されました。
このスライドは、2012 CERNカンファレンスでのGavin McCance によるプレゼンテーションからの抜粋です。 ただし、The Register は 、類推の最初の著者がMicrosoftのBill Bakerであることを示しています。
仮想化時代の前後の展開の違いは、家畜と牛の違いと比較できます。 ペットには、「tomcat」（私の場合は「Turtle」、「Achilles」など）など、愛情を込めて選ばれた名前が付けられます。 彼らは成長し、世話をします。 それらは垂直に拡大し、大きくなります。 そして、彼らが病気になったら、あなたは彼らを治療します。 牛では、そうではありません。 名前の代わりに、「vm0042」などの機能識別子があります。 それらは実質的に互いに同一です。 それらは、その数を増やすことによって水平にスケーリングします。 そして、それらのうちの1つが病気になった場合、あなたは同じものを別のものと交換するだけです。
Massimoが示すように、この類推に基づいて、「ペット」サーバーと「牛」サーバーのどちらを扱っているかを判断するのは非常に簡単です。 自問してみてください。サーバーのいくつかが現在利用できなくなったらどうなりますか？ これがユーザーになんらかの影響を与えない場合、おめでとうございます-あなたは自由に牛の群れを飼っています。 これがサービスの誤動作につながる場合は、ペットで作業しています。
同じ原則が、アーキテクチャを評価するためのテンプレートの根底にあります。 サーバーを見て、自問してください。このサーバーが「病気になった」場合はどうすればよいですか？ 正解：すぐに破棄して、まったく同じものに置き換えます。 バックアップ、データダンプ、スケジュールされたダウンタイム、または退屈な手動構成が心配な場合、これはアーキテクチャに関する「鐘」です。
ただし、仮想化後の展開モデルはまだ比較的若く、今後多くのレガシーアプリケーションが必要になります。 複雑なアーキテクチャにより、ペットと牛でさえ同じサーバーファームに同時に住むことができます（申し訳ありませんが、抵抗できませんでした）。 Engine Yardがそれらとそれらの両方をサポートしているのは良いことです。
著者について
ノア・スレーターは、ベルリンに住んでいるイギリス人で、1999年以来オープンソースに従事しています。 彼はDebian、GNU、Free Software Foundationに貢献しました。 執筆時点で、彼はApache Software Foundationのメンバーです。 彼が取り組んでいる主なプロジェクトは、NoSQL運動を開始したドキュメント指向のデータベースであるApache CouchDBです。 彼はまた、新しいプロジェクトの参加者にオープンソースの操作方法を教えることで、Apache Incubatorを支援しています。
ここから牛の写真が撮られています。