RDS에서 데이터베이스를 생성할 때 Aurora로 설정해서 만들 수 있습니다.
AWS의 사유 기술이며, 오픈소스가 아니고 PostgreSQL, MySQL과 호환됩니다.
즉, Aurora 데이터베이스에는 호환 드라이버가 있어서 PostgreSQL, MySQL Database에 접근이 가능하다는 것입니다.
Cloud에 최적화 되어 있어서 RDS MySQL보다는 5배, RDS PostgreSQL에는 3배 이상의 향상된 성능을 보입니다.
Aurora Storage
1) 자동 확장 기능 탑재
예:) 10GB로 시작해서 데이터베이스에 데이터를 추가하는대로 최대 64TB까지 늘어남
▷ 설계 방식과 관련이 있음
2) DB or CIS-OPS로 디스크 모니터링을 할 필요가 없음
▷ 시간이 지나면 자동으로 늘어나기 때문
3) 읽기 전용 복제본인 경우에도 최대 15개까지 가질 수 있는데 MySQL은 최대 5개까지 가질 수 있음
▷ 복제 속도 또한 훨씬 빠르다
4) 장애 조치도 즉각적으로 진행
▷ RDS MySQL의 다중 AZ에서의 장애조치보다 속도가 더 빠르다. 그 이유는 Aurora가 클라우드 네이티브 기반이여서
가용성도 높기 때문에 조치 속도 또한 빠르다.
5) RDS 보다는 20% 정도 비용이 더 비싸지만 규모 면에서 더 효율적이기 때문에 오히려 비용을 절약할 수도 있습니다.
Aurora 고가용성 & 읽기 스케일링
1) 3개의 AZ에 걸처 기록하는 것은 무엇이든 6개의 데이터 복제본을 저장
예:) 6개의 복제본을 저장하는데, 쓰기에는 6개 중 4개만 필요, 즉 하나의 AZ가 다운되어도 괜찮음
읽기에는 6개 중 3개만 필요, 읽기에는 아주 적합한 구조
2) 자가 복구 과정
: 일부 데이터가 손상되거나 잘못된 경우, 백앤드에서 P2P 복제로 자가 복구 진행
▷ 하나가 아니라 수백개의 볼륨에 의지할 수 있고 백앤드에서 진행되기에 위험 부담이 적음
* Shared Storage Volume: 공유 스토리지 볼륨으로 자동 스케일링이 가능하며 10GB~64TB까지 관리됩니다.(Logical Volume)
읽기 전용 복제는 최대 15개까지 가질 수 있고 MySQL은 5개까지 가질 수 있습니다.
실제로 스토리지와 연결하는 것이 아니라 아마존에서 설계된 방식입니다.
오로라는 RDS 다중 AZ와 동일합니다. 기록하는 인스턴스는 한 개만 존재, 즉 오로라의 마스터에 기록하는 것입니다.
만든 복제본 모두를 읽을 수 있기 때문에 읽기 전용 복제본은 최대 15개 만들 수 있으며, 이를 읽기 워크로드의 확장이라고 부릅니다.
▶ 지역 간 복제를 지원하는 장점이 있음
RDS Aurora Database MASTER에는 Writer End Point를 제공받기 때문에 쓰기 권한이 있고 그로 인해서 공유 스토리지 볼륨에
데이터를 삽입 및 수정, 제거도 가능합니다. 따라서 변경이나 장애 조치가 가능하며 데이터를 입력할 경우 다른 가용영역에서도 스토리지
볼륨을 공유하고 있기 때문에 그대로 데이터를 가져다 쓸 수 있습니다.
마스터에서 데이터가 기록되면 각 AZ에서는 해당 데이터를 공용할 수 있는 읽기 전용 복제본을 만들어 냅니다.
▶ 하나의 마스터에 대해 여러 개의 읽기 전용 복제본 그리고 스토리지가 복제되고, 작은 블록별로 자가 복구와 자동 확장이 실행됩니다.
오로라에서는 하나의 마스터와 여러개의 읽기 전용 복제본 그리고 스토리지가 복제될 수 있도록 하며, 작은 블록 별로
자가 복구와 자동확장 기능을 가지고 있습니다.
오로라는 RDS를 위한 다중 가용영역과 같은 역할을 합니다.
기록하는 인스턴스는 하나이며(Aurora Master), 언제든지 읽기 전용 복제본이 마스터가 될 수 있습니다.
마스터가 장애가 생겨서 작동하지 않으면 평균적으로 30초 안에 장애 조치가 진행되며 해당 읽기 복제본이 마스터가 됩니다.
(▷ 모든 읽기 전용 복제본이 마스터 장애시 마스터가 될 수 있음)
Writer End Point를 제공받은 마스터는 쓰기 권한이 있어서 공유 스토리지에 데이터를 CRUD 작업을 합니다. (유지보수)
이를 통해 변경된 내용은 각 AZ에서 복제본을 생성해서 읽기 전용 복제본에서 가져다 쓸 수 있도록 구성이 됩니다.
DNS 이름으로 Writer End Point는 늘 마스터를 향해 있기 때문에 마스터가 장애가 발생할 경우에도 Client는 Writer End Point와
통신하여서(by DNS Name) 올바른 인스턴스로 자동 Re-Direction을 진행합니다.
읽기 전용 복제본은 최대 15개까지 생성되며(MySQL: 5개), 읽기 전용 복제본이 생성됨에 따라 Aurora에서는 Auto-Scaling을 통해
읽기 전용 복제본이 생성되는 만큼 그 용량, 크기가 필요하기에 스케일링 작업이 자동으로 수행됩니다.
(≒ 오토스케일링을 통해 읽기 전용 복제본을 만들어낸다.)
이렇게 늘어난 읽기 전용 복제본은 Reader-End-Point와 자동으로 연결되며 백업 용으로 관리되면서 원래의 로드를 나눠 분배 받습니다.
(로드밸런싱이 Reader-End-Point에 의해서 진행되며 필요한 처리 볼륨만큼 각 복제본은 나눠서 전달받게 됩니다.)
※ 이렇게 로드 밸런싱 되는 이유 ★★★
▶ 읽기 전용 복제본이 늘어날수록 가용 공간을 늘리기 위해서 Auto Scaling이 진행되는데, Application에서는 읽기 전용 복제본과
URL을 추적하는 것이 어렵고 새로 생긴 복제본에 대해서 연결하는 것도 쉽지 않습니다. ★ (문제) ★
이러한 해결책으로서 Reader-End-Point에서는 로드 밸런싱 연결을 돕고 모든 읽기 전용 복제본이 Reader-End-Point와 자동으로 연결될 수 있도록 설정합니다.
따라서 클라이언트가 Reader-End-Point에 연결할 때마다 읽기 전용 복제본 중 하나가 Reader-End-Point와 연결되어 로드 밸런싱이 됩니다. ★ (대안) ★
* 로드 밸런싱은 연결 수준에서 발생합니다.
▷ Reader-End-Point가 각 복제본을 자신과 연결시켜 놓고 클라이언트가 Reader-End-Point에 연결될 때 읽기 전용 복제본 중 하나를 가져다가 연결 시켜서 로드 밸런싱하기 때문에 연결 수준에서 발생하는 것(명령문 X)
Aurora 특징(Back-End에서 수행)
1) 자동 장애조치, 백업 및 복원이 쉬움
2) 격리, 보안과 산업 규정 준수 기능
3) Auto Scaling을 토한 푸시 버튼식 스케일링
4) 다운 타임이 없도록 자동 패치
5) 고급 모니터링
6) 정기 유지보수
7) 백트랙(언제든지 데이터를 복원할 수 있음 ▷ 백업을 활용하지 않는 방법!)
Aurora Security
1) RDS와 같은 엔진을 쓰고 있기 때문에 보안 규칙이 동일하다.
2) KMS로 미사용 데이터를 암호화합니다. (≒ RDS)
3) 자동 백업과 스냅샷 그리고 복제본도 암호화됩니다.(≒ RDS)
4) 전송 중에는 SSL로 암호화됩니다.(≒ RDS)
5) IAM 토큰(사용자 인증)(≒ RDS)을 통해 RDS MySQL, RDS PostgreSQL 모두 통합이 가능합니다.
6) 보안그룹으로 인스턴스를 보호하며 (≒ RDS Security Group) SSH 인스턴스에 연결하지 않습니다. (≒ RDS)
'Cloud' 카테고리의 다른 글
| AWS - DNS (0) | 2023.02.04 |
|---|---|
| AWS - Elastic Cache (0) | 2023.01.30 |
| AWS - RDS (0) | 2023.01.25 |
| AWS - ASG(2) (0) | 2023.01.25 |
| AWS - ASG(1) (0) | 2023.01.19 |
