728x90
반응형
SMALL

Java 8 이후 가장 관심을 많이 받은 건 아마도 Stream API가 아닐까 싶을 정도로 굉장히 이제는 중요하고 모르면 절대 안되는 이 녀석에 대해 공부해보자.

 

Stream

  • 데이터를 담고 있는 저장소(컬렉션)가 아니다.
  • 스트림이 처리하는 데이터 소스를 변경하는 게 아니다.
  • 스트림으로 처리하는 데이터는 오직 한번만 가능하다.
  • 중개 오퍼레이션은 근본적으로 Lazy하다.
  • 손쉽게 병렬 처리를 할 수 있다.

이게 다 무슨말일까? 하나씩 차근 차근 알아가보자. 

 

데이터를 담고 있는 저장소가 아니다.

이건 말 그대로 스트림으로 처리하는 데이터는 컬렉션이 아니라는 말이다.

import java.util.ArrayList;
import java.util.List;
import java.util.stream.Stream;

public class Main {
    public static void main(String[] args) {
        List<String> friends = new ArrayList<>();
        friends.add("John");
        friends.add("Jane");
        friends.add("Bob");
        friends.add("Mary");

        Stream<String> stream = friends.stream();
    }
}
  • 위 코드를 보면, `friends`라는 Listfriends.stream()의 반환값은 명확히 Stream으로 다르다. 
  • 쉽게 말해 스트림은 저장소 역할을 하는게 아니라, 특정 자료구조에 대해 어떤 처리를 할 수 있는 일회성 공간이라고 생각해야 한다.

 

스트림이 처리하는 데이터 소스를 변경하는 게 아니다.

import java.util.ArrayList;
import java.util.List;
import java.util.stream.Stream;

public class Main {
    public static void main(String[] args) {
        List<String> friends = new ArrayList<>();
        friends.add("John");
        friends.add("Jane");
        friends.add("Bob");
        friends.add("Mary");

        List<String> upper = friends.stream()
                .map(String::toUpperCase)
                .toList();

        System.out.println(friends);
        System.out.println(upper);
    }
}
  • 위 코드를 보면, `friends`를 스트림으로 각 요소별로 대문자로 변경하여 새로운 리스트를 만들어냈다.
  • 그럼 이건 기존의 `friends`도 변경하는 걸까? 아니다! 기존의 데이터 소스를 변경하는 게 아니다.
  • 다음 실행 결과를 보면, 기존의 데이터 소스는 그대로이고 스트림으로 처리한 데이터를 새로운 리스트를 반환하는 것이다.

실행 결과

 

스트림으로 처리한 데이터는 오직 한번만 가능하다.

import java.util.ArrayList;
import java.util.List;
import java.util.stream.Stream;

public class Main {
    public static void main(String[] args) {
        List<String> friends = new ArrayList<>();
        friends.add("John");
        friends.add("Jane");
        friends.add("Bob");
        friends.add("Mary");

        Stream<String> friendsStream = friends.stream();

        List<String> upperFriends = friendsStream.map(String::toUpperCase).toList();
        System.out.println(upperFriends);

        List<String> lowerFriends = friendsStream.map(String::toLowerCase).toList();
        System.out.println(lowerFriends);
    }
}
  • 위 코드를 보면, `friends`라는 리스트를 스트림으로 변환한 `friendsStream`이 있다. 
  • 이 녀석으로 각 요소에 대해 toUpperCase()를 처리한 새로운 리스트를 만들었다.
  • 그 이후에 다시 이 `friendsStream`을 이용할 수 있을까? 그렇지 않다. 위 코드처럼 다시 `friendsStream`을 통해 각 요소에 대해 toLowerCase()를 처리한 새로운 리스트를 만드려고 한다면 다음과 같은 에러를 마주하게 된다.

 

 

중개 오퍼레이션은 근본적으로 Lazy하다.

이게 조금 중요한 말인데, 보통은 스트림을 사용할 때 다음과 같이 사용하는 사례를 많이 마주할 것이다.

customFieldManager.getCustomFieldObjects().stream()
        .filter(customField -> customField.getCustomFieldType().getName().equals("Date Picker"))
        .map(SimpleCustomFieldDTO::new)
        .collect(Collectors.toList());
  • 위 코드는 예시 코드이다. 
  • 스트림으로 변환한 후, filter()를 거치고, map()을 거쳐서, 리스트로 최종적으로 반환한다.
  • 이렇듯, 스트림은 중개 오퍼레이션과 종료 오퍼레이션이 나뉘어져 있다.
  • 여기서 중개 오퍼레이션은 filter(), map()이고, 종료 오퍼레이션은 collect()이다.
  • 쉽게 생각하면, 중개 오퍼레이션은 반환값이 그대로 Stream이다. 반대로 종료 오퍼레이션은 반환값을 Stream으로 주지 않는다.
import java.util.ArrayList;
import java.util.List;
import java.util.stream.Stream;

public class Main {
    public static void main(String[] args) {
        List<String> friends = new ArrayList<>();
        friends.add("John");
        friends.add("Jane");
        friends.add("Bob");
        friends.add("Mary");

        Stream<String> stringStream = friends.stream().filter(friend -> friend.equals("John"));
        Stream<String> stringStream1 = friends.stream().map(String::toUpperCase);
    }
}
  • 보면 filter(), map() 까지만 실행한 반환값은 모두 Stream이다. 즉, 이 두개는 중개 오퍼레이션이라는 말이다.
import java.util.ArrayList;
import java.util.List;
import java.util.stream.Stream;

public class Main {
    public static void main(String[] args) {
        List<String> friends = new ArrayList<>();
        friends.add("John");
        friends.add("Jane");
        friends.add("Bob");
        friends.add("Mary");

        List<String> friendsList = friends.stream()
                .filter(friend -> friend.equals("John"))
                .toList();
    }
}
  • 반면, toList()를 호출한 반환값은 Stream이 아니라 List이다. 즉, toList()는 종료 오퍼레이션이라는 말이다.
  • 참고로, forEach()도 종료 오퍼레이션이다. 얘는 반환값이 없기 때문에 헷갈릴 수 있어서 이렇게 꼭 집어서 말해봤다.

 

이제 중개 오퍼레이션과 종료 오퍼레이션의 차이를 알았다. 그럼 여기서 이제 "중개 오퍼레이션은 근본적으로 Lazy하다"라는 말은 무엇이냐면, 중개 오퍼레이션은 종료 오퍼레이션을 만나기 전까지 실제적으로 실행되지가 않는다! 다음 코드를 보자!

import java.util.ArrayList;
import java.util.List;

public class Main {
    public static void main(String[] args) {
        List<String> friends = new ArrayList<>();
        friends.add("John");
        friends.add("Jane");
        friends.add("Bob");
        friends.add("Mary");

        friends.stream()
                .filter(friend -> {
                    System.out.println("friend: " + friend);
                    return friend.equals("John");
                });
    }
}
  • 자, filter()는 중개 오퍼레이션이다. 이 filter() 이후로 종료 오퍼레이션은 없다. 즉, 여전히 이 녀석은 타입이 Stream인 상태이다. 그런데 내가 filter() 안에 각 요소들을 찍어보고 싶어서 `System.out.println("friend: " + friend)`를 작성한다고 이게 출력될까? 

실행 결과

위 실행 결과처럼 아무것도 출력하지 않는다. 디버깅해서 브레이크 포인트 걸어봐도 안 걸린다! 그래서! 정말 중요한 내용이다! 중개 오퍼레이션은 근본적으로 Lazy하다는 말은, 종료 오퍼레이션을 만나기 전까지 중개 오퍼레이션의 작업은 진행되지가 않는다는 말이다! 그럼 내가 저 코드에 종료 오퍼레이션을 넣고 실행하면 결과는 어떻게 될까?

import java.util.ArrayList;
import java.util.List;

public class Main {
    public static void main(String[] args) {
        List<String> friends = new ArrayList<>();
        friends.add("John");
        friends.add("Jane");
        friends.add("Bob");
        friends.add("Mary");

        friends.stream()
                .filter(friend -> {
                    System.out.println("friend: " + friend);
                    return friend.equals("John");
                }).toList();
    }
}
  • 딱 한 부분, toList()를 붙이는 것 말고 한 게 없다.

 실행 결과

 

정리

스트림 파이프라인은 0 또는 다수의 중개 오퍼레이션과 한개의 종료 오퍼레이션으로 구성되고, 스트림의 데이터 소스는 오직 종료 오퍼레이션을 실행할 때만 처리한다. 

 

 

손쉽게 병렬 처리를 할 수 있다.

이건 무슨말이냐면 이런 의문이 생길 것이다. "아니 뭐 굳이 스트림을 써? 그냥 for 루프 사용하면 되는거 아니야?" 맞다. 상관없다. 단순한 코드는 어떤걸 사용하더라도 뭐 크게 가시성이 달라지지도 않고 둘 다 읽기 편할 수 있다. 아래 코드를 보자.

import java.util.ArrayList;
import java.util.List;

public class Main {
    public static void main(String[] args) {
        List<String> friends = new ArrayList<>();
        friends.add("John");
        friends.add("Jane");
        friends.add("Bob");
        friends.add("Mary");

        friends.stream()
                .filter(friend -> friend.equals("John"))
                .forEach(System.out::println);

        for (String friend : friends) {
            if (friend.equals("John")) {
                System.out.println(friend);
            }
        }
    }
}
  • 하나는 스트림을 사용했고, 하나는 for 루프를 사용했다. 뭐 둘 다 읽기 편하고 아무런 문제도 없다. 
  • 실행 결과도 동일할 것이다.

 

그런데, 이런 경우가 있다. for 루프는 병렬 처리를 하기가 쉽지 않다. 위에 저 for 루프 안에서 요소 하나하나씩 순회하며 처리하지 저걸 병렬로 처리하고 있지 않는단 말이다. 그런데 스트림은 이걸 병렬로 처리하는게 굉장히 수월하다. 스트림은 요소 하나하나를 직렬로 어떤 행위를 처리할수도 있고 병렬로 어떤 행위를 처리할수도 있다. 

import java.util.ArrayList;
import java.util.List;

public class Main {
    public static void main(String[] args) {
        List<String> friends = new ArrayList<>();
        friends.add("John");
        friends.add("Jane");
        friends.add("Bob");
        friends.add("Mary");

        friends.parallelStream()
                .filter(friend -> friend.equals("John"))
                .forEach(System.out::println);
    }
}
  • 이렇게 stream() 대신에 parallelStream()을 사용하면 끝난다. 
  • 이럼 요소를 병렬로 처리하게 된다.

근데 또 눈으로 봐야만 믿는 사람들을 위해(나 포함) 아래와 같이 코드를 조금만 더 수정해보자.

import java.util.ArrayList;
import java.util.List;

public class Main {
    public static void main(String[] args) {
        List<String> friends = new ArrayList<>();
        friends.add("John");
        friends.add("Jane");
        friends.add("Bob");
        friends.add("Mary");

        friends.parallelStream()
                .filter(friend -> {
                    System.out.println("friend: " + friend + "||" + Thread.currentThread().getName());
                    return friend.equals("John");
                })
                .forEach(System.out::println);
    }
}
  • 실행하고 있는 쓰레드의 이름을 한번 찍어보자.

실행 결과

이 실행결과를 보면 알겠지만, 쓰레드의 이름이 다르다. 즉, 병렬처리가 제대로 되고 있다는 뜻이다. 이게 이제 손쉽게 병렬 처리를 할 수 있다는 말이다.

 

근데 손쉽게 병렬 처리를 한다고 마냥 좋을까?

지금 저 코드에서 병렬 처리를 하면 더 빠를까? 내가 볼땐 아니다. 이것도 눈으로 한번 확인해보자.

import java.util.ArrayList;
import java.util.List;

public class Main {
    public static void main(String[] args) {
        List<String> friends = new ArrayList<>();
        friends.add("John");
        friends.add("Jane");
        friends.add("Bob");
        friends.add("Mary");

        withParallelStream(friends);
        withForLoop(friends);
    }

    private static void withParallelStream(List<String> friends) {
        long startTime = System.currentTimeMillis();
        friends.parallelStream()
                .filter(friend -> friend.equals("John"))
                .forEach(System.out::println);
        long endTime = System.currentTimeMillis();
        System.out.println("parallelStream elapsed time: " + (endTime - startTime) + "ms");
    }

    private static void withForLoop(List<String> friends) {
        long startTime = System.currentTimeMillis();
        for (String friend : friends) {
            if (friend.equals("John")) {
                System.out.println(friend);
            }
        }
        long endTime = System.currentTimeMillis();
        System.out.println("for loop elapsed time: " + (endTime - startTime) + "ms");
    }
}
  • 두개를 실행해보자, 하나는 스트림으로 병렬처리를, 하나는 그냥 for 루프를 사용해서 동일한 작업을 하는데 시간을 측정해봤다.

실행 결과

엥?! 오히려 하나의 쓰레드로만 실행한게 더 빠르다. 왜 그럴까? 

 

→ 쓰레드를 여러개 사용하는데는 컨텍스트 스위칭 비용이 들기 때문이다. 또한, 쓰레드를 만들어내는 것도 리소스를 사용하는 것이기에 그렇다. 단순하게 생각해서 지금 저 `friends`라는 리스트는 그래봐야 개수가 4개밖에 없는 정말 작은 리스트이다. 그리고 요즘 컴퓨터는 1초에 연산을 몇번이나 할까? 수십억번을 한다. 수십억번. 4개 돌리는거? 일도 아니다. 그러니까 실제로 0ms가 걸린것이고. 그런데 4개 돌리는 그 와중에도 쓰레드를 3개를 더 만들어 총 4개를 사용하고, 그 4개를 돌려가며 사용하는 컨텍스트 스위칭 비용이 오히려 성능에 악화를 시키는 것이다. 그러니까 병렬 처리를 스트림으로 단순하게 할 수 있다고 해서 반드시 좋다고 생각하면 큰 오산이다. 이 경우가 그럼 언제 효율적일까? 데이터가 정말 많을때나 그 데이터로 처리하는 로직이 굉장히 복잡해서 하나의 쓰레드가 다 하는것보다 여러개의 쓰레드가 나눠 하는게 누가봐도 더 효율적일때 이 병렬 처리를 고려하면 좋다!

 

 

여러가지 Stream API

결론부터 말하면, 이거 외우는거 아니다. 쓰다보면 외워져서 바로 이거 쓰면 되겠구나! 싶은게 생길것이고, 모르면 이런거 있나? 찾아보면 된다. 진짜 여기서는 딱 두개만 해봐야겠다.

filter

말 그대로 뭔가 걸러내는 중개 오퍼레이션이다. 일단 코드로 바로 보자.

public class Shop {
    private String name;
    private boolean isOpen;

    public Shop() {
    }

    public Shop(String name, boolean isOpen) {
        this.name = name;
        this.isOpen = isOpen;
    }

    public String getName() {
        return name;
    }

    public void setName(String name) {
        this.name = name;
    }

    public boolean isOpen() {
        return isOpen;
    }

    public void setOpen(boolean open) {
        isOpen = open;
    }

    @Override
    public String toString() {
        return "Shop{" +
                "name='" + name + '\'' +
                ", isOpen=" + isOpen +
                '}';
    }
}
  • 우선 아주 간단한 클래스를 하나 만들었다. 가게에 대한 클래스고 가게 이름과 현재 열었는지 안 열었는지에 대한 필드들이 있다.
import java.util.ArrayList;
import java.util.List;

public class ShopMain {
    public static void main(String[] args) {
        Shop shopA = new Shop("A", true);
        Shop shopB = new Shop("B", true);
        Shop shopC = new Shop("C", false);
        Shop shopD = new Shop("D", true);

        List<Shop> shops = new ArrayList<>();
        shops.add(shopA);
        shops.add(shopB);
        shops.add(shopC);
        shops.add(shopD);

        shops.stream()
                .filter(Shop::isOpen)
                .forEach(System.out::println);
    }
}
  • 그리고 이렇게, 현재 오픈한 가게가 있는지를 찾아보는 간단한 스트림 API
  • 메서드 레퍼런스를 사용해서 매우매우 깔끔하게 작성했다.

실행 결과

 

 

근데, 이러고 싶을때가 있다. 안 열은 가게를 알고 싶은 경우가 있다. 이때는 역(Not)을 사용해야 하는데 그럼 이게 뭐가 살짝 불편하냐면 메서드 레퍼런스를 못쓴다. 다음과 같이 컴파일 오류가 난다. 

 

이럴때, 조금 더 이쁘게 작성할 수가 있는데, 이전 포스팅에서 배운 Predicate<T>을 사용하는 것이다! 왜냐하면 filter가 받는 타입 자체가 Predicate<T>이기 때문에 더할 나위없이 완벽하다. 그래서 이렇게 작성할 수 있다.

shops.stream()
        .filter(Predicate.not(Shop::isOpen))
        .forEach(System.out::println);

 

앞으로, 역(Not)과 메서드 레퍼런스를 같이 사용하고 싶을때 이 Predicate<T>을 적극 활용하자!

 

flatMap

flatMapmap의 추가 기능이라고 보면 된다. map이 뭐냐? 인풋을 받아 아웃풋으로 돌려준다. 그래서 인자의 타입도 우리가 배운 Function<T, R>이다. flatMap도 어떤 값(A)을 받아 어떤 값(B)로 만들어준다. 그런데 앞에 flat이 붙었다. 이건 뭐냐면, 리스트를 받아서 그 리스트의 요소를 다 풀어버리는 것이다. 코드로 보자.

 

import java.util.ArrayList;
import java.util.List;
import java.util.function.Predicate;

public class ShopMain {
    public static void main(String[] args) {
        Shop shopA = new Shop("A", true);
        Shop shopB = new Shop("B", true);
        Shop shopC = new Shop("C", true);
        Shop shopD = new Shop("D", true);

        List<Shop> openedShops = new ArrayList<>();
        openedShops.add(shopA);
        openedShops.add(shopB);
        openedShops.add(shopC);
        openedShops.add(shopD);

        Shop shopE = new Shop("E", false);
        Shop shopF = new Shop("F", false);
        Shop shopG = new Shop("G", false);
        Shop shopH = new Shop("H", false);

        List<Shop> closedShops = new ArrayList<>();
        closedShops.add(shopE);
        closedShops.add(shopF);
        closedShops.add(shopG);
        closedShops.add(shopH);

        List<List<Shop>> allShops = new ArrayList<>();
        allShops.add(openedShops);
        allShops.add(closedShops);

        allShops.stream()
                .flatMap(shops -> shops.stream())
                .forEach(shop -> System.out.println(shop.getName()));
    }
}
  • openedShops, closedShops 두 개의 리스트가 있다.
  • 그리고 이 각각 리스트를 리스트로 담은 allShops가 있다.
  • 그럼 allShops는 요소가 각각이 리스트이다.
  • allShops를 가지고 스트림을 돌리면 각 요소 하나하나가 리스트인데 flatMap을 사용해서 이 리스트를 풀어 헤치는 것이다. 그래서 그 하나의 요소인 리스트 전체를 다 돌고, 그 다음 하나의 요소인 리스트 전체를 다 돌 수 있게 말이다.

실행 결과

 

요 녀석을 더 깔끔하게 이렇게 바꿀 수도 있다.

//allShops.stream()
//        .flatMap(shops -> shops.stream())
//        .forEach(shop -> System.out.println(shop.getName()));
        
        
allShops.stream()
        .flatMap(Collection::stream)
        .forEach(shop -> System.out.println(shop.getName()));

 

 

이 정도만 알아보고 나머지 여러 기능들은 공식 문서를 통해 필요할 때 찾아서 사용하면 된다. 다시 말하지만 이걸 외우는거 아니다! 안 외워도 자주 사용하는건 저절로 외워지기도 하고 필요한게 생기면 찾아서 사용하면 된다! 다음 공식 문서에서.

 

Stream (Java Platform SE 8 )

A sequence of elements supporting sequential and parallel aggregate operations. The following example illustrates an aggregate operation using Stream and IntStream: int sum = widgets.stream() .filter(w -> w.getColor() == RED) .mapToInt(w -> w.getWeight())

docs.oracle.com

 

728x90
반응형
LIST

'JAVA의 가장 기본이 되는 내용' 카테고리의 다른 글

[Java 8] CompletableFuture  (0) 2024.11.30
[Java 8] Optional  (0) 2024.11.27
[Java 8] 함수형 인터페이스와 람다 표현식  (0) 2024.11.25
애노테이션  (6) 2024.10.21
리플렉션  (6) 2024.10.21
728x90
반응형
SMALL

자바8부터 나타난 함수형 인터페이스에 대해 알아보는 시간을 가져보자.

 

함수형 인터페이스 (Functional Interface)

  • 추상 메서드를 딱 하나만 가지고 있는 인터페이스를 말한다. (SAM 인터페이스라고도 한다) (SAM = Single Abstract Method)
  • @FunctionalInterface 애노테이션을 가지고 있는 인터페이스를 말한다.

다음 코드를 보자.

@FunctionalInterface
public interface Hello {
    void hello();
}
  • 위 코드처럼 추상 메서드가 딱 하나만 있을때 이 인터페이스를 함수형 인터페이스라고 한다.
  • 그리고 함수형 인터페이스를 정의할 일이 있다면 @FunctionalInterface 애노테이션을 사용해서 이 인터페이스가 함수형 인터페이스임을 명확히 하는게 좋다. 왜냐하면 추상 메서드가 한개가 아닌 경우 아래 사진처럼 컴파일 에러를 만들어주기 때문이다. 

 

 

이런 경우도 함수형 인터페이스이다.

@FunctionalInterface
public interface Hello {
    void hello();
    
    int h = 100;

    static void howAreYou() {
        System.out.println("how are you");
    }

    default void hi() {
        System.out.println("Hello");
    }
}
  • 자바8부터 인터페이스에 이렇게 메서드를 직접 정의할수도 있게 됐는데 그런것이 몇 개가 있던 결국 가장 중요한건 추상 메서드가 딱 한개이냐 아니냐로 함수형 인터페이스는 정의된다.
  • 여기서도 마찬가지로 abstract void hello(); 하나뿐이므로 이 인터페이스는 함수형 인터페이스이다.
  • 참고로, 인터페이스에서 abstract는 생략 가능하다.

 

그럼 이렇게 정의한 함수형 인터페이스를 어떻게 사용하면 되느냐? 다음 코드를 보자.

public class FIMain {
    public static void main(String[] args) {
        Hello h = new Hello() {
            @Override
            public void hello() {
                System.out.println("hello");
            }
        };

        h.hello();
    }
}
  • 자바8 이전에는 이런식으로 사용했다. 이거를 익명 내부 클래스라고 했었다. 굳이 구현체를 클래스로 따로 만들지 않아도 이렇게 작성하면 되니까 익명 내부 클래스라는 이름이 붙은 것 같다.
  • 지금도 당연히 이렇게 사용할 수 있다.

그런데 이 코드를 획기적으로 줄일 수가 있다. 다음 코드를 보자.

public class FIMain {
    public static void main(String[] args) {
        Hello h = () -> System.out.println("hello");

        h.hello();
    }
}
  • 단 한줄로 변경된 모습이 보이는가? 이게 함수형 인터페이스를 람다로 표현한다고 한다. 
  • 물론, 실행 부분이 저렇게 딱 한줄일때 이렇게 사용할 수 있고 만약 한 줄 이상이라면 다음과 같이 사용하면 된다.
public class FIMain {
    public static void main(String[] args) {
        Hello h = () -> {
            System.out.println("hello");
            System.out.println("Hi");
        };

        h.hello();
    }
}
  • 그럼에도 불구하고 익명 내부 클래스보단 획기적으로 코드양이 줄어 보인다.
  • 이런 표현식을 람다 표현식이라고 한다.

 

자바에서 제공하는 함수형 인터페이스

개발자가 직접 구현하지 않고 자바에서 자체적으로 제공해주는 함수형 인터페이스가 있다. 바로 다음 패키지에 있는 함수형 인터페이스들이다.

java.util.function

 

 

Java Platform SE 8

 

docs.oracle.com

 

위 패키지에서 여러가지 함수형 인터페이스가 있는데 대표적인 것들을 살펴보자.

  • Function<T, R>
  • BiFunction<T, U, R>
  • Consumer<T>
  • Supplier<T>
  • Predicate<T>
  • UnaryOperator<T>
  • BinaryOperator<T>

 

Function<T, R>

이 함수형 인터페이스는 인풋 T를 받고, 아웃풋 R을 반환한다. 코드로 바로 알아보자.

import java.util.function.Function;

public class FIMain {
    public static void main(String[] args) {
        Function<Integer, Integer> plus = (number) -> number + 1;
        
        System.out.println(plus.apply(2));
    }
}
  • Integer를 받아서 Integer를 반환하는 plus 라는 이름의 함수형 인터페이스 Function을 구현했다.
  • 이 함수형 인터페이스는 apply라는 추상 메서드를 구현해야 하고 그것을 우리는 받은 인자에 + 1을 한 값을 리턴하는 것으로 구현했다.
  • 이 녀석의 apply(2)를 실행하면 결과는 3이 나오게 된다.

실행 결과

 

 

이런식으로도 작성할 수 있겠다.

import java.util.function.Function;

public class Main {
    public static void main(String[] args) {
        Function<Integer, Integer> plusWithOne = (x) -> x + 1;
        Function<Integer, Integer> multiplyWithTwo = (x) -> x * 2;

        System.out.println(multiplyWithTwo.apply(2));
    }
}
  • 인자값을 받아 2를 곱하는 함수형 인터페이스 Function을 구현했다.
  • 실행하면 당연히 결과는 4가 나온다.

실행 결과

 

 

그런데, 이 두개의 Function을 조합할수도 있다. Function에서 제공하는 compose()라는 메서드가 있다.

import java.util.function.Function;

public class Main {
    public static void main(String[] args) {
        Function<Integer, Integer> plusWithOne = (x) -> x + 1;
        Function<Integer, Integer> multiplyWithTwo = (x) -> x * 2;
        
        Function<Integer, Integer> compose = plusWithOne.compose(multiplyWithTwo);
        System.out.println(compose.apply(2));
    }
}
  • 이렇게 composeFunctionFunction을 조합하는 게 가능하다.
  • compose는 인자로 받은 Function을 먼저 apply 수행하고, 그 결과값을 다시 apply해서 결과를 반환한다.
  • 그러니까, compose.apply(2)를 하면, 먼저 multiplyWithTwo를 실행해서 4를 만들고, 그 결과값을 plusWithOne.apply()에 인자로 넣어 실행하게 된다. 그래서 결과는 5가 나온다.

실행 결과

 

 

이번에는 이런 것도 있다.

import java.util.function.Function;

public class Main {
    public static void main(String[] args) {
        Function<Integer, Integer> plusWithOne = (x) -> x + 1;
        Function<Integer, Integer> multiplyWithTwo = (x) -> x * 2;

        Function<Integer, Integer> andThen = plusWithOne.andThen(multiplyWithTwo);
        System.out.println(andThen.apply(5));
    }
}
  • andThen(). 이것도 역시 두 Function을 조합하는데, 이건 받은 Function이 뒤에 실행된다.
  • 그러니까, 먼저 plusWithOne.apply()가 실행되고, 그 실행된 결과값을 multiplyWithTwo.apply()인자로 받아 실행된 결과값을 반환한다. 그래서 결과는 12가 나온다.

실행 결과

 

BiFunction<T, U, R>

BiFunctionFunction이랑 똑같은데, 인자값을 2개(T, U) 받는다. 그래서 R을 반환한다.

import java.util.function.BiFunction;

public class Main {
    public static void main(String[] args) {
        BiFunction<Integer, Integer, Integer> add = (x, y) -> x + y;
        System.out.println(add.apply(1, 2));
    }
}
  • 이런식으로 작성할 수 있고, 결과는 3이 나오게 된다.

실행 결과

 

 

Consumer<T>

이건 반환값이 없다. 추상 메서드의 반환 타입이 void다. 이름 그대로 소비자의 역할을 한다고 보면 된다.

import java.util.function.Consumer;

public class Main {
    public static void main(String[] args) {
        Consumer<Integer> printer = (x) -> System.out.println(x);
        printer.accept(1);
    }
}
  • 얘는 추상 메서드 명이 accept()이다. 그리고 위와 같이 반환값이 없다. 간단하게 받은 파라미터를 출력하도록 작성했다.

실행 결과

 

Supplier<T>

이 녀석은 반대다. 받는게 없고 반환만 한다. 이름 그대로 공급자의 역할을 한다고 보면 된다.

import java.util.function.Supplier;

public class Main {
    public static void main(String[] args) {
        Supplier<Integer> get10 = () -> 10;
        System.out.println(get10.get());
    }
}
  • 얘는 추상 메서드 명이 get()이다. 공급자라는 이름에 아주 걸맞는 메서드명이다.
  • 위 코드처럼 받는것은 없고 반환만 한다. 

 

Predicate<T>

이 녀석은, 어떤 인자값을 받아 boolean 타입을 반환한다.

import java.util.function.Predicate;

public class Main {
    public static void main(String[] args) {
        Predicate<Integer> isOne = (x) -> x == 1;
        System.out.println(isOne.test(1));
        System.out.println(isOne.test(2));
    }
}
  • 위 코드와 같이 인자값을 받아서 그 인자값이 1인지 확인하는 뭐 이런 코드를 작성할 수 있겠다.
  • 추상 메서드의 이름은 test()이다.

실행 결과

 

 

그리고 이 녀석은 반환값이 boolean이기 때문에 이런 조합 메서드를 제공한다.

  • and()
  • or()
  • negate()
import java.util.function.Predicate;

public class Main {
    public static void main(String[] args) {
        Predicate<Integer> isOne = (x) -> x == 1;
        Predicate<Integer> isOdd = (x) -> x % 2 != 0;

        Predicate<Integer> andPredicate = isOne.and(isOdd);
        System.out.println(andPredicate.test(1));
    }
}
  • Predicate을 조합하는데 AND 조건으로 조합해서 결과를 반환한다. 
  • 위 코드를 보면 하나는 받은 인자가 1인지, 하나는 받은 인자가 홀수인지를 체크하는 Predicate이다.
  • 이 두개를 AND로 조합해서 둘 다 true를 반환하면 true를 반환하고 둘 중 하나라도 false라면 false를 반환한다.

실행 결과

 

 

그럼 or(), negate()은 예측이 가능하다. 

import java.util.function.Predicate;

public class Main {
    public static void main(String[] args) {
        Predicate<Integer> isOne = (x) -> x == 1;
        Predicate<Integer> isOdd = (x) -> x % 2 != 0;

        Predicate<Integer> orPredicate = isOne.or(isOdd);;
        System.out.println(orPredicate.test(3));
    }
}
  • 하나는 1인지, 하나는 홀수인지를 체크하는 Predicate인데 이 두 개를 or()로 연결했다.
  • 둘 중 하나라도 true라면 true를 반환하고, 둘 중 하나라도 false라면 false를 반환할 것이다.

실행 결과

 

import java.util.function.Predicate;

public class Main {
    public static void main(String[] args) {
        Predicate<Integer> isOne = (x) -> x == 1;
        Predicate<Integer> isOdd = (x) -> x % 2 != 0;

        Predicate<Integer> negate = isOne.negate();
        System.out.println(negate.test(1));
    }
}
  • negate()은 역이다. true라면 false를, false라면 true를 반환한다.

실행 결과

 

 

UnaryOperator<T> 

이 녀석은 편리함을 제공해주는 녀석이다. 다음 코드를 보자.

import java.util.function.Function;

public class Main {
    public static void main(String[] args) {
        Function<Integer, Integer> plusWithOne = (x) -> x + 1;
    }
}
  • 위 코드처럼 입력값과 반환값의 타입이 동일한 경우에 다음과 같이 사용할 수가 있다.
import java.util.function.UnaryOperator;

public class Main {
    public static void main(String[] args) {
        // Function<Integer, Integer> plusWithOne = (x) -> x + 1;
        UnaryOperator<Integer> plusWithOne = (x) -> x + 1;
    }
}
  • 입력값과 반환값이 같은 경우, UnaryOperator를 사용해서 좀 더 간결하게 작성할 수가 있다.
  • 그리고 이 UnaryOperatorFunction을 상속받는다. 그래서 Function이 제공하는 조합 메서드(compose(), andThen(), ...)을 사용할 수 있다.

 

 

BinaryOperator<T>

이 녀석은 BiFunction<T, U, R>의 간편 메서드라고 보면 된다. 이 BiFunction은 두 개의 인자를 받아 R타입을 반환하는 녀석이다. 근데 이 세 개의 타입(T, U, R)이 모두 같은 경우 이 BinaryOperator<T>를 사용할 수가 있다.

import java.util.function.BinaryOperator;

public class Main {
    public static void main(String[] args) {
        // BiFunction<Integer, Integer, Integer> add = (x, y) -> x + y;
        BinaryOperator<Integer> add = (x, y) -> x + y;
    }
}

 

 

이렇게 대표적인 것들을 알아봤는데 직접 저 패키지 안으로 들어가보면, 이 말고도 굉장히 뭐가 많다. 근데 지금까지 배운것들의 응용이라고 생각하면 된다. 이름만 봐도 "아 이건 이거겠구나!"를 추측할 수 있을 것이다. 예를 들어, 이런 거다.

직접 이 패키지에 뭐가 있는지 쭉 보면, 맨 위에 BiConsumer<T, U>가 있다. 그럼 우린 Consumer<T>를 배웠기 때문에 이게 뭔지 추측이 가능하다. "아, 두 개의 인자를 받아서 아무것도 반환은 안하고 TU를 가지고 뭔가를 하겠구나?" 맞다. 

 

변수 캡처

이 부분은 꽤나 중요하다. 자세히 들여다보자. 함수형 인터페이스와 람다 표현식을 사용할때 주의할 점이 있다. 바로 이 변수 캡처에 대한 내용인데 다음 코드를 보자.

import java.util.function.Consumer;

public class Main {
    public static void main(String[] args) {
        final int number = 10;

        // 로컬 클래스
        class LocalClass {
            void local() {
                System.out.println(number);
            }
        }

        // 익명 내부 클래스
        Consumer<Integer> consumer = new Consumer<Integer>() {
            @Override
            public void accept(Integer integer) {
                System.out.println(number);
            }
        };

        // 람다
        Consumer<Integer> lambda = (x) -> System.out.println(x + number);
        lambda.accept(number);
    }
}
  • 로컬 클래스든, 익명 내부 클래스든, 람다 표현식이든 변수를 참조를 할수가 있다. 근데 자바8 이전에는 그 변수는 반드시 final 키워드가 붙어야 했다. 즉, 선언 이후 절대로 변경되지 않을 변수만 참조가 가능하다.
  • 그런데, 자바8 이후부터는 이런 경우에 final을 붙이지 않아도 참조할 수 있다. 다음 코드를 보자. 
import java.util.function.Consumer;

public class Main {
    public static void main(String[] args) {
        int number = 10;

        // 로컬 클래스
        class LocalClass {
            void local() {
                System.out.println(number);
            }
        }

        // 익명 내부 클래스
        Consumer<Integer> consumer = new Consumer<Integer>() {
            @Override
            public void accept(Integer integer) {
                System.out.println(number);
            }
        };

        // 람다
        Consumer<Integer> lambda = (x) -> System.out.println(x + number);
        lambda.accept(number);
    }
}
  • 이 역시 문법적으로 아무런 문제도 되지 않는 올바른 코드이다. 이게 이제 가능한데 이거를 "사실상 final" 이라고 표현한다.
  • "사실상 final" 이란 말은, final 이라는 키워드는 붙지 않았지만, 이 값이 final처럼 취급되는 경우를 말한다.
  • 여기서 만약, 이후에 값을 변경하려고 하면 어떻게 될까? 아래와 같이 컴파일 오류가 발생한다.

즉, 선언한 후 값이 변경되지 않는 변수에 대해서는 로컬 클래스든, 익명 내부 클래스든, 람다든 변수를 참조할 수 있는데 이것을 변수 캡처라고 한다. 그런데 여기서 더 중요한 사실이 있다. [로컬 클래스, 익명 내부 클래스]와 람다는 차이가 있다.

 

다음 코드를 보자.

import java.util.function.Consumer;

public class Main {
    public static void main(String[] args) {
        final int number = 10;

        // 로컬 클래스
        class LocalClass {
            final int number = 55;
            void local() {
                int number = 30;
                System.out.println(number);
            }
        }

        new LocalClass().local();

        // 익명 내부 클래스
        Consumer<Integer> consumer = new Consumer<Integer>() {
            final int number = 40;
            @Override
            public void accept(Integer integer) {
                System.out.println(number + integer);
            }
        };
        consumer.accept(4);

        // 람다
        Consumer<Integer> lambda = (x) -> System.out.println(x + number);
        lambda.accept(5);
    }
}
  • 벌써 어지럽다. 근데, 결론적으로 로컬 클래스와 익명 내부 클래스는 로컬 변수를 가질 수가 있다.
  • 위 코드를 보면 바깥에 있는 main 메서드에 number라는 변수를 선언했는데, 로컬클래스에서 local() 메서드 안에 또 다른 로컬 변수 number를 선언했다.
  • 위 코드를 보면 바깥에 있는 main 메서드에 number라는 변수를 선언했는데, 익명 내부 클래스 안에서 또 다른 로컬 필드인 number를 선언했다. 
  • 이 경우에는 Scope이 어떻게 결정될까? 실행 결과를 보자.

  • 이러한 결과가 나왔다. 어찌보면 당연한 것이다. 물론, 익명 내부 클래스도 accept() 메서드 안에 로컬 변수로 선언해도 상관없다. 로컬 클래스와 같이 더 가까이에 있는게 적용된다. 

 

그런데, 람다는 아니다! 람다는 Scope이 람다만의 Scope은 없다. main 메서드와 Scope을 같이한다. 즉, 람다를 감싸고 있는 녀석과 같다는 말이다. 그러니까 아래 사진을 보자. 컴파일 오류가 난다. 당연하다. 왜냐? 같은 Scope에 동일한 이름의 변수를 만들 수 없는건 너무 당연하니까!

 

