RDS, Aurora & ElastiCache

🧠 들어가기 앞서:

• RDS → 그냥 AWS가 관리해주는 일반적인 데이터베이스 (MySQL 같은 거)
• Aurora → 성능 엄청 빠른 RDS 고급버전
• ElastiCache → "진짜 빠른 메모리 데이터 저장소" (Redis, Memcached)
• Read Replica → "읽기 부하 분산용 복제본 만들기"
• Multi-AZ → "장애 대비용 복제본 만들기 (읽기는 못 함)"
• Serverless → "필요할 때만 자동으로 데이터베이스 켜고 끄기"

---

📚 RDS

🔷 Amazon RDS 개요

• RDS는 **Relational Database Service(관계형 데이터베이스 서비스)**의 약자이다.
• RDS는 SQL을 쿼리 언어로 사용하는 데이터베이스를 AWS가 관리형으로 제공하는 서비스이다.
• RDS를 통해 클라우드 환경에서 데이터베이스를 쉽게 생성하고 운영할 수 있다.
• RDS는 PostgreSQL, MySQL, MariaDB, Oracle, Microsoft SQL Server, IBM DB2, Aurora를 지원한다.

---

🔷 EC2에 직접 DB를 설치하는 대신 RDS를 사용할 때의 장점

• RDS는 완전 관리형 서비스이다.
• RDS는 자동 프로비저닝 및 운영 체제 패치를 제공한다.
• RDS는 지속적인 백업과 특정 시점 복구(Point in Time Restore)를 지원한다.
• RDS는 모니터링 대시보드를 제공한다.
• RDS는 읽기 성능 향상을 위한 리드 레플리카(Read Replica)를 제공한다.
• RDS는 재해 복구를 위한 Multi-AZ 구성을 지원한다.
• RDS는 업그레이드를 위한 유지 관리 창(Maintenance Window)을 제공한다.
• RDS는 수직 및 수평 확장(Scaling)을 지원한다.
• RDS는 EBS(Elastic Block Store) 기반 저장소를 사용한다.
• 단, RDS는 SSH를 통한 인스턴스 접속을 허용하지 않는다.

---

🔷 RDS 저장소 자동 확장(Storage Auto Scaling)

• RDS 저장소 자동 확장은 DB 인스턴스의 스토리지를 동적으로 증가시키는 기능이다.
• RDS는 남은 저장 공간이 10% 이하이고, 5분 이상 지속되며, 마지막 수정 이후 6시간이 경과한 경우 자동으로 스토리지를 확장한다.
• 사용자는 최대 저장소 임계값(Maximum Storage Threshold)을 사전에 설정해야 한다.
• 저장소 자동 확장은 모든 RDS 데이터베이스 엔진을 지원한다.
• 저장소 자동 확장은 예측 불가능한 워크로드를 가진 애플리케이션에 유용하다.

---

🔷 RDS Read Replica

• RDS Read Replica는 읽기 확장성을 높이기 위한 비동기 복제 기능이다.
• 하나의 소스 DB로부터 최대 15개의 리드 레플리카를 생성할 수 있다.
• 리드 레플리카는 같은 AZ, 다른 AZ, 또는 다른 리전에 생성할 수 있다.
• 복제는 **비동기 방식(ASYNC)**으로 이루어지므로 읽기는 결국 일관성(Eventual Consistency)을 가진다.
• 리드 레플리카는 필요할 경우 독립된 데이터베이스 인스턴스로 승격할 수 있다.
• 애플리케이션은 리드 레플리카를 활용하기 위해 연결 문자열(Connection String)을 별도로 설정해야 한다.

---

🔷 RDS Read Replica 활용 사례

• 프로덕션 데이터베이스가 정상적인 부하를 처리하는 동안 별도의 읽기 전용 워크로드(예: 리포트, 분석)를 처리하고자 할 때 사용한다.
• 리드 레플리카는 **SELECT 쿼리(읽기 전용)**에만 사용된다.
• 리포트 애플리케이션은 리드 레플리카를 통해 데이터를 읽는다.
• 프로덕션 애플리케이션은 본래의 DB에 대한 성능 저하 없이 정상 운영을 지속할 수 있다.

