대용량 트래픽 경험 및 RAG를 활용한 미니 프로젝트를 백엔드 두명이서 하게 됬다.
대략적인 요구사항을 정리 한 결과 모르는게 너무 많아
블로그에 공부한 흔적을 남기며 자주 볼 수 있도록 이론에 대한 내용을 작성할 예정이다.
가장 기본적인 것 부터 비동기 작업, RAG, LangChain 등 까지 아는것과 모르는 것 상관없이 다시한번 검색해 보면서
진행 할 예정이다.
Django를 사용해 진행하기때문에 Django의 기본 Settings에 전역 설정을 할거다.
우리 apps는
로 이루어져 있기에 그대로 INSATLLED_APPS에 적어준다.
INSTALLED_APPS는 내장 앱 > 서드파티 앱 > 로컬 앱 순서로 등록하며 마이그레이션, 관리자 기능도 사용가능하다.
MIDDLEWARE는 요청/응답 처리 파이프라인이며 위에서 아래로 실행된다.
예_) CORS > 세션 > CSRF > 인증 > 메시지
URL의 경우 CBV와 FBV | Router의 활용이 있다.
FBV의 경우 Funtion Based View로
- 장점
- 구현이 간단함
- 읽기 편함
- 직관적인 코드
- 데코레이터 사용이 간단함
- 단점
- 확장 / 재사용이 힘듬
를 가지고 있고
CBV의 경우 Class Based View로
- 장점
- 확장에 용의(재사용)
- 다중 상속 Mixin등 사용 가능
- HTTP Method가 클래스 안에서 나누어 처리
- 강력한 Generic Class View 가 있음
- 단점
- 읽기 어려움(코드 흐름이 암시적)
- 상속되고 믹스되면서 코드 이해를 위해 찾아다녀야함
- 데코레이터 사용시 별로도 import 하거나 Method 생성
의 특징을 가지고 있다. 또한, URL를 사용하는 방식도 조금씩 다른데
Funtion을 사용하여 URL를 확장할땐
urlpatterns = [
path('home/', views.home_view, name='home'),
]
로 사용할 수 있지만
Class를 DjangoDRF의 ViewSet과 Router를 사용하여 URL를 사용할땐
으로 사용할 수 있다.
r'home' 은 url에 표시되는 내용으로 home을 go 로 바꾸게 된다면 GET /api/user_qa/go/ 를 사용하게 될 경우 접속이 가능하다
ORM
ORM(Object-Relational Mapping)이란 데이터베이스의 관계형 데이터와 객체 지향 프로그래밍 언어의 객체 간의 매핑을 자동화하는 기술이다. ORM을 사용하면 데이터베이스와의 상호작용을 객체 지향적으로 다룰 수 있으며, SQL 쿼리를 직접 작성하지 않고도 데이터를 조작할 수 있다.
말 그대로 객체(Object)와 관계형 데이터베이스(Relational)을 연결(Mapping) 해준다는 뜻이다.
Django에는 OO.objects 라는 Manager를 가지고 있어서
상당히 좋은 프레임워크라고 생각할 수 있다.
다른 ORM도구인 Sequelize나 Mongoose등을 사용하지 않아도 바로 사용이 가능하다 이는 django에서 많이 사용된다.
예를들어, User.objects.all() 이라는 코드는
SELECT
*
FROM
User
라는 의미를 가지고 있다.
또한 'Queryset' 이라는 객체를 통해 데이터를 반환하는 것도 쉽게 가능하다.
queryset = User.objects.all()
위의 코드처럼 queryset에 변수를 할당하여 다른 곳에도 쉽게 상속이 가능하다.
all()뿐만 아니라
aggregate()
count()
range()
union()
등 다양한 메소드를 활용하여 사용할 수 있는 장점이 있다.
이처럼 SQL문을 명확하게 다 알지 못하더라도 쉽게 적용이 되는 ORM을 활용하여 프로젝트를 계속 진행할 예정인데
장점만 가지고있는게 아니라 단점도 명확하게 존재한다.
단점은
쿼리하는 데이터가 복잡할수록 ORM이 불편한 경우가 있고 ORM의 제약으로 인해 SQL의 모든 기능을 활용하지 못하는 경우가
종종 있다.
또한, SQL을 제대로 이해하지 못하고 작성하는 ORM은 매우 비효율적인 쿼리를 만들어내는 결과를 만들 수 있으므로
ORM을 사용할 땐 SQL문을 잘 이해하고 사용해야 한다.
Redis의 개념과 데이터타입 등 기본적인 동작방식
Redis의 기본 개념
1. NoSql DBMS(비관계형 데이터베이스)로 분류되며 In memory 기반의 Key - Value 구조를 가진 데이터 관리 시스템
2. 메모리 기반이라 모든 데이터들을 메모리에 저장하고 조회에 매우 빠름(리스트형 데이터 입력과 삭제가 MySQL에 비해서
10배 정도 빠름)
3. 메모리에 상주하면서 서비스의 상황에 따라 데이터베이스로 사용될 수 있으며, Cache로도 사용될 수 있음.
4. Remote Data Storage로 여러 서버에서 같은 데이터를 공유하고 보고 싶을 때 사용 가능
5. 다양한 자료구조를 지원(Strings, Set, Sorted-Set, Hashes, List 등등)
6. 쓰기 성능 증대를 위한 클라이언트 측 샤딩을 지원
샤딩(Sharding) : 같은 데이블 스키마를 가진 데이터(row)를 다수의 데이터베이스에 분산하여 저장하는 방법
7. 메모리 기반이지만 Redis는 영속적인 데이터 보존(Persistence)이 가능하다(메모리는 원래 휘발성)
8. 스냅샷 기능을 제공해 메모리 내용을 *.rdb 파일로 저장하여 해당 시점으로 복구 가능
9. 여러 프로세스에서 동시에 같은 key에 대한 갱신을 요청하는 경우, 데이터 부정합 방지 Atomic 처리함수를 제공(원자성)
10. Redis는 기본적으로 1개의 싱글 쓰레드로 수행되기 떄문에, 안정적인 인프라를 구축하기위해서는
Replication(Master-Slave 구조) 필수이다.
캐쉬(Cache)
cache란 한번 조회된 데이터를 미리 특정 공간에 저장해놓고, 똑같은 요청이 발생하게 되면 서버에게 다시 요청하지 말고 저장해놓은 데이터를 제공해서 빠르게 서비스를 제공해주는 것을 의미
쉽게말해, 한번 나온 데이터는 Redis가 따로 저장해 두었다가 같은 요청이 들어오면 DB나 API를 통하지않고 저장되어 있는 데이터를 제공할 수 있는 기법
실 서버를 구축하여 테스트 or 운영을 진행하다보면 사용자가 늘어남에 따라 DB에 무리가 많이 오는 경우가 많아 부하상승으로 인한 성능이 하락한다.
Redis Cache는 메모리 단(In-Memory)에 위치하여 용량은 작지만 접근 속도는 빠르다.
따라서 메모리 크기보다 작은 데이터셋은 Redis에 저장하여 빠른 접근속도를 유지하는 것이 좋다.
Cache의 구조 패턴
cache를 사용하는 패턴은 첫번쨰로 Look aide Cache 패턴이다.
위의 있는 내용 그대로 일반적인 캐쉬 정의를 그대로 구현한 패턴으로 한번 접근하여 데이터가 있는지 판단한 후, 있다면 캐퀴의 데이터를 사용하고 없으면 DB나 API를 호출하는 방식으로 지금 하고 있는 프로젝트에 적합하여 채택할 예정이다.
두번째 패턴은 write back 패턴이다.
write back 패턴은 쓰기 작업이 대부분으로, INSERT쿼리를 하나하나 날리지 않고 한꺼번에 배치 처리를 하기 위해 사용된다.
이 패턴은 한번에 많은 작업이 들어올경우 이를 처리하는 DB가 죽지않고 온전히 처리 할 수 있도록 캐시 메모리에 데이터를 올려놓고 한번에 병렬식으로 처리가 가능한 패턴이다.
이 패턴은 진행하는 프로젝트에서는 사용할 일이 없을거같다.
'AI_RSS_트래픽 프로젝트' 카테고리의 다른 글
| 모르는 상태로 하는 RSS&분석&RAG 프로젝트(5) Celery+Redis (0) | 2025.11.25 |
|---|---|
| 모르는 상태로 하는 RSS&분석&RAG 프로젝트(4) Celery (0) | 2025.11.21 |
| 모르는 상태로 하는 RSS&분석&RAG 프로젝트(3) Redis (0) | 2025.11.20 |
| Docker wsl, Virual Machine Platform 활성화 오류 해결 (0) | 2025.11.20 |
| 모르는 상태로 하는 RSS&분석&RAG 프로젝트(2) Redis (0) | 2025.11.14 |