Puppet Compilerの深淵：コンパイル地獄から脱却せよ！数万ノードを支えるSREのためのプロファイリング＆高速化全手法
テックリードの私たちが日々のインフラ運用の現場で最も恐怖するもの、それは何か？
AWSの障害か？ランサムウェアか？いや、「Puppetエージェントの実行に毎回10分以上かかる」という静かなる生産性の殺人者だ。
数千、数万台規模のインフラストラクチャをPuppetで宣言的に管理していると、コードベースの肥大化とともに、Puppet Serverのカタログコンパイル時間がじわじわと延びていく。
「なぜか `puppet agent -t` が終わらない」「PuppetDBへの負荷が高止まりしている」「デプロイパイプラインがコンパイル待ちで渋滞を起こしている」。
もし君のチームがこの泥沼にハマっているなら、原因当てずっぽうのリファクタリングはやめなさい。私たちSREに必要なのは、データに基づいた正確なプロファイリングと、コンパイルの内部メカニズムに基づいた構造改革だ。
今回は、Puppet Compilerの内部挙動を丸裸にし、重いマニフェストやHieraの迷宮を特定して爆速化させる極限の知見を授けよう。
—
1. なぜPuppet Compilerは遅くなるのか？（根本原因の解剖）
Puppet Serverは、エージェントからリクエストを受けると、JRubyインタープリタ上でPuppet Parserを動かし、DSLを評価（Evaluate）してカタログ（JSON）を生成する。このコンパイルプロセスが重くなる主な要因は以下の3点に集約される。
1. 過剰なHieraルックアップと複雑なデータ構造
- 巨大なYAML階層、不必要な `lookup()` のネスト、`deep_merge` の多用。
2. 無駄なリソース評価と依存関係（Relationship）の爆発
- `resources` メタパラメータや、全ノードで評価される巨大な `create_resources()`。
3. PuppetDBへの無駄なクエリ（Exported Resourcesの乱用）
- 適切にインデックスされていないPuppetDBへの重いクエリ。
これを感覚ではなく、ミリ秒単位の数値として暴いていく。
—
2. 導入必須：Puppet Compilerプロファイリング機能の全容
Puppet Serverには、標準でカタログコンパイルの各フェーズを計測するプロファイル機能が備わっている。まずはこれを有効化し、どこに時間が溶けているのかを可視化する。
2.1 設定ファイルのベストプラクティス (`routes.yaml` と `puppetserver.conf`)
プロファイルを有効にするには、Puppet Serverの設定を変更する。本番環境で常時有効にするとI/Oとメモリを圧迫するため、特定のデバッグウィンドウでのみ有効化するか、詳細なメトリクスをログに吐かせる設定にする。
`/etc/puppetlabs/puppetserver/conf.d/puppetserver.conf` のプロファイル設定をチューニングせよ。
/etc/puppetlabs/puppetserver/conf.d/puppetserver.conf
profiler: {
# 総合的なプロファイリングを有効化
enabled: true
# 実行時間がこの閾値（ミリ秒）を超えたコンパイルステップをログに記録
# 開発・検証環境では 100ms 程度に設定してボトルネックをあぶり出す
print-profiler-results: true
}
さらに、JRubyのプール設定やメトリクスエンドポイント（Prometheus形式）を有効化し、Grafanaでコンパイル時間のトレンドを常時監視できるようにしておくことが大前提だ。
2.2 `puppet-profiler` による詳細な内訳の可視化
Puppet 6/7/8環境において、どのクラスや定義（Defined Type）が時間を食っているかを特定するには、組み込みの `profile` 関数や、コミュニティで実績のある解析ツールを活用する。
Puppetコード内に直接プロファイル計測を埋め込むことも可能だ：
重い処理や疑わしいカスタムクラスの囲い込み
profile(‘Complex Hiera and Resource Generation’, [‘my_module::heavy_operation’]) do
# 疑わしい処理
$massive_data = lookup(‘extremely_complex_hierarchy’, Hash, ‘deep’, {})
…
end
これにより、`/var/log/puppetlabs/puppetserver/puppetserver.log` に以下のような詳細なトレースが出力される。
2023-10-25T10:15:30.123+00:00 INFO [qtp123456789-11] [puppetserver] Puppet Evaluation:
Class[My_module::Heavy_operation] took 4200ms
Hiera lookup for ‘extremely_complex_hierarchy’ took 1850ms
—
3. 犯人を暴く：重いマニフェストとHieraルックアップの特定手法
ログから「どの部分が遅いか」のあたりをつけたら、次は具体的な悪者コードを特定する。実務で遭遇しがちなしみったれたアンチパターンと、その排除手法を公開する。
アンチパターン A: 全ノードでの巨大な `lookup()` と `deep_merge` の乱用
【やってはいけない実装】
すべてのノードのカタログコンパイルでこの巨大YAMLをマージさせている
$global_app_config = lookup(‘app::clusters’, Hash, ‘deep’, {})
$global_app_config.each |$cluster_name, $config| {
# ノードに関係ない全クラスターの設定をここでループ評価している
my_module::cluster_setup { $cluster_name:
config => $config,
}
}
【なぜ遅いか】
Hieraの `deep_merge` は、階層（Datadirs）が深ければ深いほど、またキーの数が多いほどCPUとメモリを激しく消費する。関係のないノードまでこの処理を通すのは、CPUの無駄遣いである。
【高速化の極意】
1. スコープを絞る: 必要なノードだけにHieraデータを分割する。
2. Lookupの遅延評価とデータ型の厳格化: 不要なマージを避け、必要最低限のキーのみを取得する。
3. Hiera 5の `lookup_options` の最適化: メソッドを `first` にできる部分は `deep` を避ける。
アンチパターン B: 暗黙的な依存関係の連鎖 (`->`, `
Puppetのコンパイラは、リソース間の依存関係グラフ（DAG: Directed Acyclic Graph）を構築する際に、全リソース間の順序関係を検証する。数万個のリソースを持つカタログでは、このグラフ構築アルゴリズムがO(N^2)に近い負荷を生むことがある。
【高速化の極意】
- グローバルな `Anchor` パターンや過剰な `Contain` のネストを見直す。
- クラス間の依存関係は必要最小限にし、リソースレベルの密結合を避ける。
—
4. チーム開発で実践すべきコード最適化と設定共有化ルール
個人のスキルに頼るな。チーム全体で「重いPuppetコードを書かせない」ための仕組みとルールをコードベースに組み込め。
4.1 チーム共有：絶対入れるべき神プラグインとLinter設定
VSCodeやIntelliJを使い、ローカルの段階で悪質なコードを弾く。`.puppet-lint.rc` をプロジェクトルートに配置し、CI/CDパイプライン（GitHub Actions等）で強制せよ。
`.puppet-lint.rc` (ベストプラクティス設定)
チーム共通のPuppet-Lintルール
複雑度やパフォーマンスに悪影響を及ぼす書き方を厳格にチェックする
–all-checks
–with-filename
可読性とパフォーマンスを害するスタイルを禁止
–disable-class_inherits_from_params_class
–disable-documentation
–enable-autoloader_layout
–enable-hardcoded_hostname
警告ではなくエラーとして扱う（CIを落とす）
–error-level error
さらに、VSCodeを使うなら以下の拡張機能をチーム全員に義務付けよ。
- Puppet (Puppet Labs公式): インテリセンスとシンタックスハイライト。
- Hiera JSON/YAML Validator: Hieraデータの構造ミスをリアルタイムで検知。
4.2 高速化のためのキーボードショートカット＆エディタハック（VSCode）
テックリードとして、開発スピードを極限まで高めるためのショートカットをチームに布教せよ。
- クイック・クラスジャンプ (`Ctrl + P` または `Cmd + P`):
モジュール名やクラス名（例: `profile::base::linux`）を瞬時に入力してジャンプする習慣をつけ、ファイルツリーをマウスで探す無駄な時間をゼロにする。
- マルチカーソルによるリソース定義の一括修正 (`Alt + Click` or `Ctrl + Alt + Down`):
複数のパラメータを一括で書き換える際、キーボードから手を離さずに編集を完了させる。
—
5. 実践：リファクタリングによる高速化のビフォー・アフター
実際のコード改善例を見てみよう。
【Before】コンパイルに3秒かかっていた泥沼コード
class profile::app::database {
$db_users = lookup(‘database::users’, Array, ‘unique’, [])
# 配列を全件ループしてリソースを動的生成（コンパイラに大負荷）
$db_users.each |$user| {
mysql_user { “${user[‘name’]}@${user[‘host’]}”:
password_hash => $user[‘password_hash’],
require => Class[‘mysql::server’],
}
mysql_grant { “${user[‘name’]}@${user[‘host’]}-all”:
user => “${user[‘name’]}@${user[‘host’]}”,
table => “${user[‘db’]}.”,
privileges => [‘ALL’],
require -> Mysql_user[“${user[‘name’]}@${user[‘host’]}”],
}
}
}
- 問題点: `lookup` の `unique` マージ、及びDSL内での過剰な文字列結合とループによるリソース動的生成がコンパイラを重くしている。
【After】コンパイル時間を80%削減した洗練されたコード
class profile::app::database (
# Hieraの自動パラメータバインディング（Class Parameters）を活用
# コンパイラの評価コストを最小化し、型安全性を担保する
Hash $db_users_hash = {},
) {
include mysql::server
# create_resources の現代的・高速な代替である Hash iteration を最適化し、
# 不要な依存関係の連鎖を排除
$db_users_hash.each |$username, $attrs| {
mysql_user { “${username}@${attrs[‘host’]}”:
ensure => present,
password_hash => $attrs[‘password_hash’],
}
mysql_grant { “${username}@${attrs[‘host’]}-grant”:
user => “${username}@${attrs[‘host’]}”,
table => “${attrs[‘db’]}.”,
privileges => $attrs[‘privileges’],
}
}
}
改善のポイント:
1. クラスパラメータの自動バインディング: `lookup()` を明示的に何度も呼ぶのではなく、Puppetのクラスパラメータバインディングに任せることで、コンパイラの内部最適化の恩恵を受ける。
2. 依存関係の削減: 明示的な `require` を必要最低限に絞り、Puppetの自動タイプ解決に委ねることでDAG構築コストを激減。
—
6. おわりに：SREが守るべきインフラコードの美学
Puppet Compilerのプロファイリングと高速化は、単なる「待ち時間の短縮」にとどまらない。
コンパイルが速くなるということは、デプロイサイクルの高速化、CI/CDパイプラインの効率化、そしてインフラストラクチャ全体の変更に対する俊敏性（Agility）を手に入れるということだ。
「動けばいい」という汚いマニフェストや、思考停止した巨大なHieraの階層構造を放置するな。プロファイラーでボトルネックを数値で突き止め、コードを研ぎ澄ませ。
君たちの書く優美で高速なPuppetコードこそが、組織全体の開発スピードを限界突破させるエンジンとなるのだから。