AWS monolithic APP 고도화(1)

1. 개요

이번 파트에서는 DB와 어플리케이션을 분리하는 작업을 진행할 것이다. 이를 통해서 어플리케이션들은 하나의 DB를 참조하는 stateless 한 구조로 변경할 수 있다. 또한 private subnet에 DB를 위치함으로 외부로부터의 접근을 막고 어플리케이션을 통해서만 접근할 수 있다.

2. 세팅

2.1 VPC 생성

프로젝트를 위한 가상 네트워크를 만들어 준다. 단순하게 이름과 IPv4 CIDR 만 임의로 설정해 주면 된다. 다음과 같이 설정했다

2.1.1 인터넷 게이트웨이

가상 네트워크인 VPC에서 외부 인터넷과 통신을 하기 위해서는 인터넷 게이트웨이가 필요하다. 생성한 후에 뒤에서 routing table과 연결해서 각각의 subnet에서 외부와 통신이 가능하다.

2.2 Subnet 생성

생성된 VPC 위에subnet 을 생성해 준다. 이때 subnet에 private subnet과 public subnet 두 종류가 존재한다. public subnet에는 private subnet이 외부 네트워크와 통신할 수 있게 도와주는 NAT Gateway를 올릴 수 있고 private subnet에는 현재 어플리케이션과 DB를 실행시킨다.

앞서 만들어 주었던 VPC를 연결하고 적절한 서브넷 이름과 CIDR을 설정해준다. 이때 CIDR은 VPC의 CIDR 범위 내에서 다른 subnet과 겹치지 않아야 된다. 또한 나중에 Auto Scale을 적용할 것이기 때문에 가용영역(Avaliable Zone)을 다양하게 선택해준다.

 

2.2.1 NAT 게이트웨이

private subnet은 public ip를 할당받지 못한다. 그렇게 때문에 외부 인터넷과 통신할 수 있는 방법이 없는데, 이를 해결하는 것이 NAT Gateway이다. private subnet 은 NAT Gateway의 public ip 주소를 자신의 public ip로 사용해서 외부와 통신한다. 이때 private subnet은 외부로 요청을 할 수는 있지만 외부로부터 요청을 받을 수 없다. 즉 outbound 요청만 가능하다.

NAT Gateway는 public subnet에 위치해서 private subnet 은 먼저 요청을 public subnet으로 보내 내부의 NAT Gateway를 사용한다.

앞서 만들어 두었던 public subnet 에 NAT Gateway를 위치시킨다

2.2.2 라우팅 테이블

subnet 은 라우팅 테이블을 사용해서 트래픽을 올바르게 전달한다. 라우팅 테이블은 다음과 같은 형태로 구성되어 있다

위의 테이블에서는 0.0.0.0/0 즉 모든 요청에 대해서는 인터넷 게이트웨이(igw-??)로 전달하고 10.16.0.0/16 요청에 대해서는 local로 전달한다. 이때 더 자세한 주소를 우선으로 실행한다.

앞서 생성한 VPC에 생성한다

라우팅 테이블을 생성하고 나서 체크박스를 선택한 후 라우팅을 확인해 보게 되면 local 만 존재한다. 라우팅 편집을 눌러서 0.0.0.0/0 요청에 대해서 public subnet은 인터넷 게이트웨이(igw-??)를 private subnet은 NAT Gateway(nat-??)을 추가해 준다.

그 후에 subnet으로 돌아가 각각의 subnet의 라우팅 테이블에 방금 생성했던 라우팅 테이블들을 적절히 연결해 준다.

추가적으로 DB를 위한 subnet이 필요하다. 동일한 과정을 진행해서 privateDBSubnet을 2~3개 생성해 준다. 이때 해당 subnet 에는 추가적인 라우팅 테이블 설정 없이 기본 라우팅 테이블을 사용한다

default routing table

2.2.3 결과

굳이 subnet 개수를 맞출 필요 없이 2개 이상으로만 만들어주면 된다.

2.3 RDS

