종우의 삶 (전체 공개)

기존의 테스트가 로그도 부실하고 쓸모없는 체크과정이 많아서 좀 변경해보았다. Controller에서는 간단한 로깅만 실시하고Service 쪽에서 더 상세한 로그를 나누어 보았다. @Transactionalpublic OrderResponse createTimeOrder(Long customerId, Long productId, Long quantity) { log.info("주문 시작 - CustomerId: {}, ProductId: {}, Quantity: {}", customerId, productId, quantity); if (stockExhausted.get()) { log.warn("재고 소진 - CustomerId: {}, ProductId: {}", customer..

예약 구매 시나리오에 맞게, 특정 시간에 많은 주문이 몰리게되는 테스트를 진행했다.  주어진 상황특정 시간에 상품이 오픈되면 한정된 재고 (eg. 10개) 를 1만명이 구매하려한다.구매, 결제 과정에서 20% 는 이탈하게 되고, 그 재고도 다시 반영하여 구매자들에게 제공되어야한다. 대충 이런 형태인데, 기존에 만들었던 로직과는 좀 다른 느낌이어서 새로운 API로 만들어 보았다.  @Slf4j@Service@RequiredArgsConstructorpublic class TimeOrderService { private final ProductClient productClient; private final PaymentClient paymentClient; private final Order..

프로젝트 진행 과정에 발생한 트러블 슈팅을 정리해본다. 프로젝트 진행 중에 있던 내용으로, 최종 프로젝트 상태와 문제 발생 당시의 상태는 다를 수 있음. 증상 : 회원 가입 로직을 진행할 때, 입력한 메일 주소로 인증 메일을 보낸다.그리고 링크를 클릭하면 회원가입이 정상적으로 완료되는 형태이다. 링크를 클릭한 순간 DB에 정상적으로 회원의 데이터가 저장이 된다. 회원 가입시 필요한 데이터는 다음과 같이 입력한다.{ "customerName": "testname", "password": "1234", "email": "test@email.com", "address": "무명도 무명시 도로명주소", "addressDetail": "0000호"} 링크를 클릭하면, 입력받은 데이터를 ..

MSA로 전환하면서 간단한 아키텍처 다이어그램을 다시 그려보았다. 기본적인 로직은 아래와 같다. 이전 포스트에서 설명했다시피 Eureka로 묶인 서비스들은 API Gatway로 들어온 요청들을 처리하게 된다. 그 과정에서 서로의 서비스를 불러오고, 다른 서비스의  DB를 조회해야 할 필요가 생긴다. Kafka를 고려하기도 했지만, 요청을 보내고 반드시 응답이 돌아와야 다음 로직이 가능하기 때문에 Kafka와 같은 메시지 브로커는 적합하지 않다고 생각했다.이러한 단순한 데이터 전송은 동기적으로 처리되어야 한다. 그래서 간단한 Feign Client를 사용하여 서비스 간 통신을 진행해보았다. 사례 1) 특정 상품을 주문에 추가하려 할 때이러한 상황이 주어졌다고 생각해보자. 주문을 하기 위해서는 우선 상품을 ..

0. 모놀리식으로 개발중인 현재 프로젝트를 어떻게 분리하고 MSA로 변경할 수 있을까?가장 중요한 사안은 서비스 분리가 수월하도록 각 서비스와 계층간 의존성을 낮춰야 한다는 것이다. MSA에 대해 알아보기Monolithic Architecture지금까지 개발해왔던 형태를 모놀리식 아키텍쳐라고 할 수 있겠다. 하나의 프로젝트에 모든 서비스와 기능들이 들어가있다. 모듈 단위로 쪼개지는 것이 아니라 프로젝트 단위로 개발이 진행되는 것.  현재 회원, 주문, 상품 등의 서비스가 존재한다면 계속해서 기능들이 추가 될 때마다 프로젝트 내의 코드의 양이 점점 증가할 것이다. 모놀리식의 장점이자 단점이 필요한 기능이 전부 한 곳에 모여있는 것인데, 초기 개발에 적합하여 빠르게 MVP를 만들 수 있지만 프로젝트의 크기가..

* 따로 정리하던 내용들을 하나씩 블로그로 작성함.* 현재 진행중인 MSA 관련 프로젝트에서, 어떤 것들을 진행하고 있는지 살펴보자. * 모놀리식 구성과 이후  MSA의 형태는 약간 다르다. 각각의 단계에서 어떤 것들을 구현하였는지 정리하였다. MSA를 도입하기 전, 우선 하나의 프로젝트를 구성사실 MSA에 대한 큰 고려를 하지 않고 늘 하던대로 하나의 프로젝트를 구성하였는데, 이후 서비스를 분리하여 구성할 때 분리 자체가 어려운 부분이 있었다. 그건 나중의 이야기이므로 현재의 상황을 살펴보자 Customer, Product, Order 3개의 커다란 서비스를 중심으로 세부적인 내용들을 조정하였다. 주요 서비스 외에도 Security, Redis, Api응답을 위한 일반적인 서비스들도 존재한다. Cust..

* 따로 정리하던 내용들을 하나씩 블로그로 작성함.* 현재 진행중인 MSA 관련 프로젝트에서, 어떤 것들을 진행하고 있는지 살펴보자. 프로젝트 소개- Micro Service Architecture를 활용한 E- commerce 서버- Eureka Server, API Gateway를 기반으로 서비스들을 하나로 묶어서 관리함- Customer, Order, Product, Payment 등 필요한 서비스를 나누어 개별적인 서버로 분리- 각 서비스의 DB는 Docker로 운영하였음.  기술 스택- Java 21- Spring boot 3.3- MySQL, Redis, Docker- Eureka, API Gateway  프로젝트 주요 기능- 일반적인 Commerce 서비스를 구성하는 기본적인 기능(상품 등록..