celery란?celery는 파이썬 기반의 분산처리(distributed task queue) 라이브러리로 비동기 작업 실행을 도와주는 시스템이다.분산처리란 여러개의 프로세스(worker)를 동시에 실행하여 작업을 분산시키는 방식task queue 형태를 사용해, 처리해야 할 다양한 작업(태스크)을 큐에 쌓아두고, 별도의 워커(worker) 프로세스가 그 작업을 소비하여 실행이렇게 웹 요청을 처리하는 django 프로세스와 무거운 연산을 담당하는 worker 프로세스를 분리해 놓으면 웹서버(django)는 더 빨리 응답할 수 있고, 무겁거나 오래걸리는 로직은 뒤에서 celery가 담당하게 된다. Task Queue란?작업(태스크)을 큐(queue)에 쌓아두고 실제 실행은 별도의 워커(worker) 프로세..

원래 사용하던 블로그 - https://yeonnan.hashnode.dev/docker-error-for-web-containerconfig?source=more_series_bottom_blogs   sudo docker-compose build 후sudo docker-compose up을 하면 지속적으로 ERROR: for web  'ContainerConfig' 에러 발생docker 버전 : 26.1.3docker compose 버전 : 1.29.2원인ERROR: for web  'ContainerConfig'는 docker compose v1의 버그로 인한 문제로기존의 docker compose 1.29.2 버전은 필드가 존재할 것을 가정하고 동작하기 때문에 최신 docker 에서는 해당 키를 ..

원래 사용하던 블로그 - https://yeonnan.hashnode.dev/s3-s3putbucketpolicy?source=more_series_bottom_blogs     1. S3 생성 중 정책 생성 페이지에서 s3:PutBucketPolicy 권한이 없어 오류 발생IAM 사용이 아닌 루트 사용자 버전으로 설명AWS IAM 콘솔 → 정책 → AdministratorAccess⁠검색→ 정책이 나타나면 사용자에 연결→ 없다면 새로운 정책 추가 없으므로 AdministratorAccess 생성 정책 생성 버튼 클릭 → JSON 탭 선택 후 아래 코드 입력 → 생성{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", ..

원래 사용하던 블로그 - https://yeonnan.hashnode.dev/postgres-user-password-docker-compose-up?source=more_series_bottom_blogs   문제 상황.env 파일에서 POSTGRES_USER, POSTGRES_PASSWORD 값을 수정함docker-compose build, docker-compose up으로 컨테이너 재시작 했더니 아래의 에러 발생psycopg2.OperationalError: connection to server at "db" (----), port 5432 failed: FATAL: password authentication failed for user원인 및 해결postgres 컨테이너는 처음 실행될 때 데이..

원래 사용하던 블로그 - https://yeonnan.hashnode.dev/llm?source=more_series_bottom_blogs    OpenAI API를 이용한 챗봇을 만들면서 대화가 길어질수록 LLM 호출 시 토큰 수 증가로 응답 시간이 길어지는 문제가 발생문제분석여기서 생각하는 문제는db 조회의 부하처음 챗봇에게 부여하는 역할이 너무 긴데, 이걸 매 API 호출마다 전송함대화 흐름을 기억하기 위해 챗봇-유저 간 대화 내용을 모두 DB에 저장한 다음 그대로 API 호출 마다 LLM에 전달함→ 모든 대화 내용을 LLM한테 보내버리는 것→ 이렇게 모든 내용을 전송 하다보면 대화 내용이 쌓일수록 엄청난 양의 토큰과 데이터가 소모될 것구상이걸 해결하기 위해 생각한것이챗봇 역할 단순화하기대화 내용..

원래 사용하던 블로그 - https://yeonnan.hashnode.dev/1-2?source=more_series_bottom_blogs    1번 유저와 진행한 대화 내용이 2번 유저와의 대화에서도 기억되는 문제가 발생했다.세션 자체는 유저별로 잘 생성되고, 데이터베이스에서도 세션별로 나뉘어 저장되고 있음세션 자체는 유저별로 잘 생성되고 데이터베이스에서도 세션별로 나뉘어 저장되고 있다.문제는 현재 대화 저장 로직에서 유저별 세션 관리가 제대로 작동하지 않아서 그러는것 같다. → 기존 방식은 유저와 날짜별로 세션을 가져오거나 생성하는데 ChatBot.objects.filter(session=session)에서대화 기록을 가져오는 과정에서 대화 기록이 사용자별로 명확히 분리되지 않아서 다른 사용자의 대..

원래 사용하던 블로그 - https://yeonnan.hashnode.dev/onedaychat    openai를 이용해 챗봇을 만들다 두가지 이슈가 생겼다.1. 대화 기억 문제챗봇이 이전 대화를 기억하지 못하고 매번 새로운 대화처럼 응답한다.openai 호출에서 message 리스트에 전체 대화가 전달되지 않고, openai 역할로 설정해둔 전역 변수 message 리스트에 사용자 메세지와 openai 응답만 단순히 추가해서 이전 대화를 기억하지 못하는 거였다. 해결은? 이전 대화 내용을 db에서 불러와 message 리스트에 포함시키기!1.⁠ previous_message = ChatBot.objects.filter(session=session).order_by("timestamp")⁠로 세션에 저..

원래 사용하던 블로그 - https://yeonnan.hashnode.dev/redis-cli?source=more_series_bottom_blogs   로컬에서⁠docker-compose up 으로 서버를 열고 페이지에 접속하면 Spotify API 데이터가 넘어오는 로그는 확인이 됨docker exec -it playlist-upgrade-redis-1 redis-cli⁠로 Redis-CLI로 Redis를 실행한 다음 keys *를 실행하면 아무 결과가 안나옴Redis에 실제로 데이터가 저장되지 않고 있는 상황1차 접근1. docker 컨테이너 내부에서 redis cli에 접근다시 한번 ⁠docker exec -it playlist-upgrade-redis-1 redis-cli⁠를 이용해서docke..

원래 사용하던 블로그 - https://yeonnan.hashnode.dev/whatever-song-db?source=more_series_bottom_blogs   기존에 사용했던 Redis 캐시 기능과 유저 찜 기능을 보며, 캐시와 로컬 DB를 활용해 추가할 수 있는 기능이 뭐가 있을까 더 고민해보았다.Spotify API 호출을 최소화하고, 데이터를 효율적으로 관리할 수 있는 방법1. 최초 요청 시 로컬 DB에 저장Spotify API에서 데이터를 가져올 때, 그 데이터를 로컬 DB에 저장한다.이후 동일한 요청이 발생하면 로컬 DB에서 데이터를 먼저 확인하고, DB에 존재하지 않을 경우 Spotify API를 다시 호출하여 데이터를 가져온다.2. 재요청 시 캐시와 로컬 DB 활용재요청이 발생하면 ..