7. RDS, Aurora, ElastiCache

 

 

Amazon RDS 개요

 

 

개념

RDS(Relational Database Service) = AWS 관리형 데이터베이스 서비스 : SQL 기반 엔진 지원 : 프로비저닝·패치·백업·모니터링 자동화 : EC2에 직접 DB 설치하는 것과 달리 운영 부담을 AWS가 대신 관리

 

지원 엔진

PostgreSQL, MySQL, MariaDB, Oracle, Microsoft SQL Server, IBM DB2, Aurora(AWS 독자 엔진)

 

특징

• 자동화 : DB 프로비저닝, OS 패치, 백업 및 Point-in-Time 복구
• 고가용성 : Multi-AZ 배포 가능 → 재해 복구 대비
• 확장성 : 수직 확장(인스턴스 타입 변경), 수평 확장(Read Replica 추가)
• 모니터링 : 성능 대시보드 제공
• 관리 : 유지보수 윈도우(Maintenance Window)로 업그레이드 조율
• 제한 : SSH 직접 접속 불가 (AWS 관리형 서비스이므로 EC2 레벨 접근 불가)

스토리지

• 스토리지는 EBS가 지원
• RDS Storage Auto Scaling 지원 → 스토리지 자동 확장 기능
  조건 : 남은 공간 < 10%, 5분 이상 지속, 마지막 확장 후 6시간 경과 시 자동 확장
  최대 스토리지 한도 지정 가능 → 무한 확장 방지
  모든 RDS 엔진에서 지원

핵심 요약

RDS = AWS가 관리하는 SQL 기반 DB 서비스 : 엔진 다양 / 자동 백업·패치·복원 / Multi-AZ·Read Replica로 확장·고가용성 지원 / 스토리지 자동 확장 기능 포함

---

 

RDS 읽기 전용 복제본 vs 다중 AZ

 

 

읽기 전용 복제본 (Read Replica) 개념

읽기 전용 쿼리를 스케일링하기 위한 기능 : 메인 DB 인스턴스의 데이터를 비동기식(읽기가 일관적으로 유지)으로 복제 : 최대 15개 생성 가능 : 같은 AZ, 다른 AZ, 다른 리전에 둘 수 있음

특징

'비동기식' 복제(데이터의 최신 상태 보장x) → 읽기 지연 가능 : SELECT 전용, INSERT/UPDATE/DELETE 불가 : 필요 시 DB로 승격 가능 : 그러면 이 복제본은 복제 메커니즘 완전 탈피하게 되겠지 : 다른 AZ 내 복제는 무료, 리전 간 복제는 비용 발생

사용 사례

보고서·분석 작업 분리 : 프로덕션 DB 부하 분산 : 읽기 트래픽 급증 대응(뉴스 등)

 

 

다중 AZ (Multi-AZ) 개념

고가용성(HA)과 재해 복구(DR)를 위한 기능 : 메인 DB를 다른 AZ의 스탠바이 DB로 동기식 복제

 

특징

'동기식' 복제 → 데이터 일관성 보장 : 자동 장애 조치(Failover) 지원 : 스탠바이 DB는 읽기/쓰기 불가 (단순 장애조치 대기일뿐) : 하나의 DNS 이름으로 자동 전환 → 애플리케이션 수정 불필요 : 즉, SQL 연결 문자열을 변경하지 않아도 됨

 

사용 사례

서비스 중단 없는 고가용성 확보 : 데이터센터·AZ 장애 대비 : 미션 크리티컬 DB 운영

 

포인트

• 읽기 전용 복제본 = 스케일링용 (읽기 부하 분산)
• 다중 AZ = 가용성/장애 조치용 (재해 복구)
• 단일 AZ에서 다중-AZ 전환? : 가능 : 근데 다운타임 없음 : 즉, 전환시 데이터베이스 중지 필요x
• 원하는 경우 읽기 전용 복제본을 다중-AZ 설정 가능(재해 복구를 대비해서 읽기 전용 복제본을 다중 AZ로 설정)

핵심 요약

읽기 전용 복제본 = 읽기 확장, 비동기 : 다중 AZ = 고가용성, 동기식, 장애 조치용

 

---

 

RDS Custom

 

개념

RDS는 OS·DB 내부 접근 불가 : RDS Custom은 Oracle, MS SQL Server 전용 : 운영체제·데이터베이스까지 직접 엑세스, 제어 가능

