[AWS-SAA] 06. RDS, Aurora & ElastiCache 요약

1강. Amazon RDS 개요 - 4강. RDS Custom

• Amazon RDS(Relational Database Service)란 AWS에서 제공하는 관리형 데이터베이스 서비스이다.
  • 지원 데이터베이스 엔진
    • 오픈소스 기반: PostgreSQL, MySQL, MariaDB
    • 상용 DBMS: Oracle, Microsoft SQL Server, IBM DB2
    • AWS 자체 DB: Aurora
• RDS 사용 이점
  • 자동화된 운영 관리: DB 프로비저닝, OS 패치
  • 자동 백업 & 특정 시점 복구(Point in Time Restore)
  • 모니터링 대시보드 제공
  • 읽기 성능 최적화: 최대 15개의 Read Replica 지원
  • 고가용성(HA) 및 DR 지원: Multi-AZ 구성 가능
  • 유지보수 윈도우 제공: 자동 업그레이드 적용 가능
  • 확장성 지원: Scale Up(인스턴스 타입 변경) 및 Scale Out(Read Replica 추가) 확장 가능
  • EBS 기반 스토리지 사용
• SSH로 직접 접근 불가능하다는 단점이 있다.
• RDS 스토리지 자동 확장 (Storage Auto Scaling) : RDS가 자동으로 스토리지 부족을 감지하고 확장함
  • 최대 스토리지 한도 설정 가능
  • 자동 확장 조건
    • 남은 스토리지가 10% 미만
    • 5분 이상 저용량 상태 지속
    • 최근 확장 이후 6시간 경과
  • 사용 예시) 예측할 수 없는 워크로드
• RDS Read Replicas (읽기 확장성)
  • 최대 15개의 Read Replica 지원
  • 배포 옵션은 크게 3가지로 구분할 수 있음
    • 단일 AZ
    • 다중 AZ(Cross AZ)
    • 다중 리전(Cross Region)
      • 비동기(Async) 복제 → 데이터 읽기는 Eventually Consistent
      • Read Replica를 독립적인 DB로 승격(Promotion) 가능
      • 사용자가 애플리케이션의 DB 연결(Connection String)을 변경해야 함
  • Read Replica 사용 사례
    • 분석용 쿼리(SELECT) 수행 시 사용 → 본 DB 부하 감소
    • 트래픽 증가 시 확장성 확보
    • BI(비즈니스 인텔리전스) 및 Reporting 애플리케이션 분리
  • 같은 AZ 내에서만 무료이므로 다른 AZ 간 트래픽 이동에 대한 네트워크 비용을 주의해야 한다.
• RDS Multi-AZ (고가용성 & 재해복구, DR)
  • 동기(SYNC) 복제 지원
  • 단일 DNS 엔드포인트 제공 → 자동 페일오버 지원
    • AZ, 네트워크, 인스턴스, 스토리지 장애 발생 시 자동 복구
    • 반면 Read Replica는 DNS 이름을 갖는 새로운 엔드 포인트를 추가해야 한다. 따라서 로드밸런싱을 위해 애플리케이션이 개별적으로 참조를 하게끔 변경해야 한다.
  • 애플리케이션에서 별도 수정 필요 없음
    • 확장(Scaling) 용도가 아니고 재해 복구용
  • Read Replica(확장 용도)를 Multi-AZ 설정하여 DR(재해복구) 가능
• RDS Single-AZ를 Multi-AZ로 무중단 전환 가능
  • 내부적으로 전환하는 방법
    1. 스냅샷 생성
    2. 새 AZ에 복원
    3. 기존 DB와 동기화(Sync Replication 설정)
• RDS Custom (DB & OS 커스터마이징)
  • Oracle 및 Microsoft SQL Server 지원
  • 기본 RDS와 차이점
  • RDS Custom을 사용하면 SSH 및 SSM(Session Manager)으로 EC2 인스턴스 직접 접근 가능
  • 자동화 모드를 비활성화해야 커스텀 작업 수행 가능 → 사전에 DB 스냅샷 백업 필수

