[AWS] RDS와 Aurora란? 쉽게 개념 정리 (Snapshot, Automated Backups, Multi-AZ, Read Replica, 데이터 암호화)

◇  공부 기록용으로 작성하였으니 틀린 점, 피드백 주시면 감사하겠습니다 ◇

 

 

RDS

 

 

RDS (Relational Database Service)

RDS

RDS는 AWS managed의 관계형 데이터베이스 서비스이다.

 

🟦 관계형 데이터베이스(RDB)를 EC2 인스턴스에 직접 설치하여 사용할 수 있는데 왜 RDS를 사용하는가??

RDS를 사용하면 상당히 더 효율적으로 DB를 유지/관리할 수 있다.

왜냐하면 AWS 측에서 상당 부분을 관리해 주기 때문에 개발 측에서 운영 관리 부담을 줄여준다.

아래 이미지는 DB 관리를 위한 책임 영역이다. OS의 설치나 백업과 같이 필수적이지만 귀찮은 부분을 AWS 측에서 해준다.

 

https://docs.aws.amazon.com/prescriptive-guidance/latest/migration-sql-server/comparison.html

 

 

🤨 주의점

그러나 RDS는 사용 가능한 데이터베이스 엔진이나 버전이 제한되어 있기 때문에 커스터마이징이 많이 필요한 경우에는 RDS가 적합하지 않을 수 있다. 

예를 들어 Microsoft SQL Server라는 데이터베이스 엔진에만 있는 특수 기능이 있을 경우, RDS에서 사용 못할 수도 있다.

이러한 기능을 AWS에서 계속 사용하려면, EC2 인스턴스에 Microsoft SQL Server를 설치해서 사용해야 한다.

 

---

RDS의 특징

• 간편한 관리 (Easy to manage)
  • 인프라의 프로비저닝 필요❌, 소프트웨어 패치&관리 필요❌
  • DB 인프라 관리가 쉽다. (AWS가 대신 관리 해준다) 사용자는 애플리케이션 개발에 집중할 수 있다.
• 다양한 엔진 옵션 (Choice of engines)
  • MySQL, PostgreSQL, Oracle, Microsoft SQL Server, MariaDB, Amazon Aurora
    
• 고가용성 (High Availability)
  • 백업 및 복구 (스냅샷)
  • Multi-AZ 기능
  • Read Replica (읽기 전용 복제본)
  • Cross-Region Replication (리전 간 복제)
• 확장성 (Scalability)
  1. 수직적 확장 (Vertical Scaling) :인스턴스의 성능을 향상시키는 방법
     • 인스턴스 유형 변경: 더 높은 성능의 인스턴스 유형으로 업그레이드. 예시) t3.micro → r5.large로 변경
     • 인스턴스 크기 조정: 동일한 인스턴스 유형 내에서 CPU, 메모리, 스토리지 용량을 조정
  2. 수평적 확장 (Horizontal Scaling)
     • Read Replica (읽기 전용 복제본)
     • Sharding (샤딩)

https://aws.amazon.com/rds/?nc1=h_ls

 

 

 

 

RDS 데이터베이스 엔진

사용자는 이러한 엔진 중에서 요구에 맞는 데이터베이스 엔진을 선택할 수 있다.

• MySQL
• PostgreSQL
• Amazon Aurora
• MariaDB
• ORACLE
• Microsoft SQLServer

 

MySQL와 PostgreSQL은 많이 들었는데 Aurora가 뭐지?? 처음 보는데
(요즘 많은 곳에서 Aurora를 사용한다고 들었다.)

 

 

Amazon Aurora란? (오로라)

AWS가 직접 만든 관계형 데이터베이스 엔진이다.

MySQL와 PostgreSQL를 기반으로 호환해서 성능을 높인 엔진이다. 

 

Aurora는 MySQL보다 약 5배, PostgreSQL보다 약 3배 빠른 성능을 갖는다.

Aurora는 불필요한 input/output (I/O)를 줄임으로써, 데이터베이스 비용을 낮출 수 있다고 한다.

 

자세한 내용: Aurora 특징

