스프링에 대해 공부하면서 그리고 프로젝트를 진행해보고 여러 예제 코드들을 접해보면서 느낀 것은 관습적으로 브릿지 패턴을 이용한 추상화를 사용하고 있다는 점입니다. 관습적인 추상화 계층화된 아키텍처인 MVC 패턴을 적용한 대부분의 프로젝트에서는 그 중에서도 Service 계층에서는 MemberService 와 같이 서비스를 인터페이스로 생성하고 MemberServiceImpl 이라는 구현체를 생성해서 사용하는 방식으로 대부분의 설계가 이루어집니다. 토비의 스프링이나 여러 객체지향과 스프링 관련 책들을 보면 이와 같은 패턴으로 설계를 해야하는 이유에 대해서 잘 설명하고 있습니다. 인터페이스와 구현체의 분리를 통해 특정 기술이나 외부환경에 독립적으로 보다 자유로운 확장이 가능해진다는 OCP 원칙에 입각한 분명..

HikariCP hikariCP는 스프링 부트 2.0부터 default JDBC connection pool이다. hikariCP github사이트에 가보면 엄청 빠르고, 가볍고, 신뢰할 수 있다고 설명한다. 심지어 "zero-overhead"라며 엄청나게 높은 성능을 강조하고 벤치마크 결과도 보여준다. 원하면 벤치마크 테스트 소스도 가져가서 직접 돌려보라고도 하는데 자세한건 모르겠고 나만의 테스트 환경을 만들어서 테스트 해보기로 했다. 스프링 부트에서 hikariCP 성능 테스트 PC 사양도 중요하고 인터넷 사양도 중요하고 로컬 DB냐 원격 DB냐도 갈리고 여러 환경이 중요한 것으로 아는데 크게 생각 안하고 단순히 직접 경험해본다에 중점을 두었다. 먼저 hikariCP는 스프링부트 2.0부터 defau..

OAuth1 란 OAuth는 Open Authorization, Open Authentication 뜻하는 것으로 애플리케이션(페이스북,구글,트위터)(Service Provider)의 유저의 비밀번호를 Third party앱에 제공 없이 인증,인가를 할 수 있는 오픈 스탠다드 프로토콜이다. OAuth 인증을 통해 애플리케이션 API를 유저대신에 접근할 수 있는 권한을 얻을 수 있다. OAuth가 사용되기 전에는 외부 사이트와 인증기반의 데이터를 연동할 때 인증방식의 표준이 없었기 때문에 기존의 기본인증인 아이디와 비밀번호를 사용하였는데, 이는 보안상 취약한 구조였다. 유저의 비밀번호가 노출될 가망성이 크기 때문이다. 그렇기 때문에 이 문제를 보안하기 위해 OAuth의 인증은 API를 제공하는 서버에서 진..

Spring + Webflux ​ Webflux (Reactive) 를 이해하기 위해 sync, async, blocking, non-blocking 차이를 이해해야 했고, async 한 코딩을 위해 CoroutineScope 를 사용하면 편리하다는 점을 알게 되었습니다. Webflux 를 이해하기 위해 일반 sync + blocking 코드를 async + non-blocking 코드로 변환해가며 이해하고자 노력하였습니다. ​ #1 Sync 코드 ​아래 코드를 보면, 1~3 까지 출력을 두번 합니다. 첫번째 loop문이 끝나야 두번째 loop문을 실행합니다. 순서대로 코드가 실행되며 (sync), 앞의 loop문은 뒤의 loop문을 blocking 한다고 볼 수 있습니다. (1..3).forEach {..

