PROJECT DETAIL / 업무 프로젝트

AMS

배송 메시지 발송 이력과 통계·정산을 관리하는 백엔드

배송 시스템 연계 모듈개발·운영

  • Java 21
  • Spring Boot
  • PostgreSQL
  • ECS Fargate
  • S3
  • EventBridge
OVERVIEW

프로젝트 개요

배송 앱의 문자 발송 이력과 통계·정산 API를 개발했습니다. 원본 이력에 발송 일시 기준 RANGE 파티셔닝을 적용해 조회 범위를 줄이고 보관 기간이 지난 데이터를 파티션 단위로 삭제하도록 설계했습니다.

SCOPE

담당 업무 및 개발 내용

배송 앱과 연계되는 메시지 이력·정산 모듈의 백엔드 설계와 API 개발을 담당했습니다. 원본 이력의 파티셔닝과 조회·보관 정책, 일별·월별 집계, S3 이미지 업로드·조회를 구현하고 AWS 환경에서 배포·운영했습니다.

원본 이력
발송 일시 RANGE 분할
조회 최적화
파티션 프루닝 · 집계
보관 정책
1년 경과 파티션 삭제

01 / ARCHITECTURE

시스템 구성과 처리 흐름

발송 이력 저장과 통계·정산 조회

  1. 배송 앱문자 발송 결과 전달
  2. Spring API이력 저장 · 조회
  3. 원본 이력발송 일시 RANGE 분할
  4. 집계 · 정산EventBridge 배치
원본 이력은 발송 일시 기준의 RANGE 파티션에 저장하고, 기간 조건이 있는 조회는 파티션 프루닝을 활용합니다. EventBridge 배치로 일별·월별 집계 데이터를 만들며, 1년이 지난 원본 데이터는 해당 파티션을 DROP하는 방식으로 정리합니다. 이미지는 Pre-signed URL을 통해 S3와 직접 통신합니다.

02 / IMPLEMENTATION

주요 기능과 설계

기능별 처리 흐름과 문제 해결 과정, 설계 이유와 구현 결과를 소개합니다.

FEATURE 01 구현 완료

발송 이력

LMS·MMS 발송 결과를 저장하고 운송장 기준으로 조회합니다.

발송 이력 처리 흐름

  1. 발송 결과LMS · MMS
  2. 이력 API결과 수신
  3. 원본 저장발송 상태 관리
  4. 이력 조회운송장 기준
PROBLEM

문제

배송 앱에서 발생하는 문자 발송 결과를 추적하고 기사별 발송량을 정산에 활용할 수 있는 관리 기능이 필요했습니다.

SOLUTION

해결

발송 라이브러리의 결과를 수신하는 API와 운송장 번호 기준의 이력 조회 기능을 구현했습니다.

설계 이유와 트레이드오프

추적용 원본과 정산용 집계 구분

발송 이력은 개별 결과를 추적하는 근거로 보관하고 정산은 집계 데이터로 조회합니다. 조회 목적에 맞는 데이터 구조를 사용할 수 있지만 원본과 집계의 갱신 시점은 달라집니다.

VALIDATION

구현 결과와 테스트

운송장 기준 발송 이력 조회와 기사별 발송량 집계를 제공해 이력 추적과 정산 업무를 지원했습니다.

FEATURE 02 구현 완료

파티셔닝·보관 정책

발송 일시 기준으로 원본 이력을 분할해 조회와 보관 만료 데이터의 삭제를 함께 설계했습니다.

파티셔닝·보관 정책 처리 흐름

  1. 원본 저장발송 일시 RANGE
  2. 기간별 분할시간 범위별 파티션
  3. 기간 조건 조회파티션 프루닝
  4. 보관 만료1년 경과 파티션 DROP
발송 원본의 저장·조회·보관 만료 처리 과정입니다. 조회와 삭제는 각각 필요한 시점에 수행합니다.
PROBLEM

문제

발송 이력이 계속 쌓이면 기간별 조회의 탐색 범위가 커지고 오래된 원본을 행 단위로 대량 삭제하는 작업도 DB에 부담을 줍니다.

SOLUTION

해결

발송 일시를 기준으로 RANGE 파티셔닝을 적용했습니다. 기간 조회 조건으로 관련 파티션만 탐색하도록 구성하고, 1년이 지난 데이터는 보관 만료 파티션을 DROP해 정리하도록 설계했습니다.

설계 이유와 트레이드오프

조회 조건과 보관 기준에 맞춘 분할

기간별 이력 조회와 1년 보관 정책에 같은 시간 기준을 사용했습니다. 데이터가 늘어도 조회할 파티션 범위를 제한할 수 있지만, 파티션 기준과 맞는 기간 조건을 쿼리에 포함해야 합니다.

행 단위 DELETE 대신 파티션 DROP

