별걸 다 좋아하는 사람

2025년 공부 내용은 깃허브에 기록 중 입니다.

넓고얕은사람 — Thu, 16 Oct 2025 14:55:37 +0900

https://github.com/dmlal/DevStudy_Summary

GitHub - dmlal/DevStudy_Summary: 공부한 개발 컨텐츠 요약 정리 용 레포지토리

공부한 개발 컨텐츠 요약 정리 용 레포지토리. Contribute to dmlal/DevStudy_Summary development by creating an account on GitHub.

github.com

코드를 정리해야할 일이 많아 깃허브로 이전하였습니다.

개인적으로 공부한 내용은 깃허브에 기록 중 입니다.

넓고얕은사람 — Thu, 16 Oct 2025 14:54:01 +0900

https://github.com/dmlal/DevStudy_Summary

GitHub - dmlal/DevStudy_Summary: 공부한 개발 컨텐츠 요약 정리 용 레포지토리

공부한 개발 컨텐츠 요약 정리 용 레포지토리. Contribute to dmlal/DevStudy_Summary development by creating an account on GitHub.

github.com

코드를 기록 해야할 일이 많아 깃허브로 이전하였습니다.

실전 카프카 개발부터 운영까지 2

넓고얕은사람 — Sun, 5 Jan 2025 16:22:54 +0900

카프카 주요 구성요소

1. 카프카(또는 카프카 클러스터)

2. 브로커

카프카가 설치된 서버 또는 노드

3. 프로듀서

카프카로 메세지를 보내는 역할을 하는 클라이언트

4. 컨슈머

카프카에서 메세지를 꺼내가는 역할을 하는 클라이언트

컨슈머는 특정 컨슈머 그룹에 속하며, 같은 그룹에 속한 컨슈머들은 토픽의 파티션을 분산 처리함

기본적으로 컨슈머는 스티키 파티셔닝(Sticky Partitioning)을 사용.
이는 특정 컨슈머가 특정 파티션에 붙어서 계속해서 데이터를 처리하는 방식으로, 데이터 지역성을 높여
캐시 히트율을 증가시키고 전반적인 처리 성능을 향상시킴.

5. 토픽

메시지를 저장하는 장소

6. 파티션

병렬 처리 및 고성능을 위해 하나의 토픽을 여러개로 나눔

파티션은 토픽을 물리적으로 나눈 단위로, 각 파티션은 독립적으로 메시지를 저장하고 관리

각 파티션은 메시지를 순서대로 저장하며, 파티션 내의 메시지는 고유한 오프셋으로 식별

파티션을 통해 데이터를 병렬로 처리할 수 있으며, 클러스터 내의 여러 브로커에 분산시켜 저장할 수 있다.

7. 세그먼트

프로듀서가 전송한 실제 메세지가 브로커의 로컬 디스크에 저장되는 파일

replication을 하면 토픽이 replication 되는게 아니라 토픽의 파티션이 replication 된다.

레플리케이션 팩터 수가 커지면 안정성은 높아지지만 리소스를 많이 사용하게 되므로

복제에 대한 오버헤드를 줄이고 최대한 브로커를 효율적으로 사용해야한다.

기준을 세우자면

테스트나 개발환경에서는 팩터 1

운영환경에서 약간의 유실이 허용되는 경우 팩터2

유실을 허용하지 않는 운영환경 팩터3

경험에 비춰보자면 팩터 3에서도 충분히 메세지 안정성을 보장하며, 디스크 공간을 효율적으로 사용할 수 있었다.

그래서 그 이상으로 올리는 것은 고려해봐야할 사항

파티션

하나의 토픽을 여러개로 나눠 병렬 처리가 가능하게 함

이렇게 하나를 여러개로 나누면 분산처리도 가능하며, 이렇게 나눈 파티션 수만큼 컨슈머를 연결할 수 있다.

파티션은 초기 생성 후에 얼마든지 늘릴 수 있지만, 늘린 파티션을 다시 줄일수는없다.

