AWS RDS(Relational Database Service)란?

 

[Hands-on] AWS Lake Formation으로 손쉽게 데이터 환경을 구축하기

 

Amazon Web Service는 클라우드 환경에서 다양한 관계형 데이터베이스 서비스를 제공해주고 있습니다. 이 글에서는 관련된 중점 사항들은 무엇이 있고, 어떠한 서비스들이 존재하는지 알아보겠습니다.

 

---

Amazon Relational Database Service

아마존 RDS는 클라우드에서 관계형 데이터베이스를 실행할 수 있도록 하는 managed 데이터베이스 서비스입니다. RDS는 데이터베이스 시스템 셋업, 백업 수행, HA 관리, 그리고 기반한 OS 시스템이나 데이터베이스 소프트웨어 설치를 기본적으로 제공합니다. RDS는 또한 데이터베이스 실패 회복이나 데이터 복구, 애플리케이션 요구사항에 따른 데이터베이스 확장 등을 손쉽게 만들어 줍니다. 

 

RDS는 사용해서 데이터베이스를 배포하기 위해서, 먼저 독립된 데이터베이스 환경인 데이터베이스 인스턴스를 설정하여야 합니다. 데이터베이스 인스턴스는 설정한 virtual private cloud(VPC)에 존재하나 EC2와는 달리 AWS가 완전하게 데이터베이스 인스턴스를 관리해줍니다. 그렇기에 사용자는 데이터베이스 인스턴스에 SSH 접근이 불가능하며, 사용자의 EC2 인스턴스 리스트에서도 데이터베이스 인스턴스는 보이지 않습니다.

 

 

데이터베이스 엔진들

 

Image from AWS [1]

 

하나의 데이터베이스 엔진은 단순하게 데이터베이스 안에 데이터를 저장하고, 조직하고, 추출하는 소프트웨어입니다. 각 데이터베이스 인스턴스는 오직 하나의 데이터베이스 엔진을 실행할 수 있습니다. RDS는 아래와 같이 6개의 데이터베이스 엔진을 제공합니다 [1]:

 

• MySQL: MySQL은 블로그 또는 이커머스와 같은 OLTP 애플리케이션을 위해 디자인 되었습니다. RDS는 최신의 MySQL 커뮤니티 에디션 버젼을 제공합니다. MySQL은 MyISAM과 InnoDB의 2가지 스토리지 엔진을 제공합니다만, 오직 InnoDB만이 RDS-managed 자동 백업과 compatible하기에 InnoDB 엔진을 사용하여야 합니다.

 

• MariaDB: MariaDB는 MySQL 대체로 사용할 수 있는 엔진입니다. MariaDB는 Oracle이 MySQL을 개발한 회사를 인수한 직후 MySQL의 향후 방향에 대한 우려의 결과로 탄생하게 되었습니다. MariaDB는 XtraDB와 InnoDB 엔진을 지원하나, AWS는 RDS와의 호환성을 위해 후자를 사용하길 권장하고 있습니다.

 

• Oracle: Oracle은 가장 널리 사용되는 관계형 데이터베이스입니다. 몇몇의 애플리케이션은 특정하여 Oracle 데이터베이스 사용을 요구사항에 포함하고 있습니다. RDS는 아래와 같은 Oracle 데이터베이스 에디션을 제공합니다:
  • Standard Edition One (SE1)
  • Standard Edition Two (SE2)
  • Standard Edition (SE)
  • Enterprise Edition (SE)

 

• PostgreSQL: PostgreSQL은 가장 Oracle-호환성이 있는 오픈소스 데이터베이스임을 자랑합니다. 특히 Oracle을 위해 개발된 인하우스 애플리케이션의 비용절감을 고려할 때 선택할 수 있는 옵션입니다. 

 

• Amazon Aurora: Aurora는 아마존의 MySQL 및 PostreSQL 대체 데이터베이스 엔진입니다. Aurora는 그 2가지 보다 더 나은 write 성능을 보이는데, 그 부분은 기반한 스토리지에 write 횟수를 줄이는 가상화된 스토리지 레이어를 사용하기에 그러합니다. 2가지 에디션을 제공합니다:
  • MySQL 호환
  • PostgreSQL 호환

 

