[5일차] RDS + Aurora + ElastiCache

soyeon·2023년 3월 29일
0

SAA

목록 보기
5/6
post-thumbnail

Amozon RDS(Relational Database Service)

: '관계형 데이터베이스 서비스'

SQL을 쿼리 언어로 사용하는 데이터베이스용 관리형 데이터베이스 서비스이다.
SQL은 데이터베이스를 쿼리하는 구조화된 언어로 적합하고, 많은 엔진 실행에 사용된다.
클라우드의 RDS 서비스에 DB를 생성할 수 있고 AWS가 DB를 관리하므로 누릴 수 있는 혜택이 많다.

  • AWS가 관리하는 DB 엔진의 유형
    : PostgreSQL, MySQL, MariaDB, Oracle Microsoft SQL Server, Aurora

RDS 장점 & 단점

  • 장점
    : 데이터베이스 뿐만 아니라 다양한 서비스를 제공한다.
    - 데이터베이스 프로비저닝과 기본 운영체제 패치가 자동화되어 있다.
    - 지속적으로 백업이 생성되므로 특정 시점으로 복원할 수 있다.
    - 데이터베이스의 성능을 대시보드에서 모니터링할 수 있다.
    - 읽기 전용 복제본을 활용해 읽기 성능을 개선할 수 있다.
    - 재해 복구 목적으로 다중 AZ를 설정할 수 있다.
    - 수직확장, 수평확장이 가능하다.
    - 파일 스토리지는 EBS에 구성된다.(gp2, io1)

  • 단점
    - RDS 인스턴스에 SSH로 접속할 수 없다.

RDS - Storage Auto Scaling

데이터베이스를 많이 사용하면 공간이 부족해질 수 있다.

RDS 스토리지 오토 스케일링 기능이 활성화되어 있으면 RDS가 이를 감지해서 자동으로 스토리지를 확장해 준다. 스토리지 용량을 늘리기 위해 DB를 다운시키는 등의 작업을 할 필요가 없다.

애플리케이션이 RDS 데이터베이스에서 읽기와 쓰기 작업을 많이 하면 임곗값에 도달하게 되고 RDS가 자동으로 스토리지를 오토 스케일링한다.

이를 위해 최대 스토리지 임곗값을 설정해야 한다. 할당된 용량에서 남은 공간이 10% 미만이 되면 스토리지를 자동으로 수정한다.

워크로드를 예측할 수 없는 애플리케이션에서 굉장히 유용하다.

모든 RDS 데이터베이스 엔진에서 지원되는 기능이다.(MariaDB, MySQL PostgreSQL, SQL Server)

RDS Read Replicas for read scalability

: 읽기를 스케일링한다.

애플리케이션과 RDS 데이터베이스 인스턴스가 있다. 애플리케이션은 데이터베이스 인스턴스에 대해 읽기와 쓰기를 수행한다. 하지만 주된 데이터베이스 인스턴스가 너무 많은 요청을 받아서 충분히 스케일링할 수가 없어서 읽기를 스케일링하고자 한다.

  • 읽기 전용 복제본은 최대 다섯 개까지 생성할 수 있다.
  • 동일한 가용 영역 또는 다른 가용 영역이나 리전을 걸쳐서 생성될 수 있다.
  • 주된 RDS 데이터베이스 인스턴스와 읽기 전용 복제본 사이에 비동기식 복제가 발생한다.
  • 읽기 전용 복제본을 데이터베이스로 승격시켜 이용할 수 있다.

Read Replicas - Use Cases

평균적인 로드를 감당하고 있는 생산 데이터베이스가 있다. 생산 데이터베이스에서는 메인 RDS 데이터베이스 인스턴스에 대한 읽기 및 쓰기가 수행된다.

이때 새로운 팀 이 데이터를 기반으로 몇 가지 보고와 분석을 실시하고자 한다고 한다. 보고 애플리케이션을 메인 RDS 데이터베이스 인스턴스에 연결하면 오버로드가 발생하고 생산 애플리케이션의 속도가 느려진다.
➡️ 새로운 워크로드에 대한 읽기 전용 복제본을 생성한다.

읽기 전용 복제본이 있는 경우에는 SELECT 명령문만 사용할 수 있다.

Read Replicas - Network Cost

AWS에서는 하나의 가용 영역에서 다른 가용 영역으로 데이터가 이동할 때에 비용이 발생한다. 하지만 관리형 서비스에서는 예외가 존재한다.

  • 읽기 전용 복제본이 다른 AZ이지만 동일한 리전 내에 있을 때는 비용이 발생하지 않는다.
  • 서로 다른 리전에 복제본이 존재하는 경우 비용이 발생한다.

