/musinsa

musinsa assignment

Primary LanguageJava

Musinsa Assignment

목차

서비스 구조 및 아키텍처와 ERD

  • gateway
    • backoffice와 search 서비스의 게이트웨이 역할
    • 8080 포트로 모든 요청을 받음
  • backoffice
    • 상품 및 브랜드의 추가/수정/삭제 서비스
  • search
    • 사용자에게 필요한 데이터 검색 서비스
      • 카테고리 조합 최저가 조회
      • 단일 브랜드 최저가 조회
      • 카테고리 최저가 상품 조회
  • aggregator
    • backoffice 데이터 집계하여 search 서비스에 사용할 수 있도록 ETL 수행 역할

아키텍처

ERD

주어진 조건 외 사용한 스택 및 라이브러리

  • Spring Cloud Gateway
    • backoffice 성격의 서비스와 사용자 서비스의 컨테이너 분리 및 동일한 포트의 요청 수신을 위해 도입
  • Redis
    • backoffice에서 수정되는 H2 DB와 별개로, 사용자의 조회용 데이터를 따로 저장해두기 위한 용도로 도입
    • 요구사항에 명시된 데이터를 조회하기 위해서 H2 DB의 집계된 데이터가 필요함
      • 해당 집계 데이터는 상품 데이터의 변경이 없는 한 멱등성이 지켜지는 데이터이므로 미리 집계해두어 Redis에 저장
      • 만약 backoffice를 통해 상품데이터가 변경되면, aggregator에 의해 집계 데이터 갱신 API 호출하여 새로운 집계 데이터 저장
  • Open Feign
    • backoffice에서 상품데이터가 변경되면 aggregator API 호출하기 위해 사용한 원격 API 호출 라이브러리

요구사항 구현

  • search 기능

    • 고객은 카테고리 별로 최저가격인 브랜드와 가격을 조회하고 총액이 얼마인지 확인할 수 있어야 합니다.
    • 고객은 단일 브랜드로 전체 카테고리 상품을 구매할 경우 최저가격인 브랜드와 총액이 얼마인지 확인할 수 있어야 합니다.
    • 고객은 특정 카테고리에서 최저가격 브랜드와 최고가격 브랜드를 확인하고 각 브랜드 상품의 가격을 확인할 수 있어야 합니다.

  • backoffice 기능

    • 운영자는 새로운 브랜드를 등록하고, 모든 브랜드의 상품을 추가, 변경, 삭제할 수 있어야 합니다.

실행법

docker-compose 이용

  • h2, redis, backoffice, search, aggregator, gateway 컨테이너를 컴포징 하여 실행하는 방법입니다.
# docker-compose.yml과 docker-build 스크립트가 위치한 경로로 이동 후 아래 과정을 실행합니다.

# windows
> .\docker-build.bat

# etc
$ ./docker-build.sh


...
[+] Running 7/7
 ⠿ Network musinsa_default  Created    0.0s
 ⠿ Container musinsa-h2     Started    0.6s
 ⠿ Container musinsa-redis  Started    0.8s
 ⠿ Container backoffice     Started    1.0s
 ⠿ Container aggregator     Started    1.2s
 ⠿ Container search         Started    1.5s
 ⠿ Container gateway        Started    1.9s



$ docker ps
CONTAINER ID   IMAGE                    COMMAND                  CREATED         STATUS         PORTS                    NAMES
9ecc4eb194b8   musinsa/gateway:1.0      "java -jar -Dspring.…"   3 minutes ago   Up 3 minutes   0.0.0.0:8080->8080/tcp   gateway
a3418a1d6a40   musinsa/search:1.0       "java -jar -Dspring.…"   3 minutes ago   Up 3 minutes   8001/tcp                 search
5fbeb0a919a8   musinsa/aggregator:1.0   "java -jar -Dspring.…"   3 minutes ago   Up 3 minutes   8002/tcp                 aggregator
6e226b3451ad   musinsa/backoffice:1.0   "java -jar -Dspring.…"   3 minutes ago   Up 3 minutes   8000/tcp                 backoffice
9195318731ff   redis:7.0.4              "docker-entrypoint.s…"   3 minutes ago   Up 3 minutes   6379/tcp                 musinsa-redis
c747cad23ea4   oscarfonts/h2:2.1.210    "/bin/sh -c 'java -c…"   3 minutes ago   Up 3 minutes   81/tcp, 1521/tcp         musinsa-h2


# 중지
docker-compose down

postman으로 실행해보기

postman 컬렉션 import 하여 순차적으로 실행해보며 결과를 확인할 수 있습니다.

개선 포인트

  • backoffice에서 대량 상품 정보 변경 수행에 대한 고민
    • 현재는 단일 상품, 단일 브랜드에 대한 기능 뿐이지만, 대량의 상품 가격 일괄 변경과 같은 기능이 없습니다.
  • aggregator 작동 방식에 대한 고민
    • 매번 전체 집계를 수행하여 효율이 좋지 않습니다.
    • 증분 데이터, 변경 데이터에 대한 명확한 감지가 가능하다면 집계 로직을 간소화 할 수 있습니다.
      • Kafka CDC Connector를 지원하는 RDB를 사용한다면 구현해볼 수 있습니다.
  • redis에 대한 고민
    • 현재 요구사항에 의하면 사용자가 조회할 집계 데이터는 상품 정보가 변경되지 않는 한 멱등성이 보장되는 데이터입니다.
    • 추후 조회할 데이터들의 종류가 많아지고, 그 안에서 특정 조건으로 검색을 해야 할 상황이라면 redis는 그다지 좋은 선택지는 아니라고 생각합니다.
    • 다중 조건 검색에 유리한 Elasticsearch를 도입하면 다양한 요구사항에 맞는 집계 검색 또는 조건 검색을 수행할 수 있습니다.
    • 이 때, 현재 aggregator와 비슷한 작동을 하는 색인기가 필요하고 정확한 변경사항을 반영하여 색인을 하기 위해서는 중간에 메세지 큐 등이 필요할 수 있습니다.