줄이는게 가능 할 경우 기존 파티션에 저장된 데이터를 새 파티션으로 이동해야 하고, 이때 데이터 순서와 파티션 키 무결성을 보장할 수 없기 때문에 제약을 걸어둔 것

줄이고 싶다면 기존 토픽 데이터를 새 토픽으로 이동하면서 새 토픽에서 파티션 수를 기존보다 적게 만들면 된다.

실전 카프카 개발부터 운영까지

넓고얕은사람 — Sun, 5 Jan 2025 04:34:35 +0900

프로젝트에 카프카를 적용해야하여 카프카를 학습하는 중이다.

강의와 서적 모두 학습 중인데 서적은 요약이 필요할 것 같아 대략적인 내용과 필요한 부분을 기록해 두려 한다.

다만 카프카 버전이 현재와 많이 차이나므로 대략적으로 참고만 하는 식으로 진행할 것이며,

사용 중단된 기능(Deprecated)에 대해서는 기록하지 않거나, 현재와의 차이점을 기록할 것이다.

1장. 카프카 개요

기업의 카프카 도입 사례와 카프카의 장점

아파치 카프카와 인플루언트 카프카의 차이

-> 아파치 카프카는 자동차의 엔진이라면
인플루언트 카프카는 각종 편의기능(네비게이션, 조향장치 등)이 모두 탑재된 완성된 자동차

Apache Kafka와 Confluent Kafka의 주요 차이점

기능	Apache Kafka	Confluent Kafka
배포	오픈소스, 직접 설정	상업적 배포, 기본 기능 포함 + 확장
운영 도구	직접 도구 설치 필요	Control Center 등 다양한 도구 제공
데이터 관리	Schema Registry 없음	Schema Registry 제공
커넥터	기본 커넥터만 제공	다수의 사전 빌드된 커넥터 제공
스트리밍 처리	Streams API 제공	Streams API + KSQL 지원
보안 및 인증	기본 보안 기능 제공	강화된 보안 옵션 제공
지원	커뮤니티 기반	상업적 지원 제공
비용	무료	커뮤니티 버전 무료, 엔터프라이즈 유료
클라우드 배포	별도 설정 필요	Confluent Cloud로 완전 관리형 제공

"이벤트 드리븐 시스템 구성에서 가장 중요한 사항은 인바운드 데이터와 아웃바운드 데이터가 동일해야한다."

카프카 장점

1. 빠른 데이터 수집이 가능한 높은 처리량

2. 순서 보장
이벤트 처리 순서가 보장되면서, 엔티티 간의 유효성 검사나 동시 수정 같은 복잡성 제거

3. 적어도 한번 전송

4. 카프카 클라이언트는 pull 방식으로 동작

pull은 자기자신의 속도로 데이터 처리 가능

push는 브로커가 보내주는 속도에 의존

5. 강력한 파티셔닝

이를 통해 수평확장 가능

카프카 주요 특징

1. 높은 처리량과 낮은 지연시간

-> 처리량은 카프가가 가장 높고, 응답속도만 보면 RabbitMQ가 가장 빠르지만, 둘 다 함께 고려할 경우 카프카가 압도적

2. 높은 확장성

-> 기초 설계부터 확장성 고려

3. 고가용성

-> replcation 기능

4. 내구성

람다 아키텍처?

데이터 처리 아키텍처 중 배치 파이프라인과 실시간 파이프라인이 있는 아키텍처

빅데이터를 처리하는 방식의 일종으로 하이브리드 방식으로 배치 처리나 스트림 처리를 이용할 수 있게 해준다.

빅데이터를 실시간으로 분석하기 어렵기 때문에 대용량 데이터와 실시간 데이터를 결합해서 사용

아키텍처는 3개의 계층 (Batch, Serving, Speed 레이어) 으로 이루어져있다.

실시간 및 배치 처리를 동시에 제공하여 대용량 데이터 처리를 가능하게 하지만

구현의 복잡성과 동일 로직을 각각 구현해야하는 코드의 중복이 있다. 그래서 디버깅이 어려움.

