RDS + Aurora + ElastiCache

📍 SAA 도전 5일차
📍 Udemy-AWS Certified Solutions Architect Associate 섹션 8

---

Amazon RDS

• RDS는 '관계형 데이터베이스 서비스'의 약자이다.
• SQL을 쿼리 언어로 사용하는 데이터베이스용 관리형 데이터베이스 서비스이다.
  • SQL은 데이터베이스를 쿼리하는 구조화된 언어로 적합하고 많은 엔진 실행에 널리 사용되고 있다.
• 클라우드의 RDS 서비스에 DB를 생성할 수 있고 AWS가 DB를 관리한다. AWS가 관리하는 데이터베이스 엔진 유형으로는 다음과 같다.
  • PostgreSQL
  • MySQL
  • MariaDB
  • Oracle
  • Microsoft SQL Server
  • Aurora(AWS Proprietary database)

EC2 인스턴스에 자체 DB 서비스를 배포하지 않고 RDS를 사용하는 이유

• RDS는 관리형 서비스이다.
  • 데이터베이스 프로비저닝, 기본 운영체제 패치가 완전 자동화되어 있다.
  • 지속적으로 백업이 생성되므로 특정 타임 스탬프, 즉 특정 시점으로 복원할 수 있다.
  • 데이터베이스의 성능을 대시보드에서 모니터링할 수 있다.
  • 읽기 전용 복제본을 활용해 읽기 성능을 개선할 수 있다.
  • 재해 복구 목적으로 다중 AZ를 설정할 수 있다.
  • 유지 관리 기간에 업그레이드를 할 수 있다.
  • 인스턴스 유형을 늘려 수직 확장하거나 읽기 전용 복제본을 추가하여 수평 확장할 수 있다.
  • 파일 스토리지는 EBS에 구성된다.
• 한 가지 단점은 RDS 인스턴스에 SSH 액세스할 수 없다는 점이다.

RDS - Storage Auto Scaling

• RDS 데이터베이스를 만들 때 RDS 스토리지 오토 스케일링 기능이 활성화되어 있으면 RDS가 이를 감지해서 자동으로 스토리지를 확장해 준다.
• 스토리지를 확장하기 위해 DB를 다운시키는 등의 작업을 할 필요가 없다.
• 데이터베이스 스토리지를 수동으로 확장하는 작업을 피할 수 있게 해준다.
• 이를 위해 최대 스토리지 임곗값을 설정해야 한다. 이는 스토리지를 확장할 최대치를 정하는 것이다.
• 할당된 용량에서 남은 공간이 10% 미만이 되면 스토리지를 자동으로 수정한다.
• 스토리지 부족 상태가 5분 이상 지속되거나 지난 수정으로부터 6시간이 지났을 경우 오토 스케일링이 활성화되어 있다면 스토리지가 자동 확장된다.(스토리지 최적화가 최대 6시간 동안 소요되기 때문에 지난 수정으로부터 6시간 이후에 스토리지 오토 스케일링을 수행하는 것 같음)
• 워크로드를 예측할 수 없는 애플리케이션에서 굉장히 유용하다.
• 모든 RDS 데이터베이스 엔진에서 지원되는 기능이다.

RDS Read Replicas for read scalability

