AnsibleのStrategy設計入門｜linear・free・host_pinnedで複数ホストの並列実行を制御する方法

この記事の監修：宮崎智広（Linux実務・教育歴20年以上・受講者3,100名超）

ＨＯＭＥ＞ Linux技術リナックスマスター.JP（Linuxマスター.JP）＞ Ansible ＞ AnsibleのStrategy設計入門｜linear・free・host_pinnedで複数ホストの並列実行を制御する方法

「1台が遅れると全体が止まる。なのに全体が止まって手が付けられない」
複数サーバーへのAnsible実行で、こんな状況に直面したことはないだろうか。
あるいは、100台規模でパッケージ更新を走らせたとき「全ホストがタスク1を終えるまで次に進めない」という無駄な待機時間に悩んだことはないだろうか。

こうした並列実行の動作を制御するのがAnsibleのstrategy（ストラテジー）設定だ。
strategyはPlaybookに一行加えるだけで動作が変わるが、「どのホストがいつ次のタスクへ進めるか」という挙動を根本的に変えるため、理解なしに切り替えるとホスト間の状態不整合を招くことがある。

この記事では、AnsibleのStrategy（linear・free・host_pinned）の仕組みを設計レベルで解説する。
forksとの組み合わせ方、serialとの使い分け、トラブルシュートまでを整理し、ホスト数が増えてきたチームが直面する並列実行の課題に答える。

この記事のポイント

・AnsibleのStrategyは「どのホストがいつ次のタスクへ進めるか」を制御する設定で、linear・free・host_pinnedの3種がある
・linearはデフォルト。全ホストが同じタスクを完了してから次に進む（遅いホストがボトルネックになる）
・freeは完了したホストが即座に次のタスクへ先行できる。ホスト間に依存がない処理で時間を短縮できる
・forksが「同時接続数の上限」、serialが「何ホストずつグループ化するか」を制御する点でstrategyとは別の軸になる

「このままじゃマズい」と感じていませんか？

参考書を開く気力もない、同年代に取り残される不安——
でも安心してください。プロのエンジニアはコマンドを暗記していません。
「現場で使える型」を効率よく使いこなしているだけです。

姓・名・メールの3つだけ／30秒／解除は3秒／詳細はこちら

AnsibleのStrategy（実行戦略）とは何か

Ansibleが複数のホストに対してPlaybookを実行するとき、内部的には「タスクごとに全ホストをループする」という構造になっている。

このループの進み方を決めるのがstrategyだ。

デフォルトのstrategyはlinearと呼ばれ、次のように動作する。

・タスク1を全ホストが完了する
・タスク2へ全ホストが進む
・タスク3を全ホストが完了する

この動作は「全ホストが常に同じタスクにいる」ことを保証するため、状態の追跡が容易だ。
しかし裏を返せば、「タスク1を最も遅く完了したホストが全体のペースを決める」ことになる。

ホスト数が10台・50台・100台と増えるにつれ、この「最遅ホスト依存」が実行時間に無視できない影響を与えてくる。
strategyを理解することは、Ansibleを大規模環境で運用する上で避けて通れない設計判断だ。

linear・free・host_pinnedの動作と特徴

1. linear（デフォルト）

Ansibleのデフォルトstrategyはlinearだ。明示的に指定しなければ常にlinearが使われる。

linearの動作の特徴:
・全ホストが「タスクN」を完了するまで、全ホストが「タスクN+1」へ進まない
・遅いホストや応答が遅延するホストが全体のボトルネックになる
・Playbookの実行中、全ホストが常に同じタスク段階にある

linearが適している場面:
・ロールバックを考慮したデプロイ（全ホストが同じ状態にある方が判断しやすい）
・タスク間に依存関係がある変更（「設定ファイル更新→サービス再起動」を全ホスト揃えたい場合）
・問題発生時にどのホストがどのタスクにいるかを即座に把握したい場面

2. free

strategy: freeを指定すると、タスクが完了したホストが即座に次のタスクへ進む。
遅いホストの完了を待たずに、先に完了したホストは先行して次のタスクを実行する。

freeの動作の特徴:
・hostAが「タスク3」を実行している間、hostBはまだ「タスク1」にいることがある
・全体の実行時間は最速ホストの時間に近づく（遅いホストのペースに引きずられない）
・どのホストがどのタスクにいるかは実行中にばらつきが生じる

