개발 일기장

Reactive Programing

blue-curtain — Sat, 5 Mar 2022 17:07:31 +0900

Reactive Programming

데이터 흐름과 전달에 관한 프로그래밍 패러다임
리액티브 스트림을 사용하는 프로그래밍
- 리액티브 스트림
  - 잠재적으로 무한정 들어올 수 있는 비동기 데이터를 순서대로, 그리고 블록하지 않고 (non-blocking) 역압력(backpressure, 배압, 메세지를 받는 쪽에서 보내는 쪽으로 지속적으로 메세지를 처리할 수 있는지 알려 요청의 양을 조절하는 기술)으로 처리하는 표준 기술
- 엽압력 (배압, Backpressure)
  - 발행 - 구독 프로토콜에서 이벤트 스트림(발행쪽)의 구독자가 발행된 이벤트를 처리하는 속도보다 느린 속도로 이벤트를 소비하면서 문제가 발생하지 않도록 보장하는 장치이다.
왜 이런 패러다임이 생겼나?
- 빅데이터/모바일부터 클라우드 기반 클러스터에 이르는 다양한 환경/밀리초 단위의 응답시간을 기대하는 유저의 사용패턴 요구사항을 만족시켜주기 위해
- 기존에는 Thread Pool 을 활용해서 일처리를 진행했다. 이 때 I/O 작업이 많은 일을 하게 되는 Thread 의 경우 대부분 기다리는 상황이 벌어진다. 특히 Thread Pool 의 크기가 정해져 있다보니 성능의 한계가 찾아온다. 이를 해결하기 위해서 Thread Pool 대신 비동기 & non-blocking 모델을 사용해서 메시지 커뮤니케이션으로 전환하게 된다. 이 중에서 비동기 & non-blocking 모델에서 발생할 수 있는 문제를 backpressure 로 해결한 리액티브 스트림을 채택
Reactive 의 속성 4가지 Keyword
- 반응성 : 일정하고 예상할 수 있는 빠른 반응시간
- 회복성 : 장애가 전파되지 않고 복구된다.
- 탄력성 : 작업량의 변화와 무관하다. 병목이 발생하면 관련 컴포넌트에 할당된 자원 수를 늘리면 그만이다.
- 메시지기반 : 컴포넌트 간의 결합이 약하다. 시스템은 비동기 메세지 전달에 의존한다.
JDK 에서 리액티브 프로그래밍을 제공하는 기술
- RxJava
  - 자바로 리액티브 프로그래밍을 할 수 있는 라이브러리
    - 비동기 프로그래밍과 함수형 프로그래밍 기법을 활용한다.
  - 복잡한 비동기 프로그램을 쉽게 개발할 수 있게 해준다.
- Project Reactor
- Spring Framework 5.0

java.util.concurrent.Flow 클래스

자바 9에서 리액티브 프로그래밍을 제공하기 위해서 Flow 클래스를 추가했다.

Akka, RxJava 등의 리액티브 라이브러리는 Flow 클래스에 정의된 인터페이스 표준을 따른다. 자세한 내용은 북마크를 참고해주세요.

참고

https://modimodi.tistory.com/m/47

Reactive Stream 이란?, backPressure 이란?

blue-curtain — Sat, 5 Mar 2022 17:05:36 +0900

정의

non-blocking, backPressure 를 이용해서 비용기 서비스를 할 때 기본이 되는 스팩이다. Java RxJava, Spring5 Webflux의 Core 에 있는 ProjectReactor 프로젝트 모두 해당 스팩을 사용하고 있습니다.

따라서 비동기 프로젝트를 잘 이해하기 위해서 기본 스펙이 되는 Reactive Stream 에 대한 이해가 필요하다.

개요

non-blocking backpressure 를 이용하여 비동기 스트림 처리의 표준을 제공하는 것

목적, 설계, 범위

지속적으로 들어오는 스트림 데이터를 효율적으로 처리하기 위해서는 비동기 시스템이 효과적이다. 비동기 처리를 하면서 가장 중요한 문제는 데이터 처리가 목적지의 리소스 소비를 예측가능한 범위에서 신중하게 제어할 수 있어야 한다는 것이다. 네크워크를 통한 서버간의 협업 또는 단일 서버에서 컴퓨팅 리소스를 동시에 사용할 때 주로 씁니다.

Reactive Stream 의 주된 목적은 비동기의 경계를 명확히하여 스트림 데이터의 교환을 효과적으로 관리하는 것에 있음. 즉, 비동기로 데이터를 처리하는 시스템이 어느정도의 data 가 들어올 지 예측가능하도록 하는 것.

Reactive Stream 에서는 BackPressure가 이를 달성할 수 있게 해주는 중요한 부분이다.

Java 가 제공하는 Flow API 의 구현체인 SubmissionPublisher 라이브러리를 예시로 들자면, 비동기 요청으로 받는 쪽(subscriber)에서 요청을 보내는 쪽(publisher)에 “n개의 데이터 처리가 가능한 상태입니다" 하고 알림을 주면 publisher 가 전송할 데이터가 있을 때 subscriber 에게 데이터를 보냅니다.

Reactive Stream은 다음과 같은 스트림 지향 라이브러리에 대한 표준 및 사양입니다.

잠재적으로 무한한 숫자의 데이터 처리
순서대로 처리
컴포넌트간에 데이터를 비동기적으로 전달
backpressure 를 이용한 데이터 흐름제어

BackPressure (배압)

리액티브 선언문

한 컴포넌트가 부하를 이겨내기 힘들 때, 시스템 전체가 합리적인 방법으로 대응해야 한다.

즉, 컴포넌트가 대처할 수 없고 장애가 발생해선 안 되기 때문에 컴포넌트는 상류 컴포넌트들에 자신이 과부하 상태라는 것을 알려 부하를 줄이도록 해야 한다.

이러한 배압은 시스템이 부하로 인해 무너지지 않고 정상적으로 응답할 수 있게 하는 중요한 피드백 방법이다. 배압이 사용자에게까지 전달되어 응답성이 떨어질 수 있지만, 이 메커니즘은 부하에 대한 시스템의 복원력을 보장하고 시스템 자체가 부하를 분산할 수 있는 자원을 제공할 수 있는지 정보를 제공할 것이다.

API Components

Reactive Stream API 의 구성요소는 아래와 같다.

Publisher
Subscriber
Subscription
Processor

Publisher 는 무한한 data를 제공합니다. 제공된 data 는 Subscriber 가 구독하는 형식으로 처리됩니다. Publisher.subscribe(Subscriber) 의 형식으로 data 제공자와 구독자가 연결을 맺게 됩니다.

그리고 호출되는 순서는 아래와 같습니다.

onSubscribe
- publisher 가 생산하는 data를 Subscriber 가 받을 준비가 되어 있다는 의미이며, onNext로 데이터를 수신합니다.
onNext
- 데이터를 수신한다는 의미입니다.
onError
- 실패가 있는 경우 호출됩니다.
onComplete
- 더 이상 사용할 수 있는 신호가 없을 경우 Publisher 는 onComplete 을 호출합니다.

API Components 명세서

public interface Publisher<T> {
    public void subscribe(Subscriber<? super T> s);
}

Publisher 를 Subscriber 가 구독할 수 있도록 메서드를 제공합니다.

public interface Subscriber<T> {
    public void onSubscribe(Subscription s);
    public void onNext(T t);
    public void onError(Throwable t);
    public void onComplete();
}

Subscriber 는 Subscription 를 등록해야하고, Subscription 에서 오는 신호에 따라서 동작합니다. Subscriber 에게 오는 신호는 onNext, onError, onComplete 가 있습니다.

public interface Subscription {
    public void request(long n);
    public void cancel();
}

Subscription 은 Publisher 와 Subscriber 사이에서 중계하는 역할을 합니다.

request 메서드는 Subscriber 가 Publisher 에게 데이터를 요청하는 개수이며 (요청할 수 있다는 준비상태를 알림) cancel 은 구독을 취소하겠다는 의미입니다.

위 interface 를 토대로 아래와 같은 flow 를 만들 수 있습니다.

Reactive Stream Flow, 출처 : https://grokonez.com/java/java-9-flow-api-reactive-streams

Publisher 에 본인이 소유할 Subscription 를 구현하고 publishing 할 data 를 만듭니다.
Publisher 는 subscribe() 메서드를 통해서 Subscriber 를 등록합니다.
Subscriber 는 onSubscribe() 메서드를 통해서 Subscription 을 등록하고 Publisher 를 구독하기 시작합니다. 이는 Publisher 에 구현된 Subscription 을 통해서 이루어집니다. 이렇게 하면 Publisher 와 Subscriber는 Subscription 을 통해 연결된 상태가 됩니다. onSubscribe() 내부에서 Subscription 의 request() 를 요청하면 그 때부터 data 에 대한 구독이 시작됩니다.
Subscriber 는 Subscription 메서드의 request() 또는 cancel() 을 호출해서 data 흐름을 제어할 수 있습니다.
Subscription 의 request() 에는 조건에 따라 Subscriber 의 onNext(), onComplete() 또는 onError()를 호툴합니다. 그러면 Subscriber 의 해당 메서드 로직에 따라서 request() 또는 cancel() 로 제어하게 됩니다.

샘플 예제

public class Sample {
    public static void main(String[] args) {
				Flow.Publisher<String> publisher = new SubmissionPublisher<>();

        Flow.Subscriber<String> subscriber = new Flow.Subscriber<String>() {

            private Flow.Subscription subscription;

            @Override
            public void onSubscribe(Flow.Subscription subscription) {
                // 구독을 수행합니다.
                System.out.println("구독");
                // Subscription 를 등록합니다.
                this.subscription = subscription;
                // 1개의 데이터를 요청합니다.
                this.subscription.request(1);
            }

            @Override
            public void onNext(String item) {
                // Subscriber 가 데이터를 받으면 next 가 호출됩니다.
                System.out.println("onNext call");
                System.out.println(item);
                // 다음 메세지를 호출할 수 있는 상태인지 Subscription 을 통해서 Publisher 에게 알립니다.
                subscription.request(1);
            }

            @Override
            public void onError(Throwable throwable) {
                throwable.printStackTrace();
            }

            @Override
            public void onComplete() {
                System.out.println("completed");
            }
        };

        publisher.subscribe(subscriber);
        ((SubmissionPublisher)publisher).submit("submit1");
        ((SubmissionPublisher)publisher).submit("submit2");
        ((SubmissionPublisher)publisher).submit("submit3");
        ((SubmissionPublisher)publisher).submit("submit4");
        ((SubmissionPublisher)publisher).close();
        System.out.println("끝");

    }
}

결과

끝
구독
onNext call
submit1
onNext call
submit2
onNext call
submit3
onNext call
submit4
completed

보면 비동기로 요청이 일어나기 때문에 “끝" 이라는 메세지가 먼저 호출된 것을 알 수 있다.

구독 후에 publisher 에게 메세지를 submit 하면 Publisher는 Subscriber 에게 onNext 신호를 주고 데이터 처리를 진행합니다.

참고

https://sabarada.tistory.com/98

[Java] Reactive Stream 이란?

reactive stream이란 non-blocking(넌블럭킹) backPressure(역압)을 이용하여 비동기 서비스를 할 때 기본이 되는 스펙입니다. java의 RxJava, Spring5 Webflux의 Core에 있는 ProjectReactor 프로젝트 모두 해당..

sabarada.tistory.com

Java I/O (Input/Output)란?

blue-curtain — Sat, 5 Mar 2022 17:03:19 +0900

IO 장치들은 여러 문제가 있음.

다양한 주변 장치가 존재
- 서로 다른 포멧의 데이터를 전송
- 서로 다른 속도로 동작
CPU 와 RAM 보다 I/O 작업이 느림
입출력 모듈을 필요로 한다.

여기서 입출력 모듈이란 CPU 와 메모리의 인터페이스이고 하나 또는 그 이상의 주변 장치에 대한 인터페이스를 의미

Programmed I/O (프로그램 입출력)

