[이론] AWS Database 기본 개념

안녕하세요 서후아빠입니다. ^_^

이번 세션은 AWS Database에 대해서 업무적으로 필요한 최소한의 개념에 대해서 간단히 정리해 보았습니다.

---

Database

RDS : MSSQL, Oracle(Oracle OLAP), MySQL, PostgreSQL, MariaDB

  - MSSQL, Oracle : 별도 라이선스 비용 발생(자신의 라이선스 사용 가능)

NoSQL : DynamoDB, DocumentDB, ElasticCashe
EC2 인스턴스에서 동작 : OS를 AWS에서 관리하기 때문에 SSH로 액세스 불가능

Public IP 할당 : 필요한 경우 DNS로 접근 가능

스토리지 : EBS 활용, 고정 용량 설정, 추후 용량 증설 가능
CloudWatch 연동 : Log(error, general 등) 등 모니터링
Parameter Group : Root유저만 설정 가능한 DB의 설정값들을 모아 놓은 그룹

  - DB클러스터에 Parameter Group 적용시켜 설정값을 적용
업데이트

  - 마이너 버전 엔진 : 자동 설정 가능

  - 기타 구성 및 일반적인 업데이트 : 시간 설정으로 자동 설정 가능
로그인 방식 3가지

  - ID+PW : PW는 AWS Secret Manager 연동하여 자동 변경 가능

  - IAM DB 인증 : DB를 IAM 유저 크레덴셜/Role 통해 관리 가능

  - Kerberos 인증 : AD 연동
비용 : 컴퓨팅 파워+스토리지 용량+백업용량+네트워크 비용, RI 약정 시 저렴 (단, Instance 변경 불가하므로 신중)
암호화

  - SQL서버 (or Oracle)는 TDB (Transparent Data Encryption) 지원

  - EBS 볼륨 암호화 지원 : Default Master Key (or 생성한 Master Key) 선택 가능

  - Auto Backup, Snapshot, Read Replica 등에 적용
백업

  - 자동 백업 : Daily Snapshot (Data+트랜잭션 로그)을 S3에 저장, 1~365일 보관 지원,백업 시 약간의 Delay 발생

  - 수동 백업 : User (or 다른 프로세스)의 요청에 따라 Snapshot을 S3에 저장,  DB클러스터 삭제 시에도 보관
복제(복원) : 신규 DB클러스터(Instance)로 생성하여 교체  

RDS 구성 (Multi AZ)

동일 VPC, 멀티 AZ, Primary-Standby 구성 : 안정성 우선
Primary 장애 시 Standby가 원본으로 승격 : DNS가 Standby로 자동 연결(평상 시 Standby로 접근 불가)
SQL서버, Oracle, MySQL, PostgreSQL, MariaDB 지원

  ※ Aurora 경우 멀티AZ 설계단계에서 지원

Multi AZ 구성도

RDS 구성 (읽기 전용 복제본 (Read Replica))

원본(Master : M) DB는 쓰기, 복제(Read Replica : RR) DB는 읽기

  - 워크로드 분산, 성능 우선, 최대 5개까지 생성 가능

  - 자동 백업 활성화시에만 RR생성 가능

  - Oracle, MySQL, PostgreSQL, MariaDB, Aurora 지원

  - 원본 DB 장애 시 복제 DB 중 1개 선택하여 수동으로 RR DB를 Master DB로 DNS 변경
복제 DB

  - 접근 가능한 각 고유 DNS 할당

  - 타 리전에도 복제 DB 구성 가능

  - 복제본 자체에 멀티AZ 구성 지원 : Oracle, MySQL, PostgreSQL, MariaDB
각 DB의 엔진 버전이 다를 수 있음

Read Replica 구성도

RDS 구성 (Multi Region)

읽기 전용 복제본과 거의 동일

  - A리전의 Master DB 장애 발생 시 수동으로 B리전의 RR DB를 Master DB로 승격
주로 로컬 성능 (or DR시나리오)으로 활용
리전별 : 자동 백업 가능, 멀티 AZ 가능

RDS 구성 비교(Multi AZ vs Read Replica vs Multi Region)

구분	Multi AZ	Read Replica	Multi Region
목적	고가용성	확장성 / 성능	로컬 성능 / DR개념
복제방식	sync	Async	Async
Active	Primary만	Read만	Read만
Backup	자동백업	기본적으로 Off	자동백업
Failover	자동	수동	수동
엔진 Update	Primary만	개별 DB별	리전별

Aurora

