백번 열번

Retry Jitter

100win10 — Sun, 4 Aug 2024 15:46:17 +0900

Retry 메커니즘에서 'jitter'는 반복적인 재시도 간의 시간을 조정하기 위해 사용되는 기법이다. 이는 주로 네트워크 요청이나 분산 시스템에서 실패한 요청을 다시 시도할 때 사용된다. 기본적으로, 재시도 메커니즘은 일정한 지연 시간 후에 요청을 다시 시도한다. 그러나 모든 클라이언트가 동일한 간격으로 재시도하면, 서버에 일시에 많은 요청이 집중되어 과부하가 발생할 수 있다.

이를 방지하기 위해 'jitter'를 사용하여 지연 시간을 무작위로 변동시킨다. 이는 각 클라이언트의 재시도 시간을 약간 다르게 만들어 서버에 대한 요청이 분산되도록 한다.

import reactor.util.retry.Retry;
import java.time.Duration;

// 예시 WebClient 설정
WebClient client = WebClient.create();

client.get()
    .uri("http://test.com")
    .retrieve()
    .bodyToMono(String.class)
    .retryWhen(Retry.backoff(2, Duration.ofSeconds(1)).jitter(0.1))
    ...

WebFlux에서 Retry.backoff(2, Duration.ofSeconds(1)).jitter(0.1)와 같이 설정된 부분에서 0.1은 Jitter를 추가하는 정도를 나타내는데 이 값은 백오프(backoff) 지연 시간에 대해 무작위 변동을 도입하는 비율이다.

Retry.backoff(2, Duration.ofSeconds(1)): 최대 2번 재시도하며, 각 재시도 간에 1초의 지연 시간을 두는 백오프 전략을 설정한다.
.jitter(0.1): 지연 시간에 대해 ±10%의 무작위 변동을 추가한다.

예)

1초 지연 시간을 기준으로 ±10%의 jitter를 적용하면, 지연 시간은 다음과 같이 변동될 수 있습다.

최소 지연 시간: 0.9초 (1초 - 10%)
최대 지연 시간: 1.1초 (1초 + 10%)

즉, 각 재시도 시 지연 시간은 0.9초에서 1.1초 사이의 랜덤한 값이 된다. 이렇게 하면 모든 클라이언트가 동일한 시간에 재시도하지 않도록 하여 서버에 과부하가 걸리는 것을 방지할 수 있다. 위 코드에서 retryWhen 연산자는 최대 2번 재시도하며, 각 재시도 간에는 0.9초에서 1.1초 사이의 랜덤한 지연 시간을 갖는다. 이렇게 하면 재시도 시점이 분산되어 서버에 과부하가 걸리는 것을 예방할 수 있다.

반복적인 lua script를 사용한다면 EVAL 대신 EVALSHA 로

100win10 — Sun, 4 Aug 2024 15:43:18 +0900

EVAL과 EVALSHA는 Redis에서 Lua 스크립트를 실행하는 명령어로, 둘 다 Lua 스크립트를 사용하여 복잡한 로직을 Redis 서버 측에서 실행할 수 있게 해준다.

EVAL vs. EVALSHA 비교

EVAL (Evaluate):
- EVAL은 Lua 스크립트를 처음부터 Redis 서버로 보내고 실행한다.
- Redis는 EVAL로 받은 스크립트를 실행하기 전에 해당 스크립트를 해시화하고, 캐시에 저장한다.
- 매번 스크립트를 Redis 서버에 전달하고 컴파일해야 하므로 네트워크 및 CPU 리소스가 더 많이 소모된다.
EVALSHA (Evaluate SHA-1):
- EVALSHA는 이미 Redis 서버에 로드된 Lua 스크립트의 해시(SHA-1) 값을 사용하여 스크립트를 실행한다.
- EVALSHA는 스크립트의 해시를 사용하여 스크립트를 다시 전달하지 않으므로 네트워크 오버헤드가 줄어든다.
- 스크립트의 해시값으로 요청을 보내기 때문에 Redis 서버는 이미 컴파일된 스크립트를 찾아 즉시 실행한다.
- 스크립트를 매번 컴파일할 필요가 없기 때문에 CPU 사용량이 적어지고 성능이 개선된다.

성능과 CPU 측면에서의 차이점

네트워크 효율성:
- EVAL은 스크립트를 매번 서버에 전달하므로 네트워크 트래픽이 증가한다.
- EVALSHA는 SHA-1 해시값만 전달하므로 네트워크 오버헤드가 크게 줄어든다.
CPU 효율성:
- EVAL은 매번 스크립트를 파싱하고 컴파일해야 하므로 CPU 리소스를 더 많이 사용한다.
- EVALSHA는 이미 컴파일된 스크립트를 실행하므로 CPU 사용량이 낮.
속도 개선:
- EVALSHA는 기존의 컴파일된 스크립트를 재사용하므로 실행 속도가 EVAL에 비해 더 빠르다. 이 차이는 특히 반복적인 Lua 스크립트 실행에서 두드러진다.
캐시 효과:
- EVALSHA는 Redis 서버의 스크립트 캐시를 적극 활용하므로 동일한 스크립트를 여러 번 실행할 때 성능 향상이 크다.

반복적으로 동일한 Lua 스크립트를 실행해야 하는 상황에서는 EVALSHA가 훨씬 더 효율적이라고 볼 수 있을 것 같다. EVALSHA를 사용하면 스크립트를 처음 한 번만 로드하고, 이후에는 해당 스크립트의 SHA-1 해시값만 사용하여 실행하기 때문에 네트워크 트래픽이 줄고 CPU 리소스도 절약할 수 있다.

logback 사용시 대용량 배치 작업에서 성능 저하를 유발할 수도!

100win10 — Sun, 14 Jul 2024 15:13:12 +0900

성능테스트를 어느정도 마친 배치 서비스에서 코드를 리펙터링하고 로그 포맷을 정리하여 배치 task 를 실행시켰을때 기존 테스트때보다 2배 정도 걸리는 것을 확인하였다. 어떤 부분이 영향을 미쳤을까 하나씩 확인해보던 중 logback.xml 을 설정을 다음과 같이 추가한 부분에 영향이 미침을 확인하였다.

<?xml version="1.0" encoding="UTF-8"?>
<configuration>

	...
    <springProfile name="prod">
        <include resource=".../tracer-console-appender.xml" />

        <logger name="CUSTOM_LOG" level="INFO">
            <appender-ref ref="CUSTOM_CONSOLE" />
        </logger>
        <logger name="CUSTOM_ERROR_LOG" level="ERROR">
            <appender-ref ref="CUSTOM_CONSOLE" />
        </logger>
    </springProfile>

</configuration>

다음과 같이 로그백 설정을 주어 INFO 나 ERROR 상태에 있는 로그를 콘솔로 출력하고 kibana 를 통해서 JSON 형태의 로그를 확인할 수 있도록 하였는데 INFO 수준에 레벨을 처리하는 CUSTOM_LOG 가 문제였다. 배치는 청크단위로 reader-processor-writer 로 처리되는데 INFO 수준에서 실제로 남기는 로그는 없었기에 이부분에 문제일 거라 생각하지 못했다.

그런데 실제로 콘솔에 출력되는 로그가 없다 하더라도, INFO 레벨로 로그 설정이 되어 있으면 성능에 영향을 미칠 가능성이 있다는 것을 확인했다. 그 이유는 로그백(Logback)이 내부적으로 로그 레벨에 맞는 로그 메시지를 평가하고 필터링하는 과정에서 리소스를 사용하기 때문이다. 이 과정이 누적되면 특히 대용량 배치 작업에서 성능 저하를 유발할 수 있다. 몇 가지 성능 저하를 유발할 수 있는 이유는 다음과 같다.

