taeyoon2 님의 블로그

[내일배움캠프 사전캠프] 24회차 TIL(7/29 수) - RabbitMQ 구조 설계 및 이해, Kafka 개념 정리

taeyoon2 — Wed, 29 Jul 2026 20:19:08 +0900

RabbitMQ란?

RabbitMQ는 서비스나 애플리케이션 사이에서 메시지를 전달하는 메시지 브로커(Message Broker) 이다.

서비스가 다른 서비스를 직접 호출하는 대신 RabbitMQ에 메시지를 전달하면, RabbitMQ가 메시지를 Queue에 보관하고 해당 Queue를 구독하는 Consumer에게 전달한다.

예를 들어 주문이 생성되었을 때 Order Service가 Product Service를 직접 호출하지 않고 RabbitMQ를 사용한다면 다음과 같은 구조가 된다.

Order Service
    ↓
RabbitMQ
    ↓
Product Queue
    ↓
Product Service

Order Service는 메시지를 생성해 RabbitMQ로 보내는 Producer 역할을 한다.

RabbitMQ는 전달받은 메시지를 Queue에 보관하고, Product Service는 Queue에서 메시지를 가져와 처리하는 Consumer 역할을 한다.

이러한 구조를 사용하면 Order Service와 Product Service가 서로를 직접 호출하지 않아도 되기 때문에 서비스 사이의 결합도를 낮출 수 있다.

RabbitMQ의 장점

1. 신뢰성

RabbitMQ는 메시지 승인 방식인 ACK(Acknowledgement) 를 지원한다.

Consumer가 메시지를 정상적으로 처리하면 ACK를 RabbitMQ에 전달하고, RabbitMQ는 해당 메시지가 성공적으로 처리되었다고 판단한다.

반대로 메시지 처리 중 오류가 발생하여 ACK가 전달되지 않으면 메시지를 다시 Queue에 넣거나 다른 Consumer에게 전달하도록 구성할 수 있다.

또한 Queue를 Durable로 설정하고 메시지를 Persistent 형태로 전송하면 RabbitMQ가 재시작되더라도 메시지가 유지되도록 구성할 수 있다.

단, RabbitMQ에 메시지를 보낸다고 해서 모든 메시지가 자동으로 디스크에 영구 저장되는 것은 아니다. Queue와 메시지의 영속성 설정이 함께 필요하다.

2. 유연성

RabbitMQ는 여러 메시지 전달 방식을 지원한다.

Exchange의 종류와 Routing Key를 이용하면 하나의 메시지를 특정 Queue로 전달하거나 여러 Queue에 동시에 전달하는 등의 구조를 만들 수 있다.

RabbitMQ는 기본적으로 AMQP를 사용하며, 플러그인을 통해 STOMP와 MQTT 등의 프로토콜도 지원한다.

3. 확장성

RabbitMQ는 클러스터링을 통해 여러 노드로 구성할 수 있다.

이를 통해 장애에 대비한 고가용성 환경을 구성하거나 여러 Consumer를 실행하여 메시지 처리 부하를 분산할 수 있다.

4. 관리 및 모니터링

RabbitMQ는 웹 기반 Management UI를 제공한다.

관리 화면을 통해 다음과 같은 정보를 확인할 수 있다.

Exchange 목록
Queue 목록
Binding 관계
Queue에 쌓인 메시지 수
Producer와 Consumer 연결 상태
메시지 처리 속도

5. 비동기 처리

Producer는 Consumer의 작업이 끝날 때까지 기다리지 않고 RabbitMQ에 메시지를 전송한 뒤 자신의 작업을 계속할 수 있다.

따라서 처리 시간이 오래 걸리는 작업을 비동기로 분리할 수 있다.

RabbitMQ의 단점

1. 설정 및 운영 복잡성

Exchange, Queue, Routing Key, Binding, ACK, 재시도 정책 등을 올바르게 설정해야 한다.
서비스 규모가 커질수록 Queue와 메시지 흐름을 관리하는 작업도 복잡해질 수 있다.

2. 메시지 중복 처리 가능성

ACK가 전달되지 않거나 네트워크 오류가 발생하면 동일한 메시지가 다시 전달될 수 있다.
따라서 Consumer는 같은 메시지를 여러 번 받더라도 문제가 발생하지 않도록 멱등성을 고려해야 한다.

3. 성능 관리 필요

Queue에 메시지가 지나치게 많이 쌓이거나 Consumer의 처리 속도가 느리면 메시지 지연이 발생할 수 있다.
메시지 크기, Consumer 개수, Prefetch 설정 등을 적절하게 조절해야 한다.

4. 운영 비용

RabbitMQ 서버 구축뿐만 아니라 장애 대응, 모니터링, 백업, 클러스터 관리 등에 추가적인 운영 비용이 발생한다.

RabbitMQ의 구성 요소

메시지(Message)

RabbitMQ를 통해 전달되는 데이터 단위이다.

현재 프로젝트에서는 주문 ID, 상품 ID, 주문 수량 등의 정보를 가진 DeliveryMessage 객체가 메시지로 사용된다.

RabbitMQ는 Java 객체 자체를 이해하는 것이 아니라 바이트 데이터를 전달한다.

따라서 Jackson 기반의 MessageConverter를 사용하면 Java 객체를 JSON 형태로 변환하여 메시지로 전송하고, Consumer에서는 다시 Java 객체로 변환해 받을 수 있다.

DeliveryMessage 객체
        ↓
Jackson JSON 변환
        ↓
RabbitMQ 전송
        ↓
Jackson 객체 변환
        ↓
DeliveryMessage 객체

Producer

메시지를 생성하여 RabbitMQ로 전송하는 주체이다.

현재 프로젝트에서는 Order Service가 주문 생성 후 상품 재고 차감 메시지를 전송하므로 Producer 역할을 한다.

Spring에서는 RabbitTemplate.convertAndSend();을 이용해 메시지를 전송할 수 있다.

Queue

메시지가 Consumer에 의해 처리되기 전까지 대기하는 공간이다.

Producer가 전송한 메시지는 Queue에 들어가고, 해당 Queue를 구독하는 Consumer가 메시지를 가져가 처리한다.

현재 프로젝트에서는 다음과 같은 Queue를 사용한다.

productQueue
paymentQueue
errorOrderQueue
errorProductQueue

Consumer

Queue의 메시지를 가져와 처리하는 주체이다.

Spring에서는 @RabbitListener를 사용하여 특정 Queue를 구독할 수 있다.

메시지가 Queue에 들어오면 Spring이 @RabbitListener가 선언된 메서드를 자동으로 호출한다.

현재 프로젝트에서는 Product Service의 ProductEndpoint가 productQueue를 구독하는 Consumer 역할을 한다.

Exchange

Producer가 전송한 메시지를 어떤 Queue로 전달할지 결정하는 역할을 한다.

Exchange는 메시지의 Routing Key와 Binding 정보를 확인하여 적절한 Queue로 메시지를 라우팅한다.

Order Service
    ↓
Exchange
    ↓
Product Queue
    ↓
Product Service

Binding

Exchange와 Queue를 연결하는 설정이다.

Binding에는 Routing Key가 포함될 수 있으며, Exchange는 메시지의 Routing Key와 Binding Key를 비교하여 메시지를 전달할 Queue를 결정한다.

그림으로 표현하면 Exchange와 Queue 사이를 연결하는 화살표라고 볼 수 있다.

Exchange ── Binding ──> Product Queue

RabbitMQ에서 AMQP란?

AMQP는 Advanced Message Queuing Protocol의 약자로, 메시지 브로커를 통해 메시지를 전달하기 위한 표준 프로토콜이다.

메시지 생성, 전송, Queue 저장, 라우팅, ACK 처리 등의 방식을 표준화한다.

RabbitMQ는 AMQP 모델을 기반으로 Exchange, Queue, Binding, Routing Key를 사용하여 메시지를 전달한다.

AMQP의 주요 개념은 다음과 같다.

Message
Producer
Consumer
Exchange
Queue
Routing Key
Binding
ACK

전체 메시지 처리 구조

현재 프로젝트의 정상적인 주문 처리 흐름은 다음과 같다.

클라이언트
    ↓ HTTP 요청
OrderEndpoint
    ↓
OrderService
    ↓ RabbitTemplate
RabbitMQ
    ↓
productQueue
    ↓ @RabbitListener
ProductEndpoint
    ↓
ProductService
    ↓
상품 재고 차감

각 계층의 책임은 다음과 같이 구분할 수 있다.

OrderEndpoint
- 클라이언트의 HTTP 요청 수신
- OrderService 호출

OrderService
- 주문 생성
- 주문 저장
- RabbitTemplate을 이용한 메시지 전송

ProductEndpoint
- @RabbitListener를 이용한 Queue 구독
- 메시지 수신
- ProductService 호출

ProductService
- 상품 재고 차감
- 재고 복구
- 실제 비즈니스 로직 수행

RabbitMQ 구조 설정

다음 코드는 Exchange, Queue, Binding을 Spring Bean으로 등록하는 설정이다.

@Configuration
public class OrderApplicationQueueConfig {

    @Bean
    public MessageConverter messageConverter() {
        return new JacksonJsonMessageConverter();
    }

    @Value("${message.exchange}")
    private String exchange;

    @Value("${message.queue.product}")
    private String queueProduct;

    @Value("${message.queue.payment}")
    private String queuePayment;

    @Value("${message.err.exchange}")
    private String exchangeErr;

    @Value("${message.queue.err.order}")
    private String queueErrOrder;

    @Value("${message.queue.err.product}")
    private String queueErrProduct;


    @Bean public TopicExchange exchange() { return new TopicExchange(exchange);}

    @Bean public Queue queueProduct(){ return new Queue(queueProduct);}
    @Bean public Queue queuePayment(){ return new Queue(queuePayment);}

    // 아래 두개는 order -> exchange에서 productQueue로 가는 화살표를 바인딩하는 것과
    // product -> exchange에서 paymentQueue로 가는 화살표를 바인딩 한 것
    @Bean public Binding bindingProduct(){ return BindingBuilder.bind(queueProduct()).to(exchange()).with(queueProduct); }
    @Bean public Binding bindingPayment(){ return BindingBuilder.bind(queuePayment()).to(exchange()).with(queuePayment); }


    @Bean public TopicExchange exchangeErr() { return new TopicExchange(exchangeErr);}

    @Bean public Queue queueErrOrder() { return new Queue(queueErrOrder); }
    @Bean public Queue queueErrProduct() { return new Queue(queueErrProduct);}

    @Bean public Binding bindingErrOrder(){ return BindingBuilder.bind(queueErrOrder()).to(exchangeErr()).with(queueErrOrder);}
    @Bean public Binding bindingErrProduct(){ return BindingBuilder.bind(queueErrProduct()).to(exchangeErr()).with(queueErrProduct);}

이 설정은 메시지를 실제로 보내거나 처리하는 코드가 아니다.

RabbitMQ 내부에 다음과 같은 구조를 등록하는 역할을 한다.

Normal Exchange
    ├── productQueue
    └── paymentQueue

Error Exchange
    ├── queueErrOrder
    └── queueErrProduct

Binding은 Exchange와 Queue를 연결하고, 어떤 Routing Key를 가진 메시지가 어떤 Queue로 전달될지를 정의한다.

OrderEndpoint

@RestController
@RequiredArgsConstructor
public class OrderEndpoint {

    private final OrderService orderService;

    @GetMapping("/order/{orderId}")
    public ResponseEntity<Order> getOrder(
            @PathVariable("orderId") UUID orderId
    ) {
        Order order = orderService.getOrder(orderId);

        return ResponseEntity.ok(order);
    }

    @PostMapping("/order")
    public ResponseEntity<Order> order(
            @RequestBody OrderRequestDto orderRequestDto
    ) {
        Order order = orderService.createOrder(orderRequestDto);

        return ResponseEntity.ok(order);
    }
}

OrderEndpoint는 RabbitMQ로 메시지를 직접 전송하는 역할이 아니다.

클라이언트의 HTTP 요청을 받아 OrderService에 전달하는 진입점 역할을 한다.

POST /order 요청이 들어오면 요청 데이터를 OrderService의 createOrder() 메서드로 전달한다.

Client
   ↓ HTTP POST
OrderEndpoint
   ↓
OrderService

즉, OrderEndpoint의 주요 책임은 다음과 같다.

HTTP 요청 수신
요청 데이터 전달
Service 호출
처리 결과 반환

실제 주문 생성과 RabbitMQ 메시지 전송은 OrderService에서 처리한다.

OrderService

@Slf4j
@Service
@RequiredArgsConstructor
public class OrderService {

    @Value("${message.queue.product}")
    private String productQueue;

    private final RabbitTemplate rabbitTemplate;

    /**
     * 데이터베이스 대신 사용하는 임시 메모리 저장소
     */
    private final Map<UUID, Order> orderStore = new HashMap<>();

    public Order createOrder(
            OrderEndpoint.OrderRequestDto orderRequestDto
    ) {
        Order order = orderRequestDto.toOrder();

        DeliveryMessage deliveryMessage =
                orderRequestDto.toDeliveryMessage(order.getOrderId());

        orderStore.put(order.getOrderId(), order);

        log.info("SEND MESSAGE: {}", deliveryMessage);

        rabbitTemplate.convertAndSend(
                productQueue,
                deliveryMessage
        );

        return order;
    }

    public Order getOrder(UUID orderId) {
        return orderStore.get(orderId);
    }
}

OrderService는 주문 생성과 메시지 전송을 담당한다.

주문 요청이 들어오면 먼저 Order 객체를 생성하고, Product Service로 전달할 DeliveryMessage 객체를 생성한다.

생성한 주문은 현재 데이터베이스 대신 Map에 임시로 저장한다.

그 후 RabbitTemplate의 convertAndSend()를 사용하여 메시지를 productQueue로 전송한다.

rabbitTemplate.convertAndSend(
        productQueue,
        deliveryMessage
);

RabbitTemplate은 Spring에서 RabbitMQ로 메시지를 전송하기 위해 사용하는 객체이다.

등록된 MessageConverter가 DeliveryMessage 객체를 JSON 등의 메시지 형태로 변환한 뒤 RabbitMQ로 전달한다.

따라서 OrderService의 역할은 Queue에서 메시지를 가져오는 것이 아니다.

현재 코드에서 OrderService는 메시지를 생성하고 전송하는 Producer 역할을 한다.

OrderService
    ↓ DeliveryMessage 생성
RabbitTemplate
    ↓
productQueue

현재 전송 방식에서 주의할 점

현재 코드는 다음과 같이 인자 두 개를 사용한다.

rabbitTemplate.convertAndSend(
        productQueue,
        deliveryMessage
);

이 방식은 직접 만든 TopicExchange의 이름을 지정하지 않는다.

Spring AMQP에서는 첫 번째 인자를 Routing Key로 사용하여 RabbitMQ의 기본 Exchange를 통해 이름이 같은 Queue로 메시지를 전달한다.

따라서 현재 흐름은 다음과 가깝다.

OrderService
    ↓
RabbitMQ 기본 Exchange
    ↓ Queue 이름과 Routing Key 일치
productQueue

앞에서 생성한 TopicExchange를 명시적으로 사용하려면 Exchange 이름과 Routing Key를 모두 전달해야 한다.

rabbitTemplate.convertAndSend(
        exchangeName,
        productQueue,
        deliveryMessage
);

이 경우 메시지 흐름은 다음과 같다.

OrderService
    ↓
TopicExchange
    ↓ Binding 및 Routing Key 확인
productQueue

즉, 현재 코드처럼 Queue 이름만 전달하면 직접 만든 Topic Exchange를 거치지 않을 수 있다는 점을 구분해야 한다.

ProductEndpoint와 ProductService

Product Service에서는 ProductEndpoint와 ProductService가 서로 다른 역할을 담당한다.

ProductEndpoint는 RabbitMQ Queue를 구독하고 메시지를 수신하는 Consumer 역할을 한다.

ProductService는 수신한 메시지의 상품 정보를 검증하고, 처리 결과에 따라 다음 Queue로 메시지를 전달하는 비즈니스 로직 역할을 한다.

전체적인 역할은 다음과 같이 구분할 수 있다.

RabbitMQ Queue
      ↓
ProductEndpoint
      ↓
ProductService
      ↓
다음 Queue로 메시지 전달

ProductEndpoint

@Slf4j
@Component
@RequiredArgsConstructor
public class ProductEndpoint {

