거북이 developer

[Kubernetes] k8s 환경에서 springboot graceful shutdown 방법

흥부가귀막혀 — Mon, 29 Jan 2024 15:57:59 +0900

문제 상황

(1) request 처리 도중 Pod 이 종료되면 Request 가 비정상적으로 처리될 수 있음
(2) Pod 이 종료될 때 종료 중인 Pod 에 request 가 들어오면 클라이언트는 connection refused 에러를 만나게 됨

문제 해결을 위한 과정

(1)번 이슈는 Spring 에서 제공해주는 Graceful Shutdown 설정을 통해 해결 가능하다.

server:
    shutdown: graceful

(2)번 상황을 막기 위해 Readiness Probe 를 /actuator/health endpoint 로 잡아주고 Custom Health Indicator 를 구현하여 API 로 유입된 값에 따라 Application 상태를 Active/Inactive 하게 변경할 수 있게 하였다.
이렇게 하면 prestop 훅에 Application 상태를 Inactive 로 변경하여 Readiness Probe 를 통해 Service 에서 제외하고 Graceful Shutdown 을 하여 (2) 번 상황을 해결할 수 있을거라 판단하였다.
내가 진행한 방법이 Best Practice 일거라 생각했지만, 스프링 공식 가이드 문서를 보니 이게 왠걸.. 단순히 sleep 만 걸어주면 된다고 정리되어 있었다.
그래서 이게 왜 그런지 확인해보았다.

Pod 종료 절차

Pod 를 종료하면 위와 같은 절차가 진행되게 된다.
- A : Pod 종료 sequence
- B : 종료되는 Pod 으로 Request 가 가지 않도록 IP 를 변경하는 sequence
  - B2 : 삭제되는 Pod 이 속한 Service 의 엔드포인트에서 삭제될 Pod 제거 (엔드포인트 API 오브젝트 수정)
  - B3 : 각 노드에서 iptables 를 업데이트해서 연결이 종료되는 Pod 으로 새로운 커넥션이 전달되지 않도록 함
  - 보다 완전한 이해를 위해서는 kube-proxy, iptables 등 개념에 대한 학습이 필요할 듯 하다.

별도 작업을 해주지 않으면 B 의 sequence 가 더 오래 걸린다. 따라서 위와 같이 connection refused 되는 request 가 생겨날 수 있다.

Sleep 을 하면 어떻게 될까?

prestop 훅에 sleep 추가
sleep 을 통해 iptables 가 변경되기 위해 필요한 시간을 확보한다.
iptables 가 변경될때까지 Sleep 을 통해 Application 이 종료되지 않기 때문에 자연스럽게 Graceful Shutdown 을 수행할 수 있게 된다.

결론

내가 진행했던 Custom Headlth Indicator 와 Readness Probe 를 사용하는 전략도 이슈는 없지만 굳이 그렇게 할 필요는 없다.
k8s 환경에서 spring boot 의 graceful shutdown 을 위해서는 아래 두 가지 설정이 필요하다.
- Spring Application Properties 에 graceful shutdown 설정 추가
- prestop hook 에 sleep 커맨드 추가
어설픈 지식보단 공식문서와 전체적인 개념을 잘 파악하자

References

Kubernetes 구축

흥부가귀막혀 — Mon, 29 Jan 2024 15:25:58 +0900

공통(Master/Worker Node)

Docker 설치

Docker Engine Install 을 참고하여 사용하는 OS 에 맞게 설치 진행한다.
centos 버전으로 설치 진행
root 권한이 필요하기 때문에 root 계정으로 진행한다.

yum-utils 설치 및 docker repository 등록

sudo yum install -y yum-utils
sudo yum-config-manager \
    --add-repo \
    https://download.docker.com/linux/centos/docker-ce.repo

필요한 Docker Package 설치(특정 버전을 설치하고자 한다면, yum list docker-ce --showduplicates | sort -r 로 원하는 버전 확인 후 설치를 진행한다)

sudo yum install docker-ce docker-ce-cli containerd.io docker-compose-plugin -y

Docker 실행

sudo systemctl start docker

Kubernetes 설치

kubeadm 설치 를 참고하여 진행한다.
root 권한이 필요하기 때문에 root 계정으로 진행한다.

1. swap 비활성화

sudo /sbin/swapoff -a && sudo sed -i '/swap/s/^/#/' /etc/fstab

2. IPv4 포워딩 및 iptables에서 브리지된 트래픽 확인

Container Runtime 가이드에 따라 IPv4 포워딩 및 iptables에서 브리지된 트래픽 확인을 진행한다.
root 권한이 필요하기 때문에 root 계정으로 진행한다.

cat <<EOF | sudo tee /etc/modules-load.d/k8s.conf
overlay
br_netfilter
EOF

# sysctl params required by setup, params persist across reboots
cat <<EOF | sudo tee /etc/sysctl.d/k8s.conf
net.bridge.bridge-nf-call-iptables  = 1
net.bridge.bridge-nf-call-ip6tables = 1
net.ipv4.ip_forward                 = 1
EOF

# Apply sysctl params without reboot
sudo /sbin/sysctl --system

3. Container Runtime Interface 설치

Kubernetes 와 Container Runtime 을 연결해주기 위한 Container Runtime Interface 가 설치되야 하는데 종류가 몇가지 있다.
현재 구축한 kubernetes 는 cri-dockerd 로 설치

1) Containerd

Docker 설치 과정에서 설치된다. 다만, 정상적인 동작을 위해 Kubernetes 에서 제공하는 containerd 가이드 에 따라 추가로 작업을 진행해야 한다.

/etc/containerd/config.toml 설정 파일에서 cri disabled 제거

sed -i '/"cri"/ s/^/#/' /etc/containerd/config.toml

/etc/containerd/config.toml 설정 파일에서 runc 설정 추가

vi /etc/containerd/config.toml
[plugins."io.containerd.grpc.v1.cri".containerd.runtimes.runc]
  [plugins."io.containerd.grpc.v1.cri".containerd.runtimes.runc.options]
    SystemdCgroup = true

2) cri-dockerd

cri-dockerd README 를 참고하여 설치를 진행한다.
# Run these commands as root ###Install GO### wget https://storage.googleapis.com/golang/getgo/installer_linux chmod +x ./installer_linux ./installer_linux source ~/.bash_profile

