Ansibleか、Chefか？──SREが語る「サーバー構成管理」の真の選定基準
「IaCのトレンドはAnsibleだ」と囁かれて久しい。しかし、大規模インフラの深淵を覗き続けてきた者からすれば、その問いはあまりに浅い。
ツール選びとは、単なる「書きやすさ」の比較ではない。それは、「君たちのインフラが、どの程度の抽象度で、どれほどの規模を、どのような頻度で更新し続けるのか」という、アーキテクチャの生存戦略そのものだ。
今日は、AnsibleとChefのどちらを武器にすべきか、現場のエンジニアが血を流して得た知見を元に、その境界線を解き明かす。
—
1. 思想の衝突：プル型（Chef） vs プッシュ型（Ansible）
この二つの最大の違いは、「状態維持の主体」がどこにあるかだ。
- Ansible（プッシュ型）: 制御ノードがターゲットにSSHし、コマンドを叩く。シンプルで即時性が高いが、制御ノードが死ねば何も動かない。
- Chef（プル型）: エージェント（Chef Infra Client）が定期的にサーバー上で動作し、レシピをPullして「自分の状態」を修正する。
プロの視点:
Ansibleは「その瞬間の状態」を合わせるのに適しているが、Chefは「常に理想の状態を維持する（Config Driftの自動修復）」という自己治癒力において圧倒的だ。数千台のノードが勝手に自分の設定を維持し続けるChefの安定感は、一度味わうと戻れない中毒性がある。
—
2. 現場で「差」が出る実務テクニック
【Ansible】開発スピードを加速する極限設定
Ansibleの最大の弱点は「実行速度」だ。これを克服しなければ、CI/CDパイプラインはボトルネックと化す。
- 神設定：`ansible.cfg`のチューニング
[defaults]
# SSH接続のオーバーヘッドを削減。パイプラインモードで実行速度を劇的に向上
pipelining = True
# 実行速度を上げるための並列実行数（大規模環境ではこの数値を増やす）
forks = 50
# 不要な統計表示をオフにして出力をクリーンに
stdout_callback = yaml
- VSCode神プラグイン: `Ansible` (Red Hat公式)。YAMLのバリデーションはこれ無しではあり得ない。
【Chef】大規模インフラを支配する「Policyfile」
Chefのレガシーな `chef-repo` 運用で疲弊しているなら、今すぐ `Policyfile` に移行せよ。
- Policyfileのベストプラクティス:
従来の `environments` や `roles` の複雑な依存関係を排除し、完全な固定化を行う。
# Policyfile.rb – これ一つで構成を完結させる
name ‘web-server’
default_source :supermarket
# バージョンを固定し、冪等性を完璧に担保する
cookbook ‘nginx’, ‘~> 12.0’
run_list ‘nginx::default’
—
3. なぜ「大規模」になるとChefが選ばれるのか
Ansibleは小規模〜中規模、またはステートレスな構成では最強だ。しかし、以下の条件に直面したとき、Ansibleの限界が訪れる。
1. ネットワークが不安定なマルチリージョン: 制御ノードからの長時間のSSH接続はタイムアウトのリスクがある。
2. Config Drift（設定の乖離）: 誰かが手動で設定を変えてしまった際、ChefならChef Clientが次回のポーリングで即座に元に戻す。Ansibleは「再実行」をトリガーしない限り何も起きない。
3. 複雑な条件分岐: Rubyで書けるChefは、複雑なロジックをクラスやモジュールにカプセル化できる。AnsibleのJinja2テンプレートで複雑な条件分岐を書くと、すぐに地獄を見る。
—
4. 現場の要件別：ツール選定ガイド
| 選定項目 | Ansibleを選択すべきケース | Chefを選択すべきケース |
| :— | :— | :— |
| チーム構成 | インフラ専任が少ない、開発者が片手間で書く | 専任SREがいる、Rubyが読み書きできる |
| サーバー台数 | 100台未満 | 数百〜数千台規模 |
| 変化の頻度 | 突発的なデプロイが多い | 常に一定の状態を保つ必要が高い |
| 学習コスト | 低い（YAMLのみ） | 高い（Rubyの知識が必要） |
結論：今、どちらを学ぶべきか？
- 「とりあえずIaCを始めたい」なら迷わずAnsible。
今のモダンなインフラ（Terraformでリソース構築、Ansibleで構成管理）の基本形を学ぶのが最短距離だ。
- 「インフラエンジニアとして大規模システムの堅牢性を担保したい」ならChefを深掘れ。
Chefの「コードによるシステム管理」の思想は、複雑なサーバー群を「一つのソフトウェア」として扱うための極意を教えてくれる。
最後に、プロからのアドバイス：
ツールに宗教戦争を挑むな。重要なのは「IaCコードがレビュー可能か」「手動作業が徹底的に排除されているか」だ。
設定ファイルは、常にバージョン管理し、誰が読んでも意図がわかるようにコメントを残せ。それができないエンジニアは、どのツールを使っても結局「手動修正の沼」から抜け出すことはできない。
さあ、今日はどの構成を自動化して、SREとしての時間を創出する？