Amazon RDS

Jong Eun Lee·2024년 6월 4일
amazon rdsaws
0

AWS

목록 보기
14/21

RDS는 Relational Database Services의 약며로 Amazon에서 제공하는 관리형 관계형 데이터베이스이며 데이터베이스의 버전 업데이트, 보안, 가용성 등을 AWS에서 관리합니다. 따라서 온프레미스나 EC2 인스턴스에서 자체 DB를 구축하는 것보다 간편하게 구축, 운영, 확장이 가능합니다. Amazon RDS는 6개의 DB 엔진을 지원하여 사용자가 원하는 DB엔진을 선택할 수 있습니다.

  • Amazon RDS 종류
    • Postgres
    • MySQL
    • MariaDB
    • Oracle
    • Microsoft SQL Server
    • Aurora - AWS 소유의 데이터베이스

온프레미스 vs Amazon EC2 인스턴스 vs Amazon RDS

기능온프레미스 관리Amazon EC2 관리Amazon RDS 관리
애플리케이션 최적화고객고객고객
확장성고객고객AWS
높은 가용성고객고객AWS
데이터베이스 백업고객고객AWS
데이터베이스 소프트웨어 패치고객고객AWS
데이터베이스 소프트웨어 설치고객고객AWS
OS 패치고객고객AWS
OS 설치고객고객AWS
서버 유지 관리고객AWSAWS
하드웨어 수명고객AWSAWS
전력, 네트워크 및 냉각고객AWSAWS

위의 표와 같이 온프레미스나 EC2 인스턴스에 자체 DB를 구축하는 것보다 RDS에 구축할 때 유리한 점은 DB 프로비저닝과 OS 패치 자동화, 유지관리 업데이트 지원, 백업 자동화, 수평 확장의 용이성, 다중 AZ 설정을 통한 고가용성 및 재해 복구 지원, DB 모니터링 데시보드 지원이 있습니다. 이 장점들은 DB를 구축, 운영에 있어 사용자의 부담을 줄여 주고 업무 효율을 높여 줄 수 있습니다. 일반적으로 RDS는 RDS가 실행 중인 인스턴스에 SSH 액세스가 불가능해서 내부 설정 구성이나 패치 적용을 사용자가 수행할 수 없습니다.
RDS가 온프레미스나 EC2 인스턴스에 구축한 DB와 가장 많이 차이나는 점은 오토스케일링입니다. DB의 용량이 부족할 경우 스토리지를 확장하고 이 과정을 자동화하여 확장하는 중에도 다운타임 없이 사용이 가능하고 스토리지의 확장 상한을 설정하여 스토리지 무한 확장을 방지할 수도 있어 워크로드를 예측할 수 없는 애플리케이션에 유용합니다.

  • 오토 스케일링이 동작하는 경우
    • 남은 용량이 10%미만일 때
    • 스토리지 부족 상태가 5분 이상 지속될 때
    • 마지막 수정으로부터 6시간이 지났을 경우

RDS Read Replicas for read scalability & Multi AZ

Read Replicas

  • RDS의 읽기 성능을 향상 시키기 위해 읽기 전용 복제본을 생성
  • 최대 15개의 읽기 전용 복제본을 생성할 수 있으며 동일한 가용 영역 혹은 다른 가용 영역, 다른 리전에 걸쳐 생성할 수 있다.
  • ASYNC
    • 두 읽기 전용 복제본 사이에 비동기식 복제가 발생
    • 데이터를 복제하기 전 읽기 전용 복제본에서 애플리케이션이 데이터를 읽어들이면 모든 데이터를 얻을 수 있다.
    • 읽기 전용 복제본이 권한을 받으면 DB로 승격시켜 사용할 수 있다. 다만 자체적은 생애 주기를 갖는다.
    • 읽기 전용 복제본을 사용하기 위해서 애플리케이션은 모든 연결을 업데이트해야 RDS 클러스터 상의 읽기 전용 복제폼 전체 목록을 활용할 수 있다.
  • Use case
    • 평균적인 로드를 가지는 프로덕션용 데이터베이스가 있고 이 DB에서는 메인 RDS 데이터베이스 인스턴스에 대한 읽기 및 쓰기가 수행된다.
    • DB의 데이터 기반으로 몇몇 보고와 분석을 실시하려고 할 때 메인 RDS 인스턴스에 직접 보고 애플리케이션을 연결하면 오버로드가 발생하고 애플리케이션 속도가 느려질 것을 예상하고 이를 피하고자 한다.
    • 이때 비동기식으로 읽기 전용 복제본을 생성해서 보고 애플리케이션에 연결하면 프로덕션 애플리케이션의 성능에 영향을 미치지 않게 할 수 있다.
    • 읽기 전용 복제본이 있는 경우 SELECT 키워드만 사용가능하다.
  • Network Cost
    • AWS에서는 다른 가용 영역으로 데이터가 이동할 때 비용이 발생한다.
    • 이 비용은 관리형 서비스를 사용할 경우 예외적으로 발생하지 않는다.
    • 다른 리전으로 복제하는 것을 비용이 발생한다.