git clone [https://github.com/Mirantis/cri-dockerd.git](https://github.com/Mirantis/cri-dockerd.git)  
cd cri-dockerd  
mkdir bin  
go build -o bin/cri-dockerd  
sudo mkdir -p /usr/local/bin  
sudo install -o root -g root -m 0755 bin/cri-dockerd /usr/local/bin/cri-dockerd  
sudo cp -a packaging/systemd/\* /etc/systemd/system  
sudo sed -i -e 's,/usr/bin/cri-dockerd,/usr/local/bin/cri-dockerd,' /etc/systemd/system/cri-docker.service  
sudo systemctl daemon-reload  
sudo systemctl enable cri-docker.service  
sudo systemctl enable --now cri-docker.socket

4. kubeadm, kubelet, kubectl 설치

kubernetes repository 등록

cat <<EOF | sudo tee /etc/yum.repos.d/kubernetes.repo
[kubernetes]
name=Kubernetes
baseurl=https://packages.cloud.google.com/yum/repos/kubernetes-el7-\$basearch
enabled=1
gpgcheck=1
gpgkey=https://packages.cloud.google.com/yum/doc/rpm-package-key.gpg
exclude=kubelet kubeadm kubectl
EOF

SELinux mode 변경

# Set SELinux in permissive mode (effectively disabling it)
sudo /sbin/setenforce 0
# 가이드에서는 permissive 모드로 변경하였지만, 효과적으로 하려면 disabled 로 설정해도 된다.(현재 구축된 kubernetes 는 disabled 로 설정)
# sudo sed -i 's/^SELINUX=enforcing$/SELINUX=permissive/' /etc/selinux/config     # permissive 로 변경 
sudo sed -i 's/^SELINUX=enforcing$/SELINUX=disabled/' /etc/selinux/config      # disabled 로 변경

kubeadm, kubelet, kubectl 설치 및 kubelet 실행

sudo yum install -y kubelet kubeadm kubectl --disableexcludes=kubernetes

sudo systemctl enable --now kubelet

Master Node 구축(⚠️ Worker 노드에서는 하면 안됨!)

Creating a cluster with kubeadm 을 참고하여 Master Node 를 구축한다.

1. kubeadm init 실행

Container Network Interface 를 어떤걸 쓰냐에 따라 init 수행시 --pod-network-cidr 설정을 다르게 가야한다.
현재 구축된 kubernetes 는 flannel 을 설치하였고 이에 맞게 init 설정을 진행함
원래는 calico 를 초기에 셋팅했었으나, ncloud 장비의 bpf 관련 이슈로 정상적으로 동작하지 않아 변경함.
CRI 로 Containerd, cri-dockerd 둘다 설치했을 경우 어떤 CRI 를 사용할 것인지 정해줘야 한다. init 실행시 --cri-socket 옵션을 추가하여 사용할 CRI 가 어떤건지 설정한다.

init command 실행

# flannel 의 기본 cidr 설정값인 10.244.0.0/16 을 설정한다.
sudo kubeadm init --pod-network-cidr=10.244.0.0/16 --cri-socket=unix:///var/run/cri-dockerd.sock

init 호출 후 stdout 에 출력된 Worker node 추가에 필요한 join command 내용을 잘 기록해둔다. 이거 안하면 Worker Node 추가가 불가능하기 때문에 다시 reset 해야함.

vi token.txt

kubeadm join <control-plane-host>:<control-plane-port> --token <token> --discovery-token-ca-cert-hash sha256:<hash>

sudo 권한 없이 kubectl 사용을 위한 설정 추가

mkdir -p $HOME/.kube
sudo cp -i /etc/kubernetes/admin.conf $HOME/.kube/config
sudo chown $(id -u):$(id -g) $HOME/.kube/config

❔ 혹시나 init 과정에서 실패가 발생했거나 master node 설정을 초기화 하고 싶다면? reset command 를 호출한다.

# 어떤 CRI 로 구축했는지 알아야 해서 --cri-socket 옵션을 넣어준다. 
sudo kubeadm reset --cri-socket=unix:///var/run/cri-dockerd.sock

2. CNI 설치(flannel)

다음 명령어를 통해 flannel 을 설치한다.
kubectl apply -f https://raw.githubusercontent.com/flannel-io/flannel/master/Documentation/kube-flannel.yml
간혹 flannel 설치 이후 /run/flannel 디렉토리 안 subnet.env 파일이 생성되지 않아 오류가 발생할 수 있다. 파일이 생성되었는지 확인하고 혹시 생성이 안되어있다면 다음과 같이 생성해준다.
sudo vi /run/flannel/subnet.env

FLANNEL\_NETWORK=10.244.0.0/16  
FLANNEL\_SUBNET=10.244.0.1/24  
FLANNEL\_MTU=1450  
FLANNEL\_IPMASQ=true

3. Master Node 에 필요한 pod 이 정상인지 확인

kubectl 을 통해 node 상태 및 control-plane 이 정상적으로 운영중인지 확인한다.

kubectl get nodes
NAME STATUS ROLES AGE VERSION  
dev-k8s-node-002 Ready control-plane 179m v1.26.1

혹여 node 의 STATUS 가 NotReady 일 경우 정확한 확인을 위해 pod 상태를 확인해본다.
kubectl get pod -n kube-system

NAME READY STATUS RESTARTS AGE  
coredns-787d4945fb-2f9f7 1/1 Running 0 179m  
coredns-787d4945fb-ksp7d 1/1 Running 0 179m  
etcd-dev-k8s-node-002 1/1 Running 0 3h  
kube-apiserver-dev-k8s-node-002 1/1 Running 0 3h  
kube-controller-manager-dev-k8s-node-002 1/1 Running 0 3h  
kube-proxy-98thd 1/1 Running 0 174m  
kube-proxy-d5ddx 1/1 Running 0 179m  
kube-scheduler-dev-k8s-node-002 1/1 Running 0 3h

STATUS 가 Running 이 아닌 Pod 이 있을 경우 다음 명령어를 통해 log 및 pod event 내용을 확인한다.

log 확인

kubectl logs coredns-787d4945fb-2f9f7 -n kube-system

pod event 확인

kubectl describe pod coredns-787d4945fb-2f9f7 -n kube-system

Name:                 coredns-787d4945fb-2f9f7
Namespace:            kube-system
Priority:             2000000000
Priority Class Name:  system-cluster-critical
Service Account:      coredns
Node:                 dev-k8s-node-002/10.113.137.19
Start Time:           Thu, 02 Feb 2023 12:09:20 +0900
Labels:               k8s-app=kube-dns
                      pod-template-hash=787d4945fb
Annotations:          <none>
Status:               Running
IP:                   10.244.0.3
IPs:
  IP:           10.244.0.3
Controlled By:  ReplicaSet/coredns-787d4945fb
Containers:
  coredns:
    Container ID:  docker://bb053af27773abb6622792d75f56835f1530ca435601337b9afd68910309790c
    Image:         registry.k8s.io/coredns/coredns:v1.9.3
    Image ID:      docker-pullable://registry.k8s.io/coredns/coredns@sha256:8e352a029d304ca7431c6507b56800636c321cb52289686a581ab70aaa8a2e2a
    Ports:         53/UDP, 53/TCP, 9153/TCP
    Host Ports:    0/UDP, 0/TCP, 0/TCP
    Args:
      -conf
      /etc/coredns/Corefile
    State:          Running
      Started:      Thu, 02 Feb 2023 12:09:21 +0900
    Ready:          True
    Restart Count:  0
    Limits:
      memory:  170Mi
    Requests:
      cpu:        100m
      memory:     70Mi
    Liveness:     http-get http://:8080/health delay=60s timeout=5s period=10s #success=1 #failure=5
    Readiness:    http-get http://:8181/ready delay=0s timeout=1s period=10s #success=1 #failure=3
    Environment:  <none>
    Mounts:
      /etc/coredns from config-volume (ro)
      /var/run/secrets/kubernetes.io/serviceaccount from kube-api-access-4xgx5 (ro)
Conditions:
  Type              Status
  Initialized       True 
  Ready             True 
  ContainersReady   True 
  PodScheduled      True 
Volumes:
  config-volume:
    Type:      ConfigMap (a volume populated by a ConfigMap)
    Name:      coredns
    Optional:  false
  kube-api-access-4xgx5:
    Type:                    Projected (a volume that contains injected data from multiple sources)
    TokenExpirationSeconds:  3607
    ConfigMapName:           kube-root-ca.crt
    ConfigMapOptional:       <nil>
    DownwardAPI:             true
QoS Class:                   Burstable
Node-Selectors:              kubernetes.io/os=linux
Tolerations:                 CriticalAddonsOnly op=Exists
                             node-role.kubernetes.io/control-plane:NoSchedule
                             node.kubernetes.io/not-ready:NoExecute op=Exists for 300s
                             node.kubernetes.io/unreachable:NoExecute op=Exists for 300s
Events:                      <none>

Worker Node 구축

1. Master Node 구축시 출력된 join 명령어를 수행한다.

# CRI 가 여러개 설치되었을 경우 join 명령어 수행시 --cri-socket 설정을 추가하여 CRI 를 설정한다.
sudo kubeadm join <control-plane-host>:<control-plane-port> --token <token> --discovery-token-ca-cert-hash sha256:<hash> --cri-socket=unix:///var/run/cri-dockerd.sock

2. Master Node 에서 Worker Node 가 정상적으로 Join 되었는지 확인한다.

kubectl get nodes

NAME               STATUS   ROLES           AGE    VERSION
dev-k8s-node-002   Ready    control-plane   3h9m   v1.26.1
dev-k8s-node-003   Ready    <none>          3h3m   v1.26.1

Reference

Java8 이후로 달라진 기능들

흥부가귀막혀 — Thu, 4 May 2023 18:19:31 +0900

개요

LTS 버전중에 현재 가장 점유율이 높고 사랑받는(?) 버전은 Java 8 과 11 인듯 싶다.(관련 통계: https://www.jetbrains.com/ko-kr/lp/devecosystem-2022/java/#Java_which-versions-of-java-do-you-regularly-use 참고)
최근 몇년간 신규 Java 버전이 계속 릴리즈 되었고 이와 관련되서 새로운 기능들이 많아졌다.
통계적으로 가장 많이 사용하고 있는 Java 8 이후에 어떤 기능들이 추가되었는지 살펴보자.

Java 21(2023. 09 월 release 예정) 까지의 주요 업데이트

ZGC Garbage Collector 추가

JDK 11부터 공개되었고, “Stop-The-World”로 인한 성능저하를 개선하기 위한 목적을 가지고 개발되었다.

ZGC 동작 원리 (Wiki, GitHub)

Pause Mark Start: Colored pointers 알고리즘을 기반해 ZGC Root에서 가리키는 객체의 상태값을 Mark(저장) 합니다.
Pause Mark End: 새로 들어온 객체를 대상으로 Mark가 일어나고, ZPage(ZGC에서 다루는 영역)를 찾아 RelocationSet()에 배치합니다.
Pause Relocate Start: Root 참조 객체에 대한 재배치를 하며, 이후 Load barriers 알고리즘을 통해 모든 객체를 안전하게 업데이트합니다.

특징

대기 시간이 짧은 Application에 적합한 Garbage Collection입니다.
Thread 가 실행 중일 때 동시 작업을 수행하기에 모든 작업을 동시에 수행합니다. (병렬 처리)
처리 시간이 10ms를 초과하지 않아 짧은 지연시간을 보장합니다.
8MB부터 16TB까지의 Heap 크기를 지원합니다.

적용 방법

Java Application 실행 시 다음 옵션 실행 (기본 설정: G1GC)
```
java -XX:+UseZGC -jar Application.java
```

Reference

https://www.blog-dreamus.com/post/zgc%EC%97%90-%EB%8C%80%ED%95%B4%EC%84%9C

Collection Factory Method 강화

Set, List, Map 인터페이스에 Immutable 성격의 Collection 을 생성할 수 있는 메서드가 추가 되었다.

 // AS-IS
 Set<String> set = new HashSet<>();
 set.add("제이든");
 set.add("Jayden");

 List<String> list = new ArrayList<>();
 list.add("제이든");
 list.add("버나드");
 list.add("자이노");
 list.add("메이슨");
 list.add("엘빈");

 Map<String, String> map = new HashMap<>();
 map.put("J","Jayden");
 map.put("B","Bernard");
 map.put("Z","Zino");
 map.put("M","Mason");
 map.put("E","Elvin");

 // TO-BE
 Set<String> set = Set.of("제이든", "Jayden", "개발3팀");

 List<String> list = List.of("제이든", "버나드", "자이노", "메이슨", "엘빈");

 Map<String, String> map
    = Map.of(
    "J", "Jayden",
    "B", "Bernard",
    "Z", "Zino",
    "M", "Mason",
    "E", "Elvin");

“var” 변수 타입 지원

로컬 변수 선언 시, “타입 추론”을 이용하여 명시적 타입 선언 없이도 변수 선언이 가능하도록 지원하는 신규 Keyword.
JDK 10 버전부터 공식 지원하기 시작하였고 이후 LTS 버전인 JDK 11 부터는 람다 타입에서도 사용 가능하도록 지원.
컴파일 시 변수 타입을 추론하기 때문에 성능에 영향을 주지는 않지만 가독성 높은 코드 작성을 위해 무분별한 “var” Keyword 이용은 지양하는 것이 좋다.

제약

멤버 변수 또는 Method 파라미터로 선언은 불가능하며, 오로지 Method 내 로컬 변수로만 선언 가능.

// 가능한 사항
public void test() {
  var strData = "Jayden";
  var doubleData = 1.5;
  var intData = 100;

  var datas = List.of(strData, doubleData, intData);

  for (var data : datas) {
     ...
  }
}

// 불가능한 사항
class MyModel {
  private var test; // X
}

신규 String Method 추가

문자열 내 공백 확인/제거 등 JDK 11 버전부터 String에 여러 편리한 기능을 지원하는 새로운 Method 들이 추가

신규 method

isBlank: 문자열이 비어있거나 공백이면 True 반환
lines: 줄 단위로 나뉘어 있는 문자를 배열로 반환
strip: 문자열 공백 제거 (기존 “trim()”이 ‘\u0020’ 이하 공백만을 제거 하였다면, “strip()”은 유니코드의 공백들을 전부 제거)
stripLeading: 문자열 앞의 공백을 제거
stripTrailing: 문자열 뒤의 공백을 제거
repeat: 문자열을 파라미터로 주어진 수 만큼 반복

public static void isBlankMethod() {
   "".isBlank();        // Output :: true
   "Jayden".isBlank();  // Output :: false
}

public static void linesMethod() {
   "Jayden\nBernard\nZino\nElvin\nMason".lines().toArray();
   // Output :: [Jayden, Bernard, Zino, Elvin, Mason]
}

public static void stripMethod() {
   " 여기어때컴퍼니 ".strip();         // Output :: (여기어때컴퍼니)
   " 여기어때컴퍼니 ".stripLeading();  // Output :: (여기어때컴퍼니  )
   " 여기어때컴퍼니 ".stripTrailing(); // Output :: (  여기어때컴퍼니)
}

public static void repeatMethod() {
   "Jayden ".repeat(3); // Output :: Jayden Jayden Jayden 
}

텍스트 블록

JDK 15부터 정식 지원하는 새로운 기능.
“”” {String 문자열 } “”” 형식을 이용해 Java 문자열을 보다 가독성있게 작성하도록 도와준다.
TextBlock 내 데이터를 동적으로 다루게 될 경우 %s 문자와 format Method 를 이용하여 구현할 수 있고, 또한 블록 내 “+” 연산자를 이용하여 구현할 수도 있다.

String message = """
      [
         {
            "type": "header",
            "text": {
                  "type": "plain_text",
                  "text": "%s :mag:",
                  "emoji": true
            }
         },
         {
            "type": "section",
            "text": {
                  "type": "mrkdwn",
                  "text": "*API*: %s\\n*remoteIP*: %s\\n*serverIP*: %s"
            }
         },
         {
            "type": "divider"
         }
      ]
         """;

Switch 표현식 기능 향상

Case문 람다식 지원

static void  test(Day day){
        switch (day) {
             case MONDAY, FRIDAY, SUNDAY -> System.out.println(6);
             case TUESDAY                -> System.out.println(7);
             case THURSDAY, SATURDAY     -> System.out.println(8);
             case WEDNESDAY              -> System.out.println(9);
    }
}

Switch 문 값 직접 반환

public void test(Day day) {
        System.out.println(
                switch (day) {
                    case MONDAY, FRIDAY, SUNDAY -> 6;
                    case TUESDAY                -> 7;
                    case THURSDAY, SATURDAY     -> 8;
                    case WEDNESDAY              -> 9;
            });
}

yield 예약어 이용한 값 리턴 방식 추가

public void test(Day day) {
        int cnt = switch (day) {
            case MONDAY -> 0;
            case TUESDAY -> 1; 
            case WEDNESDAY -> {
                int k = day.toString().length();
                int result = k+5;
        yield result;
                //break result; <----- java 12 Switch Expression
            }
            default -> 0;
        };
}

yield 키워드는 항상 Switch 블록 내부에서만 사용된다.

public void test(Day day) {
        int cnt = switch (day) {
            case MONDAY -> 0;
            case TUESDAY -> yield 1; // error! yield는 block 안에서만 유효다
            case WEDNESDAY -> { yield 2;} // ok
            default -> 0;
        }
}

추가로 보통 java 예약어는 변수명으로 지정이 불가능하지만 yield 키워드는 변수명으로 사용이 가능하다.

int volatile = 3; // error!
int yield = 3; // ok

default 선언 여부에 따른 compile 에러

enum Test {
  FIRST,
  SECOND,
  THIRD;
}

Test test = getTest();

// default 를 선언하지 않아 compile 에러가 발생
switch(test) {
  case FIRST -> 1;
  case SECOND -> 2; 
}

// default 를 선언하여 case 에 모든 조건을 추가하지 않아도 compile 에러가 발생하지 않음.
switch(test) {
  case FIRST -> 1;
  default -> 0; 
}

Pattern Matching for switch

아직 Preview 기능이라 정식 지원되는 기능은 아님 (https://openjdk.org/jeps/433)
instanceof 분기처리

// if
static String formatter(Object obj) {
    String formatted = "unknown";
    if (obj instanceof Integer i) {
        formatted = String.format("int %d", i);
    } else if (obj instanceof Long l) {
        formatted = String.format("long %d", l);
    } else if (obj instanceof Double d) {
        formatted = String.format("double %f", d);
    } else if (obj instanceof String s) {
        formatted = String.format("String %s", s);
    }
    return formatted;
}

// switch
static String formatterPatternSwitch(Object obj) {
    return switch (obj) {
        case Integer i -> String.format("int %d", i);
        case Long l    -> String.format("long %d", l);
        case Double d  -> String.format("double %f", d);
        case String s  -> String.format("String %s", s);
        default        -> obj.toString();
    };
}

null 분기처리

// if
static void testFooBar(String s) {
    if (s == null) {
        System.out.println("Oops!");
        return;
    }
    switch (s) {
        case "Foo", "Bar" -> System.out.println("Great");
        default           -> System.out.println("Ok");
    }
}

// switch
static void testFooBar(String s) {
    switch (s) {
        case null         -> System.out.println("Oops");
        case "Foo", "Bar" -> System.out.println("Great");
        default           -> System.out.println("Ok");
    }
}

when 예약어 사용

// AS-IS
static void testTriangle(Shape s) {
    switch (s) {
        case null:
            break;
        case Triangle t:
            if (t.calculateArea() > 100) {
                System.out.println("Large triangle");
                break;
            }
        default:
            System.out.println("A shape, possibly a small triangle");
    }
}

// TO-BE
static void testTriangle(Shape s) {
    switch (s) {
        case null -> 
            { break; }
        case Triangle t
        when t.calculateArea() > 100 ->
            System.out.println("Large triangle");
        case Triangle t ->
            System.out.println("Small triangle");
        default ->
            System.out.println("Non-triangle");
    }
}

instanceof 연산자에 대한 Pattern Matching

Instanceof 내부에서 객체를 캐스팅 하는 과정이 필요하였으나, 캐스팅 과정을 내부에서 지원할 수 있도록 변경
JDK 16 부터 지원

// 기존 Java 8 코드
    @Override
    public boolean equals(Object obj) {
        if (obj instanceof Student) {
            Student student = (Student) obj;
            if (this.studentNumber == student.studentNumber) {
                return true;
            } else {
                return false;
            }
        }
        return false;
    }

// Java 16 instanceof 연산자에 대한 pattern matching
    @Override
    public boolean equals(Object obj) {
        if (obj instanceof Student student) {
            if (this.studentNumber == student.studentNumber) {
                return true;
            } else {
                return false;
            }
        }
        return false;
    }

Record Data Class

JDK 14 버전부터 공개된 Immutable 객체를 생성하는 새로운 유형의 클래스.
Record 선언을 하게 되면 기존 toString, equals, hashCode 메소드를 자동으로 구현해주며, 모든 인스턴스 필드를 초기화해주는 생성자가 생성이 됩니다.
Immutable 객체이기 때문에 모든 값은 생성자를 통해 설정되어야 합니다.
DTO 와 같은 Data Object 용도로 활용 시 보다 편리하고 간결하게 구분할 수 있습니다.
setter 를 통해 값을 주입하는 라이브러리 혹은 기능을 구현한다면 Record Class 를 사용할 수 없다.
Record Class는 상속이 불가능하다. (모든 필드는 “private final ,,”로 선언이 되기에,,)
단순 선언

   public record RecordUserData(String name, int weight) {

   }

   ...

   RecordUserData userRecord = new RecordUserData("Jayden", 110);

   // Output :: Jayden
   System.out.println(userRecord.name());

   // Output :: 110
   System.out.println(userRecord.weight());

   // Output :: false
   System.out.println(userRecord.equals(new RecordUserData("Jayden", 90)));

   // Output :: true
   System.out.println(userRecord.equals(new RecordUserData("Jayden", 110)));

   // Output :: RecordUserData[name=Jayden, weight=110]
   System.out.println(userRecord);

Static 변수와 Method 선언

public record Citizen(String name, String country) {
    public static String UNKNOWN_COUNTRY = "Unknown";
}

public record Citizen(String name, String country) {
    public static Citizen justCountry(String country) {
        return new Citizen("", country);
    }
}

String country = Citizen.UNKNOWN_COUNTRY;
Citizen citizen = Citizen.justCountry("korea");

Interface Private Method 지원

JDK9 부터 지원

// example
public interface Foo {

    default void bar() {
        System.out.print("Hello");
        baz();
    }

    private void baz() {
        System.out.println(" world!");
    }
}
// static method 도 사용 가능
public interface Foo {

    static void buzz() {
        System.out.print("Hello");
        staticBaz();
    }

    private static void staticBaz() {
        System.out.println(" static world!");
    }
}

Sealed class

무분별한 상속을 막기 위한 목적으로 등장한 기능으로 지정한 클래스 외 상속을 허용하지 않으며, 지정한 클래스 외 상속 불가능.
즉, 클래스 또는 인터페이스는 이제 어떤 클래스가 이를 구현하거나 확장할 수 있는지 정의할 수 있다. 이를 통해 도메인 모델링 및 라이브러리 보안 강화에 유용해진다.
JDk 17 부터 지원
Sealed interface

public sealed interface Service permits Car, Truck {

    int getMaxServiceIntervalInMonths();

    default int getMaxDistanceBetweenServicesInKilometers() {
        return 100000;
    }

}

Sealed abstract class

public abstract sealed class Vehicle permits Car, Truck {

    protected final String registrationNumber;

    public Vehicle(String registrationNumber) {
        this.registrationNumber = registrationNumber;
    }

    public String getRegistrationNumber() {
        return registrationNumber;
    }

}

추가 확장을 방지하고자 한다면 final 을 선언한다.

public final class Truck extends Vehicle implements Service {

    private final int loadCapacity;

    public Truck(int loadCapacity, String registrationNumber) {
        super(registrationNumber);
        this.loadCapacity = loadCapacity;
    }

    public int getLoadCapacity() {
        return loadCapacity;
    }

    @Override
    public int getMaxServiceIntervalInMonths() {
        return 18;
    }

}

추가 확장을 허용하려면 non-sealed 를 정의한다.

public non-sealed class Car extends Vehicle implements Service {

    private final int numberOfSeats;

    public Car(int numberOfSeats, String registrationNumber) {
        super(registrationNumber);
        this.numberOfSeats = numberOfSeats;
    }

    public int getNumberOfSeats() {
        return numberOfSeats;
    }

    @Override
    public int getMaxServiceIntervalInMonths() {
        return 12;
    }

}

제약

허용된 모든 하위 클래스는 봉인된 클래스와 동일한 모듈에 속해야 한다.
허용된 모든 하위 클래스는 봉인된 클래스를 명시적으로 확장해야 한다.
허용된 모든 하위 클래스는 수정자를 정의해야 한다.(final, sealed 또는 non-sealed)

Record 와의 궁합

Record class 는 내부적으로 final 이 명시된 class 이기 때문에 좀더 간결한 구조로 정의가 가능하다.

public sealed interface Vehicle permits Car, Truck {

    String getRegistrationNumber();

}

public record Car(int numberOfSeats, String registrationNumber) implements Vehicle {

    @Override
    public String getRegistrationNumber() {
        return registrationNumber;
    }

    public int getNumberOfSeats() {
        return numberOfSeats;
    }

}

public record Truck(int loadCapacity, String registrationNumber) implements Vehicle {

    @Override
    public String getRegistrationNumber() {
        return registrationNumber;
    }

    public int getLoadCapacity() {
        return loadCapacity;
    }

}

Reflection

java.lang.Class 에서 다음과 같은 2개의 API 를 추가로 지원한다.
isSealed: 주어진 클래스 또는 인터페이스가 봉인된 경우 true 를 반환.
getPermittedSubclasses: 허용된 모든 하위 클래스를 나타내는 객체 배열을 반환.

Assertions.assertThat(truck.getClass().isSealed()).isEqualTo(false);
Assertions.assertThat(truck.getClass().getSuperclass().isSealed()).isEqualTo(true);
Assertions.assertThat(truck.getClass().getSuperclass().getPermittedSubclasses())
  .contains(ClassDesc.of(truck.getClass().getCanonicalName()));

Virtual Thread(aka. Project Loom)

Java 21 에 정식 지원 예정 (관련 기사 : https://www.infoq.com/news/2023/04/virtual-threads-arrives-jdk21/)
JDK 21 부터 Java 는 플랫폼 쓰레드와 가상 쓰레드라는 2종류의 쓰레드를 지원
플랫폼 쓰레드는 OS 쓰레드에 대한 1대1 매핑이고, 가상 쓰레드는 Java 가 제공하는 경량 쓰레드로 하나의 OS 쓰레드 내에서 가상 쓰레드 1만개를 동시 실행 가능

try (var executor = Executors.newVirtualThreadPerTaskExecutor()) {
    IntStream.range(0, 10_000).forEach(i -> {
        executor.submit(() -> {
            Thread.sleep(Duration.ofSeconds(1));
            return i;
        });
    });
}

Reference

Spring 에서 제공하는 MongoDB Annotation

흥부가귀막혀 — Wed, 5 Apr 2023 12:17:19 +0900

개요

Application 에서 정의한 Model 객체가 어떻게 MongoDB 로 변환이 되어 들어가고, 조회시에는 어떻게 Model 객체로 맵핑이 되는지에 대한 궁금증에서 시작.
MappingMongoConverter 에서 이러한 기능을 담당하는거로 확인했지만, 이번 시간에는 이부분에 대해 깊게 파진 않고 이러한 Mapping 을 도와주는 Annotation 에 대해 알아보려고 한다.

@Document

Spring Data Mongodb 에서만 사용할 수 있는 Annotation
어노테이션이 정의된 Class 를 사용할 MongoDB Collection 을 지정할 수 있다.

/**
 * 나는 base collection 에 들어갈거다!
 */
@Document("base")
public class BaseDocument {
    @Id
    private String documentId;
}

@Id

ObjectId 에 해당하는 필드를 지정할 경우 선언할 수 있다.
해당 어노테이션이 없을 경우 필드 네이밍이 id 라고 선언한 필드를 ObjectId 로 인지한다.
id 이름으로 선언된 필드와 @Id 어노테이션이 지정된 필드가 있을경우 어노테이션을 선언한 필드를 ObjectId 필드로 인지한다.
@PersistenceConstructor 로 지정한 생성자에 id 값을 주입 안하더라도 MappingMongoConverter 에서 field injection 으로 값을 넣어준다.(이건 setter method 가 없어도 동일하다.)
해당 어노테이션은 MongoDB 전용은 아니고 Spring Data 하위 프로젝트에서 모두 사용할 수 있다.

@Id annotation 을 사용할 경우

public class BaseDocument {
    @Id
    private String documentId;
}

@Id annotation 을 사용하지 않을 경우

public class BaseDocument {
    private String id;
}

setter method 가 없어도 주입된다.

public class BaseDocument {
    @Id
    private String id;

        public String getId() {
           return id;
        }
}

@PersistenceConstructor 를 사용할 때 굳이 id 값을 주입받지 않아도 된다.

public class BaseDocument {
    @Id
    private String id;
        private String name;

        @PersistenceConstructor
    BaseDocument(String name) {
        this.name = name;
    }
}

@PersistenceConstructor

MongoDB 에서 가져온 데이터(DBObject)를 Model Class 로 전환할 때 사용할 생성자를 지정한다.
해당 어노테이션이 없을 경우 기본 생성자를 찾아서 사용한다.
해당 어노테이션을 지정하는 생성자는 public 이 아니어도 된다. protected, private, package private 로 정의된 생성자 모두 사용 가능하다. 이게 가능한 이유는 역시 Java Reflection 때문.
생성자에 정의된 각 argument 의 key 값이 db 필드의 key 값과 일치하면 주입해준다.
해당 어노테이션은 MongoDB 전용은 아니고 Spring Data 하위 프로젝트에서 모두 사용할 수 있다.

public class BaseDocument {
    private String service;
    private Integer version;
    private String name;

    public BaseDocument(String service, Integer version) {
        this.service = service;
        this.version = version;
    }

    @PersistenceConstructor
        // 어노테이션을 지정했기 때문에 위에 선언한 생성자를 사용하지 않는다는데 내 맥북과 마우스 전부를 건다.
        // private 여도 이 생성자를 쓴다는거에 내 맥북과 마우스 전부를 건다.
    private BaseDocument(String service, Integer version, String name) {
        this.service = service;
        this.version = version;
        this.name = name;
    }
}

@CreatedDate, @LastModifiedDate

Document 의 생성시간, 변경 시간을 정의한 field 에 선언하면 알아서 날짜값을 만들어준다.
단, 해당 어노테이션이 의도한대로 동작하기 위해서는 @EnableMongoAuditing, @EnableReactiveMongoAuditing 가 선언되야한다.
단, save 를 통해 한번 저장된 data 를 또 save 하게 될 경우 의도한대로 동작하지 않는다. 한번 save 된 데이터 일 경우 findAndModify 를 쓰거나 @Version Annotation 을 활용해야한다.
해당 어노테이션은 MongoDB 전용은 아니고 Spring Data 하위 프로젝트에서 모두 사용할 수 있다.

@EnableMongoAuditing 혹은 @EnableReactiveMongoAuditing 을 선언하고

@SpringBootApplication
@EnableReactiveMongoAuditing
public class Application {
    public static void main(String[] args) {
        SpringApplication.run(Application.class, args);
    }
}

다음과 같이 class 를 선언하고

public class BaseDocument {
    @Id
    private String id;
    @CreatedDate
    private Date createTime;
    @LastModifiedDate
    private Date updateTime;

    public BaseDocument() {
    }

    @Override
    public String toString() {
        return ToStringBuilder.reflectionToString(this, ToStringStyle.NO_CLASS_NAME_STYLE);
    }
}

이렇게 코드를 짜서 보면

BaseDocument saveDocument = template.save(new BaseDocument());
System.out.println(saveDocument);

console 에 이렇게 찍힌다.

[mongod output] [id=63bfca54eb3c3c148edb42a9,createTime=Thu Jan 12 17:52:36 KST 2023,updateTime=Thu Jan 12 17:52:36 KST 2023]

@CreatedBy, @LastModifiedBy

Document 를 생성 및 변경에 대한 사용자 관련 field 에 해당 어노테이션을 선언하면 알아서 해당 값을 주입해준다.
단, 해당 어노테이션이 의도한대로 동작하기 위해서는 @EnableMongoAuditing, @EnableReactiveMongoAuditing 가 선언되야한다.
또한 생성할 사용자 정보를 전달해주기 위해 AuditorAware 혹은 ReactiveAuditorAware 를 정의해줘야한다.
해당 어노테이션은 MongoDB 전용은 아니고 Spring Data 하위 프로젝트에서 모두 사용할 수 있다.

@EnableMongoAuditing 혹은 @EnableReactiveMongoAuditing 을 선언하고

@SpringBootApplication
@EnableReactiveMongoAuditing
public class Application {
    public static void main(String[] args) {
        SpringApplication.run(Application.class, args);
    }
}

AuditorAware 혹은 ReactiveAuditorAware 를 정의하고

@Component
public class UserAudtiting implements AuditorAware<String>{

    @Override
    public Optional<String> getCurrentAuditor() {
        return Optional.of("me");
    }

}

다음과 같이 class 를 선언하고

public class BaseDocument {
    @Id
    private String id;
    @CreatedBy
    private  String createUser;
    @LastModifiedBy
    private Date updateUser;

    public BaseDocument() {
    }

    @Override
    public String toString() {
        return ToStringBuilder.reflectionToString(this, ToStringStyle.NO_CLASS_NAME_STYLE);
    }
}

이렇게 코드를 짜서 보면

BaseDocument saveDocument = template.save(new BaseDocument());
System.out.println(saveDocument);

console 에 이렇게 찍힌다.

[mongod output] [id=63bfca54eb3c3c148edb42a9,createUser=me,updateUser=me]

@Transient

DB 에 기록하지 않을 field 가 있을 경우 해당 어노테이션을 선언한다.
Spring Data Mongodb 는 기본적으로 field 에 정의된 데이터만 DB 에 기록하기 때문에 getter method 로 선언한 내용은 해당 어노테이션을 붙이지 않아도 된다.(어차피 DB 에 저장하지 않을것이기 때문)
해당 어노테이션은 MongoDB 전용은 아니고 Spring Data 하위 프로젝트에서 모두 사용할 수 있다.

@Version

Document 의 version 값에 해당하는 field 가 있을 경우 해당 어노테이션을 선언하면 save 할 때 자동으로 version 값을 올려준다.
해당 어노테이션을 둘 경우 save query 에 기존 version 값이 조건으로 추가되어 동시에 save 할 경우 벌어질 동시성 이슈를 막을 수 있다.(다만, 이건 로직적으로 잘 파악하고 사용해야할듯 하다.)

다음과 같이 class 를 선언하고

public class BaseDocument {
    @Id
    private String id;
    @Version
    private  long version;

    public BaseDocument() {
    }

    @Override
    public String toString() {
        return ToStringBuilder.reflectionToString(this, ToStringStyle.NO_CLASS_NAME_STYLE);
    }
}

이렇게 코드를 짜서 보면

BaseDocument saveDocument = template.save(new BaseDocument());
System.out.println(saveDocument);
BaseDocument secondSaveDocument = template.save(saveDocument);
System.out.println(secondSaveDocument);

console 에 이렇게 찍힌다.

[mongod output] [id=63bfca54eb3c3c148edb42a9,version=1]
[mongod output] [id=63bfca54eb3c3c148edb42a9,version=2]

@Field

Spring Data Mongodb 에서만 사용할 수 있는 Annotation
DB 에 정의된 field 이름과 model 에 정의된 field 이름이 다를 경우 사용할 수 있다.
MongoDB 에서 Model Class 로 Mapping 할 때 Setter method 를 사용하고자 할때도 사용할 수 있다. 단, 이럴 경우 @AccessType(AccessType.Type.PROPERTY) 를 같이 선언해줘야 한다.

DB 에는 createTime, Model Class 에는 createDate 라고 정의했을 경우

public class BaseDocument {
    @Id
    private String id;
    @ Field("createTime")
    private  Date createDate;

    public BaseDocument() {
    }

    @Override
    public String toString() {
        return ToStringBuilder.reflectionToString(this, ToStringStyle.NO_CLASS_NAME_STYLE);
    }
}

setter 함수로 데이터 injection 을 할 경우

public class BaseDocument {
    @Id
    private String id;
    private NameCard nameCard = new NameCard();

    public BaseDocument() {
    }

        @AccessType(AccessType.Type.PROPERTY)
        @Field("name")
        public setPhone(String name) {
            nameCard.setName(name);
        }

        @AccessType(AccessType.Type.PROPERTY)
        @Field("phoneNumber")
        public setPhoneNumber(String phoneNumber) {
            nameCard.setPhoneNumber(phoneNumber);
        }

    @Override
    public String toString() {
        return ToStringBuilder.reflectionToString(this, ToStringStyle.NO_CLASS_NAME_STYLE);
    }
}

@TypeAlias

MongoDB 의 Collection 에는 다양한 유형의 Model Class 를 Document 로 포함할 수 있는데, 이렇게 저장된 객체를 조회할 때는 입력당시 사용한 Model Class 에 올바르게 Mapping 하는 것이 중요하다. 따라서 Document 를 저장할 때 함께 타입 정보를 저장하는 매커니즘을 사용하며, 이러한 역할에 도움을 주는 것이 바로 _class 필드다.
하지만 이 기능의 치명적인 단점은, _class 로 기록된 타입값이 추후 변경되면 동일한 모델이더라도 올바르게 맵핑할 수 없다는 단점이 존재한다.(예를 들어 package 명이 변경되거나 Model Class 이름을 변경했을 경우)
그래서 이런 불상사를 막기 위해 _class 에 기록할 특정 네이밍을 정하고자 한다면, @TypeAlias 를 사용하면 된다.

❓ @TypeAlias 가 동작하는 케이스는?

MongoTemplate 혹은 ReactiveMongoTemplate 에서 쿼리를 요청할 때 파라미터로 전달하는 Entity Class 가 Abstract class 혹은 Interface 일 경우 동작한다.
만약 구현체 Class 를 Entity Class 로 넘겨줄 경우 _class 값을 통한 Model Class 맵핑은 무시되고 Entity Class 로 전달한 구현체 Class 에 맞춰 데이터가 맵핑된다.

❓ _class 가 Package 경로로 주입된 데이터의 모델에 @TypeAlias 를 넣으면 어떻게 될까?

이미 package 경로로 _class 가 입력된 데이터에 대한 Model Class 에 @TypeAlias 로 다른 네이밍을 정의했을 경우에도 조회시 정상동작한다.
즉, Spring Data 에서는 _class 값이 Model Class 의 Package 경로와 일치하거나 @TypeAlias 의 정의된 네이밍과 일치하면 정상적으로 맵핑시키는 구조로 보인다.

❓ 중간에 @TypeAlias 를 빼면 어떻게 될까?

_class 가 이미 @TypeAlias 에 지정된 값으로 입력되었다면 이후 @TypeAlias 를 제거하거나 네이밍을 변경할 경우 정상적으로 맵핑을 못시킨다.
단, 이는 특정 field 가 Object 형태이고 해당 Object 내부에 _class 가 정의되었을경우 정상적으로 맵핑을 못시키지만, root 경로에 있는 _class 는 실제 Model Class 와 달라도 정상동작한다. 그 이유는 MongoTemplate 에서 findById 등으로 조회시 class 값을 넘겨주는데 이걸로 맵핑을 하기 때문에 root 경로에 있는 _class 가 달라도 정상적으로 맵핑이 가능하다.

❓ 특정 필드의 데이터를 Map 혹은 Object 로 조회하면 어떻게 될까?

만약 @TypeAlias 로 선언된 class 가 있거나, _class 와 동일한 경로에 Model Class 가 존재할 경우 해당 class 로 맵핑시켜준다.

⚠️ @TypeAlias 사용시 주의사항

Spring 에서 Model Mapping 에 사용하는 MappingMongoConverter 에 @TypeAlias 어노테이션이 정의된 네임에 맵핑할 class 정보가 사전에 미리 셋팅 되어있어야 한다.
정상적인 Spring Application 이라면 @EnableMongoRepositories 혹은 @EnableReactiveMongoRepositories 가 선언되어있을 경우 이를 scan 하고 자동으로 생성된 MappingMongoConverter 에 주입해주기 때문에 이슈가 없다.
하지만 직접 MongoTemplate 혹은 MappingMongoConverter 를 생성해서 사용하게 될 경우 위의 scan 작업에 대한 결과가 주입되지 못하기 때문에 해당 class 에 대해 save query 를 수행해야지만 @TypeAlias 네임과 class 정보가 맵핑된다. 그전까지는 정상적으로 맵핑이 되지 않는다.

이렇게 TypeAlias 를 정의하고

/**
 * 나는 base collection 에 들어갈거다!
 */
@Document("base")
@TypeAlias("base")
public class BaseDocument {
    @Id
    private String id;
}

save 를 해보면?

{
  "_id":{
           "$oid":"63c001f341eb836dfd411888"
        },
  "_class":"base"
}

@DBRef

Spring Data Mongodb 에서만 사용할 수 있는 Annotation
MongoDB 에서 제공하는 DBRefs 를 지원하도록 만들어진 어노테이션
DBRefs 로 정의된 Data 일 경우 자동으로 해당 Collection 에 맞게 데이터를 조회하여 model 에 맵핑해준다.
어노테이션의 db 속성값을 통해 다른 Database 에 들어간 데이터도 맵핑이 가능합니다.
lazy 속성값을 통해 field 에 접근하기 전까지 data 조회를 지연시킬 수 있습니다.(기본값은 false 라서 처음 mapping 과정에서 모든 객체를 로드합니다.)
해당 어노테이션은 DBObject 에서 Model 객체로 Mapping 해주는 기능에만 사용하기 때문에 아쉽게도 save 시에는 자동으로 생성해주진 않는다.
자세한 예제는 baeldung 참고

@EnableMongoAuditing, @EnableReactiveMongoAuditing

Spring Data Mongodb 에서만 사용할 수 있는 Annotation
Spring Data 에서 제공하는 Auditing 기능을 MongoDB 에 맞게 제공할 수 있도록 지원하는 Annotation
@CreatedBy, @LastModifiedBy, @CreatedDate, @LastModifiedDate 어노테이션을 사용할 경우 해당 annotation 을 특정 class(Configuration 혹은 Application Class 등)에 정의해줘야한다.

[Spring Boot] NoClassDefFoundError 와 Spring Boot 의 Executable Jar 관계

흥부가귀막혀 — Wed, 14 Sep 2022 17:51:27 +0900

최근에 Spring Boot 로 개발된 Web Application 을 운영하던 도중에 아래와 같은 Error 를 맞딱뜨렸습니다.

2022-08-30 11:07:35.485  WARN 3038 --- [SpringContextShutdownHook] o.s.c.support.DefaultLifecycleProcessor  : Failed to stop bean 'webServerGracefulShutdown'

 java.lang.BootstrapMethodError: java.lang.NoClassDefFoundError: org/springframework/boot/web/server/GracefulShutdownResult
     at org.springframework.boot.web.servlet.context.WebServerGracefulShutdownLifecycle.stop(WebServerGracefulShutdownLifecycle.java:51)
     at org.springframework.context.support.DefaultLifecycleProcessor.doStop(DefaultLifecycleProcessor.java:238)
     at org.springframework.context.support.DefaultLifecycleProcessor.access$300(DefaultLifecycleProcessor.java:53)
     at org.springframework.context.support.DefaultLifecycleProcessor$LifecycleGroup.stop(DefaultLifecycleProcessor.java:377)
     at org.springframework.context.support.DefaultLifecycleProcessor.stopBeans(DefaultLifecycleProcessor.java:210)
     at org.springframework.context.support.DefaultLifecycleProcessor.onClose(DefaultLifecycleProcessor.java:128)
     at org.springframework.context.support.AbstractApplicationContext.doClose(AbstractApplicationContext.java:1022)
     at org.springframework.boot.web.servlet.context.ServletWebServerApplicationContext.doClose(ServletWebServerApplicationContext.java:170)
     at org.springframework.context.support.AbstractApplicationContext$1.run(AbstractApplicationContext.java:949)
 Caused by: java.lang.NoClassDefFoundError: org/springframework/boot/web/server/GracefulShutdownResult
     ... 9 common frames omitted
 Caused by: java.lang.ClassNotFoundException: org.springframework.boot.web.server.GracefulShutdownResult
     at java.net.URLClassLoader.findClass(URLClassLoader.java:381)
     at java.lang.ClassLoader.loadClass(ClassLoader.java:424)
     at org.springframework.boot.loader.LaunchedURLClassLoader.loadClass(LaunchedURLClassLoader.java:151)
     at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
     ... 9 common frames omitted

 2022-08-30 11:08:05.486  INFO 3038 --- [SpringContextShutdownHook] o.s.c.support.DefaultLifecycleProcessor  : Failed to shut down 1 bean with phase value 2147483647 within timeout of 30000ms: [webServerGracefulShutdown]
 2022-08-30 11:08:35.514  INFO 3038 --- [SpringContextShutdownHook] j.LocalContainerEntityManagerFactoryBean : Closing JPA EntityManagerFactory for persistence unit 'default'
 2022-08-30 11:08:35.519  INFO 3038 --- [SpringContextShutdownHook] o.s.s.c.ThreadPoolTaskScheduler          : Shutting down ExecutorService 'taskScheduler'
 2022-08-30 11:08:35.520  INFO 3038 --- [SpringContextShutdownHook] com.zaxxer.hikari.HikariDataSource       : HikariPool-1 - Shutdown initiated...
 2022-08-30 11:08:35.528  INFO 3038 --- [SpringContextShutdownHook] com.zaxxer.hikari.HikariDataSource       : HikariPool-1 - Shutdown completed.
 2022-08-30 11:08:35.530  INFO 3038 --- [SpringContextShutdownHook] o.s.s.c.ThreadPoolTaskScheduler          : Shutting down ExecutorService

Application 을 배포하기 위해 종료하던 과정에서 발생하였는데, 해당 Error 로 인해 Application 이 정상적으로 종료되지 않았고 결국 kill -9 명령어로 강제 종료시킬 수 밖에 없었습니다.

처음 보는 에러가 발생할 때.jpg

갑작스러운 Error 였고 언제 다시 발생할지 모른다는 불안감에 오랜 시간 해당 Error 가 발생한 원인을 분석해보았는데 그 결과 위 에러는 SpringBoot 의 Executable Jar 동작 방식과 연관이 있었습니다.

Java 는 Nested Jar 파일 (즉, jar 안에 jar 가 들어가있는 파일)을 로드하는 표준 방법을 제공하지 않습니다.
그래서 Spring Boot 에서는 자체적으로 Nested Jar 파일을 실행하기 위한 Jar 파일 구조를 정의하고 Loader 를 구현하였습니다.

Spring Boot Loader 를 사용하기 위한 Jar 파일 구조는 다음과 같이 정의되어있습니다.

example.jar
 |
 +-META-INF
 |  +-MANIFEST.MF
 +-org
 |  +-springframework
 |     +-boot
 |        +-loader
 |           +-<spring boot loader classes>
 +-BOOT-INF
    +-classes
    |  +-mycompany
    |     +-project
    |        +-YourClasses.class
    +-lib
       +-dependency1.jar
       +-dependency2.jar

Application Service 에 관련된 코드(개발자가 작성한 코드) 는 BOOT-INF/classes 경로에 정리되고,
의존성이 추가된 lib 들은 BOOT-INF/lib 에 있도록 정의하였습니다.

실제 spring-boot-maven-plugin 을 통해 만들어진 jar 결과물을 보면 위와 같은 구조를 확인할 수 있고
추가적으로 Spring Boot 에서 구현한 JarLauncher 구현 내용을 보시면 위 경로에 대해 정의되어 있는걸 확인하실 수 있습니다.

JarLauncher 는 Spring Boot 에서 jar 형태로 빌드된 Spring Boot Application 을 실행하기 위해 만들어진 Launcher Class 입니다.
그래서 jar 로 빌드된 결과물의 Main Class 는 해당 Launcher 로 지정이 되야 정상적으로 실행이 가능합니다. 실제 Spring Boot Jar 에서 META-INF/MANIFEST.MF 내용을 확인해보면 아래와 같이 정의된걸 확인할 수 있습니다.

Main-Class: org.springframework.boot.loader.JarLauncher
Start-Class: com.mycompany.project.MyApplication

이처럼 java 에서 수행할 Main-Class 는 Spring Boot 에서 구현한 JarLauncher 로 지정된걸 알 수 있습니다.

그렇다면 Spring Boot 에서는 jar 에 안에 있는 각 class 와 jar 들은 어떻게 Load 하는 걸까요?

Spring Boot 는 아래와 같이 각 class 와 jar 의 파일 offset 값을 기록해 둡니다. 그리하여 필요할 때마다 해당 offset 에 있는 class 와 jar 파일을 load 할 수 있도록 구현을 해 두었습니다.

myapp.jar
+-------------------+-------------------------+
| /BOOT-INF/classes | /BOOT-INF/lib/mylib.jar |
|+-----------------+||+-----------+----------+|
||     A.class      |||  B.class  |  C.class ||
|+-----------------+||+-----------+----------+|
+-------------------+-------------------------+
 ^                    ^           ^
 0063                 3452        3980

이렇게 했을 때 장점은 jar 파일의 압축을 풀거나 모든 항목 데이터를 메모리로 읽지 않아도 필요시 바로 바로 찾아서 Load 할 수 있다는 점입니다.

반대로 단점은 jar 파일이 변경되었을 경우 jar 파일 안에 class 나 jar 파일이 존재함에도 불구하고 제가 위에서 경험한 NoClassDefFoundError 가 발생할 수 있습니다.

jar 파일이 변경되기 전에 이미 Load 된 class 나 jar 파일이면 상관이 없지만, 아직 Load 가 안된 상태에서 jar 파일이 변경된 경우 그리고 이로 인해 각 class 와 jar 파일의 offset 정보가 달라졌을 경우 jar 안에 class 나 jar 파일이 존재하더라도 class 를 찾을 수 없는 상태가 되기 때문에 NoClassDefFoundError, ClassNotFoundException 이 발생하게 됩니다.

제가 맞딱뜨렸던 Error 상황은 배포 시나리오가 잘못되어 빌드된 jar 파일을 application 종료 전에 먼저 배포하게 되었고
종료시그널을 받았을 때 처음으로 Load 된 GracefulShutdownResult class 로 인해 위와 같은 현상이 발생하게 된 것이었습니다.
현재 해당 현상을 해결할 수 있는 방법은 jar 파일을 교체하기 전에 반드시 Application 을 종료하는 방법밖에 없는것으로 알고 있습니다.
(만약에 다른 방법이 있다면 알려주세요!)

Reference

Spring Boot Document - executable jar

Spring Rest Docs 로 Swagger API 문서 관리 자동화

흥부가귀막혀 — Fri, 26 Aug 2022 15:31:41 +0900

Spring Rest Docs 란? Spring REST Docs 는 RESTful 서비스의 문서화를 도와주는 도구이다.
문서 작성 도구로 Asciidoctor 를 기본적으로 사용하며, 이것을 통해 HTML 문서를 생성한다. 필요한 경우 Markdown 문법을 사용하도록 변경할 수 있다.
RESTful API를 문서화 할때 중요한 포인트는 API 에서 필요한 HTTP 요청과 응답의 리소스를 설명하는 것인데 Spring REST Docs 를 사용할 경우 테스트 코드를 작성하여 이러한 리소스와 HTTP 요청/응답에 대한 세부 내용을 문서화하는데 편리한 기능을 제공한다.

Swagger 란?
RESTful API 를 약속된 규칙에 따라 json 이나 yaml 형식으로 문서화한 Open API Specification(OAS) 라는게 있는데 이 문서를 관리하기위한 목적으로 만들어진 프레임워크다.
API 문서 자동화 도구로 Spring REST Docs 의 비교군으로 자주 등장하는데 Spring 을 사용할 경우 서비스 코드에 어노테이션만 추가하면 멋진 API 문서 하나가 뚝딱 만들어지는 신기한 도구다.
게다가 실제로 API 를 요청해 볼 수 있는 기능도 있기 때문에 API 를 어떻게 요청하고 어떤 응답을 내려주는지도 테스트가 가능하다.

이걸 하게 된 이유?
- wiki 페이지를 통해 개발한 API 문서를 정리하고 타 부서에 공유하였는데 변경사항이 발생할때마다 관리가 힘들고 잘못 작성되거나 변경사항이 반영되지 않아 커뮤니케이션 비용이 많이 발생하였다.
- Swagger 를 통해 API 문서를 제공해보니 API 에 대한 테스트도 할 수 있고 코드가 변경될때 같이 변경할 수 있는 장점이 있으나 실제 코드에 API 문서를 작성하기 위한 코드를 같이 작성해야했고 검증되지 않은(정상작동하지 않는) API 가 노출될 수 있었다.
- Spring Rest Docs 를 써보니 테스트 코드를 통해 API 문서를 작성할 수 있어 검증된 API 만 문서를 만들수 있고 실제 코드는 API 문서에 관련된 코드를 작성하지 않아서 좋았지만 Swagger 에서 제공해주는 API 호출 기능이 없어서 아쉬웠다.(개인적인 생각이지만 UI 도 Swagger 가 더 좋다고 느꼈다)
- 좀 더 좋은 방법이 없을까를 찾던 중 링크로 걸어둔 내용을 보게 되었고 팀 프로젝트 상황에 맞게 커스터마이징 하여 적용해 보았다.

좋았던 점
- 테스트 코드를 통해 어느정도 검증된 API 가 문서에 반영될 수 있다는 점(+ 이를 Swagger 로 실행해 볼 수 있다는 점).
- API에 변경이 발생하면 자연스럽게 테스트 코드도 변경이 필요하게되고 이로 인해 API 문서 변경도 자연스럽게 발생한다는 점.(단, API 문서까지 자연스럽게 변경되려면 빌드/배포 구조까지 잘 잡혀져야 한다)
- Swagger 특성상 여러 API 문서들을 같이 관리할 수 있어 통합 API 문서를 구축할 수 있다. 이를 통해 각 컴포넌트 별로 Swagger URL 이 따로 있지 않아도 되어 타 부서에 공유할 때 편했다.(wiki 로 치면 API 문서 부모 페이지 하나만 공유하면 되는것과 동일)

아쉬운 점
- Spring Rest Docs 를 쓰기 때문에 어쩔수 없는 한계인가 싶긴 하지만 테스트 코드 작성시 API 문서를 작성하기 위한 테스트 코드를 추가로 작성해야 한다.
- 여러가지 검증을 위한 테스트 코드를 작성하다보면 API 문서에 영향을 줄 수 있기 때문에 이에 대한 고려를 하면서 테스트 코드를 작성해야 한다.(가끔은 주객전도가 된듯한 느낌도 받는다)
- 가끔씩 타 부서에서 미리 코드를 작성할 수 있게 API Interface 공유가 불가능하냐는 문의가 들어오면 답이 없다.(이럴땐 어쩔수 없이 우리쪽 API 설계 문서를 공유해주곤 한다)

Reference
- Swagger: https://swagger.io/docs/open-source-tools/swagger-ui/usage/installation/
- Spring Rest Docs: https://docs.spring.io/spring-restdocs/docs/current/reference/html5/
- Rest Docs API specification Integration: https://github.com/ePages-de/restdocs-api-spec
- Restdocs Spec Generation Support: https://github.com/BerkleyTechnologyServices/restdocs-spec

GitHub - BerkleyTechnologyServices/restdocs-spec: A maven plugin for generating Open API and Postman Collection specifications u

A maven plugin for generating Open API and Postman Collection specifications using Spring Restdocs. - GitHub - BerkleyTechnologyServices/restdocs-spec: A maven plugin for generating Open API and Po...

github.com

- [NHN Forward 2020] MSA 환경에서 API 문서 관리하기: 생성부터 배포까지: https://www.youtube.com/watch?v=qguXHW0s8RY

Kafka 와 Zookeeper 의 헤어질 결심. 그 결말은??

흥부가귀막혀 — Fri, 26 Aug 2022 15:28:16 +0900

Kafka 와 Zookeeper 의 관계?
떼려야 뗄 수 없는 관계다.
Kafka 는 Zookeeper 를 통해 필요한 Metadata 를 안전하게 저장하고 Cluster 운영을 위한 리더 및 파티션 오너를 선출하고 있다.
이러한 관계로 Kafka 를 운영하기 위해서는 반드시 Zookeeper 가 구축되어야 하고 운영단계에서는 Kafka 가 사용하는 Zookeeper 를 다른 솔루션과 함께 사용하지 말라고 권장하고 있다.

Kafka 는 왜 Zookeeper 와 헤어지려고 하는가?
다음과 같은 몇가지 이유가 있다.

1️⃣ Kafka 를 쓰려면 Zookeeper 도 같이 알아야 한다.
- 처음 Kafka 를 배우는 입장에서는 동시에 2가지의 솔루션을 배워야 한다는 것에 진입장벽을 느낄 수 있다.
- 서로 다른 두개의 분산 시스템을 같이 운영하고 관리 및 배포를 할 수 있도록 학습이 되고 준비가 되어야 하는데 이는 처음 진입하는 사람 입장에서는 부담스러울 수 있고 학습 비용 및 구축에 시간이 들 수 있다.

2️⃣ 보안 설정시 Zookeeper 도 같이 설정해줘야 한다.
- 1번 내용과 비슷한 맥락이지만 완벽하게 Kafka Cluster 에 대한 보안 설정을 적용하려면 Zookeeper 까지 같이 해줘야 한다.
- 만약 이러한 부분을 놓쳐서 Kafka 만 진행했을 경우 보안에 이슈가 발생할 가능성이 있다.

3️⃣ Zookeeper 를 운영하는 서버 리소스가 아깝다.
- 안전하게 운영하길 원한다면 Zookeeper 를 최소 5대 이상 구축할것을 권장하고 있다. 만약 이렇게 구축한 Zookeeper 노드를 모두 Kafka 로 바꿀 수 있다면 Kafka Cluster 에서 운영할 수 있는 토픽이나 파티션수가 증가하게 된다.
- 간단하게 테스트 목적으로 Single 노드를 구축 하고싶어도 Zookeeper 가 기본적으로 구축 되어야 하므로 이에 대한 리소스 낭비나 비효율적인 구조가 발생한다.

4️⃣ Kafka 와 Zookeeper 간의 데이터 불일치가 발생한다.
- 이게 아마 가장 큰 이유이지 않을까 싶은데, 몇가지 Metadata 는 Zookeeper 에 기록하지만 Kafka 에서도 메모리에 기록하는데 이때 Kafka 와 Zookeeper 간에 데이터 불일치가 발생하면 운영에 크리티컬한 이슈가 발생한다.
- 이러한 이슈를 피하기 위해 Zookeeper 의 znode 를 매번 탐색하도록 하는것도 비효율적이고 상태 변경이나 전파가 오래걸리거나 중간에 유실될 수 있다.

Kafka 는 Zookeeper 와 어떻게 헤어지려고 하는가?
https://careerly.co.kr/comments/64092?utm_campaign=self-share 에서도 언급했던 Raft 라는 알고리즘으로 새롭게 분산 시스템 운영에 필요한 리더 선출이나 이벤트 전파등을 만들려고 시도하고 있다.
즉, 기존에 Zookeeper 를 통해 사용하던 ZAB 알고리즘을 Raft 알고리즘으로 바꾸는거라 생각하면 된다.
최소 3대 이상의 쿼럼 노드가 있고 이중에 컨트롤러와 Metadata 복제 및 컨트롤러 상태를 체크하는 팔로워 노드를 둔다.
쿼럼 노드들은 Raft 알고리즘으로 구현한 이벤트 전파 및 Metadata 복제, 리더 선출등을 하게 된다.
Zookeeper 와 마찬가지로 쿼럼 노드가 많으면 많을수록 장애에 대한 복구 가능성이 커진다.
변경되는 항목중에 알고리즘 외에 흥미로웠던 부분은 기존에는 Metadata 에 대한 변경이 발생하면 컨트롤러 노드가 나머지 노드들에게 변경사항을 Push 하는 구조였는데 이게 Poll 형태로 바뀐다는 점이다.

결말은?
2019년 7월에 이 제안이 나왔고 그로부터 2년뒤인 2021년 4월에 2.8 버전으로 얼리 엑세스 빌드가 릴리즈 되었다.
현재 3.2 버전까지 출시가 되었지만 아직까지 운영(Production)단계에서 Zookeeper 를 사용하는것을 권장하고 있다.
개인적으로 Zookeeper 제외에 대한 안정화된 릴리즈가 나오기를 바라고 있지만 실제로는 더 오래걸릴것 같다는 생각이 든다.
그 이유로 분산 시스템의 핵심이나 다름없는 리더 선출이나 이벤트 전파 및 Metadata 관리 알고리즘을 바꾼다는게 생각보다 쉬운일이 아니다. 더군다나 Zookeeper 에서 사용하는 ZAB 알고리즘이 아닌 Raft 알고리즘으로 바꾸는 것이니 그 간극은 더 클 수 밖에 없다.
또한 오픈소스 특성상 많은 사람들이 써보고 경험한 다양한 이슈를 올려줘야 이를 패치하고 안정화가 진행될 수 있는데 Zookeeper 제외 모드를 운영환경에서 쓰는 사용자가 많지 않은것도 한몫 하지 않을까 싶다. 사실 이런건 Kafka 가 어느정도 안정된 상태였을때 개선하지 말고 초반(1.0 버전 전이었을때)에 했어야 하지 않았나 싶다.
이 로맨스(?)의 결론이 어떻게 날지 귀추가 주목된다.

# Reference

- https://cwiki.apache.org/confluence/plugins/servlet/mobile?contentId=123898922#content/view/123898922

Java 유료화와 OpenJDK 의 오해와 진실

흥부가귀막혀 — Fri, 26 Aug 2022 15:22:20 +0900

Programming 언어가 유료화가 된다고?
프로젝트를 Java 언어로 진행하고 있거나 이미 운영중인 사람들 입장에서는 처음 Java 유료화 라는 말을 들었을 때 헉! 할수밖에 없을 것이다. 그만큼 Java 는 인기있는 언어이고 대체하기 위해서는 많은 리소스를 투자할 수 밖에 없다.

결론부터 얘기하자면 Java 라는 프로그래밍 언어 자체는 GPL 라이센스로 무료이다.
그럼 도대체 어떤것이 유료화가 된다는 말일까?

Java 프로그램을 실행하기 위해서는 아래의 2가지 핵심 기능이 필요하다
- Java 로 작성한 프로그램을 컴파일 해주는 JDK
- 컴파일된 결과물을 실행시켜주는 JVM

JDK 에 JVM 이 같이 패키징되어 배포되는 구조라 흔히들 JDK, JVM 을 합쳐 JDK 라 부르는데 이 JDK 가 유료화 되는것이다.
즉, 프로그래밍 언어로써 Java 를 사용하는건 무료이지만 이를 실행시키기위한 컴파일과 실행 머신이 유료라는 것이다.

JDK 는 크게 OracleJDK 와 OpenJDK 로 나뉘어지는데 이중 OracleJDK 가 유료화 정책을 펼치고 있다.

OracleJDK 쓰면 무조건 돈내야해요?
OracleJDK는 BCL(Oracle Binary Code License) 이라는 라이센스를 적용하고 있는데 BCL 라이센스에서는 일반적인 목적의 컴퓨팅(General Purpose Computing)에 사용시에만 무료라고 밝히고 있다.
여기서 말하는 일반적인 목적의 컴퓨팅이란 데스크탑, 노트북, 스마트폰, 태플릿 등에서의 사용인 것인데 즉, 개인이 학습이나 테스트 목적으로 개인의 디바이스에 사용하는건 문제가 없다는 말이다.

반대로 특정 기능만을 위해 작동하는 시스템 및 솔루션에서 사용하는것은 일반적이지 않은 목적의 컴퓨팅이라 규정하고 있는데 이 표현이 모호하여 대부분의 상업 프로젝트를 진행하는 회사의 경우 라이센스 비용을 지불한다고 생각하는게 좋다.

그렇지만 모든 OracleJDK 가 유료인것은 아니고 2019년 01월 15일에 공개된 JDK 8u202 버전까지는 무료로 제공해주고 있다.

OpenJDK 는 유료화 안되나요?
OpenJDK 는 JDK(Java SE) 의 오픈소스 구현체로 GPL v2 with the Classpath Exception 라이센스가 적용되어 무료이다.
많은 상업 벤더들이 구현체 개발에 참여하여 다양한 종류의 OpenJDK 가 존재하고 무료로 배포되고 있다.

OpenJDK 는 OracleJDK 보다 성능이 떨어진다?
Jave SE 6 버전의 OpenJDK는 백포트 방식으로 구현되어 성능 저하 이슈가 존재했었다. 이로인해 OpenJDK 가 OracleJDK 에 비해 성능이 떨어질것이라는 인식이 생겼는데 Java SE 7부터 모든 JDK는 OpenJDK 레퍼런스 소스 코드를 기반으로 제작되도록 변경되어 두 JDK 간에 성능차이가 거의 없어졌다.
또한 오라클이 아닌 서드파티 업체가 OpenJDK를 기반으로 공인된 JDK를 제작하여 배포하려면 오라클의 엄격한 TCK 인증을 통과해야 한다. 수만가지의 테스트를 단 하나라도 통과하지 못하면 인증되지 않는다. 이러한 프로세스로 인해 OpenJDK 가 OracleJDK 보다 이슈나 트러블이 발생할 일은 없어졌다.

그러면 무조건 OpenJDK 쓰면 되는거 아닌가요?
일반적인 서버 어플리케이션이나 오픈소스 솔루션은 OpenJDK 로 운영이 가능하기 때문에 굳이 OracleJDK 를 쓸 필요는 없다.
하지만 글꼴 라이브러리나 Java Web Start 와 같이 Oracle이 재산권을 보유하고 있는 플러그인 기능을 써야하는 경우 OpenJDK 에는 해당 플러그인이 제공되지 않기 때문에 쓸 수 없다.

마무리
이 논란이 발생한건 꽤 오래전 일이지만 아직도 자세히 알지 못하는 사람들이 있는것 같아 자세히 정리된 블로그를 참고하여 정리해보았다.
이 논란이 한창 진행될때는 JDK 를 유료화하는 오라클을 단순히 미워(?)했지만 지금 생각해보면 OracleJDK 를 통해 수익구조를 만들었지만 동시에 OpenJDK 에 대한 운영도 주체가 되어 공존시킴으로써 Java 의 발전을 크게 위협하지 않는 선에서 나름 똑똑하게 수익구조를 만든것같다는 생각이 든다.
이런 똑똑한 전략이 있었기에 오늘날에도 Java 가 인기있는 언어로 손꼽히는게 아닐까 싶다.

LinkedIn 의 brooklin 활용

흥부가귀막혀 — Fri, 26 Aug 2022 15:20:28 +0900

최근에 흥미로웠던 LinkedIn 에서 Brooklin 을 활용한 Mirror Maker 를 소개하고자 한다.

현재 Kafka Cluster 간 Message 를 Mirroring 하는 방법은 다양하다. 대표적으로 Mirror Maker 라는 오픈소스가 있고(이건 v2 가 release 되었다), Kafka Connector 나 오늘 소개할 Brooklin, 그리고 직접 Consumer 와 Producer 를 구현해서 만들수도 있다.
필자가 Kafka Mirroring 과 관련된 모든 오픈소스를 확인해본건 아니지만, 적어도 위에서 언급한 방법들에 대해서만 한정하자면 모두 공통적으로 Source Cluster 에서 message 를 Consuming 하고, 이를 Target Cluster 로 Publish 하는 방식을 기본으로 한다.
그래서 사실 어떤 오픈 소스를 쓰거나 혹은 직접 구현하는게 크게 특별한 차이가 존재하지 않을거라 생각했는데 Linkedin 의 Brooklin 활용 방식을 보고 내 생각이 짧았음을 느끼게 되었다.
LinkedIn 의 Brooklin 활용 방식을 통해 인상깊게 느꼈던 부분은 다음과 같다.

1. Kafka 에서 제공하는 Metric 을 자동화 시스템을 위한 지표로 활용한 점.
Kafka 에서 제공하는 JMX metric 중에는 Topic 의 Partition 단위로 traffic 이 얼마나 되는지 볼 수 있는 metric 이 있는데 LinkedIn 에서는 이 metric 을 활용하여 Mirroring 노드가 받을 트래픽을 계산하고 이를 기반으로 노드별 트래픽이 분산되도록 자동화 시스템을 구축했다.
필자는 이 Metric 을 단순히 Kafka 가 받고 있는 Traffic 이 어느정도인지 모니터링 하는 용도로 사용할 생각만 했지 이를 자동화 시스템을 구현하기 위한 지표로 활용할 생각은 전혀 못했다.

2. 자신들의 목표를 위해 Kafka 가 제공해주는 기능을 활용하지 않은 점.
Kafka 가 제공해주는 기능중에 Consumer 의 Partition Ownership 을 각 Consumer 에 적절히 분산시켜주는 기능이 있는데 LinkedIn 은 이를 사용하지 않았다.
그 이유는 Kafka 가 Consumer 의 Partition Ownership 을 분배하는 방식은 단순히 Partition 갯수를 기반으로 균등하게 분배하는 방식이기 때문에 파티션별 트래픽이 달라질 경우 이를 컨트롤 할 수 없다. 즉, 경우에 따라 특정 노드는 열심히 일하고 특정 노드는 놀게되는 현상이 발생하게 된다.
그래서 LinkedIn 에서는 Brooklin 에서 Mirroring 을 위한 Datastream(흔히들 얘기하는 Job 과 비슷한 개념으로 생각하면 된다.) 을 정의할 때 Consumer 가 특정한 partition 만 assign 하도록 설정한다. 즉, Kafka 가 자동으로 Partition 을 지정해주는게 아닌 LinkedIn 에서 직접 자신들이 원하는 Partition 에 assign 하도록 로직을 구현한 것이다.
Kafka 의 Partition Ownership 분배가 얼마나 강력한 기능인지는 Kafka 를 사용해본 사람이라면 누구나 알것이다. 그런데 LinkedIn 은 자신들이 목표한 Mirroring 기능을 위해 이 기능을 포기하고 본인들이 직접 Control 하도록 변경한것이다.
당연하게 사용해야될 기능인줄 알았는데 이렇게 변화를 줄 수도 있다는 사실이 필자에겐 꽤나 충격적이고 신선했다.

3. 이런 구현이 가능하도록 Brooklin 을 설계했다.
Brooklin 을 만든 목적이 이 글에서 소개한 자동화된 mirroring 을 구현하기 위한건지, 아니면 만들다보니 이렇게 활용할 수 있게 된건지는 정확하게 모르겠지만 한가지 분명한건 LinkedIn 에서 활용한 방식을 비슷하게 해볼려면 필자가 알고있는 방법중에는 Brooklin 을 쓰는게 가장 적절해 보인다는 점이다. 현재 필자가 업무를 하고 있는 팀에서도 Mirroring 을 구현할 방안으로 Brooklin 을 활용할지 검토중이다.

이밖에 OLAP 데이터 저장소로 Apache Pinot 과 Samza 를 통한 스트리밍 처리도 흥미로운 주제이지만 이 내용은 다음에 기회가 되면 정리해볼까 한다.(Samza 대신 Kafka Streams 를 써도 되지 않았을까 하는 생각이 든다)

# Reference

- https://engineering.linkedin.com/blog/2022/load-balanced-brooklin-mirror-maker--replicating-large-scale-kaf

Java 의 Project Loom 이 만들어지고 있어요! 조금만 기다려주세요!

흥부가귀막혀 — Fri, 26 Aug 2022 15:18:01 +0900

Project Loom 이란?

Project Loom 은 Java 의 동시성 처리 개선을 위해 Ron Pressler(Quasar 라는 Java 경량 스레드 라이브러리 개발자)가 제안하여 2017년에 시작된 프로젝트다.
최근에 완성도 높은 형태의 얼리 엑세스 빌드가 제공되어 올해 정식 릴리즈가 되지 않을까 하는 기대감이 생겼다.

Project Loom 의 동기

하나의 서버에서 수백만개의 소켓을 다룰 수 있지만, OS 스레드를 직접 사용하는 Java 에서는 동시에 수천개 이상의 요청을 효율적으로 다루기 어렵다. 즉, 현재 Java 의 스레드는 자원 사용면에서 효율적이지 못하다.
비동기 관련 API 들이 나왔지만 사용하기 어렵고 디버깅이 쉽지 않아 유지보수에 좋지 않다.

Project Loom 의 목표

동기 코드를 작성하듯이 사용하기 쉽고 비동기 코드처럼 서버 자원을 효율적으로 사용할 수 있어야 한다.
이를 위해 수백만개를 생성할 수 있는 경량 스레드를 정의하여 기존의 동기 코드처럼 작성해도 비용(서버 자원)이 적게 들어가도록 한다.

Project Loom 이 해결한 것

제어 흐름을 잃는 문제. 비동기 프로그래밍을 하게 되면 조건 분기나 반복문 같은 간단한 제어 흐름을 복잡하게 구성해야하는 경우가 생기고 이로 인해 콜백 헬이나 부가적인 코드가 많이 발생하게 되는데 Project Loom 은 코드를 동기식으로 짤 수 있게 만들었기 때문에 이런 문제가 발생하지 않는다.
컨텍스트를 잃는 문제. 비동기 프로그래밍에서는 스레드를 넘나들며 요청이 처리되기 때문에 거쳐온 컨텍스트가 스택 트레이스에 쌓이지 않게 되고 이로 인해 스택 트레이스가 유용하지 않게 되버린다. 하지만 Project Loom 은 스레드를 넘나드는게 아닌 경량 스레드를 실행하는 구조이기 때문에 이 문제가 없어진다.
함수의 색 문제. https://careerly.co.kr/comments/63069?utm_campaign=self-share 에서도 언급했던 내용인 전염성 혹은 함수의 색문제로 인해 동기/비동기 함수간에 연동이 쉽지 않고 개발단계와 유지보수에 영향을 미치게 된다. Project Loom 은 블록킹 코드로 작성되고 내부적으로 논블록킹으로 동작하기 때문에 동기/비동기 코드간에 벽이 허물어진다.

Project Loom 이 해결하지 못한 것

비록 낮은 수준이지만 동기화 요소를 직접 다루는 컨셉이기 때문에 기존에 나와있는 비동기 처리 솔루션들의 장점인 우아하고 자연스러운 동시성 처리를 하는것에는 한계가 있어 보인다.

Project Loom 이 가져올 변화와 기대되는 점

Tomcat 과 같은 Servlet 기반 웹서버의 성능이 눈에 띄게 향상될 것이고 이에 대한 사용도 늘어날 것으로 기대.
Spring Webflux 사용이 줄어들 수 있을 것 같지만 Spring 에서 Project Loom 으로 어떤 멋진걸 만들지도 기대된다.
코틀린 코루틴 대신 Project Loom 을 활용하는 케이스가 많아질 것 같다.
Akka 와 같은 기존 Java Thread 의 한계를 극복하기 위해 나왔던 솔루션들이 Project Loom 을 어떻게 수용하고 변화할지 기대된다.
Java Thread 의 한계로 다른 솔루션(Go 나 NodeJS)으로 건너간 개발자들이 다시 돌아올 수 있을지, Java 가 지금보다 더 크게 활성화 될 수 있을지 기대된다.

Reference

https://cr.openjdk.java.net/~rpressler/loom/Loom-Proposal.html

[VictoriaMetrics] Metric 수집(Direct Push)

흥부가귀막혀 — Wed, 16 Mar 2022 17:02:48 +0900

InfluxDB Line Protocol

기본적으로 VictoriaMetrics 를 실행하면 8428 포트로 운영이 되고, 해당 포트에 InfluxDB Line Protocol 형식으로 data 요청이 가능하다.
만약 InfluxDB Line Protocol 을 받을 포트를 변경하고 싶다면, -influxListenAddr 옵션을 통해 변경할 수 있다.

/path/to/victoria-metrics-prod -influxListenAddr=:8428

VictoriaMetrics 는 InfluxDB Data 를 받으면 이를 Prometheus 데이터 포인트로 변환을 한다.
아래와 같은 InfluxDB Data 를 보낸다고 가정하면

foo,tag1=value1,tag2=value2 field1=12,field2=40

VictoriaMetrics 에는 아래의 형태로 변환이 된다.

foo_field1{tag1="value1", tag2="value2"} 12
foo_field2{tag1="value1", tag2="value2"} 40

HTTP Protocol 통신을 통해 InfluxDB Data 를 전송할 수 있다.
요청시 '\n'(개행 문자라고도 함)으로 구분된 임의의 수의 행을 보낼 수 있다.

curl -d 'measurement,tag1=value1,tag2=value2 field1=123,field2=1.23' -X POST 'http://localhost:8428/write'

데이터가 전송된 이후에, /api/v1/export을 통해 확인할 수도 있다.

curl -G 'http://localhost:8428/api/v1/export' -d 'match={__name__=~"measurement_.*"}'

{"metric":{"__name__":"measurement_field1","tag1":"value1","tag2":"value2"},"values":[123],"timestamps":[1560272508147]}
{"metric":{"__name__":"measurement_field2","tag1":"value1","tag2":"value2"},"values":[1.23],"timestamps":[1560272508147]}

InfluxDB 라인 프로토콜은 기본적으로 나노초 단위의 타임스탬프를 정의하지만, VictoriaMetrics는 밀리초 단위로 저장한다.
extra_label=name=value 쿼리 파라미터를 전달하여 작성된 모든 시계열에 레이블을 추가할 수 있다. 예를 들어 수집된 모든 측정항목에 {foo="bar"} 레이블을 추가하고자 한다면, /write?extra_label=foo=bar 로 요청한다.
Reference: How to send data from influxdb-compatible agents such as telegraf

Graphite

VictoriaMetrics 실행 시 graphite metric을 수집할 포트를 정의한다.

/path/to/victoria-metrics-prod -graphiteListenAddr=:2003

메트릭을 graphite 형식에 맞추어 전송한다. 여러 메트릭이 필요한 경우, \n으로 개행한다. timestamp가 없는 경우, 현재 시간이 자동으로 삽입된다.

echo "foo.bar.baz;tag1=value1;tag2=value2 123 `date +%s`" | nc -N localhost 2003

데이터가 전송된 이후에, /api/v1/export을 통해 확인할 수도 있다.

curl -G 'http://localhost:8428/api/v1/export' -d 'match=foo.bar.baz'

{"metric":{"__name__":"foo.bar.baz","tag1":"value1","tag2":"value2"},"values":[123],"timestamps":[1560277406000]}

Reference: How to send data from Graphite-compatible agents such as StatsD

OpenTSDB 호환 방식(OpenTSDB Agent 호환)

openTSDB metric을 수집할 HTTP포트를 열어준다.

/path/to/victoria-metrics-prod -opentsdbListenAddr=:4242

OpenTSDB 호환 에이전트에서 지정된 주소로 데이터를 보낸다.
\n(개행 문자라고도 함) 으로 구분된 임의의 수의 행을 한번에 보낼 수 있다.
아래는 nc command 를 사용하여 로컬 VictoriaMetrics에 OpenTSDB 프로토콜로 데이터를 쓰는 예.

echo "put foo.bar.baz `date +%s` 123 tag1=value1 tag2=value2" | nc -N localhost 4242

데이터가 전송된 이후에, /api/v1/export을 통해 확인할 수도 있다.

curl -G 'http://localhost:8428/api/v1/export' -d 'match=foo.bar.baz'

{"metric":{"__name__":"foo.bar.baz","tag1":"value1","tag2":"value2"},"values":[123],"timestamps":[1560277292000]}

Reference: How to send data from OpenTSDB-compatible agents

OpenTSDB 호환 방식(HTTP 통신)

openTSDB metric을 수집할 HTTP포트를 열어준다.

/path/to/victoria-metrics-prod -opentsdbHTTPListenAddr=:4242

다음 처럼 json 형대의 메트릭을 /api/put으로 전송한다.

curl -H 'Content-Type: application/json' -d '{"metric":"x.y.z","value":45.34,"tags":{"t1":"v1","t2":"v2"}}' http://localhost:4242/api/put

여러 메트릭을 보내는 형식은 다음과 같다.

curl -H 'Content-Type: application/json' -d '[{"metric":"foo","value":45.34},{"metric":"bar","value":43}]' http://localhost:4242/api/put

데이터가 전송된 이후에, /api/v1/export을 통해 확인할 수도 있다.

curl -G 'http://localhost:8428/api/v1/export' -d 'match[]=x.y.z' -d 'match[]=foo' -d 'match[]=bar'

{"metric":{"__name__":"foo"},"values":[45.34],"timestamps":[1566464846000]}
{"metric":{"__name__":"bar"},"values":[43],"timestamps":[1566464846000]}
{"metric":{"__name__":"x.y.z","t1":"v1","t2":"v2"},"values":[45.34],"timestamps":[1566464763000]}

Reference: Sending OpenTSDB data via HTTP /api/put requests

[VictoriaMetrics] Overview

흥부가귀막혀 — Wed, 16 Mar 2022 15:14:33 +0900

개요

Go-fasthttp 개발자가 만든 Prometheus 호환 TSDB

특징

PromQL 을 하위호환하는 MetricsQL 지원
InfluxDB, Graphite, Prometheus 등 다양한 Metric Input 지원
간단한 아키텍쳐
Gorilla Compression 을 통한 효율적인 storage 활용
Line Use Case 존재

설계 철학

KISS(Keep It Simple, Stupid)
단순한 아키텍쳐 지향 - shared nothing
외부 의존성 최소화
최소한의 자동화

지원하지 않는 것들

클러스터 자동 resizing
자동 노드 discovering
data rebalancing

Architecture

출처: VictoriaMetrics Github

Gorilla Compression

Facebook 에서 Time Series Data 를 효과적으로 압축하는 방법론 소개
이후 대부분의 Modern TSDB 에 적용 & 응용되고 있음

Timestamp Compression

timestamp 는 대부분 일정한 간격으로 수집 된다.
간격(delta)이 일정하다(delta of delta = 0)면 그냥 1bit flag 하나만으로 다음 timestamp 값을 표현 가능하다.

Value Compression

이진수 표현 시 이전 값과 현재 값의 대부분의 bit 는 동일 -> XOR 연산 시 '0'
XOR 연산으로 '0' 으로 바뀐 bit 들은 압축시켜서 표현

Compression Summary

Timestamp: 96.39%. 1bit 만으로 시간 표현 가능.
Value: 59.06%. 1bit 만으로 값 표현 가능.
압축률: 16 bytes를 1.37 bytes 로 줄임 (약 12배 향상)
Query 속도: 경우에 따라 최대 73 ~ 350배 향상

[Kafka] binary 설치 및 실행

흥부가귀막혀 — Tue, 15 Mar 2022 15:12:53 +0900

1. Zookeeper 구축

1) Zookeeper 설치

https://archive.apache.org/dist/zookeeper/ 경로에서 원하는 버전의 zookeeper 를 다운받는다.
다운받은 zookeeper 압축파일을 원하는 경로에 해제한다.

2) Zookeeper 설정

zookeeper configuration 을 참고하여 zookeeper 설정 파일을 정의한다.
cluster 로 구축해야하므로 설정파일에 zookeeper 로 구축할 각 서버정보를 아래와 같이 정의한다.

server.{zookeeper-1.serverId}={zookeeper-host1}:{follower-port}:{leader-election-port}
server.{zookeeper-2.serverId}={zookeeper-host2}:{follower-port}:{leader-election-port}
server.{zookeeper-3.serverId}={zookeeper-host3}:{follower-port}:{leader-election-port}

** follower-port 와 leader-election-port 는 kafka 에서 쓰는게 아닌 zookeeper 내부 통신용이므로 보통 kafka 가 접근하는 port 설정인 clientPort 설정과 다르게 해주어야 합니다.
** serverId 는 각 zookeeper 서버에 정의해주어야 하는 ID 값이므로 숫자로 중복되지 않게 정의해줍니다.

각 zookeeper 서버에 위 설정파일에서 정의한 dataDir 경로 하위에 myid 라는 파일명으로 serverId 값을 기록합니다.(예시에서는 $HOME/data/zookeeper 경로를 dataDir 로 정의)

** example(serverId 를 1로 설정한 zookeeper 노드)

$ pwd
$HOME/data/zookeeper
$ ll
-rw-rw-r-- 1 user user    1 Sep 25  2019 myid
$ cat myid 
1

zookeeper 설정 파일이 있는 경로에 필요한 JVM 환경변수를 정의한 파일이나, log4j.properties 파일을 같이 정의하고 zookeeper 설정 파일이 있는 경로를 ZOOCFGDIR 명으로 환경변수를 설정한다.

** ZOOCFGDIR 환경변수 설정은 설치한 zookeeper 의 conf 디렉토리 하위에 설정파일을 두었다면 하지 않아도 된다.(경로를 변경해야할때 정의한다.)
** JVM 환경변수로 설정해야할 내용은 설치한 zookeeper의 bin 디렉토리 하위에 있는 zkEnv.sh 내용을 참고해서 필요한 사항들을 정의한다.

3) Zookeeper 실행

설치한 zookeeper 의 bin 디렉토리 하위에 있는 zkServer.sh 를 아래와 같이 실행한다.

[irteamsu@dev-ncs-wmgq-de1-005-ncl bin]$ ./zkServer.sh start {zoo-conf filename}

** {zoo-conf filename} 은 설정파일을 zoo.cfg 로 했을경우 정의하지 않아도 된다. 파일명이 zoo.cfg 가 아닐경우에만 정의한다.

4) Zookeeper 종료

