[AWS]EC2 내부 Redis vs ElastiCache 선택할 때 고민사항

개인 프로젝트에서 검색어 자동완성 기능을 구현하기 위해 Redis를 활용하였다.

그래서 배포환경에서는 Redis를 어디에 둬야할까 고민을 해보았다.

(일단 나는 AWS 프리티어 사용자로서 매달 연속해서 사용할 수 있는 EC2는 한 대 뿐이다.)

 

두 가지 선택지가 있었다.

1. EC2 내부에 Redis를 설치하여 개발환경과 같이 localhost로 사용하기
2. 별도의 캐시 서버 구성하기

오늘은 두 가지 선택지 중 하나를 결정하기 위해서 생각한 고민을 정리하고자 한다.

---

EC2 내부 로컬 Redis

Redis를 EC2 내부에 직접 설치하여 운영하는 방식이다.

[장점]

• 매우 간단하고 .properties 파일에 연결정보 또한 로컬환경과 동일하게 가져갈 수 있다.
• 하나의 EC2 내부에서 동작하기에 운영비용이 절감된다는 장점이 있다.

[단점]

• Redis 관리의 문제

나는 Redis에 대해 깊게알지 못하여 관리적인 측면에서는 확실히 부족하다. 

이러한 캐시 유지관리 및 보안, 모니터링 관련해서는 확인하기 힘들다. 

• 확장성 문제

만약 나중에라도 스케일 아웃하여 다중 서버환경으로 변경한다면 캐시서버를 어차피 따로둬야 한다는 것이다. 

이러한 혹시모를 확장성과 유연성 문제에 대해 대응하기 위해서라고 캐시서버를 별도로 구성해야 한다고 생각했다.

---

별도의 캐시 서버 구성하기

별도의 캐시 서버를 구성하는 것이다. 이 때도 직접 Redis 클러스터를 구성하는 것과 AWS ElastiCache를 사용하여 간단히 캐시 서버를 구성하는 두 가지 선택지가 있었는데 프리티어 사용자는 매달 750시간 무료로 사용이 가능하기에 ElastiCache를 사용하기로 결정했다.

 

[장점]

• 별도의 캐시서버가 존재하기에 확장성과 가용성이 뛰어나다.

다중 서버환경으로 변경한다고 하더라도 여러개의 서버를 캐시서버를 바라보게 함으로서 쉽게 확장이 가능하다.

• ElastiCache는 완전 관리형 캐시 서비스를 제공한다.
• 복제 및 샤드, 백업, 모니터링, 보안 등을 지원하므로 운영이 간단하다.

개발자가 생각해야할 여럭가지 사항을 지원해줌으로써 관리 비용이 줄어든다.

[단점]

• 상대적으로 높은 비용 부담

ElastiCache도 AWS의 서비스이므로 사용한만큼 비용을 지불해야한다. 현재 나는 프리티어 사용자라 하나의 클러스터는 750시간 무료지만 프리티어가 종료되면 비용을 지불해야한다.

---

프리티어 사용자에 간단한 토이프로젝트를 진행하는 나로써는 1번 선택지도 괜찮아보이지만 아무리 토이프로젝트라고해도 확장성과 유연성 등을 고려하지 않고 진행하는 것은 좋지못하다고 생각한다. 프리티어가 종료되면 환경을 변경해야하지만 이번에는 ElastiCache를 사용하기로 결정했다.