오리토리의 개발공간

Spring Boot에 Kafka 적용하기 - 실전

오리토리 — Fri, 20 Jun 2025 17:56:09 +0900

앞에서는 Kafka의 개념에 대해서 정리했는데 Spring Boot 에 실제로 어떻게 적용해서 사용하는지 코드와 함께 정리해보려고 한다!

1. dependency & application.yml 추가

//kafka
implementation("org.springframework.kafka:spring-kafka")

bootstrap.servers 설정은 클라이언트가 접근하는 토픽 파티션의 메타데이터를 요청하기 위한 설정입니다.

  kafka:
    bootstrap-servers: localhost:29092

예를 들어 bootstrap-servers : broker1:9092,broker2:9092,broker3:9092 로 설정되어 있다면 클라이언트는 broker1:9092부터 메타데이터를 요청하고 실패하면 broker2:9092로 요청합니다.

※ kafka의 기본 포트는 9092이고, zookeeper의 기본 포트는 2181 임.

2. Config 설정

2-1. Producer

KafkaProdecerConfig는 실제 Kafka Broker에 메시지를 보내는 역할을 하는 KafkaTemplate를 구성하고 bean으로 등록하는 역할을 합니다.

KafkaTemplate는 Kafka에 메시지를 보내는 여러 메서드를 제공하며, 이 메서드를 사용하여 브로커로 메시지를 보내기 위해 직접 Kafka Producer API를 사용하는 대신, send 메서드를 통해 더 편리하고 간결한 코드로 메시지를 보낼 수 있습니다.

import org.apache.kafka.clients.producer.ProducerConfig;
import org.apache.kafka.common.serialization.StringSerializer;
import org.springframework.beans.factory.annotation.Value;
import org.springframework.context.annotation.Bean;
import org.springframework.context.annotation.Configuration;
import org.springframework.kafka.core.DefaultKafkaProducerFactory;
import org.springframework.kafka.core.KafkaTemplate;
import org.springframework.kafka.core.ProducerFactory;

import java.util.*;

@Configuration
public class KafkaProducerConfig {
    @Value("${spring.kafka.bootstrap-servers}")
    private String bootStrapServer;

    @Bean
    public ProducerFactory<String, String> producerFactory() {
        Map<String, Object> properties = new HashMap<>();
        properties.put(ProducerConfig.BOOTSTRAP_SERVERS_CONFIG, bootStrapServer);
        properties.put(ProducerConfig.KEY_SERIALIZER_CLASS_CONFIG, StringSerializer.class);
        properties.put(ProducerConfig.VALUE_SERIALIZER_CLASS_CONFIG, StringSerializer.class);

        return new DefaultKafkaProducerFactory<>(properties);
    }

    @Bean
    public KafkaTemplate<String, String> kafkaTemplate() {
        return new KafkaTemplate<>(producerFactory());
    }
}

- BOOTSTRAP_SERVER_CONFIG : Producer가 처음으로 연결할 Kafka 브로커의 위치를 설정합니다.

- KEY_SERIALIZER_CLASS_CONFIG/VALUE_SERIALIZER_CLASS_CONFIG : 카프카에서 데이터를 보낼 때 key/value를 직렬화 합니다. 여기서 key와 value는 뒤에서 살펴볼 Kafka Template의 key,value 를 의미합니다.
개발 상황에 맞춰서 작성하면 되는데, 작성자는 메시지가 문자열 데이터이고, 넘겨줄 데이터도 문자열이므로 StringDeserializer를 사용했습니다.

2-2. Consumer

KafkaConsumerConfig 는 ConcurrentKafkaListenerContainerFactory 클래스를 생성하고 ConsumerFactory 인터페이스를 내부 멤버변수에 set 하고 bean 으로 등록하는 역할을 합니다.

ConcurrentKafkaListenerContainerFactory는 Spring의 @KafkaListener 어노테이션이 붙은 메서드에 주입되어 사용되며, 메시지를 동시에 처리할 수 있는 메시지 리스터 컨테이너를 생성합니다.

import org.apache.kafka.clients.consumer.ConsumerConfig;
import org.apache.kafka.common.serialization.StringDeserializer;
import org.springframework.beans.factory.annotation.Value;
import org.springframework.context.annotation.Bean;
import org.springframework.context.annotation.Configuration;
import org.springframework.kafka.config.ConcurrentKafkaListenerContainerFactory;
import org.springframework.kafka.core.ConsumerFactory;
import org.springframework.kafka.core.DefaultKafkaConsumerFactory;

import java.util.*;

@Configuration
public class KafkaConsumerConfig {
    @Value("${spring.kafka.bootstrap-servers}")
    private String bootStrapServer;

    @Bean
    public ConsumerFactory<String, Object> consumerFactory() {
        Map<String, Object> config = new HashMap<>();
        config.put(ConsumerConfig.BOOTSTRAP_SERVERS_CONFIG, bootStrapServer);
        config.put(ConsumerConfig.GROUP_ID_CONFIG, "notification-consumer-group");
        config.put(ConsumerConfig.KEY_DESERIALIZER_CLASS_CONFIG, StringDeserializer.class);
        config.put(ConsumerConfig.VALUE_DESERIALIZER_CLASS_CONFIG, StringDeserializer.class);

        return new DefaultKafkaConsumerFactory<>(config);
    }

    @Bean
    public ConcurrentKafkaListenerContainerFactory<String, Object> kafkaListenerContainerFactory() {
        ConcurrentKafkaListenerContainerFactory<String, Object> factory = new ConcurrentKafkaListenerContainerFactory<>();
        factory.setConsumerFactory(consumerFactory());

        return factory;
    }
}

- KEY_DESERIALIZER_CLASS_CONFIG / VALUE_DESERIALIZER_CLASS_CONFIG : 카프카에서 데이터를 받아올 때 key/value 를 역직렬화 합니다. producer에서 살펴본 KEY_SERIALIZER_CLASS_CONFIG / VALUE_SERIALIZER_CLASS_CONFIG 와 동일한 내용입니다.

- GROUP_ID_CONFIG : 컨슈머는 컨슈머 그룹이 존재하기 때문에 유일하게 식별 가능한 컨슈머 그룹을 작성합니다. Consumer 그룹은 같은 토픽을 소비하는 Consumer들의 그룹으로, 그룹 내의 모든 Consumer는 토픽의 서로 다른 파티션에서 메시지를 읽습니다. 이를 통해 메시지 처리를 병렬화 하여 처리 속도를 향상시킬 수 있으며, Consumer 가 실패할 경우 다른 Consumer가 해당 Consumer의 파티션을 처리하여 고가용성을 제공할 수 있습니다.

3. Controller

3-1. KafkaController

Srping Boot 어플리케이션에서 kafka메시지를 전송하기 위한 REST API 컨트롤러 역할을 합니다.

import •••.NoticeSendRequest;

import io.swagger.v3.oas.annotations.Operation;
import io.swagger.v3.oas.annotations.tags.Tag;
import lombok.RequiredArgsConstructor;
import org.springframework.web.bind.annotation.PostMapping;
import org.springframework.web.bind.annotation.RequestBody;
import org.springframework.web.bind.annotation.RequestMapping;
import org.springframework.web.bind.annotation.RestController;

@Tag(name = "알림")
@RestController
@RequestMapping("/api/internal/notice")
@RequiredArgsConstructor
public class KafkaController {

    private final KafkaService kafkaService;

    @Operation(summary = "메시지 전송")
    @PostMapping("/send")
    public void sendMessage(@RequestBody NoticeSendRequest noticeSendRequest){

        kafkaService.processNotificationEvent(noticeSendRequest);
    }
}

3-2.KafkaService

kafkaTemplate를 이용해서 kafka broker로 전송하는 역할을 합니다.

kafkaTemplate는 앞에서 설정 해 둔 , KafkaProdecerConfig에서 설정한 KafkaTemplate와 타입을 맞춰줘야 합니다.

import •••.NoticeSendRequest;

import lombok.extern.slf4j.Slf4j;
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.kafka.core.KafkaTemplate;
import org.springframework.stereotype.Component;

@Component
@Slf4j
public class KafkaService {

   private final KafkaTemplate<String, String> kafkaTemplate;

    public KafkaService(KafkaTemplate<String, String> kafkaTemplate) {
        
        this.kafkaTemplate = kafkaTemplate;
    }

    public void processNotificationEvent(NoticeSendRequest noticeSendRequest) {

        // 템플릿 조회, FCM 메시지 생성 및 전송
        kafkaTemplate.send("notification-event-topic", noticeSendRequest.getNickname() + " 님으로부터 급여가 입금됐어요.");
    }
}

3-3. KafkaConsumerService

KafkaConsumerService는 Kafka 메시지를 소비하는 역할을 합니다. Kafka 토픽에서 메시지를 수신하고 처리하기 위한 리스너로 설정되어 있습니다.

@KafkaListener 어노테이션을 통해 kafka 리스너로 지정하여 특정 kafka topic 으로부터 메시지를 수신하는 역할을 합니다. 속성에 구독하는 Topic과 해당 Consumer가 속하는 Group Id를 설정 해주면 됩니다.

import lombok.RequiredArgsConstructor;
import lombok.extern.slf4j.Slf4j;
import org.springframework.kafka.annotation.KafkaListener;
import org.springframework.stereotype.Component;

/**
 *
 * 알림 메시지를 Kafka로 처리
 * */
@Slf4j
@RequiredArgsConstructor
@Component
public class KafkaConsumerService {
    @KafkaListener(
            topics = "notification-event-topic",
            groupId = "notification-consumer-group",
            containerFactory = "kafkaListenerContainerFactory"
    )
    public void processNotificationEvent(String message) {
        // 템플릿 조회, FCM 메시지 생성 및 전송
        System.out.println("Consumed Message : " + message);
        log.info("Consumer User : " + message);
    }
}

4. 결과 확인

4-1. Window로 실행시키기

아래의 블로그를 참고하여 작성하였습니다. 자세하게 설명되어 있으니 참고 바랍니다!

https://syk531.tistory.com/47

[Apache Kafka] 설치 및 실행

개요 Apache Kafka는 대규모 실시간 데이터 스트리밍 및 메시징 플랫폼입니다. 이는 대량의 데이터를 안정적으로 처리하고, 여러 시스템 간에 데이터를 신속하게 전송하고, 실시간으로 데이터를 처

syk531.tistory.com

Kafka 설치

Kafka 공식 홈페이지에서 최신버전의 Kafka를 다운로드 받는다.

Binary 파일을 실행시켜줘야 하므로 Scala 2.13 - kafka_2.13-3.9.1.tgz 파일을 다운받아 줍니다.

다운받은 파일을 적당한 위치로 옮긴 후 압축을 풀어줍니다.

압축을 푼 폴더에 bin 폴더에는 리눅스 환경일 경우 실행할 bin 파일들이 있고 bin 폴더에서 windows 폴더로 들어가면 windows 환경에 실행할 bat 파일들이 있습니다.

Kafka 실행

실행 및 테스트는 zookeeper와 kafka를 실행하고 producer로 메세지를 전송하고 consumer에 메세지가 전달되는지 확인해보면 됩니다. 실행할 파일들은 아래와 같습니다.

zookeeper-server-start.bat : zookeeper 실행
kafka-server-start.bat : kafka 실행
kafka-console-producer.bat : console에서 kafka로 메세지를 전달할수 있게 해줌(producer 역활)
kafka-console-consumer.bat : producer에서 전달한 메세지를 kafka에 요청해서 console에 노출(소비)해줌(consumer 역활)

경로 : kafka_2.13-3.9.0\bin\windows

▶️ cmd창에 zookeeper 실행

.\zookeeper-server-start.bat ..\..\config\zookeeper.properties

▶️ 새로운 cmd창을 열어(zookeeper 가 실행중인 cmd창은 그대로 두고) kafka server 실행

.\kafka-server-start.bat ..\..\config\server.properties

▶️consumer 서버와 producer 서버는 실행 시킬 필요가 없다. 왜냐하면 consumer 와 producer 를 Bean으로 등록해 두었기 때문에 2개의 서버만 실행 시킨 후 메시지를 확인 해 볼 수 있다.

결과확인

KakfaConsumerService 에 정의해놓은 log 를 확인 해 볼 수 있다.

추가적으로 consumer 서버를 실행 시켜서 메시지가 잘 전달 된건지 확인 해보면

▶️ 새로운 cmd 창을 열어 consumer 서버 실행

.\kafka-console-consumer.bat --bootstrap-server localhost:9092 --topic notification-event-topic --from-beginning

한글은 지원하지 않아서 깨지긴 하지만, 아래와 같이 메시지가 소비 된 것을 확인 해 볼 수 있다.

4-2. kafka 를 docker 컨테이너로 실행시키기

docker에서 kafka를 띄우는 가장 간단한 방법은 docker-compose를 사용 하는 것입니다. 그래서 docker-compose를 사용하여 서버를 올려보도록 하겠습니다.

적당한 경로에 해당 yml 파일을 추가합니다. 저는 열어놓은 프로젝트의 경로에 추가해두었습니다.

위에서 cmd 창으로 테스트 해볼 때는 kafka 의 default 포트인 9092로 해서 테스트 해보았지만, docker 로 서버를 올릴 때는 프로젝트가 실행되는 kafka의 서버 포트가 29092로 되어 있어서 해당 포트로 설정해보겠습니다. (현재 kafka.boostrap-server : localhost:29092)

※ 각자의 프로젝트 환경에 맞춰서 포트를 설정하면 됨.

version: '3.8'
services:
  zookeeper:
    image: confluentinc/cp-zookeeper:7.5.0
    container_name: zookeeper
    ports:
      - "2181:2181"
    environment:
      ZOOKEEPER_CLIENT_PORT: 2181
      ZOOKEEPER_TICK_TIME: 2000
    networks:
      - kafka-net  # ✅ 여기에 추가

  kafka:
    image: confluentinc/cp-kafka:7.5.0
    container_name: kafka
    ports:
      - "29092:29092"                    # 외부에서 접근 가능한 포트
    depends_on:
      - zookeeper # zookeeper 서비스가 먼저 시작된 후에 kafka가 시작되도록 의존성을 설정합니다.
    environment:
      KAFKA_BROKER_ID: 1
      KAFKA_ZOOKEEPER_CONNECT: zookeeper:2181
      # 클라이언트에게 공개할 리스너 주소
      # PLAINTEXT://kafka:9092 ➡️ 브로커 간의 통신 포트 (내부)
      # PLAINTEXT_HOST://localhost:29092 ➡️ Spring Boot 에서 kafka 브로커로 통신 포트 (외부)
      KAFKA_ADVERTISED_LISTENERS: PLAINTEXT://kafka:9092,PLAINTEXT_HOST://localhost:29092
      # 리스너별 보안 프로토콜 매핑
      KAFKA_LISTENER_SECURITY_PROTOCOL_MAP: PLAINTEXT:PLAINTEXT,PLAINTEXT_HOST:PLAINTEXT
      # 브로커 간 통신용 리스너 이름
      KAFKA_INTER_BROKER_LISTENER_NAME: PLAINTEXT
    networks:
      - kafka-net