설치한 zookeeper 의 bin 디렉토리 하위에 있는 zkServer.sh 를 아래와 같이 실행한다.

[irteamsu@dev-ncs-wmgq-de1-005-ncl bin]$ ./zkServer.sh stop {zoo-conf filename}

** {zoo-conf filename} 은 설정파일을 zoo.cfg 로 했을경우 정의하지 않아도 된다. 파일명이 zoo.cfg 가 아닐경우에만 정의한다.

2. Apache Kafka 구축

1) Kafka 설치

https://archive.apache.org/dist/kafka/ 에서 원하는 버전의 kafka 를 다운받는다.
다운받은 kafka 압축파일을 원하는 경로에 해제한다.

2) Kafka 설정

kafka broker config 내용을 참고하여 properites 파일을 작성.
설정값중 zookeeper.connect 는 위에서 구축한 주키퍼 서버를 '호스트:포트' 형태로 , 로 구분하여 정의한다.
설정파일 정의시 각 broker 노드들을 구분할 수 있는 broker.id 를 숫자형태로 각 서버마다 고유하게 정의한다.
kafka 실행시 아래의 JVM 환경 변수들을 셋팅하여 적용할 수 있다.
- KAFKA_JMX_OPTS : jmx 관련 설정 정의(단, jmx port 를 해당 환경변수로 설정하고자 한다면, JMX_PORT 환경변수는 설정하지 않는다.)
- JMX_PORT : jmx port 정의(단, KAFKA_JMX_OPTS 에서 -Dcom.sun.management.jmxremote.port 를 정의했을 경우 설정하지 말아야 한다.)
- KAFKA_LOG4J_OPTS : kafka log4j 설정 관련 정의
- LOG_DIR : kafka log 경로 정의
- JAVA_HOME : java home path 정의
- KAFKA_HEAP_OPTS : kafka heap 설정 정의
- KAFKA_JVM_PERFORMANCE_OPTS : kafka jvm 옵션 관련 설정 정의

