Amazon Aurora
- AWS의 특허 기술로 Postgres과 MySQL 사이에서 호환이 가능하며
기본적으로 Aurora 데이터베이스는 호환가능한 드라이버를 가지므로 Postgres와 MySQL 데이터베이스처럼 연결하면 작동 - 클라우드에 최적화되며 많은 최적화와 여러 작업이 행해져 성능이 RDS의 MySQL보다 5배, Postgres보다 3개 가량 개선되었음
- Aurora 스토리지는 자동적으로 확장되며 10 기가 바이트에서 시작하여 자동적으로 128 테라 바이트로 증가
- DB나 CIS-ops 어디에서든지 디스크를 관리할 필요가 없고 시간이 흐름에 따라 자동으로 확장
- Aurora는 최대 15개의 Replica를 가질 수 있으며 복제 속도도 훨씬 빠르게 설계되었음
- Aurora에서 장애 조치를 하면 동시적으로 발생하기 때문에 MySQL RDS의 Multi AZ의 장애 조치보다 훨씬 빠르게 조치
- 기본적으로 클라우드 네이티브이기 때문에 더 높은 가용성을 가짐
- 비용이 RDS에 비해 약 20% 정도 더 비싸지만 훨씬 효율적이며 규모적 측면에서 더 절약
Aurora High Availability and Read Scaling
- 높은 가용성과 읽기 확장을 가지며 Aurora는 3개의 AZ에 쓰기를 할 경우 6개의 데이터 복사본을 저장
(3개의 AZ에 걸쳐 6개의 복사본을 저장) - 쓰기를 위해서는 6개의 복사본 중 4개만 필요
- 읽기를 위해서는 6개의 복사본 중 3개의 복사본만 필요하며 높은 가용성을 가짐
- 자동 복구 과정을 가지며 데이터가 망가진 경우 자동 복구 과정을 통해 백엔드로 P2P 식의 복제를 실행
- 하나의 볼륨이 아닌 수 많은 볼륨에 의지하므로 큰 위험을 덜어줌
- 3개의 AZ가 있고 공유된 스토리지 볼륨을 가지고 있을 때는 논리적 볼륨으로 복제, 자동 복구, 자동 확장 등 많은 속성을 실행
3개의 AZ에는 각각 데이터의 각 2개 씩 6개의 스프라이프되어 복사본이 속하게 됨
Aurora는 RDS의 Multi AZ와 유사하며 기본적으로 쓰기를 취하는 인스턴스는 하나뿐이며 Aurora의 Master가 있음
Master가 동작하지 않으면 장애 조치는 평균 30초 이내로 행해짐
Master는 15개 이상의 Read Replica를 가지고 있고 모두 읽기를 하여 많은 Read를 가질 수 있어 읽기 워크로드를 확장
모든 Read Replica는 Master가 장애가 될 경우 Master가 될 수 있음
교차 구역 복제를 지원하여 하나의 Master에 여러 개의 Replica가 대응되며
스토리지는 각 블록별로 복제되고, 자동 복구 되고 자동 확장됨
Aurora DB Cluster
- 클라이언트를 가지고 있을 때 Aurora의 작동 방식 (인스턴스와 인터페이스하는 방법)
자동 확장되는 공유된 스토리지 볼륨이 주어지고 이는 10 기가 바이트에서 64 테라바이트로 자동 확장되고
Master만 유일하게 스토리지로 쓰기를 할 수 있으며 Master가 변경되고 장애 조치될 수 있으므로
Aurora는 Writer Endpoint를 제공하며 이는 DNS 이름을 뜻하며 항상 Master를 가르키고 있음
Master가 장애 조치될 경우 클라이언트는 Writer Endpoint와 소통하여 자동으로 올바른 인스턴스로 재설정
아주 많은 1개에서 15개의 Read Replica가 주어지며 이들은 모두 자동 확장을 가지고 있음
Reader Endpoint가 있으며 Writer Endpoint와 같은 속성을 가지며 연결 로드 밸런서를 돕고 Read Replica를 자동으로 연결
클라이언트가 Reader Endpoint에 연결될 때마다 Read Replica 중 하나에 연결되며 이 방향으로 로드 밸런싱을 행함
로드 밸런싱은 명령 단계가 아닌 연결 단계에서 행해짐
Features of Aurora
- 자동 장애 조치
- 백업 및 복구
- 격리 및 보안
- 업계 규정 (산업 규정) 준수
- 자동 확장을 위핸 푸시 버튼 스케일링
- 다운타임이 없는 자동화된 패치
- 고급 모니터링
- 루틴 유지 보수
- 백업을 사용하지 않고 언제든지 데이터 복원하기 위핸 역추적
Aurora Security
- 보안은 Postgres와 MySQL 엔진과 동일한 엔진을 사용하므로 RDS와 유사
- KMS를 사용한 고정화된 Rest 저장 데이터 암호화
- 자동 백업, 스냅샷 및 복제본도 암호화
- SSL을 사용한 in-flight 암호화 (MySQL 또는 Postgres와 동일한 프로세스)
- IAM 토큰을 사용하여 자격 증명으로 인증 가능 (RDS와 동일한 방식)
- 보안 그룹으로 인스턴스를 보호할 책임이 존재
- 인스턴스에 SSH를 할 수 없음
- Aurora 보안은 전반적으로 RDS 보안과 완벽히 동일
<Aurora Hands On>
- 오로라 데이터베이스 생성
RDS에서 표준 생성으로 MySQL 호환 버전와 PostgreSQL 호화 버전 오로라 에디션 중 MySQL 호환 버전 에디션 사용
복제 기능의 경우 단일 마스터를 사용해 단일 라이터 인스턴스에만 기록하도록 함
다중 마스터는 다중 라이터 인스턴스에 기록하는 것을 지원하며 지속적인 기록이 필요할 때 적합
엔진 버전의 경우 53개의 버전을 지원하며 각 버전은 각기 다른 기능을 지원
필터를 사용하면 전역 데이터베이스를 지원하는 버전을 선택해 다양한 AWS 리전으로 확장하거나
병렬 쿼리만 지원하는 버전 등을 선택할 수 있음
오로라가 추천해주는 2.10.1 버전을 선택
템플릿의 경우 프로덕션을 선택
데이터베이스 식별자는 database-2로 하고 사용자 이름은 admin, 암호는 password
데이터베이스 인스턴스 클래스는 비용을 최소한으로 유지하기 위해 버스터블 클래스에서 db.t3.small을 선택
가용성 및 내구성에서 다중 AZ 배포 선택
VPC와 서브넷 그룹의 경우 공용 액세스로 설정하고 새로운 보안 그룹인 demo-aurora-mysql을 생성
데이터베이스 인증에서 암호 인증을 선택
추가 옵션에서는 백업, 데이터베이스 암호화, 모니터링, 백트랙 기능 등을 활성화할 수도 있음 - 생성된 Aurora 데이터베이스
Writer 인스턴스와 Reader 데이터베이스의 리전 클러스터가 존재하며
기록하고 읽는 인스턴스가 각기 다른 인스턴스와 AZ에 존재하며
데이터베이스를 클릭하면 연결성에 엔드 포인트가 2개 있으며 리더 엔드 포인트와 라이터 엔드 포인트를 뜻함
각각 언제나 올바른 라이터 인스턴스와 리더 인스턴스로 연결되기 때문에 매우 편리
- 오로라 데이터베이스의 또다른 기능
리더 클러스터에 더 많은 리더를 추가해 스케일링 용량을 추가할 수 있으며
다른 리전에 복제본을 얻으려면 리전 간 읽기 전용 복제본을 생성할 수 있으며 언제든지 복원할 수 있음
또한 복제본 자동 스케일링을 추가할 수 있어 오로라 복제의 평균 CPU 사용량을 기반으로 하거나
오로라 복제본의 평균 연결 수를 기반으로 읽기 전용 복제본을 스케일링할 수 있으므로
ReadReplicasScalingPolicy로 생성하여 읽기 전용 복제본이 60%의 목표값을 갖도록 함
또한 기간별 스케일릉 정의할 수 있어 최소 1개에서 15개까지 오로라 복제본을 가질 수 있음 - 오로라의 전체 권한
AWS 리전을 추가하고 작업을 수행하기 위해서는 전역 데이터베이스 기능을 활성화한 버전의 오로라를 선택한 경우에만 가능
다른 리전에 데이터베이스를 추가하면 각각의 전역 데이터베이스를 얻게 되는데 지금까지 생성한 클러스터로는 불가능하며
호환 가능한 크기의 인스턴스가 필요하므로 더 큰 유형의 인스턴스로 변경해야 함
더 큰 유형의 인스턴스로 변경하면 데이터베이스 클러스터에 리전을 추가할 수 있음 - 리더 인스턴스를 삭제한 후, 라이터 인스턴스를 삭제하고 데이터베이스를 삭제
'Cloud > AWS' 카테고리의 다른 글
[SAA] ElastiCache (0) | 2022.03.08 |
---|---|
[SAA] Aurora 고급 개념 (0) | 2022.03.08 |
[SAA] RDS 암호화 + 보안 (0) | 2022.03.07 |
[SAA] RDS 읽기 전용 복제본과 다중 AZ (0) | 2022.03.07 |
[SAA] RDS 개요 (0) | 2022.03.07 |