[AWS SAA-C03] AWS Aurora 정리

AWS Aurora

• AWS RDS Aurora는 고급 상용 데이터베이스의 속도 및 안정성과 오픈 소스 데이터베이스의 단순성 및 비용 효율성을 결합한 관계형 데이터베이스 엔진이다.
• 완전 관리형 MySQL 및 PostgreSQL 호환 관계형 데이터베이스 엔진으로, MySQL로 개발된 애플리케이션을 거의 또는 전혀 변경하지 않고도 Aurora로 전환할 수 있다.
• 대부분의 MySQL 애플리케이션을 변경할 필요 없이 MySQL의 최대 5배, PostgreSQL의 최대 3배의 성능을 제공한다.
• 프로비저닝, 패치, 백업, 복구, 장애 감지 및 복구와 같이 시간이 많이 걸리는 작업을 RDS가 데이터베이스를 완벽하게 관리한다.
• 데이터베이스 사용량에 따라 데이터베이스 성능에 영향을 주지 않고 10GB에서 128TiB까지 10GB 단위로 스토리지를 자동으로 확장할 수 있다.

Aurora DB Cluster

• Aurora DB 클러스터는 하나 이상의 DB 인스턴스와 해당 DB 인스턴스의 데이터를 관리하는 클러스터 볼륨으로 구성된다.

• 클러스터 볼륨은 여러 AZ에 걸쳐 있는 가상 데이터베이스 스토리지 볼륨으로, 각 AZ에는 DB 클러스터 데이터의 복사본이 있다.

• 두 가지 유형의 DB 인스턴스가 Aurora DB 클러스터를 구성한다.
  = 기본 DB 인스턴스
  읽기 및 쓰기 작업을 지원하며 클러스터 볼륨에 대한 모든 데이터 수정을 수행한다.
  각 DB 클러스터에는 하나의 기본 DB 인스턴스가 있다.
  = Aurora 복제본(Replicas)
  기본 DB 인스턴스와 동일한 스토리지 볼륨에 연결되며 읽기 작업만 지원한다.
  각 DB 클러스터는 기본 DB 인스턴스 외에 최대 15개의 Aurora 복제본을 보유할 수 있다.
  별도의 AZ에 복제본을 배치하여 고가용성 제공
  기본 DB 인스턴스를 사용할 수 없게 되는 경우, Aurora는 자동으로 복제본으로 페일오버한다.
  복제본의 장애 조치 우선순위를 지정할 수 있다.
  복제본은 기본 DB 인스턴스에서 읽기 워크로드를 오프로드할 수도 있다.

• Aurora 멀티마스터 클러스터의 경우
  = 모든 DB 인스턴스는 기본 및 복제본 간에 차이 없이 읽기/쓰기 기능을 갖는다.

• Aurora 연결 엔드포인트
  = Aurora는 단일 인스턴스가 아닌 DB 인스턴스 클러스터를 포하한다.
  = 엔드포인트는 클러스터에 연결하기 위해 지정된 호스트 이름과 포트를 가진 중간 핸들러를 의미한다.
  = Aurora는 엔드포인트 매커니즘을 사용하여 이러한 연결을 추상화한다.

• 클러스터 엔드포인트
  = DB 클러스터의 클러스터 엔드포인트(또는 쓰기 엔드포인트)는 해당 DB 클러스터의 현재 기본 DB 인스턴스에 연결한다.
  = 클러스터 엔드포인트는 읽기 작업뿐만 아니라 DDL 문과 같은 쓰기 작업도 수행할 수 있는 유일한 엔드포인트이다.
  = 각 DB 클러스터에는 하나의 클러스터 엔드포인트와 하나의 기본 DB 인스턴스가 있다.
  = 클러스터 엔드포인트는 DB 클러스터에 대한 읽기/쓰기 연결에 대한 페일오버를 지원한다. DB 클러스터의 현재 기본 DB 인스턴스에 장애가 발생하면 Aurora는 자동으로 새 기본 DB 인스턴스로 페일오버한다.
  = 장애 조치 중에 DB 클러스터는 서비스 중단을 최소화하면서 새 기본 DB 인스턴스에서 클러스터 엔드포인트에 대한 연결 요청을 계속 처리한다.

