webserver_NGINX

1 웹서버가 필요한 이유
1.1 웹서버의 정의
클라이언트에게 정적인 콘텐츠를 제공하는 서버를 Web Server(웹서버)라고 한다. 

정적인 콘텐츠가 아니라 클라이언트 요청에 따라서 제공되는 응답이 달라지는 것을 동적인 콘텐츠라고 하고, 

동적인 콘텐츠를 제공하는 서버를 Application Server(어플리케이션 서버)라고 한다.

 

1.2 웹서버가 필요한 이유

1.2.1

API 서버를 스프링과 같은 프레임워크를 이용해서 코드를 짜서 만들었다고 해보자.

클라이언트가 요청한 것에 대해서 해당 코드로 로직을 수행하고 그 결과를 응답할 것이다.
웹서비스를 생각해보면, 이렇게 요청의 내용을 해석해야하는 것도 있지만 그렇지 않은 콘텐츠가 많다. 

html파일, 이미지, 동영상등은 대부분 생성된 뒤로 변경되지 않고 매번 같은 파일을 제공하면 되는 경우가 많다. 

이런 경우 엔드포인트 주소가 명확히 대상을 가리킨다면 굳이 로직을 거치지 않아도 된다.
게다가 웹서비스가 커지거나 사용자가 많아질수록 요청량을 빨리 처리하는 것이 중요한데 모든 요청이 코드로된 로직을 거쳐야한다면 그
부하를 해결하는 것도 큰 과제이다.
정적인 콘텐츠(대상)에 대해서는 어떤 응답을 하면되는지 알고있는 서버가 있다면 정적인 요청이 오면 웹서버가 응답하고, 

그렇지 않은 요청은 어플리케이션 서버에 요청을 전달(proxy)해서 응답하도록 하는 방법으로 응답속도도 높이고 어플리케이션 서버의 부하도 낮출 수 있다.
뿐만 아니라, 콘텐츠 제공에 있어서 모든 요청에 필수적으로 처리해야 하는 작업을 앞에서 먼저 해서 어플리케이션 서버에 부하를 낮출수
있는 작업들을 처리한다.

 

1.2.2 요즘 웹서버
요즈음 웹서버는 단순히 정적인 콘텐츠를 구분해서 제공하는 것에 그치는 것이 아니라 API Gateway, Load Balancing, Service
Discovery, Distributed Environment, Cloud Native 등의 기능이나 인프라를 지원하는 것을 목표로 하고 있다. 

사실상 API/Service Gateway와의 경계가 사라지고 있다.

 

1.3 웹서버의 종류들
1.3.1 Apache (HTTP server)
Apache (HTTP server) 는 오픈소스 웹서버의 원조로 불린다. 호환하는 OS의 종류가 가장 많다. 초기에는 요청에 대해서 synchronous하게 처리하는 아키텍처였다. 

NGINX 도 Apache 를 대항하고자 만들기 시작했다. NGINX 와의 성능차이가 많이 나면서부터 인기가 시들었지만, 아직도 사용하는 곳이 많다.

1.3.2 NGINX
오픈소스로 된 Web Server 중 가장 대중적인 제품. Apache 를 대항하기 위해 나왔고, 최초로 C10K problem 을 해결했다. 

비동기로 요청을 처리하는 아키텍처 덕분이다. NGINX 이후로 대부분의 웹서버들이 비동기로 처리를 지원하기 시작했다. 

멀티 프로세스로 동시에 여러 요청을 처리한다. C로 구현되어있다.

1.3.3 Caddy
Golang으로 만들어진 Web Server 이다. 운영체제에 따른 native library에 대한 dependency 없이 동작한다는 것을 장점으로 내세운다.
이 외에도 NGINX의 단점을 극복하기 위한 설계와 여러 기능이 있다.
1. easy configuration
2. modular architecture

 

2. NGINX 개요

엔진엑스(Nginx)는 Igor Sysoev라는 러시아 개발자가 동시접속 처리에 특화된 웹 서버 프로그램이다. 

Apache보다 동작이 단순하고, 전달자 역할만 하기 때문에 동시접속 처리에 특화됨

동시접속자(약 700명) 이상이라면 서버를 증설하거나 Nginx 환경을 권장한다고 한다.

지금은 아파치가 시장 점유율이 압도적(?)이지만, 아마존웹서비스(AWS) 상에서는 시장 점유율 44%에 달할정도로 가볍고, 성능이 좋은 엔진임

 

2.1. NGINX 역할

1-1. 정적 파일을 처리하는 HTTP 서버로서의 역할

- 웹서버의 역할은 HTML, CSS, Javascript, 이미지와 같은 정보를 웹 브라우저(Chrome, Iexplore, Opera, Firefox 등)에 전송하는 역할을 한다. (HTTP 프로토콜을 준수)

 

1-2 응용 프로그램 서버에 요청을 보내는 리버스 프록시로서의 역할

- 두번째 역할은 리버스 프록시(reverse proxy)인데, 한마디로 말하면 클라이언트는 가짜 서버에 요청(request)하면 프록시 서버가 배후 서버(reverse server)로 부터 데이터를 가져오는 역할을 함

- 여기서 프록시 서버가 Nginx, 리버스 서버가 응용프로그램 서버를 의미함

- 웹 응용프로그램 서버에 리버스 프록시(Nginx)를 두는 이유는 요청(request)에 대한 버퍼링이 있기 때문

- 클라이언트가 직접 App 서버에 직접 요청하는 경우, 프로세스 1개가 응답 대기 상태가 되어야만 함

- 따라서 프록시 서버를 둠으로써 요청을 배분하는 역할을 함

- > nginx.conf 파일에서 location 지시어를 사용하여 요청을 배분함

- Nginx 는 비동기 처리 방식(Event-Drive)방식을 채택하고 있음

a. 동기(Synchronous):A가 B에게 데이터를 요청했을 때, 이 요청에 따른 응답을 주어야만 A가 다시 작업 처리가 가능(하나의 요청, 하나의 작업에 충실)

b. 비동기(Asynchronous) : A의 요청을 B가 즉시 주지 않아도 A의 유휴시간으로 또 다른 작업 처리가 가능한 방식

 

2.2 설치 기본 세팅

 

- Nginx 서버를 소스코드 설치함으로서 얻을 수 있는 가장 중요한 이득은 커스텀 모듈을 추가할 수 있다는 점

- 기존의 표준 Nginx 기능들을 확장할 수 있다는 점

- Nginx 모듈에는 두 가지 형태가 있다.

1. 하나는 번들 모듈(bundled modules)이고

2. 다른 하나는 써드파티 모듈이다(third party module)

- 써드파티 모듈은 다른 개발자에 의해 만들어진 모듈이고 이를 사용하기 위해서는 다운로드를 받고 컴파일해야 한다. 반면, 번들 모듈은 Nginx에 포함된 모듈을 의미한다. 예를들어 --with-http__ssl_module 옵션을 주면 Nginx는 빌드를 할 때 이 모듈을 포함함