AWS 데이터베이스 서비스

임종혁·2024년 12월 9일
aws

5장 데이터베이스 서비스

OLTP데이터베이스

개념

  • OLTP 데이터베이스는 데이터의 빈번한 읽기 및 쓰기 작업이 요구되는 애플리케이션 적합
    • 신속한 쿼리 작업 최적화
    • 정형화된 쿼리 주로 사용
    • 높은 수준 메모리 용량
    • 충분한 수준 메모리 및 컴퓨트 용량을 지닌 단일 서버를 통해 모든 쓰기 및 읽기 작업 처리
    • 주로 온라인 주문 시스템 사용

OLAP

개념

  • 대규모 데이터에 대한 복잡한 쿼리 작업에 적합
  • 높은 수준 컴퓨트 및 스토리지 성능 요구
    • 데이터 웨어하우스 일경우 단일 OLAP데이터베이스에 다수 OLTP 데이터베이스 결합 사용
  • 여러개 서버를 두고 복잡한쿼리 작업 처리를 나눠서함
    • 파티셔닝 샤딩 작업을 통해 서버가 처리할 부분을 맡아서 처리

RDS

개념

  • 클라우드 기반 관계형 데이터 베이스
    • 데이터베이스 복원 , 복구, 확장 자동 수행
  • 생성시 AWS 전과정 관리
    • EC2 인스턴스에서 바로 접근 불가능

데이터베이스 엔진

개념

  • 데이터베이스에 데이터 저장, 조직화, 인출하는 소프트웨어

    • 데이터베이스 인스턴스는 오직 하나의 데이터베이스 엔진만 실행

  • MySQL, MariaDB, Oracle, PostgreSQL, Amazon Aurora,

데이터베이스 인스턴스 클래스 종류

스탠다드 데이터베이스 인스턴스

  • 대부분의 사용자의 데이터베이스에 대한 요구에 맞춘 클래스
    • 384GB메모리
    • 96vCPU
    • 25Gbps 네트워크 대역폭
    • 19000Mbps 디스크 처리 용량

메모리 최적화 데이터베이스 인스턴스

  • 높은 수준의 성능을 요구하는 데이터베이스에 적합 인스턴스 타입
  • 메모리에 더 많으 ㄴ데이터를 저장할 수 있도록 충분한 메모리 제공
    • 3904GB of 메모리
    • 128vCPU
    • 25Gbps 네트워크 대역폭
    • 14000Mbps 디스크처리용량
  • EBS 스토리지 사용
  • EBS 스토리지와 고속의 전용 네트우크로 연결

성능 가속 데이터베이스 인스턴스

  • 개발, 테스트, 비상용화를 고려한 데이터베이스 인스턴스
    • 32GB of 메모리
    • 8vCPU
    • 5Gbps 네트워크 대역폭
    • 2048Mbps 디스크 처리 용량
  • 최대 디스크 처리용량으로 디스크 읽기 쓰기 작업 처리

스토리지

초당 입출력 이해

  • IOPS
    • 초당 입출력 작업량
    • IOPS 수치가 높을수록 데이터베이스가 더욱 빨리 데이터를 저장 인출 할 수 있다
    • 데이터의 양은 데이터베이스 엔진이 사용하는 페이지 크기에 따라 달라진다.
    • 즉 피룡 디스크 처리 용량이 얼마인지 알아야함
      • EX) 102400KB 데이터를 읽어야하는데 페이지 크기가 16KB 이면 6400IOPS 가 필요한다 할수 있음
      • 즉 페이지가 클수록 더욱 적은 수준 IOPS성능 필요

RDS 지원 스토리지 4가지

범용 스토리지

  • 대부분 데이터베이스에서 범용 SSD 스토리지는 충분한 성능 및 밀리초 수준 저지연성 제공

  • 최대 64TB볼륨 할당 최소 20GB

    • 볼륨은 기가바이트당 3IOPS
    • 볼륨당 최대 16000IOPS처리 성능

  • 볼륨의 크기가 클수록 성능 좋아짐

  • 페이지 크기가 16KB 인 MariaDB 실행시 2000Mbps 의 디스크 스루풋을 지원하는 IOPS 계산법

    • 2000Mbps / 0.128Mb = 15,625IOPS

  • 초당 가속 성능 공식

    • 크레딧 잔고 / [3000-3* 스토리지 용량 GB]

프로비전 스토리지

  • 필요한 만큼 IOPS를 할당하고 그에 따른 비용을 지불
    • 높은 수준 성능이 필요한 경우 유용한 옵션

마스네틱 스토리지(스탠다드) 스토리지

  • 구형 인스턴스를 위한 제공
  • 사용 권장하지 않음

일기 정용 복제본