설정에 대한 자세한 설명은 아래 블로그 참고!

https://adjh54.tistory.com/637

[Docker] Docker Compose를 이용한 Apache Kafka 환경 구성 방법 -1 : KRaft, Kafka-ui

해당 글에서는 Docker Compose를 통해서 Apache Kafka(KRaft), Kafka-ui 구성하는 방법에 대해 알아봅니다 [참고] 이전에 작성한 Docker 관련 글들을 읽으시면 도움이 됩니다.분류설명링크이해하기Docker 환

adjh54.tistory.com

https://redhat-developer-demos.github.io/kafka-tutorial/kafka-tutorial/1.0.x/08-kafka-listeners.html

코드 기반으로 설명하자면, Host Machine = Spring Boot 애플리케이션이 동작하는 환경.

즉, Spring Boot 가 Producer 의 역할을 수행하고 있는 것이며 Docker 컨테이너 안에 있는 Kafka Broker 에 접근하기 위한 포트를 29092로 설정한 것이다.

그리고 Docker 내부에서 접근할 때는 9092 포트를 사용한다.

※ 접근방식의 차이를 설명하기 위해 Docker 내부에 Producer 가 있는 거처럼 묘사를 하였지만 실제로는 개발 환경에 따라 차이가 존재한다.

이렇게 설정하고 실행을 하게 되면 위에서처럼 KakfaConsumerService에 정의해둔 log를 콘솔에 찍힐 것이라고 기대했지만 찍히지 않는 문제가 발생하였다..

알고보니 메시지를 소비할 때 "Replication factor: 3 larger than available brokers: 1." 라는 오류가 발생하고 있었고, 이 오류는 로컬 환경에서 흔히 발생 되는 오류라고 한다. 그래서 replication factor 기본값을 낮춤으로써 문제를 해결하였다.

의심1.

kafka 서버를 실행시키면 "Connection to kafka:9092 failed" 와 같은 경고가 보인다. 혹시나 이거 때문에 @KafkaListener 가 실행되지 않는 것인가 싶었지만 실제로 프로젝트를 실행 시켰을 때 정상적으로 되면 무시해도 되는 오류라고 한다..

통신이 안되면 KAFKA_LISTENERS 를 추가해서 명확하게 지정해 보는 것을 시도!

KAFKA_LISTENERS: PLAINTEXT://0.0.0.0:9092,PLAINTEXT_HOST://0.0.0.0:29092

의심2.

오류 내용은 Replication factor 3을 요청했는데, 브로커는 1개만 실행 중이라는 뜻으로 카프카가 내부에서 관리용 토픽(예: __consumer_offsets)을 만들 때 복제본을 3개 만들려고 했지만, 브로커가 1개라 실패 했다는 것을 의미한다.

Error processing create topic request CreatableTopic(name='__consumer_offsets', numPartitions=50, replicationFactor=3, assignments=[], configs=[CreateableTopicConfig(name='compression.type', value='producer'), CreateableTopicConfig(name='cleanup.policy', value='compact'), CreateableTopicConfig(name='segment.bytes', value='104857600')]) (kafka.server.ZkAdminManager)
org.apache.kafka.common.errors.InvalidReplicationFactorException: Replication factor: 3 larger than available brokers: 1.

기본적으로 Kafka는 __consumer_offsets 토픽 등 내부 토픽을 replication factor 3으로 만들려고 시도합니다.

그런데 현재 docker-compose로 브로커 1개만 띄운 상태라서 이런 에러가 납니다.

이 에러는 테스트/로컬 환경에서는 굉장히 흔한 현상이라고 한다..

그래서 kafka 설정에서 아래 3줄을 추가하였다. 이것의 의미는 브로커 환경에 맞게 replication factor 기본값 낮춤으로써 문제를 해결하였다.

      # 아래 세 줄 추가!!
      KAFKA_OFFSETS_TOPIC_REPLICATION_FACTOR: 1
      KAFKA_TRANSACTION_STATE_LOG_REPLICATION_FACTOR: 1
      KAFKA_TRANSACTION_STATE_LOG_MIN_ISR: 1

또는 kafka를 3개로 설정하는 방법도 있다!

docker-compose.yml 파일을 수정해서 프로젝트를 실행 하면 KafkaMessageListenerContainer 가 정상적으로 등록된 것을 확인 할 수 있다.

그래서 메시지를 전송하면 @KafkaListener 의 로그가 정상적으로 콘솔에 찍히는 것을 확인 할 수 있었다!!!

4-3. Kafka UI 설정

zookeeper 와 kafka 에서 더 나아가서 kafka ui 를 설정하여 메시지가 어떻게 전송되는 지 확인해 볼 수 있다.

docker-compose.yml 에서 kafka 설정해 둔 것 밑에 kafka-ui 를 설정해 둔다.

  kafka-ui:
    image: provectuslabs/kafka-ui:latest
    container_name: kafka-ui
    ports:
      - "9580:8080"
    depends_on:
      - kafka
    environment:
      KAFKA_CLUSTERS_0_NAME: local-cluster
      KAFKA_CLUSTERS_0_BOOTSTRAPSERVERS: kafka:9092
    networks:
      - kafka-net

설정해 둔 후 docker 에서 다시 재실행 시켜서 localhost:9580 에 접근하게 되면 kafka ui 를 확인해 볼 수 있다.

topic 이 추가 되고 어떻게 메시지가 전송 되었는지 확인 해 볼 수 있다.

4-4. 다양한 테스트

서로 다른 GroupId 와 동일한 Topic 인 경우
https://pixx.tistory.com/333

kafka-ui 에서 Topic 을 확인해보면, topic1에 group_a, group_b 2개의 consumer group 이 생성 되어 있는 것을 확인 할 수 있다.
topic1에 메시지를 요청하여 로그를 확인 해 보면 Gropu A와 Group B의 시간차가 존재하지만 동일한 메시지를 수신하는 것을 확인 할 수 있다.
이를 통해 동일한 토픽에 대해 서로 다른 그룹이 각자의 메시지를 독립적으로 수신하는 것을 확인 할 수 있다.
https://pixx.tistory.com/333
동일한 GroupId 와 서로 다른 Topic

https://pixx.tistory.com/333

topic2에 메시지를 요청하여 로그를 확인 해 보면, GroupC에 대한 리스너만 실행 된 것을 확인 할 수 있다.
이를 통해 같은 그룹에 있더라도 메시지는 특정 토픽을 대상으로 수신 되는 것을 확인 할 수 있다.

https://pixx.tistory.com/333

Spring Boot에 Kafka 적용하기 - 개념

오리토리 — Fri, 11 Apr 2025 10:27:43 +0900

사이드 프로젝트를 진행하면서 결제알림,채팅알림 등 다양한 알림 처리에 대해 어떤 툴을 사용할까 고민을 하다가 Kafka 를 적용하게 되었다. 우선 Kafaka 가 무엇인지에 대해 설명하면서 왜 메시지 툴을 사용하여야 하는지 알아보도록 하자~

0. 개발 환경

Back-end : java17

IDE : intelliJ 2023.1

CI/CD : gitAction

AWS

1. Kafka 에 대해서

https://tecoble.techcourse.co.kr/post/2021-09-19-message-queue/

카프카는 실시간, 이벤트 기반 애플리케이션 개발을 가능하게 하는 대규모 데이터 스트리밍 및 메시지 플랫폼입니다. 이는 대량의 데이터를 안정적으로 처리하고, 여러 시스템 간에 데이터를 신속하게 전송하고 실시간으로 데이터를 처리할 수 있는 기능을 제공합니다.

카프카는 분산형 메시지 큐로서 데이터를 프로듀서(Producer)가 생성하고, 이를 컨슈머(Consumer)가 실시간으로 읽을 수 있도록 하는 시스템입니다. 이 메시지 시스템은 여러 토픽(Topic)으로 구성되어 있으며, 각 토픽은 관련딘 메시지들의 스트림을 담당합니다.

카프카의 주요 특징 중 하나는 높은 확장성과 내결함성을 가지고 있다는 것입니다. 이는 카프카 클러스터를 통해 데이터의 병렬 처리와 분산 저장을 가능하게 하며, 이를 통해 높은 처리량과 데이터의 손실 없이 안정적인 작동이 가능합니다.

https://syk531.tistory.com/47

[Apache Kafka] 설치 및 실행

syk531.tistory.com

카프카는 Pub/Sub모델(Publish-Subscribe) 입니다.

중앙에 메시징 시스템 서버(카프카)를 두고 메시지를 주고받는 형태의 통신을 Pub/Sub모델이라고 합니다.

▶️발행자(Publisher) : 메시지를 보내는 쪽

발행자는 구독자의 정보를 알 필요가 없으며, 발행자-구독자 간의 의존성 또한 없습니다.

발행자는 메시지를 특정 채널(Topic)에 전송하는 역할만 합니다.

➡️ Producer

▶️구독자(Subscribe) : 메시지를 받는 쪽

구독자는 발행자가 전송한 메시지 중 자신이 원하는 메시지를 읽어갑니다.

구독자는 발행자의 변경에 대해 아무런 영향을 끼치지 않으며 오로지 자신이 원하는 메시지만 가져오면 됩니다.

➡️ Consumer

https://devfunny.tistory.com/823

Apache Kafka 기본 개념 총정리

카프카의 탄생 카프카 도입 전의 단점을 파악하여 카프카가 왜 탄생했는지에 대해서 알아봅시다. 카프카 도입 전 1) 일반적으로 데이터를 생성하는 '소스 애플리케이션'과 생성된 데이터가 적재

devfunny.tistory.com

https://ifuwanna.tistory.com/487

[Kafka] 카프카란? 주요개념 및 용어 소개

카프카(Kafka)란? Apache Kafka는 고성능 데이터 파이프라인, 스트리밍 분석, 데이터 통합 및 미션 크리티컬 애플리케이션을 위해 오픈 소스 분산 이벤트 스트리밍 플랫폼(distributed event streaming platform)

ifuwanna.tistory.com

https://velog.io/@youngerjesus/Apache-Kafka-Design

- Producer : 카프카와 통신하면서 메시지를 보내는 역할 (console에서 카프카로 메시지를 전달)
- Consumer : 카프카와 통신하면서 메시지를 가져오는 역할(프로듀서에서 전달한 메시지를 카프카에 요청해서 console에 노출(소비))
- Zookeeper : 컨슈머와 통신, 카프카의 메타데이터를 저장, 카프카의 상태관리 등 목적으로 이용
- Kafka Broker : 카프카 애플리케이션이 설치되어 있는 서버 또는 노드
- Kafka Cluster : 카프카 브로커들의 모임. 카프카는 확장성과 고가용성을 위하여 브로커들이 클러스터를 수정
- Topic : 카프카 데이터 저장소 (한개의 토픽은 여러개의 파티션으로 구성됨)
- Partition : 각 토픽 당 데이터를 분산 처리하는 단위
- Offset :파티션 내의 각 레코드를 고유하게 식별하는 순차적인 ID
- 컨슈머 그룹 리밸런싱(Rebalancing) : 컨슈머 그룹 내의 각 컨슈머의 파티션 소유권 이관작업
- Broker Partition Replication : 파티션 복제 기능
- ISR : Reader, Follower 파티션이 모두 동기화 된 상태
- 컨슈머 랙 : 토픽의 최신 오프셋(LOG-END-OFFSET)과 컨슈머 오프셋(CURRENT-OFFSET) 간의 차이

Zookeeper

분산 애플리케이션을 사용하게 되면, 분산 애플리케이션 관리를 위한 안정적인 코디네이션 애플리케이션이 추가로 필요하게 된다. 그것이 주키퍼이다.

주키퍼는 분산 애플리케이션이 안정적인 서비스를 할 수 있도록 분산되어 있는 각 애플리케이션의 정보를 중앙에 집중하고 구성관리, 동기화 등의 서비스를 제공한다.

서버 여러 대를 앙상블(클러스터)로 구성하고, 분산 애플리케이션들이 각각 클라이언트가 되어 주키퍼 서버들과 커넥션을 맺은 후 상태 정보 등을 주고 받는다. 아래 그림에서 Server는 주키퍼, Client 는 카프가가 된다.

https://cornswrold.tistory.com/523

Kafka Broker (Kafka)

카프카 브로커는 일반적으로 '카프카' 라고 불리는 시스템을 말합니다. 프로듀서와 컨슈머는 별도의 애플리케이션으로 구성되는 반면, 브로커는 카프카 자체이기 때문입니다.

카프카를 구성할 때는 한 대 이상의 주키퍼로 구성된 주키퍼 클러스터와 한 대 이상의 브로커로 구성된 브로커(=카프카) 클러스터로 구성됩니다.

https://curiousjinan.tistory.com/entry/understanding-kafka-all-structure

각 브로커는 카프카 토픽의 하나 이상의 파티션을 저장하고 관리한다. 이 파티션들에는 메시지 또는 레코드가 순차적으로 저장된다. 브로커는 프로듀서로부터 데이터를 받아 저장하고, 컨슈머의 요청에 따라 저장된 데이터를 제공한다.

카프카는 데이터의 안정성을 위해 파티션을 여러 브로커에 복제한다. 이를 통해, 하나의 브로커에 장애가 발생해도 시스템은 계속 작동 할 수 있다. 그리고 필요시 클러스터에 새로운 브로커를 추가하여 시스템의 처리 능력과 저장 용량을 확장 할 수 있다.

(주키퍼는 브로커들의 상태체크를 한다.)

Topic & Partition

토픽은 여러개의 파티션으로 구성되어 있다.

