[AWS] Amazon Aurora

Aurora란 무엇인가?

간단하게 말하면 AWS에서 MySQL PostgreSQL을 기반으로 새롭게 설계한 관계형 데이터베이스이다. 그 과정에서 여러가지 클라우드 요소를 집어 넣어 다양한 기술을 제공, 효율일 좋고 고가용성, 안정성을 제공한다. 기존 RDS와 조금 다른 아키텍쳐를 가지고 있어 여러 장점을 통해 효율적인 운영을 가능하게 한다.

Amazon에서 설명하는Aurora

Amazon Aurora는 고성능 상용 데이터베이스의 성능과 가용성에 오픈 소스 데이터베이스의 간편성과 비용 효율성을 결합하였으며, 클라우드를 위해 구축된 MySQL 및 PostgreSQL 호환 관계형 데이터 베이스 입니다.

Amazon Aurora는 표준 MySQL 데이터베이스보다 최대 5배 빠르고 표준 PostgreSQL 데이터베이스보다 3배 빠릅니다. 또한 1/10의 비용으로 상용 데이터베이스의 보안, 가용성 및 안정성을 제공합니다. 하드웨어 프로비저닝, 데이터베이스 설정, 패치 및 백업과 같은 시간 소모적인 관리 작업을 자동화하는 RDS에서 Amazon Aurora의 모든것을 관리합니다.

Aurora 특징

MySQL / PostgreSQL 지원

• 두가지 모드
  • 다수의 노드로 읽기, 쓰기가 가능한 Multi-Master
  • 한 개의 쓰기 전용 노드와, 다수의 읽기 전용 노드(Aurora Replicas) 구성의 Single-Master

대부분 Single-Master를 사용한다. Multi-Master는 장점이 있지만 Multi-Master를 사용하면 Aurora의 기능 중 사용하지 못하는 기능이 존재하기 때문에 보통 Single-Master를 사용

• 용량의 자동 증감

RDS는 EBS 기반이라 따로 용량을 설정해야 한다. 그러나 Aurora의 경우 10GB부터 시작해서 10GB단위로 용량 증가가 가능하다(최대 128TB)이는 RDS와는 다르게 읽기 쓰기 노드와 저장 노드를 분리시켰기 때문에 생기는 장점이다.

• 연산능력: 96vCPU와 768GB까지 증가 가능(db.r5.24xlarge)
• 데이터의 분산저장: 각 AZ마다 2개의 데이터 복제본 저장 X 3개 이상의 AZ = 6개의 복제본
  • 3개 이상을 잃어버리기 전에는 쓰기 능력 유지
  • 4개 이상을 잃어버리기 전에는 읽기 능력 유지
  • 손실된 복제본은 자가 치유: 지속적으로 손실된 부분을 검사 후 복구(읽기 노드와 저장 노드가 분리되어 있기에 가능하다)
  • Quorum 모델 사용(투표 시스템, 총 6개의 복제본의 상태를 어떻게 유지하느냐에 대한 방법을 투표로 정한다.)

Aurora의 두가지 모델

• Single-Master 모드
  • 한 대의 writer 인스턴스와 다수의 읽기 전용 인스턴스(Aurora Replicas)로 구성
  • 총 15개의 Replica 생성 가능
  • Async 복제
  • 하나의 리전 안에 생성 가능
  • writer가 죽을 경우 자동으로 Replica중 하나가 writer로 Failover(장애극복)
    • 데이터 손실 없이 Failover시 메인으로 승격 가능
  • 고 가용성(High Availability)를 확보
• Multi-Master 모드
  • 최대 4개의 노드가 읽기 / 쓰기를 담당
    • 각 노드는 독립적: 정지 / 재부팅 /삭제 등 서로 영향을 받지 않는다.
  • 지속적인 가용성(Continuous Availability) 제공
  • 주로 Multitenant 혹은 sharding이 적용된 어플리케이션에서 좋은 성능을 발휘한다.

Aurora Global Database

