간단 정리 정규화란 데이터를 안전하게 관리하기 위한 설계 방법이다. 제1 정규화는 한 컬럼에 하나의 데이터만 존재하도록 만드는 것이다. 제2 정규화는 제1 정규화 + 현재 테이블의 주제와 관련이 없는 컬럼을 분리(다른 테이블)하는 것이다. 제3 정규화는 제2 정규화 + 일반 컬럼에만 종속된 컬럼을 분리(다른 테이블)하는 것이다.

DB 정규화

데이터베이스 설계에서 정규화(Normalization) 는 데이터 중복을 제거하고, 데이터 무결성을 유지하며, 이상 현상(anomaly)을 방지하기 위해 사용되는 기법입니다. 이 글에서는 정규화의 기본 개념과 주요 정규형(1NF, 2NF, 3NF, BCNF 등)을 살펴보고, 실제 예제를 통해 정규화가 어떻게 적용되는지 확인해보겠습니다.

1. 정규화의 기본 개념

정규화의 주요 목적은 다음과 같습니다

데이터 중복 제거: 동일한 정보를 여러 테이블에 반복 저장하지 않아 데이터 불일치를 방지합니다. 데이터 무결성 유지: 삽입, 갱신, 삭제 작업 시 발생할 수 있는 이상 현상을 최소화합니다. 효율적인 관리: 관련 데이터를 논리적으로 분리하여 유지보수와 쿼리 성능을 개선합니다.

2. 정규형의 단계

[ 제1 정규화 ]

제1 정규화란 테이블의 컬럼이 원자값(Atomic Value, 하나의 값)을 갖도록 테이블을 분해하는 것이다. 예를 들어 아래와 같은 고객 취미 테이블이 존재한다고 하자. 

위의 테이블에서 추신수와 박세리는 여러 개의 취미를 가지고 있기 때문에 제1 정규형을 만족하지 못하고 있다. 그렇기 때문에 이를 제1 정규화하여 분해할 수 있다. 제1 정규화를 진행한 테이블은 아래와 같다.

[ 제2 정규화 ]

제2 정규화란 제1 정규화를 진행한 테이블에 대해 완전 함수 종속을 만족하도록 테이블을 분해하는 것이다. 여기서 완전 함수 종속이라는 것은 기본키의 부분집합이 결정자가 되어선 안된다는 것을 의미한다. 예를 들어 아래와 같은 수강 강좌 테이블을 살펴보자.   

이 테이블에서 기본키는 (학생번호, 강좌이름)으로 복합키이다. 그리고 (학생번호, 강좌이름)인 기본키는 성적을 결정하고 있다. (학생번호, 강좌이름) --> (성적) 그런데 여기서 강의실이라는 컬럼은 기본키의 부분집합인 강좌이름에 의해 결정될 수 있다. (강좌이름) --> (강의실)즉, 기본키(학생번호, 강좌이름)의 부분키인 강좌이름이 결정자이기 때문에 위의 테이블의 경우 다음과 같이 기존의 테이블에서 강의실을 분해하여 별도의 테이블로 관리하여 제2 정규형을 만족시킬 수 있다.

[ 제3 정규화 ]

제3 정규화란 제2 정규화를 진행한 테이블에 대해 이행적 종속을 없애도록 테이블을 분해하는 것이다. 여기서 이행적 종속이라는 것은 A -> B, B -> C가 성립할 때 A -> C가 성립되는 것을 의미한다. 예를 들어 아래와 같은 계절 학기 테이블을 살펴보자. 

    기존의 테이블에서 학생 번호는 강좌 이름을 결정하고 있고, 강좌 이름은 수강료를 결정하고 있다. 그렇기 때문에 이를 (학생 번호, 강좌 이름) 테이블과 (강좌 이름, 수강료) 테이블로 분해해야 한다.  이행적 종속을 제거하는 이유는 비교적 간단하다. 예를 들어 501번 학생이 수강하는 강좌가 스포츠경영학으로 변경되었다고 하자. 이행적 종속이 존재한다면 501번의 학생은 스포츠경영학이라는 수업을 20000원이라는 수강료로 듣게 된다. 물론 강좌 이름에 맞게 수강료를 다시 변경할 수 있지만, 이러한 번거로움을 해결하기 위해 제3 정규화를 하는 것이다. 즉, 학생 번호를 통해 강좌 이름을 참조하고, 강좌 이름으로 수강료를 참조하도록 테이블을 분해해야 하며 그 결과는 다음의 그림과 같다.

[ BCNF 정규화 ]

BCNF 정규화란 제3 정규화를 진행한 테이블에 대해 모든 결정자가 후보키가 되도록 테이블을 분해하는 것이다. 예를 들어 다음과 같은 특강수강 테이블이 존재한다고 하자.  

  특강수강 테이블에서 기본키는 (학생번호, 특강이름)이다. 그리고 기본키 (학생번호, 특강이름)는 교수를 결정하고 있다. 또한 여기서 교수는 특강이름을 결정하고 있다. 그런데 문제는 교수가 특강이름을 결정하는 결정자이지만, 후보키가 아니라는 점이다. 그렇기 때문에 BCNF 정규화를 만족시키기 위해서 위의 테이블을 분해해야 하는데, 다음과 같이 특강신청 테이블과 특강교수 테이블로 분해할 수 있다.

3. 실무 적용 예제: 주문 관리 시스템

아래는 주문 관리 시스템에서의 비정규화된 테이블을 정규화하는 과정을 보여주는 예제입니다.

3.1 비정규화된 테이블 구조

CREATE TABLE Orders (
    OrderID INT,
    CustomerName VARCHAR(100),
    ProductID INT,
    ProductName VARCHAR(100),
    Quantity INT,
    PRIMARY KEY (OrderID, ProductID)
);

이 구조에서는 고객 정보와 상품 정보가 하나의 테이블에 함께 저장되어 데이터 중복 및 업데이트 이상 현상이 발생할 수 있습니다.

3.2 정규화된 테이블 구조

고객과 상품 정보를 별도의 테이블로 분리하여 2NF와 3NF를 만족시키는 예제입니다.

고객 테이블

CREATE TABLE Customers (
    CustomerID INT PRIMARY KEY,
    CustomerName VARCHAR(100)
);

상품 테이블

CREATE TABLE Products (
    ProductID INT PRIMARY KEY,
    ProductName VARCHAR(100)
);

주문 및 주문 상세 테이블

CREATE TABLE Orders (
    OrderID INT PRIMARY KEY,
    CustomerID INT,
    OrderDate DATE,
    FOREIGN KEY (CustomerID) REFERENCES Customers(CustomerID)
);

CREATE TABLE OrderDetails (
    OrderID INT,
    ProductID INT,
    Quantity INT,
    PRIMARY KEY (OrderID, ProductID),
    FOREIGN KEY (OrderID) REFERENCES Orders(OrderID),
    FOREIGN KEY (ProductID) REFERENCES Products(ProductID)
);

이 구조를 통해 고객 정보와 상품 정보가 별도의 테이블로 분리되며, 데이터의 중복 저장을 방지하고, 각 테이블의 수정 및 유지보수가 용이해집니다.

4. 정규화의 장단점

장점 데이터 무결성 보장 업데이트 이상(삽입, 삭제, 갱신) 최소화 효율적인 데이터 관리

단점 조인(Join) 연산 증가로 인한 성능 저하 가능성 복잡한 쿼리로 인한 관리 어려움 과도한 정규화 시 오히려 성능 저하 우려

장점: 데이터의 중복을 제거하여 무결성을 높이고, 변경 시 발생할 수 있는 이상 현상을 줄입니다. 단점: 여러 테이블로 분리되어 데이터를 조회할 때 조인이 많이 필요하므로 성능 저하가 발생할 수 있으며, 상황에 따라 일부 의도적인 비정규화(Denormalization)가 필요할 수 있습니다.

결론

데이터베이스 정규화는 데이터 중복 제거와 무결성 유지를 위한 핵심 설계 기법입니다. 실무에서는 정규화와 비정규화 사이의 균형을 잘 맞추어 최적의 데이터베이스 성능을 확보하는 것이 중요합니다.

위의 예제와 같이, 비정규화된 데이터를 정규화하면 데이터의 일관성과 관리 효율성이 향상됩니다. 필요에 따라 SQL 코드와 마크다운 표 예시를 참고하여 자신의 시스템에 맞는 최적의 구조를 설계해 보시기 바랍니다.

출처: https://mangkyu.tistory.com/110 [MangKyu's Diary:티스토리]

인덱스란 데이터베이스에서 검색 성능을 향상시키기 위해 사용하는 자료구조이다. 마치 책의 목차처럼 특정 데이터를 빠르게 찾을 수 있도록 도와준다. 인덱스가 없을 경우, 데이터베이스는 원하는 데이터를 찾기 위해 전체 테이블을 조회(Full Table Scan)해야 하지만, 인덱스를 사용하면 원하는 데이터를 효율적으로 검색할 수 있다.

한마디로, 정렬해놓은 컬럼 사본을 의미한다.

2. 인덱스의 동작 원리

인덱스는 일반적으로 B-Tree 또는 Hash 구조를 이용하여 데이터를 정렬하거나 해싱하여 관리한다. 예를 들어, B-Tree 인덱스는 정렬된 데이터를 유지하면서 검색, 삽입, 삭제 작업을 효율적으로 수행할 수 있도록 한다. 이를 통해 특정 값을 빠르게 찾고, 범위 검색도 효과적으로 수행할 수 있다.

3. 인덱스의 종류

3.1 기본(Basic) 인덱스

클러스터형 인덱스(Clustered Index)

테이블의 데이터가 인덱스에 의해 정렬된 형태로 저장된다.

한 테이블당 하나의 클러스터형 인덱스만 생성 가능하다.

검색 속도가 빠르지만, 데이터 삽입/삭제 시 재정렬이 필요할 수 있다.

비클러스터형 인덱스(Non-Clustered Index)

데이터 자체는 정렬되지 않고, 별도의 인덱스 페이지가 존재하여 검색 시 실제 데이터 페이지로 매핑된다.

한 테이블에 여러 개의 비클러스터형 인덱스를 생성할 수 있다.

3.2 특수 인덱스

유니크 인덱스(Unique Index)

중복 값을 허용하지 않는 인덱스이다.

PRIMARY KEY 또는 UNIQUE 제약 조건을 적용할 때 사용된다.

복합 인덱스(Composite Index)

여러 개의 컬럼을 조합하여 생성하는 인덱스이다.

특정 컬럼 조합에 대한 검색 성능을 높일 수 있다.

해시 인덱스(Hash Index)

키-값 기반의 해시 테이블을 사용하여 데이터를 검색한다.

동등(=) 검색에는 빠르지만 범위 검색에는 적합하지 않다.

부분 인덱스(Partial Index)

테이블의 특정 부분만을 대상으로 생성하는 인덱스이다.

필요하지 않은 데이터까지 인덱싱하는 비용을 줄일 수 있다.

4. 인덱스의 장점과 단점

4.1 장점

검색 속도 향상: 특정 컬럼에 대한 검색이 빠르게 수행됨.

정렬 속도 개선: ORDER BY 절을 사용할 때 성능 향상.

조인 성능 향상: 조인 시 필요한 키 값을 빠르게 찾을 수 있음.

4.2 단점

INSERT/UPDATE/DELETE 성능 저하: 인덱스가 많을수록 데이터 변경 시 추가적인 인덱스 관리 비용 발생.

디스크 공간 사용 증가: 인덱스는 별도의 저장 공간을 차지하므로 테이블 크기가 증가함.

과도한 인덱스 생성 시 오버헤드 발생: 너무 많은 인덱스는 오히려 성능을 저하시킬 수 있음.

5. 인덱스 사용 예제 (MySQL 기준)

5.1 기본 인덱스 생성

CREATE INDEX idx_user_name ON users(name);

5.2 클러스터형 인덱스 (PRIMARY KEY)

CREATE TABLE users ( id INT PRIMARY KEY, name VARCHAR(100), email VARCHAR(100) );

5.3 비클러스터형 인덱스 생성

CREATE INDEX idx_email ON users(email);

5.4 복합 인덱스 생성

CREATE INDEX idx_name_email ON users(name, email);

5.5 인덱스 삭제

DROP INDEX idx_user_name ON users;

6. 인덱스 활용 및 최적화 전략

자주 조회되는 컬럼에 대해 인덱스를 설정.

중복되지 않는 유니크한 값이 많은 컬럼을 선택하여 인덱스를 생성.

불필요한 인덱스는 제거하여 데이터 삽입/수정 성능을 개선.

쿼리 실행 계획(EXPLAIN)을 사용하여 인덱스가 제대로 활용되는지 확인.

7. 결론

인덱스는 데이터베이스 성능 최적화의 핵심 요소이며, 적절한 사용이 중요하다. 무분별한 인덱스 생성은 오히려 성능 저하를 초래할 수 있으므로, 데이터 특성과 조회 패턴을 고려하여 신중하게 인덱스를 설계해야 한다.

저장 공간

• 저장공간에 값을 저장(할당)하는 법

  // 1 방법
  int number = 10;  // 저장공간 선언과 동시에 값을 할당 = 초기화
  

// 2방벙 int number; // 저장공간 선언 number = 10; // 값을 따로 할당

###  변수 : 변하는 수
 > 변수를 선언하고 언제든 값을 덮어씌울 수 있다.(바꿀 수 있다)

int number = 10; // 1. 변수로 선언 및 초기화 number = 11; // 2. 변수의 값을 바꾼다. (덮어쓰기)

### 상수 : 변하지 않는 수
  > 상수를 선언하면 그 이후로는 값을 바꿀 수 없다.

final int number = 10; // 1. 상수로 선언 (데이터 타입 앞에 final 을 붙이면 됩니다.) number = 11; // e2. 변수의 값을 바꾸려고하면 에러가 납니다!

### 저장공간 타입 종류

1. 논리형(bool) 타입

boolean flag = true; // 1. 논리형 변수 boolean 으로 선언 및 True 값으로 초기화

flag = false; // 2. False 값으로도 저장할 수 있습니다.

2. 문자형 타입

char alphabet = 'A'; // 문자 하나를 저장합니다. ''를 이용

// 문자열은 "" 를 이용 String message = "Hello World!";

3. 정수형 타입

byte byteNumber = 127; // byte 는 -128 ~ 127 범위의 숫자만 저장 가능합니다.

short shortNumber = 32767; // short 는 -32,768~32,767 범위의 숫자만 저장 가능합니다.

int intNumber = 2147483647; // int 는 -21억~21억 범위의 숫자만 저장 가능합니다.

long longNumber = 2147483647L; // long 은 숫자뒤에 알파벳 L 을 붙여서 표기하며 매우 큰수를 저장 가능합니다.

4. 실수형 타입

float floatNumber = 0.123f; // float 는 4byte 로 3.4 * 10^38 범위를 표현하는 실수값 double doubleNumber = 0.123123123; // double 은 8byte 로 1.7 * 10^308 범위를 표현하는 실수값

## 문자와 숫자
메모리는 0과 1로만 이루어진다. 그럼 문자는 어떻게 저장될까? 바로 아스키코드를 통해 숫자로 변환하여 저장한다.
![](https://velog.velcdn.com/images/taketheking/post/986562f5-54f7-4ac6-89e0-563b94b67b05/image.png)


예시)

// 숫자 -> 문자 import java.util.Scanner;

public class Main {

public static void main(String[] args) {
    Scanner sc = new Scanner(System.in);

    int asciiNumber = sc.nextInt();
    char ch = (char)asciiNumber; // 문자로 형변환을 해주면 숫자에 맞는 문자로 표현됩니다.

    System.out.println(ch);
}

}

// 입력 97

// 출력 a

// 문자 -> 숫자

import java.util.Scanner;

public class Main {

public static void main(String[] args) {
    Scanner sc = new Scanner(System.in);

    char letter = sc.nextLine().charAt(0); // 첫번째 글자만 받아오기위해 charAt(0) 메서드를 사용합니다.
    int asciiNumber = (int)letter; // 숫자로 형변환을 해주면 저장되어있던 아스키 숫자값으로 표현됩니다.

    System.out.println(asciiNumber);
}

}

// 입력 a

// 출력 97

float 의 바이트가 더 적은데 어떻게 long보다 넓은 범위를 표현할까?

실수 와 부동 소수점

실수 표현과 부동 소수점에 대해 이해하기 위해서는 먼저 '실수'와 '부동 소수점'이 무엇인지 알아야 합니다.

실수(Real Number): 실수는 소수점이 있는 숫자를 말합니다. 예를 들어, 3.14, 0.01, -2.5 등이 실수입니다. 이러한 실수는 컴퓨터에서 표현하기 위해 '부동 소수점' 방식을 사용합니다.

