AWS

RDS (2) - Aurora에 대해 알아보자

S_N_Y 2024. 3. 23. 12:53

 

Aurora에 대해 이전에 간단하게 정리해둔 글이 있는데

먼저 읽고 아래의 자세한 Aurora에 대해서 알아가면 훨씬 도움이 될 것이다.👍

⬇️⬇️⬇️

https://670811.tistory.com/50#1-amazon-aurora

 

AWS Database에 관해

데이터 구조에 따라 저장하고자 한다면 AWS 데이터베이스를 이용하게 될텐데 이때, 구조를 통해서 효과적인 쿼리와 데이터 검색을 위한 인덱스를 구축할 수 있다. 그리고 데이터셋 간의 관계도

670811.tistory.com

 

#0 Amazon Aurora란?🌌

Aurora는 PsotgresSQL이나 MySQL과 호환되도록 만든 데이터베이스이다.

(RDS의 MySQL보다 성능이 5배 높고 RDS의 PostgresSQL보다 성능이 3배가 높다.)

특징은 아래와 같이 짧게 정리할 수 있다.⬇️

 

- Aurora는 스토리지를 자동으로 확장한다. 설계하기에 따라 다르지만 DB나 SysOps로써 저장 디스크를 신경 쓰지 않아도 된다는 것이다.

- 읽기 전용 복제본의 경우, MySQL에서는 5개만 가능했었는데 Aurora는 15개까지 만들 수 있다.

- Aurora의 장애 조치는 즉각적이라 다중 AZ나 MySQL RDS보다 훨씬 빠르다.

(기본적으로 클라우드 네이티브라 가용성이 ↑)

-  비용은 RDS에 비해 당연히 좀 더 높지만 스케일링 측면에서 훨씬 더 효율적이라 오히려 비용을 절감할 수도 있다.

 

<높은 가용성과 읽기 스케일링 측면>

Aurora는 특이하게 무언가를 기록할 때마다 6개의 사본을 저장한다. '쓰기'에는 6개의 사본 중 4개, '읽기'에는 6개의 사본 중 3개만 필요한 구조이다.

일부 데이터가 손상되거나 문제가 있으면 백엔드에서 P2P 복제를 통한 자가 복구가 진행된다. 그리고 단일 볼륨에 의존하지 않고 수 백개의 볼륨을 사용한다. 

=> 공통적으로 백엔드 단에서 진행되는 과정이고 리스크를 크게 감소시켜주어 가용성이 좋다는 말이다.

 

그리고 복제본을 많이 두고 읽기 워크로드를 스케일링할 수 있다.

마스터에 문제가 생기면 읽기 전용 복제본 중 하나가 마스터가 되어 대체하는 점에서 RDS와는 작동 방식이 꽤 다르다고 할 수 있다.(기본적으로 마스터가 하나인건 동일)

=> 즉 마스터는 하나, 복제본은 여럿이고 스토리지가 복제된다는 점

 

<클러스터로서의 Aurora 살펴보기 - Aurora 작동방식>

 

클라이언트가 있을 때 수많은 인스턴스와 어떻게 접속할까?🤷‍♂️

 

위에서 언급했듯이 공유 볼륨은 자동으로 확장되는데 스토리지에 쓰는 것은 마스터만이 가능하다.

마스터가 바뀌거나 장애조치가 실행될 수 있어서 Aurora에서는 Writer Endpoint를 제공한다. Writer Endpointsms DNS 이름으로 항상 마스터를 가르킨다. 따라서 장애조치 후에도 클라이언트는 Writer Endpoint와 상호작용하게 되고 올바른 인스턴스로 자동으로 리다이렉트된다.

또한 이 복제본에 대한 자동 스케일링이 가능하다는 사실인데 자동 스케일링을 설정해서 항상 적절한 수의 읽기 전용 복제본이 존재하도록 할 수 있다. 그러나 우리의 입장에서는 복제본이 어디에 있고 URL은 무엇이며 어떻게 연결하는지 파악하기 어려울 수 있는데 Writer Endpoint 와 정확히 같은 기능을 하는 Reader Endpoint로 Connection Loadbalancing에 도움을 준다.

=> 모든 읽기 전용 복제본과 자동으로 연결되고 클라이언트가 Reader Endpoint에 연결될 때마다 읽기 전용 복제본 중 하나로 연결되며 이런 방식으로 로드 밸런싱을 도와준다.

 

+) 로드 밸런싱이 문장 레벨이 아닌 연결 레벨에서 일어나니 꼭 기억해두기

 

#1 Aurora 복제본(Replicas) - Auto Scaling

먼저 그림을 통해 설명해보려고 한다.

클라이언트가 있고, 우리에게 세 개의 Aurora 인스턴스가 있는 상황을 가정해보자

한 개는 writer endpoint로 쓰고 있을 거고 나머지 두 개는 leader endpoint로 읽고 있을 것이다. 그리고 leader endpoint에 아주 많은 읽기 요청이 들어온다고 가정해보고 그럼으로 인해 데이터베이스의 CPU 사용량이 증가했다.

