【実務・中級編】Chef Infra Clientのメモリリーク診断と対策：長期稼働ノードで発生するリソース枯渇問題のトラブルシューティング – インフラ構成管理（IaC）活用バイブル

Chef Infra Clientのメモリリークを制圧する：大規模ノードを「沈黙させない」ための深淵なるチューニング術

Chef Infra Clientを常駐プロセス（`chef-client -i`）として運用していると、ある日突然、見えない敵に襲われる。メモリ使用量が階段状に上昇し、最終的にはOOM Killerに刈り取られる。特に数千台規模のフリート、あるいは複雑な依存関係を持つカスタムリソースを抱えるノードで顕著だ。

これはChefのバグか？いや、多くの場合、Rubyのメモリ管理の特性と、Ohaiによる動的な情報収集の「蓄積」が原因だ。今日は、この「メモリの死」を回避し、Chefを真の安定稼働へと導くための現場レベルの戦術を伝授する。

—

1. メモリリーク診断：犯人は誰だ？

メモリが溢れているとき、闇雲に再起動してはいけない。まず、どのオブジェクトがヒープを占拠しているかを見極める必要がある。

Ruby GCの可視化

ChefはRubyで動いている。まずは `ObjectSpace` を使って、何が生き残っているかを特定せよ。`chef-client` 実行中に以下を仕込むのが最短ルートだ。

/etc/chef/client.rb に含めるか、実行時にロードするデバッグ用コード
require ‘objspace’

実行終了時にメモリ状況を出力するフック
at_exit do
GC.start
# 主要なクラスごとのオブジェクト数をカウントしてログへ
ObjectSpace.count_objects.each { |k, v| Chef::Log.info(“#{k}: #{v}”) }
end

これで、`Chef::Resource` や `Chef::Provider` のインスタンスが回収されずに溜まっていないかを確認できる。

—

2. メモリ肥大化の「最大の犯人」：Ohaiとカスタムプラグイン

Chefは実行のたびにOhaiでシステム情報を収集するが、ここが鬼門だ。
特に、巨大なJSONを生成するカスタムプラグインや、外部コマンドを頻繁に叩くプラグインは、実行ごとにメモリを食い散らかす。

対策：Ohaiプラグインの適正化

1. キャッシュの無効化: 不要なプラグインを `client.rb` で明示的に無効化する。
2. 外部コマンド呼び出しの最小化: `shell_out` を乱用せず、直接ファイルを読むか、ネイティブなRubyメソッドに書き換える。

/etc/chef/client.rb
不要なOhaiプラグインを殺す（標準の不要な情報収集を削る）
ohai.disabled_plugins = [
“Passwd”, # ユーザー数が多いとメモリを食う
“Virtualization” # クラウド環境ならメタデータサービスで十分な場合が多い
]

—

3. Ruby GCのチューニング：ヒープの断片化を防ぐ

デフォルトのRuby GC設定は、汎用的なアプリケーション向けであり、長時間稼働する監視・構成管理ツールには最適化されていない。環境変数でGCの挙動を縛り付けるのがプロの技だ。

`chef-client` が動作する環境に、以下の環境変数をセットせよ（systemdのServiceファイル等）。

/etc/systemd/system/chef-client.service
[Service]
Environment=”RUBY_GC_HEAP_FREE_SLOTS=100000″
Environment=”RUBY_GC_MALLOC_LIMIT=64000000″
Environment=”RUBY_GC_MALLOC_LIMIT_MAX=128000000″
これにより、GCの頻度を下げつつ、ヒープの断片化を抑制する

—

4. 生産性を爆上げする「隠れた神テクニック」

プロが使うVim/VSCode設定（Chef開発用）

Chefのレシピを書くとき、`metadata.rb` や `.kitchen.yml` の記述ミスは致命的だ。以下の設定を入れるだけで、生産性は確実に2倍になる。

VSCode神プラグイン: `Chef Extension for VS Code` (Chef社公式)。これなしでレシピを書くのは目隠しで高速道路を走るようなものだ。
YAML構成のベストプラクティス (`.kitchen.yml`):

常に `verifier` を活用し、検証を自動化せよ。

.kitchen.yml の推奨設定
verifier:
name: inspec
sudo: true

suites:

name: default

provisioner:
name: chef_infra
product_name: chef
attributes:
# 属性は必ず階層化し、ハードコーディングを避ける
my_app:
version: “1.2.3”
log_level: “info”

チーム開発のルール：`Attribute` の汚染を防ぐ

`default` 属性をむやみに増やしてはいけない。チームの生産性を落とす最大の原因は「どこで属性が上書きされたか分からない」状況だ。

原則: Attributeは「環境固有の設定」のみに使い、それ以外は `node.run_state` を活用せよ。
ルール: 重要な属性変更は `environment` ではなく、`policyfile` に集約せよ。

—

結論：Chefを「守り」から「攻め」のツールへ

Chefのメモリリーク問題は、ツールそのものの問題というより、「ChefをどのようにRubyプロセスとして長く走らせるか」という設計思想の欠如から生じる。

1. Ohaiを軽量化し、無駄な情報を削ぎ落とす
2. GCパラメータをノードの物理メモリに合わせてチューニングする
3. Policyfileによる構成の完全固定で、Chef-Clientの計算負荷を減らす

この3点を徹底するだけで、Chefはただの「設定ツール」から、あなたのインフラを24時間365日静かに守り続ける「自律的な管理エンジン」へと進化する。

現場で躓いているなら、まずは `ObjectSpace` でメモリの断末魔を聞くことから始めてほしい。インフラエンジニアの真価は、トラブルが起きたときの「深掘り」にあるのだから。