본 포스트는 '미띵' 프로젝트의 배포 과정을 담고 있습니다.
ALB(Application Load Balancer) 란?
ALB는 AWS에서 제공하는 로드밸런서 중 하나로 OSI Layer7인 어플리케이션 계층에서 동작하는 로드밸런서입니다. 부하(Load), 즉 트래픽을 균형있게 나누어준다(Balance)는 의미로 로드 밸런서라고 부릅니다.
위 사진과 같이 Load Balancer, Listener, Rule, Target group 으로 이루어져있습니다.
사실 로드밸런서 연결을 처음 해보는 입장에서 네트워크 기본 개념을 제대로 이해하고 있지 않아 이걸 왜 여기 연결하라는 거지? 라는 의문이 반복적으로 들었습니다. 배포하기 앞서서 네트워크 기본 구조를 짚고 넘어가겠습니다.
VPC(Virtual Private Cloud)
VPC는 VPN과 같이 실제로 같은 네트워크(리전)상에 있어도 논리적으로 다른 네트워크인 것처럼 인스턴스를 분리합니다.
VPC가 없다면 EC2 인스턴스들이 서로 거미줄처럼 연결되고 인터넷과 연결됩니다. 이런 구조는 시스템의 복잡도를 엄청나게 끌어올릴뿐만 아니라 하나의 인스턴스만 추가되도 모든 인스턴스를 수정해야하는 불편함이 생깁니다.
VPC를 적용하면 위 그림과같이 VPC별로 네트워크를 구성할 수 있고 각각의 VPC에따라 다르게 네트워크 설정을 줄 수 있습니다. 또한 각각의 VPC는 완전히 독립된 네트워크처럼 작동하게됩니다.
VPC를 생성하는 경우, 다음과 같이 /16RFC 1918:규격에 따라 프라이빗(비공개적으로 라우팅 가능) IPv4주소 범위에 속하는 CIDR블록을 지정하는 것이 좋습니다.
- 10.0.0.0 ~ 10.255.255.255(10/8 prefix)
- 172.16.0.0 ~ 172.31.255.255(172.16/12 prefix)
- 192.168.0.0 ~ 192.168.255.255(192.168/16 prefix)
VPC 생성시 블록 크기는 /16 ~ /28 비트의 서브넷 마스크만을 허용합니다. 즉 가장 큰 대역은 /16, 가장 작은 대역은 /28 입니다.
한번 설정된 아이피대역은 수정할 수 없으며 각 VPC는 하나의 리전에 종속됩니다. 각각의 VPC는 완전히 독립적이기때문에 만약 VPC간 통신을 원한다면 VPC 피어링 서비스를 고려해볼 수 있습니다.
172.31.0.0/16 으로 VPC를 생성하였습니다.
서브넷
VPC를 만들었다면 이제 서브넷을 만들 수 있습니다. 서브넷은 VPC를 잘개 쪼개는 과정입니다. 서브넷은 VPC안에 있는 VPC보다 더 작은단위이기때문에 연히 서브넷마스크가 더 높게되고 아이피범위가 더 작은값을 갖게됩니다. 서브넷을 나누는 이유는 더 많은 네트워크망을 만들기 위해서입니다.
네트워크 요청이 발생하면 데이터는 우선 라우터로 향하게됩니다. 라우터는 서로 다른 네트워크에 있는 데이터의 목적지가 정해지면 해당 목적지까지 어떤 경로로 가는 것이 좋은지를 알려주고 이 경로 정보를 라우팅테이블에 등록합니다.
cf) 랜에서는 MAC 주소만으로 통신할 수 있지만 다른 네트워크에 데이터를 보내기 위해선 라우터와 IP주소가 필요하다
서브넷A의 라우팅테이블은 172.31.0.0/16 즉 VPC안의 네트워크 범위를 갖는 네트워크 요청은 로컬에서 찾도록 되어있습니다. 하지만 그 이외 외부로 통하는 트래픽을 처리할 수 없습니다. 이때 인터넷 게이트웨이를 사용합니다.
IGW(Internet Gate Way)
인터넷게이트웨이는 VPC와 인터넷을 연결해주는 하나의 관문입니다. 서브넷B의 라우팅테이블을 잘보면 0.0.0.0/0으로 정의되어있습니다. 이뜻은 모든 트래픽에 대하여 IGA(인터넷 게이트웨이) A로 향하라는뜻입니다. 라우팅테이블은 가장 먼저 목적지의 주소가 172.31.0.0/16에 매칭되는지를 확인한 후 매칭되지 않는다면 IGA A로 보냅니다.
인터넷과 연결되어있는 서브넷을 퍼블릭서브넷, 인터넷과 연결되어 있지 않는 서브넷을 프라이빗서브넷이라고합니다.
미띵 프로젝트의 경우 현재 VPC1, 서브넷4, 라우팅테이블1, IGW1 으로 구성되었으며 서브넷4개 모두 퍼블릭 서브넷입니다.
Route53 도메인 생성
미띵 서버는 api.meething.net, config.meething.net, chat.meething.net 과 같이 세개의 서브 도메인으로 나뉘며, 로드밸런서가 서브도메인에 따라 서버에 요청을 보내게 됩니다.
로드밸런서를 연결하기 앞서 https 로 접속이 가능하게 SSL 인증서를 발행합니다.
ACM (Amazon Certificate Manager)에서 인증서 발급
모든 서브 도메인에 대한 SSL을 받고싶으면 와일드카드 인증서(*.your.domain)를 요청하면 됩니다. 저는 위와 같이 *.meething.net 으로 요청했습니다. Route 53 에서 레코드 생성이라는 버튼이 있는데 이를통해 조금 전 만들어 놓은 Route 53에 자동으로 DNS 설정 됩니다.
A
도메인 주소를 서버의 IP 주소로 직접 매핑시키는 방법
첫 번째 컬럼으로 a.meething.net 두번째 칼럼으로 123.123.123.123을 설정하면, 사용자가 a.meething.net 을 요청했을 때 DNS서버는 123.123.123.123을 전달하게 된다.
CNAME
도메인 주소를 또 다른 도메인 주소로 매핑 시키는 방법
위의 A 레코드가 추가 돼있는 상태에서, CNAME을 새로 추가한다고 가정해보자.
첫 번째 칼럼으로 cname.meething.net, 두번째 칼럼에 a.meething.net 을 설정하면, 사용자가 cname.meething.net 을 요청했을 때 DNS 서버는 a.meething.net 을 전달하게되고, 다시 사용자가 a.meething.net 을 요청하면 DNS 서버는 최종적으로 123.123.123.123을 전달하게 된다.
A 레코드는 IP주소가 변경되면 연결된 도메인의 컬럼을 모두 변경 해주어야 하지만 CNAME 같은 경우에는 연결된 도메인의 A 레코드 컬럼만 변경해주면 되기 때문에 IP가 자주 변경되는 환경에서 유연하게 대처할 수 있다는 장점이 있다. 하지만 IP주소를 얻는 데 까지 있어서 DNS 서버와의 여러번의 전송이 필요해 성능저하를 유발할 수 있다.
VPC, 서브넷, IGW 연결과 SSL인증서 발행까지 마쳤다면 ALB를 연결할 수 있습니다.
- 대상 그룹 생성
- 로드밸런서 생성 및 대상 그룹 연결
- Route53 레코드에 로드밸런서 연결
순서대로 진행합니다.
대상 그룹 생성
앞서 생성했던 VPC에 대상 그룹을 생성하고 각 대상 그룹에 맞는 인스턴스를 등록합니다.
ALB 생성
Application Load Balancer 를 생성합니다.
앞서 생성한 VPC를 매핑하고 서브넷을 선택합니다.
리스너 생성
HTTPS:443 과 HTTP:80 프로토콜 리스너를 생성합니다.
라우팅 액션을 대상 그룹으로 전달, 앞서 생성한 대상그룹을 매핑해줍니다. HTTPS:443 의 경우 보안 정책을 선택하고 ACM 인증서도 연결해줍니다.
리스너 규칙 생성
각 리스너에 규칙을 생성해줍니다.
Route53 에 ALB 라우팅 레코드 추가
처음엔 Route53에도 A레코드 형식의 api.meething.net, chat.meething.net, config.meething.net 서브도메인에 ALB를 각각 라우팅하도록 레코드를 추가해주었으나 이렇게 하면 연결이 되지 않습니다. Route53 에는 와일드카드 도메인 (*.meething.net) 하나만 레코드로 추가해 ALB를 라우팅합니다.
서브도메인에 따라 올바르게 접속되는것을 확인 할 수 있습니다.
'기타' 카테고리의 다른 글
| QueryDsl + JPA 로 게시글 페이지네이션 구현기, 일대다 외부조인시 유의해야할 점 (0) | 2023.09.17 |
|---|---|
| ERD Cloud 를 이용한 데이터 모델링, DB 설계 (0) | 2023.09.17 |
| 우아한 테크코스 프리코스 회고 (0) | 2023.03.23 |
| 오브젝트 (역할, 책임, 협력/캡슐화와 응집도에 대하여) (0) | 2023.03.23 |
| AWS SNS vs. SQS (feat. Lambda) (1) | 2023.03.07 |
댓글