fork 작업으로 인한 고성능 요청 지연

RDB 스냅샷 생성이나 AOF 재작성 시 디스크 I/O 작업이 발생하며 메인 프로세스가 하위 프로세스를 fork합니다. 이때 하위 프로세스는 상위 프로세스의 메모리 페이지 테이블을 복제하는데, 10GB 메모리 기준 약 200ms가 소요될 수 있습니다. info stats의 latest_fork_usec로 마지막 fork 시간을 확인 가능합니다. 초당 수만 건 처리 환경에서 이 지연은 요청 처리 시간을 1초 이상으로 늘릴 수 있습니다.

# 최적화 방안
redis-server --maxmemory 10gb  # 메모리 제한 설정
slaveof master_ip 6379         # 10GB 이하 슬레이브에서 전체 복제 수행

AOF 블로킹 문제

everysec 설정 시 2초 이상 fsync 지연 발생하면 쓰기 작업이 차단됩니다. AOF 버퍼에 데이터 기록 후 별도 스레드가 fsync를 실행하지만, 메인 스레드는 fsync 간격을 모니터링하여 지연 시 블로킹을 유발합니다.

# 최적화 방안
# SSD 저장장치 사용 권장
# 설정 파일 수정
appendfsync everysec
appendfilename "ssd_aof.log"

복제 지연 모니터링

마스터-슬레이브 간 복제 지연이 발생할 수 있으며, info replication의 offset 차이로 지연량을 계산합니다. 임계값 초과 시 알림 시스템을 구현해야 합니다.

# 지연 감지 스크립트 예시
master_offset=$(redis-cli -h master info replication | grep offset)
slave_offset=$(redis-cli -h slave info replication | grep offset)
if (( master_offset - slave_offset > 10000 )); then
  send_alert "Replication Lag Alert"
fi

복제 스톰 현상

다중 슬레이브가 동시에 전체 복제를 요청하면 네트워크 대역폭 포화 상태가 발생합니다. 슬레이브가 여러 개인 경우 스타 구조보다 트리 구조를 권장합니다.

vm.overcommit_memory 설정

fork 실패 방지를 위해 값 설정이 필요합니다:

# 권장 설정 값
sudo sysctl vm.overcommit_memory=1
echo "vm.overcommit_memory=1" | sudo tee -a /etc/sysctl.conf

swappiness 조정

커널 버전별 설정 차이:

# 커널 버전 확인
uname -r
# 3.5 미만: 
echo 0 | sudo tee /proc/sys/vm/swappiness
# 3.5 이상: 
echo 1 | sudo tee /proc/sys/vm/swappiness

파일 핸들 제한 상향

운영체제별 설정 방법:

# Linux 시스템 예시
ulimit -n 65535
echo "* soft nofile 65535" | sudo tee -a /etc/security/limits.conf

TCP 백로그 설정

# 커널 파라미터 조정
echo 2048 | sudo tee /proc/sys/net/core/somaxconn
sysctl -w net.core.somaxconn=2048