운영 DB와 리포트 DB를 나눠 생각하기

데이터와 리포트 설계 시리즈 7/8

운영 콘솔에서 데이터베이스를 쓴다고 해서 모든 쿼리가 같은 성격은 아니다.

화면 조회를 위한 쿼리와 리포트 생성을 위한 쿼리는 다르다.

운영 데이터와 리포트 데이터도 다르다.

이 차이를 무시하면 대시보드가 느려지거나, 리포트 생성이 운영 DB에 부담을 주거나, 정산성 데이터의 기준이 흔들릴 수 있다.

운영 화면의 데이터

운영 화면의 데이터는 빠르게 보여주는 것이 중요하다.

예를 들어:

• 오늘의 요약
• 최근 주문
• 상태별 건수
• 점포 또는 사용자 목록
• 간단한 필터 조회

이런 데이터는 사용자가 화면에서 반복적으로 본다.

응답 시간이 중요하고, 쿼리는 자주 실행된다.

따라서 connection pool, index, pagination, cache 같은 요소가 중요하다.

리포트 데이터

리포트 데이터는 성격이 다르다.

리포트는 넓은 기간의 데이터를 조회하고, 여러 조건을 조합하며, 파일로 생성된다.

특징은 다음과 같다.

• 조회 범위가 넓다.
• 실행 빈도는 낮을 수 있다.
• 한 번 실행될 때 부하가 크다.
• 결과의 재현 가능성이 중요하다.
• 감사 추적이 필요할 수 있다.
• 파일 산출물이 남는다.

이런 작업을 운영 화면 조회와 같은 방식으로 처리하면 문제가 생길 수 있다.

같은 DB를 써도 경로는 나눠야 한다

물리적으로 DB가 하나일 수도 있다.

하지만 논리적으로는 경로를 나눠 생각해야 한다.

운영 화면 조회
-> 짧고 잦은 SELECT
-> 상주 API 서버
-> connection pool

리포트 생성
-> 넓고 무거운 SELECT
-> 비동기 worker
-> job table
-> object storage

같은 데이터베이스를 읽더라도 실행 모델이 다르다.

이 구분이 없으면 무거운 리포트 생성이 일반 화면 응답에 영향을 줄 수 있다.

read/write 분리

일부 시스템에서는 read host와 write host를 나눌 수 있다.

읽기 쿼리는 read replica로 보내고, 상태 변경이나 job 갱신은 write host로 보낸다.

리포트 생성은 대부분 읽기 작업이지만, job 상태 갱신은 쓰기 작업이다.

따라서 다음을 구분해야 한다.

• 원천 데이터 조회
• 작업 상태 생성
• 작업 상태 갱신
• 결과 파일 위치 저장

읽기와 쓰기 연결이 섞이면 장애나 일관성 문제가 생길 수 있다.

감사 추적이 필요한 데이터

리포트나 정산성 데이터는 단순 조회보다 감사 추적이 중요할 수 있다.

예를 들어 다음을 남겨야 할 수 있다.

• 누가 요청했는가
• 어떤 조건으로 생성했는가
• 언제 생성했는가
• 어떤 파일이 결과물인가
• 실패했는가
• 재생성했는가

이 정보는 운영 화면 조회에는 필요하지 않을 수 있다.

하지만 리포트 기능에는 필요하다.

그래서 job table이나 history table이 생긴다.

원천 데이터와 산출물 구분

리포트 파일은 원천 데이터가 아니다.

원천 데이터에서 특정 시점과 조건으로 생성한 산출물이다.

따라서 리포트 파일을 저장할 때는 원천 데이터와 구분해야 한다.

RDB: 원천 데이터, job 상태
Object storage: 생성된 파일

파일을 DB에 직접 넣기보다 object storage에 두고, DB에는 위치와 metadata를 저장하는 편이 일반적이다.

대시보드와 리포트 숫자 맞추기

대시보드와 리포트가 같은 지표를 다룰 때 숫자가 달라지면 신뢰가 떨어진다.

이 문제를 줄이려면 지표 정의를 공유해야 한다.

• 같은 기준 날짜를 쓰는가
• 같은 상태값을 포함하는가
• 취소나 예외를 같은 방식으로 처리하는가
• 세금이나 수수료 기준이 같은가
• 통계 적재와 리포트 생성이 같은 로직을 쓰는가

가능하면 공통 view, 통계 테이블, 또는 문서화된 쿼리 기준을 둔다.

DB 부하 관점

리포트 쿼리는 DB에 부담을 줄 수 있다.

운영 시간 중 무거운 리포트가 여러 개 실행되면 화면 조회가 느려질 수 있다.

완화 방법은 여러 가지다.

• 비동기 worker로 분리
• 동시 실행 수 제한
• read replica 사용
• 월별 통계 사전 적재
• 쿼리 최적화
• 리포트 생성 시간 제한
• 캐시 또는 기존 파일 재사용

중요한 것은 리포트 작업이 일반 운영 화면을 방해하지 않게 하는 것이다.

정리

운영 DB와 리포트 DB를 반드시 물리적으로 나눠야 한다는 뜻은 아니다.

먼저 논리적으로 나눠 생각해야 한다.

운영 화면 조회는 짧고 잦다.

리포트 생성은 드물지만 무겁고, 상태 추적과 산출물 저장이 필요하다.

이 둘을 같은 실행 모델로 다루면 운영 문제가 생길 수 있다.

따라서 데이터 경로를 나눈다.

• 빠른 조회 API
• 비동기 리포트 worker
• job table
• object storage
• 통계 적재

운영 데이터와 리포트 데이터의 차이를 이해하는 것이 안정적인 관리자 페이지의 출발점이다.

함께 볼 GitHub 저장소

• report-job-worker-demo