RR

Spring boot CircuitBreaker 간단하게 알아보기

jay Joon — Sat, 18 Feb 2023 01:09:01 +0900

- 개요 -

스프링 프로젝트에서 서킷브레이커를 적용하기 위해서는 아래의 2가지 프레임워크를 이용합니다

hystrix circuit breaker
resilience4j circuit breaker

현재는 hystrix circuit breaker는 2021년 11월 1일부로 공식적인 지원이 중단되어
사용을 추천하지 않습니다.

따라서 이번 글에서는 resilience4j 의 circuit breaker을 설명하도록 하겠습니다.

우선 의존성은 아래와 같습니다.

dependencies {
    implementation 'io.github.resilience4j:resilience4j-spring-boot2:{version}'
}

스프링 부트 버전과 호환되는 각각의 resilience4j 은 아래와 같으니 현재 자신의 프로젝트에 맞는
version을 사용해 주세요!

Spring Boot 2.6.x: Resilience4j-Spring Boot 1.7.x
Spring Boot 2.5.x: Resilience4j-Spring Boot 1.6.x
Spring Boot 2.4.x: Resilience4j-Spring Boot 1.5.x
Spring Boot 2.3.x: Resilience4j-Spring Boot 1.4.x
Spring Boot 2.2.x: Resilience4j-Spring Boot 1.3.x

- 본문 -

설정

우선 CircuitBreaker를 사용하기 위해선 config 설정을 먼저 하여야 하는데 두 가지 방법이 존재합니다.

직접 Config 객체를 만들어 설정하는 법
yml 파일에 명시하여 설정하는 법 (이번글을 읽고 공식문서만 잠깐 참고하여도 이해하는데 크게 문제가 없음으로 이번 글에서는 설명하지 않겠습니다.)

직접 Config 객체를 만들어 설정하는 법은 아래와 같습니다!

CircuitBreakerConfig config = CircuitBreakerConfig.custom() 
                .failureRateThreshold(50)
                .waitDurationInOpenState(Duration.ofMillis(1000))
                .permittedNumberOfCallsInHalfOpenState(3) 
                .slidingWindowSize(100) 
                .build();

각각의 설정의 의미는

failureRateThreshold(50) : Circuit Breaker가 Open 상태로 전환될 실패율 임계값을 50%로 설정 → slidingWindowSize 개의 실패한 호출의 비율이 50%를 초과하면 Circuit Breaker가 Open 상태로 변경 (100개 중 50개가 실패면 open)
waitDurationInOpenState(Duration.ofMillis(1000)) : Circuit Breaker가 Open 상태에서 Half-Open 상태로 전환될 때까지 대기하는 시간을 1초로 설정
permittedNumberOfCallsInHalfOpenState(3) : Circuit Breaker가 Half-Open 상태에서 허용되는 최대 호출 횟수를 3으로 설정. Half-Open 상태에서 3번 호출 시 모두 성공해야 다시 closed 상태로 변한다. (한 번이라도 실패한 경우 다시 open)
slidingWindowSize(100) : Circuit Breaker가 Closed 상태일 때 통계를 수집하기 위한 window size를 100으로 설정

이렇게 config 설정을 완료하였다면 CircuitBreaker를 아래와 같이 생성하면 됩니다!

CircuitBreaker circuitBreaker = CircuitBreaker.of("testCircuitBreaker", config);

여기까지 했다면 CircuitBreaker(testCircuitBreaker)가 정상적으로 생성되었습니다.

다음은 생성된 CircuitBreaker을 사용해 봅시다.

circuitBreaker.decorateCheckedSupplier(() -> {
            System.out.println("실행할 로직");
            return "test";
        });

간단하게는 다음과 같으며 decorateCheckedSupplier 이외에도 다른 decorater 메서드들이 많으니 필요에 따라 사용하면 됩니다.

만약 실행할 로직에서 예외가 발생한 경우 fallback 코드도 아래와 같이 설정할 수 있습니다.

CheckedFunction0<String> checkedSupplier = circuitBreaker.decorateCheckedSupplier(() -> {
            throw new RuntimeException("무조건 실패");
        });

String result = Try.of(checkedSupplier).recover(throwable -> {
            log.error("실행 로직 실패 fallback 동작  error: {}", throwable.getMessage());
            return "fallback";
        }).get();

System.out.println(result);

위 코드를 실행 시 다음과 같은 결과를 얻게 됩니다.

즉 error 가 발생하여도 실패에 따른 동작을 지정할 수 있습니다.

이렇게 error 가 발생하면 앞서 설정한 config 설정대로 집계하다가 실패율 임계치가 넘는 순간 서킷의 상태는 OPEN으로 변경되고 본 로직을 실행하지 않고 바로 fallback 로직을 실행하게 됩니다.

코드로 보면 다음과 같습니다.

circuitBreaker.transitionToOpenState(); // 강제로 open 상태로 변경

CheckedFunction0<String> checkedSupplier = circuitBreaker.decorateCheckedSupplier(() -> {
    throw new RuntimeException("무조건 실패");
});

String result = Try.of(checkedSupplier).recover(throwable -> {
    log.error("실행 로직 실패 fallback 동작  error: {}", throwable.getMessage());
    return "fallback";
}).get();
  
System.out.println("result :" + result);

결과

조금 더 알아보기

이렇게 간단하게 서킷브레이커를 사용하는 방법을 알아보았는데요.

추가적으로 애매한 부분을 더 알아봅시다.

만약 아래처럼 동일한 서킷브레이커 이름으로 두 번 생성 시 어떻게 될까요?

CircuitBreaker circuitBreaker1 = CircuitBreaker.of("testCircuitBreaker", config);
CircuitBreaker circuitBreaker2 = CircuitBreaker.of("testCircuitBreaker", config);

circuitBreaker1과 circuitBreaker2 은 동일한 객체일까요?

맞습니다 동일한 객체입니다. 서킷브레이커 등록 시 testCircuitBreaker에 해당하는 이름이 이미 존재할 시 같은 인스턴스를 반환하게 됩니다. ( circuitBreaker1 == circuitBreaker2 )

만약 다른 로직에서 생성된 서킷 브레이커(testCircuitBreaker)를 가져오고 싶을 땐 아래와 같이 가져오면 됩니다.

CircuitBreakerRegistry circuitBreakerRegistry = CircuitBreakerRegistry.ofDefaults();
CircuitBreaker circuitBreaker = circuitBreakerRegistry.circuitBreaker("testCircuitBreaker");

마무리

이렇게 간단하게 서킷브레이커에 대해서 알아보았는데요.

해당 글에서 설명한 내용은 서킷브레이커 설정의 일부분 임으로 추가적인 내용이 필요하시다면

특정 에러만 실패 집계
애노테이션 기반의 서킷브레이커 구성
yml 설정 (문서)

등 다양한 설정이 필요하시다면 공식문서를 참고하시면 도움이 될 것 같습니다.

감사합니다.

[Spring-batch] Job 에 대해 알아보자!

jay Joon — Fri, 25 Feb 2022 13:39:39 +0900

기본개념

배치 계층 구조에서 가장 상위에 있는 개념(하나의 배치작업 자체이다)
적어도 하나 이상의 step을 포함하고 있는 컨테이너

기본 구현체

SimpleJob
- 순차적으로 Step을 실행시키는 Job
- 모든 Job에서 유용하게 사용할 수 있는 표준 기능을 갖고 있음
FlowJob
- 특정한 조건과 흐름에 따라 Step을 구성하여 실행시키는 Job
- Flow 객체를 실행시켜서 작업을 진행함

Job 은 어떻게 만들어지고 어떻게 실행되는 걸까??

대부분 JobBuilderFactory 을 이용하여 Job 생성하게 된다.

jobBuilderFactory.get("simpleJob") // job 의 이름을 정한다.
            .start(simpleStep1()) // 실행할 step 을  지정한다.
            .next(simpleStep2()) //  step 은 여러개 가질 수 있다.
            .build(); // 최종적으로 Job 을 생성한다.

Job 구현체 내부 stepList에 step을 순차적으로 저장하여 최종적으로 저장하여 생성하게 된다.

실행은 (스프링 부트 기준)