3) Kafka 실행

설치한 kafka 의 bin 하위에 있는 kafka-server-start.sh 를 실행한다.
백그라운드 프로세스로 실행하기 위해서는 -deamon 설정을 추가한다.
설정파일 경로를 파라미터로 추가한다.
만약 설정파일에 정의한 내용을 override 할 설정이 있다면 --override property=value 형태의 옵션을 추가한다.

$ ./kafka-server-start.sh -deamon $CONFIG_DIR/kafka/kafka.properties

4) Kafka 종료

설치한 kafka 의 bin 하위에 있는 kafka-server-stop.sh 를 실행한다.
종료시 특별히 필요한 파라미터는 없다.

$ ./kafka-server-stop.sh

[Kafka] Consumer Group Offset Reset

흥부가귀막혀 — Tue, 15 Mar 2022 14:56:37 +0900

필요한 상황

Consumer 에 이슈가 발생해서 특정 시점으로 offset 을 돌려서 다시 읽고 싶어요.
지금까지 읽었던 메세지를 다시 읽게 하고 싶을 경우?

사전 확인 사항

- offset 을 어디까지로 reset 할지 확인

특정 offset 으로 reset 을 하고 싶다면 Consumer 에서 남긴 로그를 통해 각 파티션별 reset 하고자 하는 offset 값을 알아야 한다.
특정 시점으로 reset 을 하고 싶다면 reset 하고자 하는 시점을 'yyyy-MM-ddTHH:mm:SS.sss' 포맷으로 정의한다.

- 경우에 따라 메세지 처리가 중복으로 발생할 수 있는데 이때 이슈가 없는지 확인한다.

이슈가 없다면 상관없지만 이슈가 있을 경우 Consumer 로직에서 중복처리를 하지 않도록 수정작업이 필요하다.

Kafka Command 수행 방법

- 신규 Consumer Group 생성 방법

offset 을 reset 하기 위해 /home1/irteam/apps/kafka/bin/kafka-consumer-groups.sh 로 --execute 요청을 하면 consumer group 이 없을경우 신규로 만들어진다.(즉, consumer group 생성을 위해 특별히 어떤 command 요청을 할 필요는 없고 offset reset command 만 실행하면 된다.)

- Consumer Group 삭제 방법

⚠️ consumer group 을 삭제하기 위해서는 해당 consumer group 상태가 inactive 여야 가능하다.

consumer group 을 삭제하고자 하는 kafka broker 장비에 접속한다.
$KAFKA_HOME/bin/kafka-consumer-groups.sh 을 아래와 같이 실행한다.

$ bin/kafka-consumer-groups.sh --bootstrap-server $KAFKA --group $CONSUMER_GROUP --topic $TOPIC --delete --execute

⚠️ Kafka Broker 에 보안설정이 되어있을 경우 --command-config 옵션을 통해 보안 관련 설정을 반드시 추가해야 한다.

특정 시점의 offset 으로 reset 할 경우

⚠️ consumer group 의 offset 을 reset 하기 위해서는 해당 consumer group 상태가 inactive 여야 가능하다. 신규로 정의되는 consumer group 일 경우 이부분은 신경쓰지 않아도 된다.

offset 을 변경하고자 하는 kafka broker 장비에 접속한다.
$KAFKA_HOME/bin/kafka-consumer-groups.sh 을 아래와 같이 실행한다.

$ bin/kafka-consumer-groups.sh --bootstrap-server $KAFKA --group $CONSUMER_GROUP --topic $TOPIC --reset-offsets --to-datetime '2020-01-01 01:00:00.001' --execute

⚠️ Kafka Broker 에 보안설정이 되어있을 경우 --command-config 옵션을 통해 보안 관련 설정을 반드시 추가해야 한다.

특정 offset 값으로 reset 할 경우

⚠️ consumer group 의 offset 을 reset 하기 위해서는 해당 consumer group 상태가 inactive 여야 가능하다. 신규로 정의되는 consumer group 일 경우 이부분은 신경쓰지 않아도 된다.

offset 을 변경하고자 하는 kafka broker 장비에 접속한다.
아래와 같이 csv 포멧으로 offset 설정 파일을 만든다.(토픽, 파티션Id, offset 값 순으로 나열한다.)

example,0,16569
example,1,15715
example,2,13281
example,3,15252
...

$KAFKA_HOME/bin/kafka-consumer-groups.sh 을 아래와 같이 실행한다.

$ bin/kafka-consumer-groups.sh --bootstrap-server $KAFKA --group $CONSUMER_GROUP --reset-offsets --from-file $CONSUMER_GROUP_offsets.csv --execute

⚠️ Kafka Broker 에 보안설정이 되어있을 경우 --command-config 옵션을 통해 보안 관련 설정을 반드시 추가해야 한다.

[Kafka] Reassign Partition 방법

흥부가귀막혀 — Tue, 15 Mar 2022 14:41:53 +0900

필요한 상황

신규 broker 장비 추가
broker 장비 이전
특정 토픽을 특정 노드에서만 운영하고 싶을 때

실행 방법

kafka bin 디렉토리 하위에 있는 kafka-reassign-partitions.sh 스크립트를 사용
이동시킬 topic 이 무엇인지 json 포맷으로 정의 예) example-to-move.json

{"topics":[{"topic": "example1"},{"topic": "example2"},{"topic": "example3"}],"version":1}

--topics-to-move-json-file 옵션으로 위에서 생성한 json 파일을 지정하고, --generate 옵션을 통해 이동시킬 broker 에 대한 파티션 설정값을 자동으로 생성

$ bin/kafka-reassign-partitions.sh --zookeeper "zookeeper-host:port,zookeeper-host:port,..." --broker-list "1,2,3" --topics-to-move-json-file example-to-move.json --generate

