StudyDad

데이터와 리포트 설계 시리즈 8/8작은 운영 콘솔의 리포트 시스템은 단순하게 시작할 수 있다.job table을 만들고, worker를 비동기로 실행하고, 결과 파일을 object storage에 저장한다.이 정도면 많은 내부 도구에는 충분하다.하지만 시간이 지나면 다시 검토할 지점들이 생긴다.좋은 설계는 처음부터 모든 것을 넣는 것이 아니라, 나중에 무엇을 볼지 알고 시작하는 것이다.현재 구조기본 구조는 다음과 같다.POST /api/reports-> job 생성-> worker 비동기 실행-> 파일 생성-> object storage 업로드-> job 완료-> polling으로 상태 확인이 구조는 단순하고 이해하기 쉽다.하지만 작업량이 늘거나 실패 대응이 중요해지면 개선 후보가 생긴다.1. 전용 Qu..

데이터와 리포트 설계 시리즈 7/8운영 콘솔에서 데이터베이스를 쓴다고 해서 모든 쿼리가 같은 성격은 아니다.화면 조회를 위한 쿼리와 리포트 생성을 위한 쿼리는 다르다.운영 데이터와 리포트 데이터도 다르다.이 차이를 무시하면 대시보드가 느려지거나, 리포트 생성이 운영 DB에 부담을 주거나, 정산성 데이터의 기준이 흔들릴 수 있다.운영 화면의 데이터운영 화면의 데이터는 빠르게 보여주는 것이 중요하다.예를 들어:오늘의 요약최근 주문상태별 건수점포 또는 사용자 목록간단한 필터 조회이런 데이터는 사용자가 화면에서 반복적으로 본다.응답 시간이 중요하고, 쿼리는 자주 실행된다.따라서 connection pool, index, pagination, cache 같은 요소가 중요하다.리포트 데이터리포트 데이터는 성격이 다..

데이터와 리포트 설계 시리즈 6/8운영 콘솔에는 통계 화면이 자주 등장한다.월별 매출, 주문 수, 사용자 수, 처리 건수, 리포트 합계 같은 지표를 보여준다.처음에는 화면이 열릴 때마다 원천 데이터를 조회해서 실시간 집계하면 된다고 생각할 수 있다.하지만 운영 통계는 매번 실시간으로 계산하는 것이 항상 좋은 선택은 아니다.반복 조회되는 통계는 미리 계산해두는 편이 더 안정적일 수 있다.문제 상황운영자는 대시보드에서 월별 통계를 자주 확인한다.통계는 여러 원천 데이터를 조합해서 계산해야 한다.데이터 범위가 넓거나 쿼리가 복잡하면 매번 화면 조회 시 집계하는 방식은 부담이 된다.특히 다음 문제가 생길 수 있다.대시보드 로딩이 느려진다.DB에 반복적인 집계 부하가 생긴다.같은 월 통계를 여러 사용자가 반복 조..

데이터와 리포트 설계 시리즈 3/8오래 걸리는 리포트 생성을 비동기로 처리하려면 작업 상태를 저장할 곳이 필요하다.메모리에 상태를 들고 있으면 안 된다.서버가 재시작될 수 있고, Lambda는 실행 환경이 유지된다는 보장이 없으며, 운영자는 나중에 작업 이력을 확인해야 한다.그래서 job table이 필요하다.job table의 역할job table은 리포트 생성 작업의 기록장이다.사용자가 리포트를 요청하면 먼저 job row를 만든다.worker는 이 job을 처리하면서 상태를 갱신한다.프론트엔드는 job id로 상태를 조회한다.job table이 있으면 작업은 추적 가능한 단위가 된다.기본 상태 모델처음에는 단순한 상태만으로도 충분하다.PENDINGIN_PROGRESSCOMPLETEFAILED각 상태..

데이터와 리포트 설계 시리즈 1/8운영 콘솔에서 리포트 기능은 단순해 보인다.사용자는 조건을 선택하고 버튼을 누른다. 잠시 뒤 엑셀 파일을 내려받는다.겉으로 보면 "조회해서 파일로 만들면 되는 기능"처럼 보인다.하지만 실제로 만들어보면 리포트 기능은 단순 조회 API와 다르다. 데이터 조회, 집계, 파일 생성, 작업 상태, 저장, 다운로드, 실패 처리까지 함께 설계해야 한다.버튼 하나 뒤에 있는 일들사용자는 하나의 버튼을 본다.[리포트 다운로드]하지만 시스템 내부에서는 여러 단계가 이어진다.요청 파라미터 검증-> 작업 생성-> 데이터 조회-> 집계 또는 가공-> 엑셀 파일 생성-> 파일 저장-> 작업 상태 갱신-> 다운로드 URL 제공이 중 하나라도 실패하면 사용자는 파일을 받지 못한다.그래서 리포트 기..