현재 서비스의 트랜잭션 범위에 대한 이해상품 주문 결제 트랜잭션Tx -> 사용자 조회 -> 장바구니 조회 -> 주문 및 주문 아이템 생성 -> 재고 차감 -> 결제 -> 주문 정보 전송 -> commit현재 트랜잭션 범위의 문제점긴 트랜잭션 : 하나의 트랜잭션에서 주문, 결제 같이 여러 작업을 처리하게 될 경우 트랜잭션의 작업 시간이 길어져, 다른 트랜잭션에서 커넥션이 필요할 때 대기시간이 길어져 사용성이 떨어진다. -> 트랜잭션의 사용시간이 길어 생기는 문제전체 롤백 문제 : 주문 정보를 외부 데이터 플랫폼에 전송 도중 오류로 인해 전송에 실패하면 이전 작업(주문 생성, 재고 차감, 결제)들이 모두 롤백된다. 상품 주문 시 핵심적인 비즈니스 로직이 부가적인 주문 정보 전송 로직에 의해 롤백되고 있기 때..
애플리케이션 성능 향상이번 주차는 인덱스와 캐시를 이용해 기존 애플리케이션의 성능을 높이는 것이 주요 목표였다. 애플리케이션의 성능을 높이기 위해서는 여러 가지 방법이 존재하겠지만 그 중 이번에는 DB의 성능 튜닝과 캐시를 이용하여 애플리케이션의 성능을 향상해보았다. 저번주와 마찬가지로 이번주도 인덱스의 대한 이해를 위해 Real MySQL8.0의 인덱스 챕터 부분을 읽고 시작한 게 매우 도움이 되었다.그 중 DB 성능 튜닝의 핵심은 "어떻게 디스크 I/O를 줄이느냐가 관건"이라는 것을 배웠다. 디스크의 I/O를 줄이는 방법으로는 인덱스를 이용해 DB를 최적화하는 방법과 캐싱 방법이 존재한다. 인덱스인덱스를 통한 효율적인 쿼리로 불필요하게 데이터에 접근하는 것을 줄일 수 있기 때문에, 인덱스에 대해 공..
대용량 트래픽 & 데이터 처리 챕터 시작본격적으로 대용량 트래픽과 데이터를 처리하기 위한 과정이 시작되었다. 이번주는 현재 이커머스 서비스에서 발생할 수 있는 동시성 상황들을 분석해 보고 여라가지 방법들의 각각의 장단점을 파악하여 직접 동시성 문제를 해결해 보았다. 우선 나는 이전까지 개인적으로 진행하는 프로젝트나 실무에서 조차 동시성 문제를 직접 고려해 본 적이 없다. 그래서 어떤 상황에서 동시성이 발생하는지 1도 모르고 더군다나 DB에 대한 공부를 거의 하지 않아서 어떻게 해결해야 하는지 1도 모르는 상황이었다. 그래서 DB를 먼저 공부해야겠다고 생각을 하여 현재 주로 사용하는 DB인 MySQL을 공부하기 위해 Real MySQL8.0을 사서 먼저 트랜잭션과 잠금 파트를 읽어보았다.덕분에 MySQL..
E-commerce 마무리이번주는 E-commerce 서버 구축을 마무리하는 한 주로 아직 구현하지 못한 장바구니 관련 기능과 미비된 통합 테스트를 추가 작성하고, 주문 결제 시스템을 이벤트 기반 아키텍처 구조로 변경하는 작업을 했다.특히 기존 하나의 트랜잭션 단위의 주문 결제 시스템에서 이벤트 기반 아키텍처 구조로 변경하는데 많은 시간을 사용했다.이벤트 기반 아키텍처 구조로 변경했을 때의 이점과 왜 변경해야 하는지에 대한 고민과 독립적인 트랜잭션 구성 방법에 대한 많은 고민을 하고 관련해서 트러블 슈팅 글을 작성했다.https://seungjjun.tistory.com/328 [E-commerce] 주문 결제를 이벤트 기반 아키텍처로 구축하기주문 결제를 이벤트 기반 아키텍처로 구축하기 이 글에서는 주문..
프로젝트 선택 E-commerce 서버 구축 프로젝트를 통해, 다양한 기술적 문제와 해결 방안을 경험할 수 있었다. 프로젝트의 선택 과정부터 구현까지, 트랜잭션 관리 방안, 이벤트 기반 아키텍처 구조로의 전환과 같은 문제들을 다루면서 평소에 경험할 수 없었던 내용들을 학습하면서 프로젝트를 진행했던 것 같다. 처음에는 문서 작업부터 시작했는데, 프로젝트 초기 단계에서는 문서 작업의 어려움을 많이 느꼈다. 특히, 변경이 잦은 ERD와 API 명세의 수정이 반복되어 힘든 부분이 있었지만, 실제 개발을 진행하는 과정에서 초기 프로젝트 설계의 중요성과 필요성을 인식할 수 있었다. 트랜잭션 처리의 고민과 해결 이번에 이커머스 서비스를 진행하면서 가장 시간을 많이 소비했던 부분이 주문 결제 시스템의 트랜잭션 처리 였..
주문 결제를 이벤트 기반 아키텍처로 구축하기이 글에서는 주문 결제 시스템을 이벤트 기반 아키텍처로 전환하면서 겪었던 문제와 그 과정을 공유하고자 합니다. 현재 이커머스 프로젝트의 주문 결제 시스템은 한 트랜잭션 내에서 동기 처리 방식으로 처리하고 있습니다. 현재 OrderUseCase를 간단히 살펴보면사용자 조회 -> 상품 조회 -> 상품 재고 조회 -> 주문 -> 결제 -> 재고 차감 순으로 주문 결제 시스템이 이루어져 있습니다. 그럼 이 주문 결제 시스템을 이벤트 기반 아키텍처로 구축하면서 겪었던 문제와 과정을 정리해 보겠습니다. 이벤트 기반 아키텍처로 변경하는 이유결합도 감소현재 주문 결제 시스템은 상품 재고 관련 로직, 결제 로직이 주문 로직에 깊게 관여되어 도메인끼리 강한 결합을 갖고 있다는..