06. RDS + Aurora + ElastiCache

1장. Amazon RDS 개요

01) Amazon RDS 란?
(1) RDS: 관계형 데이터베이스 서비스(Relational Database Service)의 약자.
(2) SQL을 쿼리 언어로 사용하는 데이터베이스용 관리형 데이터베이스 서비스.
(3) AWS에서 관리되는 클라우드 상의 데이터베이스를 생성할 수 있도록 해줌.
- Postgres
- MySQL
- MariaDB
- Oracle
- Microsoft SQL Server
- Aurora (AWS Proprietary database)

02) EC2에 DB를 구축하지 않고, RDS를 사용하는 이유
- RDS는 관리형 서비스이며, AWS는 데이터베이스 뿐만 아니라 다양한 서비스를 제공함.

• 프로비저닝, 기본 운영체제 패치 자동화
• 지속적인 백업과 특정 타임스탬프로의 복원 (특정 시점 복원)
• 모니터링 대시보드
• 읽기 성능 향상을 위한 읽기 전용 복제본
• 재해 복구를 위한 다중 AZ 설정
• 유지 관리 기간에 업그레이드 가능
• 수직 및 수평 스케일링 기능
• EBS(gp2 또는 io1)로 지원되는 스토리지

- 한 가지 단점은, RDS 인스턴스에 SSH로 접속할 수 없음.

03) RDS – Storage Auto Scaling

• RDS DB 인스턴스의 스토리지를 동적으로 늘릴 수 있도록 지원합니다.
• 데이터베이스 스토리지가 부족해지고, RDS 스토리지 Auto Scaling 기능이 활성화되어 있으면 RDS가 이를 감지하여 자동으로 스토리지를 확장해 줌.
• 데이터베이스 스토리지를 수동으로 스케일링하는 작업을 피할 수 있음.
• 최대 스토리지 임계값(스토리지의 최대 제한)을 설정해야 함.

- 다음의 경우에 자동으로 스토리지를 수정함.

• 스토리지의 남은 공간이 10% 미만인 경우
• 스토리지 부족 상태가 5분 이상 지속
• 마지막 수정 이후 6시간이 지난 경우

- 워크로드(부하)를 예측할 수 없는 애플리케이션에서 유용함.
- 모든 RDS 데이터베이스 엔진 (MariaDB, MySQL, PostgreSQL, SQL Server, Oracle)을 지원.

---

2장. RDS 읽기 전용 복제본과 다중 AZ

01) 읽기 확장성을 위한 RDS 읽기 복제본

• 읽기 전용 복제본을 최대 15개까지 생성 가능. (mysql은 5개)
• 동일한 가용 영역 또는 가용 영역이나 리전을 걸쳐 생성 가능.
• 복제는 비동기 방식으로 진행됨. 즉, 읽기가 일관적으로 유지됨.
• 복제본은 자체 데이터베이스로 승격될 수 있음.
• 읽기 전용 복제본을 사용하려는 경우에는 주요 애플리케이션은 모든 연결을 업데이트 해야하며 이를 통해 RDS 클러스터 상의 읽기 전용 복제본 전체 목록을 활용할 수 있음.

02) 사용 예시

• 정상적인 작업 부하를 처리하는 프로덕션 데이터베이스가 있다고 가정.
• 데이터를 기반으로 몇 가지 보고와 분석을 실시하고자 함.
• 새로운 작업 부하를 처리하기 위해 읽기 전용 복제본을 생성.
• 읽기 전용 복제본은 SELECT(=읽기) 명령문에만 사용. (INSERT, UPDATE, DELETE는 제외)

03) RDS 읽기 전용 복제본의 네트워킹 비용

• AWS에서는 데이터가 한 AZ에서 다른 AZ로 이동할 때 네트워크 비용이 발생한다.
• 하지만, 동일한 리전 내에서의 RDS 읽기 전용 복제본에 대해서는 해당 비용을 지불하지 않는다.

04) RDS 다중 AZ (재해 복구)

• 동기식 복제
• 하나의 DNS 이름 - 대기에 대한 자동 앱 failover
• 가용성 향상
• AZ 손실, 네트워크 손실, 인스턴스 또는 스토리지 장애 발생 시 페일오버 - 스탠바이 데이터베이스가 새로운 마스터가 될 수 있도록 함.
• 애플리케이션에 수동으로 조치를 취할 필요가 없음.
• 스케일링에는 사용되지 않음.
  참고: 읽기 전용 복제본은 재해 복구(DR)을 위해 다중 AZ로 설정될 수 있음.

05) 단일 AZ 에서 다중 AZ으로 옮기기