메서드 레퍼런스

메서드 레퍼런스는 뭘까? 다시 한번 아래 코드를 보자.

import java.util.function.Consumer;

public class Main {
    public static void main(String[] args) {
        Consumer<Integer> lambda = (x) -> System.out.println(x);
        lambda.accept(5);
    }
}
  • Consumer를 람다 표현식으로 만들었다. 그리고 바디에서 하는 일은 입력값을 그대로 시스템 콘솔에 출력한다.
  • 그런데 이렇게 람다의 바디에서 하는 일이 기존 메서드 또는 생성자를 호출하는 거라면, 메서드 레퍼런스를 사용해서 매우 간결하게 표현할수가 있는데 다음 코드를 보자.
import java.util.function.Consumer;

public class Main {
    public static void main(String[] args) {
        Consumer<Integer> lambda = System.out::println;
        lambda.accept(5);
    }
}
  • 이게 바로 메서드 레퍼런스이다. 훨씬 더 깔끔해졌다. 그냥 System.outprintln()을 호출하는 것 뿐이고 그런 경우에는 이렇게 메서드 레퍼런스로 매우 간결하게 출력할 수 있다. 
  • 당연히 출력하는 값은 Consumer는 입력값을 받기 때문에 입력값을 그대로 출력한다.

실행 결과

 

 

굳이 따지자면, 이렇게 4가지가 가능하다.

  • 타입::스태틱 메서드
  • 객체 레퍼런스::인스턴스 메서드
  • 타입::인스턴스 메서드
  • 타입::new

타입::스태틱 메서드

public class MethodRef {

    public static String staticMethod(String s) {
        return "Hello " + s;
    }
}

자, 위와 같은 클래스가 있다고 해보자.

 

import java.util.function.UnaryOperator;

public class Main {
    public static void main(String[] args) {
        UnaryOperator<String> lambda = MethodRef::staticMethod;
        System.out.println(lambda.apply("World"));
    }
}
  • 똑같이 String을 받아서 String을 반환한다면, 타입::스태틱 메서드 형태로 표현할 수 있다.

실행 결과

 

객체 레퍼런스::인스턴스 메서드

public class MethodRef {

    public String instanceMethod(String s) {
        return "Hello " + s;
    }

    public static String staticMethod(String s) {
        return "Hello " + s;
    }
}

 

 

import java.util.function.UnaryOperator;

public class Main {
    public static void main(String[] args) {
        MethodRef methodRef = new MethodRef();

        UnaryOperator<String> lambda = methodRef::instanceMethod;
        System.out.println(lambda.apply("World"));
    }
}
  • 위 코드처럼 인스턴스가 있고, 인스턴스의 메서드를 가지고 람다 표현식을 깔끔하게 쓸 수 있다.

실행 결과

 

 

타입::new

public class MethodRef {

    private String s;

    public MethodRef() {
    }

    public MethodRef(String s) {
        this.s = s;
    }

    public String getS() {
        return s;
    }

    public String instanceMethod(String s) {
        return "Hello " + s;
    }

    public static String staticMethod(String s) {
        return "Hello " + s;
    }
}

자, 이번엔 필드하나를 추가하고 생성자 두개를 추가했다.

 

import java.util.function.Supplier;

public class Main {
    public static void main(String[] args) {
        Supplier<MethodRef> methodRef = MethodRef::new;
        MethodRef methodRefBySupplier = methodRef.get();
    }
}
  • 이런게 가능하다. 생성자를 호출할 수도 있다.
  • 여기서 호출한 생성자는 뭘까 그럼? Supplier는 아무런 인자도 받지 않는다. 그리고 반환하는 것이 MethodRef다. 이런 경우엔? 저기 위에서 선언한 기본생성자를 호출하는 것이다.
import java.util.function.Function;

public class Main {
    public static void main(String[] args) {
        Function<String, MethodRef> methodRef = MethodRef::new;
        MethodRef hello = methodRef.apply("hello");

        System.out.println(hello.getS());
    }
}
  • 이번에도 역시 생성자를 호출하는데, 지금 보면 Function으로 되어 있다. 즉, 받는 값이 있고 반환하는 값이 있는건데, 받는 값이 String이고 반환값이 MethodRef다. 이 경우에는 당연히 기본 생성자가 아니라 String을 받는 생성자를 호출하는 것이다!
  • 실제로 apply("hello")를 호출했을때, 필드 `s`에 저 값이 들어가는지 확인해보면 다음과 같다.

실행 결과

 

 

타입::인스턴스 메서드

import java.util.Arrays;

public class Main {
    public static void main(String[] args) {
        String[] fruit = {"apple", "tomato", "orange"};
        Arrays.sort(fruit, String::compareToIgnoreCase);
    }
}
  • 이런게 타입::인스턴스 메서드이다. 
  • 보면, Arrays.sort()를 사용해서 배열을 받고 정렬을 하고 있다.
  • 정렬할때 두번째 인자로, Comparator를 넣어줘야 하는데, 보통은 이제 아래와 같이 사용을 할 것이다.
import java.util.Arrays;
import java.util.Comparator;

public class Main {
    public static void main(String[] args) {
        String[] fruit = {"apple", "tomato", "orange"};
        
        Comparator<String> comparator = (o1, o2) -> o1.compareTo(o2);
        Arrays.sort(fruit, comparator);
    }
}
  • 그런데 이제, 이렇게 사용이 가능하다는 것이다.
Arrays.sort(fruit, String::compareToIgnoreCase);
  • 이건 이제, fruit 안에 있는 문자열 두개를 가져와서 서로 비교를 하고 있는건데, String 이라는 타입의 "apple", "tomato", "orange"라는 인스턴스의 메서드인 compareToIgnore()을 사용하고 있는 타입::인스턴스 메서드이다.

 

인터페이스 기본 메서드와 스태틱 메서드

또한, 자바8부터 제공되는 인터페이스의 기본 메서드와 스태틱 메서드도 알아보자. 자 다음 코드를 보자.

public interface Hello {
    void printHello();
}
  • Hello 라는 인터페이스 하나가 있다.
public class HelloImpl implements Hello {
    @Override
    public void printHello() {

    }
}
  • Hello 를 구현한 HelloImpl 클래스가 있다.

 

그런데 만약 이때, Hello를 구현하는 모든 구현체는 다 동일하게 어떤 메서드를 가지고 싶게 하려면 어떻게 하면 될까? 모두 같은 기능을 하는 메서드인데 인터페이스에 또 추상 메서드를 하나 선언해버리면? 다음과 같은 컴파일 오류가 날 것이다.

public interface Hello {
    void printHello();

    void printHi();
}

 

이런 경우에 자바8부터는 인터페이스에 기본 메서드를 만들 수 있도록 했다. 바로 이렇게 말이다.

public interface Hello {
    void printHello();

    default void printHi() {
        System.out.println("Hi");
    }
}
  • 이렇게 default 라는 키워드를 사용하여 메서드를 직접 인터페이스에서 구현할 수 있게 했고, 이때 이 인터페이스를 구현하는 구현체는 모두 동일하게 이 메서드를 사용할 수 있다.
public class HelloImpl implements Hello {
    @Override
    public void printHello() {
        printHi();
    }
}
  • 조금 모양새가 웃기긴 하지만, printHello() 메서드 안에 기본 메서드인 printHi()를 호출하고 있다.

 

기본 메서드의 탄생 취지

→ 해당 인터페이스를 구현한 클래스를 깨뜨리지 않고 모든 구현한 클래스에 동일한 새 기능을 추가할 수 있다.

 

그런데, 이 기본 메서드는 구현체가 모르게 추가된 기능이기 때문에 그만큼 리스크가 있다. 어떤 리스크가 있을까? 

기본 메서드의 리스크

public interface Hello {
    void printHello();

    default void printHi(String yourName) {
        System.out.println(yourName.toUpperCase() + ", Hello!");
    }
}
  • 예를 들어, 기본 메서드를 하나 만들었는데 파라미터로 이름을 받는다. 그리고 그 이름을 toUpperCase()를 호출하는데 만약 넘겨진 이름이 null 이라면? 런타임 오류가 발생할 수 있다.
  • 그래서, 최대한 이런 예측 못한 에러를 방지할 수 있도록 다음과 같이 문서화 하는 것을 꼭 염두하자. 
public interface Hello {
    void printHello();

    /**
     * @implSpec 파라미터로 이름을 받아서 해당 이름을 대문자로 변경한 후, ", Hello!"를 붙여 출력한다. 따라서 이름은 반드시 필수로 받아야 한다.
     * @param yourName 이름 
     */
    default void printHi(String yourName) {
        System.out.println(yourName.toUpperCase() + ", Hello!");
    }
}

 

기본 메서드의 여러가지 규칙들

기본 메서드를 만들 때, Object가 제공하는 기능(toString(), equals(), ...)은 기본 메서드로 제공할 수 없다. 기본 메서드로 선언하는 순간 다음과 같은 컴파일 오류가 발생한다.

 

인터페이스를 상속받는 인터페이스에서 다시 추상 메서드로 변경도 가능하다.

public interface Hello {
    void printHello();

    /**
     * @implSpec 파라미터로 이름을 받아서 해당 이름을 대문자로 변경한 후, ", Hello!"를 붙여 출력한다. 따라서 이름은 반드시 필수로 받아야 한다.
     * @param yourName 이름
     */
    default void printHi(String yourName) {
        System.out.println(yourName.toUpperCase() + ", Hello!");
    }
}

 

public interface HelloExtends extends Hello {

    void printHi(String yourName);
}
  • Hello를 상속받는 HelloExtendsprintHi를 다시 추상 메서드로 변경했다.
  • 이제 이 HelloExtends를 구현하는 구현체는 반드시 printHi(String yourName)을 구현해야 한다.

 

두 개의 인터페이스가 같은 시그니처를 갖는 기본 메서드를 제공할 경우에는 그 두 인터페이스를 둘 다 구현하는 구현체는 무조건 동일한 시그니처를 갖는 기본 메서드를 재정의해야 한다.

예를 들어 아래 코드를 보자.

public interface Hello {
    void printHello();

    /**
     * @implSpec 파라미터로 이름을 받아서 해당 이름을 대문자로 변경한 후, ", Hello!"를 붙여 출력한다. 따라서 이름은 반드시 필수로 받아야 한다.
     * @param yourName 이름
     */
    default void printHi(String yourName) {
        System.out.println(yourName.toUpperCase() + ", Hello!");
    }
}

 

public interface Hi {
    default void printHi(String yourName) {
        System.out.println(yourName.toUpperCase() + ", Hi!");
    }
}

 

  • Hello, Hi를 둘 다 구현하는 HelloHiImpl 클래스는 오류가 발생한다. 왜냐하면, 완전히 동일한 시그니처를 가지는 기본 메서드가 둘 다 있기 때문에 어떤걸 사용해야 할지 컴파일러는 애매하기 때문이다. 그래서 이런 경우에는 반드시 해당 기본 메서드를 재정의 해야 한다. 아래와 같이.
public class HelloHiImpl implements Hello, Hi {
    @Override
    public void printHello() {

    }

    @Override
    public void printHi(String yourName) {
        System.out.println("HH");
    }
}

 

 

이제 스태틱 메서드를 알아볼건데 이건 뭐 없다. 그냥 인터페이스에 스태틱 메서드를 만들 수 있다가 끝이다.

public interface Hello {

    static String returnString(String a) {
        return a + "string";
    }
}
  • 이렇게 인터페이스에도 스태틱 메서드를 만들 수가 있다. 
public class Main {
    public static void main(String[] args) {
        String gg = Hello.returnString("gg");
        System.out.println(gg);
    }
}
  • 사용하는 것도 스태틱 메서드 사용하는것 그대로 동일하다.

인터페이스의 기본 메서드가 가져온 새로운 혁신

인터페이스의 기본 메서드가 생기고 나서부터 엄청난 혁신이 생기게 됐다. 자바8 이전에는 인터페이스가 이렇게 있었다면,

public interface Something {
    void a();
    void b();
    void c();
}

이 인터페이스를 구현하는 구현체 하나를 두기도 했다.

public abstract class SomethingAbstract implements Something {
    @Override
    public void a() {
        
    }

    @Override
    public void b() {

    }

    @Override
    public void c() {

    }
}
  • 왜 이랬을까? 저 인터페이스를 구현하는 구현체에게 편리함을 제공하기 위해서다.
  • 자바8 이전에는 저 인터페이스를 구현하는 구현체는 좋든 싫든 a(), b(), c()를 모두 구현해야만 했다.
  • 그게 너무 싫으니, 이렇게 아무것도 없는 껍데기뿐인 Abstract 클래스를 하나 만들고 인터페이스를 구현하게 하고 이 클래스를 상속받는 클래스를 만들어서 본인이 원하는 메서드만 구현하게 했던 것이다.
public class SomethingA extends SomethingAbstract {
    @Override
    public void a() {
        System.out.println("SomethingA");
    }
}
  • 이렇게 말이다. 
  • 그런데 이제는 인터페이스에서 기본 메서드를 구현할 수 있으니 이런 불편함을 없애는것과 동시에 혁신적 혁명이 일어난다.
  • 왜 혁명일까? 인터페이스는 상속이 아니라 구현이기 때문에 아무리 많이 구현해도 상관이 없고 상속의 강제화에서 벗어날 수 있기 때문이다. 

 

이러한 이유로 인터페이스의 기본 메서드는 라이브러리나 프레임워크를 만들때 굉장히 자주 빈번하게 사용되는 것을 볼 수 있다. 스프링도 그렇다. 

 

 

자바 API 기본 메서드

자바8부터 굉장히 많은 것들이 추가가 됐다. 그 중 대표적인 게 Stream API인데, 이건 이제는 너무 중요하기도 하고 자주 사용되기 때문에 아예 포스팅 하나를 새로 만들어서 이것만 다뤄보기로 할것이고 여기서는 맛보기 정도를 해보자.

 

Iterable의 기본 메서드

  • forEach()
  • spliterator()

이 두개를 한번 맛보자. forEach()는 순회하는 기능인데, 이거 보면 재밌다.

  • forEach()가 인자로 무엇을 받고 있나? 바로 Consumer다. 위에서 배운 Consumer.
  • Consumer를 받는다는 것은 람다로 표현할 수 있다는 뜻이고, 인자를 받지만 반환은 하지 않는 그런 함수형 인터페이스이다.
  • 그래서 다음과 같이 사용할 수 있다.
friends.forEach(friend -> System.out.println(friend));
  • Consumer를 배우니까 이게 어떤것인지 너무나 명확하게 이해가 된다.
  • 순회하는 각 요소를 Consumer의 인자로 주고 그 안에서 무언가를 하지만 반환은 하지 않는 것이다.
  • 그리고, 저렇게 작성하면? 그렇다. 메서드 레퍼런스를 사용해서 더 간단하게 축약할 수 있다.
friends.forEach(System.out::println);

 

spliterator()는 자주 사용되는 것은 아니지만, 알아둬서 나쁠건 없다. 이 녀석 역시 순회를 하는데 이 녀석도 재밌다.

import java.util.ArrayList;
import java.util.List;
import java.util.Spliterator;

public class Main {
    public static void main(String[] args) {
        List<String> friends = new ArrayList<>();
        friends.add("John");
        friends.add("Jane");
        friends.add("Bob");
        friends.add("Mary");

        Spliterator<String> spliterator = friends.spliterator();
        while (spliterator.tryAdvance(System.out::println));
    }
}
  • 역시 마찬가지로 순회를 하는데 얘는 꼭 next()를 호출하는 것 같은 생김새다.
  • 이 친구는 next() 대신 tryAdvance()를 사용하는데 그 안에 어떤 작업을 할지도 작성할 수 있다.
  • 그리고 이름에 split이 있는거 보니, 쪼갤 수도 있는 것 같다. 맞다. 
import java.util.ArrayList;
import java.util.List;
import java.util.Spliterator;

public class Main {
    public static void main(String[] args) {
        List<String> friends = new ArrayList<>();
        friends.add("John");
        friends.add("Jane");
        friends.add("Bob");
        friends.add("Mary");

        Spliterator<String> spliterator = friends.spliterator();
        Spliterator<String> stringSpliterator1 = spliterator.trySplit();

        while (stringSpliterator1.tryAdvance(System.out::println));
        System.out.println("=================================");
        while (spliterator.tryAdvance(System.out::println));
    }
}
  • 이렇게 반으로 쪼갤수도 있다. 그리고 각각을 순회시켜서 출력해보면 결과는 다음과 같다.

 

그 외 여러가지 API가 있는데, 이후에 작성할 포스팅에서 Stream API를 배워보면서 자세하게 배워보자!

728x90
반응형
LIST

'JAVA의 가장 기본이 되는 내용' 카테고리의 다른 글

[Java 8] Optional  (0) 2024.11.27
[Java 8] Stream API  (0) 2024.11.27
애노테이션  (6) 2024.10.21
리플렉션  (6) 2024.10.21
ServerSocket으로 HTTP 서버 만들기  (2) 2024.10.18
728x90
반응형
SMALL

참고자료

 

스프링 DB 1편 - 데이터 접근 핵심 원리 강의 | 김영한 - 인프런

김영한 | 백엔드 개발에 필요한 DB 데이터 접근 기술을 기초부터 이해하고, 완성할 수 있습니다. 스프링 DB 접근 기술의 원리와 구조를 이해하고, 더 깊이있는 백엔드 개발자로 성장할 수 있습니

www.inflearn.com

 

저번 포스팅에 이어서 진행하자. 저번 포스팅까지 트랜잭션에 대해 알아보았다. 트랜잭션을 사용하니 원자성을 유지할 수 있었으나 여러 문제점들이 있었는데 어떤 문제가 있었는지를 차근차근 알아보면서 그 문제점들을 스프링이 어떻게 완벽하게 해결해주는지 알아보자.

 

문제점들

애플리케이션 구조

여러가지 애플리케이션 구조가 있지만, 가장 단순하면서 많이 사용하는 방법은 역할에 따라 3가지 계층으로 나누는 것이다.

  • 프레젠테이션 계층
    • UI와 관련된 처리 담당
    • 웹 요청과 응답
    • 사용자 요청을 검증
    • 주 사용 기술: 서블릿과 HTTP 같은 웹 기술, 스프링 MVC
  • 서비스 계층
    • 비즈니스 로직을 담당
    • 주 사용 기술: 가급적 특정 기술에 의존하지 않고 순수 자바 코드로 작성
  • 데이터 접근 계층
    • 실제 데이터베이스에 접근하는 코드
    • 주 사용 기술: JDBC, JPA, Redis, ...

순수한 서비스 계층

여기서 가장 중요한 곳은 바로 핵심 비즈니스 로직이 있는 서비스 계층이다. 시간이 흘러서 UI(웹)와 관련된 부분이 변하고, 데이터 저장 기술을 다른 기술로 변경해도, 비즈니스 로직은 최대한 변경없이 유지되어야 한다. 이렇게 하려면 서비스 계층을 특정 기술에 종속적이지 않게 개발해야 한다. 위처럼 계층을 나눈 이유도 서비스 계층을 최대한 순수하게 유지하기 위한 목적이 크다. 기술에 종속적인 부분은 프레젠테이션 계층, 데이터 접근 계층에서 가지고 간다. 

  • 프레젠테이션 계층은 클라이언트가 접근하는 UI와 관련된 기술인 웹, 서블릿, HTTP와 관련된 부분을 담당해준다. 그래서 서비스 계층을 이런 UI와 관련된 기술로부터 보호해준다. 예를 들어서, HTTP API를 사용하다가 GRPC와 같은 기술로 변경해도 프레젠테이션 계층의 코드만 변경하고, 서비스 계층은 변경하지 않아도 된다.
  • 데이터 접근 계층은 데이터를 저장하고 관리하는 기술을 담당해준다. 그래서 JDBC, JPA와 같은 구체적인 데이터 접근 기술로부터 서비스 계층을 보호해준다. 예를 들어서 JDBC를 사용하다가 JPA로 변경해도 서비스 계층은 변경하지 않아도 된다. 물론 서비스 계층에서 데이터 접근 계층을 직접 접근하는 것이 아니라, 인터페이스를 제공하고 서비스 계층은 이 인터페이스에 의존하는 것이 좋다. 그래야 서비스 코드의 변경없이 JdbcRepositoryJpaRepository로 변경할 수 있다.

서비스 계층이 특정 기술에 종속되지 않기 때문에 비즈니스 로직을 유지보수 하기도 쉽고, 테스트하기도 쉽다. 정리하자면 서비스 계층은 가급적 비즈니스 로직만 구현하고 특정 구현 기술에 직접 의존해서는 안된다. 이렇게하면 향후 구현 기술이 변경될 때 변경의 영향 범위를 최소화할 수 있다.

 

 

그럼 서비스 계층을 순수하게 유지하는게 좋다는 것은 알았다. 지금까지 개발한 MemberService 코드들을 살펴보자.

MemberServiceV1

package cwchoiit.jdbc.service;

import cwchoiit.jdbc.domain.Member;
import cwchoiit.jdbc.repository.MemberRepositoryV1;
import lombok.RequiredArgsConstructor;

import java.sql.SQLException;

@RequiredArgsConstructor
public class MemberServiceV1 {

    private final MemberRepositoryV1 memberRepository;

    public void accountTransfer(String fromId, String toId, int money) throws SQLException {
        Member fromMember = memberRepository.findById(fromId);
        Member toMember = memberRepository.findById(toId);

        memberRepository.update(fromId, fromMember.getMoney() - money);

        validation(toMember);

        memberRepository.update(toId, toMember.getMoney() + money);
    }

    private void validation(Member toMember) {
        if (toMember.getMemberId().equals("ex")) {
            throw new IllegalStateException("이체중 예외 발생");
        }
    }
}
  • V1은 특정 기술에 거의 종속적이지 않고 순수한 비즈니스 로직만 존재한다.
  • 특정 기술과 관련된 코드가 거의 없어서 코드가 깔끔하고, 유지보수 하기 쉽다. 보면, MemberRepository에만 의존하고 있는데 이것 역시 특정 기술에 의존하는게 아니라 인터페이스에 의존하고 이 인터페이스를 구현한 구현체를 얼마든 갈아끼워도 상관이 없게 설계하면 된다.
  • 향후 비즈니스 로직의 변경이 필요하면 이 부분을 변경하면 된다.
  • 물론, 남은 문제가 있다 여기서도. 바로 SQLException을 의존하고 있다는 것. 이건 MemberRepository에서 올라오는 예외인데 원래라면 이 예외는 저 Repository에서 처리하는 게 맞다. 이것도 이후에 알아보자. 지금은 이 코드는 그저 예시를 위한 코드일뿐이다.

 

다음은 트랜잭션을 적용한 V2 코드를 살펴보자.

MemberServiceV2

package cwchoiit.jdbc.service;

import cwchoiit.jdbc.domain.Member;
import cwchoiit.jdbc.repository.MemberRepositoryV1;
import cwchoiit.jdbc.repository.MemberRepositoryV2;
import lombok.RequiredArgsConstructor;
import lombok.extern.slf4j.Slf4j;

import javax.sql.DataSource;
import java.sql.Connection;
import java.sql.SQLException;

@Slf4j
@RequiredArgsConstructor
public class MemberServiceV2 {

    private final DataSource dataSource;
    private final MemberRepositoryV2 memberRepository;

    public void accountTransfer(String fromId, String toId, int money) throws SQLException {
        Connection connection = dataSource.getConnection();

        try {
            connection.setAutoCommit(false);

            bizLogic(connection, fromId, toId, money);

            connection.commit();
        } catch (Exception e) {
            connection.rollback();
            throw new IllegalStateException(e);
        } finally {
            releaseConnection(connection);
        }
    }

    private void bizLogic(Connection connection, String fromId, String toId, int money) throws SQLException {
        Member fromMember = memberRepository.findById(connection, fromId);
        Member toMember = memberRepository.findById(connection, toId);

        memberRepository.update(connection, fromId, fromMember.getMoney() - money);

        validation(toMember);

        memberRepository.update(connection, toId, toMember.getMoney() + money);
    }

    private void releaseConnection(Connection connection) {
        if (connection != null) {
            try {
                connection.setAutoCommit(true);
                connection.close(); // 커넥션 풀을 사용할땐 close()가 반납
            } catch (Exception e) {
                log.error("error, ", e);
            }
        }
    }

    private void validation(Member toMember) {
        if (toMember.getMemberId().equals("ex")) {
            throw new IllegalStateException("이체중 예외 발생");
        }
    }
}
  • 트랜잭션은 비즈니스 로직이 있는 서비스 계층에서 시작하는 것이 좋다.
  • 그런데 문제는 트랜잭션을 사용하기 위해서 javax.sql.DataSource, java.sql.Connection, java.sql.SQLException 같은 JDBC 기술에 의존해야 한다는 점이다.
  • 트랜잭션을 사용하기 위해 JDBC 기술에 의존하고 있는 서비스 계층이다. 결과적으로 비즈니스 로직보다 JDBC를 사용해서 트랜잭션을 처리하는 코드가 더 많다.
  • 향후 JDBC에서 JPA로 기술을 변경하면 서비스 코드도 모두 함께 변경해야 한다.
  • 핵심 비즈니스 로직과 JDBC 기술이 섞여 있어서 유지보수가 어렵다.

문제를 정리해보면

  • 트랜잭션 문제
  • 예외 누수 문제
  • JDBC 반복 문제

이렇게 크게 세가지가 있다. 

 

트랜잭션 문제

가장 큰 문제는 트랜잭션을 적용하면서 생긴 다음과 같은 문제들이다.

  • JDBC 구현 기술이 서비스 계층에 누수되는 문제
    • 트랜잭션을 적용하기 위해 JDBC 구현 기술이 서비스 계층에 누수되었다.
    • 서비스 계층은 순수해야 한다. 구현 기술을 변경해도 서비스 계층 코드는 최대한 유지할 수 있어야 한다.
    • 서비스 계층은 특정 기술에 종속되지 않아야 한다. 지금까지 그렇게 열심히 노력해서 데이터 접근 계층으로 JDBC 관련 코드를 모았다(Repository 클래스에서 UPDATE, INSERT, DELETE, SELECT를 하는 등). 그런데 트랜잭션을 적용하면서 결국 서비스 계층에 JDBC 구현 기술의 누수가 발생했다.
  • 트랜잭션 동기화 문제
    • 같은 트랜잭션을 유지하기 위해 커넥션을 파라미터로 넘겨야 한다.
    • 이때 파생되는 문제도 있다. 똑같은 기능도 트랜잭션용 기능과 트랜잭션을 유지하지 않아도 되는 기능으로 분리해야 한다.
  • 트랜잭션 적용 반복 문제
    • 트랜잭션 적용 코드를 보면 반복이 많다. `try - catch - finally`...

 

예외 누수

  • 데이터 접근 계층의 JDBC 구현 기술 예외가 서비스 계층으로 전파되고 있다.
  • SQLException은 체크 예외이기 때문에 데이터 접근 계층을 호출한 서비스 계층에서 해당 예외를 잡아서 처리하거나 명시적으로 throws를 통해서 다시 던져야 한다.
  • SQLException은 JDBC 전용 기술이다. 향후 JPA나 다른 데이터 접근 기술을 사용하면, 그에 맞는 다른 예외로 변경해야 하고, 결국 서비스 코드도 모두 수정해야 한다.

 

JDBC 반복 문제

  • 지금까지 작성한 MemberRepository 코드는 순수한 JDBC 코드를 사용했다.
  • 근데 이 코드들은 유사한 코드의 반복이 너무 많다.
    • `try - catch - finally`
    • 커넥션을 열고, PreparedStatement를 사용하고, 결과를 매핑하고, 실행하고, 리소스를 정리하고.

 

 

이런 여러 문제가 있는데, 스프링은 지금 말한 모든 문제를 모두 아름답게 해결해준다. 이제 이 문제를 스프링을 사용해서 하나씩 해결해보자!

 

트랜잭션 추상화

현재 서비스 계층은 트랜잭션을 사용하기 위해서 JDBC 기술에 의존하고 있다. 향후 JDBC에서 JPA와 같은 다른 데이터 접근 기술로 변경하면, 서비스 계층의 트랜잭션 관련 코드도 모두 함께 수정해야 한다.

 

무슨 말이냐면, 구현 기술에 따라 트랜잭션 사용방법이 다 다르다.

  • JDBC: `con.setAutoCommit(false)`
  • JPA: `transaction.begin()`

JDBC 트랜잭션 의존

 

JDBC 기술 → JPA 기술로 변경

 

이렇게 JDBC 기술을 사용하다가 JPA로 기술을 변경하게 되면, 서비스 계층의 코드도 JPA 기술을 사용하도록 함께 수정해야 한다.

이런 문제를 해결하려면 트랜잭션 기능을 추상화하면 된다. 아주 단순하게 생각하면 다음과 같은 인터페이스를 만들어서 사용하면 된다.

public interface TxManager {
    begin();
    commit();
    rollback();
}
  • 트랜잭션은 사실 단순하다. 트랜잭션을 시작하고, 비즈니스 로직이 수행되고, 끝나면 커밋또는 롤백을 하면 된다.
  • 그리고 이 트랜잭션 매니저 인터페이스를 기반으로 아래와 같이 각각의 기술에 맞는 구현체를 만들면 된다.
    • JdbcTxManager: JDBC 트랜잭션 기능을 제공하는 구현체
    • JpaTxManager: JPA 트랜잭션 기능을 제공하는 구현체

  • 서비스는 특정 트랜잭션 기술에 직접 의존하는 것이 아니라, TxManager라는 추상화된 인터페이스에 의존한다.
  • 이제 원하는 구현체를 DI를 통해서 주입하면 된다. 예를 들어서 JDBC 트랜잭션 기능이 필요하면 JdbcTxManager를 서비스에 주입하고, JPA 트랜잭션 기능으로 변경해야 하면 JpaTxManager를 주입하면 된다. 
  • 클라이언트 서비스는 인터페이스에 의존하고 DI를 사용한 덕분에 OCP 원칙을 지키게 되었다. 이제 트랜잭션을 사용하는 서비스 코드를 전혀 변경하지 않고, 트랜잭션 기술을 마음껏 변경할 수 있다.

 

스프링의 트랜잭션 추상화

스프링은 이미 이런 고민을 다 해두었다. 우리는 스프링이 제공하는 트랜잭션 추상화 기술을 사용하면 된다. 심지어 데이터 접근 기술에 따른 트랜잭션 구현체도 대부분 만들어두어서 가져다가 사용만 하면 된다.

  • 스프링의 트랜잭션 추상화의 핵심은 PlatformTransactionManager 인터페이스이다.
  • org.springframework.transaction.PlatformTransactionManager
package org.springframework.transaction;

import org.springframework.lang.Nullable;

public interface PlatformTransactionManager extends TransactionManager {

	TransactionStatus getTransaction(@Nullable TransactionDefinition definition) throws TransactionException;

	void commit(TransactionStatus status) throws TransactionException;

	void rollback(TransactionStatus status) throws TransactionException;

}
  • getTransaction(): 트랜잭션을 시작한다. 이름이 getTransaction인 이유는 기존에 이미 진행중인 트랜잭션이 있는 경우 해당 트랜잭션에 참여할 수 있기 때문이다. 참고로 트랜잭션 참여, 전파에 대한 부분은 뒤에서 설명한다. 지금은 단순히 트랜잭션을 시작하는 것으로 이해하면 된다.
  • commit(): 트랜잭션을 커밋한다.
  • rollback(): 트랜잭션을 롤백한다.

앞으로, PlatformTransactionManager 인터페이스와 구현체를 포함해서 트랜잭션 매니저로 줄여서 이야기 하겠다.

 

트랜잭션 동기화

스프링이 제공하는 트랜잭션 매니저는 크게 2가지 역할을 한다.

  • 트랜잭션 추상화
  • 리소스 동기화

트랜잭션 추상화

바로 위에서 이야기 했다. PlatformTransactionManager를 사용해서 트랜잭션 기술을 추상화한다는 이야기.

 

리소스 동기화

트랜잭션을 유지하려면, 트랜잭션의 시작부터 끝까지 같은 데이터베이스 커넥션을 유지해야 한다. 결국 같은 커넥션을 동기화하기 위해서 이전에는 파라미터로 커넥션을 전달하는 방법을 사용했는데 이 방법은 코드가 지저분해지는 것은 물론이고, 커넥션을 넘기는 메서드와 넘기지 않는 메서드를 중복해서 만들어야 하는 등 여러가지 단점들이 있다.

 

커넥션과 세션

  • 이 그림을 보면 알 수 있듯, 하나의 커넥션이 하나의 세션을 가지고 있고 이 세션안에서 작업을 해야 하나의 작업으로 간주된다. 즉, 트랜잭션의 시작부터 끝까지 같은 데이터베이스 커넥션을 유지해야 하나의 작업에서 롤백과 커밋이 제대로 작동한다는 의미이다. 

트랜잭션 매니저와 트랜잭션 동기화 매니저

  • 그럼 트랜잭션을 동기화해야 하는데 스프링은 트랜잭션 동기화 매니저를 제공한다. 이것은 쓰레드 로컬(ThreadLocal)을 사용해서 커넥션을 동기화해준다. 트랜잭션 매니저는 내부에서 이 트랜잭션 동기화 매니저를 사용한다.
  • 트랜잭션 동기화 매니저는 쓰레드 로컬을 사용하기 때문에 멀티쓰레드 환경에서 안전하게 커넥션을 동기화할 수 있다. 따라서, 커넥션이 필요하면 트랜잭션 동기화 매니저를 통해 커넥션을 획득하면 된다. 따라서 이전처럼 파라미터로 커넥션을 넘기지 않아도 된다.

동작 방식

  1. 트랜잭션을 시작하려면 커넥션이 필요하다. 트랜잭션 매니저는 데이터소스를 통해 커넥션을 만들고 트랜잭션을 시작한다.
  2. 트랜잭션 매니저는 트랜잭션이 시작된 커넥션을 트랜잭션 동기화 매니저에 보관한다.
  3. 리포지토리는 트랜잭션 동기화 매니저에 보관된 커넥션을 꺼내서 사용한다. 따라서 파라미터로 커넥션을 전달하지 않아도 된다. 
  4. 트랜잭션이 종료되면 트랜잭션 매니저는 트랜잭션 동기화 매니저에 보관된 커넥션을 통해 트랜잭션을 종료하고 커넥션도 닫는다.
쓰레드 로컬을 사용하면 각각의 쓰레드마다 별도의 저장소가 부여된다. 따라서 해당 쓰레드만 해당 데이터에 접근할 수 있다.

 

 

트랜잭션 문제 해결 - 트랜잭션 매니저1

이제 본격적으로 애플리케이션 코드에 트랜잭션 매니저를 적용해보자.

MemberRepositoryV3

package cwchoiit.jdbc.repository;

import cwchoiit.jdbc.domain.Member;
import lombok.RequiredArgsConstructor;
import lombok.extern.slf4j.Slf4j;
import org.springframework.jdbc.datasource.DataSourceUtils;
import org.springframework.jdbc.support.JdbcUtils;

import javax.sql.DataSource;
import java.sql.*;
import java.util.NoSuchElementException;

/**
 * 트랜잭션 - 트랜잭션 매니저
 * DataSourceUtils.getConnection()
 * DataSourceUtils.releaseConnection()
 */
@Slf4j
@RequiredArgsConstructor
public class MemberRepositoryV3 {

    private final DataSource dataSource;

    public Member save(Member member) throws SQLException {
        String sql = "INSERT INTO member (member_id, money) VALUES (?, ?)";

        Connection connection = null;
        PreparedStatement stmt = null;

        try {
            connection = getConnection();
            stmt = connection.prepareStatement(sql);

            stmt.setString(1, member.getMemberId());
            stmt.setInt(2, member.getMoney());
            stmt.executeUpdate();
            return member;
        } catch (SQLException e) {
            log.error("DB Error", e);
            throw e;
        } finally {
            close(connection, stmt, null);
        }
    }

    public Member findById(String memberId) throws SQLException {
        String sql = "SELECT * FROM member WHERE member_id = ?";

        Connection connection = null;
        PreparedStatement stmt = null;
        ResultSet rs = null;

        try {
            connection = getConnection();
            stmt = connection.prepareStatement(sql);
            stmt.setString(1, memberId);

            rs = stmt.executeQuery();

            if (rs.next()) {
                Member member = new Member();
                member.setMemberId(rs.getString("member_id"));
                member.setMoney(rs.getInt("money"));
                return member;
            } else {
                throw new NoSuchElementException("Member not found with id = " + memberId);
            }
        } catch (SQLException e) {
            log.error("DB Error", e);
            throw e;
        } finally {
            close(connection, stmt, rs);
        }
    }

    public void update(String memberId, int money) throws SQLException {
        String sql = "UPDATE member SET money = ? WHERE member_id = ?";

        Connection connection = null;
        PreparedStatement stmt = null;

        try {
            connection = getConnection();
            stmt = connection.prepareStatement(sql);

            stmt.setInt(1, money);
            stmt.setString(2, memberId);
            int resultSize = stmt.executeUpdate();
            log.info("resultSize = {}", resultSize);
        } catch (SQLException e) {
            log.error("DB Error", e);
            throw e;
        } finally {
            close(connection, stmt, null);
        }
    }

    public void delete(String memberId) throws SQLException {
        String sql = "DELETE FROM member WHERE member_id = ?";

        Connection connection = null;
        PreparedStatement stmt = null;
        try {

            connection = getConnection();
            stmt = connection.prepareStatement(sql);

            stmt.setString(1, memberId);
            stmt.executeUpdate();
        } catch (SQLException e) {
            log.error("DB Error", e);
            throw e;
        } finally {
            close(connection, stmt, null);
        }
    }

