NginX(Web Server)

Dana's Log·2022년 12월 23일

[참고 링크]
Web Server - WAS (참고:https://velog.io/@allsilver94/2-SpringBoot-Http-Socket)
https://www.youtube.com/watch?v=Zimhvf2B7Es

1. NginX (엔진 엑스)

경량 웹 서버
Event-Driven 구조(비동기 이벤트 방식)의 웹 서버 소프트웨어
HTTP Web Server - 클라이언트로부터 요청을 받았을 때 요청에 맞는 정적 파일(이미 생성되어 있는 데이터:html,css,img 등)을 응답
Reverse Proxy Server - WAS 서버의 부하를 줄일 수 있는 로드 밸런서로 활용
장애에 대한 대응 - NginX에 내장된 모듈 upstream module를 통해 부사분산, 속도 개선. 장애 발생시 다른 서버와 연결하여 사용자가 서비스 이용에 불편함이 없도록 구성가능.

리버스 프록시 (Reverse Proxy)
리버스 프록시 서버는 쉽게 설명하면 중계 기능을 하는 하는 서버이다. 클라이언트가 서버를 호출할 때 직접 서버에 접근 하는 것이 아니라 리버스 프록시 서버를 호출하게 되고, 리버스 프록시 서버가 서버에게 요청을 하고 응답을 받아 클라이언트에 전달을 한다.
(WAS, 웹 어플리케이션 서버는 대부분 DB 서버와 연결되어 있기 때문에 WAS가 최전방에 있으면 보안에 취약해짐)
클라이언트는 리버스 프록시 서버를 호출하기 때문에 실제 서버의 IP를 감출 수 있고(서버 내부적으로 파일들이 어느 폴더에 있는지, 어느 서비스가 어느 포트에서 작업 중인지 등 서버의 정보를 감춤) 이를 통해 보안을 높일 수 있다는 장점이 있다.
클라이언트와 WAS 사이의 중계자로서 둘 사이의 통신을 담당. WAS는 서버 확장에 있어 자유로워짐. 클라이언트가 요청하는 End Point는 프록시 서버의 도메인임.
!- 포워드 프록시 : 클라이언트(사용자)가 인터넷에 직접 접근하는게 아니라 포워드 프록시 서버가 요청을 받고 인터넷에 연결하여 결과를 클라이언트에 전달 (forward) 해준다. 프록시 서버는 Cache 를 사용하여 자주 사용하는 데이터라면 요청을 보내지 않고 캐시에서 가져올 수 있기 때문에 성능 향상이 가능.
(장점)
1.보안
프록시 서버를 사용하면 클라이언트나 서버 모두 IP를 숨길 수 있다. 실제 서버 또는 클라이언트의 IP를 숨기고 프록시 서버의 IP만 공개함으로써 해킹을 대비한다.
2.성능
프록시 서버를 사용하여 캐싱 기능과 트래픽 분산으로 성능 향상을 가져올 수 있다. 캐싱 기능은 자주 사용되는 동일한 요청을 캐싱하여 재활용하는 방식이다. 실제 서버로 다시 호출하지 않고 프록시 서버가 대신 응답을 주어 서버의 자원 사용을 줄여준다.
3.트래픽 분산
일부 프록시 서버는 로드 밸런싱도 제공하여 여러 대의 분산된 서버가 있다면 서버의 트랙픽을 분산시켜준다. 그리고 앤드 포인트(URL)마다 호출하는 서버를 설정할 수 있어 역할에 따라 서버의 트래픽을 분산할 수 있다.
HTTPS의 인증서 관리를 하나의 프록시 서버가 담당하고 뒤에 동작하고 있는 서버는 HTTP로 서비스할 수 도 있다. 이렇게 되면 서버를 실행할 때마다 인증서를 관리하지 않아도 되는 장점이 있다.

로드밸런싱
로드밸런서는 직역하면 부하 분산으로, 서버에 가해지는 부하를 분산해주는 역할을 하는 것이다.
이용자가 많아서 발생하는 요청이 많을 때, 하나의 서버에서 이를 모두 처리하는 것이 아니라 여러대의 서버를 이용하여 요청을 처리하게 한다.
이때 서버의 로드율과 부하량 등을 고려하여 적절하게 서버들에게 분산처리 하는 것을 로드 밸런싱이라고 한다.
하나의 서버가 멈추더라도 서비스 중단 없이 다른 서버가 서비스를 계속 유지할 수 있는 무중단 배포가 가능하다는 장점이 있다. (무중단 배포)

Event-Driven 처리 기반 구조

한 개 또는 고정된 프로세스만 생성하고, 여러 개의 Connection을 모두 Event-Handler를 통해 비동기 방식으로 처리합니다.
(Nginx의 비동기 이벤트란 HTTP 요청이 수 천 개여도 정해진 수의 프로세스(worker procss)가 이 요청들을 이벤트로 등록하고 비동기 방식으로 대기시켜 완료되는 요청(이벤트)부터 응답(처리)해주는 것을 말함)
적은 양의 스레드만 사용되기 때문에 Context Swiching 비용이 적고, CPU 소모가 적습니다.
Apache(HTTP 서버의 스레드/프로세스 기반 구조)와 달리 동시 접속자 수가 많아져도 추가적인 생성 비용이 들지 않습니다.
CPU와 관계없이 모든 I/O들을 전부 Event Listener로 미루기 때문에 흐름이 끊기지 않고 응답이 빠르게 진행되어 1개의 프로세스로 더 빠른 작업이 가능합니다. 이 덕분에 메모리를 적게 사용합니다.

Context Swiching
Context: 스레드가 작업을 진행하는 동안 작업정보(레지스터, 커널스택, 사용자스택 등)를 보관.
OS가 A작업을 진행할 때 A스레드의 Context를 읽어오며, B스레드로 전환 할 때 A스레드의 Context를 저장하고 B스레드의 Context를 읽어오는 일련의 반복을 수행.
스레드의 갯수가 많아질 수록 context swiching 작업은 더 빈번하게 일어나고, 이 때문에 성능이 저하될 수 있음.

2. NginX 내부 구조

NginX 1개의 master process와 3종류의 자식 프로세스로 구성

master process(Worker Process를 관리)
(1) 특권 명령을 수행하고, Single Thread로 구성된 다수의 Worker Process 관리
- listen socket에 port를 바인딩
- NginX 설정 읽기
- 아래 3가지 타입의 자식 프로세스 생성하고 관리
child processes
(1) cache loader
- 디스크 기반 캐시를 메모리에 불러오고, 종료
- NginX 시작 시 실행된다.
- 보수적으로 스케줄링되므로, 이 프로세스의 리소스 요구사항은 낮음
(2) cache manager
- 주기적으로 실행된다.
- 디스크 캐시를 설정된 사이즈로 유지하기 위해, 캐시 엔트리를 정리
(3) worker process(Single Thread)
- listen 소켓을 배정받는다.
- listen 소켓으로부터 클라이언트의 요청이 들어오면 커넥션을 형성하여 처리
- 초당 수천 개의 모든 http 요청을 한 프로세스에서 처리하고 응답
- CPU 코어당 1개의 worker 프로세스(싱글 스레드)를 생성하도록 설정하는 것을 권장
- 각 worker 프로세스들은 문맥 전환을 줄이기 위해, non-blocking 방식으로 동작한다.

3. NginX 구동 방식

NginX에서는 커넥션 생성 및 커넥션 제거, 그리고 새로운 요청을 처리하는 것을 이벤트라고 부른다. 이 이벤트들은 OS커널이 큐 형식으로 worker 프로세스에게 전달해주고, 이벤트가 큐에 담긴 상태에서 worker 프로세스가 처리할 때까지 비동기 방식으로 대기한다. 그리고 워커 프로세스는 하나의 스레드로 이벤트를 꺼내서 처리해 나간다. 이렇게 되면 워커 프로세스가 쉴틈없이 일하기 때문에 아파치 서버에서 요청이 없다면 방치되던 프로세스보다 서버 자원을 더 효율적으로 쓸 수 있게 되는 것이다.

그러나 네모 칸(큐)에 있는 요청(이벤트) 중 하나가 시간이 오래걸리는 작업(ex. Disk I/O)이면 어떻게 될까?

그 뒤에 있는 이벤트는 요청을 처리하는 긴 시간동안 블로킹이 된다. 그래서 NginX는 시간이 오래 걸리는 작업은 따로 수행하는 스레드 풀(Thread Pool)을 만들어놓고, 워커 프로세스는 지금 처리할 요청이 시간이 많이 걸릴 것 같다면 스레드 풀에 그 이벤트를 위임하고 큐 안에 있는 다른 이벤트를 처리하러 가게 된다.