부동 소수점(Floating Point): 부동 소수점은 실수를 컴퓨터에서 표현하는 방식입니다. '부동'이란 단어가 의미하는 것은 소수점의 위치가 고정되어 있지 않고, '움직일 수 있다'는 것입니다. 이 방식은 매우 큰 수나 매우 작은 수를 표현하는 데 유용합니다.

예를 들어, 0.000123과 123000000.0 두 수를 생각해봅시다. 이 두 수를 부동 소수점으로 표현하면, 각각 1.23 x 10^-4와 1.23 x 10^8로 표현할 수 있습니다. 여기서 1.23은 '가수(mantissa)'라고 하고, -4와 8은 '지수(exponent)'라고 합니다. 이처럼 부동 소수점은 가수와 지수로 이루어져 있습니다.

결론

정수타입(long)은 지수를 사용하지 못하고, 실수타입(float)은 지수를 사용할 수 있다. => 제곱의 사용으로 훨씬 더 큰 수(범위)를 만들어 낼 수 있다. long의 범위 : long은 64비트(8바이트)를 사용하여 정수를 표현합니다. 이는 2의 64승, 즉 약 -9,223,372,036,854,775,808부터 9,223,372,036,854,775,807까지의 정수를 표현할 수 있습니다.

약 -922경 3372조 368억 5477만 5807 ~ +922경 3372조 368억 5477만 5807

float의 범위 : 반면에 float는 32비트(4바이트)를 사용하여 실수를 표현합니다. 그러나 이 32비트는 부동 소수점 방식에 따라 '가수'와 '지수'로 나뉘어 사용됩니다. 이 방식 덕분에 float는 매우 큰 수(약 10^38)부터 매우 작은 수(약 10^-38)까지 표현할 수 있습니다.

약 +-100,000,000,000,000,000,000,000,000,000,000,000,000 > 백간(^38) 억(^8) < 조(^12) < 경(^16) < 해(^20) < 자(^24) < 자(^24) < 양(^28) < 구(^32) < 간(^36) <백간(^38)

public class Main {
    public static void main(String[] args) {
        long a = 10000000000L;  // 10^10, long으로 표현 가능
        float b = 10000000000F;  // 10^10, float으로 표현 가능

        long c = 10000000000000000000L;  // 10^19, long으로 표현 불가능
        float d = 10000000000000000000F;  // 10^19, float으로 표현 가능

        long e = 0.1L;  // 0.1, long으로 표현 불가능
        float f = 0.1F;  // 0.1, float으로 표현 가능
    }
}

10진수의 2진수 변환

10진수 -> 2진수 변환방법

1) 정수부분

10진수를 2진법으로 변환하는 방법은 10진수 숫자를 2로 나눌 수 없을 때까지 나누고 아래에서부터 꺼꾸로 나열하면 변환할 수 있다.

** * 큰 숫자 를 변환할 때**

2) 소수부분

소수 부분을 2로 계속 곱해서 정수 부분이 1이 되면 2진수에서 1로 변환, 정수 부분이 0이 되면 2진수에서 0으로 변환하고 소수부분이 0이 될 때까지 나머지 소수 부분에 계속 2를 곱한다.

무한이 나누어 질때

소수 부분이 0으로 나누어 떨어지지 않고 무한히 나누어지는 경우가 있다. 이때는 무한 소수로 나타낸다.

2진수 -> 10진수 변환방법

1) 정수부분

2) 소수부분 + (정수 부분)

출처 : https://blog.hexabrain.net/357 출처 : https://ourcalc.com/2%EC%A7%84%EC%88%98-%EB%B3%80%ED%99%98%EA%B8%B0/

public class Main {
    public static void main(String[] args) {
        System.out.println("Hello world!");
    }
}

 // () : 소괄호
 // {} : 중괄호
 // [] : 대괄호

클래스 정의

public class Main {...}

(1) public : 접근 제어자 - 접근 권한을 설정 (2) class : 클래스라 정의하는 것 (3) Main : 클래스 이름 - 첫글자는 대문자로 설정 (4) {...} : 클래스의 내용 (5) 클래스 : 객체의 틀 = (객체를 정의)

(6) 객체 : 하나의 물체처럼 특징와 행동을 가지고 있는 것 (7) 객체의 특징 : 사람이면 MBTI, 키, 몸무게, 성격 등 (8) 객체의 행동 : 먹기, 자기, 공부하기 등

main 메소드

public static void main(String[] args) {...}

(1) public : 접근 제어자 - 접근 권한을 설정 (2) static : 정적 메소드 정의 (3) void : 메소드 출력값 데이터 타입 정의 - 메소드 안에서 밖으로 값을 출력할 때 정의 (4) main : 메소드 이름 - 소문자로만 (5) (String[] args) : 매개변수(input) - 메소드 사용할 때, 메소드 안에 전달할 값이 들어있는 변수로 메소드 안에서만 사용가능

(6) {...} : 메소드 내용 - 보통 동작을 작성

main 메소드 특징

자바 프로젝트(앱)는 제일 먼저 클래스의 main 메소드를 실행시킨다. = JVM의 약속

초기에 항상 드는 의문이 "왜?? 왜 이렇게 해야돼?" 이다. 여기에 대한 답은 "그냥 만든 사람이 그렇게 정했어"이다.

집에서 콩국수를 먹는다고 해보자. 그런데 엄마가 "콩국수에는 소금을 뿌려먹는 거야!" 라고 하면 소금을 뿌려먹어야 한다. 그게 집에서의 약속이자 룰이다.

이처럼 개발도 엄마같은 "사람이 이거는 이렇게 쓰는 거야" 라고 정하기 때문에 그냥 그렇게 하면 된다.

하지만 중요한 것은 왜 그렇게 약속을 정해졌는 지 알아야 한다. 예를 들면, 모든 프로그램의 표준을 제시하기 위해 약속이 정해졌을 수 있기 때문이다. 표준을 지켜야 코드의 유지, 보수가 쉽다.

• 옛날 썰

  처음 C언어를 공부할 때, 항상 마지막에 return 0; 을 붙이라고 배웠다. 근데 나는 항상 궁금했다. "왜 return 0; 을 붙여야 되는거지?" 그 당시, 다들 "나중에 되면 알아. 그냥 외워." 라는 반응이었다. 나는 너무 궁금해서 집요한 서치를 통해서 결국 return 0; 이 부모 프로세스에게 해당 프로그램이 무사히 끝났다고 알려주는 하나의 약속이라는 사실을 알게 되었다. 그러면서 약속의 개념과 프로그램의 동작을 어렴풋이 이해하게 되었다.

제네릭은 자바에서 데이터 타입을 일반화하는 방법으로, 컴파일 시에 타입을 미리 지정하여 타입 안정성을 높이고 불필요한 타입 변환을 줄입니다1. 제네릭의 주요 장점은 다음과 같습니다:

타입 안정성 보장

불필요한 형 변환 제거

코드 재사용성 증가

제네릭 타입은 컴파일 시점, 즉 객체를 선언하고 new로 생성할 때 정해집니다. 제네릭을 사용하지 않으면 타입 안정성이 보장되지 않아 형 변환 오류가 발생할 수 있습니다.

자바의 동시성 문제와 멀티스레드 동시성 문제는 여러 스레드가 동시에 공유 자원에 접근할 때 발생할 수 있는 문제로, 데이터의 일관성을 해칠 수 있습니다4. 이를 해결하기 위한 방법으로는 synchronized 키워드 사용, java.util.concurrent 패키지의 활용, 그리고 락(lock) 메커니즘 등이 있습니다2.

멀티스레드의 과도한 생성은 다음과 같은 문제를 야기할 수 있습니다:

서버 리소스 과다 사용으로 인한 성능 저하

컨텍스트 스위칭 비용 증가

데드락 발생 가능성 증가

동기화와 비동기화 동기화는 작업이 끝날 때까지 기다리는 방식으로 작업의 순서를 보장하며, 비동기화는 작업을 병렬적으로 처리하여 효율성을 높이는 방식입니다3. 자바에서는 CAS(Compare-And-Swap)와 같은 메커니즘을 통해 효율적인 동기화를 구현할 수 있습니다.

캡슐화: 객체 지향 프로그래밍의 핵심 캡슐화는 객체의 상태나 메서드를 하나로 묶어 사용하기 쉽게 만드는 것입니다. 주로 접근 제어자를 통해 구현되며, 데이터 은닉과 보안을 강화합니다. 그러나 코드 복잡성 증가, 성능 저하 가능성, 테스트와 유지보수의 어려움 등의 단점도 있습니다.

Optional: null 처리의 안전성 향상 Optional은 null 처리를 보다 안전하게 할 수 있도록 도와주는 클래스입니다. 사용 시 주의할 점은 다음과 같습니다:

필드로 사용하지 않기

.get() 메소드 사용 자제

Optional을 남용하면 불필요한 객체 생성으로 인한 오버헤드가 발생할 수 있어 성능상 문제가 될 수 있습니다.

결론 자바의 다양한 기능과 개념들은 각각 고유한 장단점을 가지고 있습니다. 제네릭, 멀티스레딩, 동기화 메커니즘, 캡슐화, Optional 등을 적절히 활용하면 타입 안정성, 성능, 코드 품질을 크게 향상시킬 수 있습니다. 그러나 각 기능의 특성과 제약을 잘 이해하고 상황에 맞게 사용하는 것이 중요합니다.

싱글톤 패턴은 객체를 하나만 생성하여 애플리케이션 전체에서 공유할 수 있도록 하는 디자인 패턴입니다.

특징 하나의 인스턴스만 생성됨 전역적으로 접근 가능 메모리 절약 및 데이터 공유 용이

구현 방법 (Lazy Initialization)

public class Singleton {
    private static Singleton instance;

    private Singleton() {} // 외부에서 인스턴스 생성을 막음

    public static Singleton getInstance() {
        if (instance == null) {
            instance = new Singleton();
        }
        return instance;
    }
}

하지만 위 방식은 멀티스레드 환경에서 안전하지 않기 때문에 double-checked locking 또는 static inner class 방식을 추천합니다.

static inner class 방식 (권장됨)

public class Singleton {
    private Singleton() {}

    private static class Holder {
        private static final Singleton INSTANCE = new Singleton();
    }

    public static Singleton getInstance() {
        return Holder.INSTANCE;
    }
}

이 방식은 클래스가 로드될 때 인스턴스가 생성되지 않고, 최초 getInstance() 호출 시 생성되므로 효율적이며 스레드 안전합니다.

2. JVM (Java Virtual Machine)

JVM(Java Virtual Machine)은 자바 바이트코드를 실행하는 가상 머신입니다.

JVM의 역할

바이트코드 실행 → 자바 프로그램을 운영체제와 관계없이 실행 가능 메모리 관리 → GC(Garbage Collection)를 통해 자동으로 메모리 관리 플랫폼 독립성 제공 → Write Once, Run Anywhere

JVM의 구성 요소

클래스 로더(Class Loader): .class 파일을 로드하고 메모리에 적재 메모리 영역 (Runtime Data Area): JVM이 관리하는 메모리 공간 실행 엔진(Execution Engine): 바이트코드를 기계어로 변환하여 실행 GC(Garbage Collector): 불필요한 객체를 정리

3. 자바 메모리 영역

JVM의 메모리 영역은 다음과 같이 구성됩니다.

1) 메서드 영역(Method Area, 클래스 영역)

클래스 정보, static 변수, 상수, 메서드 코드가 저장됨 프로그램이 종료될 때까지 유지됨

2) 힙(Heap)

객체(instance)들이 저장되는 공간 GC(Garbage Collector)가 관리

3) 스택(Stack)

메서드 호출 시 지역 변수, 매개변수, 리턴값 저장 메서드 실행이 끝나면 제거됨 (LIFO 방식)

4) PC 레지스터(Program Counter Register)

현재 실행 중인 JVM 명령어의 주소를 저장

5) 네이티브 메서드 스택(Native Method Stack)

JNI(Java Native Interface)를 통해 호출된 네이티브 코드(C, C++)의 정보 저장

4. 오버로딩(Overloading)과 오버라이딩(Overriding) 차이

구분 오버로딩 (Overloading) 오버라이딩 (Overriding) 의미 같은 이름의 메서드를 여러 개 정의 상속받은 메서드를 재정의 클래스 관계 같은 클래스 내에서 발생 부모 클래스의 메서드를 자식 클래스에서 재정의 매개변수 개수, 타입, 순서를 다르게 정의 동일해야 함 반환 타입 달라도 가능 동일해야 함 접근 제한자 제한 없음 부모보다 좁아질 수 없음 애너테이션 없음 @Override 사용

오버로딩 예제

class MathUtils {
    int add(int a, int b) {
        return a + b;
    }

    double add(double a, double b) { // 매개변수 타입이 다름
        return a + b;
    }
}

오버라이딩 예제

class Parent {
    void showMessage() {
        System.out.println("부모 클래스");
    }
}

class Child extends Parent {
    @Override
    void showMessage() { // 부모 메서드 재정의
        System.out.println("자식 클래스");
    }
}

5. 클래스(Class), 객체(Object), 인스턴스(Instance) 차이

클래스(Class): 객체를 만들기 위한 설계도 객체(Object): 클래스에서 생성된 실제 대상 인스턴스(Instance): 객체가 메모리에 할당된 상태

예제

class Car {  // 클래스
    String model;
}

public class Main {
    public static void main(String[] args) {
        Car myCar = new Car(); // 객체 생성 (인스턴스)
    }
}

Car는 클래스 myCar는 객체이자 인스턴스 즉, "인스턴스는 객체의 특정한 상태를 나타내는 개념"이라고 볼 수 있습니다.

6. 원시 타입(Primitive Type)과 참조 타입(Reference Type) 차이

구분 원시 타입 (Primitive Type) 참조 타입 (Reference Type) 데이터 저장 방식 값 자체를 저장 객체의 주소(참조값)를 저장 메모리 위치 스택(Stack) 힙(Heap) 크기 고정적 가변적 기본 값 int → 0, boolean → false null 비교 방식 값 자체 비교 (==) 주소 비교 (==), 내용 비교 (equals())

원시 타입 예제

int a = 10;
int b = a; // 값이 복사됨
b = 20;
System.out.println(a); // 10 (a의 값은 변하지 않음)

참조 타입 예제

class Person {
    String name;
}

Person p1 = new Person();
p1.name = "Alice";

Person p2 = p1; // 주소가 복사됨
p2.name = "Bob";

System.out.println(p1.name); // "Bob" (같은 객체를 참조하므로 값이 변경됨) 참조 타입은 같은 객체를 가리키므로 p1과 p2가 같은 데이터를 공유합니다.

기존 DB 기반 방식

초기 구현에서는 데이터베이스에서 직접 쿼리를 수행하여 "실시간 웨이팅 순서"를 계산했습니다.

예를 들어, 아래와 같이 특정 가게와 날짜, 그리고 본인의 웨이팅 번호보다 앞에 있는 대기 중인 팀의 수를 DB에서 직접 카운트하는 방식입니다.

/**
 * 실시간 웨이팅 순서 조회 메서드
 *
 * @param waitingId
 * @return WaitingNowSeqNumberResponseDto
 */
public WaitingNumberResponseDto getNowSeqNumber(Long waitingId) {

    Waiting waiting = waitingRepository.findByIdOrElseThrow(waitingId);

    // 웨이팅 날짜만 가져오기
    LocalDate waitingDate = waiting.getCreatedAt().toLocalDate();

    // 앞에 대기중인 웨이팅 개수 가져오기
    int nowSeqNum = waitingRepository.countByStoreAndWaitingStatusAndCreatedAtBetweenAndWaitingNumberLessThanEqual(
            waiting.getStore(),
            WaitingStatus.PENDING,
            waitingDate.atTime(0, 0, 0), waitingDate.atTime(23, 59, 59),
            waiting.getWaitingNumber()
    );

    return new WaitingNumberResponseDto(nowSeqNum);
}

문제점:

• DB 부하 증가: 실시간으로 사용자의 순서를 확인할 때마다 복잡한 조건을 가진 쿼리를 실행하기 때문에, 사용자가 많아질 경우 DB에 큰 부하가 발생합니다.
• 성능 이슈: 매번 DB를 조회함으로써 응답 속도가 느려질 수 있으며, 동시 요청이 많은 경우 트래픽 폭주 상황에서 병목 현상이 발생할 수 있습니다.

2. Redis 기반 개선 방식

Redis와 Redisson을 활용한 설계

Redis를 활용하면 메모리 기반 데이터 저장소의 장점을 살려 실시간 조회 및 업데이트를 빠르게 처리할 수 있습니다. Redisson 라이브러리를 이용하여 Java 애플리케이션에서 Redis의 자료구조(특히, 정렬된 집합)를 효과적으로 사용할 수 있도록 구현했습니다.

주요 개선 포인트