- 다운타임이 없는 운영 (DB를 중지할 필요 없음)
- 데이터베이스에 대해 "수정"을 클릭하고 활성화시키기만 하면 됨.
- 내부적으로는 다음이 수행됨.

• 기본 데이터베이스의 RDS가 자동으로 스냅샷 생성
• 이 스냅샷에서 새로운 DB가 새로운 가용 영역에 복원됨
• 두 개의 데이터베이스 간에 동기화가 설정

06) RDS Custom (AWS - SAA)
- Oracle & Microsoft SQL Server DatabaseOS: RDS Custom 덕분에 데이터베이스 사용자 지정 기능에 액세스할 수 있음
- RDS: AWS에서의 데이터베이스 설정, 운영 및 확장을 자동화
- Custom: 기저 데이터베이스와 운영 체제에 액세스할 수 있음

• 내부 설정 구성 (Configure setting)
• 패치 설치
• 네이티브 기능 활성화
• SSH 또는 SSM 세션 관리자를 통해 RDS 뒤에 있는 기저 EC2 인스턴스에 액세스 가능

- 사용자 지정 설정을 사용하려면 RDS가 수시로 자동화, 유지 관리 또는 스케일링과 같은 작업을 수행하지 않도록 자동화를 꺼두는 것이 좋음
- 기저 EC2 인스턴스에 액세스가 가능하므로 문제가 쉽게 발생할 수 있기 때문에 데이터베이스 스냅샷을 만들어두는 것이 권장됨.
- RDS vs RDS Custom

• RDS: AWS가 데이터베이스 및 OS 전체를 관리
• RDS Custom: Oracle과 Microsoft SQL Server에서만 사용 가능, 기저 운영 체제와 데이터베이스에 대한 관리자 권한 전체를 가짐.

---

3장. Aurora
01) Amazon Aurora 란?

• Aurora는 AWS 고유 기술로 오픈 소스는 아님.
• Postgres와 MySQL이 호환됨.
• Aurora는 "AWS 클라우드 최적화"되었으며, RDS의 MySQL에 비해 5배 높은 성능이고, RDS의 Postgres에 비해 3배 높은 성능.
• Aurora 스토리지는 자동으로 10GB 단위로 증가하며, 최대 128TB까지 확장할 수 있음.
• Aurora는 최대 15개의 복제본을 가질 수 있으며, 복제 과정은 MySQL보다 빠름 (10ms 미만의 복제 지연).
• 페일오버(Failover)는 즉시 이루어지고 가용성이 높음.
• 비용은 RDS에 비해 약 20% 정도 높지만 스케일링 측면에서 훨씬 효율적임.

02) Aurora 고가용성 및 읽기 확장

- 3개의 가용영역에 걸쳐 6개의 데이터 복사본을 저장. (파란색)
- 쓰기 작업을 위해서는 6개의 사본 중 4개만 있으면 됨. (즉, AZ 하나가 작동하지 않아도 괜찮음.)
- 읽기 작업을 위해서는 6개의 사본 중 3개만 있으면 됨. (즉, 읽기 가용성이 높음.)

• 백엔드에서 P2P(peer-to-peer) 복제를 통한 자가 복구 진행.
• 단일 볼륨에 의존하지 않고 수 백 개의 볼륨 사용함.

- 하나의 Aurora 인스턴스가 쓰기 작업을 수행함. (master)
- 스터의 자동 장애 조치(failover)는 30초 이내에 이루어짐.
- 마스터 외에 읽기를 제공하는 읽기 전용 복제본을 15개까지 둘 수 있음.
- Cross Region 복제 지원
마스터는 하나, 복제본은 여러 개, 스토리지 복제, 작은 블록 단위로 자가 복구 또는 확장이 일어남.

03) Aurora DB 클러스터 (작동 방식)

• writer endpoint
• reader endpoint
• 자동 스케일링, 자동 확장되는 공유 스토리지 볼륨
• 로드 밸런싱이 statement level이 아니라 connection level에서 일어난다는 사실을 기억하기!

04) Aurora의 기능들

• 자동 장애 조치(failover)
• 백업 및 복구
• 격리 및 보안
• 산업 규정 준수
• 버튼 한 번으로 확장 가능 (push-button scaling)
• 제로 다운타임 자동 패치 설치
• 고급 모니터링
• 정기적인 유지 보수
• Backtrack(백트랙): 백업을 사용하지 않고 언제든 데이터 복원 가능

---

4장) RDS 및 Aurora 보안

01) RDS 및 Aurora 보안
(1) At-rest encryption

