@deveely

Vector DB - Qdrant 를 활용하여 벡터 데이터 다뤄보기

@deveely — Sun, 19 Oct 2025 23:55:30 +0900

1. Vector DB란?

Vector DB는 데이터를 벡터(숫자 배열) 형태로 저장하고 벡터 간 유사도(Similarity) 를 계산해주는 AI 특화 데이터베이스입니다.

텍스트, 이미지, 오디오처럼 비정형 데이터를 임베딩(Embedding) 모델을 통해 벡터로 변환하고 이 벡터들의 “의미적 거리”를 계산함으로써 의미 기반 검색(Semantic Search), 추천 시스템, RAG(Retrieval Augmented Generation) 등에 활용됩니다.

대표적으로 많이 사용되는 Vector DB입니다.

이름 특징 주요 사용 사례

Pinecone	완전 관리형 SaaS. 인프라 관리 불필요	빠른 RAG 구축, 대규모 상용 서비스
Qdrant	오픈소스 기반, HTTP·gRPC 모두 지원	로컬/클라우드 환경, Spring AI 연동
Weaviate	GraphQL API, 다양한 백엔드 스토리지 연동	멀티모달(텍스트+이미지) 검색

이 글에서는 Qdrant를 활용하여 Vector DB와 가까워져보고자 합니다.

2. 설치방법

Qdrant는 Docker를 활용하여 매우 간단하게 설치할 수 있습니다.

아래와 같이 이미지를 Pull 받고 실행해주면 끝입니다!

> docker pull qdrant/qdrant
> docker run -d \\
    --name qdrant \\
    -p 6333:6333 \\ // for HTTP
    -p 6334:6334 \\ // for gRPC 
    -v ~/qdrant_storage:/qdrant/storage \\ // 데이터 볼륨 설정
    qdrant/qdrant

도커 실행 명령어를 조금 들여다보면 6333 6334 2개 포트를 호스트와 연결시켜주는데요.

Qdrant는 HTTP, gRPC 2가지 통신 방식을 지원하기 때문에 서비스 특성에 맞춰 사용하시면 되겠습니다.

(참고로 gRPC에 대해 처음 접하시는 분들은 gRPC Reference - 개요 및 특징 살펴보시는것도 추천드립니다)

정상 기동 후 아래 명령으로 컬렉션 목록이 보인다면 성공입니다.

3. 간단한 실습

본격적으로 실습하기 전에 몇가지 사전지식을 알아보고 가겠습니다.

대표적으로 Collection, Point, Vector, Payload 가 있습니다.

Vector : 데이터를 임베딩하여 얻은 숫자 배열 데이터
Payload : 벡터에 대한 부연설명을 할 수 있는 메타 데이터
Point : Vector + Payload
Collection : 여러 Point 로 이뤄진 집합

즉 Collection은 Point (Payload를 같는 Vector)들의 집합이라고 정의할 수 있습니다.

Qdrant에서는 같은 Collection에 속한 모든 Vector가 동일한 차원(Dimension) 과 같은 Metric(유사도 계산 방식) 을 가져야 합니다.

대표적인 Metric 종류는 다음과 같습니다.

Metric 설명 특징 / 사용 예시

Cosine	코사인 유사도	문장, 단어 임베딩 등 방향(semantic) 이 중요한 NLP에 적합
Dot	벡터 내적	크기와 방향을 모두 반영, 이미지·멀티모달 임베딩에 자주 사용
Euclid	유클리드 거리	물리적 거리나 좌표형 데이터 등 절대 거리 기반 비교에 사용

Collection 은 아래와 같이 만들어 볼 수 있습니다.

이름을 지정하여 생성하며 size는 차원, distance는 유사도 계산 방식을 의미합니다.

> curl -X PUT "<http://localhost:6333/collections/{컬렉션명}>" -d '{
  "vectors": {
    "size": 3,
    "distance": "Cosine"
  }
}'

{"result":true,"status":"ok","time":0.059407167}

다음과 같은 방법으로 현재 만들어져있는 컬렉션 목록을 확인해볼수도 있습니다.

> curl -X GET "<http://localhost:6333/collections>"

{"result":{"collections":[{"name":"test_collection"}]},"status":"ok","time":7.667e-6}

다음으로 만들어진 컬렉션에 벡터를 저장해보겠습니다.

wait 파라미터가 true이면 동기, false면 비동기로 처리합니다

> curl -X PUT "<http://localhost:6333/collections/{컬렉션명}/points?wait=true>" -d '{
  "points": [
      {
          "id": 1,
          "payload": {"color": "red"},
          "vector": [0.9, 0.1, 0.1]
      },
      {
          "id": 2,
          "payload": {"color": "green"},
          "vector": [0.1, 0.9, 0.1]
      },
      {
          "id": 3,
          "payload": {"color": "blue"},
          "vector": [0.1, 0.1, 0.9]
      }
  ]
}'

{"result":{"operation_id":0,"status":"acknowledged"},"status":"ok","time":0.000972208}

scroll API를 활용해 조회해보면 3개 포인트가 정상적으로 조회되는 부분이 확인됩니다.

> curl -s -X POST <http://localhost:6333/collections/test_collection/points/scroll> \\
  -H "Content-Type: application/json" \\
  -d '{"limit": 10, "with_vector": false, "with_payload": true}'

{"result":{"points":[{"id":1,"payload":{"color":"red"}},{"id":2,"payload":{"color":"green"}},{"id":3,"payload":{"color":"blue"}}],"next_page_offset":null},"status":"ok","time":0.000514917}

이렇게 가볍게 컬렉션을 생성하고 벡터 저장 및 조회를 해봤습니다.

4. 마무리

Qdrant는 이 외에도 필터링, 조건 검색, Named Vector 등 다양한 고급 기능을 제공합니다.

자세한 내용은 공식 문서를 참고하시면 좋습니다.

다음 글에서는 Spring AI + Vector DB 를 활용한 RAG 아키텍쳐를 구현해보도록 하겠습니다.

[Spring AI 공식문서 읽기] 3. Advisors API

@deveely — Tue, 14 Oct 2025 09:40:18 +0900

Spring AI의 Advisors API는 Spring 애플리케이션에서 AI 기반 상호작용을 가로채고(intercept), 수정하고(modify), 향상(enhance)할 수 있는 유연하고 강력한 방법을 제공합니다.

Advisors API를 활용하면 개발자는 더 정교하고, 재사용 가능하며, 유지 관리가 용이한 AI 컴포넌트를 만들 수 있습니다.

주요 이점에는 반복되는 생성형 AI 패턴을 캡슐화하고, 대규모 언어 모델(LLM)에 보내고 받는 데이터를 변환하며, 다양한 모델과 사용 사례에서 이식성을 제공하는 것이 포함됩니다.

아래 예제와 같이 ChatClient API를 사용해 기존 Advisor를 구성할 수 있습니다

ChatMemory chatMemory = ... // Initialize your chat memory store
VectorStore vectorStore = ... // Initialize your vector store

var chatClient = ChatClient.builder(chatModel)
    .defaultAdvisors(
        MessageChatMemoryAdvisor.builder(chatMemory).build(), // chat-memory advisor
        QuestionAnswerAdvisor.builder(vectorStore).build()    // RAG advisor
    )
    .build();

var conversationId = "678";

String response = this.chatClient.prompt()
    // Set advisor parameters at runtime
    .advisors(advisor -> advisor.param(ChatMemory.CONVERSATION_ID, conversationId))
    .user(userText)
    .call()
	.content();

빌드 시점에 builder의 defaultAdvisors() 메서드를 사용하여 Advisor를 등록하는 것이 권장됩니다.

또한 Advisor는 Observability 스택에도 참여하므로, 실행과 관련된 메트릭과 트레이스를 확인할 수 있습니다.

1. 핵심 컴포넌트

Advisor API는 비스트리밍(non-streaming) 시나리오를 위한 CallAdvisor 와 CallAdvisorChain,

스트리밍(streaming) 시나리오를 위한 StreamAdvisor 와 StreamAdvisorChain으로 구성됩니다.

또한 프롬프트 요청을 표현하는 ChatClientRequest 와 채팅 완료(Chat Completion) 응답을 표현하는 ChatClientResponse를 포함합니다.

이 두 객체 모두 advisor 체인 전체에서 상태를 공유하기 위한 advise-context를 보유하고 있습니다.

adviseCall() 과 adviseStream() 메서드는 Advisor의 핵심 메서드로, 일반적으로 다음과 같은 작업을 수행합니다.

unsealed Prompt 데이터 검사
Prompt 데이터 커스터마이징 및 보강(augmenting)
advisor 체인의 다음 엔티티 호출
요청을 차단(옵션)
Chat Completion 응답 검사
처리 오류를 나타내기 위해 예외 발생

또한 getOrder() 메서드는 체인 내에서 Advisor의 실행 순서를 결정하며 getName() 메서드는 고유한 Advisor 이름을 제공합니다.

Spring AI 프레임워크가 생성하는 Advisor Chain은 getOrder() 값에 따라 정렬된 여러 Advisor를 순차적으로 호출할 수 있도록 합니다. 값이 낮을수록 먼저 실행되며, 마지막 Advisor(자동으로 추가됨)가 실제로 요청을 LLM에 전달합니다.

아래 흐름도는 Advisor Chain과 Chat Model 간의 상호작용을 설명합니다.

Spring AI 프레임워크는 사용자의 Prompt 로부터 ChatClientRequest 를 생성하고, 빈 advisor context 객체를 함께 초기화합니다.
체인에 포함된 각 Advisor는 요청을 처리하며 필요하면 이를 수정할 수 있습니다. 또는 요청을 다음 엔티티에 전달하지 않고 차단(block) 할 수도 있으며, 이 경우 해당 Advisor가 직접 응답을 작성해야 합니다.
프레임워크에서 제공하는 마지막 Advisor가 최종적으로 요청을 Chat Model에 전달합니다.
Chat Model이 반환한 응답은 다시 Advisor Chain을 거치며 전달되고, 이 과정에서 응답은 ChatClientResponse 로 변환됩니다. 이 객체에는 공유된 advisor context 인스턴스가 포함됩니다.
각 Advisor는 이 단계에서 응답을 검사하거나 수정할 수 있습니다.
최종적으로 완성된 ChatClientResponse 는 ChatCompletion 을 추출하여 클라이언트에 반환됩니다.

1.1. Advisor Order

Advisor 체인에서 실행 순서는 getOrder() 메서드에 의해 결정됩니다.

값이 낮은 Advisor가 먼저 실행됩니다.
Advisor 체인은 **스택(stack)**처럼 동작합니다:
- 체인의 첫 번째 Advisor가 요청(request)을 가장 먼저 처리합니다.
- 동시에 이 Advisor가 응답(response)을 가장 마지막에 처리합니다.
실행 순서를 제어하려면:
- Ordered.HIGHEST_PRECEDENCE(가장 작은 값)에 가깝게 설정하면 Advisor가 요청을 가장 먼저 처리하고 응답을 가장 마지막에 처리하게 됩니다.
- Ordered.LOWEST_PRECEDENCE(가장 큰 값)에 가깝게 설정하면 Advisor가 요청을 가장 마지막에 처리하고 응답을 가장 먼저 처리하게 됩니다.
값이 클수록 우선순위가 낮게 해석됩니다.
여러 Advisor가 동일한 order 값을 가진 경우, 실행 순서는 보장되지 않습니다.

참고로, 다음은 Spring Ordered 인터페이스의 의미(동작 방식)입니다:

public interface Ordered {

    /**
     * Constant for the highest precedence value.
     * @see java.lang.Integer#MIN_VALUE
     */
    int HIGHEST_PRECEDENCE = Integer.MIN_VALUE;

    /**
     * Constant for the lowest precedence value.
     * @see java.lang.Integer#MAX_VALUE
     */
    int LOWEST_PRECEDENCE = Integer.MAX_VALUE;

    /**
     * Get the order value of this object.
     * <p>Higher values are interpreted as lower priority. As a consequence,
     * the object with the lowest value has the highest priority (somewhat
     * analogous to Servlet {@code load-on-startup} values).
     * <p>Same order values will result in arbitrary sort positions for the
     * affected objects.
     * @return the order value
     * @see #HIGHEST_PRECEDENCE
     * @see #LOWEST_PRECEDENCE
     */
    int getOrder();
}

<aside>

입력과 출력 양쪽에서 모두 체인의 첫 번째가 되어야 하는 사용 사례의 경우:

입력용 Advisor와 출력용 Advisor를 별도로 구현합니다.
각각을 다른 order 값으로 설정합니다.
두 Advisor 간에 상태를 공유하기 위해 advisor context를 사용합니다. </aside>

2. API 개요

주요 Advisor 인터페이스들은 org.springframework.ai.chat.client.advisor.api 패키지에 위치해 있습니다. 커스텀 Advisor를 만들 때 접하게 될 핵심 인터페이스들은 다음과 같습니다.

public interface Advisor extends Ordered {
	
	String getName();
	
}

동기식 및 반응형 방식을 위한 두가지 서브 인터페이스가 있습니다.

public interface CallAdvisor extends Advisor { // sync

	ChatClientResponse adviseCall(
		ChatClientRequest chatClientRequest, CallAdvisorChain callAdvisorChain);

}

public interface StreamAdvisor extends Advisor { // reactive

	Flux<ChatClientResponse> adviseStream(
		ChatClientRequest chatClientRequest, StreamAdvisorChain streamAdvisorChain);

}

각 방식에 해당하는 Advisor가 실행되기 위한 체인도 동작방식별로 존재합니다.

public interface CallAdvisorChain extends AdvisorChain {

	/**
	 * Invokes the next {@link CallAdvisor} in the {@link CallAdvisorChain} with the given
	 * request.
	 */
	ChatClientResponse nextCall(ChatClientRequest chatClientRequest);

	/**
	 * Returns the list of all the {@link CallAdvisor} instances included in this chain at
	 * the time of its creation.
	 */
	List<CallAdvisor> getCallAdvisors();

}

public interface StreamAdvisorChain extends AdvisorChain {

	/**
	 * Invokes the next {@link StreamAdvisor} in the {@link StreamAdvisorChain} with the
	 * given request.
	 */
	Flux<ChatClientResponse> nextStream(ChatClientRequest chatClientRequest);

	/**
	 * Returns the list of all the {@link StreamAdvisor} instances included in this chain
	 * at the time of its creation.
	 */
	List<StreamAdvisor> getStreamAdvisors();

}

3. Advisor 구현

Advisor를 생성하려면 CallAdvisor 또는 StreamAdvisor(또는 둘 다)를 구현하면 됩니다. 핵심 메서드는 논스트리밍의 경우 nextCall()이고, 스트리밍 advisor의 경우 nextStream()입니다.

3.1 Examples

관찰(observing) 및 보강(augmenting) 사용 사례를 구현하는 방법을 보여주기 위해 몇 가지 실습 예제를 제공하겠습니다.

3.1.1 Logging Advisor

체인에서 다음 Advisor를 호출하기 전에는 ChatClientRequest, 호출한 후에는 ChatClientResponse를 로깅하는 간단한 로깅 Advisor를 구현할 수 있습니다. 이 Advisor는 요청과 응답을 관찰만 하며 수정하지는 않습니다. 본 구현은 비스트리밍과 스트리밍 시나리오를 모두 지원합니다.

public class SimpleLoggerAdvisor implements CallAdvisor, StreamAdvisor {

	private static final Logger logger = LoggerFactory.getLogger(SimpleLoggerAdvisor.class);

	@Override
	public String getName() {
	  // Advisor 에 유니크한 이름 제공
		return this.getClass().getSimpleName();
	}

	@Override
	public int getOrder() {
	  // 실행 순서 제어
		return 0;
	}

	@Override
	public ChatClientResponse adviseCall(ChatClientRequest chatClientRequest, CallAdvisorChain callAdvisorChain) {
		logRequest(chatClientRequest);

		ChatClientResponse chatClientResponse = callAdvisorChain.nextCall(chatClientRequest);

		logResponse(chatClientResponse);

		return chatClientResponse;
	}

	@Override
	public Flux<ChatClientResponse> adviseStream(ChatClientRequest chatClientRequest,
			StreamAdvisorChain streamAdvisorChain) {
		logRequest(chatClientRequest);

		Flux<ChatClientResponse> chatClientResponses = streamAdvisorChain.nextStream(chatClientRequest);

		return new ChatClientMessageAggregator().aggregateChatClientResponse(chatClientResponses, this::logResponse);
	}

	private void logRequest(ChatClientRequest request) {
		logger.debug("request: {}", request);
	}

	private void logResponse(ChatClientResponse chatClientResponse) {
		logger.debug("response: {}", chatClientResponse);
	}

}

스트리밍 방식 예제에서 사용된 MessageAggregator는 Flux 형태의 응답들을 단일 ChatClientResponse로 집계하는 유틸리티 클래스입니다. 이는 스트림의 개별 항목이 아니라 전체 응답을 관찰해야 하는 로깅 또는 기타 처리에 유용합니다. 또한 읽기 전용으로 동작하므로, MessageAggregator 내부에서는 응답을 변경할 수 없습니다.

3.3.2 Re-Reading (Re2) Advisor

Re-Reading Improves Reasoning in Large Language Models라는 논문에서는 Re-Reading(Re2) 이라는 기법을 소개합니다. 이 기법은 대규모 언어 모델(LLM) 의 추론(reasoning) 능력을 향상시키는 방법으로, 입력 프롬프트를 아래와 같이 보강(augmenting) 하는 과정을 필요로 합니다.

{Input_Query}
Read the question again: {Input_Query}

LoggingAdvisor 예시와 달리 before, after 로 나누어 접근하는 방법도 존재합니다.

Re2 적용은 요청 전 단계에서만 작업하면 되므로 before 메서드를 활용하여 구현할 수 있습니다.

public class ReReadingAdvisor implements BaseAdvisor {

	private static final String DEFAULT_RE2_ADVISE_TEMPLATE = """
			{re2_input_query}
			Read the question again: {re2_input_query}
			""";

	private final String re2AdviseTemplate;

	private int order = 0;

	public ReReadingAdvisor() {
		this(DEFAULT_RE2_ADVISE_TEMPLATE);
	}

	public ReReadingAdvisor(String re2AdviseTemplate) {
		this.re2AdviseTemplate = re2AdviseTemplate;
	}

	@Override
	public ChatClientRequest before(ChatClientRequest chatClientRequest, AdvisorChain advisorChain) { 
	  // 요청에서 사용자 입력 프롬프트를 Re2 적용된 프롬프트로 바꾼다
		String augmentedUserText = PromptTemplate.builder()
			.template(this.re2AdviseTemplate)
			.variables(Map.of("re2_input_query", chatClientRequest.prompt().getUserMessage().getText()))
			.build()
			.render();

		return chatClientRequest.mutate()
			.prompt(chatClientRequest.prompt().augmentUserMessage(augmentedUserText))
			.build();
	}

	@Override
	public ChatClientResponse after(ChatClientResponse chatClientResponse, AdvisorChain advisorChain) {
		return chatClientResponse;
	}

	@Override
	public int getOrder() { 
		return this.order;
	}

	public ReReadingAdvisor withOrder(int order) {
		this.order = order;
		return this;
	}

}

3.3.3. Spring Built-in Advisors

Spring AI Framework 에서는 AI와 여러 상호작용을 하기 위한 여러 built-in advisor를 제공합니다.

유형 Advisor 이름 설명

Chat Memory Advisors	MessageChatMemoryAdvisor	메모리를 검색하여 메시지 컬렉션으로 프롬프트에 추가. 대화 히스토리 구조 유지. (모든 AI 모델이 지원하는 것은 아님)
	PromptChatMemoryAdvisor	메모리를 검색하여 프롬프트의 시스템 텍스트에 통합
	VectorStoreChatMemoryAdvisor	VectorStore에서 메모리를 검색하여 프롬프트의 시스템 텍스트에 추가. 대규모 데이터셋에서 효율적인 검색 및 정보 추출에 유용
Question Answering Advisor	QuestionAnswerAdvisor	Vector Store를 사용하여 질의응답 기능 제공. 일반적인 RAG 패턴 구현
	RetrievalAugmentationAdvisor	org.springframework.ai.rag 패키지의 빌딩 블록을 사용하여 일반적인 RAG 플로우 구현. Modular RAG Architecture 기반
Reasoning Advisor	ReReadingAdvisor	LLM 추론을 위한 RE2(Re-Reading) 전략 구현. 입력 단계에서 이해력 향상. 논문 기반
Content Safety Advisor	SafeGuardAdvisor	모델이 유해하거나 부적절한 콘텐츠를 생성하지 않도록 방지하는 간단한 Advisor

3.4. Streaming VS Non-streaming

Non-streaming Advisor 는 요청, 응답을 단일객체로 한번에 처리합니다.

요청 → [Advisor 1] → [Advisor 2] → [Chat Model - 10초 대기] 
                                        ↓
                                    "AI는 인공지능입니다..."
                                        ↓
응답 ← [Advisor 1] ← [Advisor 2] ← 완성된 응답

Streaming Advisor는 요청은 한번 처리하되 응답은 여러 번 호출될 수 있습니다.
- 응답 Chunk 만큼 수행될 수 있음

요청 → [Advisor 1] → [Advisor 2] → [Chat Model]
                                        ↓
                                    "AI는" (0.1초)
                                        ↓
응답 조각1 ← [Advisor 1 AFTER] ← [Advisor 2 AFTER] ← "AI는"
                                        ↓
                                    "인공지능을" (0.2초)
                                        ↓
응답 조각2 ← [Advisor 1 AFTER] ← [Advisor 2 AFTER] ← "인공지능을"
                                        ↓
                                    "의미합니다" (0.3초)
                                        ↓
응답 조각3 ← [Advisor 1 AFTER] ← [Advisor 2 AFTER] ← "의미합니다"

Logging 을 예시로 보면 아래와 같이 동작할 수 있습니다.

// Non-streaming: 전체 응답 한 번에 로깅
.map(response -> {
    log.info("완성된 응답: {}", response.getContent());
    // 출력: "완성된 응답: AI는 인공지능을 의미합니다..."
    return response;
});

// Streaming: 각 조각마다 로깅
.map(chunk -> {
    log.info("응답 조각: {}", chunk.getContent());
    // 출력1: "응답 조각: AI는"
    // 출력2: "응답 조각: 인공지능을"
    // 출력3: "응답 조각: 의미합니다"
    return chunk;
});

3.5 Best Practices

특정 Advisor가 특정 작업에 집중하도록 구현한다 (모듈화)
Advisor 간 상태 공유가 필요한 경우 adviseContext 를 활용한다.
유연성을 극대화하기 위해 Advisor 구현 시 Streaming, Non-streaming 방식 모두 구현하는 것이 좋다.
적절한 데이터 흐름을 보장하기 위해 Advisor 체인 순서를 잘 구성하는 것이 중요하다

[Spring AI 공식문서 읽기] 2. ChatClient API

@deveely — Sun, 5 Oct 2025 01:18:45 +0900

0. Overview

Spring AI의 ChatClient는 AI 모델과 대화하기 위한 도구입니다.

동기식과 스트리밍 방식을 모두 지원하고,
Fluent API로 프롬프트를 쉽게 구성할 수 있습니다.

프롬프트는 사용자 메시지와 시스템 메시지로 이루어지며, 실행 시점에 변수를 치환할 수 있는 플레이스홀더도 활용할 수 있습니다. 또한 사용할 AI 모델 종류와 temperature 값 같은 옵션을 통해 답변의 톤과 창의성을 조절할 수 있습니다.

1. ChatClient 생성

ChatClient 는 ChatClient.Builder 를 통해 생성할 수 있습니다.

Spring Boot 환경에서는 자동 구성된 ChatClient.Builder 를 주입받아 생성할 수 있고, 프로그래밍적인 방법으로 직접 생성할 수 도 있습니다.

1.1 자동구성된 ChatClient.Builder 사용

아래는 간단한 사용사례로 ChatClient.Builder 를 주입받아 ChatClient 를 생성하고 사용자 입력에 대한 String 응답을 가져오는 예시입니다.

call() 메서드는 AI모델로 요청을 보내고, content() 메서드는 AI응답을 문자열로 반환합니다.

@RestController
class MyController {

    private final ChatClient chatClient;

    public MyController(ChatClient.Builder chatClientBuilder) {
        this.chatClient = chatClientBuilder.build();
    }

    @GetMapping("/ai")
    String generation(String userInput) {
        return this.chatClient.prompt()
            .user(userInput)
            .call()
            .content();
    }
}

1.2. 다중 Chat Models 활용하기

하나의 애플리케이션에서 여러 개의 Chat Model을 사용해야 하는 상황이 있습니다. 예를 들어:

작업별 다른 모델 사용 : 복잡한 추론에는 강력한 모델, 단순 작업에는 빠르고 저렴한 모델 활용
장애 대비(Fallback) : 특정 모델 서비스가 불가능할 때 다른 모델로 대체
A/B 테스트 : 서로 다른 모델이나 설정을 비교 실험
사용자 선택 제공 : 사용자 취향에 따라 모델을 고를 수 있도록 옵션 제공
전문화된 모델 조합 : 코드 생성용 모델, 창의적 글쓰기용 모델 등 역할별 모델을 함께 사용

자동구성 이용 시 단일 모델에 대한 ChatClient.Builder 만 사용이 가능하기 때문에 애플리케이션 내에서 여러 모델을 이용하려면 자동구성을 비활성화하고 ChatClient 인스턴스를 직접 생성해야합니다.

spring:
  ai:
    chat:
      client:
        enabled: false

ChatModel 에 따라 각각 클라이언트를 구성할 수 있습니다.

@Configuration
public class ChatClientConfig {

    @Bean
    public ChatClient openAiChatClient(OpenAiChatModel chatModel) {
        return ChatClient.create(chatModel);
    }

    @Bean
    public ChatClient anthropicChatClient(AnthropicChatModel chatModel) {
        return ChatClient.create(chatModel);
    }
}

Spring 환경에 맞게 모델을 주입받고 적절히 분기하여 사용되게 코드를 구성할 수 있습니다.

@Configuration
public class ChatClientExample {

    @Bean
    CommandLineRunner cli(
            @Qualifier("openAiChatClient") ChatClient openAiChatClient,
            @Qualifier("anthropicChatClient") ChatClient anthropicChatClient) {

        return args -> {
            var scanner = new Scanner(System.in);
            ChatClient chat;

            // Model selection
            System.out.println("\\nSelect your AI model:");
            System.out.println("1. OpenAI");
            System.out.println("2. Anthropic");
            System.out.print("Enter your choice (1 or 2): ");

            String choice = scanner.nextLine().trim();

            if (choice.equals("1")) {
                chat = openAiChatClient;
                System.out.println("Using OpenAI model");
            } else {
                chat = anthropicChatClient;
                System.out.println("Using Anthropic model");
            }

            // Use the selected chat client
            System.out.print("\\nEnter your question: ");
            String input = scanner.nextLine();
            String response = chat.prompt(input).call().content();
            System.out.println("ASSISTANT: " + response);

            scanner.close();
        };
    }
}

혹은 단일 ChatModel을 이용하더라도 시스템 프롬프트 등 구성을 달리하는 ChatClient 를 여러 개 구성할 수도 있습니다.

ChatClient.Builder builder = ChatClient.builder(myChatModel);

// 기본 클라이언트
ChatClient defaultChatClient = builder.build();

// 시스템프롬프트 커스텀한 클라이언트
ChatClient customChatClient = builder
    .defaultSystemPrompt("You are a helpful assistant.")
    .build();

1.3. 다중 OpenAI API 호환 엔드포인트 연동 예시

OpenAI 모델과 OpenAI API 호환 모델 (e.g. Groq) 을 동시에 사용하는 경우 기준 모델을 mutate() 메서드로 간단히 속성만 변경하여 사용할 수 있습니다.

@Configuration
public class ChatClientConfig {

    @Autowired
    private OpenAiChatModel baseChatModel;

    @Autowired
    private OpenAiApi baseOpenAiApi;

    @Bean
    public ChatClient groqChatClient(OpenAiChatModel groqModel) {
        return ChatClient.builder(groqModel).build();
    }

    @Bean
    public ChatClient gpt4ChatClient(OpenAiChatModel gpt4Model) {
        return ChatClient.builder(gpt4Model).build();
    }

    @Bean
    public OpenAiChatModel groqModel(OpenAiApi groqApi) {
        return baseChatModel.mutate()
            .openAiApi(groqApi)
            .defaultOptions(OpenAiChatOptions.builder()
                .model("llama3-70b-8192")
                .temperature(0.5)
                .build())
            .build();
    }

    @Bean
    public OpenAiChatModel gpt4Model(OpenAiApi gpt4Api) {
        return baseChatModel.mutate()
            .openAiApi(gpt4Api)
            .defaultOptions(OpenAiChatOptions.builder()
                .model("gpt-4")
                .temperature(0.7)
                .build())
            .build();
    }
    
    @Bean
    public OpenAiApi groqApi() {
        return baseOpenAiApi.mutate()
            .baseUrl("<https://api.groq.com/openai>")
            .apiKey(System.getenv("GROQ_API_KEY"))
            .build();
    }

    @Bean
    public OpenAiApi gpt4Api() {
        return baseOpenAiApi.mutate()
            .baseUrl("<https://api.openai.com>")
            .apiKey(System.getenv("OPENAI_API_KEY"))
            .build();
    }
}

2. ChatClient Fluent API

ChatClient의 prompt 메서드를 사용해 세 가지 방식으로 프롬프트를 생성할 수 있습니다.

메서드 설명

prompt()	인자가 없는 이 메서드는 플루언트 API를 시작할 때 사용하며, 사용자(user), 시스템(system) 등의 메시지를 단계적으로 추가해 프롬프트를 구성할 수 있습니다.
prompt(Prompt prompt)	Prompt 인스턴스를 인자로 받아, 플루언트 API가 아닌 방식으로 미리 생성한 Prompt 객체를 전달할 수 있습니다.
prompt(String content)	사용자의 텍스트 내용을 바로 전달할 수 있습니다.

3. ChatClient Responses

ChatClient를 사용하여 AI 모델의 응답을 다양한 방식으로 포맷할 수 있는 방법을 제공합니다.

3.1. ChatResponse 반환

AI 모델의 응답은 ChatResponse ****타입으로 정의된 풍부한 구조를 가지고 있습니다.

이 객체에는 응답이 어떻게 생성되었는지에 대한 메타데이터가 포함되어 있으며, 여러 개의 응답을 가질 수도 있습니다. 각 응답은 자체 메타데이터를 포함합니다.

메타데이터에는 응답을 생성하는 데 사용된 토큰 수가 포함되며, 이는 호스팅되는 AI 모델이 요청당 사용된 토큰 수에 따라 과금하기 때문에 중요한 정보입니다.

아래 예시는 call() 메서드 호출 후 chatResponse()를 사용하여 메타데이터가 포함된 ChatResponse 객체를 반환하는 방법을 보여줍니다.

ChatResponse chatResponse = chatClient.prompt()
    .user("Tell me a joke")
    .call()
    .chatResponse();

3.2. Entity 반환

AI 모델의 응답을 단순 문자열이 아니라 모델 객체로 매핑해 반환하고 싶을 때가 있습니다.

ChatClient의 entity() 메서드를 통해 응답을 특정 클래스로 매핑할 수 있습니다.

record ActorFilms(String actor, List<String> movies) {}

// 무작위 배우 대상 배우, 영화목록 형태 응답을 기대
ActorFilms actorFilms = chatClient.prompt()
    .user("Generate the filmography for a random actor.")
    .call()
    .entity(ActorFilms.class);

혹은 아래와 같이 List, Map 과 같은 복잡한 타입을 알려줄 수도 있습니다.

// Tom Hanks와 Bill Murray 배우의 영화목록 형태 응답을 기대
List<ActorFilms> actorFilms = chatClient.prompt()
    .user("Generate the filmography of 5 movies for Tom Hanks and Bill Murray.")
    .call()
    .entity(new ParameterizedTypeReference<List<ActorFilms>>() {});

3.3. 응답 Streaming

stream() 메서드를 사용하면 아래와 같이 비동기(reactive) 방식으로 응답을 스트리밍할 수 있습니다:

Flux<String> output = chatClient.prompt()
    .user("Tell me a joke")
    .stream()
    .content();

앞으로는 stream() 메서드를 사용할 때 Java 엔티티를 바로 반환할 수 있는 편의 메서드가 제공될 예정입니다만 현재 버전에서는 아래 예시처럼 Structured Output Converter를 사용해 스트리밍된 응답을 직접 변환해야 합니다.

아래 예시에서는 param() 메서드를 활용한 파라미터를 사용하는 방법을 함께 보여줍니다. (자세한 내용은 문서의 후반부에서 설명됩니다)

var converter = new BeanOutputConverter<>(new ParameterizedTypeReference<List<ActorsFilms>>() {});

Flux<String> flux = this.chatClient.prompt()
    .user(u -> u.text("""
                        Generate the filmography for a random actor.
                        {format}
                      """)
            .param("format", this.converter.getFormat()))
    .stream()
    .content();

String content = this.flux.collectList().block().stream().collect(Collectors.joining());

List<ActorsFilms> actorFilms = this.converter.convert(this.content);

4. 프롬프트 템플릿

ChatClient는 런타임에 변수가 치환되는 템플릿 형태로 사용자(user)와 시스템(system) 텍스트를 제공할 수 있습니다.

String answer = ChatClient.create(chatModel).prompt()
    .user(u -> u
            .text("Tell me the names of 5 movies whose soundtrack was composed by {composer}")
            .param("composer", "John Williams"))
    .call()
    .content();

내부적으로 ChatClient는 PromptTemplate ****클래스를 사용해 사용자 및 시스템 텍스트를 처리하며, 런타임에 제공된 값으로 변수를 치환합니다. 이때 TemplateRenderer 구현체를 사용합니다.

기본적으로 Spring AI는 StTemplateRenderer 구현체를 사용하며, 이는 Terence Parr가 개발한 오픈 소스 StringTemplate 엔진을 기반으로 합니다.

또한 Spring AI는 템플릿 처리가 필요하지 않은 경우를 위해 NoOpTemplateRenderer 도 제공합니다.

<aside>

ChatClient에 직접 설정한 TemplateRenderer(예: .templateRenderer() 사용)는 빌더 체인에서 직접 정의한 프롬프트 내용(예: .user(), .system())에만 적용됩니다.

이는 QuestionAnswerAdvisor와 같이 어드바이저 내부에서 사용되는 템플릿에는 영향을 주지 않으며,

해당 어드바이저들은 자체적인 템플릿 커스터마이징 메커니즘을 가지고 있습니다.

(자세한 내용은 Custom Advisor Templates 섹션을 참고하십시오.)

</aside>

만약 다른 템플릿 엔진을 사용하고 싶다면, TemplateRenderer 인터페이스를 직접 구현하여 ChatClient에 제공할 수 있습니다.

또는 기본적으로 제공되는 StTemplateRenderer 를 계속 사용하되, 사용자 정의 설정으로 커스터마이징할 수도 있습니다.

예를 들어, 기본적으로 템플릿 변수는 {} 구문으로 식별됩니다.

프롬프트에 JSON을 포함할 계획이라면 JSON의 중괄호({})와 충돌을 피하기 위해 다른 구분자를 사용할 수 있습니다.

아래 예시는 템플릿 변수 식별자를 < 와 > 로 변경하는 예제입니다.

TemplateRenderer customTemplateRenderer = StTemplateRenderer.builder()
    .startDelimiterToken('<')
    .endDelimiterToken('>')
    .build();

String answer = ChatClient.create(chatModel).prompt()
    .user(u -> u
            .text("Tell me the names of 5 movies whose soundtrack was composed by <composer>")
            .param("composer", "John Williams"))
    .templateRenderer(customTemplateRenderer)
    .call()
    .content();

5. call() return values

ChatClient에서 call() 메서드를 지정한 후에는 응답을 다양한 형태로 받을 수 있는 여러 옵션이 있습니다.

메서드 설명