    private void close(Connection connection, Statement stmt, ResultSet rs) {
        JdbcUtils.closeResultSet(rs);
        JdbcUtils.closeStatement(stmt);
        // 주의! 트랜잭션 동기화를 제대로 사용하려면 DataSourceUtils 를 사용해야 한다.
        DataSourceUtils.releaseConnection(connection, dataSource);
    }

    private Connection getConnection() throws SQLException {
        // 주의! 트랜잭션 동기화를 제대로 수행하려면, DataSourceUtils 를 사용해야 한다.
        Connection connection = DataSourceUtils.getConnection(dataSource);
        log.info("get connection = {}, class = {}", connection, connection.getClass());
        return connection;
    }
}
  • 우선 동일한 커넥션을 사용하기 위해 파라미터로 전달해야 했던 메서드는 모두 제거했다.
  • getConnection() → 이제 커넥션을 획득할때 DataSourceUtils를 사용해서 커넥션을 가져온다. 이 녀석은 트랜잭션 동기화 매니저가 관리하는 커넥션이 있으면 해당 커넥션을 반환하고, 없으면 새로운 커넥션을 생성해서 반환한다. 우리는 트랜잭션 매니저를 사용해야 하니까 당연히 이렇게 가져와야 한다.
  • close() → close()라는 메서드에서 자원을 정리하는데 커넥션의 경우, DataSourceUtils를 사용해서 releaseConnection()을 호출하고 있다. 이 부분을 주의해야 하는데, 만약 `connection.close()`로 커넥션을 직접 닫아버리면 커넥션이 유지가 되지 않는 문제가 발생한다. 커넥션은 이후 로직은 물론이고 트랜잭션이 종료될때까지 살아있어야 한다. 그러니까 커넥션을 레포지토리에서 닫으면 안된다는 얘기다. 그럼 releaseConnection()은 무엇을 할까?
    • 트랜잭션을 사용하기 위해 동기화된 커넥션은 커넥션을 닫지 않고 그대로 유지해준다. 
    • 트랜잭션 동기화 매니저가 관리하는 커넥션이 없는 경우 해당 커넥션을 닫는다.
  • 트랜잭션을 종료(롤백, 커밋)하는 시점은 트랜잭션을 시작하는 부분인 서비스 레이어에서 일어나야 한다! 

 

MemberServiceV3_1

package cwchoiit.jdbc.service;

import cwchoiit.jdbc.domain.Member;
import cwchoiit.jdbc.repository.MemberRepositoryV3;
import lombok.RequiredArgsConstructor;
import lombok.extern.slf4j.Slf4j;
import org.springframework.transaction.PlatformTransactionManager;
import org.springframework.transaction.TransactionStatus;
import org.springframework.transaction.support.DefaultTransactionDefinition;

import java.sql.SQLException;

@Slf4j
@RequiredArgsConstructor
public class MemberServiceV3_1 {

    private final PlatformTransactionManager transactionManager;
    private final MemberRepositoryV3 memberRepository;

    public void accountTransfer(String fromId, String toId, int money) throws SQLException {

        TransactionStatus transaction = transactionManager.getTransaction(new DefaultTransactionDefinition());

        try {
            bizLogic(fromId, toId, money);
            transactionManager.commit(transaction);
        } catch (Exception e) {
            transactionManager.rollback(transaction);
            throw new IllegalStateException(e);
        }
    }

    private void bizLogic(String fromId, String toId, int money) throws SQLException {
        Member fromMember = memberRepository.findById(fromId);
        Member toMember = memberRepository.findById(toId);

        memberRepository.update(fromId, fromMember.getMoney() - money);

        validation(toMember);

        memberRepository.update(toId, toMember.getMoney() + money);
    }

    private void validation(Member toMember) {
        if (toMember.getMemberId().equals("ex")) {
            throw new IllegalStateException("이체중 예외 발생");
        }
    }
}
  • PlatformTransactionManager를 주입받는 서비스 클래스가 생겼다. 이제 트랜잭션을 사용하는 기술이 JDBC이든, JPA이든 상관없이 구현체를 갈아끼워 주입만 시켜주면 이 서비스 코드는 수정할 필요가 전혀없이 기술을 변경할 수 있다.
  • transactionManager.getTransaction()으로 트랜잭션을 시작했다. 반환값은 TransactionStatus 타입을 반환하는데 현재 트랜잭션의 상태 정보가 포함되어 있다. 이 반환값은 이후 롤백 또는 커밋을 할 때 필요하다.
  • new DefaultTransactionDefinition() 이 녀석은 트랜잭션과 관련된 옵션을 지정할 수 있는데 자세한 내용은 뒤에서 설명한다.
  • transactionManager.commit(transaction) → 트랜잭션 내 모든 로직이 정상적으로 수행되면 커밋을 호출한다.
  • transactionManager.rollback(transaction) → 트랜잭션 내 로직 중 하나라도 실패하면 롤백을 호출한다.

 

MemberServiceV3_1Test

package cwchoiit.jdbc.service;

import cwchoiit.jdbc.domain.Member;
import cwchoiit.jdbc.repository.MemberRepositoryV2;
import cwchoiit.jdbc.repository.MemberRepositoryV3;
import org.junit.jupiter.api.AfterEach;
import org.junit.jupiter.api.BeforeEach;
import org.junit.jupiter.api.DisplayName;
import org.junit.jupiter.api.Test;
import org.springframework.jdbc.datasource.DataSourceTransactionManager;
import org.springframework.jdbc.datasource.DriverManagerDataSource;
import org.springframework.transaction.PlatformTransactionManager;

import java.sql.SQLException;

import static cwchoiit.jdbc.connection.ConnectionConst.*;
import static org.assertj.core.api.Assertions.assertThat;
import static org.assertj.core.api.Assertions.assertThatThrownBy;

class MemberServiceV3_1Test {

    public static final String MEMBER_A = "memberA";
    public static final String MEMBER_B = "memberB";
    public static final String MEMBER_EX = "ex";

    private MemberRepositoryV3 memberRepository;
    private MemberServiceV3_1 memberService;

    @BeforeEach
    void beforeEach() {
        DriverManagerDataSource dataSource = new DriverManagerDataSource(URL, USERNAME, PASSWORD);
        memberRepository = new MemberRepositoryV3(dataSource);

        PlatformTransactionManager transactionManager = new DataSourceTransactionManager(dataSource);
        memberService = new MemberServiceV3_1(transactionManager, memberRepository);
    }

    @AfterEach
    void afterEach() throws SQLException {
        memberRepository.delete(MEMBER_A);
        memberRepository.delete(MEMBER_B);
        memberRepository.delete(MEMBER_EX);
    }

    @Test
    @DisplayName("정상 이체")
    void accountTransfer() throws SQLException {
        Member memberA = new Member(MEMBER_A, 10000);
        Member memberB = new Member(MEMBER_B, 10000);

        memberRepository.save(memberA);
        memberRepository.save(memberB);

        memberService.accountTransfer(memberA.getMemberId(), memberB.getMemberId(), 2000);

        Member findMemberA = memberRepository.findById(memberA.getMemberId());
        Member findMemberB = memberRepository.findById(memberB.getMemberId());

        assertThat(findMemberA.getMoney()).isEqualTo(8000);
        assertThat(findMemberB.getMoney()).isEqualTo(12000);
    }

    @Test
    @DisplayName("이체 중 예외")
    void accountTransfer_ex() throws SQLException {
        Member memberA = new Member(MEMBER_A, 10000);
        Member memberEx = new Member(MEMBER_EX, 10000);

        memberRepository.save(memberA);
        memberRepository.save(memberEx);

        assertThatThrownBy(() -> memberService.accountTransfer(memberA.getMemberId(), memberEx.getMemberId(), 2000))
                .isInstanceOf(IllegalStateException.class);

        Member findMemberA = memberRepository.findById(memberA.getMemberId());
        Member findMemberEx = memberRepository.findById(memberEx.getMemberId());

        assertThat(findMemberA.getMoney()).isEqualTo(10000);
        assertThat(findMemberEx.getMoney()).isEqualTo(10000);
    }
}
  • 이제 테스트 코드를 통해 제대로 수행되는지 확인하자. 가장 중요한 부분은 초기화 코드이다.
@BeforeEach
void beforeEach() {
    DriverManagerDataSource dataSource = new DriverManagerDataSource(URL, USERNAME, PASSWORD);
    memberRepository = new MemberRepositoryV3(dataSource);

    PlatformTransactionManager transactionManager = new DataSourceTransactionManager(dataSource);
    memberService = new MemberServiceV3_1(transactionManager, memberRepository);
}
  • 우리는 지금 JDBC 기술을 사용중이므로, JDBC용 트랜잭션 매니저인 DataSourceTransactionManager를 구현체로 사용해야 한다. 그리고 이 구현체를 MemberServiceV3_1에 주입한다. 
  • 트랜잭션 매니저는 내부에서 데이터소스를 통해 커넥션을 획득하므로 DataSource가 필요하다.
  • 테스트를 실행하면 정상적으로 수행되는 것을 확인할 수 있다.

트랜잭션 문제 해결 - 트랜잭션 매니저2

그림으로 트랜잭션 매니저의 전체 동작 흐름을 자세히 이해해보자.

트랜잭션 매니저 - 트랜잭션 시작

  • 클라이언트의 요청으로 서비스 로직을 실행한다.
  • 서비스 계층에서 transactionManager.getTransaction()을 호출해서 트랜잭션을 시작한다.
  • 트랜잭션을 시작하려면 먼저 데이터베이스 커넥션이 필요하다. 트랜잭션 매니저는 내부에서 데이터소스를 사용해서 커넥션을 생성한다.
  • 커넥션을 수동 커밋 모드로 변경해서 실제 데이터베이스 트랜잭션을 시작한다.
  • 커넥션을 트랜잭션 동기화 매니저에 보관한다.
  • 트랜잭션 동기화 매니저는 쓰레드 로컬에 커넥션을 보관한다. 따라서, 멀티쓰레드 환경에 안전하게 커넥션을 보관할 수 있다.

트랜잭션 매니저 - 로직 실행

  • 서비스는 비즈니스 로직을 실행하면서 레포지토리의 메서드들을 호출한다. 이때, 이제는 커넥션을 파라미터로 전달하지 않는다.
  • 레포지토리 메서드들은 트랜잭션이 시작된 커넥션이 필요하다. 레포지토리는 DataSourceUtils.getConnection()을 사용해서 트랜잭션 동기화 매니저에 보관된 커넥션을 꺼내서 사용한다. 이 과정을 통해서 자연스럽게 같은 커넥션을 사용하고, 트랜잭션도 유지된다.
  • 획득한 커넥션을 사용해서 SQL을 데이터베이스에 전달해서 실행한다.

트랜잭션 매니저 - 트랜잭션 종료

  • 비즈니스 로직이 끝나고 트랜잭션을 종료한다. 트랜잭션은 커밋하거나 롤백하면 종료된다.
  • 트랜잭션을 종료하려면 동기화된 커넥션이 필요하다. 트랜잭션 동기화 매니저를 통해 동기화된 커넥션을 획득한다.
  • 획득한 커넥션을 통해 데이터베이스에 트랜잭션을 커밋하거나 롤백한다.
  • 전체 리소스를 정리한다.
    • 트랜잭션 동기화 매니저를 정리한다. 쓰레드 로컬은 사용 후 꼭 정리해야 한다.
    • conn.setAutoCommit(true)로 되돌린다. 커넥션 풀을 고려해야 한다.
    • conn.close()를 호출해서 커넥션을 종료한다. 커넥션 풀을 사용하는 경우, conn.close()를 호출하면 커넥션 풀에 반환된다.

 

정리를 하자면

  • 트랜잭션 추상화 덕분에 서비스 코드는 이제 JDBC 기술에 의존하지 않고, PlatformTransactionManager에 의존한다. 따라서, 향후 JDBC에서 JPA로 기술을 변경해도 DataSourceTransactionManager에서 JpaTransactionManager로 구현체만 갈아끼워주면 서비스 코드에는 아무런 변경도 할 필요가 없다.
  • 트랜잭션 동기화 매니저 덕분에 커넥션을 파라미터로 넘기지 않아도 된다.

트랜잭션 문제 해결 - 트랜잭션 템플릿

아직 남은 문제가 있다. 위 코드를 살펴보면 다음과 같은 패턴이 반복된다.

public void accountTransfer(String fromId, String toId, int money) throws SQLException {

    TransactionStatus transaction = transactionManager.getTransaction(new DefaultTransactionDefinition());

    try {
        bizLogic(fromId, toId, money);
        transactionManager.commit(transaction);
    } catch (Exception e) {
        transactionManager.rollback(transaction);
        throw new IllegalStateException(e);
    }
}
  • 트랜잭션을 시작한다. 
  • 성공하면 커밋한다.
  • 실패하면 롤백한다.
  • try - catch 구문
  • 모든 서비스에서 이 형태의 코드가 반복될 것이다. 

이럴때 템플릿 콜백 패턴을 활용하면 이런 문제를 해결할 수가 있다.

 

트랜잭션 템플릿

템플릿 콜백 패턴을 적용하려면 템플릿을 제공하는 클래스를 작성해야 한다. 그런데 스프링은 또 우리를 위해 TransactionTemplate이라는 템플릿 클래스를 제공한다.

public class TransactionTemplate {
  private PlatformTransactionManager transactionManager;
  public <T> T execute(TransactionCallback<T> action){..}
  void executeWithoutResult(Consumer<TransactionStatus> action){..}
}
  • execute() → 응답값이 있을 때 사용한다.
  • executeWithoutResult() → 응답값이 없을 때 사용한다.

MemberServiceV3_2

package cwchoiit.jdbc.service;

import cwchoiit.jdbc.domain.Member;
import cwchoiit.jdbc.repository.MemberRepositoryV3;
import lombok.RequiredArgsConstructor;
import lombok.extern.slf4j.Slf4j;
import org.springframework.transaction.PlatformTransactionManager;
import org.springframework.transaction.TransactionStatus;
import org.springframework.transaction.support.DefaultTransactionDefinition;
import org.springframework.transaction.support.TransactionTemplate;

import java.sql.SQLException;

@Slf4j
public class MemberServiceV3_2 {

    private final TransactionTemplate transactionTemplate;
    private final MemberRepositoryV3 memberRepository;

    public MemberServiceV3_2(PlatformTransactionManager transactionManager, MemberRepositoryV3 memberRepository) {
        this.transactionTemplate = new TransactionTemplate(transactionManager);
        this.memberRepository = memberRepository;
    }

    public void accountTransfer(String fromId, String toId, int money) throws SQLException {
        transactionTemplate.executeWithoutResult(status -> {
            try {
                bizLogic(fromId, toId, money);
            } catch (SQLException e) {
                throw new IllegalStateException(e);
            }
        });
    }

    private void bizLogic(String fromId, String toId, int money) throws SQLException {
        Member fromMember = memberRepository.findById(fromId);
        Member toMember = memberRepository.findById(toId);

        memberRepository.update(fromId, fromMember.getMoney() - money);

        validation(toMember);

        memberRepository.update(toId, toMember.getMoney() + money);
    }

    private void validation(Member toMember) {
        if (toMember.getMemberId().equals("ex")) {
            throw new IllegalStateException("이체중 예외 발생");
        }
    }
}
  • TransactionTemplate을 사용하려면 TransactionManager가 필요하다. 생성자에서 TransactionManager를 주입 받으면서 TransactionTemplate을 생성했다.
  • 트랜잭션 템플릿 사용한 코드를 보자.
public void accountTransfer(String fromId, String toId, int money) throws SQLException {
    transactionTemplate.executeWithoutResult(status -> {
        try {
            bizLogic(fromId, toId, money);
        } catch (SQLException e) {
            throw new IllegalStateException(e);
        }
    });
}
  • 굉장히 깔끔하게 딱 비즈니스 로직만 작성해도 되게끔 변경됐다.
  • 트랜잭션을 시작하거나, 커밋, 롤백하는 부분도 다 없어졌다.
  • 트랜잭션 템플릿의 기본 동작은 비즈니스 로직이 정상 수행되면 커밋하고, 언체크 예외가 발생하면 롤백한다. 그 외의 경우(체크 예외가 발생하는 경우나 정상적으로 끝나는 경우)에는 커밋한다. 기본 흐름이 그렇다. 이 또한 변경할수도 있다.
  • 그런데 살짝 아쉬운 부분은 bizLogic 자체가 SQLException을 던지기 때문에 그것을 잡아줘야 하는 try - catch 구문이 들어간다. 만약 로직을 언체크 예외로 작성했다면 이 부분도 없어질 것이다. 이건 뒤에서 차차 알아보자.

 

정리를 하자면

  • 트랜잭션 템플릿을 사용하니 반복하는 코드를 최대한 제거할 수 있었다.
  • 하지만, 여전히 서비스 로직에 비즈니스 로직뿐만 아니라 트랜잭션을 처리하는 기술인 트랜잭션 템플릿 코드가 함께 포함되어 있다.
  • 즉, 두 관심사가 동시에 로직에 쓰여지고 있다는 말인데 이걸 어떻게 깔끔하게 서비스 코드에는 비즈니스 로직만 남겨두게 할 수 있을까?

 

트랜잭션 문제 해결 - 트랜잭션 AOP 이해

  • 지금까지 트랜잭션을 편리하게 처리하기 위해 트랜잭션 추상화도 도입하고, 추가로 반복적인 트랜잭션 로직을 해결하기 위해 트랜잭션 템플릿도 도입했다.
  • 트랜잭션 템플릿 덕분에 트랜잭션을 처리하는 반복적인 코드는 해결할 수 있었다. 하지만, 서비스 계층에 순수한 비즈니스 로직만 남긴다는 목표는 아직 달성하지 못했다.
  • 이럴때, 스프링 AOP를 통해 프록시를 도입하면 문제를 깔끔하게 해결할 수 있다.

 

프록시를 통한 문제 해결

프록시 도입 전

프록시를 도입하기 전에는 이렇듯 서비스의 로직에서 트랜잭션을 직접 시작한다.

 

프록시 도입 후

프록시를 사용하면 트랜잭션을 처리하는 객체와 비즈니스 로직을 처리하는 서비스 객체를 명확하게 분리할 수 있다.

이 내용의 깊은 부분은 스프링 AOP에 대해 완전히 이해해야 한다. 그 부분에 대한 내용 역시 포스팅으로 정리해 두었다. 

 

트랜잭션 문제 해결 - 트랜잭션 AOP 적용

MemberServiceV3_3

package cwchoiit.jdbc.service;

import cwchoiit.jdbc.domain.Member;
import cwchoiit.jdbc.repository.MemberRepositoryV3;
import lombok.RequiredArgsConstructor;
import lombok.extern.slf4j.Slf4j;
import org.springframework.transaction.PlatformTransactionManager;
import org.springframework.transaction.annotation.Transactional;
import org.springframework.transaction.support.TransactionTemplate;

import java.sql.SQLException;

@Slf4j
@RequiredArgsConstructor
public class MemberServiceV3_3 {

    private final MemberRepositoryV3 memberRepository;

    @Transactional
    public void accountTransfer(String fromId, String toId, int money) throws SQLException {
        bizLogic(fromId, toId, money);
    }

    private void bizLogic(String fromId, String toId, int money) throws SQLException {
        Member fromMember = memberRepository.findById(fromId);
        Member toMember = memberRepository.findById(toId);

        memberRepository.update(fromId, fromMember.getMoney() - money);

        validation(toMember);

        memberRepository.update(toId, toMember.getMoney() + money);
    }

    private void validation(Member toMember) {
        if (toMember.getMemberId().equals("ex")) {
            throw new IllegalStateException("이체중 예외 발생");
        }
    }
}
  • 순수한 비즈니스 로직만 남기고, 트랜잭션 관련 코드는 모두 제거됐다.
  • 스프링이 제공하는 트랜잭션 AOP를 적용하기 위해 @Transactional 애노테이션을 추가했다.
  • @Transactional 애노테이션은 메서드에 붙여도 되고, 클래스에 붙여도 된다. 클래스에 붙이면 외부에서 호출 가능한 public 메서드가 AOP 적용 대상이 된다.

 

MemberServiceV3_3Test

package cwchoiit.jdbc.service;

import cwchoiit.jdbc.domain.Member;
import cwchoiit.jdbc.repository.MemberRepositoryV3;
import lombok.extern.slf4j.Slf4j;
import org.junit.jupiter.api.AfterEach;
import org.junit.jupiter.api.BeforeEach;
import org.junit.jupiter.api.DisplayName;
import org.junit.jupiter.api.Test;
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.boot.test.context.SpringBootTest;
import org.springframework.boot.test.context.TestConfiguration;
import org.springframework.context.annotation.Bean;
import org.springframework.jdbc.datasource.DataSourceTransactionManager;
import org.springframework.jdbc.datasource.DriverManagerDataSource;
import org.springframework.transaction.PlatformTransactionManager;

import javax.sql.DataSource;
import java.sql.SQLException;

import static cwchoiit.jdbc.connection.ConnectionConst.*;
import static org.assertj.core.api.Assertions.assertThat;
import static org.assertj.core.api.Assertions.assertThatThrownBy;

@Slf4j
@SpringBootTest
class MemberServiceV3_3Test {

    public static final String MEMBER_A = "memberA";
    public static final String MEMBER_B = "memberB";
    public static final String MEMBER_EX = "ex";

    @Autowired
    private MemberRepositoryV3 memberRepository;

    @Autowired
    private MemberServiceV3_3 memberService;

    @TestConfiguration
    static class TestContextConfiguration {
        @Bean
        DataSource dataSource() {
            return new DriverManagerDataSource(URL, USERNAME, PASSWORD);
        }

        @Bean
        PlatformTransactionManager transactionManager() {
            return new DataSourceTransactionManager(dataSource());
        }

        @Bean
        MemberRepositoryV3 memberRepository() {
            return new MemberRepositoryV3(dataSource());
        }

        @Bean
        MemberServiceV3_3 memberService() {
            return new MemberServiceV3_3(memberRepository());
        }
    }

    @AfterEach
    void afterEach() throws SQLException {
        memberRepository.delete(MEMBER_A);
        memberRepository.delete(MEMBER_B);
        memberRepository.delete(MEMBER_EX);
    }

    @Test
    @DisplayName("정상 이체")
    void accountTransfer() throws SQLException {
        Member memberA = new Member(MEMBER_A, 10000);
        Member memberB = new Member(MEMBER_B, 10000);

        memberRepository.save(memberA);
        memberRepository.save(memberB);

        memberService.accountTransfer(memberA.getMemberId(), memberB.getMemberId(), 2000);

        Member findMemberA = memberRepository.findById(memberA.getMemberId());
        Member findMemberB = memberRepository.findById(memberB.getMemberId());

        assertThat(findMemberA.getMoney()).isEqualTo(8000);
        assertThat(findMemberB.getMoney()).isEqualTo(12000);
    }

    @Test
    @DisplayName("이체 중 예외")
    void accountTransfer_ex() throws SQLException {
        Member memberA = new Member(MEMBER_A, 10000);
        Member memberEx = new Member(MEMBER_EX, 10000);

        memberRepository.save(memberA);
        memberRepository.save(memberEx);

        assertThatThrownBy(() -> memberService.accountTransfer(memberA.getMemberId(), memberEx.getMemberId(), 2000))
                .isInstanceOf(IllegalStateException.class);

        Member findMemberA = memberRepository.findById(memberA.getMemberId());
        Member findMemberEx = memberRepository.findById(memberEx.getMemberId());

        assertThat(findMemberA.getMoney()).isEqualTo(10000);
        assertThat(findMemberEx.getMoney()).isEqualTo(10000);
    }
}
  • 스프링 AOP를 적용한 테스트를 하기 위해서는 @SpringBootTest 애노테이션을 붙여줘야 테스트를 실행할 때 스프링이 띄워진다. 그리고 @Autowired 애노테이션으로 필요한 빈들을 주입받을 수 있다.
  • @TestConfiguration 애노테이션은 테스트 안에서 내부 설정 클래스를 만들어서 사용하면서 이 애노테이션을 붙이면, 스프링 부트가 자동으로 만들어주는 빈들에 추가적으로 필요한 스프링 빈들을 등록하고 테스트를 수행할 수 있다.
  • 테스트를 실행해보면, 정상적으로 수행되는 것을 확인할 수 있다.

 

 

728x90
반응형
LIST
728x90
반응형
SMALL

참고자료:

 

스프링 DB 1편 - 데이터 접근 핵심 원리 강의 | 김영한 - 인프런

김영한 | 백엔드 개발에 필요한 DB 데이터 접근 기술을 기초부터 이해하고, 완성할 수 있습니다. 스프링 DB 접근 기술의 원리와 구조를 이해하고, 더 깊이있는 백엔드 개발자로 성장할 수 있습니

www.inflearn.com

 

트랜잭션 개념 이해

데이터를 저장할 때 단순히 파일에 저장해도 되는데, 데이터베이스에 저장하는 이유는 무엇일까? 여러가지 이유가 있지만, 가장 대표적인 이유는 바로 데이터베이스는 트랜잭션이라는 개념을 지원하기 때문이다.

 

트랜잭션을 이름 그대로 번역하면 거래라는 뜻이다. 이것을 쉽게 풀어서 이야기하면, 데이터베이스에서 트랜잭션은 하나의 거래를 안전하게 처리하도록 보장해주는 것을 뜻한다. 그런데 하나의 거래를 안전하게 처리하려면 생각보다 고려해야 할 점이 많다. 예를 들어, A의 5000원을 B에게 계좌이체한다고 생각해보자. A의 잔고를 5000원 감소하고, B의 잔고를 5000원 증가해야 한다.

 

5000원 계좌 이체

  1. A의 잔고를 5000원 감소
  2. B의 잔고를 5000원 증가

계좌이체라는 거래는 이렇게 2가지 작업이 합쳐져서 하나의 작업처럼 동작해야 한다. 만약, 1번은 성공했는데 2번에서 시스템에 문제가 발생하면 계좌이체는 실패하고 A의 잔고만 5000원 감소하는 심각한 문제가 발생한다. 데이터베이스가 제공하는 트랜잭션 기능을 사용하면, 1번과 2번 둘 다 함께 성공해야 저장하고, 중간에 하나라도 실패하면 거래전의 상태로 돌아갈 수 있다. 만약, 1번은 성공했는데 2번에서 시스템에 문제가 발생하면 계좌이체는 실패하고 거래 전의 상태로 완전히 돌아갈 수 있다. 결과적으로 A의 잔고가 감소하지 않는다.

 

모든 작업이 성공해서 데이터베이스에 정상 반영하는 것을 커밋(Commit)이라 하고, 작업 중 하나라도 실패해서 거래 이전으로 되돌리는 것을 롤백(Rollback)이라 한다.

 

트랜잭션 ACID

트랜잭션은 ACID라 하는 원자성(Atomicity), 일관성(Consistency), 격리성(Isolation), 지속성(Durability)을 보장해야 한다.

  • 원자성: 트랜잭션 내에서 실행한 작업들은 마치 하나의 작업인 것처럼 모두 성공하거나 모두 실패해야 한다.
  • 일관성: 모든 트랜잭션은 일관성 있는 데이터베이스 상태를 유지해야 한다. 예를 들어, 데이터베이스에서 정한 무결성 제약 조건을 항상 만족해야 한다.
  • 격리성: 동시에 실행되는 트랜잭션들이 서로에게 영향을 미치지 않도록 격리한다. 예를 들어, 동시에 같은 데이터를 수정하지 못하도록 해야 한다. 격리성은 동시성과 관련된 성능 이슈로 인해 트랜잭션 격리 수준(Isolation Level)을 선택할 수 있다.
  • 지속성: 트랜잭션을 성공적으로 끝내고 나면 그 결과가 항상 기록되어야 한다. 중간에 시스템에 문제가 발생해도 데이터베이스 로그 등을 사용해서 성공한 트랜잭션 내용을 복구해야 한다.

트랜잭션 격리 수준(Isolation Level)

  • READ UNCOMMITED - 커밋되지 않은 읽기
  • READ COMMITED - 커밋된 읽기
  • REPEATABLE READ - 반복 가능한 읽기
  • SERIALIZABLE - 직렬화 가능

 

데이터베이스 연결 구조와 DB 세션

트랜잭션을 더 자세히 이해하기 위해 데이터베이스 서버 연결 구조와 DB 세션에 대해 알아보자.

  • 사용자는 웹 애플리케이션 서버(WAS)나 DB 접근 툴 같은 클라이언트를 사용해서 데이터베이스 서버에 접근할 수 있다. 클라이언트는 데이터베이스 서버에 연결을 요청하고 커넥션을 맺게 된다. 이때 데이터베이스 서버는 내부에 세션이라는 것을 만든다. 그리고 앞으로 해당 커넥션을 통한 모든 요청은 이 세션을 통해서 실행하게 된다.
  • 쉽게 이야기해서, 개발자가 클라이언트를 통해 SQL을 전달하면 현재 커넥션에 연결된 세션이 SQL을 실행한다.
  • 세션은 트랜잭션을 시작하고, 커밋 또는 롤백을 통해 트랜잭션을 종료한다. 그리고 이후에 새로운 트랜잭션을 다시 시작할 수 있다.
  • 사용자가 커넥션을 닫거나, 또는 DBA가 세션을 강제로 종료하면 세션은 종료된다.

  • 커넥션 풀이 10개의 커넥션을 생성하면, 세션도 10개가 만들어진다. 

트랜잭션 DB 예제1 - 개념 이해

트랜잭션 동작을 예제를 통해 확인해보자. 이번 시간에는 먼저 트랜잭션의 동작 개념의 전체 그림을 이해하는데 집중하자. 

참고로, 지금부터 설명하는 내용은 트랜잭션 개념의 이해를 돕기 위해 예시로 설명하는 것이다. 구체적인 실제 구현 방식은 데이터베이스마다 다르다. 

 

트랜잭션 사용법

  • 데이터 변경 쿼리를 실행하고 데이터베이스에 그 결과를 반영하려면 커밋 명령어인 `commit`을 호출하고, 결과를 반영하고 싶지 않으면 롤백 명령어인 `rollback`을 호출하면 된다.
  • 커밋을 호출하기 전까지는 임시로 데이터를 저장하는 것이다. 따라서 해당 트랜잭션을 시작한 세션(사용자)에게만 변경 데이터가 보이고 다른 세션(사용자)에게는 변경 데이터가 보이지 않는다.
  • 등록, 수정, 삭제 모두 같은 원리로 동작한다. 앞으로는 등록, 수정, 삭제를 간단히 변경이라는 단어로 표현하겠다.

  • 세션1, 세션2 둘 다 가운데 있는 기본 테이블을 조회하면 해당 데이터가 그대로 조회된다.

 

세션1에서 신규 데이터 추가

  • 세션1은 트랜잭션을 시작하고 신규 회원1, 신규 회원2를 DB에 추가했다. 아직 커밋은 하지 않은 상태이다.
  • 새로운 데이터는 임시 상태로 저장된다.
  • 세션1은 SELECT 쿼리를 실행해서 본인이 입력한 신규 회원1, 신규 회원2를 조회할 수 있다.
  • 세션2는 SELECT 쿼리를 실행해도 신규 회원들을 조회할 수 없다. 왜냐하면 세션1이 아직 커밋을 하지 않았기 때문이다.

커밋하지 않은 데이터를 다른 곳에서 조회할 수 있으면 어떤 문제가 발생할까?

  • 예를 들어, 커밋하지 않은 데이터가 보인다면, 세션2는 데이터를 조회했을 때 신규 회원1, 2가 보일 것이다. 따라서 신규 회원1, 신규 회원2가 있다고 가정하고 어떤 로직을 수행할 수 있다. 그런데 세션1이 롤백을 수행하면 신규 회원1, 신규 회원2의 데이터가 사라질 것이다. 따라서 데이터 정합성에 큰 문제가 생긴다.
  • 세션2에서 세션1이 아직 커밋하지 않은 변경 데이터가 보인다면, 세션1이 롤백했을 때 심각한 문제가 발생할 수 있다. 따라서 커밋 전의 데이터는 다른 세션에서 보이면 안된다!

세션1 신규 데이터 추가 후 커밋

  • 세션1이 신규 데이터를 추가한 후 커밋을 호출했다.
  • 커밋으로 새로운 데이터가 실제 데이터베이스에 반영된다. 데이터의 상태도 임시에서 완료로 변경되었다.
  • 이제 다른 세션에서도 회원 테이블을 조회하면 신규 회원들을 확인할 수 있다.

 

세션1 신규 데이터 추가 후 롤백

  • 세션1이 신규 데이터를 추가한 후에 커밋 대신 롤백을 호출했다.
  • 세션1이 데이터베이스에 반영한 모든 데이터가 트랜잭션을 시작하기 직전의 상태로 복구된다.
  • 수정하거나 삭제한 데이터도 롤백을 호출하면 모두 트랜잭션을 시작하기 직전의 상태로 복구된다.

 

트랜잭션 - 자동 커밋, 수동 커밋

자동 커밋

트랜잭션을 사용하려면, 먼저 자동 커밋과 수동 커밋을 이해해야 한다. 자동 커밋으로 설정하면 각각의 쿼리 실행 직후에 자동으로 커밋을 호출한다. 따라서 커밋이나 롤백을 직접 호출하지 않아도 되는 편리함이 있다. 하지만 쿼리를 하나하나 실행할 때마다 자동으로 커밋이 되어버리기 때문에 우리가 원하는 트랜잭션 기능을 제대로 사용할 수 없다.

 

자동 커밋 설정

set autocommit true; //자동 커밋 모드 설정
insert into member(member_id, money) values ('data1',10000); //자동 커밋 
insert into member(member_id, money) values ('data2',10000); //자동 커밋

 

수동 커밋 설정

set autocommit false; //수동 커밋 모드 설정
insert into member(member_id, money) values ('data3',10000); 
insert into member(member_id, money) values ('data4',10000); 
commit; //수동 커밋

 

보통은 자동 커밋 모드가 기본으로 설정된 경우가 많기 때문에, 수동 커밋 모드로 설정하는 것을 트랜잭션을 시작한다고 표현한다. 수동 커밋 설정을 하면 이후에 꼭 commit, rollback 둘 중 하나를 호출해야 한다. 참고로 수동 커밋 모드나 자동 커밋 모드는 한번 설정하면 해당 세션에서는 계속 유지된다. 중간에 변경하는 것은 가능하다. 

 

만약, 자동 커밋 모드로 동작하는데 계좌이체 중간에 실패하면 어떻게 될까? 쿼리를 하나 실행할 때마다 바로바로 커밋이 되어버리기 때문에 특정 유저의 돈만 빠져나가는 심각한 문제가 발생한다. 이는 데이터베이스에서 가장 중요한 성질 중 하나인 원자성을 위배하는 것이다.

 

원자성: 트랜잭션 내에서 실행한 작업은 마치 하나의 작업인 것처럼 모두 성공하거나 모두 실패해야 한다. 

 

그렇기 때문에, 자동 커밋이 아닌 수동 커밋으로 설정하고 모든 작업이 성공적으로 끝나면 커밋을, 하나라도 실패하면 모두 되돌리는 롤백을 하여 트랜잭션의 원자성 기능을 최대한 사용해야 한다. 

 

DB 락 개념 이해

세션1이 트랜잭션을 시작하고 데이터를 수정하는 동안 아직 커밋을 수행하지 않았는데, 세션2에서 동시에 같은 데이터를 수정하게 되면 여러가지 문제가 발생한다. 바로 트랜잭션의 원자성이 깨지는 것이다. 여기에 더해서 세션1이 중간에 롤백을 하게 되면, 세션2는 잘못된 데이터를 수정하는 문제가 발생한다. 이런 문제를 방지하려면, 세션이 트랜잭션을 시작하고 데이터를 수정하는 동안에는 커밋이나 롤백 전까지 다른 세션에서 해당 데이터를 수정할 수 없게 막아야 한다. 

 

이런 문제를 바로 이라는 개념이 해결한다.

  • 세션1은 memberA의 금액을 500원으로 변경하고 싶고, 세션2는 같은 memberA의 금액을 1000원으로 변경하고 싶다.
  • 데이터베이스는 이런 문제를 해결하기 위해 락(Lock)이라는 개념을 제공한다.
  • 다음 예시를 통해 동시에 데이터를 수정하는 문제를 락으로 어떻게 해결하는지 자세히 알아보자.

  • 세션1은 트랜잭션을 시작한다.
  • 세션1은 memberAmoney를 500으로 변경을 시도한다. 이때, 해당 로우의 락을 먼저 획득해야 한다. 락이 남아 있으므로 세션1은 락을 획득한다. (세션1이 간발의 차이로 세션2보다 먼저 요청했다)
  • 세션1은 락을 획득했으므로 해당 로우에 UPDATE 쿼리를 수행한다.

  • 세션2는 트랜잭션을 시작한다.
  • 세션2도 memberAmoney 데이터를 변경하려고 시도한다. 이때, 해당 로우의 락을 먼저 획득해야 한다.
  • 그런데 락이 없다. 락이 돌아올 때까지 대기한다.
  • 참고로 세션2가 락을 무한정 대기하는 것은 아니다. 락 대기 시간을 넘어가면 락 타임아웃 오류가 발생한다. 락 대기 시간은 설정할 수 있다. 락을 대기하다가 락 대기 시간을 넘어가면 아래와 같은 에러 메시지를 확인할 수 있다. (H2 데이터베이스 기준)
  Timeout trying to lock table {0}; SQL statement:
  update member set money=10000 - 2000 where member_id = 'memberA' [50200-200]
  HYT00/50200

  • 세션1은 커밋을 수행한다. 커밋으로 트랜잭션이 종료되었으므로 락도 반납한다.

  • 락을 획득하기 위해 대기하던 세션2가 락을 획득한다.

  • 세션2는 UPDATE 쿼리를 수행한다.

  • 세션2는 커밋을 수행하고 트랜잭션이 종료되었으므로 락을 반납한다.

 

DB 락 - 조회

