AWS ElasticCache는 AWS의 in memory cache로 SaaS 형태로 제공됩니다. ElastiCache는 AWS에서 S3, EC2, RDS, CloudFront 다음으로 많이 사용하는 서비스입니다.
엔진은 Memcached와 Redis를 지원합니다. 현재 Memcached는 1.4.5, Redis는 2.8.X, 3.1까지 지원합니다. 따라서 ElastiCache Redis의 경우 Cluster가 지원되지 않습니다. 지원됩니다. Replication Cluster를 통해 HA 구성을 해야 합니다.
기존 IDC 혹은 VM 위에 Redis를 구성했을 경우와 ElastiCache(Redis)를 사용할 경우 비교 및 제약 사항
1. HA 구성
- 만약 Redis 구성을 직접 수행한다면, SE는 서비스 형태에 따라 HA 구성을 고려해야 합니다. (Sentinel, proxy..)
AWS ElastiCache Redis를 사용할 경우, Multi-AZ를 통해 Failover가 가능합니다. (DNS)
2. Public Access 불가
- ElastiCache는 기본적으로 같은 VPC 내의 EC2 Instance에서만 접근 가능합니다.
3. 계정 생성 불가
- 보안을 위한 계정 생성이 불가합니다. 기본적으로 Security Group를 통해서 접근 제어를 합니다.
4. 튜닝 제약
- AWS에서 정의된 파라미터만 변경 가능합니다. 또한 파라미터 변경 후 reboot 작업이 필요합니다. (데이터 날아감)
(http://docs.aws.amazon.com/ko_kr/AmazonElastiCache/latest/UserGuide/ParameterGroups.Redis.html)
5. 비용
단순히 EC2 * 2 vs ElastiCache * 2node를 비교하면 ElastiCache 사용 비용이 약 15%정도 비용이 비쌉니다.
6. Read Replication의 Cluster Node DNS는 제공되지 않습니다. Client 단에서 Hash 형태로 각각 DNS node를 사용해야 합니다.
7. 모든 Node는 동일한 Type으로 통일되야 합니다. 만약 Type 변경을 할 경우 Downgrade는 불가하며 변경이 완료될 때까지 Redis 접근은 불가합니다. 기존 데이터는 보존됩니다.
[간단한 실습]
[AWS Console] > [ElastiCache] > [Redis]
ElastiCache의 Multi-AZ는 RDS의 Multi-AZ와 약간 차이가 있습니다. RDS의 Multi-AZ의 경우는 단순한 Slave 개념입니다.
반면 ElastiCache의 Multi-AZ는 장애 발생 시 생성한 Replication Node를 자동적으로 Primary Node(Master_read/write)로 승격됩니다. (RDS Aurora와 같음)
Parameter는 default보단 변경이 필요할 수 있으므로, 먼저 생성하고 Parameter Group을 매핑해주는게 좋습니다.
*Replication 선택, Mutli-AZ를 선택하지 않음: Master 장애 발생 시, Read Replication은 Slave 상태를 유지합니다. 사용자가 직접 Slave를 Master로 승격시켜야 합니다.
*Replication 선택, Multi-AZ 선택: Master 장애 발생 시, Read Replication을 Master로 승격하고 Primary Node DNS가 이관되어 사용자는 write를 기존처럼 사용할 수 있습니다.
기존 Master가 복구되면 Read Replication이 됩니다. 만약 Read job을 따로 구분해서 사용하고 있었다면 Client Side에서 Replication DNS는 사용자가 직접 변경을 해야 합니다. (Route53 private DNS 처리 권장)
S3 Location of Redis RDB file: RDB 파일을 Redis에 Import 시킬 때 S3 경로입니다. (초기 데이터가 없으므로 비워둡니다.)
RDS 설정과 다르게 Public Access 옵션이 없습니다. VPC 내에서만 Access가 가능합니다.
Backup/Maintenance는 RDS 설정과 동일합니다.
대략 5~10분 이내로 Replication Cluster가 구성된 Redis를 구축할 수 있습니다.
Redis가 생성되면 Replication Groups에서 Primary Endpoint를 확인할 수 있습니다. Primary Endpoint는 Master Node의 DNS입니다.
Master에 장애가 생기거나, AWS 정기적인 maintenance가 수행되면 read replica가 Master로 승격되고, Primary Endpoint를 사용할 수 있습니다. 기존 Master Node는 read replica node가 됩니다. (multi-az를 선택하지 않았다면 해당 장애 시간동안 Primary Endpoint에서 Read/Write 수행이 불가하지만 Action이 활성화 되어 사용자가 Replication Node를 Master로 승격시킬 수 있습니다.) read node를 여러개 사용하면 Client side Cluster에 read node를 추가시켜줘야 합니다.
Modify를 선택한 화면입니다. Backup Node는 기본적으로 Replication으로 선택되어 있습니다.
1 2 3 4 5 6 | [root@ip-10-0-0-123 redis-stable]# redis-cli -h leedoingweb.dmijrs.ng.0001.apn2.cache.amazonaws.com -p 6379 leedoingweb.dmijrs.ng.0001.apn2.cache.amazonaws.com:6379> set name leedoing OK leedoingweb.dmijrs.ng.0001.apn2.cache.amazonaws.com:6379> get name "leedoing" leedoingweb.dmijrs.ng.0001.apn2.cache.amazonaws.com:6379> | cs |
http://redis.io/topics/quickstart을 확인하고, primary end-point에 접근해서 redis-cli를 통해 set, get 테스트합니다.
1 2 3 4 | leedoingweb-002.dmijrs.0001.apn2.cache.amazonaws.com:6379> get name "leedoing" leedoingweb-002.dmijrs.0001.apn2.cache.amazonaws.com:6379> set name leedoing2 (error) READONLY You can't write against a read only slave. |
Read Replica Node는 get만 가능합니다.
Slave를 Replication Groups에서 Promote를 통한 Master 임의 변경 시 순단 현상은 없었습니다. RDS와 같이 Primary DNS의 CNAME이 Slave Node로 변경됩니다. 데이터는 삭제되지 않습니다.
Redis Scale Up을 진행할 경우 Scale Up이 진행되는 동안 Redis 접근은 불가하며, 기존 데이터는 보존됩니다. 그러나 완료되기까지 Redis 접근이 불가하기 때문에 서비스 중 작업을 위해서는 신규 Redis의 Snapshot을 이용하여 생성해야 합니다. 하지만 Redis End-Point가 변경되기 때문에 개발 단을 수정해줘야 하는 번거로움이 생깁니다. (Route53의 Private DNS 이용 권장)
(https://aws.amazon.com/ko/blogs/aws/elasticache-for-redis-update-upgrade-engines-and-scale-up/)
Cluster 구성의 경우 Reboot을 지원하지 않는다.
AWS Elasticache를 이용하면 기존 대비 제약(버전 문제, 플러그인 설치, 튜닝 등)이 생기나, Maintenance에 대한 장점을 갖기 때문에 현재 상황을 잘 파악하고 적절한 선택을 해야 합니다.
감사합니다.
약 10개월 사이에 Cluster 지원은 물론, Replication Group 메뉴가 없어지는 등 상당히 편해졌다...직관적이다.