• 빠른 읽기/쓰기: Redis는 메모리 내 데이터 처리를 통해 낮은 지연 시간으로 실시간 순서 조회에 적합합니다.
• TTL (Time-To-Live) 설정: 대기열에 TTL을 설정하여 일정 시간이 지난 데이터는 자동으로 삭제되도록 함으로써, 메모리 낭비를 줄이고 데이터의 신선도를 유지합니다.
• 정렬된 집합 사용: RScoredSortedSet을 이용해 대기열에 등록된 웨이팅 항목을 정렬된 형태로 관리하고, 이를 통해 순위(rank)를 효율적으로 계산할 수 있습니다.

3. 코드 상세 분석

3.1. 웨이팅 큐에 등록하는 메서드: addToWaitingQueue

public void addToWaitingQueue(Waiting waiting) {
    String key = "waiting:store:" + waiting.getWaitingType().name() + ":" + waiting.getStore().getStoreId();
    RScoredSortedSet<Long> waitingQueue = redissonClient.getScoredSortedSet(key);

    // 웨이팅 번호를 score 로 추가 (혹시라도 있을 중복을 위해 날짜로 번호 구분)
    waitingQueue.add(LocalDate.now().getDayOfYear() * 1000000L + waiting.getWaitingNumber(), waiting.getWaitingId());

    // TTL 설정 (6시간 후 자동 삭제)
    waitingQueue.expire(Duration.ofHours(6));
}

설명:

• Key 구성: 대기열 키는 waiting:store:[웨이팅타입]:[가게ID] 형식으로 생성하여, 가게와 웨이팅 타입에 따라 분리된 저장소를 사용합니다.
• Score 계산: score는 오늘 날짜의 일자(예, dayOfYear)에 대기 번호를 곱하여 생성합니다. 이 방식은 동일한 번호가 중복 등록되는 상황을 방지하고, 정렬 기준으로 활용됩니다.
• TTL 설정: 해당 대기열은 6시간 후 자동으로 삭제되도록 설정하여 오래된 데이터가 남지 않도록 관리합니다.

3.2. 현재 순서를 조회하는 메서드: getNowSeqNumber

public Integer getNowSeqNumber(Waiting waiting) {
    String key = "waiting:store:" + waiting.getWaitingType() + ":" + waiting.getStore().getStoreId();
    RScoredSortedSet<Long> waitingQueue = redissonClient.getScoredSortedSet(key);

    // 현재 웨이팅의 번호 조회
    Integer rank = waitingQueue.rank(waiting.getWaitingId());
    if (rank == null) {
        return 0;
    }
    // 0-indexed 이므로 1을 더해 실제 순서 계산
    return rank + 1;
}

설명:

• 순위 계산: rank() 메서드는 해당 웨이팅 ID가 정렬된 집합 내에서 몇 번째에 위치하는지를 0부터 계산합니다. 따라서 사용자에게 보여줄 순서는 rank + 1이 됩니다.
• 결과 반환: 만약 해당 대기 항목이 존재하지 않는다면 0을 반환하여 예외 상황을 처리합니다.

3.3. 대기열에서 제거하는 메서드: removeFromWaitingQueue

public void removeFromWaitingQueue(Waiting waiting) {
    String key = "waiting:store:" + waiting.getWaitingType() + ":" + waiting.getStore().getStoreId();
    RScoredSortedSet<Long> waitingQueue = redissonClient.getScoredSortedSet(key);

    // Redis 의 대기열에서 해당 웨이팅 ID 제거
    waitingQueue.remove(waiting.getWaitingId());
}

설명:

• 해당 웨이팅 항목이 처리되었거나 취소되었을 경우, Redis 대기열에서 제거하여 실시간 순위 계산에서 제외합니다.

3.4. 남은 팀 수 저장 메서드: saveWaitingLeft

public void saveWaitingLeft(Waiting waiting) {
    String key = "waiting:store:" + waiting.getStore().getStoreId() + ":" + waiting.getWaitingType() + ":left";
    RMap<Long, Integer> waitingLeftMap = redissonClient.getMap(key);

    Integer leftNow = getNowSeqNumber(waiting);
    waitingLeftMap.put(waiting.getWaitingNumber(), leftNow);
}

설명:

• Map 사용: 특정 가게와 웨이팅 타입에 대한 남은 대기 팀 수를 별도의 Redis Map에 저장합니다.
• 저장 방식: 웨이팅 번호를 key로, 현재 순위를 value로 저장하여 나중에 통계나 모니터링 용도로 활용할 수 있습니다.

3.5. 대기 소요 시간 관련 메서드

3.5.1. 1팀 당 소요 시간 저장: saveTakenTimeWaiting

public void saveTakenTimeWaiting(Long waitingId) {
    Waiting waiting = waitingRepository.findByIdOrElseThrow(waitingId);
    Integer takenTime = (int) Duration.between(waiting.getCreatedAt(), waiting.getModifiedAt()).toMinutes(); // 등록 - 입장 소요시간

    String key = "waiting:store:" + waiting.getStore().getStoreId() + ":" + waiting.getWaitingType() + ":time";
    RScoredSortedSet<Long> timeQueue = redissonClient.getScoredSortedSet(key);

    String leftKey = "waiting:store:" + waiting.getStore().getStoreId() + ":" + waiting.getWaitingType() + ":left";
    RMap<Long, Long> waitingLeftMap = redissonClient.getMap(leftKey);

    Long left = waitingLeftMap.get(waiting.getWaitingId());
    timeQueue.add((int) (takenTime / left), waiting.getWaitingId()); // 1팀 당 소요시간 저장

    // 데이터 수가 많아지면 오래된 데이터 제거
    if (timeQueue.size() > 150) {
        timeQueue.remove(0);
    }
}

설명:

• 소요 시간 계산: 등록 시각과 입장 시각의 차이를 계산하여, 전체 소요 시간을 구합니다.
• 평균 계산: 전체 소요 시간을 현재 대기 팀 수(저장된 left 값)로 나누어 1팀 당 소요 시간을 구합니다.
• 데이터 관리: 일정 크기(150개)를 초과하면 오래된 데이터를 제거하여 메모리 사용량을 관리합니다.

3.5.2. 소요 시간 삭제: deleteTakenTimeWaiting

public void deleteTakenTimeWaiting(Waiting waiting) {
    String key = "waiting:store:" + waiting.getStore().getStoreId() + ":" + waiting.getWaitingType() + ":time";
    RScoredSortedSet<Long> timeQueue = redissonClient.getScoredSortedSet(key);

    timeQueue.remove(waiting.getWaitingId());
}

설명:

• 처리된 웨이팅 항목의 소요 시간 데이터를 정리하기 위한 메서드입니다.

3.5.3. 예상 대기 시간 조회: getTakenTimeWaiting

public Integer getTakenTimeWaiting(Waiting waiting) {
    String key = "waiting:store:" + waiting.getStore().getStoreId() + ":" + waiting.getWaitingType() + ":time";
    RScoredSortedSet<Long> timeQueue = redissonClient.getScoredSortedSet(key);

    long leftNow = getNowSeqNumber(waiting);
    int sum = 0;
    int time;

    if (timeQueue.size() < 10) {
        time = 15; // 데이터가 충분하지 않을 경우 기본값 15분
    } else {
        for (Long num : timeQueue) {
            sum += num.intValue();
        }
        time = sum / timeQueue.size();
    }
    return time * (int) leftNow;
}

설명:

• 데이터 안정성: 데이터 포인트가 충분하지 않은 경우 기본값(15분)을 적용합니다.
• 평균 소요 시간: 저장된 각 웨이팅 항목의 1팀 당 소요 시간을 평균내어, 이를 현재 대기 팀 수와 곱해 전체 예상 대기 시간을 산출합니다.

3.6. 최종 결과 통합: getNowSequenceAndTime

public WaitingSequenceDto getNowSequenceAndTime(Long waitingId) {
    Waiting waiting = waitingRepository.findByIdOrElseThrow(waitingId);

    // 현재 나의 순서 조회
    Integer nowSeqNumber = getNowSeqNumber(waiting);

    // 예상 대기 시간 조회
    Integer waitingTime = getTakenTimeWaiting(waiting);

    return new WaitingSequenceDto(nowSeqNumber, waitingTime);
}

설명:

• DB에서 웨이팅 정보를 불러온 후, Redis에 저장된 데이터(순서 및 소요 시간)를 활용하여 사용자에게 실시간 순서와 예상 대기 시간을 함께 제공합니다.
• 이로써 DB 부하를 최소화하면서도, 사용자에게 빠르고 정확한 정보를 제공할 수 있습니다.

4. 전체 코드 동작 흐름

1. 등록 시 처리:
   • 사용자가 웨이팅에 등록하면 addToWaitingQueue를 호출하여 Redis의 정렬된 집합에 등록합니다.
   • 동시에 현재 남은 팀 수를 saveWaitingLeft 메서드로 Redis Map에 저장합니다.
2. 순서 및 예상 대기 시간 조회:
   • 사용자가 자신의 순서와 예상 대기 시간을 조회할 때 getNowSequenceAndTime 메서드를 호출합니다.
   • 내부적으로 getNowSeqNumber로 현재 순위를, getTakenTimeWaiting으로 대기 시간을 계산합니다.
3. 완료/취소 시 처리:
   • 웨이팅이 완료되거나 취소되면, removeFromWaitingQueue와 deleteTakenTimeWaiting을 통해 관련 데이터를 Redis에서 정리합니다.

5. 결론

Redis를 활용한 이번 개선 방식은 다음과 같은 장점을 제공합니다.

• 실시간 응답 속도 개선: 메모리 기반의 정렬된 집합을 사용하여, 사용자에게 빠른 순서 계산 및 예상 대기 시간 제공이 가능해졌습니다.
• DB 부하 완화: DB 대신 Redis를 통해 많은 계산 및 조회 작업을 처리함으로써, DB 서버의 부하를 크게 줄일 수 있습니다.
• 데이터 관리: TTL, 데이터 수 제한 등의 전략을 통해 Redis 메모리 사용을 효율적으로 관리합니다.

이와 같이 Redis 기반의 대기열 관리 방식을 활용하면, 대규모 사용자가 동시에 접근하는 상황에서도 안정적이고 빠른 실시간 정보 제공이 가능해집니다.

1. 배경

데이터 수가 증가함에 따라 현재 Store 엔티티와 연관된 검색 기능에서 성능 문제가 발생하고 있습니다.

2. 문제

searchStoreQuery 메서드에서 다수의 조인과 조건 필터링이 이루어지며 응답 속도가 저하됩니다. 이로 인해 사용자가 검색 결과를 확인하는 데 시간이 오래 걸리고, 서버의 리소스 사용량이 증가하는 문제가 발생합니다.

2.1 원인

• 조건 검색의 비효율성: BooleanExpression을 이용한 필터링에서 인덱스 활용 부족
• 반복적인 DB 접근: Redis 캐싱 미적용으로 인해 동일한 검색이 반복적으로 DB에 접근
• Lazy Loading으로 인한 N+1 문제 가능성
• 복잡한 검색 필터링 로직: 최적화가 필요

3. 성능 개선 방법

3.0 데이터 준비

• store 더미 데이터 50만 개 생성
  • net.datafaker.Faker를 사용하여 랜덤 데이터를 생성하고, 이를 DB에 저장합니다.

package com.gotcha.earlytable.domain.store;

import com.gotcha.earlytable.domain.file.FileService;
import com.gotcha.earlytable.domain.store.entity.Store;
import com.gotcha.earlytable.domain.store.enums.StoreCategory;
import com.gotcha.earlytable.domain.store.enums.StoreStatus;
import com.gotcha.earlytable.domain.user.UserRepository;
import com.gotcha.earlytable.domain.user.entity.User;
import com.gotcha.earlytable.global.enums.RegionBottom;
import com.gotcha.earlytable.global.enums.RegionTop;
import jakarta.annotation.PostConstruct;
import lombok.RequiredArgsConstructor;
import org.springframework.stereotype.Component;
import org.springframework.transaction.annotation.Transactional;
import net.datafaker.Faker;

import java.util.ArrayList;
import java.util.List;
import java.util.Locale;
import java.util.Random;

@Component
@RequiredArgsConstructor
public class StoreDummyDataInitializer {

    private final StoreRepository storeRepository;
    private final UserRepository userRepository;
    private final FileService fileService;

    private final Random random = new Random();
    private final Faker faker = new Faker(Locale.KOREAN);

    private static final int STORE_COUNT = 500_000;

    @PostConstruct
    @Transactional
    public void init() {
        List<User> users = userRepository.findAll();

        if (users.isEmpty()) {
            throw new IllegalStateException("User가 존재하지 않습니다.");
        }

        List<Store> stores = new ArrayList<>();

        for (int i = 0; i < STORE_COUNT; i++) {
            stores.add(createRandomStore(users));

            if (i % 10_000 == 0) { // 10,000개씩 배치 저장
                storeRepository.saveAll(stores);
                stores.clear();
                System.out.println(i + " 개의 데이터를 저장 완료...");
            }
        }

        if (!stores.isEmpty()) {
            storeRepository.saveAll(stores);
        }

        System.out.println("총 " + STORE_COUNT + " 개의 더미 데이터 저장 완료!");
    }

    private Store createRandomStore(List<User> users) {
        return new Store(
                faker.company().name(), // 랜덤 상점명
                faker.phoneNumber().phoneNumber(), // 랜덤 전화번호
                faker.lorem().sentence(), // 랜덤 설명
                faker.address().fullAddress(), // 랜덤 주소
                randomEnum(StoreStatus.class), // 랜덤 StoreStatus
                randomEnum(StoreCategory.class), // 랜덤 StoreCategory
                randomEnum(RegionTop.class), // 랜덤 RegionTop
                randomEnum(RegionBottom.class), // 랜덤 RegionBottom
                getRandomElement(users), // 랜덤 User
                fileService.createFile() // New File
        );
    }

    private <T extends Enum<?>> T randomEnum(Class<T> enumClass) {
        T[] enumConstants = enumClass.getEnumConstants();
        return enumConstants[random.nextInt(enumConstants.length)];
    }

    private <T> T getRandomElement(List<T> list) {
        return list.get(random.nextInt(list.size()));
    }
}

• build.gradle에 의존성 추가

implementation 'net.datafaker:datafaker:2.0.2'

• 더미 데이터 예시

3.1 인덱스 최적화

현재 storeName, regionTop, regionBottom, storeCategory 등에 대해 적절한 인덱스가 없어 DB에서 검색하는 데 시간이 오래 걸립니다.

해결 방법

아래와 같이 인덱스를 추가하여 검색 성능을 개선할 수 있습니다

@Entity
@Table(name = "store", indexes = {
@Index(name = "idx_store_name", columnList = "storeName"),
@Index(name = "idx_region_top", columnList = "regionTop"),
@Index(name = "idx_region_bottom", columnList = "regionBottom"),
@Index(name = "idx_store_category", columnList = "storeCategory")
})
public class Store extends BaseEntity {

    // ...이하 생략

}

• 기본 키와 외래 키는 이미 데이터베이스에서 자동으로 인덱스를 생성함

  • JPA에서는 @Id(storeId) 와 @manyToOne(UserId), @OneToOne(fileId) 관계의 필드를 인덱스로 자동 생성

• 조건 중 검색어는 가게 이름과 대표 메뉴 이름을 LIKE 조건으로 검색하기 때문에 “%검색어” 나 “%검색어%” 처럼 정렬이 무의미한 경우는 인덱스가 의미가 없음 → 실제로 시간이 더 오래 걸림(인덱스 수정)
• 조건 중 가격은 자주 변경될 가능성이 높고, BETWEEN 조건이라 성능 개선이 크게 이루어지지 않을 가능성이 높음

적용 전/후 성능 비교

• 인덱스 적용 전

  

• 인덱스 적용 후

  

결과

전체적으로 성능이 개선되긴 했지만 큰 지역(31,813개)과 카테고리(85,001개)처럼 많은 양의 데이터를 가져오는 상황에서는 크게 유의미한 결과를 보여주진 못하고, 작은 지역과 작은 지역(2,259개) + 카테고리(5,303개) 10% 이하의 데이터를 가져올 때는 큰 성능 향상이 있었습니다.

3.2 Redis 캐싱 적용

동일한 검색이 반복적으로 발생할 경우, 캐싱이 없으면 매번 DB에서 조회해야하는 문제가 있습니다.

해결 방법

동일한 검색이 반복적으로 발생할 경우, DB에서 매번 조회하는 대신 Redis를 이용해 캐싱함으로써 성능을 개선할 수 있습니다.