Multi AZ

  • 동기식 복제본을 가지며 이 복제본은 사용되지 않고 대기 상태로 다른 가용 영역에 있다.
  • 마스터 DB 인스턴스와 대기중인 DB 인스턴스는 같은 DNS 네임을 가지며 마스터에 장애가 발생한 경우 자동으로 대기 중인 DB 인스턴스와 연결되므로 가용성이 올라가고 장애에 대처 가능하다.
  • 이러한 구성은 전체 AZ 또는 네트워크가 손실될 때를 대비한 장애 조치이며 마스터 DB 인스턴스나 스토리지에 장애가 발생했을 경우에 대기 중인 DB 인스턴스가 새로운 마스터가 될 수 있도록 한다.
  • 수동으로 조치할 필요가 없다.
  • 복제본은 온전히 장애 조치를 위한 대기 인스턴스이므로 스케일링에 사용되지 않는다.
  • 재해 복구를 위해 원하는 경우 읽기 전용 복제본을 다중 AZ로 설정할 수 있다.

From Single AZ to Multi AZ

  • 다운 타임이 전혀 없다.
  • 실행 중인 데이터베이스 설정 수정해 다중 AZ 기능을 활성화하면 된다.
  • 내부에서 일어나는 작업
    1. 기본 데이터베이스의 RDS가 자동으로 스냅샷을 생성
    2. 생성된 스냅샷은 새로운 대기 데이터베이스에 복원된다.
    3. 대기 데이터베이스 인스턴스가 생성되면 두 데이터베이스 간 동기화가 설정

Create RDS

  1. 사용할 DB 엔진과 엔진 버전을 선택

    rds 1

  2. 사용 목적에 따른 템플릿을 선택

    • 프로덕션 : 고가용성 및 빠르고 일관된 성능을 사용해야할 때 사용
    • 개발/테스트 : 프로덕션 환경 외부에서 개발 용도로 사용
    • 프리 티어

  3. 가용성 및 내구성 설정

    • 다중 AZ DB 클러스터
      • 기본 DB 인스턴스와 읽기 전용 복제본 DB 인스턴스 2개
      • 고가용성, 데이터 이중화 제공 및 읽기 워크로드 성능 향상
    • 다중 AZ DB 인스턴스
      • 기본 DB 인스턴스와 대기 DB 인스턴스 1개
      • 고가용성과 데이터 이중화를 제공하지만 읽기 워크로드 성능 향상을 되지 않는다.
    • 단일 DB 인스턴스
      • 기본 DB 인스턴스 1개

  4. DB 설정

    • 자격 증명 설정
      • 마스터 이름
      • 암호 설정

  5. 인스턴스 구성

    • DB 인스턴스 클래스 선택 및 세부 유형 선택

  6. 스토리지

    • EBS 볼륨 유형 선택
    • 볼륨 용량 및 IOPS 설정

  7. 연결

    • EC2 연결 여부 설정
    • VPC 및 서브넷 설정
    • 퍼블릭 액세스 설정
    • 보안 그룹 생성 혹은 선택

  8. 데이터베이스 인증

    • 암호 인증
    • 암호 및 IAM 데이터베이스 인증
    • 암호 및 Kerberos 인증

  9. 모니터링 설정

  10. 추가 구성

    • 초기 데이터베이스 이름
    • DB 파라미터 그룹
    • 옵션 그룹
    • 백업
    • 암호화
    • 로그 내보내기 설정 → CloudWatch
    • 유지 관리 설정

