ElastiCache

ElastiCache는 클라우드에서 분산 인 메모리 데이터 스토어 또는 캐시 환경을 원활하게 설정, 관리 및 확장할 수 있는 웹 서비스 입니다. 이 서비스는 확장 가능하며 비용 효율적인 고성능 캐싱 솔루션을 제공합니다. 또한 분산 캐시 환경 배포 및 관리와 관련된 복잡한 작업도 수행할 필요가 없습니다.

ElastiCache는 Redis와 Memcached 두 가지 오픈 소스 인 메모리 엔진을 지원합니다.

ElastiCache 엔진

ElastiCache는 위 2가지 오픈 소스 호환 인 메모리 데이터 스토에 대해 완전 관리형 기능을 제공합니다.

ElastiCache for Memcached를 사용하여 데이터 집약적 앱에 대한 확장 가능한 캐싱 티어를 구축할 수 있습니다. 1밀리초 미만의 응답 시간이 필요한 가장 까다로운 애플리케이션을 지원할 수 있도록 인 메모리 데이터 스토어 및 캐시의 역할을 합니다. 또한, 확장 가능하고 안전한 완전관리형 서비스로서 자주 액세스하는 데이터가 인 메모리에 상주해야 하는 사용 사례에 적합합니다. 이 엔진은 다중 스레딩을 사용하는 간단한 캐싱 모델을 제공합니다. 웹, 모바일 앱, 게임, 광고 기술 및 전자 상거래와 같은 사용 사례에 주로 사용됩니다. Memcached 호환 서비스는 자동 검색도 지원합니다.

ElastiCache for Redis는 인터넷 규모에서 1 밀리 초 미만의 지연 시간을 제공하는 인 메모리 데이터 스토어 입니다. Redis용 ElastiCache는 오픈 소스 Redis의 속도, 간편성, 및 다양성과 Amazon의 관리 용의성, 보안 및 확장성을 결합합니다. 게임, 광고 기술, 전자 상거래, 헬스케어, 금융 서비스 및 사물 인터넷(IoT) 분야에서 가장 까다로운 실시간 애플리케이션도 지원할 수 있습니다.

2가지 오픈 소스 비교 상세

스레드(Thread)
어떤 프로그램 내(특히 프로세스)에서 실행되는 흐름의 단위를 말합니다. 일반적으로 한 프로그램은 하나의 스레드를 가지고 있디만, 프로그램 환경에 따라 둘 이상의 스레드를 동시에 실행할 수 있는데, 이러한 실행 방식을 다중(멀티)스레드(Multithread)라고 합니다.

DynamoDB Accelerator(DAX)

DynamoDB는 확장성과 성능을 고려하여 설계되었습니다. 대부분의 경우 DynamoDB 응답 시간은 한 자릿수 밀리초 단위로 측정될 수 있습니다. 하지만 일부 용례는 마이크로초 단위의 응답 시간이 필요합니다. 이러한 사용 사례에서 DAX는 최종 일관성을 갖춘 데이터에 액세스하기 위한 빠른 응답 시간을 제공합니다.

DAX는 까다로운 애플리케이션에서 빠른 인 메모리 성능을 제공하는 DynamoDB와 호환되는 캐싱 서비스입니다.

VPC에 DAX 클러스터를 생성하여 캐시된 데이터를 애플리케이션에 더 가깝게 저장할 수 있습니다. 해당 VPC에서 애플리케이션을 실행하는 EC2 인스턴스에 DAX 클라이언트를 설치합니다. DAX 클라이언트는 런타임에 애플리케이션의 모든 DynamoDB 요청을 DAX 클러스터로 전송합니다. DAX는 요청을 직접 처리할 수 있으면 처리하고, 그 외의 경우에는 DynamoDB로 요청을 전달합니다.

DAX 개발자 안내서

캐시를 고려해야하는 항목

애플리케이션이 데이터베이스 캐싱을 사용해야 하는지 여부를 결정하기 위해서 다음과 같은 사항을 고려할 수 있습니다.