/**
     * 가게 조건 검색 메서드
     *
     * @param requestDto
     * @return
     */
    public List<StoreSearchResponseDto> searchStore(StoreSearchRequestDto requestDto) {
        String cacheKey = "store_search:" + getCacheKey(requestDto);

        // RBucket을 JsonJacksonCodec과 함께 사용
        RBucket<String> cachedResult = redissonClient.getBucket(cacheKey, JsonJacksonCodec.INSTANCE);

        Instant start = Instant.now(); // 시작 시간 기록

        // 캐시된 결과가 있으면 반환
        String resultJson = cachedResult.get();
        List<StoreSearchResponseDto> result = null;
        if (resultJson != null && !resultJson.isEmpty()) {
            try {
                result = objectMapper.readValue(resultJson, objectMapper.getTypeFactory().constructCollectionType(List.class, StoreSearchResponseDto.class));
            } catch (Exception e) {
                log.error("Error deserializing cached result", e);
            }
        }

        if (result == null || result.isEmpty()) {
            // 캐시된 결과가 없으면 DB에서 조회 후 캐시에 저장
            result = storeRepository.searchStoreQuery(requestDto);

            try {
                String resultJsonToCache = objectMapper.writeValueAsString(result); // List to JSON
                cachedResult.set(resultJsonToCache, 10, TimeUnit.MINUTES); // 캐시 만료 시간은 10분으로 설정
            } catch (Exception e) {
                log.error("Error serializing result to cache", e);
            }
        }

        Instant end = Instant.now(); // 종료 시간 기록
        long elapsedTime = Duration.between(start, end).toMillis(); // 실행 시간(ms)

        log.info("searchStoreQuery 실행 시간: {} ms, 결과 개수: {}", elapsedTime, result.size());

        return result;
    }

    // 캐시 키를 위한 핵심 파라미터들만 조합하는 메소드
    private String getCacheKey(StoreSearchRequestDto requestDto) {
        return requestDto.getSearchWord() + ":" +
                requestDto.getRegionTop() + ":" +
                requestDto.getRegionBottom() + ":" +
                requestDto.getStoreCategory();
    }

