Chapter3 - CPU Bound 애플리케이션 무중단 배포(Nginx 로드밸런싱)

• 안녕하세요~ 이전에 운영하던 블로그 및 GitHub, 공부 내용을 정리하는 Study-GitHub 가 있습니다!

• 네이버 블로그

• GitHub

• Study-GitHub

• 🐔

---

✔ CLASS101 백엔드 시스템 실무 - Chapter3 CPU Bound 애플리케이션 무중단 배포

안녕하세요, 클래스101 백엔드 시스템 실무 강의를 듣고, 복습 차원으로 정리하여 남기려고 합니다! 혹시 문제가 된다면 글을 삭제하겠습니다 !!

 

class101.net/products/5fc4a3b4fc231b000d85661b

현직 대기업 개발자 푸와 함께하는 진짜 백엔드 시스템 실무!

---

 

✔ 무중단 배포를 위한 환경 이해하기

    • 무중단 + 배포 = 배포를 중단없이 진행한다는 의미

    • 배포(Deploy)란, 개발 환경에서 개발된 코드를 패키징하여 새로운 버전의 애플리케이션을 실행하는 것

 

class101.net/products/5fc4a3b4fc231b000d85661b

구 버전(v1)의 애플리케이션을 종료하고, 새로운 버전(v2)의 애플리케이션을 실행하고 클라이언트의 요청을 받을 준비가 될 때까지 서비스가 중단됩니다.

이렇게, 서비스가 중단되는 시간을 다운타임(downtime) 이라고 합니다.

 

🎗 새로운 버전(v2)를 시작하기 전에 구 버전(v1)을 내려야 하는 이유는 무엇일까요?

    • v1과 v2가 동일한 포트를 사용하기 때문입니다.

        • 한 서버에서 한 포트를 동시에 서로 다른 애플리케이션이 사용하는 것은 불가능합니다.

 

🎗 이러한 문제점을 해결하기 위해, 단순히 서버만 두 대로 늘린다면 해결이 될까요?

    • 사용자(클라이언트)는 두 서버의 IP 혹은 DNS 주소를 알아야 한다는 문제점이 있습니다.

    • 또한 어떠한 서버가 배포되는지 알 방법도 없습니다.

 

🎗 이러한 문제점을 해결하기 위해 애플리케이션 서버와 사용자 사이에 중계(Proxy)해 줄 서버가 필요합니다.

    • 애플리케이션 서버와 사용자 사이에서 요청을 중계해주는 서버를 '리버스 프록시(Reverse Proxy)' 라고 합니다.

    • 프록시는, 대리자의 뜻으로 클라이언트를 숨겨주는 역할(서버는 클라이언트의 식별이 불가능)

    • 리버스 프록시는 프록시와 반대로 서버를 숨겨주는 역할(클라이언트는 서버의 식별이 불가능)

 

 

 

class101.net/products/5fc4a3b4fc231b000d85661b

🎗 리버스 프록시로 서버를 숨기다보니, 트래픽도 분산이 가능합니다.

    • 하나의 서버에서 받아야 할 트래픽을 여러 서버로 분산이 가능합니다.

        • 이를 부하 분산(로드 밸런싱) 이라고 합니다.

        • 이러한 리버스 프록시와 로드 밸런싱을 위해 현재 가장 인기있는 웹서버가 "Nginx(엔진엑스)" 입니다.

 

 

🎗 Nginx 만으로 트래픽 처리가 모두 가능할까요?

    • Nginx도 서버 자원을 사용해서 동작하는 애플리케이션이기에 트래픽을 무한정 받아낼 수는 없습니다.

    • 다음과 같은 해결 방법을 생각할 수 있습니다.

        • Nginx가 실행되는 서버의 Scale-Up 을 할 수 있습니다.

        • 네트워크 장치(하드웨어 성능 ↑)로 로드 밸런싱(L4, L7 로드 밸런서)

        • DNS 리다이렉션

 

🎗 체크할 사항

    • 배포 성공 여부 체크

        • 배포 스크립트 자체에 포함될 수 있으나, 새로 배포된 서비스의 특정 API 요청을 했을때, 올바른 요청이 도착하

          는지 체크(Health Check)

        • 롤백을 수동으로 할지, 자동으로 할지의 여부

---

 

✔ Nginx를 통한 로드밸런싱 구성

    • 무중단 + 배포 = 배포를 중단없이 진행한다는 의미

    • 배포(Deploy)란, 개발 환경에서 개발된 코드를 패키징하여 새로운 버전의 애플리케이션을 실행하는 것

class101.net/products/5fc4a3b4fc231b000d85661b

 

 

 

 

🎗 GCP 인스턴스 복제(머신 이미지) - 로드밸런싱을 적용하기 위해 인스턴스를 여러개 생성

GCP에서 머신 이미지 > 머신 이미지 만들기를 클릭합니다.

 

 

 

이름, 소스 VM 인스턴스를 수정한 후 CREATE를 누릅니다.

 

 

 

작업의 점 > 인스턴스 만들기를 클릭합니다.

 

 

 

이름만 수정하고, 나머지는 기존의 인스턴스를 복제했으므로 동일한 설정을 가지게 됩니다.

