지금의 기록이 미래의 자산이 된다.

A Steadily Growing Developer

실전! 스프링 부트와 JPA 활용2: API 개발 고급 - 컬렉션 조회 최적화 (엔티티 조회 기준)

2023-10-21

devFancy

JPA
이 글의 코드와 정보들은 [실전! 스프링 부트와 JPA 활용 2] 강의를 들으며 정리한 내용을 토대로 작성하였습니다.

API 개발 고급

이번 글은 주문내역에서 주문한 상품 정보를 추가로 조회하자.

Order 기준으로 컬렉션인 OrderItem와 Item이 필요하다.

(참고로, 위의 엔티티 테이블에서 확인할 수 있듯이 주문과 주문상품(OrderItem)은 일대다 관계이며, 주문상품과 상품(Item)은 다대일 관계로 구성되어 있다)

이전 글인 지연 로딩과 조회 성능 최적화 부분에서는 toOne(OneToOne, ManyToOne) 관계에 대한 해결책을 정리했다.

이번에는 컬렉션인 엔티티 조회를 기준으로 일대다(OneToMany) 관계를 조회하고, 최적화하는 방법을 알아보자.

앞서, 이번 글에서는 V1(엔티티 직접 노출), V2(엔티티를 조회해서 DTO로 변환)은 이전 글에서 이미 다루었기 때문에 생략했다.

주문 조회 V3: 엔티티를 DTO로 변환 - 페치 조인 최적화

OrderApiController에 추가
```
@RestController
@RequiredArgsConstructor
public class OrderApiController {
    
    @GetMapping("/api/v3/orders")
    public List<OrderDto> ordersV3() {
        List<Order> orders =  orderRepository.findAllWithItem();

        for (Order order : orders) {
            System.out.println("order ref=" + order + " id=" + order.getId());
        }

        List<OrderDto> result = orders.stream()
                .map(o -> new OrderDto(o))
                .collect(toList());
        return result;
    }
}
```
출력결과
```
order ref=jpabook.jpashop.domain.Order@27dc3bfe id=4
order ref=jpabook.jpashop.domain.Order@27dc3bfe id=4
order ref=jpabook.jpashop.domain.Order@300b5fd6 id=11
order ref=jpabook.jpashop.domain.Order@300b5fd6 id=11
```
- DB 참조값, JPA pk id 값이 동일하게 2번 반복되어 출력되는 것을 확인할 수 있다.
- 동일하게 반복된 부분을 제거하기 위해 DB 쿼리문에서 distinct를 추가해주면 된다.
OrderRepository에 추가
```
@Repository
@RequiredArgsConstructor
public class OrderRepository {
    
    private final EntityManager em;

    public List<Order> findAllWithItem() {
        return em.createQuery(
                        "select distinct o from Order o" +
                                " join fetch o.member m" +
                                " join fetch o.delivery d" +
                                " join fetch o.orderItems oi" +
                                " join fetch oi.item i", Order.class)
                .setFirstResult(1)
                .setMaxResults(100)
                .getResultList();
    }
}
```
- 페치 조인(fetch join)으로 SQL이 1번만 실행된다.
- 현재 Order(주문)과 OrderItem(주문상품)의 관계는 일대다 관계이면서 조인이 있으므로 데이터베이스의 row가 증가한다.
- 그 결과 같은 order 엔티티의 조회 수도 증가하게 된다.
- 이런 반복된 부분을 제거하기 위해 SQL에 distinct를 추가하고, 더해서 같은 엔티티가 조회되면, 애플리케이션에서 중복을 걸러주게 된다.
- 위의 예시처럼 order가 컬렉션 페치 조인 때문에 중복 조회 되는 것을 막아준다.
- 하지만 이런 경우 단점이 존재한다.
  - 컬렉션 페치 조인을 사용하면 페이징이 불가능하다.
  - 하이버네이트는 경고 로그를 남기면서 모든 데이터를 DB에서 읽어오고, 메모리에서 페이징 해버려 매우 위험한 결과를 초래한다.
- 컬렉션 페치 조인은 1개만 사용할 수 있다. 컬렉션 둘 이상에 페치 조인을 사용하게 되면 데이터가 부정합하게 조회 될 수 있기 때문에 사용해선 안된다.
(자세한 내용은 자바 ORM 표준 JPA 프로그래밍을 참고하자)

주문 조회 V3.1: 엔티티를 DTO로 변환 - 페이징과 한계 돌파