카프카 클러스터는 토픽에 데이터를 저장한다. 하나의 토픽에 여러 프로듀서들이 데이터를 전송할 수 있고, 여러 컨슈머들이 하나의 토픽에서 데이터를 읽어올 수 있다. 토픽을 효율적으로 관리하기 위해서는 여러 파티션으로 구성되어야 한다.

만약 여러 프로듀서 A,B,C가 같은 "event-topic" 토픽에 데이터를 전송했다고 가정해보자.

토픽에 파티션이 1개라면 프로듀서 A,B,C가 보내는 모든 데이터를 해당 파티션이 혼자 감당해야 한다. 이러한 경우 하나의 메시지 전송 완료 이후 다음 메시지 전송이 가능해지면서 전송 속도에 영향을 주게 된다.

그래서 파티션이 여러개 인 경우에는 A,B,C가 한번에 데이터를 전송하더라도 여러개의 파티션들에 나눠져서 병렬로 처리 될 수 있다.

Producer

프로듀서는 카프카 브로커로 데이터를 전송하는 역할을 수행한다.

메시지 전달 과정
직렬화 ➡️ 파티셔닝➡️ 메시지 배치 ➡️ 압축 ➡️ 전달

프로듀서 설정 옵션값에 대해 알아보자

▶️필수옵션

- bootstrap.servers : 프로듀서가 데이터를 전송할 대상 카프카 클러스터에 속한 브로커의 hostname:port를 1개 이상 작성합니다.

※ 2개이상의 브로커 정보를 입력하여 일부 브로커에 이슈가 발생하더라도 접속하는데에 이슈가 없도록 설정 가능.

- key.serializer : 레코드의 메시지 키를 직렬화하는 클래스를 지정한다.

- value.serializer : 레코드의 메시지 값을 직렬화하는 클래스를 지정한다.

▶️선택옵션

- buffer.memory

- retries

- batch.size

- linger.ms

- partitioner.class

- enable.idempotence

- transactional.id

Consumer

컨슈머는 카프카 브로커의 데이터를 가져오는 역할을 수행한다.

카프카의 컨슈머는 Polling 구조를 가진다. Polling 구조를 가짐으로써, 컨슈머는 자신이 원하는 만큼의 메시지를 브로커에게 요청 할 수 있다.

하나의 토픽에 여러개의 컨슈머들이 동시에 구독할 수 있다. 컨슈머가 메시지를 읽었을 때 그 메시지가 삭제되지 않기 때문에 여러 컨슈머들이 하나의 동일한 메시지를 가져갈 수 있다. 각 컨슈머가 어느 토픽 파티션의 어느 오프셋까지 읽었는지 아는 방법은 *Offset 을 컨슈머 오프셋('_consumer_offset')이라는 토픽에 저장하기 때문이다. 이러한 특징 때문에 장애가 발생하더라도 다시 구동이 되면 컨슈머 오프셋에 저장된 정보를 통해 어디서부터 메시지를 읽어야 하는지 알 수 있어서 안정적인 메시지 polling이 가능하다.

*offset : 오프셋은 각 파티션마다 메시지가 저장되는 위치이다. 오프셋은 파티션마다 유니크한 값을 가진다. 즉, 하나의 파티션 내에서만 유일한 숫자임을 보장한다. 카프카에서는 이 오프셋으로 메시지의 순서를 보장하고, 컨슈머는 오프셋 순서대로만 데이터를 가져갈 수 있다.

컨슈머 그룹이 존재하여 하나 이상의 컨슈머가 컨슈머 그룹을 구성하여 하나의 토픽을 구독 할 수 있다. 컨슈머 그룹은 다른 컨슈머 그룹과 격리되는 특징을 가지고 있다. 따라서 프로듀서가 보낸 데이터를 각기 다른 역할을 하는 컨슈머 그룹끼리 영향을 받지 않게 처리 할 수 있다.

▶️필수옵션

- bootstrap.servers : 프로듀서가 데이터를 전송할 대상 카프카 클러스터에 속한 브로커의 hostname:port를 1개 이상 작성합니다.

※ 2개이상의 브로커 정보를 입력하여 일부 브로커에 이슈가 발생하더라도 접속하는데에 이슈가 없도록 설정 가능.

- key.serializer : 레코드의 메시지 키를 역직렬화하는 클래스를 지정한다.

- value.serializer : 레코드의 메시지 값을 역직렬화하는 클래스를 지정한다.

▶️선택옵션

- group.id

- enable.auto.commit

- auto.commit.interval.ms

- max.poll.records

- session.timeout.ms

- heatbeat.interval.ms

- max.poll.interval.ms

- isolation.level

MyBatis 파라미터 콘솔에 찍기 (with. foreach)

오리토리 — Wed, 2 Apr 2025 17:53:29 +0900

콘솔 로그에 쿼리가 찍히고 있는데, 현재 <foreach></foreach> 문에 대해서는 빈값으로 찍히고 있다.

AND USER_NAME IN ( '', '', '')

그렇다 보니 디버그 할 때 불편해서 개선해보기로 했다!

1. src/main/java/config/spring/mybatis.yml

        <bean id="sqlSession" class="core.dao.RefreshableSqlSessionFactoryBean">
            <property name="dataSource" ref="dataSource" />
            <property name="mapperLocations" value="classpath*:/**/query/*.xml" />
            <property name="configLocation" value="classpath:config/sqlmap/sql-mapper-config-local.xml" />
            <property name="plugins">
	            <array>
	            	<!-- local debug시 masking 문 생성 -->
	                <bean class="core.mybatis.MaskingInterceptor" />
	                <!-- local debug시 query 문 생성 -->
	                <bean class="core.mybatis.MybatisLogInterceptor" />
	            </array>
	        </property>
        </bean>

mybatis bean 설정을 xml 로 설정되어 있고, query문을 찍어주고 있는 Interceptor 부분이 MybatisLogInterceptor 클래스로 되어 있는 것을 확인 할 수 있었다.

2. MybatisLogInterceptor.class

	@Override
	public Object intercept(Invocation invocation) throws Throwable {
		Object[] args = invocation.getArgs();
		MappedStatement ms = (MappedStatement) args[0];
		Object param = args[1];
		BoundSql boundSql = ms.getBoundSql(param);
        try{
        	// 쿼리문을 가져온다(이 상태에서의 쿼리는 값이 들어갈 부분에 ?가 있다)
			String sql = boundSql.getSql();
            ...
            List<ParameterMapping> paramMapping = boundSql.getParameterMappings();
            for (ParameterMapping mapping : paramMapping) {
            	String propValue = mapping.getProperty(); // 파라미터로 넘긴 Map의 key 값이 들어오게 된다
                Object value = ((Map) param).get(propValue); // 넘겨받은 key 값을 이용해 실제 값을 꺼낸다
                ...
                
            }
            ...
        }catch(NullPointerException | IllegalArgumentException e) {
			logger.debug("\n sql 로그 생성 중 에러\n {}\n", boundSql.getSql());
		}
        ...
        
        ...
    }

foreach 구문이 있는 경우에는 ParameterMapping 안에 '__frch_item_0' 이런형태로 적재된다.

param = {userNameList : ['가','나'], userAge : "20"} 이런형태로 파라미터가 넘어오게 되는데 userNameList 는 ParameterMapping __frch_item_0, __frch_item_1 의 형태로 적재되어 있는 상태이다.

그래서 아래 처럼 데이터를 찍어보게 되면,

String propValue = mapping.getProperty();
-> propValue = __frch_item_0

value = ((Map) param).get(propValue);

-> vaule = null

결론적으로 파라미터를 받아오는 value가 null이다 보니 콘솔문에 찍힐 때 빈값으로 찍히는 오류가 발생했던 것이다.

그렇기 때문에 foreach 파라미터는 boundSql.hasAdditionalParameter(propValue) 를 사용해서 처리 하면된다.

hasAdditionalParameter 를 통해 동적 SQL을 알아낼 수 있다. 그래서 동적 SQL문이면 true , 그외는 false 로 응답 하기 때문에 분리해서 value 를 가져와야 한다.

Object value = ((Map) param).get(propValue); 이렇게 되어 있는 것을

아래 코드로 변경하면 foreach 문도 콘솔에 찍히게 할 수 있었다.

Object value;
// 동적 SQL로 인해 __frch_item_0 같은 파라미터가 생성되어 적재됨, additionalParameter로 획득
if(boundSql.hasAdditionalParameter(propValue)) {
          value = boundSql.getAdditionalParameter(propValue);
} else {
          value = ((Map) param).get(propValue); // 넘겨받은 key 값을 이용해 실제 값을 꺼낸다

}

이를 통해 디버깅 할 때 대량의 foreach 파라미터가 넘어 가는 경우 (약 100개) 콘솔에 찍히는 파라미터를 복붙하는 무의미한 작업으로 업무 효율성이 떨어졌었지만 이를 통해 조금이나마 개선 된 거 같다..ㅎㅎ

AWS 운영과 개발 서버 분리하기(with.git action, spring swagger)

오리토리 — Sun, 9 Mar 2025 15:33:25 +0900

프로젝트에서 서버를 AWS에서 관리되고 있는데, 현재는 개발 서버만 세팅되어 있었다. 이제 오픈을 위해 운영서버로 분리해야 했는데 이 작업을 맡게 되었다.

AWS를 처음 다뤄보다보니 개념이 너무 어려웠고, (사실은 아직도 잘 모르겠다 ) 많은 시행착오를 겪으면서 결국 성공했는데 이것을 한번 잘 정리해보겠다..

1. EC2설정 : VPC,SUBNET,보안

기존에는 redis와 Bastion-Host 2개가 실행 중이었다.

기능에 대해서 설명하면 Bastion-Host 는 DB와 같이 private 한 네트워크에 위치해 있는 인스턴스에 접근하기 위한 터널링 역할로 사용한다. redis는 주로 데이터 캐싱이나 세션 저장 같은 작업을 처리하는 역할로 사용한다. 그래서 현재 redis에는 redis, kafka(알림), grafana(로그 시각화) 서버가 redis 도커 컨테이너에 올라가 있다.

※ AWS에서는 무엇을 보고 redis 기능과 Bastion 기능을 구분짓는지 궁금하여 아래에 자세히 설명했두었음. ※

Bastion-Host 설정 방식

- 퍼블릭 서브넷에 위치시킴 (인터넷 게이트웨이 연결)

※ 인터넷게이트웨이 연결 여부는 VPC를 확인

VPC → 인터넷게이트웨이 → 상태가 **"연결됨(Attached)"**인지 확인

만약 인터넷 게이트웨이에 연결되지 않았다면
VPC → 인터넷 게이트웨이 생성 후, 인터넷 게이트웨이 연결 → 라우팅 테이블에서 0.0.0.0/0 대상 추가
하여 인터넷 연결

Bastion-Host 의 서브넷 : DEV_PUB_SUBNET
DEV_PUB_SUBNET 의 라우팅 테이블 : PUB_RTB

PUB_RTB의 라우팅
0.0.0.0 / 0 ▶ igw-XXXXX (게이트웨이에 연결됨)

- 보안 그룹 설정에서 SSH(포트 22) 허용 → 외부에서 Bastion-Host로 접근 가능

▶ 프라이빗 인스턴스로의 터널링을 위해 프라이빗 인스턴스 보안 그룹에서 Bastion-Host의 IP를 허용

Redis 설정 방식

- 프라이빗 서브넷에 위치시킴 (인터넷 게이트웨이 연결 X)

서브넷 : DEV_PRV_SUBNET	DEV_PRV_SUBNET 의 라우팅 테이블 : DEV_PRV_RTB
DEV_PRV_RTB의 라우팅 0.0.0.0 / 0 ▶ nat-XXXXX igw-xxxxx 로 되어 있으면 인터넷게이트에 연결된 상태이지만 nat-xxxx로 되어 있으므로 프라이빗 서브넷에 위치된 상태임을 짐작 할 수 있다.

- 보안 그룹에서 외부 접근 차단하고 Bastion-Host 또는 특정 애플리케이션 서버에서만 접근 허용 (예: 포트 6379)

필요하다면 VPC 피어링이나 보안 그룹 규칙으로 Bastion-Host를 통해 접속 가능하게 설정

2. RDS 추가

개발과 운영을 나눌 때 가장 먼저 한 작업은 RDS 분리였다.

기존에 dev-db로 추가 되어 있었는데 이것과 설정을 비슷하게 해서 prod-dev로 추가했다.

서브넷에는 PRD_PRV_SUBNET_B, PRD_PRV_SUBNET_C 를 추가해주었다. 보안은 기존에 추가되어 있었던 개발 DB 보안을 일단 그대로 사용하였다.

2-1. 로컬에서 prod db 연결 확인하기

※ tool : dbeaver

db : postgresql

SSH에서 Bation-Host 의 IP 를 통해 AWS 운영 db 에 접근 할 수 있다.

Host/IP : Bastion-Host IP주소 (AWS EC2 에서 확인)

User Name : ec2-user (default 설정)

Authentication Method : Public Key

Private Key : prod db를 생성할 때 받은 .pem 파일을 업로드

Host, Database, Username AWS RDS 에서 확인 가능

connection 이 success 나오면 RDS 설정이 잘 된것!

3. ECS 배포(with. git action)

우선, AWS로 배포를 위해 각 프로젝트별로 task-definition.json 과 git action 의 workflow.yml 파일을 개발과 운영으로 분리 해줘야 한다.

그래서 기존 파일 이름을 task-definition-dev.json, dev-workflow.yml 로 수정하고,

task-definition-prod.json, prod-workflow.yml 을 추가해주었다.

name: DEV-Cluster CI CD
# 운영인 경우에는 PROD-Cluster CI CD 로 명칭했음

on:
  workflow_dispatch:

env:
  DB_RESOURCE_PATH: ./src/main/resources/application-database.yml
  REGION: ap-northeast-2
  ECR_REPOSITORY: [aws 에서 확인]
  IMAGE_TAG: [프로젝트명칭]
  ECR_CLUSTER_NAME: [AWS ECS에 추가할 클러스터 명]
  ECR_SERVICE_NAME: [AWS ECS 클러스터에 추가 될 서비스명칭]
  CONTAINER_NAME: [AWS ECS 클러스터에 추가 될 컨테이너명칭]

