(1) 라이선스 고려사항
RDS는 데이터베이스 엔진을 실행하는 데 필요한 두 가지 소프트웨어 라이선스 모델을 제공한다. 라이선스가 포함된 모델은 RDS 인스턴스 요금에 라이선스 비용이 포함되며, 기존 보유 라이선스 사용(BYOL, Bring Your Own License) 모델을 선택하려면 실행 중인 데이터베이스 엔진의 라이선스를 확보해야 한다.
-
라이선스가 포함된 모델
MariaDB와 MysOL은 GNU GPL(General Public License) v2.0을 사용하며, PostgreSQL은 PostgreSQL 라이선스를 사용하고, 별도의 라이선스 비용은 없다. RDS에서 실행하는 Microsoft SOL 서버의 모든 버전과 에디션은 라이선스를 포함하고 있고, Oracle Database Standard Edition One(SE1)과 Standard Edition Two(SE2)도 라이선스를 포함하고 있다. -
기존 보유 라이선스 사용
다음 Oracle 데이터베이스 에디션에서 기존 보유 라이선스를 사용할 수 있다.- Enterprise Edition(EE)
- Standard Edition(SE)
- Standard Edition One(SE1)
- Standard Edition Two(SE2)
(2) 데이터베이스 옵션 그룹
데이터베이스 엔진은 데이터베이스 관리와 보안 향상을 지원하는 다양한 기능을 제공한다. 옵션 그룹은 옵션이라는 관리 및 보안 기능을 지정해서 하나 이상의 인스턴스에 적용할 수 있게 한다. 옵션을 사용하려면 메모리가 더 필요하므로 인스턴스에 충분한 메모리가 있는지 확인하고 필요한 것만 활성화해야 한다.
옵션 그룹에서 사용 가능한 옵션은 데이터베이스 엔진마다 다르며, Microsoft SQL Server와 Oracle은 TDE(Transparent Data Encryption)를 제공해 스토리지에 쓰기를 수행하기 전에 엔진이 데이터를 암호화하게 한다. MySQL과 MariaDB는 데이터베이스 사용자 로그인과 쿼리 활동을 기록하게 하는 감사 플러그인을 제공한다.
(3) 데이터베이스 인스턴스 클래스
데이터베이스 인스턴스를 시작할 때 처리 성능, 메모리, 네트워크 대역폭, 디스크 치리량이 어느 정도 필요한지 결정해야 한다. RDS는 여러 데이터베이스의 다양한 성능 요구 사항을 충족하기 위해 다양한 데이터베이스 인스턴스 클래스를 제공한다.
선택을 잘못 했거나 요구 사항이 변경될 때 인스턴스를 다른 클래스로 전환할 수도 있다. RDS는 데이터베이스 인스턴스 클래스를 다음 세 가지 유형으로 나눈다.
-
표준
표준 인스턴스 클래스는 데이터베이스 요구를 대부분 충족하며, 최신 세대 인스턴스 클래스는 db.m4로 다음 사양을 제공한다.- 256GB 메모리
- 64 VCPU
- 25Gbps 네트워크 대역폭
- 10,000Mbps(1,280MBps) 디스크 처리량
-
메모리 최적화
메모리 최적화 인스턴스 클래스는 높은 처리 성능이 요구되는 데이터베이스용이며, 메모리를 더 많이 확보하고 있으면 메모리에 더 많은 데이터를 저장할 수 있으므로 쿼리 시간이 빨라진다. 최신 세대의 인스턴스 클래스는 db.x1e이며 다음 사양을 제공한다.- 3,904GB 메모리
- 128 vCPU
- 25Gbps 네트워크 대역폭
- 14,000Mbps(1,750MBps) 디스크 처리량
데이터베이스 인스턴스는 EBS 스토리지를 사용한다. EBS 스토리지와의 데이터 전송을 위한 전용 대역폭을 제공하기 위해 표준과 메모리 최적화 인스턴스 클래스 유형은 EBS 최적화를 지원한다.
- 순간 확장 가능
순간 확장 가능 인스턴스(db.2)는 개발, 테스트, 다른 비프로덕션 데이터베이스를 위한 인스턴스이며 다음 사양을 제공한다.- 32GB 메모리
- 8 VCPU
AWS는 네트워크 성능을 '보통'이라고 표시하는데, 이는 대개 1Gbps 미만에 해당한다. AWS는 디스크 처리량의 상태를 제공하지 않지만, 3,200Mbps(400MBps)를 넘지 않는다고 예상하는 것이 좋다.
- 스토리지
데이터베이스 인스턴스에 적합한 스토리지 선택은 충분한 디스크 공간 확보 이상으로 중요하다. 데이터베이스 기반 애플리케이션의 성능 요구 사항을 충족하기 위해서는 얼마나 빠른 스토리지를 선택할지도 판단해야 한다.
(4) IOPS 이해
AWS는 초당 입력/출력 작업(IOPS, Input/Output Operations Per Second)을 사용해 스토리지 성능을 측정한다. 입출력 작업은 스토리지 읽기 또는 쓰기 작업이며, 다른 모든 조건이 같을 때, IOPS가 큰 데이터베이스는 데이터를 저장하고 검색하는 속도가 더 빠르다.
RDS는 스토리지 타입에 따라 IOPS를 할당할 수 있으나 임곗값을 초과할 수 없다. 데이터베이스 스토리지의 속도는 할당된 IOPS 수에 제한된다. 단일 I/O 작업에서 전송할 수 있는 데이터의 양은 데이터베이스 엔진이 사용하는 페이지 크기에 달려 있으며, 요구되는 TOPS 수준을 파악하려면 먼저 필요한 디스크 처리량을 알아야 한다.
MySQL과 MariaDB의 페이지 크기는 16KB이므로, 디스크에 16KB의 데이터 쓰기가 하나의 I/O 작업을 구성한다. 반면, Oracle, PostgreSQL, Microsoft SQL Serversms 8KB 크기의 페이지를 사용하며, 이 경우 16KB의 데이터를 쓰면 I/O 작업이 두 번 이뤄진다. 페이지 크기가 클수록 단일 I/O 작업에서 더 많은 데이터를 전송할 수 있다.
페이지의 크기가 16KB라고 하고, 데이터베이스가 초당 102,400KB(100MB)의 데이터를 읽어야 한다고 했을 때, 이러한 성능 요구를 달성하려면 데이터베이스는 매 초 10KB 페이지 크기로 6,400페이지를 읽어야 하며, 페이지당 I/O 작업 하나로 계산하기 때문에 스토리지와 인스턴스 클래스는 6,400 IOPS를 유지해야 한다. 이때, IOPS 수와 페이지 크기는 반비레 관계라는 데 주목해야 한다. 페이지 크기가 클수록 같은
처리량을 달성하는 데 필요한 IOPS는 적어진다.
페이지 크기가 32KB를 넘으면 흥미로운 일이 발생한다. 데이터베이스 엔진이 단일 I/O 작업에서 32KB가 넘는 쓰기를 하면, 2개 이상의 I/O 작업으로 계산된다. 예를 들어, 64KB 페이지의 읽기 및 쓰기는 2개의 I/O 작업으로 계산되고, 128KB 페이지는 4개의 I/O 연산 으로 계산된다.
스토리지 유형에 따라서 IOPS 수가 달라지며, AWS RDS는 다음 세 가지 유형의 스토리지를 제공한다.
- 범용 SSD
- 프로비저닝된 IOPS SSD(iol)
- 마그네틱 스토리지
(5) 고가용성(다중-AZ)
데이터베이스 인스턴스가 중단돼도 데이터베이스를 계속 운영하려면, RDS의 다중 AZ 배포를 통해 여러 가용 영역에 데이터베이스 인스턴스 여러 개를 배포한다. 다중 AZ 배포를 사용하면 한 가용 영역에 읽기 및 쓰기를 처리하는 기본 데이터베이스 인스턴스를 두고, 다른 가용 영역에는 예비 데이터베이스 인스턴스를 두게 되며, 기본 인스턴스가 중단되면 보통 2분 이내에 예비 인스턴스로 장애 조치가 수행된다.
데이터베이스 인스턴스의 대표적인 중단 이유는 다음과 같다.
- 가용 영역 중단
- 데이터베이스 인스턴스 유형 변경
- 인스턴스의 운영 체제 패치
데이터베이스 인스턴스를 만들 때나 만든 후라도 다중 AZ를 구성할 수 있다. 모든 데이터베이스 엔진은 다중 AZ를 지원하지만 구현 방식은 약간씩 다르며, 인스턴스를 만든 후에 다중 AZ를 활성화하면 성능이 상당히 떨어지므로 유지 관리 주기를 좀 더 짧게 잡아야 한다.
(6) 백업과 복구
RDS는 데이터베이스 인스턴스의 EBS 볼륨 스냅샷 기능을 제공한다. 일반 EBS 스냅샷처럼 인스턴스에 기반한 모든 데이터베이스는 스냅샷을 생성해서 S3에 저장할 수 있다. 스냅샷은 중복성을 위해 같은 리전의 여러 영역에 보관된다.
Microsoft SQL Server 이외의 데이터베이스 엔진에서는 다중 AZ를 사용하지 않는 한 스냅샷을 하면 몇 초 동안 모든 I/O 작업이 일시 중단되므로 사용량이 적은 시간에 스냅샷을 만들어야 한다.
백업 및 복구가 필요할 때 고려해야 할 두 가지 지표가 있는데, 하나는 복구 목표 시간(RTO, Recovery Time Objective)으로서 장애 후 데이터를 복구하고 처리를 재개하는 데까지 최대 허용 시간이고, 다른 하나는 복구 목표 지점(RPO, Recovery Point Objective)으로서 데이터 손실을 허용할 수 있는 최대 기간이다. RDS 백업 옵션을 선택할 때 RTO와 RPO 요구를 고려해야 한다.
PDS 스냅샷을 복구할 때 스냅샷을 새 인스턴스로 복구하는데, 복구 시간은 몇 분 정도 걸리며 크기에 따라 차이가 있다. 새 인스턴스에 더 빠른 성능의 프로비저닝된 IOPS를 할당하면 복구 시간이 빨라진다.
(7) 자동화된 스냅샷
RDS는 매일 30분 백업 기간에 인스턴스 스냅샷을 자동 생성할 수 있으며, 이 기간은 사용자가 지정할 수도 있고 RDS가 자동으로 수행하게 할 수도 있다. 스냅샷을 진행하면 성능에 영향을 주기 때문에 데이터베이스가 가장 적게 사용되는 시간에 진행 하는 것이 좋다. RDS에서 백업을 진행하도록 설정하면, 리전마다 다르게 8시간 간격으로 30분 백업을 진행한다.
자동 백업을 사용하면 특정 시점 복구가 가능해지며, 데이터베이스 변경 로그를 5분 마다 S3로 저장한다. 장애 이벤트가 발생하면 최대 5분 분량의 데이터만 손실된다. 특정 시점 복구는 몇 시간이 걸릴 수도 있으며, 트랜잭션 로그에 있는 데이터양에 따라 차이가 있다.
RDS는 자동화된 스냅샷을 일정 기간동안 유지하고, 기간이 지나면 삭제한다. 사용자는 1일에서 35일 사이의 보존 기간을 선택할 수 있으며, 기본값은 7일이다. 자동 스냅샷을 사용하지 않으려면 보존 기간을 0으로 설정한다. 자동 스냅샷을 비활성화 하면 기존의 자동화된 스냅샷 모두가 즉시 삭제되고, 특정 시점 복구가 비활성화된다. 보존 기간을 0에서 다른 값으로 변경하면 즉시 스냅샷이 트리거된다.
데이터베이스 인스턴스에 대해 수동으로 스냅샷을 수행할 수 있으며, 자동화된 스냅 샷과 달리 수동 스냅샷은 삭제할 때까지 유지된다. 인스턴스를 삭제하면 사용자는 RDS의 최종 스냅샷 작업 수행 여부와 자동 스냅샷 유지 여부를 선택해야 하고, 최종 스냅샷과 모든 수동 스냅샷은 유지되지만, 자동 백업을 유지하지 않기로 선택하면 자동 스냅샷은 즉시 삭제된다.
(8) 유지 관리 항목
RDS는 관리형 서비스이므로 패치 및 업그레이드 처리는 AWS가 책임지며, 데이터베이스 인스턴스에서 운영 체제 보안과 안정성 패치 등의 유지 관리를 몇 달에 한 번씩 정기적으로 수행한다. 유지 관리 기간 동안 데이터베이스 엔진을 업그레이드할 수도 있다. AWS에서 새 버전의 데이터베이스 엔진을 지원하게 되면, 사용자는 새 버전 업그레이드를 결정할 수 있다. 메이저 버전 업그레이드에는 이전 버전과 호환하지 않는 데이터베이스 변경 사항이 포함돼 있을 수 있으로, 메이저 버전 업그레이드는 사용자가 직접 적용해야 한다. AWS는 데이터베이스를 다시 빌드할 필요 없는(nonbreaking) 마이너 버전 변경을 자동으로 적용한다.
유지 관리 기간을 매주 30분으로 지정해 유지 관리 작업이 수행되는 시기를 지정할 수 있으며, 유지 관리와 백업을 같은 기간에 지정할 수 있다. 유지 관리 기간을 30분으로 설정해도 작업은 유지 관리 기간을 넘어서 수행될 수도 있다.
nonbreaking upgrade는 데이터베이스의 테이블, 저장 프로시저 등 스키마와 실제 데이터 등을 변경하지 않고 기존에 운영하고 있는 애플리케이션이나 여러 버전의 애플리케이션에 영향을 미치지 않고 데이터베이스 엔진을 업그레이드하는 것을 말한다.
5주 차를 마치며...
AWS RDS를 학습하며 이전에 AMI에 의해 자동으로 스냅샷이 생성된 경험이 있었는데, 이번에 이를 더 깊이 이해하게 되었다. RDS의 백업 및 복구 기능에 대해 학습하면서 데이터베이스를 안전하게 관리하고 복구 시간을 단축시킬 수 있는 방법을 알게 되어 유용했다. 특히, 자동 백업과 수동 스냅샷의 차이점, 그리고 복구 시 활용되는 절차를 배우며 AWS의 이러한 기능은 안정적인 데이터 관리에 유용하다고 생각이 들었다.