지원 : MySQL, PostgreSQL
속도 향상 : MySQL보다 5배, PostgreSQL보다 3배
비용 절감 : 상용 RDB보다 1/10배
Amazon RDS에서 H/W 프로비저닝, DB 설정/패치/백업 작업 자동화
96vCPU와 768GB까지 증가 가능 (db.r5.24xlarge)
스토리지에 데이터 분산 저장 (최소 6개 복제 = AZ별 2개 x 최소 AZ 3개 이상)

  - 스토리지는 자동 증감(10GB 단위, 최대 128TB)

  - Quorum 모델 사용 : 투표 시스템, 아래처럼 6개 중 몇 개가 정상인지 보고 판단

  - 쓰기 능력 상실 : 6개 중 3개 이상 (and 1개의 Full) 손실 경우    ■■■□□□ (□ : 손실) 

  - 읽기 능력 상실 : 6개 중 4개 이상 (or 3개의 Full) 손실 경우       ■■□□□□ (□ : 손실)

  - 손실된 복제본 자가 치유 : 지속적으로 손실 부분 검사 후 복구
CloudWatch 연동 : Log(error, general 등) 등 모니터링
백업

  - RDS처럼 자동/수동 백업 지원

  - 읽기 복제본 지원 : MySQL의 바이너리 log 복제 (Binlog), 다른 리전에만 생성 가능
복제 (복원) : 스냅샷 이용하여 Copy-on-Write

  -  데이터를 페이지처럼 연결 : 신규 Instance 생성보다 빠르고 저렴

  - 기존 DB클러스터 삭제해도 정상 동작

Copy-on-Write 흐름도

복제 (복원) : Backtrack (테이프 되감기와 비슷한 개념)

  - 기존 DB를 특정 시점으로 복원, 시간당 DB변화 저장

  - 생성 시 설정한 경우만 지원되므로 스냅샷을 복구/복제 통해 기능 활성화 가능

  - MySQL만 지원, Multi-Master 모드 미지원

병렬쿼리 : 다수의 읽기 노드를 통해 병렬로 쿼리 처리

  - MySQL 5.6/5.7에서만 지원, 낮은 인스턴스 (db.t2, db.t3 등)와 Multi-Master 모드 미지원

Target Backtrack Window : 지정 시점(or 기간) 정의, 그 시점 이전으로는 Backtrack 불가능 Actual Backtrack Window : 실제 시간을 얼만큼 돌릴지 정의, Target Backtrack Window보다 적어야 함. Actual Backtrack Window > Target Backtrack Window 경우 알림 발생

지속적인 서비스 제공 개념

  - MTTF : 실패까지 걸리는 시간 (ex : 1시간마다)

  - MTTR : 복구까지 걸리는 시간 (ex : 몇분 내, 10GB 단위로 디스크 보관)

  - Amazon은 MTTF시간보다 MTRR시간이 짧기 때문에 서비스 정상 유지
LSN (log seqence number) : 데이터베이스 로그 파일에서 특정 로그 파일의 위치 혹은 오프셋

  - 쓰여진 데이터 바이트만큼 추가

  - 각 쿼리 (=로그파일)별로 고유의 값 획득되고 계속 증가

LSN 구조

  - 6개 구성 : 3개는 Full Segment (data+log record, 10GB단위), 3개는 Tail Segment (log record, 10GB 단위)
빠른 응답 원인 : LSN 비교해서 응답 가능한 스토리지 선정 > Latency 가장 짧은 스토리지 선정 > 응답

  - 사용자 요청하면 LSN 비교해서 바로 처리 응답

  - 실제는 백업단에서 Async 방식으로 업데이트 : 모든 스토리지가 동일한 상태 아님
비용 : 스토리지 6개 비용이 아닌 3개(Full)+0.X개(Tail)의 비용

Aurora 구성 (Single-Master 모드)

쓰기 전용 (Aurora Master) 1개 노드, 읽기 전용 (Aurora Replica) 다수 노드
최대 15개 Replica 생성 가능 : Async 복제, 하나의 리전 내 
Master 장애 시 데이터 손실없이 자동으로 Replica 중 1개가 Master로 Failover 

Single-Master 모드 구성도

Aurora 구성 (Multi-Master 모드)

쓰기/읽기 가능한 (Aurora Master) 다수의 노드 : 최대 4대 노드

  - 각 노드 독립적 (정지/재부팅/삭제 등에 상호 영향 없음)

  - HA보다 높은 지속적인 가용성 (Continuous Availability)

  - 주로 Multi-tenant (or Sharding) 적용된 Application에 적합

Multi-Master 모드 구성도

Version upgrade

RDS(Aurora 포함)은 서비스에 대해서 가용성 고려하여 다양한 구성 (Multi AZ, Read Replica, Multi Region, Single-Master, Multi-Master 등)이 가능하나, 유지보수 측면에서는 해당이 되지 않습니다. 

모든 Managed database는 수동이든 자동이든 upgrade가 진행되면 서비스를 유지(무중단)하고 upgrade 불가능하다는 점 꼭 기억하시기 바랍니다. 

RDS : https://docs.aws.amazon.com/ko_kr/AmazonRDS/latest/UserGuide/USER_UpgradeDBInstance.Upgrading.html > 엔진 버전 수동 업그레이드

Aurora  :  https://docs.aws.amazon.com/ko_kr/AmazonRDS/latest/AuroraUserGuide/Aurora.Modifying.html> Amazon Aurora에 대한 설정