Kim-Baek 개발자 이야기

Spring WebClient는 Spring WebFlux에서 제공하는 비동기 및 논블로킹 HTTP 클라이언트로, 다른 서비스나 API와 통신할 때 사용됩니다. 이전에 사용되던 RestTemplate의 대안이며, 리액티브 프로그래밍을 지원하여 더 나은 성능과 유연성을 제공합니다.---1. WebClient 특징비동기/논블로킹: 요청과 응답이 블로킹 없이 처리됩니다.리액티브 스트림 지원: Mono와 Flux를 반환하여 리액티브 방식으로 데이터를 처리합니다.RestTemplate의 대안: Spring 5 이상에서는 WebClient를 추천합니다.동기식 호출 가능: 원한다면 동기식으로도 호출할 수 있습니다.---2. WebClient 생성WebClient는 크게 두 가지 방식으로 생성할 수 있습니다:1. 빌더..

프로듀서(Producer) 모듈과 컨슈머(Consumer) 모듈을 분리하고, 이들 간의 통신을 RabbitMQ와 같은 메시지 브로커를 통해 처리하는 아키텍처는 마이크로서비스 아키텍처나 이벤트 기반 아키텍처에서 자주 채택되는 패턴입니다. 이러한 구조는 시스템의 유연성, 확장성, 신뢰성을 높이기 위해 다양한 상황에서 유용하게 사용될 수 있습니다. 아래에서는 이 구조가 언제, 왜 유용한지에 대해 자세히 설명하겠습니다.1. 프로듀서-컨슈머 아키텍처란?프로듀서-컨슈머 아키텍처는 비동기 메시징을 기반으로 하는 아키텍처 패턴으로, 한쪽(프로듀서)이 메시지를 생성하여 메시지 큐(예: RabbitMQ)에 발행하고, 다른 쪽(컨슈머)이 이를 구독하여 처리합니다. 이때 프로듀서와 컨슈머는 직접적으로 연결되지 않고, 메시지 ..

Write-Behind Caching(쓰기 후방 캐싱)은 **캐시(Cache)**와 영속 저장소(Persistent Storage) 간의 데이터 동기화 방식을 나타내는 개념 중 하나입니다. 이 방식은 데이터가 먼저 캐시에 기록되고, 나중에 비동기적으로 영속 저장소에 반영되는 방식을 의미합니다. 반대로, Write-Through Caching(쓰기 직전 캐싱)은 데이터가 캐시와 영속 저장소에 동시에 동기적으로 기록되는 방식을 말합니다.아래에서 Write-Behind Caching의 개념, 작동 방식, 장단점, 그리고 사용 사례에 대해 자세히 설명드리겠습니다.1. Write-Behind Caching의 개념Write-Behind Caching은 애플리케이션이 데이터를 캐시에 쓰면, 이 데이터 변경 사항을 즉..

1. SLF4J와 Logback의 개요a. SLF4J (Simple Logging Facade for Java)정의: SLF4J는 다양한 로깅 프레임워크에 대한 추상화 계층을 제공하는 로깅 파사드(Facade)입니다.역할: 애플리케이션 코드에서 직접 특정 로깅 프레임워크에 의존하지 않고, SLF4J API를 통해 로깅을 수행하도록 합니다. 이를 통해 로깅 구현체를 쉽게 교체하거나 변경할 수 있습니다.장점:유연성: 여러 로깅 프레임워크(Log4j, Logback, java.util.logging 등)와 독립적으로 사용할 수 있습니다.일관된 API: 다양한 로깅 프레임워크에 대해 일관된 로깅 API를 제공합니다.성능 최적화: 메시지 포맷 시점에서 실제 로깅 여부를 검사하여 불필요한 문자열 연산을 방지합니다...

1. Spring WebFlux란?Spring WebFlux는 Spring Framework 5에서 도입된 논블로킹(Non-blocking) 및 리액티브(Reactive) 프로그래밍을 지원하는 웹 프레임워크입니다. 기존의 Spring MVC가 서블릿 기반의 동기(Blocking) 모델을 사용한다면, WebFlux는 논블로킹 처리를 통해 더 높은 확장성과 성능을 제공합니다.주요 특징:논블로킹 I/O: 요청 처리 동안 스레드가 블로킹되지 않습니다.리액티브 스트림: 데이터 스트림을 비동기적으로 처리합니다.함수형 라우팅: 함수형 프로그래밍 방식을 사용한 라우팅 지원.다양한 런타임 지원: Netty, Undertow 등 서블릿 컨테이너가 아닌 서버에서도 실행 가능.2. Spring MVC와의 차이점Spring M..

