공부노트

OpenSSH의 ControlMaster, ControlPersist를 통한 연결 비용 최소화

Jaehee Jeon — Sun, 26 Apr 2026 16:50:18 +0900

ssh 커넥션을 자주 열고 닫는 환경에서는 매번 TCP 연결, 키 교환, 인증, 세션 초기화를 반복하는 비용이 꽤 크다.
이 글에서는 OpenSSH portable의 실제 구현을 참고하여 TCP 커넥션 위의 논리적인 SSH session과 channel을 OpenSSH가 어떻게 관리하고 재사용하는지 정리해 본다.

1. TCP connection, SSH session, channel의 관계

ssh를 쓰다 보면 “세션을 연다”, “커넥션을 유지한다”, “터널을 만든다” 같은 말을 섞어 쓰게 된다. 실제 구현을 볼 때는 이 단어들을 조금 분리해서 보는 편이 좋다.

먼저 전체 구조를 보면 대략 이렇다.

TCP connection
└─ SSH transport: 암호화, MAC, key exchange, rekey
   └─ SSH connection protocol
      ├─ channel 0: session:shell
      ├─ channel 1: direct-tcpip 또는 forwarded-tcpip
      ├─ channel 2: x11-connection
      └─ ...

이 구조를 위에서부터 내려오며 정리하면 다음과 같다.

TCP connection은 가장 바깥의 실제 네트워크 연결
ssh user@host를 실행하면 클라이언트는 서버의 22번 포트, 또는 설정된 포트로 TCP 연결을 만든다.
SSH transport는 TCP connection 위에 올라가는 암호화된 전송 계층
TCP 연결이 만들어진 뒤에는 SSH 버전 교환, key exchange, host key 검증, 사용자 인증이 진행된다. 여기까지 끝나면 “암호화되고 인증된 SSH 연결”이 준비된다. 이 글에서 이후 재사용된다고 말하는 핵심 대상도 바로 이 SSH transport connection이다.
SSH connection protocol은 그 위에 여러 channel을 올림
이 레이어에서 등장하는 핵심 추상화가 channel이다. OpenSSH 구현에서 channel은 로컬 fd, 원격 channel id, window size, max packet size, close 상태 등을 가진 하나의 논리 스트림으로 관리된다.
session은 channel의 한 종류
우리가 흔히 “터미널 세션”이라고 부르는 것은 보통 session 타입 channel이다. 즉 SSH 프로토콜 관점에서 session은 TCP connection이나 SSH transport와 같은 별도 계층이 아니라, channel type 중 하나로 보는 편이 정확하다. OpenSSH 코드에서 channel_new(..., "session", ...) 같은 호출을 볼 때도 “새로운 SSH 연결 전체를 만든다”기보다 “이미 만들어진 SSH connection 위에 session 타입 channel 하나를 연다”라고 읽는 것이 자연스럽다.
channel은 session만 있는 게 아님
일반적인 터미널 접속이나 원격 명령 실행은 session channel을 쓰지만, port forwarding은 direct-tcpip/forwarded-tcpip channel을 쓰고, X11 forwarding은 x11 계열 channel을 쓴다. 즉 하나의 SSH connection 위에는 목적이 다른 여러 논리 스트림이 함께 올라갈 수 있다.

session channel은 우리가 가장 자주 보는 형태다. 일반적인 ssh user@host 접속, ssh host command 실행, sftp 같은 subsystem 실행은 모두 이 session channel 위에서 shell, exec, subsystem, pty-req 같은 channel request를 보내는 식으로 구성된다. 다만 대부분의 사용자는 터미널 접속이나 원격 명령 실행을 통해 session 타입 channel을 가장 먼저 접하므로 기본 흐름은 session channel을 중심으로 설명한다.

이 구조를 이해하면 OpenSSH multiplexing이 무엇을 재사용할지가 명확해진다. multiplexing은 이미 인증까지 끝난 하나의 SSH transport connection을 마스터 프로세스가 유지하고, 이후의 ssh 실행은 그 위에 새 channel만 추가로 요청하는 방식이다.

2. 새 session channel 생성과 연결 비용의 반복

기본 옵션으로 다음 명령을 실행한다고 해보자.

ssh user@example.com

이 경우에는 보통 하나의 ssh 프로세스가 하나의 TCP connection과 하나의 대표 session channel을 가진다. OpenSSH 클라이언트 쪽 흐름을 구현 관점에서 단순화하면 다음과 같다.

ssh main()
  └─ 설정 파일/CLI 옵션 파싱
  └─ TCP 연결 생성
  └─ SSH transport 초기화: 버전 교환, KEX, 인증
  └─ ssh_session2()
     └─ ssh_session2_open(): 논리적 채널 생성
        └─ channel_new("session", SSH_CHANNEL_OPENING, ...)
        └─ channel_send_open()
     └─ open confirm 이후 client_session2_setup(): 채널을 어떤 용도로 쓸지 협상
        └─ pty 할당 요청 / 환경 변수 세팅 / 단순 명령 exec / shell 할당 요청
  └─ client_loop()
     ├─ network socket
     ├─ channel fd
     ├─ window adjust
     ├─ channel data/eof/close
     └─ server alive / rekey / signal 처리

위 흐름에서 짧은 요청 하나를 보내기 위해 매번 TCP 연결 생성부터 SSH transport 초기화, KEX, 인증까지 반복하는 것은 꽤 비싸다. 이미 인증까지 끝난 SSH transport connection을 유지할 수 있다면, 이후 실행에서는 이 앞단을 생략하고 기존 connection 위에 새로운 session channel만 열면 된다.

이 글에서 말하는 “세션 채널 캐싱”은 개별 session channel 자체를 저장해 두고 재사용한다는 뜻은 아니다. OpenSSH가 실제로 재사용하는 것은 더 비싼 단위인 SSH transport connection이고, 필요할 때마다 그 위에 새 session channel을 빠르게 추가한다.

OpenSSH의 multiplexing은 이 지점에서 등장한다.

3. Multiplexing의 핵심 아이디어

OpenSSH의 multiplexing은 여러 ssh 프로세스가 하나의 TCP socket을 직접 나눠 쓰는 구조가 아니다. 더 정확히는 마스터 프로세스가 서버와의 SSH 연결을 독점하고, 슬레이브 프로세스들은 마스터에게 작업을 위임하는 구조다.

마스터가 필요한 이유는 SSH transport가 단순한 byte stream이 아니기 때문이다. 하나의 SSH connection에서는 packet sequence, MAC/cipher 상태, rekey 타이밍, channel id 공간이 모두 하나의 순서 안에서 관리된다. 여러 프로세스가 같은 TCP socket에 직접 SSH 패킷을 쓰면 이 상태를 일관되게 직렬화하기 어렵다. 그래서 OpenSSH는 TCP socket과 SSH transport 상태를 마스터 하나만 소유하게 만든다.

master ssh process
  ├─ 서버와의 TCP socket 보유
  ├─ SSH transport 암호화 상태 보유
  ├─ channel id / window / rekey 상태 관리
  └─ 기존 SSH connection 위에 새 session channel 생성

slave ssh process
  └─ ControlPath의 Unix domain socket으로 master에 접속
      └─ MUX_C_NEW_SESSION 요청 `이 command로 session channel 하나 열어줘`

Unix domain socket은 multiplexing을 자동으로 해주는 소켓이 아니라, 같은 머신 안의 slave와 master가 대화하기 위한 로컬 통로다. 이 소켓은 master가 ControlPath 경로에 listener로 만들어두고, slave는 같은 경로로 connect 해 master를 찾는다.

mux.c의 클라이언트 경로는 이 소켓으로 master에 접속한 뒤 메시지를 보낸다. 일반적인 새 명령 실행이라면 이 메시지는 MUX_C_NEW_SESSION이고, master는 이벤트 루프에서 control socket 이벤트를 받아 요청을 해석한 뒤 자신이 가진 SSH connection 위에 새 session channel을 연다.

4. 슬레이브가 붙는 과정: muxclient()

이제 두 번째 ssh를 실행했다고 해보자.

ssh user@example.com hostname

ControlMaster auto이고 같은 ControlPath에 이미 마스터가 있으면, 새 ssh 프로세스는 TCP 연결을 만들기 전에 mux.c의 muxclient() 경로를 시도한다. 여기서 슬레이브가 붙는 대상은 원격 서버가 아니라, 이미 떠 있는 로컬 마스터 프로세스다.

muxclient(ControlPath)
  ├─ AF_UNIX socket 생성
  ├─ ControlPath로 로컬 master에 connect()
  ├─ 실패하면:
  │   ├─ auto 계열이면 일반 SSH 연결로 fallback
  │   └─ stale socket처럼 보이면 정리
  └─ 성공하면:
      ├─ master와 mux protocol HELLO 교환
      └─ 요청 종류에 따라 session / forward / check / exit / proxy 수행

HELLO 교환은 슬레이브가 ControlPath의 Unix domain socket으로 마스터에 붙은 뒤, 로컬 마스터와 mux protocol 버전이 맞는지 확인하는 단계다. 이 확인이 끝나야 슬레이브는 “이 마스터에게 세션 생성을 위임해도 된다”라고 판단하고 다음 요청으로 넘어간다.

일반적인 새 쉘/명령 실행은 MUX_C_NEW_SESSION 요청으로 이어진다. 여기서 중요한 점은 슬레이브가 단순히 명령어 문자열만 보내는 것이 아니라, 자신이 가진 세션 제어권을 마스터에게 넘긴다는 점이다.

특히 fd 전달이 핵심이다. Unix domain socket의 프로세스 간 file descriptor 전달 기능을 이용, 슬레이브의 stdin, stdout, stderr fd를 마스터에게 보낸다. 그래서 마스터는 슬레이브의 터미널 입출력 통로를 직접 가진 상태로 새 session channel을 만들 수 있다.

이후 슬레이브는 네트워크 패킷을 직접 만들지 않는다. 마스터가 받은 fd를 session channel의 입출력에 연결하고, 서버와의 실제 SSH protocol exchange를 대신 수행한다. 슬레이브 프로세스는 foreground에 남아 있다가 마스터가 보내주는 session open 결과, 종료 상태, 에러 메시지를 기다린다.

그래서 사용자는 두 번째 ssh도 독립 프로세스처럼 느낀다. 터미널도 있고, 종료 코드도 받고, 표준 입/출력도 분리되어 있다. 하지만 실제 TCP 연결, 암호화, channel 생성과 관리는 모두 마스터가 이미 가지고 있던 하나의 SSH connection 위에서 처리된다.

5. 종료 과정: 세션 종료와 마스터 종료는 다르다

multiplexing을 이해할 때 종료 과정을 분리해서 봐야 한다.

첫 번째는 개별 session channel의 종료다. 예를 들어 슬레이브로 실행한 ssh host hostname 명령이 끝나면, 서버는 session channel에 exit status를 보낸다. 마스터는 이 정보를 control socket을 통해 슬레이브에게 알려주고, 슬레이브는 그 exit status로 종료한다. mux_client_request_session()은 MUX_S_SESSION_OPENED를 받은 뒤 계속 control socket을 읽다가 MUX_S_EXIT_MESSAGE 등을 처리한다.

두 번째는 마스터의 종료다. 마스터는 여러 이유로 끝날 수 있다.

1. 일반적인 ssh session이 끝나고 더 유지할 이유가 없을 때
2. ControlPersist timeout이 지났을 때
3. 사용자가 `ssh -O exit host`를 보냈을 때
4. 네트워크 연결이 끊겼을 때
5. 마스터 프로세스가 죽었을 때

ssh -O exit는 mux protocol의 MUX_C_TERMINATE 요청으로 간다. 마스터는 이를 받으면 종료 플래그를 세우고 loop를 빠져나간다. 반면 ssh -O stop은 조금 다르다. 이것은 새 multiplexing 요청을 더 받지 않도록 control socket을 닫는 쪽에 가깝다. client_stop_mux()는 ControlPath를 unlink 하고, persist 모드이거나 shell이 없는 경우 모든 active channel이 닫힌 뒤 종료되도록 표시한다.

6. ControlPersist: 연결을 언제까지 들고 있을까

ControlMaster는 이미 만들어진 SSH transport connection을 마스터 프로세스가 들고 있게 만든다. 그렇다고 해서 마스터가 자신의 원래 session이 끝나는 즉시 항상 죽는 것은 아니다. clientloop.c의 메인 루프는 session_closed만 보지 않고 channel_still_open(ssh)도 함께 본다. 즉 마스터가 실행한 원래 명령이 끝났더라도 아직 슬레이브가 만든 channel이 하나라도 열려 있으면 마스터는 계속 살아서 대행을 이어간다.

ControlMaster만 있는 경우
  ├─ 마스터의 원래 session 종료
  ├─ 그래도 열린 slave channel이 있으면 유지
  └─ 모든 channel이 닫히면 즉시 종료

ControlPersist는 여기서 한 걸음 더 나간다. 모든 session channel이 닫혀 더 이상 처리할 슬레이브가 없어도, 마스터를 일정 시간 더 살려둔다. 이 로직은 clientloop.c의 set_control_persist_exit_time()에 드러난다. 열린 channel이 있으면 종료 예약을 취소하고, 열린 channel이 없으면 ControlPersist 설정값에 따라 종료 시각을 잡는다.

ControlPersist가 있는 경우
  ├─ 열린 channel이 있으면 계속 유지
  ├─ 열린 channel이 없어도 바로 종료하지 않음
  ├─ ControlPersist yes / 0 이면 계속 대기
  └─ ControlPersist 10m 이면 마지막 channel 종료 후 10분 뒤 종료