jobs:
  build:
    runs-on: ubuntu-latest

    steps:
      - uses: actions/checkout@v3

      - name: Set up JDK 17
        uses: actions/setup-java@v3
        with:
          java-version: '17'
          distribution: 'temurin'

      - name: Set database info
        uses: microsoft/variable-substitution@v1
        with:
          files: ${{ env.DB_RESOURCE_PATH }}
        env:
          spring.datasource.url: ${{ secrets.DEV_RDS_HOST }}
          spring.datasource.username: ${{ secrets.DEV_RDS_USERNAME }}
          spring.datasource.password: ${{ secrets.DEV_RDS_PASSWORD }}
          spring.data.redis.host: ${{ secrets.DEV_REDIS_HOST }}
          shell: bash


      - name: Grant Gradle Wrapper
        run: chmod +x ./gradlew

      - name: Build with Gradle
        uses: gradle/gradle-build-action@bd5760595778326ba7f1441bcf7e88b49de61a25 # v2.6.0
        with:
          arguments: clean build -x test

      - name: Setting AWS Credentials
        uses: aws-actions/configure-aws-credentials@v2
        with:
          aws-region: ${{ env.REGION }}
          aws-access-key-id: ${{ secrets.AWS_ACCESS_KEY_ID }}
          aws-secret-access-key: ${{ secrets.AWS_SECRET_ACCESS_KEY }}

      - name: Login to Amazon ECR
        id: login-ecr
        uses: aws-actions/amazon-ecr-login@v1

      - name: Build, tag, and push image to Amazon ECR
        id: build-image
        env:
          ECR_REGISTRY: ${{ steps.login-ecr.outputs.registry }}
          IMAGE_TAG: ${{ env.IMAGE_TAG }}
        run: |
          docker build -t $ECR_REGISTRY/$ECR_REPOSITORY:$IMAGE_TAG .
          docker push $ECR_REGISTRY/$ECR_REPOSITORY:$IMAGE_TAG
          echo "::set-output name=image::$ECR_REGISTRY/$ECR_REPOSITORY:$IMAGE_TAG"

      - name: Fill in the new image ID in the Amazon ECS task definition
        id: task-def
        uses: aws-actions/amazon-ecs-render-task-definition@v1
        with:
          ✨task-definition: task-definition-dev.json✨
          # 운영인 경우에는 task-definition-prod.json 으로 경로 수정해 주어야 함.
          container-name: ${{env.CONTAINER_NAME}}
          image: ${{ steps.build-image.outputs.image }}

      - name: Deploy Amazon ECS task definition
        uses: aws-actions/amazon-ecs-deploy-task-definition@v1
        with:
          task-definition: ${{ steps.task-def.outputs.task-definition }}
          cluster: ${{env.ECR_CLUSTER_NAME}}
          service: ${{env.ECR_SERVICE_NAME}}
          wait-for-service-stability: true

SPRING_PROFILES_ACTIVE 설정으로 dev와 prod 를 구분짓는다.

그래서 dev 라고 설정 되어 있으면 task-definition-dev.json 파일을 읽게 될 것이다.

{
  "containerDefinitions": [
    {
      "name": "[프로젝트 컨테이너 명칭]",
      "image": "[AWS 이미지경로]",
      "cpu": 0,
      "portMappings": [
        {
          "name": "[컨테이너명칭]-8080-tcp",
          "containerPort": 8080,
          "hostPort": 8080,
          "protocol": "tcp",
          "appProtocol": "http"
        }
      ],
      "essential": true,
      "environment": [
      ✨✨✨✨✨✨✨✨✨✨✨✨✨✨✨✨✨
        {
          "name": "SPRING_PROFILES_ACTIVE",
          "value": "dev"
        },
        ✨✨✨✨✨✨✨✨✨✨✨✨✨✨✨✨✨
        {
          "name": "LOGGING_LEVEL_COM_MOMMYDNDN_API",
          "value": "DEBUG"
        },
        {
          "name": "SPRING_KAFKA_BOOTSTRAP_SERVERS",
          "value": "[redis IP:포트번호]"
        },
        {
          "name": "PUSH_GATEWAY_SERVERS",
          "value": "[redis IP:포트번호]"
        }
      ],
      "environmentFiles": [],
      "mountPoints": [],
      "volumesFrom": [],
      "ulimits": [],
      "logConfiguration": {
        "logDriver": "awslogs",
        "options": {
          "awslogs-create-group": "true",
          "awslogs-group": "/ecs/[태스크명칭]",
          "awslogs-region": "ap-northeast-2",
          "awslogs-stream-prefix": "ecs"
        },
        "secretOptions": []
      }
    }
  ],
  "family": "[태스크명칭]",
  "executionRoleArn": "arn:aws:iam::[iam번호]:role/ecsTaskExecutionRole",
  "networkMode": "awsvpc",
  "volumes": [],
  "placementConstraints": [],
  "requiresCompatibilities": [
    "FARGATE"
  ],
  "cpu": "256",
  "memory": "512",
  "runtimePlatform": {
    "cpuArchitecture": "X86_64",
    "operatingSystemFamily": "LINUX"
  },
  "tags": []
}

3-1.배포

배포를 하게 되면 TASK 만 생성되고 ECS 에 서비스가 생성되지 않는 오류가 발생하였다. 이유는 서비스가 없을때 생성하는 로직을 넣는것 자체가 위험하다보니 깃 워크플로우는 ECS에서 서비스를 생성하진 않는 것이었다.

그래서 생성된 TASK로 서비스를 생성하면 원래라면 ECS 배포가 정상적으로 성공했어야 했는데 또 다른 오류가 발생하였다.

해결방법1.

unable to pull secretes or registry auth 라고 검색하니 권한 문제인거 같아서 아래처럼 권한을 추가해보았다. ❌ 실패!

기존 개발 ECS 는 정상적으로 배포 되었으니, 권한 문제는 아니었다.

해결방법 2.

TASK 쪽 로그를 자세히 확인 해보니, 런타임 에러가 있었고 이것을 토대로 검색해 보니 운영으로 추가한 SUBNET 에 대해서 NAT 게이트웨이 설정이 덜 되어 있었다! 이 부분은 초기에 개발 해 놓은 분이 설정을 일부만 해놓아서 찾기 어려웠던 거 같다.

위에서 추가했던 PRD_PUB_SUBNET_B, PRD_PUB_SUBNET_C 각각에 대해서 아래처럼 NAT 게이트웨이가 연결되어 있었어야 했는데 B에 대해서만 연결되어 있고 C에 대해서 연결되어 있지 않아 발생했던 오류였다. ⭕해결!

배포성공

3-2.spring swagger 운영도메인 확인하기

ECS 에 필요한 프로젝트를 배포 성공하였고, spring swagger 로 API를 확인 하려고 하는데

[도메인]/[서비스명]/v3/api-docs 경로로 접근하면 왼쪽 이미지처럼 json이 응답되어야 하는데 운영도메인으로 접근하면 500에러가 발생하였다.

3-3. 로드밸런스 확인하기

기존 로드밸런서 설정에서 리스너에는 HTTP:80과 HTTPS:443 이 추가 되어 있었다. 그리고 HTTP:80 포트로 접근 하면 HTTPS:443 으로 리다렉션 해주는 규칙이 추가 되어 있다.

※ 80포트를 443으로 리다렉션 해주어야 한다. 그리고 GATEWAY 프로젝트에서 url 경로를 관리하고 권한을 체크하다보니 배포 할 때 GATEWAY 프로젝트가 필요하고 우선적으로 배포되는 것이 좋다.

HTTPS:443 에는 개발대상그룹 (DEV-GATEWAY-SERVICE) 만 연결되어 있는 상태였다.

아래에 간략한 그림과 함께 설명하자면 현재 ECS 에는 개발, 운영 클러스터로 나뉘어져 있으며 각각 프로젝트가 배포되어 있는 상태이다.

로드밸런서에 연결할 GATEWAY_SERVICE 를 생성 할 때는 로드밸런싱 사용을 체크로 하여 로드밸런서에 연결해주어야 한다.

그리고 대상그룹을 새로 추가한다. 추가한 대상그룹은 EC2 → 로드밸런서 → 대상그룹 에서 확인 해 볼 수 있다.

그리고 배포를 했을 때 대상에 IP가 생성되어 있고 상태가 Healthy 이면 정상적으로 배포 된 것을 확인 할 수 있다.

처음 로드밸런서에 연결을 해야 하는 걸 몰라서 배포하면 대상그룹의 타겟 IP의 상태가 Unhealthy 가 뜨고 배포가 실패 했었다.

그래서 개발과 같이 운영 GATEWAY_SERVICE 를 생성 할 때 로드밸런서를 연결하면서 대상을 추가해주니,

PROD-GATEWAY-SERVICE 대상도 로드밸런서에 정상적으로 연결되었다.

그리고 HTTPS:443 에 운영과 개발의 도메인을 분리시키는 규칙을 추가함으로써 타겟을 분리시켰다.

3-4. spring swagger 운영도메인 다시 확인하기

이렇게만 해주면 swagger 도 연결이 잘 될 줄 알았으나... 계속해서 500에러가 났다..

Chat gpt 와 검색을 통해서 확인해 보라는 사항은 다 확인 해 보았다.

확인사항1. API docs 문제 : [도메인주소]/caring-service/v3/api-docs 호출하여 json 응답이 오는지 확인 ❌

springdoc.api-docs.path 설정값이 "/caring-service/v3/api-docs" 인지 확인.

application.yml

@Configuration
public class WebConfig implements WebMvcConfigurer {
    private final LoginUserIdArgumentResolver loginUserIdArgumentResolver;
    private final ApiLogInterceptor apiLogInterceptor;

    public WebConfig(LoginUserIdArgumentResolver loginUserIdArgumentResolver,
                     ApiLogInterceptor apiLogInterceptor) {
        this.loginUserIdArgumentResolver = loginUserIdArgumentResolver;
        this.apiLogInterceptor = apiLogInterceptor;
    }

    @Override
    public void addArgumentResolvers(List<HandlerMethodArgumentResolver> resolvers) {
        resolvers.add(loginUserIdArgumentResolver);
    }


    @Override
    public void addInterceptors(InterceptorRegistry registry) {
        registry.addInterceptor(apiLogInterceptor)
                .addPathPatterns("/**")
                .excludePathPatterns(
                        "/swagger-ui/**",
                        "/v3/api-docs/**",
                        "/error",
                        "/favicon.ico"
                );
    }


}

확인사항2. [도메인주소]/v3/api-docs/swagger-config 호출 했을 때, json 이 응답되는지 확인 ⭕

이것을 봤을 때, caring-service 명을 못 찾는 오류 인 거 같다는 생각이 번뜩 나버렸다!!!

그래서 ECS 에서 확인을 해 보니 구성및네트워킹 > 서비스연결 에서 DNS 를 연결해주지 않아서 발생했던 오류 였다 ㅠㅠ

(3일정도를 고생했던거 같다..)

이렇게 해주니 정상적으로 운영 swagger 를 확인 할 수 있었다!

여전히 AWS 각각의 기능에 대해서 정확히 이해하지는 못하고 처음부터 환경을 구축하라고 한다면 할 수 있을지 자신은 없지만 어느정도 환경이 이렇게 구성되어 있구나를 머릿속으로 그림은 그릴 수 있게 된거 같아 뿌듯하다. ㅎㅎ

HttpServletRequestWrapper 에 대해서 ( with. ExceptionHandler)

오리토리 — Thu, 22 Aug 2024 16:24:24 +0900

프로젝트 진행 중에 Exception 이 발생하면 로그테이블에 저장해주는 로직을 개발해야 하는 상황이었다. 그래서 예외 처리를 @ExceptionHandler 를 통해 관리하고 @Aspect 어노테이션을 붙인 클래스에서 로그테이블을 저장 하는 흐름으로 개발 했는데 문제가 발생하였다.

바로 @RequsetBody 를 통해 들어온 파라미터를 받아서 로그에 저장해야 하는데 현재 개발되어 있는 파라미터로는 요청 파라미터를 받을 수 없어서 찾아보던 중 HttpServletRequestWrapper 를 통해 값을 읽어오는 방법을 알게 되었음! (유레카 )

상황

Controller

    @PostMapping("/approval")
    public CardResponse paymentApproval(
            @Parameter(hidden = true) @LoginUserId Long userId
            ,@RequestBody PaymentApprovalRequest request
    ) {
        return paymentService.prepaymentContract(userId, request, "결제");
    }

LoggingAspect

@Aspect
@Component
@Slf4j
@RequiredArgsConstructor
public class LoggingAspect {

	@Before(value = "execution(* [프로젝트명].exception.handler.GlobalExceptionHandler.*(..)) && args(exception, webRequest)", argNames = "exception,webRequest")
    public void logExceptionBeforeMethod(Exception exception, WebRequest webRequest) {
        saveToDatabaseCardLog(exception.getMessage().trim(), webRequest);
    }
    
    
    private void saveToDatabaseCardLog(String exceptionMessage, WebRequest webRequest){
        ServletWebRequest servletWebRequest = (ServletWebRequest) webRequest;

        [오류가 난 컨트롤러에서의 RequestBody 파라미터];
        ✨ String parameter = getRequestBody(servletWebRequest);
        CardLog cardLog = CardLog.builder()
                .requestNo(parameter)
                .build();

        CardLogRepository.save(cardLog);
    }
}

어떤 데이터가 오류가 난 건지 Controller 의 @RequestBody 에 넘어온 파라미터를 로그 테이블에 저장하고 싶은 상황인데 검색해보니, HttpServletRequest 클래스의 getInputStream() 을 활용하여 body 값을 조회 해 올 수 있다고 함!

방법1-1. HttpServletRequest 를 통해 body 값 가져오기 - getInputStream()

public String getRequestBody(ServletWebRequest servletWebRequest){
        BufferedReader br = null;
        StringBuilder stringBuilder = new StringBuilder();
        try{
            HttpServletRequest request = servletWebRequest.getNativeRequest(HttpServletRequest.class);
            InputStream inputStream = request.getInputStream();
            String line = "";
            if(inputStream != null){
                br = new BufferedReader(new InputStreamReader(inputStream));
                while ((line = br.readLine()) != null){
                    stringBuilder.append(line);
                }
            }
            log.info("###### body {}" ,stringBuilder);
        }catch (Exception e){
            throw new RuntimeException(e);
        }


        return null;
}

HttpServletRequest request = servletWebRequest.getNativeRequest(HttpServletRequest.class);

-> ServletWebRequest 를 HttpServletRequest 로 변환

request.getInputSreamReader()

-> 읽기

