[AWS] AWS 기술 정리 5편 RDS, Aurora, ElastiCache - (AWS SAA, Udemy 강의 정리)

https://aws.amazon.com/ko/certification

 

 이 글은 24년 하반기 AWS Certified Solutions Architect - Associate(이하 AWS SAA-C03) 자격증 취득을 위해서 아래 유데미 강의를 보고, 공부한 내용을 정리하였습니다.

https://www.udemy.com/course/best-aws-certified-solutions-architect-associate

 

RDS

RDS: SQL을 쿼리언어로 사용하는 DB에 대한 관계형 데이터베이스 서비스

`- Postgres, MySQL, MariaDB, Oracle, Microsoft SQL Server, IBM DB2, Aurora(AWS 독점 DB)

 

RDS를 사용하는 이유

관리형 서비스, DB 프로비저닝 자동화, OS 패치, 지속적 백업, 특정 시점 복원, 모니터 데시보드, Multi-AZ, 수평/수직 확장, EBS의 지원을 받음(gp2, io1)

(단, SSH는 사용불가)

 

`RDS 스토리지 오토스케일링

- RDS를 생성할 때 원하는 스토리지 용량을 지정해야함, RDS는 DB가 찬걸 감지하고, 자동으로 늘림 / 혹은 RW가 많아지면 자동으로 스케일링됨

- 최대 저장 임계값을 설정해야함

- 모든 DB엔진이 지원함

 

 

`RDS 읽기 전용 복제본 & 다중 AZ의 차이

읽기 전용 복제본

- 읽기를 스케일링함, 15개까지 Read Replica를 사용할 수 있음

- 동일 AZ도 가능하고, AZ나 리전을 걸쳐서 생성될 수도 있음

- 비동기식(읽기가 일관적으로 유지되는 것)으로 동작함, 업데이트가 바로 이뤄지지 않을 수도 있음

- 만약 복제본 중 하나를 데이터베이스로 사용하고자 그에 대한 권한을 획득하면, 복제 메커니즘에서 탈피함. - 단 자체적인 생애 주기를 가짐

- 읽기 전용 복제본을 사용할 때는, 애플리케이션의 모든 연결을 업데이트해 RDS 클러스터 상의 읽기 전용 복제본 전체 목록을 활용 가능

 

사용 사례 : 평균적인 로드를 감당하는 DB가 있을 때, 보고/분석을 위해 애플리케이션을 개발하는 상황에서 메인 DB에 직접 연결하면, 오버로드가 발생하고 애플리케이션 속도가 느려짐, 이때 새로운 워크로드에 대한 읽기 전용 복제본을 생성하면, DB인스턴스와 읽기 전용 복제본 간 비동기식 복제가 발생함.. 이때 분석 애플리케이션이 읽기 작업과 분석을 실행하면 오버로드 없이 가능

 

당연히 SELECT 명령문에만 사용 가능!

 

네트워킹 비용

- AZ간 이동을 해도 동일 리전에 있을 때는 비용을 내지 않음

- 다른 리전에 존재할 경우 복제 비용이 발생함

 

다중 AZ

주로 재해 복구에 사용(가용성을 높일 수 있음)

동기식으로 다른 AZ에 스탠바이 인스턴스로 복제함

하나의 DNS 이름을 갖고, 마스터에 문제가 생길 때도 자동으로 스탠바이 DB에 장애 조치가 수행됨

전체 AZ 또는 네트워크 손실에 대비한 장애조치

자동으로 failover됨

 

`원하는 경우 읽기 전용 복제본을 다중 AZ로도 설정할 수 있음

 

`단일 AZ에서 다중 AZ로 RDS DB 전환이 가능함, 이때 다운타임이 전혀없음(무중단)

 

`내부적으로 기본 DB의 RDS가 자동으로 스냅샷을 생성하고, 새로운 스탠바이 DB에 복원됨.

이후 두 DB간 동기화가 설정되어, 다중 AZ 설정 상태가 됨.

 

 

RDS 커스텀

RDS에서는 기저 OS나 사용자 지정 기능에 엑세스할 수 없음.. RDS 커스텀에서는 가능

