[AWS + Spring] EB + ElastiCache Redis + Spring Boot 연동 (1)

이번 포스팅에선 AWS ElastiCache Redis Cluster를 구축하여 Spring Boot와 연동하고 최종적으로

AWS Elastic Beanstalk에 배포까지 해본다. (Elasticache는 같은 VPC내에서만 접근 가능하기 때문)

단, 이번 포스팅에선 테스트 목적이기 때문에 '싱글 클러스터 노드'로 구축할 것이다.

 

💡 애플리케이션을 배포할 Elastic Beanstalk & Redis 접속을 위한 Bastion-Host가

없으신 분은 해당 링크 참고하여 생성

 

시작하기 앞서, 간단히 살펴보자.

ElastiCache는 알려진 대로 데이터베이스 캐싱을 위해 사용한다.

ElastiCache for Redis를 구축할 때 고민해야 하는 것 중 하나가 바로 클러스터 구성이다.

​

클러스터 구성에 세 가지 옵션이 있다.

① 싱글 클러스터 노드

② 클러스터 모드 없이 Replication만 지원(클러스터 모드 X)

③ 클러스터 모드와 Replication 모두 지원(클러스터 모드 O)

​

Redis는 주노드(Primary node)와 복제 노드(Replica Node)로 구성하는 게 일반적이며, 이런 구성을 shard로 여러 벌 준비하여 data partinioning을 수행하는 것이 클러스터 모드(cluster mode)다.

 

 

각 구성의 특징은 아래와 같다.

	싱글 클러스터 노드	클러스터 모드 X (Replication만 지원)	클러스터 모드 O
데이터 복제 (Replication)	X	O (노드 당 최대 5 replicas)	O (노드 당 최대 5 replicas)
데이터 분할 (Data Partitioning)	O	X (싱글 샤드)	O (최대 90 샤드)
확장성 (Scaling)	노드 타입을 변경하는 수직 확장	노드 타입을 변경하는 수직 확장	샤드의 추가/삭제 및 밸런싱을 통한 수평적 확장
Multi-AZ	X	최소 1 replica 이상의 옵션	필요

 

 

 

클러스터 모드는 언제 쓰면 좋을까?

가용성이 중요한 프로덕션 환경이라면 Replication은 필수적이라 할 수 있다. 다만 Replication은 수직 확장만 지원한다는

단점이 있다.

​

클러스터 모드는 위 테이블에서 볼 수 있듯 샤드를 이용한 수평 확장(scaling)이 가장 큰 특징이다. 이를 응용해 최대 90개 샤드에서 100TB 용량의 큰 데이터 규모로 스케일 확장이 가능하다. 이는 새로운 서비스의 워크 로드의 저장 용량 산정이 어려울 경우에 대한 대비도 가능하다.

​

READ 작업이 많을 때는 하나의 샤드 안에 READ Replica를 추가하는 방식(최대 5개)을 사용하고 WRITE 작업이 많을 때엔 클러스터 모드를 통해 추가적인 WRITE Endpoints(= 추가적인 Primary Node)를 새로운 샤드를 통해 얻어오는 방식이 바람직하다.

​

데이터 샤딩(Data Sharding)

Redis는 모든 캐시 키가 해시 슬롯(hash slot)에 매핑하는 방식으로 샤딩을 활용한다. 1개의 클러스터는 16,384개의 해시 슬롯을 사용할 수 있고 일반적으로 클러스터 내 총 샤드에 균등하게 배포한다.

​

이는 동일한 캐시키를 사용하는 데이터는 모든 Redis 노드에 Read/Write가 가능하단 의미다. 워크 로드가 증가하면 가용성을 확보하고 성능 지연을 줄이기 위해 복수 노드에 워크 로드를 분산한다. 이때에도 Redis 클라이언트는 하나의 endpoint에 접속하며 Redis 내부에서 로드를 분산하는 구조다.

 

실습환경

• Intellij Ultimate
• JAVA 17
• Spring Boot 2.7.3
• Maven
• AWS Elasticache Redis
• 개발 서버 환경 기준 (Not Local)

