Nginx 로드밸런싱 환경 구성하기

LJH·2021년 6월 11일
10

DevOps 강의 (feat. Foo)

목록 보기
8/16

해당 내용은 Class101의 현직 대기업 개발자 푸와 함께하는 진짜 백엔드 시스템 실무! 강의를 기반으로 작성했습니다.

무중단 배포 환경에 대해 잘 모든다면 이전 글을 참고해주세요.

😀 목표

위 그림과 같이 Nginx로 로드밸런싱하여 무중단으로 배포 할 수 있는 환경 구성하기


1. 인스턴스 추가 생성

  • 로드 밸런싱을 위해 추가로 두 개의 인스턴스를 생성하자.
    하나하나 일일이 생성해도 되지만, gcp는 인스턴스를 복제할 수 있는 기능을 제공한다.
    (여러 클라우드 서비스에서 공통적으로 제공하는 기능이다.)

1-1. 머신 이미지 생성

  • 기본설정 그대로하고 소스 VM 인스턴스만 잘 확인하면된다.
    복제할 인스턴스를 선택해주면 된다.

1-2. 머신 이미지로 인스턴스 생성

  • 인스턴스 만들기를 클릭하면 인스턴스 생성 화면이 나온다.

  • 복제하고 싶은 인스턴스의 설정이 그대로 되어있다.

  • 여기서 이름과 리전만 변경해주면 된다.

1-3 젠킨스 인스턴스 실행 및 접속

  • 강의에서는 젠킨스 인스턴스에 관해 성능향상 경고가 나와서
    머신을 e2-micro → e2-small로 변경한다.

  • 하지만 내 화면에서는 인스턴스를 종료하라는 경고가 나온다.

  • 수동으로 인스턴스 머신 사양을 수정하려했으나 어차피 300달러 크레딧이면 충분할테니
    그냥 진행한다. 수정하고 싶다면 공식 레퍼런스를 참고하자.

  • 젠킨스 인스턴스에 접속하려 했는데 접근이 되지않아 인스턴스를 재시작하고
    젠킨스 서버를 다시 구동시켜준다.

    sudo systemctl start jenkins
  • 젠킨스 인스턴스에 접속이 된다.

2. 젠킨스로 배포 설정

  • 새로 생성한 2번 3번 인스턴스도, 지난번에 진행한 젠킨스를 이용한 배포 자동화를 해보자.

2-1. 서버 설정

  • 지난번에 설정한 인스턴스와 같이 서버 설정을 추가한다.

  • Name, Hostname(내부IP)만 변경해주면된다.

2-2. 젠킨스의 공개키 복사

  • 젠킨스 인스턴스만 워커 인스턴스에 접근 가능해야한다.
    따라서 젠킨스의 공개키를 각 인스턴스에 추가해줘야한다.

  • 이전에 1번 워커 인스턴스에서 진행했었는데 Test Configuration 결과 키가 사라졌다.
    1번 ~ 3번 모두 공개키를 추가해주자.

  • 권한도 변경해줘야 한다.

그러나 이 키는 매일 초기화 되기 때문에 공개키를 복사하는 과정을 매일 수행해줘야한다.
지금은 인스턴스가 3개이지만 스케일 아웃으로 엄청나게 늘어난다면..?

그래서 gcp에서는 ssh 키를 따로 관리하는 곳이 존재한다. 아래에서 살펴보자.

2-3. GCP 메타데이터에 SSH키 등록하기

  • 좌측에 메타데이터 설정 → SSH 키 → 수정 버튼 클릭

  • 아래 항목 추가 버튼을 누르고 젠킨스의 공개키(id_rsa.pub)를 넣어주면 된다.

이렇게 설정 해주면 앞으로 생성되는 모든 인스턴스 + 현재 생성된 인스턴스의 authorized_keys 항목에 젠킨스의 공개키가 항상 들어가서 배포를 따로 설정해주지 않아도
알아서 SSH로 접속 할 준비가 되어있는 상태가 된다.

  • Test Configuration 결과를 보면 성공한 걸 확인 할 수 있다. 저장을 누르자.

2-4. 젠킨스로 각 인스턴스에 애플리케이션 실행 & 로그 남기기

  • 지난번에 만든 deploy를 재사용하기 위해 이름을 cpu-worker-instance deploy로 변경한다.

  • 대시보드에서 좌측에 구성 버튼을 클릭하고 Add Server를 클릭해 2,3 인스턴스도 추가한다.

  • Exec Command는 1번 인스턴스와 똑같이 복사한다.

  • 명령어에서 /dev/null은 로그를 휴지통으로 보내고 있는거와 같다.

  • /dev/null → nohup.out 으로 변경 (1,2,3 워커 인스턴스 동일) 후 저장

  • 빌드하고 콘솔을 확인해보면 별 이상이 없다. 하지만 워커 인스턴스에서 로그를 찍어보면 다르다.

  • 1번 인스턴스에는 이미 8080 포트로 실행중인 애플리케이션이 있다는 로그가 찍혀있다.
    (지난번에 8080포트로 이미 애플리케이션을 띄워놨기 때문이다.)

  • 2,3번은 도커 데몬이 실행중이지 않다는 로그가 찍혀있다.

  • 2,3번 워커 인스턴스에서 도커를 실행시켜준다.

  • 이대로하면 저번에 삽질했던 것 처럼 권한 에러가 날것이다. 권한도 같이 추가하자

