nFolyo Post-MVP 아키텍처와 기술 스택 검토
카테고리
프로그래밍/소프트웨어 개발
서브카테고리
웹 개발
대상자
- 대상자: 소프트웨어 아키텍트, 백엔드 개발자, 시스템 설계자
- 난이도: 중급~고급 (아키텍처 패턴, 병렬 처리, 성능 최적화 기술 이해 필요)
핵심 요약
- 현재 아키텍처의 주요 한계:
/update-account
엔드포인트는 단일 스레드로 동작하며, TWRR 계산이 전체 처리 시간의 80%를 차지함 (현재 20분 소요).- Pandas의 대규모 데이터 처리 비효율, 시퀀셜 처리로 인한 병목 현상.
- v0.5.0 개선 방안:
- Celery + Redis/RabbitMQ 기반 메시지 큐 도입으로 병렬 처리 구현.
- TWRR 계산 알고리즘 개선 및 Polars로 Pandas 대체.
/update-account
엔드포인트 분할 (시장 가치 업데이트와 TWRR 계산 분리).- 성능 향상 목표:
- TWRR 계산 시간 80% 감소, 1분 20초 → 10~20초로 단축.
- Server-Sent Events 도입으로 UI의 실시간 업데이트 지원.
섹션별 세부 요약
1. 현재 아키텍처 및 기술 스택
- nFolyo Client App:
- Next.js/TypeScript 기반, RadixUI + 커스텀 컴포넌트 사용.
- 데이터 처리는 nFolyo Core (Flask/Python)에 위임.
- nFolyo Core:
- Interactive Brokers, Freetrade와 같은 브로커의 거래 데이터를 표준화하여 처리.
- nFolyo Finance 서비스에서 가격 및 외환 데이터를 가져와 PnL, TWRR 계산.
- nFolyo Admin:
- Next.js + shadcn/ui 기반, VPN 보호된 관리자 웹 앱.
- Benchmarker Database와 연동하여 성능 모니터링 지원.
2. 성능 한계 및 문제점
- /update-account 엔드포인트:
- 단일 스레드로 동작, 111개 보유 자산 처리 시 20분 소요.
getHistoricalData
(1분 20초) 및calculateHoldingPerformanceTWRR
(80% 시간 소요)가 주요 병목.- Pandas의 대규모 데이터 처리 비효율 및 시퀀셜 처리로 인한 성능 저하.
- UI 경험:
- 사용자에게 실시간 업데이트 없이 장시간 대기 강요.
3. v0.5.0 개선 계획
- 병렬 처리 구현:
- Celery 워커 도입, Redis/RabbitMQ를 통해 TWRR 계산 태스크 큐잉.
- 2개 워커로 처리 시간 50% 감소 예상.
- 성능 최적화:
- Polars로 Pandas 대체, TWRR 알고리즘 개선.
- 가격 제공업체 변경으로 역사적 가격 조회 시간 1분 20초 → 10~20초 단축.
- 엔드포인트 분할:
- 시장 가치 업데이트와 TWRR 계산을 분리하여 UI 실시간 업데이트 지원.
- Server-Sent Events 도입:
- 현재 대기 상태를 실시간으로 전달, polling 기반 접근 개선.
4. 개선된 아키텍처 설계
- 핵심 변경 사항:
- nFolyo Core은 요청 수신 및 태스크 오케스트레이션만 수행, 중간 처리 로직은 Celery 워커로 이관.
- 스케줄링 작업은 메시지 큐 또는 nFolyo Core 엔드포인트를 통해 처리.
- 기대 효과:
- UI 응답성 향상, 실시간 업데이트 제공, 병목 현상 해소.
결론
- 핵심 권장사항:
- 메시지 큐 (Celery + Redis/RabbitMQ) 도입으로 병렬 처리 구현.
- TWRR 계산 알고리즘 개선 및 Polars 사용으로 성능 최적화.
- 엔드포인트 분할과 Server-Sent Events 도입으로 사용자 경험 향상.
- v0.5.0에서는 병목 현상 해소, 사용자 대기 시간 20분 → 10~20초로 단축 예상.