25.04.03‐회의록 - LIMITED-TEAM25/wiki_repository GitHub Wiki

심화 파이널 프로젝트 주제 선정

상품 선착순 판매 서비스

  • 설명

    • 상품 판매 시스템
      • 상품 개수 제한, 선착순 판매
    • 쿠폰 발행 시스템
      • 쿠폰의 개수 제한, 선착순 쿠폰 습득 가능
    • 상품 경매 시스템 - down
      • 시간 제한, 실시간으로 가격 변동 발생시 해당 정보 반영하여 소비자가 추가 입찰
    • 체험단 시스템
      • 랜덤 선발
        • 응모 인원 제한 X
        • 선발 인원 제한 O

  • 기술 포인트

    • 대용량 트래픽 처리 및 대응
      • Redis, Kafka, AWS 사용으로 트래픽 집중 시 캐싱, 스케일 업, 비동기 처리
    • 대용량 & 실시간 데이터 처리
      • 대용량 : Kafka 메시지 큐 사용하여 처리,
    • 모니터링 시스템 구축
      • Prometheus(수집), Grafana(view 제공), Loki(로그 저장), Promtail(로그수집)를 활용한 실시간 메트릭 및 로그 모니터링으로 시스템 안정성 확보
      • 모니터링 정보 슬랙 전송 + actuator

  • 서비스 기능 정의

    • 상품 판매 시스템 -

      • 상품의 개수에 제한이 있으므로 선착순 판매 기능 구현
        • Kafka 메시지 큐를 사용하여 상품의 실제 개수만큼 성공 반환
        • 상품 개수 이상의 요청은 실패 응답 반환.
        • 파티션이 여러개이면….. 고민!

    • 쿠폰 발행 시스템

      • 쿠폰의 개수 제한이 있으므로 선착순 쿠폰 발행 기능 구현
        • Kafka 메시지 큐를 사용하여 쿠폰의 실제 개수만큼 성공 반환
        • 쿠폰 개수 이상의 topic은 실패 응답 반환.
        • 파티션이 여러개이면….. 고민!

    • 구매 입찰 시스템 (블라인드 경매)

      • 시간 제한, 추가입찰 불가, 최대 금액 입찰자 선정
        • 제한된 시간 내에 가장 높은 가격을 입찰한 회원이 해당 상품 구매 가능
        • 현재 최고 입찰가 이하로 요청한 가격은 실패 처리

    • 체험단 시스템

      • 인원 제한, 랜덤 선발
      • 가입일 or 실 구매자 기반으로 지원 자격 제한(로그인 기록 테이블 필요) 성별, 나이 간단하게 잡기!

  • 적용 기술

    • 상품 판매 시스템
      • 상품 개수 제한, 선착순 판매
    • 쿠폰 발행 시스템
      • 쿠폰의 개수 제한, 선착순 쿠폰 습득 가능
      • 랜덤 쿠폰(사용시 랜덤하게 할인률 적용), 개수 제한 없음 - 리팩톤 시 적용
    • 구매 입찰 시스템
      • 시간 제한, 실시간으로 가격 변동 발생시 해당 정보 반영하여 소비자가 추가 입찰
    • 체험단 시스템
      • 인원 제한, 랜덤 선발

  • 기능 리스트

    • 인증/인가 서비스

      권한 생성 삭제 조회 및 검색
      ADMIN O O O
      USER O (본인) O (본인) O (본인)
      • 쿠폰 CRU 발급, 소진, 기간 X 테스트 복잡도 상승
      • 선착순으로 판매가 진행 되었음. → 이미 완료된 주문에 대하여 쿠폰을 적용하여 계좌 환급
      • 트래픽, 데이터 처리는 선착순 상품 판매와 동일

    • 체험단 서비스 5

      • 선발된 회원 & 체험할 상품
      • 선발 인원 제한 = 체험할 상품의 수량, 랜덤 선발
    1. 공통 모듈 포함하기
    2. 자세한 사항은 내일 피드백 후!!

  • 기술적 의사 결정

  1. 비관락 분산락 관련
  2. Github Actions
  3. 선착순 서비스 공통으로 뺄것인가 기능별로 하나씩 둘것인가.

문제 발생

  • 예를 들어 주문 서비스에 많은 요청이 몰릴 경우 주요 서비스인 주문 서비스가 다운될 가능성이 존재합니다.
  • 해당 문제를 해결하기 위해 많은 API 요청이 들어올 경우 해당 요청을 복잡하게 처리하지 않고, 바로 메세지로 전송하는 서비스가 필요하다고 생각합니다.

팀원 의견

  • 중간 서버를 만들어서 대용량 트래픽 처리를 감당하는것이 좋을 것 같습니다.
  • 서버를 여러개로 분리하면 비용이 많이 나올 수 있다 VS 분리하는게 좋다

질문 내용

  • 대용량 데이터 처리 전용 서버를 하나만 구현(하나만 둔다면 내부에서 기능별 분리여부)

    OR

    선착순,경매,쿠폰,체험단 서비스 별로 분리해서 구현

요청이 들어옴 (주문 서비스 API 호출 : 주문 생성) → 하나의 주문 요청이 처리되지 않았는데 계속 주문요청이 들어옴 → 과부화

주문 → 요청 처리(Kafka 메세지 생성)→ 데이터 처리(주문 서비스에서 주문 생성) → (상품 레디스) → 주문완료

버튼을 눌렀을때 → api 게이트 → (4개 나누는 서비스)특정 이벤트 (트래픽 처리) → 레디스 접근해서 (상품 재고 차감) → 완료 건에 대해서 주문 넣기 → 주문 완료 건/ 취소 건 분류해서 다시 레디스에 업데이트

  • 튜터님 피드백
  • 도메인 선정 : 이커머스(상품 선착순 구매)
  • 구현기능 선정 : 기능에 대한 기술적 접근 시도(대략적으로. 기술 선택 포함)
  • 협업 컨벤션
  • 코드스타일 지정
  • 결제시스템 제외
  • 도메인 간단한걸로 다시 생각해보기

단일 파티션 좀 더 고민해보기(확장성 없음, 컨슈머 확장 안됨, 처리량 제한됨)

인당 1~3개 정도 api 기능 맡아서 하기

본인이 맡은 부분 → 설계, 구현, 배포, 성능테스트(스크립트, 시나리오), 모니터링, 개선사항 전부

ㄴ 한 사이클 전부 돌 수 있게

도커 허브를 활용한 이미지 관리 논의.

  • PR을 올릴경우 PR 올린분이 현재 변경점을 반영하여 docker hub에 push
  • PR이 빠르게 반영되지 않을 가능성을 생각하여 도커 허브에 올라온 이미지로 빠르게 테스트.
⚠️ **GitHub.com Fallback** ⚠️