짱정연의 짱개발자 도전기

코테를 위한 Java 문법 정리

짱정연 — Thu, 24 Oct 2024 23:33:28 +0900

평소 C++을 코테 주 언어로 사용하는데, 백엔드 직무의 경우 Java로 코테를 응시해야 하는 경우가 있어 ~~벼락치기용으로~~ Java 문법을 정리하고자 한다. (틈틈이 업데이트 중)

입출력

import java.io.*;
import java.util.*;

public class Main {
    public static void main(String[] args) throws IOException {
        BufferedReader br = new BufferedReader(new InputStreamReader(System.in));
        StringTokenizer st = new StringTokenizer(br.readLine());

        int n = Integer.parseInt(st.nextToken());
        int m = Integer.parseInt(st.nextToken());
        int k = Integer.parseInt(st.nextToken());
        
      	String str = br.readLine();

        System.out.println(n);
        System.out.println(m);
        System.out.println(k);
        System.out.println(str);
    }
}

BufferedReader가 Scanner보다 빠르다.
정수 타입 변수인 n, m, k를 저장할 때 str.nextToken()의 결과는 String 타입이고, 숫자 타입으로 저장하기 위해 parseInt 과정이 필요하다.

length, length(), size()

length: 배열의 길이
length(): 문자열(String)의 길이
size(): 컬렉션의 요소의 개수

int[] numbers = {1, 2, 3, 4, 5};
System.out.println(numbers.length);

String text = "Hello, World!";
System.out.println(text.length());

ArrayList<String> list = new ArrayList<>();
list.add("A");
list.add("B");
System.out.println(list.size());

String

문자열 뒤집기

String str = "abcde";
StringBuffer sb = new StringBuffer(str);
str = sb.reverse().toString();

문자열 비교

==의 경우 참조 주소를 비교하므로, 값을 비교할 때는 equals()를 사용하자

2차원 ArrayList를 배열로 변환

int[][] answer = new int[arr1.length][arr1[0].length];

for (int i = 0; i < result.size(); i++) {
    for (int j = 0; j < result.get(0).size(); j++) {
        answer[i][j] = result.get(i).get(j);
    }
}

ArrayList 정렬

// 오름차순
Collections.sort(list);

// 내림차순
Collections.sort(list, Collections.reverseOrder());

// 커스텀 정렬 with 람다식
list.sort((Integer a, Integer b) -> {
	return a - b;
});

Pair

자바에는 C++의 pair나 tuple 같은 자료형을 제공하지 않으므로 클래스로 직접 구현해야 한다.

static class Pair {
	int x;
    int y;
    
    Pair(int x, int y) {
    	this.x = x;
        this.y = y;
    }
}

Queue<Pair> q = new LinkedList<>();
q.offer(new Pair(1, 2));

큐와 우선순위 큐

offer(): 원소 추가, 값 추가 실패 시 false 반환
poll(): 첫 번째 값을 반환하고 제거, 비어있으면 null
peek(): 값을 꺼내지 않고 확인만

add, remove는 실패 시 에러가 발생하므로 offer, poll을 사용하자. 큐와 우선순위 큐 둘 다 함수는 동일하다.

큐를 구현할 때 구현체로 LinkedList와 ArrayDeque를 사용할 수 있지만, 메모리와 속도 측면에서 ArrayDeque가 더 많은 장점을 가지고 있다.

// 큐 선언
Queue<Integer> q = new ArrayDeque<>();

// 우선순위 큐 선언 1 (작은 숫자 먼저)
PriorityQueue<Integer> pq = new PriorityQueue<>();

// 우선순위 큐 선언 2 (큰 숫자 먼저)
PriorityQueue<Integer> pq = new PriorityQueue<>(Collections.reverseOrder());

q.offer(1);
q.offer(6);
q.offer(2);

while(!q.isEmpty()) {
	System.out.println(q.poll());
}

HasmMap 순회

Map<String, String> map = new HashMap<>();

for (String key : map.keySet()) {
	map.get(key);
}

리스트 회전

List<Integer> arr = new ArrayList<>();
for (int i = 0; i < 5; i++) {
	arr.add(i);
}

System.out.println(arr); // [0, 1, 2, 3, 4]
Collections.rotate(arr, 1);
System.out.println(arr); // [4, 0, 1, 2, 3]

[C++] 트라이(Trie)

짱정연 — Tue, 22 Oct 2024 12:11:53 +0900

1. 트라이(Trie)

트라이(Trie)는 어떤 문자열이 특정 문자열에 해당되는지 알아낼 때 효율적으로 사용할 수 있는 자료구조이다.

트라이는 문자열 집합 내에서 중복되는 접두사들에 대응되는 노드들이 서로 연결된 트리이다.

루트는 빈 문자열로 시작하여, 리프 노드는 문자열이 된다. 만약 위와 같은 트라이에서 'ten'이라는 단어를 찾을 때, 루트 노드에서 시작하여 t를 찾는다. 그 후 자식 노드들 중 e를 찾고, 또 n을 찾는다.

리프 노드까지 도달했다면, 해당 문자열이 우리가 찾던 문자열이 되고 탐색이 완료된다.

트라이는 모든 문자열을 O(log n)으로 탐색이 가능하여 문자열 탐색이 굉장히 빠르다는 장점이 있다.

하지만, 알파벳은 총 26개이므로 문자열을 포함하는 각 노드는 26개의 자식 노드 포인터를 가지게 되어 메모리를 많이 사용한다. 그러므로, 공간복잡도를 고려하여 문제에서 사용해야 한다.

2. C++로 트라이 구현

트리 형태를 나타내기 위해서 구조체로 각 노드를 표현해야 한다. 그리고 트라이에 문자열을 삽입하는 insert 함수와, 트라이에서 문자열을 찾는 find 함수가 필요하다.

노드 구조체
- 26개의 자식 노드 포인터와 finish 여부(리프 노드에 도달했는지)를 변수로 가짐
- 자식 노드 포인터는 O(1) 탐색을 위해 정적 배열이나 해시맵으로 관리하면 좋음
insert
- 루트부터 단어의 글자를 차례대로 탐색
- 현재 노드 자식 중 해당 자식이 있으면 이동, 없다면 새로운 자식을 생성
- 단어 삽입 후 마지막 노드에 입력된 단어 정보를 추가
find
- 루트에서 시작하여 차례대로 탐색
- 현재 노드 자식 중 해당 자식이 있다면 자식으로 이동, 없으면 탐색 실패

#include <iostream>
#include <vector>
#include <unordered_map>

using namespace std;

struct TrieNode {
    // 해시맵으로 자식 노드 포인터를 구현
    unordered_map<char, TrieNode*> children;
    // 리프 노드에 도달했는지
    bool finish;

    // 생성자
    TrieNode() : children(), finish(false) {}

    void insert(string& key, int idx) {
        // 문자열의 마지막 글자에 도달
        if (idx == key.length() - 1) finish = true;
        else {
            // 현재 탐색 중인 글자
            char next = key[idx];
            // 자식 노드에 없다면 새로운 자식 생성
            if (children[next] == nullptr) children[next] = new TrieNode;

            // 다음 글자 탐색
            children[next]->insert(key, idx+1);
        }
    }

    // 접두사로 검색되면 true 리턴
    bool findPrefix(string& key, int depth) {
        // 문자열의 마지막 글자에 도달
        if (depth == key.length()-1) return true;

        // 현재 탐색 중인 글자
        char next = key[depth];
        // 자식 노드에 없다면 탐색 실패
        if (children[next] == nullptr) return false;

        // 다음 글자 재귀 탐색
        return children[next]->findPrefix(key, depth+1);
    }

    // 완전히 일치하는 단어 단위로 찾아 true 리턴
    bool findString(string& key, int depth) {
        // 문자열의 마지막 글자에 도달 + 리프 노드에 도달 = 완전히 일치하는 단어
        if (depth == key.length()-1 && finish) return true;
        // 문자열의 마지막 글자에 도달 + 리프 노드가 아님 = 접두사
        if (depth == key.length()-1 && !finish) return false;

        char next = key[depth];
        // 현재 글자의 자식 노드가 없어 탐색 실패
        if (children[next] == nullptr) return false;

        // 다음 글자 재귀 탐색
        return children[next]->findString(key, depth+1);
    }
};

int main() {
    ios::sync_with_stdio(false);
    cin.tie(NULL);
    cout.tie(NULL);

    vector<string> words = { "what", "when", "yours", "apple", "her", "his", "you" };

    TrieNode root;
    for (string word : words) {
        root.insert(word, 0);
    }

    string target = "wh";

    if (root.findPrefix(target, 0)) {
        cout << target << "가 검색 결과에 있습니다.\n";
    } else {
        cout << target << "가 검색 결과에 없습니다.\n";
    }

    if (root.findString(target, 0)) {
        cout << target << "가 검색 결과에 있습니다.\n";
    } else {
        cout << target << "가 검색 결과에 없습니다.\n";
    }

    return 0;
}

