A steady developer

[JAVA] 멀티프로세스&멀티쓰레드란

코드기록사 — Mon, 30 Mar 2026 01:42:59 +0900

Java 멀티프로세스 & 멀티스레드 완전 정복

들어가며

Java 백엔드 개발을 하다 보면 멀티스레드, 동시성이라는 말을 자주 접하게 됩니다. 그런데 이런 생각을 한 번쯤 해봤을 것입니다.

"멀티프로세스와 멀티스레드가 뭐가 다른 거지? 그냥 여러 개 동시에 돌리는 거 아닌가?"

둘 다 '동시에 여러 작업을 처리'하지만, 메모리 구조와 동작 방식이 완전히 다릅니다. 이 글에서는 기본 개념부터 Java 코드 예제, 그리고 멀티스레드에서 발생하는 실제 문제점까지 차근차근 살펴보겠습니다.

1. 프로세스 vs 스레드 기본 개념

2. 멀티프로세스 — 구조, Java 예제, 한계

3. 멀티스레드 — 구조, Java 예제

4. 멀티스레드 문제점 심화 (경쟁 조건, 데드락, 가시성)

5. 멀티프로세스 vs 멀티스레드 비교 & 선택 기준

프로세스와 스레드란?

멀티프로세스와 멀티스레드를 이해하려면, 먼저 프로세스(Process)와 스레드(Thread)가 무엇인지 알아야 합니다.

프로세스 (Process)

운영체제로부터 독립적인 메모리 공간을 할당받은 실행 단위입니다. 각 프로세스는 Code, Data, Heap, Stack 영역을 독립적으로 가지며, 다른 프로세스의 메모리에 직접 접근할 수 없습니다.

스레드 (Thread)

프로세스 내부에서 실행되는 작업의 단위입니다. 같은 프로세스 내의 스레드들은 Code, Data, Heap 영역을 공유하고, Stack만 독립적으로 가집니다.

메모리 구조 비교

영역	멀티프로세스	멀티스레드
Code 영역	각 프로세스 독립	스레드 간 공유
Data 영역	각 프로세스 독립	스레드 간 공유
Heap 영역	각 프로세스 독립	스레드 간 공유
Stack 영역	각 프로세스 독립	각 스레드 독립

핵심 요약
프로세스는 완전히 독립된 실행 공간이고, 스레드는 프로세스 안에서 메모리를 나눠 쓰는 실행 흐름입니다. 이 차이가 멀티프로세스와 멀티스레드의 모든 특성 차이로 이어집니다.

멀티프로세스 (Multi-Process)

멀티프로세스란 하나의 작업을 여러 개의 독립된 프로세스로 나누어 처리하는 방식입니다. 각 프로세스는 완전히 독립된 메모리를 가지므로, 하나가 비정상 종료되어도 다른 프로세스에 영향을 주지 않습니다.

실생활 비유
각자 독립된 주방(메모리)을 가진 여러 요리사가 별개의 요리를 만드는 것과 같습니다. 한 요리사가 실수해도 다른 주방은 영향을 받지 않습니다.

Java에서 새로운 프로세스를 생성할 때는 ProcessBuilder를 사용합니다.

import java.util.*;

public class MultiProcessExample {

    public static void main(String[] args) throws Exception {

        List<Process> processes = new ArrayList<>();

        // 3개의 독립 프로세스 생성
        for (int i = 0; i < 3; i++) {
            ProcessBuilder pb = new ProcessBuilder(
                "java", "-cp", System.getProperty("java.class.path"),
                "Worker", String.valueOf(i)
            );
            pb.redirectErrorStream(true);
            Process process = pb.start();
            processes.add(process);

            System.out.println("프로세스 " + i + " 시작. PID: " + process.pid());
        }

        // 모든 프로세스 종료 대기
        for (Process p : processes) {
            int exitCode = p.waitFor();
            System.out.println("프로세스 종료. 코드: " + exitCode);
        }
    }
}

// 별도 프로세스에서 실행될 Worker 클래스
class Worker {
    public static void main(String[] args) throws InterruptedException {
        int id = Integer.parseInt(args[0]);
        System.out.println("Worker-" + id + ": 작업 시작");
        Thread.sleep(1000);
        System.out.println("Worker-" + id + ": 작업 완료");
    }
}

멀티프로세스의 한계
프로세스 간 데이터를 주고받으려면 IPC(Inter-Process Communication) — 소켓, 파이프, 공유 메모리 등을 사용해야 합니다. 또한 프로세스 생성 시 메모리를 통째로 복제하므로 생성 비용이 매우 크고, 컨텍스트 스위칭 시 PCB 전체를 교체해야 해 오버헤드가 큽니다.

멀티스레드 (Multi-Thread)

멀티스레드란 하나의 프로세스 내에서 여러 스레드를 동시에 실행하는 방식입니다. 스레드들은 같은 메모리 공간을 공유하기 때문에 데이터 교환이 빠르고 생성 비용도 낮습니다.

실생활 비유
같은 주방(메모리)에서 여러 요리사가 재료(데이터)를 함께 쓰며 요리하는 것. 빠르고 효율적이지만, 같은 재료를 동시에 건드리려다 충돌이 날 수 있습니다.

방법 1 — Thread 직접 생성

public class BasicThreadExample {

    public static void main(String[] args) throws InterruptedException {

        Thread t1 = new Thread(() -> {
            for (int i = 0; i < 3; i++) {
                System.out.println("[Thread-1] 작업 " + i);
            }
        });

        Thread t2 = new Thread(() -> {
            for (int i = 0; i < 3; i++) {
                System.out.println("[Thread-2] 작업 " + i);
            }
        });

        t1.start(); // start()로 실행 (run() 직접 호출)
        t2.start();

        t1.join();  // t1 종료 대기
        t2.join();  // t2 종료 대기

        System.out.println("모든 스레드 완료");
    }
}

방법 2 — ExecutorService

import java.util.concurrent.*;

public class ExecutorExample {

    public static void main(String[] args) throws Exception {

        // 스레드 풀 생성 (CPU 코어 수만큼)
        ExecutorService executor = Executors.newFixedThreadPool(
            Runtime.getRuntime().availableProcessors()
        );

        List<Future<String>> futures = new ArrayList<>();

        for (int i = 0; i < 5; i++) {
            final int taskId = i;
            Future<String> future = executor.submit(() -> {
                Thread.sleep(500);
                return "Task-" + taskId + " 완료 by " + Thread.currentThread().getName();
            });
            futures.add(future);
        }

        for (Future<String> f : futures) {
            System.out.println(f.get()); // 결과 대기
        }

        executor.shutdown(); // 반드시 종료 호출!
    }
}

실무 팁
Thread를 직접 생성하는 방식은 학습용으로만 사용하고, 실무에서는 ExecutorService 또는 Spring의 @Async + ThreadPoolTaskExecutor를 사용하세요. 스레드 생성·종료 비용을 줄이고 스레드 수를 제어할 수 있습니다.

멀티스레드의 문제점

공유 메모리는 멀티스레드의 강점이지만, 동시에 가장 위험한 특성이기도 합니다. 반드시 알아야 할 3가지 핵심 문제를 살펴봅니다.

① 경쟁 조건 (Race Condition)

두 스레드가 동시에 같은 데이터를 읽고 쓸 때 의도치 않은 결과가 발생합니다. count++는 단순해 보이지만, 실제로는 읽기 → 증가 → 쓰기 3단계 연산입니다.

시점	Thread-1	Thread-2
T1	count 읽음 → 0
T2		count 읽음 → 0
T3	0+1 = 1 → count에 씀
T4		0+1 = 1 → count에 씀
결과	count = 1 (기대값: 2) — 데이터 유실 발생!

import java.util.concurrent.atomic.*;

public class RaceConditionDemo {

    static int unsafeCount = 0;                        // 위험
    static AtomicInteger safeCount = new AtomicInteger(0); // 안전

    public static void main(String[] args) throws InterruptedException {
        Thread t1 = new Thread(() -> {
            for (int i = 0; i < 1000; i++) safeCount.incrementAndGet();
        });
        Thread t2 = new Thread(() -> {
            for (int i = 0; i < 1000; i++) safeCount.incrementAndGet();
        });

        t1.start(); t2.start();
        t1.join();  t2.join();

        System.out.println("결과: " + safeCount.get()); // 항상 2000
    }
}

해결 방법
synchronized 키워드로 임계 구역 보호, AtomicInteger 등 java.util.concurrent.atomic 패키지 활용, ReentrantLock 사용

② 데드락 (Deadlock)

두 스레드가 서로가 가진 락을 기다리며 영원히 멈춰버리는 상태입니다. 프로그램이 아무 오류 없이 응답만 안 하는 원인 1위입니다.

Thread-A	Thread-B
Lock-1 보유 중	Lock-2 보유 중
Lock-2 요청 → 대기	Lock-1 요청 → 대기
서로 상대방의 락이 풀리길 기다리며 무한 대기 (데드락)

public class DeadlockDemo {
    static final Object lockA = new Object();
    static final Object lockB = new Object();

    // 데드락 발생 코드 — 락 획득 순서가 반대
    static void badThread1() {
        synchronized (lockA) {
            synchronized (lockB) { }  // lockB 대기 → 데드락!
        }
    }

    static void badThread2() {
        synchronized (lockB) {
            synchronized (lockA) { }  // lockA 대기 → 데드락!
        }
    }

    // 해결: 모든 스레드가 동일한 순서로 락 획득
    static void safeThread1() {
        synchronized (lockA) {        // 항상 A → B 순서
            synchronized (lockB) { }
        }
    }

    static void safeThread2() {
        synchronized (lockA) {        // 동일하게 A → B 순서
            synchronized (lockB) { }
        }
    }
}

해결 방법
락 획득 순서를 모든 스레드에서 동일하게 유지, tryLock() 타임아웃 활용, 락 범위 최소화

③ 가시성 문제 (Visibility Problem)

각 CPU 코어는 캐시 메모리를 가집니다. 한 스레드가 값을 변경해도 다른 스레드의 CPU 캐시에는 아직 이전 값이 남아 있을 수 있어, 변경 사항을 인식하지 못하는 문제입니다.

public class VisibilityDemo {

    // volatile 없으면: Thread-1이 변경해도 Thread-2가 인식 못할 수 있음
    private volatile boolean running = true;

    public void start() {
        // Thread-1: running 플래그 모니터링
        Thread worker = new Thread(() -> {
            while (running) {        // volatile로 항상 최신값을 메인 메모리에서 읽음
                // 작업 수행...
            }
            System.out.println("Worker 종료됨");
        });

        // Thread-2: 1초 후 종료 신호 전송
        Thread stopper = new Thread(() -> {
            try { Thread.sleep(1000); } catch (InterruptedException e) {}
            running = false;         // volatile이므로 메인 메모리에 즉시 반영
            System.out.println("종료 신호 전송");
        });

        worker.start();
        stopper.start();
    }
}

