<aside> 🏁 실전 프로젝트 6주차에 가장 집중해주셔야 할 것은 “최종 발표회 준비”입니다. 최종 발표에는 6주간 진행했던 프로젝트 개발 과정을 엔지니어답게 설명할 수 있어야합니다. 아래 항목들을 바탕으로 기술적으로 더욱 매력적인 최종 발표를 준비해봅니다.

</aside>

• 우리 프로젝트에서 기술적으로 강점을 삼을 만할 항목을 정리해 주세요. (최종 발표 및 면접에서 프로젝트를 진행할 때 어떤 도전을 했는지 말할 수 있는 좋은 소스가 됩니다)

  • 검색, 조회 성능 향상(Query DSL, 인덱스, full-text-search, *Redis)
  • Redis로 DB 분산
  • 동시성 제어
  • 모니터링
  • 테스트 커버리지
  • 서버 튜닝

• 우리 프로젝트에서 기술적으로 강점을 삼을 만할 항목을 정리해 주세요. (최종 발표 및 면접에서 프로젝트를 진행할 때 어떤 도전을 했는지 말할 수 있는 좋은 소스가 됩니다)

  • 남병관 멘토님 기술 제언 참고

  구분	요구사항	선택지	핵심 기술을 선택한 이유 및 근거
  BE	1000만 건 상품 데이터 필터링 데이터 조회	- QueryDSL

  • Index
  • Redis | QueryDSL
  1. 동적인 쿼리 작성이 편리함.
  • 프로젝트 특성 상 조회 시 여러 가지 조건에 따라 동적으로 쿼리문이 실행되어야 하는 상황이 존재
  2. 자동 완성 등 IDE의 도움을 받을 수 있음.
  3. 문자가 아닌 코드로 쿼리를 작성함으로써, 컴파일 시점에 문법 오류를 쉽게 확인할 수 있다.
  • 쿼리문을 작성하며 자동완성과 문법 오류를 검증할 수 있기 때문에 편리함
  4. 쿼리 작성 시 제약 조건 등을 메서드 추출을 통해 재사용할 수 있음.
  • 쿼리문이 길어지게 되면 가독성이 떨어지는데 메서드를 사용하여 재사용하여 쿼리문의 길이를 줄이면 가독성이 증가함

  Index mysql에서 index를 생성하여 조회하면 B-Tree 구조로 index를 생성하게 되는데 검색이나 정렬 시 B-Tree의 루트 노드부터 시작해 브랜치 노드를 거쳐 최종 리프 노드까지 이동하면서 비교하 작업을 수행하기(트리탐색) 때문에 작업속도가 매우 우수함.

  Redis

  1. 메인페이지 로딩 최적화를 위해 캐시된 데이터를 사용해야했고, 랭킹보드 활용이 필요해 레디스 zSet을 활용했다.

  2. i/o가 많은 조회가 끊임없이 db에 update문을 날리고 성능 저하로 연결됐고, 이를 해결하기 위해 조회 increment를 레디스에서 받아 주기적으로 배치해주는 WriteBack 기술을 적용했다.

  3. 클릭이 많은 인기 상품페이지를 캐싱해서 사용하고, warmup 동작 시 부하를 낮추기 위해 파이프라인을 구축했다. | | | | 1000만 건 상품 데이터 키워드 검색 | - Full-Text-Search | Full-Text-Search 1000만건이 되는 데이터의 키워드를 조회하려고 하기 like 키워드 만으로 조회를 하기에는 한계가 있다는 것을 느꼈음. 1000만 건의 5분의 1 수준 200만건을 조회하는데도 32.09초가 걸려 목표로하는 2초 이내의 조회를 하기에는 많이 부족해 보여서 인덱스를 활용하여 조회하는 full-text-search를 도입하여 조회 성능을 향상시키고자 했음. | | | | 이벤트 시 주문 동시성 처리 | - Pessimistic Lock

  • Optimistic Lock
  • Lettuce
  • Redisson
  • Synchronized | - Pessimistic Lock -> DB Replica -> Max pool size custom -> 트랜잭션 분리 Propagation.REQUIRES_NEW -> saveAndFlush() } | |

• 이번 주 한 일

  • 팀 전체 (리더님께서 필두로 정리해 주세요.)

    순서	내용	완료 여부
    1	RDS 읽기 전용 복제본	완료✅
    2	JMeter 부하테스트	진행중🟨
    3	노션 / 리드미 작성 (기술 스택 사용 이유, 트러블 슈팅)	진행중🟨
    4	프론트 배포 VERCEL	예정⬜
    5	React 코드	완료✅

• 성능개선 내용을 기반으로, 최종자료에 무엇을 어떻게 정리하면 좋을지 우선순위 별로 기록 해 주세요

  우선순위	성능개선 및 추가사항	마감일자
  1	조회/검색 성능 향상
  2	동시성 제어
  3	테스트 커버리지
  4	부하테스트
  5	모니터링

• 트러블 슈팅 : 000상황(기능, 인프라, 서버 문제)에서 0000(지표) 한 문제가 있어서, ㅌㅌㅌㅌ 중에서 0000을 적용했고, 그래서 3333(지표)이 (000%) 만큼 개선되었다.
• 프로젝트 소개 : 의류 쇼핑몰 - 사용자 편의성을 위해 대용량 데이터 의류 조회 및 필터링이 가능
• 기능
  • 주요기능 : 대용량 데이터(0000건), 상품 필터링 조회, 필터링, 재고 처리
  • 검색 성능
    • 검색, 조회 성능 향상(Query DSL, 인덱스, full-text-search, Redis)
    • → 검색, 조회 성능 향상(Redis, 복합 인덱싱, full-text-search, Query DSL)
  • 시나리오 항목 - 동시성 제어
  • 안정적 DB 운영
    • Redis로 DB 분산
  • 서비스 안정성
    • 테스트 커버리지 00%
    • 부하테스트
    • 모니터링 ( 알림 )
  • 배포
    • 서버 튜닝 → 부하테스트 메모리 증량, 커넥션 풀
    • 모니터링 - 뭐뭐뭐
    • GithubAction, Beanstlk
• 트러블 슈팅
  • 서버 튜닝 → 부하테스트 메모리 증량
  • 동시성 처리 - 비관적 락 선택 - 강점으로

꺼꾸로 가도 상관은 없는데 개발 프로세스 기준에 맞춰서

인프라(아키텍쳐, 모니터링) - 배포 - DB(분산 DB - 인덱싱 - 모델링) - 기능 (검색 - Redis 활용, 동시성 제어)