[AWS] ElastiCache 란?

다음은 ElastiCache 공식 문서를 정리한 내용입니다.

Amazon ElastiCache For Redis 란?

What is Amazon ElastiCache (Redis OSS)?

ElastiCache (Redis OSS)는 Redis 오픈소스를 사용하여 제공하는 In-Memory DB 입니다.

서버리스와 자체 클러스터 설계로 선택하여 구성할 수 있으며

그중 자체 클러스터 설계의 경우 클러스터 여부, 샤드 수, 노드 인스턴스 타입, 노드 수 등을 사용자가 선택하여 구성할 수 있습니다.

 

주요 이점 (서버리스와 비교하여)

세밀한 제어 : 파라미터 그룹의 설정을 통하여 설정, MultiAZ 설정 등 세부 사항까지 사용자가 직접 설정이 가능합니다.. 

수직 및 수평 확장 : 필요에 따라 수동으로 캐시 노드 크기, 클러스터 수평 확장을 하거나 자동 확장 기능을 사용하여 관리할 수 있습니다.

 

비용

캐시 노드 사용 시간당 비용을 지불합니다.

 

백업

Redis OSS 캐시의 특정 시점 복사본 백업을 생성할 수 있습니다. 백업은 기존 캐시를 복원하거나 새 캐시을 시딩하는 데 사용할 수 있습니다.

 

---

Choosing between deployment options (serverless 제외)

배포 옵션 선택 기준

서버리스

• 새로운 작업이나 예측하기 어려운 작업 부하에 대한 캐시
• 예측할 수 없는 애플리케이션 트래픽
• 손쉬운 캐시 구성

자체 ElastiCache 클러스터

• Redis OSS를 실행하는 노드 유형, 노드 수, 노드 배치를 더욱 세부적으로 제어
• 애플리케이션 트래픽이 비교적 예측 가능한 상황에서 성능, 가용성 및 비용에 대한 세부적인 제어를 원합니다.
• 비용을 통제하기 위해 용량 요구 사항을 예측할 수 있습니다.

특징	설명
캐시 설정	사용자는 MultiAZ 여부, 노드 인스턴스 타입, 노드 수 및 배치 등을 직접 선택할 수 있습니다.
지원되는 Redis OSS 버전	ElastiCache(Redis OSS) 버전 4.0 이상
클러스터 모드	클러스터 모드 활성화 또는 비활성화
스케일링	필요에 따라 수직 수평 스케일링이 가능합니다. 오토 스케일링 기능을 사용하면 일정에 따라 크기 조정을 구성하거나 CPU 및 메모리 사용량과 같은 측정 항목을 기준으로 크기 조정을 구성할 수도 있습니다.
클라이언트 연결	클라이언트는 제공되는 엔드포인트를 통하여 클러스터에 접근 가능합니다.
구성 가능성	자체 설계 클러스터는 세분화된 구성 옵션을 제공합니다. 매개변수 그룹을 사용할 수 있습니다.
Multi-AZ	Multi-AZ 클러스터의 경우, 데이터는 더 높은 가용성과 향상된 읽기 대기 시간을 위해 여러 가용성 영역에 비동기적으로 복제됩니다.
미사용 데이터 암호화	암호화를 활성화 또는 비활성화하는 옵션. AWS KMS를 통하여 관리할 수 있습니다.
전송 중 암호화(TLS)	클라이언트가 TLS 통신을 하도록 강제하는 옵션.
백업	클러스터는 사용 가능한 예약된 메모리에 따라 성능에 영향을 받을 수 있습니다.  ElastiCache Serverless 캐시나 자체 설계 클러스터로 복원할 수 있습니다.
모니터링	각 노드 수준에서 다양한 지표를 확인 가능합니다.
유효성	자체 설계 클러스터는 최대 99.99%의 가용성을 달성하도록 설계될 수 있습니다.
업그레이드 및 패치	마이너 및 패치 버전 업그레이드와 메이저 버전 업그레이드 가능.
글로벌 데이터 스토어	단일 지역 쓰기 및 다중 지역 읽기를 통해 교차 지역 복제를 가능하게 하는 Global Data Store를 지원합니다.
데이터 계층화	r6gd 제품군의 노드를 사용하여 설계된 클러스터는 메모리와 로컬 SSD 스토리지 간에 데이터가 계층화됩니다. 데이터 계층화는 메모리에 데이터를 저장하는 것 외에도 각 클러스터 노드에서 SSD를 활용하여 Redis OSS 워크로드에 대한 가격 대비 성능 옵션을 제공합니다.
비용	캐시 노드 사용량에 따라 시간당 지불.

 