JobLauncherApplicationRunner 안에 있는 JobLauncher 를 이용하여 Job을 실행한다.

JobLauncher 는 인터페이스이며 실 구현체는 SimpleJobLauncher 를 이용한다.

다음처럼 SimpleJobLauncher 를 이용하여 등록한 Job을 step 별로 실행하게 된다.

추가적으로 publisher 가 등록되어있다면 job 이 실행되고 이벤트도 발행시킬 수 있습니다.

그렇다면 애플리케이션에 여러 개의 Job 등록되어있으면 어떻게 될까?

별 다른 설정을 하지 않고 애플리케이션을 실행하면 등록된 모든 Job을 실행하게 된다.

특정 job 만 실행시키고 싶다면 application.yml 에 spring.batch.job.names: ${job.name:NONE}

옵션을 추가하여 program arguments에 job 이름을 넣어주어 실행시켜주면 된다.

그렇다면 이 넘겨준 Job 이름은 어디서 사용되고 어떻게 한 가지 Job 만 실행되는 걸까?

Spring boot 가 실행될때

JobLauncherApplicationRunner을 자동적으로 생성하여 등록하는 부분을 찾아보면 됩니다!

등록되는 Config 이름은 BatchAutoConfiguration 입니다.

코드를 보면 properties 또는 args로 넘겨준 jobName 이 있다면 생성할 때 runner에 등록을 합니다.

없다면 별다른 설정없이 생성됩니다.

이렇게 생성되었다면 JobLauncherApplicationRunner 가 실질적으로 SimpleJobLauncher 을 실행할 때 모든 Job을 실행할지 특정 Job 만 실행할지 결정하게 됩니다.

해당 메서드에서 executeLocalJobs , executeRegisteredJobs 두 개의 메서드가 불립니다.

여기서 executeLocalJobs 은 JobName 이 있다면 해당 job을 찾아 실행하게 됩니다.

그 후 executeRegisteredJobs 가 불리지만 JobLauncherApplicationRunner 에 jobName 이 설정되어 있다면 해당 메서드는 실행되지 않고 종료됩니다.

앞선 살펴본 코드를 요약하자면 다음과 같습니다.

jobName을 넘겨준다고 해서 해당하는 Job의 Bean 만 등록이 되는 것이 아니다.
단지 jobName으로 여러 개의 job 들 중 이름이 같은 job 만 실행이 된다.

JobInstance, JobExecution에 대해 알아보자

JobExecution, JobInstance 는 위 그림과 같은 구조로 생성이 됩니다.

그림만으로도 충분히 이해하실 수 있지만 코드와 설명을 통해 조금 더 알아보죠!

JobInstance

Job 이 실행될 때마다 BATCH_JOB_INSTANCE에 저장할 Entity
이미 동일한 JobParameter, JobName 이 존재하면 저장되지 않음
- 중요) 저장이 안 된다는 거지 Job 실행이 안 되는 건 아닙니다.
즉 동일한 Job에 대해서 JobParameter 가 다르다면 계속해서 생성됩니다.
관계
- Job (1) : JobInstance(N)
- JobInstance (1) : JobParameter(1)

JobExecution

JobInstance 가 정상적으로 성공했는지? 아니면 실패했는지 기록합니다.
- 성공시간, 시작시간 , Job 실행 상태 기록
- 기록하는 테이블은 BATCH_JOB_EXECUTION입니다.
관계
- JobInstance (1) : JobExecution(N)

앞서 언급한 것 처럼 중요한 부분은 기존에 동일한 JobInstance 있다고 해서 실행하고자 하는

Job 이 무조건 실패하는 건 아닙니다.

(~~제가 처음 batch 을 접했을 땐 그런 줄 알았습니다.~~ )

이미 존재하는 JobInstance에 대해 동일한 Job, JobParameter을 실행시 다음과 같이 동작합니다.
(설명하는 내용은 JobInstance 존재하지 않아도 동일하게 검증을 진행합니다.)

첫 번째 검증

jobInstanceDao 로 부터 JobInstance 를 가져옵니다.
JobInstance 이용jobExecutionDao 으로부터 가장 마지막으로 등록된 JobExecution 가져옵니다.
가져온 JobExecution 의 하위의 StepExecution 을 확인하여 실행을 할지 안 할지 결정합니다.
- StepExecution 은 step을 설명할 때 다시 설명하도록 하겠습니다.

코드는 SimpleJobLauncher 의 run() 메서드를 따라가면서 보시면 됩니다.

해당 코드가 앞선 첫 번째 단계에 대해 설명한 부분입니다.

위 과정을 통과한다면 다시 다음과 같은 동작을 합니다.

두 번째 검증

jobInstanceDao 로 부터 JobInstance 를 가져옵니다.
JobInstance 이용 jobExecutionDao으로부터 등록된 모든 JobExecution 가져옵니다.
모든 JobExecution 순회하며 상태를 확인하여 확인하여 실행을 할지 안 할지 결정합니다.
위 과정이 이상이 없다면 새로운 jobExecution 을 만들어 저장합니다.

해당 코드는 SimpleJobLauncher run() 메서드 안의 jobRepository.createJobExecution 을 참고
하여 보시면 됩니다.

jobRepository의 구현체는 SimpleJobRepository 입니다.

해당 과정을 요약하자면

이미 등록된 JobInstance 가 존재하여도 jobExecution 의 상태에 따라 Job 실행 여부가 결정됩니다.

여기까지 Job 에 관련된 동작원리 및 속성에 대해 알아보았는데요!

모든 동작원리, 속성에 대해 설명하지 않았지만 제가 생각하는 중요한 부분은 짚고 넘어간거 같습니다.

혹시라도 글 본문에 잘못된 내용이 있거나 이 외에도 중요한내용이 있다면
댓글로 남겨주시면 반영하도록 하겠습니다.

감사합니다. ‍♂️

참고: spring-batch reference

Spring Config 서버는 필요할까?

jay Joon — Sun, 20 Feb 2022 03:02:09 +0900

해당 질문에 대해서는 서비스가 어떻게 구축되었는가에 따라 정답이 다르겠지만
적어도 yml에서 관리되고 있는 property 가 동일한 값을 여러 프로젝트에서 사용하고 있다면 매우 필요하다고 느끼고 있다.

왜 필요한가?

예를 들어 여러 프로젝트에서 Slack 알림을 발송하고 있다고 가정해보자.

Slack 알람을 발송하기 위해선 webHook 이 필요할 것이다. 또한 채널명도 알고 있어야 된다.
간단하게 아래와 같은 그림이 될 것 같다.

예시 1

만약 현재 상태에서 슬랙 채널의 이름이 변경된다고 가정해보자.

그러면 모든 프로젝트의 yml 파일에 가서 정보를 변경해야 한다 여기까지는 충분히 할 수 있다.

(만약 프로젝트가 많다면 해당 슬랙 채널로 발송하고 있는 프로젝트를 다 찾아야 한다.)

하지만 코드를 변경했지만 Slack 채널명은 변경하지 못한다.

왜냐하면 배포를 하지 않았기 때문에 슬랙 채널명은 배포 시점에 같이 변경해야 한다.

여기까지도 충분히 할 수 있다.

하지만 프로젝트, 프로젝트 2, 프로젝트 3 이 모두 배포되고 나서야 Slack 채널명을 변경할 수 있다.

단 하나라도 먼저 배포하거나 하나라도 빠진다면 이슈 알람은 받지 못할 것이다.

슬랙 채널명을 변경하기 위해 알람을 발송하고 있는 서비스를 재배포하는 것도 뭔가.. 아쉽다.

만약 Config Server 가 있다면 편해질까?

예시 2

그림과 같이 나는 yml 이 저장소에 저장되어있는 파일만 수정하여 해당 파일이 변경되었다는

이벤트만 config server로 발행하고 config server는 해당 서버를 구독하고 있는
프로젝트들에게 알림을 발송하여 새로운 yml 파일로 변경하라는 메시지만 발행해준다면

앞선 문제점인

yml 파일을 3번 수정하거나
누락되어 수정되지 않은 프로젝트가 있거나
마지막으로 제일 행복한 재배포 과정을 3번이나 가지지 않아도 된다.