RDS Custom for Oracle and Microsoft SQL Server

  • RDS는 기반이 되는 OS나 사용자 지정 기능에 액세스할 수 없지만 RDS Custom은 가능하다.
  • RDS Custom은 Oracle과 Microsoft SQL Server로 관리할 수 있다.
  • RDS에서 누릴 수 있는 장점을 그대로 누리면서 RDS OS에 액세스할 수 있다.
    • 내부 설정 구성
    • 패치 적용
    • 네이티브 기능 활성화
    • SSH나 SSM 세션 관리자를 사용해서 RDS EC2 인스턴스 액세스 가능
  • 사용자 지정 설정을 사용하기 위해 RDS가 자동으로 유지 관리 또는 스케일링 작업을 하지 않도록 자동화 모드를 해제해야한다.
  • 스냅샷을 수동으로 만들어 두어야 한다.
  • RDS vs RDS Custom
    • RDS는 데이터베이스 전체를 관리
      • OS와 나머지는 AWS에서 관리
    • RDS Custom은 Oracle과 Microsoft SQL Server에서만 사용 가능
      • OS의 전체 관리자 권한을 갖는다.

Amazon Aurora

Basic

  • Amazon Aurora는 AWS 고유의 기술
  • 오픈소스는 아니지만 Postgres와 MySQL과 호환되도록 설계
  • 클라우드에 최적화되어 있고 여러 최적화를 통해서 RDS MySQL보다 5배 높은 성능 Postgres보다 3배 높은 성능을 보인다. 성능 뿐 아니라 다양한 개선점도 있다.
  • 용량에 따라 스토리지를 자동으로 확장한다. 10GB ~ 128TB 사이의 용량을 사용가능
  • MySQL의 경우 읽기 전용 복제본이 5개로 제한되어 있지만 Aurora는 15개까지 생성할 수 있다. 복제 속도도 10ms 미만으로 매우 빠르다.
  • 장애 조치는 즉각적으로 일어나며 다중 AZ나 MySQL RDS보다 훨씬 빠르며 기본적으로 클라우드 네이티브이므로 가용성이 높다.
  • RDS에 비해 20% 정도 비싸지만 더 효율적이다. 스케일링 부분이 두드러져 오히려 비용을 절약할 수 있다.

High Availability and Read Scaling

  • 사용자가 Aurora에 무언가를 기록할 때마다 6개 복사본을 3개의 가용영역에 저장한다.
    • 6개 중 4개만 작동해도 쓰기 작업이 가능하다.
    • 6개 중 3개만 작동해도 읽기 작업이 가능하며 쓰기보다 읽기에 대한 가용성이 더 좋다.
    • 자가 복구 기능이 있어 데이터 손상이나 문제가 발생했을 때 백앤드에서 P2P 복제를 통한 자가 복구가 진행된다.
    • 단일 볼륨에 의존하지 않고 수백개의 볼륨을 사용
  • 쓰기 작업은 RDS와 유사하다.
    • 쓰기 작업을 진행하는 인스턴스는 하나로 해당 인스턴스가 마스터가 된다.
  • 마스터에 장애가 발생할 경우 평균 30초 이내로 장애 조치가 시작된다.
  • 마스터 외에 읽기를 제공하는 읽기 전용 복제본을 15개까지 둘 수 있다.
    • 복제본을 많이 두고 읽기 워크로드를 스케일링할 수 있다.
    • 마스터에 문제가 생기면 읽기 전용 복제본 중 하나가 마스터로 대체된다.
  • 복제본들은 리전 간 복제를 지원한다.

Aurora Cluster