그래서 ControlMaster만으로도 “이미 붙어 있는 슬레이브”는 보호된다. 하지만 모든 슬레이브가 잠깐이라도 0개가 되는 순간 마스터가 사라지기 때문에, 다음 짧은 요청은 다시 TCP 연결과 인증부터 시작해야 한다. ControlPersist는 바로 이 공백을 메우기 위한 옵션이다. Ansible, 배포 스크립트, 짧은 ssh host command를 반복하는 환경에서 효과가 큰 이유도 여기에 있다.

7. 왜 이렇게 설계했을까?

OpenSSH multiplexing의 핵심은 공유할 것과 위임할 것을 분리한 것이다. TCP socket과 SSH transport 상태는 마스터가 계속 들고 있고, 슬레이브는 매번 새로 생기는 사용자 입출력과 명령 실행 요청만 마스터에게 넘긴다.

마스터가 관리하는 범위
  ├─ TCP socket
  ├─ SSH transport 암호화 상태
  ├─ rekey 상태
  ├─ channel id / window 상태
  └─ 서버와의 실제 protocol exchange

슬레이브가 관리하는 범위
  ├─ 사용자 터미널/stdio
  ├─ 실행하고 싶은 command
  ├─ 이번 실행의 옵션
  └─ 종료 상태를 기다리는 foreground 프로세스

이렇게 나누면 SSH transport의 복잡한 상태는 한 프로세스 안에서만 직렬화할 수 있다. packet sequence, MAC/cipher 상태, rekey, channel window 같은 값은 마스터가 일관되게 관리하고, 슬레이브는 Unix domain socket을 통해 “새 session channel을 열어달라”는 고수준 요청만 보낸다.

동시에 사용자 경험은 기존 ssh와 크게 달라지지 않는다. 슬레이브는 자기 stdin, stdout, stderr fd를 마스터에게 넘기고 foreground에서 종료 상태를 기다린다. 사용자는 독립적인 ssh 명령을 실행한 것처럼 느끼지만, 실제로는 마스터가 기존 SSH connection 위에 새 channel을 열어 대신 처리한다.

결국 ControlMaster는 “TCP socket을 여러 프로세스가 같이 만지는 기능”이 아니라, 마스터가 연결 상태를 중앙에서 관리하고 슬레이브의 요청을 channel 단위로 대행하는 구조다. 마스터가 소유한 암호화나 시퀀스 상태를 자신의 명령이 끝날 때 살아 있는 슬레이브에게 원자적으로 넘겨주는 까다로운 방식을 택하지도 않는다. 이 덕분에 TCP handshake, key exchange, 인증 같은 비싼 단계를 반복하지 않으면서도 SSH transport의 상태를 안전하게 유지할 수 있다.

Reference

RFC 4254: The Secure Shell (SSH) Connection Protocol
OpenSSH portable GitHub Repository: https://github.com/openssh/openssh-portable

ForkJoinPool 아키텍처와 경합 최소화

Jaehee Jeon — Fri, 19 Dec 2025 13:58:24 +0900

Java 7부터 도입된 스레드 풀 ForkJoinPool은 Java 5의 전통적인 ThreadPoolExecutor와는 구조와 동작 방식이 특이하다. 직접 ForkJoinPool을 사용한 적은 없더라도 병렬 스트림, CompletableFuture, 가상 스레드 풀 등 다양한 자바 기능들이 내부적으로 ForkJoinPool를 의존하여 나도 모르게 사용하고 있었을 가능성이 크다.

ForkJoinPool은 멀티 코어 CPU를 최대한 효율적으로 활용하는 것을 목표한다.

코어 수와 유사한 개수의 스레드를 만들고 이것들의 가동률을 100%로 유지한다.
병렬도와 무관하게 경합을 고려해야 하는 로직을 최소화한다.

ForkJoinPool구현의 주요한 아이디어들을 살펴보자.

1. `ForkJoinPool`내의 경합을 최소화환 WorkQueue Array 관리

ForkJoinPool내에는 두 종류의 큐가 존재한다.

풀 내의 워커 스레드(ForkJoinWorkerThread)가 관리하는 Local Queue
외부 스레드에서 제출한 작업이 쌓이는 Submission Queue

이러한 하나의 Submission Queue를 떠올리기 쉽지만 실은 아니다

ForkJoinPool은 워커 스레드가 Submission Queue에서 작업을 꺼내가는 pull 방식으로 설계되었다.

위와 같이 여러 워커 스레드가 하나의 바라보고 작업을 가져가는 방식을 떠올리기 쉽지만 이런 모델은 여러 워커 스레드가 Submission Queue에 접근할 때 경합이 빈번히 발생하며, 워커 스레드가 늘어날수록 경합을 기하급수적으로 늘린다.

이 문제를 해소하고자 ForkJoinPool의 실제 구현에서는 Submission Queue를 Local Queue와 같은 수로 유지하고, 두 종류의 Queue를 array 형태로 묶은 WorkQueue[]로 관리한다.

WorkQueue[]는 지정한 병렬성의 2배 이상의 가장 작은 2의 거듭제곱 크기로 생성되고 짝수 인덱스는 Submission Queue로 활용, 홀수 인덱스는 개별 워커 스레드의 Local Queue로 활용한다.

워커 스레드 각각의 큐와 외부에서 작업을 제출하는 큐의 개수가 같다

ForkJoinPool내에 작업을 추가 시 작업을 추가하는 스레드가 어떤 스레드인지 검사 되며, 워커 스레드(ForkJoinWorkerThread)가 아닌 외부 스레드라면 Submission Queue에 작업이 추가된다.

Submission Queue가 전체의 반이나 되는데 어떤 큐를 어떤 순서로 사용할까?
ForkJoinPool내부에선 언제나 수많은 Submission Queue중 랜덤한 하나를 골라 접근, 고른 분배를 꾀한다.

스레드 고유의 랜덤 시드(r)를 shifting(<< 1)하며 짝수 인덱스만 스캔한다.

스레드 각각이 가진 랜덤 시드(r)의 bit shifting으로 빠르게 짝수 인덱스(id)를 하나 선택, 큐 크기와 나머지 연산((queueSize - 1) & (id = r << 1))하여 접근할 임의의 Submission Queue를 선정하는 것을 볼 수 있다. 순차 탐색이 목표가 아니며 모든 큐를 완전 탐색하는 게 목표가 아니므로 유효하고 빠른 방법이다.

워커 스레드들이 쉬다가 깨어나서 다른 큐에서 작업을 훔칠 큐를 선정하는 흐름도 유사하다. 마찬가지로 의사 난수를 통해 WorkQueue의 인덱스를 선정, 랜덤한 큐에서 훔쳐갈 것이 있나 살펴본다.

외부에서 작업을 넣을 때는 최대한 흩뿌려서 큐의 크기를 고르게 유지하고, 워커 스레드가 훔쳐갈 남의 큐를 랜덤하게 선택하도록 하여 스레드 간 경합이 발생하는 상황 자체를 최소화한다.

왜 스레드 풀 외부의 스레드가 작업을 제출할 때부터 Local Queue를 임의 선택하여 추가하는 Push 모델이 아닐까?
워커 스레드들이 Pull하는 방식으로 설계하지 않았다면 여러 개의 Submission Queue도 필요하지 않을 것이다.

Pull 모델을 선택한 이유는 후술 할 Work-Stealing 방식을 채택한 이유와도 이어지는데, 1. Local Queue에 작업을 추가하는 주체를 시스템 전역에서 Local Queue를 소유한 하나의 워커 스레드로 한정하여 경합을 줄이고, 2. 외부 스레드 입장에선 어떤 워커 스레드가 여유로운지 알 수 없으므로 워커 스레드가 직접 작업을 선택하게 하는 방식이 낫다고 판단한 것으로 보인다.

3. Work-Stealing Deque 기반의 경합을 최소화하는 `WorkQueue`

하나의 WorkQueue를 동시 접근할 때의 경합을 Lock-free 방식으로 최소화하는 것도 핵심이다.
클래스의 이름은 WorkQueue이지만 실질적인 구현은 Deque이며, 양 끝단을 접근하는 주체는 철저히 분리된다.

WorkQueue는 Chase-Lev의 'Dynamic Circular Work-Stealing Deque'을 최적화하여 구현해놓았는데 핵심은 소유자와 도둑의 역할 및 접근 지점 분리이다.

가장 간단한 형태로 논문의 Work-Stealing 방식만 설명하면 아래와 같다.

락 사용 없이 top과 bottom 위치를 volatile로 선언하여 메모리 가시성을 확보하고 최소한의 CAS 연산을 사용한다.
bottom 인덱스는 단조 증가하며, 작업을 추가하는 주인에 의해서만 변경한다(pushBottom)
도둑은 작업 훔치기만 가능하며, CAS 연산을 통한 top을 증가시키는 방식으로 한정된다.
이렇게 구현 시 주인이 작업을 가져가는 위치인 bottom에서는 마지막 작업이 아닌 이상 CAS 가 불필요해진다.

class WorkQueue {
    Task[] tasks = new Task[CAPACITY];

    // volatile을 통한 메모리 가시성 확보
    volatile int top = 0;    // 도둑이 훔쳐가는 위치
    volatile int bottom = 0; // 주인이 작업을 넣고 빼는 위치

    // 도둑 스레드가 CAS 기반의 top에서 작업을 훔치는 메서드
    public Task steal() {
        ...
    }

    // 주인이 bottom에 작업을 추가하는 메서드
    public void pushBottom(Task task) {
        ...
    }

    // 주인이 bottom에서 작업을 꺼내가는 메서드. 작업이 하나 남은게 아니라면 CAS가 불필요하다
    public Task popBottom() {
        int b = this.bottom - 1;
        this.bottom = b;      // 일단 인덱스를 하나 줄여 예약

        int t = this.top;     // top을 읽어와서 경합 여부 확인
        int size = b - t;

        if (size < 0) {       // 1) 큐가 비어있음
            this.bottom = t;  // 인덱스 복구
            return null;
        }

        Task task = tasks[b]; // 작업 가져오기

        if (size > 0) {       // 2) 작업이 넉넉함 = 경합 없음
            return task;      // CAS 없이 바로 리턴
        }

        // 3) size == 0, 마지막 아이템이므로 도둑과 경합 발생 가능
        // CAS로 top을 증가시켜서 도둑이 못 가져가게 막아야
        if (!compareAndSwapTop(t, t + 1)) {
            this.bottom = t + 1; // 도둑이 먼저 가져가 실패한 경우 인덱스 복구
            return null; 
        }

        this.bottom = t + 1; // 성공 시 상태 업데이트
        return task;
    }
}

실제 구현에선 WorkQueue에 쓰기 작업을 수행하는 스레드는 WorkQueue의 주인으로 한정되므로 top과 bottom 각각을 volatile로 지정하는 대신 별도의 메모리 동기화용 필드 access를 활용한다.

하나의 큐에서도 도둑과 주인의 접근 방향을 구분하는 아이디어로 주인이 자기 큐의 작업을 집중적으로 처리할 때 대부분의 상황에서 동기화 로직 없이 작업을 손쉽게 할당한다. (메모리 가시성 정도만 고려)

3. ManagedBlocker를 통한 I/O 작업 최적화

스레드 수를 지정하는 전통적인 ThreadPoolExecutor와 달리 ForkJoinPool은 '병렬도'만을 지정하는 생성자들이 존재한다. 스레드 수가 아닌 병렬도를 지정한다는 의미가 무슨 의미일까?

이는 ForkJoinPool이 I/O 작업을 수행하는 워커 스레드가 있으면 해당 스레드는 커널에 의해 sleep되는 것으로 간주하고 동적으로 신규 스레드를 할당하여 유저가 원하는 수의 실질적 병렬도를 유지시킨다는 의미이다.

Project Loom을 들어보지 못했거나 JVM 스레드와 커널 스레드 간의 1:1 관계가 I/O 작업 과정에서 어떻게 동작하는지 이해하지 못하면 이 필요성을 전혀 알 수 없으므로 동작 방식을 간단히 설명한다.

JVM 위에선 C 코드 수행 경과를 알기 어렵다.

전통적인 자바의 소켓 라이브러리 등을 사용할 때 I/O를 수행하는 Native 코드들은 C 기반의 JNI 구현체를 호출한다.
JNI 구현체에서 socket.read()와 같은 코드가 실행되었으나 소켓 버퍼에 읽을 내용이 없다면 커널에 의해 pthread는 Sleep된다.
JVM 스레드는 여전히 JNI 구현체 코드가 끝나지 않은 것으로 인식, jstack 등으로 JVM 스레드의 상태를 출력해 보면 실행 중임을 의미하는 RUNNABLE로 표기된다.

즉, 자바의 특성상 JVM 위에서는 Native 코드 내에서 이뤄지는 I/O과정의 무한 대기 여부를 판별할 수 없으므로 프로그래머가 '이 코드의 내용엔 커널이 pthread를 sleep 시킬 만한 내용이 있어'를 알려야 한다.

ForkJoinPool에선 별도의 ManagedBlocker라는 인터페이스의 block()을 구현하여 풀에 '작업 과정의 I/O 블록이 발생할 수 있는 영역'을 개발자가 정의하게 한다.

ManagedBlocker 사용 예시

public static void main(String[] args) {  
    ForkJoinPool forkJoinPool = ForkJoinPool.commonPool();  
    forkJoinPool.submit(new MyTask());  
}

// RecursiveAction은 ForkJoinPool이 허용하는 ForkJoinTask의 자식 클래스.
private static class MyTask extends RecursiveAction {  

