🎱 REDIS 배포 전략 짜기 - ElastiCache를 처음으로 써보다.

🖤 Intro

이제 REDIS를 배포할때 “어떻게 배포할지”에 대해 고민할 단계이다.

Redis를 배포하는 방법은, EC2에 직접 올리는 방법, 그리고 AWS에서 제공하는 ElastiCache를 사용하는 방법 두 가지가 있는데, 나의 경우 최대한 3-tier 아키텍처 분리 관점에서 아키텍처적으로 가장 깔끔한 방법을 선택하고자 한다. 어떤 방법을 사용하면 좋을지를 알아보자.

🩶 Start

EC2 ? ElastiCache? 뭐가 좋은 선택일까?

일단 우리 프로젝트의 경우, 간단한 직렬화 커스텀 전략만 사용 & Redis의 기능 중 극히 일부 기능인 캐싱 기능만 사용하므로 별다른 커스텀이 필요하지 않다. 또한 소규모 프로젝트이고, 단기간 동안 만들어야 하는 프로젝트 이므로, 자잘한 관리가 자동으로 가능한 시스템이면 더욱 좋다.

ElastiCache는 쉽게 말하면, 보안 설정, 백업, 장애 대비 등의 모든 부가 모니터링 기능들을 AWS가 알아서 해주는 것을 말한다. 단점이 있다면 대신, 모듈/커스텀에 제약이 있다는 것이고, 그냥 EC2 서버를 이용하는 것보다 비용이 더 나올 수 있다는 것이다. 이는 ElastiCache가 노드단위 과금 체계를 유지하고 있기 때문이다.

노드 단위 과금?

ElastiCache에서 Redis 클러스터를 만들 때, 노드 타입(예: cache.t3.micro, cache.r6g.large)과 노드 개수(프라이머리 1개 + 리드 레플리카 몇 개)를 정한다. 여기서 요금은 시간당 노드 요금 * 노드 개수로 계산되이게 1개를 쓰든, 10개를 쓰든 각각 노드별로 24시간 동안 계속 요금이 나가는 식이다.

EC2에 올릴경우, EC2라는 하나의 서버에 대한 요금만 청구되지만, 이는 관리형 서비스이기 때문에 “노드(=Redis 프로세스를 위한 인스턴스)” 단위로 과금되는 것이다.

ElastiCache를 사용해보자!

ec2에 redis를 올릴경우, 가장 큰 문제는 장애 대비, 보안 그룹 관리, 백업 등의 복잡한 운영 요구사항들을 내가 직접 구성해야 한다는 것이다. 특히 Sentinel/클러스터를 직접 구성해야 한다.

보통 장애 대비를 위해 Sentinel을 두거나 여러대를 묶어서 하나의 클러스터로 관리를 하게 되는데, 이 둘 중 하나의 모드를 택해서 서버가 죽는 상황에서도 대비할 수 있도록 구성해야 한다

ElastiCache의 경우는 이 모든 과정이 자동화 되어 있어서 마스터 죽으면 자동으로 리드레플리카를 승격 시키는 방식으로 이에 대한 대비를 한다.

사실 우리 프로젝트의 규모는 직접 운영 감시를 해야 할 정도로 사이즈가 큰 프로젝트는 아니지만, 금융 프로젝트라는 도메인 특성상 서버 장애 대비와 보안 관리는 매우 중요한 요소이다.

그러나 시간이 짧은 만큼, 이 모든걸 다 고려하는 것은 사실상 무리이다. 그러므로 우리는 이 모든것을 대신해서 관리해주는 ElastiCache를 사용해보자

그렇다면 serverless? 일반 elasticache?

eleaticache에는 두 가지 버전이 있다. 하나는 serverless고, 하나는 일반 버전이다. 이 두가지의 차이가 뭔지를 알아보고, 우리 프로젝트에서는 어떤 것을 적용하면 좋을지를 알아보자.

serverless의 경우, AWS가 자동으로 용량을 관리해주고, 트래픽에 따라 자동으로 확장/축소를 도와준다. 즉, 인프라 관리를 전부 AWS가 자동으로 해주므로, 인프라 관리에 신경 쓸 필요가 없다.

그에 비해 일반 elasticache는 실행한 인스턴스 시간만큼 고정 비용 지불하며, 인프라 관리는 우리가 따로 해줘야 한다. 그러나 더 세밀한 튜닝이 가능하고, 네트워크와 메모리 설정을 직접 제어할 수 있다는 장점이 존재한다.

이렇게 말만 들으면 serverless가 더 좋을 것 같지만, 여기에는 치명적인 단점이 존재한다. 바로 API 요청당 비용이 청구된다는 것이다. 즉, 단기적으로 진행하면서 챗봇 한 마디 한마디에 API 요청을 해야 하는 우리로써는 굉장히 불리한 구조이다.

일반 ElastiCache가 인스턴스 비용만 지불하면 되는 것과는 애초에 다른 구조인 것이다.

또한, 우리의 경우 트래픽이 불규칙해서 유동적 조절이 필요한 애플리케이션이 아니므로, 굳이 serverless를 사용할 필요가 없다.

즉 우리는 이러한 이유로 일반 elasticache + t3.micro와 같은 작은 인스턴스 조합으로 실습해보도록 하자.

⭐ ElastiCache에 우리 REDIS 배포하기

모든 설정 과정은 공식문서의 다음 단계를 기반으로 한다.

