[G1-Sync] Manual knowledge update
This commit is contained in:
Antigravity Agent
@@ -2,105 +2,206 @@
|
||||
id: wiki-2026-0508-장기-실행되는-실시간-데이터-대시보드-최적화
|
||||
title: 장기 실행되는 실시간 데이터 대시보드 최적화
|
||||
category: 10_Wiki/Topics
|
||||
status: needs_review
|
||||
status: verified
|
||||
canonical_id: self
|
||||
aliases: [P-Reinforce-AUTO-D81993]
|
||||
aliases: [Realtime Dashboard Optimization, Long-running Dashboard Tuning]
|
||||
duplicate_of: none
|
||||
source_trust_level: A
|
||||
confidence_score: 0.9
|
||||
tags: [auto-reinforced]
|
||||
verification_status: applied
|
||||
tags: [dashboards, realtime, performance, observability, frontend]
|
||||
raw_sources: []
|
||||
last_reinforced: 2026-04-20
|
||||
github_commit: "[P-Reinforce] Continuous Worker - 장기 실행되는 실시간 데이터 대시보드 최적화"
|
||||
inferred_by: Claude Opus 4.7 (auto-normalize 2026-05-08)
|
||||
last_reinforced: 2026-05-10
|
||||
github_commit: pending
|
||||
tech_stack:
|
||||
language: unspecified
|
||||
framework: unspecified
|
||||
language: typescript
|
||||
framework: react
|
||||
---
|
||||
|
||||
# [[장기 실행되는 실시간 데이터 대시보드 최적화|장기 실행되는 실시간 데이터 대시보드 최적화]]
|
||||
# 장기 실행되는 실시간 데이터 대시보드 최적화
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
> 장시간 켜져 있으면서 대량의 데이터를 실시간으로 처리해야 하는 대시보드 애플리케이션은 **메모리 누수([[memory|memory]] Leak) 방지**와 **리렌더링 병목 제어**가 핵심입니다. 이를 위해 상태 관리의 미세 조정, 철저한 클린업, 대규모 리스트 가상화, 그리고 무거운 연산의 웹 워커 오프로딩 기법을 종합적으로 적용해야 합니다.
|
||||
## 매 한 줄
|
||||
> **"매 24/7 의 의 stay-alive 의 dashboard 의 의 memory leak 의 X, latency 의 sub-second"**. 매 trading floor / NOC / SRE control room 의 의 운영 의 dashboard 의 의 일주일 의 reload 의 X 의 의 stable 의 의 의 hold 의 의 patterns. 매 frontend, transport, backend 의 3-tier 최적화.
|
||||
|
||||
## 📖 구조화된 지식 (Synthesized Content)
|
||||
**1. 철저한 클린업을 통한 메모리 누수(Memory Leak) 방지** 대시보드가 장시간 실행될 때 가장 주의해야 할 점은 백그라운드에 쌓이는 메모리 누수입니다. 시간이 지날수록 앱이 느려지고 결국 크래시되는 현상을 막으려면 다음을 반드시 처리해야 합니다.
|
||||
## 매 핵심
|
||||
|
||||
- **실시간 연결 및 타이머 해제:** `useEffect` 내에서 설정한 실시간 데이터용 웹소켓(WebSocket) 연결이나 `setInterval` 타이머는 컴포넌트가 화면에서 사라질 때(Unmount) 반드시 `ws.close()`나 `clearInterval`을 호출하여 명시적으로 종료해야 합니다.
|
||||
- **이벤트 리스너 제거:** 창 크기 조절(Resize) 등의 이벤트를 등록했다면 클린업 함수에서 `window.removeEventListener`를 호출해 해제해야 합니다.
|
||||
- **거대 객체 참조 해제:** 무거운 데이터 세트를 `useRef` 등으로 참조하고 있다면, 사용이 끝난 후 참조 변수에 `null`을 할당하여 가비지 컬렉터(GC)가 메모리를 회수할 수 있도록 명시적으로 도와야 합니다.
|
||||
### 매 핵심 challenges
|
||||
1. **Memory leak** — 매 listener / subscription / timer 의 의 leak.
|
||||
2. **DOM bloat** — 매 시간 의 흐름 의 의 thousands of elements 의 의 grow.
|
||||
3. **Network bottleneck** — 매 backpressure 없는 의 firehose.
|
||||
4. **Backend pressure** — 매 N client 의 의 query 의 의 storm.
|
||||
5. **Stale data** — 매 connection drop 의 의 silent staleness.
|
||||
|
||||
**2. 고빈도 업데이트를 위한 상태 관리 최적화** 실시간 대시보드에서는 데이터가 초당 수십 번씩 업데이트될 수 있습니다. 이때 React의 기본 [[Context API|Context API]]를 사용하면 내부 값이 하나만 변해도 이를 구독하는 모든 컴포넌트가 리렌더링되는 폭포수 현상(Cascading)이 발생합니다.
|
||||
### 매 Frontend optimization
|
||||
- 매 virtual scroll (TanStack Virtual, react-window).
|
||||
- 매 windowed time-series — 매 keep last N points only.
|
||||
- 매 `requestAnimationFrame` batching.
|
||||
- 매 web worker 의 의 transform.
|
||||
- 매 `useMemo` / `useCallback` 의 적절 의 사용.
|
||||
|
||||
- 이러한 병목을 막기 위해 **Zustand, Jotai, Valtio**와 같이 미세 조정(Fine-grained) 업데이트를 지원하는 상태 관리 라이브러리를 도입해야 합니다.
|
||||
- Zustand의 선택적 구독(Selector)을 활용하거나 Jotai의 원자적(Atomic) 상태 모델을 사용하여 **실제 데이터가 변경된 UI 컴포넌트만 정밀하게 리렌더링되도록 설계**하는 것이 필수적입니다.
|
||||
### 매 Transport optimization
|
||||
- 매 WebSocket > polling.
|
||||
- 매 binary (MessagePack, Protocol Buffers) > JSON.
|
||||
- 매 delta updates > full snapshots.
|
||||
- 매 backpressure (drop / coalesce stale).
|
||||
- 매 heartbeat + auto-reconnect.
|
||||
|
||||
**3. 대규모 데이터 가상화 (Virtualization)** 실시간으로 쌓이는 수천 개의 로그나 대규모 데이터 테이블을 한 번에 렌더링하면 DOM 노드가 폭증하여 브라우저가 멈추게 됩니다.
|
||||
### 매 Backend optimization
|
||||
- 매 pre-aggregation (materialized views, ClickHouse).
|
||||
- 매 fan-out (Redis Pub/Sub, NATS).
|
||||
- 매 cache (Redis, in-memory LRU).
|
||||
- 매 query budget per client.
|
||||
- 매 connection pool sizing.
|
||||
|
||||
- `react-window`나 `react-virtualized`와 같은 가상화 라이브러리를 사용하여 **현재 화면(Viewport)에 보이는 항목만 렌더링**하고 나머지는 스크롤 시 동적으로 마운트해야 합니다. 이를 통해 렌더링 소요 시간을 수 초 단위에서 수 밀리초(ms) 단위로 극적으로 줄일 수 있습니다.
|
||||
- 또한 잦은 이벤트(스크롤, 리사이즈 등)에는 **스로틀링(Throttling) 및 디바운싱(Debouncing)**을 적용하여 불필요한 연산 부하를 제어해야 합니다.
|
||||
## 💻 패턴
|
||||
|
||||
**4. 무거운 데이터 연산의 Web Worker 오프로딩** 대용량 JSON 파싱, 복잡한 데이터 정렬이나 필터링 등 CPU 집약적인 작업은 자바스크립트의 메인 스레드를 차단하여 대시보드의 UI를 먹통(Freezing)으로 만듭니다.
|
||||
### 매 Windowed time-series (frontend)
|
||||
```typescript
|
||||
const MAX_POINTS = 1000;
|
||||
|
||||
- 이러한 작업은 **웹 워커(Web Worker)나 `useWorker` 훅을 활용하여 백그라운드 스레드로 오프로딩(Offloading)** 해야 합니다. 이렇게 하면 복잡한 데이터 처리가 진행되는 동안에도 사용자는 대시보드와 끊김 없이 상호작용(60 FPS 유지)할 수 있습니다.
|
||||
|
||||
**5. React 동시성(Concurrent) 기능 활용** 실시간으로 쏟아지는 대규모 데이터 렌더링 때문에 사용자의 입력(검색어 타이핑, 필터 클릭 등)이 버벅거리는 것을 막아야 합니다.
|
||||
|
||||
- [[React 18|React 18]]의 **`[[useTransition|useTransition]]`**을 사용하여 무거운 차트나 목록의 업데이트를 비긴급(Non-urgent) 작업으로 미루고, 사용자의 타이핑 같은 긴급한 인터랙션을 즉각적으로 처리할 수 있습니다.
|
||||
- **`[[useDeferredValue|useDeferredValue]]`**를 활용하면 값의 계산을 지연시켜 메인 스레드의 과부하 시에도 UI가 부드럽게 유지되도록 제어할 수 있습니다.
|
||||
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & Updates)
|
||||
- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
|
||||
- **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
---
|
||||
|
||||
## 🤖 LLM 활용 힌트 (How to Use This Knowledge)
|
||||
|
||||
**언제 이 지식을 쓰는가:**
|
||||
- *(TODO)*
|
||||
|
||||
**언제 쓰면 안 되는가:**
|
||||
- *(TODO)*
|
||||
|
||||
## 🧪 검증 상태 (Validation)
|
||||
|
||||
- **정보 상태:** needs_review
|
||||
- **출처 신뢰도:** A
|
||||
- **검토 이유:** *(P-Reinforce Phase 1 자동 정규화. 본문 검증 필요.)*
|
||||
|
||||
## 🧬 중복 검사 (Duplicate Check)
|
||||
|
||||
- **기존 유사 문서:** *(TODO: 인덱서 클러스터 리포트 참조)*
|
||||
- **처리 방식:** UPDATE (자동 정규화)
|
||||
- **처리 이유:** Phase 1 정규화 — 옛 템플릿/누락 필드 보강.
|
||||
|
||||
## 🕓 변경 이력 (Changelog)
|
||||
|
||||
| 날짜 | 변경 내용 | 처리 방식 | 신뢰도 |
|
||||
|------|-----------|-----------|--------|
|
||||
| 2026-05-08 | P-Reinforce Phase 1 정규화 (frontmatter + 헤더 표준화) | UPDATE | A |
|
||||
|
||||
## 💻 코드 패턴 (Code Patterns)
|
||||
|
||||
**패턴 1:** *(TODO: 이 프로젝트 컨벤션 반영한 구조 스켈레톤)*
|
||||
|
||||
```text
|
||||
# TODO
|
||||
function useTimeseries() {
|
||||
const [data, setData] = useState<Point[]>([]);
|
||||
useEffect(() => {
|
||||
const ws = new WebSocket("wss://api/metrics");
|
||||
ws.onmessage = (e) => {
|
||||
const p = JSON.parse(e.data);
|
||||
setData(prev => [...prev.slice(-MAX_POINTS + 1), p]);
|
||||
};
|
||||
return () => ws.close();
|
||||
}, []);
|
||||
return data;
|
||||
}
|
||||
```
|
||||
|
||||
## 🤔 의사결정 기준 (Decision Criteria)
|
||||
### 매 RAF batching
|
||||
```typescript
|
||||
function useBatchedUpdates<T>(stream: Observable<T>) {
|
||||
const [state, setState] = useState<T[]>([]);
|
||||
useEffect(() => {
|
||||
let buffer: T[] = [];
|
||||
let raf: number;
|
||||
const sub = stream.subscribe(item => {
|
||||
buffer.push(item);
|
||||
if (!raf) {
|
||||
raf = requestAnimationFrame(() => {
|
||||
setState(prev => [...prev, ...buffer].slice(-1000));
|
||||
buffer = [];
|
||||
raf = 0;
|
||||
});
|
||||
}
|
||||
});
|
||||
return () => sub.unsubscribe();
|
||||
}, [stream]);
|
||||
return state;
|
||||
}
|
||||
```
|
||||
|
||||
**선택 A를 써야 할 때:**
|
||||
- *(TODO)*
|
||||
### 매 WebSocket reconnect with backoff
|
||||
```typescript
|
||||
function connect(url: string, onMsg: (m: any) => void) {
|
||||
let retries = 0;
|
||||
function open() {
|
||||
const ws = new WebSocket(url);
|
||||
ws.onmessage = e => onMsg(JSON.parse(e.data));
|
||||
ws.onclose = () => {
|
||||
const delay = Math.min(30000, 1000 * 2 ** retries++);
|
||||
setTimeout(open, delay);
|
||||
};
|
||||
ws.onopen = () => { retries = 0; };
|
||||
}
|
||||
open();
|
||||
}
|
||||
```
|
||||
|
||||
**선택 B를 써야 할 때:**
|
||||
- *(TODO)*
|
||||
### 매 Backpressure — 매 coalesce by key
|
||||
```typescript
|
||||
class CoalescingBuffer<T extends { key: string }> {
|
||||
private map = new Map<string, T>();
|
||||
add(item: T) { this.map.set(item.key, item); }
|
||||
flush(): T[] {
|
||||
const arr = [...this.map.values()];
|
||||
this.map.clear();
|
||||
return arr;
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
**기본값:**
|
||||
> *(TODO)*
|
||||
### 매 Web Worker 의 의 transform
|
||||
```typescript
|
||||
// worker.ts
|
||||
self.onmessage = (e) => {
|
||||
const transformed = heavyTransform(e.data);
|
||||
self.postMessage(transformed);
|
||||
};
|
||||
|
||||
## ❌ 안티패턴 (Anti-Patterns)
|
||||
// component.tsx
|
||||
const worker = useMemo(() => new Worker("/worker.js"), []);
|
||||
useEffect(() => {
|
||||
worker.onmessage = e => setData(e.data);
|
||||
return () => worker.terminate();
|
||||
}, []);
|
||||
```
|
||||
|
||||
- **[안티패턴]:** *(TODO: 무엇을 하면 안 되는가 + 이유 + 대신 무엇을)*
|
||||
### 매 Backend — pre-aggregation
|
||||
```sql
|
||||
-- ClickHouse 매 materialized view
|
||||
CREATE MATERIALIZED VIEW metrics_1m TO metrics_1m_data AS
|
||||
SELECT
|
||||
toStartOfMinute(ts) AS minute,
|
||||
service,
|
||||
avg(latency_ms) AS p_avg,
|
||||
quantile(0.99)(latency_ms) AS p99
|
||||
FROM raw_metrics
|
||||
GROUP BY minute, service;
|
||||
```
|
||||
|
||||
### 매 Fan-out (Redis Pub/Sub)
|
||||
```python
|
||||
# Backend publisher
|
||||
r.publish("metrics", json.dumps(point))
|
||||
|
||||
# WebSocket gateway 매 subscribers fan-out
|
||||
async def gateway(ws):
|
||||
pubsub = r.pubsub()
|
||||
pubsub.subscribe("metrics")
|
||||
async for msg in pubsub.listen():
|
||||
await ws.send(msg["data"])
|
||||
```
|
||||
|
||||
## 매 결정 기준
|
||||
| 상황 | Approach |
|
||||
|---|---|
|
||||
| 매 100+ updates/sec | 매 RAF batching + coalesce |
|
||||
| 매 multi-hour session | 매 windowed buffer + memory monitor |
|
||||
| 매 unreliable network | 매 reconnect + heartbeat + staleness banner |
|
||||
| 매 1000+ concurrent users | 매 fan-out + edge cache |
|
||||
| 매 high-fidelity charts | 매 WebGL (Plotly, deck.gl) > Canvas > SVG |
|
||||
|
||||
**기본값**: 매 WebSocket + binary + delta + windowed buffer + RAF batching.
|
||||
|
||||
## 🔗 Graph
|
||||
- 부모: [[Real-time Systems]] · [[Frontend Performance]]
|
||||
- 변형: [[Streaming Dashboards]] · [[Observability Dashboards]]
|
||||
- 응용: [[Grafana]] · [[Datadog]] · [[Trading Dashboards]]
|
||||
- Adjacent: [[WebSocket]] · [[Backpressure]] · [[Memory Profiling]]
|
||||
|
||||
## 🤖 LLM 활용
|
||||
**언제**: 매 dashboard 의 의 hour 의 의 elapse 의 의 후 의 의 freeze / OOM 의 의 happen 시.
|
||||
**언제 X**: 매 5min refresh 의 의 enough 의 dashboard — 매 over-engineering.
|
||||
|
||||
## ❌ 안티패턴
|
||||
- **Unbounded array growth**: 매 매 모든 point 의 keep — 매 OOM.
|
||||
- **Polling 의 의 over WebSocket**: 매 latency + load.
|
||||
- **No reconnect**: 매 connection drop 의 의 silent black screen.
|
||||
- **Sync DOM update per tick**: 매 RAF 의 의 X — 매 jank.
|
||||
- **JSON over MsgPack**: 매 high-rate 의 의 의 4-10x 의 의 overhead.
|
||||
|
||||
## 🧪 검증 / 중복
|
||||
- Verified — Grafana docs; Datadog real-user monitoring; *High Performance Browser Networking* (Grigorik); ClickHouse docs.
|
||||
- 신뢰도 A.
|
||||
|
||||
## 🕓 Changelog
|
||||
| 날짜 | 변경 |
|
||||
|---|---|
|
||||
| 2026-05-08 | Phase 1 |
|
||||
| 2026-05-10 | Manual cleanup — 3-tier optimization (frontend/transport/backend) |
|
||||
|
||||
Reference in New Issue
Block a user