1. Quartz란?1.1. Quartz 소개Quartz는 오픈 소스 스케줄링 라이브러리로, 복잡한 스케줄링 작업을 간편하게 구현할 수 있도록 도와줍니다. 주기적인 작업 실행, 일정한 간격으로 작업 실행, 특정 시간에 작업 실행 등 다양한 방식으로 작업을 스케줄링할 수 있습니다.1.2. 주요 기능다양한 트리거 지원: Cron 트리거, Simple 트리거 등 다양한 트리거 유형을 지원하여 유연한 스케줄링이 가능합니다.작업 지속성: 작업(Job)과 트리거(Trigger)를 데이터베이스에 저장하여 애플리케이션 재시작 후에도 스케줄이 유지됩니다.클러스터링 지원: 여러 인스턴스에서 Quartz를 클러스터링하여 고가용성을 구현할 수 있습니다.잡 리스너 및 트리거 리스너: 작업 실행 전후에 특정 로직을 실행할 수 있..

JPA(Java Persistence API)를 사용하면서 종종 마주하게 되는 N+1 문제에 대해 친절하고 상세하게 설명드리겠습니다. 이 문제는 특히 성능 최적화가 중요한 애플리케이션에서 자주 언급되며, 이해하고 해결하는 것이 중요한 부분입니다.📌 N+1 문제란?N+1 문제는 데이터베이스에 접근할 때 발생하는 성능 이슈 가운데 하나로, 주로 ORM(Object-Relational Mapping) 프레임워크를 사용할 때 나타납니다. 이 문제는 다음과 같은 형태로 발생합니다:N개의 쿼리 + 1개의 메인 쿼리가 실행됩니다.즉, 첫 번째 메인 쿼리가 실행된 후, 각 결과에 대해 추가적인 N개의 쿼리가 발생하게 됩니다.이로 인해 데이터베이스에 불필요하게 많은 요청이 발생하고, 애플리케이션의 성능이 저하될 수 있..

Apache Kafka는 고성능, 분산형 이벤트 스트리밍 플랫폼으로, 대규모 데이터 스트림을 실시간으로 처리하고 관리할 수 있게 해줍니다. Kafka는 원래 LinkedIn에서 내부 메시징 시스템으로 개발되었으며, 현재는 오픈 소스로 제공되어 다양한 애플리케이션에서 널리 사용되고 있습니다.주요 특징높은 처리량: 수백 메가바이트에서 기가바이트 단위의 데이터를 초당 처리할 수 있습니다.확장성: 클러스터 규모를 손쉽게 확장할 수 있어 대규모 데이터 스트림을 처리할 수 있습니다.내결함성: 데이터 복제와 분산 저장을 통해 장애 발생 시에도 데이터 손실 없이 안정적으로 운영됩니다.실시간 처리: 실시간으로 데이터를 생산하고 소비할 수 있어, 실시간 분석 및 모니터링에 적합합니다.다양한 사용 사례: 로그 수집, 실시간..

레빗엠큐란? **레빗엠큐(RabbitMQ)**는 메시지 브로커의 한 종류로, 애플리케이션 간의 비동기 통신을 가능하게 하는 오픈 소스 소프트웨어입니다. 다양한 프로그래밍 언어를 지원하며, 분산 시스템에서 데이터를 안정적으로 전달하는 데 사용됩니다. 왜 레빗엠큐를 사용할까요? * 비동기 처리: 작업 처리 시간이 오래 걸리는 경우, 메시지를 큐에 넣고 다른 작업을 수행할 수 있습니다. * 시스템 분리: 애플리케이션 간의 의존성을 줄이고, 각 애플리케이션이 독립적으로 작동할 수 있도록 합니다. * 확장성: 시스템 부하가 증가하더라도 메시지 큐를 추가하여 시스템 성능을 향상시킬 수 있습니다. * 데이터 전달 보장: 메시지가 손실되지 않도록 다양한 메커니즘을 제공합니다. 레빗엠큐의 주요 개념 * Producer:..

Spring Cloud Config란?Spring Cloud Config는 마이크로서비스 아키텍처에서 애플리케이션의 설정을 외부에서 관리할 수 있도록 도와주는 구성 관리 솔루션입니다. 이를 통해 다양한 환경(개발, 테스트, 운영 등)에서 애플리케이션 설정을 중앙에서 관리하고 배포할 수 있습니다.주요 특징외부 구성 관리: 애플리케이션의 설정 파일(application.properties, application.yml 등)을 Git, SVN, 파일 시스템 등 외부 저장소에 저장하여 중앙에서 관리할 수 있습니다.환경별 설정: 각 서비스와 환경에 맞는 별도의 설정을 쉽게 관리할 수 있습니다. 예를 들어, 개발 환경과 운영 환경에서 다른 데이터베이스 설정을 적용할 수 있습니다.버전 관리: Git과 같은 버전 관리..

