본문 바로가기

개발기술/Web Dev

NGNIX 사용

Nginx의 역할 개요

   Nginx는  "클라이언트 요청을 목적지로 라우팅(프록시)하는 고성능 리버스 프록시 서버" 로써 다양한 역할을 수행하는 강력한 서버 소프트웨어(미들웨어)입니다.

  본질적으로 "요청 분기 처리기", 즉 라우팅 분기

 

  부가적으로 요청 경로가 특정 조건(location block)에 맞으면, 디스크에서 직접 파일도 제공 가능

 

역할 설명
① 웹 서버 (Web Server) HTML, CSS, JS, 이미지 등 정적 파일을 빠르게 서빙
② 리버스 프록시 (Reverse Proxy) 클라이언트 요청을 받아 백엔드 서버(Spring, Node 등)로 전달
→ 백엔드 직접 노출 없이 보호 및 전달
③ 로드 밸런서 (Load Balancer) 여러 서버에 요청을 분산하여 트래픽 균형 유지
④ 보안 게이트웨이 (Security Gateway) SSL(HTTPS), IP 차단, DDoS 방지, CORS 제한, Rate Limit 등
⑤ 성능 최적화 (Performance Optimization) 캐싱, 압축(Gzip), Keep-Alive 등으로 응답 속도 향상

 

Nginx의 분기 기반 처리 흐름

Nginx는 다음 기준에 따라 요청을 분기(routing) 해:

  1. 포트 (listen)
    • listen 80, listen 443 ssl 등으로 어떤 포트로 요청이 들어왔는지에 따라 처리.
  2. 도메인 (server_name)
    • server_name api.myapp.com, admin.myapp.com 이런 식으로 요청된 호스트네임에 따라 어떤 server 블록을 쓸지 결정.
  3. 경로 (location)
    • /api/, /admin/, /static/, / 등 요청 경로에 따라 처리 대상 설정.
    • 여기서 proxy_pass, root, rewrite 등으로 내부 처리를 설정함.

 

 

1. Nginx의 주요 역할

웹 서버(Web Server)

📌 정적 파일(HTML, CSS, JS, 이미지 등)을 빠르게 제공하는 웹 서버 역할
📌 Apache보다 가볍고 성능이 뛰어나 대규모 트래픽 처리에 강함

💡 예제: 정적 파일 제공 설정

 

location /static/ {
root /var/www/html;
try_files $uri $uri/ =404;
        }
명령어 의미
location /static/ /static/ 경로로 시작하는 요청 처리
root /var/www/html 실제 파일 경로를 /var/www/html/static/로 매핑
try_files $uri $uri/ =404; 요청한 경로가 존재하는 파일인지 확인하고 없으면 404 반환

 

내부 파일 보호 + X-Accel-Redirect

location /internal-files/ {
internal;
alias /var/www/files/;
        }
명령어 의미
location /internal-files/ 내부 파일 요청 전용 처리
internal 직접 접근 ❌, X-Accel-Redirect 헤더로만 접근 허용
alias 실제 디렉토리를 지정 (/var/www/files/)

 

리버스 프록시(Reverse Proxy)

📌 클라이언트 요청을 받아 백엔드 서버(Spring Boot, Node.js 등)로 전달하는 역할
📌 직접 백엔드 서버에 접근하지 못하게 보호하는 기능
📌 부하 분산(Load Balancing)과 보안 기능을 결합할 수 있음

💡 예제: 리버스 프록시 설정

 

✅ 클라이언트가 api.example.com으로 요청을 보내면 backend_server로 전달
✅ 백엔드 서버를 직접 노출하지 않음 → 보안 강화

server {
    listen 80;
    server_name api.example.com;

    location / {
            proxy_pass http://localhost:8080;
    }
}

 

명령어 의미
server { ... } 하나의 가상 호스트 설정 시작 (도메인, 포트별 서비스)
listen 80; 80 포트에서 HTTP 요청 수신
server_name yourdomain.com; 이 블록은 yourdomain.com 요청에 대응
location / { ... } /으로 시작하는 모든 요청 처리 블록
proxy_pass http://localhost:8080; 요청을 8080에서 실행 중인 백엔드(Spring 등)로 전달

 

 로드 밸런서(Load Balancer)