    @Override  
    protected void compute() {  
       // CPU bound job 1
       // ...

       // I/O 작업 부분은 ManagedBlocker 구현체를 실행하는 것으로 대체한다.
       FileReadBlocker blocker = new FileReadBlocker();  
       try {  
          ForkJoinPool.managedBlock(blocker);  
       } catch (InterruptedException e) {  
          e.printStackTrace();  
       }

       // CPU bound job 2...  
       String blockerResult = blocker.getResult();  

    }  
}

// I/O 작업 부분만 모아두는 ManagedBlocker 구현체
private static class FileReadBlocker implements ForkJoinPool.ManagedBlocker {  

    private String result;  
    private boolean finished = false;  

    @Override  
    public boolean block() throws InterruptedException {  
       try (BufferedReader br = new BufferedReader(new FileReader("/myPath"))) { 
          this.result = br.readLine();  
       } catch (IOException e) {  
          throw new RuntimeException(e);  
       }  
       this.finished = true;  
       return true;  
    }  

    @Override  
    public boolean isReleasable() {
        //...
       return false;
    }  

    public String getResult() {  
       return result;  
    }  
}

이처럼 구현 시 MyTask 내의 File I/O를 실행하는 코드를 진입할 때는 ForkJoinPool이 'I/O가 발생했으니 커널에 의해 pthread는 Sleep 되고 JVM 스레드는 RUNNABLE인, 실질적 동시 CPU 작업을 수행하는 스레드가 하나 줄어들겠군'이라는 판단을 하고 동적으로 풀에 추가 스레드를 할당하여 병렬도를 유지한다.

이것이 ForkJoinPool에 타 스레드 풀과 달리 생성자에서 '스레드 수'를 지정하지 않고 '원하는 병렬도'를 지정하는 이유이다.

내부적으로 `ForkJoinPool`이 사용되는 경우를 알아두자

`CompletableFuture`

별도 스레드에서 작업을 처리하는 CompletableFuture.runAsync(), supplyAsync(), thenApplyAsync()등은 실행할 스레드 풀을 지정하지 않으면 실행 환경의 코어 수 - 1 크기의 워커 스레드를 가지는 ForkJoinPool.commonPool()에서 실행된다.

여기에 쿼리나 HTTP 통신, 파일 I/O등 I/O 작업을 전달하면 전체 시스템 병목의 원인이 된다.
ForkJoinPool에 직접 작업을 추가할 땐 ManagedBlocker를 구현해서 동적으로 추가 스레드 생성 힌트라도 줄 수 있었는데 CompletableFuture에는 Runnable, Supplier 등만 등록 가능하다.

내부에선 ForkJoinPool이 Runnable과 같은 인터페이스의 인스턴스를 전달받으면 분할은 불가하나 어댑터를 씌워 ForkJoinTask의 모습으로 바꾸어 실행한다. 껍데기만 씌웠으므로 워커 스레드가 실행하는 과정에서 작은 CPU bound 작업들로 분할하여 여러 워커 스레드가 분할 정복하는 ForkJoinPool의 이점은 하나도 누리지 못한다.

Parallel Stream, `Arrays.parallelSort()`, 일부 `Collections` API

마찬가지로 특별한 꼼수를 쓰지 않는 이상 ForkJoinPool.commonPool()에서 실행된다.
Arrays.parallelSort()나 reduce(), ConcurrentHashMap.search()등은 순수한 CPU 작업이므로 문제 될 게 없다.

병렬 스트림을 사용하는 경우 한정, CompletableFuture와 마찬가지로 I/O 작업을 넣으면 시스템 병목을 일으킨다. 인메모리 CPU 계산에만 사용하자.

모두 같은 ForkJoinPool.commonPool()을 사용하므로 한 곳에서만 잘못 써도 풀을 공유하는 모든 로직에서 병목이 발생한다.

Virtual Thread

앞선 두 가지와 다르게 전용 ForkJoinPool을 만들어 사용한다. ForkJoinPool의 워커 스레드들이 가상 스레드에서 이야기하는 캐리어 스레드 역할을 한다.

가상 스레드와 ForkJoinPool 모두 커널 스레드의 컨텍스트 스위칭을 최소화하며 CPU를 남김없이 쓰자는 것은 동일하나, I/O를 감지(ManagedBlocker)하면 JVM 스레드와 커널 스레드를 추가 할당하는 ForkJoinPool과 달리 가상 스레드는 I/O를 미리 감지하고 가상 스레드만 교체한다는 측면에서 다르다.

ForkJoinPool은 임의의 사용자 환경에서 범용적인 병렬도를 최대한 유지하며 CPU 집약적인 작업들을 처리하기 위해 설계되었다. ManagedBlocker 또한 CPU 집약적 작업 과정에서 드물게 발생하는 I/O 로직을 구제하는 장치일 뿐이다.

ForkJoinPool을 사용하는 몇몇 라이브러리들을 사용하기보다 내부 코드를 열어본다면 성능을 위한 경합 최소화부터 Temporal Locality를 위한 한 번 고른 큐를 집중 공략하는 로직, Unsafe를 통한 최소한의 메모리 가시성 확보나 하나의 ctl 변수에 최대한 정보를 몰아두고 bitwise 연산을 활용하는 등의 마이크로 최적화까지 다양한 고민들을 공감할 수 있을 것이다.

Reference

Chase and Lev. (2005). Dynamic Circular Work-Stealing Deque, SPAA 2005
Amazon Corretto 21.0.9

WebDAV와 NGINX의 ngx_http_dav_module

Jaehee Jeon — Wed, 5 Feb 2025 23:33:09 +0900

WebDAV

WebDAV는 HTTP 1.1 프로토콜의 확장 프로토콜이다.

DAV는 Distributed Authoring and Versiong의 약자로, HTTP보다 세부적인 웹 기반의 자원 관리와 관련된 표준이다.

아래의 예시처럼 HTTP에서는 볼 수 없는 특별한 메서드들이 존재한다.

LOCK / UNLOCK: 자원에 대한 락 취득 / 해제
MKCOL: 디렉터리 생성
MOVE / COPY: 자원 이동 / 복사
PROPFIND / PROPPATCH: 자원에 정의된 프로퍼티 조회 / 수정

WebDAV의 장점

HTTP 1.1과 호환되므로 익숙한 HTTP 관련 구현 기술들을 그대로 사용 가능
보통 구현 기술들이 웹 서버와 같은 포트(80, 443)를 사용하여 웹 서버에 적용한 보안 등의 인프라를 그대로 적용 가능
특정 자원에 대한 잠금이 가능하여 여러 사용자에 대한 동시 접근 관리 가능

익숙한 HTTP로 서버 자원을 세밀하게 관리하는 게 목적에 맞게 사용이 간단하다.

예를 들어 서버에서 자원의 위치를 변경하는 MOVE 메서드는 curl 명령에 단순히 HTTP Method만 수정하고 요청하면 된다.

# /old/file.txt를 /new/file.txt로 옮기는 예시
curl -X MOVE --header "Destination: https://www.test.com/new/file.txt" https://www.test.com/old/file.txt

구현 기술

Microsoft Office나 오픈소스인 Libere Office 등 문서에 대한 동시 편집 기능이 필요한 기술에 기능이 구현되어 있으며, Apache Web Server, NGINX나 시놀로지 NAS 등 웹 요청을 통해 파일을 관리하는 기술들에도 구현이 존재한다.

NGINX의 ngx_http_dav_module

이 글의 목적인 NGINX에서의 WebDAV 관련 기능을 확인해보자.

NGINX 공식 이미지에는 이미 Web DAV 모듈이 존재

글 작성 시점의 NGINX 최신 안정화 버전인 1.26.2에는 이미 Web DAV 구현 모듈인 ngx_http_dav_module이 포함되어 있다.

NGINX 1.26.2(stable) 이미지는 http_dav_module을 내장 중이다.

적절히 NGINX 설정 파일을 활성화하기만 하면 WebDAV 기능을 사용할 수 있다.

만약 공식 이미지를 통한 컨테이너가 아닌 직접 바이너리를 설치하는 경우, 바이너리에 ngx_http_dav_module이 포함되었는지 확인해야 하며 없다면 바이너리를 직접 빌드해야 한다.

사용 방법