• 속도와 비용
  기본적으로 속도는 더 느리고 비용은 더 많이 드는 데이터베이스 쿼리가 존재합니다. 예를 들어 여러 테이블에서 조인을 수행하는 쿼리는 단순한 단일 테이블 쿼리보다 훨씬 더 많은 시간과 비용이 듭니다. 요청하는 데이터를 수신하려면 속도가 느리고 비용이 많이 드는 쿼리를 실행해야 하는 경우 해당 데이터를 캐시할 수 있습니다.
• 데이터 및 액세스 패턴
  캐싱할 항목을 결정할 때는 데이터 그 자체와 데이터의 액세스 패턴도 이해해야 합니다. 예를 들어 빠르게 변경되거나 거의 액세스하지 않는 데이터는 캐시할 필요가 없습니다. 캐싱을 통해 유의미한 이점을 얻으려면 소셜 미디어 사이트의 개인 프로필과 같이 비교적 정적이면서 액세스 빈도가 높은 데이터가 있어야 합니다.
• 캐시 유효성
  데이터는 캐시에 저장되어 있는 동안 오래된 상태가 될 수 있습니다. 즉, 데이터베이스의 해당 데이터에 대해 수행되는 쓰기가 캐시하기에 적합한지를 결정할 때는 정확하지 않을 수도 있는 캐시 데이터에 대한 애플리케이션의 내결함성을 결정해야 합니다.

캐싱 아키텍처

캐싱을 사용하지 않는 경우 EC2 인스턴스가 데이터베이스에서 직접 읽고 씁니다. 반면 캐싱을 사용하는 경우 인스턴스는 먼저 캐시에서 읽기를 시도하는데, 이 읽기에는 고성능 메모리가 사용됩니다. 에를들어 ElasticCache 및 DynamoDB Accelerator(DAX)와 같은 AWS의 데이터베이스 캐시는 인 메모리 DB입니다. 이러한 데이터베이스가 사용하는 캐시 클러스터에는 서브넷 간에 분산된 캐시 노드 집합이 포함되어 있습니다. 해당 서브넷 내의 리소스는 이러한 노드에 고속으로 액세스합니다.

위 예에서는 VPC의 2개 가용 영역에 각각 앱 서브넷과 데이터 서브넷이 있습니다. 두 앱 서브넷의 애플리케이션 서버는 데이터 서브넷 하나의 프라이머리 DB가 연결됩니다. 다른 데이터 서브넷에는 복제본 DB가 포함되어 있습니다. 두 앱 서브넷에 걸쳐 캐시 클러스터가 표시되어 있으며, 각 서브넷의 클러스터에는 캐시 노드가 있습니다.

백엔드 데이터 스토어에 캐시를 사용할 경우 사이드 캐시가 일반적인 접근 방식입니다. 정식 예에는 Redis와 Memcached가 모두 포함됩니다. 이러한 캐시는 범용이며 기본 데이터 스토어와는 분리됩니다. 그러므로 워크로드 및 내구성 요구 사항에 따라 읽기 및 쓰기 처리량을 모두 높일 수 있습니다.

Redis? Memcached?
Redis는 키-값(Key-Value) 구조의 비정형 데이터를 저장하고 관리하기 위한 오픈 소스 기반의 비관계형 DBMS입니다. DB, 캐시, 메세지 브로커로 사용되며 인메모리 데이터 구조를 가진 저장소입니다.

키-값 구조로 쿼리를 사용할 필요가 없고, 메모리에서 데이터를 처리하기 때문에 처리 속도가 빠르다는 특징이 있습니다. 하지만 서버 장애시 데이터 유실이 일어날 수 있으므로 장애 복구 플랜이 중요합니다.

Memcached는 고성능 분산 메모리 캐시 시스템입니다. 데이터베이스 부하를 완화하여 동적 웹 응용 프로그램의 속도를 높이는 데 사용하도록 만들어졌습니다. Redis와 마찬가지로 사용하기 쉽고, 높은 성능을 자랑합니다. Redis와 비슷한 원리로 동작해 특징 또한 거의 유사합니다.

일반적인 캐싱 전략

다양한 전략을 활용해 캐시의 정보를 DB와 동기화된 상태로 유지할 수 있습니다. 두 가지 일반적인 캐싱 전략은 지연 로딩과 라이트 스루입니다.

지연 로딩

