오늘은 실무에서 주로 사용하는 nginx가 무엇인지? 그리고 nginx의 하는 역할 중에 하나인 LoadBalancer에 대해 실습해보도록 하겠습니다!

📌 1. Nginx란?

우선 Nginx란 고성능 웹 서버이자 리버스 프록시 서버로, 다양한 기능을 제공하는 오픈소스 소프트웨어입니다.

웹 서버 즉 WS는 인터넷에서 사용자가 웹사이트를 요청하면(브라우저에서 주소 입력) 그 요청을 받아서 HTML, 이미지, 동영상 등 웹페이지에 필요한 파일(정적 파일)들을 보내주는 프로그램을 말해요.

우리가 흔히 개발하는 서버는 WAS이고 이 앞단에서 정적인 파일에 대한 값을 반환해주는 것이 WS다 라고 이해하면 될 것 같습니다! 이 WAS의 종류는 Apache, nginx가 있는데요, 실무에서는 주로 nginx를 사용합니다! 이유는 아래와 같아요!

Apache: 각 요청을 프로세스/스레드로 처리
Nginx: 각 요청을 비동기 이벤트 방식으로 처리

위와 같은 차이점이 있기 때문에 요청이 많아지면 많아질수록 Apche는 리소스 사용량들이 많아지기 때문에 주로 실무에서는 Nginx를 많이 사용합니다!

그렇다면 Nginx의 역할을 살펴봅시다!

1) 웹 서버

위에서 언급했듯이 요청에 대해 정적파일(HTML, CSS, 이미지 등)을 반환합니다.

그러면 WAS에서는 정적파일을 처리할 수 없을까요??

정답은 처리할 수는 있습니다!

그렇지만 WAS는 동적 파일, 즉 비즈니스 로직을 실행하고 이에 대한 응답을 주는데 최적화되어있지 정적파일을 주는데 최적화 되어있지는 않아서 비효율적입니다. 그리고 동적 처리에 리소스를 집중해야되는데 정적까지 맡게된다면 자원 처리가 효율적이지 않겠죠?

따라서 앞단에 WS가 있게 된다면 정적 응답에 대해 캐시, TLS 터미네이션과 같은 WAS의 부담을 줄여줄 수 있기 때문에 WAS에서 모든 요청을 처리하지 않는 것 입니다!

2) 리버스 프록시

쉽게 말하면 "중간 관리자" 역할을 한다! 라고 이해하시면 될 것 같습니다.

요청을 WAS로 전달하기 전에 이 리버스 프록시에서는 해당 요청이 안전한지 검사도 할 수 있고, TLS 핸드쉐이크 등 보안적인 부분을 확보할 수 있습니다!

그리고 무중단 배포를 할 때 이 리버스 프록시가 필요한데요!

새로운 버전으로 서버를 교체할 때는 기존 서버가 중단되고 새 버전으로 교체되는 과정에서, 요청이 끊기거나 취소될 수밖에 없습니다. 하지만 리버스 프록시는 교체 전까지는 기존 서버로 요청을 전달하고, 교체가 완료되면 자동으로 새로운 서버로 요청을 보내도록 설정할 수 있습니다. 덕분에 사용자 입장에서는 배포 중에도 서비스가 끊기지 않고, 무중단 배포를 구현할 수 있게 됩니다.

3) 🔥 로드 밸런서 🔥

오늘 우리가 다뤄볼 주제인 로드밸런서 역할입니다!

서버가 여러 대일 때, 각 서버에 요청을 골고루 분산해 서버 과부하를 방지해줍니다! 예를 들어 서버 한 대가 장애나 과부하로 응답이 늦어지면 다른 서버로 요청을 보내는 방식을 통해 요청의 병목현상을 방지합니다!

4) 캐시 서버

자주 요청되는 응답을 메모리나 디스크에 저장하고 다시 요청이 오면 빠르게 응답해 서버 부하를 줄일 수 있습니다!

📌 2. LoadBalancer 실습

자 이제 로드 밸런서를 실습할 건데요! 우선 아래와 같은 코드가 필요합니다!

# nginx.conf
upstream nginx-test {
    server 172.17.0.1:5001;
    server 172.17.0.1:5002;
    server 172.17.0.1:5003;
}

server {
    location / {
        proxy_pass http://nginx-test;
    }
}

