[SAA] RDS

RDS

• 다양한 DB 엔진 지원
• SQL DB 관리형 서비스

사용 이유

• 인스턴스에 DB 띄우는 것과 무슨 차이가 있을까
• 말 그대로 관리형 서비스이다. 관리가 편함
• OS 패치, 프로비저닝 자동화
• 특정 시간 단위 백업 / 복구 지원
• 모니터링 대시보드 지원
• 읽기 전용 복제본 지원
• 재해 복구용 멀티 AZ
• 관리화면 제공
• 스케일링 용이
• EBS를 통한 스토리지 백업
• 인스턴스에 직접 접근 불가능

RDS 스토리지 Auto Scaling

• RDS 용량이 부족하면 스토리지를 자동으로 용량 증가
• Max Strorage Threshold를 설정해주면 최대 용량 설정 가능 (설정값과 요금은 무관)
• 예측이 어려운 워크로드에 유용
• 모든 종류의 RDS DB 엔진 지원

RDS 읽기 복제본과 읽기 스케일링

• 마스터의 쓰기 작업이 무거워서 write lock이 걸리면 read lock도 걸림.
• 장애 포인트가 될 수 있다.
• 읽기 복제본(Read Replica)을 두자
• 15대의 복제본 생성 가능
• 리전 / AZ 간 생성하거나, 동일 AZ에 생성한다.
• 복제본의 AZ 간 네트워크 비용은 발생하지 않음.
• 복제본의 리전 간 네트워크 비용은 발생함. (ex. 네이버 웹툰 업로드는 한국 본사에서만 하지만 읽는 것은 전세계 DB복제본에 뿌려주면 성능 향상. 그러나 네트워크 비용 발생)
• 비동기적 복제
• 궁극적 동일성(지금 당장은 다를 수 있지만 결과적으로는 동일해짐)
• 복제본이 마스터가 될 수 있다. (빠른 failover)
• 애플리케이션이 복제본이 연결하려면 connection string 업데이트 해줘야 함.

읽기 복제본 사용

• 집계 / 통계 역할 애플리케이션
• CQRS 구현 시
• 분석용 DB 구현
• 등등 읽기 전용

RDS 멀티 AZ 재해복구

• 동기화된 복사를 진행
• 한개의 DNS를 사용
• 고가용성을 위해 사용
• AZ에 문제가 생기거나, 네트워크 / 인스턴스 등에 문제가 생겼을 때를 대비
• 절대 Scaling을 위한 용도가 아닌, 재해복구의 용도

싱글 AZ에서 멀티 AZ로 전환하기

• 스냅샷 생성 -> 새로운 DB가 스냅샷 기반으로 복구 -> 동기화
• 다운타임 없음
• 수정 버튼 클릭 하나로 적용 가능

RDS 커스텀

• 관리형 오라클, MS SQL을 사용하는 경우, OS와 DB 파라미터(구성 방법)에 대한 커스텀 지원
• 관리형 DB에서 지원하는 자체 기능 수행 가능
• 이것조차도 내가 필요한 권한에 미치지 못하면 그냥 EC2에 올려서 써라.
• 자동 모드는 끄고 스냅샷을 미리 뜨는 것을 권장 (인프라 관련은 항상 스냅샷을 뜰 것)

RDS 백업

• 자동화된 백업 제공
  • 매일 전체 DB 스냅샷 남김
  • 트랜잭션 로그도 5분마다 백업
  • 트랜잭션 로그 기반으로 복구 가능
  • [1, 35]일까지의 데이터 저장
  • 0으로 설정하면 자동 백업하지 않음.
• 수동 스냅샷
  • 원하는 기간만큼 저장 가능

---

AWS Aurora

• 완전 관리형
• Postgres, My SQL 기반 엔진 제공 (이지만 My SQL, Postgres를 사용해서 새로운 엔진을 만든 거라고 봐야 한다.)
• AWS 클라우드 최적화
• RDS에 비해 성능이 높음 (mysql 기준 5배, postgre 기준 3배)
• 15개의 복제본 생성 가능
• 복제 생성도 빠름
• 고가용성
• 비쌈

고가용성과 읽기 스케일링