일반적인 조회는 락을 사용하지 않는다.

  • 데이터베이스마다 다르지만, 보통 데이터를 조회할 때는 락을 획득하지 않고 바로 데이터를 조회할 수 있다. 예를 들어서 세션1이 락을 획득하고 데이터를 변경하고 있어도, 세션2에서 데이터를 조회할 수 있다. 물론 세션2에서 조회가 아니라 데이터를 변경하려면 락이 필요하기 때문에 락이 돌아올 때까지 대기해야 한다. 

조회와 락

  • 데이터를 조회할 때도 락을 획득하고 싶을 때가 있다. 이럴 때는 SELECT .. FOR UPDATE 구문을 사용하면 된다.
  • 이렇게 하면 세션1이 조회 시점에 락을 가져가버리기 때문에 다른 세션에서 해당 데이터를 변경할 수 없다.
  • 물론 이 경우도 트랜잭션을 커밋하면 락을 반납한다. 
  • 또한, 세션1에서 SELECT ... FOR UPDATE 쿼리를 실행할 때, 락이 없으면 락이 돌아올 때까지 세션1은 대기한다.

그럼 조회 시점에 왜 필요할까?

  • 트랜잭션 종료 시점까지 해당 데이터를 다른 곳에서 변경하지 못하도록 강제로 막아야 할 때 사용한다.
  • 예를 들어, 애플리케이션 로직에서 memberA의 금액을 조회한 다음에 이 금액 정보로 애플리케이션에서 어떤 중요한 계산을 수행한다. 그런데 이 계산이 매우 중요한 계산이라 계산이 완료될 때까지 memberA의 금액을 다른곳에서 변경하면 안된다. 이럴때, 조회 시점에 락을 획득하면 된다.
SELECT * 
FROM member 
WHERE member_id='memberA' FOR UPDATE;

 

 

트랜잭션 - 자바 예제1

실제 애플리케이션에서 DB 트랜잭션을 사용해서 계좌이체와 같은 원자성이 중요한 비즈니스 로직을 어떻게 구현하는지 알아보자. 그런데 일단 트랜잭션 없이 단순하게 계좌이체 비즈니스 로직만 구현해보자. 즉, 오토커밋이라는 말이다.

 

MemberServiceV1

package cwchoiit.jdbc.service;

import cwchoiit.jdbc.domain.Member;
import cwchoiit.jdbc.repository.MemberRepositoryV1;
import lombok.RequiredArgsConstructor;

import java.sql.SQLException;

@RequiredArgsConstructor
public class MemberServiceV1 {

    private final MemberRepositoryV1 memberRepository;

    public void accountTransfer(String fromId, String toId, int money) throws SQLException {
        Member fromMember = memberRepository.findById(fromId);
        Member toMember = memberRepository.findById(toId);

        memberRepository.update(fromId, fromMember.getMoney() - money);

        validation(toMember);

        memberRepository.update(toId, toMember.getMoney() + money);
    }

    private void validation(Member toMember) {
        if (toMember.getMemberId().equals("ex")) {
            throw new IllegalStateException("이체중 예외 발생");
        }
    }
}
  • fromId의 회원을 조회해서 toId 회원에게 money 만큼의 돈을 계좌이체하는 로직이다.
  • 예외 상황을 테스트해보기 위해 toId"ex"인 경우 예외를 발생시킨다.

MemberServiceV1Test

package cwchoiit.jdbc.service;

import cwchoiit.jdbc.connection.ConnectionConst;
import cwchoiit.jdbc.domain.Member;
import cwchoiit.jdbc.repository.MemberRepositoryV1;
import org.assertj.core.api.Assertions;
import org.junit.jupiter.api.AfterEach;
import org.junit.jupiter.api.BeforeEach;
import org.junit.jupiter.api.DisplayName;
import org.junit.jupiter.api.Test;
import org.springframework.jdbc.datasource.DriverManagerDataSource;

import java.sql.SQLException;

import static cwchoiit.jdbc.connection.ConnectionConst.*;
import static org.assertj.core.api.Assertions.*;
import static org.junit.jupiter.api.Assertions.*;

class MemberServiceV1Test {

    public static final String MEMBER_A = "memberA";
    public static final String MEMBER_B = "memberB";
    public static final String MEMBER_EX = "ex";

    private MemberRepositoryV1 memberRepository;
    private MemberServiceV1 memberService;

    @BeforeEach
    void beforeEach() {
        DriverManagerDataSource dataSource = new DriverManagerDataSource(URL, USERNAME, PASSWORD);
        memberRepository = new MemberRepositoryV1(dataSource);
        memberService = new MemberServiceV1(memberRepository);
    }

    @AfterEach
    void afterEach() throws SQLException {
        memberRepository.delete(MEMBER_A);
        memberRepository.delete(MEMBER_B);
        memberRepository.delete(MEMBER_EX);
    }

    @Test
    @DisplayName("정상 이체")
    void accountTransfer() throws SQLException {
        Member memberA = new Member(MEMBER_A, 10000);
        Member memberB = new Member(MEMBER_B, 10000);

        memberRepository.save(memberA);
        memberRepository.save(memberB);

        memberService.accountTransfer(memberA.getMemberId(), memberB.getMemberId(), 2000);

        Member findMemberA = memberRepository.findById(memberA.getMemberId());
        Member findMemberB = memberRepository.findById(memberB.getMemberId());

        assertThat(findMemberA.getMoney()).isEqualTo(8000);
        assertThat(findMemberB.getMoney()).isEqualTo(12000);
    }

    @Test
    @DisplayName("이체 중 예외")
    void accountTransfer_ex() throws SQLException {
        Member memberA = new Member(MEMBER_A, 10000);
        Member memberEx = new Member(MEMBER_EX, 10000);

        memberRepository.save(memberA);
        memberRepository.save(memberEx);

        assertThatThrownBy(() -> memberService.accountTransfer(memberA.getMemberId(), memberEx.getMemberId(), 2000))
                .isInstanceOf(IllegalStateException.class);

        Member findMemberA = memberRepository.findById(memberA.getMemberId());
        Member findMemberEx = memberRepository.findById(memberEx.getMemberId());

        assertThat(findMemberA.getMoney()).isEqualTo(8000);
        assertThat(findMemberEx.getMoney()).isEqualTo(10000);
    }
}
  • 두 개의 테스트가 있다. [정상 이체], [이체 중 예외]
  • [정상 이체] 테스트의 경우, 이체 과정에서 아무런 문제가 발생하지 않기 때문에 의도대로 동작하는 것을 확인할 수 있을 것이다.
  • [이체 중 예외] 테스트의 경우, toId `ex`이기 때문에 중간에 예외가 발생한다. 그런데 문제는 트랜잭션이 없기 때문에 (다른 말로 오토커밋 모드이기 때문에) 쿼리 하나하나가 나갈때마다 전부 커밋이 된다. 그래서 결국 fromId의 돈만 2000원이 빠져나가고, toId의 돈은 그대로인 최악의 사태가 발생한다. 
  • 이게 바로 트랜잭션의 필요성이다. 지금은 원자성을 위배해버렸다.

 

트랜잭션 - 자바 예제2 - 트랜잭션 사용

이번에는 DB 트랜잭션을 사용해서 앞서 발생한 문제점을 해결해보자. 어떤 문제점이 있었나? 바로 memberA의 돈을 빼긴 했는데 memberEx의 계좌에 돈을 추가하는 과정에서 에러가 발생해서 memberA의 돈만 빠져나가고 memberEx의 계좌에는 돈이 그대로인 최악중 최악의 문제가 발생했다. 즉, 트랜잭션의 원자성을 활용하지 못하는 문제가 발생했다. 

 

그래서, 트랜잭션을 사용해서 모두가 성공하거나 모두가 실패하게 만들어보자. 그럼 고민이 하나 생긴다.

어디에 트랜잭션을 걸어야 할까? 쉽게 이야기해서 트랜잭션을 어디에서 시작하고 어디에서 끝내야 할까?

  • 트랜잭션은 비즈니스 로직이 있는 서비스 계층에서 시작해야 한다. 비즈니스 로직이 잘못되면 해당 비즈니스 로직으로 인해 문제가 되는 부분을 함께 롤백해야 하기 때문이다.
  • 그런데 트랜잭션을 시작하려면 커넥션이 필요하다. 결국 서비스 계층에서 커넥션을 만들고, 트랜잭션 커밋 이후에 커넥션을 종료해야 한다.
  • 애플리케이션에서 DB 트랜잭션을 사용하려면, 트랜잭션을 사용하는 동안 같은 커넥션을 유지해야 한다. 그래야 같은 세션을 사용할 수 있다.

애플리케이션에서 같은 커넥션을 유지하려면 어떻게 해야 할까? 가장 단순한 방법은 커넥션을 파라미터로 전달해서 같은 커넥션이 사용되도록 유지하는 것이다. 먼저 리포지토리가 파라미터를 통해 같은 커넥션을 유지할 수 있도록 파라미터를 추가해보자.

MemberRepositoryV2

package cwchoiit.jdbc.repository;

import cwchoiit.jdbc.domain.Member;
import lombok.RequiredArgsConstructor;
import lombok.extern.slf4j.Slf4j;

import javax.sql.DataSource;
import java.sql.Connection;
import java.sql.PreparedStatement;
import java.sql.ResultSet;
import java.sql.SQLException;
import java.util.NoSuchElementException;

@Slf4j
@RequiredArgsConstructor
public class MemberRepositoryV2 {

    private final DataSource dataSource;

    public Member save(Member member) throws SQLException {
        String sql = "INSERT INTO member (member_id, money) VALUES (?, ?)";


        try (Connection connection = getConnection();
             PreparedStatement stmt = connection.prepareStatement(sql)) {
            stmt.setString(1, member.getMemberId());
            stmt.setInt(2, member.getMoney());
            stmt.executeUpdate();
            return member;
        } catch (SQLException e) {
            log.error("DB Error", e);
            throw e;
        }
    }

    public Member findById(String memberId) throws SQLException {
        String sql = "SELECT * FROM member WHERE member_id = ?";

        try (Connection connection = getConnection();
             PreparedStatement stmt = connection.prepareStatement(sql)) {
            stmt.setString(1, memberId);

            try (ResultSet rs = stmt.executeQuery()) {
                if (rs.next()) {
                    Member member = new Member();
                    member.setMemberId(rs.getString("member_id"));
                    member.setMoney(rs.getInt("money"));
                    return member;
                } else {
                    throw new NoSuchElementException("Member not found with id = " + memberId);
                }
            }
        } catch (SQLException e) {
            log.error("DB Error", e);
            throw e;
        }
    }

    public Member findById(Connection connection, String memberId) throws SQLException {
        String sql = "SELECT * FROM member WHERE member_id = ?";

        try (PreparedStatement stmt = connection.prepareStatement(sql)) {
            stmt.setString(1, memberId);

            try (ResultSet rs = stmt.executeQuery()) {
                if (rs.next()) {
                    Member member = new Member();
                    member.setMemberId(rs.getString("member_id"));
                    member.setMoney(rs.getInt("money"));
                    return member;
                } else {
                    throw new NoSuchElementException("Member not found with id = " + memberId);
                }
            }
        } catch (SQLException e) {
            log.error("DB Error", e);
            throw e;
        }
    }

    public void update(String memberId, int money) throws SQLException {
        String sql = "UPDATE member SET money = ? WHERE member_id = ?";
        try (Connection connection = getConnection();
             PreparedStatement stmt = connection.prepareStatement(sql)) {

            stmt.setInt(1, money);
            stmt.setString(2, memberId);
            int resultSize = stmt.executeUpdate();
            log.info("resultSize = {}", resultSize);
        } catch (SQLException e) {
            log.error("DB Error", e);
            throw e;
        }
    }

    public void update(Connection connection, String memberId, int money) throws SQLException {
        String sql = "UPDATE member SET money = ? WHERE member_id = ?";
        try (PreparedStatement stmt = connection.prepareStatement(sql)) {

            stmt.setInt(1, money);
            stmt.setString(2, memberId);
            int resultSize = stmt.executeUpdate();
            log.info("resultSize = {}", resultSize);
        } catch (SQLException e) {
            log.error("DB Error", e);
            throw e;
        }
    }

    public void delete(String memberId) throws SQLException {
        String sql = "DELETE FROM member WHERE member_id = ?";

        try (Connection connection = getConnection();
             PreparedStatement stmt = connection.prepareStatement(sql)) {

            stmt.setString(1, memberId);
            stmt.executeUpdate();
        } catch (SQLException e) {
            log.error("DB Error", e);
            throw e;
        }
    }

    private Connection getConnection() throws SQLException {
        Connection con = dataSource.getConnection();
        log.info("get connection = {}, class = {}", con, con.getClass());
        return con;
    }
}
  • 코드를 보면, V2는 기존 코드와 같지만, 커넥션 유지가 필요한 다음 두 메서드가 추가되었다. 
  • findById(Connection connection, String memberId)
  • update(Connection connection, String memberId, int money)

주의할 부분이 있다!

  • 커넥션 유지가 필요한 두 메서드는 파라미터로 넘어온 커넥션을 사용해야 한다. 그러므로 메서드 안에서 getConnection()을 호출해서는 절대 안된다!
  • 커넥션 유지가 필요한 두 메서드는 리포지토리에서 커넥션을 닫으면 안된다. 커넥션을 전달 받은 리포지토리 뿐만 아니라 이후에도 커넥션을 계속 이어서 사용하기 때문이다. 그래서 이후 서비스 로직이 끝날 때 트랜잭션을 종료하고 커넥션을 닫아야 한다.

MemberServiceV2

package cwchoiit.jdbc.service;

import cwchoiit.jdbc.domain.Member;
import cwchoiit.jdbc.repository.MemberRepositoryV1;
import cwchoiit.jdbc.repository.MemberRepositoryV2;
import lombok.RequiredArgsConstructor;
import lombok.extern.slf4j.Slf4j;

import javax.sql.DataSource;
import java.sql.Connection;
import java.sql.SQLException;

@Slf4j
@RequiredArgsConstructor
public class MemberServiceV2 {

    private final DataSource dataSource;
    private final MemberRepositoryV2 memberRepository;

    public void accountTransfer(String fromId, String toId, int money) throws SQLException {
        Connection connection = dataSource.getConnection();

        try {
            connection.setAutoCommit(false);

            bizLogic(connection, fromId, toId, money);

            connection.commit();
        } catch (Exception e) {
            connection.rollback();
            throw new IllegalStateException(e);
        } finally {
            releaseConnection(connection);
        }
    }

    private void bizLogic(Connection connection, String fromId, String toId, int money) throws SQLException {
        Member fromMember = memberRepository.findById(connection, fromId);
        Member toMember = memberRepository.findById(connection, toId);

        memberRepository.update(connection, fromId, fromMember.getMoney() - money);

        validation(toMember);

        memberRepository.update(connection, toId, toMember.getMoney() + money);
    }

    private void releaseConnection(Connection connection) {
        if (connection != null) {
            try {
                connection.setAutoCommit(true);
                connection.close(); // 커넥션 풀을 사용할땐 close()가 반납
            } catch (Exception e) {
                log.error("error, ", e);
            }
        }
    }

    private void validation(Member toMember) {
        if (toMember.getMemberId().equals("ex")) {
            throw new IllegalStateException("이체중 예외 발생");
        }
    }
}
  • 이제 서비스 로직이 있는 accountTransfer() 메서드를 유심히 보자.
public void accountTransfer(String fromId, String toId, int money) throws SQLException {
    Connection connection = dataSource.getConnection();

    try {
        connection.setAutoCommit(false);

        bizLogic(connection, fromId, toId, money);

        connection.commit();
    } catch (Exception e) {
        connection.rollback();
        throw new IllegalStateException(e);
    } finally {
        releaseConnection(connection);
    }
}
  • 트랜잭션이 시작하려면 먼저 커넥션이 필요하기 때문에, 커넥션을 가져온다. 
  • 그런 다음, 트랜잭션을 시작한다는 말은 다른 말로 수동 커밋을 사용한다는 의미이다. 따라서 커넥션을 수동 커밋 모드로 변경한다.
  • 그런 다음 실질적인 비즈니스 로직을 수행한다. 보기 편하게 따로 메서드를 추출했다. 또한, 트랜잭션을 관리하는 로직과 비즈니스 로직을 구분하기 위해서도 메서드를 추출했다.
private void bizLogic(Connection connection, String fromId, String toId, int money) throws SQLException {
    Member fromMember = memberRepository.findById(connection, fromId);
    Member toMember = memberRepository.findById(connection, toId);

    memberRepository.update(connection, fromId, fromMember.getMoney() - money);

    validation(toMember);

    memberRepository.update(connection, toId, toMember.getMoney() + money);
}
  • 비즈니스 로직을 잘 보면, 리포지토리에 커넥션을 파라미터로 넘겨서 사용하는 것을 볼 수 있다.
public void accountTransfer(String fromId, String toId, int money) throws SQLException {
    Connection connection = dataSource.getConnection();

    try {
        connection.setAutoCommit(false);

        bizLogic(connection, fromId, toId, money);

        connection.commit();
    } catch (Exception e) {
        connection.rollback();
        throw new IllegalStateException(e);
    } finally {
        releaseConnection(connection);
    }
}
  • 비즈니스 로직이 정상적으로 끝나면 당연히 커밋을 호출해야 한다.
  • 그런데 만약, 비즈니스 로직을 수행하던 중 오류가 발생하면 이 트랜잭션에서 수행했던 모든 작업을 트랜잭션을 수행하기 전 모습으로 돌려야 한다. 따라서, catch 블록에서 롤백을 수행하고 있다.
  • 모든 작업이 끝나면 항상 커넥션을 반납해야 한다. 따라서 finally 블록에서 커넥션을 정리하는 메서드를 호출한다.
private void releaseConnection(Connection connection) {
    if (connection != null) {
        try {
            connection.setAutoCommit(true);
            connection.close(); // 커넥션 풀을 사용할땐 close()가 반납
        } catch (Exception e) {
            log.error("error, ", e);
        }
    }
}
  • 커넥션을 정리를 할때, 반드시 반납하기 전 오토 커밋 모드를 다시 `true`로 변경해야 한다. 왜냐하면 기본이 자동 커밋이기 때문에 누군가는 자동 커밋을 예상하고 로직을 작성할 수 있다. DriverManager를 통해 필요할때마다 커넥션을 생성하고 바로 닫아버리면 상관이 없다. 그런데 커넥션 풀을 사용하는 경우 수동 커밋으로 변경하고 다시 자동 커밋으로 돌려 놓은 후에 커넥션을 반납하지 않으면 이 커넥션은 계속 수동 커밋 모드인 상태로 남아 있게 된다. 그러면 누군가는 자동 커밋을 생각하고 커밋을 호출안하면 이건 굉장히 큰 문제를 야기한다.

이제 기존에 사용했던 테스트 코드를 다시 실행해보자!

MemberServiceV2Test

package cwchoiit.jdbc.service;

import cwchoiit.jdbc.domain.Member;
import cwchoiit.jdbc.repository.MemberRepositoryV2;
import org.junit.jupiter.api.AfterEach;
import org.junit.jupiter.api.BeforeEach;
import org.junit.jupiter.api.DisplayName;
import org.junit.jupiter.api.Test;
import org.springframework.jdbc.datasource.DriverManagerDataSource;

import java.sql.SQLException;

import static cwchoiit.jdbc.connection.ConnectionConst.*;
import static org.assertj.core.api.Assertions.assertThat;
import static org.assertj.core.api.Assertions.assertThatThrownBy;

class MemberServiceV2Test {

    public static final String MEMBER_A = "memberA";
    public static final String MEMBER_B = "memberB";
    public static final String MEMBER_EX = "ex";

    private MemberRepositoryV2 memberRepository;
    private MemberServiceV2 memberService;

    @BeforeEach
    void beforeEach() {
        DriverManagerDataSource dataSource = new DriverManagerDataSource(URL, USERNAME, PASSWORD);
        memberRepository = new MemberRepositoryV2(dataSource);
        memberService = new MemberServiceV2(dataSource, memberRepository);
    }

    @AfterEach
    void afterEach() throws SQLException {
        memberRepository.delete(MEMBER_A);
        memberRepository.delete(MEMBER_B);
        memberRepository.delete(MEMBER_EX);
    }

    @Test
    @DisplayName("정상 이체")
    void accountTransfer() throws SQLException {
        Member memberA = new Member(MEMBER_A, 10000);
        Member memberB = new Member(MEMBER_B, 10000);

        memberRepository.save(memberA);
        memberRepository.save(memberB);

        memberService.accountTransfer(memberA.getMemberId(), memberB.getMemberId(), 2000);

        Member findMemberA = memberRepository.findById(memberA.getMemberId());
        Member findMemberB = memberRepository.findById(memberB.getMemberId());

        assertThat(findMemberA.getMoney()).isEqualTo(8000);
        assertThat(findMemberB.getMoney()).isEqualTo(12000);
    }

    @Test
    @DisplayName("이체 중 예외")
    void accountTransfer_ex() throws SQLException {
        Member memberA = new Member(MEMBER_A, 10000);
        Member memberEx = new Member(MEMBER_EX, 10000);

        memberRepository.save(memberA);
        memberRepository.save(memberEx);

        assertThatThrownBy(() -> memberService.accountTransfer(memberA.getMemberId(), memberEx.getMemberId(), 2000))
                .isInstanceOf(IllegalStateException.class);

        Member findMemberA = memberRepository.findById(memberA.getMemberId());
        Member findMemberEx = memberRepository.findById(memberEx.getMemberId());

        assertThat(findMemberA.getMoney()).isEqualTo(10000);
        assertThat(findMemberEx.getMoney()).isEqualTo(10000);
    }
}
  • 두 개의 테스트가 있다. [정상 이체], [이체 중 예외]
  • [정상 이체] 테스트는 기존과 동일하게 잘 동작한다.
  • [이체 중 예외] 테스트는 이제 같은 트랜잭션을 사용하고 문제가 발생하면 롤백이 일어나기 때문에, memberA2000원을 차감하는데는 성공했어도 memberEx에게 2000원을 추가하는 부분에서 문제가 발생하기 때문에 이 트랜잭션에서 일어난 모든 작업이 다시 롤백된다. 따라서, 최종적으로 두 회원 모두 원래대로 10000원으로 돌아간다.

 

이렇게 트랜잭션을 사용해서, 원자성을 유지할 수 있게 됐다. 이게 바로 트랜잭션의 힘이다.

 

문제

그런데 문제가 있다. V1, V2서비스 코드를 비교해서 다시 한번 보자.

V1

public void accountTransfer(String fromId, String toId, int money) throws SQLException {
    Member fromMember = memberRepository.findById(fromId);
    Member toMember = memberRepository.findById(toId);

    memberRepository.update(fromId, fromMember.getMoney() - money);

    validation(toMember);

    memberRepository.update(toId, toMember.getMoney() + money);
}

V2

public void accountTransfer(String fromId, String toId, int money) throws SQLException {
    Connection connection = dataSource.getConnection();

    try {
        connection.setAutoCommit(false);

        bizLogic(connection, fromId, toId, money);

        connection.commit();
    } catch (Exception e) {
        connection.rollback();
        throw new IllegalStateException(e);
    } finally {
        releaseConnection(connection);
    }
}
  • 트랜잭션을 사용한 코드를 보면, 어찌된게 서비스 로직보다 트랜잭션을 처리하는 코드가 더 많다. 이는 서비스 계층의 역할을 과하게 늘리게 되고, 비즈니스 로직에 다른 코드가 추가되니 코드 자체도 지저분해진다. 
  • 추가적으로 트랜잭션을 사용하는 코드마다 파라미터에 커넥션을 넘겨야 하니 그 또한 골치거리다.
  • 이런 문제를 스프링은 기가막히게 해결해주는데, 그 기가막힌 해결법을 다음 포스팅에서 알아보자!

 

728x90
반응형
LIST

'Spring + Database' 카테고리의 다른 글

[Renewal] 예외  (0) 2024.12.05
[Renewal] 스프링의 트랜잭션  (0) 2024.11.24
[Renewal] 커넥션풀과 DataSource 이해  (2) 2024.11.21
[Renewal] JDBC 이해  (2) 2024.11.20
Index란? (DB)  (0) 2024.04.05
728x90
반응형
SMALL

참고자료

 

스프링 DB 1편 - 데이터 접근 핵심 원리 강의 | 김영한 - 인프런

김영한 | 백엔드 개발에 필요한 DB 데이터 접근 기술을 기초부터 이해하고, 완성할 수 있습니다. 스프링 DB 접근 기술의 원리와 구조를 이해하고, 더 깊이있는 백엔드 개발자로 성장할 수 있습니

www.inflearn.com

 

커넥션 풀 이해

  • 이전 포스팅에서 해봤지만, 애플리케이션과 데이터베이스를 연동하기 위해선 데이터베이스의 커넥션을 얻어와야 한다. 그런데 이 커넥션을 얻어오는 과정은 복잡하다. 
    • 애플리케이션 로직은 DB 드라이버를 통해 커넥션을 조회한다.
    • DB 드라이버는 DB와 TCP/IP 커넥션을 연결한다. 물론 이 과정에서 3 way handshake 같은 TCP/IP 연결을 위한 네트워크 동작도 발생한다.
    • DB 드라이버는 TCP/IP 커넥션이 연결되면, ID, PW와 기타 부가정보를 DB에 전달한다.
    • DB는 ID, PW를 통해 내부 인증을 완료하고, 내부에 DB 세션을 생성한다.
    • DB는 커넥션 생성이 완료되었다는 응답을 보낸다.
    • DB 드라이버는 커넥션 객체를 생성해서 클라이언트에 반환한다.

이렇게 커넥션을 새로 만드는 것은 과정도 복잡하고 시간도 많이 소요되는 일이다. DB는 물론이고 애플리케이션 서버에서도 TCP/IP 커넥션을 새로 생성하기 위한 리소스를 매번 사용해야 한다. 진짜 문제는 고객이 애플리케이션을 사용할 때, SQL을 실행하는 시간 뿐만 아니라 커넥션을 새로 만드는 시간이 추가되기 때문에 결과적으로 응답 속도에 영향을 준다. 이것은 사용자에게 좋지 않은 경험을 줄 수 있다. 

 

이런 문제를 한번에 해결하는 아이디어가 바로 커넥션을 미리 생성해두고, 사용하는 커넥션 풀이라는 방법이다.

커넥션 풀은 이름 그대로 커넥션을 관리하는 풀이다.

애플리케이션을 시작하는 시점에 커넥션 풀은 필요한만큼 커넥션을 미리 확보해서 풀에 보관한다. 보통 얼마나 보관할지는 서비스의 특징과 서버 스펙에 따라 다르지만 기본값은 보통 10개이다. 

 

커넥션 풀에 들어 있는 커넥션은 TCP/IP로 DB와 커넥션이 연결되어 있는 상태이기 때문에 언제든지 즉시 SQL을 DB에 전달할 수 있다.

 

애플리케이션 로직에서 이제는 DB 드라이버를 통해서 새로운 커넥션을 획득하는 것이 아니다. 이제는 커넥션 풀을 통해 이미 생성되어 있는 커넥션을 객체 참조로 그냥 가져다 사용하면 된다. 커넥션 풀에 커넥션을 요청하면 커넥션 풀은 자신이 가지고 있는 커넥션 중에 하나를 반환한다. 

 

애플리케이션 로직은 커넥션 풀에서 받은 커넥션을 사용해서 SQL을 데이터베이스에 전달하고, 그 결과를 받아서 처리한다. 커넥션을 모두 사용하고 나면 이제는 커넥션을 종료하는 것이 아니라, 다음에 다시 사용할 수 있도록 해당 커넥션을 그대로 커넥션 풀에 반납하면 된다. 여기서 주의할 점은 커넥션을 종료하는 것이 아니라 커넥션이 살아있는 상태로 커넥션 풀에 반환해야 한다는 것이다.

 

정리를 하자면

  • 적절한 커넥션 풀 숫자는 서비스의 특징과 애플리케이션 서버 스펙, DB 서버 스펙에 따라 다르기 때문에 성능 테스트를 통해서 정해야 한다.
  • 커넥션 풀은 서버당 최대 커넥션 수를 제한할 수 있다. 따라서 DB에 무한정 연결이 생성되는 것을 막아주어서 DB를 보호하는 효과도 있다. 
  • 이런 커넥션 풀은 얻는 이점이 매우 크기 때문에 실무에서는 항상 기본으로 사용한다.
  • 커넥션 풀은 개념적으로 단순해서 직접 구현할 수도 있지만 사용도 편리하고 성능도 뛰어난 오픈소스 커넥션 풀이 많기 때문에 오픈소스를 사용하자.
  • 대표적인 오픈소스는 HikariCP 이것만 알면 된다. 스프링 부트 2.0부터는 기본 커넥션 풀로 hikariCP를 제공한다.

 

DataSource 이해

그럼 이제, 커넥션 풀까지 이해했으면 커넥션을 얻는 방법은 앞서 학습한 JDBC DriverManager를 직접 사용하거나, 커넥션 풀을 사용하는 등 다양한 방법이 존재한다는 것을 알게됐다.

 

  • 이렇게 커넥션을 획득하는 방법이 다양하다. 
  • 그런데, 만약 DriverManager를 통해 커넥션을 획득하다가 커넥션 풀로 변경하고 싶어서 변경하면 어떻게 될까?

 

예를 들어, 애플리케이션 로직에서 DriverManager를 사용해서 커넥션을 획득하다가 HikariCP 같은 커넥션 풀을 사용하도록 변경하면 커넥션을 획득하는 애플리케이션 코드도 함께 변경해야 한다. 의존관계가 DriverManager에서 HikariCP로 변경되기 때문이다. 물론 둘의 사용법도 다를 것이다. 

이런 경우 자바는 항상 뭐다? 표준과 구현체를 제공한다.

그렇다. 자바에서는 이런 문제를 해결하기 위해 커넥션을 획득하는 방법을 추상화 하는데 그게 바로 DataSource이다.

  • 자바에서는 커넥션을 획득하는 방법을 추상화하는 javax.sql.DataSource라는 인터페이스를 제공한다.
  • 이 인터페이스의 핵심 기능은 커넥션 조회 하나이다. (다른것은 중요하지 않다)

DataSource

public interface DataSource {
    Connection getConnection() throws SQLException;
}

 

그러니까 정리를 하자면,

  • 대부분의 커넥션 풀은 DataSource 인터페이스를 이미 구현해두었다. 따라서 개발자는 commons-dbcp2, tomcat-jdbc pool, hikariCP 등 커넥션 풀 기능을 제공하는 이 코드에 직접 의존하는게 아니라, DataSource 인터페이스에만 의존하도록 애플리케이션 로직을 작성하면 된다.
  • 예를 들어, DBCP2에서 HikariCP로 커넥션 풀 구현 기술을 변경하고 싶으면 그냥 이 라이브러리만 내려받으면 끝난다.
  • 하지만, 안타깝게도 DriverManagerDataSource 인터페이스를 구현하지 않았다. 따라서 DriverManager는 이전 포스팅에서 JDBC를 직접 다룰때처럼 직접 사용해야 한다. 따라서 DriverManager를 사용하다가, DataSource 기반의 커넥션 풀을 사용하도록 변경하면 관련 코드를 다 고쳐야 한다. 이런 문제를 해결하기 위해 스프링에서는 DriverManagerDataSource를 통해서 사용할 수 있도록 DriverManagerDataSource라는 DataSource를 구현한 클래스를 제공한다. 
  • 그래서 스프링을 사용하면, DataSource라는 인터페이스에만 의존하면 커넥션 풀을 사용하는 기술이던, 직접 커넥션을 가져오던 상관없이 DataSource 인터페이스에만 의존하면 된다. 구현체만 갈아끼우면 된다는 뜻이다. 그래서 DriverManagerDataSource를 통해서 DriverManager를 사용하다가 커넥션 풀을 사용하도록 구현체를 갈아끼워도 애플리케이션 로직은 변경하지 않아도 된다.

 

DataSource 예제1 - DriverManagerDataSource

예제를 통해 DataSource를 한번 사용해보자.

먼저, 기존에 개발했던 DriverManager를 통해서 커넥션을 획득하는 방법을 확인해보자.

ConnectionTest

package cwchoiit.jdbc.connection;

import lombok.extern.slf4j.Slf4j;
import org.junit.jupiter.api.Test;
import org.springframework.jdbc.datasource.DriverManagerDataSource;

import javax.sql.DataSource;
import java.sql.Connection;
import java.sql.DriverManager;
import java.sql.SQLException;

import static cwchoiit.jdbc.connection.ConnectionConst.*;

@Slf4j
public class ConnectionTest {

    @Test
    void driverManager() throws SQLException {
        Connection con1 = DriverManager.getConnection(URL, USERNAME, PASSWORD);
        Connection con2 = DriverManager.getConnection(URL, USERNAME, PASSWORD);

        log.info("connection = {}, class = {}", con1, con1.getClass());
        log.info("connection = {}, class = {}", con2, con2.getClass());
    }
}

실행 결과

16:33:00.976 [Test worker] INFO cwchoiit.jdbc.connection.ConnectionTest -- connection = conn0: url=jdbc:h2:tcp://localhost/~/h2/db/jdbc user=SA, class = class org.h2.jdbc.JdbcConnection
16:33:00.978 [Test worker] INFO cwchoiit.jdbc.connection.ConnectionTest -- connection = conn1: url=jdbc:h2:tcp://localhost/~/h2/db/jdbc user=SA, class = class org.h2.jdbc.JdbcConnection
  • 두번의 getConnection()을 호출해서 서로 다른 커넥션을 얻어왔음을 알 수 있다. 이게 이전 포스팅에서 해봤던 JDBC의 DriverManager를 사용해 커넥션을 가져오는 방법이다.

 

이번에는 스프링이 제공하는 DataSource를 구현한 DriverManagerDataSource를 사용해보자. 차이가 있다면 이 녀석을 사용하면 클라이언트 코드는 DataSource 인터페이스에만 의존하면 된다는 점이다. 직접 커넥션을 가져오든, 커넥션 풀을 통해 가져오든 말이다.

ConnectionTest

package cwchoiit.jdbc.connection;

import lombok.extern.slf4j.Slf4j;
import org.junit.jupiter.api.Test;
import org.springframework.jdbc.datasource.DriverManagerDataSource;

import javax.sql.DataSource;
import java.sql.Connection;
import java.sql.DriverManager;
import java.sql.SQLException;

import static cwchoiit.jdbc.connection.ConnectionConst.*;

@Slf4j
public class ConnectionTest {

    @Test
    void dataSourceDriverManager() throws SQLException {
        DataSource dataSource = new DriverManagerDataSource(URL, USERNAME, PASSWORD);
        useDataSource(dataSource);
    }

    private void useDataSource(DataSource dataSource) throws SQLException {
        Connection con1 = dataSource.getConnection();
        Connection con2 = dataSource.getConnection();
        log.info("connection = {}, class = {}", con1, con1.getClass());
        log.info("connection = {}, class = {}", con2, con2.getClass());
    }
}
  • 기존 코드와 비슷하지만 DriverManagerDataSourceDataSource를 통해서 커넥션을 획득할 수 있다. 보면 알겠지만 타입도 DataSource로 받을 수 있다. 스프링이 제공하는 DriverManagerDataSourceDataSource를 구현한다.

실행 결과

16:33:00.976 [Test worker] INFO cwchoiit.jdbc.connection.ConnectionTest -- connection = conn0: url=jdbc:h2:tcp://localhost/~/h2/db/jdbc user=SA, class = class org.h2.jdbc.JdbcConnection
16:33:00.978 [Test worker] INFO cwchoiit.jdbc.connection.ConnectionTest -- connection = conn1: url=jdbc:h2:tcp://localhost/~/h2/db/jdbc user=SA, class = class org.h2.jdbc.JdbcConnection
  • 당연히 커넥션 풀이 아니라, 내부적으로 DriverManager를 사용하므로 두 커넥션은 서로 다른 커넥션이다. 
  • 그런데, 여기서 엄청 큰 차이가 하나 있다. 바로 새로운 커넥션을 획득하더라도 파라미터를 그때그때 넘기지 않아도 된다는 점이다.

 

DriverManager 직접 사용 시

DriverManager.getConnection(URL, USERNAME, PASSWORD)
DriverManager.getConnection(URL, USERNAME, PASSWORD)

 

DataSource 사용 시

@Test
void dataSourceDriverManager() throws SQLException {
    DataSource dataSource = new DriverManagerDataSource(URL, USERNAME, PASSWORD);
    useDataSource(dataSource);
}

private void useDataSource(DataSource dataSource) throws SQLException {
    Connection con1 = dataSource.getConnection();
    Connection con2 = dataSource.getConnection();
    log.info("connection = {}, class = {}", con1, con1.getClass());
    log.info("connection = {}, class = {}", con2, con2.getClass());
}
  • DriverManager는 커넥션을 획득할 때마다 파라미터로 URL, USERNAME, PASSWORD를 넘겨야 한다. 반면, DataSource를 구현한 DriverManagerDataSource는 처음 객체를 생성할때 생성자로 그 값들을 넘겨주면 그 이후에 커넥션을 획득할 땐, 단순히 getConnection()만 호출하면 된다. 

이는 설정과 사용의 분리를 의미한다.

  • 설정: DataSource를 만들고 필요한 속성들을 사용해서 URL, USERNAME, PASSWORD 같은 부분을 입력하는 것을 말한다. 이렇게 설정과 관련된 속성들은 한 곳에 있는 것이 향후 변경에 더 유연하게 대처할 수 있다.
  • 사용: 설정은 신경쓰지 않고, DataSourcegetConnection()만 호출해서 사용하면 된다.

이런 설정과 사용의 분리가 작아보이지만 굉장히 큰 차이를 만든다. 보통 설정은 한군데에서 하더라도 사용은 여러군데에서 하는 경우가 많다. 그런데 그때 사용하는 지점에도 설정 관련 정보를 알아야 한다면 굉장히 골치아파진다. 그리고 변경할때는 더 문제다. 적용한 부분을 모두 다 수정해줘야하니 말이다.

 