특징

SSH·SSM으로 기저 EC2 접근 가능 : 내부 설정 변경·패치 적용·네이티브 기능 활용 가능 : 자동화 기능 일부 끄는 것 권장 : 문제 발생 대비 스냅샷 필수

비교

RDS = AWS가 완전 관리 (사용자 개입 최소) : RDS Custom = 유연성↑, 직접 제어 가능, 대신 위험도↑

사용 사례

기업 내부 규정상 특정 설정 필요 : 오라클·MS SQL 고급 기능 활용 : 맞춤형 환경에서 테스트·운영

핵심 요약

RDS = 안정성과 자동화 중심 : RDS Custom = 제어권과 유연성 중심 (Oracle/MS SQL 한정)

 

 

---

 

 

Amazon Aurora

개념

AWS 독자적 DB 서비스 : MySQL·Postgres 호환 : 클라우드 최적화 아키텍처 : RDS 대비 성능 향상 (MySQL 5배, Postgres 3배)

 

스토리지

10GB 시작 → 자동 확장 최대 128TB : 무언가를 기록할 때 다중 AZ에 6개 복제해서 저장해놓음 : 쓰기는 6개 중 4개 성공 시 완료 : 읽기는 6개 중 3개만 필요 : 자가 복구 가능

복제와 가용성

읽기 전용 복제본 최대 15개 지원 : 복제 속도 빠름 : 다중 AZ와 유사하게 마스터 장애 시 30초 내 자동 장애 조치 : 즉, 다중 AZ 내장으로 고가용성 보장 : 즉, 쓰기 기능이 있는 마스터가 하나인데, 무언가를 기록할 때 다중 AZ에 6개씩 복제해놓아 확장이 일어난 것이 있을 것 : 근데 마스터가 장애가 생기면 읽기 전용 복제본들이 여러개 또 생겨서 그 무언가를 기록해놓은걸 다시 읽어들일 수 있게되는 작동방식임

엔드포인트

Writer Endpoint = 항상 마스터 가리킴 : 장애 조치 후에도 자동 갱신 : Reader Endpoint = 읽기 전용 복제본들과 연결되어 분산 : 연결 레벨 로드 밸런싱 지원

비용

RDS 대비 약 20% 비쌈 : 하지만 스토리지 자동 확장·효율적 스케일링 덕에 장기적으로 비용 절감 가능

추가 기능

자동 백업·복구 : 보안·규정 준수 지원 : Zero-downtime 패치 : Aurora Backtrack 기능 → 특정 시점으로 복구 가능 (백업 의존 X)

사용 사례

고성능·고가용성 요구 DB : 대규모 읽기 트래픽 분산 : 미션 크리티컬 애플리케이션 운영

핵심 요약

Aurora = RDS보다 빠르고 안정적 : 자동 확장 스토리지 + 다중 AZ 6중 복제 : Writer/Reader 엔드포인트로 읽기·쓰기 분리 : 읽기 복제본 최대 15개, 장애 조치 빠름

 

---

 

Aurora 고급 개념

 

복제본 Auto Scaling
개념 : 읽기 복제본 수를 자동으로 조절 : CPU·트래픽 부하 증가 시 자동 복제본 생성 : 리더 엔드포인트에 연결된 요청을 분산 처리
장점 : 읽기 부하 급증에도 안정적 : 수동 관리 불필요

사용자 지정 엔드포인트
개념 : 특정 인스턴스 그룹에 전용 엔드포인트 부여 : 예) 상대적으로 작은 인스턴스(large)보단 대형 인스턴스(2xlarge 등)에 엔드포인트 지정하여 분석 쿼리 전용으로 활용
장점 : 워크로드 분리 가능 : 강력한 인스턴스에 특정 작업 집중

Aurora Serverless
개념 : 사용에 따른 자동 데이터베이스 생성 + Auto Scaling : capacity planning 불필요 : 요청량에 따라 Aurora 인스턴스가 자동 생성·제거 : 사용량 기준 과금
특징 : 간헐적·예측 불가 워크로드에 최적 : Aurora 프록시 플릿이 백엔드 인스턴스를 자동 관리

