Jinnie devlog

Redis의 ZSET은 정렬된 집합으로, "멤버"는 유일한 문자열이고 각 멤버에 붙는 "점수"로 오름차순으로 정렬된다. ZSET(Sorted Set) 는 (member, score) 쌍을 점수 기준 정렬해 보관한다.ZINCRBY key delta member : 멤버 점수를 가산/감산(원자적)ZREVRANGE key start stop WITHSCORES : 점수 내림차순으로 페이지 조회ZREVRANK key member : 멤버의 0-based 순위ZSCORE key member : 멤버 점수 조회EXPIREAT key ts : 키 만료 시각 지정랭킹은 실시간 가산, 빠른 페이지 조회, 상위 N개가 핵심인데, 이 조합이 ZSET에 딱 맞다. 정렬된 집합: 각 멤버에 실수 점수(score) 를 붙여 자동..

Kafka 는 흔히 고성능 메시지 큐라고 생각하지만, 근본적으로는 분산 로그 저장소(Distributed Log Store)이다.Kafka 는 메세지가 흘러가는 통로보다는 로그가 쌓이는 거대한 시스템 에 좀 더 가깝다.일반적인 Message Queue 와는 다르게 디스크에 Log 를 지속적으로 append 함Consumer 는 각자의 Offset 을 기억하고 필요한 시점부터 읽는 것이 가능함 (재처리 가능)Kafka 의 주요 특징고가용성 - Partition + Replica 구조로 브로커 장애 시에도 데이터 유실을 최소화확장성 - Broker, Partion 의 수평 확장으로 처리량의 선형 증가범용성 - 단순 메세징 뿐이 아닌 다음의 용도로도 사용로그 수집이벤트 소싱스트리밍 처리의 기반핵심 구성요소Pr..

커머스 시스템을 구현하면서 재고 차감, 포인트 차감, 쿠폰 사용, 결제 처리 등 모든 흐름을 하나의 트랜잭션 안에서 처리하였다. 하지만 이 방식은 트랜잭션이 커지고, 실패 포인트가 많아지며, 시스템의 결합도도 높아지는 단점이 있다.이러한 단점들을 해결하고자 애플리케이션 이벤트를 활용해 유스케이스의 후속 흐름을 분리하고, 비동기 트랜잭션 흐름을 설계하는 방법을 알아보았다. 왜 트랜잭션을 나누는가?현재 구조의 문제점실패 전파PG API가 느려지거나 실패하면 주문 전체가 롤백됩니다높은 결합도User, Product, Coupon, Payment 도메인이 모두 한 흐름에 엮입니다재시도 불가롤백은 가능하지만, 어디까지 성공했는지 불확실하여 복구가 어렵습니다성능 저하트랜잭션이 길어질수록 DB 락이 길게 유지되어 T..

회사에서 업무를 하다 보면 외부 시스템과의 수많은 인터페이스를 경험하게 된다. 나는 통계 시스템을 담당하고 있는데, 하드웨어 장비, 통합인증, 인사 시스템 등으로 부터 데이터를 받아 통계를 생성하게 된다.물론 결제와 같이 실시간으로 장애를 대응해야 하는 것들은 아니지만 인터페이스가 불가능 한 상태가 되거나 배치가 제 시간에 작동하지 않으면 통계가 틀어질 수 있어서 매일 아침 실패한 배치가 없는지 확인하고 있다. 커머스 시스템의 상품 주문-결제 과정에서는 사용자가 물건을 선택하여 주문을 진행하고, 결제까지의 프로세스를 타게 된다.주문(Order) 과정 안에 결제(Payment) 로직이 껴있다 보니, 결제(PG 연동)가 실패하게 되었을 때 그에 대한 처리가 잘 안되어있다면 결제는 되지 않았는데 주문이 성공하..

회사에서 신규 통계 테이블을 생성할 때, 매번 인덱스를 설정하고 있었음에도 형식적으로만 적용하였지 깊게 고민해보고 적용하지 않았던 것 같다.많은 양의 데이터를 조회할 경우, 성능 개선을 위해 인덱스 적용은 거의 필수라고 볼 수 있는데 테스트를 위해 10만개의 데이터를 세팅하였고 K6라는 성능 측정 도구도 사용해보았다.인덱스 적용 전인덱스 적용 전에 실행되는 쿼리SELECT p.id, p.name, p.price, p.brand_id, COALESCE(cnt.c, 0) AS like_countFROM products p LEFT JOIN ( SELECT product_id, COUNT(*) AS c GROUP BY product_id) cnt ON cnt.produ..

커머스 시스템의 주문 로직에 쿠폰 기능을 추가하면서, 주문 과정에 필요한 트랜잭션이 점점 많아졌다. 그동안은 거의 모든 서비스 클래스에 @Transactional을 붙여 사용했고, 특별한 문제는 없었다.그런데 찾아보니 무분별한 트랜잭션 사용은 성능 저하와 의도치 않은 트랜잭션 경계를 만들 수 있다는 사실을 알게 됐다.그래서 “가능한 한 @Transactional을 빼보자”는 마음으로 무작정 제거 후 테스트를 돌렸다가, 두 번의 힘든 경험을 했다.첫번 째 경우 - 좋아요 기능의 TOCTOU(체크-사용 사이 레이스)public LikeInfo like(LikeCommand.Create likeCommand) { final LikeEntity likeEntity = LikeEntity.of(likeCom..

이번 주차에는 지난주에 설계한 내용을 바탕으로 실제 코드를 구현해보았다.아직 DDD와 클린 아키텍처가 익숙하지 않다 보니 전체적인 구조를 잡는 데에 꽤 많은 시간이 소요되었고, 각 계층의 역할을 구분하여 구현하는 것이 쉽지 않았다.이번 구현은 다음과 같은 순서로 진행하려고 노력했다:도메인 테스트 코드 작성 → 엔티티 생성 → 서비스 테스트 코드 작성 → 서비스 구현 → 파사드 테스트 코드 작성 → 파사드 구현 정확하게 맞는 방식인지는 잘 모르겠지만, 도메인 엔티티를 우선 정의하고, 해당 도메인에서 수행되어야 하는 기능들을 도메인 서비스에 작성하는 방식으로 접근했다.📦 도메인 서비스 구성BrandService브랜드 생성, 브랜드 단건 조회ProductService상품 생성, 상품 조회, 재고 차감/추가 ..

회사에서 프로젝트나 일을 하면서, ERD 를 그려본 적은 있었지만 그 외의 다른 설계 문서를 작성해 본 적은 없다.사내 임직원들을 위한 마음 건강 플랫폼 개발을 주도적으로 진행했었는데, 비개발자인 현업과 소통하기 위해 요구사항과 간단한 화면정의서만 작성한 후 바로 구현을 시작했었다.비교적 단순한 도메인이었기에 큰 무리 없이 개발은 완료했지만 시퀀스 다이어그램, 클래스 다이어그램, ERD 등 설계 문서를 작성하는 과정을 거쳤다면 더 명확하게 요구사항을 정의하고, 구현 하는 데에 고민하는 시간을 줄일 수 있었겠다는 생각이 들었다. 무엇보다, 협업 하는 데에 큰 도움이 되었을 것 같다. 이번 과제를 통해 아래의 문서들을 작성해보았다.요구사항 정리 / 기능 명세시퀀스 다이어그램클래스 다이어그램ERD(Entity..