---

🔷 RDS Read Replica 네트워크 비용

• 리전 내 다른 AZ 간 리드 레플리카 복제는 네트워크 비용이 발생하지 않는다.
• 리전 간(Cross-Region) 리드 레플리카 복제는 추가 네트워크 비용이 발생한다.
• 같은 리전, 같은 AZ 또는 다른 AZ에서의 리드 레플리카는 복제 비용이 무료이다.

---

🔷 RDS Multi-AZ (다중 가용 영역 구성)

• RDS Multi-AZ는 장애 복구(Disaster Recovery)를 위한 동기 복제(SYNC Replication) 기능이다.
• 마스터 DB와 스탠바이 DB는 동기 복제되어 항상 데이터 일관성을 유지한다.
• 하나의 공통 DNS 이름을 사용하여 애플리케이션이 장애 발생 시에도 자동으로 스탠바이 인스턴스로 페일오버(Failover)된다.
• Multi-AZ는 가용성을 높이고, AZ, 네트워크, 인스턴스, 스토리지 장애 시 자동 복구를 지원한다.
• Multi-AZ는 확장(Scaling) 목적으로는 사용되지 않는다.
• 참고로, 리드 레플리카 또한 Multi-AZ 구성을 통해 DR(Disaster Recovery)을 강화할 수 있다.

---

🔷 RDS Single-AZ를 Multi-AZ로 변경

• Single-AZ에서 Multi-AZ로 전환은 제로 다운타임(Zero Downtime)으로 진행된다.
• 데이터베이스 수정(Modify)을 클릭하면, 다음 절차가 자동으로 수행된다:
  • 스냅샷이 생성된다.
  • 새로운 AZ에 데이터베이스가 복원된다.
  • 두 데이터베이스 간 동기화(Synchronization)가 설정된다.

---

🔷 RDS Custom

• RDS Custom은 OS와 데이터베이스 커스터마이징이 가능한 관리형 Oracle 및 Microsoft SQL Server 데이터베이스 서비스이다.
• RDS Custom은 AWS가 기본적인 데이터베이스 설치, 운영, 확장 작업을 자동화한다.
• 사용자는 기본 OS 및 데이터베이스에 직접 접근하여 설정을 조정하거나 패치를 설치하거나 네이티브 기능을 활성화할 수 있다.
• SSH 또는 SSM(Session Manager)을 통해 하위 EC2 인스턴스에 접근할 수 있다.
• 자동화 모드를 비활성화(De-activate)한 뒤, 커스터마이징을 진행하는 것이 권장되며, 작업 전에 DB 스냅샷을 생성하는 것이 좋다.
• RDS는 AWS가 데이터베이스와 OS를 완전히 관리하는 서비스이다.
• RDS Custom은 사용자에게 데이터베이스와 OS에 대한 전체 관리자 권한을 제공하는 서비스이다.

---

🧾 최종 요약

• RDS는 관리형 관계형 데이터베이스 서비스이다.
• RDS Read Replica는 읽기 부하를 분산하기 위한 비동기 복제 기능이다.
• RDS Multi-AZ는 고가용성과 장애 복구를 위한 동기 복제 구성이다.
• RDS Custom은 사용자가 데이터베이스와 운영 체제를 커스터마이징할 수 있는 특별한 버전이다.

---

📚 Amazon Aurora

🔷 Aurora 기본 개요

• Aurora는 AWS의 독자 기술로 오픈 소스가 아니다.
• Aurora는 PostgreSQL과 MySQL을 지원하여 기존 드라이버와 호환된다.
• Aurora는 AWS 클라우드에 최적화되어 있으며, MySQL 대비 5배, PostgreSQL 대비 3배 이상의 성능 향상을 제공한다고 주장한다.
• Aurora는 스토리지가 10GB 단위로 자동 확장되며 최대 128TB까지 확장 가능하다.
• Aurora는 최대 15개의 리드 레플리카를 지원하며, 복제 지연이 10밀리초 미만으로 매우 빠르다.