• AWS KMS를 사용하여 데이터베이스 마스터 및 복제본 암호화 - 이는 데이터베이스를 처음 실행할 때 정의됨.
• 마스터가 암호화되지 않은 경우 읽기 복제본을 암호화할 수 없음.
• 암호화되지 않은 기존 데이터베이스를 암호화하려면 DB 스냅샷을 통해 암호화된 DB 형태로 데이터베이스 스냅샷을 복원해야 함.

(2) In-flight encryption: 기본적으로 TLS 사용 가능. 클라이언트는 AWS TLS 루트 인증서 사용해야 함.
(3) IAM 인증:사용자 이름/암호 대신 IAM Role을 사용하여 DB에 연결 가능.
(4) 보안 그룹:RDS/AUrora DB에 대한 네트워크 액세스 제어
(5) SSH 액세스 불가능 (RDS Custom 제외)
(6) 감사 로그 활성화 - CloudWatch Logs로 전송하여 장기간 보관 가능.

---

5장. Amazon RDS 프록시

1 ) Amazon RDS 프록시

• RDS에 대한 완벽하게 관리되는 데이터베이스 프록시
• 애플리케이션이 데이터베이스 내에서 데이터베이스 연결 풀을 형성하고 공유할 수 있음. (애플리케이션을 RDS DB 인스턴스에 일일이 연결하는 대신 프록시에 연결하면 프록시가 하나의 풀에 연결을 모아서 RDS DB 인스턴스로 연결함)
• 데이터베이스 리소스에 가해지는 부하를 줄이고 (ex. CPU, RAM), 데이터베이스에 개방된 연결과 타임아웃을 최소화하여 데이터베이스의 효율성을 향상
• RDS 프록시는 완전한 서버리스로 오토 스케일링이 가능해 용량을 관리할 필요가 없고 가용성이 높음. 다중 AZ도 지원.
• RDS**와 Aurora의 장애 조치 시간을 66%까지 줄일 수 있음**
• RDS (MySQL, PostgreSQL, MariaDB, MS SQL Server) 및 Aurora (MySQL, PostgreSQL)를 지원
• 애플리케이션의 코드를 변경하지 않아도 됨
• DB**에 대한 IAM 인증을 강제함으로써 IAM 인증을 통해서만 RDS DB 인스턴스에 연결할 수 있음. 이때 자격 증명은 AWS Secrets Manager에 안전하게 저장됨.**
• RDS 프록시는 퍼블릭 액세스가 절대 불가능함. (VPC에서만 접근 가능)

---

6장. ElastiCache

01 ) Amazon ElastiCache 란?

• RDS와 동일한 방식으로 관계형 데이터베이스를 관리할 수 있음.
• ElastiCache는 Redis 또는 Memcached와 같은 캐시 기술을 관리할 수 있도록 함.
• Cache: 매우 높은 성능과 낮은 지연 시간을 가진 인메모리 데이터베이스.
• 읽기 집약적인 워크로드에서 데이터베이스의 부하를 줄이는데 도움.
• 애플리케이션을 stateless로 만드는데 도움이 됨.
• AWS는 OS 유지 관리/패치, 최적화, 설정, 구성, 모니터링, 장애 복구 및 백업을 처리.
• ElastiCache를 사용하는 것은 애플리케이션 코드 변경이 많이 필요

02) ElastiCache 솔루션 아키텍처
(1) DB Cache

• 애플리케이션은 ElastiCache에 쿼리를 보내고, ElastiCache에 데이터가 없는 경우 RDS에서 가져와 ElastiCache에 저장.
• RDS의 부하를 완화하는 데 도움.
• 캐시는 가장 최신 데이터만 사용되도록 만료 전략(invalidation strategy)을 가져야 함.

(2) User Session Store

• 사용자가 애플리케이션 중 하나에 로그인하면 애플리케이션은 세션 데이터를 ElastiCache에 기록한다.
• 사용자가 이후 애플리케이션의 다른 인스턴스로 리디렉션 되면 애플리케이션은 ElastiCache에서 직접 세션 캐시를 검색하고 사용자는 계속 로그인한 상태로 한번 더 로그인할 필요가 없음.

03) Redis vs Memcached
(1) Redis

• 자동 장애 조치(Auto-Failover)를 위한 Multi AZ
• 읽기 스케일링에 사용되며 가용성이 높은 읽기 전용 복제본
• AOF 지속성을 통한 데이터 내구성
• 백업 및 복원 기능
• 세트(Sets)와 정렬 세트(Sorted Sets)를 지원함

(2) Memcached

• 데이터 파티셔닝(sharding)을 위한 다중 노드 사용
• 가용성이 높지 않고 복제도 발생하지 않음
• 지속적인 캐시가 아님
• 백업 및 복원 기능이 없음
• 멀티스레드 아키텍처

