Nginx

Apache의 구조

1. 아파치는 요청이 들어오면 커넥션을 형성하기 위해서 프로세스를 생성한다.

즉, 프로세스를 형성하고 커넥션을 맺는다. -> 새로운 클라언트 요청이 들어올 때마다 새로운 커넥션을 만든다.

1. 프로세스를 만드는 것은 시간이 오래걸리기 때문에 요청이 들어오기 전에 미리 만들어놓는 prefor 모드로 구성되어 있다. 그래서 새로운 클라이언트 요청이 들어오면 만들어놓은 프로세스를 사용한다.

• perfork : 자식 프로세스를 미리 생성하는 방식으로 최대 1024개 생성이 가능하고, 한 개의 스레드당 한 개의 프로세스를 연결한다. 스레드간 메모리를 공유하지 않아서 독립적 사용은 안정적이지만 메모리가 많이 사용된다.

🌟 C10K 문제. (Connection 10,000 problem)

https://en.wikipedia.org/wiki/C10k_problem

테크톡 pk의 nginx

• (1) 동시에 연결된 커넥션 수 : 서버가 요청을 처리하기 위해 얼마나 많은 클라이언트와 커넥션을 형성하는지를 나타냄

• (2) 초당 요청 처리 수 : 서버가 얼마나 빨리 요청을 처리할 수 있는지를 나타내는 지표

한 커넥션에서 여러 요청을 보낼 수 있기때문에 두 지표는 서로 같지 않다. (1) ≠ (2)

http 헤더에는 Keep-Alive라는 헤더가 있는데 client와 server는 여기 적힌 시간만큼 커넥션을 유지한다.

client의 수가 많아지면 동시에 연결된 커넥션 수가 많아질 것이다. 동시 커넥션이 10,000 단위가 넘어가는 순간에 server는 더이상 커넥션을 형성할 수 없는 문제이다. H/W의 문제가 아니라 아파치 서버의 구조였다.

아파치는 구조상 커넥션이 형성될 때마다 프로세스를 할당했기 때문에 동시에 처리하는 커넥션이 많아지면 그만큼 프로세스가 많이 있는것이고 결국 메모리 부족현상으로 이어진다.

또, 많은 connection에서 요청이 들어오기 시작하면 CPU 코어는 계속 프로세스를 바꿔가며 동작해야 했기 때문에 CPU가 할 일이 많아졌다. (CPU 부하)

• 컨텍스트 스위칭을 많이 해야한다.

즉, 수많은 동시 커넥션을 감당하기 위해서는 아파치 서버의 구조가 적합하지 않았다.

Nginx의 등장

2004년 아파치 서버를 보완하기 위한 S/W가 등장하는데 이것이 Nginx이다. 초창기 엔진엑스는 아파치와 함께 사용하기 위해서 만들어졌는데, 아파치를 완전히 대체할 목적은 아니였다. 위와 같은 아파치의 구조적 문제를 Nginx를 함께 사용함으로써 극복하려고 했다.

위 방식처럼 아파치 서버 앞단에 Nginx를 둔다면, 기존 아파치에서 감당해야 했던 수많은 동시 커넥션을 Nginx가 대신 유지할 수 있다. 구조적으로 동시 커넥션을 많이 유지 못하는 아파치 서버의 부하를 Nginx를 이용해서 많이 줄일 수 있다. Nginx도 웹 서버이기 때문에 정적 파일(image, html, css, js)에 대한 요청은 스스로 처리할 수 있다.

웹 서버는 클라이언트로부터 동적 파일 요청을 받을 경우에만 뒤에 있는 서버와 커넥션을 형성한다. 이렇게 동적 요청에만 아파치 서버와 커넥션을 가지면서 아파치 서버의 리소스를 커넥션 유지에 사용하지 않고 개발자의 로직 처리에 쓰도록 도와준다.

그럼 Nginx는 어떤 구조이기에 많은 동시 커넥션을 유지할 수 있을까?