rds 2
  • Aurora는 DB 인스턴스 간 공유 볼륨을 사용하고 마스터가 바뀌거나 장애 조치가 실행될 수 있으므로 Writer 엔드포인트를 제공한다.
  • Writer 엔드포인트는 DNS 네임으로 항상 마스터를 가리킨다.
  • 클라이언트는 장애 조치 후에도 Writer 엔드포인트와 상호작용하며 올바른 인스턴스로 자동 리다이렉트된다.
  • 읽기 전용 복제본은 15개까지 자동 스케일링이 가능하다.
  • 여러 복제본이 있을 때 어떤 복제본에 연결되어 읽기 작업을 수행해야할지 파악하기 어려울 수 있지만 Reader 엔드포인트를 사용해 모든 읽기 전용 복제본과 연결한다. Reader 엔드포인트는 로드밸런서 역할을 수행할 수 있다.

Features of Aurora

  • 자동 장애 조치
  • 백업 및 복구
  • 격리 및 보안
  • 산업 규정 준수
  • 버튼식 스케일링
  • 제로 다운타임 자동 패치 설치
  • 고급 모니터링
  • 통상 유지 관리
  • 백트랙
    • 과거 어떤 시점으로도 데이터를 복원
    • 백업에 의존하는 기능은 아니다.

Create Aurora

  1. Aurora는 MySQL 호환과 PostgreSQL 호환 두가지 엔진이 있다.
  2. 엔진 버전은 Aurora가 지원하는 기능에 따라 필터링 후 선택할 수 있다.
  3. Aurora는 프리 티어 템플릿을 지원하지 않아 실습시 비용이 청구될 수 있다.
  4. 인스턴스 구성
    • 메모리 최적화 클래스와 버스터블 클래스 두가지로 나뉜다.
  5. 가용성 및 내구성
    • 다중 AZ사용이 기본적으로 활성화 되어있다.
    • Aurora 복제본 혹은 Reader node를 다른 AZ에 생성한다.
    • 장애 조치 속도와 가용성을 높이는데 유용
  6. 연결
    • EC2 인스턴스 연결 설정
    • 네트워크 유형 설정 - IPv4, IPv6
    • VPC 및 서브넷 설정
    • 퍼블릭 액세스 설정
    • 보안그룹 설정
  7. 데이터베이스 인증
    • 암호 인증
    • 암호 및 IAM 데이터베이스 인증
  8. 모니터링 설정
  9. 추가 구성
    • 초기 DB 설정

  • Aurora DB를 생성하면 리전 클러스터에 라이터 인스턴스, 리더 인스턴스가 생성된 것을 확인할 수 있다.

    rds 3

  • DB 클러스더의 엔드포인트가 2개 생성된 것을 확인할 수 있고 각각 라이터와 리더 인스턴스와 연결된다.

    • 각 인스턴스를 클릭하면 라이터나 리더 앤드포인트와 별개로 인스턴스 고유 앤드포인트도 확인할 수 있다.

      rds 4

  • Auto Scaling Policy - Read Replica

    rds 5 - Aurora 복제본의 평균 CPU 사용량이나 연결 수에 기반하여 읽기 전용 복제본에 대한 오토 스케일링 정책을 생성할 수 있다.

  • 리전 추가

    • 데이터베이스 클러스터에 리전을 추가하여 글로벌 Aurora 서비스를 구축할 수 있다.
    • 인스턴스 크기에 따라서 기능이 호환되지 않을 수 있다.