• Microsoft SQL Server: RDS는 다양한 Microsoft SQL Server 버젼을 지원합니다. 에디션과 관련해서, 사용자는 Express, Web, Standard, Enterprise 중에 선택할 수 있습니다. 이러한 다양성은 여러 온프레미스 환경으로부터 클라우드 마이그레이션 시, 데이터베이스의 별다른 버젼 변경 없이 순조롭게 이관할 수 있도록 돕는 요소가 됩니다. 

 

라이센싱 관련 사항들

RDS는 데이터베이스 엔진 소프트웨어에 대한 라이센싱과 관련해 2가지 방식을 제공합니다. 'License included' 방식은 RDS 인스턴스 비용에 라이센스 비용을 포함하고 있습니다. 'Bring your own license (BYOL)' 방식은 데이터베이스 엔진을 사용하기 위해 사용자가 해당 엔진에 대한 라이센스를 보유하고 있어야 합니다. 

 

• License Included: MariaDB와 MySQL은 GNU General Public License (GPL) v2.0을 사용하고, PostgreSQL은 PostgreSQL  라이센스를 사용하는데 모두 각 소프트웨어의 무료 사용을 허용합니다. RDS에서 실행할 수 있는 Microsoft SQL Server 에디션의 모든 버젼과 Oracle SE1과 SE2는 라이센스를 포함합니다.

 

• BYOL: 오직 Oracle 데이터베이스 엔진만이 이러한 라이센싱 방식을 지원합니다. 구체적으로 아래와 같은 에디션에 해당됩니다:
  • EE
  • SE
  • SE1
  • SE2

 

데이터베이스 옵션 그룹

다른 데이터베이스 엔진은 데이터베이스를 관리하고 보안을 높이기 위한 각기 다른 다양한 기능과 옵션을 제공합니다. '옵션 그룹'은 이러한 기능들을 사용자가 이러한 기능들을 명시하고 하나 이상의 인스턴스에 동시적으로 적용할 수 있도록 합니다. 옵션은 추가적인 메모리를 요구하기에 사용자는 인스턴스가 충부한 메모리를 가지고 있도록 해야 하며 꼭 필요한 옵션만 설정하는 것이 좋습니다. 

 

데이터베이스 옵션 그룹에 등록 가능한 옵션은 데이터베이스 엔진에 따라 다릅니다. Oracle은 S3 연동을 제공합니다. Microsoft SQL Server와 Oracle은 transparent data encryption (TDE)를 제공하며, 이 기능은 엔진이 데이터를 스토리지에 쓰기 전에 암호화하도록 합니다. MySQL과 MariaDB는 DB 사용자의 로그인과 쿼리를 로깅할 수 있는 audit plug-in을 제공합니다. 

 

 

데이터베이스 인스턴스 클래스

데이터베이스 인스턴스를 생성할 때, 얼마의 처리량, 메모리, 네트워크 대역폭, 디스크 throughput이 필요한지 결정해야 합니다. RDS에서는 다양한 데이터베이스 인스턴스 클래스를 통해 목적에 맞는 설정이 가능합니다. 그러한 클래스를 잘 못 설정하였거나 변경할 필요가 있다면, 다른 클래스로 쉽게 변경할 수 있습니다. RDS는 데이터베이스 인스턴스 클래스를 아래의 3가지 타입으로 분류합니다:

 

Standard

Standard 인스턴스 클래스는 대부분 데이터베이스에 대한 요구사항을 만족시킵니다. db.m5 클래스는 최대 아래와 같은 스펙을 제공합니다:

 

• 384 GB의 메모리
• 96 vCPU
• 25 Gbps 네트워크 대역폭
• 19,000 Mbps (2,375 MBps) 디스크 throughput

 

Memory Optimized

Memory-optimized 인스턴스 클래스는 조금 더 높은 성능 요구사항을 필요로 하는 데이터베이스를 위한 것입니다. 데이터베이스에 더 많은 메모리를 제공하는 것은 메모리에 데이터를 더 저장할 수 있고, 그 점은 더욱 빠른 쿼리 시간이라는 결과로 나타나게 됩니다. 

 

데이터베이스 인스턴스는 EBS 스토리지를 사용합니다. Standard와 memory-optimized 인스턴스 클래스 타입은 EBS optimized기에, EBS 스토리지와 인스턴스 간의 dedicated 대역폭을 제공합니다.

 