하지만 정말로 이대로 행복한 걸까?

아직 깊게 공부하지는 않았지만 Config Server 가 단일 장애점이 될 수도 있지 않을까? 에 대한 생각은 아직도 남아있다.

결론

해당 본문은 Spring Cloud Config Server 만들어보기 전에 왜 구축해보고 싶었는지 도입 글?이라고 해야 할까요..

아직까지는 단점보다는 장점이 많아 보이긴 하지만 또 하다 보면 단점이 더 많을 수도 있겠죠!?

따라서 다음 글은 구축 과정과 Spring Cloud Config과 관련된 글을 작성하고자 합니다.

부족한 글 읽어주셔서

감사합니다!

신입 개발자가 되기까지(취업준비 후기)

jay Joon — Sun, 3 Oct 2021 00:38:43 +0900

총평: 힘들었다..

졸업 후 취업까지 걸린 기간은 총 3개월 정도 걸린 것 같다.

누군가에게는 적당한 시간일 수도 또는 짧은 시간일 수도 있다고 생각한다.

하지만 취준의 피 말리는 프로세스는 앞으로 몇 년간은 경험하고 싶지 않다.~~(탈모 올 뻔)~~

이번 글에서는 취업하면서 느꼈던 점과 저 자신을 다시 한번 돌아보는 글을 써보고자 합니다.

나는 "비전공자" 다.

저는 비 전공자입니다.(너무 뜬금없나요?? )

군대를 다녀온 후 2019년 에 처음으로 JAVA를 접했는데요

물론 개발자를 하기 위해서 JAVA를 공부했던 것은 아니었습니다 (학교 과제 때문에 처음으로 접하게 되었습니다.)

그때 당시 진행했던 과제가 간단하게 JSP + Servlet으로 웹 환경을 구축하고 저만의 서비스를 만드는 수업이었습니다.

자료구조, 일반적인 기본 타입 마저 일체 모르는 상태였습니다.

뒤에 등장할 말이 너무 뻔해서 결론은 수업이 재미있었습니다 그래서 꾸준히 열심히 했습니다.

어떻게 공부했는가?

저는 국비 학원 또는 취업프로그램 같은 것은 일체 듣지 않았습니다.
딱히 큰 이유는 없지만 결국 취업프로그램이나 국비 학원을 통해서 배운걸 내 걸로 만들기 위해 개인적 공부는 필요하기 때문에 인강으로도 충분하다고 생각했습니다.
인강의 장점은 계속해서 다시 들을수 있다는 게 제일 좋은 장점인 거 같습니다.
(현장 강의도 충분히 매력 있지만 어떠한 부분에서 이해가 안 된다면 잠시 멈추고 공부하고 다시 들을 때마다 새로운 느낌을 받을 수 있습니다.)

2020년까지 혼자 인프런을 보면서 계속 공부를 했습니다.(~~백기선 님 강의 없었으면 취업 못했을 것 같습니다~~)

하지만.. 혼자 공부하다 보니 한계점을 느껴서 2020년 10월 달부터 스터디에 참여하여 스터디원 분들과 공부를 했습니다.

또한 개인 프로젝트와 팀 프로젝트도 같이 진행하면서 새로 알게 되었던 부분을 블로그에 정리하거나 스터디 내부에서 발표했습니다.

지금 돌이켜 생각해보면 혼자 공부했던 시간보다 스터디를 하면서 공부했던 시간이 효율적으로 3배는 더 좋았던 것 같습니다.

또한 항상 새로 알게 된 지식에 대해서는 직접 타이핑하여 정리하면서 공부하였습니다.(이 중에서 마음에 드는 건 블로그에 포스팅합니다. )

이렇게 한번 정리하고 나면 기억이 정말 오래갑니다.

본격적인 취업준비 활동

사실 저는 올해 취업할 생각이 없었습니다.

스터디원 중 한 분이 이력서를 써보라고 하셔서 쓰다 보니 취업활동까지 이어졌습니다.

이력서 컨펌도 해주시고 매우 감사하게 생각하고 있습니다. ‍♂️

이력서를 쓰고 나서 원티드 또는 회사 자체 홈페이지에 있는 공고를 보며

경력 3년 차 이상 또는 이에 준하는 실력이 있으신 분이라는 문구가 있으면 경력이 없어도 모든 곳에 지원했습니다.

신입을 뽑는 공고도 많이 없을뿐더러 가고 싶은 회사가 있지 않았습니다.

처참한 결과

이에 따른 서류 합격률은 50개 정도를 넣어서 8개 정도가 붙었습니다.(처음에는 떨어지면 슬펐는데 나중에는 슬프지도 않더라고요)

이렇게 경력직 공고에 넣어서 서류에 합격하게 된다면 대부분 다음 채용과정으로는 코딩 테스트가 주어지게 되는데요.

코딩 테스트가 자신 없긴 했지만 공채로 뽑는 코딩 테스트에 비해 매우 쉬운 난이도의 문제이기 때문에

문제만 꼼꼼히 읽으면 어느 정도 풀 수 있었습니다.(leetcode의 easy, medium 수준)

어찌어찌해서 코딩 테스트까지 합격했다면 다음은 면접이라는 관문이 남아있는데요.

면접은 제일 어려웠던 과정이면서 많이 배웠던 프로세스였습니다.

첫 면접은 탈락이지!

운 좋게 과제 전형에서 통과했지만 1차 면접에서 탈락하였습니다.

제 인생에서의 첫 면접이면서 가고 싶은 회사이기에 기대도 많이 했지만

지금 돌이켜 생각해보면 스스로 많이 부족했다고 느꼈습니다.

구체적인 면접 내용은 공개할 수 없지만

끝나고 느낀 점은 정말 내가 특정 기술들을 사용하면서 정말 깊게 생각하고 썼을까?라는 생각을 가지게 되었습니다.

계속되는 탈락

취업준비 초기에는 정말 금방 취업할 수 있다고 생각했습니다.

하지만 취업의 문은 결코 낮지 않았습니다 코딩 테스트를 통과해도 똑같이 면접에서 계속해서 탈락하였습니다.

피드백

그래도 포기할 수 없죠! 면접 과정에서 피드백을 요청하여 저의 문제점을 찾고자 했습니다.

피드백 요청을 해서 모든 회사가 피드백을 제공해주지는 않지만 그래도 주는 회사도 있으니 꼭 문의 메일을 보내는 것을 추천합니다.

이 외에도 과제 전형에서 탈락하거나 코딩 테스트에서 떨어지는 과정을 한 달간 가지게 됩니다.

이렇게 탈락하면서 제가 느낀 점은

다양한 기술을 적용해보았는가?
다양한 언어를 많이 사용해보았는가?

이런 건 하나도 중요하지 않습니다(물론 중요할 수도 있지만)

결국 가장 중요한 것은 기초였습니다.

여기서 기초라고 하면 자료구조, JVM 동작원리, GC 동작원리, 다양한 디자인 패턴 등 일 수도 있지만

가장 중요한 건 나의 이력서에 적은 기술에 대해서 정말로 깊게 알고 있는가?

장단점을 설명할 수 있는가?
어떠한 부분에서 이 기술이 필요해서 적용했는가?
적용했을 때의 발생할 수 있는 문제점을 알고 있는가?
다른 방법을 고민해 보았는가?

제가 생각하기엔 이 네 가지가 가장 중요하다고 느껴졌습니다.

합격

면접도 경험이라고 말할 수 있을까요? 한두 개씩 합격 메일을 받게 되었습니다.

계속 떨어지다 보니 점차 이제 떨리지도 않고

아는 내용에 대해서는 최대한 아는 만큼 말하고 모르는 내용에 대해서는 쿨하게 인정하자!라는 마인드로 면접을 계속 보았습니다.

모르는 내용을 계속 억지로 끌고 가는 것보다는 짧은 면접 시간 동안 제가 아는 부분을 말하기에도 시간이 부족하기 때문입니다.

(물론 모르겠다고 한 질문에 대해서는 면접이 끝나고 정리하였습니다.)

여러 가지 합격한 회사 중에

최종적으로 제가 가게 된 회사는 우아한형제들(배달의민족)입니다!