• 요약
  • RDS는 AWS에서 관리하는 관계형 데이터베이스 서비스
  • EC2에서 직접 DB를 운영하는 것보다 자동 백업, 복구, 확장 등의 이점 제공
  • 스토리지 자동 확장(Storage Auto Scaling)으로 예기치 못한 용량 부족 방지
  • 읽기 부하 분산 시 Read Replica 사용, 장애 대비는 Multi-AZ 사용
  • 커스터마이징이 필요한 경우 RDS Custom 활용 가능
  • 적절한 RDS 기능을 활용하여 가용성, 성능, 비용을 최적화할 것!

 

5강. Amazon Aurora 개요 - 8강. Amazon Aurora 고급 개념

• Amazon Aurora : AWS의 독점 기술(AWS Proprietary DB), 오픈 소스 아님
  • MySQL 및 PostgreSQL과 호환됨 (DB 드라이버 그대로 사용 가능)
  • AWS 클라우드에 최적화
    • MySQL 대비 5배, PostgreSQL 대비 3배 성능 향상
  • 스토리지 자동 확장
    • 10GB 단위로 최대 128TB까지 자동 증가
  • 고가용성(HA) 및 빠른 복제
    • 최대 15개의 리드 레플리카 지원
    • 복제 지연(sub 10ms) 최소화
  • Aurora 비용
    • RDS보다 20% 더 비싸지만 성능이 우수함
• Aurora 고가용성(HA) 및 읽기 확장성
  • 3개의 가용 영역(AZ)에 6개의 데이터 복사본 유지
    • 쓰기(Write)에는 6개 중 4개 복사본 필요
    • 읽기(Read)에는 6개 중 3개 복사본 필요
    • 자동 복구(Self-Healing) 및 피어-투-피어 복제 지원
    • 스토리지가 수백 개의 볼륨으로 분산(Striped Storage)
  • 마스터(Master) 인스턴스가 쓰기를 담당하고, 최대 15개의 Aurora Read Replica가 읽기 요청 처리
  • 자동 장애 조치(Failover) 지원
    • 마스터 인스턴스 장애 시 30초 이내 자동 전환
  • Cross-Region Replication 지원
• Aurora DB 클러스터 개요
  • Aurora DB는 클러스터 기반 구조로 운영됨.
  • 하나의 클러스터에 여러 개의 노드(인스턴스) 포함
    • Writer EndPoint를 통해 접근하면 마스터 노드(쓰기 권한 보유)에 연결됨
    • Reader EndPoint를 통해 접근하면 여러 개의 레플리카 노드(읽기 권한 보유)에 연결됨
    • 마스터 노드(Master): 쓰기 요청 담당
    • 리드 레플리카(Replica): 읽기 요청 담당 → 최대 15개
    • 스토리지는 클러스터 내 모든 노드가 공유
    • 클러스터 내에서 자동으로 확장 및 장애 조치 가능
• Aurora 기능
  • 자동 장애 조치 (Failover) : 마스터 장애 시 자동 전환
  • 백업 및 복구 : Point-in-Time Restore 지원
  • 보안 및 격리 : VPC 내에서 네트워크 격리 가능
  • 규정 준수 : 다양한 컴플라이언스 준수 (SOC, PCI 등)
  • 자동 스케일링 : Aurora Replicas와 Serverless 지원
    • Aurora Read Replica는 자동 스케일링(Scale Out & Scale In)을 지원해 사용자가 직접 관리할 필요 없이 수요 변화에 따라 읽기 성능을 최적화
    • Aurora Serverless는 DB 인스턴스가 필요할 때만 자동 실행한 뒤 실행한 만큼 초 단위로 과금하는 방식.
      • 용량 계획 필요 없고, 사용량에 따라 자동 스케일링됨.
      • 예시) 불규칙한 워크로드에 적합
  • 무중단 패치 (Zero Downtime Patching) : 운영 중 패치 적용 가능
  • 고급 모니터링 : 성능 개선을 위한 상세 지표 제공
  • Backtrack 기능 : 백업 없이 특정 시점으로 데이터 롤백 가능
  • Aurora Custom Endpoints 기능 : Aurora의 특정 인스턴스 그룹을 별도의 엔드포인트로 정의 가능
    • 예시) 분석 쿼리는 특정 Read Replica(사이즈가 더 큰 인스턴스)에만 할당
    • Reader Endpoint 사용을 줄이고, 특정 워크로드에 맞는 엔드포인트 구성 가능
  • Aurora Global Database
    • DR(재해 복구) 목적
    • 1개의 Primary Region(Read/Write) + 최대 5개의 Secondary Region(Read-Only)
      • Aurora 글로벌 데이터베이스를 사용하면 최대 5개의 2차 리전까지 Aurora 복제본을 가질 수 있다. → AWS 리전 레벨 장애 대응 가능
      • 각 Secondary Region에서 최대 16개의 Read Replica 지원
        • 다른 리전을 Primary로 승격(Promotion) 가능 → DR 목적
          • 재해 발생 시 1분 이내 RTO 보장
          • 리전 간 복제 지연이 1초 미만