수직적 확장

  • 애플리케이션 또는 데이터베이스는 그대로 둔채 인스턴스와 관련된 리소스만 추가하는 방법
  • 인스턴스의 클래스 업그레이드
    • 수직적확장, 스케일 업

수평적 확장

  • 스케일 아웃은 읽기전용 복제본이라 부르는 데이터베이스 인스턴스를 추가하는 방법

  • 읽기 전용 복제본은 데이터베이스에 대한 쿼리 작업만 가능

  • 마스터 데이터베이스 인스턴스의 쿼리 작업 부담을 줄여주어 쓰기 작업에 집중할 수 있도록 함

  • 읽기 작업이 많은 애플리케이션에 유용

  • 마스터 데이터는 비동기적으로 읽기 전용 복제본 저장

    • 마스터 데이터 기록 시점과 읽기 전용 복제본 읽을 시점에는 약간의 차이가 발생

  • 읽기 전용 복제본 생성시 RDS는 리드온리 엔드포인트하는 도메인 네임 제공해 접속 가능

  • 읽기 전용 복제본과 마스터는 서로 다른 Az, 리전에 있어도 무방

  • 마스터 실패시 읽기 전용 복제본 마스터 승격

  • 비동기적으로 작동하므로 유실 가능성

고가용성 구현

개념

  • 데이터베이스 인스턴스 중단 상태가 발생하더라도 데이터베이스가 문제없이 실행 되도록 하려면, 다수의 AZ에 다수의 데이터베이스 인스턴스를 배포하는것이 좋음

    • RDS 에서는 AZ 배포라 부름
    • 하나의 AZ에 기보 ㄴ데이터베이스 인스터스를 두어 읽기 쓰기 작업 담당, 다른 AZ에 대기 또는 스탠바이 데이터베이스 인스턴스를 두는 방식
    • 프라이머리 인스턴스 중단시 2분이내 스탠바이 인스턴스로 데이터베이스 복구

  • 데이터베이스 인스턴스 생성 시 또는 생성 후 설정 가능

  • 활성화시 성능 저하 발생할수 있으므로 유지보수 기간에 활성화

  • 동일 리전에 있어야함

  • 동기적으로 프라이머리 인스턴스에서 스탠바이 인스턴스로 데이터 복제

    • 성능 저하 발생 할수 있음

  • 애플리케이션은 프라이머리 인스턴승 엔드포인트 도메인 네임에 연결

  • 읽기 전용 복제본과는 다르므로 읽기 트래픽을 처리하지 않음

    • 중단상태 대비해서 대기 상태 유지
    • 상태 발생시 RDS는 프라이머리 엔드포인트에 연결된 DNS 스탠바이 엔드포인트 변경
      • 애플리케이션을 이 엔드포인트에 연결

Amazon Aurora 멀티 AZ

  • Amazon Aurora에서 멀티 AZ 환경을 구성하는 방법은 싱글 마스터와 멀티마스터 두가지

싱글 마스터

  • 프라이머리 인스턴스를 구성하며 Aurora는 프라이머리 인스턴스를 가리키는 클러스터 엔드포인트 제공
  • Aurora 클러스트에는 Aurora 레플리카 또는 읽기 복제본 포함 가능
  • 프라이머리 인스턴스와 레플리카는 3개의 AZ에서 동기적으로 복제되는 클러스터 볼륨 공유
  • Aurora 레플리카가 없을시 자동으로 새 프라이머리 인스턴스 생성
  • 레플리카 있는경우 레플리카를 프라이머리 승격

멀티 마스터

  • 모든 인스턴스가 데이터베이스를 기록할 수 있으며
    • 즉 하나의 인스턴스가 실패하더차도 별도의 페일 오버 작업이 실행되지 않음
    • 다른 모든 인스턴스가 공유 클러스터 볼륨에 데이터 기록
  • 최소 하나 이상의 데이터베이스 인스턴스만 실행 되더라도 데이터 베이스 ㅇ릭기 및 쓰기 작업을 차질 없이 계속 수행 가능
    • 지속적 가용성

백업과 복원

  • RDS를 사용하면 데이터베이스 인스턴스의 EBS볼륨 스냅샷 기록 , 다수 AZ 에 저장
  • 멀티 AZ 기반의 데이터베이스 엔진 사용하지 않는한 스냅샷을 생성할대 몇초간 모든 IO작업 중단
  • 스냅샷 복구 시 RDS는 새 인스턴스 생성한 뒤 데이터 복구

RTO (Recovery Time Objective)

  • 데이터 복원 및 데이터 처리 재개가 가능한 최대 허용 시간

RPO(Recovery Point Objective)

  • 최대 데이터 손실 허용 기간

