땍땍 블로그

개요기존 운영 중인 매장 관리 서비스는 단일 서버로 운영되고 있었지만, 요구사항이 증가함에 따라 서버의 부담이 점차 커지고 있었다.이러한 상황에서 매장 관리 외에 새로운 도메인에 대한 기획이 추가되었고, 도메인 별 서비스 분리의 필요성을 느끼게 되었다.때문에 본격적인 개발에 앞서, 우선 매장 관리 서비스를 분리하기로 결정하였다. 목표메인 서버 (매장 관리 도메인) 의 부담 경감클라이언트에게 단일 진입점 제공 상황매장 관리 서비스를 운영 중인 기존 서버는 여유 자원이 부족해, 새로운 서버를 추가로 구동할 수밖에 없는 상황이었다.그러나 비용적인 제약으로 인프라 변경이 불가능한, 어플리케이션 하나만 구동할 수 있는 수준의 서버를 임시로 확보하게 되었다.이로 인해 별도의 게이트웨이 서버를 구성할 수 없었고, 결..

프로젝트 진행 중, 클라이언트에게 전달 받은 요청을 5분 이후에 처리해야 하는 지연 처리 기능이 필요하게 되었다.이를 위해 다양한 방안을 검토하였고, 최종적으로 Kafka 를 활용해 지연 처리를 구현하게 되었다.해당 글에서는 이러한 지연 처리 구현까지의 접근 방식과 고민 등을 정리하고자 한다. --------------------------------------------------- ⚠️ 상황클라이언트에게 전달 받는 요청을 5분 이후에 처리 해야 함해당 서비스는 다중 서버로 구성기본 메세지 큐로 Kafka 를 사용Redis 는 캐싱, 임시 데이터 저장 등 다용한 용도로 활용 중--------------------------------------------------- 🧪 시도 RabbitMQ , SQ..

[2025-02-03 22:48:44.371] [http-nio-8080-exec-8] [8706cf15-ff91-49be-98c7-236cb49d64c6] ERROR [.error.GlobalExceptionHandler.handleException:25 ] - Content-Type 'application/octet-stream' is not supported[2025-02-03 22:48:44.372] [http-nio-8080-exec-8] [8706cf15-ff91-49be-98c7-236cb49d64c6] ERROR [.error.GlobalExceptionHandler.handleException:26 ] - Exception : org.springframework.web.HttpMediaT..

당연하겠지만, 모든 코드는 작성 후 의도에 맞게 정상 작동하는지 확인하는 과정을 거쳐야만 한다.정말 간단한 코드라도 예상치 못 한 부분에서 문제가 발생할 수 있기에 이를 확인해주는 것이 정말 중요한데Swagger 나, Postman 등을 활용하여 직접 값을 입력해 확인해보는 과정을 거쳐도 되지만 가능하면 테스트 코드를 통해 확인하는 것이 효율적이다.테스트 코드를 작성하기 전, 어떠한 환경에서 어떠한 목적을 갖고 이를 작성할지 정해야만 한다.기본적으로 코드의 전체적인 테스트를 한다는 목적은 변하지 않지만, 예를 들어빠른 시간 내에 최소한의 테스트만을 위해 , 시간이 소요되더라도 완벽한 테스트를 위해 등상세한 목적에 맞춰 작성법이 달라지기에 이를 확실히 하고 작성을 시작하면 되겠다.이번 통합 테스트는,하나의..

코드를 작성하다보면 에러를 발견하는 것은 너무나 당연한 수순이다.이러한 에러를 발견했을 때 이를 해결하기 위해 로그를 확인하고, 문제가 되는 부분을 추적해 해결해야만 한다.하지만, 로그를 한 번이라도 확인해봤으면 알겠지만 이러한 로그는 길이가 짧지 않아 이를 읽고 파악하는데 생각보다 많은 시간이 소요되게 된다.또한, 이러한 로그는 보안상 local 환경에서만 확인할 수 있도록 하여 별도의 처리가 없는 한 API를 가져다 쓰는 프론트 쪽에서는 오류가 발생해도 어떤 것이 문제인지 파악할 수 없는 경우가 빈번히 발생하게 된다.예시를 들어보겠다.아래 코드는 Integer a 를 전달 받고, 해당 값에 +3 을 더한 값을 반환하는 코드이다. @PostMapping("/post") public int po..

