관계형 데이터베이스

• 데이터의 관계에 집중한 데이터베이스
  • 사전에 정의된 관계가 있을 때 사용
• 미리 지정된 형식과 타입의 데이터만 저장 가능
• 테이블의 형식으로 데이터를 관리
  • 행과 열을 기반으로 한 여러 테이블을 통해 데이터를 정의
• 고유의 키로 각 데이터를 식별
• 트랜젝션 지원
  • 원하는 동작이 정확히 수행되거나 완전히 실패 둘 중 하나로 유지
  • 즉, 어중간한 상태(일부만 반영되거나 실패했으나 데이터 변경이 되거나)는 없음

RDS

• 관계형 데이터베이스를 제공하는 서비스
  • Relational Database Service
  • <-> NoSql 비관계형과 반대
• 가상 머신 위에서 동작
  • 단, 직접 시스템에 직접 로그인 불가능 > OS 패치, 관리 등은 AWS의 역할
• RDS는 Serverless 서비스가 아님
  • 단 Aurora Serverless는 말 그대로 Serverless 서비스

RDS와 EC2

• 내부에서는 EC2를 활용
• VPC 안에서 동작
  • 기본적으로 public IP를 부여하지 않아 외부에서 접근 불가능
  • 설정에 따라 Public으로 오픈 가능
• 서브넷과 보안그룹 지정 필요
• EC2타입의 지정 필요
• 스토리지는 EBS를 활용
  • EBS 타입 및 용량 선택 필요
• 중지 가능
  • 단, 7일 후에 다시 시작됨
    

RDS의 인증 방법

• 전통적인 유저/패스워드 방식
  • AWS Secret Manager와 연동하여 자동 로테이션 가능
• IAM DB 인증
  • 데이터베이스를 IAM유저 자격증명/ 역할을 통해 관리 가능

RDS에서 제공하는 DB 엔진

• MS SQL Server
• Oracle
  • Oracle OLAP
• MySQL Server
• Postgre SQL
• Maria DB
• Amazon Aurora

RDS Multi AZ

• 두 개 이상의 AZ에 걸쳐 데이터베이스르 구축하고 원본과 다른 DB를 자동으로 동기화
• 원본 DB의 장애 발생 시 자동으로 다른 DB가 원본으로 승격됨
• StandBy DB는 접근 불가능
  

읽기 전용 복제본

• 데이터베이스의 읽기 전용 복제본을 생성(Async 복제)
• 쓰기는 원본 데이터베이스에, 읽기는 복제본에서 처리하여 워크로드 분산
• 원본 DB의 장애 발생 시 수동으로 DNS 변경이 필요함

RDS Multi AZ 와 Async 복제 각각 어떤 상황에 적절한지 설명해 주세요

RDS Multi Region

• 다른 리전에 지속적으로 동기화 시키는 DB클러스터를 생성
  • Async 복제
• 주로 로컬 퍼포먼스 혹은 DR시나리오로 활용

DB Subnet Group

• RDS가 프로비전되는 서브넷을 묶은 그룹
  • 실전에서는 주로 프라이빗 서브넷만을 사용
    • 보안적인 이유
  • 최소 두 개 이상의 같은 리전의 서브넷 필요
• 퍼블릭 접근을 허용하기 위해서는 퍼블릭 서브넷으로 구성 필요

RDS 비용

• 인스턴스 비용
  • 온디맨드/예약 인스턴스
• 스토리지 비용
  • SSD/IOPS 특화 등 EBS와 동일
• 데이터 전송 비용
• 기타 비용
  • 백업, 라이센스 비용, 추가 기능 비용 등

Amazon Aurora

• AWS에서 만든 클라우드 친화적인 관계형 데이터베이스 엔진

  • MySQL, PostgreSQL 지원

• 클라우드 환경에 최적화된 DB

  • RDS보다 3~5배 빠름

• 다양한 기능

  • 역추적 : 원하는 시간으로 데이터베이스를 되돌릴 수 있음

• Aurora Serverless 사용 가능

  • Serverless 환경에서 관계형 DB를 사용 가능

• 용량의 자동 증감 : 10GB부터 시작하여 10GB단위로 용량 증가

  • 연산 능력 : 128vCPU와 메모리 1024GB까지 증가 가능
  • 데이터의 분산 저장 : 각 AZ마다 2개의 데이터 복제본 저장 * 최소 3개이상의 AZ= 최소 6개의 복제본
  • 3개 이상을 잃어버리기 전엔 쓰기 능력이 유지
  • 4개 이상을 잃어버리기 전에는 읽기 능력 유지
  • 손실된 복제본은 자가 치유 : 지속적으로 손실된 부분을 검사 후 복구
  • Quorum 모델 사용
    

• 한대의 Writer 인스턴스와 다수의 읽기 전용 인스턴스로 구성

  • 총 15개의 Replica 생성 가능