---

ElastiCache (Redis OSS) terminology

 

Console	API/CLI
Node	Node
(단일 노드) Cluser	(단일 노드) Cluster
Shard	Node Group
(다중 노드) Cluster	Replication Group
Primary Node	Primary Node
Replica Node	Replica Node

글로벌 데이터 스토어 : 리전 간에서 서로 복제하는 하나 이상의 클러스터 모음.

글로벌 데이터 스토어는 다음과 같이 구성됩니다.

• 기본(활성) 클러스터 - 기본 클러스터는 글로벌 데이터 스토어 내의 모든 클러스터에 복제되는 쓰기를 허용합니다. 기본 클러스터는 읽기 요청도 허용합니다.
• 보조(수동) 클러스터 - 보조 클러스터는 읽기 요청만 허용하고 기본 클러스터에서 데이터 업데이트를 복제합니다. 보조 클러스터는 기본 클러스터와 다른 AWS 지역에 있어야 합니다.

Redis OSS용 글로벌 데이터스토어를 사용하면 다음과 같은 이점이 있습니다.

• 멀티 리전 성능 : 여러 지역에서 지연 시간이 짧은 읽기를 제공하여 애플리케이션의 응답성을 높이는 데 도움이 될 수 있습니다. 
• DR -  보조 클러스터를 새 기본 클러스터로 수등으로 승격할 수 있습니다.

 

ElastiCache components and features

노드

노드는 ElastiCache 배포의 가장 작은 구성 요소입니다. 노드는 다른 노드와 독립적으로 존재하거나 다른 노드와 일부 관련되어 존재할 수 있습니다.

각 노드는 클러스터를 생성할 때 선택한 엔진 및 버전의 인스턴스를 실행합니다. 필요한 경우 클러스터의 노드를 다른 인스턴스 유형으로 스케일 업하거나 스케일 다운할 수 있습니다. 

클러스터 내 모든 노드는 인스턴스 유형이 동일하며, 동일한 캐시 엔진을 실행합니다. 각 캐시 노드에는 고유한 DNS가 있습니다. 

노드 사용에 대한 비용은 On-demand와 RI를 통하여 관리할 수 있습니다.

 

샤드

샤드 (또는 노드 그룹) 는 1~6개의 관련 노드를 그룹화한 것입니다. 클러스터 모드가 활성화된 Redis OSS 클러스터에는 항상 샤드가 하나 이상 있습니다.

샤딩을 통해 작업을 여러 개별 섹션으로 분산하여 데이터베이스 효율성을 높일 수 있습니다. 샤드를 사용하면 성능, 확장성, 비용 효율성 향상 등 많은 이점을 얻을 수 있습니다.

Redis OSS 엔진 버전이 5.0.6 이상인 경우 샤드 한도를 클러스터당 최대 500개까지 늘릴 수 있습니다 (노드 역시 최대 500개 이므로 이 경우는 샤드당 기본 노드만 가지고 있도록 구성).

증가를 수용할 수 있는 IP 주소가 충분한지 확인해야 합니다. 

샤드는 기본 노드 하나와 1~5개의 복제본 노드를 통해 복제를 구현할 수 있습니다. 

 

 

클러스터

클러스터는 하나 이상의 캐시 노드 모음입니다. 클러스터 모드가 활성화된 Redis OSS 클러스터에서는 샤드 간에 데이터가 분할됩니다.

 

클러스터 구성

클러스터 모드가 비활성화된 Redis OSS 클러스터는 항상 샤드를 하나만 포함합니다.