• 읽기 전용 복제본은 최대 5개까지 생성할 수 있다.
• 이들은 동일한 AZ 또는 AZ나 리전을 걸쳐서 생성될 수 있다.
• Master RDS 데이터베이스 인스턴스와 두 읽기 전용 복제본 사이에 비동기식 복제가 발생한다.
• 비동기식이란 결국 읽기가 일관적으로 유지된다는 것을 의미한다. 가령 애플리케이션에서 데이터를 복제하기 전 읽기 전용 복제본을 읽어들이면 모든 데이터를 얻을 수 있다. 이것이 바로 일관적인 비동기식 복제의 의미이다.
• 복제본 중 하나를 데이터베이스로도 승격시켜 이용할 수 있다. 즉 이들 복제본 중 하나를 데이터베이스로 사용하고자 하며 그에 대한 권한을 획득하면 이를 데이터베이스로 승격시킬 수 있다. 그 후에 이 복제본은 복제 메커니즘을 완저히 탈피한다. 대신 자체적인 생애 주기를 갖게 된다.
• 읽기 전용 복제본을 사용하려는 경우에는 화면 상단의 주요 애플리케이션에 있는 모든 연결을 업데이터해야 하며 이를 통해서 RDS 클러스터 상의 읽기 전용 복제본 전체 목록을 활용할 수 있다.
• 읽기 전용 복제본은 SELECT문만 필요한 경우에 사용된다.
  

RDS Read Replicas - Network Cost

• AWS에서는 하나의 AZ에서 다른 AZ로 데이터가 이동할 때에 비용이 발생한다. 하지만 예외가 존재하며 이 예외는 보통 관리형 서비스에서 나타난다.
• RDS 읽기 전용 복제본은 관리형 서비스이기 때문에 예외이다.
• 읽기 전용 복제본이 다른 AZ 상에 위치하지만 동일한 리전 내에 있을 때는 비용이 발생하지 않는다.
• 하지만 서로 다른 리전에 복제본이 존재하는 경우 여러 리전을 넘나들어야 하기 때문에 네트워크에 대한 복제 비용이 발생한다.

RDS Multi AZ(Disaster Recovery)

• 다중 AZ는 주로 대해 복구에 사용된다.
• AZ A에 위치한 RDS Master DB 인스턴스를 동기식으로 복제해서 AZ B에 스탠바이 인스턴스로 복제한다. 마스터 데이터베이스의 모든 변화를 동기적으로 복제하는 것인데 이는 애플리케이션의 마스터에 쓰이는 변경 사항이 대기 인스턴스에도 그대로 복제된다는 것을 의미한다.
• 즉 하나의 DNS 이름을 갖고 애플리케이션 또한 하나의 DNS 이름으로 통신하며 마스터에 문제가 생길 때에도 스탠바이 데이터베이스에 자동으로 장애 조치가 수행된다.
• 이를 통해 가용성을 높일 수 있기 때문에 Multi AZ라고 불린다.
• 전체 AZ 또는 네트워크가 손실될 때에 대비한 장애 조치이자 마스터 데이터베이스의 인스턴스 또는 스토리지에 장애가 발생할 때 스탠바이 데이터베이스가 새로운 마스터가 될 수 있도록 하는 것이다.
• 따로 앱에 수동으로 조치를 취할 필요가 없다. 자동으로 데이터베이스에 연결이 시도되고 장애 조치가 필요하게 될 때에도 스탠바이가 마스터로 승격되는 과정이 자동으로 이루어질 테니까 말이다.
• 스케일링에 이용되지 않는다. 스탠 바이 데이터베이스는 단지 대기 목적 하나만 수행한다. 마스터 데이터베이스에 문제가 발생할 경우를 대비한 장애 조치일 뿐이다.
• 읽기 전용 복제본도 장애를 대비하여 다중 AZ로 설정할 수 있다. (일기 전용 복제본 vs Multi AZ의 차이를 묻는 문제가 자주 출제된다)

RDS From Single-AZ to Multi-AZ

• 시험에서 단일 AZ에서 다중 AZ로 RDS 데이터베이스 전환이 가능할지 물을 수 있다.
• 단일 AZ에서 다중 AZ로 전환할 때 다운타임이 전혀 없다는 점을 염두에 둬야 한다.
• 즉 단일 AZ에서 다중 AZ로 전환할 때에 데이터베이스를 중지할 필요가 없다.
• 데이터베이스 수정을 클릭하고 다중 AZ 기능을 활성화시키기만 하면 된다.(버튼만 누르면 알아서 수행됨)
• 이를 통해서 RDS 데이터베이스 인스턴스는 마스터를 갖고 동기식 복제본인 스탠바이 데이터베이스를 확보한다.

