코딩 해파리

- 왜 '정확히 한 번'이 중요한가요?분산 메시징 시스템에서는 네트워크 장애나 애플리케이션 재시작으로 인해 데이터가 중복 처리될 위험이 항상 존재합니다. 예를 들어, 결제 시스템에서 중복 처리된 메시지는 사용자에게 이중 과금을 유발할 수 있습니다. '정확히 한 번' 보장은 이러한 문제를 원천적으로 방지하여 데이터 정합성을 유지하는 핵심 기술입니다.1️⃣ 멱등적 프로듀서 (Idempotent Producer)멱등적 프로듀서는 프로듀서의 재시도 과정에서 발생할 수 있는 메시지 중복을 방지하는 기능입니다.멱등성(Idempotence)이란?동일한 연산을 여러 번 수행하더라도, 단 한 번 수행한 것과 동일한 결과를 내는 특성을 의미합니다.멱등성이 아닌 연산: UPDATE count = count + 1 (호출할 ..

인스턴스 생성 방식에는 크게 4가지가 있을 것 같습니다.자바 기준으로 설명을 드리겠습니다!그냥 new를 사용정적팩토리 메서드를 이용Builder 패턴을 이용기본 생성자 + Setter1. 생성자 호출 (new 키워드)User user = new User("Haepal", 27);언제 쓰나?필수값이 명확하고 객체 상태를 명확히 유지하고 싶을 때필드 개수가 적고 단순한 객체일 때 가장 심플불변(Immutable) 객체 생성 시 간편하고 명확함문제점생성자에 인자가 많으면 가독성 급감 (예: new User(a,b,c,d,e,f,g,h) ← 보기 어려움) - 근데 사실 요즘 IDE가 매우매우 좋아서 파라미터명 힌트를 줘서… 가독성도 낫배드…선택적 필드 처리에 취약 (null 남발 가능)결론: 필수 필드가 소수이..

디테일하게 더 알고싶다는... 욕심으로...카프카 핵심 가이드라는 책을 읽고 공부하며 정리하기 위해 이 카테고리를 만들었습니다..!그럼 시작하겠습니다!데이터 중심 시대, 왜 카프카(Kafka) 인가?📌 본질은 결국 데이터다기업은 끊임없이 데이터를 수집하고, 분석하고, 이를 기반으로 가치를 창출합니다.이 과정에서 중요한 데이터를 필요한 곳에 빠르게 전달하는 능력이 필수적입니다."과학자들이 의견 차이가 생기는 이유는 오직 데이터가 부족하기 때문이다. 충분한 데이터를 얻으면 문제는 해결된다." — 닐 디그래스 타이슨그래서 우리는 데이터를 빠르고 안정적으로 전달하는 기술, 즉 데이터 파이프라인을 구축하고자 합니다.📌 발행/구독 (Pub/Sub) 메시지 전달 방식이란?Pub/Sub 패턴이란?메시지를 보내는 쪽..

(2장) 의존성 역전하기1. 단일 책임 원칙(SRP)이 원칙의 일반적인 해석은 다음과 같습니다.‘하나의 컴포넌트는 오로지 한 가지 일만 해야 하고, 그것을 올바르게 수행해야 한다.’ 이는 좋은 조언이지만, 단일 책임 원칙의 실제 의도는 아니라고 필자는 말합니다.‘오로지 한 가지 일만 하는 것’은 단일 책임이라는 말을 가장 직관적으로 해석했지만, 실제 정의는 다음과 같습니다. ‘컴포넌트를 변경하는 이유는 오직 하나뿐이어야 한다.’ 여기서 강조하는 부분은 ‘책임’이란 사실 ‘오로지 한 가지 일만 하는 것’ 보다는 ‘변경할 이유’로 해석해야 한다는 것입니다!아키텍처에서는 이것이 어떤 의미일까요?만약 컴포넌트를 변경할 이유가 한 가지라면 우리가 어떤 다른 이유로 소프트웨어를 변경하더라도, 여전히 이 컴포넌트는 ..

[만들면서 배우는 클린 아키텍처 - 톰 홀버그]라는 책을 읽으며 정리한 글입니다!졸업 프로젝트에서 헥사고날 아키텍처를 적용하면서 코드를 작성하려고 노력했지만, 부족한 지점들이 많은 것 같아서... 공부하기 위해... 이 책을 조금 더 열심히 파보고 정리해보려 합니다..!시작하며헥사고날 아키텍처 먼저 약간 알아보자면, 애플리케이션은 비즈니스 관심사를 다루는 내부(inside)와 기술적인 관심사를 다루는 외부(outside)로 분해됩니다. 여기서 외부에 포함된 기술적인 컴포넌트를 어댑터(adapter)라 부르고, 어댑터가 내부와 상호작용하는 접점을 포트(port)라고 부릅니다. 헥사고날 아키텍처 패턴을 포트와 어댑터 패턴이라고도 부르는 이유가 바로 이 때문입니다.[도메인 주도 설계 - 에릭 에반스]에서 “도..

들어가며현재 프로젝트 목표 중에 높은 트래픽 상황을 견디며 처리하는 성능이 좋은 서버를 구축하는 부분이 있었습니다. 하지만, 기존에는 주문 생성 이벤트가 들어올 때마다 매번 DB에 쓰기 작업을 수행하도록 설계되어 있었기 때문에, 주문이 발생하였을 때 상품 재고 감소 처리 로직(재고 차감 로직)에서 심각한 성능 저하가 발생했습니다. 이렇게 많은 이벤트를 단건 단위로 처리하다 보니, 트래픽이 폭주할 때 자원 사용량 증가로 시스템 전반에 병목 현상이 생겼습니다.이 글에서는 이벤트 배치 처리 방식을 도입하여 성능을 최적화한 과정을 공유합니다. 기존 문제점N건의 이벤트에 대해 N번의 DB 쓰기주문 생성 이벤트가 1건 들어올 때마다 상품 서비스에서 재고 차감 로직을 실행 → DB에 직접 쓰기.이벤트가 폭발적으로 증..

- 개발 환경 - 애플실리콘 MacOSGCP - GKE   마주했던 문제 상황... 1. GCP에서 Google K8s Engine을 통해 애플리케이션을 배포2. GCP의 Managed Kafka가 아직 베타인건지... 제대로된 안내 or 레퍼런스가 존재 x -> 포기3. 인프라 담당한 팀원이 Confluent Kafka 공식 사이트의 Helm 차트 안내서를 통해 카프카를 통합 배포4. 현재 Outbox - CDC 패턴을 적용하여 Debezium이 필요5. 통합 배포된 Kafka Connector에 Debezium 플러그인이 필요 이런 상황을 겪으신 분들이 있을지... 모르겠지만... ㅎㅎ;;해결책을 공유해보겠습니다원래 로컬에서 테스트할 때는 Debezium이 미리 설치된 이미지를 쓰기 때문에 당연히 문..

들어가며이 포스팅은 "MSA 환경에서 이벤트를 주고받으며 프로세스를 진행할 때 발생할 수 있는 데이터 정합성 불일치 문제 발생"을 주제로 합니다. 제 졸업 프로젝트에서 MSA를 적용할 때, 서비스를 분리하기만 하면 끝나는 줄 알았지만 실제론 이벤트가 중복 처리되거나 외부시스템(DB)이 커밋을 실패하거나... 하는 등의 이유로 전체 데이터 정합성이 깨질 수 있는... 곤란한 일이 생길 수 있다는 사실을 깨닫고 많은 고민을 하며 해결했던 과정을 정리해보았습니다.1. 네트워크와 브로커는 100% 신뢰가 어렵다네트워크 장애로 인하여 패킷 손실 혹은 타임아웃 등으로 인해 오프셋이 커밋되지 않는 등의 이유로 재전송이 여러 번 이뤄져 중복 이벤트 컨슘 상황이 발생할 수 있습니다. 또한, 모종의 이유로 이벤트를 발행한..

들어가며졸업 프로젝트를 진행하기에 앞서 처음 마주한 고민은 "모놀리식(Monolithic) 구조로 갈까, 아니면 MSA(Microservices Architecture)로 갈까?"라는 질문이었습니다. 사실 초기에는 하나의 애플리케이션으로 통합해버리면 개발과 배포가 간편할 것이라 생각했는데, 실제로 조사하고 실험해보니 예상치 못한 문제들이 나타났습니다. 이번 포스팅에서는 제가 왜 MSA를 도입해야겠다고 결심하게 됐는지(모놀리식 대비 MSA의 강점)와 분산된 서비스들 간에 어떻게 데이터를 주고받을 것인지(Remote API vs Message Queue)에 대해 정리하려고 합니다. 1. 왜 MSA를 도입했나? — 모놀리식과의 비교1.1 모놀리식의 장점개발 초기 편리성: 초기에는 한꺼번에 빌드하고 배포하면..

이 졸업 프로젝트 관련 포스팅들을 적기에 앞서,저는 어느 정도 규모가 큰 서비스 기업에서 유난히 많이 채택하는 기술,코드 수준의 설계 원칙, 아키텍처에 대한 선택의 이유가 항상 궁금했습니다. 대표적으로 아키텍처 구조로는 MSA(Microservices Architecture)와 EDA(Event-Driven Architecture)가 있었고,기술로는 Kafka, Kubernetes(K8S), Redis 등이 있었습니다.코드 수준의 설계 원칙으로는 DDD(Domain-Driven Design), 헥사고날 아키텍처, TDD(Test-Driven Development) 등이 있었습니다.또한, 많은 기업들이 채용 공고에서 요구하는 '대용량 트래픽 경험'이라는 표현을 보면서, 그것이 얼마나 어렵고 고려할 사항이 ..