우선 nginx.conf 파일을 생성해서 nginx에 대한 설정을 해줘야 하는데요! 해당 설정은 요청이 들어온다면 nginx 프록시 서버에서 172.17.0.1:5001, server 172.17.0.1:5002, server 172.17.0.1:5003 세 서버 중에 요청을 보내고 응답을 받아 클라이언트에 반환한다는 설정입니다.

그리고 DockerFile을 생성해주어야 합니다!

FROM nginx:alpine
RUN rm /etc/nginx/conf.d/default.conf
COPY nginx.conf /etc/nginx/conf.d/default.conf

쉽게 말하면 nginx:alpine 기반으로 새 이미지를 만들고 기본 설정을 삭제 후 커스텀 nginx.conf로 교체해서 내가 원하는 방식으로 NGINX 서버를 동작시키는 컨테이너 이미지를 만드는 것을 의미합니다!

그리고 총 3개의 웹 서버가 필요합니다!

저는 간단히 아래와 같이 각 number를 리턴해주는 웹 서버를 만들었습니다!

from flask import Flask

app1 = Flask(__name__)


@app1.route("/")
def hello_world():
    return "Web Application [1]\n"


if __name__ == "__main__":
    app1.run(debug=True, host="0.0.0.0")

그리고 DockerFile과 requirements.txt를 아래와 같이 작성해주시면 될 것같습니다!

FROM python:3
COPY ../../requirements.txt /requirements.txt
WORKDIR /
RUN pip install -r requirements.txt
COPY ../.. /
ENTRYPOINT ["python"]
CMD ["server1.py"]

blinker==1.6.3
click==8.1.7
Flask==3.0.0

이렇게 3개의 서버를 작성해주시면 됩니다! 참고로 저는 아래와 같이 Dir 구조를 설정했으니 혹시 문제가 생기시면 참고하시길 바라겠습니다~

자 여기까지 했으면 이제 docker-compose.yml을 작성해주어야 하는데요 각 서버를 빌드 후 컨테이너를 띄우고 마지막으로 nginx 컨테이너까지 띄우는 것을 의미합니다!

version: "3"
services:
  server1:
    build: ../server1
    ports:
      - "5001:5000"

  server2:
    build: ../server2
    ports:
      - "5002:5000"

  server3:
    build: ../server3
    ports:
      - "5003:5000"

  nginx:
    build: .
    ports:
      - "8080:80"
    depends_on:
      - server1
      - server2
      - server3

자 이렇게 된다면 준비는 끝입니다!

여기서 이제 아래 Command를 입력하시면 실행이 되는 것을 볼 수 있습니다!

 docker-compose up -d

그럼 위와 같이 컨테이너가 잘 시작되는 것을 볼 수 있는데요! 또 아래 명령어로도 각 컨테이너의 상태를 확인해볼 수 있습니다!

docker compose ps

위의 사진처럼 3개의 컨테이너가 잘 사용되는 것을 볼 수 있죠?

자 그럼 테스트를 해봐야겠죠! 물론 Localhost:8080으로 접속을 해도 볼 수 있지만 저는 동시에 여러 개의 요청을 보내고 싶어서 Jmeter라는 도구를 활용해보겠습니다!

Jmeter 사용법은 이전 포스팅에서 다뤘으니 참고하시면 될 것 같습니다!

우선 설정을 아래와 같이 10개의 쓰레드가 동시에 접근하는 시나리오로 설정해줍니다!

그리고 HTTP Request를 Localhost:8080으로 설정한다음 결과를 확인해보면?

위의 사진과 같이 로드밸런싱이 아주 잘 동작하는 것을 볼 수 있습니다!! 👏👏👏

3. 마치며

실무에서 개발하다보면 비즈니스 개발만 하다보니 이런 Infra적인 부분을 놓지고 있을 때가 많은 거 같습니다! 하지만 이런 Infra 지식을 놓치고 있다보면 어느덧 비즈니스 개발에 벽을 느끼게 될 때가 많더라구요 😭😭 시간 날 때 틈틈히 우리 회사의 미들웨어가 어떻게 구성되어있는지 한번 씩 살펴보는 것도 큰 도움이 될 것 같습니다!!

그러면 이번 포스팅도 여러분께 유용한 포스팅이 되길 바라며 마치겠습니다~! 🙌 다음에는 더 좋은 포스팅을 돌아오겠습니다~~