sudo systemctl start docker
sudo chmod 666 /var/run/docker.sock

  • 다시 젠킨스로 빌드해보면 이번엔 2,3번 인스턴스도 정상적으로 애플리케이션이 실행됬다.
    (1번은 이미 실행되어 있다.)

3. Nginx 인스턴스 세팅

3-1. 인스턴스 생성

  • 서울 리전은 총 4개의 인스턴스밖에 생성 못하기 때문에 타이완으로 선택했다.

  • 워커 인스턴스와는 다르게 머신을 미디움으로 선택했다.

  • 부팅 디스크 → CentOS7 , 방화벽 체크

3-2. 인스턴스에 Nginx 설치 및 확인

  • nginx를 설치한다.
sudo yum install nginx

  • 설치 후 nginx를 실행시키고 nginx 외부 ip로 접속하면 위와 같은 화면이 나온다.
sudo systemctl start nginx

3-3. 로드밸런싱 설정

  • nignx.conf 파일에 코드를 추가해주면 된다.
upstream cpu-bound-app {
  server {instance_1번의내부_ip}:8080 weight=100 max_fails=3 fail_timeout=3s;
  server {instance_2번의내부_ip}:8080 weight=100 max_fails=3 fail_timeout=3s;
  server {instance_3번의내부_ip}:8080 weight=100 max_fails=3 fail_timeout=3s;
}
location / {
  proxy_pass http://cpu-bound-app;
  proxy_http_version 1.1;
  proxy_set_header Upgrade $http_upgrade;
  proxy_set_header Connection 'upgrade';
  proxy_set_header Host $host;
  proxy_cache_bypass $http_upgrade;
}
  • 외부ip가 아닌 내부 ip를 적어야 한다는 점 조심하고 자세한 내용은 공식 레퍼런스 참고하자.

3-4. nginx 리로드

sudo systemctl reload nginx
  • 위 명령어를 입력하면 리로드 된다.

3-5. reload와 restart 차이

  • 현재 nginx.conf 파일의 수정한 내용을 반영하기 위해 reload 명령어를 사용했다.

  • 이와 비슷한 동작을 하는 restart 명령어가 있는데 무슨차이가 있을까?

  • reload

    • 프로세스를 종료하지 않고 해당 서비스의 설정 파일들을 다시 로딩

    • 서비스에 따라 configuration 파일을 리로드하도록 설정하지 않은 경우가 있다.
      따라서 변경한 설정이 적용되지 않을 수 있다는 의미이다. 굉장한 삽질 포인트이다.
      아무리 리로드해도 변경한 설정이 적용되지 않는다면 restart를 해보자.

  • restart

    • 서비스를 종료 후 재시작한다. PID가 변경된다.

    • 서비스가 종료 후 재시작 되기 때문에 configuration 파일 등을 무조건 새로 가져와서 실행시키므로 변경사항이 무조건 반영된다.

3-6. 로드밸런싱 동작 확인

  • 이후 nginx에 /hash/123 경로로 url을 입력하면 404 에러가 나온다.

  • 에러 로그를 확인해보자.

sudo tail -f /var/log/nginx/error.log
  • Nginx에서 네트워크 자원을 엑세스 하지 못해서 발생하는 오류이다.

  • rule을 추가해줘야 Nginx에서 tomcat으로의 네트워크 접근이 가능해진다.

sudo setsebool -P httpd_can_network_connect on
  • -P 옵션을 주게 되면 리눅스 설정 파일에 반영되어 리부팅 후에도 설정 값이 사라지지 않는다.

  • 다시 요청해보면 정상적으로 응답이 온걸 확인할 수 있다.

  • Nginx 인스턴스에 요청을 날렸는데 워커 인스턴스에 있는 애플리케이션의 응답이 오는
    신기한 경험을 할 수 있다!


4. 마치며

  • 이번에 한 내용을 간단히 정리하면
  1. 머신 이미지를 통한 인스턴스 복제

  2. 추가한 인스턴스들도 젠킨스로 배포 자동화 설정

  3. Gcp 인스턴스 생성 -> Nginx 설치 -> 로드밸런싱 설정

다음에는 지금까지 설정한 로드밸런싱 환경을 기반으로 스트레스 테스트를 진행해 보자.
이번 글에서 사용한 명령어 모음

0개의 댓글