I'm Prostars

휴먼북 활동의 가벼운 회고

prostars — Fri, 28 Nov 2025 20:08:50 +0900

몇 년 전 상현도서관 휴먼북으로 등록한 후 계속 활동 상태를 유지하고 있다. 올해는 아마도 오늘 운영위원회에 참석한 게 마지막 활동일 듯하여, 가볍게 정리해 본다.

2025년에는 5개의 중·고등학교 방문 강연을 했고, 한 번의 1:1 휴먼북 세션도 진행했다. 이런 활동 덕분인지 상현도서관 운영위원회 위원 선정도 되어 보고 다양한 경험을 할 수 있었다.

내 강연을 듣고 개발자가 더 되고 싶었을지 '아, 저건 할 게 아닌 듯하다’라는 생각이 들었을지 기대 반, 걱정 반이다.

몇 달 전에 휴먼북 서면 인터뷰는 SNS에 발행되고 끝난 줄 알았는데, 해당 내용이 곧 도서관 소식지에도 실린다고 하니 한 부 요청해서 받아볼 수 있으면 좋겠다.

퇴사 후 프리랜서를 하다 보니 휴먼북 등 다양한 활동을 자유롭게 할 수 있다는 면에서는 좋다. 내년에도 이 스탠스를 유지할지 다른 무언가를 할지 아직 미정인데 뭐 어떤가. 경험을 공유할 수 있다는 건 나름 보람도 있고 좋은 활동이라고 생각한다.

내년에는 몇 번의 요청을 받게 될지 모르겠지만, 휴먼북은 계속 활동 상태로 유지하려고 한다.

맥에서 듀얼 모니터 정렬 프리셋 단축키 설정

prostars — Thu, 25 Sep 2025 14:57:05 +0900

맥북을 집과 회사와 같이 서로 다른 모니터를 확장 모니터로 연결할 땐 해당 모니터에 대한 마지막 정렬 상태로 자동으로 설정해준다. 이런 환경에서 사용할 때는 별도로 정렬 프리셋 기능이 필요하지 않다.

다만, 집에서 같은 모니터를 확장 모니터로 사용하면서 맥북을 책상에 놓고 사용하기도 하고 거치대에 올려서 사용할 때는 매번 확장 모니터 정렬을 변경해야 하는 불편함이 있다.

집에서 주로 맥북을 거치대에 올려놓고 확장 모니터의 왼쪽에 두는 정렬을 사용하면서, 맥북 모니터의 해상도는 한 단계 낮추어서 사용한다.

하지만, 요즘 맥북을 바로 내 앞에 놓고 사용할 일이 많아지면서 하루에도 몇 번씩 내렸다 올렸다 한다. 이때마다 확장 모니터 정렬을 바꾸고, 맥북 모니터의 해상도를 기본 설정으로 변경하는 게 너무 번거로워서 두 개의 프리셋을 저장해두고 단축키를 사용하여 한 번에 모니터 정렬과 해상도를 변경할 수 있게 설정하기로 했다.

이 글은 displayplacer 유틸리티와 macOS에서 기본 제공하는 Automator를 사용하여 확장 모니터 정렬 프리셋에 단축키를 지정해놓고 간편하게 확장 모니터 정렬 상태를 스위칭하는 방법을 소개한다.

단축어를 사용할 수도 있지만, 단축어를 사용하려면 '스크립트 실행 허용’을 활성화해야만 하므로 여기서는 Automator를 사용하여 2개의 프리셋을 만들고 단축키를 설정하는 과정을 단계별로 진행한다.

macOS Sequoia 15.7 환경을 기준으로 한다. 아직은 무서워서 macOS 26으로 업그레이드를 하지 않았다.

Homebrew는 설치가 되어 있다고 가정한다. 설치되어 있지 않다면, https://brew.sh 여기를 참고하여 간단히 설치할 수 있다.

displayplacer 설치

Homebrew를 사용하여 아래와 같이 간단히 설치할 수 있다.

$ brew install displayplacer

Homebrew를 사용하여 displayplacer를 설치하면 추가 설정 없이 바로 displayplacer를 사용해 볼 수 있다.

아래와 같이 현재의 모니터 정렬 상태를 확인할 수 있다.

$ displayplacer list

Homebrew를 사용하고 있지 않다면, https://github.com/jakehilborn/displayplacer/releases 에서 직접 바이너리를 받아서 사용할 수도 있지만, 페이지에 안내되어 있듯이 추가 설정이 필요하다.

Automator 빠른 동작 만들기

Automator를 실행하고 '새 문서’를 클릭하면 아래와 같이 '문서 유형 선택' 창이 열린다.

Automator

'빠른 동작’을 선택하면 아래와 같은 창이 열린다.

아래와 같이 열린 창에서 '작업’흐름 수신’을 '입력 없음’으로 바꾸고, '선택 항목 위치’는 기본 값인 '모든 응용 프로그램’을 그대로 둔다.

왼쪽 패널에서 '유틸리티’를 선택하고, '셸 스트립트 실행’을 더블 클릭하거나 오른쪽 빈 공간으로 드래그해서 작업 흐름에 '셸 스트립트 실행’을 추가해서 아래와 같은 상태로 설정한다.

Automator - 빠른 동작

Automator는 이 상태로 잠시 두고, '시스템 설정’의 '디스플레이’에서 확장 모니터 정렬과 해상도 등을 첫 번째 프리셋으로 저장할 상태로 설정한다.

거치대 사용 시 정렬

거치대 사용 시 내장 디스플레이의 해상도

나의 경우는 위와 같은 정렬로 맥북의 내장 디스플레이를 '확장된 디스플레이’로 사용하면서 한 단계 낮은 해상도를 첫 번째 프리셋으로 사용한다. 이제 터미널에서 아래와 같이 displayplacer를 실행한다.

$ displayplacer list
Persistent screen id: 749CEAFA-6416-4099-8397-2F7FA35B7E91
...
displayplacer "id:749CEAFA-6416-4099-8397-2F7FA35B7E91 res:2560x1440 hz:60 color_depth:8 enabled:true scaling:on origin:(0,0) degree:0" "id:37D8832A-2D66-02CA-B9F7-8F30A301B230 res:1280x832 hz:60 color_depth:8 enabled:true scaling:on origin:(-1280,331) degree:0"

현재 모니터 구성 정보가 출력된다. 출력된 결과에서 가장 마지막에 출력된 정보 'displayplacer "id:...degree:0"'가 필요하다.

다시 터미널에서 아래와 같이 displayplacer를 실행한다.

$ which displayplacer
/opt/homebrew/bin/displayplacer

displayplacer가 설치된 절대 경로가 출력된다. 나의 경우 '/opt/homebrew/bin/displayplacer’로 출력되었다.

이렇게 얻은 2개의 정보를 아래와 같이 조합한다.

/opt/homebrew/bin/displayplacer "id:749CEAFA-6416-4099-8397-2F7FA35B7E91 res:2560x1440 hz:60 color_depth:8 enabled:true scaling:on origin:(0,0) degree:0" "id:37D8832A-2D66-02CA-B9F7-8F30A301B230 res:1280x832 hz:60 color_depth:8 enabled:true scaling:on origin:(-1280,331) degree:0"

이 내용을 조금 전에 열어둔 Automator의 '셸 스크립트 실행' 창의 'cat’이 있는 자리에 아래와 같이 넣는다.

Automator - 빠른 동작 - 셸 스크립트 실행

이 상태에서 적당한 이름으로 저장하면 되는데, 여기서는 'DispPresetA’로 저장한다.

'DispPresetA'라는 이름으로 저장

이렇게 해서 첫 번째 프리셋 설정을 준비했고, 이제 두 번째 프리셋 설정을 진행하자.

Automator의 파일 메뉴에서 복제를 선택하고 아래와 같이 'DispPresetB’라고 이름을 지정한다.

'DispPresetB'라는 이름으로 복제

다시 Automator는 이 상태로 잠시 두고, '시스템 설정’의 '디스플레이’에서 확장 모니터 정렬과 해상도 등을 두 번째 프리셋으로 저장할 상태로 설정한다.

책상 위 사용 시 정렬

책상 위 사용 시 내장 디스플레이의 해상도

나의 경우는 위와 같은 정렬로 맥북의 내장 디스플레이를 '확장된 디스플레이’로 사용하면서 기본 해상도를 두 번째 프리셋으로 사용한다. 다시 터미널에서 아래와 같이 displayplacer를 실행한다.