Redis OSS 샤드는 1~6개의 노드를 포함합니다. 한 샤드에 노드가 두 개 이상 있는 경우 샤드에서는 복제를 지원합니다. 이 경우 한 노드는 읽기/쓰기 기본 노드이고 다른 노드는 읽기 전용 복제 노드입니다.

내결함성을 높이려면 Redis OSS 클러스터에 노드를 2개 이상 두고 다중 AZ를 활성화하는 것이 좋습니다. 

클러스터 내의 복제본 노드는 기본 노드에서 데이터가 작성될 때마다 비동기식으로 업데이트 됩니다.

데이터 계층화 : 자주 액세스하지 않는 데이터는 디스크에 저장. 데이터 계층화를 사용하면 메모리 요구 사항이 줄어들 수 있다는 장점이 있습니다. 

 

 

복제

각 Replica 노드는 Primary 노드에서 데이터 사본을 유지합니다.

Replica 노드는 비동기식 복제 메커니즘을 사용하여 기본 노드와의 동기화를 유지합니다. Replica 노드는 비클러스터드 모드에서 엔드포인트에 읽기를 분산하여 확장성을 향상합니다. 

MultiAZ에서 읽기 전용 Replica를 구성하면 고가용성이 더욱 개선됩니다. 

 

 

	클러스터 모드가 비활성화된 Redis OSS 클러스터	클러스터 모드가 활성화된 Redis OSS 클러스터
샤드 수	1	1~500
각 샤드의 복제본 수	0~5	0~5
데이터 파티셔닝	아니요	예
복제본 추가/삭제 가능 여부	예	예
샤드 추가/삭제 가능 여부	아니요	예
스케일링	예	예
엔진 업그레이드 지원	예	예
복제본을 기본 노드로 승격	예	자동
Multi-AZ	선택 사항	선택 사항
자동 장애 조치	선택 사항	필수
백업/복구	예	예
참고:
복제본이 없는 기본 노드에서 장애가 발생할 경우 기본 노드에 저장된 데이터가 모두 손실됩니다.

 

ElastiCache 엔드포인트

엔드포인트는 애플리케이션이 ElastiCache 노드나 클러스터에 연결하는 데 사용하는 고유한 주소입니다.

클러스터 모드와 상관 없이 개별 노드의 엔드포인트는 제공이 됩니다.

클러스터 모드 비활성화

• 단일 노드 : 읽기 및 쓰기 모두에 대해 클러스터에 연결하는 데 사용됩니다.
• 다중 노드 
  • Primary Endpoint : Pirmary 노드에 대한 엔드포인트
  • Reader Endpoint : Replica 노드에 대한 엔드포인트 

클러스터 모드 활성화 엔드포인트

• Configuration Endpoint :  애플리케이션이 ElastiCache 클러스터에 연결하는데 사용이되며 읽기, 쓰기 모두 사용합니다.

 

ElastiCache 파라미터 그룹

파라미터 그룹을 생성 및 수정하여 할당할 수 있습니다.

클러스터 단위로 지정이 되며 노드 단위 별도 지정은 불가능한 것으로 보입니다.

 

ElastiCache 보안

ElastiCache 노드 액세스는 허용한 Amazon EC2 인스턴스에서 실행되는 애플리케이션으로 제한됩니다.

보안 그룹을 사용하여 클러스터에 액세스할 수 있는 Amazon EC2 인스턴스를 제어할 수 있습니다.

전송 중 데이터 암호화, 미사용 데이터 암호화, 인증 및 권한 기능이 사용 가능합니다

 

 

전송 중 데이터 암호화 (TLS) : TransitEncryptionEnabled 파라미터를 통해 제어가 가능합니다.

전송 중 암호화는 엔드포인트에서 데이터를 암호화 및 해독하기 위해 몇 가지 처리가 필요하기 때문에 전송 중 데이터 암호화를 활성화하면 성능에 어느 정도 영향이 있을 수 있습니다

암호화 옵션에 따른 QPS 테스트 성능 저하에 대한 테스트 내용이 있습니다. 해당 페이지의 테스트 내용은 다음과 같습니다. (약 10% 가량의 성능 감소)