로그 메시지 생성 과정: 로그 메시지를 기록할 때, 로그 레벨이 일치하지 않아 실제로 출력되지 않더라도, 메시지 자체를 만들기 위해 문자열 연산 및 로그 처리 작업이 발생한다. 특히 로그 메시지에 많은 정보가 포함될수록 이 연산의 비용이 커질 수 있다.
필터링 및 레벨 평가: 로그백은 로그가 출력되기 전에 현재 로그 레벨이 설정된 레벨에 맞는지 평가한다. 이 평가 작업도 성능 부하가 될 수 있다. 특히 많은 양의 로그가 기록될 경우, 필터링 비용이 쌓일 수 있다.
동시성 및 스레드 관리: 많은 병렬 작업이 로그를 남기려 할 때, 콘솔 출력을 하지 않더라도 내부적으로 스레드와 자원 관리에 비용이 발생할 수 있다. 이 때문에 병렬 작업에서 성능 저하가 발생할 수 있다.

INFO 레벨의 로거가 설정된 상태에서 성능이 영향을 받을 가능성이 있는 이유는 이 과정들이 반복되기 때문. 따라서, 실제로 로그를 콘솔에 출력하지 않더라도 불필요한 INFO 레벨의 로거가 설정되어 있으면 성능에 영향을 미칠 수 있을 것 같다.

scdf 배치 task 실행시 볼륨과 함께 initContainer 실행시키기

100win10 — Sun, 14 Jul 2024 14:36:42 +0900

Spring Cloud Data Flow(SCDF)는 배치 작업과 스트리밍 작업을 관리하고 실행할 수 있는 플랫폼이다. 이 중 배치 작업(Task)을 실행할 때, 경우에 따라 특정 작업이 실행되기 전에 미리 설정해야 할 작업이 있을 수 있다. 이를 위해 Kubernetes 환경에서는 initContainer와 함께 필요한 볼륨을 설정하여 작업을 준비할 수 있다.

배치 작업에서 볼륨과 initContainer 사용하기

배치 작업에서 볼륨을 사용하여 데이터를 저장하거나 공유하고, initContainer를 이용해 그 데이터를 미리 세팅할 수 있다. 예를 들어, 배치 작업이 실행되기 전에 로그 파일을 생성하거나, 모니터링을 위한 환경을 준비하는 데 활용할 수 있다.

다음은 Spring Cloud Data Flow에서 배치 Task를 실행할 때, 볼륨과 함께 initContainer를 설정하는 예시이다.

1. scdf helm values 파일 수정하여 Task가 실행되는 동안 사용할 임시 볼륨을 설정한다. emptyDir 볼륨은 Pod가 실행되는 동안에만 존재하며, Pod가 종료되면 해당 볼륨도 함께 삭제된다. Task가 일시적으로 데이터를 저장하거나 공유할 때 적합하다.

deployer:
  volumeMounts:
    - name: share-vol
      mountPath: /share-vol
  volumes:
    - name: share-vol
      emptyDir:
        medium: ""
        sizeLimit: "500Mi"

2. initContainer 설정

- dataflow launch 시에 properties 값 추가

  val properties = mapOf(
            "deployer.${taskName}.kubernetes.initContainer" to INIT_CONTAINER_PROPERTY
        )

        return dataflowTaskClient.launchV2(taskName, properties, arguments)
        ..
        

        const val INIT_CONTAINER_PROPERTY = """
        {
            "containerName": "test-container",
            "environmentVariables": ['TEST=test'],
            "imageName": "imageName: 'busybox:latest",
            "volumeMounts": [
                {
                    "name": "share-vol",
                    "mountPath": "/share-vol"
                }
            ]
        }
        
    """

https://docs.spring.io/spring-cloud-dataflow/docs/current/reference/htmlsingle/#_init_containers

Spring Cloud Data Flow Reference Guide

You can also tap into various task and batch events when the task is launched. If the task is enabled to generate task or batch events (with the additional dependencies of spring-cloud-task-stream and, in the case of Kafka as the binder, spring-cloud-strea

docs.spring.io

Transactional Outbox Pattern

100win10 — Sun, 7 Jul 2024 20:45:18 +0900

Transactional Outbox 패턴은 데이터베이스와 메시지 브로커 간의 데이터 일관성을 유지하기 위해 사용된다. 핵심 아이디어는 트랜잭션 내에서 데이터베이스에 변경 사항을 기록할 때, 동시에 "아웃박스" 테이블에 메시지(또는 이벤트)를 기록하는 것이다. 그런 다음, 별도의 프로세스가 이 아웃박스 테이블에서 메시지를 가져와 메시지 브로커에 전송하게 된다.

이 패턴을 사용하면 데이터베이스와 메시지 브로커 간의 일관성을 유지하면서도, 트랜잭션을 통해 데이터의 원자성을 보장할 수 있다.

이 방식은 데이터 손실을 방지하고 시스템의 신뢰성을 높이는 데 유용하다.

기존에 트랜잭션 내에서 메시지 브로커로 메시지를 먼저 보내고 데이터베이스에 커밋을 하는 방식에서는, 메시지가 먼저 전송되고 나서 데이터베이스 커밋이 실패하면, 메시지는 이미 브로커로 전송되었기 때문에 롤백이 불가능해지는 문제가 발생한다. 이로 인해 데이터 일관성에 문제가 생길 수 있다.

트랜잭셔널 아웃박스 패턴은 이 문제를 해결하기 위해, 트랜잭션 내에서 메시지를 직접 브로커로 보내는 대신, 메시지를 아웃박스 테이블에 기록하는 방식으로 처리한다. 데이터베이스에 커밋이 성공하면, 그 후에 별도의 프로세스가 아웃박스 테이블에서 메시지를 읽어 브로커로 전송하게 된다. 이렇게 하면 데이터베이스 커밋과 메시지 전송 간의 일관성을 유지할 수 있다.

따라서, 아웃박스 테이블에 메시지가 기록되고 데이터베이스 커밋이 성공적으로 이루어졌다면, 그 이후에만 메시지가 브로커로 전송되므로, 롤백 상황에서도 데이터의 일관성이 보장된다.

이 패턴을 사용하면, 데이터베이스 커밋과 메시지 전송은 분리되지만, 데이터 커밋과 메세지 전송에 대한 커밋 모두 데이터베이스를 이용하기 때문에 하나의 트랜잭션에 대한 일관성을 유지할 수 있으며 메세지 전송에 대한 테이블에 row 가 삭제될때까지 재시도할 수 있기 때문에 신뢰성을 보장할 수 있다.

데이터 베이스를 먼저 커밋한다면?

단순히 순서를 바꾸는 방법으로는 문제가 있다.

메시지 전송을 데이터베이스 커밋 뒤에 두면, 메시지 전송 과정에서 네트워크 문제나 메시지 브로커 자체의 문제로 인해 실패할 가능성이 있 . 이 경우 데이터베이스에는 커밋이 완료되었지만 메시지가 전달되지 않아서 시스템 간의 일관성 문제가 생길 수 있다. 다시 말해, 수신자는 메시지를 받지 못했는데 데이터베이스에는 성공적으로 처리된 데이터가 남아있는 상황이 발생할 수 있다.

즉 순서만 바꾸는 것은 일관성 문제를 완전히 해결하지 못한다. 메시지 전송이 실패하거나 네트워크 문제가 생길 수 있기 때문. 반면, Transactional Outbox Pattern은 데이터베이스 커밋과 메시지 전송을 안전하게 분리해주고, 메시지 전송 실패 시에도 데이터를 잃지 않도록 도와준다.

메세지가 at least once 를 보장한다면?

기본적으로 at least once 메시징을 보장한다면 트랜잭셔널 아웃박스 패턴을 구현하지 않아도 될 수 있을 것 같은데 이 방식에도 몇 가지 고려해야 할 점이 있다. at least once 메시징은 메시지가 적어도 한 번 이상 전송됨을 보장하는 방식이다. 만약 메시지 전송 중에 실패하면, 메시지를 재전송하여 브로커가 메시지를 결국 수신하게 된다. 이 방식의 장점은 메시지 손실을 최소화할 수 있다는 점이다. 하지만 at least once 메시징에는 다음과 같은 단점도 있다

중복 메시지 처리 필요: 메시지가 재전송되는 과정에서 브로커가 동일한 메시지를 여러 번 수신할 수 있다. 이를 처리하려면, 수신 측(혹은 메시지 소비자)이 중복 메시지를 감지하고 적절히 처리해야 한다.
복잡성 증가: 메시지를 재전송하는 로직이나 중복 메시지를 감지하는 로직을 추가로 구현해야 하므로, 시스템의 복잡성이 증가할 수 있다.

트랜잭셔널 아웃박스 패턴은 데이터베이스와 메시징 시스템 간의 일관성을 유지하는 데 중점을 두기 때문에, 시스템이 특정한 비즈니스 요구사항을 가지고 있을 때 적합하다. 반면, at least once 메시징은 일관성보다는 메시지 손실을 피하는 데 더 초점을 맞춘 접근법. 따라서, 시스템 요구사항에 따라 트랜잭셔널 아웃박스 패턴을 사용할지, 아니면 at least once 메시징으로 충분할지 결정해야 한다. 둘 다 상황에 따라 유용할 수 있지만, 목표로 하는 일관성 수준과 메시지 전달 보장을 고려해 선택하는 것이 중요할 듯 하다.

Trasnactional outbox pattern

Outbox 테이블:
- 트랜잭션이 발생할 때, 변경된 데이터를 직접 다른 서비스에 전송하지 않고, 변경 내용을 별도의 Outbox 테이블에 기록한다. 이 테이블은 같은 데이터베이스 트랜잭션 내에서 업데이트된다.
폴링(Polling) 프로세스:
- 백그라운드 작업이나 별도의 서비스가 주기적으로 Outbox 테이블을 확인하고, 새로운 변경 내역을 메시지 브로커나 다른 서비스로 전송한다. 이 전송이 성공하면 Outbox 테이블에서 해당 기록을 삭제한다.
데이터 일관성:
- Outbox 패턴은 데이터베이스 트랜잭션의 일부분으로 처리되기 때문에, 원자성을 보장한다. 즉, 트랜잭션이 성공하면 Outbox 테이블에 데이터가 기록되고, 실패하면 기록되지 않는다.

작동 방식

쓰기 트랜잭션:
- 애플리케이션이 어떤 데이터를 변경할 때, 이 변경 내역을 Outbox 테이블에 기록한다. 이 과정은 데이터베이스 트랜잭션의 일부분으로 처리된다.
Outbox 테이블 확인:
- 백그라운드 프로세스가 주기적으로 Outbox 테이블을 확인한다.
메시지 전송:
- 새로운 기록이 있으면, 이를 메시지 브로커(예: Kafka, RabbitMQ)나 다른 서비스로 전송한다.
기록 삭제:
- 메시지 전송이 성공하면 Outbox 테이블에서 해당 기록을 삭제한다.

예시

주문 서비스가 주문을 생성하면, 주문 내역을 데이터베이스에 저장하고, 동시에 Outbox 테이블에 주문 생성 이벤트를 기록한다.
백그라운드 프로세스가 Outbox 테이블을 확인하고, 새로운 주문 생성 이벤트를 메시지 브로커를 통해 배송 서비스로 전송한다.
배송 서비스는 메시지를 수신하고, 주문을 처리하여 배송을 준비한다.

장점

데이터 일관성 보장: 데이터베이스 트랜잭션의 일부분으로 처리되기 때문에 데이터 일관성이 보장된다.
내결함성: 메시지 전송 실패 시, 재시도를 통해 신뢰성 있는 메시지 전달을 보장한다.
분산 시스템에서의 효율성: 서비스 간의 직접적인 통신을 줄이고, 메시지 브로커를 통해 간접적으로 통신함으로써 시스템의 복잡도를 줄인다.

Transactional Outbox Pattern은 마이크로서비스 환경에서 데이터 일관성과 메시지 전달의 신뢰성을 보장하는 데 유용한 패턴이며 이를 통해 복잡한 분산 시스템에서의 데이터 동기화를 효과적으로 관리할 수 있다.

예)