예시로, 설정 파일인 /etc/nginx/nginx.conf 또는 /etc/nginx/conf.d/*. conf의 server 블록을 아래와 같이 정의해야 한다.

server {
    listen       80;
    listen  [::]:80;
    server_name  localhost;

    location ~ "/storage/([0-9a-zA-Z-.]*)$" {
        dav_methods            PUT DELETE MKCOL COPY MOVE;
        client_body_temp_path  /storage/tmp/;
        alias                  /local/$1;
        create_full_put_path   on;
        dav_access             group:rw  all:r;
    }
}

설정에 대한 설명은 아래와 같다

location: 정규식을 사용하여 HTTP URL이 /storage 하위인 경우 매칭
dav_methods: WebDAV의 메서드 중 허용할 메서드를 선언. (default: off => 모듈이 내장되어 있으나 기본 미사용되는 이유)
client_body_temp_path: 전송 중 임시 파일이 잔류할 위치. 이 위치에 임시 파일이 생성된 이후 옮기는 방식으로 동작.
alias: 실제 자원이 관리될 로컬 파일시스템 경로로 치환. URL이 /storage/text.txt 라면 바디의 내용이 /local/text.txt에 저장됨
create_full_put_path: URL과 동일한 폴더 구조를 자동 생성할지 여부. (default: off)
dav_access: 자원 생성 시 초기 부여되는 파일 권한. 위의 경우 그룹 권한으로는 읽기 / 쓰기, 전체로는 읽기 권한 부여

위의 설정으로 띄운 NGINX에 curl을 사용해 아래처럼 요청을 보내면 /local 하위에 123이란 내용의 text.txt가 생성된다.

curl -X PUT -d "123\n" http://localhost/storage/text.txt

유의사항

1. PUT으로 파일 업로드 시 Content-Type을 Plain Text로 지정해야 한다.

특별한 웹앱 서버처럼 동작하는 방식이 아니다 보니 Content-Type을 다르게 지정하는 경우 정상 저장 응답이 오나 실제 저장된 파일에 불필요한 데이터가 추가되는 경우가 존재했다.

일반적인 웹앱처럼 multipart/form-data로 하나의 HTTP 요청으로 여러 파일들을 한 번에 저장하는 동작 등이 불가능한 것도 단점.

2. 가장 눈여겨보았던 LOCK 관련 메서드나 자원의 프로퍼티 관리 관련 메서드는 지원하지 않는다.

ngx_http_dav_module docs

WebDAV 프로토콜의 DA(Distributed Authoring)을 위한 핵심 기능이라 생각해서 아쉬움에 찾아보니

애초에 WebDAV 표준인 RFC 2518, 4918에서 LOCK 등 일부 메서드에 대한 지원까지는 강제하지 않고 있었다.

RFC 2518 - 6.2 Lock 메서드 지원은 필수가 아니다 (최신 표준인 RFC 4918에서도 동일)

NGINX는 많은 사용자에 대한 빠른 정적 콘텐츠 서빙을 목표로 하는데, 스펙에 맞게 파일 별 S락, X락이나 자원의 프로퍼티들을 관리하려면 이 모듈을 위한 영속성 데이터를 관리해야 하므로 지원 범위를 제한한 것으로 보인다.

참고로 Apache의 WebDAV 모듈은 Lock과 관련한 고급 기능도 제공하는데, 이 기능을 위해 간단한 key-value 기반의 파일 DB(SDBM)를 설정해야 한다. 혹여 제대로 쓰려면 Apache 한계와 SDBM 관련 모듈을 원하는 DB로 커스텀할 수 있는지 등을 모두 고려해야 할 듯.

https://httpd.apache.org/docs/2.4/ko/mod/mod_dav.html

NGINX 쪽에서는 비공식 모듈인 nginx-dav-ext-module에서 프로퍼티, Lock 관련 기능을 지원하긴 한다.

단순히 리스트로 정보를 관리해 락 점유 여부를 확인할 때 O(n)이 소요된다 하니.. 조금이라도 규모 있는 환경에서는 쓰면 안 되겠다.

https://github.com/arut/nginx-dav-ext-module

아쉽게도 내장된 WebDAV 모듈은 이미 NGINX로 정적 파일 서빙을 하던 서버에 설정만 조금 바꿔서 정말 간단한 업로드 기능을 구현하는 정도로밖에 못 쓸 듯 하다.

결국 PUT 동작 방식으로 인해 파일 덮어쓰는 것을 방지하는 등의 로직을 커스텀하거나, Lock 기능이 본격적으로 필요하다면 별도의 솔루션 사용이나 웹앱 개발이 불가피해 보인다.

조금 더 찾아보고자 한다면 아래의 WebDAV 구현체 소개를 모아둔 프로젝트가 있으니 참고하면 좋다.

https://github.com/fstanis/awesome-webdav?tab=readme-ov-file

Reference

https://www.ietf.org/rfc/rfc2518.txt?number=2518

https://datatracker.ietf.org/doc/html/rfc4918

https://nginx.org/en/docs/http/ngx_http_dav_module.html

List 초기화와 MultipleBagFetchException 발생 원인

Jaehee Jeon — Sun, 10 Nov 2024 17:52:08 +0900

일을 하면서 OneToMany 관계를 여럿 가지는 부모 엔티티를 자식과 함께 가져와야만 하는 경우들을 마주친다.

때로는 비즈니스 제약으로 규모는 크지 않으나 부모 - 자식1 - 자식2 등의 2개 이상의 계층을 한 번에 가져와야 하는 경우도 있다.

왜 hibernate는 단일 쿼리로의 다중 List 초기화를 방지하며,

왜 부모는 자식을 항상 Set이 아닌 List로 초기화할까?

환경: hibernate-core 6.5.3 Final

MultipleBagFetchException

하나의 쿼리에서 둘 이상의 List를 Fetch Join으로 초기화하는 것은 불가하다.

설명에 사용할 객체의 연관 관계

Lazy Loading으로 Parent의 두 Child 컬렉션을 설정해둔 뒤 두 개의 Fetch Join으로 한 번에 연관된 데이터를 가져오려 하면 아래처럼 예외가 발생한다.

TypedQuery<Parent> query = entityManager.createQuery(
    "select p from Parent p join fetch p.child1s c1 join fetch p.child2s c2", Parent.class);
try {
    Parent findParent = query.getSingleResult();
    ...

MultipleBagFetchException 발생

사용자 입장에서는 아래와 같은 쿼리를 예상했겠지만, multiple bags에 대한 조회는 불가능하다는 응답만이 반환된다.

select
    ...
from
    parent p1_0 
join
    child1 c1_0 
        on p1_0.id=c1_0.parent_id 
join
    child2 c2_0 
        on p1_0.id=c2_0.parent_id

hibernate는 런타임에 List를 PersistentBag라는 프록시로 대체하고 지연 로딩 시 사용 시점에 초기화하는데, Fetch Join을 사용하여 명시적으로 하나의 쿼리에서 초기화를 시도하면 MultipleBagsFetchException이 발생한다.

원인: Cartesian Product를 인스턴스화하는 과정이 지나치게 비싸다

위의 예상되는 쿼리로 두 개의 컬렉션을 한 번에 가져왔다면 hibernate가 처리해야 할 ResultSet을 상상해 보자.

두 개의 컬렉션에 각각 두 개의 자식이 포함된 한 부모를 가정한다.

parent_id	parent_name	child1_id	child1_name	child2_id	child2_name
1	parent	1	child1_1	1	child2_1
1	parent	1	child1_1	2	child2_2
1	parent	2	child1_2	1	child2_1
1	parent	2	child1_2	2	child2_1

두 컬렉션의 크기가 각각 n, m라면, Cartesian Product로 인해 총 n*m개의 row를 가진 Result Set을 가져올 것이고 Hibernate는 이를 인스턴스로 만들어 컬렉션을 채워나가야 한다.

이때 다중 컬렉션 초기화가 컬렉션의 개수에 따라 공간 복잡도가 선형적으로 증가하고, OOM(Out Of Memory) 발생 가능성이 있어서 예외를 발생시킨다 말하면 맞는 설명일까? 만약 데이터의 크기가 크지 않다면 사용자 판단 하에 사용해도 될 듯한데 원천 차단하는 이유는 무엇일까?

여러 개의 Set은 한 번에 초기화해도 MultipleBagsFetchException이 발생하지 않는다.

같은 상황에서 컬렉션의 자료 구조를 Set으로 변경하면 문제없이 원하는 쿼리가 수행된다.

@Entity
public class Parent {

    ...

    @OneToMany(mappedBy = "parent")
    private Set<Child1> child1s = new HashSet<>();
//    private List<Child1> child1s = new ArrayList<>();

    @OneToMany(mappedBy = "parent")
    private Set<Child2> child2s = new HashSet<>();
//    private List<Child2> child2s = new ArrayList<>();

    ...

자료 구조만 바꾸었는데 원했던 데이터가 가져와진다는 것은 Result Set의 크기로 인한 OOM이 문제가 아니라는 뜻이다.

자료 구조에 의한 객체 초기화의 시간 복잡도가 원인이다.

위의 예시에서의 Result Set의 자식 인스턴스들이 처리되는 흐름을 고민해 보자.

parent_id	parent_name	child1_id	child1_name	child2_id	child2_name
1	parent	1	child1_1	1	child2_1
1	parent	1	child1_1	2	child2_2
1	parent	2	child1_2	1	child2_1
1	parent	2	child1_2	2	child2_1

hibernate는 parent_id = 1인 인스턴스에 List 또는 Set을 프록시로 대체한 두 컬렉션을 넣어둔다.
row 1: child1s 컬렉션에 child1_1이 있는지 확인한다. 없으므로 생성한다.
row 1: child2s 컬렉션에 child2_1이 있는지 확인한다. 없으므로 생성한다.
row 2: child1s 컬렉션에 child1_1이 있는지 확인한다. 있으므로 넘어간다.
row 2: child2s 컬렉션에 child2_2이 있는지 확인한다. 없으므로 생성한다.
...

이미 눈치챘겠지만, 컬렉션을 채워 넣는 과정에서 있는지 확인하는 프로세스가 List(PersistentBag)와 Set(PersistentSet) 자료구조의 특성으로 인해 다르다.

List를 사용하는 경우, 두 컬렉션의 크기 곱(n * m)만큼의 Result Set을 처리하는 과정에서 기존에 존재하던 컬렉션 내의 값들을 매번 비교해야 하므로 시간 복잡도는 2차 이상이 된다. 이는 컬렉션이 두 개일 때이며 컬렉션 수에 따라 지수 항 또한 증가한다.

hibernate는 대규모 데이터로 인한 메모리 문제를 우려한다기보다, 여러 List 초기화에 시간 복잡도가 엄청나 막는다고 보는 게 맞겠다.

Set은 어떤 문제를 가지나?

데이터의 중복과 무관하게 일반적으로 List를 선택하는 이유는 무엇일까? Set은 값을 추가하는 경우 등에서 지연 로딩의 이점을 살리지 못하기 때문이다.

기존에 존재하던 부모를 조회하고, 자식을 하나 더 추가해 보자.

TransactionStatus tx2 = platformTransactionManager.getTransaction(
        TransactionDefinition.withDefaults());
try {
	// 부모를 조회하고,
    Parent findParent = entityManager.find(Parent.class, 1L);
    Child1 child1_2 = new Child1();
    child1_2.setName("child1_2");
    // 자식을 추가한다. (cascade를 추가하지 않아 직접 영속화한다)
    findParent.addChild1(child1_2);
    entityManager.persist(child1_2);
    entityManager.flush();
    entityManager.clear();
    ...

List

Set

자식을 추가하는 과정에서 List의 경우 중복을 고려할 필요가 없으므로 바로 데이터를 삽입하는 반면,

Set의 경우 자료 구조의 특성상 삽입 시점에 해싱을 통한 데이터 중복을 검사해야 한다.

List와 달리 지연 로딩으로 값이 비어있던 Set(PersistentSet)을 초기화하기 위해 모든 자식을 가져오는 조회 쿼리가 추가로 발생한다.

즉, Set은 데이터 삽입 시 지연 로딩의 이점을 살리지 못한다.

즉시 로딩으로 여러 컬렉션을 가진 부모를 조회하면 어떨까?

비즈니스 특성 상 부모 - 자식이 언제나 함께 조회되어야 하는 상황이라면 즉시 로딩을 고려해 볼 수 있다.

위에서 hibernate는 여러 List를 하나의 조회 쿼리로의 초기화를 방지하는 것을 확인했다.

지연 로딩이었던 설정을 즉시 로딩으로 바꾸고 부모를 가져오면 어떤 쿼리가 발생할까?

@Entity
public class Parent {

    ...

    @OneToMany(mappedBy = "parent", fetch = FetchType.EAGER)
    private List<Child1> child1s = new ArrayList<>();

    @OneToMany(mappedBy = "parent", fetch = FetchType.EAGER)
    private List<Child2> child2s = new ArrayList<>();

    ...

위에서 말했듯 여러 List에 대한 동시 조회는 비용이 너무 비싸므로, 알아서 하나의 List(PersistentBag)에 대해서만 초기화를 하도록 child1을 join 하여 가져오고, 별개의 쿼리로 child2를 가져온다.

추가로,

하나는 List, 나머지는 Set인 경우에도 컬렉션 별로 다른 쿼리를 통해 초기화한다
두 계층(Parent - Child1)이 아닌 더 많은 계층 (Parent - Child1 - ChildX..)의 경우에도 알아서 첫 Child1까지만 join으로 가져오고, 나머지 계층은 개별적인 쿼리로 가져온다.

이를 통해 hibernate가 List 초기화 과정을 최대한 간소화하는 방향을 선택함을 알 수 있다.

또한 즉시 로딩은 구현체(hibernate)의 판단에 따라 하나의 쿼리로 묶이지 않는 경우도 있음을 알았다.

[InnoDB] 인덱싱되지 않은 컬럼으로 UPDATE 시 데드락이 발생한다

Jaehee Jeon — Mon, 8 Jul 2024 00:58:52 +0900

결제 서비스를 만들고 테스트하던 중 인덱싱 되지 않은 컬럼을 검색 조건으로 활용한 Update에서, 단건의 요청 처리에 대해 문제가 없었으나 다수의 요청 동시 처리 시 데드락이 발생하는 상황을 경험했다.

1. 데드락 확인

org.springframework.dao.TransientDataAccessResourceException: execute; SQL [UPDATE payment_orders
SET payment_order_status = :status, updated_at = CURRENT_TIMESTAMP
WHERE order_id = :orderId]; Deadlock found when trying to get lock; try restarting transaction

스프링을 통해 어떤 로직을 테스트하던 중, 인덱싱되지 않은 컬럼을 검색 조건으로 UPDATE 쿼리가 동시에 다수 발생할 때 데드락으로 인해 실패하는 것을 확인했다.

mysql> show engine innodb status;

데드락이 발생한 트랜잭션과 쿼리의 상세 정보를 확인하기 위해 DB에 접속하여 InnoDB의 상태를 출력하였다.

------------------------
LATEST DETECTED DEADLOCK
------------------------
2024-07-07 07:18:17 281472619503424
*** (1) TRANSACTION:
TRANSACTION 5431, ACTIVE 0 sec starting index read
mysql tables in use 1, locked 1
LOCK WAIT 5 lock struct(s), heap size 1128, 3 row lock(s), undo log entries 2
MySQL thread id 22, OS thread handle 281472562806592, query id 123 192.168.65.1 root updating
UPDATE payment_orders
SET payment_order_status = 'UNKNOWN', updated_at = CURRENT_TIMESTAMP
WHERE order_id = 'ce6d18a4-5ac0-4c27-b032-aba1c6225695'

*** (1) HOLDS THE LOCK(S):
RECORD LOCKS space id 3 page no 4 n bits 80 index PRIMARY of table `test`.`payment_orders` trx id 5431 lock mode S locks rec but not gap
Record lock, heap no 12 PHYSICAL RECORD: n_fields 15; compact format; info bits 0
 0: len 8; hex 80000000000000bf; asc         ;;
...
 14: len 5; hex 99b3ce7490; asc    t ;;

Record lock, heap no 13 PHYSICAL RECORD: n_fields 15; compact format; info bits 0
 0: len 8; hex 80000000000000c0; asc         ;;
...
 14: len 5; hex 99b3ce7490; asc    t ;;


*** (1) WAITING FOR THIS LOCK TO BE GRANTED:
RECORD LOCKS space id 3 page no 4 n bits 80 index PRIMARY of table `test`.`payment_orders` trx id 5431 lock_mode X waiting
Record lock, heap no 2 PHYSICAL RECORD: n_fields 15; compact format; info bits 0
 0: len 8; hex 80000000000000b5; asc         ;;
...
 14: len 5; hex 99b3ce6ddc; asc    m ;;


*** (2) TRANSACTION:
TRANSACTION 5427, ACTIVE 0 sec fetching rows
mysql tables in use 1, locked 1
LOCK WAIT 8 lock struct(s), heap size 1128, 13 row lock(s), undo log entries 4
MySQL thread id 21, OS thread handle 281472567033664, query id 122 192.168.65.1 root updating
UPDATE payment_orders
SET payment_order_status = 'UNKNOWN', updated_at = CURRENT_TIMESTAMP
WHERE order_id = 'f4f0c58e-dfad-4b03-89f1-2114f3e4e9b7'

*** (2) HOLDS THE LOCK(S):
RECORD LOCKS space id 3 page no 4 n bits 80 index PRIMARY of table `test`.`payment_orders` trx id 5427 lock_mode X
Record lock, heap no 2 PHYSICAL RECORD: n_fields 15; compact format; info bits 0
 0: len 8; hex 80000000000000b5; asc         ;;
...
 14: len 5; hex 99b3ce6ddc; asc    m ;;

Record lock, heap no 3 PHYSICAL RECORD: n_fields 15; compact format; info bits 0
 0: len 8; hex 80000000000000b6; asc         ;;
...
 14: len 5; hex 99b3ce6ddc; asc    m ;;

Record lock, heap no 4 PHYSICAL RECORD: n_fields 15; compact format; info bits 0
 0: len 8; hex 80000000000000b7; asc         ;;
...
 14: len 5; hex 99b3ce6ea9; asc    n ;;

Record lock, heap no 5 PHYSICAL RECORD: n_fields 15; compact format; info bits 0
 0: len 8; hex 80000000000000b8; asc         ;;
...
 14: len 5; hex 99b3ce6ea9; asc    n ;;


*** (2) WAITING FOR THIS LOCK TO BE GRANTED:
RECORD LOCKS space id 3 page no 4 n bits 80 index PRIMARY of table `test`.`payment_orders` trx id 5427 lock_mode X waiting
Record lock, heap no 12 PHYSICAL RECORD: n_fields 15; compact format; info bits 0
 0: len 8; hex 80000000000000bf; asc         ;;
...
 14: len 5; hex 99b3ce7490; asc    t ;;

*** WE ROLL BACK TRANSACTION (1)

Transaction 5427과 Transaction 5431에서 각각 아래 쿼리를 실행하는 도중 데드락이 발생했다는 것을 볼 수 있다.

-- TX 5427
SET payment_order_status = 'UNKNOWN', updated_at = CURRENT_TIMESTAMP
WHERE order_id = 'f4f0c58e-dfad-4b03-89f1-2114f3e4e9b7'

-- TX 5431
SET payment_order_status = 'UNKNOWN', updated_at = CURRENT_TIMESTAMP
WHERE order_id = 'ce6d18a4-5ac0-4c27-b032-aba1c6225695'

로그 중 아래와 같은 부분들을 통해 실제 어떤 row에 대한 record lock인지도 특정할 수 있다. 각 줄은 TX 정보부터 해당 row의 각 컬럼이 무엇인지를 내포한다.

 0: len 8; hex 80000000000000b6; asc         ;;
...
 6: len 30; hex 64336433323034342d653432622d343833342d396338392d666662633562; asc d3d32044-e42b-4834-9c89-ffbc5b; (total 36 bytes);
...
 14: len 5; hex 99b3ce6ddc; asc    m ;;

실제 db에 저장된 값들(UUID d3d32044-e42b-4834-9c89-ffbc5b) 등이 보인다.

서버에서 관련 예외를 이미 받았으므로 데드락은 자동 감지되어 처리됨을 예상 가능, show processlist 명령으로 프로세스 및 스레드를 확인하면 이미 트랜잭션을 처리하는 스레드는 보이지 않음도 확인하였다.

2. 원인 분석

TX 5427은 heap no 2, 3, 4, 5에 대한 X lock을 가지고 heap no 12에 대한 X lock을 얻지 못해 대기,

TX 5431은 heap no 12, 13에 대한 S lock을 가지고 heap no 2에 대한 X lock을 얻지 못해 대기하는 중이다.

1. 같은 컬럼에 대한 검색 조건이 다른데 Record 락 경합이 발생한다는 점,

2. 테스트 도중 저장되어 있는 데이터의 수가 적고 쿼리가 단순한데 비교적 많은 레코드들을 로드하고 락을 건다는 점

두 가지 근거로 고민해보니 원인은 너무 단순했다.

아직 테스트 중인 DB로 검색 조건인 order_id에 대한 인덱싱을 하지 않아 Full Scan을 수행, 다른 TX가 겹치며 문제가 발생한 것.

https://medium.com/@im_zero/non-unique-index%EC%99%80-next-key-lock-b314379d9b0f

이미 실험해보신 분이 있었는데, non-indexed column에 대한 업데이트 쿼리 시 풀 스캔 후 수정 과정에서 모든 레코드에 X lock이 걸리게 된다. X lock 취득은 레코드 단위로 순차적으로 일어나는데, 먼저 시작된 TX 5427이 레코드에 대한 X lock을 거는 도중 TX 5431가 이미 S lock을 잡고 있어 수행되지 못했고, 마찬가지로 TX 5431도 쓰기 작업을 위해 X lock을 취득을 시도할 때 데드락이 발생한 것.

(공식 문서에서 찾진 못했으나 UPDATE 쿼리의 경우 읽기 단계에서 S lock을, 이후 X lock으로 재취득하는 과정이 이뤄지는 듯)

https://dev.mysql.com/doc/refman/8.4/en/innodb-locks-set.html

관련 근거는 위의 공식 문서에서 일부 확인 가능했다.

A locking read, an UPDATE, or a DELETE generally set record locks on every index record that is scanned in the processing of an SQL statement.
If you have no indexes suitable for your statement and MySQL must scan the entire table to process the statement, every row of the table becomes locked, which in turn blocks all inserts by other users to the table.

locking read, update, delete는 SQL에 의해 스캔되는 모든 index record에 record lock을 건다. 구문에 사용될 적절한 index가 없다면, MySQL은 테이블의 모든 row에 대한 lock (record)를 걸어 다른 사용자의 insert를 금지한다.

3. 해소

데드락 자체는 MySQL에서 알아서 감지하고 해소하여 수동으로 프로세스를 처리할 필요는 없었고,

인덱스를 추가하여 문제가 해소됨을 확인하였다.

검색 조건에 인덱싱을 하는 건 너무 당연한 일이다.

다만 인덱싱의 부재가 성능적 문제 외에 InnoDB의 특성으로 데드락에 걸릴 수 있다는 사실이 제법 흥미로웠다.

과거에 인덱싱되지 않은 컬럼으로 검색 시 모든 레코드에 락이 걸린다는 내용을 어렴풋이 본 것 같은데.. 실제로 테스트하며 마주친 덕분에 innodb의 동작도 다시 살펴볼 수 있었다.

@Async의 ThreadPoolTaskExecutor 설정하기

Jaehee Jeon — Sat, 15 Jun 2024 19:47:04 +0900

최신의 스프링 부트 애플리케이션에서 Async, Scheduled 등을 사용하면 가상 스레딩을 활용하지 않는 이상 ThreadPoolTaskExecutor가 구현체로 선택된다. 기본적인 설정, 종료 시점의 예약 작업 핸들링 설정 등을 설명한다.

Task Executor

스프링 어플리케이션에서 @EnableAsync 설정을 추가하고 @Async가 붙은 메서드를 런타임에 호출 시 Runnable 혹은 Callable의 형태로 스레드 풀의 Blocking Queue에 작업을 등록한 뒤 비동기로 처리된다.

비동기 처리 시 작업을 등록할 스레드 풀이 필요한데, 스프링 부트가 아닌 순수 스프링 환경에서는 별도의 설정이 없다면 AsyncExecutionInterceptor에 의해 요청마다 스레드를 새로 생성하는 SimpleAsyncTaskExecutor를 Executor로 등록한다.

스프링 부트에서는 Java 21 이상을 사용해 가상 스레드를 사용하도록 설정하는 경우에만(spring.threads.virtual.enabled = true) 스레드의 생성 작업이 비교적 가벼워 SimpleAsyncTaskExecutor를 기본 Task Executor로 등록, 이외에는 설정에 따라 풀링을 하는 ThreadPoolTaskExecutor를 등록한다.

ThreadPoolTaskExecutor

스프링에서 제공하는 Task Executor 클래스이나 내부적으로는 JDK의 스레드 풀인 ThreadPoolExecutor를 사용하며 부가 기능을 일부 포함한다. 실제 풀링 기능의 동작 방식은 JDK의 ThreadPoolExecutor를 따른다.

protected ExecutorService initializeExecutor(ThreadFactory threadFactory, RejectedExecutionHandler rejectedExecutionHandler) {
    ...
    executor = new ThreadPoolExecutor(this.corePoolSize, this.maxPoolSize, (long)this.keepAliveSeconds, TimeUnit.SECONDS, queue, threadFactory, rejectedExecutionHandler);
    ...
}

기본 설정과 동작 방식

Spring Boot를 통해 기본 생성되는 ThreadPoolTaskExecutor의 주요 풀링 관련 설정(=ThreadPoolExecutor 설정)은 아래와 같다

corePoolSize: 8
maxPoolSize: Integer.MAX_VALUE
queueCapacity: Integer.MAX_VALUE
keepAliveSeconds: 60

이 환경에서의 동작 방식은 ThreadPoolExecutor의 JavaDoc을 보면 자세히 알 수 있다.

런타임에서는 최초 크기 0의 스레드 풀로 시작한다.
스레드 풀에 작업이 등록되면 corePoolSize까지의 요청은 바로 신규 스레드가 생성되어 처리된다.
corePoolSize 이상의 요청이 동시 등록되면 Blocking Queue에 우선 작업이 쌓인다.
Blocking Queue 크기 이상의 작업이 요청되었다면 순차적으로 maxPoolSize 크기 이하의 스레드를 생성하여 작업들을 할당한다.
설정된 한도만큼의 스레드를 사용 중이며 Blocking Queue도 가득 찼으나 새로운 작업이 등록되면 RejectedExecutionHandler에 의해 처리된다(기본: RejectedExecutionException 발생)
corePoolSize 이상으로 늘어난 스레드는 이후 요청이 감소하면 keepAliveSeconds만큼 대기했다가 정리된다.

유의할 점은 corePoolSize만큼의 스레드가 동시 처리를 하는 중 신규 작업이 추가되었을 때 maxPoolSize까지 신규 스레드를 생성하는 것이 아닌, Blocking Queue에 작업을 우선적으로 등록한다는 것.

하지만 queueCapacity가 기본 Integer.MAX_VALUE이므로 기본 설정에서는 corePoolSize 크기 이상의 스레드가 할당될 일이 사실상 없고 모두 Blocking Queue에서 대기하게 된다.

이로 인해 기본 설정에서는 동시 요청이 많은 순간 @Async 메서드 콜이 몰려도 8개의 스레드에서만 작업을 처리해 비동기 작업이 지연될 수 있다.

설정 변경

두 가지 방법이 존재한다.

application.yaml 혹은 application.properties의 spring.task.execution.pool 설정을 바꿔 spring boot가 지정한 설정의 pool을 생성하도록 할 수 있다.

# application.yaml
spring:
  task:
    execution:
      pool:
        max-size: 16
        queue-capacity: 100
        keep-alive: "10s"

혹은 설정 파일에서 Executor 관련 Bean을 직접 주입하면 @Async 처리 과정에서 이 스레드 풀을 사용한다.

아래의 방법으로는 스레드 풀을 여럿 설정하여 @Async 호출 시 원하는 스레드 풀을 사용하도록 선택할 수도 있다.

@Config
public class BeanConfig {

    @Bean
    public TaskExecutor taskExecutor() {
        ThreadPoolTaskExecutor taskExecutor = new ThreadPoolTaskExecutor();
        taskExecutor.setCorePoolSize(8);
        taskExecutor.setQueueCapacity(Integer.MAX_VALUE);
        taskExecutor.setMaxPoolSize(Integer.MAX_VALUE);
        taskExecutor.initialize();
        return taskExecutor;
    }
}

만약 요청이 급증할 때 Blocking Queue를 거치지 않고 바로 신규 스레드를 생성하여 비동기 작업들을 빠르게 처리해야 한다면 queueCapacity를 0으로 설정하면 된다.

종료 시의 예약된 작업 핸들링

앱이 종료 시그널을 받고 종료되는 상황에서 기존 작업이 어떻게 정리되는지는 매우 중요한 문제다.

완전하진 않지만 아래의 두 설정을 통해 이미 예약된 작업들의 처리를 어느 정도 수행할 수 있다.

setWaitForTasksToCompleteOnShutDown()

true로 설정 시 스레드 풀을 종료하는 과정에서 ExecutorService의 shutdown()을 수행, 기본 값 false로 설정 시 shutdownNow()를 수행한다.

// ExecutorConfigurationSupport.class
public void shutdown() {
	...
    if (this.executor != null) {
        if (this.waitForTasksToCompleteOnShutdown) {
            this.executor.shutdown();
        } else {
            Iterator var1 = this.executor.shutdownNow().iterator();
            ...
        }
        this.awaitTerminationIfNecessary(this.executor);
    }
}

ExecutorService의 shutdown()은 예약된 작업들의 완료를 보장하지는 않으며, 신규 작업의 예약만 추가적으로 받아들이지 않는다.

반면 ExecutorService의 shutdownNow()는 처리 중 및 대기 중인 작업 모두를 중단 시도하고 중단된 작업들을 반환한다.

setAwaitTerminationMillis(), setAwaitTerminationSeconds()

위의 ExecutorConfigurationSupport 클래스에서 볼 수 있듯, 스레드 풀을 종료하는 과정에서는 awaitTerminationIfNecessary가 호출된다. 이 곳이 지정된 시간만큼 처리 중인 작업들이 완료되기를 기다리는 블로킹 구간이다.

두 메서드로 설정한 시간만큼 작업들의 완료를 기다리며, 시간이 초과될 시 할당되었던 스레드는 Interrupt 시킨다.

스레드 풀을 닫을 때 이미 등록된 작업의 무조건적 완료를 보장하는 방법은 제공하지 않으며, 위의 두 가지 설정을 조합하여 지정된 최대 시간 동안의 대기까지는 허용할 수 있다.

추가적인 설정

이외에도 부가적인 ThreadPoolTaskExecutor 설정 몇 개를 소개한다.

setTaskDecorator()

TaskDecorator 설정을 추가하면 스레드 풀을 통해 작업이 처리될 때 decorator의 runnable이 추가적으로 수행된다. (기본 null)

protected ExecutorService initializeExecutor(ThreadFactory threadFactory, RejectedExecutionHandler rejectedExecutionHandler) {
    ...
    if (this.taskDecorator != null) {
        executor = new ThreadPoolExecutor(this.corePoolSize, this.maxPoolSize, (long)this.keepAliveSeconds, TimeUnit.SECONDS, queue, threadFactory, rejectedExecutionHandler) {
            public void execute(Runnable command) {
                Runnable decorated = ThreadPoolTaskExecutor.this.taskDecorator.decorate(command);
                if (decorated != command) {
                    ThreadPoolTaskExecutor.this.decoratedTaskMap.put(decorated, command);
                }

                super.execute(decorated);
            }
        };
    }
    ...
}

일례로, 아래와 같이 사용 시 스레드 풀의 작업 처리 과정에서 스레드 별 로그가 출력된다.

TaskDecorator taskDecorator = runnable -> () -> log.debug("decorator");
taskExecutor.setTaskDecorator(taskDecorator);

setAllowCoreThreadTimeOut()

기본 옵션 false에서 corePool 크기 이상으로 만들어진 스레드는 유휴 상태에서 keepAliveSeconds(기본 60초) 이후 자동으로 정리되나,

corePool 크기 만큼의 스레드들(Core Thread)은 생성 이후 정리되지 않는다.

이 옵션을 true로 설정 시 Core Thread 또한 유휴 상태가 지속되면 정리된다.

setPrestartAllCoreThreads()

위에서 설명했듯, 기본 옵션 false에서는 최초 런타임에서는 비동기 요청이 시작되어야 Core Thread들이 생성된다.

true로 설정 시 마치 HikariCP와 같은 Connection Pool이 미리 pool size만큼의 커넥션을 최초 런타임에 한 번에 맺듯,

런타임 초기에 Core Thread들을 corePoolSize만큼 바로 생성해 서버의 warm up 영향을 줄일 수 있다.

Reference

https://github.com/spring-projects/spring-framework/blob/5e808ad0183a63944ab08017a13cbc7ed75bc581/spring-aop/src/main/java/org/springframework/aop/interceptor/AsyncExecutionInterceptor.java#L156

https://docs.spring.io/spring-framework/reference/integration/scheduling.html

컨테이너에서의 사용자 프로세스 제한과 UID

Jaehee Jeon — Sun, 24 Mar 2024 17:50:02 +0900

회사에서 한 장비에 수십 개의 도커 컨테이너를 동시에 운용할 상황이 생겼다.

컨테이너 각각에서 작업이 이루어지고 ssh를 통해 접속해서 확인할 수 있도록 구성하였는데,

컨테이너가 많아지자 모든 컨테이너로의 ssh 접속이 불가해졌다는 연락을 받았다.

ssh -vv로 로그를 확인하니 접속 시 인증 단계는 정상적으로 넘어가나, 셸 할당이 실패하는 상황이었다.

결론적으로는 ssh 접속 시의 사용자에 대한 프로세스 제한을 늘려주어 임시로 해소하였고,

각 컨테이너에서의 사용자 UID를 구분해 주어 근본적인 문제를 해결하였다.

컨테이너에서의 ulimit -a로 프로세스 제한을 확인했을 때는 분명 unlimited로 표시되었고,

서버 자원은 충분하며 각 컨테이너에서의 프로세스/스레드는 수백 개 수준이었는데도 프로세스 생성이 불가하여 원인을 찾는데 시간이 꽤 걸렸다. 문제를 해결하며 덕분에 컨테이너에서의 사용자 UID를 구분해야 함을 알게 되었다.

다른 컨테이너에서 같은 UID의 사용자 중 하나로 스레드 초과 실행하기

상황 재현을 위해 외부에서 ssh로 접속 가능한 컨테이너 두 개를 띄우고, 한 쪽에서만 스레드를 많이 띄워보자.

아래와 같이 `start.sh`와 Dockerfile을 만들고 컨테이너를 띄운다.

#!/bin/bash

# start.sh

/usr/sbin/sshd

tail -f /dev/null

SSH 데몬을 직접 실행시킨다.

# Dockerfile
FROM centos:7

COPY start.sh /start.sh
RUN chmod +x /start.sh

RUN yum -y install openssh-server && \
      yum clean all

RUN ssh-keygen -A

RUN useradd appuser && \
      echo "appuser:1234" | chpasswd

ENTRYPOINT ["/start.sh"]

간단하게 appuser라는 사용자를 생성한다.

docker build -t test .
docker run -d -p 10001:22 --name cont1 test
docker run -d -p 10002:22 --name cont2 test

ssh appuser@localhost -p10001 # 1234
# [appuser@server ~]$

위의 도커파일을 통해 cont1, cont2라는 컨테이너를 생성하였고,

정상적으로 ssh 접속도 가능함을 확인 가능하다.

이제 두 번째 컨테이너에 아래와 같이 더미 스레드를 생성하는 스크립트를 만들고 실행하자

(리눅스에서 프로세스와 스레드는 동일하게 취급된다)

#!/bin/bash

count="$1"

process_count=0

for ((i = 0; i < count; i++)); do
    sleep 3600 &

    process_count=$((process_count + 1))
done

# docker exec로 접속하여 실행
docker exec -u appuser -it cont2 /bin/bash
[appuser@server /]$ vi limit.sh
[appuser@server /]$ ./limit.sh 5000 # 5000개의 스레드 생성
[appuser@server /]$ ps aux | wc -l
# >> 5007

더미 스레드는 두 번째 컨테이너에 생성했지만

두 번째 컨테이너 뿐만 아니라 첫 번째 컨테이너에서도 ssh 접속이 셸 할당 단계에서 불가능해진다

ssh -vv appuser@localhost -p10001 # 프로세스가 몇 없는 1번 컨테이너로 접속

# >> ...
# >> debug2: PTY allocation request accepted on channel 0
# >> debug2: channel_input_status_confirm: type 100 id 0
# >> shell request failed on channel 0

문제 진단 및 해소

이는 Dockerfile에서 생성한 사용자의 UID가 동일한 것이 원인이다.

두 컨테이너 모두 `appuser` 일반 사용자로 접속해 UID를 확인해 보자

[appuser@server /]$ id
# >> uid=1000(appuser) gid=1000(appuser) groups=1000(appuser)

별도의 설정을 하지 않는다면 같은 UID를 가진 사용자가 만들어질 수 있다.

SSH 접속 과정에서 PAM(Pluggable Authentication Modules) 인증을 거치는데 이 과정에서 각 사용자가 생성 가능한 프로세스/스레드 수를 검사하게 된다.

제한 관련 설정은 리눅스 배포판마다 위치가 조금씩 다른데, centos7의 경우 /etc/security/limits.d/ 의 20-proc.conf에 존재한다.

redhat 계열의 linux는 이름이 다르지만 대부분 이 폴더에 존재하며, 보통 /etc/security에서의 설정들이 영향을 미친다.

# 20-nproc.conf
# Default limit for number of user's processes to prevent
# accidental fork bombs.
# See rhbz #432903 for reasoning.

*          soft    nproc     4096
root       soft    nproc     unlimited

root 이외의 사용자(*)는 프로세스 수 제한이 4096개로 기본 설정되어 있다.

root 계정으로만 설정 가능한 hard 옵션에서 지정한 범위 이하로 일반 사용자도 자신의 최대 프로세스 수를 soft옵션으로 제한 가능하다.

기본 수치는 리눅스 배포판마다 다르며 aws와 같은 서비스를 이용하는 경우 인스턴스 사양에 따라 적절히 조절된 채로 제공되니 확인이 필요하다.

기본 사용자의 상한이 4096이었으므로 스레드를 5000개 이상 실행해 버린 2번 컨테이너에는 ssh 접속 시 새로운 셸, 즉 새로운 프로세스가 appuser라는 일반 사용자 이름으로 할당되는 시점에 제한에 막혀 접속 불가 처리된 것이다.

같은 UID의 일반 사용자를 통해 1번 컨테이너에 접속이 불가능한 이유는 뭘까?

컨테이너는 다르나 UID가 같으면 사용자에 대한 프로세스/스레드 수가 검사될 때 이 수가 합산되기 때문이다.

컨테이너를 사용하면 호스트의 커널을 공유하게 되며 UID, GID 풀은 전역으로 단 하나만 공유, 관리된다.

`appuser` 사용자로 컨테이너 1에 ssh 접속을 시도하면 아래의 과정을 거쳐 실패하는 듯하다.

1. 호스트에서 ssh 요청으로 인해 새로운 셸 프로세스를 생성할 때 컨테이너 내의 사용자 `appuser`의 UID 1000으로 프로세스 수를 검색,

2. 글로벌하게 UID 1000으로 생성된 프로세스가 5000개 이상임이 확인,

3. 컨테이너 1의 `20-proc.conf`를 참조, root 이외 사용자는 4096개의 프로세스만 생성 가능하므로 셸 프로세스 생성 실패

즉, 단 하나의 프로세스를 같은 UID의 일반 사용자로 실행하는 컨테이너를 4096개 생성하면,

모든 컨테이너에서 해당 사용자로의 프로세스 생성이 불가능해지는 것이다.

만약 2번 컨테이너에만 `appuser`의 프로세스 제한을 해제하면 어떻게 될까?

# container2 20-nproc.conf

# Default limit for number of user's processes to prevent
# accidental fork bombs.
# See rhbz #432903 for reasoning.

*          soft    nproc     4096
root       soft    nproc     unlimited
appuser    soft    nproc     unlimited # appuser 사용자에 대한 process soft limit 해제

# 2번 컨테이너에 일반 사용자로 접속 시도 (성공)
ssh appuser@localhost -p10002
# >> Last login: ...
[appuser@server ~]$ ps aux | wc -l
# >> 5009

# 1번 컨테이너에 일반 사용자로 접속 시도 (실패)
ssh appuser@localhost -p10001
# >> shell request failed on channel 0

# 1번 컨테이너에 루트 사용자로 접속 시도 (성공)
ssh root@localhost -p10001
[root@server ~]$ ps aux | wc -l
# >> 7

5000개 이상의 프로세스를 실행 중인 2번 컨테이너에 `appuser`로는 접속이 가능해지고

단 7개의 프로세스를 실행 중인 1번 컨테이너에는 억울하게도 여전히 `appuser`로 접근이 불가하다.

root 사용자의 경우 프로세스 수의 제한이 없으므로 1번 컨테이너에도 접속이 가능하다.

일반 사용자들의 UID 자체를 다르게 가져가거나, 컨테이너마다 이 제한을 매번 해제해주면 문제가 해결됨을 알 수 있다.

참고로, docker exec로 /bin/bash에 진입해 스크립트를 돌리는 상황에서는 PAM 인증을 거치지 않아 일반 사용자로도 제한 이상의 프로세스를 생성할 수 있다.

예시는 SSH로의 접속을 들었으나, 같은 UID의 일반 사용자로 새로운 프로세스를 생성하는 모든 작업에선 컨테이너가 많아진다면 문제가 발생할 수 있다.

동일한 커널을 공유하는 컨테이너 기술에서는 같은 UID를 가지는 사용자를 활용하는 것은 위험하다.

컨테이너들에서 일반 사용자를 추가할 때 동적으로 다른 UID를 가지도록 관리해야 안전하다.

Reference

https://access.redhat.com/solutions/30316

https://medium.com/@mccode/understanding-how-uid-and-gid-work-in-docker-containers-c37a01d01cf

https://techblog.woowahan.com/2569/

git diff, patch 사용법

Jaehee Jeon — Sun, 4 Feb 2024 17:02:15 +0900

사내에서 diff와 patch를 다룰 일이 잦아 관련 내용을 정리해보고자 한다.
git version 2.39.2 (Apple Git-143), patch 2.0-12u11-Apple에서 확인한 내용이며 버전에 따라 출력 형식은 조금 변할 수 있다.

diff?

git diff라는 명령으로 사용 가능하다.

깃의 워킹 디렉토리와 스테이징 영역을 비교하거나, 특정 커밋과 비교하거나, 로컬과 원격 깃 레포지토리를 비교하는 명령이다.

diff 사용법

diff라는 폴더에 first.txt라는 파일을 생성해 임의의 최초 커밋을 생성한 다음,

second.txt라는 파일을 생성한 뒤 git log를 확인한 결과는 아래와 같다.

# git log
commit 8d475c23f8ac7f857ca6f1ab7790f034467e8e55 (HEAD -> main)
Author: ... <...@gmail.com>
Date:   Sun Feb 4 15:51:24 2024 +0900

    second.txt

commit a9720f836dd6385594dd0e3ac53537c3f63acf03
Author: ... <...@gmail.com>
Date:   Sun Feb 4 15:47:16 2024 +0900

    create first.txt

git diff HEAD~1..HEAD 로 HEAD에 위치한 가장 최근 커밋과 첫 번째 커밋을 비교할 수 있다.
HEAD대신 원하는 커밋의 커밋 해시(SHA)를 지정하여 비교할 수도 있다.

# git diff HEAD~1..HEAD, HEAD의 1개 이전 커밋과 HEAD를 비교, 커밋 해시로도 비교 가능
diff --git a/second.txt b/second.txt
new file mode 100644
index 0000000..86a2422
--- /dev/null
+++ b/second.txt
@@ -0,0 +1 @@
+create second.txt

어떤 디렉토리에 어떤 내용의 파일이 변경되었는지 알려준다.

`a/`, `b/` ??

실제 파일 디렉토리와 무관하게 디렉토리 앞에 a/, b/가 붙는 것을 볼 수 있다.

이는 git이 변경 사항을 관리하기 위해 임의로 붙이는 prefix로, 변경 전 디렉토리에는 a/를, 변경 후 디렉토리에는 b/를 자동으로 붙여 표현하게 된다.

이러한 prefix 없이 실제 디렉토리만을 표현하고자 한다면 --no-prefix 옵션을 붙이면 된다

`--no-prefix`

git diff시 출력에 디렉토리에 자동으로 변경 전, 후를 나타내기 위해 붙는 a/, b/와 같은 prefix를 제거할 수 있다.

--no-prefix를 추가해 diff를 출력한 결과는 아래와 같다.

# git diff HEAD~1..HEAD --no-prefix
diff --git second.txt second.txt # 옵션 없이는 diff --git a/second.txt b/second.txt 로 출력되었음
new file mode 100644
index 0000000..86a2422
--- /dev/null
+++ second.txt # 옵션 없이는 b/second.txt로 출력되었음.
@@ -0,0 +1 @@
+create second.txt

file mode?

새로운 변경에 대한 종류 및 권한 또한 표시되는 것을 볼 수 있다.

new file mode 100644

100644는 파일의 유형 및 권한을 8진수로 표현한 것이다.

앞의 100은 변경의 유형, 뒤의 644는 해당 파일의 권한을 나타낸다.

100은 일반 파일, 644는 -rw-r--r--로 소유자의 읽기 쓰기 권한, 그룹의 읽기 권한, 다른 사용자는 읽기 권한을 가진 파일임을 나타낸다.

index?

변경되는 부분이 로컬에서 어떤 해시를 부여받아 추적되는지 나타낸다.

위에서는 새로운 파일을 생성하는 경우이므로 기존 해시가 0000000였고 새로운 해시가 부여되는 것을 볼 수 있다.

git 버전에 따라 file mode와 index가 같은 행에 표시되는 경우가 존재한다.

`/dev/null`?

git으로 관리되는 프로젝트의 루트 디렉토리에 바로 파일을 생성했음에도 /dev/null이라는 파일이 사라지고 생성한 파일이 대체한 것으로 표현된다.

/dev/null은 유닉스 시스템에서 특별하게 다뤄지는 파일로 데이터를 버리고 아무 동작도 하지 않는 파일을 의미한다.

실제로 우리가 생성한 파일과 관계가 없다.

파일 생성, 수정, 삭제, 이름 변경 시의 diff

파일 생성, 수정, 삭제 시의 diff 형태를 한눈에 보면 아래와 같다.

기존의 first.txt는 삭제, second.txt는 수정, third.txt라는 파일은 새로 생성했다.

# 생성, 수정, 삭제 시의 diff
diff --git a/first.txt b/first.txt
deleted file mode 100644
index cbd2c53..0000000
--- a/first.txt
+++ /dev/null
@@ -1,2 +0,0 @@
-create first file
-
diff --git a/second.txt b/second.txt
index 86a2422..3dcf956 100644
--- a/second.txt
+++ b/second.txt
@@ -1 +1,5 @@
+prefix
+
 create second.txt
+
+postfix
diff --git a/third.txt b/third.txt
new file mode 100644
index 0000000..a1c5d2c
--- /dev/null
+++ b/third.txt
@@ -0,0 +1,2 @@
+create third.txt
+

# 이름 변경 시의 diff
diff --git a/second.txt b/second_new_name.txt
similarity index 100%
rename from second.txt
rename to second_new_name.txt

patch

git diff를 통해 얻어낸 변경 사항을 patch 라는 별도의 프로그램을 통해 git과 무관하게 적용할 수 있다.

patch를 사용하면 변경 내역을 파일로 관리, 손쉽게 변경을 적용할 수 있다.

두 사람의 git디렉토리에 first.txt만 있는 상황을 가정,

나의 로컬에서의 변경점을 원격 git 레포지토리 활용 없이 타인의 로컬에 반영하려고 한다.

#ls
first.txt

어떠한 작업을 수행하여 결과로 second.txt가 생성되었고 그 내용을 커밋하였다.

diff를 출력하면 다음과 같다.

# git diff HEAD~1..HEAD
diff --git a/second.txt b/second.txt
new file mode 100644
index 0000000..86a2422
--- /dev/null
+++ b/second.txt
@@ -0,0 +1 @@
+create second.txt

이 diff를 단순히 콘솔에 출력하지 않고 파일의 형태로 만들어내면 patch프로그램에 이를 그대로 적용 가능하다.

diff가 곧 patch file이 된다.

# 패치 파일 생성
git diff HEAD~1 HEAD > ../patch_file # 생성을 원하는 디렉토리 및 파일 명 입력

당연히 파일의 내용은 diff로 출력한 내용과 동일하다.

이제 이 패치 파일을 타인의 로컬에 그대로 전달하고,
아래와 같이 패치 파일 표준 입력으로 넣어주기만 하면 된다.

# patch 적용 전 ls
first.txt

# patch 적용
# patch -p1 < ../patch_file
patching file second.txt

# patch 적용 결과 ls
first.txt  second.txt

파일의 형태로 변경 사항을 가볍게 주고받고 적용할 수 있다.

`-p1`?

왜 굳이 p1 옵션을 붙이는 것일까?
이것은 패치 파일(diff)에 존재하는 디렉토리 정보에서 경로 정보의 상위 몇 번째 디렉토리까지 무시하고 적용할지 알리는 옵션이다.

위에서 설명했듯 --no-prefix 옵션 없이 패치 파일을 생성(diff)하면

a/, b/와 같이 git이 prefix로 별도 디렉토리 정보를 추가한 결과가 출력되므로,

diff --git a/second.txt b/second.txt # 실제 디렉토리 정보가 아닌 `a/`, `b/`가 포함됨.
new file mode 100644
index 0000000..86a2422
--- /dev/null
+++ b/second.txt
@@ -0,0 +1 @@
+create second.txt

patch 프로그램이 이를 실제로 적용할 때 디렉토리에 붙은 접두어 한 단계를 무시하고 적용하도록 하는 것이다.

당연하게도 만약 --no-prefix옵션을 주어 패치 파일을 생성했다면,
패치 적용 시에는 patch -p0 < ${patch_file}로 p0옵션을 주어야 한다.

패치 파일과 패치 적용 시의 디렉토리 옵션이 맞지 않는 경우 사용자가 직접 이 충돌을 해소해주어야 하며 실패하는 경우 Oops.rej가 남는다.

참고

단순 파일에 대한 변경의 경우 패치 파일에 권한 및 로컬 깃 인덱스 정보가 누락되어도 적용은 가능하다.

# 파일 권한 및 인덱스 정보가 없는 아래의 약식 패치 파일도 적용이 가능하다.
--- /dev/null
+++ b/second.txt
@@ -0,0 +1 @@
+create second.txt

[Java] Lambda는 JVM에서 어떻게 다뤄지는가? (invokedynamic)

Jaehee Jeon — Fri, 10 Nov 2023 03:44:04 +0900

JVM이 Lambda를 어떤 방식으로 다루는지 궁금해서 찾아보던 중 Oracle 블로그에서 Red Hat의 시니어 엔지니어인 Ben Evans가 쓴 글을 찾을 수 있었다. 이를 이해하며 Lambda가 JVM에서 어떻게 다뤄지는지 살펴보려 한다.

https://blogs.oracle.com/javamagazine/post/behind-the-scenes-how-do-lambda-expressions-really-work-in-java

blogs.oracle.com

javac, javap 모두 19.0.1을 사용하였다.

Bytecode 레벨에서 살펴보기

람다는 단순히 익명(내부) 클래스 구현을 대신하는 눈속임일까?

먼저 람다를 활용하지 않는 경우를 보자

람다를 활용하지 않는 다음의 코드를 컴파일한 후 디컴파일해서 어떻게 바이트코드가 구성되는지 살펴보자.

public class NonLambda {
    private static final String HELLO = "Hello World!";

    public static void main(String[] args) throws Exception {
        Runnable r = new Runnable() {
            @Override
            public void run() {
                System.out.println(HELLO);
            }
        };
    
        Thread t = new Thread(r);
        t.start();
        t.join();
    }
}

javac로 컴파일한 결과 두 개의 클래스로 컴파일되었다.

각각을 디컴파일한 결과는 아래와 같다.

javap -c -p NonLambda.class

javap -c -p NonLambda.class$1.class

익명 클래스는 내부 클래스를 컴파일할 때와 같이 두 개의 클래스 파일로 나눠지고, 각각을 디컴파일한 결과는 당연히 각자가 수행할 내용만을 포함한다.

이번에는 람다를 활용하는 다음의 코드를 컴파일한 후 디컴파일해서 어떻게 바이트코드가 구성되는지 살펴보자.

public class Lambda {
    private static final String HELLO = "Hello World!";

    public static void main(String[] args) throws Exception {
        Runnable r = () -> System.out.println(HELLO);
        Thread t = new Thread(r);
        t.start();
        t.join();
    }
}

javap -c -p

조금은 다른 결과가 나왔다.

컴파일 시 하나의 클래스파일만이 생성되며 디컴파일 시 람다로 동작할 내용이 모두 포함됨을 볼 수 있다.

람다로 선언한 내용은 private static 메서드로 만들어졌다.

반환형은 람다가 구현한 인터페이스 메서드의 반환형을 따른다

익명 객체와는 다른 스타일로 처리됨을 알 수 있다.

invokedynamic

바이트코드는 다르다는 것을 알았다. 하지만 그것만이 궁금한 것은 아닐 것이다.

익명 클래스와 처리 과정의 차이는 어디에서 기인하는가?

단순히 클래스 파일이 나눠지냐 합쳐지냐만 다른 것이 아니다.

람다 사용 시의 메인 메서드의 바이트코드를 자세히 보면 invokedynamic라는 opcode로 시작하는 것을 볼 수 있다.

invokedynamic은 어떠한 팩토리 메서드를 실행하는 것으로 이해하면 된다.

어떤 메서드가 main 메서드가 실행될 때 가장 먼저 실행되고 그 결과가 지역 변수에 저장되어(astore_1) 스택에 가장 먼저 쌓인다.

특이한 점은 컴파일 시점에는 이 opcode가 어떤 메서드를 호출하는지는 여기에서 결정되지 않는다는 것이다.

이는 몇 가지의 추가 정보를 포함하여 런타임에 실행된다. 리플렉션과 유사하다.

invokedynamic 옆에 써 있는 '#7, 0'을 참고하여 Constant Pool(상수 풀)과 Bootstrap Method 정보를 살펴보자.

Constant Pool

먼저 #7을 Constant Pool에서 찾아보면 다음의 정보가 나타난다.

javap -v -p

상수 풀에 #7 InvokeDynamic과 관련된 정보가 존재하는 것을 볼 수 있다.

InvokeDynamic은 다시 0번과 8번을 가리키는데,

상수 풀은 1번부터 시작하므로 0번에 대한 정보는 상수 풀에 존재하지 않으며,

8번은 NameAndType, 이름과 타입 정보가 #9, #10에 포함됨을 알린다.

9번의 이름은 임의로 결정되는 것이며(run)

10번에는 유의미한 정보인 람다의 타입 정보인 Runnable이 적혀있다.

이 타입 정보는 런타임에 invokedynamic factory가 반환할 정보가 된다.

Bootstrap Method

InvokeDynamic이 가리켰던 0번에 대한 정보는 Bootstrap Method에서 찾을 수 있다.

내용이 많아보이지만 천천히 살펴보면 복잡하지 않다.

시그니처를 보면 LambdaMetafactory 클래스의 metafactory라는 정적 메서드를 호출하는 것을 알 수 있다.

또한 이 정적 메서드의 argument로 세 개의 정보가 넘겨지는 것을 볼 수 있다.

이들은 람다에서 사용되는 시그니처에 대한 정보이다. #59는 람다의 입력, #60은 람다 바디 정보이다.

여기에서는 Void를 의미하는 ()V가 들어가 있다.

Runnable 구현은 너무 간단한 람다이니 비교를 위해 Function을 디컴파일하여 BSM(Bootstrap Method) 예시도 한번 보자.

Function<Integer, Integer> f = a -> a + 1;

람다의 입력은 타입을 명시하지 않았으므로 Object, 출력은 Integer이며 바디에서 사용되는 Integer를 포함한다.

bootstrap method에서 호출하는 LambdaMetaFactory의 metafactory로 넘어가 보자.

    public static CallSite metafactory(MethodHandles.Lookup caller,
                                       String interfaceMethodName,
                                       MethodType factoryType,
                                       MethodType interfaceMethodType,
                                       MethodHandle implementation,
                                       MethodType dynamicMethodType)
            throws LambdaConversionException {
        AbstractValidatingLambdaMetafactory mf;
        mf = new InnerClassLambdaMetafactory(Objects.requireNonNull(caller),
                                             Objects.requireNonNull(factoryType),
                                             Objects.requireNonNull(interfaceMethodName),
                                             Objects.requireNonNull(interfaceMethodType),
                                             Objects.requireNonNull(implementation),
                                             Objects.requireNonNull(dynamicMethodType),
                                             false,
                                             EMPTY_CLASS_ARRAY,
                                             EMPTY_MT_ARRAY);
        mf.validateMetafactoryArgs();
        return mf.buildCallSite();
    }

자바 버전에 따라 파라미터의 이름이 조금 다를 수 있다.

MethodType 클래스는 리턴 타입과 파라미터 타입 배열을 가지고 있다.

파라미터 중 위의 세 정보는 JVM에 의해 입력되고 마지막 세 개의 정보들은...

interfaceMethodType은 구현해야 할 메서드의 리턴 타입과 파라미터들의 타입을, (runnable은 리턴이 void)

MethodHandle은 실제 람다 내에서 실행하고자 하는 내용이 들어간다(System.out.pritnln(HELLO))

dynamicMethodtype에는 interfaceMethodType에서 제네릭 메서드를 사용했다면 제외했을 실제 타입을 넣는다.

이 메서드를 통하여 CallSite 객체를 얻어낼 수 있다.

CallSite

CallSite는 MethodHandle을 들고 있는 Holder 클래스이다.

javadoc을 보면 MethodHandle은 실행 가능한 람다 인스턴스의 참조이다.

/** MethodHandle
 * A method handle is a typed, directly executable reference to an underlying method,
 * constructor, field, or similar low-level operation, with optional
 * transformations of arguments or return values.
 * ...
 **/