결과 : 빈값으로 나오는 오류 발생

원인

[이미지 출처] Filter, Interceptor, AOP 차이 - 갓대희님 블로그 출처

요청 -> 필터 -> 디스패처서블릿 -> 인터셉터 -> 컨트롤러의 객체로 값을 바인딩을 하는 흐름인데, 지금 상황 같은 경우 body data를 Controller 단에서 소비하고 AOP 에서 getInputStream() 을 하니 비워져 있는 것이다.

왜 AOP가 아닌 "Controller 단에서 소비" 했다고 말하는 이유?

-> 예외가 발생하게 되면 @RestControllerAdvice 어노테이션이 붙은 클래스의 @ExeptionHandler 에서 예외처리를 받아 주는 상황이다. 그런데 그 전에 @Aspect 어노테이션을 붙은 클래스에서 @Before 로 포인트컷을 주어서

ExceptionHandler 클래스의 하위 메소드가 실행되기 전에 Aspect 클래스가 실행되고 거기서 Controller 단에서 받은 body 파라미터를 로그테이블에 저장하고 싶은 상황이다.

즉, Controller ----- throw 예외처리 ----> AOP -> ExceptionHandler 흐름이기 때문에 Controller 에서 이미 getInputStream()이 소비 되어서 AOP 에서 읽으려고 하니 비어있는 상황인것이다.

방법1-2. HttpServletRequest 를 통해 body 값 가져오기 - getReader()

    public String getRequestBody(ServletWebRequest servletWebRequest){
        BufferedReader br = null;
        StringBuilder stringBuilder = new StringBuilder();
        try{
            HttpServletRequest request = servletWebRequest.getNativeRequest(HttpServletRequest.class);


            String line = "";
                br = request.getReader();
                while ((line = br.readLine()) != null){
                    stringBuilder.append(line);
                }
            log.info("###### body {}" ,stringBuilder);
        }catch (Exception e){
            throw new RuntimeException(e);
        }


        return null;
}

br = request.getReader();

-> getInputStream() 이 아닌, getReader() 로 파라미터 값을 받아옴.

결과 : getInputStream() has already been called for this request

원인

getReader()에서 InputStream을 생성하는데, tomcat 에서 한번만 사용할 수 있도록 막아두었기 때문에 한번 read한 body 값은 다시 읽을 수 없다.

그래서 이 부분을 해결하기 위해서 HttpServletRequestWrapper 를 만들어서, getReader() 메서드를 오버라이드 하고 새로운 InputStreamReader를 만들어서 반환하도록 한 뒤, Filter 를 통해 들어오는 request들을 새로 만든 wrapper로 변경하여 받아올 수 있다.

방법2-1. HttpServletRequestWrapper 를 상속받는 클래스 생성

- 한번 읽고 사라지는 httpBody가 아닌 여러번 계속해서 읽을 수 있도록 구현

- getInputSream()에서 요청 httpBody를 복사하여 값을 저장하고 반환하는 기능을 재정의.

@Slf4j
public class RequestWrapper extends HttpServletRequestWrapper {
    private final String body;

    /**
     * Constructs a request object wrapping the given request.
     *
     * @param request The request to wrap
     * @throws IllegalArgumentException if the request is null
     */
    public RequestWrapper(HttpServletRequest request) {
        super(request);

        StringBuilder stringBuilder = new StringBuilder();
        try (BufferedReader bufferedReader = request.getReader()) {
            char[] charBuffer = new char[128];
            int bytesRead;
            while ((bytesRead = bufferedReader.read(charBuffer)) > 0) {
                stringBuilder.append(charBuffer, 0, bytesRead);
            }
        } catch (IOException e) {
            throw new RuntimeException(e);
        }

        body = stringBuilder.toString();
    }

    @Override
    public ServletInputStream getInputStream() {
        final ByteArrayInputStream byteArrayInputStream = new ByteArrayInputStream(body.getBytes());
        return new ServletInputStream() {
            @Override
            public boolean isFinished() {
                return false;
            }

            @Override
            public boolean isReady() {
                return false;
            }

            @Override
            public void setReadListener(ReadListener readListener) {
                throw new UnsupportedOperationException();
            }

            public int read() {
                return byteArrayInputStream.read();
            }
        };
    }

    @Override
    public BufferedReader getReader() {
        return new BufferedReader(new InputStreamReader(this.getInputStream()));
    }
}

방법2-2 : RequestFilter 생성

- 인터셉터에서 httpBody 가 소모되기 전에 필터 단계에서 httpBody를 옮겨 담는 기능을 수행.

@Component
@WebFilter(urlPatterns="/api/payment/*")
public class RequestFilter implements Filter {
    @Override
    public void doFilter(ServletRequest request, ServletResponse response, FilterChain chain) throws IOException, ServletException {
        HttpServletRequest httpServletRequest = (HttpServletRequest) request;
        // 다시 읽을 수 있는 클래스로 래핑 해주는 코드..
        ⭐request = new RequestWrapper(httpServletRequest);⭐
        chain.doFilter(request, response);
    }
}

@WebFilter 어노테이션은 해당 url 으로 들어오는 경우에만 해당 로직을 처리하고 싶어서 추가한 것이다.

완성

    public String getRequestBody(ServletWebRequest servletWebRequest){
        HttpServletRequest httpServletRequest = servletWebRequest.getNativeRequest(HttpServletRequest.class);
        String body;
        StringBuilder stringBuilder = new StringBuilder();
        ⭐try(BufferedReader bufferedReader = Objects.requireNonNull(httpServletRequest).getReader()){⭐
            log.info("##### LoggingAspect body");
            while ((body = bufferedReader.readLine()) != null){
                log.info(body);
                stringBuilder.append(body);
            }
            JSONParser parser = new JSONParser();
            JSONObject jsonObject = (JSONObject) parser.parse(stringBuilder.toString());
            return jsonObject.get("orderId") == null ? stringBuilder.toString() : jsonObject.get("orderId").toString();
        }catch (Exception e){
            throw new RuntimeException(e);
        }
    }

https://sjh9708.tistory.com/168

[Spring Boot] 사용자 정의 예외처리 : Exception Handler

이번 포스팅에서는 Spring Boot에서 예외가 발생했을 때, 이를 처리하기 위한 계층을 정의해서 만들어보려고 한다. Exception Handler 정의의 필요성 @Override @Transactional public Long addMember(MemberJoinRequestDto i

sjh9708.tistory.com

https://hirlawldo.tistory.com/44

[Spring 프로젝트] Interceptor로 request, response body json 값 로깅하기

Spring Logging (Interceptor로 Request, Response body json 값 로깅하기) 스프링 프로젝트를 하면서 기존에는 LoggingAspect를 만들어서 Aspect파일에서 parameter값과 body값을 찍어주고 있었다. response 값도 찍어주기

hirlawldo.tistory.com

https://hirlawldo.tistory.com/42

[Spring 프로젝트] AOP Logging (Post 메서드의 Json Body 값 로깅하기)

Logging AOP - Json으로 들어온 Request Body값 로깅하기 테스트 하다보니 기존에 추가했었던 로깅 Aspect 에서는 Parameter값을 로깅하는 것만 추가했어서 Post 메서드에서 들어오는 json body값을 로깅하고 있

hirlawldo.tistory.com

https://velog.io/@best1370/HttpRequest%EC%97%90%EC%84%9C-body%EA%B0%92-%EA%B0%80%EC%A0%B8%EC%98%A4%EA%B8%B0

HttpRequest에서 body값 가져오기

Form Data를 어느 method에 넣느냐에 따라 쿼리파라미터의 위치가 다르다get: urlpost: body요청 -> 필터 -> 디스패처 서블릿 -> 인터셉터 -> 컨트롤러로 값을 바인딩 하는 과정에서 Interceptor에서 getInputStream

velog.io

AOP의 @Aspect 에 대해서

오리토리 — Wed, 21 Aug 2024 14:54:46 +0900

Spring AOP의 핵심기능과 부가기능

AOP는 업무 로직을 포함하는 핵심기능과 핵심기능을 도와주는 부가적인 기능(로깅,보안,트랜젝션)인 부가기능으로 나누어서 볼 수 있는데, 이 관점을 기준으로 각각 모듈화 하겠다는 개념으로 볼 수 있다.

코드상에서 다른 부분에 계속 반복해서 쓰는 코드들을 발견 할 수 있는데 이것을 흩어진 관심사라 부른다.

@Aspect 의 원리

예시로) 코드1 이 Class A와 Class B 에서 사용중이라면 Aspect X로 모듈화 할 수 있으며 재사용 할 수 있다.

AOP용어정리

Target	핵심기능을 담고 있는 모듈. 부가기능을 부여할 대상이 됨. Aspect 를 적용하는 곳 (클래스, 메소드 ...)
Advice	실질적으로 어떤 일을 해야할 지에 대한 것. (실질적인 부가기능을 담은 모듈)
Join Point	Advice가 적용될 위치. 타켓 객체가 구현한 인터페이스의 모든 메서드는 조인포인트가됨. ex) 메서드 진입지점, 생성자 호출시점, 필드에서 값을 꺼내올 때 등
Pointcut	Advice를 적용할 타켓의 메서드를 선별하는 정규표현식. JointPoint 의 상세한 스펙을 정의한 것. 포인트컷 표현식은 execution으로 시작하고 메서드의 Signature를 비교하는 방법을 주로 이용함.
Aspect	= Advice + PointCut AOP의 기본 모듈. 싱글톤 형태의 객체로 존재.
Advisor	= Advice + PointCut Spring AOP에서만 사용되는 특별한 용어
Weaving	포인트컷에 의해서 결정된 타켓의 조인포인트에 부가기능(어드바이스)를 삽입하는 과정. AOP가 핵심기능(타켓)의 코드에 영향을 주지 않으면서 필요한 부가기능(어드바이스)을 추가할 수 있도록 해주는 핵심적인 처리과정임.

AOP의 구현방식

1. XML 기반의 POJO클래스를 이용한 AOP구현

부가기능을 제공하는 Advice클래스를 작성한다. XML 설정파일에 <aop:config> 를 이용해서 Aspect를 설정한다.

2. @Aspect어노테이션을 이용한 AOP구현

@Aspect 어노테이션을 이용해서 부가기능을 제공하는 Aspect 클래스를 작성한다. 이 때 Aspect 클래스는 어드바이스를 구현하는 메서드와 포인트컷을 포함한다.

Aspect 란?

Aspect 는 부가기능을 정의한 코드인 Advice와 Advice를 어디에 적용할지 결정하는 포인트컷(PointCut)을 합친 개념이다.

(Advice + Pointcut = Aspect) AOP개념을 적용하면 핵심기능 코드 사이에 침투된 부가기능을 독립적인 Aspect 로 구분해 낼 수 있으며, 구분된 부가기능은 런타임시에 필요한 위치에 동적으로 참여할 수 있게 된다.

@Aspect
@Component
public class LoggingAspect {
	@Before(value = "execution(* [프로젝트].exception.handler.GlobalExceptionHandler.*(..)) && args(exception, webRequest)", argNames = "exception,webRequest")
	 public void logExceptionBeforeMethod(Exception exception, WebRequest webRequest){
     	코드작성
     }
}

@Aspect 어노테이션을 붙여 해당 클래스가 Aspect 클래스 라는 것을 명시하고 @Component 를 붙여 스프링 빈으로 등록한다.

@Before 어노테이션은 Advice타켓 메소드가 호출되기 전에 Advice 가능을 수행함을 의미한다. 추가적으로 execution(* ..)가 의미하는 바는 ~.GlobalExceptionHandler 아래 패키지 경로의 모든 메서드에 이 Aspect 를 적용하겠다는 의미.

Aspect실행 지점을 지정할 수 있는 어노테이션 (Advice)의 종류

@Before (이전)	어드바이스 타켓 메소드가 호출되기 전에 어드바이스 기능을 수행. -> JoinPoint 앞에서 실행 <aop:before>
@After (이후)	타켓 메소드의 결과에 관계없이 타켓 메소드가 완료되면 어드바이스 기능을 수행 -> try-catch-finally 에서 finally 블록과 비슷. <aop:after>
@AfterReturning (정상적 반환 이후)	타켓 메소드가 성공적으로 결과값을 반환 후에 어디바이스기능 수행 -> JoinPoint 메서드 호출이 정상적으로 종료된 뒤에 실행 <aop:after-returning>
@AfterThrowing (예외 발생 이후)	타켓 매소드가 수행 중 예외를 던지게 되면 어드바이스 기능을 수행 -> 예외가 던져질 때 실행 -> try-catch 블록에서 catch블록과 비슷함. <aop:after-throwing>
@Around (메소드 실행 전후)	어디바이스 타켓 메소드를 감싸서 타켓 메소드 호출전과 후에 어드바이스 기능을 수행 -> JoinPoint 앞과 뒤에서 실행 <aop:around>

JointPoint 는 Spring AOP 혹은 AspectJ에서 AOP가 적용되는 지점을 의미한다. 해당 지점을 AspectJ에서 JointPoint 라는 인터페이스로 나타낸다.

@Around("@annotation(com.example.testing.poly.MethodAop)")
public Object aspectParameter(final ProceedingJoinPoint joinPoint) throws Throwable {
    log.error("[aspectParameter] name: {}", joinPoint.getArgs()[0]);
    return joinPoint.proceed();
}
출처: https://mangkyu.tistory.com/231 [MangKyu's Diary:티스토리]

예시로 jointPoint.getArgs() 를 통해 파라미터를 직접 조회 할 수 있다.

포인트컷 지시자의 종류

포인트컷 표현식은 execution 같은 포인트컷 지시자로 시작한다.

execution	메서드 실행 조인포인트를 매칭함. 스프링 AOP에서 가장 많이 사용하며, 기능도 복잡
within / @within	특정 타입내의 조인포인트를 매칭.
args / @args	인자가 주어진 타입의 인스턴스인 조인포인트
this	스프링 빈 객체(Spring AOP 프록시) 를 대상으로 하는 조인 포인트
target / @target	Target 객체(Spring AOP프록시가 가리키는 실제 대상)를 대상으로 하는 조인포인트
@annotation	메서드가 주어진 어노테이션을 가지고 있는 조인포인트를 매칭
bean	스프링 전용 포인트컷 지시자로 빈의 이름으로 포인트컷을 지정

포인트컷 표현식

@Pointcut("execution(public * *(..))")
private void anyPulbicOperation(){}