RDS의 다른 데이터베이스 엔진과 비교했을 때 Aurora의 특징은 다음과 같다:

• 데이터베이스 인스턴스와 스토리지가 분리된 아키텍처
  • 예를 들어 2 개의 데이터베이스 인스턴스가 존재하지만, 수동 데이터베이스 관리가 필요 없는 서버리스 구성이나 최대 15개의 복제 인스턴스(읽기 전용 인스턴스)를 구성할 수도 있다.
    

    

    https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/Aurora.Overview.html

• 여러 데이터 복사본과 자동 복구 기능을 통한 스토리지의 높은 장애 내성
  • 스토리지는 기본적으로 3개의 AZ(가용 영역)에 각각 2개의 데이터 복사본(총 6개)을 생성한다.
  • 이러한 스토리지는 "클러스터 볼륨"이라는 클러스터 구성으로 관리된다.
  • Aurora의 클러스터 볼륨 내 스토리지는 서로를 모니터링하여 데이터 손상이 발생하더라도 자동으로 감지하고 복구한다.
• 복제 인스턴스의 자동 장애 조치를 통한 고가용성
  • 데이터베이스 인스턴스는 쓰기를 담당하는 기본 인스턴스 하나와 최대 15개의 읽기 전용 복제 인스턴스(리드 레플리카)를 생성할 수 있다.
  • 복제 인스턴스는 기본적으로 기본 인스턴스와 다른 AZ에 생성되며, 기본 인스턴스에 장애가 발생할 경우 자동으로 장애 조치(페일오버) 및 기본 인스턴스로의 승격이 이루어진다.
• 데이터베이스 클론의 신속한 생성
  • Aurora에는 데이터베이스 클론(복제)을 생성하는 기능이 있다.
  • 클론은 "Copy-on-Write" 기술로 생성됩니다. Copy-on-Write는 데이터를 복제할 때 실제로는 원본 데이터를 참조하지만, 복제한 것처럼 보이게 하는 기술이다.

 

 

 

 

RDS의 기능 정리

 

⚡ 1. Snapshot (스냅샷)

스냅샷은 DB 인스턴스의 상태를 정적인 이미지로 캡처한 것이다.
→ 즉, DB의 그 시점 상태를 그대로 복사해 저장한 느낌이다.

 

스냅샷은 특정 시점의 DB 상태를 보존하고, 필요한 경우에는 해당 시점으로 DB를 복원할 수 있도록 한다.

일반적으로 스냅샷은 Amazon S3에 저장한다. 스냅샷은 저장용량에 대한 비용이 발생한다.

(RDS를 삭제해도, 스냅샷은 S3 버킷에 그대로 존재)

 

스냅샷을 통해 수동으로 DB 인스턴스를 재생성할 수 있다.

https://aws.amazon.com/blogs/database/amazon-rds-snapshot-restore-and-recovery-demystified/

 

 

 

 

⚡ 2. Automated Backups (자동 백업) 

RDS에서 디폴트로 자동 백업기능이 설정되어 있다. 
정해진 주기(일반적으로 하루에 한 번)에 스냅샷(Snapshot)를 참고해 자동으로 백업한다.

Retention Period(1~35일): 백업 보존 기간은 최대 35일이며, 백업 내용을 통해 과거 DB 상태로 돌아갈 수 있다.

 

하지만 실제로는 다른 DB 인스턴스를 새로 생성해서 스냅샷을 적용시키는 방식이다.

백업 기능을 통해 5분 전 상태로도 돌아갈 수 있다. Retention Period안에 백업 있으면 돌아갈 수 있다.

https://aws.amazon.com/blogs/database/backup-and-restore-strategies-for-amazon-rds-for-sql-server/

RDS는 백업 복원(Restore)시 도메인이 변경된다.
도메인 이름이 변경 되는것에 주의하자.

 

 

 

⚡ 3. Multi AZ (다중 AZ) :  

RDS Multi-AZ Synchronous Replication (동기 복제):
거의 실시간으로 데이터가 다른 AZ에 복제되어 동기화를 유지한다.

 