Reference

공유 락(Shared Lock)과 배타 락(Exclusive Lock), 그리고 교착 상태(Deadlock)

짱정연 — Fri, 18 Oct 2024 12:19:37 +0900

1. 들어가며

트랜잭션 격리 수준과 격리 수준에 따른 문제점

1. 트랜잭션 격리성트랜잭션은 데이터베이스에서 하나의 논리적 기능을 수행하기 위한 작업의 단위를 말한다.트랜잭션에는 ACID라는 네 가지 특징이 있다. 그 중 격리성(Isolation)은 트랜잭션 수행

leeeeeyeon-dev.tistory.com

이전에 트랜잭션 격리 수준과 그에 따른 문제점에 대해 살펴보며, 트랜잭션이 동시에 수행될 때 발생할 수 있는 문제점에 대해 알아보았다.

트랜잭션들이 동시에 수행될 때, 일관성을 해치는 것을 방지하기 위해 데이터 접근을 제어하는 동시성 제어가 필요하다.

동시성 제어를 위해 데이터에 잠금을 거는 락 기법을 사용할 수 있다. 데이터베이스에 따라 다양한 락이 존재하지만 크게 공유 락과 배타 락으로 나눌 수 있다.

2. 공유 락(Shared Lock, S-Lock)

읽기 락(Read Lock)으로도 불린다.

공유 락이 걸린 데이터에 대해서는 읽기 연산만 실행 가능하며, 쓰기 연산을 불가능하다.

또한, 공유 락이 걸린 데이터에 대해서는 다른 트랜잭션도 공유 락을 획득할 수 있다. 즉, 두 트랜잭션이 해당 데이터를 동시에 읽는 것이 가능하다.

하지만, 공유 락이 걸린 데이터에 배타 락을 거는 것을 불가능하다.

3. 배타 락(Exclusive Lock, X-Lock)

쓰기 락(Write Lock)으로도 불린다.

배타 락을 획득한 트랜잭션은 해당 데이터에 대해 읽기 연산과 쓰기 연산 모두 실행할 수 있다.

하지만, 다른 트랜잭션은 배타 락이 걸린 데이터에 대해 읽기 연산이나 쓰기 연산을 수행할 수 없다. 즉, 배타 락을 실행한 트랜잭션만 해당 데이터에 대한 독점권을 가지는 것이다.

공유 락과 배타 락의 양립 가능성을 표로 정리하면 아래와 같다.

	S-Lock	X-Lock
S-Lock	⭕️	❌
X-Lock	❌	❌

4. 블로킹(Blocking)과 교착 상태(Deadlock)

다른 트랜잭션에 의해 락이 걸려서 데이터에 접근하지 못할 때, 즉 두 트랜잭션의 락이 양립 불가능할 때 해당 트랜잭션은 작업을 진행하지 못하고 대기 상태가 되며, 이를 블로킹(Blocking) 상태라고 한다.

만약 두 개의 트랜잭션이 각각의 트랜잭션이 가지고 있는 데이터의 Lock 획득을 시도하면, 둘 다 블로킹 상태가 되어 무한 대기하게 되는 문제가 발생하며, 이를 교착 상태(Deadlock)이라고 한다.

아래 예시를 보자.

교착 상태가 발생하는 예시 상황

트랜잭션 1이 리소스 1에 대한 배타 락을 획득한다
트랜잭션 2가 리소스 2에 대한 공유 락을 획득한다
트랜잭션 1이 리소스 1을 점유하고 있는 상태에서, 리소스 2에 대한 배타 락 획득을 시도하지만 얻을 수 없어 블로킹 상태에 진입한다
트랜잭션 2가 리소스 2를 점유하고 있는 상태에서, 리소스 1에 대한 공유 락 획득을 시도하지만 얻을 수 없어 블로킹 상태에 진입한다

5. 교착 상태 해결 방법

교착 상태를 해결할 수 있는 방법은 예방 기법, 회피 기법(Wait-Die 방식, Wound-Wait 방식), 낙관적 병행 기법, 빈도 낮추기가 있다.

5-1. 예방 기법

트랜잭션이 시작되기 전에 필요한 모든 데이터에 대한 락을 획득한다.

하지만 데이터가 많이 필요한 경우, 모든 데이터를 잠궈야 하므로 트랜잭션의 병행성이 떨어진다. 또한, 몇몇 트랜잭션은 계속 작업을 처리하지 못하는 기아 상태가 발생할 수 있다.

5-2. 회피 기법

자원을 할당할 때 타임스탬프를 활용하여 교착 상태가 일어나지 않도록 회피한다. 회피 방법으로는 Wait-Die 방식과 Wound-Wait 방식이 있다.

Wait-Die 방식

다른 트랜잭션이 데이터를 점유하고 있을 때 먼저 들어온 트랜잭션이라면 대기(wait)하고, 나중에 들어온 트랜잭션이라면 포기(die)하고 나중에 다시 요청한다.

오래된 프로세스에게 대기의 기회를 제공하고, 최신 프로세스는 자주 복귀하기 때문에 오버헤드의 가능성이 있다.

Wound-Wait 방식

다른 트랜잭션이 데이터를 점유하고 있을 때 먼저 들어온 트랜잭션이 접근하면 선점(wound)하고, 나중에 들어온 트랜잭션이라면 대기(wait)한다.

5-3. 낙관적 병행 기법

트랜잭션이 실행되는 동안에는 검사를 하지 않고, 트랜잭션이 다 실행된 이후에 검사하여 문제가 있다면 되돌린다.

5-4. 빈도 낮추기

교착상태의 빈도를 낮추기 위해 아래와 같은 방법을 시도한다.

트랜잭션을 자주 커밋
트랜잭션들이 동일한 테이블 순으로 접근
읽기 잠금의 사용을 피한다. (SELECT ~ FOR UPDATE)
테이블 단위의 락을 획득해 갱신을 직렬화
- 테으블의 복수행을 복수의 연결에서 순서 없이 갱신하면 교착 상태가 자주 발생한다

Reference

[Packy] Github Actions과 Flyway를 사용한 엔티티-테이블 매핑 검증 자동화

짱정연 — Sun, 1 Sep 2024 16:32:39 +0900

1. 들어가며

Spring boot 프로젝트에 Flyway 도입하기 (feat. 기존 데이터가 있을 경우)

Flyway란? Flyway는 데이터베이스의 형상 관리를 목적으로 하는 오픈소스 마이그레이션 툴이다. Flyway를 통해 변경 사항을 추적하고, 업데이트나 롤백을 보다 쉽게 할 수 있다. 우리가 개발하며 필수

leeeeeyeon-dev.tistory.com

지금 운영하고 있는 패키 프로젝트에서는 Flyway를 사용하여 DDL 생성을 자동화하고 있다.

Flyway를 사용하면 엔티티와 테이블 매핑이 일치하지 않을 때 애플리케이션 실행에 실패한다. 그렇기 때문에 테이블 컬럼을 수정하지 않아 나중에 서비스를 운영하다가 비즈니스 로직이 실패하는 문제 상황을 예방할 수 있다.

애플리케이션 실행 실패 예시

나는 해당 기능을 활용하여 개발/운영 환경을 배포하기 전에 로컬에서 profile을 dev와 prod로 변경한 뒤 애플리케이션을 실행해보며 배포 실패를 방지하고 있다. 최근에는 해당 단계를 깜빡하여 개발 환경 배포 시 애플리케이션 실행에 실패한 경험이 있다 ㅠㅠ

이번 포스트에서는 Github Actions에서 애플리케이션 실행을 대신하여 이러한 반쪽짜리 자동화를 발전시켜보자 !

2. FlywayApplication

참고로 패키는 멀티 모듈 프로젝트로 구성되어 있으며, 실제 SpringApplication이 실행되는 모듈은 api 모듈이다.

기존에는 flyway 관련 설정을 domain 모듈에서 진행했는데 해당 모듈은 api 모듈과 의존성을 가지고 있어 api 모듈과 독립된 flyway 모듈을 만들어 해당 모듈로 flyway 관련 설정을 옮겼다.

@EntityScan(basePackages = {"com.dilly.*"})
@SpringBootApplication
public class FlywayApplication {

    public static void main(String[] args) {
        System.setProperty("spring.config.name",
            "application-domain, application-flyway");

        ConfigurableApplicationContext ctx = SpringApplication.run(FlywayApplication.class, args);
        ctx.close();
    }
}

Github Actions에서 엔티티-테이블 매핑 검증 자동화를 위해 사용할 애플리케이션이다. 해당 애플리케이션은 검증에만 사용되고 계속 실행될 필요가 없으므로 close 메서드로 애플리케이션을 종료시켜주었다.

3. Github Actions 스크립트 수정

name: packy API Server - CI

on:
  pull_request:
    branches:
      - main
      - develop

