ControlPersist 및 Pipelining을 활용한 Ansible 성능 극대화

ControlPersist 및 Pipelining을 통한 Ansible 성능 극대화

Ansible은 IT 인프라를 자동화하고 구성 관리 및 애플리케이션 배포를 대규모로 가능하게 하는 강력한 도구입니다. 그러나 대규모 환경 또는 많은 수의 노드를 관리할 때 각 작업마다 SSH 연결을 설정하는 고유한 오버헤드가 상당한 병목 현상이 될 수 있습니다. 이는 플레이북 실행 시간을 고통스러울 정도로 느리게 만들 수 있습니다. 다행히 Ansible은 ControlPersist 및 Pipelining이라는 두 가지 강력한 기능을 제공하여 Ansible이 관리되는 노드와 통신하는 방식을 최적화함으로써 성능을 극적으로 향상시킬 수 있습니다.

이 가이드에서는 ControlPersist 및 Pipelining을 이해하고 구현하는 방법을 설명합니다. 이러한 기술을 활용하면 특히 수백 또는 수천 개의 호스트가 있는 환경에서 실행 시간을 크게 줄여 Ansible 자동화를 보다 효율적이고 반응적으로 만들 수 있습니다. 이러한 최적화를 마스터하는 것은 Ansible 배포를 효과적으로 확장하려는 모든 사람에게 중요합니다.

Ansible의 기본 연결 동작 이해

기본적으로 Ansible은 플레이북 내에서 실행되는 모든 작업에 대해 각 관리 호스트에 새 SSH 연결을 설정합니다. 각 연결에 대해 다음 단계를 수행합니다:

SSH 연결 시작: 새 SSH 연결이 설정됩니다.
모듈 전송: Ansible은 필요한 Python 모듈(또는 기타 관련 파일)을 원격 호스트로 전송합니다.
모듈 실행: 모듈이 원격 호스트에서 실행됩니다.
출력 수신: Ansible은 실행 결과를 검색합니다.
연결 종료: SSH 연결이 종료됩니다.

이 접근 방식은 견고하며 각 작업에 대해 깔끔한 상태를 보장하지만, 반복되는 연결 및 모듈 전송 프로세스는 특히 수많은 작업 또는 대규모 인벤토리를 처리할 때 상당한 시간을 소비합니다.

ControlPersist를 통한 연결 최적화

ControlPersist는 초기 명령이 완료된 후에도 지정된 기간 동안 SSH 연결을 열어둘 수 있는 SSH 기능입니다. 이는 동일한 호스트를 대상으로 하는 후속 Ansible 작업이 새 연결을 설정하는 대신 기존의 열린 연결을 재사용할 수 있음을 의미합니다. 이는 SSH 세션 설정과 관련된 지연 시간을 크게 줄입니다.

ControlPersist 작동 방식

ControlPersist가 활성화되면 SSH 클라이언트에 제어 마스터 연결을 유지하도록 지시합니다. 동일한 자격 증명과 옵션을 사용하여 동일한 호스트에 대한 후속 SSH 연결은 이 마스터 연결을 통해 다중화될 수 있습니다. Ansible은 SSH 구성에서 ControlPath 및 ControlPersist 옵션을 설정하여 이를 활용합니다.

Ansible에서 ControlPersist 활성화

ControlPersist는 여러 가지 방법으로 활성화할 수 있습니다:

ansible.cfg를 통해 (글로벌 또는 프로젝트별 설정에 권장):
ansible.cfg 파일(Ansible 프로젝트 디렉터리, ~/.ansible.cfg 또는 /etc/ansible/ansible.cfg에 있음)을 편집하거나 생성합니다. [ssh_connection] 섹션에 다음 구성을 추가합니다:

ini [ssh_connection] ssh_args = -o ControlMaster=auto -o ControlPersist=600 -o ControlPath=~/.ssh/ansible_control_%r@%h:%p
- -o ControlMaster=auto: 연결 공유를 활성화합니다. 마스터 연결이 존재하면 사용하고, 그렇지 않으면 생성합니다.
- -o ControlPersist=600: 제어 연결을 600초(10분) 동안 열어둡니다. 워크플로 및 보안 정책에 따라 이 값을 조정하십시오. 기간이 길수록 재사용 가능성이 높아지지만, 더 많은 리소스가 열린 상태로 유지됩니다.
- -o ControlPath=~/.ssh/ansible_control_%r@%h:%p: 제어 소켓의 경로를 정의합니다. %r은 원격 사용자 이름, %h는 호스트 이름, %p는 포트입니다. 이는 서로 다른 연결에 대해 고유한 소켓을 보장합니다.
환경 변수를 통해:
환경 변수를 사용하여 SSH 인수를 직접 설정할 수 있습니다:

bash export ANSIBLE_SSH_ARGS='-o ControlMaster=auto -o ControlPersist=600 -o ControlPath=~/.ssh/ansible_control_%r@%h:%p' ansible-playbook your_playbook.yml
플레이북을 통해 (이 설정에는 덜 일반적):
가능하지만, 플레이북 자체 내에서 영구 SSH 옵션을 설정하는 것은 일반적으로 권장되지 않습니다. 이는 연결 수준 설정이기 때문입니다. 하지만 완전성을 위해 ansible.builtin.set_fact 또는 유사한 것을 사용하여 영향을 미칠 수 있지만, ansible.cfg가 선호됩니다.

ControlPersist 고려 사항

보안: 승인된 사용자만 제어 소켓에 액세스할 수 있도록 ControlPath가 보호되는지 확인하십시오. 예제의 기본 경로는 일반적으로 사용자 수준 구성에 안전합니다.
리소스 사용량: 연결을 열어두면 제어 노드와 관리 노드 모두에서 리소스가 소비됩니다. 매우 많은 수의 영구 연결이 있는 경우 리소스 사용량을 모니터링하십시오.
연결 재설정: 중간 네트워크 장치 또는 원격 SSH 서버가 ControlPersist보다 짧은 연결 시간 초과를 적용하는 경우 연결이 여전히 끊어질 수 있습니다. ControlPersist는 안정적인 네트워크 환경에서 가장 잘 작동합니다.

Pipelining을 통한 모듈 실행 간소화

Pipelining은 작업 실행 오버헤드를 더욱 줄이는 또 다른 강력한 Ansible 최적화입니다. 모듈을 원격 호스트로 전송하고, 실행하고, 출력을 검색하는 대신, 파이프라이닝은 SSH 연결을 통해 명령을 직접 스트리밍합니다. 이는 Ansible이 원격 파일 시스템에 모듈을 배치하거나 출력을 위한 임시 파일을 생성할 필요가 없다는 것을 의미합니다.

Pipelining 작동 방식

Pipelining이 활성화되면 Ansible은 원격 호스트에서 ssh를 통해 모듈을 직접 실행합니다. 모듈의 표준 출력 및 표준 오류는 동일한 SSH 연결을 통해 Ansible로 다시 파이프됩니다. 이는 Ansible이 원격 파일 시스템에 파일(예: /usr/bin/ansible_module_name 또는 임시 파일)을 작성한 다음 실행할 필요를 없애줍니다. 이는 권한 에스컬레이션이나 원격 파일 시스템과의 중요한 상호 작용이 필요 없는 모듈에 특히 효과적입니다.

Ansible에서 Pipelining 활성화

Pipelining은 ansible.cfg 파일 또는 환경 변수를 통해 활성화됩니다.

ansible.cfg를 통해:
[ssh_connection] 섹션을 추가하거나 수정합니다:

ini [ssh_connection] pipelining = True
환경 변수를 통해:
bash export ANSIBLE_PIPELINING=True ansible-playbook your_playbook.yml

Pipelining 고려 사항

권한 에스컬레이션: Pipelining은 권한 에스컬레이션(예: become: yes 또는 sudo 사용)이 필요 없는 모듈에서 가장 잘 작동합니다. become이 사용될 때 Ansible은 일반적으로 파일을 원격 시스템에 복사해야 합니다. become을 자주 사용하는 경우, 파이프라이닝이 그다지 많은 이점을 제공하지 않거나 특정 모듈 유형에서 문제를 일으킬 수도 있습니다.
모듈 호환성: 대부분의 내장 Ansible 모듈은 파이프라이닝과 잘 작동합니다. 그러나 사용자 지정 모듈 또는 원격 파일 시스템 작업에 크게 의존하는 모듈은 다르게 작동할 수 있습니다. 철저히 테스트하십시오.
연결 안정성: 안정적인 SSH 연결은 파이프라이닝이 올바르게 작동하는 데 중요합니다.
requiretty SSH 설정: Pipelining은 원격 서버의 requiretty SSH 옵션과 호환되지 않습니다. SSH 서버의 /etc/sudoers에 Defaults requiretty가 있는 경우, 이를 비활성화하거나 Ansible이 연결하는 특정 사용자에 대해 !requiretty를 사용해야 할 수 있습니다.

