Test Environment 3인 유저 채팅방에서 채팅 추가 시, api의 속도를 확인하는 것으로 cache 적용 전 후 의 성능을 비교했습니다. 기본 전략 반복 읽기가 많은 데이터를 캐싱하였기에 lookl aside +write around 전략을 사용하고, 일관성 유지를 위해 데이터 수정 발생시 캐시 데이터를 버린 뒤, 이후 사용시 캐시를 다시 Hit시켜 캐시메모리에 변경사항을 로딩하는 방식을 사용했습니다. caching 적용 전 api 속도 sql 수행 횟수 기본적으로 chatroom, mem ber의 엔티티를 select하는 sql이 각각 수행되고, 해당 채팅을 db에 insert하는 명령어가 수행된다. 추가적으로, 캐싱을 적용하지 않았으므로 채팅 알림을 보내기 위해 채팅 방 내의 모든 멤버들의..
Spring mvc는 분명 "multi Thread, sync, Blcoking" 방식을 통해 Node.js 대비 이점이 존재하지만, 단점 역시 존재한다. 그리고 이러한 단점이 요즘의 애플리케이션 개발 트렌드에 적합하지 않기에 Spring webflux등의 Reactive Stack을 통한 리액티브 프로그래밍을 통해 이러한 단점을 극복하도록 지원한다. 하지만, Spring의 Reactive Stack와 유사하게, express 기반의 Node.js 역시 async, non-blocking, event-driven 방식을 사용한다. 이번 글에선 스프링 webflux와 유사하게 async, non-blocking, event-driven 방식을 사용하는 Node.js를 비교분석해보겠다. 1) Spring w..
리액티브 프로그래밍 리액티브 프로그래밍은 비동기적인 데이터 스트림을 다루기 위한 프로그래밍 패러다임이다. 이 패러다임은 데이터의 흐름을 중심으로 개발을 진행하며, 데이터의 변경에 반응하여 비동기적으로 처리합니다. 리액티브 프로그래밍은 확장성과 반응성이 중요한 애플리케이션에서 유용하게 활용된다. 리액티브 프로그램의 필요성 1년 치 구독료를 지불하였는데 배달이 오지 않고 1년 치 신문이 모두 준비되면 그제야 배달을 시작한다면 어떻게 될까? 실제로는 기사가 최신일 때 독자가 읽을 수 있도록 출간 후 가능한 빨리 배달된다. 또한 독자가 기사를 읽는 동안 기자는 새로운 다음 기사를 작성한다. 이 모든 것은 병행으로 진행된다. 이처럼 애플리케이션 코드를 개발할 때는 명령형(imperative)와 리액티브(react..
이번 글에선 이론적으로 WebFlux가 Spring MVC에 대비해 어떤 이점이 있는지 분석하고, 외부의 performance Test를 이러한 이론을 증명하겠습니다. WebFlux를 사용하는 이유는? - aync & Non-blocking방식으로 인해 cpu, Thread, memory등의 리소스 낭비 없이 효율적으로 동작한다. - 서비스간 호출이 많은 MSA에 적합하다. spring webmvc vs webflux webmvc - Blocking & sync - 사용자의 요청이 들어올 때 마다 Thread를 생성하여 처리(multi thread) - Thread Pool에서 미리 스레드를 일정 갯수 생성하고 사용(스레드 생성, 삭제 비용의 절감) - 요청이 들어오면 Queue 에 쌓고 순서에 따라서 ..
Spring에서 Reactive Stack과 Servlet Stack의 차이점과 장단점은 다음과 같다. Servlet Stack: Servlet Stack은 전통적인 방식으로 웹 애플리케이션을 처리하는 기술 스택이다. Servlet 컨테이너를 기반으로 동작하며, 요청마다 쓰레드를 생성하여 처리한다. 각 쓰레드는 독립적으로 요청을 처리하고 응답을 반환한다. 장점: - 잘 알려진 기술 스택: Servlet은 오랜 기간 동안 사용되어온 기술로, 많은 개발자들이 익숙하다. - 간편한 개발: Servlet API를 사용하여 간단한 웹 애플리케이션을 구축할 수 있다. - 기존 라이브러리와의 호환성: 많은 서드파티 라이브러리들이 Servlet 기반으로 개발되어 있으며, 기존에 작성된 코드를 쉽게 통합할 수 있다. 단..
이번 글에선 스프링 AOP를 실제로 사용할 때, 주의해야할 사항들에 대해 살펴보자. 스프링 AOP를 프록시 방식의 AOP를 사용하기에 다음과 같은 문제점들이 있다. 1) 내부 호출시 실제 객체를 사용하여 프록시 적용이 안되는 문제 2)프록시 기술 자체의 한계 프록시와 내부 호출 - 문제 스프링은 프록시 방식의 AOP를 사용한다. 따라서 AOP를 적용하려면 항상 프록시를 통해서 대상 객체(Target)을 호출해야 한다. 이렇게 해야 프록시에서 먼저 어드바이스를 호출하고, 이후에 대상 객체를 호출한다. 만약 프록시를 거치지 않고 대상 객체를 직접 호출하게 되면 AOP가 적용되지 않고, 어드바이스도 호출되지 않는다. AOP를 적용하면 스프링은 대상 객체 대신에 프록시를 스프링 빈으로 등록한다. 따라서 스프링은..
어노테이션 기반 개발의 예제를 몇가지 만들어보자. @Trace: 로그 출력 @Retry: 예외 발생해도 일정 횟수 재시도. 과 같은 유용한 AOP를 만들어보자. 우선, AOP를 적용할 예제를 만들어보자. Repository 5번에 1번은 실패하는 Repository를 구성한다. @Repository public class ExamRepository { private static int seq = 0; /** * 5번에 1번 실패하는 요청 */ public String save(String itemId) { seq++; if (seq % 5 == 0) { throw new IllegalStateException("예외 발생"); } return "ok"; } } Service 단순히 Repository를 ..
https://codenme.tistory.com/117 스프링 핵심원리-고급편 7 [스프링 AOP 사용법] https://codenme.tistory.com/116 스프링 핵심원리-고급편 6 [스프링 AOP] https://codenme.tistory.com/115 스프링 핵심원리-고급편 6 [@Aspect AOP] https://codenme.tistory.com/114 스프링 핵심원리-고급편 6 [빈 후처리기] https: codenme.tistory.com 위의 글과 이어지는 내용입니다. 이전의 글에서부터 아래와 같은 포인트 컷 표현식을 사용했는데, 이에 대해 정리해보자. @Pointcut("execution(* hello.aop.order..*(..))") 포인트컷 지시자 지금부터 포인트컷 표현..