<나만의 이해>

• 동기식 복제본 -> 마스터 & 스탠바이 데이터베이스
• 비동기식 복제본 -> 마스터 & 읽기 전용 데이터베이스

RDS Custom

• RDS Custom은 Oracle과 Microsoft SQL Server 두 유형의 데이터베이스를 다룬다.
• RDS Custom 덕분에 이 둘에서 OS 및 데이터베이스 사용자 지정 기능에 액세스할 수 있다.
• RDS를 통해 AWS에서의 데이터베이스 자동화 설정, 운영 그리고 스케일링 장점을 모두 챙길 수 있다.
• RDS Custom 옵션을 추가하면 기저 데이터베이스와 운영체제에 접근할 수 있게 된다.
• 따라서 내부 설정 구성, 패치 적용 그리고 네이티브 기능 활성화가 가능하며 SSH 또는 SSM 세션 관리자를 사용해서 RDS 뒤에 있는 시저 EC2 인스턴스에 액세스할 수 있다.
• 사용자 지정 설정을 사용하려면 RDS가 수시로 자동화, 유지 관리 또는 스케일링과 같은 작업을 수행하지 않도록 자동화를 꺼두는 것이 좋다.
• 이제 기저 EC2 인스턴스에 액세스가 가능하므로 문제가 쉽게 발생할 수 있기 때문에 데이터베이스 스냅샷을 만들어 두는 것이 좋다. 그렇지 않으면 오류가 발생했을 때 복구가 어려울 수도 있다.
• 요약 비교
  • RDS: 데이터베이스 전체와 운영체제가 AWS에 의해 관리된다.
  • RDS Custom: Oracle 및 Microsoft SQL Server에서만 사용 가능하다. 기저 운영 체제와 데이터베이스에 대한 관리자 권한 전체를 갖게 된다.

Amazon Aurora

• Aurora는 AWS 고유의 기술이다. (오픈소스는 아니다)
• Postgres 및 MySQL과 호환되도록 만들었다.
• Aurora 데이터베이스에 호환 가능한 드라이버가 있는데 Postgres 및 MySQL 데이터베이스에 연결하면 작동함을 의미한다.
• 클라우드에 최적화되어 있고 여러 가지 똑똑한 최적화를 통해서 RDS의 MySQL보다 5배 높은 성능이고 RDS의 Postgres보다는 3배 높은 성능이다.
• 단순한 성능뿐 아니라 다양한 개선점들이 있다.
• Aurora Storage는 자동으로 확장한다. 10GB에서 시작하지만 데이터베이스에 더 많은 데이터를 넣을 수록 자동으로 12TB까지 커진다.
• 읽기 전용 복제본의 경우 15개의 복제본을 둘 수 있다. 복제 속도도 훨씬 빠르다.
• Aurora의 장애 조치는 즉각적이다. 따라서 다중 AZ나 MySQL RDS보다 훨씬 빠르다. 그리고 기본적으로 클라우드 네이티브이므로 가용성이 높다.
• 비용은 RDS에 비해 약 20%정도 높지만 스케일링 측면에서 훨씬 더 효율적이다. 따라서 오히려 비용을 절감할 수 있다.

Aurora High Availability and Read Scaling

• Aurora는 특이하게도 3개의 AZ에 걸쳐 무언가를 기록할 때마다 6개의 사본을 저장한다.
  • 따라서 Aurora는 가용성이 높으며 쓰기에는 6개의 사본 중 4개만 있으면 된다. 이는 AZ 중 하나가 없어도 괜찮음을 의미한다.
  • 읽기에는 6개의 사본 중 3개만 있으면 된다. 즉, 읽기 가용성이 높다.
  • 일종의 자가 복구 과정이 있다. 일부 데이터가 손상되거나 문제가 있으면 백엔드에서 P2P 복제를 통한 자가 복구가 진행된다.
  • 그리고 단일 볼륨에 의존하지 않고 수 백개의 볼륨을 사용한다.
    
  • 위의 사진을 보면 파란색 쓰기에 따라 6개의 사본이 저장되었음을 확인할 수 있다. 또한 주황색 쓰기에 따라 6개의 사본이 저장되었음을 확인할 수 있다.
