Kotest란?

코틀린에서 사용가능한 테스트 프레임워크입니다. Kotest의 DSL을 이용하여 테스트 코드를 가독성 좋게 작성하도록 돕습니다.

class MyTest : StringSpec({
    "2 + 2 = 4 이다" {
        val sum = 2 + 2
        sum shouldBe 4
    }

    "숫자를 0으로 나누면 예외가 발생한다" {
        shouldThrow<ArithmeticException> {
            val result = 1 / 0
        }
    }
})

위의 예시와 같이 shouldBe, shouldThrow 와 StringSpec를 사용하여 간단하고 명료하게 테스트 코드를 작성할 수 있습니다. 그리고 Kotest는 다양한 테스트 스타일을 제공하여 개발자가 선호하는 테스트 작성 방식을 선택할 수 있게 합니다.

설치

    dependencies {
        testImplementation("io.kotest:kotest-runner-junit5-jvm:${Versions.KOTEST}")
        testImplementation("io.kotest:kotest-assertions-core:${Versions.KOTEST}")
        testImplementation("io.kotest.extensions:kotest-extensions-spring:${Versions.KOTEST_SPRING}")
    }

저는 build.gradle.kts 파일에서 위와 같은 의존성을 추가했습니다. 마지막의 spring 관련 kotest는 스프링을 사용할 때 추가적으로 사용할 수 있습니다. 오늘 다룰 내용에서는 굳이 필요하지 않습니다.

gradle에 추가를 했다면 intellij 플러그인으로 Kotest를 설치해야합니다. 그렇지 않으면 테스트 실행을 할 수 없습니다.

다양한 테스트 스타일

kotest에서는 10개의 테스트 스타일을 제공하고 있습니다.

간단히 몇 종류의 스타일만 알아보도록 하겠습니다.

FunSpec

class MyFunSpecTest : FunSpec({
    test("2 + 2 = 4 이다") {
        val sum = 2 + 2
        sum shouldBe 4
    }

    test("숫자를 0으로 나누면 예외가 발생한다") {
        shouldThrow<ArithmeticException> {
            val result = 1 / 0
        }
    }
})

StringSpec와 큰 차이가 없어보입니다. 그저 test라는 함수 이름을 명시하여 테스트라는 것을 한눈에 보이도록 했습니다.

BehaviorSpec

class MyBehaviorSpecTest : BehaviorSpec({
    given("2가 2개 주어졌을 때") {
        `when`("두 숫자를 더하면") {
            then("4가 된다") {
                val sum = 2 + 2
                sum shouldBe 4
            }
        }
    }

    given("1과 0이 주어졌을 때") {
        `when`("1을 0으로 나누면") {
            then("예외가 발생한다") {
                shouldThrow<ArithmeticException> {
                    val result = 1 / 0
                }
            }
        }
    }
})

BDD 스타일의 테스트입니다. 많은 개발자들에게 익숙한 given-when-then 키워드를 사용하여 테스트 코드를 작성할 수 있습니다. when의 경우 코틀린의 키워드와 겹치기 때문에 백틱을 사용하고 있습니다. 이를 보완하고자 kotest에서는 아래와 같이 대문자로도 사용할 수 있게끔 제공해줍니다.

    Given("2가 2개 주어졌을 때") {
        When("두 숫자를 더하면") {
            Then("4가 된다") {
                val sum = 2 + 2
                sum shouldBe 4
            }
        }
    }

focus and bang

focus

kotest에서 focus를 사용하면 focus 적용된 테스트만 실행됩니다.

class FocusExample : StringSpec({
    "test 1" {
     // this will be skipped
    }

    "f:test 2" {
     // this will be executed
    }

    "test 3" {
     // this will be skipped
    }
})

예시처럼 함수 설명 앞에 f: 키워드를 붙이면 focus 모드가 되고, 전체 테스트를 실행시키더라도 focus 된 테스트만 실행됩니다. 특정 테스트에 집중하게 하려는 목적으로 만든 것 같은데, 유용할지는 모르겠습니다. 그냥 단축키 이용해서 테스트 하나만 실행시키면 되지 않나... 생각이 드는 기능입니다.

bang

focus와 반대로 실행하지 않을 테스트를 정하는 기능입니다. focus처럼 함수 설명 앞에 ! 만 붙이면 됩니다. 느낌표 하나만으로 해당 테스트를 실행하지 않을 수 있습니다. Junit의 @Ignore 어노테이션과 비슷한 역할을 합니다.

class BangExample : StringSpec({

  "!test 1" {
    // this will be ignored
  }

  "test 2" {
    // this will run
  }

  "test 3" {
    // this will run too
  }
})

Junit에 비해 간단하게 사용할 수 있지만, 한 눈에 들어오지는 않을 것 같습니다. 실행되지 않는 테스트를 확인하고 싶을 때 확인할 수 있는 방법이 로그를 확인하는 것 말고는 없을 것 같습니다.

Junit을 사용할 때는 전체검색 cmd+shift+f로 @Ignore을 검색해 사용하고 있지 않는 테스트를 확인할 수 있지만, 느낌표는 코드에서 너무 많이 사용되는 키워드이기 때문에 쉽게 찾기 어려울 것 같습니다. 따라서 bang도 굳이 사용하지 않을 것 같습니다.

Isolation Modes

Kotest는 여러가지 격리 모드를 지원하여 테스트 간의 상호작용을 제어할 수 있습니다. Kotest의 격리 모드는 IsolationMode enum을 통해 설정할 수 있으며, 각 모드는 테스트 실행 방식에 영향을 미칩니다.

적용법

전역 변수의 값을 변경해주는 방식과 함수 override를 사용하는 방식, 총 2가지 방법으로 적용할 수 있습니다.

전역 변수 값 변경 방식

class MyTestClass : WordSpec({
 isolationMode = IsolationMode.SingleInstance
 // tests here
})

override 방식

class MyTestClass : WordSpec() {
  override fun isolationMode() = IsolationMode.SingleInstance
  init {
    // tests here
  }
}

override를 이용한 방식은 init 블록 내부에 테스트를 작성해야합니다. 초기화 문제 때문입니다. 만약 클래스 초기화 블록인 init 외부에 테스트를 작성하게 되면, 해당 테스트는 코틀린 객체가 초기화되기 전에 실행됩니다. 그렇다면 override가 적용되기 전에 테스트가 실행되겠죠? 따라서 init 블록 밖에서 테스트를 작성하게 되면 격리 모드가 올바르게 적용되지 않습니다.

다양한 격리 모드

• IsolationMode.InstancePerTest
  • 각 테스트마다 새로운 테스트 인스턴스를 생성합니다.
  • 테스트 간 상태 공유가 없으며, 완전한 격리를 보장합니다.
    
• IsolationMode.InstancePerLeaf
  • 각 리프(leaf) 테스트마다 새로운 인스턴스를 생성합니다.
  • 일반적으로 FunSpec과 같은 스타일에서 사용되며, 각 test 블록마다 인스턴스를 생성합니다.
    
• IsolationMode.SingleInstance
  • 테스트 클래스 전체에서 하나의 인스턴스만 생성합니다.
  • 상태를 공유하는 테스트가 가능하지만, 테스트 간 상호작용이 발생할 수 있습니다.

InstancePerTest

InstancePerTest 모드는 모든 테스트 케이스에 대해 spec 인스턴스가 생성됩니다. 즉 모든 테스트 케이스가 독립적으로 실행됩니다. 아래의 테스트 코드가 있다고 가정하겠습니다.

class InstancePerTestExample : WordSpec() {

  override fun isolationMode(): IsolationMode = IsolationMode.InstancePerTest

  init {
    "a" should {
      println("Hello")
      "b" {
        println("From")
      }
      "c" {
        println("Sam")
      }
    }
  }
}

테스트를 실행시켰을 때 결과는 아래와 같습니다.

Hello
Hello
From
Hello
Sam

처음에는 "a"를 위한 spec 인스턴스를 생성하여 Hello를 출력합니다. 두번째로 "b"를 위한 spec 인스턴스를 생성하고 부모에서의 Hello와 b 내부에서의 From을 출력합니다. 세번째로 "c"를 위한 spec 인스턴스를 생성하고 부모에서의 Hello와 c 내부에서의 Sam을 출력합니다.

성능이 아쉬울 것 같아서 완전 격리가 필요한 상황이 아니라면 굳이 사용할 것 같지 않은 모드입니다.

InstancePerLeaf

InstancePerLeaf 모드는 모든 리프에 대해 spec 인스턴스가 생성됩니다. 이전의 InstancePerTest에서는 루트까지 격리했다면, InstancePerLeaf는 리프만 격리합니다.

class InstancePerLeafExample : WordSpec() {

  override fun isolationMode(): IsolationMode = IsolationMode.InstancePerLeaf

  init {
    "a" should {
      println("Hello")
      "b" {
        println("From")
      }
      "c" {
        println("Sam")
      }
    }
  }
}

같은 예시 테스트입니다.

Hello
From
Hello
Sam

해당 테스트에서는 부모 루트는 격리하지 않기 때문에, 처음에는 "b"를 위한 spec 인스턴스를 생성하여 Hello와 From을 출력합니다. 두번째로 "c"를 위한 spec 인스턴스를 생성하여 Hello와 Sam을 출력합니다.

SingleInstance

SingleInstance 모드는 테스트 클래스의 인스턴스가 전체 테스트 실행 동안 한 번만 생성됩니다. 이는 테스트 클래스의 모든 테스트가 동일한 인스턴스에서 실행된다는 것을 의미합니다. 따라서 상태가 공유될 수 있고, 초기화 블록도 한 번만 실행됩니다.

class SingleInstanceExample : WordSpec() {

  override fun isolationMode(): IsolationMode = IsolationMode.SingleInstance

  init {
    "a" should {
      println("Hello")
      "b" {
        println("From")
      }
      "c" {
        println("Sam")
      }
    }
  }
}

Hello
From
Sam

같은 테스트를 실행시켰을 때 결과는 위와 같습니다. "a"가 실행되면서 Hello를 출력하고, 그 뒤에 "b"가 실행되면서 From, "c"가 실행되면서 Sam이 출력됩니다.

상태가 공유되기 때문에 공통 변수를 사용한다면 문제가 생길 여지가 있습니다.

마무리

kotest의 기본 구조와 사용법에 대해 알아보았습니다. 다음에는 이를 스프링부트에서 어떻게 활용하는지에 대해 작성할 예정입니다.

yml 파일 구조

프로젝트는 크게 api, application, rdb 모듈로 이루어져있습니다. api 모듈은 application 모듈에 의존하고, application 모듈은 rdb 모듈에 의존하고 있습니다. rdb 모듈에 데이터베이스 관련 정보를 적어놨고, 상위인 api 모듈에서 active profile을 설정할 수 있도록 구성했습니다.

rdb 모듈의 설정 파일은 아래와 같습니다.

server:
  shutdown: graceful
spring:
  jpa:
    open-in-view: false

---
spring:
  config:
    import:
      - optional:application-secret-rdb
    activate:
      on-profile: prod
  jpa:
    ...

---
spring:
  config:
    activate:
      on-profile: local
  datasource:
    url: jdbc:mysql://localhost:3307/nottodo?allowPublicKeyRetrieval=true&characterEncoding=UTF-8&serverTimezone=Asia/Seoul
    username: root
    password: root
    driver-class-name: com.mysql.cj.jdbc.Driver
  jpa:
    ...

---
spring:
  config:
    activate:
      on-profile: test
  datasource:
    hikari:
      driver-class-name: org.h2.Driver
      jdbc-url: jdbc:h2:mem://localhost/~/nottodo;MODE=MYSQL;DB_CLOSE_DELAY=-1;DATABASE_TO_UPPER=false;DB_CLOSE_ON_EXIT=false;TIME ZONE=Asia/Seoul
    username: sa
    password:
  jpa:
    ...

prod 환경인 경우 github에 데이터베이스 정보가 유출되면 안되기 때문에 서브 모듈을 두어 prod profile 인 경우에만 데이터베이스 정보를 받을 수 있도록 설정했습니다.

optional

yml 파일을 작성하면서 optional 이라는 것을 처음 사용해보았는데요. optional은 말그대로 있으면 사용하고, 없으면 사용하지 않는다는 뜻입니다. 위에 작성한 yml 파일을 예로들면 applicaiton-secret-rdb.yml 파일이 있으면 해당 환경변수 파일을 import 하고, 없는 경우 import 하지 않습니다.

위험점

그런데, 이 기능을 설정하면서 prod의 데이터베이스를 초기화시켰습니다.. 개발할때는 active profile을 local로 설정했는데 어떻게 날릴 수 있었을까요?

환경 설정 파일의 우선순위 때문입니다. optional의 경우 있으면 해당 환경 설정 파일을 사용한다 정도가 아니라 해당 환경 설정으로 덮어씌웁니다. active profile에 상관없이 application-secret-rdb.yml 파일이 존재하면 해당 파일을 import하여 기존 datasource를 덮어씌웁니다. active profile의 우선순위가 optional의 우선순위보다 낮다는 뜻입니다.

첫 실행을 했을 때 "왜 local DB가 안보이지? 분명 잘 설정했는데...". 원래는 ddl-auto 옵션을 update로 설정하는데, 잘 되지 않아 local profile의 ddl-auto 옵션을 create로 바꾸어보았습니다. 그렇게 prod DB의 데이터가 초기화되었고 복구하는데 고생했습니다.

문제 해결

처음에 제가 optional을 사용한 의도는 application-secret-rdb.yml 파일이 없어도 FileNotFoundException과 같은 오류를 내지 않기 위해서입니다. 동료 개발자가 prod의 데이터베이스 정보를 알지 않아도 개발에 지장없게끔 하고 싶었습니다.

기존에는 어플리케이션 실행 시에 gradle에서 서브모듈 파일을 복사하고, 복사본을 읽을 수 있도록 했습니다. 이렇게 하는 경우 실행할 때마다 서브모듈의 파일이 계속 복사되기 때문에 yml의 optional 옵션에 걸리게 되고, local profile 이더라도 prod db를 읽어오는 참사가 일어납니다. 저는 prod profile 인 경우에는 서브모듈의 파일을 복사하고, 빌드하고 나선 복사본을 제거하는 간단한 방법으로 문제를 해결했습니다.

gradle 코드는 아래와 같습니다.

val copyYml = tasks.register<Copy>("copyYml") {
    from("../../server-secret/application-secret-rdb.yml")
    into("src/main/resources/")

    doLast {
        val file = file("src/main/resources/application-secret-rdb.yml")
        if (file.exists()) {
            file.delete()
        }
    }
}

tasks.processResources {
    if (project.hasProperty("spring.profiles.active") && project.property("spring.profiles.active") == "prod") {
        dependsOn(copyYml)
    }
}

마무리

반년만에 글을 써봤습니다. 첫 시작이 어렵다는데, 일단 어려운 고비 다시 넘겼으니 계속 글을 남겨보겠습니다. 짧은 글이지만 읽어주셔서 감사합니다.

직접 트랜잭션

    public void transaction() throws SQLException {
        Connection connection = null;
        try {
            connection = dataSource.getConnection();
            connection.setAutoCommit(false);
            PreparedStatement preparedStatement = connection.prepareStatement(
                    "INSERT INTO item (name, price, stock_quantity) VALUES (?, ?, ?)");
            preparedStatement.setString(1, "트랜잭션 상품");
            preparedStatement.setInt(2, 1000);
            preparedStatement.setInt(3, 1);
            preparedStatement.executeUpdate();
            connection.commit();
        } catch (SQLException e) {
            if (connection != null) {
                connection.rollback();
            }
        } finally {
            if (connection != null) {
                connection.close();
            }
        }
    }

위 코드와 같이 connection.setAutoCommit(false);를 설정하면 자동 커밋 옵션이 해제됩니다. 이렇게 item을 생성하는 것에 대해 직접 트랜잭션을 적용하게 되면, rollback과 commit을 직접 설정할 수 있습니다.

문제점

하지만 만약 하나의 트랜잭션이 조금 커지면 어떻게 될까요? 코드가 길어질거고, transaction 설정 부분을 service 계층에 두어야하는 상황이 발생합니다. service 부분까지 dataSource가 침입하게 되죠. (비즈니스 로직 + 트랜잭션 로직) 두 로직을 함께 처리해야하기 때문에 복잡해집니다.

선언적 트랜잭션

어노테이션을 이용하여 직접 트랜잭션을 적용하는 방식입니다.

    @Transactional
    public Long declarativeTransaction() {
        System.out.println(TransactionSynchronizationManager.getCurrentTransactionName());
        final Item item = itemRepository.save(new Item("트랜잭션 상품", 1000, 1));
        return item.getId();
    }

어노테이션 만으로 트랜잭션이 동작합니다. 롤백과 커밋 모두 어노테이션 하나로 동작할 수 있습니다. 그렇다면 스프링은 어떻게 어노테이션 만으로 트랜잭션 동작이 가능하게 한 것일까요?

@Transactional 동작 원리

@Transactional은 Spring AOP를 통해 프록시 객체를 생성하여 사용됩니다. 프록시 객체를 통해 트랜잭션의 로직을 처리하고, 비즈니스 로직은 target 객체에서 처리하는 방법을 선택했습니다. 스프링 @Transactional은 2가지 방법으로 프록시 패턴 사용했는데요. 각각 살펴보도록 하겠습니다.

JDK dynamic 프록시

JDK dynamic 프록시는 인터페이스를 기반으로 작동합니다. 이 방식에서는 InvocationHandler를 사용하여 메소드 호출을 가로챕니다. @Transactional이 붙은 메소드 호출이 프록시를 통해 이루어질 때, InvocationHandler의 invoke() 메소드를 통해 트랜잭션 시작, 커밋, 롤백이 실행됩니다.

public interface ProductService {
    void perform();
}

public class ProductServiceImpl implements ProductService {
    @Transactional
    @Override
    public void perform() {
        System.out.println("Performing a transactional action");
        // 여기에 비즈니스 로직 구현
    }
}

인터페이스 기반으로 동작한다고 했는데, 이는 반드시 필요합니다. 비즈니스 로직을 처리하는 Service 객체에 인터페이스가 존재해야 합니다. 인터페이스를 두고, target 객체를 구현체로 만들었습니다. target에는 비즈니스 로직을 작성했다고 가정하겠습니다.

스프링 어플리케이션이 시작되고 스프링 컨텍스트가 로드될 때, 스프링은 @Transactional이 붙은 어노테이션이 적용된 클래스 또는 인터페이스를 찾아 프록시 객체를 생성하는 작업을 수행합니다. 이 때 리플렉션 API의 Proxy 클래스를 사용하여 인터페이스를 구현하는 프록시 객체가 생성됩니다. 생성된 프록시 객체는 원본 객체의 메소드 호출을 가로채고, 필요한 추가적인 처리를 수행한 후 실제 메소드를 호출합니다. 이 호출을 가로챌 때 InvocationHandler가 사용된다고 했는데, 어떤 원리로 동작하는지 자세히 살펴보겠습니다.

public class TransactionalInvocationHandler implements InvocationHandler {
    private final Object target;

    public TransactionalInvocationHandler(Object target) {
        this.target = target;
    }

    @Override
    public Object invoke(Object proxy, Method method, Object[] args) throws Throwable {
        if (method.getName().startsWith("perform")) {
            beginTransaction();
            try {
                Object result = method.invoke(target, args);
                commitTransaction();
                return result;
            } catch (Exception e) {
                rollbackTransaction();
                throw e;
            }
        } else {
            return method.invoke(target, args);
        }
    }

    private void beginTransaction() {
        System.out.println("Transaction started");
        // 트랜잭션 시작 로직
    }

    private void commitTransaction() {
        System.out.println("Transaction committed");
        // 트랜잭션 커밋 로직
    }

    private void rollbackTransaction() {
        System.out.println("Transaction rolled back");
        // 트랜잭션 롤백 로직
    }
}

TransactionalInvocationHandler를 만들어서 invoke()메소드에 트랜잭션 로직을 모두 작성했습니다. 실제 코드는 훨씬 복잡하지만 간단하게만 보았을 때 위 코드와 같습니다. 동작 순서를 살펴보자면,

1. 컨트롤러에서 ProductService의 perform() 메소드를 호출하면, 이 호출은 실제로 ProductService의 프록시 객체를 통해 메소드 호출이 이루어집니다.
2. 프록시 객체에서 invoke() 메소드를 호출하여 트랜잭션 관리 로직을 실행한 후, 프록시는 원본 ProductServiceImpl 클래스의 perform() 메소드를 호출합니다.
3. perform() 메소드의 실행이 완료되면, 그 결과는 invoke() 메소드를 통해 호출자에게 반환됩니다. 메소드 실행 중 예외가 발생하면, 이는 invoke() 메소드에서 상황에 따라 트랜잭션을 롤백할 수 있습니다.

JDK dynamic 프록시 방식의 경우 리플랙션을 활용하여 메소드를 호출하기 때문에 성능이 조금 아쉬울 수 있습니다. 하지만, 성능 차이가 미미하기 때문에 신경쓸 정도가 아니라고 하네요!

CGLIB 프록시

JDK dynamic 프록시 방식의 경우 interface가 필수적으로 필요합니다. interface가 없는 클래스에 @Transactional을 사용하는 경우 CGLIB 프록시 방식이 사용됩니다. CGLIB는 클래스를 상속하여 프록시 객체를 생성하는 방식을 사용합니다. 코드로 살펴보겠습니다.

