전체 글

💧 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하게 되면서 동일한 서비스가 늘어난다...

🥽 내가 구현한 기능MSA방식으로 변경되어 모놀리식으로 되어 있는 서비스를 모두 모듈화했고 하는 과정에 각 서비스를 로드밸런싱해주는 API Gateway를 제작해주었다. 또한 API Gateway에서 인가를 진행하게 되고 다른 서비스도 통합에서 분리로 적용하게 되어 Redis를 통해 global하게 사용되고 있는 데이터는 Redis를 통해 관리하게 제작했다.또한 장바구니의 기능 또한 Redis로 제작하게 되며 DB에서 빠지게 되었고 각 서비스 간의 요청에 Feign을 사용했다또한 MSA로 변경되면서 DB Lock을 걸어주어야 하는 서비스에 접근하여 해당 서비스에서 사용될 로직을 더욱 작성하여 동시성 문제를 해결 추가로 분산락을 사용하고자 했지만 분산락으로 충분한 상황이여서 이후 다시 구현 예정한개의 서..

💨 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 우선 문제가 일어나는 코드를 살펴보자 ..

🧊 재고 처리에 대한 동시성 문제동시성 문제는 동일한 데이터에 2개 이상의 스레드, 혹은 세션에서 가변 데이터를 동시에 제어하게 될 때 나타나는 문제이다 만약 하나의 작업이 진행하는 중인데 다른 작업이 끼어들어 데이터를 또 다시 처리하면 데이터가 부숴지게 되는 것이다 이때 나오는 문제가 Concurrency 문제가 발생하는 것이다 간단한 로직우선 재고가 감소하는 로직을 만든다.StockEntity@Entity@Getter@NoArgsConstructor@AllArgsConstructorpublic class Stock { @Id @GeneratedValue(strategy = GenerationType.IDENTITY) private Long id; private Long..

🌱 데이터 충돌서버에서 트랜잭션을 진행하면 우연이든 필연이든 데이터의 충돌이 일어날 수 있다. 이런 문제를 해결하는 것은 개발자로써 꼭 경험하고 알고 있어야 하는 내용이 아닌가 싶다. 어쨌든 데이터의 일관성이 깨질 수 있기때문에 DB에서 lock을 걸고 관리하는 것을 Locking 이라고 한다해당 Locking의 방식은 두가지의 방식이 있다. 🌱 낙관적 락(Optimistic) 자원에 락을 걸지 않고 데이터 업데이트를 할 때 동시성에 문제가 발생하면 그때 처리하는 것이다.데이터를 수정할때 수정했다고 명시해서 다른 트랜잭션이 동일한 조건으로 값을 수정할 수 없게 하는 것이다.낙관적 락은 동시성이 높은 환경에서 성능을 향상 시킬 수 있지만, 충돌이 발생할 가능성이 높은 경우 롤백이나 재시도가 필요하다충돌..

해당 내용은 쉬운코드님의 영상을 기반으로 작성되었습니다🔌 들어가기 앞서전 트랜잭션(4)의 마지막 내용에서 read-read 의 상황에서만 데이터가 교류되는 것을 확인하고 그 이외의 상황은 모두 lock으로 인해 접근 할 수 없다는 것을 알았다. 이는 좋지 않은 성능을 나타내기 때문에 해결할 방법으로 MVCC가 있다고 했다.그에 대해 알아보자 🔌 MVCC (Multi Version Concurrency Control)지금까지 봐왔던것과 달리 훨씬 더 개방적인 모습을 볼 수 있다. 근데 이렇게 그림만 보면 그냥 좀 포용력이 좋아졌다 생각될 뿐 어떻게 작동할지 정확히 어떤 이점이 존재할지 바로 떠오르지 않는다 예시로 가보자 ♬ 예시이번예시는 이해하기 힘들겠지만 말로 설명해보고자 한다 ( 나의 이해도 같이 ..

해당 내용은 쉬운코드님의 영상을 기반으로 제작되었습니다 🔌 LOCK우리는 트랜잭션 (3) 에서 다양한 트랜잭션에 대한 문제를 만나보았다. 거기서 계속해서 진행하던 write는 과연 단순한 값 바꾸기일까? 그것보다 더욱 복잡한 과정이 생길 수 있다. 만약 다른 트랜잭션에서 같은 값을 똑같이 write하려고 한다면 어떻게 되는 걸까? 이때 예상치 못한 문제가 발생할 수 있다 이때 사용하는 것이 바로 lock이라는 것이다. 이때 lock은 운영체제의 lock과 굉장히 비슷하다. 데이터마다 lock 이 있어서 데이터를 변경하거나 읽으려면 lock을 취득해야한다 만약 취득하지 못한다면 얻을 때까지 기다려야한다♬ Lock 을 이해하기 위한 예시1. 트랜잭션 1 : x를 20으로 바꾼다트랜잭션 2 : x를 90으로..