1. 현업에서 EC2에 Redis를 설치해서 쓰지 않고 ElastiCache를 쓰는 이유
예시
EC2에 MySQL을 직접 설치해서 DB 서버처럼 써도 괜찮지만, 직접 MySQL을 깔고 이것저것 설정하는 것보단 AWS RDS 서버(AWS에서 세팅해 놓은 DB 서버)를 사용하는 게 여러 가지 부가 기능도 사용할 수 있고 안정성도 높다.
현업에서 EC2에 Redis를 설치해서 쓰지 않고 ElastiCache를 쓰는 이유도 비슷하다. 현업에서 EC2에 Redis를 직접 설치하는 경우는 드물다. 일일이 Redis를 설치하고 세팅하고 관리하면서 확장까지 하려면 신경 쓸 게 생각보다 많다. 그러나 ElastiCache를 사용하면 세팅이나 확장을 쉽게 할 수 있고, 기본적인 모니터링 기능도 제공해 주며 장애가 날 가능성도 훨씬 적다. 이런 이유로 현업에서는 ElastiCache를 많이 활용한다.
- EC2에서 Redis를 설치해 직접 만져보지 않고 바로 ElastiCache를 사용하게 되면, 어떤 식으로 작동하는지 이해하기가 굉장히 어렵다. 따라서 학습을 하는 입장에서는 다 만들어져 있는 서비스를 쓰는 것보단, 처음부터 구축해 보는 게 훨씬 도움이 된다.
아키텍처 구성 변화
a. ElastiCache 도입 전
- EC2 하나에 Spring과 Redis를 같이 두는 경우는 드물다. 취준생 레벨이나, 비용을 극단적으로 갖게 되는 초기 스타트업 입장에서는 EC2에 여러 가지 서비스들을 두는 편이지만, 실제론 조금만 규모가 커져도 이런식으로 서비스를 구성하는 경우는 많이 없다.
b. ElastiCache 도입 후
- Spring용 서버와 RDS용 서버, 캐시(ElastiCache)용 서버를 전부 다 분리시키는 경우가 많다.
2. AWS ElastiCache 셋팅하기
세팅 방법
AWS에서 ElastiCache 검색 후 [지금 시작] 버튼에서 [Rediss OSS] 클릭
- 아래 Memcached는 잘 쓰지 않음
[구성]에서 [자체 캐시 설계]와 [클러스터 캐시] 선택
- 여기서 말하는 클러스터(Cluster)란 여러 캐시 서버를 이루는 한 단위의 그룹을 뜻한다.
- 하나의 캐시 서버는 노드(Node)라고 말한다.
[클러스터 모드]에서 [비활성화됨] 선택
- 대규모 트래픽 처리를 위한 '클러스터 모드'가 있다. 그러나 어지간한 규모의 트래픽이 발생하는 서비스가 아니라면, '클러스터 모드'를 쓸 일은 없다. 나중에 관심이 있다면 따로 공부하도록 하자.
[클러스터 정보]에서 이름 입력하기
[위치]에서 다중 AZ 사용 제
- 다중 AZ(Multi AZ): 여러 Region에 캐시 서버를 나눠서 세팅해 두는 것이다. 특정 Region에서 재난이 발생해 서비스가 중단될 수도 있는 걸 방지하는 기능이다. 그러나 재난이 발생할 가능성은 아주 적은데 비해, 비용은 추가로 발생하기 때문에 재난으로 인해 서비스가 중단되는 게 치명적인 경우가 아니면 사용하지 않는 게 좋다.
- 자동 장애 조치(Failover): 클러스터 내부에 특정 노드(Node)가 장애가 났을 때, 정상 노드(Node)로 교체하는 기능이다. 쉽게 말해 내부에 장애가 일어나는 경우 스스로 고치는 기능이라고 할 수 있다.
- 하나의 클러스터 안엔 모든 기능을 총체적으로 관리하는 Primary Node가 존재하고, 이 Node에 장애가 발생하면 바로 다른 캐시 서버를 Primary Node로 교체시킨다.
[클러스터 설정]에서 노드 유형은 t3.micro로, 복제본 개수는 0으로 설정
- 최소한의 비용으로 테스트하기 위해 복제본 개수는 0으로 설정한다.
- 복제본 개수가 늘어날수록 노드(Node)가 늘어난다. ElastiCache는 노드(Node) 당 가격을 매기고 있다.
- 복제본 개수가 1 이상이어야만 Failover 기능을 활용할 수 있다. 이 때문에 프로덕션에서는 복제본 개수를 1개 이상으로 만드는 경우가 많다.
[연결]에서 이름만 입력하고 밑으로 내려 [다음] 버튼 클릭
EC2 서비스로 가서 보안그룹 생성하기
- 인바운드 규칙: Redis 서버에 어떤 트래픽만 접근할 수 있게 만들 것인지 정하는 것
- 아래는 6379 포트로 모든 IP의 접근을 허용하는 것이다.
- ElastiCache 서비스는 기본적으로 같은 VPC 내에서만 접근(외부 IP 접근이 막힘)할 수 있게끔 세팅되어 있기 때문에 보안적으로 문제가 생기지 않는다.
ElastiCache 세팅으로 돌아와 [보안그룹] 세팅하기
[백업]에서 [자동 백업 사용] 해제하고 모두 넘긴 뒤 [생성] 버튼 누르기
- 임시로 데이터를 저장(TTL)하는 캐싱 용도로 쓸 것이기 때문에 백업 옵션은 해제해 둔다.
AWS ElastiCache가 정상적으로 잘 생성됐는지 확인하기
ElastiCache 대시보드 들어가서 [기본 엔드포인트] 주소에서 포트 번호 빼고 복사하기
- 기본 엔드포인트: Primary Endpoint로, 주로 모든 걸 총체적으로 관리하는 권한을 가진 Redis의 주소
- 리더(Reader) 엔드포인트: 읽기 전용 주소
EC2에 연결해서 ElastiCache에 접속해 보기
- ElastiCache는 같은 VPC일 때만 접속할 수 있기 때문에 로컬 환경에선 접속이 안 되는 걸 알 수 있다.
# redis-cli -h {호스트 주소}
$ redis-cli -h {ElastiCache의 기본 엔드포인트}
3. Spring Boot에 ElastiCache 연결하기
연결 방법
application.yml 파일 수정하기
- GitHub Repository에 Push 하고 EC2에서 Git Pull 받기
...
---
# prod 환경
spring:
config:
activate:
on-profile: prod
datasource:
url: jdbc:mysql://{RDS 주소}:3306/mydb
username: admin
password: password
data:
redis:
host: {ElastiCache 기본 엔드포인트}
port: 6379
기존 Docker Compose 서버 종료시키고 Spring Boot 프로젝트 실행하기
$ docker compose down # 이전 실습에서 실행시켰던 컨테이너 종료시키기
$ docker ps # 종료됐는 지 확인
$ ./gradlew clean build -x test
$ cd build/libs
$ java -jar -Dspring.profiles.active=prod {빌드된 jar 파일명}
실제 ElastiCache에 캐시가 저장되고 있는지 확인해 보기
- 새로운 EC2 연결 창을 열어서 아래 명령어를 통해 ElastiCache에 접속하기
$ redis-cli -h {ElastiCache의 기본 엔드포인트}
$ keys *
$ get getBoards::boards:page:1:size:10
$ ttl getBoards::boards:page:1:size:10
비용이 나가지 않게 지금까지 사용했던 AWS 리소스 종료하기
EC2 인스턴스 종료하기
RDS 인스턴스 종료하기
- 최종 스냅샷 생성과 자동 백업 보존을 체크하면 비용이 나간다. 따라서 실제 운영용 DB가 아니라면 체크하지 않고 삭제한다.
ElastiCache 종료하기
- 백업을 생성하면 비용이 많이 나가므로 [아니요]를 선택하고 삭제한다.
끝!
