【Ansible応用講座 第3回】爆速化チューニング。Forks、Pipelining、Mitogenによるパフォーマンス改善

「100台へのデプロイに1時間かかる」…その待ち時間、無駄です。

こんにちは！「LINUX工房」管理人の「リナックス先生」です。
Ansible応用講座も第3回。ここまでは「動的インベントリ」や「高度なロジック」といった機能面にフォーカスしてきました。

しかし、機能が充実して管理対象が増えてくると、必ず直面する壁があります。
「Ansible、遅すぎない？」問題です。

本記事では、AlmaLinux 9 をベースに、標準機能でのチューニング（Forks, Pipelining, ControlPersist）から、アーキテクチャレベルで高速化するサードパーティ製プラグイン「Mitogen for Ansible」の導入まで、パフォーマンス改善の秘儀を徹底解説します。

---

第1章：なぜAnsibleは「遅い」のか？

チューニングを始める前に、敵（ボトルネック）を知りましょう。
Ansibleが遅くなる主な原因は以下の2つです。

1. SSH接続のオーバーヘッド

Ansibleはエージェントレスであるため、1つのタスク（モジュール）を実行するたびに、以下の手順を繰り返します。

1. SSH接続を確立する
2. PythonモジュールをSFTPで転送する
3. リモートで実行する
4. 結果を受け取る
5. SSHを切断する

たった1回の copy や dnf のために、これだけの通信が発生します。
タスクが10個あれば10回、サーバーが100台あれば1000回のSSH接続・切断が行われます。
これが「遅い」最大の原因です。

2. 並列実行数の制限（Forks）

Ansibleのデフォルト設定では、並列実行数（Forks）は 5 に設定されています。
つまり、100台のサーバーがあっても、一度に処理されるのは5台だけ。
残りの95台は順番待ちをしている状態です。

---

第2章：基本チューニング（ansible.cfg）

まずは標準機能の設定変更だけで、できる限りの高速化を図ります。
ansible.cfg を編集します。

1. 並列数（Forks）を増やす

サーバーのスペック（CPU/メモリ）が許す限り、Forksを増やしましょう。
最近のPCやサーバーなら、50〜100 くらいまでは余裕で上げられます。

[defaults]
# デフォルトは5。一気に増やす！
forks = 50

これだけで、単純計算で処理速度が10倍になります。

2. Pipelining（パイプライニング）の有効化

SSH接続のオーバーヘッドを減らすための最強設定です。
これを有効にすると、SSH接続を維持したまま、「ファイル転送」と「実行」をパイプ処理で行うようになり、接続回数が激減します。

[ssh_connection]
# SSH接続のパイプライン化を有効にする
pipelining = True

注意点： ターゲットサーバー側の /etc/sudoers で requiretty が無効になっている必要があります。
（AlmaLinux 9などの最近のOSではデフォルトで無効なので、基本的に問題ありません）

3. SSH接続のキャッシュ (ControlPersist)

一度確立したSSH接続を、一定時間「張りっぱなし」にして再利用する設定です。
連続するタスク間での再接続コストをゼロにします。

[ssh_connection]
# 接続を30分間(1800秒)維持する
ssh_args = -o ControlMaster=auto -o ControlPersist=1800s

4. Fact収集の最適化

Playbook実行のたびに走る Gathering Facts（サーバー情報の収集）も、台数が多いと時間がかかります。
必要ない場合はOFFにするか、キャッシュを有効にします。

OFFにする場合 (Playbook内):

- hosts: all
  gather_facts: false  # これを書くだけ
  tasks: ...

キャッシュする場合 (ansible.cfg):
収集した情報をJSONファイルやRedisに保存し、2回目以降はそれを使い回します。

[defaults]
gathering = smart
fact_caching = jsonfile
fact_caching_connection = /tmp/ansible_facts
fact_caching_timeout = 86400  # 1日間保持

---

第3章：禁断の高速化プラグイン「Mitogen」

ここまでのチューニングでも十分速くなりますが、さらに次元の違うスピードを求めるなら Mitogen for Ansible です。
Ansibleの内部構造（通信レイヤー）を根本から置き換えるサードパーティ製プラグインです。

Mitogenとは？

通常のAnsibleは「SSHでPythonコードを送り込んで実行」しますが、Mitogenは「SSH接続の中にPythonのプロセスを常駐させ、メモリ上で処理を完結」させます。
これにより、ファイル転送やプロセス起動のコストがほぼゼロになり、実行速度が1.5倍〜10倍になると言われています。

導入手順

MitogenはAnsible Galaxyやpipではなく、公式サイトからダウンロードして配置する形式が一般的です。
（※最近は ansible-galaxy で管理できるラッパーもありますが、ここでは基本の手順を紹介します）

1. ダウンロードと展開