Oracle과 MS SQL Server를 다룸.. 

RDS를 통해 AWS의 DB 자동화 설정, 운영, 스케일링의 장점을 챙길 수 있음

기저 DB와 OS에 접근 가능, 내부 설정 구성, 패치 적용, 네이티브 기능 활성화 가능, SSH/SSM 세션 관리자로 RDS 뒤에있는 EC2 인스턴스에 접근 가능

사용자 지정 설정을 사용하려면, RDS가 수시로 자동화, 유지 관리, 스케일링을 수행하지 않도록 자동화를 꺼두는게 좋음

쉽게 문제가 생길 수있으니 DB 스냅샷을 만들어 두면 좋음

 

RDS: DB 전체를 관리해줌 OS 등 AWS에서 관리하고 아무것도 안해도됨

RDS 커스텀 : Oracle, MS SQL Server에서만 사용가능, 기저 OS/DB에 대해 관리자 권한을 가짐

 

 

Amazon Aurora

- AWS 고유 기술로 Postgres와 MySQL이 호환되게 만듬

- 클라우드에 최적화되어 MySQL보다 5배 높은 성능, Postgres보다 3배 높은 성능

- 자동으로 확장 가능 10GB에서 시작해서 128TB까지 커짐

- 15개의 읽기전용 레플리카 사용가능, 복제속도 더 빠름

- Failover가 즉각적임, 다중 AZ나 MySQL RDS보다 훨씬 빠름. 가용성이 높음

- 비용은 RDS보다 20% 정도 더 비쌈

 

 

높은 가용성 & 읽기 스케일링

`- Aurora는 무언가를 기록할 때마다 3개의 AZ에 걸쳐 6개의 사본을 저장

  - 쓰기에는 6개의 사본 중 4개만 있으면 됨

  - 읽기에는 6개의 사본 중 3개만 있으면 됨

  - 백엔드에서 P2P 프로세스를 통해 자가 복구 프로세스가 있음

  - 단일 볼륨에 의존하지 않고, 수 백 개의 볼륨을 사용함

 

RDS의 다중 AZ와 유사 : 쓰기를 받는 인스턴스는 하나뿐이고, Aurora에도 마스터가 하나 존재해 여기서 쓰기를 받음, 마스터가 동작하지 않으면 30s 내로 페일오버 시작. 마스터에 문제가 생기면 읽기 전용 복제본 중 하나가 마스터가 되어 대체함.

복제본들은 리전 간 복제를 지원함

 

`Aurora DB 클러스터

- 마스터가 교체될 수 있음으로, Aurora에서는 라이터(Writer) 엔드포인트를 제공함, 라이터는 DNS 이름으로 항상 마스터를 가리킴

- 읽기 전용 복제본은 오토스케일링 할 수 있음

- 읽기 전용 복제본들에게 Client가 접근하기 위해서 Reader 엔드포인트를 제공함, 이는 연결 로드 밸런싱에도 도움을 줌.. 문(state) 레벨이 아닌 연결 레벨에서 로드밸런싱이 일어남

 

Aurora 기능

- 자동 페일오버 / 백업, 복원 / 격리 및 보안 / 산업 규정 준수 / 버튼식 스케일링 / zero 다운타임 자동 패치 / 고급 모니터링 / 통상 유지관리 / 백트랙(과거 어떤 시점으로든 복원 가능)

 

 

Aurora 고급 개념

복제본 오토스케일링

ex) DB에 많은 읽기 요청이 와서 CPU 사용량이 증가 시 복제본 오토스케일링으로 레플리카들이 추가되고, Reader 엔드포인트는 새로운 레플리카를 위해 확장됨

 

사용자 지정 엔드포인트

ex) Read 레플리카의 인스턴스 종류가 2가지라고 할 때, 읽기 레플리카 인스턴스의 부분집합을 커스텀 엔드포인트로 설정 가능... 더 인스턴스 성능이 좋은 특정 복제본들이 분석 쿼리를 담당하는 것이 나을 경우와 같을 때 사용... 

