인프런 커뮤니티 질문&답변
작성한 질문수
실무 통계 질문(고민) 드립니다..!
작성
·
28
0
안녕하세요! 현재 사내 시스템의 기본 차트 기능이 요구사항을 구현하기엔 너무 복잡하고 한계가 있어서, 차라리 API로 데이터를 직접 뽑아 커스텀 대시보드 웹사이트를 자체 구축하여 운영하고 있습니다.
이 과정에서 데이터 구조 및 아키텍처 설계에 대한 고민이 생겨 선배님들의 조언을 구하고자 합니다.
[현재 상황 및 아키텍처]
요구사항: N개의 프로젝트마다 각기 다른 40여 개의 통계 차트를 제공해야 합니다.
데이터 수집 (파멸의 약 30만 번 API 호출...): 외부 API를 연동해 통계 데이터를 수집합니다. 전체 프로젝트 기준 매일 새벽 3시에 약 프로젝트 갯수 * 3000 번의 API 호출이 발생합니다.
배치 및 동시성 처리: Spring WebFlux를 활용해 10개 단위로 청크(Chunk)를 나누어 병렬로 배치 처리를 하고 있습니다.
데이터 적재: 프로젝트의 일별 베이스라인(Baseline)을 유지하기 위해 원본(Raw) 데이터는 MongoDB에 저장하고 있습니다.
실시간 동기화: 사용자가 화면에서 차트 '새로고침'을 누르면, 해당 시점에 즉시 API를 다시 쏘아서 데이터를 업데이트해 줍니다.
현재의 서빙 방식: 일별 통계 결과는 현재 Redis에 담아두고 클라이언트에 제공하고 있습니다.
🤔 [고민되는 지점] 프로젝트당 40개의 차트를 그리는데, 각 차트(통계)마다 필요한 Raw Data의 종류와 개수가 천차만별입니다.
처음에는 통계 결과용 RDB 테이블을 만들까 했지만, Project_ID와 구조가 제각각인 Raw Data들을 깔끔하게 담아내기가 까다로웠습니다. 그래서 현재는 캐시 툴에 크게 의존하고 있는데, 앞으로 차트 종류가 더 늘어나고 시스템이 확장될 것을 고려하여 좀 더 포괄적인 대응을 위해 "차트에 대한 메타데이터 테이블"을 별도로 설계하여 매핑하는 방식으로 구조를 개편할까 고민 중입니다.
💡 [질문 드립니다]
이처럼 요구되는 Raw Data의 형태와 수량이 각기 다른 수십 개의 차트를 서빙할 때, 메타데이터 테이블을 도입하여 관리하는 방식에 대해 어떻게 생각하시나요? 캐시에만 의존하는 것보다 나은 선택일까요?
혹시 비슷한 형태의 대규모 API 연동 기반 통계/대시보드 시스템을 구축에 있어, 추천할 만한 데이터 모델링이나 아키텍처 개선 방향이 있을지 궁금합니다....
개인적인 고민 질문드려 죄송하고 잘 모르는 후배가 선배님께 여쭤봅니다. 영한님이 아니시더라도 해당 고민을 들어주시고 의견 주시는 선배님들께 감사합니다 !
답변 1
0
안녕하세요, 인프런 AI 인턴입니다. 감사합니두~ 님.
데이터베이스 설계와 아키텍처 고민에 대한 질문을 주셨군요. 데이터 구조 및 아키텍처를 설계하는 것은 매우 중요한 일이며, 현재 시스템이 계속해서 발전하고 요구사항이 증가하는 상황에서 최적화를 고민하시는 모습이 인상깊습니다. 관련하여 몇 가지 정보와 기존 질문들을 참고할 수 있는 링크를 제공하겠습니다.
1. 메타데이터 테이블 관리 방식
메타데이터 테이블을 활용하여 차트에 필요한 데이터 구조와 매핑 정보를 관리하는 방식은 확장성과 유지보수성에서 유리할 수 있습니다. 캐시를 통해 빠른 성능을 제공할 수 있으나, 카테고리와 구조가 다양한 차트 데이터를 관리하고자 할 때는 메타데이터 테이블로 데이터의 유형과 특성을 명확히 정의하는 것이 도움이 됩니다. 그러면 새로운 차트가 추가되더라도 기존 시스템에 주는 영향을 최소화하면서 유연성을 확보할 수 있습니다.
2. 데이터 모델링 및 아키텍처 개선 방향
캐시 전략 최적화: 차트 업데이트 빈도가 낮고 큰 변화가 없을 경우, 캐시를 활용하는 것이 좋습니다. Redis와 같은 캐시 툴을 사용하여 자주 사용되는 데이터를 메모리에 저장함으로써 성능을 최적화할 수 있습니다.
분산 시스템 도입: 배치 작업의 분산 처리 및 로드 밸런싱을 통해 처리 효율성을 높일 수 있습니다. 예를 들어, Apache Kafka와 같은 메시지 큐를 통해 데이터를 스트리밍 방식으로 처리할 수 있습니다.
데이터 웨어하우스 고려: 통계성 데이터를 통합적으로 관리하고 분석하기 위해 데이터 웨어하우스를 도입하는 것도 하나의 방법입니다. BigQuery, Redshift, Snowflake 등의 솔루션을 고려할 수 있습니다.
참고할 수 있는 질문
- 통계성 데이터 조회 - 통계성 데이터를 어떻게 처리할지에 대한 또 다른 질문입니다. 네이티브 쿼리를 이용한 해결 방안에 대한 논의가 있습니다.
- 간단한 통계 쿼리가 가능한가요? - JPA와 QueryDSL을 통한 복잡한 통계 쿼리 처리 방식에 대해 다룸.
저는 질문자님의 이해를 돕고자 지식공유자님의 기존 답변을 참고하여 유사한 답변 링크를 추천해드리고 있습니다. 현재 베타 기능으로 답변이 만족스럽지 않을 수 있는 점 양해 부탁드립니다. 🙏 추가적으로 궁금한 점이 있으시면, 이어서 질문해 주세요. 곧 지식공유자께서 답변해 주실 것입니다.