permissions:
  contents: read

jobs:
  CI:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
        with:
          token: ${{ secrets.ACTION_TOKEN }}
          submodules: true

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

      - name: Setup Gradle
        uses: gradle/actions/setup-gradle@v4

      - name: Run build Flyway Module
        run: ./gradlew clean packy-flyway:build

      - name: Run FlywayApplication
        run: java -Dspring.profiles.active=${{ env.PROFILE }} -jar ./packy-flyway/build/libs/packy-flyway-0.0.1-SNAPSHOT.jar
        env:
          PROFILE: ${{ github.ref == 'refs/heads/main' && 'prod' || 'dev' }}

      - name: Run build with Gradle Wrapper
        run: ./gradlew clean build --parallel

      - name: Report to CodeCov
        uses: codecov/codecov-action@v4
        with:
          token: ${{ secrets.CODECOV_TOKEN }}
          file: 'packy-support/build/reports/jacoco/testCodeCoverageReport/testCodeCoverageReport.xml'

위 step 중 Run build Flyway Module, Run FlywayApplication이 매핑 검증 단계이고 나머지는 기존 CI 스크립트에 있던 코드이다.

gradle build를 할 경우 모든 모듈이 빌드되기 때문에 flyway 모듈만 빌드하도록 하였으며, dev 또는 prod로 profile을 설정하여 FlywayApplication을 실행했다.

4. 결과

엔티티와 테이블 매핑이 일치하지 않는 상황을 만들기 위해 Member 엔티티에 임의로 test라는 컬럼을 추가하고 워크플로우를 실행시켜보았다.

@Entity
public class Member extends BaseTimeEntity {
	@Id
	@GeneratedValue(strategy = IDENTITY)
	private Long id;
    
    // 중략 ...

	String test;
}

스키마 불일치로 인해 어플리케이션 실행에 실패하여 워크플로우가 실패한 모습을 볼 수 있다.

5. 마치며

이제는 직접 SpringApplication을 실행해보는 작업을 하지 않아도 배포 이전에 엔티티-테이블 스키마가 일치하는지 확인할 수 있도록 자동화 단계를 추가하였다 :)

기존에 Flyway를 도입한 것도 자동화였지만, 일부 수동 작업이 필요한 자동화였다. 이번 경험을 통해 이미 자동화를 적용한 영역에서도 불편함을 찾아 자동화 단계를 보다 개선할 수 있음을 배웠고, 앞으로도 자동화를 거친 단계에 수동으롤 반복되는 작업이 더 없는가 다시 고민해보고 개선하는 자세로 프로젝트를 관리해야겠다.

Reference

https://mindybughunter.com/flyway%EC%99%80-github-actions%EC%9D%84-%ED%86%B5%ED%95%9C-entity-table-%EB%A7%A4%ED%95%91-%EA%B2%80%EC%A6%9D-%EC%9E%90%EB%8F%99%ED%99%94/

[Packy] 선물박스 열기 동시성 문제 해결 2 - Redisson으로 분산락 구현

짱정연 — Thu, 29 Aug 2024 10:55:24 +0900

1. 들어가며

[Packy] 선물박스 열기 동시성 문제 해결 1 - 분산 락을 선택한 이유

1. 들어가며 패키에서는 선물박스를 받게 되면 Receiver 테이블에 받은 유저 ID와 선물박스 ID를 저장한다.지금은 하나의 선물박스를 1명만 받을 수 있지만(PRIVATE), 나중에 하나의 선물박스를 여러

leeeeeyeon-dev.tistory.com

저번 포스트에서 선물박스 열기 로직에 발생할 수 있는 동시성 문제에 대해 알아보고, 이를 해결할 수 있는 방법에 대해 찾아본 뒤 최종적으로 Redis의 Message Broker 방식을 활용한 분산 락으로 해결하기로 결정하였다.

이번 포스트에서는 Redisson으로 분산 락을 구현하는 과정을 코드와 함께 살펴보자.

2. 의존성 추가

Redisson 라이브러리를 build.gradle에 추가해준다

implementation 'org.redisson:redisson-spring-boot-starter:3.34.1'

다른 테크 블로그를 참고하여 구현하며 3.27.0 버전을 사용하였는데 아래와 같이 빈을 생성하지 못하는 에러가 발생했는데 공식 문서 상 최신 버전은 3.34.1로 업그레이드하여 해결하였다.

Error creating bean with name 'redissonClient' defined in class path resource [com/dilly/global/config/RedissonConfig.class]: Failed to instantiate [org.redisson.api.RedissonClient]: Factory method 'redissonClient' threw exception with message: 'io.netty.resolver.dns.DnsNameResolverBuilder io.netty.resolver.dns.DnsNameResolverBuilder.socketChannelType(java.lang.Class, boolean)'

3. RedissonConfig

RedissonClient를 사용하기 위한 설정을 빈으로 등록한다.

@Configuration
public class RedissonConfig {

    @Value("${spring.data.redis.host}")
    private String host;

    @Value("${spring.data.redis.port}")
    private int port;

    private static final String REDISSION_HOST_PREFIX = "redis://";

    @Bean
    public RedissonClient redissonClient() {
        Config config = new Config();
        String address = REDISSION_HOST_PREFIX + host + ":" + port;
        config.useSingleServer().setAddress(address);

        return Redisson.create(config);
    }
}

4. RedissonLock

AOP와 Spring AOP에 대해 알아보자

1. AOP란? AOP는 Aspect Oriented Programming의 약자로, 관점 지향 프로그래밍을 의미한다. 핵심적인 비즈니스 로직으로부터 횡단 관심사를 분리하는 것을 목적으로 한다. 로깅, 보안, 트랜잭션 처리와 같

leeeeeyeon-dev.tistory.com

분산 락 코드를 Service 클래스에 작성할 경우 비즈니스 로직(선물박스 열기)과 관련이 없는 코드가 섞이게 되고, 추후 다른 로직에 분산 락을 적용할 경우 중복되는 코드가 생길 수 있어 AOP를 활용하여 분산 락을 구현할 것이다.

AOP에 대한 개념은 이전에 정리해둔 포스트가 있으니 위에 있는 포스트를 참고하자!

@RedissonLock이라는 커스텀 어노테이션을 만들고, 해당 어노테이션이 있는 메서드가 실행되면 AOP를 수행하도록 한다.

@Target({ElementType.METHOD, ElementType.TYPE})
@Retention(RetentionPolicy.RUNTIME)
@Documented
public @interface RedissonLock {

    String value(); // 락의 이름
    TimeUnit timeUnit() default TimeUnit.MILLISECONDS; // 시간 단위
    long waitTime() default 5_000L; // 락 획득을 위해 waitTime만큼 대기
    long leaseTime() default 5_000L; // 락 획득 후 leaseTime만큼 락 유지
}

Redisson Lock은 value, timeUnit, waitTime, leaseTime 네 가지 값이 있으며 각 값의 역할은 주석에 적은 것과 같다.

value 외의 값들은 값을 명시하지 않을 경우 기본값을 사용할 수 있도록 기본값을 지정해주었다.

waitTime이 짧을 경우 선착순에 들었지만 대기 시간이 짧아 기회가 박탈될 수 있고, leaseTime이 짧을 경우 로직이 진행되다가 락이 해제되는 경우가 발생할 수 있으므로 적절하게 시간을 조절해주어야 한다.

5. RedissonLockAspect

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

    @Value("${spring.profiles.active}")
    private String profilePrefix;

    private final RedissonClient redissonClient;
    private final AopForTransaction aopForTransaction;

    @Around("@annotation(com.dilly.global.aop.RedissonLock)")
    public Object redissonLock(ProceedingJoinPoint joinPoint) throws Throwable {
        MethodSignature signature = (MethodSignature) joinPoint.getSignature();
        Method method = signature.getMethod();
        RedissonLock annotation = method.getAnnotation(RedissonLock.class);

        String lockKey =
            profilePrefix + ":" + method.getName() + CustomSpringELParser.getDynamicValue(
            signature.getParameterNames(), joinPoint.getArgs(), annotation.value());

        RLock lock = redissonClient.getLock(lockKey);

        try {
            boolean lockable = lock.tryLock(annotation.waitTime(), annotation.leaseTime(),
                annotation.timeUnit());
            if (!lockable) {
                log.info("Lock 획득 실패: {}", lockKey);
                throw new ConcurrencyFailedException();
            }

            log.info("Lock 획득 성공: {}", lockKey);
            return aopForTransaction.proceed(joinPoint);
        } catch (InterruptedException e) {
            log.info("에러 발생");
            throw e;
        } finally {
            if (lock != null && lock.isHeldByCurrentThread()) {
                log.info("Lock 해제");
                lock.unlock();
            }
        }
    }
}