---

🔷 RDS 및 Aurora 백업

• RDS는 매일 전체 백업과 5분마다 트랜잭션 로그 백업을 수행한다.
• RDS 백업은 1~35일간 보존 가능하며, 특정 시점 복구(Point-in-Time Recovery)를 지원한다.
• 수동 스냅샷은 사용자가 직접 생성하며 무기한 보존할 수 있다.
• 데이터베이스를 정지하더라도 스토리지 비용이 계속 발생하므로 장기 정지 시 스냅샷 후 삭제가 권장된다.

---

🔷 Aurora 백업

• Aurora는 1~35일간 자동 백업을 제공하며 비활성화할 수 없다.
• Aurora는 수동 스냅샷도 지원하며 사용자가 필요에 따라 생성할 수 있다.

---

🔷 RDS & Aurora 복원 옵션

• RDS나 Aurora에서 백업이나 스냅샷 복원 시 항상 새로운 데이터베이스 인스턴스가 생성된다.
• 온프레미스 MySQL 백업은 S3에 저장한 후 새로운 RDS 인스턴스로 복원할 수 있다.
• Percona XtraBackup을 사용하여 Aurora MySQL 클러스터를 S3 백업에서 복원할 수 있다.

---

🔷 Aurora 데이터베이스 복제 (Cloning)

• Aurora는 기존 DB 클러스터를 복제하여 새 클러스터를 생성할 수 있다.
• 복제는 스냅샷과 복원보다 빠르며 Copy-on-Write 기술을 사용한다.
• 복제 초기에는 원본 데이터 볼륨을 공유하며, 변경이 발생할 때만 별도 스토리지가 할당된다.
• Aurora 복제는 프로덕션 DB로부터 스테이징 DB를 빠르게 만들 때 유용하다.

---

🔷 RDS & Aurora 보안

• 저장 데이터 암호화는 AWS KMS를 통해 마스터 및 리드 레플리카 모두 암호화할 수 있다.
• 암호화는 인스턴스 생성 시 설정해야 하며 이후 변경할 수 없다.
• 미암호화된 데이터베이스를 암호화하려면 스냅샷 후 암호화 복원 작업이 필요하다.
• 전송 중 데이터는 기본적으로 TLS 암호화가 적용된다.
• IAM 인증을 통해 사용자 이름/비밀번호 대신 IAM 역할을 이용해 DB에 연결할 수 있다.
• 보안 그룹을 사용하여 네트워크 접근을 제어할 수 있다.
• RDS Custom을 제외하고는 SSH 접속이 불가능하다.
• 감사 로그는 CloudWatch Logs로 전송하여 장기 보존할 수 있다.

---

🔷 Amazon RDS Proxy

• RDS Proxy는 RDS를 위한 완전 관리형 데이터베이스 프록시 서비스이다.
• RDS Proxy는 애플리케이션이 데이터베이스 연결을 풀링하고 공유할 수 있도록 지원하여 리소스 소비를 줄인다.
• RDS Proxy는 서버리스이며 자동 확장 및 다중 AZ 고가용성을 지원한다.
• RDS Proxy는 RDS 및 Aurora (MySQL, PostgreSQL 엔진) 모두를 지원하며 대부분의 앱은 코드 변경 없이 사용할 수 있다.
• RDS Proxy는 IAM 인증과 AWS Secrets Manager를 통한 비밀번호 관리를 지원한다.
• RDS Proxy는 퍼블릭 접근을 허용하지 않으며 반드시 VPC 내에서 접근해야 한다.
• RDS Proxy를 사용하면 RDS 및 Aurora 페일오버 시간을 최대 66%까지 단축할 수 있다.

---

🔷 Aurora 고가용성과 읽기 확장