Burstable Performance

Burstable performance 인스턴스는 개발, 테스트, 또는 다른 비-사용을 위한 데이터베이스입니다. 

 

db.t3, db.m5와 db.r5 클래스는 AWS Nitro 시스템에 기반하여 이전 클래스들에 비해서 더욱 개선된 성능을 제공합니다. 

 

 

스토리지

스토리지의 선택은 데이터베이스를 위한 충분한 디스크 공간 선택이라는 점 외에도 원하는 성능 요구사항을 만족하는지와 같은 부분을 고려해야 합니다. 

 

Input/Output Operations Per Second의 이해

AWS는 스토리지 성능을 input/output operations per second (IOPS)라는 방법으로 측정합니다. 하나의 input/output (I/O) 연산은 스토리지에 쓰거나 읽는 것을 말합니다. 모든 부분이 동일할 때, 더 많은 IOPS를 보일수록 데이터베이스는 더욱 빠르게 데이터를 저장하거나 꺼낼 수 있습니다. 

 

RDS는 스토리지 선택 조건에 따라 여러 IOPS를 할당해주며, 사용자는 이러한 제한을 넘을 수 없습니다. 그렇기에 데이터베이스 스토리지의 속도는 할당된 IOPS 수에 따라 제약을 받습니다. 얼마나 많은 IOPS가 필요한지 파악하기 위해서, 먼저 얼마나 많은 disk throughput이 필요한지를 알고 있어야 합니다.

 

MySQL과 MariaDB는 16KB의 페이지 사이즈를 가지고 있습니다. 그러므로, disk에 16KB의 데이터를 쓰는 것은 하나의 I/O 연산을 이룹니다. Oracle, PostgreSQL, 그리고 Microsoft SQL Server는 8KB의 페이지 사이즈를 사용합니다. 페이지 사이즈가 클 수록, 하나의 I/O 연산에서 더욱 많은 데이터를 이동시킬 수 있습니다.

 

16KB의 페이지 사이즈를 가정했을 때, 애플리케이션 요구사항이 데이터베이스에서 매초에 102,400 KB(100 MB)의 데이터를 읽는 것이라고 해보겠습니다. 이러한 레벨의 성능을 만족시키기 위해서 데이터베이스는 매 초당 6,400개의 16KB 페이지를 읽을 수 있어야 합니다. 각 페이지는 하나의 I/O 연산에 해당되기에, 스토리지와 인스턴스 클래스는 6,400 IOPS를 버텨낼 수 있어야 합니다. 이 부분에서 페이지 사이즈와 IOPS 간의 반대되는 특성을 기억할 필요가 있습니다.

 

General-Purpose SSD

대부분의 데이터베이스에서 general-purpose SSD (gp2) 스토리지는 충분합니다. SSD는 빠르고, 한 자릿수의 밀리세컨드 latency를 제공합니다. 최대 64TB의 볼륨을 할당할 수 있습니다. 사용자가 볼륨에 더하는 각 GB마다, RDS는 볼륨에 3 IOPS의 기본 성능을 최대 16,000 IOPS까지 추가합니다. 20 GB의 볼륨은 60 IOPS를, 100 GB 볼륨은 300 IOPS를 가지게 됩니다. 그렇기에 볼륨이 더 클수록 더 높은 성능을 가지게 됩니다. 

 

gp2 스토리지가 제공하는 최대 throughput은 2,000 Mbps (250 MBps)입니다. 이러한 성능을 이루기 위해서 크게 2가지 부분이 만족되어야 합니다. 첫 번째로, 모든 인스턴스 클래스가 그정도 이상의 disk throughput을 제공해야 합니다. 두 번째로, 이러한 throughput을 감당하기 위해서 충분한 IOPS가 할당되어야 합니다. 계산을 해보면 2,000 Mbps / 0.128 Mb (페이지 사이즈가 16KB 일때)로 15,625 IOPS가 필요하다는 것을 알 수 있습니다. 최대치의 IOPS (16,000)을 얻기 위해서는 볼륨이 5.33 TB 정도가 되어야 합니다.

 