입출력 모듈 중에 프로그램 입출력은 IO 로 부터 제어권을 CPU 가 가져와서 작업을 진행하는 것으로 CPU 는 입출력 모듈이 명령어의 수행을 완료할 때까지 기다립니다. 따라서 이 방식은 CPU 의 시간을 소모합니다.

Java I/O 는 이런 문제점 때문에 파일 입출력이 느리다는 인상을 많이 주었음. 이런 문제점을 Non-blocking IO(nio, New IO) API를 제공해서 극복해왔습니다.

Blocking, Non-Blocking

https://way-be-developer.tistory.com/295

Synch/Async vs blocking/non-blocking 차이

동기/비동기, blocking/non-blocking 의 차이는 동기/비동기, blocking/non-blocking 두 그룹의 차이는 관심사가 다르다. blocking/non-blocking 호출되는 함수가 바로 return 하느냐 마느냐가 관심사이다. 호출된..

way-be-developer.tistory.com

위에 북마크를 참고하면 Blocking, Non-Blocking 에 대한 개념을 잡을 수 있습니다.

NodeJS 의 장점은 이벤트 기반의 비동기 논블로킹 IO 지원으로 자원을 효율적으로 사용한다는 장점이 있다.

Blocking API

Blocking API 란 API 를 호출한 Thread 가 API 의 작업이 끝날 때까지 다른 동작을 하지 않는 API 를 블로킹이라고 한다.

Java의 기본 IO 관련 API 들이 Blocking 방식을 사용하는데 InputStream, OutputStream이 있다.

InputStream inputstream = new FileInputStream("c:\\\\data\\\\input-text.txt");

int data = inputstream.read(); // Blocking!
while(data != -1) {
  doSomethingWithData(data);
  data = inputstream.read();
}
inputstream.close();

위 코드는 Blocking API 들은 반환값을 받을 때까지 Blocking 되어서 Thread 는 idle (프로세스를 실행하고 있지 않은 상태)로 유지됩니다. 예시는 파일이지만 네트워킹 처럼 오래걸리는 작업의 경우 Blocking 으로 작업을 수행하면 bottle neck(병목) 의 원인이 되기 쉽습니다.

Non Blocking API

Non-Blocking API 는 쉽게 말해서 API 호출시 요청한 작업의 완료 여부와 상관 없이 즉각적으로 현재 상태에 대한 응답이 옵니다. 그래서 API 호출 후 Thread 제어권이 있기 때문에 다른 작업을 진행할 수 있음

Java NIO (New IO) 의 등장으로 Non Blocking방식을 구현할 수 있게 되었습니다.

하나의 Thread 가 IO작업에 의존적이지 않기 때문에 하나의 Thread 로 다수의 IO를 처리할 수도 있습니다.

NIO 와 IO 의 주요 차이점

NIO 와 IO는 개념적으로는 Blocking, Non-Blocking 의 차이가 있지만, 그 외에도 차이점이 존재합니다.

Stream Oriented vs Buffer Oriented
Blocking IO vs Non Blocking IO
Selector

Stream 기반 vs Buffer 기반

Java NIO 와 IO 사이의 큰 차이는 IO는 Stream 기반이고, NIO는 Buffer 기반이라는 점입니다.

즉, 스트림 기반의 Java IO는 스트림으로 부터 한번에 여러 바이트를 읽습니다. 읽은 바이트를 가지고 무엇을 할지는 사용하는 이에게 달려있고, 데이터는 어디에도 캐시되지 않습니다.

그리고 스트림 속 데이터에서 앞 뒤로 이동할 수도 없습니다. 만약 스트림으로 부터 읽은 데이터 내부에서 앞 뒤로 이동할 필요가 있다면 버퍼를 만들어 캐싱해야 합니다.

버퍼 기반의 Java NIO는 조금 다릅니다. 이미 처리된 buffer 로 부터 데이터를 읽어서 필요하다면 버퍼 내부에서 앞뒤로 이동할 수 있습니다. 이는 데이터를 처리하는 동안 좀 더 유연함을 제공합니다.

Blocking vs Non-Blocking IO

Java IO의 여러 스트림들은 Blocking 방식입니다. 하나의 Thread가 read() or write()를 발생 시킬 때, 해당 thread는 데이터를 읽을 때까지 혹은 데이터를 적을 때까지 blocked 상태입니다.

Java NIO의 Non-Blocking mode 는 thread 가 채널을 통해서 데이터를 읽는 것을 요청한 뒤, 이용 가능한 데이터만을 얻을 수도 있고, 만약 아무 데이터가 없다면 즉시 리턴하여 thread 가 동작할 수 있게 합니다. (스레드가 Blocking 되지않습니다.)

Non-Blocking writing 도 마찬가지로 thread 는 channel 을 통해서 어떤 데이터를 쓰도록 요청하고 데이터를 전부 다 작성할 동안 기다리지 않고 그 동안 다른 동작을 할 수 있습니다.

Non-Blocking thread이 block 되지 않는 순간엔 다른 채널에 IO를 수행할 수도 있습니다.

따라서 단 하나의 thread 가 다수의 input, output channels 를 관리 할 수도 있습니다.

Selector

Java NIO Selector는 하나의 thread 가 여러개의 input channel 들을 모니터링 할 수 있습니다.

이런 특징은 다수의 Thread 로 IO를 관리하는 방식에 비해 Thread Switching 을 줄이기 때문에 이점을 줍니다.

하나의 selector 를 사용해서 다수의 channels 를 등록할 수 있으며 하나의 스레드를 사용해서 input 을 처리할 수 있는 channel 을 선택할 수 있으며 또한 writing 을 위해 준비된 channel 을 선택할 수 있다.

이런 매커니즘은 하나의 thread 가 여러개의 channel을 관리하기 쉽게 해준다.

이제 Java I/O 패키지에 대해서 좀 더 자세하게 알아보려고 한다.

Java I/O 패키지란?

Provides for system input and output through data streams, serialization and the file system. Unless otherwise noted, passing a null argument to a constructor or method in any class or interface in this package will cause a NullPointerException to be thrown.

java.io (Java SE 13 & JDK 13 )

쉽게 말하면 데이터 스트림, 직렬화 및 파일 시스템을 통한 시스템 입력 및 출력을 제공. 즉 Java I/O 패키지 않에는 파일 파일 입출력과 관련된 클래스을 포함하고 있다는 의미이다.

바이트 단위 스트림

InputStream, OutputStream 둘다 바이트 기반 입출력. 스트림의 최상위 클래스로 추상 클래스이다.
관련된 모든 바이트 기반 입출력 스트림은 이 클래스를 상속 받아서 만들어졌다.
그림, 멀티미디어, 문자 등 모든 종류의 데이터를 주고 받을 수가 있다.
Java I/O 도식표

Java.io 패키지의 주요 클래스 설명

File	파일 시스템의 파일 정보를 얻기 위한 클래스
Console	콘솔로부터 문자를 입출력하기 위한 클래스
InputStream / OutputStream	바이트 단위 입출력을 위한 최상위 입출력 스트림 클래스
FileInputStream / FileOutputStream	바이트 단위 입출력을 위한 하위 스트림 클래스
DataInputStream / DataOutputStream	바이트 단위 입출력을 위한 하위 스트림 클래스
ObjectInputStream / ObjectOutputStream	바이트 단위 입출력을 위한 하위 스트림 클래스
PrintStream	바이트 단위 입출력을 위한 하위 스트림 클래스
BufferedInputStream / BufferedOutputStream	바이트 단위 입출력을 위한 하위 스트림 클래스
Reader / Writer	문자 단위 입출력을 위한 최상위 입출력 스트림 클래스
FileReader / FileWriter	문자 단위 입출력을 위한 하위 스트림 클래스
InputStreamReader / InputStreamWriter	문자 단위 입출력을 위한 하위 스트림 클래스
PrintWriter	문자 단위 입출력을 위한 하위 스트림 클래스
BufferedReader / BufferedWriter	문자 단위 입출력을 위한 하위 스트림 클래스

문자 단위 스트림

Reader, Writer 둘다 문자 데이터 기반 입출력의 최상위 클래스이다. 관련된 모든 텍스트 기반 입출력은 이 클래스를 상속 받아서 만들어진다.
문자데이터를 입출력할 때 사용하는 문자 기반의 스트림이다.
오로지 문자 데이터를 주고 받기 위해서 특화되어 있다.

보조 스트림

스트림의 기능을 보완하기 위해서 나온 스트림이다. (입출력 성능 속도 향상, 데이터 포멧 지원 등)
1. 실제 데이터를 주고 받지 않는다.
2. 데이터를 주고 받을 수 없기 때문에 스트림을 생성해서 등록한 뒤에 사용해야 한다.
```
DataInputStream dataInputStream = new DataInputStream(new FileInputStream("test.txt"))
```

실험

코드를 공개하고 싶긴하지만, 다른 사람이 작성한 코드이기 때문에 정확한 코드를 게시하진 않고 결과만 말씀 드리겠습니다. 코드는 아래 블로그에 들어가 직접 보시면 될 것 같습니다.

[FileReader로 47.2MB 파일을 읽을 경우] vs [BufferReader로 47.2MB 파일을 읽을 경우]

전자는 3분이 넘어도 빌드하지 못했다고 한다. 후자는 24초만에 빌드를 성공했다고 한다.

참고

https://blackinkgj.github.io/IO/

[컴퓨터 구조] Input/Output

입출력에 관해서 알아보도록 한다.

blackinkgj.github.io

https://velog.io/@jihoson94/BIO-vs-NIO

Java IO vs NIO

Basic IO와 New IO에 대해 알아보겠습니다. 차이점과 장단점을 비교하면 진행해보겠습니다.Referencehttp://tutorials.jenkov.com/java-nio/nio-vs-io.html비교할 요소는 아래 3가지입니다.Stream Orient

velog.io

https://velog.io/@ljs0429777/Java-IO

Java I/O

Input과 Output의 약자로 입출력을 의미함입출력의 간단한 예로 키보드로 텍스트를 입력하고, 모니터로 입력한 텍스트를 출력하는 것임Input -> Output (지극히 개인적인 비유법,,) 식에서 "->" 스트

velog.io

자바 가비지컬렉터. 강한참조 (String Reference), 약한참조 (Weak Reference)

blue-curtain — Thu, 3 Mar 2022 22:26:23 +0900

가비지컬렉터

Java의 가비지 컬렉터는 많은 종류가 있지만 크게 두가지 작업을 공통적으로 수행합니다.

힙 메모리 내의 객체 중 가비지를 찾아낸다.
찾아낸 가비지를 처리해서 힙 메모리를 회수한다.

최초의 Java 에서는 이들 가비지 컬렉션 작업에 사용자 코드가 관여 하지 않도록 구현되어 있었습니다. 좀 더 다양한 방법으로 객체를 처리하려는 요구가 있었고 이에 따라 JDK 1.2 부터 java.lang.ref 패키지를 추가해서 제한적이나마 사용자 코드와 GC가 상호작용 할 수 있게 했습니다.

java.lang.ref 패키지는 객체를 new로 생성했을 때 생기는 string reference 이외에도 soft, weak, phantom 3가지의 새로운 참조 방식을 각각의 Reference 클래스로 제공합니다. 이 3가지 Reference 클래스를 애플리케이션에 사용하면 앞서 설명하였듯이 GC에 일정 부분 관여할 수 있습니다.

가비지컬렉터와 Reachability

Java 가비지컬렉터는 객체가 가비지인지 판별하기 위해서 reachability 라는 개념을 사용한다. 어떤 객체에 유효한 참조가 있으면 reachable 로 간주하고 없으면 unreachable 로 간주한다.

GC는 unreachable 로 간주된 객체를 가비지로 판단하여 GC (Garbage Collection)을 수행합니다. 한 객체는 여러 다른 객체를 참조할 수 있고, 참조된 객체들도 또다른 객체를 참조할 수 있으므로 객체들의 참조는 사슬모양을 이룬다. 이런 상황에서 유효한 참조 여부를 파악하려면 항상 유효한 최초의 참조가 있어야 하는데 이를 객체 참조의 root set이라고 한다.

