[AWS] Amanzon RDS

RDS(Relational Databases Service)

• 관계형 데이터 베이스 서비스의 약자이다.
• SQL을 쿼리 언어로 사용하는 데이터베이스에 대한 관리형 데이터베이스 서비스를 의미한다.
   (cf : SQL은 데이터베이스를 쿼리하는 구조화된 언어이다.)
• 클라우드에서 RDS 서비스인 데이터베이스를 만들 수 있다. 이러한 데이터베이스는 AWS에서 관리된다.
  AWS에서는 밑의 다양한 유형의 데이터베이스 엔진을 관리한다.
    - PostgreSQL
    - MySQL
    - Oracale
    - Microsoft SQL Server
    - IBM DB2
    - Aurora(AWS의 독점 데이터베이스)

 

EC2 인스턴스 위에 자체 데이터베이스 서비스를 구축하는 대신 RDS를 사용하는 이유는 무엇일까?

• 왜냐면 RDS는 관리형 서비스이기 때문에 AWS는 단순히 데이터베이스를 제공하는 것 외에도 많은 서비스를 제공한다.
   - 데이터베이스 프로비저닝은 완전히 자동화되어 있으며, 기본 운영 체제 패치도 마찬가지이다.
   - 지속적인 백업이 이루어지고 있으며, 특정 타임 스탬프로 복원할 수 있다.
     (= '특정 시점 복원'이라 한다.)
   - 모니터링 대시보드를 사용하여 데이터베이스 성능을 볼 수도 있다.
   - 읽기 성능을 향상시키기 위해 다중 가용 영역을 설정할 수 있다.
   - 업그레이드를 위한 유지보수 창이 있다.
   - 인스턴스 유형을 늘려 수직적으로 확장하고 읽기 전용 복제본을 추가하여 수평적으로 확장할 수 있는 기능이 있다.
   - 스토리지는 EBS의 지원을 받는다.
• 그러나, 가지고 있지 않은 유일한 것은 인스턴스, 즉 RDS 인스턴스에 SSH를 적용할 수 없다는 것이다.
   = 관리형 서비스이기 때문에 AWS는 사용자에게 서비스를 제공하지만 우리는 기저 EC2 인스턴스에 액세스 할 수 없다.

 

RDS - Storage Auto Scailng

• 예측할 수 없는 업무량을 가진 애플리케이션에 매우 유용하며, RDS용 모든 데이터베이스 엔진을 지원한다.
• RDS 데이터베이스를 생성할 때 원하는 스토리지 용량을 지정해야 한다는 것이다.
   : 예를 들어, 20GB의 스토리지를 원하지만 데이터베이스를 많이 사용하고 있어, 여유 공간이 부족하다고 가정해보자. 그런 다음 이 기능을 사용하면 RDS 스토리지가 자동으로 스케일링된다. 그래서 스토리리지를 늘리기 위해 데이터베이스를 중단하는 등의 작업을 할 필요가 없습니다.
• 밑의 이미지 예시의 모든 것은 데이터베이스 스토리지를 수동으로 스케일링하는 작업을 방지하기 위한 것이다.
  그래서 이를 위해서 최대 저장 임계값을 설정해야 한다.
    (= 스토리지 확장을 원하는 최대 한도를 의미한다.)
• 밑에와 같은 경우, 스토리지를 자동으로 수정한다.
    - 할당된 저장 공간의 10%미만이 남는 경우
    - 부족한 저장 공간이 5분 이상 지속되는 경우
    - 마지막 수정 이후 6시간이 지났을 경우

(출처 : 구글이미지)

• 애플리케이션이 RDS 데이터베이스에 대해 많은 읽기 및 쓰기를 수행한 다음, 일부 임계값을 사용하여 자동으로 확인한다는 것이다. 그러면 스토리지가 자동으로 스케일링 될 수 있다.

 

RDS Read Replicas for read scalability(RDS 읽기 전용 복제본)