만료된 데이터를 한 행씩 삭제하는 대신 파티션 단위로 제거해 대량 삭제와 이후 정리 작업의 부담을 줄였습니다. 파티션 경계와 보관 기간을 맞춰야 하며, 생성·삭제 시점과 DDL 잠금은 운영 과정에서 고려해야 합니다.

VALIDATION

구현 결과와 테스트

기간 조건 조회에 파티션 프루닝을 적용해 조회 범위를 줄였습니다. 1년이 지난 원본 데이터를 파티션 DROP으로 정리할 수 있는 보관 정책을 설계했습니다.

FEATURE 03 구현 완료

이미지 업로드

Pre-signed URL로 이미지 전송과 API 처리를 분리했습니다.

이미지 업로드 처리 흐름

  1. 클라이언트업로드 URL 요청
  2. API 서버Pre-signed URL 발급
  3. S3 직접 전송이미지 업로드
  4. 이미지 조회조회 URL 발급
PROBLEM

문제

이미지 전송을 API 서버가 중계하면 파일 크기와 요청량에 따라 서버의 네트워크·처리 부담이 커집니다.

SOLUTION

해결

API에서 S3 Pre-signed URL을 발급하고 클라이언트가 S3에 직접 업로드·조회하도록 구현했습니다.

설계 이유와 트레이드오프

API는 접근 제어, S3는 파일 전송

API 서버는 파일 접근에 필요한 URL을 발급하고 이미지 데이터는 S3로 전송합니다. 서버의 파일 중계를 줄이는 대신 URL 만료 시간과 객체 접근 정책을 관리해야 합니다.

VALIDATION

구현 결과와 테스트

이미지 업로드·조회 경로를 S3 직접 통신으로 전환해 API 서버가 이미지 바이너리를 중계하는 구조를 개선했습니다.

FEATURE 04 구현 완료

집계·정산

대량 발송 이력을 일별·월별로 집계해 통계와 정산에 활용합니다.

집계·정산 처리 흐름

  1. 발송 원본지속 적재
  2. 배치 실행EventBridge
  3. 집계 데이터일별 · 월별
  4. 조회 API통계 · 정산
PROBLEM

문제

통계·정산 요청마다 대량의 발송 원본을 집계하면 조회 비용과 운영 DB의 부담이 커집니다.

SOLUTION

해결

원본 이력과 조회용 집계 데이터를 분리하고 EventBridge 기반의 일별·월별 집계 흐름을 구성했습니다.

설계 이유와 트레이드오프

사전 집계로 반복 계산 줄이기

배치에서 집계한 결과를 조회하면 요청마다 원본 전체를 계산하지 않아도 됩니다. 대신 배치 완료 시점까지 최신 원본이 집계 결과에 반영되지 않는 지연을 고려해야 합니다.

VALIDATION

구현 결과와 테스트

일별·월별 집계 데이터를 기반으로 통계·정산 API를 제공하고 원본 적재와 집계 조회의 역할을 분리했습니다.

03 / RESULTS & TESTING

개발 결과와 테스트

AMS 개발 결과
항목결과
처리 규모일 50만~200만 건 규모의 메시지 발송 이력 관리
이력 관리운송장 기준 추적 및 기사별 발송량 집계
원본 관리발송 일시 RANGE 파티셔닝, 기간 조회 프루닝, 1년 경과 파티션 DROP
이미지 처리S3 Pre-signed URL을 통한 직접 업로드·조회
통계 · 정산EventBridge 기반 일별·월별 집계와 조회 API

04 / REFLECTION

개발 회고와 개선 방향

회고

발송 이력은 저장과 조회뿐 아니라 보관 기간이 끝난 뒤의 정리 방식까지 고려해야 했습니다. 원본 파티셔닝으로 기간 조회와 만료 데이터 삭제를 설계하고, 통계·정산은 별도 집계 데이터로 제공했습니다. 파일 전송도 S3로 분리하면서 각 처리 목적에 맞는 구조를 구성했습니다.

NEXT / 향후 계획

향후 개선 방향

다시 설계한다면 파티션 경계와 보관 기간, 파티션 생성·삭제 작업의 관찰 지표를 더 명확하게 정리하겠습니다. 집계 지연과 재처리 기준, 원본과 집계 결과를 대조하는 절차도 함께 고려하겠습니다.

다른 프로젝트도 살펴보기

업무 프로젝트모바일·기간계 연계 미들웨어업무 프로젝트오토스캐너 연계 API업무 프로젝트배송지 주소 조회 서비스개인 프로젝트PeakLog개인 프로젝트WMS-Lite
전체 프로젝트로 돌아가기 ←

처리 흐름

100%확대 후 가로·세로로 스크롤할 수 있습니다.
선택한 확대 도식
↑