public class ProductService {
    public void perform() {
        System.out.println("Performing a business logic");
        // 여기에 비즈니스 로직 구현
    }
}

public class ProductServiceProxyFactory {
    public static ProductService createProxy() {
        Enhancer enhancer = new Enhancer();
        enhancer.setSuperclass(ProductService.class);
        enhancer.setCallback(new MethodInterceptor() {
            @Override
            public Object intercept(Object obj, Method method, Object[] args, MethodProxy proxy) throws Throwable {
                // 트랜잭션 시작 로직
                System.out.println("Transaction started");
                Object result = null;
                try {
                    result = proxy.invokeSuper(obj, args);
                    // 트랜잭션 커밋 로직
                    System.out.println("Transaction committed");
                } catch (Exception e) {
                    // 트랜잭션 롤백 로직
                    System.out.println("Transaction rolled back");
                    throw e;
                }
                return result;
            }
        });
        return (ProductService) enhancer.create();
    }
}

JDK dynamic 프록시 방식과 크게 다르지 않습니다. perform() 메소드가 호출되면 intercept()가 먼저 호출된 후에 내부에서 invokeSuper() 메소드를 통해 perform()이 호출됩니다. JDK dynamic 프록시는 리플랙션 방식을 선택한 반면에, CGLIB는 바이트 코드를 조작하는 방식을 선택했습니다.

CGLIB는 런타임에 클래스의 바이트코드를 조작하여 프록시 클래스를 생성합니다. 이 과정은 일반적인 JDK dynamic 프록시보다 더 복잡하고, 초기 프록시 생성 시에 약간 더 많은 리소스를 사용할 수 있습니다. 하지만 생성이 된 후에 실행 속도는 JDK dynamic 프록시보다 빠르다는 장점이 있습니다.

스프링은 기본 설정인 경우 인터페이스가 존재하지 않는 경우에만 CGLIB를 채택하고 있습니다. 만약 설정파일에 proxy-target-class 속성을 true로 둔다면 클래스 기반으로 프록시를 생성합니다. 즉, 인터페이스가 존재하더라도 CGLIB 방식을 채택합니다.

그렇다면 왜 스프링은 default로 JDK dynamic 프록시 방식을 선택했을까요? CGLIB에는 아래와 같은 단점이 있기 때문입니다.

• 클래스의 제약: CGLIB는 final 클래스나 메소드에 대해서는 프록시를 생성할 수 없습니다. 이는 final 클래스나 메소드가 상속 또는 오버라이딩되지 않기 때문입니다.

• 복잡성: CGLIB는 JDK dynamic 프록시보다 복잡하게 구현되어 있고, 더 무겁습니다.

마무리

면접에서 transactional과 spring AOP 관련해서 깊이 있는 질문을 받았습니다. 제대로 대답하지 못해 아쉬워 정리해보았습니다.

B-Tree 란?

B-Tree는 균형 이진 트리(Balanced Binary Tree)의 일종으로, 데이터베이스 시스템과 파일 시스템에서 널리 사용되는 자료구조입니다. 대량의 데이터를 효율적으로 관리하고 검색할 수 있게끔 설계되어있습니다.

특징

B-Tree에서 지켜야하는 몇 가지 특징이 있는데요. 아래와 같습니다.

1. 균형 트리: B-Tree의 모든 Leaf 노드는 동일한 깊이를 가지며, 트리가 변경될 때마다 이 균형이 유지됩니다.
2. 다입도: B-Tree의 각 노드는 여러 개의 자식을 가질 수 있습니다. 이때 노드당 가질 수 있는 최대 자식의 수를 차수(order)라고 합니다. 차수를 m이라고 가정할 때, 최대 m개의 자식을 가질 수 있기 때문에 노드는 최대 2개의 키를 저장할 수 있습니다.
3. 키 정렬: 각 노드에 저장된 키는 정렬된 상태로 유지됩니다.
4. 분할 및 병합: 노드의 키가 너무 많아지면 노드가 분할되고, 반대로 키가 너무 적어지면 노드가 인접한 형제 노드와 병합됩니다.
5. 최소 사용률: B-Tree는 각 노드가 최소한 차수의 절반만큼 키를 가지도록 유지시킵니다. 만약 절반으로 나누어떨어지지 않다면 올림합니다.

목적

B-Tree의 주요 목적은 디스크 I/O 작업을 최소화하면서 대량의 데이터를 저장하고 검색하는 것입니다. 저는 그래서 메모리에 인덱스 테이블을 올려두고 작업하는줄 알았는데요. 그것이 아니었습니다. 일부의 index만 메모리에 올려둔다고 하네요.

디스크에서 데이터를 읽거나 쓸 때, 보통 한 번의 I/O 작업으로 디스크 내의 한 블록의 데이터를 읽거나 씁니다. B-Tree는 이러한 블록 단위의 I/O를 최적화하기 위해 설계되었다고 하는데요. 이때 노드마다 하나의 블록에 저장되는 방식을 이용하여 디스크 I/O를 최소한으로 줄입니다.

이진 트리를 이용하게 되면 각 노드는 하나의 키 밖에 가지지 못하기 때문에 공간 비효율적이게 됩니다. B-Tree는 이런 문제점을 개선하고자 이진 트리를 확장하여 N개의 자식을 가질 수 있도록 고안되었습니다. 이때 각 노드는 넣을 수 있는 양 만큼의 키를 저장하여 공간 효율적으로 디스크를 관리합니다.

동작 원리

차수(order)를 3이라고 가정하고 B-Tree를 차곡차곡 쌓아보겠습니다.

1. 키가 1과 20인 것이 tree에 있었다고 가정합니다.
2. 2를 추가하는 요청이 들어왔습니다. 2는 1보다 크고, 20보다 작기 때문에 1과 20 사이에 저장됩니다.
3. 2가 노드에 추가되었습니다. 그런데 노드에 2개의 키 밖에 저장하지 못하기 때문에 새로운 노드를 만들어야합니다.

4. 먼저 20을 떼어내서 새로운 노드를 만듭니다. 그리고 가운데 키 값이었던 2는 부모 노드로 만들어 승급시킵니다. 이렇게 노드가 2개 추가되었습니다.
5. 이번에는 10이 요청으로 들어왔습니다. 부모 노드에서 10이 2보다 큰 지 비교합니다. 2보다 크기 때문에 오른쪽 자식 노드로 이동합니다.
6. 자식 노드(leaf 노드)에 있던 20과 비교했을 때, 10은 20보다 작기 때문에 10을 20보다 앞에 둡니다. 이렇게 자식 노드가 정렬됩니다. 만약 중간 branch 노드였다면 자식 노드를 더 탐색해야했지만, leaf 노드이기 때문에 key를 추가했습니다.

7. 30이 추가되는 요청이 들어왔습니다.
8. leaf 노드까지는 잘 도착했지만, leaf 노드의 수용 공간이 다 찼습니다. 따라서 새로운 공간을 만들어주었습니다.
9. 새로운 leaf 노드를 만들었고, 20을 루트 노드로 승격시켰습니다. 이렇게 2보다 작으면 왼쪽 자식 노드, 2보다 크고 20보다 작으면 중간 자식 노드, 20보다 크면 오른쪽 자식 노드로 이동할 수 있게 했습니다.

10. 40이 추가되는 요청이 들어왔습니다.
11. 노드의 추가 없이 40이 오른쪽 자식 노드에 추가되었습니다.
12. 25가 추가되는 요청이 들어왔습니다.

13. 20보다 크기때문에 오른쪽 자식 노드로 25를 위치시킵니다. 하지만 자식 노드의 키 개수가 3개가 되었습니다.
14. 오른쪽 자식 노드에서 가장 큰 값인 40을 새로운 노드로 만들어 분리했습니다.
15. 그리고 30을 부모 노드로 승격시켰습니다. 이때도 문제가 발생합니다. 노드의 키 개수가 3이 되기때문에 부모 노드에서도 노드를 분리합니다.
16. 자식 노드와 같은 과정을 거치면 그림처럼 새로운 부모 노드가 생성됩니다.

위와 같은 로직으로 B-Tree의 키가 저장됩니다. 별 것 아닌 규칙들 같지만, 자연스레 모든 leaf 노드가 같은 레벨에 있는 것을 알 수 있습니다. 이렇게 B-Tree는 모든 검색에 대해 logN의 시간 복잡도를 보장하고 있습니다.

B-Tree 조회 방식

B-Tree 의 경우에는 모든 key 값이 pk 값이나 DB 레코드 포인터를 가지고 있습니다. 만약 Primary Key Index 라면 (pk, 레코드 포인터) 쌍을 노드에 저장하고 있고, Secondary Index 의 경우에는 (칼럼 값, pk) 쌍을 노드에 저장하고 있습니다. 중요한 건, 부모 노드, 브랜치 노드, 리프 노드 상관 없이 모든 노드의 key가 pk 값이나 레코드 포인터를 저장하고 있다는 것입니다.

B+Tree

지금까지 B-Tree에 대해 살펴보았는데요. 실제로 mysql은 B-Tree의 개념을 이용한 B+Tree를 사용하여 index 테이블을 구성한다고 합니다. B+Tree는 B-Tree와 어떤 부분이 다를까요?

1. B+Tree에서 모든 키 값들은 leaf 노드에만 저장되며, 브랜치 노드나 루트 노드는 leaf 노드들로의 경로를 가리키는 용도로 사용됩니다. 루트와 브랜치 노드들에는 키 값만 있고, 실제 레코드에 대한 포인터는 leaf 노드에만 존재합니다.
2. leaf 노드들이 양방향 혹은 단방향 연결 리스트로 서로 연결되어 있습니다. 덕분에 범위 검색이 더 쉽고 효율적입니다.
3. 키가 leaf 노드에만 존재하므로, 루트와 브랜치 노드에 더 많은 키를 한 페이지에 저장할 수 있어 디스크 I/O를 줄이는 데 도움이 됩니다.

위 그림과 같이 leaf 노드에만 레코드 포인터를 저장하고 있습니다. 그리고 linked list 형태로 leaf 노드 간의 범위 검색이 가능하도록 설계했습니다. (mysql은 더블 링크드 리스트라고 합니다.)

마무리

index가 어떤 방식으로 데이터베이스 레코드 포인터를 검색하는지 알았습니다. 다음에는 mysql 만의 index를 효율적으로 사용하는 방식에 대해 알아보겠습니다.

Database Connection Pool?

DBCP(Database Connection Pool)은 데이터베이스 연결을 관리하고 효율적으로 재사용하기 위한 자바 라이브러리 또는 프레임워크입니다. DBCP는 데이터베이스와의 연결 생성 및 관리를 단순화하며, 다수의 클라이언트 또는 스레드에서 동시에 데이터베이스 연결을 사용할 때 발생할 수 있는 리소스 부족 문제를 방지하는 데 도움을 줍니다.

동작 방식

어플리케이션 서버에서 Spring 어플리케이션이 돌아가는데요. 이때 유저의 요청을 받은 Spring은 connection pool을 통해 데이터베이스와 미리 연결되어 있는 connection을 받습니다.

"미리 연결"되어 있다고 했는데, 이 부분이 connection pool의 존재 이유이고 성능을 높일 수 있는 핵심이라고 생각합니다. 그렇다면 왜 database connection을 미리 연결해두는 것일까요?

Database connection의 시작과 종료

쿼리의 동작 방식을 생각해보겠습니다. Spring에서 쿼리를 작성하면, 그 쿼리는 데이터베이스에 명령을 보내고 쿼리문을 통해 원하는 데이터를 전달받을 것입니다. 이때 데이터베이스와의 connection을 통해 데이터베이스로 요청을 전달하고 데이터베이스한테 정보를 응답받습니다. 이 connection은 TCP 통신을 통해 이루어집니다. TCP 특징상 연결 시에 3-handshake를 진행하고 연결 해제 시에 4-handshake를 진행합니다. TCP의 이런 특징 때문에 connection의 연결과 해제 시에 많은 시간 비용이 듭니다.

Connection Pool의 필요성

connection pool은 데이터베이스와의 연결을 효율적으로 관리하는 데 도움을 준다고 했는데요. 데이터베이스와 TCP 연결을 미리 해놓은 connection들을 connection pool에 저장함으로써 속도에 대한 성능을 챙기게 됩니다. 따라서 connection pool의 존재 덕분에 Java 스레드는 connection을 연결하거나 연결 해제하지 않고, 연결되어있는 connection을 connection pool로부터 받기만 하면 됩니다. 작업이 완료되면 connection을 connection pool에 반납하는 방식이죠.

1. Connection 획득

2. 쿼리 실행

3. Connection 반납

데이터베이스 설정

데이터베이스 Connection은 Spring과 Database를 연결하는 작업이기 때문에 개발자는 Spring 관련 설정과 Database 설정 모두 알고 있어야 합니다. 우선 Database 설정부터 알아보겠습니다.

Database 입장에서는 부하를 방지하기 위해 최대 연결 가능한 수를 제한할 필요가 있습니다. 이 제한을 max_connections라고 합니다. Connection Pool의 connection 수와 max_connections 수의 설정을 바꿔가며 상황을 살펴보겠습니다. (Connection Pool에 저장할 수 있는 최대 connection 수를 HikariCP에서는 maximumPoolSize라고 하는데, 편의상 maximumPoolSize로 계속 지칭하겠습니다.)

1. maximumPoolSize <= max_connections

max_connections가 더 크거나 같은 경우에는 Database 측에서 낭비되고 있는 리소스가 생깁니다. 만약 낭비되는 리소스가 많다면 서버 비용이 더 부담되겠죠... HikariCP에서는 권장하지 않는 방법이라고 합니다.

2. maximumPoolSize > max_connections

그림처럼 connection pool에서 연결되지 못한 connection이 존재하게 됩니다. Database 입장에서는 최대 허용 기준치가 찼기 때문에 요청을 거절한 것입니다. 이런 경우에는 connection pool에 최대 4개의 연결을 허용했다고 하더라도 3개까지만 연결되는 현상이 발생합니다.

wait_timeout

만약 max_connections 수치가 maximumPoolSize보다 크면 리소스 낭비가 일어날 수 있다고 윗 부분에서 언급했는데요. 이것 말고도 다른 방법으로도 리소스 낭비가 일어날 수 있습니다. 만약 한 Connection이 중간에 비정상적으로 끊기는 경우가 그런 경우입니다. Database 입장에서는 한 Connection에 요청이 들어오지 않을 뿐 close에 대한 요청이 없었기 때문에 connection이 유지되고 있다고 생각할 것입니다. 실제로 요청을 보내고 있지 않은 경우라면 상관 없지만, 오류로 인해 연결이 끊긴지 모르는 것은 문제가 됩니다.

그래서 MySql에는 wait_timeout이라는 옵션이 존재합니다. 이름에서 유추할 수 있듯이, Database에서 스프링 어플리케이션 connection의 대기 시간을 설정하는 변수입니다. 이 변수는 클라이언트와 Database 서버 간의 connection이 유효한 상태로 유지되는 시간을 초 단위로 지정합니다. 만약 클라이언트가 지정된 시간 동안 서버와 통신하지 않으면, 데이터베이스 서버는 해당 connection을 끊습니다. 그로 인해 connection 오류에 대한 해결을 할 수 있는 것이죠.

또, 만약 wait_timeout을 60초로 설정했다고 가정했을 때 60초 안에 요청이 들어오면 Database는 시간 count를 다시 0초로 초기화시킵니다. 이렇게 요청이 계속 오면 60초가 지났다 하더라도 연결이 끊어지지 않고 계속 같은 연결된 상태로 있을 수 있는 것이죠.

Spring Application 설정

이번에는 Spring Application 에서 Connection Pool을 설정하는 방법에 대해 알아보겠습니다. 앞으로 서술할 내용들은 Spring 2.0부터 지금까지 채택되고 있는 HikariCP 기준으로 작성할 예정입니다.

maximumPoolSize

위에서 잠깐 살펴보았는데요. Connection Pool에 들어갈 수 있는 최대 connection 수를 의미합니다.

minimumIdle

Connection Pool에서 유지하는 최소한의 idle connection 수를 의미합니다. (idle connection == 일 없는 connection) Connection Pool은 일반적으로 최소한의 idle connection을 유지하여, 스프링 어플리케이션이 Database와의 연결을 필요로 할 때 추가 연결을 생성하는 시간과 비용을 절감하도록 도와줍니다. 예를 들어, minimumIdle을 5로 설정하면 Connection Pool은 항상 최소 5개의 idle Connection을 유지하려고 노력합니다. 즉, TCP 연결이 끊기지 않도록 노력하는 connection 수 입니다.

minimumIdle 의문

그렇다면 의문이 생깁니다. 앞전에 Database에는 wait_timeout이 존재한다고 했는데요. wait_timeout이 60초로 설정되어있다고 가정하고, 60초동안 유저가 아무 요청도 보내지 않으면 결국 모든 connection이 끊어지는 것이 아닌가 의심이 들었습니다. HikariCP 코드를 보니 아래와 같이 health check를 하는 부분이 있었습니다. 주기적으로 health check를 하면서 idle connection을 유지하고 있었습니다.

자세한 스케줄링까지는 검색이 되지 않아 살펴볼 수 없었지만 해당 메소드를 통해 주기적으로 health check를 하는 요청을 Database로 보내고 있다는 것은 알 수 있었습니다.

maximumPoolSize와 minimumIdle 주의점

maximumPoolSize와 minimumIdle을 커스텀 설정할 때 주의해야하는 부분이 있습니다. minimumIdle은 절대로 maximumPoolSize보다 크면 안됩니다. maximumPoolSize가 minimumIdle보다 우선 순위가 높기 때문인데요. 예시를 통해 조금 더 자세하게 살펴보겠습니다. maximumPoolSize를 4, minimumIdle을 2로 설정했다고 가정하겠습니다.

minimumIdle은 2이기 때문에 아무 요청이 없다면 위 그림과 같이 2개의 connection이 존재할 것입니다. 만약 이때 getConnection() 요청이 들어오면 어떻게 될까요?

Database와 연결되어있는 connection을 java thread에 빌려줍니다. 이 때, minimumIdle이 위반되기 때문에 Connection Pool은 재빠르게 새로운 connection을 연결합니다. 그러면 만약 Connection Pool에 maximumPoolSize인 4까지 다 채워지게 된다면 어떻게 될까요?

maximumPoolSize가 4이기 때문에 이를 넘는 connection은 만들지 않습니다. 이 때 minimumIdle는 2가 되어야하는 규칙은 maximumPoolSize에 밀려 무시됩니다!

또 정말 중요한 점이 있습니다. HikariCp에서는 maximumPoolSize와 minimumIdle를 같게 두는 것을 권장합니다.

This property controls the minimum number of idle connections that HikariCP tries to maintain in the pool. If the idle connections dip below this value and total connections in the pool are less than maximumPoolSize, HikariCP will make a best effort to add additional connections quickly and efficiently. However, for maximum performance and responsiveness to spike demands, we recommend not setting this value and instead allowing HikariCP to act as a fixed size connection pool. Default: same as maximumPoolSize

트래픽이 확 몰리는 경우에 대비하기 위해 이렇게 default로 두는 것을 권장한다고 하네요.

maxLifeTime

Connection Pool에서 connection의 최대 수명을 뜻합니다. maxLifeTime을 60초로 잡았다고 가정을 한다면 60초마다 새로운 connection을 만든다는 이야기입니다. 그렇다면 굳이 왜 살아있는 connection을 재설정하는걸까요? 크게 2가지 이유가 있습니다.

1. 자원 누수 방지: 연결이 오랜 시간 동안 열려 있으면 자원이 소비되며, 일정 시간 이상 동안 활성화되지 않는 연결은 자원 누수를 발생시킬 수 있습니다. 따라서 유효기간을 설정하여 자원 누수를 막아주는 것입니다.
2. 보안: 연결이 오랜 시간 동안 열려 있으면 보안 취약점을 만들 수 있습니다. connection을 계속 교체해가며 보안을 높이는 효과를 볼 수 있습니다.

Connection Pool 내부에 있는 idle Connection은 60초로 설정된 maxLifeTime이 지나면 새로 connection을 교체하는데, java thread가 사용하고 있다면 java thread로부터 반납 받아야 connection을 새롭게 설정할 수 있습니다. 그러면 여기서 문제점이 보이실텐데요. 만약 java thread의 오류로 connection을 계속 점유하고 있다면 어떻게 될까요?

Database의 wait_timeout이 동작하여 connection이 끊어지게 될 것입니다. 그런데 만약 정말 오래걸리는 작업이어서 connection이 늦게 Connection Pool로 반환된 경우도 있겠죠. 그런 경우에는 끊어진 connection 이기 때문에 예외가 발생하게 됩니다. 따라서 Connection Pool로 잘 반환할 수 있도록 하는 것이 정말 중요하겠죠. 또 만약 admin을 위한 통계 기능 어플리케이션의 경우 넉넉하게 Database와 어플리케이션 모두 timeout을 넉넉하게 두면 좋을 것 같습니다.

maxLifeTime 주의점

HikariCP에서는 maxLifeTime은 Database나 인프라의 timeout보다 몇 초 더 짧게 설정하는 것을 권장하고 있습니다.

