RDS
- AWS Cloud 상에서 만드는 관계형 데이터베이스
- SQL을 사용하며 데이터베이스를 관리하면서도 AWS 서비스를 사용할 수 있어 구조상 큰 이점을 가짐
RDS Engine
- PostgreSQL
- MySQL
- MariaDB
- Oracle
- MS SQL Server
- Aurora (AWS Proprietary Database)
RDS
Database의 프로비저닝은 완전히 자동화되고 기본 운영체제 패치 또한 자동화됩니다.
지속적인 백업과 특정 타임 스탬프(PITR)로 복구가 가능합니다.
모니터링 대시보드를 통해 데이터베이스 성능을 확인할 수 있습니다.
다중 AZ를 설정하여 재해 복구시 유용하게 사용할 수 있습니다.
읽기 전용 복제본을 추가하여 인스턴스 유형을 수직, 수평적으로 확장할 수 있습니다.
스토리지가 EBS를 기반으로 함(gp2 or io1)
RDS 인스턴스에서는 SSH를 따로 가질 수 없음
▷ 관리형 서비스로 RDS는 AWS에서 제공하기 때문에 기본 EC2 인스턴스에 대해서는 사용자가 따로 접근할 권한이 없음.
자동 백업과 자동 생성 기능이 있으며, 정해놓은 기간동안 매일 수행되는 데이터베이스 전체에 대한 백업과
Transaction Log, 즉 일일 트랜잭션 로그가 매 5분마다 RDS에 백업된다.
자동 백업은 기본적으로 7일간 보관되며 최대 35일 보관 가능하다.
데이터베이스 스냅샷은 사용자가 수동으로 발동시키는 백업으로 보관 기관도 임의로 정할 수 있다.
RDS Storage Auto Scaling
: RDS 데이터베이스를 생성할 때는 원하는 스토리지 용량을 지정해야한다.
[예시]
- 스토리지 20GB 지정
- RDS Storage Auto Scaling 옵션이 활성화
> 데이터베이스 사용자가 많아지고 사용 공간이 부족해지면 RDS가 자동으로 스토리지에 대한 스케일링을 수행합니다.
> 스토리지 확장을 하는 동안 데이터베이스는 중단하는 등의 작업은 수행하지 않습니다.Application이 RDS의 데이터에 다량의 읽기/쓰기 작업을 수행할 때 자동으로 임계값을 체크한 다음 스토리지에 대한
자동 스케일링 작업을 RDS가 수행합니다.
RDS의 스토리지에 대한 자동 스케일링 작업을 하기 위해서는 우선 Auto Scaling 옵션이 활성화 되어야 하며,
최대 스토리지 임계값 또한 설정해야 합니다.
사용 가능한 스토리지가 할당된 스토리지의 10% 미안으로 떨어지거나 남은 스토리지 상태가 5분 이상 지속되며,
지난 수정이 6시간 이상 지났을 경우 자동으로 RDS에서 스토리지를 증가시킵니다.
RDS 읽기전용 복제본과 다중 AZ 차이 및 사용 사례에 대해서 확실히 알아야함
메인 데이터베이스 인스턴스가 너무 많은 요청으로 충분히 스케일링 할 수 없을 경우, 읽기만 스케일링 한다고 할 때
읽기 전용 복제본을 최대 5개까지 생성합니다.
동일한 가용영역 또는 가용영역이나 리전에 걸쳐서 생성이 가능합니다.
* 총 3가지 영역
1) 같은 지역, 같은 가용영역(비용발생 X)
2) 같은 지역, 다른 가용영역(비용발생 X)
3) 다른 지역, 다른 가용영역(비용발생 O)
Application에서 데이터를 복제하기 전 읽기 전용 복제본을 읽었다면 모든 데이터를 얻을 수 있음
Read Replica를 만들기 전에 기존 RDS DB Instance에 데이터베이스를 읽어두고 그 다음 복제본을 만든다면
복제본에 접근할 때에도 메인 DB Instance에 있는 모든 데이터를 얻을 수 있다는 것입니다.
다른 앱에서 RDS DB Instance(main database)에 접근하기를 원할 때, 메인 데이터베이스에 이미 App(1)이 붙어있고 그로 인해 과부하가 발생하기도 합니다.
이럴 경우 트래픽 로드 및 용량 과부하, 속도저하 등을 막고자 App(2)는 읽기 복제본 DB 인스턴스에 접근합니다.
읽기 전용 복제본임에도 App(2)는 읽기작업과 분석작업을 수행할 수 있습니다.
단, 읽기 전용 복제본 DB 인스턴스에 접근한 것이기 때문에 Select 명령문에 대해서만 사용 가능합니다.
CUD(Create, Update, Delete)가 진행되지 않는다는 점입니다.
읽기 전용 복제본 DB Instance는 읽기 스케일링에 적합하지만, 메인 데이터베이스로 승격하여 이용할 수 있습니다.
단, 메인 데이터베이스로 승격하여 사용하려면 읽기 권한 외에 다른 권한을 받아야만 승격해 사용할 수 있습니다.
복제본을 메인 데이터베이스로 활용하려면, 화면 상단의 주된 Application에서 모든 연결을 업데이트할 것!
▷ RDS Cluster 상의 읽기 전용 복제본 전체 목록을 메인 데이터베이스로 활용할 수 있습니다.
※ RDS DB Instance Read Replica(읽기 복제본) 네트워크 비용
- AWS에선 하나의 가용영역에서 다른 가용영역으로 데이터가 이동할 때 비용이 발생하지만 RDS 읽기전용 복제본은
관리형 서비스이기 때문에 동일한 Region일 경우 다른 가용 영역이더라도 비용은 발생하지 않습니다.
(같은 Region, 다른 AZ -> Read Replica 사용 : 비용 발생 X)
위 같은 경우 다른 가용영역에서 RDS Instance를 복제하여 사용할지라도, 같은 지역이기 때문에 비용은 발생하지 않습니다.
Cross Region인 경우는 네트워크에 대한 복제 비용이 발생합니다.
RDS 다중 AZ
1) 주로 재해 복구에 사용되며 마스터(메인) 데이터베이스의 모든 변화를 동기화하여 복제합니다.
2) Application의 마스터에 쓰이는 변경 사항이 대기 인스턴스에도 그대로 복제됩니다.
즉, 하나의 DNS 이름을 갖고 Application 또한 하나의 DNS 이름으로 통신하며 마스터에 문제가 발생해도 스탠바이 데이터베이스에서
자동으로 장애 조치를 수행합니다. 이렇게 할 수 있는 이유는 하나의 DNS 이름을 갖기 때문입니다.
3) 가용성을 높이기 위해서 다중 AZ라고 부름
4) 전체 AZ 또는 네트워크가 손실될 때를 대비한 장애 조치
5) 마스터 데이터베이스의 인스턴스 또는 스토리지에 장애가 발생할 경우, 스탠바이 데이터베이스가 새로운 마스터가 될 수 있도록 함
▷ 따로 App에 수동으로 조치할 필요는 없음
- 자동으로 데이터베이스에 연결이 시도되며, 장애 조치가 필요하게 될 때에도 스탠바이가 마스터로 승격하는 과정은 자동으로 이루어짐
- Scaling에도 별다른 조치가 필요 없음
- 스탠바이 데이터베이스는 누구도 읽고 쓰기가 불가능하며 오직 대기용으로 DR 목적으로 진행
Q. 재해 복구를 대비해서 읽기 전용 복제본을 다중 AZ로 설정할 수 있나요?
A. 가능합니다. 읽기 전용 복제본을 다중 AZ로도 설정 가능합니다.
Q. 단일 AZ에서 다중 AZ로 RDS 데이터베이스 전환이 가능하나요?
A. 가능합니다. 단일 AZ에서 다중 AZ로 데이터베이스가 전환될 때 데이터베이스는 중지될 필요도 없고 다운 타임이 전혀 없습니다.
단순히, 수정 버튼을 눌러서 다중 AZ 기능 활성화만 해주시면 됩니다.
▷ RDS 데이터베이스 인스턴스는 마스터를 갖고 동기식 복제본인 스탠바이 데이터베이스를 확보하게 됩니다.
☆ 내부적으로는 RDS가 자동으로 SnapShot을 생성하며 새로운 스탠바이 데이터베이스에 복원합니다.
☆ 스탠바이 데이터베이스에 마스터 데이터베이스 RDS 정보(SnapShot)가 복원되면 두 데이터베이스 간에 동기화가 설정되므로
스탠바이 데이터베이스가 메인 RDS 데이터베이스 내용을 모두 수용하여 다중 AZ 설정 상태가 됩니다.
| 읽기 전용 복제본(RDS DB Instance Read Replica) | RDS 다중 AZ |
| RDS DB Instance를 현재 상태에서 그대로 복제하는데, 비동기적인 복제이기에 복제 이후 데이터가 들어오면 해당 내용은 복제본에 반영되지 않음 |
RDS DB Instance의 모든 변화를 동기적으로 복제하기 때문에 현재 RDS DB Instance의 내용 그대로 동기화되어 사용할 수 있음 (Stand By Instance) |
| 같은 지역이면 네트워크 비용이 발생하지 않으나, 다른 지역이면 네트워크 비용이 발생한다. |
재난 상황에서 마스터 데이터베이스를 보완하고자 다중 AZ가 관리됨 (하나의 DNS 이름을 갖기 때문에 스탠바이 데이터베이스가 마스터 데이터베이스를 자동으로 보완해주고 장애를 조치해줍니다.) |
| 읽기 전용이기 때문에 Select문만 사용 가능하다. | 마스터 데이터베이스와 스탠바이 데이터베이스가 동기화 되어 있고 하나의 DNS 이름을 쓰기 때문에 바로 DR 조치가 되므로 가용성이 높아서 다중 AZ라 부름 |
| 마스터 데이터베이스로 활용 가능하다. 읽기 전용 복제본 또한 마스터 데이터베이스로도 활용할 수 있으며 다중 AZ로도 설정할 수 있습니다. 읽기 전용 복제본은 읽기에 대한 권한만 있기 때문에 다른 권한들을 가질 경우 메인 데이터베이스로 승격할 수 있으며, 승격하게 된다면 복제 매커니즘은 완전히 탈피하게 됩니다. (자체적인 생애주기를 가짐) |
재난 발생으로 마스터 데이터베이스가 먹통일 때, 자동으로 스탠바이 데이터베이스에 연결되고 마스터로 승격하게 됩니다. ☆ 스케일링에 사용되지 않습니다. ☆ 다중 AZ의 대기 목적은 장애 복구 목적이지, 누구나 읽고 쓰고 하는 것이 아닙니다. |
※ RDS: 단일 AZ -> 다중 AZ 전환 가능
- 다운 타임이 전혀 없음(DB Stop X): 데이터베이스 수정 > 다중 AZ 기능 활성화
▷ RDS 데이터베이스 인스턴스는 마스터를 가짐, 동기식 복제본인 스탠바이 데이터베이스를 확보함
- 내부적으로 수행(보이지 않음)
1) 기본 데이터베이스의 RDS가 자동으로 스냅샷을 생성합니다.
2) 생성된 스냅샷은 스탠바이 데이터베이스에 자동으로 복원합니다.
3) 스탠바이 데이터베이스로 복원되면 마스터 데이터베이스와 동기화가 설정되므로 스탠바이 데이터베이스가 메인 RDS 데이터베이스
내용을 모두 수용하기 때문에 다중 AZ 설정 환경이 됩니다.
※ SnapShot을 이용한 데이터베이스 복원
1) Restore to point in time
: 지정한 시점으로 데이터베이스를 복원하는 것
2) Migrate Snapshot
: 다른 Region으로 옮길 때 사용
RDS의 기본적인 목적은 Database를 관리하는 것이고 읽기 전용 복제본이나 다중 AZ를 생성하는 것입니다.
앞으로 인스턴스의 유형은 증가시킬 수 있으며, 관리형 서비스로서 아주 유용한 기능입니다.
RDS Security
1) 미사용 데이터 암호화는 AES 256으로 암호화하는 AWS KMS(AWS Key Management Service)를 통해 암호화됩니다.
KMS를 이용해서 마스터 데이터베이스와 읽기 전용 복제본을 암호화 할 수 있습니다.
- 암호화 실행할 때 실행 시간을 정의해야함 ★
- 마스터 데이터베이스를 암호화 하지 않는다면 복제본 또한 암호화 할 수 없다. (스냅샷으로는 암호화 가능) ★ ★
- Oracle과 SQL 서버에서는 TDE라고 하는 투명한 데이터 암호화를 활성화 할 수 있습니다. (→ 데이터베이스 암호화의 대안을 제공) ★
2) In-Flight Encryption
- SSL 인증서가 필요한 인플라이트(전송중) 암호화가 있음
- 데이터 전송 중에 RDS로 암호화를 사용함(Client -> Database로 데이터 전송할 때)
- 데이터베이스 연결시, 신뢰할 수 있는 인증서로 SSL 옵션을 제공하면 SSL을 연결할 수 있음
- 모든 클라이언트가 SSL을 사용하도록 하려면 PostgreSQL에서는 콘솔 매개변수 그룹을 설정해야 한다.
// PostgreSQL은 콘솔 매개변수로 값을 넘겨야함
rds.force_ssl = I (콘솔 매개변수 그룹 설정)- MySQL은 SQL 명령문을 데이터베이스 내부에서 실행
// MySQL -> DB 내부에 쿼리를 이용해 명령문 전달
Grant USAGE ON *.* TO 'mysqluser'@'%' REQUIRED SSL;
RDS 암호화 작업
1) RDS 백업을 암호화 하는 방법
- 암호화되지 않은 RDS 데이터베이스에서 Snapshot을 생성하면 Snapshot 자체는 암호화 되지 않습니다.
- 암호화된 RDS 데이터베이스에서 Snapshot을 생성하면 Snapshot은 기본적으로 암호화되지만 그것이 기본값은 아닙니다.
▶ 암호화되지 않은 스냅샷을 암호화된 스냅샷으로 복제해야 합니다. (암호화된 버전으로 만드는 과정)
※ 암호화되지 않은 RDS 데이터베이스의 암호화 방법
a. 스냅샷을 생성한다. (RDS Database가 암호화 되지 않아야 함)
b. 생성한 스냅샷을 복제한다.
c. 복제한 스냅샷에 암호화를 활성화한다.
d. 복제된 암호화 스냅샷으로 데이터베이스를 복원한다.
e. 암호화된 RDS 데이터베이스 완성!
▶ 모든 Application을 이전의 암호화되지 않은 RDS 데이터베이스에서 새 암호화된 RDS 데이터베이스로 옮기고
이전 데이터베이스를 삭제한다. ★★
2) 네트워크 & IAM 보안
ㄱ. Network Security
- 네트워크 보안의 RDS 데이터베이스는 보통 Public Subnet이 아니라 Private Subnet에서 배포됩니다.
▶ 데이터베이스가 WWW에 노출되어선 안됩니다. ★
- RDS 보안은 RDS 인스턴스에 연결되어 있는 보안 그룹을 활용하여 실행됩니다.
(= EC2 Instance처럼 인스턴스에 연결된 보안 그룹으룹으로 보안 관리)
- RDS와 통신할 수 있는 IP 또는 보안 그룹을 제어합니다.
ㄴ. Access Management
- IAM 정책: AWS RDS를 관리하는 사람만 제어할 수 있음(RDS api를 통해 진행)
▶ 데이터를 생성 & 삭제가 가능하며, 읽기 전용 복제본 생성 등이 가능합니다.
- 기본 방식으로 데이터베이스를 연결하려면 데이터베이스에 로그인하고자 하는 기존 사용자 이름, 암호를 사용하거나
RDS MySQL과 PostgreSQL인 경우 IAM 기반의 인증 작업으로 진행하면 됩니다.
EC2에서는 IAM Role에서 RDS Service(관리형 서비스 = AWS 서비스)에 접근할 권한 및 정책을 부여한 상태에서 API 콜을 진행합니다.
RDS Service를 호출하면서 응답으로 인증된 토큰을 받고 이 인증된 토큰을 통해 RDS Security Group에 접근합니다.
데이터를 RDS Database에 전달하는 동안 토큰을 함께 보내면서 SSL 암호화 작업을 하여 보냅니다.
연결 자체를 암호화하기에 네트워크 안팎으로 SSL 암호화가 되며 IAM은 데이터베이스 내부에서의 사용자 관리 대신에
서비스 중앙에서 사용자 관리를 하기 때문에 중앙 집중화된 인증 유형입니다.
IAM 역할과 EC2 인스턴스 Profile로 쉽게 통합이 가능하다.
RDS Security 요약
1) 미사용 데이터 암호화
: 데이터베이스 인스턴스를 처음 생성할 때만 생성되며 암호화되지 않았다면 스냅샷을 생성해야 합니다.
스냅샷을 복제하여 암호화한 다음에 이를 가지고 새 암호화된 데이터베이스를 생성해냅니다.
기존 RDS 데이터베이스에 붙어 있던 모든 Application은 새 암호화 된 데이터베이스에 연결하고 이전 데이터베이스는 종료합니다.
2) To-Do
ㄱ. IP 보안그룹, 인바운드 규칙, 사용 가능한 데이터베이스의 보안 그룹을 확인할 것
ㄴ. 내부 데이터베이스의 모든 사용자 생성 및 권한을 관리하거나 MySQL, PostgreSQL용 IAM으로 관리할 것
ㄷ. 퍼블릭 접근을 통하든 통하지 않든 데이터베이스를 생성한 다음에 프라이빗 서브넷이나 퍼블릭 서브넷으로 가게 할 것
ㄹ. 파라미터 그룹과 데이터베이스가 SSL 연결만 허용하도록 구성하여 암호화되는지를 확인할 것(get Auth Token)
3) AWS 책임
ㄱ. SSL 액세스가 발생하지 않도록 구성
ㄴ. DB 패치나 OS 패치를 할 필요가 없음
ㄷ. 기본 인스턴스도 확인하지 않아도 됨
'Cloud' 카테고리의 다른 글
| AWS - Elastic Cache (0) | 2023.01.30 |
|---|---|
| AWS - Aurora (0) | 2023.01.27 |
| AWS - ASG(2) (0) | 2023.01.25 |
| AWS - ASG(1) (0) | 2023.01.19 |
| AWS - Connection Draining (0) | 2023.01.18 |
