| 일 | 월 | 화 | 수 | 목 | 금 | 토 |
|---|---|---|---|---|---|---|
| 1 | 2 | 3 | 4 | |||
| 5 | 6 | 7 | 8 | 9 | 10 | 11 |
| 12 | 13 | 14 | 15 | 16 | 17 | 18 |
| 19 | 20 | 21 | 22 | 23 | 24 | 25 |
| 26 | 27 | 28 | 29 | 30 | 31 |
- Serialization
- C 언어 코딩 도장
- list 컬렉션
- s
- 이것이 자바다
- 메모리구조
- 이스케이프 문자
- 윤성우의 열혈 자료구조
- coding test
- Algorithm
- insertion sort
- C programming
- R
- JSON
- 알기쉬운 알고리즘
- buffer
- datastructure
- Graph
- 윤성우 열혈자료구조
- Selection Sorting
- 혼자 공부하는 C언어
- Stack
- stream
- Today
- Total
목록SW Engineering (21)
Engineering Note
이커머스 프로젝트에서 장바구니 조회 기능을 구현하면서, 여러 테이블에 분산된 데이터를 효율적으로 조회하는 방법을 고민했습니다. N+1문제를 피하고 성능을 최적화하면서도 필요한 모든 정보를 한 번에 가져오는 과정을 공유합니다. 요구사항 분석 사용자 스토리:로그인한 사용자가 장바구니 페이지에 접속하면, 담아둔 상품들의 이름, 가격, 수량, 대표 이미지를 확인할 수 있어야 한다. 기숙적 요구사항한 번의 쿼리로 모든 필요한 정보 조회 (N+1 문제 방지)상품의 대표 이미지만 표시 (상품당 여러 이미지 중 하나만 표시)장바구니가 비어있는 경우 예외 처리 데이터 모델 설계프로젝트의 핵심 Entity들과 연관관계입니다. // 장바구니 (회원당 1개)@Entity@Table(name = "cart")@Getter @..
JPA @Transactional 어노테이션의 동작방법과 JPA 영속성 컨텍스트이커머스 프로젝트 장바구니 기능을 위한 테스트 코드다. 유저가 상품을 구매하기 위해 장바구니에 상품을 담고, 처음 장바구니에 담은 상품 수량을 수정하는 기능을 테스트했다. 테스트를 하면서 JPA 영속성 컨텍스트와 @Transactional 어노테이션이 어떻게 동작하는지 확실히 이해하기 위해 다시 정리하기로 했다.package com.shop.service;import com.shop.constant.ItemSellStatus;import com.shop.dto.CartItemDto;import com.shop.entity.CartItem;import com.shop.entity.Item;import com.shop.entity..
장바구니 조회 기능을 구현하던 중 JOIN FETCH와 DTO 생성자 패턴을 함께 사용했을 때 발생하는 Hibernate 에러를 해결한 과정을 공유하고자 합니다. 이 에러는 JPA를 사용하면서 성능 최적화를 시도할 때 자주 마주치는 문제입니다.문제 상황@Query("select new com.shop.dto.CartDetailDto(ci.id, i.itemNm, i.price, ci.count, im.imgUrl) "+ "from CartItem ci " + "join fetch ci.item i " + // 문제가 된 부분 "join ItemImg im on im.item.id = i.id " + "where ci.cart.id = :cartId " ..
장바구니 조회 기능을 구현하면서 의문이 들어서, 평소에 자주 사용하던 JOIN과 FETCH JOIN의 차이를 정리해보려고 한다. 발생할 가능성이 있는 조건과 그렇지 않은 경우를 함께 살펴보자.객체-테이블 패러다임 차이와 연관관계JPA는 데이터베이스의 테이블과 매핑되는 Entity를 클래스로 활용한다. 이때 객체와 테이블의 서로 다른 패러다임으로 인해 연관관계라는 개념이 등장한다.테이블은 외래키를 통해 조회 기준이 되는 테이블이나 엔티티와 관계없이 자유롭게 서로 조회할 수 있다. 반면 객체 엔티티는 필드를 가지기 때문에 해당 필드에 정의된 Entity만 조회가 가능하다.지연로딩과 N+1 문제Entity에 정의된 다른 Entity 필드가 현재 조회 기능에서 필요할 때도 있고, 불필요할 때도 있다. 이런 이유..
메모리 문제 해결 및 자동화 구축 보고서개요환경 정보플랫폼: Google Cloud Platform 프리티어서버 스펙: vCPU 2개, RAM 1GB, 디스크 30GB애플리케이션: Spring Boot + MySQL초기 문제 상황수동 배포 과정에서 서버 메모리 부족으로 인한 빌드 실패 및 성능 저하 발생문제 분석1. 메모리 사용량 실측 데이터서버 메모리 현황 분석# 실제 측정 결과 (top 명령어 출력)mysqld: 249MB (26.0% 사용)기타 시스템 프로세스: 262MB총 사용량: 511MB가용 메모리 계산VM 총 메모리: 958MB (1GB 중 실제 사용 가능)시스템 기본 사용량: 511MB실제 가용 메모리: 447MB2. Maven 빌드 메모리 요구량 측정스왑 메모리 사용량 분석# 빌드 중 스..
동시성 문제 테스트 환경 구축기문제 정의상품 주문 로직을 개발하다 보면 여러 사용자가 동시에 주문을 하거나, 한 사용자가 네트워크 오류·중복 클릭 등으로 동일한 주문이 여러 번 요청될 수 있습니다. 이런 경우 재고가 음수로 내려가거나, 중복 주문이 발생하는 장애가 생길 수 있습니다.하지만 JUnit 테스트에서 이런 동시 요청 상황을 시뮬레이션할 도구가 마땅치 않아, 직접 간단한 테스트 도구를 구현하기로 했습니다.해결 방법JUnit 환경에서 Thread Pool을 활용해 멀티쓰레딩 동시 요청을 구현했습니다.ExecutorService executor = Executors.newFixedThreadPool(10);ExecutorService를 이용해 직접 new Thread()를 만들지 않고 쓰레드 풀 방식..
문제 정의 상품 조회 기능을 개발할 때, JPA의 쿼리메서드를 사용하여 개발하면 성능의 문제는 없을지 문제의식을 가졌고, 직접 실험해보면서 문제를 해결하였습니다.상품 조회 Pagination 기능을 개발할 때, findall JPA 쿼리 메서드를 사용한 Pagination과 Cursor 기반 Pagination에 대해 실제 실행되는 Query를 비교하고 성능 측정하여, 어떤 문제가 발생하는지 확인하고 적합한 Pagination 기능을 위한 기술을 선택하게 된 과정. 개발환경- Java(17), Spring Boot(3), MySQL(9.0), JPA/Hibernate 상황설명JPA의 Pageable 타입을 매개변수로 받는 findall를 이용한 페이지 조회에서 무한스크롤 지원 API를 위해 조회 성능 ..
case1 client 입장에서 server로 비동기 통신 보내면서 비동기 통신 익히기 case2 server to server API 통신으로 비동기 통신 익히기 case 2-1 보내는 server case 2-2 받는 serverCASE1 client 입장에서 server로 비동기 통신 보내면서 비동기 통신 익히기 먼저 동기 통신으로 서버에 요청을 보내고 브레이크 포인트를 걸면서 동기 통신 동작과정을 브라우저에서 확인해보았다. 1.먼저 요청을 받을 endpoint를 만들어 준다.package com.staging.excercise.controller;import org.springframework.web.bind.annotation.*;@RestController@RequestMapping("/..