프로젝트/항해99 개인 프로젝트

🍞 상품의 캐싱처리현재 나의 서비스는 대규모 요청을 처리하는 것에 포커싱이 맞춰져있다. 그렇다면 서비스를 사용할때 사용자가 가장 많이 요청을 하는 곳이 어디일까? 바로 전체 상품을 보는 API 요청이 가장 많이 오게 된다는 것이다. 그렇다면 현재 코드를 한 번 돌아봐야 한다. 지금은 사용자가 전체 상품을 보기 위해 요청을 하면 우리의 서비스 DB로 들어가서 전체 상품을 가져와서 응답을 한다 물론 DBMS의 성능이 무척 좋기 때문에 개인이 테스트하는 수준으로는 DB의 과부하를 만들기는 쉽지 않겠지만 가정을 해본다면 DB의 과부하를 발생시킬수 있다는 것이다. 어쨌든 DB의 과부하는 굉장히 위험하다. 해당 서비스가 장애가 발생하면서 아예 먹통이 되어 버릴수도 있다는 것이다. 1차 해결 방법 JPA의 Page..

🥽 굳이 Feign? 기존에 사용하던 방식은 Feign Client로 데이터를 전달하고 응답을 받아서 이어서 데이터를 처리하는 동기방식을 사용하고 있었다. 하지만 쿠폰서비스에서 유저서비스쪽에 쿠폰이 등록되는 것을 꼭 알아야 할까? 즉, 응답이 필요할 것인가 라는 것이다. 역시 답은 "아니다"라는 것이다. 쿠폰의 발급이 진행되었다면 사용자서비스에 해당 사용자의 상황만을 전달하고 사용자에게 쿠폰을 저장해주는 것은 유저서비스에서 진행하면 되는 것이다. ♬ 비동기 통신그래서 비동기 통신을 해서 데이터를 처리하고자 한다. 기존에 Feign은 필요한 데이터를 응답받기위해 동기방식으로 처리된 것을 확인할 수있지만 굳이 응답을 받지 않고 데이터를 전달해서 해당 서비스에게 해야하는 일을 전달만 해주는 방식을 사용해서 ..

💧 선착순 시스템이번 쇼핑몰 프로젝트를 통해 다양한 도전을 해보았고 이번에는 선착순을 통해 할인 쿠폰을 발급하는 로직을 만들어 대규모 트래픽을 어떻게 조종할 수 있을까하고 생각해보았다. 대표적으로 배민의 쿠폰 할인이 가장 먼저 떠올랐다. 만약 밑의 사진 처럼 딱 정해진 시간에 선착순으로 할인권이 발급된다고 한다면 어떻게 될까?이 때 굉장히 많은 트래픽이 모이게 되고 굉장히 많은 트래픽은 서버를 과부하되게 만들고 문제는 곧바로 서비스의 장애로 이어진다. 그래서 대용량 트래픽이 발생하면 기존의 서비스에 문제가 가지 않도록 처리를 해야한다.  줄을 세워보자세상에 어딜가던 사람이 과하게 몰리면 좀 어렵게 말하면 공급에 비해 수요가 너무 많은 곳이라면 어디든 줄 세우기를 하는 것을 알 수 있다.아주 큰 예로 최..

💧 N+1 문제 발생현재 진행 중인 프로젝트가 JPA로 제작이 되고 있는 상황에서 N+1의 문제는 피할 수 없다. 물론 현재 나의 프로젝트에서도 문제가 어김없이 발생했다.  N+1 이란?조회를 할때 많이 발생하는 과정이다. 애초에 1개의 쿼리를 통해 전체 데이터를 조회하고자 하지만 막상 쿼리문이 발생하는것을 보면 N개가 추가로 발생하는 것이다. 💧 왜 발생했는가?현재 나의 상황은 orderProduct라는 테이블을 중간테이블로 사용하고 있는 상황이다. 사용의 이유는 간단하다 주문은 다양한 상품을 가지게 되는데 한 개의 오더 마다 order테이블에 중복적인 행이 발생하는 것을 막기위해 즉, 정규화를 지키기 위해 제작해두었다.  이 이외에는 전부 MSA의 서비스 상태라서 N+1 의 상황이 발생하지 않고 ..

🎆 들어가기 앞서이전 블로그에서 모놀리스 방식에서 Sync와 분산락을 사용해서 동시성을 제어하는 것을 보여준적이 있다.https://latewalk.tistory.com/244 🚢 재고 관리를 위한 동시성 제어 (Monolithic Architecture)🦐 모놀리식 상황에서 재고 처리 동시성 문제먼저 동시성을 해결해야 하는 문제가 발생했다 바로 주문을 할때 여러명이 동시에 같은 물건을 주문한 상황이 발생한 것이다. 아 물론 발생한건latewalk.tistory.com하지만 이제 서비스가 MSA 방식으로 변경되면서 수정 사항이 생겼다Sync동기화 방식을 사용하는 Synchronized는 더이상 사용할 수 없다 왜냐하면 MSA의 특징 상 서비스는 scale-out하게 되면서 동일한 서비스가 늘어난다...