지연 로딩에서는 캐시를 업데이트하지 않고 데이터베이스를 업데이트합니다. 캐시 미스의 경우 데이터베이스에서 검색된 정보가 나중에 캐시에 기록될 수 있습니다. 지연 로딩 시에는 애플리케이션에 필요한 데이터가 캐시에 로드됩니다. 하지만 일부 사용 사례에서는 캐시 미스 비율이 높아질 수 있습니다.

라이트 스루

DB에 액세스할 때마다 캐시에 라이트 스루를 수행하는 방법입니다. 이러한 접근 방식은 캐시 미스가 줄어든다는 특징이 있습니다. 그 결과 성능이 개선되지만 애플리케이션에 필요하지 않을 수 있는 데이터용 추가 스토리지가 필요합니다.

최상의 전략은 사용 사레에 따라 다릅니다. 부실 데이터가 사용 사례에 미치는 영향을 이해하는 것이 중요합니다. 영향이 높은 경우 라이트 스루를 사용하여 새로 고침 상태를 유지하는 것이 좋습니다. 영향이 낮은 경우 지연 로딩으로 충분할 수 있습니다. 또한 기본 데이터의 변경 빈도를 이해하는 데 도움이 됩니다. 캐싱 전략의 성능 및 비용 절충에 영향을 미치기 때문입니다.

캐싱 유지 관리 전략을 경정한 후에는 애플리케이션 내에서 이 접근 방식을 구현해야합니다.

캐시 미스
CPU가 데이터를 요청하여 캐시 메모리에 접근했을 때 캐시 메모리가 해당 데이터를 가지고 있다면 이를 "캐시 적중(Cache hit)", 해당 데이터가 없어서 DRAM에서 가져와야 한다면 "캐시 부적중(Cache miss)"라고 부릅니다.

ElastiCache for Redis / Memcached 상세

캐시 관리

캐시 유효성 관리

지연 로딩은 기한 경과 데이터를 제공할 수도 있지만 빈 노드로 인해 실패하지는 않습니다. 라이트 스루에서는 최신 데이터가 유지도비니다. 그러나 빈 노드로 인해 실패할 수 있으며 불필요한 데이터로 캐시를 채울 수 있습니다. 캐시에 대한 각 쓰기에 유지 시간(TTL) 값을 추가하면 데이터를 최신 상태로 유지할 수 있으며, 여분의 데이터로 인해 캐시가 가득 차는 현상을 방지할 수 있습니다.

TTL은 키가 만료할 때까지의 시간(초 or 밀리초)을 지정하는 정수 값입니다. 애플리케이션이 만료된 키를 읽으려고 하면 캐시에서 데이터를 찾지 못한 것으로 처리됩니다. 따라서 데이터베이스가 쿼리되고 캐시가 업데이트됩니다. 그럼 데이터 기한 경과를 방지할 수 있습니다. 단, 데이터베이스에서 가끔씩 캐시의 값을 새로 고쳐야 합니다.

메모리 관리

캐시 메모리가 가득 차면 캐시 엔진이 새 데이터용 공간을 확보하기 위해 메모리에서 데이터를 제거합니다. 엔진은 사용자가 설정한 제거 정책을 기준으로 이 데이터를 선택합니다. 제거 정책은 데이터의 다음  특성을 평가합니다.

• 액세스한 지 가장 오래된 데이터
• 액세스 빈도가 가장 낮은 데이터
• TTL 세트와 TTL 값이 설정되어 있는 데이터

DynamoDB 테이블

DynamoDB는 데이터를 테이블에 저장합니다. 테이블을 생성할 때 테이블 이름과 파티션 키를 지정해야 합니다. 테이블 생성 시에 필요한 엔터티는 이 두 항목 뿐입니다.

DynamoDB는 기본 키를 사용하여 테이블의 각 항목을 고유하게 식별하고 보조 인덱스를 사용하여 보다 유연하게 쿼리를 작성하도록 해 줍니다. 지원되는 기본 키의 2가지 유형은 다음과 같습니다.

• 단순 기본 키
  파티션 키라는 속성 하나만으로 구성된 단순한 기본 키입니다. 파티션 키를 하나만 사용하는 경우 두 항목이 동일한 값을 가질 수 없습니다.
