상세 컨텐츠

본문 제목

AWS - RDS, Aurora, ElastiCache

클라우드

by myeongjaechoi 2025. 10. 18. 17:31

본문

RDS(Relational Database Service)

  • 관리형 데이터베이스 서비스
  • SQL을 쿼리 언어로 사용하는 데이터베이스를 위한 서비스
    • PostgreSQL
    • MySQL
    • MariaDB
    • Oracle
    • Microsoft SQL Server
    • IBM DB2
    • Aurora(AWS 독점 데이터베이스)
  • AWS에서 관리됨

RDS와 EC2 인스턴스에 직접 DB 배포 차이점

  • RDS는 DB 제공 외에 다양한 서비스 제공
  • 데이터베이스 프로비저닝 및 기본 운영체제 패치 자동화
  • 지속적으로 백업이 이루어짐(특정 시점으로 복원 가능) = Point in Time Restore
  • 데이터베이스 성능을 모니터링할 수 있는 대시보드 사용 가능
  • 가용성 높이고, 재해 복구에 유용한 Multi-AZ 구성
  • 인스턴스 타입을 늘려 수직 수평 확장 가능
  • SSH 인스턴스 접속 불가

RDS - Storage Auto Scaling

  • RDS Database 생성할 때 필요한 스토리지 용량을 지정해야 함
  • 스토리지 용량을 늘리기 위해 데이터베이스 중단 필요X
  • 업무량이 예측하기 어려운 애플리케이션에 매우 유용

RDS 읽기 전용 복제본(RDS Read Replicas for read scalability)

  • 최대 15개 까지 읽기 전용 복제본 생성 가능
  • 동일 AZ, 다른 AZ, 다른 Region 가능(AZ간 이동은 무료, Region은 비용 발생)
  • Main RDS 데이터베이스 인스턴스와 복제본 사이에 비동기식 복제
  • 데이터베이스로 승격 가능. But, 생명주기를 가짐

RDS 읽기 전용 복제본 - 사용 사례

  • Select SQL 키워드만 사용(수정, 삭제, 생성 X)

RDS Multi AZ

  • 재해 복구용으로만 사용
  • 동기식
  • 애플리케이션 -통신-> DNS 이름
    • 마스터 데이터베이스에 문제가 발생시 스탠바이 데이터베이스에 자동으로 장애 조치 수행
    • -> 스탠바이 데이터베이스가 마스터 데이터베이스로 승격
    • 스케일링 X
    • 읽기, 쓰기 X
  • 단일 AZ에서 멀티 AZ로 변경할 때 다운타임 0 -> 데이터베이스 중지X

RDS 생성

Amazon Aurora

  • AWS 고유의 기술
  • Postgres 및 MySQL과 호환
  • RDS의 MySQL보다 5배 높은 성능
  • RDS의 PostgreSQL 보다 3배 높은 성능
  • 스토리지 자동 확장 가능(많은 데이터가 쌓이면 자동으로 10GB -> 128TB)
  • 장애 조치 즉각적
  • 비용 RDS에 비해 20% 높음
  • 복제, 자가복구 가능
  • Global Aurora
    • 요새 추천 방식
    • 읽기, 쓰기 하나의 기본 리전, 최대 5개의 보조 읽기 전용 리전 생성 -> 응답 지연 1초 이하
    • 보조 Region 당 최대 16개의 읽기 전용 복제본 사용 가능
    • 재해 복구를 위해 다른 Region을 승격시키는데, 복구시키는 시간이 1분 이내
    • 평균적으로 한 Region에서 다른 Region으로 복제하는데 1초 이하
  • Aurora Machine Learning
    • 기계 학습 모델 
    • SageMaker : 백엔드인 어떤 종류의 기계 학습 모델이라도 사용할 수 있게 허용
    • Comprehend : 감정 분석을 할 때 사용
    • 사용 사례 : 광고 타겟팅, 감정 분석, 상품 추천, 이상 행위 탐지 등

 

 

Amazon Aurora process

RDS Backups

  • 자동 백업
    • RDS 서비스가 자동으로 매일 DB 전체 백업을 수행
    • 5분마다 트랜잭션 로그가 백업됨
    • -> 가장 빠른 백업은 5분 전 백업으로, 언제든 5분 전으로 복원 가능
    • 자동 백업 보존 기간 1~35일 사이로 설정 가능 or 0으로 설정하여 백업 사용X
  • 수동 DB 스냅샷
    • 장점 : 백업 원하는 기간 동안 유지 가능
  • 백업 사용 예시
    • 데이터 백업하고 싶을 때
    • 비용 절감하고 싶을 때
      • 예시로, RDS DB를 한 달에 2시간만 사용
      • -> DB 중지해도 스토리지 비용은 계속 지불해야 함
      • -> 두 시간 사용 후 스냅샷을 만든 다음, 원본 DB 삭제하면 됨(스냅샷은 RDS 데이터베이스의 실제 스토리지 비용보다 훨씬 저렴)
      • -> 데이터베이스를 다시 사용할 거면, 스냅샷을 복원하여 사용

