5. AWS RDB 기초 (AWS Certified Developer Associate)

1. Relational Databasee Service(RDB)

 관계형 데이터베이스 서비스이며 SQL을 쿼리 언어로 사용하는 DB를 위한 관리형 DB이다. SQL은 DB Query를 위한 구조적 언어이면 적용이 용이해 많은 엔진에서 사용되고 있다. 이를 이용해 Cloud DB를 생성할 수 있고 AWS상에서 관리되어 여러 이점이 많다.

AWS RDB의 유형으로는 PostgerSQL,MySQL,MariaDB,Oracle,Microsoft SQL Server,Aurora까지 다양하게 존재한다.

 

2. 인스턴스 내에 자체 DB를 배포하지 않고 RDB를 사용하는 이유

- RDS는 관리형 서비스이다.

 - 해당 DB의 프로비저닝과 기본 OS 패치가 자동화되어있다.

 - 지속적인 백업이 수행되며 특정 타임스탬프도 복구가능하다(지정 시간 복구 즉 RITR이라고도 함)

 -  모니터링 대시보드를 통해 DB 성능을 확인 할 수 있다.

 - 다중 AZ를 설정 할 수 있다.

 - 인스턴스 유형을 늘려 읽기 전용 복제본을 추가함으로써 인스턴스 유형의 수직 및 수평 확장성을 증가시킬 수 도 있다.

 - 스토리지가 EBS기반으로 하는데 gp2 볼륨 또는 io1을 뜻한다.

단>>> SSH를 따로 가질 수 없다. :::> 이는 관계형 서비스로 AWS에서 제공되믄로 EC2 인스턴스에 대해서는 사용자가 따로 접근 권한을 갖지 않기 떄문이다. BUT EC2에 자체 DB 엔진을 배포하려면 어차피 모든 사항을 따로 설정해야되므로 큰 애로사항은 아니다.

 

3. RDS 백업

- RDS 자동으로 활성화된 자동 생성 백업 

 정의해둔 유지 관리 기간 동안 매일 수행되며 DB체에 대한 백업과 트랙잭션 로그가 RDS에 백업된다. 그러므로 특정 시점으로든 DB를 복원 가능하다. 기본적으로 7일간 보간되며 최대 35일까지 가능하다.

- DB snapshots:

 사용자가 수동을 발동시키는 백업방식으로 보관 기간을 임의로 설정 가능하다.

 

**시험출제 가능성**

RDS Storage Auto Scaling

- RDS를 생성할 때는 원하는 스토리지 용량을 지정한다. 만약 DB 사용량이 많아 기존 스토리지 공간이 부족해지는 경우 Auto Scaling을 활성화 할 수 있다. 따라서 스토리지 확장을 위해 DB를 중단하는 등의 작업을 수행할 필요가 없다는 장점을 갖는 것이다.

이를 위해 최대 스토리지 임계값을 설정해야한다!! -> N% 미만으로 낮은 스토리지 상태가 특정 시간동안 지속된다면 자동으로 스토리지를 정하게 된다. :: 워크로드를 예측할 수 없는 애플리케이션엔 아주 유리한 기능이다.

 

 

4. RDS read Replicass과 다중 AZ의 차이

4-1. 읽기전용 RDS Replicas

 아래 그림을 보며 설명을 해보자. 먼저 애플리케이션관 RDS DB 인스턴스가 있다. 이때 애플리케이션은 DB 인스턴스에 W/R를 수행한다. 하지만 주 DB가 너무 많은 요청을 받게되 충분한 스케일링을 할 수 없는경우 이를 해결하기 위해 최대 5개의 읽기전용 Replicas를 생성할 수 있다. 이들은 동일한 가용 영역 또는 리전을 걸처 생성될 수 있다. 

**중요 옵션 3가지

1. 주된 RDS와 읽기전용 Replica 사이엔 async(비동기식)복제가 발생한다. :::> 즉 읽기가 일관적으로 유지된다. (비동기식 복제)

2. DB로 승격시켜 이용이 가능하다. ::> Reclica중 특정 DB를 R/W RDS로 권한을 부여할 수 있다. --> 자체적인 생애 주기를 갖게됨