Aurora 고급개념

  • Auto Scaling
    • 읽기 전용 복제본의 CPU 사용량에 따라 오토 스케일링이 되서 복제본이 늘어나면 리더 엔드포인트도 늘어난 복제본만큼 확장된다.
    • 이러한 방식으로 읽기 워크로드를 분산시킬 수 있고 전체 CPU 사용량을 줄일 수 있다.
  • Custom Endpoint
    • 읽기 전용 복제본의 인스턴스 유형이 때로는 서로 다를 때도 있다.
    • 이렇게 하는 이유는 Aurora 인스턴스의 하위 집합을 사용자 지정 엔드포인트로 정의하기 위함이다.
    • 예를 들어 서로 다른 크기의 인스턴스 유형을 가진 읽기 전용 복제본이 있을 때 더 큰 크기의 인스턴스 유형을 가진 읽기 전용 복제본의 역할을 분석 쿼리에 사용하기 위해 또다른 엔드포인트를 정의하여 연결한다.
    • 리더 엔드포인드는 사용자 지정 엔드포인트를 정의한 후에는 사라지지는 않지만 사용되지 않는다.
    • 실제로 사용자 정의 엔드포인트를 생성하여 다양한 종류의 워크로드에 대응할 수 있도록 한다.
  • Aurora Serverless
    • 실제 사용량에 따라 자동화된 데이터베이스 인스턴스화 및 오토 스케일링을 제공
    • 워크로드가 드물거나 간혈적 혹은 예측할 수 없는 경우에 유용
    • 용량 계획을 세울 필요가 없다.
    • Aurora 인스턴스의 초당 요금을 지불하므로 보다 비용 효율적이다.
  • Aurora Multi-Master
    • 라이터 노드에 대한 지속적인 쓰기 가용성을 원할 때 사용
    • Aurora 클러스터에서 모든 Aurora 인스턴스는 라이터 노드가 된다.
  • Global Aurora
    • 리전 간 읽기 복제본이 존재
      • 재해 복구에 유용
      • 간단한 설치
    • Aurora Global Database - 권장
      • 기본 리전에서 읽기 및 쓰기가 모두 일어난다.
      • 최대 5개의 보조 읽기 전용 리전 - 복제 지연이 1초 미만
      • 보조 리전 당 최대 16개 읽기 복제본 설정
      • 전세계 읽기 지연 시간을 줄일 수 있다.
      • 한 리전에서 데이터베이스가 중단되는 경우 재해 복구를 위해 다른 리전을 활성화하면 RTO - Recovery Time Objective가 1분 미만으로 할 수 있다.
  • Aurora Machine Learning
    • Aurora는 AWS내에서 ML과 연결되어 있으며 SQL을 통해 애플리케이션에 ML 기반 예측을 적용할 수 있다.
    • AWS ML 서비스와 간단하고 최적화된 안전한 통합
    • 지원 시버스
      • Amazon SageMaker - ML 모델 사용
      • Amazon Comprehend - 감정 분석
    • ML 경험 없이 사용가능
    • 사기 탐지, 광고 타겟팅, 감정 분석, 제품 추천 등의 서비스에 추천한다.

Backup & Monitoring

RDS Backups

  • 자동화된 백업
    • RDS는 데이터베이스 백업 기간 동안 매일 전체 데이터베이스를 백업한다.
    • 5분마다 트랜잭션 로그가 백업
      • 자동 백업을 통해 언제라도 5분 전으로 복원할 수 있다.
    • 자동 백업 보존 기간은 1~35일 사이로 설정할 수 있으며 사용하지 않을 경우에는 0으로 설정
  • 수동 데이터베이스 스냅샷
    • 사용자가 수동으로 트리거한다.
    • 사용자가 수동으로 원하는 기간 동안 백업을 유지할 수 있다는 점이 장점이다.
  • 백업을 활용한 트릭
    • 데이터베이스가 하루 중 사용되는 시간이 사용되지 않는 시간보다 짧을 때 스냅샷을 저장한 후 데이터베이스를 삭제하면 스냅샷을 저장하는 비용이 DB를 실행하는 것보다 비용이 저렴하므로 비용을 절약할 수 있다.
    • 생성된 스냅샷을 활용해서 다음 사용시간에 DB를 복원하여 사용한다.

Aurora Backup

  • RDS와 유사하게 자동화된 백업을 제공한다.
    • 1~35일까지 보존 기간을 설정할 수 있다.
    • 비활성화는 불가능하다.
    • 시점 복구 기능 - 해당 기간의 어느 시점에서든 복구가 가능하다.
  • 수동 DB 스냅샷
    • RDS와 동일하게 사용자가 트리거하는 스냅샷
    • 원하는 기간 동안 보존 가능

Restore Options

  • 백업이나 스냅샷을 활용하여 복원할 때마다 새로운 DB가 생성된다.
  • S3에서 MySQL DB를 복원할 수 있다.
    • On-premise DB 백업을 생성한 다음 Amazon S3에 객체로 배치한다.
  • RDS에는 Amazon S3에서 백업 파일을 복원하는 옵션이 있다.
  • Aurora MySQL을 Amazon S3에서 복원
    • Percona XtraBackup이라는 외부 소프트웨어를 사용해서 On-premise DB를 백업 - 현재는 이 방법 외에는 없다.
    • 백업 파일을 Amazon S3에 업로드 후 백업을 복원

