Ansible 포크 조정: 동시성과 리소스 소비의 균형

Ansible의 강점은 에이전트 없는 특성과 동시에 여러 호스트를 관리할 수 있는 능력에 있습니다. 이러한 동시성은 주로 forks 설정에 의해 제어됩니다. forks 매개변수를 적절히 조정하는 것은 자동화 작업에서 최적의 처리량을 달성하는 데 중요합니다. 포크가 너무 적으면 플레이북 실행 속도가 느려지고, 너무 많으면 컨트롤 노드나 관리 대상 노드에 과부하가 걸릴 위험이 있습니다.

이 글은 Ansible 포크가 무엇인지, 성능에 어떤 영향을 미치는지, 특정 환경에 최적의 값을 설정하는 방법론을 이해하기 위한 실용적인 가이드입니다. 이 설정을 정의할 수 있는 위치와 과도한 동시성에 따른 트레이드오프를 살펴보겠습니다.

Ansible 포크 이해하기

Ansible 용어에서 포크는 Ansible 컨트롤 노드가 단일 관리 호스트에 대한 연결을 동시에 관리하기 위해 생성하는 별도의 Python 프로세스를 나타냅니다. 플레이북을 실행할 때 Ansible은 forks에 정의된 수만큼의 프로세스를 시작하여 인벤토리 전체에서 작업을 병렬로 실행합니다.

포크가 성능에 중요한 이유

동시성은 Ansible 속도의 핵심입니다. 업데이트할 서버가 100대인 경우 forks = 100으로 설정하면 Ansible은 모든 서버에 동시에 연결을 시도합니다(연결 제한 및 시간 초과에 따라 다름). 그러나 이러한 병렬 처리에는 비용이 따릅니다.

컨트롤 노드 리소스 소비: 각 포크는 Ansible을 실행하는 머신(컨트롤 노드)의 CPU와 메모리를 소비합니다. 포크 수가 많으면 컨트롤 노드의 리소스가 부족해져 성능 저하, 지연 시간 증가, 잠재적 충돌이 발생할 수 있습니다.
관리 대상 노드 부하: 급속한 연결은 네트워크 스위치나 관리 호스트 자체에 과부하를 줄 수 있습니다. 특히 호스트가 이미 과부하 상태이거나 들어오는 SSH 연결 및 작업 실행을 처리할 CPU 리소스가 제한적인 경우 더욱 그렇습니다.

`forks` 매개변수 구성 위치

forks 값은 여러 위치에서 구성할 수 있으며, 계단식 순서로 이전 설정을 재정의합니다. 이 계층 구조를 이해하는 것은 다양한 프로젝트와 환경에서 일관된 동작을 위해 필수적입니다.

1. Ansible 구성 파일 (`ansible.cfg`)

시스템 전체 기본값을 설정하는 기본적이고 영구적인 위치는 ansible.cfg 파일입니다. 일반적으로 /etc/ansible/ansible.cfg(시스템 전체) 또는 프로젝트 루트 디렉터리(프로젝트별)에 있습니다.

기본 동시성 수준을 설정하려면 [defaults] 섹션을 수정하세요.

# ansible.cfg snippet
[defaults]
# Set the default number of parallel processes
forks = 50

2. 명령줄 재정의 (`-f` 또는 `--forks`)

ansible 명령을 실행하거나 플레이북을 실행할 때 구성 파일 설정을 일시적으로 재정의할 수 있습니다.

# Run a playbook with a specific fork count
ansible-playbook site.yml --forks 25

# Run an ad-hoc command with a specific fork count
ansible all -m ping -f 100

3. 환경 변수

스크립트 기반 실행 또는 CI/CD 파이프라인의 경우 ANSIBLE_FORKS 환경 변수를 설정하면 구성 파일을 수정하지 않고도 동시성을 유연하게 제어할 수 있습니다.

export ANSIBLE_FORKS=30
ansible-playbook site.yml

구성 우선 순위: 명령줄 인수는 환경 변수를 재정의하며, 둘 다 ansible.cfg의 설정을 재정의합니다.

최적의 `forks` 값을 결정하는 방법

완벽한 forks 숫자를 찾는 것은 경험적 테스트를 기반으로 한 반복적인 프로세스입니다. 단일 마법의 숫자는 없습니다. 네트워크 지연 시간, 컨트롤 노드 용량, 대상 노드 기능에 크게 의존합니다.

1단계: 컨트롤 노드 용량 평가

조정하기 전에 제약 조건을 파악하세요. 여유 CPU, 메모리 및 네트워크 용량을 갖춘 전용 컨트롤 노드는 일반적으로 VPN을 통해 Ansible을 실행하는 노트북보다 더 많은 포크를 처리할 수 있습니다. 정확한 숫자는 워크로드, 연결 플러그인, 관리 호스트의 Python 시작 오버헤드, 각 작업이 반환하는 데이터 양에 따라 달라집니다.

모범 사례: 중간 규모 플레이북을 실행하는 동안 컨트롤 노드의 CPU 및 메모리 사용량을 모니터링하세요. 작업 실행이 완료되기 전에 CPU 사용량이 지속적으로 100%에 도달하면 포크 수가 하드웨어에 비해 너무 높은 것입니다.