DataSource 예제2 - 커넥션 풀

이번에는 DataSource를 통해 커넥션 풀을 사용하는 예제를 알아보자.

@Test
void dataSourceConnectionPool() throws SQLException, InterruptedException {
    HikariDataSource dataSource = new HikariDataSource();
    dataSource.setJdbcUrl(URL);
    dataSource.setUsername(USERNAME);
    dataSource.setPassword(PASSWORD);

    dataSource.setMaximumPoolSize(10);
    dataSource.setPoolName("MyPool");

    useDataSource(dataSource);
    
    Thread.sleep(1000);
}

private void useDataSource(DataSource dataSource) throws SQLException {
    Connection con1 = dataSource.getConnection();
    Connection con2 = dataSource.getConnection();
    log.info("connection = {}, class = {}", con1, con1.getClass());
    log.info("connection = {}, class = {}", con2, con2.getClass());
}
  • HikariCP 커넥션 풀을 사용한다. HikariDataSourceDataSource 인터페이스를 구현하고 있다.
  • 커넥션 풀 최대 사이즈를 10으로 지정하고, 풀의 이름을 MyPool 이라고 지정했다.
  • 커넥션 풀에서 커넥션을 생성하는 작업은 애플리케이션 실행 속도에 영향을 주지 않기 위해 별도의 쓰레드에서 작동한다. 별도의 쓰레드에서 동작하기 때문에 테스트가 먼저 종료되어 버린다. 예제처럼 Thread.sleep을 주면 커넥션 풀에 커넥션이 생성되는 로그를 확인할 수 있을 것이다.

실행 결과

#커넥션 풀 초기화 정보 출력
HikariConfig - MyPool - configuration:
HikariConfig - maximumPoolSize................................10 
HikariConfig - poolName................................"MyPool"
#커넥션 풀 전용 쓰레드가 커넥션 풀에 커넥션을 10개 채움
[MyPool connection adder] MyPool - Added connection conn0: url=jdbc:h2:.. user=SA
[MyPool connection adder] MyPool - Added connection conn1: url=jdbc:h2:.. user=SA
[MyPool connection adder] MyPool - Added connection conn2: url=jdbc:h2:.. user=SA
[MyPool connection adder] MyPool - Added connection conn3: url=jdbc:h2:.. user=SA
[MyPool connection adder] MyPool - Added connection conn4: url=jdbc:h2:.. user=SA
  ...
[MyPool connection adder] MyPool - Added connection conn9: url=jdbc:h2:.. user=SA

#커넥션 풀에서 커넥션 획득1
ConnectionTest - connection=HikariProxyConnection@446445803 wrapping conn0: url=jdbc:h2:tcp://localhost/~/test user=SA, class=class com.zaxxer.hikari.pool.HikariProxyConnection

#커넥션 풀에서 커넥션 획득2
ConnectionTest - connection=HikariProxyConnection@832292933 wrapping conn1: url=jdbc:h2:tcp://localhost/~/test user=SA, class=class com.zaxxer.hikari.pool.HikariProxyConnection

MyPool - After adding stats (total=10, active=2, idle=8, waiting=0)

 

실행 결과를 분석해보자.

 

HikariConfig

  • HikariCP 관련 설정을 확인할 수 있다. 풀의 이름을 MyPool과 최대 풀 수 10을 확인할 수 있다.

MyPool connection adder

  • 별도의 쓰레드를 사용해서 커넥션 풀에 커넥션을 채우고 있는 것을 확인할 수 있다. 이 쓰레드는 커넥션 풀에 커넥션을 최대 풀 수 10개까지 채운다.
  • 그렇다면 왜 별도의 쓰레드를 사용해서 커넥션 풀에 커넥션을 채울까? 커넥션 풀에 커넥션을 채우는것은 상대적으로 오래 걸리는 일이다. 애플리케이션을 실행할 때 커넥션 풀을 채울때까지 마냥 대기하고 있다면, 애플리케이션 실행 시간이 늦어진다. 따라서, 별도의 쓰레드를 사용해서 커넥션 풀을 채워야 애플리케이션 실행 시간에 영향을 주지 않는다.

커넥션 풀에서 커넥션 획득

  • 커넥션 풀에서 커넥션을 획득하고 그 결과를 출력했다. 여기서는 커넥션 풀에서 커넥션을 2개 획득하고 반환하지는 않았다. 따라서 풀에 있는 10개의 커넥션 중에 2개를 가지고 있는 상태이다. 그래서 마지막 로그를 보면 사용중인 커넥션 active=2, 풀에서 대기 상태인 커넥션 idle=8을 확인할 수 있다.

 

DataSource 적용

이번에는 애플리케이션에 DataSource를 적용해보자.

MemberRepositoryV1

package cwchoiit.jdbc.repository;

import cwchoiit.jdbc.connection.DBConnectionUtil;
import cwchoiit.jdbc.domain.Member;
import lombok.RequiredArgsConstructor;
import lombok.extern.slf4j.Slf4j;

import javax.sql.DataSource;
import java.sql.Connection;
import java.sql.PreparedStatement;
import java.sql.ResultSet;
import java.sql.SQLException;
import java.util.NoSuchElementException;

/**
 * JDBC - DataSource 사용
 */
@Slf4j
@RequiredArgsConstructor
public class MemberRepositoryV1 {

    private final DataSource dataSource;

    public Member save(Member member) throws SQLException {
        String sql = "INSERT INTO member (member_id, money) VALUES (?, ?)";


        try (Connection connection = getConnection();
             PreparedStatement stmt = connection.prepareStatement(sql)) {
            stmt.setString(1, member.getMemberId());
            stmt.setInt(2, member.getMoney());
            stmt.executeUpdate();
            return member;
        } catch (SQLException e) {
            log.error("DB Error", e);
            throw e;
        }
    }

    public Member findById(String memberId) throws SQLException {
        String sql = "SELECT * FROM member WHERE member_id = ?";

        try (Connection connection = getConnection();
             PreparedStatement stmt = connection.prepareStatement(sql)) {
            stmt.setString(1, memberId);

            try (ResultSet rs = stmt.executeQuery()) {
                if (rs.next()) {
                    Member member = new Member();
                    member.setMemberId(rs.getString("member_id"));
                    member.setMoney(rs.getInt("money"));
                    return member;
                } else {
                    throw new NoSuchElementException("Member not found with id = " + memberId);
                }
            }
        } catch (SQLException e) {
            log.error("DB Error", e);
            throw e;
        }
    }

    public void update(String memberId, int money) throws SQLException {
        String sql = "UPDATE member SET money = ? WHERE member_id = ?";
        try (Connection connection = getConnection();
             PreparedStatement stmt = connection.prepareStatement(sql)) {

            stmt.setInt(1, money);
            stmt.setString(2, memberId);
            int resultSize = stmt.executeUpdate();
            log.info("resultSize = {}", resultSize);
        } catch (SQLException e) {
            log.error("DB Error", e);
            throw e;
        }
    }

    public void delete(String memberId) throws SQLException {
        String sql = "DELETE FROM member WHERE member_id = ?";

        try (Connection connection = getConnection();
             PreparedStatement stmt = connection.prepareStatement(sql)) {

            stmt.setString(1, memberId);
            stmt.executeUpdate();
        } catch (SQLException e) {
            log.error("DB Error", e);
            throw e;
        }
    }

    private Connection getConnection() throws SQLException {
        Connection con = dataSource.getConnection();
        log.info("get connection = {}, class = {}", con, con.getClass());
        return con;
    }
}
  • 기존에 사용했던 MemberRepositoryV0을 V1으로 변경했다.
  • 그리고 DataSource 의존관계를 외부에서 주입받게 만들었다. 이제 직접 만든 DBConnectionUtil을 사용하지 않아도 된다. DataSource는 표준 인터페이스이기 때문에 DriverManagerDataSource에서 HikariDataSource로 변경되어도 애플리케이션 로직을 변경할 필요가 없다.

MemberRepositoryV1Test

package cwchoiit.jdbc.repository;

import com.zaxxer.hikari.HikariDataSource;
import cwchoiit.jdbc.connection.ConnectionConst;
import cwchoiit.jdbc.domain.Member;
import lombok.extern.slf4j.Slf4j;
import org.junit.jupiter.api.BeforeEach;
import org.junit.jupiter.api.Test;
import org.springframework.jdbc.datasource.DriverManagerDataSource;

import java.sql.DriverManager;
import java.sql.SQLException;
import java.util.NoSuchElementException;

import static cwchoiit.jdbc.connection.ConnectionConst.*;
import static org.assertj.core.api.Assertions.assertThat;
import static org.assertj.core.api.Assertions.assertThatThrownBy;

@Slf4j
class MemberRepositoryV1Test {

    MemberRepositoryV1 repository;

    @BeforeEach
    void beforeEach() {
        // DriverManagerDataSource dataSource = new DriverManagerDataSource(URL, USERNAME, PASSWORD);

        HikariDataSource dataSource = new HikariDataSource();
        dataSource.setJdbcUrl(URL);
        dataSource.setUsername(USERNAME);
        dataSource.setPassword(PASSWORD);

        repository = new MemberRepositoryV1(dataSource);
    }

    @Test
    void crud() throws SQLException {
        Member member = new Member("member4", 10000);
        repository.save(member);

        Member findMember = repository.findById(member.getMemberId());
        log.info("findMember = {}", findMember);

        assertThat(findMember).isEqualTo(member);

        repository.update(member.getMemberId(), 20000);
        Member updatedMember = repository.findById(member.getMemberId());
        assertThat(updatedMember.getMoney()).isEqualTo(20000);

        repository.delete(member.getMemberId());
        assertThatThrownBy(() -> repository.findById(member.getMemberId()))
                .isInstanceOf(NoSuchElementException.class);
    }
}
  • MemberRepositoryV1DataSource 의존관계 주입이 필요하다. 따라서, 모든 테스트를 수행하기 전에 실행하는 @BeforeEach 애노테이션을 사용해서, HikariDataSource로도 주입해보고, DriverManagerDataSource로도 주입해보자. 어떤걸 주입해도 아무런 문제없이 잘 동작하는 것을 볼 수 있다. 이게 바로 외부에서 의존관계를 주입하는 DI고, 의존관계 결정을 나중으로 미루는 아주 유연한 방식이다.

실행 결과

DriverManagerDataSource 사용

  get connection=conn0: url=jdbc:h2:.. user=SA class=class
  org.h2.jdbc.JdbcConnection
  get connection=conn1: url=jdbc:h2:.. user=SA class=class
  org.h2.jdbc.JdbcConnection
  get connection=conn2: url=jdbc:h2:.. user=SA class=class
  org.h2.jdbc.JdbcConnection
  get connection=conn3: url=jdbc:h2:.. user=SA class=class
  org.h2.jdbc.JdbcConnection
  get connection=conn4: url=jdbc:h2:.. user=SA class=class
  org.h2.jdbc.JdbcConnection
  get connection=conn5: url=jdbc:h2:.. user=SA class=class
  org.h2.jdbc.JdbcConnection
  • DriverManagerDataSource를 사용하면, 매번 커넥션을 새로 만들어서 반환해주는 것을 확인할 수 있다. (conn0, conn1, ... conn5)

HikariDataSource 사용 (커넥션 풀)

  get connection=HikariProxyConnection@xxxxxxxx1 wrapping conn0: url=jdbc:h2:...
  user=SA
  get connection=HikariProxyConnection@xxxxxxxx2 wrapping conn0: url=jdbc:h2:...
  user=SA
  get connection=HikariProxyConnection@xxxxxxxx3 wrapping conn0: url=jdbc:h2:...
  user=SA
  get connection=HikariProxyConnection@xxxxxxxx4 wrapping conn0: url=jdbc:h2:...
  user=SA
  get connection=HikariProxyConnection@xxxxxxxx5 wrapping conn0: url=jdbc:h2:...
  user=SA
  get connection=HikariProxyConnection@xxxxxxxx6 wrapping conn0: url=jdbc:h2:...
  user=SA
  • 커넥션 풀을 사용하니, conn0만 계속해서 재사용중임을 알 수 있다.
  • 테스트는 순서대로 실행되기 때문에 커넥션을 사용하고 다시 돌려주는 것을 반복하고 있다. 따라서 conn0만 사용된다.

 

정리

이렇게 DataSource가 무엇인지, 커넥션 풀이 무엇인지 명확히 이해해봤다. 커넥션을 얻는 방법은 매우 여러가지지만, 그것을 고민할 필요없이 JDBC 표준으로 정의한 DataSource만을 의존하면 구현체가 변경되어도 어떠한 코드의 변경도 필요없이 커넥션을 가져오는 기술을 바꿀 수 있다. 이것이 바로 표준과 구현체를 만들어 사용하는 강력한 이유이다.

728x90
반응형
LIST

'Spring + Database' 카테고리의 다른 글

[Renewal] 예외  (0) 2024.12.05
[Renewal] 스프링의 트랜잭션  (0) 2024.11.24
[Renewal] 트랜잭션, DB 락 이해  (0) 2024.11.22
[Renewal] JDBC 이해  (2) 2024.11.20
Index란? (DB)  (0) 2024.04.05
728x90
반응형
SMALL

어지간한 상품을 판매하는 사이트에는 다 있는 포인트에 대해서, 직접 배치를 사용해 포인트 관련 일괄처리를 공부해보고 스프링 배치에 대해 좀 더 익숙해지는 시간을 가져보자.

 

프로젝트 만들기

현재 기준 Spring Boot 3.3.5 버전으로 프로젝트를 만들었다. 그리고 의존성은 다음을 참고한다.

implementation 'org.springframework.boot:spring-boot-starter-batch'
implementation 'org.springframework.boot:spring-boot-starter-data-jpa'
compileOnly 'org.projectlombok:lombok'
runtimeOnly 'com.h2database:h2'
annotationProcessor 'org.projectlombok:lombok'
testImplementation 'org.springframework.boot:spring-boot-starter-test'
testImplementation 'org.springframework.batch:spring-batch-test'
testRuntimeOnly 'org.junit.platform:junit-platform-launcher'

testImplementation 'org.springframework.batch:spring-batch-test'

implementation 'com.querydsl:querydsl-jpa:5.0.0:jakarta'
annotationProcessor "com.querydsl:querydsl-apt:5.0.0:jakarta"
annotationProcessor "jakarta.annotation:jakarta.annotation-api"
annotationProcessor "jakarta.persistence:jakarta.persistence-api"
  • Spring Batch
  • Spring Data JPA
  • Lombok
  • QueryDSL
  • H2

이렇게 5개 정도를 추가하면 된다. 

 

build.gradle (전체)

plugins {
    id 'java'
    id 'org.springframework.boot' version '3.3.5'
    id 'io.spring.dependency-management' version '1.1.6'
}

group = 'cwchoiit'
version = '0.0.1-SNAPSHOT'

java {
    toolchain {
        languageVersion = JavaLanguageVersion.of(21)
    }
}

configurations {
    compileOnly {
        extendsFrom annotationProcessor
    }
}

repositories {
    mavenCentral()
}

dependencies {
    implementation 'org.springframework.boot:spring-boot-starter-batch'
    implementation 'org.springframework.boot:spring-boot-starter-data-jpa'
    compileOnly 'org.projectlombok:lombok'
    runtimeOnly 'com.h2database:h2'
    annotationProcessor 'org.projectlombok:lombok'
    testImplementation 'org.springframework.boot:spring-boot-starter-test'
    testImplementation 'org.springframework.batch:spring-batch-test'
    testRuntimeOnly 'org.junit.platform:junit-platform-launcher'

    testImplementation 'org.springframework.batch:spring-batch-test'

    implementation 'com.querydsl:querydsl-jpa:5.0.0:jakarta'
    annotationProcessor "com.querydsl:querydsl-apt:5.0.0:jakarta"
    annotationProcessor "jakarta.annotation:jakarta.annotation-api"
    annotationProcessor "jakarta.persistence:jakarta.persistence-api"
}

tasks.named('test') {
    useJUnitPlatform()
}

// querydsl directory path
def querydslDir = "src/main/generated"

// querydsl directory를 자동 임포트 할 수 있게 설정
sourceSets {
    main.java.srcDirs += [ querydslDir ]
}

// task 중 compileJava를 실행하면 Q파일들을 생성
tasks.withType(JavaCompile).configureEach {
    options.getGeneratedSourceOutputDirectory().set(file(querydslDir))
}

// clean을 하면 querydsl directory를 삭제
clean.doLast {
    file(querydslDir).deleteDir()
}

 

 

@EnableBatchProcessing

package cwchoiit.pointbatch.config;

import org.springframework.batch.core.configuration.annotation.EnableBatchProcessing;
import org.springframework.context.annotation.Configuration;

@EnableBatchProcessing
@Configuration
public class BatchConfig {

}
  • 가장 먼저, 스프링 배치를 사용하기 위해 @EnableBatchProcessing 애노테이션을 달아준다. 그리고 이 애노테이션이 적용되기 위해 @Configuration 애노테이션도 달아준다.

 

application.yaml

spring:
  batch:
    job:
      name: ${job.name:NONE}
    jdbc:
      initialize-schema: always
  jpa:
    show-sql: true
    hibernate:
      ddl-auto: validate
  datasource:
    driver-class-name: org.h2.Driver
    url: jdbc:h2:tcp://localhost/~/h2/db/point
    username: sa
    password:
  • H2 데이터베이스는 미리 다운받고, 데이터베이스를 만들면 된다. 나는 `point`라는 이름의 데이터베이스를 만들었다.
  • `spring.batch.job.name` : ${job.name:NONE} → 이 스프링 배치 프로그램을 패키징하여 Jar 파일로 만들고 해당 파일을 실행할때, 어떤 Job을 실행시킬건지 명명해줘야 한다. 근데 이름이 너무 기니까 그 긴 이름을 `job.name`으로 축소한것이라고 생각하면 된다. 그리고 만약, Job을 선택하지 않은 경우 모든 Job이 다 실행되는데 그것은 싫으니 기본값으로 NONE을 명명했다.
  • 나머지 데이터베이스 관련 설정은 넘어간다. 이 포스팅에서 다룰 내용은 아니라고 생각한다. 이미 이것을 다룬 포스팅이 내 블로그에 많다. 

 

데이터베이스 테이블 만들기

우선, 데이터베이스 테이블을 만들자. DDL은 미리 준비해 두었다.

CREATE TABLE `point_wallet`
(
    `id`      bigint      NOT NULL AUTO_INCREMENT COMMENT 'ID',
    `amount`  bigint      NOT NULL COMMENT '보유금액',
    `user_id` varchar(20) NOT NULL COMMENT '유저 ID',
    PRIMARY KEY (`id`)
);

CREATE TABLE `point_reservation`
(
    `id`              bigint  NOT NULL AUTO_INCREMENT COMMENT 'ID',
    `amount`          bigint  NOT NULL COMMENT '적립금액',
    `available_days`  int     NOT NULL COMMENT '유효기간',
    `earned_date`     date    NOT NULL COMMENT '적립일자',
    `is_executed`     tinyint NOT NULL COMMENT '적용여부',
    `point_wallet_id` bigint  NOT NULL COMMENT '포인트 지갑 ID',
    PRIMARY KEY (`id`)
);

CREATE TABLE `point`
(
    `id`              bigint  NOT NULL AUTO_INCREMENT COMMENT 'ID',
    `amount`          bigint  NOT NULL COMMENT '적립금액',
    `earned_date`     date    NOT NULL COMMENT '적립일자',
    `expire_date`     date    NOT NULL COMMENT '만료일자',
    `is_used`         tinyint NOT NULL COMMENT '사용유무',
    `is_expired`      tinyint NOT NULL COMMENT '만료여부',
    `point_wallet_id` bigint  NOT NULL COMMENT '포인트 지갑 ID',
    PRIMARY KEY (`id`)
);

CREATE TABLE `message`
(
    `id`      bigint       NOT NULL AUTO_INCREMENT COMMENT 'ID',
    `user_id` varchar(20)  NOT NULL COMMENT '유저 ID',
    `title`   varchar(200) NOT NULL COMMENT '제목',
    `content` text         NOT NULL COMMENT '내용',
    PRIMARY KEY (`id`)
);
  • 사용자의 포인트를 보관하는 지갑을 나타내는 `point_wallet` 테이블
  • 사용자에게 포인트가 적립될 예정임을 나타내는 `point_reservation` 테이블
  • 사용자의 포인트를 나타내는 `point` 테이블
  • 포인트 소멸 또는 증액 예정에 대한 알람을 나타내는 `message` 테이블

지금까지는 비즈니스 로직에 관련된 테이블이었다. 여기서 끝나면 안된다. 왜냐하면 스프링 배치를 돌리기 위해 필요한 테이블들이 있다.

Spring Batch Meta-Data Schema

Spring BatchJob, Step, 및 실행 중인 Batch Job의 상태에 대한 정보를 기록하기 위해 다양한 메타데이터 테이블을 사용한다. 그래서 배치작업을 할 때 이 메타데이터 테이블들이 있어야 한다. 어떻게 만들까? `schema-*.sql` 이라는 파일명으로 된 DDL 스크립트를 제공한다. 저기서 `*`은 내가 사용하는 데이터베이스를 의미한다. 그래서 나는 H2를 사용하니까 `schema-h2.sql` 이라는 파일명을 찾으면 된다! 아래처럼 IntelliJ에서 파일을 찾아보면 스크립트 파일 하나가 나올것이다.

 

해당 파일을 열어보면 다음과 같이 생겼다.

-- Autogenerated: do not edit this file

CREATE TABLE BATCH_JOB_INSTANCE  (
	JOB_INSTANCE_ID BIGINT GENERATED BY DEFAULT AS IDENTITY PRIMARY KEY ,
	VERSION BIGINT ,
	JOB_NAME VARCHAR(100) NOT NULL,
	JOB_KEY VARCHAR(32) NOT NULL,
	constraint JOB_INST_UN unique (JOB_NAME, JOB_KEY)
) ;

CREATE TABLE BATCH_JOB_EXECUTION  (
	JOB_EXECUTION_ID BIGINT GENERATED BY DEFAULT AS IDENTITY PRIMARY KEY ,
	VERSION BIGINT  ,
	JOB_INSTANCE_ID BIGINT NOT NULL,
	CREATE_TIME TIMESTAMP(9) NOT NULL,
	START_TIME TIMESTAMP(9) DEFAULT NULL ,
	END_TIME TIMESTAMP(9) DEFAULT NULL ,
	STATUS VARCHAR(10) ,
	EXIT_CODE VARCHAR(2500) ,
	EXIT_MESSAGE VARCHAR(2500) ,
	LAST_UPDATED TIMESTAMP(9),
	constraint JOB_INST_EXEC_FK foreign key (JOB_INSTANCE_ID)
	references BATCH_JOB_INSTANCE(JOB_INSTANCE_ID)
) ;

CREATE TABLE BATCH_JOB_EXECUTION_PARAMS  (
	JOB_EXECUTION_ID BIGINT NOT NULL ,
	PARAMETER_NAME VARCHAR(100) NOT NULL ,
	PARAMETER_TYPE VARCHAR(100) NOT NULL ,
	PARAMETER_VALUE VARCHAR(2500) ,
	IDENTIFYING CHAR(1) NOT NULL ,
	constraint JOB_EXEC_PARAMS_FK foreign key (JOB_EXECUTION_ID)
	references BATCH_JOB_EXECUTION(JOB_EXECUTION_ID)
) ;

CREATE TABLE BATCH_STEP_EXECUTION  (
	STEP_EXECUTION_ID BIGINT GENERATED BY DEFAULT AS IDENTITY PRIMARY KEY ,
	VERSION BIGINT NOT NULL,
	STEP_NAME VARCHAR(100) NOT NULL,
	JOB_EXECUTION_ID BIGINT NOT NULL,
	CREATE_TIME TIMESTAMP(9) NOT NULL,
	START_TIME TIMESTAMP(9) DEFAULT NULL ,
	END_TIME TIMESTAMP(9) DEFAULT NULL ,
	STATUS VARCHAR(10) ,
	COMMIT_COUNT BIGINT ,
	READ_COUNT BIGINT ,
	FILTER_COUNT BIGINT ,
	WRITE_COUNT BIGINT ,
	READ_SKIP_COUNT BIGINT ,
	WRITE_SKIP_COUNT BIGINT ,
	PROCESS_SKIP_COUNT BIGINT ,
	ROLLBACK_COUNT BIGINT ,
	EXIT_CODE VARCHAR(2500) ,
	EXIT_MESSAGE VARCHAR(2500) ,
	LAST_UPDATED TIMESTAMP(9),
	constraint JOB_EXEC_STEP_FK foreign key (JOB_EXECUTION_ID)
	references BATCH_JOB_EXECUTION(JOB_EXECUTION_ID)
) ;

CREATE TABLE BATCH_STEP_EXECUTION_CONTEXT  (
	STEP_EXECUTION_ID BIGINT NOT NULL PRIMARY KEY,
	SHORT_CONTEXT VARCHAR(2500) NOT NULL,
	SERIALIZED_CONTEXT LONGVARCHAR ,
	constraint STEP_EXEC_CTX_FK foreign key (STEP_EXECUTION_ID)
	references BATCH_STEP_EXECUTION(STEP_EXECUTION_ID)
) ;

CREATE TABLE BATCH_JOB_EXECUTION_CONTEXT  (
	JOB_EXECUTION_ID BIGINT NOT NULL PRIMARY KEY,
	SHORT_CONTEXT VARCHAR(2500) NOT NULL,
	SERIALIZED_CONTEXT LONGVARCHAR ,
	constraint JOB_EXEC_CTX_FK foreign key (JOB_EXECUTION_ID)
	references BATCH_JOB_EXECUTION(JOB_EXECUTION_ID)
) ;

CREATE SEQUENCE BATCH_STEP_EXECUTION_SEQ;
CREATE SEQUENCE BATCH_JOB_EXECUTION_SEQ;
CREATE SEQUENCE BATCH_JOB_SEQ;
  • 이 스크립트 역시 실행해서 메타데이터 테이블을 만들면 된다.
  • 각각의 테이블이 정확히 어떤 내용인지는 다음 공식 문서를 참조하자. 그런데, 이름만 봐도 이게 어떤 테이블인지는 감이 대충 온다.
 

Meta-Data Schema :: Spring Batch

The Spring Batch Metadata tables closely match the domain objects that represent them in Java. For example, JobInstance, JobExecution, JobParameters, and StepExecution map to BATCH_JOB_INSTANCE, BATCH_JOB_EXECUTION, BATCH_JOB_EXECUTION_PARAMS, and BATCH_ST

docs.spring.io

 

 

엔티티 만들기

데이터베이스와 테이블을 만들었으니 이제 엔티티를 만들어보자.

 

Message

package cwchoiit.pointbatch.message.entity;

import jakarta.persistence.*;
import lombok.AccessLevel;
import lombok.AllArgsConstructor;
import lombok.Getter;
import lombok.NoArgsConstructor;

@Entity
@Table(name = "MESSAGE")
@NoArgsConstructor(access = AccessLevel.PROTECTED)
@AllArgsConstructor
@Getter
public class Message {
    @Id
    @GeneratedValue(strategy = GenerationType.IDENTITY)
    private Long id;

    @Column(name = "user_id", nullable = false)
    private String userId;

    @Column(name = "title", nullable = false)
    private String title;

    @Column(name = "content", nullable = false, columnDefinition = "text")
    private String content;
}

MessageRepository

package cwchoiit.pointbatch.message.repository;

import cwchoiit.pointbatch.message.entity.Message;
import org.springframework.data.jpa.repository.JpaRepository;

public interface MessageRepository extends JpaRepository<Message, Long> {
}

 

Point

package cwchoiit.pointbatch.point.entity;

import jakarta.persistence.*;
import lombok.AccessLevel;
import lombok.AllArgsConstructor;
import lombok.Getter;
import lombok.NoArgsConstructor;

import java.math.BigInteger;
import java.time.LocalDate;

@Entity
@Table(name = "POINT")
@NoArgsConstructor(access = AccessLevel.PROTECTED)
@AllArgsConstructor
@Getter
public class Point {
    @Id
    @GeneratedValue(strategy = GenerationType.IDENTITY)
    private Long id;

    @ManyToOne(fetch = FetchType.LAZY)
    @JoinColumn(name = "point_wallet_id", nullable = false)
    private PointWallet pointWallet;

    @Column(name = "amount", nullable = false, columnDefinition = "BIGINT")
    private BigInteger amount;

    @Column(name = "earned_date", nullable = false)
    private LocalDate earnedDate;

    @Column(name = "expire_date", nullable = false)
    private LocalDate expireDate;

    @Column(name = "is_used", nullable = false, columnDefinition = "TINYINT", length = 1)
    private boolean used;

    @Column(name = "is_expired", nullable = false, columnDefinition = "TINYINT", length = 1)
    private boolean expired;

    public Point(PointWallet pointWallet, BigInteger amount, LocalDate earnedDate, LocalDate expireDate) {
        this.pointWallet = pointWallet;
        this.amount = amount;
        this.earnedDate = earnedDate;
        this.expireDate = expireDate;
        this.used = false;
        this.expired = false;
    }

    public void expire() {
        if (!this.used) {
            this.expired = true;
        }
    }
}

PointRepository

package cwchoiit.pointbatch.point.repository;

import cwchoiit.pointbatch.point.entity.Point;
import org.springframework.data.jpa.repository.JpaRepository;

public interface PointRepository extends JpaRepository<Point, Long> {
}

 

PointWallet

package cwchoiit.pointbatch.point.entity;

import jakarta.persistence.*;
import lombok.*;

import java.math.BigInteger;

@Entity
@Table(name = "POINT_WALLET")
@NoArgsConstructor(access = AccessLevel.PROTECTED)
@AllArgsConstructor
@Getter
public class PointWallet {
    @Id
    @GeneratedValue(strategy = GenerationType.IDENTITY)
    private Long id;

    @Column(name = "user_id", unique = true, nullable = false)
    private String userId;

    @Column(name = "amount", columnDefinition = "BIGINT")
    BigInteger amount;
}

PointWalletRepository

package cwchoiit.pointbatch.point.repository;

import cwchoiit.pointbatch.point.entity.PointWallet;
import org.springframework.data.jpa.repository.JpaRepository;

public interface PointWalletRepository extends JpaRepository<PointWallet, Long> {
}

 

PointReservation

package cwchoiit.pointbatch.reservation.entity;

import cwchoiit.pointbatch.point.entity.PointWallet;
import jakarta.persistence.*;
import lombok.AccessLevel;
import lombok.AllArgsConstructor;
import lombok.Getter;
import lombok.NoArgsConstructor;

import java.math.BigInteger;
import java.time.LocalDate;

@Entity
@Table(name = "POINT_RESERVATION")
@NoArgsConstructor(access = AccessLevel.PROTECTED)
@AllArgsConstructor
@Getter
public class PointReservation {
    @Id
    @GeneratedValue(strategy = GenerationType.IDENTITY)
    private Long id;

    @ManyToOne(fetch = FetchType.LAZY)
    @JoinColumn(name = "point_wallet_id", nullable = false)
    private PointWallet pointWallet;

    @Column(name = "amount", nullable = false, columnDefinition = "BIGINT")
    private BigInteger amount;

    @Column(name = "earned_date", nullable = false)
    private LocalDate earnedDate;

    @Column(name = "available_days", nullable = false)
    private int availableDays;

    @Column(name = "is_executed", columnDefinition = "TINYINT", length = 1)
    private boolean executed;

    public PointReservation(PointWallet pointWallet, BigInteger amount, LocalDate earnedDate, int availableDays) {
        this.pointWallet = pointWallet;
        this.amount = amount;
        this.earnedDate = earnedDate;
        this.availableDays = availableDays;
        this.executed = false;
    }

    public void execute() {
        this.executed = true;
    }

    public LocalDate getExpireDate() {
        return this.earnedDate.plusDays(this.availableDays);
    }
}

PointReservationRepository

package cwchoiit.pointbatch.reservation.repository;

import cwchoiit.pointbatch.reservation.entity.PointReservation;
import org.springframework.data.jpa.repository.JpaRepository;

public interface PointReservationRepository extends JpaRepository<PointReservation, Long> {
}

 

 

테스트 코드 작성하기

이제, 비즈니스 로직을 수행할 Job을 만들건데, 그 Job을 테스트하기 위한 테스트 코드를 같이 작성해보자. 바로 들어가보자.

우선, application.yaml은 동일하게 하나 만들어주자.

 

test/resources/application.yaml

spring:
  batch:
    job:
      name: ${job.name:NONE}
    jdbc:
      initialize-schema: always
  jpa:
    show-sql: true
    hibernate:
      ddl-auto: validate
  datasource:
    url: jdbc:h2:tcp://localhost/~/h2/db/point
    username: sa
    password:
    driver-class-name: org.h2.Driver

 

BatchTestSupport

package cwchoiit.pointbatch;

import cwchoiit.pointbatch.message.repository.MessageRepository;
import cwchoiit.pointbatch.point.repository.PointRepository;
import cwchoiit.pointbatch.point.repository.PointWalletRepository;
import cwchoiit.pointbatch.reservation.repository.PointReservationRepository;
import org.junit.jupiter.api.AfterEach;
import org.springframework.batch.core.Job;
import org.springframework.batch.core.JobExecution;
import org.springframework.batch.core.JobParameters;
import org.springframework.batch.core.launch.JobLauncher;
import org.springframework.batch.core.repository.JobRepository;
import org.springframework.batch.test.JobLauncherTestUtils;
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.boot.test.context.SpringBootTest;
import org.springframework.test.context.ActiveProfiles;

@SpringBootTest
@ActiveProfiles("test")
public abstract class BatchTestSupport {

    @Autowired
    private JobLauncher jobLauncher;

    @Autowired
    private JobRepository jobRepository;

    @Autowired
    PointWalletRepository pointWalletRepository;

    @Autowired
    PointRepository pointRepository;

    @Autowired
    MessageRepository messageRepository;

    @Autowired
    PointReservationRepository pointReservationRepository;

    protected JobExecution launchJob(Job job, JobParameters jobParameters) throws Exception {
        JobLauncherTestUtils jobLauncherTestUtils = new JobLauncherTestUtils();
        jobLauncherTestUtils.setJob(job);
        jobLauncherTestUtils.setJobLauncher(jobLauncher);
        jobLauncherTestUtils.setJobRepository(jobRepository);
        return jobLauncherTestUtils.launchJob(jobParameters);
    }

    @AfterEach
    protected void deleteAll() {
        pointWalletRepository.deleteAll();
        pointRepository.deleteAll();
        messageRepository.deleteAll();
        pointReservationRepository.deleteAll();
    }
}
  • 이 파일은, Job을 실행할 때 공통적으로 처리하는 부분들을 따로 빼서 유틸리티 느낌으로 계속 사용하기 위해 만든 클래스이다.
  • 테스트 코드를 작성하는 클래스는 모두 이 클래스를 상속받을 것이라 @SpringBootTest, @ActiveProfiles 애노테이션을 달아주었다. 
@Autowired
private JobLauncher jobLauncher;

@Autowired
private JobRepository jobRepository;
  • 이 두개는 스프링 배치에서 제공해주는 빈들이다. 잡을 실행하기 위한 빈인 JobLauncher, 스프링 메타데이터 테이블에 접근하기 위한 빈인 JobRepository.
protected JobExecution launchJob(Job job, JobParameters jobParameters) throws Exception {
    JobLauncherTestUtils jobLauncherTestUtils = new JobLauncherTestUtils();
    jobLauncherTestUtils.setJob(job);
    jobLauncherTestUtils.setJobLauncher(jobLauncher);
    jobLauncherTestUtils.setJobRepository(jobRepository);
    return jobLauncherTestUtils.launchJob(jobParameters);
}
  • 실제로 Job을 실행하는 메서드이다. 파라미터로는 실행할 Job, Job을 실행할 때 사용되는 Parameter를 받는다.
  • JobLauncherTestUtils는 스프링 배치 테스트 라이브러리에서 제공해주는 테스트를 할때 유용하게 사용할 수 있는 녀석이다. 위 코드에서처럼 Job, JobLauncher, JobRepository, JobParameters를 넘겨주고 Job을 실행할 수 있다.
@AfterEach
protected void deleteAll() {
    pointWalletRepository.deleteAll();
    pointRepository.deleteAll();
    messageRepository.deleteAll();
    pointReservationRepository.deleteAll();
}
  • 이 부분은 테스트를 진행하면서 생기는 레코드들을 전부 삭제하고 싶어서 만든 부분이다. 분명, 더 좋은 방법이 있을것이라고 생각한다. 원래 스프링 부트 테스트를 실행할 때 아무런 데이터베이스 정보를 넣어주지 않으면 메모리 H2 데이터베이스를 자동으로 사용하게 해주는데 그 데이터베이스에 스프링 메타데이터 테이블을 어떻게 넣는지 모르고 있는 상태라 테스트용 데이터베이스가 아닌 실제 데이터베이스로 테스트를 진행중이다. 그래서 위 코드를 사용중에 있다.

만료된 포인트 배치 작업 처리하기

ExpirePointJobConfigurationTest

package cwchoiit.pointbatch.point.job;

import cwchoiit.pointbatch.BatchTestSupport;
import cwchoiit.pointbatch.point.entity.Point;
import cwchoiit.pointbatch.point.entity.PointWallet;
import cwchoiit.pointbatch.point.repository.PointRepository;
import cwchoiit.pointbatch.point.repository.PointWalletRepository;
import org.junit.jupiter.api.Test;
import org.springframework.batch.core.Job;
import org.springframework.batch.core.JobExecution;
import org.springframework.batch.core.JobParameters;
import org.springframework.batch.core.JobParametersBuilder;
import org.springframework.beans.factory.annotation.Autowired;

import java.math.BigInteger;
import java.time.LocalDate;
import java.util.List;