    private final ProductService productService;

    @RabbitListener(queues = "${message.queue.product}")
    public void receiveMessage(
            DeliveryMessage deliveryMessage
    ) {
        log.info("PRODUCT RECEIVE: {}", deliveryMessage);

        productService.reduceProductAmount(deliveryMessage);
    }

    @RabbitListener(queues = "${message.queue.err.product}")
    public void receiveErrorMessage(
            DeliveryMessage deliveryMessage
    ) {
        log.info("PRODUCT ERROR RECEIVE: {}", deliveryMessage);

        productService.rollbackProduct(deliveryMessage);
    }
}

ProductEndpoint는 두 개의 Queue를 구독한다.

하나는 정상적인 상품 처리 메시지를 받는 productQueue이고, 다른 하나는 이후 단계에서 발생한 오류를 전달받는 errorProductQueue이다.

정상 메시지 수신

@RabbitListener(queues = "${message.queue.product}")
public void receiveMessage(DeliveryMessage deliveryMessage) {
    log.info("PRODUCT RECEIVE: {}", deliveryMessage);

    productService.reduceProductAmount(deliveryMessage);
}

다음 설정을 통해 productQueue를 지속적으로 구독한다.

@RabbitListener(queues = "${message.queue.product}")

productQueue에 메시지가 들어오면 Spring AMQP가 receiveMessage()를 자동으로 호출한다.

RabbitMQ에 저장된 메시지는 설정된 MessageConverter를 통해 DeliveryMessage 객체로 변환되어 메서드의 매개변수로 전달된다.

productService.reduceProductAmount(deliveryMessage);

ProductEndpoint는 상품 검증을 직접 수행하지 않고, 메시지를 ProductService의 reduceProductAmount()에 전달한다.

오류 메시지 수신

@RabbitListener(queues = "${message.queue.err.product}")
public void receiveErrorMessage(DeliveryMessage deliveryMessage) {
    log.info("PRODUCT ERROR RECEIVE: {}", deliveryMessage);

    productService.rollbackProduct(deliveryMessage);
}

다음 설정을 통해 errorProductQueue를 구독한다.

@RabbitListener(queues = "${message.queue.err.product}")

이 Queue는 Product Service 자체에서 처음 발생한 상품 검증 오류를 받기 위한 Queue가 아니다.

Product Service가 정상적으로 메시지를 다음 단계인 Payment Service로 전달한 후, Payment Service 등 이후 처리 단계에서 오류가 발생했을 때 Product Service로 오류 메시지를 되돌려 보내기 위한 Queue이다.

오류 메시지가 errorProductQueue에 들어오면 receiveErrorMessage()가 호출되고, 해당 메시지는 ProductService의 rollbackProduct()로 전달된다.

productService.rollbackProduct(deliveryMessage);

실제 시스템이라면 이 시점에 이전에 수행했던 상품 재고 차감 작업을 취소하는 보상 처리를 구현할 수 있다.

하지만 현재 코드에는 데이터베이스의 재고를 복구하는 로직이 구현되어 있지 않다.

ProductService

@Slf4j
@Service
@RequiredArgsConstructor
public class ProductService {

    @Value("${message.queue.payment}")
    private String paymentQueue;

    @Value("${message.queue.err.order}")
    private String errOrderQueue;

    private final RabbitTemplate rabbitTemplate;

    public void reduceProductAmount(DeliveryMessage deliveryMessage) {
        Integer productId = deliveryMessage.getProductId();
        Integer productQuantity = deliveryMessage.getProductQuantity();

        if (productId != 1 || productQuantity > 1) {
            this.rollbackProduct(deliveryMessage);
            return;
        }

        rabbitTemplate.convertAndSend(
                paymentQueue,
                deliveryMessage
        );
    }