// 모든 공개 메서드 실행
execution(public * *(..))

// set 다음 이름으로 시작하는 모든 메서드 실행
execution(* set*(..))

// AccountService 인터페이스에 의해 정의된 모든 메서드의 실행
execution(* com.xyz.service.AccountService.*(..))

// service 패키지에 정의된 메서드 실행
execution(* com.xyz.service.*.*(..))

// 서비스 패키지 또는 해당 하위 패키지 중 하나에 정의된 메서드 실행
execution(* com.xyz.service..*.*(..))

// 서비스 패키지 내의 모든 조인 포인트
within(com.xyz.service.*)

// 서비스 패키지 또는 하위 패키지 중 하나 내의 모든 조인 포인트
within(com.xyz.service..*)

// AccountService 프록시가 인터페이스를 구현하는 모든 조인 포인트
this(com.xyz.service.AccountService)

// AccountService 대상 객체가 인터페이스를 구현하는 모든 조인 포인트
target(com.xyz.service.AccountService)

// 단일 매개변수를 사용하고 런타임에 전달된 인수가 Serializable과 같은 모든 조인 포인트
args(java.io.Serializable)

// 대상 객체에 @Transactional 애너테이션이 있는 모든 조인 포인트
@target(org.springframework.transaction.annotation.Transactional)

// 실행 메서드에 @Transactional 애너테이션이 있는 조인 포인트
@annotation(org.springframework.transaction.annotation.Transactional)

// 단일 매개 변수를 사용하고 전달된 인수의 런타임 유형이 @Classified 애너테이션을 갖는 조인 포인트
@args(com.xyz.security.Classified)

// tradeService 라는 이름을 가진 스프링 빈의 모든 조인 포인트
bean(tradeService)

// 와일드 표현식 *Service 라는 이름을 가진 스프링 빈의 모든 조인 포인트
bean(*Service)
출처: https://ittrue.tistory.com/233 [IT is True:티스토리]

@Pointcut("execution(* ~~.*(..)) && args(~~)") 과 같이 조합하여 사용도 가능하다.

@RestControllerAdvice
@RequiredArgsConstructor
@Slf4j
public class GlobalExceptionHandler {
    @ExceptionHandler(MomApiException.class)
    public ResponseEntity<ExceptionResponse> handleMomApiException(MomApiException e, WebRequest request) {
    	..코드작성..
    }
}

@Aspect
@Component
public class LoggingAspect {
	@Before(value = "execution(* [프로젝트].exception.handler.GlobalExceptionHandler.*(..)) && args(exception, webRequest)", argNames = "exception,webRequest")
	 public void logExceptionBeforeMethod(Exception exception, WebRequest webRequest){
     	..코드작성..
     }
}

GlobalExceptionHandler 클래스의 하위 메소드를 실행 시키면서 메소드의 exeption과 webrequest 파라미터의 전달받은 값을 추적하고 싶다는 의미로 value = "execution( ... ) && args( ... )" 의 포인트컷 표현식을 사용하였다.

execution(* [프로젝트명].exception.handler.GlobalExceptionHandler.*(..))

-> 하위 모든 메소드에 Aspect 를 적용.

args(exception, webrequest)

-> 메소드의 파라미터 값을 주입받음. ( 해당 타입이 순서대로 매칭되어야 AOP가 적용됨 )

@Before

-> GlobalExceptionHandler 클래스 하위 메소드가 실행 되기 전에 실행.

※ 참고한 블로그

https://shlee0882.tistory.com/206

Spring AOP, Aspect 개념 특징, AOP 용어 정리

1. Spring AOP의 핵심기능과 부가기능 - 업무 로직을 포함하는 기능을 핵심 기능(Core Concerns)- 핵심 기능을 도와주는 부가적인 기능(로깅, 보안)을 부가기능(Cross-cutting Concerns) 이라고 부른다. 2. AOP란?

shlee0882.tistory.com

https://engkimbs.tistory.com/entry/%EC%8A%A4%ED%94%84%EB%A7%81AOP

[Spring] 스프링 AOP (Spring AOP) 총정리 : 개념, 프록시 기반 AOP, @AOP

| 스프링 AOP ( Aspect Oriented Programming ) AOP는 Aspect Oriented Programming의 약자로 관점 지향 프로그래밍이라고 불린다. 관점 지향은 쉽게 말해 어떤 로직을 기준으로 핵심적인 관점, 부가적인 관점으로

engkimbs.tistory.com

https://mangkyu.tistory.com/231

[Spring] AOP Aspect에서 어노테이션 정보나 메소드의 파라미터값 가져오는 방법

Spring 프레임워크를 이용해 공부를 하다보면 AOP를 적용해야 하는 상황이 온다. 그리고 AOP를 적용하다보면 클래스나 메소드에 있는 어노테이션 또는 메소드로 넘겨진 파라미터 값을 필요로 할 때

mangkyu.tistory.com

ExceptionHandler (with. AOP) 에 대해서

오리토리 — Wed, 21 Aug 2024 11:15:47 +0900

프로젝트를 진행하면서 예외를 어떻게 관리할지 결정하는 것이 중요하고 어려운 단계인 지 알게 되었다..

AOP 란 ?

AOP는 Aspect Oriented Programming 의 약자로 OOP의 단점을 보완하기 위한 프로그래밍 방식이다. 간략하게 설명하면 여러 곳에서 사용되는 공통기능을 모듈화하고, 필요할 때 연결함으로써 유지보수, 재사용성에 용이하도록 프로그래밍 하는 것을 AOP 라고 한다.

@ExceptionHandler 는 Spring 에서 발생한 Exception을 기반으로 오류를 처리 할 수 있다. 하나의 클래스(컨트롤러 등)의 메서드에 추가되어 해당 클래스의 ExceptionHandler 로써 동작한다. 그렇기 때문에 컨트롤러가 늘어나면 중복코드가 늘어나는 방식이다.

그래서 모든 클래스에서 발생하는 예외를 처리 하고 싶을 때, 사용할 수 있는 개념이 AOP 이다. @ControllerAdvice 과 @RestControllerAdvice 2가지 종류가 있는데, @ControllerAdvice 어노테이션은 모든 컨트롤러에서 발생 할 수 있는 예외를 해당 어노테이션을 추가한 클래스에 존재하는 Exception Handler 로 처리 할 수 있도록 해준다. @RestControllerAdvice 는 @Controller + @ResponseBody 어노테이션이 추가된 어노테이션으로 @RestController + @ControllerAdvice 의 동일한 효과를 볼 수 있다.

AOP + ExceptionHandler 를 알기까지..

상황 : 응답코드가 "0000" 이 아닌 경우에는 화면에서 400 에러로 받으면서 오류내용을 표시해야 하고, 백에서는 해당 오류내용을 로그테이블에 저장시키고 싶음.

response = 외부 api 와의 통신 후 응답 받은 값.

// 통신은 성공하였지만 실패한 상황
if(!"0000".equals(response.resultCd)){
	throw new CustomizeException(400, [오류내용]);
}

그런데 throw 하는 순간 트랜잭션이 롤백 되면서 저장이 되지 않는 상황이 발생함..

그렇게 Exception 과 트랜잭션에 대해서 알아보게 됨.

Excption과 Trasaction 의 롤백!

@Transactional 어노테이션을 통해 트랜잭션을 선언 한 상태.

UnChecked Exception	Checked Exception
롤백 됨.	롤백 안됨.
RuntimeExeption 을 상속받은 Exception. 실행 중에 발생할 수 있는 예외를 의미. ex)NullPointerException, IndexOutOfBoundesException 등	ComplileException 이라고 불림. Exception 을 상속 받음. 컴파일 시점에서 예외에 대한 처리 (try-catch 또는 throw) 를 하지 않는 다면 컴파일 에러가 발생 ex) FileNotFoundExcetion 등

※ 아래 블로그를 참고하였음.

@Transactional 상태에서 Exception이 발생했을 때 Rollback 동작 과정

@Transactional 어노테이션을 통해 트랜잭션을 선언하고 메서드 내부 로직을 짜던 중 '트랜잭션 안에서 발생하는 예외와 그 예외를 처리하는 방법에 따라 어떻게 롤백이 되는지'에 대한 개념이 명확

wildeveloperetrain.tistory.com

위의 코드에서 CustomizeException 은 커스터마이징한 Exception 이며, RuntimeException 을 상속받고 있는 형태이기 때문에 롤백이 될 수 밖에 없는 상황이었다.

이미 개발되어 있는 구조를 바꿀 수 없는 상황이고 새로운 Exception 을 추가할까 고민에 빠지게 되는데... Exception이 발생 하게 되면 해당 오류시점에 catch 되는 설정이 없을까에 대해 엄청 검색하게 됨.

그러다가 ExceptionHandler 에 대해 알게됐음!!

AOP + ExceptionHandler

@ExceptionHandler : @Controller , @RestController 가 적용된 Bean 내에서 발생한 예외를 받아서 처리 할 수 있는 기능을 한다.

@ExceptionHandler(CustomizeException.class)
    public ResponseEntity<ExceptionResponse> handleCustomizeException(CustomizeException e, WebRequest request) {
        return new ResponseEntity<>(e, HttpStatus.BAD_REQUEST);
    }

ExceptionHandler 에는 value 속성을 가지고 있다. 때에 따라 특정 예외만 처리하고 싶은 경우에

@ExceptionHandler(CustomizeException.class) 와 같이 처리할 수 있다. (value 는 생략 가능!)

만약에 두가지 이상의 예외를 공통으로 처리 하고 싶으면,

@ExceptionHandler(value = { NullPointerException.class, ArithmeticException.class }) 이런식으로 처리 할 수 있다.

Controller 에서 작성하는 방법

  @Controller
  public class TestController {
    ...

    @ExceptionHandler(NullPointerException.class)
    public ResponseEntity handleNullPointerException(NullPointerException ne) {
      ...
    }

    @ExceptionHandler(ArithmeticException.class)
    public ResponseEntity handleArithmeticException(ArithmeticException ae) {
      ...
    }
  }

위와 같이 Controller 에서 예외처리를 하게 되면 컨트롤러가 생성 될 때마다 @ExceptionHandler 코드를 넣어줘야 하기 때문에 중복코드발생, 유지보수힘듬 이라는 단점이 있다.

이러한 단점을 해결하기 위해 AOP 방식으로 Exception 을 처리 할 수 있는 것이다.

그 때는 상단에 @ControllerAdvice 또는 @RestControllerAdvice 어노테이션을 사용해야 한다.

@ControllerAdvice 의 속성

  // 패키지를 지정하고 싶은 경우
  @ControllerAdvice(value = "test.package")
  public class TestControllerAdvice {
    ...
  }
  
  @ControllerAdvice(basePackages = "test.package")
  public class TestControllerAdvice {
    ...
  }
  
  // 특정클래스 기준으로 패키지를 지정하고 싶은 경우
  @ControllerAdvice(basePackageClasses = TestController.class)
  public class TestControllerAdvice {
    ...
  }
  
  // 특정클래스를 지정하고 싶은 경우
  @ControllerAdvice(assignableTypes = TestController.class)
  public class TestControllerAdvice {
    ...
  }
  
  // 어노테이션을 지정하고 싶은 경우
  @ControllerAdvice(annotations = Controller.class)
  public class TestControllerAdvice {
    ...
  }

@RestControllerAdvice 의 속성

@RestControllerAdvice 는 @ControllerAdvice 와 @ResponseBody 를 합친 어노테이션이다. @ControllerAdvice 와 동일한 기능을 하지만 예외를 body 에 담아 반환할 수 있다.

@ControllerAdvice
  public class TestControllerAdvice {
      @ExceptionHandler(NullPointerException.class)
      public String handleNullPointerException(NullPointerException ne) {
          return "Body Data";
      }
  }

@RestControllerAdvice
  public class TestControllerAdvice {
      @ExceptionHandler(NullPointerException.class)
      public String handleNullPointerException(NullPointerException ne) {
          return "Body Data";
      }
  }

확인해 보면 @RestContollerAdvice 는 "Body Data" 를 응답하는 것을 확인 할 수 있지만, @ControllerAdvice는 정형화된 포맷으로 응답하는 것을 확인 할 수 있을 것이다.

given-when-then 방식의 단위테스트

오리토리 — Tue, 10 Oct 2023 17:54:17 +0900

given-when-then 패턴 에 대해서 자세히 설명하기 전에 TDD 방식과 BDD 방식에 대한 사전설명이 필요하다.

1. TDD 와 BDD 란?

☝ TDD 란?

TDD(Test Diven Development) 란 테스트 주도 개발 이다.

즉, 테스트 코드를 작성하고 테스트가 정상적으로 돌아갈때까지 테스트를 하면서 코드를 작성하는 작업이다.

TDD의 예시 코드.

1. Test 클래스를 작성하여 테스트 하고 싶은 코드를 작성한다.

public class ArticleService{
}

public class ArticleServiceTest{
	ArticleService svc = new ArticleService();
    
    @Test
    void test(){
    	svc.searchArticle(null);
    }
}

2. 테스트코드에 작성한 함수를 부모 클래스에 생성한다.

public class ArticleService{
	public String searchArticle(String keyword){
    	return "keyword : " + keyword;
    }
}

3. 함수를 작성한 후, 예측한 값과 실제로 return 된 값이 동일한지 테스트한다.

(단위테스트에는 다양한 검증 코드가 존재한다. assertEquals 이외의 코드로도 활용가능.)

public class ArticleService{
	public String searchArticle(String keyword){
    	return "keyword : " + keyword;
    }
}

public class ArticleServiceTest{
	ArticleService svc = new ArticleService();
    
    @Test
    void test(){
    	String preResult = "keyword";
    	String result = svc.searchArticle(null);
        
        assertEquals(preResult, result);
    }
}

4. 테스트가 성공하면 코드작성은 종료되고, 테스트가 실패하면 반환하는 함수에서 오류가 있는 것이므로 수정을 반복한다.

✌ BDD 란?

BDD(Behavior Driven Development) 란 행동 주도 개발로, 사용자의 행위까지 생각하고 테스트 하며 개발한다.

BDD는 TDD 에서 파생된 테스트 방식이다. TDD 방식은 코드를 작성하기 전에 테스트를 먼저 작성한다 라는 방식이라면 BDD는 테스트 코드를 작성하기 전에 코드가 수행할 행위에 대한 명세를 먼저 작성한다 라는 방식이다.