dynamicInvoker()를 통해 MethodHandle을 얻어낼 수 있다.

인스턴스를 알고 있으므로 JVM은 람다를 실체화하여 실행할 수 있다.

매 람다 호출마다 전 과정이 반복되는 것은 아니며, 추상 클래스인 CallSite의 구현 중 ConstantCallSite의 형태로 람다 인스턴스를 저장하고 캐싱하여 사용한다.

Some invokedynamic call sites are effectively just lazily computed, and the method they target will never change after they have been executed the first time. This is a very common use case for ConstantCallSite, and this includes lambda expressions.

왜 이렇게 복잡한 과정을 거쳐야만 했을까?

이러한 런타임에 동작하는 리플렉션과 같은 로직은 유용하나 JIT 컴파일러에 의해 최적화되기 어렵다는 점이 치명적이다.

런타임에 매번 Method.invoke()와 같은 로직을 동적으로 수행해야 하기 때문이다.

invokedynamic을 지원함으로써 람다에 대한 인스턴스화를 런타임에 1회 진행, 상수화하고 캐싱하여 JIT 컴파일러가 최적화할 수 있는 형태로 만들게 되었다.

참고 자료

https://blogs.oracle.com/javamagazine/post/behind-the-scenes-how-do-lambda-expressions-really-work-in-java