• Aurora Machine Learning : SQL을 사용해 머신러닝(ML) 기반 예측 기능 추가 할 수 있음
  • Amazon SageMaker 및 Amazon Comprehend와 통합 지원
  • 머신러닝 경험이 없어도 간단하게 적용 가능
  • 예시) 이상 탐지(Fraud Detection), 광고 타겟팅(Ads Targeting), 감정 분석(Sentiment Analysis), 제품 추천(Product Recommendation)
• 요약
  • Aurora는 AWS에서 제공하는 고성능, 고가용성의 관리형 데이터베이스 서비스
  • MySQL 및 PostgreSQL과 호환되지만, AWS 최적화로 성능이 크게 향상됨
  • 스토리지 자동 확장, 자동 장애 복구, Cross-Region Replication 등을 지원
  • Serverless 옵션과 Global Database를 활용하면 더욱 유연한 아키텍처 구성 가능
  • Aurora Machine Learning을 통해 AI 기반 분석 및 예측 기능을 쉽게 적용할 수 있음

 

9강. Aurora & RDS 백업과 모니터링 - 11강. RDS Proxy

• RDS 백업
  • 자동 백업(Auto Backups)
    • 매일 전체 DB에 대한 백업 수행 (백업 윈도우 동안)
    • 트랜잭션 로그는 5분마다 백업됨
    • 가장 오래된 백업부터 5분 전까지의 시점으로 복원 가능
    • 보존 기간: 1~35일 (0으로 설정 시 자동 백업 비활성화)
  • 수동 스냅샷(Manual DB Snapshots)
    • 사용자가 직접 트리거
    • 원하는 기간 동안 백업을 보관 가능
    • Tip: RDS 인스턴스를 중지해도 스토리지 비용이 발생하므로, 장기간 중지할 경우 스냅샷을 생성한 후 인스턴스를 삭제하는 것이 비용 절감에 유리함
• Aurora 백업
  • 자동 백업(Auto Backups)
    • 백업 비활성화 불가능
    • 보존 기간: 1~35일
    • 해당 기간 내 특정 시점(Point-in-Time) 복원 가능
  • 수동 스냅샷(Manual DB Snapshots)
    • 사용자가 직접 트리거
    • 원하는 기간 동안 백업을 보관 가능
• RDS 및 Aurora 복원 옵션
  • RDS 및 Aurora 복원
    • 백업 또는 스냅샷 복원 시 새로운 데이터베이스 인스턴스가 생성됨
  • MySQL RDS 복원 (Amazon S3 사용)
    • 온프레미스 데이터베이스를 백업하여 Amazon S3에 저장
    • S3에 저장된 백업 파일을 기반으로 새로운 RDS 인스턴스(MySQL 실행)로 복원 가능
  • MySQL Aurora 클러스터 복원 (Amazon S3 사용)
    • Percona XtraBackup을 이용해 온프레미스 데이터베이스 백업
    • 백업 파일을 Amazon S3에 저장
    • S3에서 새로운 Aurora 클러스터(MySQL 실행)로 복원 가능
