Ansibleは「遅い」と嘆く前に。Fact収集の極致とカスタムFactによる高速化戦略
「Ansibleの実行が遅い」。
数台の検証環境ならまだしも、数百台規模のフリートを管理するSREにとって、これはもはや「IaCの敗北」を意味します。Playbookの冒頭で毎回発生する `Gathering Facts` のあの待ち時間。あれをただの儀式だと思っていませんか？
実は、Ansibleの真の力は「いかに情報を収集し、いかに情報を制御するか」にあります。今日は、デフォルト設定を疑い、Fact収集を極限まで最適化し、カスタムFactで動的変数をスマートに操る、現場で生き残るための「プロの技術」を伝授します。
—
1. Gather Factsの「聖域」にメスを入れる
デフォルト設定の `gather_facts: yes` は、すべてのモジュールがターゲットノードのOS、ネットワーク、ハードウェア情報を網羅的に収集します。しかし、あなたが「特定のディレクトリのパーミッションを変更するだけ」のタスクのために、毎回全OS情報を取得する必要があるでしょうか？
解決策：`smart` と `caching` の合わせ技
実行時間を劇的に変えるのは、`smart` モードとRedisやMemcachedを用いたキャッシングです。
ansible.cfg の推奨設定:
[defaults]
Fact収集をインテリジェントに制御
gather_subset = !all,min # minセット（ネットワーク・OS情報）のみ取得
gathering = smart # キャッシュがあればそれを利用、なければ収集
RedisをFactキャッシュのバックエンドに指定（高速・永続化）
fact_caching = redis
fact_caching_connection = localhost:6379:0
fact_caching_timeout = 86400 # 24時間保持
これだけで、再実行時のオーバーヘッドはゼロに近づきます。
—
2. カスタムFact：ターゲットノードを「賢く」する
「環境ごとに変数を変えたいが、Playbookに全部書くとカオスになる」。そんな時は、ターゲットノード側にFactを配置する `/etc/ansible/facts.d/` を使いましょう。
実践：動的変数管理の神パターン
ターゲットのOS内で `my_config.fact` (JSONまたはINI形式) を置いておくと、Ansibleはそれを `ansible_local.my_config` として自動的に読み込みます。
ターゲットノードの `/etc/ansible/facts.d/app_env.fact`:
{
“role”: “web-server”,
“version”: “v2.1.0”,
“db_enabled”: true
}
Playbookでの呼び出し:
- name: 設定値に応じたタスクの分岐
debug:
msg: “Deploying {{ ansible_local.app_env.role }} version {{ ansible_local.app_env.version }}”
when: ansible_local.app_env.db_enabled | bool
なぜこれが強いのか？
外部の変数ファイル（`group_vars` など）を肥大化させることなく、ノード自体が「自分の役割」を知っている状態（Self-describing infrastructure）を作れるからです。
—
3. 生産性を爆上げする「プロの道具箱」
VS Code 必須拡張機能
- Ansible (Red Hat公式): 言うまでもない必須。YAMLの補完とエラー検知の精度が違います。
- YAML (Red Hat): `ansible-lint` との連携を意識し、フォーマットを統一させるために必須。
チーム開発の「鉄の掟」
1. `ansible-lint` をCIに組み込む: 個人の感性でコードを書かせない。`.ansible-lint` 設定ファイルをリポジトリルートに置き、厳格なルールを強制します。
2. `idempotency`（冪等性）のテスト: モジュールを使わず `shell` や `command` を使った場合は、必ず `creates` または `removes` 引数を指定する。これがないコードは、チーム内では「未完成」とみなします。
—
4. 実践：爆速化のためのベストプラクティス構成例
チームで共有すべき、美しく保守性の高いディレクトリ構造です。
.
├── ansible.cfg # プロジェクト固有の最適化設定
├── inventory/
│ ├── production/
│ └── staging/
├── roles/
│ └── common/
│ └── tasks/
│ └── setup_custom_facts.yml # 各ノードにカスタムFactを配備するタスク
└── site.yml
`setup_custom_facts.yml` の極意:
- name: Ensure facts directory exists
file:
path: /etc/ansible/facts.d
state: directory
mode: ‘0755’
- name: Deploy dynamic configuration
copy:
content: “{{ custom_fact_content | to_json }}”
dest: /etc/ansible/facts.d/app_env.fact
—
最後に：SREとして、道具に溺れるな
Ansibleのチューニングは、突き詰めれば「情報の取得コストを最小化し、冪等性を最大化する」という戦いです。`gather_facts` を最適化し、カスタムFactでノードに知性を持たせることは、単なる高速化ではありません。それは、インフラの変更が「いつ、誰が実行しても同じ結果になる」という、信頼性への投資です。
今日からあなたのPlaybookの先頭に `gather_facts: smart` を書き加えてください。それだけで、チーム全体の待ち時間が、毎日数分ずつ返ってきます。
さあ、次はどのボトルネックを潰しましょうか？