• Aurora는 RDS의 다중 AZ와 유사하다. 쓰기를 받는 인스턴스(master instance)는 하나 뿐이다. 따라서 Aurora에도 마스터가 존재하고 여기서 쓰기를 받게 된다.
• 마스터가 작동하지 않으면 평균 30초 이내로 장애 조치(failover)가 시작된다. 장애 조치가 매우 빠르다.
• 마스터 외에 읽기를 제공하는 읽기 전용 복제본을 15개까지 둘 수 있다. 따라서 복제본을 많이 두고 읽기 워크로드를 스케일링할 수 있다.
• 마스터에 문제가 생기면 읽기 전용 복제본 중 하나가 마스터가 되어 대체한다. 즉, RDS와는 작동 방식이 꽤 다르다. 그러나 기본적으로 마스터가 하나인 건 동일하다.
• 이 복제본들은 리전 간 복제를 지원한다.
• 정리하자면 마스터는 하나고, 복제본은 여럿이며 스토리지가 복제된다. 그리고 작은 블록 단위로 자가 복구 또는 확장이 일어난다.

Aurora DB Cluster

• 전에 언급했듯이 공유 볼륨은 10GB에서 128TB까지 자동으로 확장된다.
• 스토리지에 쓰는 것은 마스터만이 가능하다. 마스터가 바뀌거나 장애 조치가 실행될 수 있으므로 Aurora에서는 Writer 엔드포인트를 제공한다. Writer 엔드포인트는 DNS 이름으로 항상 마스터를 가리킨다. 따라서 장애 조치 후에도 클라이언트는 Writer 엔드포인트와 상호작용하게 된다.
• 전에 언급했듯이 다수의 읽기 전용 복제본이 있다. 읽기 전용 복제본을 15개까지 생성 가능하며 자동 스케일링을 설정해서 항상 적절한 수의 읽기 전용 복제본이 존재하도록 할 수 있다.
• 자동 스케일링이 커져 있는 경우 우리의 앱 입장에서는 복제본이 어디에 있고, URL은 무엇이고 어떻게 연결하는지 파악하기 어려울 수도 있다. 그래서 이를 위한 기능으로 'Reader 엔드포인트'라는 것이 있다. 리더 엔드포인트는 라이터 엔드포인트와 정확히 같은 기능을 한다.
  연결 로드 밸런싱에 도움을 준다. 모든 읽기 전용 복제본과 자동으로 연결된다.
• 따라서 클라이언트가 리더 엔드포인트에 연결될 때마다 읽기 전용 복제본 중 하나로 연결되며 이런 방식으로 로드 밸런싱을 도와준다. 로드 밸런싱이 문장 레벨이 아닌 연결 레벨에서 일어난다는 사실을 꼭 기억해라!

Features of Aurora

• 기능을 더 자세히 살펴보면 이미 언급했던 내용이 나온다.
  • 자동 장애 조치
  • 백업 및 복구
  • 격리 및 보안
  • 산업 규정 준수
  • 자동 스케일링을 통한 버튼식 스케일링
  • 제로 다운타임 자동 패치 설정
  • 개선된 모니터링
  • 통상 유지 관리
  • 백트랙(Backtrack): 과거 어떤 시점의 데이터로도 복원할 수 있게 해준다.

Aurora Replicas - Auto Scaling