Quartz는 자바 기반의 오픈 소스 스케줄링 라이브러리로, 복잡한 작업 스케줄링을 손쉽게 구현할 수 있도록 도와줍니다. Spring Quartz는 Quartz Scheduler를 Spring 프레임워크와 통합하여 보다 간편하게 사용할 수 있게 한 모듈입니다. 이를 통해 애플리케이션 내에서 정기적이거나 특정 조건에 따른 작업 실행을 효율적으로 관리할 수 있습니다.주요기능잡(Job) 정의 및 실행:Job 인터페이스를 구현하여 실행할 작업을 정의.특정 시간 또는 간격에 따라 잡을 실행할 수 있음.트리거(Trigger) 설정:작업의 실행 시점을 제어하는 트리거를 설정.간단한 간격 기반 트리거(SimpleTrigger)와 복잡한 크론 표현식을 사용하는 크론 트리거(CronTrigger) 지원.스케줄링 관리:잡의..

김영한님의 [스프링 핵심 원리] 강의를 정리하고, 내가 생각한 내용까지 정리하는 포스팅 지난번에는 컨테이너에 등록된 모든 빈을 조회해보았다. 이번에는 하나의 빈을 조회하는 방법들에 대해서 기본적으로 사용되는 방식들에 대해서 알아볼 수 있도록 하겠다. 먼저 이전과 동일하게 스프링 컨테이너인 ApplicationContext의 구현체를 만들어서 빈을 가져오게 된다. 줄여서 ac 라고 사용할 수 있도록 하겠다. ac 에서 빈을 가져오는 메소드에 대해서 알아보겠다. ac.getBean ( 빈이름, 타입 ) ac.getBean ( 타입 ) 위의 두 가지 방식으로 빈을 가져올 수 있는데, 상황에 맞게 본인이 필요한 것을 쓰면 되겠다. 그런데 조회 대상의 스프링 빈이 없으면 어떻게 될까? NoSuchBeanDefin..

김영한님의 [스프링 핵심 원리] 강의를 정리하고, 내가 생각한 내용까지 정리하는 포스팅 지난번에 스프링을 사용해서 빈을 어떻게 등록하는지 알게되었습니다. 실제로 등록이 되었다고는 하는데, 정말 등록이 된게 맞는지 직접 확인을 해볼 필요가 있습니다. 그래서 컨테이너에 등록된 빈을 한번 조회해보도록 하겠습니다. package core.order.beanfind; import core.order.AppConfig; import org.junit.jupiter.api.DisplayName; import org.junit.jupiter.api.Test; import org.springframework.beans.factory.config.BeanDefinition; import org.springframework..

김영한님의 [스프링 핵심 원리] 강의를 정리하고, 내가 생각한 내용까지 정리하는 포스팅 이전에 AppConfig를 스프링으로 전환하는 과정을 진행했다. 스프링 컨테이너가 이제 그 역할을 해주는 것이라고 설명을 하였는데, 이번에는 스프링 컨테이너가 생성되는 과정을 한번 살펴보고자 한다. ApplicationContext applicationContext = new AnnotationConfigApplicationContext(AppConfig.class); ApplicationContext 를 우리는 스프링 컨테이너라고 한다. ApplicationContext 는 인터페이스이다. 그 말은 여러가지 구현체를 사용할 수 있다는 뜻이다. 스프링 컨테이너는 XML을 기반으로 할 수도 있고, 애노테이션 기반의 자바..

김영한님의 [스프링 핵심 원리] 강의를 정리하고, 내가 생각한 내용까지 정리하는 포스팅 지금까지 강의의 내용은 순수하게 자바만 사용해서 하는 것이였다. 그렇다면 스프링을 사용하면 어떤 좋은 점이 있는지를 알아야 하지 않을까? 이번부터 지금까지 생성한 내용을 스프링으로 변경하면서 진행을 하게 된다. 먼저 AppConfig를 스프링 기반으로 변경한다. package core.order; import core.order.discount.DiscountPolicy; import core.order.discount.RateDiscountPolicy; import core.order.member.MemberRepository; import core.order.member.MemberService; import co..

