AWS RDS란?
Relational DB Service
데이터 베이스 인프라 및 업데이트들을 AWS 측에서 관리해주고 데이터베이스의 설치, 운영 그리고 관리 등의 서비스들을 지원하는 AWS의 관계형 데이터베이스이다.
RDS의 종류 - Microsoft SQL, Oracle, MySQL, postgre, Aurora, Maria DB
Data Warehousing
- Business Intelligence
- 리포트 작성, 데이터 분석시 사용
- 매우 방대한 분량의 데이터 로드시 사용
OLTP(Online Transaction Processing)와 OLAP(Online Analytical Processing)는 데이터베이스 시스템에서의 두 가지 주요 접근 방식으로, 각각 실시간 트랜잭션 처리와 분석 처리에 중점을 둡니다. 이 두 시스템은 목적, 성능 요구 사항, 데이터 구조 등에 따라 크게 다릅니다.
OLTP (Online Transaction Processing)
목적: 실시간으로 많은 트랜잭션(입력, 수정, 삭제 등)을 빠르게 처리하는 것을 목적으로 합니다.
특징
- 트랜잭션 중심: 구매, 예약, 입출금 같은 짧고 반복적인 트랜잭션을 처리.
- 짧은 쿼리: 각 트랜잭션이 빠르게 처리되도록 최적화된 짧고 빈번한 쿼리.
- 데이터 구조: 데이터베이스는 정규화된 형태로, 중복을 최소화하고 데이터의 일관성을 유지.
- 데이터 크기: 일반적으로 적은 데이터 집합을 자주 업데이트.
- 성능 요구사항: 빠른 응답 시간과 높은 처리량이 요구되며, 수많은 사용자 요청을 동시에 처리.
사용 예: 전자상거래 시스템, 은행 거래 시스템, 항공 예약 시스템.
OLAP (Online Analytical Processing)
목적: 대규모의 데이터를 분석하고, 복잡한 질의를 통해 통찰을 얻는 것이 목적.
특징
- 분석 중심: 데이터를 분석하여 비즈니스 의사결정을 지원하는 데 중점.
- 긴 쿼리: 대규모 데이터를 대상으로 복잡하고 시간이 오래 걸리는 쿼리를 실행.
- 데이터 구조: 데이터 웨어하우스에서 사용되는 비정규화된 데이터 모델을 사용하여 다양한 관점에서 데이터를 분석.
- 데이터 크기: 매우 큰 데이터 집합을 다루며, 주로 읽기 작업이 많음.
- 성능 요구사항: 빠른 질의 응답은 덜 중요하지만 대량의 데이터를 신속하게 분석할 수 있어야 함.
사용 예: 경영 보고서 작성, 판매 데이터 분석, 시장 분석.
비교 요약
OLTP는 실시간 트랜잭션 처리에 특화되어 있고, OLAP은 대규모 데이터를 분석하고 의사결정에 활용하는 데 사용됩니다.
OLTP는 빠른 처리 속도와 정확성, OLAP는 복잡한 분석과 대용량 데이터 처리에 초점을 둡니다.
Database Back-ups
1. Automated Backups
데이터베이스를 설정한 백업 보존 기간 동안 자동으로 백업하여 데이터 손실에 대비할 수 있는 기능입니다.
RDS Automated Backups의 주요 특징
-
자동 백업 주기
RDS는 데이터베이스를 자동으로 백업할 수 있도록 설정할 수 있으며, 기본적으로 하루에 한 번 자동 백업을 수행합니다.
사용자가 설정한 백업 보존 기간 동안 백업이 유지되며, 최대 35일까지 보존할 수 있습니다. -
백업 보존 기간
백업 보존 기간은 사용자가 지정할 수 있으며, 이 기간 동안 RDS는 데이터베이스 스냅샷과 트랜잭션 로그를 저장하여 특정 시점으로 복구(Point-in-Time Recovery)가 가능합니다.
보존 기간이 끝난 백업은 자동으로 삭제됩니다. -
트랜잭션 로그 백업
RDS는 트랜잭션 로그도 자동으로 백업하며, 이를 통해 특정 시점으로 복구가 가능합니다. 즉, 데이터베이스의 상태를 특정 시간대로 되돌릴 수 있습니다. -
스냅샷 기반 백업
RDS는 데이터베이스 인스턴스의 스냅샷을 생성하여 전체 백업을 수행합니다. 이 스냅샷은 S3에 저장되며, 필요할 때 이를 이용해 새로운 인스턴스를 복원할 수 있습니다.
스냅샷은 사용자가 직접 수동으로 생성할 수도 있고, 자동으로 생성된 백업을 사용할 수도 있습니다. -
성능에 미치는 영향
자동 백업은 데이터베이스의 성능에 거의 영향을 미치지 않도록 백그라운드에서 수행되며, 백업 중에도 RDS 인스턴스를 계속 사용할 수 있습니다. -
백업 저장 위치
자동 백업으로 생성된 데이터는 Amazon S3에 안전하게 저장되며, AWS의 다중 가용 영역(Multi-AZ)을 사용할 경우 백업 데이터는 여러 가용 영역에 분산되어 저장됩니다.
2. DB Snapshots
스냅샷은 수동으로 생성할 수 있으며, 자동으로 생성되는 백업과 다르게 사용자가 원하는 시점에 직접 백업을 생성합니다.
-
정적 상태 복사
DB 스냅샷은 생성 시점의 데이터베이스 상태를 그대로 캡처하여 저장합니다. 이후 데이터베이스에 변경 사항이 생겨도, 스냅샷은 변경 전의 데이터를 유지합니다. -
복구 용도
스냅샷을 이용해 데이터베이스를 특정 시점으로 되돌릴 수 있습니다. 예를 들어, 데이터베이스가 손상되거나 오류가 발생했을 때, 스냅샷을 이용해 원래의 상태로 복원할 수 있습니다.
복구 시에는 새 인스턴스나 기존 인스턴스에 스냅샷을 적용해 데이터베이스를 다시 활성화할 수 있습니다. -
수동 백업
자동 백업과 달리, DB 스냅샷은 사용자가 수동으로 생성합니다. 따라서 스냅샷은 필요할 때 직접 생성하는 백업으로, 중요한 변경 사항을 적용하기 전에 생성해두면 유용합니다. -
저장 비용
스냅샷은 효율적인 방식으로 데이터를 저장하여 중복 저장 공간을 최소화합니다. 특히 클라우드 환경에서(예: AWS RDS) 스냅샷은 데이터의 변경된 부분만 저장하므로 저장 비용이 절감됩니다. -
보관 기간
DB 스냅샷은 사용자가 삭제하기 전까지 계속 보관됩니다. 자동으로 삭제되는 RDS의 자동 백업과 달리, 스냅샷은 영구적으로 유지되며, 필요할 때 언제든지 복원할 수 있습니다.
Multi-AZ
이 그림은 AWS RDS의 Multi-AZ 배포를 설명하고 있습니다.
RDS Master (Primary)
왼쪽에 있는 데이터베이스 아이콘이 'M'(Master)으로 표시된 RDS의 기본 인스턴스입니다. 이 인스턴스는 가용 영역(us-east-1b)에 위치하고 있으며, 애플리케이션은 주로 이 인스턴스를 사용하여 데이터베이스 작업을 수행합니다.
RDS Standby Replica
오른쪽에 있는 'S'(Standby)로 표시된 데이터베이스 인스턴스는 대기 인스턴스입니다. 다른 가용 영역(us-east-1a)에 위치하며, 기본 인스턴스의 백업으로 사용됩니다. 기본 인스턴스에 장애가 발생할 경우, 이 대기 인스턴스가 활성화됩니다(자동 장애 조치).
Synchronous Replication (동기적 복제)
기본 인스턴스와 대기 인스턴스 간에 동기적 복제가 이루어지고 있습니다. 이는 데이터가 기본 인스턴스에 기록될 때, 동시에 대기 인스턴스에도 동일한 데이터가 복제된다는 것을 의미합니다. 이를 통해 데이터의 일관성이 보장됩니다.
Availability Zones (가용 영역)
두 인스턴스는 각기 다른 가용 영역(AZ)인 us-east-1b와 us-east-1a에 위치하고 있습니다. 각 AZ는 물리적으로 분리된 데이터센터이며, 하나의 AZ에 문제가 발생하더라도 다른 AZ에서 데이터를 복구할 수 있습니다.
Read Replicas
애플리케이션 서버 (Application servers)
두 개의 서버가 표시되어 있습니다.
이 서버들은 주 데이터베이스 서버에 대해 읽기/쓰기(Read/write) 작업을 수행합니다.
데이터베이스 서버 (Database server)
두 개의 데이터베이스가 있습니다
a. Primary (주 데이터베이스): 애플리케이션 서버로부터 읽기/쓰기 요청을 받습니다.
b. Read replica (읽기 전용 복제본): 주 데이터베이스의 복사본으로, 읽기 전용 작업에 사용됩니다.
주 데이터베이스에서 읽기 전용 복제본으로 비동기 복제(Asynchronous replication)가 이루어집니다.
BI/reporting 애플리케이션 서버
이 서버는 읽기 전용 복제본에 대해 읽기 전용(Read only) 작업만 수행합니다.
주로 비즈니스 인텔리전스(BI)나 보고 목적으로 사용됩니다.
ElastiCache
- 클라우드 내에서 In-memory 캐시를 만들어줌
- 데이터베이스 내에서 데이터를 읽어오는 것이 아니라 캐시에서 빠른 속도로 데이터를 읽어옴
- Read-Heavy 어플리케이션에서 상당한 Latency 감소 효과를 누림
Memcached EC2 Autoscaling처럼 데이터 사용량에 따라서 커졌다 작아졌다가 가능함
사용사례
1. 가장 단순한 캐싱 모델
2. Object caching이 주 목적
3. 캐시 크기를 자유롭게 scaling
Redis
- Key-value, set, List와 같은 데이터를 In-memory에 저장 가능함
- 오픈 소스
- Multi-AZ 지원
(재해복구가능)