정말로 가고 싶은 회사 중 하나라서 앞으로 열심히 다니도록 하겠습니다!

끝맺음

기존 전공을 포기하고 개발자로 살기 위해 선택했지만 그 과정에 있어서 중간중간

개발자라는 직업이 나한테 정말 적성으로 맞을까?라는 생각은 힘들 때마다 들었습니다.

또한 계속되는 탈락 메일은 정말로 내가 실력이 없구나 라는 생각을 하게 됩니다.

저희가 떨어진 건 회사가 인재를 놓친 것이니 힘들겠지만 일일이 신경 쓰지 않으셔도 됩니다.

제가 여태까지 보았던 아티클 중 가장 마음속에 남아있는 문구가 있는데요

포기하지 않고 꾸준히 한다면 정말로 성과가 있습니다!!!

저도 마지막으로!

‍♂️ 취업준비기간 동안 도와주신 스터디원 분들 정말 감사합니다. ‍♂️

MySQL LIKE % 위치에 따른 인덱스 사용 여부

jay Joon — Thu, 9 Sep 2021 22:57:43 +0900

서론

Table 내 어떠한 칼럼에 index를 설정하여 Like 문을 통해 검색하는 경우

INDEX 설정을 하였어도 % 위치에 따라 INDEX 가 정상적으로 작동하는 경우가 있지만 반대로 잘못 사용한 경우 Full Scan 이 발생할 수 있다.

이번글에서는 LIKE 검색에서 % 위치에 따른 INDEX 사용 여부를 하나씩 살펴볼 것이다.

Table 구조

간단한 Member Table이며 더미 데이터수는 1만 개로 설정하였다.

CREATE TABLE `Member` (
  `id` int(9) unsigned NOT NULL AUTO_INCREMENT,
  `name` varchar(100) NOT NULL,
  `address` varchar(255) NOT NULL,
  `age` int(11) NOT NULL,
  PRIMARY KEY (`id`)
) ENGINE=InnoDB AUTO_INCREMENT=101 DEFAULT CHARSET=utf8;;

INDEX 칼럼

CREATE INDEX MEMBER_NAME ON Member (name);

1. 'ABC%' 데이터 시작 형식을 검색하는 경우

name like 'AB%' 검색인 경우 AB로 시작하는 데이터들을 조회하고자 하는 것이다.

해당 조회 같은 경우에는 인덱스가 잘 적용되는 것을 확인할 수 있다.

2. '% ABC' 끝나는 데이터 형식을 검색하는 경우

name like '%AB' 검색인 경우 AB로 끝나는 데이터들을 조회하고자 하는 것이다.

해당 조회 같은 경우에는 인덱스가 적용되지 않는다.

3. '%ABC%' 데이터에 포함하는지 검색하는 경우

name like '%AB%' 검색인 경우 AB가 포함된 데이터들을 조회하고자 하는 것이다.

해당 조회 같은 경우에는 인덱스가 적용되지 않는다.

왜? AB% 를 제외한 나머지 방식은 인덱스를 타지 않을까?

데이터베이스의 인덱스의 자료구조는 대부분 B-TREE 구조로 이루어져 있다.

(B-TREE 은 노드의 자식 노드의 데이터들은 노드 데이터 기준으로 데이터보다 작은 값이 왼쪽부터 오른쪽으로 정렬되어 있다.)

이러한 구조를 가지고 있다고 생각하고 왜? % 위치에 따라 인덱스 조건이 타지 않는가? 에 대해 다시 생각해보면 당연히 타지 않을 거라고 생각했어야 했다.

하지만 이제라도 공부하여 잊지않으면 괜찮지 않을까요?

그럼 어떻게 검색해야 하는가?

MySQL 5.7 버전 이상부터 FullText Search(전문 검색) 방식을 사용하여 앞서 살펴본

% ABC%, % ABC 검색을 사용했을 때 인덱스를 사용하지 못한 부분을

FullText Search 을 사용한다면 빠른 검색이 가능하다고 합니다.

해당 본문에서는 FullText Search 대해서 설명하지는 않겠습니다.

추 후 FullText Search 사용방법과 어떻게 동작하는지에 대해 공부해서 포스팅하도록 하겠습니다.

참고자료

https://dev.mysql.com/doc/refman/8.0/en/index-btree-hash.html

https://hoing.io/archives/16853

https://stackoverflow.com/questions/2042269/how-to-speed-up-select-like-queries-in-mysql-on-multiple-columns

나는 JPA 를 왜(알고) 사용하고 있을까?

jay Joon — Sun, 15 Aug 2021 00:15:11 +0900

JPA(ORM) 기술은 왜 사용하는가?

1. SQL 중심적인 개발을 벗어나게 해 준다.
기존 SQL 중심의 프로젝트는 객체 중심의 코딩이 불가능했다.

예제 코드

   public static void main(String[] args) throws Exception {
        Class.forName("jdbc");
        Connection con = DriverManager.getConnection ("DBURL","username", "password");

        Statement stmt = con.createStatement();

        String query ="query" // name,age,address
        ResultSet rs = stmt.executeQuery(query);
        
        List<Person> persons = new ArrayList<>();
        while (rs.next()) {
          String name = rs.getString("name");
          int age = rs.getInt("age");
          String address = rs.getInt("address");
          persons.add(new Person(name,age,address));
        }
}

해당 예제 코드는 말 그대로 DB에 접근하여 자료를 읽어 가져오는 역할만 한다.

만약 해당 프로젝트에서 name, age , address -> Person이라는 객체로 사용하기 위해서는 일일이 생성해줘야 한다.

여기까지는 객체지향스럽게 코딩이 가능하다고 생각할 수 있다.

하지만 예제 코드는 말 그대로 예제 코드일 뿐 현실은 그렇지 않다.

결국 프로젝트 규모가 커질수록 객체 중심 코딩은 불가능하며 데이터 중심의 코드만 짜게 된다.

2. 객체와 관계형 데이터베이스의 패러다임 불일치를 해소해준다,

상속
연관관계 - 객체는 참조를 사용 , 테이블은 외래 키를 사용한다
데이터 타입
데이터 식별 방법

3. 객체 그래프 탐색 Member -> Order -> OrderItem -> Item

처음 실행하는 SQL에 따라 탐색 가능 범위가 결정돼버림
Member -> Order -> Item 인 경우에서 Member -> Order 까지만 로딩이 되었다 가정하고 나는 사용했지만 다른 사람이 보았을 때 Item을 접근할 수 있기 때문에 만약 접근한다면 NPE 가 발생한다.
하지만 JPA 같은 경우 지연 로딩, 즉시 로딩을 설정할 수 있기 때문에 앞서 살펴본 오류를 방지할 수 있다.
(단 N+1 문제든 예상치 못한 쿼리가 발생할 수 있다. 따라서 잘 알고 쓰자!)

JPA와 hibernate의 관계

JPA를 사용하다 보면 hibernate 이야기는 항상 나오게 된다.

그리고 깊게 공부하지 않는다면 hibernate와 JPA는 똑같다고 생각할 수 있다.

위의 말은 100% 틀린 말은 아니지만 또한 100% 맞는 말도 아니다.

JPA는 단지 자바 진영의 표준 ORM 기술이다.

즉 ORM의 기술을 사용하기 위한 표준 인터페이스를 제공한다는 뜻이다.

인터페이스를 제공해준다는 뜻은 JPA를 사용한다면 하위 구현체로 hibernate 가 아닌 다른 하위 구현체로 변경할 수 있다는 뜻이다.
hibernate 이외에도 JPA 지원하는 벤더들도 많이 존재한다.

결과적으로 하위 구현체로 hibernate 가 많이 사용될 뿐이지 JPA == hibernate 인건 아니다.

추 후 hibernate 보다 뛰어난 ORM 프로젝트가 나온다면 미래에는 얼마든지 교체될 수 있다.

하지만 우리가 진행하고 있는 프로젝트의 코드를 변경하지 않아도 새로운 구현체가 (ORM 프로젝트) JPA 인터페이스를 완벽하게 지원한다면 인터페이스의 하위 구현체만 변경하여 더 좋은 성능의 ORM 프로젝트를 사용할 수 있다.