This property controls the maximum lifetime of a connection in the pool. An in-use connection will never be retired, only when it is closed will it then be removed. On a connection-by-connection basis, minor negative attenuation is applied to avoid mass-extinction in the pool. We strongly recommend setting this value, and it should be several seconds shorter than any database or infrastructure imposed connection time limit. A value of 0 indicates no maximum lifetime (infinite lifetime), subject of course to the idleTimeout setting. The minimum allowed value is 30000ms (30 seconds). Default: 1800000 (30 minutes)

왜 그럴까요? 한 번 maxLifeTime과 wait_timeout을 60초로 같게 설정해보겠습니다. 그리고 Database와 어플리케이션 모두 0초에서 타이머를 시작했다고 가정하겠습니다.

만약 59.9초에 쿼리 요청을 Database로 전달하면 maxLifeTime에 위배되지 않기 때문에 성공적으로 전송됩니다. 하지만 전송 도중에 60초가 땡하고 울리게되면 wait_timeout에서 connection 자원을 정리할 것입니다. 결국 쿼리가 도착하면 connection 자원이 되었기 때문에 요청이 성공하지 않을 것입니다. 타이밍이 아주 잘 맞아야하는 경우긴 하지만 이를 방지하기 위해 HikariCP는 maxLifeTime을 wait_timeout보다 몇 초 작게 설정하라고 권장하고 있었던 겁니다.

ConnectionTimeout

Java thread가 Connection Pool에서 connection을 구하기 위해 대기하는 시간입니다. 이미 Connection Pool의 모든 connection이 사용중일 때 발생합니다. HikariCP는 default를 30초로 잡아두었는데, 이렇게 되면 30초동안 사용자는 아무 응답도 받지 않고 그저 로딩 화면만 보고 대기하게 됩니다. 저는 티켓팅이나 수강신청을 할 때 대기중인 화면이 바로 떠올랐습니다. 서비스에 따라 다르겠지만 티켓팅이나 수강 신청과 같은 서비스가 아니라면 30초보다 적게 설정하는 것이 좋을 것 같습니다. 유저를 대기시키기보다는 요청이 많다는 에러 메시지를 보여주는 것이 더 바람직해보이기 때문입니다.

마무리

변수를 적절하게 설정해보기 위해 미리 HikariCP에 대해 학습해보았습니다. 적절한 connection 변수를 찾는 방법도 부하테스트를 통해 알아보도록 하겠습니다.

참고

• https://www.youtube.com/watch?v=zowzVqx3MQ4&t=261
• https://github.com/brettwooldridge/HikariCP

그림과 같이 V1이 종료된 후부터 V2가 정상 작동 되기까지 서버를 다운시켰습니다. 이 다운되어있는 시간은 다운 타임 이라고 합니다. 저희 서비스는 다운 타임이 약 3분이었는데요. 이 3분동안 유저가 서비스를 이용하지 못하면 불편하겠죠...?

그래서 중단 배포에서 무중단 배포로 방식을 교체하여 제로 다운 타임을 만들어 유저의 불편을 줄였습니다.

무중단 배포?

중단 배포와 다르게 서버가 다운되어있는 시간 없이 새로운 버전으로 교체하는 배포 방법을 뜻합니다. 무중단 배포 전략으로 크게 3가지가 있는데요. 한 번 알아보겠습니다.

Rolling update 배포

로드밸런서로 연결되어있는 서버들을 순차적으로 하나씩 새로운 버전으로 변환시키는 방식입니다. 배포되어있는 서버를 하나씩 교체하는 방식이라고 생각하시면 편합니다!

연결되어있는 서버를 하나씩 멈추고 새로운 버전을 교체하고 있습니다. 부가적인 서버 자원을 사용하지 않고도 배포할 수 있다는 장점이 있지만 배포되는 동안에는 평소보다 트래픽 부하가 더 걸린다는 단점이 있습니다.

윗 그림의 롤링 방식은 추가적인 서버 자원을 사용하지 않고 배포 동안에 트래픽 부하를 더 주는 방식이지만 반대의 방식도 존재합니다. 추가 서버를 하나 더 띄우고, 업데이트를 위해 정지해놓은 서버 때문에 추가적인 트래픽 부하가 걸리지 않도록 하는 방법입니다. 추가적인 서버 비용이 걱정되는 경우에는 전자를, 트래픽 부하가 걱정되는 경우에는 후자를 선택하면 좋을 것 같습니다.

또, 롤링 배포 방식에서는 기존 버전(V1)과 새로운 버전(V2)의 인스턴스가 동시에 실행될 수 있기 때문에 두 버전 간의 호환성이 매우 중요합니다.

예를 들어 "GET /articles" API가 V1에서 사용되고 있는데, V2에서 해당 API가 제거되었다면, 이는 큰 문제가 될 수 있습니다. 왜냐하면 V2로의 업데이트 과정 중에는 V1과 V2 서버가 동시에 존재하게 되고, 이 때 유저가 "GET /articles" API를 호출하면 일부는 오류 응답을 받게 될 것입니다.

이러한 호환성 문제는 API 엔드포인트뿐만 아니라 데이터베이스 스키마 등 여러 계층에서 발생할 수 있습니다! 따라서, 롤링 배포 전략을 수행할 때는 호환성 문제를 미리 고려하여 배포 전에 꼼꼼히 테스트를 수행해야 합니다.

Blue-Green 배포

Blue-Green 배포는 두 개의 독립적인 환경 Blue 환경과 Green 환경을 가지고 진행되는 배포 전략입니다. 여기서 Blue는 현재 운영중인 환경을 나타내며, Green은 새로운 버전의 환경을 의미합니다. Green의 배포 준비가 완료되면 Blue 환경에서 Green 환경으로 한 번에 전환합니다.

V2가 배포된 순간부터 로드 밸런서는 V2로 모든 트래픽을 이동시키고, V1은 마지막 트래픽의 작업이 끝나면 종료됩니다. 정말 찰나의 순간 V1과 V2 서버가 동시에 켜져있다고 생각하시면 됩니다!

롤링 배포와 다르게 한 번에 버전을 바꾸기 때문에 버전 호환에 대한 문제가 발생하지 않습니다. 또, 만약 새로운 버전에 문제가 발생하면 트래픽을 다시 Blue 환경으로 전환하여 이전 버전으로 빠르게 롤백할 수 있습니다.

단점 또한 존재하는데요. 짧은 시간이지만 두 버전이 동시에 실행되고 있는 시간도 있기 때문에 추가적인 서버 비용이 발생합니다.

Canary 배포

카나리 배포 전략은 서비스의 새로운 버전을 모든 사용자에게 바로 제공하는 것이 아니라, 먼저 일부 사용자에게 제공하여 새로운 버전의 안정성과 성능을 검증하는 배포 전략입니다. 광산에서 독가스를 감지하기 위해 캐나리 새를 사용한 것에서 유래되었다고 합니다!

절차

• 평가 단계: 먼저 새로운 버전(V2)를 제한된 사용자 그룹에 배포합니다. 이 사용자 그룹을 "카나리" 그룹이라고 합니다.
• 모니터링 단계: 카나리 그룹의 피드백과 시스템의 메트릭을 모니터링하여 V2의 문제점을 파악합니다.
• 확장 배포 단계: 앞선 단계에서 문제가 없었다면 V2 사용자 그룹을 점진적으로 확대합니다.
• 전체 배포 단계: V2를 100% 배포합니다.

카나리 배포의 경우 새로운 버전으로 업데이트하면서 발생하는 문제점들을 초기에 확인할 수 있기 때문에 빠른 롤백이 가능합니다. 또, 초기 단계에서 사용자 피드백을 받아 빠르게 수정 및 개선할 수 있습니다. 하지만, 롤링과 블루-그린 배포 전략에 비해 비용이 많이 발생한다는 단점이 있습니다.

배포 전략 선택

저희 팀은 Blue-Green 전략을 선택했습니다.

우선 rolling 방식을 사용했을 때는 빠르게 롤백할 수 있는 역량이 부족하다고 판단했습니다. 롤백하는 시간 때문에 몇몇 사용자들은 장시간 에러 페이지를 만날 수 있다는 생각에 Blue-Green 방식을 선택했습니다.

카나리 방식은 사용자가 많아야 의미 있는 전략이라고 생각합니다. 저희는 사용자가 100명대인 작은 서비스이기 때문에 카나리 전략은 생각하지 않았습니다.

추가적인 서버 리소스가 드는 단점이 있지만, 구동 중인 어플리케이션의 수가 2개 밖에 안되기 때문에 비용 체감이 작을 것이라고 생각하여 큰 단점이라고 생각하진 않았습니다.

사실, 서버가 단일 어플리케이션 환경으로 구성되어있기 때문에 rolling, Blue-Green, Canary 모두 같은 의미가 됩니다. 하지만 Blue-Green에 어울린다고 생각해 Blue-Green 전략을 선택했다고 언급한 것입니다.

구현 과정

하나의 nginx에 spring application이 하나 연결된 상태라고 가정하겠습니다.

초기 환경

Nginx의 리버스 프록시로 연결된 스프링 서버 컨테이너가 있습니다. 그리고 github actios를 이용하여 CI/CD를 진행합니다. ssh 연결이 사설 ip에서만 가능하기 때문에 배포는 self-hosted runner를 사용했습니다.

docker-compose 생성

컨테이너를 빌드하기 위해 docker-compose를 이용했습니다.

version: '3.9'

services:
  dev1:
    container_name: spring-baton1
    image: '{계정 명}/{이미지명}:{태그 이름}'
    ports:
      - '8080:8080'
    environment:
      - TZ=Asia/Seoul
    networks:
      - baton

  dev2:
    container_name: spring-baton2
    image: '{계정 명}/{이미지명}:{태그 이름}'
    ports:
      - '8081:8080'
    environment:
      - TZ=Asia/Seoul
    networks:
      - baton

networks:
  baton:
    external: true

dev1이 구동중인 경우에는 dev2가 새로운 버전으로 배포되고, dev2가 구동중인 경우에는 dev1이 새로운 버전으로 배포되는 방식을 선택했습니다. dev1과 dev2의 다른점은 8080 포트냐, 8081 포트냐 입니다. 스프링 컨테이너와 데이터베이스 컨테이너가 baton 네트워크로 묶여 있어 추가적인 네트워크 설정도 해주었습니다. 만약 네트워크 설정을 따로 하시지 않았다면 networks 부분은 제거하셔도 됩니다.

nginx 파일 수정

/etc/nginx/nginx.dev1.conf 파일과 /etc/nginx/nginx.dev2.conf 를 만들어 컨테이너를 가리키는 포트만 다르게 두었습니다. 새로운 nginx.dev1.conf와 nginx.dev2.conf 파일은 nginx.conf에서 복제하였습니다. 보안을 위해 바뀐 부분만 보여드리겠습니다.

...
location /api {
    ...
    proxy_pass http://127.0.0.1:8080;
    ...
}
...

nginx.dev1.conf에서는 proxy_pass를 8080 포트로 두었고, nginx.dev2.conf에서는 8081로 두었습니다! 만약 sites-enabled 나 sites-available 경로의 파일에 서버 포트를 설정하셨다면 해당 파일을 2개로 나누면 됩니다.

배포 스크립트 작성

#!/bin/bash

IS_DEV1=$(docker ps | grep spring-baton1)
DEFAULT_CONF=" /etc/nginx/nginx.conf"
MAX_RETRIES=20

check_service() {
  local RETRIES=0
  local URL=$1
  while [ $RETRIES -lt $MAX_RETRIES ]; do
    echo "Checking service at $URL... (attempt: $((RETRIES+1)))"
    sleep 3

    REQUEST=$(curl $URL)
    if [ -n "$REQUEST" ]; then
      echo "health check success"
      return 0
    fi

    RETRIES=$((RETRIES+1))
  done;

  echo "Failed to check service after $MAX_RETRIES attempts."
  return 1
}

if [ -z "$IS_DEV1" ];then
  echo "### DEV2 => DEV1 ###"

  echo "1. DEV1 이미지 받기"
  docker-compose pull dev1

  echo "2. DEV1 컨테이너 실행"
  docker-compose up -d dev1

  echo "3. health check"
  if ! check_service "http://127.0.0.1:8080"; then
    echo "DEV1 health check 가 실패했습니다."
    exit 1
  fi

  echo "4. nginx 재실행"
  sudo cp /etc/nginx/nginx.dev1.conf /etc/nginx/nginx.conf
  sudo nginx -s reload

  echo "5. DEV2 컨테이너 내리기"
  docker-compose stop dev2
  docker-compose rm -f dev2

else
  echo "### DEV1 => DEV2 ###"

  echo "1. DEV2 이미지 받기"
  docker-compose pull dev2

  echo "2. DEV2 컨테이너 실행"
  docker-compose up -d dev2

  echo "3. health check"
  if ! check_service "http://127.0.0.1:8081"; then
      echo "DEV1 health check 가 실패했습니다."
      exit 1
    fi

  echo "4. nginx 재실행"
  sudo cp /etc/nginx/nginx.dev2.conf /etc/nginx/nginx.conf
  sudo nginx -s reload

  echo "5. DEV1 컨테이너 내리기"
  docker-compose stop dev1
  docker-compose rm -f dev2
fi

코드 순서대로 알아보겠습니다.

1. 현재 실행중인 컨테이너가 spring-baton1인지 확인합니다.
2. if [ -z "$IS_DEV1" ] 에서 만약 $IS_DEV1 이 비어있다면 참을 반환하는데, 그 경우는 dev2가 실행중인 경우이기 때문에 dev1을 새로 배포시키는 로직을 수행시킵니다. (if와 else 부분의 로직은 같기 때문에 if 부분의 로직만 작성하겠습니다.)
3. 이미지를 pull 받습니다.
4. 컨테이너를 실행시킵니다.
5. dev1 서비스가 정상적으로 실행되는지 확인합니다. 5-1. check_service() 함수에서 3초에 한 번씩 서비스 상태를 확인합니다. 5-2. 만약 서비스가 구동중이지 않다면 계속해서 서비스 상태를 확인하는데, 20번이 넘어가면 실패를 반환합니다. 5-3. 서비스가 20번 안에 구동된다면 성공을 반환합니다. 5-4. 함수가 실패한다면 곧바로 스크립트를 오류 상태로 종료시킵니다.
6. 이전에 작성한 nginx.dev1.conf 파일은 nginx.conf 파일로 복사해서 nginx가 바라보는 포트를 바꿉니다. 그 후에 reload합니다.
7. 운영중이던 구 버전의 dev2를 종료시킵니다.

의문 1

다른 블로그들을 참고하여 쉘 스크립트를 작성했는데요. 코드에 의문점이 있었습니다. 기존 프로세스에 아직 많은 트래픽이 남았는데, nginx가 새로운 프로세스를 시작하게 되면 기존 프로세스의 남아있는 트래픽은 처리되지 않지 않을까? 하는 걱정이 있었습니다. 우려했던 점에 대해 검색하고 나서 nginx reload에 대해 몰랐던 점을 하나 배웠는데요. nginx -s reload는 nginx를 재배포하는 것이 아닌 설정을 다시 읽어들이는 방법이라고 합니다. reload 시에 다음과 같은 과정으로 실행됩니다!

1. nginx는 새로운 worker 프로세스를 시작하여 새로운 설정으로 실행합니다.
2. 모든 새로운 트래픽은 이 새로운 worker 프로세스에 의해 처리됩니다.
3. 기존의 worker 프로세스는 현재 활성화된 트래픽들을 계속 처리하다가, 그 트래픽들이 종료되면 자동으로 종료됩니다.

nginx가 이런 부분도 신경써주고 있어서 놀랐습니다.

의문 2

비슷한 다른 의문도 있었는데요. 이번에는 어플리케이션 쪽에서 아직 연산이 끝나지 않은 경우에 컨테이너가 내려가면 어떡하지 걱정되었습니다. 현재 상황에서는 종료 명령이 2가지가 있습니다. docker stop과 스프링 어플리케이션의 종료입니다.

스프링 어플리케이션의 종료부터 알아보겠습니다. 스프링부트 2.3 버전부터 Graceful Shutdown을 지원한다고 합니다. 따라서 application 파일에 server.shutdown=graceful를 두면 Hard Shutdown으로 종료되지 않고 모든 요청을 완료한 후에 어플리케이션이 종료됩니다. 그래서 어플리케이션 파일에 graceful shutdown을 설정해주었습니다!

이제 docker stop 에 대해 알아보겠습니다. docker stop 명령이 들어오면 docker는 컨테이너의 주 프로세스에 SIGTERM 신호를 전송합니다. 만약 10초 안에 프로세스가 종료되지 않는다면 SIGKILL 신호를 전송합니다. 여기서 SIGTERM 은 프로세스에게 종료 명령을 내리는 것이고, SIGKILL은 강제 종료의 명령입니다.

자 그러면 도커와 어플리케이션이 종료되는 순서는 아래와 같겠네요.

1. 도커가 스프링부트 어플리케이션에 종료 명령
2. 명령을 받은 스프링부트는 shutdown을 실행 (graceful shutdown으로 설정해놓았기 때문에 graceful shutdown)
3. 만약 10초가 지나도 스프링부트가 종료되지 않으면 어플리케이션 강제 종료

무서운건 가장 마지막 부분인데요. 상황에 따라서 10초안에 모든 요청의 로직이 끝나지 않을 수도 있습니다. 그런 경우에는 docker-compose 파일에 stop_grace_period: 60s와 같이 SIGKILL 까지의 시간을 명시하여 종료까지 시간을 더 넉넉하게 줄 수도 있습니다.

결과

지금까지 잘 동작하는지 실험해보겠습니다.

스크립트는 잘 실행되었습니다.

도커 컨테이너도 잘 올라가있군요. 이번엔 반대 방향으로의 배포도 확인해보겠습니다.

잘 동작하는 것을 확인했습니다.

github actions

배포 스크립트가 잘 동작하는 것을 확인했으니 이번에는 CD 파일을 작성해보겠습니다. 이전 글에서 CI/CD 배포 방법을 살펴보아서 깊게 다루지 않겠습니다. 해당 게시글의 cd 부분만 조금 수정했습니다. 수정된 부분은 아래와 같습니다.

  deploy:
    runs-on: [ self-hosted, Linux, ARM64, dev ]
    needs: build

    steps:

      - name: Pull Latest Docker Image
        run: |
          sudo docker login --username ${{ secrets.DOCKERHUB_DEV_USERNAME }} --password ${{ secrets.DOCKERHUB_DEV_TOKEN }}
          sudo docker pull 2023baton/2023baton:latest

      - name: Docker Compose
        run: |
          /home/ubuntu/zero-downtime-deploy.sh
          sudo docker image prune -af

self-hosted runner로 서버 내에서 코드를 실행시킵니다. 도커에 로그인 한 후에 이미지를 pull 받습니다. 그 후에 위에서 작성한 무중단 배포 파일을 실행하고 필요없는 이미지를 삭제합니다.

마무리

완벽한 무중단 배포 과정은 아닙니다. 배포된 것을 확인하는 부분에서 단순히 root endpoint인 127.0.0.1을 확인했는데, 이건 "스프링이 켜지긴 했다." 라는 뜻입니다. 데이터베이스 연결 상태, 외부 서비스와의 통신 상태 등 필요한 부분을 health check하는 과정이 필요합니다. 그래야 정말 안정적이라고 할 수 있으니까요. actuator 의존성을 추가해 health check 하는 것을 생각해보았지만, actuator를 설정하는 순간 해커에게 노출되는 부분이 많습니다. 최근 저희 서비스에 "/actuator/health" 요청을 보낸 해커가 있더라고요... 보안에 대한 학습이 부족한 탓에 조금은 아쉽지만 curl http://127.0.0.1:8080으로 배포 상태를 확인해보기로 했습니다.

참고

• https://mr-popo.tistory.com/230
• https://tecoble.techcourse.co.kr/post/2022-11-01-blue-green-deployment/
• https://hudi.blog/zero-downtime-deployment/

성능 테스트란?

성능 테스트(Performance Testing)는 특정 상황에서 소프트웨어, cpu, 램 등의 성능을 측정하는 테스트입니다. 시스템이 특정 작업을 수행하는 데 걸리는 시간, 처리량, 사용 가능한 리소스 등을 평가하기 위해 수행됩니다.

즉, 실제 트래픽 상황에서 정상적으로 동작하는지, 언제 어떤 상황에서 서버가 터지는지 확인하는 작업입니다. 어느정도 트래픽까지 버틸 수 있는지 미리 확인하면 실제 서비스 운영 상황에서 부하가 발생할 것 같을 때 미리 여유롭게 대응할 수 있기 때문에 서버가 다운되는 일은 줄어들 것입니다!

성능 테스트에 여러 카테고리가 있는데 그 중에 부하 테스트(Load Testing)와 스트레스 테스트(Stress Testing)를 알아보도록 하겠습니다.

부하 테스트

시스템이 예상되는 작업 부하를 얼마나 잘 처리할 수 있는지 평가하는 테스트입니다. 시스템의 처리 능력, 응답 시간, 리소스 사용량 등을 측정합니다. 실제 있을법한 트래픽을 시나리오로 두고 시스템이 잘 처리하는지 확인하는 과정이라고 이해했습니다.

스트레스 테스트

시스템이 극도로 높은 부하나 다양한 스트레스 조건에서 어떻게 동작하는지를 확인하는 테스트입니다. 시스템의 한계를 찾고, 언제 어떻게 실패하는지, 그리고 얼마나 빨리 정상 상태로 회복하는지를 알아보기 위해 진행합니다. 스트레스 테스트를 진행하면 서버가 터지는 순간을 알기 때문에 실제 서비스에서 최악의 재앙을 미리 대비할 수 있습니다.

