NDM

https://ndm-tech.tistory.com/90 에서 상태 패턴(State Pattern)으로 SortType을 제어문 없이, 변경 지점을 줄이며 구현하였습니다. 하지만 저는 다음과 같은 문제가 있다고 생각했습니다. 갈수록 늘어나는 구현체 Class 결국 그 하위 구현체는 Dto를 알고있을 수 밖에 없는데, 그렇게 되면 결국 수정 시 관리포인트만 늘어나는 것 아닌가? 때문에 저는 Enum에서 DTO를 아는 것은 결국 막을 수 없는 것이고, 막을 수 없다면 변경 지점을 하나로 모아야 한다고 생각하였으며 정렬방법이 늘어날 때 유사한 코드가 늘어나는 것을 대비하여 switch나 if문을 최대한 제거하였고, 단순 문자열인 정렬방법 과 코드상의 반환값인 Comparator가 연관이 있다는 것을 알려주고자..

상태패턴을 알아보고, 어떤 경우에 사용했는지 간략하게 소개하려 한다. 실제로 나는 상태패턴을 꽤 사용하고 있으며, Enum, Collection과 함께 사용하는 것을 좋아한다. 왜 Enum / Collection과 함께 사용하는지는 이후 예시에서 소개하겠다. ## 논의의 시작 @Transactional(readOnly = true) public List getExampleList( // 각종 파라미터, TestSortType sortBy) { Comparator comparing; if(sortBy.equals(TestSortType.DISTANCE)) comparing = Comparator.comparing(ExampleDto::getDistance); else if(sortBy.equals(Test..

코드 리뷰 도중 record 클래스에 대해 알게되었습니다 항상 Java 11버전만 사용해서 몰랐던 내용이므로, 한번 정리하고 넘어가려 합니다 코드리뷰는 역시 몰랐던 것을 알게되고, 간과했던 부분을 잡는다는 점에서 매우 효율적인것 같습니다 ## 개념설명 JDK 14에서 preview로 등장했고, JDK16부터 정식 스펙으로 결정되었습니다. 불변 클래스를 쉽게 생성할 수 있도록 도와주는 클래스입니다. public class Person { private final String name; private final int age; public Person(String name, int age) { this.name = name; this.age = age; } public String getName() { re..

동시성을 해결하기 위해 Redis를 선택하게 된 생각의 과정은 앞선 포스팅에서 정리하였습니다. https://ndm-tech.tistory.com/34 4. 재고 처리 로직 동시성 이슈 해결 일지 배달 어플을 구현하는 SlowDelivery 프로젝트에서 재고를 처리하는데 동시성 이슈가 있었습니다 더보기 하지만 사실 재고 도메인은 필요가 없었는지도 모릅니다. 일반적인 쇼핑몰과 다르게 배달 ndm-tech.tistory.com 이번 포스팅에서는 Redis를 어떻게 사용하여 동시성을 해결하였는지 알아보겠습니다. # Redis Transaction Redis 트랜잭션은 다른 DB와 달리 Rollback 개념이 없으며, 기본적으로 SpringBoot + Redis를 사용하였을 경우, Redis는 @Transact..

기존의 제 이벤트 상품 조회는 다음과 같이 이루어집니다. 첫 번째로 DB를 조회해서 Cache DB에 적재하고, 그 이후부터 Cache DB에서 데이터를 가져오는 방식입니다. # 왜 이벤트 상품을 캐싱으로 처리하려고 했나 ? 이벤트 상품에 대한 수정(상품 수정, 이벤트 상품 등록/취소) 작업이 일어나는 횟수가 적을 것으로 예상했고 타임딜 이벤트 상품들을 찾아보니 사이트마다 달랐지만 한번에 이벤트에 등록되는 상품 수가 많지 않았습니다. # 그럼 무엇이 잘못되었음을 깨닫고 시스템 디자인을 바꾸었는가? Cache DB를 사용하면 분명 키가 만료되는 순간이 존재한다. 그때마다 RDB를 다시 뒤져야한다. RDB를 다시 뒤질때마다 부하가 급증할 것이고, 성능도 보장할 수 없다. 지금은 모놀리식이지만, 마이크로서비스..

