도입 배경@Aysnc와 @Scheduler를 통해서 배치기능을 충분히 만들 수 있었지만, 다음 같은 이유로 Spring Batch를 도입하였습니다.프로젝트에서 배치 기능이 필요한 기능이 몇가지 있어서 배치 기능이 필요한 기능들을 따로 한 서버에 두고 관리하고 싶었습니다.chunk 별로 묶어 실패시 따로 로직을 구현하고 싶었습니다.jpa의 장점을 좀더 활용하고 싶었습니다. Spring Batch 도입쿠폰 만료 알림에 대한 기능 뿐만 아니라 회원 휴면 기능, 책 정보 동기화 기능 같은 배치 작업이 필요한 코드들을 한 곳에 모음으로써 배치 기능에 대한 작업이 편해졌습니다. 또한 작업을 10개의 청크로 모아서 처리하였습니다. CouponBatchConfiguartion@RequiredArgsConstructor..

설계 배경토스 페이먼츠 API로 결제를 할 경우 아래와 같은 순서의 요청으로 결제가 완료가 됩니다. 즉 클라이언트와 서버의 로직인 한 인스턴스 내에 있으면 트랜잭션으로 묶어서 최종 결제 실패시 롤백을 할 수 있지만, MSA 기반 프로젝트에서는 트랜잭션으로 묶기가 애매해졌습니다. 트랜잭션 설계결국 서버단에서의 결제 정보를 받고 결제 승인 API 로직을 bookstore 최종결제 트랜잭션에 @Transaction에 전파속성을 required로 설정하여 추가하였습니다.트랜잭션 설계 코드PaymentController/** * 페이먼츠 비회원 컨트롤러. * * @author 김병우 */@Slf4j@Controller@RequiredArgsConstructorpublic class PaymentGuestContr..

도입 배경처음 쿠폰 발급은 HTTP 요청을 통해서 발급을 처리했었습니다.요청이 많이 없을때는 문제가 없었지만, 1초에 10번의 요청이 1000번 들어왔을때 요청의 45%가 오류가 나는 것을 Jmeter로 확인하였습니다.이러한 이유에 보다 안정적인 발급 처리와 기능적인 확장을 위해 RabbitMQ를 도입하게 되었습니다.문제 정의문제가 뭐였는지 먼저 찾으려고 노력했습니다.이벤트 쿠폰을 발급했을 때 쿠폰 발급 기능을 Open Feign 요청으로 트랜잭션을 묶게되면 다음과 같은 순서로 로직이 처리됩니다.쿠폰 이벤트 페이지 조회쿠폰 발급 버튼 클릭 후 회원 테이블에서 회원 아이디 조회쿠폰 서버에서 쿠폰 생성 후 수량 차감회원 알림으로 쿠폰 번호 전달(정상응답출력)서버의 인스턴스가 2코어 8GB RAM이기 때문에 ..

MSA 기반 프로젝트르 진행하면서 Front에서 url만 가지고 알맞는 서버에 요청을 보내기 위해 게이트웨이를 설계했는데 그부분에 대해서 설명하려고합니다.설계 배경MSA 환경에서 그림 처럼 프론트에서 Gateway를 통하지 않고 각각의 서버에 접근한다면 IP, port를 각각 알아서 하드코딩을 통해서 설정해줘야하는 번거로움이 있습니다. 공통 요청 처리를 위한 게이트웨이 설계  이런 문제점을 해결하기 위해 위와 같이 중간에 ClientSide 로드 밸런싱을 통해서 Gateway를 추가해줬습니다. 모든 백엔드 서버를 Eureka에 등록하여, Eureka Cache가 서버들의 IP와 Port를 관리하도록 하였고, 이를 통해 Gateway에서 서버 이름을 기반으로 라우팅하여 네트워크를 구축하였습니다. 이러한 이..