k6 vs jmeter

성능 테스트 도구들 중에 떠오르는 신성 K6와 가장 널리 쓰이는 Jmeter 중에서 고민했습니다.

작성해야하는 스크립트 형식

• K6: javascript(typescript)
• Jmeter: XML

두 스크립트 모두 상관이 없었지만, 자바스크립트가 XML 보다는 5배 이상 짧았습니다. K6가 Jmeter에 비해 빠르게 코드를 작성할 수 있고, 작성한 코드를 이해하기 편했습니다.

레퍼런스 양

아무래도 오래되었고, 부동의 1위를 지키고 있는 JMeter가 레퍼런스 수가 많았습니다. 하지만 K6 공식 문서가 잘 되어있기 때문에 트러블 슈팅만 조금 힘들 수 있을 뿐이지 크게 곤란할 것 같진 않았습니다.

리소스 효율

K6는 Go로 작성되어 있고, Jmeter는 Java로 작성되어 있습니다. Go가 Java보다 더 적은 메모리와 CPU를 사용하므로 리소스 사용 면에서 K6가 더 유리합니다.

GUI 제공

• K6: GUI 미제공
• Jmeter: 자체 GUI 제공

Jmeter의 경우 GUI를 지원합니다. Jmeter 깃허브에서 GUI 사진을 따왔는데, 사진과 같습니다. 썩 예쁜 디자인은 아니었습니다. 하지만 확실히 알아보기에는 편한 것 같습니다. K6는 GUI를 지원하지 않는데 저희 팀은 딱히 상관 없다고 생각했습니다. 스크립트 가독성이 좋아서 GUI에 밀린다고 생각하지 않았습니다.

스레드

• K6: 가상 사용자 1명당 goroutine 1개
• Jmeter: 가상 사용자 1명당 스레드 1개

goroutine은 OS 쓰레드보다 훨씬 가볍게 비동기 Concurrent 처리를 구현하기 위하여 만든 것으로, 기본적으로 Go 런타임이 자체 관리한다.

고루틴의 정의 중 일부인데요. java는 OS의 스레드에 직접 매핑되는 반면 고루틴은 경량화된 스레드로 동작합니다. 성능면에서 K6가 더 우월했습니다.

결론

속도, 리소스 효율성 면에서 K6가 더 유리하기 때문에 K6를 선택하게 되었습니다.

K6 설치

맥 기준입니다.

brew install k6

위 명령어로 k6가 설치됩니다.

스크립트 작성

미리 간단한 게시글 GET api를 만들었습니다.

@RequiredArgsConstructor
@RequestMapping("/posts")
@RestController
public class PostController {

    private final PostService postService;

    @GetMapping
    public ResponseEntity<List<PostResponse>> readAll() {
        return ResponseEntity.ok(postService.readAll().stream()
                .map(PostResponse::from)
                .toList());
    }
}

해당 api의 스크립트를 작성해보겠습니다.

// GET
import http from "k6/http";
import { sleep } from "k6";

export const options = {
  vus: 100, // 가상 사용자 수
  duration: "10s", // 테스트 시간
};

export default function () {
  http.get("http://localhost:8080/posts");
  sleep(1);
}

function 부분은 http 요청을 보내는 부분이라 생략하겠습니다. options 부분은 테스트 시에 환경을 설정하는 부분입니다. 처음에는 간단하게 100명의 유저가 10초동안 접속했을 때를 측정했습니다. 요청이 끝나고 1초 동안 행동을 중지했는데요. 처음에는 왜 sleep(1)을 설정했는지 궁금했습니다. 공식 문서와 GPT께서 실제 서비스처럼 모방하기 위함이라고 하네요. "한 번 요청하고 나면 같은 요청을 1초 동안은 보내지 않을 것이다." 라고 가정한 것입니다.

실행 결과

k6 run {파일명}

명령어를 통해 테스트를 진행하면 아래와 같이 성능을 보여줍니다.

그리고 각각의 요소가 의미하는 것은 아래의 표와 같습니다. 참고

기본 메트릭 (프로토콜 상관 없이 수집)

HTTP 관련 메트릭 (HTTP 요청을 할 때만 생성)

http_req_duration != http_req_sending + http_req_waiting + http_req_receiving 인데, 그건 sleep(1) 때문입니다. 1초를 쉬었으니 1.05 sec가 된 것이고, sleep을 제외한 시간을 계산해보면 딱 맞는다는 것을 확인할 수 있습니다.

실제 테스트

윗 내용까지는 K6 사용법을 알아보기 위해 진행한 테스트이기 때문에 아주 간단한 테스트로 진행했습니다. 성능 테스트는 실제 환경처럼 세팅하고 진행하는 것이 중요하기 때문에 실제 환경으로 셋업하고 시나리오도 작성해서 진행해보도록 하겠습니다.

부하 테스트

목표

메인 화면의 게시글 목록을 보여줄 때 100ms 내에 응답하는 것을 목표로 잡겠습니다.

• 하루 최대 rps(request per second): 100rps

저희 서비스는 1시간에 1번 요청이 오는 때도 있기 때문에 평균 요청 횟수를 계산하지 않고 런칭 이벤트와 같은 피크 타임을 기준으로 잡겠습니다. 그렇다면 1초에 100건의 요청을 100ms 안에 보내면 됩니다!

스크립트 작성

최대 가상 사용자 수를 100rps * 0.1s 로 설정하겠습니다. (vus = 10)

import http from "k6/http";
import { check } from "k6";

export const options = {
  stages: [  
    { duration: '2m', target: 5 }, 
    { duration: '10m',target: 5 },
    { duration: '3m', target: 10 },
    { duration: '30m',target: 10 },
    { duration: '3m', target: 0 },
  ],

  thresholds: { 
    http_req_duration: ['p(95)<100'],
  }
};

export default function () {
  const response = http.get("http://localhost:8080/posts");
  check(response, {
    "success": (res) => res.status === 200
  });
}

코드를 해석하자면, 2분 동안 5명으로 유저를 증가시키고 10분 동안 5명의 유저를 유지시킵니다. 그리고 3분 동안 10명으로 유저를 늘립니다. 피크 시간은 30분 동안 진행되고 10명의 유저를 유지시킵니다. 그리고 3분간 0명의 유저로 줄입니다.

또, 95%가 100ms 안에 응답을 받는 것을 목표로 했습니다.

스트레스 테스트

목표

서버가 언제 터지는지 확인해보겠습니다. 그리고 어떤 이유로 터지는지 확인해보도록 하겠습니다.

스크립트

import http from "k6/http";
import { check } from "k6";

export const options = {
  stages: [
    { duration: "1m", target: 10 },
    { duration: "3m", target: 10 },
    { duration: "1m", target: 50 },
    { duration: "3m", target: 50 },
    { duration: "1m", target: 100 },
    { duration: "3m", target: 100 },
    { duration: "1m", target: 200 },
    { duration: "3m", target: 200 },
    { duration: "1m", target: 300 },
    { duration: "3m", target: 300 },
    { duration: "1m", target: 0 },
  ],

  thresholds: {
    http_req_duration: ["p(95)<100"],
  },
};

export default function () {
  const response = http.get("http://localhost:8080/posts");
  check(response, {
    "success": (res) => res.status === 200,
  });
}

테스트 서버 환경 설정

스크립트를 모두 작성했으니 이제 실제 환경에서 테스트를 진행해보겠습니다. t4g.small 서버를 사용한다고 가정하고 t4g.small에 실제 서비스 환경을 조성해주도록 하겠습니다.

grafana/k6는 arm64를 지원하지 않아 공식 설치 문서를 참고하여 우분투 내에 직접 설치했습니다. 그런데 공식 문서 또한 되지 않았습니다. k6가 arm64를 지원하지 않는 것 같습니다. 그래서 github를 찾아보았는데 다행히도 arm64 버전이 업데이트 되어있었습니다. github에서 다운받아 우분투로 scp 해주었습니다.

K6를 제외한 grafana와 influxdb를 docker-compose 로 컨테이너를 띄웠습니다.

version: '3.4'

services:
  influxdb:
    image: influxdb:1.8
    ports:
      - "8086:8086"
    environment:
      - INFLUXDB_HTTP_AUTH_ENABLED=false
      - INFLUXDB_DB=k6

  grafana:
    image: grafana/grafana:latest
    ports:
      - "3000:3000"
    environment:
      - GF_AUTH_ANONYMOUS_ORG_ROLE=Admin
      - GF_AUTH_ANONYMOUS_ENABLED=true
      - GF_AUTH_BASIC_ENABLED=false
    volumes:
      - ./grafana:/etc/grafana/provisioning/

influxdb에서 k6 라는 데이터베이스를 미리 만들었습니다. 또, 그라파나에서 로그인 된 상태로 접속할 수 있도록 설정했습니다.

컨테이너가 모두 잘 띄워져 있습니다! 원래는 독립적인 공간에서 성능 테스트를 해야합니다. 비용 이슈로 저는 한 서버에서 진행했습니다. 연습용이기도 하구요~ 스트레스 테스트에서 서버 터지면 성능 테스트 결과도 볼 수 없기 때문에 부하 테스트만 진행해보도록 하겠습니다.

influxdb 연결

aws public ip 주소를 통해 grafana에 접속합니다. 설정에 맞췄다면 {ip주소}:3000 입니다. 화면에서 datasource를 클릭하여 새로 influxdb를 만들어줍니다. 저는 이미 생성해서 아래와 같이 생성된 화면이 나왔습니다. 아래와 같이 포트와 DB 이름을 설정하고 save & test버튼을 클릭하면 정상적이라는 메시지가 뜹니다.

대시보드 생성

이제 GUI로 볼 수 있는 대시보드를 만들어보도록 하겠습니다. grafana 홈 화면에서 햄버거 버튼을 클릭하면 아래와 같은 화면이 나옵니다 Dashboards를 클릭합니다. 그리고 import를 해서 예쁜 디자인의 대시보드를 들고오도록 하겠습니다. https://grafana.com/grafana/dashboards/2587 를 입력하고 load 버튼을 클릭하면 아래와 같은 화면이 나타납니다. 이전에 생성한 k6 데이터 소스를 import 하면 모든 준비는 끝입니다.

테스트 진행

드디어 테스트를 gui로 보는 과정입니다. 다시 aws로 돌아와 성능 테스트를 실행합니다.

./k6 run --out influxdb=localhost:8086/k6 {스크립트 파일명} 

그리고 그라파나를 확인해볼까요~

성공적으로 떴습니다.

마무리

이제 스트레스 테스트의 지표로 어떤 부분을 개선해야할지 알아봐야 할 것 같습니다...

참고

• https://k6.io/blog/k6-vs-jmeter/
• https://k6.io/docs/get-started/running-k6/
• https://velog.io/@sontulip/performance-test

index 란?

인덱스는 빠른 정렬과 그룹핑을 위한 데이터베이스 기능입니다. 지정한 칼럼들을 기준으로 index를 설정하면 지정한 칼럼들이 정렬되어 index로 나타납니다.

장점

• binary search 방식으로 조회하기 때문에 O(logN)의 시간복잡도를 가져 full scan 하는 O(N)보다 성능이 좋습니다.
• index는 메모리 영역에 올라가 있으므로 캐싱을 한다면 디스크로 조회하는 것보다 빠릅니다.

단점

• insert, update, delete 시에는 index를 재설정 해주어야하기 때문에 성능적으로 더 느립니다.
• index를 설정하게 되면 데이터베이스 공간을 더 차지합니다.

언제 사용할까?

조회 시에는 성능적으로 유리하고 생성, 수정, 삭제 시에는 성능적으로 비효율적이기 때문에 조회 쿼리가 많이 쓰이는 table에 index를 설정하면 됩니다! 하지만 조회 또한 권장하는 방향이 있는데요. 1개의 칼럼만 인덱스를 걸어야 한다면 해당 컬럼은 카디널리티(Cardinality)가 가장 높은 것을 잡아야 유리합니다.

카디널리티는 전체 행에 대한 특정 컬럼의 중복 수치를 나타내는 지표이다. 중복도가 ‘낮으면’ 카디널리티가 ‘높다’고 표현한다. 중복도가 ‘높으면’ 카디널리티가 ‘낮다’고 표현한다.

Index 만들어보기

실험을 위해 아래와 같은 테이블로 index를 만들어보도록 하겠습니다. 빅데이터 사이트에서 도서 데이터를 50만 개 다운받아 실험 데이터베이스에 넣어주었습니다.

create table book
(
    SEQ_NO                    bigint         not null
        primary key,
    ISBN_THIRTEEN_NO          varchar(13)    not null,
    VLM_NM                    varchar(20)    null,
    TITLE_NM                  varchar(1000)  not null,
    AUTHR_NM                  varchar(1000)  null,
    PUBLISHER_NM              varchar(1000)   null,
    PBLICTE_DE                varchar(30)    null,
    ADTION_SMBL_NM            varchar(5)     null,
    PRC_VALUE                 decimal(9, 2)  null,
    IMAGE_URL                 varchar(1000)  null,
    BOOK_INTRCN_CN            varchar(1000)  null,
    KDC_NM                    decimal(14, 8) null,
    TITLE_SBST_NM             varchar(1000)  null,
    AUTHR_SBST_NM             varchar(1000)  null,
    TWO_PBLICTE_DE            varchar(10)    null,
    INTNT_BOOKST_BOOK_EXST_AT varchar(1)     null,
    PORTAL_SITE_BOOK_EXST_AT  varchar(1)     null,
    ISBN_NO                   varchar(41)    null
);

보통 isbm 13자리로 도서를 검색하는 경우가 많다고 생각해 ISBM_THIRTEEN_NO 칼럼을 index로 걸어보겠습니다.

create index book_idx on book(ISBN_THIRTEEN_NO);

index가 잘 걸렸는지 확인해보겠습니다.

show index from book;

사진을 보면 book_idx가 잘 들어가있는 것을 확인할 수 있습니다. 하지만 걸지 않은 PRIMARY라는 이름의 index도 보이는데요. 이는 테이블을 생성할 때 PK 기준으로 자동으로 index를 생성해주는 mysql의 특징 때문입니다.

성능 검증

index를 걸기 전과 후의 속도를 비교해보도록 하겠습니다.

index 적용 전

index 적용 후

31ms로 10배 이상의 성능 차이를 보였습니다. 실행시간만 본다면 60배 이상의 차이를 보였습니다.

주의 사항

단일 칼럼으로 index를 구성했기 때문에 다른 칼럼에 대해서는 정렬된 상태로 저장되어있지 않습니다. 따라서 where a = 1 and b = 2와 같은 다중 필터링의 경우에는 index를 적용할 때보다 성능이 떨어질 수도 있습니다. (보통 다중 필터링을 사용하는 경우는 칼럼 자체의 카디널리티가 떨어질 것이기 때문에 index를 사용하지 않을 것 같습니다.)

B-Tree

index는 B-tree 구조로 되어있는데요. 이 구조에서 이분 탐색까지 더해져 좋은 성능을 내는 것입니다. 완벽하게 B-tree의 구조를 이해하지는 못했습니다. 따라서 해당 내용에 대해 궁금하신 분들은 동욱님의 블로그를 참고해주시면 감사하겠습니다.

B-tree 구조에서 root와 branch는 자식 노드의 위치를 저장하고, leaf는 조회하려는 데이터 칼럼의 데이터베이스 포인터를 저장합니다. 그리고 포인터를 통해서 데이터베이스의 해당 주소로 바로 이동하는 방식입니다.

ISBN_THIRTEEN_NO가 1313131313131인 책을 찾는다고 가정했을 때 위와 같이 Root1 -> BRANCH2 -> LEAF4 를 거쳐 데이터베이스 주소로 다이렉트로 이동하는 방식입니다. (실제로는 브랜치가 더 깊게 퍼져있습니다.)

Composite Index

두 가지 이상의 칼럼으로 조합된 index를 composite index라고 합니다. 두 가지 칼럼의 조합으로 카디널리티가 높을 때 사용합니다. 지금 도서 데이터에서는 _책 제목 + 저자_를 기준으로 복합 index를 적용할 수 있겠습니다. 책 제목은 겹치는 경우가 종종 있고, 한 저자가 여러권의 서로 다른 책을 쓰는 경우도 많죠. 하지만 보통 작가들은 겹치는 책 제목을 짓지는 않을 것 같아서 _책 제목 + 저자_의 조합은 카디널리티가 높다고 생각했습니다.

어떻게 composite index를 만드는지 살펴보겠습니다.

create index title_author_idx on book(TITLE_NM, AUTHOR_NM);

이전과 크게 다르지 않습니다. 하지만 동작 방식에서 차이가 있습니다.

만약 TITLE_NM 칼럼만을 index로 설정했다면 title은 사전순대로 정렬되어 있지만 author는 사전순대로 정렬되어 있지 않습니다. 당연한 이야기인데요. index를 title에만 걸었으니 나머지 칼럼에 대해서는 정렬이 되어있지 않게 index가 생성됩니다. 결국 title만 이분 탐색을 하고, author에 대해서는 full scan을 하게 됩니다.

복합 index는 title로도 정렬하고, author에 대해서도 정렬하게 됩니다. 두 칼럼 모두를 검색할 때 이분 탐색을 합니다.

단점

하지만 단점 또한 존재합니다. 책 제목 + 저자 조합이 아닌 저자로만 검색하고 싶을 땐 full scan을 하게 됩니다.

_책 제목_으로 검색하는 경우에는 이 composite index를 사용하면 빠르게 검색할 수 있습니다. 1차 정렬을 책 제목으로 했고, 2차 정렬을 저자로 했기 때문입니다. 하지만 저자로 검색하는 경우 composite index가 처음에는 제목 기준으로 정렬되어 있기 때문에 full scan을 하는 것보다 더 오래 걸릴 수도 있습니다.

select * from book where title_nm = '클린코드';
select * from book where title_nm = '클린코드' and author_nm = '로버트C.마틴';

위 두 가지 경우에는 빠르게 검색 가능하지만

select * from book where author_nm = '로버트C.마틴';

위와 같은 경우는 검색 속도가 떨어집니다.

이를 해결하기 위해서는 저자에 대한 index를 만들어주어야 합니다. index를 더 만들면 좋지만 그만큼 용량 차지도 하기 때문에 정말 자주 사용하는 쿼리인지 판단하고 신중하게 index를 설정하는 것이 좋습니다.

Explain

index가 많아질수록 쿼리가 어떤 index를 사용하고 있는지 헷갈릴 수 있는데요. 이때 explain 키워드를 통해 어떤 index를 사용하고 있는지 알 수 있습니다.

create index isbn_no_idx on book(ISBN_NO);
create index isbn_thirteen_no_idx on book(ISBN_THIRTEEN_NO);
create index isbn_no_isbn_thirteen_no_idx on book(ISBN_NO, ISBN_THIRTEEN_NO);

이렇게 3개의 index를 생성했다고 가정하겠습니다.

explain select SQL_NO_CACHE * from book where ISBN_NO = '9780358354352';

위의 explain 문을 실행시키면 사진과 같이 isbn_no_idx를 사용하고 있다고 알려주고 있습니다. 그리고 가능한 index 목록도 보여주는데요. 저는 isbn_no 칼럼 만을 index로 만들기도 했고 isbn_no + isbn_thirteen_no 조합으로도 index를 만들었습니다. 두 index를 사용할 수 있고 mysql은 isbn_no_idx를 사용한 모습입니다.

만약 isbn_thirteen_no를 검색할 땐 어떻게 될까요?

explain select SQL_NO_CACHE * from book where ISBN_THIRTEEN_NO = '9780358354352';

사진과 같이 isbn_thirteen_no 만을 이용한 index를 사용하고 가능한 index 목록에도 해당 index밖에 표시되지 않습니다. composite index도 있는데 해당 index를 possible keys에 포함시키지 않은 이유는 mysql에서는 첫 순서의 칼럼이 포함되어 있지 않은 select 문에 대해서는 possible keys로 두지 않기 때문입니다.

그리고 mysql은 optimizer가 알아서 적절하게 index를 선택할 수 있게 하기 때문에 index를 선택하지 않아도 index 방식으로 조회를 하는 것입니다.

Index hint

그렇다면 개발자가 원하는 index를 사용하게 하려면 어떻게 해야할까요?

use

select 시에 use 키워드를 사용하면 해당 index로 조회가 가능합니다!

explain select SQL_NO_CACHE * from book use index(isbn_no_isbn_thirteen_no_idx) where ISBN_NO = '9780358354352';

이전에 같은 쿼리에서 optimizer는 isbn_no_idx를 사용했는데요. 이렇게 use를 이용해서 isbn_no_isbn_thirteen_no_idx로 지정해주게 되면 해당 index를 사용합니다.

force

explain select SQL_NO_CACHE * from book force index(isbn_no_isbn_thirteen_no_idx) where ISBN_NO = '9780358354352';

force도 use와 같이 원하는 index를 사용하게끔 합니다. 하지만 이름에서 유추할 수 있듯이 더 강한 권장처럼 보이죠. 어떤 것에 use를 써야하고 어떤 것에 force를 써야하는지 추상적이어서 저는 헷갈렸었는데요. 아래와 같은 특징을 가집니다.

• use
  • optimizer에게 지정한 index를 사용하라고 권장합니다.
  • 만약 full scan이 더 빠르다면 optimizer는 index 대신 full scan으로 수행할 수 있습니다.