• 한개 Aurora 인스턴스가 쓰기 권한을 가짐 (마스터)
• 리전간 복제본 생성 지원
• 마스터가 장애 발생 시 30초 이내로 복구
• 데이터를 3개 AZ에 복사해서 저장
• 공유 볼륨을 사용하여 마스터가 쓰기 작업을 하면 공유 볼륨에도 같이 작성
• 레플리카들이 읽으면 공유 볼륨의 내용을 읽어 옴. (오토 스케일링이 빠르고, 장애 복구가 빠르고, 읽기 지연이 매우 짧음)

커스텀 엔드포인트

• 특정 읽기 복제본에 별도 엔드포인트 할당 가능
• 무거운 쿼리를 날리는 녀석들을 특정 엔드포인트에 보내면 나머지 복제본(인스턴스)들의 부하는 감소됨. (독박쓰기)

서버리스

• 사용량에 따라 자동 스케일링
• 동일한 양을 발생한다면 당연히 이게 더 비쌈
• 초당으로 비용 발생

Global Aurora

• 멀티리전 지원
• 리전간 읽기 복제본 지원
• 재해 복구에 유용
• 1개의 주요 리전과 5개의 부속 리전을 가짐
• 생성에 1초 미만
• 1초 이내의 지연 시간
• 부속 리전 당 16개의 읽기 복제본 생성 가능
• 주요 리전으로 승격(RTO)시키는 데에 1분 미만 소요

머신러닝

• ML 기반 예측 데이터를 SQL을 통해 추가할 수 있도록 지원
• AWS ML 서비스와 안전하고 효율적이고 단순하게 통합 가능
• SageMaker / Comprehend를 지원
• ML 경험이 없어도 쉽게 사용 가능

백업

• 자동화 백업 지원 (중지 불가능)
• 중지 불가능을 제외하면 일반 RDS와 자동화 백업 옵션 동일.
• 수동 백업 지원
• RDS와 옵션 동일

클론

• 신규 클러스터를 생성할 때 기존 클러스터를 통해 복제
• 스냅샷, 복구보다 빠름
• copy-on-write 프로토콜 사용 (기존 클러스터와 동일한 볼륨 사용, 이후부터의 데이터는 별도 스토리지 할당)
• 빠르고 비용적으로 효율적
• 스테이징 환경 구성 시에 유용함.

 

---

RDS 복구 및 마이그레이션

스냅샷

• 스냅샷을 기반으로 새로운 DB 생성 가능

S3

• RDS는 백업 파일을 S3에 넣고 불러오는 방식을 사용
• Aurora는 Percona XtraBackup과 같은 서드 파티 백업 툴을 사용 후, S3에 넣고 불러오기 (이 방식은 아마 mysql만 되는 것으로 추정)

---

보안

• DB 마스터와 복사본은 AWS KMS를 통해 암호화
• 마스터가 암호화가 안 됐다면 복사본도 암호화 불가능
• 스냅샷을 통해 복구할 때, 암호화 옵션을 켜서 암호화 가능
• TLS가 기본 적용됨 (AWS TLS 루트 인증서 사용)
• DB 접근을 위해 IAM role을 사용해야 함
• 보안 그룹을 통해 네트워크 보안 유지
• RDS Custom을 제외하고는 SSH 접근 불가 (EC2로 우회해서 접근하도록 하자)
• Audit 로그를 설정하고 Cloudwatch에 로그를 쌓을 수 있다.

---

RDS 프록시

• 애플리케이션이 DB 커넥션 공유 가능 (프록시로)
• 최소한의 커넥션만 유지하고 DB의 스트레스 감소
• 서버리스 / ASG / 멀티 AZ 등에서 사용할 것. (멀티 AZ는 경쟁 상태가 발생하고, 서버리스는 오버헤드가 커져서 그럼. 커넥션을 계속 연결했다 끊었다 하기 때문에 connection pool을 주는 것과 같음)
• 복구 시간을 66%쯤 향상 시킴 (대기 인스턴스가 줄어서 그런듯)
• 애플리케이션 내의 코드 변경은 불필요함. (connection string)
• IAM Secret Manager를 통해 관리
• 반드시 VPC를 통해 접근해야 함. (서버리스에서 RDS에 접근하려면 오버헤드가 커지니까 프록시를 사용해야 하는데, 프록시에 접근하려면 VPC를 통해 접근해야 하므로 람다를 VPC에 넣는 거였다.)