위 아키텍처에서 이제 마지막 리소스 "DB"가 남았습니다.
AWS에서 사용할 수 있는 Database의 종류는 다음과 같습니다.
1. 인스턴스에 직접 Database 를 설치하여 사용하기
- 가장 익숙하고 쉬운 방법
- 설치, 세팅, 운영, 트러블 슈팅 등 모두 직접해야 함
2. 관리형 RDS 사용하기
- AWS에서 관리 솔루션(Read Replica, Multi-az, failover 등)을 제공하며 클라우드에 최적화된 Database
- 비싸고 또 비싸고
3. 서버리스 NoSQL 사용하기(DynamoDB)
- 비정형 데이터를 다루는데 최적화. 매우 빠르고, 서버리스라 관리할 것도 없음
- 정형데이터를 다루는데는 비적합. 비경험자에게는 고려할 사항이 많기 때문에 어려울 수 있음.(rcu, wrc 이게뭐람..)
이 외에도 RedShift같이 대용량 데이터웨어하우스, ElastiCache 같이 캐시에 사용하는 데이터베이스 등을 제공합니다.
이번 포스팅에서는 가장 많이 사용한는 관계형 데이터베이스 서비스인 RDS - MySQL을 사용하겠습니다.
1. RDS
RDS는 AWS에서 제공하는 관계형 데이터베이스 서비스입니다.
MySQL, MariaDB, PostgreSQL 등 다양한 데이터베이스를 클라우드에 최적화하여 제공하는 "관리형" 서비스입니다.
사용자는 설치부터 운영, 트러블슈팅까지 AWS가 제공하는 솔루션으자로 해결할 수 있다는 장점이 있으나, 역시나 비용 부담이 있습니다.
최근에는 AWS가 자체적으로 클러스터기반의 Aurora DB를 제공하고있는데, 속도, failover, ReadReplica 등 그 기능이 매우 뛰어나지만 기존의 RDS 보다 비용이 더 비싸다는 무시못할 한계가 있습니다.
RDS를 생성하기전에 DB 서브넷 그룹으로 지정할 서브넷을 만들겠습니다.
VPC > Subnets > Create Subnet
상세한 설명은 앞서 Subnet 챕터에서 했기 때문에 생략하겠습니다.
이제 이 서브넷들을 DB Subnet group 으로 묶어야합니다.
RDS 는 2개 이상의 서브넷으로 묶인 DB Subnet Group 내에서만 생성될 수 있기 때문입니다.
RDS > Subnet groups > Create Subnet group
1. AddSubnets
DB Subnet Group에 포함될 서브넷을 지정하는 단계입니다.
위에서 만들어 둔 DB 전용 서브넷을 A, C 존을 각각 선택한 뒤 추가해줍니다.
아래 Subnets in this subnet group 에서 확인할 수 있습니다.
아래와 같이 DB Subnet 이 추가되었습니다.
이제 RDS 인스턴스를 생성하겠습니다.
RDS > Databases > Create Database
왕초보 탈출 시리즈이기 때문에 다 설명하긴 너무 길어 기본적인 것들만 설명하겠습니다.
위 설정 사항은 이름만 봐도 알 것이라고 생각합니다.
직접 구성을 해주기 위해 Standard Create, Engine 은 MySQL 을 사용합니다.
RDS의 단점 중 실제 엔진이 업그레이드 되더라도 AWS 에서 RDS Engine 업데이트를 해주지 않으면 적용할 수 없다는 것도 있습니다. 다시말해 MySQL 5.8 버전이 나와도 RDS 에서 제공해주지 않으면 사용할 수 없다는 것입니다.
본 포스팅에서는 DB를 Multi-AZ에 배포합니다.(포스팅 상단 아키텍처 참고) 이 옵션을 쓰기 위해서는 Dev/Test 또는 Production 템플릿을 사용해야합니다.
아래 Settings 는 자유롭게 설정해주세요.
1. DB Instance Size
RDS 는 관리형 서비스입니다.
그렇기 때문에 EC2 처럼 인스턴스를 직접 관리하고 트러블슈팅하고, 관제를 빡빡하게 해주어야 할 필요는 없습니다.
하지만 관리를 AWS 가 해주는 것 뿐이지, 결국 서버 위에서 돌아가는 자원입니다.
EC2 에 t 계열의 타입이 있던 것처럼 DB Instance 도 타입이 있습니다. 일반적으로는 m 타입을 쓰며 메모리 최적화 타입인 r 클래스, 성능 버스터가 가능한 t 클래스도 사용이 가능합니다.
여기서는 기본 설정대로 가겠습니다.
2. Storage
EC2 설정 때와 동일한 것이 느껴지시나요? 기본으로 두고 넘어가겠습니다.
아래 Storage autoscaling 은 체크하지 않겠습니다.
RDS 는 Multi-AZ 배포를 지원합니다.
현재 사용하고있는 Master DB가 장애나더라도 Stand-By되어있단 다른 가용영역의 DB를 통해 자동으로 failover를 수행해줍니다.
아키텍처에서 위와 같이 두 AZ에 DB를 배치한 이유입니다.
해당 옵션을 체크합니다.
위와 같이 지정하고 아래 옵션은 그대로 두고 넘어가겠습니다.
private subnet에 위치하는 db 인스턴스를 보호하기 위해 publicly accessible 옵션을 No 체크한 것에 집중해주세요. 이 DB 인스턴스는 오직 프라이빗 아이피만 가지게됩니다.
Create 후 수초 ~ 수분 기다려줍니다.
기다리는 동안 위에서 생성하기만 했던 aws-beginner-db-sg 를 수정해봅시다.
EC2 > SecurityGroups > aws-beginner-db-sg Inbound Edit 선택
db 인스턴스에 접속하는 케이스는,
1. bastion host 터널링을 통해 로컬에서 직접 접속
2. autoscaling group(어플리케이션단)에서 DB 데이터 호출
두가지로 나눌 수 있습니다.
이를 보안그룹에 적용하면, 아래와 같이 bastion 보안그룹, asg 보안그룹을 통해 표현할 수 있습니다.
계속 그랬던 것처럼 "보안그룹 아이디"를 적극 활용해주세요.
RDS 상태가 Available 이 되면 MySQL Workbench 로 접속해보겠습니다.
bastion server 와의 SSH 연결을 통해 private 한 DB 인스턴스에 접속하는 것을 짚고 넘어갑니다.
RDS는 가변적인 IP를 제공하지 않고 고정된 EndPoint 를 제공한다는 것도 알아둡니다.
이렇게 Database까지의 세팅을 마쳤습니다.
이 상태에서 web server에 배포된 애플리케이션은 별다른 조치 없이도 RDS에 접근이 가능해집니다. 다시말해, application.yml 에 AWS 액세스키를 넣을 필요가 없다는 뜻입니다.
실제로 로컬PC 에는 Key를 .aws > .credentials 에 넣어서 접근하지만, VPC 내부의 모든 리소스는 그런 조치가 필요가 없습니다.
모든 접근은 Role과 보인그룹( + 라우팅 정책 등등 ) 으로 제한하기 떄문입니다.
여기까지 AWS 에서 세팅할 수 있는 가장 기본적인 인프라 구조였습니다.