    public void rollbackProduct(DeliveryMessage deliveryMessage) {
        log.info("PRODUCT ROLLBACK!!!");

        if (StringUtils.hasText(deliveryMessage.getErrorType())) {
            deliveryMessage.setErrorType("PRODUCT ERROR");
        }

        rabbitTemplate.convertAndSend(
                errOrderQueue,
                deliveryMessage
        );
    }
}

ProductService는 ProductEndpoint에서 전달받은 메시지를 처리하고, 처리 결과에 따라 다음 Queue를 결정한다.

현재 코드의 주요 역할은 다음과 같다.

상품 ID와 상품 수량을 확인한다.
상품 정보가 유효한지 검증한다.
검증에 성공하면 메시지를 paymentQueue로 전달한다.
검증에 실패하면 오류 메시지를 errOrderQueue로 전달한다.
이후 단계에서 오류 메시지가 돌아오면 Order Service 쪽으로 오류를 전달한다.

상품 정보 검증

public void reduceProductAmount(DeliveryMessage deliveryMessage) {
    Integer productId = deliveryMessage.getProductId();
    Integer productQuantity = deliveryMessage.getProductQuantity();

reduceProductAmount()는 DeliveryMessage에서 상품 ID와 상품 수량을 가져온다.

Integer productId = deliveryMessage.getProductId();
Integer productQuantity = deliveryMessage.getProductQuantity();

이후 다음 조건을 사용하여 상품 정보를 검증한다.

if (productId != 1 || productQuantity > 1) {
    this.rollbackProduct(deliveryMessage);
    return;
}

현재 예제에서는 다음 중 하나라도 해당하면 상품 처리를 실패한 것으로 판단한다.

상품 ID가 1이 아닌 경우
요청한 상품 수량이 1보다 큰 경우

즉, 현재 코드는 실제 데이터베이스에서 상품이나 재고를 조회하는 것이 아니라, 고정된 값을 기준으로 상품 처리 성공과 실패를 구분하는 간단한 예제이다.

검증에 실패하면 rollbackProduct()를 호출한다.

this.rollbackProduct(deliveryMessage);
return;

return을 사용했기 때문에 이후의 paymentQueue 전송 코드는 실행되지 않는다.

상품 검증 성공

상품 ID와 수량이 조건에 맞으면 다음 코드가 실행된다.

rabbitTemplate.convertAndSend(
        paymentQueue,
        deliveryMessage
);

RabbitTemplate은 DeliveryMessage를 RabbitMQ의 paymentQueue로 전송한다.

이후 Payment Service가 paymentQueue를 구독하고 있다면 해당 메시지를 수신하여 결제 처리를 이어갈 수 있다.

ProductService
      ↓
RabbitTemplate
      ↓
paymentQueue
      ↓
Payment Service

현재 코드에서는 실제 상품 재고를 데이터베이스에서 차감하는 로직이 없다.

따라서 reduceProductAmount()라는 메서드 이름과 달리, 실제 동작은 다음과 같다.

상품 ID와 수량 확인
        ↓
상품 정보 검증
        ↓
paymentQueue로 메시지 전달

현재 예제 기준으로는 “상품 재고를 차감한다”라고 설명하기보다 상품 정보를 검증하고 다음 결제 단계로 메시지를 전달한다라고 설명하는 것이 정확하다.

상품 검증 실패

상품 ID나 상품 수량이 조건에 맞지 않으면 rollbackProduct()가 호출된다.

if (productId != 1 || productQuantity > 1) {
    this.rollbackProduct(deliveryMessage);
    return;
}

이 경우 메시지는 errorProductQueue로 이동하지 않는다.

reduceProductAmount()가 rollbackProduct()를 직접 호출하고, rollbackProduct()가 곧바로 메시지를 errOrderQueue로 전송한다.

따라서 Product Service 자체에서 발생한 상품 검증 실패 흐름은 다음과 같다.

productQueue
      ↓
ProductEndpoint.receiveMessage()
      ↓
ProductService.reduceProductAmount()
      ↓
상품 검증 실패
      ↓
ProductService.rollbackProduct()
      ↓
errOrderQueue
      ↓
Order Service

rollbackProduct()

public void rollbackProduct(DeliveryMessage deliveryMessage) {
    log.info("PRODUCT ROLLBACK!!!");

    if (StringUtils.hasText(deliveryMessage.getErrorType())) {
        deliveryMessage.setErrorType("PRODUCT ERROR");
    }

    rabbitTemplate.convertAndSend(
            errOrderQueue,
            deliveryMessage
    );
}

rollbackProduct()는 상품 처리 실패 또는 이후 단계의 오류 메시지를 처리한다.

먼저 다음 로그를 출력한다.

log.info("PRODUCT ROLLBACK!!!");

그다음 메시지의 errorType을 확인한다.

if (StringUtils.hasText(deliveryMessage.getErrorType())) {
    deliveryMessage.setErrorType("PRODUCT ERROR");
}

마지막으로 메시지를 errOrderQueue로 전송한다.

rabbitTemplate.convertAndSend(
        errOrderQueue,
        deliveryMessage
);

이를 통해 Product Service보다 이전 단계인 Order Service에 오류 사실을 전달한다.

현재 rollbackProduct()에는 실제 상품 재고를 복구하는 코드가 없다.

따라서 현재 메서드가 실제로 수행하는 역할은 다음과 같다.

오류 로그 출력
      ↓
오류 정보 확인 또는 변경
      ↓
errOrderQueue로 메시지 전달

즉, 현재 예제에서 rollbackProduct()는 실제 재고 복구 메서드라기보다 오류 메시지를 이전 단계로 전달하는 메서드에 가깝다.

ProductEndpoint와 ProductService의 책임 구분

구성 요소역할

ProductEndpoint	ProductQueue를 구독한다.
ProductEndpoint	정상 메시지와 오류 메시지를 수신한다.
ProductEndpoint	수신한 메시지를 ProductService에 전달한다.
ProductService	상품 ID와 상품 수량을 검증한다.
ProductService	정상 처리 시 메시지를 paymentQueue로 전달한다.
ProductService	오류 처리 시 메시지를 errOrderQueue로 전달한다.

ProductEndpoint는 RabbitMQ와 Product Service 사이를 연결하는 메시지 수신 계층이다.

ProductService는 메시지의 내용을 확인하고 정상 흐름으로 보낼지, 오류 흐름으로 보낼지를 결정하는 비즈니스 로직 계층이다.

정상 처리 흐름

정상적인 주문 처리 과정은 다음과 같다.

클라이언트가 주문 생성 요청을 보낸다.
OrderEndpoint가 HTTP 요청을 받는다.
OrderEndpoint가 OrderService.createOrder()를 호출한다.
OrderService가 Order 객체를 생성한다.
OrderService가 DeliveryMessage를 생성한다.
OrderService가 RabbitTemplate을 사용하여 메시지를 전송한다.
메시지가 productQueue에 저장된다.
ProductEndpoint.receiveMessage()가 메시지를 수신한다.
ProductEndpoint가 ProductService.reduceProductAmount()를 호출한다.
ProductService가 상품 ID와 상품 수량을 검증한다.
검증에 성공하면 메시지를 paymentQueue로 전송한다.
Payment Service가 메시지를 받아 다음 처리를 진행한다.

Client
  ↓ HTTP 요청
OrderEndpoint
  ↓
OrderService
  ↓ RabbitTemplate
RabbitMQ 기본 Exchange
  ↓
productQueue
  ↓ @RabbitListener
ProductEndpoint.receiveMessage()
  ↓
ProductService.reduceProductAmount()
  ↓ 상품 검증 성공
RabbitTemplate
  ↓
paymentQueue
  ↓
Payment Service

현재 convertAndSend(queueName, message) 방식은 직접 생성한 TopicExchange 이름을 지정하지 않는다.

따라서 이 메시지는 RabbitMQ의 기본 Exchange를 통해 Queue 이름과 같은 Routing Key를 사용하여 전달된다.

Product Service 자체에서 검증이 실패한 흐름

Product Service가 상품 정보를 검증하는 과정에서 오류를 발견한 경우이다.

예를 들어 상품 ID가 1이 아니거나 상품 수량이 1보다 크면 이 흐름이 실행된다.

productQueue
      ↓
ProductEndpoint.receiveMessage()
      ↓
ProductService.reduceProductAmount()
      ↓
상품 ID 또는 수량 검증 실패
      ↓
ProductService.rollbackProduct()
      ↓ RabbitTemplate
errOrderQueue
      ↓
Order Service

이 경우에는 errorProductQueue나 Error Exchange를 거치지 않는다.

ProductService가 직접 rollbackProduct()를 호출하여 errOrderQueue로 메시지를 전달한다.

정리

현재 코드에서 각 구성 요소의 역할은 다음과 같다.

ProductEndpoint

productQueue를 구독한다.
errorProductQueue를 구독한다.
RabbitMQ 메시지를 DeliveryMessage로 전달받는다.
정상 메시지는 reduceProductAmount()로 전달한다.
오류 메시지는 rollbackProduct()로 전달한다.
RabbitMQ 메시지를 소비하는 Consumer 역할을 한다.

ProductService

상품 ID와 상품 수량을 검증한다.
상품 검증에 성공하면 메시지를 paymentQueue로 전달한다.
상품 검증에 실패하면 메시지를 errOrderQueue로 전달한다.
이후 단계에서 오류가 돌아오면 해당 오류 메시지를 errOrderQueue로 전달한다.
메시지의 다음 처리 방향을 결정하는 비즈니스 로직 역할을 한다.

현재 예제에는 실제 데이터베이스의 재고 차감과 재고 복구 로직이 없다.

따라서 전체 흐름은 다음과 같이 이해하는 것이 정확하다.

Order Service
      ↓
productQueue
      ↓
ProductEndpoint
      ↓
ProductService
      ↓
상품 정보 검증
   ↙           ↘
성공             실패
 ↓                ↓
paymentQueue    errOrderQueue

Kafka란?

Kafka는 분산 이벤트 스트리밍 플랫폼(Distributed Event Streaming Platform) 으로, 대용량의 데이터를 실시간으로 수집하고 저장하며 처리하기 위해 사용된다.

RabbitMQ와 마찬가지로 Producer와 Consumer 구조를 사용하지만, Kafka는 이벤트 로그를 장기간 저장하고 여러 Consumer가 동일한 데이터를 반복해서 읽을 수 있는 구조라는 점에서 차이가 있다.

예를 들어 주문이 생성되면 Producer가 주문 이벤트를 Kafka의 Topic에 저장하고, 배송 서비스, 결제 서비스, 알림 서비스 등 여러 Consumer가 동일한 이벤트를 각각 읽어 자신의 작업을 수행할 수 있다.

Producer
    ↓
Kafka Topic
    ├── Delivery Service
    ├── Payment Service
    └── Notification Service

이처럼 Kafka는 여러 서비스가 하나의 이벤트를 공유해야 하는 이벤트 기반(Event-Driven) 시스템에서 많이 사용된다.

Kafka의 구성 요소

메시지(Message)

Kafka를 통해 전달되는 데이터 단위이다.

현재 프로젝트의 DeliveryMessage와 같은 객체가 하나의 메시지가 될 수 있으며, Producer가 생성하여 Topic에 저장한다.

Producer

메시지를 생성하여 Kafka의 Topic으로 전송하는 역할을 수행한다.

Producer는 Topic 이름을 지정하여 메시지를 전송하며, 필요에 따라 Key를 함께 전달할 수 있다.

Topic

Kafka에서 메시지를 저장하는 논리적인 공간이다.

RabbitMQ의 Queue와 비슷한 역할을 하지만, 여러 개의 Partition으로 구성될 수 있다는 차이가 있다.

Producer가 전송한 메시지는 Topic에 저장되고, Consumer는 Topic으로부터 메시지를 읽어 처리한다.

Partition

Topic을 물리적으로 분할한 단위이다.

각 Partition은 독립적으로 메시지를 저장하며, 메시지마다 Offset이라는 고유 번호를 가진다.

Partition을 여러 개로 구성하면 여러 Consumer가 동시에 메시지를 처리할 수 있어 높은 처리량을 제공한다.

Order Topic

Partition 0
Offset 0
Offset 1
Offset 2

Partition 1
Offset 0
Offset 1
Offset 2

Offset

Partition 안에서 메시지를 구분하는 번호이다.

Consumer는 자신이 어디까지 읽었는지 Offset을 기록하여 이후에는 다음 메시지부터 이어서 읽을 수 있다.

Key

메시지를 어느 Partition에 저장할지 결정하는 값이다.

같은 Key를 가진 메시지는 동일한 Partition으로 저장되므로 메시지의 순서를 유지할 수 있다.

예를 들어 주문 번호를 Key로 사용하면 같은 주문과 관련된 이벤트는 항상 동일한 Partition에 저장된다.

Consumer

Topic에 저장된 메시지를 읽어 처리하는 역할을 한다.

Kafka에서는 Consumer가 Offset을 기준으로 데이터를 읽으며, Consumer Group을 사용하여 여러 Consumer가 Partition을 나누어 처리할 수 있다.

이를 통해 하나의 Topic을 여러 Consumer가 병렬로 처리할 수 있다.

Broker

Kafka 서버를 의미한다.

Broker는 Topic과 Partition을 저장하고 Producer와 Consumer 사이에서 메시지를 전달하는 역할을 수행한다.

여러 Broker를 클러스터로 구성하면 높은 처리량과 장애 대응이 가능하다.

ZooKeeper

기존 Kafka에서는 Broker의 메타데이터 관리와 클러스터 관리를 위해 ZooKeeper를 사용하였다.

Broker의 상태를 관리하고 리더 선출 등의 역할을 담당하였다.

다만 최근 Kafka(KRaft 모드)에서는 ZooKeeper 없이도 클러스터를 구성할 수 있으며, 최신 버전에서는 ZooKeeper 사용이 점차 줄어들고 있다.

Kafka와 RabbitMQ의 차이점

항목	RabbitMQ	Kafka
목적	메시지 전달(Message Broker)에 중점	대용량 이벤트 스트리밍(Event Streaming)에 중점
메시지 저장 장소	Queue	Topic(Partition)
저장 방식	Consumer가 읽으면 일반적으로 Queue에서 제거	일정 기간 Topic에 저장되며 여러 Consumer가 반복해서 읽을 수 있음
메시지 지속성	주로 단기 저장(메모리 또는 디스크)	장기 저장(디스크 기반 로그)
메시지 순서	Queue 단위로 순서 보장	Partition 내부에서 순서 보장
병렬 처리	여러 Queue 또는 Consumer를 이용	여러 Partition을 이용한 병렬 처리
소비 방식	Consumer가 메시지를 가져가면 일반적으로 제거	Offset을 이용하여 원하는 위치부터 다시 읽을 수 있음
주요 사용 사례	작업 큐, 비동기 처리, 요청/응답, 마이크로서비스 간 메시지 전달	실시간 데이터 스트리밍, 로그 수집, 이벤트 소싱, 빅데이터 처리

RabbitMQ와 Kafka는 언제 사용할까?

RabbitMQ는 메시지를 안정적으로 전달하고 작업을 비동기로 처리하는 것에 강점이 있다.

예를 들어 주문 생성 후 재고 차감, 결제 요청, 이메일 발송과 같이 서비스 간 작업을 연결하는 경우 적합하다.

반면 Kafka는 대용량 이벤트를 저장하고 여러 서비스가 동시에 소비하는 구조에 적합하다.

예를 들어 사용자 행동 로그 분석, 실시간 모니터링, 이벤트 소싱(Event Sourcing), 데이터 파이프라인 구축과 같은 환경에서 많이 사용된다.

즉,

RabbitMQ는 "메시지를 안전하게 전달하는 것"에 초점을 둔 메시지 브로커이고,
Kafka는 "이벤트를 저장하고 실시간으로 처리하는 것"에 초점을 둔 분산 스트리밍 플랫폼이라고 이해하면 된다.

[내일배움캠프 사전캠프] 23회차 TIL(7/27 월) - 대규모 시스템 설계

taeyoon2 — Mon, 27 Jul 2026 15:22:50 +0900

대규모 시스템 설계

대규모 시스템에서는 많은 사용자의 요청을 안정적으로 처리하면서도 장애에 대응할 수 있는 구조를 설계해야 한다.

단순히 서버의 성능을 높이는 것뿐만 아니라 TPS, 캐싱, 데이터베이스 최적화, CQRS와 Event Sourcing, 모니터링 및 로깅, 배포 전략 등을 종합적으로 고려해야 한다.

1. TPS와 시스템 처리량

TPS(Transaction Per Second)란?

TPS는 1초 동안 처리할 수 있는 트랜잭션의 수를 의미하며, 시스템의 처리량을 나타내는 주요 성능 지표 중 하나이다.

예를 들어 특정 시간대에 초당 200건의 트랜잭션이 발생한다면 TPS는 약 200이라고 볼 수 있다.

여기서 주의할 점은 TPS가 동시 접속자 수 자체를 의미하는 것은 아니라는 점이다.

동시 접속자 수: 동시에 시스템을 이용하고 있는 사용자 수
TPS: 시스템이 초당 처리하는 트랜잭션 수

대규모 시스템을 설계할 때는 평소의 요청량뿐만 아니라 갑작스러운 트래픽 증가에도 대응할 수 있도록 여유 있게 시스템의 처리 용량을 설계해야 한다.

예를 들어 피크 시간대의 최대 TPS가 200이라고 예상한다면 정확히 200 TPS만 처리하도록 설계하기보다는, 장애 상황이나 트래픽 증가 등을 고려하여 150% 수준인 300 TPS 등을 목표 처리량으로 설정할 수 있다.

단, 150%가 반드시 정답인 것은 아니며 실제 서비스에서는 트래픽 패턴, 비용, SLA, 장애 대응 전략 등을 고려하여 목표 처리량을 결정해야 한다.

2. Cache와 Caching

Cache란?

Cache는 자주 사용하는 데이터를 원본 저장소보다 빠른 저장 공간에 임시로 보관하여, 동일한 데이터가 다시 필요할 때 빠르게 반환하기 위한 저장 공간이다.

DB에 반복적으로 접근하는 대신 Redis와 같은 In-Memory 저장소에 데이터를 저장하면 DB의 부하를 줄이고 응답 속도를 향상시킬 수 있다.

Caching이란?

Caching은 자주 사용하는 데이터를 Cache에 저장하고 필요할 때 Cache에서 데이터를 가져오는 일련의 방식을 의미한다.

대표적인 흐름은 다음과 같다.

Client
   ↓
Application
   ↓
Redis에 데이터가 있는지 확인
   ↓
┌──────────────────────────┐
│ Cache Hit                │
│ 데이터 존재 → 즉시 반환  │
└──────────────────────────┘

┌──────────────────────────┐
│ Cache Miss               │
│ 데이터 없음              │
└──────────────────────────┘
   ↓
Database 조회
   ↓
데이터 반환
   ↓
Redis Cache에 데이터 저장
   ↓
Client에게 반환

이러한 방식을 Cache-Aside 패턴이라고 한다.

애플리케이션이 먼저 Cache를 조회하고 데이터가 존재하면 바로 반환한다. 데이터가 존재하지 않으면 DB에서 데이터를 조회한 뒤 Redis에 저장하고 사용자에게 반환한다.

이후 동일한 데이터가 요청되면 DB까지 접근할 필요 없이 Redis에서 바로 반환할 수 있다.

Redis Cache 사용 시 주의사항

Redis를 사용한다고 항상 성능이 향상되는 것은 아니다. Redis 또한 하나의 외부 시스템이기 때문에 장애, 네트워크 지연, 메모리 부족 등을 고려해야 한다.

Connection Timeout

Redis 서버에 장애가 발생하거나 네트워크 문제가 생겼을 때 애플리케이션이 Redis의 응답을 무한정 기다려서는 안 된다.

예를 들어 Redis에 연결을 시도한 뒤 5초 동안 연결되지 않는다면 연결을 중단하도록 Connection Timeout을 설정할 수 있다.

Application
    ↓
Redis 연결 시도
    ↓
응답 없음
    ↓
설정한 Timeout 초과
    ↓
연결 실패 처리

이를 통해 Redis의 장애가 애플리케이션 전체의 응답 지연으로 이어지는 것을 방지할 수 있다.

또한 캐시가 필수 데이터 저장소가 아니라 성능 개선을 위한 보조 저장소라면 상황에 따라 다음과 같은 장애 대응도 고려할 수 있다.

Redis 조회
   ↓
Redis 장애
   ↓
Fallback
   ↓
DB 직접 조회

Redis 장애 하나가 전체 서비스 장애로 전파되지 않도록 설계하는 것이 중요하다.

TTL(Time To Live)

캐시 데이터에 만료 시간을 설정하지 않으면 Redis에 데이터가 계속 쌓이면서 메모리가 부족해질 수 있다.

따라서 캐시의 특성에 따라 TTL을 설정하여 일정 시간이 지난 데이터가 자동으로 제거되도록 할 수 있다.

Cache와 DB의 데이터 정합성

DB의 데이터가 변경되었는데 Redis에는 기존 데이터가 남아있을 수 있다.

Redis → 상품 가격 10,000원
DB    → 상품 가격 12,000원

이 상태에서 Redis 데이터를 반환하면 사용자는 오래된 데이터를 받게 된다.

따라서 DB의 데이터가 변경될 때 관련 캐시를 삭제하거나 갱신하는 Cache Invalidation 전략이 필요하다.

Redis 메모리 모니터링

Redis는 메모리를 기반으로 데이터를 저장하기 때문에 메모리 사용량 관리가 중요하다.

예를 들어 Redis의 최대 메모리를 50GB로 설정했다고 가정하자.

최대 Redis Memory → 50GB

30GB 이상 → Warning
40GB 이상 → Critical

실제 임계치는 서비스 환경에 맞게 설정해야 하지만, 일정 수준 이상의 메모리가 사용되었을 때 운영자에게 알림을 보내도록 구성할 수 있다.

대표적으로 다음과 같은 구조를 사용할 수 있다.

Redis
  ↓
Redis Exporter
  ↓
Prometheus
  ↓
Grafana / Alertmanager
  ↓
Slack / Email 등으로 운영자 알림

Redis에서는 used_memory, maxmemory 등의 지표를 통해 현재 메모리 사용량을 확인할 수 있다.

또한 단순히 알림만 설정하는 것이 아니라 Redis가 최대 메모리에 도달했을 때 어떻게 데이터를 처리할지도 결정해야 한다.

이를 위해 Redis의 maxmemory와 Eviction Policy를 설정할 수 있다.

Eviction Policy에 따라 메모리가 부족할 경우 TTL이나 사용 빈도 등을 기준으로 기존 데이터를 제거할 수 있다.

즉, Redis를 운영할 때는 장애 대응 + 메모리 모니터링 + TTL + Eviction Policy + 데이터 정합성을 함께 고려해야 한다.

3. 데이터베이스 쓰기 요청 최적화

대규모 시스템에서는 수많은 쓰기 요청이 동시에 DB에 전달될 수 있다.

모든 요청을 즉시 DB에서 처리하면 데이터베이스에 부하가 집중될 수 있기 때문에 비동기 처리, 배치 처리, DB 분산 등의 전략을 사용할 수 있다.

비동기 처리

요청을 받은 즉시 모든 작업을 완료하는 대신, 즉시 처리할 필요가 없는 작업을 별도로 처리하는 방식이다.

예를 들어 주문이 완료된 이후 이메일이나 알림을 보내야 한다고 생각해보자.

주문 요청
   ↓
주문 처리
   ↓
이벤트 / 메시지 발행
   ↓
사용자에게 주문 결과 반환

       동시에

메시지 소비
   ↓
이메일 / 알림 처리

사용자는 이메일 발송이 끝날 때까지 기다릴 필요가 없다.

Kafka, RabbitMQ와 같은 메시지 브로커를 이용하여 이러한 구조를 구현할 수 있다.

비동기 처리를 통해 요청의 응답 시간을 줄이고 특정 컴포넌트에 부하가 집중되는 것을 완화할 수 있다.

Batch 처리

데이터를 한 건씩 처리하는 대신 여러 데이터를 일정 단위로 묶어서 처리하는 방식이다.

1건 저장
1건 저장
1건 저장
1건 저장
...

보다 상황에 따라

데이터 수집
데이터 수집
데이터 수집
   ↓
일정 단위로 묶음
   ↓
Batch 처리

방식을 사용할 수 있다.

로그 집계, 통계 처리, 대량 데이터 처리 등 즉시 처리할 필요가 없는 작업에서 활용할 수 있다.

다만 모든 쓰기 작업을 Batch로 처리할 수 있는 것은 아니며 실시간성이 중요한 작업에서는 적합하지 않을 수 있다.

분산 DB

하나의 데이터베이스에 모든 읽기와 쓰기 요청이 집중되면 DB가 병목 지점이 될 수 있다.

따라서 데이터의 특성에 따라 여러 DB로 데이터를 분산하는 방법을 고려할 수 있다.

대표적인 방법으로 Sharding이 있다.

User ID 1 ~ 1,000,000
        ↓
      DB 1

User ID 1,000,001 ~ 2,000,000
        ↓
      DB 2

데이터와 요청을 여러 DB에 분산하여 하나의 DB에 부하가 집중되는 것을 줄일 수 있다.

하지만 데이터 분산 기준을 설계해야 하고, 여러 DB에 걸친 JOIN이나 트랜잭션이 복잡해질 수 있다는 단점이 있다.

4. Event Sourcing

Event Sourcing은 데이터의 현재 상태만 저장하는 대신 데이터의 상태 변화를 이벤트로 기록하고, 해당 이벤트들을 순차적으로 적용하여 현재 상태를 재구성할 수 있도록 하는 방식이다.

예를 들어 주문이 다음과 같이 진행되었다고 가정해보자.

1. 주문 생성됨
2. 결제 완료됨
3. 배송 시작됨
4. 배송 완료됨

일반적인 방식에서는 최종적으로 배송 완료라는 현재 상태를 저장하는 데 집중한다.

Event Sourcing에서는 주문 생성, 결제 완료, 배송 시작, 배송 완료라는 상태 변화 자체를 이벤트로 저장한다.

필요하다면 저장된 이벤트를 순서대로 재생(Replay)하여 특정 시점 또는 현재의 상태를 재구성할 수 있다.

단, Replay는 실제 결제나 배송 같은 외부 작업을 다시 실행한다는 의미가 아니라 저장된 이벤트를 적용하여 상태를 다시 만들어낸다는 의미이다.

Event Sourcing 주요 개념

이벤트(Event)
데이터의 상태 변화를 나타내는 기록이다.

예를 들어 OrderCreated, PaymentCompleted, OrderCancelled 등이 이벤트가 될 수 있다.

이벤트 스토어(Event Store)
발생한 이벤트들을 순서대로 저장하는 저장소이다.

애그리게이트(Aggregate)
도메인에서 일관성을 유지해야 하는 데이터와 행위를 하나의 단위로 묶은 개념이다. Event Sourcing에서는 자신의 이벤트 이력을 적용하여 현재 상태를 재구성할 수 있다.

커맨드(Command)
시스템 또는 Aggregate에게 특정 동작을 수행하도록 요청하는 명령이다.

CreateOrder Command
        ↓
Order Aggregate
        ↓
OrderCreated Event

Command는 "주문을 생성해라", Event는 "주문이 생성되었다"라는 차이가 있다.

프로젝션(Projection)
이벤트를 이용하여 조회에 적합한 Read Model을 생성하는 방식이다.

Event Store
    ↓
Projection
    ↓
Read Model
    ↓
조회용 DB

이벤트가 발생하면 이를 기반으로 읽기 전용 데이터를 업데이트하여 조회 성능을 최적화할 수 있다.

5. CQRS + Event Sourcing

CQRS(Command Query Responsibility Segregation)는 데이터를 변경하는 Command와 데이터를 조회하는 Query의 책임을 분리하는 패턴이다.

Event Sourcing과 함께 사용하면 다음과 같은 구조를 만들 수 있다.

             Command
                ↓
           Aggregate
                ↓
             Event
                ↓
          Event Store
                ↓
            Projection
                ↓
           Read Model
                ↓
              Query

쓰기 영역에서는 Command를 처리한 결과로 이벤트를 생성하고 Event Store에 저장한다.

조회 영역에서는 저장된 이벤트를 기반으로 Projection을 수행하여 조회에 최적화된 Read Model을 만든다.

CQRS와 Event Sourcing을 함께 사용할 때의 장점

첫 번째는 변경 이력을 추적하기 쉽다는 것이다.

Event Store에 모든 상태 변화가 기록되기 때문에 어떤 과정을 거쳐 현재 상태가 만들어졌는지 확인할 수 있다.

두 번째는 읽기와 쓰기를 각각 최적화할 수 있다는 것이다.

쓰기 모델은 데이터 변경과 일관성에 집중하고, 읽기 모델은 조회 성능에 맞게 별도로 구성할 수 있다.

세 번째는 다양한 Read Model을 만들 수 있다는 것이다.

하나의 이벤트를 이용하여 서로 다른 목적의 조회 데이터를 생성할 수 있다.

Order Event
   ├── 사용자 주문 내역
   ├── 관리자 주문 통계
   └── 일별 매출 데이터

네 번째는 이벤트를 이용하여 상태를 재구성할 수 있다는 것이다.

필요한 경우 저장된 이벤트를 Replay하여 상태나 Read Model을 다시 만들 수 있다.

단점

CQRS와 Event Sourcing은 강력하지만 모든 시스템에서 사용할 필요는 없다.

가장 큰 단점은 시스템의 복잡성이 크게 증가한다는 것이다.

Command, Event Store, Projection, Read Model 등을 별도로 설계해야 하며 일반적인 CRUD 방식보다 개발과 운영이 어려워질 수 있다.

또한 쓰기 모델에서 이벤트가 발생한 뒤 읽기 모델에 반영되기까지 약간의 시간 차이가 발생할 수 있다.

Command 처리 완료
      ↓
Event 발생
      ↓
Projection 처리 중...
      ↓
Read Model 반영

따라서 쓰기 모델과 읽기 모델 사이의 데이터 동기화와 최종적 일관성(Eventual Consistency)을 관리해야 한다.

6. 모니터링과 로깅

대규모 시스템에서 모니터링과 로깅은 시스템의 안정성과 성능을 유지하는 데 필수적인 역할을 한다.

Monitoring

모니터링은 애플리케이션, DB, Redis, 서버 등 각 컴포넌트의 상태와 성능 지표를 지속적으로 확인하는 것이다.

예를 들어 다음과 같은 지표를 확인할 수 있다.

CPU / Memory 사용량
TPS 및 요청 수
API 응답 시간
Error Rate
DB Connection 수
Redis Memory 사용량
Cache Hit / Miss 비율

이러한 주요 지표를 지속적으로 확인하고 이상 징후가 발견되면 운영자에게 알림을 보내도록 구성할 수 있다.

예를 들어 Redis 메모리가 일정 수준을 넘어가거나 API 오류율이 급격하게 증가하면 Slack이나 Email 등으로 알림을 보낼 수 있다.

이를 통해 시스템 상태를 실시간으로 파악하고 장애 발생 시 빠르게 대응할 수 있다.

Logging

로깅은 애플리케이션에서 발생한 주요 사건과 정보를 기록하는 것이다.

사용자 요청
↓
주문 생성
↓
결제 요청
↓
결제 실패
↓
Exception 발생

이러한 과정이 로그에 기록되어 있다면 장애 발생 시 어떤 요청에서 어떤 문제가 발생했는지 추적할 수 있다.

특히 MSA처럼 여러 서비스가 서로 통신하는 환경에서는 하나의 요청이 여러 서비스를 거칠 수 있기 때문에 Trace ID 등을 이용한 분산 추적(Distributed Tracing)도 중요하다.

Client
  ↓
Gateway
  ↓
Order Service
  ↓
Payment Service
  ↓
Delivery Service

동일한 Trace ID를 통해 하나의 요청 추적

7. 대규모 시스템의 배포 전략

서비스를 운영하면서 새로운 버전을 배포할 때 서버를 모두 종료하고 새로운 버전을 실행하면 서비스 중단 시간이 발생할 수 있다.

이를 최소화하기 위해 Canary, Blue-Green, Rolling 등의 배포 전략을 사용할 수 있다.

Canary 배포

새로운 버전을 전체 사용자에게 바로 제공하지 않고 일부 사용자 또는 일부 트래픽에 먼저 적용하는 방법이다.

전체 트래픽

95% → 기존 버전
 5% → 새로운 버전

새로운 버전에서 문제가 발생하지 않는지 확인한 뒤 점진적으로 새로운 버전의 트래픽 비율을 증가시킨다.

문제가 발생하면 새로운 버전으로 향하는 트래픽을 중단하여 영향을 최소화할 수 있다.

따라서 새로운 기능을 단계적으로 도입하고 실제 운영 환경에서 안정성을 검증할 수 있다는 장점이 있다.

Blue-Green 배포

동일한 서비스를 제공할 수 있는 두 개의 환경을 준비하는 방식이다.

Blue  → 현재 운영 버전
Green → 새로운 버전

새로운 버전을 Green 환경에 배포하고 테스트가 완료되면 트래픽을 Blue에서 Green으로 전환한다.

Before

Client
  ↓
Blue


After

Client
  ↓
Green

Green 환경에서 문제가 발생하면 트래픽을 다시 Blue 환경으로 전환하여 빠르게 롤백할 수 있다.

서비스를 중단하지 않고 새로운 버전으로 전환할 수 있다는 장점이 있지만, 두 개의 환경을 유지해야 하기 때문에 추가적인 인프라 비용이 발생할 수 있다.

Rolling 배포

여러 서버를 운영하고 있을 때 서버를 한 번에 모두 변경하지 않고 일부 서버부터 순차적으로 새로운 버전으로 업데이트하는 방법이다.

기존

Server A → v1
Server B → v1
Server C → v1


1단계

Server A → v2
Server B → v1
Server C → v1


2단계

Server A → v2
Server B → v2
Server C → v1


완료

Server A → v2
Server B → v2
Server C → v2

일부 서버가 계속 요청을 처리하기 때문에 서비스 중단을 최소화하면서 새로운 버전을 배포할 수 있다.

다만 배포가 진행되는 동안 구버전과 신버전이 동시에 실행되므로 두 버전 간 호환성을 고려해야 한다.

정리

대규모 시스템에서는 단순히 서버의 개수를 늘리는 것만으로 모든 문제를 해결할 수 없다.

TPS와 트래픽을 고려한 용량 설계를 시작으로 Redis와 같은 Cache를 통한 조회 성능 개선, 비동기 및 Batch 처리와 DB 분산을 통한 쓰기 성능 개선이 필요하다.

또한 복잡한 도메인에서는 CQRS와 Event Sourcing을 이용하여 읽기와 쓰기를 분리하고 변경 이력을 관리하는 방법을 고려할 수 있다.

운영 단계에서는 Monitoring과 Logging을 통해 장애를 빠르게 탐지하고 원인을 추적해야 하며, Canary, Blue-Green, Rolling과 같은 배포 전략을 통해 서비스 중단과 배포 위험을 최소화할 수 있다.

결국 대규모 시스템 설계의 핵심은 단순히 많은 요청을 처리하는 것을 넘어 성능, 확장성, 장애 대응, 데이터 일관성, 운영 안정성을 함께 고려하는 것이다.

예습

RabbitMQ 흐름
프로듀서가 메시지 생성 -> 익스체인지 -> 큐 -> 컨슈머가 메시지 처리

프로듀서가 메시지 생성 → 익스체인지가 메시지를 받음 → 라우팅 규칙에 따라 Queue로 전달 → Consumer가 Queue의 메시지를 처리

★ MSA 총 정리 ★

taeyoon2 — Sat, 25 Jul 2026 11:02:52 +0900

MSA(Microservices Architecture) 총정리

1. MSA란?

MSA(Microservices Architecture)는 하나의 큰 애플리케이션을 여러 개의 작고 독립적인 서비스로 분리하여 개발하는 아키텍처 방식이다.

각 서비스는 주문, 결제, 배송, 회원과 같이 특정 비즈니스 기능을 담당하며 독립적으로 개발, 배포, 확장할 수 있다.

예를 들어 쇼핑몰 서비스를 MSA로 구성한다면 다음과 같이 나눌 수 있다.

[회원 서비스]
[상품 서비스]
[주문 서비스]
[결제 서비스]
[배송 서비스]

각 서비스는 서로 독립적으로 동작하며 HTTP API, 메시지 브로커(Kafka, RabbitMQ) 등을 통해 통신한다.

MSA의 주요 특징

독립적인 배포: 특정 서비스만 수정하여 별도로 배포할 수 있다.
독립적인 확장: 트래픽이 많은 서비스만 서버를 추가하여 확장할 수 있다.
작은 단위의 서비스: 각 서비스가 하나의 비즈니스 기능을 중심으로 구성된다.
기술 스택의 다양성: 서비스 특성에 따라 서로 다른 기술이나 데이터베이스를 사용할 수 있다.
장애 격리: 하나의 서비스 장애가 전체 시스템 장애로 이어지지 않도록 설계할 수 있다.

반면 서비스가 많아지면서 서비스 간 통신, 장애 처리, 데이터 정합성, 모니터링, 배포 및 운영이 복잡해진다는 단점도 존재한다.

2. Spring Cloud

Spring Cloud는 Spring Boot 기반의 MSA를 구축할 때 필요한 여러 기능을 제공하는 프로젝트들의 집합이다.

MSA에서는 여러 서비스가 서로 통신하기 때문에 다음과 같은 문제를 해결해야 한다.

서비스의 위치는 어떻게 찾을까?
        ↓
Service Discovery

요청을 어떤 서버에 전달할까?
        ↓
Load Balancing

외부 요청을 어디로 받을까?
        ↓
API Gateway

다른 서비스에 장애가 발생하면?
        ↓
Circuit Breaker

여러 서비스의 설정은 어떻게 관리할까?
        ↓
Spring Cloud Config

요청이 여러 서비스를 거칠 때 어떻게 추적할까?
        ↓
Distributed Tracing

Spring Cloud는 이러한 분산 시스템의 문제를 해결하기 위한 다양한 기능을 제공한다.

3. Service Discovery - Eureka

MSA에서는 하나의 서비스가 여러 개의 인스턴스로 실행될 수 있다.

Product Service
 ├─ localhost:8081
 ├─ localhost:8082
 └─ localhost:8083

이때 다른 서비스가 모든 서버의 IP와 Port를 직접 알고 있는 것은 관리하기 어렵다.

Service Discovery는 서비스의 위치를 등록하고 필요한 서비스가 해당 위치를 동적으로 찾을 수 있도록 하는 방식이다.

Eureka

Eureka는 Netflix에서 개발한 Service Discovery 기술이다.

각 마이크로서비스는 Eureka Server에 자신의 위치를 등록한다.

Product Service ──┐
Order Service   ──┼──> Eureka Server
Payment Service ──┘

다른 서비스는 Eureka를 통해 필요한 서비스의 인스턴스 정보를 조회할 수 있다.

따라서 IP와 Port를 직접 관리하는 대신 PRODUCT-SERVICE와 같은 서비스 이름을 기반으로 통신할 수 있다.

4. Load Balancing

로드 밸런싱은 들어오는 요청을 여러 서버에 분산하여 특정 서버에 부하가 집중되지 않도록 하는 기술이다.

             ┌─> Product Server 1
Client ──────┼─> Product Server 2
             └─> Product Server 3

대표적인 로드 밸런싱 알고리즘에는 다음과 같은 방식이 있다.

Round Robin: 서버에 순서대로 요청을 전달한다.
Weighted: 서버 성능에 따라 가중치를 부여한다.
Least Connections: 현재 연결 수가 가장 적은 서버에 전달한다.
Response Time: 응답 시간이 빠른 서버를 선택한다.

Ribbon

Ribbon은 Netflix에서 개발한 클라이언트 사이드 로드 밸런서이다.

Eureka에서 서비스 인스턴스 목록을 가져온 후 요청을 전달할 서버를 선택하는 역할을 수행했다.

다만 Ribbon은 현재 유지보수가 중단된 레거시 기술이며, 최근 Spring Cloud에서는 Spring Cloud LoadBalancer를 사용한다.

5. FeignClient

FeignClient는 다른 마이크로서비스의 REST API를 선언적인 방식으로 호출할 수 있도록 도와주는 HTTP Client이다.

일반적인 HTTP 요청 코드를 직접 작성하는 대신 인터페이스와 어노테이션을 이용하여 다른 서비스를 호출할 수 있다.

Order Service
      │
      │ FeignClient
      ▼
Product Service

Eureka 및 Spring Cloud LoadBalancer와 함께 사용하면 서비스 이름을 기반으로 인스턴스를 찾고 요청을 분산할 수도 있다.

즉,

FeignClient
    ↓
Eureka에서 서비스 검색
    ↓
LoadBalancer가 인스턴스 선택
    ↓
해당 서비스 호출

과 같은 구조로 이해할 수 있다.

6. Circuit Breaker

MSA에서는 하나의 요청이 여러 서비스를 거칠 수 있다.

Order → Payment → Delivery → Notification

만약 Payment Service에 장애가 발생했는데 계속 요청을 보내면 요청이 쌓이면서 다른 서비스까지 영향을 받을 수 있다.

Circuit Breaker는 문제가 발생한 서비스에 대한 요청을 일정 시간 차단하여 장애가 다른 서비스로 전파되는 것을 방지하는 패턴이다.

Circuit Breaker의 상태

Closed → Open → Half-Open
   ↑                 │
   └─────────────────┘

Closed 상태에서는 정상적으로 요청을 전달한다. 일정 수준 이상의 실패가 발생하면 Open 상태가 되어 요청을 즉시 차단한다.

일정 시간이 지나면 Half-Open 상태가 되어 일부 요청을 보내 서비스가 복구되었는지 확인한다.

요청이 정상적으로 처리되면 다시 Closed 상태로 돌아가며, 계속 실패하면 다시 Open 상태가 된다.

Resilience4j

Resilience4j는 Java 기반의 경량 장애 대응 라이브러리로 Circuit Breaker를 비롯해 Retry, Rate Limiter, Time Limiter 등의 기능을 제공한다.

과거에는 Netflix의 Hystrix가 많이 사용되었지만 현재는 유지보수 모드에 들어갔으며, Spring 환경에서는 Resilience4j가 대표적으로 사용된다.

Fallback

Fallback은 다른 서비스 호출에 실패했을 때 실행하는 대체 로직이다.

Payment Service 호출
        ↓
       실패
        ↓
Fallback 실행
        ↓
대체 응답 반환

이를 통해 장애 상황에서도 사용자에게 일정한 응답을 제공할 수 있다.

7. API Gateway

MSA에서는 서비스마다 각각 다른 주소를 가지고 있을 수 있다.

회원 → /users
상품 → /products
주문 → /orders
결제 → /payments

클라이언트가 각각의 서비스 주소를 직접 알고 요청하면 서비스가 많아질수록 관리가 어려워진다.

API Gateway는 외부 요청을 받는 하나의 진입점 역할을 한다.

             Client
                │
                ▼
        [ API Gateway ]
          /     |     \
         ▼      ▼      ▼
      User   Order   Product

API Gateway는 요청 경로를 확인하여 적절한 마이크로서비스로 요청을 전달한다.

대표적으로 다음과 같은 기능을 수행할 수 있다.

Routing
인증 및 인가
요청/응답 필터링
로깅
모니터링
Rate Limiting

Spring 환경에서는 Spring Cloud Gateway를 사용할 수 있다.

과거에는 Netflix의 Zuul도 사용되었지만 현재 Spring Cloud 환경에서는 Spring Cloud Gateway를 사용하는 것이 일반적이다.

Gateway Filter

Spring Cloud Gateway에서는 요청과 응답을 가공하기 위해 Filter를 사용할 수 있다.

Global Filter는 모든 요청에 적용되고, Gateway Filter는 특정 Route에 적용된다.

또한 실행 시점에 따라 다음과 같이 생각할 수 있다.

Client
  ↓
Pre Filter
  ↓
Service
  ↓
Post Filter
  ↓
Client

Pre Filter에서는 인증, 요청 로그 등의 작업을 수행할 수 있고, Post Filter에서는 응답 처리 및 응답 로그 등의 작업을 수행할 수 있다.

8. OAuth2와 JWT

MSA 환경에서는 여러 서비스에 대한 인증과 인가를 효율적으로 처리하는 것도 중요하다.

OAuth2

OAuth 2.0은 애플리케이션이 사용자의 자격 증명 자체를 직접 공유하지 않고도 보호된 리소스에 접근할 수 있도록 권한을 위임하는 프레임워크이다.

대표적인 구성 요소는 다음과 같다.

Resource Owner
Client
Authorization Server
Resource Server

현재 일반적인 사용자 로그인 환경에서는 Authorization Code 방식이 주로 사용되며, 서버 간 통신에서는 Client Credentials 방식 등을 사용할 수 있다.

JWT

JWT(JSON Web Token)는 Claim 정보를 JSON 형태로 표현하는 토큰 형식이다.

JWT는 다음 세 부분으로 구성된다.

Header.Payload.Signature

Header: 토큰 타입과 서명 알고리즘
Payload: 사용자 정보 및 Claim
Signature: 토큰이 변조되지 않았는지 검증

주의할 점은 일반적인 JWT의 Payload가 암호화되는 것은 아니라는 것이다. JWT 서명은 주로 데이터의 무결성과 발급자 검증에 사용된다.

9. Spring Cloud Config

마이크로서비스가 많아지면 각각의 application.yml 설정을 관리하기 어려워진다.

User Service    → application.yml
Order Service   → application.yml
Payment Service → application.yml
Product Service → application.yml

Spring Cloud Config는 여러 마이크로서비스의 설정을 중앙에서 관리할 수 있도록 해준다.

              Config Server
             /      |       \
            ▼       ▼        ▼
         User     Order    Product

Git 저장소 등을 이용하여 환경별 설정을 중앙에서 관리할 수도 있다.

application-dev.yml
application-test.yml
application-prod.yml

Spring Cloud Bus와 메시지 브로커를 함께 사용하면 설정 변경 사항을 여러 서비스에 전파하는 구조도 구성할 수 있다.

10. 분산 추적 - Zipkin

MSA에서는 하나의 요청이 여러 서비스를 거치기 때문에 장애가 발생했을 때 어느 서비스에서 문제가 발생했는지 찾기 어려울 수 있다.

Client
  ↓
Gateway
  ↓
Order
  ↓
Payment
  ↓
Delivery

분산 추적(Distributed Tracing)은 하나의 요청이 여러 서비스를 이동하는 전체 과정을 추적하는 방식이다.

Zipkin은 이러한 Trace 정보를 수집하고 시각화하는 분산 추적 시스템이다.

Trace와 Span

Trace는 하나의 요청에 대한 전체 흐름이다.

Trace
 ├─ Span : Gateway
 ├─ Span : Order
 ├─ Span : Payment
 └─ Span : Delivery

Span은 Trace 내부에서 수행된 하나의 작업 단위를 의미한다.

이를 이용하면 각 서비스의 처리 시간과 호출 관계를 확인하여 어느 서비스에서 지연이나 오류가 발생했는지 파악할 수 있다.

11. Event-Driven Architecture

MSA에서는 서비스 간에 HTTP를 이용한 동기 통신뿐만 아니라 이벤트를 이용한 비동기 통신 방식도 사용할 수 있다.

동기 방식에서는 다른 서비스의 처리가 끝날 때까지 응답을 기다려야 하며, 특정 서비스에 장애가 발생하면 이를 호출하는 서비스에도 영향을 줄 수 있다.

주문 서비스
    ↓
결제 서비스
    ↓
배송 서비스
    ↓
알림 서비스

Event-Driven Architecture는 서비스가 다른 서비스를 직접 호출하는 대신 특정 상황이 발생했음을 나타내는 이벤트(Event)를 전달하는 방식이다.

예를 들어 주문이 완료되면 주문 서비스에서 주문 완료 이벤트를 발행하고, 해당 이벤트가 필요한 서비스들이 이를 전달받아 각자의 작업을 처리할 수 있다.

             "주문 완료" 이벤트
Order Service ────────────────> Message Broker
                                    │
                          ┌─────────┼─────────┐
                          ▼         ▼         ▼
                       Payment   Delivery   Notification

서비스 사이에서 이벤트를 전달하는 역할을 하는 것이 Message Broker이며, 대표적인 기술로 Kafka, RabbitMQ 등이 있다.

Event-Driven의 장점

느슨한 결합(Loose Coupling): 서비스가 서로를 직접 호출하는 구조를 줄일 수 있다.
비동기 처리: 다른 서비스의 작업이 끝날 때까지 기다리지 않고 각 서비스가 독립적으로 작업을 처리할 수 있다.
장애 격리: 하나의 서비스에 장애가 발생했을 때 다른 서비스까지 직접적인 영향을 받는 것을 줄일 수 있다.

Event-Driven Architecture에서는 메시지 처리 및 데이터 정합성 등 추가적으로 고려해야 할 부분도 존재한다.

Kafka와 같은 메시지 브로커에 대한 자세한 내용은 추후 학습하면서 정리해보려고 한다.

12. 전체 구조 정리

지금까지 학습한 내용을 간단한 MSA 구조로 나타내면 다음과 같다.

                         Client
                            │
                            ▼
                  ┌─────────────────┐
                  │   API Gateway   │
                  └─────────────────┘
                            │
               ┌────────────┼────────────┐
               ▼            ▼            ▼
          User Service  Order Service  Product Service
                            │
                      Feign Client
                            │
                    Service Discovery
                        (Eureka)
                            │
                     Load Balancer
                            │
                            ▼
                     Payment Service

각 구성 요소의 역할을 간단하게 정리하면 다음과 같다.

Eureka
→ 서비스의 위치를 등록하고 필요한 서비스를 찾을 수 있도록 한다.

Spring Cloud LoadBalancer
→ 여러 서비스 인스턴스에 요청을 분산한다.

FeignClient
→ 서비스 간 HTTP 통신을 간편하게 구현할 수 있도록 한다.

Spring Cloud Gateway
→ 외부 요청의 단일 진입점 역할을 하며 요청을 적절한 서비스로 전달한다.

Resilience4j
→ 특정 서비스의 장애가 다른 서비스로 전파되는 것을 방지한다.

Spring Cloud Config
→ 여러 마이크로서비스의 설정을 중앙에서 관리한다.

Zipkin
→ 하나의 요청이 여러 서비스를 거치는 과정을 추적한다.

추가적으로 서비스 간 결합도를 낮추거나 비동기 처리가 필요한 경우에는 다음과 같이 이벤트 기반 통신을 사용할 수도 있다.

Order Service
     │
   Event
     ▼
Message Broker
     │
     ▼
다른 마이크로서비스

Message Broker에는 Kafka, RabbitMQ 등의 기술이 있으며 자세한 내용은 추후 학습하면서 다룬다.

핵심 요약

MSA의 핵심은 단순히 하나의 애플리케이션을 여러 서버로 나누는 것이 아니다.

각각의 비즈니스 기능을 독립적인 서비스로 분리하고, 각 서비스가 독립적으로 개발·배포·확장될 수 있도록 만드는 것이 핵심이다.

하지만 서비스가 분리되면서 서비스 탐색, 서비스 간 통신, 로드 밸런싱, 장애 처리, 인증, 설정 관리, 모니터링과 같은 새로운 문제들이 발생한다.

Spring Cloud와 Eureka, Gateway, LoadBalancer, FeignClient, Resilience4j, Config 등의 기술은 이러한 MSA 환경의 문제를 해결하는 데 도움을 준다.

또한 필요에 따라 메시지 브로커를 활용한 Event-Driven Architecture를 적용하여 서비스 간의 결합도를 낮추고 비동기 통신을 구현할 수도 있다.

CQRS와 NoSQL의 정의 및 관계

taeyoon2 — Sat, 25 Jul 2026 00:03:34 +0900

CQRS란?

기존 단일 모델 방식의 한계

일반적인 애플리케이션에서는 하나의 데이터베이스와 모델을 사용해 읽기와 쓰기를 모두 처리한다.

서비스가 커질수록 다음과 같은 문제가 발생할 수 있다.

복잡한 JOIN: 정규화로 데이터가 여러 테이블에 나뉘어 있어 조회 시 여러 JOIN이 필요할 수 있다.
읽기와 쓰기의 요구사항 차이: 쓰기는 정합성과 트랜잭션이 중요하고, 읽기는 빠르고 간단한 조회가 중요하다.
스키마 변경 비용 증가: 하나의 모델을 읽기와 쓰기가 함께 사용하면 변경 시 영향을 받는 범위가 커질 수 있다.

CQRS란?

CQRS(Command Query Responsibility Segregation)는 데이터의 쓰기(Command)와 읽기(Query) 책임을 분리하는 패턴이다.

Command: Create, Update, Delete
Query: Read

이를 통해 Command는 데이터 정합성과 트랜잭션에 집중하고, Query는 조회 성능에 맞게 별도로 최적화할 수 있다.

CQRS의 4단계

CQRS는 읽기와 쓰기를 분리하는 정도에 따라 다음과 같이 발전시킬 수 있다.

1단계 - 모델만 분리

하나의 데이터베이스를 사용하지만 Command 모델과 Query 모델을 분리한다.

Command Model ─┐
               ├─ RDBMS
Query Model ───┘

저장소는 동일하기 때문에 구조가 비교적 단순하면서도 읽기와 쓰기의 책임을 분리할 수 있다.

2단계 - 읽기 복제본 분리

쓰기 DB와 읽기용 복제본을 분리한다.

Command → Primary DB
              │
           Replication
              ↓
Query   → Read Replica

Command는 Primary DB에서 처리하고 Query는 복제된 Read Replica에서 처리한다.

읽기 요청이 많을 때 조회 부하를 분산할 수 있다는 장점이 있다.

다만 복제에는 시간이 필요하기 때문에 Primary DB와 Read Replica 사이에 일시적인 데이터 차이가 발생할 수 있다.

3단계 - 이중 DB 분리

Command와 Query가 서로 다른 데이터베이스를 사용한다.

Command → RDBMS
             │
          동기화
             ↓
Query   → NoSQL

예를 들어 쓰기 측에서는 트랜잭션과 데이터 정합성이 중요한 MySQL과 같은 RDBMS를 사용하고, 읽기 측에서는 빠른 조회를 위한 Redis나 조회 형태에 맞게 데이터를 저장할 수 있는 MongoDB와 같은 NoSQL을 사용할 수 있다.

이때 쓰기 DB에서 발생한 변경 사항을 읽기 DB에 전달하기 위해 Kafka와 같은 메시지 브로커를 활용할 수 있다.

Command → MySQL(RDBMS)
             ↓
           Kafka
             ↓
Query → Redis / MongoDB(NoSQL)

즉, RDBMS는 쓰기와 데이터 정합성에 집중하고, Kafka는 데이터 변경 이벤트를 전달하며, Redis나 MongoDB와 같은 NoSQL은 조회에 최적화된 데이터를 제공하는 형태로 구성할 수 있다.

4단계 - Event Sourcing + 다중 View

Command 측의 현재 상태만 저장하는 것이 아니라 발생한 이벤트 자체를 Event Store에 저장한다.

Command
   ↓
Event Store
   │
   ├─→ 주문 조회 View
   ├─→ 통계 View
   └─→ 검색 View

예를 들어 주문 상태가 변경되었다면 최종 상태만 저장하는 것이 아니라 다음과 같은 이벤트를 저장한다.

OrderCreated
PaymentCompleted
OrderShipped

각 Query 모델은 필요한 이벤트를 바탕으로 자신에게 필요한 형태의 View(Read Model)를 구성한다.

따라서 하나의 이벤트 흐름을 이용해 목적이 서로 다른 여러 조회 모델을 만들 수 있다.

정리

단계구조핵심

1단계	모델 분리	Command / Query 모델 분리
2단계	읽기 복제본	Primary / Read Replica 분리
3단계	이중 DB	RDBMS / NoSQL 등 저장소 분리
4단계	Event Sourcing	Event Store + 다중 View

NoSQL이란?

NoSQL은 관계형 데이터베이스가 아닌 다양한 형태의 데이터베이스를 포괄하는 개념이다.

Document	MongoDB	JSON 형태 데이터, 조회 모델
Key-Value	Redis	캐시, 세션, 빠른 조회
Wide-Column	Cassandra	대규모 데이터, 로그
Graph	Neo4j	관계 데이터, SNS

RDBMS와 NoSQL

구조	Table	다양한 데이터 구조
스키마	비교적 엄격	비교적 유연
관계	JOIN 중심	비정규화 활용 가능
장점	정합성, 트랜잭션	유연성, 확장성
예시	MySQL	MongoDB, Redis

CQRS에서는 Command는 RDBMS, Query는 NoSQL처럼 서로 다른 DB를 사용할 수도 있다.

Query 전용 DB에 화면에서 필요한 데이터를 미리 구성하면 복잡한 JOIN을 줄이고 조회에 최적화된 구조를 만들 수 있다.

Consistency Gap

CQRS에서 Write DB와 Read DB를 분리하면 두 DB가 항상 동시에 변경되는 것은 아니다.

Write DB 저장
    ↓
이벤트 전달
    ↓
Read DB 반영

Write DB에는 변경됐지만 아직 Read DB에는 반영되지 않은 짧은 시간이 발생할 수 있다.

이를 Consistency Gap이라고 한다.

따라서 DB까지 분리하는 CQRS 3단계 이상부터 중요하게 고려해야 하는 문제이다.

일정 시간이 지나 두 데이터가 같아지는 방식을 최종적 일관성(Eventual Consistency)이라고 한다.

Write DB와 Read DB 동기화

대표적으로 두 가지 방법이 있다.

1. 이벤트 발행 + Outbox

애플리케이션에서 변경 사항을 도메인 이벤트로 발행한다.

OrderPlaced
PaymentApproved
OrderCancelled

비즈니스 의미가 명확하다는 장점이 있지만 이벤트를 생성하고 관리하는 코드가 필요하다.

2. CDC(Change Data Capture)

DB의 변경 로그를 감지하여 이벤트로 전달한다.

MySQL → binlog → Debezium → Kafka → Read DB

애플리케이션 코드 변경을 줄일 수 있어 기존 시스템에 적용하기 좋지만, 도메인 의미가 부족하다는 단점이 있다.

Event Sourcing

CQRS와 Event Sourcing은 서로 다른 패턴이다.

CQRS: 읽기와 쓰기의 책임을 분리한다.
Event Sourcing: 현재 상태 대신 상태를 만들어낸 이벤트를 저장한다.

일반적인 방식은 현재 상태를 저장한다.

장바구니
상품 A : 1개
상품 B : 1개

Event Sourcing은 상태가 변경된 과정을 저장한다.

상품 A 추가
상품 A 추가
상품 B 추가
상품 A 제거

이 이벤트들을 순서대로 적용하면 현재 상태를 만들 수 있다.

일반적인 방식 Event Sourcing

일반적인 방식	Event Sourcing
현재 상태 저장	이벤트 저장
과거 과정 확인 어려움	변경 과정 추적 가능
구조가 단순	구조가 복잡
일반적인 CRUD에 적합	이력 추적이 중요한 시스템에 유용

즉, CQRS는 읽기/쓰기의 분리, Event Sourcing은 상태 저장 방식의 변화라고 구분하면 된다.

[내일배움캠프 사전캠프] 22회차 TIL(7/24 금) - Spring Session, Redis Cache

taeyoon2 — Fri, 24 Jul 2026 15:54:15 +0900

Spring Session과 Redis를 활용한 세션 관리와 캐싱

웹 애플리케이션을 하나의 서버에서 운영할 때는 세션 관리가 비교적 간단하다. 하지만 서버가 여러 대로 늘어나면 사용자의 세션 정보를 어떻게 공유할 것인지에 대한 문제가 발생한다.

이번 글에서는 Spring Boot의 세션 관리부터 Sticky Session, Redis를 활용한 세션 공유, 그리고 Redis의 대표적인 캐싱 전략까지 정리해본다.

1. JSESSIONID와 HttpSession

일반적인 Spring Boot 애플리케이션에서 별도의 설정을 하지 않는다면 내장 Tomcat이 세션을 관리한다.

사용자가 처음 서버에 접근해 세션이 생성되면 서버는 사용자에게 JSESSIONID라는 값을 쿠키로 전달한다.

브라우저
   │
   │ 최초 요청
   ▼
Spring Boot / Tomcat
   │
   │ 세션 생성
   ▼
HttpSession

브라우저 ◀── JSESSIONID 쿠키 전달

이후 브라우저는 서버에 요청할 때 JSESSIONID 쿠키를 함께 전송한다.

Tomcat은 전달받은 JSESSIONID를 통해 해당 사용자의 세션을 찾아 사용한다.

즉,

JSESSIONID는 서버에 저장된 세션을 식별하기 위한 값이다.

여기서 주의할 점은 JSESSIONID 자체에 세션 데이터가 저장되는 것은 아니라는 것이다. 실제 세션 데이터는 서버에 저장되고, JSESSIONID는 해당 세션을 찾기 위한 식별자 역할을 한다.

2. 서버가 여러 대라면?

하나의 서버만 사용한다면 큰 문제가 없다.

하지만 서비스를 확장하여 다음과 같이 여러 서버를 사용한다고 생각해보자.

                 Load Balancer
                 /           \
                /             \
         Server A            Server B
          :8080                :8081
        Session A            Session B

사용자가 처음에는 Server A로 요청을 보내 세션을 생성했다고 가정한다.

그런데 다음 요청이 Server B로 전달된다면 문제가 발생한다.

Server A와 Server B가 각각 자신의 메모리에 세션 정보를 저장하고 있기 때문에 Server B는 Server A에서 만들어진 세션 정보를 알지 못한다.

따라서 여러 서버를 운영하는 환경에서는 세션 정보를 어떻게 관리할 것인지 고민해야 한다.

3. Sticky Session

이 문제를 해결하는 방법 중 하나가 Sticky Session이다.

Sticky Session은 Load Balancer가 특정 사용자의 요청을 처음 연결된 서버에 계속 전달하도록 하는 방식이다.

예를 들어 사용자의 첫 요청이 Server A로 전달되었다면 이후 요청도 계속 Server A로 전달한다.

사용자 A ──→ Load Balancer ──→ Server A
   │
   ├──────→ Load Balancer ──→ Server A
   │
   └──────→ Load Balancer ──→ Server A

이렇게 하면 Server A가 가지고 있는 세션 정보를 계속 사용할 수 있다.

Sticky Session의 한계

하지만 Sticky Session에도 문제가 있다.

특정 서버에 많은 사용자가 연결되면 요청이 한쪽 서버에 집중될 수 있다.

사용자 그룹 A ──→ Server A   요청 적음
사용자 그룹 B ──→ Server B   요청 매우 많음

Server A가 여유로운 상태라고 하더라도 사용자 그룹 B의 요청은 계속 Server B로 전달되기 때문에 부하가 균등하게 분산되지 않을 수 있다.

또 다른 문제는 서버 장애다.

세션이 Server B의 메모리에만 저장되어 있는 상황에서 Server B에 장애가 발생하면 해당 서버가 가지고 있던 세션 정보에 접근할 수 없게 된다.

4. 세션 정보를 서버 밖에서 관리하기

이러한 문제를 해결하는 방법 중 하나는 세션 정보를 외부의 공용 저장소에 저장하는 것이다.

                    Load Balancer
                    /          \
                   /            \
             Server A          Server B
                   \            /
                    \          /
                       Redis
                    Session Data

Server A와 Server B가 자신의 메모리에 세션을 따로 관리하는 것이 아니라 공통된 저장소에 세션 정보를 저장한다.

따라서 사용자의 요청이

첫 번째 요청 → Server A
두 번째 요청 → Server B
세 번째 요청 → Server A

처럼 서로 다른 서버로 전달되더라도 두 서버 모두 같은 세션 저장소를 사용하기 때문에 세션 정보를 유지할 수 있다.

Spring에서는 Spring Session을 사용하여 Redis 등을 세션 저장소로 사용할 수 있다.

외부 저장소를 사용하면 네트워크 통신이 추가되기 때문에 서버 메모리에 직접 접근하는 것보다 비용이 발생한다. 따라서 빠른 읽기/쓰기가 가능한 Redis와 같은 인메모리 데이터 저장소가 세션 저장소로 많이 활용된다.

5. Cache란?

Cache(캐시)란 자주 사용하는 데이터를 빠르게 접근할 수 있는 곳에 임시로 저장해두는 공간이다.

예를 들어 매번 데이터베이스에 다음 요청을 한다고 생각해보자.

Client
   ↓
Spring
   ↓
RDB
   ↓
Spring
   ↓
Client

조회가 매우 빈번한 데이터라면 매번 데이터베이스를 조회하는 것은 비효율적일 수 있다.

이때 Redis를 캐시로 사용하면 다음과 같은 구조를 만들 수 있다.

              ┌── Redis (Cache)
Spring ───────┤
              └── RDB (원본 데이터)

자주 조회되는 데이터를 Redis에 저장해두고 Redis에서 먼저 조회하면 데이터베이스의 부하와 응답 시간을 줄일 수 있다.

6. 캐싱(Caching)

캐싱은 자주 접근하는 데이터를 캐시에 저장하여 데이터 접근 속도를 높이고 원본 데이터 저장소의 부하를 줄이는 기법이다.

Redis는 데이터를 메모리에 저장하기 때문에 디스크 기반 데이터베이스보다 빠르게 데이터에 접근할 수 있어 캐시로 많이 사용된다.

다만 캐시는 기본적으로 언제든 사라질 수 있는 임시 데이터라고 생각하는 것이 좋다.

따라서 캐시에는 어떤 데이터를 저장할지, 얼마나 오래 저장할지, 언제 삭제할지 등을 결정하는 전략이 필요하다.

7. Cache Hit과 Cache Miss

캐시를 사용하면 크게 두 가지 상황이 발생한다.

Cache Hit

캐시에서 원하는 데이터를 찾은 경우다.

요청
 ↓
Cache
 ↓
데이터 존재!
 ↓
바로 반환

Cache Hit 비율이 높을수록 원본 데이터베이스에 접근하는 횟수를 줄일 수 있다.

Cache Miss

캐시에 원하는 데이터가 존재하지 않는 경우다.

요청
 ↓
Cache
 ↓
데이터 없음
 ↓
RDB 조회

이 경우 원본 데이터베이스에서 데이터를 가져와야 한다.

8. Eviction Policy

캐시는 메모리를 사용하기 때문에 데이터를 무한정 저장할 수 없다.

따라서 캐시 공간이 부족해지면 어떤 데이터를 제거할 것인지 결정하는 정책이 필요하다.

이를 Eviction Policy라고 한다.

Redis에서도 메모리가 설정된 한도에 도달했을 때 어떤 데이터를 제거할지 다양한 Eviction Policy를 설정할 수 있다.

9. 대표적인 캐싱 전략

Cache-Aside (Lazy Loading)

가장 대표적인 캐싱 전략 중 하나다.

데이터를 조회할 때 먼저 캐시를 확인한다.

데이터 조회
    ↓
Redis 확인
   /   \
 HIT    MISS
 ↓       ↓
반환    RDB 조회
          ↓
      Redis 저장
          ↓
         반환

캐시에 데이터가 존재하면 바로 반환하고, 없다면 원본 데이터베이스에서 데이터를 가져온 후 캐시에 저장한다.

장점

실제로 요청된 데이터만 캐시에 저장할 수 있다.
Cache Hit가 발생하면 빠르게 데이터를 조회할 수 있다.

단점

최초 요청은 Cache Miss이기 때문에 상대적으로 느리다.
원본 데이터가 변경되었는데 캐시가 갱신되지 않으면 오래된 데이터가 반환될 수 있다.

Write-Through

데이터를 작성할 때 캐시와 원본 저장소를 함께 갱신하는 방식이다.

데이터 변경
    ↓
  Cache
    ↓
   RDB

따라서 캐시와 원본 데이터의 일관성을 유지하기 쉽다.

장점

캐시와 원본 데이터의 일관성을 유지하기 쉽다.
조회 시 최신 데이터를 캐시에서 얻을 가능성이 높다.

단점

데이터를 저장할 때 캐시와 원본 저장소 모두에 쓰기 작업이 필요하다.
자주 조회되지 않는 데이터까지 캐시에 저장될 수 있다.

Write-Behind (Write-Back)

데이터를 우선 캐시에 기록하고, 일정 시간 또는 일정 조건에 따라 여러 변경 사항을 모아서 원본 데이터베이스에 반영하는 방식이다.

데이터 변경
    ↓
  Cache
    ↓
일정 시간 후
    ↓
   RDB

장점

쓰기 요청이 많은 환경에서 데이터베이스의 부하를 줄일 수 있다.
여러 쓰기 작업을 모아서 처리할 수 있다.

단점

캐시의 데이터가 데이터베이스에 반영되기 전에 장애가 발생하면 데이터가 유실될 위험이 있다.

정리

Spring Boot에서 기본적으로 세션은 Tomcat의 메모리에 저장된다. 단일 서버에서는 간단하지만 서버가 여러 대로 늘어나면 세션 공유 문제가 발생한다.

Sticky Session을 사용하면 사용자를 특정 서버에 고정할 수 있지만 부하 분산과 장애 대응 측면에서 한계가 존재한다.

이 때문에 여러 서버가 공통으로 접근할 수 있는 Redis 같은 외부 저장소에 세션을 저장하는 방법을 사용할 수 있다.

Redis는 세션 저장소뿐만 아니라 캐시로도 많이 사용되며, 캐시를 사용할 때는 단순히 데이터를 Redis에 넣는 것에서 끝나는 것이 아니라 Cache Hit/Miss, 데이터 일관성, TTL, Eviction Policy, Cache-Aside/Write-Through/Write-Behind 같은 전략을 함께 고려하는 것이 중요하다.

[내일배움캠프 사전캠프] 21회차 TIL(7/23 목) - Redis

taeyoon2 — Thu, 23 Jul 2026 15:31:06 +0900

Redis란?

Redis(Remote Dictionary Server)는 Key-Value 기반의 NoSQL 데이터베이스이다.

가장 큰 특징은 데이터를 디스크가 아닌 메모리(RAM)에 저장하는 In-Memory Database라는 점이다.
메모리에서 데이터를 읽고 쓰기 때문에 일반적인 데이터베이스보다 매우 빠른 속도를 제공한다.

Redis의 특징

In-Memory Database
- 데이터를 메모리(RAM)에 저장하여 매우 빠른 조회 및 저장이 가능하다.
- 기본적으로 메모리에 저장되므로 휘발성이지만, 필요에 따라 디스크에 데이터를 저장(Persistence)할 수도 있다.
Key-Value 구조
- Key를 통해 데이터를 저장하고 조회한다.
- SQL을 사용하지 않고 Key를 이용해 데이터를 관리한다.
다양한 자료구조 지원
- 단순 문자열(String)
- List
- Set
- Sorted Set
- Hash
- Stream 등 다양한 자료구조를 제공하여 상황에 맞게 사용할 수 있다.
빠른 데이터 처리
- 메모리 기반으로 동작하기 때문에 읽기(Read)와 쓰기(Write) 속도가 매우 빠르다.
- 데이터 변경이 자주 발생하는 기능에 적합하다.

Redis를 사용하는 이유

Redis는 빠른 속도가 필요한 기능이나 자주 변경되는 데이터를 처리할 때 많이 사용된다.

대표적인 활용 사례는 다음과 같다.

캐싱(Cache) : 자주 조회되는 데이터를 메모리에 저장하여 DB 부하 감소
세션 관리(Session Clustering) : 로그인 세션 저장 및 서버 간 세션 공유
리더보드(Leaderboard) : 게임 랭킹, 점수 순위 관리
방문자 수(Visitor Tracking) : 실시간 방문자 수 및 조회수 관리
실시간 데이터 처리 : 채팅, 알림, 실시간 통계 등

Redis 명령어

String

SET <key> <value>: key에 value 문자열 데이터를 저장
```
SET user:email djaxodbs0101@naver.com
```
GET <key>: key에 저장된 문자열 반환
```
GET user:email
```
INCR key: key에 저장된 데이터를 1 증가
```
INCR user:count
```
DECR key: key에 저장된 데이터를 1 감소
```
decr user:count
```
MSET: key value의 형태로 주어진 인자들을 각 key에 value를 저장함. 여러 개 가능
MGET: 주어진 모든 key에 해당하는 데이터 반환.

List

LPUSH, RPUSH: 리스트 왼쪽으로/ 리스트 오른쪽으로 value를 저장

LPUSH user:list bred
RPUSH user:list chad

LPOP, RPOP: key에 저장된 리스트 앞쪽 / 뒷쪽에서 값을 반환 및 제거
```
LPOP user:list
RPOP user:list
```
LLEN: key에 저장된 리스트의 길이를 반환
LRANGE key start end: key의 start부터 end까지의 원소를 반환

LLEN user:list
LRANGE user:list 0 3
LRANGE user:list 0 -1

Set: 문자열의 집합으로, 중복 허용x, 순서 존재 x

SADD: key에 저장된 집합에 value를 추가
SREM: key에 저장된 집합의 value를 제거
SMEMBERS: key에 저장된 집합의 모든 원소 반환
SISMEMBER: key에 저장된 집합에 value가 존재하는지 확인(true/false)
SCARD: key에 저장된 집합의 크기를 반환

SADD user:java alex  # [alex]
SADD user:java brad  # [alex, brad]
SADD user:java chad  # [alex, brad, chad]
SREM user:java alex  # [brad, chad]

SMEMBERS user:java        # [alex, brad, chad]
SISMEMBER user:java brad  # true
SISMEMBER user:java dave  # false

합집합, 교집합

SINTER key1 key2: key1와 key2에 저장된 집합들의 교집합 원소 반환
SUNION key1 key2: key1와 key2에 저장된 집합들의 합집합 원소 반환
SINTERCARD number key1 [key2 ...]: number개의 key에 저장된 집합들의 교집합 크기 반환

SINTER user:java user:python        # [alex]
SUNION user:java user:python        # [alex, brad, chad, dave]
SINTERCARD 2 user:java user:python  # 1

Hash: field - value 쌍으로 이루어진 자료형 // Map<String, Map<String, String>> 형식

HSET key field value [field value]: key의 Hash에 field에 value를 넣는다. 한번에 여러 개도 가능

HSET user:alex name alex age 25
HSET user:alex major CSE

HGET: key에 저장된 Hash의 field에 저장된 value를 반환. 없는 field의 경우 null 반환
```
HGET user:alex name
HGET user:alex age
```
HMGET: key에 저장된 Hash에서 복수의 field 에 저장된 value 반환
HGETALL: key에 저장된 Hash 전부 반환

HMGET user:alex age major
HGETALL user:alex

HKEYS: key에 저장된 Hash에 저장된 field를 전부 반환
HLEN: key에 저장된 Hash에 저장된 field 개수 반환
```
HKEYS user:alex
HLEN user:alex
```

Sorted Set: 정렬된 집합으로 중복되지 않은 데이터 + 점수로 저장함.

ZADD key score member [score member ...]: key의 Sorted Set에 score를 점수로 가진 member를 추가, 이미 있는member의 경우 새로운 score를 설정

ZADD user:ranks 10 alex
ZADD user:ranks 9 brad 11 chad

ZRANK: Set의 member 순위를 오름차순 기준으로 0부터 세서 반환
ZRANGE key start stop: Set의 member들을 Start부터 stop 순위까지 오름차순 기준으로 반환
ZREVRANK : Set의 member 순위를 내림차순으로 내림차순 기준으로 0에서 부터 세서 반환
ZREVRANGE key start stop: Set의 member 들을 start 부터 stop 순위까지 내림차순으로 반환
ZINCRBY key increment member: member의 score를 increment만큼 증가(음수 전달 시 감소)

ZRANK user:ranks alex
ZRANGE user:ranks 0 3
ZREVRANK user:ranks alex
ZREVRANGE user:ranks 0 4

그 외 공통 명령

DEL key: key 제거

DEL user:list
DEL user:email
DEL user:count

EXPIRE key seconds: key의 TTL을 seconds로 설정, seconds 초가 지나면 key 제거

EXPIRETIME key: key가 만료되는 시각을 Unix Timestamp로 반환

SET expirekey "to be expired"
EXPIRE expirekey 5
EXPIRETIME expirekey

KEYS * : 모든 Key 확인

FLUSHDB: 모든 Key 제거

RedisTemplate

Key를 직접 설정하고 자료형도 직접 선택해 가면서 Redis를 활용하기 위해서는 RedisTemplate을 사용하면 된다.

@Autowired
    private StringRedisTemplate stringRedisTemplate;

    @Test
    public void stringOpsTest(){
        ValueOperations<String, String> ops = stringRedisTemplate.opsForValue();
        //지금 RedisTemplate에 설정된 타입을 바탕으로 문자열 조작을 하기위한 메서드 설정
        // ValueOperations<String, String> 은 자바에서 key를 전달 할 때 문자열 타입으로

        ops.set("simplekey", "simplevalue");
        System.out.println(ops.get("simplekey"));

        SetOperations<String, String> setOps = stringRedisTemplate.opsForSet();
        //Redis에서는 set 이지만, Java로 넘어올 때는 String 사용
        setOps.add("hobbies", "games");
        setOps.add("hobbies", "coding", "alcohol", "games");
        System.out.println(setOps.size("hobbies"));

        stringRedisTemplate.expire("hobbies", 10, TimeUnit.SECONDS);
        stringRedisTemplate.delete("simplekey");
    }

RedisTemplate을 Bean으로 등록하는 이유

테스트에서 RedisTemplate<String, ItemDto>를 사용하려고 했는데 다음과 같은 오류가 발생했다.

No qualifying bean of type
'RedisTemplate<String, ItemDto>' available

원인

Spring Boot는 기본적으로 RedisTemplate<Object, Object> 또는 StringRedisTemplate만 자동으로 생성한다.

하지만 내가 사용하려는 타입은

RedisTemplate<String, ItemDto>

이므로 해당 Bean이 존재하지 않아 직접 등록해야 한다.

RedisConfig

@Configuration
public class RedisConfig {

    @Bean
    public RedisTemplate<String, ItemDto> itemRedisTemplate(
            RedisConnectionFactory connectionFactory) {

        RedisTemplate<String, ItemDto> template = new RedisTemplate<>();

        template.setConnectionFactory(connectionFactory);
        template.setKeySerializer(RedisSerializer.string());

        return template;
    }
}

코드 설명

@Configuration

Spring 설정 클래스임을 의미한다.
애플리케이션 실행 시 Spring이 읽어 Bean을 등록한다.

@Bean

메서드가 반환하는 객체를 Spring Bean으로 등록한다.
따라서 RedisTemplate<String, ItemDto>를 @Autowired로 주입받을 수 있다.

RedisConnectionFactory

Redis 서버와 연결 정보를 관리한다.
application.yml의 host, port, password 설정을 사용한다.

RedisTemplate<String, ItemDto>

Redis와 통신하는 객체이다.
String은 Key 타입, ItemDto는 Value 타입을 의미한다.

KeySerializer

template.setKeySerializer(RedisSerializer.string());

Key를 문자열 형태로 저장한다.
설정하지 않으면 JDK 직렬화가 사용되어 사람이 읽기 어려운 형태로 저장될 수 있다.

[내일배움캠프 사전캠프] 20회차 TIL(7/22 수) - Docker, Docker-Compose

taeyoon2 — Wed, 22 Jul 2026 15:59:01 +0900

Docker Image, Docker Container

Docker 이미지: Docker Container 서비스를 위한 이미지로, Container 런타임에 필요한 바이너리, 라이브러리 및 설정 값 등을 포함하고, 변경되는 상태값을 보유하지 않고 변하지 않는다. 따라서 불변성, 상태 저장이 없다.

Docker Image와 Docker Container의 관계

Image: 컨테이너에 대한 OS, Application, Library 등등의 정보를 담고 있음

Container: Image를 실행한 상태. 1개의 Image로부터 N개의 Container를 생성할 수 있는 1:N의 관계.

Dockerfile

Dockerfile: APP을 컨테이너로 만들 때 이미지를 만드는 용도로 사용된다. 이를 통해 앱이 필요로 하는 모든 것을 한 곳에 담을 수 있게 된다.

그리고 같은 앱 환경을 쉽게 만들 수 있으며, 앱을 만드는 과정을 자동화할 수 있다.

# Dockerfile 예시
FROM ubuntu:latest // FROM: 베이스 이미지 선택
MAINTAINER Your Name <your-email@example.com> // MAINTAINER: 이미지를 만든 사람의 정보를 입력
RUN apt-get update && apt-get install -y nginx // RUN: 이미지에 명령을 실행하여 파일을 추가하거나 삭제
COPY index.html /usr/share/nginx/html// COPY: 파일을 이미지에 복사
EXPOSE 80 // EXPOSE: 컨테이너가 노출할 포트 설정
CMD ["nginx", "-g", "daemon off;"] // CMD: 실행할 명령을 설정

이외의 명령어

LABEL: 이미지에 메타데이터를 추가 // LABEL purpose='nginx test'
ENTRYPOINT: 컨테이너 시작할 때 실행할 명령어를 입력 // ENTRYPOINT ["npm", "start"]
ENV: 환경 변수 설정 // ENV STAGE staging or ENV JAVA_HOME /usr/lib/jvm/java-8-oracle
WORKDIR: 작업 디렉터리 지정 // WORKDIR /app
USER: 사용자 설정 
//RUN ["useradd", "user"]
USER user
RUN ["/bin/bash, "-c", "ls"]

Docker Compose

Docker Compose: 여러 컨테이너를 더 쉽게 관리, 자동 설정, 확장, 보안 강화 등 여러 컨테이너를 한 파일에 적어서 관리 가능

Compose 파일은 앱이 필요로 하는 모든 서비스들(데이터베이스, 큐, 캐시, 웹 API 등)을 정리해 주고, docker compose up 명령어로 이 모든 것을 한 번에 시작 가능

Docker Compose는 기본적으로 새 브리지 네트워크를 생성하여 각 서비스 컨테이너를 그 네트워크에 연결함. 이 네트워크는 docker-compose.yml 파일에 정의된 모든 서비스가 서로 통신할 수 있도록 함.

장점

한번에 여러 컨테이너 설정 가능: YAML 파일 하나로 여러 컨테이너의 모든 환경을 설정하고 한 번에 실행 가능
빠른 서비스 실행
같은 네트워크에서 쉽게 연결 가능

version: '3'
services:
  web:
    image: nginx
    ports:
      - "8080:80"
  app:
    build: .
    ports:
      - "8081:8080"
    depends_on:
      - db
  db:
    image: postgres
    environment:
      POSTGRES_PASSWORD: example

- `version`: Docker Compose 파일의 버전을 지정합니다.
- `services`: 애플리케이션의 각 서비스를 정의합니다.
- `web`, `app`, `db`: 각각의 서비스 이름입니다.
- `image`: 서비스를 실행할 Docker 이미지를 지정합니다.
- `build`: Dockerfile이 있는 디렉토리 경로를 지정하여 이미지를 빌드합니다.
- `ports`: 호스트와 컨테이너 간의 포트를 매핑합니다.
- `depends_on`: 다른 서비스가 먼저 실행되어야 하는 순서를 지정합니다.
- `environment`: 컨테이너의 환경 변수를 설정합니다.

Docker compose 명령어

docker compose up: yml 파일에 정의된 서비스를 빌드하고 시작함.

docker compose down: 실행 중인 모든 서비스를 중지하고 컨테이너, 네트워크, 볼륨 등을 정리함.

CI/CD

CI: 개발자가 변경한 코드를 자주 통합하고, 이 코드가 전체 시스템과 잘 어우러지는지 자동으로 테스트하는 프로세스

CD: CI의 결과물을 사용자에게 자동으로 배포한느 프로세스를 포함함. 코드 변경이 통합되고 테스트를 통과하면, 이를 자동으로 스테이징 환경 또는 프로덕션 환경에 배포함.

장점

빠른 피드백
자동화된 프로세스
일관된 배포
높은 품질 유지
개발 속도 향상

CI/CD 도구

Github Actions CI/CD

Github Actions: Github에 내장된 CI/CD 도구로, YAML 파일을 사용하여 워크 플로우를 정의함.

Github 저장소와의 강력한 통합
다양한 이벤트 기반 트리거
풍부한 커뮤니티 및 Marketplace 지원
무료 사용 가능

Jenkins

오픈 소스 CI/CD 도구로, 플러그인을 통해 다양한 기능 확장 가능

대규모 프로젝트에 적합
분산 빌드 및 다중 플랫폼 지원
다양한 플러그인 지원

GitLab CI

GitLab과 통합된 CI/CD 도구로, GitLab 저장소를 기반으로 CI/CD 파이프라인을 설정

GitLab과의 통합
강력한 파이프라인 편집기 제공
자동화된 DevOps 수명 주기 관리
클라우드 및 온프레미스 모두 지원

Amazon ECS란?

Docker 애플리케이션을 쉽게배포하고 운영 할 수 있도록 지원하는 완전관리형 Container Orchestration 서비스

ECS 구성 요소

ECR: Docker image 저장소
ECS Cluster: 컨테이너를 실행하기 위한 Cluster로 여러 인스턴스로 이루어져 Docker Container가 분산 실행됨
ECS Server: Docker APP 실행 그룹
ECS Task: ECS Server에 실제로 실행되는 docker container들

[내일배움캠프 사전캠프] 19회차 TIL(7/21 화) - Docker Image, Container

taeyoon2 — Tue, 21 Jul 2026 16:07:57 +0900

도커(Docker): 애플리케이션을 쉽게 만들고, 테스트하고, 배포할 수 있게 도와주는 소프트웨어 플랫폼

도커 이미지(Image): 애플리케이션과 그 실행에 필요한 파일을 포함한 읽기 전용 템플릿으로 이미지 안에는 코드, 런타임, 라이브러리, 환경 변수, 구성 파일 등이 포함(상태 저장x, 불변성, 이미지 변경 필요 시, 새로운 이미지 생성 필요)
도커 컨테이너(Container): Docker 이미지를 실행한 상태를 의미함. Image는 정적인 템플릿이라면, Container는 실제 애플리케이션이 실행되는 동적인 환경(격리된 환경)
Dockerfile: 이미지를 생성하기 위한 스크립트로 이미지를 빌드하는데 필요한 명령어가 담긴 파일
Docker Hub: Docker Image를 공유하고 저장하는 중앙 저장소
볼륨(Volume): 컨테이너의 데이터를 지속적으로 저장할 수 있는 메커니즘(데이터를 컨테이너와 독립적으로 관리 가능)
네트워크(Network): 컨테이너 간 통신을 관리하는 방식
- Bridge Network: 기본적으로 사용하는 네트워크로 동일한 브리지 네트워크에 연결된 컨테이너들은 서로 통신할 수 있음.

Docker를 사용하면 좋은(효율적인) 상황

일관된 개발환경이 필요할 경우: 도커를 사용하면 모든 환경에서 동일한 컨테이너를 독립적으로 실행할 수 있어, 환경 차이로 인한 문제를 줄일 수 있음.
애플리케이션을 빠르게 배포하고 싶을 경우: 도커 이미지를 빌드하고 이를 컨테이너로 실행하면, 필요한 모든 구성 요소가 포함되어 있어 별도의 설치 과정 없이 바로 실행할 수 있어 빠르게 배포 가능
CI/CD 파이프라인을 구축할 경우: 도커는 CI/CD 파이프라인에 적합하다. 코드를 변경할 때마다 자동으로 빌드, 테스트, 배포할 수 있도록 설정할 수 있어서, 개발 주기를 단축하고 배포의 신뢰성을 높일 수 있음.
쿠버네티스(Kubernetes)와 함께 사용하고자 할 경우: 쿠버네티스는 컨테이너 오케스트레이션 도구로, 다수의 도커 컨테이너를 관리하고 자동 배포, 확장, 운영을 지원함. 따라서 도커 컨테이너를 쿠버네티스 클러스터에 배포하면, 애플리케이션의 가용성과 확장성을 높일 수 있음.

Docker 기본적인 명령어

이미지 빌드(Build): Docker build -t myapp:latest . (.은 현재 파일의 Dockerfile)
이미지 가져오기: docker pull postgres (도커 허브에서 이미지를 가져오는 명령어)
이미지 목록: docker images
이미지 삭제: docker rmi myapp:latest

도커 컨테이너 관련 명령어

컨테이너 실행(Run): docker run -d -p 8080:80 myapp:latest (-d: 컨테이너를 백그라운드에서 실행하여 프롬포트에서 실행 로그 안보이도록)
★컨테이너 내부 접속: docker exec -it 컨테이너 아이디 /bin/bash (-i: 컨테이너 내부에서 사용자 입력을 받을 수 있게 하는 표준 입력, -t: 가상 터미널 할당으로 컨테이너 내부에서 터미널 사용 가능)
실행중인 컨테이너 목록 보기: docker ps
모든 컨테이너 목록 보기: docker ps -a
중지된 컨테이너 중 마지막으로 실행된 컨테이너를 가장 먼저 나열: docker ps -al
컨테이너 중지(Stop): docker stop container_id
컨테이너 시작(Start): docker start container_id
컨테이너 삭제(Remove): docker rm 컨테이너 아이디

Docker 네트워크 및 볼륨 관련 명령어

네트워크 생성: docker network create mynetwork
네트워크 목록보기: docker network ls
네트워크 삭제: docker network rm mynetwork
볼륨 생성: docker volume create myvolme
볼륨 목록 보기: docker volume ls
몰륨 삭제: docker volume rm myvolume

[내일배움캠프 사전캠프] 18회차 TIL(7/16 목) - 스프링 컨테이너

taeyoon2 — Thu, 16 Jul 2026 15:45:53 +0900

1. Spring Bean(빈)

Bean이란 스프링 컨테이너가 객체를 생성(new)하고 관리하며, 필요한 곳에 자동으로 주입해주는 객체이다.

Bean 등록 방법

1) @Component 방식

내가 직접 만든 클래스를 Bean으로 등록할 때 사용한다.

@Service, @Repository, @Controller 모두 내부적으로 @Component를 포함하고 있다.

@Service
public class ProductService {
}

스프링이 실행되면 Component Scan을 통해 @Component 계열의 클래스를 찾아 Bean으로 등록한다.

2) @Configuration + @Bean 방식

수정할 수 없는 외부 라이브러리 클래스 등을 Bean으로 등록할 때 사용한다.

@Configuration
public class AppConfig {