주의: volatile ≠ 동기화
volatile은 가시성만 보장하며, 원자성(atomicity)은 보장하지 않습니다. count++처럼 복합 연산은 여전히 Race Condition이 발생합니다. 복합 연산에는 AtomicInteger나 synchronized를 사용해야 합니다.

멀티프로세스 vs 멀티스레드 비교

구분	멀티프로세스	멀티스레드
메모리 구조	독립된 메모리 공간	메모리 공유 (Heap, Code)
생성 비용	높음 (메모리 복제)	낮음 (스택만 추가)
컨텍스트 스위칭	무거움 (PCB 전체 교체)	가벼움 (스택/레지스터만)
데이터 공유	IPC 필요 (소켓, 파이프)	직접 공유 — 빠름
안정성	높음 (독립 → 충돌 없음)	낮음 (하나 죽으면 전체 위험)
동기화 이슈	없음	있음 (Race Condition, Deadlock)
Java 구현	ProcessBuilder, Runtime.exec()	Thread, ExecutorService, @Async
대표 사례	Chrome 탭, Nginx worker, MSA	웹 서버, DB 커넥션 풀, 채팅 서버

언제 무엇을 선택할까?

멀티프로세스는 프로세스 하나가 죽어도 전체 서비스가 유지돼야 할 때, 보안상 완전한 격리가 필요할 때, 독립 배포와 스케일아웃이 필요한 MSA 구조에 적합합니다.

멀티스레드는 I/O 대기 시간 동안 다른 작업을 처리해야 할 때, 빠른 데이터 공유가 필요할 때, 메모리 제약이 있고 가볍게 동시성을 구현해야 할 때 적합합니다.

마치며

멀티프로세스와 멀티스레드는 단순히 "동시에 여러 개를 실행하는 것"이 아니라, 메모리 구조와 자원 공유 방식이 근본적으로 다른 두 가지 접근 방식입니다.

특히 멀티스레드에서 발생하는 Race Condition, Deadlock, 가시성 문제는 Java 백엔드 면접에서도 자주 나오는 주제이니 각 문제의 원인과 해결책을 함께 이해해두면 좋습니다.

[JAVA] 애너테이션(annotaion)이란?

코드기록사 — Fri, 27 Mar 2026 01:50:14 +0900

애너테이션(annotaion)이란?

들어가며

Spring이나 NestJS로 개발을 하다 보면 @Controller, @Service, @Transactional 같은 코드를 자연스럽게 쓰게 됩니다. 그런데 문득 이런 생각이 든 적이 있을거라 생각합니다.

"이 @ 기호는 도대체 뭐고, 어떻게 동작하는 걸까?"

처음엔 그냥 "붙이면 되는 것"으로 넘어가기 쉽지만, 애노테이션이 내부적으로 어떻게 동작하는지 이해하면 프레임워크를 훨씬 자신 있게 다룰 수 있습니다. 이 글에서는 애노테이션이 무엇인지, 어떤 원리로 동작하는지 차근차근 살펴보겠습니다.

애너테이션이란?

애너테이션은 코드에 메타데이터(metadata) 를 부여하는 문법입니다. 쉽게 말해, "이 클래스는 컨트롤러야", "이 메서드는 트랜잭션 안에서 실행해줘" 처럼 코드에 추가적인 정보를 표시하는 라벨 이라고 생각하면 됩니다.

직접 비즈니스 로직을 수행하지는 않지만, 컴파일러나 프레임워크가 이 라벨을 읽고 그에 맞는 동작을 대신 처리해줍니다.

@Controller        // "나는 컨트롤러야"
@RequestMapping("/users")
public class UserController {

    @GetMapping("/{id}")
    @Transactional   // "나는 트랜잭션 안에서 실행돼야 해"
    public User getUser(@PathVariable Long id) {
        return userService.findById(id);
    }
}

표준 애너테이션

자바에서 기본적으로 제공하는 애너테이션입니다. 일부는 '메타 애너테이션'으로 커스텀 애너테이션을 정의하는 데 사용됩니다.

일반 애너테이션(java.lang)

에너테이션	설명
@Override	부모 클래스나 인터페이스의 메서드를 재정의할 때 사용. 컴파일러가 올바르게 오버라이딩됐는지 검증해줍니다.
@Deprecated	더 이상 사용을 권장하지 않는 메서드·클래스에 표시. 사용 시 컴파일러가 경고를 발생시킵니다.
@SuppressWarnings	컴파일러 경고를 억제할 때 사용. @SuppressWarnings("unchecked") 처럼 억제할 경고 종류를 지정합니다.
@SafeVarargs	가변인자(varargs)와 제네릭을 함께 사용할 때 타입 안전성을 보장한다고 선언. final 또는 static 메서드에만 사용 가능합니다.
@FunctionalInterface	함수형 인터페이스임을 명시. 추상 메서드가 딱 하나여야 하며, 람다식과 함께 사용됩니다.

메타 애너테이션 (java.lang.annotation)

애너테이션	설명
@Target	애너테이션을 적용할 수 있는 위치를 지정. METHOD, FIELD, CLASS 등을 설정합니다.
@Documented	JavaDoc 생성 시 해당 애너테이션 정보도 문서에 포함되도록 합니다.
@Inherited	부모 클래스에 붙인 애너테이션을 자식 클래스도 자동으로 상속받도록 합니다.
@Retention	애너테이션 정보를 어느 시점까지 유지할지 결정. SOURCE · CLASS · RUNTIME 세 가지가 있습니다.
@Repeatable	같은 애너테이션을 동일한 대상에 여러 번 반복 적용할 수 있도록 합니다.

@Target

애너테이션이 적용가능한 대상을 지정하는데 사용된다. 아래는 '@UserAgentHeader'를 정의한 것인데, 이 애너테이션에 적용할수 있는 대상을 '@Target'으로 지정했다. 여려 개의 값을 지정할 때는 배열에서처럼 괄호{}를 사용해야한다.

'@Target' 으로 지정할수 있는 애너테이션 적용대상의 종류는 아래와 같다.

대상 타입	의미
ANNOTATION_TYPE	애너테이션
CONSTRUCTOR	생성자
FIELD	필드(멤버변수, enum) 상수
LOCAL_VARIABLE	지역변수
METHOD	메서드
PACKAGE	패키지
PARAMETER	매개변수
TYPE	타입(클래스, 인터페이스, enum)
TYPE_PARAMETER	타입 매개변수(JDK1.8)
TYPE_USE	타입이 사용되는 모든 곳(JDK1.8)

동작 원리 - 리플렉션 (Reflection)

애너테이션 자체는 단순한 표시에 불과합니다. 실제로 동작하게 만드는 건 리플렉션(Reflection) 입니다.

리플렉션이란 런타임 시점에 클래스, 메서드, 필드 등의 정보를 동적으로 읽고 조작할 수 있는 Java의 기능입니다. Spring은 애플리케이션이 시작될 때 리플렉션으로 클래스를 스캔하고, 애너테이션이 붙어 있으면 그에 맞는 처리를 자동으로 수행합니다.

// Spring이 내부적으로 하는 일 (단순화된 예시)
Class<?> clazz = UserController.class;

if (clazz.isAnnotationPresent(Controller.class)) {
    // 컨트롤러로 등록
    registerAsController(clazz);
}

for (Method method : clazz.getDeclaredMethods()) {
    if (method.isAnnotationPresent(Transactional.class)) {
        // 트랜잭션 프록시 적용
        applyTransactionProxy(method);
    }
}

커스텀 애너테이션 만들기

주의 사항
애너테이션은 상속이 허용되지 않으므로 아래와 같이 명시적으로 Annotation을 조상으로 지정할 수 없다.

@interface TestInfo extends Annotation {
    int    count();
    String testedBy();
}

직접 애너테이션을 만들면 반복되는 코드를 줄이고, 의도를 명확하게 표현할 수 있습니다.

// 1. 애너테이션 정의
@Target(ElementType.METHOD)       // 메서드에만 붙일 수 있음
@Retention(RetentionPolicy.RUNTIME) // 런타임까지 유지
public @interface LoginRequired {
}

// 2. AOP로 처리 로직 작성
@Aspect
@Component
public class LoginAspect {

    @Before("@annotation(LoginRequired)")
    public void checkLogin(JoinPoint joinPoint) {
        // 로그인 여부 확인 로직
        if (!isLoggedIn()) {
            throw new UnauthorizedException("로그인이 필요합니다.");
        }
    }
}

// 3. 사용
@GetMapping("/mypage")
@LoginRequired  // 이 메서드는 로그인한 사용자만 접근 가능
public MyPage getMyPage() {
    ...
}

애너테이션 요소 규칙

애너테이션의 요소를 선언할 때 반드시 지켜야 하는 규칙은 다음과 같다.

- 요소의 타입은 기본형, String,enum, 애너테이션, Class만 허용된다.
- ()안에 매개변수를 선언할 수 없다.
- 예외를 선언할 수 없다.
- 요소를 타입 매개변수로 정의할 수 없다.

@interface BadAnnotation {
    // 허용되지 않는 타입 (List는 사용 불가)
    List<String> tags();

    // 매개변수 선언 불가
    String name(String prefix);

    // 예외 선언 불가
    int count() throws Exception;

    // 타입 매개변수 사용 불가
    <T> Class<T> element();
}

@interface GoodAnnotation {
    // 기본형
    int count();

    // String
    String name();

    // enum
    RetentionPolicy policy();

    // 애너테이션
    Target target();

    // Class
    Class<?> element();
}

마치며

애너테이션은 단순히 "붙이면 동작하는 것"이 아니라, 리플렉션을 통해 프레임워크가 런타임에 읽고 처리하는 구조입니다. 이 원리를 이해하면 @Transactional이 왜 private 메서드에서 동작하지 않는지, @Autowired가 어떻게 자동으로 주입되는지 같은 질문에도 스스로 답을 찾을 수 있게 됩니다.

[성능 개선] Redis + RabbitMQ 이벤트 기반을 통핸 초대권 시스템 개선 By UMF 2025 초대권

코드기록사 — Mon, 27 Oct 2025 23:48:52 +0900

“Redis-Lua + RabbitMQ로 초대권 트랜잭션 병목을 끊다 — 178% 성능 개선 사례”

들어가며

다가오는 UMF 2025(EDM 페스티벌) 를 앞두고, 우리는 ‘초대권(Invitation)’ 기능을 새로 설계·개발했습니다. 행사 특성상 수천 명 사용자가 특정 시점에 동시 입장하는 초고부하 상황이 예측되었고, 실제로 3,000장 이상의 초대권이 발급되었습니다. 문제는 입장 시점에 요청이 한꺼번에 몰린다는 점이었습니다.