$ displayplacer list
Persistent screen id: 749CEAFA-6416-4099-8397-2F7FA35B7E91
...
displayplacer "id:749CEAFA-6416-4099-8397-2F7FA35B7E91 res:2560x1440 hz:60 color_depth:8 enabled:true scaling:on origin:(0,0) degree:0" "id:37D8832A-2D66-02CA-B9F7-8F30A301B230 res:1470x956 hz:60 color_depth:8 enabled:true scaling:on origin:(545,1440) degree:0"

이 내용을 조금 전에 열어둔 Automator 'DispPresetB’의 셸 스크립트 실행' 창에 아래와 같이 넣는다.

Automator - 빠른 동작 - 셸 스크립트 실행

이 내용을 저장하고 Automator를 종료한다.

단축키 지정

'시스템 설정’의 '키보드’에서 '키보드 단축키...'를 클릭하여 열린 창에서 '서비스’를 선택하고 아래와 같이 '일반' 항목을 펼치면 위에서 생성한 'DispPresetA', 'DispPresetB’가 보인다.

시스템 설정 - 키보드 - 키보드 단축키 - 서비스 ((단축키 지정 전)

'없음' 부분을 더블 클릭하면 입력창이 열리는데 이때, 사용할 단축키를 누르면 아래와 같이 설정된다. 여기서는 'DispPresetA’에 '^⌥⌘1’를 단축키로 지정하고, 'DispPresetB’에 '^⌥⌘2’를 단축키로 지정한다.

시스템 설정 - 키보드 - 키보드 단축키 - 서비스 (단축키 지정 완료)

이렇게 오픈 소스 유틸리티와 macOS에서 기본으로 제공되는 Automator를 조합해서 macOS가 기본으로 제공하지 않는 모니터 정렬 프리셋 기능을 구성했다.

이제 지정한 단축키를 입력해 보면 확장 모니터 정렬과 해상도가 스위칭되는 것을 확인할 수 있다.

저의 첫 온라인 강의, 모든 파트가 오픈되었습니다.

prostars — Tue, 1 Jul 2025 11:43:09 +0900

안녕하세요.

저의 첫 온라인 강의가 이제 마지막 파트까지 모두 오픈되었습니다.

새로운 개념이나 기능을 프로젝트에 적용할 때마다 이해를 돕기 위한 예제를 만들면서 진행하였고, 이 과정에서 10여 개의 예제를 만들었습니다.

1개의 모놀리스 프로젝트로 시작한 채팅 시스템을 기능별로 스케일 아웃할 수 있도록 4개 역할(Authentication, Connection, Message, Push)로 분리하는 과정을 진행했습니다.

강의 마지막에는 로컬 환경에서 22개의 컨테이너와 8개의 서버 인스턴스로 채팅 시스템을 구성했습니다.

강의 파트 5에서 완성된 프로젝트는 약 12,000 라인의 코드를 가지면서 다양한 인프라스트럭처(Consul, Nginx, MySQL, Redis, Kafka)를 연동하는 단일 강의 예제 프로젝트로는 제법 큰 규모가 되었습니다.

시작할 때 20~30시간 정도로 예상했던 분량은 만들다 보니 약 55시간의 생각보다 긴 강의가 되었습니다.

도움이 되는 내용이길 바랍니다.

https://fastcampus.co.kr/dev_online_chat

대규모 채팅 플랫폼으로 한 번에 끝내는 실전 대용량 트래픽 커버 완전판 | 패스트캠퍼스

전 카톡 서버 운영자가 알려주는 채팅 플랫폼 기반 '대용량' 트래픽 처리

fastcampus.co.kr

용인시 도서관 휴먼북 인터뷰

prostars — Wed, 4 Jun 2025 16:24:55 +0900

용인시 도서관과 서면 인터뷰한 내용이 공개되어 소개한다.

올해 4, 5월에 중고등학교 두 곳에서 개발자가 하는 일에 대해 강연했고, 8월까지 세 곳을 더 진행할 예정이다.

제작 중인 온라인 강의를 20시간 기준으로 시작할 때 프로토타이핑을 해보면서 강의 시간이 초과할 걸 예상은 했지만, 2배 이상 초과할 거라고는 예상하지 못했다.

분량이 너무 늘어서 마감일에 맞추기가 좀 힘들어지고 있지만, 후반부를 작업 중이다. 글의 하단에 강의 링크와 할인 코드를 첨부한다.

https://blog.naver.com/yonginlib/223886184676

[휴먼북 인터뷰] 상현도서관 이상우 휴먼북을 소개합니다.

1. 개발자란 무엇이며 개발자가 된 계기가 있으신가요? 프로그래머, 코더, 소프트웨어 엔지니어 등 개발자...

blog.naver.com

30% 할인 코드명: 대규모채팅 (~25/6/15)

강의 링크: https://buly.kr/Edt2csp

대규모 채팅 플랫폼으로 한 번에 끝내는 실전 대용량 트래픽 커버 완전판 | 패스트캠퍼스

전 카톡 서버 운영자가 알려주는 채팅 플랫폼 기반 '대용량' 트래픽 처리

fastcampus.co.kr

Spring의 ConcurrentWebSocketSessionDecorator 소개

prostars — Mon, 28 Apr 2025 14:01:27 +0900

스프링 부트에서 단순히 웹소켓을 사용하는 건 어렵지 않다. 스프링 부트 3.4.3 기준으로 기본 설정된 서블릿 컨테이너는 임베디드 톰캣이고, 모든 TCP 처리는 서블릿 컨테이너에서 처리한다.

이 글에서는 스프링 부트에서 웹소켓을 사용할 때 멀티스레드가 하나의 세션에 동시에 메시지를 전송할 때 발생하는 문제를 확인하고 대응하는 한 가지 방법을 소개한다.

여기서 사용하는 예제는 나의 온라인 강의의 파트 2-챕터 2 'Rest API와 WebSocket의 기본’ 중에서 '08. 채팅 프로젝트를 그룹 메시지로 확장하기’에 있는 코드에서 웹소켓에 대한 처리와 테스트 코드를 가져왔다.

이 예제는 Java 17에 Spring Boot 3.4를 사용하고, 통합 테스트 구성은 Groovy 4.0에 Spock 2.4를 사용한다.

전체 코드는 GitHub에 올라가 있다. Postman을 웹소켓 클라이언트로 사용한다.

Gradle 설정은 아래와 같다.

plugins {
	id 'java'
	id 'groovy'
	id 'org.springframework.boot' version '3.4.3'
	id 'io.spring.dependency-management' version '1.1.7'
}

group = 'net.prostars'
version = '0.0.1-SNAPSHOT'

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

repositories {
	mavenCentral()
}

dependencies {
	implementation 'org.springframework.boot:spring-boot-starter-websocket'

	testImplementation 'org.springframework.boot:spring-boot-starter-test'
	testImplementation 'org.spockframework:spock-core:2.4-M5-groovy-4.0'
	testImplementation 'org.spockframework:spock-spring:2.4-M5-groovy-4.0'
	testRuntimeOnly 'org.junit.platform:junit-platform-launcher'
}

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

build.gradle

스프링 부트를 사용하므로 main 구성은 간단하게 아래와 같이 한다.

@SpringBootApplication
public class WebsocketMultiThreadExample {

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

WebsocketMultiThreadExample.java

간단한 그룹 채팅과 비슷한 동작을 구현하기 위해서 웹소켓을 텍스트 베이스로 사용한다. TextWebSocketHandler를 상속받아서 빈을 하나 만든다. 서버에 접속한 모든 웹소켓 세션은 ConcurrentHashMap을 사용해서 관리한다.

이 핸들러의 동작은 서버가 클라이언트에게 메시지를 받으면 이 메시지를 전송한 클라이언트를 제외한 나머지 모든 클라이언트에게 이 메시지를 전송한다.

핸들러의 전체 코드는 아래와 같다.

@Component
public class MessageHandler extends TextWebSocketHandler {

  private static final Logger log = LoggerFactory.getLogger(MessageHandler.class);
  protected final Map<String, WebSocketSession> sessions = new ConcurrentHashMap<>();

  @Override
  public void afterConnectionEstablished(WebSocketSession session) {
    sessions.put(session.getId(), session);
  }

  @Override
  public void afterConnectionClosed(WebSocketSession session, CloseStatus status)
      throws IOException {
    WebSocketSession webSocketSession = sessions.remove(session.getId());
    if (webSocketSession != null) {
      webSocketSession.close();
    }
  }

  @Override
  protected void handleTextMessage(WebSocketSession senderSession, TextMessage message) {
    try {
      for (WebSocketSession session : sessions.values()) {
        if (!senderSession.getId().equals(session.getId())) {
          session.sendMessage(new TextMessage(message.getPayload()));
          log.info("Send {} to {}", message.getPayload(), session.getId());
        }
      }
    } catch (Exception ex) {
      log.error("Failed to send from {} error: {}", senderSession.getId(), ex.getMessage());
    }
  }
}

handler/MessageHandler.java

핸들러를 하나 준비했으므로, 아래와 같이 웹소켓 엔드포인트에 연결해야 한다.

여기서는 엔드포인트를 '/ws/v1/message' 로 설정했다.

@Configuration
@EnableWebSocket
public class WebSocketHandlerConfig implements WebSocketConfigurer {

  private final MessageHandler messageHandler;

  public WebSocketHandlerConfig(MessageHandler messageHandler) {
    this.messageHandler = messageHandler;
  }

  @Override
  public void registerWebSocketHandlers(WebSocketHandlerRegistry registry) {
    registry.addHandler(messageHandler, "/ws/v1/message");
  }
}

config/WebSocketHandlerConfig.java

일단 필요한 구성을 다 했으니, 서버를 실행할 수 있다. 서버를 실행하면 기본 포트인 8080 포트로 임베디드 톰캣이 실행된다.
Postman을 웹소켓 클라이언트로 사용한다.

아래와 같이 'ws://localhost:8080/ws/v1/message'로 접속해서 텍스트 메시지를 보내고 받을 수 있다.
여기서는 4개의 Postman을 열어서 모두 서버에 접속한 상태에서 '좌상단, 우상단, 좌하단, 우하단' 순서로 메시지를 보냈다.
'좌상단’이 메시지를 보내면 나머지 3개의 클라이언트가 메시지를 받는다.

혼자서 4개의 클라이언트를 왔다 갔다 하며 메시지를 보내보면 잘 동작한다. 이 속도로는 멀티스레드 문제가 발생하지 않는다.

멀티스레드 문제가 발생하려면 최소한 2개의 스레드에서 거의 동시에 하나의 웹소켓 세션에 메시지 전송을 시도 해야 한다.

이런 상황이 발생하면 어떤 문제가 있는지 확인하기 위해서 통합 테스트가 필요하다. 테스트에 사용할 웹소켓 클라이언트는 서버에게 받은 메시지를 블로킹 큐에 저장하고, 테스트 코드에서 꺼내서 정상 수신 여부를 확인할 때 사용한다.

이 테스트는 3개의 클라이언트를 준비하고, 3개의 클라이언트가 각각 메시지를 연속으로 보낸다. 정상 동작은 1개의 클라이언트가 보낸 메시지를 다른 2개의 클라이언트가 받아야 한다.

클라이언트가 메시지를 받지 못하면 블로킹 큐에서 꺼낼 때 지정한 타임아웃 시간을 초과하고 null을 받는다. 모든 클라이언트가 받은 메시지를 result에 모아서 null이 포함되어 있는지 확인한다. null이 포함되었다는 건 메시지를 받지 못한 클라이언트가 있다는 것이다. 이 조건을 테스트 통과 조건으로 설정한다.

이렇게 설정하는 이유는 어떤 클라이언트가 어떤 메시지를 못 받을지는 알 수 없고, 모든 클라이언트가 메시지를 받는 정상 동작은 지금 구현에서는 테스트를 실행하는 장비의 성능이 매우 좋아야 한다. 만약, 현재 구현에서 모든 클라이언트가 메시지를 받아서 이 테스트가 실패한다면, 테스트에 참여하는 클라이언트를 몇 개 더 추가해 보자.

@SpringBootTest(
        classes = WebsocketMultiThreadExample,
        webEnvironment = SpringBootTest.WebEnvironment.RANDOM_PORT)
class SendMessageMultiThreadSpec extends Specification {

    @LocalServerPort
    int port
    
    def clientA, clientB, clientC
    
    def cleanup() {
        clientA.session?.close()
        clientB.session?.close()
        clientC.session?.close()
    }

    def 'Group Chat Basic Test'() {
        given:
        def url = "ws://localhost:${port}/ws/v1/message"
        (clientA, clientB, clientC) = [createClint(url), createClint(url), createClint(url)]

        when:
        clientA.session.sendMessage(new TextMessage('clientA: 안녕하세요. A 입니다.'))
        clientB.session.sendMessage(new TextMessage('clientB: 안녕하세요. B 입니다.'))
        clientC.session.sendMessage(new TextMessage('clientC: 안녕하세요. C 입니다.'))

        then:
        def result = (0..1).collect { clientA.queue.poll(1, TimeUnit.SECONDS) }
        result << (0..1).collect { clientB.queue.poll(1, TimeUnit.SECONDS) }
        result << (0..1).collect { clientC.queue.poll(1, TimeUnit.SECONDS) }
        
        and:
        result.contains(null)
    }

    static def createClint(String url) {
        BlockingQueue<String> blockingQueue = new ArrayBlockingQueue<>(5)
        def client = new StandardWebSocketClient()
        def webSocketSession = client.execute(new TextWebSocketHandler() {
            @Override
            protected void handleTextMessage(WebSocketSession session, TextMessage message) throws Exception {
                blockingQueue.put(message.payload)
            }
        }, url).get()

        [queue: blockingQueue, session: webSocketSession]
    }
}

SendMessageMultiThreadSpec.groovy

위의 테스트를 실행하면 서버 입장에서는 메시지 3개가 거의 동시에 들어오는 것으로 처리되고, 3개의 스레드에서 각각 전송자를 제외한 현재 연결된 모든 세션으로 메시지 전송하려고 시도한다.

예를 들어 아래와 같이 clientA는 clientB와 clientC에게 보내고 clientB는 clientA와 clientC에게 보내려고 시도한다.

이때, clientA의 스레드와 clientB의 스레드에서 clientC의 웹소켓 세션에 거의 동시에 메시지를 전송하려고 sendMessage()를 호출하는 상황이 발생한다.

이 상황이 발생하면, 아래와 같이 테스트 실행 중 서버 로그에서 'The remote endpoint was in state [TEXT_PARTIAL_WRITING] which is an invalid state for called method' 라는 에러 메시지를 확인할 수 있다.

이 에러가 발생하는 이유는 Spring WebSocketSession 인터페이스에 있는 sendMessage() 메서드의 주석을 확인해 보면 알 수 있다.

Note: The underlying standard WebSocket session (JSR-356) does not allow concurrent sending. Therefore, sending must be synchronized. To ensure that, one option is to wrap the WebSocketSession with the ConcurrentWebSocketSessionDecorator.

sendMessage()는 스레드 세이프하지 않다. 멀티스레드에서 하나의 웹소켓 세션에 sendMessage()로 메시지를 보내는 것은 허용되지 않는다고 명시되어 있다. 그리고, ConcurrentWebSocketSessionDecorator를 사용하는 방법이 있다고 안내한다.

이제 ConcurrentWebSocketSessionDecorator를 사용하면 스레드 세이프한지 확인해 보자.

ConcurrentWebSocketSessionDecorator()는 간단히 적용할 수 있다. 파라미터로 WebSocketSession과 전송 타임아웃과 전송 버퍼 크기만 설정해 주면 된다.

여기서는 타임아웃 5초, 전송 버퍼 제한은 100kb로 설정했다. 버퍼 제한을 초과했을 때의 처리는 예외를 던질지 가장 오래된 메시지를 버퍼에서 버릴지 동작을 선택할 수 있고, 설정을 생략하면 예외를 발생시키는 OverflowStrategy.TERMINATE 가 기본값으로 설정된다.

타임아웃에 대한 동작을 설정하는 기능은 없고 타임아웃이 발생하면 예외를 던진다.

아래와 같이 MessageHandler를 상속받아서 ConcurrentMessageHandler 빈을 하나 만든다.

@Component
public class ConcurrentMessageHandler extends MessageHandler {

  private static final Logger log = LoggerFactory.getLogger(ConcurrentMessageHandler.class);

  @Override
  public void afterConnectionEstablished(WebSocketSession session) {
    log.info("ConnectionEstablished: {}", session.getId());
    sessions.put(
        session.getId(), new ConcurrentWebSocketSessionDecorator(session, 5000, 100 * 1024));
  }
}

handler/ConcurrentMessageHandler.java

새로 만든 핸들러를 아래와 같이 새로운 엔드포인트 '/ws/v2/message’로 연결한다.

@Configuration
@EnableWebSocket
@SuppressWarnings("unused")
public class WebSocketHandlerConfig implements WebSocketConfigurer {

  private final MessageHandler messageHandler;
  private final ConcurrentMessageHandler concurrentMessageHandler;

  public WebSocketHandlerConfig(
      MessageHandler messageHandler, ConcurrentMessageHandler concurrentMessageHandler) {
    this.messageHandler = messageHandler;
    this.concurrentMessageHandler = concurrentMessageHandler;
  }

  @Override
  public void registerWebSocketHandlers(WebSocketHandlerRegistry registry) {
    registry
        .addHandler(messageHandler, "/ws/v1/message")
        .addHandler(concurrentMessageHandler, "/ws/v2/message");
  }
}

config/WebSocketHandlerConfig.java

이제 '/ws/v2/message’로 연결되는 웹소켓 세션은 스레드 세이프하게 동작한다.

아래와 같이 동시성 상황에서 정상 동작을 검증할 테스트를 하나 추가한다. 이 테스트는 모든 클라이언트가 기대하는 메시지를 2개씩 모두 받아서 정확히 6개의 메시지를 받았는지까지 검증한다.

def 'Group Chat Concurrent Test'() {
    given:
    def url = "ws://localhost:${port}/ws/v2/message"
    (clientA, clientB, clientC) = [createClint(url), createClint(url), createClint(url)]

    when:
    clientA.session.sendMessage(new TextMessage('clientA: 안녕하세요. A 입니다.'))
    clientB.session.sendMessage(new TextMessage('clientB: 안녕하세요. B 입니다.'))
    clientC.session.sendMessage(new TextMessage('clientC: 안녕하세요. C 입니다.'))

    then:
    def resultA = (0..1).findResults { clientA.queue.poll(1, TimeUnit.SECONDS) }.join('')
    def resultB = (0..1).findResults { clientB.queue.poll(1, TimeUnit.SECONDS) }.join('')
    def resultC = (0..1).findResults { clientC.queue.poll(1, TimeUnit.SECONDS) }.join('')
    resultA.contains('clientB') && resultA.contains('clientC')
    resultB.contains('clientA') && resultB.contains('clientC')
    resultC.contains('clientA') && resultC.contains('clientB')

    and:
    clientA.queue.isEmpty()
    clientB.queue.isEmpty()
    clientC.queue.isEmpty()
}

SendMessageMultiThreadSpec.groovy

이 테스트에서도 BlockingQueue에 테스트 클라이언트가 받은 메시지를 모았다가 모두 꺼내서 합친 후에 받은 내용을 확인하는 이유는 메시지를 받는 순서를 알 수 없기 때문이다.

테스트 코드에서 clientA, clientB, clientC 순서로 메시지를 전송한다고 서버에서 각 클라이언트의 요청을 멀티스레드로 처리할 때 테스트 코드에서 전송한 순서와 같은 순서로 처리된다는 보장은 없다. 실행해 보면 테스트는 통과한다.

ConcurrentWebSocketSessionDecorator는 지금 테스트 코드에서 사용한 것과 같은 BlockingQueue를 사용하여 멀티스레드에서 들어오는 전송 요청을 모두 큐에 넣어놓고 하나씩 꺼내서 전송해 준다. 구현체는 테스트 코드에서 간단히 사용한 ArrayBlockingQueue가 아니라 LinkedBlockingQueue를 사용한다. 내부 구현이 복잡하지 않으니 한번 열어서 보는 것도 좋다.

이렇게 멀티스레드 환경에서 웹소켓을 사용할 때 발생할 수 있는 동시성 문제 중 하나를 확인하고 간단히 대응하고 검증하는 방법까지 하나의 예제로 구성해 봤다.

이상으로 ConcurrentWebSocketSessionDecorator에 대한 소개를 마치면서, 제 강의 쿠폰을 첨부합니다.

30% 할인 코드명: 채팅플랫폼 (~25/5/12) *결제 창에서 쿠폰 코드 '채팅플랫폼' 입력.

강의 링크: https://buly.kr/Edt2csp

대규모 채팅 플랫폼으로 한 번에 끝내는 실전 대용량 트래픽 커버 완전판 | 패스트캠퍼스

전 카톡 서버 운영자가 알려주는 채팅 플랫폼 기반 '대용량' 트래픽 처리

fastcampus.co.kr

IntelliJ의 Groovy Console 소개

prostars — Tue, 4 Mar 2025 14:12:43 +0900

오래전에 'IntelliJ 의 JShell Console 을 활용하자’ 라는 포스팅을 했다.

이번에는 'IntelliJ의 Groovy Console’을 소개한다. 이 글은 Java 환경에서 JShell 대신 Groovy Console 사용하는 방법을 설명한다.

이 내용은 제 온라인 강의에서 파트 2-챕터 1 '테스트에 대한 이야기’에 있는 '04. Groovy Console 소개’와 ’05. Spock 사용을 위한 Groovy 기본 문법’ 2개의 영상에 있는 내용 중에서 'Groovy 기본 문법’에 대한 내용은 제외하고 'Groovy Console'에 대해서 일부 글로 정리한 것으로, Groovy Console에서 자바 문법을 사용하여 진행하므로 Groovy를 몰라도 무방하다.

이 글의 말미에 Java의 Lambda를 받는 Java 객체에 Groovy의 Closure를 사용할 수 있는지 확인하는 코드에만 Groovy 문법을 한번 사용한다.

코드는 모두 GitHub에 올라가 있다.

Java New Project 생성

먼저 IntelliJ에서 새 프로젝트를 하나 생성한다.

이번 예제에서 Main.java 파일은 사용하지 않으니 삭제한다.

Groovy Console 실행

IntelliJ 2024.3 버전 기준으로 Groovy 플러그인이 기본으로 활성화된 상태로 추가 설정 없이 Groovy Console을 바로 사용할 수 있다.

다만, IntelliJ의 도움말 문서 'Interactive Groovy console'에는 현재 열려있는 프로젝트 종속성에 Groovy 라이브러리가 포함되어 있지 않은 상태로 그루비 콘솔을 사용하면 번들로 제공되는 2.3.9 버전의 Groovy 가 사용될 수 있다고 설명되어 있다.

여기서 사용할 코드는 Groovy 최신 버전이 필요하지 않으니, IntelliJ가 번들로 제공하는 Groovy를 그대로 사용한다.

IntelliJ가 기본 제공하는 Groovy Console은 아래 스크린샷에 보이는 것처럼 Main Menu에서 Tools에 'Groovy Console’이라는 메뉴명을 선택하여 실행할 수 있다.

'Groovy Console’이라는 메뉴를 선택하여 실행하면 아래 스크린샷에 보이는 것처럼 'groovy_console.groovy’라는 파일명을 기본값으로 하여 파일이 하나 열린다. 파일 탭 아래에 있는 플레이 아이콘 옆에 ’Select Module...'을 클릭해서 Groovy Console이 사용할 클래스 패스를 선택할 수 있다.

여기 스크린샷에 보이는 것처럼 3개의 선택지에서 Groovy Console이 사용할 클래스 패스로 main 모듈의 클래스 패스를 선택한다.

선택하고 나면, 아래와 같이 설정이 적용된다.

이렇게 하면, 이제 Groovy Console에서 main 모듈에 있는 클래스를 사용할 수 있다.

다만, 소스 파일을 참조해서 사용하는 것이 아니라 클래스 패스에 있는 클래스 파일을 사용하는 것이라서 빌드가 먼저 되어있어야 한다.

그리고, 이 부분이 이전에 소개했던 'JShell Console’과 다른 부분이다.

'JShell Console’에서는 프로젝트의 클래스를 사용하려면 IntelliJ 프로젝트 설정에서 라이브러리 설정에 클래스 패스를 직접 등록해야 했지만, 'Groovy Console’은 이런 과정 없이 바로 사용할 수 있다.

먼저, Groovy Console이 정상 동작하는지 확인하기 위해서 간단히 'Hello World.'를 출력해 본다.

System.out.println("Hello World.")

위의 코드를 열려있는 Groovy Console 편집 창에 입력합니다. 세미콜론은 생략할 수 있다. 플레이 아이콘을 클릭하거나 단축키 Command + Enter (MacOS 기준)를 입력하면 실행된다. 실행하면 아래와 같은 실행 결과를 확인할 수 있다.

이제 Groovy Console에서 사용할 코드가 필요하니, 간단한 도서관 예제를 하나 구성하자.

// Book.java
package org.example;

public record Book(String isbn, String title, boolean available) {}

이 예제는 단독으로 실행할 프로젝트가 아니므로 BookRepository와 PushService를 인터페이스로 간단히 정의한다.

// BookRepository.java
package org.example;

import java.util.Optional;

public interface BookRepository {
  Optional<Book> findBookByIsbn(String isbn);
}

// PushService.java
package org.example;

public interface PushService {
  void notification(String message);
}

// LibraryService.java
package org.example;

import java.util.Optional;

public class LibraryService {
  private final BookRepository bookRepository;
  private final PushService pushService;

  public LibraryService(BookRepository bookRepository, PushService pushService) {
    this.bookRepository = bookRepository;
    this.pushService = pushService;
  }

  public boolean isBookAvailable(String isbn) {
    return bookRepository
            .findBookByIsbn(isbn)
            .map(Book::available)
            .orElse(false);
  }

  public Optional<String> borrowBook(String isbn) {
    return bookRepository
        .findBookByIsbn(isbn)
        .filter(Book::available)
        .map(
            book -> {
              pushService.notification(
              	"대출 완료: " + book.title());
              return book.title();
            });
  }
}

이제 Groovy Console에서 사용해 볼 클래스가 준비되었다.

위에도 언급했지만, BookRepository와 PushService는 인터페이스만 있기에 지금 준비된 코드만으로는 LibraryService를 바로 생성하여 사용할 수 없다. 하지만, Groovy Console과 같은 REPL(Read-Eval-Print Loop)은 빠른 프로토타이핑을 위해서 임시로 사용할 코드 조각을 바로 만들어서 사용해 볼 수 있다.

코드로 확인해 보자.

이제 위에서 열었던 'groovy_console.groovy' 파일로 돌아가서, 아래의 코드를 입력한다.

import org.example.Book
import org.example.BookRepository
import org.example.LibraryService
import org.example.PushService

class BookRepositoryImpl implements BookRepository {
    @Override
    Optional<Book> findBookByIsbn(String isbn) {
        return Optional.of(
        	new Book("1234", "Groovy Console", true))
    }
}

class PushServiceImpl implements PushService {
    @Override
    void notification(String message) {
        System.out.println("pushed : " + message)
    }
}

BookRepository bookRepository = new BookRepositoryImpl()
PushService pushService = 
	new PushServiceImpl()
LibraryService libraryService = 
	new LibraryService(bookRepository, pushService)

String isbn = "1234"
if (libraryService.isBookAvailable(isbn)) {
    libraryService.borrowBook(isbn)
            .ifPresentOrElse(title -> 
            	System.out.println("대출 도서 : " + title),
                    () -> System.out.println("대출 불가"))
}

위와 같이 main 클래스 패스에 있는 클래스를 사용하여 LibraryService에 주입할 BookRepositoryImpl, PushServiceImpl 클래스를 모두 하나의 파일에서 정의할 수 있다. 그리고, 준비된 클래스를 사용하여 LibraryService 객체를 생성할 수 있다.

Groovy Console에서 실행하면 아래와 같은 실행 결과를 확인할 수 있다.

위에서 구현한 인터페이스 2개가 모두 1개의 메서드만 가지고 있는 단일 추상 메서드(SAM, Single Abstract Method) 인터페이스이므로 람다로 대체할 수 있다. 우리는 REPL을 사용하고 있으니 더 간결하게 수정할 수 있는지 바로 테스트해 볼 수 있다.

아래 코드를 추가하고 실행한다.

println '--------------------------------------'
LibraryService libraryServiceUsingLambda = 
    new LibraryService(
        (String ignored) -> Optional<String>.of(
            new Book("1234", "Java Lambda", true)),
        (String message) -> println("pushed : $message"))
if (libraryServiceUsingLambda.isBookAvailable(isbn)) {
    libraryServiceUsingLambda.borrowBook(isbn)
            .ifPresentOrElse(title ->
            	System.out.println("대출 도서 : " + title),
                    () -> System.out.println("대출 불가"))
}

그러면, 아래와 같은 실행 결과를 확인할 수 있다.

이번에는 마지막으로 자바의 객체에 Lambda 대신 Groovy의 Closure를 사용할 수 있는지 테스트해 보자.

println '--------------------------------------'
LibraryService libraryServiceUsingClosure = new LibraryService(
        { Optional<String>.of(
        	new Book("1234", "Groovy Closure", true)) },
        { println("pushed : $it") })
if (libraryServiceUsingClosure.isBookAvailable(isbn)) {
    libraryServiceUsingClosure.borrowBook(isbn)
            .ifPresentOrElse({ println("대출 도서 : " + it) },
                    { System.out.println("대출 불가") })
}

위의 코드는 자바의 Lambda를 사용한 부분을 Groovy의 Closure로 교체한 코드다.

실행해보면, 아래와 같이 모두 실행됨을 확인할 수 있다.

이제 Groovy Console 에 코드가 제법 많아졌다. 매번 실행할 때마다 현재 Groovy Console에 있는 코드를 모두 실행하지 않고 일부 코드만 바로 실행해 볼 필요가 있을 때도 많다.

이럴 때는 아래와 같이 실행하고자 하는 코드만 선택해서 실행할 수 있다.

코드 블록을 선택하고 실행해 보면 아래와 같이 LibraryService의 객체가 생성되는 실행 결과를 확인할 수 있다.

하지만, 아래와 같이 코드를 선택하여 실행하면 안 된다.

현재 선택한 코드 블록에 isbn 변수 정의가 없기 때문에 에러가 발생한다.

아래와 같이 isbn 변수를 정의해주면 IntelliJ 가 친절하게 이미 존재하는 변수라고 경고한다.

이 상태에서 코드 블록 선택 없이 콘솔 전체를 실행하면, 아래와 같이 경고받은 그대로 에러가 발생한다.

하지만, 아래와 같이 블록을 선택하고 실행하면 에러 없이 실행된다.

아래와 같이 선택한 코드 블록만 실행된 결과를 확인할 수 있다.

이런 식으로, 필요에 따라서 현재 콘솔에 입력된 코드 중에서 일부 코드 조각만 선택하여 실행하고 삭제하는 등 자유롭게 작업을 계속 진행할 수 있다.

이상으로 IntelliJ의 Groovy Console에 대한 소개를 마치면서, 제 강의 쿠폰을 첨부합니다.

대규모 채팅 플랫폼으로 한 번에 끝내는 실전 대용량 트래픽 커버 완전판 | 패스트캠퍼스

전 카톡 서버 운영자가 알려주는 채팅 플랫폼 기반 '대용량' 트래픽 처리

fastcampus.co.kr

[FC 1위] 패스트캠퍼스 대용량 1위 기념! 강사 특별 할인 30% 쿠폰코드: PRDTEA250225_chat (~3/16)

저의 첫 온라인 강의가 론칭되었습니다.

prostars — Fri, 24 Jan 2025 17:01:42 +0900

안녕하세요.
2025년 새해도 벌써 한 달이 지나가고 있네요.
한동안 포스팅이 뜸했지만, 현재 작업 중인 자바 백엔드 개발 온라인 강의가 론칭되었습니다.
페이지가 공식적으로 오픈되고 나니 막연한 부담감도 있지만, 더욱 집중해서 잘 만들어보겠습니다.
이번에는 간단히 강의 소개 링크만 공유하고, 이후에는 강의 예제 중에서 하나씩 선정하여 포스팅하며 다시 소개해 보겠습니다.
새해 복 많이 받으세요.

쿠폰코드: PRDSAL250124_b (~2/9)

츠바키 문구점

prostars — Thu, 22 Aug 2024 21:50:38 +0900

올해 들어 처음 읽은 소설이다. 어쩌다 보니 인문학과 기술서만 읽었네. 그렇다고 이번에 새로 산 책도 아니다. 몇 년 전 NHN 다니던 시절에 사내 이벤트로 받은 책으로 기억한다. 독서 모임 토론 주제를 발제해야 하는데, 겸사겸사 독서 후기도 적어본다.

읽으면서 영화 '리틀 포레스트’가 생각나는 이 책은 참 몽글몽글한 느낌이다. 내가 마지막으로 서류가 아닌 종이에 무언가를 적어본 게 언제인지도 가물가물하다. 업무 다이어리도 아이패드에 사용할 수 있는 터치펜이라는 물건을 한 10년 전에 손에 넣은 이후로 모든 노트 정리는 디지털로 바뀌었다.

역시 디지털이라 10년 전 회의 시간에 딴짓한 흔적을 바로 찾아서 이 글에 붙여 넣을 수 있다.

사족이 길었지만, 지금과 같이 키보드조차 낯설어지는 모바일 시대에 손편지는 보내는 사람과 받는 사람 모두에게 강한 의미를 가지리라 생각한다. 직접 전하는 편지는 더 많은 용기가 필요할 것이고, 우편으로 전해지는 편지라면 주고받는 것도 인편을 통하며 제법 긴 시간이 걸린다. 당연히, 읽음 확인도 안 된다. (손편지를 등기로 보낸다면 또 다르겠지만...) 그럼에도 아직도 손편지를 주고받는 분들이 있을 것이고, 손편지만이 주는 느낌을 이메일이 대체할 수는 없을 것이다.

하지만, 그 손편지를 당사자가 직접 쓴 것이 아니라 다른 사람이 프로 대필가가 대필한 것이라면 어떨까? 글씨만이 아니라 내용까지 대필가를 통해 다듬어지고 대신 쓰인 것이라면 직접 쓴 손편지가 갖는 그 정성과 마음을 동일하게 가졌다고 할 수 있을까? 이 책을 읽으면서 드는 생각 중 하나였다. 이 질문에 대한 작가의 생각은 책 속에 등장한다.

전통을 지키며 잔잔하고 고즈넉하게 살아가는 주인공이 부러우면서도, 나는 저렇게 못 할 것 같다는 생각을 한다. 어디까지 지키고 유지하는 것이 전통을 지키는 것일까? 무언가를 개선하여 발전시킨다면 전통을 버리는 것일까? 가볍다면 가벼운 이 책이 여러 가지 생각을 하게 해준다.

https://www.aladin.co.kr/shop/wproduct.aspx?ItemId=117384579

츠바키 문구점

섬세한 시선으로 사람들을 따뜻하게 위로하고 치유하는 힐링 소설을 통해 많은 사랑을 받고 있는 오가와 이토의 장편소설. 문구를 파는 평범한 가게처럼 보이지만, 사실은 대대로 편지를 대필

www.aladin.co.kr

휴먼 라이브러리 소개

prostars — Sun, 16 Jun 2024 19:52:05 +0900

용인으로 이사 온 후로 상현 도서관을 애용하고 있다. 도서관 게시판에 붙어있는 안내문을 보고 휴먼 라이브러리라는 서비스가 있다는 것을 알고는 2022년에 휴먼북으로 등록했다. 휴먼북으로서의 첫 활동은 개인의 신청이 아닌 도서관의 요청으로 처인구에 있는 포곡 고등학교의 툴박스(IT) 동아리 회원을 대상으로 하는 강연이었다.

그러고는 신청자가 없어서 얼마 전에 처음으로 개인으로부터 열람 신청을 받기 전까지 잊고 있었다. 도서관의 세미나실에서 신청자를 만나 여러 질문에 답하면서 이야기를 나누었고, 다행히 도움이 되었다는 피드백을 받았다. 나의 경험과 생각이 누군가에게 도움이 된다는 것은 나에게도 의미 있는 일이고, 대화하면서 나 역시 배우는 것이 있다.

조금은 더 많은 사람들이 이 서비스를 이용했으면 하는 마음에 휴먼북 서비스를 소개하려고 한다. 여기서 소개하는 것은 용인시의 휴먼 라이브러리 서비스다.

휴먼 라이브러리

용인시 도서관 회원이라면, 여기 보이는 것처럼 다양한 분야의 휴먼북을 무료로 열람할 수 있고, 열람할 수 있는 시간과 장소는 휴먼북마다 다르다. 경기도민이면 바로 가입할 수 있다. 타지역은 추가 조건이 있다고 하는데, 도서관에 문의하면 안내받을 수 있다. 여기서 나는 "IT/컴퓨터" 분야에 "개발자로 일한다는 것, 실무에선 무엇을 하나"라는 제목으로 등록되어 있다.

Partitioner와 Multi Thread를 활용한 Spring Batch 성능 개선

prostars — Tue, 21 May 2024 20:56:38 +0900

8비트 MSX로 컴퓨터를 배웠으나 나의 첫 컴퓨터는 IBM XT였고, 꽤 오랜 기간 DOS를 사용했다. 그래서인지 아직도 배치하면 AUTOEXEC.BAT가 같이 생각난다. 이번에 정리할 내용은 많이 사용하는 스프링 배치의 성능 개선에 대한 것이다.

배경

백엔드 서비스를 운영하는 개발팀은 이미 다양한 배치를 운영하고 있을 것이고, 스프링 배치로 구현되었을 확률이 높다. 많은 배치는 서비스 사용량이 적은 새벽에 실행되고, 서비스가 작을 때는 성능에 민감하지 않아도 괜찮다. 하지만, 서비스가 커지고 배치가 처리해야 하는 데이터의 양이 증가하면서 배치의 실행 시간도 같이 증가할 것이다. 예를 들어 매일 새벽 3시에 시작하는 배치의 실행 시간이 점진적으로 증가하여 9시까지 실행되고 있다면 문제가 될 수 있고, 1시간 주기로 실행되는 배치의 실행 시간이 증가하여 1시간을 넘기면 문제가 된다. 즉, 성능을 개선해야 할 필요가 생긴 것이다. 글의 말미에서 성능 차이를 확인한다.

예제

많은 스프링 배치 예제가 배치 설명에 집중하기 위해 다루기 간편한 파일을 대상으로 I/O를 구성하고 인메모리 데이터 변환 정도로 예제를 구성한다. 하지만, 실무에서는 여러 데이터베이스와 외부 API를 사용하며 실행되는 배치들도 많다. DB를 대상으로 배치를 구성하면 배치의 성능을 개선했을 때 DB의 성능 그래프가 다르게 그려지는 것을 시각적으로 간단히 확인할 수 있다는 장점도 있다. 아래에서 볼 것이다. 이번 포스팅에서 다루는 내용의 프로젝트는 예제 치고는 크지만, 실무에서 자주 볼 수 있는 구성으로 만들었고 아래와 같다.

프로젝트 구성

MySQL 8.3 - Docker Compose 3.1
- Source Database - UserNames
- Target Database - Nicknames
Spring Boot Web 2.7
- Nickname Generator API Server
Spring Batch 4.3 - Spring Boot 2.7
- DBInitializerBatch
- MigrationBatch

코드는 모두 GitHub에 올라가 있다.

SpringBatchMultiThreadedPartitions Repository에는 2개의 Batch의 코드와 Docker Compose 구성이 있다.

NicknameGeneratorAPI Repository에는 API 서버의 코드가 있다.

이 글에서 다루는 범위

배치 예제치고는 프로젝트 구성이 복잡해진 만큼 사용된 기술 스택이 많아졌다. 이 글을 읽는 데 필요한 배경지식으로 Java, Multi Thread, Spring Framework, Spring Batch, JPA, REST API, Docker Compose, Gradle에 대한 기본적인 내용을 이해하고 있으며 Docker Compose는 설치되어 있다고 가정한다. NicknameGeneratorAPI에 대한 내용은 설명하지 않고, JPA 관련 설명도 하지 않는다. SpringBatchMultiThreadedPartitions 예제에서 job 패키지에 대한 부분을 전체가 아닌 코드 조각을 가지고 중요한 부분만 설명하는 정도로 정리한다. 2개의 예제 프로젝트에는 21개의 테스트가 준비되어 있으니 참고 바란다.

환경 설정

코드에 대한 이야기를 하기 전에 배치를 실행할 수 있도록 환경 설정을 먼저 하자.

API Server 준비

NicknameGeneratorAPI를 체크아웃 받고, 체크아웃 받은 디렉터리로 이동한다.
아래와 같이 API Server를 쉽게 종료할 수 있도록 Gradle을 사용하여 API Server를 Foreground로 실행한다.

% ./gradlew bootRun

NicknameGeneratorAPI에 대한 설명을 생략하지만, 코드가 길지 않고 단위 테스트가 준비되어 있으니, 코드를 파악하기는 쉬울 것이다.

Database 준비

새로운 터미널을 열어서 SpringBatchMultiThreadedPartitions Repo를 체크아웃 받고, 체크아웃 받은 디렉터리로 이동한다.

아래와 같이 Docker Compose와 Gradle을 사용하여 로컬에 2개의 DB를 컨테이너로 실행하고, DB를 초기화한다.

DB Server 실행

% docker-compose -f docker/docker-compose.yml up -d

DB 초기화

% ./gradlew bootRun --args='--spring.batch.job.names=DBInitializerJob'

DB 마이그레이션

% ./gradlew bootRun --args='--spring.batch.job.names=MigrationJob'

MigrationJob 배치까지 정상 실행되었다면 환경 검증은 완료한 것이다. 참고로, NicknameGeneratorAPI는 5ms의 응답 지연을 강제하고 있다. IntelliJ에서 예제의 실행을 간소화하려고 잡 파라미터 입력 대신 @Value를 사용한 Property Injection을 사용했다.

스프링 배치의 파티셔닝

스프링 배치에서 제공하는 파티셔너의 개념을 간단히 소개하면, 큰 범위를 커버하는 하나의 스탭을 여러 개의 작은 범위를 커버하는 서브 스탭으로 나누어서 실행하여 성능 향상을 기대한다. 이때 각 서브 스탭은 별도의 스레드에서 실행되며 각 서브 스탭은 완전한 스탭과 동일하게 동작한다. 파티셔닝을 사용할 수 있는지는 배치가 커버할 데이터를 나눌 수 있는가와 이렇게 나누어진 데이터가 독립적으로 처리될 수 있는가에 따라서 갈린다.

이 조건을 만족하는 데이터라면 단순히 같은 배치 잡을 여러 개 실행해도 되지 않을까? 물론, 매번 각 배치 잡의 실행 파라미터로 직접 데이터를 나누어서 넣고 실행한다면 파티셔닝과 비슷하게 여러 개의 스탭이 병렬로 실행된다. 다만, 각 스탭만 실행되는 것이 아니라 잡 자체가 별도의 JVM 프로세스로 무겁게 실행되고 일부 잡이 실패한다면 개별적으로 직접 재실행해 줘야 한다.

파티셔닝 잡의 경우는 잡을 재실행하면 실패한 서브 스탭만 이어서 실행될 것이다. 물론, 이 동작은 여러 조건과 설정 상태에 따라 다르다. 또한, 데이터를 나누는 작업을 Partitioner 인터페이스를 구현하여 자동화할 수 있기에 매번 직접 데이터를 나누어서 각 잡을 별도로 실행하지 않아도 되고 각 서브 스탭은 프로세스보다 가벼운 스레드로 분리되어 실행된다. 로컬 파니셔닝에 대해서 다루는 만큼 헷갈릴 수 있는 grid 용어 사용을 글과 예제에서 배제했다.

더 자세한 설명은 https://www.baeldung.com/spring-batch-partitioner 과 글의 말미에 소개하는 책을 참고 바란다.

멀티 스레드

자바에서는 CompletableFuture를 사용하여 간단히 멀티 스레드를 사용할 수 있다. 이 예제에서는 파티셔너를 사용하여 이미 멀티 스레드 기반의 병렬 작업이 진행되는데 CompletableFuture를 이용한 멀티 스레드를 추가로 사용하는 이유는 ItemProcessor에서 REST API를 호출하고 대기하는 시간을 줄이기 위함이다. REST API를 비동기로 사용할 수 있는 다양한 방법 중에서, RestTemplate과 CompletableFuture 조합을 선택한 이유는 추상화 레벨이 낮아서 코드가 직관적이고 예제로 적당하다고 생각한다. 그리고, 파티션의 개수를 더 늘리면 되지 않을까라고 생각할 수도 있지만 단순히 파티션을 늘리면 각 서브 스탭이 가지는 ItemReader, ItemProcessor, ItemWriter 모두 늘어나며 각 스탭이 처리하는 구간이 너무 잘게 나누어진다. 이 예제에서 CompletableFuture를 사용하면서 기대하는 것은 청크 단위에서 각 아이템 처리에 병렬성을 부여하는 것이다.

파티셔너

앞에서 언급했듯이 파티셔닝을 하려면 배치가 커버할 데이터를 나눌 수 있어야 하고, 그 기준을 구현하여 각 서브 스탭이 작업할 구간을 설정해야 한다. job 패키지에 있는 Partitioner 인터페이스를 구현한 RangePartitioner가 이 책임을 가지고 있다. 이 예제의 application.properties 파일에서 PK의 범위를 batch.range.begin, batch.range.end로 설정하고, 몇 개의 파티션을 사용할지를 batch.partition.size로 설정하고 있다. 이 설정값을 기준으로 partition 메서드는 각 서브 스탭이 담당할 구간을 나누어서 설정한다.

RangePartitioner의 단위 테스트 RangePartitionerTest에는 3개의 테스트 시나리오가 있고, 기본적인 동작을 단위 테스트로 확인해 볼 수 있다.

RangePartitionerTest
- shouldThrowExceptionWhenPartitionSizeIsZeroOrNegative
- shouldHaveEqualRangesForAllPartitions
- shouldHaveOnePartitionWithRangeOneSmaller

여기서 간단히 하나만 보자면, 아래는 shouldHaveEqualRangesForAllPartitions 라는 단위 테스트의 코드다.

@Test
void shouldHaveEqualRangesForAllPartitions() {
  // given 
  final int partitionSize = 3;

  // when
  final Map<String, ExecutionContext> partitions = partitioner.partition(partitionSize);

  // then
  final List<ExecutionContext> executionContexts = new ArrayList<>(partitions.values());
  long sum = IntStream.range(0, partitionSize)
      .mapToObj(executionContexts::get)
      .mapToLong(context -> context.getLong("subEnd") - context.getLong("subBegin") + 1)
      .sum();
  assertEquals(sum, partitioner.getEnd() - partitioner.getBegin() + 1);
}

위 테스트는 전체 구간을 3개의 파티션으로 나누었을 때, 나누어진 파티션의 구간의 총합은 전체 구간과 동일해야 한다는 것을 검증한다. 테스트 코드에서 볼 수 있듯이 partition() 함수의 리턴 타입은 ExecutionContext을 값으로 가진 맵이고 이 Context에는 각 서브 스탭이 커버할 구간 정보가 담겨있다. 이 정보는 각 서브 스텝에서 직접 접근하여 읽어온다.

PrepareTasklet의 execute()에서는 아래와 같이 접근한다.

ExecutionContext executionContext =
    chunkContext.getStepContext().getStepExecution().getExecutionContext();

SourceItemReader의 beforeStep()에서는 아래와 같이 접근한다.

final ExecutionContext executionContext = stepExecution.getExecutionContext();

스레드 풀

이 예제에서 2개의 스레드 풀을 사용한다. 하나는 파티셔너가 각 서브 스탭 실행에 사용할 스레드 풀로 PartitionerTaskExecutor에서 파티션 사이즈로 풀의 크기를 설정하고, 스레드 이름을 설정하는 등의 세부 설정을 위해 별도의 빈으로 구성한다. 나머지 하나는 TransformationItemProcessor가 RestAPI 호출을 비동기로 하기 위해 newFixedThreadPool로 청크 사이즈로 풀의 크기를 설정하고 별도의 설정 없이 간단히 생성한다.

배치 잡 구성

예제에는 DB 초기화와 마이그레이션 대상 데이터를 준비하기 위한 DBInitializerJob과 실제 마이그레이션을 진행할 MigrationJob 이 있다. 이 2개의 잡은 구성이 다르다.

DBInitializerJob

CleanTablesStep과 PrepareDataMainStep으로 구성된 Tasklet 기반으로 청크를 사용하지 않는다. CleanTablesStep은 CleanTablesTasklet을 사용하여 Source와 target DB의 데이터를 삭제하고, PrepareDataMainStep은 PrepareTasklet을 사용하여 Source DB의 마이그레이션에 사용할 Dummy Data를 채운다. 이때, RangePartitioner를 사용하여 girdSize만큼 구간을 나누고 PartitionerTaskExecutor를 사용하여 각 PrepareDataSubStep를 멀티 스레드로 실행한다.

아래는 PrepareDataMainStep의 코드다.

private Step prepareDataMainStep() {
  return stepBuilderFactory.get("PrepareDataMainStep")
      .allowStartIfComplete(true) // 반복 실행해볼 수 있도록 추가한 설정이다.
      .partitioner("PrepareDataSubStep", partitioner) // 여기서 RangePartitioner를 사용하여 구간을 나눈다.
      .gridSize(partitionSize)
      .taskExecutor(taskExecutor) // 각 스탭이 사용할 스레드 풀을 설정한다. 
      .step(prepareDataSubStep()) // 각 스레드에서 실행할 스탭을 설정한다.
      .build();
}

위에서 설명한 파티셔너와 스레드 풀을 partitioner와 taskExecutor로 주입받고, PrepareDataMainStep에 설정한다. PrepareDataMainStep은 이 두 가지를 활용하여 prepareDataSubStep을 멀티 스레드로 실행한다.

MigrationJob

MigrationJob은 Tasklet 기반 잡과 달리 청크 기반으로 Reader, Processor, Writer 구성을 사용한다.
MigrationJob 구성은 MigrationMainStep 하나로 되어있지만, MigrationMainStep이 파티셔너 설정을 가지면서 MigrationSubStep을 위에서 설명한 것과 같은 방식의 멀티 스레드로 실행한다. MigrationJob이 사용하는 Reader, Processor, Writer의 실제 구성은 MigrationSubStep에 있고, MigrationMainStep은 파티셔너 역할을 한다.

Reader, Processor, Writer의 주요 동작을 하나씩 설명하면, 아래는 SourceItemReader의 read를 구현한 코드다.

@Override
public UserNameEntity read() {
  if (nextIdx >= userNameEntities.size()) {
    nextIdx = 0;
    if (!fetch()) {
      log.info("Finished");
      return null;
    }
  }
  
  final UserNameEntity item = userNameEntities.get(nextIdx);
  nextIdx++;
  return item;
}

위 코드에서 read 메서드는 매번 DB에 접근하지 않고 메모리에 캐싱된 데이터가 있는지 확인한다. 캐싱된 데이터가 없다면, 설정된 fetch-size만큼 DB를 조회하여 메모리에 캐싱한다. 이와 같이 read()가 호출될 때마다 DB를 조회하지 않도록 캐싱 방식을 적용하여 DB 접근을 줄이고, fetch-size를 적절히 설정하면서 DB 부하를 조절할 수 있다.

참고로 return userNameEntities.get(nextIdx++); 과 같이 한 줄로 기술할 수 있는 코드를 나누어 쓴 것은 코드의 간결성보다 가독성이 중요하다고 생각하여서다.

TransformationItemProcessor는 위의 '멀티 스레드' 항목에서 설명한 청크 단위에서 각 아이템의 Rest API 호출에 병렬성을 부여하기 위해서 별도의 스레드 풀을 사용한다. 예제의 청크 사이즈는 100으로 설정되어 있고, 스레드 풀의 크기는 아래와 같이 청크 사이즈와 동일하게 설정하고 있다.

public TransformationItemProcessor(NicknameClientService nicknameClientService,
    @Value("${batch.chunk-size}") int chunkCount) {
  this.nicknameClientService = nicknameClientService;
  this.executor = Executors.newFixedThreadPool(chunkCount);
}

여기서 헷갈릴 수 있는데, 배치에서 사용하는 전체 스레드 풀의 사이즈가 100이 되는 것은 아니다. 각 파티션마다 MigrationSubStep이 실행된다. 예제의 파티션 사이즈는 10으로 설정되어 있으므로, 10 * 100 해서 전체 스레드 풀의 사이즈는 1000이 된다.

아래는 TransformationItemProcessor의 테스트 코드 중 하나다.

@Test
void testProcessWithNickname() {
  // given
  final UserNameEntity userNameEntity = new UserNameEntity("user123");
  final NicknameResponse response = new NicknameResponse("CoolUser123");
  when(nicknameClientService.generateNickname(any(NicknameRequest.class))).thenReturn(response);

  // when
  final CompletableFuture<UserNameWithNickEntity> result = processor.process(userNameEntity);

  // then
  assertNotNull(result);
  assertEquals("CoolUser123", result.join().getNick(), "The nickname should be 'CoolUser123'");
}

위 테스트는 processor가 생성한 Future를 받아서 join()으로 해당 스레드 완료 처리 후의 결과를 확인한다.

아래는 TargetItemWriter의 write를 구현한 코드다.

@Override
public void write(List<? extends CompletableFuture<UserNameWithNickEntity>> items) {
  CompletableFuture.allOf(items.toArray(new CompletableFuture[0])).join();

  final List<UserNameWithNickEntity> userNameWithNickEntities = items.stream()
      .map(future -> future.getNow(null))
      .collect(Collectors.toList());

  final List<UserNameWithNickEntity> savedItems = targetNickNameRepository.saveAll(userNameWithNickEntities);
  log.info("Chunk Finished - saved rows: {}", savedItems.size());
}

process가 청크 사이즈만큼 생성한 Future들의 완료 처리를 여기서 대기한다. getNow(null)에서 null이 거슬릴 수도 있지만, 첫 번째 join 호출로 모든 Future가 완료되었으므로 저 null이 리턴될 일은 없다. 단, Future가 예외를 캡처한 상태로 완료된 경우는 캡처된 예외가 여기서 터질 수 있다.

개발하면서 항상 염두에 두는 것이 있는데, 모든 것은 트레이드 오프라는 생각이다. 단순하고 명확한 배치 처리를 하지 않고, 굳이 이렇게 Partitioner와 CompletableFuture를 같이 사용하여 복잡도를 올렸다면 얻는 것이 있어야 한다. 파티션 사이즈와 스레드 풀의 사이즈를 변경하면서 각각의 성능 차이를 확인할 수 있다. 스크린샷은 MySQL Workbench의 Dashboard다. 배치가 DB에 주는 부하 상태를 간단히 확인할 수 있다. 대상 데이터의 크기는 100,000개다.

우선 파티셔너만 사용하는 DBInitializerBatch로 파티션 사이즈를 1, 5, 10, 15로 바꾸면서 성능을 확인하면 아래와 같다. 스크린샷의 대상 DB는 'Source Database - UserNames’다.

batch.partition.size=1

배치 실행 시간: 12s 277ms

batch.partition.size=1

batch.partition.size=5

배치 실행 시간: 5s 504ms

batch.partition.size=5

batch.partition.size=10

배치 실행 시간: 4s 718ms

batch.partition.size=10

batch.partition.size=15

배치 실행 시간: 5s173ms

batch.partition.size=15

각각의 성능 차이를 보면, 파티션을 크게 설정한다고 무조건 성능이 좋아지는 것은 아니라는 것을 알 수 있다. 배치가 실행되는 환경에 맞는 적절한 설정값을 찾아야 한다. 테스트를 단순하게 하려고 fetch-size와 chunk-size는 고정한 상태로 두었다. 여기서는 파티션 사이즈 5~10 정도에서 좋은 성능을 보여준다.

이제 멀티 스레드로 NicknameGeneratorAPI 서버에 요청을 보내고 응답을 받아서 처리하는 MigrationBatch로 스레드 풀 사이즈는 청크 사이즈와 같은 100 고정이고 파티션 사이즈를 1, 5, 10, 15로 바꾸면서 성능을 확인하면 아래와 같다. 이번 스크린샷의 대상 DB는 'Target Database - Nicknames’다.

batch.partition.size=1

배치 실행 시간: 30s 809ms

batch.partition.size=1

batch.partition.size=5

배치 실행 시간: 17s 319ms

batch.partition.size=5

batch.partition.size=10

배치 실행 시간: 17s 529ms

batch.partition.size=10

batch.partition.size=15

배치 실행 시간: 17s 529ms

batch.partition.size=15

DBInitializerBatch의 성능 결과와 비슷하게 분포되는 것을 알 수 있다. 처리 시간이 전체적으로 증가한 이유는 NicknameGeneratorAPI 서버가 응답 지연 5ms을 강제하고 있어서다. 이제 마지막으로 스레드 풀 사이즈를 1로 낮추어서 성능 차이를 보면 아래와 같다.

batch.partition.size=5 (with thread pool size=1)

배치 실행 시간: 2m 15s 162ms

batch.partition.size=5 (with thread pool size=1)

위에서 스레드 풀 사이즈 낮추기 전의 실행 결과 중에서 파티션 사이즈 5일 때의 실행 시간이 17초인데 방금 확인한 2분 15초는 매우 큰 성능 차이가 생긴 것을 알 수 있다. 이 성능 차이로 파티셔너를 사용하면서도 멀티 스레드로 API의 응답 지연을 커버하는 것이 성능 개선에 도움이 된다는 것을 알 수 있다. 이 정도면 복잡도 증가와 성능 개선의 트레이드오프를 할 만한 가치가 있다고 생각한다.

마치며

지금까지 설명한 부분은 스프링 배치에서 Partitioner와 CompletableFuture의 조합으로 하나의 JVM으로 더 효율적인 배치를 실행하는 방법의 하나다. 예제의 코드 구성에서 설명하지 않은 부분이 많지만, 이 글의 도입부에서 언급했듯이 모든 내용을 하나의 포스팅으로 정리하기에는 예제를 너무 크게 만들었다. 여기서 다루지 않은 내용은 다음 기회로 남긴다. 글을 마무리하면서 참고했던 책을 하나 소개한다.

스프링 배치 완벽 가이드 2/e
스프링 배치의 새로운 버전이 이미 나온 상황이라 이 책은 이제 구버전을 다루고 있지만, 스프링 배치를 다룬 책이 달리 없고 책의 내용도 좋다.

https://www.aladin.co.kr/shop/wproduct.aspx?ItemId=269630446

스프링 배치 완벽 가이드 2/e

스프링 배치의 Hello, World!부터 최근 플랫폼의 발전에 따른 클라우드 네이티브 기술을 활용한 배치까지 폭넓은 스프링 배치 활용 방법과 이와 관련된 유용한 내용을 다룬다.