[강의] 실전! 스프링 부트와 JPA 활용2 - API 개발과 성능 최적화 1

SPRING/INFLEARN

[강의] 실전! 스프링 부트와 JPA 활용2 - API 개발과 성능 최적화 1

ozllzL 2022. 7. 25. 18:24

https://www.inflearn.com/course/%EC%8A%A4%ED%94%84%EB%A7%81%EB%B6%80%ED%8A%B8-JPA-API%EA%B0%9C%EB%B0%9C-%EC%84%B1%EB%8A%A5%EC%B5%9C%EC%A0%81%ED%99%94/dashboard

실전! 스프링 부트와 JPA 활용2 - API 개발과 성능 최적화 - 인프런 | 강의

스프링 부트와 JPA를 활용해서 API를 개발합니다. 그리고 JPA 극한의 성능 최적화 방법을 학습할 수 있습니다., - 강의 소개 | 인프런...

www.inflearn.com

1. API 개발 기본

- 회원 등록 API

version 1

//MemberApiController.java
@RestController
@RequiredArgsConstructor
public class MemberApiController {

    private final MemberService memberService;

    @PostMapping("/api/v1/members")
    public CreateMemberResponse saveMemberV1(@RequestBody @Valid Member member){
        //Json으로 온 데이터를 member로 싹 바꿔주는 @RequestBody
        //유효성 검사 @Valid
        Long id = memberService.join(member);
        return new CreateMemberResponse(id);

    }

    @Data
    static class CreateMemberResponse {
        private Long id;

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

=> 값이 없어도 저장이 된다.

방지하고 싶다면?

Member.java의 name에 @NotEmpty를 붙여준다.

@Valid 붙인 효과로 name 이 비어있으면 걸러줌!

=> 위 방법은 문제가 많다.

presentation(화면)을 위한 검증 로직이 Entity 코드에 들어와 있음.

1. 어떤 API는 @NotEmpty가 필요하지 않을 수도 있음

2. Entity 의 name -> userName으로 바꾼 경우, Entity의 스펙이 변경됨

클라측에서는 갑자기 API가 동작하지 않음

Entity를 손대서 스펙 자체가 변경된다는 것이 문제임

-> 이를 연결하는 DTO를 만들어서 API 요청 스펙이 변경되지 않도록 해야 함

엔티티 외부 노출 안됨. 엔티티를 파라미터로 받지 마

version2

@RestController
@RequiredArgsConstructor
public class MemberApiController {

    private final MemberService memberService;

	/*생략*/

    @PostMapping("/api/v21/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
    private class CreateMemberRequest {
        private String name;
    }
}

version2의 장점

클래스를 하나 더 만들어야하는 단점이 있긴 하지만,

1. 이름을 변경하면 컴파일 에러가 나줌(setter)

2. DTO는 어떤 값을 어떻게 받는지 한 눈에 보이게 해줌, 유지보수가 매우 편리함

-> 여튼 무조건 2 써야함. DTO 안만들면 안됨

- 회원 수정 API

@RestController
@RequiredArgsConstructor
public class MemberApiController {

    /*생략*/

    //Update는 변경성이다
    //Member를 반환하면, 영속성이 끊긴 member가 반환이 된다.
    //id로 다시 조회해서 찾아오는 느낌
    //커맨드와 쿼리가 같이 있는 꼴이 됨
    //그냥 아예 조회를 다시 해서 member를 반환하거나, id만 반환하는 꼴이 나음
    //유지보수성이 증대됨
    @PutMapping("/api/v2/members/{id}")
    public UpdateMemberResponse updateMemberV2(@PathVariable("id") Long id,
                                               @RequestBody @Valid UpdateMemberRequest request){
        // 새 메소드 작성할 때는 변경감지가 좋다
        memberService.update(id, request.getName());
        Member findMember = memberService.findOne(id);
        return new UpdateMemberResponse(findMember.getId(), findMember.getName());
    }


