지난번 포스팅에서는 Master/Slave DB를 사용하기 위해 어떻게 세팅을 하는지에 대해 다뤘다. 이러한 세팅을 적용하면서 궁금증이 생겼다. 세팅을 하기 위해 자료를 찾은 것과 그동안 공부했던 것들을 바탕으로 대충은 어떻게 동작하는지는 알게되었으나 더 자세히 알고 싶어졌다. 그래서 이번 글에서는 이 세팅이 어떻게 동작하는지 알아보기위해 코드를 훑어보는 시간을 가져보려고 한다. 개인 공부 용으로 남겨 놓는거라 복잡합니다. 핵심 부분은 LazyConnectionDataSourceProxy에 있으니 그 부분만 보시는 것을 추천합니다. 실행할 로직은 간단한 조회 API 입니다. @RestController public class AppApi { private final AppService appService..
SpringBoot Master/Slave DB 세팅 기존에 DB 를 하나만 사용하던 스프링 부트(버전 2.7.12) 프로젝트가 있다. 이 어플리케이션의 DB 세팅은 아래와 같이 application.properties 에 하나의 DB만 세팅 되어 있다. spring.datasource.url=IP spring.datasource.driver-class-name=org.mariadb.jdbc.Driver spring.datasource.username=계정 spring.datasource.password=비밀번호 spring.datasource.hikari.pool-name=풀이름 기타등등 hikari connection pool 세팅 이렇게 세팅을 해주면 스프링에서 알아서 데이터 소스를 만들어주고 사용..
MariaDB CDC 프로그램을 개발하고 테스트 하기 위해 MariaDB 설치를 진행했습니다. 로컬에 설치하는 것 보다는 컨테이너를 활용하는게 나을 것 같아 도커에 MariaDB 컨테이너를 올렸습니다. Docker compose 를 통해 MariaDB 를 설치하고 외부에 만들어 놓은 Config 파일을 세팅해주는 간단한 절차만 확인해보려고 합니다. 아래와 같은 순서로 글을 작성하겠습니다. 도커는 알아서 잘 설치해주셨으리라 믿고 가겠습니다 ^_^ Docker-compose 작성 MariaDB Config 작성 실행 및 확인 추가 이슈 Docker-compose 작성 MariaDB 컨테이너를 올리기 위해서는 도커 이미지가 필요합니다. 이미지를 받기 위해선 아래와 같이 pull 명령어를 사용하시면 됩니다. d..
Background 현재 사내 시스템 구조개선 진행중에 있습니다. 그중 아래와 같은 요구사항을 가진 시스템을 설계하게 되었습니다. - A 시스템 영역은 B 시스템 영역에 직접적인 의존성을 가지면 안됨 (ex: API 호출) - A Component 에서 실행한 로직이 성공하면 결과가 반드시 B Component 전파되어야 함 - A Component 에서 실행에 실패한 로직의 결과가 B Component 로 전파되면 안됨 - A Component 에서 발생한 로직의 결과는 B,C,D Component 로 전파가 될 수도 있음 간략하게 그림으로 표현해봤습니다. 시스템간 소통하는 방법은 다양한 방법이 존재합니다. 위와 같은 요구사항을 만족하기 위해 메시징 방법을 사용하기로 했고, 메시징 플랫폼 중 아파치 카..
이번 DDD 스터디가 끝나고 한동안 휴식을 취하며 공부했던 것들을 정리하는 시간을 가지려 했으나 우아한스터디 모집글을 봤습니다… 그동안 우아한스터디를 여러번 지원했지만 안타깝게도 함께 할 수 없었던 기억이 있어, 이번에는 꼭 참여해보고자 지원했습니다. 스터디 목록을 보고 가장 참여하고 싶은 스터디에 지원을 했고, 그 결과 2023 우아한스터디 겨울시즌-내 코드가 그렇게 이상한가요? 스터디에 참여하게 되었습니다. 이 스터디를 지원한 이유 중 첫번째는 책입니다. 스터디에서 다루게 될 책은 표지에도 써있는 것과 같이 좋은 코드와 나쁜 코드로 배우는 설계를 다루는 책입니다. 목차를 보니 전에 그동안 공부했었던 내용이지만 지금은 기억이 나지 않거나 실무에서 지키지 못하고 있는 내용이 많았습니다. 그래서 복습 차원..
예전부터 테스트를 작성하다보면 어떤 테스트가 좋은 테스트인지 궁금했습니다. 하지만 좋은 테스트에 대해 감히 내가 정의할 수는 없었습니다. '좋은' 이라는 단어가 상대적이어서 그럴수도 있고 단어 자체가 주는 부담감 또는 누구에게 좋은 테스트가 누구에겐 좋지 않을 수도 있는 케바케의 문제가 있을 수 있다고 생각해서 였습니다(케바케 보다는 상황에 따라서 라는 말을 더 선호합니다). 하지만 이 책에서는 좋은 테스트를 주제로 책을 시작하고 있습니다. 테스트를 왜 작성해야 하는지, 좋은 테스트란 무엇인지 쉽게 잘 설명해주어 이 글을 기반으로 정리용 글을 쓰기로 했습니다. 테스트의 가치란? 1. 테스트는 실수를 바로 잡아줍니다. 새로운 기능을 개발하면 작성한 코드가 기대했던 대로 동작하는지 확인을 해야 합니다. 그리..
지금까지는 주로 spring-restdocs 를 이용해 API 를 문서화 했습니다. spring-restdocs 를 사용한 이유는 아래와 같은 이유로 사용을 했습니다. 테스트 코드를 기반으로 작성, 테스트를 통과해야 문서를 만들 수 있으니 문서에 신뢰성이 생깁니다 프로덕션 코드에 문서화를 위한 코드를 추가할 필요가 없습니다 Swagger 는 문서화를 위한 코드를 추가해줘야 합니다 이러한 이유로 restdocs 를 사용했지만 문제가 있었습니다. 바로 문서를 보기 싫다는것! (제 기준으로는...ㅎㅎ) 기껏 신경써서 문서를 만들었지만 화면에 보이는 것은 칙칙한 API 문서… 조치가 필요했습니다. 그래서 Swagger 사용을 고려해봤으나 코드에 api 문서 관련 코드를 넣고 싶지 않아 사용하지 않았습니다. 자료..
Resilience4jFeign 을 사용해 Content-Type 이 x-www-form-urlencoded 인 API 를 호출할 때 요청 객체를 Record 로 선언하면 발생하는 문제입니다. 결제 시스템을 구현하던 중에 발생한 이슈입니다. 새 결제 시스템 프로젝트 구성은 아래와 같습니다. Java 17 Spring boot 2.7.9 resilience4j-feign 2.0.2 feign-(core,okhttp,jackson,slf4j) 12.2 feign-form 3.8.0 위와 같은 환경을 구성해 카카오페이 결제준비 API 를 호출할 때 발생한 이슈에 대해서 기록해 놓으려고 합니다. 회사 프로젝트를 올릴 순 없어 해당 이슈 기록을 위한 작은 프로젝트를 하나 만들었습니다. 아래 코드는 이슈를 설명하기..
아파치 카프카 - 애플리케이션 프로그래밍 (최원영 지음) 4장 4.1 토픽과 파티션 4.1.1 적정 파티션 개수 토픽의 파티션 개수는 성능과 관련이 있다. 그래서 파티션 개수를 정할땐 신중히 정해야 한다. 파티션 개수 고려사항은 아래 3개가 있다. 데이터 처리량 메시지 키 사용 여부 브로커, 컨슈머 영향도 데이터 처리량 파티션은 카프카 병렬처리의 핵심 요소이다. 파티션의 개수가 많아지면 컨슈머와 1:1 매핑되는 개수가 늘어나기 때문이다. 데이터 처리 속도를 올리는 방법은 컨슈머의 처리량을 늘리는 방법과 컨슈머,파티션을 추가해서 병렬처리량을 늘리는 방법이 있다. 컨슈머 처리량을 늘리는 방법은 Scale up, GC 튜닝 등이 있지만 일정 수준 이상 처리량을 올리기 어렵다. 반면 파티션 개수를 늘리는 방법은..
The Go Programming Language - 에이콘출판사 책을 정리한 글 입니다. The Go Programming Chapter 5. 함수 함수는 여러 문장을 하나의 단위로 묶어 프로그램 내의 다른 부분에서 수차례 호출 할 수 있다. 함수를 통해 큰 작업을 여러 작은 작업으로 분할할 수 있으며, 함수를 사용하면 사용자에게 구현의 세부 사항을 숨길 수 있다. 5.1 함수 선언 함수는 아래와 같은 형식으로 이루어져 있다. func 이름(파라미터 목록) (결과 목록) { 본문 } 파라미터 목록 함수 파라미터의 이름과 타입을 지정 이 인자는 함수를 호출하는 호출자가 값이나 인자를 제공한다. 결과 목록 함수가 반환하는 값의 타입을 지정한다. 함수가 한개의 이름없는 결과를 반환하거나 결과를 반환하지 않을..
참고 : 테스트 주도 개발 시작하기 - 최범균 (가메출판사) 테스트 관련 책들을 읽었으니 TDD 를 사용해서 개발을 해보려는데... 적용하는데 어려움을 겪고 있다. 생각보다 어렵다... 아니 생각을 해서 어려운건가 싶기도 하다. 단순하게 생각할 수 있다면 TDD 적용이 보다 수월할 거 같은데, 단순하게 생각한다는 것 역시 쉬운일이 아니다... 그래서 테스트에 대해 다시 공부를 할까도 싶었지만, 현재 공부중인게 있으니 테스트 공부는 나중으로 미루고 TDD 에 대해 간단하게 복습 및 정리만 하고 넘어가려고 한다. TDD에 대해 더 알고 싶으신 분은 위 참고에 나온 책을 보는 것을 추천드립니다. TDD(테스트 주도 개발) 이전의 개발 만들 기능에 대해 설계를 고민. 어떤 클래스, 인터페이스를 도출할 지 고민하..