옵션	QPS
암호화 X	162
미사용 데이터 암호화	159
전송 중 암호화	141

 

전송 중 암호화는 다음 기능을 구현합니다.

• 암호화된 클라이언트 연결 - 캐시 노드에 대한 클라이언트 연결은 TLS로 암호화됩니다.
• 암호화된 서버 연결 - 클러스터의 노드 간에 이동하는 데이터는 암호화됩니다.
• 서버 인증 - 클라이언트가 자신이 올바른 서버에 연결 중임을 인증할 수 있습니다.
• 클라이언트 인증 - 서버는 Redis OSS AUTH 기능을 사용하여 클라이언트를 인증할 수 있습니다.

사용 중인 클러스터를 전송 중 암호화로 변경시 다음의 구성 단계가 필요합니다.

전송 중 암호화 모드를 preferred 로 변경하여 TLS 연결 기능 추가 → API에서 ElastiCache 연결을 TLS로 변경 → 전송 중 암호화 모드를 required로 변경하여 TLS 강제화

 

미사용 데이터 암호화 : ElastiCache의 메모리가 아닌 디스크의 데이터를 암호화하여 보안을 강화하는 기능으로 AtRestEncryptionEnabled  파라미터를 통해 제어가 가능하며 다음의 데이터들이 암호화 됩니다.

• 동기화, 백업 및 스왑 작업 중 디스크 
• Amazon S3에 저장된 백업 파일들
• 데이터 계층화가 활성화된 클러스터의 SSD에 저장된 데이터 

파라미터 변경은 불가능하여 해당 옵션을 사용하기 위해선 백업 및 클러스터 재구성이 필요합니다.

인증 및 권한 기능 : 전송 중 암호화를 사용하는 클러스터의 경우 ElastiCache RBAC, Redis OSS Auth 2가지 제어 방법이 있습니다.

RBAC : 6.0 이상 버전부터 사용이 가능한 기능으로 사용자 그룹을 통해 액세스를 제어가 가능합니다. ACL 기능에 기반하며 사용자별 명령어, key에 대한 제한도 가능합니다.

Redis OSS Auth : Redis OSS 인증 토큰 또는 비밀번호를 사용하면 Redis OSS에서 클라이언트가 명령을 실행하기 전에 비밀번호를 요구하여 데이터 보안을 개선할 수 있습니다.

https://docs.aws.amazon.com/ko_kr/AmazonElastiCache/latest/red-ug/Clusters.RBAC.html

 

ElastiCache 서브넷 그룹

Amazon VPC에서 클러스터를 생성하는 경우 캐시 서브넷 그룹을 지정해야 합니다. 해당 캐시 서브넷 그룹을 사용하여 해당 서브넷 내에서 캐시 노드와 연결할 서브넷 및 IP 주소를 선택합니다.

 

ElastiCache (Redis OSS) 백업 및 동기화

백업을 사용하여 기존 클러스터를 복원하거나 새 클러스터를 시드할 수 있습니다. 백업은 클러스터의 모든 데이터와 일부 메타데이터로 구성됩니다.

클러스터에서 실행되는 Redis OSS 버전에 따라 백업 프로세스에 필요한 예약 메모리 양도 달라집니다.

 

2.8.22 이후의 포크리스 방식이 추가 지원됩니다.

포크된 백업을 지원할 만큼 메모리가 충분하지 않으면 ElastiCache는 협력적 백그라운드 처리를 사용하는 포크리스 방식을 사용합니다.

포크된 저장 프로세스를 지원할 만큼 메모리가 충분한 경우 이전 Redis 버전과 동일한 프로세스가 사용됩니다.

2.8.22 이전 버전 및 동기화 및 백업 구현 방법 : 기본 노드와 복제 노드간의 백업 및 동기화를 지원합니다.
동기화는 다음과 같은 순서로 진행됩니다

1.  포크하여 백그라운드 프로세스에서 특정 시점 스냅샷을 생성합니다.
2.  포그라운드에서 변경 로그를 버퍼에 축적합니다.
3.  캐시 데이터, 변경 로그를 복제 노드로 전송합니다.
   
   
   