그렇다면 페이징 + 컬렉션 엔티티를 함께 조회하려면 어떻게 해야할까?

페이징 문제 해결 방안
- 먼저 ToOne(OneToOne, ManyToOne) 관계를 모두 페치 조인한다.
- ToOne 관계는 row 수를 증가시키지 않으므로 페이징 쿼리에 영향을 주지 않는다.
- 켈력선은 지연 로딩으로 조회한다.
- 지연 로딩 성능 최적화를 위해 다음 2가지를 중 1개를 사용하면 된다.
  - [1] 글로벌 설정: application.yml 파일에 hibernate.default_batch_fetch_size 를 추가한다.
  - [2] 개별 최적화: 적용할 엔티티 클래스, 컬렉션 필드 위에 @BatchSize을 추가한다.
  - 이 옵션을 사용하면 컬렉션이나, 프록시 객체를 한꺼번에 설정한 size 만큼 IN 쿼리로 조회한다.
OrderRepository에 추가
```
@Repository
@RequiredArgsConstructor
public class OrderRepository {

    private final EntityManager em;

    // 재사용성 O
    public List<Order> findAllWithMemberDelivery() {
        return em.createQuery(
                "select o from Order o" +
                        " join fetch o.member m" +
                        " join fetch o.delivery d", Order.class
        ).getResultList();
    }
}
```
OrderApiController에 추가
```
/**
* V3.1 엔티티를 조회해서 DTO로 변환 페이징 고려
*-ToOne 관계만 우선 모두 페치 조인으로 최적화
* - 컬렉션 관계는 hibernate.default_batch_fetch_size, @BatchSize로 최적화 */
@RestController
@RequiredArgsConstructor
public class OrderApiController {

    private final OrderRepository orderRepository;

    @GetMapping("/api/v3.1/orders")
    public List<OrderDto> ordersV3_page(@RequestParam(value = "offset",
            defaultValue = "0") int offset,
                                        @RequestParam(value = "limit", defaultValue
                                                = "100") int limit) {
        List<Order> orders = orderRepository.findAllWithMemberDelivery(offset,
                limit);
        List<OrderDto> result = orders.stream()
                .map(o -> new OrderDto(o))
                .collect(toList());
        return result;
    }
}
```
최적화 옵션 - 글로벌
```
 spring: jpa:
        properties:
          hibernate:
            default_batch_fetch_size: 1000
```
- 만약, 글로벌 설정이 아닌 개별로 설정하려면 @BatchSize를 적용하면 된다.
- 이렇게 최적화 옵션을 적용하면 다음과 같은 장점이 존재한다.
  - 쿼리 호출 수가 1 + N -> 1 + 1로 최적화 된다. (N+1 문제 해결)
  - 조인보다 DB 데이터 전송량이 최적화 된다. (Order와 OrderItem을 조인하면 Order가 OrderItem 만큼 중복해서 조회된다. 이 방법은 각각 조회하므로 전송해야할 중복 데이터가 없다)
  - 페치 조인 방식과 비교해서 쿼리 호출 수가 약간 증가하지만, DB 데이터 전송량이 감소한다.
  - 컬렉션 페치 조인은 페이징이 불가능하지만, 이 방법은 페이징이 가능하다.
- 결론
  - ToOne 관계는 페치 조인해도 페이징에 영향을 주지 않는다.
  - 따라서 ToOne 관계는 페치 조인으로 쿼리 수를 줄이고, 나머지는 hibernate.default_batch_fetch_size로 최적화하자.
- 참고로, default_batch_fetch_size의 크기는 100 ~ 1000 사이 선택하는 것을 권장한다. DB에 따라 IN 절 파라미터를 1000으로 제한하기도 한다.
  - 예시) 1000으로 잡으면 한번에 1000개를 DB에서 애플리케이션에 불러오므로 DB에 순간 부하가 증가할 수 있다.
  - 하지만 애플리케이션은 100이든 1000이든 결국 전체 데이터를 로딩해야 하므로 메모리 사용량이 같다.
  - 즉, DB든 애플리케이션이든 순간 부하를 어디까지 견딜 수 있는지로 결정하면 된다.
Review

컬렉션이 포함된 조회인 경우 어떻게 해야 최적화 되는지 알게 되는 강의였다.

다대일, 일대일 관계처럼 ToOne 관계는 페치 조인으로 하고 일대다 관계인 ToMany인 경우 개별적으로 @BatchSize 하거나 또는 글로벌 설정으로 hibernate.default_batch_fetch_size을 적용하자.