Redisson이라는 라이브러리에 분산 락 메커니즘과 재시도 로직이 구현되어 있기 때문에 해당 라이브러리를 사용하여 분산 락을 구현할 수 있다. 우리는 락 획득 시도, 락 획득 성공 후 처리, 락 획득 실패 로직을 구현하면 된다.

AOP를 활용하여 구현한 분산 락 로직이다. 락 획득 시도, 락 획득 성공 후 처리, 락 획득 실패 로직을 포함하고 있다.

서버비를 아끼기 위해 ㅠuㅠ ElastiCache를 하나만 사용하려고 하기 때문에 profile 값(dev, prod)를 lockKey 이름에 포함하여 구분하였다.

CustomSpringELParser는 Spring 표현식을 좀 더 자세하게 파싱할 수 있도록 만든 파서로, 구체적인 코드는 아래를 확인하면 된다.

redissonClient.getLock()으로 락을 획득하고, tryLock()으로 락 획득을 시도한다.

락 획득에 성공했다면 선물박스 열기 로직을 수행하고, 락 획득에 실패했으면 ConcurrencyFailedException이라는 커스텀 비즈니스 예외를 던지도록 하였다.

AOP의 기본 proceed() 메소드를 사용하지 않고, ApoForTransaction 클래스의 proceed() 메소드를 사용했음을 주의하자. 관련하여 자세한 내용은 잠시 후 나온다.

마지막으로 finally 구문에서는 만약 락을 획득한 상태라면 락을 해제하도록 하였다.

6. CustomSpringELParser

public class CustomSpringELParser {

    public static Object getDynamicValue(String[] parameterNames, Object[] args, String key) {
        SpelExpressionParser parser = new SpelExpressionParser();
        StandardEvaluationContext context = new StandardEvaluationContext();

        for (int i = 0; i < parameterNames.length; i++) {
            context.setVariable(parameterNames[i], args[i]);
        }

        return parser.parseExpression(key).getValue(context);
    }
}

7. AopForTransaction

@Component
public class AopForTransaction {

    @Transactional(propagation = Propagation.REQUIRES_NEW)
    public Object proceed(ProceedingJoinPoint joinPoint) throws Throwable {
        return joinPoint.proceed();
    }

}

@RedissonLock이 선언된 메소드는 트랜잭션 옵션을 REQUIRES_NEW로 지정하여 부모 트랜잭션의 유무와 관계없이 별도의 트랜잭션으로 동작하여 트랜잭션이 커밋된 이후 락이 해제되도록 한다. 그 이유는 아래 그림으로 확인할 수 있다.

왼쪽은 락의 해제 시점이 커밋보다 먼저인 경우, 오른쪽은 락의 해제 시점이 커밋 이후인 경우이다.

출처: https://helloworld.kurly.com/blog/distributed-redisson-lock/

왼쪽 시나리오에서는 Client 1과 Client 2가 동시에 재고를 차감했으므로 2개가 차감되어야 하는데 1개만 차감되어 데이터 정합성이 깨지는 문제가 발생하였다.

반면 오른쪽 시나리오에서는 정상적으로 2개가 차감되는 것을 확인할 수 있다.

8. 기존 테스트 코드에 분산 락 적용되지 않도록 하는 방법

패키 프로젝트의 테스트 코드는

테스트의 편리함을 위해 @Transactional 어노테이션을 사용
비즈니스 계층(Service)와 영속성 계층(Repository)을 합쳐 통합 테스트를 진행하고 있다

라는 특징이 있다. 통합 테스트를 위해 선물박스 접근 권한이나 삭제 로직을 테스트할 때 openGiftBox 메소드(선물박스 열기 로직)로 미리 선물박스를 저장한다.

하지만 openGiftBox 메소드를 사용하던 기존 테스트 코드들이 분산 락 도입 이후 실패하는 상황이 발생하였다.

AopForTransaction에서 별도의 트랜잭션을 사용하면서 테스트 레이어의 트랜잭션과 openGiftBox 메소드의 트랜잭션 범위가 달라져 발생한 문제인 것 같다. 그래서 기존 테스트 코드에서는 분산 락을 적용하지 않도록 결정하였다.

만약 동시성이나 분산 락 관련 로직을 테스트할 일이 있으면 GiftBoxConcurrencyTest 클래스나 새로운 테스트 클래스에서 테스트를 진행하고, 통합 테스트에서는 단일 요청을 기준으로 테스트 코드를 작성하는 방식으로 테스트 코드를 운영하고자 한다.

@ConditionalOnExpression("${ableRedissonLock:true}")
public class RedissonLockAspect {
	// 중략 ...
}

@ConditionalOnExpression 어노테이션을 사용하여 ableRedissonLock라는 환경변수가 true일 때만 동작하도록 하였다.

만약 속성값이 없으면 true가 default 값이 된다.

그리고 통합 테스트를 관리하는 추상 클래스인 IntegrationTestSupport 클래스에서는 @TestPropertySource 어노테이션을 사용하여 ableRedissonLock을 false로 지정해주었다.

@TestPropertySource(properties = "ableRedissonLock=false")
public abstract class IntegrationTestSupport {
	// 중략 ...
}

9. 마치며

저번 포스트에서 알아본 동시성 문제와 분산 락에 이어 이번 포스트에서는 직접 코드로 분산 락을 구현해보았다.

멀티 스레드, 락, 트랜잭션, AOP 등 다양한 CS와 Spring 이론이 필요했던 문제 해결 과정이었다. 특히 트랜잭션 관련 삽질을 많이 하면서 트랜잭션에 대한 공부가 많이 되었던 시간이었다.

그 중 예시로, 테스트 코드를 작성하며 테스트 코드의 @Transactional과 Service의 @Transactional이 다르다는 충격적인 사실을 배울 수 있었다. 아래 글이 테스트 코드에서의 @Transactional 어노테이션 사용에 대해 정리가 잘 되어 있어 정말 도움이 되었다.

@Transactional 이모저모 1 - 테스트코드와 @Transactional

이 포스팅 보고 테스트 짰다면 얼마나 좋았을까?

velog.io

Reference

[Packy] 선물박스 열기 동시성 문제 해결 1 - 분산 락을 선택한 이유

짱정연 — Wed, 28 Aug 2024 13:25:15 +0900

1. 들어가며

패키 ERD 일부

패키에서는 선물박스를 받게 되면 Receiver 테이블에 받은 유저 ID와 선물박스 ID를 저장한다.

지금은 하나의 선물박스를 1명만 받을 수 있지만(PRIVATE), 나중에 하나의 선물박스를 여러 유저가 받을 수 있는 상황(SEMI_PUBLIC, PUBLIC)을 고려하여 다대일로 관계를 설정하였다.

만약 여러 유저가 동시에 선물박스 열기(=선물박스 받기)를 시도할 경우 어떻게 될까? 테스트 코드로 상황을 시뮬레이션 해보자.

2. 선물박스 열기 테스트 코드 작성

여러 유저가 동시에 선물박스 열기를 시도하는 상황을 어떻게 구현할 수 있을까?

Spring Boot에서는 내장된 서블릿 컨테이너(TomCat)에서 다중 요청을 처리한다.

톰캣은 부팅할 때 스레드의 컬렉션인 Thread Pool을 생성
유저 요청(HttpServletRequest)가 들어오면 Thread Pool에서 하나씩 Thread를 할당
작업을 모두 수행하고 Thread는 Thread Pool로 반환

그러므로 여러 스레드를 사용해서 유저가 동시에 접근하는 상황을 구현하면 된다. 코드는 아래와 같다.

giftBoxType은 PRIVATE이라고 가정한다

참고로 나는 서비스 레이어 테스트 코드에 @Transactional 어노테이션을 추가하여 진행했는데 어노테이션을 사용할 경우 데이터가 의도한 것처럼 저장되지 않아 기존 GiftBoxServiceTest에 테스트 메서드를 작성하는 대신 @Transactional을 사용하지 않는 GiftBoxConcurrencyTest 테스트 클래스를 만들어 테스트를 진행하였다.

class GiftBoxConcurrencyTest {

    // 의존성 주입, BeforeEach 중략 ...
    
