[Redis] 레디스를 활용한 캐시 서버 구성

 
 
틀린 내용을 발견하신 경우 말씀 부탁드립니다! 🙇

---

 
현재 다니고 있는 회사의 일부 서비스 페이지 로딩 속도가 느린 이슈가 있었고, 이를 해결하기 위하여 (근본적인 해결책은 아니지만) 레디스를 도입해 캐시 처리를 하기로 했다. 이전에 레디스를 활용하여 API 문서 자동 생성기를 만들어보긴 했으나, 사용자들이 직접 사용하는 서비스에 레디스를 적용한 것은 또 다른 느낌이라 블로그에 기록하기로 했다. 상세한 명령어나 설정 방법은 구글링을 하면 충분히 나오는 것이기 때문에 이번 작업에서 내가 배웠다고 생각한 것들만 간략히 기록하기로...
 
 

0. 왜 Redis를 사용했는가?

'인메모리 저장소에는 Redis 뿐만 아니라 Memcached도 있는데 왜 Redis를 사용했나요?'라고 누군가가 물어본다면 아래와 같이 답할 것이다.

① 서버에서 주는 응답 바디는 대부분 json 타입이다. Redis는 다양한 데이터 타입을 제공하기 때문에, Redis를 사용한다면 데이터 저장시 따로 파싱 하는 작업이 필요 없다. (+ 실제로 저장할 때는 stringify하기 때문에 이 내용은 사실 잘못된 것)

② 나중에 캐시 서버를 확장해야 하는 상황이 올 수도 있다. Redis는 복제 기능을 제공하기 때문에, 데이터 유실 없이 서버 확장이 가능하다.

 
 

1. 캐시 대상 선정 과정

각 사용자가 호출하는 모든 데이터를 캐시 서버에 저장할 필요가 있을까? 사용자들이 많이 사용하는 기능 위주(파레토의 법칙), 그중에서도 응답 속도가 느린 것들만 캐시 처리해도 충분하다고 생각한다. 무엇을 캐싱 처리해야 되는지 알아보기 위해 사용자들이 접근한 페이지에 대한 로그를 확인하고 접근 빈도가 높은 페이지들을 나열했다. 그곳들에서 호출하는 모든 프로시저를 정리했고 이 중 실행 속도가 1000ms 이상인 것들을 추려내 캐시 대상으로 선정했다.
 

2. 구조

캐시 대상 프로시저들이 호출되었을 때,
1) 캐시 서버에 캐싱 처리된 데이터가 존재하는지 확인.
2) 있으면 캐시 서버에서 데이터를 갖고와 브라우저에 전달.
3-1) 없으면 프로시저를 호출하여 DB에서 데이터를 갖고 온 뒤,
3-2) 캐시 서버에 값을 저장(Data type: String) 하고 브라우저에 전달.

레디스 서버에 캐시 데이터 있을 경우 / 없을 경우

redis 내에서 db를 선택하여 string data type으로 데이터를 저장하였으며 각 key에 expire을 설정해 일정 시간이 되면 자동으로 데이터가 지워지도록 했다. (select 1, select 2... 같은 방식으로 redis 내에서 db 선택이 가능하다.)
 

3. 레디스 세팅

AWS에서 엘라스틱캐시라고 인메모리 db 서비스를 제공하긴 하는데 이를 도입하기에 별도로 리서치를 해야 되기 때문에 그냥 EC2 서버에 redis를 설치하여 사용하기로 했다. redis 6.2 (stable ver) 설치 후 외부 접속을 허용하기 위해 redis.conf 파일에서 bind 127.0.0.1을 0.0.0.0으로 변경해 주었다. 레디스 서버 세팅 후 서비스 프로젝트가 구동 중인 서버의 outbound에 레디스 서버 ip와 포트(6379)를 추가하여 서버 간 통신이 되도록 했다.
 

4. 적용 후 발생 이슈 및 해결 

캐시 서버를 도입하고 일주일 뒤에 이슈가 생겼다. 신규 데이터 생성 또는 기존 데이터 삭제를 했을 때, 캐싱 처리된 데이터로 인해 변경된 내용이 페이지에 반영되지 않는 것이었다. 이를 해결하기 위해 데이터 생성/삭제 시 특정 키워드를 갖는 key를 scan 하고 hit 된 key들은 del 처리하였다.