캐시
데이터의 실시간성을 약간 포기하고, 큰 성능적 이점을 얻는 것
캐시는 캐시의 접근 시간에 비해 원래 데이터를 접근하는 시간이 오래 걸리는 경우(접근 비용이 비싸다고 표현함)나 값을 다시 계산하는 시간을 절약하고 싶은 경우에 사용한다.
*데이터의 실시간성을 약간 포기 : 데이터 변경/생성의 업데이트가 느릴 수 있다는것.
제가 진행중인 프로젝트에서도 캐싱을 적용하고 있습니다.
클라이언트의 동일한 읽기 요청에 대해 데이터베이스를 접근할때, MySql은 하드디스크 기반의 데이터 저장공간이기 때문에 서버의 메모리보다 훨씬 느린 속도로 데이터를 탐색합니다.
따라서 우리는 Redis의 캐시를 이용해 중간 저장소에서 더 빠르게 정보를 꺼내올 수 있습니다.
Local Cache와 Global Cache
캐시의 저장위치에 따라 Local과 global로 위치를 나눌 수 있습니다.
Local cache
- 데이터 조회 오버헤드가 없다.
외부에 저장된 캐시를 네트워크 통신을 통해 접근, 가져올 필요가 없으므로 데이터 조회 속도가 빠릅니다. - 서버 간 데이터 일관성이 깨질 수 있다.
단일 서버 인스턴스에 캐시 데이터를 저장하기 때문에 여러 서버인스턴스를 사용하는 경우 데이터의 일관성 문제가 생길 수 있습니다. - 서버간 동기화가 어렵고, 비용이 발생한다.
캐시의 일관성 유지를 위해 동기화를 하게 되면 추가적인 비용이 발생합니다.
Gobal cache
- 네트워크 통신 비용 발생
외부 캐시 저장소에 접근하여 데이터를 가져오는 과정에서 네트워크 I/O 비용이 발생합니다. - 데이터 일관성을 유지할 수 있다.
모든 서버 인스턴스가 동일한 캐시 저장소에 접근하기 때문에, 데이터의 일관성을 보장할 수 있습니다.
NestJs 기준 - Redis
결론
- 데이터의 일관성 유지의 중요도에 따라 Local, Gobal을 선택해 캐시를 적용할 수 있습니다.
- 현 프로젝트에서는 이메일 인증번호를 저장하기 위해 캐시를 사용하고 있습니다.
- 사용자의 개인 정보(마이페이지) 등은 서버간의 동기화 이슈로 수정 사항이 반영되는데 시간이 걸리더라도 큰 문제가 생기지 않지만, 이메일 인증번호는 만료시간이 5분 이내이며, 인증번호가 일치할 때 회원가입을 진행하기 때문에 데이터 일관성이 중요하다고 판단되어 Global Cache인 Redis를 적용하였습니다.
- 추후 성능 테스트를 하며 성능개선이 필요하다 판단되면 local cache를 적용해볼 계획입니다.
RDB vs Redis 성능 비교
DB 이메일 요청시 :
23-10-30 오늘 날자로 토큰이 생성되었습니다.
인증번호 DB로 조회 후 일치하면 회원가입 성공 (269ms)
Redis 이메일 인증 요청시 :
토큰이 생성되었습니다.
Redis cache를 통해 토큰 조회후 일치하면 회원가입 성공(296ms)
레디스보다 mysql local이 빠른 이유는
- mysql local이라서 더 빠를 것이다.
- redis는 네트워크를 사용하기 때문에 상대적으로 느릴 것이다(local보다)
- 트래픽량, 분산서버 유무에 따라 데이터 저장소를 고려할 수 있다.
- 현 프로젝트의 이메일 인증 코드는 RDBMS 가 상대적으로 저장 비용이 크다는 점, 이메일 인증코드는 날아가더라도 큰 문제가 생기지 않기 때문에(재발급받을 수 있음) Redis에 저장하도록 하였다.
- 배포시, Redis를 사용하며 추가적으로 비용이 발생한다면 종합적으로 고려해 DB를 선택할 것이다.
출처
