DevOps 도구 및 베스트 프랙티스 마스터 - DevOps 지식 허브 DevOps 도구 및 베스트 프랙티스 마스터 - DevOps 지식 허브

ZLib 압축을 통한 SSH 성능 최적화 완벽 가이드

SSH Zlib 압축이 언제 도움이 되고, 언제 해가 되는지, 그리고 느린 링크와 텍스트 중심 전송을 위해 안전하게 활성화하는 방법을 알아보세요.

ZLib 압축을 통한 SSH 성능 최적화 완벽 가이드

Secure Shell(SSH)은 신뢰할 수 있지만, 느린 WAN 링크, VPN 또는 대화형 터미널 세션에서는 SSH 성능이 저하될 수 있습니다. 데이터가 텍스트 위주이고 네트워크가 병목인 경우 Zlib 압축이 도움이 될 수 있지만, 링크가 이미 빠르거나 파일이 이미 압축된 경우 CPU를 낭비할 수 있습니다.

이 가이드에서는 SSH 압축이 적합한 상황, 클라이언트와 서버에서 활성화하는 방법, 그리고 실제로 워크로드에 개선이 있는지 테스트하는 방법을 설명합니다.

SSH 성능 및 압축 이해

SSH 성능은 네트워크 지연 시간, 사용 가능한 대역폭, 전송되는 데이터의 특성 등 다양한 요인에 의해 영향을 받을 수 있습니다. 예를 들어, 느린 연결을 통해 대용량 텍스트 파일, 로그 아카이브를 전송하거나 상세한 명령줄 애플리케이션과 상호 작용하면 느리게 느껴질 수 있습니다. 이때 압축이发挥作用합니다.

ZLib 압축은 널리 사용되는 데이터 압축 라이브러리로, 압축률과 속도 사이에서 좋은 균형을 제공합니다. SSH와 통합되면 ZLib는 데이터를 암호화하여 네트워크로 보내기 전에 압축하고, 수신 시 압축을 해제합니다. 이렇게 하면 전송되는 총 데이터 양이 줄어들어 잠재적으로 더 빠른 전송과 더 나은 응답성을 얻을 수 있습니다.

ZLib가 SSH와 함께 작동하는 방식

SSH 압축이 활성화되면 클라이언트와 서버는 ZLib 사용을 협상합니다. 일단 설정되면 모든 데이터 페이로드(예: 셸 출력, scp/sftp 중 파일 내용)는 송신자가 압축하고 수신자가 압축 해제합니다. 헤더 및 암호화 키와 같은 실제 SSH 프로토콜 오버헤드는 일반적으로 압축되지 않습니다. SSH 클라이언트와 서버의 Compression 옵션은 일반적으로 ZLib 압축을 나타냅니다.

SSH 압축을 사용해야 하는 경우(및 사용하지 말아야 하는 경우)

압축을 활성화하는 것이 보편적인 해결책은 아닙니다. 그 이점은 특정 사용 사례와 네트워크 조건에 크게 의존합니다. 언제 적용해야 하는지 이해하는 것이 진정한 최적화의 핵심입니다.

SSH 압축에 이상적인 시나리오

  • 저대역폭 연결: 네트워크 연결의 대역폭이 제한된 경우(예: DSL, 위성 인터넷 또는 혼잡한 Wi-Fi), 전송되는 데이터 양을 줄이면 효과적인 처리량을 크게 향상시킬 수 있습니다. 더 적은 데이터를 전송하여 절약된 시간이 압축/해제에 소비되는 CPU 주기를 능가합니다.
  • 고지연 연결: 대역폭이 충분하더라도 높은 지연 시간은 대화형 SSH 세션을 응답하지 않게 만들 수 있습니다. 압축은 데이터가 이동할 때 가능한 한 컴팩트하게 만들어 큰 출력의 "첫 번째 바이트까지의 시간"을 줄여 큰 차이를 만들 수 있습니다.
  • 반복성이 높은 데이터 전송: 텍스트 파일, 로그 파일, 구성 파일, 소스 코드 및 기타 형태의 구조화되거나 반구조화된 데이터는 종종 높은 수준의 중복성을 포함합니다. ZLib는 이러한 데이터를 압축하는 데 매우 효과적이어서 상당한 크기 감소를 가져옵니다.
  • 자세한 출력이 있는 대화형 터미널 세션: 방대한 텍스트 출력을 생성하는 명령(예: 대규모 리포지토리의 dmesg, journalctl, git log)을 자주 실행하는 경우 압축을 통해 이러한 출력이 터미널에 훨씬 더 빠르게 나타나도록 할 수 있습니다.

