전체 글
-
Distributed Tracing: Trace, Span으로 분산 시스템 추적하기이코에코(Eco²) 제작 문서 및 리포트/Applied 2025. 12. 25. 22:22
참고: OpenTelemetry Documentation참고: W3C Trace Context들어가며분산 시스템에서 하나의 요청이 여러 서비스를 거쳐 처리된다.문제가 발생했을 때 "어디서 느려졌는지", "어디서 에러가 났는지" 찾기가 매우 어렵다.┌─────────────────────────────────────────────────────────────┐│ 분산 시스템 디버깅의 어려움 │├─────────────────────────────────────────────────────────────┤│ ││ 사용자 요청: "스캔 결과가 ..
-
Idempotent Consumer: 중복 메시지 처리 패턴이코에코(Eco²) 제작 문서 및 리포트/Foundations 2025. 12. 25. 22:13
참고: Enterprise Integration Patterns - Gregor Hohpe참고: Microservices Patterns - Chris Richardson 분산 시스템에서 메시지는 정확히 한 번(Exactly-Once) 전달되기 어렵다.네트워크 장애, Consumer 재시작, Broker 장애 등으로 같은 메시지가 여러 번 전달(At-Least-Once)될 수 있다.┌─────────────────────────────────────────────────────────────┐│ 메시지 중복 전달 시나리오 │├─────────────────────────────────────────────────────────────┤│ ..
-
Celery: Python 분산 태스크 큐Python 2025. 12. 25. 22:06
원문: Celery Documentation저자: Ask Solem (2009~)들어가며 Celery는 Python으로 작성된 분산 태스크 큐 시스템이다. 2009년 Ask Solem이 Django 프로젝트의 비동기 작업 처리를 위해 개발했으며, 현재 Python 생태계에서 가장 널리 사용되는 비동기 작업 처리 라이브러리다. (이코에코에선 RabbitMQ, FastAPI와 함께 쓰였다.) Celery의 핵심 철학단순함: 복잡한 분산 시스템을 간단한 데코레이터로 추상화유연함: RabbitMQ, Redis 등 다양한 브로커 지원신뢰성: 재시도, DLQ, 모니터링 내장Celery 탄생 배경Django의 한계2009년, Django 웹 애플리케이션들은 심각한 문제에 직면했다:┌───────────────────..
-
AMQP와 RabbitMQ: 메시지 브로커의 표준이코에코(Eco²) 제작 문서 및 리포트/Foundations 2025. 12. 25. 22:00
원문: AMQP 0-9-1 Specification (2006)RabbitMQ: RabbitMQ Documentation들어가며AMQP(Advanced Message Queuing Protocol)는 메시지 지향 미들웨어의 개방형 표준 프로토콜이다.2003년 JPMorgan Chase에서 시작되어 2006년에 AMQP 0-9-1로 표준화되었다.RabbitMQ는 AMQP 0-9-1의 가장 널리 사용되는 구현체로, Erlang으로 작성되어 높은 안정성과 분산 처리 능력을 제공한다.Kafka가 로그라면, RabbitMQ는 우체국에 가깝다.Kafka: 메시지를 로그처럼 영구 저장, Consumer가 원하는 위치에서 읽음RabbitMQ: 메시지를 큐에 저장, Consumer에게 전달 후 삭제AMQP 탄생 배경금융..
-
Gevent+Celery Event+SSE 50 VU 부하 테스트 병목 분석 레포트이코에코(Eco²)/Message Queue 2025. 12. 25. 21:51
테스트 일시: 2025-12-25 19:50 ~ 19:55 KST (약 5분)테스트 환경: k6 SSE Load Test, 50 VU엔드포인트: POST /api/v1/scan/classify/completion https://snapshots.raintank.io/dashboard/snapshot/7xvEQyVzhIXMUxMehz8nlP0jSJXlfrPq 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.ini..
-
이코에코(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 미등록 에러🟡..