[AWS] 05. RDS 관련 개념

# 학습 목표

• Cloud와 Deployment의 의미를 각각 알고, 서비스를 남에게 배포할 수 있다.
• 클라우드 컴퓨팅이 무엇인지 설명할 수 있다.
• 애플리케이션 배포가 어떻게 변화되어 왔는지 이해할 수 있다.
• AWS의 각 서비스가 어떤 목적에 부합하는지 이해할 수 있다.
• S3의 목적과, 정적 웹 사이트 배포 방법을 이해할 수 있다.
• EC2의 주요 용어를 이해할 수 있다. (AMI, 인스턴스, 인스턴스 유형, 스토리지 타입, 퍼블릭/프라이빗 IP)
• EC2의 인스턴스 시작/중지/종료에 대해 이해할 수 있다.
• RDS와 EC2에서의 MySQL 사용이 어떻게 다른지 이해할 수 있다.
• CloudFront의 목적을 이해할 수 있다.
• Auto Scaling의 특징 및 역할을 알 수 있다.
• 로드 밸런서 중 ELB, 그 중에서 Application Load Balancer의 목적을 이해할 수 있다.
• AWS 인프라 중 VPC에 대해서 이해할 수 있다.
• Route 53의 목적을 이해하고, 도메인을 연결해 HTTPS로 배포할 수 있다.
• 빌드 및 배포시 필요한 환경 설정을 할 수 있다.
• 배포 시 발생하는 문제를 이해하고 고칠 수 있다.

 

---

# 학습 내용

1.  RDS 개요

RDS(Relational Database Service)

-  AWS에서 제공하는 관계형 데이터베이스 서비스

- EC2 인스턴스에 MySQL 같은 관계형 데이터베이스 엔진을 설치하면 굳이 RDS를 사용할 이유가 없는데 데이터베이스만 따로 분리해서 서비스를 RDS 이용해야 할 이유는?

 

RDS 사용의 이점

1) 사용상의 편리성

출처 : 코드스테이츠 데브옵스 부트캠프 과정

EC2 인스턴스에 관계형 데이터베이스 엔진을 설치해 데이터를 관리할 경우

- 데이터베이스와 관련해서 자동으로 관리를 담당하는 부분이 매우 적기 때문에, 사용자가 일일이 시간을 투자하여 데이터베이스 엔진의 설치와 버전 관리, 데이터 백업 수행

- 가용성과 내구성이 확보되지 않기 때문에 데이터베이스에 저장된 데이터가 유실되거나 정상적으로 사용하지 못할 확률이 커지며, 후에 필요에 따라 데이터베이스의 규모를 확장하기 어려움

RDS를 사용해 데이터를 관리할 경우

- RDS를 이용하면 데이터베이스 유지 보수와 관련된 일들을 RDS에서 전적으로 자동 관리

- 사용자가 해야 할 일은 초기 설정을 제외하고 데이터베이스에 저장된 데이터를 관리하는 일 밖에 없으므로 편리

2) 다양한 데이터베이스 엔진 선택지 제공

 

2. RDS Architecture

관계형 데이터베이스의 개요

DBMS

- 데이터 저장, 조직화, 인출과 관련된 제반 업무를 관장하는 시스템 소프트웨어, 미들웨어

RDB(관계형 데이터베이스)

- 정보를 열과 행으로 이뤄진 테이블에 저장되고

- 테이블에 저장된 데이터는 공통 키 또는 공통 컨셉에 따라 서로 관계를 유지

- 테이블에서 데이터를 인출할 때 이와 같은 관계성을 이용

Amazon RDS의 개요

- AWS는 관계형 데이터베이스 호스팅 및 관리 서비스인 Amazon Relational Database Service(RDS)를 제공하며, 다음과 같은 RDBMS 엔진을 사용 가능

• Aurora MySQL
• Aurora PostgreSQL
• Oracle
• SQL Server
• MySQL
• PostgreSQL
• MariaDB

 

