티스토리 뷰

AWS

Aurora DB 클러스터

파미페럿 2022. 2. 16. 14:20

Aurora DB의 경우 프리티어로 사용이 불가해 실습은 할 수 없지만 Aurora DB 클러스터가 어떻게 동작하는지에 대해 정리하기 위해 이 글을 쓴다.

 

Aurora란

aws에서 제공하는 rbd로 MySQL과 PostgreSQ과 호환되는 두 버전이 있다.

aws에는 Aurora말고도 MySQL, MariaDB, PostgreSQL, Oracle, Microsoft SQL Server 이렇게 다른 rdb도 지원을 하지만(유료의 경우 라이센스 비용 별도) Aurora와는 차이가 있다.

 

Aurora의 경우는 다른 일반적인 rdb들과 달리 DB 클러스터를 자동화해 제공한다는 차이점이 있다.

이 때 용량 유형을 프로비저닝과 서버리스 둘 중 하나를 선택할 수 있는데 프로비저닝을 선택하면 클러스터 용량을 수동으로 관리해줘야하고 서버리스를 선택하면 클러스터 용량이 자동으로 관리가 된다. 이에 따라 프로비저닝의 경우는 write가 가능한 마스터 DB를 하나만 둘지(단일 마스터), 여러 DB에 write가 가능하게 할지(다중 마스터) 선택할 수 있다.

 

=> 용량이 예측할 수 없는 패턴으로 증가/축소되는 서비스에 대해 서버리스를 사용하면 자동으로 용량을 조절해줘 비용을 절약할 수 있다.

 

 

DB 클러스터

Aurora에서 자동으로 제공해주는 DB 클러스터는 DB 가용성을 위해 존재하는 기능이다.

아마 DB에 대한 마스터-슬레이브 등을 들어봤을 것이다. DB의 동작을 주로 마스터에 하고 슬레이브는 마스터에 작성되는 쿼리를 백업 받아 마스터와 똑같은 DB를 백업하고 마스터가 죽을 경우 마스터 역할을 하게 되는 것이다.

 

DB클러스터가 그런 것이다.

Aurora는 DB를 생성할 때 DB 클러스터로 생성하게 하는데 이 떄 처음에는 라이터 인스턴스가 하나 있는 상태로 DB클러스터가 생성된다.

라이터 인스턴스는 마스터 DB로 여기에 데이터가 읽기 쓰기가 일어난다. 그리고 (프로비저닝의 경우) 원하는대로 다른 DB 인스턴스를 생성할 수 있는데, 단일 마스터의 겨우 최대 15개까지 인스턴스를 추가할 수 있으며 이 인스턴스들은 읽기 전용인 리더 인스턴스로 생성된다.

 

이렇게 생성된 라이터 인스턴스와 리더 인스턴스는 서로 다른 가용 영역에 저장되어 하나가 죽어도 다른 하나가 살아있게 한다.

이미지 출처: AWS DB 클러스터(https://docs.aws.amazon.com/ko_kr/AmazonRDS/latest/AuroraUserGuide/Aurora.Overview.html)

 

만일 읽기&쓰기 동작을 하던 라이터 인스턴스가 죽을 경우 동작은 아래와 같다.

1. 리더 인스턴스가 라이터 인스턴스로 role이 변경된다. (리더 인스턴스가 여러 개일 경우 설정해놓은 장애 조치 우선 순위에 따라 라이터 인스턴스로 승격될 리더 인스턴스가 정해진다. 만일 우선순위가 같을 경우 크기가 가장 큰 인스턴스를 라이터 인스턴스로 승격시킨다.)

2. 장애가 발생한 라이터 인스턴스는 재기동되고 리더 인스턴스로 role이 변경된다.

 

 

이 떄 role이 바뀌면서 서비스가 재기동되는데 살짝 중단이 있을 수는 있지만 aws 문서에 따르면 대부분 60초 미만 안에 다 복원된다고 한다.

또한 만일 리더 인스턴스가 없어 라이터 인스턴스로 승격시킬 것이 없을 경우 장애가 발생한 라이터 인스턴스가 동이란 가용영역에 다시 생성되어 서비스 재기동에 10분 미만이라는 좀 더 긴 중단이 발생할 수 있다. 따라서 하나 이상의 리더 인스턴스를 생성해 가용성을 확보하는 것이 좋다.

 

리더 인스턴스의 경우는 원래부터 복제본으로 사용되고 있었기에 죽어도 서비스가 복구되는 등의 동작은 하지 않는다.

 

 

DB 클러스터 엔드포인트

그렇다면 DB 클러스터에는 가용성을 위해 여러 개의 DB 인스턴스가 있는 것으로 설명된다.

그렇다면 외부에서 DB에 접근할 때 매번 장애에 따라 자동으로 라이터 인스턴스가 바뀔텐데 무슨 주소로 접근하면 될까?

이 때는 하나의 DB 인스턴의 엔드포인트로 접근하기보다는 DB 클러스터 자체의 엔드포인트로 접근해야한다.

 

이 엔드포인트로 접근하면 자동으로 그 때 라이터/리더 인스턴인 DB 인스턴스로 접근해지니

각 DB 인스턴스의 엔드포인트로 접근하지 말고 꼭 DB 클러스터의 엔드포인트로 접근하자.

 

 

 

✋ Amazon Surora DB 클러스터

https://docs.aws.amazon.com/ko_kr/AmazonRDS/latest/AuroraUserGuide/Aurora.Overview.html

 

Amazon Aurora DB 클러스터 - Amazon Aurora

앞의 내용은 단일 마스터 복제를 사용하는 모든 Aurora 클러스터에 적용됩니다. 여기에는 프로비저닝된 클러스터, 병렬 쿼리 클러스터, 전역 데이터베이스 클러스터, 서버리스 클러스터, 모든 MySQ

docs.aws.amazon.com

 

✋ Amazon Aurora의 고가용성

https://docs.aws.amazon.com/ko_kr/AmazonRDS/latest/AuroraUserGuide/Concepts.AuroraHighAvailability.html

 

Amazon Aurora의 고가용성 - Amazon Aurora

각 AWS 리전 내에서 가용 영역은 중단이 발생할 경우 격리를 제공하기 위해 서로 구별되는 위치를 나타냅니다. DB 클러스터의 가용성을 개선하려면 여러 가용 영역에 걸쳐 있는 DB 클러스터에 기

docs.aws.amazon.com

 

 

 

 

반응형

'AWS' 카테고리의 다른 글

AWS 프리 티어, EC2 인스턴스 생성해 SSH로 접속해보기  (0) 2022.02.08
댓글
공지사항
최근에 올라온 글
최근에 달린 댓글
Total
Today
Yesterday
링크
«   2024/05   »
1 2 3 4
5 6 7 8 9 10 11
12 13 14 15 16 17 18
19 20 21 22 23 24 25
26 27 28 29 30 31
글 보관함