• force
  • full scan이 더 효율적이어도 무조건 index를 사용합니다.
  • index를 사용할 수 없는 쿼리 (index가 걸려있지 않은 컬럼이 조건에 있는 경우)인 경우에만 다른 방법을 선택할 수 있습니다.

ignore

explain select SQL_NO_CACHE * from book ignore index(isbn_no_isbn_thirteen_no_idx) where ISBN_NO = '9780358354352';

ignore index는 이름에서 유추할 수 있듯이 지정한 index를 무시하는 문법입니다. 위의 예시처럼 isbn_no_isbn_thirteen_no_idx를 무시하면 이 index를 제외하고 다른 index로 실행하게 됩니다.

기존의 isbn_no_index를 사용하고 있네요!

Covering index

굳이 database까지 가지 않고 index만으로 커버할 수 있는 것을 말합니다. 예를 들어 아래와 같은 쿼리가 있다고 가정하겠습니다.

select book.ISBN_NO, book.ISBN_THIRTEEN_NO from book where ISBN_NO ='8988557212';

이전에 걸어둔 isbn_no_isbn_thirteen_no_idx 인덱스가 존재한다면 해당 인덱스에서 모든 정보를 추출할 수 있기 때문에 데이터베이스까지 통신하지 않고 메모리 영역에서만 탐색하고 결과를 반환합니다. 데이터베이스와 직접 통신하지 않기 때문에 속도가 개선이 되겠죠!

마무리

간단한 index 관련해서 글을 남겨보았는데요. 이외에 hash index, b+ tree 등 여러 개념을 봤는데, 아직 공부할 필요성을 느끼지 못해 자세히 보지 않았습니다. 나중에 필요할 때 사용해볼 예정입니다.

참고

• 쉬운 코딩님 강의
• 동욱님 블로그
• https://code-lab1.tistory.com/217

그 첫 주제로 데이터베이스의 격리 수준에 대해 정리해보고자 합니다.

트랜잭션

논리적 작업 단위를 말합니다.

더 이상 나눌 수 없는 작업 단위인데요. 계좌 이체를 예로 들겠습니다.

계좌 이체를 처리하려면

1. 사용자 A의 잔액을 20만원 줄이는 데 성공한다.

2. 사용자 B의 잔액을 20만원 더하는 데 성공한다.

두 가지 모두 성공해야합니다.

쿼리는 2개를 실행하더라도 논리적 작업 단위는 하나이기 때문에 이것을 트랜잭션이라고 합니다.

트랜잭션의 특징

데이터베이스에서 트랜잭션의 특징이 있는데요. ACID 라고 합니다.

총 4가지로 Atomicity(원자성), Consistency(일관성), Isolation(독립성), Durability(지속성) 이 있습니다.

하나하나 살펴보도록 하겠습니다.

Atomicity(원자성)

트랜잭션이 데이터베이스에 모두 다 반영되거나, 모두 다 반영되지 않아야 한다는 특징입니다.

여러 개의 쿼리 중에 일부만 성공했다고 해서 일부만 정상 처리하게 된다면 데이터 정합성이 깨지기 때문에 무조건 모두 다 성공해야 commit을 하고, 그렇지 않으면 rollback을 실행한다는 원칙입니다.

Consistency(일관성)

트랜잭션의 작업 처리 결과가 항상 일관성이 있어야 한다는 특징입니다.

예를 들어 트랜잭션이 완료되면 계좌 잔액의 자료형이 Long에서 String으로 변하지 않는다는 것을 보장한다는 뜻입니다.
저는 너무 당연한 말이라고 생각해 100% 완벽하게 이해한 것이 맞는지 잘 모르겠습니다...

Isolation(독립성)

트랜잭션은 다른 트랜잭션이 존재하지 않는 것처럼 서로 간섭 없이 수행되어야 한다는 것을 의미합니다.
즉, 하나의 트랜잭션이 커밋되기 전까지 다른 트랜잭션은 특정 트랜잭션의 결과를 참조할 수 없습니다.

Durability(지속성)

트랜잭션 커밋 후에는 시스템이 중단되거나 장애가 발생해도 데이터가 그대로 유지되어야 한다는 특징입니다.
작업 도중에 에러가 발생하더도 커밋된 데이터는 유지된 상태로 데이터가 변하지 않아야 한다는 뜻입니다.

Commit, Rollback

Commit

트랜잭션이 성공적으로 마무리되어, 하나의 트랜잭션이 끝났다는 것을 알려주기 위해 사용하는 연산입니다.
저는 자바의 try-catch 구문에서 try 부분이 성공했다는 표현으로 생각했습니다!

Rollback

트랜잭션이 실패했고, 이전 상태로 롤백한다는 것을 알려주기 위해 사용하는 연산입니다.
저는 자바의 try-catch 구문에서 catch 부분에 도달했을 때 이전 연산을 원래 상태로 돌리는 표현으로 생각했습니다.

InnoDB 스토리지 엔진

Mysql 스토리지에 memory, MyISAM 등이 있는데 이 중에서 가장 많이 사용되는 스토리지 엔진입니다.

다른 엔진들과 달리 InnoDB는 트랜잭션을 지원한다고 합니다.

원자성으로 예를 들어보겠습니다.

CREATE TABLE inno_db_test (
  id BIGINT PRIMARY KEY AUTO_INCREMENT,
  name VARCHAR(20)
) ENGINE=InnoDB;

INSERT INTO inno_db_test VALUES (2, 'ditoo');
INSERT INTO inno_db_test VALUES (1, 'hongsil'), (2, 'ditoo'), (3, 'ethan');
SELECT * FROM inno_db_test; -- inno_db 결과?

CREATE TABLE myisam_test (
  id BIGINT PRIMARY KEY AUTO_INCREMENT,
  name VARCHAR(20)
) ENGINE=MyISAM;

INSERT INTO myisam_test VALUES (2, 'ditoo');
INSERT INTO myisam_test VALUES (1, 'hongsil'), (2, 'ditoo'), (3, 'ethan');
SELECT * FROM myisam_test; -- myisam 결과?

위의 코드에서 inno_db의 결과는 아래와 같습니다.

그리고 myisam의 결과는 아래와 같습니다.

차이는 transaction의 지원 여부에 있습니다.

inno_db의 경우 트랜잭션을 지원하기 때문에 insert 문을 실행할 때 자동으로 트랜잭션 처리가 되어 여러 value 중 하나라도 잘못되면 전체 롤백에 됩니다. 그래서 조회 결과에 id = 2 인 데이터밖에 조회되지 않은 것입니다.

반면에 myisam의 경우 트랜잭션을 지원하지 않기 때문에 insert 문에 여러 value를 넣었을 때 성공하는 insert까지 데이터베이스에 반영됩니다. 즉, 2번째 insert에서 id = 1 까지 성공하고 id = 2 인 것부터 pk가 겹치기 때문에 실패했기 때문에 id = 1 인 것까지 데이터베이스에 반영이 된 것입니다.

mysql 5.5.5부터 inno db를 디폴트 스토리지 엔진으로 사용하고 있다고 합니다. (왜 그전까지는 myisam을 썼는지 이해되지 않음...)

트랜잭션의 격리 수준

트랜잭션에 대해 짧게 살펴보았으니, 조금 더 심화적인 부분인 트랜잭션 격리 수준에 대해 알아보고자 합니다.

Real MySQL 8.0에 따르면

트랜잭션의 격리 수준이란 여러 트랜잭션이 동시에 처리될 때 특정 트랜잭션이 다른 트랜잭션에서 변경하거나 조회하는 데이터를 볼 수 있게 허용할지 말지를 결정하는 것이다.

라고 합니다.

즉, 서로 다른 두 개 이상의 트랜잭션이 동시에 같은 데이터를 처리할 때 어떤 방식으로 처리해야 하는지에 대해 다룬 것입니다.

위 표와 같이 격리 수준을 나타내곤 하는데요. 하나하나 살펴보도록 하겠습니다.

읽기 부정합

트랜잭션의 격리 수준에 따라 발생할 수 있는 문제점들입니다.
이 문제점들을 기준으로 격리 수준을 나눌 수 있습니다.

Dirty Read

위 그림에서 Transaction 2가 Y를 80으로 바꾸었습니다. 하지만 커밋되지 않고 롤백이 되었죠.
Transaction 1은 Transaction 2가 롤백하기 전의 Y를 읽었습니다. 따라서 X는 100으로 변했고 커밋되었습니다.
여기서 모순이 발생합니다.

X에 Y를 더하면 20 + 30이 계산되어 50이 되어야 하는데, Transaction 1이 롤백하기 전의 Y를 읽어 X가 100으로 변한 것을 확인할 수 있습니다.
이런 현상을 Dirty Read 라고 합니다.

Non-Repeatable Read

X를 두 번 읽는 Transaction 1의 작업에서 두 번 읽은 X의 값이 서로 달랐습니다.
Transaction 2가 중간에 X의 값을 변경했기 때문인데요.
이렇게 같은 Transaction에서 같은 데이터를 읽는데 값이 서로 다르게 읽히는 현상을 Non-Repeatable Read 라고 합니다.

Phantom Read

Non-Repeatable Read의 일종입니다. 한 필터로 조회한 데이터들의 묶음이 달라지는 현상을 말합니다.

위의 그림에서 Transaction 2가 t2의 v를 10으로 변경하여 Transaction 1의 두 번의 조회값이 서로 달라졌습니다.
앞서 살펴본 Non-Repeatable Read와 매우 유사합니다.

격리 수준 (Isolation Level)

격리 수준은 총 4단계로 read uncommitted -> read committed -> repeatable read -> serializable 순으로 격리 수준이 높습니다.

MySQL innoDB의 디폴트 격리 수준은 3단계인 repeatable read 라고 합니다.

그럼 하나하나 살펴보도록 하겠습니다. 

Read Uncommitted

가장 낮은 단계의 격리 수준입니다. read uncommitted에서는 dirty read, non-repeatable read, phantom read 모두 허용합니다.

-- 이하 1번 커넥션

START TRANSACTION;  # 2
INSERT INTO inno_db_test VALUES (1, 'test');  # 5
ROLLBACK ;  # 7

-- 이하 2번 커넥션

SET TRANSACTION ISOLATION LEVEL READ UNCOMMITTED;  # 1

START TRANSACTION;  # 3
SELECT * FROM inno_db_test;  # 4
SELECT * FROM inno_db_test;  # 6
ROLLBACK;  # 8

위의 주석 순서로 실행하게 되면 2번 커넥션의 첫 select에서는 아래와 같이 나옵니다.

그리고 두 번째 select에서는 아래와 같이 데이터가 생긴 것을 확인할 수 있습니다.

이로 격리 수준이 read uncommitted 인 경우 커밋되지 않은 데이터까지 읽는다는 것을 확인할 수 있습니다.

Read Committed

두 번째 단계의 격리 수준입니다. read uncommitted와 달리 커밋된 데이터만 읽을 수 있습니다.

하지만 non-repeatable read를 허용하기 때문에 한 트랜잭션에서 같은 데이터를 두 번 읽을 때 서로 다른 값이 나올 수 있습니다.

우선 커밋된 데이터를 읽는지 확인해 보겠습니다.

-- 이하 1번 커넥션

START TRANSACTION;  # 3
INSERT INTO inno_db_test VALUES (1, 'test');  # 4
COMMIT;  # 6

-- 이하 2번 커넥션

SET TRANSACTION ISOLATION LEVEL READ COMMITTED;  # 1

START TRANSACTION;  # 2
SELECT * FROM inno_db_test;  # 5
SELECT * FROM inno_db_test;  # 7
ROLLBACK;  # 8

해당 주석 순서로 실행했을 때, 2번 커넥션의 첫 select에서는 아무 데이터도 읽지 않는다는 것을 확인할 수 있습니다.

1번 커넥션을 커밋하고 나면 7번 주석의 select를 실행할 때 데이터가 삽입되어 있는 것을 확인할 수 있습니다.

그렇다면 non-repeatable read는 올바르게 동작할까요?

-- 이하 1번 커넥션

START TRANSACTION;  # 3
UPDATE inno_db_test SET name = 'updated' WHERE id = 1;  # 4
COMMIT;  # 6

-- 이하 2번 커넥션

SET TRANSACTION ISOLATION LEVEL READ COMMITTED;  # 1

START TRANSACTION; # 2
SELECT * FROM inno_db_test; # 5
SELECT * FROM inno_db_test; # 7
ROLLBACK; # 8

해당 주석을 실행하기 전 데이터베이스 상태는 아래와 같습니다.

위 주석 순서로 실행했을 때, 5번 주석을 실행하면 아래와 같이 나옵니다. 데이터가 바뀌지 않았죠.

1번 커넥션을 커밋하고 7번 주석을 실행하면 아래와 같이 데이터가 업데이트 되었다는 것을 확인할 수 있었습니다. 

이 결과로 non-repeatable read 현상이 발생한 것을 확인할 수 있었습니다.

Repeatable Read

위의 read committed 수준에서 한 단계 더 강화된 격리 수준입니다.

방금 살펴본 non-repeatable read가 발생하지 않도록 격리시킵니다.

그럼 non-repeatable read가 정말 발생하지 않는지 앞선 실험과 같은 데이터로 실험해 보도록 하겠습니다.

-- 이하 1번 커넥션

START TRANSACTION;  # 3
UPDATE inno_db_test SET name = 'updated' WHERE id = 1;  # 4
COMMIT;  # 6

-- 이하 2번 커넥션

SET TRANSACTION ISOLATION LEVEL REPEATABLE READ;  # 1

START TRANSACTION; # 2
SELECT * FROM inno_db_test; # 5
SELECT * FROM inno_db_test; # 7
ROLLBACK; # 8

이전과 같이 실행 전 데이터베이스 상태는 아래와 같습니다.

그리고 주석 순서대로 진행하여 두 번의 select를 실행했을 때 결과는 모두 아래와 같았습니다.

데이터는 변하지 않았고, 이로 인해 non-repeatable read 가 발생하지 않는다는 것을 검증했습니다.

repeatable read 격리 수준에서 phantom read가 발생하는지 확인해 보도록 하겠습니다.

-- 이하 1번 커넥션

START TRANSACTION;  # 2
UPDATE inno_db_test SET name = 'updated' WHERE id = 1;  # 3
COMMIT;  # 6

-- 이하 2번 커넥션

SET TRANSACTION ISOLATION LEVEL REPEATABLE READ;  # 1

START TRANSACTION;  # 4
SELECT * FROM inno_db_test where name = 'test';  # 5
SELECT * FROM inno_db_test where name = 'test';  # 7
ROLLBACK;  # 8

해당 주석을 실행하기 전 데이터베이스 상태는 아래와 같습니다.

그리고 주석 순서대로 실행시켰을 때 결과는 놀랍게도 두 select의 결과가 같았습니다.

아래와 같이 말이죠.

phantom read가 작동하지 않은 것인데요. 이론 상이라면 repeatable read 수준에서 phantom read가 발생해야 하는데, 왜 그럴까요?

저는 실험에 MySQL 8.0.34 버전을 사용했는데요. MySQL 8.0 부터 Repeatable Read 수준에서도 Phantom Read가 발생하지 않는다고 합니다.

그 이유는 InnoDB 스토리지 엔진의 MVCC (Multi-Version Concurrency Control) 메커니즘 때문입니다.

MVCC에서 각 트랜잭션은 자신의 볼 수 있는 데이터 버전을 가지는데, 트랜잭션이 데이터를 수정하면 해당 데이터의 새 버전이 생성됩니다. 기존 버전은 유지되며 다른 트랜잭션은 이전 버전의 데이터를 볼 수 있습니다.

즉, 트랜잭션이 데이터를 읽을 때 해당 트랜잭션이 시작된 시점에서의 데이터 버전을 사용하여 읽습니다. 위의 실험에서 2번 커넥션이 시작했을 때 1번 커넥션이 커밋되기 전 버전의 데이터만 읽기 때문에 phantom read 가 발생하지 않았던 것입니다. 다른 트랜잭션이나 작업에 의한 데이터 변경으로 인한 영향을 받지 않기 때문에 Serializable 수준을 사용하지 않고도 phantom read 문제를 해결할 수 있었습니다.

Serializable

격리 수준 최종 단계인 serializable 입니다. 이는 설명하길 데이터가 중간에 바뀔 일이 절대 없다고 합니다.

그렇다면 어떻게 phamtom read까지 보장할 수 있는지 살펴보도록 하겠습니다.

-- 이하 1번 커넥션

START TRANSACTION;  # 3
UPDATE inno_db_test SET name = 'updated' WHERE id = 1;  # 5
COMMIT;  # 6

-- 이하 2번 커넥션

SET TRANSACTION ISOLATION LEVEL SERIALIZABLE;  # 1

START TRANSACTION;  # 2
SELECT * FROM inno_db_test where name = 'test';  # 4
SELECT * FROM inno_db_test where name = 'test';  # 7
ROLLBACK;  # 8

위의 실험에서 주석 순서대로 SQL 문을 실행시키면 5번 주석 부분부터 lock이 걸립니다.
2번 커넥션 트랜잭션을 다 끝내기 전까지 대기 상태에 걸리고, 2번 커넥션이 완료되어야 lock이 풀리고 SQL 문이 실행됩니다.

repeatable read 와 달리 접근을 막아 다른 트랜잭션을 대기 상태로 만듭니다.

이는 자원이 겹치는 경우 성능적으로 문제가 많을 것입니다. MySQL 8.0 부터는 MVCC를 활성화하여 repeatable read 수준에서도 phantom read 문제를 해결할 수 있기 때문에 굳이 성능도 좋지 않은 serializable 수준의 격리를 사용하지 않을 것 같습니다.

참고

• https://www.youtube.com/watch?v=bLLarZTrebU&t=45s
• 우아한테크코스 강의

self-hosted runners

CD를 구축하기 위해서 github actions에서 제공하는 self-hosted runners를 사용했습니다. 현재 진행하고 있는 프로젝트의 EC2는 우아한테크코스 ip로만 접속 가능하기 때문에 github actions에서 제공하는 가상 머신이 scp를 통해 빌드 파일을 전송하는 것이 불가능했습니다. 팀 동료가 self-hosted runners는 EC2 내부에서 외부로 접근하는 방식이어서 CD가 가능하다고 말해주어서 해당 방법으로 CD를 구축하게 되었습니다.

공식 문서에 따르면 작업을 실행하기 위해 배포하고 관리하는 시스템이라고 합니다.

github-hosted runners는 깃허브의 가상 머신을 사용하여 빌드했다면 self-hosted runners는 사용자의 서버에서 직접 빌드하는 방식입니다.

docker hub 이용

self-hosted runners는 프로젝트의 서버 자원을 사용하기 때문에 잡일은 최대한 github-hosted runners에게 시키고 싶었습니다. self-hosted runners에서는 오직 빌드된 jar 파일만 실행시키는 것을 원했는데요. 외부에서 ec2에 scp가 불가능하기에 도커를 이용했습니다.

github-hosted runners에서 jar 파일을 빌드하고 docker hub에 private image를 push하도록 구성했습니다. ec2에서는 업데이트된 image를 docker hub로부터 pull 받고 해당 image를 이용하는 container를 실행시킵니다.

상세한 순서는 아래와 같습니다.

github-hosted runners

1. 레포지토리에서 체크아웃을 한다.
2. jdk 17로 세팅한다.
3. application-dev.yml 파일로 환경 설정한다.
4. gradle로 빌드한다.
5. docker 빌드 환경을 세팅한다.
6. docker hub에 로그인한다.
7. docker image를 빌드한다.
8. docker hub에 push한다.

self-hosted runners

1. docker image를 pull 받는다.
2. docker container를 실행시킨다.

조금 더 세세하게...

단계 하나하나 알아보도록 하겠습니다. ( 이전 포스트에 올린 github-hosted runners의 1~4 단계는 생략하겠습니다.)

도커 빌드 환경 세팅

      - name: Setup Docker buildx
        uses: docker/setup-buildx-action@v2.9.1

도커 action을 실행하기 위한 세팅입니다.

도커 로그인

      - name: Login to Docker Hub
        uses: docker/login-action@v2.2.0
        with:
          username: ${{ secrets.DOCKERHUB_DEPLOY_USERNAME }}
          password: ${{ secrets.DOCKERHUB_DEPLOY_TOKEN }}

docker 계정의 이메일과 토큰을 github에 secrets로 등록합니다. 그래야 github-hosted runners가 등록한 이메일과 토큰으로 로그인할 수 있습니다. (토큰 대신 password를 입력해도 괜찮습니다. 하지만 토큰을 권유한다는 메시지가 뜨더라구요!)

docker에서 토큰을 발급받는 절차입니다. 우선 docker hub에 접속하여 settings -> security로 이동합니다. New Access Token 버튼을 클릭하여 새로운 토큰을 발급받습니다. 토큰을 복사하여 secrets에 저장합니다.

도커 image 빌드

      - name: Docker Image Build
        run: |
          docker build --platform linux/x64/v8 -t shb03323/cicd -f Dockerfile .

docker 레포지토리에 image를 빌드하는 명령어입니다. 이미지를 만들기 위해서는 docker hub의 레포지토리가 필요한데요. 한번 만들어보겠습니다. 먼저 docker hub의 repositorys 메뉴에 들어갑니다. 그 후에 private repository를 생성합니다. 무료 계정이면 하나의 private repository를 만들 수 있습니다.

