Database Service
[ AWS RDS 개요 ]
관계형데이터베이스( Relational Database )를 완전관리형으로 제공하는 서비스
→ 하드웨어 프로비저닝, OS & DB 설치 및 패치 백업 등 운영관리 지원
→ 개발자는 DB 설계에 집중할 수 있게됨
- RDS 서버 시스템에는 SSH로 직접접속 불가능( 완전관리형 서비스는 직접접속이 대부분 불가능 : LB, RDS 등… )
접속하여 진행해야하는 OS패치, DB설치 등은 AWS가 지원 - Parameter group : 데이터베이스의 파라미터 값 튜닝을 위한 변수 ( 콘솔상에서 접근가능하도록 한 장치 )
- 장애조치를 위한 다양한 기능제공 → 고가용성 옵션
- DB가 설치되는 인스턴스의 Class(type)지정가능
범용타입: db.m*
메모리최적화타입: db.r*, db.x*, db.z*
컴퓨팅최적화타입: db.c*
성능버스트타입: db.t*
[ RDS에서 지원하는 DBMS ]
- Aurora : AWS에서 개발한 DBMS로 MySQL, PostgreSQL과 호환 + 더 좋은 성능
- MySQL : 오픈소스 DBMS ⇒ 호환성이 좋음
- MariaDB : MySQL을 포크로 복제하여 만들어진 오픈소스 DBMS
- PostgreSQL : 다양한 고급기능지원( 비정형데이터 )
- Microsoft SQL Server
- Oracle : 고급 데이터 관리기능 제공( Partitioning Compression ) 라이센스 비용, 이중화 비용이 많이 소요됨 → RDS를 사용하여 비용절감가능
- IBM의 DB2
[ RDS 백업시스템 ]
- 자동백업 ( default로 활성 ) : 특정시점(분단위) 데이터 상태로 복구(PITR: point intime recovery) 가능 ( Retention Period(1~35일) 기간 내의 특정시점 )
- 스냅샷과 트랜잭션 로그를 참고하여 데이터를 백업
- 원본 DBMS가 삭제되면 함께 삭제되는 백업데이터
- 수동백업 ( Sanpshot ) : 사용자가 원하는 시점에 스냅샷을 생성 ( 중간 사이의 데이터는 백업불가 )
- 사용자가 수동으로 스냅샷을 생성하여 백업
- 원본 DBMS가 삭제되어도 스냅샷은 S3에 보관( 백업보존기간이 없고 사용자 삭제시까지 유지 )
[ AWS RDS Read Replica ]
대규모 서비스 트래픽을 분산처리하기 위해 데이터베이스 읽기작업만 지원하는 복제데이터 베이스 ( select 명령만 사용 )
- 데이터를 쓰는 작업 → write instance를 별도로 둠
데이터를 읽는 작업 → 많음, DB를 복제하여 사용
수동승격 : Read replica를 write instance로 변경가능( 다운타임 발생 ) - 최대 15개의 replica를 리전, 가용영역에 걸쳐 구성가능
- Batch작업 : 주기적으로 대량의 반복적인 데이터 작업을 수행
[ AWS RDS Multi AZ ]
Write DB를 Active-standby 형태 이중화 구성 ( Write Instance에 Multi AZ 옵션을 활성화 ) → 장애대비 자동복구 대응
- Active한 DB가 죽으면 standyBy가 Active상태가 됨
Read Replica의 쓰기 전용 데이터베이스의 승격과 유사하지만 다운타임 없음 - 예비용 인스턴스를 생성 = 실제 서비스되고 있지 않은 standby 시스템
→ 기존대비 비용이 2배 증가, 그러나 안정성이 높아짐 - 성능향상의 이점( read replica )은 보지 못함, 고가용성을 확보
[ AWS RDS Storage Auto-Scaling ]
운영관리 과정에서 디스크가 부족해지는 경우 자동으로 용량을 확장 ( 완전관리형의 특징 )
전체 용량 중 여유 공간이 10% 미만인 상태가 5분간 지속되고, 지난 6시간 동안 저장소가 변경된 이력이 없을 경우 자동으로 확장
10GB or 현재 할당공간의 10% or 지난 데이터 기반으로 예상 증가 크기 ⇒ 이중 더 큰 용량을 선택해서 확장
스토리지가 확장되어 할당된 후에는 스토리지 양을 줄일 수 없음
[ Aurora vs RDS Storage Structure ]
- RDS : 인스턴스가 개별적으로 할당된 스토리지에 데이터를 저장 및 접근
- Aurora :
- Shared Storage(공유스토리지) : 저장공간이 인스턴스와 분리되어 공유 → 내부 데이터 손실시에도 다른 영역의 사본을 통해 복구
- 최소 3개의 가용영역에서 데이터를 복제하여 1개의 데이터를 6개의 사본으로 저장 → 복구하거나 사용가능
- 4/6 Quorum : 1개의 데이터를 6개의 사본으로 저장, 쓰기작업 4개가 완료되었을때 인정
복구형상 : MySQL은 동일한 데이터를 복제해야함( 인스턴스별 데이터 ), 오로라는 공유 스토리지에서 데이터를 읽어오면 되기에 복제할 필요 없음( 읽기 가능한 것만 구축 )
- RDS : 확장은 가능하나 auto-scaling은 지원하지 않음
- Aurora : 사용하는 만큼 자동으로 확장( auto-scaling ), 읽기전용 복제본에 한해서 트래픽이 많을때 최소 15개까지 확장됨
Aurora PostgreSQL 서비스 구성 실습
[ Aurora Database 생성 ]
(1) VPC1 내부에 서브넷 2개 생성
(2) Database Routing Table 생성( lab-edu-rtb-db )
외부의 연결은 없음, VPC내의 web과 vscode에서는 db에 접속가능
(3) SG 생성 ( lab-edu-sg-aurora )
VPC 내부에서 5432포트(Postgres포트)로 접근
(3) Subnet Group 생성 ( lab-edu-subgroup-aurora ) : RDS 생성전의 사전단계
RDS 메인 콘솔 화면 → 서브넷 그룹 탭 → DB 서브넷 그룹 생성 버튼 클릭
(4) Aurora 생성
RDS 메인 콘솔 화면 → 데이터 베이스 리소스 탭 → 데이터 베이스 생성 버튼 클릭
엔진 유형: Aurora (PostgreSQL Compatible)
고가용성을 위한 multi AZ → 이중화
서브넷 그룹에 묶인 두 서브넷( 다른 AZ에 위치 )에 이중화를 구축
퍼블릭 액세스: 아니오 설정 & 기존 보안그룹 설정 : lab-edu-sg-aurora
(5) Aurora PostgreSQL 접속
cd /Workspace/scripts/
sh install_postgresql_in_ubuntu24.04_lts.sh
VS Code IDE Terminal 접속 → PostgreSQL 접속 Tool 다운로드 스크립트 실행
Aurora 접속 정보 : 라이터/리더의 엔트포인트추출 -> http://lab-edu-rds-aurora.cluster-czc2em4ge0rs.ap-northeast-2.rds.amazonaws.com/
PostgreSQL CLI 화면에서 Command 실행 : 유저생성, 권한부여
생성한 유저로 동일한 엔드포인트 접속가능
+)
현재 라이터 인스턴스만 존재 → wirte/read가 모두 몰림 읽기추가를 통한 복제로 read replica생성가능 엔드 포인트는 변하지 않는데, 엔드포인트로 접속을 하면 추가된 레플리카에 접속
클러스터 : 하나의 군집 같은 개념으로 writer와 reader를 묶어놓음 → 각 작업의 엔드포인트가 존재
[ Custom Parameter Group 생성 ]
RDS DB 엔진의 설정 값(Parameter)를 관리하는 기능
💡 Default Parameter Group vs Custom Parameter Group
- Default Parameter Group: RDS에서 기본 제공하며 수정 불가
- Custom Parameter Group: 사용자가 생성하고 커스터마이징 가능
💡 Parameter Classification
- Dynamic Parameters: 변경 사항 즉시 적용
- Static Parameters: 변경 사항은 RDS 인스턴스 재부팅 필요 (Custom Parameter Group의 대부분은 Static
💡 Parameter Type
- DB Parameters Group: 단일 Aurora 인스턴스에 대한 설정 관리
- Cluster Parameters Group: Aurora 클러스에서 속한 모든 인스턴스에 전역으로 적용되는 설정 관리
RDS, Aurora 생성 후 자주 설정하게 되는 Parameter인 timezone을 파라미터 그룹으로 설정해보기
(1) 파라미터 그룹 생성( lab-edu-pg-postgresql )
RDS 메인 콘솔 화면 → 파라미터 그룹 탭 → 파라미터 그룹 생성 버튼 클릭
(2) 파라미터 값 수정 ( timezone = Asia/Seoul )
(3) Parameter Group 적용
RDS 메인 콘솔 화면 → 데이터 베이스 탭 → lab-edu-rds-aurora 선택 → 수정 클릭
마스터 암호 입력 & 파라미터 그룹 적용 → 즉시적용
[ Read Replica 테스트 ]
(1) read replica 생성
RDS 메인 콘솔 화면 → 데이터 베이스 탭 → lab-edu-rds-aurora 선택 → 작업 → 읽기 추가 클릭
(2) Writer Instance 접속
라이터 엔드포인트로 접속
Parameter Group 설정 적용 상태 확인
테이블 attractions 생성
(3) Reader Instance 접속( 읽기 엔드포인트 ) → 반복적인 읽기 작업 수행( 10초에 한번씩 select 문 실행 )
좌측( 라이터 엔드포인트 )에서 insert → 우측( 리더 엔드포인터 )에서 select
[ Aurora Cluster Failover 테스트 ]
(1) 현재Writer / Reader Instance IP 정보 확인
라이터 인스턴스 IP 조회( 라이터 엔드포인트 nslookup ) : 10.0.81.251
리더 인스턴스 IP 조회( 리더 엔드포인트 nslookup ) : 10.0.80.45
(2) Writer Instance IP 반복 조회 명령어 실행
Writer Instance IP 반복 조회 Shell Script 실행
(3) Writer Instance 장애 조치 테스트
조회중인 라이터 인스턴스를 장애조치함
조회되는 IP 값 모니터링 : WRITER_IP → READER_IP 변경
writer가 죽으면 read replica가 자동으로 writer로 승격( multi-az처럼 수행 )