🔆 RDS Intro
RDS 는 Relational Database Service 의 약자로 ✅ AWS 에서 제공하는 관계형 데이터베이스 서비스이다.
❓ 왜 RDS 를 사용할까?
EC2 는 가상의 컴퓨터를 임대하는 서비스이다.
EC2 인스턴스에 MySQL 같은 관계형 데이터베이스 엔진을 설치하면 굳이 RDS를 사용할 이유가 있을까?
데이터 베이스만 따로 분리해서 서비스를 이용해야 할 이유가 있을까?
RDS 사용의 이점에 대해 알아보자.
💥 EC2 인스턴스에 데이터베이스 설치
EC2 인스턴스에 관계형 데이터베이스 엔진을 설치해서 데이터를 관리할 때와 RDS를 통해 데이터를 관리할 때의 차이는 개인 소유 차량과 렌터카 회사에서 대여한 차량으로 비유할 수 있다.
EC2 인스턴스에 데이터베이스를 설치하여 데이터를 관리하는 것은 개인 소유 차량을 이용하는 것과 비슷하다.
개인 소유 차량을 이용하면 유지 보수, 보험처리 같은 일들을 온전히 운전자가 부담한다.
차량 정비를 위해서 정비소에 주기적으로 방문해야 하고, 기타 차량과 관련된 다른 일이 생길 때 들여야 하는 시간과 수고가 크다.
EC2 인스턴스를 사용하면 데이터베이스와 관련해서 자동으로 관리를 담당하는 부분이 매우 적기 때문에, ✅ 사용자가 일일이 시간을 투자하여 데이터베이스 엔진의 설치와 버전 관리, 데이터 백업을 해야 한다.
게다가 가용성과 내구성이 확보되지 않기 때문에 데이터베이스에 저장된 데이터가 유실되거나 정상적으로 사용하지 못할 확률이 커지며, 후에 필요에 따라 데이터베이스의 규모를 확장하기 어렵다.
💥 RDS 사용
그에 비해 RDS를 이용하는 것은 렌터카 회사에서 차량을 대여하는 것과 비슷하다.
렌터카 회사에서 차량을 대여하면 대여 차량과 관련하여 시간이 들어가는 일들을 렌터카 회사에서 대신 처리한다.
운전자는 차량을 관리하는 일에 대해서 시간을 따로 쏟을 필요 없이 운전만 하면 되기에 매우 편리하다.
✅ RDS를 이용하면 데이터베이스 유지 보수와 관련된 일들을 RDS에서 전적으로 자동 관리 한다.
사용자가 해야 할 일은 초기 설정을 제외하고 데이터베이스에 저장된 데이터를 관리하는 일 밖에 없기에 큰 편의성을 느낄 수 있다.
💥 다양한 데이터베이스 엔진 선택지 제공
기타 RDS 이용 시 얻을 수 있는 ✅ 장점으로 다양한 데이터베이스 엔진 선택지를 제공한다는 점 이다.
회사에서 근무하고 있는 실무자는 회사에 필요한 데이터베이스 엔진을 취사선택하여 이용할 수 있다.
그 외 일반 사용자는 데이터베이스 엔진마다 제공하는 기능이 조금씩 다르기에 필요와 목적에 맞게 데이터베이스 엔진을 선택하여 효율성을 높일 수 있다.
🔆 RDS Architecture
💥 관계형 데이터베이스의 개요
✅ 데이터베이스 관리 시스템, 즉 DBMS는 데이터 저장, 조직화, 인출과 관련된 제반 업무를 관장하는 소프트웨어입니다. 그 중 📌 관계형 데이터베이스에서 정보는 열과 행으로 이뤄진 테이블에 저장되고, 📌테이블에 저장된 데이터는 공통 키 또는 공통 컨셉에 따라 서로 관계를 유지하며, 📌테이블에서 데이터를 인출할 때 이와 같은 관계성을 이용한다는 측면에서 💡 관계형 데이터베이스 라는 이름이 붙었습니다.
💥 Amazon RDS의 개요
AWS는 관계형 데이터베이스 호스팅 및 관리 서비스인 Amazon Relational Database Service(RDS)를 제공 하며, 다음과 같은 RDBMS 엔진을 사용할 수 있다.
- Aurora MySQL
- Aurora PostgreSQL
- Oracle
- SQL Server
- MySQL
- PostgreSQL
- MariaDB
Amazon RDS를 본격적으로 소개하기 전 데이터베이스 호스팅 방식을 알아보자.
전통적인 방식은 온프레미스 데이터 센터에 데이터베이스를 호스팅하는 것이지만, AWS에서는 EC2 서버에서 혹은 Amazon RDS에서 관계형 데이터베이스를 호스팅 할 수 있다.
관계형 데이터베이스를 호스팅하기 위한 주요 시나리오는 다음과 같다.
시나리오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 배포
RDS를 상용화 환경이 아닌 개발 환경에서 데이터베이스를 사용하거나 클라우드 기반 데이터베이스에 대한 경험을 얻는 차원에서 사용하는 거라면, 싱글 AZ 환경에서 RDS 인스턴스를 론칭해도 됩니다. 이때 사용자는 VPC 내에서 필요한 수준의 스토리지를 붙여서 하나의 RDS 인스턴스를 사용하게 됩니다.
고가용성 아키텍처 : 멀티 AZ 배포
기업에게 매우 중요한 데이터베이스를 실행하거나, 데이터를 절대 잃어버려서는 안되는 경우, 설정된 복원 소요 시간이 매우 촉박하거나 가동 정지 시간이 일절 허용되지 않는 경우, 멀티 AZ 환경에서 데이터베이스를 배포해야 합니다.
멀티 AZ 아키텍처에 데이터베이스를 배포하려면, 사용자가 먼저 기본 데이터베이스 인스턴스를 어느 AZ에 놓을지 정해야 합니다. 그러면 RDS는 또 다른 AZ에 대기 인스턴스 또는 스탠바이 인스턴스 및 스토리지를 선택해 배포하게 됩니다. 대기 인스턴스는 기본 인스턴스와 동일한 타입으로 배포되고, 스토리지 또한 기본 스토리지와 동일한 환경 설정 내용으로 구성됩니다.
멀티 AZ 아키텍처의 경우 마스터 데이터베이스라고 부르는 기본 데이터베이스가 모든 트래픽을 처리하고, 스탠바이 데이터베이스는 애플리케이션이 실행되고 있는 기본 데이터베이스가 셧다운되는 상황을 대비해 가동 가능 상태에서 대기 하게 됩니다. RDS는 기본 데이터베이스는 정상 상태를 유지하도록 하고, 대기 데이터베이스는 즉시 복구가 가능하도록 대기 상태를 유지하도록 합니다.
이때 대기 데이터베이스는 대기라는 상태에 있는 한 작동시킬 수 없고, 기본 데이터베이스와 대기 데이터베이스에 동시에 트래픽을 분산시킬 수는 없으며 이는 액티브 및 패시브(active/passive) 데이터베이스 모델과 비슷한 개념입니다. 기본 데이터베이스의 데이터는 동기적으로 대기 데이터베이스의 스토리지에 복제됩니다.
RDS는 장애 발생 시 다양한 유형의 대응 방식을 자동으로 적용해, 호스트 인스턴스 셧다운, 스토리지 장애, 기본 인스턴스의 네트워크 연결 단락, AZ 자체 셧다운 등의 장애 상황에 대처 가능합니다.
장애 대응 상황이 발생하면, 대기 데이터베이스가 기본 데이터베이스의 역할을 이어 받아서 새로운 기본 데이터베이스로서 모든 애플리케이션의 트래픽을 처리하게 됩니다. RDS의 멀티 AZ 아키텍처에서 애플리케이션은 장애 발생 시 자동으로 DNS 장애 대응 기능을 활성화시켜, 기본 인스턴스와 대기 인스턴스를 맵핑한 DNS 엔드포인트를 이용해 데이터베이스에 연결됩니다. 따라서 사용자는 장애 대응을 위해 애플리케이션을 새로운 기본 데이터베이스에 연결할 필요가 없습니다.
💥 RDS 확장성 구현
RDS에서 실행되는 데이터베이스의 확장성을 관리 할 수 있는 다양한 방법이 존재합니다. 사용자는 여러가지 이유로 RDS에서 데이터베이스의 확장성을 높이려 합니다. 예를 들어, 애플리케이션의 사용자 수가 증가하면서, 기업은 CPU와 메모리 용량 부족으로 서비스 성능 저하를 경험하게 됩니다. 혹은 적절한 워크로드 분석 없이 애플리케이션을 상용화 한 경우에도 확장성 제고의 필요성을 느끼게 됩니다. 즉, 기업이 성장함에 따라 워크로드가 추가 되고 이는 확장성을 구현함에 따라 해결할 수 있습니다. 확장성을 구현하는데는 아래와 같은 방법이 있습니다.
인스턴스 타입 변경
확장성 조절을 위한 가장 간단한 방법은 데이터베이스 인스턴스 타입을 변경하는 것입니다. 하나의 인스턴스 클래스에서 다른 인스턴스 클래스로 변경함으로써 스케일업 또는 스케일 다운 할 수 있습니다.
이러한 변경 사항을 즉시 적용하면, 인스턴스 클래스 변경에 따라 약간의 가동 정지시간(downtime)이 발생할 수 있으므로, 애플리케이션이 이러한 가동 정지시간에 영향을 받지 않도록 확인해야합니다.
읽기 사본 활용
읽기 사본은 마스터 데이터베이스의 Read-Only 복사본으로 마스터베이스와 동기화 상태를 유지하며, RDS는 RDBMS 엔진에 따라 최대 15개의 읽기 사본을 지닐 수 있습니다. 읽기 사본은 read-only 쿼리의 부담을 줄여주며, 결과적으로는 마스터 데이터베이스의 워크로드를 감소 시키는 장점이 있습니다.
또 읽기 사본은 고가용성 구현 매커니즘으로 사용할 수 있습니다. 예를 들어 마스터 데이터베이스와 읽기 사본을 운용 중인 상황에서 마스터 데이터베이스가 다운되면 읽기 사본이 마스터로 승격될 수 있습니다. 이때 데이터가 비동기적으로 복제되므로 데이터의 손실 가능성이 존재하기 때문에 데이터 손실에 주의해야 합니다.