RDS Multi AZ(Disaster Recovery)

다중 AZ는 주로 재해 복구에 사용된다.

전체 AZ 또는 네트워크가 손실될 때에 대비한 장애 조치로, 마스터 데이터베이스의 인스턴스 또는 스토리지에 장애가 발생할 때 스탠바이 데이터베이스가 새로운 마스터가 될 수 있도록 한다.

스탠바이 데이터베이스는 단지 대기 목적 하나만 수행한다. 그 누구도 이를 읽거나 쓸 수 없다.

Single Az → Multi AZ

: 다운타임이 전혀 없는지 확인해야 한다.
즉 단일 AZ에서 다중 AZ로 전환할 때에 데이터베이스를 중지할 필요가 없다.

RDS Custom

RDS에서는 기저 운영 체제나 사용자 지정 기능에 액세스할 수 없다.
그러나 RDS Custom에서는 가능하다.

  • Oracle과 Microsoft SQL Server에서 사용 가능하다.
  • 내부 설정 구성, 패치 적용 그리고 네이티브 기능 활성화가 가능하다.
  • SSH 또는 SSM 세션 관리자를 사용해서 RDS 뒤에 있는 기저 EC2 인스턴스에 액세스할 수 있다.
  • 사용자 지정 설정을 사용하려면 RDS가 수시로 자동화, 유지 관리 또는 스케일링과 같은 작업을 수행하지 않도록 자동화를 꺼두는 것이 좋다.
  • 데이터베이스 스냅샷을 만들어 두는 것이 좋다.

Amazon Aurora

  • AWS 고유의 기술(오픈소스는 아니다.)
  • Postgres 및 MySQL과 호환된다.
    클라우드에 최적화되어 있고, RDS의 MySQL보다 5배 높은 성능, RDS의 Psostgres보다는 3배 높은 성능을 보인다.
  • 스토리지는 자동으로 확장된다.(10GB에서 시작하지만 데이터를 넣을수록 자동으로 128TB까지 커진다.)
  • 읽기 전용 복제본은 15개까지 둘 수 있다.
  • 복제 속도도 훨신 빠르다.
  • 비용은 RDS에 비해 약 20% 높지면 스케일링 측면에서 훨씬 더 효율적이다.
  • 장애 조치가 빠르다.

Aurora DB Cluster

Aurora Replicas - Auto Scaling

아래 그림을 보면, 클라이언트가 있고 세 개의 Aurora 인스턴스가 있다. 하나는 라이터 엔드포인트를 통해 쓰고 있고 나머지 둘은 리더 엔드포인트를 통해 읽고 있다.

그런데, 리더 엔드포인트의 읽기 요청이 매우 많아서 CPU 사용량이 증가하고 있다.

➡️ 복제본 자동 스케일링을 설정하면 된다.

Amazon Aurora 복제본이 추가되고, 새로운 복제본을 처리하기 위해 자동으로 리더 엔드포인트가 연장된다. 새로운 복제본들이 트래픽을 받게 되고 읽기가 좀 더 분산된 형태로 이루어지게 된다.

Aurora - Custom Endpoints

이번에는 두 종류의 다른 복제본이 있다. 일부 복제본은 다른 복제본보다 크기가 크다.

이렇게 하는 이유는 Aurora 인스턴스의 서브셋을 사용자 지정 엔드포인트로 정의하기 위해서이다.

이 인스턴스들이 더 강력해서 이 특정 복제본에서 분석 쿼리를 실행하는 게 더 낫기 때문이다.

사용자 지정 엔드포인트가 있으면 리더 엔드포인트는 사용하지 않는다. 사라지는 않지만 더 이상 사용하지 않게 된다.

Aurora Serverless

실제 사용량에 기반자동 데이터베이스 인스턴스화와 자동 스케일을 가능하게 해준다.

  • 비정기적, 간헐적, 또는 예측 불허한 워크로드에 유용하다.
  • 용량 계획을 세울 필요가 없다.
  • 각 Aurora 인스턴스에 대해 매 초당 비용을 지불하게 된다.
    비용 면에서 훨씬 더 효율적이다.

Aurora Multi-Master

라이터 노드에 대한 즉각적 장애 조치라이터 노드에 높은 가용성을 갖추고자 할 때 사용한다.

  • Aurora 클러스터의 모든 노드에서 읽기 및 쓰기가 가능하다.

