[Spring] 분산 시스템에서 효과적인 데이터 전달 방법 (1) - RDB

최근 많은 기업들이 분산 시스템으로 서버를 구축하고 있고, 나 또한 분산 시스템에 관심이 많다.

 

이번엔 분산 시스템 속에서, 각 컴포넌트들 사이에 어떻게 정보를 효과적으로 전달하는 것이 좋을지 공부해보겠다.

 

0.  분산시스템이란?

분산 시스템은 여러 개의 컴퓨터 리소스를 사용하여 두 개 이상의 컴포넌트로 구성되어 있는 시스템이다.

 

각 컴포넌트들은 하나의 기능을 수행한다.

 

크게 세 가지 유형이 있을 수 있다.

• 엔터프라이즈 애플리케이션 Enterprise-application
• 마이크로 서비스 아키텍쳐 애플리케이션 MSA(Micro Service Architecture)
• 모놀리식 아키텍쳐 애플리케이션 + 검색엔진  Monolithic Architecture + Search Engine

 

1. 데이터 전달 방법

그렇다면 이 분산 시스템에서, 각 컴포넌트들의 데이터 전달하는 방법은 어떤 방식이 있을까.

 

 

1-1. Remote API

최근 개발하는 방법 중 가장 친숙한 방법이다.

 

서버-클라이언트 구조로 이루어져 있고, 서버는 CRUD API를 제공한다.

 

 

1-2. Message Queue

Publisher-Consumer구조로 이루어져 있다.

 

Publisher가 Message Queue에 데이터를 전송하고, Consumer가 해당 데이터를 받아서 데이터를 처리한다.

 

보통 배치 작업, 비동기 작업에서 주로 사용한다.

 

최근 공부했던 kafka가 이에 해당한다.

 

 

1-3. 효율적으로 전달하는 방법

분산 시스템의 각 컴포넌트들은 네트워크로 연결되어있기 때문에, 아래 상황들을 고려해야 한다.

• 패킷 손실 Packet Loss
• 네트워크 지연 Latency
• 네트워크 다운 Network Down

중요한 시스템일 수록, 항상 데이터나 서버에 장애가 생겼을 때를 대비해야 한다.

 

---

데이터 전달 방법론

1. At-most-once Delivery (최대 한 번 전달)

 

신뢰성이 가장 낮은 전달 방법이다.

Producer는 최대 한 번만 메세지를 전달하고, 메세지를 받지 못했는지 확인하지 않는다.

 

간단한 구조로 이루어져 있어 대규모 데이터를 처리하기 쉽지만 메세지 유실을 유발할 수 있다.

 

2. At-least-once Delivery (최소 한 번 전달)

 

Producer는 최소 한 번 메세지를 전달하고, Consumer는 최소 한 번 메세지를 수신한다.

 

네트워크 패킷에서 사용하는 것 처럼, ACK(Acknowledgement)를 이용하여 Consumer가 데이터를 수신했다는 정보를 공유한다.

 

3. Exactly-once Delivery (정확히 한 번 전달)

 

가장 이상적인 환경으로, 메세지를 정확하게 한 번만 전달하는 것이다.

 

누락과 중복이 없는 만큼, 시스템의 개발 난이도가 높다.

 

Producer, Message Queue, Consumer 모든 상태를 관리해야 한다.

 

---

 

해당 방법 중에서, 데이터의 중요도에 따라 어떤 방식을 선택하는지에 따라 애플리케이션의 신뢰성이 증가한다.

 

 

 

 

 

 

 

2. RDB를 사용하는 애플리케이션에서 전달 방법

 

2-1. 서비스별 데이터베이스 패턴 (Database per Service Pattern)

 

https://medium.com/design-microservices-architecture-with-patterns/the-database-per-service-pattern-9d511b882425

MSA구조에서 가장 일반적으로 사용하는 패턴이다.

 

각 서비스들이 각 독립된 DB를 갖고있고, 서비스별로 DB트랜잭션이 발생한다.

 

 

여기서, 문제점이 발생할 수 있는데, 아래 예시를 보자.

 

