10. [최적화7] ZRAM 압축 알고리즘 및 설정 비교: t2.micro 환경에서 최적화 테스트

스왑(Swap) 메모리 최적화: ZRAM 활용 방법

이번 포스팅에서는 ZRAM을 활용한 스왑 최적화를 다룹니다.

기존 디스크 기반 스왑의 단점을 해결하고, 저사양 서버(t2.micro 등)에서 메모리 부족 문제를 개선할 수 있습니다.

---

1. ZRAM이란?

• 디스크 대신 RAM을 활용하여 압축된 형태로 스왑을 저장하는 기술
• 디스크 기반 vs ZRAM 기반

비교 항목	디스크 기반 스왑	ZRAM 기반 스왑
저장 위치	SSD/HDD	RAM(압축 저장)
속도	느림 (디스크 I/O 속도에 의존)	빠름 (메모리 내 압축 데이터 처리)
I/O 부하	높음 (디스크 쓰기/읽기 부담)	낮음 (디스크 I/O 거의 없음)
메모리 사용량	추가적인 디스크 공간 필요	RAM 일부를 사용 (압축률 높음)
CPU 부하	낮음	CPU 사용 (압축/해제 필요)
적합한 환경	대용량 RAM 부족 시 보조	CPU 여유가 있는 경우 최적

테스트 환경

• EC2 인스턴스: t2.micro (vCPU 1개, RAM 1GB)
• 테스트 도구: Artillery (WebSocket 부하 테스트)
• 비교 대상
  1. ZRAM 미사용 (기본 상태)
  2. ZRAM + lz4 (빠른 압축)
  3. ZRAM + zstd (고압축율)

스왑 방식의 차이점

스왑 방식	특징	장점	단점
디스크 스왑	RAM이 부족하면 SSD에 데이터를 저장하여 가상 메모리처럼 사용	- 설정이 간단- CPU 사용량 낮음	- SSD I/O 병목 발생 가능- 응답 속도 느림
ZRAM (LZ4)	RAM에서 데이터를 압축하여 가상 메모리처럼 사용 (빠른 압축)	- 빠른 압축 속도- SSD I/O 감소	- CPU 사용량 증가
ZRAM (ZSTD)	더 높은 압축률을 제공하는 ZRAM 설정	- 더 많은 데이터를 압축하여 RAM 활용도 증가	- CPU 사용량이 매우 높아 성능 저하 가능

기대효과

• 저사양 서버에서는 디스크 기반 스왑 사용 시 CPU 사용률이 낮지만, SSD의 IOPS 한계를 초과하면 병목 발생 가능
• ZRAM을 사용하면 디스크 I/O 없이 메모리를 확장할 수 있어 속도와 성능이 향상
• ZRAM (LZ4)는 빠르지만 CPU 부하가 커서 WebSocket 서버와 경합 발생
• ZRAM (ZSTD)는 높은 압축률을 제공하지만 CPU를 지나치게 사용하여 오히려 성능 저하 가능

---

2. ZRAM 활성화 및 설정 방법

(1) ZRAM 설치

sudo apt update
sudo apt install zram-tools -y

• zram-tools 패키지를 설치하면 ZRAM을 쉽게 관리가능

(2) ZRAM 설정 및 활성화

sudo zramctl --find --size 1G

• 1GB 크기의 ZRAM 스왑을 생성
• 필요에 따라 크기를 조절 가능

(3) 기존 스왑 해제 후 ZRAM 사용

sudo swapoff -a  # 기존 디스크 스왑 비활성화
sudo swapon --priority 100 /dev/zram0  # ZRAM을 최우선 스왑으로 설정

• 기존의 디스크 기반 스왑을 비활성화하고 ZRAM을 최우선으로 사용

(4) 재부팅 후에도 유지되도록 설정

ZRAM 설정을 /etc/systemd/zram-generator.conf에 저장하면 재부팅 후에도 유지

sudo nano /etc/systemd/zram-generator.conf

다음 내용을 추가

[zram0]
zram-size = 1G
compression-algorithm = zstd
swap-priority = 100
fs-type = swap

파일 저장 후 적용

sudo systemctl daemon-reexec

Test Setup

• 설정 적용 방법

  • No ZRAM (Baseline)

      sudo swapoff -a

  • ZRAM with lz4

      sudo swapoff -a
      sudo modprobe zram
      echo lz4 | sudo tee /sys/block/zram0/comp_algorithm
      echo 1G | sudo tee /sys/block/zram0/disksize
      sudo mkswap /dev/zram0
      sudo swapon /dev/zram0 -p 100

  • ZRAM with zstd

      sudo swapoff -a
      sudo modprobe zram
      echo zstd | sudo tee /sys/block/zram0/comp_algorithm
      echo 1G | sudo tee /sys/block/zram0/disksize
      sudo mkswap /dev/zram0
      sudo swapon /dev/zram0 -p 100