사용패턴에 따라 특정 시간에는 3000 IOPS 정도 까지 필요하나 너무 많은 스토리지가 필요 없다면 IOPS를 위해 굳이 너무 많은 스토리지를 할당할 필요는 없습니다. 1 TB보다 작은 볼륨은 일시적으로 3,000 IOPS까지 burst할 수 있습니다. burst할 수 있는 시간은 아래와 같은 공식에 의해 결정됩니다:

 

Burst 할 수 있는 시간 (초) = (Credit balance) / [3,000 - 3 * (storage size in GB)]

 

 

데이터베이스를 처음 부팅했을 때, 5,400,000 IOPS에 해당하는 credit을 받습니다. 이후 기본 IOPS를 넘는 IOPS를 사용하게 되면, 그 부분은 credit에서 차감되어 사용하게 됩니다. Credit balance가 고갈된 이후에는, 더 이상 burst할 수 없습니다. 예로, 200 GB 볼륨을 사용한다면, burst 시간은 2,250 초로 약 37.5분 정도 됩니다. 

 

Credit balance는 기본 IOPS에 따라 매초 차오르게 됩니다. 예로, 200 GB 볼륨인 경우 기본 IOPS는 600으로 매초 600 IOPS의 credit이 차오르며 최대 5,400,000입니다. 

 

Provisioned IOPS SSD (io1)

gp2 스토리지가 복잡하고 까다롭다고 느껴지는 경우에는 RDS가 제공하는 또 다른 옵션인 Provisioned IOPS SSD를 사용할 수 있습니다. 이 옵션은 인스턴스 생성 시 사용자가 직접 사용할 IOPS를 설정하도록 해줍니다. io1 스토리지에는 burst라는 개념이 없기에, 사용자는 사용하든 안하든 설정한 IOPS에 대한 비용을 지불하게 됩니다. 그렇기에 일정하고 꾸준한 latency를 원하는 경우 적절합니다.

 

사용자는 io1 볼륨에 최대 64,000 IOPS까지 설정할 수 있습니다. IOPS와 스토리지 용량의 최대치는 어떤 엔진을 사용하느냐에 따라 다릅니다. 

 

Throughput-optimized HDD (st1)

st1는 magnetic storage를 사용합니다. 볼륨 크기는 500 MB에서 16 TB까지 다양합니다. 기본 throughput은 역시 볼륨 크기에 의존하며, 1 TB 당 40 MBps를 제공합니다. 

 

Cold HDD (sc1)

sc1 볼륨도 역시 magnetic storage를 사용하고 500 MB에서 16 TB까지의 용량을 제공합니다. 차이는 sc1 볼륨은 더 낮은 throughput을 제공한다는 점입니다. 1 TB 당 12MBps를 제공받으며, st1보다 저렴합니다.

 

 

 

Read Replicas

데이터베이스 인스턴스가 성능 요구사항을 만족하지 못한다면, 사용자는 병목지점에 따라 scale up 또는 scale out하여 문제를 해결할 수 있습니다.

 

Scale up

앞서 살펴본 것과 같이, memory, compute, network speed 또는 disk throughput이 문제가 되는 경우 다른 변경 없이 단순히 더 많은 리소스를 추가할 수 있습니다. 

 

Scale out

Scaling out은 read replicas라고 불리는 추가적인 데이터베이스 인스턴스를 생성하는 것을 동반합니다. Microsoft SQL Server를 제외한 모든 엔진은 read replicas를 지원합니다. 

 

read replica는 또 다른 데이터베이스 인스턴스로 오직 데이터베이스 쿼리만 서비스합니다. read replica는 데이터베이스에 데이터를 쓰는 master 데이터베이스 인스턴스로부터 일부 쿼리 부하를 경감시킵니다. 

 

read replica pattern - Image from CDP

 

 

High Availability (Multi-AZ)

하나의 데이터베이스 인스턴스의 장애 시에도 데이터베이스가 정상적으로 동작하게 하기 위해서, RDS의 multi-AZ 배포라는 기능을 통해 여러 데이터베이스 인스턴스를 여러 availability zone에 배포할 수 있습니다. multi-AZ 배포에서 사용자는 primary 데이터베이스 인스턴스를 하나의 availability zone에 가지며, 이것은 데이터베이스에 대한 읽기 쓰기를 처리합니다. 그리고 standby 데이터베이스 인스턴스는 다른 availability zone에 존재하게 됩니다. Primary 인스턴스가 장애로 서비스가 불가능하면, standby로 페일오버 됩니다 (평균 2분 안에).

 

