[NCP] Load Balancer 설정 작업

개요

인프런의 강의를 들으면서 Vue를 활용하는 예제를 보고싶어서 강의를 보던 중, AWS배포 과정이 영상으로 있길래, 현재 금액이 발생하는 AWS를 사용하는 것보다는, 현재 내가 무료로 사용할 수 있는 Naver Cloud를 활용해 보기로 마음을 먹었다.

또한 과거에 구매했던 도메인을 활용하여 도메인을 통한 접속으로 AWS로 치면 EC2인 Server에 접속하도록 아키텍쳐를 구상하던 중, Load Balancer부분에서 많은 에로사항이 있었어 가지고, 기록해 두고자 글을 남겨둔다.

개요에서 미리 적어두지만 모든 과정을 nginx로도 처리가 가능하다.
단지 필자의 경우 구매한 도메인인 jong1.com을 dev.devlog.jong1.com, prod.devlog.jong1.com 등등 여러 도메인으로 활용하고 싶었고, SSH연결을 해서 nginx설정을 하는게 아니라 Web(NCP)에서 리스너 변경만으로 모든 과정을 처리하고 싶었다.

실제 듣는중인 Inflearn강의

호돌맨의 요절복통 개발쇼 (SpringBoot, Vue.JS, AWS) - 인프런 | 강의

---

구성 아키텍쳐 구상도

일단 도메인을 통해서 접속을 하는게 목표였기 때문에 NCP의 2세대 버전의 DNS인 Global DNS와 DNS에 추가한 A 레코드와 매핑을 잡아줄 Load Balancer 그리고 기존에 사용중이던 Instance Server를 사용하였다.

아키텍쳐가 간단한 이유는 애초 목적이 하나였다. http://dev.devlog.jong1.com을 주소창에 입력할 경우 Server의 SpringBoot로 Request가 오고 Response를 Return하는 것을 확인을 하고자 하는게 목표기 때문이다.

 

Nginx를 활용 할 수는 있었지만, 그러면 결국 모든 처리를 내가 직접 Server에서 해야하기 떄문에 좋든 싫든 외부의 처리로 필터를 하는 과정을 겪어 봐야 겠다 생각했기 떄문이다..

---

작업 과정

Server Instance의 경우에는 기본적으로 생성 할 수 있을 것이라 생각을 하도록 하겠다.

또한 DNS부터 설정해도 상관없으나, 그래봐야 Target Group, Load Balancer생성해야한다.
먼저 생성하고 작업하는게 편하다

---

Target Group 생성

Load Balancer → Target Group에 존재하는 항목이다.
Target Group의 경우 Load Balancer가 조건이 만족 요청을 Target Group으로 Request를 전송해주는 Group이다

 

첫번째 페이지

Target Group의 이름은 설정하는 개발자가 구분하기 쉬운 명칭을 임의로 지어주면 된다.

Target 유형의 경우 필자는 VPC Server내부의 항목들에 대해서 Target으로 잡을 예정이었으나, 애초애 항목이 저거 하나였다.

VPC는 만들어둔 대역이 저거뿐이라 설정하였으며, 해당설정에 Server가 존재한다.

프로토콜은 API서버의 경우 RESTful API서버이며, 현재 SSL작업을 진행하지 않아 HTTP로 설정하였다.

포트는 Spring Boot 내장톰캣을 사용할 예정이며 따로 port변경을 하지않아 Default인 8080을 설정하였다. 

---

두번째 페이지

해당 페이지의 경우에는 실제 내가 Target으로 잡은 Server:Port가 200통신(ALIVE)인지 확인을 하는 신호를 보내는 작업을 진행한다.

따라서 필자의 경우 Spring Boot의 @GetMapping("/") 경로의 경우 그냥 간단한 Hello 메세지와 함께 200상태코드를 보내도록 설정하였다.

 

프로토콜의 경우 첫번째 페이지처럼 HTTP를 사용할 예정이기에 HTTP로 선택하였다.