데이터베이스 호스팅 방식

시나리오1 : 온프레미스 데이터 센터에 데이터베이스 호스팅

- 사용자의 데이터 센터에 데이터베이스를 호스팅

- 전원, 네트워크 환경설정, 서버 환경설정부터 애플리케이션 최적화, 데이터베이스 소프트웨어 업그레이드 등까지 데이터 센터 운영을 위한 제반 업무를 모두 수행해야 함

시나리오2 : Amazon EC2 서버에 데이터베이스 호스팅

- EC2 서버에 데이터베이스를 호스팅

- 사용자는 DB 소프트웨어 설치, 패치, 데이터베이스 백업, 앱 최적화등을 관리하고, AWS는 OS설치, 서버유지 보수, 서버 랙 관리, 네트워크 관리 등의 업무를 처리

시나리오3 : Amazon RDS를 이용해 데이터베이스 호스팅

- Amazon RDS를 이용해 데이터베이스를 호스팅

- AWS가 데이터베이스 설치부터 업그레이드 등, 데이터베이스 호스팅과 관련된 모든 복잡한 업무를 대신 처리

- 사용자는 애플리케이션 최적화에만 집중 가능

- RDS 사용 시 장점

> 인프라 관리 불필요 : AWS가 데이터베이스와 관련된 모든 업무를 대신 처리하므로 사용자는 데이터베이스와 관련된 어떤 인프라도 직접 관리할 필요가 없음

 > 즉각적 프로비저닝 : RDS에서 데이터베이스 프로비저닝은 거의 즉시 이루어지므로 클릭 몇 번만으로 원하는 사양의 RDBMS를 배포할 수 있습니다. 

 > 확장성 관리 : RDS는 매우 간단하게 스케일업 및 스케일다운 할 수 있으며, 사용자가 원하는 내용대로 환경을 설정할 수 있음 (언제든 컴퓨팅 또는 메모리 리소스의 확장성을 조절 가능)

 > 애플리케이션 호환성 : RDS는 다양한 데이터베이스 엔진을 지원하므로 업계에서 널리 사용되는 데이터베이스 애플리케이션, 커스텀 코드, 기업에서 이미 사용 중인 데이터베이스 도구 등과 완벽하게 호환

 > 고가용성 : RDS를 이용해 멀티 AZ 환경에 데이터를 프로비전하면, RDS는 동기적으로 데이터를 복제해 다른 AZ의 대기 인스턴스에 저장 

 > 보안 유지 : RDS는 대기 상태 데이터 및 이동 상태 데이터의 암호화를 지원하며, 이를 이용해 대기 상태의 데이터를 암호화 할 수 있고, SSL 기법을 이용해 전송 상태의 데이터를 암호화 가능

RDS 고가용성 구현

- RDS는 고가용성(high availability) 아키텍처를 지원

-  데이터베이스가 잠시라도 셧다운되면 기업의 모든 업무가 마비 되므로 데이터베이스는 본질적으로 고가용성 아키텍처

 

RDS에 적용할 수 있는 다양한 아키텍처 옵션

가장 단순한 아키텍처 : 싱글 AZ 배포

- 상용화 환경이 아닌 개발 환경에서 데이터베이스를 사용하거나, 클라우드 기반 데이터베이스에 대한 경험을 얻는 차원에서 사용 시 싱글 AZ 환경에서 RDS 인스턴스를 론칭

- 사용자는 VPC 내에서 필요한 수준의 스토리지를 붙여서 하나의 RDS 인스턴스를 사용

고가용성 아키텍처 : 멀티 AZ 배포

- 기업에게 매우 중요한 데이터베이스를 실행하거나, 데이터를 절대 잃어버려서는 안되는 경우, 설정된 복원 소요 시간이 매우 촉박하거나 가동 정지 시간이 일절 허용되지 않는 경우, 멀티 AZ 환경에서 데이터베이스를 배포

- 멀티 AZ 아키텍처 데이터베이스 배포 동작 방식