3. ZRAM 적용 후 성능 테스트 결과 비교

주요 성능 비교 결과

항목	ZRAM 미사용	ZRAM + lz4	ZRAM + zstd	비고
총 소요 시간	3분 11초	3분 7초	3분 7초	차이 미미
WebSocket 에러	36건	221건	152건	lz4에서 오류 급증
Socket.io Emits	834	683	762	lz4에서 처리량 감소
Emit Rate	4/sec	2/sec	4/sec	lz4 성능 저하
응답 시간 (최대)	35.9ms	38.6ms	4ms	zstd 응답시간 개선
응답 시간 (평균)	0.5ms	0.4ms	0.4ms	비슷한 수준
가상 유저 성공률	834/930	683/930	762/930	lz4에서 실패율 급증
세션 길이 (평균)	24326.1ms	12180.8ms	11160.3ms	zstd에서 세션 길이 짧아짐

결과 분석

1. ZRAM을 사용하면 일부 응답 속도가 향상되지만, 알고리즘에 따라 차이가 발생함
   • lz4는 Swap 속도는 빠르지만, 실패율(WebSocket 에러)이 급증
   • zstd는 압축률이 높아 RAM을 덜 사용하지만, Swap 부하로 인해 WebSocket 처리량 감소
2. WebSocket 에러 증가
   • lz4 적용 시: 오류 급증 (+185건 증가)
   • zstd 적용 시: 기본 대비 4배 이상 증가
   • 💡 원인: CPU 사용량 증가 → WebSocket 요청이 정상적으로 처리되지 않음
3. zstd 사용 시 응답 속도 개선
   • 최대 응답 시간 35.9ms → 4ms로 단축
   • 하지만 가상 유저 성공률이 낮아지는 부작용 발생
   • lz4는 기본 Swap보다 약간 높은 응답 시간(35.9ms)이지만, 안정적인 성능 유지
   • zstd는 압축 효율이 높지만 오버헤드로 인해 WebSocket 처리량이 급감

ZRAM 적용 후 긍정적인 변화

응답 속도 개선

• 기본 Swap 사용 시 최대 응답 시간 35.9ms → ZRAM(zstd) 사용 시 4ms로 단축
• 서버가 높은 부하를 처리할 때 응답 지연이 크게 줄어듦
• 실시간 웹 서비스(WebSocket, API)에서 중요한 개선점

세션 길이 감소

• ZRAM(zstd) 사용 시 세션 길이가 기존 대비 50% 이상 감소(11.1초 → 24.3초)
• 이는 서버가 빠르게 요청을 처리하고 종료할 수 있다는 의미
• 즉, 동일한 시간 동안 더 많은 요청을 처리할 수 있음

디스크 I/O 감소 → 안정성 증가

• 일반 Swap은 디스크를 사용하여 I/O 부하를 증가시킴
• ZRAM은 RAM 내부에서 Swap을 처리하여 I/O 병목을 줄임
• 이는 서버가 과부하 상태에서도 안정적으로 운영될 가능성을 높임

ZRAM 적용 후 부정적인 변화 (에러 증가 이유 분석)

WebSocket 에러 증가 (36 → 152)

• CPU가 ZRAM의 압축/해제를 수행하느라 부하가 증가했을 가능성
• 이로 인해 일부 요청을 정상적으로 처리하지 못하고 WebSocket 연결이 끊겼을 가능성
• 압축률이 높은 zstd는 CPU 사용량이 많아지므로, 서버 리소스가 부족할 때 성능 저하가 발생할 수 있음

가상 유저 실패율 증가 (96 → 168)

• 요청이 많아질 때 CPU 자원이 부족하여 처리하지 못한 요청 증가
• CPU 성능이 낮은 경우, ZRAM이 오히려 성능 저하를 유발할 수 있음
• ZRAM이 필요 이상의 RAM을 사용하면 오히려 시스템 전체 성능이 저하될 수 있음

ZRAM 적용 시 주의할 점

1. 압축 알고리즘 선택이 중요

   • lz4: 속도는 빠르지만 WebSocket 에러 증가(CPU 부하 때문)
   • zstd: 높은 압축률을 제공하며, 안정적인 성능을 유지함

2. RAM 사용량 모니터링 필요

   • ZRAM은 RAM을 일부 할당하므로, RAM 사용량이 너무 높은 경우 오히려 성능 저하 발생 가능

   • htop이나 free -h로 사용량을 주기적으로 체크해야 함

   • htop을 사용하여 CPU 사용량이 과부하 상태인지 확인

   • iotop을 실행하여 디스크 I/O가 줄었는지 체크

     htop  # CPU 사용량 확인
     iotop  # 디스크 I/O 확인
     free -h  # 실제 메모리 사용량 확인

