2024.09.27.금.TIL NginX

김기남·2024년 9월 26일

안녕하세요, 오늘은 NginX 에 대해 정리해보았습니다.

APACHE SERVER

💡 아파치는 오픈 소스 웹 서버중 하나이다. 다양한 운영 체제에서 동작하며 **안정성, 확장성, 모듈화**로 널리 사용된다. SSL, 가상 호스팅 등 기능 제공으로 **웹 호스팅에 적합하며, 로드 밸런싱, 보안 기능**도 갖추고 있습니다.

키워드에 대해서는 아래 본문에서 다루겠습니다.

Apache server VS NginX

Apache에 비하면 NginX는 비교적 최신기술이지만 오래된 기술중 하나이다.
NginX 현재 Web Server 분야에서 점유율 1등이다.
이제부터 왜 NginX가 1등을 차지하고 있는지에 대해서 알아보자.

NCSA HTTPd

1995년 당시 유닉스 기반의 최초의 웹서버 NCSA HTTPd 사용
하지만, 기존의 HTTPd는 각종 버그를 내포하고 있었다.

이에 불편함을 겪은 개발자들은 버그를 직접 수정하기 시작했고 새롭게 만들어진것이 Apache Server 이다.
NCSA HTTPd 공식 홈페이지

The NCSA HTTPd Home Page

APACHE SERVER의 구조

💡 Apache Server는 Web Server이다. 즉, Web 통신 방법인 HTTP를 사용한다.

Client로부터 Apache Server에 Request가 들어오면?

Request가 들어오면 Connection을 위해 Process를 생성한다.
새로운 요청이 들어올 때 마다 새로운 프로세스를 만든다.
- (UNIX계열 OS가 Network Connection을 형성하는 모델을 그대로 적용)

PREFORK 방식
- Process를 생성하는것은 무거운 작업이다.
- 미리 Process를 만들어놓는 PREFORK 방식 사용.
- 만약, 만들어진 Process가 모두 할당되면 추가 생성
확장성
- 위와같은 Apacher Server의 구조는 개발하기 쉽다는 장점이 있다.
- 개발자는 다양한 모듈을 만들어서 서버에 빠르게 기능을 추가할 수 있다.
- 즉, 확장성을 가지고 있다.
- Apache Server는 동적 컨텐츠까지 처리할 수 있게 되었다.
- 확장성 덕분에 Request, Response 모든 과정을 하나의 서버에서 처리할 수 있게 되었다.
Apache Server가 인기를 얻은 비결.
Apacher Server는 출시된지 1년도 되지 않은 시점에 세계 점유율 1위의 Server가 되었다.

1999년

💡 1999년은 Internet Traffic이 지속적으로 증가하는 상황에 놓였다. 점점 Traffic이 증가함에 따라서 기존 Server는 감당하지 못하기 시작했고 Server에 문제가 발생하기 시작한다.

C10K

서버에 동시에 연결된 커넥션이 많아졌을 때 더이상 커넥션을 생성하지 못하는 문제 발생
이것을 C10K 라고한다.(커넥션 10000개의 문제)
바로 이 C10K 가 이번 수업의 핵심 내용이다.

동시 연결 커넥션 수

💡 요청을 처리하기 위해 Server가 한 시점에 얼마나 많은 커넥션을 형성하고 있는가를 의미한다. 하나의 클라이언트는 하나의 커넥션으로 여러 요청을 보낼 수 있다. 즉, 커넥션은 긴 시간동안 유지될 수 있다.

Http Header : Keep-Alive

Connection을 형성하려면 많은 절차가 필요하다.
각 요청마다 매번 Connection을 만들기엔 매우 비효율적
이미 만들어진 Connection이 있다면 재사용
Http Header Keep-Alive 에 적힌 시간만큼 한번 형성한 Connection을 유지한다.

10000단위 이상의 Connection

클라이언트 수가 많아지면 그만큼 동시에 연결되어 있는 커넥션 수는 많아진다.
10000 단위가 넘어가는 순간 Server는 Connection을 형성하지 못하게된다.

문제점

C10K 문제는 하드웨어 문제가 아니다.
- 발전 속도가 아주 빠른 상황
- 컴퓨터의 성능은 Web에 비해 충분히 좋았다.
문제는 Web SERVER의 구조(점유율 1위인 Apache Server 포함)
- Connection이 많아지면 형성되는 Process가 많아진다.
- Traffic이 증가함에 따라 메모리 부족 현상이 발생한다.
Apache Server가 장점으로 가지고있던 확장성은 Process가 차지하는 리소스의 양을 늘리게됨
많은 Connection에서 요청이 들어오면 CPU는 컨텍스트 스위칭을 하며 프로세스를 바꾸며 일한다.
- 즉, 부하가 발생한다.
- 컨텍스트 스위칭

