[aws] Amazon Aurora 알아보기

 

 

이 글의 일부는 aws 공식문서의 내용을 참조하였음을 밝힙니다.

 

 

 

📌 Amazon Aurora

 

Aurora는 AWS 고유의 기술로 오픈 소스는 아니지만 Postgres 및 MySQL과 호환되도록 만들었다. Aurora는 클라우드에 최적화 되어있고 여러 가지 최적화를 통해 MySQL보다 5배 높은 성능 이고 Psostgres 보다는 3배 높은 성능을 보인다. Aurora는 자동으로 스토리지를 확장하며 설계하기에 따라서 10GB로 시작하여 자동으로 128TB 까지 커진다. 읽기 전용 복제본의 경우 MySQL에서는 5개만 생성할 수 있는 반면 Aurora는 15개의 복제본을 둘 수 있으며 복제본도 훨씬 빠르다.  장애 조치에 대해서도 훨씬 신속한데 다중 AZ 역시 MySQL 보다 훨씬 빠르고 기본적으로 클라우드 네이티브이므로 가용성이 높다. 비용은 RDS에 비해 20%정도 높지만 스케일링 측면에서 훨씬 더 효율적이다. 

 

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

 

Aurora는 특이하게도 데이터를 생성할 때 3 AZ를 걸쳐 6개의 사본을 저장한다. 따라서 Aurora는 가용성이 높으며 쓰기에는 6개 사본 중 4개만 존재하면 되고 읽기에는 6개 사본 중 3개만 존재하여도 된다. 또한 일종의 자가 치유를 지원하여 일부 데이터가 손상되거나 문제가 있으면 P2P 복제를 통한 자가 복구가 진행된다.  그리고 단일 볼륨에 의존하지 않고 수 백 개의 볼륨을 사용하는데 이 과정은 리스크를 현저히 줄여준다. 도식을 통해 보면 3개의 AZ가 있다.  이 공유 볼륨은 복제, 자가 복구, 그리고 자동 확장 기능을 수행한다. 만약 데이터를 쓴다고 가정하였을 때 그림처럼 각기 다른 AZ에 6개의 사본이 생겨 각기 다른 볼륨으로 저장될 것이다. 

 

 

 

 

Aurora는 RDS의 다중 AZ와 유사하다. 쓰기를 받는 인스턴스는 하나 뿐이다. 따라서 Aurora에도 마스터가 존재하고 여기서 쓰기를 받게 된다. 그리고 마스터가 작동하지 않으면 평균 30초 이내로 장애 조치가 시작된다.  마스터에 문제가 생기면 읽기 전용 복제본 중 하나가 마스터가 되어 대체하는데 이러한 부분은 기존 RDS와는 작동 방식이 꽤 다르다. 기본적으로 마스터가 하나인 건 동일하지만 복제본들이 리전 간 복제를 지원함으로써 차이를 둔다.

 

 

Aurora Cluster

 

위에서 언급했던 공유 볼륨은 10GB에서 128TB까지 자동으로 확장된다. 스토리지에 쓰는 것 역시 동일하게 마스터만이 가능하지만 마스터가 바뀌거나 장애 조치가 실행될 수 있으므로 Aurora에서는 Writer 엔드포인트를 제공한다. Writer 엔드포인트는 DNS 이름으로 항상 마스터를 가르키기 때문에 장애 조치 후에도 클라이언트는 Writer 엔드포인트와 상호작용하게 되어 올바른 인스턴스로 자동으로 리다이렉트 된다. 

 

 

 

 

 

복제본 또한 자동 스케일링이 가능한데 읽기 전용 복제본은 15개까지 생성 가능하여 자동 스케일링을 통해 항상 적절한 수의 읽기 전용 복제본이 존재하도록 할 수 있다. 자동 스케일링이 켜져 있는 경우 앱 입장에서는 복제본이 어디 있고, URL은 무엇이고 어떻게 연결하는지 파악하기 어려운데 이를 위한 기능으로 Reader 엔드 포인트가 존재한다. Reader 엔드 포인터는 Writer 엔드 포인터처럼 연결 로드 밸런싱에 도움을 주며 모든 읽기 전용 복제본과 자동으로 연결된다. 따라서 클라이언트가 리더 엔드포인트에 연결될 때 마다 읽기 전용 복제본 중 하나로 연결되며 이런 방식으로 로드 밸런싱을 도와준다. 이 때, 로드밸런싱은 문장 레벨이 아닌 연결 레벨에서 일어난다.

 

 

 