• Aurora 데이터베이스 클로닝(DB 복제) : 기존 Aurora DB 클러스터를 기반으로 새로운 클러스터를 생성하는 기능
  • 스냅샷 및 복원 방식보다 빠름 (Copy-on-Write 프로토콜 사용)
    • 빠르고 비용 효율적인 방식으로 프로덕션 DB에서 스테이징(Staging) 환경을 구축할 때 유용
  • 초기에는 기존 클러스터와 동일한 스토리지 사용
    • 새로운 클러스터에서 변경이 발생하면 추가 스토리지가 할당되며 데이터가 복사됨
• RDS 및 Aurora 보안
  • 데이터 암호화
    • AWS KMS(Key Management Service) 사용하여 마스터 및 리드 복제본 암호화
    • 데이터베이스 생성 시 암호화 옵션 설정 필요
    • 마스터 DB가 암호화되지 않으면 리드 복제본도 암호화 불가능
    • 암호화되지 않은 DB를 암호화하려면 스냅샷 생성 후 암호화된 DB로 복원해야 함
  • 전송 중 암호화 (In-Transit Encryption)
    • TLS(Transport Layer Security) 기본 지원하고, AWS TLS 루트 인증서를 사용하여 클라이언트 측에서 보안 연결 가능
  • IAM 역할 접근을 활성화해 데이터베이스 접근 가능 (사용자명/비밀번호 대신)
• 네트워크 보안
  • 보안 그룹(Security Groups): RDS 및 Aurora 데이터베이스에 대한 네트워크 접근 제어
  • SSH 불가능 (RDS Custom는 예외)
  • 감사 로그(Audit Logs): CloudWatch Logs로 전송하여 장기 보관 가능
• Amazon RDS Proxy : 완전 관리형 데이터베이스 프록시 서비스로, DB 연결을 풀링(Pooling) 및 공유(Sharing)하여 성능 최적화
  • 데이터베이스 리소스 부하 감소 (CPU, RAM 사용량 최적화)
  • 연결 개수 최소화 → 타임아웃 감소
  • 고가용성 지원 (Multi-AZ)
  • RDS 및 Aurora 장애 조치(Failover) 시간 최대 66% 단축
  • 지원 데이터베이스 종류
    • RDS: MySQL, PostgreSQL, MariaDB, SQL Server
    • Aurora: MySQL, PostgreSQL
  • 대부분의 애플리케이션에서 코드 변경 없이 적용 가능
  • IAM 인증 강제 적용 가능
  • AWS Secrets Manager와 연동하여 보안 자격 증명 저장
  • 퍼블릭 액세스 불가 (VPC 내에서만 접근 가능)
• 요약
  • Amazon RDS 및 Aurora는 AWS에서 제공하는 강력한 관리형 데이터베이스 서비스
  • 자동 백업 및 특정 시점 복원을 지원하여 데이터 보호 강화
  • Aurora는 Copy-on-Write 클로닝을 지원하여 빠르고 효율적인 데이터베이스 복제 가능
  • 보안 기능 강화 (IAM 인증, TLS 암호화, KMS 기반 암호화 등)
  • RDS Proxy를 활용하여 성능 최적화 및 장애 조치 속도 개선
  • Aurora는 서버리스(Serverless) 및 글로벌 데이터베이스(Global Database) 지원으로 확장성이 뛰어남

 

12강. Elastic Cache 개요 - 15강. 친숙한 포트 목록

• Amazon ElastiCache : AWS에서 관리하는 Redis 및 Memcached 서비스이다.
  • RDS가 관리형 관계형 데이터베이스(RDB)를 제공하는 것처럼, ElastiCache는 관리형 인메모리 캐시 서비스를 제공
  • 인메모리 캐시는 매우 높은 성능과 낮은 지연시간을 제공하는 데이터베이스
  • 데이터베이스의 부하를 줄여 읽기 집중적인(READ-intensive) 워크로드 성능 개선
  • 애플리케이션을 무상태(Stateless) 로 설계하는 데 도움
  • AWS가 운영체제(OS) 유지보수, 패치, 최적화, 설정, 모니터링, 장애 복구 및 백업을 관리
  • ElastiCache를 활용하려면 애플리케이션 코드의 많은 변경이 필요할 수 있음