import static org.assertj.core.api.Assertions.assertThat;
import static org.springframework.batch.core.ExitStatus.COMPLETED;

class ExpirePointJobConfigurationTest extends BatchTestSupport {

    @Autowired
    Job expirePointJob;

    @Autowired
    PointWalletRepository pointWalletRepository;

    @Autowired
    PointRepository pointRepository;

    @Test
    void expirePointJob() throws Exception {

        LocalDate earnDate = LocalDate.of(2024, 11, 1);
        LocalDate expireDate = LocalDate.of(2024, 11, 3);

        PointWallet savedPointWallet = pointWalletRepository.save(new PointWallet("userA", BigInteger.valueOf(6000)));

        pointRepository.save(new Point(savedPointWallet, BigInteger.valueOf(1000), earnDate, expireDate));
        pointRepository.save(new Point(savedPointWallet, BigInteger.valueOf(1000), earnDate, expireDate));
        pointRepository.save(new Point(savedPointWallet, BigInteger.valueOf(1000), earnDate, expireDate));

        JobParameters jobParameters = new JobParametersBuilder()
                .addString("today", "2024-11-09")
                .toJobParameters();
        JobExecution jobExecution = launchJob(expirePointJob, jobParameters);
        assertThat(jobExecution.getExitStatus()).isEqualTo(COMPLETED);

        List<Point> points = pointRepository.findAll();
        assertThat(points.stream().filter(Point::isExpired)).hasSize(3);

        PointWallet changedPointWallet = pointWalletRepository.findById(savedPointWallet.getId()).orElse(null);
        assertThat(changedPointWallet).isNotNull();
        assertThat(changedPointWallet.getAmount()).isEqualTo(BigInteger.valueOf(3000));
    }
}
  • 이제 첫번째 배치성 비즈니스 로직을 작성해보자. 우선, 가장 먼저 만료된 포인트를 처리하는 배치를 작성해보자.
  • 테스트 코드와 비즈니스 로직 코드를 같이 작성하자. 그래서 위 코드를 작성했다. 한 줄 한 줄 살펴보자.
LocalDate earnDate = LocalDate.of(2024, 11, 1);
LocalDate expireDate = LocalDate.of(2024, 11, 3);

PointWallet savedPointWallet = pointWalletRepository.save(new PointWallet("userA", BigInteger.valueOf(6000)));

pointRepository.save(new Point(savedPointWallet, BigInteger.valueOf(1000), earnDate, expireDate));
pointRepository.save(new Point(savedPointWallet, BigInteger.valueOf(1000), earnDate, expireDate));
pointRepository.save(new Point(savedPointWallet, BigInteger.valueOf(1000), earnDate, expireDate));
  • 우선, 이 부분은 데이터베이스에 레코드를 추가하는 부분이다. 필요한 엔티티는 PointWallet 엔티티 하나, Point 엔티티 3개가 필요하다. 그러니까 한명의 유저의 포인트 지갑에 포인트가 3개 들어간다고 보면 된다. 
  • 포인트는 3개 전부 다 1000 포인트, 포인트 지급일은 2024-11-01, 포인트 만료일은 2024-11-03일로 동일하다.
JobParameters jobParameters = new JobParametersBuilder()
                .addString("today", "2024-11-09")
                .toJobParameters();
JobExecution jobExecution = launchJob(expirePointJob, jobParameters);
assertThat(jobExecution.getExitStatus()).isEqualTo(COMPLETED);

List<Point> points = pointRepository.findAll();
assertThat(points.stream().filter(Point::isExpired)).hasSize(3);

PointWallet changedPointWallet = pointWalletRepository.findById(savedPointWallet.getId()).orElse(null);
assertThat(changedPointWallet).isNotNull();
assertThat(changedPointWallet.getAmount()).isEqualTo(BigInteger.valueOf(3000));
  • 그리고 Job을 실행하기 위한 JobParameters를 생성한다. today라는 key에 2024-11-09일 이라는 날짜를 입력한다.
  • 아까 BatchTestSupport에서 만든 launchJob(...) 메서드를 실행한다. JobexpirePointJob을 넘겨준다. 이 Job은 아직 만들지 않았다. 곧 만들어보자. JobParameters로는 today가 들어있는 jobParameters를 넘기자.
  • 그러니까, 오늘날짜보다 만료일이 더 이전인 포인트를 전부 유효하지 않은 포인트 처리를 하는 배치 작업인 것이다.
  • 그리고 배치 작업을 실행했으면 테스트 결과를 찍어봐야 하니까 실행한 JobExecutionExitStatus 값이 COMPLETED인지 확인하고, 모든 포인트들을 찾아서 포인트가 만료된 개수가 3개 모두 인지 확인하고, 포인트 지갑의 남아있는 포인트가 3000인지도 확인한다. 

 

자, 이제 Job을 만들어보자!

 

ExpirePointJobConfiguration

package cwchoiit.pointbatch.point.job;

import cwchoiit.pointbatch.point.job.validator.TodayJobParameterValidator;
import org.springframework.batch.core.Job;
import org.springframework.batch.core.Step;
import org.springframework.batch.core.job.builder.JobBuilder;
import org.springframework.batch.core.repository.JobRepository;
import org.springframework.context.annotation.Bean;
import org.springframework.context.annotation.Configuration;

@Configuration
public class ExpirePointJobConfiguration {

    @Bean
    public Job expirePointJob(JobRepository jobRepository, Step expirePointStep, TodayJobParameterValidator validator) {
        return new JobBuilder("expirePointJob", jobRepository)
                .validator(validator)
                .start(expirePointStep)
                .build();
    }
}
  • Job, Step 모두 빈으로 등록해야 한다. 그래서 @Bean 애노테이션을 사용한다.
  • 아까 만들기로 했던 expirePointJob을 만들자. 파라미터로는 JobRepository, Step, TodayJobParameterValidator가 들어간다. 아직 Step expirePointStep, TodayJobParameterValidator validator는 만들지 않았다.
  • JobBuilder를 통해서 새로운 Job을 만들고 validator 적용, 실행할 Step 적용을 하고 build()를 호출한다.

얼른 TodayJobParameterValidator를 만들어보자.

TodayJobParameterValidator

package cwchoiit.pointbatch.point.job.validator;

import org.springframework.batch.core.JobParameters;
import org.springframework.batch.core.JobParametersInvalidException;
import org.springframework.batch.core.JobParametersValidator;
import org.springframework.stereotype.Component;

import java.time.LocalDate;
import java.time.format.DateTimeParseException;

@Component
public class TodayJobParameterValidator implements JobParametersValidator {

    @Override
    public void validate(JobParameters parameters) throws JobParametersInvalidException {
        if (parameters == null) {
            throw new JobParametersInvalidException("JobParameters is null");
        }
        String today = parameters.getString("today");
        if (today == null) {
            throw new JobParametersInvalidException("JobParameters [today] is null");
        }

        try {
            LocalDate.parse(today);
        } catch (DateTimeParseException e) {
            throw new JobParametersInvalidException("JobParameters [today] is not a valid date");
        }
    }
}
  • 스프링 배치는 JobParameters를 검증할 수 있는 JobParametersValidator를 제공한다. 이것을 구현한 클래스가 바로 TodayJobParameterValidator이다.
  • 구현 로직은 간단하다. Parameter가 있는지, 있다면 today라는 파라미터가 있는지를 검증하고, today라는 파라미터의 값으로 LocalDate로 파싱이 가능한지를 검증한다. 셋 중 하나라도 문제가 발생하면 JobParametersInvalidException을 발생시킨다.

 

이제 expirePointStep을 만들어보자!

 

ExpirePointStepConfiguration

package cwchoiit.pointbatch.point.job;

import cwchoiit.pointbatch.point.entity.Point;
import cwchoiit.pointbatch.point.entity.PointWallet;
import cwchoiit.pointbatch.point.repository.PointRepository;
import cwchoiit.pointbatch.point.repository.PointWalletRepository;
import jakarta.persistence.EntityManagerFactory;
import org.springframework.batch.core.Step;
import org.springframework.batch.core.configuration.annotation.JobScope;
import org.springframework.batch.core.configuration.annotation.StepScope;
import org.springframework.batch.core.repository.JobRepository;
import org.springframework.batch.core.step.builder.StepBuilder;
import org.springframework.batch.item.ItemProcessor;
import org.springframework.batch.item.ItemWriter;
import org.springframework.batch.item.database.JpaPagingItemReader;
import org.springframework.batch.item.database.builder.JpaPagingItemReaderBuilder;
import org.springframework.beans.factory.annotation.Value;
import org.springframework.context.annotation.Bean;
import org.springframework.context.annotation.Configuration;
import org.springframework.transaction.PlatformTransactionManager;

import java.time.LocalDate;
import java.util.Map;

@Configuration
public class ExpirePointStepConfiguration {

    @Bean
    @StepScope
    public JpaPagingItemReader<Point> expirePointItemReader(EntityManagerFactory entityManagerFactory,
                                                            @Value("#{T(java.time.LocalDate).parse(jobParameters[today])}") LocalDate today) {
        return new JpaPagingItemReaderBuilder<Point>()
                .name("expirePointItemReader")
                .entityManagerFactory(entityManagerFactory)
                .queryString("SELECT p FROM Point p WHERE p.expireDate < :today and used = false and expired = false")
                .parameterValues(Map.of("today", today))
                .pageSize(1000)
                .build();
    }

    @Bean
    @StepScope
    public ItemProcessor<Point, Point> expirePointItemProcessor() {
        return point -> {
            point.setExpired(true);
            PointWallet wallet = point.getPointWallet();
            wallet.setAmount(wallet.getAmount().subtract(point.getAmount()));
            return point;
        };
    }

    @Bean
    @StepScope
    public ItemWriter<Point> expirePointItemWriter(PointRepository pointRepository,
                                                   PointWalletRepository pointWalletRepository) {
        return points -> {
            for (Point point : points) {
                if (point.isExpired()) {
                    pointRepository.save(point);
                    pointWalletRepository.save(point.getPointWallet());
                }
            }
        };
    }

    @Bean
    @JobScope
    public Step expirePointStep(JobRepository jobRepository,
                                PlatformTransactionManager transactionManager,
                                JpaPagingItemReader<Point> expirePointItemReader,
                                ItemProcessor<Point, Point> expirePointItemProcessor,
                                ItemWriter<Point> expirePointItemWriter) {
        return new StepBuilder("expirePointStep", jobRepository)
                .<Point, Point>chunk(1000, transactionManager)
                .reader(expirePointItemReader)
                .processor(expirePointItemProcessor)
                .writer(expirePointItemWriter)
                .build();
    }
}
  • StepStep을 구성하는 reader, processor, writer를 만들었다. 참고로 이게 어떤 내용인지는 이미 이전 포스팅에 다 작성을 했기 때문에 참고하면 된다. 가장 먼저, Step을 확인해보자.
@Bean
@JobScope
public Step expirePointStep(JobRepository jobRepository,
                            PlatformTransactionManager transactionManager,
                            JpaPagingItemReader<Point> expirePointItemReader,
                            ItemProcessor<Point, Point> expirePointItemProcessor,
                            ItemWriter<Point> expirePointItemWriter) {
    return new StepBuilder("expirePointStep", jobRepository)
            .<Point, Point>chunk(1000, transactionManager)
            .reader(expirePointItemReader)
            .processor(expirePointItemProcessor)
            .writer(expirePointItemWriter)
            .build();
}
  • 우선은 Step도 빈으로 등록되어야 하기 때문에 @Bean 애노테이션을 달았고, 이 Step을 사용하는 Job이 실행될 때 이 Step이 로딩되기를 원하기 때문에 @JobScope 애노테이션을 작성했다. 
  • StepBuilder를 사용해서, Step을 만들어내는데, 데이터베이스에 데이터가 너무 많은 경우 한번에 다 가져올 수 없으니 chunk를 통해 1000개씩 쪼개서 가져오도록 했고, reader, processor, writer를 집어넣었다.
  • 참고로 PlatformTransactionManager는 스프링에서 제공해주는 트랜잭션 매니저이다. 그러니까 이 작업동안에 사용할 트랜잭션을 제공한다고 보면 된다.

expirePointItemReader

@Bean
@StepScope
public JpaPagingItemReader<Point> expirePointItemReader(EntityManagerFactory entityManagerFactory,
                                                        @Value("#{T(java.time.LocalDate).parse(jobParameters[today])}") LocalDate today) {
    return new JpaPagingItemReaderBuilder<Point>()
            .name("expirePointItemReader")
            .entityManagerFactory(entityManagerFactory)
            .queryString("SELECT p FROM Point p WHERE p.expireDate < :today and used = false and expired = false")
            .parameterValues(Map.of("today", today))
            .pageSize(1000)
            .build();
}
  • 역시 이 Reader도 연관된 스텝이 사용될 때 로딩되도록 @StepScope를 사용했다.
  • 간단하게 JPAJPQL로 원하는 데이터를 읽어온다. 우리가 원하는건 "포인트 테이블에서 파라미터로 전달받은 오늘 날짜보다 만료일이 이전이고, 사용하지 않았고, 만료 체크되지도 않은 모든 포인트"를 가져오고 싶다.
  • 이렇게 가져온 데이터들이 Processor로 넘어간다.

expirePointItemProcessor

@Bean
@StepScope
public ItemProcessor<Point, Point> expirePointItemProcessor() {
    return point -> {
        point.setExpired(true);
        PointWallet wallet = point.getPointWallet();
        wallet.setAmount(wallet.getAmount().subtract(point.getAmount()));
        return point;
    };
}
  • 역시 이 Processor도 연관된 스텝이 사용될 때 로딩되도록 @StepScope를 사용했다.
  • 가져온 데이터를 Point 타입에서 Point 타입으로 처리할 것이므로(다른 말로 타입의 변환은 일으키지 않을 것이라는 말이다) <Point, Point>를 사용했다.
  • 각 포인트의 만료여부를 `true`로 변경한다.
  • 그리고 해당 포인트를 가지고 있는 PointWallet의 포인트 가격을 지금 이 포인트가 들고있는 가격만큼 차감한다. (만료된 포인트니까)

expirePointItemWriter

@Bean
@StepScope
public ItemWriter<Point> expirePointItemWriter(PointRepository pointRepository,
                                               PointWalletRepository pointWalletRepository) {
    return points -> {
        for (Point point : points) {
            if (point.isExpired()) {
                pointRepository.save(point);
                pointWalletRepository.save(point.getPointWallet());
            }
        }
    };
}
  • 역시 이 Writer도 연관된 스텝이 사용될 때 로딩되도록 @StepScope를 사용했다.
  • 이제 처리한 모든 포인트들을 순회하며, 만료여부가 `true`인 경우, 작업처리된 포인트와 포인트지갑을 반영해야 하므로 save()를 호출해준다.

 

이렇게 Job, Step, Reader, Processor, Writer를 전부 구현했다. 이제 실행해보자! 아까 테스트 코드로 만든 아래 코드를 실행하자!

@Test
void expirePointJob() throws Exception {

    LocalDate earnDate = LocalDate.of(2024, 11, 1);
    LocalDate expireDate = LocalDate.of(2024, 11, 3);

    PointWallet savedPointWallet = pointWalletRepository.save(new PointWallet("userA", BigInteger.valueOf(6000)));

    pointRepository.save(new Point(savedPointWallet, BigInteger.valueOf(1000), earnDate, expireDate));
    pointRepository.save(new Point(savedPointWallet, BigInteger.valueOf(1000), earnDate, expireDate));
    pointRepository.save(new Point(savedPointWallet, BigInteger.valueOf(1000), earnDate, expireDate));

    JobParameters jobParameters = new JobParametersBuilder()
            .addString("today", "2024-11-12")
            .toJobParameters();
    JobExecution jobExecution = launchJob(expirePointJob, jobParameters);
    assertThat(jobExecution.getExitStatus()).isEqualTo(COMPLETED);

    List<Point> points = pointRepository.findAll();
    assertThat(points.stream().filter(Point::isExpired)).hasSize(3);

    PointWallet changedPointWallet = pointWalletRepository.findById(savedPointWallet.getId()).orElse(null);
    assertThat(changedPointWallet).isNotNull();
    assertThat(changedPointWallet.getAmount()).isEqualTo(BigInteger.valueOf(3000));
}

실행 결과

  • 테스트가 성공적으로 끝났다. 다시 한번 실행해보자!

재실행 결과

  • 어? 테스트에 실패했다 왜 그럴까?

에러 내용은 다음과 같다.

A job instance already exists and is complete for identifying parameters={'today':'{value=2024-11-12, type=class java.lang.String, identifying=true}'}.  If you want to run this job again, change the parameters.
org.springframework.batch.core.repository.JobInstanceAlreadyCompleteException: A job instance already exists and is complete for identifying parameters={'today':'{value=2024-11-12, type=class java.lang.String, identifying=true}'}.  If you want to run this job again, change the parameters.
  • 쉽게 말해, 이미 같은 파라미터로 실행한 Job Instance가 존재한다는 것이다. 스프링 배치는 설계하기를 배치성 로직을 같은 파라미터로 한번 더 수행하는 것을 잘못된 수행으로 판단했다. 그도 그럴것이 배치성이라는게 날 잡아서 큰 작업을 한번에 처리하는건데 이것을 동일한 데이터로 한번 더하면 문제가 될 수 있다고 판단하는 것이다.
  • 그래서, 실행하기 전 아까 위에서 말한 메타데이터 테이블로 같은 파라미터로 실행된 Job이 있는지 먼저 확인을 한다. 

 

정리

아직 할 게 더 남았지만, 포스팅이 길어지니까 다음 포스팅에 계속하겠다. 그래도 포인트 만료시키는 배치 작업을 해보면서 어느정도 스프링 배치에 대해 감을 좀 잡았다.

728x90
반응형
LIST

'Spring Batch' 카테고리의 다른 글

이커머스 포인트 배치를 구현해보기 2  (0) 2024.11.22
Listener  (1) 2024.10.09
ItemWriter  (1) 2024.10.09
ItemProcessor  (2) 2024.10.09
ItemReader  (1) 2024.10.09
728x90
반응형
SMALL

참고자료

 

스프링 DB 1편 - 데이터 접근 핵심 원리 강의 | 김영한 - 인프런

김영한 | 백엔드 개발에 필요한 DB 데이터 접근 기술을 기초부터 이해하고, 완성할 수 있습니다. 스프링 DB 접근 기술의 원리와 구조를 이해하고, 더 깊이있는 백엔드 개발자로 성장할 수 있습니

www.inflearn.com

 

JDBC 이해

애플리케이션을 개발할 때, 중요한 데이터는 대부분 데이터베이스에 보관한다.

 

클라이언트가 애플리케이션 서버를 통해 데이터를 저장하거나 조회하면, 애플리케이션 서버는 다음 과정을 통해서 데이터베이스를 사용한다.

  • 커넥션 연결: 주로 TCP/IP를 통해 커넥션을 연결한다.
  • SQL 전달: 애플리케이션 서버는 DB가 이해할 수 있는 SQL을 연결된 커넥션을 통해 DB에 전달한다.
  • 결과 응답: DB는 전달된 SQL을 수행하고 그 결과를 응답한다. 애플리케이션 서버는 응답 결과를 활용한다.

 

문제는, 각각의 데이터베이스마다 커넥션을 연결하는 방법, SQL을 전달하는 방법, 그리고 결과를 응답 받는 방법이 모두 다르다는 점이다. 참고로 관계형 데이터베이스는 수십개가 있다. 여기에는 2가지 큰 문제가 있는데, 다음과 같다.

  • 데이터베이스를 다른 종류의 데이터베이스로 변경하면 애플리케이션 서버에 개발된 데이터베이스 사용 코드도 함께 변경해야 한다.
  • 개발자가 각각의 데이터베이스마다 커넥션 연결, SQL 전달, 그리고 그 결과를 응답 받는 방법을 새로 학습해야 한다.

이런 문제를 해결하기 위해 JDBC라는 자바 표준이 등장한다.

 

JDBC 표준 인터페이스

JDBC(Java Database Connectivity)는 자바에서 데이터베이스에 접속할 수 있도록 하는 자바 API다. JDBC는 데이터베이스에서 자료를 쿼리하거나 업데이트하는 방법을 제공한다.

대표적으로 다음 3가지 기능을 표준 인터페이스로 정의해서 제공한다.

  • java.sql.Connection → 연결
  • java.sql.Statement → SQL을 담은 내용
  • java.sql.ResultSet → SQL 요청 응답

자바는 이렇게 표준 인터페이스를 정의해두었다. 이제부터 개발자는 이 표준 인터페이스만 사용해서 개발하면 된다. 그런데 인터페이스만 있다고해서 기능이 동작하지는 않는다. 이 JDBC 인터페이스를 각각의 DB 벤더(회사)에서 자신의 DB에 맞도록 구현해서 라이브러리로 제공하는데, 이것을 JDBC 드라이버라고 한다. 예를 들어, MySQL에 접근할 수 있는 것은 MySQL JDBC 드라이버라고 하고, OracleDB에 접근할 수 있는 것은 Oracle JDBC 드라이버라고 한다.

 

MySQL 드라이버 사용

 

Oracle 드라이버 사용

 

JDBC의 등장으로 다음 2가지 문제가 해결되었다.

  • 데이터베이스를 다른 종류의 데이터베이스로 변경하면 애플리케이션 서버의 데이터베이스 사용 코드도 함께 변경해야 하는 문제를 애플리케이션 로직은 이제 JDBC 표준 인터페이스만 의존한다. 따라서 데이터베이스를 다른 종류의 데이터베이스로 변경하고 싶으면 JDBC 구현 라이브러리만 변경하면 된다. 즉, 드라이버만 변경하면 된다. 따라서 다른 종류의 데이터베이스로 변경해도 애플리케이션 서버의 사용 코드를 그대로 유지할 수 있다.
  • 개발자가 각각의 데이터베이스마다 커넥션 연결, SQL 전달, 그리고 그 결과를 응답 받는 방법을 새로 학습해야 하는 문제를 JDBC 표준 인터페이스 사용법만 학습하면 된다. 한번 배워두면 수십개의 데이터베이스에 모두 동일하게 적용할 수 있다.
표준화의 한계도 있다. JDBC의 등장으로 많은 것이 편리해졌지만, 각각의 데이터베이스마다 SQL, 데이터타입 등의 일부 사용법이 다르다. 대표적으로 실무에서 기본으로 사용하는 페이징 SQL은 각각의 데이터베이스마다 사용법이 다르다. 결국 데이터베이스를 변경하면 JDBC 코드는 변경하지 않아도 되지만, SQL은 해당 데이터베이스에 맞도록 변경해야 한다. 

 

 

JDBC와 최신 데이터 접근 기술

JDBC는 1997년에 출시될 정도로 오래된 기술이고, 사용하는 방법도 복잡하다. 그래서 최근에는 JDBC를 직접 사용하기 보다는 JDBC를 편리하게 사용하는 다양한 기술들이 존재한다. 대표적으로 SQL MapperORM 기술로 나눌 수 있다.

  • SQL Mapper
    • JDBC를 편리하게 사용하도록 도와준다.
    • SQL 응답 결과를 객체로 편리하게 변환해준다.
    • JDBC의 반복 코드를 제거해준다.
    • 개발자가 직접 SQL을 작성해야 한다.
    • 대표 기술로는 스프링 JdbcTemplate, MyBatis가 있다.

  • ORM 기술
    • ORM은 객체를 관계형 데이터베이스 테이블과 매핑해주는 기술이다. 이 기술 덕분에 개발자는 반복적인 SQL을 직접 작성하지 않고, ORM 기술이 개발자 대신에 SQL을 동적으로 만들어 실행해준다. 추가로 각각의 데이터베이스마다 다른 SQL을 사용하는 문제도 중간에서 해결해준다. 
    • 대표 기술로는 JPA가 있다. 

 

SQL Mapper vs ORM 기술

둘 다 장단점이 있다. SQL Mapper는 SQL만 직접 작성하면 나머지 번거로운 일은 SQL Mapper가 대신 해결해준다. 그래서 SQL만 작성할 줄 알면 금방 배워서 사용할 수 있다. ORM 기술은 SQL 자체를 작성하지 않아도 되어서 개발 생산성이 매우 높아진다. 편리한 반면 쉬운 기술은 아니므로 실무에서 사용하려면 깊이있게 학습해야 한다. 

중요한 점은, 이런 기술들도 내부에서는 모두 JDBC를 사용한다. 따라서 JDBC를 직접 사용하지 않더라도, JDBC가 어떻게 동작하는지 기본원리를 알아야 한다. 그래야 해당 기술들을 더 깊이있게 이해할 수 있고, 무엇보다 문제가 발생했을 때 근본적인 문제를 찾아서 해결할 수 있다. JDBC는 자바 개발자라면 꼭 알아두어야 하는 필수 기본 기술이다.

 

데이터베이스 연결

애플리케이션과 데이터베이스를 연결해보자. 먼저, 데이터베이스는 H2 데이터베이스를 사용하기로 한다. 그러려면 H2 데이터베이스 라이브러리가 추가되어야 한다. 그리고 스프링 부트를 사용하여 테스트한다.

 

ConnectionConst

package cwchoiit.jdbc.connection;

public abstract class ConnectionConst {
    public static final String URL = "jdbc:h2:tcp://localhost/~/h2/db/jdbc";
    public static final String USERNAME = "sa";
    public static final String PASSWORD = "";
}
  • 데이터베이스에 접속하는데 필요한 기본 정보를 편리하게 사용할 수 있도록 상수로 만들었다.
  • 이제 JDBC를 사용해서 실제 데이터베이스에 연결하는 코드를 작성해보자.
package cwchoiit.jdbc.connection;

import lombok.extern.slf4j.Slf4j;

import java.sql.Connection;
import java.sql.DriverManager;
import java.sql.SQLException;

import static cwchoiit.jdbc.connection.ConnectionConst.*;

@Slf4j
public class DBConnectionUtil {

    public static Connection getConnection() {
        try {
            Connection connection = DriverManager.getConnection(URL, USERNAME, PASSWORD);
            log.info("get connection = {}, class = {}", connection, connection.getClass());
            return connection;
        } catch (SQLException e) {
            throw new RuntimeException(e);
        }
    }
}
  • 데이터베이스에 연결하려면, JDBC가 제공하는 DriverManager.getConnection(...)을 사용하면 된다. 이렇게 하면 라이브러리에 있는 데이터베이스 드라이버를 찾아서 해당 드라이버가 제공하는 커넥션을 반환해준다. 여기서는 H2 데이터베이스 드라이버가 작동해서 실제 데이터베이스와 커넥션을 맺고, 그 결과를 반환해 줄 것이다.

DBConnectionUtilTests

package cwchoiit.jdbc.connection;

import lombok.extern.slf4j.Slf4j;
import org.junit.jupiter.api.Test;

import java.sql.Connection;

import static org.assertj.core.api.Assertions.assertThat;

@Slf4j
class DBConnectionUtilTests {

    @Test
    void connection() {
        Connection connection = DBConnectionUtil.getConnection();
        assertThat(connection).isNotNull();
    }
}

실행 결과

16:52:45.721 [Test worker] INFO cwchoiit.jdbc.connection.DBConnectionUtil -- get connection = conn0: url=jdbc:h2:tcp://localhost/~/h2/db/jdbc user=SA, class = class org.h2.jdbc.JdbcConnection
  • 실행 결과를 보면 class=class org.h2.jdbc.JdbcConnection 부분을 확인할 수 있다. 이것이 바로 H2 데이터베이스 드라이버가 제공하는 H2 전용 커넥션이다. 물론 이 커넥션은 JDBC 표준 커넥션 인터페이스인 java.sql.Connection 인터페이스를 구현하고 있다.

 

JDBC DriverManager 연결 이해

지금까지 코드로 확인해 본 과정을 좀 더 자세히 들여다보자.

JDBC 커넥션 인터페이스와 구현

  • JDBC는 java.sql.Connection 표준 커넥션 인터페이스를 정의한다.
  • H2 데이터베이스 드라이버는 JDBC Connection 인터페이스를 구현한 org.h2.jdbc.JdbcConnection 구현체를 제공한다.

DriverManager 커넥션 요청 흐름

  • JDBC가 제공하는 DriverManager는 라이브러리에 등록된 DB 드라이버들을 관리하고, 커넥션을 획득하는 기능을 제공한다.
  • 애플리케이션 로직에서 커넥션이 필요하면 DriverManager.getConnection(...)을 호출한다.
  • DriverManager는 라이브러리에 등록된 드라이버 목록을 자동으로 인식한다. 이 드라이버들에게 순서대로 다음 정보를 넘겨서 커넥션을 획득할 수 있는지 확인한다.
    • URL: jdbc:h2:tcp://localhost/~/h2/db/jdbc
    • 이름, 비밀번호 등 접속에 필요한 추가 정보
    • 여기서 각각의 드라이버는 URL 정보를 체크해서 본인이 처리할 수 있는 요청인지 확인한다. 예를 들어서 URL이 jdbc:h2로 시작하면 이것은 H2 데이터베이스에 접근하기 위한 규칙이다. 따라서 H2 드라이버는 본인이 처리할 수 있으므로 실제 데이터베이스에 연결해서 커넥션을 획득하고, 이 커넥션을 클라이언트에 반환한다. 반면에, URL이 jdbc:h2로 시작했는데 MySQL 드라이버가 먼저 실행되면 이 경우 본인이 처리할 수 없다는 결과를 반환하게 되고 다음 드라이버에게 순서가 넘어간다.
  • 이렇게 찾은 커넥션 구현체가 클라이언트에 반환된다.

우리는 H2 데이터베이스 드라이버만 라이브러리에 등록했기 때문에, H2 드라이버가 제공하는 H2 커넥션을 제공받는다. 물론, 이 H2 커넥션은 JDBC가 제공하는 java.sql.Connection 인터페이스를 구현하고 있다.

 

참고: H2 데이터베이스 드라이버 라이브러리

runtimeOnly 'com.h2database:h2' //h2-x.x.xxx.jar

 

 

JDBC 개발 - 등록

이제 본격적으로 JDBC를 사용해서 애플리케이션을 개발해보자. 사실 JDBC를 직접 사용해서 개발할 일은 앞으로 없을테지만, 이것을 한번 해보는 것은 엄청 큰 의의가 있다. 결국 나중에 사용할 JPA도 JDBC를 사용하는 거고 다 이 JDBC를 내부적으로 사용하는 것이기 때문에.

 

우선, 테이블을 먼저 간단하게 만들어두자.

create table member (
  member_id varchar(10),
  money integer not null default 0,
  primary key (member_id)
);

테이블을 만들었으면 이제 시작하면 된다. 먼저 Member 클래스 하나를 만들자.

 

Member

package cwchoiit.jdbc.domain;

import lombok.AllArgsConstructor;
import lombok.Data;
import lombok.NoArgsConstructor;

@Data
@NoArgsConstructor
@AllArgsConstructor
public class Member {
    private String memberId;
    private int money;
}
  • 회원의 ID와 해당 회원이 소지한 금액을 표현하는 단순한 클래스이다. 앞서 만들어둔 member 테이블에 데이터를 저장하고 조회할 때 사용한다. 

 

가장 먼저 JDBC를 사용해서 이렇게 만든 회원 객체를 데이터베이스에 저장해보자.

MemberRepositoryV0

package cwchoiit.jdbc.repository;

import cwchoiit.jdbc.connection.DBConnectionUtil;
import cwchoiit.jdbc.domain.Member;
import lombok.extern.slf4j.Slf4j;

import java.sql.Connection;
import java.sql.PreparedStatement;
import java.sql.SQLException;

/**
 * JDBC - DriverManager 사용
 */
@Slf4j
public class MemberRepositoryV0 {

    public Member save(Member member) throws SQLException {
        String sql = "INSERT INTO member (member_id, money) VALUES (?, ?)";


        try (Connection connection = getConnection();
             PreparedStatement stmt = connection.prepareStatement(sql)) {
            stmt.setString(1, member.getMemberId());
            stmt.setInt(2, member.getMoney());
            stmt.executeUpdate();
            return member;
        } catch (SQLException e) {
            log.error("DB Error", e);
            throw e;
        }
    }

    private Connection getConnection() {
        return DBConnectionUtil.getConnection();
    }
}
  • 커넥션을 획득하는 메서드인 getConnection()을 먼저 보자. 이전에 만든 DBConnectionUtilgetConnection() 메서드를 호출하는 메서드이다. 이 MemberRepositoryV0에서 여러번 사용될 예정이라 따로 메서드로 뽑았다. 내부적으로 DriverManager를 사용한다.
  • save() 메서드를 살펴보자. JDBC를 사용하려면 SQL을 직접 작성해야 한다. 여기서는 데이터를 등록해야 하므로 INSERT 쿼리를 작성한다. 
  • 데이터베이스에 대한 Connection과 데이터베이스에 전달할 SQL과 파라미터로 전달할 데이터를 가지고 있는 Statement는 반드시 사용한 후 반납해야 한다. 그래서 try-with-resources 구문을 사용해서 어떤일이 있어도 반납할 수 있도록 했다.
  • 회원 데이터를 만들기 위해 필요한 데이터인 `member_id``money`를 파라미터로 던진다. 그때, PreparedStatementsetString(), setInt()를 사용해서 각 숫자에 맞는(물음표가 먼저 나오는 순서대로) 파라미터를 전달한다. 
  • PreparedStatementStatement의 자식 타입인데, `?`를 통한 파라미터 바인딩을 가능하게 해준다. 참고로 SQL Injection 공격을 예방하려면 PreparedStatement를 통한 파라미터 바인딩 방식을 사용해야 한다.
  • 준비된 SQL을 커넥션을 통해 실제 데이터베이스에 전달한다. 참고로 executeUpdate()int를 반환하는데 이 값은 영향받은 Row수를 반환한다. 

 

이제 테스트 코드를 사용해서 이 코드를 사용해보자.

MemberRepositoryV0Test

package cwchoiit.jdbc.repository;

import cwchoiit.jdbc.domain.Member;
import org.junit.jupiter.api.Test;

import java.sql.SQLException;

import static org.junit.jupiter.api.Assertions.*;

class MemberRepositoryV0Test {

    private final MemberRepositoryV0 repository = new MemberRepositoryV0();

    @Test
    void save() throws SQLException {
        Member member0 = new Member("member0", 10000);
        repository.save(member0);
    }
}

실행 결과를 확인해보면, 데이터베이스에 정상적으로 데이터가 들어간 것을 확인할 수 있을 것이다.

 

JDBC 개발 - 조회

이번에는 JDBC를 통해 이전에 저장한 데이터를 조회하는 기능을 개발해보자.

MemberRepositoryV0 - 회원 조회 추가

public Member findById(String memberId) throws SQLException {
    String sql = "SELECT * FROM member WHERE member_id = ?";

    try (Connection connection = getConnection();
         PreparedStatement stmt = connection.prepareStatement(sql)) {
        stmt.setString(1, memberId);

        try (ResultSet rs = stmt.executeQuery()) {
            if (rs.next()) {
                Member member = new Member();
                member.setMemberId(rs.getString("member_id"));
                member.setMoney(rs.getInt("money"));
                return member;
            } else {
                throw new NoSuchElementException("Member not found with id = " + memberId);
            }
        }
    } catch (SQLException e) {
        log.error("DB Error", e);
        throw e;
    }
}
  • 여기서는, ResultSet이 등장했다. 조회의 경우 조회한 데이터를 보관하고 있는 녀석이 필요한데 그게 바로 이 녀석이다. 그리고 조회의 경우 executeQuery()를 사용한다. 데이터를 변경할땐 executeUpdate()를 사용했었다. 그래서 executeQuery()를 실행한 결과를 ResultSet에 담아서 반환한다. 그리고 이 녀석 역시 사용한 후엔 반납을 해야한다. 그런데, 사용하기 전에 PreparedStatement를 통해 파라미터 바인딩을 해줘야하기 때문에 같은 try-with-resourcesResultSet을 묶을수가 없다. 그래서 내부에 한번의 try가 더 있다.
  • rs.next()는 데이터베이스에 쿼리를 날려서 얻은 데이터에 대한 cursor를 다음으로 넘기는 메서드이다. 참고로 최초에는 커서가 데이터를 가리키고 있지 않기 때문에 최초에 한번은 호출을 해야 데이터를 조회할 수 있다. 아래 그림을 보자.

  • 최초에는 커서가 데이터를 가리키지 않고 있다가 한번 호출을 하면 가장 처음 데이터를 가리킬 것이다. 그래서 데이터가 있다면 `true`를 반환한다. 그럼 데이터를 가져오면 된다. 
  • rs.next()를 호출해서 커서가 다음 레코드로 이동했는데 데이터가 없으면 `false`를 반환한다. 
  • findById() 메서드는 회원 한명을 조회한다. 따라서 조회 결과가 항상 1건이거나 0건이므로 while() 대신 if()를 사용해서 rs.next()를 호출한다. 그래서 최초에도 데이터가 없다면 이 ID를 가진 회원이 없다는 뜻이므로 NoSuchElementException을 발생시킨다.

 

테스트 코드에 이 메서드를 추가해보자!

package cwchoiit.jdbc.repository;

import cwchoiit.jdbc.domain.Member;
import lombok.extern.slf4j.Slf4j;
import org.assertj.core.api.Assertions;
import org.junit.jupiter.api.Test;

import java.sql.SQLException;

import static org.assertj.core.api.Assertions.*;
import static org.junit.jupiter.api.Assertions.*;

@Slf4j
class MemberRepositoryV0Test {

    private final MemberRepositoryV0 repository = new MemberRepositoryV0();

    @Test
    void save() throws SQLException {
        Member member = new Member("member2", 10000);
        repository.save(member);

        Member findMember = repository.findById(member.getMemberId());
        log.info("findMember = {}", findMember);

        assertThat(findMember).isEqualTo(member);
    }
}

실행 결과

