미뤄만왔던 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의 업데이트가 선행된 후 주데이터베이스에 업데이트 되도록 순서에도 신경을 써야합니다. 이렇게해야 거의 동시에 이루어지는 작업에도 문제가 생기지 않겠죠.


# 마치면서

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