• 복합 기본 키
  복합 기본 키는 파티션 키와 정렬 키로 구성됩니다. 이 경우 여러 항목의 파티션 키 값은 같을 수 있지만 정렬 키 값은 달라야 합니다.

핵심 구성 요소는 테이블, 항목, 및 속성입니다. 테이블은 항목의 모음이고 각 항목은 속성의 모음입니다. 위 예시에서 나와 있는 테이블에는 2개 항목이 포함되어 있고, Hammer57과 FluffyDuffy가 단순 기본 키입니다. 기본 키가 Hammer57인 항목에는 3개의 속성 (게임 ID, 최고점, 장르)이 있습니다. FluffyDuffy의 기본 키에는 구독 여부 속성이 포함되며 장르 속성은 포함되지 않았습니다.

상세

DynamoDB 용량 및 크기 조정

DynamoDB에서 용량을 계획할 때는 초당 읽기/쓰기 요청의 예상 수와 해당 요청의 크기를 고려해야 합니다. 이 정보를 고려하면 테이블용 용량 모드를 쉽게 선택할 수 있습니다. 또한 메시지 크기를 관리할 수 있도록 테이블을 설계할 수 있습니다.

온디맨드 용량 모드는 요청 단위로 요금이 부과되는 모델입니다. 다음과 같은 상황에서는 온디맨드 용량 모드가 유용합니다.

• 워크로드를 알 수 없는 경우
• 트래픽을 예측할 수 없는 경우
• 사용한 만큼만 지불하는 요금제를 사용하려는 경우

프로비저닝된 용량 모드 사용 시에는 RCU와 WCU의 최대 수를 설정합니다. 트래픽이 해당 한도를 초과하면 DynamoDB는 비용 제어를 위해 요청을 스로틀합니다. 자동 크기 조정을 사용해 프로비저닝된 용량을 조정할 수 있습니다. 다음과 같은 상황에서는 프로비저닝된 용량 모드가 유용합니다.

• 애플리케이션 트래픽이 예측 간으한 경우
• 트래픽의 양이 일정하거나 점진적으로 변경되는 경우
• 비용 관리를 위해 용량 요구 사항을 예측할 수 있는 경우

상세

DynamoDB 일관성 옵션

애플리케이션이 DynamoDB 테이블에 데이터를 쓰고 HTTP 200 응답(OK)을 수신하면 쓰기가 발생하며 내구성을 갖습니다. 데이터는 일반적으로 1초 이내에 모든 스토리지 위치에서 최종적으로 일관성을 갖습니다. DynamoDB는 최종적으로 일관된 읽기와 강력한 일관된 읽기를 지원합니다

• 최종적으로 일관된 읽기
  DynamoDB 테이블의 데이터를 읽을 때, 응답은 최근 완료된 쓰기 작업의 결과를 반영하지 않을 수 있습니다. 응답에는 부실 데이터가 일부 포함될 수 있습니다. 잠시 후 읽기 요청을 반복하면 응답이 최신 데이터를 반환합니다.
  (Ex_ YouTube 댓글, 쇼핑 장바구니 등 실시간 동기화가 굳이 필요하지 않은 경우)
  
  
• 강력한 읽기 일관성
  강력한 읽기 일관성을 요청하면 DynamoDB는 성공한 모든 이전 쓰기 작업의 업데이트를 반영하여 가장 최신 데이터로 응답을 반환합니다. 강력한 읽기 일관성은 네트워크 지연 또는 중단이 발생하는 경우에 사용이 어려울 수 있습니다.
  (Ex_ 항공권 구매, 티켓팅 등 실시간 동기화가 필요한 경우)

옵션을 지정하지 않을 경우 DynamoDB는 최종적으로 일관된 읽기를 사용합니다. 읽기 작업(GetItem, Query,Scan)은 CnsistentRead 파라미터를 제공합니다. 이 파라미터를 true로 설정하면 DynamoDB는 작업 중에 강력한 읽기 일관성을 사용합니다.

DynamoDB 글로벌 테이블

