물리 서버(113.11) 대역폭 충돌 문제 해결

증상

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

• 특정 시간대에 서버 간 통신 지연 급증 (ping RTT 100ms 이상)
• 파일 전송 속도 저하 (평소 대비 1/10 수준)
• 일부 서비스 타임아웃 발생
• 물리 서버 자체의 CPU/메모리는 정상 범위

원인 분석

1. 네트워크 트래픽 모니터링

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

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

2. 대역폭 충돌 원인

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

• 백업 작업: 대용량 파일 전송 (야간 배치)
• 모니터링 에이전트: 주기적 메트릭 수집
• 애플리케이션 서비스: 실시간 API 트래픽

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

3. 네트워크 구성 확인

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

해결 방법

1. 트래픽 유형별 서브넷 분리

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

2. 백업 작업 대역폭 제한

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

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

3. 백업 스케줄 조정

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

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

결과

• 서비스 트래픽 지연 해소 (ping RTT 1ms 이하로 복구)
• 백업 작업 중에도 서비스 영향 없음
• 파일 전송 속도 정상화
• 서브넷 분리로 향후 트래픽 관리 용이

교훈

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