SSH 압축을 피하거나 주의해야 하는 경우

  • 고대역폭, 저지연 LAN 연결: 빠른 로컬 영역 네트워크에서는 데이터 압축 및 해제의 오버헤드가 데이터 전송 감소로 절약된 시간보다 더 많은 CPU 주기를 소비할 수 있습니다. 이러한 경우 네트워크 링크가 병목이 아닐 가능성이 높으며 CPU 사용량이 제한 요소가 됩니다.
  • 이미 압축된 데이터 전송: 이미 압축된 파일(예: JPEG 이미지, MP3 오디오, ZIP 아카이브, GZip 파일, MP4 비디오)을 압축하려고 시도하는 것은 대체로 효과가 없습니다. ZLib는 더 이상의 중복성을 거의 또는 전혀 찾지 못하여 무시할 수 있는 크기 감소만 있고 불필요한 CPU 오버헤드만 추가합니다.
  • CPU 바운드 시스템(클라이언트 또는 서버): 클라이언트 시스템이나 SSH 서버가 이미 CPU 부하가 높은 경우 압축을 활성화하면 성능 문제를 해결하기보다는 오히려 악화시킬 수 있습니다. CPU 사용량을 모니터링하여 압축이 과도한 부담을 주지 않는지 확인하세요.

SSH에서 ZLib 압축 활성화

SSH 압축은 클라이언트 측, 서버 측 또는 지속적인 설정을 위한 구성 파일을 통해 활성화할 수 있습니다.

클라이언트 측 구성

일반적으로 로컬 시스템(SSH 클라이언트)에서 압축을 제어합니다.

1. -C 명령줄 옵션 사용

단일 SSH 명령에 대해 압축을 활성화하는 가장 간단한 방법은 -C 플래그를 사용하는 것입니다.

ssh -C user@hostname
scp -C local_file user@hostname:/remote/path
sftp -C user@hostname

이 옵션은 해당 명령으로 시작된 특정 세션에 대해 압축을 강제합니다. 압축이 유용할 것으로 알고 있는 테스트 또는 일회성 전송에 유용합니다.

2. ~/.ssh/config 파일 사용

특정 호스트 또는 모든 호스트에 대해 지속적인 압축을 설정하려면 일반적으로 Unix 계열 시스템의 ~/.ssh/config에 있는 SSH 클라이언트 구성 파일을 편집할 수 있습니다. 파일이 없으면 만들 수 있습니다.

# 기본적으로 모든 호스트에 대해 압축 활성화
Host *
    Compression yes

# 특정 호스트에 대해서만 압축 활성화
Host my_remote_server
    HostName 192.168.1.100
    User remote_user
    Compression yes
    Port 2222

# 특정 호스트에 대해 압축 비활성화(전역 설정 재정의)
Host fast_lan_server
    HostName 10.0.0.5
    Compression no

지시문 설명:

  • Host *: 더 구체적인 Host 블록으로 재정의되지 않는 한 모든 SSH 연결에 다음 설정을 적용합니다.
  • Host my_remote_server: ssh my_remote_server를 사용하여 연결할 때만 설정을 적용합니다.
  • Compression yes|no: 지정된 호스트 또는 전역적으로 압축을 명시적으로 활성화하거나 비활성화합니다.

서버 측 구성(선택 사항이지만 제어에 권장됨)

일반적으로 압축을 협상하려면 클라이언트 측 활성화로 충분하지만(서버가 지원하는 경우), SSH 서버(sshd)에도 압축과 관련된 구성 옵션이 있습니다. 일반적으로 /etc/ssh/sshd_config에 있습니다.

1. Compression 지시문

기본적으로 sshd는 일반적으로 클라이언트가 요청하면 압축을 허용합니다. 그러나 명시적으로 설정할 수 있습니다.

# /etc/ssh/sshd_config
Compression yes

서버에서 Compression yes를 설정하면 서버가 클라이언트의 압축 요청을 수락하고 처리할 수 있습니다. no로 설정하면 클라이언트가 요청하더라도 압축이 비활성화됩니다.

2. Compression 지시문과 delayed

특히 많은 동시 연결이 있는 경우 최적의 서버 성능을 위해 OpenSSH는 Compression delayed 옵션을 도입했습니다. 이 설정은 사용자가 성공적으로 인증할 때까지 압축 시작을 지연시킵니다. 이렇게 하면 잠재적으로 악의적이거나 봇 클라이언트의 인증 시도(일반적으로 작고 반복적이지 않음)를 압축하는 데 불필요한 CPU 주기가 소모되는 것을 방지할 수 있습니다.

# /etc/ssh/sshd_config
Compression delayed

/etc/ssh/sshd_config를 수정한 후 파일의 유효성을 검사하고 sshd를 다시 로드하거나 다시 시작하세요.

sudo sshd -t
sudo systemctl reload sshd

일부 배포판에서는 특히 Debian 기반 시스템에서 서비스 이름이 sshd 대신 ssh일 수 있습니다.

실제 예제 및 사용 사례

압축이 실제 이점으로 어떻게 이어지는지 살펴보겠습니다.

예제 1: scp로 대용량 로그 파일 전송