• 적용 전

  • 테스트 1

    

    ![](https://velog.velcdn.com/images/take_the_king/post/6a23e3c5-d1ed-4845-93fb-21cccb90359a/image.png)


- 테스트 2

    ![](https://velog.velcdn.com/images/take_the_king/post/6c7da1b5-56d0-4dee-9092-5c60c405f43b/image.png)


    ![](https://velog.velcdn.com/images/take_the_king/post/d6b82e5e-d348-4819-8449-7910a38a4287/image.png)

• 적용 후

  • 테스트 1 - 캐싱 후

    

- 테스트 2 - 캐싱 후

    ![](https://velog.velcdn.com/images/take_the_king/post/ecf41371-32f8-4272-8509-229b4252cfc7/image.png)

결과

데이터를 캐싱한 결과 평균 95% 이상의 성능 개선이 이루어졌습니다. 자주 조회되는 조건들에 경우에는 아주 효과적인 개선 방법이 될 수 있습니다. 하지만 캐시 적중률이 높지 않다면 결국에는 DB 조회가 일어날 것입니다.

또한, 모든 조회들을 캐싱에 담아두고 긴 시간동안 보관하면 메모리 부하가 발생할 것입니다. 그렇기 때문에 적절한 만료시간과 자주 조회되는 컬럼을 적용시키면 아주 효과적인 성능 개선이 이루어질 것입니다.

주의사항

• 변경 빈도 고려: 만약 가게 데이터가 자주 변경된다면, 캐시에 저장된 데이터와 DB의 데이터 간에 불일치(데이터 정합성 문제)가 발생할 수 있습니다. 이런 경우 캐시를 자주 무효화하거나 업데이트해야 하므로, 캐시 업데이트 작업이 빈번해져 오히려 Redis에 부하를 줄 수 있습니다.
• 캐시 적중률 고려: 캐시 적중률이 높다면 대부분의 요청이 Redis에서 처리되어 DB 부하가 줄어들지만, 캐시 적중률이 낮으면 DB 조회가 빈번하게 발생합니다. 특히 캐시 미스가 잦은 경우, Redis와 DB 간의 네트워크 트래픽이 증가할 수 있습니다.

3.3 N + 1 문제 해결

@OneToMany(fetch = FetchType.LAZY) 관계에서 N+1 문제가 발생할 가능성이 있습니다.

해결 방법 1(Hibernate Batch Size 조정)

@BatchSize(size = 100)를 사용하여 성능을 개선할 수 있습니다.

• store 엔티티

@Entity
@Table(name = "store", indexes = {
@Index(name = "idx_store_name", columnList = "storeName"),
@Index(name = "idx_region_top", columnList = "regionTop"),
@Index(name = "idx_region_bottom", columnList = "regionBottom"),
@Index(name = "idx_store_category", columnList = "storeCategory")
})
public class Store extends BaseEntity {

    // ...

    @OneToOne(fetch = FetchType.LAZY)
  @JoinColumn(name = "file_id", nullable = false)
  private File file;

    @BatchSize(size = 100)
  @OneToMany(mappedBy = "store", cascade = CascadeType.ALL, orphanRemoval = true, fetch = FetchType.LAZY)
  private final List<Menu> menuList = new ArrayList<>();

    @BatchSize(size = 100)
  @OneToMany(mappedBy = "store", cascade = CascadeType.ALL, orphanRemoval = true, fetch = FetchType.LAZY)
  private final List<Review> reviewList = new ArrayList<>();
}

• file 엔티티

@Getter
@Entity
@Table(name = "file")
@BatchSize(size = 100)
public class File extends BaseEntity {

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

    @BatchSize(size = 100)
    @OneToMany(mappedBy = "file", cascade = CascadeType.ALL, orphanRemoval = true)
    private List<FileDetail> fileDetailList = new ArrayList<>();

    public File() {

    }

}

결과

이처럼 수십 번 발생할 쿼리를 몇 번의 쿼리로 데이터를 가져오게 됩니다.

실제로 76번의 쿼리가 4개의 쿼리로 줄어들었습니다.

또한 실행 시간도 약간이지만 단축되는 효과가 있었습니다.

이것은 batchsize를 적용하기 전의 실행 시간이다. batchsize를 적용 후 3% 정도 단축되었습니다.

추가 조회 실행 후에도

• batchsize 적용 전 (2차)

• batchsize 적용 후 (2차)

약 10% 정도 단축되는 것을 볼 수 있습니다.

이를 통해 batchsize를 알맞은 상황에 적용하면 쿼리도 최적화를 하고 성능도 개선할 수 있다는 것을 알 수 있습니다.

해결 방법 2(fetchType 설정)

가게를 조회할 때 항상 사용되는 필드는 조인해서 하나의 쿼리에서 데이터를 가져오도록 설정합니다.

결과

왼쪽은 fetchType 이 Lazy 일 때 쿼리가 3번 발생하는 상황이고, fetchType 을 Eager로 설정해서 1번의 쿼리만 발생하는 상황입니다. 항상 같이 조회되는 데이터의 경우는 조인을 통해 같이 가져오는 방법이 성능 개선이 도움을 줄 수 있습니다.

4. 결론

• 인덱스 최적화, 데이터 캐싱, N+1 문제 해결을 통해 성능 개선을 이룰 수 있었습니다.
• 특히 인덱스 최적화와 Redis 캐싱이 성능 향상에 중요한 역할을 했습니다.
• 이러한 최적화 방법들은 각 상황에 맞게 사용하면, 시스템 성능을 크게 개선할 수 있습니다.

5. 추후 고려 사항

5.1 Elasticsearch 도입 고려

검색 성능을 더욱 향상하기 위해 Elasticsearch 도입을 고려.

• 빠른 텍스트 검색 가능
• 복합적인 필터링 및 랭킹 기능 제공

5.2 인덱스 추가

검색 성능을 위해 더 다양한 인덱스 추가 고려

• 알러지에 대한 인덱스 추가
• 복합 인덱스 추가

SSE (Server-Sent Events)를 React 애플리케이션에 적용하면서 발생한 문제들과 해결 방법을 정리

🚨 1. 로그인/회원가입 페이지에서도 SSE가 실행되는 문제

🔍 문제 원인

• SSE를 알림기능에 사용하기 위해 전역 페이지에 적용함.
• SSEProvider가 App.js의 Router 전체를 감싸고 있어 로그인/회원가입 페이지에서도 SSE가 실행됨.
• 로그인하지 않은 사용자에게는 불필요한 SSE 연결이 발생함.

💡 해결 방법

✅ 로그인 및 회원가입 페이지는 SSEProvider에서 제외하고, 인증된 페이지에만 적용

<Router>
  <Routes>
    {/* ✅ 로그인 & 회원가입에서는 SSEProvider 제외 */}
    <Route path="/register" element={<Register />} />
    <Route path="/login" element={<Login />} />

    {/* ✅ 나머지 페이지에서는 SSEProvider 적용 */}
    <Route
      path="/*"
      element={
        <SSEProvider>
          <Routes>
            <Route path="/" element={<Home />} />
            <Route path="/store/:storeId" element={<StoreDetails />} />
            {/* ...생략 */}
          </Routes>
        </SSEProvider>
      }
    />
  </Routes>
</Router

🚨 2. 중복 SSE 연결이 발생하는 문제

🔍 문제 원인

• SSEProvider의 useEffect가 여러 번 실행되어 기존 SSE 연결을 닫지 않은 채 새로운 연결이 계속 생성됨.
• 페이지 이동 시 기존 SSE 연결이 유지되지 않고 새로운 연결이 생성되어 중복 발생.

💡 해결 방법

✅ eventSourceRef를 useRef로 관리하여 중복 연결 방지

✅ 기존 SSE 연결이 있으면 새 연결을 생성하지 않도록 조건 추가

onst eventSourceRef = useRef(null);

const connectSSE = () => {
  if (eventSourceRef.current) {
    console.log("⚠️ 기존 SSE 연결 존재, 중복 연결 방지");
    return;
  }

  eventSourceRef.current = new EventSourcePolyfill(
    "http://localhost:8080/notifications/subscribe",
    {
      headers: { Authorization: `Bearer ${localStorage.getItem("accessToken")}` },
      withCredentials: true,
    }
  );

  eventSourceRef.current.onopen = () => {
    console.log("✅ SSE 연결 성공");
  };

  eventSourceRef.current.onerror = () => {
    console.error("❌ SSE 연결 오류 발생, 재연결 시도...");
    eventSourceRef.current?.close();
    eventSourceRef.current = null;
    setTimeout(connectSSE, 3000); // 3초 후 재연결
  };
};

useEffect(() => {
  connectSSE();

  return () => {
    console.log("🛑 SSE 연결 해제");
    eventSourceRef.current?.close();
    eventSourceRef.current = null;
  };
}, []);

✅ 이제 페이지 이동 시에도 기존 SSE가 유지되며, 중복 연결이 방지됨!

🚨 3. SSE 연결 끊김 시 자동 재연결되지 않는 문제

🔍 문제 원인

• SSE 연결이 끊기면 새로운 연결을 시도하지 않고 종료됨.
• 브라우저의 자동 재연결 기능이 동작하지 않는 경우가 발생함.

💡 해결 방법

✅ SSE 에러 발생 시 자동 재연결 로직 구현

✅ 최대 3회까지 재연결을 시도하고, 실패 시 토큰 갱신 후 재시도

const retryCountRef = useRef(0);

const connectSSE = () => {
  if (eventSourceRef.current) {
    console.log("⚠️ 기존 SSE 연결 존재, 중복 연결 방지");
    return;
  }

  eventSourceRef.current = new EventSourcePolyfill(
    "http://localhost:8080/notifications/subscribe",
    {
      headers: { Authorization: `Bearer ${localStorage.getItem("accessToken")}` },
      withCredentials: true,
    }
  );

  eventSourceRef.current.onopen = () => {
    console.log("✅ SSE 연결 성공");
    retryCountRef.current = 0; // 재연결 카운트 초기화
  };

  eventSourceRef.current.onerror = async (error) => {
    console.error("❌ SSE 연결 오류 발생:", error);
    eventSourceRef.current?.close();
    eventSourceRef.current = null;

    if (retryCountRef.current >= 3) {
      console.warn("🚨 SSE 재연결 3회 실패, 토큰 갱신 후 재시도");
      const success = await getRefreshToken();
      if (success) connectSSE();
    } else {
      setTimeout(() => {
        retryCountRef.current += 1;
        console.log(`🔄 SSE 재연결 (${retryCountRef.current}번째 시도)`);
        connectSSE();
      }, 3000);
    }
  };
};

✅ 이제 SSE 연결이 끊겨도 자동으로 재연결됨!

🚨 4. 액세스 토큰 만료 시 401 오류가 반복되는 문제

🔍 문제 원인

• 액세스 토큰 만료 시 새로운 토큰을 받아오지 못해 SSE 연결이 실패함.
• SSE 요청 시 만료된 액세스 토큰을 계속 사용하여 401 에러가 반복됨.

💡 해결 방법

✅ 401 오류 발생 시 자동으로 리프레시 토큰을 요청하고, 성공하면 SSE 재연결

✅ 토큰 갱신 요청의 중복 실행을 방지하도록 isRefreshingRef 활용

const isRefreshingRef = useRef(false);

const getRefreshToken = async () => {
  if (isRefreshingRef.current) return false;
  isRefreshingRef.current = true;

  try {
    console.log("🔄 토큰 갱신 시도...");
    const response = await instance.post("/users/refresh", {}, {
      headers: { "Content-Type": "application/json" },
      withCredentials: true,
    });

    const newAccessToken = response.data.accessToken;
    if (!newAccessToken) throw new Error("새로운 토큰 없음");

    localStorage.setItem("accessToken", newAccessToken);
    console.log("✅ 토큰 갱신 성공");
    return true;
  } catch (err) {
    console.error("❌ 토큰 갱신 실패, 로그인 페이지로 이동");
    navigate("/login");
    return false;
  } finally {
    isRefreshingRef.current = false;
  }
};

eventSourceRef.current.onerror = async (error) => {
  console.error("❌ SSE 연결 오류 발생:", error);
  eventSourceRef.current?.close();
  eventSourceRef.current = null;

  if (error.status === 401) {
    const success = await getRefreshToken();
    if (success) {
      console.log("🔄 SSE 재연결 시도...");
      connectSSE();
    }
  } else {
    setTimeout(() => {
      console.log("🔄 SSE 자동 재연결...");
      connectSSE();
    }, 3000);
  }
};

✅ 이제 토큰이 만료되어도 자동으로 갱신되고 SSE가 재연결됨!

🎯 정리

초기에는 엑세스토큰만을 사용하여 로그인을 관리했는데, 엑세스토큰의 만료 시간이 짧아 사용자가 자주 로그인을 다시 해야 하는 불편함이 발생했습니다.

즉, 사용자가 로그인한 후에도 짧은 시간마다 토큰 만료로 인해 인증이 끊기고, 다시 로그인을 해야 하는 상황이 문제였습니다.

2. 원인

• 엑세스토큰 만료 시간

  엑세스토큰은 보통 보안상의 이유로 만료 시간이 짧게 설정됩니다. 이로 인해, 사용자가 서비스를 이용하는 도중에 토큰이 만료되면 인증 상태가 풀려 다시 로그인을 요구하게 됩니다.

• 엑세스토큰 단독 관리

  기존에는 엑세스토큰만 관리하다 보니, 토큰 갱신 로직이 없어서 만료되면 새 토큰을 발급받지 못하고 로그인이 끊기는 문제가 발생했습니다.

3. 해결책

해결책으로는 리프레쉬 토큰(Refresh Token)을 도입하는 것입니다.

• 리프레쉬 토큰 발급:

  사용자가 로그인할 때 서버는 엑세스토큰과 함께 리프레쉬 토큰을 발급합니다.

• 리프레쉬 토큰 저장:

  리프레쉬 토큰은 보안상의 이유로 HttpOnly 쿠키로 저장합니다. 이 쿠키는 JavaScript에서 접근할 수 없으므로, XSS 공격에 안전합니다.

• 엑세스토큰 저장:

  엑세스토큰은 브라우저의 로컬스토리지에 저장하여 클라이언트 측에서 사용합니다.

• 자동 토큰 갱신:

  클라이언트에서는 엑세스토큰을 사용하다가 만료되면, HttpOnly 쿠키에 저장된 리프레쉬 토큰을 사용하여 서버에 새 엑세스토큰 발급을 요청합니다. 이 과정은 axios 인터셉터 등을 통해 자동으로 처리할 수 있습니다.

4. 적용 (코드 예시)

4.1. 서버에서 RefreshToken 추가 발급

@PostMapping("/login")
    public ResponseEntity<JwtAuthResponse> loginUser(@Valid @RequestBody UserLoginRequestDto requestDto,
                                                     HttpServletResponse response) {

        String accessToken = userService.loginUser(requestDto);

                // 쿠키에 refresh token 담기
        response.addCookie(userService.craeteCookie(requestDto.getEmail()));

        return ResponseEntity.status(HttpStatus.OK).body(new JwtAuthResponse(AuthenticationScheme.BEARER.getName(), accessToken));
    }

• refresh Token 을 생성해서 쿠키에 담는 메서드 (UserService)

/**
     * refresh Token 을 쿠키에 담기
     *
     * @return Cookie
     */
    public Cookie craeteCookie(String email) {

        String cookieName = "refreshToken";
        String cookieValue = jwtProvider.generateRefreshToken(email); // 쿠키벨류엔 글자제한이 이써, 벨류로 만들어담아준다.

        // refreshToken db 저장
        refreshTokenService.saveRefreshToken(email, cookieValue);

        Cookie cookie = new Cookie(cookieName, cookieValue);
        // 쿠키 속성 설정
        cookie.setHttpOnly(true);  //httponly 옵션 설정
        // cookie.setSecure(true); //https 옵션 설정
        cookie.setPath("/"); // 모든 곳에서 쿠키열람이 가능하도록 설정
        cookie.setMaxAge(60 * 60 * 24); //쿠키 만료시간 설정
        return cookie;

    }

• Redis에 refresh Token을 저장 (만료 기간 30일)

@Service
public class RefreshTokenService {

    private final RedissonClient redissonClient;

    public RefreshTokenService(RedissonClient redissonClient) {
        this.redissonClient = redissonClient;
    }

    // RefreshToken 저장
    public void saveRefreshToken(String username, String refreshToken) {
        RBucket<String> bucket = redissonClient.getBucket("refreshToken:" + username);
        bucket.set(refreshToken, Duration.ofDays(30));
    }

    // RefreshToken 가져오기
    public String getRefreshToken(String username) {
        RBucket<String> bucket = redissonClient.getBucket("refreshToken:" + username);
        return bucket.get();
    }

    // RefreshToken 삭제
    public void deleteRefreshToken(String username) {
        RBucket<String> bucket = redissonClient.getBucket("refreshToken:" + username);
        bucket.delete();
    }

    // RefreshToken 검증
    public boolean validateRefreshToken(String username, String refreshToken) {
        String storedToken = getRefreshToken(username);
        return storedToken != null && storedToken.equals(refreshToken);
    }
}

4.2. Axios 인터셉터를 활용한 자동 토큰 갱신

import axios from "axios";

// 🔹 Axios 인스턴스 생성
const instance = axios.create({
  baseURL: "http://localhost:8080", // Spring Boot 서버 주소
  withCredentials: true, // 쿠키 포함 요청
});

// 🔹 액세스 토큰을 가져오는 함수
const getAccessToken = () => localStorage.getItem("accessToken");

// 🔹 요청 인터셉터: 헤더에 액세스 토큰 추가
instance.interceptors.request.use(
  (config) => {
    const accessToken = getAccessToken();
    if (accessToken) {
      config.headers.Authorization = `Bearer ${accessToken}`;
    }
    return config;
  },
  (error) => Promise.reject(error)
);

// 🔹 리프레시 토큰을 사용해 새로운 액세스 토큰을 가져오는 함수
const refreshAccessToken = async () => {
  try {
    const response = await instance.post(
      "/users/refresh",
      {},
      {
        headers: { "Content-Type": "application/json" },
        withCredentials: true, // HttpOnly 쿠키 포함
      }
    );

    const newAccessToken = response.data.accessToken;
    if (!newAccessToken) throw new Error("새로운 액세스 토큰 없음");

    localStorage.setItem("accessToken", newAccessToken);
    return newAccessToken;
  } catch (error) {
    console.error("❌ 리프레시 토큰 만료: 로그인 페이지로 이동");
    localStorage.removeItem("accessToken");
    window.location.href = "/login"; // 로그인 페이지로 리디렉션
    return null;
  }
};

// 🔹 응답 인터셉터: 401 응답 처리 (액세스 토큰 갱신 후 요청 재시도)
instance.interceptors.response.use(
  (response) => response,
  async (error) => {
    const originalRequest = error.config;

    if (error.response?.status === 401 && !originalRequest._retry) {
      originalRequest._retry = true; // 재시도 방지 플래그 설정

      const newAccessToken = await refreshAccessToken();
      if (newAccessToken) {
        originalRequest.headers.Authorization = `Bearer ${newAccessToken}`;
        return instance(originalRequest); // 요청 재시도
      }
    }

    return Promise.reject(error);
  }
);

export default instance;

4.3 서버에서 엑세스 토큰 재발급 (UserService)

/**
     * refreshToken 확인 및 accessToken 재발급
     *
     * @param email
     * @return accessToken
     */
    public String refresh(String email, String refreshToken) {

        if(!refreshTokenService.validateRefreshToken(email, refreshToken)) {
            throw new UnauthorizedException(ErrorCode.UNAUTHORIZED);
        }

        return jwtProvider.generateAccessToken(email);
    }

5. 자동 로그인 플로우 설명

1. 로그인 시 토큰 발급
   • 사용자가 로그인하면 서버는 엑세스토큰과 리프레쉬 토큰을 함께 발급합니다.
   • 엑세스토큰은 로컬스토리지에 저장되고, 리프레쉬 토큰은 HttpOnly 쿠키에 저장됩니다.
2. 요청 시 엑세스토큰 사용
   • 클라이언트는 axios 인터셉터를 통해 로컬스토리지의 엑세스토큰을 HTTP 헤더에 포함하여 요청합니다.
3. 엑세스토큰 만료 시
   • 서버로부터 401 Unauthorized 응답을 받으면 axios 응답 인터셉터가 동작합니다.
4. 토큰 갱신 요청
   • 인터셉터에서 /users/refresh API를 호출하여 리프레쉬 토큰을 사용해 새 엑세스토큰을 발급받습니다.
5. 새 토큰으로 재시도
   • 발급받은 새 엑세스토큰을 로컬스토리지에 저장하고, 원래의 요청을 재시도하여 자동 로그인을 유지합니다.
6. 갱신 실패 시
   • 새 토큰 발급에 실패하면 사용자를 로그인 페이지로 리디렉션하여 다시 로그인하도록 합니다.

결론

엑세스토큰의 짧은 만료 시간 문제를 해결하기 위해 리프레쉬 토큰을 도입하였습니다.

리프레쉬 토큰은 HttpOnly 쿠키에 안전하게 저장되고, 엑세스토큰은 로컬스토리지에 저장되어 사용됩니다.

axios 인터셉터를 활용해 401 에러 발생 시 자동으로 리프레쉬 토큰을 사용해 새 엑세스토큰을 발급받아 원래의 요청을 재시도하도록 구현하여, 사용자가 자주 로그인할 필요 없이 자동 로그인이 유지되도록 해결했습니다.

KG 이니시스 🏦💳

• 🟩장점
  • 다양한 결제 수단 지원💳 : 신용카드, 가상계좌, 계좌이체, 휴대폰 결제 등 다양한 결제 옵션을 제공
  • API 안정성 높음🔒 : 오랜 기간 운영된 PG사인만큼 장애 발생 가능성이 적음
  • 정기 결제 & B2B 기능 제공📅🔄 : 정기 결제, 자동 결제 같은 고급 기능 지원
  • 대량 거래 처리 가능📊 : 트래픽이 많거나 B2B 환경에서도 안정적
• 🟥단점
  • JSON기반이 아닌 key=value방식 사용📝 : RESTful API를 제공하지만, 최신 표준인 JSON이 아닌 key = value 형태로 데이터를 주고 받음
  • 불편한 테스트 환경⚠️ : API를 테스트 하려면 실제 가맹점 가입 & 승인 절차가 필요
  • UI/UX 개선 필요🖥️ : 다른 결제 서비스 대비 사용자 경험이 다소 불편할 수 있음

KakaoPay💛💬💰

• 🟩장점
  • 높은 사용자 접근성🌍 : 카카오톡 기반으로 가입자가 많아 결제 전환율이 높음
  • 모바일 친화적인 UX/UI📱 : 카카오톡 기반 결제로 사용자에게 익숙한 환경
  • 편의성🔑 : 결제 연동이 간편하고 문서화가 잘 되어 있음
  • 손쉬운 테스트 환경🧪 : 별도의 심사 없이 테스트 가능
• 🟥단점
  • 카카오톡 중심📲 : 카카오톡을 사용하지 않는 사용자에게는 접근성이 낮음, 카카오톡 장애 발생시 결제 불가
  • 일부 결제 수단 제한 🌍💳 : 해외 결제 및 일부 신용카드 결제 제한
  • 제한된 UI커스텀🛠️ : 카카오 페이에서 제공하는 방식으로만 창을 띄울 수 있고 PC환경에서는 결제를 위해 QR코드 스캔 또는 전화번호 입력의 번거로움이 있음

TossPay 💙⚡💰

• 🟩장점
  • 손쉬운 테스트 환경🧪 : 별도의 심사 없이 테스트 가능
  • 결제창 UI 커스텀 가능🎨 : Toss Paymemts SDK를 활용하여 자체 UI구성이 가능
  • 광범위한 결제 수단 지원 💳📱 : 신용카드, 계좌이체, 가상계좌, 휴대폰결제 등 다양한 결제 수단을 제공
• 🟥단점
  • 제한적인 사용자층👥 : 토스 사용자가 빠르게 증가하였지만, 카카오페이에 비해 인지도나 이용자가 적을 수 있음 (4050세대 이상)
  • PC환경에서의 결제 경험 제한💻 : 모바일 중심 서비스라 PC웹에서 UX가 최적화 되지 않았을 수도 있음

왜 KakaoPay를 선택했는가? 💛

이번 프로젝트에서 KakaoPay를 선택한 이유는 주로 사용자 접근성과 편의성에 큰 장점이 있기 때문입니다. 여러 PG사들이 각각의 장단점이 있지만, KakaoPay는 다음과 같은 이유로 더 적합한 선택이었습니다.

1. 높은 사용자 접근성 🌍

KakaoPay는 카카오톡과 깊게 통합되어 있기 때문에, 이미 많은 사용자들이 익숙하게 사용하고 있는 환경입니다. 결제 과정에서 사용자가 별도의 앱을 설치할 필요 없이 카카오톡만 있으면 바로 결제가 가능합니다. 이는 사용자 경험을 크게 향상시키며, 결제 전환율을 높이는 데 유리한 요소입니다. 토스도 마찬가지로 많은 사용자와 모바일에 친숙하지만 토스 이용자 수 보다 카카오톡을 이용하는 이용자 수가 더 높을 것으로 예상되었습니다.

2. 모바일 친화적인 UX/UI📱

KakaoPay는 모바일 환경에서 최적화된 UI/UX를 제공하여, 사용자가 결제 과정을 더욱 직관적으로 진행할 수 있습니다. 특히 카카오톡 사용자들에게 매우 익숙한 UI를 제공하여 사용자의 불편함을 최소화 할 수 있습니다. 이런 점에서 모바일 중심의 비즈니스에 특히 유리합니다. 완성까지의 시간을 고려하여 앱이 아닌 웹으로 유저의 UI를 제작하게 되었지만 기존에 앱을 생각하며 구상하였기 때문에 더욱 적합하다 생각하였습니다.

3. 편리한 테스트 환경 🧪

다른 PG사들과 달리 KakaoPay는 심사 없이 테스트가 가능하다는 점이 큰 장점으로 와닿았습니다. 개발 및 테스트가 용이하고, 별도의 절차 없이 바로 테스트를 시작할 수 있어 개발 속도와 효율성을 크게 개선할 수 있었습니다.

선택의 아쉬운 점 😮‍💨

1. 결제 수단의 제한🚫💳

KakaoPay는 카카오톡 기반이라 편리하지만, 카카오톡을 사용하지 않거나 카카오페이 결제에 익숙하지 않은 사용자에게는 접근성이 떨어질 수 있습니다. 또한, 특정 해외 결제 및 일부 신용카드 사용이 제한되는 점도 아쉬운 부분입니다.

2. UI 커스터마이징의 한계🎨🔒

KakaoPay의 결제 화면은 카카오가 제공하는 방식 그대로 사용해야 하므로, 서비스에 맞게 자유롭게 커스터마이징하기 어렵습니다. 특히 PC 환경에서는 QR코드 스캔 또는 전화번호 입력 과정이 다소 번거롭게 느껴졌습니다.

3. 여러 PG사 연동의 어려움🔄🛠️

이번 프로젝트에서는 KakaoPay만을 고려하여 개발을 진행했기 때문에 당장은 문제가 없지만, 추후 다른 결제 서비스를 추가하려면 각각 개별로 연동해야 하는 번거로움이 발생할 수 있습니다.

이러한 경험을 바탕으로, 다음 프로젝트에서는 "포트원(PortOne)"을 활용하여 여러 PG사를 하나의 API로 통합하여 연동하는 방식을 시도할 계획입니다. 이를 통해 다양한 결제 수단을 유연하게 추가하고, 유지보수의 부담을 줄일 수 있을 것으로 기대됩니다.

프로젝트 배포 파이프라인을 구축할 때, Jenkins와 GitHub Actions 두 가지 옵션을 검토했습니다. 여러 측면에서 비교한 결과, GitHub Actions를 선택한 주요 이유는 다음과 같습니다.

1) 통합 및 사용 편의성

GitHub Actions: GitHub Actions는 GitHub 리포지토리와 완벽하게 통합되어 있어 별도의 CI/CD 서버를 구성할 필요 없이, 소스 코드 변경과 동시에 자동화된 배포 파이프라인을 바로 구축할 수 있습니다. 또한, YAML 기반의 워크플로우 설정이 직관적이어서 빠르게 학습하고 적용할 수 있습니다.

Jenkins: Jenkins는 강력한 플러그인 에코시스템과 커스터마이징 가능성을 제공하지만, 별도의 설치, 관리, 유지보수가 필요합니다. GitHub와의 연동도 플러그인을 추가해야 하는 등 초기 설정과 관리에 더 많은 노력이 요구됩니다.

2) 유지보수 및 비용 효율성

GitHub Actions: GitHub Actions는 클라우드 기반으로 운영되며, GitHub 리포지토리 내에서 관리되기 때문에 별도의 서버 관리 부담이 없습니다. 또한, 사용량에 따라 무료 제공 범위가 있어 소규모부터 중규모 프로젝트에 비용 효율적으로 적용할 수 있습니다.

Jenkins: Jenkins는 자체 호스팅이 일반적이므로, 서버 관리, 보안 업데이트, 백업 등의 추가 유지보수 작업이 필요하며, 인프라 비용이 발생할 수 있습니다.

3) 확장성과 커뮤니티 지원

GitHub Actions: GitHub Actions는 GitHub의 활발한 커뮤니티와 풍부한 오픈소스 액션들이 이미 제공되고 있어, 필요에 따라 다양한 액션을 쉽게 활용할 수 있습니다. 또한, GitHub의 인프라를 활용하여 높은 확장성을 확보할 수 있습니다.

Jenkins: Jenkins 또한 오랜 기간 널리 사용되며 방대한 플러그인을 보유하고 있지만, 플러그인 간의 호환성 문제나 업데이트 관리 등에서 복잡성이 증가할 수 있습니다.

2. Docker 및 Docker Hub를 활용

배포 프로세스의 효율성과 일관성을 높이기 위해, 애플리케이션을 Docker 이미지로 빌드하고 Docker Hub에 업로드한 후, EC2 서버에서 해당 이미지를 다운로드하여 컨테이너로 실행하는 방식을 채택했습니다.

Docker 사용 이유

애플리케이션을 이미지 파일로 패키징하여 환경 간 일관성을 보장 로컬, 스테이징, 프로덕션 등 다양한 배포 환경에서 동일한 이미지를 사용할 수 있어 배포 및 유지보수가 용이

Docker Hub 사용 이유

중앙화된 이미지 저장소를 통해 배포 파이프라인에서 손쉽게 이미지를 관리 CI/CD 파이프라인과의 원활한 연계를 통해 빌드된 이미지를 자동으로 푸시하고, EC2 서버에서는 이를 풀(Pull) 받아 최신 버전으로 배포 가능

3. 결론

GitHub Actions를 선택함으로써, GitHub와의 완벽한 통합과 간편한 YAML 설정을 통해 CI/CD 파이프라인을 효율적으로 구축할 수 있습니다. 또한, Docker와 Docker Hub를 활용한 배포 전략은 애플리케이션의 일관된 환경 제공 및 배포 자동화를 가능하게 하여, EC2 서버에서 최신 이미지를 손쉽게 배포할 수 있도록 합니다. 이러한 기술적 의사 결정은 초기 설정과 유지보수의 부담을 줄이고, 배포 과정에서의 효율성과 확장성을 극대화하는 데 기여합니다.

서비스에서는 사용자가 특정 가게 상세 조회 페이지에 진입하면 해당 가게의 조회수가 증가하고, 페이지를 벗어나면 감소하는 동적 기능이 필요합니다. 이를 위해 여러 통신 기술(SSE, WebSocket, RabbitMQ, Kafka)을 고려하였으며, 각 기술의 장단점을 아래와 같이 비교했습니다. 또한 이 조회수를 다른 사용자에게 전달하기 위해 메시징 이벤트가 필요합니다. 이 메시징 이벤트를 구현하기 위해 Redis의 Pub/Sub 기능을 활용했습니다.

1. 기술 비교

2. SSE 선택 이유

이 서비스에서는 실시간 단방향 알림 기능만 필요하므로, SSE(Server-Sent Events)를 선택했습니다.

조회수는 단순히 증감하는 이벤트이므로 양방향 통신이 필요 없습니다.

서비스에서 조회수 기능은 “사용자가 페이지에 들어갔을 때 증가, 나갔을 때 감소”하는 이벤트로, 클라이언트로 실시간 알림을 보내면 되므로 복잡한 양방향 통신이 필요하지 않습니다.

SSE는 HTTP 기반으로 브라우저에서 기본적으로 지원되며, 추가적인 라이브러리 없이 쉽게 구현 가능합니다.

지속적인 연결 유지가 필요하지만, WebSocket처럼 복잡한 핸드셰이크 및 연결 유지 관리가 필요 없습니다.

서버에서 클라이언트로만 데이터 전송이 가능하므로, 실시간 조회수 갱신에 적합합니다.

3. Redis Pub/Sub 활용

사용자가 특정 가게의 상세 조회 페이지에 들어가면 Redis의 Pub 이벤트가 발생합니다. 해당 페이지에 이미 접속해 있는 사용자들은 Sub 이벤트를 수신하여 실시간으로 조회수를 업데이트 받습니다.

실시간 반영: 사용자가 페이지에 들어가거나 나갈 때마다 즉각적으로 조회수가 업데이트되어 사용자 경험을 향상시킵니다.

경량화: 별도의 무거운 메시지 큐 시스템 없이, Redis의 경량 Pub/Sub 기능을 통해 빠른 메시지 전달이 가능해집니다.

확장성: 여러 서버 인스턴스 간에도 이벤트 전달이 원활하여, 트래픽이 증가하더라도 안정적인 성능을 유지할 수 있습니다.

4. 결론

실시간 가게 조회수 기능은 사용자가 현재 보고있는 가게의 인기와 경쟁도를 확인하고 예약을 촉진시킬 수 있는 기능입니다.

이 기능을 구현하기 위해서는 서버와 클라이언트가 지속적으로 연결이 유지되는 통신 기술이 필요하고 조회 수 변경 감지에 따른 조회 수 업데이트가 필요하기 때문에 메세지 이벤트 시스템이 필요했습니다.

이 요구사항에 맞게 여러 기술을 비교해보고, SSE와 Redis의 Pub/Sub 기술을 이 서비스에 적합하다고 판단하여 적용하게 되었습니다.

"줄서기 스트레스는 그만! 효율적인 웨이팅의 시작"

외식을 자주 즐기는 요즘 인기 맛집에서 길게 줄 서는 시대는 끝! 얼리 테이블로 미리 예약하고, 웨이팅을 잡아 스마트하게 식사 준비하세요. 시간도 아끼고, 더 맛있게!!

❤️ 서비스/프로젝트 소개

서비스 개요

기획 배경

현재 많은 음식점이 테이블링 앱을 활용하고 있지만, 사용자들은 여러 문제점을 겪고 있습니다.

• 부정확한 대기 시간 예측: 기존 서비스에서는 대기 시간이 미제공 또는 부정확하게 제공되어 사용자 불편이 발생
• 개인화된 서비스 부족: 사용자의 식습관(예: 알러지 등)에 대한 필터링 기능이 미비
• 일행 관리 서비스 부족: 일행이 예약에 대한 정보를 알고싶을 때 예약자를 통해 확인하는 번거로움 발생

개선 사항

본 서비스는 기존의 문제를 해결하고, 보다 편리한 예약 및 웨이팅 환경을 제공하기 위해 다음과 같은 기능을 제공합니다.

1. 실시간 예상 대기 시간 제공
   • 정확한 대기 시간 정보 제공
   • 실시간 대기열 업데이트로 사용자의 대기 불편 최소화
2. 맞춤형 필터링 기능
   • 알러지, 특정 식재료 제외 등 사용자의 조건을 고려한 음식점 필터링 제공
3. 향상된 사용자 경험 제공
   • 손쉬운 예약 및 웨이팅 기능 제공
   • 알림 기능을 활용한 예약 및 웨이팅 상태 실시간 업데이트
   • 일행을 초대하고 관리할 수 있는 서비스 제공
   • 실시간 특정 가게 조회수 조회 기능 제공

📊 주요 기능

실시간 웨이팅

• 실시간 남은 웨이팅 순서 정보 + 실시간 예상 대기 시간 제공

실시간 예약 및 결제 API 연동

• 동시성 제어 - Redis 분산락 적용
• 카카오 페이의 API를 연동하여 결제 정보처리 및 결과 DB에 반영

실시간 가게 조회수

• SSE와 Redis Pub/Sub 기능 이용

알림 서비스

• FCM과 SSE, Redis Pub/Sub 기능 이용

맞춤형 조건 검색

• 지역, 금액, 음식 카테고리, 알러지 및 검색어로 맞춤 검색 기능 제공

🛠️ 적용 기술

🛣️ 인프라 설계도

이 프로젝트는 AWS 인프라 클라우드 환경에서 구축했습니다. 사용자가 처음 접속하면 Route 53을 통해 연결된 도메인으로 접근하며, 정적 콘텐츠는 S3에서 제공됩니다. API 요청이 들어오면 ALB가 트래픽을 분산시키고, EC2 인스턴스에서 동작하는 Spring Boot 서버와 RDS(MySQL)가 연동하여 요청을 처리합니다. ALB를 통해 분산 서버에 대한 확장성을 고려할 수 있습니다. 성능 최적화를 위해 Redis의 캐싱과 분산락, Pub/Sub 기능을 사용합니다. GitHub Actions + Docker를 이용한 CI/CD 파이프라인을 구축하여, 코드 변경 시 자동으로 빌드 및 배포가 이루어지도록 만들었습니다.

ERD

이 ERD는 식당 예약/웨이팅 시스템을 중심으로 설계되었습니다. 핵심 테이블인 가게를 중심으로 메뉴, 예약, 웨이팅 테이블을 구성하여 시스템의 주요 기능을 구현했습니다. 부가적으로 알러지, 가게 키워드, 리뷰, 이미지 파일 및 가게 설정 관련 테이블을 구성하여 다양한 기능을 지원할 수 있도록 구성했습니다. 정규화를 준수하여 데이터 중복을 최소화하고, 테이블 간의 관계 설정을 통해 데이터 일관성을 유지하도록 설계했습니다. JPA를 활용하여 객체와 테이블 간의 연관관계를 매핑하고, QueryDSL을 사용하여 타입-세이프한 방식으로 동적 쿼리를 최적화하여 유지보수성과 성능을 향상시켰습니다.

업무 타임라인

• wbs

1) 의존성 추가