mkdir plugins
cd plugins
wget https://networkgenomics.com/try/mitogen-0.3.3.tar.gz
tar xf mitogen-0.3.3.tar.gz
mv mitogen-0.3.3 mitogen

2. ansible.cfg の設定

Ansibleに「Mitogenのストラテジー（実行戦略）を使うよ」と教えてあげます。

[defaults]
# プラグインの場所を指定
strategy_plugins = ./plugins/mitogen/ansible_mitogen/plugins/strategy

# デフォルトのストラテジーをmitogenに変更
strategy = mitogen_linear

3. 効果の確認

これだけで設定完了です。
いつも通り ansible-playbook を実行してみてください。

ansible-playbook site.yml

ログの出力形式が少し変わり、実行速度が目に見えて速くなっているはずです。
特に yum や copy などの重いモジュールよりも、多数の小さなタスクを連続実行する場合に効果絶大です。

---

第4章：実行戦略（Strategy）の使い分け

Ansibleには、デフォルトの linear 以外にも、標準でいくつかの実行戦略（Strategy）が用意されています。

1. linear (デフォルト)

「全サーバーでタスク1を完了させてから、タスク2に進む」方式。
エラーが出たサーバーをそこで脱落させられるため、安全ですが、一番遅いサーバーに全員が待たされます。

2. free (フリー走行)

「各サーバーが自分のペースでどんどん次のタスクに進む」方式。
他のサーバーの完了を待たないので、全体の完了時間は最短になります。
ただし、ログが入り乱れて見づらくなるのと、「全台で停止してから、全台で起動する」といった同期が必要な処理には向きません。

- hosts: webservers
  strategy: free  # ここで指定
  tasks: ...

3. debug

タスクが失敗した時に、そこで停止してデバッガー（対話モード）を起動するモード。
開発中には便利ですが、自動化には向きません。

---

第5章：Async（非同期実行）による長時間タスクの放置

「OSのアップデート」や「DBのバックアップ」など、完了までに数分〜数時間かかるタスクがある場合、AnsibleがSSH接続を維持して待ち続けるのはリスクがあります（タイムアウトで切れる可能性があります）。

そんな時は Async（非同期） を使って、「実行指示だけ出して、あとは時々様子を見に行く」スタイルに変えましょう。

Playbookの書き方

- name: Long running operation (OS Update)
  ansible.builtin.dnf:
    name: '*'
    state: latest
  async: 3600        # 最大待ち時間 (秒)
  poll: 30           # 30秒ごとに完了チェックをする

投げっぱなし (Fire and Forget)

poll: 0 にすると、Ansibleは完了を確認せずに次のタスクへ進みます（または終了します）。
「ログ収集エージェントのインストーラーをキックして終わり」といった場合に便利です。

- name: Kick installer
  ansible.builtin.shell: /opt/install_agent.sh
  async: 600
  poll: 0            # 待たない！

---

第6章：ベンチマーク測定（Before / After）

チューニングの効果を実感するために、実行時間を計測しましょう。
time コマンドを使うのが一番簡単ですが、Ansibleには Profile Tasks という便利なコールバックプラグインがあります。

プロファイリングの有効化

ansible.cfg に以下を追記します。

[defaults]
callbacks_enabled = profile_tasks

これを設定すると、Playbook実行後に「どのタスクに何秒かかったか」のランキングが表示されるようになります。

Tuesday 20 January 2026  10:00:00 +0900 (0:00:05.123)       0:00:20.456 ******* =============================================================================== 
Install Apache --------------------------------------------------------- 10.52s
Update System ----------------------------------------------------------- 8.21s
...

これでボトルネックになっているタスクを特定し、重点的に改善することができます。

---

まとめ：スピードは正義である

お疲れ様でした！
これで、あなたのAnsibleは数百台規模の環境でもサクサク動く「高速マシン」へと進化しました。

今回の重要ポイント：

• forks を増やして並列度を上げるのが基本中の基本。
• pipelining = True でSSH接続のオーバーヘッドを削減する。
• strategy: free や async を使って、待ち時間を最小化する。
• Mitogen は爆速だが、導入には互換性チェックが必要。

実行時間が短くなれば、トライ＆エラーの回数が増やせます。
それはすなわち、エンジニアの学習速度と品質向上に直結するということです。
たかがチューニングと侮らず、快適な自動化ライフを手に入れてください。

さて、高速化してPlaybookをガンガン回せるようになると、今度は「標準モジュールだけではやりたいことができない」という壁にぶつかることがあります。
「社内独自のAPIを叩きたい」「特殊な設定ファイルを操作したい」…そんな時どうするか？

次回、応用講座 第4回は「標準機能で足りないなら。PythonによるCustom Module開発入門」です。
ついにAnsibleの中身、Pythonの世界へ踏み込みます。
自分だけの専用モジュールを作って、Ansibleを自由に拡張する方法を学びましょう。プログラミングの知識が少し必要ですが、解説しますのでご安心を！