카파 아키텍처?

람다 아키텍처의 복잡성을 줄이기 위해 제안된 아키텍처로, 실시간 스트림 처리 중심으로 설계된 아키텍처이다.

단일 데이터 처리 파이프라인을 통해 모든 데이터를 실시간으로 처리한다.

모든 데이터를 실시간으로 처리하므로 배치 레이어가 필요하지 않다.

설계와 유지보수가 간단하다는 장점이 있고, 배치 레이어를 사용하지 않음으로 인해 중복구현이 필요없어졌다.

다만 모든 데이터를 스트림 처리 방식으로 처리하므로, 매우 큰 배치 작업에서는 성능이 떨어질 수 있다.

특징	람다 아키텍처	카파 아키텍처
구조	배치 레이어 + 실시간 레이어	단일 스트림 처리 레이어
복잡성	높음	낮음
중복 구현	있음	없음
재처리 지원	제한적	로그 시스템에서 재처리 가능
실시간 처리 능력	배치와 실시간 결합으로 처리	실시간 처리에 최적화
적용 사례	복잡한 데이터 처리 환경	스트림 중심의 실시간 처리 환경

"실제 운영 환경에서는 서비스의 안정성이 최우선이므로 단독 서버 형태로 운영하는 경우는 거의 없다."

-> 카프카 최소 3개 쓰자

동시성이 터졌다.

넓고얕은사람 — Sat, 14 Dec 2024 16:10:47 +0900