---

7장. 캐싱 전략과 고려 사항

01 ) 캐싱 전략시 고려해야 할 사항들
(1) 데이터를 캐싱하는 것은 안전한가?

• 데이터가 최신 정보가 아닐 수 있으나, 최종적으로는 일관성을 유지한다.

(2) 캐싱이 데이터에 효과적인가?

• 패턴: 데이터 변경이 느리고 필요한 키가 적은 경우
• 안티 패턴: 데이터가 빠르게 바뀌고 데이터셋의 모든 키가 필요한 경우

(3) 데이터의 구조가 캐싱에 적합한가?

• 예시: 키-값 캐싱 또는 집계 결과의 캐싱

=> 그렇다면 어떤 캐싱 설계 패턴이 가장 적합할까?

02) Lazy Loading / Cache-Aside / Lazy Population
(1) 장점

• 요청된 데이터만 캐시됨 (요청되지 않은 데이터는 캐시되지 않음)
• 노드 실패가 발생해도 치명적이지 않음 (캐시를 워밍하기 위한 대기 시간이 증가할 뿐)

(2) 단점

• 캐시 미스일 경우 3번의 네트워크 호출이 이뤄지며, 해당 요청에 대한 지연이 발생할 수 있음
• 오래된 데이터: 데이터는 데이터베이스에서 업데이트 되었지만 캐시에서는 오래된 상태일 수 있음

(3) Lazy Loading / Cache-Aside / Lazy Population Python Pseudocode

 

04) Write Through – Add or Update cache when database is updated

(1) 장점

• 캐시된 데이터는 절대로 오래된 상태가 아니며, 읽기가 빠르다
• 쓰기 패널티 vs 읽기 패널티

(2) 단점

• 데이터가 데이터베이스에 추가/업데이트 되기 전까지는 데이터가 없다. 이를 완화하기 위해 Lazy Loading 전략을 결합하여 구현할 수 있다.
• 캐시 이탈률(churn): 많은 데이터를 추가할 경우 많은 데이터가 읽히지 않을 수 있다.

(4) Write-Through Python Pseudocode

 

5) Cache Evictions and Time-to-live (TTL)
(1) 캐시 제거는 세 가지 방식으로 발생할 수 있다.

• 캐시에서 명시적으로 항목을 삭제한다.
• 메모리가 가득 찼을 때 가장 최근에 사용되지 않은 항목이 제거된다. (LRU, Least Recently Used)
• 타임 투 리브 (TTL)로 설정한다.

(2) TTL은 다양한 종류의 데이터에 유용하다.

• 리더보드
• 댓글
• 활동 스트림

(3) TTL은 몇 초부터 몇 시간 또는 며칠까지 다양하다.

• 메모리가 항상 꽉 차서 너무 많은 제거가 발생하는 경우, 스케일 업 또는 스케일 아웃을 해야 한다.

6) 마지막 용어 정리

• Lazy Loading / Cache aside는 구현하기 쉽고 다양한 상황에서 기본으로 사용되며, 특히 읽기 측면에서 작동한다.
• Write-through는 일반적으로 Lazy Loading과 결합되어 이 최적화를 적용하는 쿼리나 워크로드를 대상으로 한다.
• TTL(Time-to-live) 설정은 일반적으로 좋은 아이디어다. Write-through를 사용하지 않을 때를 제외하고는 응용 프로그램에 적합한 값을 설정해야 한다.
• 필요한 데이터에만 캐싱을 적용해야 한다. (사용자 프로필, 블로그 등)

---

8장. Amazon MemoryDB를 위한 Redis

01 ) Amazon MemoryDB의 레디스

• Redis와 호환되고, 내구성이 뛰어난 인메모리 데이터베이스 서비스
• 초당 1억 6천만 건 이상의 초고속 성능
• 다중 AZ 트랜잭션 로그를 사용한 내구성 있는 인메모리 데이터 스토리지
• 10GB에서 100TB까지의 스토리지로 원활하게 확장 가능
• 사용 사례: 웹 및 모바일 앱, 온라인 게임, 미디어 스트리밍 등

02) 중요한 포트

• FTP: 21
• SSH: 22
• SFTP: 22 (SSH와 같음)
• HTTP: 80
• HTTPS: 443

03) RDS 데이터베이스 포트

• PostgreSQL: 5432
• MySQL: 3306
• Oracle RDS: 1521
• MSSQL Server: 1433
• MariaDB: 3306 (MySQL과 같음)
• Aurora: 5432 (PostgreSQL와 호환될 경우) 또는 3306 (MySQL과 호환될 경우)