아래 코드는 트랜잭션이 발생하는 코드의 예이다.

@Service
public class CreateTaskService implments CreateTaskUserCase {

    @Transactional
    public CreateTaskResponse createTask(CreateTaksCommand createTaksCommand) {
    
    	Task task = createTaskCommand.toTask();
        taskRepository.save(task); // Save task Entity
        eventHandler.propagate(CreateTaskEvent.of(task)); // REST-API (To Another Component)
        return CreateTaskResponse.of(task);
    }
}

 

Task의 Entity를 DB에 저장하고, MSA구조 내에 다른 컴포넌트에게 REST API 호출을 하는 구조이다.

 

Spring의 Transactional 어노테이션은 AOP를 생성하여 Proxy객체를 생성한다.

즉, 아래 세 가지 단계로 실행이 된다.

 

데이터 저장 → 이벤트 전달 → 트랜잭션 커밋 (혹은 Rollback)

 

만약, DB트랜잭션 과정 중에 Exception이 발생하여 DB가 롤백 됐다면,

DB에 데이터가 없는데 API호출이 이루어지는 것이다.

 

해결하는 방법은 다음과 같다.

 

 

 

1.  트랜잭션 Commit 이벤트 사용

• @TransactionalEventListner + @Retryable

Spring 프레임워크가 제공하는 이벤트를 이용하는 방법이다.

 

@Service
public class EventHandler {

    @Retryable(maxAttempts = 3, backoff = @Backoff(delay = 100L))
    @TransactionalEventListener(phase = TransactionPhase.AFTER_COMMIT)
    public void propagate(CreateTaskEvent event) {
        //이벤트 발생 로직
        System.out.println("이벤트 발생");
        // restTemplate.execute(...);
        // rabbitTemplate.send(...);
    }
}

 

REST API나 Message Queue를 이용하여 다른 컴포넌트에게 데이터를 전달하는 경우,

 

TransactionalEventListener를 propagate에게 적용시킨다.

 

 

어노테이션 옵션은 다음과 같다.

• @TransactionalEventHandler(phase = TransactionPhase.AFTER_COMMIT)
  • deafult값이다. 트랜잭션이 commit될 때 이벤트를 실행한다.
• @TransactionalEventHandler(phase = TransactionPhase.ROLLBACK)
  • 트랜잭션이 rollback될 때 이벤트를 실행한다.
• @TransactionalEventHandler(phase = TransactionPhase.AFTER_COMPLETION)
  • 트랜잭션이 completion( commit 또는 rollback)될 때 이벤트를 실행한다.
• @TransactionalEventHandler(phase = TransactionPhase.BEFORE_COMMIT)
  • 트랜잭션이 commit되기 전 이벤트를 실행한다.

네 어노테이션을 모두 실행시키면, 순서는 다음과 같이 실행된다.

 

- 트랜잭션 성공 시

"BEFORE_COMMIT" → "AFTER_COMMIT" → "AFTER_COMPLETION"

 

- 트랜잭션 실패 시

"ROLLBACK" → "AFTER_COMPLETION"

 

 

여기까지 환경을 구축했다면, DB트랜잭션 → REST API 순서가 보장된다.

 

하지만, DB트랜잭션을 성공했지만 REST API가 실패할 수 있다.

그렇기 때문에 어노테이션 @Retryable을 사용한다.

@Retryable(
    maxAttempts = 3, 
    backoff = @Backoff(delay = 100L)
)

 

위 옵션은 최대 3번 다시 시도하고, backoff delay를 100으로 설정해둔 값이다.

 

 

 

 

 

 

 

하지만 만약 재시도도 모두 실패한다면, MSA구조에서 다음 패턴을 시도할 수 있겠다.

 

 

2. Transaction Outbox Pattern & Polling Publisher Pattern

 

- Transaction Outbox Pattern

Transaction Outbox Pattern

 

RDB를 Message Queue로 이용하는 패턴이다.

 

즉, 한 트랜잭션에 이벤트나 메세지가 발생하면 RDB에 저장한다.

 

RDB에는 ["이벤트", "데이터"]가 저장되겠다.

 