• 리더 엔드포인트(Reader Endpoint)
  = DB 클러스터용 리더 엔드포인트는 DB 클러스터에 대한 읽기 전용 연결에 대한 로드 밸런싱 지원을 제공한다.
  = 쿼리와 같은 읽기 작업에는 리더 엔드포인트를 사용할 것을 권장한다.
  = 리더 엔드포인트는 읽기 전용 복제본에서 구문을 처리하여 기본 인스턴스의 오버헤드를 줄인다.
  = 각 DB 클러스터에는 하나의 리더 엔드포인트가 있다.
  = 클러스터에 하나 이상의 복제본이 포함된 경우, 리더 엔드포인트는 복제본 간의 각 연결 요청을 로드밸런싱한다.

• 사용자 지정 엔드포인트
  = DB 클러스터의 사용자 지정 엔드포인트는 사용자가 선택한 DB 인스턴스 집합을 나타낸다.
  = Aurora는 로드 밸런싱을 수행하고 그룹에 있는 인스턴스 중 하나를 선택하여 연결을 처리한다.
  = 사용자 지정 엔드포인트가 생성되기 전까지는 사용자 지정 엔드포인트가 없으며, 프로비저닝된 각 클러스터에 대해 최대 5개의 사용자 지정 엔드포인트를 생성할 수 있다.
  = Aurora 서버리스 클러스터는 사용자 지정 엔드포인트를 지원하지 않는다.

• 인스턴스 엔드포인트
  = 인스턴스 엔드포인트는 클러스터 내의 특정 DB 인스턴스에 연결되며, DB 클러스터에 대한 연결을 직접 제어할 수 있다.
  = DB 클러스터의 각 DB 인스턴스에는 고유한 인스턴스 엔드포인트가 있다. 따라서 DB 클러스터의 현재 기본 DB 인스턴스에 대해 하나의 인스턴스 엔드포인트가 있고, DB 클러스터의 각 복제본에 대해 하나의 인스턴스 엔드포인트가 있다.

고가용성 및 복제

• Aurora는 99.99% 이상의 가용성을 제공하도록 설계되었다.

데이터 내구성 및 안정성 제공

• 단일 리전의 가용 영역 3개에 걸쳐 데이터베이스 볼륨을 6가지 방식으로 복제하여 데이터 내구성과 신뢰성을 제공한다.
• 데이터를 S3에 지속적으로 백업한다.
• 물리적 스토리지 장애로부터 투명하게 복구하며, 인스턴스 페일오버는 일반적으로 30초 이내에 완료된다.
• 기본 DB 인스턴스에 장애가 발생하면 기존 복제본을 새 기본 DB 인스턴스로 승격하거나 새 기본 DB 인스턴스를 생성하여 자동으로 새 기본 DB 인스턴스로 페일오버한다.
• 데이터베이스 볼륨을 여러 디스크에 분산된 10GB 세그먼트로 자동 분할한다. 데이터베이스 볼륨의 각 10GB 정크는 3개의 가용성 영역에 걸쳐 6가지 방식으로 복제된다.
• 자가 복구 스토리지를 제공한다. 데이터 블록과 디스크는 지속적으로 오류를 검사하고 자동으로 복구된다.
• 복제본은 기본 인스턴스와 동일한 기본 볼륨을 공유한다. 기본 인스턴스에서 수행한 업데이트는 모든 복제본에 표시된다.
• 복제본은 기본 인스턴스와 동일한 데이터 볼륨을 공유하므로 복제 지연이 거의 발생하지 않는다.
• 모든 복제본은 데이터 손실 없이 기본 인스턴스로 승격될 수 있으므로 기본 DB 인스턴스 장애 발생 시 내결함성을 강화하는 데 사용할 수 있다.
• 데이터베이스 가용성을 높이기 위해 3개 AZ 중 하나에 1~15개의 복제본을 생성할 수 있으며, 데이터베이스 중단 시 RDS가 자동으로 복제본을 페일오버 기본 선택 항목에 포함시킨다.