@Entity
public class Order {
    @Id
    @GeneratedValue(strategy = GenerationType.IDENTITY)
    private Long id;
    private String description;

    // Getters and Setters
}

@Entity
public class OutboxEvent {
    @Id
    @GeneratedValue(strategy = GenerationType.IDENTITY)
    private Long id;
    private String eventType;
    private String payload;
    private LocalDateTime createdAt;

    // Getters and Setters
}

...
 @Transactional
    public Order createOrder(String description) {
        // 1. 주문 생성
        Order order = new Order();
        order.setDescription(description);
        order = orderRepository.save(order);

        // 2. Outbox 이벤트 기록
        OutboxEvent event = new OutboxEvent();
        event.setEventType("ORDER_CREATED");
        event.setPayload("Order ID: " + order.getId());
        event.setCreatedAt(LocalDateTime.now());
        outboxEventRepository.save(event);

        return order;
    }

 ...


@Service
public class OutboxEventProcessor {

    @Autowired
    private OutboxEventRepository outboxEventRepository;

    @Scheduled(fixedRate = 5000)
    public void processOutboxEvents() {
        List<OutboxEvent> events = outboxEventRepository.findAll();
        for (OutboxEvent event : events) {
            // 메시지 브로커로 이벤트 전송 (여기서는 단순히 로그로 대체)
            System.out.println("Processing event: " + event.getPayload());

            // 이벤트 처리 후 Outbox 테이블에서 삭제
            outboxEventRepository.delete(event);
        }
    }
}

설명

Order 생성: OrderService에서 주문을 생성하고, 이 주문 생성 이벤트를 OutboxEvent 테이블에 기록한다. 이 과정은 하나의 트랜잭션으로 처리된다.
OutboxEvent 처리: OutboxEventProcessor가 주기적으로 Outbox 테이블을 확인하고, 새로운 이벤트가 있으면 이를 메시지 브로커(여기서는 단순히 로그)로 전송한다. 전송이 완료되면 해당 이벤트를 Outbox 테이블에서 삭제한다.

이 예제를 통해 Transactional Outbox Pattern의 기본적인 개념과 작동 방식을 이해할 수 있다. 이 패턴을 사용하면 마이크로서비스 간 데이터 일관성을 유지하면서 신뢰성 있는 메시지 전달을 구현할 수 있다.

Transactional Outbox Pattern 적용 방법 CDC?

CDC(Change Data Capture)는 트랜잭셔널 아웃박스 패턴에서 자주 사용되는 또 다른 방법이다. CDC는 데이터베이스의 변경 사항을 실시간으로 감지하고, 이를 기반으로 다른 시스템(예: 메시지 브로커)으로 데이터를 전송하는 기술이다. 즉 데이터베이스에 기록된 변경 사항을 CDC 도구가 감지하는 것인데 CDC 도구는 데이터베이스 로그(예: MySQL의 binlog, PostgreSQL의 WAL)를 모니터링하면서, 데이터베이스 테이블에 발생한 변경 사항을 실시간으로 추적할 수 있다.

CDC를 활용한 트랜잭셔널 아웃박스 패턴은 실시간 데이터 전송이 필요하거나, 아웃박스 테이블을 주기적으로 조회하는 방식이 비효율적일 때 유용할 수 있다. 이를 통해 시스템의 복잡성을 줄이고, 실시간성을 확보할 수 있다. 대표적인 CDC 도구로는 Debezium, Apache Kafka의 Kafka Connect 등이 있다. CDC를 활용하면 메시지를 보다 빠르게, 그리고 더 정확하게 브로커로 전송할 수 있어 많은 대규모 시스템에서 선호된다고 한다.

출처:

https://pradeepl.com/blog/transactional-outbox-pattern/

RabbitMQ에서 At Least Once 보장

100win10 — Sun, 7 Jul 2024 20:45:11 +0900