최대 성능을 위해 ControlPersist 및 Pipelining 결합

가장 중요한 성능 향상을 위해서는 ControlPersist와 Pipelining을 모두 활성화하는 것이 강력히 권장됩니다. 이 조합은 연결 설정 및 모듈 실행이라는 두 가지 주요 오버헤드를 해결합니다.

둘 다 활성화되었을 때 ansible.cfg는 다음과 같이 보일 수 있습니다:

[ssh_connection]
ssh_args = -o ControlMaster=auto -o ControlPersist=600 -o ControlPath=~/.ssh/ansible_control_%r@%h:%p
pipelining = True

둘 다 활성화된 경우:

Ansible은 SSH 연결을 시작하고 존재하지 않으면 ControlMaster를 설정합니다 (ControlPersist).
후속 작업의 경우 기존의 열린 연결이 재사용됩니다.
모듈은 파일 시스템에 복사되지 않고 스트림을 통해 직접 실행됩니다 (Pipelining).

이러한 시너지는 Ansible이 각 관리 노드와 통신하는 데 소비하는 시간을 극적으로 줄여 플레이북 실행 속도를 훨씬 빠르게 만듭니다.

실제 예시 시나리오

100개의 호스트에서 10개의 간단한 작업을 실행해야 하는 플레이북을 상상해 봅시다.

최적화 없음:
각 작업에는 새 SSH 연결, 모듈 전송, 실행 및 연결 종료가 필요합니다. 이는 100 host * 10 task * (connection_time + module_transfer_time)에 해당합니다. connection_time이 0.5초이고 module_transfer_time이 0.2초라면, 실제 모듈 실행을 제외하고 통신 및 전송에만 100 * 10 * 0.7 = 700초의 오버헤드가 발생합니다.

ControlPersist 및 Pipelining 활성화:

각 호스트의 첫 번째 작업은 초기 연결을 설정하고 ControlMaster를 설정합니다.
해당 호스트의 후속 9개 작업은 열린 연결을 재사용하고 모듈 실행을 스트리밍합니다.

호스트당 오버헤드는 connection_time + (9 * minimal_streaming_overhead)에 가까워집니다. 전체 시간은 크게 줄어들고, 플레이북 실행 시간의 대부분은 통신 메커니즘이 아닌 모듈이 수행하는 실제 작업에 할애됩니다.

주의할 점

이러한 최적화는 강력하지만, 고려 없이 보편적으로 적용할 수 있는 것은 아닙니다:

엄격한 방화벽 또는 네트워크 제한이 있는 환경: 잦은 연결 끊김 또는 상태 저장 검사가 ControlPersist에 방해가 될 수 있습니다.
고보안 환경: 장기 지속 SSH 연결은 고도로 규제된 환경에서 보안 문제가 될 수 있습니다. 그에 따라 ControlPersist 기간을 조정하십시오.
become 및 파일 작업에 크게 의존하는 플레이북: become이 지속적으로 사용될 때 파일 작업이 종종 필요하므로 Pipelining의 효과가 감소합니다. 성능 영향을 테스트하십시오.

결론

관리되는 노드와의 Ansible 통신을 최적화하는 것은 효율적이고 확장 가능한 자동화를 위한 핵심 단계입니다. ControlPersist 및 Pipelining을 이해하고 구현함으로써 플레이북 실행 시간을 획기적으로 단축할 수 있습니다. ControlPersist는 SSH 연결을 유지하여 연결 오버헤드를 줄이고, Pipelining은 모듈 실행을 스트리밍하여 파일 전송의 필요성을 없앱니다. 주로 ansible.cfg를 통해 이 두 가지 설정을 결합하는 것은 상당한 수의 호스트를 관리하거나 복잡한 플레이북을 실행하는 모든 Ansible 사용자에게 모범 사례입니다. 항상 특정 환경에서 이러한 구성을 테스트하여 성능을 미세 조정하고 호환성을 보장하십시오.