서론 exactly-once message delivery 과정에서 어떤 문제가 생길 수 있는지 알아보고 kafka transaction 처리가 어떤 방식으로 그 문제를 해결하는지 알아보자. 해당 글에서 write-produce와 read-consume은 서로 같은 의미로 썼습니다. 왜 transaction이 필요할까? 점차 많은 사람들이 카프카를 사용하면서 read-process-write 과정에서 exactly-once 기능의 지원을 필요로 했다. A 메세지의 consume이 B 메세지의 publish라는 필요충분 조건을 만족시켜야 했다는 말이다. 일반적인 at-least-once 프로듀서와 컨슈머로는 다음 상황들로 인해 exactly-once read-process-write(rpw)을 만족시키는 application을 만들 수 없다. producer의 중복 요청 : 이는 위에 언급한 producer에서 멱등성 유지를 위한 sequence 번호 부여로 해결가능하다.

기존 상황 n+1 쿼리를 db 호출 로그를 통해 육안으로 확인하고 있었습니다. 목적 테스트를 통해서 n+1 쿼리를 빠르게 방지할 수 있는 방법을 찾고 싶습니다. 해결 방안 datasource-proxy 라이브러리를 통해 실행한 쿼리문의 개수를 불러와서 예상한 쿼리문의 수와 맞는지 비교합니다. 설정 build.gradle.kts에 다음과 같은 내용을 dependencies에 추가합니다. implementation("net.ttddyy:datasource-proxy:1.7") 그리고 spring-boot에서 proxybean을 생성하게 위해서 BeanPostProcessor를 하나 만들어서 등록해줍니다. 테스트에서만 사용할 거라 적절한 @Profile도 붙여줍니다. @Configuration @Profile("test") class DatasourceProxyBeanPostProcessor : BeanPostProcessor { override fun postProcessAfterInitialization(bean: Any, beanName: String): Any?

이 글은 (1) Reasons & Ways to Improve Code Quality • Venkat Subramaniam • GOTO 2021 - YouTube 의 저만의 해석 및 감상문입니다. [TOC] 코드 품질을 왜 높여야만 하는가? 코드 품질을 높여야 하는 이유는 순전히 경제적인 이유 때문입니다. 코드의 품질이 낮아지면 코드의 가독성이 떨어지고 기능의 수정이나 개선을 하기 위해서 어떻게 해야 하는지 알아내기가 점점 어려워집니다. 그렇게 되면 시간을 많이 소요하게 될 것이고, 프로그래머들이 만들어내는 시간 대비 가치는 점점 낮아질 것입니다.