사용자 지정 엔드포인트 정의후에는 Reader 엔드포인트 자체는 사용하지 않게됨(없어지는 건 아님), 각 업무마다 다양한 사용자 지정 엔드포인트를 만들어야함

 

Aurora 서버리스

간헐적, 예측 불가 업무량에 대응 가능 

ex) 클라이언트는 Aurora가 관리하는 프록시 플릿(Proxy Fleet)에 연락함, 백엔드에는 많은 Aurora 인스턴스 생성(업무량에 기반해 자동 생성)

 

글로벌 Aurora

리전 교차 읽기 전용 복제본은 재해 복구나 실행에 간편함

하지만 요즘은 Aurora Global Database를 추천함

- 모든 읽기/쓰기가 일어나는 하나의 기본 리전이 있음

- 최대 5개의 보조 읽기 전용 리전을 만들 수 있는데, 응답 지연이 1초 이하임

- 보조 리전 당 최대 16개의 읽기 전용 복제본 생성 가능

- 전 세계에서 오는 읽기 업무량에 따른 대기 시간을 줄일 때 도움을 줌

- 한 리전이 중단되어도 다른 리전을 진급(R/W 다 가능하도록)시키는데, 복구 시간이 1분미만

`- 평균적으로 Aurora Global DB에서 한 리전에서 다른 리전으로 데이터를 복제하는 데에는 1초 이하의 시간이 걸림

 

Aurora Machine Learning

- SQL 인터페이스를 통해 응용프로그램에 기계 합습 기반의 예측을 추가할 수 있음

- Aurora와 다른 AWS ML 서비스 간의 간단하고 최적화된 안전한 통합

- SameMaker(ML 모델 사용)와 Comprehend(감정 분석에 사용)이 통합 가능

- 사례 : 이상 행위 탐지, 광고 타겟팅, 감정 분석, 상품 추천

- 응용프로그램 - Aurora - Sagemaker - 결과 응답(예측치)

 

 

RDS & Aurora 백업과 모니터링

RDS 백업

자동화된 백업

- 자동으로 전체 백업을 함, 5분마다 트랜잭션 로그가 백업

- 가장 빠른 백업은 5분 전의 백업(항상 5분전으로 복원 가능)

- 1~35일 동안 보관 가능

 

수동 데이터베이스 스냅샷

- 사용자가 수동으로 트리거함

- 백업을 원하는 기간동안 유지가능

`사례 : 한 달에 2시간만 사용하는 DB가 있다면? 스냅샷을 만들어서 비용절감을 할 수 있음

 

Aurora 백업

자동화된 백업

- 1~35일 동안 보관 가능(단, 비활성화 불가.. RDS는 가능)

- 시점 복구 기능 있음

 

수동 DB 스냅샷

<- RDS와 유사함

 

?* 재해 복구 및 감사 목적으로 Aurora 데이터베이스에 대한 장기 백업을 저장시, Aurora DB 복제 사용

 

RDS & Aurora 복원 옵션

- RDS 또는 Aurora의 백업 또는 스냅샷은 그것들로 새 데이터베이스를 생성하는 것

 

S3로부터 RDS MySQL 복원하기

- 온프레미스 DB를 생성하고, S3에 객체로 저장해두기

- RDS에는 S3에서 백업 파일을 복원하거나 새로운 RDS MySQL을 실행하는 옵션이 있음

 

S3로부터 Aurora 클러스터  MySQL 복원하기

- 외부적으로 온프레미스 DB를 다시 백업하면됨, Percona XtraBackUp이라는 SW 사용

- Percona XtraBackUp의 백업 파일을 S3로 보내, 거기서 백업을 복원할 수도 있음(MySQL을 실행하는 새 Aurora Cluster로 복원됨)

 

차이점은, RDS 복원시에는 DB 백업만 있으면 되지만, Aurora에서는 ' Percona XtraBackUp'로 백업을 하고, S3에서 Aurora DB 클러스터로 백업해야함

 

 

Aurora Database 복제(cloning)

기존 DB 클러스터에서 새로운 Aurora DB 클러스터 생성가능

ex) 프로덕션 DB가 있고, 테스트를 실행하고 싶을 때, staging DB로 복사할 수 있음