자동 스냅샷

  • RDS는 자동으로 매일 30분간 백업 윈도우 기간 동안 인스턴스 스냅샷 생성 할 수 있다.
  • 자동백업을 킬시
    • 시점별 복구 기능 활성화
      • 5분마다 데이터베이스 변경 로그 기록
      • 즉 실패시 최대 5분만큼 데이터 손실 경험
  • 일정 기간만 스냅샷 유지 후 삭제
  • 자동 스냅샷 기능 끌시 즉시 자동 기록된 모든 스냅샷 삭제
  • 수동 스냅샷은 삭제할때 까지 그대로 유지

Amazon RDS Proxy

  • 애플리케이션과 데이터베이스 인스턴스를 연결하기 위한 프록시 서비스
    • 애플리케이션이 직접 데이터베이스 소통시 성능 보안 문제
  • 데이터베이스 인스턴스와 최소환의 연결만 유지
  • 장애 대응 및 재연결 작업을 백엔드에서 조용히 처리

Amazon Redshift

  • Amazon Redshift는 관리형 데이터 웨어하우스 서비스
  • PostgreSQL 기반 RDS와는 별개 존재
  • 컬럼 단위로 데이터 저장하는 컬럼형 스토리지
    • 저장 속도 가 빠르고 효율적, 개별 칼럼에 신속하게 쿼리 작업 수행
  • ODBC, JDBC 데이터베이스 커넥터 지원
  • 스토리지에서 소요되는 컬럼수를 줄이기 위해 압축 인코딩 기법 사용
  • 수동으로 컬럼 단위로 압축할 수 있음

컴퓨터 노드

  • Redshift 클러스터는 하나 이상 컴퓨터 노들르 지니며, 컴퓨트 노드는 덴스 및 리더 두가지 종류가 잇음
    • 덴스는 컴퓨트 노드는 마그네틱 컴퓨트 노드
  • 클러스터에 하나 이상 컴퓨트노드가 있는 경우 리더 노드를 추가해 컴퓨트 노드간 커뮤니케이션을 조정하고 클라이언트와 소통

데이터 분산 유형

  • Redshift 데이터베이스의 행은 다수의 컴퓨트 노드에 분산 저장

  • 분산 방식으로는 EVEN, KEY, ALL 등의 유형

  • EVEN 분산

    • 리더 노드가 모든 컴퓨트 노드에 균일하게 분산

  • KEY 분산

    • 단일 컬럼내 값에 따라 데이터 분산
    • 동일한 값의 컬럼은 동일한 노드 저장

  • All 분산

    • 각각의 테이블이 모든 컴퓨트 노드에 분산

DynamoDB

개념

  • DynamoDB는 각종 관리 업무를 지원하는 비관계형 데이터베이스 서비스로서 다수의 파티션에 분산된 데이터 구조를 이용해 초당 수천회의 읽기 및 쓰기 작업을 처리
    • 파티션이란 테이블을 위한 스토리지 할당 영역, 다수 AZ에 존재하는 SSD장치 이용

파티션과 해시키

  • 테이블 생성시 기본키 와 데이터 타입 명시

  • 파티션 키 , 해시키 는 기본키의 두가지 타입

  • 하나의 파티션 키만 사용하는 경우 단순 기본키

  • 기본키로 파티션키와 소트키 또는 레인지 키 두개 조합 사용시 이를 복합 기본키

    • 파티션 키는 유일할 필요 없지만 파티션 키와 쇼트키 조합은 유일 해야함

  • DynamoDB는 기본키를 사요앻 파티션에 저장 아이템을 분산 관리

  • 동일한 파티션에 저장된 아이템에 대해 무수하게 읽기 및 쓰기 작업이 이뤄지는 경우 이를 핫 파티션 키라 부름

    • 핫 파트션키는 성능 저하 원인이 되므로 파티션키를 가능한한 세분화해서 지정하는 것이 좋음

속성과 아이템

  • 속성이란 하나의 키 벨류 쌍의미
  • 하나이상 속성이 모이면 아이템
  • DynamoDB 최대 용량은 400KB이며 약 50000영어 단어를 저장 가능한 수준

속성 타입

  • Scalar 데이터 타입
    • 하나의 값만 지닐 수 있으며 string, number, binary, Boolean, and null 타입이 이에 해당
  • String 데이터 타입
    • UTF-8 인코딩 기반 유니코드 데이터 400KB 까지 저장 0보다
  • Number 데이터 타입
    • 양수 및 음수를 최대 38까지 지정 가능, 앞뒤 0제거
  • binary 데이터 타입
    • Base-64 인코딩 포맷의 바이너리 데이터 저장
  • Boolean 데이터 타입
    • true, false 값을 저장
  • Null 데이터 타입
    • 미식별값 , 미확인 값에 대해 null 타입 부여 속성이 비어 있으면 안되고 null이라는 값은 존재
  • Set 데이터 타입
    • 무순위 스칼라 목록 저장
    • 해당 값은 세트내 유일해야 하며 세트는 최소 하나 이상 값을 지녀야함
  • Document데이터 타입
    • 스칼라 또는 세트 데이터 타입이 아닌 또 다른 유형의 데이터를 정의하기 위한 타입 32단계의 계층으로 문서 요소 간의 중첩 관계 정의
  • 리스트 도큐먼트 타입
    • 다양한 타이브이 순위형 데이터 모음을 저장