2.3.1 DB subnet group

고가용성을 생각해서 DB를 단일 AZ에만 실행시키는 것이 아니라 안정성 측면에서 백업용, 복원용 DB를 추가하거나 성능적 측면에서 read replica DB를 추가하는 등 다중 AZ 배포를 진행한다. 이를 위해서 DB를 배포할 subnet group을 정의한다.

앞서 만들었던 VPC에 위치한 privateDBSubnet을 연결해 주면 된다. 이를 통해 3개의 AZ에 동일한 DB가 존재하게 된다.

2.3.2 MySql

cloud native 한 Aurora(MySQL)을 사용하고 싶었지만 Freetier를 사용 중이기 때문에 일반 MySQL을 사용한다

여기서 다중 AZ DB 클러스터는 main DB를 제외한 다른 DB도 read replica로 main DB에서만 조회를 하는 것이 아니라 replica DB에서도 조회를 진행해서 읽기 성능을 향상시킨다. 다중 AZ DB 인스턴스란 master DB가 존재하는 상황에서 다른 DB는 단지 복원을 위해서만 사용된다. 이러한 상황에서 master DB가 예상치 못한 에러로 종료되게 되면 복원용 DB가 master DB로 자동으로 승격되서 서비스를 유지할 수 있다. 

이러한 다중 AZ 기능들을 사용하고 싶지만 Aurora와 동일하게 프리티어 문제로 단일 DB 인스턴스를 사용한다.

앞서 만들었던 DB subnet group과 VPC, 보안 그룹을 연결해 준다.

2.3.3 보안 그륩

DB는 private subnet에 위치해 있고 EC2에서만 접근을 허가하기 때문에 보안 그륩을 설정해 주어야 된다. 먼저 EC2에 대한 보안그룹을 생성한다. EC2에서는 기본적으로 http인 80, https인 443 port 에 대해서 허용한다

SSH는 디버깅을 위해 허용해두었다. 굳이 안해도 된다

그 후에 DB를 위한 추가적인 보안그룹을 생성한다. port 는 MySQL을 가리키는 3306 포트에 대해서 앞서 생성한 EC2의 보안그륩을 지정해 준다

이를 통해서 EC2에서만 해당 MySQL DB에 접근이 가능하다

2.3.4 결과

생성이 완료된 후에 해당 엔드포인트를 사용해서 EC2에서 접근할 수 있다.

2.4 EC2

DB 테스트를 진행하고 AMI과 시작 템플릿을 생성하기 위해서 일단 public subnet에 EC2를 실행한다.

앞서 생성한 VPC와 public subnet에 EC2를 실행하고 보안그룹을 통해 http, https 통신을 허용한다. 그 후에 고급 세부 정보에서 user data부분에 앞서 생성한 DB의 엔드포인트, name, password를 입력한 뒤 인스턴스를 시작한다.

해당 인스턴스의 EC2에 접속해 보면 정상적으로 동작하고 DB도 잘 연결된 것을 알 수 있다.

2.4.1 AMI

Amazon Machine Image의 약자로 EC2를 실행할 때 사용하는 이미지 파일이다. Auto Scale을 구현할 때 필요한 시작 템플릿을 쉽게 만들 수 있다. 다음과 같이 작업에서 이미지 생성을 선택해 이미지를 생성한다.

2.4.2 시작 템플릿

옆에 사이드 바에서 시작 템플릿을 선택한 뒤에 생성을 누른다.

앞서 만들었던 AMI를 선택한다

해당 Template을 사용해서 만들 인스턴스의 스팩을 정의한다

네트워크 설정에서 서브넷은 Auto Scale이 지정해 주기 때문에 포함하지 않고 보안 그룹만 설정한 뒤 생성한다. 결과적으로 private subnet에 해당 인스턴스를 실행할 것이기 때문에 public ip 설정을 따로 하지 않는다.

3. 다음 글

auto scale을 정의, ALB를 통해서 트래픽 분산 작업을 진행, 부하 테스트