Rds OVerview
- managed db service for db use sql as a query language
RDS vs EC2에 DB 배포
여러 편리한 기능을 제공한다
- automated provisioning, os patching
- continous backups and restore to specific timestamp
- monitoring dashboard
- read replicas for imporved read performance
- multi az setup for DR(Disaster REcovery)
- maintenance windows for upgrades(업그레이드용 유지보수 시간 설정 가능)
- scaling capability
- EBS 기반 스토리지로 안정적 저장
- 단점: 인스턴스에 직접 SSH 접속 불가
RDS - Storage Auto Scaling
- 자동으로 스토리지 확장: RDS 인스턴스의 스토리지를 동적으로 확장해 줌.
- 저장 용량 감지 후 자동 확장: 필요에 따라 스토리지를 자동으로 감지하고 조정.
- 최대 스토리지 한도 설정 가능: 사용자가 설정한 최대 한도까지 자동으로 스토리지 크기 증가.
- 저장 공간 부족 시 자동 수정: 여유 공간이 부족할 경우 자동으로 저장 용량을 확장해 성능 유지.
RDS Read Replicas for read scalability
- Up to 15 Read Replicas Within AZ, Cross AZ or
- Replication is ASYNC, so reads are eventually consistent
- Replicas can be promoted to their own DB
Cross Region
- Applications must update the connection string to leverage read replicas

RDS Read Replicas - Network Cost

RDS Multi AZ(Disaster Recovery)
- RDS Multi-AZ 구성은 높은 가용성을 제공하여 장애 상황에서도 애플리케이션의 지속적인 운영을 보장하는 재해 복구(Disaster Recovery) 옵션
주요 특징
- 단일 DNS 이름 제공: 애플리케이션은 단일 DNS 이름을 사용하며, 자동으로 대기 인스턴스(standby)로 장애 조치(failover)가 이루어집니다.
- 가용성 증가: Multi-AZ 설정을 통해 가용성을 높이고, 계획되지 않은 장애 상황에도 서비스가 유지됩니다.
- 자동 장애 조치: 가용 영역(AZ) 상실, 네트워크 오류, 인스턴스 실패, 스토리지 장애 발생 시 자동으로 대기 인스턴스로 전환하여 복구됩니다.
- 애플리케이션 수정 불필요: 장애 조치가 자동으로 이루어지므로, 애플리케이션 레벨에서의 수동 조치가 필요하지 않습니다.
- 확장성 목적 아님: Multi-AZ는 오로지 재해 복구와 가용성 증가에만 사용되며, 읽기 복제본과 달리 성능 확장을 위한 용도로는 사용되지 않습니다.

RDS - From Single-AZ to Multi-AZ
RDS - Single-AZ에서 Multi-AZ로 전환
RDS 인스턴스를 Single-AZ(단일 가용 영역)에서 Multi-AZ(다중 가용 영역)으로 전환할 수 있으며, 이는 서비스 중단 없이 수행됩니다. 이를 통해, 기존에 단일 AZ로 배포된 RDS를 다중 AZ로 확장해 재해 복구와 가용성을 강화할 수 있습니다.
전환 과정
1. 서비스 중단 없음: DB 인스턴스를 중지하지 않고 전환이 이루어지므로 사용자에게 영향을 미치지 않습니다.
2. 간단한 설정 변경: 콘솔에서 “Modify” 옵션을 클릭하여 간단하게 Multi-AZ 설정을 추가할 수 있습니다.
3. 내부 처리 과정:
- 스냅샷 생성: 현재 DB 인스턴스의 스냅샷을 자동으로 생성합니다.
- 새 AZ에 복원: 스냅샷을 바탕으로 새 가용 영역(AZ)에 새로운 DB 인스턴스를 복원하여 대기 인스턴스로 구성합니다.
- 동기화 설정: 두 DB 인스턴스 간의 동기화를 설정하여 데이터가 실시간으로 동일하게 유지되도록 합니다.

RDS Custom
RDS vs. RDS Custom
• RDS: entire database and the OS to be managed by AWS
• RDS Custom: full admin access to the underlying OS and the database
Amazon Aurora
- AWS Cloud Optimized -> 5x performance improvement over mysql on RDS
storage automatically grows in increments of 10GB up to 128 TB
- Aurora can have 15 replicas while MySQL has 5, and the replication process is faster
- HA native
- costs more than RDS(20% more)
High Availability and Read Scaling
- 6 copies of your data across 3AZ:
- 4 copies of 6 for write
- 3 copies of 6 for reads
- self healing with replication
- storage is striped across 100s of volumes

Aurora DB Cluster
- Master에만 write가능
- 장애를 방지하기 위해 Writer Endpoint가 있어 . 그위에 다가 쓴다
- 어디서 읽어야할지 모를 수도 있으므로 Reader Endpoint도 있다. 알아서 로드밸런싱을 해준다

Features of Aurora
• Automatic fail-over
• Backup and Recovery
• Isolation and security
• Industry compliance
• Push-button scaling
• Automated Patching with Zero Downtime
• Advanced Monitoring
• Routine Maintenance
• Backtrack: restore data at any point of time without using backups
Aurora Replicas - Auto Scaling