포트는 Tomcat의 Default Port인 8080

URL Path는 신호를 보내서 OK를 받아야 하는 포트기 떄문에, 위의 설명처럼 "/" 포트를 지정하였다.

HTTP Method는 GET을 지정하였는데 필자가 GetMapping을 활용한 이유가 해당 이유이기 떄문이다.

Check 주기, 정상임계값, 실패 임계값 같은 경우에는 Default Value에서 따로 수정을 하지는 않았다.

---

세번째 페이지

세번째 페이지의 경우에는 Load Balancer로 Request가 들어와서 해당 Target Group으로 분류가 될 경우 Request요청을 처리해줄 Server를 지정하는 페이지이다.

 

전체 Target에서 Request를 처리할 Server를 적용 Target으로 이동시키면 된다.

---

네번째 페이지

이전 설정을 확인후 생성하면 된다.

---

Target Group 생성 이후 확인 필요 사항

생성한 Target Group을 Check한 이후 Target 상태 확인을 누른다. 

해당 과정이 필요한 이유가 필자의 경우에는 해당 Status가 오류인 경우 Request요청을 보내지 않는 문제가 있었기 때문이며, 200인 경우에만 Request요청을 보낸다 판단된다.

---

Load Balancer 생성

Load Balancer → Load Balancer에 존재하는 항목이다.

 

첫번째 페이지

로드밸런서 생성에 클릭을 하게되면, 세가지 항목이 표현된다.

내가 생성하고자 하는 Spring Boot서버는 일단 Application레벨이라 생각하여 Application LoadBalancer로 생성을 진행하였다.

---

두번째 페이지

로드밸런서 생성으로 들어오면 다음의 화면이 출력된다.

 

로드밸런서 이름은 이해하기 편한 명칭으로 하면된다.

부하 처리 성능의 경우 CPS(Connection Per Second)를 의미하며 초당 TCP Connection을 맺을 수 있는 횟수를 설정한다. 

각각 3만 / 6만 / 9만회이며, 필자는 많은 요청은 아직 없을 것이기에 small로 설정하였다.

 

대상 VPC의 경우에는 Target Group과 같은 VPC대역대를 선택하였으다.

서브넷의 경우에는 사실 몇대 안들어가도 된다해서 10.0.0.0/28로 지정을 했엇는데, 그러면 한대 생성후 다시 설정할 떄마다 기존 설정을 지워줘야 하는 불상사가 생겼다. 24로  Load Balancer용 서브넷을 따로 생성하자.

 

가장 중요한 Network 인데 자기가 만약 내부에서만 Balancing을 진행할 예정이면 Private Ip로 생성을 해야한다.

하지만 필자의 경우 외부 도메인에서 부터 Request가 오는 환경을 구축할 예정이기 때문에 Public IP로 설정을 진행해야 했다.

 

해당 항목이 Private IP로 보낼 것인지 Public IP로 Reuqest를 보낼것인지 같은 의미인줄 알았는데 Load Balancer가 Public IP로 요청을 받는지, 내부 VPC에서만 요청을 받는지의 의미였다... (진짜 이거때문에 오래걸렸다)

---

세번째 페이지

리스너를 생성하는 페이지이다.

리스너란 로드 밸런서가 대기하고 있을 포트를 의미한다. 필자의 경우 웹서버 로드밸런싱이기에 80, 443 만 추가 진행하면 되나, 443을 추가할경우 Certificate설정까지 해야해서 현재는 80만 진행하였다.

 

위의 화면을 아래처럼 만들면 되며, HTTP만 진행할 경우 443을 추가하지 않아도 된다.

---

네번째 페이지

리스너로 요청이 들어오면 Request를 전달해줄 Target Group을 지정하면된다.

위에서 생성했던 Target Group을 선택하자. 

 

필자의 경우에는 Target Group을 생성까지는 하지 않아서 선택할 그룹은 없다..  해당 페이지 이후 설정확인후 생성을 진행하면 된다.