이 패턴을 이용한다면 이벤트, 트랜잭션 모두 성공하거나 롤백을 하겠다.

 

여기서 Publish는 Polling Publisher 패턴을 이용한다.

 

 

 

 

- Polling Publisher Pattern

Polling Publisher Pattern

이 패턴은 Publisher가 주기적으로 DB 레코드를 조회하여 Publish할 메세지를 Polling하여 Publish하는 방식이다.

 

최종적으로 다음과 같은 패턴이 완성된다.

 

Transaction Outobx + Polling Publisher

 

1. 데이터와 이벤트가 한 트랜잭션 내에 실행된다.

2. 데이터 + 이벤트가 DB에 저장된다.

3. Polling Publisher가 DB를 주기적으로 조회한다.

4. DB에 Publish 할 메세지가 조회되면, 메세지를 전달한다.

 

코드는 다음과 같이 완성된다.

 

- Service

@Service
public class CreateTaskService {

    @Transactional
    public CreateTaskResponse createTask(CreateTaskCommand createTaskCommand) {

        Task task = createTaskCommand.toTask();
        taskRepository.save(task); // Save task Entity
        eventRepository.save(CreateTaskEvent.of(task)); // Save Event
        return CreateTaskResponse.of(task);
    }

}

 

 

- Publihser

@Service
public class MessagePublisher {

    @Scheduled(cron = "0/5 * * * * *")
    @Transactional
    public void publish() {

        LocalDateTime now = LocalDateTime.now();
        eventRepository.findByCreatedAtBefore(now, EventStatus.READY)
                .stream()
                .map(event -> restTemplate.execute(event))
                .map(event -> event.done())
                .forEach(eventRepository::save);

    }
}

 

해당 Publisher는 어노테이션 @Scheduled를 이용해서 5초마다 Publsih를 한다.

 

 

1. Ready 상태인 Event를 모두 조회하고, RestTemplate을 이용하여 Event를 발행한다.

2. 정상적으로 발행된 이벤트는 Done으로 바꾼다.

3. 이벤트를 다시 저장한다.

 

이 모든 행동은 한 트랜잭션 내에 있기 때문에 RestTemplate, DB저장 등 어떤 행동에 Exception이 일어나면 DB 롤백이 일어나기 때문에 안전하게 데이터를 처리할 수 있다.

 

 

 

아래는 DB에 저장될 레코드의 테이블에 필요할 내용들이다.

필드명	데이터 타입	설명
event_id	BIGINT	이벤트 순서 보장
created_at	Datetime	이벤트 발생 시간
status	smallint	Ready(0) / Done(1)
payload	jsonb	JSON 타입의 Message payload
...	...	...

 

 

 

 

 

장점

• REST API 환경에서 At-least-once를 구현할 수 있다.

단점

• Polling, Publisher 과정에서 지연 처리가 발생한다.
• 데이터베이스에 부하가 발생할 수 있다.
• 데이터 베이스에 비례한 처리속도가 발생한다.

지연 처리가 발생하고, DB성능에 따라 처리속도가 달라지기 때문에 실시간성이 필요한 데이터는 고려해볼 필요가 있겠다.

 

해당 코드는 깃허브에 구현해 놓았다. 

https://github.com/DDonghyeo/EffectiveDataTransfer

내용이 길어져서 추가로 RabbitMQ, Kafka는 다음 포스팅때 다뤄보도록 하겠다.

 

참고 / 출처
https://medium.com/design-microservices-architecture-with-patterns/the-database-per-service-pattern-9d511b882425
https://www.youtube.com/watch?v=uk5fRLUsBfk&ab_channel=NHNCloud
https://docs.spring.io/spring-framework/docs/current/javadoc-api/org/springframework/transaction/event/TransactionalEventListener.html
https://microservices.io/patterns/data/transactional-outbox.html
https://microservices.io/patterns/data/polling-publisher.html
https://www.up-2date.com/post/transactional-messaging-polling-publisher
https://medium.com/batc/outbox-polling-reliable-message-broker-publisher-61f46ae65cdd