本記事は英語版ブログで公開された記事の翻訳版です。
私は2011年にEngine Yardが買収したPHP PaaS「Orchestra」のオリジナル開発者の1人でした。顧客の多くはPaaSを使うのは初めてで、 それまではたいへん従来的なホスティング環境を利用していました。各種データをFTPサーバーにアップロードしたり、リモートからconfigファイルを編集したりすることに慣れていたのです。Gitが普及しThe Twelve-Factor Appのようなサイトが人気を博している今なお、こういう習慣は広く根付いています。それに拍車をかけているのは、オフザシェルフのPHPアプリの大半がかなり旧式で、未だにそういうデプロイメントシナリオを想定しているという事実です。
しかし、だからといって笑うべきではありません。伝統的なシステム管理は、マシンは物理的なものであるという前提で成り立っています。クラスタにマシンを1台追加するには、まず機材を購入し、オフィスで設定作業を行い、そこからコロケーションデータセンターに運んで設置する必要があるでしょう。それだけでゆうに何週間もかかります。おまけにそのマシンが後で問題を起こしたら、SSH経由で修復に奮闘しなければなりません。それもだめなら、コロケーションデータセンターから運び出して修理なり交換なりせざるをえないでしょう。
私もそんな風にしてサーバーを管理してきました。ええ、今でも覚えています――まだ駆け出しのシステム管理者だった頃は、すべてのサーバーにいちいち凝った名前を付けていたものでした。ダグラス・ホフスタッターの著書『ゲーデル, エッシャー, バッハ：あるいは不思議の環』に出てくるキャラクターにちなんで。メインのApache httpdインスタンスは「亀」で、「アキレス」はSquidをリバースプロキシモードで走らせ、「蟹」はMySQLを実行し、「ランプの精」がSMTPスマートホストでした。どのマシンにもカスタムmotdが、色とりどりのASCIIアートのバナーと、例の本からの引用付きで設定してあったものです。
私は自分の構成のあらゆる部分に個別に手をかけていることが誇りでした。どのマシンも愛情を注いで世話していました。手ずからパッケージをインストールし、設定し、テストして、面倒を見てきたのです。問題が起きれば正常復帰するまで「看病」し、その間も自分が実行したアクションを逐一記録することを忘れませんでした。もし災害に見舞われたとしても、すべてを一から構築し直すことだってできたでしょう。新しいサーバーが届くまで何週間もかかるとなれば、保守には細心の注意を払うようになるものです。
けれども、クラウドにはこういうやり方はあてはまりません。
「ペットと家畜」の例えの発見
仮想化技術の登場で、物理ハードウェアと格闘したり、自分の足で出向いたりする必要はなくなりました。今ではサーバーに障害が起きても、管理者コンソールから終了させるだけのことです。その後、新しいサーバーをサーバーイメージのカタログから起動すれば済みます。数週間どころか、数分しかかかりません。
これを実現するために、ほとんどのプロバイダはシェアードナッシング アーキテクチャ、ステートレス ファイルシステム、構成管理の自動化や再試行といったコンセプトを軸にクラウドを構築しています。しかし、伝統的なホスティング環境から移行するとなると、こうしたコンセプトは何かと窮屈に感じられるものです。私は前々から、顧客に違いをうまく説明する方法を模索してきました。なにより、「なぜ」そうしたほうがうまくいくのかを納得してもらう必要がありました。
そのときMassimoがIT 2.0ブログでこんな画像を紹介していたのが目に留まりました。
プレ仮想化モデルとポスト仮想化モデルの違いは、ペットと家畜の違いに例えることができます。ペットは「長靴猫」とか（私の場合だと、亀とかアキレスとか）愛称を付けられます。それぞれに個性があり、人間が愛情をこめて手ずから育て、世話をします。スケールアップしたければ大きく育てます。病気になれば、健康を取り戻すまで看病します。いっぽう家畜は「vm0042」などといった実用的な識別名を与えられます。互いの個体差はほとんどありません。スケールアップしたければ頭数を増やします。病気になったら、他の元気な家畜と入れ替えるだけのことです。
Massimoが言うように、この例えで考えてみると、自分が扱っているのがペットか家畜かはすぐに判ります。 今、あなたのサーバーが何台かオフラインになったら、どういう事態が起きますか？そうなってもエンドユーザーは何も気づかないと思うなら、あなたは「家畜」を扱っているわけです。エンドユーザーに大きな混乱が起きると思うなら、あなたのサーバーは「ペット」です。
この例えはアーキテクチャを考える際のテンプレートにもなります。サーバーを見て「もしこいつがダメになったら？」と想像してみてください。「すぐ終了して新しいやつと入れ替えれば済むことだ」と思えるなら、理想的です。バックアップやデータダンプや、七面倒くさい手動再構成なんかが頭に浮かんだら、それは赤信号と考えるべきでしょう。
とはいえ、ポスト仮想化モデルはまだ比較的新しい概念で、当面はレガシーアプリが数多く出回り続けることでしょう。システム構成によっては、ペットと家畜の両方をサーバー農場、もといサーバーファームに置く必要も出てきます（すみません、どうしてもこれをいっぺん言ってみたくって）。幸い、Engine Yardは両方をサポートします。ペットを飼う必要があるなら、ペットを飼えます。その点については私たちもお手伝いしますし、なんなら代わりにお世話もいたします。ただ、私たちのプラットフォームの高度な機能をフル活用し、クラウドが提供する真のメリットを享受するためには、やはり家畜への切り替えを検討されることをおすすめします。（もちろんその場合もお手伝いさせていただきます！）
今後の展開
ペットサーバーと家畜サーバーの違いが分かったら、次の疑問はどうやって家畜サーバーを作るか、なによりそれ用のアプリケーションはどう開発すればいいのか、という点でしょう。これを読んでいるあなた、ツイていますよ。この記事はまさに、その点を説明する連載第1弾なのです。
次回の記事では、サーバーを構成してから起動するという、いささか直観にそぐわない概念が、実は可能であるばかりか、クラウドサーバーのデプロイメントに絶大なメリットをもたらすことを解説します。
「ペットと家畜」の例え話はお楽しみいただけたでしょうか。もうご存じの話でしたか？それともまったく初耳でしたか？この例えはあなたの経験にもあてはまりますか、それとも別の例えができるでしょうか？ぜひ皆さんの感想を聞かせてください。下のコメントフォームからどうぞ。
(翻訳:福嶋美絵子)