[AWS]AWS 볶음밥5 (데이터베이스)

Amazon RDS(Amazon Relational Database Service)

Amazon Aurora

Amazon RedShift

Amazon ElasticCache

Amazon KeySpaces 

 

	관계형 데이터베이스	비관계형 데이터베이스
데이터 스토리지	행과 열로 이뤄진 테이블	키 값, 와이드 컬럼, 그래프, 문서 또는 기타 모델
스키마	고정	동적
예시	Amazon RDS, RedShift, Aurora	DynamoDB, ElasticCache

 

관계형 데이터베이스

• 데이터는 테이블로 구분
• 고도로 정형화됨
• 관계는 키를 통해 설정됨
• 데이터 정확성 및 일관성을 제공
• 엄격한 스키마 규칙 및 데이터 품질 적용 필요
• 과도한 읽기/쓰기 용량 필요X

 

비관계형 데이터베이스

• 수평 스케일링 해야함
• 데이터가 기존 스키마에 적합X
• 스키마가 매우 유동적
• 읽기/쓰기 양이 너무 많아져서 기존 SQL로는 처리하기 힘들 때 사용

 

 

Amazon RDS 

하드웨어 OS 및 데이터 베이스 소프트웨어 배포 및 유지 관리 기본 제공 모니터링

저장 시, 전송 중 데이터 암호화 

자동 다중 가용영역 데이터 복제 ( 장애 발생시 동기식 복제 후 사용)

부하가 걸릴 때 다운타임 없어서 최소한의 어플리케이션 가동 중단으로 AutoScaling할 수 있음

 

다중 AZ 배포

• 다른 가용 영역의 대기 DB 인스턴스에 데이터를 복제

예를 들어 기본 DB 인스턴스가 장애가 발생하면 대기 DB 인스턴스가 대신 동작하는 방식

그리고 대기 DB 인스턴스가 기본으로 승격되고 가용영역 1에 대기 DB 인스턴스를 생성하는 방식

 

Aurora

클라우드를 위해 구축된 MySQL 및 PostgreSQL 호환 관계형 데이터 베이스

 

• 성능 및 확장성
• 가용성 및 내구성 - 3개의 가용영역을 제공하기에 가용성이 높음
• 뛰어난 보안 
• 완전 관리형 = 서버리스 

스토리지는 3개의 가용 영역에 분산된 수백 개의 스토리지 노드에 스트라이프된다.

 

Aurora Serverless

온디맨드로 시작하고 사용하지 않을 때 종료

AutoScaling

스케일링 시 어플리케이션에 대한 영향 없음

 

DynamoDB

완전 관리형(서버리스) NoSQL AWS 데이터베이스 서비스

 

규모에 따른 성능

관리할 서버 없음

엔터프라이즈에 사용 가능

 

 

 

DynamoDB 일관성 옵션

 

• 최종(eventually) 일관성
  • default 옵션
  • 읽기 용량 단위 0.5 사용
  • 복제 전에 유저가 데이터에 접근하면 복제되기 전 값(잘못된 값)을 가져갈 수 있다
  • 속도 빠름, 일관성 상대적으로 떨어짐
• 강력한 일관성
  • 복제가 다 끝난 후에 데이터를 넘겨주기에 확실함
  • 읽기 용량 단위 1 사용
  • 속도 느림, 데이터의 일관성 뛰어남

 

글로벌 테이블 : 리전간 복제를 자동화 

 

스케일링

 

프로비저닝 : 최소, 최대 정하면 이 사이에서 오토 스케일링

온디맨드 : 그냥 키면 0에서 부터 제한없이 오토 스케일링

 

 

데이터 웨어하우스

쓰기용 스키마(사전 정의된 스키마)

정형 데이터만

SQL 호환만

요약 또는 집계된 상세 수준의 데이터 

주로 읽어서 분석용으로 사용 

 

Amazon Redshift

취합된 데이터를 분석하는 도구

완전 관리형(서버리스) 데이터 웨어하우스

온라인 분석 처리(OLAP)

대규모 병렬 처리기능

s3로 자동 백업

 

활용 용도

• 비지니스 인텔리전스
• 이벤트에서 운영 분석
• 서비스형 데이터
• 예측 분석

 

행 기반 스토리지 

• 트랜잭션 처리
• 매우 빠른 데이터 쓰기

열 기반 스토리지 

• 고도의 분석적 쿼리 모델
• 데이터 집계 

 

동시성 스케일링

 

일시적으로 사용 부하량이 늘어나면

기본 클러스터와 같은 동시성 스케일링 클러스터를 만들어서 처리한다

다시 사용 부하량이 줄어들면 동시성 스케일링 클러스터 제거

 

 

Database Caching

캐싱은 더 빠른 스토리지(인메모리)를 사용해서 읽기 성능을 개선

서버가 캐시를 먼저 조회해서 원하는 데이터가 없으면 데이터 베이스로 이동해서 찾기

데이터

 

일반적인 캐싱 전략

• 지연 로딩(Lazy Loading) : 캐시 적중률 높이는 전략 
• 어플리케이션단에서 많은 작업 이뤄짐 
  1. 어플리케이션이 캐시에 데이터 요청
  2. 캐시에 원하는 데이터가 없다 
  3. 어플리케이션이 데이터베이스에 누락된 데이터 요청
  4. 데이터베이스가 데이터 반환
  5. 어플리케이션이 받은 데이터를 캐시에 저장 
• 라이트-스루(Write-through)
• 캐시에 읽지 않는 데이터가 저장될 가능성이 높음 
• 위의 단점을 보완하기 위해 TTL 과 혼합해서 사용  => ElastiCache
  • 캐시와 데이터베이스에 쓴다

 

DynamoDB Accelerator

DynamoDB를 위한 완전관리형 고가용성 캐시

마이크로초 응답 시간을 제공