Post

Nginx를 왜 쓰지?

나는 Nginx와 같은 웹서버의 기능이 막연하게 로드밸런싱, 포트포워딩 정도로만 알고 있다. 그래서 디테일하게 공부해보려고한다.

웹 서버?

  • 클라이언트의 요청을 받아 HTML 문서, 객체 등의 데이터를 반환하는 역활
  • HTTP 프로토콜로 통신, 클라이언트가 특정 url에 접속하면 웹 서버는 해당 요청에 맞는 데이터를 찾아서 보내줌
  • 단순히 페이지 보여주는 것 넘어, 사용자 인증 보안 등 다양한 기능 수행하고 대표적으로 Apache, Nginx 등

Proxy?

프록시 서버는 클라이언트와 다른 서버 사이를 중개하는 역활을 하는 서버로, 클라이언트가 다른 서버에 접속하거나 데이터를 요청할 때 직접 연결하는 대신 프록시 서버를 거쳐 요청하고 응답받음

  • 캐싱: 프록시 서버는 자주 요청되는 웹 페이지나 파일들을 임시로 저장하고 같은 요청이 들어올 때, 서버에서 다시 가져오는 대신 캐시된 데이터를 사용하여 빠르게 응답이 가능.
  • 보안: 프록시 서버는 내부 네트워크와 외부 네트워크 사이의 중간 단계로 작동하여, 외부로부터의 불필요하거나 위험한 접근을 차단할 수 있고 사용자의 IP 주소를 숨길 수 있음.
  • 접근 제어: 프록시 서버를 통해 특정 웹 사이트나 서비스에 대한 접근을 제한하거나 특정 사용자나 그룹의 인터넷 사용을 제어(ex. 부적절한 사이트 차단 등)
  • 지역 제한 우회: 프록시 서버는 사용자의 실제 지리적 위치를 숨기고 다른 지역에서의 접속처럼 보이게 할 수 있어서 지역적으로 제한된 콘텐츠에 접근 가능.

Reverse Proxy

일반적으로 프록시 서버라고 했을 때 생각하는 가장 흔한 형태는 Foward Proxy. 아래 이미지 처럼 클라이언트의 요청을 서버에 직접 연결하는 것이 아니라 프록시 서버가 중계함

image

프록시 서버가 클라이언트와 인터넷 사이에 위치한다면, 리버스 프록시는 아래 이미지와 같이 외부 요청과 내부 서버 사이에 위치하는 프록시 서버. 프록시 서버는 클라이언트를 대신해서 인터넷에 접근하는 역확을하고, 리버스 프록시 서버는 외부에서 내부로의 접근을 관리.

image

캐싱, 접근제어, 보안 등의 기능을 수행한다는 점은 같지만 주요 차이점은 아래와 같음

  • 작동 방향
    • 포워드 프록시는 클라이언트 측에서 작동해서 클라이언트의 요청을 인터넷에 전달
    • 리버스 프록시는 서버 측에서 작동해 외부의 요청을 내부로 전달
  • 보호 대상
    • 포워드 프록시는 클라이언트의 보호에 중점
    • 리버스 프록시는 내부 서버의 보안과 부하의 분산을 목적으로함

Nginx 특징 vs Apache

  1. 성능 및 아키텍처
    • Nginx: 비동기 이벤트 기반 모델을 사용해 많은 수의 동시 연결을 효율적으로 처리할 수 있게 해 높은 성능. 특히, 정적 콘텐츠를 제공하거나 리버스 프록시로서의 역할에 있어서 뛰어난 처리 능력
    • Apache: 프로세스 기반 또는 스레드 기반의 멀티-프로세싱 모듈(MPM)을 사용하고 이는 각 요청을 별도의 프로세스 또는 스레드에서 처리. 설정에 따라 성능을 최적화할 수는 있으나, Nginx에 비해 많은 동시 연결을 처리하는데 있어서는 상대적으로 자원 사용량이 더 높을 수 있음.
  2. 메모리 사용량 및 리소스 효율성
    • Nginx: 메모리 사용량이 적고 리소스를 효율적으로 사용. 이는 저용량 또는 고성능이 요구되는 환경에서 유리함.
    • Apache: 비교적 더 많은 메모리와 리소스를 사용할 수 있음. 다양한 모듈과 상세한 설정이 가능하다는 장점이 있지만, 대규모 동시 연결 처리 시 리소스 사용량이 증가