Aurora 장애 조치

• Aurora는 DB 클러스터의 기본 인스턴스에 장애가 발생하면 다음 순서로 자동으로 페일 오버를 수행한다.
• Aurora 읽기 복제본을 사용할 수 있는 경우, 기존 읽기 복제본을 새 기본 인스턴스로 승격한다.
• 사용 가능한 읽기 복제본이 없는 경우, 새 기본 인스턴스를 만든다.
• 여러 개의 Aurora 읽기 복제본이 있는 경우, 승격 기준은 읽기 복제본에 정의된 우선 순위에 따라 결정된다.
• 우선 순위 번호는 0에서 15까지 다양하며 언제든지 수정할 수 있다.
• PostgreSQL은 우선 순위가 가장 높은 Aurora 복제본을 새 기본 인스턴스로 승격한다.
• 우선순위가 동일한 읽기 복제본의 경우, PostgreSQL은 크기가 가장 큰 복제본을 승격하거나 임의의 방식으로 승격한다.
• 장애 조치 중에 AWS는 새로 생성/승격된 DB 인스턴스를 가리키도록 클러스터 엔드포인트를 수정한다.
• 애플리케이션이 클러스터 엔드포인트를 사용하여 연결하고 연결 재시도 로직을 구현하면 서비스 중단을 최소화할 수 있다.

보안

• Aurora는 SSL(AWS-256)을 사용하여 데이터베이스 인스턴스와 애플리케이션 간의 연결을 보호한다.
• AWS 키 관리 서비스(KMS)를 통해 관리되는 키를 사용하여 데이터베이스 암호화를 허용한다.
• 암호화와 복호화는 원할하게 처리된다.
• 암호화를 사용하면 기본 스토리지에 저장된 미사용 데이터는 물론, 동일한 클러스터에 있는 자동화된 백업, 스냅샷, 복제본도 암호화된다.
• 암호화되지 않은 기존 Aurora 인스턴스의 암호화는 지원되지 않는다. 암호화된 새 Aurora 인스턴스를 생성하고 데이터를 마이그레이션 해야 한다.

백업 및 복원

• 자동 백업은 항상 Aurora DB 인스턴스에서 활성화된다.
• 백업은 데이터베이스 성능에 영향을 미치지 않는다.
• Aurora는 수동 스냅샷 생성도 허용한다.
• Aurora는 3개의 AZ에 걸쳐 6개의 데이터 사본을 자동으로 유지 관리하며, 데이터 손실 없이 정상적인 AZ에서 데이터베이스를 자동으로 복구하려고 시도한다.
• 다음의 경우 Aurora 스토리지 내 저장이 불가능하다.
  = DB 스냅샷을 복원하는 경우
  = 새 인스턴스로 특정 시점 복원 작업을 수행할 수 있다. 특정 시점 복원 작업의 최신 복원 가능 시간은 최대 5분까지 가능하다.
• 스냅샷을 복원하면 새 Aurora DB 인스턴스가 생성된다.
• 데이터베이스를 삭제하면 모든 자동 백업(최종 스냅샷 생성 옵션 포함)이 삭제되지만 수동 스냅샷을 제거되지 않는다.
• 스냅샷(암호화된 스냅샷 포함)은 다른 AWS 계정과 공유할 수 있다.

Aurora 병렬 쿼리

