Chef Infra Clientの収束（Convergence）時間を半減させろ：現場の「重い」を解消する極限チューニング
「Chefの実行が終わらない」
「デプロイのたびに数分待たされるのが苦痛だ」
もし君がChefの実行ログを眺めながらコーヒーを淹れる時間があるなら、それはインフラエンジニアとして「敗北」している。Chefは決して遅いツールではない。遅いのは、君がChefに「不要な重荷」を背負わせているからだ。
今日は、数千台規模のサーバー群を管理してきた経験から、Chef Infra Clientの収束時間を劇的に短縮し、開発サイクルを爆速化させるための「現場の最前線」で培った技術を叩き込む。
—
1. なぜChefは「重く」なるのか？
Chefの実行プロセスは大きく分けて「Compile Phase」と「Converge Phase」の2つがあるが、多くの現場でボトルネックになるのは以下の3点だ。
1. Ohaiの肥大化: 不要なハードウェア情報の収集によるオーバーヘッド。
2. リソースの過剰な走査: 状態が変わっていないにもかかわらず、毎回ファイルやパッケージをチェックする非効率。
3. 無駄なAPI通信: Chef Serverとの同期や検索（Search）の過剰な実行。
これらを物理的に排除する。
—
2. Ohaiのプラグインを「断捨離」する
Ohaiは便利だが、全プラグインを動かす必要はない。特にクラウド環境では不要な情報収集が10秒〜20秒の遅延を生むこともある。
`client.rb` に以下の設定を追加し、不要なプラグインを無効化せよ。
/etc/chef/client.rb
不要なプラグインをロード対象から外す
例えば、EC2やGCEで動いているなら、それ以外のクラウドプラグインは不要
ohai.disabled_plugins = [
“passwd”, # ユーザー情報が膨大な場合、ここが極端に遅くなる
“dmi”, # 物理サーバー以外ではほぼ無意味
“ip_scopes” # ネットワークトポロジが複雑でなければ不要
]
Ohaiのタイムアウトを短縮（デフォルトは長い）
ohai.timeout = 5
—
3. 「冪等性」のその先へ：リソースの最適化
Chefの強力な機能である「冪等性」だが、書き方次第で劇的に遅くなる。
悪い例：毎回実行されるリソース
毎回findコマンドが走るため、ディレクトリ構造が深いと致命的
execute “cleanup” do
command “find /var/tmp -name ‘.log’ -delete”
end
良い例：ガード句（not_if/only_if）の徹底活用
「実行すべきかどうか」の判定を、シェル呼び出しではなく、Chefの持つリソース属性で判定する。
状態変化がないなら、そもそも実行させない
file “/var/tmp/app.log” do
action :delete
only_if { ::File.exist?(“/var/tmp/app.log”) }
end
また、`package`リソースでのインストール時は、`flush_cache`を安易に`true`にしないこと。これだけで収束時間は数秒変わる。
—
4. チューニングのための「神設定」と隠れた技
`client.rb` のベストプラクティス構成例
/etc/chef/client.rb
1. Chef Serverへのアクセス頻度を減らす
失敗時のリトライ回数を減らし、即座に終了させる
client_fork true # 並列実行の恩恵を受ける
splay 0 # 大規模環境以外では0にして即時実行させる
2. ログレベルの適正化
infoはIO負荷が高い。本番ではwarn以上を推奨
log_level :warn
3. 必要な時だけ実行する「Partial Search」
全ノード情報を引き出すとメモリを食う。必要な属性だけ取得せよ
現場で役立つ「開発用キーボードショートカット」
ターミナルでの開発スピードを上げるために、`.zshrc`や`.bashrc`に以下のようなエイリアスを入れるのは常識だ。
Chefの実行を高速化するエイリアス
alias c-run=’sudo chef-client -l warn –no-fork’ # 開発時はフォークを切るほうがデバッグしやすい
alias c-cook=’chef-client -o “recipe[my_app::default]”‘ # 特定レシピだけ叩く
—
5. チーム開発で守るべき「規約」
ツールを最適化しても、コードがスパゲッティでは意味がない。チームで守るべき「高速化のためのルール」だ。
1. `Search`は極力避ける: Chef Serverの検索機能は強力だが、多用すると検索インデックスの負荷でノード全体のConvergeが遅延する。属性（Attributes）は可能な限りローカルで完結させる。
2. `Library`の活用: ロジックをレシピに書かず、ライブラリに切り出す。コンパイル時のオーバーヘッドを削減できる。
3. テスト駆動開発（Test Kitchen）の徹底: 本番環境で「試行錯誤」してはいけない。ローカルで収束時間を計測し、遅いコードをコミットする前にCIで弾く。
—
結論：Chefを「道具」として支配せよ
Chefは、ただ回すだけなら誰でもできる。しかし、インフラのコードを読み解き、どこがボトルネックになっているかをプロファイリングし、設定一つで収束時間を半分に削り取るのが「SREの仕事」だ。
今回紹介したチューニングを適用すれば、デプロイの待ち時間は体感で半分以下になるはずだ。浮いた時間で、さらに高度な自動化や、システムの信頼性を高めるための設計に時間を投資してほしい。
インフラは、書き手の思考の速さを超えてはならない。
さあ、今すぐサーバーにSSHして、その無駄を削ぎ落とせ。