3. Reclicas를 사용하기 위해선 주 애플리케인션에 있는 모든 연결을 업데이트 해야된다. ::> RDS 클러스터 상의 읽기 전용 복제본 전체 목록을 활요할 수 있음

 

- 대표적 사례

메인 RDS는 Production 애플리케이션(App)에 R/W를 수행하고 있다. 이때 새로운 팀이 메인 RDS의 데이터를 기반으로 몇가지 보고와 분석을 실시하고자 한다. 하지만 메인 RDS에 연결을 한면 오버로드가 발생하고 production App의 속도가 느려진다.

이떄 우리가 사용할 수 있는 것이 읽기전용 Replica이다. 먼저 메인 RDS에서 async식 복제를 하는 읽기전용 Replica DB를 생성한다. 그리고 새로운 팀에게 Replica DB를 연결시켜준다. 그렇게되면 production App의 속도는 유지되고 메인 DB는 오버로드가 발생하지 않은체로 새팀은 올직 Replica DB의 데이터를 SELECT하며 App을 진행시키면된다.

 

 - RDS Read Replica의 네트워크 비용

  1. 같은 리전, 다른 가용 영역(AZ)

    같은 리전상에 읽기전용 Replica DB를 생성하고 해당 DB에 데이터를 전송하는 경우는 비용이 발생하지 않는다. 그 이유는 RDS는

    관리형 서비스 이기때문이다.

   2. 다른 리전...

    결론은... 비용이 발생한다..  그 이유는 데이터를 복제하기 위해 여러 리전을 넘나들어야 하기 때문에 네트워크에 대한 복제 비용이

    발생한다.

비용...

4-2. 다중 AZ

- 주로 대해 복구에 사용된다.

이역시 아래 그림을 예시로 설명을 해보자!!

먼저 한 App은 AZ A에서 읽기/쓰기를 수행하는 마스터 DB의 인슷턴스와 연결돼있다. 그리고 sync(동기식)로 AZ B에 스텐바이 인스턴스로 복제한다. 마스터 DB의 모든 변화를 동기적으로 복제하는 것인데 이는 App에서 쓰이는 변경사항이 대기 인스턴스에도 그대로 복제된다는 것을 의미한다. 즉 하나의 DNS를 갖고 App은 DNS로 통신하며 마스터에 문제가 생길 때 스텐바이 DB를 새로운 마스터로 승격시켜 장애를 자동을 조치할 수 있다. 이를 통해 가용성을 높일 수 있어 다중 AZ라고 불린다.

그렇다면 재해 복구를 대비해 읽기 전용 Replicas를 다중 AZ로 설정할 수 있을까???----> 당연 가능하다.

 

단일 AZ에서 다중 AZ로 RDS DB전환이 가능하냐??

-- > 가능

- 이때 작업을 수행하며 DB를 중지할 필요가 없는의미로 다운타임이 전혀 없다는 말을 기억하자.

내부적 발생 상황

- 메인 RDS가 자동으로 Snapshot을 생성한다. 이 Snapshot은 새로운 스탠바이 DB에 복원된다. 스탠바이 DB가 복원되면 두 DB간 동기화가 설정되므로 메인 DB의 내용을 모두 수용하게된다. 즉 다중 AZ가 된다는 말이다...

 

 

 

5. RDS 암호화 + 보안

5-1. Encryption (암호화)

5-1-1. At rest encryption(미사용 암호화)

- master DB와 read Replicas DB를 암호화할 수 있다. (AES 256비트 암호화를 사용하는 AWS Key managemenet serve ::>> KMS로 가능함 )

- 암호화 실행 시  실행 시간을 정의해야된다,

- 만약 마스터 DB를 암호화하지 않았으면 Replicas DB또한 암호화할 수 없다.

- Oracle과 SQL 서버에서 TDE라는 Transparent Data Encryption이란 암호화를 활성 할 수 있고 이는 DB 암호화의 대안을 제공한다.

