프로젝트/예약상품

1. 일단 개선을 하긴 했는데.. 이전에 프로젝트 구조개선을 시도해보았다. 완성된 아키텍처는 아래와 같다.   주문 요청에 대한 요청 처리율도 향상되었고, 재고수량의 동시성 문제도 발생하지 않았다. 하지만 위의 개선된 구조는 내가 알고있는 지식 선에서 가능한 빠르게 구조를 잡아본 형태이고, 더 좋은 선택지가 있을 수 있기 때문에 어떠한 선택지가 있었는지 고민해보고, 새로 알게된 @Scheduling에 대해서도 학습해보면 좋을 것 같다.  2. Redis외에 다른 선택지? 1) 로컬 캐시우선 개선 구조에서 가장 중요하게 생각한 포인트는, 트래픽이 집중될것으로 예상되는 주문 서버의 주문 처리 로직을 MySQL 데이터베이스 I/O를 이용하지 않고 구현하는 것이었다. 그러기 위해서는 캐시 저장소를 활용하면 좋겠..

이전 프로젝트에서는 동시간대에 많은 주문 요청이 들어올 때 동시성 문제를 해결하는데에 집중해서 프로젝트를 진행하였고 마무리 하였다. 이번에는 동시간대에 많은 주문 요청이 들어올 때 어떻게 성능을 개선해볼 수 있을지 고민해 보려고 한다. 기존 로직 성능 측정 & 문제 분석현재까지의 주문 요청 로직을 분석해보고, 어떻게 개선해볼 수 있을지 고민해보자.아래는 현재 주문 요청을 처리하는 컨트롤러, 서비스, 레포지토리 코드이다./** * 주문 생성 컨트롤러 */@PostMappingpublic Response create(@RequestBody final OrderCreate orderCreate) { final Long savedOrderId = orderService.create(orderCreate);..

취업코스를 경험하면서 많은 분들을 만났고, 취업을 위한 것만이 아니라 개발 자체에 즐거움을 느끼고 노력하는 모습에서 큰 자극을 받았다. 내가 학습한 부분에 대해 도움을 드리기도 하고, 내가 도움을 받기도 하면서 함께 성장해 나가는 과정을 경험했고, 최종적으로 예약 상품 MSA 프로젝트까지 수행해 나가면서 많은 성장을 할 수 있었던 것 같다. 프로젝트를 마무리하면서 경험들을 되돌아보고 더 좋은 발전을 위해서 회고록을 작성한다. 1. 프로젝트 목표 특정 시간부터 상품구매 버튼이 오픈되고, 짧은 시간에 많은 주문 트래픽이 발생하는 상황을 가정하여 프로젝트를 설계, 구현해보는 프로젝트를 진행하였다. 나는 크게 3가지의 주제에 대해 고민해보는 것을 목표로 잡고 프로젝트를 진행하였다.(특정 시간대에 대량의 주문 트..

🎯 CircuitBreaker와 Retry가 뭘까? 프로젝트를 진행하면서 주문 서버에 재고 관리 로직이 함께 들어가 있었다. 재고 관리 로직은 주문, 결제, 상품 관리 등 다양한 로직에 사용되어 트래픽이 많을 것으로 예상되어 확장성을 가지면 좋겠다고 생각하였고, 각 기능별로 유지보수를 위하여 서버를 분리해 보는 학습을 해보면 좋겠다고 생각하였다. 회복탄력성은 Open Feign의 resilience4j-circuitbreaker 와 resilience4j-retry를 사용하였다. MSA 학습을 위하여 뉴스피드 도메인을 간단히 설계하였다. https://topaz-raincoat-203.notion.site/65cae744cebd44cbabc3771e222e3737?pvs=4 위와 같이 분리된 서버 간에 ..

🎯 한 사람에 대한 여러 요청을 어떻게 제한할 수 있을까? 예약 상품 프로젝트는 특정 시간에 상품이 오픈되고, 많은 사용자가 짧은 시간에 주문 요청을 할 것이라고 가정한다. 위의 그림에서 고려사항1이 생겼다. 한명의 사용자가 여러 PC에서 로그인하여 동시 요청하는것을 방지하려면 어떻게해야할까? 고민해본 해결방법은 아래와 같다. 1. 로그인할 수 있는 기기 개수에 제한을 건다. 2. Gateway에서 RateLimit을 구현하여 많은 요청을 막는다. 🎯 [프로젝트에 적용] 로그인 기기 개수에 제한 걸기 로그인 할 수 있는 기기 개수에 제한을 두어 많은 PC에서 같은 ID로 주문 요청 하는것에 제한을 두려고 한다. 현재 로그아웃 구현 상태는? 현재 로그아웃 방식을 활용하기 위하여 redis를 활용하고 있다..

📌 서버를 확장한다면 synchronized를 사용하면 안 될까? 이 전에 단일 서버 환경에서 synchronized를 활용하여 동시성 문제해결에 접근해 보았다. 만약 현재 상태에서 서버를 확장한다면 어떻게 될까? 아래와 같이 하나의 프로세스 내에서는 synchronized로 인해서 1개의 스레드만 redis에 접근할 수 있다. 그러나 여러 프로세스 상에서는 동시에 redis에 접근할 수 있기 때문에 redis와 관련된 연산을 원자적으로 처리할 수 있도록 해줘야 한다. 만약 아래와 같이 redis가 아니라 MySQL과 같은 Database로 바로 접근하는 경우라면 synchronized와 MySQL의 테이블락을 활용하여 시스템을 구성해 볼 수 있을 것 같다. 이런 경우에는 각 서버에서 synchroniz..

📌 고민사항 이전에 재고의 동시성 문제를 해결하기 위하여 synchronized를 활용하여 재고수량 변경 부분에 락킹 처리를 해주었다. 그리고 단일서버 synchronized의 임계영역을 최소화 하기위해서 상품 판매 오픈전에 미리 특정상품 A에 해당하는 재고 수량정보를 로컬서버에 캐싱해 온 후 수량정보를 변경하는 방식을 생각했었다. 이러한 상황에서 아래와 같이 크게 3가지 고민사항이 생겼다. 1. 캐싱을 한다면 로컬 서버(메모리)에 캐싱할 것인가? 아니면 redis와 같은 global캐시를 활용할 것인가? 2. 상품 판매 오픈전 캐싱해올 때 어떤방식으로 캐싱해 올 것인가?(판매자의 수동처리 or 배치처리) 3. 캐시의 경우 서버가 다운되는 순간 날아가 버리고, 재고수량 관리에 문제가 생길 것이다. 이러한..

📌 고민사항 재고 증가/감소 로직에서 동시성 문제가 발생하였고, 해당문제를 해결하기 위해서 뮤텍스, 세마포어, 원자적연산등의 방법들을 고려하였다. 자바에서 뮤텍스 방식을 활용하기 위해 synchronized를 지원하는데, 동시성 문제가 발생할 수 있는 임계영역에 락을 걸어서 다른 스레드가 접근하지 못하도록 막는 방식이다. 락 방식을 사용할 때 가장 생각해봐야 할 점은 하나의 스레드에서 락을 걸어버리는 순간 다른 스레드는 해당 자원에 접근하지 못하기 때문에 대기를 하게되고, 병목현상이 발생될 수 있다는 점이다. 그래서 synchronized를 적용시킬 때에는 적용시킬 영역을 최소화 하는것이 중요하다. 📌 기존의 재고 감소 로직 아래는 동시성 문제가 발생할 수 있는 재고 수량 감소 메서드이다. @Transa..