위 실행을 통해 Current partition replica assignment 과 Proposed partition reassignment configuration 이라는 제목으로 콘솔창에 json 내용이 출력되게 되는데 Proposed partition reassignment configuration 내용을 복사하여 파일로 만들고, Current partition replica assignment 는 혹시 롤백을 해야할 경우를 대비해 따로 복사해둔다.(해당 예시에서는 example-partitions-to-move.json 이름으로 생성)
--reassignment-json-file 옵션으로 위에서 생성한 json 파일을 지정하고, --execute 옵션을 통해 파티션을 이동시키도록 실행한다.

$ bin/kafka-reassign-partitions.sh --zookeeper "zookeeper-host:port,zookeeper-host:port,..." --reassignment-json-file example-partitions-to-move.json --execute

--verify 옵션을 통해 현재 이동 상태를 확인한다.

$ bin/kafka-reassign-partitions.sh --zookeeper "zookeeper-host:port,zookeeper-host:port,..." --reassignment-json-file example-partitions-to-move.json --verify

Status of partition reassignment: 
Reassignment of partition example1-52 completed successfully
Reassignment of partition example1-15 completed successfully
Reassignment of partition example2-4 completed successfully
Reassignment of partition example2-12 completed successfully
Reassignment of partition example3-11 completed successfully
Reassignment of partition example1-29 completed successfully
Reassignment of partition example2-40 completed successfully
Reassignment of partition example3-45 completed successfully
Reassignment of partition example3-37 completed successfully
...

참고

[Kafka] OutOfOrderSequenceException

흥부가귀막혀 — Mon, 14 Mar 2022 16:11:43 +0900

내용 정리

Kafka Broker 로그에 간혹가다 아래와 같은 ERROR 로그가 발생한다.

ERROR [ReplicaManager broker=23] Error processing append operation on partition test-8 (kafka.server.ReplicaManager)
org.apache.kafka.common.errors.OutOfOrderSequenceException: Invalid sequence number for new epoch: 3 (request epoch), 4 (seq. number)

 ERROR [ReplicaManager broker=22] Error processing append operation on partition test-55 (kafka.server.ReplicaManager)
org.apache.kafka.common.errors.UnknownProducerIdException: Found no record of producerId=557891 on the broker. It is possible that the last message with the producerId=557891 has been removed due to hitting the retention limit.

분석

message publish 요청시 호출되는 함수 순서
- kafka.server.KafkaRequestHandler.run
- kafka.server.KafkaApis.handle
- kafka.server.KafkaApis.handleProduceRequest
- kafka.server.ReplicaManager.appendRecords
위 에러는 kafka.server.ReplicaManager.appendRecords 에서 ReplicaManager 의 private 함수인 appendToLocalLog 함수를 수행하면서 발생
appendRecords 함수 내용

  /**
   * Append messages to leader replicas of the partition, and wait for them to be replicated to other replicas;
   * the callback function will be triggered either when timeout or the required acks are satisfied;
   * if the callback function itself is already synchronized on some object then pass this object to avoid deadlock.
   */
  def appendRecords(timeout: Long,
                    requiredAcks: Short,
                    internalTopicsAllowed: Boolean,
                    isFromClient: Boolean,
                    entriesPerPartition: Map[TopicPartition, MemoryRecords],
                    responseCallback: Map[TopicPartition, PartitionResponse] => Unit,
                    delayedProduceLock: Option[Lock] = None,
                    recordConversionStatsCallback: Map[TopicPartition, RecordConversionStats] => Unit = _ => ()) {
    if (isValidRequiredAcks(requiredAcks)) {
      val sTime = time.milliseconds
      val localProduceResults = appendToLocalLog(internalTopicsAllowed = internalTopicsAllowed,
        isFromClient = isFromClient, entriesPerPartition, requiredAcks)
      debug("Produce to local log in %d ms".format(time.milliseconds - sTime))

      val produceStatus = localProduceResults.map { case (topicPartition, result) =>
        topicPartition ->
                ProducePartitionStatus(
                  result.info.lastOffset + 1, // required offset
                  new PartitionResponse(result.error, result.info.firstOffset.getOrElse(-1), result.info.logAppendTime, result.info.logStartOffset)) // response status
      }

      recordConversionStatsCallback(localProduceResults.mapValues(_.info.recordConversionStats))

      if (delayedProduceRequestRequired(requiredAcks, entriesPerPartition, localProduceResults)) {
        // create delayed produce operation
        val produceMetadata = ProduceMetadata(requiredAcks, produceStatus)
        val delayedProduce = new DelayedProduce(timeout, produceMetadata, this, responseCallback, delayedProduceLock)

        // create a list of (topic, partition) pairs to use as keys for this delayed produce operation
        val producerRequestKeys = entriesPerPartition.keys.map(new TopicPartitionOperationKey(_)).toSeq

        // try to complete the request immediately, otherwise put it into the purgatory
        // this is because while the delayed produce operation is being created, new
        // requests may arrive and hence make this operation completable.
        delayedProducePurgatory.tryCompleteElseWatch(delayedProduce, producerRequestKeys)

      } else {
        // we can respond immediately
        val produceResponseStatus = produceStatus.mapValues(status => status.responseStatus)
        responseCallback(produceResponseStatus)
      }
    } else {
      // If required.acks is outside accepted range, something is wrong with the client
      // Just return an error and don't handle the request at all
      val responseStatus = entriesPerPartition.map { case (topicPartition, _) =>
        topicPartition -> new PartitionResponse(Errors.INVALID_REQUIRED_ACKS,
          LogAppendInfo.UnknownLogAppendInfo.firstOffset.getOrElse(-1), RecordBatch.NO_TIMESTAMP, LogAppendInfo.UnknownLogAppendInfo.logStartOffset)
      }
      responseCallback(responseStatus)
    }
  }

appendToLocalLog 내용

  /**
   * Append the messages to the local replica logs
   */
  private def appendToLocalLog(internalTopicsAllowed: Boolean,
                               isFromClient: Boolean,
                               entriesPerPartition: Map[TopicPartition, MemoryRecords],
                               requiredAcks: Short): Map[TopicPartition, LogAppendResult] = {
    trace(s"Append [$entriesPerPartition] to local log")
    entriesPerPartition.map { case (topicPartition, records) =>
      brokerTopicStats.topicStats(topicPartition.topic).totalProduceRequestRate.mark()
      brokerTopicStats.allTopicsStats.totalProduceRequestRate.mark()

      // reject appending to internal topics if it is not allowed
      if (Topic.isInternal(topicPartition.topic) && !internalTopicsAllowed) {
        (topicPartition, LogAppendResult(
          LogAppendInfo.UnknownLogAppendInfo,
          Some(new InvalidTopicException(s"Cannot append to internal topic ${topicPartition.topic}"))))
      } else {
        try {
          val partition = getPartitionOrException(topicPartition, expectLeader = true)
          val info = partition.appendRecordsToLeader(records, isFromClient, requiredAcks)
          val numAppendedMessages = info.numMessages

          // update stats for successfully appended bytes and messages as bytesInRate and messageInRate
          brokerTopicStats.topicStats(topicPartition.topic).bytesInRate.mark(records.sizeInBytes)
          brokerTopicStats.allTopicsStats.bytesInRate.mark(records.sizeInBytes)
          brokerTopicStats.topicStats(topicPartition.topic).messagesInRate.mark(numAppendedMessages)
          brokerTopicStats.allTopicsStats.messagesInRate.mark(numAppendedMessages)

          trace(s"${records.sizeInBytes} written to log $topicPartition beginning at offset " +
            s"${info.firstOffset.getOrElse(-1)} and ending at offset ${info.lastOffset}")
          (topicPartition, LogAppendResult(info))
        } catch {
          // NOTE: Failed produce requests metric is not incremented for known exceptions
          // it is supposed to indicate un-expected failures of a broker in handling a produce request
          case e@ (_: UnknownTopicOrPartitionException |
                   _: NotLeaderForPartitionException |
                   _: RecordTooLargeException |
                   _: RecordBatchTooLargeException |
                   _: CorruptRecordException |
                   _: KafkaStorageException |
                   _: InvalidTimestampException) =>
            (topicPartition, LogAppendResult(LogAppendInfo.UnknownLogAppendInfo, Some(e)))
          case t: Throwable =>
            val logStartOffset = getPartition(topicPartition) match {
              case Some(partition) =>
                partition.logStartOffset
              case _ =>
                -1
            }
            brokerTopicStats.topicStats(topicPartition.topic).failedProduceRequestRate.mark()
            brokerTopicStats.allTopicsStats.failedProduceRequestRate.mark()
            error(s"Error processing append operation on partition $topicPartition", t)
            (topicPartition, LogAppendResult(LogAppendInfo.unknownLogAppendInfoWithLogStartOffset(logStartOffset), Some(t)))
        }
      }
    }
  }

appendToLocalLog 에서 record append 가 실패하면 실패한 결과를 넘겨주고 appendRecords 함수에서는 localProduceResults 라는 변수명으로 결과값을 받는다.

val localProduceResults = appendToLocalLog(internalTopicsAllowed = internalTopicsAllowed,
        origin, entriesPerPartition, requiredAcks)
      debug("Produce to local log in %d ms".format(time.milliseconds - sTime))

localProduceResults 결과중 실패가 있을 경우 delayedProducePurgatory 에 등록하여 재시도 처리한다.
delayedProducePurgatory 에 등록하는 조건

 // If all the following conditions are true, we need to put a delayed produce request and wait for replication to complete
  //
  // 1. required acks = -1
  // 2. there is data to append
  // 3. at least one partition append was successful (fewer errors than partitions)
  private def delayedProduceRequestRequired(requiredAcks: Short,
                                            entriesPerPartition: Map[TopicPartition, MemoryRecords],
                                            localProduceResults: Map[TopicPartition, LogAppendResult]): Boolean = {
    requiredAcks == -1 &&
    entriesPerPartition.nonEmpty &&
    localProduceResults.values.count(_.exception.isDefined) < entriesPerPartition.size
  }

OutOfOrderSequenceException 로그에서 나온 epoch 는 partition leader epoch 가 아닌 producer 관련 epoch 값이다. org.apache.kafka.common.record.RecordBatch 에 정의된 producerEpoch 값을 사용한다.(partition leader 에 대한 epoch 값은 partitionLeaderEpoch 로 따로 정의되어있다.)
메세지 publish 시에 producer 에 대한 상태 체크를 진행하게된다.
kafka.log.producerStateManager 에서 요청시 들어온 producerId 를 가지고 broker 내부에 저장된 producer 상태 정보를 가지고 온다.
조회한 상태 정보를 바탕으로 kafka.log.ProducerAppendInfo 를 생성해 maybeValidateAppend 함수에서 producerId, producerEpoch, appendFirstSeq 값을 확인하게 되는데 그 때 에러가 발생한다.
maybeValidateAppend 함수

private def maybeValidateAppend(producerEpoch: Short, firstSeq: Int) = {
    validationType match {
      case ValidationType.None =>

      case ValidationType.EpochOnly =>
        checkProducerEpoch(producerEpoch)

      case ValidationType.Full =>
        checkProducerEpoch(producerEpoch)
        checkSequence(producerEpoch, firstSeq)
    }
  }

실제 에러를 발생하는 checkSequence 함수

private def checkSequence(producerEpoch: Short, appendFirstSeq: Int): Unit = {
    if (producerEpoch != updatedEntry.producerEpoch) {
      if (appendFirstSeq != 0) {
        if (updatedEntry.producerEpoch != RecordBatch.NO_PRODUCER_EPOCH) {
          throw new OutOfOrderSequenceException(s"Invalid sequence number for new epoch: $producerEpoch " +
            s"(request epoch), $appendFirstSeq (seq. number)")
        } else {
          throw new UnknownProducerIdException(s"Found no record of producerId=$producerId on the broker. It is possible " +
            s"that the last message with the producerId=$producerId has been removed due to hitting the retention limit.")
        }
      }
    } else {
      val currentLastSeq = if (!updatedEntry.isEmpty)
        updatedEntry.lastSeq
      else if (producerEpoch == currentEntry.producerEpoch)
        currentEntry.lastSeq
      else
        RecordBatch.NO_SEQUENCE

      if (currentLastSeq == RecordBatch.NO_SEQUENCE && appendFirstSeq != 0) {
        // We have a matching epoch, but we do not know the next sequence number. This case can happen if
        // only a transaction marker is left in the log for this producer. We treat this as an unknown
        // producer id error, so that the producer can check the log start offset for truncation and reset
        // the sequence number. Note that this check follows the fencing check, so the marker still fences
        // old producers even if it cannot determine our next expected sequence number.
        throw new UnknownProducerIdException(s"Local producer state matches expected epoch $producerEpoch " +
          s"for producerId=$producerId, but next expected sequence number is not known.")
      } else if (!inSequence(currentLastSeq, appendFirstSeq)) {
        throw new OutOfOrderSequenceException(s"Out of order sequence number for producerId $producerId: $appendFirstSeq " +
          s"(incoming seq. number), $currentLastSeq (current end sequence number)")
      }
    }
  }

참고

위 분석 내용 및 코드에서 나오는 producerEpoch 와 firstSequence 에 대한 설명은 아래와 같다.

변수설명

ProducerEpoch	Introduced in 0.11.0.0 for KIP-98, this is the broker assigned producerEpoch received by the 'InitProducerId' request. Clients which want to support idempotent message delivery and transactions must set this field.
FirstSequence	Introduced in 0.11.0.0 for KIP-98, this is the producer assigned sequence number which is used by the broker to deduplicate messages. Clients which want to support idempotent message delivery and transactions must set this field. The sequence number for each Record in the RecordBatch is its OffsetDelta + FirstSequence.

idempotent write 설정을 해서 위 변수값들이 이용되어있는거로 보인다.
좀더 자세한 사항은 A Guide To The Kafka Protocol 참고
kafka broker 2.5.0 에 위 에러에 대한 개선 내용이 있는거로 보여짐.KIP-360 참고

[Kafka] kafka SASL / SCRAM 인증, kafka-acls 권한 설정

흥부가귀막혀 — Mon, 14 Mar 2022 15:56:26 +0900

개요 및 고려 사항

SCRAM (Salted Challenge Response Authentication Mechanism) 또는 SASL / SCRAM은 PLAIN과 같은 사용자 이름 / 암호 인증을 수행하는 기존 메커니즘의 보안 문제를 해결하는 SASL 메커니즘.
Apache Kafka는 SCRAM-SHA-256 및 SCRAM-SHA-512을 지원.
Kafka의 SCRAM 구현은 ZooKeeper에 SCRAM 자격 증명을 저장하기 때문에 ZooKeeper가 개인 네트워크에 있을때 사용하는것을 권장
runtime 으로 zookeeper 에 사용자에 대한 SCRAM 자격 증명을 생성할 수 있다.

super user 생성

${KAFKA_HOME}/bin/kafka-configs.sh 를 통해 super user 생성

$ ./kafka-configs.sh --zookeeper $ZOOKEEPER:2181 --alter --add-config 'SCRAM-SHA-256=[password=super-user-password]' --entity-type users --entity-name super-user-id
Completed Updating config for entity: user-principal 'super-user-id'.

ANONYMOUS user 권한 추가

기존에 보안설정을 안한 상태로 유지를 하고있다면 해당 권한 설정을 해주는게 좋다.(아니면 allow.everyone.if.no.acl.found=true 설정을 broker properties 에 해도 되는데 그럴경우 기존 운영했던 port 를 종료할때 broker 를 다시 시작해야한다.)
authorizer 를 정의하게 되면 기존 운영중인 9092 포트로 들어온 요청도 인증을 타게되어 ANONYMOUS user 로 인증이 되 유입되게 되는데 해당 user 에 대한 권한 설정을 해주지 않으면 broker 와 client 의 operation이 모두 denied 처리 되버린다.

* cluster resource 권한 추가(broker 를 위한 설정)

$ ./kafka-configs.sh --authorizer-properties zookeeper.connect=$ZOOKEEPER --add --allow-principal User:ANONYMOUS --operation "ALL" --cluster

* topic/group resource 권한 추가(client 를 위한 설정)

$ ./kafka-configs.sh  --authorizer-properties zookeeper.connect=$ZOOKEEPER --add --allow-principal User:ANONYMOUS --operation "ALL" --topic "*" --group="*"

broker 설정

각 kafka broker 에 jaas config 파일을 생성(kafka_server_jaas.conf)

KafkaServer {
   org.apache.kafka.common.security.scram.ScramLoginModule required
   username="super-user-id"
   password="super-user-id-password";
};

broker 실행 옵션에 -Djava.security.auth.login.config={path to jaas conf}/kafka_server_jaas.conf 설정 추가하여 재시작
kafka server.properties 파일에 SASL/SCRAM 메커니즘 활성을 위한 설정 추가

# List of enabled mechanisms, can be more than one
sasl.enabled.mechanisms=SCRAM-SHA-256 # or SCRAM-SHA-512
# Specify one of of the SASL mechanisms
sasl.mechanism.inter.broker.protocol=SCRAM-SHA-256 # or SCRAM-SHA-512

브로커 간 통신에 SASL을 사용하여 통신할거라면 server.properties 에 아래 설정을 추가
- SASL_SSL: SSL 암호화를 사용하는 경우
- SASL_PLAINTEXT: SSL 암호화를 사용하지 않는 경우

security.inter.broker.protocol=SASL_PLAINTEXT # or SASL_SSL

클라이언트 및 브로커 간 SASL연결을 어떻게 할것인지 server.properties 에 설정

listeners=SASL_PLAINTEXT://brokerhost1:9092

보안설정 없이 동작하는 client 를 위해 기존 PLAINTEXT 도 유지를 하고자 한다면 server.properties 를 아래와 같이 설정

# 9093 포트로 진입시에만 SASL 사용
listeners=PLAINTEXT://brokerhost1:9092,SASL_PLAINTEXT://brokerhost1:9093
advertised.listeners=PLAINTEXT://brokerhost1:9092,SASL_PLAINTEXT://brokerhost1:9093

acl 권한 체크 활성화를 위해 server.properties 에 아래와 같이 설정

# ssl 설정을 할 경우 아래 설정 추가
# ssl.client.auth=requested 
authorizer.class.name=kafka.security.auth.SimpleAclAuthorizer
# client 에 보안 설정이 되어있지 않을 경우 User:ANONYMOUS 로 요청이 들어오게 되는데, 에러가 발생되지 않도록 잠시 super 유저로 설정
super.users=User:kafka-admin;User:ANONYMOUS 
# 초기 보안 설정 구축시 보안 설정이 되어있지 않은 client 에서도 정상동작을 원한다면 아래 설정을 추가하는것도 방법
allow.everyone.if.no.acl.found=true

client

각 client 의 properties 파일에 아래 설정을 추가

security.protocol=SASL_PLAINTEXT # or SASL_SSL
sasl.mechanism=SCRAM-SHA-256 # or SCRAM-SHA-512
sasl.jaas.config=org.apache.kafka.common.security.scram.ScramLoginModule required username="userid" password="user password";

권한 추가

${KAFKA_HOME}/bin/kafka-configs.sh 를 통해 계정 생성

$ ./kafka-configs.sh --zookeeper $ZOOKEEPER:2181 --alter --add-config 'SCRAM-SHA-256=[password=demo!23]' --entity-type users --entity-name demo
Completed Updating config for entity: user-principal 'demo'.

${KAFKA_HOME}/bin/kafka-acls.sh 스크립트를 통해 권한 추가

예) demo 계정이 test 토픽으로 접근시 모든 group 에 대해 읽기 권한 추가

$ ./kafka-acls.sh --authorizer-properties zookeeper.connect=$ZOOKEEPER:2181 --add --allow-principal User:demo --operation read --topic test --group='*'
Adding ACLs for resource `Topic:LITERAL:test`: 
        User:demo has Allow permission for operations: Read from hosts: * 

Adding ACLs for resource `Group:LITERAL:*`: 
        User:demo has Allow permission for operations: Read from hosts: * 

Current ACLs for resource `Topic:LITERAL:test`: 
        User:demo has Allow permission for operations: Read from hosts: * 

Current ACLs for resource `Group:LITERAL:*`: 
        User:demo has Allow permission for operations: Read from hosts: *

Reference

[Kafka] LeaderEpochCache Warn Log

흥부가귀막혀 — Mon, 14 Mar 2022 15:43:52 +0900

개요

Broker 에 아래와 같이 Warn Level 로그가 남겨짐

[2020-07-30 12:40:03,237] WARN [LeaderEpochCache message_action-46] New epoch entry EpochEntry(epoch=27, startOffset=0) caused truncation of conflicting entries ListBuffer(EpochEntry(epoch=26, startOffset=0)). Cache now contains 1 entries. (kafka.server.epoch.LeaderEpochFileCache)

해당 로그가 왜 남겨지고, 해소할 방법은 없는지 탐색.

원인 파악

해당 로그는 partition leader 에 대한 epoch 값이 변경될 경우 변경된 epoch 값을 cache 및 기존 cache 된 내용을 truncate 하는 과정에서 발생하는 로그다.(LeaderEpoch 에 대한 내용은 KIP-101 참고)
로그를 남기고 있는 v2.1.1 코드 는 아래와 같다.

/**
   * Remove any entries which violate monotonicity following the insertion of an assigned epoch.
   */
  private def truncateAndAppend(entryToAppend: EpochEntry): Unit = {
    validateAndMaybeWarn(entryToAppend)

    val (retainedEpochs, removedEpochs) = epochs.partition { entry =>
      entry.epoch < entryToAppend.epoch && entry.startOffset < entryToAppend.startOffset
    }

    epochs = retainedEpochs :+ entryToAppend

    if (removedEpochs.isEmpty) {
      debug(s"Appended new epoch entry $entryToAppend. Cache now contains ${epochs.size} entries.")
    } else {
      warn(s"New epoch entry $entryToAppend caused truncation of conflicting entries $removedEpochs. " +
        s"Cache now contains ${epochs.size} entries.")
    }
  }

신규로 append 되는 epoch 의 startOffset 이 기존과 같거나 작으면 해당 warn log 를 남기도록 되어있다.
startOffset 이 작은 경우 문제가 있는 케이스이지만 같은건 정상적인 상황에서도 가능한 케이스라 이렇게 남긴것이 의문.
v2.3.0 코드 를 보니 아래와 같이 변경되어있다.(해당 코드는 PR 에서 수정 요청되었다.)

/**
   * Remove any entries which violate monotonicity following the insertion of an assigned epoch.
   */
  private def truncateAndAppend(entryToAppend: EpochEntry): Unit = {
    validateAndMaybeWarn(entryToAppend)

    val (retainedEpochs, removedEpochs) = epochs.partition { entry =>
      entry.epoch < entryToAppend.epoch && entry.startOffset < entryToAppend.startOffset
    }

    epochs = retainedEpochs :+ entryToAppend

    if (removedEpochs.isEmpty) {
      debug(s"Appended new epoch entry $entryToAppend. Cache now contains ${epochs.size} entries.")
    } else if (removedEpochs.size > 1 || removedEpochs.head.startOffset != entryToAppend.startOffset) {
      // Only log a warning if there were non-trivial removals. If the start offset of the new entry
      // matches the start offfset of the removed epoch, then no data has been written and the truncation
      // is expected.
      warn(s"New epoch entry $entryToAppend caused truncation of conflicting entries $removedEpochs. " +
        s"Cache now contains ${epochs.size} entries.")
    }
  }

저렇게 변경한 이유는 위에서 의문을 제기한 startOffset 이 같을 경우가 꼭 문제가 있는 상황은 아니기 때문이다. 메세지가 publish 되지 않은 상황이라면(traffic 이 적은 상황이라면) 충분히 가능한 케이스이기 때문에 2.3.1 에서 해당 상황은 로그를 안남기는거로 제외되었다.

Leader epoch 값이 왜 달랐을까?

kafka broker 에서는 partition 에 대한 leader epoch 값을 Partition 객체에도 저장(memory)하고, 추후 복구를 대비하여 LeaderEpochFileCache 를 사용하여 file 로도 저장한다.
문제는 partition leader 가 변경될 경우 변경된 leader epoch 값을 memory(Partition 객체) 와 file(LeaderEpochFileCache) 에 모두 저장하는 노드는 partition leader 노드만 그렇게 저장하고, follower 노드는 memory(Partition 객체) 에만 저장한다.
그러다보니 follower 노드에서 fetcher thread 를 통해 message 복제를 시도할 때 memory 에 저장된 leader epoch 값으로 LeaderEpochFileCache 에 append 를 하니 위와 같은 로그가 남게되는것이다.
즉, 갑자기 leader epoch 값이 올라가서 발생한게 아니라 기존에 leader epoch 값이 변경이 되었는데(브로커 노드 재시작 등으로 인해) follower 노드에서 이에 대한 update 가 message 복제 시점에 발생해서 그런 것이다.

로그를 통한 검증

기존 leader 노드를 재시작하여 partition leader 가 변경되었었다.
partition leader 가 변경되어 leaderEpoch 값이 변경된건 leader 와 follower 노드 모두 정상 처리 되었다.
leader 노드 로그