5-1-2. In-fligth Encryption

 - 클라이언트와 통신중인 RDS에 데이터를 암호화하기 위해 암호화할 SSL 인증서

 -  DB연결 시 신뢰할 수 있는 인증서로 SSL 옵션을 제공할 수 있다.

 - 모든 클라이언트가 SSL을 사용하도록 하려면?

   - PostgreSQL은 rds.force_ssl=1을 콘솔 매개변수 그룹안에 설정 :::> 매개변수 그룹

   - MySQL은 GRANT USAGE ON *.* TO 'mysqluser'@'%' REQUIRE SSL이란 명령문을 DB 내부에서 실행해야됨 :::> 명령문 

 -  Encrypting RDS 백업

: 암호화가 되지 않은 RDS에서snapshots을 생성하면 스냅샷 자체는 암호화가 되지 않는다. 반대로 암호화된 RDS에서 snapshots을 생성하면  암호화된 스냅샷을 얻을 수 있다.(이것은 기본값이지 항상은 아니다)

 - 암호화되지 않은 RDS DB에서 암호화된 RDS 생성 방법

: 먼저 암호화되지 않은 RDS으로 스냅샷을 생성한다. 그러면 암호화되지 않은 스냅샷이 생성되는데 이것을 복제할떄 암호화를 해준다. 다음으로 암호화된 스냅샷으로 RDS를 복제하면 암호화된 RDS 생성 성공!!! 

**이떄 주의할 점은 암호화되지 않은 RDS에서 암호화된 RDS로 데이터를 옯기고 기존 DB느 삭제해야된다.

 

5-2. RDS Network & IAM

5-2-1. Network 보안 RDS

: 대개 퍼블릭 서브넷이 아닌 프라이빗 서브넷에서 배포된다. 그렇기 떄문에 www에 노출되지 않도록 주의하고 RDS보안은 RDS 인스턴스에 연결되어 있는 보안 그룹을 활용해 실행된다. 그리고 RDS와 통신할 수 있는 IP 또는 보안 그룹을 제아한다.

5-2-2. IAM 정책

: 액세스 관리에 사용되면 AWS RDS를 관리하는 사람만 제어할 수 있다. IAM 정책을 통해 데이터를 생성,삭제 기능과 읽기 전용 Replicas를 생성하는 등의 관리 권한을 얻을 수 잇다.

- IAM 정책을 사용하게되면 인증 토큰이란 것을 통해 RDS의 권한을 접근할 수 있다. life time : 15분

- 아래 그림을 기준으로 설명해보면. EC2 보안 그룹에 IAM 역할이 있는 EC2가 있고, RDS 보안그룹에는 MySQL RDS가 있다고하자. 이때 EC2는 MySQL에 접속하기위해 인증 토큰을 발급받아야 된는데 이때 필요한게 IAM 정책이다. EC2 사용자는 IAM 정책에 특정 권한을 통해 RDS 서비스를 사용할 수 있어 인증 토큰을 발급받는 API를 통해 토큰을 발급받는다. 그런뒤 발급 밥은 토큰을 가지고 MySQL에 접근 할 수 있다.

::: 이러한 접근법의 장점은 네트워크 안팎이 SSL로 암호화된다는 점이다.

> IAM은 DB 내부에서의 사용자 관리 대신 중앙에서의 사용자 관리에 사용한다. 즉 좀더 중앙 집중화된 인증 유형인 셈이다.

> IAM역할과 EC2 인스턴스 프로파일로 쉽게 통합할 수 있다.

 

정리

1.  Encryption at rest:

- DB 인스턴스를 처믕 생설할 때만 실행되며 암호화되지 않았으면 스냅샷을 생성해 이를 복제해 암호화 스냅샷을 만들어 새 DB를 생성하면 DB르 암호화하게 된다.

2. Your responsibility:

- 포트/IP 보안 그룹/ 인바운두 규칙/사용 가능한 DB의 보안 그룹을 체크해야된다.

- 내부 DB의 모든 사용자 생성 및 궈한을 관리해야됨

- 퍼블릭 엑세스가 있고 없고는 DB를 생성해 프라이빗 서브넷이나 퍼블픽 서브넷에 따라 정의됨

- 파라미터 그룹과 DB가 SSL 연결만 허용하도록 구성되어 암호화되는지 확이 해야됨

3. AWS responsibility:

- SSH 엑세스 발생

- DB or OS 패치 

- 기번 인스턴스 확인