Aurora Backup

  • 자동 백업
    • 1 - 35일 까지 가능(비활성화 X)
    • 시점 복구 기능(어느 시점이든 복구 가능)
  • 수동 DB 스냅샷
    • RDS와 비숫

RDS & Aurora 복원

  • RDS / Aurora 백업 또는 스냅샷을 복원할 때마다 새 DB가 생성됨
  • Restoring MySQL RDS DB from S3
    • 온프레미스 DB의 백업을 생성한 다음 객체 스토리지인 S3에 배치
    • S3에서 MySQL을 실행하는 새 인스턴스로 백업 파일을 복원
  • Restoring MySQL Aurora cluster from S3
    • Perconda XtraBackup 소프트웨어를 사용하여 온프레미스 DB 백업

RDS Proxy

완전 관리형 데이터베이스 프록시 서비스

개념

  • VPC 내에 RDS DB를 배포할 수 있음
  • RDS Proxy 역시 완전 관리형으로 VPC 내 배포 가능
  • 애플리케이션이 DB 인스턴스에 직접 연결하는 대신 프록시를 통해 연결

동작 원리

  • RDS Proxy는 데이터베이스 연결 풀(Connection Pool) 생성 및 공유
  • 여러 애플리케이션 연결을 모아 DB 인스턴스로 가는 연결 수 감소
  • DB 리소스(CPU, RAM) 사용 효율 향상
  • 연결 개방/시간초과 최소화

장점

  1. 서버리스(Serverless)
    • 오토 스케일링 지원
    • 용량 관리 불필요
  2. 고가용성(High Availability)
    • Multi-AZ 지원
    • 장애 조치(Failover) 시간 최대 66% 감소
    • 장애 조치 시 프록시가 자동으로 대기 인스턴스에 연결
  3. 보안(Security)
    • IAM 인증 강제 가능
    • 자격 증명은 AWS Secrets Manager에 저장
    • 퍼블릭 액세스 불가, VPC 내에서만 접근 가능
  4. 호환성(Compatibility)
    • RDS(MySQL, PostgreSQL, MariaDB) 지원
    • Aurora(MySQL, PostgreSQL) 지원
    • 애플리케이션 코드 수정 불필요 — 연결 대상만 프록시로 변경

Lambda와 RDS Proxy

  • Lambda 함수는 대량의 짧은-lived 인스턴스를 빠르게 생성/삭제
  • 직접 DB에 연결 시, 수많은 개방 연결과 시간초과 발생 가능
  • RDS Proxy 사용 시
    • Lambda가 Proxy의 연결 풀을 공유
    • DB 연결 수 감소 → 성능 향상 및 안정성 확보

요약

  • RDS Proxy = RDS/Aurora의 연결 수 최소화
  • 장애 조치 시간 최대 66% 단축
  • IAM 인증 강제 및 Secrets Manager 저장
  • Lambda 대규모 연결 문제 해결

Amazon ElastiCache

관리형 인메모리 데이터베이스 서비스

개념

  • RDS가 관리형 관계형 데이터베이스를 제공하듯,
    ElastiCache는 관리형 Redis / Memcached 제공
  • 캐시(Cache) = 인메모리 기반 초고속 데이터베이스
  • 읽기 집중형(READ-heavy) 작업 부하에서 DB 부하 감소

캐시의 역할

  • 자주 수행되는 쿼리 결과를 메모리에 저장
  • 이후 동일한 요청 시 DB 쿼리 생략 → 지연 시간 단축, 부하 감소
  • ElastiCache는 상태 정보 저장소로도 사용 가능 → 무상태(Stateless) 애플리케이션 구현 가능

관리형 서비스 이점

  • AWS가 담당: OS 유지 관리, 패치, 구성, 모니터링, 장애 복구, 백업 등
  • RDS와 동일한 관리형 장점 제공

ElastiCache 사용 아키텍처

1️⃣ 캐시 조회 중심 구조

  • 구성: Application ↔ ElastiCache ↔ RDS
  • 동작:
    1. 앱이 ElastiCache에서 쿼리 결과 존재 여부 확인
    2. 존재 시 → 캐시 히트(Cache Hit) → RDS 접근 생략
    3. 없을 시 → 캐시 미스(Cache Miss) → RDS에서 데이터 조회 후 ElastiCache에 저장
  • 효과: RDS 부하 감소, 응답 시간 단축
  • 주의: 캐시 무효화 전략(Cache Invalidation) 필요 (최신 데이터 유지용)