Multi AZ는 기존의 RDS(Primary)에 추가로 서로 다른 AZ에 걸쳐 하나 더 추가로 RDS(Standby)를 설치한 형태이다.

(RDS는 2개 이상이다. 3개 일수도 있다.)

 

Multi AZ의 RDS는 서로 자동으로 동기화(Sync)되어 있다.

이로써 기존의 RDS에 문제/장애가 있으면 다른 AZ에 있는 RDS로 자동으로 빠르게 전환된다.
→ Disaster Recovery(장애 복구)

참고: Read Replica는 비동기 복제(asynchronous replication)이다.

 

Multi AZ는 AWS에 의해서 자동으로 관리가 이루어진다.

• 기본적으로 애플리케이션에서 RDS(Standby)는 접근 불가이다.
• 기존의 RDS(Primary)에 장애 발생 → Failover
  • 자동으로 DNS를 RDS(Standby)로 연결해 준다.
  • 기존의 RDS(Primary)와의 연결을 끊는다.
• 굉장히 빠른 속도로 장애복구 가능하다.

Failover: 서버에 장애가 생겼을 때 미리 준비해둔 서버로 전환
Failback: 다시 기존의 서버로 전환

 

 

 

⚡ 4. Read Replica, RR

읽기 전용 복제본을 여러 개 생성하여 읽기 작업을 분산

RDS를 생성하면 기본적으로 RDS Primary만 생성된다.

이때 RDS의 읽기 작업 성능을 향상하고 싶으면 Read Replica라는 기능을 활용하면 된다.

 

쓰기 작업은 RDS Primary에서 처리하고, 읽기 작업은 Read Replica에서 처리한다.

이를 통해 읽기 작업의 부하를 분산하여 시스템 성능을 향상할 수 있다.

이렇게 데이터베이스를 복제하여 쓰기와 읽기를 분별하여 트래픽을 분산하는 기술을 DB Replication이라고 한다.

• RDS Primary: 읽기와 쓰기 작업을 모두 처리한다. (모든 쓰기 작업은 여기서 수행된다)
• Read Replica: 읽기 작업만을 처리한다.
  • RDS Primary를 비동기적으로 복제한다.
  • 변경 사항이 동기화되므로 Read Replica도 최신 변경 데이터를 읽을 수 있다.
  • Aurora 클러스터는 최대 15개 생성 가능
  • MySQL, MariaDB, PostgreSQL는 인스턴스 당 최대 5개 생성 가능

👩‍🏫 Failover의 상황
RDS에서 Master DB 인스턴스가 failover(장애 전환)되었을 경우, Read Replica를 사용하여 애플리케이션이 서비스를 계속할 수 있다. 이때 Read Replica가 자동으로 Master로 승격되어 읽기 작업을 지원할 수 있다.

 

 

⚡ 5. 데이터 암호화

RDS는 DB 인스턴스를 암호화할 수 있다.
DB 인스턴스를 암호화하면 BackUp이나 Snapshot, 로그, Read Replica들도 암호화된다.

📌 암호화 설정 주의점:

• ⚠ RDS 작성 시에 암호화를 유효화 해야 한다.
  • 암호화를 유효화하여 RDS를 생성했다면 나중에 다시 암호화를 무효화할 수 없다.
  • 암호화를 하지 않고 RDS를 생성했다면 나중에 다시 암호화를 추가할 수 없다.
• ⚠ RDS를 작성시에 까먹고 암호화를 안했는데 암호화를 시키고 싶다면, 다음과 같은 절차를 따라야한다
  • RDS의 Snapshot을 생성하기
  • 해당 Snapshot을 복사하면서 암호화 적용하기 
  • 암호화된 Snapshot으로 새로운 인스턴스 생성하기.

📌 데이터 암호화 방법

• KMS (Key Management Service) 통합:
  • RDS는 AWS KMS를 사용하여 데이터베이스와 스냅샷의 암호화를 지원한다.
  • KMS는 관리형 키와 사용자 관리형 키를 제공하여 사용자가 키를 생성하고 관리할 수 있게 한다.
• AES-256 암호화: RDS는 AES-256 알고리즘을 사용하여 데이터를 암호화한다.

 

 

 