String content()	응답의 문자열 내용만 반환합니다.
ChatResponse chatResponse()	여러 Generations(응답 후보)을 포함하고, 응답 생성에 사용된 토큰 수 등 메타데이터를 담은 ChatResponse 객체를 반환합니다.
ChatClientResponse chatClientResponse()	ChatResponse 와 함께 ChatClient 실행 컨텍스트를 포함하는 객체를 반환합니다. 이를 통해 어드바이저 실행 중 사용된 추가 데이터(예: RAG 플로우에서 검색된 문서 등)에 접근할 수 있습니다.
ResponseEntity<?> responseEntity()	상태 코드, 헤더, 바디를 포함한 전체 HTTP 응답을 ResponseEntity 로 반환합니다. 저수준 HTTP 세부 정보가 필요할 때 유용합니다.

entity() 메서드로 특정 모델로 바로 변환할 수 있습니다.

메서드 설명

entity()	Java 타입으로 변환된 엔티티를 반환합니다.
entity(ParameterizedTypeReference type)	컬렉션 형태의 엔티티 타입을 반환할 때 사용합니다.
entity(Class type)	특정 단일 엔티티 타입으로 변환합니다.
entity(StructuredOutputConverter structuredOutputConverter)	StructuredOutputConverter 인스턴스를 지정해 문자열을 원하는 엔티티 타입으로 변환합니다.

<aside>

call() 메서드를 호출하는 것만으로는 실제 AI 모델 실행이 이루어지지 않습니다. 이 메서드는 Spring AI에게 동기 호출을 할지 스트리밍 호출을 할지를 지정하는 역할만 합니다. 실제 AI 모델 호출은 content(), chatResponse(), responseEntity() 와 같은 메서드를 호출할 때 수행됩니다.

</aside>

6. stream() return values

ChatClient에서 stream() 메서드를 지정한 후에는 응답을 받을 수 있는 몇 가지 옵션이 있습니다

메서드 설명

Flux content()	AI 모델이 생성하는 문자열을 Flux 형태로 반환합니다.
Flux chatResponse()	메타데이터를 포함한 ChatResponse 객체를 Flux 형태로 반환합니다.
Flux chatClientResponse()	ChatResponse 와 ChatClient 실행 컨텍스트를 포함하는 ChatClientResponse 객체를 Flux 형태로 반환합니다. 이를 통해 어드바이저 실행 중 사용된 추가 데이터(예: RAG 플로우에서 검색된 문서 등)에 접근할 수 있습니다.

7. Using Defaults

@Configuration 클래스에서 기본 시스템 텍스트를 설정하여 ChatClient를 생성하면 런타임 코드가 간결해집니다. 기본값을 설정해두면 ChatClient를 호출할 때 사용자 텍스트만 지정하면 되며, 매번 요청마다 시스템 텍스트를 설정할 필요가 없습니다.

7.1. Default System Text 설정하기

아래 예제와 같이 LLM 시스템 대화의 기본 행동태도를 ChatClient 설정으로 변경해줄수 있습니다.

이 내용은 해당 ChatClient의 모든 system 메시지에 적용됩니다.

@Configuration
class Config {

    @Bean
    ChatClient chatClient(ChatClient.Builder builder) {
        return builder
            .defaultSystem("You are a friendly chat bot that answers question in the voice of a Pirate")
            .build();
    }

}

테스트하기위한 간단한 RestController 를 작성하고 호출합니다.

@RestController
class AIController {

	private final ChatClient chatClient;

	AIController(ChatClient chatClient) {
		this.chatClient = chatClient;
	}

	@GetMapping("/ai/simple")
	public Map<String, String> completion(@RequestParam(value = "message", defaultValue = "Tell me a joke") String message) {
		return Map.of("completion", this.chatClient.prompt().user(message).call().content());
	}
}

아래와 같이 응답하는 것을 확인할 수 있습니다.

❯ curl localhost:8080/ai/simple
{"completion":"Why did the pirate go to the comedy club? To hear some arrr-rated jokes! Arrr, matey!"}

7.2. Default System Text 에 Parameter 적용하기

아례 예시에서는 설정 시점에 파라미터를 갖는 defaultSystem을 설정해두고 런타임에 값을 지정하는 예시입니다.

@Configuration
class Config {

    @Bean
    ChatClient chatClient(ChatClient.Builder builder) {
        return builder
            .defaultSystem("You are a friendly chat bot that answers question in the voice of a {voice}")
            .build();
    }

}

ChatClient 의 system 메서드를 통해 파라미터를 지정합니다.

@RestController
class AIController {
	private final ChatClient chatClient;

	AIController(ChatClient chatClient) {
		this.chatClient = chatClient;
	}

	@GetMapping("/ai")
	Map<String, String> completion(@RequestParam(value = "message", defaultValue = "Tell me a joke") String message, String voice) {
		return Map.of("completion",
				this.chatClient.prompt()
						.system(sp -> sp.param("voice", voice))
						.user(message)
						.call()
						.content());
	}

}

7.3. 다른 설정가능한 default 값

ChatClient.Builder 정의 시점에 system 외 다른 기본값도 설정할 수 있습니다.

메서드 설명

defaultOptions(ChatOptions chatOptions)	ChatOptions 클래스에서 정의된 범용 옵션이나, OpenAiChatOptions 와 같은 모델별 옵션을 전달할 수 있습니다. 모델별 ChatOptions 구현체에 대한 자세한 내용은 JavaDocs를 참고하십시오.
defaultFunction(String name, String description, java.util.function.Function<I, O> function)	name 은 사용자 텍스트에서 함수를 참조할 때 사용되며, description 은 함수의 목적을 설명하고 AI 모델이 올바른 함수를 선택해 정확한 응답을 생성하도록 돕습니다. function 인자는 모델이 필요 시 실행할 Java 함수 인스턴스입니다.
defaultFunctions(String… functionNames)	애플리케이션 컨텍스트에 정의된 java.util.Function 빈(bean)의 이름을 지정합니다.
defaultUser(String text)defaultUser(Resource text)defaultUser(Consumer<UserSpec> userSpecConsumer)	기본 사용자 텍스트를 정의합니다. Consumer<UserSpec> 을 사용하면 람다식으로 사용자 텍스트와 기본 파라미터를 지정할 수 있습니다.
defaultAdvisors(Advisor… advisor)	Advisor 를 통해 프롬프트를 구성하는 데이터를 수정할 수 있습니다. QuestionAnswerAdvisor 구현체를 사용하면 사용자 텍스트와 관련된 컨텍스트 정보를 프롬프트에 추가해 Retrieval Augmented Generation 패턴을 구현할 수 있습니다.
defaultAdvisors(Consumer<AdvisorSpec> advisorSpecConsumer)	Consumer<AdvisorSpec> 을 사용해 여러 Advisor 를 설정할 수 있습니다. 예를 들어, QuestionAnswerAdvisor 를 추가하여 사용자 텍스트 기반으로 관련 컨텍스트를 프롬프트에 덧붙이는 Retrieval Augmented Generation 패턴을 구성할 수 있습니다.

이러한 기본 설정은 런타임에 동일한 이름에서 default 접두어가 없는 메서드를 사용하여 재정의할 수 있습니다.

options(ChatOptions chatOptions)
function(String name, String description, java.util.function.Function<I, O> function)
functions(String… functionNames)
user(String text), user(Resource text), user(Consumer<UserSpec> userSpecConsumer)
advisors(Advisor… advisor)
advisors(Consumer<AdvisorSpec> advisorSpecConsumer)

8. Advisors

Advisors API는 Spring 애플리케이션에서 AI 기반 상호작용을 가로채고(intercept), 수정하고(modify), 향상시키는(enhance) 유연하고 강력한 방법을 제공합니다.

AI 모델을 사용자 입력과 함께 호출할 때 자주 사용하는 패턴 중 하나는 프롬프트에 컨텍스트 데이터(contextual data)를 추가하거나 보강하는 것입니다.

이 컨텍스트 데이터는 여러 유형일 수 있으며, 일반적으로 다음과 같은 유형이 있습니다.

Your own data : AI 모델이 학습하지 않은 데이터입니다. 모델이 유사한 데이터를 학습했더라도, 추가된 컨텍스트 데이터가 응답 생성 시 우선적으로 반영됩니다.
Conversational history : 채팅 모델의 API는 상태를 저장하지 않습니다. 예를 들어, 모델에 본인의 이름을 알려도 이후 대화에서 기억하지 못합니다. 이전 상호작용을 고려하도록 하려면 매 요청마다 대화 이력을 함께 전달해야 합니다.

8.1. ChatClient에 Advisor 설정

ChatClient의 유창한(Fluent) API는 AdvisorSpec 인터페이스를 제공하여 어드바이저를 구성할 수 있게 합니다.

이 인터페이스는 파라미터를 추가하거나, 한 번에 여러 파라미터를 설정하거나, 하나 이상의 어드바이저를 체인에 추가하는 메서드를 제공합니다.

interface AdvisorSpec {
    AdvisorSpec param(String k, Object v);
    AdvisorSpec params(Map<String, Object> p);
    AdvisorSpec advisors(Advisor... advisors);
    AdvisorSpec advisors(List<Advisor> advisors);
}

<aside>

체인에 어드바이저가 추가되는 순서는 매우 중요합니다. 이 순서가 실행 순서를 결정하기 때문입니다. 각 어드바이저는 프롬프트나 컨텍스트를 어떤 방식으로든 수정하며, 앞선 어드바이저가 만든 변경 사항은 다음 어드바이저로 전달됩니다.

</aside>

아래 구성에서 MessageChatMemoryAdvisor 는 먼저 실행되어 대화 이력을 프롬프트에 추가합니다. 그 다음 QuestionAnswerAdvisor 가 사용자의 질문과 추가된 대화 이력을 기반으로 검색을 수행하여, 더 관련성 높은 결과를 제공할 수 있습니다.

ChatClient.builder(chatModel)
    .build()
    .prompt()
    .advisors(
        MessageChatMemoryAdvisor.builder(chatMemory).build(),
        QuestionAnswerAdvisor.builder(vectorStore).build()
    )
    .user(userText)
    .call()
    .content();

8.2. Retrieval Augmented Generation

Advisor를 활용한 Retrieval Augmented Generation (RAG) 내용은 별도 가이드 문서에서 상세하게 확인할 수 있습니다.

8.3. Logging

SimpleLoggerAdvisor 는 ChatClient의 요청과 응답 데이터를 로깅하는 어드바이저입니다. 이 어드바이저는 AI 상호작용을 디버깅하거나 모니터링할 때 유용하게 사용할 수 있습니다.

Logging을 활성화하려면 ChatClient를 생성할 때 어드바이저 체인에 SimpleLoggerAdvisor를 추가하면 됩니다.

일반적으로 체인의 끝부분에 추가하는 것을 권장합니다.

ChatResponse response = ChatClient.create(chatModel).prompt()
        .advisors(new SimpleLoggerAdvisor())
        .user("Tell me a joke?")
        .call()
        .chatResponse();

로그를 확인하려면 application.properties 또는 application.yaml 파일에 다음과 같이 설정해

advisor 패키지의 로깅 레벨을 DEBUG로 지정합니다.

logging.level.org.springframework.ai.chat.client.advisor=DEBUG

또한, 아래와 같이 생성자를 사용하면 AdvisedRequest와 ChatResponse에서 어떤 데이터를 로깅할지 커스터마이징할 수 있습니다.

SimpleLoggerAdvisor(
    Function<ChatClientRequest, String> requestToString,
    Function<ChatResponse, String> responseToString,
    int order
)

사용 예시:

SimpleLoggerAdvisor customLogger = new SimpleLoggerAdvisor(
    request -> "Custom request: " + request.prompt().getUserMessage(),
    response -> "Custom response: " + response.getResult(),
    0
);

이를 통해 로깅되는 정보를 애플리케이션의 요구 사항에 맞게 조정할 수 있습니다.

9. Chat Memory

ChatMemory 인터페이스는 채팅 대화 메모리 저장소를 나타냅니다. 이 인터페이스는 대화에 메시지를 추가하고, 대화에서 메시지를 조회하며, 대화 기록을 초기화하는 메서드를 제공합니다.

현재 기본으로 제공되는 구현체는 MessageWindowChatMemory 입니다.

MessageWindowChatMemory 는 지정된 최대 크기(기본값: 20개 메시지)까지 메시지 윈도우를 유지하는 채팅 메모리 구현체입니다.

메시지 개수가 이 한도를 초과하면 가장 오래된 메시지부터 제거되지만, 시스템 메시지는 유지됩니다.

새로운 시스템 메시지가 추가되면 기존의 모든 시스템 메시지가 메모리에서 제거됩니다.

이를 통해 대화에서 가장 최근의 컨텍스트를 항상 유지하면서도 메모리 사용량을 제한할 수 있습니다.

MessageWindowChatMemory 는 ChatMemoryRepository 추상화를 기반으로 하며,

이는 채팅 대화 메모리를 저장하기 위한 다양한 구현체를 제공합니다.

사용 가능한 구현체에는 InMemoryChatMemoryRepository, JdbcChatMemoryRepository,

CassandraChatMemoryRepository, Neo4jChatMemoryRepository 등이 있습니다.

자세한 내용과 사용 예시는 Chat Memory 문서를 참고하십시오.

10. Implementation Notes

ChatClient 는 명령형(imperative)과 반응형(reactive) 프로그래밍 모델을 함께 사용하는 독특한 API입니다.
- 대부분의 애플리케이션은 보통 둘 중 하나만 사용하지만, ChatClient 는 두 모델을 모두 지원합니다.
모델 구현의 HTTP 클라이언트 상호작용을 커스터마이징할 때는 RestClient 와 WebClient 모두를 설정해야 합니다.
- Spring Boot 3.4의 버그 때문에 spring.http.client.factory=jdk 속성을 반드시 설정해야 합니다. 그렇지 않으면 기본값이 reactor 로 설정되며, ImageModel 과 같은 일부 AI 워크플로가 정상적으로 동작하지 않습니다.
스트리밍(streaming)은 반응형 스택에서만 지원됩니다.
- 명령형 애플리케이션에서도 스트리밍을 사용하려면 반응형 스택(예: spring-boot-starter-webflux)을 반드시 포함해야 합니다.
비스트리밍(non-streaming)은 서블릿 스택에서만 지원됩니다.
- 반응형 애플리케이션에서 비스트리밍 호출을 사용하려면 서블릿 스택(예: spring-boot-starter-web)을 포함해야 하며, 일부 호출은 블로킹될 수 있습니다.
도구 호출(tool calling) 은 명령형 방식으로 동작하며, 이는 워크플로를 블로킹하게 만듭니다.
- 이로 인해 Micrometer 관측이 부분적 또는 중단될 수 있습니다.
- (예: ChatClient span 과 tool calling span 이 연결되지 않아 첫 번째 span 이 미완성 상태로 남을 수 있습니다.)
내장 어드바이저는 일반 호출에서는 블로킹 방식으로, 스트리밍 호출에서는 논블로킹 방식으로 동작합니다.
- 어드바이저의 스트리밍 호출에서 사용되는 Reactor Scheduler 는 각 어드바이저 클래스의 Builder를 통해 설정할 수 있습니다.

참고

Spring AI Reference - Chat Client API

Spring AI 를 활용한 MCP 서버 구현 및 Claude AI에 적용하기

@deveely — Fri, 3 Oct 2025 03:37:14 +0900

1. MCP란?

Model Context Protocol의 약자로, AI 모델과 외부 데이터 소스를 연결하기 위한 표준 프로토콜
LLM이 외부 시스템의 데이터나 기능에 접근할 수 있도록 하는 개방형 표준입니다.
Tool과 Resource를 통해 AI가 실시간 데이터를 조회하거나 특정 작업을 수행할 수 있게 합니다.
클로드 개발사인 Anthropic 이 주도하여 개발했으며, 다양한 언어의 SDK를 제공합니다.

MCP는 다양한 통신 방식을 지원하여 유연한 구현이 가능합니다.

HTTP 기반 JSON-RPC 방식으로 통신하며 STDIO(표준입출력), Streamable HTTP 방식을 지원합니다.
초기에는 SSE(Server-Sent Events) 방식이 기본 스펙이었으나, Streamable HTTP로 변경되었고 SSE는 선택사항이 되었습니다.
MCP 서버가 원격지에 구성되어 있을 경우 표준입출력 통신이 불가능하기 때문에 HTTP 기반 통신방식을 사용할 수 있습니다.
단일 endpoint만 제공해야 하며, 서버로 요청할 때는 POST 메서드를 사용해야 합니다.
MCP 서버는 클라이언트에세 서버가 제공하는 리소스, 프롬프트, 툴 목록과 설명을 제공합니다

상세한 스펙은 공식 문서를 참고하세요.

2. 간단한 MCP 서버 구현

간단한 MCP 서버를 구현하고 테스트해보고자 합니다.

마침 현재 여러 회사의 채용공고를 수집하여 제공하는 사이드 프로젝트를 운영하고 있습니다.

지금 DB에 수집되고 있는 채용정보를 LLM이 검색할 수 있도록 기능을 만들어서 제공하고, ChatGPT나 Claude 같은 서비스에서 사용할 것이기 때문에 Streamable HTTP 통신방식을 통해 구현해보겠습니다.

2.1 Resource vs Tool: 무엇을 선택할까?

MCP는 데이터 제공 방식에 따라 Resource와 Tool 두 가지 타입을 제공합니다.

Resource Tool

용도	정적이거나 반정형화된 데이터 제공	동적 데이터 조회 및 작업 수행
갱신주기	갱신되지 않거나 시간 / 일 단위로 느린 갱신	실시간 혹은 빠른 갱신
예시	Readme 파일, 정책 문서, 코드베이스	데이터베이스 검색, 주가 등 외부 데이터 검색, 데이터 변경 작업 수행

지금 구현하고자 하는 예시에서는 데이터베이스 조회를 통하기 때문에 Tool이 적합하다고 판단하였습니다.

2.2. Spring AI MCP 활용하기

MCP는 다양한 언어의 SDK를 제공하며, Java SDK도 그 중 하나입니다.

저는 이미 Spring Boot 기반으로 서비스를 운영 중이었고, 기존에 구현해둔 채용정보 검색 기능을 재사용하고 싶었습니다.

Spring AI 에서는 MCP 서버, 클라이언트를 쉽게 구현할 수 있도록 구현체를 제공합니다. MCP Java SDK를 래핑하여 Spring 환경에서 쉽게 사용할 수 있도록 해주며, 필요시 저수준 API(MCP Java SDK)도 그대로 활용할 수 있습니다.

3. 코드 작성

먼저 구현하고자 하는 방식에 맞는 적절한 starter 를 의존성을 추가해줍니다.

제 경우는 원격지에 서버를 구동시켜두고자 하여 웹 의존성이 있는 스타터를 사용하였습니다.

dependencies {
    implementation(platform("org.springframework.ai:spring-ai-bom:1.0.2"))
    implementation("org.springframework.ai:org.springframework.ai:spring-ai-starter-mcp-server-webmvc")
}

다음 아래와 같이 통신방식과 insturctions 를 설정해주었습니다.

가능한 모든 설정 목록은 공식문서를 확인하세요.

spring:
  application:
    name: mcp
  ai:
    mcp:
      server:
        protocol: stateless
        instructions: "XXX 서비스에서 제공하는 채용공고에 대한 검색 기능을 제공하는 MCP 서버"

@Tool 어노테이션만으로 간단히 MCP Tool을 구현할 수 있습니다.

description 에 툴에 대해 설명을 명시하고, ToolParam 으로 해당 툴의 파라미터를 명시하여줍니다.

내부 로직은 자유롭게 구현하면 Spring 이 MCP 서버 제공 스펙에 맞춰 변환해줍니다.

(아래 예시는 빠른 구현을 위해 DTO 없이 Map을 반환했습니다. 실제 프로덕션 환경에서는 명확한 응답 모델을 정의하는 것을 권장합니다.)

@Tool(description = """
    # Request
    - searchKeyword 로 채용공고를 검색합니다. 제목 기반 like 검색 결과를 반환합니다.
    - companyGroup 이 지정되면 해당 회사 그룹 내에서만 검색합니다.
    
    # Response
    - infoNo : 공고번호. fetch 툴에서 상세 정보를 조회할 때 사용합니다.
    - title : 공고 제목
    - companyGroup : 회사 그룹 (예: 네이버, 카카오)
    - startAt : 공고 시작일 (yyyy-MM-dd), null 일 경우 확인 불가 케이스
    - endAt : 공고 마감일 (yyyy-MM-dd), null 일 경우 확인 불가 케이스
    - jobCategory : 직군 (예: 개발, 디자인)
    - recruitmentLink : 공고 URL
""")
fun search(
    @ToolParam(
        description = "회사 enum 값을 참고하여 네이버 -> NAVER, 카카오 -> KAKAO 와 같이 Enum 값으로 요청해야합니다.", 
        required = false
    ) companyGroup: CompanyGroup?,
    @ToolParam(description = "검색 키워드") searchKeyword: String
): List<Map<String, Any?>> {
    val searchResult = recruitmentInfoRepository.findAllBySearchParams(
        RecruitmentInfoSearchParams(
            title = searchKeyword,
            companyGroup = companyGroup
        )
    )
    
    return searchResult.map {
        mapOf(
            "infoNo" to it.infoNo,
            "title" to it.title,
            "companyGroup" to it.companyGroup.nameKr,
            "startAt" to it.startAt?.let { date -> TimeUtils.format(date, "yyyy-MM-dd") },
            "endAt" to it.endAt?.let { date -> TimeUtils.format(date, "yyyy-MM-dd") },
            "jobCategory" to it.jobCategory,
            "recruitmentLink" to it.recruitmentLink
        )
    }
}

참고로 여기서 Tool은 Spring AI 에서 제공하는 Tool로 꼭 MCP로만 제공되지 않아도 됩니다. 아직 마일스톤 버전이지만 1.1.0 에서는 McpTool 과 같이 명시적으로 MCP 용 애노테이션들이 제공되는것으로 확인하였습니다.

구현은 위가 전부입니다.

4. Claude AI에 연결하기

다음 서버를 배포한 후 서비스에 추가해봅니다.

커스텀 커넥터에 MCP 서버 주소와 이름을 입력해줍니다.

아래와 같이 올바르게 추가된 것을 확인할 수 있습니다.

MCP 연결을 하고나면 LLM 이 연결된 MCP를 올바르게 인식하고 있는지 확인해볼수 있습니다.

다음은 툴이 올바르게 동작하는지 확인하기 위해 질문을 해봅니다.

의도한대로 MCP 적절히 활용하여 대답하는것을 확인할 수 있습니다.

질문을 잘 해석하고 파라미터도 적절하게 사용하여 요청하는게 아주 놀랍습니다.

마치며

MCP를 활용하여 LLM이 우리의 데이터에 매우 간단하게 접근하도록 할 수 있었습니다.

또한 Spring AI MCP를 사용하여 기존 Spring Boot 애플리케이션에 쉽고 자연스럽게 통합할 수 있어 사용경험도 괜찮았습니다.

단점이라면 MCP의 단점은 아니지만 Spring AI 는 이제 막 1.0.0 릴리즈 수준으로 극 초기 단계이다보니 완성도 면에서 성숙하지는 못한 단계라고 느꼈습니다. 이는 시간이 지나면서 차차 개선되길 기대해봅니다.

긴 글 봐주셔서 감사합니다.

[Spring AI 공식문서 읽기] 1. Spring AI 핵심 개념과 컨셉

@deveely — Sun, 31 Aug 2025 22:34:50 +0900

Spring AI Document를 읽으며 공부한 내용을 정리한 글입니다.

1. Spring AI 소개

Spring AI는 스프링 생태계에서 인공지능 기능을 쉽게 통합할 수 있도록 돕는 프레임워크입니다.
Python 진영의 LangChain, LlamaIndex에서 영감을 받았지만 단순 이식이 아니라, Java/Spring 환경에 맞춘 독자적 접근을 취합니다.

OpenAI, Anthropic, Microsoft, Amazon, Google 등 다양한 AI 모델 지원
(Chat, Embedding, Text→Image, Audio, Moderation 등)
구조화된 출력(POJO 매핑)과 RAG 구현을 위한 벡터 데이터베이스 연동
(PostgreSQL PGVector, Pinecone, Redis, Milvus 등 다수)
Function Calling(도구/함수 호출)로 모델이 외부 API나 클라이언트 기능 실행 가능
Observability(관측성) 제공, ETL 기반 문서 처리, 생성형 AI 모델 평가 유틸리티 지원

즉, Spring AI는 기업 데이터·API와 AI 모델을 쉽게 연결하고,
실무 친화적인 기능들을 제공하는 스프링 스타일 AI 통합 플랫폼이라고 할 수 있습니다.

2. 핵심 개념

Models (모델)
- 언어, 이미지, 오디오 처리 모델 지원
- Embeddings(임베딩)으로 의미 기반 표현 활용
- Pre-trained 모델을 쉽게 활용 가능
Prompts & Prompt Templates (프롬프트와 템플릿)
- 단순 문자열이 아닌 역할(Role) 기반 메시지 포함
- Prompt Engineering으로 효과적 지시 가능
- Spring AI는 StringTemplate을 이용한 동적 프롬프트 지원
Embeddings (임베딩)
- 텍스트/이미지/영상 → 벡터 변환
- 의미 기반 유사도 검색 및 RAG의 핵심
Tokens (토큰)
- 모델이 처리하는 최소 단위
- 비용 및 컨텍스트 한계와 직결
- GPT-3 (4K 토큰), Claude (100K 토큰), 최신 모델은 최대 1M 토큰
Structured Output (구조화된 출력)
- 단순 문자열 응답을 POJO 등 구조화 객체로 매핑 가능
Bringing Your Data & APIs (데이터와 API 연결)
- Fine-tuning: 모델 수정 (비용↑)
- Prompt stuffing: 데이터 포함 (RAG)
- Tool calling: 외부 API/도구 호출
- Spring AI는 RAG + Tool Calling 직접 지원
Evaluating AI Responses (응답 평가)
- 모델 응답 품질 검증 API 제공
- 관련성, 일관성, 사실성 등을 평가
- 요청/응답을 다시 모델에 검증시킬 수도 있음

위와 같이 Spring AI는 모델, 프롬프트 작성, 임베딩, 토큰 기반 처리, 구조화된 응답 처리, 데이터 ETL, 그리고 응답 평가까지
LLM 연동하는 개발자가 쉽게 연동할 수 있도록 하는 기능 전반을 제공합니다.
스프링에 익숙한 Java / Spring 기반 개발자라면 랭체인 등 타 언어 프레임워크 보다 훨씬 익숙하다는 부분도 있겠습니다.

3. Spring AI를 이용하려면?

먼저 BOM 을 프로젝트에 추가해줍니다.

dependencyManagement {
    imports {
        mavenBom "org.springframework.ai:spring-ai-bom:1.0.0" // Replace with desired version
    }
}

다음 필요한 의존성을 추가해줍니다.

e.g. OpenAI 모델 이용 시

dependencies {
    implementation 'org.springframework.ai:spring-ai-starter-model-openai'
}

사용가능한 Starters 목록은 여기에서 확인 가능합니다.

다음 글에서는 문서의 Reference를 보면서 실습해보는 시간을 가져보겠습니다.

랭체인(Langchain) 기본 개념과 간단한 활용 예제

@deveely — Sun, 24 Aug 2025 21:50:38 +0900

일반적인 백엔드 개발자 관점에서 학습한 내용을 정리한 글로 부정확한 내용이 있을수있습니다.

LLM 공부와 LLM을 활용한 서비스 구현을 계획하면서 공부하면서 자연스럽게 파이썬 생태계에서 시작된 LangChain을 접하게 되었습니다. 예전 같으면 모델 API 연동, RAG용 외부 데이터 연결, 프롬프트 설계 등을 각각 구현했을 것입니다.
LangChain은 프롬프트·체인·RAG·에이전트·툴까지 LLM 기반 서비스 전 과정을 아우르는 프레임워크/라이브러리 모음입니다.
이 글에서는 제가 이해한 LangChain의 핵심과 간단한 활용 예제를 간단히 정리하겠습니다.

1. 모델 I/O

LLM 과 상호작용 (Input, Output) 하기 위한 컴포넌트 영역
LLM에 전달할 프롬프트 생성
- 입력 임베딩 & RAG 검색 결과
LLM API 호출
LLM 응답 출력
- 구조화된 정보를 얻고자할때 출력 파서 이용
- JSON, CSV 등 LLM에 출력 형식을 알려주고 응답을 파싱
예시코드

from langchain import PromptTemplate
from langchain.chat_models import ChatOpenAI
from langchain.output_parsers import CommaSeparatedListOutputParser

openai = ChatOpenAI(temperature = 0, model_name='gpt-4')

output_parser = CommaSeparatedListOutputParser()
format_instructions = output_parser.get_format_instructions()

# 프롬프트 생성 (문자열 템플레이팅, 출력 형식 지정)
prompt = PromptTemplate(
    template = "7개의 팀을 보여줘 {subject}.\\n{format_instructions}",
    input_variables = ["subject"],    
    partial_variables={"format_instructions": format_instructions} 
)

# LLM API 호출 & 응답 수신
res = openai.predict(prompt.format(subject="한국의 야구팀은?"))

# 결과 파싱 (이 케이스에선 콤마로 연결된 값들을 List로 변환)
print(output_parser.parse(res))

2. 데이터 연결

데이터 ETL에 해당
문서 가져오기 (document loaders) : 다양한 소스에서 문서를 가져오는 것
문서 변환 (document transformers) : 문서를 청크로 분할하고 결합 등
문서 임베딩 (embedding model): 문서를 벡터 임베딩
- FAISS (인메모리 벡터 DB)
벡터 저장소 (vector stores) : 임베딩 결과물 적재
검색기 (retrievers) : 언어 모델과 결합할 문서 가져오기 위한 정보 검색
예시 코드
- PDF Read → 임베딩하여 인메모리 벡터 DB에 저장
- 체인을 활용해 LLM과 백터DB를 연결

from langchain.document_loaders import PyPDFLoader
from langchain.vectorstores import FAISS
from langchain.embeddings import OpenAIEmbeddings
from langchain.chat_models import ChatOpenAI
from langchain.chains import RetrievalQA

loader = PyPDFLoader("path/to/pdf")
document = loader.load()

# OpenAI 임베딩 사용. 벡터만 다루고자 하면 embeddings 객체 활용 가능
embeddings = OpenAIEmbeddings()

# 인메모리DB FAISS 에 임베딩 벡터 저장
# 검색 도구 (Retriever 로 사용)
db = FAISS.from_documents(document, embeddings)
retriever = db.as_retriever()

llm = ChatOpenAI(temperature = 0, model_name = 'gpt-4')
qa = RetrievalQA.from_chain_type(
    llm = llm, 
    chain_type = "stuff", 
    retriever = retriever
)

qa({ "query": "PDF 파일에 내용을 검색하면 잘 답변해준다." })

3. 체인

Langchain 내 여러 컴포넌트들을 묶어 하나의 행위를 만들어주는 역할
기본적인 예시

from langchain.chains import LLMChain
from langchain import PromptTemplate
from langchain.chat_models import ChatOpenAI

llm = ChatOpenAI(temperature = 0, model_name = 'gpt-4')

prompt = PromptTemplate(input_variables = ["country"], template = "{country}의 수도는 어디야?")

# LLM 과 프롬프트를 연결한 예시
chain = LLMChain(llm = llm, prompt = prompt)
chain.run("미국")

여러 체인 연결하여 사용하는 예시
- 특정 체인의 출력값을 다음 체인의 입력값으로 사용

from langchain.chains import LLMChain, SequentialChain
from langchain import PromptTemplate
from langchain.chat_models import ChatOpenAI
import os

os.environ["OPENAI_API_KEY"] = "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"

# LLM 생성
llm = ChatOpenAI(temperature = 0, model_name = 'gpt-4')

# 번역체인 생성 (번역 프롬프트 + LLM)
translatePrompt = PromptTemplate.from_template("다음 문장을 한글로 번역하세요.\\n\\n{sentence}")
translateChain = LLMChain(llm=llm, prompt=translatePrompt, output_key="translation")

# 요약체인 생성 (요약 프롬프트 - 번역체인 결과값 사용 + LLM)
summaryPrompt = PromptTemplate.from_template("다음 문장을 한 문장으로 요약하세요.\\n\\n{translation}")
summaryChain = LLMChain(llm=llm, prompt=summaryPrompt, output_key="summary")

# 최종 체인 (번역체인 -> 요약체인 순으로 수행)
aggregateChain = SequentialChain(
    chains=[translateChain, summaryChain], 
    input_variables=['sentence'], 
    output_variables=['translation', 'summary']
)

sentence="""
Ukraine’s President Volodymyr Zelenskyy, who has a checkered relationship with Trump and was not invited to the talks, will be nervous as they get underway. On Friday, the president commented on X that “it is time to end the war, and the necessary steps must be taken by Russia. We are counting on America.”
Both he and his European allies fear the U.S. leader could capitulate to skilled negotiator Putin’s likely demands for Moscow to retain occupied Ukrainian territory and cut short Ukraine’s NATO membership aspirations, in return for halting its military offensive.
As he headed off to Alaska on Air Force One, Trump told reporters that “something is going to come of it [the meeting].” When asked about Russia’s ongoing attacks on Ukraine, the president said Putin “thinks that gives him strength in talks, I think it hurts him,” in comments reported by Reuters.
Trump also insisted that Ukraine has to decide about its territory and that security guarantees were “possible along with Europe,” without giving further detail.
What’s the schedule?
On Friday, the White House confirmed that the U.S. delegation includes Secretary of State Marco Rubio, Treasury and Commerce Secretaries Scott Bessent and Howard Lutnick, CIA Director John Ratcliffe and Special Envoy Steven Witkoff, as well as other senior U.S. officials.
Moscow released more details about the summit earlier than Washington, however, which only this week confirmed that the presidents’ talks would be a “one-on-one” meeting.
"""

aggregateChain.invoke(sentence)

4. 메모리

LLM은 기본적으로 채팅 기록을 장기적으로 보관하지 않고 따로 저장해놔야하는데 랭체인에서 제공하는 컴포넌트를 사용하면 쉽게 구현할 수 있음

from langchain import ConversationChain
from langchain.chat_models import ChatOpenAI
import os

os.environ["OPENAI_API_KEY"] = "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"

llm = ChatOpenAI(temperature = 0, model_name = 'gpt-4')

conversation = ConversationChain(llm = llm, verbose=True)

# 아래 대화 내용들이 메모리에 저장되어 LLM 이 기억함
conversation.predict(input = "진희는 강아지를 한마리 키우고 있습니다.")
conversation.predict(input = "영수는 고양이를 두마리 키우고 있습니다.")
conversation.predict(input = "진희와 영수가 키우는 동물은 총 몇마리?")

5. 에이전트 / 툴

학습되지 않은 정보에 대해서는 전혀 모르는 LLM의 한계를 해소하기 위한 것이다.
에이전트도 주어진 프롬프트에 답변하는것이 목적으로 LLM과 유사하지만 방식이 LLM 과 크게 다르다
에이전트는 LLM 을 이용해서 어떤 작업을 어떤 순서로 수행할지 결정하는데, “어떤 작업”에 툴을 사용한다.
- 이때 에이전트 유형(AgentType)에 따라 LLM이 어떻게 툴을 결정하도록 할 지 지정할 수 있음
- ZERO_SHOT_REACT_DESCRIPTION : 스스로 선택 X. 언제 툴을 쓸 지 설명 필요
- REACT_DOCSTORE : 질문에 답하기 위해 검색 도구가 필요함
- …
툴은 특정 작업을 수행하기 위한 도구로 LLM 이외 다른 리소스를 의미한다.

import os
from langchain.chat_models import ChatOpenAI
from langchain.agents import load_tools, initialize_agent, AgentType

os.environ["OPENAI_API_KEY"] = "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"

llm = ChatOpenAI(temperature = 0, model_name = 'gpt-4')

# wikipedia, llm-math 툴 사용
tools = load_tools(["wikipedia", "llm-math"], llm=llm)

# 위 툴을 이용하는 Agent 생성
agent = initialize_agent(tools, llm, agent = AgentType.ZERO_SHOT_REACT_DESCRIPTION, description='계산이 필요할 때 사용', verbose=True)

agent.run("에드 시런이 태어난 해는? 2025년도 현재 에드 시런은 몇 살?")