메시징 큐 시스템에서 메시지의 신뢰성과 전달 보장은 매우 중요하다. 특히, "at least once" 보장은 메시지가 최소한 한 번은 수신자에게 전달된다는 것을 의미한다. 이번 포스트에서는 Spring Boot를 사용하여 RabbitMQ에서 "at least once" 보장을 구현하는 방법과 RabbitMQ의 2PC(Two-Phase Commit) 지원 방안에 대해 알아보자.

RabbitMQ에서 At Least Once 보장하기

기본적으로 RabbitMQ는 "at least once" 보장을 하지 않는다. 네트워크 장애나 메시지를 보내는 측의 문제로 인해 메시지가 유실될 수 있다. 이를 방지하기 위해 메시지 지속성과 확인 메시지를 활용한 설정이 필요하다.

메시지 지속성(Persistence)
- 메시지를 퍼블리싱할 때 지속성 모드를 설정하여 RabbitMQ 서버가 재시작되더라도 메시지가 유실되지 않도록 한다.
확인 메시지(Acknowledgements)
- 메시지를 소비한 후 RabbitMQ에 확인 응답(ACK)을 보내야 한다. 이를 통해 메시지를 처리한 후에만 큐에서 제거할 수 있다.
메시지 재전송
- 메시지 처리 중 오류가 발생하면 RabbitMQ가 해당 메시지를 다시 큐에 넣고 재전송한다.

아래는 이러한 설정을 반영한 퍼블리셔와 컨슈머 코드이다.

퍼블리셔 코드

퍼블리셔 코드에는 지속성 큐를 설정하여 메시지를 전송한다.

   @Bean
    public Queue myQueue() {
        return new Queue("myQueue", true); // 지속성 큐 설정
    }

컨슈머 코드

컨슈머 코드에는 메시지를 수신하고 처리한 후 수동으로 ACK 또는 NACK를 보내는 로직을 추가한다.

    @Bean
    public Queue myQueue() {
        return new Queue("myQueue", true); // 지속성 큐 설정
    }

    @RabbitListener(queues = "myQueue")
    public void receiveMessage(String message, Channel channel, @Header(AmqpHeaders.DELIVERY_TAG) long tag) {
        try {
            // 메시지 처리 로직
            channel.basicAck(tag, false); // 메시지 처리 성공 시 ACK 전송
        } catch (Exception e) {
            channel.basicNack(tag, false, true); // 메시지 처리 실패 시 NACK 전송
        }
    }

이제 퍼블리셔와 컨슈머 서비스가 메시지를 지속성 큐에 전송하고, 수신한 메시지를 수동으로 확인(ACK) 또는 거부(NACK)하여 "at least once" 보장을 구현가능하게 만들었다.

수동 확인(ACK/NACK) 및 메시지 지속성 설정은 성능에 영향을 줄 수 있다.

메시지 지속성:
- 메시지를 지속성 큐에 저장하면 RabbitMQ는 메시지를 디스크에 기록하므로 디스크 I/O가 추가된다. 이는 메시지 전송 속도를 낮출 수 있다.
수동 확인(ACK/NACK):
- 수동 확인을 사용하면 메시지를 처리한 후 ACK 또는 NACK를 보내야 한다. 이 과정은 자동 확인보다 시간이 더 걸릴 수 있다.
- 특히, 메시지 처리 로직이 복잡하거나 시간이 많이 걸리는 경우 전체 처리 시간이 길어질 수 있다.

이러한 성능 저하를 최소화하기 위한 몇 가지 방법도 있다.

Batch ACK: 여러 메시지를 한 번에 ACK하여 성능을 향상시킬 수 있다. 이는 네트워크 통신을 줄여준다.
QoS 설정: prefetch 설정을 사용하여 소비자가 한 번에 처리할 수 있는 메시지 수를 제한할 수 있다. 이를 통해 메시지 처리량을 조절하고 과부하를 방지할 수 있음.
비동기 처리: 메시지 처리를 비동기로 처리하여 병렬로 여러 메시지를 동시에 처리할 수 있음.

메시지가 컨슈머에게 도달하지 않았을 경우, 컨슈머는 NACK를 보낼 수 없다. 이러한 경우에 "at least once" 보장을 제공하기 위해서는 추가적인 방안이 필요하다.

"At Least Once" 보장을 위한 추가적인 메커니즘

메시지 지속성(Persistence): 메시지가 RabbitMQ 서버에 안전하게 저장되도록 보장한다. 이렇게 하면 서버 재시작이나 네트워크 문제에도 메시지가 손실되지 않는다.

메시지를 퍼블리싱할 때, deliveryMode를 persistent로 설정 및 큐를 생성할 때 durable 속성을 true로 설정하여 디스크에 저장되도록 한다.

2. 퍼블리셔 확인(Publisher Confirms): 메시지를 브로커에 보낸 후, 브로커가 메시지를 안전하게 수신했음을 퍼블리셔에게 확인해주는 방식. 퍼블리셔는 확인 응답을 기다리며, 응답이 오지 않으면 메시지를 다시 전송할 수 있다.

channel.confirmSelect();

if (channel.waitForConfirms()) {
    // 메시지가 브로커에 성공적으로 도달함
} else {
    // 메시지가 브로커에 도달하지 않음, 재전송 로직 필요
}

3. 컨슈머 연결 상태 모니터링: RabbitMQ는 소비자와의 연결 상태를 모니터링하여 연결이 끊어진 경우 이를 감지할 수 있다. 메시지가 특정 소비자에게 전달되지 않으면 RabbitMQ는 메시지를 다시 큐에 넣어 다른 소비자가 처리할 수 있도록 한다.

출처

http://www.rabbitmq.com/tutorials/amqp-concepts.html
[AMQP 0-9-1 Model Explained | RabbitMQ

AMQP 0-9-1 Model Explained | RabbitMQ

<!--

www.rabbitmq.com

맵리듀스와 분산 파일 시스템

100win10 — Thu, 27 Jun 2024 13:57:23 +0900

맵 리듀스(MapReduce)는 구글에서 개발한 대용량 데이터 처리를 위한 분산 컴퓨팅 모델이다. 이 모델은 주로 빅데이터를 분석하고 처리하는 데 사용된다. 맵 리듀스는 두 가지 주요 단계로 구성돠는데 크게 맵(Map) 단계와 리듀스(Reduce) 단계이다.

먼저, 맵(Map) 단계에서는 입력 데이터를 여러 조각으로 나누어 각 조각을 병렬로 처리한다.. 각 조각은 키-값 쌍으로 변환되며, 이 쌍들이 중간 결과로 생성된다. 예를 들어, 단어 빈도를 계산하는 경우, 입력 텍스트의 각 단어를 키로, 단어의 출현 횟수를 값으로 하는 쌍이 만들어 질 수 있다.

그 다음, 리듀스(Reduce) 단계에서는 맵 단계에서 생성된 중간 결과를 취합하여 최종 결과를 생성한다. 같은 키를 가진 데이터들을 모아서 지정된 연산을 수행한다. 단어 빈도 계산의 예시에서는 같은 단어에 대한 빈도들을 합산하여 최종 빈도를 계산한다.

맵 리듀스 작업 실행하기

1. 입력 파일을 읽는다. 레코드로 쪼갠다. 예 ) 레코드 분리자로 '\n' 을 사용

2. 각 입력 레코드마다 매퍼 함수를 호출해 키와 값을 추출한다.

3. 키를 기준으로 키와 값 쌍을 모두 정렬한다.

4. 정렬된 키 값 쌍 전체를 대상으로 reduce 함수를 호출한다. 같은 키가 여러 번 등장했다면 정렬 과정에서 해당 키-값 쌍은 서로 인접한다. 따라서 같은 키를 가지는 값들을 따로 메모리 상에 상태를 유지하지 않고도 쉽게 결합할 수 있다.

2, 4 단계는 사용자가 직접 작성한 데이터 처리 코드다. 1단계는 파일을 나누어 레코드를 만드는 데 입력 형식 파서를 쓴다. 3단계는 정렬 단계로 맵리듀스에 내재하는 단계에서 직접 작성할 필요가 없는데 매퍼의 출력은 리듀스로 들어가기 전에 이미 정렬됐기 때문이다.

