스프링의 순환참조 상황을 알아보자📌 서론스프링으로 개발을 하다 보면 정말 가끔씩 발생하는 오류가 있다. 바로 circular references (순환참조)다.스프링 빈을 등록하면서 2가지의 클래스가 서로를 의존하면 이러한 문제가 발생한다. 서버가 실행되면 스프링 컨테이너가 빈을 등록하는 과정에서 의존성 주입을 하는데 이 과정에서 서로 의존하는 두 빈이 서로를 기다리며 무한루프에 빠지게 되는 것이다.순환참조라는 이름만 봐도 순환해서 참조한다는 의미이므로 생각해 보면 간단하게 한쪽의 참조만 끊어주면 해결될 것으로 보인다. 그러나 가끔은 서로의 로직을 사용해야 하는 경우가 있을 수도 있다. 이때는 어떻게 문제를 해결해야 할까?  이런 상황에 문제를 해결하는 여러 가지 방법이 존재한다. 1. @Lazy 어노..

스프링부트 3.x.x에 gRPC 예외 처리 인터셉터를 적용시켜 보자📌 서론저번 포스트에서 SpringBoot3.3.1에 gRPC를 적용시켰다. 완전히 최신 버전을 사용해보고자 했기에 java, gradle, protobuf, spring 버전에 따른 오류도 조금씩 있었는데 아직 이 부분은 조금씩 진행하면서 코드를 개선하는 중이다. (계속 업데이트해서 올릴 예정)이번 포스트에서 소개할 내용은 gRPC의 예외처리 방법이다. http에서는 예외가 발생하면 @RestControllerAdvice를 사용해서 전역 예외처리를 하곤 한다. 그럼 gRPC도 예외처리를 하는 방법이 있지 않을까? 당연히 예외처리가 가능하다.검색을 해보니 SpringBoot에서는 gRPC의 예외처리를 인터셉터를 통해 처리한다는 것을 알아..

SpringBoot3.3.1에 gRPC를 적용시켜 보자📌 서론이번 포스팅보다 더 자세한 글을 적어둔 링크를 새롭게 적어두었습니다! gRPC 서버 구성, gRPC 클라이언트 구성, gRPC 인터셉터로 인증 구현, feign vs gRPC, 서킷 브레이커 적용 등 MSA를 구성하는데 필요한 정보들을 적어둔 링크입니다.예시 프로젝트는 아래의 github에 만들어 두었습니다. (편하게 사용해 주시면 됩니다.) GitHub - wlsdks/grpc-demo: SpringBoot3.x.x 버전 grpc 사용 예제 프로젝트SpringBoot3.x.x 버전 grpc 사용 예제 프로젝트. Contribute to wlsdks/grpc-demo development by creating an account on GitH..

개발중 동시성 문제를 해결하기 위해 lock을 걸곤 한다. 이때 synchronized를 잘못된 위치에 사용하면 lock이 제대로 걸리지 않으니 주의하자.📌 서론자바와 스프링으로 서버를 개발하다 보면 synchronized를 사용해서 lock을 걸어본 경험이 있을 것이다.또한 스프링 내부를 뜯어보다 보면 종종 synchronized를 사용한 코드들이 보인다. 나는 이것들에 대해 크게 신경 쓰지 않고 있었는데 이번에 인강으로 동시성 문제에 대한 공부를 하던 도중 새롭게 알게 된 사실이 있다. 바로 synchronized는 트랜잭션이 걸린 서비스 코드가 아닌 이 서비스 코드를 호출하는 컨트롤러에 걸어줘야만 동기화가 제대로 동작한다는 것이다.지금부터 코드를 통해 왜 서비스에서 synchronized를 적용시..

코틀린 스프링에서 Spring Validation을 적용하기 위해서는 꼭 알아둬야 할 것이 있다.📌 서론코틀린 스프링으로 개발하던 도중 독특한 문제를 만났다.프로젝트에 spring validation을 적용시켜 requestDto의 유효성을 검증하도록 설계했다. 왜냐하면 코틀린이 null safe 한 언어라지만 클라이언트 측에서 보내는 데이터까지 모두 컨트롤할 수 없기 때문에 클라이언트 요청을 바로 validation으로 검증하여 데이터의 무결성을 보장하고자 했다.  그래서 나는 검증하고자 하는 DTO 필드에 @NotBlank 어노테이션을 적어줬고 HTTPie(Postman)을 사용해 validation을 적용한 필드에 값을 넣지 않고 api요청을 보내봤다. (일부로 오류를 발생시키기 위함) 근데.....