13:37:46.054 [Test worker] INFO cwchoiit.jdbc.connection.DBConnectionUtil -- get connection = conn0: url=jdbc:h2:tcp://localhost/~/h2/db/jdbc user=SA, class = class org.h2.jdbc.JdbcConnection
13:37:46.060 [Test worker] INFO cwchoiit.jdbc.connection.DBConnectionUtil -- get connection = conn1: url=jdbc:h2:tcp://localhost/~/h2/db/jdbc user=SA, class = class org.h2.jdbc.JdbcConnection
13:37:46.062 [Test worker] INFO cwchoiit.jdbc.repository.MemberRepositoryV0Test -- findMember = Member(memberId=member2, money=10000)
  • 테스트는 정상적으로 통과한다.
  • 로그를 보면, 두개의 커넥션을 얻고 있음을 알 수 있다. 한번은 save(), 한번은 findById().
  • 이러니까 커넥션 반납은 필수이고 굉장히 중요한 것이다. 커넥션은 한정적이라 계속 물고 있으면 고갈된다. 

JDBC 개발 - 수정, 삭제

수정과 삭제는 등록과 비슷하다. 등록, 수정, 삭제처럼 데이터를 변경하는 쿼리는 executeUpdate()를 사용하면 된다.

public void update(String memberId, int money) throws SQLException {
    String sql = "UPDATE member SET money = ? WHERE member_id = ?";
    try (Connection connection = getConnection();
         PreparedStatement stmt = connection.prepareStatement(sql)) {

        stmt.setInt(1, money);
        stmt.setString(2, memberId);
        int resultSize = stmt.executeUpdate();
        log.info("resultSize = {}", resultSize);
    } catch (SQLException e) {
        log.error("DB Error", e);
        throw e;
    }
}
  • executeUpdate()는 쿼리를 실행하고 영향받은 Row수를 반환한다. 여기서는 하나의 데이터만 변경하기 때문에 결과로 1이 반환된다. 만약, 회원이 100명이고, 모든 회원의 데이터를 한번에 수정하는 UPDATE 쿼리를 실행하면 결과는 100이 될 것이다.
public void delete(String memberId) throws SQLException {
    String sql = "DELETE FROM member WHERE member_id = ?";

    try (Connection connection = getConnection();
         PreparedStatement stmt = connection.prepareStatement(sql)) {

        stmt.setString(1, memberId);
        stmt.executeUpdate();
    } catch (SQLException e) {
        log.error("DB Error", e);
        throw e;
    }
}
  • 위 업데이트와 쿼리만 DELETE로 달라질 뿐 나머지는 동일하다.

 

계속해서 사용했던 테스트 코드에 추가적으로 수정과 삭제를 넣어보자!

@Test
void save() throws SQLException {
    Member member = new Member("member4", 10000);
    repository.save(member);

    Member findMember = repository.findById(member.getMemberId());
    log.info("findMember = {}", findMember);

    assertThat(findMember).isEqualTo(member);

    repository.update(member.getMemberId(), 20000);
    Member updatedMember = repository.findById(member.getMemberId());
    assertThat(updatedMember.getMoney()).isEqualTo(20000);

    repository.delete(member.getMemberId());
    assertThatThrownBy(() -> repository.findById(member.getMemberId()))
            .isInstanceOf(NoSuchElementException.class);
}
  • 실행 결과는 정상적으로 업데이트가 되고 삭제가 될 것이다.

 

정리

이렇게해서 JDBC를 통한 데이터베이스와 상호작용을 다시한번 리마인드해봤다. 현재 가장 핫한 ORM 기술인 JPA도 결국 내부적으로 JDBC를 사용하는 것이기 때문에 이 JDBC가 어떻게 동작하고 어떤 원리를 통해 데이터베이스에 접근해 커넥션을 가져오는지 이해하는게 중요하다. 결국 JDBC라는 표준 인터페이스를 구현한 각각의 데이터베이스마다 드라이버를 제공하고 그 드라이버를 라이브러리에 추가하면 JDBC가 자동으로 라이브러리에 추가된 드라이버를 인식하고 커넥션을 가져올 수 있는 드라이버를 찾는다. 이게 항상 말하지만 표준과 그것을 구현한 구현체의 위대함이다. 내가 데이터베이스를 변경하더라도 구현체만 갈아끼우면 되고 실제 클라이언트 코드는 변경할 필요가 없다. (물론 SQL은 데이터베이스마다 방언이라는게 존재하기 때문에 달라진다면 변경해야 겠지만)

 

자, 이제 JDBC를 다시 한번 리마인드했으니 이제 Connection PoolDataSource에 대해 공부할 차례다.

728x90
반응형
LIST

'Spring + Database' 카테고리의 다른 글

[Renewal] 예외  (0) 2024.12.05
[Renewal] 스프링의 트랜잭션  (0) 2024.11.24
[Renewal] 트랜잭션, DB 락 이해  (0) 2024.11.22
[Renewal] 커넥션풀과 DataSource 이해  (2) 2024.11.21
Index란? (DB)  (0) 2024.04.05
728x90
반응형
SMALL

이번 포스팅에는 OSIV가 무엇인지, 이게 어떤 성능에 영향을 주는지 알아보는 시간을 가져보자!

OSIV(Open Session In View)라는 이 녀석은, 스프링을 사용하면 이런 설정값으로 표현된다.

spring.jpa.open-in-view

근데, 이 값이 기본으로 `true`이다. 즉, 아무것도 설정하지 않으면 이 설정이 켜져있는건데 이게 켜져있으면 데이터베이스 커넥션이 반납되는 시점이 크게 달라진다. 

 

자, 다음 코드를 보자.

package cwchoiit.shoppingmall.service;

import cwchoiit.shoppingmall.domain.Member;
import cwchoiit.shoppingmall.repository.MemberRepository;
import lombok.RequiredArgsConstructor;
import org.springframework.stereotype.Service;
import org.springframework.transaction.annotation.Transactional;

import java.util.List;

@Service
@RequiredArgsConstructor
@Transactional(readOnly = true)
public class MemberService {

    private final MemberRepository memberRepository;

    @Transactional
    public Long signup(Member member) {
        validateDuplicateMember(member);

        memberRepository.save(member);
        return member.getId();
    }
}
  • 여기보면 signup() 이라는 메서드가 하나 있고, @Transactional 애노테이션이 달려있다.
  • JPA는 @Transactional 애노테이션이 붙어있는 메서드가 실행하는 시점에 커넥션을 받아온다. 그리고 일반적으로 @Transactional 애노테이션이 달린 메서드가 끝나면 커넥션을 반납하게 된다.
  • 그런데, 이 OSIV가 켜져있으면 메서드가 끝나는 시점에 커넥션을 반환하지 않는다. 
  • 그럼 언제 반환하지? 자, 이 signup()을 호출한 컨트롤러로 넘어가보자.
@PostMapping("/members/new")
public String create(@Validated MemberForm memberForm, BindingResult bindingResult) {
    if (bindingResult.hasErrors()) {
        return "members/createMemberForm";
    }

    Address address = new Address(memberForm.getCity(), memberForm.getStreet(), memberForm.getZipCode());

    Member member = Member.builder()
            .name(memberForm.getName())
            .address(address)
            .build();

    memberService.signup(member);
    return "redirect:/";
}
  • 이 컨트롤러에서 signup()을 호출하는데, 호출하고 다시 돌아오는 시점에도, 커넥션은 반환되지 않는다. 그리고 사용자에게 최종적으로 화면이 뿌려지고 완전히 응답이 끝나면! 그때 커넥션을 반납한다.
  • 왜 그러냐면, 만약, 데이터베이스를 통해 데이터를 받아왔는데 이 데이터 중 프록시를 초기화해야 하는 데이터가 있을수도 있기 때문에 그때까지 영속성 컨텍스트를 살려두어야만 초기화가 가능하기 때문이다.
  • 프록시 초기화는 반드시 영속성 컨텍스트가 관리하고 있는 엔티티여야만 가능하다!

그럼, 결국 OSIV가 켜져있으면, API라면 호출한 곳으로부터 응답이 완전히 다 나가고 나서 커넥션이 반납되고, API가 아니라 뷰를 반환하는 경우라면 템플릿이 완전히 다 만들어지고 사용자에게 화면이 뿌려지는 시점에 커넥션이 반납된다.

 

그러니까, OSIV는 장단점이 있다. 컨트롤러나 뷰 레이어에서도 지연로딩을 처리할 수도 있다는 장점이 있지만 단점은 커넥션을 너무 오랫동안 유지하고 있다는 점이다. 그래서 자칫 잘못하면 커넥션이 반납이 너무 느려져서 말라버릴 수도 있다. 그럼 도대체 이 옵션은 켜야하나 꺼야하나? 끄면 모든 지연로딩을 트랜잭션 안에서 처리해야 하는 단점이 있지만, 키면 커넥션을 너무 오랫동안 가지고 있다는 단점이 있다. 

 

 

내가 생각하는 좋은 방법은..

  • OSIV 옵션을 끈다.
  • 모든 지연로딩을 페치 조인이나, 중간 레이어를 두어서 컨트롤러나 뷰에서 처리할 필요가 없도록 데이터를 받아온다.

그래서, 커넥션을 너무 오랫동안 유지하고 있지 않도록 하는게 가장 좋은 방법인것 같다. 어차피 지연로딩을 초기화해야 하는 경우라면 페치 조인을 사용해서 처음부터 모든 데이터를 받아오도록 하면 될 것이고, 바로 지연로딩이 초기화가 필요한 게 아니라 특정 순간에만 필요한 경우 중간 레이어 하나를 만들어서 쿼리와 커맨드를 분리해서 한번 더 트랜잭션의 도움을 받으면 될 것 같다. 

 

근데 이게 뭐 딱 정해진 정답이 있는게 아니라 상황에 따라 잘 활용하면 될 것 같다. 예를 들어 이렇게 하는 것이다.

  • 고객 서비스의 실시간 APIOSIV를 꺼서 최대한 커넥션 반납을 빠르게 하고, ADMIN 화면과 같은 커넥션을 많이 사용하지 않는 곳에서는 OSIV를 키는 방식으로 유연하게 적용한다.

 

 

728x90
반응형
LIST
728x90
반응형
SMALL

이번 포스팅에는 JPA를 통해 컬렉션을 조회할 때 최적화하는 방법을 설명한다. ToMany 관계에 있는 데이터를 가져올때 문제가 되는 부분들과 그 문제를 해결하는 방법을 설명한다.

 

우선, OneToMany 관계에 있는 OrderOrderItems를 API로 반환해보자.

 

1. 모든 엔티티를 제거하고 DTO로 변환하라

@GetMapping("/api/v2/orders")
public List<OrderDto> ordersV2() {
    List<Order> orders = orderRepository.findAllByCriteria(new OrderSearch());
    return orders.stream().map(OrderDto::new).toList();
}
  • 일단 @GetMapping으로 REST API 하나를 매핑시키고, 반환하는 데이터는 반드시 DTO로 변환하자.
  • 아 물론, 반환 데이터는 응답 공통 객체로 감싸는게 더 좋다. 그래야 전체 개수나 페이지 수 같은 메타데이터도 포함시킬 수 있기 때문이다. 여기서는 단순화를 위해 데이터만 반환하도록 했다.
@Data
static class OrderDto {
    private Long orderId;
    private String name;
    private LocalDateTime orderDate;
    private OrderStatus orderStatus;
    private Address address;
    private List<OrderItemDto> orderItems;

    public OrderDto(Order order) {
        this.orderId = order.getId();
        this.name = order.getMember().getName();
        this.orderDate = order.getOrderDate();
        this.orderStatus = order.getStatus();
        this.address = order.getDelivery().getAddress();

        this.orderItems = order.getOrderItems().stream().map(OrderItemDto::new).toList();
    }
}

@Data
static class OrderItemDto {
    private String itemName;
    private int orderPrice;
    private int count;

    public OrderItemDto(OrderItem orderItem) {
        this.itemName = orderItem.getItem().getName();
        this.orderPrice = orderItem.getOrderPrice();
        this.count = orderItem.getCount();
    }
}
  • 반환하려는 OrderDto는 이렇게 생겼다. 여기서 중요한 점은, OrderItems에 해당하는 데이터 역시 DTO로 변환해야 한다는 점이다. 엔티티를 DTO로 변환하라는 말은 껍데기만 DTO를 사용하라는 말이 아니라 모든 엔티티가 없어야 한다.
  • 그래서, orderItems 타입도 역시 DTO로 만들기 위해 OrderItemDto도 존재한다.

 

이 상태에서 REST API를 호출해보자. 아래와 같은 결과가 나온다.

[
  {
    "orderId": 1,
    "name": "userA",
    "orderDate": "2024-11-17T13:40:39.935598",
    "orderStatus": "ORDER",
    "address": {
      "city": "서울",
      "street": "1",
      "zipCode": "1111"
    },
    "orderItems": [
      {
        "itemName": "JPA BOOK 1",
        "orderPrice": 10000,
        "count": 1
      },
      {
        "itemName": "JPA BOOK 2",
        "orderPrice": 20000,
        "count": 2
      }
    ]
  },
  {
    "orderId": 2,
    "name": "userB",
    "orderDate": "2024-11-17T13:40:39.940763",
    "orderStatus": "ORDER",
    "address": {
      "city": "경기",
      "street": "2",
      "zipCode": "2222"
    },
    "orderItems": [
      {
        "itemName": "SPRING BOOK 1",
        "orderPrice": 10000,
        "count": 1
      },
      {
        "itemName": "SPRING BOOK 2",
        "orderPrice": 20000,
        "count": 2
      }
    ]
  }
]
  • 결과는 원하는대로 잘 나왔다

여기서 끝낼 수 없다. 우선, 엔티티는 모두가 다 지연로딩이기 때문에 이 API를 호출하는 순간, 정말 많은 쿼리가 나갈것이다. 왜냐하면 아직 페치 조인으로 쿼리 최적화를 한 상태가 아니기 때문에. 그래서 엔티티를 DTO로 변환하는 것까진 좋지만 이제 쿼리 최적화를 위해 페치 조인을 사용해보자.

 

2. 쿼리 최적화를 위해 페치 조인을 사용하라

이제 페치 조인을 사용해서, 조인을 함과 동시에 셀렉트 절에 필드에 값을 채워넣는 작업까지 한번의 쿼리로 끝내보자. JPA가 제공하는 막강한 기능이다.

OrderRepository 일부분

public List<Order> findAllWithItem() {
    return entityManager.createQuery(
            "SELECT 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)
            .getResultList();
}
  • 다음 코드와 같이 관련된 모든 엔티티에 대해 페치 조인을 사용했다. 이러면 SQL문으로 조인을 하는것까진 똑같은데 조인을 한 다음 실제 그 데이터를 메모리에 올려서 필드에 퍼올려주게 된다. 
  • 그런데 여기서 문제는 바로, o.orderItems를 페치 조인하는 것이다. 이 녀석은 OneToMany 관계로 설정된 컬렉션이다. 컬렉션을 페치 조인하게 되면 데이터가 뻥튀기가 된다. 결과를 보자.

OrderController 일부분

@GetMapping("/api/v3/orders")
public List<OrderDto> ordersV3() {
    return orderRepository.findAllWithItem().stream().map(OrderDto::new).toList();
}
  • 페치 조인을 사용하는 메서드를 호출한다. 이 녀석을 API로 호출해보자. 호출을 해보면 실제로 쿼리가 어떻게 나가는지 볼 수 있는데, 다음과 같이 나간다.
select
        o1_0.order_id,
        d1_0.delivery_id,
        d1_0.city,
        d1_0.street,
        d1_0.zip_code,
        d1_0.status,
        m1_0.member_id,
        m1_0.city,
        m1_0.street,
        m1_0.zip_code,
        m1_0.name,
        o1_0.order_date,
        oi1_0.order_id,
        oi1_0.order_item_id,
        oi1_0.count,
        i1_0.item_id,
        case 
            when i1_1.item_id is not null 
                then 1 
            when i1_2.item_id is not null 
                then 2 
            when i1_3.item_id is not null 
                then 3 
        end,
        i1_0.name,
        i1_0.price,
        i1_0.stock_quantity,
        i1_1.artist,
        i1_1.etc,
        i1_2.author,
        i1_2.isbn,
        i1_3.actor,
        i1_3.director,
        oi1_0.order_price,
        o1_0.status 
    from
        orders o1_0 
    join
        member m1_0 
            on m1_0.member_id=o1_0.member_id 
    join
        delivery d1_0 
            on d1_0.delivery_id=o1_0.delivery_id 
    join
        order_item oi1_0 
            on o1_0.order_id=oi1_0.order_id 
    join
        (item i1_0 
    left join
        album i1_1 
            on i1_0.item_id=i1_1.item_id 
    left join
        book i1_2 
            on i1_0.item_id=i1_2.item_id 
    left join
        movie i1_3 
            on i1_0.item_id=i1_3.item_id) 
        on i1_0.item_id=oi1_0.item_id
  • 쿼리는 매우 행복하게 딱 한개만 나간다. 이게 페치 조인의 힘이다. 근데 이 쿼리를 실제로 데이터베이스에서 날려보면 어떻게 될까? 결과는 다음과 같다.

  • 보다시피 Order 레코드는 ID가 1, 2로 2개뿐이지만, OneToMany 관계에 있는 OrderItems와 조인을 해버리니까 데이터가 4개로 뻥튀기 됐다. 왜냐하면 1번 주문이 가지고 있는 OrderItem이 2개다 보니까 1번 주문의 레코드가 2개가 나올수밖에 없다. 2번도 마찬가지 이유다.

이게 바로 OneToMany 관계에 있는 엔티티와 조인할 때 즉, 컬렉션을 조인할때 생기는 데이터 뻥튀기 현상이다. 이걸 가지고 페이징 처리를 한다면? 뭔가 문제가 생길 수 밖에 없다. 그래서 이를 해결하기 위해 JPA에서 무엇을 제공하냐? `DISTINCT` 라는 키워드를 제공한다.

 

"어? 데이터베이스에서 그냥 제공하는 키워드 아닌가요?" → 맞다. 맞는데, JPA가 추가적인 기능을 제공한다. 일단 사용을 해보자.

public List<Order> findAllWithItem() {
    return entityManager.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)
            .getResultList();
}
  • 다음과 같이 JPQLDISTINCT만 추가했다.
  • 실행한 다음 나간 쿼리를 한번 보자. 
select
        distinct o1_0.order_id,
        d1_0.delivery_id,
        d1_0.city,
        d1_0.street,
        d1_0.zip_code,
        d1_0.status,
        m1_0.member_id,
        m1_0.city,
        m1_0.street,
        m1_0.zip_code,
        m1_0.name,
        o1_0.order_date,
        oi1_0.order_id,
        oi1_0.order_item_id,
        oi1_0.count,
        i1_0.item_id,
        case 
            when i1_1.item_id is not null 
                then 1 
            when i1_2.item_id is not null 
                then 2 
            when i1_3.item_id is not null 
                then 3 
        end,
        i1_0.name,
        i1_0.price,
        i1_0.stock_quantity,
        i1_1.artist,
        i1_1.etc,
        i1_2.author,
        i1_2.isbn,
        i1_3.actor,
        i1_3.director,
        oi1_0.order_price,
        o1_0.status 
    from
        orders o1_0 
    join
        member m1_0 
            on m1_0.member_id=o1_0.member_id 
    join
        delivery d1_0 
            on d1_0.delivery_id=o1_0.delivery_id 
    join
        order_item oi1_0 
            on o1_0.order_id=oi1_0.order_id 
    join
        (item i1_0 
    left join
        album i1_1 
            on i1_0.item_id=i1_1.item_id 
    left join
        book i1_2 
            on i1_0.item_id=i1_2.item_id 
    left join
        movie i1_3 
            on i1_0.item_id=i1_3.item_id) 
        on i1_0.item_id=oi1_0.item_id
  • 이 나간 쿼리에도 DISTINCT가 붙어있다. 근데 이 쿼리 그대로 복사해서 데이터베이스에 실제로 날려보면 결과 어떻게 나올까? 안타깝게도 전혀 달라지지 않는다.

  • 이런 현상의 이유는 데이터베이스의 DISTINCT는 정말 레코드의 모든 값이 다 똑같아야 중복으로 판단하고 제거해준다. 그런데 위 결과를 보면, 1번 주문의 2개의 레코드는 Order 관련 데이터만 동일하고, 나머지 값은 다르다. OrderItem이 다르니까.

그런데 API 날리고 받은 응답을 보면, 데이터는 두개만 보여진다.

[
  {
    "orderId": 1,
    "name": "userA",
    "orderDate": "2024-11-17T14:24:10.567046",
    "orderStatus": "ORDER",
    "address": {
      "city": "서울",
      "street": "1",
      "zipCode": "1111"
    },
    "orderItems": [
      {
        "itemName": "JPA BOOK 1",
        "orderPrice": 10000,
        "count": 1
      },
      {
        "itemName": "JPA BOOK 2",
        "orderPrice": 20000,
        "count": 2
      }
    ]
  },
  {
    "orderId": 2,
    "name": "userB",
    "orderDate": "2024-11-17T14:24:10.571629",
    "orderStatus": "ORDER",
    "address": {
      "city": "경기",
      "street": "2",
      "zipCode": "2222"
    },
    "orderItems": [
      {
        "itemName": "SPRING BOOK 1",
        "orderPrice": 10000,
        "count": 1
      },
      {
        "itemName": "SPRING BOOK 2",
        "orderPrice": 20000,
        "count": 2
      }
    ]
  }
]
  • 이게 JPA가 추가적으로 해주는 기능이다. JPA는 DISTINCT를 사용하면, 우선 SQL에도 그 키워드를 붙여준다. 그래서 만약, 레코드의 모든 값이 동일한 레코드가 있다면 하나만 보여주게 해준다.
  • 두번째로는, JPA가 추가적으로 제공하는 기능인데 가져온 데이터를 메모리에 퍼 올릴때, 반환 엔티티에 대한 ID가 동일하다면 (여기서는 Order) 그 값은 중복된 것으로 판단하고 메모리에 올리지 않는다. 이게 JPA가 해주는 추가적인 기능이다.

 

그래서 결론적으로 깔끔하게 DTO와 페치조인을 사용해서 일대다 조인을 사용할때도 깔끔하게 데이터를 가져올 수 있게 됐다. 그런데, 이때 정말 치명적인 문제가 하나 발생한다. 일대다 페치 조인을 하는 순간 페이징 처리가 불가능하다. 

 

2-1. 일대다 페치 조인을 할 때 페이징이 불가능한 문제

바로 위에서 일대다 페치 조인을 할 때 치명적인 문제를 말했다. 즉, 페이징 처리가 불가능해진다. 바로 코드로 보자.

페이징 처리라는 게 별게 아니라 다음과 같이 사용하면 된다.

public List<Order> findAllWithItem() {
    return entityManager.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(1000)
            .getResultList();
}
  • setFirstResult(1), setMaxResults(1000) 을 사용해서 0번은 건너뛰고 1번부터 1000개를 가져오는 쿼리를 작성했다. 그러면 여기서 드는 생각은, 아 지금 현재 데이터는 2개니까 앞에꺼 하나를 건너뛰고 뒤에꺼 한 개만 가져오겠군?! 이라고 생각이 든다.

근데 이거 실제로 실행해보자. 실행해보면, 날라가는 쿼리가 다음과 같다.

select
        distinct o1_0.order_id,
        d1_0.delivery_id,
        d1_0.city,
        d1_0.street,
        d1_0.zip_code,
        d1_0.status,
        m1_0.member_id,
        m1_0.city,
        m1_0.street,
        m1_0.zip_code,
        m1_0.name,
        o1_0.order_date,
        oi1_0.order_id,
        oi1_0.order_item_id,
        oi1_0.count,
        i1_0.item_id,
        case 
            when i1_1.item_id is not null 
                then 1 
            when i1_2.item_id is not null 
                then 2 
            when i1_3.item_id is not null 
                then 3 
        end,
        i1_0.name,
        i1_0.price,
        i1_0.stock_quantity,
        i1_1.artist,
        i1_1.etc,
        i1_2.author,
        i1_2.isbn,
        i1_3.actor,
        i1_3.director,
        oi1_0.order_price,
        o1_0.status 
    from
        orders o1_0 
    join
        member m1_0 
            on m1_0.member_id=o1_0.member_id 
    join
        delivery d1_0 
            on d1_0.delivery_id=o1_0.delivery_id 
    join
        order_item oi1_0 
            on o1_0.order_id=oi1_0.order_id 
    join
        (item i1_0 
    left join
        album i1_1 
            on i1_0.item_id=i1_1.item_id 
    left join
        book i1_2 
            on i1_0.item_id=i1_2.item_id 
    left join
        movie i1_3 
            on i1_0.item_id=i1_3.item_id) 
        on i1_0.item_id=oi1_0.item_id
  • ..? limit, offset은 어디있는거지? 

페이징을 추가했는데 날라가는 쿼리에는 페이징 처리를 위한 limit, offset이 없다. 굉장히 심각한거다. 그리고 로그를 보면 이러한 로그가 보인다. 컬렉션 페치조인과 같이 firstResult, maxResults가 사용됐다고 말해주고, 이 데이터를 메모리에 올려서 페이징 처리를 하겠다는 무시무시한 로그가 찍힌다.

2024-11-17T14:34:19.126+09:00  WARN 42800 --- [ShoppingMall] [nio-8080-exec-1] org.hibernate.orm.query                  : HHH90003004: firstResult/maxResults specified with collection fetch; applying in memory
  • 이 로그가 왜 무시무시하냐? 데이터가 만개면? 십만개면? 메모리에 올리는 순간 OOM이 터질 수 있다. 실제 운영중인 서비스라면..? 끔찍하다.
  • 아니 그럼 도대체 왜..? 메모리에 올려서 페이징 처리를 하지..? 왜 Hibernate는 이런 극단적인 선택을 했을까?

2-2. 일대다 페치 조인일 때 페이징 시도 시 Hibernate가 극단적 선택을 한 이유

일대다 페치 조인을 했을 때, 왜 도대체 메모리에 올려서 페이징을 할까? 

 

 

아까 일대다 페치 조인을 했을 때 날라가는 쿼리를 직접 데이터베이스에서 실행해봤을 때 이런 결과를 얻었다.

  • 실제 데이터베이스에 있는 주문 데이터는 딱 2개다. ID가 (1, 2)
  • 그렇지만, 그 주문 데이터는 주문 아이템 데이터를 두개씩 가지고 있기 때문에 위 결과처럼 데이터가 뻥튀기 된다.
  • 이 상태에서 limit, offset을 적용하면 정확한 데이터가 나올까? 아니다. 실제로는 주문은 2개뿐인데, 지금 상태에서 offset 1 limit 1000을 쿼리에 붙여 실행하면 위 결과에서 ORDER_ID 컬럼 기준으로 맨 위에 데이터를 제외하고 (1, 2, 2) 세 개의 데이터가 나올 것이다. 그 말은 잘못된 페이징 처리가 된다는 뜻이다.
  • 그런데, JPA가 어떤 도움을 주냐? 이 상태의 데이터를 메모리에 올릴때 같은 아이디는 제거해버린다. 그래서 메모리에 올라간 시점은 뻥튀기 데이터가 사라진 상태가 된다. 그렇기 때문에 메모리에 올린 상태에서 페이징 처리를 꾸역꾸역 해주는 것이다.

이러한 이유때문에 결국 일대다 페치 조인을 사용할때 페이징 처리를 하면 메모리에 올려서 페이징 처리를 할 수 밖에 없게 되는 것이다.

그리고 또 한가지 주의할 점이 있다. 일대다 페치 조인은 딱 한개만 사용해야 한다. 그러니까 위 예시에서는 Order입장에서 일대다 관계가 OrderItems였는데, 여기에 만약에 추가적으로 일대다 관계가 있는 녀석(A)이 있다고 가정하면, 페치 조인 시 OrderItems, A 이 두개를 같이 페치조인하면 안된다는 뜻이다. 이유는 위에서 이미 다 봤다. 데이터가 뻥튀기가 되는데, 이건 배로 뻥튀기가 된다. 데이터 정합성의 문제가 생길 소지가 너무 많고, 이렇게 굳이 하지 않아도 충분히 원하는 데이터를 뽑아낼 수 있는데 리스크는 크고 리턴은 적다. 

 

 

3. 일대다 페치조인 시 페이징과 한계 돌파

일대다 페치조인시 생기는 페이징 처리의 문제를 해결하는 방법을 소개한다. 결론부터 말하면 페이징이 필요한 쿼리에서 일대다 관계에 있는 녀석들은 다 지워버리면 된다. 그럼 페이징에 아무런 문제가 발생하지 않는다. 그럼 여기서 남은 문제는 페치 조인을 하지 않으면 일대다 관계에 있는 녀석들도 API 응답을 반환할때 반환 데이터로 이 컬렉션이 필요한 경우엔 프록시 초기화를 해야하니까 쿼리가 여러번 나갈텐데 이걸 어떻게 해결할까?

 

큰 그림으로 이렇게 정리할 수 있겠다. 다음 단계를 따르면 된다.

  1. ToMany 관계에 있는, 즉, 컬렉션은 모두 페치 조인에서 제거한다.
  2. ToOne 관계에 있는 엔티티들만 몇개가 됐든 상관없이 모두 페치조인한다.
  3. `default_batch_fetch_size` 옵션을 적절하게 부여해서 한번에 이 속성에 적용한 개수만큼 데이터를 가져오게 한다.

 

@GetMapping("/api/v3.1/orders")
public List<OrderDto> ordersV3_1(@RequestParam(value = "offset", defaultValue = "0") int offset,
                                 @RequestParam(value = "limit", defaultValue = "100") int limit) {
    return orderRepository.findAllWithMemberDelivery(offset, limit).stream()
            .map(OrderDto::new)
            .toList();
}
  • ToOne 관계에 있는 엔티티는 몇개가 됐든 페치 조인을 해도 상관없고 페이징도 아주 잘 작동한다. 데이터 뻥튀기란 존재할 수 없기 때문에 그렇다. 
  • 그렇기 때문에 위 코드처럼 offset, limit을 쿼리 파라미터로 받아서 페이징을 처리할수 있는 메서드를 하나 만들자.
public List<Order> findAllWithMemberDelivery(int offset, int limit) {
    return entityManager.createQuery(
                    "SELECT o " +
                            "FROM Order o " +
                            "JOIN FETCH o.member m " +
                            "JOIN FETCH o.delivery d", Order.class)
            .setFirstResult(offset)
            .setMaxResults(limit)
            .getResultList();
}

 

  • 위에서 말한대로, ToOne 관계에 있는 엔티티들(Member, Delivery)는 모두 페치 조인을 했고 컬렉션 관계에 있는 엔티티(OrderItems)는 페치 조인에서 제거했다.
  • 이 상태로 실행해보자. 결과는 다음과 같다.
[
    {
        "orderId": 2,
        "name": "userB",
        "orderDate": "2024-11-17T15:26:12.224888",
        "orderStatus": "ORDER",
        "address": {
            "city": "경기",
            "street": "2",
            "zipCode": "2222"
        },
        "orderItems": [
            {
                "itemName": "SPRING BOOK 1",
                "orderPrice": 10000,
                "count": 1
            },
            {
                "itemName": "SPRING BOOK 2",
                "orderPrice": 20000,
                "count": 2
            }
        ]
    }
]
  • 아주 깔끔하게 딱 페이징이 된 모습이다.
  • 그런데 이걸 실행했을 때 날라가는 쿼리를 보면 굉장히 많이 나갈 수 밖에 없다. 왜냐하면 OrderItems는 지연로딩이고 이 값을 초기화하기 위한 쿼리가 모두 나가야하기 때문이다.

 

그럼 여기서 일대다 관계에 있는 데이터인 OrderItems는 페치 조인으로 적용하지 않았기 때문에 반환값으로 이 데이터를 보여주려면 프록시 초기화가 진행된다. 초기화하기 위해 추가적으로 날라가는 많은 쿼리들을 어떻게 최적화하면 될까? 다음과 같이 적용하면 된다.

application.yaml

...
  jpa:
    properties:
      hibernate:
        default_batch_fetch_size: 100
...
  • jpa.properties.hibernate 하위에 다음과 같은 프로퍼티가 있다: `default_batch_fetch_size`.
  • 이 값을 적절하게 넣어주면 프록시 초기화를 할 때, 한번에 저 개수만큼 초기화하는 쿼리가 날라간다. 
  • 바로 쿼리로 확인해보자.

 

우선, 가장 먼저 OrderMember, Delivery를 조인하는 쿼리가 나간다. 

    select
        o1_0.order_id,
        d1_0.delivery_id,
        d1_0.city,
        d1_0.street,
        d1_0.zip_code,
        d1_0.status,
        m1_0.member_id,
        m1_0.city,
        m1_0.street,
        m1_0.zip_code,
        m1_0.name,
        o1_0.order_date,
        o1_0.status 
    from
        orders o1_0 
    join
        member m1_0 
            on m1_0.member_id=o1_0.member_id 
    join
        delivery d1_0 
            on d1_0.delivery_id=o1_0.delivery_id 
    offset
        ? rows 
    fetch
        first ? rows only

 

그 다음은, OrderItems의 값을 가져와야 하므로 프록시 초기화를 하고 초기화 하기 위해 쿼리를 날리는데, 이렇게 날라간다.

    select
        oi1_0.order_id,
        oi1_0.order_item_id,
        oi1_0.count,
        oi1_0.item_id,
        oi1_0.order_price 
    from
        order_item oi1_0 
    where
        oi1_0.order_id=?

ㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡ

    select
        i1_0.item_id,
        case 
            when i1_1.item_id is not null 
                then 1 
            when i1_2.item_id is not null 
                then 2 
            when i1_3.item_id is not null 
                then 3 
        end,
        i1_0.name,
        i1_0.price,
        i1_0.stock_quantity,
        i1_1.artist,
        i1_1.etc,
        i1_2.author,
        i1_2.isbn,
        i1_3.actor,
        i1_3.director 
    from
        item i1_0 
    left join
        album i1_1 
            on i1_0.item_id=i1_1.item_id 
    left join
        book i1_2 
            on i1_0.item_id=i1_2.item_id 
    left join
        movie i1_3 
            on i1_0.item_id=i1_3.item_id 
    where
        i1_0.item_id in (?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?)
  • 참고로, 나는 ItemAlbum, Book, Movie를 조인 전략을 사용해서 상속 관계 매핑을 정의했기 때문에 OrderItem을 가져오고 OrderItem에 있는 Item의 실제 데이터를 가져오기 위해 Album, Book, Movie와 조인하는 쿼리 한번이 더 나간다. 만약, ItemAlbum, Book, Movie를 싱글 테이블 전략을 사용했다면 조인하는 쿼리가 나가지 않을 것이다. 이건 테이블 매핑 전략을 어떻게 사용하느냐에 따라 달라진다.
  • 그래서, OrderItem을 가져오는 쿼리를 한번 날린다. 근데 OrderItem에는 Item이 있고 이 ItemAlbum, Book, Movie 중 하나이기 때문에 조인 쿼리를 하나 더 날리는데 그때, IN 키워드로 100개의 ID가 한번에 날라간다.
  • 이게 바로 default_batch_fetch_size가 적용된 결과다. 만약, 이 값이 적용되지 않았다면, OrderItem에 있는 Item 마다마다 그 값을 가져오기 위한 쿼리가 나갔을 것이다.

 

일대다 페치조인의 한계돌파 결론

결론적으로, 이 일대다 관계를 가지고 있는 엔티티(OrderItems)가 있는 엔티티(Order)를 페치 조인으로 페이징 할 때는 1. 일대다 관계의 엔티티를 페치 조인에서 전부다 제거하고, 2. ToOne 관계에 있는 모든 엔티티는 페치조인을 사용해서 최대한 여러번의 쿼리가 나가는 것을 방지한 다음, 페이징을 처리해서 원하는 데이터를 원하는 수만큼 가져온다. 그런데 여기서 반환해야 하는 데이터에 컬렉션 데이터가 필요한 경우 그 값들을 채우기 위해 프록시 초기화가 발생하기에 추가적으로 나가는 쿼리를 최대한 최적화하기 위해, 3. default_batch_fetch_size 옵션을 설정해서 한번에 설정한 값만큼 데이터를 가져오도록 최적화한다. 

 

그리고 이 default_batch_fetch_size 옵션은 글로벌 옵션이다. 그래서 전체에 적용이 되는데, 만약에 특정 부분만 적용하고 싶은 경우 이렇게 하면 된다.

 

Order 엔티티 일부분

package cwchoiit.shoppingmall.domain;

import jakarta.persistence.*;
import lombok.AccessLevel;
import lombok.Getter;
import lombok.NoArgsConstructor;
import org.hibernate.annotations.BatchSize;

import java.time.LocalDateTime;
import java.util.ArrayList;
import java.util.Arrays;
import java.util.List;

@Entity
@Getter
@Table(name = "orders")
@NoArgsConstructor(access = AccessLevel.PROTECTED) // 생성 메서드를 만들었으면 그 메서드로만 인스턴스를 생성할 수 있도록 막아야 함
public class Order {
    ...

    @BatchSize(size = 100)
    @OneToMany(mappedBy = "order", fetch = FetchType.LAZY, cascade = CascadeType.ALL)
    private List<OrderItem> orderItems = new ArrayList<>();
    
    ...
}
  • 이런식으로 필드에 @BatchSize 애노테이션을 붙여주면 된다. 근데 이건 컬렉션 필드에는 이렇게 적용하면 되는데 ToOne에는 이렇게 적용하면 안되고 다음과 같이 적용해야 한다.

OrderItem 일부분

package cwchoiit.shoppingmall.domain;

import com.fasterxml.jackson.annotation.JsonIgnore;
import jakarta.persistence.*;
import lombok.AccessLevel;
import lombok.Getter;
import lombok.NoArgsConstructor;
import org.hibernate.annotations.BatchSize;

@BatchSize(size = 100)
@Entity
@Getter
@NoArgsConstructor(access = AccessLevel.PROTECTED)
public class OrderItem {

