Amazon Aurora

• AWS 고유의 기술로 오픈 소스는 아니지만 Postgres 및 MySQL과 호환되도록 만들어졌다.
• Aurora 데이터베이스에 호환 가능한 드라이버가 있는데 Postgres 및 MySQL 데이터베이스에 연결하면 작동함을 의미한다.
• 클라우드에 최적화되어 있고 여러가지 최적화를 통해서 RDS의 MySQL보다 5배 높은 성능을 가지고 RDS의 Postgres보다는 3배 높은 성능을 가진다.
• Aurora의 스토리지는 자동으로 확장하는데 10GB에서 시작하여 데이터베이스에 더 많은 데이터를 넣을수록 자동으로 128TB까지 커진다. 저장 디스크를 신경쓰지 않아도 된다.
• 읽기 전용 복제본의 경우 15개의 복제본을 둘 수 있다.
• Aurora의 장애 조치는 즉각적이다. 다중 AZ나 MySQL RDS보다 훨씬 빠르다.
• 기본적으로 클라우드 네이티브이므로 가용성이 높다.
• 비용적으로 RDS 보다 20%이상 비싸지만 스케일링 측면에서 훨씬 더 효율적이다.

Aurora의 높은 가용성과 읽기 스케일링

• Aurora는 3개의 AZ에 걸쳐 무언가를 기록할 때마다 6개의 사본을 저장한다. 따라서 Aurora는 가용성이 높다.
• 쓰기에는 6개의 사본 중 4개만 있으면 된다. AZ 하나가 작동하지 않아도 괜찮다.
• 읽기에는 6개의 사본 중 3개만 있으면 된다. 읽기 가용성이 높다.
• 자가 복구 과정이 있다. 일부 데이터가 손상되거나 문제가 있으면 백엔드에서 P2P를 활용하여 자가복구가 진행된다.
• 단일 볼륨에 의존하지 않고 수 백개의 볼륨을 사용한다. 백엔드에서 진행되는 과정이며 리스크를 크게 감소시킨다.
• 쓰기를 받는 인스턴스는 하나 뿐이다. Aurora에도 마스터가 존재하고 여기서 쓰기를 받게 된다.
• 마스터가 평균 30초 이내로 장애 조치가 시작된다. 장애 조치가 매우 빠르다.
• 마스터 외의 읽기를 제공하는 읽기 전용 복제본을 15개까지 둘 수 있다. 따라서 복제본을 많이 두고 읽기 워크로드를 스케일링할 수 있다.
• 마스터에 문제가 생기면 읽기 전용 복제본 중 하나가 마스터가 되어 대체한다.
• 복제본들은 리전 간 복제를 지원한다.
• 마스터는 하나고 복제본은 여럿이며 스토리지가 복제된다.
• 작은 블록 단위로 자가 복구 또는 확장이 일어난다.

Aurora DB Cluster

• Aurora의 공유 볼륨은 10GB 에서 128TB까지 자동으로 확장된다.
• 스토리지에 쓰는 것은 마스터만이 가능하다.
• Aurora에서는 라이터 엔드포인트(Writer Endpoint)를 제공한다.
• 라이터 엔트포인트는 DNS이름으로 항상 마스터를 가리킨다.
• 따라서 장애 조치 후에도 클라이언트는 라이터 엔트포인트와 상호작용하며 올바른 인스턴스로 자동 리다이렉트된다.
• Aurora는 다수의 읽기 전용 복제본이 존재하고 이 복제본에 대한 자동 스케일링이 가능하다.
• 읽기 전용 복제본을 15개까지 생성 가능하며 자동 스케일링을 설정해서 항상 적적한 수의 읽기 전용 복제본이 존재하도록 할 수 있다.
• 자동 스케일링이 켜져 있는 경우 앱 입장에서는 복제본이 어디에 있고, URL은 무엇이고 어떻게 연결하는지 파악하기 어렵다.
• 이를 처리하기 위해 리더 엔드포인트(Reader Endpoint)를 이용한다.
• 리더 엔드포인트는 라이터 엔드포인트와 정확히 같은 기능을 하며 연결 로드 밸런싱에 도움을 준다.
• 클라이언트가 리더 엔드포인트에 연결될 때마다 읽기 전용 복제본 중 하나로 연결되며 로드 밸런싱에 도움을 준다. 로드 밸런싱이 문장 레벨이 아닌 연결 레벨에서 일어난다.