기존 아키텍처는 이 트래픽을 감당하지 못했습니다. 동시 60건을 넘기면서부터 서비스가 불안정해졌고, DB Connection Pool이 고갈되어 이후 요청이 처리되지 않는 상황이 반복되었습니다. MSA 구조였음에도 내부적으로 블록체인 기록 로직을 트랜잭션 안에서 동기적으로 실행하는 설계 때문에, 트랜잭션 경합과 DB 잠금이 누적된 것이 근본 원인이었습니다.

이를 해결하기 위해, 우리는 Redis 이벤트 기반 트랜잭션 제어(원자 연산 + 대기열/디스패치)와 (선택적으로) RabbitMQ를 활용한 후속 처리 비동기화를 도입했습니다. 핵심 아이디어는 단순합니다.
“선점/가용성 판단은 Redis의 원자 연산으로 초저지연 처리하고, 무거운 후속 로직은 트랜잭션 밖으로 분리한다.”

그 결과, 초당 약 70TPS 수준이던 처리량이 3,000TPS 이상 (약 42.9배) 증가했고, 안정적인 처리율을 달성했습니다.

이후 글에서는 Redis를 중심으로 트랜잭션 병목을 제거하고, 안정적인 초고부하 처리를 가능하게 만든 구조적 개선 과정을 상세히 다뤄보겠습니다

1. 블록체인 트랜잭션의 특성과 병목 원인

블록체인 시스템의 트랜잭션은 우리가 흔히 사용하는 데이터베이스(DB) 트랜잭션과는 다릅니다.
DB 트랜잭션은 하나의 커넥션 안에서 여러 작업을 묶어 원자적으로 처리하는 개념이지만, 블록체인의 트랜잭션은 “계정(Account)”을 통해 네트워크에 전송되는 서명된 실행 단위를 의미합니다.

여기서 중요한 차이점은, 하나의 계정(EOA, Externally Owned Account) 은 동시에 여러 트랜잭션을 보낼 수 없다는 점입니다.

그 이유는 블록체인 네트워크가 트랜잭션의 순서(Nonce) 를 기반으로 동작하기 때문입니다.
각 계정은 트랜잭션을 보낼 때마다 nonce 값을 1씩 증가시키며, 이 값이 겹치거나 순서가 어긋나면 네트워크는 해당 요청을 거부(revert) 하거나 대기(pending) 상태로 둡니다.

1-1 동시 요청 시 실패

즉,

같은 계정에서 여러 트랜잭션을 동시에 보내면 → Nonce 충돌 발생
Nonce 충돌이 나면 → 이전 트랜잭션이 처리될 때까지 네트워크가 대기
결국 서버 입장에서는 여러 요청이 동시에 들어와도, 실제 블록체인 네트워크에서는 순차(Sequential) 처리가 됩니다.

1-2 트랜잭션 실패

이더리움 메인넷은 한 트랜잭션이 블록에 포함되기까지 평균 약 8초, 빠른 체인에서도 1~2초 정도가 소요됩니다.
이 시간 동안은 동일한 계정에서 새로운 트랜잭션을 전송할 수 없는 상태가 됩니다.

문제는 이러한 블록체인의 직렬 처리 특성이 그대로 백엔드 서비스의 병목으로 전이된다는 점입니다.

특히 우리 시스템은 모든 발급 및 입장 트랜잭션을 단일 Pool 계정을 통해 처리하고 있었기 때문에,
블록체인 측에서는 트랜잭션 대기로 인한 지연이 발생하고, 서버 측에서는 그동안 DB 트랜잭션이 점유되어 Connection Pool이 고갈되는 연쇄적인 병목 현상이 발생했습니다.

2. 기존 아키텍처 구조 와 문제점

1.1 기존 아키텍처

기존 아키텍처에서 관리자가 초대권 발행 요청을 70개 보냈다고 가정해보겠습니다.
서비스는 데이터베이스에 저장된 단 2개의 EOA(Ethereum 계정) 를 사용해 트랜잭션을 처리했습니다.

요청이 들어오면, 서버는 다음과 같은 순서로 동작했습니다.

DB에서 사용 가능한 계정을 조회
비관적 락(SELECT ... FOR UPDATE) 을 걸어 계정을 선점
선점에 실패한 요청은 재시도하며 동일한 쿼리를 반복 실행
선점이 완료된 요청은 해당 계정으로 트랜잭션 오브젝트를 생성하고 이더리움 네트워크(EVM)에 전송하여 초대권을 발행

이 구조는 동시 요청이 적은 환경에서는 큰 문제가 없었습니다.
하지만 요청이 동시에 몰릴 경우, 심각한 성능 저하를 일으켰습니다.

비관적 락의 문제

SELECT ... FOR UPDATE 쿼리는 DB 자원을 가장 많이 사용하는 쿼리 중 하나입니다.
락을 걸어 다른 트랜잭션의 접근을 막기 때문에, 락이 해제되기 전까지는 동일한 행(row)에 접근하는 모든 요청이 대기 상태로 머무르게 됩니다. 위 예시에서 70개의 요청 중 2개만 계정을 선점하고, 나머지 68개 요청은 선점을 위해 반복적으로 재시도합니다.
이 과정에서 DB는 락 대기 상태를 유지하며 Connection Pool의 커넥션을 점점 소모하게 됩니다. 결국 일정 수 이상의 요청이 쌓이면 Connection Pool이 가득 차서 그 이후의 요청은 더 이상 처리되지 않는 병목 현상이 발생합니다.

체결 지연과 누적 부하

블록체인 트랜잭션은 평균적으로 약 8초(이더리움 기준) 가 소요되며, 이 시간 동안 해당 계정은 새로운 트랜잭션을 처리할 수 없다고 앞에서 설명한 바있습니다. 즉, 트랜잭션이 체결되기 전까지 락이 유지되며, 남은 68개의 요청은 계속해서 “계정 선점” 쿼리를 재시도하게 됩니다. 만약 요청이 초당 5회씩 재시도된다면, 68 * 5 = 340 회의 DB 쿼리가 매초 발생하게 됩니다.이는 단일 서비스 인스턴스 수준에서도 DB 부하를 폭발적으로 증가시키는 수준입니다.

단순한 확장으로는 해결되지 않는다

이 문제를 피하기 위한 단순한 방법 으로는 계정을 10개 .. 200개 그 이상으로 늘리는 것입니다. 하지만 이 방식은 요청이 적을 때 불필요한 리소스 낭비를 초래합니다. 또한 계정이 많아질수록 관리 비용이 증가하고, 보안·트랜잭션 관리의 복잡도도 함께 커집니다.

구조적 한계

결국 이 구조는 동시에 많은 사용자가 초대권을 발급받는 상황(예: 대규모 행사 입장) 에서는확실히 한계를 드러냈습니다.

DB 락 경합
커넥션 풀 고갈
트랜잭션 지연 누적

이 세 가지 문제는 시스템 전반의 처리 속도를 떨어뜨리고, 서비스 중단으로 이어질 가능성이 높았습니다. 이러한 이유로, 이번 UMF 행사를 대비하여 우리는 기존 구조를 이벤트 기반의 트랜잭션 처리 구조로 개선하기로 결정했습니다.

3. 개선 방향 및 적용한 과정

1. DLQ + Back-Off 적용 - 사다리형 구조

기존 시스템에서는 요청이 실패하면 단순히 “재시도”만 반복했습니다. 하지만 트랜잭션이 블록체인 체결을 기다리는 동안(평균 8초 이상), 서버는 여전히 Connection Pool을 점유하고 있었죠. 결국 “일시적 실패”조차 시스템 전체의 병목으로 번지게 되었습니다.

이 문제를 해결하려면,

실패를 즉시 재시도하지 않고 지연시켜야 하고,
계속 실패하는 요청은 다른 큐로 분리해야 했습니다.

이 두 가지 조건을 동시에 만족시키는 구조가 바로 DLQ(Dead Letter Queue) 와 Back-Off 의 조합입니다.

DLQ(Dead Letter Queue)란?

DLQ는 메시지 큐 시스템에서 정상적으로 처리되지 못한 메시지를 별도로 보관하는 큐를 의미합니다. 즉,

컨슈머(Consumer)가 메시지를 처리하다가 예외가 발생하거나,
재시도 횟수를 초과해도 성공하지 못한 메시지들을

즉시 폐기하지 않고 DLQ에 보관함으로써,이후 운영자가 해당 메시지를 수동으로 확인하거나 재처리할 수 있도록 합니다.

이 방식은 단순히 실패를 무시하지 않고, “실패한 이벤트도 추적 가능한 데이터로 관리”할 수 있게 해주므로 대규모 비동기 처리 시스템의 안정성을 높이는 핵심 요소입니다.

Back-Off 재시도란?

Back-Off은 요청이 실패했을 때 일정한 지연 시간을 두고 재시도하는 전략입니다.
단순히 즉시 재시도하는 대신, 실패가 반복될수록 재시도 간격을 점차 늘려주는(Exponential Back-Off) 방식을 적용합니다.

시도횟수	대기 시간
1 회차	1초
2 회차	2초
3 회차	5초

이벤트 기반 재시도 구조 적용 및 결과

이러한 DLQ + Back-Off 방식을 실제 시스템에 적용하자, 요청 흐름이 명확히 구분되었습니다.

요청이 처음 들어왔을 때 계정을 성공적으로 선점한 요청은 정상적으로 초대권 발행이 진행됩니다. 반면, 계정을 선점하지 못한 나머지 68개의 요청은 이전처럼 무한히 반복 재시도를 하지 않습니다. 대신, 이 요청들은 다음 큐(Queue) 로 메시지를 전달하며,
각 메시지에는 랜덤한 Back-Off 지연 시간이 함께 설정됩니다. 이 지연 시간 동안 요청은 잠시 대기하고, 대기 후 다시 “계정 선점 실행 큐”로 메시지를 재발행하여 쿼리 부하를 분산시켰습니다. 즉, 모든 요청이 동시에 DB를 두드리는 대신, 시간 차를 두어 안정적인 재시도가 가능해졌습니다. 또한, 지정된 재시도 횟수를 초과한 메시지는 무한 루프에 빠지지 않도록 DLQ(Dead Letter Queue) 로 이동시켰습니다. 이 DLQ에 적재된 메시지는 추후 운영자가 실패한 이벤트를 트래킹하고 재처리할 수 있도록 설계했습니다.

여전히 남은 문제

물론 완벽한 해결책은 아니었습니다. 이 구조는 안정성을 크게 높였지만, 여전히 몇 가지 한계가 존재했습니다.

Back-Off가 적용되면서 요청들이 일정 시간 대기 상태에 머물게 되었고, 서버 내부적으로는 대기 중인 인터벌(Interval) 처리 부담이 남았습니다.
트래픽이 매우 많을 경우, 랜덤한 Back-Off를 적용하더라도 대기 시간이 겹치는 구간이 발생해, 순간적인 동시성 스파이크가 완전히 사라지지는 않았습니다.