📌 여러 개의 백엔드 서버에 트래픽을 분산하여 부하를 줄이는 역할
📌 트래픽이 몰리는 특정 서버를 보호하여 서비스 안정성 향상

💡 예제: 두 개의 백엔드 서버로 부하 분산

 

✅ 클라이언트 요청을 backend1 또는 backend2로 자동 분배
✅ 특정 서버 과부하 방지

upstream backend {
server 192.168.0.10:8080;
server 192.168.0.11:8080;
        }
server {
    location / {
            proxy_pass http://backend;
    }
}
명령어 의미
upstream backend { ... } 로드밸런싱 대상 서버 그룹을 정의 (이름: backend)
server 192.168.0.10:8080; 첫 번째 백엔드 서버
server 192.168.0.11:8080; 두 번째 백엔드 서버
proxy_pass http://backend; 클라이언트 요청을 위의 백엔드 서버 그룹 중 하나에 분산 전달

 

 

Nginx 경로 분기(Path-based routing)

 

 

 

 

 

 

 

server {
    listen 80;
    server_name myapp.com;

    # ✅ /api로 시작하는 요청은 Spring API 서버로 전달
    location /api/ {
            proxy_pass http://localhost:8080;
    }

    # ✅ /files로 시작하는 요청은 Nginx가 직접 파일을 서빙
    location /files/ {
            alias /var/www/files/;
    }

    # ✅ /images 같은 정적 리소스 경로도 서빙 가능
    location /images/ {
            root /static/assets/;
    }
}

 

 

이렇게 설정해두면,

  • /api/user → Spring 서버 (8080)
  • /files/abc.pdf → Nginx 정적 파일
  • /images/logo.png → Nginx가 서빙

 