이 경우에 복제본 Auto Scaling을 설정할 수 있는데 이는 Amazon Aurora 복제본들을 추가할 것이다. 그로인해 자동으로 leader endpoint는 새로운 레플리카들을 위해 확장될 것이다. 그러면 새 레플리카들은 트래픽을 받기 시작할거고 읽기는 더 많이 분배되는 방식으로 일어날 것이다.

=> 전체적인 CPU 사용량을 낮출 수 있다.

 

#2 Custom Endpoints - 사용자 지정 엔드 포인트

위와 같은 상황에서 이번에는 두 종류의 복제본이 있다고 가정하자.

각 Aurora 읽기 전용 복제본은 다른 것보다 용량이 큰 상태인데 이렇게 하는 이유는

Aurora 인스턴스의 부분집합을 custom endpoint로 정의하기 위해서이다.

그래서 위의 그림과 같이 두 개의 큰 Aurora 인스턴스(🌟주로 분석적 쿼리를 담당할 때..🌟)에 custom endpoint를 정의한다고 할 때, 정의된 custom endpoint가 생기고 정의 후에는 reader endpoint 자체는 사용되지 않게 된다.(왼쪽 기본 Aurora 인스턴스 두 개는 둔다는 말)

 

#3 Aurora Serverless

서버리스는 우리에게 자동화된 데이터베이스 예시화 하거나 실제 사용량에 따른 Auto Scaling을 제공한다.

=> 간헐적이거나 예측하기에 불가능한 업무량에 대응하는 것을 도와준다.

클라이언트는 Aurora가 관리하는 Proxy Fleet(프록시 플릿)에 연락할 것인데 백엔드에는 많은 Aurora 인스턴스들이 생성될 것이다. 우리의 업무량에 기반에 서버리스 방식으로 되는데 이로 인해 미리 용량을 준비하지 않아도 된다..!

 

#4 Global Aurora

Aurora Cross Region Read Replicas(교차 region 읽기 전용 복제본)은

재해 복구에 도움이 많이 되고 실행하기 간단하다.

=> Aurora Global Database를 이용하는게 요즘 추천되는 방식이라고 한다.

 

모든 읽기와 쓰기가 일어나는 하나의 기본 region이 있고 최대 5개의 보조 읽기 전용 region을 만들 수 있는데 이는 응답 지연이 1초 이하이다. 그리고 보조 region당 최대 16개의 읽기 전용 복제본을 사용할 수 있다. 이는 전 세계에서 오는 읽기 업무량에 따른 대기 시간을 줄이는 데 도움을 줄 것이다.

또한 한 region에 데이터베이스 중단이 일어날 경우, 재해 복구를 위해 다른 region을 진급시키는데 다른 region으로 들어가 복구시키는 시간이 1분 이내이다.

=> 평균적으로 Aurora Global Database에서 한 region에서 다른 region으로 데이터를 복제하는 데에는 1초 이하의 시간이 걸린다.

예시 그림

us-east-1을 기본 region으로 하고 (응용프로그램이 읽기와 쓰기를 하는 곳이다) eu-west-1에 보조 region을 만든다. 이곳에선 Aurora의 Global Database와 함께 데이터 복제가 일어나고 응용 프로그램은 읽기만 가능하다.

만약 us-east-1가 중단되면 eu-west-1로 failover(장애조치)를 한다.

=> 읽기/쓰기 Aurora 클러스터로 진급시키는 것

 

#5 Aurora Machine Learning

Aurora는 AWS 안에 있는 머신러닝 서비스와 통합하기도 한다.

Aurora Machine Learning이란 SQL 인터페이스를 통해 우리의 응용프로그램에 머신러닝 기반 예측을 추가할 수 있다는 말이다.

(Aurora와 다른 AWS 머신러닝 서비스 간의 안전하고 최적화된 통합이라고 할 수 있다)

 

⬇️Aurora Machine Learning을 통해 아래와 같은 두 가지 서비스가 지원된다⬇️

1. SageMaker : 백엔드인 어떤 종류의 머신러닝 모델이라도 사용할 수 있게 허용

2. Amazon Comprehend : sentiment 분석(감정 분석)을 할 때 사용

=> 결론은 Aurora가 이들이랑 통합지원된다는 것을 알아두고 가면 좋다.

 

사용 사례) 광고 타겟팅, 감정 분석, 상품 추천, 이상 행위 탐지 등..

위의 그림을 빌려 한 번 더 설명하자면 Aurora는 AWS 안의 머신러닝 서비스에 우리의 응용 프로그램은 간단 SQL 쿼리만 실행할 수 있다. 예를 들어 '추천 상품은 무엇인가?'가 들어오면 aurora가 머신러닝 서비스로 데이터를 보내게 되는데 사용자의 프로필고 구매이력 등등 머신러닝해서 Aurora에 직접적으로 예측을 보내는 것이다.

그러면 Aurora는 쿼리 결과를 응용프로그램에 반환하면 된다..!