ElastiCache 설정 - Amazon ElastiCache

이를 설정하기 위해서는 캐시에 연결할 EC2 인스턴스가 있어야 하는데, 나의 경우는 예전에 시범상 사용했던 EC2가 있어서 이걸 사용하기로 하였다.

testEc2를 이용해보도록 하겠다.

REDIS를 위한 인바운드 보안 규칙 하나 추가하기

redis (elasticache)에서 ec2에 접근할 수 있어야 하므로, 다음과 같이 인바운드 규칙을 새로 추가했다.

이는 elasticache에서 사용할 보안 규칙을 생성하는 과정이다.

나의 경우는 개발 용도로도 사용해야 해서 일단 내 ip에서 접근할 때도 같이 열어주었다.

기본적으로 VPC의 경우, 프라이빗 IP로 연결 요청하기 때문에 EC2의 프라이빗 IP를 연결 가능하도록 만들어 줘야 한다.

우리 프로젝트의 경우,,기본적으로 데이터 팀이 다 레디스에 접근할 수 있어야 해서 IPv4 포트를 0.0.0.0으로 열어야 하나 하는 고민이 있었는데 이럴 경우 해킹 위험이 너무 크다고 한다…..

이걸 SSH로 접속하는 방법, 우회하는 방법, 개발중에는 일단 각자 로컬 Redis를 이용하는 방법, 인바운드 규칙에 레디스를 쓰는 팀원들의 ip를 추가하는 방법 등 방법은 여러가지가 있는데 이건 어떻게 할지 고민을 해봐야 할 것 같다..!

ElastiCache 새 캐시 하나 생성하기 - Valkey 캐시

Redis OSS 서버리스 캐시 생성 - Amazon ElastiCache

이제 사용할 보안 인바운드 규칙까지 하나 만들었으니 elasticache를 생성해보자.

ap-northeast-2.console.aws.amazon.com

해당 사이트에서 생성이 가능하다.

우리는 Valkey 캐시를 생성할 것이므로, 이걸 눌러주고, 인스턴스 생성하듯이 생성하면 된다.

Valkey 캐시 vs Redis OSS 캐시

문득 궁금한 점이 생긴게, 원래 Redis OSS 캐시를 생성하려다가 Valkey 캐시가 비용이 더 저렴하대서 이쪽으로 노선을 튼 것인데, 둘은 어떤 차이가 있는걸까?

찾아보니 딱히 기능상의 큰 차이는 없고, 노드 기반에서 20% 저렴하다고 한다. 특히 우리처럼 단기적인 프로젝트에서 비용을 아끼고자 할때 더 좋은 선택이 될 것 같다.

이제 생성을 시작해보자.

엔진은 Valkey, 배포 옵션은 서버리스가 아닌 자체 캐시 설계, 생성 방법은 간편한 생성으로 편리하게 생성해준다.

참고로 캡쳐는 못했지만, 인스턴스 용량 크게 잡으면 비용 폭탄 맞으므로 구성은 데모(t4g.micro)로 설정해준다.

연결 설정은 다음과 같다.

중요한 것은, VPC가 내가 연결할 인스턴스의 VPC와 같아야 한다는 점이다.

좀 오래 기다리다보면… 다음과 같이 캐시가 생성된다.

ElastiCache설정을 server에 연동하기

나의 경우 local에서 개발할때는, redis가 더이상 window를 지원하지 않아서 docker로 containering을 한 다음에 개발했었는데, ElastiCache에 올릴 경우, ElastiCache에서 알아서 환경 설정을 해주므로 docker로 감싸서 올릴 필요가 없다고 한다! 그래서 그거에 맞춰서 배포를 시작해 볼 것이다.

아, 그전에 우리가 만들었던 redis 보안 그룹을 추가해주는것도 잊지 말자.

  data:
    redis:
      host: localhost
      port: 6379

초반에 local에서 개발할때 설정했던 yml 파일이다.

여기서 host를 우리 ElastiCache의 환경으로 맞추면 된다.

생성된 ElastiCache에 가보면, 다음과 같이 구성 엔드포인트가 있다. 이걸로 바꿔주면 된다.

spring:
  config:
    import: optional:file:.env[.properties]
  datasource:
    url: ${DB_URL}
    username: ${DB_USERNAME}
    password: ${DB_PASSWORD}
  jpa:
    hibernate:
      ddl-auto: create #ddl 생성을 위해 일단 create로 설정
    open-in-view: false
  jackson:
    property-naming-strategy: SNAKE_CASE
    time-zone: Asia/Seoul
  data:
    redis:
      host: ${REDIS_HOST:localhost}
      port: ${REDIS_PORT:6379}

다음과 같이 .env 환경 변수로 주입받도록 설정했다.

여기까지 설정을 마쳤으면 거의 다 된 것이다!!! 축하축하한다

이제 애플리케이션 서버를 실행해서 redis 연결 로그가 잘 찍히는지를 보면 된다.

logging:
  level:
    org.springframework.data.redis: DEBUG
    io.lettuce: DEBUG

참고로 나는 로그가 잘 안보여서 yml에 해당 설정을 추가했다.

2025-09-07T16:08:42.868+09:00 DEBUG 32168 --- [  restartedMain] o.s.d.r.l.RedisMessageListenerContainer  : Postpone listening for Redis messages until actual listeners are added

레디스 리스너 연결이 완료되었다. 정상적으로 연결이 완료된 것을 볼 수 있다!