3. ZRAM 크기 조정 (512MB → 256MB)

• 현재 ZRAM 크기가 512MB → t2.micro는 RAM이 1GB로 제한되므로 256MB가 적절할 가능성 있음
• Swap 크기가 너무 크면 불필요한 압축/해제 작업이 늘어나 CPU 부하 증가 가능

sudo swapoff -a
echo 256M | sudo tee /sys/block/zram0/disksize
sudo mkswap /dev/zram0
sudo swapon /dev/zram0 -p 100

기대 효과

• 불필요한 ZRAM 사용량을 줄여 CPU 사용량 절약
• WebSocket 프로세스가 더 많은 CPU를 활용 가능

1. WebSocket 프로세스와 ZRAM의 CPU 경합 최소화

• PM2를 사용하여 WebSocket 서버의 실행 우선순위를 높임
• ZRAM 프로세스가 높은 우선순위로 실행되지 않도록 함

sudo renice 10 -p $(pgrep zram)

기대 효과

• WebSocket 서버가 CPU 리소스를 더 확보하여 응답 속도 유지 가능
• ZRAM의 압축/해제 작업이 서버 성능에 미치는 영향 감소

ZRAM 설정 개선(t2.micro, WebSocket 서버 고려)

sudo swapoff -a
sudo modprobe -r zram
sudo modprobe zram num_devices=1
echo lzo | sudo tee /sys/block/zram0/comp_algorithm
echo 256M | sudo tee /sys/block/zram0/disksize
sudo mkswap /dev/zram0
sudo swapon /dev/zram0 -p 100
sudo renice 10 -p $(pgrep zram)

기대효과

• 압축 알고리즘 (lzo) → CPU 부하 감소
• 적절한 크기 (256MB) → 메모리 부족 방지
• WebSocket 프로세스 우선순위 확보 → 서비스 성능 유지

(1) 압축 알고리즘별 비교 (기본 설정)

설정	CPU 사용률	웹소켓 에러	최대 응답 시간	평균 응답 시간	가상 유저 실패	총 테스트 시간
디스크 스왑	60~70%	36건	35.9ms	0.5ms	96명	3분 11초
ZRAM (LZO)	95~99%	273건	10.9ms	0.4ms	289명	3분 6초
ZRAM (LZ4)	95~99%	221건	38.6ms	0.4ms	247명	3분 7초
ZRAM (ZSTD)	99%	152건	4ms	0.4ms	168명	3분 7초

💡 분석

✅ 디스크 기반 스왑 사용 시 웹소켓 에러와 실패율이 가장 낮았지만, 응답 시간이 길어지는 문제가 있음

✅ LZO, LZ4, ZSTD 모두 CPU 사용량을 크게 증가시키며 웹소켓 성능 저하 발생

✅ ZSTD는 압축률이 높아 메모리 절약 효과는 크지만, CPU 부담으로 인해 성능 저하 가능성 있음

---

(2) 256MB ZRAM + renice 적용 후 비교

설정	CPU 사용률	웹소켓 에러	최대 응답 시간	평균 응답 시간	가상 유저 실패	총 테스트 시간
ZRAM (LZO, 256M, renice)	95~99%	273건	10.9ms	0.4ms	289명	3분 6초

💡 분석

✅ ZRAM 크기를 256MB로 제한하고 renice를 적용했을 때, CPU 사용률이 95~99%로 유지되며 일부 성능이 개선됨

❌ 그러나, 웹소켓 에러 및 실패율이 오히려 증가

✅ 최대 응답 시간(10.9ms)은 ZSTD보다 낮아졌지만, 여전히 LZO 기본 설정보다 좋지 않음

---

결론: t2.micro 환경에서 ZRAM이 필요한가?

추천 설정

1. 디스크 기반 스왑 사용 (기본 스왑)
   • 웹소켓 에러 최소화 및 안정적인 응답 속도 제공
   • CPU 사용량 증가 없음
   • t2.micro 환경에서 가장 적합한 설정
2. ZRAM (LZO) 사용 가능 (RAM 부족 시)
   • CPU 사용량을 감당할 수 있다면, LZO 적용 가능
   • ZSTD, LZ4는 CPU 사용량 과다로 성능 저하 발생 가능성 큼
3. 256MB 제한 및 renice 적용 비추천
   • 성능 개선 효과가 미비하며, 오히려 에러율이 증가

---

결론

• 결론적으로, ZRAM은 t2.micro 환경에서 성능 향상을 보장하지 않으며, CPU 사용량 증가로 인해 웹소켓 서버의 안정성을 저하시킬 수 있음
• 최적의 선택은 기본 디스크 기반 스왑을 유지하면서 CPU 사용량을 조절하는 것