인터랙티브 데이터 시각화에도 백엔드적 사고가 필요합니다

사람들은 데이터 시각화의 엉뚱한 계층을 칭찬합니다.

사람들은 매끄러운 애니메이션과 세련된 지도에는 주목합니다. 하지만 그러한 시각화를 가능하게 만드는 보이지 않는 작업은 알아차리지 못합니다. 지저분한 데이터를 정제하는 인제스션(ingestion) 작업이나 API를 빠르게 유지하는 캐시 전략은 보지 못합니다.

그 보이지 않는 작업이 바로 실제 제품입니다.

데이터 집약적인 경험을 구축한다면, 프론트엔드는 단지 렌더러일 뿐입니다. 진짜 엔지니어링 과제는 업스트림(upstream)에서 발생합니다. 어떤 데이터 형태가 브라우저에 도달할지, 그리고 얼마나 많은 데이터가 전달될지를 결정해야 합니다.

시각화가 실제 트래픽을 견뎌내길 원한다면, 백엔드 우선 설계(backend-first design)가 필요합니다. 그렇지 않으면 불안정한 경로 위에 멋진 애니메이션 레이어만 얹은 데모를 출시하는 것에 불과합니다.

많은 시각화 스택이 실패하는 이유는 API가 스토리지 모델과 너무 밀접하기 때문입니다. 백엔드는 로우(raw) 레코드를 보내고, 프론트엔드는 데이터를 정제, 집계, 그룹화해야 하는 부담을 떠안습니다. 개발 단계에서는 이것이 빠르게 느껴질 수 있습니다. 하지만 운영 단계에서는 모든 사용자가 데이터 정제 비용을 지불하게 되므로 매우 비효율적이 됩니다.

백엔드는 로우 로그(raw log)가 아닌 플레이백 모델(playback model)을 제공해야 합니다.

백엔드가 무거운 작업을 처리하면 모든 것이 개선됩니다:

• CPU 작업이 브라우저 밖으로 이동합니다.
• 동작을 테스트하기 쉬워집니다.
• 캐시 효율성이 향상됩니다.
• 시스템이 예측 가능해집니다.

시각화는 특화된 소비자입니다. 빠른 액세스와 작은 페이로드(payload)가 필요합니다. 시각화에 관리자 대시보드나 데이터 내보내기와 동일한 API를 사용하도록 강요하지 마세요. 시각화만을 위한 전용 백엔드 계약(contract)을 제공하십시오.

전문적인 파이프라인은 다음 다섯 가지를 수행해야 합니다:

• 소스 레코드를 검증하여 잘못된 데이터를 거릅니다.
• 시간대나 단위와 같은 구조를 정규화합니다.
• 로우 행(row) 대신 플레이백 세그먼트를 도출합니다.
• 다양한 줌 레벨에 맞춰 여러 해상도를 생성합니다.
• 오래된 데이터가 섞이지 않도록 리비전(revision)을 찍습니다.

페이로드 크기를 프론트엔드의 문제로 취급하는 것을 멈추십시오. 그것은 API 계약의 문제입니다. 서버가 너무 많은 데이터를 보내면 상호작용은 결코 빠르게 느껴질 수 없습니다.

강력한 API는 가능한 한 가장 작으면서도 진실된 뷰(view)를 보냅니다. 시간, 지역, 상세 수준에 따라 요청 범위를 제한합니다.

시스템을 링(ring) 구조로 구축하십시오:

• 첫 번째 링은 개요(overview)를 통해 방향성을 제공합니다.
• 두 번째 링은 스크러빙(scrubbing)과 줌(zooming)을 위한 인터랙션을 제공합니다.
• 세 번째 링은 엔티티의 상세 정보를 확인하는 정밀 조사(inspection)를 제공합니다.

가동 시간(uptime)만 추적하지 마십시오. 페이로드 크기, 캐시 히트율, 데이터 신선도(freshness)를 추적하십시오. 무엇보다도, 처리된 결과물(artifacts)이 여전히 실제 데이터와 일치하는지 검증하십시오.

파생된 시각화는 데이터 제품입니다. 단순히 렌더링하는 것이 아니라 검증이 필요합니다.

프론트엔드가 버전 관리되는 데이터 제품을 위한 플레이백 클라이언트인 것처럼 백엔드를 구축하십시오. 그것이 바로 출시 후에도 견고하게 유지되는 시스템을 구축하는 방법입니다.

Source: https://dev.to/saqueib/interactive-data-visualizations-need-backend-thinking-too-5bk0