[AWS] Amazon Aurora

https://jeidiiy.notion.site/Amazon-Aurora-9ad08277dc2443c0be32a7d5c711463c?pvs=4 

Amazon Aurora

💡노션에 최적화된 글입니다. 위 링크를 통해 접근할 수 있습니다.

Amazon Aurora

목차

1. Amazon Aurora란?
2. Aurora의 고가용성 및 읽기 스케일링
3. Aurora DB Cluster
4. 특징 정리
5. 고급 개념
6. 백업
7. 복원
8. 보안

1. Amazon Aurora란?

• AWS에서 만든 고유 DB 기술 (not open sourced)
• PostgreSQL, MySQL과 호환
• AWS 클라우드에 최적화되어 있고 그 외 많은 최적화 기법을 통해 RDS의 MySQL보다 5배, PostgreSQL보다 3배 높은 성능
• 스토리지 자동 확장 (10GB ~ 128TB)
• 15개의 읽기 전용 레플리카 지원(MySQL - 5개) 및 RDS보다 빠른 레플리케이션 처리 속도
• 즉각적인 장애 조치
  • 다중 AZ나 MySQL RDS보다 훨씬 빠름
• 클라우드 네이티브로 인한 높은 가용성
• 비용은 RDS보다 20% 정도 비싸지만 스케일링 측면에서 훨씬 효율적이며 비용 절감 가능

2. Aurora의 고가용성 및 읽기 스케일링

• DB 작업 시 3개의 AZ에 걸쳐 6개의 사본에 저장
  • AZ 하나에 문제가 생겨도 상관 X
• 쓰기는 6개의 사본 중 4개 필요
• 읽기는 6개의 사본 중 3개 필요
• 쓰기를 받는 마스터 인스턴스는 1개
• 레플리카는 여럿이며 스토리지 복제
• 마스터가 작동하지 않으면 평균 30초 이내로 장애 조치 시작
  • 마스터에 문제 발생 시 읽기 전용 레플리카 중 하나를 마스터로 대체
• 레플리카들의 리전 간 복제 지원
• 일부 데이터가 손상되거나 문제 발생 시 P2P 복제를 통한 자가 복구 진행
• 단일 볼륨이 아닌 수 백 개의 볼륨 사용Aurora 동작 원리
• 공유하는 스토리지 볼륨을 통해 레플리케이션, 자가 복구, 자동 확장을 수행
• 데이터 쓰기 작업 시 3개의 가용 영역에 6개의 사본이 계속 생성
• 각기 다른 볼륨에 기록되며 스트라이프 형식으로 되어 작동
• 작은 블록 단위로 자가 복구 또는 확장 수행

3. Aurora DB Cluster

• Aurora에서는 Writer, Reader 엔드포인트를 제공

Writer Endpoint

• 스토리지에 대한 쓰기 작업은 마스터만 가능
• 마스터가 바뀌거나 장애 조치가 실행될 수 있으므로 엔드포인트를 둠
• DNS 이름으로 항상 마스터를 가리킴
• 클라이언트는 장애 조치 후에도 Writer Endpoint와 상호작용하므로 올바른 인스턴스로 자동 리다이렉트

Reader Endpoint

• 읽기 전용 레플리카는 15개까지 생성 가능하며 자동 스케일링 가능
• 항상 적절한 수의 읽기 전용 레플리카가 존재하도록 할 수 있음
• 이 경우 레플리카의 위치, URL, 연결 정보 등에 대한 파악이 어려움
• 따라서 Reader Endpoint를 두어 모든 다운스트림 레플리카에 대해 로드 밸런싱

💡 로드 밸런싱은 문장 레벨이 아닌 연결 레벨에서 일어난다.

4. 특징 정리

• 장애 조치 자동화
• 백업 및 복구
• 격리 및 보안
• 산업 규정 준수
• 다운타임이 없는 자동 패치
• 자동 스케일링을 통한 버튼식 스케일링
• 고급 모니터링
• 유지 관리
• 백트랙
  • 과거의 어떤 시점으로도 복원하는 기능

5. 고급 개념

Aurora Replicas - Auto Scaling