모든 데이터베이스 엔진은 multi-AZ를 지원하며, 기존에 생성한 인스턴스에 multi-AZ을 enable하면 급격한 성능 저하가 발생할 수도 있습니다.

 

 

Backup과 Recovery

RDS에서 사용자는 데이터베이스 인스턴스에 대해 EBS 볼륨 스냅샷을 만들 수 있습니다. 스냅샷은 인스턴스에 있는 모든 데이터베이스를 포함하며 S3에 저장되게 됩니다. 스냅샷은 redundancy를 위해 동일한 리젼의 여러 zone에 보관되게 됩니다. 

 

스냅샷을 찍는 것은 multi-AZ을 사용하지 않는 이상 몇 초 동안 모든  I/O 연산을 중단하게 됩니다.

 

백업과 리커버리 요구를 고려할 때, 2가지 메트릭을 이해하고 있으면 좋습니다. 하나는 recovery time objective (RTO)로 데이터 복구에 최대한 쓸 수 있는 시간으로 실패 이후 프로세싱을 다시 시작하는 데에 걸리는 시간입니다. recovery point objective (RPO)는 최대 허용 가능한 데이터 손실 기간입니다. RDS의 백업 옵션을 고려할 때, 이 2가지 점에 기반해 선택하여야 합니다.

 

스냅샷으로부터 복원을 할 때, RDS는 새로운 인스턴스에 복원하게 됩니다. 스냅샷을 통한 복원은 데이터 사이즈에 따라 대략 수 분이 소요되게 됩니다. IOPS가 더 많다면, 더욱 빨리 복원할 수 있습니다.

 

Automated Snapshots

RDS는 30 분의 백업 구간동안 인스턴스에 대한 스냅샷을 매일 자동적으로 생성할 수 있습니다. 사용자는 이러한 백업 구간을 조정할 수도 있고, RDS가 직접 설정하도록 할 수도 있습니다. 스냅샷을 찍는 것은 성능에 영향을 미치기 때문에, 데이터베이스가 조금 한가할 때에 진행하는 것을 권장합니다. RDS가 간격을 설정하도록 한다면, RDS는 랜덤하게 8시간 블록으로 30분을 설정하게 됩니다. 

 

자동 백업은 point-in-time recovery를 할 수 있게 해주는데, 이 기능은 5분마다 change logs를 S3로 아카이빙해주는 기능입니다. 만약 실패가 발생하여도, 사용자는 오직 5분 정도의 데이터 손실만이 발생하게 됩니다. point-in-time 시점으로의 복구는 트랜잭션 로그 크기에 따라 몇 시간 정도가 소요될 수 있습니다.

 

RDS는 자동적으로 생성된 스냅샷을 특정 기간 동안 보관하고 이후 삭제합니다. 이러한 보관주기는 ~ 35일까지 설정이 가능하며, 디폴트는 7일입니다. 수동으로 데이터베이스 인스턴스의 스냅샷을 생성할 수도 있지만, 이 경우 삭제도 수동으로 진행해 주어야 합니다. 

 

 

Amazon Redshift

Redshift는 아마존의 managed 데이터 웨어하우스 서비스입니다. 비록 PostgreSQL에 기반해 만들어졌지만, RDS에 속하지 않고 단독 서비스로 존재합니다. Redshift는 컬럼형 스토리지를 사용합니다. 이 부분은 스토리지의 속도와 효율성을 개선해주고, 개별 컬럼에 대한 쿼리를 더욱 빠르게 만들어 주게 됩니다. Redshift는 Open Database Connectivity (ODBC)와 Java Database Connectivity (JDBC) 코넥터를 지원합니다. 

 

Redshift는 각 컬럼이 차지하는 사이즈를 줄이기 위해 압축 인코딩을 제공하는데, 각 컬럼별로 수동으로 압축방식 설정이 가능합니다. 

 

좀 더 구체적인 사항은 추후에 개별 내용으로 다뤄보겠습니다.

 

Reference

[1] https://aws.amazon.com/rds 

[2] https://www.amazon.com/Certified-Solutions-Architect-Study-Guide/dp/1119713080