RDS
EC2 인스턴스에 데이터베이스를 설치 & 사용하지 않고 RDS 사용하는 이유
1.데이터베이스의 프로비저닝 완전 자동화
2.기본 운영 체제 자동 패치
3.지속적인 백업, PITR(특정 타임스탬프에 대한 복구)
4.모니터링 대시보드를 통한 DB 성능 확인
5.여러 가용 영역을 설정해 재해 복구에 유용하게 이용 가능
6.읽기 전용으로 복제하여 인스턴스의 수직 & 수평 확장성 증가
7.EBS 스토리지 사용
8.RDS 는 별도의 SSH를 가질 수 없음
backup
Auto backup
백업은 자동으로 활성화
정의해 놓은 유지 관리 기간동안 매일 수행되는 데이터베이스 전체 백업
일일 트랜잭션 로그가 5분 마다 RDS 안에 백업
위 전체 백업, 로그 2가지를 이용해서 특정 시점으로 복원 가능
자동 백업 보관 기간은 default: 7일, ~35일 까지 가능
Snapshot
사용자가 수동으로 발동시키는 백업
백업 기간을 사용자가 정함
예시로 6개월간의 지정 시점 동안의 데이터베이스 내용을 보관 가능
Storage Auto Scaling
RDS를 생성할 때 스토리지 사이즈를 설정함
예시로 20GB를 설정해서 생성하였고 20GB를 모두 사용했다면
기존 온프레미스에서는 용량을 늘려주기 위한 별도의 작업을 수행해야함
이러한 상황을 피하기 위한 용도
최대 스토리지 임계값에 대한 설정이 필요하며 무한대로 확장은 불가
사용 가능한 스토리지가 10% 미만, 10% 미만 상태가 5분을 지났거나
수정사항이 6시간이 지났거나 등의 설정값을 확인하여 스케일링
워크로드를 예측할 수 없는 애플리케이션에 유용
Read Replicas for read scalibility
하나의 RDS 서비스에서 모든 요청에 대해 처리하기 벅찬 경우
RDS DB Instance 를 읽기 전용 서버로 스케일링하여 트래픽을 분산
읽기 전용 서버를 복제할 때 비동기식으로 진행
읽기 전용 복제본은 최대 5개 까지 생성 가능
읽기 전용 서버를 데이터베이스로 승격시켜 이용할 수 있음
읽기 전용에서 완전히 탈피되지만 자체적인 생애 주기를 가짐
Use Cases
개발팀에서 RDS DB Instance 를 사용하고 있음
다른팀에서 통계 데이터를 만들기위해 조회만 필요한 경우
읽기 전용으로 복제하여 RDS DB Instance 의 부하를 막음
Network Cost
특정 AZ -> 외부 AZ 로 데이터의 이동이 있을 때 비용 발생
그러나 관리형 서비스에 대해서는 예외가 있음
A 리전, A 가용 영역에 RDS DB Instance 가 있다고 가정
A 리전, B 가용 영역에 읽기 전용을 구성하기 위해 트래픽이 발생하는 경우
무료로 구성할 수 있음
그러나 리전이 다른 경우에는 해당되지 않음
Multi AZ
주로 재해 복구에 사용
A 가용 영역에 RDS Master DB Instance 가 있다고 가정
마스터 DB 인스턴스의 모든 변화를 B 가용 영역 RDS DB Instance
stanby 에 복제
마스터 DB 인스턴스에 문제가 발생하면 standby 인스턴스가 별도의
설정없이 마스터 DB가 되어 기존 수행을 이어 진행함
standby 인스턴스가 아닌 읽기 전용을 다중 AZ로 설정하여
재해에 대해 대비할 수 있음
Single AZ -> Multi AZ
전환할 때 다운타임이 없으며 데이터베이스를 중지할 필요 없음을 의미
데이터베이스 옵션에 다중 AZ 기능을 활성화 하면 적용됨
활성화시 위에서 얘기한 동기식 복제 standby DB 를 확보함
1.내부적으로 DB 스냅샷 생성
2.해당 스냅샷으로 standby DB에 반영
3.RDS DB Instance, Standby DB 동기화
4.이 후 마스터 인스턴스에 대한 변경사항을 Standby DB에도 적용
RDS 실습
1.RDS Dashboard -> create datatable
2.Standard create, MariaDB, Production
3.Credentials Settings -> 패스워드 입력 (계정 메모)
4.Instance Configuration 에서 필요한 서버 옵션 선택
5.Burstable classes 체크, Include previous generation classes 활성화를 진행하여 db.t2.micro(제일 낮은 옵션) 선택 가능
6.Storage 설정 및 Storage autoscaling 용량 설정 가능
7.Availability & durability: Multi-AZ standby 인스턴스 생성 여부
8.Connectivity - Public access - Yes 선택하여 공개적 테스트 가능
9.기존 VPC 를 사용하거나 생성하여 적용
10.Database authentication - Password, 운영 시(Password, IAM)
11.Additional configuration - options, backup, log 등...
12.Create
13.RDS Dashboard -> 생성한 DB 클릭 -> Connectivity & security
14.Endpoint, Port, 계정 정보 확인
15.다양한 SQL Tools 다운로드 및 실행 후 접속 테스트
- Actions
- Create read replica(읽기 전용)
- Take snapshot(스냅샷 생성하여 해당 스냅샷으로 복구 가능)
- Restore to point in time(특정 시점 백업)
- Migrate snapshot(스냅샷을 다른 리전으로 옮기는 작업)
DataBase 삭제
삭제를 진행하기 전 삭제 보호를 제거해야 함
1.RDS Dashboard -> 특정 DB 클릭 -> Modify 클릭
2.Deletion protection - Enable deletion protection 체크 해제
3.RDS Dashboard -> 특정 DB 클릭 -> Actions -> Delete 클릭
4.팝업 삭제 동의에 관한 체크 및 나머지 체크 해제 후 삭제 진행
Security
At rest encryption
AWS KMS(Key Management Service, AES 256 암호화) 사용하여
마스터 데이터베이스, 일기 전용 복제본 암호화 가능
마스터 DB 암호화를 한 경우에만 복제본에 대해 암호화 가능
Oracle, SQL Server 에서 TDE 투명한 데이터 암호화 활성화 사용 가능
In-flight Encryption
항상 SSL 인증서가 필요한 전송 중 암호화(Client -> DB 전송중인 데이터)
신뢰할 수 있는 SSL 인증서를 제공하여 SSL 연결 가능
PostgreSQL 콘솔 매개변수: rds.force_ssl=I
MYSQL 명령문: GRANT USAGE ON . TO 'mysqluser'@%'REQUIRE SSL
Encryption Operations
스냅샷이 암호화 되어있으면 복사본도 암호화, 반대의 경우도 동일
- 암호화되지 않은 RDS DB의 암호화
- 암호화 되지 않은 RDS 데이터베이스 스냅샷 생성
- 생성한 스냅샷 복제, 복제 스냅샷을 암호화 활성
- 암호화 스냅샷으로 데이터베이스 복원, 암호화된 RDS 데이터베이스 제공
Network & IAM
네트워크 보안의 RDS 데이터베이스는 대게 프라이빗 서브넷에 배포
RDS 는 WWW 에 공개되지 않도록 해야함
RDS 보안은 RDS 인스턴스에 연결되어 있는 보안 그룹을 활용하여 실행하는데
이는 EC2 인스턴스와 동일한 개념임
사용자 관리, 권한의 액세스 관리에는 IAM 정책 사용
해당 정책은 AWS RDS 를 관리하는 사람만 제어 가능
IAM 인증을 사용한 RDS 연결 방법
MySQL, PostgreSQL 에서만 실행
RDS API 호출 사용하여 IAM 으로 인증 토큰을 직접 얻을 수 있음
인증 토큰 수명 시간 15분
RDS IAM 의 흐름
EC2 Security Group 의 EC2 는 IAM Role 이 적용되고
RDS Service 에 API 콜하여 인증 토큰을 받음
인증 토큰을 사용하여 MySQL 데이터베이스에 연결하는 동안 토큰을 전달
연결이 암호화 되었는지 확인 필요
위 방식의 장점으로 네트워크 안팎이 SSL로 암호화 됨
데이터베이스 내부의 사용자 인증이 아닌 중앙 집중화 인증을 사용
IAM 역할, EC2 인스턴스 프로파일로 통합 가능
RDS 암호화 정리
- 미사용 데이터 암호화
- 데이터베이스 인스턴스 처음 생성시에만 실행
- 암호화 되지 않은 경우 스냅샷을 생성
- 스냅샷을 암호화하고 새 데이터베이스(암호화) 생성
- 사용자 역할
- 포트, 보안 그룹, 인바운드 규칙, 데이터베이스 보안 그룹 확인
- 내부 데이터베이스의 사용자 생성 및 권한 관리
- MySQL, PostgreSQL 용 IAM으로 관리
- 퍼블릭 액세스가 있고 없는 데이터베이스 생성
- 프라이빗 서브넷, 퍼블릭 서브넷으로 가도록 설정
- 파라미터 그룹, 데이터베이스를 SSL 연결에만 허용하도록 구성
- 암호화 되는지 확인
- AWS 역할
- SSH 액세스 발생하지 않도록 함
- OS, DB 자동 패치
Aurora
MySQL, Postgres 호환 가능
MySQL x 5배, Postgres x 3배 정도 더 빠르며 20% 정도 비쌈
스토리지는 10GB 부터 시작하여 128TB 까지 자동으로 커짐
Aurora는 15개의 읽기 전용을 가질 수 있으며 복제 속도 또한 더 빠름
장애 조치에 대해 빠르며 클라우드 네이티브라 고가용성을 얻을 수 있음
고가용성 & 읽기 스케일링
쓰기 요청을 할 때 마다 6개의 데이터 복제본 3개의 AZ에 걸쳐 저장
이는 하나의 AZ 쓰기 요청이 실패하더라도 문제가 되지 않음을 의미
자가 복구 과정을 가지고 있어 데이터 손상된 경우 백엔드 P2P 복제로
자가 복구 할 수 있음
수백 개의 볼륨에 의지 가능
Aurora 에 마스터가 있으며 쓰기 요청을 진행함
마스터가 작동하지 않으면 30초 안에 장애 조치가 이루어짐
모든 읽기 전용 복제는 마스터를 대체할 수 있음
읽기 전용 복제는 리전 간 복제를 지원함
Aurora DB Cluster
공유 스토리지 볼륨은 자동 확장 됨을 얘기함
마스터는 위 스토리지에 유일하게 쓰기를 할 수 있음
그리고 변경 및 장애 조치를 할 수 있기 때문에 Writer 엔드포인트 제공
DNS 이름인 Writer 엔드포인트는 항상 마스터를 가리킴
읽기 전용은 오토 스케일링 되어 위치, URL 추적 및 연결이 어려움
이 때 사용하는 방법으로 Reader 엔드포인트를 사용
로그 밸런싱 연결 지원하며 모든 읽기 전용 복제본에 자동으로 연결
이는 클라이언트 -> 리더 엔드포인트 -> 로드밸런싱 -> 읽기 전용 복제
Aurora 기능
- 자동 장애 조치
- 백업 및 복구
- 격리 및 보안
- 산업 규정 준수
- 푸시 버튼 스케일링
- 다운타임 없는 자동 패치
- 확장 모니터링
- 정기 유지 보수
- 백트랙(원하는 시점으로 언제든지 복원)
Security 는 RDS 와 거의 동일함
Aurora 실습
RDS 생성 방법과 크게 다르지 않으며 몇가지 추가 구성 필요
Aurora 삭제할 때는 쓰기, 읽기 엔드포인트 부터 삭제한 후 삭제 가능
1.Edition - MySQL, PostgreSQL Compatible Edition 선택
2.Additional configuration - BackTrack, 역추적으로 백업
3.데이터베이스 생성 후 클릭
4.Regional cluster, Writer instance, Reader instance 구성 확인
5.Connectivity & security 에서 각 각의 엔드 포인트 확인
6.쓰기, 읽기 인스턴스를 클릭하여 전용 엔드포인트도 확인 가능
7.Actions 에서 읽기 인스턴스 추가, 리전간 복제도 가능
8.Actions - Add Auto Scaling policy(복제본 자동 스케일링) 가능
Aurora - Custom Endpoints
1개의 쓰기 인스턴스, 4개의 읽기 인스턴스
4개의 읽기 인스턴스 중 2개의 인스턴스는 사양이 높은 경우
엔드포인트를 커스텀하여 고사양의 인스턴스에서는 특정 요청을 받도록
하여 인스턴스 별로 역할을 분할 할 수 있음
Aurora - Serverless
자동 데이터베이스 인스턴스화, 자동 스케일링 기반으로 사용
드물거나 간헐적이거나 예측할 수 없는 워크로드에 유용
용량 계획을 수행할 필요 없음
실행 중인 각 오로라 인스턴스의 초당 비용을 지불하는 구조
클라이언트 -> 프록시 플릿(Aurora) 통신 -> 서버리스(백앤드)
워크로드를 기반으로 많은 오로라 인스턴스 생성
Aurora - Multi Master
쓰기 노드 장애에 대해 빠른 수정이 필요한 경우
일반적으로 사용했던 쓰기, 읽기 노트를 나누지 않고 모든 노드가 같은 권한
특정 노드에서 장애 발생시 다른 노드로 자동 장애 조치 수행
Global Aurora
리전 간 읽기 전용 복제본은 재해 복구에 유용하며 간단하게 구현 가능
모든 읽기 및 쓰기가 발생하는 하나의 기본 리전이 있을 때
최대 다섯 개의 보조 읽기 전용 리전을 설정 가능
최대 16개의 읽기 전용 복제본을 가질 수 있음
특정 리전에 aurora 인스턴스를 마스터로 사용하다가 장애가 발생하면
다른 리전에 aurora 인스턴스를 마스터로 승격하여 사용할 수 있음
Aurora Machine Learning
SQL 인터페이스를 통한 애플리케이션에 ML 기반 예측을 추가할 수 있음
- SageMaker
- 모든 종류의 머신 러닝 모델 사용 가능
- Comprehend
- 감정 분석 수행
사용 사례는 사기 탐지, 광고 타겟팅, 감정 분석, 제품 추천이 해당됨
오로라는 사용자의 정보, 쇼핑 내역 과 같은 데이터를 머신러닝으로 보냄
전달 받은 머신 러닝 서비스에서 예측을 오로라에게 직접 반환함
해당 예측의 SQL 의 반환값을 애플리케이션에 반환하는 구조
ElastiCache
RDS와 동일한 방식으로 관계형 데이터베이스 관리
redis, memcached 같은 캐시 기술을 관리할 수 있음
캐시를 사용하여 읽기 워크로드의 부하를 줄일 수 있음
이는 일반적인 쿼리가 캐시되어 데이터베이스가 매번 쿼리 되지 않음
RDS의 장점을 동일하게 가지고 있음
cache
높은 성능, 낮은 지연 시간을 가진 인 메모리 데이터베이스
ElastiCache Solution Architecture
Application, ElastiCache, RDS 가 있다고 가정
애플리케이션은 엘라스틱캐시를 캐시 히트함
이미 생성되어 저장되었다면 쿼리하기 위해 데이터베이스에 접근하는
동선을 하나 줄일 수 있게됨
캐시 미스의 경우에는 데이터베이스에서 데이터를 가져와서 캐시에
저장하고 동일한 쿼리가 발생하는 다른 애플리케이션, 인스턴스에
같은 쿼리는 캐시 히트를 얻도록 함
캐시무효화 전략 적용과 가장 최근 데이터만 사용하는지 반드시 확인되야함
세션에도 적용할 수 있음
사용자 로그인의 경우 로그인이 완료된 세션 값을 캐시에 저장
다른 인스턴스에 요청이 전달되더라도 캐시에서 사용자를 확인할 수 있음
캐시 히트
이미 생성되어 일래스틱 캐시에 저장됐는지 확인
캐시 미스
일래스틱 캐시에 저장되지 않은 경우
ElastiCache - Redis vs Memcached
- Redis
- 자동 장애 조치로 다중 AZ를 수행하는 기술
- 읽기 전용 복제본은 읽기 스케일링에 사용되며 가용성이 높음
- 지속성으로 인해 데이터 내구성이 있음
- 백업, 기능 복원 기능, 전체적으로 RDS와 유사함
- Memcached
- 데이터 분할에 다중 노드를 사용(sharding:샤딩)
- 가용성이 높지 않고 복제도 발생하지 않음
- 지속적인 캐시가 아니며 백업, 복원 안됨
- 다중 스레드 아키텍처로 몇몇 샤딩과 함께 캐시에서 실행
ElastiCache 실습
1.ElastiCache Dashboard -> Create cluster -> Create Redis cluster
2.백업본을 가지고 레디스 클러스터 재생성도 가능
3.Cluster mode 활성화:여러 복제가 생기며 확장성 및 가용성 향상
4.Location - ElastiCache 서비스가 AWS or On premises 인지
5.Multi-AZ는 향상된 고가용성을 제공, 자동 장애 조치 통해 실행
6.이 외에 설정 값들은 다른 서비스들과 거의 동일 -> Next
7.Encryption at rest: 키를 사용하여 저장된 암호화 활성화
8.Encryption in transit: 전송 중 암호화 선택
9.전송 중 암호화 활성화는 엑세스 제어를 얻으며 사용자 엑세스 Redis Auth 토큰을 지정 가능
10.이후 설정은 동일 - Create
해당 서비스도 상세에 엔드포인트를 확인 및 이용하여 사용 가능
솔루션 설계자를 위한 ElastiCache
ElastiCache의 모든 캐시는 IAM 인증 지원 안함
AWS API 수준(캐시 생성, 캐시 삭제) 보안에서만 IAM 인증 사용
Redis Auth 를 사용하여 레디스 클러스터 생성시 비밀번호, 토큰 설정
전송 중 암호화를 위해 SSL 보안 지원
Memcached는 더 높은 수준의 SASL 기반 인증 지원
SASL: 인터넷 프로토콜에서 인증과 데이터보안을 위한 프레임워크
ElastiCache 데이터 불러오는 3개 패턴
Lazy Loading
모든 읽기 데이터가 캐시, 데이터가 캐시에서 부실해짐
Write Through
오래된 데이터가 없는 데이터베이스에 데이터를 기록할 때마다 캐시에
데이터를 추가하거나 업데이트
Session Store
ElastiCache를 저장소로 쓸 수 있고 Time To Live 속성으로 세션 만료
Redis Use Case
게임 리더보드 생성, 순위 가려내는 개념
고유성과 요소 순서를 가려내는 정렬된 집합이라는 기능이 있음
요소가 추가될 때마다 실시간으로 순위가 매겨지고 올바른 순서로 추가됨