⚡ 6. Delete Protection (삭제 보호 기능)

RDS의 삭제 보호 기능은 실수로 데이터베이스 인스턴스를 삭제하지 않도록 보호하는 기능이다.

이 기능을 활성화하면 삭제 명령을 실행할 때 추가적인 확인 절차를 요구하여 데이터를 안전하게 보호할 수 있다.

 

 

⚡ 7. ACID 특징

관계형 데이터베이스에는 ACID 특성이 있다.

원자성(Atomicity), 일관성(Consistency), 고립성(Isolation), 내구성(Durability)의 앞 글자를 딴 약자로, 데이터베이스의 트랜잭션이 안전하게 수행되기 위한 4가지 필수적인 특성입니다

 

업데이트 처리 중에 불완전한 데이터가 기록되지 않거나, 병렬 처리가 각각 독립적으로 동작(상호 간섭하지 않음)하는 등, 처리의 신뢰성을 보장하는 특성이다.

 

RDS도 관계형 데이터베이스 서비스이므로 ACID 특성을 가지고 있다.

 

 

⚡ 8. Sharding (샤딩)

https://www.digitalocean.com/community/tutorials/understanding-database-sharding

Sharding이란 데이터베이스의 테이블을 여러 개의 작은 테이블로 나누어 저장하는 기술이다.

(딱히 RDS에서만 사용되는 기술은 아니다. 하지만 RDS에서 많이 사용되는 용어이기에 외워두면 좋다)

 

데이터를 여러 데이터베이스 인스턴스에 분산 저장하여 읽기 및 쓰기 성능을 향상한다. 

Sharding은 주로 애플리케이션 레벨에서 구현된다.

 

 

 

⚡ 9. 데이터베이스의 마이그레이션

현재 사용 중인 데이터베이스를 RDS로 마이그레이션 할 때도 가능한 한 수고를 덜 수 있도록 고려되어 있다.
예를 들어, MySQL을 사용하는 경우, 자체 환경에 저장된 백업 데이터를 이용해 마이그레이션을 할 수 있는 기능이 제공된다.
또한, Snapshot을 사용하여 데이터베이스를 복원하거나, 데이터베이스를 다른 DB 엔진으로 마이그레이션 하는 기능도 제공된다

 

예시) MySQL의 Snapshot을 통해 Aurora로 마이그레이션

https://docs.aws.amazon.com/whitepapers/latest/migrating-databases-to-amazon-aurora/rds-snapshot-migration.html

 

 

 

⚡ 10. RDS의 Snapshot(백업) 공유

RDS는 (데이터베이스를 소유하고 있는 AWS 계정과는) 다른 AWS 계정과 RDS의 Snapshot을 공유할 수 있다.
예시) 다른 AWS 계정을 가진 부서에게 DB를 이전하고 싶은 경우, 스냅샷을 공유하고 스냅샷을 통해 DB를 복원하여 사용 가능.

참고로, 스냅샷이 암호화된 경우, KMS Key Policy 설정에서 공유 대상 계정이 KMS 암호화 키를 사용할 수 있도록 허가해야 한다.

 

 

 

⚡ 11. Parameter Group & Option Group

RDS에서 타임존, 최대 연결 수, 감사 로그 활성화 등 데이터베이스 엔진의 내부 설정을 변경하고자 할 때는 Parameter Group 또는 Option Group에서 정의한다.

 

Parameter Group: DB 엔진의 동작을 제어하는 구성 설정 모음

• 기본으로 제공되는 파라미터 그룹과 사용자가 커스터마이징된 파라미터 그룹이 있다.
• 예시) max_connections: 최대 동시 접속 수

 Option Group: RDS 인스턴스에 추가 기능(옵션)을 제공하는 설정 모음.

• 데이터베이스 엔진의 기본 기능 외에 추가적으로 필요한 기능을 활성화할 때 사용한다.

Parameter Group과 Option Group은 DB 엔진별로 생성되는 Parameter 또는 Option의 정의 그룹으로, 생성 후 여러 데이터베이스(또는 데이터베이스 클러스터)에 연결할 수 있다.