• Aurora는 3개의 가용 영역(AZ)에 걸쳐 6개의 데이터 복제본을 유지한다.
• 쓰기 작업에는 6개 중 4개 복제본의 동의를 필요로 하며, 읽기 작업에는 3개 복제본이 필요하다.
• Aurora는 피어 투 피어 복제(peer-to-peer replication)로 셀프 힐링(self-healing)을 지원한다.
• 스토리지는 수백 개의 볼륨에 스트라이프 방식으로 분산 저장되며, 10GB 단위로 최대 128TB까지 확장된다.
• 하나의 마스터 인스턴스가 쓰기 작업을 담당하며, 최대 15개의 리드 레플리카가 읽기 작업을 담당한다.
• 마스터 장애 발생 시 30초 이내 자동 페일오버가 이루어진다.
• Aurora는 **Cross-Region Replication(리전 간 복제)**를 지원한다.

---

🔷 Aurora 주요 기능

• Aurora는 자동 페일오버, 백업 및 복구, 격리 및 보안, 산업 규정 준수, 버튼 클릭 확장, 무중단 패치, 고급 모니터링, 주기적 유지보수를 제공한다.
• Aurora는 Backtrack 기능을 제공하여 백업 없이도 특정 시점으로 복원할 수 있다.

---

🔷 Aurora 리드 레플리카 자동 확장

• Aurora는 CPU 사용량에 따라 리드 레플리카 수를 자동으로 확장하거나 축소할 수 있다.
• 클라이언트 요청이 증가하면 자동으로 읽기 엔드포인트가 확장된다.

---

🔷 Aurora 커스텀 엔드포인트

• Aurora는 특정 리플리카들을 묶어 커스텀 엔드포인트를 정의할 수 있다.
• 커스텀 엔드포인트를 통해 분석 쿼리 같은 특정 워크로드를 특정 인스턴스로 분리하여 처리할 수 있다.
• 커스텀 엔드포인트를 사용하면 리더 엔드포인트 사용이 줄어든다.

---

🔷 Aurora Serverless

• Aurora Serverless는 애플리케이션 사용량에 따라 자동으로 데이터베이스를 시작하고 종료하며 용량을 조정한다.
• Aurora Serverless는 빈번하지 않거나 간헐적이거나 예측이 어려운 워크로드에 적합하다.
• Aurora Serverless는 초 단위 과금이 적용되어 비용 효율적일 수 있다.

---

🔷 Aurora 글로벌 데이터베이스 (Global Database)

• Aurora 글로벌 데이터베이스는 1개의 기본 리전과 최대 5개의 보조 리전(읽기 전용)으로 구성된다.
• 글로벌 복제는 1초 미만의 지연으로 동작한다.
• 보조 리전마다 최대 16개의 리드 레플리카를 둘 수 있다.
• 재해 복구(Disaster Recovery) 시 1분 이내에 보조 리전을 승격할 수 있다.
• 글로벌 데이터베이스는 지연을 줄이고 지역 장애에 대비할 수 있게 한다.

---

🔷 Aurora와 머신러닝 통합

• Aurora는 SQL을 통해 머신러닝 기반 예측을 애플리케이션에 통합할 수 있게 한다.
• 통합 가능한 서비스는 Amazon SageMaker와 Amazon Comprehend이다.
• 머신러닝 경험 없이도 사기 탐지, 광고 타겟팅, 감성 분석, 제품 추천 등의 기능을 구현할 수 있다.

---

🧾 최종 요약

• Aurora는 AWS가 제공하는 고성능, 고가용성, 자동 확장형 관계형 데이터베이스 서비스이다.
• Aurora는 백업, 복구, 복제, 서버리스, 글로벌 확장, 머신러닝 통합 등 다양한 고급 기능을 기본으로 제공한다.
• Aurora는 RDS보다 20% 정도 비용이 더 높지만, 훨씬 더 높은 효율성과 기능성을 제공한다.

---

📚 Amazon ElastiCache

🔷 Amazon ElastiCache 기본 개요