이번 시간에는 엔티티 조회를 기준으로 컬렉션에 대한 조회를 최적화하는 방법을 정리했다.

다음 시간에는 DTO 직접 조회를 기준으로 컬렉션에 대한 조회를 최적화 하는 방법을 정리해보자.

Reference
- 실전! 스프링 부트와 JPA 활용2 - API 개발과 성능 최적화 - API 개발 고급
Read All

실전! 스프링 부트와 JPA 활용2: API 개발 고급 - 지연 로딩과 조회 성능 최적화

2023-10-19

devFancy

JPA

API 개발 고급
간단한 주문 조회 V1: 엔티티를 직접 노출
간단한 주문 조회 V2: 엔티티를 DTO로 변환
간단한 주문 조회 V3: 엔티티를 DTO로 변환 - 페치 조인 최적화
간단한 주문 조회 V4: JPA에서 DTO로 바로 조회
Review
Reference

이 글의 코드와 정보들은 [실전! 스프링 부트와 JPA 활용 2] 강의를 들으며 정리한 내용을 토대로 작성하였습니다.

API 개발 고급

주문 + 배송정보 + 회원을 조회하는 API를 만들면서 지연 로딩 때문에 발생하는 성능 문제를 단계적으로 해결하는 과정을 정리했다.

간단한 주문 조회 V1: 엔티티를 직접 노출

OrderSimpleApiController

package jpabook.jpashop.api;
/**
 * xToOne(ManyToOne, OneToOne) - 성능 최적화
 * Order
 * Order -> Member
 * Order -> Delivery
 */
@RestController
@RequiredArgsConstructor
public class OrderSimpleApiController {

    private final OrderRepository orderRepository;

    /**
     * V1. 엔티티 직접 노출
     * - Hibernate5Module 모듈 등록, LAZY=null 처리 * - 양방향 관계 문제 발생 -> @JsonIgnore
     */
    
    @GetMapping("/api/v1/simple-orders")
    public List<Order> ordersV1() {
        List<Order> all = orderRepository.findAllByString(new OrderSearch());
        for (Order order : all) {
            order.getMember().getName();
            order.getDelivery().getAddress();
        }
        return all;
    }
}

엔티티를 직접 노출하는 것은 좋지 않다. (이러한 이유에 대해서는 이전글에서 이미 설명했음)
order -> member, order -> delivery는 지연 로딩으로 실제 엔티티 대신에 프록시가 존재하게 된다.
- (참고로, Order - Member 엔티티는 다대일 관계, Order와 Delivery는 일대일 관계)
jackson 라이브러리는 기본적이로 이 프록시 객체를 json으로 어떻게 생성하는지 모르기 때문에 예외가 발생한다.
- 예외 내용: No serializer found for class org.hibernate.proxy.pojo.bytebuddy.ByteBuddyInterceptor and no properties discovered to create BeanSerializer (to avoid exception, disable SerializationFeature.FAIL_ON_EMPTY_BEANS) (through reference chain: java.util.ArrayList[0]->jpabook.jpashop.domain.Order["member"]->jpabook.jpashop.domain.Member$HibernateProxy$5vbd87AL["hibernateLazyInitializer"])
따라서 Hibernate5Module을 스프링 빈으로 등록하면 해결된다.
- 스프링 부트 3.0 미만인 경우 build.gradle 에서 다음 라이브러리를 추가한다.
- implementation 'com.fasterxml.jackson.datatype:jackson-datatype-hibernate5'
그런 다음, JpashopApplication 에 다음 코드를 추가해준다.

@SpringBootApplication
public class JpashopApplication {

	public static void main(String[] args) {
		SpringApplication.run(JpashopApplication.class, args);
	}

	@Bean
	Hibernate5Module hibernate5Module() {
		Hibernate5Module hibernate5Module = new Hibernate5Module();
		//강제 지연 로딩 설정 (사실 아래에 있는 건 쓰면 안됨)
		hibernate5Module.configure(Hibernate5Module.Feature.FORCE_LAZY_LOADING,true);
		return hibernate5Module;
	}
}

이 옵션을 키면, 양방향 연관관계(order -> member, member -> orders)로 계속 로딩하게 된다. 따라서 @JsonIgnore 옵션을 두개의 엔티티중 한곳에 주어야 한다.

