DevOps 지식 허브
DevOps 지식 허브

Ansible 팩트 캐싱 구성에 대한 종합 가이드

팩트 캐싱 구성을 마스터하여 Ansible 플레이북 실행 속도를 최적화하십시오. 이 가이드에서는 `ansible.cfg` 내에서 로컬 JSON 파일 캐싱과 고성능 Redis 캐싱 메커니즘을 모두 설정하는 단계별 지침을 제공합니다. SSH 오버헤드를 줄이고 적절한 시간 초과를 설정하며 대규모 환경에서 상당한 성능 향상을 위해 팩트 캐시를 효과적으로 관리하는 방법을 알아보십시오.

34 조회수

Ansible 팩 캐싱 구성을 위한 종합 가이드

Ansible이 관리 대상 노드에 대한 팩을 수집하는 능력은 동적 인벤토리, 조건부 실행 및 상세 보고에 매우 중요합니다. 그러나 모든 플레이북 실행에 대해 gather_facts: true를 실행하면, 특히 수백 또는 수천 개의 호스트가 있는 환경에서는 전체 플레이북 실행 시간을 상당히 늘릴 수 있습니다. 이 성능 병목 현상은 Ansible 팩 캐싱을 통해 효과적으로 해결됩니다.

팩 캐싱을 사용하면 Ansible은 이전 실행에서 수집된 팩을 저장하고 후속 실행에서 즉시 재사용하여 시간이 많이 걸리는 SSH 연결 및 데이터 수집 프로세스를 건너뛸 수 있습니다. 이 가이드에서는 JSON 파일과 Redis라는 두 가지 주요 방법을 사용하여 팩 캐싱을 구성하고 활용하는 방법을 자세히 설명하며, 자동화 워크플로우에서 상당한 성능 향상을 가능하게 합니다.

Ansible 팩 및 성능 영향 이해

Ansible은 setup 모듈(또는 gather_facts: true를 통해 암시적으로)을 사용하여 팩을 수집합니다. 이러한 팩에는 운영 체제 세부 정보, 네트워크 인터페이스, 설치된 패키지 등이 포함됩니다. 매우 유용하지만 SSH를 통해 이러한 팩을 수집하는 것은 특히 높은 지연 시간 연결이나 대규모 머신 관리를 할 때 느릴 수 있습니다.

주요 성능 이점: 캐싱을 활성화하면 후속 플레이북 실행 시 원격 호스트에서 setup 모듈을 실행하는 대신 로컬 캐시(JSON 파일) 또는 빠른 인메모리 저장소(Redis)에서 팩을 읽습니다.

팩 캐싱 구성 방법

Ansible은 ansible.cfg 파일을 통해 구성되는 여러 캐싱 메커니즘을 지원합니다. 가장 일반적이고 안정적인 두 가지 방법은 JSON 파일 캐싱과 Redis 캐싱입니다.

1. JSON 파일 캐싱 (로컬 저장소)

JSON 캐싱은 팩 데이터를 제어 머신에 직렬화된 파일로 저장하는 가장 간단한 방법입니다. 외부 서비스가 필요하지 않습니다.

ansible.cfg에서 JSON 캐싱 구성

JSON 캐싱을 활성화하려면 캐시 플러그인을 정의하고 파일이 저장될 위치를 지정해야 합니다.

[defaults]
# 사용할 캐싱 플러그인 지정
fact_caching = json

# 팩 파일이 저장될 디렉토리 지정
fact_caching_connection = /path/to/ansible_facts_cache

# 캐시 만료 시간(초) 설정. 0은 만료되지 않음을 의미합니다.
fact_caching_timeout = 600

매개변수 설명:

  • fact_caching = json: 내장 JSON 캐싱 플러그인을 활성화합니다.
  • fact_caching_connection: 이 디렉토리는 존재해야 하며 Ansible을 실행하는 사용자가 쓸 수 있어야 합니다.
  • fact_caching_timeout: 이 예에서는 팩이 오래된 것으로 간주되며 600초(10분) 후에 다시 수집됩니다.

모범 사례: 최적의 읽기/쓰기 성능을 위해 캐시 디렉토리를 빠른 로컬 저장소(NVMe 드라이브 등)에 배치하십시오.

2. Redis 캐싱 (공유, 고성능 저장소)

Redis는 종종 고성능 캐시 또는 메시지 브로커로 사용되는 인메모리 데이터 구조 저장소입니다. 팩 캐싱에 Redis를 사용하는 것은 여러 사용자 또는 CI/CD 파이프라인이 동일한 캐시에 빠르고 일관되게 액세스해야 하는 팀 환경에 이상적입니다.

Redis 캐싱을 위한 전제 조건

  1. Ansible 제어 머신에서 액세스 가능한 실행 중인 Redis 서버.
  2. 제어 머신에 Python redis 라이브러리가 설치되어 있어야 합니다: pip install redis.

ansible.cfg에서 Redis 캐싱 구성

Redis를 사용할 때 fact_caching_connection은 Redis 연결 매개변수(호스트 및 포트)를 정의하는 데 사용됩니다.

