【入門編】大規模インフラを支えるPuppetパフォーマンスチューニングの極意 – インフラ構成管理（IaC）活用バイブル

大規模インフラの深淵を制御する：Puppetパフォーマンスチューニングの「極意」

こんにちは。インフラの自動化という荒野を駆け抜けてきた諸君、ようこそ。

Puppetは、宣言的な記述によって「あるべき姿（Desired State）」を維持し続ける、極めて強力な構成管理ツールです。しかし、管理対象のノード（Agent）が数百、数千と増えてくると、必ず「Puppet Serverが悲鳴を上げる」という壁にぶつかります。

今日は、初心者から一歩先へ進み、大規模環境を意のままに操るための「Puppetの魂」とも言えるチューニング手法を伝授します。これをマスターすれば、深夜の構成変更で胃を痛めることもなくなりますよ。

—

Puppetの負荷は、主に「コンパイル」に起因します。各Agentがチェックインするたびに、Puppet Serverは複雑なRubyコードを解釈し、カタログ（設定の設計図）を生成します。

これらを順を追って解決していきましょう。

—

Puppet ServerはJRuby上で動作します。ここが最大のボトルネックです。

`/etc/puppetlabs/puppetserver/conf.d/puppetserver.conf` を開いてください。

jruby-puppetの設定
jruby-puppet {
# CPUコア数に合わせて調整。一般的にコア数-1が目安
max-active-instances: 4
# メモリ不足を防ぐためのヒープサイズ
max-requests-per-instance: 5000
}

極意: `max-active-instances` を増やせば並列処理は増えますが、メモリを食いつぶします。サーバーの物理メモリ量と相談し、一つあたりのJRubyインスタンスに「1GB〜2GB」程度を割り当てられるように計算してください。

—

PuppetDBはAgentの履歴や状態を保持する「心臓部」です。ここが遅いとインフラ全体が死にます。

`conf.d/database.conf` でコネクションプール数を増やしましょう。

database {
# 同時接続数を増やす
pool-size: 25
# PostgreSQL側でのインデックス不足がないか、定期的にログを確認すること
}

極意: 大規模環境では、PostgreSQL自体の `shared_buffers` や `work_mem` の調整が不可欠です。また、古いレポートを自動削除する `pruning` 設定を必ず有効にしてください。ゴミが溜まったDBで検索をかけてはいけません。

—

全てのAgentが同時に「チェックイン」すると、Puppet Serverは一瞬でダウンします（これをThundering Herd＝群れで押し寄せる牛の群れ、と呼びます）。

これを防ぐのが `splay` です。

/etc/puppetlabs/puppet/puppet.conf
[agent]
30分（1800秒）の間でランダムに時間をずらして接続する
splay = true
splaylimit = 1800

—

初めてPuppetに触れるあなたのために、最も単純な「構成適用」を体験しましょう。

`/etc/puppetlabs/code/environments/production/manifests/site.pp` を作成します。

これは「あるべき姿」の定義です
file { ‘/tmp/hello.txt’:
ensure => file,
content => “Puppetの世界へようこそ！\n”,
owner => ‘root’,
mode => ‘0644’,
}

まずはAgent側で以下のコマンドを打ちます。

sudo puppet agent -t –noop

—

Puppetを運用する上で最も重要なのは、「冪等性（べきとうせい）」です。何度実行しても、結果は常に同じであること。この原則さえ守れば、Puppetはあなたの最も忠実な部下となります。

大規模インフラは魔法ではなく、こうした小さな設定の積み重ねで支えられています。最初は難しく感じるかもしれませんが、一度「コードによるインフラ管理」の快感を覚えたら、もう手作業には戻れませんよ。

さあ、次はあなたの番です。まずは開発環境で `splay` を体感するところから始めてみてください。応援しています！