위의 스크립트에 -f Dockerfile . 명령어가 있는데요. 이는 프로젝트 내부의 Dockerfile이라는 것을 이용하여 빌드한다는 뜻입니다. 이 Dockerfile을 이용해서 jar 파일을 만들어보겠습니다. 프로젝트 레포지토리 최상단에 Dockerfile을 만들어 아래와 같은 내용으로 구성했습니다.

FROM arm64v8/amazoncorretto:17

WORKDIR /app

COPY ./build/libs/cicd-0.0.1-SNAPSHOT.jar /app/cicd.jar

CMD ["java", "-jar", "-Dspring.profiles.active=dev", "cicd.jar"]

jdk 17로 설정하고, docker 레포지토리에 cicd.jar를 복사합니다. 그 후에 jar 파일로 빌드합니다.

도커 image push

      - name: Docker Hub Push
        run: docker push shb03323/cicd

도커 image push 명령어를 실행합니다.

self-hosted runners 설정하기

EC2에 self-hosted runners를 등록해야 image를 pull 받을 수 있습니다. 한번 등록해보도록 하겠습니다. 레포지토리의 settings -> Actions -> Runners 탭을 클릭하면 위와 같은 화면이 나옵니다. New self-hosted runner 버튼을 클릭하면 명령어들이 나오는데, 그대로 EC2 서버에 입력하시면 됩니다! 완료하면 예쁜 CLI창이 나옵니다. Runners를 다시 확인했을때 self-hosted runner가 생성된 것을 볼 수 있습니다.

self-hosted runners job

github-hosted runners와 다른 환경에서 실행되기 때문에 작업 또한 달라야합니다. 따라서 cd라는 이름을 가진 job를 생성했습니다.

  cd:
    needs: ci
    runs-on: [ self-hosted, Linux, x64 ]

ci job를 실행한 후에 cd 작업이 수행될 수 있도록 needs 속성을 넣어주었습니다. 또한, 환경도 다르게 설정해주었는데요. 이는 EC2 t2.micro의 환경입니다.

self-hosted runners에서 image pull 받기

      - name: Pull Latest Docker Image
        run: |
          sudo docker login --username ${{ secrets.DOCKERHUB_DEPLOY_USERNAME }} --password ${{ secrets.DOCKERHUB_DEPLOY_TOKEN }}
          if sudo docker inspect cicd-container &>/dev/null; then
            sudo docker stop cicd-container
            sudo docker rm -f cicd-container
            sudo docker image prune -af
          fi
          sudo docker pull shb03323/cicd:latest

이전에 docker hub에 push한 image를 받기 위해서는 로그인이 필요합니다. docker hub에 로그인 유지 시간이 있을 것이 분명하기 때문에 일단 계속 로그인 시도하도록 설정했습니다. 그리고 실행중인 container를 삭제하고 새로운 이미지로 pull 받았습니다.

container 실행

      - name: Run Container
        run: |
          sudo docker run --name cicd-container -p 8080:8080 shb03323/cicd:latest 1>> build.log 2>> error.log &

최신 상태로 pull 받은 image를 이용하여 container를 실행하는 명령어입니다. 이로써 모든 단계가 완료되었습니다.

최종 스크립트

name: continuous-deploy

on:
  push:
    branches:
      - main

jobs:
  ci:
    runs-on: ubuntu-22.04

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

      - name: Make application-dev.yml
        if: ${{ github.event.push.head.ref == 'main' }}
        env:
          PROPERTIES_DEV: ${{ secrets.PROPERTIES_DEV }}
        run: |
          cd ./src/main/resources
          touch ./application-dev.yml
          echo "${PROPERTIES_DEV}" > ./application-dev.yml
        shell: bash

      - name: Build with Gradle
        uses: gradle/gradle-build-action@v2.6.0
        with:
          arguments: build

      - name: Setup Docker buildx
        uses: docker/setup-buildx-action@v2.9.1

      - name: Login to Docker Hub
        uses: docker/login-action@v2.2.0
        with:
          username: ${{ secrets.DOCKERHUB_DEPLOY_USERNAME }}
          password: ${{ secrets.DOCKERHUB_DEPLOY_TOKEN }}

      - name: Docker Image Build
        run: |
          docker build --platform linux/x64/v8 -t shb03323/cicd -f Dockerfile .

      - name: Docker Hub Push
        run: docker push shb03323/cicd

  cd:
    needs: ci
    runs-on: [ self-hosted, Linux, X64 ]

    steps:
      - name: Pull Latest Docker Image
        run: |
          sudo docker login --username ${{ secrets.DOCKERHUB_DEPLOY_USERNAME }} --password ${{ secrets.DOCKERHUB_DEPLOY_TOKEN }}
          if sudo docker inspect cicd-container &>/dev/null; then
            sudo docker stop cicd-container
            sudo docker rm -f cicd-container
            sudo docker image prune -af
          fi
          sudo docker pull shb03323/cicd:latest

      - name: Run Container
        run: |
          sudo docker run --name cicd-container -p 8080:8080 shb03323/cicd:latest 1>> build.log 2>> error.log &

확인해보기

한 번 확인해볼까요? main에 push를 하니 github actions가 동작했습니다. CI/CD 둘 다 성공한 것을 볼 수 있습니다. EC2에서 docker가 실행된 것을 볼 수 있습니다. 비록 에러나서 꺼졌지만, cicd는 성공적으로 완수했습니다.

마무리

아직 actions로 밖에 CI/CD를 구축해보지 않았지만 과금이 되면 젠킨스로 넘어가지 않을까 합니다. github actions는 한 달 2000분까지만 무료라고 하더군요...

여럿이 같이하는 프로젝트에서 코드를 통합할때 특정 부분에서 오류가 발생할 수 있습니다. 실수로 동료의 코드를 지웠다던지, 충돌 해결을 잘못했다던지, 나의 코드 변경으로 동료의 코드가 동작하지 않게 된다던지 등등... 많은 상황을 겪어보았는데요. 이때 CI(지속적 통합)를 통해 공통 브랜치로 코드가 push 될 때 마다 코드가 정상적으로 빌드되는지 확인할 수 있습니다.

github actions 선택 이유

선택지로 github actions 와 jenkins 두가지가 있었는데요. 자체 서버 자원을 사용해야하고 상대적으로 무거운 jenkins보다는, build용 가상 머신을 제공해주고 가벼운 github actions를 선택했습니다. 지원하는 기능은 jenkins가 더 많지만, 그 기능들에 대해 잘 모르기도 하고 지금 프로젝트 규모에서는 github actions만으로 충분하다고 생각했습니다.

github-hosted runners

앞에서 github actions는 빌드를 위한 가상 머신을 제공해준다고 했는데요. 이때 그 가상 머신 실행기가 github-hosted runners 입니다. github-hosted runners는 아래와 같은 순서로 작업을 처리합니다.

1. 레포지토리를 로컬로 복제한다.
2. 테스트 소프트웨어를 설치한다.
3. 코드를 검사하는 명령을 실행한다.

github-hosted runners를 사용하기 위해서는 작업(job)을 만들고 runs-on 기능을 사용하여 작업을 처리할 가상 머신의 유형(ubuntu, windows, macOS)을 지정해야 합니다.

작업이 시작되면 깃허브는 해당 작업을 위한 가상 머신을 자동으로 프로비저닝하고 작업을 실행합니다. 작업이 완료되면 가상 머신이 자동으로 꺼집니다. 즉, push나 pull-request와 같은 이벤트에 따라 깃허브가 알아서 자원을 할당하고 해제합니다.

workflow

깃허브에서 발생하는 이벤트를 감지하고 이벤트에 따라 작업을 실행해주는 프로세스를 workflow라고 합니다. 레포지토리의 .github/workflows 디렉토리 안에 yaml 파일로 생성할 수 있습니다.

workflow 안에서 여러 github-hosted runners가 실행됩니다.

현재 진행중인 프로젝트에서의 빌드 과정을 그려보았는데요. 하나의 workflow에서 백엔드 관련 runner와 프론트엔드 관련 runner를 각각 작업하도록 둔 것을 볼 수 있습니다. 하나의 작업 안에 여러 step이 있는 것을 볼 수 있는데요. step은 순서대로 작업됩니다. 빌드를 위한 환경 설정을 초기 step에서 진행하고 마지막 step에서 빌드하는 흐름입니다.

조금 더 세세하게...

name: continuous-integration

on:
  pull_request:
    branches:
      - main

jobs:
  build-spring:
    runs-on: ubuntu-22.04

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

    - name: Make application-dev.yml
      if: ${{ github.event.pull_request.head.ref == 'dev' }}
      run: |
        cd ./src/main/resources
        touch ./application-dev.yml
        echo "${{ secrets.PROPERTIES_DEV }} > ./application-dev.yml
      shell: bash

    - name: Build with Gradle
      uses: gradle/gradle-build-action@v2.6.0
      with:
        arguments: build

임의로 스크립트를 만들어 보았는데요. 위 스크립트를 예시로 하나씩 세세하게 살펴보도록 하겠습니다.

이벤트

workflow는 이벤트를 감지하여 실행된다고 했는데요. 그 이벤트를 정의해주는 곳이 on 입니다.

on:
  pull_request:
    branches:
      - main

스크립트를 해석하자면, main 브랜치로 pull-request 시에 이벤트를 발생시키겠다는 의미입니다.

jobs

workflow에서 job이란 독립된 환경에서 실행하는 하나의 처리 단위를 의미합니다. 즉, workflow 부분의 그림에서 백엔드 빌드 작업과 프론트엔드 빌드 작업은 독립적으로 실행됩니다!

여기서 필수적으로 정의해야 할 속성은 runs-on과 steps입니다. runs-on은 빌드할 환경을 뜻하고, steps는 작업 목록 순서를 뜻합니다. build-spring은 그저 작업의 이름을 정의한 것입니다.

위의 스크립트를 보면 ubuntu-22.04 환경에서 빌드하도록 되어있고, 레포지토리 checkout -> JDK 17 세팅 -> application 환경 변수 설정 -> Gradle로 빌드 순으로 작업을 처리하도록 되어있습니다.

steps

각각의 step을 의미하고 job과 마찬가지로 이름을 설정할 수 있습니다. name 속성으로 step의 이름을 명시하면 됩니다! run 속성을 통해 스크립트 혹은 커멘드를 실행할 수 있습니다. uses 속성을 통해서는 action을 사용할 수 있습니다. if 속성으로 step에 대한 조건도 걸 수 있습니다!

실행해보기

PR을 만들면 자동으로 CI를 진행하는 것을 볼 수 있습니다.

검사가 끝나면 정상 코드라는 표시가 뜨게 됩니다. actions 탭에 들어가면 아래와 같이 실행 순서가 step 순서와 같다는 것을 확인할 수 있습니다. 자원 정리는 역순으로 해주네요!

하지만 특이점이 보이죠? application-dev.yml에는 체크 표시가 뜨지 않습니다. if 조건문의 조건이 만족하지 않으면 실행하지 않습니다. 스크립트대로라면 조건을 만족하기 때문에 읽혀야 정상입니다! 저는 일단 성공시키기 위해 위의 스크립트에서 조건만 슬쩍 바꿔 실행 안되도록 해보았습니다. 위 application-dev.yml 파일을 읽는 것에 성공하지 못하는 이유는 아직 secrets를 설정하지 않아서 그렇습니다. 이제 github secrets로 application-dev.yml을 읽게끔 해보겠습니다.

깃허브 환경 변수 설정

github actions는 base64로 인코딩된 값을 읽는다고 합니다. 따라서 환경 변수에 대한 인코딩 작업을 진행한 후에 환경변수를 만들도록 하겠습니다. 인코딩 사이트를 통해 인코딩을 진행했습니다.

그 후에 환경 변수를 설정하기 위해 레포지토리로 다시 이동합니다! 레포지토리 페이지의 settings -> Secrets and variables -> Actions 로 들어가면 환경 변수를 설정할 수 있는 페이지가 나옵니다. New repository secret 버튼을 클릭하여 application.yml 환경 변수를 넣어보도록 하겠습니다. 다시 actions를 실행시켰습니다. 만세~ 환경 변수 파일까지 실행시켰습니다:)

마무리

CI 만든지 꽤 됐는데 이제야 작성하고 있습니다. 빠른 시일 내에 CD도 작성해볼까 합니다.

이전까지는...

메신저로 공유

이전 프로젝트들을 진행하면서 모든 환경 변수 파일을 메신저를 통해 공유했습니다. 환경 변수가 바뀔 때마다 톡방이나 슬랙 채널에 남기게 되었는데요. 거참 되게 불편하죠...? 하지만 이때 당시에는 비밀 파일이기 때문에 당연한줄 알았습니다.

깃헙 서브모듈이란?

한 저장소 안에 있는 또 다른 별개의 저장소입니다. 이때 상위 저장소를 슈퍼 프로젝트(super project), 하위 저장소를 서브 모듈(sub module)이라고 합니다. 레포지토리 안에 다른 레포지토리가 있다고 이해하시면 편할 것 같습니다.

보통 대형 프로젝트에서 기능을 분리하기 위한 목적으로 사용되는데요. 저희 팀은 서브 모듈을 private 레포지토리로 설정하고 해당 레포지토리에 application*.yml 파일을 저장하기 위한 목적으로 사용했습니다.

레포지토리 연결

먼저 메인과 서브 두 레포지토리를 만듭니다. 저는 연습용 레포인 CICD 레포지토리를 슈퍼 프로젝트, sub-module 레포지토리를 서브 모듈로 두었습니다. 왼쪽이 서브, 오른쪽이 메인입니다!

메인에서 서브모듈을 등록해보겠습니다!

# git submodule add [repository-url] [path]
git submodule add https://github.com/shb03323/sub-module.git

만약 path를 생략한다면 git repository 명으로 디랙토리가 생성됩니다.

서브모듈을 등록하게 되면 위 사진과 같이 .gitmodules 와 sub-module 디랙토리가 생성된 것을 볼 수 있습니다.

.gitmodules

.gitmodules를 살펴보면 아래와 같이 서브 모듈의 경로와 repository 주소를 등록한 것을 확인할 수 있습니다.

서브 모듈 디랙토리

서브 모듈에서는 깃 초기화만 진행하고 아무 진행하지 않아 readme 파일만 있는 상태입니다. 깃헙 홈페이지에서는 아래와 같이 보입니다. @ac18ce4 와 같은 해시값이 디랙토리 이름 옆에 붙어있는데요. 이는 서브 모듈 레포지토리의 커밋 주소입니다!

서브 모듈 변동 사항 반영

서브 모듈 연결까지 성공했으니 이제 서브 모듈 변경사항을 슈퍼 프로젝트에 반영해보겠습니다.

우선 서브 모듈에 커밋, 푸시합니다. 저는 아래와 같이 리드미를 수정하여 커밋했습니다.

푸시를 진행하니 커밋 주소가 ac18ce4 -> ef4a463 으로 바뀐 것을 확인할 수 있습니다.

그렇다면 슈퍼 프로젝트에서는 어떻게 보일까요? 확인해보겠습니다. 아직 슈퍼 프로젝트에는 반영되지 않은 것을 확인할 수 있습니다. pull도 진행해보았는데요. 아래와 같이 최신 버전이라는 말만 나오고 반영되지 않고 있었습니다.

왜그럴까요? 서브 모듈 저장소는 슈퍼 프로젝트 저장소와 독립적인 저장소이기 때문입니다. 서브 모듈의 변동 사항을 반영하기 위해서는 아래의 명령어를 입력해주어야 합니다.

git submodule update --remote

무엇인가 pull 받아오는 것을 확인할 수 있습니다. 리드미에도 정상적으로 업데이트 되었네요.

푸시를 하게 되면 아래와 같이 커밋 주소가 바뀐 것을 확인할 수 있습니다.

마무리

동료들과 서브모듈을 이용하여 환경 변수를 주고 받는 방법에 대해 알아보았는데요. 원래 이런 용도로 사용하라고 만든 것은 아닌 것 같은데... private 레포를 파서 아주 잘 사용하고 있습니다. 하하하

docker로 DB를 관리하게 된 이유

1. 일관된 환경

도커 이미지를 사용하면 개발, 로컬, 운영 환경에서 모두 동일한 이미지를 배포할 수 있습니다. 즉, 모든 데이터베이스의 환경을 동일하게 유지할 수 있고 환경 변화가 있다면 동일하게 환경을 변경시킬 수 있습니다.

또한 도커 컴포즈를 이용하여 로컬에서도 동료들간 같은 환경을 구성하여 DB를 사용할 수 있습니다.

2. 환경 충돌 방지

우아한테크코스에서 DB를 위한 ec2 인스턴스는 1개만 제공되었습니다. 나중에 mysql 뿐만 아니라 다른 db를 추가하게 되는 경우에 인스턴스 내부에서 환경이 얽힐수도 있겠다는 생각을 했습니다. 만약 도커를 이용하여 컨테이너를 분리하게 된다면 환경이 얽힐 일이 없고, 더 안정적인 운영이 가능하다고 생각했습니다.

3. 손쉬운 스케일링

서비스가 커지게되면 트래픽이 늘어나고 부하가 발생할 수 있는데요. 이때 도커를 이용하면 컨테이너를 필요한 시점에 빠르게 확장하거나 축소할 수 있습니다.

EC2에 도커 설치

sudo snap install docker

명령어를 이용하여 도커를 설치합니다.

처음에는 apt update와 apt install 명령어를 통해 도커를 설치하려 했는데, 잘 되지 않았습니다. 찾아보니 요즘은 snap을 사용하면 더 간단히 도커를 설치할 수 있기에 snap 사용을 권장한다고 하네요.

위와 같이 설치를 완료했습니다.

저는 매번 sudo를 이용하여 권한 인증하는 것이 귀찮아서 추가적인 설정을 통해 일반 사용자도 도커에 접근할 수 있도록 설정했습니다. 과정은 해당 링크를 참고했습니다.

 sudo addgroup --system docker
 sudo adduser $USER docker
 newgrp docker
 sudo snap disable docker
 sudo snap enable docker

before

after

도커에 mysql 컨테이너 설치

이미지 다운

도커에서 mysql 이미지를 다운받습니다.

docker pull mysql

도커에서 이미지란 하나의 환경파일(?)을 말합니다. nginx, mysql, node 등등 많은 이미지들이 있는데, 사용 목적에 맞게 이미지를 선택해서 컨테이너로 생성하면 해당 이미지에 맞는 환경이 설치된 상태로 컨테이너를 사용할 수 있습니다. OOP에서 원하는 클래스의 인스턴스를 생성하는 것과 비슷한 느낌이라고 할 수 있겠습니다.

mysql 이미지가 정상적으로 깔린 것을 확인할 수 있습니다. tag는 버전을 뜻하는데, latest는 가장 최신버전이라는 뜻입니다. 만약 제가 docker pull mysql:8.0.33 명령어로 이미지를 풀 받게 되면 해당 버전의 mysql을 풀 받습니다.

현재 가장 최근 버전의 mysql이 8.0.33 이어서 image id가 같은 것 같습니다.

컨테이너 생성 & 실행

docker run --name mysql-dev-container -e MYSQL_ROOT_PASSWORD={비밀번호} -d -p 3306:3306 mysql:latest

해석하자면,

• --name: mysql-dev-container의 이름으로 컨테이너를 실행한다.
• -e: 컨테이너의 환경 변수중 MYSQL_ROOT_PASSWORD를 입력한 비밀번호로 설정한다.
• -d: 데몬 모드로 실행한다. (백그라운드 모드)
• -p: 호스트 포트:컨테이너 포트로 설정한다.
• 이미지는 mysql:latest 로 설정한다.

정상적으로 컨테이너가 생긴 것을 확인할 수 있습니다.

이제 컨테이너에 접속해보겠습니다.

docker exec -it {컨테이너 Id} bash

위 명령어를 통해 도커 컨테이너 bash에 접속했습니다.

mysql에 db 생성

이제 컨테이너에 mysql database를 설치해보도록 하겠습니다. 여기부터는 일반 리눅스나 맥에서 database 생성하는 것과 똑같습니다.

먼저 mysql에 접속합니다.

mysql -u root -p

그리고, database를 생성합니다.

create database ditoo_dev;

intellij에서 생성한 db에 정상적으로 접근되는지 확인해보겠습니다! 정상적으로 접근되었습니다.

간단한 post, tag, post_tag 테이블을 만들어 table이 정상적으로 생성되는지 확인해보도록 하겠습니다.

스프링 어플리케이션에서는 정상적으로 테이블이 생성된 것을 확인했습니다.

db에도 정상적으로 table이 생긴 것을 확인할 수 있었습니다.

마치며

docker로 간단하게 db를 관리하는 것을 학습했습니다. 다음 시간에는 docker-compose를 이용하여 db, spring, react 모두 같이 관리하는 방법에 대해 학습해보려 합니다.

• java 17
• springboot 3.1.1
• h2 database

실험할 엔티티

지하철 역과 노선 사이의 관계를 실험할 예정입니다. 각각의 엔티티 정보는 아래와 같습니다.

Station

@NoArgsConstructor(access = PROTECTED)
@AllArgsConstructor
@Entity
public class Station {

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

    @Column(unique = true, nullable = false)
    private String name;
}

Line

@NoArgsConstructor(access = PROTECTED)
@AllArgsConstructor
@Entity
public class Line {

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

    @Column(nullable = false)
    private String name;
}

