개발과 일상

이전에 썼던 글에서 언젠가 Redis로 넘어갈 거라고 했었는데, 결국은 안정성 문제로 Redis를 쓰게 됐다. Redis가 고성능 인메모리 캐시라는 것 정도만 알고 있는데, 사용하기 전에 한번 짚고 들어가자. Redis 란? Redis는 데이터베이스, 캐시, 메시지 브로커 및 스트리밍 엔진으로 사용되는 오픈 소스(BSD 라이센스), 메모리 내 데이터 구조 저장소 입니다. Redis는 문자열, 해시, 목록, 세트, 범위 쿼리가 있는 정렬된 세트 , 비트맵 , 하이퍼로그로그 , 지리공간 인덱스 및 스트림과 같은 데이터 구조를 제공합니다. Redis에는 복제 , Lua 스크립팅 , LRU 제거 , 트랜잭션 및 다양한 수준의 디스크 지속성이 내장되어 있습니다. Redis Sentinel을 통한 고가용성과 Red..

6월 16일에 OpenAI가 업데이트 되었다. function call 기능과 함께 토큰 수가 증가 되었다. 무려 4k에서 16k로 4배나 증가 되었다. GPT-4도 GPT-3.5와 마찬가지로 16k 업데이트 되었다. 토큰 수가 업데이트되면서, 이전 대화를 기억하게 하는 기능을 적극적으로 활용할 수 있게 되었다. (기존 4천개로는 너무 적었음...) 구현 방식은 여러가지가 있을 것 같다. 가볍게 떠오르는건 두 가지정도인데, 1. FE는 질문만 전달, BE가 이전 질문과 답변을 저장하고 있다가 답변 생성 2. FE가 어차피 화면에 그려줘야하니까, 질문과 답변을 모두 보내주기 상용화될 앱이라면 1번이 맞다고 생각되어 1번으로 구현해봤다. 시작! chat API 연동 먼저 fegin client로 chat A..

앞선 글에서는 캐시에 단순 String만 저장했다. 그런데 작업을 하다보면 한 줄의 단순한 String 보다는 더 많은 정보를 담고싶기 때문에 Object를 저장하고 싶을 것이다. 이 내용을 정리해봤다. 1. 저장하기 객체를 스트림으로 변환 후 Byte[] 형태로 저장한다. id는 기존 String을 저장하는 방식과 같이 UUID로 랜덤값을 생성했다. public String saveObjectCache(ObjectVo value) { Cache cache = cacheManager.getCache("myCache"); String id = UUID.randomUUID().toString(); byte[] bytes = null; try (ByteArrayOutputStream bos = new Byte..

앞선 글에서 캐시를 삭제하는 부분이 빠졌었다. 사실, 서버 입장에서는 캐시를 만드는 것 보다 캐시를 삭제하는게 더 중요하다. 캐시를 삭제하지않고 계속 쌓게되면 100% 확률로 서버는 언젠가 죽기 때문이다. 이를 방지하기 위해 캐시를 꼭 삭제해야한다. 캐시 삭제 전략 일단 캐시의 삭제 전략은 크게 세가지가 있다. (더 있으면 알려주세요..) 1. ID별로 만든 캐시를 하나씩 수동 삭제하기 2. 특정시간 마다 통으로 캐시 비우기 3. TTL(Time-to-Live)을 설정해 ID별 캐시가 살아있는 시간 설정 안정적으로 설계를 잘한다면 1번만으로 사용이 가능하겠지만, 예외 발생시 캐시를 삭제 안하고 넘어가는 경우가 분명 발생할 것이다. 때문에, 사용하지 않는 캐시를 주기적으로 삭제하는 2번 전략도 필요하다. ..

매번 데이터를 저장하기 위해 데이터베이스를 거치는 것은 번거롭고 오버헤드가 발생하는 작업이다. 때문에, DB의 부하도 줄일 겸해서 인메모리에 짧은 시간, 작은 크기의 데이터를 저장해서 사용하는 경우가 많다. 대표적인 예가 Redis를 사용해서 캐싱을 하는건데, 스프링 자체에서도 캐시 기능을 제공한다. 이전에 비슷한 내용의 글을 작성했는데, 스프링부트에서 굉장히 쉽게 구현이 가능해서 정리해봤다. 사용법 별도의 gradle 설정이 필요 없다. 라이브러리도 딱히 받을 필요없음. 1. Config 설정 - Map형식으로 사용하고 싶어서 ConcurrentMapCacheManager 사용함 @Configuration @EnableCaching public class CacheConfig { @Bean public..

1. 캐시란? 서버는 많은 리소스들을 저장하고 있다. 개중에는 엄청나게 큰 파일을 요청하는 경우가 있는데, 이럴 경우 여러번 같은 파일을 요청할 경우 서버는 많은 사용자가 사용 중이 아니어도 과부하 상태 빠질 것이다. 위와 같은 경우를 대비해서 서버-클라이언트 서비스 간에 캐시(Cahce)를 둬서 리소스에 대한 좀더 빠른 접근할 수 있도록 한다. 캐시의 위치는 구현법과 솔루션에 따라 나뉘는데, 1. 인 메모리 캐싱(In-memory caching): 서버의 RAM에 데이터를 저장해 캐싱된 데이터에 빠르게 접근할 수 있도록 한다. Java 라이브러리 ehcache가 대표적인 예이고, 스프링 내부적으로도 제공하는 @Cacheable도 인메모리 캐싱이다. 2. 디스크 캐싱(Disk caching): 데이터를 ..