개발과 일상

이 글은 이 전에 작성한, Chat API에서 stream 설정의 연장선상의 글이다. 먼저 SSE(Server-Sent Events)에 대해 알아보기 전에 서버-클라이언트의 통신 방식에 대해 간단히 짚고 넘어가는게 좋을 것 같다. 일반적인 서버-클라이언트 네트워크는 폴링(Polling) 방식을 이용한다. 폴링(Polling) 이란? 클라이언트가 서버에 요청을 보내고 응답을 받는 가장 일반적인 형태의 네트워크 방식이다. HTTP 프로토콜 기반으로 주로 구현되면서 사용되고, 서버의 데이터의 업데이트 속도가 느리거나 실시간성이 요구되지 않는 경우에 유용하게 사용할 수 있다. 다만, 데이터가 업데이트 되지 않았는데 불필요한 요청이 발생하는 경우가 있을 수 있으며, 실시간으로 데이터를 주고 받는데 어려움이 있다는..

이전 글에서 https://api.openai.com/v1/chat/completions API에 대해 간단히 다뤄보았다. 그런데 앞선 글이 너무 겉핥기라 정작 중요한 부분을 몇 가지를 놓친 것 같아서 추가적으로 정리해보려고 한다. 크게 두 가지 부분이 아쉬워서 내용을 보강해보려고 한다. 첫 번째는 GPT 프롬프트(Prompt)라고 알려진 메시지 프롬프트가 들어가는 message 배열 부분과 두 번째는 현재 GPT가 답변을 주는 것처럼 한 글자씩 내려주는 stream 부분이다. 하나씩 알아보자. 1. message 배열 먼저, user는 일반적인 사용자를 의미한다. 우리가 평소에 GPT를 사용할 때처럼 아래와 같이 작성하고 보내도, GPT는 정상적으로 답변을 보내준다. "messages": [ { "ro..

이전 글에서 EC2 환경을 구축하고 Docker를 설치한 후 Tomcat을 통해 웹 서버를 배포까지 진행 해봤다. 그런데, EC2에 Docker를 설치 후 Dockerfile로 Build하는 과정에서 정상적으로 진행되지 않고 자꾸 프리징이 발생했다. 여기서 부터 2편을 시작해 보려고 한다. 1편과의 간격이 너무 길었지만 3편과의 간격이 더 길 수도 있다. 1. 스왑 메모리(swap memory) 적용 EC2에서 제공하는 t2.micro 인스턴스는 램의 크기가 1GB이다. 여기에 리눅스를 올리고 Docker 까지 설치하고, Docker 내부에서 Gradle 빌드까지하기엔, t2.micro의 메모리는 매우매우 부족하다, 그래서 프리징 현상이 발생하게 되고, 이를 해결하기 위해서 스왑 메모리라는 기법을 사용했..

흔히 볼 수 있는 교차 출처 리소스 공유(Cross-Origin Resource Sharing, CORS) 에러... CORS를 간단히 정리하면 아래와 같다. CORS는 다른 도메인 간에 리소스를 공유할 때 발생하는 보안상의 이슈를 해결하기 위해 만들어진 매커니즘. 웹 브라우저에서는 보안상의 이유로 다른 출처(Origin)에 있는 리소스를 직접 요청할 수 없다. 자세히 정리된 곳은 많으니 따로 정리하진 않겠다. 스프링 프레임워크에서는 간단히 해결이 가능하다. @Configuration public class CorsConfig implements WebMvcConfigurer { @Override public void addCorsMappings(CorsRegistry registry) { registr..

"error": { "message": "This model's maximum context length is 4097 tokens. However, you requested 7869 tokens (3773 in the messages, 4096 in the completion). Please reduce the length of the messages or completion.", "type": "invalid_request_error", "param": "messages", "code": "context_length_exceeded" } Open AI의 chat API를 쓸 때, 답변이 짧은 질문을 해도 무조건 토큰허용량이 초과했다고 뜨는 경우가 있다. 이유는 모르겠는데, max_tokens를 최대치..

앞선 글에서는 캐시에 단순 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..