Station과 Line은 N:1 관계로 설정할 예정입니다. 하나의 노선 안에 여러 역이 있다고 가정하고 연관 관계를 매핑해보겠습니다.

연관 관계 매핑

먼저 Station 엔티티에 Line 필드를 추가해보았습니다. 영속성 엔티티는 속성 타입으로 될 수 없다는 메시지가 나오네요. 그렇다면 String 타입으로 하면 정상적으로 동작될까요? 빨간 줄이 생기지 않았고, table 또한 정상적으로 생성되었습니다.

자 그럼 이제 Station에 Line을 연관 관계 매핑해보도록 하겠습니다. 정상적으로 table이 생긴 것을 볼 수 있습니다. foreign key로 line_id가 지정된 것을 확인할 수 있네요.

만약 @JoinColumn 어노테이션을 이용해서 name을 바꾸어주면 어떻게 될까요? join column의 이름이 line_number로 설정된 것을 확인할 수 있습니다.

여기서 모르고 있던 한가지를 배웠습니다. @JoinColumn이 없어도 line_id 라는 이름으로 연관 관계를 맺어준다는 사실을 배웠는데요. 생각보다 스프링은 더 편리해서 놀랐습니다. 하지만 명시적으로 보이는 것도 중요하기 때문에 저는 @JoinColumn(name = "line_id")로 설정할 예정입니다.

단방향 관계

지금까지 작성한 코드를 보면 Station이 Line에 접근 가능하지만, Line은 Station에 접근하지 못합니다. Line에 Station 관련 필드가 없기 때문이죠. 이걸 스프링 JPA에서는 단방향 관계라고 합니다.

만약 새로운 Station을 DB에 저장하는데, Line이 영속상태가 아니라면 어떻게 될까요?

    @Test
    void saveWithLine() {
        final Station expected = new Station("선릉역");
        expected.setLine(new Line("2호선"));
        final Station actual = stationRepository.save(expected);
        stationRepository.flush();
    }

예외가 발생합니다. 메시지를 읽어보면, flush를 하기 전에 일시적인 인스턴스를 save하라고 나와있습니다. 자바 객체를 영속성 컨텍스트에 저장해놓지 않으면 DB에 반영할 수 없다는 것을 알 수 있습니다.

Line을 먼저 저장하고 Station을 저장하면 정상적으로 동작하는 것을 확인할 수 있습니다.

    // no error
    @Test
    void saveWithLine() {
        final Station expected = new Station("선릉역");
        expected.setLine(lineRepository.save(new Line("2호선")));
        final Station actual = stationRepository.save(expected);
        stationRepository.flush();
    }

만약 update인 경우는 어떨까요?

    @Test
    void update() {
        final Station station = new Station("교대역");
        station.setLine(lineRepository.save(new Line("3호선")));
        stationRepository.save(station);
        stationRepository.flush();

        Station changedStation = stationRepository.findByName("교대역");
        changedStation.setLine(new Line("2호선"));
        stationRepository.save(changedStation);
        stationRepository.flush();
    }

같은 예외가 발생했습니다.

만약 Station과 연관 관계를 맺고 있는 Line을 DB에서 delete 하면 어떨까요? 이 경우는 DBMS 관점에서 문제가 생깁니다. 해당 Line을 참조한 모든 데이터의 연관 관계를 지워야만 삭제할 수 있습니다. 만약 참조한 데이터가 많다면 이 모든 데이터의 연관 관계를 끊어줘야 하는데요. 굉장히 노가다스러워 보입니다.

JPA는 이를 위한 것도 제공해주고 있습니다. 바로 양방향 연관 관계를 이용하는 건데요.

양방향 연관 관계

위에서 Station만 Line을 알 수 있었는데요. Line도 Station의 목록을 알게 하면 그것이 양방향 연관 관계가 됩니다.

@NoArgsConstructor(access = PROTECTED)
@AllArgsConstructor
@Getter
@Entity
public class Line {

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

    @Column(nullable = false)
    private String name;

    @OneToMany(mappedBy = "line")
    private List<Station> stations = new ArrayList<>();

    public Line(final String name) {
        this.name = name;
    }
}

여기서 @OneToMany 어노테이션이 사용되었는데요. 이는 1대다를 의미하고 있습니다. 속성에 mappedBy는 연관 관계 주인의 field 이름을 뜻합니다. Station 객체에서 Line의 필드 이름을 line으로 두었기 때문에 mappedBy = "line" 으로 두었습니다. 여기서 '연관 관계 주인'은 보통 1대다 관계에서 다 쪽이 가지게 됩니다.

만약 이 외래키를 관리하는 속성인 mappedBy를 없애면 어떻게 될까요?

새로운 table인 line_stations이 생기는 것을 확인할 수 있습니다. 이렇게 관계를 직접 명시해주지 않으면 불필요한 table이 생성되는 것을 확인할 수 있습니다.
이제 Line을 추가하는 테스트를 해보겠습니다. 먼저 Line 객체에 역 추가 메서드를 만들었습니다.

    public void addStation(final Station station) {
        station.setLine(this);
        stations.add(station);
    }

그 후에 테스트를 진행합니다.

    @Test
    void save() {
        final Line line = new Line("2호선");
        line.addStation(stationRepository.save(new Station("선릉역")));
        lineRepository.save(line);
        lineRepository.flush();
    }

테스트는 통과하지만 아래와 같이 연관 관계가 설정되지 않은 것을 확인할 수 있습니다.

연관 관계 주인에게 Line에 대한 정보를 제공하지 않았기 때문에 발생한 문제입니다.

    public void addStation(final Station station) {
        station.setLine(this);
        stations.add(station);
    }

연관 관계 주인인 Station에도 Line을 세팅했습니다. 그 결과 정상적인 쿼리가 생성되었습니다.

추가적으로 Station 객체의 setter에도 Line 객체를 호출하여 자신을 추가하겠습니다.

    public void setLine(Line line) {
        this.line = line;
        line.getStations().add(this);
    }

하지만 이때 문제가 발생합니다. 자칫 잘못하면 순환 참조가 발생하게 됩니다. 따라서 아래와 같이 순환 참조를 막아주었습니다.

    public void setLine(Line line) {
        this.line = line;
        final List<Station> stations = line.getStations();
        if (!stations.contains(this)) {
            line.getStations().add(this);
        }
    }

마지막으로 아까 살펴보았던 참조된 연관 관계 모두 끊어 삭제하는 JPA의 기능을 알아보겠습니다. 연관 관계의 주인에서 cascade 옵션을 remove로 걸면 됩니다. 그러면 참조된 것이 모두 제거되는 것을 확인할 수 있습니다.

@OneToMany(mappedBy = "line", cascade = CascadeType.REMOVE)
private List<Station> stations = new ArrayList<>();

하지만 이 방법은 참조된 모든 데이터를 제거합니다. 관계만 끊는게 아니라 싹다 삭제해버리기 때문에 위험해보입니다. 의도하지 않은 데이터도 삭제될 수 있으니까요.

관계만 끊는 방법은 조금 더 공부하고 오도록 하겠습니다.

스프링에서 사용되는 Converter는 데이터 변환을 수행하는 함수형 인터페이스입니다. 주로 Spring의 데이터 바인딩, 폼 처리, 데이터 유효성 검증 등에서 사용됩니다. 소스 객체를 대상 객체로 변환하는 기능을 제공합니다.

public interface Converter<S, T> {
    T convert(S source);
}

S 타입의 객체가 input으로 들어오면 T 타입의 객체로 변환해주는 역할을 합니다.

학습 계기

우테코 지하철 미션을 진행하면서 노선에 역을 등록하는 API를 설계하는 것이 미션에 포함되었습니다.

{
    "direction": "UP",
    "standardStationName": "구일",
    "newStationName": "가산디지털단지",
    "distance": 1
}

위는 해당 API의 request body인데요. 노선에 역을 등록할 때 "윗쪽에 추가" 혹은 "밑쪽에 추가"라는 것을 명시해야 했습니다. 그래야 기준역에서 올바른 방향으로 새로운 역이 추가되니까요:)

처음에는 String 형태의 json이 들어오기 때문에 아래와 같이 String 자료형으로 설정해주었습니다.

public class StationRegisterInLineRequest {

    @NotBlank(message = "direction 이 비어있습니다.")
    private final String direction;
    @NotBlank(message = "standardStationName 이 비어있습니다.")
    private final String standardStationName;
    @NotBlank(message = "newStationName 이 비어있습니다.")
    private final String newStationName;
    @NotNull(message = "distance 가 null 입니다.")
    @Positive(message = "거리는 양의 정수만 가능합니다.")
    private final Integer distance;

    ...

}

이때, String으로 들어오는 "direction": "UP" 값을 request dto에서 바로 enum으로 설정할 수 있지 않을까 생각했습니다. 아래처럼 말이죠.

public class StationRegisterInLineRequest {

    @NotNull(message = "direction 이 null 입니다.")
    private final SubwayDirection direction;
    @NotBlank(message = "standardStationName 이 비어있습니다.")
    private final String standardStationName;
    @NotBlank(message = "newStationName 이 비어있습니다.")
    private final String newStationName;
    @NotNull(message = "distance 가 null 입니다.")
    @Positive(message = "거리는 양의 정수만 가능합니다.")
    private final Integer distance;

    ...

}

Converter 선택

request body의 필드로 enum을 사용하는 방법을 알아보았을 때, Formatter와 Converter가 주로 쓰인다는 것을 배웠습니다.

• Formatter

  • Object <-> String 간의 변환을 담당한다.
  • Locale에 따라 다국화하는 기능을 제공한다.

• Converter

  • Source가 들어오면 Target을 반환한다.
  • Thread-safe 해서 스프링 빈으로 등록해서 사용할 수 있다.

Locale을 지원하는 Formatter는 원하는대로 타입 전환을 할 수 있는 Converter가 현재 서비스에 더 어울린다고 생각했습니다. Converter의 특별한 버전을 Formatter라고 이해했고, Formatter는 문자에 특화된 기능이라고 생각했습니다.

지금 서비스는 객체간의 타입 변환을 목적으로 했기 때문에 Converter를 선택했습니다.

Config 등록

Converter의 구현체를 만들어 String 값을 enum으로 바꾸는 convert 메소드를 구현했습니다.

@Component
public class StringToSubwayDirectionConverter implements Converter<String, SubwayDirection> {

    @Override
    public SubwayDirection convert(final String value) {
        return SubwayDirection.from(value);
    }
}

구현한 Converter를 적용하기 위해 config에 등록해주었습니다.

@Configuration
public class WebConfig implements WebMvcConfigurer {

    @Override
    public void addFormatters(final FormatterRegistry registry) {
        registry.addConverter(new StringToSubwayDirectionConverter());
    }
}

enum에도 따로 설정을 해주어야하는데요. json 형태로 값을 받기 때문에 enum의 생성자에 @JsonCreater로 json 값을 java 코드로 직렬화해야합니다.

public enum SubwayDirection {

    UP("up"), DOWN("down");

    private final String directionName;

    SubwayDirection(final String directionName) {
        this.directionName = directionName;
    }

    @JsonCreator
    public static SubwayDirection from(final String input) {
        return Arrays.stream(SubwayDirection.values())
                .filter(value -> input.equalsIgnoreCase(value.directionName))
                .findFirst()
                .orElseThrow(InvalidDirectionException::new);
    }
}

결과

json 값을 java 코드의 request body에서 enum 타입으로 설정에 성공한 것을 볼 수 있습니다. 잘못된 문자를 입력하면 아래와 같이 설정한 오류를 올바르게 오류도 보여줍니다.

마무리

누군가 알려줘서 찾은 불편이 아닌, 제가 찾은 불편을 스스로 해결해서 뿌듯합니다.

학습 계기

지금까지 request body나 request parameter, path variable를 사용하면서 어노테이션을 이용하여 요청 데이터들을 처리해줬습니다. 이를 위한 어노테이션이 있기 때문에 어노테이션 사용만으로 쉽게 원하는 데이터를 바인딩할 수 있었습니다. 하지만 이번 우테코 미션에 추가된 인증과 인가와 같은 특수 상황인 경우에는 이를 위한 어노테이션이 존재하지 않았습니다.

우테코 학습 테스트로 주어진 Interceptor와 ArgumentResolver를 보고 인증과 인가를 처리하는 것을 익혔는데요. controller의 코드에 아무런 표시없이 작업을 처리하는 Interceptor보다 @RequestBody처럼 어노테이션으로 표시를 해주고 작업 처리를 하는 ArgumentResolver를 이용해 사용자 확인 코드를 작성했습니다.

Interceptor로는 요청의 header 안에 Authorization이 있는지 확인하는 역할을 주려했는데요, header에 값을 넣어주어도 Interceptor에서는 보이지 않고 ArgumentResolver에서는 보였습니다. 그래서 Interceptor는 미션에 적용하지 못했습니다. 이 문제는 추후 해결해보겠습니다.

사용하지 않았을 때

사용하지 않았을 경우, 유저 인증이 필요한 모든 API에서 유저를 찾는 로직을 controller에 중복적으로 넣어야합니다. 아래 코드는 제 예전 프로젝트 코드입니다.

@PostMapping
public ResponseMessage createProject(
        @Valid @RequestBody ProjectRequestDto projectRequestDto, HttpServletRequest request) {

    Long userId = Long.valueOf(request.getUserPrincipal().getName());

    return ResponseMessage.toResponseEntity(
            ResponseCode.CREATE_PROJECT_SUCCESS,
            projectService.createProject(projectRequestDto, userId)
    );
}

@PatchMapping("/{projectId}")
public ResponseMessage modifyProject(@PathVariable Long projectId,
                                     @Valid @RequestBody ProjectRequestDto projectRequestDto, HttpServletRequest request) {

    Long userId = Long.valueOf(request.getUserPrincipal().getName());

    return ResponseMessage.toResponseEntity(
            ResponseCode.MODIFY_PROJECT_SUCCESS,
            projectService.modifyProject(userId, projectId, projectRequestDto)
    );
}

코드를 보면 userId를 찾는 부분을 중복으로 쓰고 있는 것을 볼 수 있습니다. 중복을 없애기 위해 HandlerMethodArgumentResolver를 사용해보도록 하겠습니다.

HandlerMethodArgumentResolver

HandlerMethodArgumentResolver를 implements하면 두 개의 메소드를 오버라이드 해야합니다. supportsParameter()와 resolveArgument()입니다. 각각 알아보겠습니다.

• boolean supportsParameter() : 요청 파라미터에 대한 조건을 걸고 조건을 충족할 때 true를 반환합니다.
• Object resolveArgument() : 앞의 supportsParameter()에서 true가 반환되면 이 메서드를 실행시켜 parameter를 원하는 형태로 바꾸어주는 메소드입니다.

두 메소드를 통해 특정 조건에 유저 인증을 할 수 있도록 설정할 수 있습니다. 저는 @Auth라는 어노테이션을 만들어 특정 조건을 만들어주었습니다.

@Target(ElementType.PARAMETER)
@Retention(RetentionPolicy.RUNTIME)
public @interface Auth {
}

간단하게 해당 어노테이션을 런타임시에 파라미터에만 사용할 수 있도록 설정했습니다.

구현 코드

먼저 supprotsParameter()에서 파라미터가 Integer 타입이고 @Auth 어노테이션을 사용했을 때 true를 반환하도록 했습니다. controller 메소드의 인자에 @Auth 어노테이션과 Integer 타입이 엮여있으면 유저 인증을 진행합니다.

resolveArgument()의 반환 타입이 Object인데, 다형성을 살리기 위해서 자바 개발자들이 가장 큰 Object를 반환하도록 설계했다고 생각했습니다. 저는 인증된 유저의 id를 반환하도록 했기 때문에 Integer 자료형으로 반환이 될 것입니다. Integer형으로 반환되기 때문에 supportsParameter()의 조건에 파라미터 타입이 Integer여야 한다는 것을 걸어 동료 개발자가 같은 파일에서 resolveArgument()의 Object 타입을 보고 어떤 타입으로 반환될 지 굳이 다른 파일을 보지 않고 알 수 있게끔 했습니다.

resolveArgument()에서는 요청 헤더에 담긴 Basic Authorization을 읽었습니다. 값을 디코딩한 후에 이메일과 패스워드로 사용자의 id를 알아내는 방식입니다.

코드는 아래와 같습니다.

@Component
public class AuthArgumentResolver implements HandlerMethodArgumentResolver {

    private static final String AUTHORIZATION = "Authorization";

    private final AuthDao authDao;

    public AuthArgumentResolver(final AuthDao authDao) {
        this.authDao = authDao;
    }

    @Override
    public boolean supportsParameter(final MethodParameter parameter) {
        return parameter.getParameterType().equals(Integer.class) &&
                parameter.hasParameterAnnotation(Auth.class);
    }

    @Override
    public Object resolveArgument(final MethodParameter parameter, final ModelAndViewContainer mavContainer,
                                  final NativeWebRequest webRequest, final WebDataBinderFactory binderFactory) {
        final HttpServletRequest httpServletRequest = (HttpServletRequest) webRequest.getNativeRequest();
        final String authorizationHeader = httpServletRequest.getHeader(AUTHORIZATION);
        final AuthenticationDto authenticationDto = BasicAuthorizationExtractor.extract(authorizationHeader);
        return authDao.findIdByEmailAndPassword(authenticationDto.getEmail(), authenticationDto.getPassword());
    }
}

이제 추가적으로 이 ArgumentResolver를 WebMvcConfigurer에 등록만 해주면 됩니다!

@Configuration
public class WebMvcConfiguration implements WebMvcConfigurer {

    private final AuthArgumentResolver authArgumentResolver;

    public WebMvcConfiguration(final AuthArgumentResolver authArgumentResolver) {
        this.authArgumentResolver = authArgumentResolver;
    }

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

이렇게 하여 컨트롤러에서 아래와 같이 간단한 어노테이션 하나로 유저를 인증할 수 있었습니다.

@PostMapping
public ResponseEntity<Void> create(@Auth final Integer userId,
                                   @RequestBody @Valid final CartRequestDto cartRequestDto) {
    cartService.create(cartRequestDto, userId);
    return ResponseEntity.created(URI.create(REDIRECT_URL)).build();
}

@GetMapping
public ResponseEntity<List<CartItemResponseDto>> read(@Auth final Integer userId) {
    final List<CartItemResponseDto> response = cartService.getProductsInCart(userId);
    return ResponseEntity.ok().body(response);
}

마무리

점점 중복을 줄이는 방법을 알게되는 것 같아 행복합니다.

테스트 코드를 작성할 때 @SpringBootTest, @JdbcTest, @WebMvcTest 차이를 확실하게 알지 않고 코드를 작성한 것 같았습니다. 차이를 제대로 알아보고자 이번 글을 올리게 되었습니다.

@JdbcTest

JDBC 관련 테스트입니다. Respository(Dao) 클래스를 위한 테스트입니다. 데이터가 정상적으로 저장되고 정상적으로 호출되는지 확인하는 것을 목적으로 한 테스트 어노테이션입니다.

특징

• jdbc와 관련 있는 빈들만 auto configuration하는 테스트
• default로 in-memory 데이터베이스를 사용
• 각각의 테스트는 하나의 트랜젝션이고, 테스트가 끝나면 원래 상태의 데이터베이스로 롤백됨

특징을 보면 굳이 스프링 빈을 모두 주입하지 않고, 상대적으로 가볍게 테스트 할 수 있다는 장점이 있습니다. 또, 데이터베이스도 직접 롤백하지 않아도 되죠.

예시 코드입니다.

@JdbcTest
class ProductDaoTest {

    @Autowired
    private DataSource dataSource;

    private JdbcTemplate jdbcTemplate;

    private ProductDao productDao;

    @BeforeEach
    void setUp() {
        productDao = new ProductDao(dataSource);
        jdbcTemplate = new JdbcTemplate(dataSource);
    }