1) 사용자가 먼저 기본 데이터베이스 인스턴스를 어느 AZ에 놓을지 설정

2) RDS는 또 다른 AZ에 대기 인스턴스 또는 스탠바이 인스턴스 및 스토리지를 선택해 배포

3) 대기 인스턴스는 기본 인스턴스와 동일한 타입으로 배포되며 스토리지 또한 기본 스토리지와 동일한 환경 설정 내용으로 구성

출처 : 코드스테이츠 데브옵스 부트캠프 과정

- 멀티 AZ 아키텍처 데이터베이스 구성 :  액티브 및 패시브(active/passive) 데이터베이스 모델과 비슷한 개념

① 마스터 데이터베이스

 > 기본 데이터베이스로 모든 트래픽을 처리

 > 정상 상태 유지

② 스탠바이 데이터베이스

 > 애플리케이션이 실행되고 있는 기본 데이터베이스가 셧다운되는 상황을 대비해 가동 가능 상태에서 대기

 > 즉시 복구가 가능하도록 대기 상태 유지

 > 대기 데이터베이스는 대기 상태에 있는 한 작동 불가하며 기본 데이터베이스와 대기 데이터베이스에 동시에 트래픽을 분산 불가

 > 기본 데이터베이스의 데이터는 동기적으로 대기 데이터베이스의 스토리지에 복제. 

- RDS는 장애 대처 방법

 > 자동으로 호스트 인스턴스 셧다운, 스토리지 장애, 기본 인스턴스의 네트워크 연결 단락, AZ 자체 셧다운 등의 장애 상황에 대응

 > 장애 대응 상황이 발생하면, 대기 데이터베이스가 기본 데이터베이스의 역할을 이어 받아서 새로운 기본 데이터베이스로서 모든 애플리케이션의 트래픽을 처리

 > RDS의 멀티 AZ 아키텍처에서 애플리케이션은 장애 발생 시 자동으로 DNS 장애 대응 기능을 활성화시켜, 기본 인스턴스와 대기 인스턴스를 맵핑한 DNS 엔드포인트를 이용해 데이터베이스에 연결

 > 따라서 사용자는 장애 대응을 위해 애플리케이션을 새로운 기본 데이터베이스에 연결할 필요 없음

 

RDS 확장성 구현

- 애플리케이션의 사용자 수가 증가(CPU와 메모리 용량 부족으로 서비스 성능 저하를 경험)나, 적절한 워크로드 분석 없이 애플리케이션을 상용화 한 경우 등 기업이 성장함에 따라 워크로드가 추가 되어 확장의 필요성 체감

 

RDS 확장성 구현 방법

인스턴스 타입 변경

- 확장성 조절을 위한 가장 간단한 방법

- 데이터베이스 인스턴스 타입을 변경

- 하나의 인스턴스 클래스에서 다른 인스턴스 클래스로 변경함으로써 스케일업 또는 스케일 다운 가능

- 변경 사항을 즉시 적용하면, 인스턴스 클래스 변경에 따라 약간의 가동 정지시간(downtime)이 발생할 수 있으므로 애플리케이션이 이러한 가동 정지시간에 영향을 받지 않도록 확인

읽기 사본 활용

- 마스터 데이터베이스의 Read-Only 복사본으로 마스터베이스와 동기화 상태를 유지

- RDS는 RDBMS 엔진에 따라 최대 15개의 읽기 사본 지니는 것 가능

- 읽기 사본은 read-only 쿼리의 부담을 줄여주며, 결과적으로는 마스터 데이터베이스의 워크로드를 감소 시키는 장점

- 읽기 사본은 고가용성 구현 매커니즘으로 사용 가능 (ex. 마스터 데이터베이스와 읽기 사본을 운용 중인 상황에서 마스터 데이터베이스가 다운되면 읽기 사본이 마스터로 승격, 이때 데이터가 비동기적으로 복제되므로 데이터의 손실 가능성이 존재하기 때문에 데이터 손실에 주의)