https://www.oracle.com/a/ocom/docs/corporate/java-magazine-nov-dec-2017.pdf#page=67

정적 파일, 웹 서버, DB 스키마까지 무중단 배포 시도하기(2) - Trigger로 무중단 DB 마이그레이션 진행하기

Jaehee Jeon — Sun, 29 Oct 2023 17:58:17 +0900

버전이 올라가며 이전, 이후 버전의 DB 스키마가 크게 바뀌었다.

주요 테이블의 네이밍이 수정되었고 서비스 로직이 변경되며 컬럼의 위치도 일부 수정되었다.

개인 별로 저장되던 스터디 참여자들의 진행 정보가 기획이 수정되며 함께 관리되도록 바뀌었다.

이전 버전의 스키마

목표하는 스키마

문제: 스키마는 바꼈지만 이전 버전의 데이터도 신버전에서 실시간으로 보고 싶다

스키마의 변경 자체는 크진 않지만 신규 배포를 무중단으로 진행해야 한다는 점이 가장 큰 문제였다.

서비스에는 다음의 세 주요 기능이 존재한다.

1. 스터디 함께 진행하기

2. 혼자 공부하기(다인 스터디를 혼자 진행하는 형태)

3. 자신의 스터디 기록 조회하기

이번 배포에서는 기능이 빈약한 '1. 스터디 함께 진행하기'에 실시간 동기화 기능을 추가하는 것이 가장 큰 변경이었고,