김영한님의 [스프링 핵심 원리] 강의를 정리하고, 내가 생각한 내용까지 정리하는 포스팅 이번에는 IoC와 DI, 컨테이너에 대해서 설명을 한다. 스프링을 하는 사람들은 다들 많이 들어본 내용일텐데, IoC, DI, AOP까지 해서 스프링 관련된 중요한 개념이라고 생각된다. 어려운 내용은 아니고 지금까지 우리가 강의를 통해서 해왔던 내용들이 다 여기에 담겨있어서 어떤 내용들과 매칭되는지 다시한번 기억을 되살려서 살펴보도록 하자. 제어의 역전 IoC ( Inversion of Control ) 우선 제어의 역전을 알아보기 전에 기존 프로그램의 동작과정을 살펴보도록 하자 클라이언트가 필요한 서버 구현 객체를 생성하고, 연결하고 실행했다. 구현 객체가 프로그램의 제어 흐름을 스스로 조종했다. 일반적으로 이게 개..

김영한님의 [스프링 핵심 원리] 강의를 정리하고, 내가 생각한 내용까지 정리하는 포스팅 지금까지 만들어오면서 적용한 객체 지향 설계의 원칙에 대해서 살펴보고자 한다. 객체 지향 설계의 5가지 원칙은 이전에 작성한 글에도 잘 정리가 되어있으니 생각이 나지 않는다면 해당 내용을 다시한번 보는 것을 권장한다. 1. SRP ( 단일 책임 원칙 ) - 한 클래스는 하나의 책임만 가져야 한다는 원칙이다. 우리가 처음에 만들었던 클라이언트 객체는 직접 구현 객체를 생성하고, 연결하고 실행까지 하는 다양한 첵임을 가지고 있었다. SRP 원칙에 따라서 관심사를 분리하게 된다. 더 이상 클라이언트는 구현 객체를 생성하거나 연결하지 않고, AppConfig 가 해당 역할을 담당하게 된다 클라이언트 객체는 실행하는 책임만 담..

김영한님의 [스프링 핵심 원리] 강의를 정리하고, 내가 생각한 내용까지 정리하는 포스팅 이제는 이전에 해보려고 했었던 할인 정책을 변경을 해보고자 한다. 기존에는 정액 할인 정책을 사용하여 어떤 주문이 들어오더라도 1000원만큼만 할인이 이루어졌다. 바꾸려고 하는 것은 정률 할인 정책으로 주문가격의 10%를 할인해주는 정책이다. FixDiscountPolicy -> RateDiscountPolicy 로 변경을 하게 되는데 이제 어떤 부분을 바꿔주면 되는지 살펴보자. 우리는 AppConfig를 만들게 되면서 애플리케이션이 실제 로직이 수행되는 사용 영역과 객체를 생성하고 구성(Configuration)하는 영역으로 분리되었다. 현재 애플리케이션의 구조는 이와 같은 상태라고 할 수 있다. 그렇다면 할인정책은..

김영한님의 [스프링 핵심 원리] 강의를 정리하고, 내가 생각한 내용까지 정리하는 포스팅 지난번에 AppConfig를 만들어서 관심사를 분리해서, 각자 역할들이 본인들의 역할의 수행에만 집중할 수 있는 코드를 완성했다. 그런데 다시한번 보면 AppConfig가 중복이 있고, 역할에 따른 구현이 잘 안보이는 문제가 있다. 우리가 원하는 그림은 이런 것 일 것이다. 역할이 있고 구현 객체들이 어떤 것인지 명확하게 보이는 그림이다. package core.order; import core.order.discount.FixDiscountPolicy; import core.order.member.MemberService; import core.order.member.MemberServiceImpl; import c..

김영한님의 [스프링 핵심 원리] 강의를 정리하고, 내가 생각한 내용까지 정리하는 포스팅 다시 처음으로 돌아가서 한번 생각을 해보자. 공연에서 각각 인터페이스는 배역이라고 할 수 있다. 그렇다면 이 배역을 연기하는 배우는 누가 선택을 하게 되는게 맞을까? 현재까지 작성한 코드는 로미오와 줄리엣이라는 공연에서, 로미오 역할을 하는 배우인 레오나르도 디카프리오 ( 구현체, 배우 ) 가 줄리엣 역할을 하는 여자 주인공 ( 구현체, 배우 )를 직접 캐스팅하는 것과 마찬가지인 내용이다. 디카프리오는 직접 공연도 하고, 여자 주인공도 캐스팅하는 다양한 역할을 하고 있는 셈이다. 관심사의 분리 - 배우는 자신이 맡은 배역을 수행하는 역할만 수행하는 데 집중하는 것이 맞다. - 디카프리오는 상대 여자 주인공이 어떤 사람..