스냅샷 생성 시 유의사항

reserved-memory-percent 파라미터 설정 값
ElastiCache 클러스터 구성에서 백업, 장애 조치 시에 해당 파라미터로 예약한 메모리 공간을 통해 작업 동안의 요청되는 쓰기 작업들을 기록합니다.

 

 

읽기 전용 복제본에서 백업 생성이 가능합니다. 이럴 경우 Primary Node에서는 영향을 받지 않고 계속해서 요청 처리가 가능합니다.

 

ElastiCache 이벤트

캐시 클러스터에서 중요한 이벤트가 발생하면 특정 Amazon SNS 주제에 알림을 ElastiCache 보낼 수 있습니다. 

클러스터, 노드, 파라미터 그룹 등의 리소스에서 발생하는 중요한 상태 변경 사항을 기록합니다. 여기에는 노드 재시작, 노드 추가/삭제, 장애 조치(failover), 백업 완료 등과 같은 주요 이벤트가 포함됩니다.

콘솔을 통해서는 24시간 동안의 이벤트를 확인할 수 있으며 AWS CLI의 명령어 aws elasticache describe-events 를 통하여 최대 14일 분의 데이터를 확인할 수 있습니다.

 

스케일링

수동 스케일링

Redis OSS 클러스터 크기 조정작업	Redis OSS (클러스터 모드 비활성화)	Redis OSS (클러스터 모드 활성화)
노드 축소	노드 삭제	노드 삭제, 온라인 샤드 제거 및 리밸런싱
노드 확장	노드 추가	노드 추가, 온라인 샤드 추가 및 리밸런싱
노드 유형 변경 → 샤드를 추가 삭제하는 작업은 온라인으로 작업이 되지만 스케일 업다운은 장비를 프로비저닝 한 이후 데이터 동기화 및 dns 이동이 필요하여 dns 이동 시점에서 기존 장비들에 대한 연결이 끊기는 단절이 발생합니다.	단일 노드 동일한 가용 영역에 요청 인스턴스 타입으로 클러스터가 생성됩니다. 기존 클러스터의 데이터가 새 클러스터로 복사됩니다. 이 프로세스의 기간은 노드 유형 및 클러스터에 있는 데이터의 양에 따라 달라집니다. 신규 클러스터를 사용하여 읽기 및 쓰기를 수행합니다. 신규 클러스터의 엔드포인트가 이전 클러스터의 엔드포인트와 동일하므로 애플리케이션에 있는 엔드포인트를 업데이트할 필요가 없습니다. DNS 항목이 업데이트되는 동안 기본 노드의 읽기 및 쓰기가 잠깐(몇 초) 중단될 수 있습니다. 이전 클러스터를 삭제합니다. 이전 노드에 대한 연결이 끊어지기 때문에 이전 노드의 읽기 및 쓰기가 잠깐(몇 초) 중단될 수 있습니다. 다중 노드 요청 인스턴스 타입으로 클러스터가 생성됩니다. 현재 Primary 노드에서 신규 Primary 노드로 모든 데이터를 복사합니다. 신규 Replica 노드를 신규 Primary  노드와 동기화합니다. DNS 항목이 신 노드를 가리키도록 해당 항목을 업데이트합니다. Redis OSS 5.0.5 이상의 경우 클러스터가 온라인 상태를 유지하고 들어오는 요청을 처리하면서 자동 장애 조치가 활성화된 클러스터를 확장할 수 있습니다. 이전 클러스터를 삭제합니다. 이전 노드에 대한 연결이 끊어지기 때문에 이전 노드의 읽기 및 쓰기가 잠깐(몇 초) 중단될 수 있습니다.	온라인 변경 가능 확장 및 축소 프로세스는 새로 선택한 노드 유형을 사용하여 클러스터를 생성하고 새 노드를 이전 노드와 동기화합니다
샤드 수 변경	X	온라인/오프라인 리샤드 및 리밸런싱 사용 가능

 

https://docs.aws.amazon.com/ko_kr/AmazonElastiCache/latest/red-ug/Scaling-self-designed.html

 

