Kafka Streams를 활용하여 실시간 피드 제공 기능을 개발하는 도중 KStream-KTable 간 조인 시 발생했던 문제 상황을 공유하고자 합니다.글에서 제공되는 예시 코드는 실제로 동작하지 않는 pseudo code입니다.  현재 상황코스피/코스닥에 상장된 기업들의 주가 정보(시가/고가/종가/현재가 등등)을 5초마다 호출하여 파티션이 5개인 토픽에 저장합니다.오전 6시에 이전 영업일의 코스피/코스닥에 상장된 기업들의 valuation 값(per, pbr, psr 등등)들이 저장된 엑셀 데이터를 파싱하여 DB 저장 및 파티션이 1개인 토픽에 저장합니다. 두 토픽에 저장된 데이터를 이용하여 각 기업의 실시간 주가 정보를 이용하여 valuation을 계산하여 오전 6시에 엑셀 데이터를 파싱하여 토픽에..

최근 빌더 패턴을 구현하다 CRTP(Curiously Recurring Template Pattern) 패턴을 알게 되었는데, 처음 접하는 패턴이라는 점과 제네릭을 통해 구현된 다소 복잡해 보이는 패턴이라 공부하게 되었습니다. 이번 글을 통해 CRTP 패턴이 무엇인지와 장단점에 대해 소개드립니다. CRTP란?CRTP는 원래 C++에서 주로 사용되는 패턴으로 클래스가 자신의 서브클래스 타입을 제네릭 매개변수로 사용하는 디자인 패턴입니다. 자바에서는 주로 빌더 패턴에서 자식 클래스의 타입을 부모 클래스에 전달하여 메서드 체이닝 시 자식 클래스의 메서드를 사용할 수 있게 합니다. (제네릭을 이용한 재귀적 타입 제한) 즉, 빌더 패턴에서 주로 이루어지는 메서드 체이닝에서 자식 클래스 타입을 유지함으로 컴파일 시..

TL;DR주식 시장 마감 후 코스피/코스닥 종목의 종가와 수익률을 계산해 시황 피드를 생성하는 시스템에서 종가 변동률 계산 오류가 발생했습니다. 문제는 시황 정보 생성 시점에 당일 종가 정보가 DB에 아직 저장되지 않아 이전 영업일 데이터를 참조한 데 있었습니다. 이를 해결하기 위해 피드 생성 서버 코드를 수정하여 시황 정보 수신 시 종가 데이터 유무를 확인하고, 종가 정보가 없으면 상태를 저장한 후 스케줄러를 통해 주기적으로 재시도하는 방안을 도입했습니다. 이로써 데이터 정합성을 확보하고 버그를 수정했습니다. 항상 버그는 퇴근하고 발생하는 것 같은 기분이 듭니다.  주식 시장이 마감되고 코스피/코스닥에 상장된 종목들의 종가 및 종목 수익률을 계산하여 당일 시황의 전반적인 상황을 피드로 생성하여 제공하는..

문제기존 Protobuf 포맷으로 정의된 스키마(Version 1)에 새로운 inner message를 생성하여 스키마 버전(Version 2) 업을 하는 경우 이전 버전 스키마가 새로 생성한 inner message 를 참조하지 못하여 스키마 업그레이드를 하지 못하는 문제가 발생. 해결스키마에 inner message를 생성하는 방식이 아닌 별도의 schema를 생성하여 수정할 스키마에서 이를 참조하는 방식으로 해결 + Terraform Provider로 Confluent Schema Reference 적용 시 발생한 문제A스키마에서 B스키마를 참조할 경우 참조할 스키마(B)가 먼저 생성이 되어 있어야 한다."A" 스키마에서 새로운 메시지인 "B" 스키마를 참조하려고 할 때, "B" 스키마 생성과, "..

현재 서비스의 트랜잭션 범위에 대한 이해상품 주문 결제 트랜잭션Tx -> 사용자 조회 -> 장바구니 조회 -> 주문 및 주문 아이템 생성 -> 재고 차감 -> 결제 -> 주문 정보 전송 -> commit현재 트랜잭션 범위의 문제점긴 트랜잭션 : 하나의 트랜잭션에서 주문, 결제 같이 여러 작업을 처리하게 될 경우 트랜잭션의 작업 시간이 길어져, 다른 트랜잭션에서 커넥션이 필요할 때 대기시간이 길어져 사용성이 떨어진다.-> 트랜잭션의 사용시간이 길어 생기는 문제전체 롤백 문제 : 주문 정보를 외부 데이터 플랫폼에 전송 도중 오류로 인해 전송에 실패하면 이전 작업(주문 생성, 재고 차감, 결제)들이 모두 롤백된다. 상품 주문 시 핵심적인 비즈니스 로직이 부가적인 주문 정보 전송 로직에 의해 롤백되고 있기 때문..

주문 결제를 이벤트 기반 아키텍처로 구축하기이 글에서는 주문 결제 시스템을 이벤트 기반 아키텍처로 전환하면서 겪었던 문제와 그 과정을 공유하고자 합니다.  현재 이커머스 프로젝트의 주문 결제 시스템은 한 트랜잭션 내에서 동기 처리 방식으로 처리하고 있습니다.  현재 OrderUseCase를 간단히 살펴보면사용자 조회 -> 상품 조회 -> 상품 재고 조회 -> 주문 -> 결제 -> 재고 차감 순으로 주문 결제 시스템이 이루어져 있습니다. 그럼 이 주문 결제 시스템을 이벤트 기반 아키텍처로 구축하면서 겪었던 문제와 과정을 정리해 보겠습니다. 이벤트 기반 아키텍처로 변경하는 이유결합도 감소현재 주문 결제 시스템은 상품 재고 관련 로직, 결제 로직이 주문 로직에 깊게 관여되어 도메인끼리 강한 결합을 갖고 있다는..