정리하자면 많은 동시 커넥션을 감당하고자 한다면 Apache Server는 적합하지 않다.
Apache Server는 이러한 문제를 해결하고자 꾸준히 성능 개선이 이루어지고 있다.

하지만, 이 시기부터 새로 만들어진 서버들은 기존의 Web Server와 다른 구조를 채택하였다.

2004년

💡 Apache Server를 보완하기 위한 소프트웨어인 Nginx가 등장한 년도 기존의 Server들과는 다른 구조를 채택하였다.

초창기 NGINX는 APACHE SERVER와 함께 사용하기 위해 만들어 졌다.
웹서버이지만 Apache Server를 대체할 목적은 아니였다.
기존의 Web Server가 지닌 구조적 한계를 NginX를 사용함으로써 극복하고자 했다.

NginX

Apache Server 앞쪽에 NginX를 위치시킨다.
- 많은 동시 커넥션을 유지하지 못하는 Apache Server 대신 NginX가 동시 커넥션을 유지할 수 있다.
- 즉, NginX로 Apache Server의 부하를 줄일 수 있게되었다.
NginX 또한 Web Server이다.
- 즉, 정적 리소스에 대한 요청은 스스로 처리할 수 있다.

동적 파일에 대한 요청

동적 파일요청을 받았을 경우에만 Apache Server와 Connection을 형성한다.
- 아파치 서버의 리소스를 커넥션 유지에 사용하지 않는다.
- Apache Server의 리소스는 개발자가 원하는 로직처리에 사용되도록 만들어준다.
NginX는 어떤 구조를 채택하여서 수많은 동시 커넥션을 유지할 수 있을까?

NginX 구조

💡 NginX와 Apache Server는 **만들어지는 프로세스 수**에 대한 차이가 있다.

Master Process 와 Worker Process

Master Process
- 설정 파일을 읽어들여 그에 맞는 Worker Process를 생성하는 Process
Worker Process
- 실제로 일(Work)을하는 Process
- 생성될 때 Listen Socket을 배정받는다.
- 궁금한 분들은 Web Socket 이 무엇인가?

Listen Socket

Request가 NginX로 들어온 후
Worker Process가 배정받은 Listen Socket에 Request가 전달된다.
- Connectioon을 형성하고 Request를 처리한다.
- Keep-Alive 시간만큼 Connection을 유지한다.
Worker Process에 Connection이 형성되어있다고 해서 하나의 Connection만 담당하지 않는다.
1. 형성된 Connection에 요청이 없다면 새로운 Connection을 형성할 수 있다.
2. 이미 만들어진 Connection으로부터 Request를 처리할 수 있다.

Event

💡 NginX에서는 1. Connection 형성 2. Connection 제거 3. 새로운 Request 처리 하는것을 **Event**라고 한다.

OS 커널

이벤트들은 OS커널이 Que 형식으로 Worker Process에게 전달한다.
- 이벤트는 Que에담긴 상태에서 Worker Process가 처리할 때 까지 비동기 방식으로 대기한다.
- Worker Process는 하나의 Thread로 Event를 꺼내서 처리한다.
  - Worker Process가 쉬지않고 일을할 수 있다.
  - 요청이 없다면 대기하던 Apace Server의 Process보다 리소스를 효율적으로 사용한다.
  - 멀티플렉싱, epoll
만약 Que에 쌓인 Event중 하나의 작업처리 시간이 오래 걸린다면?
- 뒤쪽에 위치한 Event는 Blocking된다.
- 시간이 오래 걸리는 작업은 어떻게 처리하는가?

Thread Pool

NginX는 오래걸리는 작업을 수행하기 위해 Thread Pool을 만들어 놓는다.

Woker Process는 요청의 처리시간이 오래걸릴것 같다면 Thread Pool의 Thread에 요청을 위임한다.
이후 Worker Process는 Que안에 있는 다른 Event를 처리한다.

Worker Process의 개수

Worker Process는 CPU의 Core 개수만큼 생성한다.
- Core가 담당하는 Process를 바꾸는 횟수를 최소화할 수 있다.
- 즉, CPU의 Context Switching 사용을 줄인다.