    @DisplayName("선물박스 열기 동시성 테스트")
    @Test
    void multipleUserOpenGiftBox() throws InterruptedException {
        // given
        int memberCount = 10;
        int giftBoxAmount = 1;

        List<Member> receivers = new ArrayList<>();
        Long lastMemberId = memberReader.count();
        for (long i = lastMemberId + 1; i <= lastMemberId + memberCount; i++) {
            Member member = memberWriter.save(NORMAL_MEMBER_RECEIVER.createMember());
            receivers.add(member);
        }

        GiftBox giftBox = giftBoxWriter.save(
            sendGiftBoxFixtureWithGift(MEMBER_SENDER, letter));

        ExecutorService executorService = Executors.newFixedThreadPool(10);
        CountDownLatch countDownLatch = new CountDownLatch(memberCount);

        AtomicInteger successCount = new AtomicInteger();
        AtomicInteger failCount = new AtomicInteger();

        Long receiverBefore = receiverReader.countByGiftBox(giftBox);

        // when
        for (int i = 0; i < memberCount; i++) {
            Member member = receivers.get(i);
            Long memberId = member.getId();
            executorService.submit(() -> {
                try {
                    createSecurityContextWithMockUser(memberId.toString());
                    giftBoxService.openGiftBox(giftBox.getId());
                    successCount.incrementAndGet();
                } catch (Exception e) {
                    e.printStackTrace();
                    failCount.incrementAndGet();
                } finally {
                    countDownLatch.countDown();
                }
            });
        }

        countDownLatch.await();

        Long receiverAfter = receiverReader.countByGiftBox(giftBox);
        List<Receiver> receiverList = receiverReader.findByGiftBox(giftBox);

        System.out.println("successCount = " + successCount);
        System.out.println("failCount = " + failCount);

        countDownLatch.await();

        // then
        assertThat(successCount.get()).isEqualTo(giftBoxAmount);
        assertThat(receiverAfter).isEqualTo(giftBoxAmount);
    }
}

ExecutorService를 사용하여 ThreadPool을 이용한 작업을 진행하고, CountDownLatch를 필요한 스레드 수의 값으로 초기화한 뒤 스레드 작업이 완료되는 것을 기다릴 수 있다.

테스트 코드 결과

선물박스 열기를 시도한 모든 유저가 RECEIVER로 변경되었다.

1명만 열 수 있는 선물박스를 10명이 모두 열 수 있게 저장되는 문제가 발생하였다.

3. 어떻게 해결해야 할까?

synchronized

synchronized는 Java에서 제공하는 키워드로, 모니터 기반 상호 배제(mutual exclusion) 기능을 제공한다.

하지만 synchronized를 사용하는 것에는 2가지 문제가 있다.

같은 프로세스에서만 상호 배제를 보장하기 때문에 분산 환경에서는 보장되지 않을 수 있다.
@Transactional 어노테이션과 함께 사용할 경우 문제가 발생할 수 있다.

출처: https://tecoble.techcourse.co.kr/post/2023-08-16-concurrency-managing/

@Transactional 어노테이션이 붙은 메서드가 호출되면, Spring은 프록시 객체를 생성한다.

해당 프록시 객체는 원복 객체를 감싸며, 메서드 전후로 transaction begin과 transaction commit을 수행한다.

transaction begin, commit은 synchronize의 영향을 받지 않기 때문에 위 그림처럼 T1 스레드에서 commit되기 전 T2 스레드가 시작하는 상황이 발생할 수 있다.

Lock

락(Lock)은 데이터가 읽힌 후 사용될 때까지 데이터가 변경되는 것을 방지하기 위한 조치이다.

데이터베이스에서 제공하는 락(S-lock, X-lock 등...)도 있지만 어플리케이션 레벨에서의 락 기법도 존재한다.

동시성 문제 해결을 위해 대표적으로 사용되는 락은 낙관적 락, 비관적 락, 분산 락이 있다.

3가지 락의 특징에 대해 간단하게 알아보자.

낙관적 락

여러 트랜잭션 간 충돌이 일어나지 않을 것이라고 '낙관적'으로 가정하고, 실제 충돌이 발생했을 때만 대응한다.

데이터베이스에 대한 변경이 드물고, 충돌 가능성이 낮은 환경에서 유용하다.

테이블에 version 컬럼을 추가하여 버전 불일치 여부를 확인하는 방식으로 동작한다. 버전 불일치로 인한 실패 처리는 어플리케이션 레벨에서 처리해주어야 한다. (예외 처리 & 실패 후 재시도 로직)

비관적 락

여러 트랜잭션 간 충돌이 일어날 것이라고 '비관적'으로 가정하고, 데이터를 처음부터 잠그는 방식으로 충돌을 방지한다.

데이터 변경이 자주 발생하고, 충돌 가능성이 높은 환경에서 유용하다.

단일 DB 환경에만 적용 가능하고, 많은 대기 시간이 발생한다는 단점이 있다.

동시에 많은 요청이 들어왔을 때, 사실상 하나의 요청씩 작업할 수 있기 때문에 요청이 많아지면 대기 시간이 길어진다.

분산 락

분산 환경에서 상호 배제를 구현하여 동시성 문제를 다루기 위해 등장한 방법이다.

락에 대한 정보를 어딘가에 공통적으로 보관하고, 여러 대의 서버는 공통된 어딘가를 바라보며 자신이 임계 영역에 접근할 수 있는지 확인하는 방법으로 동작한다.

'어딘가'는 MySQL 네임드 락, Redis, Zookeeper 등의 기술이 될 수 있다.

어떤 락을 사용해야 할까?

3가지 락을 비교해보았을 때, 낙관적 락과 비관적 락은 특정 엔티티에 대한 동시 접근 제어에 관심이 있다. 즉, 이미 존재하는 엔티티에 동시 접근하는 상황(ex. update 쿼리)에 적합한 방법이다.

그러나 현재 문제 상황에서는 이미 존재하는 엔티티가 아니라 Receiver라는 새로운 엔티티의 생성 개수 제한에 문제가 발생가 발생하므로 낙관적 락과 비관적 락은 적합하지 않다.

그러므로 분산 락을 최종적으로 선택하여 동시성 문제를 해결하려고 한다.

4. 분산 락을 구현하는 2가지 방식

분산 락을 구현하는 방법은 1️⃣ SENTX를 활용해 스핀 락을 구현하는 방법과 2️⃣ Message Broker를 사용하는 2가지 방법이 있다.

SENTX를 활용한 스핀 락 구현

SENTX는 Redis의 명령어로 키에 값이 존재하지 않을 때만 값을 설정할 수 있도록 하는 연산이다.

해당 연산을 사용하여 스핀 락 방식을 구현할 수 있다.

스핀 락은 락을 사용할 수 있을 때까지 지속적으로 확인하며 기다리는 방식이다.

// 락을 획득할 때까지 대기하는 예시 코드
while(!redisLockRepository.lock(giftBoxId)) {
	Thread.sleep(100);
}

기본 제공되는 Redis Client인 Lettuce만으로 간단하게 구현 가능하다는 장점이 있다.

하지만 락을 사용할 수 있을 때까지 계속 접근을 시도하므로 Reids 서버에 불필요한 부하를 주게 된다.

만약 애플리케이션 장애로 인해 락을 획득하지 못한다면 무한 루프를 돌거나, 락을 잡고 있던 서버가 죽어 락 해제를 하지 못하는 상황도 발생할 수 있다.

Message Broker 사용

Redis는 캐시뿐만 아니라 Pub/Sub 구조의 Message Broker로도 사용이 가능하다.

subscribe라는 명령어로 subscriber는 특정 channel을 구독할수 있다.

publisher는 publish 명령으로 특정 channel에 메시지를 발행할 수 있고, 해당 channel을 구독한 subscriber는 메시지를 받을 수 있다.

출처: https://www.geeksforgeeks.org/redis-publish-subscribe/

분산 락에서는 락을 해제하는 측이 락을 대기하는 프로세스에게 이제 락 획득 시도 해제해도 돼~ 라고 메시지를 발행할 수 있다.

Redisson이라는 라이브러리에 분산 락 메커니즘과 재시도 로직이 구현되어 있기 때문에 해당 라이브러리를 사용하여 분산 락을 구현할 수 있다. 우리는 락 획득 시도, 락 획득 성공 후 처리, 락 획득 실패 로직을 구현하면 된다.

두 가지 방식을 비교해보았을 때, 스핀 락은 락을 획득하지 못하는 상황이나 장애 발생 상황에 대해 추가적으로 구현할 로직이 많고 이를 빼먹을 경우 선물박스 열기라는 핵심 비즈니스 로직이 아예 동작하지 않는 심각한 상황이 발생할 수 있어 더 안정적인 Message Broker 방식을 사용하려고 한다.

5. 마치며

이번 포스트에서는 선물박스 열기 로직에 동시성 제어를 도입하려는 이유를 소개하고 테스트 코드를 통한 문제 상황 파악하였다.

그 후 synchronized 키워드와 3가지 락에 대한 개념을 기본적으로 알아보고, 최종적으로 Redis의 Message Broker 방식을 활용한 분산 락으로 해결할 것을 결정 지었다.

Redisson을 이용한 구체적인 구현 과정을 이번 포스트에서 적으면 글이 너무 길어질 것 같아 다음 포스트(아래 링크 참고)에서 작성하려고 한다.

[Packy] 선물박스 열기 동시성 문제 해결 2 - Redisson으로 분산락 구현

1. 들어가며 [Packy] 선물박스 열기 동시성 문제 해결 1 - 분산 락을 선택한 이유1. 들어가며 패키에서는 선물박스를 받게 되면 Receiver 테이블에 받은 유저 ID와 선물박스 ID를 저장한다.지금은 하나