• ElastiCache는 RDS가 관리형 관계형 데이터베이스를 제공하는 것처럼, 관리형 Redis 또는 Memcached를 제공하는 서비스이다
  .

  📚 Redis와 Memcached 쉽게 이해하기

  1. 공통점부터

  • 둘 다 **"메모리 기반 저장소"**이다.
  • 디스크가 아니라 **RAM(메모리)**에 저장하니까 엄청 빠르다.
  • 둘 다 **데이터를 임시로 저장하는 캐시(Cache)**로 많이 쓴다.

  ✅ 핵심 공통점:
  "느린 데이터베이스까지 가지 말고, 메모리에 저장해두자!"

  ---

  2. Redis는 뭐냐?

  • **"슈퍼 파워 캐시 저장소"**라고 생각하면 된다.
  • 그냥 키(Key)-값(Value) 저장 뿐만 아니라,
    • 리스트(List)
    • 셋(Set)
    • 정렬된 셋(Sorted Set)
    • 해시(Hash) 같은 복잡한 데이터 구조까지 저장할 수 있다.
  • 백업할 수도 있고, **복제(리드 레플리카)**도 가능하다.
  • 고가용성(Auto Failover) 기능도 있다.

  🖼️ Redis 그림

  css

  복사편집

  [키: user123] → [값: {"이름": "홍길동", "나이": 25}] [키: board_rank] → [값: 정렬된 점수 목록]

  ✅ Redis = "빠른 속도 + 복잡한 데이터 구조 + 고급 기능"

  ---

  3. Memcached는 뭐냐?

  • **"진짜 단순한 캐시"**다.
  • 오직 Key-Value 형태만 저장한다.
  • 복잡한 데이터 구조 없음.
  • 백업 기능도 거의 없음(휘발성).
  • 멀티스레드 구조라 CPU를 잘 활용할 수 있다.

  🖼️ Memcached 그림

  css

  복사편집

  [키: page_home] → [값: '홈페이지 HTML 소스 코드'] [키: product_1234] → [값: 상품 정보]

  ✅ Memcached = "빠른 속도 + 단순한 데이터 저장 + 가벼운 구조"

  ---

  4. 둘을 비교하면

  항목RedisMemcached

  데이터 구조	리스트, 셋, 정렬셋 등 복잡한 구조 지원	단순 Key-Value 저장만
  복제/고가용성	지원	지원 안 함
  데이터 백업	지원 (AOF, RDB 방식)	거의 없음 (휘발성)
  CPU 사용	싱글 스레드	멀티 스레드
  사용 목적	복잡한 데이터 캐시 + 세션 저장 + 리더보드 등	간단한 캐시(페이지, 간단한 값 저장)

  ---

  🧩 예시로 이해하기

  ✅ Redis 쓰는 경우

  "게임 앱에서 사용자 점수 리더보드를 빠르게 보여줘야 해.
  점수 순위를 정렬하고 실시간으로 업데이트해야 한다."
  → Redis의 Sorted Set 기능이 필요하다.

  ---

  ✅ Memcached 쓰는 경우

  "뉴스 사이트에서 오늘자 기사 리스트를 빠르게 불러오고 싶어.
  그냥 페이지 통째로 캐시하면 된다."
  → Memcached로 간단히 Key-Value로 저장하면 된다.

  ---

  🧾 정리

  • Redis는 복잡한 데이터 처리가 가능한 강력한 캐시 저장소이다.
  • Memcached는 단순하고 빠른 캐시에 딱 맞는 초간단 저장소이다.

  둘 다 빠르고, 역할이 살짝 다르다!

• ElastiCache는 메모리 기반의 초고속, 초저지연 성능을 제공하는 캐시 서비스이다.
• ElastiCache는 읽기 집중적 워크로드에서 데이터베이스 부하를 줄이는 데 도움이 된다.
• ElastiCache는 애플리케이션을 무상태(Stateless)로 만드는 데 기여한다.
• ElastiCache는 운영 체제 유지보수, 패치, 최적화, 설정, 모니터링, 장애 복구, 백업을 AWS가 관리한다.
• ElastiCache 사용 시 애플리케이션 코드에 상당한 변경이 필요할 수 있다.

---

🔷 ElastiCache 솔루션 아키텍처 – 데이터베이스 캐시(DB Cache)