freeが適している場面:
・パッケージ更新（dnf/apt）のように各ホストが独立してこなせる処理
・ホスト間に依存がない設定ファイルの配布・適用
・大規模環境でトータルの実行時間を短縮したい場面

3. host_pinned

strategy: host_pinnedはfreeと同じ「完了したホストが次のタスクへ先行する」動作だが、Ansibleのforks数を厳密に守る点が異なる。

freeは理論上、新しいホストへの接続を積極的に増やすことがある。
host_pinnedは「同時に接続するホスト数をforksの値以内に厳密に抑える」ため、大規模環境でコントロールノードのリソース上限を守りながら並列実行したい場合に使う。

動作上はfreeとほぼ同じだが、接続数の制御が厳密になる点が違いだ。

Ansibleのstrategyを実機ハンズオンで体験したい方は、Ansibleハンズオン講座（ansible.linuxmaster.jp）も参考にしていただきたい。strategy設計を含む実践的なPlaybook設計をRHEL 10環境で学べる内容になっている。

PlaybookへのStrategy設定方法

1. play単位でstrategyを指定する

strategyはPlaybookのplay定義の中に記述する。

--- - name: パッケージを高速並列更新する hosts: all strategy: free tasks: - name: 全パッケージを最新化する ansible.builtin.dnf: name: "*" state: latest

strategy: freeをplay直下に書くだけで、そのplay内のタスク実行がfreeモードに変わる。
複数のplayがある場合、play単位で異なるstrategyを指定できる。

--- # play1: 設定変更は全ホスト足並みを揃える（linear） - name: Nginxの設定ファイルを配布する hosts: webservers strategy: linear tasks: - name: nginx.confを配置する ansible.builtin.template: src: nginx.conf.j2 dest: /etc/nginx/nginx.conf # play2: パッケージ更新はホストごとに先行させる（free） - name: セキュリティパッチを適用する hosts: webservers strategy: free tasks: - name: セキュリティパッチをインストールする ansible.builtin.dnf: name: "*" state: latest

設定変更はlinearで全ホストの整合性を保ち、パッケージ更新はfreeで高速化するという使い分けが実務でよく見られるパターンだ。

2. ansible.cfgでデフォルトstrategyを変更する

プロジェクト全体のデフォルトstrategyをansible.cfgで変更することもできる。


[defaults]
strategy = free

ただし、ansible.cfgのデフォルト変更は全Playbookに影響するため注意が必要だ。
「特定のPlaybookだけfree」という意図でansible.cfgを変更すると、他のPlaybookが意図せずfreeで実行されてしまう。

通常はPlaybook単位でstrategyを明示指定し、ansible.cfgのデフォルトは変更しない運用が安全だ。

forksとserialとの組み合わせ設計

strategyを理解する上で、forksとserialとの違いを整理しておくことが重要だ。
この3つは混同されやすいが、それぞれ制御する対象が異なる。

1. forksの役割（同時接続数の上限）

forksはAnsibleのコントロールノードが同時に接続するホスト数の上限だ。デフォルト値は5。

ansible.cfgで変更する場合:


[defaults]
forks = 20

strategyとforksの関係は次のようになる。

・strategy: linearでforks=20の場合: 最大20ホスト同時にタスクを実行し、全ホスト完了後に次のタスクへ進む
・strategy: freeでforks=20の場合: 最大20ホスト同時接続で、完了したホストが即座に次のタスクへ先行する

forksを増やすとコントロールノードのCPU・メモリ・SSH接続数が増加するため、ホスト数に応じた適切な値に設定する必要がある。

2. serialとstrategyの違いと組み合わせ

serialはPlaybookの「何ホストずつグループ化してPlayを実行するか」を制御する設定だ。
ローリングアップデート（全台同時ではなく段階的に更新する）に使う。

strategyとserialの違い:
・strategyは「1つのPlay内でタスクをどの順番で実行するか」を制御する
・serialは「Playを実行するホストのグループサイズ」を制御する

この2つは独立しており、組み合わせて使うことができる。