Aurora - Custom Endpoints
- Define a subset of Aurora Instances as a Custom Endpoint
- Custom Endpoints를 사용하는 이유는 특정 Aurora 인스턴스에 대해 맞춤형 트래픽 분배를 가능하게 하여, 각 인스턴스의 역할을 세분화하고 효율적으로 운영하기 위함
1. 특정 작업에 맞춤화된 인스턴스 활용:
- 예를 들어, 분석 쿼리와 같은 고성능 요구 작업을 특정 리더 인스턴스(복제본)에만 할당할 수 있습니다. 이렇게 하면 분석 작업이 전체 클러스터에 영향을 주지 않고도 수행될 수 있습니다.
- 트랜잭션 처리와 같은 주요 애플리케이션 작업은 다른 인스턴스에서 원활하게 진행할 수 있습니다.
• Example: Run analytical queries on specific replicas
• The Reader Endpoint is generally not used after defining Custom Endpoints

Aurora Serverless
- Aurora Serverless는 자동으로 데이터베이스를 생성하고, 사용량에 따라 자동으로 확장/축소하는 기능을 갖춘 서버리스(DB 인스턴스가 없는) 데이터베이스
- Automated database instantiation and auto- scaling based on actual usage
- No capacity planning needed
- Pay per second, can be more cost-effective
- 개발 및 테스트 용도로 자주 사용하지 않거나, 사용량이 일정하지 않은 데이터베이스 환경에서 비용을 절감

Global Aurora
- Aurora Cross Region Read Replicas
- Aurora Global Database
- up to 5 secondary regions, replication lag is less than 1 second
- Promoting another region (for disaster recovery) has an RTO of < 1 minute
- 평균적으로 Aurora 글로벌 데이터베이스에서 한 리전에서 다른 리전으로 데이터를 복제하는 데에는 1초 이하의 시간이 걸립니다.
- 기계학습과 연동
Enables you to add ML-based predictions to your applications via SQL
- Amazon SageMaker
- Amazon Comprehend
Use cases: fraud detection, ads targeting, sentiment analysis, product recommendations
RDS Backups
- Automated backups:
- Daily full backup of the database
- Transaction logs are backed up by RDS every 5minutes
- 1 to 35 days of retention
- Manual DB Snapshots
- Manually triggered by user
- Retention as long as you want
Aurora Backups
Automated backups
• 1 to 35 days (cannot be disabled)
• point-in-time recovery in that timeframe
Manual DB Snapshots
• Manually triggered by the user
• Retention of backup for as long as you want
- RDS 또는 Aurora 백업 복구:
- RDS나 Aurora의 백업이나 스냅샷을 복구할 때, 복구가 기존 데이터베이스를 덮어쓰지 않고, 새로운 데이터베이스 인스턴스를 생성합니다. 즉, 기존 데이터베이스는 그대로 유지되고, 새 인스턴스로 복구됩니다.
- S3에서 RDS로 MySQL 데이터베이스 복구:
- 온프레미스 (자체 서버에 있는) MySQL 데이터베이스를 RDS로 복구하려는 경우:
- 먼저 온프레미스 데이터베이스 백업 파일을 생성합니다.
- 이 파일을 Amazon S3에 저장합니다.
- S3에 저장된 백업 파일을 사용해 새로운 RDS 인스턴스 (MySQL)를 생성하며, 이 과정에서 백업 파일을 RDS로 복구할 수 있습니다.
- S3에서 Aurora로 MySQL 클러스터 복구:
- Aurora를 사용하는 경우 MySQL 백업을 복구하려면:
- 온프레미스 데이터베이스의 백업을 Percona XtraBackup을 사용해 생성합니다. 이 도구는 MySQL 데이터베이스를 백업할 때 유용하며, 데이터 일관성을 보장해 줍니다.
- 생성된 백업 파일을 Amazon S3에 저장합니다.
- S3에 저장된 백업 파일을 사용해 새로운 Aurora 클러스터 (MySQL)를 생성하며, 복구를 진행할 수 있습니다.
Aurora Database Cloning
목적: 기존 Aurora DB 클러스터에서 새 클러스터를 빠르게 생성.
속도: 스냅샷 및 복원보다 훨씬 빠름.
프로토콜: Copy-on-write 방식 사용으로 효율성 극대화.
저장소 처리: 새로운 클러스터는 초기에는 기존 클러스터와 동일한 데이터 볼륨을 사용하며, 새로운 클러스터에 업데이트가 이루어질 때에만 별도의 저장소가 할당되고 데이터가 복사됨.
장점: 매우 빠르고 비용 효율적이며, 프로덕션 데이터베이스에 영향을 주지 않고 “프로덕션” 데이터베이스에서 “스테이징” 데이터베이스를 생성하는 데 유용함.
RDS 및 Aurora 보안
- 데이터 암호화(저장 시):
- AWS KMS를 사용하여 마스터와 복제본을 암호화하며, 초기 설정 시 적용 필요.
- 주의사항: 마스터가 암호화되지 않은 경우, 복제본도 암호화할 수 없음.
- 기존 암호화되지 않은 데이터베이스를 암호화하려면 스냅샷 및 복원을 통해 암호화를 적용.
- 데이터 암호화(전송 시): 기본적으로 TLS가 준비되어 있으며, AWS TLS 루트 인증서를 클라이언트측 사용
- IAM 인증: 전통적인 사용자 이름과 비밀번호 대신 IAM 역할을 통해 데이터베이스에 연결 가능.
- 보안 그룹: RDS/Aurora 데이터베이스에 대한 네트워크 접근을 제어.
- SSH: SSH 접속 불가 (RDS Custom을 제외).
- 감사 로그: 활성화하여 CloudWatch Logs로 전송하면 장기 보관 가능.
Amazon RDS 프록시
- 목적: RDS/Aurora에 대한 관리형 데이터베이스 프록시로, 연결 관리 개선.
- 기능:
- 데이터베이스 연결을 풀링 및 공유하여 리소스(CPU, RAM)에 대한 부담 감소.
- 열려있는 연결을 최소화하고 타임아웃 방지.
- 특징:
- 서버리스, 자동 확장, 다중 가용 영역(Multi-AZ) 지원.
- 장애조치(failover) 시간을 최대 66%까지 단축.
- 지원 데이터베이스: RDS(MySQL, PostgreSQL, MariaDB, MS SQL Server) 및 Aurora(MySQL, PostgreSQL).
- 보안:
- IAM 인증을 강제 적용.
- AWS Secrets Manager에 자격 증명을 안전하게 저장.
- 접근성: 공개적으로 접근할 수 없으며, VPC 내에서만 접근 가능.
- 통합성: 대부분의 애플리케이션에서 코드 변경 없이 사용 가능.
ElastiCache
- ElastiCache is to get managed Redis or Memcached
- Caches are in-memory databases with really high performance, low latency
- Helps reduce load off of databases for read intensive workloads
- 어떻게?
- 일반적인 쿼는 캐시에 저장된다
- 직접적인 디비 조회없이 캐시만 사용하여 쿼리할 수 있따
- Using ElastiCache involves heavy application code changes
- 캐시를 쿼리하도로고 애플리케이션을 변경해야한다