정리

엔진엑스는 Event Driven Model 을 채택했다. (이벤트 기반 구조)
Apache Server와의 가장 큰 차이점이 바로 위와같은 구조

NginX 단점

NginX에 기능 추가를 시도하는 경우
1. 정상적으로 동작하던 Worker Process가 종료되는 상황이 발생한다.
2. Worker Process가 관리하고 있던 Connection 및 관련 요청들을 처리할 수 없게된다.
NginX는 직접 모듈을 만들어 확장하기 까다롭다.
1. 그럼에도 장점이 너무 좋다.

NginX 장점

Apache Server 대비 동시 Connection 양의 증가
1. 대략 10~ 1000배 증가
수많은 동시 Connection을 빠르게 처리한다.
1. 그럼에도 Process를 적게 만든다. 즉, 가볍다.
2. 이벤트 기반 구조로 동일한 커넥션 수일 때 처리속도 증가

Process를 적게 만드는 NginX의 구조는 설정을 동적으로 변경할 수 있게 만들었다.
1. 설정 파일을 변경하고 NginX에 해당 설정을 적용한다면
2. Master Process 는 그 설정에 맞는 워커 프로세스를 따로 생성한다.
3. 기존에 있는 Worker Process 가 더이상 커넥션을 형성하지 않도록 한다.
4. 기존 Old Worker Process가 담당하던 작업이 종료되면 Old Woker Process를 종료한다.

리버스 프록시

💡 클라이언트의 요청을 대신 받아 적절한 서버로 전달(로드 밸런싱)하고, 서버에서 받은 응답을 클라이언트에게 반환하는 중간 서버를 **리버스 프록시 서버**라고 한다.

NginX의 동적 설정변경

NginX 부하분산 알고리즘 Default 라운드로빈,
서버 확장 Scale Out, Scale Up

NginX가 여러 동시 Connection을 관리하는 도중에 Server가 추가된다면?
- NginX는 수많은 Connection을 관리하고 있기 때문에 설정을 바꾸기위해 서버를 종료하기 어렵다.
- 동시 Connection을 유지한채, 기존 요청을 처리하며 뒷단에 서버를 추가할 수 있다.
- 이러한 동적 설정변경을 초당 수십번을 해도 안정하게 서버가 유지된다.
  - Event 기반 구조이기 때문에 가능한 방식!
NginX는 로드 밸런서의 역할을 수행한다.
- 여러 서버로 요청을 분산하는 역할을 수행
이 모든것은 NginX가 이벤트 기반 구조이기 때문에 가능한 일이다.

2008년

💡 수많은 장점들에도 불구하고 NginX의 점유율은 그리 높지 않았다. 2007년 까지만해도 Apache는 여전히 점유율 1위 자리를 놓치지 않았고 Nginx는 순위권에도 없었다.

하지만 2008년이 되며 Apache Server의 점유율은 서서히 내려오고 NginX가 빠르게 올라오기 시작했다.

NginX의 시대

2008년 - 스마트폰 상용화의 시대
스마트폰은 사람들이 인터넷을 더 많이 사용하게 만들었다.
- 즉, 동시 커넥션을 훨씬 더 많이 생성하게 되는 계기
사람들은 Youtube와 같이 다양한 정보를 실시간으로 받아보고 싶었다.
웹에 담기는 컨텐츠가 다양해지고 그 용량이 커지게 되었다.
브라우저는 리소스를 빠르게 가져오기 위해 여러 TCP Connection을 동시에 형성하기 시작
- 각각의 커넥션이 Keep-Alive 설정으로 유지됨
결국 동시 커넥션 문제를 처리해야 할 서버가 점점 늘어나게 되었다.

자연스럽게 회사들은 NginX를 찾게 되었고, 특히 대기업에서 각광받게 되었다.
스마트폰의 등장 이후 NginX의 수요는 점점 증가하게 되었다.

Apache MPM

이러한 시대에 맞게 Apache 진영에서도 MPM이란 모듈을 추가하여 성능을 개선한다.
MPM은 Apache Server를 어떤 방식으로 운영할지 선택할 수 있게 만들어주는 모듈이다.
1. 안정성, 하위호환이 필요한 경우 : 기존의 PreFork 방식 선택
2. 성능 향상이 필요한 경우 : 새로운 Worker라는 이름의 Thread를 만들어 처리하는 방식 선택