JIB를 사용하여 Docker 이미지를 빌드해 보자📌 서론이전 포스트에서 Dockerfile을 사용하여 Image를 빌드했다.근데 이미지의 용량을 봤는데 400MB가 넘어가는 것을 확인했다. 이런 이미지의 용량을 보고 최적화를 해보고 싶어 졌고 바로 이미지의 용량 최적화 방법을 알아봤다. 열심히 검색하며 알아보던 도중 JIB라는 것이 존재한다는 것을 알게 되었고 바로 적용시켜 봤다.이번 포스트에서는 스프링 부트에서 JIB를 사용하여 Docker 이미지를 빌드하고 DockerHub에 저장해 볼 예정이다. 또한 이 과정을 통해 이미지의 용량이 얼마나 최적화가 되었는지 알아볼 것이다.이전 포스트 확인하기 [Docker] 단일 단계 빌드 vs 다단계 빌드Docker에서 단일 빌드와 다단계 빌드의 차이점을 알아..

M1에서 k8s 환경을 구성하고 k8s dashboard까지 세팅해 보자📌 서론최근 새로운 회사로 이직한 후 회사 적응에 집중하기로 정하여 한동안 글을 작성하지 못했습니다.한 달쯤 지난 지금 그동안 스스로의 미래에 대해 많은 생각과 고민을 했으며 저는 개발, DevOps를 모두 해보고 싶다는 생각이 들어 다시 개인 공부를 시작했습니다.그래서 이 모든 것을 할 수 있는 개인 프로젝트를 하나 만들었고 이 프로젝트의 로컬 인프라 구성을 k8s로 정했습니다. 이번 포스트는 제가 Apple silicon chip 맥북(M2 max)에서 k8s를 설치한 후 k8s 대시보드까지 세팅해 보는 과정을 설명하고자 합니다. 이 과정 중 많은 블로그들을 확인했지만 그중 한 블로그의 도움을 많이 받았으며 저는 그 과정을 그대..

예외가 발생하면 stackTrace는 어떻게 생성될까?📌 서론 RuntimeException이 발생했을 때 (우리가 주로 커스텀 예외를 만들 때도 RuntimeException을 던진다.)우리 개발자들은 예외가 발생하면 로그창에서 stackTrace 로그 내용을 분석하며 쉽게 오류사항을 찾아내곤 한다.스프링은 발생하는 예외를 어떻게 처리하고 stackTrace에 그 내용을 남기는 걸까?이번 포스트에서는 직접 RuntimeException 예외를 발생시키고 이 예외를 처리하는 코드를 따라가 보며 최종적으로 stackTrace를 만들어주는 코드를 분석해 보도록 하자. 이렇게 코드 분석을 따라가다 보면 알게 되는 점은 다음과 같을 것이다.1. RuntimeException은 어떻게 처리되는가 (예외처리 코드..

Spring Event 스레드의 동작원리를 이해해 보자 📌 서론 스프링 이벤트(Application Events)는 기본적으로 발행자(publisher)와 리스너(listener)가 같은 스레드에서 동작한다. 즉, 이벤트를 발행하는 메서드를 호출하면 그 호출을 처리하는 스레드가 이벤트 리스너도 처리하는 것이 기본 동작이다. 이번 포스트에서는 스프링 이벤트와 스레드의 동작 방식을 자세히 알아보자 1. 스프링 이벤트와 스레드 동작 방식 (1개의 이벤트 리스너) 스프링 이벤트의 스레드 동작(동기) 기본적으로, 스프링에서 이벤트를 발행하면, 그 이벤트는 기존 로직을 처리하고 있던 같은 스레드에서 처리된다. 예를 들어 어떤 컨트롤러 메서드에서 이벤트를 발행했다면, 그 이벤트에 대한 처리도 요청을 처리하고 있던 그..