nginx를 쓰는 이유
nginx는 앞단에서 트래픽, 연결, 리소스를 정리해 뒤쪽 애플리케이션을 보호하고 전체 효율을 높이기 위해 사용한다.
1. 리버스 프록시 (Reverse Proxy)
- 외부 요청을 애플리케이션 서버(Node, Java, PHP 등)에 직접 전달하지 않음
- nginx가 요청을 수신한 뒤 내부 서버로 전달
- 내부 서버 구조 은닉 가능
실무 효과
- 서버 교체, 포트 변경, 서버 증설 시 클라이언트 영향 최소화
- 앱 서버 장애 시에도 앞단에서 제어 가능
2. 로드 밸런싱 (Load Balancer)
- 여러 WAS/API 서버로 트래픽 분산
round-robin,least_conn,ip_hash등 분산 전략 지원
실무 효과
- 무중단 배포(Blue-Green, Rolling) 가능
- 트래픽 피크 대응
- 단일 장애 지점(SPOF) 제거
3. 정적 파일 처리 성능
- CSS, JS, 이미지, 동영상 등 정적 파일을 매우 빠르게 처리
- sendfile, zero-copy, OS 캐시 적극 활용
실무 효과
- 앱 서버에서 정적 파일 서빙 불필요
- 애플리케이션은 비즈니스 로직에 집중
- 트래픽 대비 서버 비용 절감
4. TLS(HTTPS) 종료 지점
- SSL/TLS 처리를 nginx에서 수행
- 내부 서버는 HTTP로 단순화
실무 효과
- 인증서 관리 일원화 (예: Let’s Encrypt 자동 갱신)
- 앱 서버의 암복호화 부하 제거
- 보안 설정 중앙 관리
5. 트래픽 제어 및 보안 게이트
- Rate Limit 설정
- IP 차단 및 허용 제어
- Header 제어, User-Agent / Referer 필터링
- 기본적인 DDoS 완충 역할
실무 효과
- 애플리케이션 코드 수정 없이 보안 정책 적용
- 봇, 크롤러 트래픽 제어
- 외부 WAF 없이 1차 방어선 역할 수행
6. 비동기 이벤트 기반 구조
- Event-driven, non-blocking 아키텍처
- 프로세스/스레드 기반 웹서버 대비 메모리 효율 우수
실무 효과
- 동시 커넥션 수가 많아도 안정적
- C10K 문제에 강함
- 트래픽 급증 상황에서도 버티는 구조
한 줄 의사결정 요약
- 앱 서버를 외부에 직접 노출하지 않기 위해
- 공통 트래픽·보안·성능 처리를 인프라 레이어에서 해결하기 위해
- 운영 복잡도를 애플리케이션 코드가 아닌 서버 설정으로 분리하기 위해
nginx를 굳이 쓰지 않아도 되는 경우
- 단일 서버, 내부 전용 서비스
- 트래픽이 매우 적은 서비스
- 이미 프록시 계층이 포함된 서버리스/매니지드 플랫폼 사용 시