Redis, 레디스를 사용한 데이터베이스 캐싱서버 운영하기

Redis 서버의 구축 및 운영 등 여러가지 방안에 대하여 생각한 바를 정리한 내용이다. 먼저 Redis 서버가 필요한 이유는 무엇일까...

# Why Redis?

Redis를 왜 구축하는가를 아려면 Redis가 무엇인지부터 알아야한다.

! Redis란?

Redis는 데이터베이스의 여러 솔루션 중 하나로 메모리를 사용하는 키, 밸류 형식의 데이터베이스이다. Redis의 최고 장점은 메모리를 사용하기 때문에 매우 빠른 속도를 자랑한다. 일반적인 하드 디스크에 비하여 상대적으로 엄청나게 빠를수도 있다. 다만 메모리라는 제약으로 공간이 크지 않고 키, 밸류(Key, Value) 형식의 입출력 방식이기에 복잡한 데이터베이스에 적합하지 않다.

위 내용만으로도 장점과 단점이 너무 극명하다. 빠르나 효과적인 주 데이터베이스로 사용하기에 다소 어려워보이는 점이다. 또한 공간이 많아질수록 비용이 급격히 올라가므로 이를 고려한다면 Redis는 빛좋은 개살구일 수 있다... 하지만! 대부분 Redis를 보조 데이터베이스 역할로 그 가치를 최대한 끌어내어 활용하고 있다. 그 중 Redis에 가장 적합한 것이 바로 데이터베이스 캐싱(Caching)이다.

! Caching Database Server

캐싱(Caching)은 말 그대로 미리 읽어두었다가 요청이 올 경우 빠르게 응답하기 위한 목적으로 사용할 수 있다. 이 경우 전체 데이터가 필요없고 데이터 역시 계속 유지될 필요가 없기에 Redis처럼 적은 공간의 데이터베이스에 최적이다. 게다가 빠른 속도의 메모리를 사용하므로 잘 이용한다면 Redis 캐싱은 선택이 아닌 필수가 아닐까? 어찌보면 Redis는 캐싱을 위해 존재하는지도...

! 데이터베이스 캐싱... 꼭 필요한가?

사실 이런 의문이 들 수도 있지만 모든 컴퓨터의 입출력 기술에는 알게 모르게 많은 부분이 캐싱되어 사용되고 있다. 메모리에 올려져 눈에만 안 보일 뿐 대부분이 이미 캐싱되어있지 않을까? 그렇다면 이번에는 웹서비스의 환경을 생각해보자. 아카마이나 CloudFront 등이 서버에서... 데이터베이스 역시 Redis Oracle의 TenTimes등에서 캐싱이 이뤄지고... 로컬 역시 다양한 방식으로 캐싱되며 localStorage, sessionStorage를 사용해서도 클라이언트측 캐싱 서비스가 구축된다.

특히 대용량데이터나 컨넥션이 빈번하게 네트워크가 사용된다면 이에 따른 성능차이는 말로 표현하기 어렵다. 아키텍쳐에서 빠질 수 없는 부분이 바로 캐싱이며 어떻게 구축하고 운영하는가가 매우 중요하다.

# Redis 서버의 운영

여기까지 Redis의 장점과 필요성을 알아봤다면 이제 실제 운영을 위해 고민해보자. 일단 앞에 언급했듯이 Redis를 단독으로 주 데이터베이스로 사용하는 것은 무리가 있다. 텍스트 위주의 데이터라면 가능할 수 있으나 차라리 Expire 시점을 짧게 설정하는 편이 더 나을 것이다. 이는 뒤에 또 다루겠다.

어쨌든 Redis는 별도 서버로 구축되어 주서버와 지속적인 서비스를 주고 받는 방법이 효과적이다. 요즘은 하나에 모든 것을 관리 운영하기 보다 각각의 기능, 필요에 따른 마이크로 서비스(Micro Service) 형태로 많이 운영되어진다. 

# CRUD에 따른 Redis 데이터 처리

Redis서버는 Client에서 Read 요청이 들어올때 주서버로부터 값을 가져와 저장한다. 이때 주서버와 싱크된 데이터 이 외에 추가로 데이터 만료시점을 처리하기 위해서 현재시간이나 만효시간을 함께 저장해야한다.

다음은 클라이언트의 Read 요청에 따른 처리과정으로 아래를 따르게 된다.

! Read 요청시

- 방문자, 사용자의 새로운 데이터 서버에 요청
- Redis 서버에서 요청 데이터가 있는지 확인
- 데이터가 존재하는 경우 만료여부 확인 후 이 정보를 반환
- 정보를 반환한 경우 시간을 현재로 업데이트 후 종료
- 데이터가 만료되었거나 없는 경우 삭제 후 주 서버에 요청
- 주 서버에서 받은 데이터를 캐싱, 데이터베이스에 저장
- 이 값을 방문자에게 반환 후 종료

! CUD Create, Update, Delete 요청시

이 경우 앞의 과정과는 조금 다르다. 그 이유는 데이터에 변화가 생겼으므로 해당하는 값의 데이터는 캐싱 값이 아닌 현재 실시간 정보를 보내주는 것이 효과적이기 때문이다. 캐싱 만료시간이 아무리 짧게 설정되어도 없는 데이터를 사용자가 보게되는 일으도록 해야할 것이다. 그러기 위해 필요한 조치는 비교적 간단하다. CUD 요청시 아래와 같이 처리한다.

- 방문자가 CUD를 서버에 요청
- CUD 요청을 주서버에 반영하여 업데이트
- 변경된 데이터 값을 캐싱데이터인 Redis에서 찾아 삭제 후 종료

여기서 가장 중요한 점은 캐싱을 제공하는 경우 단순하게 정보를 제공하는 주분만 고려하는 것이 아니라 다양한 상황에 대처해야한다는 점이다. 이 중 한 가지가 위와같이 CUD처럼 데이터에 중요한 변경사항이 있는 경우 기존의 캐싱 데이터를 삭제처리하는 과정이다.

! 마치면서

여기까지 Redis 서버에 대하여 간략하게 알아보았다. 서비스를 구축할때 나도 이런 서비스를 제공한다라는 점보다 어떻게 제공하느냐가 매우 중요하다. 캐싱의 방법 역시 다양한 관점에서 고민하고 제공되어야 할 것이다.

! 추가내용

위와같이 클라이언트 사용자의 요청에 따라 데이터를 만료하는 경우 요청이 없는 데이터가 불필요하게 오래 남을 수 있다. 이런 이유로 정기적인 시점... 특히 방문자가 적은 새벽 시점에 만료된 데이터를 clear하는 처리가 요구된다. 이런 작업은 Cron이나 AWS의 람다를 이용하는 것도 좋은 방법이다.