JVM 에서 메모리 영역인 런타임 데이터 영역 (runtime data area) 의 구조를 그림으로 그리면 다음과 같다

런타임 데이터 영역은 위와 같이 크게 세 부분으로 나뉜다.

스레드가 차지하는 영역
객체를 생성 및 보관하는 힙
클래스 정보가 차지하는 영역인 메서드 영역

(객체에 대한 참조는 화살표로 표시되어 있다.)

힙에 있는 객체들에 대한 참조는 다음 4가지 종류 중 하나이다.

힙 내의 다른 객체에 의한 참조 (1번)
Java 스택, 즉 Java 메서드 실행 시에 사용하는 지역변수와 파라미터들에 의한 참조
네이티브 스택, 즉 JNI(Java Native Interface)에 의해 생성된 객체에 대한 참조
메서드 영역의 정적 변수에 의한 참조

이 중 1번을 제외한 나머지가 root set 이고 reachability 를 판가름하는 기준이 된다.

reachability 를 더 자세히 설명하기 위해 root set과 힙 내의 객체를 중심으로 다시 그리면 다음과 같다.

위 그림에서 보듯, root set으로 부터 시작한 참조 사슬에 속한 객체들은 reachable 객체이고 이 참조사슬 밖에 있는 객체는 참조가 있다고 해도 unreachable 객체로 GC의 대상이다. 오른쪽 아래 객체처럼 reachable 객체를 참조해도 다른 reachable 객체가 이 객체를 참조하지 않는다면 이 객체는 unreachable 객체이다. 이 그림에서의 참조는 모두 java.lang.ref 패키지를 사용하지 않은 일반적인 참조이며, 이를 흔히 strong reference 라고 부른다.

Soft, Weak, Phantom Reference

java.lang.ref 는 soft reference 와 weak reference, phantom reference 를 클래스 형태로 제공한다. 예를 들어서 약한 참조를 생성하기 위해서 사용하는 클래스인 java.lang.ref.WeakReference 클래스는 참조 대상이 될 객체를 캡슐화(encapsulate)한다. Java 가비지 콜렉터는 이 객체를 일반적인 객체와 다르게 특별하게 취급한다. (자세한 설명은 뒤에서). 캡슐화된 내부 객체는 weak reference 에 의해서 참조된다.

다음은 WeakReference 클래스가 객체를 생성하는 예제이다.

WeakReference<Sample> wr = new WeakReference<Sample>( new Sample());  
Sample ex = wr.get();  
...
ex = null;

위 코드의 첫줄의 WeakReference 객체는 Sample 객체를 캡슐화한 객체이다. 이렇게 생성된 Sample 객체는 두 번째 줄에서 get() 메서드를 통해서 다른 참조에 대입된다. 이 시점에서는 WeakReference 객체 내의 참조와 ex 변수의 참조, 두 개의 참조가 처음 생성한 Sample 객체를 가리킨다.

위 코드 마지막 줄에서 ex 변수에 null 을 대입하면 처음 생성한 Sample 객체는 오직 WeakReference 내부에서만 참조된다. 이 상태를 weakly reachable 객체라고 하는데 자세한 내용은 뒤에서 다룬다.

Java 스펙에서는 SoftReference, WeakReference, PhantomReference 3가지 클래스에 의해 생성된 객체를 reference object 라고 부른다. 그리고 이들 reference object 에 의해 참조된 객체는 “referent” 라고 부른다.

위 소스 코드에서 new WeakReference() 생성자로 의해 생성된 wr 객체는 reference object 이고 new Sample() 생성자로 생성된 객체는 referent 이다.

Reference와 Reachability

앞에서 설명한 것처럼, 원래 GC 대상 여부는 reachable 인가 unreachable 인가로만 구분하였고, 이를 사용자 코드에서 관여할 수 없었다. 그러나 java.lang.ref 패키지를 이용해서 reachable 객체들을 strongly, softly, weakly, phantomly 4가지 상태로 더 자세히 구별해서 GC의 동작을 달리 지정할 수 있게 되었다. 즉, GC 대상 여부를 판별하는 부분에 사용자 코드가 개입할 수 있게 되었다.

녹색으로 표시한 중간의 두 객체는 WeakReference 로만 참조된 weakly reachable 객체이고, 파란색 객체는 strongly reachable 객체이다. GC 가 동작할 때 unreachable 객체 뿐 아니라, weakly reachable 객체도 가비지 객체로 간주되어 메모리에서 회수된다. (참조가 끊어지기 때문에) root set 으로 부터 시작된 참조 사슬에 있음에도 불구하고 GC가 동작할 때 회수 된다.

위 그림에서 WeaklyReference 객체 자체는 weakly reachable 객체가 아니라 strongly reachable 객체이다. A의 경우에는 WeakReference 에 의한 참조 이외에 Root set으로 부터 시작된 참조 사슬에 포함되어 있기 때문에 weakly reachable 객체가 아니라 strongly reachable 객체이다.

GC가 동작하여 어떤 객체를 weakly reachable 객체로 판명하면 GC가 WeakReference 객체의 weakly reachable 객체에 대한 참조를 null 로 설정한다. 그래서 weakly reachable 객체는 unreachable 객체와 마찬가지 상태가 되어 가비지로 판명이 나는 것이다.

Softly Reachable과 SoftReference

softly reachable 객체, 즉 strong reachable 이 아니고 오직 SoftReference 객체로만 참조된 객체는 힙에 남아있는 메모리의 크기와 해당 객체의 사용 빈도에 따라서 GC 여부가 결정된다.

그래서 reachable 객체는 weakly reachable 객체와 달리 GC가 동작할 때마다 회수되는 것이 아니고, 자주 사용할 수록 더 오래 살아남는다. Oracle HotSpot VM 에서는 softly reachable 객체의 GC를 조절하기 위해 다음 JVM 옵션을 제공한다.

-XX:SoftRefLRUPolicyMSPerMB=<N>

이 옵션의 기본 값을 1000이다.

softly reachable 객체의 GC 여부는 위 옵션 값으로 다음 수식을 계산한 결과에 의해 결정된다.

(마지막 strong reference 가 GC 된 때 부터 지금까지의 시간) > (옵션 설정값 N) * (힙에 남아있는 메모리 크기)

어떤 객체가 사용된다는 것은 strong reference 에 의해 참조되는 것이고 위 수식의 좌변은 해당 객체가 얼마나 자주 사용되는지를 의미한다. 만약 N 이 1000이고 남은 힙 메모리 크키가 100MB 이면 수식의 우변은 1000 * 100 = 100,000ms = 100초가 된다. 즉 reachable 객체가 100초 이상 사용되지 않으면 GC 에 의해 회수 대상이 된다. 힙에 남아있는 메모리가 작을수록 우변의 값이 작아지므로, 힙이 거의 소진되면 대부분의 softly reachable 객체는 모두 메모리에서 회수되어 OutOfMemoryError 를 막게 된다.

softly reachable 객체를 GC하기로 결정나면 WeakReference 의 경우와 마찬가지로 SoftReference 객체의 softly reachable 객체에 대한 참조를 null 로 설정한다. 이 후 softly reachable 객체는 unreachable 객체가 되어 GC에 의해 메모리에서 회수된다.

ReferenceQueue

phantomly reachable 객체의 동작과 PhantomReference를 설명하기 전에 java.lang.ref 패키지에서 제공하는 ReferenceQueue 클래스에 대해 설명할 필요가 있다.

SoftReference 객체나 WeakReference 객체가 참조하는 객체가 GC 대상이 되면 SoftReference 객체, WeakReference 객체 내의 참조는 null로 설정되고 SoftReference 객체, WeakReference 객체 자체는 ReferenceQueue에 enqueue된다.

ReferenceQueue에 enqueue하는 작업은 GC에 의해 자동으로 수행된다. ReferenceQueue의 poll() 메서드를 활용해서 reference object 를 꺼내면 softly reachable 객체나 weakly reachable 객체가 GC되었는지를 파악할 수 있고 이와 관련한 후처리 작업을 할 수 있다.

실제 Java Collections 클래스 중에서 간단한 캐시를 구현하는 용도로 자주 사용되는 WeakHashMap 클래스는 ReferenceQueue 와 WeakReference 를 사용하여 구현되어 있다.

SoftReference 와 WeakReference 는 ReferenceQueue 를 사용할 수도 있고 사용하지 않을 수도 있지만 PhantomReference 는 반드시 ReferenceQueue 를 사용해야만 한다. 그래서 딱 1개 있는 PhantomReference 클래스의 생성자는 ReferenceQueue를 인자로 받는다.

ReferenceQueue<Object> rq = new ReferenceQueue<Object>();
PhantomReference<Object> pr = new PhantomReference<Object>(referent, rq);

phantomly reachable 는 파이널 라이즈와 메모리 회수 사이에 관여한다. strongly, softly, weakly 에 해당하지 않고 PhantomReference 로만 참조되는 객체는 파이널라이즈 된 이후에 phantomly reachable 로 간주된다. GC가 객체를 처리하는 순서는 항상 다음과 같다.

soft references
weak references
파이널라이즈 (가비지 컬렉션이 회수에하기 전에 객체가 리소스를 해제하고 다른 정리 작업을 수행할 수 있게 하는 것)
phantom references
메모리 회수

즉, GC 여부를 판별할 때 어떤 객체의 reachability 를 strongly, softly, weakly 순서로 먼저 판별하고 모두 아니면 phantomly reachable 여부를 판별하기 전에 파이널라이즈 를 진행한다. 그리고 대상 객체를 참조하는 PhantomReference 가 있다면 phantomly reachable 로 간주해서 메모리 회수는 지연시키고 파이널 라이즈 이후 해야할 작업을 애플리케이션이 수행할 수 있도록 한다.

앞서 설명한 것처럼 PhatomReference는 항상 ReferenceQueue를 필요로 한다. 그리고 PhantomReference의 get() 메서드는 SoftReference, WeakReference와 달리 항상 null을 반환한다. 따라서 한 번 phantomly reachable로 판명된 객체는 더 이상 사용될 수 없게 된다. 그리고 phantomly reachable로 판명된 객체에 대한 참조를 GC가 자동으로 null로 설정하지 않으므로, 후처리 작업 후에 사용자 코드에서 명시적으로 clear() 메서드를 실행하여 null로 설정해야 메모리 회수가 진행된다.

이와 같이, PhantomReference를 사용하면 어떤 객체가 파이널라이즈된 이후에 할당된 메모리가 회수되는 시점에 사용자 코드가 관여할 수 있게 된다. 파이널라이즈 이후에 처리해야 하는 리소스 정리 등의 작업이 있다면 유용하게 사용할 수 있다. 그러나 개인적으로는 PhantomReference를 사용하는 코드를 거의 본 적이 없으며, 그 효용성에 대해서는 의문이 있다.

추가적인 설명

strongly reachable 객체는 unreachable 객체가 되면 GC에 의해서 메모리 상에서 회수된다.

발행/구독 패턴을 따르는 옵저버 디자인 패턴을 사용한 애플리케이션이나 웹소켓 연결에서 내부적으로 세션을 가지고 있는 경우, 또는 서버가 세션을 저장하는 방식의 애플리케이션의 경우 메소드 내부의 지역 변수 등등에서 해당 객체를 참조하고 있기 때문에 strongly reachable 객체이고 관련한 인스턴스가 살아있는 동안 메모리 상에서 사라지지 않는다.

그래서 Out Of Memory 가 발생할 수 있는데 이를 방지하고자 reference object 사용을 고려해볼 수 있다. 아래 테스트 코드를 보자

class BigData {
    private int[] array = new int[2500];
}

public class ReferenceTest {
    private List<WeakReference<BigData>> weakReferences = new LinkedList<>();
    private List<SoftReference<BigData>> softReferences = new LinkedList<>();
    private List<BigData> bigDatas = new LinkedList<>();

