llm api
-
이코에코(Eco²) Clean Architecture #13: Scan Worker 마이그레이션 로드맵이코에코(Eco²)/Clean Architecture Migration 2026. 1. 5. 19:07
작성일: 2026-01-05상태: Implemented1. 마이그레이션 배경1.1 기존 구조의 한계domains/scan과 domains/_shared/waste_pipeline은 빠른 프로토타이핑에 적합했으나, 시스템이 성장하면서 다음과 같은 문제가 드러났다.레이어 경계가 모호했다. Vision API 호출, 프롬프트 로딩, 파이프라인 조합이 모두 한 디렉토리에 뒤섞여 있어 모델 확장이 어려웠다. OpenAI만 사용하던 초기와 달리, Gemini 등 멀티모델을 지원해 보다 에이전틱스럽게 작동하길 바랐다.1.2 마이그레이션 목표Clean Architecture 적용Application/Infrastructure 레이어 분리LLM DI모델명 기반 런타임 어댑터 선택Stateless ReducerStep을 ..
-
Scan API 600 VUs Load Test: 처리량 포화 분석 리포트이코에코(Eco²)/Reports 2025. 12. 29. 20:36
Date: 2025-12-29 19:30~19:40 KSTTest Duration: 270.1s (4m30s)Result: 33.2% Completion Rate (Throughput Saturation)Overviewhttps://snapshots.raintank.io/dashboard/snapshot/AIAkKSCF1y6UbA4URziiwD0bbdLPOvBe GrafanaIf you're seeing this Grafana has failed to load its application files 1. This could be caused by your reverse proxy settings. 2. If you host grafana under subpath make sure your grafana...
-
이코에코(Eco²) Message Queue #13: Scan API 성능 측정 (SSE + Celery Chain + Gevent)이코에코(Eco²)/Message Queue 2025. 12. 25. 04:57
Celery Chain + Gevent Pool 기반 비동기 아키텍처 전환 후 실제 성능을 측정하고, HTTP 1.1 + gRPC + asyncio와 비교합니다.항목내용테스트 일시2025-12-25 02:16 ~ 04:35 (KST)테스트 도구k6 (JavaScript 기반 부하 테스트)대상 엔드포인트/api/v1/scan/classify/completion (SSE)모니터링Prometheus + Grafana (Scan SSE Pipeline 대시보드)1. 테스트 환경1.1 Queueing 아키텍처1.2 Worker 설정scan-workergevent1001~5character-match-workergevent501~4character-workergevent501~2my-workergevent501~2..
-
이코에코(Eco²) Message Queue #12: Gevent 기반 LLM API 큐잉 시스템이코에코(Eco²)/Message Queue 2025. 12. 25. 03:36
목표OpenAI GPT-5.1 기반 폐기물 분류 파이프라인을 고가용성 큐잉 시스템으로 구현:RPM 제한 대응: 50RPM+ 환경에서 안정적 처리실시간 진행률: SSE로 4단계 파이프라인 상태 스트리밍장애 복원력: DLQ 기반 자동 재처리수평 확장: HPA로 부하 기반 자동 스케일링핵심 수치지표Before (동기)After (큐잉)개선율동시 처리량3 req50+ req33x메모리 사용4GB (prefork)1GB (gevent)75%↓장애 복구수동자동 (DLQ)-스케일링수동HPA 자동-Queueing 시스템 구성도Celery Chain 파이프라인4단계 파이프라인 구조파이프라인 실행 절차StepTask역할평균 소요시간1️⃣visionGPT-5.1 Vision API로 이미지 분류 (major/middle/m..
-
Message Queue 트러블슈팅: Gevent Pool 마이그레이션 및 Stateless 체이닝의 한계이코에코(Eco²)/Troubleshooting 2025. 12. 25. 03:16
#11 Prefork 병목 분석에서 I/O-bound 워크로드(65% OpenAI API)에 prefork가 비효율적임을 확인하고, Gevent Pool로 전환했습니다. 이 문서는 전환 과정에서 발생한 7개 문제와 해결 과정을 기록합니다.2. 문제 목록1Gevent + Asyncio 충돌98% 요청 실패🔴 Critical~2시간2Redis ReadOnly ReplicaResult 저장 실패🔴 Critical~1시간3RPC Result Backend 한계character.match 타임아웃🟠 High~1시간4Character Cache 미로드match 실패, 더미 응답🟠 High~2시간5SSE 이벤트 처리 오류reward: null 응답🟠 High~1시간6DLQ 라우팅 오류Task 미등록 에러🟡..
-
이코에코(Eco²) Message Queue #7: Celery Chain + Celery Events (2)이코에코(Eco²)/Message Queue 2025. 12. 24. 11:44
이전 글: Celery Chain + Celery Events (1)관련 트러블슈팅: Celery + RabbitMQ 트러블슈팅 가이드개요본 문서는 4단계 Scan Pipeline + Fire&Forget RDB 저장으로 고도화된 Celery Chain 아키텍처를 다룬다.클라이언트 응답 경로에서 Persistence Layer를 완전히 제거하여 Stateless한 응답을 구현했다.1. 설계 원칙1.1 기존 아키텍처의 문제(1)편에서 scan_reward_task가 character-worker에서 실행되며 DB 조회와 gRPC 호출을 포함:scan-worker character-worker┌────────────────────────┐ ┌──────────────..