    ...
}

DataSource를 주입시키고 JdbcTemplate와 Dao 인스턴스를 만들어주었습니다.

@Sql

테스트를 실행하기 전 원하는 sql문을 실행시켜주는 어노테이션입니다. 단위 테스트를 위해 값이 미리 세팅되어야하는 상황이 발생하는데요. 저는 patch, get, delete 메소드에서 이런 상황이 발생했습니다. 처음에는 테스트 메서드 안에서 JdbcTemplate로 직접 값을 넣어주었습니다. 아래는 그 코드입니다.

@Test
@DisplayName("상품 전체 조회 성공")
void findALl_success() {
    // given
    final String sql = "insert into product (name, image, price) values (?, ?, ?)";
    jdbcTemplate.query(sql, "디투", "ditoo.jpg", 1000);

    // when
    final List<ProductEntity> allProducts = productDao.findAll();

    // then
    assertAll(
            () -> assertThat(allProducts).hasSize(1),
            () -> assertThat(allProducts.get(0).getName()).isEqualTo("디투"),
            () -> assertThat(allProducts.get(0).getImage()).isEqualTo("ditoo.jpg"),
            () -> assertThat(allProducts.get(0).getPrice()).isEqualTo(1000)
    );
}

@Sql 어노테이션을 이용하여 sql 파일을 불러와 미리 세팅한 상태로 테스트 코드를 작성한다면 given 부분을 조금 더 쉽게 할 수 도 있을 것 같습니다! 아래는 적용한 코드입니다.

@Test
@DisplayName("상품 전체 조회 성공")
@Sql(scripts = "/dummy_data.sql")
void findALl_success() {
    // given, when
    final List<ProductEntity> allProducts = productDao.findAll();

    // then
    assertAll(
            () -> assertThat(allProducts).hasSize(3),
            () -> assertThat(allProducts.get(0).getName()).isEqualTo("pooh"),
            () -> assertThat(allProducts.get(0).getImage()).isEqualTo("pooh.jpg"),
            () -> assertThat(allProducts.get(0).getPrice()).isEqualTo(1_000_000),
            () -> assertThat(allProducts.get(2).getPrice()).isEqualTo(10)
    );
}

sql 파일의 내용은 아래와 같습니다.

truncate table product;
alter table product auto_increment = 1;
insert into product (name, image, price)
values ('pooh', 'pooh.jpg', 1000000),
       ('ditoo', 'ditoo.jpg', 1000000),
       ('pobi', 'pobi.jpg', 10);

테스트 실행 전에 sql로 값을 세팅하고 시작하면 더 깔끔한 테스트 코드를 작성할 수 있습니다.

문제 상황 발생

sql문을 보시면 alter table product auto_increment = 1;이 있습니다. 이는 pk가 auto increment인 경우에 pk를 다시 1부터 시작한다는 쿼리인데요. 1부터 시작하게 해주지 않으면 테스트가 끝나고 DB가 롤백이 되더라도 pk가 1부터 시작이 되는 것이 아니라 마지막 pk의 다음 숫자부터 시작하게 됩니다.

예를 들어보겠습니다. @Sql을 이용하여 윗 sql 스크립트 파일을 세팅하고 테스트를 2개 돌린다고 가정했을 때, 첫 테스트에서는 pk가 1, 2, 3로 1부터 시작하게 되지만 두 번째 테스트에서는 pk가 4, 5, 6으로 설정됩니다. 데이터는 롤백이 되지만 pk 시작 번호는 롤백이 되지 않은 것이죠.

그리고 이 문법은 mysql 문법이기 때문에 h2 데이터베이스를 사용한다면 application.properties에서 spring.datasource.url=jdbc:h2:mem:productDb;MODE=MySQL를 통해 mysql 모드로 실행되도록 해야합니다.

두 번째 문제 상황 발생

mysql모드로 설정하고 쿼리를 실행시켰는데도 문제가 발생했는데요. org.springframework.jdbc.datasource.init.ScriptStatementFailedException: Failed to execute SQL script statement #2 of class path resource [dummy_data.sql]: alter table product auto_increment = 1; nested exception is org.h2.jdbc.JdbcSQLSyntaxErrorException: Syntax error in SQL statement "alter table product [*]auto_increment = 1"; expected "., ADD, SET, RENAME, DROP, ALTER"; SQL statement: alter table product auto_increment = 1 [42001-214] 위와 같은 에러가 발생했습니다. 분명 mysql모드로 바꾸었는데 왜 h2 데이터베이스 sql 오류로 나타났을까요...?

@JdbcTest를 쓰면서 mysql 설정으로 변경해주지 않아서 그렇습니다. @JdbcTest 특징 부분에서 언급했던

default로 in-memory 데이터베이스를 사용

때문에 테스트가 자동으로 in-memory h2 데이터베이스를 사용하게 된 것이죠. 이 설정을 바꿔주기 위해 @AutoConfigureTestDatabase(replace = AutoConfigureTestDatabase.Replace.NONE)를 사용했습니다.

여기서 Replace를 살펴보자면 아래 사진과 같이 3가지 옵션이 있습니다. default는 ANY입니다.

• ANY: 자동 설정이나 수동 정의에 상관 없이 DataSource 빈을 교체
• AUTO_CONFIGURED: 자동 설정된 경우에 DataSource 빈을 교체
• NONE: default DataSource를 교체하지 않음

application.properties에 설정을 해두어도 Replace.ANY 설정으로 in-memory로 바뀌어버린 설정을 None으로 바꾸어 mysql를 사용하도록 설정했습니다.

아래는 바뀐 코드입니다.

@JdbcTest
@AutoConfigureTestDatabase(replace = AutoConfigureTestDatabase.Replace.NONE)
class ProductDaoTest {

    @Autowired
    private DataSource dataSource;

    private JdbcTemplate jdbcTemplate;

    private ProductDao productDao;

    @BeforeEach
    void setUp() {
        productDao = new ProductDao(dataSource);
        jdbcTemplate = new JdbcTemplate(dataSource);
    }

    @Test
    @DisplayName("상품 전체 조회 성공")
    @Sql(scripts = "/dummy_data.sql")
    void findALl_success() {
        // given, when
        final List<ProductEntity> allProducts = productDao.findAll();

        // then
        assertAll(
                () -> assertThat(allProducts).hasSize(3),
                () -> assertThat(allProducts.get(0).getName()).isEqualTo("pooh"),
                () -> assertThat(allProducts.get(0).getImage()).isEqualTo("pooh.jpg"),
                () -> assertThat(allProducts.get(0).getPrice()).isEqualTo(1_000_000),
                () -> assertThat(allProducts.get(2).getPrice()).isEqualTo(10)
        );
    }

    ...
}

마무리

에러를 해결하면서 왜 안되지 하며 저와 비슷한 상황을 겪은 사람들을 검색했습니다. 사실 에러 메시지에서 h2 설정으로 되어있다는 것을 알 수 있었는데, 왜 변하지 않았을까 고민하기 보다는 일단 구글링을 했던 것 같습니다. 조금 더 근본적인 해결책을 찾는 습관을 길러야 할 것 같습니다.

결론부터...

결론부터 말하자면 @RestController는 @Controller와 @ResponseBody를 합친 어노테이션입니다.

@Controller
@ResponseBody
public class Controller {}

@RestController
public class RestfulController {}

그렇다면 @RestController는 컨트롤러에서 ResponseBody로 반환을 해줄 때 사용하면 되는 것일까요? @Controller는 ResPonseBody가 아닌 형식(json, xml...이 아닌 형식)을 반환할 때 쓰이는 것일까요?

공부해보니 두 어노테이션의 차이는 단순히 반환 값 차이뿐 아니라 철학적인 차이도 있다는 것을 알았습니다. 이번에는 그 철학적인 차이를 알아보기 위해 글을 작성하게 되었습니다.

@Controller

스프링에서 @Controller는 주로 뷰를 반환하기 위해 사용됩니다. 컨트롤러의 메소드를 호출하게 되면 컨트롤러에서 반환되는 String에 해당하는 뷰 이름을 ViewResolver에 전달합니다.

자세한 동작 방식은 유저 페이지를 조회하는 것으로 예로 들겠습니다.

1️⃣ 클라이언트가 서버에 "/user" uri에 대한 요청을 합니다. 2️⃣ HandlerMapping에서 "/user"와 매칭되는 handler를 찾습니다. 3️⃣ 매칭되는 컨트롤러가 UserController라는 것을 알려줍니다. 4️⃣ HandlerAdapter에게 UserController의 처리를 요청합니다. 5️⃣ 어댑터는 UserController를 실행시킵니다. 6️⃣,7️⃣ 실행 결과를 반환합니다. 8️⃣ 실행 결과와 일치하는 뷰 검색을 ViewResolver에 요청합니다. 9️⃣,🔟 찾은 뷰를 반환한다.

@RestController

백엔드 어플리케이션에서 주로 json 형식으로 데이터를 응답합니다. json 형식의 데이터를 반환 받기 위해 스프링에서 @ResponseBody 어노테이션을 이용합니다.

다음은 view가 아닌 json을 반환할 때 실행되는 과정입니다.

1️⃣ 클라이언트가 서버에 "/user" uri에 대한 요청을 합니다. 2️⃣ HandlerMapping에서 "/user"와 매칭되는 handler를 찾습니다. 3️⃣ 매칭되는 컨트롤러가 UserRestController라는 것을 알려줍니다. 4️⃣ HandlerAdapter에게 UserRestController의 처리를 요청합니다. 5️⃣ 어댑터는 UserController를 실행시킵니다. 6️⃣ 실행 결과로 ResponseEntity를 반환합니다. 이 때 @ResponseBody 어노테이션을 사용하였기 때문에 응답 결과를 웹 응답의 body로 감쌉니다. 7️⃣,8️⃣ 반환 결과를 전달합니다.

마무리

스프링 프로젝트 자체에서 view를 반환하고 싶은 경우에는 @Controller를, json이나 xml 형식으로 클라이언트에 전달하고 싶은 경우에는 @RestController를 사용합시다.

• 스프링에서 지원하는 jdbc를 편하게 사용하기 위한 클래스입니다.

JDBC

우테코 체스 미션에서 JdbcTemplate를 사용하지 않고 직접 jdbc를 사용했습니다. 아래의 코드와 같이 DB 연결, 자원 정리 작업을 직접했습니다.

public Connection getConnection() {
    try {
        return DriverManager.getConnection("jdbc:mysql://" + SERVER + "/" + DATABASE + OPTION, USERNAME, PASSWORD);
    } catch (final SQLException e) {
        System.err.println("DB 연결 오류:" + e.getMessage());
        e.printStackTrace();
        return null;
    }
}

@Override
public int save(final ChessGameDto chessGameDto) {
    try (final Connection connection = databaseConnector.getConnection()) {
        int chessGameId = saveChessGame(chessGameDto, connection);
        savePiece(chessGameDto.getBoard(), connection, chessGameId);
        return chessGameId;
    } catch (SQLException | IllegalStateException e) {
        e.printStackTrace();
        throw new RuntimeException("정상 저장되지 않았습니다.");
    }
}

private int saveChessGame(final ChessGameDto chessGameDto, final Connection connection) {
    final String query = "insert into chess_game(turn) values (?)";
    try (final PreparedStatement ps = connection.prepareStatement(query, Statement.RETURN_GENERATED_KEYS);) {
        ps.setString(1, chessGameDto.getTurn());
        ps.executeUpdate();
        return findChessGameId(ps);
    } catch (SQLException e) {
        e.printStackTrace();
        throw new RuntimeException("정상 저장되지 않았습니다.");
    }
}

일부의 코드를 가져왔습니다. 코드에서와 같이 connection을 할 때 application.properties (application.yml)의 DB 연결 정보를 직접 넣어주어야 합니다. 또, 자원 정리 또한 직접 해줘야 합니다.

Spring JDBC

JdbcTemplate을 사용하면 위의 코드처럼 직접 connection을 걸어주지 않아도 됩니다. DataSource가 Connection 객체 생성을 하도록 할 수 있습니다.

private final JdbcTemplate jdbcTemplate;

public JdbcTemplateDao(final DataSource dataSource) {
    this.jdbcTemplate = new JdbcTemplate(dataSource);
}

@Override
public int save(final ChessGameDto chessGameDto) {
    final String sql = "insert into chess_game(turn) values (?)";
    jdbcTemplate.update(sql, chessGameDto.getTurn());
}

DataSource를 생성자의 인자로 받아왔지만 getConnection() 메소드가 보이지 않습니다. DB 연결을 하지 않고 쿼리를 날리는 것처럼 보입니다. 자원 정리를 하는 부분도 보이지 않습니다. JdbcTemplate의 update()메소드에서 DB 연결과 자원을 정리 모두 해주기 때문입니다. 아래 코드는 JdbcTemplate의 update() 메소드의 구현체 입니다. 마지막의 execute() 메소드를 주목해보겠습니다.

    @Override
    public int update(final String sql) throws DataAccessException {
        Assert.notNull(sql, "SQL must not be null");
        if (logger.isDebugEnabled()) {
            logger.debug("Executing SQL update [" + sql + "]");
        }

        /**
         * Callback to execute the update statement.
         */
        class UpdateStatementCallback implements StatementCallback<Integer>, SqlProvider {
            @Override
            public Integer doInStatement(Statement stmt) throws SQLException {
                int rows = stmt.executeUpdate(sql);
                if (logger.isTraceEnabled()) {
                    logger.trace("SQL update affected " + rows + " rows");
                }
                return rows;
            }
            @Override
            public String getSql() {
                return sql;
            }
        }

        return updateCount(execute(new UpdateStatementCallback(), true));
    }

    @Nullable
    private <T> T execute(StatementCallback<T> action, boolean closeResources) throws DataAccessException {
        Assert.notNull(action, "Callback object must not be null");

        Connection con = DataSourceUtils.getConnection(obtainDataSource());
        Statement stmt = null;
        try {
            stmt = con.createStatement();
            applyStatementSettings(stmt);
            T result = action.doInStatement(stmt);
            handleWarnings(stmt);
            return result;
        }
        catch (SQLException ex) {
            // Release Connection early, to avoid potential connection pool deadlock
            // in the case when the exception translator hasn't been initialized yet.
            String sql = getSql(action);
            JdbcUtils.closeStatement(stmt);
            stmt = null;
            DataSourceUtils.releaseConnection(con, getDataSource());
            con = null;
            throw translateException("StatementCallback", sql, ex);
        }
        finally {
            if (closeResources) {
                JdbcUtils.closeStatement(stmt);
                DataSourceUtils.releaseConnection(con, getDataSource());
            }
        }
    }

처음에 getConnection()으로 DB와 연결을 하고, 마지막 finally에서 DB 연결을 해제하고 Statement의 자원을 정리합니다. JdbcTemplate의 모든 메소드는 execute()를 거치게 되는데, 이 때 자원 할당과 정리를 해주고 있습니다!

RowMapper

JdbcTemplate의 메소드를 이용하다 보면 원하는 도메인 클래스 타입으로 반환되게 하고 싶은 경우가 있습니다. 아래의 코드와 같이 반환 값을 도메인 클래스로 지정하게 되면 class mismatch 에러가 발생합니다.

public User getUser(Long id) {
    final String sql = "select * from users where id = ?";
    return jdbcTemplate.queryForObject(sql, User.class, id);
}

당연하게 DB에는 User 객체가 존재하지 않습니다. users table이 존재할 뿐이죠. 그런데 DB에서 User 타입으로 반환하게끔 코드를 작성했기 때문에 에러가 발생한 것입니다. 이런 상황을 위해 Spring JDBC는 RowMapper를 제공합니다.

RowMapper를 사용하면 원하는 형태의 결과값을 반환할 수 있습니다.

public User getUser(Long id) {
    final String sql = "select * from users where id = ?";
    return jdbcTemplate.queryForObject(sql, userRowMapper, id);
}

private final RowMapper<User> userRowMapper = (resultSet, rowNum) -> {
    User user = new User(
            resultSet.getLong("id"),
            resultSet.getString("name"),
            resultSet.getString("nickname"),
            resultSet.getInt("age"),
            resultSet.getString("address")
    );
    return user;
};

ResultSet으로 DB 결과값을 먼저 받고 User 객체에 담아서 반환하는 방식입니다. 조금 더 개선해보자면 아래와 같이 바꿀 수 있습니다.

public User getUser(Long id) {
    final String sql = "select * from users where id = ?";
    return jdbcTemplate.queryForObject(
            sql, 
            (resultSet, rowNum) -> new User(
                    resultSet.getLong("id"),
                    resultSet.getString("name"),
                    resultSet.getString("nickname"),
                    resultSet.getInt("age"),
                    resultSet.getString("address")
                    ), 
            id);
}

NamedParameterJdbcTemplate

기존 JdbcTemplate에는 불편한 점이 있었습니다. 쿼리에 들어가는 인자를 세팅할 때 순서대로 세팅을 해주어야 했습니다. 아래와 같이 말이죠.

final String sql = "insert into users (name, nickname, age, address) values (?,?,?,?)"
template.update(sql, user.getName(), user.getNickname(), user.getAge(), user.getAddress());

인자가 많아질수록 순서는 헷갈리게 되고 굉장히 불편해지는데요, 이럴 때 사용할 수 있는 것이 NamedParameterJdbcTemplate 입니다. NamedParameterJdbcTemplate를 사용하면 메소드 매개변수의 순서를 고려하지 않아도 됩니다.

public int saveUser(final User user) {
    final String sql = "insert into users(name, nickname, age, address) values (:name,:nickname,:age,:address)";
    final SqlParameterSource param = new MapSqlParameterSource()
            .addValue("name", user.getName())
            .addValue("age", user.getAge())
            .addValue("nickname", user.getNickname())
            .addValue("address", user.getAddress());
    return namedParameterJdbcTemplate.update(sql, param);
}

key-value 형태인 Map 방식으로 parameter source를 저장하기 때문에 JdbcTemplate에 비해 더 간편하게 코드를 작성할 수 있었습니다. 위 코드에서는 더 간단하게 코드를 작성할 수도 있습니다. BeanPropertySqlParameterSource를 이용하는 방법인데요. 코드를 우선 보겠습니다.

public int saveUser(final User user) {
    final String sql = "insert into users(name, nickname, age, address) values (:name,:nickname,:age,:address)";
    final SqlParameterSource param = new BeanPropertySqlParameterSource(user);
    return namedParameterJdbcTemplate.update(sql, param);
}

BeanPropertySqlParameterSource는 Java Bean 객체의 속성 이름을 key로 하고, 해당 속성의 값을 value로 하여 SqlParameterSource 구현체를 만듭니다. MapSqlParameterSource처럼 key-value를 이용하는데, BeanPropertySqlParameterSource는 자동으로 key-value 쌍을 연결해주는 방식입니다. 당연하게도 필드 명과 parameter source들의 이름이 같아야합니다.

SimpleJdbcInsert

윗 부분의 코드들은 삽입 과정에서 불편한 점이 있습니다. 삽입하고 나서 바로 id를 조회하고 싶을 때, 코드가 굉장히 복잡해집니다. 아래의 코드는 KeyHolder를 이용하여 primary key를 조회하는 방식인데, 가독성이 떨어집니다.

public Long insertWithKeyHolder(User user) {
    final String sql = "insert into users (name, nickname, age, address) values (?, ?, ?, ?)";
        final KeyHolder generatedKeyHolder = new GeneratedKeyHolder();
        jdbcTemplate.update(connection -> {
            PreparedStatement ps = connection.prepareStatement(sql, new String[]{"id"});
            ps.setString(1, user.getName());
            ps.setString(2, user.getNickname());
            ps.setInt(3, user.getAge());
            ps.setString(4, user.getAddress());
            return ps;
        }, generatedKeyHolder);
        return generatedKeyHolder.getKey().longValue();
    }

이를 위해 스프링에서는 SimpleJdbcInsert라는 삽입을 위한 클래스를 제공합니다. 처음에 아래와 같이 세팅을 합니다.

private SimpleJdbcInsert insertActor;

public SimpleInsertDao(DataSource dataSource) {
    this.insertActor = new SimpleJdbcInsert(dataSource)
            .withTableName("users")
            .usingGeneratedKeyColumns("id");
}

table명과 generatedKey의 칼럼명을 설정해주면 SimpleJdbcInsert를 사용할 때 해당 table의 해당 칼럼의 값을 조회할 수 있게 됩니다. 아래의 코드처럼 간단하게 insert 할 수 있습니다.

public User insertWithSimpleJdbcInsert(User user) {
    SqlParameterSource params = new BeanPropertySqlParameterSource(user);
    final long id = insertActor.executeAndReturnKey(params).longValue();
    return new User(id, user.getName(), user.getNickname(), user.getAge(), user.getAddress());
}

마무리

Spring JDBC 라이브러리에 있는 주요 객체들에 대해 살펴보았습니다. 처음 공부해보는 라이브러리라서 부족한 부분이 있을 것 같습니다. 잘못된 정보는 차차 수정해 나가겠습니다.

• 사다리 실행 결과를 출력해야 한다.
• 개인별 이름을 입력하면 개인별 결과를 출력하고, "all"을 입력하면 전체 참여자의 실행 결과를 출력한다.

사다리 타기 방식

첫 리뷰 요청에서는 사다리를 내려갈 때 모든 플레이어가 한 층씩 내려갔다. 층을 내려갈 때 다리가 있으면 다리의 왼쪽과 오른쪽에 있는 유저의 위치를 바꾸어주었다. 이렇게 끝까지 내려가면 플레이어들의 최종 위치가 결과 리스트로 생성된다.

처음에는 위와 같은 방식이 효율적이어서 선택했다. 모든 유저를 한 번에 계산하기 때문에 성능적으로 좋아보였다.

하지만 만약 밑에서 위로 연결되는 다리가 있다면 내가 선택한 방식을 쓸 수 없다. 그리고 현실에서 내가 선택한 방식으로 사다리타기를 하지 않는다. 보통 한 명씩 사다리를 탄다. 성능적으로는 이점이 있을지라도 확장성에 있어서 단점이 많이 보이는 방법이었다. 그래서 두번째 리팩터링을 하면서 한 명씩 사다리를 타는 방식으로 변경했다.

비대한 controller

처음 코드를 작성할 때 controller에 도메인 생성이나 정보 교환 로직을 넣었다. controller는 view와 domain의 이어주는 역할만 담당해야하는데 도메인이 담당해야할 부분까지 역할 수행을 했다. 리팩터링하면서 최대한 controller의 크기를 줄여보려 했으나 실패한 것 같다.

회고를 하는 지금 코드를 보았을 때 controller를 더 작게 줄여볼만한 부분이 여럿 보였다. 특히 모든 domain 생성을 controller가 담당하게 하여 아쉬웠다.

github

코드 : https://github.com/shb03323/java-ladder/tree/step2 PR : https://github.com/woowacourse/java-ladder/pull/219

마무리

오래전 미션의 회고여서 그런가,,, 코드가 너무 별로라는 생각이 강하게 든다. 나 정말 발전하긴 했나보다.