    public void weakReferenceTest() {
        try {
            while (true) {
                weakReferences.add(new WeakReference<BigData>(new BigData()));
            }
        } catch (OutOfMemoryError e) {
            System.out.println("out of memory");
        }
    }

    public void softReferenceTest() {
        try {
            while (true) {
                softReferences.add(new SoftReference<BigData>(new BigData()));
            }
        } catch (OutOfMemoryError e) {
            System.out.println("out of memory");
        }
    }

    public void strongReferenceTest() {
        try {
            while (true) {
                bigDatas.add(new BigData());
            }
        } catch (OutOfMemoryError e) {
            System.out.println("out of memory");
        }
    }

    public static void main(String[] args) {
        System.out.println("실행");

//        ReferenceQueue<Test> rq = new ReferenceQueue<Test>();
//        PhantomReference<Test> pr = new PhantomReference<Test>(new Test("test"), rq);


        ReferenceTest test = new ReferenceTest();
        test.weakReferenceTest();
//        test.softReferenceTest();
//        test.strongReferenceTest();

        System.out.println("종료");
    }
}

코드 출처 : https://ktko.tistory.com/entry/자바-강한참조Strong-Reference와-약한참조Weak-Reference

weakReferenceTest

weakReferenceTest 메소드는 동작하면 weakReferences 에 데이터를 쌓는다. 메모리 부족 타이밍에 GC 가 동작하고 WeakReference 에 의한 참조 값이 null 이 되어 unreachable 상태가 되어 메모리 상에서 회수 된다. 즉, OutOfMemoryError 가 발생하지 않는다.

softReferenceTest

softReferenceTest 메소드가 동작하면 softReferences 에 데이터를 쌓는다. 힙 메모리 영역이 점점 작아지면 위에서 언급한 공식에 의해 GC 대상이 되고 SoftReference 에 의한 참조 값이 null 이 되어 unreachable 상태가 된다. 메모리에서 회수되어 OutOfMemoryError 가 발생하지 않는다.

strongReferenceTest

strongReferenceTest 메소드가 동작하면 위와 같은 방식으로 bigDatas 에 데이터를 쌓는다. 이 ReferenceTest 의 메소드의 지역변수에서 참조하고 있기 때문에 GC 대상이 되지 않으며 결국 OutOfMemoryError 가 발생한다.

출처

https://d2.naver.com/helloworld/329631

spring framework - @Value 가 동작하지 않는다면

blue-curtain — Sun, 13 Feb 2022 23:34:55 +0900

환경 : java, springframework

코드

@Component
public class TestBean {
    @Value("${test}")
    private String test;

    private String defaultTestValue = getTest();

    public TestBean() {
        System.out.println("Constructor test = " + test);
        System.out.println("Constructor defaultTestValue = " + defaultTestValue);
    }

    @PostConstruct
    public void init() {
        System.out.println("PostConstruct test = " + test);
        System.out.println("PostConstruct defaultTestValue = " + defaultTestValue);
    }

    public String getTest() {
        return test;
    }
}

결과

Constructor test = null
Constructor defaultTestValue = null
PostConstruct test = test
PostConstruct defaultTestValue = null

원인

왜 이렇게 동작했는지 알려면 스프링 빈의 생명주기를 알아야 한다.

스프링 컨테이너 생성 -> 스프링 빈 생성 -> 의존관계 주입 -> 초기화 콜백 -> 사용 -> 소멸전 콜백 -> 스프링 종료

의존성 주입의 방법은 대표적으로 세가지가 있다.

생성자 주입
- 생성 시점에 의존성 모듈을 찾지 못하면 빈 생성을 하지 못한다.
- 스프링 빈 생성시점에 동작한다
필드 주입
- 필드에 @Autowired를 붙이면 주입
- 의존성 관계 주입 시점에 동작한다. (런타임)
Setter 주입 (메소드를 통한 주입)
- 메소드에 @Autowired를 붙이면 주입
- 의존성 관계 주입 시점에 동작한다. (런타임)
- 의존성이 순환참조 문제 날 때, 유용하게 사용할 수 있음

@Value 는 필드주입과 동일하게 의존관계 주입 시점에 동작하는데, 이는 생성자 호출 시점 이후이다.

defaultTestValue 생성 타이밍은 생성자 호출 시점에 생성 되는 것이기 때문에 @Value 어노테이션이 동작하기 전이다.

초기화 콜백인 @PostConstruct 이 동작하는 시점에는 @Value 가 동작한 이후이기 때문에 필드값이 출력이 되는 것이다.

그리고 new 로 생성할 때도 주입 받을 수 없는 값이기 때문에 주의를 해야한다.

참고

javax.annotation.PostConstruct 는 스프링 종속적인 기술이 아니라 JSR-250 라는 자바 표준이다.

초기화 콜백 : @PostConstruct
소멸전 콜백 : @PreDestroy

JPA & Mysql 환경에서 데드락 관련 이슈

blue-curtain — Sat, 5 Feb 2022 19:05:49 +0900

참고

https://techblog.woowahan.com/2664/

HikariCP Dead lock에서 벗어나기 (이론편) | 우아한형제들 기술블로그

{{item.name}} 안녕하세요! 공통시스템개발팀에서 메세지 플랫폼 개발을 하고 있는 이재훈입니다. 메세지 플랫폼 운영 장애를 바탕으로 HikariCP에서 Dead lock이 발생할 수 있는 case와 Dead lock을 회피할

techblog.woowahan.com

https://techblog.woowahan.com/2664/

HikariCP Dead lock에서 벗어나기 (이론편) | 우아한형제들 기술블로그

techblog.woowahan.com

https://techblog.woowahan.com/2664/

HikariCP Dead lock에서 벗어나기 (이론편) | 우아한형제들 기술블로그

techblog.woowahan.com

테스트 코드

https://github.com/donghyeon0725/jpaDeadLockTest

GitHub - donghyeon0725/jpaDeadLockTest

Contribute to donghyeon0725/jpaDeadLockTest development by creating an account on GitHub.

github.com

발생한 예외

Caused by: java.sql.SQLTransactionRollbackException: (conn:...) Deadlock found when trying to get lock; try restarting transaction

데드락이 걸린 상황입니다.

문제 상황

java, spring, jpa 사용 중입니다. Food 엔티티를 insert 하고 이 엔티티를 다시 조회해서 update 하는 간단한 코드였습니다.

Food 엔티티

@Getter
@Setter
@Entity
public class Food {
    @Id
    @GeneratedValue(strategy = GenerationType.SEQUENCE)
    private Long foodId;

    private String name;

    private Integer price;
}

FoodRepository.java

public interface FoodRepository extends JpaRepository<Food, Long> {
}

FoodService.java

...

@Transactional
public Long saveFood(FoodCommand foodCommand) {
    Food food = new Food();

    food.setName(foodCommand.getName());
    food.setPrice(foodCommand.getPrice());

    foodRepository.save(food);

    return food.getFoodId();
}

FoodController.java

...

@PostMapping("/v3.0/food")
public void createFoodV3(@RequestBody FoodCommand foodCommand) {
    Long foodId = foodService.saveFood(foodCommand).getFoodId();

    Food food = foodRepository.findById(foodId).orElseThrow(() -> new RuntimeException("못 찾음"));
    food.setStatus(FoodStatus.REGISTERED);
    foodRepository.save(food); // 예외 터진 부분!
}

foodRepository.save(food) 메소드에서 예외가 터졌습니다. 이때, 예외가 계속 터지지는 않았고 사용자가 몰릴 때만 예외가 터졌습니다.

처음에 생각(예상) 했던 문제 원인

서로 다른 트랜잭션을 사용하고 있었고 Open-Session-In-View 옵션이 true 이였기 때문에 DB 락의 Isolation 레벨에 의한 예외라고 생각했습니다.

즉, 아직 Write 트랜잭션이 닫히지 않아서 Lock 이 걸려있는 상황에서 다른 트랜잭션이 이 row에 대한 접근을 시도할 것이라고 예상했었고, row 가 없기 때문에 무한정 대기를 타다가 예외가 터져버릴 것으로 예상했습니다.

그런데 이 예상은 틀렸습니다. 그 이유는 트랜잭션이 열려있는 상황에도 명시적인 트랜잭션이 끝날 때는 insert 쿼리가 실제로 나가기 때문입니다. 이러면 사실상 DB 입장에서는 트랜잭션 처리가 끝난 것이라고 보는 것이 맞을 것이고 이렇게 되면 Isolation 레벨과는 상관없이 읽을 수 있을 것이기 때문입니다. 또한 제가 예상한 문제가 맞다면 사용자 수와 관계없이 늘 예외가 터져야 하는데 그렇지 않았습니다.

그리고 테스트 코드를 여럿 만들었고 예외가 나기를 기대했는데, 같은 예외를 만들 수 없었습니다

진짜 문제 원인

하나의 쓰레드가 2개의 커넥션을 요청해서 사용했기 때문에 문제가 된 상황입니다. (MYSQL DB를 사용할 때, JPA의 특정한 아이디 생성 전략을 사용하면 키 생성을 위해서 별도의 connection 이 하나 더 필요합니다.)

순간적으로 connection pool에 저장된 connection수를 넘는 연결 시도가 있었고, connection pool의 connection이 동난 상황에서 이미 connection을 얻어서 작업 중이던 쓰레드가 JPA 엔티티의 키 생성을 위해서 또 다른 connection을 요구하니까 pool 입장에선 더이상 내어줄 connection이 없었던 것입니다.

쓰레드 입장에서는 키 자원에 대한 요청을 했는데 응답이 오지않으니, “아! 키 자원이 데드락 상태이구나" 판단해버린 것입니다. 그래서, 사용자가 많아질 때에만 순간적으로 DeadLock이 걸렸던 것입니다.

문제 환경 정리

먼저 문제의 원인을 풀어 나가기 전에, 문제에 직접적으로 원인이 되었던 요소를 정리하겠습니다.

Spring JPA 사용
DB : MYSQL (테스트할 때 버전은 8.0.28)
엔티티의 키 생성 전략 : TABLE (SEQUENCE, AUTO 포함)
커넥션 수 : 커넥션 풀의 개수가 최대 생성될 수 있는 쓰레드의 수와 같거나 작을 때

기존 쓰레드 풀 동작

아래와 같은 상황을 가정

쓰레드 개수 : 4개
커넥션 수 : 3개
요청 하나를 처리하는데 필요한 커넥션 수 : 2개

정상적인 상황

요청을 받는다.
DB 커넥션 풀에서 커넥션을 요청해 받아온다.
받은 커넥션을 이용해서 DB 작업이 진행된다.
처리가 끝나면 응답을 내어준다. 그리고 커넥션은 풀에 돌려준다.

동시에 4개의 요청을 받았을 때

이 때는 작업을 위한 커넥션의 수가 모자란 상황입니다.

작업을 시작하기 위해 3개의 쓰레드에서 커넥션 풀을 요청해서 받아갔고, 3번째 쓰레드는 커넥션을 얻기 위해서 대기합니다. (또는 예외를 만납니다)

모든 쓰레드가 1개의 connection 을 이미 가지고 간 상황

다음과 같은 상황으로 가정하겠습니다.

쓰레드 수 : 2개
커넥션 수 : 2개
요청 하나를 처리하는데 필요한 커넥션 수 : 2개

두 개의 모든 쓰레드는 키 삽입을 위해서 커넥션이 하나 더 필요한데 없기 때문에 대기합니다.

기본 설정 시간인 30초가 지나면 그제야 TimeoutException 을 발생시키면서 가지고 있던 커넥션을 모두 풀에 돌려줍니다.

문제 상황을 피하려면

이미 이 이슈는 HikariCP github에서도 issue로 등록되었고, HikariCP wiki에서 Dead lock을 해결하는 방법을 제시하고 있습니다.

방법 1

pool size = Tn x (Cm - 1) + 1

Tn : 전체 Thread 개수
Cm : 하나의 Task에서 동시에 필요한 최대 Connection 수

HikariCP wiki에서는 이 공식대로 Maximum pool size를 설정하면 Dead lock을 피할 수 있다고 합니다.