• Aurora 병렬 쿼리는 단일 쿼리의 계산 부하를 Aurora의 스토리지 계층에 있는 수천 개에의 CPU에 푸시 다운하여 분산하는 기능을 뜻한다.
• 병렬 쿼리가 없다면, Aurora 데이터베이스에 대해 실행되는 쿼리는 데이터베이스 클러스터의 한 인스턴스 내에서 전적으로 실행되며, 이는 대부분의 데이터베이스가 작동하는 방식과 유사하다.
• 병렬 쿼리는 대규모 테이블에서도 새로운 데이터와 우수한 쿼리 성능을 필요로 하는 분석 워크로드에 적합하다.
• 병렬 쿼리는 다음의 이점을 제공한다.
  = 더 빠른 성능: 병렬 쿼리는 분석 쿼리 속도를 최대 2배까지 높일 수 있다.
  = 운영 간소화 및 데이터 최신성: Aurora 클러스터의 현재 트랜잭션데이터에 대해 직접 쿼리를 실행할 수 있다.
  = 동일한 데이터베이스에서 트랜잭션 및 분석 워크로드: 병렬 쿼리를 통해 Aurora는 동시 분석 쿼리와 함께 높은 트랜잭션 처리량을 유지할 수 있다.
• 병렬 쿼리는 전역 및 세션 수준 모두에서 aurora_pq 매개변수를 사용하여 동적으로 활성화 및 비활성화할 수 있다.
• 병렬 쿼리는 MySQL 5.6 호환 버전의 Aurora에서 사용할 수 있다.

Aurora Scaling

• Aurora스토리지 확장은 기본 제공되며 데이터베이스 성능에 영향을 주지 않고 10GB 단위로 최대 64TB(소프트 제한)까지 자동으로 확장된다.
• 미리 스토리지를 프로비저닝할 필요가 없다.
• Compute Scaling
  = Instance Scaling
  = 마스터 인스턴스의 수직 확장. DB 인스턴스 클래스를 변경하여 메모리 및 CPU 리소스를 수정한다.
  = 읽기 복제본을 스케일링하고 강제 페일오버를 사용하여 마스터로 승격하여 가동 중단 시간을 최소화한다.
  = Read Scaling
  = 최대 15개의 읽기 복제본으로 수평적 확장을 제공한다.
  = Auto Scaling
  = CloudWatch CPU 또는 연결 메트릭 조건 확장에 따라 최소 및 최대 복제본 수로 읽기 복제본을 추가하는 스케일링 정책

Aurora Backtracking

• 백트래킹은 DB 클러스터를 지정된 시간으로 "되돌리는" 기능이다.
• 백트래킹은 제자리 복원을 수행하며 새 인스턴스를 생성하지 않는다. 이와 관련된 다운타임이 최소화된다.
• 백트래킹은 MySQL 호환성을 갖춘 Aurora에서 사용할 수 있다.
• 백트래킹은 특정 시점으로 복원할 수 있도록 DB 클러스터를 백업하는 것을 대체하지 않는다.
• 백트래킹에는 목표 백트래킹 윈도우와 실제 백트래킹 윈도우가 있다.
  = Target Backtracking Window는 DB 클러스터를 24시간 동안 백트래킹할 수 있도록 원하는 시간이다. 백트래킹 기간의 제한은 72시간 이다.
  = 실제 백트래킹 기간은 DB 클러스터를 백트래킹 할 수 있는 실제 시간으로, 목표 백트래킹 기간보다 짧을 수 있다. 실제 백트래킹 기간은 워크로드 및 변경 레코드라고 하는 데이터베이스 변경에 대한 정보를 저장할 수 있는 스토리지에 따라 결정된다.
• 백트래킹이 활성화된 DB 클러스터는 변경 레코드를 생성한다.
• Aurora는 대상 백트래킹 기간과 DB 클러스터의 워크로드에 따라 저장되는 변경 기록의 수가 결정된다.
• 워크로드는 주어진 시간 동안 DB 클러스터에 수행된 변경 사항의 수이다. 워크로드가 많으면 워크로드가 적은 경우보다 백트래킹 창에 더 많은 변경 레코드를 저장한다.
• 백트래킹은 전체 DB 클러스터에 영향을 미치며 단일 테이블 또는 단일 데이터 업데이트를 선택적으로 백트래킹할 수 없다.
• 백트래킹은 기존 백업 및 복원에 비해 다음과 같은 이점을 제공한다.
  = 실수 실행 취소 - WHERE 절이 없는 DELETE와 같은 파괴적인 작업을 되돌릴 수 있다.
  = DB 클러스터를 신속하게 백트래킹 - 특정 시점으로 DB 클러스터를 복원하면 새 DB 클러스터가 시작되고 백업 데이터 또는 DB 클러스터에서 복원된다.
  = 이전 데이터 변경 사항 탐색 - 특정 데이터 변경이 발생한 시점을 파악하는 데 도움이 되도록 DB 클러스터를 반복적으로 앞뒤로 역추적한다.