• 리더 엔드포인트의 읽기 요청이 많을 때 Amazon Aurora 데이터베이스의 CPU 사용량이 증가한다.
• 이런 상황에서 복제본 자동 스케일링을 설정하면 Amazon Aurora 복제본이 추가된다. 그리고 이 새로운 복제본을 처리하기 위해 자동으로 리더 엔드포인트가 연장된다.
• 그러면 이 새로운 복제본들이 트래픽을 받게 되고 읽기가 좀 더 분산된 형태로 이루어지게 된다. 이를 통해 전반적 CPU 사용량 감소를 기대할 수 있다.
  

Aurora - Custom Endpoints

• 위와 같은 상황이다. 그러나 이번에는 두 종류의 다른 복제본이 있다. 일부 복제본은 다른 복제본보다 크기가 크다.
• 이렇게 하는 이유는 Aurora 인스턴스의 서브셋을 사용자 지정 엔드포인트로 정의하기 위해서이다. 이 특정 복제본에서 특정 쿼리를 실행하는 게 더 나을 수도 있기 때문이다.
• 따라서, 이렇게 사용자 지정 엔드포인트를 정의할 수 있다.
• 그리고 일반적으로 사용자 지정 엔드포인트를 정의하면 리더 엔드포인트는 사용하지 않는다.리더 엔드포인트가 사라지지는 않지만 더 이상 사용하지 않게 된다.
  
  

Aurora Serverless

• 이는 실제 사용량에 기반한 자동 데이터베이스 인스턴스화와 자동 스케일을 가능하게 해준다.
• 이는 비정기적 간헐적, 또는 예측 불허한 워크로드에 유용하다.
• 용량 계획을 세울 필요가 전혀 없다.
• 각 Aurora 인스턴스에 대해 매 초당 비용을 지불하게 된다. 비용 면에서 훨씬 효율적이다.
• 원리를 살펴보면 클라이언트는 Aurora 관리 하위 프록시 플릿과 소통한다. 그리고 백엔드에서 워크로드에 기반해 서버리스 방식으로 여러 Aurora 인스턴스가 생성된다. 따라서 용량을 미리 확보할 필요가 없다.
  

Aurora Multi-Master

• 멀티 마스터는 라이터 노드에 대한 즉각적인 장애 조치로 라이터 노드에 높은 가용성을 갖추고자 할 때 사용한다.
• 이 경우 Aurora 클러스터의 모든 노드에서 읽기 및 쓰기가 가능하다.

Global Aurora

• Aurora 리전 간 복제본은 재해 복구에 많은 도움이 되며 간단하게 생성 가능하다.
• 하지만 최근에는 Aurora Global 데이터베이스를 만드는 것을 권장하고 있다.
• Global Aurora의 경우 모든 쓰기 및 읽기가 진행되는 하나의 기본 리전이 있다. 복제 지연이 1초 미만인 보조 읽기 전용 리전을 다섯 개까지 설정할 수 있고 각 보조 지역마다 읽기 전용 복제본을 16개까지 생성 가능하다.
  • 이렇게 하면 세계 각지에 있는 읽기 전용 복제본의 지연 시간을 단축할 수 있다.
  • 또한 한 리전의 데이터베이스가 작동 중단될 경우 재해 복구 목적으로 다른 지역을 승격하는데 필요한 RTO(복구 시간 목표)는 1분 미만이다.
  • 이는 다른 리전으로 복구하는 데 1분도 걸리지 않는다는 뜻이다.
• 따라서, Aurora Global 데이터베이스에서 리전에 걸쳐 데이터를 복제하는데 걸리는 시간은 평균 1초 미만이다.

Aurora Machine Learning

• Aurora는 AWS 내의 머신 러닝 서비스와의 통합을 지원한다.
• Aurora 머신 러닝의 개념은 ML 기반 예측을 SQL 인터페이스로 애플리케이션에 적용하는 것이다.
• Aurora와 다양한 AWS 머신 러닝 서비스를 쉽고 최적화된 방식으로 안전하게 통합할 수 있다.
• 지원하는 두 서비스가 있다.
  • 백엔드에서 어떤 머신 러닝 모델이라도 사용할 수 있게 해주는 sageMaker
  • 감정 분석에 사용하는 Amazon Comprehend이다.