📌 Amazon Aurora - advanced

 

 

 

Aurora Replicas - Auto Scaling 

 

클라이언트가 있고  Aurora 인스턴스들이 있는 상황을 가정해보자. 한 개는  Writer 엔드포인트로 쓰고 있을 것이고 , 나머지 두 개는 Reader 엔드포인트로 쓰이고 있다. 만약 두 개의 Reader 엔드포인트에 아주 많은 읽기 요청이 들어온다면 Aurora 데이터베이스의 CPU 사용량이 증가하게 될 것이다. 이 때 우리는 복제본 Auto Scaling 을 설정할 수 있는데 그로 인해 자동적으로 Reader 엔드포인트는 새로운 읽기 전용 복제본들을 위해 확장된다. 이 경우 읽기의 트래픽이 분산됨으로써 CPU 사용량을 낮출 수 있게 될 것이다. 

 

 

 

 

 

Aurora - Custom Endpoints

 

 

아까와 같은 상황에서 이번에는 두 종류의 복제본이 있다고 가정하자.  여기서 추가 되는 2개의  읽기 전용 복제본의 인스턴스는 다르다고 가정했을 때 사용자 지정 엔드 포인트를 사용하면 db.r5.2xlarge  와 같이 더 큰 Aurora 인스턴스에 접근시킬 수 있다. 이렇게 하는 이유는  특정 복제본들에게 분석적 쿼리 같이 복잡한 업무를 담당하는게 나을 것이기 때문이다. 이 때, 사용자 지정 엔드포인트 정의가 되면 Reader 엔드포인트 자체는 사용되지 않게 된다.

 

 

 

 

 

 

 

Aurora Serverless 

 

서버리스는 자동화된 데이터베이스 예시화와 실제 사용량에 따른 Auto Scaling 을 제공한다. 이는 간헐적이고 예측 불가능한 업무량에 대응하는 것을 도와준다. 그러므로 capacity planning을 할 필요가 없다. 작동 방식은 다음과 같다. 클라이언트는 Aurora 가 관리하는 프록시 플릿에 접근하게 되면 백엔드에는 많은 Aurora 인스턴스들이 생성될 것이다. 이 때 업무량에 기반에 서버리스 방식으로 되는데 이로 인해 미리 용량을 준비하지 않아도 된다. 

 

 

 

 

 

Global Aurora 

 

 

Aurora 교차 리전 읽기 전용 복제본은 재해 복구에 도움이 많이 되고 , 실행하기 간단하다. 그럼에도 불구하고 Aurora 글로벌 DB를 이용하는게 요즘 추천되는 방식이다. 이 경우 , 모든 읽기와 쓰기가 일어나는 하나의 기본 리전이 있고 최대 5개의 보조 읽기 전용 리전을 만들 수 있으며 보조 리전 당 최대 16개의 읽기 전용 복제본을 사용할 수 있다. 만약 한 리전에 데이터베이스 중단이 일어날 경우 재해 복구를 위해 다른 리전을 진급시키는데 다른 리전으로 들어가 복구시키는 시간이 1분 이내이다. 

 

 

 

 

Aurora Machine Learning

 

Aurora는 머신 러닝 서비스와 통합되기도 한다. 머신 러닝은 SQL 인터페이스를 통해 우리의 프로그램에 머신 러닝 기반 예측을 추가할 수 있다는 말이다. 두 가지 지원되는 서비스 중 하나는 Sage Maker로 백엔드인 어떤 종류의 머신 러닝이라도 사용할 수 있게 허용해준다. 

나머지 하나는 Amazon Comprehand 로 감정 분석을 할 때 사용된다. ML에 대한 경험이 없어도 이상 행위 탐지, 광고 타겟팅, 감정 분석 상품 추천 등 Aurora DB를 사용하여 간단한 SQL 쿼리만으로 ML을 사용할 수 있다.