Example: User Session Store
- user logs into any of the application
- application wrties the session data into elastiCache
- use hits another instance of our application
- The instance retrieves the data and the user is already logged in


ElastiCache – Cache Security
1. IAM 인증 지원 (Redis):
- Redis는 IAM 인증을 지원합니다. 그러나 IAM 정책은 AWS API 보안 용도로만 사용되며, 실제 Redis 클러스터에 접근하는 세션 자체의 보안을 위한 것은 아닙니다.
- Redis AUTH (비밀번호/토큰 설정):
- Redis 클러스터를 생성할 때 비밀번호나 토큰을 설정할 수 있습니다. 이는 보안 그룹 외에도 추가적인 보안 계층을 제공하여, Redis 캐시에 접근할 때 인증을 요구하게 합니다.
- 전송 중 SSL 암호화:
- Redis는 SSL 암호화를 통해, 데이터를 전송하는 동안 제3자가 데이터를 볼 수 없도록 보호합니다.
- Memcached 보안:
- Memcached는 SASL 기반 인증을 지원하며, 이는 고급 인증 방법으로 사용됩니다. 그러나 Redis와는 달리 복잡한 보안 설정이 많지 않습니다.

Patterns for ElastiCache
- Lazy Loading (지연 로딩):
- 읽기 데이터가 캐시에 저장되며, 캐시가 데이터베이스(DB)로부터 데이터를 읽어 올 때 저장됩니다.
- 한 번 캐시에 저장된 데이터가 업데이트되지 않으면 오래된 데이터가 캐시에 남을 수 있습니다
- Write Through (쓰기 반영):
- 데이터가 DB에 저장되거나 업데이트될 때 캐시에도 동시에 반영됩니다.
- 덕분에 오래된 데이터가 남지 않으며 항상 최신 데이터가 캐시에 유지됩니다.
- Session Store (세션 저장소):
- 사용자 세션이나 일시적인 데이터를 캐시에 저장할 때 사용합니다. TTL(유효 시간)을 설정해 일정 시간이 지나면 데이터를 자동으로 삭제할 수 있습니다.
ElastiCache – Redis Use Case
• Redis Sorted sets guarantee both uniqueness and element ordering
• Each time a new element added, it’s ranked in real time, then added in correct order
문제
- 암호화되지 않은 RDS DB인스턴스를 암호화하는 방법
- 암호화되지 않은 RDS DB 인스턴스의 스냅샷을 생성, 스냅샷을 복사해 암호화 활성화하기 박스를 체크한뒤, RDS DB인스턴스를 암호화되지 않은 스냅샷에서 복구
- RDS 데이터베이스를 위해 최대 15개이의 읽기 전용 복제본을 가질 수 있다
- Aurora DB 클러스터도 15개의 Aurora 읽기 전용 복제본을 가질 수 있다