공식 문서https://naver.github.io/fixture-monkey/v1-0-0-kor/docs/plugins/jakarta-validation-plugin/features/fixtureMonkey를 사용하여 실제 테스트 코드를 작성하다보면 무조건 한 번씩 발생하는 오류 중 하나가 필드별 제약 조건이다.분명 닉네임 값은 필수 값이며, 최대 20자 까지 밖에 입력이 되지 않아야하지만, fixtureMonkey는 이를 무시하고 null 값을 반환하거나 최대 자리수를 초과하는 값을 생성하곤 한다.이러한 문제는 JakartaValidationPlugin 를 사용하여 해결할 수 있다.사용 가능한 어노테이션은 해당 글 하단에 작성해두었다. 공식 문서에서 가져온 내용이니 시간이 여유롭다면 공식 문서를 참고..

공식 문서https://naver.github.io/fixture-monkey/v1-0-0-kor/테스트 코드를 작성하다보면 객체, 보통 엔티티에 무작위한 값을 넣고 이를 테스트해야하는 경우가 많다.다만 이러한 과정을 위해 시간을 소요하고 동일한 과정을 반복하는 것이 번거롭기에 이를 간단하게 해결 하기 위해 나온 것이 Fixture Monkey이다.사용법은 정말 간단하다.의존성// GradletestRuntimeOnly("org.junit.platform:junit-platform-launcher:{version}")testImplementation("com.navercorp.fixturemonkey:fixture-monkey-starter:1.0.23")// Maven com.navercorp.f..

service , controller 등에서는 mock 을 이용해 로직이 잘 동작하는지를 주목적으로 테스트 코드를 작성 하지만, Repository Test는 실제로 데이터가 DB에 잘 이동하는지 확인하기 위해서 하는 목적이 큰 만큼 mock을 사용하는 것이 아닌 실제 DB를 이용하는 것을 추천한다.실제 DB는 사용 중인 개발/운영 서버의 DB에 테스트 후에 Transaction을 하는 방법도 있겠지만, 데이터가 많거나 실제 운영 중인 서버라면 속도 지연의 원인이 될 수 있기에 테스트 DB는 따로 설정하는 것이 좋다.이를 위해 휘발성 DB인 H2를 이용하도록 하겠다.testRuntimeOnly 'com.h2database:h2'테스트를 진행할 테이블은 Members 테이블이며, 아래와 같은 구조를 가지고..

프로젝트의 규모가 크지 않거나, 시작 단계일 경우 하나의 Repository에서 모든 쿼리를 관리하는 경우를 종종 볼 수 있을 것이다.public interface MemberRepository extends JpaRepository { Optional findByEmailAndNickname(String email, String nickname); List findByRole(Role role); ... 등등}위의 코드는 아직 정의된 메소드가 두 가지 밖에 없기에 잘 와닿지 않겠지만, 관련 쿼리가 몇 십,백개가 넘어가거나현재는 Jpa만 사용하지만 jpsql 혹은 querydsl 등으로 직접 쿼리문을 작성하는 경우 하나에 파일에서 관리하게 되면 코드가 복잡해져 유지보수에 있어 어려움을 느낄 ..

https://start.spring.io/ 에서 생성된 프로젝트를 그대로 실행하였을 경우 springboot가 실행과 동시에 종료가 된다.다양한 이유가 있겠지만, 로그에 Tomcat 관련 내역이 없다면 의존성을 추가하지 않아 발생하는 오류일 가능성이 높다.해결 방법 → 의존성 추가implementation 'org.springframework.boot:spring-boot-starter-web'자칫 org.springframework.boot:spring-boot-starter 과 동일한 의존성인 줄 아는 분들도 계시지만, 다른 의존성이기에 별개로 추가해주어야 한다.