그렇다면 JPA는 단점이 없는가?

(제 생각이 어느 정도 들어간 문단입니다.)

편안함에서 오는 복잡함(무슨 소리야? )

제가 말하고자 하는 것은 예상하지 못한 Query 구문, 발생 횟수뿐이 아닌
편리함을 추 구하기 위해 과도하게 연관관계를 맺는 행위를 말하고자 합니다.

객체 그래프 탐색은 매우 매력적이고 개발을 함에 있어 매우 편리하여 양방향 연관관계를 맺어 사용하는 경우가 있습니다.

사실 도메인 로직상 과도한 연관관계가 필요한 경우는 제가 아직까지 만나보지 못한 걸 수도 있지만 대부분 단방향이거나 연관관계를 굳이 맺고 있지 않아도 처리가 가능합니다.

즉 CRUD에서 CUD 로직은 과도한 연관관계가 대부분 필요 없다고 생각합니다.

위의 예제는 제가 프로젝트를 하면서 연관관계에 대해서 다시 생각해본 내용입니다.
(해당 이유가 정답이 아닐 수도 있지만)

Entity 간의 연관관계가 꼭 필요한지 한 번쯤은 생각해보는 것도 좋을 듯합니다.

또한 프로젝트의 연관관계가 너무 복잡하다면

CRUD의 Read(select)를 편하게 하기 위해서 맺는 경우가 있는지 한번 확인해보시면 좋을 것 같습니다.

높은 학습비용

아직까지도 JPA를 사용하다 보면 N+1 문제
영속성 콘텍스트 범위 관리를 하지 못하여 update 가 되지 않거나
예상하지 못한 쿼리가 발생한다거나

JPA를 주의하면서 쓴다고 해도 100% 해당 문제를 다시 안 만난다는 보장은 없습니다.

성능

앞서 말한 것처럼 간단한 Select Query는 JPA로 사용해도 괜찮지만
복잡한 통계성 쿼리는 JPA의 JPQL을 이용하기보다는 Native query를 사용하거나 Mybatis를 이용하는 것이 좋다.

나는 왜 JAVA 를 사용하게되었는가?

jay Joon — Wed, 11 Aug 2021 21:24:09 +0900

해당 주제에 대한 답변으로 어떤 게 떠올르시나요?

자바가 첫 언어이기 때문에
언어는 중요하지 않고 개발에 먼저 익숙해지고 패러다임을 익히기 위해
혼자 공부하는 데에 있어 참고자료가 풍부하기 때문에
회사가 Java를 사용하기 때문에

막상 대답하려고 하면 막막합니다. 사실 위에 있는 답변이 저는 틀렸다고 생각하지 않습니다.

사람마다 선택하는 기술을 선택하는 기준이 다르다고 생각하고
그 기준이 나쁘다고 생각하지도 않습니다.

하지만 개발을 하다 보면 코드의 구조나 품질에 대해서는 많은 논의를 하고 배우고자 하지만

단 한 번도 왜 자바를 쓰고 있는 건가?라는 의문을 품은 적은 없었습니다.

즉 진행하고 있는 프로젝트가 꼭 자바로 구현하고자 하는 이유가 있는가?
(다른 언어로는 구현하지 못하는가?)

해당 질문을 들었을 때 솔직히 속으로는

여태까지 자바로 해왔고 언어적으로 발생하는 문제가 발생하지 않았다.
Java 기반의 프레임워크를 익혀왔고 가장 친숙하고 자신 있고 아는 게 Java 뿐이라서

이런 생각이 먼저 떠올르고 마음속 생각을 그대로 말할 수 없어 Java 언어의 장점을 생각하여 답변을 하기 위해 준비하고 있었습니다.

결국 답변으로는 강력한 타입 체킹 언어, 플랫폼 독립적, GC를 통한 메모리 관리 등 형식적인 답변만 할 수밖에 없었습니다.

즉 원론적인 이유인 왜 해당 프로젝트에는 JAVA가 어울리는지를 설명하지 못했습니다.

대부분 자바의 장점으로 알고 있는 형식적인 답변이 다른 언어에서는 지원하지 못하는가?

그런 것도 아닌데도 말이죠

해당 질문에 대해서는 아직까지도 완벽한 답변을 생각하지 못했습니다.(사실 정답이 없다고도 생각을 합니다.)

하지만 한 가지 느낀 점은 무의식적으로 익숙한 도구를 계속 사용해왔다는 점만 알게 되었습니다.

결국에는 조금 더 환경에 맞는 좋은 기술, 언어를 채택할 수 있음에도 불구하고

익숙하지 않은 환경을 피하고자 하는 마음이 먼저 들었다는 것
말로는 개발자로서 언어는 도구일 뿐이야 라고 말만 하고 행동은 전혀 그렇지 않았다는 것

지금은 왜 사용하고 있는지 아는가?

저는 언어 수준에서 이유를 찾기에는 아는 것도 부족하고 너무 어렵다고 생각하여 더 높은 곳부터 이유를 찾고자 합니다.

다음 포스팅 주제에 대해서는 다음과 같습니다.

왜 Spring 사용했는가?
왜 JWT 기술은 왜 적용해보았는가?
왜 QueryDSL을 사용해야 하는가?
왜 ORM을 적용했는가?
왜 이벤트 기반의 방식을 사용했는가?

이 외에도 제가 여태까지 알고 있던 기술에 대해서 왜? 사용했는지에 대해 다시 한번 생각하는 시간을 가져보고자 합니다.

물론 해당 주제가 하나하나가 깊게 들어가면 한 없이 크다는 것도 알고 있습니다.

주제의 깊이는 누군가에게 설명을 했을 때 그래도 생각은 하고 사용했구나 정도가 저의 목표입니다.

마무리

JAVA 언어를 왜 사용했는가? 에 대해 궁금해서 들어오셨다면 글을 읽고 도움이 전혀 되지 않았다는 것을 알고 있습니다.

해당 부분에서 사죄드립니다. ‍♂️

이 글의 분위기는 사실 회고성이 더 가깝다는 것도 알고 있습니다.

하지만 이 글을 읽으신 분들은 기술을 사용하는 것도 좋지만

가장 중요한것은 기술의 장단점을 파악하여 사용하는 것이라는 생각도 들었으면 좋겠습니다.

부족한 글 읽어주셔서 감사합니다.

[JPA] findById() , getById() 에 대한 생각

jay Joon — Tue, 27 Jul 2021 16:54:30 +0900

서론

이번 글에서는 findById(), getById() 메서드의 차이점과 제가 생각하는 느낀 점에 대해 말해보고자 합니다.

따라서 개인적인 생각이 담긴 글이니 어느정도 비판적인 시각으로 봐주시면 감사하겠습니다.

사전 설명

다음과 같은 Entity 연관관계를 가지고 있을 때 저희는 일반적으로 게시판에 해당하는 댓글을 추가하기 위해서클라이언트 요청으로부터 게시판의 Id, 댓글내용, 작성자 등 필요한 정보를 받게됩니다.

그러면 저희는 Serivce Layer에서 해당하는 게시판이 있는지 확인 후 Reply 객체를 생성해서 연관관계를 맺은 후 저장하게 됩니다.

간단히 이러한 로직이 만들어지게 됩니다.

public void save(RequestReply requestReply) {

    // 해당하는 게시판이 존재하는가 ?
    Board board = boardRepository.findById(requestReply.getBoardId())
        .orElseThrow(EntityNotFoundException::new);

    // 댓글 생성
    Reply reply = Reply.builder()
        .content(requestReply.getContent())
        .board(board)
        .build();

    replyRepository.save(reply);
}

해당 로직 테스트 코드는 다음과 같습니다.

@Test
@DisplayName("댓글등록")
void replySave() {
    //given
    StudyBoard studyBoard = StudyBoard.builder()
        .title("토비의 스프링 스터디원 구해요")
        .studyName("초보를 위한 Spring Study")
        .description("이러한 이유로 모집합니다.")
        .place("서울")
        .recruitmentDeadline(LocalDateTime.now().plusDays(7))
        .recruiter(4)
        .createBy("KJJ")
        .build();
    StudyBoard study = boardRepository.save(studyBoard);


    RequestReply requestReply = new RequestReply(study.getId(), "저요저요!");
    System.out.println("==================================================================");
    //when  save 호출시 쿼리 발생 갯수 확인
    replyService.save(requestReply);
}