결과적으로, 이 개선을 통해 동시 70건의 요청을 약 120건까지 확장할 수 있었지만, 여전히 우리가 목표로 한 수천 TPS 수준의 처리량에는 미치지 못했습니다.

2. Redis + Lua 스크립트를 활용한 이벤트 기반 확장

DLQ와 Back-Off 구조를 통해 재시도 안정성은 확보했지만, 여전히 DB 락(SELECT ... FOR UPDATE) 이 전체 성능의 병목으로 남아 있었습니다. 트랜잭션이 블록체인에 체결되는 동안(평균 8초 이상) DB 커넥션이 점유되고 있었고, 이는 Connection Pool을 빠르게 소진시키며 TPS 확장을 가로막는 주요 원인이었습니다.

이 문제를 해결하기 위해, DLQ의 메시지 흐름 구조를 그대로 유지하면서 **Redis를 활용한 “사다리 타기형 구조”**를 구상했습니다.

핵심 아이디어는 단순합니다. DB의 계정 선점을 Redis와 동기화하고, 계정 가용 상태를 캐시 기반으로 제어하는 것입니다.

Redis를 활용한 캐시 기반 계정 선점

Redis를 사용하면 매번 DB에 접근하지 않고도 계정의 가용 여부를 즉시 확인할 수 있습니다. 예를 들어, 계정을 선점할 때는 Redis에 +1을 수행하고, 사용을 완료하면 -1을 수행하여 DB의 상태와 Redis의 캐시를 동기화할 수 있습니다.

이 방식의 장점은 명확합니다.

불필요한 DB 락 경쟁이 사라지고
계정 선점 및 해제가 메모리 기반 연산으로 전환

계정 선점 프로세스

Lua 스크립트를 통한 원자적 제어

Redis의 Lua 스크립트를 활용하면, “가용 슬롯 증가 → 대기열 확인 → 대기 중 메시지를 깨워 실행 큐로 이동” 같은 일련의 과정을 단일 트랜잭션처럼 원자적으로 처리할 수 있습니다. 즉, 여러 요청이 동시에 동일한 키를 조작하더라도
레이스 컨디션(race condition)이 발생하지 않습니다. 이 구조는 단순한 캐시 제어를 넘어, Redis가 분산 환경에서의 락 관리자 역할을 수행하도록 합니다.

세마포어(Semaphore) 방식 적용

여기에 세마포어(Semaphore) 개념을 결합했습니다. 세마포어란 한정된 자원의 접근 허용 개수를 제어하는 동기화 기법으로,
자원 접근 시 카운트를 감소시키고, 해제 시 다시 증가시켜 동시에 접근 가능한 프로세스 수를 제어합니다.

Redis를 기반으로 세마포어를 구현하면, 여러 서버 인스턴스가 동시에 Redis를 공유하더라도
전역 단위의 동시성 제어(Distributed Semaphore) 가 가능합니다. 이를 통해 특정 계정 풀(pool)에 허용된 동시 요청 개수를 실시간으로 관리할 수 있으며, 모든 요청이 동일 시점에 몰리는 스파이크 현상도 자연스럽게 완화됩니다.

테스트 및 결과

테스트 성능표

테스트 시나리오

이번 성능 테스트는 Redis + Lua + 세마포어 기반 구조가 실제로 병목을 얼마나 줄이는지를 검증하기 위해 진행했습니다.
테스트는 아래와 같은 조건으로 구성되었습니다.

요청 수(Requests): 10, 20, 30, 50, 70, 100개의 동시 요청
계정 수(Accounts): 5개, 7개, 10개로 나누어 단계별 실험
측정 항목: 처리 시간(Time)과 TPS(Transaction Per Second)

즉, 계정 풀 크기를 점진적으로 늘려가며 동일한 요청 부하를 반복 적용하여
시스템의 응답 속도와 처리 효율(TPS)을 동시에 측정했습니다.

테스트 방법

기존 방식 (DB Lock 기반)
- 각 요청은 SELECT ... FOR UPDATE로 DB에서 직접 계정을 잠그며,
  트랜잭션이 끝날 때까지 커넥션을 점유하는 구조였습니다.
개선 방식 (Redis + Lua + 세마포어 기반)
- 계정 선점과 해제를 Redis로 처리하고,
  Lua 스크립트를 통해 원자적 증감 연산 및 큐 관리가 수행됩니다.
- DB는 단순 상태 동기화 역할만 수행하며,
  Redis가 실질적인 병렬 제어(세마포어 역할)를 담당합니다.

테스트 결과

구분평균 개선 효과

시간(Time)	최대 69.9% 단축, 평균 약 46.9% 단축
TPS(Transaction Per Second)	최대 170% 향상, 평균 약 107.9% 향상

요청 수가 많을수록(특히 70건 이상) 성능 향상이 두드러졌으며,Redis 기반 구조로 전환한 후 처리 안정성과 속도 모두 향상되었습니다. 특히 100개 동시 요청 시,

개선 전: 119.5초 / 0.82 TPS
개선 후: 45.5초 / 2.2 TPS
로, 약 170% 이상의 TPS 향상을 달성했습니다.

결론

Redis + Lua + 세마포어 구조를 적용한 결과, 단순 DLQ + Back-Off 단계에서 약 170% 추가적인 성능 향상을 확인했습니다.이제 시스템은 재시도 안정성뿐만 아니라, DB 부하 분산, 트랜잭션 병목 제거, 처리량 확장성까지 확보하게 되었습니다.

마무리

이번 UMF 2025 초대권 시스템은 단순한 성능 개선을 넘어, 구조적 병목을 제거하고 안정성을 확보한 실전 사례였습니다.
Redis-Lua와 RabbitMQ 기반의 비동기 트랜잭션 제어를 적용한 결과, 수천 건의 요청이 동시에 몰리는 상황에서도
시스템은 한 번도 중단되지 않았으며, 실제 행사 현장에서도 단 한 건의 오류 없이 안정적으로 초대권 발급이 완료되었습니다.

무엇보다, 이번 개선을 통해 단순히 수치를 올리는 것을 넘어 “대규모 실사용 환경에서도 견고하게 버틸 수 있는 구조”를 직접 설계하고 검증할 수 있었다는 점에서 큰 의미가 있었습니다. 행사 기간 동안 사용자가 직접 초대권을 발급받고 입장 과정을 원활히 진행하는 모습을 보며, 그동안의 수많은 테스트와 튜닝 과정이 결실을 맺은 것 같아 정말 뿌듯했습니다. 앞으로도 이번 경험을 바탕으로,
더 많은 트래픽을 안정적으로 처리하고, 블록체인 기반 서비스의 신뢰성과 확장성을 강화할 수 있는 구조적 개선을 지속해 나갈 예정입니다. 감사합니다.

[JPA] QueryDSL 에서 FROM절에 SubQuery 및 ROW_NUMBER() 사용 방법

코드기록사 — Wed, 18 Sep 2024 05:11:27 +0900

FROM 절에 서브쿼리를 사용해 보자

들어가며

프로젝트를 진행하면서, 각 카테고리별로 좋아요 수를 기준으로 상위 2개의 게시물을 조회하는 쿼리가 필요하게 되었다. 하지만 일반 SQL문을 사용하는 것이 아닌 QueryDSL을 사용할 때 FROM 절에 서브쿼리를 어떻게 적용할 수 있는지 한번 알아보도록 하겠습니다.

SQL 조회 예시

위와 같이, Article 테이블에서 카테고리별로 좋아요 순으로 상위 2개의 게시물을 조회하는 방법에 대해 설명드리겠습니다.

카테고리별 좋아요 순 쿼리

- 먼저 각 게시물에 ROW_NUMBER()를 사용하여, 카테고리별로 좋아요 순위를 매깁니다. SQL 쿼리는 다음과 같습니다:

 SELECT a.*, ROW_NUMBER() OVER (PARTITION BY a.article_category ORDER BY a.like_count DESC) AS rn
 FROM article a;

- 이 쿼리를 통해, 각 카테고리별로 게시물의 좋아요 순위가 매겨집니다. 이제 각 카테고리에서 상위 2개의 게시물을 조회해야 합니다.

FROM 절에 카테고리별 좋아요 서브쿼리

- ROW_NUMBER()를 통해 계산된 순위를 이용해, 상위 2개의 게시물만 필터링하기 위해서는 서브쿼리를 FROM 절에 넣어야 합니다. 이를 적용한 SQL은 다음과 같습니다:

SELECT ra.*
FROM(
	SELECT a.*, ROW_NUMBER() OVER (PARTITION BY a.article_category ORDER BY a.like_count DESC) AS rn
	FROM article a) as ra
where ra.rn<=2;

- 이 쿼리는 각 카테고리별로 좋아요 순으로 정렬된 게시물 중 상위 2개 만을 필터링하여 가져옵니다.

다음과 같이 카테고리별로 좋아요가 많은 게시글을 2개씩 조회된 것을 볼 수 있습니다.

QueryDSL에서 윈도우 함수 사용

기본적으로 JPA와 QueryDSL을 어느 정도 사용해 본 경험이 있다고 간주하고 Q클래스 및 설정 방법 등은 생략하고 작성하도록 하겠습니다.!! ( 스프링부트 3.x 이상버전 사용 중이며, Hibernate 7.0 이상 기준입니다)

먼저 QueryDSL에서의 ROW_OVER() 윈도우 함수 사용방법에 대해서 알아봅시다.

1. Expressions 사용하기

Expressions 사용법

 JPAQuery<Tuple> rowNumber = jpaQueryFactory.select(
                        article,
                        Expressions.numberTemplate(
                                Long.class,
                                "row_number() over (partition by {0} order by {1})",
                                article.articleCategory,
                                article.likeCount
                        ).as("rowNumber"))
                .from(article);

위와 같이 QueryDsl에서 서브쿼리르 사용할 때 사용하는 Expressions를 사용하여 직접 template를 작성해 주면 됩니다.

쿼리를 실행해 보면 아래와 같이 쿼리가 실행되는 것을 볼 수 있습니다.

2. SQLExpressions사용하기

QueryDSL에서 지원하는 SQLExpressions을 사용하면 됩니다.

rowNumber을 지원하는 것을 볼 수 있습니다.

SQLExpressions을 사용하기 위해서는 다음 의존성을 추가해줘야 합니다.

implementation 'com.querydsl:querydsl-sql:5.0.0'

SQLExpressions 사용법

JPAQuery<Tuple> rowNumber = jpaQueryFactory.select(article, SQLExpressions.rowNumber().over().partitionBy(article.articleCategory).as("rn"))
                .from(article)
                .orderBy(Expressions.stringPath("rn").desc());

