こんにちは！インフラストラクチャの世界へようこそ。
日々、膨大なサーバー群の構成管理に追われていませんか？「設定ファイルを書き換えたのに反映されない」「なぜかエージェントとの通信がタイムアウトする」……そんなインフラエンジニアの悲鳴を、美しく、そして完全に過去のものにしてくれるのがPuppetです。
今回は、これからPuppetに触れるあなたに向けて、その中核である「Puppet Server」の最も深淵にして重要なテーマ「JVMメモリチューニングとGC（ガベージコレクション）の最適化」について、現場の生きた知見を交えて優しく徹底解説します。
これをマスターすれば、深夜に突然飛んでくる「Puppet ServerがOutOfMemoryで死んだんだけど！」という恐怖のアラートから解放されますよ。さあ、一緒に扉を開けましょう！
—
1. そもそもPuppetってなに？（ツールの役割）
Puppetは、サーバーの「あるべき姿（Desired State）」をコードで定義し、自動的にその状態を維持・収束させるための構成管理ツール（IaCツール）の金字塔です。
- 「何台あっても怖くない」：手動で設定変更を行う「Configuration Drift（設定の乖離）」を防ぎます。
- 「冪等性（べきとうせい）」の担保：何度コードを実行しても、サーバーの状態が正しく安全に保たれるよう設計されています。
しかし、このPuppetを支える「Puppet Server」というエンジンには、一つだけ大きな弱点があります。それが「Java（JVM）の上で動いている」という点です。
Puppet Serverの実体は、JRubyという「Java上で動くRuby処理系」です。つまり、Rubyのコードを書きながらも、内部では厳格なJavaのメモリ管理（JVMチューニング）の作法が要求されます。ここをサボると、すぐにメモリリークやスラッシング（OSがメモリ不足でフリーズ寸前になる現象）を引き起こすのです。
—
2. インストールと最も重要な基礎セットアップ
まずは、Puppet Serverを安全に稼働させるための土台を作りましょう。今回は多くのモダンなLinux環境（RHEL系 / Ubuntu系）を想定し、最短かつ堅牢なセットアップ手順を示します。
① リポジトリの追加とインストール
例: AlmaLinux 9 / RHEL 9 の場合
sudo dnf install -y https://yum.puppet.com/puppet8-release-el-9.noarch.rpm
sudo dnf install -y puppetserver
② 最重要！JVMヒープメモリの初期サイジング
インストールしたら、絶対にそのまま起動してはいけません。 デフォルトのメモリ設定は、小規模なテスト環境を想定しているため、本番では一瞬でパンクします。
設定ファイルは `/etc/default/puppetserver`（Systemd環境）にあります。ここを開いて、JVMに割り当てるメモリ（ヒープサイズ）を明示的に指定します。
/etc/default/puppetserver の該当部分を抜粋・調整
物理メモリの「半分」を割り当てるのがJVMチューニングの黄金律です（例: 8GB搭載サーバーなら 4GB）
JAVA_ARGS=”-Xms4g -Xmx4g”
- `-Xms4g`：起動時の初期ヒープサイズを4GBに固定（メモリの動的拡張によるオーバーヘッドを防ぐ）
- `-Xmx4g`：最大ヒープサイズを4GBに制限（OSのメモリを食いつぶしてOOM Killerに殺されるのを防ぐ）
—
3. 【核心】G1GCによるガベージコレクション最適化とメモリリーク対策
さて、ここからが本記事のハイライトです。JRubyはオブジェクトの生成と破棄が非常に激しいため、デフォルトのGCアルゴリズムでは「Stop-the-World（JVMが完全に停止する時間）」が頻発し、エージェントからのリクエストがタイムアウトします。
ここで投入するのが、G1GC (Garbage-First Garbage Collector) と、JVMチューニングの極意です。
先ほどの設定ファイル（`/etc/default/puppetserver`）の `JAVA_ARGS` に、以下のフラグをごっそり追加してください。現場の修羅場をくぐり抜けて導き出された「最強の布陣」です。
JAVA_ARGS=”
-Xms4g
-Xmx4g
-XX:+UseG1GC
-XX:MaxGCPauseMillis=200
-XX:InitiatingHeapOccupancyPercent=45
-XX:+ExplicitGCInvokesConcurrent
-Djruby.logger.class=com.puppetlabs.jruby_utils.jcl.JRubySlf4jLogger
”
各パラメータの意味と優しさの解説
1. `-XX:+UseG1GC`
- 大容量メモリ（4GB以上）を効率よく扱い、停止時間を予測可能にする最新のGCアルゴリズムを指定します。
2. `-XX:MaxGCPauseMillis=200`
- 「GCによるサーバーの停止時間を、できるだけ200ミリ秒以内に抑えてくれ」というJVMへの強い要望（目標値）です。
3. `-XX:InitiatingHeapOccupancyPercent=45`
- ここが一番重要です！ ヒープ使用量が45%を超えた時点で、G1GCにバックグラウンドでのゴミ掃除を早期開始させます。「ギリギリまで掃除をしない」デフォルト設定だと、たまったゴミが一気に処理されてサーバーがフリーズ（スラッシング）します。早め、早めの掃除がサーバーを救うのです。
4. `-XX:+ExplicitGCInvokesConcurrent`
- Rubyコード内からの不要な明示的ガベージコレクション要求を、アプリケーションを止めずに並行処理させます。
—
4. スレッドプールのサイジング（JRubyインスタンスの最適化）
メモリだけでなく、「何人のエージェントと同時に会話するか」もチューニングする必要があります。Puppet Serverは、同時に処理できるリクエストの数を「JRubyインスタンス数」で管理しています。
設定ファイル：`/etc/puppetlabs/puppetserver/conf.d/puppetserver.conf`
抜粋
ruby: {
# 搭載しているCPUコア数に合わせて調整します
# 一般的な目安は 「(CPUコア数 – 1)」 または 「物理コア数」 です
max-active-instances: 4
}
メモリをいくら多く積んでも、このインスタンス数を大きくしすぎると、1インスタンスあたりのJVMヒープが圧迫され、結局OutOfMemoryエラーを引き起こします。「メモリ量とJRubyインスタンス数のバランス」を意識することが、プロのインフラエンジニアの技量見せ所です。
—
5. 精度高い「HelloWorld」的動作確認
設定が変わったら、Puppet Serverを再起動して、正しく動くか魂の動作確認を行いましょう。
サービスの再起動
sudo systemctl restart puppetserver
ログをリアルタイム監視してエラーが出ていないか確認
sudo journalctl -u puppetserver -f
うまく起動したら、ローカル環境でPuppetエージェントを走らせて「HelloWorld（設定の適用）」を確認します。
テスト用のマニフェスト（コード）を作成
echo “notify { ‘Hello, Puppet Server! Tuning is successful!’: }” > /tmp/hello.pp
適用テスト
puppet apply /tmp/hello.pp
実行結果のイメージ：
Notice: Compiled catalog for webserver01.local in environment production in 0.04 seconds
Notice: Hello, Puppet Server! Tuning is successful!
Notice /Stage[main]/Main/Notify[Hello, Puppet Server! Tuning is successful!]/message: defined ‘message’
Notice: Finished catalog application in 0.03 seconds
この美しい出力が見られたら、あなたのPuppet Serverは、過酷な本番環境の負荷にも耐えうる「強靭なインフラ基盤」へと生まれ変わっています！
—
まとめ
今回は、Puppet ServerのJVMメモリチューニングとG1GCの最適化について解説しました。
- JVMヒープは物理メモリの半分で固定する（`-Xms`, `-Xmx`）
- G1GCを有効化し、早めのゴミ掃除（IHOP=45%）でスラッシングを防ぐ
- CPUコア数とメモリ量に見合ったJRubyインスタンス数を設定する
この基本原則を押さえておけば、もうメモリリークや突然のサービス停止に怯える必要はありません。
これをマスターすれば、あなたのインフラ管理の日常は劇的に、そして圧倒的に楽になりますよ。
さあ、自信を持って素晴らしい自動化の世界へ踏み出しましょう！