글로벌 테이블은 단일 AWS 계정이 소유하고 복제 테이블로 식별되는 한 개 이상의 DynamoDB 테이블의 모음입니다. 복제 테이블(이하 복제본)은 글로벌 테이블의 일부로 기능하는 단일 DynamoDB 테이블입니다. 각 복제본에는 동일한 데이터 항목 집합이 저장됩니다. 글로벌 테이블은 리전당 한 개의 복제 테이블을 가질 수 있습니다. 모든 복제본은 동일한 테이블 이름과 동일한 기본 키 스키마를 갖습니다.

DynamoDB 글로벌 테이블은 복제 솔루션을 직접 구축하여 관리하지 않고도 다중 리전, 다중 활성 마스터 DB를 배포할 수 있는 완전관리형 솔루션을 제공합니다. 글로벌 테이블을 생성할 때 테이블을 사용할 수 있게 할 리전을 지정해야 합니다. DynamoDB는 이러한 리전에 동일한 테이블을 만들고 이들 모든 테이블에 대한 데이터 변경을 지속적으로 전파하기 위해 필요한 모든 태스크를 수행해야 합니다. DynamoDB는 AWS 네트워크 백본을 통해 이러한 변경 사항을 전달합니다.

상세

Dynamo DB

Dnamo DB는 완전관리형 NoSQL DB 서비스입니다. 이와 같이 대규모 확장이 가능한 분산형 NoSQL 데이터베이스를 관리하는 복잡한 작업은 서비스 자체에서 관리합니다. 그러므로 소프트웨어 개발자가 인프라 관리 대신 애플리케이션 구축에 집중할 수 있습니다.

NoSQL 데이터베이스는 기본적으로 확장이 가능하지만 해당 아키텍처가 정교하므로 대규모 NoSQL 클러스터를 실행하는 경우 상당한 운영 오버헤드가 발생할 수 있습니다. Dynamo DB를 사용하기 위해 고급 분산 컴퓨팅 개념을 다루는 전문가일 필요가 없습니다. 선택한 프로그래밍 언어의 SDK를 사용하여 DynamoDB의 간단한 API를 배우기만 하면 됩니다.

DynamoDB는 비용 효율적입니다. 사용하는 스토리지와 프로비저닝한 I/O 처리량에 대한 요금을 지불하면 됩니다. 이 데이터베이스는 고성능을 유지하면서 탄력적으로 확장 가능하도록 설계되었습니다. 애플리케이션의 스토리지 및 처리량 요구 사항이 낮은 경우 소량의 용량을 프로비저닝하도록 선택할 수 있습니다.

자동 크기 조정을 선택하면 필요한 I/O 처리량이 증가할 경우 사용자가 설정한 한도 내에서 추가 용량이 프로비저닝됩니다. 온디맨드 옵션을 선택하면 데이터베ㅣ스에 초당 수천 건의 동시 요청을 전송하는 수백만명의 사용자를 지원하도록 애플리케이션을 원활히 확장할 수 있습니다.

DynamoDB는 이벤트 중심의 프로그래밍과 세분화된 액세스 제어를 지원합니다.

오버헤드(Overhead)
어떤 처리를 하기 위해 들어가는 간접적인 처리 시간과 메모리 등을 말합니다. 예를들어 a작업을 단순하게 실행하는데 10초가 걸리고, 안정성을 고려하여 부가적인 처리를 한 A를 실행한 결과 15초가 걸렸다면, 오버헤드는 5초가 됩니다. 이를 개선해 A1이 처리하는 시간이 12초가 되었다면, "오버헤드가 3초 줄었다"라고 표현합니다.

SDK(Software Development Kit)
소프트웨어 개발 키드를 줄인 것으로 기본적으로 미리 작성된 코드를 뜻합니다. 여기에는 개발자가 기존 소프트웨어를 사용하여 새 애플리케이션을 구축하는 데 필요한 모든 도구가 포함됩니다. SDK에는 보통 컴파일러와 디버거, API가 있습니다. 이외에도 다양한 요소를 포함할 수 있습니다.

키-값 데이터

NoSQL DB에서는 데이터의 액세스 및 관리를 위해 다양한 데이터 모델을 사용합니다. 이러한 데이터베이스 유형은 큰 데이터 볼륨, 짧은 지연 시간, 유연한 데이터 모델이 필요한 애플리케이션에 최적화되었습니다. NoSQL 데이터베이스에서는 다른 데이터베이스의 데이터 일관성 제약 조건 일부를 완화하는 방식으로 최적화됩니다. 한 가지 일반적인 모델을 키-값 데이터 입니다.