    @Bean
    public Apple apple() {
        return new Apple();
    }
}

두 방식의 차이

구분	@Component	@Configuration + @Bean
사용 대상	내가 만든 클래스	외부 라이브러리 클래스
객체 생성	스프링이 생성	개발자가 직접 생성
Bean 이름	클래스명(memberService)	메서드명(apple)

2. 생성자 주입

Spring에서는 생성자 주입(Constructor Injection) 을 가장 권장한다.

@RequiredArgsConstructor를 사용하면 final 필드에 대한 생성자를 Lombok이 자동으로 생성해준다.

@Service
@RequiredArgsConstructor
public class ProductService {

    private final OrderRepository orderRepository;
    private final UserRepository userRepository;

}

장점

불변 객체 생성 가능
의존성 누락 방지
테스트가 쉬움

3. Singleton(싱글톤)

Spring Bean은 기본적으로 Singleton으로 관리된다.

즉, 사용자 1000명이 요청하더라도 객체는 하나만 생성되고 모두가 공유해서 사용한다.

잘못된 예

private int price;

필드에 상태를 저장하면 여러 사용자가 동시에 접근하면서 값이 변경될 수 있다.

올바른 예

@Service
@RequiredArgsConstructor
public class OrderService {

    private final OrderRepository orderRepository;