Aurora Replicas - Auto Scaling

Aurora 복제본 Auto Scaling은 Reader EndPoint에 아주 많은 읽기 요청이 들어오고 있어 Amazon Aurora 데이터베이스에 CPU의 사용량이 증가하였을 때 복제본 Auto Scaling을 설정할 수 있다. 이로 인해 Reader EndPoint는 새로운 복제본들을 위해 확장된다. 확장후 새로운 복제본들은 트래픽을 받기 시작하고 읽기는 더욱 많이 분배되도록 일어난다. 결과적으로 전체적으로 CPU 사용량을 낮출 수 있게 된다.

Aurora Custom EndPoint

여러 종류의 복제본이 있을때, 읽기 전용 복제본은 모두 다른 크기를 가질 수 있는데 Aurora 인스턴스의 부분집합을 사용자지정 엔드포인트로 정의하기 위해서다. 이렇게 하면 더 큰 용량을 가진 특정 읽기 복제본이 분석적 쿼리를 담당하게 할 수 있다. 이렇게 하면 정의된 사용자 지정 엔드포인트가 생긴다. 일반적으로 사용자 지정 엔드포인트를 갖게 되면 사용자 정의 엔드포인트 정의 이후에는 리더 엔드포인트 자체는 사용되지 않게 된다. 사라지진 않지만, 더 이상 사용되지 않는다. 그래서 각각의 업무마다 다양한 사용자 지정 엔드포인트를 만들어야 한다. 이는 Aurora 복제본의 부분집합에 쿼리하도록 해준다.

Aurora Serverless

서버리스는 자동화된 데이터베이스 예시화와 실제 사용량에 따른 Auto Scaling을 제공한다. 이는 간헐적이고 예측 불가능한 업무량에 대응하는 것을 도와준다. 그러므로 Capacity planning을 할 필요가 없게 된다. 활용하고 있는 Aurora 인스턴스마다 초당 비용을 지불을 하는 것이 훨씬 효율적이다.

Global Aurora

Aurora 교차 리전 읽기 전용 복제본은 재해 복구에 도움이 많이 되고, 실행되기 간단하다. 그럼에도 Aurora 글로벌 데이터베이스를 이용하는게 요즘 추천된다. 모든 읽기와 쓰기가 일어나는 하나의 기본 리전이 있고 최대 5개의 보조 읽기 전용 리전을 만들 수 있는데 이는 응답 지연이 1초 이하이다. 그리고 보조 리전당 최대 16개의 읽기 전용 복제본을 사용할 수 있다. 전 세계에서 오는 읽기 업무량에 따른 대기 시간을 줄이는데 도움을 줄 수 있다. 또한 한 리전에 데이터베이스 중단이 일어날 경우 재해 복구를 위해 다른 리전을 진급시키는데 다른 리전으로 들어가 복구시키는 시간이 1분이내이다. 평균적으로 Aurora 글로벌 데이터베이스에서 한 리전에서 다른 리전으로 데이터를 복제하는 데에는 1초 이하의 시간이 걸린다.

Aurora Machine Learning

Aurora의 머신러닝 개념은 SQL 인터페이스를 통해 응용프로그램에 머신러닝 기반의 예측을 추가하는 것이다. Aurora와 다른 AWS 머신러닝 서비스간의 간단하고 최적화된, 안전한 통합이다. 통합 지원이 되는 서비스는 다음과 같다.

• 지원되는 서비스
  - SageMaker : 백엔드인 어떤 종류의 머신러닝 모델이라도 사용할 수 있게 허용
  - Amazon Comprehend : 감정 분석시 사용
  Aurora 머신러닝을 사용하기위해 머신러닝 경험이 필요하지 않고 사용 사례는 이상 행위 탐지, 광고 타겟팅, 감정 분석, 상품 추천등이 있다.