Aurora Serverless

• Amazon aurora 서버리스는 주문형 자동 확장 구성으로, MySQL 호환 및 PostgreSQL 호환 버전의 Aurora를 위한 것이다.
• aurora 서버리스 DB 클러스터는 애플리케이션의 필요에 따라 자동으로 시작, 종료되고 용량을 늘리거나 줄일 수 있다.
• 데이터베이스 인스턴스를 관리할 필요 없이 클라우드에서 데이터베이스를 실행할 수 있다.
• 빈번하지 않거나 간헐적이거나 예측할 수 없는 워크로드를 위한 비교적 간단하고 비용 효율적인 옵션을 제공한다.
• 사용 사례는 다음과 같다.
  = 자주 사용하지 않는 애플리케이션
  = 새로운 애플리케이션 - 요구 사항과 인스턴스 크기가 아직 결정되지 않은 경우
  = 가변적이고 예측할 수 없는 워크로드 - 필요에 따라 확장 가능
  = 개발 및 테스트 데이터베이스
  = 멀티테넌트 애플리케이션
• DB 클러스터에는 퍼블릭 IP 주소가 없으며 VPC 서비스를 기반으로 한 VPC 내에서만 액세스할 수 있다.

  Aurora Global Database

• Aurora 글로벌 데이터베이스는 데이터가 마스터되는 하나의 기본 AWS 리전과 최대 5개의 읽기 전용 보조 AWS 리전으로 구성된다.
• 데이터가 마스터되는 기본 AWS 리전의 Aurora 클러스터는 읽기 및 쓰기 작업을 모두 수행한다. 보조 리전의 클러스터는 지연 시간이 짧은 읽기를 지원한다.
• aurora는 일반적으로 1초 미만의 지연 시간으로 데이터를 보조 AWS 리전으로 복제한다.
• 보조 클러스터는 읽기 전용 워크로드에 서비스를 제공하기 위해 DB 인스턴스(aurora 복제본) 중 하나를 추가하여 독립적으로 확장할 수 있다.
• aurora 글로벌 데이터베이스는 전용 인프라를 사용하여 데이터를 복제하므로 데이터베이스 리소스를 전적으로 애플리케이션을 지원하는 데 사용할 수 있다.
• 전 세계에 걸쳐 있는 애플리케이션은 지연 시간이 짧은 읽기를 위해 보조 AWS 리전의 리더 인스턴스를 사용할 수 있다.
• 재해 또는 가동 중단이 발생하는 경우 보조 AWS 리전의 클러스터 중 하나를 승격하여 1분 이내에 전체 읽기/쓰기 워크로드를 처리할 수 있다.

Aurora Clone

• Aurora 복제 기능을 사용하면 빠르고 비용 효율적으로 aurora 클러스터 복제본을 생성할 수 있다.
• 복제본을 생성하는 것이 스냅샷 복원과 같은 다른 기술을 사용하여 물리적으로 데이터를 복사하는 것보다 더 빠르고 공간 효율적이다.
• aurora 복제본은 복사본-on-쓰기 프로토콜을 사용한다.
• aurora 복제본은 처음 생성할 때 최소한의 추가 공간만 필요하다. 처음에 aurora는 데이터의 단일 복사본을 유지하며, 이 복사본은 원본 및 새 DB클러스터에서 모두 사용된다.
• 원본 클러스터나 복제된 클러스터에서 데이터가 변경될 때만 aurora는 새 스토리지를 할당한다.