쿼리를 작성하고 실행하게 되면 다음과 같은 오류 메시지를 볼수 있습니다.

발생 원인

JPQL 쿼리 언어는 SQL 함수인 ROW_NUMBER()와 같은 고급 SQL 표현식을 직접 지원하지 않는다. 따라서, 이를 사용하기 위해서는 JPQL 템플릿을 사용자 정의하여 ORM에 이러한 함수가 사용될 수 있도록 설정해야 하는 오류가 발생합니다.

해결 방법

jpaQueryFactory를 EntityManger을 통해 빈으로 등록 시에 row_number을 사용하도록 JPQLTemplates의 Enum타입으로 정의된 SQLOps을 등록하여 사용가능하도록 하면 해결할 수 있다.

 @Bean
 public JPAQueryFactory jpaQueryFactory(){
      JPQLTemplates templates = new JPQLTemplates() {
          {
              add(SQLOps.ROWNUMBER, "row_number()");
          }
      };
      return new JPAQueryFactory(templates,entityManager);
}

위의 주입을 해주게 된다면 정삭적으로 쿼리가 실행되어 조회되는 것을 볼 수 있습니다.

QueryDsl에서 From 절에 서브쿼리 사용하기

From 절에 서브쿼리를 사용하려고 여러 자료를 조사해 본 결과, From 절에서 서브쿼리를 사용하는 것이 가능한지에 대한 정보가 엇갈리고 있었습니다. 어떤 자료에서는 From 절에서 서브쿼리를 사용할 수 없다고 하고, 다른 자료에서는 사용이 가능하다고 설명하고 있었습니다. 여러 시도를 통해 완벽하지는 않지만, 정적인 조회에서는 From 절에 서브쿼리를 사용할 수 있는 방법을 찾게 되었습니다. 이제 이 방법에 대해 자세히 설명드리겠습니다.

From 절에 서브쿼리 사용 시

위에서 row_number을 from절에 쿼리로 사용하게 되면 다음과 같은 에러 메시지와 함께 조회의 실패하는 것을 볼 수 있습니다.

 Servlet.service() for servlet [dispatcherServlet] in context with path [] threw exception [Request processing failed: java.lang.ClassCastException: class com.querydsl.jpa.impl.JPAQuery cannot be cast to class com.querydsl.core.types.EntityPath (com.querydsl.jpa.impl.JPAQuery and com.querydsl.core.types.EntityPath are in unnamed module of loader 'app')] with root cause

java.lang.ClassCastException: class com.querydsl.jpa.impl.JPAQuery cannot be cast to class com.querydsl.core.types.EntityPath (com.querydsl.jpa.impl.JPAQuery and com.querydsl.core.types.EntityPath are in unnamed module of loader 'app')

발생 원인

JPQL에서는 서브쿼리를 직접 FROM절에 사용할 수 없기때문에 EntityPath으로 캐스팅을 하더라고 메타데이터인 QAticle로 조회되지 못해 사용할수 없는거 같은 생각이 들었습니다.

해결 방법

서브 조회 클래스를 만들어 조회된 Qsub 클래스를 from절에 넣는 방법
네이티브 쿼리를 사용하여 조회하는 방법

위에 해결 방법에서는 서브 조회 클래스를 만들어 from절에 사용하는 방법을 알아보도록 하겠습니다.

먼저 본 클래스와 똑같이 클래스를 하나 만들어줍니다.

@Entity
@Subselect(
        "SELECT " +
                "a.*, " +
                "ROW_NUMBER() OVER (PARTITION BY a.article_category ORDER BY a.like_count DESC) AS rn " +
                "FROM article a"
)
@Immutable
@Synchronize("article")
@NoArgsConstructor
@AllArgsConstructor
@Data
public class ArticleRowSub extends BaseTime {

    @Id
    @Column(name = "article_id") // assuming this is the primary key
    private Long id;

    private String title;               // 제목

    @Column(length = 5000)
    private String content;             // 내용

    private Integer likeCount;          // 좋아요 수
}

@Subselect :
1. 서브쿼리의 결과 매핑 : 서브쿼리의 결과를 JPA엔티티로 매핑이 가능하다.
2. 쿼리와 엔티티 분리 : 복잡한 쿼리를 엔티티를 통해 매핑하여 복잡하거나 사용할수 없을 때 분리하여 유지보수성 향상
3. 복잡한 결과 집합 처리 : @Subselect를 사용하면, 복잡한 집계 함수나 조인 결과를 엔티티로 매핑할 수 있습니다. 이로 인해 복잡한 데이터 집합을 간편하게 처리할 수 있습니다.
@Immutable :
1. 불변(immutable)임을 나타냅니다. 즉, 엔티티의 데이터가 변경되지 않으며, 읽기 전용으로 다루어야 함을 명시합니다.
@Synchronize :
- 특정 엔티티나 컬렉션에 대한 동시성 문제를 제어하는 데 사용됩니다. article의 데이터의 일관성을 유지합니다.

QueryDsl 쿼리

 JPAQuery<ArticleRowSub> from = jpaQueryFactory.select(articleRowSub)
                .from(articleRowSub);

article를 사용하여 조회하는 방식이 아닌 ArticleRowSub을 통해 조회하면 from절에 서브쿼리로 사용하는 것과 같은 기능을 동작하게 됩니다.

querydsl 이 만든 쿼리와 직접 실행되는 쿼리가 다른 것을 볼 수 있습니다. from 절에 서브쿼리가 사용되어 조회된것을 볼수 있습니다.

문제점

QueryDSL을 사용하면 동적인 쿼리를 쉽게 생성할 수 있지만, @Subselect를 사용하여 FROM 절에 서브쿼리를 포함할 경우 동적인 조회가 어려울 수 있습니다. 특히, 카테고리별로 조회할 때 차단된 사용자의 게시글을 제외해야 하는 제약이 있는 경우, QueryDSL의 동적 쿼리 기능만으로는 충분하지 않을 수 있습니다. 이 경우 비즈니스 로직에 조건문을 추가하여 네이티브 쿼리를 사용하는 것이 현실적인 해결책이 될 수 있습니다.

참고

SQLExpressions (Querydsl 4.4.0 API)

cumeDist public static WithinGroup cumeDist(Object... args) As an aggregate function, CUME_DIST calculates, for a hypothetical row r identified by the arguments of the function and a corresponding sort specification, the relative position of row r amon

querydsl.com

JPA Querydsl from절에 subquery 사용하기(@Subselect 이용)

이슈사항 이번 내용도 배치로 통계로 구축하다가 생긴 이슈이다. 통계 쿼리를 mybatis로 작성하는 것은 쉬운데 검색해보니 querydsl은 subquery가 select 절이나 where 절에만 사용가능하고 from절에는 불

wms0603.tistory.com

[Jenkins] Nginx+Docker+Jenkins 활용한 배포

코드기록사 — Wed, 7 Aug 2024 07:40:08 +0900

무중단 배포를 한번 해보자!

들어가며

새로운 프로젝트를 시작하면서 CI/CD를 구성하게 되었습니다. 이전 프로젝트에서는 새로운 기능이 담긴 JAR 파일을 배포할 때 기존 서버를 종료하고 새로운 서버를 띄우는 과정에서 다운타임이 발생하는 문제가 있었습니다. 이로 인해 짧게는 30초, 길게는 1분 이상 서비스가 중단되어 사용자에게 불편을 초래했습니다. 이번 프로젝트에서는 이러한 문제를 해결하기 위해 무중단 배포를 구현하려고 합니다.

다운 타임

다운타임이란 스템, 서버, 네트워크, 또는 애플리케이션이 정상적으로 작동하지 않고, 사용자가 접근할 수 없는 시간을 의미합니다. 다운타임은 계획된 경우와 계획되지 않은 경우로 나뉩니다.

계획된 다운 타임 :
- 시스템 유지 보수 : 시스템의 성능을 올리거나 유지보수를 하는 동안 사용할 수 없는 시간
- 배포 및 릴리스 : 새로운 기능이느 버그가 발생해 새로운 버전을 배포 시 발생 시간
계획되지 않은 다운 타임:
- 시스템 오류 : 시스템이 다운됐거나, 오류가 발생해 사용할 수 없을 때 발생하는 시간
- 보안 : 블랙해커의 의해 시스템이 해킹되어 사용 할 수 없는 시간

만약 새로운 기능일 개발해 CI/CD를 진행한다면 위에서 설명한 계횐된 다운타임-배포 및 릴리스의 해당되어 새 버가 새롭게 배포되기 전까지의 과정에서 다운타임이 발생하게 됩니다. 그래서 이를 해결하기 위해서는 무중단 배포(Zero Downtime Deployment) 기술을 활용하면 서비스 중단 없이 사용할 수 있습니다.

무중단 배포 방식

무중단 배포방식의 여러가지 방식이 있습니다, 그중 이번 포스팅에서는 블루 그린 방식에 대해서만 설명하겠습니다.

블루-그린 무중단 배포란?

블루-그린 배포(Blue-Green Deployment)는 두 개의 서버를 활용한 배포 방식입니다.

동작 과정

현재 서버는 GREEN 서버가 동작 중입니다.

새로운 버전을 개발하여 새로운 배포 서버를 띄우려고 합니다.

먼저, 현재 사용 중인 서버가 BLUE 서버인지 GREEN 서버인지 확인합니다.

확인 결과, 현재 GREEN 서버가 동작 중임을 확인했습니다.

그럼 BLUE서버 포트를 사용해 새롭게 서버를 실행합니다.

아직 그대로 데이터 전송은 GREEN 서버로 전달합니다.

기존에 GREEN서버를 DOWN 시키고 BLUE 서버로 전달이 되도록 변경합니다.

이런식의 과정으로 GREEN-BLUE 방식이 동작합니다.

단점

1. 비용 증가: 두 개의 환경을 동시에 운영하기 때문에 인프라 비용이 증가할 수 있습니다.

2. 복잡성 증가: 환경 관리와 전환 작업이 추가되므로 설정과 운영의 복잡성이 높아질 수 있습니다.

사전 준비

이번 구현 방법에서는 Nginx, Docker, AWS, Jenkins, Spring를 기본적으로 숙지한 상태라고 가정하며, 자세한 설치 과정 등은 생략하도록 하겠습니다.

사전 준비

Spring-boot : actuator, web 준비

AWS-EC2 : docker, docker-compose, nginx, jenkins 준비

Docker : docker-hub 에 빌드된 image

Nginx 설정

Docker-compose를통해 nginx를 실행할 수 있게 작성해 줍니다.

version: '3.9'

services:
  nginx:
    image: nginx:latest
    volumes:
      - ./conf/nginx.conf:/etc/nginx/nginx.conf
    restart: always
    ports:
      - 80:80
    networks:
      - backend_network
    depends_on:
      - api