• ElastiCache 솔루션 아키텍처
  • 1. DB 캐시 패턴 (Database Cache) 
    • 동작 방식
      • 애플리케이션이 ElastiCache에 쿼리 요청
      • Cache Hit: 요청된 데이터가 캐시에 있으면 즉시 반환
      • Cache Miss: 데이터가 없으면 RDS에서 읽고, 해당 데이터를 ElastiCache에 저장
      • 이를 통해 RDS의 부하를 줄이고 응답 속도를 높임
    • 캐시 무효화(Invalidation) 전략 필요
      • 캐시에 오래된 데이터가 저장되지 않도록 최신 데이터를 유지해야 함
      • 잘못된 데이터가 제공되지 않도록 주기적으로 갱신 필요
  • 2. 사용자 세션 저장소 (User Session Store)
    • 사용자 로그인 시 ElastiCache에 세션 데이터 저장
      • 사용자가 애플리케이션에 로그인하면 세션 데이터를 ElastiCache에 기록
      • 동일한 사용자가 다른 애플리케이션 인스턴스를 사용할 경우 ElastiCache에서 세션을 조회하여 로그인 상태 유지
    • 장점
      • 세션 데이터를 빠르게 조회 가능하여 웹 애플리케이션의 성능 향상
      • 애플리케이션 인스턴스 간 세션 공유 가능

• ElastiCache 보안
  • Redis를 위한 IAM 인증 지원하지만, IAM 정책은 AWS API 수준에서만 보안 적용된다.
  • Redis AUTH
    • Redis 클러스터 생성 시 비밀번호/토큰 설정 가능
    • 보안 그룹(Security Groups) 외에 추가적인 보안 계층 제공
  • 데이터 전송 시 SSL/TLS 암호화 지원
  • Memcached을 위한 SASL 기반 인증을 지원한다. (고급 옵션)
• ElastiCache 캐싱 전략
  • Lazy Loading (지연 로딩)
    • 모든 읽기 데이터를 캐시에 저장
    • 캐시에 데이터가 없을 경우(캐시 미스), RDS에서 읽은 후 캐시에 저장
    • 단점: 캐시에 오래된 데이터가 남아 있을 수 있음 (Stale Data 문제 발생 가능)
  • Write Through (쓰기 반영)
    • DB에 쓰기 작업이 발생하면 동시에 캐시에도 반영
    • Stale Data 문제 없음
    • 단점: 불필요한 캐시 업데이트가 발생할 수 있음
  • Session Store (세션 저장소)
    • TTL(Time-To-Live) 기능을 활용하여 세션 데이터를 캐시에 저장
    • 세션이 만료되면 자동 삭제
• ElastiCache – Redis 활용 사례
  • 게임 리더보드 (Gaming Leaderboard)
    • Sorted Sets을 활용하여 실시간 랭킹 계산 가능
    • 중복 없는 정렬된 데이터 저장 가능
    • 새로운 점수가 추가될 때 실시간으로 순위를 반영하여 저장
• 요약
  • ElastiCache는 AWS에서 관리하는 Redis 및 Memcached 서비스로, 데이터베이스 부하를 줄이고 애플리케이션 성능을 향상
  • ElastiCache를 사용하면 세션 관리 및 캐싱을 통해 빠른 데이터 접근 가능
  • Redis는 고가용성(Auto-Failover), 데이터 지속성, 백업/복원 등을 지원하며, Memcached는 멀티스레드 및 샤딩에 강점
  • Lazy Loading, Write Through, Session Store 등 다양한 캐싱 전략 활용 가능
  • Elastic Cache는 게임 리더보드, 세션 관리, 실시간 데이터 처리 등에 적합