상어코딩

1. 목표와 범위목표기본적인 운영 데이터 분석을 위한 유저 활동 데이터(페이지뷰, 액션) 수집밴드룸 상세 페이지에서 일/주 단위 방문자 수(PV/UV) 통계 제공운영 모니터링(성능/지연/에러율) 및 로그 수집 기반 문제 진단범위Web/모바일 클라이언트/서버에서의 이벤트 수집이벤트 스트리밍, 실시간 카운팅, 집계/서빙 API운영 지표 수집·알림 체계제외마케팅 퍼널/리텐션/고급 코호트 분석(향후 OLAP 확장 시 포함)세션 리플레이, 히트맵 등 고급 프론트 분석(외부 솔루션 연동 고려)2. 용어 정의페이지뷰(PV): 특정 리소스(밴드룸 상세/리스트 등)에 대한 조회 사건 수고유방문자(UV): 중복 없는 방문자 수(사용자 또는 세션 기준)이벤트: 유저 활동 로그(페이지뷰, 클릭 등), 추적 가능한 단위 레코드..

리뷰 시스템 DSL 구현DSL(Domain Specific Language) 설계리뷰 조회를 위한 직관적이고 유연한 DSL을 설계하여 복잡한 쿼리를 간단하게 표현할 수 있도록 구현했습니다.ReviewQueryBuilder 클래스 구현public class ReviewQueryBuilder { private Long reservationId; private Long userId; private Long bandRoomId; private Long reviewRate; private SortCriteria sortCriteria; private Sort.Direction sortDirection = Sort.Direction.ASC; public static Review..

리뷰 모듈 기획·설계·구현 정리서 (review × bandroom-info 메시징 & 캐싱 중심)1. 배경과 목표1.1 배경밴드룸 플랫폼은 사용자들이 합주실(밴드룸)을 선택할 때 객관적인 평판 지표(평균 평점, 리뷰 수)를 빠르게 확인할 수 있어야 한다. 리뷰 본문(텍스트, 사진 등)은 review 도메인에서 보관/조회하고, 대량 트래픽이 걸리는 리스트/상세 뷰에서 필요한 핵심 지표(평균 평점, 리뷰 수)는 bandroom-info에 캐싱하여 고속으로 제공하는 전략을 택했다.1.2 목표리뷰 생성/수정/삭제 시점의 이벤트를 통해 bandroom-info의 캐시(리뷰 수/평점)를 일관되게 갱신한다.트래픽 많은 조회 경로에서 bandroom-info의 캐시만으로도 빠르고 비용 효율적인 응답을 제공한다.실패/..

1) 요약본 저장소는 public/* 공용 모듈과 service/, bandroom/, application/* 도메인 모듈로 구성되어 있습니다.공용 모듈은 광범위하게 참조되며, 특히 exception, infra-messaging, data-serializer, event, logtracer, infra-redis 등이 높은 빈도로 사용됩니다.다수의 패키지 네이밍 오탈자(response, excrptions)가 코드 전반에 퍼져 있으며, 이는 패키지 체계의 일관성을 해치고 IDE 네비게이션/자동완성에도 부정적입니다.일부 모듈 간 경계가 모호하거나 중복(예: response와 common-api의 경계, event/contract/infra-messaging/outbox의 경계)하여 통합 또는 명확화가 ..

들어가며메시징은 마이크로서비스의 혈관이다. 그러나 현실의 메시징 인프라는 “브로커 혼용, 불일치한 컨슈머 정책, 산발적인 직렬화 규약, 미흡한 트레이싱/관측성, 표준화되지 않은 재시도/DEAD 처리”라는 복합 문제를 안고 있는 경우가 많다. 본 글은 이러한 문제를 체계적으로 요약하고, 본격 도입에 앞서 안전하게 실험(Playground)하기 위해 만든 리포지토리와 설계 아이디어를 공유한다. 최종적으로는 도메인 코드가 브로커 구현에 의존하지 않도록 추상화(DIP)를 적용하고, Outbox/Producer/Consumer/트레이싱/관측성을 하나의 스타터로 수렴하는 여정을 제시한다.이 글은 다음 순서로 진행된다.문제점만 요약그래서 본격 도입 전에 실험실(Playground)을 만들었다일반적인 메시징 큐 시스템..

로컬 개발 환경의 지옥, 그리고 Docker의 등장MSA가 제공하는 수많은 장점에도 불구하고, 개발 단계에서는 여러 서비스와 데이터베이스, 메시지 큐 등을 모두 로컬 머신에 띄워야 하는 '개발 환경의 지옥'을 마주하게 됩니다. 각 서비스의 의존성, 포트 충돌, 설정의 파편화는 개발자의 생산성을 심각하게 저하시키는 주범이죠.저희 프로젝트 역시 인증, 메일, 사용자 프로필, 이미지, 합주실 정보/예약 등 수많은 서비스와 MySQL, Redis, Kafka, RabbitMQ 등 다양한 인프라를 사용하고 있었습니다. 이를 해결하기 위해 저희는 Docker와 Docker Compose를 도입하여, 명령어 한 줄로 전체 개발 환경을 일관성 있게 구축하는 것을 목표로 삼았습니다.핵심 전략 1: 관심사 분리를 통한 d..

Docker-Compose와 Nginx로 시작하는 마이크로서비스 아키텍처저희 팀은 확장성과 유지보수성을 높이기 위해 MSA를 도입하기로 결정했고, 그 기반을 다지기 위해 Docker와 Nginx를 선택했습니다.이 글에서는 여러 개의 Docker Compose 파일을 활용하여 인프라 서비스와 애플리케이션 서비스를 분리하고, Nginx를 리버스 프록시(Reverse Proxy) 로 설정하여 모든 요청을 단일 창구에서 관리하는 방법을 다룹니다. 그리고 마지막으로, Docker 환경에서 거의 반드시 마주치게 되는 localhost 네트워크 트러블슈팅 경험을 자세히 공유해 드립니다. 1단계: 서비스의 분리 - infra.yml vs apps.ymlMSA는 여러 서비스의 집합입니다. 이 서비스들은 크게 두 ..

[MSA 실전 아키텍처] 캐시, N+1 문제를 넘어 Kafka로 데이터 무결성까지MSA(마이크로서비스 아키텍처)에서 성능과 데이터 일관성은 종종 트레이드오프 관계에 놓입니다. BFF(Backend For Frontend)가 여러 마이크로서비스의 데이터를 조합할 때, 단순한 API 호출은 N+1 문제로 성능을 저하하고, 캐시(Cache)는 데이터 불일치라는 또 다른 숙제를 남깁니다.이 글에서는 '닉네임 조회'라는 간단한 기능에서 출발해, 배치(Batch) 처리로 N+1을 해결하고, 더 나아가 Kafka를 이용한 이벤트 기반 동기화로 캐시의 데이터 무결성까지 확보해 나간 저희 팀의 아키텍처 진화 과정을 공유합니다. 1. 시작점: N+1 문제와 배치(Batch) 처리의 도입게시글 목록처럼 한 화면에 여러..

왜 로그 추적기가 필요한가?현대의 애플리케이션은 여러 개의 독립적인 서비스들이 서로 통신하며 하나의 큰 비즈니스 로직을 완성하는 MSA 구조를 채택하는 경우가 많습니다. 예를 들어, 사용자의 '결제 요청' 하나를 처리하기 위해 BFF(Backend for Frontend) -> 결제 서비스 -> 외부 PG사 API -> 주문 서비스 -> 메시지 큐 등 수많은 단계를 거칠 수 있습니다.이런 환경에서 장애가 발생하거나 성능 저하가 의심될 때, 분산된 로그들을 하나하나 뒤져가며 원인을 찾는 것은 엄청난 시간과 노력을 소모하는 일입니다.로그 추적기는 이러한 분산된 호출들을 하나의 트랜잭션 ID(Trace ID)로 묶고, 호출 깊이를 시각적으로 표현하여 전체 요청의 흐름과 각 단계의 소요 시간을 명확하게 보여줍니..

1. AOP, 대체 왜 필요한가? - 프로그래밍의 '관점'을 바꾸다본격적인 이야기에 앞서, AOP가 무엇인지, 그리고 왜 현대적인 소프트웨어 개발에서 필수적인 패러다임으로 자리 잡았는지부터 짚고 넘어가겠습니다.두 종류의 '관심사'소프트웨어를 개발할 때 우리가 작성하는 코드는 크게 두 가지 '관심사(Concern)'로 나눌 수 있습니다.핵심 관심사 (Core Concern): 애플리케이션의 본질적인 기능, 즉 비즈니스 로직 그 자체를 의미합니다. 예를 들어, '쿠폰을 발급한다', '사용자 프로필을 조회한다', '예약 스케줄을 확인한다'와 같은 기능들이 여기에 해당합니다. 이들은 애플리케이션이 존재하는 이유 그 자체입니다.횡단 관심사 (Cross-Cutting Concern): 비즈니스 로직과 직접적인 관련..