• Aurora ML을 사용하기 위해 머신 러닝 경험은 필요하지 않다.
• 활용 예시로는 감지 맞춤 광고, 감정 분석, 제품 추천 등이 있다.
  

RDS Backups

• 자동 백업
  • 이는 RDS 서비스가 자동으로 매일 데이터베이스 유지 관리 시간에 데이터베이스 전체를 백업한다는 뜻이다.
  • 거기에 더해서 5분마다 트랜잭션 로그도 백업된다. 이는 가장 최신 백업이 5분 전임을 뜻한다. 따라서, 이 기능을 사용하면 5분보다 이전의 어떤 시점으로도 복구가 가능하다.
  • 자동 백업 보유 기간은 1일에서 35일까지로 설정할 수 있다. 0으로 설정해서 자동 백업을 비활성화할 수 있다.
• 수동 DB 스냅샷 생성
  • 사용자가 수동으로 트리거해야 한다.
  • 하지만 수동 백업은 원하는 만큼 오랫동안 보유할 수 있다는 장점이 있다.
  • 자동 백업은 기간이 지나면 사라지지만 수동으로 만든 DB 스냅샵은 원하는 기간 동안 보유가 가능하다.
• 트릭: 멈춘 RDS 데이터베이스의 경우, 스토리지에 대한 비용을 지불해야 한다. 만약 오랫 동안 멈춰야 한다면 snapshot & restore하는 방법을 택하자. 스냅샷의 비용은 RDS 데이터베이스 스토리지 보다 훨씬 저렴하다.

Aurora Backups

• 자동화된 백업
  • 1 ~ 35일까지 보유 가능한 자동 백업, 비활성화는 불가능
  • RDS에서는 비활성화가 가능하지만 Aurora에서는 불가능하다.
  • 지정 시간 복구 기능(정해진 시간 범위 내의 어느 시점으로도 복구가 가능하다)
• 수동 DB 스냅샷
  • 사용자가 수동으로 만들 수 있다.
  • 원하는 기간 동안 보유 가능하다.

RDS & Aurora Restore options

• RDS & Aurora의 백업 또는 스냅샷을 새로운 데이터베이스로 복원할 수 있다.
  • 자동 백업이나 수동 스냅샷을 복원할 때마다 새로운 데이터베이스가 생성된다.
• 또 다른 방법으로는 S3로부터 MySQL RDS 데이터베이스를 복원할 수 있다. S3는 AWS 클라우드에 객체를 저장하는 매우 인기있는 서비스이다.
  • 기본적인 개념은 온프레미스 데이터베이스의 백업을 만들어서 객체 스토리지인 Amazon S3에 두는 것이다.
  • 그리고 마지막으로 RDS에는 Amazon S3에서 MySQL을 실행 중인 새로운 RDS 인스턴스로 백업 파일을 복원하는 방법이 있다.
• S3로부터 MySQL Aurora 클러스터로 복구하고 싶으면 온프레미스 데이터베이스를 외부로 다시 백업하고 Percona XtraBackup이라는 소프트웨어를 사용하면 된다.

Aurora Database Cloning

• 기존의 데이터베이스로부터 새로운 AuroraDB 클러스터를 만들 수 있다.
• 스냅샷을 만들고 복원하는 것보다 복제한 Aurora를 사용하는 편이 더 빠르다.
• 새 데이터베이스는 같은 클러스터 볼륨을 사용하며 이것이 더 빠른 이유이다.
• 따라서, 데이터베이스 복제는 매우 빠르고 비용 면에서 효율적이며 프로덕션 데이터베이스에 영향을 주지 않는다.