[2020-07-10 12:22:06,652] TRACE [Broker id=23] Cached leader info PartitionState(controllerEpoch=16, leader=23, leaderEpoch=211, isr=[24, 23], zkVersion=295, replicas=[23, 24], offlineReplicas=[]) for partition test-48 in response to UpdateMetadata request sent by controller 24 epoch 16 with correlation id 11 (state.change.logger)

follower 노드 로그

[2020-07-10 12:22:04,687] TRACE [Broker id=24] Cached leader info PartitionState(controllerEpoch=16, leader=23, leaderEpoch=211, isr=[24, 23], zkVersion=295, replicas=[23, 24], offlineReplicas=[]) for partition test-48 in response to UpdateMetadata request sent by controller 24 epoch 16 with correlation id 17 (state.change.logger)

브로커 재시작 이후 test topic 48번 파티션으로 최초로 메세지가 유입되어 follower 노드쪽에 복제가 발생하고 아래와 같은 로그가 발생하였다

[2020-08-04 19:03:40,945] WARN [LeaderEpochCache test-48] New epoch entry EpochEntry(epoch=211, startOffset=40) caused truncation of conflicting entries ListBuffer(EpochEntry(epoch=210, startOffset=40)). Cache now contains 1 entries. (kafka.server.epoch.LeaderEpochFileCache)

의문

왜 follower 노드에서는 파티션 리더가 변경될 당시에 file cache 를 하지 않았는지 의문.

[Kafka] fetch.max.wait.ms 와 fetch.min.bytes 설정 으로 인한 Consumer 성능 이슈 정리

흥부가귀막혀 — Mon, 14 Mar 2022 15:06:17 +0900

이슈

producer 가 메세지를 일정 간격으로 전송(500ms)
consumer 설정 중 fetch.min.bytes 를 1로 설정(데이터가 있으면 즉시 받도록 최소로 설정) 하고 fetch.max.wait.ms 를 default(500ms)로 설정했을 때, consumer 가 저장된 메세지를 읽어들이는데 지연시간이 발생.(메세지가 broker 에 도착시간은 12시 0분 0초 0ms 인데 해당 메세지를 컨슈머가 읽은 시간은 12시 0분 0초 300ms)
fetch.max.wait.ms 를 100ms 로 설정하였을 경우 지연시간이 줄어듬

원인

kafka documentation 에 정리된 설정값의 설명을 보면 fetch.min.bytes 를 1로 설정할 경우 데이터가 들어왔을 때 즉시 응답을 줄거로 예상하지만 실제 동작은 그게 아니였다.
consumer 에서 fetch request 를 보냈을 때 broker 에서는 응답해야할 메세지가 있으면 fetch.min.bytes 가 1 이기 때문에 즉시 응답을 준다.
하지만 broker 에서 응답을 줄 메세지가 없을 경우 대기를 하게 되고, 이 대기 시간은 새로운 메세지가 들어올때 끝나는게 아니라 fetch.max.wait.ms 만큼 기다리게 된다.
즉, 응답할 메세지가 없는 상태에서 fetch request 가 0.3 초에 요청되고 메세지가 0.5 초에 도착했더라도 fetch.max.wait.ms 가 500ms 로 설정되었다면 0.5초에 응답을 받는게 아니라 0.8초에 응답을 받게되어 지연이 발생하게 된다.
해당 내용은 kafka broker code 를 통해 확인 가능하다.

    // respond immediately if 1) fetch request does not want to wait
    //                        2) fetch request does not require any data
    //                        3) has enough data to respond
    //                        4) some error happens while reading data
    if (timeout <= 0 || fetchInfos.isEmpty || bytesReadable >= fetchMinBytes || errorReadingData) {
      val fetchPartitionData = logReadResults.map { case (tp, result) =>
        tp -> FetchPartitionData(result.error, result.highWatermark, result.leaderLogStartOffset, result.info.records,
          result.lastStableOffset, result.info.abortedTransactions)
      }
      responseCallback(fetchPartitionData)
    } else {
      // construct the fetch results from the read results
      val fetchPartitionStatus = new mutable.ArrayBuffer[(TopicPartition, FetchPartitionStatus)]
      fetchInfos.foreach { case (topicPartition, partitionData) =>
        logReadResultMap.get(topicPartition).foreach(logReadResult => {
          val logOffsetMetadata = logReadResult.info.fetchOffsetMetadata
          fetchPartitionStatus += (topicPartition -> FetchPartitionStatus(logOffsetMetadata, partitionData))
        })
      }
      val fetchMetadata = FetchMetadata(fetchMinBytes, fetchMaxBytes, hardMaxBytesLimit, fetchOnlyFromLeader,
        fetchIsolation, isFromFollower, replicaId, fetchPartitionStatus)
      val delayedFetch = new DelayedFetch(timeout, fetchMetadata, this, quota, responseCallback)

      // create a list of (topic, partition) pairs to use as keys for this delayed fetch operation
      val delayedFetchKeys = fetchPartitionStatus.map { case (tp, _) => new TopicPartitionOperationKey(tp) }

      // try to complete the request immediately, otherwise put it into the purgatory;
      // this is because while the delayed fetch operation is being created, new requests
      // may arrive and hence make this operation completable.
      delayedFetchPurgatory.tryCompleteElseWatch(delayedFetch, delayedFetchKeys)
    }

주석에 설명되어있듯이 즉시 응답을 주는 조건은 다음과 같다.

timeout 값(fetch.max.wait.ms 설정값)을 0 이하로 했을 경우
fetch 요청할 토픽과 파티션 정보가 없을 경우(이런 케이스는 어떤 케이스인지 확인 필요)
fetch.min.bytes 이상의 데이터를 읽었을 경우
에러가 발생했을 경우

그래서.. 결론은?

fetch.max.wait.ms 를 줄이는게 무조건 좋은건 아니다. fetch.max.wait.ms 를 줄이게 되면 그만큼 polling 루프가 빨라지게 되고 fetch 요청도 많아져 broker 에 부담이 갈 수 밖에 없다. 또한, max.partition.fetch.bytes, fetch.max.bytes 만큼 받지 못하고 짧게 끊어서 여러번 받기 때문에 네트워크 비용도 증가한다.
일반적인 client 의 consumer 라면, 그리고 message 를 간헐적으로 보내는 producer 가 있을때 빠르게 반응해야하는게 아니라면 해당 설정은 default 로 두어도 무방하다.
하지만 어떤 간격의 message 가 오더라도 빠르게 반응하고 전달해야하는 Consumer 라면 fetch.max.wait.ms 를 default 값보다 줄이는게 이득으로 보인다.

[VictoriaMetrics] 설치

흥부가귀막혀 — Mon, 14 Mar 2022 14:13:04 +0900

스펙

Server

CentOS 7.4 64bit
CPU: 2core
Mem: 2GB
Disk: 100GB
User: irteam(home: /home1/irteam/)

VictoriaMetrics

version: 1.62.0

Go

version: 1.16.5

HA 구성

HA 구성 방법에는 단일 노드와 cluster 구성 방법이 있다.
단일 노드로 구성할 경우 vmagent 를 통해 단일 노드로 구축한 여러대의 victoria-metrics 에 write 를 할 수 있다. 만약 vmagent 를 사용하지 않을 경우 client 가 직접 이런 처리를 해야한다.
cluster 로 구성할 경우 vminsert 가 단일 노드시 사용하는 vmagent 역할을 하는거로 보인다.(이때 replica 도 정의할 수 있다.) 자세한 사항은 cluster guide 참고
metric 데이터량이 크지 않을 경우 단일 노드로 구성하는걸 추천

설치 가이드

공통 사항

dir 생성

# apps 및 victoria metrics bin 폴더 생성
mkdir -p /home1/irteam/apps/victoria-metrics/
# data 를 저장할 경로 생성 
mkdir -p /home1/irteam/data/victoria-metrics
mkdir -p /home1/irteam/data/vmagent
# log 폴더 생성
mkdir -p /home1/irteam/logs/victoria-metrics/
# 필요한 내용을 설치할 INSTALL 폴더 생성
mkdir -p /home1/irteam/INSTALL

1안. source compile

go 설치

다운로드

cd /home1/irteam/INSTALL
wget 'https://dl.google.com/go/go1.16.5.linux-amd64.tar.gz'
tar -zxvf go1.16.5.linux-amd64.tar.gz
# apps 로 이동
mv go ~/apps

환경 변수 설정

export GO_HOME=${APP_HOME}/apps/go
export PATH=${GO_HOME}/bin:$PATH

make 수행시 compile 에러 방지를 위해 GCC upgrade

sudo yum install centos-release-scl -y
sudo yum install devtoolset-7 -y
scl enable devtoolset-7 bash

Victoria Metrics

cd /home1/irteam/INSTALL
git clone -b v1.62.0 https://github.com/VictoriaMetrics/VictoriaMetrics.git
cd VictoriaMetrics
# 1.62.0 이 맞는지 확인을 위하 한번더 checkout
git checkout -b v1.62.0
# fatal: A branch named 'v1.62.0' already exists. 라 뜨면 정상적으로 1.62.0 을 clone 받은 것.
make victoria-metrics
# 생성된 binary 를 apps 폴더로 이동
mv bin/victoria-metrics ~/apps/victoria-metrics/

vmagent

# Victoria Metrics 설치 이후에 진행.
make vmagent
# 생성된 binary 를 apps 폴더로 이동
mv bin/vmagent ~/apps/victoria-metrics/

vmalert

# Victoria Metrics 설치 이후에 진행.
make vmalert
# 생성된 binary 를 apps 폴더로 이동
mv bin/vmalert ~/apps/victoria-metrics/

2안. victoria metrics 에서 제공해준 product download

Victoria Metrics

다운로드

cd /home1/irteam/INSTALL
wget https://github.com/VictoriaMetrics/VictoriaMetrics/releases/download/v1.62.0/victoria-metrics-amd64-v1.62.0.tar.gz
tar -zxvf victoria-metrics-amd64-v1.62.0.tar.gz
mv victoria-metrics-prod ~/apps/victoria-metrics/victoria-metrics

vmagent

다운로드

cd /home1/irteam/INSTALL
wget https://github.com/VictoriaMetrics/VictoriaMetrics/releases/download/v1.62.0/vmutils-amd64-v1.62.0.tar.gz
tar -zxvf vmutils-amd64-v1.62.0.tar.gz
mv vmagent-prod ~/apps/victoria-metrics/vmagent

vmalert

다운로드

# vmagent 설치로 vmutils-amd64-v1.62.0.tar.gz 을 download 받고 압축을 해제했을 경우
mv vmalert-prod ~/apps/victoria-metrics/vmalert

실행

victoria metrics

bin 폴더 접근하여 아래와 같은 arg 로 실행

cd /home1/irteam/apps/victoria-metrics/
./victoria-metrics \ 
     -storageDataPath=/home1/irteam/data/victoria-metrics \
     1> /home1/irteam/logs/victoria-metrics/vm.log 2>&1 &

실행시 줄수 있는 옵션은 link 참고
systemd 를 사용하여 실행하는 방법은 link 참고

vmagent

bin 폴더 접근하여 아래와 같은 arg 로 실행

cd /home1/irteam/apps/victoria-metrics/
./vmagent \
    -remoteWrite.tmpDataPath=/home1/irteam/data/vmagent \
    -remoteWrite.maxDiskUsagePerURL=1GB \
    -remoteWrite.url=http://<victoriametrics-host-1>:8428/api/v1/write \
    -remoteWrite.url=http://<victoriametrics-host-2>:8428/api/v1/write \
    1> /home1/irteam/logs/victoria-metrics/vmagent.log 2>&1 &

실행시 줄수 있는 옵션은 link 참고

vmalert

/home1/irteam/config/vmalert 폴더에 alert.rules 설정 파일 정의
bin 폴더 접근하여 아래와 같은 arg 로 실행
alert rule 은 prometheus 에서 정의한 alert rule 을 따른다

./vmalert -rule=/home1/irteam/config/vmalert/alert.rules \            # Path to the file with rules configuration. Supports wildcard
    -datasource.url=http://localhost:8428 \  # PromQL compatible datasource
    -notifier.url=http://<alertmanager addr>:9093 \    # AlertManager URL
    -remoteWrite.url=http://localhost:8428 \ # Remote write compatible storage to persist rules
    -remoteRead.url=http://localhost:8428  \ # MetricsQL compatible datasource to restore alerts state from
    -evaluationInterval=30s \
    1> /home1/irteam/logs/victoria-metrics/vmalert.log 2>&1 &

Spring Webflux - Utils

흥부가귀막혀 — Mon, 14 Mar 2022 13:14:01 +0900

BlockHound

Spring Webflux 는 예상치 못한 blocking 로직이 있을 경우 성능에 큰 영향을 미치기 때문에 이러한 로직이 있는지 탐지하고 수정할 수 있어야 한다.
BlockHound 는 비지니스 로직이 수행될 때 blocking 로직이 있으면 exception 을 던져 blocking 로직을 파악할 수 있게 도와준다.
번역 gateway 에서는 아래와 같은 방식으로 blockhound 를 실행한다.

Dependency 추가

 <dependency>
     <groupId>io.projectreactor.tools</groupId>
     <artifactId>blockhound</artifactId>
     <version>1.0.3.RELEASE</version>
 </dependency>

Application class 에서 BlockHound 실행여부를 판단

@SpringBootApplication
public class Application {
    static final String BLOCK_HOUND_INSTALL = "service.block-hound.install"; // (1)

    public static void main(String[] args) {
        boolean installBlockHound = SpringApplication.run(Application.class, args) // (2)
            .getEnvironment()
            .getProperty(BLOCK_HOUND_INSTALL, boolean.class, false);

        if (installBlockHound) {
            BlockHound.install(); // (3)
        }
    }
}

(1) application 실행시 특정 config 값을 통해 BlockHound 실행 여부를 판단할 수 있게 정의한다.
(2) application 실행시 BlockHound 실행 여부를 판단할 수 있는 config 값을 조회한다.
(3) BlockHound 를 실행하도록 config 가 주입되었으면 install API 호출을 통해 실행

비지니스 로직 수행중에 blocking 로직이 탐지되면 아래와 같이 에러가 발생한다.

java.lang.Error: Blocking call! java.lang.Thread.sleep
at reactor.blockhound.BlockHound$Builder.lambda$new$0(BlockHound.java:167)
at reactor.blockhound.BlockHound$Builder.lambda$install$6(BlockHound.java:226)
at reactor.blockhound.BlockHoundRuntime.checkBlocking(BlockHoundRuntime.java:46)
at java.lang.Thread.sleep(Thread.java)
at com.example.demo.DemoApplication.block(DemoApplication.java:30)

Reloadable Configuration

Reloadable Configuration 을 하는 방법은 몇가지 있지만 Spring 에서 공식적으로 지원하는 방식은 Spring Cloud에서 지원하는 @RefreshScope 사용한 방식이다.

Spring Cloud 에 대한 dependency 추가

<dependencyManagement>
    <dependencies>
        <dependency>
            <groupId>org.springframework.cloud</groupId>
            <artifactId>spring-cloud-dependencies</artifactId>
            <version>${spring-cloud.version}</version>
            <type>pom</type>
            <scope>import</scope>
        </dependency>
    </dependencies>
</dependencyManagement>

<dependencies>
    <dependency>
        <groupId>org.springframework.cloud</groupId>
        <artifactId>spring-cloud-starter</artifactId>
    </dependency>
</dependencies>

Reloadable ConfigurationProperties 정의

	@Bean
	@RefreshScope
	@ConfigurationProperties(prefix = "example.reload.properties")
	public Map<String, String> exampleProperties() {
		return new HashMap<String, String>();
	}

Configuration 이 필요한 곳에서는 Bean 으로 등록된 Properties 를 주입받아 사용.

@Autowired
private Map<String, String> exampleProperties;

/**
 * properties value 조회
 */
public String getValue(String key) {
   return exampleProperties.get(key);
}

Configuration 변경이 필요할 경우 config file 을 수정한 뒤 다음과 같이 actuator API 호출. (단, management.endpoints.web.exposure.include 에 refresh 가 활성화 되있어야 한다.)

curl -XPOST http://{host}:{port}/actuator/refresh

Spring Webflux - Test Code

흥부가귀막혀 — Mon, 14 Mar 2022 13:12:53 +0900

Test Code

StepVerifier

Reactor 를 사용할 경우 주로 다루는 Mono/Flux 를 반환하는 리액티브 API 에 대한 테스트는 기존 Test Code 작성 방법으로는 테스트하기 힘들다.
아래와 같이 reactor-test 에 대한 dependency 를 추가해야 사용이 가능하다

<dependency>
    <groupId>io.projectreactor</groupId>
    <artifactId>reactor-test</artifactId>
    <scope>test</scope>
</dependency>

◉ 일반적인 Test Code 작성시 발생할 수 있는 실수 1

@Test
public void mono() {
  Mono<Integer> mono = Mono.just(1) // (1)
        .subscribeOn(Schedulers.single());  // (2)

  Mono.subscribe(item -> assertThat(item).isEqualTo(1)); // (3)
}

(1) 1을 생성하는 Mono 생성.
(2) single thread 로 비동기 동작을 수행하도록 scheduler 설정.
(3) subscribe 를 통해 생성한 Mono 구독 후 검증.

위의 테스트 코드의 결과는 성공으로 반환되지만 실제로는 정상적인 테스트가 이루어지지 않은 것이다. 그 이유는 Scheduler 를 통해 비동기로 테스트코드가 동작하게 되면서 아직 테스트코드가 전부 실행되지 않은 상태에서 mono Test Code 함수가 정상적으로 종료되었기 때문이다.
실제로 isEqualTo(1) 을 isEqualTo(100) 으로 변경해도 테스트 코드는 성공한다.

◉ 일반적인 Test Code 작성시 발생할 수 있는 실수 2

@Test
public void mono() {
  Mono<Integer> mono = Mono.just(1) 
        .subscribeOn(Schedulers.single()); 

  CountDownLatch latch = new CountDownLatch(1); // (1)

  Mono.subscribe(item -> {
        assertThat(item).isEqualTo(2); // (2)
        latch.countDown(); // (3)      
  }); 

  latch.await(); // (4)
}

(1) 1의 실수 케이스를 보완하기 위해 비동기 동작이 끝날때까지 기다리도록 CountDownLatch 선언.
(2) 테스트 코드 검증 로직에서 실패 발생.
(3) 테스트가 성공할 경우 count 가 증가하도록 하려 했으나 (2) 에서 예외가 발생하여 수행되지 못함.
(4) 테스트가 무한정 대기하게 된다.

비동기로 동작하는 로직을 검증하기 위해 blocking 로직을 테스트코드에 넣었다가 발생할 수 있는 실수다.
예외 처리를 통해 위와 같은 실수를 방지할수는 있지만 고작 1을 publish 하는 Mono 에 대한 검증치고는 테스트코드가 너무 방대하고 신경써야할게 많다.

StepVerifier 를 사용할 경우

위에 실수 케이스에 대해 StepVerifier 를 사용할 경우 아래와 같이 코드를 짤 수 있다.

@Test
public void mono() {
  Mono<Integer> mono = Mono.just(1) 
        .subscribeOn(Schedulers.single());  

  StepVerifier.create(mono) // (1)
        .expectNext(1)      // (2)
        .verifyComplete();  // (3)
}

(1) mono 에 대한 StepVerifier Step 생성
(2) Mono 에서 처음 publish 한 데이터가 1인지 검증
(3) 테스트 검증 완료

예외 발생에 대한 검증

예외 발생에 대한 검증을 위해 제공하는 API 들도 있다.

