[Spring Boot] 캐시 + Spring Boot 인증메일 저장하기

캐시를 왜 쓰는건가요?

캐시가 무엇이고 왜 쓰는지 먼저 알아보기..! 위키피디아에서는 아래와 같이 정의 

캐시(cache, 문화어: 캐쉬, 고속완충기, 고속완충기억기)는 컴퓨터 과학에서 데이터나 값을 미리 복사해 놓는 임시 장소를 가리킨다. 
캐시는 캐시의 접근 시간에 비해 미가공 데이터 또는 1차 데이터(raw data or primary data)에 접근하는 
시간이 오래 걸리는 경우나 값을 다시 계산하는 시간을 절약하고 싶은 경우에 사용한다.

 

쉽게 말해, 자주 사용하는 데이터를 가까운 어딘가에 저장해두었다가, 필요할 때 빠르게 꺼내보기 위한 기술이다. 

 

Java CAS 나 volatile 키워드를 찾아보면 OS까지 내려갈 필요도 없이 자바 언어에서도 이미 캐시가 적용되고 있음을 알 수 있다. 

 

웹 어플리케이션의 서버라면 데이터 조회 성능을 개선하기 위해 캐시를 사용하는 일이 많은 것 같다. 

- 스프링에서 MySQL의 데이터를 꺼내오려면 DB 서버와의 커넥션과 디스크 I/O가 필요하다. 

- 하지만 메모리에 데이터를 캐시 해두면, 그 다음 요청부턴 DB에 접근할 필요 없이 메모리 영역에서 요청을 해결할 수 있어 성능이 개선된다. 

 

Local 캐시 VS Global 캐시

어플리케이션에서 캐시를 적용하려면 로컬 캐시와 글로벌 캐시에 대해 알아야 한다. 

이름 그대로 로컬 영역에 있는 캐시인지, 시스템 전체에서 공유되는 별도의 외부 서버 캐시인지를 의미한다. 

 

로컬 캐시:)

Local Cache는 서버마다 각 캐시 서버를 두고 따로 저장하는 전략이다. 

 

 

장점:

• 고속 접근: 데이터를 사용자의 장치나 서버 내부에 저장하기 때문에, 매우 빠른 데이터 접근 속도를 제공한다.
• 네트워크 의존성: 네트워크 연결이 필요 없거나 연결 상태가 좋지 않은 환경에서도 데이터 접근이 가능하다. 
• 개별 최적화: 사용자 또는 특정 애플리케이션에 맞춘 개별적인 데이터 관리와 최적화가 가능하다. 

 

단점: 

• 데이터 일관성: 각 서버 간의 데이터가 불일치 문제가 다른 서버에서 데이터가 변경되어도 해당 변경 사항이 다른 서버의 캐시에 자동으로 반영되지 않는다. 
• 스케일링 제한: 해당 서버나 장치의 리소스에 제한되어 있기 때문에, 시스템이 확장될 때 캐시 크기 또는 성능이 그 한계에 도달할 수 있다. 이는 전체 시스템의 확정에 제약을 줄 수 있다.
• 리소스 사용의 비효율: 각 서버가 동일한 데이터의 복사본을 로컬 캐시로 유지하게 되면, 중복 데이터 저장으로 인한 메모리 사용이 비효율적일 수 있다. 

Remote Cache

Remote Cache는 로컬 시스템 외부, 즉 원격 서버나 클라우드 기반 인프라에 데이터를 저장하는 캐시 유형이다.

이 캐시는 중앙에서 데이터를 관리하며, 여러 클라이언트 또는 애플리케이션이 공통된 데이터에 접근할 수 있도록 한다. 

 

장점:

• 중앙집중적 관리: 데이터를 원격 서버에 저장하고 관리함으로서 데이터 일관성과 보안을 향상시킬 수 있다. 
• 확장성: 클라우드 기반의 캐시는 높은 확장성을 제공하며, 사용자 수나 데이터 양의 증가에 유연하게 대응할 수 있다. 
• 가용성 및 내구성: 데이터를 여러 위치에 복제함으로써 높은 가용성을 제공하고, 장애 발생 시 데이터 복구가 용이하다. 

단점: 

• 네트워크 지연: Remote cache는 네트워크를 통해 데이터에 접근하기 때문에, 네트워크 지연이 성능에 큰 영향을 미칠 수 있다. 특히 대용량의 데이터를 자주 접근하는 애플리케이션의 경우, 이러한 지연이 눈에 띄게 성능 저하를 일으킬 수 있다. 
• 중앙 집중적 장애 지점: 모든 데이터가 중앙 서버에 위치하는 Remote cache는, 해당 서버에 문제 발생했을 때 전체 시스템에 영향을 줄 수 있는 단일 장애 지점이 될 수 있다. 이는 시스템의 가용성과 신뢰성을 저하 시킬 수 있음. 
• 보안 문제: 데이터가 네트워크를 통해 전송되기 때문에, Remote cache는 데이터 유출 또는 무단 접근과 같은 보안 위험에 더 취약할 수 있음. 

 

두 가지 중 하나를 골라서 사실 이메일 인증코드를 적용하려고 했다. 곰곰히 고민해본 결과 추후에, 상품 판매 관련하여 MSA로 나누자고 팀원과 약속하였고, 이를 통해서 상품 거래를 할 때, 이메일 인증코드를 받을 일이 있을 수도 있다고 판단하였다. 위에와 같은 이유로 글로벌 캐시를 적용하고자 마음 먹었다. 추후에 상품관련 쪽에서 이메일 인증코드가 쓰이지 않는다면 로컬 캐시로 변경할 예정이다.