정리: 해당 방법은 강제로 지연 로딩을 설정해서 에러를 해결했으나, 이전에 말했듯이 엔티티를 API 응답으로 외부로 노출하는 것은 좋지 않다. 따라서 Hibernate5Module를 사용하기 보다는 DTO로 변환해서 하는 것이 좋은 방법이다.

간단한 주문 조회 V2: 엔티티를 DTO로 변환

OrderSimpleApiController - 추가

package jpabook.jpashop.api;

@RestController
@RequiredArgsConstructor
public class OrderSimpleApiController {

    private final OrderRepository orderRepository;

    @GetMapping("/api/v2/simple-orders")
    public List<SimpleOrderDto> ordersV2() {
        // ORDER 2개
        // N + 1 -> 1 + N(2): 첫번째 쿼리의 결과로 n번만큼 query가 추가 실행되는 게 N + 1이라는 의미임.
        // N + 1 -> 1 + 회원 N + 배송 N
        List<Order> orders = orderRepository.findAllByString(new OrderSearch());

        List<SimpleOrderDto> result = orders
                .stream()
                .map(o -> new SimpleOrderDto(o))
                .collect(Collectors.toList());

        return result;
    }

    @Data
    static class SimpleOrderDto {
        private Long orderId;
        private String name;
        private LocalDateTime orderDate;
        private OrderStatus orderStatus;
        private Address address;

        public SimpleOrderDto(Order order) {
            orderId = order.getId();
            name = order.getMember().getName(); // LAZY 초기화
            orderDate = order.getOrderDate();
            orderStatus = order.getStatus();
            address = order.getDelivery().getAddress();  // LAZY 초기화
        }
    }
}

V1과 다르게 V2에서는 엔티티를 DTO로 변환한 일반적인 방법이다.
하지만 V2에서는 실제 쿼리를 실행했을 때 N+1 문제가 생긴다.
- 현재 로직상 order와 연관된 member와 delivery에서 지연 로딩으로 인해 조회가 N번 실행된다.
- 그래서 쿼리가 총 1 + N + N번 실행된다. (이는 V1에서의 쿼리 수 결과와 같다)
- 자세하게 설명하면, order 조회에서 1번, order -> member 지연 로딩 조회에서 N번, order -> delivery 지연 로딩 조회에서 N번이 실행된다.
- 만약 같은 회원이였으면 N번이 아닌 1번인데, 서로 다른 회원이므로 N번이 된 것이다.
- 지연로딩은 영속성 컨텍스트에서 조회하므로, 이미 조회된 경우 쿼리를 생략한다.
따라서 이러한 N+1 문제를 해결하기 위해 페치 조인(fetch join)을 통해 성능을 최적화하는 방법을 사용한다.

간단한 주문 조회 V3: 엔티티를 DTO로 변환 - 페치 조인 최적화

OrderSimpleApiController - 추가

package jpabook.jpashop.api;

@RestController
@RequiredArgsConstructor
public class OrderSimpleApiController {

    private final OrderRepository orderRepository;

    @GetMapping("/api/v3/simple-orders")
    public List<SimpleOrderDto> ordersV3() {
        List<Order> orders = orderRepository.findAllWithMemberDelivery();

        List<SimpleOrderDto> result = orders.stream()
                .map(o -> new SimpleOrderDto(o))
                .collect(Collectors.toList());
        return result;
    }
}

OrderRepository - 추가 코드

@Repository
@RequiredArgsConstructor
public class OrderRepository {

    private final EntityManager em;

    // 재사용성 O
    public List<Order> findAllWithMemberDelivery() {
        return em.createQuery(
                "select o from Order o" +
                        " join fetch o.member m" +
                        " join fetch o.delivery d", Order.class
        ).getResultList();
    }
}

엔티티를 페치 조인(fetch join)을 사용해서 5번이였던 쿼리를 1번만 조회할 수 있는 효과를 볼 수 있다.
페치 조인으로 인해 order -> member, order -> delivery는 이미 조회된 상태이므로 지연로딩이 되지 않는다.
실제 쿼리를 돌려보면 아래와 같이 조회 결과가 나오게 된다.