    ...

    @ManyToOne(fetch = FetchType.LAZY)
    @JoinColumn(name = "order_id")
    private Order order;

    @ManyToOne(fetch = FetchType.LAZY)
    @JoinColumn(name = "item_id")
    private Item item;

    ...
}
  • 이렇게 OrderItemToOne 관계로 Order, Item이 있는데 이 녀석들에도 배치 사이즈를 부여하고 싶으면 클래스 레벨에 @BatchSize를 붙여주면 된다.

 

근데 보통은 그냥, 글로벌로 적용해두면 좋다. 그냥 기본으로 깔고 간다고 생각하면 좋다.

참고로, 이 default_batch_fetch_size값의 최대값은 1000이다.

 

 

자, 이렇게 일대다 페치 조인의 한계까지 해결해보고 지연로딩도 어떻게 해결해야 하는지 Part.1부터 걸쳐서 알아봤다. 여기까지 완벽히 이해하면 JPA로 성능 문제의 90%는 해결할 수 있다. 

 

 

번외: 컬렉션도 DTO로 바로 조회하기

이 컬렉션을 데이터베이스에서 가져와야 할 때도 SELECT절에 DTO로 직접 조회가 가능하다. 한번 이 부분도 다뤄보자. 

Part.1 에서 만들었었던 OrderQueryRepository를 기억하는가? 어떤 특정 화면에 종속적인 그러니까 순수한 Repository가 아니라 어딘가에 핏하게 종속되는데 사용되는 쿼리만 따로 모아두는 레포지토리를 만들었었다. 여기서 DTO로 직접 받아서 딱 필요한 필드들만 메모리에 올리게끔 최적화를 해본 적이 있는데 이걸 그대로 사용해보자.

 

우선, DTO부터 만들어야 한다.

package cwchoiit.shoppingmall.repository.order;

import cwchoiit.shoppingmall.domain.Address;
import cwchoiit.shoppingmall.domain.OrderStatus;
import lombok.Data;

import java.time.LocalDateTime;
import java.util.List;

@Data
public class OrderQueryDto {
    private Long orderId;
    private String name;
    private LocalDateTime orderDate;
    private OrderStatus orderStatus;
    private Address address;
    private List<OrderItemQueryDto> orderItems;

    public OrderQueryDto(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;
    }
}
package cwchoiit.shoppingmall.repository.order;

import lombok.Data;

@Data
public class OrderItemQueryDto {

    private Long orderId;
    private String itemName;
    private int orderPrice;
    private int count;

    public OrderItemQueryDto(Long orderId, String itemName, int orderPrice, int count) {
        this.orderId = orderId;
        this.itemName = itemName;
        this.orderPrice = orderPrice;
        this.count = count;
    }
}
  • DTO를 두개 만들었다. 왜냐하면 Order를 위한 DTOOrderItems를 위한 DTO.

OrderQueryRepository

package cwchoiit.shoppingmall.repository.order;

import cwchoiit.shoppingmall.dto.SimpleOrderQuery;
import jakarta.persistence.EntityManager;
import lombok.RequiredArgsConstructor;
import org.springframework.stereotype.Repository;

import java.util.List;

@Repository
@RequiredArgsConstructor
public class OrderQueryRepository {

    private final EntityManager entityManager;

    public List<SimpleOrderQuery> findOrderByDTO() {
        return entityManager.createQuery(
                        "SELECT new cwchoiit.shoppingmall.dto.SimpleOrderQuery(o.id, m.name, o.orderDate, o.status, d.address) " +
                                "FROM Order o " +
                                "JOIN o.member m " +
                                "JOIN o.delivery d", SimpleOrderQuery.class)
                .getResultList();
    }

    public List<OrderQueryDto> findOrderQueries() {
        List<OrderQueryDto> results = entityManager.createQuery(
                        "SELECT new cwchoiit.shoppingmall.repository.order.OrderQueryDto(o.id, m.name, o.orderDate, o.status, o.delivery.address) " +
                                "FROM Order o " +
                                "JOIN o.member m " +
                                "JOIN o.delivery d", OrderQueryDto.class)
                .getResultList();

        results.forEach(r -> {
            List<OrderItemQueryDto> orderItems =  findOrderItems(r.getOrderId());
            r.setOrderItems(orderItems);
        });

        return results;
    }

    private List<OrderItemQueryDto> findOrderItems(Long orderId) {
        return entityManager.createQuery(
                "SELECT new cwchoiit.shoppingmall.repository.order.OrderItemQueryDto(oi.order.id, i.name, oi.orderPrice, oi.count) " +
                        "FROM OrderItem oi " +
                        "JOIN oi.item i " +
                        "WHERE oi.order.id = :orderId", OrderItemQueryDto.class)
                .setParameter("orderId", orderId)
                .getResultList();
    }
}
  • 지금 추가한 부분은 딱 두 부분이다. 하나씩 살펴보자.
public List<OrderQueryDto> findOrderQueries() {
    List<OrderQueryDto> results = entityManager.createQuery(
                    "SELECT new cwchoiit.shoppingmall.repository.order.OrderQueryDto(o.id, m.name, o.orderDate, o.status, o.delivery.address) " +
                            "FROM Order o " +
                            "JOIN o.member m " +
                            "JOIN o.delivery d", OrderQueryDto.class)
            .getResultList();

    results.forEach(r -> {
        List<OrderItemQueryDto> orderItems =  findOrderItems(r.getOrderId());
        r.setOrderItems(orderItems);
    });

    return results;
}
  • 먼저, DTO로 직접 필요한 필드들만 받기 위해 SELECT절에 new 키워드를 사용해서 DTO로 직접 받고 있다. 그리고 이때도 마찬가지로 컬렉션 데이터는 조인해서 가져오지 않는다. 애시당초에 DTO로 조회를 할 때 컬렉션 데이터는 데이터베이스에서 바로 붙일수도 없다. 이건 위에서 말한 일대다 페치 조인을 할 때 페이징에 대한 한계를 돌파하는 방법이랑은 또 다른 얘기다. 그냥 DTO로 받아올때 필드에 컬렉션이 있으면 그 컬렉션에 데이터베이스에서 값을 한번에 넣어줄 수가 없다.
  • 그래서, 우선 컬렉션을 제외하고 DTO로 데이터를 다 받아오면 이 데이터를 가지고 루프를 돌아야 한다. 그 부분이 바로 다음 results.forEach(...) 이 부분이다.
private List<OrderItemQueryDto> findOrderItems(Long orderId) {
    return entityManager.createQuery(
            "SELECT new cwchoiit.shoppingmall.repository.order.OrderItemQueryDto(oi.order.id, i.name, oi.orderPrice, oi.count) " +
                    "FROM OrderItem oi " +
                    "JOIN oi.item i " +
                    "WHERE oi.order.id = :orderId", OrderItemQueryDto.class)
            .setParameter("orderId", orderId)
            .getResultList();
}
  • 그래서 이제 순회하면서 Order 레코드 하나하나가 이 메서드를 하나씩 실행한다. 이 메서드는 OrderItem으로부터 데이터를 받아오는데 이 역시 DTO로 직접 받아 온다.
  • 그런데, WHERE절에서 특정 OrderID 조건을 넣어서 해당하는 데이터만 가져온다.
  • 그래서 아래 코드를 보면, 순회하면서 실행한 후 이렇게 받아온 데이터를 r.setOrderItems(...)를 호출해서 넣어준다. 조금 귀찮지만 DTO로 직접 받아올때 컬렉션 데이터를 받을 수 있는 유일한 방법이다.
results.forEach(r -> {
    List<OrderItemQueryDto> orderItems =  findOrderItems(r.getOrderId());
    r.setOrderItems(orderItems);
});

 

 

그리고 컨트롤러에서 이 메서드를 이제 실행한다.

OrderController 일부분

@GetMapping("/api/v4/orders")
public List<OrderQueryDto> ordersV4() {
    return orderQueryRepository.findOrderQueries();
}

 

실행 결과는 다음과 같다. 결과는 똑같이 나오겠지만 쿼리를 보자.

    select
        o1_0.order_id,
        m1_0.name,
        o1_0.order_date,
        o1_0.status,
        d1_0.city,
        d1_0.street,
        d1_0.zip_code 
    from
        orders o1_0 
    join
        member m1_0 
            on m1_0.member_id=o1_0.member_id 
    join
        delivery d1_0 
            on d1_0.delivery_id=o1_0.delivery_id
            
ㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡ

    select
        oi1_0.order_id,
        i1_0.name,
        oi1_0.order_price,
        oi1_0.count 
    from
        order_item oi1_0 
    join
        item i1_0 
            on i1_0.item_id=oi1_0.item_id 
    where
        oi1_0.order_id=?
        
ㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡ

    select
        oi1_0.order_id,
        i1_0.name,
        oi1_0.order_price,
        oi1_0.count 
    from
        order_item oi1_0 
    join
        item i1_0 
            on i1_0.item_id=oi1_0.item_id 
    where
        oi1_0.order_id=?
  • 최초에 Order를 가져오는 쿼리는 당연히 나간다.
  • 그런데, 그 OrderItem들을 가져오는 쿼리가 개수만큼 나가고 있다. 어찌보면 당연한게 가져온 Order 데이터들로 순회하면서 OrderItemDTO로 받아오기 위해 호출하는 메서드가 있기 때문에 당연한건데 이것 역시 N + 1 문제이다.
  • 이 부분을 해결해야 한다.

 

다음 코드는 N + 1 문제를 해결하는 방법이다. 하나씩 보면서 살펴보자.

public List<OrderQueryDto> findOrderQueries2() {
    List<OrderQueryDto> results = entityManager.createQuery(
                    "SELECT new cwchoiit.shoppingmall.repository.order.OrderQueryDto(o.id, m.name, o.orderDate, o.status, o.delivery.address) " +
                            "FROM Order o " +
                            "JOIN o.member m " +
                            "JOIN o.delivery d", OrderQueryDto.class)
            .getResultList();

    List<Long> orderIds = results.stream().map(OrderQueryDto::getOrderId).toList();

    List<OrderItemQueryDto> orderItems = entityManager.createQuery(
                    "SELECT new cwchoiit.shoppingmall.repository.order.OrderItemQueryDto(oi.order.id, i.name, oi.orderPrice, oi.count) " +
                            "FROM OrderItem oi " +
                            "JOIN oi.item i " +
                            "WHERE oi.order.id IN :orderIds", OrderItemQueryDto.class)
            .setParameter("orderIds", orderIds)
            .getResultList();

    /**
     * orderItem: OrderItemQueryDto(orderId=1, itemName=JPA BOOK 1, orderPrice=10000, count=1)
     * orderItem: OrderItemQueryDto(orderId=1, itemName=JPA BOOK 2, orderPrice=20000, count=2)
     * orderItem: OrderItemQueryDto(orderId=2, itemName=SPRING BOOK 1, orderPrice=10000, count=1)
     * orderItem: OrderItemQueryDto(orderId=2, itemName=SPRING BOOK 2, orderPrice=20000, count=2)
     *
     * 이렇게 orderItems 가 있으면, 이걸 orderId 로 groupingBy를 하면
     * <1, [OrderItemQueryDto(orderId=1, itemName=JPA BOOK 1, orderPrice=10000, count=1), OrderItemQueryDto(orderId=1, itemName=JPA BOOK 2, orderPrice=20000, count=2)]>
     * <2, [OrderItemQueryDto(orderId=2, itemName=SPRING BOOK 1, orderPrice=10000, count=1), OrderItemQueryDto(orderId=2, itemName=SPRING BOOK 2, orderPrice=20000, count=2)]>
     * 이렇게 된다.
     */
    Map<Long, List<OrderItemQueryDto>> orderItemMap = orderItems.stream()
            .collect(Collectors.groupingBy(OrderItemQueryDto::getOrderId));

    results.forEach(r -> r.setOrderItems(orderItemMap.get(r.getOrderId())));

    return results;
}

 

List<OrderQueryDto> results = entityManager.createQuery(
            "SELECT new cwchoiit.shoppingmall.repository.order.OrderQueryDto(o.id, m.name, o.orderDate, o.status, o.delivery.address) " +
                    "FROM Order o " +
                    "JOIN o.member m " +
                    "JOIN o.delivery d", OrderQueryDto.class)
    .getResultList();
  • 우선, findOrderQueries()와 동일하게 처음은 Order 관련 데이터를 DTO로 바로 받아온다. 이때, Member, Delivery와 같은 ToOne 관계만 조인하는 것 역시 동일하다.
List<Long> orderIds = results.stream().map(OrderQueryDto::getOrderId).toList();

List<OrderItemQueryDto> orderItems = entityManager.createQuery(
                "SELECT new cwchoiit.shoppingmall.repository.order.OrderItemQueryDto(oi.order.id, i.name, oi.orderPrice, oi.count) " +
                        "FROM OrderItem oi " +
                        "JOIN oi.item i " +
                        "WHERE oi.order.id IN :orderIds", OrderItemQueryDto.class)
        .setParameter("orderIds", orderIds)
        .getResultList();
  • 이제 여기가 변하는 지점인데, 기존에는 가져온 Order 데이터들로 순회하면서 본인의 OrderItems를 하나씩 DTO로 받아왔다. 그러다보니 N + 1 문제가 발생한 것인데, 여기서는 그 부분을 해결하기 위해 가져온 Order 데이터들의 ID값을 모두 추출한 후 WHERE절에 IN 키워드로 한번에 모두 해당하는 데이터를 가져온다. 이렇게 N + 1 문제를 해결할 수 있다.
Map<Long, List<OrderItemQueryDto>> orderItemMap = orderItems.stream()
                .collect(Collectors.groupingBy(OrderItemQueryDto::getOrderId));

results.forEach(r -> r.setOrderItems(orderItemMap.get(r.getOrderId())));
  • 이제 OrderItems를 모두 받아왔으면, OrderQueryDtoOrderItems에 값을 넣어줘야 한다. 이때, 자기의 OrderItems을 컬렉션으로 넣어주기 위해 가져온 orderItems를 가지고 Collectors.groupingBy(OrderItemQueryDto::getOrderId)를 사용한다. 이건뭐냐면, 리스트를 맵으로 변경하는데 이때 그룹핑을 할 수가 있다. 각 리스트의 요소인 orderId로.
  • 이 부분의 자세한 동작은 주석으로 설명을 추가해놨다. 다시 한번 주석을 보여주면 이렇게 생각하면 된다.
/**
 * orderItem: OrderItemQueryDto(orderId=1, itemName=JPA BOOK 1, orderPrice=10000, count=1)
 * orderItem: OrderItemQueryDto(orderId=1, itemName=JPA BOOK 2, orderPrice=20000, count=2)
 * orderItem: OrderItemQueryDto(orderId=2, itemName=SPRING BOOK 1, orderPrice=10000, count=1)
 * orderItem: OrderItemQueryDto(orderId=2, itemName=SPRING BOOK 2, orderPrice=20000, count=2)
 *
 * 이렇게 orderItems 가 있으면, 이걸 orderId 로 groupingBy를 하면
 * <1, [OrderItemQueryDto(orderId=1, itemName=JPA BOOK 1, orderPrice=10000, count=1), OrderItemQueryDto(orderId=1, itemName=JPA BOOK 2, orderPrice=20000, count=2)]>
 * <2, [OrderItemQueryDto(orderId=2, itemName=SPRING BOOK 1, orderPrice=10000, count=1), OrderItemQueryDto(orderId=2, itemName=SPRING BOOK 2, orderPrice=20000, count=2)]>
 * 이렇게 된다.
 */

 

이러면, 이제 OrderItems가 몇개가 됐건, 딱 2번의 쿼리(Order 데이터를 가져오는 쿼리, 각 Order에 있는 OrderItems를 한번에 다 가져오는 쿼리)만 나가게 된다. 이렇게 컬렉션도 DTO로 직접 조회를 할 수 있고 N + 1 문제도 해결할 수 있게 된 것이다.

 

근데 지금 보면 SELECT절에 DTO로 직접 받아오는게 생각보다 만만치 않다. 귀찮기도 하고, 무엇보다 그냥 페치 조인을 사용해서 전체 필드에 값을 다 박을때보다 코드양이 너무 길어진다. 그래서 SELECT절에 DTO로 딱 필요한 것만 받아오면 아무래도 모든 데이터를 퍼올리는 페치 조인보다는 성능적인 부분에서 장점이 있지만, 코드의 가시성이나 더 많은 코드를 수행하는 부분에서는 성능적인 단점이 또 있다. 즉, 트레이드 오프가 있다는 말이다.

 

 

정리를 하자면

컬렉션이 있는 엔티티를 조회할 때 여러 난관이 있다. 대표적으로 페치 조인을 할 때 페이징이 불가능하다는 점이다. 그리고 이 문제를 해결하기 위해 페치 조인에서 컬렉션은 페치 조인에서 제외한 후 페이징을 하고 컬렉션 데이터를 초기화할 때 N + 1 문제를 BatchSize로 해결했다. 이게 가장 최적의 방법이고 사실 이 방법을 제외하고 방법도 없다. 

 

그리고, 마지막에는 DTO로 바로 조회하는 방법도 알아봤다. 이제 조회에 대해서는 다 배운것이다.

 

그럼 권장하는 방식을 정리해보면,

  • SELECT절에 엔티티 조회? DTO 직접 조회? → 엔티티 조회로 우선 접근
  • 컬렉션 최적화
    • 페이징 필요 → 컬렉션 데이터를 페치 조인에서 제외하고, default_batch_fetch_size를 사용해서 최적화
    • 페이징 필요 X → 페치 조인 사용
  • SELECT절에 엔티티로 조회하는 방식으로 해결이 안되면 DTO 조회 방식을 사용
  • 이도 저도 안되면 NativeSQL을 사용

 

728x90
반응형
LIST
728x90
반응형
SMALL

컨트롤러에서 엔티티를 직접 반환하지 마라! 이유는 너무 많다.

  • 엔티티를 반환하는 설계를 하면 엔티티의 변경이 생기면 API 스펙이 변경된다.
    • Member 엔티티의 name 필드를 username 필드로 변경하면, API 스펙 자체가 변경된다. 가져다가 사용하는 쪽은 매우 화가 난다.
  • 엔티티에 양방향 연관관계가 있는 경우, 무한 재호출로 인한 무응답 현상이 일어난다.
    • 이후에 코드로 직접 살펴보자. 
  • 엔티티에는 민감한 데이터가 있기도 하고, 굳이 외부로 노출시키지 않아도 되는 데이터가 있는데 그런 데이터까지 노출된다.
    • @JsonIgnore 애노테이션으로 막으면 되잖아요? → 다른 곳에서는 그 필드가 필요한 경우엔 어떡할래?
  • 지연로딩으로 설정한 연관 엔티티를 처리하기가 매우 귀찮아진다. 

 

컨트롤러에서 엔티티를 직접 반환하면 생기는 문제들

이런 여러 문제가 있고 엔티티를 직접 노출하지 않는 코드를 작성해서 더 우아하게 JPA를 사용하자. 다음 코드를 보자.

@RestController
@RequiredArgsConstructor
public class OrderSimpleApiController {

    private final OrderRepository orderRepository;

    @GetMapping("/api/v1/simple-orders")
    public List<Order> ordersV1() {
        return orderRepository.findAllByCriteria(new OrderSearch());
    }
}
  • Order 라는 엔티티를 직접 반환하고 있다. 일단 이걸 실행해보자.
  • 아래와 같은 에러가 발생하고 뭔가 제대로 동작하지 않는다.
Ignoring exception, response committed already: org.springframework.http.converter.HttpMessageNotWritableException: Could not write JSON: Document nesting depth (1001) exceeds the maximum allowed (1000, from `StreamWriteConstraints.getMaxNestingDepth()`)

 

이게 무슨 일이냐면, Order로 들어가보자.

@Entity
@Getter
@Table(name = "orders")
@NoArgsConstructor(access = AccessLevel.PROTECTED) // 생성 메서드를 만들었으면 그 메서드로만 인스턴스를 생성할 수 있도록 막아야 함
public class Order {

    @Id
    @GeneratedValue
    @Column(name = "order_id")
    private Long id;

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

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

    @OneToMany(mappedBy = "order", fetch = FetchType.LAZY, cascade = CascadeType.ALL)
    private List<OrderItem> orderItems = new ArrayList<>();

    private LocalDateTime orderDate;

    @Enumerated(EnumType.STRING)
    private OrderStatus status;

    ....
}
  • OrderMember를 가지고 있다. Member로 들어가보자.
@Entity
@Getter
@Builder
@AllArgsConstructor
@NoArgsConstructor
@Table(
        indexes = {
                @Index(name = "idx_name", columnList = "name"),
                @Index(name = "idx_name_address", columnList = "name, city")
        }
)
public class Member {

    @Id
    @GeneratedValue
    @Column(name = "member_id")
    private Long id;

    private String name;

    @Embedded
    private Address address;

    @OneToMany(mappedBy = "member", fetch = FetchType.LAZY)
    @Builder.Default
    private List<Order> orders = new ArrayList<>();


    public void change(String name) {
        this.name = name;
    }
}
  • MemberOrder를 가지고 있다. 자꾸 서로가 서로를 호출하다가 더 이상 못하겠다! 라고 말하는 중이다.
  • 이게 맨 위에서 설명한 무한 재호출이다.

 

그럼 이제, 이걸 해결하기 위해 혹시라도 @JsonIgnore 애노테이션을 사용했다고 해보자. 다음과 같이 말이다.

Order 일부분

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

...

 

이번에는 응답은 받았는데 뭔가 또 문제가 생겼다.

 

어떤 문제일까? 에러 내용은 다음과 같다.

com.fasterxml.jackson.databind.exc.InvalidDefinitionException: 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]->cwchoiit.shoppingmall.domain.Order["member"]->cwchoiit.shoppingmall.domain.Member$HibernateProxy$UdxcWMDQ["hibernateLazyInitializer"])
...
  • 결론부터 말하면 지연로딩으로 처리한 연관관계 엔티티를 반환하려 할 때 나 지연로딩이라 데이터를 돌려줄 수 없어! 라고 말하는 것이다.
  • 이렇듯, 엔티티를 직접 노출하면 지연 로딩을 원하든 원치않든 무조건 다뤄야 한다는 또 하나의 단점이 있다.

그럼 이제 이 여러 문제를 어떻게 해결하면 될까? 

 

1. 엔티티를 DTO로 변환

우선, 가장 먼저 엔티티를 전부 제거해버려라. 그리고 엔티티를 반환하지 말고 DTO로 변환해서 반환해라. 다음 코드를 보자.

@GetMapping("/api/v2/simple-orders")
public List<SimpleOrderDTO> ordersV2() {
    return orderService.findOrders(new OrderSearch()).stream()
            .map(SimpleOrderDTO::new)
            .toList();
}
  • OrderController에서 주문 데이터들을 반환하는데 반환값이 List<SimpleOrderDTO>이다. 즉, 이젠 엔티티를 반환하지 않고 DTO로 반환한다. (물론, 이 데이터를 응답 공통 객체로 감싸서 count, page, maxResults 등 추가 정보를 같이 넘기는게 일반적이다)
  • 그리고 DTO는 어떻게 생겼냐면, 별게 없다. 
@Data
static class SimpleOrderDTO {
    private Long orderId;
    private String name;
    private LocalDateTime orderDate;
    private OrderStatus orderStatus;
    private Address address;

    public SimpleOrderDTO(Order order) {
        this.orderId = order.getId();
        this.name = order.getMember().getName();
        this.orderDate = order.getOrderDate();
        this.orderStatus = order.getStatus();
        this.address = order.getMember().getAddress();
    }
}
  • 이너 클래스로 간단하게 만들어봤다. 다른 방식으로 해도 좋다. 
  • DTO는 곧 API 스펙이 되면 된다. 이제 API 스펙은 데이터를 orderId, name, orderDate, orderStatus, address 외 다른것은 넘기지 않게 서로 협의를 하면 끝이다. 이러면 Order 엔티티에 변경이 생겨도 이 API 스펙만 유지해줄 수 있다면 아무런 문제도 발생하지 않게 된다.

 

그럼 실제로 결과를 보자. 아래와 같이 데이터가 잘 나간다. 

 

 

그럼 이대로 괜찮을까? 아니다. 왜냐? 지연 로딩에 대한 문제가 여전히 남아있다. 나간 쿼리를 로그로 확인해보자.

 

  • 우선, 첫번째로 Order에 대해 조회를 하기 때문에 당연히 Order 관련 쿼리가 처음으로 나간다. 그리고 그 쿼리엔 Member와 조인하는 것도 있기 때문에 멤버를 조인한다.
  • 그런데 이게 조인을 한다고 해서 바로 지연로딩으로 설정한 연관관계들의 데이터를 다 가져오는 게 아니라, 지연로딩으로 설정한 녀석들은 프록시로 만들어 돌려준다. 이게 JPA의 규칙이다. (페치 조인과 헷갈리면 안된다. 애시당초에 데이터베이스에는 페치 조인이라는 개념 자체가 없다. 이 페치 조인은 JPA에서 사용하는 것이다)
  • 그리고 실제로 이 프록시를 초기화할때, 그러니까 위 코드에서는 엔티티를 DTO로 변환할 때 생성자에서 order.getMember().getName()과 같은 메서드를 실행하는 순간, JPA는 "어? 멤버가 필요하구나? 초기화 해야겠다!"라고 판단하고 해당 데이터를 가져오기 위해 쿼리를 날린다.
  • 그럼 결론적으로 Order에 대한 조회를 했고 데이터가 2개가 나왔다. 그 각각의 레코드에는 멤버 관련 데이터도 있어야 하지만 우선은 지연로딩이기 때문에 바로 데이터를 가져오는게 아니라 프록시로 만들어둔다. 그리고 이후에 해당 프록시를 초기화하는 순간, 그 데이터를 뽑아오기 위해 쿼리를 날리게 된다. 그 얘기는 Order가 10개고 각각의 주문이 모두 다 다른 유저라면 1 + 10개의 쿼리가 나가는 것이다. 이게 바로 N + 1 문제이고. 만약, 지연 로딩으로 설정한 연관관계가 더 많고 그 연관관계의 엔티티를 모두 프록시 초기화를 한다면 10개보다 더 나갈것이다.

 

결론은, 엔티티를 DTO로 변환하는 것으로 API 스펙이 바뀌는 문제를 해결하고 불필요한 데이터를 외부로 노출하지 않게 됐지만 여기서 끝내면 안된다는 것이다!

 

2. 페치조인을 사용해 N +1 문제 해결 

이제 정말 JPA에서 정말 중요한 페치 조인을 사용해서 딱 한번의 쿼리로 원하는 데이터를 다 가져와보자!

아래와 같이 GET 매핑을 하나 더 만들자.

@GetMapping("/api/v3/simple-orders")
public List<SimpleOrderDTO> ordersV3() {
    return orderRepository.findAllWithMemberDelivery().stream()
            .map(SimpleOrderDTO::new)
            .toList();
}

 

그리고, OrderRepository에서 다음과 같은 메서드를 하나 만든다.

public List<Order> findAllWithMemberDelivery() {
    return entityManager
            .createQuery(
                    "SELECT o " +
                            "FROM Order o " +
                            "JOIN FETCH o.member m " +
                            "JOIN FETCH o.delivery d", Order.class)
            .getResultList();
}

 

  • JPQL 부분을 보면, JOIN FETCH 라는 키워드가 있다. 그냥 JOIN이 아니다! 
  • JOIN FETCHJPA에서 제공해주는 기능인데 조인을 한 후 데이터를 모두 넣어서 한번에 돌려준다.
  • 그래서 지연로딩의 프록시 데이터도 프록시 초기화를 할 필요가 없어진다. 

 

나가는 쿼리를 한번 확인해보자! 아래와 같이 딱 한번의 쿼리로 모든 데이터를 다 받아왔고, 더 이상 쿼리가 나가지 않는다.

 

 

V2와 달랐던 점은, JOIN을 한다고 해도 그 엔티티가 지연로딩이면 바로 데이터를 넣어주는 게 아니라 프록시로 만들어서 실제로 필요한 시점에 메서드를 호출하면 그때 비로소 프록시가 초기화 되면서 그 값을 가져오기 위해 쿼리를 추가적으로 날렸는데 지금은 아예 처음부터 데이터를 다 가져와버린다. 이렇게 해서 N+1 문제를 해결할 수 있다. 

 

그런데, 한가지만 더 최적화해보자. 지금은 모든 필드가 SELECT절에 다 걸린다. 막상 필요한 데이터만 있을 수도 있는데 이건 다 걸려있기 때문에 이 부분마저 최적화해보자.

 

3. SELECT 절을 DTO로 받기

일단 위에서 사용한 페치 조인과 컨트롤러에서 엔티티를 직접 반환하는 게 아니라 DTO로 변환하여 반환하는 이 두가지 기법을 사용하면 거의 모든 대부분의 성능 문제? API 스펙 문제? 해결 된다. 근데, 위 쿼리를 보면 알겠지만 모든 필드를 다 SELECT절에서 받기 때문에 아무렴 DB에서 데이터를 메모리에 많이 퍼올리게 된다. 

 

만약, 어떤 유저가 주문한 [주문 내역]이라는 화면에 들어갔을때 보여져야 할 필드들이 주문번호, 주문자명, 배달위치, 주문일시, 주문상태 이렇게 딱 5개만 필요하다고 해보자. 그럼 저 나머지 필드들은 의미없이 메모리에 데이터를 퍼올리는 셈이 된다. 

 

그래서, 이 경우에 SELECT절 자체를 DTO로 받아볼 수 있다. 다음 코드를 보자.

 

OrderRepository 일부분

public List<SimpleOrderQuery> findOrderByDTO() {
    return entityManager.createQuery(
            "SELECT new cwchoiit.shoppingmall.dto.SimpleOrderQuery(o.id, m.name, o.orderDate, o.status, d.address) " +
                    "FROM Order o " +
                    "JOIN o.member m " +
                    "JOIN o.delivery d", SimpleOrderQuery.class)
            .getResultList();
}
  • 지금 보면, SELECT 절에 newDTO 클래스를 사용하고 있다. 그래서 딱 원하는 데이터만 넣어주고 있다. 
  • 이렇게 해서 반환 자체를 저 DTO의 리스트로 반환하면 된다.

SimpleOrderQuery

package cwchoiit.shoppingmall.dto;

import cwchoiit.shoppingmall.domain.Address;
import cwchoiit.shoppingmall.domain.OrderStatus;
import lombok.Data;

import java.time.LocalDateTime;

@Data
public class SimpleOrderQuery {

    private Long orderId;
    private String name;
    private LocalDateTime orderDate;
    private OrderStatus orderStatus;
    private Address address;

    public SimpleOrderQuery(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;
    }
}
  • 이렇게 DTO를 만들었다.

OrderController 일부분

@GetMapping("/api/v4/simple-orders")
public List<SimpleOrderQuery> ordersV4() {
    return orderRepository.findOrderByDTO();
}
  • 컨트롤러는 단지 위임만 하고 있다.

 

이렇게 하고 실행해보면, 다음과 같이 딱 우리가 필요한 필드들만 SELECT절에서 받아오고 있음을 확인할 수 있다. 그리고 더이상의 쿼리는 나가지 않는다. "어? 페치 조인이 아닌데 왜 지연로딩을 초기화하는 쿼리가 안나가요?"DTOSELECT절을 받을때, 생성자로 넘겨주는 값 자체를 넘겼으니 그때 그 값을 가져와야 하므로 이미 쿼리를 날릴때 필요한 필드들을 모두 메모리에 퍼 올리게 된다.

 

 

이러면, 정말 극한의 최적화가 완성이 되는데.. 이 방법은 트레이드 오프가 있다.

  • SELECT절이 지저분해진다. 아래와 같이 패키지 명까지 모두 작성을 해줘야하는 번거로움이 있다.

  • Repository의 순수함이 사라진다.
    • 이 말은 무슨말이냐면, Repository는 결국 엔티티에 의존해야 한다. 그 외 어떤것에도 의존하지 않는게 가장 좋은 방법이다. 그런데 지금 같은 경우, 좁게 보면 DTO(SimpleOrderQuery)에 의존하고 있으며 넓게 보면 화면 하나에 의존하고 있다.
    • 화면 하나에 의존한다는 말은 우리가 [주문 내역]이라는 화면에서 필요한 데이터만을 위해 지금 이 쿼리를 만들었단 뜻이다. 
    • 다음 전체 코드를 보자. 이 메서드가 만들어지기 전까지 이 레포지토리는 오로지 Order 라는 엔티티에만 의존하고 있었다.

OrderRepository

package cwchoiit.shoppingmall.repository;

import cwchoiit.shoppingmall.domain.Order;
import cwchoiit.shoppingmall.dto.OrderSearch;
import cwchoiit.shoppingmall.dto.SimpleOrderQuery;
import jakarta.persistence.EntityManager;
import jakarta.persistence.criteria.*;
import lombok.RequiredArgsConstructor;
import org.springframework.stereotype.Repository;
import org.springframework.util.StringUtils;

import java.util.ArrayList;
import java.util.List;

@Repository
@RequiredArgsConstructor
public class OrderRepository {

    private final EntityManager entityManager;

    public void save(Order order) {
        entityManager.persist(order);
    }

    public Order findById(Long id) {
        return entityManager.find(Order.class, id);
    }

    public List<Order> findAllByCriteria(OrderSearch orderSearch) {
        CriteriaBuilder cb = entityManager.getCriteriaBuilder();
        CriteriaQuery<Order> cq = cb.createQuery(Order.class);

        Root<Order> o = cq.from(Order.class);
        Join<Object, Object> m = o.join("member", JoinType.INNER);

        List<Predicate> predicates = new ArrayList<>();

        if (orderSearch.getOrderStatus() != null) {
            Predicate status = cb.equal(o.get("status"), orderSearch.getOrderStatus());
            predicates.add(status);
        }

        if (StringUtils.hasText(orderSearch.getMemberName())) {
            Predicate name = cb.like(m.get("name"), "%" + orderSearch.getMemberName() + "%");
            predicates.add(name);
        }

        cq.where(cb.and(predicates.toArray(new Predicate[0])));

        return entityManager
                .createQuery(cq)
                .setMaxResults(1000)
                .getResultList();
    }

    public List<Order> findAllWithMemberDelivery() {
        return entityManager.createQuery(
                        "SELECT o " +
                                "FROM Order o " +
                                "JOIN FETCH o.member m " +
                                "JOIN FETCH o.delivery d", Order.class)
                .getResultList();
    }

    public List<SimpleOrderQuery> findOrderByDTO() {
        return entityManager.createQuery(
                        "SELECT new cwchoiit.shoppingmall.dto.SimpleOrderQuery(o.id, m.name, o.orderDate, o.status, d.address) " +
                                "FROM Order o " +
                                "JOIN o.member m " +
                                "JOIN o.delivery d", SimpleOrderQuery.class)
                .getResultList();
    }
}
  • 전부 다 반환값으로 Order 엔티티를 반환하고 있고, 사실 이게 가장 모범적인 방식이다. 마지막 findOrderByDTO()는 오로지 하나의 화면을 위해서 만들어진 메서드이지 범용적으로 사용할 수 없다.
  • 그럼 방안은 없을까?

방안

그래서, 이런 경우 방안이 있는데, 이렇게 가장 기본이 되는 Repository는 순수한 Repository로 남겨두고 저런 특정 화면에 필요한 최적화된 쿼리들을 모아두는 Repository를 하나 더 만드는 것이다.

 

OrderQueryRepository

package cwchoiit.shoppingmall.repository.order;

import cwchoiit.shoppingmall.dto.SimpleOrderQuery;
import jakarta.persistence.EntityManager;
import lombok.RequiredArgsConstructor;
import org.springframework.stereotype.Repository;

import java.util.List;

@Repository
@RequiredArgsConstructor
public class OrderQueryRepository {

    private final EntityManager entityManager;

    public List<SimpleOrderQuery> findOrderByDTO() {
        return entityManager.createQuery(
                        "SELECT new cwchoiit.shoppingmall.dto.SimpleOrderQuery(o.id, m.name, o.orderDate, o.status, d.address) " +
                                "FROM Order o " +
                                "JOIN o.member m " +
                                "JOIN o.delivery d", SimpleOrderQuery.class)
                .getResultList();
    }
}
  • 이제 OrderQueryRepository를 따로 만들어서, 특정 화면이나 어떤 딱 필요한 부분에만 사용되는 쿼리들을 따로 모아두고 관리하는 것이다. 
  • 이러면 두가지 장점이 생기는데 첫번째는 유지보수성이 좋아진다. 순수한 OrderRepository는 다시 오로지 엔티티에만 의존하고 있기 때문에 결합력이 약해진다. 두번째는 분리된 Repository로 인해 개발하는 개발자도 이 쿼리는 어딘가에 특정된 쿼리구나를 인식할 수 있게 한다. 

그리고 가져다가 사용하는 쪽도, 이렇게 변경해주면 된다. 

@GetMapping("/api/v4/simple-orders")
public List<SimpleOrderQuery> ordersV4() {
    return orderQueryRepository.findOrderByDTO();
}
  • 물론 컨트롤러가 의존성이 더 추가됐지만, 컨트롤러는 얼마든지 그럴 수 있다.

 

 

결론

결론을 얘기하면 다음 순서를 따르자!

  1. 무조건 컨트롤러는 엔티티 말고 DTO를 반환한다.
  2. 필요하면 페치 조인으로 성능을 최적화한다. 대부분은 이걸로 성능 이슈가 해결된다.
  3. 그래도 더욱 더욱 최적화 하고 싶다면 SELECT절을 DTO로 받아서 정말 딱 필요한 데이터만 메모리에 퍼올리자.
  4. 아예 이것도 저것도 안되면, JPA가 제공하는 네이티브 SQL이나 스프링 JDBCTemplate을 사용해서 SQL을 직접 날린다.
728x90
반응형
LIST

+ Recent posts