Nginx

💬 Nginx를 공부하기 전에, 먼저 웹 서버가 무엇인지부터 알아보자.

💡웹 서버(Web server)

• 웹 페이지와 웹 애플리케이션을 클라이언트에게 제공하는 역할을 수행하는 컴퓨터 프로그램 또는 하드웨어
  (여기서 클라이언트는 웹 브라우저)
• 정적 콘텐츠(HTML, CSS, JavaScript, 이미지 등)를 클라이언트(브라우저)에 제공
• 대표적인 웹 서버로는 Apache HTTP Server, Nginx 등이 있음
• 이때 웹 서버는 정적인 페이지만 처리 가능하다는 한계가 나타났고 이에 WAS가 등장

WAS(Web Application Server)

• 웹 서버가 처리할 수 없는 동적 콘텐츠(사용자 인증, DB 조회 등)를 담당
• 클라이언트의 요청에 따라 애플리케이션 로직을 실행하고, 데이터베이스와 상호작용하여 결과를 생성한 후,
  이를 웹 서버를 통해 클라이언트로 반환

 

💡 Apache vs Nginx

• Apache
  • 1995년에 출시된 가장 오래되고 널리 사용되는 웹 서버
  • 프로세스/쓰레드 기반 멀티프로세스 구조를 채택
  • 요청 처리 방식을 결정하는 MPM을 통해 유연한 아키텍처를 제공
    MPM(Multi-Processing Module)
    

    : 클라이언트에서 요청이 들어올 때 어떤식으로 처리할것인지에 대한 모듈

    • prefork
      • 하나의 요청에 대해서 하나의 자식 프로세스가 하나의 쓰레드를 사용해서 처리하는 방식
      • 동시에 여러개의 요청이 들어온다면 생성되어있는 자식 프로세스에서 각 요청을 처리하게 된다. 각 프로세스들의 자원은 독립적이므로 다른 요청이 들어오거나 프로세스 하나에 장애가 발생하더라도 다른 요청에 영향이 가지 않는다는 이점이 있다.
      • 하지만 프로세스가 많아진다면 프로세스가 차지하고 있는 메모리 공간이 크기 때문에 부하가 일어날 수 있다는 단점이 있다.
    • worker
      • 하나의 자식 프로세스 안에 여러개의 쓰레드를 사용하고, 각 요청은 각 쓰레드에서 처리
      • 제한된 쓰레드 수를 넘어가면 새로운 자식 프로세스를 생성해서 처리
      • prefork에 비해 메모리가 절약된다는 장점이 있지만, 쓰레드끼리 자원을 공유하기 때문에 프로세스가 죽으면 다른 쓰레드들도 같이 죽을 수 있음
    • event
      • Nginx의 성공 이후 Apache도 비동기 처리 방식의 중요성을 인식하게 되었고, 이를 반영한 Event MPM을 개발
      • 기존 prefork(프로세스 기반)과 worker(쓰레드 기반) MPM의 단점을 보완
      • 비동기 방식과 쓰레드 풀을 활용하여 클라이언트 요청을 처리하는 고성능 방식
  • 프로세스나 쓰레드 하나가 하나의 요청을 처리하는 방식으로 인해, 메모리 사용량과 CPU부하가 급증하는 문제점(C10k(Connection 1000 problem)) 발생
  • 이러한 문제점들을 해결 가능한 Nginx가 등장 (2004년)

 

💡 Nginx

• 초창기의 Nginx는 완전히 Apache를 대체할 목적은 아니었으며, Apache 서버의 구조적인 문제를 해결하기 위해 함께 사용되기 시작
• 수많은 동시 connection을 Nginx가 유지하고 정적 파일에 대한 요청은 스스로 처리하지만, 웹 서버인 Nginx는 동적파일에 대한 요청은 처리할 수 없으므로, Apache 서버와 connection을 형성하여 부하를 줄여줌

 

❓Nginx는 어떻게 수많은 동시 connection 을 유지할 수 있을까

  Nginx의 동작원리