키-값 DB는 요청한 데이터를 단일 키와 연결할 수 있는 사용 사례에 적합합니다. 예를 들어 애플리케이션의 사용자 프로파일 데이터를 키 값 DB에 저장한 후 GamerTag 값을 키로 사용할 수 있습니다. 이 경우 특정 GamerTag만 요청하면 사용자 데이터를 빠르게 검색할 수 있습니다.

DynamoDB 사용 사례

사례1

게임 제작자는 DynamoDB를 사용해 간단한 플레이어 프로파일 페이지를 지원할 수 있습니다. GamerTag를 키로 사용하여 DynamoDB에 사용자 프로파일 데이터를 저장할 수 있습니다. 프로파일 페이지가 로드될 때 애플리케이션은 GamerTag 값을 사용하여 DynamoDB에 읽기 요청을 한 번만 하면 됩니다. 그리고 새 게임이 출시되면 DynamoDB는 크기를 빠르게 조정하여 급증하는 트래픽을 지원하기에 충분한 스토리지와 처리량을 제공할 수 있습니다.

사례 상세

사례2

전자 상거래 애플리케이션을 통해 고객에게 제품을 판매한다고 가정해보겠습니다. 이 경우 정확한 재고 표시를 위한 웹스토어가 필요합니다. 그런데 트래픽이 많은 시기와 명절 할인 행사 기간 등에는 재고를 정확하게 표시하기가 매우 어렵습니다. DynamoDB는 다양한 제품의 데이털르 추가할 수 있는 유동적인 스키마를 지원합니다. 그리고 다수의 동시 읽기와 쓰기 작업을 관리하며, 저장된 데이터의 정확도도 유지 관리합니다.

저장 데이터 암호화

RDS는 AWS KMS(Key Management Service)를 사용하여 저장 데이터 암호화를 제공합니다. AWS KMS는 암화키를 생성 및 관리하고 해당 키를 사용하여 데이터를 암화화 및 복호화하는 기능을 제공하는 관리형 서비스입니다.

모든 키는 사용자의 AWS 계정에 연결되고 사용자가 전반적인 관리를 담당합니다. KMS는 RDS 인스턴스의 기본 스토리지에 대한 무단 액세스로부터 보호하는 추가 보호 계층을 제공합니다. KMS는 업계 표준 AES-256 암호화를 사용하여 RDS 인스턴스가 실행되는 기본 호스트에 저장되는 데이터를 보호합니다.

암호화와 복호화
암호화(Encryption)는 정보를 보호하기 위해 평문을 암호문으로 변환하는 과정입니다. 복호화(Decryption)는 암호문을 평문으로 변환하는 과정입니다.

Aurora

Aurora는 엔터프라이즈급 관계형 데이터베이스입니다. 이 데이터베이스는 MySQL 및 PostgreSQL  관계형 데이터베이스와 호환됩니다. Aurora Serverless는 표준 MySQL DB보다 최대 5배 빠르고 표준 PostgreSQL DB 보다는 최대 3배 빠릅니다.

Aurora는 DB 리소스의 안정성 및 가용성을 유지하면서 불필요한 I/O 작업을 줄여 DB 비용을 절감하는 데 도움이 됩니다. 워크로드에 고가용성이 필요한 경우 Aurora를 고려할 수 있습니다. 이 DB는 6개의 데이터 복사본을 3개의 가용 영역에 복제하고 지속적으로 S3(Simple Storage Service)에 데이터를 백업합니다.

또한, 네트워크 격리, 저장 중 및 정손 중 데이터 암호화, 규정 준수 및 보장 프로그램을 지원합니다. Aurora는 RDS에 의해 관리되기 때문에 서버 프로비저닝, 소프트웨어 패치 적용, 설정, 구성  또는 백업이 필요하지 않습니다.

Aurora DB 클러스터

Aurora DB 클러스터는 하나 이상의 DB 인스턴스와 해당 DB 인스턴스에 대한 데이터를 관리하는 클러스터 볼륨으로 구성됩니다. 이러한 인스턴스는 데이터베이스의 컴픂팅 기능을 수행하며, 실제 데이터는 클러스터 볼륨에 저장됩니다.