nginx는 시작 시 필요한 메모리를 할당하고, 이후 추가적인 연결에 대해 매우 적은 양의 메모리만 추가로 사용하는 방식으로 메모리 사용을 최소화한다.

  1. 리버스 프록시 및 로드 밸런싱
    • Nginx: 리버스 프록시와 로드 밸런싱 기능이 핵심 기능
    • Apache: 모듈을 통해 리버스 프록시와 로드 밸런싱 기능을 제공할 수 있지만, Nginx만큼 효율적이진 않음. Apache는 다양한 기능과 유연성에 중점을 둔 설계로, 복잡한 구성이 가능
  2. 정적 및 동적 콘텐츠 처리
    • Nginx: 정적 파일을 처리하는데 있어서 매우 빠르며, 동적 콘텐츠의 경우 백엔드 애플리케이션 서버로의 프록시 역할을 통해 처리
    • Apache: mod_php와 같은 모듈을 통해 동적 콘텐츠를 직접 처리할 수 있으며, 정적 파일도 효율적으로 제공. 동적 콘텐츠 처리에 있어서는 Apache가 Nginx보다 더 유연

Apache는 클라이언트의 요청 마다 하나의 프로세스를 만드는데, 프로세스를 만드는데 많은 시간이 소요되기 때문에 prefork 방식으로 요청이 오기 전 미리 프로세스를 만드는 방식으로 구성되어 있다. 이런 구조는 동시에 여러 요청을 처리하기에 메모리 비효율 적이고 이를 극복하고자 nginx가 개발되었다.

ex) 고객(클라이언트의 요청)이 식당에 들어올 때마다 새로운 요리사(프로세스)가 할당되고, 많은 고객을 대비해 미리 요리사를 준비해 두는 것.

Nginx는 이벤트 기반 처리 방식으로 소수의 워커 프로세스가 여러가지 요청을 동시에 처리한다.

ex) 소수의 요리사(워커 프로세스)가 여러 고객(클라이언트의 요청)을 담당하는 것

Nginx Process 처리량 늘리기

  1. Linux 커널 튜닝
  • fs.file-max 값은 시스템 전체의 모든 프로세스에 대해 열 수 있는 파일의 최대 수를 결정함.
    • /etc/sysctl.conf' 파일에서 설정 fs.file-max = 10000 후 sysctl 재시작 sudo sysctl -p`
  1. Nginx 워커 프로세스와 백로그

nginx.conf에서 워커프로세스 관련 설정

  • worker_process : cpu core 수에 따라 설정하고 20% 정도는 os를 위해 남겨둬야함, auto로 설정하면 nginx가 자동으로 cpu 코어 수에 맞춰 설정
  • worker_rlimit_nofile : 작업 프로세스가 열 수 있는 파일의 수를 제한
  • worker_connections : 동시에 받을 수 있는 요청의 수
  • multi_accept on : 요청을 순차적으로 받는 것이 아니라 동시에

백로그는 동시에 대기할 수 있는 연결 요청의 최대 수를 지정

1
2
3
4
server {
    listen 80 backlog=2048;
    # 기타 서버 설정...
}

Reference

  • https://www.lesstif.com/system-admin/forward-proxy-reverse-proxy-21430345.html
  • https://f-lab.kr/insight/web-server-and-nginx
  • https://couplewith.tistory.com/231?category=212810
This post is licensed under CC BY 4.0 by the author.