예를 들어서, 아래와 같은 상황일 땐 다음과 같이 계산하면 됩니다.

전체 쓰레드 개수 : 2
하나의 쓰레드에서 동시에 필요한 최대 커넥션 수 : 2

pool size = 2 * (2 - 1) + 1 = 3

방법 2

ID 대역을 언제든지 변경할 수 있어야 하는 상황이 아닌 경우에는 시퀀스 생성 전략을 바꾸는 것이 방법이 될 수 있습니다.

사실 문제가 되는 키 전략이었던 TABLE 전략의 경우엔 성능 자체도 그렇게 좋은 편이 아닙니다.

해결방안 공식 검증 (방법 1번 검증)

2개의 Thread가 동시에 HikariCP에 Connection을 요청하고 2개의 Connection을 골고루 나눠 가졌습니다. 그럼에도 불구하고 1개의 Connection이 남아있습니다.

이 1개의 Connection이 Dead lock을 피할 수 있게 해주는 Key Connection이 됩니다. 남은 1개의 커넥션을 2개의 쓰레드가 번갈아 사용하면서 작업을 마칠 수 있게 되는 것이죠.

공식에 따라서 여분의 커넥션을 하나 늘렸고, 이제 커넥션 개수가 2개가 아니라 3개가 되었습니다.

여분의 커넥션이 색은 주황색으로 표기했습니다.

두 개의 요청이 동시에 들어와서 두 쓰레드 모두 각각 하나의 커넥션을 가져갔고, 이 상황에서 두 쓰레드에서 추가적으로 커넥션 하나를 더 얻으려는 시도가 발생합니다.

우측에 쓰레드가 먼저 커넥션을 받아가 작업을 처리합니다.
그렇게 되면 왼쪽 쓰레드는 여분의 커넥션이 생길 때까지 대기합니다.

이 때 2번째 커넥션을 먼저 받은 쓰레드가 처리하고 키 생성이 끝나면 여분의 connection 만 풀에 반납 후 나머지 작업을 진행합니다.

이후 왼쪽 쓰레드가 여분의 Connection 을 받아 요청을 처리합니다.

이렇게 하면 여분의 커넥션 덕에 DeadLock 이 걸리는 상황은 막을 수 있습니다. 물론 쓰레드 성능과 개수에 따라서 Timeout 이 날 가능성은 여전히 존재하지만요.

적절한 커넥션의 개수는?

실제로 운이 없게 모든 커넥션이 모두 찰 수 있고 1개의 여분 커넥션으로 이 상황을 돌파하려고 하면, 여분의 커넥션을 기다리면서 30초 이상의 타임아웃이 발생할 가능성 또한 있기 때문에 문제가 발생한다면 아래와 같이 DBCP (DataBase Connection Pool) 수를 설정하는 것이 어떨까 싶습니다.

pool size = 최대쓰레드수 * (최대 사용하는 커넥션 수 - 1) + 최대쓰레드수 * 0.1 + alpha

다만, 다른 관점도 있습니다.

https://www.holaxprogramming.com/2013/01/10/devops-how-to-manage-dbcp/

DB Connection Pool에 대한 이야기 · 안녕 프로그래밍

웹 애플리케이션을 운영하다 보면 에러 로그로는 식별 할 수 없는 잠재적인 이슈가 발생 할 때가 있다. 애플리케이션내의 오류가 명확히 확인이 되지 않은 상태에서 Out of memory가 발생 하거나, DB

www.holaxprogramming.com

DBPC가 WAS Thread 수를 넘어설 경우 비효율적이라는 말입니다. 따라서, 예외가 발생할 경우에만 위 설정을 따르거나,

ID 대역을 언제든지 변경할 수 있어야 하는 상황이 아닌 경우에는 시퀀스 생성 전략을 바꾸는 것이 방법이 될 수 있을 것 같습니다.

가장 좋은 것은 현재 운영되는 서비스의 동접자 수를 확인하고 상황에 맞춰서 대처하는 것일 거 같습니다.

왜 하나의 쓰레드에서 2개의 커넥션을 사용할까?

그럼, 왜 1개의 쓰레드에서 2개의 커넥션 요청이 생길 수밖에 없었는지 그 상황에 대해서 이해해보려고 합니다.

먼저, mybatis 와 jpa 를 같이 사용하고 있는 경우 서로 다른 커넥션을 사용하기 때문에, 데드락은 아니지만(예외의 모양새가 데드락인지, 아닌지 정확하게 확인 못함) 위와 같은 timeout 문제가 나타날 수 있습니다.

그리고, 두번 째는 JPA의 키 생성 전략 때문에 나타나는 문제입니다.

이이해하려면 MYSQL DB 특성과 JPA 의 키 생성 전략에 대해서 이해하고 있어야 합니다.

키 생성 방식 종류 (@GeneratedValue 어노테이션)

strategy = GenerationType.AUTO
- JPA 구현체가 자동으로 생성 전략을 결정
strategy = GenerationType.IDENTITY
- 기본키 생성을 데이터베이스에게 위임
strategy = GenerationType.SEQUENCE
- 데이터베이스의 오브젝트인 시퀀스를 사용하여 기본키를 생성
strategy = GenerationType.TABLE
- 데이터베이스에 키 생성 전용 테이블을 만들고 이를 사용하여 기본키 생성

Mysql 일 경우 SEQUENCE 전략을 사용해도 의미가 없는데 이유는, Mysql 자체가 시퀀스 객체를 지원하지 않기 때문입니다. 따라서 SEQUENCE 를 사용하면 TABLE 전략과 동일하게 동작합니다.

TABLE 전략은 테이블을 이용해서 시퀀스 객체를 흉내 내는 기법으로, 테이블에 저장된 값을 시퀀스 값으로 사용합니다. 그리고 jpa 는 hibernate_sequence 이라는 테이블을 하나 만들어서 이 값을 관리합니다.

TABLE 전략의 구현 방식은 키 생성 쿼리 로그를 보면 확인할 수 있습니다. jpa repository의 메소드인 save 가 호출되는 시점에 다음과 같은 로그를 확인할 수 있습니다.

select next_val as id_val from hibernate_sequence for update
update hibernate_sequence set next_val= ? where next_val=?

즉, 값을 조회해서 키 값으로 사용하고 이 값을 + n 해놓습니다.

여기서 for update 가 붙었는데, Mysql 에서 select 쿼리에 for update 가 붙으면 row 에 트랜잭션이 끝나기 전까지 row 에 lock 이 걸립니다.

ID 값을 담당하는 값이기에 중복이 되면 안 되고, 이 값을 select 하는 시점에, 동시성 문제가 발생하면 키 값이 중복될 수 있기 때문에 락 처리를 위해 이런 쿼리를 구성한 것 같습니다.

한편, 이런 lock 처리가 걸려 있으면 이 트랜잭션이 끝날 때까지 다른 트랜잭션에서 접근할 수 없습니다.

실제로 jpa 는 이렇게 hibernate_sequence 테이블 조회하고 업데이트하는 과정에서 별도의 sub 트랜잭션을 생성해서 실행하는데 이유는 다음과 같이 추측됩니다.

jpa는 영속성 관리를 위해서 key 값이 필요한데 이를 위해서 전략이 IDENTITY 인 경우에 persist 메소드 호출 시점에 바로 쿼리를 날려서 키를 받아옵니다. (데이터를 insert 할 때 key 값을 받는 방식 때문)

마찬가지로 비슷한 이유에서 TABLE 전략을 사용하면 persist 할 때 key 를 먼저 받아오기 위해서 위와 같은 쿼리를 날리는 것 같습니다.

그런데, lock 이 걸리는 위 쿼리 특성상 트랜잭션이 끝나기 전까지 다른 스레드에서 이 key 값을 읽을 수 없기 때문에 별도의 sub 트랜잭션을 열어서 처리하는 것으로 추측하고 있습니다. (의도는 다를 수 있음)

여기서 순간적으로 connection 을 2개 사용하게 됩니다.

테스트 코드로 증명하려던 예외

테스트 코드는 위에서 언급한 환경이 갖춰졌을 때, 쓰레드 개수가 1개라고 가정을 하고 최대 커넥션을 2개 요구하는 상황을 만들었습니다. 그리고, DB 커넥션 풀의 개수를 1로 맞춰 테스트를 진행했습니다.

순간적으로 connection 을 2개 사용하려고 시도하면 SQLTransactionRollbackException 예외가 날 것을 예상하고 테스트를 진행했습니다.

시퀀스 생성 전략이 AUTO 인데도 환경에서 예외가 난 이유는?

시퀀스 생성 전략이 AUTO 일 때 기본값으로 설정된 전략을 따라가게 되는데 다음과 같습니다.

spring boot 1.5 이상 2.0 미만 : SEQUENCE
spring boot 2.0 이상 : TABLE

이 기본 설정은 바꿀 수 있습니다.

spring.jpa.hibernate.use-new-id-generator-mappings=true

위 설정 값을 true 로 하면 TABLE 전략을 따라가고 false 하면 SEQUENCE 전략을 따라갑니다.

spring boot 1.5 이상 2.0 미만 : SEQUENCE (use-new-id-generator-mappings = false)
spring boot 2.0 이상 : TABLE(use-new-id-generator-mappings = true)

시퀀스 생성 전략이 AUTO인 경우 설정 값에 따라서 시퀀스 생성 전략이 바뀔 수 있는데 이는 코드에서 살펴볼 수 있습니다. 위에 언급한 배민 기술 블로그에서 자료를 긁어왔습니다.

Id Generator에 대해 hibernate 공식 문서에서는 아래와 같이 설명하고 있습니다.

This is the default strategy since Hibernate 5.0. For older versions, this strategy is enabled through the hibernate.id.new_generator_mappingsconfiguration property . When using this strategy, AUTO always resolvesto SequenceStyleGenerator. If the underlying database supportssequences, then a SEQUENCE generator is used. Otherwise, a TABLEgenerator is going to be used instead.

위의 내용 + 실제 코드를 기반으로 작성한 Flow chart입니다.

Flow chart

먼저 hibernate.id.new_generator_mappings=false 인 경우입니다.

DefaultIdentifierGeneratorFactory.getIdentifierGeneratorClass

strategy가 native 인 경우 사용하는 Dialect에 의해 Generator가 결정됩니다.

Dialect.getNativeIdentifierGeneratorStrategy

Dialect에서 supportsIdentityColumns()가 true 인 경우 IdentityGenerator를 사용하게 됩니다. false 인 경우 SequenceStyleGenerator를 사용하게 됩니다.

이번엔 hibernate.id.new_generator_mappings=true 인 경우입니다.

SequenceStyleGenerator.buildDatabaseStructure

Dialect에서 Sequence기능 제공 여부에 따라 내부적으로 사용하는 DatabaseStructure가 결정됩니다.

SequenceStyleGenerator.isPhysicalSequence

Sequence기능을 지원하는 경우 SequenceStructure를 사용
Sequence기능을 지원하지 않는 경우 TableStructure를 사용합니다.

위에서 결정된 DatabaseStructure는 아래 코드에서 사용됩니다.

SequenceStyleGenerator.generate

키 생성 시점에 2개의 connection 를 사용하는 게 맞는지 코드 검증

save 시점에 Key 생성과 관련한 로직이 동작할 것이기 때문에 save 메서드 코드를 열어보았습니다.

과정 확인 없이 맨 아래에 클래스 하나만 확인하셔도 충분합니다.

CrudRepository.java

@NoRepositoryBean
public interface CrudRepository<T, ID> extends Repository<T, ID> {

	/**
	 * Saves a given entity. Use the returned instance for further operations as the save operation might have changed the
	 * entity instance completely.
	 *
	 * @param entity must not be {@literal null}.
	 * @return the saved entity; will never be {@literal null}.
	 * @throws IllegalArgumentException in case the given {@literal entity} is {@literal null}.
	 */
	<S extends T> S save(S entity);

	...
}

jpa 가 제공하는 CrudRepository 인터페이스

