[AWS]RDS (이제 나도 클라우드 MySQL에 데이터 넣을 수 있어요)

차보경·2022년 11월 5일

aws rds 관계형 데이터베이스

AWS

목록 보기

3/13

RDS : Relational DB Service (관계형 데이터베이스)

데이터베이스 : RDS, NoSQL(JSON형태를 지님)
Like Excel
데이터베이스
테이블
데이터(하나의 set, row)
필드(col)

Relational DB 종류 (AWS RDS에서 사용가능)

Microsoft SQL, Oracle, MySQL, Postgre, Aurora, Maria DB
Aurora : AWS에서 제공하는 RDB로 Free Tier 아님!

Data Warehousing

Business Intelligence
리포트 작성, 데이터분석시 사용 (Production Database -> Data Warehousing)
매우 방대한 분량의 데이터 로드시 사용(빅데이터!)
다양한 소스에서 데이터가 합쳐지고, 저장하고있다 나중에 불러올 수 있음 (Transection 프로세싱에선 적합하지 않음)
- Transection Processing : 데이터베이스에서 트랜잭션(= 정보를 변경하는 작업)을 구성하기 위한 컴퓨터 시스템의 사용
OLTP VS OLAP_두개차이 중요
- OLTP : INSERT와 같이 종종 사용되어지는, 혹은 규모가 작은 데이터를 불러올때 사용되는 SQL쿼리가 필요할때 유용
  ex) Order # 210에만 해당되는 customer 이름, 주소, 시간 정보
  INSERT
- OLAP : 매우 큰 데이터를 불러올때 사용. 주로 덩치가 큰 SELECT 쿼리가 사용됨
  ex) 특정 회사 부서의 Net Profit, Products

Database Backups

2종류의 Backup이 있음

Automated Backups (자동 백업)
DB Snapshots (데이터베이스 스냅샷)

Automated Backups(AB) - 자동 백업

Retention Period(Point In Time(PIT)) 1-35일 안의 어떤 시간으로 돌아가게 할 수 있음
AB는 그날 생성된 스냅샷과 Transaction logs(TL)을 참고함
(매일 snapshop, log를 저장)
디폴트로 AB기능이 설정되어 있으며 백업 정보는 S3에 저장
(S3는 RDS 용량 만큼 무료, 그 이상은 유료)
AB동안 약간의 I/O suspension이 존재할 수 있음 -> Latency

DB Snapshots (데이터베이스 스냅샷)

주로 사용자에 의해 실행됨
원본 RDS Instance를 삭제해도 스냅샷은 존재함 (vs AB : instance 삭제시 없어짐)

데이터베이스 백업

기존 RDS로 새 RDS 복원시 다른 RDS 객체가 생성되는 것으로 판단, RDS instance, RDS Endpoint 가 새로 생성됨.
2개는 완전 다른 객체임 (Backup end point는 origin이 아닌 restored가 붙음_이게AWS RDS 데이터베이스 백업시 생기는 현상 -> 앞선 2개가 생성됨)

Multi AZ, Read Replicas

Multi AZ (Multi Availability Zones)

원래 존재하는 RDS DB에 무언가 변화(e.x : Write) 가 생길때 다른 Availability Zone에 똑같은 복제본이 만들어짐 = Synchronize (동시다발성 -> delay가 적음)
AWS에 의해서 자동으로 관리가 이루어짐 (No admin intervention)
원본 RDS DB에 문제가 생길 시 자동으로 다른 AZ의 복제본이 사용됨(=Disaster Recovery)
Disaster Recovery Only! -> 성능 개선을 위해서 사용되지는 않음. 따라서 성능 개선을 기대하기 위해선 Read Replica가 사용되어져야 함!
3개의 EC2 instance가 하나의 Production RDS DB에 연결되어 쓰여진다면, RDS end points가 다른 RDS가 연동됨. -> 기존 RDS에 문제가 생기면 바로 바꿈. 재해복구 시간 감소

