<개요>
우리가 사용하였던 EBS라는 현재 사용하는 저장소와, 이제 DB를 따로 떼서 관리해줄 RDS에 대한 개념을 정리하고자 한다.
1.) EBS란?
컴퓨터 본체를 보면, CPU와 램카드, 그래픽카드, SSD, HDD가 다같이 장착되어 컴퓨터가 돌아가게 된다.
EC2 인스턴스가 연산에 관한 (CPU, 메모리 등) 처리를 한다고 하면, 데이터를 저장하는 역할(SSD, HDD)은 바로 EBS가 한다고 보면 된다.
즉, EBS는 클라우드에서 사용하는 가상 하드디스크(HDD)라고 말할 수 있다.
EBS는 AWS 클라우드의 Amazon EC2 인스턴스에 사용할 영구 블록 스토리지 볼륨을 제공한다.
그리고 단 몇분 내에 사용량을 많게 또는 적게 확장할 수 있으며, 프로비저닝(빌리는 행위)한 부분에 대해서만 저렴한 비용을 지불 할 수 있다.
2.) EBS ↔ EC2 연결 특징
EBS의 가장 큰 특징은 EC2 인스턴스가 종료되어도 별개로 작동하여 유지가 가능하다는 점이다.
보통 컴퓨터 본체가 꺼지면 하드도 꺼져 당연히 이용을 못하겠지만, EBS는 네트워크로 별개로 연결된 서비스이기 때문에 가능한 것이다.
그래서 만일 잠시 인스턴스의 처리 기능이 필요하지않고 저장 장치 기능만 필요할때는, 인스턴스를 정지시켜도 EBS는 독립적으로 살아있기 때문에 스토리지 기능만 이용하는데 인스턴스의 추가 요금을 내지 않아도 된다.
인스턴스 교체가 유연하다
집 컴퓨터 같은 경우 CPU를 i9으로 업그레이드 한다고 하면 컴퓨터를 끄고 본체를 뜯어서 교체해줘야 하지만, 네트워크로 연결된(묶여있는) 인스턴스와 EBS는 단순히 인스턴스만 다른걸로 EBS와 재연결만 시키면 되기 때문이다.
하나의 EBS를 여러 EC2에 장착 가능
거꾸로 하나의 EBS를 여러 EC2 장착(EBS Multi Attach) 가능하기도 하다. 여러 컴퓨터가 있으면 하나의 하드를 공용 저장소로 사용하는 원리이다.
이것은 당연히 물리적인 컴퓨터에서는 불가능하지만 네트워크(클라우드)에서만 가능한 특징인 셈이다.
AZ(가용 영역) 제한
EBS는 EC2와 같은 가용영역(AZ)에 존재한다. AZ가 같아야 연결 및 통신이 빠르기 때문이다.
만일 다른 AZ로 생성해서 EC2에 붙이려고 한다면 에러가 나게 된다.
3.)EBS 볼륨(Volume)이란?
EBS로 생성한 디스크 하나하나 저장 단위를 말한다.
EBS 볼륨을 인스턴스에 연결한다는 말은 EC2에 물리적 하드 드라이브처럼 사용하겠다는 뜻이다.
쉽게 말하자면, 윈도우에서 흔히 볼수 있는 C 드라이브, D드라이브는 각각 디스크이며 볼륨이라고 보면 된다.
EBS 볼륨 유형 타입
EBS 타입이란 시중에서도 같은 하드 저장 디스크라도 SSD와 HDD로 나뉘고 용량에 따라 성능과 가격이 차이나는 것처럼, EBS도 각각 타입으로 나뉘놓은 것이다.
EBS는 총 5가지 타입을 제공하는데, 다음과 같다.
| 타입 | 범용타입 | 프로비저닝 된 IOPS | troughput 최적화 HDD | Cold HDD | 마그네틱 |
|---|---|---|---|---|---|
| 이름 | GP3 | IO2 | ST1 | SC1 | Standard |
| 용량 | 1GB~16TB | 4GB~16TB | 500GB~16TB | 500GB~16TB | 1GB~1TB |
| 사용 | 일반 범용 | IOPS가 중요한 어플리케이션/데이터베이스 | 쓰루풋이 중요한 어플리케이션/하둡/OLAP 데이터베이스 등 | 파일 저장소 | 백업/비 주기적인 데이터 액세스 |
| MAX IOPS | 16,000 | 64,000 | 500 | 250 | 40~200 |
각 하드의 성능은 용량과 MAX IOPS 수치를 보면 된다.
IOPS 수치가 높을수록 데이터 통신이 빠르다고 보면 된다. 그래서 프로비저닝 된 IOPS(64,000)이 가장 빠르고 좋다.
일반적으로 범용타입인 GP3를 선택하면 되지만, 자신은 요금을 극도로 아끼겠다 하면 마그네틱을 사용하면 된다.
4.) EBS와 Instance Storage 비교
EC2 인스턴스의 저장 타입은 대표적으로 두가지가 있다. 앞서 배운 EBS 기반과 그리고 인스턴스 저장 기반이다.
EBS 기반
- EC2가 EBS와 네트워크로 연결
- 그래서 속도가 느림
- 대신 인스턴스가 삭제되더라도 EBS는 남아있음 (영구적 스토리지)
- 하나의 인스턴스에 연결한 EBS 볼륨을 따로 분리해서 다른 인스턴스에 연결 가능 (마치 USB를 뺐다 넣듯이)
인스턴스 저장 기반 (Instance Storage)
- EC2 안에 storage가 들어있음 (네트워크 연결X)
- 그래서 속도가 빠름
- 안에 들어있는 형태이니, 인스턴스가 삭제되면 storage도 같이 삭제 됨
- EBS처럼 스토어를 분리해서 다른 인스턴스에 연결 불가능
- 보통 영구적이지 않은 데이터를 저장 (ex. 캐시 데이터)
EC2를 생성할때, EC2 타입을 고르는 항목에서 인스턴스 스토리지 항목에 EBS 전용과 1 x 100 (SSD)라고 써져있는 유형들을 볼 수 있을 것이다.
EBS 전용은 말 그대로 스토리지를 EBS로만 사용할수 있는 EC2 인스턴스 타입이라는 뜻이며, (SSD)라고 명시되어있는 것이 인스턴스 스토리지를 따로 가지고 있다는 뜻이다.
5.) EC2에 EBS Volume 추가하기
1. EBS 볼륨 만들기
지금까지 EC2 인스턴스를 생성할때 EBS 볼륨을 같이 설정해서 만들었다면, 이번에는 이미 생성된 EC2 인스턴스에 직접 EBS 볼륨을 추가해서 연결하는 방법을 알아보자.
EC2 대시보드 좌측 메뉴에서 Elastic Block Store > 볼륨으로 이동한 뒤, 우측 상단의 볼륨 생성 버튼을 클릭한다.
볼륨 설정
- 볼륨 유형: 마그네틱(표준) — 요금 절약을 위해 선택
- 크기(GiB): 2 — 최소 크기로 설정
- 가용 영역:
ap-northeast-2c— 연결할 EC2 인스턴스가 위치한 AZ와 반드시 일치시켜줘야 한다 - 태그: Key =
Name, Value =MyVolume2
2. EBS 볼륨을 EC2(리눅스)에 추가하기
볼륨이 생성되면 볼륨 목록에서 사용 가능 상태를 확인할 수 있다.
해당 볼륨을 선택한 뒤, 우측 상단 작업 드롭다운에서 볼륨 연결을 클릭한다.
볼륨을 인스턴스에 연결했으면, 필히 인스턴스를 재시작을 해주어야 볼륨 추가 적용이 된다.
3. EBS 볼륨 연결 확인하기
ls -al /dev/xvd* 명령이나 lsblk 명령어를 입력하면 연결된 디스크를 확인할 수 있다.
새로 연결한 /dev/xvdb라는 볼륨이 보인다.
$ ls -al /dev/xvd* # 디렉토리 조회
$ lsblk # 파일 시스템 조회💡 Tip: 만일 디바이스 명을
/dev/sdf로 지정했다면, 최신 Linux 커널로 인해 내부적으로 xvdf로 바뀌게 된다. 따라서 장치명이/dev/xvdf로 나오게 된다.
4. EBS 볼륨을 파일시스템 포맷하기
착각하기 쉬운게 /dev/xvdb는 디렉토리가 아니다.
리눅스에서 /dev는 단순히 외부 디바이스, 하드를 모아둔 곳이지, 하드(EBS 볼륨)를 리눅스에 연결했다고 해서 바로 D: 드라이브 처럼 저장디스크를 바로 사용할수 있는 것이 아니다.
이를 파일시스템으로 포맷해줘야 컴퓨터에서 하드를 쓸수있게 된다.
파일 시스템이란?
저장장치에 파일을 어떻게 쓰고, 관리하고, 찾고, 읽을 것인지에 대한 규칙이다. 이 체계가 있어야만 리눅스에서 파일을 읽고 쓸 수 있게된다.비유: 하드디스크 = 도서관, 파일시스템 = 도서검색대, 파일 = 책, 데이터 = 원하는 내용
파일 시스템 종류
- Linux: ext, ext2, ext3, ext4, xfs
- Windows: FAT12, FAT16, FAT32, exFAT, NTFS
- Mac: HFS, HFS+
file -s "장치명" 명령어를 이용하여 볼륨에 파일시스템이 있는지 확인한다. 값이 data라고 나타난다면 파일시스템이 존재하지 않는 것이다.
$ file -s /dev/xvdb파일시스템이 없다면, 다음 명령어로 ext4 파일시스템으로 포맷해준다.
$ sudo -s # 루트 권한 획득
$ mkfs -t ext4 /dev/xvdb # 해당 볼륨을 파일시스템으로 포맷6.) AWS RDS(Relational Database Service) 정리
이제 DB를 따로 떼서 관리해줄 RDS를 사용하여 보자.
DB를 AWS에 올리는 2가지 방식
| 항목 | 1. RDS 사용 | 2. EC2에 MySQL 직접 설치 |
|---|---|---|
| 설정 난이도 | 중간 (AWS 콘솔에서 생성) | 낮음 (apt install mysql) |
| 메모리 | EC2 메모리 여유 생김 | EC2 1GB를 Spring Boot + MySQL이 나눠씀 |
| 안정성 | 높음 (AWS 관리형) | 메모리 부족 시 OOM 위험 |
| 비용 | 12개월 후 ~$15~20/월 | 추가 비용 없음 (영구 무료) |
| 적합한 경우 | 포트폴리오, 실제 서비스 운영 | 학습용, 테스트용, 단기 프로젝트 |
RDS(Relational Database Service)란?
AWS RDS란 관계형 데이터베이스를 간편하게 클라우드에서 설정, 운영, 확장이 가능하도록 지원하는 웹 서비스이다.
RDS는 MySQL이나 오라클 같은 데이터베이스의 설치, 모니터링, 백업, 알람 등 관리를 대신해주며, 하드웨어 프로비저닝, 데이터베이스 설정, 패치 및 백업과 같이 잦은 운영 작업을 자동화하여 비용 효율적이고 크기 조정 가능한 DB 서비스를 제공한다.
따라서 RDS를 통해 개발자는 DB 인프라를 구성하는데 힘을 들이지 않고, 개발이라는 본질적인 작업에 집중할 수 있게되는 장점이 있다.
RDS와 EC2의 관계
물론 EC2 자체가 컴퓨터니까 EC2 인스턴스에 직접 데이터베이스를 설치해서 사용해도 된다.
하지만 AWS RDS는 EC2에 RDB(관계형 데이터베이스)를 직접 구축하여운영할 때보다 더 많은 부분을 자동으로 관리할 수 있어 편리하기 때문에 많이 애용된다.
Amazon EC2에서 직접 관리해야 하는 항목: 앱 최적화, 스케일링, 고가용성 처리, 데이터베이스 백업, DB S/W 패치, DB S/W 설치, OS 패치, OS 설치, 서버 설치 및 장비, 랙 & 스택, 전력/냉난방 제어/회선
AWS RDS에서 자동 관리되는 항목: 앱 최적화를 제외한 스케일링, 고가용성 처리, 데이터베이스 백업, DB S/W 패치, DB S/W 설치, OS 패치, OS 설치, 서버 설치 및 장비, 랙 & 스택, 전력/냉난방 제어/회선
→ RDS를 사용하면 스케일링부터 백업까지 AWS가 자동으로 관리해주므로, 개발자는 앱 최적화에만 집중하면 된다.
RDS의 주요 특성
- RDS의 데이터베이스 제공 방식은 EC2와 비슷하다. EC2 인스턴스를 생성해서 컴퓨팅을 사용하듯이, RDS 인스턴스를 생성해서 DB를 사용하는 원리이다.
- 하지만 EC2같이 유저가 시스템에 직접 로그인은 불가능하다. RDS 인스턴스의 OS패치, 관리 등은 AWS가 전담 한다.
- RDS는 데이터베이스 모니터링 기능을 지원해주는데, DB에서 발생하는 여러 로그 (Error Log, General Log 등)를 CloudWatch와 연동하여 확인도 가능하다.
- RDS는 기본적으로 VPC 안에서 동작하며, 기본적으로 public IP를 부여하지 않아 외부에서 접근 불가능하다.
- 다만, 설정에 따라 public으로 오픈 가능하며 대신 로드밸런서 같이 DNS로만 접근이 가능하다.
- VPC 내에서 동작하는 서비스이니 당연히 서브넷과 보안그룹 지정도 필요하다.
- RDS 인스턴스를 생성할때도 인스턴스 타입을 지정해주어야 하며, 스토리지는 EBS를 그대로 활용하기 때문에 EBS 타입의 선택도 필요하다.
- RDS는 유동적으로 데이터 저장소 용량을 증설하는게 아닌, 생성시 EBS의 용량을 지정해서 생성한다. (추후에 용량 증설 가능)
cf) AWS 데이터베이스 서비스인 Amazon Aurora는 용량지정 X, 사용한만큼만 비용 지불
파라미터 그룹 (Parameter Group)
RDS의 가장 큰 특징은 파라미터 그룹(Parameter Group) 시스템인데, 이는 DB의 설정값들을 모아 그룹화한 개념이다.
이 DB 설정들을 모은 그룹을 각 DB 인스턴스에 적용시켜 DB의 설정값을 적용하는 시스템이다.
왜냐하면 위에서 말했듯이 직접 RDS 인스턴스 수정이 불가능 하기 때문에 이런 우회적인 방법으로 설정값을 세팅하는 원리이다.
💡 Tip: AWS 프리티어로는 RDS를 12개월동안 단일 AZ, db.t2.micro 인스턴스를 750시간 무료 사용할 수 있다.
RDS 데이터베이스 종류
RDS에서는 Amazon Aurora, PostgreSQL, MySQL, MariaDB, Oracle, MS SQLServer 총 6개의 데이터베이스 엔진 중에서 원하는 DBMS를 선택할 수 있다.
또한 AWS Database Migration Services를 사용하여 기존 데이터베이스를 Amazon RDS로 손쉽게 마이그레이션 또는 복제 할 수 있다.
각 DB 엔진 특징
Amazon Aurora: MySQL 및 PostgreSQL호환 관계형 데이터베이스로, 오픈 소스 데이터베이스의 간편 성과 비용 효율성을 결합한 것이다. 표준 MySQL보다 5배, PostgreSQL보다 3배 빠르다고 한다. 상용 데이터베이스의 보안, 가용성 및 안전성을 1/10의 비용으로 제공하기도 한다.
PostgreSQL: 오픈 소스 관계형 데이터베이스 중 기능도 많고 성능도 좋은 거의 원탑의 데이터베이스이다.
MySQL: 세계적으로 가장 많이 사용되는 오픈 소스 관계형 데이터베이스다. Amazon RDS를 통해 비용 효율적이고 크기 조정이 가능한 MySQL 서버를 몇 분 안에 생성할 수 니다.
MariaDB: MySQL을 개발한 개발자가 만든 오픈 소스 관계형 데이터베이스이다. MySQL 업그레이드 판이라고 봐도 된다.
Oracle: 오라클사의 유료 관계형 데이터베이스로서, RDS를 사용해 클라우드에서 손쉽게 배포, 설정, 운영 할 수 있는 완전 관리형 상용 데이터베이스이다. 다만 유료 데이터베이스라 라이선스 비용이 든다.
SQL Server(MSSQL): Microsoft에서 개발한 관계형 데이터베이스 관리 시스템으로 Amazon RDS를 통해 손쉽게 배포, 운영, 확장이 가능하다.
7.) RDS의 특징 & 기능
1. 관리 부담 감소
- 사용 편의성: 몇 분 이내에 데이터베이스 인스턴스를 시작하고 애플리케이션을 연결할 수 있다. DB 파라미터 그룹을 사용하면 데이터베이스를 세부적으로 제어하고 튜닝할 수도 있다.
- 자동 소프트웨어 패치: RDS는 최신 패치를 통해 배포를 지원하는 관계형 데이터베이스 소프트웨어가 최신 상태로 유지되도록 한다. 패치 여부와 시기를 선택적으로 제어할 수 있다.
- 모범 사례 권장 시스템: RDS에서는 데이터베이스 인스턴스의 구성과 사용 지표를 분석하여 모범 사례 지침을 제공한다.
2. 확장성
- 즉각적인 컴퓨팅 규모 조정: 배포에 사용할 컴퓨팅 및 메모리 리소스를 최대 vCPU 32개와 RAM 244G의 범위 내에서 확장하거나 축소할 수 있다.
- 간편한 스토리지 규모 조정: 스토리지에 대한 요구 증가량에 따라 추가 스토리지를 프로비저닝할 수도 있다. DB 가동 중단 없이 즉시 스토리지 확장이 가능하다.
- 읽기 전용 복제본 시스템: DB 인스턴스의 복제본을 하나 이상 생성하여 대량의 애플리케이션 읽기 트래픽을 처리할수 있는 기능을 제공 한다.
3. 가용성 및 내구성
- 자동 백업: RDS는 데이터베이스와 트랜잭션 로그를 백업하고 사용자가 지정한 보존 기간 동안 이를 모두 저장할 수 있다. 이를 통해 데이터베이스를 보존 기간 중 어느 시점(초 단위)으로나 복원할 수 있다(최근 5분 전까지 가능). 자동 백업 보존 기간은 최대 35일로 구성할 수 있다.
- 데이터베이스 스냅샷: 사용자는 원하는 경우 언제든 데이터베이스 스냅샷으로 새 RDB 인스턴스를 생성할 수 있다.
- 다중 AZ 구성 배포: 다중 AZ 구성은 현재 서비스되는 RDB에 문제가 되어도 다른 AZ에 있는 RDB로 빠르게 장애 복구를 할수 있다. 가용성 및 내구성을 높여주므로 프로덕션 데이터베이스 워크로드에 적합하다.
- 자동 호스트 교체: 하드웨어에 장애가 발생할 경우, 배포를 지원하는 컴퓨팅 인스턴스를 자동으로 교체한다.
4. 보안
- 저장 데이터 및 전송 데이터 암호화: RDS를 사용하면 사용자가 AWS Key Management Service(KMS)를 통해 관리하는 키를 사용해 데이터베이스를 암호화할 수 있다. 자동 백업, 읽기 전용 복제본 및 스냅샷과 마찬가지로 기본 스토리지에 저장된 데이터가 암호화 된다.
- 네트워크 격리: VPC에서 데이터베이스 인스턴스를 실행하여 방화벽 설정을 구성하고 데이터베이스 인스턴스에 대한 네트워크 액세스를 제어할 수 있다.
- IAM 리소스 수준 권한: RDS는 IAM과 통합되어 사용자 및 그룹이 특정 Amazon RDS 리소스(데이터베이스 인스턴스, 스냅샷, 파라미터 그룹 및 옵션 그룹)에서 수행할 수 있는 작업을 제어하는 기능을 제공한다.
5. 관리 효율성
- 모니터링 및 지표: RDS는 추가 비용 없이 데이터베이스 인스턴스에 대한 Amazon CloudWatch와 연동해 지표를 제공한다. RDS 관리 콘솔을 사용하면 컴퓨팅/메모리/스토리지 용량 사용률, I/O 작업, 인스턴스 연결 등 주요 작업 지표를 보고 성능 문제를 신속하게 감지할 수 있다.
- 이벤트 알림: Amazon SNS를 통해 데이터베이스 이벤트를 이메일이나 SMS 텍스트 메시지로 알려줄 수 있다.
6. 비용 효율성
- 사용한 만큼만 비용 지불
- 예약 인스턴스: 1년 또는 3년 약정 기간에 DB 인스턴스를 예약하여 온디맨드 대비 시간당 요금을 대폭 할인받을 수 있다. 3년 약정이면 거의 56%이상 저렴하다.
- 인스턴스 중지 및 시작: Amazon RDS를 활용하면 한 번에 최대 7일까지 데이터베이스 인스턴스를 쉽게 중지했다 시작할 수 있다. 따라서 데이터베이스를 상시 구동하지 않아도 되는 개발 및 테스트 작업에 데이터베이스를 쉽고 저렴하게 이용할 수 있다.
8.) RDS 백업 시스템
자동 백업
자동 백업(Automated Backups) 줄여서 AB는 매일마다 스냅샷과 트랜잭션 로그를 참고하여 자동으로 백업을 해준다.
RDS에서는 디폴트로 AB 기능이 설정되어 있다.
그리고 AB를 통해 데이터베이스를 Retention Period(1~35일) 안의 과거 특정 시간으로 되돌아갈 수도 있다.
단, 풀백 동작은 과거 상태로 그대로 돌아가는게 아닌, 다른 DB 인스턴스를 새로 생성해서 스냅샷을 적용 시키는 형식임을 유의하자.
RDB 백업 정보는 S3에 저장되며, AB동안 약간의 I/O suspension(딜레이)이 존재할 수 있다.
그나마 Multi-az로 하면 Standby를 통해 백업을 수행하기 때문에 딜레이가 덜하다.
💡 Standby 란?
돌발 사태로 예정된 기능이 이뤄지지 못할 경우를 대비한 '임시'를 뜻함
수동 백업 (DB 스냅샷)
AB(자동 백업)이 자동으로 스냅샷을 떠서 백업하는 것이라면, 수동 백업은 유저 혹은 다른 프로세스로부터 요청에 따라 만들어지는 DB 스냅샷이다.
즉, EC2 스냅샷을 뜨듯이 사용자에 의해 수동적으로 진행되는 백업이다.
만약 원본 RDS를 삭제한다고 하더라도, 스냅샷은 S3 버킷에 그대로 존재한다. 따라서 스냅샷만으로 RDS 인스턴스를 복원시킬 수 있다.
반대로 AB 백업 기능은 인스턴스를 삭제할 때 스냅샷도 모두 없어진다는 특징이 있다.
스냅샷의 복구는 항상 새로운 DB Instance를 생성하여 수행되며, 만약 데이터베이스를 복구해야 한다면, 새로운 DB를 만들고 기존 DB의 연결을 끊고 새로 만든 DB에 연결해 주는 작업이 필요하다.
RDS 백업 복원시 도메인 변경
원본 RDS 인스턴스를 가지고 새로운 DB를 복원시 새로운 인스턴스와 Endpoint가 생성된다.
원본 DNS는 앞에 original인 반면, 복원된 것은 앞에 restored가 붙게된다.
원본: original.ap-northeast-2.rds.amazonaws.com
복원: restored.ap-northeast-2.rds.amazonaws.comRDS 가격 모델
- 컴퓨팅 파워 + 스토리지 용량 + 백업 용량 + 네트워크 비용을 모두 합쳐서 지불
- EC2 인스턴스를 구매해 사용했던 것처럼, RDS에는 Reserved Instance(RI)를 구매해서 사용하는 시스템이다.
- EC2와 마찬가지로 일정기간을 계약하여 저렴한 가격에 서비스를 이용
- 3년 약정이면 거의 56%이상 저렴
- 단, 인스턴스 타입 변경이 쉽지않기 때문에 수요에 대한 신중하게 결정
RDS 요금 정책
| 요금 발생 유형 | 요금 정책 |
|---|---|
| 온디맨드 | 인스턴스에서 실행한 컴퓨팅 파워에 대해서 시간당 요금 지불 |
| 예약 | 온디맨드보다 저렴. 1년~3년 약정 기간에 DB 인스턴스 예약 |
| DB Storage | 범용(SSD) 스토리지: 프로비저닝한 스토리지에 대해 요금 청구 (I/O는 요금 청구 없음). 프로비저닝 IOPS(SSD) 스토리지: DB에 필요한 I/O 용량을 지정하거나 프로비저닝 가능. 프로비저닝한 처리량 및 스토리지에 대해 비용 청구(I/O 요금청구 없음) |
| 백업 스토리지 | 리전별로 할당. 리전 전체 데이터베이스 스토리지의 최대 100프로에 해당하는 백업 스토리지는 추가비용 없음. DB 인스턴스 종료 후에 백업스토리지에 월별 GiB당 요금청구. 추가 백업 스토리지에는 월별 GiB당 요금 청구 |
| 스냅샷 내보내기 | 스냅샷 용량에 따라 요금 지불. 동일한 스냅샷에서 추가로 데이터 내보내는건 요금 없음. RDS내에서 데이터 내보내거나 S3로 내보낸 |
| 데이터 전송 | 동일한 가용 영역에서 Amazon RDS와 Amazon EC2 인스턴스 간에 전송된 데이터는 무료. 같은 리전의 서로 다른 가용 영역에서 Amazon EC2 인스턴스와 Amazon RDS DB 인스턴스 간에 전송된 데이터의 경우, 양쪽 모두에 Amazon EC2 리전 데이터 전송 요금이 청구 |
RDS 구성 아키텍처
데이터베이스는 관리가 중요하다.
만일 어느 데이터베이스가 장애가 나면 재빨리 다른 데이터베이스로 옮겨 서비스를 지속하는 등 고가용적인 관리가 필요하다.
또한 트래픽이 몰려 데이터베이스 서버가 터지는걸 대비해 분산 기법도 이용해야 한다.
AWS RDS는 데이터베이스를 보다 효율적으로 관리할수 있게 하는 인프라 아키텍처 방법 3가지를 제공한다.
| Multi-AZ | Multi-Region | Read Replica | |
|---|---|---|---|
| 목적 | 고가용성 | DR/로컬 퍼포먼스 | 확장성/성능 |
| 복제방식 | Sync | Async | Async |
| 액티브 | Primary DB만 읽기/쓰기 가능 | Read만 가능 | Read만 가능 |
| 백업 | 자동백업(Standby기준) | 자동 백업 가능 | 기본적으로 백업 x |
| 엔진 업데이트 | Primary만 업데이트 | 각 리전별로 다른 업데이트 | DB별로 다른 업데이트 |
| FailOver | 자동으로 Standby로 Failover | 수동으로 Failover | 수동으로 Failover |
RDS Multi AZ 구조
RDS 멀티 AZ는 위 사진에서 보듯이, 두개 이상의 AZ에 걸쳐 데이터베이스를 구축하고 원본과 다른 DB(Standby)를 자동으로 동기화(Sync)하는 구조이다.
Multi AZ는 AWS에 의해서 자동으로 관리가 이루어 진다.
만약 RDS DB를 만들고, DB에 특정 레코드를 insert 할 시, 다른 AZ(Availability Zone)에 똑같은 복제본이 만들어지게 된다.
그리고 유사시 우리가 현재 사용하고 있는 메인 DB에 문제가 생길 경우 RDS는 이를 즉시 발견하고 다른 AZ에 만들어진 복제본을 원본 DB를 숨겨시켜 그대로 사용하게 된다. 이를 Disaster Recovery(재해 복구)라고 부른다.
마무리
이번 포스팅에서는 EBS의 개념과 EC2 연결 방법, 그리고 RDS의 개념과 특징, 백업 시스템, 가격 모델, 구성 아키텍처까지 정리하였다.
다음 포스팅에서는 실제로 RDS를 구축하고 EC2와 연결하는 과정을 다룰 예정이다.