SimpleJpaRepository.java

@Repository
@Transactional(readOnly = true)
public class SimpleJpaRepository<T, ID> implements JpaRepositoryImplementation<T, ID> {
	/*
	 * (non-Javadoc)
	 * @see org.springframework.data.repository.CrudRepository#save(java.lang.Object)
	 */
	@Transactional
	@Override
	public <S extends T> S save(S entity) {

		Assert.notNull(entity, "Entity must not be null.");

		if (entityInformation.isNew(entity)) {
			em.persist(entity);
			return entity;
		} else {
			return em.merge(entity);
		}
	}

	...
}

CrudRepository 구현체인 SimpleJpaRepository 를 보면 엔티티를 EntityManager 를 통해 persist 하는 코드를 확인할 수 있다.

EntityManager.java

public interface EntityManager {

    /**
     * Make an instance managed and persistent.
     * @param entity  entity instance
     * @throws EntityExistsException if the entity already exists.
     * (If the entity already exists, the <code>EntityExistsException</code> may 
     * be thrown when the persist operation is invoked, or the
     * <code>EntityExistsException</code> or another <code>PersistenceException</code> may be 
     * thrown at flush or commit time.) 
     * @throws IllegalArgumentException if the instance is not an
     *         entity
     * @throws TransactionRequiredException if there is no transaction when
     *         invoked on a container-managed entity manager of that is of type 
     *         <code>PersistenceContextType.TRANSACTION</code>
     */
    public void persist(Object entity);

		...
}

EntityManager 인터페이스

SessionImpl.java

AbstractSessionImpl 클래스 - SessionImplementor 인터페이스 - Session 인터페이스를 보면 EntityManager 인터페이스를 상속받는 부분이 있다.

public class SessionImpl
		extends AbstractSessionImpl
		implements EventSource, SessionImplementor, HibernateEntityManagerImplementor {

	@Override
	public void persist(Object object) throws HibernateException {
		checkOpen();
		firePersist( new PersistEvent( null, object, this ) );
	}

	private void firePersist(final PersistEvent event) {
		try {
			checkTransactionSynchStatus();
			checkNoUnresolvedActionsBeforeOperation();

			fastSessionServices.eventListenerGroup_PERSIST.fireEventOnEachListener( event, PersistEventListener::onPersist );
		}
		catch (MappingException e) {
			throw getExceptionConverter().convert( new IllegalArgumentException( e.getMessage() ) );
		}
		catch (RuntimeException e) {
			throw getExceptionConverter().convert( e );
		}
		finally {
			try {
				checkNoUnresolvedActionsAfterOperation();
			}
			catch (RuntimeException e) {
				throw getExceptionConverter().convert( e );
			}
		}
	}

	...
}

EntityManager 구현체인 SessionImpl 를 보면 persist 메소드가 있다. 코드 흐름을 따라가보면

PersistEvent 이벤트를 PersistEventListener 에 발행하고 있는 것을 알 수 있다.

PersistEventListener.java

public interface PersistEventListener extends Serializable {

    /** 
     * Handle the given create event.
     *
     * @param event The create event to be handled.
     * @throws HibernateException
     */
	public void onPersist(PersistEvent event) throws HibernateException;
	
	...
}

PersistEventListener 인터페이스를 보면 onPersist 메소드를 통해서 이벤트를 핸들링함을 알 수 있다.

DefaultPersistEventListener.java

public class DefaultPersistEventListener
		extends AbstractSaveEventListener
		implements PersistEventListener, CallbackRegistryConsumer {

	/**
	 * Handle the given create event.
	 *
	 * @param event The create event to be handled.
	 *
	 */
	public void onPersist(PersistEvent event, Map createCache) throws HibernateException {
			
		...

		final EntityEntry entityEntry = source.getPersistenceContextInternal().getEntry( entity );
		EntityState entityState = EntityState.getEntityState( entity, entityName, entityEntry, source, true );
		if ( entityState == EntityState.DETACHED ) {
			...
		}

		switch ( entityState ) {
			case DETACHED: {
				throw new PersistentObjectException(
						"detached entity passed to persist: " +
								EventUtil.getLoggableName( event.getEntityName(), entity )
				);
			}
			case PERSISTENT: {
				entityIsPersistent( event, createCache );
				break;
			}
			case TRANSIENT: {
				entityIsTransient( event, createCache );
				break;
			}
			case DELETED: {
				entityEntry.setStatus( Status.MANAGED );
				entityEntry.setDeletedState( null );
				event.getSession().getActionQueue().unScheduleDeletion( entityEntry, event.getObject() );
				entityIsDeleted( event, createCache );
				break;
			}
			default: {
				throw new ObjectDeletedException(
						"deleted entity passed to persist",
						null,
						EventUtil.getLoggableName( event.getEntityName(), entity )
				);
			}
		}

	}

	protected void entityIsTransient(PersistEvent event, Map createCache) {
		LOG.trace( "Saving transient instance" );

		final EventSource source = event.getSession();
		final Object entity = source.getPersistenceContextInternal().unproxy( event.getObject() );

		if ( createCache.put( entity, entity ) == null ) {
			saveWithGeneratedId( entity, event.getEntityName(), createCache, source, false );
		}
	}

	...
}

PersistEventListener 구현체인 onPersist 를 따라가면

엔티티 상태가 영속성 관리 전, 즉 TRANSIENT 일 때 entityIsTransient 메서드가 동작하고 있음을 알 수 있다.

saveWithGeneratedId 메서드가 동작한다.

AbstractSaveEventListener.java

public abstract class AbstractSaveEventListener
		extends AbstractReassociateEventListener
		implements CallbackRegistryConsumer {

	/**
	 * Prepares the save call using a newly generated id.
	 *
	 * @param entity The entity to be saved
	 * @param entityName The entity-name for the entity to be saved
	 * @param anything Generally cascade-specific information.
	 * @param source The session which is the source of this save event.
	 * @param requiresImmediateIdAccess does the event context require
	 * access to the identifier immediately after execution of this method (if
	 * not, post-insert style id generators may be postponed if we are outside
	 * a transaction).
	 *
	 * @return The id used to save the entity; may be null depending on the
	 *         type of id generator used and the requiresImmediateIdAccess value
	 */
	protected Serializable saveWithGeneratedId(
			Object entity,
			String entityName,
			Object anything,
			EventSource source,
			boolean requiresImmediateIdAccess) {
		callbackRegistry.preCreate( entity );

		if ( entity instanceof SelfDirtinessTracker ) {
			( (SelfDirtinessTracker) entity ).$$_hibernate_clearDirtyAttributes();
		}

		EntityPersister persister = source.getEntityPersister( entityName, entity );
		Serializable generatedId = persister.getIdentifierGenerator().generate( source, entity );
		
		...
	}

	...
}

Serializable generatedId = persister.getIdentifierGenerator().generate( source, entity ); 부분을 보면 generate 메소드가 동작한다.

IdentifierGenerator.java

public interface IdentifierGenerator extends Configurable, ExportableProducer {
	/**
	 * Generate a new identifier.
	 *
	 * @param session The session from which the request originates
	 * @param object the entity or collection (idbag) for which the id is being generated
	 *
	 * @return a new identifier
	 *
	 * @throws HibernateException Indicates trouble generating the identifier
	 */
	Serializable generate(SharedSessionContractImplementor session, Object object) throws HibernateException;

	...
}

IdentifierGenerator 인터페이스를 보면 식별자를 생성하는 메소드임을 알 수 있다.

SequenceStyleGenerator.java

public class SequenceStyleGenerator
		implements PersistentIdentifierGenerator, BulkInsertionCapableIdentifierGenerator {

	@Override
	public Serializable generate(SharedSessionContractImplementor session, Object object) throws HibernateException {
		return optimizer.generate( databaseStructure.buildCallback( session ) );
	}

	...
}

구현체인 SequenceStyleGenerator 를 보면 generate 메소드가 동작하면서 buildCallback 메소드가 동작한다.

DatabaseStructure.java

public interface DatabaseStructure extends ExportableProducer {
	
	/**
	 * A callback to be able to get the next value from the underlying
	 * structure as needed.
	 *
	 * @param session The session.
	 * @return The next value.
	 */
	AccessCallback buildCallback(SharedSessionContractImplementor session);

	...
}

buildCallback 메소드를 통해서 다음 식별자를 가져온다.

TableStructure.java

public class TableStructure implements DatabaseStructure {
	@Override
	public AccessCallback buildCallback(final SharedSessionContractImplementor session) {
		final SqlStatementLogger statementLogger = session.getFactory().getServiceRegistry()
				.getService( JdbcServices.class )
				.getSqlStatementLogger();
		if ( selectQuery == null || updateQuery == null ) {
			throw new AssertionFailure( "SequenceStyleGenerator's TableStructure was not properly initialized" );
		}

		final SessionEventListenerManager statsCollector = session.getEventListenerManager();

		return new AccessCallback() {
			@Override
			public IntegralDataTypeHolder getNextValue() {
				return session.getTransactionCoordinator().createIsolationDelegate().delegateWork(
						...
				);
			}

			...
		};
	}

	...
}

DatabaseStructure 구현체인 TableStructure 클래스의 buildCallback 메소드를 보면

session.getTransactionCoordinator().createIsolationDelegate().delegateWork() 메소드가 동작하는데 인터페이스를 열어보며

현재 트랜젝션의 고립 레벨 안으로 주어진 일을 수행한다.

IsolationDelegate.java

public interface IsolationDelegate {
	/**
	 * Perform the given work in isolation from current transaction.
	 *
	 * @param work The work to be performed.
	 * @param transacted Should the work itself be done in a (isolated) transaction?
	 *
	 * @return The work result
	 *
	 * @throws HibernateException Indicates a problem performing the work.
	 */
	public <T> T delegateWork(WorkExecutorVisitable<T> work, boolean transacted) throws HibernateException;

}

IsolationDelegate 인터페이스

JdbcIsolationDelegate.java

public class JdbcIsolationDelegate implements IsolationDelegate {

	@Override
	public <T> T delegateWork(WorkExecutorVisitable<T> work, boolean transacted) throws HibernateException {
		boolean wasAutoCommit = false;
		try {
			Connection connection = jdbcConnectionAccess().obtainConnection();
			
			...
		}
		catch (SQLException sqle) {
			throw sqlExceptionHelper().convert( sqle, "unable to obtain isolated JDBC connection" );
		}
	}

	...
}

jdbcConnectionAccess().obtainConnection(); 메소드가 동작하면서 새로운 connection 을 얻고 있다.

JdbcConnectionAccess.java

public interface JdbcConnectionAccess extends Serializable {
	/**
	 * Obtain a JDBC connection
	 *
	 * @return The obtained connection
	 *
	 * @throws SQLException Indicates a problem getting the connection
	 */
	Connection obtainConnection() throws SQLException;
	
	...
}

여기서 새로운 커넥션을 얻고 있다.

발생한 SQLTransactionRollbackException.java 를 열어보면 SQLTransientException.java 를 통해서 SQLException.java 를 상속 받고 있음을 알 수 있다.

왜 문제 원인을 예상 못 했을까?

connection 을 모두 사용했을 때 이를 초과하는 요청이 오면 해당 사용자는 두가지중 하나의 상황에 직면합니다.

연결할 수 없다는 예외를 만나기
커넥션 풀에 커넥션이 찰 때까지 기다리기
- 또는 요청 처리 자체를 제 시간 내에 시작하지 못하고, 일정 시간이 초과되어 CannotGetJdbcConnectionException 만나기

위 두 상황은 모두 데드락 상황이 아닙니다.

그리고 spring framework 내에서 1개의 Request에 1개의 Thead를 생성해서 처리하고 해당 쓰레드는 1개의 connection 을 얻어서 처리하는 것을 당연하게 생각하고 있었습니다.

따라서 위 생각(가정)이 맞다면 데드락이 아니라, 다른 예외가 나야 할 것이라고 생각했습니다.

그래서 전혀 connection pool 이 문제일 것이라고 예상하지 못했습니다.