• 설정파일을 읽고, 설정에 맞게 worker process를 생성하는 master process로 구성
  • Master Process
    • Nginx 서버의 관리와 설정을 담당하는 프로세스
    • 실제 클라이언트 요청을 처리하진 않음 Master Process
  • Worker Process
    • 실제 클라이언트의 요청을 처리하는 프로세스
    • 한개의 worker process는 여러 개의 요청을 동시에 처리 가능
    • 생성 시 지정된 Listen 소켓을 배정받고, 그 소켓에 새로운 클라이언트의 요청이 들어오면 connection을 형성하고, 이 connection은 정해진 시간(Keep-Alive)만큼 유지
      

      Listen 소켓

      • 소켓(Socket)은 네트워크 통신을 위해 서버와 클라이언트가 데이터를 주고받는 통로
      • 서버가 특정 포트에서 클라이언트의 요청을 받으려면, 그 포트를 열어놓고 기다려야 하는데, 이때 사용되는 것이 Listen 소켓
      • 즉, 서버가 클라이언트의 연결 요청을 받을 준비가 되어 있음을 나타내는 소켓
      • 쉽게 말해 서버가 클라이언트로부터 연결을 기다리고 있는 상태라는 의미
      • 클라이언트가 연결을 시도하면, 서버는 Listen 소켓을 통해 요청을 수락하고, 새로운 소켓을 만들어서 해당 클라이언트와 데이터를 주고받음
      • 즉, 클라이언트와 연결이 성사되면 Listen 소켓은 더 이상 사용되지 않고 새로운 소켓이 연결을 담당
    • worker process는 해당 connection 하나만 담당하지 않고, 형성된 connection으로부터 아무런 요청이 없다면 새로운 connection을 형성하거나 이미 만들어진 다른 connection으로부터 들어온 요청을 처리함
    • 이러한 connection 형성과 제거, 그리고 새로운 요청을 처리하는 것을 이벤트(Event) 라고 함

  Nginx의 특징

• 이벤트 기반 비동기 아키텍처를 도입하여, 가벼운 리소스로도 높은 동시 연결 처리가 가능
  • 이벤트 기반 처리 (Event-Driven)
    • 이벤트(Event)들은 큐(Queue) 형식으로 worker process에 전달되며, 이 이벤트들은 큐에 담긴 상태에서 비동기 상태로 대기
    • worker process는 이 큐에서 하나씩 이벤트를 꺼내 처리하는 방식으로 요청을 처리
    • 이런 방식은 worker process가 쉬지 않고 일을 하기에, 요청이 없을 때 프로세스를 방치시키는 Apache Server보다 훨씬 효율적으로 자원을 사용할 수 있음
• 리버스 프록시 및 로드 밸런싱 사용 가능
  • 인터넷 접속을 할 때 보안상의 문제로 직접 통신을 주고 받을 수 없을 경우, 그 사이에서 대신 통신을 수행하는 기능을 프록시(Proxy)라고 함
    • 포워드 프록시(Forward Proxy)
      • 프록시 서버클라이언트와 서버 사이에서 클라이언트의 요청을 대리하여 서버와 통신하는 프록시 서버
    • 리버스 프록시(Reverse Proxy)
      • 클라이언트와 서버 사이에서 서버의 응답을 대리하여 클라이언트와 통신하는 프록시 서버
    • 리버스 프록시를 사용하면 클라이언트의 요청이 반드시 리버스 프록시를 거쳐야 하므로, 요청을 여러 서버에 분산시키는 로드 밸런싱이 기술적으로 쉽게 구현 가능
      • 로드 밸런싱 : 클라이언트 요청을 여러 서버에 분배하여 트래픽을 균등하게 처리하도록 하는 기술
• Nginx는 정적 리소스를 캐싱하여 WAS에 불필요한 요청이 전달되지 않도록 함
• 이 외에도 SSL/TLS 암호화, URL 리다이렉션 등 다양한 기능을 제공하여 웹 서버의 유연성과 안정성을 높일 수 있음
  
  

💡 Nginx 설정 코드 예시

1. Nginx 기본 설정

user nginx;
worker_processes  auto;
error_log  /var/log/nginx/error.log warn;
pid        /var/run/nginx.pid;;

• user nginx;
  • Nginx가 어떤 사용자 권한으로 실행될지 설정
  • 보통 nginx 사용자로 실행

• worker_processes auto;
  • Nginx가 사용할 워커 프로세스의 수를 설정
  • auto는 CPU 코어 수에 맞춰 자동으로 설정

