[DevOps] NGINX란?

 

 

 

 

 

 

🚀 NGINX

    🔽  NGINX란?

        📦 개요

NGINX는 많은 기능을 수행할 수 있는 Software로 Revers Proxy, Load balancer, Cache 등을 처리할 수 있는 Software에요.

또한 NGINX는 데몬으로 동작하는데, 데몬이란 백그라운드에서 실행되는 Service에 대한 용어에요. 모든 서비스에서 실행되는 Service와 OS 시작 중에 자동으로 시작하도록 데몬을 구성할 수 있어요.

출처: https://www.nginx.com/resources/glossary/nginx

NGINX는 두개의 Process로 구동이 되요.
즉, Master Process와 Worker Process로 자동 구동이 되요.

출처 : https://nginx.org/en/docs/beginners_guide.html

출처 : https://www.youtube.com/watch?v=hA0cxENGBQQ

NGINX 처리 과정을 좀 더 살펴보면 최초 Client가 요청(Request)를 보내게 되면, NGINX Master Process가 이 요청을 받고, 어떤 작업을 처리하는 것이 아닌 바로 Worker Process에게 전달을 하게되고, Worker Process가 이를 처리하는 방식으로 구동이 되고 있어요.

{"originWidth":3038,"originHeight":142,"style":"CDM","link":" grep nginx ","caption":"ps aux --forest

728x90

💡 참고 사항
--forest: Process에 부모, 자식 간의 관계를 볼 수 있는 Option.

Master Process는 부모 Process로 실행이 되고, Woker Process는 자식 Process로 실행이 되는걸 확인할 수 있어요.

/etc/nginx/nginx.conf에서 자식 Process 개수를 늘리거나, 줄일수 있어요.

vim /etc/nginx/nginx.conf

반응형

위의 설정 File에서 두번째 줄을 보면 worker_processes가 auto로 되어 있는걸 볼 수 있는데, 이는 구동하는 PC의 CPU Core에 따라 자동으로 할당 받겠다는 의미에요. 

vim /etc/nginx/nginx.conf

위와 같이 설정하게 되면 자식 Process 즉, Worker Process를 두 개로 만들 수 있어요.

여기서 우리가 알 수 있는 건 NGINX에 관련 설정을 할 때는 nginx.conf를 건드려 주면 된다는 점이에요.

        📦 Configure File

1. 설정 파일은 /etc/nginx/nginx.conf
2. 설정 파일은 Directives(디렉티브)로 관리
   ∙ Simple(간단) 디렉티브와 Block(블록) 디렉티브로 분류
     - Block Directive
        블록(중 괄호)으로 감싸져 있으면 블록 디렉티브이고, 안 감싸져 있으면 Simple 디렉티브

출처 : https://nginx.org/en/docs/beginners_guide.html

3. 설정의 끝은 세미콜론(;)으로 마무리 및 표시

출처 : https://nginx.org/en/docs/beginners_guide.html

4. Include 이용하여 설정 파일 분리 관리

출처 : https://www.youtube.com/watch?v=hA0cxENGBQQ

NGINX 설정을 nginx.conf에만 하게 되면 많은 량에 Script 문이 들어가게 될 수도 있어요.
이러한 이유로 설정 파일을 분리해서 관리할 수 있는데, 위와 같이 include 문을 써서 해당 conf File에 위치를 지정해 주면 되요.

        📦 Server Block이란?

1. Server 기능 설정.
2. 어떤 Address:Port로 Request(요청)을 받을지 결정.

출처 : https://www.youtube.com/watch?v=hA0cxENGBQQ

위의 그림에서 처럼 Client가 NGINX에게 helloworld.com:80으로 어떤 요청을 보낼수도 있고,
example.com:81로 요청을 보낼수도 있어요.

출처 : https://www.youtube.com/watch?v=hA0cxENGBQQ

위와 같이 요청을 보낼 수 있는 이유는 각각의 Server Block을 이용해서 listen을 통해 해당 Service가 요청을 받을 Port를 지정하고, server_name을 통해 URL을 지정해 주었기 때문이에요.

위에서 server는 블록 디렉티브인데, listen, server_name은 간단 디렉티브에요. 

위의 Script를 분석해 보면 www.example.org에 80 Port로 요청이 들어오면 받겠다라는 의미에요.

💡 참고 사항
NGINX 문법 검사 요령

1. nginx -t 명령어를 통해 nginx 설정 파일 안에 Script문이 문법에 맞게 작성 되었는지 확인 가능.

출처 : https://www.youtube.com/watch?v=hA0cxENGBQQ

출처 : https://www.youtube.com/watch?v=hA0cxENGBQQ

 

 

 

 

        📦 Http Block이란?

1. http Protocol 사용

출처 : https://www.youtube.com/watch?v=hA0cxENGBQQ

위에서 Script File은 Server Block 밖에 없었지만, nginx.conf File을 보게 되면 http {}로 http Block이 있고, 그 안에 include를 하여 다른 conf File을 포함하게 되어 있어요.

그렇기 때문에 http Block을 생략하더라도 이미 전역적으로 포함이 되어 있다는 의미가 되요.

        📦 Location Block이란?

1. 요청 URI를 분석하여 세부 설정

출처 : https://www.youtube.com/watch?v=hA0cxENGBQQ

위의 그림과 같이 /(root)와 /documents, /images에 대한 URI를 따로 설정하고, 각각의 URI가 호출 되었을 때, 어떤 처리를 할 것인지를 정할 수 있어요.

Server Block 안에 Location Block을 넣고, 거기서 URI 별 설정을 하면 되요.

출처 : https://www.youtube.com/watch?v=hA0cxENGBQQ

위와 같이 각각의 URI를 호출했을 때, 특정 문자열이 반환되도록 할 수 있어요.

출처 : https://www.youtube.com/watch?v=hA0cxENGBQQ

위와 같이 HTTP Status Code와 함께 문자열이 반환되도록 처리를 해주었어요.

하지만, 위와 같이 설정하게 되면 한 가지 문제점이 발생하는 것이에요.

예를 들어 /a/aaa 라는 하위 URI 추가로 있어 이에 대한 설정을 하더라도 /a에 대한 설정이 먹어버려 원하는 작업이 처리되지 않는 문제에요.

즉, Prefix만 맞게 되면 뒤에 추가 URI 문자열이 있더라도 해당 Prefix에 설정한 작업이 진행되게 된다는 것이에요.

출처 : http://nginx.org/en/docs/beginners_guide.html

위 내용은 NGINX 공식 문서에도 언급이 되어 있어요.

이를 해결하기 위해서는 Prefix Match가 아닌 Exact Match 방식으로 변경을 해주어야 해요.

출처 : http://nginx.org/en/docs/beginners_guide.html

즉, 조건 검사를 하는 부분이 추가되어야 한다는 것이에요.

출처 : https://www.youtube.com/watch?v=hA0cxENGBQQ

위와 같이 URI를 설정하는 location Block에 '='을 붙혀주면 해결 된답니다.
이건 그냥 기본적으로 써야 할 것 같아요.

        📦 File Return

1. 문자열이 아닌 File을 반환(html, png, 등)

출처 : https://www.youtube.com/watch?v=hA0cxENGBQQ

위에서 문자열을 반환할 때와 차이점은 root 디렉티브를 이용해서 반환하고자 하는 File이 위치한 경로를 적어줘야 하는 것이에요.

해당 경로에 File이 있다면 그 File을 반환하게 되고, 만약 File이 없다면 NGINX 설정에 따른 값을 반환하게 되는데, 대표적으로 404 Not Found Error를 반환할 수 있어요.

현재 /tmp/images 라는 Directory가 있고, 그 안에 a라는 File이 들어가게 설정이 되어 있어요.

이 때, NGINX 설정 File에는 Prefix URI인 /tmp를 root 디렉티브에 적어주고, 하위 위치값을 location 디렉티브에 적어줘야해요.

# case1 : 정규식(대소문 구분 하지 않음)
# 준비 :
mkdir -p /tmp/images
touch /tmp/images/a.jpg
curl helloword.com:82/images/a.jpg
curl helloworld.com:82/a.jpg

 

server {
	listen *:82;
    
    location = / {
    	return 200 "helloworld";
    }
        
    location /images {
    	root /tmp;
        try_files $uri = 404;
    }
}

 

 

 

        📦 Reverse Proxy란?

Proxy를 먼저 간단하게 이야기하자면 A, B, C라는 사람이 있는데, A와 C가 싸운거에요.
둘은 화해는 하고 싶지만, 자존심이 강해서 직접 이야기 하고 싶지는 않았어요.

A는 B에게 이렇게 말했어요. "C한테 배고픈데, 배 안 고프냐고 물어봐줘"
B는 C에게 전달을 했어요.

그러자 C가 B에게 "배 고픈데, 뭐 먹을건지 A에게 물어봐줘"라고 이야기 했어요.
B는 A에게 전달 했어요.

이 때, B가 바로 Proxy 역할을 해 준 것이고, 중계 Server를 Proxy Server라고 해요.

Proxy에는 크게 두가지로 나눌 수 있어요.

1. Forward Proxy (순방향 프록시)

회사의 내부망에 물려 있는 PC나, Server들이 인터넷에 접속할 때, 가장 먼저 Proxy Server를 거친 뒤 인터넷으로 나가게 되는 연결 방식을 이야기해요.

순방향 프록시는 두가지 장점이 존재해요.

  ∙ 보안 : Proxy Server에서 In / Out Bound Packe에 대한 보안 정책 (Content Filering 등)을 적용.
  ∙ 성능 : Proxy Server는 내부에 Cache를 유지하며, 이미 한번 통신한 외부 Server의 Image, File, 그 외 정보들을
                 저장할 수 있으며, 내부 사용자가 원격 서버 접속 시 Cache에 Data가 있으면 물리적으로 먼 곳까지 갈 필요없이
                 Proxy Server가 Data를 제공하여 빠른 통신 가능.

 

출처 : https://medium.com/sjk5766/nginx-reverse-proxy-%EC%82%AC%EC%9A%A9%ED%95%98%EA%B8%B0-e11e18fcf843

2. Reverse Proxy (역방향 프록시)

회사를 기준으로 회사 외부에서 내부 Server가 제공하는 Service 접근을 하려 할 때, Proxy Server를 먼저 거친 뒤 내부 Server로 들어오게 하는 방식이에요.

역방향 프록시를 사용함으로 얻을 수 있는 장점 또한, 세 가지가 있어요.


  ∙ 보안 : 외부 이용자는 실제 내부망에 있는 Server에 존재를 알 수 없으며, 모든 접속은 Reverse Proxy Server에
     들어오게 된다. Reverse Proxy는 요청에 Mapping 되는 내부 Server의 정보를 알고 있으므로, 외부에서 들어온
     요청을 해당 Server에게 전달하게 된다. 따라서 내부 Server의 정보를 외부로부터 숨길 수 있다.

  ∙ 로드밸런싱 : Proxy Server가 내부 Server 정보를 알고 있기 때문에 로드밸런싱을 통해 부하 여부에 따라 요청
      분배하는 부하 분산을 할 수 있다.

     - Scale Up : Server 성능 높이기 (비용도 대칭으로 올라감)
     - Scale Out : 여러 대의 Server를 두어 트래픽 분산 (물리 / 논리적으로)

  ∙ 성능 : Proxy Server가 Cache 기능과 트래픽 분산 기능을 결합시켜 전반적인 Server 성능 향상을 이끌 수 있다.

출처 : https://medium.com/sjk5766/nginx-reverse-proxy-%EC%82%AC%EC%9A%A9%ED%95%98%EA%B8%B0-e11e18fcf843

 

 

        📦 Load Balancing이란?

Service 중인 Server가 갑자기 죽거나, Network 장애등 Service를 할 수 없는 상황이 생겨 버린다면 1대의 Server로만 운영중일 때, 해당 Service는 운영 불가 상태를 맞이하게 되요.

이를 막기 위해 여러대의 Server를 Master / Slave 혹은 Master / Master 등으로 구성하고, 장애 대비를 해두게 되는데,
이를 Fail Over 즉, 장애 대비라고 해요.

하드웨어적으로 로드밸런싱을 할 수도 있는데, 대체로 L4 Switch라는 장비를 이용해서 로드밸런싱을 구성할 수 있어요.

출처 : https://velog.io/@kimjiwonpg98/Nginx-%EB%A1%9C%EB%93%9C%EB%B0%B8%EB%9F%B0%EC%8B%B1-%EA%B0%9C%EB%85%90-%EB%B0%8F-%EA%B5%AC%EC%B6%95

1. OSI 7 Layer의 Network Layer (4계층) 위치.
2. TCP / UDP Port 정보를 바탕으로 Network 통신.
3. Data 안을 보지 않고, Packet Level에서 작업.
   ∙ 속도가 빠르고, 효율이 높다.
   ∙ Data 내용을 부호화하지 않아 안전.
   ∙ L7 Switch 보다 저렴.
4. 사용자 IP가 수시로 바뀌는 경우 연속적 Service 제공 어렵다.


L7 Switch로도 로드밸런싱을 구성할 수 있어요.

출처 : https://velog.io/@kimjiwonpg98/Nginx-%EB%A1%9C%EB%93%9C%EB%B0%B8%EB%9F%B0%EC%8B%B1-%EA%B0%9C%EB%85%90-%EB%B0%8F-%EA%B5%AC%EC%B6%95

1. OSI 7 Layer의 Network Layer (7계층) 위치.
2. TCP / UDP와 HTTP URI, FTP File Name, Cookie 정보 등을 바탕으로 작업.
3. Caching 기능 제공.
4. 섬세한 Routing 가능.
5. 비 정상적 트래픽 사전 Filtering (안전성 향상)
6. 너무너무 비싸다.


그럼 이제 우리가 써보려고 하는 Software 로드밸런싱에 대해 알아볼게요.

소프트웨어 로드밸런싱은 기본적으로 Reverse Proxy 기반으로 동작해요.

이는 로드밸런싱만을 위해 개발된 프로그램이 아니기 때문에 기본적인 로드밸런싱의 기능만이 있지만, 그만큼 비용이 저렴하고, 구축이 쉽다는 장점을 가지고 있어요.

소프트웨어 로드밸런싱을 할 수 있는 소프트 웨어는 대표적으로 두 가지가 있어요.

1. NGINX
   ∙ Open Source.
   ∙ 특정 알고리즘은 NGINX Plus에서만 사용 가능.

2. HA Proxy
   ∙ Open Source.
   ∙ 여러 로드밸런싱 기능 지원.


이러한 점 때문에 NGINX를 사용한답니다.