※ Cluster 모드에서는 대부분의 작업이 온라인으로 처리가 가능한 것으로 보였습니다.

Non Cluster 모드에서는 복제본이 없는 경우 초단위 중단이 발생하며 복제본이 있는 경우 5.0.5 버전 이상에서는 온라인 상태를 유지하며 타입 변경이 가능한 것으로 내용을 이해하였습니다.

 

오토 스케일링

사전 조건 

ElastiCache (Redis OSS) Auto Scaling은 다음과 같이 제한됩니다.

• Redis OSS 엔진 버전 6.0 이상을 실행하는 Redis OSS (클러스터 모드 사용) 클러스터
• Redis OSS 엔진 버전 7.0.7 이상을 실행하는 데이터 계층화 (클러스터 모드 사용) 클러스터
• 인스턴스 크기 - Large, XLarge, 2XLarge
• 인스턴스 유형 패밀리 - R7g, R6g, R6gd, R5, M7g, M6g, M5, C7gn

 

샤드와 복제본 단위로 오토 스케일링이 가능합니다.

오토 스케일링을 하기 위해선 사전에 클러스터에 특정 지표의 특정 임계치 설정이 필요합니다.

샤드에서 설정 가능한 임계값은 아래와 같고 35% ~ 70%로 설정 가능합니다.

• 프라이머리 CPU 사용률: 프라이머리 노드의 EngineCPUUtilization 지표에 대한 대상 값을 유지합니다.
• 용량 : DatabaseCapacityUsageCountedForEvictPercentage 지표의 목표 값을 유지합니다.
• 메모리 : DatabaseMemoryUsageCountedForEvictPercentage 지표의 목표 값을 유지합니다.

복제본의 경우 아래의 지표로 임계치 설정이 가능하빈다.

• ElastiCacheReplicaEngineCPUUtilization  AVG EngineCPU 사용률 목표를 35% ~ 70% 사이로 설정할 수 있습니다.

 

추가적으로 CloudWatch 지표를 사용하여 임계치 생성이 가능합니다.

RI 관련하여 비용에서 손해가 많이 발생 할 수 있습니다.

https://docs.aws.amazon.com/ko_kr/AmazonElastiCache/latest/red-ug/AutoScaling.html

 

 

장애조치

사용 가능한 읽기 전용 복제본이 하나 이상 있는 클러스터에서만 MultiAZ를 활성화할 수 있습니다.

MultiAZ를 활성화하면 장애가 발생한 기본 노드가 복제 지연이 가장 짧은 복제본으로 장애 조치됩니다. 

클러스터 구성간에는 장애 완화를 고려하여 구성을 진행해야 합니다.

 

복제 노드의 장애

1. 복제 노드 장애를 탐지합니다.
2. 장애가 발생한 노드를 오프라인 상태로 전환합니다.
3. 동일한 AZ에서 대체 노드를 시작하고 프로비저닝합니다.
4. 새 노드가 프라이머리 노드와 동기화됩니다.

 

Single-AZ

프라이머리 노드에 장애

1. 프라이머리 노드에 장애를 감지합니다.
2. 프라이머리 노드를 오프라인 상태로 전환합니다.
3. 장애가 발생한 프라이머리  노드를 대체하기 위해 새 프라이머리 노드를 만들고 프로비저닝합니다.
4. 새 기본 복제 노드를 기존 복제 노드 중 하나와 동기화합니다.
5. 동기화가 완료되면 새 노드가 클러스터의 프라이머리 노드로 작동합니다.

4단계 까지 Write는 실패하지만 Read는 가능합니다.

 

MultiAZ

프라이머리 노드에만 장애

프라이머리 노드에 장애가 발생하면 복제 지연 시간이 가장 짧은 복제 노드를 프라이머리 노드로 승격시킵니다. 

이후 장애가 발생한 프라이머리가 있던 AZ에 신규 노드를 생성하고 복제로 구성합니다.

