IT 技書の森

ペットと家畜

サーバーを個別に管理する「ペット」から、使い捨て可能な「家畜」へ移行するインフラ運用の考え方

インフラクラウド

ペットと家畜とは

「ペットと家畜 (Pets vs Cattle)」は、サーバーの管理方針を表すメタファーだ。Microsoft の Bill Baker が 2012 年頃に提唱し、クラウドネイティブの設計思想を象徴する概念として広く浸透した。

  • ペット (Pets): 名前を付けて大切に育てるサーバー。web-server-01、db-master のように個別に管理し、障害が起きたら手動で修復する。サーバーが「病気」になったら「治療」する
  • 家畜 (Cattle): 番号で管理する使い捨てのサーバー。障害が起きたら破棄して新しいものを起動する。個体の識別は不要で、群れ全体の健康を管理する

ペットモデルの問題点

オンプレミス時代のペットモデルには、以下の構造的な問題があった。

  • スノーフレークサーバー: 長期間の手動変更が蓄積し、同じ構成を再現できない「雪の結晶」状態になる。構築手順書があっても、暗黙の設定変更が反映されていない
  • 障害復旧の遅延: サーバーの修復に数時間〜数日かかる。ハードウェア交換、OS 再インストール、アプリケーション設定の復元が必要
  • スケールの限界: 負荷増加時に新しいサーバーを追加するのに数週間かかる (物理サーバーの調達、ラッキング、ネットワーク設定)
  • 属人化: 特定のサーバーの設定を知っているのが 1 人だけ、という状況が生まれやすい

家畜モデルへの移行

クラウドの登場により、サーバーを API 1 つで起動・破棄できるようになった。これが家畜モデルを現実的にした。

観点 ペット 家畜
命名 個別の名前 (web-01) 自動採番 (i-0a1b2c3d)
障害対応 修復する 破棄して再作成する
構成管理 手動 + 手順書 IaC (CloudFormation, Terraform)
スケーリング 手動で追加 Auto Scaling で自動
状態 ローカルに保持 外部ストレージに分離
復旧時間 数時間〜数日 数分

家畜モデルの前提条件

家畜モデルを採用するには、以下の設計原則を満たす必要がある。

  • ステートレス設計: アプリケーションサーバーにローカル状態を持たない。セッション情報は DynamoDB や ElastiCache に、ファイルは S3 に保存する
  • IaC による再現性: サーバーの構成をコードで定義し、いつでも同一の環境を再作成できる
  • ヘルスチェックと自動復旧: ロードバランサーのヘルスチェックで異常を検知し、Auto Scaling が自動的にインスタンスを入れ替える
  • イミュータブルデプロイ: 既存サーバーを更新するのではなく、新しいサーバーを起動してトラフィックを切り替える

サーバーレスは「家畜」の究極形

Lambda はこの考え方の究極形だ。実行環境を意識する必要すらなく、コードを渡せばインフラが自動的にスケールする。サーバーの存在自体が抽象化され、「ペットか家畜か」という議論すら不要になる。

ペット (物理サーバー)
  → 家畜 (EC2 Auto Scaling)
    → 群れすら不要 (Lambda)

よくある誤解

「家畜モデル = サーバーを雑に扱ってよい」ではない。個々のサーバーは使い捨てだが、システム全体の信頼性は高く保つ必要がある。Auto Scaling の設定、ヘルスチェックの閾値、デプロイ戦略 (Blue/Green, Rolling) を適切に設計しなければ、家畜モデルでも障害は発生する。

また、データベースサーバーは完全な家畜にはなりにくい。RDS のマルチ AZ 構成はフェイルオーバーを自動化するが、データの永続性という性質上、コンピュートノードほど気軽に破棄・再作成はできない。

「The Phoenix Project」(Gene Kim ら著) や「Infrastructure as Code」(Kief Morris 著) で、ペットから家畜への移行が詳しく論じられている。

ペットと家畜については関連書籍でも詳しく扱われている。

関連用語