에이전트는 결국 LLM이 "생각 → 도구 선택 → 실행 → 결과 결합" 과정을 통해 외부 세계와 상호작용하면서 답하는 기능을 묶어둔 것이다.

LLM 기본 개념

@deveely — Sun, 24 Aug 2025 21:33:59 +0900

LLM 정의

언어 모델링 (Language Modeling) 은 NLP의 하위 분야
토큰을 기본 입력으로 한다.
- 토큰이란 문장이나 텍스트에서 의미를 가지는 가장 작은 단위
모델링 방법
- 자동 인코딩 작업
  - 손상된 입력 내용으로부터 기존 문장을 재구성 하도록 하는 형태로 학습
  - 주로 문장 분류 또는 토큰 분류
- 자기회귀 작업
  - 이전 토큰으로 다음 토큰을 예측 하도록 훈련
  - 텍스트 생성에 이상적이며 GPT가 자기회귀

LLM 주요 특징

트랜스포머 아키텍쳐 기반
인코더: 원시 텍스트를 → 핵심 구성 요소로 분리 → 벡터로 변환, 어텐션을 사용하여 맥락 이해
디코더: 어텐션을 사용하여 다음에 올 최적의 토큰을 예측하여 텍스트를 생성
인코더로 텍스트를 잘 이해하고, 디코더로 잘 생성해내는 구조
GPT 계열 LLM은 자기회귀 모델링으로 학습, 디코더만 있는 모델로 텍스트 생성에 최적화

LLM 작동 원리

사전 훈련 (Pre-Traning)
- 대량의 텍스트 데이터로 일반적인 언어, 단어 간의 관계를 배움
- BERT(자동 인코딩 모델)의 경우 마스크된 언어 모델링 (MLM) 및 다음 문장 예측 (NSP)로 학#습
- MLM은 하나의 문장에서 토큰의 상호작용 인식하도록 함
- NSP는 문장들 사이에 토큰이 어떻게 상호작용하는지 이해하도록 함
```
# MLM
이스탄불은 방문하기에 훌륭한 [마스크] << 추측하도록 함

# NSP
A: 이스탄불은 방문하기에 훌륭한 도시입니다.
B: 나는 거기 가봤습니다.

문장 B는 문장의 A의 바로 다음에 왔습니까? Y or N
```
- GPT 계열은 다른 데이터 셋에, 다른 방식으로 사전 훈련함
- 이런 사전 훈련을 뭐로 하냐에 따라 어떤 LLM이 되냐가 갈리게된다.
전이학습 (Transfer Learning)
- 적이학습이란 한 작업에서 나온 결과물을 다른 작업의 성능 향상에 활용하는 방식
- LLM 에서는 말뭉치 (텍스트를 목적에 맞는 포맷으로 데이터화 해둔것) 를 기반으로 사전 훈련 (말뭉치 전이학습) 되고, 이보다 작은 데이터셋을 통해 파인튜닝 할 수 있다.
파인튜닝
- 사전 훈련된 LLM을 특정 도메인에 특화 시키는 과정
- 사전 훈련이 기본적이고 일반적인 개념을 가르치는 과정이라면, 파인튜닝은 해당 분야 전문 지식을 가르치는 것
- 적절한 학습률, 에포크 설정이 필요
- 용어 정리
  - 학습률 : 딥 러닝 모델에서 입력 데이터로 학습된 데이터 가중치를 얼마나 변경할 지
  - 에포크 : 딥 러닝에서 전체 데이터 셋이 해당 신경망을 통과한 횟수 (문제집 전체 몇 번 풀었냐)
어텐션
- 동일 입력 (문장, 단어)에 대해 동일하게 보지 않고 상황에 따라 가중치를 두어 중요도를 다르게 함
- LLM이 중요한 것을 판가름할 수 있는데에 도움을 줌
임베딩
- 우리가 인지하는 텍스트를 기계가 읽을 수 있는 형태로 변환하는 것
- 단어, 구절, 토큰을 수학적으로 표현한 데이터 구조
- 임베딩도 여러 종류가 있으며 파인튜닝을 통해 업데이트 가능
토큰화
- 텍스트를 토큰으로 나누는 과정
- 전통적인 NLP에서 불용어 (the, a, an) 제거 등은 하지 않는다
  - LLM은 사람이 사용하는 언어의 본질을 이해 시키는 게 목적이기 때문
- 영어의 경우 대소문자 변환 과정도 포함될 수 있으며 모델 성능에 영향을 끼친다
  - 단순한 작업은 대소문자 상관이 없지만 프로그래밍 코드와 같은건 대소문자 구문이 필수