서점 프로젝트를 진행하면서 로그인 구현을 어떻게 했는지 차근차근 설명하겠습니다. 1. 초기 인증 구현처음 구현할때 인증을 로그인 세션을 이용해서 사용했습니다. 하지만 한가지 큰 문제가 있었습니다.MSA 기반 프로젝트기 때문에 세션을 사용하니 모든 서버를 사용할 때 마다 인증을 요청해야했다. (즉, 다른 서버에서는 이 사용자가 인증했는지 안했는지 알 수가 없다) 2. JWT 인증 도입위의 문제를 해결하고자 인증서버에서 JWT 토큰을 만들고 게이트웨이에서 모든 요청을 검사하여 쿠키에 토큰이 있으면 JWT 토큰을 확인해서 모든 요청의 헤더에 Member-Id를 추가해서 요청을 보내게 했습니다. 이렇게하여 모든 서버를 사용할 때 마다 인증을 할 필요가 없었고 게이트웨이에서 토큰을 확인만 하면 사용자를 확인할 수..

이번 게시글은 회원 장바구니 정보 뿐만 아니라 비회원 장바구니 정보를 영구저장 시키기 위해 ERD 설계를 어떤 방식으로 했는지 설명하려고합니다. 초기 설계 및 수정 배경정말 초기 설계여서 그림이 없지만 도서, 회원 사이에 도서회원 장바구니 테이블을 두어 1대다 다대1로 연결하여 회원의 장바구니만 영구저장을 하고, 비회원의 장바구니 데이터는 세션이나 Redis로 따로 처리하려고 했습니다.이렇게 설계하니 몇가지 문제점이 생겼습니다.비회원의 장바구니 데이터를 영구저장할 수 없다. 비회원과 회원의 장바구니를 따로 관리해야한다. 최종 설계기존 설계에서 책 장바구니 테이블과 회원 테이블 사이에 장바구니를 추가하였습니다. 비회원은 장바구니 ID를 쿠키로 보내주는 것을 통해서 비회원의 장바구니 데이터를 DB에서 영구저..

서점 프로젝트를 진행하면서 MSA기반으로 하다보니 팀원들이 어떤 API를 구현해놨는지 알기 어렵기 때문에 결국 API 명세서를 작성해서 만들기로 했습니다. 그러던중 Swagger, Rest Docs를 접하게되었고 어떤 기술을 사용할지 고민했습니다. 이 글에선 어떤 생각으로 두가지를 같이 쓰기로했는지 설명할까합니다. Swagger장점API를 테스트해 볼 수 있는 화면을 제공API문서가 자동으로 생긴다어노테이션을 통해 문서가 생성되기 때문에 API 문서화가 쉽다(Rest Docs에 비해서)단점 프로덕션 코드에 문서화를 위한 코드가 들어간다. (코드가 많이 복잡해진다, 안그래도 어노테이션이 덕지덕지 붙어있는데 더 붙는다)서버가 실행됨가 동시에 문서가 만들어지기 때문에 API 스펙만 분리해서 관리하기 어렵다 R..

구글링하면 장바구니나 주문 같은 ERD 설계는 대부분 비슷한데 쿠폰 ERD 설계는 정말 제각각이어서 이번 프로젝트를 진행하면서 고민하여 만든 확장성을 좀 고려하려고 노력했던 쿠폰 ERD설계를 소개해볼려고합니다.  최초 설계의 문제점첫 쿠폰 ERD설계는 카테고리 쿠폰, 북 쿠폰이 있을 수 있다고 가정했고 쿠폰 타입은 비율 쿠폰과 고정 할인 쿠폰이 있어 이 값들을 필요한 테이블을 끌고와서 쿠폰양식으로 사용해 IS-A관계로 ERD를 설계했습니다. 이 설계에는 제가 생각하기에 3가지 문제점이 있었습니다. 1. FK에 NULL을 허용해 줘서 외래키에 제약조건을 만들지못해 NULL 값을 체크를 하지못하는 문제점이 있다.설계자의 의도와 다르게 값이 들어가 데이터의 무결성 관리가 힘들어진다. 2. 설령 1번의 문제점으..