Aurora Database Cloning

  • 기존 DB 클러스터에서 새로운 Aurora DB 클러스터를 생성할 수 있다.
  • 예시
    • Aurora에 프로덕션 DB가 있고 해당 DB에서 테스트를 실행하고자 한다.
    • 테스트 애플리케이션은 스테이징 환경에 있어 동일한 데이터를 복사할 필요가 있다.
    • 이 경우 프로덕션 Aurora DB를 복제하면 된다.
    • Cloning은 스냅샷을 찍고 복원하는 것보다 빠르다.
      • Copy-on-write 프로토콜을 사용
      • 처음 DB 복제본을 만들 때는, 원래 DB 클러스터와 동일한 데이터 볼륨을 사용한다. 같은 볼륨을 사용한다는 것은 실제 복사는 이루지지 않기 때문
      • 새 DB의 업데이트가 완료되면 새로운 추가 스토리지가 할당되고, 데이터가 복사 및 분리된다.
  • 매우 빠르고 비용 효율적이다.
  • 프로덕션 DB에 영향을 주지 않고 프로덕션 DB를 복제하는데 유용

RDS Security

  • At-rest encryption
    • 데이터가 볼륨에서 암호화된다.
    • KMS를 사용해 마스터와 모든 복제본의 암호화가 이루어지며 이 과정은 데이터베이스를 처음 실행할 때 정의
    • 마스터 DB를 암호화하지 않으면 읽기 전용 복제본을 암호화할 수 없다.
    • 암호화 되어있지 않은 기존 DB를 암호화하기 위해서는 기존 DB의 스냅샷을 찍은 후 암호화된 형태로 DB를 복원해야한다.
  • In-flight encryption
    • RDS는 기본적으로 클라이언트와 DB간 데이터 전송 중 데이터 암호화 기능을 갖추고 있다.
    • 클라이언트는 AWS의 TLS root 인증서를 사용해야한다.
  • IAM Authentication
    • 암호만을 사용한 DB 접속을 사용할 수도 있지만 AWS에서 사용하는 만큼 IAM 역할을 추가해서 DB에 연결할 수 있다.
    • EC2 인스턴스의 경우 RDS 연결 권한이 있는 IAM 역할을 가지고 있을 경우 사용자 이름과 암호를 사용하지 않아도 RDS 연결을 할 수 있다.
  • Security Group
    • 보안 그룹을 사용해서 데이터베이스에 대한 네트워크 액세스를 통제할 수 있다.
  • RDS와 Aurora는 SSH 액세스가 없다. RDS custom은 가능하다.
  • Audit Log
    • 감사 로그가 있어 시간에 따라 RDS 및 Aurora에서 어떠한 쿼리가 생성되고 있는지 확인할 수 있다.
    • 장기간 보관을 원하면 CloudWatch Logs에 전송한다.