기능이 변경되면 이전 버전과 아예 호환이 되지 않기에 구버전에서 기능을 사용하지 못하도록 선제조치를 진행했다.

배포 과정에서도 '2. 혼자 공부하기'와 '3. 자신의 스터디 기록 조회하기'는 중단이 없어야 하므로 다음의 제약사항을 해결해야 했다.

1. 이전, 이후 버전이 다른 WAS로 요청을 보내지만 사용자가 생성하는 기록은 각자의 버전에 맞춰 DB에 생성되거나 변경되는 동시에,

2. 신규 버전에선 이전 버전까지의 기록을 통합하여 확인할 수 있어야 한다.

즉, 이전 버전에서 쓰인 데이터는 1. 이전 버전대로 저장도 되며 2. 실시간으로 신버전에 맞게도 저장되어야

배포 직후 신버전을 내려받아 사용하는 사람이 구버전에서 완료한 스터디 기록을 바로 조회할 수 있다.

실패한 시도: 짧은 간격의 Schedule을 돌려 새로 추가된 내용을 신규 테이블에 복제하자

DB를 구버전, 신버전으로 나누어 해결하는 방법도 있을지 모르겠으나 이는 시간이 부족한 상황에서 선택하기 어려운 방법이었다.

불행인지 다행인지 테이블의 이름이 바꼈으므로 신버전에서 쓸 새로운 테이블을 만들고 구버전 테이블에 새로 쓰이는 데이터를 추가로 복사해서 넘겨주는 방식을 고려했다.