[Client] ─▶ Nginx (80/443)
               ├── /api/**    → Spring API (8080)
               ├── /files/**  → 정적 파일
               └── /health    → 헬스체크 등
✔️ Spring은 내부포트(8080)에서만 listen
✔️ 외부는 오직 Nginx(80/443)만 노출
✔️ Nginx가 모든 요청을 분기 + 제어 + 보호

 

 

  • 왜 하나의 웹서버로 여러가지 도메인을 라우팅하는 방식이 일반적인가?]
    • 서버 인프라 절감 : Nginx는 리소스를 거의 쓰지 않기 때문에 굳이 도메인마다 별도 서버를 만들 필요가 없음.
    • 운영/배포가 단순 : SSL 인증서(*.myapp.com) 하나로 통일해서 관리 가능. 도메인마다 백엔드만 다르게 넘겨주면 되니 구성도 단순.
    • 보안, 캐싱, 로깅 설정 일관 관리 :  헤더, gzip 압축, access log, rate limiting 같은 걸 하나의 config에서 공통 적용 가능.

 

Ngnix 주요설정

 

Ngnix 설정 계층구조

  위쪽은 Nginx 엔진의 운영 세팅, server {}는 각 요청 처리 규칙 (도메인/포트/경로 등)

nginx.conf
├── worker_processes
├── events
└── http
    ├── 공통 설정들 (mime, keepalive 등)
    ├── server { ... }   ← 도메인이나 용도별 설정
    ├── server { ... }

 

 

worker_processes 1;

events {
    worker_connections 1024;
}

http {
    include       mime.types;
    default_type  application/octet-stream;

    sendfile        on;

    keepalive_timeout  65;

 

 

1. worker_processes 1;

  • Nginx가 동시에 몇 개의 프로세스를 실행할지를 정함.
  • 이벤트 루프방식으로 1프로세스당 1스레드이므로, CPU 코어 수에 맞춰 프로세스의 개수를 설정하는 게 일반적 (예: 4코어면 4)

2. events { worker_connections 1024; }

  • 각 워커 프로세스가 동시에 처리할 수 있는 클라이언트 연결 수
  • 예: 1개의 worker × 1024 → 최대 1024개의 동시 접속 처리

3. http { ... }

  • HTTP 관련 전체 설정 블록 (가장 핵심)
  • 이 안에 server {}들을 여러 개 둘 수 있어
  • 또한 여기에 다음과 같은 공통 설정들이 들어감:
    • include mime.types:  Ngnix가 클라이언트에게 response를 보낼 때 파일 확장자에 맞는 Content-Type 공지하여 파일의 MIME 타입(Content-Type)을 알려주는 역할
      • 만약 mime.types가 없다면? 설정이 없거나 잘못되면 default_type에 지정된 application/octet-stream이 들어가서 브라우저가 이미지를 미리보기 형식으로 띄우기보다, 파일을 그냥 "다운로드"로 처리할 수 있음 (타입을 알 수 없으니까)
    • sendfile on: 파일 전송 최적화
    • keepalive_timeout: HTTP keep-alive 연결 유지 시간

 

server {
    server_name api.myapp.com;
    location / {
        proxy_pass http://localhost:8081;
    }
}
server {
    server_name admin.myapp.com;
    location / {
        proxy_pass http://localhost:8082;
    }
}

 

 

 

server {
    listen 80;
    server_name myapp.com;

    location / {
        root /var/www/frontend;
        index index.html;
        try_files $uri $uri/ /index.html;
    }

    location /api/ {
        proxy_pass http://backend:8080;
    }

    location /admin/ {
        proxy_pass http://admin-api:8081;
    }

    location /files/ {
        root /var/www; # 파일서버
    }
}

 

  • listen 80 ;  이 서버 블록이 HTTP 기본 포트인 80번에서 요청을 받아들이겠다는 의미
  • server_name localhost ; 서버가 어떤 이름의 도메인으로 들어온 요청을 처리할지 지정.
    • localhost는 로컬 환경에서 테스트할 때 기본값. 실제는 server_name yourdomain.com; 처럼 DNS와 연결된 도메인
    • Nginx는 server_name 없는 설정을 default server로 간주해 처리할 수도 있음. 단, 여러 server 블록이 있으면 명확한 도메인 지정이 필요.

 

location /files/floorplan/ {
    alias C:/Users/bsh62/platform/floorplan/;
    autoindex off;
    access_log off;

    expires 30d;
    add_header Cache-Control "public";
}
  • location /files/floorplan/ { ... } ; 정적 이미지 파일을 서빙하는 부분
    • location /files/floorplan/ : /files/floorplan/으로 시작하는 URL 요청이 오면 이 블록이 실행됨.

 

요청 경로(URL)와 실제 파일 경로(디스크) 매핑

  • root 사용 시 : 웹 루트에서 url의 경로를 서브 경로처럼 취급하고 싶을 때 사용. root의 주소+ location 뒤 경로
  • alias C:/Users/bsh62/platform/flow-plan/ ; alias는 전체 경로를 직접 치환해서 실제 디스크 상의 경로를 지정해 줌.
    • 즉 : http://localhost/files/floorplan/123/abc.jpg → 실제 파일: C:/Users/bsh62/platform/flow-plan/123/abc.jpg
location /files/ {
    root /var/www;
}
GET http://localhost/files/example.jpg
/var/www/files/example.jpg

 

location /files/ {
    alias /var/www/files/;
}
GET http://localhost/files/example.jpg
/var/www/files/example.jpg

 

  • autoindex off :  디렉토리 listing 금지. /files/floorplan/39/처럼 폴더만 접근 시 파일 목록 보이는 걸 막음.
  • access_log off; : 이 경로에 대한 요청은 로그를 남기지 않음 (불필요한 로그 방지).
  • expires 30d; / add_header Cache-Control "public";: 브라우저 캐시 설정.
    • 파일을 받아간 클라이언트는 30일 동안 새로 받지 않아도 됨.
    • 이미지는 자주 안 바뀌니까, 30일간 브라우저 캐싱 허용해서 트래픽 줄이는 목적.

 

'개발기술 > Web Dev' 카테고리의 다른 글

Static File Upload  (0) 2025.04.12
Tomat And Netty  (0) 2025.04.06
RESTFUL API 설계  (0) 2024.12.15
Interception , Filter  (0) 2024.09.05
프론트엔드 연계 관련 지식  (0) 2024.07.08