2️⃣ 세션 관리 구조

  • 사용자 세션을 ElastiCache에 저장
  • 앱 인스턴스 간 세션 공유 가능 → 무상태 애플리케이션 구현
  • 사용자는 다른 인스턴스로 리디렉션되어도 로그인 유지

Redis vs Memcached

항목                                  Redis                                                                                Memcached
가용성 다중 AZ 지원, 자동 장애 조치 고가용성 X
복제(Replication) 지원 (읽기 복제본 생성 가능) 없음
데이터 내구성 AOF 지속성 제공 없음 (서버리스 버전 예외)
백업/복원 지원 일부 서버리스 버전만 지원
데이터 구조 문자열, 집합, 정렬된 집합 등 (리더보드 구현 유용) Key-Value 기반 단순 구조
확장 방식 복제 기반 (노드 간 데이터 복제) 차팅(Sharding) 기반 (데이터 분할 저장)
성능 구조 단일 스레드 멀티 스레드

정리

  • ElastiCache = 관리형 Redis/Memcached 인메모리 캐시
  • 장점: 고속 응답, DB 부하 감소, 무상태 앱 구성 가능
  • Redis: 고가용성·복제·백업·다양한 데이터 구조 지원
  • Memcached: 단순 Key-Value 캐시, 빠르지만 복제/백업 기능 부족

ElastiCache 사용

Amazon ElastiCache 보안 & 캐싱 전략

ElastiCache 인증 방식

항목                                                      Redis                                                                                       Memcached
IAM 인증 지원 (Redis 전용) 미지원
기본 인증 Redis AUTH (비밀번호/토큰 설정) SASL 기반 인증
전송 중 암호화(SSL) 지원 일부 지원
보안 그룹 VPC 내에서 보안 그룹으로 보호 동일
  • Redis AUTH : Redis 클러스터 생성 시 설정 가능
    → 캐시에 추가 보안 계층 제공
  • IAM 정책 : AWS API 수준 보안에만 사용됨
  • SSL 암호화 : 전송 중 데이터 보호 가능
  • Memcached : SASL 기반 인증 메커니즘 제공 (이름만 알아두면 됨)

🔐 요약

EC2 인스턴스 → Redis AUTH / IAM 인증 / 보안 그룹 / SSL 암호화
로 안전하게 Redis 클러스터 접근 가능

캐시 로딩 전략 (3가지)

전략                                        설명                                                        장점                          단점
1️⃣ Lazy Loading (지연 로딩) 캐시 히트 없을 때만 DB 조회 후 캐시에 저장 단순, 효율적 초기 요청 시 지연 발생, 오래된 데이터 가능성
2️⃣ Write Through DB에 데이터 기록 시 동시에 캐시에 저장 항상 최신 데이터 유지 쓰기 부하 증가
3️⃣ Session Store 세션 데이터를 캐시에 저장, TTL로 자동 만료 무상태 앱 구현 가능 TTL 관리 필요

Lazy Loading 동작 방식

1️⃣ Cache Hit → ElastiCache에서 직접 데이터 반환
2️⃣ Cache Miss → RDS(DB)에서 데이터 조회 후 캐시에 저장
→ 다음 요청 시 캐시 히트 발생

Redis 실전 사용 사례 – 실시간 리더보드

  • Redis Sorted Set (정렬된 세트)
    • 고유성 + 정렬된 순서 모두 보장
    • 점수(score) 기준으로 실시간 순위 매김
    • 새로운 요소 추가 시 자동 정렬
  • 사용 예시:
    • 게임 리더보드 (1위, 2위, 3위 등 실시간 갱신)
    • 실시간 점수판, 순위 기반 랭킹 시스템
  • 장점:
    • 모든 클라이언트가 동일한 리더보드 접근
    • 애플리케이션 측에서 별도 구현 불필요
    • Redis 내부 구조로 즉시 순위 제공

정리

  • Redis 보안: IAM 인증, AUTH 비밀번호, SSL 전송 암호화
  • Memcached 보안: SASL 인증 (IAM X, 단순 구조)
  • 캐시 전략: Lazy Loading / Write Through / Session Store
  • Redis Sorted Set: 실시간 리더보드 구현 핵심

'클라우드' 카테고리의 다른 글

AWS - 세 개의 아키텍처 예시 및 Beanstalk  (0) 2025.10.21
AWS - DNS, Route 53  (0) 2025.10.19
AWS - Load Balancer  (0) 2025.10.17
AWS - EBS, AMI, EFS  (0) 2025.10.15
AWS - 탄력적 IP, 배치 그룹, Hibernate,  (1) 2025.10.14

관련글 더보기

티스토리툴바