옛 Schema에 맞춰 삽입된 데이터를 어떻게 새로운 table에도 저장할 수 있을까?

우선 익숙한 MySQL Schedule을 사용해 해결하는 방법을 구상했다.

'lastly_updated_pks'는 마지막으로 복제 작업을 완료한 컬럼의 PK를 기억하기 위함이다.

'mapping table'은 다른 테이블의 데이터 복제 시 FK를 참조해야 하는 경우가 있어 필요하다.

LAST_INSERT_ID() 함수를 통해 신규 테이블에 insert하며 생성된 auto_increment_id를 얻을 수 있다.

이를 바탕으로 fk가 필요한 다른 테이블에도 삽입 작업을 한다. (LAST_INSERT_ID()와 관련해선 유의해야 할 점들이 있다)

한 번의 스케줄 내에서는 아래의 동작들을 한다.

0. 짧은 간격의 스케줄이 돌기 전 구버전 사용자는 old_table에 기록을, 신규 사용자는 new_table에 기록을 남긴다.

1. 스케줄 시작 시 mapping table에서 마지막으로 복사 작업을 한 데이터의 pk를 가져온다. (old table id = 7)

2. 범위 검색을 통해 마지막 스케줄 이후 old_table에 새로 삽입된 row들을 가져온다(old table id = 8, 9)

3. new_table에 스키마에 맞게 insert문을 날린다. (new_table id = 12)

4. 기존 테이블 - 복제된 데이터의 pk 정보를 mapping table에 기록한다

5. 6. 추가적인 데이터에 대해서도 insert 및 mapping table의 기록을 진행한다

7. 복제를 완료한 old table의 id를 갱신한다(7 -> 9)

총 테이블이 네 개가 변경되므로 네 테이블 모두에 대한 schedule이 필요하고, 이때 신규 테이블에서 사용 중인 FK를 참조하기 위해 각 테이블의 mapping table을 별도로 관리한다. (실제로 FK를 사용하고 있진 않으나 연관성을 나타내기 적절해 표현상으로만 쓴다.)

방법이 조금 복잡하고 일시적으로 성능은 감수해야겠지만 특정 시점부터 구 테이블에 삽입된 데이터는 신규 테이블에도 맞게 삽입된다.

적절히 짧은 시간마다 schedule이 돌게 하면 추가된 사항만 점검하므로 사용자가 체감하지 못할 수준으로 복제된다.

열심히 스케줄을 다 작성해가는 도중...

팀원이 '이거 변경에 대해서는 어떻게 복제하지?'

아....

새로운 시도: Trigger를 사용하자

짧은 간격의 스케줄로 Table Full Scan을 하며 변경을 찾아내는 건 말이 안 된다.

잠시, 아니 좀 길게 낙담했다가...

문득 MySQL에서는 바이너리 로그로 Master-Slave 간 변경을 반영하는데 이처럼

사용자 수준에서 변경(INSERT, UPDATE, DELETE)에 대한 처리를 명시적으로 해 줄 방법은 없을까? 하는 생각이 났다.

조금 뒤져보니 너무 다행히도 MySQL에는 Trigger라는 기능이 있었다.

일종의 Stored Procedure이며 테이블 단위로 INSERT, UPDATE, DELETE에 대한 이벤트 발생 시 사용자가 지정한 행위를 하도록 만들 수 있다.

아래처럼 Trigger를 만들어주었다.

DELIMITER $$
CREATE TRIGGER pomodoro_study_insert_trigger
AFTER INSERT
ON pomodoro_study
FOR EACH ROW

BEGIN
	INSERT INTO study(name, total_cycle, time_per_cycle, current_cycle, step, created_date, last_modified_date) VALUES (NEW.name, NEW.total_cycle, NEW.time_per_cycle, 1, 'PLANNING', NEW.created_date, NEW.last_modified_date);
	INSERT INTO pomodoro_study_to_study(pomodoro_study_id, study_id) VALUES
	(NEW.id, LAST_INSERT_ID());

END $$
DELIMITER ;

이렇게 적용하면 'pomodoro_study'라는 테이블에 INSERT가 발생했을 때 내가 지정한 작업,

'study'테이블에 INSERT를 수행하고, 위에서 언급한 mapping table에도 해당 정보를 기록한다.

(모든 테이블의 레코드 생성 시점이 같은 것이 아니어서 여전히 FK 참조를 위해 mapping table은 필요했다)

이와 같은 형태로 다른 테이블에도 필요한 내용의 INSERT, UPDATE Trigger를 모두 준비해 두었다.

이제 남은 고민은 예상처럼 Transaction 처리가 깔끔하게 되나? 였다.

WAS 사용 시점은 NGINX를 통해 제어가 가능하므로 '신규 테이블을 생성하는 DDL'은 먼저 입력해 두어도 문제가 없다.

1. '기존 데이터 복제', 2. 'Trigger를 통한 신규 데이터 복제' 두 가지만 같은 시점에 명령하면 되었다.

스케줄을 통해 기존 데이터 복제와 Trigger 생성을 동시에 하려고 하였으나...

Trigger는 Schedule을 통한 생성이 불가능했다.

불가피하게 데이터 복제와 Trigger 생성이 한 트랜잭션 내에서 처리가 불가능한 상황이었다.

이로 인해 1번과 2번 사이에서 사용자가 구버전의 테이블에 삽입/수정을 진행하면

Trigger가 생성되기 이전이므로 신규 테이블에 반영되지 않을 것이다.

이를 해결하기 위해 데이터 복제가 끝난 시점의 시간과 Trigger를 선언하기 직전의 시간을 기록한다.

마지막에 'last_modified_date'을 참조하여 이 사이에 변경이 있었던 기록을 다시 추적하여 직접 반영하는 스크립트를 추가로 만들었다.

WAS를 통해 DB를 사용할 땐 Locking Read를 사용하므로 복제 시점에 일시적인 성능 저하가 있을 순 있지만 현 서비스 규모에서는 크게 문제 되지 않는다 판단하였고 실제로도 그랬다.

테스트 서버에서 환경을 동일하게 구성하여 수 차례 스크립트들을 순차적으로 실행시키며 점검하였다.

꼬박 하루를 소요했지만 다행히 문제없이 DB의 무중단 마이그레이션을 진행했다.

공부노트

OpenSSH의 ControlMaster, ControlPersist를 통한 연결 비용 최소화

1. TCP connection, SSH session, channel의 관계

2. 새 session channel 생성과 연결 비용의 반복

3. Multiplexing의 핵심 아이디어

4. 슬레이브가 붙는 과정: muxclient()

5. 종료 과정: 세션 종료와 마스터 종료는 다르다

6. ControlPersist: 연결을 언제까지 들고 있을까

7. 왜 이렇게 설계했을까?

Reference

ForkJoinPool 아키텍처와 경합 최소화

1. ForkJoinPool내의 경합을 최소화환 WorkQueue Array 관리

3. Work-Stealing Deque 기반의 경합을 최소화하는 WorkQueue

3. ManagedBlocker를 통한 I/O 작업 최적화

내부적으로 ForkJoinPool이 사용되는 경우를 알아두자

CompletableFuture

Parallel Stream, Arrays.parallelSort(), 일부 Collections API

Virtual Thread

Reference

WebDAV와 NGINX의 ngx_http_dav_module

WebDAV

WebDAV의 장점

구현 기술

NGINX의 ngx_http_dav_module

NGINX 공식 이미지에는 이미 Web DAV 모듈이 존재

사용 방법

유의사항

1. PUT으로 파일 업로드 시 Content-Type을 Plain Text로 지정해야 한다.

2. 가장 눈여겨보았던 LOCK 관련 메서드나 자원의 프로퍼티 관리 관련 메서드는 지원하지 않는다.

Reference

List 초기화와 MultipleBagFetchException 발생 원인

MultipleBagFetchException

하나의 쿼리에서 둘 이상의 List를 Fetch Join으로 초기화하는 것은 불가하다.

원인: Cartesian Product를 인스턴스화하는 과정이 지나치게 비싸다

여러 개의 Set은 한 번에 초기화해도 MultipleBagsFetchException이 발생하지 않는다.

Set은 어떤 문제를 가지나?

즉시 로딩으로 여러 컬렉션을 가진 부모를 조회하면 어떨까?

[InnoDB] 인덱싱되지 않은 컬럼으로 UPDATE 시 데드락이 발생한다

1. 데드락 확인

2. 원인 분석

3. 해소

@Async의 ThreadPoolTaskExecutor 설정하기

Task Executor

ThreadPoolTaskExecutor

기본 설정과 동작 방식

설정 변경

종료 시의 예약된 작업 핸들링

setWaitForTasksToCompleteOnShutDown()

setAwaitTerminationMillis(), setAwaitTerminationSeconds()

추가적인 설정

setTaskDecorator()

setAllowCoreThreadTimeOut()

setPrestartAllCoreThreads()

Reference

컨테이너에서의 사용자 프로세스 제한과 UID

다른 컨테이너에서 같은 UID의 사용자 중 하나로 스레드 초과 실행하기

문제 진단 및 해소

Reference

git diff, patch 사용법

diff?

diff 사용법

a/, b/ ??

--no-prefix

file mode?

index?

/dev/null?

파일 생성, 수정, 삭제, 이름 변경 시의 diff

patch

-p1?

참고

[Java] Lambda는 JVM에서 어떻게 다뤄지는가? (invokedynamic)

Bytecode 레벨에서 살펴보기

람다는 단순히 익명(내부) 클래스 구현을 대신하는 눈속임일까?

invokedynamic

Constant Pool

Bootstrap Method

CallSite

왜 이렇게 복잡한 과정을 거쳐야만 했을까?

참고 자료

정적 파일, 웹 서버, DB 스키마까지 무중단 배포 시도하기(2) - Trigger로 무중단 DB 마이그레이션 진행하기

1. `ForkJoinPool`내의 경합을 최소화환 WorkQueue Array 관리

3. Work-Stealing Deque 기반의 경합을 최소화하는 `WorkQueue`

내부적으로 `ForkJoinPool`이 사용되는 경우를 알아두자

`CompletableFuture`

Parallel Stream, `Arrays.parallelSort()`, 일부 `Collections` API

`a/`, `b/` ??

`--no-prefix`

`/dev/null`?

`-p1`?