TDD vs BDD

출처 : https://mingule.tistory.com/43

TDD, BDD란?

TDD (Test Driven Development) TDD란, 말 그대로 테스트 주도로 개발을 이끌어 나가는 것이다. 즉, 테스트를 먼저 작성하고 나서, 테스트가 정상적으로 돌아갈 때 까지 테스트를 하면서 코드를 작성하는

mingule.tistory.com

이 BDD에서 나온 패턴 중 하나가 given-when-then 패턴이다.

2. given-when-then 패턴

given : 시나리오 진행에 필요한 값을 설정. 테스트의 상태를 설정 [예측]

when : 시나리오 진행에 필요조건을 명시. 테스트하고자 하는 행동 [실행]

then : 시나리오를 완료했을 때 보장해야하는 결과를 명시. [검증]

이 패턴은 [ 준비 - 실행 - 검증] 이라고 할 수 있다.

패턴을 적용한 예시코드.

public class ArticleService{
	public String searchArticle(String keyword){
    	return "keyword : " + keyword;
    }
}

public class ArticleServiceTest{
	ArticleService svc = new ArticleService();
    
    @Test
    void test(){
    	// given
    	String preResult = "keyword";
        
        // when
    	String result = svc.searchArticle(null);
        
        // then
        assertEquals(preResult, result);
    }
}

별 차이가 없다. BDD 자체는 TDD의 새로운 개념이 아닌 더 협조적으로 사용하기 위한 방식이기 때문이다.

더 BDD 스럽게 테스트 방식은 BDDMockito 라이브러리를 이용하는 것이다.

BDDMockito를 이용한 BDD

예시코드.

@DisplayName("비즈니스 로직 - 게시글")
@ExtendWith(MockitoExtension.class)
public class ArticleServiceTest {
    // mock 을 주입하는 대상에 @InjectMocks 그 외는 @Mock
   @InjectMocks
   private ArticleService svc;

   @Mock
   private ArticleRepository articleRepository;

   @DisplayName("검색어 없이 게시글을 검색하면, 게시글 페이지를 반환한다.")
   @Test
    void noSearchArticle_ReturnArticlePage(){
       //Given
       Pageable pageable = Pageable.ofSize(20);
       given(articleRepository.findAll(pageable)).willReturn(Page.empty());

       //When
       Page<ArticleDto> articles = svc.searchArticle(null, null, pageable);

       //Then
       Assertions.assertThat(articles).isNotNull();
       then(articleRepository).should().findAll(pageable);
   }
}

코드분석.

위의 예시코드를 토대로 코드를 분석해보겠다.

- given : BDDMockito 의 내장 함수로 상황을 설정. 즉 이러한 값을 반환 할 것이라고 예측하는 것이다.

- articleRepository.findAll : Mocking 할 메서드

→ Unit Test 에서 중요한 것은 테스트 하려는 대상의 고립.

테스트 대상을 고립한다는 것은 테스트 대상에 연관된 다른 객체들은 관여하지 않도록

가짜 객체를 넣어줘야 한다는 의미이다.

이렇게 테스트 대상을 고립하기 위해 @Mock 으로 ArticleRepository 를 주입시켜 준 것이고,

실제 테스트 대상체는 svc.searchArticle 이지만 articleRepository.findAll 로 가짜로 실행 시키는 것이다.

- pageble : 메서드의 파라미터

→ pageble은 사용자의 파라미터로, 여기서 사용한 pageble 은 페이징 처리를 위한 파라미터이다.

메서드 안에 파라미터는 any 라는 BDDMockito 함수를 사용 할수 있다. (any 이외에도 여러가지가 있음.)

사용법은 any(Object object) 이고, Object 타입의 모든 객체라는 뜻이다.

ex) any(String.class) : 모든 String 객체가 가능하다.

- willReturn(Page.empty) : 해당 메서드가 반환하는 값.

→ willReturn 이외에도 will()(invocation을 통해 새로운 객체 반환 / 행동 반환 가능) , willThrow()(예외) 가 있다.

참고 : https://go-coding.tistory.com/102

TDD와 BDD에서 사용되는 given/when/then 행동과 실습