[defaults]
# 사용할 캐싱 플러그인 지정
fact_caching = redis

# 연결 문자열 형식: <host>[:<port>][/<db_number>]
# 기본 포트에서 같은 머신에서 실행되는 경우:
fact_caching_connection = 127.0.0.1:6379/0

# 캐시 만료 시간(초) 설정. Redis의 경우 매우 권장됩니다.
fact_caching_timeout = 3600

Redis 데이터베이스 참고: 마지막 숫자(예: /0)는 사용할 Redis 데이터베이스 인덱스를 지정합니다. Redis가 다른 목적으로 사용되는 경우 충돌을 방지하기 위해 이 인덱스가 Ansible 팩 전용인지 확인하십시오.

플레이북에 캐싱 통합

ansible.cfg를 구성하면 기본 동작이 설정됩니다. 캐싱을 효과적으로 활용하려면 플레이북에서 두 가지 사항을 확인해야 합니다.

  1. 팩을 수집하는 플레이를 실행하여 캐시가 채워집니다.
  2. 후속 플레이는 다시 수집하는 대신 캐시에 의존합니다.

초기 채우기를 위한 팩 수집 강제 실행

플레이북을 처음 실행하거나 타임아웃 후에는 Ansible이 팩 수집 프로세스를 실행합니다.

- name: Play 1 - 팩 수집 및 작업 실행
  hosts: webservers
  gather_facts: true  # 이것이 처음에 캐시를 채웁니다
  tasks:
    - name: 수집된 팩 사용
      debug:
        msg: "OS Family는 {{ ansible_os_family }} 입니다."

후속 실행에서 캐시 활용

fact_caching이 구성된 경우, gather_facts가 true로 설정되고 팩이 타임아웃 기간 내에 있으면 후속 실행은 캐시된 데이터를 자동으로 사용합니다.

그러나 팩 수집을 완전히 건너뛰고 캐시에만 의존하도록 보장하려면(또는 캐시가 누락된 경우 실패), 초기 채우기 후에 gather_facts: false를 사용할 수 있으며, 팩이 여전히 유효하다고 가정합니다.

gather_facts: false를 명시적으로 설정하고 캐싱이 활성화된 경우 Ansible은 먼저 캐시를 확인합니다. 유효한 데이터가 있으면 사용합니다. 그렇지 않으면 팩 없이 진행하며, 이는 팩에 의존하는 작업에 문제를 일으킬 수 있습니다.

중요 동작: gather_facts: true가 사용되면 Ansible은 캐시된 팩이 만료되었거나 누락된 경우에만 원격 팩 수집을 수행합니다.

팩 캐시 관리

때로는 캐시를 수동으로 지워 모든 호스트에서 Ansible이 최신 데이터를 수집하도록 강제해야 할 수 있습니다.

JSON 캐시 지우기

JSON 캐싱을 사용하는 경우 fact_caching_connection에 지정된 디렉토리의 내용을 삭제하기만 하면 됩니다.

# 이전에 정의된 경로를 사용하는 예
rm -rf /path/to/ansible_facts_cache/*

Redis 캐시 지우기

Redis를 사용하는 경우 Ansible과 관련된 키를 선택적으로 지우거나 Ansible에서 사용하는 전체 데이터베이스를 지울 수 있습니다.

기본 Ansible 접두사(일반적으로 인벤토리 소스와 관련됨)와 관련된 모든 키를 지우려면:

# redis-cli에 연결하여 전체 데이터베이스를 플러시합니다(이 예에서는 DB 0).
redis-cli -n 0 FLUSHDB

경고: Redis에서 FLUSHDB 또는 FLUSHALL은 지정된 데이터베이스의 모든 데이터를 삭제하므로 매우 주의해서 사용해야 합니다.

모범 사례 요약

  1. 현명하게 선택: 간단한 단일 사용자 설정 또는 외부 종속성이 제한된 경우 JSON 캐싱을 사용하십시오. 협업 환경 또는 대규모 CI/CD 통합에는 Redis를 사용하십시오.
  2. 현실적인 타임아웃 설정: 성능 이점과 데이터 최신성 간의 균형을 맞추기 위해 fact_caching_timeout을 구성하십시오. 구성이 자주 변경되지 않는 환경에서는 1~24시간의 타임아웃이 일반적입니다.
  3. 구성 확인: 항상 ansible --version을 실행하거나 첫 번째 캐시 실행 결과를 확인하여 캐시 플러그인이 활성화되어 작동하는지 확인하십시오.
  4. 인벤토리 종속성: 팩 캐싱은 정적 또는 동적으로 생성된 인벤토리와 함께 가장 잘 작동합니다. 자주 변경되는 동적 인벤토리 스크립트를 사용하는 경우 캐싱의 이점이 오래된 데이터 또는 오류로 인해 무효화될 수 있습니다.

팩 캐싱을 올바르게 구현하면 Ansible을 완전한 반복 구성 도구에서 각 실행당 최소한의 지연 시간으로 대규모 인프라를 관리할 수 있는 고도로 최적화된 시스템으로 전환할 수 있습니다.