2단계: 대상 노드 허용 오차 평가

관리 대상 노드가 중요한 서비스를 실행 중이거나 이미 많이 사용 중인 경우 forks를 너무 높게 설정하면 해당 서버의 성능 저하(예: 느린 SSH 응답, 서비스 중단)로 이어질 수 있습니다.

팁: 사실 수집과 같은 비침습적 작업만 실행해야 하는 경우 더 높은 포크를 사용할 수 있습니다. 대규모 애플리케이션 업데이트를 배포하는 경우 프로덕션 시스템에 대한 동시 부하를 최소화하기 위해 포크를 줄이는 것이 좋습니다.

3단계: 경험적 부하 테스트

보수적인 값(예: 20 또는 50)으로 시작하여 표준 대표 플레이북의 총 실행 시간을 측정하면서 점진적으로 증가시킵니다.

테스트 반복	포크 설정	총 실행 시간
1	20	450초
2	50	210초
3	100	185초
4	150	190초 (약간 증가)

이 샘플 실행에서 유용한 균형점은 약 100 포크입니다. 150으로 증가해도 시간 절감 효과가 없었고 불필요한 오버헤드가 추가되었기 때문입니다. 이것을 벤치마크가 아닌 테스트 패턴으로 취급하세요. 사용자 환경에 따라 20 포크, 75 포크 또는 완전히 다른 값에서 결과가 평평해질 수 있습니다.

연결 유형과의 상호 작용

forks 설정은 선택한 연결 플러그인(가장 일반적으로 ssh)과 함께 작동합니다.

SSH 연결 지연 시간

연결 지연 시간이 높은 경우(예: 대륙 간 또는 느린 VPN) 포크를 늘려도 수익이 감소할 수 있습니다. 연결 설정을 기다리는 시간이 실행 시간을 지배하기 때문입니다. 이러한 경우 시간 초과 설정을 줄이는 것이 포크를 늘리는 것보다 더 유용할 수 있습니다.

영구 연결 (Async/ControlPersist)

ControlPersist(Ansible 실행 간에 SSH 소켓을 열린 상태로 유지)와 같은 최신 SSH 구성을 사용하는 환경에서는 초기 연결 설정의 오버헤드가 분산됩니다. 이를 통해 초기 연결 설정 시간에 심각한 불이익 없이 더 높은 포크 수를 안전하게 사용할 수 있습니다.

일반적인 함정 피하기

forks를 너무 높게 설정하는 것은 일반적인 성능 실수입니다. 다음은 중요한 경고입니다.

경고: 대규모 인벤토리에서 forks를 총 호스트 수와 동일하게 설정할 때는 주의하세요. 소규모 실험실에서는 괜찮을 수 있지만 프로덕션에서는 먼저 테스트해야 합니다. 대규모 인벤토리의 경우 합리적인 포크 수를 serial, throttle, 배치 처리 또는 별도의 인벤토리 그룹과 결합하여 단일 플레이북 실행이 연결 폭풍을 일으키지 않도록 하세요.

포크를 늘릴 때 Cannot connect to host 또는 Connection timed out과 관련된 오류가 관찰되면 컨트롤 노드의 네트워크 스택 또는 관리 노드의 SSH 데몬 용량을 초과했음을 나타내는 강력한 신호입니다.

실용적인 조정 워크스루

Ansible 포크를 조정하는 가장 쉬운 방법은 환경에서 일반적인 작업처럼 보이는 하나의 플레이북을 사용하는 것입니다. ping 테스트는 연결성을 확인하는 데 유용하지만 실제 배포 압력에 대해 많은 것을 알려주기에는 너무 가볍습니다. 더 나은 테스트는 패키지 메타데이터 새로 고침, 소규모 템플릿 배포, 서비스 상태 확인 또는 가장 자주 실행하는 역할의 드라이 런과 같은 것입니다.

현재 동작을 기록하는 것부터 시작하세요. 기존 설정으로 플레이북을 실행하고 경과 시간, 실패한 호스트 수, 컨트롤 노드의 비정상적인 점을 저장하세요. 복잡한 벤치마크 도구는 필요하지 않습니다. time ansible-playbook -i inventory site.yml --limit web은 첫 번째 시도에 충분한 경우가 많습니다. 다른 터미널에서 운영 체제에서 제공하는 top, htop, vm_stat, iostat 등으로 컨트롤 노드를 모니터링하세요. 컨트롤 노드가 스와핑 중이라면 포크를 위쪽으로 조정해도 도움이 되지 않습니다.

그런 다음 천천히 증가시키세요. 현재 값이 5이면 10, 20, 40을 시도해 보세요. 현재 값이 50이면 수백으로 건너뛰기 전에 75와 100을 시도해 보세요. 각 실행 후 세 가지 질문을 하세요.

플레이북이 더 빨리 끝났습니까?
실패 또는 재시도가 나타났습니까?
CPU, 메모리, 파일 디스크립터 또는 네트워크 사용량이 불편해졌습니까?

