티스토리 뷰
Amazon RDS (Relational Database Service), Amazon DynamoDB 그리고 AWS DMS (Database Migration Service)
GodNR 2019. 7. 7. 09:21이번 포스팅에서는 관계형 데이터베이스인 Amazon RDS와 비 관계형 데이터베이스 DynamoDB에 대해 알아보겠습니다.
# 본 포스팅은 개인적으로 또는 회사 차원에서 진행한 TF의 다양한 학습 결과 그리고 Architecting On AWS 교육 등을 통해 습득한 지식을 리마인드하며 공유하는 것임을 알려드립니다.
데이터베이스의 경우 Scale-In / Scale-Out에 제약이 있어 대체로 Scale-Up / Scale-Down으로 용량을 산정하며, IOPS (Input/Output Operations Per Second) 기준으로 비용이 산정되는 경우가 많습니다.
사용자가 몰릴 경우를 대비하여 IOPS를 무작정 늘려 놓을 경우 비용 폭탄을 맞을 수 있다는 의미이죠.
따라서 AWS 서비스를 활용하여 Database를 구축할 경우 다음과 같은 고려사항에 유의해야 합니다.
먼저 처리량에 대한 고려입니다. 데이터베이스의 Scale-Out에 대한 고려가 대체로 불가능 하기 때문에 초기 전산 자원에 대한 고려가 여전히 중요합니다. 이를 기반으로 사용량의 증가 시 확장성은 고려할 수 있는지 등을 함께 고려하여 선정합니다.
다음으로 데이터베이스가 사용 할 스토리지 사이즈 및 종류는 이전 포스팅을 참고하시면 되겠구요.
저장할 객체의 크기 및 유형을 통한 선정 및 내구성, 가용성, 복구성을 위한 고려 등을 통해 데이터베이스의 종류를 선정하게 됩니다.
또한 데이터베이스 관리 주체를 어디로 넘길 것이냐에 따른 선정 기준을 고려해야 합니다.
AWS에서는 비관리형 데이터베이스, 관리형 데이터베이스, 완전 관리형 데이터베이스를 나누어 제공하고 있으며, 고객의 커스터마이징 수준과 관리의 주체 등이 선정 기준이 됩니다.
데이터베이스는 크게 다음과 같은 유형으로 나눠 볼 수 있습니다.
관계형 데이터베이스 |
비 관계형 데이터베이스 |
|
스키마 |
고정 : 엄격한 스키마 규칙으로 데이터의 품질 요구사항에 적용이 필요한 경우 |
동적 : Key-Value 형태로 JSON 형태로 관리 |
성능 고려사항 |
IOPS에 따른 과도한 읽기/쓰기에는 적합하지 않은 형태 |
Scale-Up 방식으로 확장이 가능하며, 보다 빠른 성능을 요구할 때 |
대표 Component |
MS SQL Server, Oracle DB, MySQL 등 |
MongoDB, Cassandra, Redis 등 |
데이터 스토리지 |
행 및 열 |
Key-Value, 문서 및 그래프 |
쿼리 형태 |
SQL 기반 쿼리 |
문서 수집에 집중 |
확장성 |
수직적 (Scale-Up / Scale-Down) |
수평적 (Scale-In / Scale-Out) |
자 그럼 본격적으로 데이터베이스를 살펴보도록 하겠습니다.
첫번째로 관계형 데이터베이스입니다.
Amazon RDS
- Amazon RDS는 완전 관리형 관계형 데이터베이스로 수직적 확장을 지원합니다.
- 앞서 살펴본데로 몇분만에 프로비저닝, 몇번의 클릭으로 수직 확장이 가능하며, 복잡하고, 결합적이며, 구문 규칙이 필요할 경우 관계형 데이터베이스를 적용합니다.
Amazon Aurora
- 또 다른 대표적인 완전 관리형 관계형 데이터베이스에는 Amazon Aurora가 있습니다.
- MySQL 처리량의 최대 5배, PostgreSQL 3배의 고성능을 자랑합니다.
- 3개의 가용영역에 6개의 데이터 복제본을 유지할 수 있어 내결함성은 0%에 가깝습니다. 전쟁이나 천재지변이 발생하지 않는한..
두번째로 비관계형 데이터베이스입니다.
Amazon DynamoDB, Amazon ElasticCache, Amazon Neptune등이 있으며, 그 중 대표적인 완전 관리형 비관계형 데이터베이스는 Amazon DynamoDB를 들 수 있습니다.
Amazon DynamoDB
- 기본 복제 3Copy로 가용성을 확보합니다.
- 이벤트 중심프로그래밍 (서버리스 컴퓨팅)이 가능합니다.
- 대용량의 단순 데이터를 보유하는 용도나 신속하고 간편하게 확장 가능해야 하는 경우 즉 마이크로서비스 환경에 매우 적합한 구조입니다. 또한 복잡한 조인이 필요하지 않을 경우에 사용됩니다.
- DynamoDB의 경우 글로벌 테이블을 사용하여 Multi Master를 구성할 수 있습니다.
서로 다른 리전에 글로벌 테이블을 Replication하는 방식으로 Master를 유지할 수 있으며, 이는 글로벌 게임사들의 실시간 게임순위 공개 등에 많이 사용 됩니다.
임시 데이터 저장 용도로도 많이 사용되어 장바구니/찜/즐겨찾기 등의 항목에서도 많이 사용되는 형태입니다.
- DynamoDB의 Master Node 간의 일관성을 관리하기 위해서는 RCU / WCU를 어떻게 관리할 것이가에 따라 결정이 되며 이는 비용과 직결되어 있습니다.
# RCU(Read Consistency Unit 초당 4K) / WCU(Write Consistency Unit 초당 1K)
Eventualy Consistency (최종 일관성) : 반영이 되기까지의 Delay 시간을 그냥 묵인하는 처리 방식 (Lock 메카니즘을 사용하지 않음) / RCU / WCU 2배씩 사용하고 묵인하는 방식 / 비용 저렴
Strong Contsistency (강력한 일관성) : RCU / WCU 기준대로 / 비용 그래도 차지 됨
마지막으로 살펴볼 정보는 보안 관리입니다. 데이터베이스의 핵심이라고 할 수 있죠. 데이터를 저장하는 주체이기 때문에 데이터베이스 보안이 취약할 경우 심각한 문제를 발생 시킬 수 있음을 명심해야 합니다.
Amazon RDS
- Amazon RDS의 보안그룹은 기본 모두 차단 액세스입니다. 접근을 허용하기 위해서는 네트워크 IP 또는 EC2 보안그룹을 해제 해 주어야 합니다.
- DB 자체에 대한 액세스, 저장 시 암호화, 전송 중 암호화, 이벤트 알림 등을 통해 보안을 강화할 수 있습니다.
Amazon DynamoDB
- DymanoDB에서는 데이터베이스의 테이블에서 항목, 심지어 속성까지 액세스 권한을 부여할 수 있습니다.
- 또한 저장 시 암호화 및 SSL/TLS 통신을 지원합니다.
데이터베이스 마이그레이션
지금까지는 Amazon에서 서비스하는 관계형 / 비 관계형 데이터베이스에 대해 살펴보았습니다.이번에는 데이터베이스의 마이그레이션은 어떻게 수행되는지 살펴보겠습니다.
AWS Database Migration Service (AWS DMS)
- Amazon DMS를 사용하면 AWS / On-premise 간의 마이그레이션이 가능해 집니다.
- AWS Schema Conversion Tool을 사용하여 마이그레이션을 진행해야 합니다.
AWS->AWS, AWS->On-Prem, On-Prem->AWS 간의 마이그레이션을 통해 데이터베이스를 전환 관리할 수 있습니다.
- S3에서 살펴본 것과 같이 대용량의 데이터를 이전하여 마이그레이션이 진행되어야 할 경우 AWS Snowball Edge 서비스를 권장합니다. (마찬가지로 오프라인 서비스)
웹 애플리케이션 배포 실습
이번 포스팅의 궁극적인 목표는 Amazon RDS와 EC2 인스턴스를 연동하여 애플리케이션을 호출하는 로직을 구현하는 것입니다.
1. 보안 구성
- 보안 그룹은 하나 이상의 인스턴스에 대한 트래픽을 제어하는 가상 방화벽 역할을 수행합니다.
- 보안 그룹을 통해 기본 전체 차단으로 되어 있는 인바운드 트래픽을 오픈하여 서비스하는 용도로 구성하게 됩니다.
- 각각 웹 서버 용도의 보안 그룹과 데이터베이스 용도의 보안 그룹을 추가합니다.
Services → EC2 → 네트워크 및 보안 → 보안 그룹 → 보안 그룹 생성 |
보안 그룹 이름 |
AWS-WEB-SG |
보안 그룹 ID |
설명 |
HTTP, HTTPS |
Description |
인바운드 유형 HTTP |
80 Port / 소스 : 위치 무관 |
80 포트에 대한 인바운드 트래픽 허용 |
인바운드 유형 HTTPS |
443 Port / 소스 : 위치 무관 |
443 포트에 대한 인바운드 트래픽 허용 |
Database의 보안 그룹을 추가하기 전 접근 권한부여를 위한 AWS-WEB-SG의 그룹 아이디를 복사해 둡니다.
복사한 그룹 ID를 사용자 지정 인바운드 트래픽에 적용하며, AWS-DB-SG를 추가합니다.
보안 그룹 이름 |
AWS-DB-SG |
보안 그룹 ID |
설명 |
MySQL |
Description |
인바운드 유형 MySQL/Aurora |
3306 Port / 소스 : 위치 무관 |
3306 포트에 대한 웹 서버로부터의 (sg-066a1bd5352e59880)인바운드 트래픽 허용 |
지금까지 설계된 정보를 기반으로 보안 그룹의 흐름을 살펴보자면, 다음과 같습니다.
1) 인터넷 환경의 클라이언트는 HTTP, HTTPS 프로토콜을 통해 웹 서버로 요청합니다.
2) 웹 서버는 MySQL 서버인 DB 서버로 3306 포트를 이용하여 연결 요청합니다.
3) 이때 MySQL은 지정된 보안그룹을 사용하는 웹 서버의 요청이 아닐 경우 해당 요청을 거부합니다.
2. Amazon RDS 데이터베이스 생성
1) Amazon RDS 생성
Services → RDS → 데이터베이스 생성 |
2) MySQL 선택
3) 모드 선택
- 프로덕션 : Amazon Aurora 적용
- 프로덕션 : MySQL 적용 (다중 AZ 배포 및 프로비저닝된 IOPS 스토리지)
- 개발/테스트 : MySQL 적용 (RDS 프리티어)
본 장에서는 테스트 용도이므로 개발/테스트로 생성하겠습니다.
4) DB 세부 정보 지정
DB 인스턴스 클래스 |
db.t2.micro - 1vCPU, 1GiB RAM |
DB 인스턴스 종류 선택 |
DB 인스턴스 식별자 |
AWS-RDS-Instance |
RDS Name |
마스터 사용자 이름 |
nrson |
Master User Name |
마스터 암호 |
xxxxxxxx |
Master User Password |
암호 확인 |
xxxxxxxx |
Password Check |
5) 고급 설정 구성
Virtual Private Cloud (VPC) |
Default VPC |
RDS가 위치할 VPC 선택 |
VPC 보안 그룹 → 기존 VPC 보안 그룹 사용 |
AWS-DB-SG |
앞서 추가한 VPC 등록 |
데이터베이스 이름 |
AWS_RDS |
MySQL Database 이름 |
- 그 밖에도 암호화, 백업, 모니터링, 로깅, 유지 관리, 삭제 방지 등의 설정을 통해 보다 RDS를 고가용성으로 관리할 수 있습니다. 상세한 설정은 한번씩 추가해 보고 테스트 해보시기 바랍니다.
생성이 완료되면 다음과 같은 화면이 출력됩니다. 다만 실제 백그라운드로 DB Instance를 생성하는데에는 수분의 시간이 소요가 되니 잠시 대기후 정보를 확인하기 바랍니다.
3. Amazon EC2 웹 서버 생성
1) EC2 인스턴스 생성
Services → EC2 → 인스턴스 시작 |
2) AMI 선택
Amazon Linux 2 AMI (HVM), SSD Volume Type - ami-095ca789e0549777d 선택 |
3) 인스턴스 유형
t2.micro |
4) 인스턴스 세부 정보 구성
네트워크 |
Default VPC |
VPC 선택 |
서브넷 |
Public Subnet |
웹 서버는 공개된 영역에 위치하여 HTTP, HTTPS 서비스를 수행하므로 Public Subnet으로 등록 |
데이터베이스 이름 |
AWS_RDS |
MySQL Database 이름 |
- 추가로 인스턴스가 기동되는 시점에 수행할 동작에 대해 명시적으로 선언할 수 있는 User data (사용자 데이터)는 다음과 같이 입력합니다.
#!/bin/bash yum install -y httpd mysql amazon-linux-extras install -y php7.2 unzip inventory-app.zip -d /var/www/html/ wget https://github.com/aws/aws-sdk-php/releases/download/3.62.3/aws.zip unzip aws -d /var/www/html chkconfig httpd on service httpd start |
5) 보안 그룹 구성
스토리지와 태그는 확인만 진행하고 넘어가며, 보안 그룹 구성을 확인합니다.
앞서 추가한 AWS-WEB-SG를 선택하기 위해 기존 보안 그룹 선택을 누르시고 "AWS-WEB-SG"를 선택하여 인바운드 트래픽에 대한 설정을 검토합니다.
6) 인스턴스 시작하기
마지막으로 검토화면의 시작을 누르시면 Keypair 설정에 대한 부분이 나타납니다.
먼저 새 키 페어 생성을 진행합니다.
키 페어 이름을 입력하고 키 페어 다운로드를 클릭하면 접속에 사용할 수 있는 인증 키를 발급 받게 됩니다. 이후 인스턴스 시작 버튼을 클릭하면 손쉽게 인스턴스 생성을 완료할 수 있습니다.
4. 애플리케이션 테스트
정상적인 애플리케이션 테스트가 진행되는지 확인할 차례입니다.
먼저 웹 서버의 보안 그룹에 오픈했던 80 포트로 접근을 시도합니다.
웹 서버 접근 도메인은 다음 화면에서 확인할 수 있습니다.
해당 Public Domain 기반으로 브라우저에 호출을 시도하면 아래와 같은 화면이 출력되는 것을 볼 수 있습니다.
위 화면에 접속이 완료되면 이는 클라이언트가 웹 서버로 HTTP 요청을 통해 응답받은 결과라고 볼 수 있습니다.
5. 데이터베이스 연동 테스트
이제 웹 서버와 데이터베이스 간의 연동 테스트를 진행해 보겠습니다.
연동을 위해 필요한 정보는 Database Endpoint, Database Name, Database User, Database Password 입니다.
먼저 엔드포인트 URL은 다음 위치에서 확인할 수 있습니다.
Services → RDS → aws-rds-instance 선택 |
연결 & 보안 탭의 엔드포인트 정보를 저장합니다.
이 정보를 기반으로 Database에 Connection하는 로직을 구현하여 MongoDB에 Connection을 생성할 수 있습니다.
이때 앞서 설정한 것과 같이 AWS-DB-SG의 보안 그룹은 AWS-WEB-SG로의 인바운드만 허용된다는 규칙을 넣었으므로, DB로의 직접 요청은 불가능 하고 반드시 WEB Server를 통한 요청 구조로 접근해야 합니다.
자 오늘은 AWS Database에 대해 살펴보았습니다.
다양한 AWS 서비스 중 관계형, 비 관계형 데이터베이스에 대해 알아보았고, 직접 Web Server / Database Server를 구축하여 호출하는 과정까지 살펴보았습니다.
다음 시간에는 AWS의 핵심 중 하나인 AWS 네트워킹에 대해 알아보도록 하겠습니다.
'③ 클라우드 > ⓐ AWS' 카테고리의 다른 글
ELB, Amazon Route 53, Amazon 네트워킹 (VPC 피어링, VPC 엔드포인트) (0) | 2019.07.07 |
---|---|
Amazon VPC (Virtual Private Cloud), VPC Peering (0) | 2019.07.07 |
Amazon EC2(Elastic Compute Cloud), EBS(Elastic Block Store), Amazon EFS 및 Amazon FSx (0) | 2019.07.07 |
Amazon S3(Simple Storage Service) (0) | 2019.07.06 |
AWS WAF(Well-Architecture Framework) (0) | 2019.07.06 |
- Total
- Today
- Yesterday
- 마이크로서비스
- webtob
- nodejs
- Architecture
- git
- JEUS7
- jeus
- MSA
- 쿠버네티스
- openstack tenant
- TA
- 아키텍처
- aws
- wildfly
- node.js
- Docker
- kubernetes
- 마이크로서비스 아키텍처
- SWA
- OpenStack
- JEUS6
- JBoss
- openstack token issue
- k8s
- apache
- Da
- 오픈스택
- API Gateway
- SA
- aa
일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | |||||
3 | 4 | 5 | 6 | 7 | 8 | 9 |
10 | 11 | 12 | 13 | 14 | 15 | 16 |
17 | 18 | 19 | 20 | 21 | 22 | 23 |
24 | 25 | 26 | 27 | 28 | 29 | 30 |