Aurora 글로벌 데이터베이스
개념 : 한 리전 → 최대 5개의 다른(보조) 리전으로 복제 가능 : 복제 지연은 1초 이하밖에 안됨 : 보조 리전당 최대 16개 읽기 전용 복제본 사용 가능
장점 : 전 세계 사용자에 낮은 지연 제공 : 만약 재해 시 보조 리전을 마스터로 승격 가능 (1분 내 복구)
포인트 : “1초 미만 지연” → Aurora Global

Aurora + Machine Learning 통합
개념 : SQL 쿼리로 ML 예측 결과 활용 가능 : Aurora → SageMaker·Comprehend 통합 지원
사용 사례 : 이상 탐지, 감정 분석, 추천 시스템, 광고 타겟팅 : ML 경험 불필요, SQL만으로 구현 가능

핵심 요약
복제본 Auto Scaling = 읽기 부하 자동 대응
사용자 지정 엔드포인트 = 특정 워크로드 분리
Serverless = 사용량 기반 자동 확장·축소
글로벌 Aurora = 다중 리전 복제, 1초 미만 지연, 빠른 DR
ML 통합 = SQL만으로 ML 예측 호출

 

---

 

RDS 백업 & Aurora 백업

 

 

RDS 백업

• 자동 백업 : 매일 전체 DB 백업 + 5분마다 트랜잭션 로그 백업 : 시점 복구(PITR) 가능 : 보존 기간 1~35일 설정 가능 (0으로 비활성화)
• 수동 스냅샷 : 사용자가 직접 생성 : 원하는 기간 동안 무제한 보관 가능 : 비용 절감을 위해 DB 삭제 전 스냅샷 보관 → 필요 시 복원
• 활용 요령 : DB를 잠깐만 쓰는 경우 스냅샷 저장 후 DB 삭제 → 스토리지 비용 절감 : 스냅샷은 RDS 데이터베이스의 실제 스토리지 비용보다 훨씬 저렴하기 때문

Aurora 백업

• 자동 백업 : 1~35일 보존 가능 : 비활성화 불가 : 시점 복구 지원
• 수동 스냅샷 : 수동으로 원하는 기간동안 유지 무제한 보관

복원 옵션
자동 백업/스냅샷 복원 : 할때마다 항상 새 데이터베이스가 생성됨 : 새 데이터베이스로 복원할 수 있는 것
RDS MySQL S3 복원 : S3(AWS의 클라우드에 객체를 저장하는 방법)에서 MySQL을 복원할 수 있음 : 온프레미스 데이터베이스의 백업을 생성한 다음 객체 스토리지인 Amazon S3에 배치하는 것임

Aurora MySQL S3 복원 : Aurora MySQL로 복원하려면 외부적으로 Percona XtraBackup 소프트웨어 사용하여 백업 필요, 그걸 S3로 보내어 클러스터 복원 : 즉, 단순 데이터베이스 백업만 있으면 되는 RDS의 경우와 달리 복잡함

 

Aurora DB 복제 기능
개념 : 기존 클러스터를 빠르게 복제해 새 클러스터 생성 (프로덕션 → 스테이징/테스트 등) : 프로덕션 데이터베이스의 영향을 주지 않고 복사 및 분리가되는 장점
특징 : snapshot 복원보다 빠름 : copy-on-write 프로토콜 기반 : 처음에는 원본과 동일한 스토리지 공유 → 변경 시 '그때' 필요한 블록만 복사 : 복제본이 여전히 원래 블록을 참조하기에 데이터 충돌 없이 원본에 영향을 주지 않고 일관성 유지 : 다른 AZ에 읽기 전용 복제본을 생성하고 프로덕션 데이터베이스의 영향을 주지 않고 복제본에서 테스트

핵심 요약
RDS 자동 백업 = 5분 단위 트랜잭션 로그, 1~35일 보존
수동 스냅샷 = 무기한 보관 가능, 비용 절감 활용
Aurora 백업 = 비활성화 불가, 기본 제공
S3 복원 = 외부 DB 마이그레이션 경로
Aurora 복제 = 빠른 복제, 스테이징/테스트 환경에 유용

 

 

---

 

 

RDS 및 Aurora 보안

 

저장 데이터 암호화

RDS 및 Aurora 데이터베이스에 저장된 데이터를 암호화할 수 있음 : KMS 기반 : 마스터/복제본 모두 암호화됨 : DB 생성 시에만 설정 가능 : 기존 비암호화 DB는 스냅샷 → 암호화 복원 절차 필요 : 즉, 암호화되지 않음 RDS DB 인스턴스로는 암호화된 읽지 전용 복제본도 생성할 수 없겠지

