기존에는 애플리케이션을 배포할 때 실행 중인 애플리케이션을 종료한 뒤, 패키징된 파일을 서버로 전송하고 다시 실행하는 방식으로 진행했다.
애플리케이션 종료
→ jar 파일 전송
→ 애플리케이션 재실행
하지만 이 방식에는 문제가 있다. 애플리케이션이 종료된 순간부터 다시 실행될 때까지 사용자의 요청을 처리할 수 없기 때문이다.
즉, 배포 과정에서 서비스가 일시적으로 중단될 수 있다.
이 문제를 해결하기 위해 여러 대의 애플리케이션 서버를 두고 서비스를 운영하는 방식을 생각할 수 있다. 하나의 서버를 배포하는 동안 다른 서버가 요청을 처리하도록 하면 서비스 중단 시간을 줄일 수 있다.
하지만, 서버가 여러 대가 되면 또 다른 문제가 생긴다. 클라이언트가 모든 애플리케이션 서버의 IP 주소를 알고 직접 요청을 보내야 한다면 구조가 복잡해진다. 서버가 추가되거나 제거될 때마다 클라이언트도 영향을 받게 된다.
이러한 다운타임을 줄이기 위한 대표적인 방법이 무중단 배포이다. 무중단 배포를 구현하기 위해서는 여러 대의 애플리케이션 서버를 운영하고, 트래픽을 적절히 분산시켜 줄 수 있는 구성 요소가 필요하다. 이 역할을 수행할 수 있는 대표적인 도구가 Nginx이다.
Nginx란?
Nginx는 웹 서버이면서 동시에 리버스 프록시, 로드 밸런서, 게이트웨이 역할을 수행할 수 있는 서버 프로그램이다.
Nginx를 클라이언트와 애플리케이션 서버 사이에 두면 클라이언트는 실제 애플리케이션 서버의 존재를 알 필요가 없다.
Client
↓
Nginx
↓
Application Server 1
Application Server 2
Application Server 3
클라이언트는 Nginx의 주소로만 요청을 보내고, Nginx가 내부적으로 적절한 애플리케이션 서버로 요청을 전달한다.
Nginx의 역할
Nginx는 다음과 같은 역할을 할 수 있다.
- 첫 번째는 리버스 프록시이다.
클라이언트의 요청을 대신 받아 내부 애플리케이션 서버로 전달한다. - 두 번째는 로드 밸런서이다.
여러 대의 서버가 있을 때 요청을 한 서버에만 몰아주지 않고 여러 서버로 분산한다. - 세 번째는 웹 서버이다.
HTML, CSS, JavaScript, 이미지 같은 정적 파일을 직접 제공할 수 있다. - 네 번째는 게이트웨이이다.
요청이 어떤 서버로 전달되어야 하는지 라우팅하고, HTTPS 설정, 로깅, 인증/인가와 같은 관문 역할을 수행할 수 있다.
프록시와 리버스 프록시
프록시는 클라이언트가 자신을 숨기기 위해 사용하는 서버이다.
예를 들어 클라이언트가 프록시 서버를 통해 요청을 보내면, 실제 서버는 클라이언트의 IP가 아니라 프록시 서버의 IP를 보게 된다. VPN도 넓은 의미에서는 중간 서버를 거친다는 점에서 비슷한 역할을 한다.
반대로 리버스 프록시는 서버가 자신을 숨기기 위해 사용한다.
클라이언트는 실제 애플리케이션 서버의 IP나 포트를 알지 못하고 Nginx로만 요청을 보낸다. Nginx는 이 요청을 받아 내부 서버로 대신 전달한다. 즉, Nginx를 리버스 프록시로 사용하면 클라이언트와 애플리케이션 서버 사이의 직접적인 의존성을 줄일 수 있다.
웹 서버와 WAS
서버가 제공하는 데이터의 종류에 따라 웹 서버와 웹 애플리케이션 서버를 구분할 수 있다.
웹 서버는 HTML, CSS, JavaScript, 이미지 같은 정적 콘텐츠를 제공하는 데 사용된다.
반면 WAS(Web Application Server)는 DB 조회, 비즈니스 로직 처리 등 동적 콘텐츠를 제공하는 역할을 한다.
물론 WAS만 사용해서 정적 파일과 동적 응답을 모두 처리할 수도 있다.
하지만 정적 콘텐츠 제공은 웹 서버가 더 효율적으로 처리할 수 있기 때문에, 실무에서는 웹 서버와 WAS를 함께 사용하는 경우가 많다.
Nginx 설치 및 실행
Nginx 서버에 접속한 뒤 다음 명령어로 Nginx를 설치한다.
sudo dnf install nginx
설치 후 Nginx를 실행한다.
sudo systemctl start nginx
정상적으로 실행 중인지 확인한다.
sudo systemctl status nginx
서버 재부팅 후에도 Nginx가 자동으로 실행되도록 설정할 수 있다.
sudo systemctl enable nginx
방화벽 설정
외부에서 80번 포트로 접근할 수 있도록 HTTP 서비스를 방화벽에 허용한다.
sudo firewall-cmd --permanent --add-service=http
sudo firewall-cmd --reload
Nginx 설정 변경
Nginx의 기본 설정 파일은 /etc/ngins/nginx.conf에 있다. 여기서 80번 포트로 들어온 요청을 Spring Boot가 실행 중인 8080 포트로 전달하는 설정을 추가해줘야 한다.
sudo vi /etc/nginx/nginx.conf
server {
listen 80;
location / {
proxy_pass http://localhost:8080;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
}
}
설정을 수정한 뒤에는 문법 검사를 먼저 수행한다.
sudo nginx -t
문법에 문제가 없다면 Nginx를 재시작하거나 reload해주면 된다.
sudo systemctl reload nginx
이번 글을 통해 Nginx가 왜 필요한지, 그리고 무중단 배포 환경에서 어떤 역할을 수행하는지 이해할 수 있었다. 다음 글에서는 CI/CD가 무엇인지에 대해서 정리해보려고 한다.
'Infra' 카테고리의 다른 글
| [CI/CD] Jenkins로 처음 구축해본 CI/CD 파이프라인3 (0) | 2026.03.27 |
|---|---|
| [Jenkins] Jenkins로 처음 구축해본 CI/CD 파이프라인1 (0) | 2026.03.22 |
| [k8s] 로컬로 쿠버네티스 구축하기 - minikube, kubectl (0) | 2026.03.08 |
| [k8s] 쿠버네티스란? (0) | 2026.03.04 |
| [AWS] Elastic Beanstalk로 FastAPI + Redis CRUD API 배포하기(2) (1) | 2025.06.07 |