Row was updated or deleted by another transaction (or unsaved-value mapping was incorrect): 
[com.sparta.msa_exam.order.entity.Order#2]

아주 멋진 에러가 터졌다.

another transaction 바로 동시성 문제

바로 낙관적 락을 걸어주었다.

jpa:
  properties: 
    hibernate:   
      use_version_always: true
      
      
엔티티엔
@Version 추가

Detached entity with generated id '2' has an uninitialized version value 'null': 
com.sparta.msa_exam.order.entity.Order.version

뭐라는거야 왜 못가져오는데

그냥 flush를 명시적으로 해주었다.

entityManager.persist(order);
orderRepository.save(order);
orderRepository.flush();

이젠 그냥 막 NPE 에러가 뜬다

Cannot invoke "java.util.List.stream()" because the return value of 
"com.sparta.msa_exam.order.entity.Order.getOrderProductList()" is null

영속성에서 저장이 문제구나 하는 생각에

List<OrderProductDto> orderProductDtoList = 
		Optional.ofNullable(order.getOrderProductList())                
			.orElse(Collections.emptyList()).stream()        
			.map(orderProduct -> new OrderProductDto(
					orderProduct.getProductId(), 
					orderProduct.getQuantity().getQuantity())
					).toList();

@Transactional
    public CreateOrderResponseDto createOrder(Long userId, CreateOrderRequestDto requestDto) {
        Order order = Order.builder()
                .userId(userId)
                .orderProductList(new ArrayList<>())
                .build();

        order = orderRepository.saveAndFlush(order);    // 이게 답이었다.

마지막부분을 save 대신 saveAndFlush로 날리니 어찌 해결은 되었다.

그런데 또 이어서 에러가 터진다.

SimpleMessageConverter only supports String, byte[] and Serializable payloads, received:
com.sparta.msa_exam.order.event.OrderCreateEvent

SimpleMessageConverter는 String, byte[], Serializable 인터페이스를 구현한 객체만 지원한다.

그래서 해당 객체를 직렬화 해주면 된다.

또한 잭슨 컨터버를 추가하였다.

public class OrderCreateEvent implements Serializable {
    private Long orderId;
    private Long userId;
    private List<OrderProductDto> orderProductDtoList;
}

@Bean
    public RabbitTemplate rabbitTemplate(ConnectionFactory connectionFactory) {
        RabbitTemplate template = new RabbitTemplate(connectionFactory);
        template.setMessageConverter(jackson2JsonMessageConverter());
        return template;
    }

    @Bean
    public Jackson2JsonMessageConverter jackson2JsonMessageConverter() {
        return new Jackson2JsonMessageConverter();
    }

그러고 실행하니

{
    "orderId": 1,
    "userId": 1,
    "totalPrice": 0,
    "failedProductList": [
        1,
        2,
        3
    ]
}

실패에 담겼다.

주문 생성 실패 리스트에 담겼다.

for (Long productId : requestDto.getProductIdList()) {
            try {
                GetProductInfoResponseDto responseDto = productClient.getProductInfo(productId);
                OrderProduct orderProduct = new OrderProduct(order, productId, Price.of(responseDto.getPrice()), Quantity.of(responseDto.getQuantity()));
                order.addOrderProduct(orderProduct);
            } catch (CustomException e) {
                failedProductList.add(productId);
            }
        }

이는 역직렬화를 통해 해결하였다.

여기까지 완벽한 트러블슈팅이었으나,

애플리케이션 실행 시에 강제로 메세지큐가 실행되어 에러가 계속 발생하는 문제가 생겼다.

여러 시도 끝에 메세지큐에 남아있는 요청이 문제라는 것을 확인하였다.

그래서 메세지큐 도커 내부에서 메세지큐를 비워주었다.

"명령어"로

docker exec -it rabbitmq /bin/bash

rabbitmqctl purge_queue order.created.queue

exit

래빗MQ 웹으로 들어가는 관리자페이지는 default 아이디, 패스워드를 입력하니 권한이 없다고 한다.

그냥 잘 아는 도커로 해야겠다.

프로젝트 시작 - 대략적인 구상

넓고얕은사람 — Sat, 30 Nov 2024 18:17:31 +0900

문서로 제공된 요구사항 외에 내가 어떻게 구현해야할지에 대해 며칠을 고민했다.

거의 3일을 어떻게 해야할지에 대해 고민만 한 것 같다.

먼저 DB에 대한 고민

DB 분리 스키마 vs 테이블

MSA 환경에서 데이터베이스를 어떻게 할 지 고민 도커컴포즈로 mysql과 레디스를 묶어 사용하려 했다. 이 경우 레디스는 key-space를 도메인 별로 나누면 된다. 하지만 mysql은 각 도메인마다 독립적

like-it-too.tistory.com

어떻게 해야할지에 대해 고민했던 것 같다.

깃허브 레포 관리에 대한 고민

마이크로서비스 깃허브 관리방식

MSA 프로젝트를 하며 깃허브 레포지토리를 어떻게 관리해야할지많은 고민이 생겨 이것저것 알아보았다. 깃허브 관리 방식에는 3가지를 찾을 수 있었다. 1. 모노레포 (Monorepo)2. 서브모듈 (Submodule)

like-it-too.tistory.com

이건 쉽게 결정했는데 프로젝트의 git 설정이 생각보다 귀찮았다.

처음에 잘해뒀어야했는데 프로젝트 골조를 미리 다 만들고 init commit을 날리면 msa에선 대참사가 난다는걸 알아버렸다.

개빡치는 깃 - 하위 모듈 push rejected 해결?

결과 스포 프로젝트 전체 삭제 후 다시 만듦 하면 안되는 행동 목록 1. 모듈 remote 금지처음엔 main -> 이곳이 비어있어서 remote해줬는데 절대 이러면 안된다. 루트디렉토리만 push가 되

like-it-too.tistory.com

이제 개인적으로 넣어보려는 것들의 목록이다.

1. 유저 권한 user / admin

a. admin은 "주문 전체 조회" 와 "상품 정보 추가", "상품 정보 수정", "상품 정보 삭제" 기능을 가진다.

b. admin이 로그인 이후 권한이 변경 된 경우를 생각해서 서비스 쪽에서 한번 더 검증해줘야한다.

이를 어떻게 할지 고민했다.

권한은 무조건 게이트웨이 필터에서 검증하는 것이었고 추가검증을 서비스에서 각자 해결할지

auth를 타게할지에 대한 고민이었는데 auth를 타는것에 대해 나는 항상 부정적이었다.

auth를 타지않는다면

게이트웨이 - 주문 - 프로덕트로 깔끔하게 끝나는 반면

auth를 탄다면

게이트웨이 - 주문 - auth - 주문 - 프로덕트로 중간과정이 2개나 추가된다.

각 서비스가 통신을 통해 연결되기 때문에 과정이 길어진다는건 처리시간 증가 및 에러 발생확률 증가와

긴밀하게 연관된다고 생각하여 전자로 구현하기로 결정했다.

2. ddd 맛보기 (값 객체, 애그리거트, 4 레이어드 아키텍처)

msa에 ddd의 몇 가지 개념을 선별해서 적용해 보려했다.

ddd 를 접목하면 도메인의 경계를 명확히하여 각 서비스의 역할과 책임을 명확히 할 수 있다.

이는 서비스가 다른 서비스의 영향을 덜 받게되며 서비스의 독립성 강화로 이어질 수 있다고 보았다.

그래서 값객체와 애그리거트 2가지 개념을 사용해보기로 하였다.

값객체

각 서비스의 중요한 컬럼을 외부의 변경으로부터 막을 수 있다.

이를 통해 데이터 일관성을 유지할 수 있음.

현재 고려중인 부분은 유저 - 유저네임, 오더 - 주문 금액, 주문 상태, 프로덕트 - 상품 가격, 수량

정도에 적용할 것 같다.

애그리거트

관련된 데이터를 묶어 루트 애그리거트로만 접근하게 만들기 때문에

애그리거트를 통해 서비스 경계를 명확히 할 수 있다.

주문 - 주문금액 + 주문상품(id 제품명 수량 가격) + 주문 상태, 프로덕트 - id 제품명 가격 수량

으로 사용할 것 같다.

4 레이어드 아키텍처

이것도 고려해보았으나 지금 사용하는 패키지 구성과 비교했을 때 들인 시간에 비해 얻는 효율이 떨어질 것

같아 다른 곳에 투자하기로 하였다.

3. rabbitMQ 사용

오더 생성 시에만 적용해보기로 하였다.

주문 생성 -> 재고 감소 메세지

재고 부족 -> 주문 취소 메세지

4. 보상트랜잭션

오더 생성에만 적용해보기로 하였다.

재고 부족 -> 주문취소 메세지 일때 보상트랜잭션을 사용하여 주문 취소 처리를 하는 것까지를 목표로 설정하였다.

주문상태를 cancelled로 변경, 주문 데이터를 취소상태로 업데이트, 주문 관련 트랜잭션 롤백

할 수 있다면 낙관적락까지 하면 좋겠지만 구현하다보면 서킷브레이커까지 엮일 것 같아

관련 시간이 매우 많이 들 것 같았다.

그래서 일단은 패스하였다.

매우 화나는 깃 - 하위 모듈 push rejected 해결?

넓고얕은사람 — Fri, 29 Nov 2024 20:39:22 +0900

결과 스포

프로젝트 전체 삭제 후 다시 만듦

하면 안되는 행동 목록

1. 모듈 remote 금지

처음엔 main -> 이곳이 비어있어서 remote해줬는데 절대 이러면 안된다.

루트디렉토리만 push가 되고 하위 모듈들은 푸시를 거절당하게 된다.

나처럼 이런 실수를 저질렀다면 위와 같이 해당 디렉토리로 이동해 명령어를 실행하면된다.

인텔리제이 파워쉘 명령어이기 때문에 본인의 설정에 맞춰 진행하면 된다.

아무것도 안뜨면 성공한 것이다.

Get 하기 귀찮으면 폴더에서 .git 파일을 찾아보면 된다.

그 다음으로 진행한 해결방식들

대체 왜..

rebase로 양쪽을 맞춰보기도 했지만 결과는 같았다.

여전히 커밋만 되고 깃허브에 푸시는 안되는 상태

git status로 상태를 보니

order와 product에 대해 git 이 아직 추적을 하고 있지 않았다

2 add 생각없이 쓰기 금지

order와 product의 remote를 제거하고 (두번째 사진)

add 명령어를 날려 추적을 하도록 하였다.

그리고 푸시하니

???

너무 멋있어서 박수 쳐주고싶고

빡쳐서 모듈을 싹 다 지운 다음 다시 등록하였다.

이미 git init을 한 적이 있어서 깃이 이를 서브모듈로 인식한다고 한다.

더이상 참지 못했다

삭제

삭제 후엔 침착하게

유레카만 생성한 후 init commit을 날리고

order와 product 모듈을 생성 후 다시 .git을 삭제해주고 init commit을 날리니 끝이 났다.

인텔리제이 재실행시 매핑에 문제가 있다고하는데 무시하면 된다.

인텔리제이 말 믿고 건드렸다간 push를 gui로 할 수 없게 된다.

나도 알고 싶지 않았다.

DB 분리 스키마 vs 테이블

넓고얕은사람 — Thu, 28 Nov 2024 16:53:21 +0900

MSA 환경에서 데이터베이스를 어떻게 할 지 고민

도커컴포즈로 mysql과 레디스를 묶어 사용하려 했다.

이 경우 레디스는 key-space를 도메인 별로 나누면 된다.

하지만 mysql은 각 도메인마다 독립적인 데이터베이스를 가져야하는데 어떻게 구현해야하나 고민이 되었다.

방식은 두가지가 있다.

1. 각 도메인이 다른 스키마를 사용

2. 같은 스키마를 공유하되, 도메인 별로 테이블을 분리

1. 각 도메인이 다른 스키마를 사용

Order는 order_db, Product는 product_db, Auth는 auth_db

로 스키마를 분리할 수 있다.

이 경우 각 도메인은 url이 분리되어 각자 독립적인 db를 보유한 것처럼 사용할 수 있다.

jdbc:mysql://mysql:3306/product_db
jdbc:mysql://mysql:3306/order_db
jdbc:mysql://mysql:3306/auth_db

장점으로는 각 도메인이 물리적으로 다른 공간을 사용하기 때문에 충돌 가능성이 없으며,

데이터베이스 수준의 독립성을 가질 수 있다.

또한 개별 스키마를 사용하므로 권한 제어 및 데이터 관리가 쉽다.

문제 발생 시 해당 스키마만 백업 또는 복구 할 수 있기 때문에 문제 해결이 쉽다.

마지막으로 MSA 확장 시 물리적으로 DB를 분리하기 쉽다.

2. 같은 스키마를 공유하되, 도메인 별로 테이블을 분리

msa_example 이라는 스키마 아래에

product, order, auth 테이블이 존재한다.

이 경우엔 같은 도메인을 쓰고 내부에서 테이블이 독립적이다.

테이블끼리 직접 의존하지 않고 http 통신을 통해 데이터가 교환되기 때문에 논리적 독립성을 유지한다.

또한 구성이 쉬우며, 설정이 간편하다.

결론

도커를 사용하는 기준에서는 스키마분리가 더 쉽다고 생각한다.

도커컴포즈 yml에서 각 스키마를 작성해야하므로 코드가 길어진다는 것이 단점인데

yml파일을 단 한번만 작성하면 되므로 큰 문제는 아니라고 생각한다.

마이크로서비스 깃허브 관리방식

넓고얕은사람 — Thu, 28 Nov 2024 02:18:16 +0900

MSA 프로젝트를 하며 깃허브 레포지토리를 어떻게 관리해야할지

많은 고민이 생겨 이것저것 알아보았다.

깃허브 관리 방식에는 3가지를 찾을 수 있었다.

1. 모노레포 (Monorepo)

2. 서브모듈 (Submodule)

3. 다중 레포지토리 (Multi-repo)

각 방식에 대해 간략히 설명해보자면

1. 모노레포 (Monorepo)

모노레포란 하나의 깃 레포지토리에서 여러 프로젝트 또는 서비스를 통합 관리하는 방식

모든 서비스와 코드를 하나의 레포지토리에서 관리하는 것이 특징

장점

1. CICD 파이프라인 설정과 코드 공유가 쉽다.

2. 서비스 간 의존성 문제를 해결하기 쉽다.

3. 같은 레포지토리에서 작업하므로 변경사항 추적이 쉬우며, 협업이 쉽다.

4. 관련된 모든 변경사항을 한번의 커밋으로 관리할 수 있기 때문에 원자적으로 관리 가능하다. All or Nothing

단점

1. msa지만 각 서비스의 독립적을 강조하기가 어렵다.
특정 서비스만 배포하기 위해선 다른 관리방식보다 더 많은 설정이 필요하다.

2. 프로젝트가 커질수록 작업에 애로사항이 많다.

2. 서브모듈 (Submodule)

서브모듈은 하나의 깃 레포지토리에 다른 깃 레포지토리를 포함하여 관리할 수 있도록 한다.

이를 사용하여 프로젝트 내에서 특정 서비스를 별도의 깃 레포지토리로 관리하면서도 메인 프로젝트와 연동할 수 있다.

독립적인 저장소이므로 메인의 일부이지만, 별도의 커밋 히스토리와 브랜치를 가진다.

장점

1. 버전관리를 독립적으로 할 수 있다.

2. 공통 코드의 경우 여러 프로젝트에서 서브모듈로 추가하여 코드의 중복을 제거할 수 있다.

그래서 msa에서 dto, 유틸리티 메서드, 글로벌 예외처리로직을 별도의 저장소로 관리하고

각 서비스의 서브모듈로 사용할 수 있다.

3. 서브모듈만 독립적으로 빌드하고 배포할 수 있다.

단점

1. 서브모듈의 버전 동기화가 까다롭다.

메인 레포지토리에서 서브모듈의 버전을 명시적으로 업데이트 해주어야 한다.

2. 메인과 서브모듈 간 의존성이 생기면 두 레포지토리의 변경사항을 동시에 관리해야한다.

3. 서브모듈의 변경사항을 메인에 제때 반영하지않으면 버전차이가 발생할 수 있다.

4. 팀원들이 모두 서브모듈 사용법을 숙지하고 있어야한다.

5. 독립적으로 배포가능하다는 장점이 있으나, CICD 파이프라인 설정이 까다롭다.

3. 다중 레포지토리

각 프로젝트나 서비스를 독립된 깃 레포지토리로 관리하는 방식.

각 서비스가 완전한 독립성을 가질 수 있다.

장점

1. 완전히 독립적이기 때문에 다른 서비스의 영향을 받지 않고 개발 및 배포가 가능

2. 레포지토리의 크기가 작기 때문에 깃 속도가 빠름

3. 서비스 별로 CICD 파이프라인을 각각 설정할 수 있어 커스텀이 쉽다.

단점

1. 의존성 관리가 어렵다.

글로벌로 사용되는 공통 코드 관리에 추가적인 작업이 필요

2. 변경 사항 추적이 어렵다.

여러 레포지토리에 영향을 미치는 커밋의 경우 추적이 쉽지 않다.

세 방식을 알아보며 위와 같이 정리할 수 있었다.

현재 프로젝트는 규모가 크지 않으며, MSA에 대한 이해도가 낮으므로

모노레포가 가장 적합하다고 생각한다.

서브모듈의 경우 혼자서는 학습 후 적용할 수 있지만, 팀의 모든 인원이 서브모듈에 대한 이해도가 필요하기 때문에 힘들 것 같고

다중 레포지토리는 서비스의 규모가 작기 때문에 적용하기엔 과하다고 생각한다.

결국 모노레포

Commit Count 확장 - 로그(TIL) 카운트 EventListener Error

넓고얕은사람 — Tue, 26 Nov 2024 18:46:51 +0900

커밋카운트 로직을 바탕으로 알고리즘 카운트, 로그(TIL) 카운트 를 만들었다.

    @EventListener
    @Async
    public void handleLogSubmitEvent(LogSubmitEvent event) {
        logCountService.updateLogCountOnSubmit(event.getUserId());
    }
}

이 곳에는 비동기를 적용하여

사용자가 제출한 이후 카운트를 따로 처리하게 함으로써 제출 이후 바로 다른 작업을 할 수 있도록 하였다.

테스트코드를 작성하여 간단히 로그 제출 -> 제출하며 카운트 이벤트 호출 로직으로 구성하였다.

하지만 테스트에서 문제가 발생하였고, 비동기가 제대로 적용되지 않은것이라 생각해

 Awaitility.await()
                .atMost(5, TimeUnit.SECONDS)
                .untilAsserted(() ->

여기에 5초를 주고 다음엔 30초씩 줘가며 확인을 하였지만 실패하였고,

트랜잭션이 제대로 돌아가지 않는게 문제인가 해서 트랜잭션을 삭제하고 afterEach로 레포지토리를 비워주었다.

이때 테스트는 성공하였으나 테스트 내부에서 에러가 발생하였고,

깔끔한 테스트 성공을 위해 testConfig를 하나 더 만들어서 적용하였다.

org.springframework.transaction.UnexpectedRollbackException: 
Transaction silently rolled back because it has been marked as rollback-only

테스트 코드에서 트랜잭션을 없앴지만 서비스코드에 남아있어서 이런 에러가 발생한다고 판단하였고,

@Transactional(propagation = Propagation.REQUIRES_NEW)

public void updateLogCountOnSubmit(Long userId)

트랜잭션의 전파 속성을 변경해보았지만 결과는 같았다.

그래서 다시 일반 트랜잭션으로 되돌리고

    @EventListener
    @Async
    public void handleLogSubmitEvent(LogSubmitEvent event) {
        logCountService.updateLogCountOnSubmit(event.getUserId());
    }
}

    @TransactionalEventListener
    @Async
    public void handleLogSubmitEvent(LogSubmitEvent event) {
        logCountService.updateLogCountOnSubmit(event.getUserId());
    }
}