@Test
public void flux() {
  Flux<Integer> flux = Flux.just(1)
        .concatWith(Mono.error(new IllegalArgumentException("BOOM!")) // (1)
        .subscribeOn(Schedulers.single());  

  StepVerifier.create(flux) 
        .expectNext(1)     
        .expectErrorMatches(throwable -> throwable instanceof IllegalArgumentException && throwable.getMessage().equals("BOOM!")) // (2)
        .verify(); // (3)
}

(1) 1 이후 IllegalArgumentException 이 발생하도록 추가
(2) 1 이후 error 가 발생할거라 기대하고 해당 에러가 IllegalArgumentException 인지, message 가 기대한것과 같은지 확인
(3) 테스트 검증 완료

WebTestClient

Request Mapping 및 Handler, Filter 등의 동작에 대한 검증을 할 수 있도록 WebTestClient 를 제공하고 있다.
아래와 같이 spring-boot-starter-test 에 대한 dependency 를 추가해야 사용이 가능하다

<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-test</artifactId>
    <scope>test</scope>
</dependency>

아래와 같이 Controller 로 정의한 API 에 대해 테스트 코드를 작성해볼 수 있다.

Controller

@Controller
public class HelloController {
   @GetMapping("/hello/{name}")
   public Mono<String> hello(@PathVariable String name) {
       return Mono.just("hello " + name);
   }
}

WebTestClient Test Code

@RunWith(SpringRunner.class)
@WebFluxTest
public class HelloControllerTest {
  @Autowired 
  private WebTestClient webTestClient; // (1)

  @Test
  public void hello() {
    webTestClient.get()
        .uri("/hello/{name}", "Spring") // (2)
        .exchange()
        .expectStatus()
        .isOk()  // (3)
        .expectBody(String.class)
        .isEqualTo("hello Spring"); // (4)
  }
}

(1) @WebFluxTest 에서 자동으로 WebTestClient 를 생성해서 주입이 가능하게 해주는데 이때는 Test Code 실행시 만들어지는 ApplicationContext 를 활용한 WebTestClient.bindToApplicationContext(context) 함수로 WebTestClient 가 생성된다.
(2) 생성된 WebTestClient 를 통해 /hello/Spring 이라는 url 로 API 를 요청해 본다.
(3) 응답이 성공으로 왔는지 검증한다.
(4) 응답값이 기대한 결과대로 왔는지 검증한다.

WebTestClient 는 테스트 케이스에 따라 아래와 같이 여러가지 방법으로 생성이 가능하다.

Binding to a Server : application server url 로 생성. 해당 Application Server 로 요청이 가능하다.

WebTestClient testClient = WebTestClient
  .bindToServer()
  .baseUrl("http://localhost:8080")
  .build();

Binding to a Router : RouterFunction 을 통해 생성. 테스트 요청은 해당 RouterFunction 에 맵핑된 url 만 할 수 있다.

RouterFunction function = RouterFunctions.route(
  RequestPredicates.GET("/resource"),
  request -> ServerResponse.ok().build()
);

WebTestClient testClient = WebTestClient
  .bindToRouterFunction(function)
  .build()

Binding to an Application Context : ApplicationContext 를 통해 생성. ApplicationContext 를 생성한 Application 에 대해 요청이 가능하다.

@Autowired
private ApplicationContext context;

WebTestClient testClient = WebTestClient.bindToApplicationContext(context)
  .build();

Binding to a Controller : Controller 를 통해 생성. 해당 Controller 에 맵핑된 url 에 대해 테스트 요청이 가능하다.

@Autowired
private Controller controller;

WebTestClient testClient = WebTestClient.bindToController(controller).build();

Spring Webflux - Monitoring Metrics

흥부가귀막혀 — Mon, 14 Mar 2022 13:10:53 +0900

Monitoring Metrics

Spring Boot Application 의 Metric 을 수집하는 방법중의 하나로 Spring Actuator 를 사용할 수 있다.
Spring Actuator 의 dependency 를 추가한다.

<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-actuator</artifactId>
</dependency>

management.endpoints.web.exposure.include 에 metrics 값을 추가하면 /actuator/metrics API 가 활성화 된다.

management:
  endpoints:
    web:
      exposure:
        include: ["metrics"]

HTTP GET method 요청으로 /actuator/metrics/{metric name} 형태로 요청하면 수집된 metric 에 대한 조회가 가능하다.
tag 별로 조회하고자 하면 HTTP GET method 요청으로 /actuator/metrics/{metric name}?tag=key:value 형태로 요청하면 된다.

TcpServer

Netty TcpServer 에 대한 metric
NettyServerCustomizer 를 통해 tcpServer.metrics(boolean); 함수를 호출하여 TcpServer 에 대한 metric 을 활성화해야 한다.

nametype설명

reactor.netty.tcp.server.data.received	DistributionSummary	TcpServer 에서 수신받은 data byte 수
reactor.netty.tcp.server.data.sent	DistributionSummary	TcpServer 에서 전송한 data byte 수
reactor.netty.tcp.server.errors	Counter	TcpServer Error 발생 횟수
reactor.netty.tcp.server.tls.handshake.time	Timer	TLS handshake 에 소요된 시간

HttpClient

Reactor Netty HttpClient 에 대한 metric
Reactor Netty HttpClient 생성시 HttpClient.metrics(boolean, Consumer) 함수를 호출하여 HttpClient 에 대한 metric 을 활성화해야 한다.

nametype설명

reactor.netty.http.client.data.received	DistributionSummary	TcpServer 에서 수신받은 data byte 수
reactor.netty.http.client.data.sent	DistributionSummary	TcpServer 에서 전송한 data byte 수
reactor.netty.http.client.errors	Counter	TcpServer Error 발생 횟수
reactor.netty.http.client.tls.handshake.time	Timer	TLS handshake 에 소요된 시간
reactor.netty.http.client.connect.time	Timer	TcpServer 에서 수신받은 data byte 수
reactor.netty.http.client.address.resolver	Timer	TcpServer 에서 전송한 data byte 수
reactor.netty.http.client.data.received.time	Timer	TcpServer Error 발생 횟수
reactor.netty.http.client.data.sent.time	Timer	TLS handshake 에 소요된 시간
reactor.netty.http.client.response.time	Timer	TLS handshake 에 소요된 시간

ConnectionProvider

Reactor Netty HttpClient 에서 Connection 관리를 담당하는 ConnectionProvider 에 대한 metric
Reactor Netty ConnectionProvider 를 Builder 를 통해 생성시 ConnectionProvider.Builder.metrics(boolean) 함수를 호출하여 ConnectionProvider 에 대한 metric 을 활성화해야 한다.

nametype설명

reactor.netty.connection.provider.total.connections	Gauge	TcpServer 에서 수신받은 data byte 수
reactor.netty.connection.provider.active.connections	Gauge	TcpServer 에서 전송한 data byte 수
reactor.netty.connection.provid er.idle.connections	Gauge	TcpServer Error 발생 횟수
reactor.netty.connection.provider.pending.connections	Gauge	TLS handshake 에 소요된 시간

Spring Webflux - Exception Handle

흥부가귀막혀 — Mon, 14 Mar 2022 13:09:26 +0900

Exception Handle

Functional Level

Handler 에서 함수 수행시 onErrorReturn, onErrorResume 을 정의하여 에러 핸들링 처리를 할 수 있다.

onErrorReturn

public Mono<ServerResponse> handleRequest(ServerRequest request) {
    return sayHello(request)
      .onErrorReturn("Request Fail! But Return Success Status!")
      .flatMap(s -> ServerResponse.ok()
      .contentType(MediaType.TEXT_PLAIN)
      .bodyValue(s));
}

onErrorResume

public Mono<ServerResponse> handleRequest(ServerRequest request) {
    return sayHello(request)
      .flatMap(s -> ServerResponse.ok()
      .contentType(MediaType.TEXT_PLAIN)
      .bodyValue(s))
      .onErrorResume(e -> sayHelloFallback()
         .flatMap(s -> ServerResponse.ok()
               .contentType(MediaType.TEXT_PLAIN)
               .bodyValue(s)
         )
      );
}

Controller Level

MVC 와 동일하게 @ExceptionHandler 어노테이션을 통해 error handling 이 가능하다.

@Controller public class SimpleController { 
    // ... 

    @ExceptionHandler 
    public ResponseEntity<String> handle(IOException ex) { 
         // ... 
    } 
}

⚠️ Spring WebFlux 에서 @ExceptionHandler 를 사용할 경우 request body나 @ModelAttribute에 관련된 매개변수와 반환 값은 사용 불가능하다.

Global Level

WebExceptionHandler 를 정의하여 Bean 으로 등록하면 모든 요청에 대한 Exception Handling 이 가능하다.
Spring WebFlux 에서는 아래의 WebExceptionHandler 구현체를 제공한다.
- ResponseStatusExceptionHandler : ResponseStatusException 유형에 대한 예외 처리
- WebFluxResponseStatusExceptionHandler : @ResponseStatus 가 선언된 경우에 대한 예외처리. ResponseStatusExceptionHandler의 확장
- DefaultErrorWebExceptionHandler : Exception Handle 에 대한 기본적인 기능 제공
직접 WebExceptionHandler 를 구현하고 싶다면 AbstractErrorWebExceptionHandler 나 DefaultErrorWebExceptionHandler 를 상속받아 커스터마이징 하여 Bean 으로 등록한다.

@Component
@Order(-2)
public class GlobalErrorWebExceptionHandler extends 
    AbstractErrorWebExceptionHandler {

    // constructors

    @Override
    protected RouterFunction<ServerResponse> getRoutingFunction(
      ErrorAttributes errorAttributes) {

        return RouterFunctions.route(
          RequestPredicates.all(), this::renderErrorResponse);
    }

    private Mono<ServerResponse> renderErrorResponse(
       ServerRequest request) {

       Map<String, Object> errorPropertiesMap = getErrorAttributes(request, 
         ErrorAttributeOptions.defaults());

       return ServerResponse.status(HttpStatus.BAD_REQUEST)
         .contentType(MediaType.APPLICATION_JSON)
         .body(BodyInserters.fromValue(errorPropertiesMap));
    }
}

⚠️ Spring WebFlux 에서는 DefaultErrorWebExceptionHandler 가 @Order(-1) 로 등록이 되기 때문에 DefaultErrorWebExceptionHandler 보다 먼저 error handling 을 하려면 @Order(-2) 를 정의해야한다.

에러 응답에 대한 정의만 필요하다면, ErrorAttributes 혹은 DefaultErrorAttributes 를 상속받은 구현체를 Bean 으로 정의하는 방법도 있다.

@Component
public class GlobalErrorAttributes extends DefaultErrorAttributes {
    
    @Override
    public Map<String, Object> getErrorAttributes(ServerRequest request, 
      ErrorAttributeOptions options) {
        Map<String, Object> map = super.getErrorAttributes(
          request, options);
        map.put("status", HttpStatus.BAD_REQUEST);
        map.put("message", "username is required");
        return map;
    }

}

Spring Webflux - Server Configuration

흥부가귀막혀 — Mon, 14 Mar 2022 13:06:13 +0900

Server Configuration

@EnableWebFlux

@EnableWebFlux 어노테이션을 정의할 경우 DelegatingWebFluxConfiguration 이 동작하는데 해당 Configuration 이 수행하는 기능은 다음과 같다.
- WebFlux Application 운영을 위한 default spring configuration 을 정의해준다.
- WebFluxConfigurer 를 정의한 configuration 이 있는지 탐지 및 customizing 된 내용 적용.

@Configuration
@EnableWebFlux
public class WebConfig {

    // ...
}

만약 @EnableWebFlux 를 사용하지 않고 직접 핸들링 하고 싶다면, DelegatingWebFluxConfiguration 을 직접 정의하는 방법도 있다.

@Configuration
public class WebConfig extends DelegatingWebFluxConfiguration {

    // ...
}

WebFluxConfigurer

WebFlux Server side 에 대해 사용자가 정의할 수 있는 옵션을 제공한다.
WebFluxConfigurer 가 동작하기 위해서는 @EnableWebFlux 가 어딘가 선언되어 있어야 한다.
WebFluxConfigurer 에서 지원하는 옵션은 다음과 같다.
- addFormatters(FormatterRegistry registry) : Conversion, formatting 관련 옵션
- Validator getValidator() : 전역 Validator 정의
- configureContentTypeResolver(RequestedContentTypeResolverBuilder builder) : 요청 media type 에 대한 resolver 정의. default 는 accept header 를 체크하지만 필요에 따라 parameter base 의 resolver 정의도 가능하다.
- configureHttpMessageCodecs(ServerCodecConfigurer configurer) : request, response read/write 에 관련된 codec 설정 정의. 요청 파라미터 body 사이즈를 256kb 이상 늘리고 싶다면 WebClient 에서 언급되었던 MaxInMemorySize 설정과 동일하게 설정해준다.
- configureViewResolvers(ViewResolverRegistry registry) : view resolver 를 정의. 상세 설정 방법은 spring doc 참고.
- addResourceHandlers(ResourceHandlerRegistry registry) : static resource 에 대한 handler 정의. 각 케이스별 상세 설정은 spring doc 참고.
- configurePathMatch(PathMatchConfigurer configurer) : path matching 에 대한 사용자 옵션을 정의. 옵션에 대한 자세한 사항은 PathMatchConfigurer 참고
- addCorsMappings(CorsRegistry registry) : Cors 에 대한 전역 설정 정의.
- getWebSocketService() : WebSocket Handling 을 위한 WebSocketService 를 정의.

CORS

WebFluxConfigurer 의 addCorsMappings 을 설정하거나 CorsFilter 를 bean 으로 정의하면 전역 CORS 지원이 가능하다.

WebFluxConfigurer 설정

@Configuration
@EnableWebFlux
public class WebConfig implements WebFluxConfigurer {

    @Override
    public void addCorsMappings(CorsRegistry registry) {

        registry.addMapping("/api/**")
            .allowedOrigins("https://domain2.com")
            .allowedMethods("PUT", "DELETE")
            .allowedHeaders("header1", "header2", "header3")
            .exposedHeaders("header1", "header2")
            .allowCredentials(true).maxAge(3600);

        // Add more mappings...
    }
}

CorsFilter 설정

@Bean
CorsWebFilter corsFilter() {

    CorsConfiguration config = new CorsConfiguration();

    // Possibly...
    // config.applyPermitDefaultValues()

    config.setAllowCredentials(true);
    config.addAllowedOrigin("https://domain1.com");
    config.addAllowedHeader("*");
    config.addAllowedMethod("*");

    UrlBasedCorsConfigurationSource source = new UrlBasedCorsConfigurationSource();
    source.registerCorsConfiguration("/**", config);

    return new CorsWebFilter(source);
}

CORS 에 대한 custom 한 동작이 필요하다면 CorsConfiguration 를 구현하면 된다. 예를들어 domain 의 allow origin check 를 ant pattern 이나 정규표현식 방식으로 check 하고 싶다면 CorsConfiguration 의 checkOrigin 을 구현하면 된다.

Netty TcpServer

NettyServerCustomizer 를 구현하여 Netty TcpServer 에 대한 옵션 정의가 가능하다.
TcpServer 에 설정가능한 옵션은 다음과 같다.(옵션 종류는 ChannelOption 에 필드로 정의되어있다.)
- SO_BACKLOG
- SO_KEEPALIVE
- SO_REUSEADDR
- SO_LINGER
- SO_RCVBUF
- SO_SNDBUF
- SO_TIMEOUT
- TCP_NODELAY
TcpServer 에 대한 metric 을 활성화 하고 싶다면, TcpServer.metrics(boolean) 함수를 호출하면 된다.

public class EventLoopNettyCustomizer implements NettyServerCustomizer {

    @Override
    public HttpServer apply(HttpServer httpServer) {
        EventLoopGroup parentGroup = new NioEventLoopGroup();
        EventLoopGroup childGroup = new NioEventLoopGroup();
        return httpServer.tcpConfiguration(tcpServer -> { // 필요한 설정 변경 수행 });
    }
}

⚠️ Reactor Netty 의 selector, worker thread 수도 NettyServerCustomizer 를 통해 설정할 수 있는것 같지만, 실제로 해보면 적용이 안된다.
그 이유는 selector, worker thread 는 http server 를 생성할 때 정의해야 하는데 실제 http server 를 생성하는 NettyReactiveWebServerFactory 에서 http server 를 생성한 뒤에 customizer 를 호출하도록 되어있기 때문에 여기서 설정을 해봤자 변경되지 않는다.
selector, worker thread 를 변경하기 위해선 NettyReactiveWebServerFactory 를 통해 ReactorResourceFactory 를 정의해 loopResources 를 셋팅해주거나 ReactorNetty 에 정의된 환경변수를 application 실행시 정의해주어야 한다.

NettyServerCustomizer 구현체를 Bean 으로 등록하거나 NettyReactiveWebServerFactory 을 Bean 으로 등록하고 이때 NettyServerCustomizer 를 등록하면 된다.

@Configuration
@EnableWebFlux
public class WebConfig {

    @Bean
    public EventLoopNettyCustomizer eventLoopNettyCustomizer() {
        return new EventLoopNettyCustomizer();
    }
}

@Configuration
@EnableWebFlux
public class WebConfig {

    @Bean
    public NettyReactiveWebServerFactory nettyReactiveWebServerFactory() {
        NettyReactiveWebServerFactory webServerFactory = new NettyReactiveWebServerFactory();
        webServerFactory.addServerCustomizers(new EventLoopNettyCustomizer());
        return webServerFactory;
    }
}

SSL, Http2 와 관련된 설정을 하고자 한다면, WebServerFactoryCustomizer 를 직접 정의하면 된다.

@Component
public class NettyWebServerFactorySslCustomizer 
  implements WebServerFactoryCustomizer<NettyReactiveWebServerFactory> {

    @Override
    public void customize(NettyReactiveWebServerFactory serverFactory) {
        Ssl ssl = new Ssl();
        ssl.setEnabled(true);
        ssl.setKeyStore("classpath:sample.jks");
        ssl.setKeyAlias("alias");
        ssl.setKeyPassword("password");
        ssl.setKeyStorePassword("secret");
        Http2 http2 = new Http2();
        http2.setEnabled(false);
        serverFactory.addServerCustomizers(new SslServerCustomizer(ssl, http2, null));
        serverFactory.setPort(8443);
    }
}

Spring Webflux - WebClient

흥부가귀막혀 — Mon, 14 Mar 2022 12:55:31 +0900

WebClient

생성

create

WebClient 는 간단하게 static 메서드로 생성이 가능하다.
static method 로 생성할 경우 디폴트로 Reactor Netty HttpClient 를 사용하므로 reactor-netty 라이브러리에 대한 의존성이 필요하다.

WebClient webClient1 = WebClient.create();
WebClient webClient2 = WebClient.create("http://naver.com");

builder

몇가지 옵션을 설정하려면 builder 를 사용하여 생성하는것을 권장한다.
- uriBuilderFactory: base URL 과 관련하여 UriBuilderFactory 를 커스텀하게 구현했을 경우.
- defaultUriVariables: 모든 요청에 핸들링 가능한 URI variable 설정.
- defaultHeader: 모든 요청에 사용할 header 설정.
- defaultCookie: 모든 요청에 사용할 cookie 설정.
- defaultRequest: 모든 요청의 request 를 커스터마이징 하는 설정.
- filter: 모든 요청의 filter 설정.
- exchangeStrategies: HTTP message reader/writer 의 커스터마이징 설정.
- clientConnector: HTTP client library 설정.

WebClient client = WebClient.builder()
      .exchangeStrategies(builder -> {
              return builder.codecs(codecConfigurer -> {
                  //...
              });
      })
      .build();

WebClient 는 한번 build 를 수행하면 상태를 변경할 수 없다. 기존 WebClient 에 설정을 변경하고 싶다면, mutate() 함수를 통해 복제를 하여 설정을 추가한다.

WebClient client1 = WebClient.builder()
      .filter(filterA).filter(filterB).build();

WebClient client2 = client1.mutate()
      .filter(filterC).filter(filterD).build();

중요한 Configuration

Connection

WebClient 에서 사용할 Connection 관련 설정은 ConnectionProvider.Builder 를 통해 설정하여 ConnectionProvider 를 생성한 뒤 Reactor Netty HttpClient 생성시 주입하면 된다.
ConnectionProvider.Builder 를 통해 설정할 수 있는 Connection 관련 설정은 다음과 같다.
- evictInBackground : background thread 가 connection 종료 체크를 얼마나 자주 할건지에 대한 설정.
- maxConnections : max connection 수. WebClient 에서 connection 수 이상의 요청을 하게될 경우 queue 에 들어가 대기하게 된다.
- pendingAcquireMaxCount : connection 이 없을 때 queue 에 요청을 담을 최대 갯수. -1 로 설정할 경우 제한 없음.
- pendingAcquireTimeout : connection 이 없어 queue 에 담아놓을 시간(단위: ms).
- maxIdleTime : connection 의 최대 idle time(단위: ms). -1 일 경우 제한 없음.
- maxLifeTime : connection 의 최대 life time(단위: ms). -1 일 경우 제한 없음.
- getLeasingStrategy : Connection Acquire operation 수행시 connection 대여 전략. fifo, lifo 가 있다.(default: fifo)
- metrics : Connection 관련 metric 활성화 여부. 활성화를 할 경우 /actuator/metrics 를 통해 metric 확인 가능.

ConnectionProvider.Builder connectionProviderBuilder = ConnectionProvider.builder(name);
// 설정 수행
...
HttpClient httpClient = HttpClient.create(connectionProviderBuilder.build());

WebClient webClient = WebClient.builder()
      .clientConnector(new ReactorClientHttpConnector(httpClient))
      .build();

MaxInMemorySize

스프링 웹플럭스는 어플리케이션 메모리 이슈를 방지하기 위해 코덱의 메모리 버퍼 사이즈를 제한한다. 디폴트는 256KB로 설정돼 있는데, 버퍼가 부족하면 다음과 같은 에러가 발생한다.

org.springframework.core.io.buffer.DataBufferLimitException: Exceeded limit on max bytes to buffer

codec 설정을 통해 MaxInMemorySize 를 수정할 수 있다.
-1 로 설정할 경우 무제한으로 설정된다.

WebClient webClient = WebClient.builder()
      .exchangeStrategies(builder ->
          builder.codecs(codecs ->
              codecs.defaultCodecs().maxInMemorySize(2 * 1024 * 1024)
          )
      )
      .build();

Timeout

Connect, Read/Write Timeout 은 Reactor Netty HttpClient 생성을 통해 다음과 같이 설정할 수 있다.

import io.netty.channel.ChannelOption;

HttpClient httpClient = HttpClient.create()
      .tcpConfiguration(client ->
              client.option(ChannelOption.CONNECT_TIMEOUT_MILLIS, 10000)
                    .doOnConnected(conn -> conn.addHandlerLast(new ReadTimeoutHandler(10000, TimeUnit.MILLISECONDS))
					       .addHandlerLast(new WriteTimeoutHandler(10000, TimeUnit.MILLISECONDS))));

WebClient webClient = WebClient.builder()
      .clientConnector(new ReactorClientHttpConnector(httpClient))
      .build();

Secure

타겟 서버의 ssl 인증서 체크를 무시하고자 한다면 아래와 같이 설정한다.

HttpClient httpClient = HttpClient.create()
	.secure(
		sslContextSpec -> {
			try {
				sslContextSpec.sslContext(
					SslContextBuilder.forClient()
						.trustManager(InsecureTrustManagerFactory.INSTANCE)
						.build()
				);
			} catch (SSLException e) {
				throw new ServiceException("Insecure sslContext create fail.", e);
			}
		}
	);

WebClient webClient = WebClient.builder()
      .clientConnector(new ReactorClientHttpConnector(httpClient))
      .build();

Metric

WebClient 의 요청 url 별로 metric 을 얻고 싶다면 Reactor Netty HttpClient 생성시 metrics 함수를 통해 metric 활성화 및 url 별 tag 설정을 해준다.
tag 설정이 되었다면 /actuator/metrics/{http.client.metric.key}?tag=key:value 형태로 요청하여 tag 에 맞는 metric 조회가 가능하다.

HttpClient httpClient = HttpClient.create()
	.metrics(properties.isMetricsEnabled(), uri -> {
		// uri 별 tag name 정의
		return "my-api";
	})

WebClient webClient = WebClient.builder()
      .clientConnector(new ReactorClientHttpConnector(httpClient))
      .build();

Request Body

Mono, Flux 를 통해 비동기적으로 request body serialize & write 가 가능하다

Mono<Person> personMono = ... ;

Mono<Void> result = client.post()
      .uri("/persons/{id}", id)
      .contentType(MediaType.APPLICATION_JSON)
      .body(personMono, Person.class)
      .retrieve()
      .bodyToMono(Void.class);

비동기적으로 하지 않아도 된다면, bodyValue 함수를 사용한다.

Person person = ... ;

Mono<Void> result = client.post()
      .uri("/persons/{id}", id)
      .contentType(MediaType.APPLICATION_JSON)
      .bodyValue(person)
      .retrieve()
      .bodyToMono(Void.class);

form data 의 경우 MultiValueMap<String, String> 형태로 bodyValue 를 호출하거나, BodyInserters 를 사용한다.

// bodyValue 사용
MultiValueMap<String, String> formData = ... ;

Mono<Void> result = client.post()
      .uri("/path", id)
      .bodyValue(formData)
      .retrieve()
      .bodyToMono(Void.class);

// BodyInserters 사용
Mono<Void> result = client.post()
      .uri("/path", id)
      .body(BodyInserters.fromFormData("k1", "v1").with("k2", "v2"))
      .retrieve()
      .bodyToMono(Void.class);

⚠️ Form Data 를 보낼 경우 FormHttpMessageWriter 에서 자동으로 Content-Type 을 application/x-www-form-urlencoded 으로 정의하기 때문에 contentType 함수를 사용해서 정의하지 않아도 된다.

Request & Response Handle

retrive()

retrive() 는 response body 를 받아 디코딩하는 간단한 함수이다.
4xx, 5xx 응답 코드를 받으면 디폴트는 WebClientResponseException 또는 각 HTTP 상태에 해당하는 WebClientResponseException.BadRequest, WebClientResponseException.NotFound 등의 하위 exception을 던진다.
http status 별 핸들링을 다르게 하고 싶다면 onStatus 메소드로 커스텀할 수도 있다.

Mono<Person> result = client.get()
      .uri("/persons/{id}", id).accept(MediaType.APPLICATION_JSON)
      .retrieve()
      .onStatus(HttpStatus::is4xxClientError, response -> ...)
      .onStatus(HttpStatus::is5xxServerError, response -> ...)
      .bodyToMono(Person.class);

⚠️ response body 가 있을 경우 onStatus 에서 소비하지 않으면 onStatus 호출 이후 response body 가 리소스 반환을 위해 비워지기 때문에 response body 를 볼 수 없게 된다. onStatus 를 사용하게 될 경우 response body 도 반드시 소비해야한다.

exchange()

직접 ClientResponse 를 핸들링 해야할 필요가 있다면 exchange() 함수를 통해 요청한다.
exchange() 함수는 retrive() 함수와는 다르게 4XX, 5XX http status 에 대해 자동으로 에러 응답을 주지 않는다. 사용자가 직접 http status 를 확인하고 핸들링 하는 로직을 구현해야한다.

특정 model 객체로 변환시

Mono<Person> result = client.get()
      .uri("/persons/{id}", id).accept(MediaType.APPLICATION_JSON)
      .exchange()
      .flatMap(response -> response.bodyToMono(Person.class));

ResponseEntity 로 변환시

Mono<ResponseEntity<Person>> result = client.get()
      .uri("/persons/{id}", id).accept(MediaType.APPLICATION_JSON)
      .exchange()
      .flatMap(response -> response.toEntity(Person.class));

⚠️ retrieve()와는 다르게 exchange()는 모든 시나리오에서(성공, 오류, 예기치 못한 데이터 등) 어플리케이션이 직접 response body를 컨슘해야 한다. 그렇지 않으면 메모리 릭이 발생할 수 있다. ClientResponse javadoc을 참고하면 body를 컨슘할 수 있는 모든 옵션이 나와 있다.

Spring Webflux - Filter

흥부가귀막혀 — Mon, 14 Mar 2022 12:53:03 +0900

Filter

Spring Webflux 에서는 MVC 의 Interceptor 와 비슷한 역할을 하는 HandlerFilterFunction 과 Servlet Filter 와 비슷한 역할을 하는 WebFilter Interface 를 제공하고 있다.

HandlerFilterFunction

핸들러 펑션에 필터를 적용할 땐 RouterFunction Builder 를 사용하면 되는데, 다음과 같은 함수가 있다.
- before : Handler 함수 수행 전에 동작하는 함수를 등록하며 인자로 Function<ServerRequest, ServerRequest> 를 받는다.
- after : Handler 함수가 수행 완료되면 동작하는 함수를 등록하며 인자로 BiFunction<ServerRequest, ServerResponse, ServerResponse> 를 받는다.
- filter : 인자로 HandlerFilterFunction<ServerRequest, ServerResponse> 를 받으며, 필터를 어떻게 수행하고 다음 handler function 을 어떻게 호출할지의 일련의 동작을 모두 구현할 수 있다.
필터는 빌더의 모든 라우터 펑션에 적용된다. 이 말은 필터를 감싸져 있는 라우터에서 정의하면, 상위 레벨에는 적용되지 않는다는 뜻이다.

RouterFunction<ServerResponse> route = RouterFunctions.route()
    .path("/person", b1 -> b1
        .nest(RequestPredicates.accept(APPLICATION_JSON), b2 -> b2
            .GET("/{id}", handler::getPerson)
            .GET("", handler::listPeople)
            .before(request -> ServerRequest.from(request) // (1) 
                .header("X-RequestHeader", "Value")
                .build()))
        .POST("/person", handler::createPerson))
    .after((request, response) -> logResponse(response)) // (2) 
    .build();

(1) X-RequestHeader 를 추가하는 filter 는 두 GET Router 에만 적용되며 Router 실행 전에 수행된다.
(2) response 를 logging 하는 filter 는 모든 Router 에 적용되며 Router 실행 후 수행된다.

filter 메소드는 HandlerFilterFunction을 인자로 받는다. 이 인터페이스는 ServerRequest, HandlerFunction을 받아 ServerResponse를 리턴하는 함수다. 두번째 인자로 받는 HandlerFunction 파라미터는 체인에 있는 다음 HandlerFunction 이다. 보통 이 HandlerFunction 은 라우팅할 핸들러지만, HandlerFilterFunction 이 여러 개가 등록되어있다면 HandlerFilterFunction 일 수도 있다.
path를 보고 요청을 허가할지 말지 결정하는 SecurityManager가 있다고 가정하고, filter 함수를 통해 보안 필터를 라우터에 적용해 보면 다음과 같다.

SecurityManager securityManager = ...

RouterFunction<ServerResponse> route = RouterFunctions.route()
    .path("/person", b1 -> b1
        .nest(RequestPredicates.accept(APPLICATION_JSON), b2 -> b2
            .GET("/{id}", handler::getPerson)
            .GET("", handler::listPeople))
        .POST("/person", handler::createPerson))
    .filter((request, next) -> {
        if (securityManager.allowAccessTo(request.path())) {
            return next.handle(request);
        }
        else {
            return ServerResponse.status(UNAUTHORIZED).build();
        }
    })
    .build();

위 예제를 보면 next.handle(ServerRequest) 호출은 선택이라는 점을 알 수 있다. 여기선 접근을 허가할 때만 실행했다.
⚠️ filter 를 구현하다보면 Request 객체에 attribute 나 header 등의 값을 주입하거나 변경해야할 때가 있는데, 그럴 때 ServerRequest.Builder 나 혹은 Builder 를 사용하는 API(from) 로 ServerRequest 를 새로 생성하여 변경할 경우 다음 HandlerFunction 에서 request body 를 가져올 수 없다. 반드시 주입받은 ServerRequest 를 다음 HandlerFunction 에 넘겨주도록 구현해야 한다.

WebFilter

WebFilter 를 구현하여 Bean 으로 등록(혹은 @Component Annotation 을 등록)하면 WebFilter 를 사용할 수 있다.
WebFilter 는 여러개가 등록 가능하며 순서를 맞추고자 한다면 @Order 를 사용한다.
아래는 Spring Webflux 에서 HttpHandler, ExceptionHandler, WebFlilter, DispatcherHandler 간의 동작 과정이다. FilteringWebHandler 부터 DefaultWebFilterChain 까지가 WebFilter 의 동작 부분이라 볼 수 있으며 Bean(혹은 @Component Annotation)으로 등록한 WebFliter 는 DefaultWebFilterChain 안에서 동작하게 된다.

⚠️ HandlerFilterFunction 은 위 동작에 포함되지 않으며 DispatcherHandler 수행시 동작하게 된다.

인증, ACL, Access Logging 과 같이 요청시 우선적으로 실행해야 하거나 HandlerFilterFunction 에 영향을 받지 않도록 하려면 WebFilter 를 구현하여 사용하는게 좋다.
Spring Webflux 에서 제공하는 대표적인 WebFilter 로 CorsFilter 가 있다.

Spring Webflux - HandlerFunction

흥부가귀막혀 — Mon, 14 Mar 2022 12:50:32 +0900

HandlerFunction

ServerRequest 를 받아 ServerResponse 를 리턴하는, MVC 의 Controller 와 유사한 로직을 구현하는 함수이다.
ServerRequest와 ServerResponse는 자바 8 방식으로 HTTP 요청과 응답에 접근할 수 있는 불변(immutable) 인터페이스다.
요청, 응답 body 모두 리액티브 스트림 back pressure로 처리한다. request body는 리액터 Flux나 Mono로 표현한다.
response body는 Flux와 Mono를 포함한 어떤 리액티브 스트림 Publisher든 상관없다. 자세한 정보는 Reactive Libraries 를 참고.

ServerRequest

ServerRequest로 HTTP 메소드, URI, 헤더, 쿼리 파라미터에 접근할 수 있으며, body를 추출할 수 있는 메소드를 제공한다.
query 파라미터 조회.

Optional<String> param = serverRequest.queryParam("param");

path variable 파라미터 조회.

String id = serverRequest.pathVariable("id");

RequestBody 를 Mono<String> 으로 추출.

Mono<String> string = request.bodyToMono(String.class);

RequestBody 를 Flux<Person>으로 추출한다. Person 객체는 JSON이나 XML 같은 직렬화된 데이터로 디코딩한다.

Flux<Person> people = request.bodyToFlux(Person.class);

bodyToMono, bodyToFlux 는 함수형 인터페이스 BodyExtractor를 받는 ServerRequest.body(BodyExtractor) 메소드의 축약 버전이다. BodyExtractors 유틸리티 클래스에 있는 인터페이스를 활용하여 위의 예제를 다음과 같이 사용할 수 있다.

Mono<String> string = request.body(BodyExtractors.toMono(String.class));
Flux<Person> people = request.body(BodyExtractors.toFlux(Person.class));

이밖에도 다음과 같은 목적에 맞게 request body 를 추출할 수 있는 API 가 제공된다.

form data 추출

Mono<MultiValueMap<String, String> map = request.formData();

multipart data 추출

Mono<MultiValueMap<String, Part> map = request.multipartData();

multiparts 를 streaming 으로 하나씩 추출할 때

Flux<Part> parts = request.body(BodyExtractors.toParts());

ServerResponse

HTTP 응답은 ServerResponse로 접근할 수 있으며, 이 인터페이스는 불변이기 때문에(immutable) build 메소드로 생성한다. 빌더로 헤더를 추가하거나, 상태 코드, body를 설정할 수 있다.
JSON 컨텐츠로 200 (OK) 응답

Mono<Person> person = ...
ServerResponse.ok().contentType(MediaType.APPLICATION_JSON).body(person, Person.class);

body 없이 Location 헤더로만 201 (CREATED) 응답

URI location = ...
ServerResponse.created(location).build();

hint 파라미터를 넘기면 사용하는 코덱에 따라 body 직렬화/역직렬화 방식을 커스텀할 수 있다. 아래 예는 Jackson JSON view를 지정하는 예제이다.

ServerResponse.ok().hint(Jackson2CodecSupport.JSON_VIEW_HINT, MyJacksonView.class).body(...);

Handler Classes

HandlerFunction 은 FunctionalInterface 로 정의되어있기 때문에 lamda 형태로 정의가 가능하다.

HandlerFunction<ServerResponse> helloWorld = request -> ServerResponse.ok().bodyValue("Hello World");

다만 HandlerFunction 로직이 복잡하거나 많을 경우 lamda 로 정의하는데 부담이 생기기 때문에 일반 class 에 함수를 정의하고 해당 함수를 handler function 으로 묶을 수 있다.

router

@Configuration
public class RouterConfig {

    @Bean
    public RouterFunction<?> personRouter(PersonRepository repository) {
        PersonHandler handler = new PersonHandler(repository);

        return RouterFunction<ServerResponse> route = route()
           .GET("/person/{id}", accept(APPLICATION_JSON), handler::getPerson)
           .GET("/person", accept(APPLICATION_JSON), handler::listPeople)
           .POST("/person", handler::createPerson)
           .build();
    }
}

handler class

import static org.springframework.http.MediaType.APPLICATION_JSON;
import static org.springframework.web.reactive.function.server.ServerResponse.ok;

public class PersonHandler {

    private final PersonRepository repository;

    public PersonHandler(PersonRepository repository) {
        this.repository = repository;
    }

    public Mono<ServerResponse> listPeople(ServerRequest request) { // (1)
        Flux<Person> people = repository.allPeople();
        return ok().contentType(APPLICATION_JSON).body(people, Person.class);
    }

    public Mono<ServerResponse> createPerson(ServerRequest request) { // (2)
        Mono<Person> person = request.bodyToMono(Person.class);
        return ok().build(repository.savePerson(person));
    }

    public Mono<ServerResponse> getPerson(ServerRequest request) { // (3)
        int personId = Integer.valueOf(request.pathVariable("id"));
        return repository.getPerson(personId)
            .flatMap(person -> ok().contentType(APPLICATION_JSON).bodyValue(person))
            .switchIfEmpty(ServerResponse.notFound().build());
    }
}

(1) listPeople은 레포지토리에 있는 모든 Person 객체를 JSON으로 반환하는 핸들러 펑션이다.
(2) createPerson은 request body에 있는 Person을 저장하는 핸들러 펑션이다. PersonRepository.savePerson(Person)은 Mono<Void>를 리턴한다는 점에 주의해라. 비어 있는 Mono는 요청 데이터를 읽어 저장하고 나면 완료됐다는 신호를 보낸다. 따라서 이 신호를 받았을 때(즉, Person이 저장됐을 때) 응답을 보내기 위해 build(Publisher<Void>)를 사용한다.
(3) getPerson은 path variable에 있는 id로 식별한 person 객체 하나를 리턴하는 핸들러 펑션이다. 레포지토리에서 Person을 찾으면 JSON 응답을 만든다. 찾지 못했다면 switchIfEmpty(Mono<T>)를 실행해 404 Not Found로 응답한다.

Validation

함수형 엔드포인트는 스프링 validation facilities를 사용해서 request body를 검증할 수 있다.
다음 예제는 커스텀 스프링 Validator 구현체로 person을 검증한다

public class PersonHandler {

    private final Validator validator = new PersonValidator(); // (1) 

    // ...

    public Mono<ServerResponse> createPerson(ServerRequest request) {
        Mono<Person> person = request.bodyToMono(Person.class).doOnNext(this::validate); // (2) 
        return ok().build(repository.savePerson(person));
    }

    private void validate(Person person) {
        Errors errors = new BeanPropertyBindingResult(person, "person");
        validator.validate(person, errors);
        if (errors.hasErrors()) {
            throw new ServerWebInputException(errors.toString()); // (3) 
        }
    }
}

(1) Validator 인스턴스를 생성한다.
(2) 검증 로직을 실행한다.
(3) 400으로 응답하는 exception을 발생시킨다.

Spring Webflux - Request Mapping

흥부가귀막혀 — Mon, 14 Mar 2022 12:48:09 +0900

Request Mapping

Spring Webflux 에선 아래와 같이 2가지 programming model 이 있고 그에 맞게 Request Mapping 을 해줄 수 있다.

Annotated Controllers

스프링 MVC와 동일하며 spring-web 모듈에 있는 같은 어노테이션을 사용한다. 스프링 MVC와 웹플럭스 컨트롤러 모두 리액티브(Reactor, RxJava) 리턴 타입을 지원하기 때문에 이 둘을 구분하기 어렵다. 한 가지 눈에 띄는 차이는 웹플럭스에선 @RequestBody로 리액티브 인자를 받을 수 있다.
스프링 웹플럭스는 어노테이션 기반 프로그래밍 모델을 지원하기 때문에, @Controller, @RestController 컴포넌트로 요청을 매핑하고, 입력을 받고, exception을 처리할 수 있다.
컨트롤러는 메소드를 여러 가지로 활용할 수 있어서 클래스를 상속하거나 인터페이스를 구현하지 않아도 된다.

@RestController
public class HelloController {

    @GetMapping("/hello")
    public Mono<String> handle(@RequestBody Mono<String> request) {
        return request.map(name -> "Hello Webflux. My name is " + name);
    }
}

Functional Endpoints

스프링 웹플럭스는 경량화된 함수형 프로그래밍 모델을 지원한다. WebFlux.fn이라고도 하는 이 모델은, 함수로 요청을 라우팅하고 핸들링하기 때문에 불변성(Immutablility)을 보장한다.
WebFlux.fn에선 HandlerFunction이 HTTP 요청을 처리한다. HandlerFunction은 ServerRequest를 받아 비동기 ServerResponse(i.e. Mono<ServerResponse>)를 리턴하는 함수다. 요청, 응답 객체 모두 불변(immutable)이기 때문에 JDK 8 방식으로 HTTP 요청, 응답에 접근할 수 있다. HandlerFunction 역할은 어노테이션 프로그래밍 모델로 치면 @RequestMapping 메소드가 하던 일과 동일하다.
요청은 RouterFunction이 핸들러 펑션에 라우팅한다. RouterFunction은 ServerRequest를 받아 비동기 HandlerFunction(i.e. Mono<HandlerFunction>)을 리턴하는 함수다. 매칭되는 라우터 펑션이 있으면 핸들러 펑션을 리턴하고 그 외는 비어있는 Mono를 리턴한다. RouterFunction이 하는 일은 @RequestMapping 어노테이션과 동일하지만, 라우터 펑션은 데이터뿐 아니라 행동까지 제공한다는 점이 다르다.
라우터를 만들 때는 아래 예제처럼 RouterFunctions.route()가 제공하는 빌더를 사용할 수 있다.
RouterFunction을 실행하는 방법 중 하나는 HttpHandler로 변환해 내장된 서버 어댑터에 등록하는 것인데, 라우터를 bean 으로 등록하면 Spring 에서 이러한 처리를 자동으로 해준다.

@Configuration
public class RouterConfig {

    @Bean
    public RouterFunction<?> personRouter(PersonHandler handler) {
        return RouterFunction<ServerResponse> route = RouterFunctions.route()
           .GET("/person/{id}", RequestPredicates.accept(APPLICATION_JSON), handler::getPerson)
           .GET("/person", RequestPredicates.accept(APPLICATION_JSON), handler::listPeople)
           .POST("/person", handler::createPerson)
           .build();
    }

    @Bean
    public RouterFunction<?> routerFunctionB() {
        // ...
    }
}

RouterFunction

라우터 펑션은 요청을 그에 맞는 HandlerFunction으로 라우팅한다.
라우터 펑션을 직접 만들기보단, 보통 RouterFunctions 유틸리티 클래스를 사용한다.
RouterFunctions.route()가 리턴하는 빌더를 사용하거나, RouterFunctions.route(RequestPredicate, HandlerFunction)으로 직접 라우터를 만들 수 있다.

Predicates

RequestPredicate를 직접 만들어도 되지만, 요청 path, HTTP 메소드, 컨텐츠 타입 등 자주 사용하는 구현체는 RequestPredicates 유틸리티 클래스에 준비돼 있다.
다음은 유틸리티 클래스로 Accept 헤더 조건을 추가하는 예제다.

RouterFunction<ServerResponse> route = RouterFunctions.route()
    .GET("/hello-world", RequestPredicates.accept(MediaType.TEXT_PLAIN),
        request -> ServerResponse.ok().bodyValue("Hello World")).build();

and, or 조건을 걸 수 있다.
- requestPredicate.and(RequestPredicate other) : requestPredicate 와 other predicate 가 둘다 만족해야한다.
- requestPredicate.or(RequestPredicate other) : requestPredicate 와 other predicate 중 1개만 만족해도 된다.
RequestPredicates 가 제공하는 함수는 위의 and 와 or 를 조합해서 만든 것이 많다. 예를 들어 RequestPredicates.GET(String) API 는 내부적으로 RequestPredicates.method(Method) 와 RequestPredicates.path(String) 을 and 로 연결시켰다고 생각하면 된다.

Routes

라우터 펑션은 정해진 순서대로 실행한다. 첫 번째 조건과 일치하지 않으면 두 번째를 실행하는 식이다. 따라서 구체적인 조건을 앞에 선언해야 한다. 어노테이션 프로그래밍 모델(Spring MVC)에선 자동으로 가장 구체적인 컨트롤러 메소드를 실행하지만, 함수형 모델에선 그렇지 않다 점에 주의해야한다.
build()를 호출하면 빌더에 정의한 모든 라우터 펑션을 RouterFunction 한 개로 합친다. 다음 방법으로도 여러 라우터 펑션을 조합할 수 있다.
- RouterFunctions.route() 빌더의 add(RouterFunction)
- RouterFunction.and(RouterFunction)
- RouterFunction.andRoute(RequestPredicate, HandlerFunction) — RouterFunctions.route()를 RouterFunction.and()로 감싸고 있는 축약 버전

@Configuration
public class RouterConfig {

    @Bean
    public RouterFunction<?> personRouter(PersonHandler handler) {
        return RouterFunction<ServerResponse> route = RouterFunctions.route()
           .GET("/person/{id}", RequestPredicates.accept(APPLICATION_JSON), handler::getPerson) // (1)
           .GET("/person", RequestPredicates.accept(APPLICATION_JSON), handler::listPeople) // (2)
           .POST("/person", handler::createPerson) // (3)
           .add(otherRoute) // (4)
           .build();
    }
}

(1) Accept 헤더가 JSON인 GET /person/{id}는 PersonHandler.getPerson으로 라우팅한다.
(2) Accept 헤더가 JSON인 GET /person은 PersonHandler.listPeople로 라우팅한다.
(3) POST /person은 다른 조건 없이 PersonHandler.createPerson로 라우팅한다.
(4) 마지막으로 나머지 요청을 처리할 otherRoute 펑션을 route에 추가한다.

Nested Routes

path가 같으면 대부분 같은 조건을 사용하므로, 라우터 펑션을 그룹핑하는 경우가 많다. 위의 Routes 예제는 라우터 펑션 세 개가 /person을 path 조건으로 사용했다.
어노테이션을 사용했다면 클래스 레벨에 @RequestMapping을 선언해 중복 코드를 줄였을 거다.
WebFlux.fn 에선 공통 조건을 가지고있는 RouterFunction 을 공유하기 위해 Builder 를 받는 Consumer 인터페이스를 활용하도록 하고있다.
위의 Routes 에 나온 예제를 아래와 같이 변경 가능하다.

RouterFunction<ServerResponse> route = RouterFunctions.route()
    .path("/person", builder -> builder // (1)
        .GET("/{id}", RequestPredicates.accept(APPLICATION_JSON), handler::getPerson)
        .GET("", RequestPredicates.accept(APPLICATION_JSON), handler::listPeople)
        .POST("/person", handler::createPerson))
    .add(otherRoute)
    .build();

(1) path 가 /person 인 조건의 RouterFunction 에 Builder 를 받는 Consumer 를 구현하여 분기처리를 하고있다.

builder 에서 제공하는 nest 함수를 활용하면 하위 RouterFunction 에 다른 공통 조건도 추가가 가능하다. 위 예에서 /person/{id}' 와 /person` 의 accept 조건이 같으므로 다음과 같이 변경이 가능하다.

RouterFunction<ServerResponse> route = RouterFunctions.route()
    .path("/person", b1 -> b1
        .nest(RequestPredicates.accept(APPLICATION_JSON), b2 -> b2
            .GET("/{id}", handler::getPerson)
            .GET("", handler::listPeople))
        .POST("/person", handler::createPerson))
    .add(otherRoute)
    .build();

Spring Webflux - Overview

흥부가귀막혀 — Mon, 14 Mar 2022 12:36:08 +0900

Spring Webflux 란?

Spring 5.0 버전부터 추가된 리액티브 스택 웹 프레임워크다.
완벽하게 non-blocking 으로 동작하며, Reactive Streams back pressure를 지원하고, Netty, Undertow, 서블릿 3.1+ 컨테이너 서버에서 실행된다.
기존 Spring MVC 와 같이 Spring Framework 에 공존하고 MVC 를 사용하며 Webflux 개발을 하는것도 가능하다.

Spring Webflux 는 왜 만들어졌나?

적은 쓰레드로 동시 처리를 제어하고 적은 하드웨어 리소스로 확장하기 위한 논블로킹 웹 스택의 필요성이 대두됨.
이전에도 서블릿 3.1 은 논블로킹 I/O를 위한 API를 제공했지만, 서블릿으로 논블로킹을 구현하려면 다른 동기 처리나(Filter, Servlet) 블로킹 방식(getParameter, getPart) 을 쓰는 API를 피해야 하지만 그렇게 하기가 어렵다. 이런 점 때문에 어떤 논블로킹과도 잘 동작하는 새 공통 API를 만들게 되었다. 이미 비동기 논블로킹 환경에서 자리를 잡은 서버(e.g. Netty) 때문에라도 새 API가 필요했다.
또 다른 이유로는 함수형 프로그래밍이 있다. 자바 5의 어노테이션 등장으로 선택의 폭이 넓어진 것처럼(어노테이션을 선언한 REST 컨트롤러나 유닛 테스트 등), 자바 8에서 추가된 람다 표현식덕분에 자바에서도 함수형 API를 작성할 수 있게 됐다. 이 기능은 논블로킹 어플리케이션을 만들 때도 요긴하게 쓰이며, 이제는 continuation-style API(CompletableFuture 와 ReactiveX 로 대중화된)로 비동기 로직을 선언적으로 작성할 수 있다. 프로그래밍 모델 관점에서 보면, 웹플럭스에서 어노테이션을 선언한 컨트롤러와 더불어 함수형 웹 엔드포인트를 사용할 수 있는 건 자바 8 덕분이다.

“리액티브” 는 무슨 뜻인가?

“리액티브”라는 용어는 변화에 반응하는 것을 중심에 두고 만든 프로그래밍 모델을 의미한다 (I/O 이벤트에 반응하는 네트워크 컴포넌트, 마우스 이벤트에 반응하는 UI 컨트롤러 등). 논블로킹은 작업을 기다리기보단 완료되거나 데이터를 사용할 수 있게 되면 반응하므로, 이 말대로면 논블로킹도 리액티브다.
스프링은 “리액티브”와 관련한 중요한 메커니즘이 하나 더 있는데, 논블로킹 back pressure다. 동기식 명령형(imperative) 코드에서 블로킹 호출은 호출자를 강제로 기다리게 하는 일종의 back pressure다. 논블로킹 코드에선, 프로듀셔 속도가 컨슈머 속도를 압도하지 않도록 이벤트 속도를 제어한다.
리액티브 스트림은 back pressure를 통한 비동기 컴포넌트 간의 상호작용을 정의한 간단한 스펙이다(자바 9에서도 채택했다). 예를 들어 데이터 레포지토리(Publisher 역할)가 데이터를 만들고, HTTP 서버(Subscriber 역할)로 이 데이터로 요청을 처리할 수 있다. 리액티브 스트림을 쓰는 주목적은 subscriber가 publisher의 데이터 생산 속도를 제어하는 것이다.

Reactive API

리액티브 스트림은 컴포넌트 상호 작용에서 중요한 역할을 한다. 하지만 이건 라이브러리와 기반 구조에 사용되는 컴포넌트엔 유용해도, 어플리케이션 API에서 다루기엔 너무 저수준이다. 어플리케이션은 비동기 로직을 만들기 위한 풍부한 고수준 함수형 API가 필요하다 (자바 8 스트림 API와 비슷하지만 컬렉션만을 위한 게 아니다). 이게 바로 리액티브 라이브러리가 하는 일이다.
Reactor는 스프링 웹플럭스가 선택한 리액티브 라이브러리다. 리액터는 Mono 와 Flux API 타입을 제공한다.
ReactiveX vocabulary of operators 에 정리된 풍부한 연산자를 사용해 데이터 시퀀스를 0~1개는 Mono, 0~N개는 Flux로 표현할 수 있다. 리액터는 리액티브 스트림 라이브러리이기 때문에 모든 연산자는 논블로킹 back pressure를 지원한다. 리액터는 특히 서버 사이드 자바에 초점을 두고 스프링과 긴밀히 협력해서 개발됐다.
웹플럭스는 Reactor 를 핵심 라이브러리로 사용하지만, 다른 리액티브 라이브러리를 써도 리액티브 스트림으로 상호작용할 수 있다. 웹플럭스 API의 일반적인 룰은, 순수한 Publisher를 입력으로 받아 내부적으로 리액터 타입으로 맞추고, 이걸 사용해서 Flux나 Mono를 반환한다. 따라서 어떤 Publisher든 입력으로 전달하고 연산할 수 있지만, 다른 리액티브 라이브러리를 사용하려면 출력 형식을 맞춰줘야 한다. 웹플럭스는 가능만 하다면 (e.g. 어노테이션을 선언한 컨트롤러) 투명한 방식으로 RxJava나 다른 리액티브 라이브러리에 맞게 바꿔준다. 자세한 내용은 Reactive Libraries를 참고.

❗ 리액티브 API와는 별개로 웹플럭스는 코틀린의 코루틴 API와도 사용할 수 있는데, 이를 사용하면 좀 더 명령적(imperative)인 프로그래밍이 가능하다.

Concurrency Model

스프링 MVC와 스프링 웹플럭스 둘 다 annotated controller를 사용할 수 있다는 점은 동일해도, 동시성 모델과 블로킹/쓰레드 기본 전략이 다르다.
스프링 MVC는 (그리고 일반적인 서블릿 어플리케이션이라면) 어플리케이션이 처리 중인 쓰레드가 잠시 중단될 수 있다(예를 들어 외부 서비스를 호출하면). 그렇기 때문에 서블릿 컨테이너는 이 블로킹을 대비에 큰 쓰레드 풀로 요청을 처리한다.
스프링 웹플럭스는 (그리고 일반적인 논블로킹 서버라면) 실행 중인 쓰레드가 중단되지 않는다는 전제가 있다. 따라서 논블로킹 서버는 작은 쓰레드 풀(이벤트 루프 워커)을 고정해놓고 요청을 처리한다.
Thread 는 Event 가 들어온 순서대로 로직들을 처리하게 되며 요청 들어온 Event 가 각 Thread 에 골고루 분산되어 효율적으로 비지니스 로직이 실행되게 된다. 필요한 task 작업이 동시에 수행되는건 아니지만 Worker Thread 에 여유가 있다면 이에 준하는 성능으로 비지니스 로직이 동작하게 된다.