• 밑의 이미지를 보면 애플리케이션과 RDS 데이터베이스 인스턴스가 있다.
  애플리케이션은 데이터베이스 인스턴스에 대해 읽기와 쓰기를 수행한다.
  하지만 주된 데이터베이스 인스턴스가 너무 많은 요청을 받아서 충분히 스케일링 할 수가 없기에 읽기를 스케일링 하고자 한다.
   - 이때, 읽기 전용 복제본을 최대 15개까지 생성할 수 있으며, 이들은 동일한 가용 영역 또는 가용 영역이나 리전을 걸쳐서 생성될 수 있다.
• RDS 비동기식 복제와 읽기 전용 복제본 활용
    - 비동기식 복제
         : 주된 RDS 인스턴스와 두 개의 읽기 전용 복제본 간에 비동기식 복제가 이루어집니다. 이는 읽기 일관성이 보장되어 복제되기 전에 읽기 전용 복제본을 통해 데이터를 읽더라도 모든 데이터를 얻을 수 있음을 의미합니다.
     ( cf : 비동기식이란, 읽기가 일관적으로 유지된다는 것을 뜻한다.)
    - 읽기 스케일링
         : 읽기 전용 복제본은 주로 읽기 작업의 부하를 분산하기 위한 목적으로 사용됩니다. 이 복제본은 읽기 성능을 높이는 데 적합합니다.
   - 복제본 승격
         : 필요에 따라 읽기 전용 복제본 중 하나를 데이터베이스로 승격할 수 있습니다. 승격된 복제본은 독립적인 데이터베이스로 동작하며 복제 메커니즘에서 벗어나 자체 생애 주기를 갖습니다.
   - 애플리케이션 업데이트
         : 복제본을 사용할 때는 애플리케이션의 모든 연결을 업데이트하여 RDS 클러스터 내의 읽기 전용 복제본 전체 목록을 사용할 수 있도록 해야 합니다.

(출처 : 구글이미지)

• 사용 사례
    - 상황
          : 프로덕션 데이터베이스에서 메인 RDS 인스턴스가 읽기 및 쓰기를 처리하고 있는 상황에서 새로운 팀이 데이터를 기반으로 보고와 분석을 진행하려고 합니다.
    - 문제
          : 보고 애플리케이션이 메인 데이터베이스에 연결되면, 오버로드로 인해 생산 애플리케이션의 성능이 저하될 수 있습니다.
    - 해결
          : 이를 방지하기 위해 읽기 전용 복제본을 생성하여 새로운 워크로드에 대한 읽기 작업과 분석을 복제본에서 처리하게 합니다. 이렇게 하면 생산 애플리케이션의 성능에 영향을 주지 않고 보고 작업을 수행할 수 있습니다.
    - 제약
          : 읽기 전용 복제본에서는 SELECT 명령문만 사용할 수 있으며, INSERT, UPDATE, DELETE 같은 데이터 변경 작업은 불가능합니다.

(출처 : 구글이미지)

 

 

RDS Read Replicas - Network Cost(네트워킹 비용)

• AWS에서는 하나의 가용 영역에서 다른 가용 영역으로 데이터가 이동할 때에 비용이 발생하는데, 
  예외가 존재하며 이 예외는 보통 관리형 서비스에서 나타난다.
  바로 RDS 읽기 전용 복제본은 관리형 서비스이다.
• 읽기 전용 복제본이 다른 AZ 상이지만 동일한 리전 내에 있을 때는 비용이 발생하지 않는다.

(출처 : 구글이미지)

• us-east-1a에 RDS DB 인스턴스가 있고, 그에 대한 읽기 전용 복제본은 us-east-1b에 있다고 하면
  이는 비동기식 복제로 읽기 전용 복제본의 복제 트래픽이 하나의 AZ에서 다른 AZ로 넘어가더라도 RDS가 관리형 서비스이기 때문에 해당 트래픽은 비용 없이 무료로 이동이 가능하다.
• 하지만, 두번째 이미지처럼 서로 다른 리전에 복제본이 존재하는 경우, 
  즉, us-east-1a에 대해서 복제본이 eu-west-1에 존재하는 경우에는 RDS DB 인스턴스와 읽기 전용 복제본이 여런 리전을 넘나들어야하기 때문에 네트워크에 대한 복제 비용이 발생한다.

 

