103 lines
4.7 KiB
Markdown
103 lines
4.7 KiB
Markdown
# O2O Negosium
|
|
|
|
동일 구조의 두 서비스(**negosium**, **negodata**)가 **하나의 PostgreSQL 인스턴스**를 공유한다.
|
|
|
|
## 구성
|
|
|
|
```
|
|
o2o-negosium/
|
|
├── docker-compose.yml # 두 backend (DB 는 외부)
|
|
├── postgres-init/ # DB·테이블 셋업 SQL (대상 DB 에 1회 적용)
|
|
├── backend/ # negosium 백엔드 (포트 9300)
|
|
├── negodata/backend/ # negodata 백엔드 (포트 9400)
|
|
├── agent/ front/ # (예정)
|
|
└── negodata/front/ # (예정)
|
|
```
|
|
|
|
두 백엔드는 같은 코드 골격(MVC · 람다 DB · Depends 주입 · JWT 로그인)을 쓴다.
|
|
아키텍처/패턴 상세는 각 서버 README 참고: [backend](backend/README.md) · [negodata/backend](negodata/backend/README.md)
|
|
|
|
### DB 는 compose 밖 (config 로 연결)
|
|
DB 는 docker-compose 에서 관리하지 않는다. 각 backend 는 `config.<APP_ENV>.toml` 의 접속 정보대로
|
|
**외부 PostgreSQL**(호스트 로컬 postgres, 또는 따로 떠 있는 docker postgres)에 연결한다.
|
|
한 PostgreSQL 안에 서비스별 database 를 둔다.
|
|
```
|
|
PostgreSQL (외부, 5432)
|
|
├── negosium_db ← negosium-backend
|
|
└── negodata_db ← negodata-backend
|
|
```
|
|
- 컨테이너(docker env)에서 호스트 DB 접근: `host.docker.internal:5432` (`config.docker.toml`)
|
|
- 로컬 실행/테스트(local·test env): `127.0.0.1:5432` (`config.local/test.toml`)
|
|
- 계정/database 명은 config 에 맞춘다 (기본 `postgres` / `password`).
|
|
|
|
| 서비스 | 서버 | docs | database |
|
|
|---|---|---|---|
|
|
| negosium-backend | http://localhost:9300 | /docs | negosium_db |
|
|
| negodata-backend | http://localhost:9400 | /docs | negodata_db |
|
|
|
|
## 빠른 시작
|
|
|
|
```bash
|
|
# 1) DB 준비 (최초 1회) — 사용할 PostgreSQL 에 스키마 적용
|
|
psql -h 127.0.0.1 -p 5432 -U postgres -f postgres-init/01-schema.sql
|
|
# (negosium_db / negodata_db + tbl_account 생성)
|
|
|
|
# 2) 백엔드 기동
|
|
docker compose up -d # 두 backend (DB 는 config 대로 외부 연결)
|
|
docker compose logs -f
|
|
docker compose down
|
|
```
|
|
|
|
## 테스트
|
|
|
|
```bash
|
|
# config.test.toml 의 PostgreSQL(기본 127.0.0.1:5432) 이 떠 있어야 한다
|
|
cd backend # 또는 negodata/backend
|
|
pip install pytest pytest-asyncio httpx
|
|
python -m pytest
|
|
```
|
|
- httpx `ASGITransport` 로 네트워크 없이 앱을 직접 호출하는 e2e (각 5개).
|
|
- `DB_SESSION_MNG` 싱글톤의 커넥션 풀이 첫 이벤트 루프에 묶이므로, 모든 테스트가 단일 session 루프를 공유한다(`pytest.ini`).
|
|
|
|
## 성능 / 벤치마크
|
|
|
|
`/login` 은 **bcrypt(CPU 바운드)** 가 비용의 대부분이다. 초기에는 bcrypt 가 asyncio
|
|
이벤트 루프를 막아 **아무 일도 안 하는 `/healthz` 조차 p99 3.3s** 가 나왔다.
|
|
|
|
**두 가지 최적화**
|
|
1. **bcrypt 를 `asyncio.to_thread` 로 오프로드** — 이벤트 루프 비차단. bcrypt 는 해싱 중
|
|
GIL 을 해제하므로 스레드들이 여러 코어에서 실제 병렬 실행된다.
|
|
2. **워커 수 증가** (`process_count` 1 → 4) — login 처리량을 코어만큼 확장.
|
|
|
|
### Before / After (동일 부하: 100 users)
|
|
| 지표 | Before | After | 변화 |
|
|
|---|---|---|---|
|
|
| `/healthz` median | 1700ms | **2ms** | 850배 개선|
|
|
| `/healthz` p99 | 3300ms | **14ms** | 235배 개선|
|
|
| `/me` p99 | 3100ms | **12ms** | 258배 개선|
|
|
| `/login` median | 9900ms | **220ms** | 45배 개선|
|
|
| `/login` p99 | 15000ms | **1400ms** | 11배 개선|
|
|
| `/login` RPS | 5.5 | **19.3** | 3.5배 개선|
|
|
| 전체 RPS | 17.6 | **75.2** | 4.3배 개선|
|
|
|
|
### 최적화 후 Locust 차트 (100 users)
|
|
RPS 가 ~71 로 안정, p95 ~250ms(bcrypt), 실패 0%. median 은 초기 계정생성 버스트 후 바닥으로 떨어진다.
|
|
|
|
|
|
|
|
> login 은 여전히 가장 느리다(bcrypt 의 의도된 비용). 핵심은 그게 **서버 전체를 막지 않는다**는 점.
|
|
> 더 높은 처리량은 워커/인스턴스 수평 확장이 정석이다(bcrypt cost 낮추기는 보안 트레이드오프).
|
|
> ⚠️ to_thread 가 이미 단일 워커에서 멀티코어 병렬화를 하므로, 워커를 코어 수만큼 늘리면서
|
|
> to_thread 까지 쓰면 `워커 x 스레드` 가 코어를 넘어 오버서브스크립션이 된다(워커는 코어의 절반 안팎).
|
|
|
|
부하 재현:
|
|
```bash
|
|
docker compose up -d
|
|
cd backend && pip install locust
|
|
python -m locust -f loadtest/locustfile.py --host http://localhost:9300 --headless -u 100 -r 10 -t 2m
|
|
# 부하 중 커넥션 모니터링: psql -h 127.0.0.1 -U postgres -c "SELECT count(*) FROM pg_stat_activity;"
|
|
```
|
|
|
|
## 기술 스택
|
|
FastAPI · SQLAlchemy(async) · asyncpg · PostgreSQL 16 · python-jose(JWT) · bcrypt · uvicorn · Docker Compose
|