Spring

게시판의 하단에는 위의 이미지와 같이 몇 페이지부터 몇 페이지까지 있는지 볼 수 있다.  그렇다면 이러한 페이징을 하기 위해선 어떤 것을 알아야 할까? 바로 현재 페이지의 위치, 총 페이지 수이다.  총 페이지 수란, 보통 (조회된 모든 데이터 수) / (한 페이지에서 보여줄 글 수) 를 말한다.  그 말은, 위의 이미지처럼 1페이지에서 2페이지, 3, 4, 5 넘어갈 때 마다, 이전에 조회되었던 데이터를 함께 조회해야하는 것이다. 하지만 이전에 조회된 데이터는 사용하지도 않는다.  그냥 뒤에 있는 데이터를 탐색하기 위해 어쩔 수 없이 조회되는 데이터인 것이다.  보통 내가 진행했던 프로젝트는 뭐 게시글이 천만개~1억개 정도는 되는 것이 아니라서 매번 총 데이터의 수를 조회해도 상관없었지만, 실제 현업에..

이제 Spring Batch를 내가 개발중인 프로젝트에 구현해봅시다.  구현하기 전에 필요한 건 프로젝트에 의존성을 설정하는 것과, 배치 관련 메타 테이블을 생성하는 것이다.   설정 build.gradleimplementation 'org.springframework.boot:spring-boot-starter-batch' build.gradle에 Spring Batch의 의존성을 추가한다.   메타 테이블 생성 메타 테이블을 생성하는 방법은 자동 생성, 수동 생성 두 가지 있다. 자동 생성spring: batch: jdbc: initialize-schema: always 메타 테이블 스키마를 자동으로 생성하는 설정 코드이다.  수동 생성-- Autogenerated: do not ed..

개요이전까지 과부하 테스트를 위해 많은 양의 데이터가 필요할 때, 일일이 데이터를 INSERT 해주거나, 반복문, JMeter의 Loop를 사용해 데이터를 추가했다.  위의 이미지는 100,000개의 게시글 데이터를 JMeter의 Loop문을 사용해 테스트한 결과이다.  약 6분의 시간이 소요되었다. 생각보다 많은 시간이 소요되었다..  그래서 이 6분이라는 시간을 단축시킬 수 있는 방법이 있는지 찾아보다가 Spring Batch 라는 기술을 찾게되었다.  Spring 프레임워크에서 Spring Batch를 사용해 대용량 데이터를 처리하는 래퍼런스가 많은 것을 확인하고, 이번 기회에 Spring Batch를 사용해 데이터를 추가해보기로 했다.   Spring Batch란 Spring Batch란 대용량 ..

계층 별로 테스트를 진행할 때, Repository나 Service는 @DataJpaTest나 @SpringBootTest 어노테이션의 경우엔 실제 Bean 객체를 사용하는 것이기 때문에 별 문제없이 테스트를 진행할 수 있다.  하지만 Controller는 조금 다르다. Controller는 사용자의 요청을 전달받는 계층이기 때문에 말 그대로, 데이터를 잘 받을 수 있는지를 테스트하는 영역이다.  그렇다면 다른 계층과 Controller의 테스트 방식이 어떻게 다른지, 어떤 기술을 사용하는지 한번 알아보자.  @WebMvcTest @WebMvcTest는 Controller를 테스트할 때 가장 많이 사용하는 어노테이션이다.  아래는 Spring Framework 공식 홈페이지에 나와있는 @WebMvcTes..

이전 글에서 여러개의 서버에서도 Kafka를 사용한다면 채팅기능을 충분히 구현할 수 있다는 것을 증명했다.  React 애플리케이션이 각각 3000, 3001 등의 포트를 사용하고, 백엔드 서버는 8081, 8082 등의 포트에서 실행될 경우, 각 프론트엔드에서 직접 해당 백엔드로 요청을 보내는 구조를 구현할 수 있다.  그러나 Spring Cloud Gateway를 사용하면, 프론트엔드에서 게이트웨이로 요청을 전송하고, 게이트웨이가 각 백엔드 서비스로 적절히 분산 처리해주는 방식으로 관리할 수 있다.→ 더 유연한 아키텍처 설계 가능!  그리고 이전엔 하나의 EC2에서 채팅 서버를 실행했지만, 이번엔 MSA 구조로 변경해보기로 했다.  아키텍처 구조는 아래와 같다. 위의 구조를 보면 알 수 있듯이 프론트..

채팅 기능을 구현할 때 Spring Boot에서는 주로 STOMP나 Redis를 이용해 WebSocket 기능을 개발한다.  그런데 MSA를 학습하면서 Kafka를 사용하는 과정에서, Kafka의 동작 방식이 Redis를 이용한 채팅 기능 구현과 매우 유사하다는 느낌을 받았다.  이는 Kafka의 Producer와 Consumer가 Redis의 Publisher와 Subscriber 역할을 하고, Kafka는 Kafka 브로커, Redis는 메시지 브로커가 존재하는 형태가 매우 유사하게 느껴졌기 때문이다.  이후 관련 정보를 더 찾아보니 Kafka를 이용해 채팅 기능을 구현한 사례들을 발견했다. 그래서 이번에는 모놀리틱 아키텍처 기반의 채팅 서버가 아닌, MSA 기반의 채팅 서버를 직접 구현해보고자 결심..