select
        order0_.order_id as order_id1_6_0_,
        member1_.member_id as member_i1_4_1_,
        delivery2_.delivery_id as delivery1_2_2_,
        order0_.delivery_id as delivery4_6_0_,
        order0_.member_id as member_i5_6_0_,
        order0_.order_date as order_da2_6_0_,
        order0_.status as status3_6_0_,
        member1_.city as city2_4_1_,
        member1_.street as street3_4_1_,
        member1_.zipcode as zipcode4_4_1_,
        member1_.name as name5_4_1_,
        delivery2_.city as city2_2_2_,
        delivery2_.street as street3_2_2_,
        delivery2_.zipcode as zipcode4_2_2_,
        delivery2_.status as status5_2_2_ 
    from
        orders order0_ 
    inner join
        member member1_ 
            on order0_.member_id=member1_.member_id 
    inner join
        delivery delivery2_ 
            on order0_.delivery_id=delivery2_.delivery_id
2023-10-19 14:56:18.992  INFO 48324 --- [nio-8080-exec-5] p6spy                                    : #1697694978992 | took 0ms | statement | connection 9| url jdbc:h2:tcp://localhost/~/jpashop
select order0_.order_id as order_id1_6_0_, member1_.member_id as member_i1_4_1_, delivery2_.delivery_id as delivery1_2_2_, order0_.delivery_id as delivery4_6_0_, order0_.member_id as member_i5_6_0_, order0_.order_date as order_da2_6_0_, order0_.status as status3_6_0_, member1_.city as city2_4_1_, member1_.street as street3_4_1_, member1_.zipcode as zipcode4_4_1_, member1_.name as name5_4_1_, delivery2_.city as city2_2_2_, delivery2_.street as street3_2_2_, delivery2_.zipcode as zipcode4_2_2_, delivery2_.status as status5_2_2_ from orders order0_ inner join member member1_ on order0_.member_id=member1_.member_id inner join delivery delivery2_ on order0_.delivery_id=delivery2_.delivery_id
select order0_.order_id as order_id1_6_0_, member1_.member_id as member_i1_4_1_, delivery2_.delivery_id as delivery1_2_2_, order0_.delivery_id as delivery4_6_0_, order0_.member_id as member_i5_6_0_, order0_.order_date as order_da2_6_0_, order0_.status as status3_6_0_, member1_.city as city2_4_1_, member1_.street as street3_4_1_, member1_.zipcode as zipcode4_4_1_, member1_.name as name5_4_1_, delivery2_.city as city2_2_2_, delivery2_.street as street3_2_2_, delivery2_.zipcode as zipcode4_2_2_, delivery2_.status as status5_2_2_ from orders order0_ inner join member member1_ on order0_.member_id=member1_.member_id inner join delivery delivery2_ on order0_.delivery_id=delivery2_.delivery_id;

간단한 주문 조회 V4: JPA에서 DTO로 바로 조회

OrderSimpleApiController - 추가

@RestController
@RequiredArgsConstructor
public class OrderSimpleApiController {

    private final OrderRepository orderRepository;
    private final OrderSimpleQueryRepository orderSimpleQueryRepository; // 의존관계 주입(V4)

    @GetMapping("/api/v4/simple-orders")
    public List<OrderSimpleQueryDto> ordersV4() {
        return orderSimpleQueryRepository.findOrderDto();
    }
}

OrderSimpleQueryRepository 조회 전용 리포지토리

package jpabook.jpashop.repository.order.simplequery;

/**
 * 성능 최적화 관련 레포지토리 경우
 * 따로 패키지를 만들어서 그 안에 관련 클래스를 만든다.
 */
@Repository
@RequiredArgsConstructor
public class OrderSimpleQueryRepository {

    private final EntityManager em;

    // 재사용 X, 유지보수성 O
    // 이런 식으로 성능 최적화에 대한 것은 따로 패키지를 분리하는 것을 권장함
    public List<OrderSimpleQueryDto> findOrderDto() {
        return em.createQuery(
                        "select new jpabook.jpashop.repository.order.simplequery.OrderSimpleQueryDto(o.id, m.name, o.orderDate, o.status, d.address)" +
                                " from Order o" +
                                " join o.member m" +
                                " join o.delivery d", OrderSimpleQueryDto.class)
                .getResultList();
    }
}

OrderSimpleQueryDto 리포지토리에서 DTO 직접 조회

package jpabook.jpashop.repository.order.simplequery;

@Data
public class OrderSimpleQueryDto {
    private Long orderId;
    private String name;
    private LocalDateTime orderDate;
    private OrderStatus orderStatus;
    private Address address;