findById()

앞서 살펴본 예제는 findById()를 통해 DB에 쿼리가 발생하여 객체를 찾게 됩니다.

따라 다음과 같이 총 2번의 쿼리가 발생하게 됩니다.

여기서 드는 생각은 왜?

Board 객체를 찾아야 하지?
Id 값을 알고 있으니 Insert Query 하나만 발생해도 충분한 거 아닌가?

이러한 생각이 들 수 있습니다.

하지만 ORM 입장에서는 해당 ID 값 만으로는 어떤 타입의 객체인지 알 수 없습니다.

따라서 앞서 살펴본 것처럼 한번 찾고 Reply 객체를 생성하여 Board를 설정하는 과정이 발생하게 됩니다.

이처럼 두 번 Query 가 발생하는 것이 무조건 나쁜 과정일까요?

해당 질문은 아래에서 좀 더 다루겠습니다.

getById()

getById() 메서드가 생소하신 분들도 있을 것 같은데요 Spring Data JPA 2.5.3 이후부터 getOne() 메서드가 Deprecated 되고추가된 메서드입니다 기존 getOne() 메서드와 하는 일은 동일합니다.

그렇다면 앞선 예제에서 findById() 로 Board를 찾는 대신 getById() 를 통해 Board를 찾는다면 어떻게 될까요?

다음과 같이 하나의 Query 만 발생하게 됩니다.

따라서 앞서 findById() 메서드를 사용했을 때 가진 생각을 해결할 수 있는데요!

우선 getById() 가 어떻게 작동하는지부터 알아보죠!

getById() 는 지연 로딩으로 작동하게 되는데요! ID 값을 제외한 나머지 필드에 접근했을 때 Query가 발생하게 됩니다.

public void save(RequestReply requestReply) {
    Board board = boardRepository.getById(requestReply.getBoardId());

    System.out.println("ID 값 :"+ board.getId()); // 이때는 Query 가 발생하지않음
    System.out.println("=============================================");
    System.out.println("Title 값: "+ board.getTitle()); //이때는 정보가 필요하기때문에 Query 가 발생함

    // 댓글 생성
    Reply reply = Reply.builder()
        .content(requestReply.getContent())
        .board(board)
        .build();

    replyRepository.save(reply);
}

예제를 본다면 더욱 이해하기 쉬울 것 같습니다

결과

이처럼 어떠한 객체의 ID 값이 DB에 반드시 존재하고 ID를 제외한 다른 필드에 접근하지 않을 때 사용하게 되면 좋을 것 같습니다.

나의 생각

findById(), getById() 의 차이점은 즉시 로딩, 지연 로딩으로 가져오는가? 의 차이점이 있습니다.

여기서 또 메서드 이름으로 유추해볼 수 있는 주제가 있는데요.

왜 getOne() 메서드가 Deprecated 되고 getById()로 이름만 변경되었을까요?

여기서 알 수 있는 것은 메서드가 조금 더 명확하게 변경되었다는 것입니다.

get 은 무엇을 받다, 얻다 라는 의미가 있습니다.
즉 어떠한 객체를 무조건 받는다는 가정이 있습니다. (null을 return 하면 안 된다.)

find 은 찾다 라는 의미를 가지고 있습니다.
즉 객체를 찾을 수 있고 없을 수 도 있다는 가정이 있습니다. (Optional로 return 하여 선택권을 제공)

이렇게 명확한 구분은 저희가 메서드 이용하는 입장에서 기준을 가지고 사용할 수 있게 됩니다.

따라서 이처럼 두 번 Query 가 발생하는 것이 무조건 나쁜 과정일까요? 에 대한 질문은 메서드의 의미를 생각해보면 답이 나올 것 같습니다.

비즈니스상 클라이언트로부터 들어온 ID 값이(게시글이) 어떠한 경우에도 항상 존재하는가?

Yes 인 경우에는 getById()로 메서드로 사용해도 문제가 발생하지 않습니다. (없다면 예외가 발생합니다.)
NO 인 경우에는 findById()를 사용해서 존재 여부를 확인해야 하겠죠?

결론

프레임워크가 제공하는 메서드명을 읽다 보면 의도를 어느 정도 파악할 수 있습니다.

이러한 확실한 메서드명은 개발자로 하여금 어떤 문제를 발생할 수 있는지 내부 코드를 보지 않아도 어느 정도 유추할 수 있는데요!

이러한 코드가 정말로 좋은 코드이지 않을까요?

[Spring-boot] Master - Slave 구조에 따른 Read, Write 분기

jay Joon — Wed, 21 Jul 2021 00:39:28 +0900

서론

데이터베이스를 이용한다면 대부분 쓰기보다 읽기 의 행위가 더 많습니다.

출처 : 오라클

DB의 부하를 줄이기 위해 다음과 같이 Master - Slave 구조를 많이 사용하는데요.

이러한 구조를 가지고 있을 때 Transection의 속성이 readOnly = true 인 경우
Slave 데이터베이스에 Select query 가 발생하게 해야합니다.

따라서 이번 본문에서는

@Transactional(readOnly = true) 인 경우는 Slave DB 접근
@Transactional(readOnly = false) 인 경우에는 Master DB 접근

위의 조건을 만족하기 위한 방법을 Spring-boot 기준으로 소개하고자 합니다.

사전 환경설정

실습 환경은 다른 것은 필요 없고 저는 MySQL 데이터베이스를 이용하였고

Master - Slave 구조가 준비되었다고 가정합니다.

저는 Docker를 이용하였습니다.

Master DB : 3306 PORT
Slave DB - 3307 PORT

저와 같은 환경을 설정하고 싶으신 분 Github를 참고해주세요.

본문

application.yml 설정

먼저 DB에 접근하기 위해 application.yml 에 접근 정보를 정의해보겠습니다.

spring:
  datasource:
    master:
      hikari: 
        username: root
        password: password
        driver-class-name: com.mysql.cj.jdbc.Driver
        jdbc-url: jdbc:mysql://localhost:3306/examreplication
    slave:
      hikari:
        username: root
        password: password
        driver-class-name: com.mysql.cj.jdbc.Driver
        jdbc-url: jdbc:mysql://localhost:3307/examreplication

현재 Master, Slave DB를 2 개를 사용해야 하니 Datasource를 직접 생성해야 합니다.

따라서 해당 접근 정보들을 이용하여 DataSource을 만들어야 하니 정확히 입력해주세요!

DataSource Bean 등록하기

일단 readOnly속성 별로 분기를 하기 전에 앞서 설정한 정보로 DataSource를 Bean으로 등록하는 과정입니다.

@Configuration
public class DataSourceConfiguration {

    public static final String MASTER_DATASOURCE = "masterDataSource";
    public static final String SLAVE_DATASOURCE = "slaveDataSource";

    @Bean(MASTER_DATASOURCE) 
    @ConfigurationProperties(prefix = "spring.datasource.master.hikari") // (1)
    public DataSource masterDataSource() {
        return DataSourceBuilder.create() 
            .type(HikariDataSource.class) 
            .build();
    }

    @Bean(SLAVE_DATASOURCE)
    @ConfigurationProperties(prefix = "spring.datasource.slave.hikari")
    public DataSource slaveDataSource() {
        return DataSourceBuilder.create()
            .type(HikariDataSource.class)
            .build();
    }
}

1. spring.datasource.master.hikari 에 해당하는 property를 DataSource를 생성하는데 이용.

여기서 1번 과정이 잘 이해가 안 되신다면 해당 자료를 참고해주세요.

AbstractRoutingDataSource 구현

AbstractRoutingDataSource.class 는 조회 key 기반으로 등록된 Datasource 중 하나를 호출을 하게 해 줍니다.

말이 거창하긴 한데 소스코드를 보면 매우 간단합니다.

public class RoutingDataSource extends AbstractRoutingDataSource {
    @Override
    protected Object determineCurrentLookupKey() { // (1)
        return (TransactionSynchronizationManager.isCurrentTransactionReadOnly()) ? "slave" : "master"; //(2)
    }
}