Read Replica

Production DB의 읽기 전용 복제본이 생성됨 (= 쓰기 안됨)
주로 Read-Heavy DB작업시 효율성의 극대화를 위해 사용됨 (Scaling) 하나의 사이트에 많은 유저가 들어오면 서버가 다운됨 -> Read Replica사용.
Disaster Recovery용도가 아님!
최대 5개 Read Replica DB 허용
Read Replica의 Read Replica 생성 가능 (단 Latency 발생)
각각의 Read Replica는 자기만의 고유 Endpoint 존재 (RDS는 IP주소가 아니 Endpoint로 구분)
3개의 EC2 instance가 하나의 Production RDS DB에 연결되어 쓰여진다면, Read Replica에 의해 똑같은 RDS 복재본이 생성됨. 쓰기도 복제본으로 쓰임.
왜 할까? 대부분의 인커밍 트래픽이 read라면, main으로 모두 연결시키는게 아니라 각각의 EC2 instance를 Read Replica나눠 들어가게 함 -> 트래픽 감소, 성능 개선! Read Replica의 Read Replica를 만들어서 나눌 수도 있음

ElastiCache (RDS의 효율적인 application 퍼포먼스 가능하게 해줌)

ElastiCache

클라우드 내에서 In-memory 캐시를 만들어줌 (Cache에서 불러오는게 Hard Disc보다 속도가 빠름)
데이터베이스(RDS)에서 데이터를 읽어오는 것이 아니라 캐시를 통해 빠른 속도로 데이터를 읽어옴 (SNS, 네이버 등을 읽어오면 빠르게 처리 가능)
Read-Heavy 어플리케이션에서 상당한 Latency 감소 효과 누림 (초반 TEST용으로는 적합하지 않음)
2타입이 있음
➢ Memcached
➢ Redis

Memcached

Object 캐시 시스템으로 잘 알려져 있음
ElastiCache는 Memcached의 프로토콜을 디폴트로 따름(주 프로토콜로 사용)
EC2 Auto Scaling처럼 크기가 커졌다 작아졌다 가능함(데이터 사용량에 따라 캐쉬크기 조절가능)
오픈소스
Use Case
1. 가장 단순한 캐싱 모델이 필요할 때
2. set, list처럼 advanced data type이 아닌 Object caching이 주된 목적일 때
3. EC2의 Auto Scaling처럼 캐시 크기를 마음대로 scaling해야할 때

Redis

Key-Value, Set, List와 같은 형태의 데이터를 In-Memory에 저장 가능함
오픈 소스
Multi-AZ 지원(=Disaster Recovery가능)
Use Case
1. List, Set과 같은 데이터셋을 사용
2. 리더보드처럼 데이터셋의 랭킹을 정렬하는 용도가 필요
3. Multi AZ기능이 필요

실습

버스터블 클래스(t 클래스 포함) 상황에 따라 CPU를 버스터 할 수 있음!
MySQL에 프리티어 버전으로 춍춍춍 생성해 준다

RDS 생성중......

오케이! 생성 완료~~

RDS는 IP주소가 아닌 DNS adress system
: chabbo.chydmoeg9sja.ap-northeast-2.rds.amazonaws.com
보안 : sg-0470cc1fd20d36635 (launch-wizard-1)

EC2 고급 사항 > 사용자 데이터에 아래 내용을 넣어줌

#!/bin/bash (bash에서 필수로 넣어야함)
yum install httpd php php-mysql -y (아파치, php, mysql 설치, 모두 yes)
yum update -y
chkconfig httpd on
service httpd start (아파치 서버 실행)
echo "<?php phpinfo();?>" > /var/www/html/index.php (php파일 생성 후 저장)
cd /var/www/html (폴더 이동)
wget https://aws-learner-storage.s3.ap-northeast-2.amazonaws.com/connect.php (해당 파일 다운로드 받을 거 )