현재 진행중인 토이프로젝트는 "타임딜" 이라는 단시간에 많은 트래픽이 몰리는 프로모션 상품 구매 서비스 api 서버입니다. 현재 제 프로젝트의 주요한 api는 다음 2개입니다. 상품 조회 api 주문 api 비즈니스 로직이 어떻게 진행되는지 알기 위해, 시퀀스 다이어그램을 작성해 보았습니다. # 상품 조회 상품 조회의 요구사항은 다음과 같습니다. 일반 상품과 이벤트 프로모션 상품이 존재합니다. 상품 조회는 페이징 처리가 필수적입니다. 이벤트 프로모션 상품의 경우, 이미 이벤트가 진행중인 시점이라면 상품 수정 및 이벤트 해제가 불가능합니다. 이벤트 상품과 일반 상품 모두 조회 endPoint가 같으며, 쿼리스트링의 파라미터로 구분하였습니다. 다음은 시퀀스 다이어그램입니다. 기본적인 구상은 다음과 같습니다...

시간 안에 세일한 상품 이벤트 프로모션을 진행하는 커머스 플랫폼 api 서버 프로젝트를 진행중입니다. Jmeter를 이용해 테스트할 api는 크게 주문, 상품조회로 2가지 입니다. 이번 포스팅에서는 조회 api만 다루겠습니다. Jmeter는 로컬에서 돌리고, Spring서버는 로컬에서 한번, 운영에서 한번 해보는 것으로 진행하였습니다. Jmeter와 SpringBoot를 같은 서버에서 진행하면 제대로 된 테스트를 할 수 없기에, 로컬에서 함께 진행할 때는 적은 요청으로 무리가 없는지, Jmeter 설정이 제대로 이루어졌는지만 보는식으로 진행하고 운영에서 따로 진행하였습니다. * 기본적으로 Jmeter를 돌리는 제 노트북 성능이 별로 좋지 않아 제대로 된 성능이 나오지 않습니다. # 상품조회 상품 조회는 ..

첫번째 에러 Caused by: java.lang.RuntimeException: Can't start redis server. Check logs for details. Check logs 하라는데 log를 안뱉어줍니다. 다음과 같이 하시면 됩니다. https://github.com/kstyrc/embedded-redis/blob/master/src/main/java/redis/embedded/AbstractRedisInstance.java#L59 GitHub - kstyrc/embedded-redis: Redis embedded server for Java integration testing Redis embedded server for Java integration testing - GitHub -..

타임딜 프로젝트를 진행하며 내가 사용한 서버는 다음과 같다. 넘블 X 네이버 클라우드의 혜택으로 크레딧 20만원을 받아 아키텍처를 설계할 수 있었다. 1. SpringBoot 서버 1대 2. Nginx 서버 1대 3. Redis 서버 1대 ( Session & Caching ) 4. MySQL 서버 1대 5. Pinpoint 서버 1대 6. Jmeter 서버 1대 7. Prometheus & Grafana 서버 1대 1. SpringBoot Server 4vCPU, 8GB Mem, 50GB Disk 서버를 사용했다. 더 좋은걸 사용할수도 있었지만, 초기 세팅은 이정도로만 하고 나중에 Ngrinder로 부하를 발생시키며 Pinpoint로 모니터링하면서 크레딧이 얼마 남았는지 확인하며 스케일 업을 할 예정이..

넘블 타임딜 챌린지에는 다음과 같은 요구사항이 명시되어 있습니다. 로그인 관리는 세션으로만 하며, Spring Security나 JWT의 사용은 제한한다 WAS 서버는 1대로만 제한한다. 아마 이번 챌린지의 주된 목표는 재고의 동시성 처리와 상품조회에 있다고 생각해 다음과 같은 제약사항을 걸어두신 것으로 예상합니다. 구현하는데 시간이 더 걸리고, 인프라 구성 비용도 늘어나기 때문입니다. HttpServletRequest와 HttpSession을 이용해 손쉽게 구현할 수 있었지만, 다음과 같은 상황을 고려해보기로 했습니다. 이왕 참가한 만큼 무언가를 더 얻어가고 싶었기 때문입니다. WAS가 1대로 제한되어있으나, 이후 확장 가능성까지 고려하지 말라는 말은 없었다. 이후 확장 가능성을 고려한다면 어떻게 세션..