AI Store에서 AI코딩으로 만들어진 앱을 만나보세요!
지금 바로 방문하기

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초로 단축 예상.