--- - name: Webサーバーをローリング更新する hosts: webservers # 合計20台とする serial: "20%" # 4台ずつグループ化（20% = 4台） strategy: free # 各グループ内ではfreeで並列実行 tasks: - name: アプリケーションを更新する ansible.builtin.dnf: name: myapp state: latest - name: アプリケーションを再起動する ansible.builtin.service: name: myapp state: restarted

この設定の動作:
・20台のうち4台を第1グループとしてPlayを実行する
・第1グループ内ではstrategy: freeで4台が並列実行（完了したホストが先行）
・第1グループ全台がPlayを完了したら第2グループの4台を実行する

「段階的にデプロイしながら、各段階内では高速に処理したい」という要件にマッチする設計だ。

トラブルシュート：並列実行で起きる問題と対処

1. freeに切り替えたら依存するタスクが先に実行された

症状: strategy: freeにしたところ、hostAがタスク3を実行している間にhostBはまだタスク1にいて、タスク3はタスク1と2の完了が前提なのにエラーになった。

原因: freeはホスト間の同期を取らない。「全ホストがタスクNを終えてからタスクN+1へ」という保証がないため、ホスト間に依存関係があるタスク群にfreeを適用すると不整合が起きる。

対処: タスク間に依存関係がある部分はlinearを使う。または「依存のある前半はlinearで別play」「後半の独立した処理はfreeで別play」と分割する構成が有効だ。

2. freeでhandlerが想定外のタイミングで実行された

症状: strategy: freeを使ったところ、設定変更のhandler（サービス再起動）が期待と異なるタイミングで実行された。

原因: handlerは「同一ホスト内ではplay終了時にflushed」されるが、freeではホストごとにplayの終了タイミングがずれる。「全ホストの設定変更が終わってから全ホストでhandlerを実行したい」という意図とはずれる。

対処: handler実行タイミングに強い要件がある場合、meta: flush_handlersタスクを明示的に挿入して任意のポイントでhandlerを実行させる。handler実行順序に強い依存がある場合はlinearを選択する。

tasks: - name: 設定ファイルを配布する ansible.builtin.template: src: myapp.conf.j2 dest: /etc/myapp/myapp.conf notify: myapp を再起動する # この時点でhandlerを強制実行する（全ホスト待機せず即実行） - name: handlerをここで強制実行する ansible.builtin.meta: flush_handlers

本記事のまとめ

AnsibleのStrategyは、複数ホストへの並列実行の動作を設計する核心的な設定だ。
3つのstrategyと関連設定の使い分けを整理する。

設定・概念	制御する対象	主な用途
strategy: linear	タスク実行の同期（全ホスト揃えて次へ）	整合性重視のデプロイ・ロールバック対応
strategy: free	完了ホストの先行（最速に引き上げる）	パッケージ更新・独立した設定適用の高速化
strategy: host_pinned	freeの動作＋forks数の厳密制御	大規模環境でのリソース上限管理
forks	同時接続ホスト数の上限	コントロールノードのCPU・メモリ・接続数の管理
serial	Playを実行するホストのグループサイズ	ローリングアップデート（段階的デプロイ）

strategyの選定は「全ホストの状態整合性を優先するか、実行時間の短縮を優先するか」というトレードオフだ。
ホスト数が少ないうちはlinearで始め、規模が拡大してから実測でfreeへの切り替えを検討するのが安全な進め方だ。

Ansibleのこうした設計判断を実機で体験したい方は、Ansibleハンズオン講座（ansible.linuxmaster.jp）もあわせてご覧いただきたい。strategy設計を含む実践的なPlaybook設計をRHEL 10環境で少人数ハンズオンで学べる内容になっている。

現場で通用する安全なLinuxサーバー構築の「型」を体系的に身につけたい方へ、20年以上の運用経験を持つ現役エンジニアが基礎から教えます。
Linux無料マニュアルを受け取る＞＞

無料メルマガで学習を続ける

Linuxの実践スキルをメールで毎週お届け。
登録は30秒、解除もいつでも可。

登録無料・いつでも解除できます

暗記不要・1時間後にはサーバーが動く

3,100名以上が実践した「型」を無料で公開中

プロのエンジニアはコマンドを暗記していません。
「現場で使える型」を効率よく使いこなしているだけです。
その「型」を図解60Pにまとめた入門マニュアルを、完全無料でプレゼントしています。