SeolOps

증상

사내 물리 서버(113.11 대역)에서 간헐적으로 네트워크 지연 및 패킷 손실이 발생했다.

iftop과 nethogs로 실시간 트래픽을 확인한 결과, 특정 프로세스가 대역폭을 과점하고 있었다.

# 실시간 대역폭 사용량 확인
sudo iftop -i eth0
 
# 프로세스별 네트워크 사용량
sudo nethogs eth0

동일 서브넷(113.11.x.x/24) 내에서 여러 서비스가 대역폭을 경쟁하는 구조였다.

백업 작업이 실행되면 네트워크 대역폭을 거의 전부 점유하여, 같은 서브넷의 다른 서비스들이 영향을 받는 구조였다.

ip addr show eth0
# 113.11.x.x/24 - 모든 서비스가 단일 서브넷에 혼재
 
ip route
# default via 113.11.x.1 - 단일 게이트웨이

기존 단일 서브넷 구조를 용도별로 분리했다.

tc(Traffic Control)를 사용하여 백업 프로세스의 대역폭을 제한했다.

# 백업 인터페이스에 대역폭 제한 (100Mbps)
sudo tc qdisc add dev eth1 root tbf rate 100mbit burst 32kbit latency 400ms

트래픽이 적은 시간대로 백업 스케줄을 변경했다.

# 기존: 매일 22:00 (서비스 트래픽과 겹침)
# 변경: 매일 03:00 (최저 트래픽 시간대)
0 3 * * * /opt/scripts/backup.sh

물리 서버 환경에서 서비스/백업/관리 트래픽은 서브넷 단위로 분리하는 것이 안전하다
대용량 배치 작업에는 반드시 대역폭 제한(tc)을 걸어야 한다
네트워크 문제는 서버 자체 리소스(CPU/메모리)만 봐서는 원인을 찾기 어렵다, iftop, nethogs 같은 네트워크 모니터링 도구 활용이 중요하다

CPU와 메모리가 정상인데 서비스가 느리면 남는 건 네트워크다. 그런데 인프라 점검 습관은 대개 서버 리소스에서 멈춘다. 이 일 이후로 지연이 보고되면 대역폭과 트래픽 구성을 같은 순위로 확인하게 됐다.

백업 트래픽이 서비스 트래픽을 밀어낸 구조였는데, 둘은 중요도가 다른데도 같은 길을 쓰고 있었다. 우선순위가 다른 트래픽은 길을 나누거나 속도를 제한해야 한다는 게 결론이었다.

클라우드에서도 같은 문제가 형태만 바꿔 나타난다. EBS IOPS 8,000 설정에도 4,000만 사용되는 문제가 그렇다. 설정값이 아니라 실제로 쓸 수 있는 한계를 봐야 한다는 점에서 같은 교훈이었다.