상대적으로 느린 연결을 통해 원격 서버에서 수 기가바이트의 로그 파일을 다운로드해야 한다고 가정해 보겠습니다. 로그 파일(application.log)에는 반복성이 높은 텍스트 데이터가 포함되어 있습니다.

압축 없음:

time scp user@remote_host:/var/log/application.log .

압축 사용:

time scp -C user@remote_host:/var/log/application.log .

-C를 추가하면 scp 명령이 압축을 사용합니다. 특히 로그 파일이 잘 압축되는 경우 전송 시간이 크게 단축되는 것을 확인할 수 있을 것입니다.

예제 2: SSH를 통한 rsync 성능 향상

rsync는 -z를 사용하여 자체적으로 파일 데이터를 압축하거나 ssh -C를 통해 SSH 압축을 사용할 수 있습니다. 일반적으로 둘 중 하나를 선택하고 테스트하는 것이 좋습니다. 둘을 함께 사용하는 것은 피하세요.

rsync -avz /local/path/to/sync user@remote_host:/remote/destination/

rsync -av -e "ssh -C" /local/path/to/sync user@remote_host:/remote/destination/
  • -a: 아카이브 모드(권한, 타임스탬프 등 보존)
  • -v: 자세한 출력
  • -z: rsync 자체 압축. 느린 링크를 통한 파일 전송에는 종종 이것으로 충분합니다.
  • -e "ssh -C": 원격 셸로 ssh -C를 지정합니다.

예제 3: 대화형 셸 응답성 향상

대용량 파일 시스템에서 ls -lR /와 같은 명령을 실행하거나 자세한 진단 출력을 가져올 때 압축을 사용하면 출력이 나타나기 시작하고 인쇄가 완료될 때까지의 지연 시간을 줄일 수 있습니다.

ssh -C user@hostname "ls -lR /"

이렇게 하면 네트워크 연결 상태가 좋지 않은 경우 압축되지 않은 세션에 비해 대화형 경험이 훨씬 더 빠르게 느껴집니다.

압축의 영향 측정

이점을 실제로 이해하려면 전후 성능을 측정해야 합니다. 예제에 표시된 time과 같은 도구는 총 실행 시간을 측정할 수 있습니다. 네트워크 처리량의 경우 iperf3를 사용할 수 있습니다(그러나 이는 SSH 오버헤드가 아닌 원시 네트워크 속도를 측정합니다). 가장 직접적인 방법은 실제 파일 전송 시간을 비교하고 대화형 세션의 응답성을 관찰하는 것입니다.

또한 ssh -v를 사용하여 자세한 디버깅 출력을 볼 수 있으며, 이는 때때로 압축 사용을 나타낼 수 있지만 직접적인 성능 측정이 더 의미 있습니다.

모범 사례 및 고급 팁

  • 자신의 환경에서 테스트: 항상 특정 네트워크 조건과 데이터 유형으로 압축을 테스트하세요. 한 시나리오에 잘 맞는 것이 다른 시나리오에는 해로울 수 있습니다.
  • CPU 사용량 모니터링: 압축이 활성화된 상태에서 대용량 전송 또는 장기간 대화형 세션 중에 클라이언트와 서버 모두의 CPU 부하를 확인하세요. CPU 사용량이 과도하게 급증하면 압축이 역효과를 낼 수 있습니다.
  • 다른 최적화와 결합: 압축은 SSH 최적화의 한 측면일 뿐입니다. 다음을 결합하는 것을 고려하세요.
    • 연결 다중화: 반복적인 핸드셰이크 오버헤드를 피하기 위해 기존 SSH 연결 재사용(~/.ssh/config의 ControlMaster, ControlPath).
    • 암호 선택: 보안 요구 사항이 허용하는 경우 더 빠른 암호(예: [email protected], [email protected]) 선택. 일부 암호는 다른 암호보다 CPU 집약도가 낮습니다.
    • KeepAlive 설정: ServerAliveInterval 및 ClientAliveInterval을 사용하여 비활성으로 인한 연결 끊김 방지.
  • 구체적으로 구성: ~/.ssh/config에서 전역적으로 Compression yes를 활성화하는 대신 Host 블록을 사용하여 이점이 있을 것으로 알고 있는 호스트에만 적용하세요.

핵심 요약

느린 링크, 많은 텍스트 출력이 있는 터미널 세션, 로그 또는 소스 트리와 같은 일반 텍스트 전송에는 SSH Zlib 압축을 사용하세요. 빠른 LAN, CPU 바운드 호스트 및 이미 압축된 파일의 경우에는 끄세요. 가장 안전한 다음 단계는 -C를 사용한 명령과 사용하지 않은 명령을 동일하게 테스트하고 CPU 사용량을 관찰한 다음 측정 결과가 확실히 더 나은 호스트에 대해서만 Compression yes를 활성화하는 것입니다.