determineCurrentLookupKey() 메서드는 현재 조회 키를 반환받기 위해 구현해야 하는 추상 메서드입니다.
따라서 저희는 readOnly 속성을 구별하여 key를 반환하게 합니다.

AbstractRoutingDataSource Bean 등록하기

@Bean
@Primary
@DependsOn({MASTER_DATASOURCE, SLAVE_DATASOURCE})
public DataSource routingDataSource(
    @Qualifier(MASTER_DATASOURCE) DataSource masterDataSource,
    @Qualifier(SLAVE_DATASOURCE) DataSource slaveDataSource) {

    RoutingDataSource routingDataSource = new RoutingDataSource();

    Map<Object, Object> datasourceMap = new HashMap<>() {
        {
            put("master", masterDataSource);
            put("slave", slaveDataSource);
        }
    };

    routingDataSource.setTargetDataSources(datasourceMap);
    routingDataSource.setDefaultTargetDataSource(masterDataSource);

    return routingDataSource;
}

routingDataSource Bean으로 생성하여 ~~@Primary를 선언하여 DataSource 타입에 바인딩되는 객체로 정의합니다.~~

꼭! 궁금한 부분까지 읽어주세요 ! 아직 설정해야하는 부분이있습니다.

결과 확인

@Service
@RequiredArgsConstructor
@Transactional
public class BoardService {

    private final BoardRepository boardRepository;
    private final DataSource dataSource;

    @Transactional(readOnly = true)
    public List<Board> getBoardList(){
        return boardRepository.findAll();
    }

    public List<Board> updateTitle() {
        List<Board> boards = boardRepository.findAll();
        for (Board board : boards) {
            board.setTitle("newTitle");
        }
        return getBoardList();
    }
}

이러한 서비스 코드가 존재할 때

getBoardList() 는 readOnly = ture 임으로 -> jdbc:mysql://localhost:3307 으로

updateTitle() 는 readOnly =false 임으로 -> jdbc:mysql://localhost:3306 으로

-> 여기서 중요한 점은 method의 시작 트랜잭션이 읽기 전용이 아님으로 내부에서 getBoardList() 을 호출하였을 때 Slave DB에 쿼리가 발생하는 것이 아닌 Master DB로 query 가 발생합니다.

궁금한 점 ??!!

해당 주제를 공부하면서 많은 예제와 블로그를 찾아본 결과

@Bean
@DependsOn("routingDataSource")
public LazyConnectionDataSourceProxy dataSource(DataSource routingDataSource){
    return new LazyConnectionDataSourceProxy(routingDataSource);
}

해당 예제처럼 AbstractRoutingDataSource를
LazyConnectionDataSourceProxy로 한번 감싸는 예제들이 많았다.

이렇게 감싸는 이유로는 다음과 같이 설명하고 있다.(link)

TransactionManager 선별 -> DataSource에서 Connection 획득 -> Transaction 동기화(Synchronization)

여기서 보면 트랜잭션 동기화를 마친 뒤에 ReplicationRoutingDataSource.java에서 커넥션을 획득해야만 이게 올바로 동작하는데 그 순서가 뒤바뀌어 있기 때문이다.

따라서 LazyConnectionDataSourceProxy 한번 감싸서 다음과 같이 작동하게한다.

TransactionManager -> LazyConnectionDataSourceProxy에서 Connection Proxy 객체 획득 -> Transaction 동기화

실제 쿼리 호출시에 ReplicationRoutingDataSource.getConnection()/determineCurrentLookupKey() 호출

잘못된 테스트

~~그래서 정말 그런가 싶어서 LazyConnectionDataSourceProxy 감싸지 않고~~
~~AbstractRoutingDataSource 을 빈으로 등록 사용하였는데~~

~~readOnly = ture/false 속성에 따라 Master / Slave DB에 원하는 대로 잘 쿼리가 분배가 된다.~~

따라서 제가 이해하지 못하여 이렇게나마 소개하고자 합니다.

추 후 LazyConnectionDataSourceProxy에 대해 파악하여 본문에 추가하도록 하겠습니다.

+++ 추가

LazyConnectionDataSourceProxy 으로 한번 감싸지 않고 사용할시 앞서 설명하고 있는것처럼
AbstractRoutingDataSource 로 사용할시 모든 쿼리가 Master DB 로 가는 현상이 있었다.

따라서 Transaction 동기화 시점에 커넥션을 획득하기 위해 LazyConnectionDataSourceProxy 로 한번감싸주어야 한다.

긴 글 읽어주셔서 감사합니다.

부족한 내용이나 틀린 내용이 있다면 댓글로 남겨주세요!

참고자료

[Spring boot] 여러 필드를 검사하기위한 Custom Valid Annotation 만들기

jay Joon — Fri, 25 Jun 2021 20:33:25 +0900

서론

스프링 컨트롤러에서 클라이언트로부터 받은 값을 검증하기 위해 Validation을 많이 사용하곤 합니다.

JSR 380이 제공해주는 Bean Validation 의 종류는 다양하지만 각자의 서비스에 따라
기본적으로 제공해주는 애노테이션만으로는 검증을 모두 다 지원해주지는 못합니다.

따라서 상황에 따라 각 서비스에 맞는 커스텀한 Validation을 만들어서 활용하기도 합니다.

그렇다면 이번 글에서는 왜 커스텀 Validation을 만들었고 만드는 과정을 소개하고자 합니다.

왜 필요한가?

기존 @NotNull, @NotEmpty, @NotBlank, @Email 등의 애노테이션으로 클라이언트 요청으로 값을
검증하는 것은 필드 자체의 형식이나 값을 체크하는 용도로만 사용됩니다.

즉 필드와 필드를 비교하여 검증하는 로직이 서비스 로직에 포함되는 경우가 발생하게 됩니다.

예시

-------------------------------------------------------------------------------------------------------------

예약시간 , 예약종료시간 이라는 필드가 존재할 때 기본적으로 예약시간이 예약 종료시간보다 늦을 수는 없습니다.

결국 예약시간 , 예약종료시간 이 알맞게 들어왔는지 확인하기 위해 다음과 같은 코드를 작성하게 됩니다.

if (reservationStart.isAfter(reservationEnd)){
  //TODO Exception
}

과연 이러한 코드는 비즈니스 로직에 몇 번이나 포함이 될까요?

예약을 저장, 예약시간을 변경, 선택 시간 범위 내 존재하는 예약 리스트 반환 등등 클라이언트로 요청이 넘어온 예약시간 , 예약종료시간 필드들은 항상 검증을 해야 합니다.

이러한 방법은 어쩔 수 없이 중복 코드를 발생시키고 까먹고 검증과정을 누락하여 버그를 발생시킬 수 있습니다.

또한 이러한 검증 로직이 서비스 레이어까지 내려오는 것이 맞을까요?

단순히 입력값 자체를 비교하는 과정은 조금 더 외부 Layer에서 처리하는 것이 좋을 것 같습니다.

Custom Valid Annotation 만들기

클라이언트로 받을 DTO는 다음과 같습니다.

@StartAndEndTimeCheck(startDate = "reservationStart", endDate = "reservationEnd") //해당 애노테이션을 만들고자합니다.
public class RequestOrder {

    @NotBlank
    @ApiModelProperty(value = "메뉴이름", required = true, example = "다운펌")
    private String menuName;

    @NotBlank
    @ApiModelProperty(value = "회원 전화번호", required = true, example = "01012345678")
    private String memberPhoneNumber;

    @NotBlank
    @ApiModelProperty(value = "디자이너 이름", required = true, example = "디자이너")
    private String designerName;

    @DateTimeFormat(iso = DateTimeFormat.ISO.DATE_TIME)
    @NotNull
    @ApiModelProperty(value = "예약 시작시간", required = true, example = "2021-06-16T11:40")
    private LocalDateTime reservationStart; // 필드 비교 대상

    @DateTimeFormat(iso = DateTimeFormat.ISO.DATE_TIME)
    @NotNull
    @ApiModelProperty(value = "예약 끝나는시간", required = true, example = "2021-06-16T12:40")
    private LocalDateTime reservationEnd; // // 필드 비교 대상

}