• 엔드포인트에 대한 요청이 매우 많아 자원 사용량 증가 시 레플리카 자동 스케일링 설정 가능
• 스케일링 시 Aurora 레플리카 추가
• 그리고 새로운 레플리카 처리를 위해 자동으로 Reader Endpoint가 연장됨
• 그러면 새로운 레플리카들이 트래픽을 받게 되므로 분산 처리

Custom Endpoint

• 레플리카의 유형이 다른 경우가 있음
• 특정 레플리카의 경우 더 높은 사양일 수 있음
• 이러한 레플리카를 특정하여 분석 쿼리와 같은 처리를 실행

💡 Custom Endpoint를 정의한 경우 Reader Endpoint는 사용하지 않는다. 사라지지는 않지만 더 이상 사용하지 않는다.

Aurora Serverless

• 실제 사용량에 기반한 DB 인스턴스와 스케일링을 자동화해주는 기능
• 비정기적, 간헐적, 예측 불가한 워크로드에 유용
• 용량 계획 X
• 각 Aurora 인스턴스에 대해 매 초당 비용 지불

작동 원리

• 클라이언트는 Aurora가 관리하는 프록시 플릿과 통신
• 백엔드에서 워크로드에 기반해 서버리스 방식으로 다수의 Aurora 인스턴스 생성

Aurora Multi-Master

• Writer 노드에 대한 즉각적 장애 조치
• Writer 노드에 높은 가용성 필요 시 사용
• 이 경우 Aurora 클러스터의 모든 노드에서 읽기 및 쓰기 가능
  • 기존의 경우 하나의 쓰기 노드만이 존재하며 해당 노드 장애 시 읽기 노드 중 하나를 승격시켜야 했음

Global Aurora

Aurora Cross Region Read Replicas

• 재해 복구에 유용하며 생성 간단
• 최근에는 Aurora Global DB 생성을 권장

Aurora Global

• 모든 쓰기 및 읽기가 진행되는 하나의 기본 리전 존재
• 복제 지연이 1초 미만인 보조 읽기 전용 리전을 5개까지 설정 가능
• 각 보조 지역마다 읽기 전용 레플리카를 16개까지 생성 가능
• 세계 각지에 있는 읽기 전용 레플리카의 지연 시간 단축 가능
• 한 리전의 DB가 작동 중단될 경우 재해 복구 목적으로 다른 지역을 승격하는데 필요한 RTO(복구 시간 목표)는 1분 미만

💡 리전에 걸쳐 데이터를 복제하는데 걸리는 시간은 평균 1초 미만이다. 라는 문장이 시험에서 보이면 Global Aurora를 사용하라는 단서이다.

Aurora Machine Learning

• ML 기반 예측을 SQL 인터페이스로 애플리케이션에 적용하는 기능
• 쉽고 최적화된 방식으로 안전하게 통합 가능

지원 서비스

• SageMaker - 머신 러닝 모델
• Comprehend - 감정 분석

6. 백업

자동 백업

기간

• 1일 ~ 35일
• 비활성화 불가능
• 정해진 시간 범위 내의 어느 시점으로도 복구 가능

수동 DB 스냅샷

• 사용자가 수동으로 스냅샷 생성
• 원하는 기간만큼 보유 가능

7. 복원

스냅샷

• 자동 백업이나 수동 스냅샷을 복원할 때마다 새로운 DB 생성

S3

기본 개념

1. Percona XtraBackup을 사용하여 온프레미스 DB의 백업 생성
2. S3에 백업 파일 저장
3. S3의 백업 파일로 실행 중인 MySQL에 새로운 Aurora DB 클러스터로 복원

8. 보안

• 암호화
  • AWS KMS를 사용한 DB 마스터 및 레플리카 암호화
    • 반드시 생성 시 정의
  • 마스터가 암호화되지 않았다면 레플리카 또한 암호화 불가
  • 암호화되지 않은 DB를 암호화하려면 DB 스냅샷 생성 후 복원 시 암호화
• In-flight 암호화
  • 기본적으로 데이터 전송 중 암호화 기능 적용
  • 클라이언트는 AWS에서 제공하는 AWS의 TLS 루트 인증서를 사용해야 함
• IAM 인증
• 보안 그룹
  • 특정 포트, IP 등을 활용하여 네트워크 통제
• SSH 접근 불가능 - Custom 제외
• Audit 로그 사용 가능, 장기 보존을 위해 CloudWatch 로그로 전송 가능