ABOUT ME

    -

    Today
    -
    Yesterday
    -
    Total
    -
    • RDS & Aurora & DynamoDB
      카테고리 없음 2023. 11. 20. 20:32

      RDS(Relational Data Service)

      • RDS: 관계형 데이터베이스 서비스(Relational Database Service)의 약자.
      • SQL을 쿼리 언어로 사용하는 데이터베이스용 관리형 데이터베이스 서비스.
      • AWS에서 관리되는 클라우드 상의 데이터베이스를 생성할 수 있도록 해줌.
        • Postgres
        • MySQL
        • MariaDB
        • Oracle
        • Microsoft SQL Server
        • Aurora (AWS Proprietary database)

       Advantage over using RDS versus deploying DB on EC2

      • RDS는 관리형 서비스이며, AWS는 데이터베이스 뿐만 아니라 다양한 서비스를 제공
        • 프로비저닝, 기본 운영체제 패치 자동화
        • 지속적인 백업과 특정 타임스탬프로의 복원 (특정 시점 복원)
        • 모니터링 대시보드
        • 읽기 성능 향상을 위한 읽기 전용 복제본
        • 재해 복구를 위한 다중 AZ 설정
        • 유지 관리 기간에 업그레이드 가능
        • 수직 및 수평 스케일링 기능
        • EBS(gp2 또는 io1)로 지원되는 스토리지
      • 한 가지 단점은, RDS 인스턴스에 SSH로 접속할 수 없음

      RDS – Storage Auto Scaling

      • Helps you increase storage on your RDS DB instance dynamically
      • 데이터베이스 스토리지가 부족해지고, RDS 스토리지 Auto Scaling 기능이 활성화되어 있으면 RDS가 이를 감지하여 자동으로 스토리지를 확장해 줌.
      • 데이터베이스 스토리지를 수동으로 스케일링하는 작업을 피할 수 있음.
      • ✅ 최대 스토리지 임계값(스토리지의 최대 제한)을 설정
      • 다음의 경우에 자동으로 스토리지를 수정
        • 스토리지의 남은 공간이 10% 미만인 경우
        • 스토리지 부족 상태가 5분 이상 지속
        • 마지막 수정 이후 6시간이 지난 경우
      • 워크로드를 예측할 수 없는 애플리케이션에서 유용
      • 모든 RDS 데이터베이스 엔진 (MariaDB, MySQL, PostgreSQL, SQL Server, Oracle)을 지원.

      RDS Read Replicas for read scalability

      • 읽기 전용 복제본을 최대 15개까지 생성 가능
      • 동일한 가용 영역 또는 가용 영역이나 리전을 걸쳐 생성 가능
      • ✅ 복제는 비동기 방식으로 진행 (기본 스토리지에 데이터를 쓴 다음 복제본에 데이터를 복사)
      • 즉, 읽기가 일관적으로 유지
      • 복제본은 자체 데이터베이스로 승격될 수 있음.
      • 읽기 전용 복제본을 사용하려는 경우에는 주요 애플리케이션은 모든 연결을 업데이트 해야하며 이를 통해 RDS 클러스터 상의 읽기 전용 복제본 전체 목록을 활용할 수 있음

      Network Cost


      AWS에서는 데이터가 한 AZ에서 다른 AZ로 이동할 때 네트워크 비용이 발생한다.

      💗 하지만, 동일한 리전 내에서의 RDS 읽기 전용 복제본에 대해서는 해당 비용을 지불하지 않는다.

      RDS Multi AZ (Disaster Recovery)

       

      • 동기식 복제
      • 하나의 DNS 이름 - automatic app failover to stanby
      • 가용성 향상
      • AZ 손실, 네트워크 손실, 인스턴스 또는 스토리지 장애 발생 시 페일오버 - 스탠바이 데이터베이스가 새로운 마스터가 될 수 있도록 함.
      • 애플리케이션에 수동으로 조치를 취할 필요가 없음.
      • 스케일링에는 사용되지 않음
      • 내부적으로는 다음이 수행됨.
        • 기본 데이터베이스의 RDS가 자동으로 스냅샷 생성
        • 이 스냅샷에서 새로운 DB가 새로운 가용 영역에 복원됨
        • 두 개의 데이터베이스 간에 동기화가 설정

       

      Multi AZ(다중 AZ 구성 배포)란?

      다중 AZ 구성은 현재 서비스되는 RDB에 문제가 생겨도 다른 AZ에 있는 RDB로 빠르게 장애 복구를 시킴으로써 가용성 및 내구성을 높여주므로 프로덕션 데이터베이스 워크로드에 적합하다. 다중 AZ설정시 AZ별 인스턴스에는 마스터 DB로부터 Sync 복제가 일어난다. 여러개의 RDS이지만, 하나의 DNS만 바라본다. 즉, 하나의 DNS 이름으로 통신하여 마스터 DB에 문제가 생기면 자동으로 Stanby DB로 DNS를 옮겨 장애조치를 취하는 것이다. 이때 Stanby DB에는 DNS가 없어서 접근 불가능하다. read replica도 다중 AZ로 생성할 수 있다. 이를 통해 단일 AZ와 다르게, 다운타임이 없으므로 DB를 중지시킬 필요가 없으며 서로 동기적 복제를 한다.

       

       

      Multi AZ와 Read Replica/Auto scaling의 차이점?

      multi AZ는 active - active가 아닌 active - standby이며 고가용성을 위해 장애를 대비하는 용도로 쓰인다. 

       

      cf. active - standby는 하나의 서버가 대기 상태에 있는 것을 말하며, active - active는 여러개의 자원이 동시에 서비스 되는 것을 말한다. 

      Aurora

      • Aurora는 AWS 고유 기술로 오픈 소스 X
      • Postgres와 MySQL이 호환
      • Aurora는 "AWS 클라우드 최적화"되었으며, RDS의 MySQL에 비해 5배 높은 성능이고, RDS의 Postgres에 비해 3배 높은 성능.
      • Aurora 스토리지는 자동으로 10GB 단위로 증가하며, 최대 128TB까지 확장할 수 있음.
      • Aurora는 최대 15개의 복제본을 가질 수 있으며, 복제 과정은 MySQL보다 빠름 (10ms 미만의 복제 지연).
      • 페일오버(Failover)는 즉시 이루어지고 가용성이 높음.
      • 비용은 RDS에 비해 약 20% 정도 높지만 스케일링 측면에서 훨씬 효율적임.

       

      Aurora High Availability and Read Scaling

      • 3개의 가용영역에 걸쳐 6개의 데이터 복사본을 저장
        • 쓰기 작업을 위해서는 6개의 사본 중 4개만 있으면 됨. (즉, AZ 하나가 작동하지 않아도 괜찮음.)
        • 읽기 작업을 위해서는 6개의 사본 중 3개만 있으면 됨. (즉, 읽기 가용성이 높음.)
        • 백엔드에서 P2P(peer-to-peer) 복제를 통한 자가 복구 진행
        • 단일 볼륨에 의존하지 않고 수 백 개의 볼륨 사용함
      • 하나의 Aurora 인스턴스가 쓰기 작업을 수행함. (master)
      • 마스터의 자동 장애 조치(failover)는 30초 이내에 이루어짐.
      • 마스터 외에 읽기를 제공하는 읽기 전용 복제본을 15개까지 둘 수 있음.
      • ✅ Cross Region 복제 지원
      • 마스터는 하나, 복제본은 여러 개, 스토리지 복제, 작은 블록 단위로 자가 복구 또는 확장이 일어남

      Aurora의 작동방식은?

      클라이언트가 있을 때 수많은 인스턴스와 어떻게 접속하는지

      • 마스터가 수정될 수 있으므로 writer 엔드포인트를 제공
      • 클라이언트는 Writer Endpoint로 마스터 베이스에 접근할 수 있다
      • 읽기 전용 복제본을 자동 스케일링 설정하면 적절한 수의 복제본이 항상 존재할 수 있다
      • 다만 앱 입장에서는 복제본과 URL, DB를 어떻게 연결하는지 파악이 어려울 수 있다
      • 따라서 Reader Endpoint를 제공한다
        • 커넥션 로드 밸런싱과 모든 읽기 전용 복제본과 자동 연결
        • 로드 밸런싱은 연결 레벨에서 이루어진다

       

      복제본 자동 스케일링이란?

       

      Reader 엔드포인트로 많은 요청이 들어오면 자동 스케일링 하여 트래픽을 분산시킨다. 

       

       Aurora – Custom Endpoints

      • 일부 Aurora 인스턴스를 사용자 지정 엔드포인트로 정의할 수 있음.
      • ex. 특정 복사본에서 분석 쿼리를 실행.
      • 사용자 지정 엔드포인트를 정의한 후에는 일반적으로 Reader 엔드포인트는 사용되지 않음.

      Aurora Multi-Master

      • 쓰기 노드의 즉각적 장애 조치(failover)가 필요한 경우. (쓰기 노드에 높은 가용성을 갖추고자 할 때)
      • Aurora 클러스터의 모든 노드에서 읽기 및 쓰기를 수행
      • 읽기 전용 복제본을 새로운 마스터로 승격하는 것과는 다르다

      Global Aurora

      Aurora Cross Region Read Replicas

      • 재해 복구에 유용
      • 간단하게 구성 가능

      Aurora Global Database (recommended)

      • 하나의 기본 리전 (읽기 / 쓰기 모두 가능)
      • 최대 5개의 읽기 전용 리전. 복제 지연이 1초 미만.
      • 각 보조 리전당 최대 16개의 읽기 전용 복사본 생성 가능
      • 지연 시간을 줄이는 데 도움됨.
      • 재해 복구 목적으로 다른 리전을 승격하는데 필요한 복구 시간 목표(RTO)는 1분 미만.
      • ✅ 리전에 걸쳐 데이터를 복제하는데 걸리는 시간은 평균 1초 미만

       

       

      RDS & Aurora security

      • 저장된 데이터 암호화 가능 → 볼륨에 암호화 된다
      • KMS를 사용해 마스터와 모든 복제본의 암호화가 이루어지고 처음 실행할 때 정의된다
      • 메인 DB를 암호화하지 않았다면 읽기 전용 또한 암호화 불가
      • 암호화 되지 않은 기존 db를 암호화 하려면 암호화 되지 않은 db의 스냅샷을 가져와 암호화된 형태로 데이터베이스 스냅샷을 복원하야 한다
        • 기존 db 스냅샷 생성 → 복원하는 과정에서 암호화를 시켜야 함
      • 전송 중 암호화 : 클라이언트와 DB간 암호화 TLS 기능이 기본. 클라이언트는 AWS에서 제공하는 TLS 루트 인증서를 사용해야 함
      • IAM 인증 : IAM 역할을 사용해서 DB 접근 가능
      • 보안 그룹: 네트워크 엑세스 통제 가능 포트, IP 차단
      • ssh 불가능하지만 RDS를 커스텀 하면 가능
      • audit log를 통해 어떤 쿼리가 실행되는지 확인 가능하며 장기간 보관도 가능

      Backups

      RDS Backups

      자동 백업

      • 매일 자동으로 데이터베이스 유지 관리 시간에 데이터베이스 전체 백업
      • 매 5분마다 트랜잭션 로그 백업
        • 가장 오래된 백업부터 5분 전 백업까지 어느 시점으로도 복원 가능
      • 자동 백업 보유 기간은 1일부터 35일까지 설정 가능. 이 기능을 비활성화하면 0으로 설정하면 됨.

      수동 DB 스냅샷

      • 사용자가 수동으로 트리거해야 함
      • 원하는 기간 동안 백업을 보존함

      팁: 중지된 RDS 데이터베이스에서도 여전히 스토리지 비용이 발생한다. 따라서 오랜 기간 중지할 계획이 있다면 스냅샷을 생성하고 원본 데이터베이스는 삭제한 뒤 DB가 필요할 때에 스냅샷을 복원하는 것이 좋다.

      Aurora Backups

      자동 백업

      • 1일부터 35일까지 (비활성화 불가능)
      • 지정 시간 복구 기능 - 정해진 시간 범위 내의 어느 시점으로도 복구 가능

      수동 DB 스냅샷

      • 사용자가 수동으로 트리거
      • 원하는 기간동안 백업 보유 가능

      Aurora Database Cloning

      • 기존 데이터베이스로부터 새로운 Aurora DB 클러스터 생성
      • ✅ 스냅샷 및 복원보다 빠름
      • 새 DB 클러스터는 원래 클러스터와 동일한 클러스터 볼륨과 데이터를 사용하며, 데이터 업데이트가 끝나면 변경
      • 데이터베이스 복제는 매우 빠르고 비용 면에서 효율적
      • ✅ 프로덕션(production) 데이터베이스에 영향을 주지 않고 스테이징(staging) 데이터베이스를 생성하는데 유용

      Amazon RDS Proxy

      • Fully managed database proxy for RDS
      • 애플리케이션이 데이터베이스 내에서 데이터베이스 연결 풀을 형성하고 공유할 수 있음. (애플리케이션을 RDS DB 인스턴스에 일일이 연결하는 대신 프록시에 연결하면 프록시가 하나의 풀에 연결을 모아서 RDS DB 인스턴스로 연결함)
      • 데이터베이스 리소스에 가해지는 부하를 줄이고 (ex. CPU, RAM), 데이터베이스에 개방된 연결과 타임아웃을 최소화하여 데이터베이스의 효율성을 향상
      • RDS 프록시는 완전한 서버리스로 오토 스케일링이 가능해 용량을 관리할 필요가 없고 가용성이 높음. 다중 AZ도 지원.
      • RDS와 Aurora의 장애 조치 시간을 66%까지 줄일 수 있음
      • RDS (MySQL, PostgreSQL, MariaDB, MS SQL Server) 및 Aurora (MySQL, PostgreSQL)를 지원
      • 애플리케이션의 코드를 변경하지 않아도 됨
      • DB에 대한 IAM 인증을 강제함으로써 IAM 인증을 통해서만 RDS DB 인스턴스에 연결할 수 있음. 이때 자격 증명은 AWS Secrets Manager에 안전하게 저장됨.
      • ✅ RDS 프록시는 퍼블릭 액세스가 절대 불가능 (VPC에서만 접근 가능)

      ElastiCache

      • RDS와 동일한 방식으로 관계형 데이터베이스를 관리할 수 있음
      • ElastiCache는 Redis 또는 Memcached와 같은 캐시 기술을 관리할 수 있도록 함.
      • Cache: 매우 높은 성능과 낮은 지연 시간을 가진 인메모리 데이터베이스
      • 읽기 집약적인 워크로드에서 데이터베이스의 부하를 줄이는데 도움
      • 애플리케이션을 stateless로 만드는데 도움이 됨
      • AWS는 OS 유지 관리/패치, 최적화, 설정, 구성, 모니터링, 장애 복구 및 백업을 처리
      • ElastiCache를 사용하는 것은 애플리케이션 코드 변경이 많이 필요

      DB Cache

      • 애플리케이션은 ElastiCache에 쿼리를 보내고, ElastiCache에 데이터가 없는 경우 RDS에서 가져와 ElastiCache에 저장.
      • RDS의 부하를 완화하는 데 도움
      • 캐시는 가장 최신 데이터만 사용되도록 만료 전략(invalidation strategy)을 가져야 함

      Redis vs Memcached

      Redis

      • 자동 장애 조치(Auto-Failover)를 위한 Multi AZ
      • 읽기 스케일링에 사용되며 가용성이 높은 읽기 전용 복제본
      • AOF 지속성을 통한 데이터 내구성
      • 백업 및 복원 기능
      • 세트(Sets)와 정렬 세트(Sorted Sets)를 지원함

      Memcached

      • 데이터 파티셔닝(sharding)을 위한 다중 노드 사용
      • 가용성이 높지 않고 복제도 발생하지 않음
      • 지속적인 캐시가 아님
      • 백업 및 복원 기능이 없음
      • 멀티스레드 아키텍처

      Cache Security

      • ElatiCache의 모든 캐시는
        • IAM 인증을 지원하지 않음
        • ElastiCache에서 정의할 IAM 정책은 AWS API 수준의 보안에서만 사용
      • Redis AUTH
        • Redis 클러스터를 생성할 때 비밀번호나 토큰을 설정할 수 있음
        • 캐시에 사용할 수 있는 보안 그룹에 대한 추가적인 수준의 보안
        • 전송 중 암호화를 위해 SSL 보안을 지원할 수 있음
      • Memcached
        • 좀 더 높은 수준인 SASL 기반 인증을 지원
    Designed by Tistory.

    티스토리툴바