(kafka) debezium을 사용한 exactly once producing

Abstract마이크로서비스 아키텍처(MSA) 환경에서 서비스 간 메시지 전송의 정합성을 확보하는 일은 매우 중요한 과제입니다. 일반적인 Kafka acks 설정만으로는 메시지 중복 전송 방지나 전송과 오프셋 커밋의 원자성을 동시에 만족시키기 어렵습니다. 이 글에서는 enable.idempotence와 transactional.id 기능을 활용해 브로커 단계에서 exactly‑once producing을 완전하게 확보하는 방법을 설명합니다. 아울러 Debezium을 통한 DB CDC(Change Data Capture)와 Kafka Connect/Connector 구조를 결합하여, 외부 데이터베이스 트랜잭션과 Kafka 메시지 전송 간의 일관성을 유지하면서도 높은 확장성과 운영 편의성을 제공하는 방안을..

Context테스트 커버리지는 안정성의 척도인가?어떤 애플리케이션이든 기능이 고도화됨에 따라서 코드가 많아지고, 이 코드가 정상적으로 동작하는지를 테스트하기 위해서 우리는 많은 테스트 코드를 작성합니다. 그리고 우리는 테스트의 커버리지를 척도로 삼아 이 애플리케이션이 얼마나 안정적인가를 따지곤 합니다. 하지만 실제로 테스트 커버리지가 높다고 해서 애플리케이션이 안정적인 것은 아닙니다. 커버리지는 단순히 "작성된 코드 중 테스트가 실제로 실행한 부분"으로, 예외 상황이나 경계 조건까지 테스트를 하지 않으면 수치가 높아도 의미가 없습니다. 그럼에도 불구하고 커버리지가 중요한 이유커버리지는 BMI에 비유한다면 BMI가 건강의 전부는 아니지만, 기초 지표로는 유용한 것처럼, 커버리지도 그런 신호등 역할을 해줍..

EDA에 많은 관심을 가지고 있어서 이벤트에 대해 많은 공부를 하게 되었고,그중 멱등성 있는 이벤트 발행하기라는 주제로 글을 작성하려고 합니다.  # 이벤트EDA에서 이벤트는 단순한 기록으로 처리되는 것이 아니라 시스템 구성요소 간의 동기/비동기 통신 및 비즈니스 로직 실행의 핵심 메시지로 취급합니다. 일반적인 layered architecture를 생각해 보면,A 엔티티의 변경사항이 발생하고, 이 이벤트를 A와 관련된 엔티티에 전파해야 한다면, A service  이런 패턴은, 응집도를 떨어뜨리고, 결합을 강하게 만들어 좋은 패턴이라고 볼 수는 없죠. @RequiredArgsConstructorpublic class Aservice { private final ARepository aReposit..

이 글에서는 flyway를 어떻게 spring boot에 적용하는지에 대해 작성하겠습니다. Flyway는 DB 버전 관리 툴로, 다양한 DB를 지원하고 마이그레이션을 지원합니다. 의존성 추가 및 기본 설정plugins { ... id("org.flywaydb.flyway") version "9.0.0"}dependencies { implementation("org.flywaydb:flyway-core")} build.gradle에 이렇게 두 개의 문장을 추가해 의존성을 추가해줍니다.  flyway { url = db_url user = db_user password = db_password locations = arrayOf(db_migration_file_loc) # 기본 위치는 filesyst..

트랜잭션에는 4가지 격리수준이 있습니다. read uncomittedread comittedrepeatable readserializable 그리고 각각의 트랜잭션은 다음과 같은 문제를 발생할 수 있습니다.dirty readnon-repeatable readphantom read(phantom read는 MVCC덕에 발생하지 않습니다.) 하지만 이와 별개로 serialiable을 제외한 트랜잭션 격리 레벨에서 발생할 수 있는 lost update 문제가 있습니다. Lost updateLost Update는 동시성 제어 문제 중 하나로, 두 개 이상의 트랜잭션이 동시에 같은 데이터를 수정하려고 할 때 발생할 수 있습니다. 이는 하나의 트랜잭션이 수행한 업데이트가 다른 트랜잭션에 의해 덮어쓰여지는 상황을 말..

* 몇 개월 전, 회사에서 문제 해결을 위해서 리팩터링이 있었고, 그 과정에서 에러가 발생했었는데, 그 경험을 공유하고자 이 글을 작성합니다.  저에게 하루 약 120만 건 이상의 요청이 들어오는 서버에 관한 태스크가 주어졌습니다. 서버에 새로운 파이프라인을 추가했고, 이에 대해서 개발환경에서 모든 테스트를 마치고, 실제 운영환경에 배포했습니다.  무사 배포를 기원했지만, 배포하자마자 서버는 죽었다 살아나기를 반복했고, 이 때문에 바로 서버를 롤백했습니다.  저는 매우 의아했습니다. 에러가 발생한 지점의 코드를 저는 고친 것이 없었고, 해당 지점에서 원래 에러가 발생하고 있지 않았기 때문이죠. 그렇게 한 시간 동안 원인을 찾기 위해 로그를 열심히 찾았고, 결국 문제의 원인을 찾아냅니다.    문제 발생의..