이러한 Apache 진영의 노력에도 아직까지 성능테스트(동시 커넥션 수당 메모리 사용률
와 처리하는 초당 요청의 수) 결과 NginX가 월등히 앞서있다.
NginX가 얼마나 동시 Connection 관리를 잘 하는지 알 수 있는 부분이다.

Apache Server와 NginX가 1, 2위를 다투는 이유

Apache Server는 오랜기간 업데이트를 통해 다양한 OS에서 안정적이라는 장점이 있다.
- 수많은 버그 수정이 이루어졌다.
NginX는 다양한 장점들이 있지만, Window에서 제대로된 성능을 발휘하지 못한다.
- Window컴퓨터 가진분들도 NginX 를 Docker 에서 실행하면 된다.
NginX는 기능 확장이 어렵다. 하지만 Apache Server는 쉽다.
- Apache Server로 잘 동작한다면 굳이 옮길 필요가 없다.
- 확장을 위한 모듈의 종류는 Apache Server가 훨씬 많다.

정리

Apache Server 사용 : 호환성, 안전성, 확장성
NginX 사용 : 동시 Connection 문제 (대용량 트래픽에 대비)

위 내용을 통해 어떤 서버를 선택해야하는지에 도움이 되셨길 바랍니다.

NginX를 어떻게 사용해야 하는가?

💡 위 본문 내용에서 NginX를 웹서버, 로드 밸런서로 활용하는것을 보았다. NginX는 어떻게 사용하는것인가?

NginX는 동시 Connection을 여러개 유지할 수 있다.
자원을 효율적으로 사용하여 가볍다.
추가 사용방법

SSL 터미네이션으로 웹서버 가속기 역할을 한다.
캐싱

SSL 터미네이션

💡 NginX가 클라이언트와는 HTTPS통신을 하고 서버와는 HTTP통신을 하는것을 말한다.

위 그림과같은 구조를 만들어서 서버가 보안과 관련된 복호화 과정을 담당하지 않도록 할 수 있다.
- 비지니스 로직 처리에 리소스를 사용할 수 있도록 부하를 줄여준다.
일반적으로 NginX와 Server는 같은 네트워크 안에서 존재한다.
- (NginX와 Server의 거리가 가깝다)
- 둘은 http 통신을 하여도 보안적인 위험이 적다.

캐싱

💡 NginX는 HTTP 프로토콜을 사용하여 전달하는 컨텐츠를 캐싱할 수 있다.

캐싱을 하는 경우에는 NginX를 Client 쪽에 가깝게 배치한다.
Server로 부터 받은 Response를 보관(캐싱)하고
동일한 요청이 오면 캐싱된 Response를 Client에 전달한다.
NginX 공식 홈페이지

Advanced Load Balancer, Web Server, & Reverse Proxy - NGINX

NginX의 다양한 역할

NginX는 위와같은 예시들 외에도 다양한 역할로 Server를 도와준다.
1. HSTS (HTTP Strict Transport Security)
2. CORS 처리
  
  Cross-Origin Resource Sharing (CORS) - HTTP | MDN
3. TCP/UDP Connection 부하 분산
4. HTTP/2 지원
  
  HTTP/2 프로토콜 NGINX 적용하기

엔진엑스 설정 템플릿

https://github.com/h5bp/server-configs-nginx

nginx 입문용 자료

💡현역 개발자들이 모은 NginX 설정 템플릿 모음이다. 일반적으로 사용할 때 해당 템플릿을 사용하면 매우 유용하다. 단, 제대로된 아키텍처를 위해서라면 실제로 튜닝되어야한다.

오늘의 코드카타

class Solution {

    public int solution(int[] arr) {
        int answer = 0;
        boolean bool = true;
        while (bool) {
            answer++;
            bool = false;
            for (int i = 0; i < arr.length; i++) {
                if (arr[i] >= 50 && arr[i] % 2 == 0) {
                    arr[i] /= 2;
                    bool = true;
                } else if (arr[i] < 50 && arr[i] % 2 != 0) {
                    arr[i] = arr[i] * 2 + 1;
                    bool = true;
                }
            }
        }
        return answer - 1;
    }
}

public class Main {

    public static void main(String[] args) {

        Solution solution = new Solution();

        System.out.println(solution.solution(new int[]{1, 2, 3, 100, 99, 98}));
    }
}

조건에 맞게 수열 변환하기

김기남

새로운 시작~!

이전 포스트

2024.09.26.목.TIL Docker

다음 포스트