이벤트에서 이벤트리스너를 트랜잭션이벤트리스너로 변경하였다.

로직 상 제출이 완료 된 후 카운트를 체크하는 것이 맞기에 제출 트랜잭션이 끝난 후 카운트 트랜잭션이 실행되도록

하나의 트랜잭션을 두 개로 분리하였다.

기존에는 submitLog 테스트는 성공했으나

Log saveLog = logRepository.findByAddressAndUserId(submitLogDto.getAddress(), user.getId())
.orElseThrow(() -> new AssertionError("로그 못찾음"));

이 에러가 계속 발생하였다.

그래서 비동기쪽 문제라고 생각하여 이것저것 건드려보았는데 이벤트 관련 트랜잭션을 나누는 것이 정답이었다.

요약

처음에는 @Async와 @EventListener 를 조합해서 이벤트리스너가 비동기적으로 동작하도록 설정했는데

이렇게하면 로그 제출작업이 완료되기 전에 로그 카운트 증가작업이 시작될 수 있었다.

그래서 로그 제출 트랜잭션이 아직 완료되지 않아 DB에 저장되지 않은 상태에서 이벤트가 실행될 경우

카운트 증가를 위해 로그를 조회할 때 해당로그를 찾기 못했던 것이었다.

그래서 애너테이션을 변경하여 제출 트랜잭션이 커밋된 이후에 실행되도록 하였고,

이를 통해 로그가 성공적으로 제출된 이후에 이벤트 리스너가 실행되므로 계속해서 발생하던 에러를 해결할 수 있었다.

이 성공 이후 위의 config를 삭제한 후 실행했음에도 문제가 발생하지 않았고, 성공적으로 실행되는 것으로 보아

트랜잭션 분리가 답이었다.

비동기 이벤트 처리와 트랜잭션 타이밍이 불일치하는 것이 원인이었고,

애너테이션 변경을 통해 이벤트 실행 시점을 트랜잭션 완료 후로 조정하여 문제를 해결하였다.