Aurora에서는 두 가지 인스턴스 유형이 제공됩니다.

• 프라이머리 인스턴스
  읽기 및 쓰기 작업을 지원하고, 클러스터 볼륨의 모든 데이터 변경을 싱행합니다. 각 Aurora DB 클러스터마다 프라이머리 인스턴스가 하나씩 있습니다.
• Aurora 복제본
  읽기 작업만 지원합니다. 각 Aurora DB 클러스터마다 프라이머리 인스턴스 이외에 최대 15개의 Aurora 복제본을 가징 수 있습니다. 복수의 Aurora 복제본은 읽기 워크로드를 분산합니다. Aurora 복제본은 별도의 가용 영역에 배치하여 가용성을 높일 수 있습니다. 읽기 전용 복제본은 프라이머리 인스턴스와 동일한 리전에 있을 수 있습니다.

Aurora 클러스터 볼륨은 여러 가용 영역에 걸쳐 있는 가상 데이터베이스 스토리지 볼륨입니다.  각 가용 영역에는 DB 클러스터 데이터의 복사본이 있습니다. 클러스터 볼륨의 스토리지는 스토리지 노드 수백 개에 복제됩니다. Aurora에서 클러스터 볼륨은 DB 클러스터의 Aurora 복제본과 프라이머리 인스턴스의 단일 논리 볼륨으로 제공됩니다. 클러스터 볼륨에서 쓰기 작업을 수행하면 100밀리초 이내에 Aurora 복제본에서 해당 내용을 확인할 수 있는 경우가 많습니다.

PostgreSQL 및 MySQL용 Aurora Serverless v2

Aurora Serverless v2는 Aurora의 온디맨드 자동 크기 조정을 위한 구성입니다. 이는 워크로드를 모니터링하고 데이터베이스 용량을 조정하는 프로세스를 자동화하는 데 도움이 됩니다. 용량은 애플리케이션 수요에 따라 자동으로 조정됩니다. DB 클러스터에서 사용하는 리소스 요금만 청구되므로, 예산을 준수하는 데 도움이 되며 사용하지 않는 컴퓨터 리소스 요금을 부담할 필요가 없습니다.

또한, 이를 사용하면 DB가 자동으로 애플리케이션의 피크로드를 충족하도록 용량을 늘리고 활동 급증 시간이 끝나면 다시 용량을 줄입니다. Aurora Serverless v2를 사용하면 피크 또는 평균 용량에 따라 프로비저닝할 필요가 없습니다. 가장 많은 워크로드를 처리하는 용량 상한을 지정하면 해당 용량은 필요하기 전에는 사용되지 않습니다.

최소 용량도 설정할 수 있습니다. Aurora Serverless v2 DB 인스턴스의 크기 조정 속도는 현재 용량에 따라 달라집니다. 현재 용량이 클수록 빠르게 확장됩니다. DB 인스턴스의 용량을 단시간 내에 매우 크게 확장해야 하는 경우에는 크기 조정 속도가 요구 사항을 충족하는 값으로 최소 용량을 설정할 수 있습니다. 이 유형의 자동화는 다중 테넌트 DB, 분산 DB, 개발 및 테스트 시스템, 매우 중요하지만 예측 불가능한 워크로드가 있는 기타 환경에서 특히 유용합니다.

RDS 기능

RDS는 클라우드에서 관계형 데이터베이스를 설치, 운영 및 크기 조정을 할 수 있게 해주는 웹 서비스입니다. 이 서비스는 비용 효율적이고 크기 조정이 가능한 데이터베이스 용량을 제공해 주는 동시에 시간 소모적인 데이터베이스 관리 태스크도 처리해줍니다.

이는 Aurora, PostgreSQL, MySQL, MariaDB, Oracle Database, MS SQL Server 등 선택할 수 있는 6개의 친숙한 데이터베이스 엔진을 제공합니다. 그러므로 기존 데이터베이스에서 이미 사용하고 있는 코드, 애플리케이션 및 도구를 대부분 RDS에서 사용할 수 있습니다.