RDS Proxy

  • 완전 관리형 RDS DB 프록시도 배포할 수 있다.
  • Amazon RDS Proxy를 사용하면 애플리케이션이 DB 내에서 DB 연결 풀을 형성하고 공유할 수 있다.
  • 애플리케이션을 일일이 RDS DB 인스턴스에 연결하는 대신 프록시가 하나의 풀에 연결을 모아 RDS 인스턴스로 가는 연결을 줄일 수 있다.
  • DB 인스턴스의 부담을 줄이고 개방된 연결과 시간초과를 최소화할 수 있어 DB의 효율성을 올릴 수 있다.
  • RDS 프록시는 완전한 서버리스로 오토 스케일링이 가능해 용량을 관리할 필요가 없고 가용성이 높다. - 다중 AZ 지원
  • RDS DB 인스턴스에 장애 조치가 발생하면 기본 인스턴스가 아닌 대기 상태인 인스턴스로 실행되며 RDS 프록시는 장애 조치 시간을 최대 66%까지 줄일 수 있다.
    • 메인 RDS DB 인스턴스에 애플리케이션을 모두 연결하고 장애 조치를 각자 처리하게 하는 대신 장애 조치와 무관한 RDS 프록시에 연결한다.
    • RDS 프록시가 장애 조치가 발생한 RDS DB 인스턴스를 처리하므로 장애 조치 시간이 개선
  • MySQL, PostgreSQL, MariaDB, Aurora를 지원
  • 애플리케이션의 코드를 변경하지 않아도 된다.
  • DB에 IAM 인증을 강제함으로써 IAM 인증을 통해서만 RDS DB 인스턴스에 연결하도록 할 수 있다.
  • RDS 프록시는 퍼블릭 액세스가 절대로 불가능하며 VPC 내부에서만 액세스 가능하다.
  • Lambda 함수를 DB에 사용할 때도 RDS 프록시는 유용하다.
    • Lambda 함수는 코드 조각을 실행하는 AWS 서비스이다.
    • Lambda 함수는 증식이 가능하고 매우 빠르게 사라진다.
    • 이러한 특성을 가진 수십만개의 Lambda 함수가 RDS 인스턴스에 연결을 개방하면 RDS 인스턴스에 부하가 올라가며 시간초과가 발생할 수 있다.
    • RDS 프록시가 Lambda 함수에 대한 연결 풀을 생성하면 Lambda 함수가 RDS 프록시를 오버로드한다.

ElastiCache

  • ElastiCache는 Redis나 Memcached를 관리할 수 있도록 도와주는 AWS 서비스이다.
  • 캐시는 매우 높은 성능과 짧은 지연 시간을 가진 인메모리 데이터베이스이다.
  • 캐시는 읽기 집약적인 워크로드에서 데이터베이스의 로드를 줄여준다.
  • 일반적인 쿼리는 캐시에 저장되므로, 매번 데이터베이스를 쿼리하지 않아도 캐시만 사용하여 쿼리의 결과를 검색할 수 있다.
  • 애플리케이션을 stateless로 할 수 있게 한다.
  • AWS가 OS 유지관리, 패치, 최적화, 설정, 구성, 모니터링, 장애 복구 및 백업을 관리한다.
  • ElastiCache를 사용한다는 것은 애플리케이션의 코드 수정이 필요하다는 것을 의미한다.
    • 캐시를 쿼리하는 것을 수정

ElastiCache Solution Architecture

  • DB Cache

    • 애플리케이션의 쿼리의 결과가 캐시에 있는 경우 “Cache hit” 되었다고 하며 이 경우 쿼리 수행을 위해 DB로 이동하는 시간이 절약된다.
    • 애플리케이션의 쿼리의 결과가 캐시에 없는 경우 “Cache miss” 되었다고 하며 이 경우 DB에서 데이터를 가져와야 한다.
    • “Cache miss”가 되어 DB에 데이터를 가져오면 그 결과를 캐시에 저장하고 애플리케이션에서 동일한 쿼리를 요청하면 캐시에서 결과를 가져간다.
    • DB의 로드를 줄이는데 도움이 된다.
    • 가장 최신의 데이터만을 사용되어야 하므로 캐시 무효화 전략이 필요하다. 이러한 점이 캐싱 기술을 사용하는데 가장 어려운 점이다.

  • User Session Store

    • 사용자 세션을 저장하는 아키텍처이며, 애플리케이션을 stateless로 만들 수 있다.
    • 사용자가 어떠한 애플리케이션에 로그인하면 세션 데이터를 캐시에 쓰는 것
    • 사용자가 다른 인스턴스에 접속하더라도 캐시에서 데이터를 검색할 수 있으므로 로그인 상태를 유지할 수 있다.

Redis vs Memcached

Redis

  • 자동 장애 조치 기능과 함께 다중 AZ 지원
  • 읽기 성능을 확장하고 고가용성을 가지기 위해 읽기 복제본이 있다
  • AOF 지속성을 사용한 데이터 내구성
  • 백업 및 복원 지원
  • 복제되는 캐시로 가용성과 내구성을 우선한다.
  • 세트와 정렬된 세트를 지원