---

📌 시작하기

Elasticache > Redis 클러스터 > Redis 클러스터 생성 클릭하여 화면 진입

 

1단계: 클러스터 설정

본 포스팅에선 테스트 목적이기 때문에 클러스터 모드 '비활성화' 선택

 

 

 

기본 포트 사용 (6379)

Default 파라미터 그룹 사용

테스트 목적이므로 낮은 메모리 크기인 cache.r5.large 선택

'싱글 클러스터 노드' 이므로, 복제본 개수 0개 설정

 

 

AWS 클라우드 선택

우리는 '싱글 클러스터 모드' 이기 때문에 다중 AZ와 자동 장애조치는 사용할 수 없다.

 

 

 

 

 

 

위 단계에 따라 클러스터 기본 설정을 마쳤으면 고급 설정을 해보자.

 

---

2단계: 고급 설정

고급설정에서 보안그룹 추가

3가지의 보안그룹을 추가해준다.

1. default VPC

2. Elastic Beanstalk (EB 에서 Redis 연결 위함)

3. Bastion Host (같은 VPC인 bastion host로 Redis 접속 위함)

 

 

 

테스트 목적이므로 별도의 설정은 선택하지 않았다.

설정을 마치고 클러스터를 생성하자.

 

 

Redis Cluster가 정상적으로 생성 완료된 모습을 확인할 수 있다.

 

---

EB EC2 보안그룹 수정하기

 

EB의 EC2 인스턴스 보안그룹을 설정한다. 인바운드 규칙에 포트 6379로 한 후 소스에 EB 보안그룹을 선택한다.

 

---

Bastion-Host에서 Redis 연결

EB의 EC2에서 직접 Redis를 접속하는게 아닌, bastion host에서 redis에 접근한다. (EB는 Application Level에서 접근)

 

 

Redis Cluster를 생성할 때 이미 보안그룹에 bastion host의 보안그룹을 추가해준 상태이기 때문에 별도의 설정은 필요 없다.

 

 

 

EC2 > bastion-host > '연결' Tab을 클릭하여 위 화면에 접근한다.

 

 

ssh -i "test-key.pem" ec2-user@[ec2-host-address]

해당 ssh 명령어로 EC2에 접속한다.

 

ElastiCache > Redis 클러스터 에서 노드를 선택하여 엔드포인트를 복사한다.

 

 

Redis와 같은 VPC 안에 Bastion EC2가 있는 상태이다. 만약 다른 VPC에 있을 경우 VPC Peering 설정이 필요하다.

 

Redis를 별도 설치해도 되지만 ec2 에서는 redis-cli만 사용할 것이기 때문에 redis-cli 설치를 한다.

 

1. redis-cli를 설치하기 위해서 gcc를 설치한다.

                                       2. redis-cli를 설치한 후, redis-cli를 사용하기 쉽게 /usr/bin에 복사한다.

3. redis-cli를 통해 Redis Cluster에 접속한다.

 

$sudo yum install -y gcc 
$wget http://download.redis.io/redis-stable.tar.gz && tar xvzf redis-stable.tar.gz && cd redis-stable && make
$sudo cp /home/ec2-user/redis-stable/src/redis-cli /usr/bin
$redis-cli -h [redis host] -p 6379

Bastion EC2에서 위 명령어들을 입력하자.

(redis host는 위에서 복사한 본인의 엔드포인트를 입력)

 

 

 

redis-cli를 통해 성공적으로 Redis에 연결 된 것을 확인할 수 있다.

 

* 만약 redis-cli로 접근했을때 Connection TimeOut이 뜬다면, bastion-host의 인바운드 규칙에 '모든 TCP, 0.0.0.0/0' 

규칙을 추가하길 바란다.

 

 

이어서 다음 포스팅에선 Spring Boot 설정을 하고, Elastic BeanStlak에 배포하여 API 테스트를 진행한다.

 

 

 

 

 

 

 

Reference:

https://m.blog.naver.com/techtrip/222114663016