또한, 자동으로 데이터베이스 소프트웨어를 패치하고 데이터베이스를 백업합니다. 백업을 사용자가 정의한 보존 기간 동안 저장하고 특정 시점으로 복구 기능을 제공합니다. 한 번의 API 호출로 관계형 DB 인스턴스와 연결된 컴퓨팅 리소스 또는 스토리지 용량을 유연하게 스케일링하는 이점을 누릴 수 있습니다.

RDS 다중 AZ 배포

RDS는 다중 AZ 배포를 통해 데이터베이스 인스턴스의 가용성 및 내구성을 높여 주므로 프로덕션 데이터베이스 워크로드에 적합합니다. 다중 AZ DB 인스턴스를 프로비저닝하는 경우 RDS에서 다른 가용 영역에 있는 대기 인스턴스에 데이터를 동기식으로 복제합니다.

프로비저닝은  IT 인프라를 생성하고 설정하는 프로세스로, 다양한 리소스에 대한 사용자 및 시스템 액세스를 관리하는 데 필요한 단계를 포함합니다. 프로비저닝은 서버, 애플리케이션, 네트워크 구성, 스토리지, 엣지 기기 등을 배포하는 과정에서 초기 단계에 해당 합니다.

RDS 환경을 단일 AZ에서 다중 AZ로 변경하여 배포할 수 있습니다. 각 가용 영역은 물리적으로 분리된 독립적인 인프라에서 실행되며 높은 안정성을 제공하도록 설계되었습니다.

다중 AZ 장애 조치

프라이머리 인스턴스에 장애가 발생한 경우 RDS는 대기 인스턴스로 자동 장애 조치를 수행합니다.

위 예시에서 각 가용 영역 내의 EC2 인스턴스 2개는 가용 영역 하나의 프라이머리 데이터베이스에 연결되어 있습니다. 대기 데이터베이스는 다른 가용 영역에서 호스트 됩니다. 프라이머리 데이터베이스에서 장애가 발생하면 RDS는 세컨더리 데이터베이스를 프라이머리로 승격합니다. 그러면 세컨더리 데이터베이스가 프라이머리 데이터베이스 엔드포인트가 되므로 EC2 인스턴스가 새 프라이머리 데이터 베이스를 사용하여 트래픽 전송을 다시 시작할 수 있습니다. 그와 동시에 새 대기 데이터베이스가 다른 가용 영역에 생성됩니다.

읽기 전용 복제본

RDS를 사용하면 데이터베이스의 읽기 전용 복제본을 생성할 수 있습니다. Amazon에서 자동으로 이러한 복제본을 프라이머리 데이터베이스 인스턴스와 동기화 합니다. 읽기 전용 복제본은 RDS for Aurora, MariaDB, PostgreSQL, Oracle, MS SQL Server에서 사용할 수 있습니다. 읽기 복제본 사용 시에는 다음과 같은 태스크를 수행할 수 있습니다.

읽기 전용 복제본 사용 시에는 다음과 같은 태스크를 수행할 수 있습니다.

• 추가 읽기 용량으로 프라이머리 노드에 대한 부하를 해소할 수 있습니다.
• 여러 AWS 리전에서 데이터를 애플리케이션에 더 가까이 배치할 수 있습니다.
• 프라이머리 DB 인스턴스에 장애가 발생하는 경우 재해 복구(DR) 솔루션으로 읽기 전용 복제본을 독립 실행형 인스턴스로 승격할 수 있습니다.

프라이머리 DB가 읽기 요청으로 오버로드되지 않도록 읽기 전용 복제본을 추가하여 읽기 워크로드를 처리할 수 있습니다. DB 엔진에 따라 읽기 전용 복제본을 프라이머리 DB와 다른 리전에 배치할 수도 있습니다. 이러한 배치 방식을 사용하면 읽기 전용 복제본을 특정 로케이션에 더 가까이 배치할 수 있습니다.

고가용성을 위해 원본 DB를 다중 AZ로 구성하고 읽기 확장성을 위해 단일 AZ에서는 읽기 전용 복제본을 다중 AZ 및 DR 대상으로 설정할 수도 있습니다. 읽기 전용 복제본을 독립형 데이터베이스로 승격하면 읽기 전용 복제본이 여러 가용 영역으로 복제됩니다.

읽기 전용 복제본 상세