Global Aurora

Aurora 리전 간 복제본은 재해 복구에 많은 도움이 되며 간단하게 생성이 가능하다.

최근에는 Aurora Global 데이터베이스를 만드는 것을 권장하고 있다.

  • 모든 쓰기 및 읽기가 진행되는 하나의 기본 리전이 있다.
  • 복제 지연이 1초 미만인 보조 읽기 전용 리전을 다섯 개까지 설정할 수 있고, 각 보조 지역마다 읽기 전용 복제본을 16개까지 생성 가능하다.
  • 한 리전의 데이터베이스가 작동 중단될 경우 재해 복구 목적으로 다른 지역을 승격하는데 필요한 RTO(복구 시간 목표)는 1분 미만이다.
  • 리전에 걸쳐 데이터를 복제하는데 걸리는 시간은 평균 1초 미만이다.

Aurora Machine Learning

Aurora는 AWS 내의 머신 러닝 서비스와의 통합을 지원한다.

RDS Backups

  • Automated Backup(자동 백업)
    자동으로 매일 데이터베이스가 유지 관리 시간에 데이터베이스 전체를 백업한다.
    5분마다 트랜잭션 로그도 백업된다.
    자동 백업 보유 기간은 1~35일까지 설정할 수 있다. 이 기능을 비활성화하려면 0으로 설정하면 된다.

  • Manual DB Snapshots(수동 DB 스냅샷 생성)
    사용자가 수동으로 트리거해야 한다.
    원하는 만큼 오랫동안 보유할 수 있다.

💡 비용 절감 방법
매달 2시간만 사용할 예정인 RDS 데이터베이스가 있다면, 2시간 사용 후에 스냅샷을 만들고 원본 데이터베이스는 삭제한다. 데이터베이스를 다시 사용할 대가 되면 스냅샷을 복원해서 사용하면 된다.

Aurora Backups

  • Automated Backup(자동 백업)
    자동으로 매일 데이터베이스가 유지 관리 시간에 데이터베이스 전체를 백업한다.
    자동 백업 보유 기간은 1~35일까지 설정할 수 있다. 비활성화 할 수 없다.

  • Manual DB Snapshots(수동 DB 스냅샷 생성)
    사용자가 수동으로 트리거해야 한다.
    원하는 만큼 오랫동안 보유할 수 있다.

RDS & Aurora Restore Options

  • RDS 및 Aurora 백업 또는 스냅샷을 새로운 데이터베이스로 복원한다.
    자동 백업이나 수동 스냅샷을 복원할 때마다 새로운 데이터베이스가 생성된다.

  • S3로부터 MySQL RDS 데이터베이스를 복원한다.

    • 온프레미스 데이터베이스의 백업을 만들어서 객체 스토리지인 Amazon S3에 둔다.
    • RDS에는 Amazon S3에서 MySQL를 실행 중인 새로운 RDS 인스턴스로 백업 파일을 복원하는 방법이 있다.
  • S3로부터 MySQL Aurora 클러스터를 복원한다.

    • 온프레미스 데이터베이스를 외부로 백업한다.(Percona XtraBackup 사용)
    • Percona Xtrabackup의 백업 파일이 Amazon S3로 전송된다.
    • 백업 파일을 MySQL을 실행 중인 새 Aurora 클러스터로 복원하면 된다.

Aurora Database Cloning

기존의 데이터베이스로부터 새로운 Aurora DB 클러스터를 만들 수 있다.
프로덕션 데이터베이스에 영향을 주지 않고 개발 또는 테스트를 수행할 수 있다.
매우 빠르고 비용 면에서 효율적이다.

Amazon ElastiCache

RDS와 동일한 방식으로 관계형 데이터베이스를 관리할 수 있다.

레디스 또는 멤캐시트와 같은 캐시 기술을 관리할 수 있도록 한다.

애플리케이션의 상태를 Amazon 일래스틱 캐시에 저장해 애플리케이션을 무상태로 만들 수 있다.

Redis vs Memcached

  • Redis
    레디스(Redis)는 자동 장애 조치로 다중 AZ를 수행하는 기술
    읽기 전용 복제본은 읽기 스케일링에 사용되며 가용성이 높다.
    백업과 기능 복원 기능도 있다.

  • Memcached
    데이터 분할에 다중 노드를 사용한다.
    가용성이 높지 않고 복제도 발생하지 않는다.
    지속적인 캐시가 아니다.
    백업과 복원 기능도 없다.

0개의 댓글