• Async 복제

• 하나의 리전안에 생성 가능

• Writer가 죽을 경우 자동으로 Replica중 하나가 Writer로 Failover

  • 데이터 손실 없이 Failover시 메인으로 승격 가능

• 고가용성을 확보

Aurora Global Database

• 전 세계의 모든 리전에서 1초내의 지연시간으로 데이터 엑세스 가능
• 재해복구용도로 활용 가능
  • 유사시 보조 리전중 하나를 승격하여 메인으로 활용
  • 1초 RPO(복구 목표 지점)
  • 1분 미만의 RTO(복구 목표 시간)
  • RPO와 RTO에 대해 간략히 설명해 주세요
    

Aurora의 백업

• 읽기 복제본 지원
  • MySQL DB의 Binary log 복제
  • 단, 다른 리전에만 생성 가능
• RDS와 마찬가지로 자동/수동 백업 가능
  • 자동 백업의 경우 1~35일 동안 보관
  • 수동 백업 가능
  • 백업 데이터를 복원할 경우 다른 데이터베이스를 생성

Aurora 데이터베이스 클로닝

• 기존의 데이터베이스에서 새로운 데이터베이스를 복제

  • 스냅샷을 통해 새로운 데이터베이스를 생성하는 것 보다 빠르고 저렴함

• Copy-On-Write 프로토콜

  • 기존 클러스터를 삭제해도 제대로 동작

  

Backtrack

• 기존의 DB를특정 시점으로 되돌리는 것(새로운 DB가 아닌 기존 DB)
  • DB 관리의 실수를 쉽게 만회 가능
  • 새로운 DB를 생성하는 것 보다 훨신 빠름
  • 앞 뒤로 시점을 이동할 수 있기 때문에 원하는 지점을 빠르게 찾을 수 있음
• Backtrack Window
  • Target Backtrack Window
    • 어느 시점 만큼 DB를 되돌리기 위한 데이터를 저장할 것인지
      • 지정 시점 이전으로는 Backtrack 불가능
  • Actual Backtrack Window
    • 실제로 시간을 얼만큼 되돌릴지
    • Target Backtrack Window보다 작아야함
• Backtrack 활성화시 시간당 DB의 변화를 저장
  • 저장 된 용량만큼 비용 지불
  • DB 변화가 많을 수록 많은 로그 = 많은 비용
  • DB로그가 너무 많아 ABW가 TBW보다 작을경우,알림
• MySLQ만 가능
  • Aurora생성시 Backtrack을 설정 한 DB만 Backtrack 가능
• 스냅샷을 복구하거나 Clone을 통해 기능 활성화 가능

Aurora Serverless

• Aurora의 Serverless 버전
  • 인스턴스를 미리 프로비전 하거나 관리할 필요가 없음
  • T2.micro/T2.medium 등의 인스턴스 타입 선택 역시 불필요

ACU(Aurora Capacity Unit)

• 약 2gb RAM,CPU,네트워크
  • 최대/최소 ACU 설정 가능
  • AWS에서 Warm Pool에서 인스턴스를 준비하고 스케일링에 따라 인스턴스를 할당/회수

Aurora 비용

• 인스턴스 비용
  • 온디맨드/예약 인스턴스/Serverless
• 스토리지 비용
• 데이터 전송 비용
• 기타 비용
  • 백업, 추가 기능 비용 등

Amazon RDS 접속

• RDS 생성시 두 종류의 IP가 할당
  • Private IP : 기본적으로 할당
    • VPC 내부의 리소스가 RDS에 접근하기 위해서 사용
    • RDS의 DB Instance가 위치한 서브넷에 따라 Range 결정
  • Public IP : 퍼블릭 접근 가능 옵션을 선택했을 경우 할당
    • Private 서브넷에 DB Instance가 있을 경우 할당 되지 않음
• RDS의 IP는 다양한 상황에서 변경
  • 중지 > 재시작, DB 인스턴스가 교체, AWS에서 점검, OS패치, DB 엔진 버전 업데이트 등
  • 따라서 가능하면 DNS로 접근하는 것을 권장
• 일반적으로 Production DB의 경우 프라이빗 서브넷에 두는 경우가 많음
  • 보안적으로 매우 뛰어남
• 접속?
  • Bastion Host로 가능
  • Instance Connect Endpoint가 있을 경우 활용 가능
    • 3389포트만 활용 가능, 즉 RDS를 3389로만 사용해야 함
      

Amazon RDS 인증

• 일반적인 Username/Password
  • AWS Secrets Manager로 관리 가능
• IAM 인증
  • IAM을 활용해 임시 토큰을 생성하여 RDS에 접속하는 방법
    • 이때 IAM 인증을 허용해줄 유저를 DB에 넣어줘야 함
  • 토큰 생성을 위해서는 rds-db:connect 권한 필요
  • IAM 컨디션 활용 가능
• Kerberos