    //TIP)) 강사님께서는 엔티티에는 Lombok 사용을 자제하는 편이시지만
    //      DTO에는 막 쓰시는 편이다다
    @Data
    static class UpdateMemberRequest {
        @NotEmpty
        private String name;
    }

    @Data
    @AllArgsConstructor
    static class UpdateMemberResponse {
        private Long id;
        private String name;
    }
}

//MemberService.java
@Service
@Transactional(readOnly = true)//읽기
@RequiredArgsConstructor
public class MemberService {

    /*생략*/
    
    //Transactional에 의해
    //Spring AOP가 끝나는 시점에 commit이 되고
    //그 때 JPA는 flush하고 영속성 컨텍스트 커밋도 다 해버림
    @Transactional
    public void update(Long id, String name) {
        Member member = memberRepository.findOne(id);
        member.setName(name);
    }

}

- 회원 조회 API

무식한 version1

@RestController
@RequiredArgsConstructor
public class MemberApiController {

    /*생략*/

    @GetMapping("/api/v1/members")
    public List<Member> membersV1(){
        return memberService.findMembers();
    }
    
    /*생략*/
}

이렇게 되면 필요 없는 주문 정보까지 같이 받아짐

이걸 해결하기 위한 방법으로 orders에 @JsonIgnore을 붙이는 방법이 있음

-> 하지만 다른 데에 필요한 경우도 있고

presentation 계층을 위한 로직이 Entity에 추가됨 (양방향 의존 관계)

또 변수 이름 바꾸면(엔티티 스펙이 변경되면) response의 변수 이름이 바뀌어서 API 스펙이 바뀜

=> 역시 그대로 Entity를 직접 반환하면 안됨, Array를 그대로 반환하는 것도 문제가 됨(다른 것과 함께 반환할 수 없음)

@RestController
@RequiredArgsConstructor
public class MemberApiController {

    /*생략*/

    @GetMapping("/api/v2/members")
    public Result membersV2(){
        List<Member> findMembers = memberService.findMembers();
        List<MemberDto> collect = findMembers.stream()
                .map(m -> new MemberDto(m.getName()))
                .collect(Collectors.toList());
        return new Result(collect);
    }

    @Data
    @AllArgsConstructor
    static class Result<T>{
        private T data;
    }

    @Data
    @AllArgsConstructor
    static class MemberDto<T>{
        private String name;
    }

    /*생략*/
}

1. 겉이 배열([])이 아닌 오브젝트 ({}) 형태임

유연성이 생긴다, 필요한 필드가 있다면 추가해서 리턴하기 편함

2. 필요한 정보만 담겨 있음

2. API 개발 고급 - 준비

- 조회용 샘플 데이터 입력

아래 코드로 데이터 입력

@Component
@RequiredArgsConstructor
public class InitDb {
    private final InitService initService;
    @PostConstruct
    public void init() {
        initService.dbInit1();
        initService.dbInit2();
    }
    @Component
    @Transactional
    @RequiredArgsConstructor
    static class InitService {
        private final EntityManager em;
        public void dbInit1() {
            Member member = createMember("userA", "서울", "1", "1111");
            em.persist(member);
            Book book1 = createBook("JPA1 BOOK", 10000, 100);
            em.persist(book1);
            Book book2 = createBook("JPA2 BOOK", 20000, 100);
            em.persist(book2);
            OrderItem orderItem1 = OrderItem.createOrderItem(book1, 10000, 1);
            OrderItem orderItem2 = OrderItem.createOrderItem(book2, 20000, 2);
            Order order = Order.createOrder(member, createDelivery(member),
                    orderItem1, orderItem2);
            em.persist(order);
        }
        public void dbInit2() {
            Member member = createMember("userB", "진주", "2", "2222");
            em.persist(member);
            Book book1 = createBook("SPRING1 BOOK", 20000, 200);
            em.persist(book1);
            Book book2 = createBook("SPRING2 BOOK", 40000, 300);
            em.persist(book2);
            Delivery delivery = createDelivery(member);
            OrderItem orderItem1 = OrderItem.createOrderItem(book1, 20000, 3);
            OrderItem orderItem2 = OrderItem.createOrderItem(book2, 40000, 4);
            Order order = Order.createOrder(member, delivery, orderItem1,
                    orderItem2);
            em.persist(order);
        }
        private Member createMember(String name, String city, String street,
                                    String zipcode) {
            Member member = new Member();
            member.setName(name);
            member.setAddress(new Address(city, street, zipcode));
            return member;
        }
        private Book createBook(String name, int price, int stockQuantity) {
            Book book = new Book();
            book.setName(name);
            book.setPrice(price);
            book.setStockQuantity(stockQuantity);
            return book;
        }
        private Delivery createDelivery(Member member) {
            Delivery delivery = new Delivery();
            delivery.setAddress(member.getAddress());
            return delivery;
        }
    }
}

3. API 개발 고급 - 지연 로딩과 조회 성능 최적화

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

/*
Order를 조회하고,
Order -> Member m : 1
Order -> Delivery 연관 1 : 1
결론 : toOne 관계에서의 성능 최적화를 어떻게 할 것인가

하지만 OrderItem은 toMany 관계임 -> 컬렉션 사용, 복잡, 다음장에서
 */
@RequiredArgsConstructor
@RestController
public class OrderSimpleController {
    private final OrderRepository orderRepository;

