상어코딩

설계 동기앞서 1편에서는 boolean 기반 sent 필드로 Kafka 전송 여부를 관리하는 기존 구조의 한계를 진단했습니다. 특히 다음 세 가지 문제를 해결하고자 리팩토링이 시작되었습니다:전송 결과의 모호함: 실패와 성공을 구분할 수 없음재시도 전략 부재: Kafka 전송 실패 시 복구 불가배치 최적화 미흡: Kafka로 단일 이벤트를 순차 처리 → TPS 병목설계 목표이번 개선의 핵심 목표는 다음과 같습니다.목표 항목개선 전개선 후상태 표현 방식boolean sentenum OutboxStatusKafka 전송 전략단일 전송배치 전송 + 상태 기반오류 처리실패 감지 불가실패 정보 저장 및 재시도 가능전송 주기없음스케줄러로 관리삭제 정책수동 삭제SENT + 시간 조건 기반 자동 삭제상태 모델링 - Ou..

도입서비스에 유저 활동 로그를 남기기로 결정한 이후, 나는 곧 중요한 딜레마에 부딪혔다. "유저 활동 로그는 쓰기 트래픽이 압도적으로 많고, 유실되어서는 안 되며, 속도도 중요하다." 이 세 가지 요구사항을 만족하기 위해 기존 Outbox 구조를 되돌아보게 되었다.기존의 Outbox는 단건 이벤트를 즉시 저장하고, Kafka로 전송하는 방식으로 구성되어 있었다. 하지만 로깅 시스템은 본질적으로 다르다. 수많은 작은 이벤트가 순식간에 쏟아지기 때문에, 기존 구조로는 병목이 생기고, 네트워크 사용량 또한 비효율적으로 늘어난다.기존 Outbox 구조의 한계초기 Outbox 구조는 단순하고 직관적이다.OutboxEventEntity에는 sent: boolean만 존재Kafka 전송은 개별 이벤트 단위상태 관리나..

1. 도입 – 로그를 Kafka로 바로 보내면 안 되는 이유1편에서 우리는 왜 유저 활동 로그를 수집해야 하는지, 그리고 Kafka를 도입하기로 결정한 이유를 설명했다.하지만 Kafka를 도입한다고 해서 모든 게 해결되진 않았다.유저 요청이 올 때마다 Kafka로 바로 전송한다면?요청 응답 속도에 영향을 줄 수 있다.Kafka에 대한 의존성이 높아지며, 장애에 취약해진다.로그가 수백 TPS로 들어오는 경우, Kafka 자체도 부하를 받는다.그래서 우리는 메모리 버퍼 기반 로그 수집기를 직접 만들기로 했다.2. 설계 목표 – 단순히 "버퍼에 쌓기"가 아니다우리가 만든 수집기는 단순한 List 저장소가 아니다.아래 세 가지 요구사항을 만족해야 했다.1. 로그 유실 없이, 빠르게 저장→ 버퍼는 비동기로 데이터..

"왜 우리는 로그 수집기를 직접 만들기로 했을까?"1. 도입플랫폼이 성장하고 트래픽이 늘어나면서, 단순한 서버 로그만으로는 부족해지는 순간이 온다.우리는 사용자와 플랫폼 간의 상호작용을 정밀하게 추적하고 싶었다.사용자가 어떤 합주실을 둘러보는지어떤 경로로 예약까지 이어지는지비정상 요청이 반복되는 경로는 어디인지이 모든 것을 알기 위해선, 단순 로그가 아닌 행동 기반 이벤트 수집기가 필요했다.2. 설계 목표처음부터 무리한 대시보드나 통계 시스템을 만들 생각은 없었다.우리의 목표는 다음 세 가지였다.유저의 주요 활동을 놓치지 않고 수집한다플랫폼 장애나 지연에도 유실되지 않도록 설계한다추후 분석 시스템과도 유연하게 연동할 수 있게 한다→ 이 목표를 만족하기 위해선,단순한 DB INSERT 또는 파일 로깅 방식..