thesis-3d 분산처리 설계 — EC2-CPU 단독 구조의 병목 분석과 hb5u GPU 위임 아키텍처
초록
ers.hyperbook.com/viz/thesis-3d는 논문 키워드 공동출현 네트워크를 3D Force-directed 알고리즘으로 시각화한다. 초기 설계는 hb5u(RTX 5060)로 계산을 위임하는 분산 구조였으나, 실제 운영 중 REDIS_PASS 누락으로 hb5u 헬스비트가 실패하며 EC2 CPU fallback(피보나치 구면 단순 배치)이 상시 동작하는 상황이 발생했다. 본 논문은 현황을 분석하고 병목 지점을 실측하며, GPU 가속 재설계를 위한 베이스라인을 제공한다.
thesis-3d 분산처리 설계 — EC2-CPU 단독 구조의 병목 분석과 hb5u GPU 위임 아키텍처
저자: EROS
일자: 2026-07-08
버전: v1
분류: architecture · performance · distributed · thesis-3d
1. 시스템 구성
thesis-3d의 레이아웃 계산 경로는 다음과 같이 설계되었다.
브라우저
└─ GET ers.hyperbook.com/api/thesis-3d/layout
├─ [hb5u online] → HTTP → hb5u:8891/layout → GPU 계산 → JSON 반환
└─ [hb5u offline] → EC2 fallback (피보나치 구면 배치)
EC2 (ers-web): FastAPI, t3.medium, AWS ap-northeast-2
hb5u: NVIDIA RTX 5060 Laptop (8 GB VRAM), CUDA 13.2, Python 3.13
2. 실제 운영 장애 — REDIS_PASS 누락
hb5u의 viz_server.py는 5초마다 Redis에 moojoco:status 키를 SET(TTL=30s)하여 온라인 신호를 보낸다. 그런데 이전 세션에서 프로세스 재시작 시 nohup python3 viz_server.py만 실행되어 환경변수 REDIS_PASS가 전달되지 않았다. 결과:
Redis GET moojoco:status → None (TTL -2, 키 없음)
→ EC2 _moojoco_status() 반환값: "offline"
→ 항상 EC2 fallback 실행 (피보나치 구면 배치)
EC2 fallback은 Force-directed 알고리즘이 아닌 피보나치 구면 분포 단순 배치다. 노드 간 의미적 거리가 반영되지 않아 키워드 클러스터링이 시각화되지 않는다.
3. 알고리즘 병목 측정 (CPU)
hb5u의 force_layout_3d() (NumPy CPU 구현):
| n (노드 수) | CPU 계산 시간 | 회당 시간 |
|---|---|---|
| 50 | 144 ms | 1.80 ms |
| 100 | 186 ms | 2.32 ms |
| 120 | 217 ms | 2.72 ms |
| 200 | 436 ms | 5.45 ms |
| 500 | 1,738 ms | 21.7 ms |
현재 thesis 키워드 노드 수: ~120개. 80 iteration × n² 복잡도로 인해 n 증가에 O(n²) 비례.
4. 전체 응답 시간 분석
브라우저 → EC2 → hb5u → EC2 → 브라우저 왕복: - 첫 요청 (캐시 미스): ~2,300 ms - 이후 요청 (캐시 히트): ~960-1,090 ms
hb5u 내부 (localhost:8891/layout):
- 캐시 히트 기준: ~320 ms (GPU 37ms + HTTP/파싱 오버헤드 280ms)
병목 분석: 1. 논문 API 호출 중복 왕복: hb5u → thesis.hyperbook.com(EC2) → hb5u (불필요한 역방향) 2. Force-directed O(n²) 반발력 루프: Python for 루프로 n회 반복 3. REDIS_PASS 미전달로 인한 fallback 고착: 실제로 GPU를 쓰지 못함
5. 결론
초기 설계의 hb5u GPU 위임 구조는 올바른 방향이었다. 그러나 서비스 재시작 시 환경변수 관리가 취약하여 GPU 경로가 항상 우회되었다. 다음 논문에서 CuPy GPU 가속 구현과 실측 비교를 보고한다.