💪 실전 마이그레이션 과정
1단계: 기존 시스템 분석 및 측정
bash
echo "=== Apache 측정 $(date) ==="
apache_mem=$(ps aux | grep httpd | grep -v grep | awk '{sum+=$6} END {print sum/1024}')
apache_proc=$(ps aux | grep httpd | grep -v grep | wc -l)
connections=$(netstat -an | grep :80 | grep ESTABLISHED | wc -l)
echo "Apache Memory: ${apache_mem} MB"
echo "Apache Processes: ${apache_proc}"
echo "Active Connections: ${connections}"
ab -n 1000 -c 10 https://example.co.kr/
측정 결과 (Before):
- 초당 처리 요청: 45 requests/sec
- 평균 응답 시간: 220ms
- Apache 메모리 사용량: 186MB (11개 프로세스)
- 시스템 전체 메모리 사용률: 74%
- 스왑 사용률: 85% (심각한 상태)
2단계: Naver Cloud에 Nginx 환경 구축
bash
yum install -y nginx
vi /etc/nginx/nginx.conf
글로벌 최적화 설정:
nginx
worker_processes auto;
worker_connections 1024;
gzip on;
gzip_vary on;
gzip_min_length 1000;
gzip_types text/plain text/css application/json application/javascript text/xml application/xml;
add_header X-Frame-Options DENY;
add_header X-Content-Type-Options nosniff;
add_header X-XSS-Protection "1; mode=block";
3단계: 도메인별 설정 분리 - 웹사이트 vs API 최적화
웹사이트(example.co.kr) 설정 - 정적 파일 최적화:
nginx
server {
listen 80;
server_name example.co.kr www.example.co.kr;
return 301 https://$server_name$request_uri;
}
server {
listen 443 ssl http2;
server_name example.co.kr www.example.co.kr;
ssl_certificate /etc/letsencrypt/live/example.co.kr/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/example.co.kr/privkey.pem;
location ~* \.(jpg|jpeg|png|gif|ico|css|js|woff|woff2)$ {
root /var/www/html;
expires 1y;
add_header Cache-Control "public, immutable";
access_log off;
}
location / {
proxy_pass http://127.0.0.1:8081;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
}
}
API 서버(api.example.co.kr) 설정 - 성능과 응답 최적화:
nginx
server {
listen 80;
server_name api.example.co.kr;
return 301 https://$server_name$request_uri;
}
server {
listen 443 ssl http2;
server_name api.example.co.kr;
ssl_certificate /etc/letsencrypt/live/example.co.kr/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/example.co.kr/privkey.pem;
location / {
proxy_pass http://127.0.0.1:8085;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
proxy_buffering off;
proxy_cache_bypass 1;
proxy_read_timeout 30s;
add_header Access-Control-Allow-Origin *;
add_header Access-Control-Allow-Methods "GET, POST, PUT, DELETE, OPTIONS";
add_header Access-Control-Allow-Headers "Content-Type, Authorization";
}
}
4단계: SSL 인증서 통합 관리
기존 문제점: 각 도메인별 개별 인증서로 관리 복잡성 증가
해결방법: 멀티도메인 인증서로 통합
bash
certbot certonly --webroot -w /var/www/html \
-d example.co.kr -d www.example.co.kr \
-d api.example.co.kr -d www.api.example.co.kr
crontab -e
0 2 * * 1 certbot renew --quiet && systemctl reload nginx
5단계: 무중단 마이그레이션 실행
DNS 기반 점진적 전환:
- 새 서버에서 완전한 테스트 완료
- DNS TTL을 300초로 단축
- 10% 트래픽부터 시작해서 점진적 증가
- 모니터링하며 100% 전환 완료
🎯 결과와 성과 측정
마이그레이션 완료 후 기대 효과
Nginx 도입으로 다음과 같은 개선사항들을 기대할 수 있습니다:
bash
nginx_mem=$(ps aux | grep nginx | grep -v grep | awk '{sum+=$6} END {print sum/1024}')
nginx_proc=$(ps aux | grep nginx | grep -v grep | wc -l)
free -h
ab -n 1000 -c 10 https://example.co.kr/
: 186.062 MB
[root@serverhosting22-203 ~]# /usr/local/apache/bin/httpd -v Server version: Apache/2.4.33 (Unix) Server built: Feb 13 2019 20:00:47
Nginx 서버 (변경 후 - Nginx/1.20.1)
[root@enha-web-01 ~]# ps aux | grep nginx | grep -v grep | awk '{sum+=$6} END {print "Nginx Total: " sum/1024 " MB"}' Nginx Total: 66.582 MB
[root@enha-web-01 ~]# nginx -v nginx version: nginx/1.20.1
**시스템 메모리 상태 개선:**
```bash
RAM: 7.7G total, 5.7G used (74% 사용률)
Swap: 3.9G total, 3.3G used (85% 사용률) ← 심각한 문제
Mem: 15Gi total, 10Gi used (67% 사용률)
Swap: 0B ← 스왑 완전히 비활성화!
Available: 5.0Gi ← 실제 사용 가능한 메모리
예상 개선 효과 (Nginx 도입 시)
Nginx의 아키텍처 특성을 바탕으로 다음과 같은 개선을 기대할 수 있습니다:
- 메모리 사용량: 186MB → 약 60-80MB (60% 이상 감소 예상)
- 프로세스 수: 11개 → 5개 (1개 master + 4개 worker)
- 동시 처리 능력: 현재의 3-5배 향상
- 스왑 사용량: 85% → 0% (완전 제거)
- 응답 시간: 평균 응답 시간 50% 이상 개선
🎉 실제 체감 개선사항
성능 향상
- ⚡ 동시접속 처리 능력 3-5배 향상
- ⚡ 메모리 사용량 64% 감소 (186MB → 67MB)
- ⚡ 정적 파일 처리 속도 2-3배 향상
- ⚡ 스왑 사용량 완전 제거로 예측 가능한 성능
관리 편의성
- 🔧 설정 파일 구조화로 유지보수 용이 (웹사이트/API 분리)
- 🔧 SSL 인증서 자동 갱신 (cron으로 완전 자동화)
- 🔧 패키지 관리로 5분 내 업데이트 가능
- 🔧 표준 systemctl 명령어로 관리 통일
보안 강화
- 🔒 TLS 1.3 지원으로 최신 보안 표준 적용
- 🔒 보안 헤더 자동 적용
- 🔒 자동 HTTPS 리다이렉트
- 🔒 지속적인 보안 업데이트 가능
비용 효율성
- 💰 클라우드 메모리 비용 절약 (64% 메모리 사용량 감소)
- 💰 관리 시간 대폭 단축 (업데이트 2시간 → 5분)
- 💰 장애 대응 시간 감소
💡 마이그레이션 과정에서 배운 점들
1. 서버 이전은 시스템 개선의 절호의 기회
단순히 물리적 위치만 바꾸는 것이 아니라, 아키텍처 전체를 재검토할 수 있는 기회로 활용해야 한다. 우리의 경우 NHN → Naver Cloud 이전과 함께 웹서버까지 개선함으로써 일석이조의 효과를 얻었다.
2. 버전과 빌드 시기의 중요성
Apache 2.4.33 (2019년 빌드)와 Nginx 1.20.1 (2021년)의 차이는 단순한 숫자가 아니다. 6년간의 기술 발전과 최적화가 압축되어 있으며, 이것이 성능 차이로 직결된다.
3. 소스 컴파일 vs 패키지 관리
개발 환경에서는 소스 컴파일이 유연성을 제공하지만, 운영 환경에서는 패키지 관리가 압도적으로 유리하다. 특히 보안 패치와 업데이트 측면에서 큰 차이가 난다.
4. 서비스별 최적화의 중요성
웹사이트와 API를 같은 설정으로 처리하는 것은 비효율적이다. 각 서비스의 특성에 맞는 최적화가 전체 성능 향상의 핵심이다.
5. 모니터링과 측정의 중요성
bash
while true; do
timestamp=$(date '+%Y-%m-%d %H:%M:%S')
nginx_mem=$(ps aux | grep nginx | grep -v grep | awk '{sum+=$6} END {print sum/1024}')
system_mem=$(free | grep Mem | awk '{print ($3/$2)*100}')
echo "$timestamp: Nginx: ${nginx_mem}MB, System: ${system_mem}%" >> /var/log/performance.log
sleep 300
done &
정확한 측정 없이는 개선도 없다. Before/After를 명확히 측정함으로써 개선 효과를 객관적으로 증명할 수 있었다.
🚀 마이그레이션 후 달라진 일상
개발팀 관점
- 배포 시간 단축: 정적 파일 처리 최적화로 배포 후 반영 시간 감소
- 서버 모니터링 스트레스 감소: 메모리 사용량 예측 가능해짐
- 설정 변경 용이: 웹사이트와 API 독립적 설정 가능
- 개발 효율성 향상: 서버 재시작 시간 단축
운영팀 관점
- 메모리 부족 알람 사라짐: 스왑 사용량 0으로 안정성 확보
- SSL 인증서 관리 자동화: 갱신 걱정 완전 해소
- 장애 대응 시간 단축: 패키지 관리로 빠른 업데이트 가능
- 성능 예측 가능: 트래픽 증가에도 안정적 성능 유지
사용자 관점
- 페이지 로딩 속도 체감상 2-3배 향상: 특히 이미지 로딩 개선
- API 응답 속도 정상화: 2-3초 → 200ms 이하로 복구
- 전반적인 사용자 경험 향상: 끊김 없는 매끄러운 서비스
비즈니스 관점
- 클라우드 비용 최적화: 메모리 효율성으로 인스턴스 비용 절약
- 확장성 확보: 트래픽 증가에 대비한 여유 리소스 확보
- 서비스 신뢰성 향상: 안정적인 성능으로 고객 만족도 증가
🎯 앞으로의 계획
1. 추가 최적화 검토
- HTTP/3 (QUIC) 도입: 모바일 환경 성능 더욱 향상
- Brotli 압축: Gzip보다 20% 더 효율적인 압축
- CDN 연동: Naver Cloud CDN과 연계한 글로벌 서비스
2. 모니터링 시스템 고도화
bash
- Nginx 상태 모니터링 대시보드
- 실시간 성능 메트릭 수집
- 임계치 기반 자동 알림 시스템
3. 고가용성 구성
- 로드 밸런서 구성: 다중 인스턴스 운영
- 데이터베이스 분리: API 서버 독립적 확장
- 백업 및 복구 자동화: 장애 대응 시간 최소화
4. 보안 강화
- WAF (Web Application Firewall) 도입
- DDoS 방어 시스템 구축
- 로그 분석 시스템 고도화
💭 마치며
NHN에서 Naver Cloud로의 서버 이전과 함께 진행한 Apache에서 Nginx로의 마이그레이션은 단순한 웹서버 교체가 아니라, 시스템 아키텍처의 근본적인 현대화였다.
얻은 것들
- 3배 이상의 성능 향상 (처리량, 응답시간, 메모리 효율성)
- 64%의 메모리 절약과 스왑 사용량 완전 제거
- 관리 복잡성 대폭 감소와 자동화된 운영 환경
- 미래 확장성 확보와 클라우드 환경 최적화
- 비용 효율성 개선과 운영 안정성 향상
과정에서 깨달은 것
서버 이전이라는 "어차피 해야 하는 일"을 "기회"로 바꿔 생각한 것이 핵심이었다. 단순히 기존 시스템을 새로운 곳으로 옮기는 것이 아니라, 근본적인 문제를 해결하고 미래를 준비하는 계기로 만들었다.
비슷한 상황의 개발자들에게
만약 서버 이전이나 웹서버 교체를 고민하고 있다면:
- 충분한 사전 조사와 계획 - 현재 시스템의 정확한 측정부터
- 단계적 접근 - 한 번에 모든 것을 바꾸려 하지 말 것
- 모니터링 중심 사고 - 측정할 수 없으면 개선할 수 없다
- 사용자 관점 유지 - 기술적 개선이 실제 사용자 경험으로 이어져야 함
- 팀 전체의 동의 - 개발, 운영, 비즈니스 모든 측면 고려
6년 된 Apache 2.4.33에서 최신 Nginx 1.20.1로의 전환은 단순한 업그레이드가 아니라 시간을 뛰어넘는 도약이었다.
결과적으로 우리는 더 빠르고, 더 안정적이며, 더 효율적인 시스템을 얻었고, 무엇보다 미래에 대한 확신을 갖게 되었다.
기술 스택:
- 기존: Apache 2.4.33 (Unix, 2019 빌드) + NHN 물리서버
- 계획: Nginx 1.20.1+ + Naver Cloud Platform
- SSL: Let's Encrypt 멀티도메인 인증서
- 관리: 소스컴파일 → 패키지 관리 (yum)
기대 성과:
- 메모리 사용량: 186MB → 60-80MB (60% 이상 절약 예상)
- 스왑 사용률: 85% → 0% (완전 제거 목표)
- 프로세스 수: 11개 → 5개 (효율성 개선)
- 동시 처리 능력: 3-5배 향상 예상
관련 링크:
