SLASH 기술 블로그

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

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

앱 개발을 하다가 백엔드 개발자로서 일을 시작하고 가장 크게 벽을 느꼈던 부분이 인프라에 대한 것들이다. API 개발이야, 결국 요청을 받아서 처리한 후 결과를 반환하는 일련의 과정이니 그동안 해왔던 이벤트 기반의 프로그래밍과 별반 다를 것 없다고 생각했고, 실제로도 크게 어려움을 느끼는 부분은 아니다. 오히려 이쪽은 익숙하지 않은 언어적인 부분이 신경쓰이지... 그렇지만 인프라- 이 영역은 프로그래밍과는 또 다른 분야라고 생각된다. 최근 몇 개월동안 어찌어찌 간단한 서비스를 운영할 수 있을 정도로는 인프라에 대해 알게 된 것 같지만, 배포는 간신히 되게만 만들어 놓은 상태, 모니터링은 아예 손도 못대봤고 인스턴스나 RDS같은 Managed service는 쓸 줄만 알지 제대로 이해하고 있다고 보기는 어..