    @GetMapping("/api/v1/sample-orders")
    public List<Order> orderV1(){
        List<Order> all = orderRepository.findAllByString(new OrderSearch());
        return all;
    }

}

=> 문제 : 꺄아악 무한루프!

해결법 - 양방향 연관 관계가 있을 경우, 둘 중 하나는 @JsonIgnore을 붙여줘야 한다

=> 문제 : Proxy 어쩌구 에러 발생

@Entity
@Table(name = "orders")  // 테이블 이름과 class명이 다르기 때문
@Getter @Setter
@NoArgsConstructor(access = AccessLevel.PROTECTED)
public class Order {

    /*생략*/

    @ManyToOne(fetch = FetchType.LAZY)
    @JoinColumn(name = "member_id")
    private Member member;

    @OneToMany(mappedBy = "order")
    private List<OrderItem> orderItems = new ArrayList<>();

    @OneToOne(fetch = FetchType.LAZY, cascade = CascadeType.ALL)
    @JoinColumn(name = "delivery_id")
    private Delivery delivery;

    /*생략*/
}

fetch가 Lazy로 되어있기 때문에 (1:n 은 기본이 Lazy)

Order를 가지고 올 때, null로 가져올 수 없기 때문에 Proxy Member를 대신 넣어가지고 가져옴

Member 객체에 손을 댈 때, sql 쿼리를 날려 맞는 객체를 넣음

json이 member를 뽑을 때는 proxy가 있기에 오류가 나게 됨

-> 지연 로딩인 경우에는 아예 json으로 뿌리지 않도록 하는 hibernate module이 있음

(아래 링크에서 복사해서 build.gradle에 넣고 사용)

https://mvnrepository.com/artifact/com.fasterxml.jackson.datatype/jackson-datatype-hibernate5/2.9.9

@SpringBootApplication
public class JpashopApplication {

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

	@Bean
	Hibernate5Module hibernate5Module(){
		Hibernate5Module hibernate5Module = new Hibernate5Module();
		return hibernate5Module;
	}
}

=> 지연하는 애들은 전부 null로 json으로 뿌려짐

옵션을 먹여서 강제로 로딩되게 하는 방법도 있음(사실 이런거 쓰면 안됨)

옵션 안쓰고 이런거 붙여서 강제 초기화 하는 방법도 있음

for( Order order : all){

    order.getOrder().getName();

    order.getDelivery().getAddress();

}

=> 1. 계속 문제였던 엔티티 노출

2. 성능 저하, 필요 없는 API 스펙이 노출됨

주의

지연 로딩(LAZY)을 피하기 위해 즉시 로딩(EARGR)으로 설정하면 안된다!

즉시 로딩 때문에 연관관계가 필요 없는 경우에도 데이터를 항상 조회해서 성능 문제가 발생할 수 있다.

즉시 로딩으로 설정하면 성능 튜닝이 매우 어려워 진다.
-> 항상 지연 로딩을 기본으로 하고, 성능 최적화가 필요한 경우에는 페치 조인(fetch join)을 사용해라!(V3)

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

@RequiredArgsConstructor
@RestController
public class OrderSimpleController {