leeeeeyeon-dev.tistory.com

Reference

[LitmusChaos] M1에서 LitmusChaos 실행하고 카오스 주입하기

짱정연 — Tue, 23 Jul 2024 23:51:33 +0900

1. 카오스 엔지니어링과 LitmusChaos 간단 설명

카오스 엔지니어링은 간단히 말해 시스템의 복원력을 테스트하기 위해 의도적으로 장애를 일으켜보며 취약점을 찾고 보강하는 방식의 엔지니어링 기법이다.

LitmusChaos는 쿠버네티스 플랫폼 위에서 카오스 엔지니어링을 진행할 수 있도록 도와주는 오픈소스 프로젝트이다.

LitmusChaos 아키텍처

2. 준비물

Minikube: 쿠버네티스를 로컬 환경에서 사용할 수 있게 만든 가벼운 구현체
Helm: 쿠버네티스 패키지 매니저 (like Mac의 brew, Node의 npm ...)
카오스를 주입할 데모 서비스

Minikube와 Helm 설치 과정은 생략하고, 데모 서비스의 경우 아래 명령어로 실행할 수 있다.

# Clone Repo
git clone https://github.com/GoogleCloudPlatform/microservices-demo

# Move Directory
cd microservices-demo/

# Install using mainfest file
kubectl apply -f ./release/kubernetes-manifests.yaml

# Access the demo
minikube service frontend-external --url

마지막 명령어를 실행하여 나온 URL로 데모 서비스에 접속할 수 있다.

데모 서비스 접속 화면

3. LitmusChaos 설치

지금부터 나오는 설치 과정은 M1을 기준으로 작성되었습니다
포스트 작성일(2024.07.23)을 기준으로 최신 버전(3.9.1)의 auth-server에 임시적인 로그인 이슈가 있어 3.8.0 버전으로 실습을 진행하였습니다.

먼저 LitmusChaos Helm repo를 추가한다.

# Helm repo 추가
helm repo add litmuschaos https://litmuschaos.github.io/litmus-helm/

# Helm repo 확인
helm repo list

다음으로 쿠버네티스 네임스페이스를 생성한다.

# 네임스페이스 생성
kubectl create ns litmus

# 네임스페이스 확인
kubectl get ns

ARM 기반 MongoDB를 사용하는 ChaosCenter를 설치한다.

helm install chaos litmuschaos/litmus --namespace=litmus \
--set portal.frontend.service.type=NodePort \
--set mongodb.image.registry=ghcr.io/zcube \
--set mongodb.image.repository=bitnami-compat/mongodb \
--set mongodb.image.tag=6.0.5 \
--set litmuschaos.image.tag=3.8.0

아래 사진처럼 모든 파드가 정상적으로 실행되는지 확인한다.

4. Chaos Center 접속 및 Environment 생성

아래 명령어를 입력하여 나온 URL로 Chaos Center(LitmusChaos 관리 페이지)에 접속할 수 있다.

 minikube service chaos-litmus-frontend-service -n litmus --url

최초 로그인 아이디와 비밀번호는 admin / litmus이고, 로그인 후 비밀번호를 바꿔야 한다.

처음 로그인하면 아래와 같은 팝업 창이 나오는데 버튼을 눌러 Environment를 만들어주자.

New Environment 버튼을 눌러주고

적당한 이름을 작성해주고 타입은 pre-production을 선택하여 Environment를 만든다.

Environment Type은 스테이징 관련인 것 같은데 지금은 간단한 실습을 해보는 것이므로 어떤 것을 선택하든 상관 없을 것 같다.

생성된 Environment 안에 들어가 Chaos Infrastructure를 만들어주자.

Configuration은 기본 설정으로 해주었고, 마지막 창에 나오는 설정 파일을 다운로드 받는다.

버튼 클릭

이름 작성

기본 설정 유지

설정 파일 다운로드

그러나 위에 있는 설정 파일을 그대로 배포하면 subscriber 파드가 배포에 실패하는 문제가 발생한다.

아래 명령어로 확인한 ClusterIP와 TargetPort(PORT의 왼쪽 번호)로 설정 파일의 서버 주소를 변경해주고 apply를 진행한다.

9091:32102에서 왼쪽에 적힌 값은 targetPort, 오른쪽에 적힌 값은 nodePort라고 한다.
- targetPort: 클러스터 내 다른 파드가 서비스에 접근할 때 사용
- nodePort: 클러스터 외부에서 노출되어 직접 접근할 때 사용

위 과정까지 성공적으로 수행하면 Pending 상태였던 Chaos Infrastructure가 Connected 상태로 변한다.

5. Probe 설정

카오스 엔지니어링에서는 JVM에 장애를 발생 시키기, DB나 Kafka에 발생 시키기, istio 없애기, 쿠버네티스 파드 없애기 등 다양한 장애 상황을 테스트해볼 수 있다.

이번 포스트에서는 cartservice의 파드를 제거하는 상황에 대해 테스트를 해보자.

먼저 Resilience Probes 탭에 들어가 Probe를 생성해주자.

Probe는 카오스 실험을 진행했을 때 나오는 이상적인 결과를 정의한 것이다.

ex) nginx에 HTTP 요청을 보냈을 때 200 요청이 오면 정상이다.

우리는 '파드를 제거하더라도 파드가 존재한다'를 Probe로 정의할 것이다.

아래 명령어는 파드가 존재하는지 확인하는 명령어인데, 해당 명령어의 결과가 0보다 큰지 확인하는 것이 Probe가 된다.

파드가 존재하는지 확인하는 명령어

Probe 생성 버튼을 눌러 Command Probe를 선택한다.

설정 값은 아래와 같이 해주고 Optional 값은 생략하였다.

'kubectl get pods -n default | grep cartservice | grep Running | wc -l' 명령어의 결과가 0보다 크다는 의미이다.

6. 카오스 주입

Chaos Experiments 탭에서 New Experiment 버튼을 눌러 Chaos Experiment를 생성해주자.

4번 과정에서 생성한 Chaos Infrastructure를 선택한다.

Blank Canvas를 선택한다.

Add 버튼을 누르고, pod-delete를 선택한다.

Target Application 탭에서 설정을 아래 사진처럼 설정한다.

만약 cartservice에 라벨이 없다면 아래 명령어로 라벨을 추가해주자.

kubectl label deployment cartservice app=cartservice

라벨 확인

다음으로 Probes 탭에 들어가 아까 만든 Probe를 EOT 모드로 추가해준 뒤 Apply Changes를 누르면 모든 설정이 끝난다

Select Probe 클릭

Add to Fault 클릭

EOT 선택

Run 버튼을 누르고 잠시 기다리면 ... 카오스 테스트가 성공하는 것을 볼 수 있다

Install-chaos-faults와 cleanup-chaos-resources 단계가 갑자기 추가되었는데, 카오스 실험에 필요한 리소스들을 설치하고 실험이 종료된 뒤 다시 삭제하는 단계인 것 같다.

끝!

Reference

[트러블슈팅] M1 minikube start 실패

짱정연 — Sun, 21 Jul 2024 15:13:44 +0900

1. 문제 상황

쿠버네티스 실습을 위해 minikube를 실행하려고 했는데 위와 같이 실패하였다.

2. 해결 방법

https://github.com/kubernetes/minikube/issues/14477

Minikube didnt start · Issue #14477 · kubernetes/minikube

What Happened? when hitting command "minikube start" on local machine, getting the below error. However, i tried minikube delete and start again but didnt resolve the issue. Docker Desktop is insta...

github.com

위 이슈와 댓글을 참고하여

minikube delete --all --purge

를 해주고 다시 start를 해주니 정상적으로 실행되었다.

[Packy] 전략 패턴으로 복잡한 if문 리팩토링하기

짱정연 — Wed, 26 Jun 2024 23:40:02 +0900

1. 들어가며

패키는 온라인 상으로 선물박스를 만들고 '주고받는' 서비스이다. 패키에서는 선물박스를 접하는 입장에서 유저를 보내는 유저(Sender), 받는 유저(Receiver), 둘 다 아닌 유저(Stranger) 3가지로 구분할 수 있다.

그렇기 때문에 대부분의 기능에 대해 3가지 입장을 모두 고려하여 로직을 설계해야 한다. 그러다보니 하나의 메서드에서 if문이 늘어나고, 이는 한 메서드의 책임이 너무 커지는 문제를 초래하며 가독성도 같이 떨어진다.

이번 포스트에서는 '선물박스 삭제하기' 로직을 대표로 예시를 들어 설명하겠다. 아래는 리팩토링을 진행하기 전 코드이다.

if문이 너무 많이 중첩되어 있어 주석 없이 코드를 이해하는데 오랜 시간이 소요된다..