- 스냅샷 찍고 복제보다 빠름, 복제는 copy-on-write 프로토콜을 사용하기 때문

  - 처음 DB 복제본을 만들 때는, 원래 DB 클러스터와 동일한 데이터 볼륨을 사용하게 됨.

  - 데이터를 복사하지 않아 빠르고 효율적

  - 프로덕션이나 스테이징 Aurora DB에 업데이트가 이뤄지면 새로운 추가 스토리지가 할당되고, 데이터가 복사 및 분리가 됨

- DB 복제는 빠르고 비용 효율적이며, 프로덕션 DB에 영향을 주지 않고 복제하는데 유용

 

 

RDS & Aurora 보안

저장된 데이터 암호화

- KMS를 사용해 마스터와 모든 복제본의 암호화가 이뤄짐, DB를 처음 실행할 때 정의됨

- 마스터가 암호화되지 않았다면, 읽기 복제본도 암호화 안됨

- 암호화되지 않은 DB를 암호화하고 싶다면, DB 스냅샷을 가져와서 암호화된 형태로 복원해야함

 

클라이언트-DB간 전송 중 암호화

- 각 클라이언트는 AWS에서 제공하는 TLS 루트 인증서를 사용해야함

 

IAM 인증

- 사용자 이름과 PW라는 전통적인 방식도 있지만, AWS IAM 역할을 사용해서 DB에 접속할 수도 있음

- IAM을 이용한 웹 서버 인증은 Postgres/MySQL에서 가능

 

보안 그룹

DB에 대한 네트워크 엑세스를 통제할 수 있음

 

SSH 엑세스가 없음(단, AWS RDS 커스텀 서비스는 예외)

감사 로그가 있어서 시간에 따라 어떤 쿼리가 생성되는지 기록(cloudwatch log로 보내면 장기보관 가능)

 

 

RDS Proxy

완전 관리형 RDS DB 프록시도 배포 가능

- RDS 프록시를 사용하면 애플리케이션이 DB 내에서 DB 연결 풀을 형성하고 공유할 수 있음

- 애플리케이션이 RDS DB 인스턴스에 일일이 연결하는 대신, 프록시에 연결하면 프록시가 하나의 풀에 연결을 모아 RDS DB 인스턴스로 가는 연결이 줄어듬

`- 연결이 줄어들면, DB CPU/RAM 사용률이 줄어들어 DB 효율성이 향상되고, 개방된 연결을 최소화하고 시간초과를 줄일 수 있음

- RDS 프록시는 서버리스로 오토스케일링, 다중 AZ를 지원함

`- 페일오버 발생시 대기 인스턴스로 실행되어, 장애 조치 시간을 66% 줄일 수 있음

  - RDS 프록시가 페일오버가 발생한 RDS DB 인스턴스를 처리하기 때문

- MySQL, PostgreSQL, MariaDB용 RDS를 지원 / MySQL, Postgres Aurora ㅣㅈ원

- 어플리케이션 코드 수정없이, 연결을 RDS 프록시로 하기만 하면됨

`-  DB에 IAM 인증을 강제함으로서, IAM 인증을 통해서만 연결할 수 있게하고, 자격증명은 AWS Secret Manager에 저장됨

`- RDS 프록시는 퍼블릭 엑세스가 절대불가하고, VPC 내에서만 엑세스 가능(보안이 훌륭)

- lambda 함수를 사용할 때, RDS 프록시를 사용하면, lambda 함수의 연결 풀을 생성하고 lambda 함수가 RDS 프록시를 오버로드하여, RDS DB 연결을 줄일 수 있음

 

 

ElastiCache

캐싱 기술인 Redis 또는 Memcached를 관리할 수 있도록 도와줌

 

- 캐시란 매우 높은 성능과 짧은 지연 시간을 가진 인메모리 DB

- 읽기 집약적인 워크로드에서 DB 로드를 줄여줌

- 일반적인 쿼리는 캐시에 저장되기 때문에 캐시만 사용하여 쿼리를 조회할 수 있음

- 애플리케이션 상태를 비저장형으로 할 수 있게 도와줌, 상태를 ElastiCache에 저장