맵리듀스 작업을 생성하려면 매퍼와 리듀서라는 두 가지 콜백 함수를 구현해야 한다.

매퍼 ( 정렬에 적합한 형태로 데이터를 준비 )

- 매퍼는 모든 입력 레코드마다 한번씩만 호출된다. 매퍼는 입력 레코드로부터 키와 값을 추출하는 작업이다. 각 입력으로부터 생성하는 키-값 쌍은 빈 쌍을 포함해 원하는 만큼 생성 가능하다. 매퍼는 입력 레코드로부터 다음 레코드까지 상태를 유지하지 않기 때문에 각 레코드를 독립적으로 처리한다.

리듀서 ( 정렬된 데이터를 가공 )

- 맵리듀스 프레임워크는 매퍼가 생산한 키-값 쌍을 받아 같은 키를 가진 레코드를 모으고 해당 값의 집합을 반복해 리듀서 함수를 호출한다. 리듀서는 출력 레코드를 생상한다.

이 과정을 통해 대용량 데이터를 효율적으로 분산 처리하고, 병렬 처리를 통해 성능을 크게 향상시킬 수 있다. 대표적인 구현체로는 Apache Hadoop이 있다.

하둡 맵리듀스 작업의 병렬 실행은 파티셔닝을 기반으로 한다. 작업 입력으로 HDFS 상의 디렉터리를 사용하는 것이 일반적이고, 입력 디렉터리 내 각 파일 또는 파일 블록을 독립된 맵 태스크에서 처리할 독립 파티션으로 간주한다.

HDFS

HDFS는 대용량 데이터를 저장하기 위해 설계된 분산 파일 시스템이며, Hadoop 맵 리듀스 구현에서의 파일 시스템을 말한다.

주요 특징은 다음과 같다.

분산 저장: 데이터를 여러 노드에 분산하여 저장한다.. 이는 데이터의 신뢰성을 높이고, 대규모 데이터 세트를 처리할 수 있게 한다.
중복 저장: 각 데이터 조각(블록)을 여러 노드에 복제하여 저장한다. 이는 하드웨어 고장 시 데이터 손실을 방지한다
대규모 파일 지원: 매우 큰 파일을 여러 블록으로 나누어 저장하므로, 대용량 파일을 쉽게 저장하고 접근할 수 있다.

HDFS는 확장성이 뛰어나다. HDFS를 이용한 데이터 저장과 접근 비용은 범용 하드웨어와 오픈소스 소프트웨어를 사용하기 때문에 동급 용량의 전용 저장소 장치를 사용하는 비용보다 훨씬 저렴하다. 그렇기에 대규모 확장이 가능하다.

블록(Block)이란 무엇인가?

블록은 파일 시스템에서 데이터를 나누는 기본 단위이다.
HDFS에서는 파일을 일정 크기의 블록으로 나눈다. 기본적으로 블록 크기는 128MB 또는 256MB로 설정될 수 있지만, 사용자가 조정할 수 있다.

블록으로 나누어 저장하는 이유

확장성:
- 큰 파일을 여러 블록으로 나누면 각 블록을 여러 노드에 분산하여 저장할 수 있다. 이는 파일 시스템이 매우 큰 파일을 효율적으로 저장하고 관리할 수 있게 한다.
- 여러 블록으로 나누어진 파일을 여러 노드에서 동시에 읽고 쓸 수 있으므로, 처리 속도가 빨라진다.
신뢰성:
- 각 블록은 여러 복제본(replica)을 가지며, 이 복제본들은 다른 노드에 저장된다. 이는 하나의 노드가 고장나더라도 데이터 손실을 방지할 수 있게 한다.
- HDFS는 기본적으로 각 블록의 복제본을 세 개로 유지한다. 하나의 노드가 고장나면 다른 복제본을 사용하여 데이터를 복구할 수 있다.
병렬 처리:
- 여러 노드에 분산 저장된 블록들을 병렬로 처리할 수 있어, 대용량 데이터 처리 작업(예: MapReduce 작업)이 더 효율적이다.
- 여러 블록을 동시에 읽고 쓰기 때문에 대용량 데이터를 빠르게 처리할 수 있다.

예를 들어, 1GB 크기의 파일을 HDFS에 저장한다고 가정해보자. HDFS가 사용하는 블록 크기가 128MB라면, 이 파일은 8개의 블록으로 나누어진다. 이 블록들은 HDFS 클러스터의 여러 노드에 분산 저장된다.

파일 분할:
- 1GB 파일을 128MB 크기의 8개의 블록으로 나눈다.
- 각 블록은 Block 1, Block 2, ..., Block 8로 나뉜다.
분산 저장:
- Block 1은 노드 A, Block 2는 노드 B, Block 3은 노드 C 등으로 분산 저장된다.
- 각 블록의 복제본도 다른 노드에 저장된다. (예: Block 1의 복제본은 노드 B와 노드 C에 저장).
데이터 접근 및 처리:
- MapReduce 작업을 수행할 때, 각 맵(Map) 작업은 서로 다른 노드에서 병렬로 블록을 읽어 처리할 수 있다.
- 이는 작업의 병렬성과 속도를 크게 향상시킨다.

입력 디렉터리 내 각 파일 또는 파일 블록을 독립된 맵 태스크에서 처리할 독립 파티션으로 간주한다.

1. 맵(Map) 단계

HDFS 입력 디렉터리에서 데이터를 읽어들인다. 여기서 데이터는 3개의 맵 태스크(Mapper Task)로 분산된다.
각 맵 태스크는 입력 데이터를 처리하여 키-값 쌍을 생성한다. 예를 들어, 맵 태스크 1은 입력 데이터 m1을 처리하고, 맵 태스크 2는 m2를, 맵 태스크 3는 m3를 처리한다.

2. 셔플(Shuffle) 및 정렬(Sort) 단계

맵 단계에서 생성된 중간 키-값 쌍들은 셔플과 정렬 과정을 거쳐 리듀스 태스크로 전달된다.
이미지에서 보면 각 맵 태스크의 출력이 여러 리듀스 태스크로 분배됩니다. 예를 들어, 맵 태스크 1의 출력(m1, r1, m1, r2, m1, r3)이 리듀스 태스크 1, 2, 3으로 분배되며 이는 키 값에 따라 데이터를 적절한 리듀서로 보내는 과정이다.
이 과정은 모든 맵퍼에서 생성된 동일한 키를 가진 중간 데이터를 동일한 리듀서로 보내기 위해 수행된다.

3. 리듀스(Reduce) 단계

리듀스 태스크는 셔플 및 정렬 단계에서 전달된 키-값 쌍을 받아서 처리한다. 여기서 같은 키를 가진 값들을 모아서 최종 결과를 계산한다.
예를 들어, 리듀스 태스크 1은 m1, r1, m2, r1, m3, r1 데이터를 받아 처리하고, 최종 결과 r1을 생성한다.
마찬가지로, 리듀스 태스크 2는 m1, r2, m2, r2, m3, r2를 처리하여 r2를 생성하고, 리듀스 태스크 3는 m1, r3, m2, r3, m3, r3를 처리하여 r3를 생성한다.

4. 결과 저장

각 리듀스 태스크의 출력 결과는 HDFS 출력 디렉터리에 저장된다. 이는 최종 처리 결과가 HDFS에 저장되는 것을 의미한다

맵 테스크를 m1,m2,m3으로 표시했다. 각 입력 파일은 보통 크기가 수백 메가바이트에 달한다. 각 매퍼 입력 파일의 복제본이 있는 장비에 RAM과 CPU에 여유가 충분하다면 맵리듀스 스케쥴러가 입력 파일이 있는 장비에서 작업을 수행하려 한다. 이 원리를 데이터 가까이에서 연산하기 라 하는데, 이 원리를 적용하면 네트워크를 통해 입력 파일을 복사하는 부담과 네트워크 부하가 감소하고 지역성이 증가한다.