public String deleteGiftBox(Long giftBoxId) {  
    Long memberId = SecurityUtil.getMemberId();  
    Member member = memberReader.findById(memberId);  
  
    GiftBox giftBox = giftBoxReader.findById(giftBoxId);  
    GiftBoxRole role = getGiftBoxRole(member, giftBox);  
  
    if (role.equals(MemberRole.STRANGER)) {
            throw new GiftBoxAccessDeniedException();
        }
    if (role.equals(GiftBoxRole.SENDER)) {  
        if (giftBox.getDeliverStatus().equals(DeliverStatus.DELIVERED)) {  
            giftBox.delete();  
        } else if (giftBox.getDeliverStatus().equals(DeliverStatus.WAITING)) {  
            letterWriter.delete(giftBox.getLetter());  
            giftBox.getPhotos().forEach(photo -> {  
                fileService.deleteFile(photo.getImgUrl());  
                photoWriter.delete(photo);  
            });  
            if (giftBox.getGift().getGiftType().equals(GiftType.PHOTO)) {  
                fileService.deleteFile(giftBox.getGift().getGiftUrl());  
            }  
            giftBox.getGiftBoxStickers().forEach(giftBoxStickerWriter::delete);  
            giftBoxWriter.delete(giftBox);  
        }  
    } else if (role.equals(GiftBoxRole.RECEIVER)) {  
        Receiver receiver = receiverReader.findByMemberAndGiftBox(member, giftBox);  
        receiver.delete();  
    }  
  
    return "선물박스가 삭제되었습니다";  
}

선물박스 삭제하기 로직의 if문의 가장 큰 특징은

유저 타입(Sender, Receiver)에 따라 선물박스 삭제 로직이 다르다

라는 점이다.

* Stranger의 경우 선물박스 삭제 권한이 없으므로 예외를 던진다.

어떤 식으로 리팩토링을 할까 찾아보다가 전략 패턴이라는 디자인 패턴을 알게 되었고, 지금 상황에 알맞는 방법인 것 같아 전략 패턴을 사용하여 코드를 리팩토링해보았다.

2. 전략 패턴이 뭐죠?

전략 패턴의 정의는 아래와 같다.

객체들이 할 수 있는 행위 각각에 대한 전략 클래스를 생성하고, 유사한 행위들을 캡슐화하는 인터페이스를 정의하여, 동적으로 행위의 수정이 필요한 경우 전략을 바꾸는 것만으로 행위의 수정이 가능하도록 만든 패턴

정의만 봐서는 감이 안 올 수 있어 전략 패턴 적용 구조를 선물박스 삭제 사례와 연관지어 도식화하였다.

전략 패턴 사용 구조

GiftBoxService의 deleteGiftBox()는 전략 패턴의 클라이언트로, 전략 객체를 전달하여 전략을 등록하거나 변경하여 전략 알고리즘을 실행한 결과를 얻는다.
GiftBoxActionProvider는 컨텍스트로, 알고리즘을 실행해야 할 때마다 해당 알고리즘과 연결된 전략 객체의 메소드를 호출한다.
GiftBoxStrategy는 전략 구현체에 대한 공용 인터페이스이며, SenderStrategy와 ReceiverStrategy는 이를 구현한 클래스들이다.

GiftBoxActionProvider는 유저 타입에 따라 동적으로 전략을 제공하는데, 유저 타입이 변경되더라도 해당 클래스에만 전략을 추가하고 매핑해도 되기 때문에 시스템의 유연성을 향상시켜주고, OCP(개방-폐쇄 원칙)을 준수하는 구조를 만들어준다.

또한, 전략 패턴을 통해 구현 클래스로 책임을 분리하여 단일 책임 원칙을 준수할 수 있게 되며 이 외에도 합성(composition), 다형성, 캡슐화 등 OOP 기술이 총 집합된 패턴이다.

3. 프로젝트 코드 개선 과정

패키지 구조

먼저 공통 인터페이스를 만들어보자.

@FunctionalInterface
public interface GiftBoxStrategy {

    void delete(Member member, GiftBox giftBox);
}

@FunctionalInterface는 Object Class의 메서드를 제외하고 구현해야 할 추상 메서드가 하나만 정의된 인터페이스임을 검증 및 명시해주는 어노테이션이다.

이제 각 전략을 분리해보자.

@RequiredArgsConstructor
@Component
public class SenderStrategy implements GiftBoxStrategy {

    private final FileService fileService;
    private final GiftBoxWriter giftBoxWriter;
    private final LetterWriter letterWriter;
    private final PhotoWriter photoWriter;
    private final GiftBoxStickerWriter giftBoxStickerWriter;

    @Override
    public void delete(Member member, GiftBox giftBox) {
        if (giftBox.getDeliverStatus().equals(DeliverStatus.DELIVERED)) {
            giftBox.delete();
        } else if (giftBox.getDeliverStatus().equals(DeliverStatus.WAITING)) {
            letterWriter.delete(giftBox.getLetter());
            giftBox.getPhotos().forEach(photo -> {
                fileService.deleteFile(photo.getImgUrl());
                photoWriter.delete(photo);
            });
            if (giftBox.getGift().getGiftType().equals(GiftType.PHOTO)) {
                fileService.deleteFile(giftBox.getGift().getGiftUrl());
            }
            giftBox.getGiftBoxStickers().forEach(giftBoxStickerWriter::delete);
            giftBoxWriter.delete(giftBox);
        }
    }
}

GiftBox의 DevliverStatus에 따라 분기하는 코드도 전략 패턴을 적용할 수 있겠지만 ...

1) DeliverStatus가 현재 Enum 값 외에 추가될 가능성이 거의 없음

2) 전략 패턴을 연속으로 2번 사용할 경우 추상화 레벨이 높아져 혼란스러울 수 있음

이라는 이유로 우선은 SenderStrategy의 delete 메서드는 추가적인 리팩토링을 진행하지 않았다.

@RequiredArgsConstructor
@Component
public class ReceiverStrategy implements GiftBoxStrategy {

    private final ReceiverReader receiverReader;

    @Override
    public void delete(Member member, GiftBox giftBox) {
        Receiver receiver = receiverReader.findByMemberAndGiftBox(member, giftBox);
        receiver.delete();
    }
}

마지막으로 ActionProvider는 아래와 같다.

ActionProvider는 전략 클래스들 중 적절한 클래스를 선택하는 역할을 수행한다.

@Component
public class GiftBoxActionProvider {

    private final Map<MemberRole, GiftBoxStrategy> giftBoxActions;

    public GiftBoxActionProvider(
        final SenderStrategy senderStrategy,
        final ReceiverStrategy receiverStrategy
    ) {
        this.giftBoxActions = new EnumMap<>(MemberRole.class);
        this.giftBoxActions.put(MemberRole.SENDER, senderStrategy);
        this.giftBoxActions.put(MemberRole.RECEIVER, receiverStrategy);
    }

    public GiftBoxStrategy getStrategy(MemberRole memberRole) {
        return giftBoxActions.get(memberRole);
    }
}

이제 다 만든 전략 패턴을 클라이언트에게 적용시키면 ...

public String deleteGiftBox(Long giftBoxId) {
    Long memberId = SecurityUtil.getMemberId();
    Member member = memberReader.findById(memberId);

    GiftBox giftBox = giftBoxReader.findById(giftBoxId);
    MemberRole memberRole = getMemberRole(member, giftBox);

    if (memberRole.equals(MemberRole.STRANGER)) {
        throw new GiftBoxAccessDeniedException();
    }

    final GiftBoxStrategy giftBoxStrategy = giftBoxActionProvider.getStrategy(memberRole);
    giftBoxStrategy.delete(member, giftBox);

    return "선물박스가 삭제되었습니다";
}

기존에 18줄짜리 로직을 2줄로 줄일 수 있게 되었다 !!

4. 마치며

이전에는 리팩토링을 진행하게 되면 대부분 private 함수로 분리하는 정도로 그쳤기 때문에 하나의 클래스에 코드 줄이 길어지고 위 아래를 스크롤해가며 보아야 해서 불편했다. OOP를 적극적으로 활용하여 클래스 수준으로 코드를 분리하니 훨씬 관리가 쉽고, 이해하기 쉬운 코드가 되었다.

이번 리팩토링을 계기로 더 많은 디자인 패턴을 공부하고 다음 리팩토링에도 사용해보고 싶어졌다.

Reference

[Packy] 선물박스 PK 생성 전략을 TSID로 변경한 이유

짱정연 — Tue, 25 Jun 2024 19:35:10 +0900

1. 들어가며

이번 패키 업데이트에 웹 버전을 출시하여 앱을 설치하지 않은 사람도 웹으로 선물박스를 확인할 수 있도록 할 예정이다.

웹 출시 이전에는 아래 플로우에 따라 카카오톡으로 받은 선물박스를 앱에서만 확인할 수 있었다.