Nginx는 1개의 마스터 프로세스(master process)와 여러개의 워커 프로세스들(work process)을 가지고 있다. 마스터 프로세스의 주요 역할은 설정(configuration)을 읽고 설정에 맞게 워커 프로세스들을 생성, 관리하는 것이다. 워커 프로세스의 역할은 실제로 요청들을 처리하는 애들이고, 생성될 때 지정된 listen socket을 배정받는다. 그리고 그 소켓에 새로운 클라이언트로부터 요청이 들어오면 conntection을 형성하고 요청을 처리한다.

워커에서 한번 커넥션이 생성 되었다고해서 그 커넥션에만 종속되지 않는다. 예를들어 한번 연결된 커넥션에서 Keep-Alive 시간동안 요청이 없으면 새로운 커넥션을 형성하거나 다른 커넥션으로부터 들어오는 요청을 처리한다. Nginx에서는 이러한 커넥션의 형성, 제거, 새로운 요청을 처리하는 것을 이벤트(Event)라고 부른다.

워커 프로세스는 보통 CPU의 코어 수 만큼 생성한다. 이렇게하면 코어가 담당하는 프로세스를 바꾸는 횟수를 대폭 줄일 수 있다.

• CPU가 이전의 아파치처럼 하지 않아도된다. → CPU의 컨텍스트 스위칭 사용을 줄인다.

이렇게 Nginx는 이벤트 기반 모델(Event-based model)을 사용하며, 운영체제에 의존적인(OS-dependent) 메커니즘을 활용해서 워커 프로세스들 사이의 요청을 효율적으로 분배한다. Nginx와 그 모듈들이 동작하는 방식은 configuration 파일 안에서 결정되는데, 파일 이름은 default로 nginx.conf이다.

Nginx의 SSL Termination

Nginx는 SSL 터미네이션을 수행할 수 있다.

• SSL Termination : Nginx가 클라이언트와는 https 통신을 하고, 서버와는 http 통신을 하는것을 얘기한다.

이 구조를 형성하면 서버가 복호화 과정을 감당하지 않고, 비즈니스 로직 처리에 리소스를 사용할 수 있도록 부하를 줄여준다. 보통 Nginx와 Server는 같은 네트워크 안에 존재하는 경우가 많기 때문에 http 통신을해도 보안 위험이 적다.

또, Nginx는 http 프로토콜을 사용해서 캐싱할 수 있다. 한번 서버로부터 받은 정보를 보관하고 클라이언트에게 전달한다.

Nginx는 이외에도 여러 기능이 있다.

• HSTS(Http Strict Transport Security)

• CORS 처리

• TCP/UDP 커넥션 부하 분산

• HTTP/2.0 지원

GitHub - h5bp/server-configs-nginx: Nginx HTTP server boilerplate configsGitHub

Nginx 설정 템플릿

• 제대로된 아키텍처를 구축하려면 템플릿보단 튜닝해서 사용해야 한다.

로드 밸런싱

로드 밸런싱은 서버에 들어오는 트래픽을 여러 서버로 분산시켜 처리하는 기술로, Nginx의 라우팅 기능을 통해 구현된다.

로드 밸런싱에는 L4, L7가 존재한다. 해당 프로토콜의 헤더를 부하 분산에 이용하기 때문에 이렇게 부른다.

L4는 전송 계층이므로 TCP, UDP의 정보(IP, PORT, MAC 주소 등)를 바탕으로 트래픽을 나누어 분산 처리한다.

• CLB(Connection Load Balancing) 또는 SLB (Session Load Balancing)이라고 부름

L7은 응용 계층에서 트래픽을 나누어 분산 처리한다.

HTTP, FTP, SMTP 등의 프로토콜을 기반으로 트래픽을 분산하기 때문에 HTTP 헤더, 쿠키 등과 같은 사용자 요청을 기준으로 특정 서버에 트래픽을 분산하는 것이 가능하다.

즉, 패킷의 내용을 확인하고 그 내용에 따라서 트래픽 분배가 가능하다.

• URL, 헤더 등을 확인해서 세분화하여 분산할 수 있다는 것이 장점이다.

• 바이러스를 감지해서 네트워크를 보호할 수 있어서 Dos와 같은 트래픽을 필터링할 수 있다.

참고 :

테코톡 피케이의 Nginx : https://www.youtube.com/watch?v=6FAwAXXj5N0

Ngninx 초보자 가이드 : https://architectophile.tistory.com/11