리듀서 측 연산도 파티셔닝 되는데 맵 태스크 수는 입력 파일의 블록 수로 결정되지만, 리듀스 태스크 수는 사용자가 설정한다. 즉 맵 태스크 수와 리듀스 태스크 수는 다를 수 있다. 맵리듀스 프레임워크는 같은 키를 가진 모든 키-값 쌍을 같은 리듀서에서 처리하는 것을 보장하는데, 특정 키-값 쌍이 어느 리듀스 태스크에서 수행될지 결저하기 위해 키의 해시 값을 사용한다.

파티셔닝 과정 설명

파티셔닝은 맵 단계에서 생성된 키-값 쌍을 여러 파티션으로 나누는 과정이다. 이 과정을 통해 동일한 키를 가진 모든 데이터가 동일한 리듀스 태스크로 전달되도록 한다.

맵 단계 (그림의 왼쪽 부분):
- 각 맵 태스크는 입력 데이터를 처리하여 키-값 쌍을 생성한다.
- 예: 맵 태스크 1(m1)이 키1-값1, 키2-값2를 생성한다.
파티셔닝:
- 생성된 키-값 쌍은 키의 해시값을 기반으로 여러 파티션으로 나뉜다.
- 동일한 키를 가진 데이터는 동일한 파티션에 속하게 된다.
- 예를 들어, 키1과 키2가 서로 다른 파티션에 속할 수 있다.
로컬 정렬 및 저장:
- 각 파티션은 맵 태스크의 로컬 디스크에 정렬된 상태로 저장된다.
- 예: 파티션1에는 키1-값1, 파티션2에는 키2-값2가 저장된다.
셔플 및 정렬 단계 (그림의 가운데 부분):
- 맵 태스크가 작업을 완료하면, 맵리듀스 스케줄러는 리듀스 태스크에게 이 맵 태스크의 출력 파일이 준비되었음을 알린다.
- 리듀스 태스크는 각 맵 태스크로부터 자신이 담당할 파티션의 데이터를 가져온다.
- 예: 리듀스 태스크 1(r1)은 모든 맵 태스크로부터 파티션1의 데이터를 가져온다.
리듀스 단계 (그림의 오른쪽 부분):
- 리듀스 태스크는 병합된 데이터를 받아 같은 키를 가진 값들을 처리한다.
- 예: 리듀스 태스크 1(r1)은 키1과 관련된 모든 데이터를 처리한다.

인접한 데이터를 모으는 과정은 주로 두 단계에서 이루어진다: 파티셔닝(Partitioning) 단계와 셔플(Shuffle) 및 정렬(Sort) 단계이다.

구체적인 과정

1. 맵 단계

맵 태스크는 입력 데이터를 처리하여 키-값 쌍을 생성한다.
생성된 키-값 쌍은 키의 해시값을 이용해 여러 파티션으로 나뉜다.
각 파티션은 맵 태스크의 로컬 디스크에 정렬된 상태로 저장된다.

2. 셔플 및 정렬 단계

맵 태스크가 작업을 완료하면, 리듀서는 각 맵 태스크로부터 자신이 담당할 파티션의 데이터를 다운로드한다.
리듀서는 다운로드한 데이터를 키를 기준으로 정렬한다.
이 정렬 과정에서 동일한 키를 가진 값들이 인접하게 배열된다.

3. 리듀스 단계

리듀스 태스크는 정렬된 데이터를 받아 같은 키를 가진 값들을 처리한다.
같은 키를 가진 값들이 인접하게 배열되어 있으므로, 리듀스 태스크는 효율적으로 데이터를 처리할 수 있다.

예시

맵 단계:
- 맵 태스크 1: ('apple', 1), ('banana', 1), ('apple', 1)
- 맵 태스크 2: ('apple', 1), ('banana', 1)
파티셔닝:
- 파티션 1: ('apple', 1), ('apple', 1)
- 파티션 2: ('banana', 1)
셔플 및 정렬:
- 리듀서 1은 모든 맵 태스크로부터 파티션 1의 데이터를 받아 정렬.
- 리듀서 2는 모든 맵 태스크로부터 파티션 2의 데이터를 받아 정렬.
- 정렬된 데이터에서 동일한 키를 가진 값들이 인접하게 배열됨.
리듀스 단계:
- 리듀서 1은 ('apple', [1, 1, 1])을 처리하여 최종 결과를 생성.
- 리듀서 2는 ('banana', [1, 1])을 처리하여 최종 결과를 생성.

전체 과정 요약

맵 단계:
- 입력 데이터를 처리하여 키-값 쌍을 생성하고, 이를 파티셔닝하여 로컬 디스크에 저장합니다.
파티셔닝:
- 키의 해시값을 이용해 데이터를 여러 파티션으로 나누고, 각 파티션은 로컬 디스크에 정렬된 상태로 저장됩니다.
셔플 및 정렬:
- 맵 태스크가 완료되면, 리듀스 태스크가 각 맵 태스크로부터 파티션 데이터를 다운로드합니다.
- 데이터는 리듀스 태스크로 전송되기 전에 정렬됩니다.
리듀스 단계:
- 리듀스 태스크는 병합된 데이터를 받아 정렬된 상태로 처리하여 최종 결과를 생성합니다.
- 최종 결과는 HDFS와 같은 분산 파일 시스템에 저장됩니다.

요약하자면 키를 기준으로 데이터가 같은 파티션에 모이고, 각 파티션의 데이터가 정렬된 상태로 리듀스 태스크에 전달된다. 리듀스 태스크는 이러한 정렬된 데이터를 처리한다.

MapReduce 작업을 여러 단계로 연결하고 전체 데이터 처리 파이프라인을 구성할 때, Workflow 관리 도구나 스케줄러 도구를 사용한다. 이러한 도구들을 사용하면 여러 MapReduce 작업을 순차적으로 또는 병렬로 실행할 수 있고, 복잡한 데이터 처리 워크플로우를 관리할 수 있다.

참고:

책: 데이터 중심 어플리케이션 설계

분산 시스템에서의 일관성 모델: 다이나모 스타일과 완화된 일관성

100win10 — Wed, 26 Jun 2024 23:38:36 +0900

분산 시스템에서 데이터 일관성을 유지하는 것은 매우 중요한 과제이다. 특히, 데이터가 여러 노드에 복제되는 환경에서 일관성을 유지하면서도 성능과 가용성을 높이는 것은 어려운 일이다. 다이나모 스타일 복제를 사용하는 시스템에서의 일관성 모델과 완화된 일관성 모델에 대해 알아보.

다이나모 스타일 복제

다이나모 스타일 복제(Dynamo-style replication)는 리더 없는 분산 시스템에서 사용된다. 이러한 시스템은 모든 노드가 동일한 역할을 수행하며, 쓰기 및 읽기 요청이 임의의 노드에 분산된다. 이로 인해 특정 노드의 장애가 시스템 전체에 미치는 영향을 최소화할 수 있다.

다이나모 스타일 복제를 사용하는 시스템은 궁극적 일관성(eventual consistency)을 제공한다. 궁극적 일관성이란 시간이 지나면 모든 노드가 동일한 데이터를 가지게 된다는 것을 의미한다. 즉, 데이터의 일관성을 즉각적으로 보장하지 않지만, 일정 시간이 지나면 일관된 상태에 도달한다.

선형성과 다이나모 스타일

선형성(linearity)은 분산 시스템에서 매우 강력한 일관성 모델이다. 이는 모든 연산이 단일한 순서로 직렬화된 것처럼 보이게 하여, 모든 클라이언트가 동일한 순서로 동일한 결과를 보장받게 한다. 그러나 다이나모 스타일 복제를 사용하는 시스템은 일반적으로 선형성을 보장하지 않는다. 그 이유는 다음과 같다:

읽기-쓰기 지연: 데이터를 읽거나 쓸 때 여러 노드에 분산되어 요청이 이루어지므로 지연이나 네트워크 분할이 발생할 수 있다. 이는 즉각적인 일관성을 보장하기 어렵게 만든다.
충돌 해결: 동일한 키에 대한 여러 쓰기 요청이 동시에 발생하면 데이터 충돌이 발생할 수 있다. 다이나모 스타일 시스템은 버전 벡터(version vectors)나 마지막 쓰기 승리(Last Write Wins)와 같은 충돌 해결 메커니즘을 사용하지만, 이는 궁극적 일관성을 제공할 뿐 즉각적인 선형성을 보장하지는 않는다.
동기식 연산 부족: 성능을 위해 동기식 연산을 최소화하므로, 쓰기 및 읽기 작업이 즉각적으로 모든 노드에 반영되지 않을 수 있다.

따라서 다이나모 스타일 복제를 사용하는 리더 없는 시스템은 선형성을 제공하지 않는다고 보는 것이 일반적으로 안전하다.

완화된 일관성 모델

완화된 일관성 모델(relaxed consistency model)은 분산 시스템에서 일관성 보장 수준을 완화하여 성능을 향상시키는 모델이다. 이러한 모델들은 시스템의 성능과 가용성을 높이기 위해 일관성 요구 사항을 약화시킨다. 완화된 일관성 모델의 주요 예시와 그 특성은 다음과 같다:

궁극적 일관성 (Eventual Consistency): 모든 업데이트가 결국 모든 복제본에 전파될 것을 보장한다. 시간이 지나면 모든 노드가 동일한 상태가 되지만, 즉각적으로 일관성을 보장하지 않는다. Amazon DynamoDB와 Cassandra가 이를 사용한다.
약한 일관성 (Weak Consistency): 시스템은 읽기 연산이 최신 쓰기 연산을 반영할 것을 보장하지 않는다. 일부 최신 업데이트가 반영되지 않은 데이터를 읽을 수 있다.
연결 일관성 (Session Consistency): 같은 세션 내에서 일관성을 보장한다. 즉, 클라이언트가 동일한 세션 동안 일관된 데이터를 읽을 수 있다.
순차 일관성 (Sequential Consistency): 모든 프로세스가 동일한 순서로 연산을 관찰할 것을 보장한다. 이는 직렬화 가능성보다 약하지만 여전히 강력한 일관성 모델이다.

왜 완화된 일관성 모델을 사용하는가?

완화된 일관성 모델을 사용하는 주요 이유는 다음과 같다:

성능 향상: 엄격한 일관성 모델을 유지하려면 많은 통신 오버헤드와 동기화 시간이 필요하다. 완화된 일관성 모델은 이러한 오버헤드를 줄여 성능을 향상시킨다.
가용성 증가: 완화된 일관성 모델은 시스템의 일부 노드가 일시적으로 불가용 상태가 되더라도 전체 시스템의 가용성을 유지하는 데 도움이 된다.
확장성: 대규모 분산 시스템에서는 일관성을 유지하는 데 드는 비용이 기하급수적으로 증가한다. 완화된 일관성 모델은 더 많은 노드를 추가해도 일관성 유지 비용을 줄일 수 있다.

예시

Amazon DynamoDB와 같은 시스템은 궁극적 일관성을 제공한다. 이는 다음과 같은 상황에서 유용하다:

쇼핑 카트 시스템: 쇼핑 카트에 아이템을 추가하는 연산은 즉각적인 일관성이 필요하지 않다. 시간이 지나면 모든 노드가 동일한 쇼핑 카트 상태를 가지게 되는 것으로 충분하다.
소셜 미디어 피드: 사용자가 게시물을 작성하면, 해당 게시물이 모든 사용자에게 즉시 보이지 않아도 괜찮다. 시간이 지나면서 모든 피드에 전파되면 된다.

완화된 일관성 모델은 일관성보다는 성능과 가용성을 더 중시하는 애플리케이션에 적합하다. 이를 통해 시스템은 더 빠르게 응답하고, 더 높은 가용성을 제공하며, 더 잘 확장할 수 있다.

분산 시스템에서 데이터 일관성을 유지하는 것은 매우 중요하지만, 엄격한 일관성 모델을 유지하는 것은 성능과 가용성 측면에서 어려운 일이다. 다이나모 스타일 복제를 사용하는 시스템은 리더 없는 환경에서 높은 가용성과 성능을 제공하지만, 선형성을 보장하지는 않는다. 반면, 완화된 일관성 모델은 일관성 요구 사항을 완화하여 성능과 가용성을 높일 수 있다. 애플리케이션의 요구 사항에 따라 적절한 일관성 모델을 선택하는 것이 중요하다.

참고:

책: 데이터 중심 어플리케이션 설계

io.kubernetes.client.openapi.ApiException configmaps is forbidden

100win10 — Mon, 8 Apr 2024 17:53:17 +0900

io.kubernetes.client.openapi.ApiException: Message: 
HTTP response code: 403
HTTP response body: {
    "kind":"Status",
    "apiVersion":"v1",
    "metadata":{},
    "status":"Failure",
    "message":"configmaps is forbidden: User \"system:serviceaccount:default:default\" cannot list resource \"configmaps\" in API group \"\" in the namespace \"default\"",
    "reason":"Forbidden",
    "details":{"kind":"configmaps"},
    "code":403
}

RBAC가 활성화 되어있는 쿠버네티스 클러스터에서 pod 내에 자바 client api를 이용한 어플리케이션을 띄워 클러스터 내에 동적으로 configMap 리소스를 만드려는 도중 다음의 에러를 발견했다. 인증에 실패한 서비스 어카운트는 다음과 같다.

User: system:serviceaccount:default:default

> system:serviceaccount:<namespace>:<service account name>

파드내에 어플리케이션을 띄우고 해당 어플리케이션에서 특정 쿠버네티스 클러스터 API 서버에 접속하려 한다면 인증 플러그인이 서비스 어카운트를 인증하는 과정을 거치게 되고 별다른 서비스 어카운트를 지정하지 않는다면 deployment 리소스에 정의한 네임스페이스와 서비스 어카운트를 따라가게 된다. ( 나의 어플리케이션에 경우 ns : default , sa : 지정하지 않았기에 default)

서비스 어카운트의 기본 권한으로는 리소스를 나열하거나 수정할 수 없다. 수정에 대한 롤을 만들고 서비스 어카운트에 롤을 바인딩해보자. 우선 default 서비스 어카운트를 그대로 사용하지는 않았는데 default 서비스 어카운트에 롤을 변경한다면 다른 서비스들까지 보안상의 위협이 될 수도 있을거라 생각했기 때문이다. 새로운 서비스 어카운트를 생성하고 파드에 어플리케이션을 띄울때 해당 서비스 어카운트를 이용하도록 변경하였다.

kubectl create serviceaccount {이름}

이제 해당 서비스 어카운트가 롤을 이용할 수 있도록 롤과 롤바인딩을 생성해주자. 간단히 롤은 리소스에 수행할 수 있는 것들 ( 수정, 조회등 ) 지정하는 것이며 롤 바인딩은 누가 이 룰을 사용할 수 있는지를 지정하는 것이다.

1. 롤 생성

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: {이름}
  namespace: default
rules:
  - verbs:
      - '*'
    apiGroups:
      - ''
    resources:
      - configmaps
      - deployments

2. 롤 바인딩

kubectl create rolebinding {롤 바인딩 이름} --role={ 롤 이름 } --serviceaccount={네임스페이스:서비스 어카운트 이름}

에러 해결후 정상적으로 configMap 이 생성되었다. 그런데 deployment 생성시 롤을 추가해도 동일한 에러가 발생하였다.

io.kubernetes.client.openapi.ApiException: Message: HTTP response code: 403
HTTP response body: 
{
    "kind":"Status",
    "apiVersion":"v1",
    "metadata":{},
    "status":"Failure",
    "message":"deployments.apps is forbidden: User \"system:serviceaccount:default:keyword\" cannot list resource \"deployments\" in API group \"apps\" in the namespace \"default\"",
    "reason":"Forbidden",
    "details":{"group":"apps","kind":"deployments"},
    "code":403    
}