RDS Multi AZ (Disaster Recovery 재해복구)

• RDS 다중 AZ는 재해 복구를 목적으로 사용된다. 주 인스턴스가 읽기와 쓰기를 처리하며, 이를 동기식으로 다른 가용 영역(AZ B)에 있는 스탠바이 인스턴스로 복제합니다.
• 동작 방식
    : 주 데이터베이스의 모든 변경 사항은 동기적으로 스탠바이 인스턴스에 복제됩니다. 하나의 DNS 이름을 사용하여 애플리케이션과 통신하며, 장애가 발생하면 자동으로 스탠바이 인스턴스로 장애 조치가 이루어집니다. 이를 통해 고가용성을 보장합니다.
• 장애 조치 
    : 주 데이터베이스나 스토리지에 장애가 발생하면 스탠바이 데이터베이스가 자동으로 마스터로 승격되며, 수동 조치는 필요하지 않습니다. 이 과정은 애플리케이션이 자동으로 처리합니다.
• 스케일링과 무관
    : 스탠바이 데이터베이스는 읽기 및 쓰기가 불가능하며, 단지 장애 대비용으로 존재합니다. 이는 스케일링과는 무관합니다.
• 읽기 전용 복제본 
    : 원하는 경우 읽기 전용 복제본도 다중 AZ로 설정하여 재해 복구를 지원할 수 있습니다.

(출처 : 구글이미지)

 

 

RDS - From Single-AZ to Multi AZ

• 단일 AZ에서 다중 AZ로 전환할 때에 데이터베이스를 중지할 필요가 없다.
• 데이터베이스 수정을 클릭하고 다중 AZ 기능을 활성화 시키기만 하면 된다.
    : RDS 데이터베이스 인스턴스는 마스터를 갖고, 동기식 복제본인 스탠바이 데이터베이스를 확보한다.

(출처 : 구글이미지)

• 위의 이미지는 내부적으로 발생하는 일이다.
  기본 데이터베이스의 RDS가 자동으로 스냅샷을 생성한다. 이 스냅샷은 새로운 스탠바이 데이터베이스에 복원된다.
  스탠바이 데이터베이스가 복원되면 두 데이터베이스 간 동기화가 설정되므로 스탠바이 데이트베이스가 메인 RDS 데이터베이스 내용을 모두 수용하여 다중 AS 설정 상태가 된다.

 

RDS Custom

• RDS Custom에서는 기저 운영 체제나 사용자 지정 기능에 액세스 할 수 있다. 
  (원래 RDS는 운영체제나 DB에서 제공하는 사용자 지정 기능에 액세스 할 수 없다.)
• RDS를 통해 AWS에서의 데이터베이스 자동화 설정, 운영 그리고 스케일링의 장점을 모두 챙길 수 있다.
• RDS에 Custom 옵션을 추가하면 기저 데이터베이스와 운영체제에 액세스 할 수 있게 된다.
    - 내부 설정 구성, 패치 적용, 그리고 네이티브 기능 활성화가 가능하며 SSH 또는 SSM 세션 관리자를 사용해서 RDS 뒤에 있는 기저 EC2 인스턴스에 액세스 할 수 있다.
• 사용자 지정 설정을 사용하려면 RDS가 수시로 자동화, 유지 관리 또는 스케일링과 같은 작업을 수행하지 않도록 자동화를 꺼두는 것이 좋다.
• 기저 EC2 인스턴스에 액세스가 가능하므로 문제가 쉽게 발생할 수 있기 때문에 데이터베이스 스냅샷을 만들어두는 것이 권장된다.
• RDS Custom의 두 가지 유형
   - Oracle
   - Microsoft SQL Server
• RDS vs RDS Custom
   - RDS는 데이터베이스 전체를 관리한다. 그래서 운영 체제와 나머지는 AWS에서 관리하고 사용자는 딱히 할게 없다.
   - RDS Custom은 Oracle 및 Microsoft SQL Server에서만 사용할 수 있다. 그리고 기저 운영 체제와 데이터베이스에 대한 관리자 권한 전체를 갖게 된다.