• build.gradle

  dependencies {
  //QueryDSL
    implementation "com.querydsl:querydsl-jpa:5.0.0:jakarta"
    annotationProcessor "com.querydsl:querydsl-apt:5.0.0:jakarta"
    annotationProcessor "jakarta.annotation:jakarta.annotation-api"
    annotationProcessor "jakarta.persistence:jakarta.persistence-api"
  
    ...
  }

build.gradle에 dependencies 안에 queryDSL 의존성 추가한다.

2) QClass 빌드

Gradle의 Task에서 [build > clean] ->[other > compileJava] 과정을 차례로 수행해보자.

  다음 사진과 같이 build 디렉터리에 Entity에서 생성된 Q Class가 성공적으로 빌드되었는지 확인해보자. 컴파일 단계에서 Entity와 형태가 같은 Static Class로 QClass을 생성하고, QueryDSL은 해당 클래스를 기반으로 쿼리 메서드를 실행시키게 된다. 따라서 타입의 불일치에 대한 에러 캐치에 관련하여 좋은 장점을 가질 수 있다.

QClass 뜯어보기

/**
 * QMember is a Querydsl query type for Member
 */
@Generated("com.querydsl.codegen.DefaultEntitySerializer")
public class QMember extends EntityPathBase<Member> {

    private static final long serialVersionUID = 1003972608L;

    public static final QMember member = new QMember("member1");

    public final ListPath<Category, QCategory> categories = this.<Category, QCategory>createList("categories", Category.class, QCategory.class, PathInits.DIRECT2);

    public final StringPath email = createString("email");

    public final NumberPath<Long> memberId = createNumber("memberId", Long.class);

    public final StringPath name = createString("name");

    public final StringPath password = createString("password");

    public final EnumPath<com.example.tosshelperappserver.common.constant.RoleType> role = createEnum("role", com.example.tosshelperappserver.common.constant.RoleType.class);

    public QMember(String variable) {
        super(Member.class, forVariable(variable));
    }

    public QMember(Path<? extends Member> path) {
        super(path.getType(), path.getMetadata());
    }

    public QMember(PathMetadata metadata) {
        super(Member.class, metadata);
    }

}

  생성된 QClass 내부를 살짝만 한번 들여다보고 가보자. EntityPathBase를 상속받는데, 이는 엔티티에 대한 경로를 나타내는 QueryDSL의 추상 클래스이다. 멤버 변수로 매핑된 엔티티를 기반으로 자동 생성된 속성들이 존재한다.   Type으로 그냥 String이 아니라, StringPath, 그리고 createString 따위의 메서드를 사용하는 것을 볼 수 있는데, 이는 Builder Pattern을 활용하여 QType의 속성을 변경할 수 있도록 설계되었기 때문이다.

2) QueryDSL 사용을 위한 Factory를 Bean으로 등록

@Configuration
public class QueryDslConfig {

    @PersistenceContext
    private EntityManager entityManager;

    @Bean
    public JPAQueryFactory jpaQueryFactory() {
        return new JPAQueryFactory(entityManager);
    }
}

JPAQueryFactory는 QueryDSL에서 제공하는 주요 클래스 중 하나이다. 해당 Config 파일을 만들어 JPAQueryFactory를 QueryDSL을 이용한 JPA 쿼리를 빌드하는 Factory 역할로서 사용할 수 있도록 Bean으로 등록시켜 두자.

3) Repository에서 사용하기

@Repository
public interface MemberRepository extends JpaRepository<Member, Long> {


    // 쿼리 메서드
    Member findMemberByEmail(String email);

    // 동적 쿼리 생성
    @Query(value= "select m from Member m where m.memberId = :id and m.email = :email" )
    Member findMemberByIdAndEmail(@Param("id") Long id, @Param("email") String email);


}

  기존에 JpaRepository를 사용하여 다음과 같은 쿼리들을 작성해 두었다고 가정해보자, 이제 해당 Repository에서 QueryDsl을 사용한 메서드를 작성할 수 있도록 해 보자.

4) Custom Repository에서 QueryDSL을 사용하여  쿼리 빌드

public interface MemberCustomRepository {

    Member findAllLeftFetchJoin(Long id);
}

package com.example.tosshelperappserver.repository;
import com.example.tosshelperappserver.domain.Member;
import com.querydsl.jpa.impl.JPAQueryFactory;
import lombok.AllArgsConstructor;
import org.springframework.stereotype.Repository;
import static com.example.tosshelperappserver.domain.QMember.member;


@Repository
@AllArgsConstructor
public class MemberCustomRepositoryImpl implements MemberCustomRepository{

    private final JPAQueryFactory jpaQueryFactory;


    @Override
    public Member findAllLeftFetchJoin(Long id) {
        return jpaQueryFactory.selectFrom(member)
                .where(member.memberId.eq(id))
                .leftJoin(member.categories)
                .fetchJoin()
                .fetchOne();
    }
}

  JpaRepository는 인터페이스이기 때문에 코드를 구현할 수 없다. 따라서 CustomRepository를 작성해주자. 내부에서는 JPAQueryFactory를 Injection하여 사용하고 있다.   쿼리문은 Builder 패턴으로 작성된다. 쿼리문을 작성하는 내용에 대해서는 다음에 다루어볼 예정이지만 해당 쿼리문은 memberId와 일치하는 Member를 Categories와 함께 Join하는 쿼리문이다.  눈썰미가 있다면 눈치챘을 수도 있겠지만, jpaQueryFactory에서 사용되는 쿼리문의 내부에는 QClass가 사용되고 있다.

5) JpaRepository에 추가 및 Service에서의 사용

@Repository
public interface MemberRepository extends JpaRepository<Member, Long>, MemberCustomRepository {


    // 쿼리 메서드
    Member findMemberByEmail(String email);

    // 동적 쿼리 생성
    @Query(value= "select m from Member m where m.memberId = :id and m.email = :email" )
    Member findMemberByIdAndEmail(@Param("id") Long id, @Param("email") String email);

}

  이제 해당 Repository를 JpaRepository에서 상속받아 QueryDsl을 사용한 메서드들을 사용할 수 있도록 하자.      

@Override
public MemberWithCategoryDto getMemberInfoWithOwnCategory(Long id) {
    Member member = memberJpaRepository.findAllLeftFetchJoin(id);
    MemberWithCategoryDto dto = modelMapper.map(member, MemberWithCategoryDto.class);
    return dto;
}

출처: https://sjh9708.tistory.com/174 [데굴데굴 개발자의 기록:티스토리]

1) Querydsl과 JPQL 비교

먼저 Querydsl과 JPQL을 비교해보겠다.

Querydsl vs JPQL

JPAQueryFactory qf;

  @Test
  public void startJPQL(){

  // JPQL을 사용한 member1 찾기

    String qlString = "select m from Member m " +
                      "where m.username = :username";

        Member findMember = em.createQuery(qlString, Member.class)
         .setParameter("username", "member1")
         .getSingleResult();

         assertThat(findMember.getUsername()).isEqualTo("member1");

  }

  @Test
  public void startQuerydsl(){

  //Querydsl 사용한 member1 찾기
    JPAQueryFactory qf = new JPAQueryFactory(em);

    Memeber findMember =qf
                          .select(Qmember.member)
                          .from(Qmember.member)
                          .where(Qmember.member.name.eq("member1") //파라미터 바인딩 처리
                          .fetchOne();

    assertThat(findMember.getUsername()).isEqualTo("member"1);

  }

EntityManager 로 JPAQueryFactory 생성

Querydsl 은 JPQL 빌더

JPQL: 문자(실행 시점 오류), Querydsl: 코드(컴파일 시점 오류) JPQL: 파라미터 바인딩 직접, Querydsl: 파라미터 바인딩 자동 처리

JPAQueryFactory 를 필드로 설정 할 수도 있다.

*JPQQueryFactory를 필드로 제공하면 동시성 문제는 어떻게 될까? * 동시성 문제는 JPAQueryFactory를 생성할 때 제공하는 EntiryManager(em)에 달려있다. 스프링 프레임워크는 여러 쓰레드에서 동시에 같은 EntityManager에 접근해도 트랙재션 마다 별도의 영속성 컨텍스트를 제공하기 때문에, 동시성 문제는 걱정하지 않아도 된다.

2) Qclass

기본적으로 QueryDsl을 사용할때 QClass가 생성이 된다.  초기에 QueryDSL을 사용하면서 궁금했던 내용은 그냥 Entity를 사용해도 될거같은데 굳이 QClass를 만들어서 사용을 할까? 어떻게 만드는거지? 라는 기본적인 궁금증에서 래퍼런스 문서 부터 많은 블로그의 내용을 찾아봤으며 해당 내용을 정리 해보려고 한다.   JPA_APT(JPAAnnotationProcessorTool)가 @Enttiy 와 같은 특정 어노테이션을 찾고 해당 클래스를 분석해서 QClass를 만들어 준다.  빌드 도구를 통해서 만드는 방법은 다른곳을 찾아봐도 나오니 생략한다.  (Gradle의 경우, 버전별로 설정을 하는 방식이 다르기 때문에 버전에 맞게 잘 찾아서 사용 해야 한다.)  

✋ APT 란 ?

Annotation 이 있는 기존코드를 바탕으로 새로운 코드와 새로운 파일들을 만들 수 있고, 이들을 이용한 클래스에서 compile 하는 기능도 지원해준다. 쉬운 예시로는 Lombok의 @Getter, @Setter가 있다. 해당 어노테이션을 사용하는 경우 apt가 컴파일 시점에 해당 어노테이션을 기준으로 getter 와 setter를 만들어 주기 때문에 코드를 작성하지 않고 사용이 가능해진다.  

✋ QClass 란?

