RDS & Aurora

백업과 모니터링

• RDS 백업
  • RDS 백업은 DB 백업 기간동안 자동화로 전체 백업
    5분마다 트랜잭션 로그 백업 -> 가장 빠른 백업 = 5분전 백업
    백업 보존 기간: 1~35일(0으로 설정하면 비활성화)
  • 수동 DB 스냅샷
    사용자가 수동으로 트리거
    장점: 원하는 기간동안 유지할 수 있다.
    자동 백업 = 만료 기간이 있음, 수동 백업 = 삭제하기전까지 남아있음
  • 백업 시기
    내가 원할때 백업할수 있지만 비용을 줄이기위해 백업하기도 함
    • RDS DB가 있고 한달에 2시간만 사용한다면
      DB를 중지하더라도 스토리지 비용은 계속 지불
      그래서 2시간만 사용 후 스냅샷을 만든 다음, DB를 삭제하면 스냅샷이 실제 스토리지보다 저렴하기 때문에 비용을 절약할 수 있다.
• Aurora 백업
  • RDS와 동일하게 자동화로 전체 백업
    1~35일 기간설정 가능(비활성화 불가능)
    시점 복구 기능(해당 기간 어느 시점으로든 이동 가능)
  • 수동 DB 스냅샷
    사용자가 수동으로 트리거
    장점: 원하는 기간동안 유지
• RDS & Aurora 복원 옵션
  • RDS & Aurora의 백업/스냅샷은 같다
    새 DB로 복원 가능
  • S3에서 MySQL를 복원할 수 있다.(RDS)
    온프레미스 DB의 백업을 생성한 후 S3에 배치
    RDS에는 MySQL을 실행하는 새 인스턴스로 S3에서 백업 파일을 복원하는 옵션이 있다.
  • MySQL Aurora 클러스터로 복원할 수 있다.(Aurora)
    온프레미스 DB를 다시 백업하면 된다.(Percona XtraBackup이라는 프로그램을 통해)
    -> Percona XtraBackup의 백업 파일을 S3로 보내 백업을 복원
  • 차이점
    RDS = MySQL로 복원할 때는 DB의 백업만 있으면 된다.
    Aurora = Percona XtraBackup로 백업 후 S3에서 백업.

Aurora DB 복제

• 기존 DB 클러스터에서 새로운 Aurora DB 클러스터를 생성 가능하다.
  테스트하고 싶을때 사용
  스냅샷 찍고 복우너하는 것보다 빠르다.
  • 왜?
    복제는 copy-on-write 프로토콜을 사용하기 때문
  • 과정
    처음 복제본을 만들 때는 원본 DB 클러스터와 동일한 데이터 볼륨을 사용하게 된다. -> 데이터를 복사 하는것이 아니기 때문에 빠르고 효율적
    프로덕션 Aurora DB 또는 스테이징 Aurora DB에 업데이트가 이루어지면 새로운 추가 스토리지가 할당되고, 데이터 복사 및 분리된다.
    
    DB 복제는 빠르고 비용 효율적이고, 프로덕션 DB에 영향을 주지 않고, 프로덕션 DB를 복제하는데 매우 유용
    스냅샷과 복원 기능이 필요 없다.

RDS & Aurora 보안

• RDS & Aurora DB에 암호화할 수 있다.
  DB를 처음 실행할 때 KMS를 사용해 마스터와 모든 복제본을 암호화
  마스터를 암호화하지 않으면 복제본도 암호화할 수 없다.
  DB를 만들고 암호화를 하고 싶다면 스냅샷을 찍고 암호화해서 복원해라.
• DB와 클라이언트간 전송 중 데이터 암호화
  클라이언트는 AWS에서 제공하는 TLS 루트 인증서를 사용해야한다.
  • DB 인증
    사용자 이름과 패스워드로 인증
    IAM 역할을 이용해 인증
• 보안 그룹
  DB에 대한 네트워크 액세스를 통제
  -> 특정 포트, IP, 보안 그룹을 허용/차단
• RDS & Aurora는 SSH 액세스할 수 없다.
  관리형 서비스가 있기 때문
  예외) AWS의 RDS 커스텀 서비스를 사용한다면 예외이다.
• 감사 로그
  시간에 따라 RDS & Aurora에서 어떤 쿼리가 생성되고, DB 확인가능.
  시간이 지나면 자동으로 삭제된다.(장기보관은 CloudWatch Logs 이용)

RDS 프록시

VPC내에 RDS DB를 배포 가능했었다.
또한 완전 관리형 RDS DB 프록시도 배포할 수 있다.

• 프록시가 필요한 이유
  • 애플리케이션이 DB 내에서 DB 연결 풀을 형성하고 공유할 수 있게 된다.
    애플리케이션을 RDS 인스턴스에 일일이 연결하는 대신 프록시를 통해 하나의 풀로 RDS 인스턴스로 연결
    • RDS 인스턴스에 연결이 많아지면?(시험)
      CPU와 RAM등 DB 자원을 효율적으로 사용하게 되고,
      DB에 개방된 연결과 시간초과를 최소화할 수 있다.
• RDS 프록시는 완전한 서버리스이다.
  오토 스케일링이 가능해 용량을 관리할 필요가 없다.
  가용성이 높음.
  다중 AZ 지원
• 장애 조치(시험)
  RDS 기본 인스턴스가 아니라 대기 인스턴스로 실행되고 RDS 프록시를 통해 장애 조치 시간을 66% 줄인다.
  -> 메인 RDS 인스턴스에 장애 조치를 처리하지않고 RDS 프록시에 연결해 장애 조치.
• 지원하는 DB
  MySQL, PostgreSQL, MariaDB용 RDS 지원
  MySQL, PostgreSQL용 Aurora 지원
• 애플리케이션의 코드를 변경하지 않아도 되고 RDS & Aurora에 연결하는 대신 RDS 프록시에 연결하기만 하면된다.
• RDS 프록시는 DB에 IAM 인증을 강제함으로써 IAM으로만 연결하도록 할 수 있다.
  이때 자격증명은 AWS Secret Manager 서비스에 저장된다.
• RDS 프록시는 퍼블릭 액세스가 절대로 불가하다.
  VPC 내에서만 액세스 가능.(보안 굿)
• 람다 함수를 사용할때 RDS 프록시가 아주 유용
  람다 함수는 증식: 짧은 시간에 늘어났다 줄어들었다 한다.
  RDS에 접근할떄 람다를 사용하면 정신없으니 RDS 프록시를 사용해 하나의 풀로 RDS에 접근.