---

Load Balancer 생성 이후

Load Balancer를 생성하면 로드밸런서에 아래의 빨간 박스처럼 접속정보가 출력이 된다. 

해당 주소로도 접속이 가능하니 참고하길 바란다.

 

필자의 경우 dev.devlog.jong1.com과 그냥 devlog.jong1.com의 Request를 분류하고싶었다. 

필자와 같은 고민을 하는 사람의 경우 우선 리스너 설정 변경을 클릭한다.

 

리스너 설정 변경을 누르게 되면 Load Balancer를 생성당시 추가한 리스너가 출력되는데, 이중에서 본인이 희망하는 포트를 클릭(단일갯수)후 규칙 조회/변경으로 접속한다.

규칙 조회/변경 을 누르게 되면 Default로 다음과 같은 설정이 이뤄져 있는데 해당 설정의 변경이 필요하다. 

규칙 추가를 진행하자.

해당 설정에서 필자의 경우에는 도메인을 통한 분류를 진행할 예정이다. 따라서 조건의 항목에서 Host Header로 진행할 예정이긴 하나, Path로 분류할 경우에는 Path Pattern을, HTTP Header로 넘어오는 Value를 활용할 경우에는 HTTP Header항목을 활용해보기 바란다.

다음과 같은 룰을 추가해줬으며, Sticky Session의 경우에는 기존에 보낸 요청 Server로 Request를 보내는 요청인 듯 하다.

분산환경 구축할꺼면 해당항목은 필요없을 것 같아 체크하지는 않았다.

설정을 마친 모습은 다음과 같으며, 두개모두 일단 같은 TargetGroup이지만, 추후 Default조건 Group을 변경하게 되면 dev.devlog.jong1.com으로 들어오는 요청과 그외의 모든 요청이 구분되어 사용되어 진다.

 

조건을 추가할 때 마다 다른 요청작업이 이뤄지며, Redirection설정까지도 가능하다.

필자의 경우 blog.devlog.jong1.com은 필자의 Tistory로 오도록 설정하였다.

---

Global DNS 생성

Global DNS → Record에 존재하는 항목이다.

 

첫번째 페이지

Global DNS에서 도메인 추가를 클릭 하게되면 아래의 화면이 표현된다.

DNSSEC의 경우에는 잘 모르기 떄문에 그냥 안했다... 보안관련인거같은데..

설명은 어떤 종류의 도메인인지 기록하는 정도로만 했으며, 이름은 내가 구메한 도메인을 기입하였다. 필자의 경우에는 jong1.com이었다.

---

DNS 생성 이후

도메인 추가를 진행하게 되면 다음의 빨간 박스에 네임서버 정보가 출력된다. 

해당 정보를 필자가 구매한 도메인 사이트에서 네임서버 정보를 변경하였다.

 

필자는 GoDaddy를 활용하였다. (최초면 com주소가 1년 12,000원정도다)

---

레코드 추가

네임 서버의 연결을 진행하였으면, Global DNS로 와서 다음과 같이 설정한다.

 

레코드 추가버튼을 누른 이후 A레코드를 활용하면 되며, 주소는 devlog의 모든 요청을 받을 예정이기에 *.devlog로 설정하였다.

이후 기존에 제작했던 Load Balancer를 사용할 예정이기에 LBVPC로 기존에 생성한 Load Balancer를 선택후 추가하면 된다.

 

이후 설정된 (5분)300초의 DNS 적용시간이 지나고 확인해 보기 바란다.

 

잘나온다.

---

개요

이전에 회사에서 있을 떄도 만져 본 경험은 있는데 그때는 AWS 이고, 직접 돈주고 해보긴 아까워서 기억이 가물가물 했다.

AWS랑 비슷하면서도 약간씩은 다른 느낌이 있는 것 같아서 한번 기록으로 남길 필요가 있다고 느꼈다.

인프라 설정은 잘될떄는 재밌는데.. 한번막히면 참...ㅠㅠ