- 관리형으로 패치, 최적화, 설정, 구성, 모니터링, 장애복구, 백업 등 가능

- 애플리케이션 코드를 많이 바꿔야함, DB를 쿼리하기 전/후에 캐시를 쿼리하도록 애플리케이션을 변경

 

 

아키텍처 예시

예시A : 애플리케이션은 ElastiCache에 먼저 쿼리함, 쿼리가 발생했는지 확인하고 이미 발생하여 캐싱되어있다면, 캐시 히트라고 함.(시간 절약) 캐시 미스 발생시 DB에서 데이터를 읽어와야하고, 쿼리가 반복되면 데이터를 캐시에 쓸 수 있음

캐시 무효화 전략이 있어야함, 가장 최신 데이터만 사용되어야하기 때문

 

예시B : 사용자 세션을 캐시에 저장하는 것, 애플리케이션을 상태 비저장으로 만들 수 있음

사용자가 로그인시 애플리케이션이 세션 데이터를 ElastiCache에 적음, 사용자가 다른 인스턴스로 리디렉션되면, 애플리케이션은 그 세션의 세션 캐시를 직접 검색할 수 있어서 로그인 상태가 유지됨

애플리케이션을 상태 비저장형으로 만들 수 있음

 

 

Redis vs Memcached

Redis : 다중 AZ, 읽기 복제본, AOF 지속성을 이용한 데이터 내구성, 백업/복원, 세트 및 정렬된 세트 지원

Redis는 복제되는 캐시라고 생각할 수 있음, 가용성과 내구성이 뛰어남

 

Memcached : 데이터 분할을 위해 멀티 노드 사용(=샤딩), 고가용성이 없고, 복제가 일어나지 않으며, 영구 캐시가 아님, 백업/복원 X, 멀티스레드 아키텍처, 여러 인스턴스가 모두 샤딩을 통해 동작

 

`Redis는 고가용성, 백업, 읽기 복제본 등을 위해 존재

`Memcached는 분산된 순수 캐시로, 데이터가 손실되어도 괜찮음, 고가용성 없음

 

 

ElastiCache 보안

- Redis에서만 IAM인증을 지원, 나머지 경우에 사용자 이름과 PW를 사용하면됨

- IAM 정책을 정의하면, AWS API 수준 보안에만 사용됨

- Redis AUTH라는 Redis 내 보안을 통해 PW와 토큰 설정 가능

  - Redis 클러스터를 만들 때, 추가 보안 수준 제공 가능 

  - SSL 전송 중 암호화 지원

- Memcached는 SASL 기반 인증 제공(고급) 

 

 

ElastiCache 데이터 load 패턴

1. Lazy 로딩

모든 데이터가 캐시되고, 데이터가 캐시에서 지체될 수 있음

- 애플리케이션에서 캐시 히트가 있는 경우, 캐시에서 데이터를 가져옴.. 캐시 미스의 경우 DB에서 읽고, 캐시에 쓰게됨(캐시 히트가 없을 때만 load 되는 방식)

 

2. Write Through

DB에 데이터가 기록될 때마다 캐시에 데이터를 추가하거나 업데이트하는 것.. 데이터가 지체되지 않음

 

3. Session Store

유지 시간 기능을 통해 만료 설정 가능

 

 

Redis 사용 사례

`실시간 리더보드 만들기

Redis에는 정렬된 세트(Sorted sets)가 있음, 고유성과 요소 순서를 모두 보장함.. 요소가 추가될 때마다, 실시간으로 순위를 매긴 다음 올바른 순서로 추가됨... ElastiCache에서 실시간으로 만들어주니, 애플리케이션 측에서 이 기능을 프로그래밍할 필요가 없음

 

 

친숙한 포트(Well-Known)

중요한 포트 : FTP : 21 / SSH : 22 / SFTP : 22 / HTTP : 80 / HTTPS : 443

RDS DB 포트 : PostgreSQL : 5432 / Mysql : 3306 / Oracle RDS : 1521 / MS Server : 1433 / MariaDB :3306

 - Aurora 포트 : PostgrSQL/MySQL을 따라감