github 중간점검

blue-curtain — Sat, 5 Feb 2022 17:37:10 +0900

처음 시작할 때가 엊그제 같았는데 이제 65일 남았다.

조금만 더..

메세지 브로커 push vs pull 방식 (RebbitMQ vs Kafka)

blue-curtain — Thu, 3 Feb 2022 18:24:40 +0900

참고

https://www.ibm.com/kr-ko/cloud/learn/message-brokers

Message Broker(메시지 브로커)는 Publisher(송신자)로부터 전달받은 메시지를 Subscriber(수신자)로 전달해주는 중간 역할이며 응용 소프트웨어 간에 메시지를 교환할 수 있게 한다.

애플리케이션 To 애플리케이션으로 직접 메세지를 송수신 하는 방식과 비교해, 애플리케이션 간의 결합을 낮추고 확장에 보다 더 유연하게 대처할 수 있다는 장점이 있다.

메세지 브로커는 메세지를 전달하는 방식에 따라서 크게 2가지 종류가 있다.

포인트-투-포인트 메시징

메시지의 송신자와 수신자 간에 일대일 관계를 지닌 메시지 대기열에서 사용되는 분배 패턴입니다. 큐의 각 메시지는 하나의 수신자에게만 전송되며, 오직 한 번만 이용됩니다. 포인트-투-포인트 메시징은 메시지가 한 번만 실행되어야 하는 경우에 호출됩니다.

쉽게 말해서, 브로커가 직접 클라이언트로 메세지를 보내주는 방식으로 push 방식에 해당한다. 대표적으로 RabbitMQ(pull 방식을 지원하는 API 가 있지만 성능이 좋지 않다.) 가 있다.

발행/구독 메시징

이 메시지 분배 패턴(종종 "발행/구독"이라고 함)에서 각 메시지의 생성자는 이를 토픽에 발행하고, 다수의 메시지 이용자는 해당 메시지를 수신하고자 하는 토픽을 구독합니다. 토픽에 대해 발행된 모든 메시지는 이를 구독한 모든 애플리케이션에 분배됩니다. 이는 메시지의 발행자와 이용자 사이에 일대다 관계가 있는 브로드캐스트 스타일의 분배 방법입니다.

쉽게 말해서, 브로커에 데이터가 있고 이를 클라이언트가 요청해서 받아가는 방식으로 pull 방식에 해당한다. 대표적으로 Kafka 가 이에 해당한다.

지속적인 요청을 보내서 결과를 기다리는 방법을 polling 이라고 하는데, 발행/구독 메시징 브로커의 경우 일부 polling 방식을 기반으로 메세지를 받아와 처리한다.

polling 방식의 경우 서버에 주는 부담이 크다. 그래서 대안으로 long polling 방식을 많이 사용한다. Redis 를 예시로 long polling 을 설명해본다. long polling 방식은 서버측이 클라이언트의 연결을 물고 있다가, 서버 측에 락 획득 가능 이벤트가 일어나면 클라이언트 측에 알림을 보내고 이후 클라이언트가 락 획득을 시도한다.

즉, 바로 응답을 하는 것이 아니라 연결만 물고 있다가 응답 가능 상태가 되면 클라이언트에 알림 응답을 보내주고 이때 클라이언트가 재 요청을 하는 것이다.

kafka 가 공식적으로 내놓은 Java 클라이언트 라이브러리인 apache kafka-clients 의 경우 long polling 방식을 사용하고 있다. 여기서 KafkaConsumer.poll(long) 메소드를 사용한다.

그런데 이는, 서버 측에서 이벤트가 일어나지 않을 경우 연결을 계속 물고 있기 때문에 poll 메소드가 무한정 대기하는 상태가 발생할 수 있다. 따라서 kafka 2 점대 버전 부터는 응답이 없어 timeout 이 날 경우, 빈 collection 을 반환하는 KafkaConsumer.poll(Duration) 메소드 사용을 권장하고 있다.

각각 방식에 따라서 특징이 있는데 다음과 같습니다.

push 방식

이 접근 방식은 브로커가 클라이언트에게 메세지를 보내줍니다. 따라서 데이터가 클라이언트에 의해 처리되는지 확인하는 의무는 클라이언트가 아닌 브로커에 있습니다. 또한 클라이언트는 브로커만 제어하고 모니터링하기 때문에 브로커로부터 이벤트 수신 지연이나 지연에 대해 걱정할 필요가 없습니다.

따라서 클라이언트 앱이 다운되면 브로커가 지속적으로 데이터 푸시를 시도 해야하는 상황이 됩니다.

이런 상황 속에서 여러 클라이언트가 메세지를 요청한다고 가정하면, 브로커는 각 클라이언트에게 데이터를 푸시하는 것이 큰 부담이 됩니다.

pull 방식

클라이언트는 브로커에게 요청했던 마지막 메세지에 대한 내용을 브로커의 로그에 기록합니다. 그래서, 다음에 메세지를 요청 할 때는 해당 기록을 보고 이미 받은 메세지 이후의 것만 브로커에 요청할 것입니다.

이런 방식 때문에 브로커에겐 정보가 잘 처리 되었는지 확인할 의무가 없습니다. 클라이언트 앱이 다운되어 메세지 처리가 뒤쳐질 수 있는데, 이런 경우 브로커는 클라이언트 이러한 문제에 대해 걱정할 필요가 없습니다.

풀 기반의 유일한 문제는 브로커에 더 이상 데이터가 없고 클라이언트가 새 이벤트를 기다리거나 요청하려고 할 때 지속적인 polling 요청이 브로커에 들어오면서 불필요한 트래픽을 유발한다는 점입니다.

이 문제를 극복하기 위해 브로커에 이벤트가 생길 때까지 (보내줄 메세지가 생길 때까지) 대기 하는 long polling 방식을 이용하기도 합니다.

담당 사수분께 배웠던 것들

blue-curtain — Thu, 13 Jan 2022 18:52:22 +0900

동시성을 고려한 프로그래밍

코드를 짜면 동시성에 대해서 늘 고민하게 된다. 여러 WAS 가 동시에 이 코드를 실행 했을 때 이 후 API 나 배치 등등의 작업이 어떻게 될 것인가? 동시에 같은 row 를 select 한 후 상태를 검사하고 다음 코드를 실행하면 어떤 상황이 되는지 고민을 많이 하게 된다.

예를 들어서 인증을 위한 램덤 코드를 생성한다고 가정하자. code 값이 DB에서 unique 제약 조건이 걸려있고 이 때문에 값을 insert 할 때 만든 랜덤의 코드값으로 DB 를 조회하고 이 값이 없으면 insert 를 해서 코드를 생성하는 코드를 짰다.

이 코드에 동시성 처리를 해주지 않으면 어떻게 될까? 고민을 했다. 만약 랜덤의 코드 값을 생성했는데 이 코드가 중복된 코드는 아니고, 서로 다른 WAS 의 두 스레드에서 동시에 같은 코드를 생성했다고 가정하자. 이를 통해 DB를 조회하는 코드에 다달았을 때 기존에 DB에서 가지고 있던 코드가 아니기 때문에 if 문 내부로 들어갈 것이고 DB에 insert 를 시도 할 것이다.

DB 입장에서 생각하면, unique 제약조건이 걸려있고 RDBS 특성상 일관성(Consistency)을 보장하기 때문에 데이터가 중복되는 일은 없을 것이다. 즉, 하나의 스레드에서는 insert 하는 시점에 예외를 만날 것이다.

이렇게 되면 한명의 사용자는 정상적으로 서비스 이용을 시도했는데 예외 상황을 만나게 되는 것이다. 이는 좋지 않은 사용자 경험을 유발할 수 있다. 이 때문에 캐시 서버인 Redis 서버를 lock 용도로 해당 데이터에 대한 lock 을 획득 했을 때 데이터 insert 를 할 수 있도록 처리했고, 속도는 조금 느려질 수 있지만 이렇게 처하는 것이 낫겠다 라고

테스트 코드와 설계 문서를 작성하면서

나를 담당해주시는 시니어 개발자 분께서는 항상 작업에 들어가기 전에 설계에 공을 들인다. 그런데, 설계라는게 롤에서 티모 버섯을 설계하는 그런 느낌이 아니다. 설치할 수 있는 버섯의 종류가 다 다르고, 이에 따른 특성이 모두 나뉜다. 지형 마다 버섯의 폭발 시간이 지연 될 수도 있고 어떤 데에서는 버섯이 아니라 포션이 되는 느낌이다.

롤에서 티모 버섯 설치는 직관에 의존하지만, 코드 설계는 모두 머리에서 일어나는 계산에 의존해야 한다.

모르는 것이 하나라도 있으면 전혀 다른 동작을 할 수 있기 때문에 작업을 하기 전에 관련한 코드가 있으면 모두 뒤져봐야 한다. 현재 상황은 어떠한가? 어떤 기술이 사용되었고 발생할 수 있는 사이드이펙트는 어떻게 되나? 동시성 이슈는 해결했는가? 이 값이 굳이 DB 필드에 저장되어야 하는가? 캐시서버를 이용하면 안되나? 수정으로 작업을 해야하는가? 아니면 새로운 api 를 만들어야 하는가? 서버에 최대 어느정도까지 부담이 될 수 있는가? 발생할 수 있는 모든 예외 상황은? 그 때 응답할 코드는? 응답 메세지는? 응답 메세지는 클라이언트에서 바로 사용할 것인가? 아니면 코드로 정제해서 보여줄 것인가? 비동기 MQ 의 pub/sub 서버나 batch 서버를 이용해서 해결해야할 문제일까? 레거시와 호환이 될 것인가? null 예외가 발생할 수 있는 경우의 수는? DB에 얼마나 많은 row 가 쌓일 수 있는지? 인덱싱을 어떤 필드로 잡아야 할지? 롱폴링으로 해결할까? 콜백으로 해결할까?

솔직히 설계할 때가 제일 지루한 작업인 것 같다. 모든 경우의 수를 머리속에 그리고, 모든 코드를 찾아보고 이게 말로 작성하니 아무렇지 않아보이는데 많이 힘들고 어려운 작업인 것 같다. 그런데 선배 개발자 분께서는 내게 항상 말씀해주신다.

코드 작업은 그냥 설계한 대로 타이핑 하는 작업에 불과하다.

맞는 말이다. 그리고 이것이 설계를 미리 해 놓았을 때의 장점인 것 같다. 설계를 미리 해 놓으면 코드를 짤 때 고민하는 것은 아래 몇가지 정도로 단축 된다.

단어를 뭐를 쓸까?
가독성을 덜 헤치고 성능이 더 잘 나 올만한 코드가 없을까?
설계한 대로 작성했나?

또한 설계를 하며 모든 코드를 다시 보고 머리속에서 경우의 수를 생각하기 때문에 어디에 어떤 사소한 코드가 있는지까지 모두 알게된다는 점이다. 내가 그렇다는 것은 아니고.. 선배님의 경우에 어떤 컨트롤러의 어떤 메소드에서 데이터가 어떻게 분기되고 이 데이터의 상태가 변했을 때 어떤 api 가 영향을 받는지까지.. 정말 사소한 것 하나하나까지 모두 기억하고 계신다.

기존의 레거시를 돌보면서

코드를 개선하다 보면 많은 점을 느낀다. 레거시에 대한 것을 어떻게 돌볼 것인가 고민을 하게 된다. 특히 version 2 api 출시가 아니라, 기존의 api 를 수정하는 작업을 하게 되면 이 코드가 기존의 레거시 코드에 어떤 문제를 줄 것 인가에 대해 고민을 많이 하게 된다.

이 코드가 들어갔을 때 클라이언트의 동작이 달라질 것인가?
- 달라진다면 프론트엔드에서 별도의 작업을 해주어야 하는 규모의 수정인가?
이 코드를 동작시켰을 때 기존과는 다른 방식으로 데이터를 삽입한다면 다른 api 에서 이 데이터를 사용하는데 문제가 되지는 않을 것인가?

이 외에 근본적인 문제에 대해서 고민하기도 한다.