처리 용량 스루풋 옵션 선택

  • 테이블 생성시 DynamoDB를 온디맨드 모드 또는 프로비전 모드로 선택해서 사용할 수 있음

온디맨드 모드

  • DynamoDB는 자동으로 워크로드에 맞춰서 확장 하므로 요구되는 워크로드 수준을 파악할 수 없을시 사용한 만큼만 지불할시 유용

프로비전 모드

  • 애플리케이션에 필요한 초당 읽기 및 쓰기 횟수 지정
  • 테이블 생성시 읽기 용량 유닛 및 쓰기 용량유닛 의 수를 기준으로 파티션 제공

강한 일관성 읽기

  • 항상 최신의 데이터를 유지할 수 있음

종국적 일관성 일기

  • 최근의 쓰기 작업 내역을 미처 반영하지 못하는 경우도 발생

DynamoDB AutoScaling

  • 데이터베이스 처리할 용량에 대해 정확하게 판단을 내릴 수 없는 경우 혹은 시간에 따라 처리 용량이 빠귀는 경우 Auto Scaling을 이용해 미리 정의해둔 한계점을 넘어설때 저동으로 처리 용량 추가
    • RCU , WCU 을 정의할 필요없는 온디멘드 모드와는 다름
  • 활성화 비율에 맞쳐 RCU, WCU 의 최대 및 최솟값 지정
  • 적절한 활성화 수준을 설정하는 것이 중요
    • 활성화 수준 높일수록 프로비전한 처리 용량에 처리 작업 중단될 가능성이 높음
    • 활성화 수준 너무 낮게 잡음 불필요하게 많은 비용 부담

예약 처리 용량

  • 100유닛 이상 WCU , RCU 필요시 예약 처리 용량을 구매해 비용 절감
  • 최대 100000유닛 까지 구매 가능
  • 1년 또는 3년간 사용 가능

데이터 읽기

  • 스캔과 쿼리 방식
  • 스캔
    • 테이블 모든 아이템 반환
    • 읽기 유닛 모두 소진할 수 있음
  • 쿼리
    • 파티션 키값에 따라 아이템 반환
    • 쿼리 실행시 파티션 키와 정확하게 일치하는 아이템만 반환
    • 소트키가 있는 경우 소트키를 이용해서 쿼리 작업 할 수 있음

보조 인덱스

  • 보조 인덱스가 속성 정보를 가져오는 테이블을 베이스 테이블이라함
  • 보조인덱는 항상 베이스 테이블에서 가져오는 파티션 키 및 소트키 속성을 지님
  • 사용자는 파티션 키와 소트키 해당 값만 복사할 것인지 혹시 키 이외 다른 속성 또는 다른 값도 모두 복사할 것인지 선택 가능
  • 전역 보조 인덱스 타입과 , 지역 보조 인덱스 타입으로 나뉨

전역 보조 인덱스

  • 테이블의 기본키와 다른 속성 기준 데이터 검색

  • 파티션키 정렬키 기본키와 다르게 지점

  • 테이블 생성후 언제든 전역 보조 인덱스 생성 가능

  • 전역 보조 인덱스로 읽기 작업을 숭행시 종국적 일관성의 읽기 작업이 이뤄짐

지역 보조 인덱스

  • 파티션 키는 동일 정렬키만 다른 속성
  • 베이스 테이블과 함게ㅐ 생성
  • 생성 후 지역 보조 인덱스만 삭제 할 수 없음
  • 강한 일관성 또는 종국적 일관성 모두 가능

전역 테이블

  • 가용성 높이기 위해 전역 테이블 기법으로 다수 리전에서 해당 테이블 복제해 사용
  • 온디맨드 모드 또는 프로비전 모드를 설정한 뒤 Auto Scaling활성화
  • 리전당 하나의 읽기 전용 테이블만 지님
  • 강한 일관성 읽기는 지원하지 않음

백업

  • 언제든 가능
  • RCU 소모하지 않고, DynamoDB에 성능에 영향 주지 않음
  • 백업 횟수 제한 없으며, 동일 리전은 물론 다른 리전에 이쓴ㄴ 테이블의 백업 복구 가능
  • 온디멘드 프로비전 모드 모두 적용 가능
profile
임종혁
이전 포스트

AWS VPC

다음 포스트

AWS 자격 인증과 권한 부여

0개의 댓글