1. 장애가 발생한 프라이머리 노드는 오프라인 상태로 전환.
2. 복제 지연 시간이 가장 짧은 복제 노드를 프라이머리로 승격. 일반적으로 몇 초 정도 소요. 
3. 장애가 발생한 프라이머리 노드가 있는 가용 영역에 신규 복제 노드를 생성합니다.
4. 신규 복제 노드가 새 프라이머리 노드와 동기화됩니다.

 

프라이머리 노드 및 일부 복제 노드에 장애

프라이머리 노드 및 하나 이상의 복제 노드에 장애가 발생하면 지연 시간이 가장 짧은 사용 가능한 복제본이 기본 클러스터로 승격됩니다. 또한 기본으로 승격된 복제본 및 장애가 발생한 노드로 새로운 읽기 전용 복제본이 동일 가용 영역에 생성되고 프로비저닝됩니다.

기본 노드와 일부 읽기 전용 복제본에 장애가 발생하면 ElastiCache MultiAZ는 다음을 수행합니다.

1. 장애가 발생한 프라이머리 노드 및  복제 노드가 오프라인 상태로 전환됩니다.
2. 복제 지연 시간이 가장 짧은 사용 가능한 복제 노드를 프라이머리 노드로 승격시킵니다.
3. 장애가 발생한 노드의 가용 영역에서 신규 노드를 생성합니다.
4. 모든 클러스터가 새 프라이머리 노드와 동기화됩니다.

 

전체 노드에 장애

모든 노드에 장애가 발생하면 가용 영역에 노드를 생성합니다..

이 시나리오에서는 클러스터의 모든 노드에 장애가 발생하여 클러스터의 모든 데이터가 손실됩니다.

전체 클러스터에 장애가 발생하면 ElastiCache MultiAZ는 다음을 수행합니다.

1. 장애가 발생한 노드가 오프라인 상태로 전환됩니다.
2. 신규 프라이머리 노드를 생성합니다.
3. 신규 복제 노드를 생성합니다.
4. 전체 클러스터에 장애가 발생했으므로 데이터가 손실됩니다.

 

※ ElastiCache MultiAz , clusterd, non clustered 의 fail over 차이

single az인 경우 primary가 죽으면 신규 primary를 생성하고 기존의 read replica에서 데이터를 동기화 이후에 완료가 되면 서비스가 재 실행됩니다.

multi az인 경우 primary가 죽으면 다른 여러 az에 있는 read replica 중 가장 복제 지연이 적은 node를 primary로 promote 시키고 신규 복제본을 생성하며 서비스가 유지됩니다.

 

계획된 노드 교체의 경우

클러스터모드, 5.0.6 버전 이상의 Multi-AZ가 활성화된 비클러스터모드 는 쓰기 요청을 처리하면서 계획된 노드 교체를 진행 할 수 있습니다.

비 클러스터 모드의 경우 장애 조치 기능을 미사용 할 수 있으며 클러스터 모드는 장애 조치가 필수적으로 발생합니다.

 

https://docs.aws.amazon.com/ko_kr/AmazonElastiCache/latest/red-ug/AutoFailover.html#AutoFailover.Scenarios

 

버전관리

클러스터 모드, 5.0.6 이상의 MultiAZ 가 활성화된 비 클러스터 모드의 ElastiCache 는 가동 중지 시간을 최소화하면서 클러스터 버전을 업그레이드할 수 있습니다.

전체 업그레이드 과정 중에도 클러스터를 읽을 수 있으며, 몇 초 정도 시간이 걸리는 장애 조치 작업 중인 경우를 제외하면 대부분 업그레이드 기간 중에 쓰기도 가능합니다

https://docs.aws.amazon.com/ko_kr/AmazonElastiCache/latest/red-ug/VersionManagement.html

 

엘라스틱캐시 Redis는 7버전으로 업그레이드하면서 성능이 향상되었다는 내용을 보았었는데 이에 대한 배경은 신규 기능의 도입이 있었다.

멀티플렉스IO 를 지원하는데 이 기능으로 클라이언트와의 통신 성능이 향상되어 더 빠른 처리가 가능하게된거였다 (레디스 자체의 명령어 처리는 여전히 싱글스레드)