저희의 목적은 @Valid 를 이용하여 기존 서비스 로직에 존재하는 검증 로직을 제거하는 것이 목표입니다.

@StartAndEndTimeCheck 만들기

@Target(ElementType.TYPE) 
@Retention(RetentionPolicy.RUNTIME)
@Constraint(validatedBy = StartAndEndTimeCheckValidator.class)
public @interface StartAndEndTimeCheck {

    String message() default "에약시작 시간이 예약종료 시간 보다 늦을수 없습니다.";  // 예외가 발생하면 출력할 메세지

    Class<?>[] groups() default {};

    Class<? extends Payload>[] payload() default {};

    String startDate(); // 대상 객체의 시작시간 필드 이름을 담을 그릇

    String endDate(); // 대상 객체의 종료시간 필드 이름을 담을 그릇
}

사용할 커스텀한 애노테이션을 만듭니다.

이제 커스텀 애노테이션을 만들었으니 작동할 validator를 생성하면 끝입니다.

StartAndEndTimeCheckValidator

public class StartAndEndTimeCheckValidator implements ConstraintValidator<StartAndEndTimeCheck, Object> {
    private String message;
    private String startDate;
    private String endDate;

    @Override
    public void initialize(StartAndEndTimeCheck constraintAnnotation) {
        message = constraintAnnotation.message();  // 애노테이션에 저장된 메세지
        startDate = constraintAnnotation.startDate(); // 애노테이션에 저장된 비교할 필드
        endDate = constraintAnnotation.endDate(); // 애노테이션에 저장된 비교할 필드
    }

    @Override
    public boolean isValid(Object o, ConstraintValidatorContext context) {

        int invalidCount = 0;
        LocalDateTime reservationStart = getFieldValue(o, startDate);
        LocalDateTime reservationEnd = getFieldValue(o, endDate);
        if (reservationStart.isAfter(reservationEnd)) { // 검증 후 오류가 있다면
            context.disableDefaultConstraintViolation();
            context.buildConstraintViolationWithTemplate(message)//context에 오류메세지와 
                .addPropertyNode(startDate)//대상 필드를 넣어줍니다.
                .addConstraintViolation();
            invalidCount += 1;
        }
        return invalidCount == 0;
    }
	
  	// 리플렉션을 이용하여 필드를 가져옴 
    private LocalDateTime getFieldValue(Object object, String fieldName) {
        Class<?> clazz = object.getClass();
        Field dateField;
        try {
            dateField = clazz.getDeclaredField(fieldName);
            dateField.setAccessible(true);
            Object target = dateField.get(object);
            if (!(target instanceof LocalDateTime)) {
                throw new ClassCastException("casting exception");
            }
            return (LocalDateTime) target;
        } catch (NoSuchFieldException e) {
            log.error("NoSuchFieldException", e);
        } catch (IllegalAccessException e) {
            log.error("IllegalAccessException", e);
        }
        throw new ServerErrorException("Not Found Field");
    }
}

ConstraintValidator<StartAndEndTimeCheck, Object> 여기서 왜 Object 형태를 사용하는가?
해당 애노테이션을 어떠한 특정 DTO에 종속되게 사용하지 않고 범용적으로 재활용하기 위해서 Object 형태로 받았습니다.

따라서 Object 형태로는 필드의 값을 가져오지 못해

@StartAndEndTimeCheck(startDate = "reservationStart", endDate = "reservationEnd")

리플랙션을 이용하여 특정 필드의 값을 가져올 수 있도록 하기 위해서 위처럼 애노테이션으로 대상 필드 Name을 받았습니다.

사용

사용법은 간단합니다.

해당 커스텀 애노테이션의 값에 대상 필드를 작성합니다
(Type safe 하지 않다는 단점이 존재하네요 필드 철자가 틀리면 오류가 발생합니다. )

@StartAndEndTimeCheck(startDate = "reservationStart", endDate = "reservationEnd")
public class RequestOrder {
  //생략
    private LocalDateTime reservationStart;
    private LocalDateTime reservationEnd;

}

@StartAndEndTimeCheck(startDate = "reservationStart", endDate = "reservationEnd")
public class RequestOrderTimeEdit {
    private Long id;
    private LocalDateTime reservationStart;
    private LocalDateTime reservationEnd;
}

컨트롤러에 @Valid를 붙여 검증을 하시면 됩니다.

@PostMapping("/order")
@ApiOperation(value = "예약 추가", notes = "예약 일정을 생성합니다.")
//@Valid 애노테이션으로 검증
public ResponseEntity<ResponseOrder> createOrder(@RequestBody @Valid RequestOrder requestOrder) { 
    ResponseOrder order = orderService.saveOrder(requestOrder);
    return ResponseEntity.ok(order);
}

오류 발생 시 응답 결과

요청

Request Post /order
{
  "designerName": "디자이너",
  "memberPhoneNumber": "01012345678",
  "menuName": "다운펌",
  "reservationEnd": "2021-06-16T12:40",  
  "reservationStart": "2021-06-16T13:40"  // 현재 시작시간이 종료시간보다 늦습니다  
}

응답

해당 오류 응답처럼 내보내기 위해 저는 GlobalExceptionController를 만들어서 처리하였습니다.

프로젝트를 확인해주세요!

결론

클라이언트가 요청한 내부의 단순 값과 값의 비교에 따라 비즈니스 로직 처리가 필요한 경우

Service Layer에서 일일이 검증하는 것보다는 Custom Valid Annotation을 이용해 보는 것도 좋을 것 같습니다.

긴 글 읽어주셔서 감사합니다.

본문에 존재하는 오류나 질문은 댓글로 남겨주세요!

RR

Spring boot CircuitBreaker 간단하게 알아보기

- 개요 -

- 본문 -

설정

조금 더 알아보기

마무리

[Spring-batch] Job 에 대해 알아보자!

기본개념

기본 구현체

Job 은 어떻게 만들어지고 어떻게 실행되는 걸까??

​

JobInstance, JobExecution에 대해 알아보자

JobInstance

JobExecution

Spring Config 서버는 필요할까?

왜 필요한가?

만약 Config Server 가 있다면 편해질까?

결론

신입 개발자가 되기까지(취업준비 후기)

총평: 힘들었다..

나는 "비전공자" 다.

어떻게 공부했는가?

본격적인 취업준비 활동

첫 면접은 탈락이지!

계속되는 탈락

합격

끝맺음

MySQL LIKE % 위치에 따른 인덱스 사용 여부

서론

Table 구조

1. 'ABC%' 데이터 시작 형식을 검색하는 경우

2. '% ABC' 끝나는 데이터 형식을 검색하는 경우

3. '%ABC%' 데이터에 포함하는지 검색하는 경우

왜? AB% 를 제외한 나머지 방식은 인덱스를 타지 않을까?

그럼 어떻게 검색해야 하는가?

참고자료

나는 JPA 를 왜(알고) 사용하고 있을까?

JPA(ORM) 기술은 왜 사용하는가?

JPA와 hibernate의 관계

JPA는 단지 자바 진영의 표준 ORM 기술이다.

그렇다면 JPA는 단점이 없는가?

편안함에서 오는 복잡함(무슨 소리야? )

높은 학습비용

성능

나는 왜 JAVA 를 사용하게되었는가?

해당 주제에 대한 답변으로 어떤 게 떠올르시나요?

지금은 왜 사용하고 있는지 아는가?

마무리

[JPA] findById() , getById() 에 대한 생각

서론

사전 설명

findById()

getById()

나의 생각

결론

[Spring-boot] Master - Slave 구조에 따른 Read, Write 분기

서론

사전 환경설정

본문

application.yml 설정

DataSource Bean 등록하기

AbstractRoutingDataSource 구현

AbstractRoutingDataSource Bean 등록하기

결과 확인

궁금한 점 ??!!

참고자료

[Spring boot] 여러 필드를 검사하기위한 Custom Valid Annotation 만들기

서론

왜 필요한가?

Custom Valid Annotation 만들기

@StartAndEndTimeCheck 만들기

StartAndEndTimeCheckValidator

사용

오류 발생 시 응답 결과

결론