Memcached

  • 데이터 분할을 위해 멀티 노드를 사용 - Sharding
  • 복제가 이루어지지 않아 영구 캐시가 아니며 고가용성을 보장하지 않는다.
  • 백업 및 복원 미지원
  • 멀티스레드 아키텍처
  • 여러 인스턴스가 모두 샤딩을 통해 작동

Create ElastiCache

  1. ElastiCache 생성은 VPC 설정, 클러스터 생성, 애플리케이션에 연결 순으로 진행된다.

    rds 11

  2. 클러스터를 새로 생성하거나 기존의 백업을 복원할 수 있다.

    rds 12
    1. 클러스터 모드
      • 활성화 - 여러 복제가 생기며 확장성과 가용성이 개선된다.
      • 비활성화 - 단일 노드 그룹과 최대 1개의 기본노드 및 최대 5개의 읽기 전용 복제를 얻게된다.
    2. 위치
      • AWS 클라우드
      • 온프레미스 - AWS Outposts를 사용해야한다.
      • 다중 AZ - 다중 AZ는 primary 노드에서 장애가 발생한 경우 여러 AZ에서 읽기 전용 복제본으로 자동 장애 조치를 수행하여 향상된 고가용성을 제공
      • 자동 장애 조치
        • 다중 AZ를 사용하면 기본 활성화가 되어있으며 비활성화는 불가능하다.
        • 다중 AZ를 사용하지 않으면 비활성도 가능
        • 읽기 전용 복제본에 대해 자동 장애 조치가 이루어진다.
    3. 클러스터 설정
      • 엔진 버전과 포트, 파라미터 그룹 노드 유형, 복제본 개수 설정
      • 복제본 개수가 0보다 크면 다중 AZ나 자동 장애 조치를 사용할 수 있지만 0이면 사용할 수 없다.
    4. 서브넷 그룹
      • ElastiCache가 실행될 서브넷 그룹을 선택 혹은 생성

  3. 고급 설정

    rds 13
    1. 보안
      • 저장 중 암호화 - 키를 사용해 데이터 암호화
      • 전송 중 암호화 - 서버와 클라이언트간 데이터 암호화, 액세스 제어권한 설정 가능
    2. 백업
    3. 유지관리
    4. 로그
  • 생성이 완료되면 기본 엔드포인트와 리더 엔드포인트를 확인할 수 있다.
    • 리더 엔드포인트는 읽기 전용 복제가 있을 때 사용할 수 있다.

Cache Security

  • ElastiCache는 Redis에서만 IAM을 지원하며, 나머지는 사용자 이름과 암호를 사용한다.
  • ElastiCache에서 IAM 정책을 정의하면 AWS API 수준 보안에만 사용
  • Redis AUTH
    • Redis 클러스터를 생성할 때 Redis 내 보안을 통해 암호와 토큰을 설정할 수 있다.
    • 캐시에 추가 보안 수준을 제공
    • SSL 전송 중 암호화도 지원
  • Memcached
    • SASL 기반 승인을 제공

Patterns for ElastiCache

  • Lazy Loading
    • 모든 데이터가 캐시되고 데이터가 캐시에서 지체될 수 있다.
    • “Cache miss”가 되는 경우에만 DB에서 데이터를 가져오기 때문
  • Write Through
    • DB에 데이터가 기록될 때마다 캐시에 데이터를 추가하거나 업데이트할 수 있다.
    • 데이터가 지체되지 않는다.
  • Session Store
    • 세션 데이터를 임시로 저장
    • 유지 시간 기능을 사용해 세션을 만료할 수 있다.
  • CS(Computer Science)에서 가장 어려운 것은 캐싱 무효화와 이름 붙이기라는 말이 있다.

Redis Use Case

  • 게이밍 리더보드
    • 생각하는 것보다 만드는 것이 복잡하다.
    • Redis에는 Sorted Set이 있어 고유성과 요소 순서를 보장한다.
    • 요소가 추가될 때마다 실시간으로 순위를 매긴 다음 올바른 순서로 추가

참고 자료

AWS Docs - Amazon RDS란 무엇입니까?
정보 문화사 - 아마존 웹 서비스

profile
Jong Eun Lee
오늘은 무엇을 배웠니?
이전 포스트

ASG

다음 포스트

Amazon Route 53

0개의 댓글

관련 채용 정보