프론트엔드 4명이 만드는 채팅 웹사이트(+ AWS) 2부

지난주 백엔드, AWS, DB 관련 기술 선정 및 아키텍쳐 구상을 했다.

nest로 local에 있는 mysql db에서 데이터를 처리하는 간단한 서버를 구현했고, 이를 EC2에 올려 보기로 했다.

 

이번 포스팅에서는 EC2에 올리기전에 api gateway에서 EC2가 있는 subnet의 target group까지 이를 연결하는 과정에 대한 이야기를 하겠다. 먼저 간단히 구조를 보면 다음과 같다.

 

로드밸런스는 리스너를 통해 트래픽을 받을 프로토콜과 포트번호를 정할 수 있고, 이를 라우팅할 대상그룹을 지정할 수 있다. Application Load Balancer는 path에 따라 이를 각각의 인스턴스로 라우팅할 수 있다.

 

대상 그룹 생성

먼저 EC2인스턴스를 대상으로 지정할 대상 그룹을 생성해야한다.

유저 서버의 대상 그룹 2개(http, https) / 채팅 서버의 대상 그룹 2개(http, https)

 

 

Application Load Balancer에서 리스너가 라우팅할 대상그룹은

상태 검사 경로를 지정함으로서 path에 따라 특정 ec2 인스턴스로 라우팅을 처리할 수 있다.

관련링크 : https://repost.aws/ko/knowledge-center/elb-achieve-path-based-routing-alb

 

http /api/user   https /api/user

http /api/chat   https /api/chat   이렇게 4개의 대상그룹을 생성했다.

 

 

 

ALB생성은 private subnet을 사용하기 때문에 내부로 설정하고

2개의 가용영역에서 유저서버와 채팅서버에서 사용하는 서브넷을 각각 연결했다.

 

그리고 ALB의 리스너 설정이다.

 

위에서 만들어준 대상 그룹을 추가해준다.

https도 동일하게 작업하면 된다. 현재 도메인 구매가 안되서 여기서는 건너뛰겠다.

 

 

 

다음으로 ALB를 대상으로 지정할 대상 그룹을 생성해야한다.

(local 및 개발에서 사용 http)80번 포트를 라우팅할 대상그룹 1개
(실제 서비스에서 사용 https)443번 포트를 라우팅할 대상그룹 1개를 지정해준다.

이 대상그룹은 NLB에서 리스너가 라우팅할 대상그룹을 지정할 때 사용되는데 NLB는 OSI 4계층에서 동작하므로 프로토콜이 TCP로 고정되어 있는 것을 확인할 수 있다.

 

 

총 6개의 대상그룹을 생성해줬다.

 

 

로드밸런서와 http만 리스너와 대상 그룹으로 설정한 모습이다. https는 도메인 발급 후 추가 예정