클라이언트는 선물박스 만들기 API의 응답값으로 받은 선물박스 ID를 사용하여 선물박스를 열 수 있는 딥링크를 생성한다.
생성된 딥링크이 추가된 카카오톡 템플릿을 생성한다.
선물박스를 받은 유저는 카카오톡에서 '패키 앱에서 열어보기' 버튼을 눌러 선물박스를 앱에서 확인할 수 있다.

카카오톡 예시 사진

이번 업데이트에서는 2, 3번 과정에서 딥링크 대신 제작한 웹 링크( packyforyou.com?box={giftBoxId} )를 넣고, 웹 사이트 내에 디퍼드 링크를 넣어 웹에서 앱으로 유저를 이동시키도록 하려고 한다.

기존에 앱 서비스만 운영할 때는 선물박스 식별 값을 PK 값인 id를 사용하였다. 현재 PK 생성 전략으로는 auto increment 전략을 사용하고 있다.

만약 웹 링크에서도 id를 사용하게 된다면 다른 선물박스 id를 쉽게 유추하여 다른 선물박스를 열람할 수 있게 된다.

이전에 선물박스 만들기 API를 만들 때 응답값으로 id와 함께 UUID를 넘기도록 구현해두었기 때문에, giftBoxId로 UUID 값을 사용하고자 했다.

2. 문제 상황

But . . .

클라이언트 개발자님의 개인 사정으로 어플리케이션 단 코드를 수정하지 못한다는 제약이 발생하였다.

카카오톡 템플릿에 들어가는 URL은 '딥링크 → 패키 웹 도메인'으로 변경이 가능하지만, 어플리케이션 → 카카오톡으로 데이터를 전달하는 것은 id로 구현되어 있기 때문에 이것을 UUID로 변경하지 못하는 상황이다.

>>> Mission: 선물박스의 ID 값을
1. 숫자로 이루어져야 함
2. 고유성을 지켜야 함
3. 쉽게 유추할 수 없어야 함
이라는 조건을 지키는 값으로 변경해야 한다 !

숫자로 이루어져야 하는 이유는 클라이언트 단 데이터 모델에서 선물박스의 id를 Int 또는 Long으로 받기 때문이다.

추가로 선물박스 만들기 API의 응답값(DTO)에 들어가는 값만 난수로 변경하면 되지 않느냐?라는 생각도 해보았지만 선물박스 생성 이후 단계에서 id 값을 Query Parameter로 다른 API를 호출하기 때문에 서버 단 코드의 수정 양이 어마어마해진다

즉! 위 조건을 충족하도록 선물박스 엔티티의 PK 생성 전략을 수정해야 한다 !!!

다양한 PK 생성 전략을 찾아보았고, 그중 내가 최종적으로 선택한 것은 TSID(Time-Sorted Unique Identifier)이다.

내가 TSID를 선택한 이유는 '유추 불가능하며 숫자로만 구성됨'이 핵심이긴 하지만, TSID는 이뿐만 아니라 대규모 분산 시스템에서 고유성과 성능을 보장할 수 있는 기법이라는 장점도 있기 때문에 이 부분도 함께 알아보자.

TSID는 ULID와 트위터의 스노우 플레이크(snowflake) 아이디어를 결합한 것이므로, 이 2가지에 대해 먼저 간략히 알아보자.

3. TSID

3-1. ULID

ULID 구조

48bit의 Timestamp(UNIX Time, 밀리초 단위)와 80bit의 랜덤 문자열로 이루어져 있다.

밀리초 단위의 정밀도를 가지며, 밀리초 내에 동시 생성되면 무작위성에 따라 순서가 달라진다.

ULID(26문자)는 Base32 인코딩을 사용하여 UUID(Base16 인코딩, 36문자)보다 짧은 문자열을 가짐
특수문자, 대소문자 구분 X
시간순 정렬 가능
128bit로 상대적으로 용량이 큼

자세한 내용은 ULID 공식 깃허브를 참고하자.

3-2. 트위터의 스노우 플레이크(snowflake)

초당 6,000개 이상의 트윗이 생성되는 트위터는 고가용성 방식으로 초당 수만 개를 생성할 수 있으며 대략적으로 정렬이 가능한 ID 전략이 필요했고, 이를 위해 스노우 플레이크 기법을 제시하였다.

출처: https://keeplearning.dev/twitter-snowflake-approach-is-cool-3156f78017cb

Sign, Timestamp, Worker Number, Sequence Number 4부분으로 구성되어 있다.

Sign (1bit): 음수와 양수를 구별
Timestamp (41bit): UNIX Time 사용, 밀리초 단위
- 오버 플로우 방지를 위해 시작 시간을 1288834974657(2010년 11월 4일 10시 42분 54초)을 기준으로 함
- 최댓값은 69년 (2^41 - 1 = 2199023255551ms)
- 시간 순으로 정렬 가능
Worker Number (10bit): 데이터센터(5bit)와 서버(5bit)를 구분하는 역할
- 각각 32개의 데이터센터와 서버를 지원할 수 있음
- 시스템 시작 시 결정되며, 일반적으로 시스템 운영 중에는 바뀌지 않음
- 시작 시 Zookeeper를 통해 선택됨
Sequence Number(12bit): 각 서버에서 ID를 생성할 때마다 1씩 증가
- 1밀리초가 경과할 때마다 0으로 초기화
- 1밀리초 내에 두 개 이상의 ID가 생성되지 않는 한 일반적으로 0

분산 환경에서는 유일한 키를 생성하기 위해 티켓 서버(Ticket Server)를 두는데, 이는 SPOF(Single Point of Failure)라는 단점이 있다.

스노우플레이크 기법은 Worker Number를 두기 때문에 특정 시스템에 의존한다는 티켓 서버의 문제점을 해결하였으며, 나아가 어떤 데이터센터나 서버에서 생성한 ID인지 알 수 있게 되었다.

초당 생성 가능한 ID 수도 약 4,096,000개로 넉넉하며 타임스탬프를 앞 쪽에 배치하여 시간 순 정렬도 가능하다.

3-3. TSID

TSID 구조

TSID는 ULID와 스노우플레이크 기법을 결합한 아이디어로, 42bit의 타임스탬프와 22bit의 랜덤 구성 요소로 이루어져있다.

랜덤 구성 요소는 node와 counter로 이루어져 있다.

노드는 인스턴스를 식별하는 번호이며, 카운터는 스노우플레이크의 sequence number와 동일하게 각 노드에서 생성할 때마다 1씩 증가하며 밀리초가 지나면 0으로 초기화된다.

노드는 기본값이 10bit(1024개)이며, 직접 설정하지 않으면 랜덤한 값으로 설정된다. 노드의 bit 수와 값은 직접 조절할 수 있다.

TSID 또한 시간 순 정렬이 가능하며, 최대 69년 사용 가능하다.

4. Spring Boot에서 TSID 사용하는 방법

이제 Spring Boot에서 TSID를 사용하는 방법을 알아보자.

먼저 build.gradle에 의존성을 추가한다. 이때, Hibernate 버전에 따라 다른 버전을 사용하므로 자신에게 맞는 버전을 사용하자.

아래에 나오는 코드는 Hibernate 6을 기준으로 작성되었다.

implementation 'io.hypersistence:hypersistence-utils-hibernate-63:3.7.6'

라이브러리를 추가한 후 '@Tsid' 어노테이션을 사용하여 쉽게 사용할 수 있다!

public class GiftBox {

    @Id
    @Tsid
    private Long id;
    
    // 중략 ...
}

만약 노드 bit, epoch 기준 시간 등을 변경하고 싶으면 Supplier<TSID.Factory>를 확장하는 커스텀 클래스를 생성하고, @Tsid 어노테이션의 파라미터로 전달하면 된다.

커스텀 가능한 값들은 TSID.Factory 구현 코드에서 더 확인 가능하다.

public static class CustomTsidSupplier implements Supplier<TSID.Factory> {
⠀
    @Override
    public TSID.Factory get() {
        return TSID.Factory.builder()
            .withNodeBits(1)
            .build();
    }
}

public class GiftBox {

    @Id
    @Tsid(CustomTsidSupplier.class)
    private Long id;
    
    // 중략 ...
}

5. 자바스크립트 관련 주의사항

자바스크립트에서 정수의 표현은 53비트로 제한되어 있어, 아래 콘솔 결과처럼 뒷 숫자의 정확도를 잃을 수 있다.

그러므로 생성된 아이디를 문자열로 다뤄주어야 한다.

6. 마치며

@GeneratedValue의 GenerationType에서 제공하는 기본 키 생성 전략의 경우 특정 DB에 의존적이거나, 성능 이슈가 있고 PK 생성 전략을 직접 설계하기는 막막하였는데 TSID를 사용하여 현재 상황에 맞게 PK 생성 전략을 간편하게 수정할 수 있었다.

단일 서버로 서비스를 운영해왔기 때문에 분산 시스템에서의 고유성 문제는 생각해보지 않은 영역이였는데 이번에 TSID에 대해 조사하며 좋은 인사이트를 얻었다.