최상의 값은 일반적으로 곡선이 평평해지기 직전입니다. 20 포크가 12분, 50 포크가 6분, 100 포크가 5분 40초가 걸린다면 100의 추가 압력은 가치가 없을 수 있습니다. 저장된 초가 중요하고 환경이 부하 상태에서 테스트되지 않은 경우 일반적으로 해당 경우 50을 선택합니다.

서비스를 다시 시작하거나, 데이터베이스 마이그레이션을 실행하거나, 캐시를 다시 빌드하거나, 공유 스토리지에 영향을 주는 플레이에는 특히 보수적으로 접근하세요. 높은 동시성은 모든 호스트가 동시에 비용이 많이 드는 작업을 수행하게 만들 수 있습니다. 무해한 파일 검사에는 정확히 원하는 것일 수 있지만, 모든 애플리케이션 노드가 함께 다시 시작되거나 모든 데이터베이스 복제본이 동시에 파일 압축을 시작하는 경우 좋지 않은 날이 될 수 있습니다.

출력 볼륨에도 주의를 기울이세요. 각 호스트에서 몇 줄을 반환하는 작업은 수백 대의 머신에서 대규모 명령 출력, 패키지 관리자 로그 또는 JSON 사실을 스트리밍하는 작업과 다르게 동작합니다. 컨트롤 노드는 해당 데이터를 수집, 구문 분석 및 출력해야 합니다. 관리 호스트가 유휴 상태임에도 실행 속도가 느리게 느껴지면 포크를 다시 늘리기 전에 노이즈가 많은 출력을 줄이거나, 필요한 것만 등록하거나, 사실 수집 범위를 좁혀보세요.

동시성에는 인간적인 측면도 있습니다. 20개 중 3개 호스트에서 실패한 플레이북은 추론하기 쉽습니다. 800개 중 47개 호스트에서 실패한 플레이북은 긴 보고서를 생성하고 첫 번째 유용한 오류가 묻힐 수 있습니다. 포크가 높으면 실행 시간은 단축될 수 있지만 실패 분석이 더 복잡해집니다. 운영 작업의 경우 작업이 완전히 자동화되고 실패에 대한 좋은 알림이 이미 설정되어 있지 않는 한 출력을 읽을 수 있게 유지하는 포크 설정을 선호합니다.

forks는 사용할 수 있는 유일한 제어 수단이 아닙니다. 호스트를 배치로 롤아웃하려면 serial을 사용하세요.

- name: Deploy web application safely
  hosts: webservers
  serial: 10
  tasks:
    - name: Update application package
      ansible.builtin.package:
        name: myapp
        state: latest

serial: 10을 사용하면 Ansible은 forks가 훨씬 높더라도 해당 플레이에 대해 한 번에 10개의 호스트를 처리합니다. 이렇게 하면 forks의 전역 동시성 상한선과 serial의 롤아웃 정책이 제공됩니다.

하나의 작업이 나머지 플레이보다 더 민감한 경우 throttle을 사용하세요.

- name: Restart API service in small groups
  ansible.builtin.service:
    name: api
    state: restarted
  throttle: 3

이렇게 하면 이전 작업은 광범위하게 실행하면서 위험한 작업을 제한할 수 있습니다. 단 하나의 단계만 제한이 필요한 경우 전체 실행에 대해 forks를 낮추는 것보다 더 깔끔한 옵션입니다.

CI 시스템의 경우 프로젝트 ansible.cfg 또는 파이프라인 구성에 선택한 값을 기록해 두세요. 숨겨진 로컬 설정은 일반적인 혼란의 원인입니다. 한 엔지니어는 forks = 5로 노트북에서 실행하고, 다른 엔지니어는 ANSIBLE_FORKS=100으로 CI에서 실행하면 갑자기 동일한 플레이북이 매우 다르게 동작합니다. 기본값을 지루하고 명시적으로 유지하고 알려진 경우에만 재정의하세요.

잘 작동하는 한 가지 패턴은 리포지토리에 보수적인 기본값을 유지하는 것입니다.

[defaults]
forks = 25

그런 다음 알려진 안전한 작업에 대해 재정의합니다.

ANSIBLE_FORKS=75 ansible-playbook -i inventory.ini facts-refresh.yml

이렇게 하면 호출 지점에서 예외를 확인할 수 있습니다. 정상 호스트에 대한 사실 새로 고침은 롤링 배포 또는 재시작이 많은 유지 관리 플레이보다 더 많은 동시성을 허용할 수 있습니다. forks를 한 번 조정하고 잊어버리는 전역 숫자가 아니라 합리적인 기본값을 가진 워크로드별 설정으로 취급하세요.

Ansible Automation Platform, AWX 또는 다른 실행기를 사용하는 경우 플레이북 프로세스 외부에 추가 동시성 제어가 있을 수 있음을 기억하세요. 작업 분할, 인스턴스 그룹 용량, 컨테이너 제한 및 실행 환경 리소스는 모두 forks의 효과를 제한하거나 증폭시킬 수 있습니다. 실행이 예상과 다를 경우 Ansible 설정과 주변 스케줄러를 모두 확인하세요.