    public OrderSimpleQueryDto(Long orderId, String name, LocalDateTime orderDate, OrderStatus orderStatus, Address address) {
        this. orderId = orderId;
        this.name = name;
        this.orderDate = orderDate;
        this.orderStatus = orderStatus;
        this.address = address;
    }
}

일반적인 SQL을 사용할 때 처럼 원하는 값을 선택해서 조회하는 방법이다.
new 명령어를 사용해서 JPQL의 결과를 DTO로 즉시 반환한다.
SELECT 절에서 원하는 데이터를 직접 선택하므로 DB 면에서 에플리케이션 네트워트 용량을 최적화할 수 있지만 생각보다 미비하다.
실제 쿼리를 돌려보면 아래와 같이 조회 결과가 나오게 된다.

select
        order0_.order_id as col_0_0_,
        member1_.name as col_1_0_,
        order0_.order_date as col_2_0_,
        order0_.status as col_3_0_,
        delivery2_.city as col_4_0_,
        delivery2_.street as col_4_1_,
        delivery2_.zipcode as col_4_2_ 
    from
        orders order0_ 
    inner join
        member member1_ 
            on order0_.member_id=member1_.member_id 
    inner join
        delivery delivery2_ 
            on order0_.delivery_id=delivery2_.delivery_id
2023-10-19 15:28:50.970  INFO 48765 --- [nio-8080-exec-3] p6spy                                    : #1697696930970 | took 0ms | statement | connection 7| url jdbc:h2:tcp://localhost/~/jpashop
select order0_.order_id as col_0_0_, member1_.name as col_1_0_, order0_.order_date as col_2_0_, order0_.status as col_3_0_, delivery2_.city as col_4_0_, delivery2_.street as col_4_1_, delivery2_.zipcode as col_4_2_ from orders order0_ inner join member member1_ on order0_.member_id=member1_.member_id inner join delivery delivery2_ on order0_.delivery_id=delivery2_.delivery_id
select order0_.order_id as col_0_0_, member1_.name as col_1_0_, order0_.order_date as col_2_0_, order0_.status as col_3_0_, delivery2_.city as col_4_0_, delivery2_.street as col_4_1_, delivery2_.zipcode as col_4_2_ from orders order0_ inner join member member1_ on order0_.member_id=member1_.member_id inner join delivery delivery2_ on order0_.delivery_id=delivery2_.delivery_id;

사실 V3와 V4간의 성능 차이가 크게 나진 않는다.
- V4의 경우, DTO에 직접 조회하기 때문에 리포지토리 재사용성이 떨어지고, API 스펙에 맞춘 코드가 리포지토리에 들어가는 단점이 존재한다.
- 반면에 V3의 경우, 엔티티로 조회해서 리포지토리 재사용성이 좋고 개발도 단순하다.
엔티티를 DTO로 변환하거나(V3), DTO로 바로 조회하는(V4) 두 가지 방법이 각각 장단점이 존재하기 때문에, 아래와 같은 쿼리 방식을 선택할 때 권장하는 순서를 정리했다.

쿼리 방식 선택 권장 순서

우선 엔티티 -> DTO로 변환하여 API 기능 개발한다. => 필수, V2
필요하면 페치 조인(fetch join)으로 성능을 최적화한다. (대부분의 성능 이슈가 90% 해결된다) => V3
그래도 안되면 DTO로 직접 조회하는 방법을 사용한다 => V4
최후의 방법은 JPA가 제공하는 네이티브 SQL이나 스프링 JDBC Template을 사용해서 SQL을 직접 사용한다.

(4번의 경우, 이 강의에서는 다루지 않아서 추후 실제 개발하면서 문제가 생기는 경우, 그때 가서 다시 정리할 예정이다)

Review

조회하는 부분에서 쿼리를 실행했을 때 N+1 문제가 발생하는 점과 그러한 문제를 페치 조인(fetch join)으로 해결하는 방법도 알게되었다.

현재 혹은 미래에 내가 진행하는 프로젝트에서 위와 비슷한 문제가 생겼을 때, 페치 조인(fetch join)으로 성능을 최적화하는 걸 적용해보도록 하자.

(해당 강의에서는 예시로 만든 자료이고, 예시에 있는 데이터가 적기도 해서 최적화하는 방법이 간단했지만, 실제 업무에서는 최적화를 적용하기가 어려울 것이라 생각한다)

Reference

실전! 스프링 부트와 JPA 활용2 - API 개발과 성능 최적화 - API 개발 고급

Read All

실전! 스프링 부트와 JPA 활용2 - API 개발 기본