[Spring Boot] when(), given(), any() 및 BDD 설명 패스트 캠퍼스 강의를 듣던 도중 테스트 구문 작성 코드에서 처음 보는 코드를 보았다. when(this.todoRepository.save(any(TodoEntity.class))) .then(AdditionalAnswers.returnsFir

go-coding.tistory.com

즉, 위의코드를 해석하자면

articleRepository 에 정의된 findAll 메서드가 pageble 파라미터로 Page.empty 빈 값을 호출할 것이다 를 stubbing 하는 것이다.

※ stubbing ? Mock 객체의 행동을 조작하는 것을 말함.

게시판만들기 - 개발

오리토리 — Thu, 31 Aug 2023 15:07:09 +0900

0. Dependeny 설정

dependencies {
    implementation 'org.springframework.boot:spring-boot-starter-web'
    implementation 'org.springframework.boot:spring-boot-starter-data-jpa'
    compileOnly 'org.projectlombok:lombok'
    developmentOnly 'org.springframework.boot:spring-boot-devtools'
    annotationProcessor 'org.projectlombok:lombok'
    testImplementation 'org.springframework.boot:spring-boot-starter-test'

    runtimeOnly 'com.h2database:h2'
    runtimeOnly 'com.mysql:mysql-connector-j'
    testImplementation 'org.springframework.boot:spring-boot-starter-test'
}

src/main/resources/application.yml

debug: false
management.endpoints.web.exposure.include: "*"

logging:
  level:
    com.example.board: debug
    org.springframework.web.servlet: debug
    org.hibernate.type.descriptor.sql.BasicBinder: trace

spring:
  datasource:
    url: jdbc:mysql://localhost:3306/board
    username: root
    password: 
    driver-class-name: com.mysql.cj.jdbc.Driver
  jpa:
    open-in-view: false
    hibernate.ddl-auto: create
    show-sql: true
    defer-datasource-initialization: true
    properties:
      hibernate.format_sql: true
      hibernate.default_batch_fetch_size: 100
  h2.console.enabled: false
  sql.init.mode: always
  data.rest:
    base-path: /api
    detection-strategy: annotated

---

spring:
  config.activate.on-profile: testdb
#  datasource.url: jdbc:h2:mem:testdb

src/main/resources/data.sql

-- article 테이블에 레코드 추가
INSERT INTO article (title, content, hash_tag, created_at, created_by, modified_at, modified_by)
VALUES ('Article Title', 'Article Content', 'HashTag', '2021-05-30 23:53:46', 'woo', '2021-03-10 08:48:50', 'woo');

-- article_comment 테이블에 레코드 추가
INSERT INTO article_comment (article_id, created_at, modified_at, created_by, modified_by, content)
VALUES (1, '2021-05-30 23:53:46', '2021-03-10 08:48:50', 'woo', 'woo', 'comment content');

해당 내용은 예시이므로 원하는 sql 을 작성하여 넣어놓으면 됨.

1. Entity 생성

Article(게시글)

package com.example.board.domain;

import jakarta.persistence.*;
import lombok.Getter;
import lombok.Setter;
import lombok.ToString;
import org.springframework.data.annotation.CreatedBy;
import org.springframework.data.annotation.CreatedDate;
import org.springframework.data.annotation.LastModifiedBy;
import org.springframework.data.annotation.LastModifiedDate;
import org.springframework.data.jpa.domain.support.AuditingEntityListener;

import java.time.LocalDateTime;
import java.util.LinkedHashSet;
import java.util.Objects;
import java.util.Set;

@ToString
@Getter
@Table(indexes = {
        @Index(columnList = "title"),
        @Index(columnList = "hashTag"),
        @Index(columnList = "createdAt"),
        @Index(columnList = "createdBy")
})
@EntityListeners(AuditingEntityListener.class)
@Entity
public class Article {
    @Id
    @GeneratedValue(strategy = GenerationType.IDENTITY)
    // DB에 저장 후 기본 키 값을 구할 수 있다.
    private Long id;

    @Setter @Column(nullable = false)
    private String title;   // 제목

    @Setter @Column(nullable = false, length = 10000)
    private String content; // 본문

    @ToString.Exclude
    @OrderBy("id")
    @OneToMany(mappedBy = "article", cascade = CascadeType.ALL)
    private final Set<ArticleComment> articleComments = new LinkedHashSet<>();

    @Setter
    private String hashTag; // 해시태그

    @CreatedDate private LocalDateTime createdAt;    // 생성일자
    @CreatedBy @Column(length = 100) private String createdBy;           // 셍성자
    @LastModifiedDate private LocalDateTime modifiedAt;   // 수정일자
    @LastModifiedBy @Column(length = 100) private String modifiedBy;          // 수정자

    protected Article(){}

    private Article(String title, String content, String hashTag){
        this.title = title;
        this.content = content;
        this.hashTag = hashTag;
    }

    public static Article of(String title, String content, String hashTag){
        return new Article(title, content, hashTag);
    }

    @Override
    public boolean equals(Object o) {
        if (this == o) return true;
        if (!(o instanceof Article that)) return false;
        return this.getId() != null && this.getId().equals(that.getId());
    }

    @Override
    public int hashCode() {
        return Objects.hash(this.getId());
    }
}

코드 설명

@ToString.Exclude
    @OrderBy("id")
    @OneToMany(mappedBy = "article", cascade = CascadeType.ALL)
    private final Set<ArticleComment> articleComments = new LinkedHashSet<>();

- @OneToMany : 1 : N 관계를 명시한 것으로, 1개의 게시글에 여러개의 댓글이 보여질 수 있는 관계임.

- mappedBy : article 테이블에서 왔다는 것을 명시.

- casecade : 엄청난 종속성을 가지므로 유연하게 수정하는 것이 힘들다. 원치않는 데이터 소실이 있을 수 있음.

=> CaseCadeType.All : CaseCadeType.PERSIST 와 CaseCadeType.REMOVE 두개를 합친 것.

- @Setter : title, content, hashTag 는 수정가능함.

ArticleComment(게시글댓글)

package com.example.board.domain;

import jakarta.persistence.*;
import lombok.Getter;
import lombok.Setter;
import lombok.ToString;
import org.springframework.data.annotation.CreatedBy;
import org.springframework.data.annotation.CreatedDate;
import org.springframework.data.annotation.LastModifiedBy;
import org.springframework.data.annotation.LastModifiedDate;
import org.springframework.data.jpa.domain.support.AuditingEntityListener;

import java.time.LocalDateTime;
import java.util.Objects;

@Getter
@ToString
@Table(indexes = {
        @Index(columnList = "content"),
        @Index(columnList = "createdAt"),
        @Index(columnList = "createdBy")
})
@EntityListeners(AuditingEntityListener.class)
@Entity
public class ArticleComment {
    @Id
    @GeneratedValue(strategy = GenerationType.IDENTITY)
    private Long id;

    @Setter
    @ManyToOne(optional = false)
    private Article article;        // 게시글 id

    @Setter @Column(nullable = false, length = 2000)
    private String content;         // 본문

    @CreatedDate
    private LocalDateTime createdAt;    // 생성일자
    @CreatedBy
    @Column(length = 100) private String createdBy;           // 셍성자
    @LastModifiedDate
    private LocalDateTime modifiedAt;   // 수정일자
    @LastModifiedBy
    @Column(length = 100) private String modifiedBy;          // 수정자

    protected ArticleComment(){}

    // @NoArgsConstructor 어노테이션으로 대체가능.
    private ArticleComment(Article article, String content) {
        this.article = article;
        this.content = content;
    }

    public static ArticleComment of(Article article, String content){
        return new ArticleComment(article, content);
    }

    @Override
    public boolean equals(Object o) {
        if (this == o) return true;
        if (!(o instanceof ArticleComment that)) return false;
        return this.getId() != null && this.getId().equals(that.getId());
    }

    @Override
    public int hashCode() {
        return Objects.hash(this.getId());
    }

}

코드 설명

@Setter
@ManyToOne(optional = false)
private Article article; // 게시글 id

- @ManyToOne : N : 1 관계임을 명시함.

- article 의 Primary Key 를 외래키로 가짐을 명시한것임.

- @Setter : content 수정가능함.

2. JPA Repository 테스트 코드 작성

package com.example.board.repository;

import com.example.board.config.JpaConfig;
import com.example.board.domain.Article;
import org.assertj.core.api.Assertions;
import org.junit.jupiter.api.DisplayName;
import org.junit.jupiter.api.Test;
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.boot.test.autoconfigure.orm.jpa.DataJpaTest;
import org.springframework.context.annotation.Import;

import java.util.List;

@DisplayName("jpa 연결 테스트")
@Import(JpaConfig.class)
@DataJpaTest
public class JpaRepositoryTest {
    private final ArticleRepository articleRepository;
    private final ArticleCommentRepository articleCommentRepository;

    // 생성자주입패턴 생성
    public JpaRepositoryTest(
                            @Autowired ArticleRepository articleRepository
                           ,@Autowired ArticleCommentRepository articleCommentRepository
    ) {
        this.articleRepository = articleRepository;
        this.articleCommentRepository = articleCommentRepository;
    }

    @DisplayName("select 테스트")
    @Test
    void crudTest1(){
        // Given

        // When
        List<Article> articles = articleRepository.findAll();
        // Then
        Assertions.assertThat(articles)
                  .isNotNull().hasSize(1);
    }
}

Test 코드 실행 중에 오류가 발생하였다..

아래 오류들에 대해서 정리해 놓음.

1. FOREIGN KEY 오류

✍ 오류내용

Caused by: org.h2.jdbc.JdbcSQLIntegrityConstraintViolationException: Referential integrity constraint violation: "FKGHMOCQKGQS5TKMUCF5PUTW64T: PUBLIC.ARTICLE_COMMENT FOREIGN KEY(ARTICLE_ID) REFERENCES PUBLIC.ARTICLE(ID) (CAST(2001 AS BIGINT))"; SQL statement:

✍ 오류원인

외래키에 대한 참조 무결성 제약을 위반한 상황이다.

참조 무결성 제약 조건이란 각 릴레이션(관계)은 참조할 수 없는 외래키 값을 가질 수 없어야 한다 는 제약조건이다.

✍ 오류가 발생하게 된 상황

- MySql DB 를 연결.

- data.sql 을 사용하여 article 과 article_comment 테이블에 insert 하는 쿼리를 작성해놓음.

- JAP Repository 로 findAll() 테스트를 진행.

✍ 해결방법

☝ 부모 테이블에 먼저 데이터를 insert함.

: 검색해보니 부모테이블에 데이터가 없는데 자식 테이블에 insert 하려고 하기 때문에 발생하는 오류라고 한다.

그래서 부모 테이블에 데이터를 먼저 insert 한 후에 자식 테이블에 insert 하면 해결된다고 하는데, data.sql 에

부모테이블인 article 에 insert 하는 구문이 먼저 있기 때문에 해당 해결책에 대해서는 이해가 되지 않았다..

✌ casecade = CasecadeType.REMOVE 를 설정.

: 가장 많이 나온 해결책으로 해당 설정을 통해 부모의 영속성 상태가 자식에게 전이 됨으로써 부모인 article 이 제 거될 때 연관된 자식인 article_comment 도 함께 제거됨을 명시한것. 하지만 이미 CasecaseType.ALL 로 명시하고

있기 때문에 해당 옵션을 붙여도 해결되지 않았다.

아마 대부분의 상황이 위에서 말한 해결책으로 해결이 될것이라고 본다. 하지만 나는 아무리 검색하고 해봐도 해결이 되지 않았다... 한참을 헤맨끝에 어이없는 실수때문에 되지 않았던 것..ㅠㅠ

첫번째 해결책에서 말한 거처럼 부모에 데이터가 있어야 하는데 없어서 발생했던 오류였다. 나는 이미 데이터를 부모 테이블인 article 에 데이터를 이미 insert 했다고 생각했는데 조회해 보니 insert 가 되어 있지 않았다..

그리고 artilce.id 값이 나중에 자동 생성 되기 때문에 article_comment 테이블 입장에서는 참조할 article_id 가 없기 때문에 오류가 발생하였을 것.

즉, 결론적으로는 article 테이블(부모테이블) 에 테스트 코드를 실행시키기 전에 무조건 1개 이상의 데이터를 insert 하고 실행이 되어야 한다!

+ 추가적으로 article_comment 에 insert 할때는 article_id 값이 article 에 있는 id 로만 구성되어야함.

2. PRIMARY KEY 오류

✍ 오류내용

org.springframework.dao.DataIntegrityViolationException: could not execute statement [Unique index or primary key violation: "PRIMARY KEY ON PUBLIC.ARTICLE(ID)

✍ 오류원인

DB에 INSERT 할때 PRIMARY KEY 또는 UNIQUE KEY 가 중복되어 발생하였다.

✍ 오류가 발생하게 된 상황

- data.sql 을 사용해서 미리 테이블에 데이터가 저장되어 있음.

- JPA 를 사용해서 save() 테스트를 하는 와중에 발생함.

✍ 해결방법

아래 블로그에서 엄청 자세하게 설명해주고 있음.ㅠㅠ

아래 블로그를 참고하여 article_comment 와 article 의 id 컬럼을 빼고 insert 하니 문제 해결되었다.

기존
INSERT INTO article (id, title, content, hash_tag, created_at, created_by, modified_at, modified_by) ~~
INSERT INTO article_comment (id, article_id, created_at, modified_at, created_by, modified_by, content) ~~

수정

INSERT INTO article (title, content, hash_tag, created_at, created_by, modified_at, modified_by) ~~
INSERT INTO article_comment (article_id, created_at, modified_at, created_by, modified_by, content) ~~

https://velog.io/@youswim96/Unique-index-or-primary-key-violation-%ED%95%B4%EA%B2%B0-%EB%B0%A9%EB%B2%95

Unique index or primary key violation 해결 방법

위와 같은 오류가 발생했습니다.

velog.io

Oracle - 성능비교

오리토리 — Mon, 28 Aug 2023 17:23:07 +0900

업무 중에 SELECT 절에서 집계함수를 사용하는 경우와 서브쿼리를 사용하여 집계함수를 사용했을 경우에 대한 성능이 달라서 어떻게 다른지 확실하게 궁금증을 해결하고 싶어졌다.

그래서 DBeaver의 실행계획법을 통해 궁금증을 해결하고자 한다.

※ DBearver, Oracle 을 사용할 예정이며 DBeaver 의 실행계획법은 Ctrl + Shift + E 를 통해 실행 시킬 수 있다.

1. 집계함수

WITH A AS (
    SELECT A.RUN_DT
         , A.DAY_NM 
         , A.YY
         , A.TM_GBN
         , A.CAMP_GBN
      FROM TA A
      INNER JOIN TB B
        ON A.CAMP_GBN      = B.CAMP_GBN
       AND A.RUN_AREA_CD   = B.RUN_AREA_CD
     WHERE 1=1
       AND A.YY            = '2016'
       AND A.TM_GBN        = '10'
     GROUP BY A.RUN_DT , A.YY, A.TM_GBN, A.CAMP_GBN
)
SELECT A.RUN_DT                                                                                        AS RUN_DT  -- 운행일자
     , A.DAY_NM                                                                                        AS DAY_NM  -- 요일
     , COUNT(B1.RUN_AREA_CD) AS SCH_AREA_CNT1
     , SUM(B1.GO_SCH_RIDE_RCNT) AS SCH_RIDE_RCNT1
     , COUNT(B1.RUN_AREA_CD) AS HOME_AREA_CNT1
     , SUM(B1.GO_HOME_RIDE_RCNT) AS HOME_RIDE_RCNT1
     , COUNT(B2.RUN_AREA_CD) AS SCH_AREA_CNT2
     , SUM(B2.GO_SCH_RIDE_RCNT) AS SCH_RIDE_RCNT2
     , COUNT(B2.RUN_AREA_CD) AS HOME_AREA_CNT2
     , SUM(B2.GO_HOME_RIDE_RCNT) AS HOME_RIDE_RCNT2
  FROM A
  LEFT OUTER JOIN TC B1
    ON A.YY = B1.YY
    AND A.TM_GBN = B1.TM_GBN
    AND A.CAMP_GBN = B1.CAMP_GBN
    AND B1.CAMP_GBN = '1'
    AND TRUNC(B1.RUN_DT) = A.RUN_DT
  LEFT OUTER JOIN TC B2
    ON A.YY = B2.YY
    AND A.TM_GBN = B2.TM_GBN
    AND A.CAMP_GBN = B2.CAMP_GBN
    AND B2.CAMP_GBN = '2'
    AND TRUNC(B2.RUN_DT) = A.RUN_DT		  	
WHERE 1=1
GROUP BY A.RUN_DT, A.DAY_NM
ORDER BY A.RUN_DT

실행계획결과

※흰색으로 칠한 부분은 실제 테이블 명칭으로 상단 쿼리에서 테이블 " TC " 부분이 해당됨.

빨강색 : TA

보라색 : TB

실행계획법 분석

✍ 실행계획법 용어

- Cost : 쿼리를 수행함에 있어 사용된 자원이나, 작업의 단위로 적을수록 쿼리 효율이 높다.

- Cardinality : 행 집합에서 행의 수. 적게 나타날 수록 SQL 속도가 빠르다.

행 집압은 기본테이블, View, Join, GROUP BY 의 결과.

- SORT (AGGREGATE) : 전체 로우를 대상으로 집계를 수행.

- HASH JOIN : 해쉬 알고리즘을 이용해서 데이터를 메모리에 올려놓고, 메모리에서 조인하는 조인방법.

- HASH (GROUP BY) : 집계 할때 사용되는 구문으로, SORT(GROUP BY) 와 달리 순서를 보장하지 않음.

- 가장 안쪽으로 들여쓰기 된 스텝을 시작으로 상위로 읽음.

✍ 실행계획법 분석

1번 : PK_TA 인텍스를 사용하여 INDEX RANGE SCAN 을 하면서 조건에 만족하는 인덱스 블록과 키 값을 검색한 결과를 반환.

PK_TB 인덱스에서 INDEX UNIQUE SCAN 방식으로 검색한 결과의 ROWID 를 반환.

2번 : 1번에서 반환된 데이터들을 기준으로 NESTED LOOP JOIN 방식으로 1번에서 반환된 데이터의 숫자만큼 반복하여 조인한 결과를 반환.

3번 : TC B2를 FULL TABLE SCAN 방식으로 전체 데이터를 읽어 조건에 맞는 데이터를 반환.

4번 : 1번에서 반환된 데이터와 3번에서 번환된 데이터에 대해 HASH JOIN OUTER 방식으로 JOIN 함.

5번 : TC B1을 FULL TABLE SCAN 방식으로 전체 데이터를 읽어 조건에 맞는 데이터를 반환.

6번 : 1번에서 반환된 데이터와 5번에서 번환된 데이터에 대해 HASH JOIN OUTER 방식으로 JOIN 함.

7번[HASH (GROUP BY)] : 4번과 6번의 데이터에 대해 집계함.

※ 아래 블로그 참고하여 정리함.

https://coding-factory.tistory.com/744

[DB] 데이터베이스 실행 계획에 대하여

실행 계획이란? 실행계획이란 사용자가 SQL을 실행하여 데이터를 추출하려고 할 때 옵티마이저가 수립하는 작업 절차입니다. 이렇게 만들어진 실행 계획은 여러 가지 방법을 통해 확인할 수 있

coding-factory.tistory.com

2. 서브쿼리 + 집계함수

WITH A (
	SELECT A.RUN_DT
    	  ,A.DAY_NM
          ,A.YY
          ,A.TM_GBN
          ,A.CAMP_GBN
	FROM TA A
	INNER JOIN TB B
        ON A.CAMP_GBN      = B.CAMP_GBN
       AND A.RUN_AREA_CD   = B.RUN_AREA_CD
     WHERE 1=1
       AND A.YY            = '2016'
       AND A.TM_GBN        = '10'
     GROUP BY A.RUN_DT , A.YY, A.TM_GBN, A.CAMP_GBN
)
SELECT A.RUN_DT
     , A.DAY_NM
     ,MAX((SELECT COUNT(*)
         FROM UNI.STUD807 F
        WHERE F.YY = A.YY AND F.TM_GBN = A.TM_GBN AND F.CAMP_GBN = '1' AND TRUNC(F.RUN_DT) = A.RUN_DT)) AS SCH_AREA_CNT1
     ,MAX((SELECT SUM(F.GO_SCH_RIDE_RCNT)
         FROM TC F
        WHERE F.YY = A.YY AND F.TM_GBN = A.TM_GBN AND F.CAMP_GBN = '1' AND TRUNC(F.RUN_DT) = A.RUN_DT))AS SCH_RIDE_RCNT1
     ,MAX((SELECT COUNT(*)
         FROM TC F
        WHERE F.YY = A.YY AND F.TM_GBN = A.TM_GBN AND F.CAMP_GBN = '1' AND TRUNC(F.RUN_DT) = A.RUN_DT)) AS HOME_AREA_CNT1
     ,MAX((SELECT SUM(F.GO_HOME_RIDE_RCNT)
         FROM TC F
        WHERE F.YY = A.YY AND F.TM_GBN = A.TM_GBN AND F.CAMP_GBN = '1' AND TRUNC(F.RUN_DT) = A.RUN_DT)) AS HOME_RIDE_RCNT1
     ,MAX((SELECT COUNT(*)
         FROM TC F
        WHERE F.YY = A.YY AND F.TM_GBN = A.TM_GBN AND F.CAMP_GBN = '2' AND TRUNC(F.RUN_DT) = A.RUN_DT)) AS SCH_AREA_CNT2
     ,MAX((SELECT SUM(F.GO_SCH_RIDE_RCNT)
         FROM TC F
        WHERE F.YY = A.YY AND F.TM_GBN = A.TM_GBN AND F.CAMP_GBN = '2' AND TRUNC(F.RUN_DT) = A.RUN_DT)) AS SCH_RIDE_RCNT2
     ,MAX((SELECT COUNT(*)
         FROM TC F
        WHERE F.YY = A.YY AND F.TM_GBN = A.TM_GBN AND F.CAMP_GBN = '2' AND TRUNC(F.RUN_DT) = A.RUN_DT)) AS HOME_AREA_CNT2
     ,MAX((SELECT SUM(F.GO_HOME_RIDE_RCNT)
         FROM TC F
        WHERE F.YY = A.YY AND F.TM_GBN = A.TM_GBN AND F.CAMP_GBN = '2' AND TRUNC(F.RUN_DT) = A.RUN_DT)) AS HOME_RIDE_RCNT2
  FROM A  	
WHERE 1=1
GROUP BY A.RUN_DT, A.DAY_NM
ORDER BY A.RUN_DT

실행계획 결과

※흰색으로 칠한 부분은 실제 테이블 명칭으로 상단 쿼리에서 테이블 " TC " 부분이 해당됨.

빨강색 : TA

보라색 : TB

실행계획 분석

1번 : PK_TA 인텍스를 사용하여 INDEX RANGE SCAN 을 하면서 조건에 만족하는 인덱스 블록과 키 값을 검색한 결과를 반환.

PK_TB 인덱스에서 INDEX UNIQUE SCAN 방식으로 검색한 결과의 ROWID 를 반환.

2번 : 1번에서 반환된 데이터들을 기준으로 NESTED LOOP JOIN 방식으로 1번에서 반환된 데이터의 숫자만큼 반복하여 조인한 결과를 반환.

3번[HASH(GROUP BY)] : 2번에서 반환된 데이터에 대해 GROUP BY. (view 에 해당하는 group by)

4번[VIEW] : VIEW 생성함.

5번[HASH(GROUP BY)] : group by a.run_dt, a.day_nm 실행함.

6번 : PK_TC 인덱스를 사용하여 INDEX RANGE SCAN 을 하면서 조건에 만족하는 인덱스 블록과 키 값을 검색한 결과를 반환.

7번 : 6번에서 읽은 ROWID 를 기반으로 TC 테이블로 이동하여 조건에 부합하는 결과를 반환.

8번[SORT(AGGREGATE)] : 7번에서 반환한 모든 row 에 대해 집계를 실행함.

6번~8번까지 반복한다.

3. 결론

1번에 대한 실행계획법

2번에 대한 실행계획법

두개의 차이점을 두고 비교하면 1번 view 에 대한 HASH(GROUP BY) 를 확인하면 keys = 50 개로 group by 를 하고 있고,

2번 view 에 대해서는 keys = 4 개로 group by 를 하고 있다.

그리고 최대한 FULL SCAN 을 안 하는게 쿼리 성능에 좋다.