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