굳이 수정으로 작업을 해야하나? version 2 를 출시하면 안되는 문제인가?
어떻게 하면 서버 자원은 덜 먹으면서, 가독성이 좋은 코드를 짤 수 있는지?
- 만약 이 클래스를 만들어 놓으면 다른 개발자가 사용할 때 문제가 생기지는 않을까?
  - 예를 들어서 가변인자를 통해서 받은 파라미터를 String 에 parsing 해주는 클래스를 만들었다고 하자. 그러면 실수로 인자 1개를 덜 넣어줘서 문제가 생길 수도 있다. 이 때 언제 문제가 발생하는가? 런타임인가? 애플리케이션 로드 시점인가? 발생했을 때 얼마나 크리티컬한 이슈가 되는가? 이렇게 쌓인 데이터는 마이그레이션(최악인 경우)을 하던 뭘하던 여튼 해결할 수 있는 수준인가?
작성한 코드 때문에 트랜젝션을 스레드가 물고 있는다면 그 시간은 얼마나 더 길어지지?

많은 케이스에 대해서 고민을 할 수 있게 되는 것이 너무 즐겁다. 물론 선배 개발자에게 배워가면서 작업을 하고, 그 과정을 통해서 배운 것들이지만 그래도 이런 지식들이 점점 나의 것이 되어가는 자체만으로 행복하다.

사랑합니데이 선배님

JPA - 예상치 못한 변경 감지가 동작하는 경우

blue-curtain — Wed, 29 Dec 2021 21:29:21 +0900

참고

https://github.com/donghyeon0725/jpaTest

GitHub - donghyeon0725/jpaTest

Contribute to donghyeon0725/jpaTest development by creating an account on GitHub.

github.com

JPA 에서 변경 감지가 동작하려면 다음과 같은 조건이 필요합니다.

명시적인(선언적인) 트랜잭션을 열어야 한다. (이 때 선언적인 @Transactional 이 존재해야하고, 이 트랜젝션이 commit 되는 시점에 변경 감지가 일어난다.)
영속성 관리중인 객체에 데이터 변경이 일어나야 한다.

일반적으로 Service 에서 트랜잭션(@Transactional)을 열고 Service 에서 변경감지로 JPA Entity 를 수정 한 뒤, Service 를 빠져 나왔을 때, 더 이상의 어떤 변경 감지도 동작하지 않을 것을 기대합니다.

다음은 샘플 소스 입니다.

User Entity

@Getter
@Setter
@Entity
public class User {

    @Id
    @GeneratedValue
    private Long userId;

    private String name;

    private String profileUrl;

    private Integer age = 0;
}

단순한 유저 엔티티

UserController

...
public class UserController {
		// 유저 정보 조회 api
    @GetMapping("/my/{userId}")
    public Map getMyInfo1(@PathVariable Long userId) {
        Map<String, Object> info = new HashMap<>();

        User user = userRepository.findById(userId).orElseThrow(() -> new RuntimeException("유저가 없습니다."));
        user.setProfileUrl("https://test.com/" + user.getProfileUrl());

        info.put("user", user);

        return info;
    }
}

이 코드의 의도는 user 의 정보를 보여주는 것입니다. 이 때, 프로필 url 앞에 도메인 주소에 해당 하는 값을 붙여서 보여줍니다.

여기서 질문.

JPA 의 변경 감지가 동작해서 유저의 프로필이 "https://test.com/" + user.getProfileUrl() 로 변경된 값이 반영 될까?

정답은 No. 왜냐하면, 명시적으로 트랜잭션을 열지 않았기 때문입니다. 명시적으로 연 트랜잭션이 커밋되는 시점에 변경감지가 일어나기 때문에 위 코드에서는 변경감지는 일어나지 않습니다.

에초에 조회용도로 method가 GET 인 API 에서 유저의 profile_url 필드 값을 변경하고 싶진 않았을 것입니다.

여기서, 추가 사항이 생겼다고 가정합니다. 이 사용자가 주문을 한 내역을 확인하고 싶다고 합니다. 요구 사항에 따라서 다음과 같은 Service 로직이 나왔습니다.

@Service
@RequiredArgsConstructor
public class OrdersService {
    private final OrdersRepository ordersRepository;
		// 주문 내역이 있는지 확인
    @Transactional
    public boolean hasOrderThatDoesNotStart(User user) {

        return ordersRepository.countByUserAndDeliveryStatus(user, DeliveryStatus.WAIT) > 0;
    }
}

유저가 주문한 내역이 있는지 확인하는 간단한 로직입니다. (정확하게는 주문한 것중 아직 배송 전인)

주문을 했으면 true, 안했으면 false 로 결과를 리턴 합니다.

사용자는 유저 정보를 조회하는 api 에 다음과 같이 hasOrderThatDoesNotStart 라는 필드로, 주문 여부를 확인할 수 있도록 API 에 다음과 같은 소스를 추가했습니다.

...
public class UserController {
		
    @GetMapping("/my/{userId}")
    public Map getMyInfo1(@PathVariable Long userId) {
        Map<String, Object> info = new HashMap<>();

        User user = userRepository.findById(userId).orElseThrow(() -> new RuntimeException("유저가 없습니다."));
        user.setProfileUrl("https://test.com/" + user.getProfileUrl());

        info.put("user", user);
				// 추가
				info.put("hasOrderThatDoesNotStart", ordersService.hasOrderThatDoesNotStart(user));
        
				return info;
    }
}

이 API를 호출하면 어떻게 될까?

1번 호출할 때 마다, profileUrl 의 값은 "https://test.com/" 가 붙어 계속 길이가 늘어난 값이 DB 에 저장됩니다.

왜 변경 감지가 일어났을까? 다음과 같은 조건이 마련되었기 때문 입니다.

user 를 영속성 컨텍스트에서 관리 중이다.
user 의 값이 변경 되었다.
ordersService.hasOrderThatDoesNotStart(user) 를 호출하면서 명시적 트랜젝션이 열렸고 커밋 되는 시점에 user 가 영속성 컨텍스트에 있었다.

그런데, 이상하다.

트랜잭션이 열리는 시점은 ordersService.hasOrderThatDoesNotStart(user) 가 호출되는 시점이고 이 전에 이미 트랜잭션(묵시적)이 끝난 user 를 왜 영속성 컨텍스트에서 관리중인 것일까?

이유는 Open-Session-In-View (OSIV) 옵션이 켜져 있기 때문입니다. JPA 에서는 default 설정이 OSIV true입니다.

OSIV 는 트랜잭션이 끝나고도 프록시 엔티티의 Lazy 로딩을 사용할 수 있도록 트랜잭션을 열어 놓습니다.

따라서 여전히 트랜잭션이 끝나도 엔티티를 영속 상태로 유지시키는데, 이렇게 관리중인 엔티티가 있는 상태에서 명시적인 트랜잭션(@Transactional)이 열렸고 이 트랜잭션이 커밋될 때 JPA 의 변경 감지가 동작했기 때문에 이와 같은 결과를 보이는 것입니다.

다음과 같은 코드를 사용하면 엔티티가 영속 상태인지 확인할 수 있습니다.

entityManager.contains(user)

아래와 같이 로그를 찍어 확인하면 다음과 같은 결과를 얻을 수 있습니다.

...
public Map getMyInfo(@PathVariable Long userId) {
    Map<String, Object> info = new HashMap<>();


    User user = userRepository.findById(userId).orElseThrow(() -> new RuntimeException("유저가 없습니다."));
    user.setProfileUrl("https://test.com/" + user.getProfileUrl());

    System.out.println("영속성 컨텍스트에서 관리중인가? => " + entityManager.contains(user));

    info.put("user", user);

    return info;
}

OSIV 를 켰을 때 : 영속성 컨텍스트에서 관리중인가? => true
OSIV 를 껐을 때 : 영속성 컨텍스트에서 관리중인가? => false

트랜잭션을 읽기 전용으로 해두었을 때에도 JPA 변경감지가 일어나지 않습니다.

@Transactional(readOnly = true)

하지만, 이 코드의 가장 근본적인 문제는 Entity 를 리턴 한다는 점입니다.

Entity 는 변경감지가 언제든 일어날 가능성이 있는 객체 입니다. 우리는 JPA 를 사용하면서 예상치 못한 동작을 막기 위해서 Command 와 Query 를 분리해야 합니다. 엔티티를 다룰 때, 같은 API 에서 Entity 는 데이터 변경 & 조회 두가지 용도로 사용 되서는 안됩니다.

데이터 변경이 있는 api 이고 조회 용 데이터도 보여주어야 하는 API 라면 return 용도의 DTO 클래스를 하나 만드는 것이 맞다. Entity 를 리턴 해서는 안됩니다. 같은 맥락으로 서비스단의 메소드를 설계할 때에는 데이터 변경 또는 입력이 있는 메소드의 경우 대상 Entity 를 리턴해서는 안됩니다.

DTO 를 별도로 만들어 관리하는 것이 정 어렵다면, 영속성 관리를 하지 않는 Entity (new 로 생성한, 또는 엔티티 매니저에서 detach 를 통해서 영속성 관리를 떼어낸) 에 BeanUtils.copyProperties 으로 필드를 복사해서 리턴하는 것이 훨씬 더 낫습니다

사실 OSIV 옵션은 Lazy 로딩이라는 강력한 기능을 사용하기 위해서 (편리함을 위해서) 켜 놓는 경우가 많이 있습니다. 따라서, 근본적인 해결책은 Command 와 Query 를 분리하는 것입니다. 엔티티는 언제는 변경 감지가 일어날 수 있다는 사실을 늘 고려해야 합니다.

개발 일기장

Reactive Programing

Reactive Programming

java.util.concurrent.Flow 클래스

Reactive Stream 이란?, backPressure 이란?

정의

개요

목적, 설계, 범위

BackPressure (배압)

API Components

API Components 명세서

Java I/O (Input/Output)란?

Programmed I/O (프로그램 입출력)

Blocking, Non-Blocking

Blocking API

Non Blocking API

NIO 와 IO 의 주요 차이점

Stream 기반 vs Buffer 기반

Blocking vs Non-Blocking IO

Selector

Java I/O 패키지란?

바이트 단위 스트림

문자 단위 스트림

보조 스트림

실험

자바 가비지컬렉터. 강한참조 (String Reference), 약한참조 (Weak Reference)

가비지컬렉터

가비지컬렉터와 Reachability

Soft, Weak, Phantom Reference

Reference와 Reachability

Softly Reachable과 SoftReference

ReferenceQueue

추가적인 설명

https://d2.naver.com/helloworld/329631

spring framework - @Value 가 동작하지 않는다면

JPA & Mysql 환경에서 데드락 관련 이슈

Food 엔티티

FoodRepository.java

FoodService.java

FoodController.java

정상적인 상황

동시에 4개의 요청을 받았을 때

모든 쓰레드가 1개의 connection 을 이미 가지고 간 상황

방법 1

방법 2

키 생성 방식 종류 (@GeneratedValue 어노테이션)

Flow chart

DefaultIdentifierGeneratorFactory.getIdentifierGeneratorClass

Dialect.getNativeIdentifierGeneratorStrategy

SequenceStyleGenerator.buildDatabaseStructure

SequenceStyleGenerator.isPhysicalSequence

SequenceStyleGenerator.generate

CrudRepository.java

SimpleJpaRepository.java

EntityManager.java

SessionImpl.java

PersistEventListener.java

DefaultPersistEventListener.java

AbstractSaveEventListener.java

IdentifierGenerator.java

SequenceStyleGenerator.java

DatabaseStructure.java

TableStructure.java

IsolationDelegate.java

IsolationDelegate 인터페이스JdbcIsolationDelegate.java

JdbcConnectionAccess.java

github 중간점검

메세지 브로커 push vs pull 방식 (RebbitMQ vs Kafka)

담당 사수분께 배웠던 것들

JPA - 예상치 못한 변경 감지가 동작하는 경우

IsolationDelegate 인터페이스

JdbcIsolationDelegate.java