Scouter 신버전 (2.10.0) 에서 WebFlux 를 지원한다고 한다. 다음에 써봐야지! ​ --- 많은 팀, 회사에서 Webflux 를 도입, 테스트, 실패(?) 등을 겪는 이야기를 많이 듣고 있다. 왜 도입을 시도하고, 어떤 이유로 실패를 하는지 등에 대해 정리해보고자 한다. 이론과 실전은 다르기에, 직접 스트레스 테스트를 진행해 보았고, Thread 구조, CPU 사용량, Memory 사용량, 응답시간 등을 보며 이해하고자 노력했다. ​ 알아보고자 하는 내용 1. Webflux (nio) 는 MVC (bio) 보다 빠를까? 2. webflux 에 blocking 로직이 들어가더라도 MVC 보다 빠를까? (blocking: JDBC query 실행 같은 Async 를 지원하지 않는 로직을 의미..

트랜잭션의 전파 설정이란 Spring에서 사용하는 어노테이션 '@Transactional'은 해당 메서드를 하나의 트랜잭션 안에서 진행할 수 있도록 만들어주는 역할을 합니다. 이때 트랜잭션 내부에서 트랜잭션을 또 호출한다면 스프링에서는 어떻게 처리하고 있을까요? 새로운 트랜잭션이 생성될 수도 있고, 이미 트랜잭션이 있다면 부모 트랜잭션에 합류할 수도 있을 것입니다. 진행되고 있는 트랜잭션에서 다른 트랜잭션이 호출될 때 어떻게 처리할지 정하는 것을 '트랜잭션의 전파 설정'이라고 부릅니다. 전파 설정 옵션 트랜잭션의 전파 설정은 '@Transactional'의 옵션 'propagation'을 통해 설정할 수 있습니다. 각 옵션은 아래와 같습니다. REQUIRED (기본값) 부모 트랜잭션이 존재한다면 부모 트..

스프링에서 feign client를 사용중 로그에 다음과 같은 오류 메시지가 떴다. feign 사용 중에 간헐적으로 unexpected end of stream on [주소] 가 나왔다. request 를 요청받는 서버 설정마다 다른 것 같다. 해당 원인은 요청받는 서버의 keep_alive timeout 이 feign 로 요청하는 클라이언트 서버보다 timeout 시간이 짧기 떄문이다. 다시 말하면 클라이언트 서버가 timeout 이 받아주는 서버 timout 보다 길다. 나의 경우는 feign 로 요청하고 나서 프로세스가 조금 긴 경우에 다음과 같은 현상이 나왔다. 클라이언트가 서버에서 데이터를 받고나서 서버의 keep_alive timeout 시간이 지났음에도 클라이언트에서는 프로세스가 끝나지 않기..

Controller에 요청이 들어오기전에 무엇인가를 수행한다는 기능만 보면 interceptor와 filter는 무척 비슷해 보인다. (전, 후처리기 역할을 수행한다.) 위의 사진을 보면 차이점을 쉽게 알 수 있는데, 둘다 컨트롤러 전에 작업을 처리하는 용도로 사용되지만 호출되는 시점이 다르다. 필터(Filter)는 dispatcherServlet으로 요청이 가기전에 실행되고 인터셉터(Interceptor)는 Controller로 요청이 가기전에 실행이된다. Filter DispatcherServlet 앞단에서 정보 처리 J2EE 표준스펙에 정의되어 있는 기능 Interceptor DispatcherServlet에서 Handler(Controller)로 가기전에 정보 처리 SpringFramework에서..

Spring framework Annotation 개념 XML : 분리 - 결합도를 낮추고 유지보수성을 높이기 위해 xml로 설정하였으나 xml이 너무 많아지면 오히려 유지보수성이 낮아지는 아이러니한 상황 발생 - 유지보수성에 방점 - 시스템 전체에 영향을 주고 이후에 변경 가능성이 있는 것은 xml로 설정. https://medium.com/@2xel/spring-framework-annotation-%EA%B0%9C%EB%85%90-c26c15716538 @Component 태그를 추가하면 어노테이션이 적용된 클래스를 빈으로 등록하게된다. 태그는 어노테이션과 관련해서 BeanPostProcessor를 함께 등록한다. @Required(RequiredAnnotationPostProcessor) @Aut..

spring boot 2.5 버전 이상 사용시 Spring Security의 기본적인 정책은 URL에 더블슬래시가 들어가는 것을 허용하지 않는다. 예를 들면, test라는 리소스를 요청할 때 > http://localhost:8080/api/test 라는 URL을 사용한다고 해보자. WEB 소스에서 baseURL 을 잘못설정 뭐 그러한 이유로 http://localhost:8080/api//test 로 요청이 들어오면 서버에서는 아래와 같은 에러가 발생한다. org.springframework.security.web.firewall.RequestRejectedException: The request was rejected because the URL was not normalized. at org.spr..