2023-10-18

devFancy

JPA

API 개발 기본
- 안 좋은 예시
- 좋은 예시

이 글의 코드와 정보들은 [실전! 스프링 부트와 JPA 활용 2] 강의를 들으며 정리한 내용을 토대로 작성하였습니다.

API 개발 기본

실무에서는 하나의 도메인에 대한 엔티티를 만들고(ex. 회원), 해당 엔티티를 위한 API가 다양하게 만들어지는데, 한 엔티티에 각각의 API를 위한 모든 요구사항을 담기 어렵다.
그리고 엔티티가 변경되면 API 스펙이 변한다.
결론: 그렇기 때문에 API 기능 요구사항에 맞춰서 엔티티가 아닌 별도의 DTO를 생성하여 파라미터로 받아야 한다.

안 좋은 예시

참고로, 원래라면 DTO도 클래스로 생성해야 하지만, 여기서는 이해를 우선시하기 때문에 Controller 클래스안에 DTO에 대한 코드도 담겨있다는 걸 참고하길 바란다.

V1의 경우, 엔티티를 생성해서 회원에 대한 등록 API를 기능 구현한 예시다.

package jpabook.jpashop.api;

import jpabook.jpashop.domain.Member;
import jpabook.jpashop.service.MemberService;
import lombok.AllArgsConstructor;
import lombok.Data;
import lombok.RequiredArgsConstructor;
import org.springframework.web.bind.annotation.*;

import javax.validation.Valid;
import javax.validation.constraints.NotEmpty;
import java.util.List;
import java.util.stream.Collectors;

@RestController
@RequiredArgsConstructor
    public class MemberApiController {

    private final MemberService memberService;
    
    // 실제 애플리케이션에서는 엔티티를 직접 반환해서는 안된다.
    @PostMapping("/api/v1/members")
    public CreateMemberResponse saveMemberV1(@RequestBody @Valid Member member) {
        Long id = memberService.join(member);
        return new CreateMemberResponse(id);
    }

    @Data
    static class CreateMemberRequest {
        @NotEmpty
        private String name;

    }

    @Data
    static class CreateMemberResponse {
        private Long id;

        public CreateMemberResponse(Long id) {
            this.id = id;
        }
    }
}

이런 경우, 위에서 말했던 것 처럼 나중에 엔티티가 변경되면 API 스펙도 같이 변해야 한다.

그래서 해결책으로 엔티티를 대체하는 DTO를 생성하여 API 기능을 구현하면 된다.

좋은 예시

package jpabook.jpashop.api;

import jpabook.jpashop.domain.Member;
import jpabook.jpashop.service.MemberService;
import lombok.AllArgsConstructor;
import lombok.Data;
import lombok.RequiredArgsConstructor;
import org.springframework.web.bind.annotation.*;

import javax.validation.Valid;
import javax.validation.constraints.NotEmpty;
import java.util.List;
import java.util.stream.Collectors;

@RestController
@RequiredArgsConstructor
    public class MemberApiController {

    private final MemberService memberService;
    
    // 엔티티 노출하거나 받지 말고 api 스펙에 맞는 DTO를 만들고, 그걸 활용해야 한다.
    @PostMapping("/api/v2/members")
    public CreateMemberResponse saveMemberV2(@RequestBody @Valid CreateMemberRequest request) {
        Member member = new Member();
        member.setName(request.getName());

        Long id = memberService.join(member);
        return new CreateMemberResponse(id);
    }
    
    @Data
    static class CreateMemberRequest {
        @NotEmpty
        private String name;

    }

    @Data
    static class CreateMemberResponse {
        private Long id;

        public CreateMemberResponse(Long id) {
            this.id = id;
        }
    }
}

이를 통해 다음과 같은 장점을 가질 수 있다.
- 이를 통해 엔티티와 프리젠테이션(Controller 클래스와 같은) 계층을 위한 로직을 분리할 수 있다.
- 엔티티와 API 스펙을 명확하게 분리할 수 있다.
- 엔티티가 변해도 API 스펙이 변하지 않는다.

참고: 엔티티를 외부에 노출해선 안된다.

실무에서는 기능에 따라 필요한 API가 증가하게 된다. API 마다 필요한 데이터가 다르기 때문에 API 스펙에 맞는 별도의 DTO를 노출해야 한다.

Read All

[Goodfriends] 시스템 장애를 미리 예방하기 위해 Amazon CloudWatch를 활용