- LLM이 사전에 없는 단어 (OOV - Out Of Vocaburary)를 발견하면 자신이 알고 있는 가장 작은 단어로 나눈다
  - 예시 사전: [”Sin”], 문장 “Sinan” 일 경우 [”Sin”, “##an”] 이라는 2 토큰으로 나뉨
  - ##은 부분 단어임을 의미 (LLM이 구분할 수 있도록)

현재 많이 사용되는 LLM

BERT
- 어텐션 메커니즘 활용하는 자동 인코딩 모델 (공백 추측)
- 인코더만 있고 디코더는 사용하지 않아 입력 속도가 매우 빠름
  - 이해를 잘하고 생성은 좀 못한다
- 텍스트 생성 보단 분류 등 특정 NLP 작업을 위한 사전 훈련 모델로 이용
GPT-4, ChatGPT
- 어텐션 메커니즘 활용하는 자기회귀 모델 (이전 토큰 기반 다음 토큰 예측)
- 인코더를 사용하지 않고 디코더를 통해 생성하기 때문에 텍스트 생성에 뛰어남
  - 이해는 잘 못하지만 생성은 잘한다
- GPT 기반 모델은 큰 문맥을 주었을 때 텍스트를 잘 생성해냄
T5
- 자동 인코딩 모델 및 자기회귀 모델 방식을 적절히 섞은 것
  - 이해도 생성도 잘한다
- 파인튜닝 없이 준수한 성능 자랑

SSE를 활용해 웹에서 실시간 데이터 구독 기능 구현

@deveely — Sun, 15 May 2022 01:35:02 +0900

프로젝트를 진행하다가 서버에서 주기적으로 발행하는 데이터를 클라이언트에서 실시간으로 받아 표시해주어야하는 기능을 구현할 일이 생겼다.

제일 먼저 생각났던건 웹소켓이었는데 물론 웹소켓으로도 구현은 가능하지만 웹소켓에서 지원하는 양방향 통신까지는 필요가 없고
서버 -> 클라이언트 방향으로의 단방향만 지원하면 돼서 다른 기술을 찾아보다가 SSE를 알게 되었다.

SSE는 Server Send Events의 약자로 HTML5부터 사용하능한 표준 스펙이다.

말 그대로 서버에서 주기적으로 발행하는 이벤트를 클라이언트(브라우저)에서 구독할 수 있는 기술로 접속연결만 HTTP로 하고 자체 프로토콜로 통신하는 웹소켓과 달리 전체 과정을 HTTP로 수행한다.

사용하는 방법은 간단하다.

먼저 원리를 알기 위해 SSE 스펙에 맞춰 이벤트를 발행하는 서버 코드를 작성해보자. (스프링에서 쉽게 적용하는 부분은 글 뒷 부분에 작성)

@Controller
@RequestMapping("/sse")
public class SseController {

    @GetMapping(produces = MediaType.TEXT_EVENT_STREAM_VALUE)
    public void publish(HttpServletResponse response) throws Exception {    
	    response.setCharacterEncoding("UTF-8");
        
        PrintWriter writer = response.getWriter(); 
        for(int i = 1; i <= 10; i++) { 
        	writer.write("data: { \"message\" : \"number : "+ i + "\" }\n\n"); 
            try { 
            	Thread.sleep(1000); 
            } catch (InterruptedException e) { 
            	e.printStackTrace(); 
            } 
        } 
        writer.close();
    }

}

먼저 Content-Type을 "text/event-stream"로 지정하고, 응답하는 데이터형식은 "data:실제응답할데이터\n\n"와 같이 맞춰 응답하면 된다. 그러면 보통 모든 작업이 끝난 후 response를 한번에 보내는것과 달리 데이터형식에 맞는 데이터가 write될 때 마다 해당 데이터가 클라이언트로 전송된다.

클라이언트 코드는 간단하다.

const eventSource = new EventSource("SSE API URL");
eventSource.onmessage = event => {
    console.log(event.data);
};

eventSource.onerror = error => {
    eventSource.close();
};

EventSource라는 SSE를 쉽게 다룰수 있는 클래스를 활용하면 정말 간단하게 구독 처리를 할 수 있다.

그리고 스프링 프레임워크에서도 마찬가지로 SSE를 쉽게 적용할 수 있는 구현체를 제공한다.

@Controller
public SseController {

    private TaskExecutor = Executors.newSingleThreadExecutor();

    @GetMapping
    public SseEmitter greeting(@PathVariable final int count) {
        final SseEmitter emitter = new SseEmitter();
        taskExecutor.execute(() -> {
            try {
                for (int i = 0; i < 10; i++) {
                    Thread.sleep(1000);
                    emitter.send("test data " + i);
                }
                emitter.complete();
            } catch (Exception e) {
                emitter.completeWithError(e);
            }
        });
        return emitter;
    }
}

이 예시에서는 이벤트 발행을 비동기로 처리하기 위해 별도 스레드를 통해 처리했다.

중요한건 "SseEmitter"라는 클래스를 제공하며 send 메소드로 데이터를 전송하고 전송이 끝나면 complete 메소드를 호출해주면 끝이다. 위 예시처럼 직접 Content-Type을 지정해주거나 데이터포맷을 맞출 필요 없이 편하게 사용할 수 있다.

Spring Boot Managed Dependency 버전 변경

@deveely — Fri, 8 Apr 2022 20:16:00 +0900

Spring Boot는 Spring Framework와 달리 프레임워크 빌드, 런타임 등에 필요한 의존성을 자동으로 관리해주는게 큰 장점중에 하나인데요.

Spring Boot에서는 관련 있는 기능 및 의존성을 묶어 하나의 의존성으로 제공하고 개발자들은 필요한 의존성만 선택하여 사용하면 됩니다.

그 안에서 일어나는 라이브러리 간의 호환성, 중복되는 라이브러리로 인한 충돌 등으로부터 자유로워지죠.

이를 Spring Boot 진영에서는 Managed Dependency라고 부르며 아래 링크에서 어떤 의존성들을 관리하고 있는지 볼 수 있습니다.

https://docs.spring.io/spring-boot/docs/current/reference/html/dependency-versions.html

다만 가끔은 이렇게 관리되는 의존성 중에서 특정 라이브러리나 의존성은 다른 버전을 사용하고 싶을때가 있습니다.

Spring Boot managed Dependency에선 특정 라이브러리 버전을 커스터마이즈 할 수 있는 방법을 제공하는데요.

바로 Version Properties를 제공해주어 원하는 버전으로 변경할 수 있게 해줍니다.

Maven 에서는 아래와 같이 properties로 선언해주면 됩니다. 변경가능한 Property명은 https://docs.spring.io/spring-boot/docs/current/reference/html/dependency-versions.html 의 Version Proerties에 정의되어 있습니다.

<properties>
    <srping-framework.version>5.3.18</srping-framework.version>
</properties>

Gradle의 경우엔 아래와 같이 할 수 있습니다.

ext['spring-framework.version] = '5.3.18'

이렇게 특정 라이브러리의 버전을 변경할 수 있습니다.

단 버전을 변경할 땐 기존 제공되는 의존성에서 맞춰진 호환성이 더 이상 보장되지 않기 때문에

변경 후 영향도를 반드시 체크해주어야합니다.

Spring Boot Tomcat Access Log 필터링

@deveely — Wed, 9 Mar 2022 00:25:01 +0900

Spring Boot Embedded Tomcat을 사용하면 Access Log를 남길수 있습니다.

기본적으로는 비활성화 되어있고 server.tomcat.accesslog.enabled 옵션을 true로 주면 활성화 할 수 있습니다.

Access Log는 해당 서버로 들어오는 모든 요청들을 로깅하는데 이 중 로그로 남기고 싶지 않은 건들이 있을 수 있습니다.

저의 경우엔 외부 모니터링 서버에서 헬스체크를 위해 헬스체크 URL을 1초에 한번씩 호출했고, 엑세스 로그가 과도하게 남는 케이스였습니다.

톰캣 Access Log 스펙 중에, HttpServletRequest 객체의 Attribute 내 특정 키가 포함되있거나, 되있지 않을 경우 해당 요청에 대해서는 로깅을 하지 않도록 설정할 수 있는 기능이 있는데요.

아래 문서를 통해 톰캣 Access Log 동작 관련 설정 방식을 자세하게 알아볼 수 있습니다.

https://tomcat.apache.org/tomcat-8.5-doc/config/valve.html#Access_Log_Valve/Attributes

이 포스트에서는 스프링 부트 옵션을 통해 톰캣 Access Log 설정을 하고, 필터를 통해 구현한 사례를 소개합니다.

1. Spring Boot 옵션 설정

- server.tomcat.accesslog.enabled: 액세스로그 활성화

- server.tomcat.accesslog.condition-unless: 로그를 남기지 않을 대상 Request Attribute의 key 값.

예를들어 request.getAttribute("NO-LOG") != null 인 요청은 로그를 남기지 않음

server:
  tomcat:
    accesslog:
      enabled: true
      condition-unless: NO-LOG

2. Filter 구현

- Http 요청 객체의 Attribute를 추가하여 톰캣이 액세스 로그를 남기지 않도록하는 필터

- 파라미터로 전달받는 conditionUnlessKey는 server.tomcat.accesslog.condition-unless에 설정해둔 값 (NO-LOG) 이 전달되도록 외부에서 주입 예정

public class NonLogingMarkingFilter implement Filter {

    private String conditionUnlessKey;

    @Override
    public void init(FilterConfig config) {
        conditionUnlessKey = config.getInitParam("conditionUnlessKey");
    }

    @Override
    public void doFilter(ServletRequest request, ServletResponse response, FilterChain chain) throws ServletException,
            IOException {
        request.setAttribute(conditionUnlessKey, conditionUnlessKey);
        chain.doFilter(request, response);
    }

}

3. 필터 등록

- 설정 파일 값을 주입받아 FilterRegistrationBean 통해 전달

- UrlPatterns에 로깅하지 않을 URL 목록을 설정하여 해당 요청들만 필터를 타도록 함

@Configuration
public class WebMvcConfiguration implements WebMvcConfigurer {
    
    @Value("${server.tomcat.accesslog.condition-unless}")
    private String conditionUnlessKey;

    @Bean
    public FilterRegistrationBean<NonLogingMarkingFilter> filterBean() {
        FilterRegistrationBean<NonLogingMarkingFilter> filterBean = new FilterRegistrationBean<>(new NonLogingMarkingFilter());
        filterBean.setOrder(Integer.MIN_VALUE);
        filterBean.setUrlPatterns(List.of("url", "to", "ignore"));
        filterBean.addInitParameter("conditionUnlessKey", conditionUnlessKey);
        return filterBean;
    }
}

위와 같이 구현하면 특정 URL의 요청들만 NonLogingMarkingFilter 타게 되어 Request Attribute에 conditionUnless 값이 세팅되고

톰캣 설정에 의해 해당 요청들은 엑세스 로그가 남지 않게됩니다.

[Svelte 시리즈] 컴포넌트 생명주기 (Lifecycle) 와 훅(Hook)

@deveely — Sun, 20 Feb 2022 00:59:51 +0900

이 포스트는 HEROPY 님 유튜브 Svelte 강좌를 보고 공부한 내용을 정리한 포스트입니다.

Svelte에서 컴포넌트는 화면에 랜더링되거나 사라질 때를 나타내는 컴포넌트의 상태가 있다.

이 상태의 흐름을 컴포넌트 생명주기라 한다.

mounted: 컴포넌트가 화면 또는 다른 컴포넌트에 랜더링된 (연결된) 상태. 이 전에는 화면 요소에 접근할 수 없음
destroyed: 컴포넌트가 화면 또는 다른 컴포넌트에서 사라진 (연결이 해제된) 상태
before update: 컴포넌트의 반응성 데이터 변경에 의해 재랜더링 되기 전 상태
after update: 컴포넌트의 반응성 데이터 변경에 의해 재랜더링 된 후 상태

이런 상태들은 컴포넌트가 화면(DOM)상에서 어떻게 다뤄지냐에 따라 다양하게 호출된다.

예를들어 특정 컴포넌트가 화면에 최초로 랜더링(연결될) 될 때 before update → mount → after update 의 주기로 진행된다. (destroyed는 해당 컴포넌트가 사라질 때)

또한, 화면에 그려져있는(연결되있던) 컴포넌트의 반응성 데이터가 변경되어 화면이 갱신될 때 before update → after update 순으로 진행된다.

그리고 화면에 그려져있던(연결되있던) 컴포넌트가 사라질 때 destroyed 상태로 진행된다.

각 상태는 훅(Hook)을 통해 접근하고 해당 상태일 때 처리해야할 로직을 수행할 수 있다.

mounted: onMount
destroyed: onDestroy
before update: beforeUpdate
after update: afterUpdate
App.svelte
- 각 Hook은 svelte 통해 import할 수 있고 해당 주기 때 수행할 로직을 전달할 수 있다.
- 아래와 같은 코드를 작성하고 언제 어떤 Hook이 실행되는지 확인해보자
- 참고로 과거엔 onDestroy 가 없었고 onMount 함수에서 함수를 반환하는 형태로 destroyed hook을 구현했었다. 지금도 두 방법 모두 가능하지만 onDestroy를 사용하는게 보다 더 직관적으로 보인다.

<script>
	import { onMount, onDestroy, beforeUpdate, afterUpdate } from 'svelte';
	let count = 0;
	onMount(() => {
		console.log('Mounted!!');
	});
	onDestroy(() => {
		console.log('Destroyed');
	});
	beforeUpdate(() => {
		console.log('before update');
	})
	afterUpdate(() => {
		console.log('after update');
	});
</script>

<h1>Something {count}</h1> 
<button type="button" on:click={() => count++}>+</button>

[Svelte 시리즈] 컴포넌트와 스토어

@deveely — Sat, 19 Feb 2022 00:58:00 +0900

이 포스트는 HEROPY 님 유튜브 Svelte 강좌를 보고 공부한 내용을 정리한 포스트입니다.

컴포넌트

Svelte에서는 Single File Component를 정의하고 사용할 수 있다.

Name.svelte
- 컴포넌트 사용할 때 전달받을 데이터 (props)는 export 구문을 통해 선언한다

<script>
export let name
</script>

<h1>{name}</h1>

App.svelte
- 사용 측에서 import 하여 컴포넌트를 가져온다.
- props는 해당 컴포넌트 attribute를 통해 전달한다. (컴포넌트에서 export된 이름에 맞춤)
- 전달하려는 prop의 이름과 데이터 변수명이 같다면 생략하여 작성할 수도 있다.

<script>
import Name from './Name.svelte';
let names = ['Tom', 'Mike', 'Elsa'];
let name = 'Another Tom';
</script>

{#each names as name}
<Name name={name} />
{/each}

<Name {name} />

컴포넌트내에서 데이터를 가공할 땐 원본 데이터에 영향이 없도록 작성하는 것이 중요하다.

만약 컴포넌트 내에서 데이터를 변경해야한다면 bind 키워드를 사용해 양방향 바인딩을 해주면 전달받은 prop을 변경할 수 있다.

스토어

만약 아래와 같은 상황을 가정해보자

App.svelte

<script>
import Parent from './Parent.svelte';
let name = 'Tom';
</script>

<Parent name={name} />

Parent.svelte

<script>
import Child from './Child.svelte';
export let name;
</script>

<div>
  Parent
</div>
<Child name={name} />

Child.svelte

<script>
export let name;
</script>

<div>
  Child {name}
</div>

App > Parent > Child 순으로 컴포넌트가 배치되어 있고, App에서 Child 컴포넌트로 데이터를 전달해야한다. 그럼 아래와 같은 코드가 되는데, 이 때 Parent 컴포넌트에서는 Child로 데이터 (name)을 전달하기 위해 본인은 사용하지않는 데이터를 선언해두고 받아서 전달하는 매개체 같은 역할을 해주어야한다.

이 정도 뎁스면 크게 다행이지만 컴포넌트 뎁스가 깊어지면 꽤나 큰 문제가 될 것 이다.

스토어는 이러한 문제점을 해결하기 위해 애플리케이션에서 사용되는 데이터를 한 곳에서 관리할 수 있도록 도와주는 데이터 저장소이다.

이 부분을 해결하기 위해 먼저 Svelte에서 제공하는 Store를 활용해 스토어를 작성해보자.

store.js
- 스토어에서 export될 때의 이름으로 외부에서 참조할 수 있다.
- 외부에서 값 변경이 가능하게 하려면 writable 함수를 사용해주어야한다.
- writable 함수를 사용하고 초기값을 주면 name은 외부에서 값 참조, 변경이 가능한 스토어 객체가 된다.
- Store가 외부라이브러리로 구성되어있는 타 프레임워크와 다르게 Svelte는 내장되어 있기 때문에 별도 의존성을 설치할 필요 없다.

import { writable } from 'svelte/store';
export let name = writable('');

위에서 export된 name은 writable함수에 의해 스토어 객체로 Wrapping된다.

스토어 객체는 set update subscribe 3가지 함수를 갖고 있고 이를 통해 값을 변경하고 사용할 수 있다.

set 함수는 스토어 객체에 값을 할당하는 함수이다.

update함수는 함수를 통해 스토어 객체의 값을 현재 값을 변경하는 함수이다.

subscribe는 현재 스토어의 값을 사용하는 함수 전달받아를 소비(consumer)시켜주는 함수이다.

<script>
import { name } from './store.js';

let nameValue;
// name 스토어의 값을 현재 컴포넌트의 nameValue에 할당시킴
name.subscribe(value => {
  nameValue = value;
});

// name 스토어의 값에 Hello World 문자열을 할당한다.
name.set('Hello World');

// name 스토어의 현재값에 !! 문자열을 붙힌다.
name.update(value => value + '!!');
</script>

<h1>{ nameValue }</h1>

위와 같은 함수들을 사용할 수 있지만 다소 불편한 부분이 있다.

Svelte에선 $ 키워드를 통해 스토어 데이터를 쉽게 다룰수 있다.

위 예시를 스토어를 사용한 코드로 변경해보자.

App.svelte
- 스토어의 변수를 참조할 땐 스토어 파일의 export된 이름으로 참조한다.
- 상술했듯 name은 일반 자료형 데이터가 아닌 스토어 객체이고 set, update, subscribe 함수를 사용해야하지만 $키워드를 통해 일반 변수처럼 사용할 수도 있다.
- 이를 Svelte에선 Auto-Subscribe라고 부른다.
- 이 때문에 Svelte에서는 변수앞에 $가 붙어있으면 스토에어 의해 관리되고 있는 데이터라는 의미이다.

<script>
import { name } from './store.js';
import Parent from './Parent.svelte';

$name = 'Tom';

</script>

<Parent />

Parent.svelte
- 기존 코드에서 App에서 데이터를 받아 Child로 전달해주는 코드가 없어졌다.

<script>
import Child from './Child.svelte';
</script>

<div>
  Parent
</div>
<Child />

Child.svelte
- props을 선언하는 코드 대신, 스토어에서 name 객체를 가져온다.
- $name 으로 필요한 곳에 사용한다.

[Svelte 시리즈] 데이터 바인딩, 조건문, 반복문, 이벤트 핸들링

@deveely — Thu, 17 Feb 2022 23:52:44 +0900

[Svelte 시리즈] 데이터 바인딩, 조건문, 반복문, 이벤트 핸들링

이 포스트는 HEROPY 님 유튜브 Svelte 강좌를 보고 공부한 내용을 정리한 포스트입니다.

데이터 단/양방향 바인딩

Svelte는 기본적으로 단방향 데이터 바인딩이다.

아래 예제에서 input에 name을 바인딩 했지만, 값을 변경한다고 name 변수의 값은 바뀌지 않는다.

<script>
let name = 'world';
</script>

<h1>Hello {name}</h1>
<input type="text" value={name} />

양방향 바인딩을 하려면 bind 키워드를 사용해 아래와 같이 작성해주면 된다.

<script>
let name = 'world';
</script>

<h1>Hello {name}</h1>
<input type="text" bind:value={name} />

조건문

마크업 영역에서 조건문을 사용할 수 있다.

{#if 조건} 조건문 내용 {/if} 와 같이 조건문 영역을 잡을 수 있다.

{:else}, {:else if 조건} 를 통해 else / else if 구문을 작성할 수 있다.

Svelte의 대부분 구문은 시작할 때 #, 중간단계는 :, 종료단계는 /인 것이 대부분이다.

<script>
let toggle = false;
</script>

{#if toggle}
    <h1>Hello {name}</h1>
{:else}
    <div>No name!</div>
{/if}

반복문

가장 기본적으로 for each 문은 {:each array as item} 반복문 내용 {/each} 으로 작성할 수 있다.

array는 배열 변수이며 as 뒤에는 반복문 내용에서 접근할 각 배열의 원소에 대한 이름을 지정한 것이다.

<script>
    let fruits = ['Apple', 'Banana', 'Cherry', 'Orange', 'Mango'];
</script>

<ul>
{#each fruits as fruit}
    <li>{fruit}</li>
{/each}
</ul>

참고할 점은 Svelte는 기본적으로 단방향이기 때문에 아래와 같은 코드는 fruits가 변경되더라도 화면 랜더링에는 변화가 없다. 화면 랜더링에 변화를 주려면 fruits를 변경한 후 다시 재할당 해주어야한다.

이벤트 핸들링

아래 예제는 box 클래스로 지정된 div를 클릭하면 배경색이 변경되도록 작성한 예시이다.

svelte에서 import한 onMount 함수는 document.ready와 같이 화면쪽 컴포넌트 들이 모두 구성이 완료된 후 실행될 콜백을 세팅해둘수 있는 함수이다.

<script>
    import { onMount } from 'svelte';
    let isRed = false;
    onMount(() => {
         const box = document.querySelector('.box');
         box.addEventListener('click', () => { isRed = !isRed });    
    });    
</script>

<div class="box" 
     style="background-color: {isRed ? 'red' : 'orange'}">
</div>

<style>
    .box {
        width: 300px;
        height: 150px;
        background-color: orange;
    }
</style>

svelte에서 제공해주는 방식대로 이벤트를 추가하려면 아래와 같이 할 수 있다.

on:이벤트명 과 함수를 전달하면 된다.

<script>
    let isRed = false;
</script>

<div class="box" 
     style="background-color: {isRed ? 'red' : 'orange'}"
     on:click={() => isRed = !isRed}>
</div>

<style>
    .box {
        width: 300px;
        height: 150px;
        background-color: orange;
    }
</style>

한 가지 예시를 더보자.

아래 예시는 input 태그에 input 이벤트 발생 시 해당 텍스트를 text 변수에 할당해주는 이벤트를 걸어두고

버튼 클릭 시 text변수를 ‘clicked!’ 로 변경해주는 이벤트를 걸어둔 예시이다.

<script>
    let text = '';
</script>

<h1>
    {text}
</h1>
<input type="text" 
       on:input={(e) => {text = e.target.value}} />
<button on:click={() => {text = 'clicked!'}}>
    Change Text
</button>

위 예시는 input의 값을 변경하면 값이 h1 태그 통해 출력되는 text 변수 값이 바뀌는 것을 볼 수 있다.

하지만 버튼을 클릭하면 h1 통해 출력되는 값은 바뀌지만, input 태크에 입력되어있는 값은 바뀌지 않는다.

그 이유는 위 input 태그에 값을 바인딩을 해두지 않아서이다.

아래와 같이 input 태그에 value로 값을 바인딩해주면 버튼 클릭으로도 input 태그 값이 바뀌는 것을 확인할 수 있다.

<script>
    let text = '';
</script>

<h1>
    {text}
</h1>
<input type="text" 
       on:input={(e) => {text = e.target.value}} 
       value={text}/>
<button on:click={() => {text = 'clicked!'}}>
    Change Text
</button>

이러한 방법은 양방향 바인딩으로도 해결해줄수 있다.

<input type="text" bind:value={text} /> 라고 bind 키워드를 사용해 양방향 바인딩을 해주는 것이 위와 똑같은 역할을 해주고 있는 것이다.

Docker Compose 를 이용해 Spring Boot + MySQL 서비스 구축 (기초)

@deveely — Mon, 17 Jan 2022 00:46:09 +0900

이 글은 개인적으로 공부를 목적으로 여러 블로그, 문서를 참조하며 작성하여 부정확하거나 내용이 부실할 수 있는점 양해드리며

잘못된 부분이 있다면 댓글로 알려주시면 감사하겠습니다 :)

간단한 웹 서비스를 구축한다고 가정한다.

간단하면서 일반적으로, 백엔드 애플리케이션 + DB와 프론트에 Nginx를 두는 구조를 많이 사용한다.

docker 환경에서는 백엔드 애플리케이션, DB, Nginx를 각각 설정하고 컨테이너화 하여 관리할 수 있다.

다만 서버 장비가 증설된다면 각 컨테이너 설정을 다시 해주어야하는 번거로움이 존재한다.

Docker Compose는 한 서비스를 위한 여러 컨테이너를 관리를 하나의 파일에서 할 수 있고 여러 컨테이너들을 동시에 실행시킬 수 있다. 이를 통해 위와 같이 매번 컨테이너를 설정해야하는 반복작업을 줄이며 서비스를 위한 컨테이너들의 관리를 쉽게 해준다.

이 예시에서는 아주 간단한 Spring Boot 애플리케이션 하나와, MySQL DB가 연동된 구조를 Docker Compose로 구성해보겠다.

1. Spring Boot 애플리케이션 구축

https://start.spring.io/ 에서 spring-boot-starter-data-jpa, mysql 의존성을 추가해 프로젝트 생성
빌드시스템은 Gradle 사용
간단한 REST API 하나 제공하는 서비스 생성
- Docker Compose 관련이 핵심이기 때문에, 예시코드가 좀 부실하더라도 양해 바랍니다.

// 엔티티 정의
@Entity
public class User {
    @Id
    private Long id;

    @Column
    private String name;

    // getters, setters
}

// 레파지토리 정의
@Repository
public interface UserRepository extends JpaRepository<User, Long> {
}

// 컨트롤러 정의
@RestController
@RequestMapping("/users")
public class UserController {

    private final UserRepository userRepository;

    public UserController(UserRepository userRepository) {
        this.userRepository = userRepository;
    }

    @GetMapping
    public List<User> getUsers() {
        return this.userRepository.findAll();
    }

    @GetMapping("/{id}")
    public User getUsers(@PathVariable Long id) {
        return this.userRepository.findById(id).orElse(null);
    }

}

application.yml에 설정 진행
- MySQL서버가 컨테이너 환경이 아닌 외부에 떠있는 경우엔 아래와같이 설정파일에 DB 설정을 해둔다.
- 하지만 MySQL 서버가 컨테이너로 구성되어있는 경우엔 설정할 수 있는 방벙이 다양하다.
  - Spring Boot 설정값 외부 주입을 이용하는 방법
    - 설정파일내에서 ${} 로 외부 환경변수 값을 사용할 수 있다.
  - 설정값을 외부에서 주입하지 않고 도커 서비스명으로 참조하는 방법
    - Docker Compose로 실행시키는 컨테이너들은 동일 네트워크로 묶여 상호 통신이 가능
    - 도커 네트워크에 대한 내용은 별도 포스트 참조
  - Spring Boot Relaxed Binding을 이용하면, application.yml에 datasource 설정이 없어도됨
    - https://docs.spring.io/spring-boot/docs/current/reference/html/features.html#features.external-config.typesafe-configuration-properties.relaxed-binding.environment-variables

# 아래는 MySQL이 컨테이너가 아닌 경우에 대한 설정 예시
spring:
  datasource:
    url: jdbc:mysql://localhost:3306/userdb
    username: user
    password: userpwd
    driver-class-name: com.mysql.cj.jdbc.Driver
  jpa:
    database-platform: org.hibernate.dialect.MySQL5Dialect
    show-sql: true
    hibernate:
      ddl-auto: none

# 외부 환경변수를 주입받아 설정되도록 할 경우에 대한 예시
spring:
  datasource:
    url: ${DB_CONNECTION_URL}
    username: ${DB_USER}
    password: ${DB_PASSWORD}
    driver-class-name: com.mysql.cj.jdbc.Driver
  jpa:
    database-platform: org.hibernate.dialect.MySQL5Dialect
    show-sql: true
    hibernate:
      ddl-auto: none

# 외부 환경변수를 주입받아 설정되도록 할 경우에 대한 예시
# 호스트네임의 "db"는 도커 네트워크상 참조가능한 이름으로, 이후 docker-compose 설정할 때 다시 다루겠습니다.
spring:
  datasource:
    url: jdbc:mysql://database:3306/userdb 
    username: user
    password: userpwd
    driver-class-name: com.mysql.cj.jdbc.Driver
  jpa:
    database-platform: org.hibernate.dialect.MySQL5Dialect
    show-sql: true
    hibernate:
      ddl-auto: none

이후 프로젝트를 빌드하면 프로젝트경로/build/libs 밑에 jar 파일이 생성됨
백엔드 애플리케이션 Dockerfile 작성
- Dockerfile 위치는 프로젝트 루트

FROM openjdk:11
ADD build/libs/app.jar app.jar
ENTRYPOINT ["java", "-jar", "app.jar"]

2. Docker Compose 설정

Docker Compose는 docker-compose.yml 이라는 파일을 통해 설정한다.

version: "3"
services:
  database:
    image: mysql
    environment:
      MYSQL_DATABASE: userdb
      MYSQL_USER: user      
      MYSQL_PASSWORD: userpwd
      MYSQL_ROOT_HOST: '%'
      MYSQL_ROOT_PASSWORD: rootpwd
    volumns:
      - ./db/data:/var/lib/mysql
    ports:
      - 3306:3306
    restart: always
  application:
    build: .
    depands_on:
      - database
    environment:
      SPRING_DATASOURCE_URL: jdbc:mysql://localhost:3306/userdb
      SPRING_DATASOURCE_USERNAME: user
      SPRING_DATASOURCE_PASSWORD: userpwd
    restart: always

설정파일을 살펴보면 아래와 같다.

version
- Comose 파일 버전로 도커 엔진 버전별 사용가능한 버전이 존재
services
- Docker Compose로 하나로 관리할 서비스들을 정의. 이들이 각각 컨테이너가 된다.
- services 아래 설정되는 각 서비스의 이름으로 컨테이너간 통신할 수 있다.

먼저 DB 서비스을 보면

database
- “database”라는 이름의 서비스
- 백엔드에서 DB 설정을 한다면 hostname에 이 값을 사용할 수 있다.
- image
  - mysql 기반 이미지 사용
- environment
  - 해당 컨테이너에서 사용할 환경변수 설정
  - mysql 이미지는 컨테이너의 환경변수를 참조하여 MySQL DB, 유저 정보등을 구성함
- volumns
  - 호스트의 파일시스템과 도커 컨테이너의 파일시스템을 마운트함
  - DB 데이터 유지를 위해 필수적으로 설정되야함
- ports
  - 호스트의 포트와 컨테이너의 포트를 매핑함
- restarts
  - 오류 등으로 컨테이너가 종료됐을때 재시작 여부

아까

다음은 Spring Boot 애플리케이션 컨테이너에 대한 설정이다.

application
- “application”라는 이름의 서비스
- build
  - Dockerfile을 이용해 컨테이너화 할 때 사용하는 옵션
  - 위 database 컨테이너와 달리 Dockerfile을 빌드하여 컨테이너화 해야하기 때문에 사용
  - Dockerfile이 docker-compose.yml 파일과 다른 경로에 있을경우엔 “.” 대신 해당 경로 지정
- depends_on
  - 각 서비스간 종속성을 두어 실행 순서를 정할 수 있다.
  - 이 예시에선 DB가 먼저 올라가야하기 때문에 “database” 서비스에 의존성을 갖게함
- environment
  - database 설정과 동일하게, 환경변수를 컨테이너 내부에 세팅해주기 위해 사용한다.
  - 프로젝트에서 채택한 방식에 따라 적절하게 설정해준다.
- restarts
  - 위와 동일

이렇게 docker-compose.yml 파일까지 작성이 완료되면 이제 실행만 하면 된다.

아래 docker-compose 기본적인 명령어들이다. 전체적으로 Docker 명령어와 유사하다

# 컨테이너화 + 데몬모드로 각 컨테이너 실행
docker-compose up -d 

# 상태 체크
docker-compose ps

# 컨테이너 실행 / 종료
docker-compose start
docker-compose stop

# Docker Compose 제거 (volumn, network 포함 제거)
docker-compose down

# 로그 확인
docker-compose logs

Spring Boot 애플리케이션 Docker 컨테이너로 배포 (기초)

@deveely — Sun, 16 Jan 2022 03:44:03 +0900

명령어 간략 정리

docker images            # 이미지 목록 조회
docker ps                # 실행중인 컨테이너 목록 조회 (-a 옵션 시 종료된 컨테이너 목록도 보여줌)
docker kill CONTAINER_ID # 컨테이너 종료

도커 이미지 빌드 명령어

docker build --tag [repo:tag] [Dockerfile path]

e.g.
docker build --tag myservice:0.1

컨테이너 실행 관련 명령어

docker run IMAGE_ID       # 이미지ID 기반 새 컨테이너 생성하여 실행
docker run repo:tag       # 레파지토리&태그에 해당하는 이미지 기반 새 컨테이너 생성하여 실행

docker start CONTAINER_ID # 기존 생성된 특정 컨테이너를 실행시킴
docker stop CONTAINER_ID  # 기존 실행중인 특정 컨테이너를 종료시킴

docker rm CONTAINER_ID    # 컨테이너 삭제
docker rmi IMAGE_ID       # 이미지 삭제

SpringBoot Dockerfile 예시

Dockerfile을 작성한다.
1. JDK11 환경 사용
2. build/libs/app.jar 파일 (Dockerfile 기준 상대경로)을 app.jar라는 이름으로 컨테이너 내부에 추가
3. “java -jar app.jar” 명령어 실행 (각 명령어 토큰을 배열 형태로 설정)

FROM openjdk:11
ADD build/libs/app.jar app.jar
ENTRYPOINT ["java", "-jar", "app.jar"]

Dockerfile 이미지로 빌드
- 현재 디렉토리 내 Dockerfile을 app Repository, 0.1 Tag로 빌드한다.

docker build -t app:0.1 .

컨테이너 실행
- -d 옵션 : 데몬 모드로 실행 (백그라운드에서 동작)
- -p 옵션 : 호스트 포트로 들어오는 요청을 도커 컨테이너 내부 포트로 포워딩해줌 (호스트:컨테이너)
  - 아래 예시에선 5000번 포트로 들어오는 요청이 도커 컨테이너의 8080포트로 포워딩된다.
- 실행할 이미지 : 이미지ID 또는 repo:tag 형태의 이미지 식별자 전달

docker run -d -p 5000:8080 app:0.1

컨테이너 접속하여 잘 실행되고 있는지 확인

docker exec -it /bin/bash
ps -ef | grep java

Java / Servlet 비동기 기술 흐름 with Spring

@deveely — Thu, 13 Jan 2022 03:14:51 +0900

1. Servlet 3.0 이전

기존 알고 있었던과 같이 1 Request per 1 Thread 할당 방식이다.

오래걸리는 무거운 작업은 @Async 를 활용해 비동기로 처리할 수 있었지만 이는 말 그대로 해당 스레드 내부에서 유효할 뿐 해당 작업이 끝나기 까지 그 스레드가 반환되지 못하는건 매한가지였다.

톰캣의 NIO 지원은 HTTP Connection 관련 부분을 비동기로 처리하는 것 뿐 서블릿 동작과는 별개의 문제

이 방식의 문제점은 짧게 끝나는 작업이 오래 걸리는 작업이 스레드를 오래 점유하여 덩달아 오래걸리게 되는 문제가 있었다.

2. Servlet 3.0

Servlet 3.0 부터는 이런 문제점을 어느정도 해결하여 오래 걸리는 작업을 별로 스레드에 할당하여 처리하고,

해당 스레드는 빨리 반환하여 다른 요청을 받을 수 있도록 개선하였다.

기존의 HTTP Request, Response를 담당하는 스레드는 서블릿 스레드, 작업을 처리하는 스레드는 작업 스레드(워커 스레드)로 구분된다.

서블릿 스레드 내부에서 비동기 작업(별도 스레드)이 실행되면 해당 작업은 작업 스레드가 처리하고, 현재 서블릿 스레드는 즉시 풀에 반납된다.

Spring 에선 컨트롤러 레이어에서 Callable 등이 반환되면 해당 작업이 작업 스레드에서 시작된다.

3. Servlet 3.1

Servlet 3.0에선 서블릿 스레드의 Request Read, Response Write 작업은 동기방식으로 진행됐었는데, 3.1 부턴 이 작업까지 비동기로 진행하도록 개선되었다.

4. DeferredResult와 Queue 활용

DefferedResult<T> 는 네이밍 그대로 지연된 결과 라는 뜻을 담고 있다.

Spring 컨트롤러 레이어에서 DefferedResult가 반환되면 해당 객체에 결과가 세팅될 때 까지 응답을 보내지 않고 기다린다.

보통 한 곳에서 요청하면 (풀링 개념) DefferedResult 객체를 큐에 저장하고 외부에서 이벤트를 주었을 때 해당 객체에 값이 설정되게 하며 풀링하고 있던 클라이언트에선 그 즉시 결과를 받도록 구현할 수 있다.

DefferedResult의 특징은 워커 스레드를 사용하지 않으며 서블릿 스레드도 즉시 반환한다는 점이다.

DefferedResult 객체만 메모리에 유지되면 결과가 세팅되는 시점에 바로 응답을 보낼 수 있다.

아래 아주 간단한 사용사례이다.

@RestController
public static class MyController {
	Queue<DeferredResult<String>> results = new ConcurrentLinkedQueue<>();
	
	// 아래 코드를 통해 클라이언트가 풀링하는 API
	@GetMapping("/dr")
	public DeferredResult<String> deferredResult() {
		DeferredResult<String> dr = new DeferredResult<>();
		results.add(dr);
		return dr;
	}

	@GetMapping("/dr/count")
	public String drCount() {
		return String.valueOf(results.size());
	}

	// 외부에서 이벤트 발생시키는 API 
	@GetMapping("/dr/event")
	public String drEvent(String msg) {
		for (DeferredResult<String> dr :results) {
			dr.setResult("Hello " + msg); // 이 때 결과가 세팅되며, 이 객체를 풀링하고 있는 곳에선 결과를 받을수있음
			results.remove(dr);
		}
		return "OK";
	}

}

비동기 작업 수행 후 결과를 처리할 때도 사용할 수 있다.

public class MyController {

    @GetMapping
    public ListenableFuture<String> api() {
        ListenableFuture<String> future = doAsyncTask();
				// future.get(); => 이 코드가 호출되는 순간 서블릿 스레드가 점유되어 비동기 의미가 없어짐
				return future;
    }

	  @GetMapping
    public DeferredResult<String> api() {
        DeferredResult<String> dr = new DeferredResult<>();
        ListenableFuture<String> future = doAsyncTask();
				// 콜백을 추가하고 콜백 내에서 DeferredResult에 값을 설정해줌
				future.addCallback(res -> {
						dr.setResult(res);
				}, err -> {
						dr.setErrorResult(err);
				});				
				return dr;
    }
    
}

5. ResponseBodyEmitter

SSE (Server Sent Event)는 HTTP 기반 서버 사이드 스트리밍 기술이라 생각하면 된다. (https://hamait.tistory.com/792)

WebSocket이 서버/클라이언트간 양방향 통신을 지원한다면 SSE는 서버 → 클라이언트로만 데이터를 스트리밍하면 되는 시나리오에 유용하게 사용될 수 있다. (이전의 ajax 롱 풀링, 푸시 등)

실제로 구현하려면 꽤 복잡한 구현이 필요하지만 Spring의 ResponseBodyEmitter 를 사용하면 복잡한 HTTP 레벨 구현 없이 쉽게 스트리밍 API를 구현할 수 있다.

아래 예제는 1초에 1건씩 응답을 보내는 Emitter를 구현한 것이다.

@RestController
public static class MyController {

	@GetMapping("/streaming")
	public ResponseBodyEmitter streaming() {
		ResponseBodyEmitter emitter = new ResponseBodyEmitter();
		Executors.newSingleThreadExecutor().execute(() -> {
			for (int i = 0; i <= 50; i++) {
				try {
					emitter.send("<p> Stream " + i + "</p>"); // 클라이언트로 이벤트 보냄
					Thread.sleep(1000);
				} catch (Exception e) {}
			}
		});
		return emitter;
	}

}

Java CompletableFuture 개념 및 간단한 활용 사례

@deveely — Wed, 12 Jan 2022 02:11:24 +0900

Future 는 비동기 작업 수행의 결과를 담고있는 자바의 인터페이스이다.

ListenableFuture 는 Spring 에서 제공하는 인터페이스로 Future에 콜백을 등록해 사용할 수 있도록 한 방식이다.

자바 8 때 소개된 CompletableFuture 는 여러 비동기 작업을 결합하고 처리하는데 기존 방식에 비해 훨씬 편하게 수행할 수 있다.

아래는 간단히 반환값이 없는 2개 비동기 작업을 수행하는 예시이다.

CompletableFuture
	.runAsync(() -> log.info("runAsync"))
	.thenRun(() -> log.info("thenRun"));

반환값이 있는 비동기 작업은 아래와 같이 할 수 있다.

CompletableFuture
	.supplyAsync(() -> 1)  // 비동기적으로 값을 제공 (외부 API 호출 등)
	.thenApply(i -> i + "hi")  // 값을 가공
	.exceptionally(e -> e.getMessage()) // 작업 중 오류가 발생했을 경우 사용될 값
	.thenAccept(i -> System.out.println(i)); // 값을 사용

CompletableFuture 에서 할 수 있는 작업들은 CompletionStage 에 정의되어있다.

CompletableFuture 에서 수행되는 작업은 내부에 관리되는 ForkJoinPool에 의해 실행된다.

이때 ForkJoinPool의 병렬도가 1 이상이면 ForkJoinPool, 아니면 각 작업마다 하나의 스레드가 할당되는 ThreadPerTaskExecutor가 사용된다.

(풀 병렬도는 ForkJoinPool.getCommonPoolParallelism() 메소드로 가져오는데,, 이게 정확히 무슨 값을 의미하는지는 잘 모르겠음. 아시는 분 댓글 남겨주시길 바랍니다)

메소드 네이밍에 따라 *Async 로 호출되는 메소드는 두 번째 인자로 특정 스레드풀에서 실행되게 할 수도 있다.

만약 어떤 작업 내에서 리턴값이 CompletableFuture가 되어야하는 경우 thenCompose 를 사용한다.

이는 또다른 비동기 작업을 수행하되, CompletableFuture 타입이 아닌경우 CompletableFuture로 변환하여 리턴할 수 있다.

아래 예시는 스프링의 ListenableFuture를 중간작업으로 수행하는데 CompletableFuture 체인에 연결한 예시이다.

// Callback 방식의 ListenableFuture를 CompletableFuture로 변환해주는 메소드
// ListenableFuture 콜백에 CompletableFuture 방식의 메소드를 전달한다.
public static <T> toCompletableFuture(ListenableFuture<T> lf) {
    CompletableFuture<T> cf = new CompletableFuture<>();
    lf.addCallback(cf::complete, cf::completeExceptionally);
    return cf;
}

CompletableFuture
        .supplyAsync(() -> 1)
        .thenCompose(i -> {
            ListenableFuture<Integer> lf = doListenableFutureJob();            
            return toCompletableFuture(lf); // CompletableFuture 체인에 연결해주기위해 바꿔줌
        })
        .thenAccept(i -> System.out.println(i));

[짧은정리] Gradle Multi Module 구성 시 참고사항

@deveely — Sat, 11 Dec 2021 03:39:45 +0900

멀티 모듈 구성 시 보통 common 모듈을 두고 나머지 모듈 (e.g. API 모듈, Batch 모듈, ..) 에서 common 모듈을 참조하도록 구성한다.

common 모듈에 작성한 공통 로직 + 의존성을 타모듈들에서 중복없이 사용하기 위함이다.

이 때 common 모듈에 dependency를 implementation으로 잡을 경우 common을 참조하는 타 모듈에선 common의 코드들만 노출되고 common의 dependency들은 노출되지 않는다.

예를 들어 common 모듈에 JPA Starter 의존성을 implementation으로 잡으면 api, batch 모듈에선 JPA 관련 코드가 노출이 안되는 것이고 JPARepository 등을 상속받아 구현된 Repository들에 findAll, save 등 메소드를 사용할 수 없다는 뜻이다.

이를 해결하기 위해 의존성을 api로 잡으면 이 부분이 해결된다. (Gradle 6 이하에선 compile, 7 이상에선 api)

MySQL 스키마 추출 (DDL Export)

@deveely — Sun, 21 Nov 2021 02:54:38 +0900

MySQL 특정 DB DDL 추출하는 법 정리

mysqldump 프로그램을 사용하고, --no-data 옵션으로 데이터를 제외한 나머지 오브젝트들만 export한다.

mysqldump -h [DB서버IP] -u root -p --no-data [대상DB] > [추출파일명]

참고로 AUTO_INCREMENT 값이 유지되기 때문에 유지를 원하지 않는 경우 1로 변경해두어야 한다.

Kotlin 프로퍼티 (Properties and Fields)

@deveely — Tue, 7 Sep 2021 02:47:24 +0900

보통 객체지향 프록그래밍에서 클래스를 정의할 때 객체의 상태는 멤버변수 (필드)로 행위는 메소드로 표현합니다.
그리고 보통 멤버변수가 있으면 객체의 값을 설정하고 가져오는 (setter / getter) 메소드가 동반되는 경우가 많은데요.

코틀린에서는 이런 요소를 아우르는 프로퍼티라는 개념이 제공됩니다.
즉 프로퍼티는 getter, setter와 같은 접근자를 포함하고있는 필드입니다.

프로퍼티 정의

프로퍼티를 정의하는 전체 문법은 아래와 같습니다.

(var/val) <propertyName>[: <PropertyType>] [= <property_initializer>]
          [<getter>]
          [<setter>]

var / val : 프로퍼티 선언을 위한 예약어. var는 초기화 후 값 변경이 가능한 프로퍼티, val은 초기화 후 값 변경이 불가능한 프로퍼티
propertyName: 프로퍼티명
PropertyType: 프로퍼티 타입 (타입 추론이 가능한 경우 생략 가능)
property_initializer: 프로퍼티 값 초기화 (초기화가 불필요한 경우 생략 가능)
getter / setter : 해당 프로퍼티에 대한 getter / setter를 정의 (생략할 경우 default getter, setter 적용) val 프로퍼티는 setter를 가질수없음

프로퍼티와 getter, setter는 접근제한자 (public, internal, protected, private) 적용이 가능합니다.

이제 프로퍼티가 자바로 변환되면 어떻게 적용되는지 살펴보겠습니다.
아래 name, age은 생성자 인자이면서 프로퍼티입니다.

class Person(var age: Int, val name: String)

이 코드가 자바로 변환되면 아래와 같습니다.

public static final class Person {
    private int age;
    @NotNull
    private final String name;

    public final int getAge() {
        return this.age;
    }

    public final void setAge(int var1) {
        this.age = var1;
    }

    @NotNull
    public final String getName() {
        return this.name;
    }

    public Person(int age, @NotNull String name) {
        Intrinsics.checkNotNullParameter(name, "name");
        super();
        this.age = age;
        this.name = name;
    }
}

var로 선언한 age의 경우 getAge, setAge와 같이 getter, setter가 자동으로 생성되었습니다.
반면 val로 선언한 name의 경우 값 변경이 불가능하고 setter를 정의할 수 없기 때문에 당연하게 setter가 생성되지 않은 것을 확인할 수 있습니다.

보통 자바에서는 getter / setter는 필드값 반환, 세팅의 역할이 주였는데요.
코틀린에서의 getter / setter는 보다 다양하게 활용이 가능합니다.

class Product(var size: Int) {
    val isEmpty
        get() = this.size == 0
}

이렇게 작성한 코드는 자바로 다음과 같이 변환됩니다.

public static final class Product {
  private int size;

  public final boolean isEmpty() {
      return this.size == 0;
  }

  public final int getSize() {
      return this.size;
  }

  public final void setSize(int var1) {
      this.size = var1;
  }

  public Product(int size) {
      this.size = size;
  }
}

이런식으로 다른 필드를 활용한 계산된 (computed) 속성으로도 활용이 가능합니다.

또한 커스텀 setter를 지정하여 프로퍼티 값 설정 전 유효성 검사, 혹은 다른 동작도 지정할 수 있습니다.
아래 예시에서는 1~3 값만 설정가능한 grade 프로퍼티를 정의했습니다.
setter 로직 중 field가 실제 프로퍼티의 값인데 코틀린에서는 이를 Backing Fields라고 합니다.

class Person {
    var grade = 1
        set(value) {
            if (value in 1..3) {
                field = value
            } else {
                throw IllegalArgumentException("Grade 는 1 ~ 3 사이여야합니다.")
            }
        }
}

Kotlin 생성자 개념과 사용법 정리

@deveely — Tue, 7 Sep 2021 01:42:57 +0900

코틀린에서 생성자를 정의하는 여러가지 방법에 대해 정리합니다.
코틀린 생성자는 크게 주 생성자(primary constructor)와 부 생성자(secondary constructor)로 나뉘고 각각 제약이 조금씩 다릅니다.

1. 주 생성자 (Primary constructor)

기본적으로 constructor 키워드를 통해 생성자를 정의할 수 있습니다.
constructor 키워드 앞에 접근 제한자를 지정할 수 있습니다.
constructor 키워드 자체를 생략할 수도 있습니다. 단, 이경우엔 접근 제한자는 지정할 수 없습니다.
이렇게 선언하는 생성자를 주 생성자라고 합니다.

class Person constructor(name: String, age: Int)

// 접근 제한자 지정
class Person private constructor(name: String, age: Int)

// constructor 키워드 생략 가능
class Person(name: String, age: Int)

하지만 이 경우엔 생성자 시그니쳐만 정의할 수 있고 초기화 로직 (내부 프로퍼티에 할당)을 작성할 수 가 없습니다.
즉 위 코드만 가지고는 객체 생성 시 전달되는 name, age를 클래스 내부에서 사용할 수 없는 것입니다.
이러한 상황에 대비해 init이란 키워드가 제공됩니다. 초기화 로직을 포함 추가로 필요한 로직이 있다면 호출할 수 있습니다.
혹은 프로퍼티를 정의하면서 바로 대입해줄 수 있습니다.

class Person(name: String, age: Int) {
    val name: String
    val age: Int

    // 아래 init 블록 통해 초기화 가능
    init {
      this.name = name
      this.age = age
    }

    // 혹은 init 블록 사용 없이 프로퍼티 선언 후 대입
    val name = name
    val age = age
}

하지만 매번 이런식으로 프로퍼티에 값을 할당해주는 것은 상당히 번거로운 일이 될 수 있습니다.
코틀린에서는 생성자 시그니쳐를 작성할 때 인자 선언과 동시에 프로퍼티로 할당해주는 문법을 지원합니다.
아래와 같이 인자 선언할 때 val / var 을 주면 됩니다.
또한

class Person(val name: String, val age: Int)

2. 부 생성자 (Secondary constructor)

주 생성자 이외에 추가로 생성하는 생성자들은 모두 부 생성자가 됩니다.
부 생성자는 주 생성자에 비해 몇가지 제약이 있습니다.

부 생성자는 주 생성자를 반드시 상속해야합니다.
부 생성자에는 인자 선언과 동시에 프로퍼티 할당을 할 수 없습니다.

class Person(val name: String, val age: Int) {

    constructor(grade: Int) {}  // 오류 발생

    constructor(name: String, age: Int, grade: Int): this(name, age) {  // 이렇게 주 생성자를 상속해줘야함

    }

    constructor(name: String, age: Int, val grade: Int): this(name, age) {  // 부 생성자에서 var / val 사용 불가
    }

}

주 생성자가 없는 클래스가 존재할 수도 있다. 이 경우엔 아래와 같이 부 생성자를 자유롭게 선언해둘 수 있다.

class Person {

    constructor(name: String) { 
    }

    constructor(name: String, age: Int) { 
    }

    constructor(name: String, age: Int, grade: Int) { 
    }

}

다만 이렇게 할 일이 거의 없는게.. 주 / 부 생성자 상관 없이 각 인자에 기본값(default)를 정의해 줄 수 있기 때문에
이를 활용해 대부분 주 생성자 하나로 해당 클래스의 객체 생성 방법을 대부분 다 표현해낼 수 있습니다.

class Person(val name: String, val age: Int, val grade: Int = 1)

fun main(args: Array<String>) {
    val p1 = Person("p1", 20)
    val p2 = Person("p2", 21, 2)
}

Kotlin 클래스 주요 개념 with Java class와 차이점

@deveely — Sun, 29 Aug 2021 18:16:36 +0900

클래스 정의에 대한 Java와 Kotlin 차이점

이 포스트에서는 코틀린에서의 클래스가 자바와 어떻게 다른지 대략적으로 정리한 내용을 다룹니다.
공부하면서 정리한 포스트이기에 잘못된 내용이나 부족한 부분이 있을 수 있습니다.
댓글로 일러주시면 감사하겠습니다 :)

1. class 키워드에 대한 차이점

기본적으로 자바에서는 class 키워드를 통해 클래스를 정의합니다.

class SomeClass {
    // 속성, 메서드 선언
}

코틀린에서는 이렇게 선언하면 기본적으로 클래스를 포함한 모든 멤버가 final로 정의됩니다. (상속 불가)

class SomeClass {
    // 속성, 메서드 선언
}

때문에 코틀린에는 상속 및 재정의가 가능한 요소로 만들어주는 open이라는 키워드가 있습니다.
클래스, 속성, 메서드 모든 곳에 사용이 가능합니다.

// 상속 가능
open class SomeClass {
    // final로 선언되어 상속받는 클래스에서 재정의 불가
    fun someFunction(): Int {
        return 1
    }

    // 상속받는 클래스에서 재정의 가능
    open fun otherFunction(): Int {
        return 2
    } 
}

// 이렇게 open 클래스인 SomeClass를 상속받을 수 있다.
class ExtendSomeClass(): SomeClass() {
    override fun otherFunction(): Int {
        return 4
    }
}

이는 추상 클래스에서도 동일하게 적용됩니다.

abstract class Machine(val name: String) {    
    // 반드시 재정의해야하는 메서드
    abstract fun connect()

    // 선택적으로 재정의할 수 있는 메서드
    open fun prepare() {
        println("Prepare machine")
    }

    // 재정의 불가
    fun start() {
        connect()
        parepare()
        println("Start machine - $name")
    }
}

class LocalMachine(name: String): Machine(name) {
    override fun connect() {
        println("Connect machine - $name")
    }

    override fun prepare() {
        println("Prepare machine on local")
    }
}

요약해보자면

Kotlin에서 class 키워드는 기본적으로 멤버들을 final로 정의된다.
open 키워드를 사용하면 각 멤버 (클래스, 속성, 메서드)의 상속 및 재정의 여부를 제어할 수 있다.

2. data class

data class는 용어 그대로 데이터를 보관하는 목적의 클래스들을 정의할 때 사용합니다.
data 키워드를 클래스 선언 앞에 붙혀주면 toString(), hashCode(), equals(), copy() 메소드를 자동으로 생성해줍니다.

data class Machine(val name: String, val version: Long)

fun main(args: Array<String>) {
    val aMachine = Machine("A-Machine", 1)
    println("machine info ${aMachine}")
}

여기서 Data Class인 Machine를 자바 코드로 변환해보면 아래와 같습니다. (Intellij Decompile 기능 사용)
Lombok의 @Data, @Getter, @EqaulsAndHashCode, @ToString 을 data 키워드 멋지게 해주는 것 같습니다.

public final class Machine {
   @NotNull
   private final String name;
   private final long version;

   @NotNull
   public final String getName() {
      return this.name;
   }

   public final long getVersion() {
      return this.version;
   }

   public Machine(@NotNull String name, long version) {
      Intrinsics.checkNotNullParameter(name, "name");
      super();
      this.name = name;
      this.version = version;
   }

   @NotNull
   public final String component1() {
      return this.name;
   }

   public final long component2() {
      return this.version;
   }

   @NotNull
   public final Machine copy(@NotNull String name, long version) {
      Intrinsics.checkNotNullParameter(name, "name");
      return new Machine(name, version);
   }

   // $FF: synthetic method
   public static Machine copy$default(Machine var0, String var1, long var2, int var4, Object var5) {
      if ((var4 & 1) != 0) {
         var1 = var0.name;
      }

      if ((var4 & 2) != 0) {
         var2 = var0.version;
      }

      return var0.copy(var1, var2);
   }

   @NotNull
   public String toString() {
      return "Machine(name=" + this.name + ", version=" + this.version + ")";
   }

   public int hashCode() {
      String var10000 = this.name;
      return (var10000 != null ? var10000.hashCode() : 0) * 31 + Long.hashCode(this.version);
   }

   public boolean equals(@Nullable Object var1) {
      if (this != var1) {
         if (var1 instanceof Machine) {
            Machine var2 = (Machine)var1;
            if (Intrinsics.areEqual(this.name, var2.name) && this.version == var2.version) {
               return true;
            }
         }

         return false;
      } else {
         return true;
      }
   }
}

근데 자바 코드를 보다보면 component1(), component2() 이라는 정의한 적이 없는 메소드가 생성 되어있는데요.
이는 Kotlin의 Destructuring Declaration (구조분해할당)과 관련이 있는데요.

간단하게 말해 아래와 같이 클래스 내부 속성을 여러 변수로 나누어 할당할 수 있는 Kotlin의 기능입니다.

val machine = Machine("My Machine", 1)
val (name, version) = machine
println("name: $name, version: $version")

이를 자바로 표현하면 아래와 같이 되겠죠

Machine machine = new Machine("My Machine", 1);
String name = machine.component1();
long version = machine.component2();
System.out.println(String.format("name: %s, version: %d", name, version));

이렇기 때문에 data class에서는 component1, component2 같은 메소드를 자동으로 생성하는 것입니다.
이는 일반 클래스에서도 가능합니다만 componentN 메소드들을 직접 구현해주어야 합니다!

요약해보자면

Kotlin에서는 데이터 보관 목적의 클래스를 정의하기 위한 Data Class를 지원하며 키워드는 data class 이다.
Data Class는 toString(), hashCode(), equals(), copy()를 자동으로 생성해준다.
구조분해할당을 위한 componentN() 메서드를 자동으로 생성해준다.

3. object 클래스

Kotlin에서 class 대신 object 키워드를 통해 클래스를 정의할 수 도 있는데요.
이 키워드는 해당 클래스를 싱글톤으로 만들어주는 기능을 합니다.

object MachineFactory {
    val machines = mutableListOf<Machine>()
    fun createMachine(name: String): Machine {
        val machine = Machine(name)
        machines.add(machine)
        return machine
    }
}

class Machine(val name: String)

이렇게 object 키워드만 사용했을뿐 기존 자바에서 싱글톤을 구현하기위해 했던 부수적인 코드들은 하나도 없습니다.
하지만 아래와같이 getInstance() 메소드는 없지만 싱글톤 클래스로 사용 / 동작하게 됩니다.

fun main(args: Array<String>) {
    val aMachine = MachineFactory.createMachine("A-Machine")
    println(MachineFactory.machines.size)
    val bMachine = MachineFactory.createMachine("B-Machine")
    println(MachineFactory.machines.size)
}

이를 자바코드로 변환해보면 아래와 같이 INSTANCE라는 변수가 static 블록에서 한번 초기화 되며 MachineFactory.INSTANCE와 같이 해당 객체만 참조됨을 알 수 있습니다.

public final class MachineFactory {
   @NotNull
   private static final List machines;
   @NotNull
   public static final MachineFactory INSTANCE;

   @NotNull
   public final List getMachines() {
      return machines;
   }

   @NotNull
   public final Machine createMachine(@NotNull String name) {
      Intrinsics.checkNotNullParameter(name, "name");
      Machine machine = new Machine(name);
      machines.add(machine);
      return machine;
   }

   private MachineFactory() {
   }

   static {
      MachineFactory var0 = new MachineFactory();
      INSTANCE = var0;
      boolean var1 = false;
      machines = (List)(new ArrayList());
   }
}

public static final void main(@NotNull String[] args) {
    Intrinsics.checkNotNullParameter(args, "args");
    Machine aMachine = MachineFactory.INSTANCE.createMachine("A-Machine");
    int var2 = MachineFactory.INSTANCE.getMachines().size();
    boolean var3 = false;
    System.out.println(var2);
    Machine bMachine = MachineFactory.INSTANCE.createMachine("B-Machine");
    int var6 = MachineFactory.INSTANCE.getMachines().size();
    boolean var4 = false;
    System.out.println(var6);
}

참고로 Kotlin에서는 static 키워드가 없는대신 companion object라는 키워드가 있는데요.
아래와 같이 클래스 내에 companion object 블록 내에 변수와 함수를 선언하면, 이것들이 static 멤버로 동작하게 됩니다.

class Config {
    companion object {
        var PREFIX = "config."
        fun getConfig(name: String): String {
            // do something
        }
    }
}

fun main(args: Array<String>) {
    println(Config.PREFIX)
    val someConfigValue = Config.getConfig("some-config")
}

4. 자바 클래스와 코틀린 클래스의 멤버 가시성 차이 (Visibility)

코틀린과 자바는 멤버 가시성에도 차이가 있는데요.
큰 차이점으로는

기본 접근제어자(아무것도 적지 않을경우)는 public 이다.
패키지 접근 제어성이 없는 대신 모듈에 대한 접근 제어성이 있다.
프로젝트 하위 패키지 상위 개념으로, 한꺼번에 컴파일되는 코틀린 파일들의 모임이다.

자바
- public: 모든 곳에서 접근 가능
- protected: 같은 패키지 내이거나 파생된 클래스에서 접근 가능
- default: 같은 패키지 내에서만 접근 가능 (기본)
- private: 같은 클래스 내에서만 접근 가능
코틀린
- public: 모든 곳에서 접근 가능 (기본)
- internal: 같은 모듈 내에서만 접근 가능
- protected: 해당 클래스와 해당 클래스를 상속받은 클래스에서만 접근 가능. 자바와 달리 패키지가 같다고해서 접근할 수 없음
- private: 같은 클래스 안에서만 접근 가능

참고

리액티브 프로그래밍 시리즈 3 - 스레드 스케쥴링 (Thread scheduling)

@deveely — Wed, 25 Aug 2021 00:06:34 +0900

이 포스트 시리즈는 Reactive Programming은 토비의 스프링 저자 이일민님의 리액티브 프로그래밍 유튜브 강좌를 공부하며 정리한 내용입니다.

1. 표준 Reactive streams의 문제점

지금까지 봐온 코드는 전부 하나의 스레드에서 동작한다.
이 코드를 실전에서 활용하기엔 그닥 유용하지 않은 코드이다.
- Publisher가 Blocking I/O를 사용하거나 데이터를 준비하는데 시간이 오래걸릴 경우 그걸 다 기다려야하기 때문이다.
- 반대로 Publisher의 데이터 생성은 굉장히 빠른데, Subscriber의 데이터 처리가 늦을 경우도 마찬가지다.
Reactor에서는 Scheduler를 스레드 개념의 오퍼레이터를 활용해 이부분을 해결한다.
여기에서는 이 개념을 직접 구현한 코드를 보겠다.
아래 기본적인 Publisher와 Subscriber가 있다.

public class App {

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

    public static void main(String[] args) {
        Publisher<Integer> pub = (sub) -> {
            sub.onSubscribe(new Subscription() {
                @Override
                public void request(long n) {
                    for (long i = 0; i < n; i++) {
                        Integer data = fetchData(); // 이 작업이 아주 오래걸리는 작업일 경우
                        sub.onNext(data);
                    }
                    sub.onComplete();
                }

                @Override
                public void cancel() {
                }
            });
        };

        pub.subscribe(new Subscriber<>() {
            @Override
            public void onSubscribe(Subscription s) {
                log.debug("onSubscribe");
                s.request(Long.MAX_VALUE);
            }

            @Override
            public void onNext(Integer i) {
                log.debug("onNext: {}", i);
            }

            @Override
            public void onError(Throwable t) {
                log.debug("onError: {}", t);
            }

            @Override
            public void onComplete() {
                log.debug("onComplete");
            }
        });

        log.info("exit");
    }

}

이 코드를 실행하면 subscribe 후 모든 일이 main 스레드에서 실행되기 때문에 subscribe -> onSubscribe -> onNext* -> onComplete 후 "exit" 로그가 찍힌다.
Publisher에서 데이터를 가져오는 fetchData() 메소드가 오래걸리기때문에 이 작업을 전부 다할때까지 기다려야한다.
보통은 이러한 작업은 백그라운드로 실행되어야 메인 프로그램 실행 흐름에 영향을 미치지 않고 처리할 수 있기 때문에 스레드를 활용한다.
여기 Publisher에 subscribe를 스레드에서 실행하는 오퍼레이터를 심은 Publisher를 만들어보면 아래와 같이 구현할 수 있다.

Publisher<Integer> pub = normalPub();

Publisher<Integer> subOnPub = (sub) -> {
    // 별도 스레드를 생성하여 원래 처리할 publisher에게 subscriber 위임
    ExecutorService es = Executors.newSingleThreadExecutor();
    es.execute(() -> {
        pub.subscribe(sub);
    });
};

subOnPub.subscribe(subscriber());

이렇게 되면 메인 스레드와 별도의 스레드에서 기능이 실행되며 이후 프로그램 실행에는 영향을 주지 않게된다.
Reactor에서는 이를 subscribeOn 메소드로 해결한다.
반대로 Subscriber에서 데이터를 처리하는게 오래걸리는 경우도 있다.

Publisher<Integer> pubOnSub = sub -> {
    pub.subscribe(new Subscriber<Integer>() {
        ExecutorService es = Executors.newSingleThreadExecutor();

        @Override
        public void onSubscribe(Subscription s) {
            sub.onSubscribe(s);
        }

        @Override
        public void onNext(Integer integer) {
            es.execute(() -> {
                sub.onNext(integer);
            });
        }

        @Override
        public void onError(Throwable t) {
            es.execute(() -> {
                sub.onError(t);
            });
        }

        @Override
        public void onComplete() {
            es.execute(() -> {
                sub.onComplete();
            });
        }
    });
};

위와 같이 Subscribe를 중개하면서 각 작업을 스레드에서 실행되게 wrapping하면 무거운 작업을 별도 스레드에서 처리할 수 있다.
Reactor에서는 이를 publishOn이라는 메소드로

2. Reactor publishOn, subscribeOn

기본적으로 Reactor는 비동기를 강제하지는 않는다. (별도 스레드로 실행되는게 기본이 아니라는 뜻)
위에서 얘기한 내용 토대로 실제 Reactor에서 어떠한 식으로 구현했고 사용했는지 보자.
publishOn 오퍼레이터는 데이터를 소비(consume)하는게 느릴 경우 사용한다.
Subscriber쪽 코드가 별도 스레드에서 실행된다.

Flux.range(1, 10)
    .publishOn(Schedulers.newSingle("pub"))
    .subscribe(data -> log.info("{}", data))
;

subscribeOn은 데이터 생성 로직이 느릴 경우 사용한다.
Publisher쪽 코드가 별도 스레드에서 실행된다.

Flux.range(1, 10)
  .subscribeOn(Schedulers.newSingle("sub"))
  .subscribe(data -> log.info("{}", data))
;

혹은 아래와 같이 동시에 사용해도 문제없다.

Flux.range(1, 10)
    .publishOn(Schedulers.newSingle("pub"))
    .subscribeOn(Schedulers.newSingle("sub"))
    .subscribe(data -> log.info("{}", data))
;

3. 기본적으로 별도 스레드를 사용하는 Operators

위에서 말했든 Reactor는 일반적으로 비동기를 강제하지 않는다.
하지만 몇몇 Operators는 기본적으로 비동기로 동작하는 Operator들이 있다.
아래 예시코드를 보자

Flux.intervel(Duration.ofMillis(200))   // 200ms 간격(interval)으로 데이터를 생성
    .take(5)                            // 최대 5개까지만 데이터를 수용함
    .subscribe(e -> log.info("{}", e)); // 데이터를 수신하면 로그를 출력함

이 코드를 pure reactive streams 로 구현해보면 아래와 같이 구현할 수 있다.

// 일정 주기로 데이터를 발행하는 퍼블리셔
Publisher<Integer> pub = (sub) -> {
    sub.onSubscribe(new Subscription() {
        int value = 0;
        boolean cancelled = false;

        @Override
        public void request(long max) {
            // 아래 Executor는 일정 주기로 동작하는 작업를 구현할 때 용이함
            ScheduledExecutorService exec = Executors.newSingleThreadScheduledExecutor();

            // 초기 딜레이 0, 작업간 딜레이 200ms 간격으로 스케쥴링
            exec.scheduleAtFixedRate(() -> {
                // 작업이 종료되었으면 (cancel이 호출된 경우) 스케쥴링 종료
                if (cancelled) {
                    exec.shutdown();                    
                    return;
                }
                // 데이터 발생
                sub.onNext(value++);
            }, 0, 200, TimeUnit.MILLISECONDS);
        }

        @Override
        public void cancel() {
            this.cancelled = true;
        }
    });
};

// 일정 갯수가 발행되면 발행을 중단시키는 퍼블리셔
// 내부적으로 기존 subscriber를 사용하되 일정 갯수가 되면 cancel을 날리는 Subscriber를 새로 생성
Publiser<Integer> takePub = (sub) -> {
    pub.subscribe(new Subscriber() {
        int count = 0;
        Subscription s;

        @Override
        public void onSubscribe(Subscription s) {
            sub.onSubscribe(s);
            this.s = s;
        }

        @Override
        public void onNext(Integer integer) {            
            // 기존 Subscriber로 처리 위임 후 카운트 증가
            sub.onNext(integer);
            count++;

            // 정해진 횟수를 넘어서면 cancel 호출
            if (count >= 5) {
                s.cancel();
            }
        }

        @Override
        public void onError(Throwable t) {
            sub.onError(t);
        }

        @Override
        public void onComplete() {
            sub.onComplete();
        }
    });
};

Subscriber<Integer> logSub = new Subscriber<>() {
    @Override
    public void onSubscribe(Subscription s) {
        log.info("onSubscribe");
        s.request(Long.MAX_VALUE);
    }

    @Override
    public void onNext(Integer integer) {
        log.info("onNext: {}", integer);
    }

    @Override
    public void onError(Throwable t) {
        log.info("onError: {}", t);
    }

    @Override
    public void onComplete() {
        log.info("onComplete");
    }
};

takePub.subscribe(logSub);

리액티브 프로그래밍 시리즈 2 - Operators와 Reactor 맛보기

@deveely — Sat, 21 Aug 2021 02:21:30 +0900

이 포스트 시리즈는 Reactive Programming은 토비의 스프링 저자 이일민님의 리액티브 프로그래밍 유튜브 강좌를 공부하며 정리한 내용입니다.

0. Tips

Stream 인터페이스에 iterate 라는 메소드가 있다.
이 메소드는 어떠한 데이터 스트림을 쉽게 만들어 낼 수 있는 메소드이다.

public List<Integer> createSampleIntegerList(int count) {
    return Stream.iterate(1, e -> e + 1).limit(count).collect(Collectors.toList());
}

위 코드는 1 ~ 10까지 정수를 담은 리스트를 만든다.
핵심은 iterate(시작값, 값의 변화 함수) 메소드인데, 위 예시에서 시작값은 1, 변화는 1씩 증가시킨다라는 뜻이다.
그리고 limit(10)을 통해 10개만이라는 제한을 걸어주었다. (걸지 않으면 무한하게 증가하기 때문에 collect를 할 수 없다.)

종종 활용할 곳이 있을것 같아 기록해둔다.

1. Operators 직접 구현해보기

Reactive Streams의 핵심 개념은 Publisher -> Data -> Subscriber의 흐름으로 데이터가 전달된다는 것이다.
아래에서 <- 방향으로의 흐름을 업스트림(Upstream)이라 하고 -> 방향으로의 흐름을 다운스트림(Downstream)이라 한다.
그리고 데이터는 업스트림에서 다운스트림 방향으로 (->) 흘러간다.

Publisher -> Data -> Subscriber
                <- subscribe(Subscriber)
                -> onSubscribe(Subscription)
                -> onNext
                -> onNext
                -> ...
                -> onComplete

Reactive Streams에서는 이 과정에서 Publisher -> [Data1] -> Operator -> [Data2] -> Operator2 -> [Data3] -> Subscriber 이런식으로 데이터를 가공하는 Operator를 적용할 수 있다.
아래와 같은 Publisher와 Subscriber가 있다고 해보자. 1부터 10까지 정수 데이터가 발생하고, Subscriber는 화면에 출력하고 프로그램은 종료된다.

public class PubSub {

    public static void main(String[] args) {
        Publisher<Integer> pub = iterPub(Stream.iterate(1, e -> e + 1).limit(10).collect(Collectors.toList()));
        pub.subscribe(logSub());
    }

    /**
     * Iterator의 데이터를 발생시키는 Publisher 
     * @param iter 데이터 소스
     * @return Publisher
     */
    private static Publisher<Integer> iterPub(Iterable<Integer> iter) {
        return new Publisher<>() {
            @Override
            public void subscribe(Subscriber<? super Integer> subscriber) {
                subscriber.onSubscribe(new Subscription() {
                    @Override
                    public void request(long n) {
                        // 이 예시 코드에선 Subscriber의 요청갯수인 'n' 인자에 대한 구현은 안되어있다.
                        try {
                            iter.forEach(subscriber::onNext);
                            subscriber.onComplete();
                        } catch (Exception e) {
                            subscriber.onError(e);
                        }
                    }

                    @Override
                    public void cancel() {
                        // Subscriber가 어떠한 경우로든 Publisher에게 데이터를 그만보내라고 요청하는것
                        // 그에 대비해 Publisher는 이 메소드안에 적절한 내용을 구현해두어야함
                        // 일반적으로 flag를 두고 request쪽에서 데이터를 더 보내지 않도록 함
                    }
                });
            }
        };
    }

    /**
     * Publisher에서 수신한 데이터를 출력하는 Subscriber
     * @return Subscriber
     */
    private static Subscriber<Integer> logSub() {
        return new Subscriber<>() {
            @Override
            public void onSubscribe(Subscription subscription) {
                System.out.println("onSubscribe");
                subscription.request(Long.MAX_VALUE);
            }

            @Override
            public void onNext(Integer integer) {
                System.out.println("onNext: " + integer);
            }

            @Override
            public void onError(Throwable throwable) {
                System.out.println("onError: " + throwable);
            }

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

}

여기에서, 데이터를 변환하는 과정을 넣어본다면 아래와 같이 구현할 수 있다.
마치 기존 Publisher를 한 겹 감싸고, 데이터를 전달하는 부분인 onNext 메소드에 특정 작업을 심은 새로운 Publisher를 생성하는 것이다.
아래 mapPub 함수에서 스트림의 흐름을 이해하기 쉽게 방향과 대조해보면
- 인자로 전달된 publisher: 업스트림 (현재 스트림보다 상위에 있는 스트림)
- 새로 생성되어 return되는 Publisher: 중개 스트림 (현재 스트림)
  - 이 안에서 구현하는 subscribe함수에 인자로 전달되는 subscriber: 다운스트림 (현재 스트림보다 하위에 있는 스트림)
- publisher.subscribe 안에 새로 생성하는 Subscriber: 중개 스트림 (현재 스트림)
업스트림 -> 다운스트림으로의 흐름에 무언가 중개하는 새로운 흐름이 끼어든 것이다.

public class PubSub {

    public static void main(String[] args) {
        Publisher<Integer> pub = iterPub(Stream.iterate(1, e -> e + 1).limit(10).collect(Collectors.toList()));
        Publisher<Integer> mapPub = mapPub(pub, e -> e * 10); // 기존 값에 10을 곱하는 함수 전달
        mapPub.subscribe(logSub());
    }

    private static Publisher<Integer> mapPub(Publisher<Integer> publisher, Function<Integer, Integer> mappingFunc) {
        return new Publisher<Integer>() {
            @Override
            public void subscribe(Subscriber<? super Integer> subscriber) {
                // 인자로 전달된 기존 publisher.subscribe의 인자에 새 Subscriber를 생성하여 넘겨준다.
                // 이 때, 새 Subscriber에 기존 Subscriber의 기능들을 연결시키고, onNext에 데이터를 가공하는 기능만 부가적으로 추가해준다.
                publisher.subscribe(new Subscriber<>() {
                    @Override
                    public void onSubscribe(Subscription subscription) {
                        subscriber.onSubscribe(subscription);
                    }

                    @Override
                    public void onNext(Integer integer) {
                        // 이전 퍼블리셔에서 발생된 데이터에 'mappingFunc' 적용하여 전달
                        subscriber.onNext(mappingFunc.apply(integer));
                    }

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

                    @Override
                    public void onComplete() {
                        subscriber.onComplete();
                    }
                });
            }
        };
    }
}

만약 기존 스트림(Publisher) 내 모든 값을 합한 값을 발생시키는 Publisher를 구현한다면 아래와 같이 할 수 있다.

public class PubSub {

    public static void main(String[] args) {
        Publisher<Integer> pub = iterPub(Stream.iterate(1, e -> e + 1).limit(10).collect(Collectors.toList()));
        Publisher<Integer> sumPub = sumPub(pub);
        sumPub.subscribe(logSub());
    }

    private static Publisher<Integer> sumPub(Publisher<Integer> publisher, Function<Integer, Integer> mappingFunc) {
        return new Publisher<Integer>() {
            @Override
            public void subscribe(Subscriber<? super Integer> subscriber) {
                publisher.subscribe(new Subscriber<>() {
                    // 업스트림에서 전달되는 값을 합해둘 멤버변수 선언
                    private int sum = 0;

                    @Override
                    public void onSubscribe(Subscription subscription) {
                        subscriber.onSubscribe(subscription);
                    }

                    @Override
                    public void onNext(Integer integer) {
                        // 업스트림에서 데이터가 전달되면 바로 전달하지 않고 값을 더해둠
                        this.sum += integer;
                    }

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

                    @Override
                    public void onComplete() {
                        // 업스트림에서 데이터 전달이 끝나면 더해둔 값을 다운스트림으로 보냄
                        subscriber.onNext(sum);
                        // 그리고 현재 스트림은 끝났음을 통지
                        subscriber.onComplete();
                    }
                });
            }
        };
    }
}

만약 mapPub 메소드에 제네릭을 적용하면 아래와 같이 작성할 수 있다.
T타입 데이터 흐름을 R타입 데이터 흐름으로 변경한다.

private static <T, R> Publisher<R> mapPub(Publisher<T> publisher, Function<T, R> mappingFunc) {
    return new Publisher<R>() {
        @Override
        public void subscribe(Subscriber<? super R> subscriber) {
            publisher.subscribe(new Subscriber<T>() {
                @Override
                public void onSubscribe(Subscription subscription) {
                    subscriber.onSubscribe(subscription);
                }

                @Override
                public void onNext(T integer) {
                    subscriber.onNext(mappingFunc.apply(integer));
                }

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

                @Override
                public void onComplete() {
                    subscriber.onComplete();
                }
            });
        }
    };
}

2. Reactor 맛보기

Reactor는 reactive streams 구현체중 하나로 Spring Webflux 엔진으로도 사용된다.
Reactive Streams 표준을 아주 쉽게 다룰수 있게 해두었다.

디펜던시

implementation 'io.projectreactor:reactor-core:3.4.9'

Reactor를 사용한 심플한 예제를 하나 보자
Flux는 Publisher의 구현체 중 하나이다. (데이터를 생성하는 역할이라는 뜻)
create 메소드엔 데이터 생성하는 로직이 들어가는데, next, complete 등 마치 Publisher 의 subscribe 메소드를 구현할 때 하는 작업을 편리하게 할 수 있다.
map 메소드와 같이 생성 -> 구독 사이에 여러 Operators를 체이닝 방식으로 쉽게 걸어줄 수 있다.
위에 Publisher, Subscriber 직접 생성하고 연결하는 코드들은 모두 내부에 감춰져있고 아래와 같은 간단한 코드로 하나의 흐름을 만들수있다.
```
Flux.<Integer>create(e -> {
  e.next(1);
  e.next(2);
  e.next(3);
  e.complete();
})
.map(e -> e * 10)
.reduce(0, (a, b) -> a + b)        
.subscribe(s -> System.out.println(s));
```

리액티브 프로그래밍 시리즈 1 - Reactive Streams 개요

@deveely — Tue, 17 Aug 2021 01:07:13 +0900

이 포스트 시리즈는 Reactive Programming은 토비의 스프링 저자 이일민님의 리액티브 프로그래밍 유튜브 강좌를 공부하며 정리한 내용입니다.

1. Iterable과 Observable의 차이점

Iterable과 Observable은 정반대의 동작방식으로 같은 목적의 문제를 해결한다.

1.1. Iterable 개념

자바에서 연속적인 데이터 구조를 표현할 때 List를 주로 사용한다.
그리고 주로 아래와 같이 for-each 구문을 사용한다.

import java.util.List;
import java.util.Arrays;

List<Integer> list = Arrays.asList(1, 2, 3, 4, 5);
for (Integer i : list) {
  System.out.println(i);
}

이는 List 인터페이스가 Iterable 인터페이스를 상속받고 있기 때문이다.
자바에서 Iterable 인터페이스를 구현한 타입은 for-each 루프 사용이 가능하다.

Iterable 인터페이스는 데이터를 꺼내올 수 있는 iterator()를 생성하도록 하는 메소드가 있다.
Iterator는 next() 메소드를 통해 데이터를 제공하고 hasNext() 메소드를 통해 데이터가 더 남아있는지 여부를 반환한다.
즉 Iterable > Iterator > Iterator.next() 순으로 데이터를 가져오는 것이다.

1.2. Observable 개념

참고 Java9에서 deprecate 됨

Observable: 데이터를 만들어내는 Source, Event를 발생하여 Observer에게 전달, 옵저버는 여려개가 될 수 있음
Observer: Observable에서 발생하는 이벤트를 수신하여 동작하는 오브젝트

import java.util.Observable;
import java.util.Observer;

class IntObservable extends Observable implements Runnable {
  @Override
    public void run() {
      for (int i = 0; i < 10; i++) {
        // Observable에 변화가 생겼음을 알리는 메소드
        setChanged();
        // Observer들에게 변화를 알림 (값 포함)
        notifyObservers(i);
      }
    }
}

class Program {
  public static void main(String[] args) {
    Observer observer = new Observer() {
      @Override
      public void update(Observable observable, Object o) {
        // 옵저버의 변화로 이벤트가 발생하면 아래 로직 수행
        System.out.println(o);
      }
    };
  }
}

1.3. Iterable VS Observable

데이터를 전달하고 전달받는 방식이 정반대이다. (쌍대성, duality)

Iterable은 Pull이다
- Iterator.next()를 통해 데이터를 지속적으로 당겨옴 (pull)
- next() 메소드는 리턴값이 있음
Observable은 Push다
- Observable.notifyObservers(Object)를 통해 데이터를 밀어줌 (push)
- notifyObservers 메소드는 리턴값이 없음

1.4. Observable의 문제점

끝났다 라는 개념이 없다. (Complete)
- 사용할 때 직접 이 개념을 정해놓고 써야했다.
에러 처리에 대한 방식이 없다.
- 복구 가능한 예외, 복구 불가능한 예외 등 여러 예외상황에 대한 처리 방식을 제공하지 않는다.

2. Reactive Streams의 표준

https://www.reactive-streams.org/

정식(?)은 아닌것 같지만 리액티브 프로그래밍의 대략적인 표준을 제시하고 있다.
Java9 부터 java.util.concurrent.Flow 에 포함되어 있으며, 하위 버전에서는 디펜던시를 추가하여 사용할 수 있다.
Processor, Publiser, Subscriber, Subscription 4가지 간단한 API 가 있고,
이를 reactive streams에서 제시하는 스펙 을 준수하여 구현하면 된다.
이렇게 구현된 리액티브 엔진이 ReactiveX (RxJava), Reactor 등이 있다.

2.1. Publisher / Subscriber 간단 스펙

옵저버 패턴의 Observable 역할
일련의 시퀀스를 가진 요소를 제공해야한다.
Publisher.subscribe(Subscriber)를 통해 등록
아래 프로토콜을 따라야한다.
```
onSubscribe onNext* (onError | onComplete)?
onSubscribe는 subscribe 될 시 반드시 1번 호출되야함
onNext 0 ~ 무한대
onError, onComplete 0~1번 (optional)
- onError 호출 시 onComplete 호출불가
- onComplete 호출 시 onError 호출불가

2.2. 간단한 Publisher & Subscriber

아래 리액티브 프로그래밍의 동작원리를 간단하게 구현한 코드이다.
Publisher와 Subscriber 스펙을 모두 구현한 것은 아니지만 기본적인 동작방식은 표현되어있다.
옵저버 패턴과 유사하다

import java.util.Arrays;
import java.util.concurrent.Flow.Subscriber;
import java.util.concurrent.Flow.Publisher;
import java.util.concurrent.Flow.Subscription;

public class IntPublisher implements Publisher<Integer> {

  private Iterator<Integer> datasource;

  public IntPublisher() {
      this.datasource = Arrays.asList(1, 2, 3, 4, 5).iterator();
  }

  @Override
  public void subscribe(Subscriber<? super Integer> subscriber) {
      Subscription subscription = new Subscription() {
          @Override
          public void request(long n) {
              try {
                  while (n-- < 0) {
                    if (datasource.hasNext()) {
                        // 데이터가 있을 경우 onNext 호출
                        subscriber.onNext(datasource.next());
                    } else {
                        // 데이터가 더이상 없을 경우 onComplete 호출
                        subscriber.onComplete();
                        break;
                    }
                }
              } catch (Exception e) {
                  // 예외 발생 시 onError 호출
                  subscriber.onError(e);
              }
          }
      };
      subscriber.onSubscribe(subscription);
  }
  
  @Override
  public void cancel() {
  }
}

public class IntSubscriber implements Subscriber<Integer> {
    private Subscription subscription;
    
    @Override
    public void onSubscribe(Subscription subscription) {
        System.out.println("onSubscribe");
    	  this.subscription = subscription;
    	  // subscribe 완료 후 데이터 1개 요청
        subscription.request(1);
    }

    @Override
    public void onNext(Integer integer) {
        // 데이터 1개 받은 후 1개 요청
        System.out.println("onNext " + integer);
        this.subscription.request(1);
    }

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

    @Override
    public void onError(Throwable throwable) {
        System.out.println("onError " + throwable.getMessage());
    }
}

Spring Cloud Gateway 기본 활용법

@deveely — Mon, 9 Aug 2021 23:44:13 +0900

0. Spring Cloud Gateway 란?

Netflix OSS의 API Gateway 컴포넌트인 Zuul을 Spring 진영에서 직접 만든 API Gateway 입니다.
Zuul은 기본적으로 블록킹 방식으로 동작했었는데요. (Zuul 1.x) 이를 개선하기 위해 Zuul 2.x에서 논블록킹 방식을 도입했습니다.

Spring 진영에서는 Zuul의 동기방식이었던 단점을 보완하며 Spring 생태계에 더 적합한 형태의 비동기 API Gateway를 만든것이 바로 Spring Cloud Gateway 입니다.

This project provides an API Gateway built on top of the Spring Ecosystem, including: Spring 5, Spring Boot 2 and Project Reactor. Spring Cloud Gateway aims to provide a simple, yet effective way to route to APIs and provide cross cutting concerns to them such as: security, monitoring/metrics, and resiliency.

Spring Boot 2.4.x 이상부터 Zuul을 사용할 수 없습니다.
spring-webmvc 위에서 동작하던 Zuul과 달리 Spring Cloud Gateway는 spring-webflux + Reactor 기반으로 동작합니다.
- 때문에 spring-webmvc, spring-data, spring-security 등 동기방식 기반 프로젝트들과 함께 실행하면 문제가 발생할 수 있습니다.

1. Spring Cloud Gateway 의존성 추가

build.gradle

plugins {
  id 'org.springframework.boot' version '2.5.2'
  id 'io.spring.dependency-management' version '1.0.11.RELEASE'
  id 'java'
}
group = 'com.sample.project'
version = '0.0.1-SNAPSHOT'
sourceCompatibility = '11'
repositories {
    mavenCentral()
}

dependencyManagement {
    imports {
        mavenBom "org.springframework.cloud:spring-cloud-dependencies:2020.0.3"
    }
}

dependencies {
    implementation 'org.springframework.cloud:spring-cloud-starter-gateway'
    testImplementation 'org.springframework.boot:spring-boot-starter-test'
}

2. 라우팅 설정 추가

application.yml
기본적으로 라우팅 정보, 라우팅 대상 지정 (predicates), 라우팅 시 동작 추가 (filters)를 할 수 있습니다.
- predicates를 통해 게이트웨이로 들어온 요청 중 어떤 요청들을 해당 라우트에서 처리할 지 조건을 기술합니다.
  - 시간, 쿠키, 헤더, 호스트, 메소드, 쿼리 스트링 등 사용할 수 있는 조건이 다양합니다.
  - https://cloud.spring.io/spring-cloud-gateway/reference/html/#gateway-request-predicates-factories
- filters를 통해 게이트웨이로 들어온 요청이 해당 라우트를 거치며 수행될 추가 동작들을 선언할 수 있습니다.
  - 헤더 추가, 쿼리 스트링 추가, MSA 환경의 경우 써킷 브레이커 추가, Path 재설정 등등 다양합니다.
  - https://cloud.spring.io/spring-cloud-gateway/reference/html/#gatewayfilter-factories
아래 설정은 게이트웨이로 들어오는 요청을 아래와 같이 처리합니다.
- `/api/monitoring` 로 시작하는 요청만을 대상으로 하며
- Path를 `/api/monitoring/*` => `/monitor/*`로 변경하여
- uri에 설정된 서버로 라우팅


spring:
  cloud:
    gateway:
      routes:
        - id: 서비스 아이디
          uri: 라우팅할 서비스 URI
          predicates:
            - Path=/api/monitoring/**
          filters:
            - RewritePath=/api/monitoring, /monitor

Java에서 파일의 Mime type을 판별하는 방법

@deveely — Wed, 4 Nov 2020 21:36:40 +0900

얼마전, 로컬 파일 시스템에 저장되어 있는 파일을 바이너리 형태로 내려주는 REST API를 작성할 일이 있었습니다.
파일을 내려줄 때 Content-Type 헤더에 Mime Type을 알맞게 지정해줘야 하는데요. 찾아보니 다음과 같은 방법으로 할 수 있었습니다.

Path filePath = Paths.get("file/save/path");
String fileContentType = Files.probeContentType(path);

시스템에 따라 파일 타입을 감지하지 못하는 경우도 있는데요. 제 경우엔 Mac OSX에서 파일 타입을 감지하지 못하는 경우가 있었습니다.
때문에 알아보니 URLConnection을 이용하는 방법도 있었습니다.

URLConnection.guessContentTypeFromName("file/save/path");

위 2가지 방법에 기반하여 아래와 같이 유틸 메소드를 작성했습니다.

/**
 * 파일 Mime Type 탐지
 * @param filePath 파일 저장 경로
 * @return 파일 Mime Type
 */
public String detectFileMimeType(String filePath) {
  Path path = Paths.get(filePath);
  String detectedMimeType = null;
  try {
    detectedMimeType = Files.probeContentType(path);
  } catch (IOException e) {
    // ignore
  }
  return detectedMimeType != null ? detectedMimeType : URLConnection.guessContentTypeFromName(filePath);
}

상황에 맞춰 사용하면 될 것 같습니다.

Spring Boot Redis Connection Pool + Cluster 설정

@deveely — Tue, 21 Jul 2020 06:52:26 +0900

Spring Boot에서 Redis Cluster에 접속하는 방법을 정리한다.

Spring Boot 설정

spring:
    redis:
        cluster:
            nodes:
                1.1.1.1:1234
                1.1.1.2:1234
                1.1.1.3:1234

@Configuration
public class RedisConfiguration {

    @Value("${spring.redis.cluster.nodes}")
    private String[] clusterNodes;

    /**
     * Jedis Connection Pool
     */
    @Bean
    public JedisPoolConfig jedisPoolConfig() {
        return new JedisPoolConfig();
    }

    /**
     * Redis Connection Factory (커넥션풀링 + 클러스터링)
     */
    @Bean
    public RedisConnectionFactory redisConnectionFactory(JedisPoolConfig jedisPoolConfig) {
        RedisClusterConfiguration redisClusterConfigurations = new RedisClusterConfiguration(clusterNodes);
        return new JedisConnectionFactory(redisClusterConfigurations, jedisPoolConfig);
    }

    /**
     * 어플리케이션에서 사용할 RedisTemplate 설정
     */
    @Bean
    public RedisTemplate<String, Object> redisTemplate(RedisConnectionFactory redisConnectionFactory) {
        RedisTemplate<String, Object> redisTemplate = new RedisTemplate<>();
        redisTemplate.setConnectionFactory(redisConnectionFactory);
        redisTemplate.setDefaultSerializer(new StringRedisSerializer());
        return redisTemplate;
    }

    public StringRedisTemplate stringRedisTemplate(RedisConnectionFactory redisConnectionFactory) {
        return new StringRedisTemplate(redisConnectionFactory);
    }
}

이 후 사용은 보통 RedisTemplate 혹은 Repository 사용하듯이 사용하면 된다.

참고 (Redis 클러스터 모드로 접속)

-c 옵션으로 클러스터 모드로 접속

redis-cli -c -h 1.2.3.4 -p 1234

Spring Boot에서 Redis 활용

@deveely — Mon, 20 Jul 2020 16:19:09 +0900

설정

의존성 추가

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

설정 클래스 작성
아래와 같이 설정하면 default 설정에 의해 localhost:6379 로 연결합니다.
변경하려면 설정파일에 spring.redis.host, spring.redis.port로 지정할 수 있습니다.
Key / Value Serializer를 설정해주는 이유는 RedisTemplate에서 Spring ~ Redis간 데이터 직, 역직렬화 시 사용하는 방식이 Jdk 직렬화 방식이기 때문입니다. 동작에는 문제가 없지만 redis-cli를 통해 직접 데이터를 보려고 할 때 알아볼수 없는 형태로 출력되기 때문에 Serializer를 변경해준 것입니다. 참고 링크

한글의 경우 이 설정으로도 깨질수가 있는데, cli 접속 시 redis-cli --raw 이렇게 옵션을 주고 접속하면 정상적으로 볼 수 있습니다.

@Configuration
public class RedisConfiguration {

    @Bean
    public RedisConnectionFactory redisConnectionFactory() {
        // 사용하는 Redis Client 팩토리 지정
        // Pool 사용 시 이곳에서 설정 가능
        return new JedisConnectionFactory(); 
    }

    @Bean
    public RedisTemplate<String, Object> redisTemplate() {
        RedisTemplate<String, Object> redisTemplate = new RedisTemplate<>();
        redisTemplate.setConnectionFactory(redisConnectionFactory());
        redisTemplate.setKeySerializer(new StringRedisSerializer());
        redisTemplate.setValueSerializer(new StringRedisSerializer());
        // Hash Operation 사용 시
        redisTemplate.setHashKeySerializer(new StringRedisSerializer());
        redisTemplate.setHashValueSerializer(new StringRedisSerializer());

        // 혹은 아래 설정으로 모든 Key / Value Serialization을 변경할 수 있음
        redisTemplate.setDefaultSerializer(new StringRedisSerializer());

        return redisTemplate;
    }
}

사용

1. RedisTemplate 사용한 방법

@Service
public RedisTestService {

    // 기본 
    @Autowired
    private RedisTemplate<String, Object> redisTemplate;

    /**
     * String Operation의 set 커맨드
     * @param key Redis Key
     * @param value key에 저장될 value
     */
    public void setStringValue(String key, String value) {
        redisTemplate.opsForValue().set(key, value);
    }

    /**
     * String Operation의 get 커맨드
     * @param key Redis Key
     * @param value key에 저장될 value
     */
    public String getStringValue(String key) {
        return (String) redisTemplate.opsForValue().get(key);
    } 
}

RedisTemplate의 opsFor* 메소드들은 특정 컬렉션의 커맨드(Operation)을 호출할 수 있는 기능을 모아둔
*Operations 인터페이스를 반환합니다.

메소드명	반환 오퍼레이션	관련 Redis 자료구조
opsForValue()	ValueOperations	String
opsForList()	ListOperations	List
opsForSet()	ListOperations	List
opsForList()	SetOperations	Set
opsForZSet()	ZSetOperations	Sorted Set
opsForHash()	HashOperations	Hash

여기서 이 *Operations는 아래와 같은 방식으로도 주입받을 수 있습니다.
이런 경우 프레임워크에서 자동으로 판단하여 주입해준다고 합니다.

For cases where a certain template view is needed, declare the view as a dependency and inject the template: the container will automatically perform the conversion eliminating the opsFor[X] calls:

@Service
public RedisTestService {

    // 기본 
    @Autowired
    private RedisTemplate<String, Object> redisTemplate;

    // 특정 오퍼레이션 직접 주입
    @Resource(name ="redisTemplate")
    private ValueOperations<String, Object> valueOps;
}

또한, Key Bound Operation을 제공하는데, 이건 특정 Redis Key 한정으로 오퍼레이션을 수행할 수 있는 인터페이스입니다. 즉, redisTemplate.opsForValue().set("key~~", "string value") 이렇게 할 것을 redisTemplate.boundValueOps("key~~").set("string value") 이렇게 할 수 있습니다.

추가로, StringRedisTemplate 라는 구현체도 있습니다.
Serializer가 String으로 설정되어있는 RedisTemplate<String, String>입니다.

이렇게 여러가지 방식이 있으니 필요에 따라서 사용하면 좋을듯 합니다.

2. Spring Data CrudRepository 를 통한 방법

JPA 사용해 RDB와 통신할 때 org.springframework.data.repository 밑에 있는 Repository 인터페이스를 상속받으면 findAll, findById, save 등 자동으로 여러 기능들을 바로 사용할 수 있듯이 Redis 또한 이 방식을 사용할 수 있습니다. (Redis의 Hash 자료구조 한정)

엔티티(모델) 클래스 작성

@RedisHash 어노테이션의 "testModel" 을 Redis 키 prefix로 사용합니다.
@Id는 JPA와 동일한 역할을 수행합니다. "testModel:{id}" 의 id 위치에 자동 generate 값이 들어갑니다.
@RedisHash("testModels") public class TestModel { @Id private Long id; private String name; private int age; // getter, setters, ... }

Repository 작성
public interface TestModelRedisRepository extends CrudRepository<TestModel, Long> { }
사용
간단합니다. JPA에서 save를 호출하면 insert 문이 호출되듯, hmset, hset 등이 자동으로 호출됩니다.
@Service public class RedisTestService { @Autowired private TestModelRedisRepository testModelRedisRepository; public void addModel(String name, int age) { TestModel testModel = createModel(name, age); testModelRedisRepository.save(testModel); }

}

redis-cli에서 `keys *`로 확인해보면 추가된 것이 확인됩니다.

> keys *
$ testModels
$ testModels:1564644222311766174

`hgetall testModels:1564644222311766174`로 값이 잘 들어갔는지 확인해보면

_class
com.testprj.entity.redis.TestModel
id
1564644222311766174
name
이현규
age._class
java.lang.Integer
age
99

위와같이 우리가 저장하고자 하는 실제 필드 (id, name, age)와 Java Type (Redis - Spring Boot간 매핑에 사용되는 듯한)이 저장되있음을 확인할 수 있습니다.

이외에 findOne, findAll 또한 모두 잘 동작합니다.

참고

https://stackoverflow.com/questions/31608394/get-set-value-from-redis-using-redistemplate
https://yookeun.github.io/java/2017/05/21/spring-redis/

Redis 개념과 설치, 활용방안

@deveely — Fri, 17 Jul 2020 15:13:32 +0900

Redis란?

Redis는 REmote Dictionary Server의 약자로 "key-value" 기반 인메모리비 관계형 데이터 베이스다.
모든 데이터를 메모리에 저장하고 조회하기 때문에 빠른 Read, Write 속도를 보장한다.
다양한 value에 다양한 자료구조를 지원해 사용자 애플리케이션 개발 시 활용도가 높다.

Redis vs Memcached

Redis를 검색해보면 개념 설명과 함께 Memcached와의 비교글을 많이 볼 수 있다.
Memcached는 메모리 기반이라 처리속도가 빠르고 데이터에 만료 시간을 지정할 수 있고, 저장소 공간이 없으면 LRU 알고리즘에 의해
삭제되는 특징이 있어, 대형 포털에서 Static Page나 검색 결과 등 캐싱 용도로 많이 사용된다.
다만 프로세스가 죽거나 장비가 shutdown되면
저장된 데이터가 사라지기 때문에 중요 데이터를 저장하면 안된다.

Redis는 메모리 기반 빠른 처리 속도 등의 Memcached와 차이 없는 처리속도를 보장함과 동시에, 데이터를 디스크에도 저장해 영속화가 가능(데이터가 유실될 위험이 없음)하다.
또한 문자열만 저장할 수 있는 Memcached와 달리 List, Set, Sorted Set, Hash 등 여러 자료 구조를 지원한다는 장점이 있다.

Mac에 Redis 설치하기

Homebrew를 이용해 redis 서버 설치

brew install redis

Redis 자료구조와 커맨드

1. String

가장 간단한 자료 구조, 쉽게 생각하면 문자열에 다른 문자열을 매핑하는 것.
전체 커맨드: https://redis.io/commands#string

> set hello world
OK

> get hello
"world"

2. List

일반적인 연결 리스트의 특성을 갖고 있음.
LPUSH / LPOP / RPUSH / RPOP 등 명령어로 양 끝단 엘리먼트 조작을 빠르게 할 수 있고.
LSET / LINDEX 등 명령어로 특정 인덱스의 엘리먼트에 대한 조작도 할 수 있다.

Pub-Sub(생산자-소비자)와 잘 어울리는 자료구조. (생산자가 List에 PUSH하면 소비자가 POP)
Blocking 연산도 지원해 소비자가 POP 시도 시 List에 원소가 없으면 들어올 때 까지 대기하게 할 수도 있다.

전체 커맨드: https://redis.io/commands#list

3. Hash

Key하나에 여러 field-value 쌍을 저장할 수 있는 자료구조로 RDB의 테이블과 유사하며 비교해보면 아래와 같다.

RDB	Redis
PK	Key
Column	Hash Field
Value	Hash Value

즉 Redis Key하나 당 RDB Table의 row라고 생각하면 된다.

만약 아래와 같은 구조를 같는 User 테이블이 있다고하면

ID	Name	Age
1	Kim	29
2	Lee	28

이를 Redis Hash 구조에서는 아래와 같이 표현된다.
User-1 (HashKey)

Name	Kim
Age	29

User-2 (HashKey)

Name	Lee
Age	28

전체 커맨드: https://redis.io/commands#hash

4. Set

정렬되지 않는 문자열의 모음으로, Set인만큼 원소의 중복은 불가하다.
집합연산 (교집합, 합집합, 차집합) 연산을 지원하기 때문에 객체관의 관계를 표현하는데 용이하다.

예를들어 어떤 블로그 포스트에 연결된 태그 ID [1, 2, 3, 4, 5]를 저장해야하는 경우가 있다면

sadd post:1234:tags 1 2 3 4 5

smembers post:1234:tags

이렇게 추가할 수 있다. (참고로 Key "post:1234:tags"는 설계하기 나름이지만 여기서는 1234번 포스트의 태그라는 의미로 저렇게 부여함)

참고로 집합연산은 SINTER (교집합), SUNION (합집합), SDIFF (차집합) 커맨드로 수행할 수 있다.

전체 커맨드: https://redis.io/commands#set

5. Sorted Set

Set과 마찬가지로 Key하나에 중복되지않는 여러 엘리먼트를 저장할 수 있는 자료구조이다.
단, 원소 추가 시 score를 같이 입력해주고, 내부적으로 이 score를 기준으로 정렬을 유지시키는 특징을 갖고 있다.
ZRANGE (인덱스로 범위 검색), ZRANGEBYSCORE (스코어로 범위검색) 등 연산을 지원한다.

Redis 키 설계와 사용

Redis 키는 문자열이기 때문에 공백문자 ("")부터 JPEG 파일 등 이진형태로 표현되는 모든 값을 키로 사용할 수 있다. (최대 512MB)

키는 너무 길지 않게 설계하는 것을 권장(조회 성능때문), 너무 길어지면 차라리 Hash를 이용하는 것이 나을수도 있다.

키는 데이터 스키마를 기준으로 "object-type:id" 설계하는 것을 추천한다.

예를들면, "user:1234"라는 키는 User 타입의 ID가 1234인 오브젝트를 의미한다.

주로 사용하는 부호로는 :, ., -등이 있다.

예를들면 "post:123:comments"라는 키는 ID가 123인 포스트(post)의 댓글목록(comments)를 의미한다.

키 관련 대표적인 명령어

Command	Description
SORT	해당 키의 Value를 정렬해서 반환
EXISTS	해당 키가 존재하는지 여부 반환
DEL	해당 키를 삭제
TYPE	해당 키의 Value가 어떤 자료구조인지 반환

Redis와 Expire 기능

https://redis.io/commands/expire

Redis는 인메모리 DB인 만큼 저장할 수 있는 데이터량이 한정적.
메모리에 더 이상 저장할 수 없는 경우 가장 먼저 들어온 데이터를 삭제하거나 가장 오랫동안 사용하지 않은 데이터를 삭제. 혹은, 꽉 차서 더 이상 입력이 불가능해질수도 있음.

가장 좋은 방법은 삭제 / 만료를 직접 설정하는 것이다.
키에 timeout을 걸거나, 유닉스 타임스태프를 지정해 해당 시간에 자동으로 삭제되도록 할 수 있다. (DEL 명령어 사용과 같은 효과)

timeout의 경우 동일한 키의 변경이 있을 경우 갱신된다.
기본적으로 모든 데이터에 Expire 처리를 할 것을 권장하며, 너무 짧으면 레디스에 부하가, 너무 길면 의미가 없어지니 적절한 시간을 찾는것이 중요하다.

참고

https://medium.com/garimoo/개발자를-위한-레디스-튜토리얼-01-92aaa24ca8cc
https://redis.io/

[Cloud Series] 클라우드란? - 2

@deveely — Thu, 16 Jul 2020 23:20:43 +0900

클라우드의 정의와 특징

미국 국립 표준 기술연구소 NIST에서는 클라우드를 아래와 같이 정의하고 있습니다.

클라우드 컴퓨팅이란, 공유 구성이 가능한 컴퓨팅 리소스(네트워크, 서버, 스토리지, 애플리케이션 서비스)의 통합을 통해 어디서나 간편하게, 요청에 따라 네트워크를 통해 접근하는 것을 가능하게 하는 모델이다. 이는 최소한의 이용 절차 또는 서비스 공급자의 상호 작용을 통해, 신속히 할당되어 제공된다.

또한, 클라우드의 특징으로 아래 5가지를 들었습니다.

주문형 셀프 서비스 사업자와 직접 상호 작용하지 않고, 사용자의 개별 관리화면(콘솔 등)을 통해 서비스를 이용할 수 있다.
광범위한 네트워크 접속 모바일 기기 등의 다양한 디바이스를 통해 서비스에 접속할 수 있다.
리소스의 공유 사업자의 컴퓨팅 리소르를 여러 사용자가 공유하는 형태로 이용한다. 사용자마다 리소스가 할당되지만 사용자는 시스템의 어느 부분에 할당, 접속하였는지 알 수도, 알 필요도 없다.
신속한 확장성 필요에 따라, 필요한 만큼의 스케일링이 가능하다. 스케일링 방법으로는 아래와 같은 종류가 있습니다.
스케일 업: 노드의 스펙을 상향하여 처리량을 높히는 것
스케일 다운: 노드의 스펙을 하향하여 처리량을 낮추는 것
스케일 아웃: 노드의 수를 늘려 처리량을 높히는 것
스케일 인: 노드의 수를 줄여 처리량을 낮추는 것.

스케일 업 / 다운 방식은 노드 스펙 상한이 처리량의 한계가 되는 단점이 있습니다.

측정 가능한 서비스 이용한 만큼 요금이 부과되는 종량제 서비스

이외에도 SaaS(Software as a Service), PaaS(Platform as a Service), IaaS(Infrastructure as a Service)와 같은 서비스 모델 프라이빗 클라우드, 퍼블릭 클라우드와 같은 이용 모델로 구성됩니다.

“그림으로 배우는 클라우드(하야시 마사유키 저)” 책을 읽고 정리한 내용입니다.

클라우드의 장점

클라우드는 기존 자체 시스템을 구축하는 “온 프레미스” 방식과 비교해봤을 때 여러 장점이 있습니다.

경제성 온 프레미스 방식에서는 피크 타임을 예상하여 그를 처리할 수 있는 하드웨어와 소프트웨어를 준비해야합니다. 반면 클라우드는 유연한 스케일링이 가능하여 그 때 그 때에 맞는 비용으로 상황에 대응할 수 있습니다. 또한 부서별 / 사업장별 관리하던 소프트웨어와 데이터를 클라우드에서 통합 관리하여 관리 효율을 증대하고 비용을 절감할 수 있습니다.
유연성 위 “경제성”이 가능한 이유입니다. 유연한 스케일링을 통해 큰 노력과 비용을 들이지 않기 때문에 굉장히 용이합니다.
가용성 온 프레미스 방식에서는 서버 장애에 대처하기 위한 이중화, 백업을 직접 조치해야합니다. 반면 클라우드는 재해에 강하게 구축된 데이터 센터에 보관되며 일부 하드웨어에 장애가 있더라도 서비스를 계속해서 사용할 수 있도록 구성되어있기 때문에 온 프레미스 방식보다 낮은 비용으로 가용성이 높은 환경을 구축할 수 있습니다.
빠른 구축 속도 온 프레미스 방식의 경우 설계 후 하드웨어와 소프트웨어를 조달하여 배치하기까지 시간이 걸립니다. 클라우드는 클라우드가 제공하는 준비된 인프라에서 하드웨어와 소프트웨어를 이용하여 시스템을 신속하게 구축할 수 있습니다.

도서 정보: http://www.yes24.com/Product/Goods/41171236

[Cloud Series] 클라우드란? - 1

@deveely — Wed, 15 Jul 2020 18:54:56 +0900

금일부터 클라우드 기반 지식 정리를 공부하고 내용을 정리해보고자 합니다.

1. 클라우드 컴퓨팅이란?

클라우드 컴퓨팅(이하 클라우드)이란 컴퓨터를 사용한 정보의 처리를 자신의 PC가 아닌 인터넷 너머에 존재하는 컴퓨터를 처리하는 서비스를 의미합니다. 아마존의 AWS, MS의 Azure는 이러한 클라우드 서비스를 제공하는 대표적인 클라우드 사업자입니다.

클라우드는 네트워크나 인터넷에 연결되어있는 여러 장치들이 마치 구름과 같이 표현된다는 것에서 유래되었다고 하는데요. 말 그대로 이 구름과 같이 연결되어 있는 네트워크에서 제공하는 서비스를 통해 개인 혹은 기업이 하고자 하는 일을 처리할 수 있습니다.

중요한 점은 개인이 소유한 자원이 아닌 인터넷에 연결되어있는 클라우드 환경에서 제공되는 컴퓨팅 파워, 소프트웨어를 이용한다는 부분입니다.

클라우드는 “은행예금”과도 비유할 수 있습니다. “은행예금”은 금융 자산을 직접 보관하는 것이 아닌 금융 기관에 맡기고 필요할 때 ATM이 있는 곳이라면 어디에서든 입금, 출금, 이체 등 금융 서비스를 이용할 있습니다. 클라우드도 이와 비슷합니다. 우리가 보유한 정보가 금융자산이고 클라우드 사업자가 금융 기관이라고 할 수 있습니다. 우리는 정보를 클라우드에 위임하고, 우리가 필요한 각종 서비스를 클라우드를 통해 어디서든 수행할 수 있습니다.

우리가 금융 기관에 금융 자산을 맡기는 것이 당연하다고 느끼듯, 입증된 클라우드 사업자에게 정보 자산을 맡기고 서비스를 운용하는 것 또한 점차 당연해지고 있고 사례도 늘어가고 있습니다.

2. 클라우드가 등장한 배경

클라우드가 등장하기 전 IT 환경은 여러 단계에 걸쳐 변화해왔습니다.

1980년대에는 메인 프레임이라고 하는 대형 범용 컴퓨터가 주류였습니다. 애플리케이션과 데이터를 모두 하나의 대형 컴퓨터에 집중시키고 단말기에서는 입력 / 출력만을 담당하는 구조였습니다.

1990년대에는 클라이언트 단말기 성능이 향상되며 여러 클라이언트 측에서도 처리 기능을 수행하도록한 분상형 클라이언트 서버 모델로 변화합니다.

2000년대에는 네트워크가 빨라지고, 웹 및 브라우저 발달이 고속화되며 다시 처리 기능이 중앙 서버로 모이고, 웹 브라우저를 이용한 입 / 출력 처리를 하는 형태로 발전합니다.

2010년대에 들어서며 가상화, 분산 처리 기술의 발달로 중앙 집중식이 아닌 서버가 여러 개로 분산 배치되고, 필요한 만큼만 사용이 가능한 클라우드 컴퓨팅 모델로 발전되어 현재까지 끊임없이 발전하고 있습니다.

이렇게 발전하게 요인으로는

첫 째는 기술의 발전이 있습니다. CPU 성능 향상, 가상화 및 분산 처리 기술의 발달, 빨라지고 저렴해진 네트워크 비용, 거대한 데이터를 구축해 둘 수 있는 데이터 센터 등이 클라이드 환경이 구축될 수 있는 것을 도왔습니다.

두 번째는 기업의 니즈입니다. 규모가 커질수록 서버 구축, 운용 비용은 늘어가고 예측하기 어려운 트래픽과 필요 자원에 유연하게 대응해야하는 것이 주요 과제 중 하나가 됩니다. 클라우드 컴퓨팅 환경은 이러한 요구사항을 완벽히 해결해 줄 수 있었으며 이러한 환경을 제공하는 클라우드 사업자 또한 효율성 높은 서비스를 제공하고 안정적인 수입을 얻을 수 있다는 점 또한 요인이라 생각합니다.

“그림으로 배우는 클라우드(하야시 마사유키 저)” 책을 읽고 정리한 내용입니다.

도서 정보: http://www.yes24.com/Product/Goods/41171236

Spring Security + JWT를 활용한 토큰 기반 인증 구현 (with Spring Boot)

@deveely — Tue, 23 Jun 2020 18:34:09 +0900

Spring Security는 Spring Framework 기반 웹 애플리케이션의 보안을 담당하는 프레임워크입니다.

Spring Security is a framework that provides authentication, authorization, and protection against common attacks. With first class support for both imperative and reactive applications, it is the de-facto standard for securing Spring-based applications.

웹 보안은 기본적으로 요청하는 사용자를 식별하는 인증(Authenticate)과 인증된 사용자가 보호된 리소스에 접근할 권한이 있는지 확인하는 인가(Authorize)이 기본 바탕입니다.
이 글에서는 여러 인증방식 중 REST 서비스 등에서 주로 이용되는 토큰 기반 인증을 소개하고 구현하는 과정을 보여드리고자 합니다.

(개인적으로 공부하면서 해본 것을 기록한 것이라 구현 과정이나 글 내용에 오류가 있을 수 있습니다. 잘못된 부분이 있다면 댓글로 알려주시면 감사하겠습니다!)

토큰 기반 인증? JWT?

먼저 JWT는 JSON Web Token의 약자로 Json형태로 표현된 정보를 전달하는 하나의 방식으로, 토큰 자체에 모든 정보(토큰 기본정보, 전달할 정보, 검증됐다는 시그니쳐 정보 등)를 스스로 지니고 있다는 것이 큰 특징입니다. (자가 수용적, Self-Contained)
웹 서버의 경우 헤더나 파라미터를 통해 손쉽게 넘길 수 있어 인증이 필요한 REST 서비스에서 주로 활용됩니다.

토큰 기반 인증은 주로 클라이언트와 연결고리가 없는 모던 웹 서비스에서 사용하는 인증 방식입니다.
백엔드는 상태가 없는(stateless) REST 서비스로 구성하기 때문에 로그인 정보나 기타 정보를 세션에 저장하지 않습니다.
상태가 없이 서버로 들어오는 클라이언트의 요청으로 판단하기 위해 요청에 포함된 토큰을 해석하고, 권한이 있는 유저인지 판단하여 서버의 리소스에 접근하는 것을 허용합니다.

인증 과정을 간략하게 얘기하면

클라이언트가 인증 API를 통해 인증 요청
서버는 인증 진행 후 유효한 경우 토큰 발급 (JWT)
다음 요청 시 인증 토큰을 요청에 포함시켜 요청
서버는 요청에 포함된 인증 토큰을 해석해 권한 검사

Spring Security 핵심 개념과 토큰 기반 인증

토큰 기반 인증을 Spring Security로 구현하기 위해 핵심 개념을 아래와 같이 간략하게 정리해봤습니다.

접근 주체 (Principal)
- 보호된 리소스에 접근하려는 주체
인증 (Authenticate, Authentication)
- 접근 주체가 누구인지 식별하는 과정
- 식별이 완료된 정보는 인증 객체로 표현되어 이후 절차에서 참조될 수 있도록 전파됨
인가 (Authorize)
- 현재 사용자가 보호된 리소스에 대해 권한이 있는지 검사
- 인증을 통해 확인한 사용자가 보유한 권한(Roles)을 확인해 요청한 서비스(API)를 수행할 권한이 있는지 확인하는 과정
권한
- 인증된 접근 주체가 요청한 서비스를 수행할 자격이 있음을 증명하는 것

토큰 기반 인증은 인증을 토큰 기반으로 수행한다는 것입니다.
즉 요청에 포함된 토큰을 해석하고, 해당 사용자가 누구인지 확인하고 인증 객체를 생성해 프레임워크에 넘겨주는 과정을 구현해보도록 하겠습니다.

예제 진행

Spring Boot 2.3.1
Lombok

1. Spring Security 의존성 추가

먼저 Spring Boot 프로젝트에 security 의존성을 추가해줍니다.

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

2. Security 설정

기본적인 REST API 서버로 사용하기 위한 설정만 해둔 상태입니다.
이번에 다루는 주요 주제가 Security 설정이 아니기때문에 간략한 설명만 아래 코드에 주석으로 달아두겠습니다.

@Configuration
public class SecurityConfiguration extends WebSecurityConfigurerAdapter {

    private static final String[] PUBLIC_URI = {
            "/some-public-apis"
    };

    @Override
    protected void configure(HttpSecurity http) throws Exception {
        http
            // 개발 편의성을 위해 CSRF 프로텍션을 비활성화
            .csrf()
                .disable()
            // HTTP 기본 인증 비활성화
            .httpBasic()
                .disable()
            // 폼 기반 인증 비활성화  
            .formLogin()
                .disable()
            // stateless한 세션 정책 설정  
            .sessionManagement()
                .sessionCreationPolicy(SessionCreationPolicy.STATELESS)
                .and()
            // 리소스 별 허용 범위 설정  
            .authorizeRequests()      
                .antMatchers(PUBLIC_URI)
                    .permitAll()
                .anyRequest()
                    .authenticated()
                .and()
            // 인증 오류 발생 시 처리를 위한 핸들러 추가  
            .exceptionHandling()
                .authenticationEntryPoint(new RestAuthenticationEntryPoint())
        ;
    }
}

3. JWT 라이브러리 추가 및 토큰 인증 클래스 정의

기본적인 설정은 마치고, 본격적으로 토큰 기반 인증을 구현합니다.
먼저 JWT를 사용하기 위해 의존성을 추가해줍니다.

<dependency>
  <groupId>io.jsonwebtoken</groupId>
  <artifactId>jjwt</artifactId>
  <version>0.5.1</version>
</dependency>

다음 인증 토큰을 표현한 인터페이스와 구현 클래스를 간단히 작성합니다.

public interface AuthenticationToken {
    String getToken();
}

@Builder
@Getter
public class JwtAuthenticationToken implements AuthenticationToken {
    private String token;
}

4. 인증 토큰 처리 인터페이스 및 구현 클래스 작성

인증에 사용되는 토큰 유형이 달라지거나, 인증 토큰을 획득하는 방식 등 변경 가능성이 있는 부분이 많다고 생각이 들어서 인터페이스를 먼저 정의했습니다.
각 메소드에 대한 설명은 주석으로 대체하겠습니다.

public interface AuthenticationTokenProvider {

    /***
     * HTTP 요청에서 토큰 취득
     * @param request HTTP 요청
     * @return 토큰
     */
    String parseTokenString(HttpServletRequest request);

    /***
     * 토큰 발급
     * @param userNo 유저 No
     * @return 토큰
     */
    AuthenticationToken issue(Long userNo);

    /***
     * 토큰에서 userNo 취득
     * @param token 토큰
     * @return userNo
     */
    Long getTokenOwnerNo(String token);

    /***
     * 토큰 유효성 검사
     * @param token 토큰
     * @return 유효여부
     */
    boolean validateToken(String token);

}

다음은 구현 클래스입니다. 위에서 정의한 AuthenticationTokenProvider를 impletements하여 구체적인 동작을 정의해줍니다.

@Component
public class JwtAuthenticationTokenProvider implements AuthenticationTokenProvider {
    private static final Logger logger = LoggerFactory.getLogger(JwtAuthenticationTokenProvider.class);

    // 보통 설정파일에 관리하고 `@Value` 등으로 주입받아 사용하는 것을 추천
    private static final String SECRET_KEY = "SOME_SECRET_KEY";
    private static final long EXPIRATION_MS = 1000 * 60 * 60 * 24; 

    @Override
    public String parseTokenString(HttpServletRequest request) {
        String bearerToken = request.getHeader("Authorization");
        if (bearerToken != null && bearerToken.startsWith("Bearer ")) {
            return bearerToken.substring(7);
        }
        return null;
    }

    @Override
    public AuthenticationToken issue(Long userNo) {
        return AuthenticationToken.builder().token(buildToken(userNo)).build();
    }

    // JWT 토큰 생성
    private String buildToken(Long userNo) {
        LocalDateTime now = LocalDateTime.now();
        LocalDateTime expiredAt = now.plus(EXPIRATION_MS, ChronoUnit.MILLIS);
        return Jwts.builder()
                .setSubject(String.valueOf(userNo))
                .setIssuedAt(Date.from(now.atZone(ZoneId.systemDefault()).toInstant()))
                .setExpiration(Date.from(expiredAt.atZone(ZoneId.systemDefault()).toInstant()))
                .signWith(SignatureAlgorithm.HS512, SECRET_KEY)
                .compact();
    }

    @Override
    public Long getTokenOwnerNo(String token) {
        Claims claims = Jwts.parser()
                .setSigningKey(SECRET_KEY)
                .parseClaimsJws(token)
                .getBody();
        return Long.parseLong(claims.getSubject());
    }

    @Override
    public boolean validateToken(String token) {
        if (StringUtils.isNotEmpty(token)) {
            try {
                Jwts.parser().setSigningKey(SECRET_KEY).parseClaimsJws(token);
                return true;
            } catch (SignatureException e) {
                logger.error("Invalid JWT signature", e);
            } catch (MalformedJwtException e) {
                logger.error("Invalid JWT token", e);
            } catch (ExpiredJwtException e) {
                logger.error("Expired JWT token", e);
            } catch (UnsupportedJwtException e) {
                logger.error("Unsupported JWT token", e);
            } catch (IllegalArgumentException e) {
                logger.error("JWT claims string is empty.", e);
            }
        }
        return false;
    }
}

5. Spring Security 인증 절차에 추가하기

1 ~ 4번 과정을 통해 토큰 기반 인증을 수행하는데 필요한 작업을 진행했습니다.
이제 실제 인증을 수행하는 검사기를 만들고, 인증 절차에 추가해주어야 하는데요.
여기서는 Filter를 통해 검사하고 필터체인에 등록하도록 하겠습니다.

public class TokenAuthenticationFilter extends OncePerRequestFilter {
    @Autowired
    private AuthenticationTokenProvider authenticationTokenProvider;

    @Autowired
    private UserService userService;

    @Override
    protected void doFilterInternal(HttpServletRequest request, HttpServletResponse response, FilterChain filterChain)
            throws ServletException, IOException {
        String token = authenticationTokenProvider.parseTokenString(request);
        if (authenticationTokenProvider.validateToken(token)) {
            Long userNo = authenticationTokenProvider.getTokenOwnerNo(token);
            try {
                User member = (User) userService.loadUserByUsername(userNo.toString());
                UsernamePasswordAuthenticationToken authentication = new UsernamePasswordAuthenticationToken(member,
                        member.getPassword(), member.getAuthorities());
                authentication.setDetails(new WebAuthenticationDetailsSource().buildDetails(request));
                SecurityContextHolder.getContext().setAuthentication(authentication);
            } catch (UsernameNotFoundException e) {
                throw new ForbiddenException("유효하지않은 인증토큰 입니다. 인증토큰 회원 정보 오류");
            }
        }
        filterChain.doFilter(request, response);
    }
}

인증에 필요한 기능을 제공해주는 AuthenticationTokenProvider를 통해 인증을 수행하는 로직을 구현합니다.
토큰이 유효한지 확인 후 회원정보를 조회 및 인증 객체를 생성해 프레임워크에 전달하는 간단한 로직입니다.

다음으로는 이 필터를 아래와 같이 추가해 검사가 수행될 수 있도록 해줍니다.

@Configuration
public class SecurityConfiguration extends WebSecurityConfigurerAdapter {

    private static final String[] PUBLIC_URI = {
            "/some-public-apis"
    };

    @Override
    protected void configure(HttpSecurity http) throws Exception {
        http
            // 개발 편의성을 위해 CSRF 프로텍션을 비활성화
            .csrf()
                .disable()
            // HTTP 기본 인증 비활성화
            .httpBasic()
                .disable()
            // 폼 기반 인증 비활성화  
            .formLogin()
                .disable()
            // stateless한 세션 정책 설정  
            .sessionManagement()
                .sessionCreationPolicy(SessionCreationPolicy.STATELESS)
                .and()
            // 리소스 별 허용 범위 설정  
            .authorizeRequests()      
                .antMatchers(PUBLIC_URI)
                    .permitAll()
                .anyRequest()
                    .authenticated()
                .and()
            // 인증 오류 발생 시 처리를 위한 핸들러 추가  
            .exceptionHandling()
                .authenticationEntryPoint(new RestAuthenticationEntryPoint())
        ;

    // 토큰 인증 필터 추가
    http.addFilterBefore(tokenAuthenticationFilter(), UsernamePasswordAuthenticationFilter.class);
    }

  @Bean
    public TokenAuthenticationFilter tokenAuthenticationFilter() {
        return new TokenAuthenticationFilter();
    }
}

마치며

토큰 인증 검사와 Spring Security를 사용해 구현하는 방법을 아주 간단하게 알아봤습니다.
Spring Security는 설계가 굉장히 탄탄하게 되어있고, 인증 절차 전 영역에 걸쳐 개발자가 원하는 지점을 커스터마이징 하기 쉽게 되어있습니다.
다만 이번 공부를 하면서.. Spring Security를 사용해 구현한다는게 Filter를 사용한 부분밖에 없고, Security의 핵심개념을 잘 살리지 못한 것 같아 아쉬웠습니다.
이 부분은 좀 더 공부해서, 더 나은 방법으로 구현하는 방식을 포스팅해야겠다는 생각이 듭니다.

리눅스 zip, unzip 압축, 압축 풀기

@deveely — Tue, 2 Jun 2020 18:27:33 +0900

리눅스 환경에서 zip으로 압축 및 .zip파일을 압축해제하는 zip, unzip 명령어에 대해 정리합니다.

1. zip

zip 명령어를 통해 특정 파일 혹은 디렉토리를 압축할 수 있습니다.

zip [압축 파일명.zip] [압축 대상] [압축 대상]...

특정 디렉토리 압축

-r 옵션은 대상 디렉토리 하위에 또 다른 폴더가 있을경우 전부 포함시키라는 옵션입니다.

zip -r [압축 파일명.zip] [압축 대상 디렉토리]

# test 폴더 전체 압축해 test.zip 생성
zip -r test.zip test/*

2. unzip

unzip 명령어를 통해 zip파일 압축 해제를 할 수 있습니다.

현재 폴더에 압축 풀기

unzip [압축 파일명.zip]

특정 디렉토리에 압축 풀기

unzip [압축 파일명.zip] -d [압축 풀 경로]

# test.zip 파일 압축을 /home/test 위치에 품
unzip test.zip -d /home/test

Spring Data JPA Audit기능을 활용해 Entity 생성시간 / 수정시간 자동 매핑하기

@deveely — Wed, 27 May 2020 15:34:26 +0900

보통 시스템에 필요한 테이블을 설계하면 이력 관리 등의 목적으로 row 생성시간, 수정시간을 저장할 컬럼 두는 경우가 많습니다.
JPA를 통해 해당 테이블들을 엔티티로 매핑하면 여러 테이블에 걸쳐 중복코드가 발생할 수 있습니다.
첫 째로는 각 엔티티에 생성 / 수정 시간을 매핑할 필드를 선언해줘야하고,
두 번째로는 특정 엔티티가 생성, 수정 될 때 해당 필드의 값에 현재시간 값으로 세팅해주는 코드가 필요하게 되는 점입니다.

이번 글에서는 Spring Data JPA 환경 제공하는 Audit 기능을 통해 이 컬럼들을 효율적으로 매핑할 수 있는 방법들을 소개합니다.

Spring Data JPA Auditing

Audit 기능은 엔티티에 발생하는 변경사항을 추적하는 기능을 구현하는데 도움을 줍니다.

1. Auditing 활성화

@EnableJpaAuditing으로 Auditing 기능을 활성화합니다.

@EnableJpaAuditing
public class Application {
  // ... 생략
}

2. EntityListener 설정 및 BaseEntity 생성

EntityListener는 Entity가 DB로 load / persist되기 전후에 커스텀 로직을 선언하는 인터페이스입니다.
커스텀 리스너를 구현 후 @EntityListeners를 통해 해당 엔티티에 등록해줄 수 있는데,
이번 예제에서는 Spring에서 제공하는 구현클래스인 AuditingEntityListener라는 Auditing기능을 수행하는 리스너를 등록했습니다.

AuditingEntityListener는 해당 엔티티에 선언된 CreatedDate, LastModifiedDate, CreatedBy, LastModifiedBy 어노테이션을
탐색해 엔티티 변경 시 해당값을 자동으로 업데이트 해줍니다. 이 예제에서는 CreatedDate, LastModifiedDate만 사용했습니다.

@MappedSuperClass는 해당 클래스가 상속될 속성을 포함하고 있는 SuperClass 라는걸 알리는 마커 어노테이션입니다.

@EntityListeners(value = {AuditingEntityListener.class})
@MappedSupperClass
public abstract class BaseEntity {
    @CreatedDate
    @Column(nullable = false)
    private LocalDateTime createdAt;               

    @LastModifiedDate                                   
    @Column(nullable = false)
    private LocalDateTime updatedAt;

    // getter 등 기타 코드 생량
}

3. 실제 엔티티 구현

이제 2번에서 구현한 BaseEntity를 실제 엔티티에 상속받기만 하면 생성시간, 수정시간 속성을 포함하며 해당 값이 자동으로 업데이트되는 기능까지 포함된 효과를 얻게 됩니다.

@Entity
@Table(name = "user")
public class UserEntity extends BaseEntity {
    // 생략
}

이렇게 간단하게 Auditing 기능을 통해 생성시간 수정시간을 자동으로 설정해봤습니다.
상속을 통해 중복되는 속성을 제거했고, AuditingEntityListener를 통해 지루하고 중복되는 값 설정해주는 로직을 제거할 수 있었습니다.

IntelliJ Custom Live Template 사용

@deveely — Sun, 22 Mar 2020 13:26:06 +0900

이번 포스트에서는 IntelliJ에서 유용하게 사용할 수 있는 커스텀 Live Template을 추가하는 방법을 소개합니다.

Live Template 기능 소개

Live Template 은 간단한 약어로 예약된 코드를 Generate 해주는 유용한 기능인데요.

예를들어 코드 편집창에서 main이라 치면

public static void main(String[] args) { 

}

이렇게 메인 메소드가 Generate됩니다.

IntelliJ의 Preferences > Editor > Live Templates 에서 제공되는 Live Template들을 확인할 수 있습니다.

커스텀 Live Template 추가

Preferences > Editor > Live Templates 메뉴 우측에 + 버튼을 클릭하여 라이브 템플릿을 추가합니다.

위 항목들을 설명드리면

Abbreviation은 Live Template의 약어
Description은 해당 Live Template에 대한 설명
Template text는 약어를 통해 Generate할 실제 코드
하단부에 Define 버튼을 클릭하여 Live Template이 활성화될 컨텍스트를 지정합니다.

자바 파일에서 tc라는 약어를 사용해 하나의 테스트 메소드를 generate하는 추가해보겠습니다.

Template text에서 $END$는 코드가 generate된 후 커서가 이동될 위치를 지정해주는 것입니다.

이렇게 Live Template을 이용해 빈번하게 반복되는 작업을 줄여 보다 생산성을 높힐수 있는거 같습니다.

리눅스 CentOS Jenkins 설치하기

@deveely — Sat, 21 Mar 2020 13:15:22 +0900

Jenkins는 가장 널리 사용되는 CI(Continous Integration)툴 중 하나입니다.

현 시점에서 많이 사용되는 CI툴로 Travis CI, Jenkins, TeamCity 등이 있습니다.
이 중에서도 Jenkins는 오랜 기간 널리 사용되어 오면서 수많은 사용자와 플러그인, 레퍼런스 등이 갖춰져있습니다.

개인 프로젝트에 적용할 CI툴을 고민해봤는데, Travis CI는 무료정책도 있지만 현재 제 상황에서는 무료정책을 이용할 수 없는 상황이었고, TeamCity도 일정 기준 이상이면 무료로는 사용이 불가하다고하여 우선 무료이면서 가장 보편적인 Jenkins를 구축해보기로 했습니다.

설치

먼저 아래 명령어로 Jenkins를 설치합니다.

wget -O /etc/yum.repos.d/jenkins.repo http://pkg.jenkins-ci.org/redhat-stable/jenkins.repo
rpm --import https://jenkins-ci.org/redhat/jenkins-ci.org.key
yum install jenkins

설정

기본 설정

CentOS의 경우 Jenkins Home 디렉토리나 포트 등의 설정은 /etc/sysconfig/jenkins에서 진행할 수 있습니다.
저의 경우 머신 하나만 가지고 진행하고 있기 때문에 애플리케이션이 사용하는 포트와 겹치지 않게 하기위해 포트를 변경하였습니다. (9000대 포트를 사용한다고 합니다)

...

## Type:        integer(0:65535)
## Default:     8080
## ServiceRestart: jenkins
#
# Port Jenkins is listening on.
# Set to -1 to disable
#
JENKINS_PORT="9001"

...

JRE 설정

Jenkins는 Java 기반으로 제작된 도구이기 때문에 JRE를 필요로 하는데요.

Jenkins는 기본적으로 아래 경로들을 대상으로 JRE 자동으로 탐색합니다.

/etc/alternatives/java
/usr/lib/jvm/java-1.8.0/bin/java
/usr/lib/jvm/jre-1.8.0/bin/java
/usr/lib/jvm/java-1.7.0/bin/java
/usr/lib/jvm/jre-1.7.0/bin/java
/usr/lib/jvm/java-11.0/bin/java
/usr/lib/jvm/jre-11.0/bin/java
/usr/lib/jvm/java-11-openjdk-amd64
/usr/bin/java

만약 수정을 원하면 /etc/init.d/jenkins 파일에 candidate목록에 본인 환경에 맞는 경로를 추가해주면 됩니다.

위 경로에 Java가 설치되어있지 않은 경우 No Such File... 오류가 발생합니다.

경로가 제대로 잡혔더라도 권한 문제로 Permission Denied 오류가 발생할 수도 있는데요.
이경우엔 /etc/sysconfig/jenkins 에 JENKINS_USER값을 root로 변경해주면 됩니다.

...

## Type:        string
## Default:     "jenkins"
## ServiceRestart: jenkins
#
# Unix user account that runs the Jenkins daemon
# Be careful when you change this, as you need to update
# permissions of $JENKINS_HOME and /var/log/jenkins.
#
JENKINS_USER="root"

...

JRE 관련 추가 설정

이 설정은 OpenJDK를 사용하는 경우에만 해줘야하는 것으로 예상되는데요.

저의 경우 Jenkins 실행은 정상적으로 되지만 페이지 접속 시 AWT 관련 오류가 발생했습니다. 정확한 원인은 파악하지 못했지만 예상되는 원인으로는 사용하는 OpenJDK에 몇몇 라이브러리가 누락되어 발생한 것으로 예상했는데요.

after installing Jenkins for integration with FishEye always get error message below trying to access Jenkins site:
AWT is not properly configured on this server. Perhaps you need to run your container with "-Djava.awt.headless=true"?

아래 링크에서 OS별 설치방법 확인해서 필요한 라이브러리 설치하여 해결할 수 있었습니다.
https://wiki.jenkins.io/display/JENKINS/Jenkins+got+java.awt.headless+problem

Centos 의 경우

yum install dejavu-sans-fonts
yum install fontconfig

설정을 마친 후 젠킨스 서비스를 실행합니다.

실행

아래 명령어를 통해 젠킨스를 실행한 후 머신주소:설정한포트로 접속하면 드디어 젠킨스 로그인 페이지를 볼 수 있습니다.

sudo service jenkins start

리눅스 CentOS Git 설치하기

@deveely — Fri, 20 Mar 2020 12:12:44 +0900

CentOS에서 git을 설치해 사용하는 방법을 간략하게 정리합니다.

1. 설치확인

설치 전에 먼저 이미 설치되어있는지 확인합니다.

git --version

command not found 오류가 발생하거나, git이 설치되어있지 않다는 오류 문구가 나면 설치되지 않은 것입니다.

2. 설치

아래 명령어를 통해 git을 설치할 수 있습니다.

yum install git

위와 같이하면 yum에서 제공되는 git 버전이 자동으로 설치되는데, 만약 원하는 버전이 있다면 아래와 같이 버전을 명시하면 됩니다.

yum install git-<version>

3. 사용자 설정

git config --global user.name "userName" git config --global user.email "email"

4. 정상 설치 확인

git --version

스프링 부트 (Spring Boot) 와 의존성 관리

@deveely — Tue, 18 Feb 2020 16:59:27 +0900

스프링 부트의 강력한 장점 중 하나는 스프링, 써드파티 라이브러리 의존성을 관리해주는 부분이라고 생각합니다.
의존성 관련 내용에 앞서 스프링 부트가 무엇인지 간략하게 소개하겠습니다.

스프링 부트 (Spring Boot)란?

스프링 부트 공식 홈페이지에서는 다음과 같이 소개하고 있습니다.

Spring Boot makes it easy to create stand-alone, production-grade Spring based Applications that you can "just run".

상용 수준의 독립실행형 스프링 애플리케이션을 쉽게 만들 수 있도록 해주는 기술로 대표적으로 다음과 같은 기능을 제공합니다.

독립 실행형 애플리케이션 제작 Create stand-alone Spring applications
내장 WAS 지원(Tomcat, Jetty, Undertow)
빌드 구성을 단순화해주는 starter 의존성 제공
스프링 및 써드파티 라이브러리 자동 구성 (Auto Configuration)
메트릭, 헬스체크, 설정 외부화 등 상용 기능 제공
XML 설정 등 필요 X

Spring Boot 의 의존성 관리

위에서 언급한대로 스프링 부트는 starter라 불리는 의존성을 제공합니다.

각 starter는 관련있는 의존성들의 묶음으로 하나의 starter 의존성으로 해당 의존성과 관련된 스프링 & 써드파티 라이브러리 또는 또다른 starter 의존성까지도 의존성 간 버전, 호환성 걱정 없이 한번에 애플리케이션에 포함시킬 수 있습니다.

아래 링크에서 Spring Boot에서 제공하는 모든 starter 의존성을 확인할 수 있습니다.
https://docs.spring.io/spring-boot/docs/current/reference/htmlsingle/#using-boot-starter

대표적인 spring-boot-starter-web은 웹 관련 기능의 집합으로 기존에 sprinb-web, spring-webmvc을 포함한 여러 라이브러리를 포함시켜야했던 때와 달리 위 의존성 하나로 웹 관련 의존성을 버전 등이 최적화된 상태로 포함시킬 수 있습니다.

spring-boot-starter-web의 pom.xml

<?xml version="1.0" encoding="UTF-8"?>
<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 https://maven.apache.org/xsd/maven-4.0.0.xsd">
  <modelVersion>4.0.0</modelVersion>
  <parent>
      <groupId>org.springframework.boot</groupId>
      <artifactId>spring-boot-starters</artifactId>
      <version>${revision}</version>
  </parent>
  <artifactId>spring-boot-starter-web</artifactId>
  <name>Spring Boot Web Starter</name>
  <description>Starter for building web, including RESTful, applications using Spring
      MVC. Uses Tomcat as the default embedded container</description>
  <properties>
      <main.basedir>${basedir}/../../..</main.basedir>
  </properties>
  <scm>
      <url>${git.url}</url>
      <connection>${git.connection}</connection>
      <developerConnection>${git.developerConnection}</developerConnection>
  </scm>
  <dependencies>
      <dependency>
          <groupId>org.springframework.boot</groupId>
          <artifactId>spring-boot-starter</artifactId>
      </dependency>
      <dependency>
          <groupId>org.springframework.boot</groupId>
          <artifactId>spring-boot-starter-json</artifactId>
      </dependency>
      <dependency>
          <groupId>org.springframework.boot</groupId>
          <artifactId>spring-boot-starter-tomcat</artifactId>
      </dependency>
      <dependency>
          <groupId>org.springframework.boot</groupId>
          <artifactId>spring-boot-starter-validation</artifactId>
          <exclusions>
              <exclusion>
                  <groupId>org.apache.tomcat.embed</groupId>
                  <artifactId>tomcat-embed-el</artifactId>
              </exclusion>
          </exclusions>
      </dependency>
      <dependency>
          <groupId>org.springframework</groupId>
          <artifactId>spring-web</artifactId>
      </dependency>
      <dependency>
          <groupId>org.springframework</groupId>
          <artifactId>spring-webmvc</artifactId>
      </dependency>
  </dependencies>
</project>

Spring Boot 의존성의 버전 관리

위 spring-boot-starter-web의 pom.xml을 보면 각 라이브러리의 버전정보가 적혀있지 않은데요. 그 이유는 버전정보의 경우 별도의 파일에서 관리하고 있기 때문입니다.

보통 스프링 부트를 사용해 개발하면 Maven이던 Gradle이던 spring-boot-starter-parent라는 의존성을 상속하게 되는데요. 이 starter 의존성이 상속하고 있는 spring-boot-dependencies 라는 의존성에 모든 의존성의 버전정보가 들어있습니다.

spring-boot-dependencies의 pom.xml

<?xml version="1.0" encoding="UTF-8"?>
<project xmlns="http://maven.apache.org/POM/4.0.0"
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 https://maven.apache.org/xsd/maven-4.0.0.xsd">
  ....
  <properties>
      <main.basedir>${basedir}/../..</main.basedir>
      <!-- Dependency versions -->
      <activemq.version>5.15.11</activemq.version>
      <antlr2.version>2.7.7</antlr2.version>
      <appengine-sdk.version>1.9.77</appengine-sdk.version>
      <artemis.version>2.10.1</artemis.version>
      <aspectj.version>1.9.5</aspectj.version>
      <assertj.version>3.13.2</assertj.version>
      <atomikos.version>4.0.6</atomikos.version>
      <awaitility.version>4.0.2</awaitility.version>
      <bitronix.version>2.1.4</bitronix.version>
      <byte-buddy.version>1.10.6</byte-buddy.version>
      ...
      </properties>
      ...
</project>

라이브러리 버전 Override

위 처럼 properties에 각 라이브러리 별 버전 프로퍼티가 선언되어있고, 사용측에서 이 프로퍼티를 참조하기 때문에, 버전을 변경할 일 이 있으면 위 프로퍼티명을 참고하여 우리 프로젝트의 pom.xml에서 버전정보를 Override 할 수 있습니다.

Project의 pom.xml

...
<parent>
  <groupId>org.springframework.boot</groupId>
  <artifactId>spring-boot-starter-parent</artifactId>
  <version>사용할 Spring Boot 버전</version>
</parent>
<properties>
  여기에서 프로퍼티 정보를 통해 기본 의존성의 버전을 변경할 수 있습니다.
</properties>
<dependencies>
  사용할 spring-boot-starter 모듈들 선언....
</dependencies>
...

참고

Java Bean Validation 사용하기

@deveely — Mon, 17 Feb 2020 11:25:45 +0900

Java Bean Validation는 공식 사이트에서는 오브젝트 레벨의 제약 선언 및 유효성 검사 기술을 제공하는 것을 목표로 하고 있는 기술이라고 합니다.

The technical objective of this work is to provide an object level constraint declaration and validation facility for the Java application developer, as well as a constraint metadata repository and query API.

실제로 프로그래밍을 하다보면 어떤 객체의 값이 비었는지, 공백인지, 날짜가 이전인지 등의 유효성 검사를 빈번하게 수행하게 되고 이로 인해 유효성 검사 로직들이 여러 곳에 흩어지게 되는 경우도 있는데요. Java Bean Validation을 이용하면 검사 대상 클래스에 어노테이션 기반 제약조건을 선언하여 간결하게 유효성 검사를 할 수 있습니다.

Bean Validation은 자바에서 유효성 검사를 하는 방법에 대한 명세입니다. 즉, 실제로 동작하는 코드가 아니라는 것입니다.

때문에 실제로 동작하려면 이 명세를 구현한 구현체가 있어야하는데 대표적인게 Hibernate Validator입니다. 그리고 Spring Boot 2.0은 Bean Validation 2.0을 사용하고 있습니다.

# Bean Validation 버전별 Hibernate Validator 호환성

Version	JSR	Release	Compatible Implementation
Bean Validation 1.0	JSR 303	Java EE6, 2009	Hibernate Validator 4.3.1.Final
Bean Validation 1.1	JSR 349	Java EE7, 2013	Hibernate Validator 5.1.1.Final
Bean Validation 2.0	JSR 380	Java EE8, 2017	Hibernate Validator 6.0.1.Final

그럼 Bean Validation을 실제로 사용하는 방법을 알아보겠습니다.

기본적인 사용 방법

# 의존성 추가

Bean Validation은 javax.validation.validation-api로 별도 모듈이 있지만, Hibernate Validator가 해당 모듈을 포함하고 있기 때문에 pom.xml에 아래와 같이 의존성을 추가해줍니다.

<dependency>
  <groupId>org.hibernate</groupId>
  <artifactId>hibernate-validator</artifactId>
  <version>6.0.7.Final</version>
</dependency>

만약 실행환경이 SE라면 아래 의존성을 함께 추가해줘야함니다. (Tomcat 등의 EE 환경에서는 필요 없음)

org.glassfish.javax.el의 경우 JSR 341에 명시된 Unified Expression Language에 대한 구현체로 Hibernate Validator가 제약 조건 위반 메시지 표현 등을 처리하기 위해 필요하다고 합니다.

org.hibernate.hibernate-validator-cdi는 JSR 346에 명시된 CDI (Contexts and Dependency Injection)의 구현체로 자세히는 모르겠지만 @Inject 등으로 Validator를 주입받고, @Valid 등으로 유효성 검사를 자동으로 수행하는 등에 사용하기 위해 필요한 의존성으로 생각됩니다.

<dependency>
  <groupId>org.glassfish</groupId>
  <artifactId>javax.el</artifactId>
  <version>3.0.0</version>
</dependency>
<dependency>
  <groupId>org.hibernate</groupId>
  <artifactId>hibernate-validator-cdi</artifactId>
  <version>6.0.7.Final</version>
</dependency>

# 유효성 검증할 객체 생성

예시로, 아래와 같이 모델 객체를 만들어 보겠습니다.

필드 위에 선언한 @NotBlank, @Positive 어노테이션들이 바로 제약조건들입니다.

아래 예시에서는 name은 공백이지 않아야하며 age는 0보다 큰 숫자여야한다는 제약조건을 걸었습니다.

public class Member {
    @NotBlank
    private String name;

    @Positive
    private int age;

    public Member(String name, int age) {
        this.name = name;
        this.age = age;
    }

    public String getName() {
        return name;
    }

    public int getAge() {
        return age;
    }
}

# 유효성 검증 수행

먼저 유효성 검사를 수행하는 Validator를 생성합니다.

private Validator validator = Validation.buildDefaultValidatorFactory().getValidator();

다음으로 Validator를 통해 Member 객체의 유효성 검사를 수행합니다.

Validator의 validate 메소드에 검사할 객체를 전달하고, 그 결과를 Set<ConstraintViolation<?>> (제약조건 위반 Set)으로 받습니다.

Member member = new Member("", -1);

Set<ConstraintViolation<Member>> violations = validator.validate(member);
violations.forEach(e -> {
  System.out.println(String.format("검사 필드: %s, 유효하지 않은 값: [%s] 메시지: %s", e.getPropertyPath(), e.getInvalidValue(), e.getMessage()));
});

위 코드를 실행하면 아래와 같은 결과를 확인할 수 있습니다.

검사 필드: age, 유효하지 않은 값: [-1] 메시지: must be greater than 0
검사 필드: name, 유효하지 않은 값: [] 메시지: 반드시 값이 존재하고 공백 문자를 제외한 길이가 0보다 커야 합니다.

만약 메시지를 커스텀 메시지를 출력하고 싶다면 각 제약조건 어노테이션의 message 속성에 설정하면 됩니다.

public class Member {
    @NotBlank(message = "이름이 비어있습니다.")
    private String name;

    @Positive(message = "나이는 0보다 큰 값이어야합니다.")
    private int age;

    ...
}

검사 필드: name, 유효하지 않은 값: [] 메시지: 이름이 비어있습니다.
검사 필드: age, 유효하지 않은 값: [-1] 메시지: 나이는 0보다 큰 값이어야합니다.

Built-in Constraint Definitions

Bean Validation에는 대부분의 경우에 사용가능한 제약조건 어노테이션들이 내장(Built-in) 되어있습니다.

javax.validation.constraints 패키지를 확인해보면 총 22개의 내장 제약조건이 있는것을 확인할 수 있습니다.

@AssertFalse
@AssertTrue
@DecimalMax
@DecimalMin
@Digits
@Email
@Future
@FutureOrPresent
@Max
@Min
@Negative
@NegativeOrZero
@NotBlank
@NotEmpty
@NotNull
@Null
@Past
@PastOrPresent
@Pattern
@Positive
@PositiveOrZero
@Size

거의 모든 어노테이션들이 이름만으로 어떤 제약조건인지 쉽게 유추가 가능합니다.

자세한 사항은 공식 홈페이지의 8. Built-in Constraint definitions 섹션을 참고하시는 것을 추천드립니다.

Bean Validation 1.1 vs 2.0

Bean Validation 2.0의 주요 변경사항은 공식 사이트에서 아래와 같이 소개하고 있습니다.
전체 변경사항은 이 곳에서 확인할 수 있습니다.

support for validating container elements by annotating type arguments of parameterized types e.g. List<@Positive Integer> positiveNumbers. This also includes:
- more flexible cascaded validation of container types
- support for java.util.Optional
- support for the property types declared by JavaFX
- support for custom container types
support for the new date/time data types (JSR 310) for @Past and @Future
new built-in constraints: @Email, @NotEmpty, @NotBlank, @Positive, @PositiveOrZero, @Negative, @NegativeOrZero, @PastOrPresent and @FutureOrPresent
leverage the JDK 8 new features (built-in constraints are marked repeatable, parameter names are retrieved via reflection)

참고

아까도 언급했지만 Spring Boot 2.0 이상 버전에서는 Bean Validation 2.0이 기본적으로 사용됩니다.
하지만 이하 버전에서는 Bean Validation 1.1 버전이 사용되는데 이런 경우 다음과 같은 방법으로 버전업을 진행하면 됩니다.

<properties>
    <javax-validation.version>2.0.1.Final</javax-validation.version>
    <hibernate-validation.version>6.0.7.Final</hibernate-validation.version>
</properties>

JUnit5 사용해보기

@deveely — Sat, 1 Feb 2020 19:38:37 +0900

JUnit은 Java를 위한 단위 테스트 (Unit Test) 프레임워크로 개발하는 프로그램에 대한 테스트케이스를 쉽게 작성할 수 있도록 도와줍니다.
그동안 JUnit4를 주로 사용해왔는데, 최근들어 JUnit5가 있음을 알게되고(사실 나온지는 2년이 넘은..) 어떤 차이점이 있는지 알아보고 사용해보려합니다.

JUnit4에서 JUnit5로 넘어오며 달라진 점

먼저 JUnit5를 사용하기 위해서는 아래 지원범위에 만족하는지 확인해봐야합니다.

Java8 이상 지원
IntelliJ IDEA 2016.2 이후 지원
Eclipse Oxygen 이후 지원
Kotlin 지원

JUnit5 User Guide 문서 첫 단락에 보면 다음과 같은 문구가 적혀있습니다.

Unlike previous versions of JUnit, JUnit5 is composed of several different modules from three different sub-projects.

JUnit5 = JUnit Platform + JUnit Jupiter + JUnit Vintage

이전 버전들과 달리 JUnit5 에 들어서며 여러 개의 서브 모듈로 나뉘었다는 것입니다.

# JUnit Platform

JUnit Platform은 Test를 실행하기 위한 전반적인 사항들을 제공하는 역할입니다. 테스트케이스를 발견, 실행하고 결과를 보고해주는 일종의 컨텍스트라는 생각이 듭니다.
JUnit Platform은 어떻게 테스트를 발견하고 실행하고 보고할 지에 대한 실제 동작은 TestEngine 인터페이스를 구현하여 정의되며 실제 구현체들은 별도 모듈로 존재합니다.

# JUnit Jupiter

JUnit Jupiter는 TestEngine을 구현한 엔진입니다. (jupiter-engine) Jupiter API는 JUnit5에 새롭게 추가된 API들을 포함하고 있습니다.

# JUnit Vintage

JUnit Vintage는 기존 JUnit4 버전으로 작성된 테스트를 실행하기 위한 엔진입니다. (vintage-engine)

참고로 Spring Boot 2.2.0 버전부터 JUnit5가 기본으로 채택되었는데요.
Spring Initializer를 통해 프로젝트를 만들어보면 Test 디펜던시가 다음과 같이 되어있는것을 볼 수 있습니다.

...
<dependency>
  <groupId>org.springframework.boot</groupId>
  <artifactId>spring-boot-starter-test</artifactId>
  <scope>test</scope>
  <exclusions>    
    <exclusion>
      <groupId>org.junit.vintage</groupId>
      <artifactId>junit-vintage-engine</artifactId>
    </exclusion>
  </exclusions>
</dependency>
...

junit-vintage-engine 모듈을 제외하고 있습니다. vintage-engine 자체가 JUnit4를 지원하기 위한 모듈이다보니 기본적으로는 제외하도록 설정되는 것입니다.

만약 JUnit4 테스트케이스를 같이 관리해주어야하는 상황이라면 위 exclusion 설정을 삭제하면 됩니다.

새로운 혹은 변경된 기능

아키텍쳐는 많이 바뀌었지만 실제 테스트케이스를 작성하는 부분에서는 크게 바뀐 점은 느껴지지 않습니다.

주로 기존에 사용되던 어노테이션들의 네이밍이 좀 더 명확해지는등의 차이점이 눈에 띕니다.

1. @DisplayName

기존에 테스트 결과가 보고될 때 메소드명이 테스트케이스 이름으로 사용되었는데요. 때문에 테스트케이스를 잘 설명하기 위해 한글로 하고는 했습니다.

JUnit5에서는 @DisplayName 어노테이션을 활용해 좀 더 깔끔하게 이름을 붙혀줄 수 있습니다.

public class MemberServiceTest {

  // 기존 방식
    @Test
    public void 멤버_프로필_조회() {
        ...
    }

  // JUnit5 방식
  @Test
  @DisplayName("멤버 프로필 조회")
  public void getMemberProfileTest() {    
        ...    
  }
}

2. @Disabled

기존 @Ignore 어노테이션을 대체하는 어노테이션입니다.

3. LifeCycle Hook

JUnit 테스트케이스 작성 시 개발자가 테스트 수행 전 후 특정 시점에 실행될 동작을 정의할 수 있습니다.

기존에는 @BeforeClass, @AfterClass, @Before, @After 어노테이션을 활용했었는데요.

JUnit5에서는 @BeforeAll, @AfterAll, @BeforeEach, @AfterEach 로 변경되었습니다. @Before와 @After는 기존에 (테스트케이스 마다)라는 의미가 없어서 혼동의 여지가 있었는데, 변경된 네이밍은 이를 잘 표현하고 있어 마음에 듭니다.

4. assertAll with Lambda

테스트에서 assertion종류가 많고 복잡한 경우 assertAll(Executable...executables)을 이용할 수 있습니다.
Executable은 파라미터와 반환값이 없는 함수형 인터페이스이기 때문에 assertAll로 그룹핑 + assertion을 람다로 작성할 수 있습니다.

assertAll("assertionGroup1",
  () -> assertEquals(expected, actual),
  ...    
)

5. @ParameterizedTest

한 메소드에서 여러 종류의 파라미터를 받아 테스트를 수행할 수 있습니다.

@DisplayName("공백 문자열 테스트")
@ParameterizedTest(name = "문자열 {0}으로 조회")
@ValueSource(strings = " ", "")
public void isBlankStringTest(String source) {
  boolean isBlank = service.isBlank(source);
  assertTrue(isBlank);
}

참고로 @ParamterizedTest를 사용하려면 junit-jupiter-params 모듈을 추가해야합니다.

maven

<dependency>
  <groupId>org.junit.jupiter</groupId>
  <artifactId>junit-jupiter-params</artifactId>
  <version>VERSION_TO_USE</version>
  <scope>test</scope>
</dependency>

gradle

testCompile group: 'org.junit.jupiter', name: 'junit-jupiter-params', version: 'VERSION_TO_USE'

이외에 더 자세히 알아보고싶으면 JUnit5 공식 홈페이지를 방문해보시는 것을 추천드립니다.

HikariCP와 커넥션 누수(Connection Leak) 관련 트러블슈팅

@deveely — Fri, 31 Jan 2020 15:14:21 +0900

문제 발생

운영중인 서비스에서 사용하는 DB에서 특정 테이블들을 분리하여 별도 DB로 구축하는 일이 생겼습니다. 때문에 이를 위해 Multi Datasource를 적용하였습니다.
기존 서비스는 Tomcat connection pool이 적용되어있었는데, 이번 작업을 하며 HikariCP로 변경하였습니다.
(참고로 Spring Boot 2.0 부터는 HikariCP가 기본 커넥션풀이라고 합니다.)

In Spring Boot 1.x, Tomcat connection pool was the default connection pool but in Spring Boot 2.x HikariCP is the default connection pool.

적용을 완료하고 정상동작을 확인한 후 개발환경에 반영해둔 다음날..

서비스 API 호출 시 오류가 발생한다는 문의를 받고 로그를 확인해보니 아래와 같은 에러 발생 및 API 호출 불가한 현상이 확인되었습니다.

 
[2020-01-10 08:49:08,143 +0900] [WARN] [c.z.h.p.ProxyConnection] GAMEDB-POOL - Connection com.mysql.jdbc.JDBC4Connection@158c355 marked as broken because of 
SQLSTATE(08S01), ErrorCode(0)
com.mysql.jdbc.exceptions.jdbc4.CommunicationsException: The last packet successfully received from the server was 36,305,998 milliseconds ago.  The last packet sent successfully to the server was 36,305,999 milliseconds ago. is longer than the server configured value of 'wait_timeout'. You should consider either expiring and/or testing connection validity before use in your application, increasing the server configured values for client timeouts, or using the Connector/J connection property 'autoReconnect=true' to avoid this problem.
        at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
        at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
        at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
        at java.lang.reflect.Constructor.newInstance(Constructor.java:423)
        at com.mysql.jdbc.Util.handleNewInstance(Util.java:425)
        at com.mysql.jdbc.SQLError.createCommunicationsException(SQLError.java:989)
        at com.mysql.jdbc.MysqlIO.send(MysqlIO.java:3746)
        at com.mysql.jdbc.MysqlIO.sendCommand(MysqlIO.java:2509)
        at com.mysql.jdbc.MysqlIO.sqlQueryDirect(MysqlIO.java:2680)
        at com.mysql.jdbc.ConnectionImpl.execSQL(ConnectionImpl.java:2487)
        at com.mysql.jdbc.PreparedStatement.executeInternal(PreparedStatement.java:1858)
        at com.mysql.jdbc.PreparedStatement.executeQuery(PreparedStatement.java:1966)
        at com.zaxxer.hikari.pool.ProxyPreparedStatement.executeQuery(ProxyPreparedStatement.java:52)
        at com.zaxxer.hikari.pool.HikariProxyPreparedStatement.executeQuery(HikariProxyPreparedStatement.java)

...        

Caused by: java.net.SocketException: 파이프가 깨어짐 (Write failed)
        at java.net.SocketOutputStream.socketWrite0(Native Method)
        at java.net.SocketOutputStream.socketWrite(SocketOutputStream.java:111)
        at java.net.SocketOutputStream.write(SocketOutputStream.java:155)
        at java.io.BufferedOutputStream.flushBuffer(BufferedOutputStream.java:82)
        at java.io.BufferedOutputStream.flush(BufferedOutputStream.java:140)
        at com.mysql.jdbc.MysqlIO.send(MysqlIO.java:3728)

원인

해당 서비스가 사용하는 DBMS는 MySQL입니다.
MySQL은 기본적으로 자신에게 맺어진 커넥션 중 일정 시간이상 사용하지 않은 커넥션을 종료하는 프로세스가 존재합니다. (MySQL의 wait_timeout이라는 값을 통해 확인할 수 있고 default 8시간)

이를 위해 기존 커넥션풀은 대부분 연결을 맺은 커넥션들이 끊기는 것을 방지하기 위해 SELECT 1 등의 쿼리를 주기적으로 날려 이 문제를 회피하는 반면 HikariCP는 maxLifetime 설정값에 따라 스스로 미사용된 커넥션을 제거하고 새로 생성하는 방식으로 동작한다고 합니다.

이번에 문제는 맺어졌던 커넥션이 장시간 사용되지 않아 MySQL 서버에 의해 끊어졌고 커넥션 풀은 끊어진 커넥션인줄 모르고 계속 사용되어 발생하였습니다.

Q. 커넥션이 장시간 사용되지 않더라도 HikariCP의 `maxLifeTime`이 MySQL의 `wait_timeout`보다 짧으면 문제될 것이 없지 않나?

위에서 언급한 것처럼 HikariCP는 maxLifetime에 도달한 커넥션의 연결을 끊고 새로운 커넥션을 생성하는 방식입니다. 때문에 maxLifetime이 wait_timeout보다 짧으면 MySQL 서버가 끊기 전에 스스로 연결을 끊고 새로 커넥션을 맺기 때문에 이런 문제가 발생할 여지가 없습니다. (maxLifetime 기본값은 30분)

하지만 그럼에도 밤새도록 종료되지 않는 커넥션이 있었던 것은 작성된 QueryDSL을 적용한 Repository에서 커넥션 누수가 있었기 때문입니다.
maxLifetime은 사용하지 않는 커넥션 한정으로 적용됩니다. 커넥션 누수로 인해 특정 커넥션이 close되지 않았고, HikariCP입장에서는 계속 active 상태로 인지하여 maxLifetime 적용되지 않았던 것입니다.

문제를 해결하기 위해 시도해본 것들

사실 문제 발생 초기엔 HikariCP의 동작방식에 대한 정확한 이해가 없었고, 때문에 커넥션 누수가 있을것이라고 예상치 못했습니다.

대신 설정값에 문제가 있을 것이라고 추측했고 삽질의 길이 시작되었습니다....

0. HikariCP 디버깅 로그 출력 설정

우선 더 정확히 현상을 파악하기 위해 logback 설정에 HikariCP에서 출력하는 디버그용 로그를 보기 위해 아래 설정을 진행하였습니다.

 ...
<logger name="com.zaxxer.hikari.HikariConfig" level="DEBUG"/>
<logger name="com.zaxxer.hikari" level="TRACE"/>
...

1. 설정값 (수치)에 따른 문제?

해당 서비스의 커넥션풀을 변경하면서 풀사이즈, 최소 유휴 상태 커넥션 수 등 풀 동작과 관련된 설정값을 기존 커넥션풀에 적용되어있는 수치 그대로 적용했는데요.
이것이 문제가 되는 것으로 알고 HikariCP를 사용하면서 문제가 없었던 타 서비스들과 동일한 설정을 사용하도록 하였습니다.

설정을 변경한 이후에도 문제가 발생했는데 그 이유는 아래와 같았습니다.

타 서비스들은 주기적으로 API 클라이언트 혹은 자체 스케쥴에 의해 db 호출을 하고 있었던 상황
문제가 발생한 서비스는 야간 시간대에 8시간 이상 아무런 호출이 없었음

2. maxLifetime 조정

HikariCP 공식 문서에 보면 maxLifetime값을 DB의 wait_timeout보다 몇 초 정도 짧게 설정하라고 권장하는 가이드가 있어 적용해봤습니다.

We strongly recommend setting this value, and it should be several seconds shorter than any database or infrastructure imposed connection time limit. 
A value of 0 indicates no maximum lifetime (infinite lifetime), subject of course to the idleTimeout setting. 

Default: 1800000 (30 minutes)

하지만 여전히 문제는 발생하였습니다.

3. autoreconnect=true

로그를 살펴보던 중, No operations allowed after connection closed. 라는 오류 메시지를 확인하게 됐습니다.
이를 보고 JDBC URL에 autoreconnect옵션을 줬지만, 효과가 없었습니다. 심지어 HikariCP 기본 작동 방식을 봤을때 넣는게 무의미한 설정이라고 합니다.

혼란을 주는 에러메시지
- 아래 에러메시지도 (HikariCP라면) 믿으면 안됩니다.
- 에러메시지: No operations allowed after connection closed.

4. minimumIdle 조정

idleTimeout은 생성된 커넥션이 유휴 상태로 풀에 존재할 수 있는 최대시간입니다.
이 설정은 minimumIdle < maximumPoolSize 일 경우에만 적용되는 값으로 이를 테스트하기 위해 값을 조정봤습니다. (역시 문제는 해결되지않음)

5. HikariCP와 Hibernate 의 버전 차이

지푸라기를 잡는 심정으로 버전을 확인해봤습니다. 기존 hikariCP, hibernate 두 버전의 차이가 4년 가량 있었습니다.
때문에 버전 차이에서 오는 알려지지 않은 버그일까 라는 생각에 버전업을 진행했지만 마찬가지로 문제가 해결되지 않았습니다.

[Before]
hibernate.version: 5.0.12.Final
hikaricp.version: 3.1.0

[After]
hibernate.version: 5.4.10.Final
hikaricp.version: 3.4.1

6. Connection 누수 현상 확인 (실제 원인)

또 다시 오류 메시지를 보던 중 문제가 된 Connection인 com.mysql.jdbc.JDBC4Connection@3bfbf166이 커넥션 풀에 등록은 되었으나 해제되지 않은 부분을 발견했습니다.

[2020-01-14 08:21:01,071 +0900] [WARN] [c.z.h.p.ProxyConnection] GAMEDB-POOL - Connection com.mysql.jdbc.JDBC4Connection@3bfbf166 marked as broken because of SQLSTATE(08S01), ErrorCode(0)
com.mysql.jdbc.exceptions.jdbc4.CommunicationsException: The last packet successfully received from the server was 52,889,749 milliseconds ago.  The last packet sent successfully to the server was 52,889,750 milliseconds ago. is longer than the server configured value of 'wait_timeout'. You should consider either expiring and/or testing connection validity before use in your application, increasing the server configured values for client timeouts, or using the Connector/J connection property 'autoReconnect=true' to avoid this problem.
...

실제로 Connection 생성 / 해제 로그를 추출해 확인해본 결과

maxLifetime에 따라 생성, 해제를 수행한 내역에서 위 문제가 된 커넥션이 Add는 되었지만 Close가 된 기록은 확인할 수 없었습니다.

[2020-01-13 16:09:29,349 +0900] [DEBUG] [c.z.h.p.HikariPool] GAMEDB-POOL - Added connection com.mysql.jdbc.JDBC4Connection@3bfbf166
[2020-01-13 16:09:29,353 +0900] [DEBUG] [c.z.h.p.HikariPool] GAMEDB-POOL - Added connection com.mysql.jdbc.JDBC4Connection@17d7631
[2020-01-13 16:09:29,359 +0900] [DEBUG] [c.z.h.p.HikariPool] GAMEDB-POOL - Added connection com.mysql.jdbc.JDBC4Connection@161f17c2
[2020-01-13 16:34:22,082 +0900] [DEBUG] [c.z.h.p.HikariPool] GAMEDB-POOL - Added connection com.mysql.jdbc.JDBC4Connection@60cc1c45
[2020-01-13 16:34:22,089 +0900] [DEBUG] [c.z.h.p.HikariPool] GAMEDB-POOL - Added connection com.mysql.jdbc.JDBC4Connection@7e3ef6ea
[2020-01-13 16:34:22,492 +0900] [DEBUG] [c.z.h.p.HikariPool] GAMEDB-POOL - Added connection com.mysql.jdbc.JDBC4Connection@6befd804
[2020-01-13 16:35:17,046 +0900] [DEBUG] [c.z.h.p.HikariPool] GAMEDB-POOL - Added connection com.mysql.jdbc.JDBC4Connection@273141d1
[2020-01-13 16:35:17,103 +0900] [DEBUG] [c.z.h.p.HikariPool] GAMEDB-POOL - Added connection com.mysql.jdbc.JDBC4Connection@3eac312e
[2020-01-13 16:35:17,208 +0900] [DEBUG] [c.z.h.p.HikariPool] GAMEDB-POOL - Added connection com.mysql.jdbc.JDBC4Connection@66d58bc3
[2020-01-13 16:35:17,278 +0900] [DEBUG] [c.z.h.p.HikariPool] GAMEDB-POOL - Added connection com.mysql.jdbc.JDBC4Connection@7d94ee53
[2020-01-13 16:55:35,178 +0900] [DEBUG] [c.z.h.p.PoolBase] GAMEDB-POOL - Closing connection com.mysql.jdbc.JDBC4Connection@161f17c2: (connection has passed maxLifetime)
[2020-01-13 16:55:43,855 +0900] [DEBUG] [c.z.h.p.PoolBase] GAMEDB-POOL - Closing connection com.mysql.jdbc.JDBC4Connection@17d7631: (connection has passed maxLifetime)
[2020-01-13 17:20:29,614 +0900] [DEBUG] [c.z.h.p.PoolBase] GAMEDB-POOL - Closing connection com.mysql.jdbc.JDBC4Connection@60cc1c45: (connection has passed maxLifetime)
[2020-01-13 17:20:47,468 +0900] [DEBUG] [c.z.h.p.PoolBase] GAMEDB-POOL - Closing connection com.mysql.jdbc.JDBC4Connection@6befd804: (connection has passed maxLifetime)
[2020-01-13 17:20:48,773 +0900] [DEBUG] [c.z.h.p.PoolBase] GAMEDB-POOL - Closing connection com.mysql.jdbc.JDBC4Connection@7e3ef6ea: (connection has passed maxLifetime)
[2020-01-13 17:21:30,939 +0900] [DEBUG] [c.z.h.p.PoolBase] GAMEDB-POOL - Closing connection com.mysql.jdbc.JDBC4Connection@273141d1: (connection has passed maxLifetime)
[2020-01-13 17:21:47,343 +0900] [DEBUG] [c.z.h.p.PoolBase] GAMEDB-POOL - Closing connection com.mysql.jdbc.JDBC4Connection@66d58bc3: (connection has passed maxLifetime)
[2020-01-13 17:21:50,493 +0900] [DEBUG] [c.z.h.p.PoolBase] GAMEDB-POOL - Closing connection com.mysql.jdbc.JDBC4Connection@3eac312e: (connection has passed maxLifetime)
[2020-01-13 17:21:59,390 +0900] [DEBUG] [c.z.h.p.HikariPool] GAMEDB-POOL - Added connection com.mysql.jdbc.JDBC4Connection@11991843
[2020-01-13 17:21:59,394 +0900] [DEBUG] [c.z.h.p.HikariPool] GAMEDB-POOL - Added connection com.mysql.jdbc.JDBC4Connection@30201cdf
[2020-01-13 17:22:01,785 +0900] [DEBUG] [c.z.h.p.PoolBase] GAMEDB-POOL - Closing connection com.mysql.jdbc.JDBC4Connection@7d94ee53: (connection has passed maxLifetime)
[2020-01-13 17:22:29,393 +0900] [DEBUG] [c.z.h.p.HikariPool] GAMEDB-POOL - Added connection com.mysql.jdbc.JDBC4Connection@35653c28

이제서야 커넥션 누수가 있음을 알고, HikariCP에서 제공하는 leakDetectionThreshold 옵션을 설정해 로컬에서 확인해본 결과 QueryDSL 이 적용되어있는 특정 API 부분에서 커넥션 누수가 확인되었습니다.

커넥션 누수가 발생한 원인

아래 2가지 이유가 복합적으로 연관되어 문제가 발생하였습니다.

EntityManager를 Bean으로 설정함
- EntityManager는 스레드간 절대 공유하면 안됨
QueryDSL 구현 Resitory에서 특정 datasource의 EntityManager를 받기 위해 setEntityManager를 재정의하지 않고 별도 setting 메소드 작성

JPA를 사용할 때 보통 EntityManager를 클래스 멤버변수로 두고 `@PersistenceContext`로 주입받아 사용하는데 이것은 어떻게 안전할까요?

바로 일반적으로 EntityManagerFactory를 통해 하나하나 생성되는 EntityManager가 아닌 SharedEntityManagerBean 라는 공유 가능하며 커넥션 생성 / 반환에 대한 관리를 지원하는 구현체가 주입되기 때문입니다.

QueryDslRepositorySupport는 아래와 같이 EntityManager를 주입받는 코드가 존재합니다.
특별한 설정이 없으면 SharedEntityManagerBean이 주입되어 아무 문제 없이 작동 했을것입니다.

@Repository
public abstract class QueryDslRepositorySupport {
//    ....

    /**
     * Setter to inject {@link EntityManager}.
     * 
     * @param entityManager must not be {@literal null}.
     */
    @Autowired
    public void setEntityManager(EntityManager entityManager) {

        Assert.notNull(entityManager, "EntityManager must not be null!");
        this.querydsl = new Querydsl(entityManager, builder);
        this.entityManager = entityManager;
    }

//    ....
}

하지만 MultidataSource를 적용하는 과정에서 @Autowired 어노테이션만으로는 프레임워크가 어떤 데이터소스의 EntityManager를 넣어줘야할지 판단하지 못하기 때문에 오류가 발생했고, 이 오류를 해결한다고 아래와 같이 일반 EntityManager를 싱글톤 빈으로 잡는 잘못된 설정을 하였습니다.

@Configuration
@EnableTransactionManagement
@EnableJpaRepositories(
        entityManagerFactoryRef = "gameEntityManagerFactory",
        transactionManagerRef = ServiceTransactionManager.GAME_DATABASE_TRANSACTION_MANAGER,
        basePackages = { "com.anan.repository.game" }
)
public class GameDatabaseConfiguration {
    // ...

	// 문제가 된 부분 - @Autowired 시 Persistence 기능 관련 프레임워크의 관리를 받지 못하는 EntityManager가 주입됨
    @Primary
    @Bean(name = "gameEntityManager")
    public EntityManager entityManager(@Qualifier("gameEntityManagerFactory") EntityManagerFactory entityManagerFactory) {
        return entityManagerFactory.createEntityManager();
    }

	// ...
}

public class GreetingRepositoryImpl extends QueryDslRepositorySupport implements GreetingRepositorySupport {
    // ...

    // 문제가 된 부분 - EntityManager를 주입받기위해 setEntityManage 재정의하지 않고 별도의 메소드를 통함
    // @PersistenceContext에 의해 setTargetEntityManager(정상 EntityManager) -> super.setEntityManager(정상 EntityManager) 
    // 상위 메소드의 @Autowired에 의해 setEntityManager(비정상 EntityManager)로 일반 EntityManager가 사용됨
    @PersistenceContext(unitName = "game")
    public void setTargetEntityManager(EntityManager entityManager) {
        super.setEntityManager(entityManager);
    }

    // ...

}

때문에 해당 커넥션을 사용 후 Connection.close가 제대로 동작하지 않았습니다.

해결

해결하기 위해 우선 EntityManager를 Bean으로 설정한 부분을 제거하였습니다.
두 번째로, MultidataSource를 적용하는 과정에서 @Autowired 어노테이션만으로는 프레임워크가 어떤 데이터소스의 EntityManager를 넣어줘야할지 판단하지 못하는 오류를 해결하기 위해 @PersistenceContext + unitName attribute 지정하는 방식으로 setEntityManager를 재정의하였습니다.

public class GreetingRepositoryImpl extends QueryDslRepositorySupport implements GreetingRepositorySupport {
    // ...

    @Override
    @PersistenceContext(unitName = "game")
    public void setEntityManager(EntityManager entityManager) {
        super.setEntityManager(entityManager);
    }

    // ...
}

마치며

기본이 중요하다는 것을 다시 느꼈습니다. 분명 JPA를 공부하며 책에서 EntityManager는 스레드간 공유하면 안되는 것이라는 내용을 본 적이 있음에도 불고하고
실수를 하여 문제가 발생했고 해결하기 위해 수많은 삽질을 하였습니다.

두번째는 자신이 사용하는 기술을 정확히 이해하고 사용하자는 것입니다. 이번에 겪은 이슈도 JPA의 대한 이해와 HikariCP에 대한 이해 부족으로 시간이 오래 걸렸습니다.
기술에 대한 이해가 있었다면 애초에 문제가 발생하지 않았거나 훨씬 빠르게 조치를 할 수 있었을 것입니다.

하지만 퍼포먼스가 좋다, 가장 인기있다라는 것만 알고 있던 HikariCP에 대해 좀 더 자세히 알게 되어서 한편으로는 좋은 경험이었다는 생각이듭니다.

참고

HikariCP 공식 문서 : https://github.com/brettwooldridge/HikariCP

HikariCP Connection Pool 해제 이슈

@deveely — Wed, 15 Jan 2020 03:29:27 +0900

몇 일 전, 개발환경에 구축되어있는 백엔드 시스템의 커넥션풀을 변경해야하는 일이 생겨 기존 Tomcat 커넥션풀 (tomcat-dbcp)에서 HikariCP로 변경하였습니다. 변경하면서 기존 설정되어있던 수치들을 HikariCP에서 제공하는 옵션에 맞추어 마이그레이션 했는데요. 완료 후 특별한 문제점은 보이지 않았습니다. 하지만 다음 날 출근 후…. 해당 시스템의 API를 호출하자 갑자기 아래와 같은 오류 메시지가 나오며 시스템이 정상적으로 동작하지 않는 상태인 것이 확인되었습니다.

[2020-01-10 08:49:08,143 +0900] [WARN] [c.z.h.p.ProxyConnection] GAMEDB-POOL - Connection com.mysql.jdbc.JDBC4Connection@158c355 marked as broken because of SQLSTATE(08S01), ErrorCode(0)
com.mysql.jdbc.exceptions.jdbc4.CommunicationsException: The last packet successfully received from the server was 36,305,998 milliseconds ago.  The last packet sent successfully to the server was 36,305,999 milliseconds ago. is longer than the server configured value of 'wait_timeout'. You should consider either expiring and/or testing connection validity before use in your application, increasing the server configured values for client timeouts, or using the Connector/J connection property 'autoReconnect=true' to avoid this problem.
        at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
        at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
        at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
        at java.lang.reflect.Constructor.newInstance(Constructor.java:423)
        at com.mysql.jdbc.Util.handleNewInstance(Util.java:425)
        at com.mysql.jdbc.SQLError.createCommunicationsException(SQLError.java:989)
        at com.mysql.jdbc.MysqlIO.send(MysqlIO.java:3746)
        at com.mysql.jdbc.MysqlIO.sendCommand(MysqlIO.java:2509)
        at com.mysql.jdbc.MysqlIO.sqlQueryDirect(MysqlIO.java:2680)
        at com.mysql.jdbc.ConnectionImpl.execSQL(ConnectionImpl.java:2487)
        at com.mysql.jdbc.PreparedStatement.executeInternal(PreparedStatement.java:1858)
        at com.mysql.jdbc.PreparedStatement.executeQuery(PreparedStatement.java:1966)
        at com.zaxxer.hikari.pool.ProxyPreparedStatement.executeQuery(ProxyPreparedStatement.java:52)
        at com.zaxxer.hikari.pool.HikariProxyPreparedStatement.executeQuery(HikariProxyPreparedStatement.java)
Caused by: java.net.SocketException: 파이프가 깨어짐 (Write failed)
        at java.net.SocketOutputStream.socketWrite0(Native Method)
        at java.net.SocketOutputStream.socketWrite(SocketOutputStream.java:111)
        at java.net.SocketOutputStream.write(SocketOutputStream.java:155)
        at java.io.BufferedOutputStream.flushBuffer(BufferedOutputStream.java:82)
        at java.io.BufferedOutputStream.flush(BufferedOutputStream.java:140)
        at com.mysql.jdbc.MysqlIO.send(MysqlIO.java:3728)

원인

리서치를 해본 결과 핵심은 기존 사용하던 tomcat-dbcp와 HikariCP의 철학이 달라서 생긴 문제였습니다. 현재 백엔드 시스템은 MySQL을 사용중인데요. MySQL은 맺어진 커넥션이 장시간 사용되지 않으면 해당 커넥션을 해제하도록 설계되어있습니다. (기본 8시간)

tomcat-jdbc

test-while-idle 설정이 true로 되어있으면 IDLE 상태의 커넥션들을 대상으로 DB서버에 SELECT 1을 주기적으로 보냅니다. 이를 통해 커넥션이 지속적으로 갱신되고 서버로부터 disconnect되지 않습니다.

spring.datasource.tomcat.test-while-idle=true
spring.datasource.tomcat.validation-query=SELECT 1

HikariCP

공식 문서: https://github.com/brettwooldridge/HikariCP

참고로 Spring Boot 2.0을 기점으로 기본 DBCP가 Tomcat DBCP에서 HikariCP로 바뀌었습니다. HikariCP는 tomcat-dbcp와 달리 사용하지 않는 Connection을 회수하도록 설계되었습니다. maxLifeTime으로 설정된 시간이 지나면 풀에서 제거되고, 다시 생성되는 방이며 connectionTestQuery는 커넥션을 최초 맺을때, 풀에서 가져올 때 사용되는 옵션이라고 합니다. 또한 JDBC4를 지원하는 환경에서는 connectionTestQuery 를 명시하지 않는것을 권고하고 있습니다.

[Do not use JDBC4]
hikaricp.opts.connectionTestQuery=SELECT 1

HikariCP 내부 JDBC 구현체에서는 아래와 같이 JDBC4에 대한 구현을 하고 있습니다.

PoolBase.java
  
boolean isConnectionAlive(final Connection connection) {
    ...
    if (isUseJdbc4Validation) {
        return connection.isValid(validationSeconds);
    }
    ...
}
  
/**
 * Execute isValid() or connection test query.
 *
 * @param connection a Connection to check
 */
private void checkDriverSupport(final Connection connection) throws SQLException {
    ...
    if (isUseJdbc4Validation) {
        connection.isValid(1);
    }
    ...
}

대처

우선은 maxLifeTime 값을 설정하고, connectionTestQuery 설정을 제거한 후 모니터링을 해보고자 합니다.

실제 운영환경에서는 발생하지 않았을 오류이지만, 오히려 개발환경인 덕에 발생하고, HikariCP에 대해 상세하게 리서치해 볼 수 있는 기회였습니다. 문제가 해결되면 해결된 글로 다시 작성해야겠습니다.

gRPC Reference - 예제

@deveely — Tue, 14 Jan 2020 03:25:44 +0900

전 편에서 gRPC에 대한 설명과 특징을 알아보았습니다. 이번 포스트에서는 grpc-java 모듈을 활용한 몇 가지 예제코드를 소개하고, 실제 프로젝트에 적용하는 방안에 대해 소개해보겠습니다.

gRPC Reference - 개요 및 특징

gRPC Basic

프로젝트 생성
- Java : 1.8
- gRPC : 1.25.0
- ProtoBuf : 3.11.0
pom.xml 설정
- gRPC + Protobuf 의존성 설정
- 스텁 생성을 위해 protoc 플러그인 설정
- proto 컴파일 -> 애플리케이션 컴파일 순으로 진행되도록 설정

<?xml version="1.0" encoding="UTF-8"?>
<project xmlns="http://maven.apache.org/POM/4.0.0"
         xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
         xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
    <modelVersion>4.0.0</modelVersion>

    <groupId>com.nhn.gia</groupId>
    <artifactId>gia-grpc</artifactId>
    <version>1.0-SNAPSHOT</version>

    <properties>
        <project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
        <grpc.version>1.25.0</grpc.version>
        <protobuf.version>3.11.0</protobuf.version>
        <protoc.version>3.11.0</protoc.version>
        <maven.compiler.source>1.7</maven.compiler.source>
        <maven.compiler.target>1.7</maven.compiler.target>
    </properties>

    <dependencies>
        <dependency>
            <groupId>io.grpc</groupId>
            <artifactId>grpc-netty-shaded</artifactId>
            <scope>runtime</scope>
            <version>${grpc.version}</version>
        </dependency>
        <dependency>
            <groupId>io.grpc</groupId>
            <artifactId>grpc-protobuf</artifactId>
            <version>${grpc.version}</version>
        </dependency>
        <dependency>
            <groupId>io.grpc</groupId>
            <artifactId>grpc-stub</artifactId>
            <version>${grpc.version}</version>
        </dependency>
    </dependencies>

    <build>
        <!-- Maven OS Extension -->
        <extensions>
            <extension>
                <groupId>kr.motd.maven</groupId>
                <artifactId>os-maven-plugin</artifactId>
                <version>1.6.2</version>
            </extension>
        </extensions>
        <plugins>
            <!-- proto (IDL) generator plugin -->
            <plugin>
                <groupId>org.xolstice.maven.plugins</groupId>
                <artifactId>protobuf-maven-plugin</artifactId>
                <version>0.6.1</version>
                <configuration>
                    <protocArtifact>com.google.protobuf:protoc:${protoc.version}:exe:${os.detected.classifier}</protocArtifact>
                    <pluginId>grpc-java</pluginId>
                    <pluginArtifact>io.grpc:protoc-gen-grpc-java:${grpc.version}:exe:${os.detected.classifier}</pluginArtifact>
                </configuration>
                <executions>
                    <execution>
                        <goals>
                            <goal>compile</goal>
                            <goal>compile-custom</goal>
                        </goals>
                    </execution>
                </executions>
            </plugin>
            <plugin>
                <groupId>org.apache.maven.plugins</groupId>
                <artifactId>maven-compiler-plugin</artifactId>
                <configuration>
                    <source>8</source>
                    <target>8</target>
                </configuration>
            </plugin>
        </plugins>
    </build>

</project>

proto 파일 작성 (서비스 정의)
- proto 파일을 별도로 컴파일할 경우 mvn protobuf:{goal} 명령어로 컴파일 할 수 있다.
- 컴파일된 결과물은 target(혹은 지정 빌드 디렉토리)/generated-sources/protobuf/java 이하 디렉토리에 생성된다.
- message 는 서버-클라이언트 간 송수신될 데이터 포맷
- service 는 서버, 클라이언트에서 원격 호출되는 서비스 메소드

syntax = "proto3";

package proto_test;

option java_package = "com.nhn.gia.grpc.proto";
option java_multiple_files = true;

service EchoService {
    rpc Echo (EchoRequest) returns (EchoResponse) {}
}

message EchoRequest {
    string msg = 1;
}

message EchoResponse {
    string msg = 1;
}

서버 프로그램 작성
- 서비스 기능 구현: proto파일에서 작성한 service 의 RPC 메소드들을 구현해줌
- 아래 예시에서는 정의된 rpc Echo (EchoRequest) returns (EchoResponse) {} 를 구현

public class EchoServiceImpl extends EchoServiceGrpc.EchoServiceImplBase {
    @Override
    public void echo(EchoRequest request, StreamObserver<EchoResponse> responseObserver) {
        EchoResponse response = EchoResponse.newBuilder().setMsg(request.getMsg()).build();

        responseObserver.onNext(response);
        responseObserver.onCompleted();
    }
}

작성한 서비스를 사용하는 서버 프로그램 작성

public class EchoServer {
  public static void main(String[] args) throws IOException, InterruptedException {
      Server server = ServerBuilder.forPort(8000)
              .addService(new EchoServiceImpl())
              .build();

      server.start();

      Runtime.getRuntime().addShutdownHook(new Thread(() -> {
          server.shutdown();
      }));

      server.awaitTermination();
  }
}

클라이언트 프로그램 작성

public class EchoClient {
    public static void main(String[] args) {
        ManagedChannel channel = ManagedChannelBuilder
                .forAddress("localhost", 8000)
                .usePlaintext()
                .build();

        EchoServiceBlockingStub stub = EchoServiceGrpc.newBlockingStub(channel);
        EchoResponse response = stub.echo(EchoRequest.newBuilder().setMsg("Hello gRPC!!").build());
        Logger.log("Echo Client: %s", response.getMsg());
        channel.shutdown();
    }

}

gRPC with SpringBoot

스프링 환경에서도 gRPC를 사용할 수 있다. 공식은 아니지만 몇 가지 개인 또는 그룹에서 제작해서 사용하고 있는 Spring boot starter가 있다. (https://github.com/LogNet/grpc-spring-boot-starter) (https://github.com/saturnism/spring-boot-starter-grpc)

아래는 별도 Spring Boot Starter 없이 진행한 예제

프로젝트 생성, pom.xml 에 gRPC 관련 의존성 추가, proto 파일 작성은 기존과 동일
- proto

syntax = "proto3";

option java_package = "com.nhn.gia.proto";
option java_multiple_files = true;

service UserService {
	rpc GetUser(UserSearchRequest) returns (User) {}
}

message UserSearchRequest {
	string id = 1;
}

message User {
	string _id = 1;
	int64 index = 2;
	bool isActive = 3;
	int32 age = 4;
	string name = 5;
	string gender = 6;
	string email = 7;
}

컴포넌트 정의 (gRPC 서비스)

@Service
public class UserServiceImpl extends UserServiceGrpc.UserServiceImplBase {
    private static final Logger logger = LoggerFactory.getLogger(UserServiceImpl.class);

    private final UserRepository userRepository;

    @Autowired
    public UserServiceImpl(UserRepository userRepository) {
        this.userRepository = userRepository;
    }

    @Override
    public void getUser(UserSearchRequest request, StreamObserver<User> responseObserver) {
        String requestId = request.getId();
        logger.info("requestId: {}", requestId);
        UserEntity entity = userRepository.findOne(requestId);

        responseObserver.onNext(buildUser(entity));
        responseObserver.onCompleted();
    }

    private User buildUser(UserEntity entity) {
        return User.newBuilder()
                .setId(entity.getId())
                .setIndex(entity.getIndex())
                .setIsActive(entity.getIsActive())
                .setAge(entity.getAge())
                .setName(entity.getName())
                .setGender(entity.getGender())
                .setEmail(entity.getEmail())
                .build();
    }
}

gRPC 서버 설정

@Configuration
public class GrpcServerConfiguration {

    @Value("${grpc.server.port}")
    private int grpcServerPort;

    @Bean
    public Server grpcServer(UserServiceImpl userService) {
        return ServerBuilder.forPort(grpcServerPort)
                .addService(userService)
                .build();
    }

}

Application 구동 시 gRPC 서버가 실행되도록 처리

@Component
public class GrpcServerRunner implements ApplicationRunner, DisposableBean {
    private static final Logger logger = LoggerFactory.getLogger(GrpcServerRunner.class);

    @Autowired
    private Server grpcServer;

    @Override
    public void run(ApplicationArguments args) throws Exception {
        grpcServer.start();

        logger.info("GrpcServer listening on port {}", grpcServer.getPort());

        grpcServer.awaitTermination();
    }
    
    @Override
    public void destroy() throws Exception {
        if (grpcServer != null) {
            grpcServer.shutdown();
        }
    }
}

gRPC Reference - 개요 및 특징

@deveely — Mon, 13 Jan 2020 03:16:44 +0900

1. gRPC 란

Protocol Buffer를 IDL (Interface Definition Language)로 사용하는 RPC 프레임워크
구글에서 10년 이상동안 MSA 아키텍쳐 이하 수많은 시스템들, 데이터 센터 간 통신을 위해 사용하던 범용 RPC 프레임워크인 Stubby를 오픈소스화해 공개한 것

1.1. RPC란?

RPC (Remote Procedure Call)은 별도의 원격제어 없이 프로세스간 함수나 프로시저를 호출할 수 있도록 하는 통신 기술
서로 통신하는 양 측의 Request, Response에 대한 인터페이스를 정의 후 양 측 프로그래밍 언어에 맞는 코드로 변환해야함.
이 때 인터페이스를 정의하는 용어는 IDL(Interface Definition Language)라 함
IDL이 컴파일러 등으로 특정 언어의 코드로 변환된 결과를 Skeleton (서버 측), Stub (클라이언트 측) 라 함

1.2. Protocol Buffer (ProtoBuf)

구글에서 개발한 데이터 직렬화 오픈소스로 gRPC의 IDL로 사용
직렬화하려는 데이터의 구조를 프로토 파일에 정의 (.proto)
ProtoBuf의 데이터는 message 들로 구성되며 각 message는 field (name, value pair) 로 구성

message Person {
  string name = 1;
  int32 id = 2;
  bool has_ponycopter = 3;
}

프로토 파일을 protoc(프로토콜 버퍼 컴파일러)로 원하는 언어에서 사용가능한 결과물로 컴파일하여 사용한다.

2. gRPC 의 특징

높은 생산성과 효율적인 유지보수
- 서비스와 메시지를 정의하기 위해 오직 ProtoBuf 만을 사용
다양한 언어와 플랫폼 지원

LanguagePlatformCompiler

C/C++	Linux/Mac	GCC 4.8+, Clang 3.3+
C/C++	Windows 7+	Visual Studio 2015+
C#	Linux/Mac	.NET Core, Mono 4+
C#	Windows 7+	.NET Core, .NET 4.5+
Dart	Windows/Linux/Mac	Dart 2.0+
Go	Windows/Linux/Mac	Go 1.6+
Java	Windows/Linux/Mac	JDK 8 recommended. Gingerbread+ for Android
Node.js	Windows/Linux/Mac	Node v4+
Objective-C	Mac OS X 10.11+/iOS 7.0+	Xcode 7.2+
PHP (Beta)	Linux/Mac	PHP 5.5+ and PHP 7.0+
Python	Windows/Linux/Mac	Python 2.7 and Python 3.4+
Ruby	Windows/Linux/Mac	Ruby 2.3+

HTTP/2 기반 통신
- gRPC 는 HTTP/2 기반 통신으로 기존 HTTP 과는 다르게 서버와 클라이언트가 서로 데이터를 스트리밍으로 주고 받을 수 있음
  - simple RPC : 클라이언트 요청에 서버가 응답하고 종료
  - server-side streaming RPC : 클라이언트 요청에 응답을 여러번 보냄
  - client-side streaming RPC : 클라이언트가 요청을 여러번 보내고, 요청이 끝나면 응답을 보냄
  - bidirectional streaming RPC : 양방향 독립적으로 요청/응답을 보냄
- 기존 HTTP 보다 높은 헤더 압축률이 보장되고, ProtoBuf의 직렬화에 의해 전송되는 메시지가 획기적으로 줄어듬

3. gRPC vs REST

Payload 의 차이
- gRPC는 Protobuf 형식 자체 직렬화된 데이터
- REST 는 JSON 데이터를 주고받음
HTTP 버전의 차이
- gRPC는 HTTP/2 기반 통신
- REST는 일반적으로 HTTP/1.1 통신
- 때문에 gRPC는 스트리밍, 헤더 압축 등 HTTP/2 의 여러 장점을 확보
호출방식의 차이
- gRPC는 proto파일에 정의한 message, service 를 각 언어에 필요한 형태로 generate됨. 클라이언트에서 service 메소드를 호출하면 그에 해당하는 서버에서 구현한 service가 실행되고, 요청/응답 페이로드는 언어에 맞게 generate 결과를 사용
- REST는 endpoint 를 HTTP Method + URI 로 표현하고, 페이로드 처리는 각 서버/클라이언트 측에서 각각 부담

4. gRPC의 활용

gRPC는 단일 인스턴스로 동작하는 CRUD 웹 애플리케이션에서 부터 수십 수백개의 인스턴스가 상호 작용하는 MSA 까지 모든 구조에서 사용 가능
클라이언트 측에 gRPC 스텁을 library 등으로 제공해줘야하는 부분은 존재하는등 몇 가지 한계점도 존재 -> 호출 인터페이스 측면에서 웹 환경에서 사용한다면 REST 방식에 비해 일부제약
gRPC Gateway 플러그인을 사용하면 gRPC 서비스에 REST API 인터페이스를 제공할 수 있게 go 런타임에서 작동하는 프록시 서버와 Swagger 문서를 generate 해준다. (go 이외 다른 언어는 미지원) 때문에 gRPC 서비스를 이용할 준비가 되지 않은 클라이언트의 경우나 웹 환경에서 사용 가능
https://github.com/wejrowski/grpc-gateway-java-gradle (Spring Boot gRPC + grpc-gateway 예시)
https://grpc-ecosystem.github.io/grpc-gateway/ (grpc-gateway 공식 문서)

Spring Ehcache 사용 간략한 정리

@deveely — Sun, 12 Jan 2020 02:12:58 +0900

1. Spring Cache Abstraction

https://docs.spring.io/spring-boot/docs/current/reference/html/boot-features-caching.html#boot-features-caching-provider

2. 적용2-1. @EnableCaching

Spring Boot Application 설정시 @EnableCaching 어노테이션 추가하여 Application에 캐시 기능 사용하겠다는 것을 알린다

@SpringBootApplication
@ComponentScan("com.nhnent.gia")
@EntityScan(basePackages = {"com.nhnent.gia.model"}, basePackageClasses = {Application.class, Jsr310JpaConverters.class})
@EnableCaching 
public class Application {
	public static void main(String[] args) {
		SpringApplication.run(Application.class, args);
	}
}

이후 추가적이 설정이 없는 경우 기본 캐시 ConcurrentHasnMap 를 사용하고, 다른 캐시 라이브러리를 추가하면 Spring Boot의 Auto Detect기능에 따라 해당 라이브러리를 자동으로 사용하게 된다.

2-2. ehcache.xml 작성

https://www.ehcache.org/documentation/2.8/configuration/configuration.html

<?xml version="1.0" encoding="UTF-8"?>
<ehcache xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
         xsi:noNamespaceSchemaLocation="http://www.ehcache.org/ehcache.xsd"
         updateCheck="true"
         moritoring="autodetect"
         dynamicConfig="true"
         maxBytesLocalHeap="4M">
    
	<cache name="recentWinHistory"
                eternal="false"
                timeToIdleSeconds="0"
                timeToLiveSeconds="300"
                overflowToDisk="false"
                diskPersistent="false"
                diskExpiryThreadIntervalSeconds="120"
                memoryStoreEvictionPolicy="LRU">
	</cache>
</ehcache>

2-3. application.properties추가

캐시 설정파일 ehcache.xml 경로 설정

spring.cache.ehcache.config=classpath:ehcache.xml

2-4. @Cacheable

ehcache.xml에서 정의한 캐시를 @Cacheable("{name}") 형태로 적용

기본

@Cacheable("recentWinHistory")
List<WinHistory> findAllWinHistory(Integer eventCode, Integer eventNo);

파라미터별로 캐싱하고 싶은 경우 캐시가 eventCode값 단위로 캐싱된다

@Cacheable("recentWinHistory", key="#eventCode")
List<WinHistory> findAllWinHistory(Integer eventCode, Integer eventNo);

저자 블로그, git 정보

@deveely — Tue, 24 Dec 2019 09:36:40 +0900

Github: https://github.com/hyungyu-lee

개츠비 블로그: https://deveely-log.netlify.app/

mac terminal 에서 특정 프로젝트를 vscode 또는 IntelliJ 실행하기

@deveely — Sat, 21 Dec 2019 17:08:07 +0900

mac 사용하다 보면 ide에서 Finder UI를 통해 특정 프로젝트를 open 하는 일이 자주 있는데요. 저의 경우 vscode와 IntelliJ에서 그런 경우가 자주 있는 편입니다.

특정 프로젝트를 vscode로 실행하기

vscode 의 경우 아주 간단합니다. 터미널에서 프로젝트 경로로 이동한 후 code . 명령어를 입력하면 해당 프로젝트 open으로 vscode가 실행됩니다.

cd 프로젝트경로
code .

특정 프로젝트를 IntelliJ로 실행하기

IntelliJ의 경우도 vscode와 유사하지만 1가지 차이점이 있습니다. IntelliJ 실행 시 사용하는 idea 명령어가 있는 경로가 환경변수에 등록되어 있지 않기 때문인데요. 이는 IntelliJ에서 간단히 추가가 가능합니다. IntelliJ를 실행 후 Tools > Create Command-line Launcher... 메뉴를 클릭하면 터미널에서 idea명령어를 바로 사용할 수 있게됩니다.

명령어를 환경변수에 추가한 후 실행할 프로젝트로 이동해 아래 명령어를 입력하면 해당 프로젝트 open 으로 IntelliJ가 실행되게 됩니다. 아래 예시의 경우 제가 실행할 프로젝트가 maven 프로젝트여서 pom.xml을 대상 파일로 지정했구요. gradle이면 build.gradle 등 다른 타입의 프로젝트는 해당하는 파일을 지정하면 됩니다.

cd 프로젝트경로
idea pom.xml

git commit 날짜, author 변경하기

@deveely — Sat, 21 Dec 2019 17:01:46 +0900

git을 사용하면 거의 대부분 원격 저장소로 github을 많이 이용합니다. github엔 저장소에 commit 내역을 시각화하여 보여주는 기능(잔디밭..)이 있는데요. 가끔 실수로 날짜를 못지키거나, author를 잘못지정해 색칠이 안되는 경우가 있습니다. 잔디밭에 신경을 쓰시는 분이라면 빈 구멍이 굉장히 신경이 쓰이실수 있는데요. 이 때 사용할 수 있는 방법을 공유합니다.

git commit 변경

꼭 잔디밭이 아니더라도 commit의 날짜를 변경해야하는 경우는 종종 있을것입니다.

기본적으로 commit 변경은 변경할 commit을 찾는것에서 시작합니다.

1. commit 히스토리 확인

git log

git log 명령어를 실행하면 아래와 같이 commit 히스토리를 확인할 수 있습니다. 아래 내역에서 수정하고싶은 commit의 직전 commit의 해쉬값을 복사합니다. 이 예시에서 저는 책 목차 추가 커밋을 수정하기 위해 그 아래 커밋인 65068f594d469e848beab5fd475219f428339436값을 사용하겠습니다. log 명령 결과화면에서 q를 입력하면 화면이 종료됩니다.

commit 5b52b3874068dfd0b1f77023eac03113f3b6db9a
Author: HyunGyu-Lee <gusrb0808@naver.com>
Date:   Mon Dec 9 00:32:41 2019 +0900

    컨텐츠 추가(DDD Start!)

commit 0c6be06e2ede8cac5bc1b78b511620583e159bf5
Author: HyunGyu-Lee <gusrb0808@naver.com>
Date:   Fri Nov 8 13:35:32 2019 +0900

    책 목차 추가

commit 65068f594d469e848beab5fd475219f428339436
Author: HyunGyu-Lee <gusrb0808@naver.com>
Date:   Tue Nov 5 01:01:48 2019 +0900

    collapse 태그 인식 불가 분제 fix

2. 날짜/author 변경

해쉬값을 확인한 후 git rebase 명령을 입력합니다.

git rebase -i 65068f594d469e848beab5fd475219f428339436

그럼 아래와 같은 UI가 나오는데요. 변경할 대상 커밋의 커멘드를 edit으로 변경하고 저장합니다. (vi)

자세한 커멘드는 아래 주석에 적혀있습니다.

edit 0c6be06 책 목차 추가
pick 5b52b38 컨텐츠 추가(DDD Start!)

# Rebase 65068f5..d896625 onto 65068f5 (4 commands)
#
# Commands:
# p, pick <commit> = use commit
# r, reword <commit> = use commit, but edit the commit message
# e, edit <commit> = use commit, but stop for amending
# s, squash <commit> = use commit, but meld into previous commit
# f, fixup <commit> = like "squash", but discard this commit's log message
# x, exec <command> = run command (the rest of the line) using shell
# b, break = stop here (continue rebase later with 'git rebase --continue')
# d, drop <commit> = remove commit
# l, label <label> = label current HEAD with a name
# t, reset <label> = reset HEAD to a label
# m, merge [-C <commit> | -c <commit>] <label> [# <oneline>]
# .       create a merge commit using the original merge commit's
# .       message (or the oneline, if no original merge commit was
# .       specified). Use -c <commit> to reword the commit message.
#
# These lines can be re-ordered; they are executed from top to bottom.
#
# If you remove a line here THAT COMMIT WILL BE LOST.
#
# However, if you remove everything, the rebase will be aborted.
#
# Note that empty commits are commented out

그럼 다음과 같이 rebase 모드에 진입하게 되고 해당 커밋으로 이동하게됩니다. 수정을 하려면 git commit --amend를 수정하지 않고 넘어가려면 git rebase --continue를 입력하면 됩니다.

>> git rebase -i 65068f594d469e848beab5fd475219f428339436
Stopped at 0c6be06...  책 목차 추가
You can amend the commit now, with

  git commit --amend

Once you are satisfied with your changes, run

  git rebase --continue
>>

변경할 커밋에서 amend 를 통해 author 혹은 날짜를 수정하면 됩니다.

# 날짜 변경
GIT_COMMITTER_DATE="{날짜}" git commit --amend --no-edit --date "{날짜}"

# author 변경
git commit --amend --author "username <email>"

그다음 아까 언급한것처럼 수정을 하려면 git commit --amend를 수정하지 않고 넘어가려면 git rebase --continue를 입력하면 되고, 더 이상 수정할 것이 없으면 rebase 모드가 종료되게 됩니다. 수정을 마치고 push 하여 마무리 해주면 github에도 반영되게 됩니다.

NHN FORWARD 2019 후기

@deveely — Mon, 16 Dec 2019 10:33:27 +0900

NHN Forward 2019 컨퍼런스 참여 후기입니다.

NHN Forward 2019

지난 11월 27일 NHN Forward 2019 컨퍼런스에 참가했습니다. 회사가 회사다 보니 다양한 컨텐츠들이 준비되어 있었는데요. 크게 아래와 같았습니다.

세션
1. 발표세션
2. 스몰 스텝
3. 프런트엔드 상담소
4. 커뮤니티 라운지
워크숍
핸즈온 랩

프론트엔드 전문 개발자분들이 직접 고민을 들어주고 대화를 할 수 있는 프런트엔드 상담소나 평소에 궁금했거나 해보고 싶었던 것들을 쉽게 따라해보고 경혐해 볼 수 있었던 핸즈온 랩 등 준비를 정말 많이 했다는 느낌이 들었습니다.

특히 발표세션에서는 실무에서 겪을수 있는 문제점들이나 겪었던 문제들을 사례를 많이 공유받을수 있어 유익한 시간이었습니다.

발표세션은 총 7개 트랙에서 시간대별로 각각 강의가 주로 진행되었는데요. 저는 아래와 같이 세션을 참여했습니다.

발표세션

1. ‘깃’깔나는 Git 워크 플로우 알아보기

개발에 필수인 깃을 더 잘 쓰는 방법에 대해 사례를 통해 들을 수 있었습니다. 특히 전 GitFlow 이외에 깃헙 플로우, 깃랩 플로우가 있는 거는 처음알았습니다.

깃 플로우: 메인브랜치(master / develop)와 서포팅프랜치 (feature, release, hotfix) 을 활용한 깃 워크플로
깃헙 플로우: 깃 플로우가 대부분의 케이스에서 갖는 복잡함을 해소하고자 master / topic 브랜치를 활용해 간단하지만 강력한 워크플로
깃랩 플로우: 깃 플로우는 너무 복잡하고, 깃헙 플로우는 너무 단순하다. 절충안을 제안

2. DDD-Lite@Spring

NHN의 서비스 중 Dooray! 의 위키 서비스를 사례로 애플리케이션의 복잡함으로 고통받는 개발자들을 위해 DDD를 소개하고, 어떻게 복잡함을 극복할 수 있는지 소개했습니다.

DDD에서 모델링 시 속성보다는 행위가 우선이다.
속성은 어떤 행위를 할 때 필요하면 그 때 추가한다.
JPA로 생각해보면 바로 양방향 매핑을 하지 않고 우선 단방향 매핑을 하고 필요 시 추가로 양방향 매핑을 한다.
도메인 모델을 풍부하게 만들어준다. (Rich Domain Model)
여러 변 연산을 적용해도 그 결과가 달라지지 않는 성질, 멱등성을 유지하도록 설계한다.
헥사고날 아키텍쳐

3. 레거시 웹 서비스 길들이기: 서버 개발자의 SPA 적용기

저 또한 Spring 기반 웹 백엔드 애플리케이션을 만드는 개발자 다 보니 이 세션에서 소개해주신 사례들이 하나하나가 공감가는 사례들이었습니다. 제가 평소에 겪었던 고민들에 대한 해결책을 들을수있어 좋았습니다.

적용하기전의 고민 / 적용하면서의 고민 / 현재 팀의 상황 / 효율적인 빌드를 위한 프로젝트 구성 / API 호출 방식 with Zuul /상태관리 / 다국어처리

4. Spring JPA의 사실과 오해

Spring JPA에 평소에 잘 알려지지 않은 사실들과 오해들을 소개해주셨습니다.

연관관계: 대부분의 경우는 단방향 매핑이 간단, 하지만 영속성 전이를 사용하는 경우 양방향 매핑을 사용하자 (추가 update 쿼리 방지)
JpaRepository에 대한 사실
- JpaRepository를 상속하는 것만으로도 대부분의 왠만한 기능을 사용할 수 있다.
- JpaRepository로도 JOIN이 가능하다.
- JpaRepository로도 다양한 DTO Projection이 가능하다.

5. Paas & API Experience: 좋은 API DX를 제공하기 위한 작은 걸음

마치며

NHN Forward 2019의 심볼인 » 는 리달리디렉션 기호 »를 형상화한 것으로 지식과 경험을 더하고 쌓을 수 있기를 바라는 마음을 담았다고 합니다.

이런 NHN의 의지만큼 많은 것을 경험하고, 배우고, 즐거웠던 1분 1초가 아깝지 않은 시간이었습니다.

감사합니다.