• 전 세계의 모든 리전에서 1초내의 지연시간으로 데이터 액세스가 가능하다
• 재해복구용도로 활용 가능하다
  • 유사시 보조 리전 중 하나를 승격하여 메인으로 활요한다.
  • 1초의 RPO(복구 목표 지점)
  • 1분 미만의 RTO(복구 목표 시간)
• 보조 리전에는 총 16개의 Read 전용 노드 생성이 가능하다.

병렬 쿼리

• 다수의읽기 노드를 통해서 쿼리를 병렬로 처리하는 모드
  • 빠르다
  • 부하 분산(CPU, Memory)
• MySQL 5.6 / 5.7 에서만 지원이 가능하다.
• 몇몇 낮은 인스턴스(db.t2, db.t3등) 에서는 지원하지 않는다.

Aurora의 백업

• 읽기 복제본(Read Replica) 지원 (Aurora Replica와 다른 개념)
  • MySQL DB의 Binary Log 복제
  • 단 다른 리전에만 생성 가능
• RDS와 마찬가지로 자동 / 수동 백업 가능
  • 자동 백업의 경우 1 ~ 35일동안 보관(S3에 보관)
  • 수동 백업(스냅샷) 가능
  • 백업 데이터를 복원할 경우 다른 데이터 베이스를 생성한다.(원본은 그대로)

Aurora 데이터베이스 cloning

• 기존의 데이터베이스에서 새로운 데이터베이스를 복제
  • 스냅샷을 통해 새로운 데이터베이스를 생성하는 것보다 빠르고 저렴하다.
• Copy-on-write 프로토콜을 사용
  • 기존 클러스터를 삭제해도 제대로 동작한다.
    
    Aurora는 보는 것 같이 모든 데이터를 페이지 단위로 저장한다.

만약 데이터를 cloning 한다고 하면 새로우 페이지를 생성하는 것이 아닌 기존 페이지를 참고한다.

만약 오리지널에서 5번 페이지를 변경한다면 오로라 오리지널에서 5번 페이지에 대한 연결을 끊고 오리지날만을 위한 새로운 5번을 만들어 준다.

만약 clone에서 1번에 변화를 준다면 기존 1번 페이지에 연결을 끊고 새로운 1번을 만들어서 붙인다. 이렇게 되면 오리지널이 삭제돼도 내부에서 알아서 클론이 동작할 수 있도록 처리를 한다.

Backtrack

• 기존의 DB를 특정 시점으로 되돌리는 것(새로운 DB가 아닌 기존 DB) 스냅샷이나 자동백업의 경우 복구시 새로운 RDS 인스턴스를 만들었음
  • DB 관리의 실수를 쉽게 만회 가능
  • 새로운 DB를 생성하는 것보다 훨씬 빠름
  • 앞 뒤로 시점을 이동할 수 있기 대문에 원하는 지점을 빠르게 찾을 수 있음
• Backtrack Window
  • Target Backtrack Window(미리 설정)
    • 어느 시점만큼 DB를 되돌리기 위한 데이터를 저장 할 것인지
      • 지정한 시점 이전으로는 Backtrack 불가능
  • Actual Backtrack Window
    • 실제로 시간을 얼마나 되돌릴지
    • Target Backtrack Window보다 작아야 한다.
• Backtrack 활성화시 시간당 DB의 변화를 저장
  • 저장된 용량만큼 비용 지불
  • DB 변화가 많을수록 많은 로그 = 많은 비용
  • DB 로그가 너무 많아 Actual Backtrack Window가 Target Backtrack Window(설정값)보다 작을 경우 알림(백트랙 윈도우는 최대 72시간임, 만약 DB 변화가 너무 많아 72시간 만큼의 로그를 저장하지 못하는 경우가 생길수도 있다.)
• MySQL만 가능
• Aurora 생성 시 Backtrack을 설정한 DB만 Backtrack 가능(중간에 안됨, 생성시에만 가능)
  • 스냅샷을 복구하거나 clone을 통해 기능 활성화
• Multi-Master 상태에서는 Backtrack 불가능

Reference

https://www.youtube.com/channel/UCpDxKxars7BHR3owaNRctaQ