• error_log와 pid: 에러 로그를 저장할 파일 경로와 PID 파일 경로를 설정합니다.

2. events 블록

events {
    worker_connections 1024;
}

• worker_connections 1024;
  • 각 워커 프로세스가 동시에 처리할 수 있는 최대 연결 수를 설정
  • 여기서는 1024개의 연결을 처리할 수 있음

3. http 블록

: http 블록 안에서 여러 설정을 하는데, 여기서 upstream과 server 부분이 중요

 

upstream 블록

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

	# 백엔드 upstream 설정
    # upstream myweb-api {
    #     server api:8080;
    # }

	# 프론트엔드 upstream 설정
    upstream next-server {
        server 172.17.0.1:3000; # docker를 사용하지 않는다면 localhost:3000(웹서버주소)
    }

• upstream next-server
  • 여러 백엔드 서버를 정의하는 블록으로, 여기서는 하나의 서버(172.17.0.1:3000)를 지정하고 있는데, 이는 Nginx가 요청을 전달할 서버
  • 만약 여러 서버가 있다면 upstream에 여러 server 항목을 추가하여 로드 밸런싱을 할 수 있음

server 블록

    server {
        listen 80;

		# /api 경로로 오는 요청을 백엔드 upstream 의 /api 경로로 포워딩
        # location /api {
        #     proxy_pass         http://myweb-api/api;
        # }

		# / 경로로 오는 요청을 프론트엔드 upstream 의 / 경로로 포워딩
        location / {
            proxy_pass         http://next-server/;
            proxy_http_version 1.1;
            proxy_set_header Upgrade $http_upgrade;
            proxy_set_header Connection 'upgrade';
            proxy_set_header Host $host;
            proxy_cache_bypass $http_upgrade;
        }
    }

• listen 80;
  • Nginx가 80번 포트(HTTP 기본 포트)에서 요청을 듣도록 설정
• location /
  • / 경로로 오는 모든 요청에 대해 처리 방법을 정의
• proxy_pass http://next-server/;
  • /로 들어오는 요청을 upstream에 정의된 next-server로 전달
  • 즉, http://172.17.0.1:3000/으로 요청을 보냄
• proxy_http_version 1.1
  • HTTP/1.1을 사용하도록 설정
•  proxy_set_header
  • 프록시 요청 시 헤더를 설정하는 부분으로, 요청을 원활하게 처리하기 위해서 필요
  • 예를 들어, Upgrade와 Connection 헤더는 WebSocket 연결을 지원하기 위해 설정
• proxy_cache_bypass $http_upgrade;
  • WebSocket 연결을 위한 업그레이드 헤더가 있을 경우 캐시를 우회하도록 설정

4. 작동 원리

1. 사용자가 Nginx 서버에 요청을 보낸다. (예를 들어, http://localhost:80/ 주소로 접근)
2. Nginx는 location / 블록에서 proxy_pass로 지정된 next-server에 요청을 전달한다.
   (이 경우 next-server는 upstream 블록에서 정의한 172.17.0.1:3000 서버)
3. 프론트엔드 서버 (예: Next.js)가 172.17.0.1:3000에서 실행되고 있다고 가정하면, 이 서버가 실제 요청을 처리하고 결과를 Nginx로 다시 보낸다.
4. Nginx는 받은 응답을 사용자에게 전달한다.

5. 설정에서 중요한 부분

• proxy_pass
  •  클라이언트의 요청을 특정 서버(여기서는 next-server)로 전달하는 역할을 함
• upstream
  • 여러 서버를 묶어서 하나의 서버처럼 사용하려는 설정으로, 여러 개의 서버를 정의하여 로드 밸런싱을 할 수 있음
• proxy_set_header:
  • 클라이언트 요청의 일부 헤더를 백엔드 서버로 전달하는 데 사용
    예를 들어, WebSocket을 지원하려면 Upgrade 및 Connection 헤더를 설정해야 함

 

---

참조

https://blog.naver.com/gi_balja/223028077537
https://jammdev.tistory.com/217
https://velog.io/@choidongkuen/%EC%84%9C%EB%B2%84-Nginx-%EB%9E%80
https://nginxstore.com/blog/nginx/nginx-%EB%9E%80/
https://wikidocs.net/223839