💨 Feign Client 와 RestTemplate 중 어떤 걸 선택하는게 좋을까?간편성 및 사용 편의성Feign Client : Feign은 선언적 방식으로 REST API를 정의하고 사용할 수 있도록 한다. 인터페이스를 정의하고 이를 통해 HTTP 요청을 보내는데 이는 개발자의 구현 로직이 줄어드는 이점이 있다RestTemplate : 설정과 코드를 요구하면서 요청 및 응답을 모두 직접적으로 처리해야 한다.유연성과 성능Feign Client : Feign Client는 Cloud와 통합되어 있다. 이는 로드 밸런싱, 재시도, circuitBreaker 패턴등을 쉽게 구현할 수 있다RestTemplate : Spring에서 오랫동안 사용되어 왔고 풍부한 기능과 확장성을 제공한다. 하지만 Cloud의..

💧 시작에 앞서현재 나의 서비스는 주문을 하기 위해 OrderService에서 feign client를 이용해서 ProductService를 통해 차감되어어야 하는 데이터가 있고 그에대한 반환값을 전달해야 하는데 이때 만약 Product 쪽에 문제가 발생한다면 Transactional의 특성으로 인해 전부다 rollback이 될테고 예외가 발생하게 될 것이다.  하지만 이건 문제가 있다. 왜냐하면 문제는 ProductService에 존재하는데 정작 사용자에게 나타나는 오류 메세지는 마치 OrderService의 서버가 문제가 있는것처럼 나타나기 때문이다. 이건 너무 MSA 방식과 거리가 멀 다는 것을 알 수 있다. 각각의 서비스의 결합도는 낮아야 하는데 한개의 서비스가 오류가 발생하면 다른 곳에 영향을..

🦐 모놀리식 상황에서 재고 처리 동시성 문제먼저 동시성을 해결해야 하는 문제가 발생했다 바로 주문을 할때 여러명이 동시에 같은 물건을 주문한 상황이 발생한 것이다. 아 물론 발생한건 아니고 그런 상황에서 문제가 일어난다는 것이다. 즉, 이번에 제작한 나의 코드를 통해 동시성 문제를 해결해 보려고 한다. 동시성을 해결하기 위한 방법은 해당 블로그에 적혀있다.https://latewalk.tistory.com/243 💾 동시성 문제를 해결하는 방법🧊 재고 처리에 대한 동시성 문제동시성 문제는 동일한 데이터에 2개 이상의 스레드, 혹은 세션에서 가변 데이터를 동시에 제어하게 될 때 나타나는 문제이다 만약 하나의 작업이 진행하는 중latewalk.tistory.com 우선 문제가 일어나는 코드를 살펴보자 ..

문제우선 좀 더 명확한 요구사항이 나오게 되면서 깨닳게 된것이 WishList라는 것이 찜같은 것이 아니라 장바구니의 역할을 하게 된다는 것이였다. 이유는 WishList와 관련된 서비스가 User에 존재하지 않고 Order에 존재했기 때문이다. 사용자가 찜을 해서 사용자가 자신의 마이페이지에 갔을때 찜한 목록을 보는 것이다 라고 생각한다면 해당 서비스는 User에 생겨야 한다고 생각했지만 요구사항에서 Order에 존재한다는 것은 해당 내용이 주문으로 이어진다는 이야기이고 그것은 곧 장바구니이다. 라고 생각이 떠올랐다 Redis(Shopping Cart)이번에 Redis를 공부하게 되면서 장바구니 하면 떠오르는 것이 바로 redis이다. 왜냐하면 사용자의 입장에서 장바구니를 접근하는 횟수는 다른 요청에 ..

문제 발생기존의 이메일을 인지하고 인증 코드를 보낼때 서버에서는 세션에 저장하여 이후 해당 이메일 인증 코드가 들어오면 세션의 값과 비교해서 이메일을 인증했다. 그렇게 진행을 했지만 MSA로 변경하고나서 문제가 발생했다. 더이상 세션을 통해 코드를 확인할 수 없다. 그 이유는 세션이 휘발성의 성격으로 인해 다음 요청에 세션이 비어있는 것이다. 모놀리식과 MSA의 세션 정책모놀리식모놀리식에서는 일반적으로 세션 저장소를 사용해서 세션을 관리한다. 이는 세션이 서버의 메모리나 외부 DB에 지속된다는 것인데 이는 클라이언트가 세션을 만들고 서버와 상호작용을 지속하고 있는 한 세션이 유지되고 있다MSA 서비스 간에 상태를 공유하는것을 피하기 위해 상태를 분리한다. 모두 독립적으로 실행되고 있으며 일반적으로 세션과..