따라서 위와 같이 수정한 후 생성합니다.

 

 

 

위와 같이 동일하게 cpu의 인스턴스를 3까지 만들어 줍니다.

 

 

 

Jenkins에서 관리 > 시스템 설정으로 들어가서 위와 같이 SSH Server을 추가해줍니다.

    • Hostname은 GCP에서 내부 IP를 적어주시면 됩니다.

 

 

 

 

Jenkins에서 GCP의 인스턴스 1,2,3 을 모두 배포해야 하기에 프로젝트 Name을 위와같이 일부 수정합니다.

 

 

 

 

그 후 프로젝트에서 구성을 클릭한 뒤, 위와 같이 GCP 인스턴스 2, 3번에 대한 SSH Server를 추가합니다.

또한 기존에 /dev/null 버렸던 로그를, 이번에는 남겨보도록 하겠습니다.

 

Exec command 명령어를 다음처럼 수정합니다.

nohup docker run -p 8080:80 docker계정/docker repo이름 > nohup.out 2>&1 &

ex) nohup docker run -p 8080:80 juhyun419/spring-boot-cpu-bound > nohup.out 2>&1 &

 

위와같이 수정한 후 저장을 하고 배포(Build Now)를 진행합니다.

 

 

 

배포를 한 뒤 로그를 보면 딱히 오류가 없는데, GCP 인스턴스의 SSH에서 nohup.out 파일을 확인해 봅니다.

 

 

 

 

instance-1

GCP에서 인스턴스-1은 위와 같이 port is already allocated 라는 오류가 발생합니다.

즉, Port가 이미 할당되었다는 오류인데요..

기존에 8080 포트를 실행중이었기에 발생하는 오류입니다.

 

 

 

또한 GCP 인스턴스-2,3 은 위와 같이 Docker demon에 연결할 수 없다고, 실행중인 상태냐고 친절하게 로그를 알려줍니다.

 

인스턴스-2,3 은 로그를 종료(Ctrl + C) 한 뒤, docker를 실행해줍니다.

$ sudo systemctl start docker

 

또한 아래 명령어를 통해 권한을 수정해줍니다.

$ sudo chmod 666 /var/run/docker.sock

 

위 과정을 끝내고 Jenkins에서 다시 배포를 해봅시다!!

 

 

 

nohup 로그를 확인해보시면, GCP 인스턴스-2,3 은 이제 정상적으로 배포가 된 걸 볼 수 있습니다 🙌 

 

 

 

 

 

🎗 Nginx GCP 인스턴스 생성하기

 

이제 Nginx 인스턴스를 생성해줍니다!!

이름은 nginx-instance-1

리전은 타이완으로 설정합니다.(서울 리전은 최대 4개가 되는데, 모두 할당했기때문)

머신 유형은 e2-medium 으로 설정합니다.

 

기타 CentOS 7, 방화벽은 HTTP, HTTPS 모두 허용은 동일하게 설정하고 인스턴스를 생성합니다.

 

 

 

 

 

🎗 GCP 인스턴스에서 Nginx 설치 & 실행하기

인스턴스 생성이 다되었으면, SSH를 접속해서 Nginx를 설치해줍니다.

$ sudo yum install nginx

 

설치가 다 끝났으면 Nginx를 실행합니다.

$ sudo systemctl start nginx

 

 

 

Nginx를 설치한 인스턴스의 외부IP로 접속해보면 위와 같은 사이트가 나옵니다. ✌

 

 

 

 

🎗 Nginx 로드밸런싱 설정

Nginx의 로드밸런싱을 설정하기 위해 위 conf 파일에 vi 모드로 실행합니다.

 

 

 

오타 조심!!! 😢

Nginx에 로드밸런싱을 설정을 합니다.

 

위와 같은 설정 파일은 Nginx의 공식 문서 를 참고하시면 됩니다.

또한 server는 GCP 인스턴스의 내부 IP를 작성하시면 됩니다.

upstream의 간단한 설명... upstream <upstream name> {     <로드밸런스 타입> - default는 라운드 로빈(들어온 순서대로 처리)     server <host1>:<port1> <option ...>     ...     server <host2>:<port2> <option ...> } weight:  로드밸런싱에 가중치를 둬서 분산시킵니다. max_conns:  최대 연결 한계를 정합니다. max_fails:  최대 실패 한계를 정합니다.(최대 실패횟수에 도달하면 서버가 죽은것으로 간주) fail_timeout:  시간 지정(이 시간을 넘어서도 응답이 없으면 서버가 죽은것으로 간주) backup:  backup 서버로, 다른 서버가 죽었을 때 동작

 

 

 

Nginx의 IP에서 /hash/123 으로 접근을 하려고 하면 현재는 로드밸런싱이 적용이 되어있지 않기 때문에,

404 에러가 발생합니다.

따라서, Nginx를 reload(restart) 한 뒤 적용합니다.

$ sudo systemctl reload nginx

 

또한 아래 설정을 지정합니다.

$ sudo setsebool -P httpd_can_network_connect on

 

 

 

 

그 후 Nginx의 서버로 접속해보면 /hash/123 URL이 정상적으로 접근이 됩니다!! 😂