2023-10-13

devFancy

Side_Project
- 도입 배경
- EC2 서버에 Amazon CloudWatch 적용하는 과정
굿프렌즈 기술 블로그 방문하기 🎋

이 글은 우리FISA 1기 굿프렌즈팀의 기술 블로그에 게시된 글 입니다.

Amazon CloudWatch가 무엇이고 왜 도입해야 하는지 알고 넘어가려고 합니다.

도입 배경

모니터링 없이 시스템을 운영하게 된다면 마치 계기판을 보지 않고 자동차를 운전하는 것과 같다는 이야기가 있습니다. 시스템 장애는 곧바로 서비스 중지로 이어질 수 있기 때문에 시스템 모니터링은 그만큼 중요합니다. 따라서 시스템 관리자는 지속적으로 시스템의 상태를 모니터링하고 분석하여 미래에 발생할 수 있는 예기치 않는 장애에 대비해야 합니다.

시스템 관리자는 시스템의 다음 요소들을 모니터링할 필요가 있습니다.
- CPU 사용률
- 메모리 사용률
- 디스크 사용률
- 네트워크 부하
Amazon CloudWatch은 AWS 리소스와 온프레미스 서버에서 CPU 사용률, 디스크 I/O, 네트워크 부화 등과 같은 기본 지표를 수집하여 모니터링 서비스를 제공하고 있습니다.

현재 굿프렌즈의 백엔드, 프론트 EC2 인스턴스 유형은 t2.micro입니다. 1GB 메모리, 8GB 디스크 사용량으로 아주 작은 사이즈입니다.

간혹 서비스를 운영하다보면 특히 비즈니스 로직이 많이 들어있는 백엔드 EC2 서버 디스크 용량이 50% 이상 넘길 수도 있습니다.

그래서 인스턴스의 디스크 사용량이 전부 차기전에 미리 알아야 하기 때문에, EC2 인스턴스의 사용중인 용량이 4GB 넘어가면 (50% 이상) Amazaon Cloudwatch를 통해 모니터링을 하고 알림을 받을 수 있도록 설정을 하려고 합니다.

아래 글은 백엔드 기준, EC2 인스턴스의 디스크 사용량을 체크하기 위해서 CloudWatch 적용하는 방법을 소개해드리고자 합니다.

EC2 서버에 Amazon CloudWatch 적용하는 과정

굿프렌즈 백엔드 EC2 애플리케이션 및 OS 이미지는 아래와 같습니다.
Read All
[Programmers] 17686. [3차] 파일명 정렬

2023-10-10

devFancy

Algorithm
문제 링크

성능 요약
- 메모리: 77 MB, 시간: 18.81 ms
구분
- 코딩테스트 연습 > 문자열, 구현
Answer Code1(23.10.10)

```java import java.util.Arrays; import java.util.Comparator;

class Solution {
```
public static String[] solution(String[] files) {
```
Read All

17/57

지금의 기록이 미래의 자산이 된다.

실전! 스프링 부트와 JPA 활용2: API 개발 고급 - 컬렉션 조회 최적화 (엔티티 조회 기준)

API 개발 고급

주문 조회 V3: 엔티티를 DTO로 변환 - 페치 조인 최적화

OrderApiController에 추가

OrderRepository에 추가

주문 조회 V3.1: 엔티티를 DTO로 변환 - 페이징과 한계 돌파

페이징 문제 해결 방안

OrderRepository에 추가

OrderApiController에 추가

최적화 옵션 - 글로벌

Review

Reference

실전! 스프링 부트와 JPA 활용2: API 개발 고급 - 지연 로딩과 조회 성능 최적화

API 개발 고급

간단한 주문 조회 V1: 엔티티를 직접 노출

간단한 주문 조회 V2: 엔티티를 DTO로 변환

간단한 주문 조회 V3: 엔티티를 DTO로 변환 - 페치 조인 최적화

간단한 주문 조회 V4: JPA에서 DTO로 바로 조회

Review

Reference

실전! 스프링 부트와 JPA 활용2 - API 개발 기본

API 개발 기본

안 좋은 예시

좋은 예시

[Goodfriends] 시스템 장애를 미리 예방하기 위해 Amazon CloudWatch를 활용

도입 배경

EC2 서버에 Amazon CloudWatch 적용하는 과정

[Programmers] 17686. [3차] 파일명 정렬

성능 요약

구분

Answer Code1(23.10.10)