개발 일기

이전 편: https://writerroom.tistory.com/379상황 공제 가맹점이라는 테이블 특성 상, Hit 가 적을 수 밖에 없기에 여기서는 성능 개선의 여지가 적다고 판단했다.다시 로직을 보면, 아래 6개의 과정으로 분류할 수 있다. 팀과 논의 후, 슬로워 쿼리 개선 /캐시 적용 등을 이미 해보았으니, DB 부하 감소로는 최적화의 여지가 없다고 판단했다. 현재 로직이 이미 복잡하기에, 작업을 멀티 쓰레드에서 동시에 실행해서 처리 속도를 높여보기로 했다 [로직]  1)올해 국내 결제 내역 조회(Reader) *2-5는 Processor2)결제 건의 가맹점 번호를 기반으로 공제 타입 확인3)이미 연말정산 된 거래인지 중복 확인4)할인,그룹, 거래 타입 분류 등 기타 상세 내역 확인5)정산에 필..

문제 2024년 한 해 동안 발생한 결제 건을 연말 정산 하여, 국세청에 제출한다. 이때 정산 내역을 만드는 배치의 소요 시간이 매우 길었다.  참고로 복잡한 비즈니스 로직을 수행하는 processor 에서 소모한 시간이 대부분이다. Reader/writer는 I/O 작업 위주라서 영향이 거의 없다. Read Time: 20초Process Time: 6시간 10분 Write Time: 4분긴 배치 시간은  1)지속적인 모니터링으로 작업 효율성을 떨어트리며,2) 최악의 상황에서는 다른 배치가 실행되지 못하는 위험이 있다 (현재 여러 배치가 한 EC2 인스턴스에서 실행되기 때문) 로직1)올해 국내 결제 내역 조회(Reader)*2-5는 Processor2)결제 건의 가맹점 번호를 기반으로 공제 타입 확인3)..

상황 프레시 카트는 Redis 를 사용하고 있고, 용도는 아래와 같습니다 - 다중 서버 환경에서 로그인 유저의 세션을 보관할 수 있는 공통 저장소 - 추후 메인 페이지에서 보여지는 전체 상품 데이터를 캐싱하기 위해. 서버는 언제나 fail 될 수 있고, 서버 문제로 애플리케이션이 동작하지 않는다고 가정해봅시다. 서버가 동작하지 않는 시간 만큼 비즈니스 중단/고객의 불편이라는 손실로 이어집니다. 특히 프레시 카트의 메인 기능인 주문은 로그인을 해야 가능하기 때문에, 늘 로그인을 가능하게 하는 것이 중요합니다. Redis Clustering 을 선택한 이유 레디스의 fail over 방식으로는 replication, clustering, sentinel이 있습니다. 이에 대해서는 별도 포스팅에서 자세히 설명..

문제 판매자의 제품 등록 기능에서 Insert 쿼리가 다수 발생한다는 것을 발견했습니다. Disk I/O는 웹 서비스 성능에 많은 영향을 미치는 중요 모니터링 지표입니다. 디스크의 데이터 처리 속도가 메모리나 CPU에 비해 너무 느리기 때문입니다. DISK I/O를 줄이는 것은 DB 성능 개선의 핵심 이기도 합니다. 이번 글에서는 쿼리를 여러번 날렸을 때, 나타나는 지연 현상을 개선 해보겠습니다. 개요 네이버 쇼핑, 배달의 민족 등 평소 이용하는 이커머스 서비스를 보면, 소비자가 다양한 옵션을 구성할 수 있도록 제품이 제공됩니다. 이를 충족하기 위해, 판매자가 제품을 등록할 때, 다양한 옵션 그룹과 옵션을 설정할 수 있어야 합니다. 제품 등록 POST 요청 값의 예시입니다. 제품(샐러드) 에 옵션이 있을..