• 애플리케이션은 먼저 ElastiCache를 조회하고(Cache Hit), 데이터가 없으면(Cache Miss) RDS에서 읽고 ElastiCache에 저장한다.
• ElastiCache를 사용하면 RDS 데이터베이스에 가해지는 부하를 줄일 수 있다.
• 캐시는 무조건 최신 데이터를 반영해야 하므로 적절한 캐시 무효화 전략(Invalidation Strategy)이 필요하다.

---

🔷 ElastiCache 솔루션 아키텍처 – 사용자 세션 저장소(User Session Store)

• 사용자가 애플리케이션에 로그인하면 애플리케이션이 세션 데이터를 ElastiCache에 저장한다.
• 사용자가 다른 인스턴스의 애플리케이션을 이용해도 ElastiCache에서 세션을 조회하여 로그인 상태를 유지할 수 있다.
• 이 방식은 애플리케이션을 무상태로 운영하는 데 매우 유용하다.

---

🔷 ElastiCache – Redis와 Memcached 비교

항목	Redis	Memcached
고가용성	멀티 AZ, 자동 장애 조치(Auto-Failover) 지원	지원하지 않음
읽기 확장성	리드 레플리카(Read Replica) 지원	기본적으로 없음
데이터 영속성	AOF(Append-Only File) 기반 영속성 지원	비영속성(메모리 기반)
백업 및 복구	지원	지원 (서버리스 방식)
아키텍처	싱글 쓰레드 기반	멀티 쓰레드 기반
데이터 구조 지원	세트(Set), 정렬 세트(Sorted Set) 지원	간단한 키-값 저장소

• Redis는 복제와 장애 복구에 강하며, 복잡한 데이터 구조를 지원한다.
• Memcached는 간단하고 가벼우며, 대규모 샤딩에 적합하다.

---

🔷 ElastiCache – 보안(Security)

• Redis는 IAM 인증을 지원하며, 주로 AWS API 수준 접근 제어에 사용된다.
• Redis 클러스터 생성 시 **Redis AUTH(패스워드/토큰 기반 인증)**를 설정할 수 있다.
• Redis는 SSL을 통한 인플라이트(전송 중) 암호화를 지원한다.
• Memcached는 SASL 기반 고급 인증을 지원한다.
• ElastiCache는 보안 그룹(Security Group)을 통한 네트워크 접근 제어를 필수로 설정해야 한다.

---

🔷 ElastiCache 패턴

• Lazy Loading: 데이터가 요청될 때만 캐시에 저장하는 방식으로, 캐시 데이터가 오래되거나 부정확해질 수 있다.
• Write Through: DB에 데이터를 쓸 때마다 캐시에 동시에 업데이트하는 방식으로, 캐시 불일치를 방지할 수 있다.
• Session Store: 사용자 세션 데이터를 TTL(수명 주기) 기능을 활용하여 임시로 캐시에 저장하는 방식이다.
• 컴퓨터 과학의 격언: "캐시 무효화(Cache Invalidation)와 명명 규칙은 가장 어려운 문제다."

---

🔷 ElastiCache Redis 사용 사례

• 게임 리더보드는 복잡한 계산이 필요한 워크로드로, Redis의 **정렬된 집합(Sorted Set)**을 사용하면 데이터의 고유성과 순서를 동시에 보장할 수 있다.
• 새로운 요소가 추가될 때마다 실시간으로 순위가 계산되고 저장된다.
• Redis를 통해 다수의 클라이언트가 빠르고 정확한 리더보드 결과를 실시간으로 조회할 수 있다.

---

🧾 최종 요약

• ElastiCache는 초고속 인메모리 데이터베이스로 Redis와 Memcached를 관리형으로 제공한다.
• ElastiCache는 DB 부하 감소, 세션 관리, 애플리케이션 무상태화에 크게 기여한다.
• Redis는 고급 기능과 복제 지원, Memcached는 가벼운 구조와 대규모 샤딩에 적합하다.
• 적절한 캐시 패턴과 보안 설정이 필수적이며, 특정 워크로드에 최적화된 캐시 전략을 수립해야 한다.