클라이언트에 대한 단일 접점 역할을 수행한다. 로드 밸런서는 여러 가용 영역에서 여러 인스턴스 대상에 수신 애플리케이션 트래픽을 분산한다. 이렇게 하면 애플리케이션의 가용성이 향상된다.
Load Balancer 적용
1.로드밸런서 생성 - 1
2.로드밸런서 유형 선택
사용하는 환경에 따라 3가지 Load Balancer 유형을 제공한다. 나는 애플리케이션 로드밸런서를 선택했다.
3.로드밸런서 생성 - 2
클라이언트에 대한 단일 접점 역할을 하기 위해선 Public IP를 받는다. 부하 처리 성능은 Small, Medium, Large 순서대로 각각 3만, 6만, 9만 초당 연결 수를 보장한다. 그리고 VPC를 선택하고, 해당 VPC 안에 로드밸런서용 subnet이 존재해야한다.
4.로드밸런서 생성 - 3
리스너를 설정한다. 리스너는 외부 에서 어떤 프로토콜의 어떤 포트로 클라이언트로 부터 받는 것이다. 즉 클라이언트 에게 귀를 귀울이고 있다. HTTP 혹은 HTTPS로 받을지 설정하고 포트를 설정한다. Load Balancer가 제공하는 DNS를 통해 들어올 때 기본 포트인 80 포트로 들어오기 때문에 나는 HTTP, 80 으로 설정하고 추가했다. 더 나아가, HTTPS로 받기 위해서는 인증서가 필요하다. 그리고 기본 포트는 443이다.
5.타겟 그룹 선택
타겟 그룹을 설정한다.
Target Group 적용
1.타겟 그룹 생성 - 1
2.타겟 그룹 생성 - 2
이름을 설정하고, Target 유형에 VPC server를 선택한다.(VPC server 밖에 없다.) 그리고 로드밸런서가 있을 예정인 VPC를 선택한다. 그리고 프로토콜을 선택해야 한다. TCP, Proxy TCP, HTTP, HTTPS가 있다. 그 전에 알아두어야 할 것이 어떤 프로토콜을 선택하느냐에 따라 로드밸런서의 유형이 결정된다.
프로토콜
로드 밸런서 유형
TCP
Network Load Balancer
Proxy TCP
Network Proxy Load Balancer
HTTP, HTTPS
Application Load Balancer
그리고 포트를 설정해준다.
나는 HTTP 프로토콜에 포트 80으로 설정했다.
3.Health Check 설정
로드 밸런서가 주기적으로 관리하고 있는 서버에 핼스 체크를 날리는데, 핼스 체크를 하기 위해 포트와 HTTP 메소드를 설정해준다.
그리고 핼스 체크 주기와 정상, 실패 임계값을 설정한다. 핼스체크를 몇번을 성공해야 로드 밸런서가 해당 서버는 안전하다고 생각하는지의 수치가 정상 임계값이고 실패 임계값은 그 반대이다.
4.타겟 추가
전체 Target 영역에서 Target Group에 포함시킬 Target을 선택한다. 전체 Target은 VPC 내 모든 서버를 대상으로 한다. [>] 버튼을 클릭하여 적용 Target 영역으로 이동하여 타겟을 적용한다. 그렇게 이제 타겟 생성이 완료 되었고 로드 밸런서에 적용 되어 있을 것이다.
오토스케일링(Auto Scaling)은 클라우드의 유연성을 돋보이게 하는 핵심기술로 CPU, 메모리, 디스크, 네트워크 트래픽과 같은 시스템 자원들의 메트릭(Metric) 값을 모니터링하여 서버 사이즈를 자동으로 조절한다. 이를 통해 사용자는 예상치 못한 서비스 부하에 효과적으로 대응하고 비용 절감 효과를 볼 수 있다.
Auto Scaling 적용
Auto Scaling 서비스는 Launch Configuration을 생성하고, Auto Scaling Group을 생성한 후에 이용할 수 있다.
Launch Configuration 생성
1.Launch Configuration 생성
2.서버 이미지 설정
나는 centos-7.8-64로 선택하였다.
3.서버 설정 서버 이미지를 설정 하고 서버를 설정한다.
서버 타입을 설정하고, 서버에 init Script가 설정 되어 있는 서버에서만 SourceDeploy 서비스를 이용할 수 있다.
인증키를 설정한다. NCP에서 발급 받은 .pem 파일로 인증을 한다. Auto Scaling이 생성 해내는 인스턴스에 접근할 때 사용된다.
이 설정이 마치면 Auto Scaling Launcher가 생성된다.
Auto Scaling Group 생성
1.Auto Scaling Group 생성
2.Launch Configuration 선택 Launch Configuration을 선택한다.
3.Auto Scaling Group 설정
오토스케일링을 생성하기 전에 오토스케일링 전용 Subnet을 만들어서 적용시켜준다.
입력사항
설명
최소 용량
그룹의 최소 서버 수
최대 용량
그룹에서 생성 가능한 최대 서버 수
기대 용량
서버의 수는 기대 용량값에 따라서 조정된다. 이 값은 최소 용량 이상, 최대 용량 이하여야 한다.
쿨다운 기본값(초)
실제 Scaling이 수행 중이거나 수행 완료된 이후에 모니터링 이벤트 알람이 발생하더라도 반응하지 않고 무시하도록 설정한 기간이다. 기본값은 300초이다.
헬스 체크 보류 기간
서버 인스턴스가 생성되어 상태가 ‘운영 중’으로 변했더라도, 서버의 업데이트 설치 등 작업에 의해서 헬스 체크에 정상 응답하지 못하는 경우가 생길 수 있다. 이런 경우 헬스 체크 보류 기간을 지정하면 해당 기간 동안에는 헬스 체크에 실패하더라도 서버 헬스에 이상이 있다고 판단하지 않는다.
헬스 체크 유형
헬스체크 유형이다. 서버, 로드벨런서가 있다.
4.네트워크 접근 설정 ACG를 생성하여 적용시킨다.
5.정책 설정
Scaling 정책은 3가지 방식으로 설정할 수 있다.
(1) 증감변경: 현재 그룹 크기와 상관없이 지정한 서버 대수를 직접 추가 또는 삭제하는 방법
(2) 비율변경: 현재 그룹 크기 대비 일정한 비율(%)로 서버를 증감시키는 방법.
(3) 고정값: 그룹 크기를 지정한 값으로 고정시키는 방법.
쿨다운(cooldown)이란 일단 Scaling이 수행되면 추가적인 알람이 발생하더라도 이에 반응하지 않도록 설정된 시간이다. 쿨다운 시간 동안은 Scaling의 수행이나 완료 여부에 상관없이 추가로 발생한 이벤트에 대해서 아무 동작을 하지 않게 된다.
새로운 코드 변경사항이 정기적으로 테스트 빌드 되므로, 여러 명의 개발자가 동시에 어플리케이션 개발을 할 때 충돌 문제를 해결할 수 있다. 그리고 개발자의 변경 사항을 리포지토리에서 고객이 사용 가능한 프로덕션 환경까지 자동으로 릴리스하기 위함이다.
CI/CD 프로세스를 적용함으로써 수작업으로 진행되었던 많은 부수적인 일들을 줄일 수 있다. 그리하여 개발자는 개발에 집중할 수 있다.
CI/CD 적용
NBP(네이버 클라우드 플랫폼)에는 CI/CD 구축을 돕기 위해 SourceCommit, SourceBuild, SourceDeploy, SourcePipeline을 제공하고 있다. 나열한 순서대로 CI 부터 CD까지 적용을 돕는다. 그리고 SourcePipeline으로 CI/CD 모든 과정을 이어준다.
SourceCommit
1.외부 레포지토리 복사를 클릭
"레포지토리 생성"을 누르면 빈 레포지토리가 생성되고 "외부 레포지토리 복사"를 누르면 외부의 레포지토리를 복사할 수 있다. 나는 깃헙에 있는 레포지토리를 복사하는 것을 선택했다.
2.레포지토리 생성
레포지토리 이름과 복사할 Git URL을 입력한다.
그 다음 File Safer 상품과 연동할 것인지 묻는다. (File Safer는 고객이 업로드/다운로드 하는 파일의 악성코드 여부를 검사할 수 있는 서비스이다.)
처음에 연동을 하고 하루가 지나고 지불된 금액을 확인했는데 바로 10만원 가까이 나가있었다.. 그래서 나는 연동을 하지 않았다.
3.생성
확인을 누르면 생성이 된다.
4.생성된 레포지토리를 클릭하고 코드 이동을 누르면
깃헙에 있었던 코드들이 그대로 옮겨져 있는 것을 볼 수 있다. 여기서 오해할 수 있는 점이 깃에 푸시를 해도 NCP의 SourceCommit 레포지토리에 반영은 되지 않는다. 그 의미는 깃헙의 깃액션 CI를 사용하지 못한다는 의미이다.
해당 SourceCommit 레포지토리에 반영을 하려면
따로 git clone을 해줘야한다. SourceCommit은 git 명령어를 지원해서 기존 깃헙 사용자들도 사용하기 편리할 것이다.
SourceBuild
1.빌드 프로젝트 생성
2.Object Storage 연결
빌드한 결과물을 저장해두는 저장소 같은 개념이다. AWS의 S3랑 비슷한 개념을 가진 저장소이다.
3.빌드 프로젝트 생성 - 기본 설정
여기서 중요한 곳은 빌드 대상인데, SourceCommit, 깃헙, Bitbucket에 있는 레포지토리 세 가지를 선택할 수 있다. 나는 SourceCommit을 선택하였다.
깃헙을 선택해서 깃헙에 있는 레포지토리에 push를 하면 그게 트리거가 되어서 배포 파이프라인이 작동되게끔 하고 싶었는데 NCP에서는 깃헙의 트리거를 못받는 것 같았다. 그래서 빌드 대상을 깃헙 대신 SourceCommit을 선택 하였다.
이 부분은 추후 젠킨스로 구현 해봐도 좋을 것 같다.
4.빌드 프로젝트 생성 - 빌드 환경
빌드 환경 설정이다.
ubuntu 16.04 (x64) 환경에서 java로 빌드하게 하였다. 비용 문제로 컴퓨팅 유형은 제일 작은걸로 하였다.
그리고 나의 프로젝트에서 docker-compose를 사용하기 때문에 도커 환경이 필요했다. 그래서 도커 이미지 빌드 를 체크 해주었다. 도커 환경이 필요하지만 체크를 하지 않으면 명령어로 도커를 다운로드하고 설정하는 귀찮은 작업을 따로 해주어야한다.
5.빌드 프로젝트 생성 - 빌드 명령어 설정
SourceCommit에 있는 프로젝트를 빌드 하고 필요한 명령어를 입력하는 곳이다.
나는 빌드 후 프로젝트 전체를 jar파일로 말아올려 서버에서 실행시킬 명령어인 ./gradlew bootjar 명령어를 입력 해주었고 깃헙을 거쳐 깃헙 액션을 실행시키지 못하는 환경을 대신해서 ./gradlew test 명령어를 실행시켜 빌드 후 테스트 과정도 거치게 하였다.
6.빌드 프로젝트 생성 - 결과물 업로드 설정
빌드 후 결과물을 Object Storage에 저장할 때 경로를 설정하는 곳이다. 빌드 결과물은 .zip 파일로 저장이 된다. 빌드 결과물을 저장할 Storage를 설정하고 경로, 폴더/파일명을 설정한다. 그리고 백업파일 여부도 설정한다.
백업 사용을 설정하면 Object Storage에 따로 백업 폴더가 생성된다.
7.빌드 프로젝트 생성 - 추가 상품 연동
추가 상품은 비용 문제로 연동하지 않았다.
SourceDeploy
1.배포 프로젝트 생성
2.프로젝트 이름 설정
3.배포 환경 설정
배포 환경 설정에서 stage를 설정하고 배포 타겟을 설정한다. 나는 Auto Scaling 되고있는 서버 전체에 모두 배포를 하기 위해서 배포 타겟을 Auto Scaling으로 했다. 사실 Server를 체크 해서 해도 되지만 만약 Auto Scaling에서 서버를 자동적으로 늘릴 때 그 서버를 수동으로 포함 시켜줘야하기 때문에 Auto Scaling으로 체크 하였다.
4.배포 시나리오 설정
설정이 끝나면 배포 시나리오를 설정 해야한다.
아래처럼 배포 시나리오를 설정하면 된다.
배포 전략에 지금은 기본으로 되어있지만 추후 블루/그린 배포 전략을 사용 해볼 예정이다.
배포 과정은 순차 배포, 동시 배포가 있는데 순차 배포가 더 낫다고 생각하여 순차배포를 선택하였다. 그 이유는 배포과정에 놓여진 서버는 로드벨런서가 트래픽을 보낼 수 없기 때문에 순차적으로 배포 될 때 배포 되고 있지 않는 서버들에게는 트래픽을 보낼 수 있기 때문에 무중단 배포가 된다고 생각하여 순차 배포가 낫다고 생각하였다.
배포 파일은 Object Storage에 있는 빌드된 zip 파일을 배포하는 것으로 설정 해두었다.
그 다음은 배포 명령어를 설정한다.
배포 전 실행, 파일 배포, 배포 후 실행으로 나뉜다.
설정할 때 주의할 점이 경로이다. 그리고 한 줄이 실행되면 원래의 경로로 돌아오기 때문에 &&로 구분하여 묶여있는 명령어는 한번에 처리해야한다.