	/*생략*/

    @GetMapping("/api/v2/sample-orders")
    public List<SimpleOrderDto> orderV2(){
        List<Order> orders = orderRepository.findAllByString(new OrderSearch());
        return orders.stream()
                .map(o-> new SimpleOrderDto(o))
                .collect(Collectors.toList()); //static import까지 하면 코드를 더 줄일 수 있음
    }

    private 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();
            orderDate = order.getOrderDate();
            orderStatus = order.getStatus();
            address = order.getDelivery().getAddress();
        }
    }
}

## 문제

주문 조회 웹 들어갈 때마다 터짐 , 복습하면서 다시 확인

엔티티를 DTO로 변환하는 일반적인 방법

로그의 넘어간 쿼리를 확인해보자

쿼리가 1 + N + N 번 실행된다 (최악의 경우)

지연로딩은 영속성 컨텍스트에서 조회하므로, 이미 조회된 경우 쿼리를 생략하기도 하기 때문

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

@Repository
@RequiredArgsConstructor
public class OrderRepository {
	/*생략*/
    public List<Order> findAllWithMemberDelivery(){

        //fetch join은 매우 중요. 100% 이해해야 함
        return em.createQuery(
                "select o from Order o" +
                        " join fetch o.member m" +
                        " join fetch o.delivery d", Order.class
        ).getResultList();
    }
}

fetch join으로 하나의 쿼리로 모든 내용을 다 가지고 온다 -> 성능 최적화

@RequiredArgsConstructor
@RestController
public class OrderSimpleController {
    
    /*생략*/

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

        return orders.stream()
                .map(o-> new SimpleOrderDto(o))
                .collect(Collectors.toList());
    }
    
	/*생략*/
}

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

@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;
    }
}

@Repository
@RequiredArgsConstructor
public class OrderRepository {
	/*생략*/
	public List<OrderSimpleQueryDto> findOrderDtos() {
        return em.createQuery(
                        "select new jpabook.jpashop.repository.order.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();
    }
}

@RequiredArgsConstructor
@RestController
public class OrderSimpleController {
	/*생략*/
    @GetMapping("/api/v4/sample-orders")
    public List<SimpleOrderDto> orderV4(){
        List<Order> orders = orderRepository.findAllWithMemberDelivery();

        return orders.stream()
                .map(o-> new SimpleOrderDto(o))
                .collect(Collectors.toList());
    }
	/*생략*/
}

V3와 V4는 장단점이 있음

V3에 비해 V4는 원하는 것만 조회

new 명령어를 사용해서 JPQL의 결과를 DTO로 즉시 변환

하지만,

재사용성이 없음. 이 DTO를 사용할 때만 사용하게 됨

원하는 데이터만 직접 SELECT 절에서 선택하므로 네트워크 용량 최적화(요즘에는 다 빨라서 이정도는 미미)

데이터 사이즈가 너무 크다면 고려해보는 게 좋음

API 스펙에 맞춘 코드가 리포지토리에 들어가는 단점을 보완하기 위해,

Repository에서 얘 전용으로 위 코드 부분만 빼서 넣는 방법

일단 V3를 쓰고, 이래도 약하면 V4

이래도 안되면 JPA가 제공하는 네이티브 SQL이나 스프링 JDBC Template을 사용해서 SQL을 직접
사용