cluster-admin 클러스터 롤을 해당 서비스 어카운트에 클러스터 롤 바인딩 시켜 해결

kubectl create clusterrolebinding {클러스터 롤 바인딩 이름} --clusterrole=cluster-admin --serviceaccount=default:{서비스 어카운트 이름}

참고

- 쿠버네티스 인 액션

- https://kubernetes.io/docs/tasks/configure-pod-container/configure-pod-configmap/

- https://stackoverflow.com/questions/49173838/deployments-apps-is-forbidden-user-systemserviceaccountdefaultdefault-cann

Configure a Pod to Use a ConfigMap

Many applications rely on configuration which is used during either application initialization or runtime. Most times, there is a requirement to adjust values assigned to configuration parameters. ConfigMaps are a Kubernetes mechanism that let you inject c

kubernetes.io

Spring Cloud Kubernetes: ConfigMap 변경 시 전체 서비스 갱신

100win10 — Wed, 10 Jan 2024 00:01:34 +0900

Kubernetes 환경에서 Spring Cloud를 사용하면 ConfigMap 변경 시 전체 서비스가 갱신되는 기능을 제공한다. 이는 spring-cloud-starter-kubernetes-client-config 라이브러리를 통해 가능하다.

ConfigMap 감지

Spring Cloud Kubernetes는 Kubernetes API 서버와 통신하여 ConfigMap의 변경을 감지한다. 이를 위해 Kubernetes Watch API를 사용하여 ConfigMap 리소스를 모니터링한다. Watch API는 Kubernetes 리소스의 생성, 업데이트, 삭제 등의 이벤트를 실시간으로 스트리밍한다.

이벤트 수신 및 트리거

ConfigMap이 변경되면, Watch API는 해당 변경 이벤트를 Spring Cloud Kubernetes로 전달한다. Spring Cloud Kubernetes는 이 이벤트를 수신하고, 설정된 리스너(listener)를 통해 애플리케이션에 알린다.

Spring Cloud Kubernetes는 내부적으로 다양한 리스너를 사용하여 ConfigMap 변경 이벤트를 처리한다. 이를 통해 설정 값이 동적으로 반영될 수 있다. 여기서 리스너는 일종의 콜백 함수나 메서드로, 특정 이벤트가 발생했을 때 자동으로 호출된다.

Spring Cloud Kubernetes Configuration Watch

Spring Cloud Kubernetes에서는 기본적으로 ConfigurationChangeDetector라는 컴포넌트가 ConfigMap의 변경 사항을 감지하는 역할을 한다. 이 컴포넌트는 Kubernetes 클러스터와 연결되어 ConfigMap 변경 이벤트를 수신하고, 이를 Spring Cloud Context로 전달한다.

https://github.com/fabric8io/spring-cloud-kubernetes/blob/master/spring-cloud-kubernetes-core/src/main/java/io/fabric8/spring/cloud/kubernetes/reload/ConfigurationChangeDetector.java

spring-cloud-kubernetes/spring-cloud-kubernetes-core/src/main/java/io/fabric8/spring/cloud/kubernetes/reload/ConfigurationChange

Kubernetes integration with Spring Cloud. Contribute to fabric8io/spring-cloud-kubernetes development by creating an account on GitHub.

github.com

동작 과정 요약

Kubernetes Watch 설정: Spring Cloud Kubernetes는 Kubernetes Watch API를 사용하여 ConfigMap의 변경을 실시간으로 감지한다.
이벤트 수신: ConfigMap이 변경되면, Watch API는 변경 이벤트를 Spring Cloud Kubernetes로 전달한다.
리스너 호출: Spring Cloud Kubernetes는 수신된 이벤트를 기반으로 설정된 리스너를 호출한다.
설정 업데이트: 리스너는 변경된 설정 값을 처리하고, 필요 시 @ConfigurationProperties 또는 @RefreshScope 빈을 다시 로드하거나 갱신한다.

설정 업데이트?

Spring Cloud Kubernetes는 수신된 이벤트를 바탕으로 애플리케이션의 환경 설정을 동적으로 업데이트한다. Spring의 Environment 객체가 업데이트되며, 이 과정에서 변경된 설정 값들이 반영된다.

빈(Bean) 리프레시

Spring Cloud Kubernetes는 @ConfigurationProperties 또는 @RefreshScope로 선언된 빈(Bean)들을 다시 로드하거나 갱신한다. @RefreshScope는 Spring Cloud Context 모듈의 기능으로, 빈의 상태를 유지하면서 설정값을 갱신할 수 있다. 이로 인해 변경된 설정 값이 즉시 애플리케이션에 반영되고, 관련 빈이 재생성되거나 갱신된다.

@ConfigurationProperties 빈이 갱신되는 메커니즘은 Spring Cloud Kubernetes와 Spring Cloud Context의 기능을 결합하여 이루어진다. 이 과정은 Kubernetes에서 ConfigMap 변경을 감지하고, 변경된 설정을 Spring 애플리케이션에 동적으로 반영하며, 필요한 경우 관련 빈을 갱신하는 것을 포함한다.

1. ConfigMap 변경 감지

Spring Cloud Kubernetes는 Kubernetes Watch API를 사용하여 ConfigMap의 변경을 실시간으로 감지한다. 변경이 감지되면, Spring Cloud Kubernetes는 변경 이벤트를 수신하고 이를 처리하기 시작한다.

2. 환경(Environment) 재설정

변경 이벤트가 수신되면, Spring Cloud Kubernetes는 변경된 ConfigMap 값을 Spring의 Environment 객체에 반영한다. 이는 Spring의 환경 설정이 갱신된다는 것을 의미한다.

3. @RefreshScope 빈 갱신

@RefreshScope로 주석이 달린 빈은 Spring Cloud Context의 RefreshScope에 의해 관리된다. 이 어노테이션은 해당 빈의 상태를 유지하면서 설정 값이 변경될 때 빈을 다시 로드하거나 갱신할 수 있게 한다.

4. /actuator/refresh 엔드포인트 호출

Spring Boot Actuator를 사용하여 /actuator/refresh 엔드포인트를 활성화할 수 있다. 이 엔드포인트를 호출하면 Spring Cloud Context는 Environment 객체가 갱신된 것을 감지하고, @RefreshScope로 주석이 달린 모든 빈을 다시 로드하거나 갱신한다.

@ConfigurationProperties와 @RefreshScope

1. @ConfigurationProperties

@ConfigurationProperties는 설정 파일의 값을 클래스에 바인딩하는 데 사용된다. 이를 통해 애플리케이션 설정을 쉽게 관리할 수 있다.

import org.springframework.boot.context.properties.ConfigurationProperties;
import org.springframework.context.annotation.Configuration;

@Configuration
@ConfigurationProperties(prefix = "my")
public class MyConfigProperties {
    private String message;
    private int value;

    // Getters and Setters
    public String getMessage() {
        return message;
    }

    public void setMessage(String message) {
        this.message = message;
    }

    public int getValue() {
        return value;
    }

    public void setValue(int value) {
        this.value = value;
    }
}

import org.springframework.cloud.context.config.annotation.RefreshScope;
import org.springframework.web.bind.annotation.RestController;

@RefreshScope
@RestController
public class MyConfigController {

    @Autowired
    private MyConfigProperties myConfigProperties;

    @GetMapping("/config")
    public String getConfig() {
        return "Message: " + myConfigProperties.getMessage() + ", Value: " + myConfigProperties.getValue();
    }
}

ConfigMap 생성

apiVersion: v1
kind: ConfigMap
metadata:
  name: my-config
data:
  application.yml: |
    my:
      message: Hello from ConfigMap
      value: 42

어플리케이션 설정

spring:
  cloud:
    kubernetes:
      config:
        enabled: true
        name: my-config
        namespace: default

management:
  endpoints:
    web:
      exposure:
        include: refresh, health, info