전송 중 데이터 암호화

기본 TLS 지원 : 클라이언트는 AWS TLS 루트 인증서 사용

인증 방식

전통적 사용자명+비밀번호 가능 : IAM 사용자는 기본적으로 RDS 데이터베이스에 접근할 수 없음 : IAM 데이터베이스 인증을 활성화해야함 : 그럼 패스워드 없이 EC2 등에서 안전하게 접속 : 근데 Oracle은 IAM 인증을 지원하지 않음

네트워크 보안

보안 그룹 규칙으로 접근 제어 : 포트, IP, SG 단위로 허용/차단 설정

 

관리 제한

RDS/Aurora는 SSH 불가 : 단, RDS Custom은 예외적으로 OS/DB 접근 가능

감사 로그

쿼리 및 접속 로그 추적 가능 : 장기 보관은 CloudWatch Logs로 전송

핵심 요약

저장 암호화 = KMS, 전송 암호화 = TLS, 인증 = IAM 지원, 접근 제어 = 보안 그룹, SSH 접근 불가(예외: RDS Custom), 로그 = CloudWatch Logs로 보관

 

---

 

RDS 프록시 (Amazon RDS Proxy)

 

RDS 데이터베이스에 바로 액세스하면 되는데 왜 프록시가 필요할까? : Amazon RDS 프록시를 사용하면 애플리케이션이 데이터베이스 내에서 데이터베이스 연결 풀을 형성하고 공유할 수 있음 : 애플리케이션을 RDS 데이터베이스 인스턴스에 일일이 연결하는 대신 프록시에 연결하면 프록시가 하나의 풀에 연결을 모아 RDS 데이터베이스 인스턴스로 가는 연결이 줄어듦

 

왜 이렇게까지 할까? : RDS 데이터베이스 인스턴스에 연결이 많은 경우 : CPU와 RAM 등 데이터베이스 리소스의 부담을 줄여 데이터베이스 효율성을 향상시킬 수 있고 데이터베이스에 개방된 연결과 시간초과를 최소화할 수 있기 때문

개념

완전 관리형 데이터베이스 프록시 서비스 : RDS/Aurora 앞단에서 연결 풀링 제공 : 애플리케이션이 직접 DB에 연결하지 않고 프록시를 통해 연결

특징

완전한 서버리스 기반 자동 확장 : 다중 AZ 지원 → 장애 조치 시 DB 다운타임 66% 단축 : MySQL, PostgreSQL, MariaDB RDS 지원 / MySQL, PostgreSQL Aurora 지원 : VPC 내 전용 → 인터넷 직접 접근 불가

장점

연결 풀링으로 DB 부하 감소 (CPU, 메모리, 연결 수 절약) : Lambda 대량 연결 문제 해결 → 안정적 연결 관리 : IAM 인증 강제 가능 → Secrets Manager에 자격 증명 저장

사용 사례

대규모 트래픽 환경에서 DB 연결 효율화 : Lambda 함수와의 통합 : 장애 조치(Failover) 시간 단축 : 보안 강화를 위한 IAM 인증 강제

핵심 요약

RDS 프록시 = 연결 풀링 + 장애 조치 단축 + IAM 인증 강제 : DB 직접 연결 대신 프록시 활용 → 안정성·보안·성능 모두 개선

 

 

---

 

 

Amazon ElastiCache

 

 

RDS가 관리형 관계형 데이터베이스를 제공하는 것과 마찬가지로 ElastiCache는 관리형 Redis 또는 Memcached를 제공하여 캐시 기술을 활용할 수 있도록 도와주는 것 : 그렇다면 캐시란 무엇일까? : 캐시는 매우 높은 성능과 낮은 지연 시간을 가진 인메모리 데이터베이스 : 캐시는 읽기 집중적인 작업 부하에서 데이터베이스의 부하를 줄이는 데 도움을 줌 : 일반적인 쿼리가 캐시에 저장되므로 데이터베이스가 매번 쿼리되지 않게 됨

 

개념

관리형 인메모리 캐시 서비스 : Redis / Memcached 엔진 지원 : 초고속 읽기·쓰기 성능, 낮은 지연 시간 제공 : RDS 부하 분산 및 애플리케이션 상태 비저장 설계 가능