networks:
  backend_network:
    external: true

간단하게 작성해 줍니다. 서버는 다른 docker-compose 작성해 실행해 줄 예정이니 depends_on을 통해 의존해 줍니다.
또한 사용할 수 있게 네트워크도 연결해줘야 합니다.

 docker network create backend_network

명령어를 통해 네트워크를 만들어줍니다.

이제 두 개의 blue, green의 yml파일도 작성해 줍니다.

docker-compose.blue.yml

version: "3.9"

networks:
  backend_network:
     external: true

services:
  api:
    image: [이미지명]
    container_name: [컨테이너명]
    restart: always
    ports:
      - "8443:8443"
    networks:
      - backend_network

docker-compose.green.yml

version: "3.9"

networks:
  backend_network:
     external: true

services:
  api:
    image: [이미지명]
    container_name: [컨테이너명]
    restart: always
    ports:
      - "8444:8443"
    networks:
      - backend_network

nginx.conf

events {
    worker_connections 1024;
}

http {

    server {
        listen 80;

        server_name 52.78.225.238;

        location /.well-known/acme-challenge/ {
            allow all;
        }
        location /actuator {
            add_header X-Served-By $host;
            proxy_set_header Host $host;
            proxy_set_header X-Forwarded-Scheme $scheme;
            proxy_set_header X-Forwarded-Proto $scheme;
            proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
            proxy_set_header X-Real-IP $remote_addr;
        }
    }
}

docker-compose -f [docker-compose.[색].yml] -p [별명] -f docker-compose.yml up -d

위 명령어를 입력하여 실행해 줍니다.

실행 중인 Niginx의 접속하여 VIM을 설치해 줍니다.

vim /etc/nginx/include/service_url.conf

아래 내용을 작성해 줍니다.

set $service_url :8081;

현재 실행 중인 Green 서버의 포트번호입니다.

이제 shell작성하면 현재 실행중인 포트번호로 자동으로 바뀌게 할 예정입니다.

deploy.sh

EXIST_BLUE=$(sudo docker-compose -p blog-blue -f /blog/docker-compose.blue.yml ps | grep blog-blue)
echo "${EXIST_BLUE}"

#1
if [ -z "$EXIST_BLUE" ]; then
  echo "blue 컨테이너는 실행 중이지 않습니다."
  sudo docker-compose -p blog-blue -f /blog/docker-compose.blue.yml up -d
  BEFORE_COLOR="green"
  AFTER_COLOR="blue"
  BEFORE_PORT=8081
  AFTER_PORT=8080
else
  echo "blue 컨테이너는 실행 중입니다."
  sudo docker-compose -p blog-green -f /blog/docker-compose.green.yml up -d
  BEFORE_COLOR="blue"
  AFTER_COLOR="green"
  BEFORE_PORT=8080
  AFTER_PORT=8081
fi

echo "${AFTER_COLOR} server up(port:${AFTER_PORT})"


