SLASH 기술 블로그

이전 글에서는 Redis의 키 관리나 자료 구조의 선택을 어떻게 할 것인지에 대해 간단한 생각을 이야기했다. 오늘은 실제로 BSER.FUN 사이트를 구현하면서, 유저가 전적 갱신을 요청했을 때 이를 처리하기 위해 Redis를 적극적으로 활용했던 경험이 있어, 이를 공유하고자 한다. Redis가 캐시로 많이 쓰이기는 하지만, 꼭 캐시로만 써야하는 것도 아니다. 그동안 캐시로만 Redis를 사용했던 분들이라면 Redis를 활용하는 새로운 방법에 대한 힌트를 얻어갈 수 있지 않을까 싶다. 데이터 갱신을 위한 Queue - List 활용 게임 전적 사이트에서는 유저마다 전적을 보여주고 동시에 다양한 통계를 보여주기 위해서 유저가 플레이한 게임 데이터를 갱신하는 로직이 반드시 필요하다. 어떤 방식을 취하든, 기본..

동일한 입력에 대해 동일한 출력을 뱉는 API라면 매 번 요청이 들어올 때마다 연산을 할 필요가 없다. 이처럼 적절한 곳에 적절한 형태의 캐싱을 사용하면, 연산량이 많은 작업이나 DB Hit을 줄일 수 있어 서버 부하를 덜고 API의 반응 속도를 올릴 수 있다. 현재 서비스하고 있는 BSER.FUN 사이트에서도 캐싱을 사용했는데, 얼마 전까지는 Redis가 아닌 단순 로컬 캐시로만 처리를 했다. (서버 로컬 메모리) 당시 Redis의 존재 자체는 알았지만, 막연하게 느껴지는 심리적인 장벽과 기능 개발에 집중해야하는 스탠스로 인해서 쉽사리 적용해볼 생각을 못했는데, 이후 Redis를 도입하게 되면서 캐싱뿐만 아니라 앱 전반에서 다양한 이득을 보아 그 사례를 공유하고자 한다. 한 편, 여러 개의 노드가 동일..