특징

AWS는 운영체제·패치·모니터링·장애 복구 관리 담당 : Amazon ElastiCache를 사용할 경우 애플리케이션 코드에 상당한 수정 필요 (조회 순서에 캐시 추가) : 캐시 히트/미스 전략 필요 : 세션 저장으로 상태 비저장 아키텍처 구현 가능

아키텍처 활용

읽기 캐시 → 자주 쓰는 쿼리 결과를 캐시에 저장 후 재사용(캐시히트) : 세션 캐시 → 사용자 로그인 세션을 캐시에 저장 → 인스턴스 이동 시에도 로그인 유지

Redis

멀티 AZ 지원 → 자동 장애 조치 가능 : 읽기 복제본 생성 → 읽기 스케일링 가능 : 데이터 내구성 → AOF 지속성 + 백업/복원 지원 : 고급 자료구조 지원 (집합·정렬 집합 등) → 리더보드, 실시간 랭킹 구현에 적합 : 단일 노드 복제 구조 기반

Memcached

여러 노드를 설정하여 데이터를 분할하는 sharding 기반 단순 구조 : 멀티스레드 아키텍처로 고성능 제공 : 고가용성, 복제 기본 미지원 : 백업/복원 기능 없음 (서버리스 버전 일부 예외) : 단순 캐시·분산형 저장소 용도로 적합

사용 사례

Redis → 고가용성/복제/내구성 필요할 때, 세션 저장, 리더보드, 복잡한 자료구조 활용 : Memcached → 단순 캐싱, 빠른 분산 처리, 임시 데이터 저장, 고정세션(스티키세션) 대신에 세션 데이터를 ElastiCache에 저장하여 사용 가능

핵심 요약

ElastiCache = 관리형 캐시 (Redis/ Memcached) : Redis = 고가용성·복제·내구성 지원 : Memcached = 단순, 샤딩 기반, 초고속

 

---

 

ElastiCache 보안

 

인증

IAM 인증은 ElastiCache에서는 지원되지 않음 : IAM 정책은 API 수준 보안에만 적용 : 대신 Redis AUTH(비밀번호·토큰 기반) 사용 가능 : Memcached는 SASL 인증 지원

전송 암호화

Redis에서 SSL/TLS 인플라이트 암호화 지원 : 데이터 전송 구간 보안 강화

보안 그룹

VPC 보안 그룹으로 접근 제어 : 특정 IP, 포트, SG 단위로 허용/차단 가능

캐싱 전략

지연 로딩(Lazy Loading) → 캐시 미스 시 DB에서 읽고 캐시에 저장 : Write Through → DB 기록 시 캐시에도 동시에 기록 : 세션 스토어 → 사용자 세션을 캐시에 저장, TTL(만료 시간)로 관리

캐싱 난제

캐시 무효화(Cache Invalidation)는 컴퓨터 과학의 가장 어려운 문제 중 하나로 꼽힘 → 최신 데이터 유지 전략 설계 필수

Redis 포인트

Redis에는 정렬된 세트라는 게 있음 : 고유성과 요소 순서를 모두 보장 : 요소가 추가될 때마다, 실시간으로 순위를 매긴 다음 올바른 순서로 추가 : Redis 클러스터가 있는 경우 실시간 리더보드를 만들 수 있음 : 실시간으로 1, 2, 3위 플레이어를 구할 수 있게되는 것 : 모든 Redis 캐시는 동일한 리더보드를 사용할 수 있음 : 즉, 클라이언트가 Redis를 사용하여 Amazon elasticache와 대화할 때 이 실시간 리더보드에 액세스할 수 있으며, 애플리케이션 측에서 이 기능을 프로그래밍할 필요가 없음 : 정렬된 세트와 함께 Redis를 활용하여 실시간 리더보드에 액세스할 수 있음

핵심 요약

Redis = IAM + AUTH + TLS 지원, 실시간 리더보드 가능 : Memcached = SASL 인증, 단순 캐싱 : 캐싱 전략 = Lazy Loading / Write Through / 세션 스토어

 

 

---

 

 

중요한 포트
FTP : 21
SSH : 22
SFTP : 22 (SSH와 같음)
HTTP : 80
HTTPS : 443

 

RDS 데이터베이스 포트

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

 

중요 포트와 RDS 데이터베이스 포트를 구분할 필요는 있음