    public int order(String userName, int price) {

        int orderPrice = price;

        ...

    }
}

지역변수를 사용하면 요청마다 별도의 값이 생성되어 안전하다.

4. JPA 실행 구조

JPA가 실제 SQL을 실행하는 과정은 다음과 같다.

Repository
    ↓
Spring Data JPA
    ↓
JPA (표준 명세)
    ↓
Hibernate
    ↓
Database

Spring Data JPA : Repository 구현체를 자동 생성
JPA : 인터페이스(표준)
Hibernate : 실제 SQL 생성 및 실행

5. 엔티티 매핑

JPA는 엔티티 클래스를 DB 테이블과 매핑하여 관리한다.

@Entity
@Table(name = "products")
@Getter
@NoArgsConstructor(access = AccessLevel.PROTECTED)
public class Product {

    @Id
    @GeneratedValue(strategy = GenerationType.IDENTITY)
    private Long id;

    @Column(nullable = false)
    private String name;

}

주요 어노테이션

@Entity : JPA 엔티티
@Table : 테이블명 지정
@NoArgsConstructor(PROTECTED) : JPA 기본 생성자
@Id : 기본키(PK)
@GeneratedValue : PK 자동 생성(AUTO_INCREMENT)
@Column : 컬럼 옵션 지정

6. 영속성 컨텍스트(Persistence Context)

영속성 컨텍스트는 엔티티를 관리하는 공간(1차 캐시) 이다.

엔티티 상태

비영속(New) : 객체만 생성된 상태, DB와 관계 없음
영속(Managed) : 영속성 컨텍스트에서 관리되는 상태
준영속(Detached) : 영속성 컨텍스트에서 분리된 상태
삭제(Removed) : 삭제 예정 상태

Dirty Checking(변경 감지)

@Transactional 안에서 영속 상태의 엔티티를 수정하면 save()를 호출하지 않아도 변경 사항을 감지하여 트랜잭션 종료 시 자동으로 UPDATE SQL을 실행한다.

@Transactional
public void update() {

    Product product = repository.findById(id).get();

    product.changeName("사과");

}

→ save() 없이도 UPDATE가 수행된다.

7. 연관관계와 N+1 문제

회원과 주문처럼 엔티티는 서로 연관관계를 가진다.

@ManyToOne(fetch = FetchType.LAZY)
@JoinColumn(name = "member_id")
private Member member;

여기서 LAZY를 사용하면 실제 필요한 시점에 데이터를 조회한다.

N+1 문제

주문 목록 조회
↓
SELECT * FROM orders      (1번)

↓

for (Order order : orders) {
    order.getMember().getName();
}

↓

회원 조회 쿼리 N번 발생

총 1 + N번의 SQL이 실행된다.

예를 들어 주문이 10개라면

주문 조회 : 1번
회원 조회 : 10번

총 11번

이것이 N+1 문제이다.

해결 방법

필요한 연관 데이터를 처음부터 함께 조회한다.

@Query("""
SELECT o
FROM Order o
JOIN FETCH o.member
""")
List<Order> findAllWithMember();

또는

@EntityGraph(attributePaths = "member")

를 사용하여 한 번의 조회로 필요한 데이터를 가져올 수 있다.

★ 오늘 배운 점

Spring Bean은 스프링 컨테이너가 생성하고 관리하는 객체이다.
Bean 등록 방식에는 @Component와 @Configuration + @Bean이 있다.
Spring Bean은 기본적으로 Singleton으로 관리되므로 상태를 필드에 저장하지 않는 것이 중요하다.
JPA는 Repository → Spring Data JPA → JPA → Hibernate → DB 순서로 동작한다.
@Transactional에서는 Dirty Checking을 통해 save() 없이도 변경 사항이 반영된다.
LAZY 로딩은 성능 최적화에 유리하지만 N+1 문제가 발생할 수 있으며, Fetch Join이나 @EntityGraph를 사용해 해결할 수 있다.

[내일배움캠프 사전캠프] 17회차 TIL(7/15 수)

taeyoon2 — Wed, 15 Jul 2026 15:32:59 +0900

내가 맡은 파트 도메인 비즈니스 로직 개선 및 예외 처리 구조 개선

1. 기본 배송지 관리 로직 개선

문제 상황

배송지 도메인을 구현하면서 사용자는 하나의 기본 배송지만 유지해야 한다는 비즈니스 요구사항이 존재했다.

처음에는 단순히 배송지의 isDefault 값만 변경하면 된다고 생각했지만, 다음과 같은 문제가 발생할 수 있었다.

새로운 배송지를 기본 배송지로 지정했을 때 기존 기본 배송지가 유지되어 여러 개의 기본 배송지가 생성될 가능성
기본 배송지로 설정된 배송지를 삭제했을 때 사용자의 기본 배송지가 존재하지 않는 문제

따라서 기본 배송지 변경과 삭제 과정에서 데이터 정합성을 유지할 수 있는 로직이 필요했다.

2. 기본 배송지 변경 로직 구현

기본 배송지를 변경하는 경우 기존 기본 배송지를 먼저 확인하도록 구현했다.

기존 기본 배송지 조회:

findByUserAndIsDefault(address.getUser(), true)

기존 기본 배송지가 존재한다면:

oldAddress.updateDefault(false);

를 호출하여 기존 배송지를 기본 배송지에서 해제한 후 새로운 배송지를 기본 배송지로 변경하도록 처리했다.

이를 통해 사용자마다 하나의 기본 배송지만 유지되도록 구현했다.

3. 기본 배송지 삭제 처리

기본 배송지 삭제 시 단순히 삭제 처리만 진행하면 사용자의 기본 배송지가 사라지는 문제가 발생할 수 있었다.

따라서 삭제 대상 배송지가 기본 배송지인지 확인 후 처리하도록 구현했다.

삭제 처리:

address.markAsDeleted(userId);

삭제 대상이 기본 배송지인 경우:

findFirstByUserOrderByCreatedAtDesc()

를 통해 가장 최근 생성된 배송지를 조회하고 해당 배송지를 새로운 기본 배송지로 지정했다.

이를 통해 기본 배송지가 없는 상태를 방지하고 데이터 정합성을 유지할 수 있었다.

4. DTO 책임 분리 및 응답 구조 개선

문제 상황

기존에는 요청 DTO와 응답 DTO의 역할이 명확하게 분리되지 않았고, Entity 데이터를 DTO로 변환하는 과정에서 변환 로직이 Service 계층에 포함되는 문제가 있었다.

Service에서 비즈니스 로직과 DTO 변환 로직을 함께 처리하면서 코드의 책임이 분산되었다.

개선 방향

Request DTO와 Response DTO를 목적에 맞게 분리했다.

Request DTO

클라이언트 요청 데이터 관리

DeliveryRequestDto
DeliveryUpdateRequestDto

Response DTO

API 응답 데이터 관리

DeliveryResponseDto
DeliveryDetailResponseDto
DeliveryUpdateResponseDto

또한 Response DTO 내부에 from() 메서드를 추가하여 Entity → DTO 변환 책임을 DTO에서 관리하도록 개선했다.

이를 통해 Service 계층에서는 비즈니스 로직 처리에 집중할 수 있도록 구조를 개선했다.

5. Global Exception 구조 적용

문제 상황

예외 발생 시 각 Service에서 직접 예외 메시지를 관리하면서 예외 처리 방식이 일관되지 않은 문제가 있었다.

또한 프로젝트 규모가 커질수록 새로운 예외 추가 시 관리가 어려워질 가능성이 있었다.

개선 방향

Custom Exception과 GlobalExceptionHandler 구조를 적용했다.

구조:

Service
 ↓
CustomException 발생
 ↓
GlobalExceptionHandler 처리
 ↓
통일된 ErrorResponse 반환

ErrorCode Enum을 활용하여 예외 코드와 메시지를 중앙에서 관리하도록 구성했다.

적용 결과

예외 응답 형식 통일
중복된 예외 처리 코드 감소
비즈니스 로직과 예외 처리 책임 분리
새로운 예외 추가 및 수정 용이

6. 동시성 문제 고민

현재 기본 배송지 변경 로직은 단일 요청 기준에서는 데이터 정합성을 보장한다.

하지만 동시에 여러 요청이 발생하는 경우 Race Condition이 발생할 가능성이 있다.

예:

사용자가 동시에 두 개의 배송지를 기본 배송지로 변경 요청
두 요청 모두 기존 기본 배송지를 조회
서로 다른 배송지를 기본 배송지로 설정
결과적으로 하나 이상의 기본 배송지가 존재할 가능성

이를 해결하기 위해 추후:

Pessimistic Lock
DB Unique Constraint

등을 적용하여 동시성 문제를 개선할 예정이다.

배운 점

이번 작업을 통해 단순 CRUD 구현보다 중요한 것은 도메인의 비즈니스 규칙을 코드로 어떻게 보장하는가라는 점을 배웠다.

특히 기본 배송지처럼 하나의 상태만 유지되어야 하는 데이터는 단순한 필드 변경이 아니라 변경 과정 전체를 관리해야 한다는 것을 알게 되었다.

또한 DTO 변환 책임과 예외 처리 책임을 분리하면서 각 계층이 자신의 역할에 집중하는 구조가 유지보수성 향상에 중요하다는 것을 경험했다.

오늘의 정리

기본 배송지 변경/삭제 과정에서 데이터 정합성을 유지하는 비즈니스 로직 구현
DTO from() 메서드를 활용해 Entity → DTO 변환 책임 분리
CustomException + GlobalExceptionHandler를 적용하여 예외 처리 구조 개선
향후 Race Condition 해결을 위해 Lock 및 DB 제약 조건 적용 필요성 확인