#2
for cnt in {1..10}
do
  echo "서버 응답 확인중(${cnt}/10)"
  UP=$(curl -s http://52.78.225.238/:${AFTER_PORT}/actuator/health)
  if [ -z "$UP" ]; then
    sleep 10
    continue
  else
    break
  fi
done

if [ $cnt -eq 10 ]; then
  echo "서버가 정상적으로 구동되지 않았습니다."
  exit 1
fi


#3
# 설정 파일을 호스트에서 수정
echo "Modifying Nginx Configuration on Host..."
sudo docker exec blog-green_nginx_1 sed -i "s/:${BEFORE_PORT}/:${AFTER_PORT}/" /etc/nginx/include/service_url.conf


# Nginx 서버 재로드
echo "Reloading Nginx..."
sudo docker exec blog-green_nginx_1 nginx -s reload

echo "Deploy Completed!!"

#4
echo "$BEFORE_COLOR server down(port:${BEFORE_PORT})"
pwd
sudo docker stop blog-${BEFORE_COLOR}
sudo docker rm blog-${BEFORE_COLOR}

디렉터리 구조

blog
├── deploy.sh
├── docker-compose.blue.yml
├── docker-compose.green.yml
├── docker-compose.yml
├── nginx.conf
└── service_url.conf

젠킨스 설정

원격으로 ssh를 접속하기 위해서 SSH 플러그인을 다운로드하여줍니다.

그 후 EC2에 접속할 때 사용한. pem키의 내용을 복사해 줍니다.

credenials를 추가해줍니다.

ID : 사용할 커스텀 아이디(마음대로 지정가능합니다.)

Description : 부가설명을 작성합니다.

Username : EC2의 접속할 때 사용한 명을 사용합니다.(우분투 : ubuntu, 아마존리눅스면 : ec2-user)

Key : ec2 접속 시 사용했던 키의 내용을 복사

파이프라인 작성

pipeline{
    agent any
    
    stages{
        
       stage('Deploy') {
            steps {
                sshagent (credentials: ['ec2_blog']) {
                        sh """
                            ssh -o StrictHostKeyChecking=no ubuntu@52.78.225.238 '
                            cd /blog
                            ls -a
                            sudo ./deploy.sh
                            '
                        """
                }
            }
        }
    }
}

추가적인 필요한 것이 있으면 stage를 통해 추가하시면 됩니다.

현재는 ip주소가 그대로 노출되지만 블로그 작성 시에만 사용했지만 꼭 환경변수로 사용해야 합니다!!

이제 쉘스크립트를 실행하게 되면 이전에 작성했던 service_url.conf 이 동적으로 바뀌어 새롭게 연결해 주는 것을 기대할 수 있다.

쉘 스크립트에 작성한 내용이 정상적으로 나오는 것을 볼 수 있다.

결과 학인

위 로그에서 blue가 실행 중이지 않아서 blue가 실행되고 green서버가 다운된 것을 확인할 수 있다.

마무리

이렇게 우여곡절 끝에 green-blue 무중단배포를 구현하게 됐습니다. 어려운 점이 많이 있었지만.. 역시.. 삽질하면서 하다 보면 언젠가는 구현하는 것 같습니다.!! 궁금하거나 틀린 부분이 있으면 말씀해 주세요!! 감사합니다

Reference

Jenkins, Docker를 이용한 무중단 배포 시작하기

시작하기 예전에는 배포하는 날이면 접속하는 사용자가 적은 새벽시간에 했다고 본적이 있습니다. 배포를 할 때에는 새로운 버전의 jar 파일을 배포할 서버로 복사시키고, 직접 SSH로 접속하여 ja

iseunghan.tistory.com

[MySQL]FULLTEXT with N-GRAM 전문 검색 을 사용한 최적화

코드기록사 — Fri, 12 Jul 2024 17:52:52 +0900

FULLTEXT with N-GRAM 전문 검색을 사용해 보자

들어가며

웹사이트를 사용하다 보면 검색 기능을 쉽게 접할 수 있습니다. 기본적으로 많은 웹사이트는 엘라스틱서치(Elasticsearch)를 사용하여 손쉽게 검색 기능을 구현하고 개선합니다. 그러나 MySQL에서도 FULLTEXT와 N-GRAM을 지원하여 검색 기능을 최적화할 수 있습니다. 이번 포스팅에서는 MySQL을 사용하여 검색 기능을 최적화하는 방법에 대해 알아보겠습니다.

FullText Index

동작 방식

FULLTEXT 검색은 관계형 데이터베이스에서 텍스트 기반의 검색 기능을 제공하는 중요한 기술입니다. 특히 MySQL과 같은 데이터베이스에서는 FULLTEXT 인덱스를 통해 이 기능을 구현할 수 있습니다. 이 인덱스는 텍스트 필드 내의 단어들을 색인화하여 빠르게 검색할 수 있도록 돕습니다.

일반적으로 데이터베이스에서 LIKE 문을 사용하여 검색할 때는 데이터가 적을 때는 빠를 수 있지만, 데이터가 많아지면 성능 문제가 발생할 수 있습니다. 특히 LIKE 문에서 %_, _%, %_%과 같은 와일드카드 패턴을 사용할 경우 인덱스를 효과적으로 활용하기 어렵습니다. 이때 FULLTEXT 인덱스는 이러한 패턴 검색을 지원하며 빠른 속도로 데이터를 검색할 수 있습니다.

예를 들어, FULLTEXT 인덱스를 사용하여 다음과 같은 검색을 수행할 수 있습니다:

LIKE 'apple%': FULLTEXT 인덱스는 이 패턴을 지원하여 빠르게 결과를 반환할 수 있습니다.
LIKE '%orange%': FULLTEXT 인덱스 역시 이러한 패턴을 효율적으로 처리할 수 있습니다.

FULLTEXT 검색은 단순히 텍스트 매칭을 넘어서, 단어의 의미론적인 관계나 가까운 거리에 있는 단어들을 검색할 수 있는 기능도 제공합니다. 이는 사용자가 원하는 검색 결과를 더 정확하게 찾을 수 있도록 도와줍니다.

FULLTEXT 검색

FULLTEXT검색은 일반적으로 다음과 같은 필드 유형에만 적용됩니다.

CHAR

VARCHAR

TEXT

FULLTEXT 인덱스 생성

인덱스 생성 방법

CREATE FULLTEXT INDEX idx_name ON table_name(column1, column2, ...);

사용 방법

- IN NATURAL LANGUAGE MODE

SELECT * FROM TABLE
WHERE MATCH(column) AGAINST ('keyword' IN NATURAL LANUGUAGE MODE);

키워드 토큰화: 검색할 키워드를 공백을 기준으로 토큰화하여 각각의 단어로 분리합니다. 예를 들어, "apple pie"라는 검색어는 "apple"과 "pie"로 분리됩니다.
단어 포함 검색: 분리된 각 단어 중 하나라도 테이블의 해당 컬럼에 포함되어 있으면 해당 레코드를 검색 결과로 반환
합니다. 즉, OR 조건과 비슷하게 동작하며, 하나 이상의 단어가 포함된 레코드를 검색합니다.

- IN BOLEAN MODE

SELECT * FROM TABLE
WHERE MATCH(column) AGAINST ('keyword' IN BOOLEAN MODE);

키워드 분리: 검색할 키워드를 공백을 기준으로 토큰화하여 각각의 단어로 분리합니다. 예를 들어, "apple pie"라는 검색어는 "apple"과 "pie"로 분리됩니다.
부울 연산자 사용: BOOLEAN MODE에서는 부울 연산자(+, -, *, " 등)를 사용하여 검색 조건을 명확히 할 수 있습니다.

Operate	Description
+	반드시 포함하는 단어
-	반드시 제외하는 단어
>	포함하면서 검색 순위를 높일 단어
<	포함하지만 검색 순위를 낮출 단어
()	하위 표현식으로 그룹화
~	'_' 연산자와 비슷하나 제외 시키지 않고 검색 조건 낮춤
*	와일드 카드
""	구문 정의

FULLTEXT 인덱스 설정

show variables like '%ft_min%';

단어를 2글자로 검색하게 된다면 검색이 되지 않습니다. 왜냐면 기본적으로 검색되는 단어의 길이가 4로 되어있는걸을 볼 수 있습니다. 만약 2 글자도 검색이 가능하게 하고 싶으면 설정을 변경하시면 됩니다.(my.ini, cnf의 파일에서 ft_min_word_len="바꿀 길이수" 변경하시면 됩니다.)

일반 검색

FullText 검색

일반 like문을 사용 시에 테이블 풀스캔을 통해 모든 데이터를 조회했지만, 인덱스를 생성 후 match() - against()을 사용하게 되면 fulltext인덱스를 사용하면서 성능적인 우의를 찾는 것을 볼 수 있습니다.

하지만 조회되는 데이터의 수가 다른 것을 볼 수 있습니다. 문제의 원인은 FULLTEXT 인덱스에서 사용되는 토큰화 방식에 있습니다. FULLTEXT 검색에서는 기본적으로 공백을 기준으로 단어를 분리하여 토큰화합니다. 따라서 "돼지고기"와 "돼지고기"는 다르게 인식될 수 있습니다.

N-GRAM

N-GRAM은 텍스트를 N개의 연속된 문자 또는 단어로 분할하는 방법입니다. 이를 통해 텍스트의 부분 문자열을 검색할 수 있게 합니다. 예를 들어, "hello"라는 단어를 2-그램(바이그램)으로 분할하면 다음과 같은 조각들이 생성됩니다:

"he" , "el", "ll" , "lo"로 토큰을 만들게 됩니다. 띄어 씌기가 있을 경우, 띄어쓰기를 제거 후 하나의 단어로만 존재하게 됩니다.

위에서 FullText만 사용했을 때 발생한 문제점을 해결하려면 N-gram을 함께 사용한 인덱스를 생성하면 됩니다.

FULLTEXT With N-gram 인덱스 생성

ALTER TABLE example ADD FULLTEXT INDEX ngram_idx (content) WITH PARSER ngram;

생성 후 실행하 보면 FullText 인덱스를 사용하는 것을 볼 수있다. 하지만 13개가이난 무려 10705개가 조회된것을 볼수 있다.

조회된 데이터를 보면 "돼지", "고기" 단어가 들어간 단어가 조회되면서 데이터가 많은 데이터를 조회되는 것을 볼 수 있다.

FULLTEXT With N-gram 인덱스 단점

너무 많은 데이터 조회: N-gram을 사용하면 특정 단어의 일부만으로도 해당 단어를 포함한 많은 데이터가 조회될 수 있습니다. 예를 들어, "돼지"와 "고기"라는 두 단어가 각각 포함된 모든 데이터가 조회될 수 있습니다. 이는 사용자가 원하는 검색 결과와 실제로 조회된 결과가 다를 수 있는 원인이 됩니다.
정확도 저하: 특히 단어의 일부만으로 조회되는 경우, 원하는 결과와 다른 데이터가 섞일 수 있어 검색 결과의 정확도가 저하될 수 있습니다.
성능 저하: N-gram을 사용하여 데이터베이스를 쿼리 할 때는 추가적인 연산이 필요하며, 많은 데이터가 조회될 경우 성능이 저하될 수 있습니다.
문맥 파악의 어려움: N-gram은 단어의 일부를 기반으로 검색을 수행하기 때문에 문맥을 완전히 이해하지 못할 수 있습니다. 예를 들어, "돼지고기"라는 단어가 포함된 데이터는 "돼지"와 "고기"라는 단어가 각각 포함된 데이터와 다를 수 있습니다.

정리

하지만 기본적인 MySQL에서 지원해 주는 것만으로도 많은 성능 개선되는 것을 볼 수 있습니다. 아래와 같이 같은 돼지고기를 검색하면

2476건의 데이터를 조회하는 데 0.093sec 걸린반면 10705건을 조회하는데 걸린 시간은 0.032 sec가 걸린 것을 보면

엄청 빠른 속도로 검색되는 것을 확인할 수 있습니다. 검색조건을 추가하거나 위에 작성한 부울 검색을 활용해서 잘만 적용한다면 MySQL에서도 충분히 빠른 속도로 검색이 가능할 것 같습니다.

Reference

MySQL :: InnoDB 전문 검색 : N-gram Parser

기본 InnoDB 전문 검색(Full Text) 파서는 공백이나 단어 분리자가 토큰인 라틴 기반 언어들에서는 이상적이지만 개별 단어에 대한 고정된 구분자가 없는 중국어, 일본어, 한국어(CJK)같은 언어들에서

dev.mysql.com

[SpringBoot] Let's encrypt - 스프링 부트 SSL/TLS 인증서 발급 받기

코드기록사 — Fri, 12 Jul 2024 16:29:21 +0900

SSL/TLS인증서를 발급받기

들어가며

이번 포스팅에서는 스프링 부트를 사용하는 애플리케이션이 Let`s encrypt를 이용한 SSL/TLS 인증서를 발급받고 설정하는 방법을 알아보도록 하겠습니다.

SSL/TLS란

SSL(Secure Sockets Layer)와 TLS(Transport Layer Secuity)는 인터넷상에서 데이터의 기밀성과 무결성을 보장하는 보안 프로토콜입니다. 이 프로토콜은 주로 웹 서버 간의 통신을 암호화하여 데이터를 안전하게 전송하기 위해 사용됩니다.

Let's Encrypt

et's Encrypt는 무료, 자동, 개방형, 인증 기관(CA)입니다. 인터넷 보안을 개선하고 HTTPS 사용을 장려하기 위해서 비영리 단체로 설립되었습니다. 그래서 Let's Encrypt는 누구나 무료로 SSL/TLS 인증서를 발급받아 웹사이트에 HTTPS를 적용 가능합니다.

특징

가격 : AWS나 다른 상용 인증서와 달리 Let’s Encrypt 무료로 인증서를 발급받을 수 있습니다.
자동화 : 인증서를 발급받을 때 설치, 갱신, 발급 과정을 명령어를 사용해 자동화하여 편의성을 제공합니다.
개방형 : 모든 사용자가 공개적인 API의 인증서를 발급 가능
투명성 : 발급받은 인증서는 공개되므로 누가 발급받았는지 알 수 있습니다.

작동 방식

도메인 소유권 확인 : 해당 도메인이 존재하는지 실제로 소유하고 있는지 확인
인증서 발급 : 소유권이 확인되면 해동 도메인에 대해서 SSL/TLS를 발급
인증서 설치 및 갱신 : 발급된 인증서는 자동으로 웹서버에 설치되며, 인증서의 유효 기간(보통 90)이 만료되기 전에 자동 갱신

인증서 발급 방법

필자는 Windows10 pro, aws Linux 기준으로 작성되었습니다.

1. SSH 서버로 접속합니다.

저는 Mobaxterm를 사용 중이니 다운 방법이 궁금하시면 다음 글을 통해 설치해주시면 될 것 같습니다.

MobaXterm 다운 방법

MobaXterm 다운하기 MobaXterm란? MobaXterm은 Windows 운영 체제에서 사용할 수 있는 다목적 원격 접속 및 시스템 관리 도구이다. 이 프로그램은 SSH, RDP, X11, SFTP 등 다양한 프로토콜을 지원하여 원격 서버

back-stead.tistory.com

2. Cerbot을 설치합니다.

sudo yum install certbot

3. 인증 방법 선택

인증서를 발급받기 옵션에는 여러 가지가 존재합니다, --standalone , --webroot ,--apache 등등 여러 가지가 존재하지만, 스프링 서버에서 적용할 인증서를 발급받는 거기 때문에 --standalone 을 사용해 독립 실행을 하여 웹서버의 소유권을 확인해 인증서를 발급받을 것입니다.

sudo certbot certonly --standalone

실행 후 발급받은 도메인과, 이메일 주소를 입력하고 나면 정상적은 도메인을 가진 경우라면

/etc/letsencrypt/live/도메인/ 경로에 fullcahin.pem과 privkey.pem 가 발급되었다고 안내합니다.

4. keyStore 발급

스프링 부트에서 https를 사용하려면 이전에 발급받았던 pem 방식이 아닌 keySotre 방식으로 사용해야 합니다. 그래서 아래 명령어를 통해 keySotre 파일을 생성해야 합니다. 인증서가 발급된 디렉터리로 이동해 아래 명령어를 실행해 줍니다.

그럼 비밀번호를 입력하고 나면 keystore.12 파일이 생성된 것을 볼 수 있습니다.

sudo openssl pkcs12 -export -in fullchain.pem -inkey privkey.pem -out keystore.p12 -name ttp -CAfile chain.pem -caname root

5. keystore 로컬에 다운로드

이제 발급받은 keystore.12 인증서를 로컬에 다운로드하아야 합니다. 필자는 윈도를 사용하고 있어 아래 명령어를 통해 ssh 서버의 데이터를 다운로드하였습니다.

PowerShell을 실행하여 아래 명령어를 통해 파일을 다운로드하여줍니다.

scp -i [AWS PEM 경로] [사용자명]@[EC2_IP주소]:[keystore.12가 저장된 파일경로] [로컬에 다운 받을 경로]

6. 스프링 부트 적용

resources의 파일을 저장하고, yaml파일아 다음과 같이 작성해 줍니다.

server:
	ssl:
    	key-store: classpath:ssl/keystore.p12
    	key-store-type: PKCS12
    	key-store-password: 변환후입력헀던비밀번호
    port: 8443

그 후 AWS에서 Spring 서버를 실행해 줍니다.

결과

인증서가 올바르게 발급되어 실행되는 것을 볼 수 있습니다.

Reference

Let's Encrypt

Jun 24, 2024 NTP is critical to how TLS works, and now it’s memory safe at Let’s Encrypt. Read more May 30, 2024 Increasing defense against BGP attacks thanks to support from the Open Technology Fund. Read more May 1, 2024 Takeaways from Tailscale’s

letsencrypt.org

SSL 인증서란 무엇인가요? - SSL/TLS 인증서 설명 - AWS

SSL/TLS 인증서란 무엇입니까? SSL/TLS 인증서는 시스템에서 ID를 확인하고 이후에 Secure Sockets Layer/전송 계층 보안(SSL/TLS) 프로토콜을 사용하여 다른 시스템에 대한 암호화된 네트워크 연결을 설정할

aws.amazon.com

[SpringBoot] @Qualifier 사용하기

코드기록사 — Tue, 18 Jun 2024 05:52:24 +0900

@Qualifier 사용해 보자!

들어가며

개발을 하다 보면 종종 여러 구현체가 동일한 인터페이스를 구현하게 됩니다. 이럴 때 어떤 구현체를 사용할지에 대해서 지정해 주는 에노테이션입니다. 이번 포스팅에서는 사용방법에 대해서 알아보도록 하겠습니다.

@Qualifier이란

@Qualifier 어노테이션은 DI할때 어떤 빈을 등록할 것인지를 명시해 줄 때 사용됩니다. 하지만 기본적으로는 @Autowired을 통해서 DI를 하게 되지만, 동인 한 인터페이스를 가진 구현체가 있을대 @Autowired를 사용하게 되면 빈이 유일하지 않다는 NoUniqueBeanDefinitionException 예외를 발생하게 됩니다. 이럴 때에 구현체를 지정해 주기 때문에 예외를 피할 수 있습니다.

즉 동일한 Interface를 가진 구현체의 대해서 명시할 때 사용됩니다.

@ Qualifier 예시

다음과 같이 이메일 전송에 관한 서비스의 두 개의 이메일 로직을 구현했다고 가정해 봅시다.

public class findEmail implements EmailService {
    public void send() {
        // 찾기 이메일 로직
    }
}


public class joinEmail implements EmailService {
   public void send() {
        // 가입 이메일 로직
    }
}

public interface EmailService {
  
  void send();
  
}

만약 이 상태에서 DI(의존성 주입)을 하게 되면 위에 설명했던 것처럼 예외가 발생합니다. 스프링 컨테이너에서 두 개의 빈이 등록되어 있으니 Spring빈은 스프링 컨테이너에서 어떤 빈이 해당 로직에서 어떤 구현체를 주입해줘야 하는지 모르기 때문에 NoUniqueBeanDefinitionException 예외가 발생하게 됩니다. 이때 명시적으로 'joinEmail' 구현체를 사용할 거야!라고 명시해 주면 Spring이 아! 이걸 사용하는구나라고 알 수 있어서 올바르게 빈을 등록해 줍니다. @Qualifier 에노테이션은

@Qualifier("JoinEmail")
public class joinEmail implements EmailService {
   public void send() {
        // 가입 이메일 로직
    }
}

클래스상단에 작성해 주면 됩니다.

DI 주입 방법

생성자 주입 시

Lombook을 사용하고 있다면 final 필드에 붙여 작성해 주면 됩니다.

@Qualifier("JoinEmail")
private final MailService mailService;

[오류] @RequiredArgsConstructor과 @Qualifier 이슈

오류 발생롬복의 @RequiredArgsConstructor을 통해 생성자 주입을 아주 편리하게 사용하고 있는 도중에동일한 인터페에스를 사용하는 여러 구현체가 있어서 @Qualifier오류가 뜬것이 아닌가.......(┬┬

back-stead.tistory.com

(롬복 생성자 주입 오류시 해당 포스팅 참고 바랍니다!!)

기존 생성자 주입 시

파라미터에 에노테이션을 작성해 주면 됩니다.

public EmailController(@Qualifier("JoinEmail") MailService mailService) {
	this.mailService = mailService;
}

Reference

Badldung

[오류] @RequiredArgsConstructor과 @Qualifier 이슈

코드기록사 — Tue, 18 Jun 2024 05:50:22 +0900

오류 발생

롬복의 @RequiredArgsConstructor을 통해 생성자 주입을 아주 편리하게 사용하고 있는 도중에

동일한 인터페에스를 사용하는 여러 구현체가 있어서 @Qualifier

오류가 뜬것이 아닌가.......(┬┬﹏┬┬)

그래서 찾아보니.

@RequiredArgsConstructor 어노테이션은 final이거나 @NonNull이 붙은 필드에 대해 생성자를 자동으로 만들어 주기 때문에 @Qualifier 어노테이션이 붙은 필드에 대해서는 @Qualifier 어노테이션을 생성자의 매개변수에 복사하지 않기 때문에 생성자를 주입할 수 없는 오류가 발생했던 것이다..

해결책

Lombock.config 파일의 다음과 같은 설정을 추가해 주고 Rebuild Project를 해주면 된다.

lombok.copyableAnnotations += org.springframework.beans.factory.annotation.Qualifier

해당 명령어를 작성해 주면 Lombok은 @Qualifier 어노테이션을 생성자의 매개변수에 복사 하게게됩니다.!

정상적으로 실행된 것을 볼 수 있다.

Reference

podo-dev : @RequiredArgsConstructor과 @Qualifier 같이 사용 시 이슈 해결법

문제 Lombok의 @RequiredArgsConstructor는 final인 필수 멤버변수에 대해서, 자동으로 생성자를 만들어주는 어노테이션입니다. 문제는 다음과 같은 상황일때, 발생합니다. ``` java @RequiredArgsConstructor public c

www.podo-dev.com

Springboot dependency: two dependencies found and Qualifier ignored

This is my class: @Repository @RequiredArgsConstructor @Slf4j public class ServeiTerritorialCatalegsClientRepositoryImpl implements ServeiTerritorialCatalegsClientRepository { @Qualifier("

stackoverflow.com

[MySQL] CSV 파일 Import 및 Export: 간편 가이드

코드기록사 — Tue, 18 Jun 2024 04:52:13 +0900

MySQL에서 데이터를 Import 및 Export 해보자!

들어가며

로컬 환경에서 작업한 데이터를 AWS 또는 다른 데이터베이스(DB)로 효율적으로 이관하는 방법을 LOAD DATA INFILE을 사용하는 방법이 있습니다. 이 방법은 데이터를 빠르게 로드할 수 있어 사용하는 방법을 한번 알아보도록 하겠습니다.

설정 확인하기

LOAD DATA INFILE을 사용하기 전에 먼저 환경 설정을 확인해야 합니다.

SHOW VARIABLES LIKE 'local_infile';

위 명령어를 통해 해당 Mysql의 설정 정보를 확인해 줍니다. 만약

Value가 Off로 되어있다면 아래 명령어를 입력해 On으로 변경해줍니다.

SET GLOBAL local_infile=1;

설정파일 변경 시(Windows 기준)

C:\ProgramData\MySQL\MySQL Server 8.0\my.ini

설정 파일에서 직접 ' local_infile=1 ' 명령어를 작성해 줄수도 있습니다. 위와 동일합니다.

WorkBench 설정

workbench에서 접속할 connection의 edit connection에 들어갑니다.
Advanced탭의 Others에 OPT_LOCAL_INFILE=1 입력합니다.

OPT_LOCAL_INFILE=1

Export

Export란 MySQL 데이터베이스에서 데이터를 외부 파일로 내보내는 작업을 말합니다. csv와 같은 데이터파을을 외부로 추출해 내는 것을 말합니다.

SELECT column1, column2, ...
INTO OUTFILE '\경로\저장할 파일명.csv'
FIELDS TERMINATED BY ',' 
OPTIONALLY ENCLOSED BY '"'
LINES TERMINATED BY '\n'
FROM 테이블명
WHERE condition;

INTO OUTFILE : 결과를 지정된 파일로 Export 합니다.
FIELDS TERMINATED BY ', ' : 각 열을 쉼표로 구분합니다.
OPTIONALLY ENCLOSED BY '"' : 필드 값이 문자열일 경우 따옴표로 묶습니다.
LINES TERMINATED BY '\n' : 각 행을 개행 문자로 구분합니다.

파일 경로에서 (Windos 기준) 경로를 'C:/ProgramData/MySQL/MySQL Server 8.0/Uploads/' 다음 경로를 작성 후 파일명을 작성해줘야 한다. 안 그러면 1209 에러가 뜨면서 사용할 수 없게 된다. 이 에러는 파일의 입출력 경로가 다를 경우에 발생하는 에러이다. 기본적으로 mysql의 구성파일을 보면 다음과 같이 기본 경로가 설정된 것을 볼 수 있다. (수정하면 수정한 경로로 저장이 된다.)

Export 성공 시

정상적으로 약 18만 개의 데이터가 0.5초 만에 csv파일로 만들어진 것을 볼 수 있다. csv파일 안에 내용은 인코딩 형식이 맞지 않아 정상적으로 출력 도지 않지만 db에 바로 Import 할 거 기 때문에 굳이 설정까지 안 해도 된다.

Import

Import란 외부 파일에서 데이터를 MySQL 데이터베이스로 가져오는 작업을 말합니다. 지금 csv로 뽑은 데이터를 다시 다른 db로 넣는 행위라고 할 수 있습니다.

Import 하는 방법이 두 가지가 있습니다. 워크벤치에서 Table Data Export 하는 방법과 LOAD DATA INFILE 명령어를 사용해서 하는 방법이 존재합니다. Table Data Export로 데이터를 Import를 하게 되면 outfile의 배해 속도가 엄청 차이 납니다. 그래서 여기서는 LOAD DATA INFILE을 사용해 Import를 해보도록 하겠습니다.

Table Data Export

Table Data Export는 간단하게 버튼 클릭으로 데이터를 Import 할 수 있습니다.

LOAD DATA INFILE

LOAD DATA INFILE '/경로/저장한 파일명.csv'
INTO TABLE table_name
FIELDS TERMINATED BY ',' 
OPTIONALLY ENCLOSED BY '"'
LINES TERMINATED BY '\n'
IGNORE 1 LINES;

INTO TABLE : 데이터를 지정된 테이블로 Import 합니다.
FIELDS TERMINATED BY ',' : 각 열을 쉼표로 구분합니다.
OPTIONALLY ENCLOSED BY '"' : 필드 값이 문자열일 경우 따옴표로 묶습니다.
LINES TERMINATED BY '\n' : 각 행을 개행 문자로 구분합니다.
IGNORE 1 LINES : CSV 파일의 첫 번째 줄은 보통 헤더이므로 Import 시 무시할 수 있습니다.

Import시에 약 18만 개의 데이터가 2초도 안돼서 삽입되는 것을 볼 수 있다.

데이터도 db에 정상적으로 출력되는 것을 볼 수 있다!

aws rds에 로드 시!!

LOAD DATA LOCAL INFILE 'C:/ProgramData/MySQL/MySQL Server 8.0/Uploads/blog.csv'
INTO TABLE recipe
FIELDS TERMINATED BY ',' ENCLOSED BY '"'
LINES TERMINATED BY '\n';

INFILE 종류

LOAD DATA LOCAL INFILE: 클라이언트 로컬 파일 시스템에서 업로드.
LOAD DATA INFILE: 서버 파일 시스템에서 업로드.

RDS IMPORT

먼저 RDS에서 Import를 하기 위해서는 파라미터 그룹을 직접 변경해줘야 한다.

파라미터 그룹을 생성하고 사용 중인 RDS와 연결을 한상태에서

파라티터 그룹 → 파라미터 편집 → local_infile 검색 → 값을 1로 변경

변경사항을 저장을 하고 RDS를 재부팅하고 나면 Infile 명령어를 통해서 import를 할 수 있을 것입니다.!