엔티티 클래스의 메타 정보를 담고 있는 클래스로, Querydsl은 이를 이용하여 타입 안정성(Type safe)을 보장하면서 쿼리를 작성할 수 있게 된다.   QClass는 엔티티 클래스와 대응되며  엔티티의 속성을 나타내고 있다. 이러한 QClass를 사용하여 쿼리를 작성하면 엔티티 속성을 직접 참조하고 조합하여 쿼리를 구성할 수 있다. QClass를 사용하면 컴파일 시점에 오류를 확인할 수 있고, IDE의 자동완성 기능을 활용하여 쿼리 작성을 보다 편리하게 할 수 있다.   그렇다면 굳이 엔티티 클래스 대신 Q클래스를 만들어서 사용하는 이유에 대해서 정리 하려고 한다.    QClass와 엔티티 클래스는 많은 장점을 공유하고 있지만 그럼에 QClass를 사용하는 이유는 다음과 같다.

QClass는 엔티티 속성을 정적인 방식으로 표현하므로 IDE의 자동 완성 기능을 활용할 수 있고, 속성 이름을 직접 기억하거나 확인하지 않아도 된다는 장점을 가지고 있다.  QClass는 엔티티 속성의 타입을 정확하게 표현하므로, 타입에 맞지 않는 연산이나 비교를 시도하면 컴파일러가 오류를 감지할 수 있다.

QClass는 엔티티 클래스의 확장으로 생각할 수 있다. 엔티티 클래스는 데이터베이스 테이블의 매핑을 담당하고, QClass는 쿼리 작성을 위한 편의성과 안전성을 제공을 해주면서 유지보수의 편의성 및 실수 방지를 하지 않도록 해준다고 생각한다.

기본 Q-Type 활용 Q클래스 인스턴스를 사용하는 3가지 방법

QMember qMember = new QMember("m"); //별칭 직접 설정
QMember qMember = QMember.member; //기본 인스턴스 사용

import static kbds.querydsl.domain.QMember.member; //static 상수 설정

참고 : 같은 테이블을 조인해야하는 경우가 아니면 기본 인스턴스를 사용하자. 검색 조건 쿼리

 @Test
 public void search(){

  Member findMember =  qf
    .selectFrom(member)
    .where(member.username.eq("member1")
    .and(member.age.eq(10))
    .fetchOne();

 }

2) 기본 문법

(1) 셋팅

사용할 데이터

1. Author : Book = 1 : N Author(저자)는 여러 개의 Book(책)을 가진다.  
2. Author : Organization = N : 1 Author(저자)는 한곳의 Organization(조직)에 속한다.  
3. Book : Review = 1 : N Book(책)은 여러 개의 Review(리뷰)를 가진다.

@Entity
@Table(name = "Organization")
@Getter
@Setter
public class Organization {
    @Id
    @GeneratedValue(strategy = GenerationType.IDENTITY)
    private Long id;

    private String orgName;

    @OneToMany(mappedBy = "organization", cascade = CascadeType.ALL)
    private List<Author> authors = new ArrayList<>();

}

@Entity
@Table(name = "Author")
@Getter
@Setter
public class Author {

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

    private String name;

    @OneToMany(mappedBy = "author", cascade = CascadeType.ALL)
    private List<Book> book = new ArrayList<>();

    @ManyToOne(fetch=FetchType.LAZY)
    @JoinColumn(name = "organization_id")
    private Organization organization;

}

@Entity
@Table(name = "Book")
@Getter
@Setter
public class Book {

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

    private String title;

    @ManyToOne(fetch=FetchType.LAZY)
    @JoinColumn(name = "author_id")
    private Author author;

    @OneToMany(mappedBy = "book", cascade = CascadeType.ALL)
    private List<Review> reviews = new ArrayList<>();

}

@Entity
@Table(name = "Review")
@Getter
@Setter
public class Review {

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

    private String comment;

    @ManyToOne
    @JoinColumn(name = "book_id")
    private Book book;

}

(2) 검색(Select)

리스트 조회

public List<Book> findBookList() {
    List<Book> result = queryFactory
            .selectFrom(book)
            .fetch();
    return result;
}

단일 조회

public Book findBookByTitle(String title) {
    Book result = queryFactory.selectFrom(book)
            .where(book.title.eq(title))
            .fetchOne();
    return result;
}

• selectFrom(QType) : 해당 엔티티에서 모든 컬럼 조회
• fetch() : 리스트를 조회, 데이터가 존재하지 않을 시 빈 리스트를 반환
• fetchOne() : 단일 조회, 결과가 없으면 Null, 결과가 단일이 아닐 시 Exception 발생
• fetchFirst() : 단일 조회, 결과가 여러개여도 맨 처음 레코드 반환

컬럼 선택하여 조회

public List<String> findBookListTitle() {
    List<String> result = queryFactory.select(book.title)
            .from(book)
            .fetch();
    return result;
}

• select(QType.Column1, QType.Column2) : 엔티티의 해당 컬럼(들) 조회
• from(QType) : 조회 대상 엔티티

(3) 조건(Where)

public Book findBookByTitle(String title) {
    Book result = queryFactory.selectFrom(book)
            .where(book.title.eq(title))
            .fetchOne();
    return result;
}

• where(조건) : 해당 조건과 일치하는 레코드(들)을 반환

다양한 조건 함수

// 동일 여부
author.name.eq("John"); // 일치
author.name.ne("John"); // 일치X
author.name.isNotNull(); // NullX

// 포함
author.age.in(20, 30, 40); // 포함
author.age.notIn(25, 35, 45); // 미포함

// 문자열
author.name.like("J%"); // LIKE : J로 시작
author.name.startsWith("J"); // J로 시작
author.name.contains("Jo"); // J 포함

// 수 비교
author.age.between(25, 35); // 25 ~ 35
author.age.lt(30); // < 30
author.age.loe(30); // <= 30
author.age.gt(30); // > 30
author.age.goe(30); // >= 30

복합 조건 연산

public List<Author> findAuthorByCondition() {

    List<Author> result = queryFactory.selectFrom(author)
            .where(
                    author.age.notBetween(20, 30)
                            .and(author.age.gt(10))
                            .and(author.age.lt(50))
            )
            .fetch();

    return result;
}

select * from author
where age NOT BETWEEN 20 and 30 
and age > 10 and age < 50;

• and(조건) : AND 복합 조건
• or(조건) : OR 복합 조건

public List<Author> findAuthorByCondition2() {

    List<Author> result = queryFactory.selectFrom(author)
            .where(
                    (
                            author.age.notBetween(20, 30)
                                    .and(author.age.gt(10))
                                    .and(author.age.lt(50))
                    ).or(
                            author.name.like("%John%")
                    )
            )
            .fetch();


    return result;

}

select * from author
where (age NOT BETWEEN 20 and 30 
and age > 10 and age < 50) or
(name LIKE "%John%");

• () 로 조건들을 묶어 표현식 만들 수 있다.

.where(
    boardIdEq(boardId),
    cardTitleEq(cardTitle),
    cardExplanationEq(cardExplanation),
    endAtEq(endAt),
    cardManagerNicknameEq(cardMangerName)
)

...

private BooleanExpression boardIdEq(Long boardId) {
        return boardId != null ? card.boardList.board.id.eq(boardId) : null;
    }

    private BooleanExpression cardTitleEq(String cardTitle) {
        return cardTitle != null ? card.cardTitle.contains(cardTitle) : null;
    }

    private BooleanExpression cardExplanationEq(String cardExplanation) {
        return cardExplanation != null ? card.cardExplanation.contains(cardExplanation) : null;
    }

    private BooleanExpression endAtEq(String endAt) {
        if (endAt == null) {
            return null;
        }
        LocalDate ConvertedEndAt = LocalDate.parse(endAt);
        return card.endAt.eq(ConvertedEndAt);
    }

    private BooleanExpression cardManagerNicknameEq(String userNickname) {
        return userNickname != null ? user.nickName.eq(userNickname) : null;
    }

• 메서드로 조건을 추출하며 적용할 수 있다.

연관된 엔티티의 컬럼을 조건으로 사용

public List<Book> findBooksByAuthorName(String name) {
    List<Book> result = queryFactory
            .selectFrom(book)
            .where(book.author.name.eq(name))
            .fetch();
    return result;
}

• book.author.name 을 보면 연관된 엔티티의 컬럼을 조건으로 사용할 수 있다. (Book과 Author은 N:1 관계)
• SQL 쿼리문으로는 아래와 같다.

SELECT Book.*
FROM Book
INNER JOIN Author ON Book.author_id = Author.id
WHERE Author.name = 'John Doe';

(4) 정렬 (Order By)

public List<Book> findBookListOrderBy() {
    List<Book> result = queryFactory
            .selectFrom(book)
            .orderBy(book.title.desc())
            .fetch();
    return result;
}

• orderBy(QType.Column.(정렬조건)) : 해당 컬럼을 정렬조건에 따라 정렬 (디폴트는 asc)

정렬조건

• desc() : 내림차순
• asc() : 올림차순

public List<Book> findBookListOrderBy() {
    List<Book> result = queryFactory
            .selectFrom(book)
            .orderBy(book.title.desc().nullsLast())
            .fetch();
    return result;
}

• nullsLast(), nullsFirst() : Null 데이터에 대한 순서를 부여한다(끝, 시작)

(5) 페이지네이션 (Offset, Limit)

public List<Book> findBookListPagenation(int offset, int limit) {
    List<Book> result = queryFactory
            .selectFrom(book)
            .offset(offset)
            .limit(limit)
            .fetch();
    return result;
}

• offset(long x) : 0부터 시작하는 결과에 대한 오프셋(시작 위치)
• limit(long x) : 쿼리 결과에 대한 최대치 제한(Limit)

public List<Book> findBookListPagenation(int offset, int limit) {
    QueryResults<Book> res = queryFactory
            .selectFrom(book)
            .offset(offset)
            .limit(limit)
            .fetchResults();

    System.out.println("Total : " + res.getTotal());
    System.out.println("Limit : " + res.getLimit());
    System.out.println("Offset : " + res.getOffset());
    List<Book> result = res.getResults();
    return result;
}

• fetchResults : 결과를 가져올 때 페이지네이션 정보를 함께 가져온다. (total, limit, offset) 결과는 getResults()를 호출 시 얻을 수 있다.

(6) 집계함수(Aggregation)

  그룹 함수와 함께 주로 사용된다.

public List<Tuple> findAuthorAggregation() {
    List<Tuple> result = queryFactory
            .select(author.count(), author.age.avg())
            .from(author)
            .fetch();
    return result;
}

• count() : 집합의 행 수 계산
• sum() : 합 계산
• avg() : 평균 계산
• max() : 최대 계산
• min() : 최소 계산

(7) 그룹화 (Group By, Having)

public List<Tuple> findAuthorGroupByGender() {
    List<Tuple> result = queryFactory
            .select(author.gender, author.count(), author.age.avg())
            .from(author)
            .groupBy(author.gender)
            .fetch();
    return result;
}

SELECT
    author.gender,
    COUNT(author.id),
    AVG(author.age)
FROM
    author
GROUP BY
    author.gender;

• groupBy(컬럼1, 컬럼2..) : 해당 컬럼을 기준으로 그룹화한다.

public List<Tuple> findAuthorGroupBy() {
    List<Tuple> result = queryFactory
            .select(author.organization.orgName, author.count(), author.age.avg())
            .from(author)
            .groupBy(author.organization.id)
            .having(author.age.avg().gt(10))
            .fetch();
    return result;
}

SELECT
    author_organization.org_name,
    COUNT(author.id),
    AVG(author.age)
FROM
    author
JOIN
    organization AS author_organization ON author.organization_id = author_organization.id
GROUP BY
    author.organization_id
HAVING
    AVG(author.age) > 10;

• having(조건) : 특정 조건을 만족하는 그룹을 필터링한다.
• 해당 예시는 연관된 엔티티의 컬럼을 기준으로 GroupBy를 수행한 예시이다.

출처: https://ssow93.tistory.com/60 [soTech:티스토리] 출처: https://sjh9708.tistory.com/175 [데굴데굴 개발자의 기록:티스토리]

JPA를 사용하여 데이터베이스와 연결된 애플리케이션을 개발할 때, 동시성 처리와 관련된 이슈가 발생할 수 있다. 이러한 이슈를 해결하기 위한 방법 중 하나는 락(lock)을 사용하는 것이다. 이번 포스팅에는 낙관적 락과 비관적 락에 대해 알아보고, 예제코드와 이를 사용하는 이유 및 장단점을 함께 써보겠다.

낙관적 락(Optimistic Lock)

낙관적 락은 충돌이 거의 발생하지 않을 것이라고 가정하고, 충돌이 발생한 경우에 대비하는 방식이다. 낙관적 락은 JPA에서 버전(Version) 속성을 이용하여 구현할 수 있다. 낙관적 락의 특징으로는 충돌 발생확률이 낮고, 지속적인 락으로 인한 성능저하를 막을 수 있다.아래는 예시 코드이다.

1. Entity

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

    @Version
    private Long version;

    private String data;
}

2. Repository

@Repository
public interface SampleEntityRepository extends JpaRepository<SampleEntity, Long> {
}

3. Service

@Service
public class SampleEntityService {
    @Autowired
    private SampleEntityRepository sampleEntityRepository;

    public SampleEntity updateData(Long id, String newData) {
        SampleEntity sampleEntity = sampleEntityRepository.findById(id).orElseThrow();
        sampleEntity.setData(newData);
        return sampleEntityRepository.save(sampleEntity);
    }
}

작동원리로는 SampleEntity 클래스에 @Version 어노테이션을 이용하여 version 필드로 지정한다. 데이터를 수정할 때 같은 id 값이지만 다른 사용자에 의한 변경이 발생하면 version 값이 다르게 되고, 이때 예외가 발생하므로 충돌로부터 안전하게 처리할 수 있다.

예제

@Version Annotation JPA에서 version 속성을 정의할때 지켜야하는 몇가지 규칙이 있습니다.

각 Entity Class에는 @Version 속성이 하나만 있어야 한다 여러 테이블에 매핑된 Entity의 경우 기본 테이블에 배치되어야 한다 버전에 타입은 int , Integer , long , Long , short , Short , java.sql.Timestamp 중 하나여야 한다 이 field 의 값 혹은 시간이 처음 조회될 때의 버전과 commit될때의 버전이 서로 다르다면 이는 충돌이 발생한 것으로 판단하고 예외를 발생시킵니다.

재고를 차감하는 예를 들어보겠습니다. 치킨A라는 재고는 현재 단 한개가 남아 있습니다.

[transaction-1] : 치킨A의 재고를 확인 / 치킨A 재고: 1개, version: 1 [transaction-2] : 치킨A의 재고를 확인 / 치킨A 재고: 1개, version: 1

-- 이때 두 트랜잭션 중 transaction-1 가 먼저 완료되었다고 가정해보겠습니다.

[transaction-1] : 치킨A를 구매 / 치킨A 재고: 0개, version: 2 로 업데이트하고 커밋 [transaction-2] : 치킨A를 구매 / 치킨A 재고: 0개, version: 2 로 업데이트하고 커밋하려는데 version이 처음 조회했던 1이 아니라 [transaction-1]에서 2로 변경되어 현재 조회한 버전과 다르므로 업데이트 실패

update stock
set
    availableStock = ?,
    version = 2
where
    id = ?
    and version = 1

위와 같은 쿼리가 발생하지만 해당 재고의 version은 transaction-1 으로 인해 이미 2로 증가된 상태입니다. 이때 처음 조회했던 version값인 1을 전달하게 되니 업데이트할 대상을 찾지 못해 예외가 발생합니다.

비관적 락(Pessimistic Lock)

비관적 락은 충돌이 발생할 확률이 높다고 가정하여, 실제로 데이터에 액세스 하기 전에 먼저 락을 걸어 충돌을 예방하는 방식이다. 비관적 락은 JPA에서 제공하는 LockModeType을 사용하여 구현할 수 있다.아래는 예시코드이다1.

Repository

@Repository
public interface SampleEntityRepository extends JpaRepository<SampleEntity, Long> {
}
2. Service
@Service
public class SampleEntityService {
    @Autowired
    private SampleEntityRepository sampleEntityRepository;

    @Autowired
    private EntityManager entityManager;

    @Transactional
    public SampleEntity updateDataWithPessimisticLock(Long id, String newData) {
        SampleEntity sampleEntity = entityManager.find(SampleEntity.class, id, LockModeType.PESSIMISTIC_WRITE);
        sampleEntity.setData(newData);
        entityManager.flush();
        return sampleEntity;
    }
}

  위 코드를 설명해보면 EntityManager의 find 메소드에 락 타입(LockModeType.PESSIMISTIC_WRITE)을 지정하여 데이터에 락을 걸어두고, 변경 작업이 끝난 후에 락을 해제한다. 이를 통해 다른 트랜잭션이 동시에 수정할 수 없어 동시성 처리 이슈를 방지할 수 있게 된다.

장단점

이제 낙관적 락과 비관적 락에 대해 알아보았으니 이들의 장단점에 대해서도 알아보자

낙관적 락

장점: 리소스 경쟁이 적고 락으로 인한 성능저하가 적다. 단점: 충돌 발생 시 처리해야 할 외부 요인이 존재한다.