상황 프레시카트라는 이커머스 서비스의 주문 기능을 구현하고 있었습니다. 주문의 특성 상, 여러 유저가 하나의 상품을 동시에 주문하는 상황이 빈번할 것입니다. 이렇게 동일한 재고 수량 데이터를 차감하는 상황이라면 코드가 잘 작동할지 점검 해보고 싶었습니다. 먼저 주문 기능의 동작을 살펴보겠습니다. 이는 하나의 트랜젝션 내에서 수행됩니다. 1) 유저가 CART(DTO) 에 주문 객체를 담는다. 2) Product_Inventory 테이블에서 주문하려는 제품의 재고를 확인한다. 3) 재고가 있는 경우 주문 수량만큼 차감하여 수량을 업데이트 한다. 3) 주문을 완료한다 주문 로직 - OrderRegisterProcessor.java @Transactional public void place(LoginUser u..

프레시카트는 1인 프로젝트 입니다. 1인 프로젝트이다 보니, 팀과 협업할 때보다 충돌이 발생하는 지점이 적었고 신경 쓸 부분도 많지 않았습니다. 현업에서는 개발 못지 않게, 개발 환경을 구성하고 개선하는 것 역시 필요할 것이라고 생각했습니다. 이전의 팀 프로젝트에서 느꼈던 어려움을 돌이켜보고, 개발자 동료들이 공유해주는 어려움을 참고하면서 여러 기술을 도입해보았습니다. Flyway로 데이터 베이스 스키마의 변경 이력 관리 도입 이유 이전에 팀 프로젝트를 할 때, DB를 공유해서 쓰면서 어려움을 겪은 적이 있었습니다. 스키마 변경이 있을 때마다, 공유된 내용을 확인하고, 변경 사항을 인지해야 했습니다. 성과 flyway 적용으로 변경 이력을 문서화 할 수 있게 되었습니다. 변경에 맞춰 애플리케이션 로직도 ..

상황 이커머스 서비스를 구현하면서, 서버 메모리에 세션을 저장하는 방식으로 로그인을 구현했습니다. 추후 서버가 증설될 경우, 세션이 여러 서버에 걸쳐 공유되어야 하는데, 기존 구조는 서버마다 저장소를 독립적으로 갖는다는 한계가 있었습니다. 이전 포스팅 에서도 살펴 보았듯, 세션의 특성 상 서버 scale-out 시에는 (서버의 대수를 늘리는 것) 별도 처리를 해줘야 하기 때문입니다. 실제로 유저가 몰려서 서버를 증설하는 상황은 아니었습니다. 하지만, 유저가 늘어나고 이에 따라 scale-out 하는 것이 매우 흔한 상황임을 가정해볼 때, 다중 서버 구성에 대비하는 것이 중요하다고 생각했습니다. 깊이 학습해볼 필요성을 느껴서 Redis로 로그인 중앙화를 구현하였습니다. 이번 포스팅에서는 1. 해당 문제를 ..

객체 지향을 고민하게 된 계기 작년에 스프링 입문을 위한 자바 객체 지향의 원리와 이해 책을 읽었습니다. (이 책을 읽고 나서 스프링을 좀 더 개발 의도에 맞게 (== 객체 지향을 생각하며) 바라볼 수 있었습니다. 디자인 패턴, SOLID 등을 소개하면서 어떻게 객체 지향을 적용할 수 있을지, 좋은 가이드가 되어준 책 이었는데요. 스프링 개발자라면 꼭 읽어보기를 추천합니다. ) 객체 지향은 인간이 사물을 인지하는 방식대로 프로그래밍 하는 방식입니다. 즉 기계에 맞춰 사고하던 방식이 아니라, 인간이 현실세계를 인지하는 방식으로 프로그램을 만들자는 의도에서 출발합니다. 객체 지향 원칙을 지키다 보면, 결합도는 낮추고 응집도는 높이는 방향으로 설계하게 됩니다. 그리고 이는 재사용성, 유지보수성을 용이하게 해줍..