python에 redis 캐싱서버를 완료 후 리뷰

미뤄만왔던 redis cache 서버의 구축이 얼마 전 완료되었습니다. 시작부터 완료까지 있었던 크고 작은 부분들의 로그입니다.

! redis 꼭 필요한가?

사실 대규모 트래픽이 없는 상황에서 반드시 필요한 것은 아니었죠. 다만 향후 로그관리 및 애널리틱스를 위한 트래킹을 별도 관리하려면 언젠가는 꼭 필요한 작업이었기에 더 이상 미루지않기로 했습니다.

# Python에 redis 구축의 난이도

서버 연동부터 설정의 부분들은 어려울 것 없이 이루어졌습니다. redis 자체가 단순한 key, value 방식으로 이루어져 간단한 restful 방식의 SNS 모듈을 별도로 만든 후 import하니 생각보다 금방 끝나더군요. 다만 데이터를 캐싱하기 위해 변환, 저장 및 삭제하는 부분들 그리고 운영하는 부분들까지는 생각지 못한 부분들이 많았습니다. 아래에 좀 더 자세히 다뤄봅니다.

# Redis 구축 과정에서 생각해야할 부분들

구축과정에서 생각치 못했던 부분들이 많더군요. 간단하게 나열해보면 아래의 과정들입니다.

• 무엇을 key 값으로 할 것인가?
• 어떤 데이터를 redis에 저장할 것인가?
• 캐싱의 만료 시간(TTL)은 얼마가 적당한가?
• 정기적으로 redis 비우는 작업이 필요한가?
• 주 데이터베이스와 redis 사이의 싱크를 맞추기 위해 무엇이 필요한가

! 무엇을 key값으로 할 것인가

모든 글들이 /날짜/제목/을 기반으로 라우팅이 설정되어 redis에 id를 키로 저장할 방법이 없었습니다... id를 알기 위해 주db를 한번 더 콜한다면 redis의 목적이 희석되겠죠..

! 어떤 데이터를 redis에 저장할 것인가?

저장 할 데이터가 너무 많아질 경우 redis의 성능은 주서버보다 늦을 수 있습니다. 저장할 데이터가 많지 않다고해서 모든 데이터를 저장할 필요는 없겠죠. 다른 데이터 콜에 영향을 줄 수 있으니까요. 제 경우 작성된 포스트 내용이 거의 모든 트래픽이므로 포스팅 내용과 페이지에 보여주는 데이터를 최소화하여 캐싱을 적용하였습니다.

! 캐싱 만료 시간은 얼마가 적절한가?

어떤 데이터이냐... 보안과 관련도가 있냐 등 다양한 생각이 필요합니다. 여러사람이 데이터를 CUD 생성, 변경, 삭제하는 경우 주 데이터베이스와 싱크를 맞추기 위해 너무 많은 콜 필요합니다.

! 정기적으로 redis 비우는 작업이 필요한가?

이 부분 역시 고민이 되었습니니다. ttl을 설정해두어 자동으로 expired된 아이템이 삭제되고 주서버에서 반영되지만 최근 CUD되지 않거나 새롭게 읽히지 않는 포스트들은 메모리에 계속 남기 때문입니다. 결국 메모리 효율과 성능을 고려한다면 주기적인 정리가 필요할 수 있죠. 포스팅이 주로 읽히는 일상시간을 제외한 새벽시간이 제 경우 가장 이상적이었습니다. 새벽의 경우 방문자가 거의 없어 캐싱의 효과가 크지 않기 때문이죠.

! 주데이터베이스와 redis 싱크 맞추는 부분

만약 캐시된 데이터가 실데이터와 다르다면 문제가 발생할 수 있습니다. 어떤 데이터냐에 따라서 크게 고려할 부분이 아닐 수 있으나 만약 삭제되거나 보안상 중요한 데이터는 정확히 일치할 필요가 있습니다. 이런 문제를 피하려면 데이터의 조작이 발생할 때 redis의 key값을 파기하거나 업데이트하는 작업이 필요합니다. 또한 redis의 업데이트가 선행된 후 주데이터베이스에 업데이트 되도록 순서에도 신경을 써야합니다. 이렇게해야 거의 동시에 이루어지는 작업에도 문제가 생기지 않겠죠.

# 마치면서

서버가 느려지고 데이터베이스가 여러번 눕는 상황을 피하기 위해 여러가지 기술, 기법들이 필요하다는 것을 뼈져리게 느끼게 됩니다. 쿼리를 얼마나 효과적이 짜느냐도 중요하지만 하드웨어 상황을 고려하지 않거나 캐싱 및 데이터 콜을 줄이는 등등 다양한 성능 향상의 고민들이 수반되어야 원할한 서비스 운영이 가능한 것 같습니다.