비관적 락

장점: 충돌 발생을 미연에 방지하고 데이터의 일관성을 유지할 수 있다. 단점: 동시 처리 성능 저하 및 교착상태(Deadlock) 발생 가능성이 있다.

위에서 알아본 내용처럼 낙관적 락과 비관적 락은 각각의 사용 상황에 따라 선택할 수 있다. 충돌 발생 확률이 낮고 성능 저하를 예방하려면 낙관적 락을 사용하면 되고, 충돌을 미연에 방지하고 데이터의 일관성을 유지하려면 비관적 락을 사용하면 된다. 선택한 락 방식에 따라 JPA를 효과적으로 사용하여 동시성 처리 이슈를 해결할 수 있다.

출처: https://mozzi-devlog.tistory.com/37 [우당탕탕:티스토리] 출처: https://devoong2.tistory.com/entry/JPA-%EC%97%90%EC%84%9C-%EB%82%99%EA%B4%80%EC%A0%81-%EB%9D%BDOptimistic-Lock%EC%9D%84-%EC%9D%B4%EC%9A%A9%ED%95%B4-%EB%8F%99%EC%8B%9C%EC%84%B1-%EC%B2%98%EB%A6%AC%ED%95%98%EA%B8%B0

Trello에서 멤버는 특정 키워드로 카드를 검색하거나, 프로젝트별로 카드를 필터링하고 있습니다. 하지만 데이터가 대량으로 축적됨에 따라 카드 검색 속도가 느려질 수 있습니다. 카드 검색 속도를 향상시킬 수 있는 최적화 방법을 적용해주세요.

요구사항

• 카드 검색 속도를 향상시키기 위해 적절한 인덱스를 설계해주세요.
• 자주 사용되는 조건에 맞는 컬럼에 인덱스를 적용하여 대용량 데이터에서도 빠른 검색을 지원하세요.

발표 자료 준비

• 개선 대상 쿼리와 해당 쿼리를 선택한 이유
• 인덱스 설정 DDL 쿼리
• 쿼리 속도 비교(before, after)

1. 카드 도메인의 쿼리 3가지

카드 도메인에서 발생하는 쿼리는 3가지이다.

// 1번
Card card = cardRepository.findByIdOrElseThrow(cardId);

// 2번
List<Card> cardList = cardRepository.findAllByBoardListId(listId);

// 3번
List<Card> cards = cardRepository.findAllSearchByConditions(pageable,
                cardSearchRequestDto.getBoardId(),
                cardSearchRequestDto.getCardTitle(),
                cardSearchRequestDto.getCardExplanation(),
                cardSearchRequestDto.getEndAt(),
                cardSearchRequestDto.getCardManagerName()
        );

• 3번 쿼리 (QueryDsl)

  queryFactory.selectFrom(card)
                .leftJoin(card.boardList, boardList)
                .leftJoin(card.cardManagers, cardManager)
                .leftJoin(cardManager.user, user)
                .fetchJoin()
                .where(
                        boardIdEq(boardId),
                        cardTitleEq(cardTitle),
                        cardExplanationEq(cardExplanation),
                        endAtEq(endAt),
                        cardManagerNicknameEq(cardMangerName)
                )
                .offset(pageable.getOffset())
                .limit(pageable.getPageSize())
                .orderBy(card.modifiedAt.desc())
                .fetch();

1번 쿼리

1번 쿼리는 PK 컬럼으로 조회하기 때문에 이미 존재하는 인덱스를 통해 검색할 것이다.

2번 쿼리

2번 쿼리는 사용자가 보드에 접속할 때마다 사용되는 쿼리로 굉장히 자주 사용될 것이다. 그리고 listId 컬럼은 card 테이블에서 중복도가 낮은 컬럼이고 수정될 가능성이 낮은 컬럼이기 때문에 인덱스를 적용하기 적합하다.

3번 쿼리

3번 쿼리는 여러 조건을 통해 부합하는 데이터를 조회하는 쿼리로 각 조건들은 null일 수도 있다. 일반적으로 카드를 조회하는 대표적인 조건으로는

1) 제목과 내용에 어떤 단어나 문장이 포함되어있는 지 2) 오늘까지 마감일인 카드가 있는 지 3) 특정 보드 안에 있는 모든 카드를 검색할 때

이라고 생각한다.

1번에서는 내용의 경우는 수정이 아주 빈번하게 발생할 가능성이 높기 때문에 오히려 성능 저하를 일으킬 수 있다. 왜냐하면 수정을 할 때 인덱스에도 추가 작업을 수행해야하기 때문이다. 그래서 1번에서는 제목에만 인덱스를 적용하면 좋을 것이다.

2번은 수정의 빈도수가 적당하고, 조건으로 자주 사용될 것이라 생각하기 때문에 인덱스를 적용하면 좋을 것이다.

3번은 어차피 보드에 진입시 볼 수 있기 때문에, 특정 보드 조건은 다른 조건과 함께 사용될 가능성이 높다.

2. 인덱스 설정 및 데이터 셋팅

1) JPA 엔티티에 설정

@Getter
@Entity
@Table(name = "card", indexes = {
        @Index(name = "idx_list_Id", columnList = "list_id"),
        @Index(name = "idx_endAt", columnList = "end_at"),
        @Index(name = "idx_card_title", columnList = "card_title")
//        @Index(name = "idx_card_title_card_explanation", columnList = "card_title, card_explanation")
})
public class Card extends BaseEntity {

...

}

2) 인덱스 설정 DDL 쿼리

-- 리스트 식별자(list_id)에 대한 인덱스 생성
CREATE INDEX idx_list_Id ON card (list_id);

-- 마감일(end_at)에 대한 인덱스 생성
CREATE INDEX idx_endAt ON card (end_at);

-- 카드 제목(card_title)에 대한 인덱스 생성
CREATE INDEX idx_card_title ON card (card_title);

-- 카드 제목(card_title)과 카드 설명(card_explanation)에 대한 복합 인덱스
-- CREATE INDEX idx_card_title_card_explanation ON card (card_title, card_explanation);

3) 데이터 셋팅

-데이터 10만 건을 셋팅한다.

@Component
public class CardInitConfig {

    private final String[] array1 = {"바나나", "사과", "귤", "포도", "키위", "멜론", "두리안", "배", "감", "망고"};
    private final String[] array2 = {"하나", "둘", "셋", "넷", "다섯", "여섯", "일곱", "여덟", "아홉", "열"};
    private final String[] colors = {"빨강", "주황", "노랑", "초록", "파랑", "남색", "보라", "검정", "흰색", "회색"};

    private final WorkspaceRepository workspaceRepository;
    private final BoardRepository boardRepository;
    private final BoardListRepository boardListRepository;
    private final CardRepository cardRepository;


    public CardInitConfig(WorkspaceRepository workspaceRepository, BoardRepository boardRepository, BoardListRepository boardListRepository, CardRepository cardRepository) {
        this.workspaceRepository = workspaceRepository;
        this.boardRepository = boardRepository;
        this.boardListRepository = boardListRepository;
        this.cardRepository = cardRepository;
    }

    @PostConstruct
    @Transactional
    public void init() {

        // 워크스페이스 생성
        Workspace workspace = workspaceRepository.save(new Workspace("워크스페이스1", "환영"));

        // 리스트 생성
        List<Board> boards = new ArrayList<>();
        for (int i=0; i<1000; i++){
            for (int j=0; j<10; j++){
                Board board = new Board(workspace, "보드", "#000000", "image.jpg");
                boards.add(board);
            }

        }
        boardRepository.saveAll(boards);


        // 리스트 생성
        List<BoardList> boardLists = new ArrayList<>();
        for (int i=0; i<100; i++){
            for (int j=0; j<10; j++){
                BoardList boardList = new BoardList(boards.get(i*10+j), "리스트"+i+array1[j]);
                boardList.addArrayNumber(i);
                boardLists.add(boardList);
            }

        }
        boardListRepository.saveAll(boardLists);

        // 카드 생성
        List<Card> cardList = new ArrayList<>();
        for(int i=0; i<10; i++){
            for (int j=0; j<10; j++){
                for(int k=0; k<100; k++){
                    for (int j2=0; j2<10; j2++){
                        // 카드 생성
                        Card card = new Card("제목 "+ array1[i] + array2[j]+colors[j2],
                                "내용 "+ array1[i] + array2[j],
                                LocalDate.parse("2024-01-01").plusYears(i).plusMonths(j).plusDays(j2)
                        );
                        card.addBoardList(boardLists.get(k*10+j2));

                        // 카드 리스트에 추가
                        cardList.add(card);
                    }
                }

            }
        }
        cardRepository.saveAll(cardList);
    }

}

3. 최적화 시도

1) FK도 자동 인덱스 적용

2번 쿼리와 3번 쿼리의 3) 조건은 각 테이블의 FK로 설정되어있는 컬럼을 조건으로 조회하는데 FK는 mysql에서 기본적으로 인덱스를 적용하기 때문에 최적화가 이미 되어있다고 할 수 있다.

// 2번 쿼리
SELECT * FROM card WHERE list_id = 2;

// 3번의 3번째 조건 쿼리
SELECT * FROM card c JOIN board_list bl on c.list_id = bl.id WHERE bl.board_id = 93;

2) 제목과 내용 기준 최적화

SELECT * FROM card WHERE card_title LIKE '%바나나하나회색%';

위의 쿼리를 통해 조회했을 때 인덱스가 있을 때와 차이가 나지 않았고 어떤 경우에는 더 많은 시간이 소요되기도 했다. 이는 내용이 많고 수정이 자주 일어나는 컬럼이고 LIKE 문으로 조건을 확인하기 때문이라 생각된다.

• 제목 인덱스 적용 전

• 제목 인덱스 적용 후

SELECT * FROM card WHERE card_title LIKE '%바나나둘회색%' AND  card_explanation LIKE '%바나나%';

마찬가지로 제목과 내용을 조건으로 적용해도 차이가 발생하지 않았다.

• 제목과 내용 인덱스 적용 전

• 제목과 내용 인덱스 적용 후

3) 마감일 기준 최적화

SELECT * FROM card WHERE end_at = '2024-08-01';

위의 쿼리를 통해 조회했을 때는 인덱스의 유무에 따라 엄청난 차이가 발생했다.

4. 결론

PK와 FK는 mysql 에서 자동으로 인덱스를 적용하여 최적화한다. 내용이 길고 수정이 많은 문자열로 이루어진 컬럼에 LIKE 문을 적용하면 오히려 성능저하가 올 수 있다. 딱 떨어지는 문자나 특정 타입의 컬럼에 인덱스를 적용하면 최적화를 할 수 있다. 오히려 많은 수의 컬럼을 인덱스에 적용하려고 하면 인덱스 테이블이 거대해져서 많은 저장공간을 차지한다. 그리고 성능도 떨어진다. 인덱스가 적용된 컬럼에 INSERT, UPDATE, DELETE가 수행된다면 원본 테이블 뿐만 아니라 인덱스에도 다음과 같이 추가 작업을 수행해줘야 하기 때문에 3가지 쿼리가 자주 발생하는 컬럼은 적용하면 안된다.

intro 프로젝트를 하는 과정에서 많은 데이터의 상태를 모두 변경해야되는 문제에 직면했다.

예를 들어, 사람들이 신고한 사용자의 id를 하루동안 받았다가 한 번에 처리할 때나 쿠폰이 만료 기간이 지나서 한번에 상태를 만료로 변경해야 할 때가 있다.

문제 발생

수 백만 건의 데이터를 수정하려니 수백 만 개의 sql문이 데이터베이스에 날아가는 문제가 발생했다.

보통은 데이터를 수정할 때, 데이터베이스에서 특정 데이터를 가져와서 해당 데이터의 상태를 변경하고 저장하는 단건 수정 방식을 사용한다. 그런데 이 방법을 쓰면 수정하려는 데이터가 수백만, 수천만 개가 되면 데이터베이스가 마비될 것이다.

@Transactional
    public void reportUsers(List<Long> userIds) {
        for (Long userId : userIds) {
            User user = userRepository.findById(userId).orElseThrow(() -> new IllegalArgumentException("해당 ID에 맞는 값이 존재하지 않습니다."));

            user.updateStatusToBlocked();

            userRepository.save(user);
        }
    }

위에 경우에 백만 개를 처리한다고 하면 백만 번의 select문 처리와 백만 번의 update문 처리가 이루어져야 된다.

그래서 위 문제를 해결하기 위해 한 번의 데이베이스 접근으로 모두 수정하는 방법을 찾아보았다.

해결방법

벌크 연산을 사용하자!

벌크 연산은 데이터베이스에서 UPDATE, DELETE 시 대량의 데이터를 한 번에 처리하기 위한 작업이다. 즉, JPA에서 벌크 연산은 단 건 데이터를 변경(더티 체킹)하는 것이 아닌, 여러 데이터에 변경 쿼리를 날리는 작업을 말한다.

@Modifying을 변경이 일어나는 쿼리와 함께 사용해야 JPA에서 변경 감지와 관련된 처리를 생략하고 더 효율적인 실행이 가능하다.

@Modifying(clearAutomatically = true)
@Query("UPDATE User u SET u.status = :status where u.id IN :userIds")
void updateStatusByIds(@Param("status") String status, @Param("userIds") List<Long> userIds);

where ... in ... 조건으로 수정할 데이터들을 정하고 set 으로 수정할 내용으로 수정한다. 여기서 중요한 것은 Modifying 어노테이션이다.

JPA에서는 원래 수정할 때 영속성 컨텍스트가 변화를 감지(1차 캐시와 비교)하여 업데이트를 데이터베이스에 보내게 되는데, 위의 경우는 직접 쿼리문을 보내기 때문에 영속성 컨텍스트와 데이터베이스의 정보가 일치하지 않는다. 그래서 잘못해서 영속성 컨텍스트에 있는 데이터를 조회하면 실제 데이터와 다른 정보를 얻게 되는 불상사가 생기게 된다.

Modifying 어노테이션은 그래서 영속성 컨텍스트를 초기화하는 방법을 제공하는데 (clearAutomatically = true)라는 옵션을 통해 초기화할 수 있게 해준다.

...

entityManager.flush();
entityManager.clear();

기본적으로는 영속성 컨텍스트를 초기화 해주는 방법이 있다.

@Transactional
    public void reportUsers(List<Long> userIds) {

//        List<User> users = userRepository.findAllById(userIds).stream().toList();
//
//        if(users.isEmpty()) {
//            throw new IllegalArgumentException("해당 ID에 맞는 값이 존재하지 않습니다.");
//        }

        // 위의 user 조회가 없어도 동작함
        // 해당 id의 레코드가 없어도 실행됨
        userRepository.updateStatusByIds("BLOCKED", userIds);
    }

이 위의 코드는 한 번의 select문과 한 번의 update문으로 많은 데이터를 한 번씩의 접근으로 해결했다.

주의점

변경 쿼리 동기화 문제

JPA에서는 1차 캐시라는 기능이 있다. 1차 캐시를 간단하게 설명하면 영속성 컨텍스트에 있는 1차 캐시를 통해 엔티티를 캐싱하고, DB의 접근 횟수를 줄임으로써 성능 개선 한다.

그런데 @Modifying과 @Query 를 사용한 벌크 연산에서 1차 캐시와 관련하여 문제가 발생한다. JPA에서 조회를 실행할 시에 1차 캐시를 확인해서 해당 엔티티가 1차 캐시에 존재한다면 DB에 접근하지 않고, 1차 캐시에 있는 엔티티를 반환한다. 하지만 벌크 연산은 1차 캐시를 포함한 영속성 컨텍스트를 무시하고 바로 Query를 실행하기 때문에 영속성 컨텍스트는 데이터 변경을 알 수가 없다. 즉, 벌크 연산 실행 시, 1차 캐시(영속성 컨텍스트)와 DB의 데이터 싱크가 맞지 않게 되는 것이다.

그래서 데이터를 사용하기 전에 영속성 컨텍스트를 비워주는 작업이 필요한데, @Modifying의 clearAutomatically=true 속성을 사용해 변경 후 자동으로 영속성 컨텍스트를 초기화 할 수 있다.  해당 속성을 추가하게 되면, 조회를 실행할 때 1차캐시에 해당 엔티티가 존재하지 않기 때문에 DB 조회 쿼리를 실행하게 된다. ( 데이터 동기화 문제를 해결 )

트랜잭션 관리

@Modifying 애노테이션은 기본적으로 @Transactional과 함께 사용된다. 변경 작업은 트랜잭션 내에서 실행되어야 하며, 완료되지 않은 변경 작업이 여러 작업에 영향을 줄 수 있기 때문이다. 이를 통해 데이터베이스에 대한 변경 작업을 수행할 때 원자성(Atomicity), 일관성(Consistency), 독립성(Isolation), 지속성(Durability)을 보장할 수 있게 된다.