DevLog

[Spring] 프로퍼티 주입 시 동적으로 핸들링하기

dolmeng2 — Sat, 28 Sep 2024 09:21:10 +0900

들어가기 전

블로그를 자주 써야겠다고 생각했는데 또 마지막 글을 쓴 지 3개월이 지나버렸다. 그래서, 사내에서 개발하던 중에 발생했던 이슈가 생각나서 간단하게 적어보고자 한다. 사실 해결 방법은 간단했던 문제였는데, 어떤 식으로 문제를 해결해나갔는지 적어두면 좋을 것 같아서 작성해보고자 한다.

현재 사내 시스템에서는 카프카를 통해 비동기로 핵심 비즈니스 로직을 처리하는 부분이 많은데, 우리 서비스의 핵심 기능이라고 볼 수 있을 만큼 중요한 기능이다 보니까 작은 피처를 개발하더라도 꼭 테스트를 해주고 넘어가는 부분들이 있다.
이때, 보통은 본인의 로컬 환경에서 띄워서 테스트를 하는 경우도 많지만, 나 같은 경우 로컬에서 처리되는 느린 속도 & 실제 앱 환경에서 어떤 식으로 돌아가는지 (모든 플로우가 정상적으로 동작하는지) 확인하고 싶은 경우가 많아서 개발 환경에 작업물을 띄워서 테스트하는 경우가 많았다.

이때, 현재 사내 시스템 상으로는 내가 작업한 branch를 대상으로 내 요청이 자동으로 포워딩 되는 기능을 제공하고 있어 테스트하는데 어렵지는 않지만, 다음과 같은 문제가 발생하고 있었다.

☁︎ 카프카를 사용하는 부분에 대해서는 별도로 토픽, 혹은 컨슈머 그룹을 분리해주지 않으면 내 개인 작업 환경에서 프로듀싱한 데이터가 개발환경에서 컨슘이 되어 원하는대로 테스트가 동작하지 않음
☁︎ 개발 환경에 바로 merge를 하게 되면 타인의 작업물과 겹치기도 하고, 실수로 운영 환경으로 배포본이 나갈 수 있음

첫 번째 문제의 경우, 개발 환경과 내가 작업한 브랜치 환경이 둘 다 컨슘을 진행하게 되어서 일부 트래픽은 개발 환경으로, 일부 트래픽은 나의 개인 브랜치 환경으로 컨슘이 되어, 모든 로직들이 정상적으로 동작하는지 확인이 어려운 문제였다.

그래서 보통 우리 팀 인원들은 개발 환경에 바로 merge를 진행하여 테스트를 진행하는 경우도 있었는데, 사실 올바른 테스트 방법은 아니라는 생각이 계속 들었었다. (믿음 주도 개발....) 혹은, 개인 작업물 대상으로 매번 토픽이나 컨슈머 그룹을 변경하여 push 하고, merge 시에 제거하는 방법을 활용하는 방법도 있었다. 당연하게도 이는 매우 귀찮다 보니까 자주 사용하지 않는 방법이었다... ㅠㅠ

물론! 통합 테스트를 통해서 어느 정도 확인이 가능하지만 (embedded kafka 활용) 앱 내에서 확인하는 것이 조금 더 편하게 느껴져서 다른 방법으로 해결을 하고 싶었다. (사실 통합 테스트를 사용하는 것이 맞다...! 다만 우리의 모든 비즈니스 로직에 대해 완벽하게 적용이 되어 있는 것은 아니라서 테스트에 조금 더 고도화가 필요한 상황이었던 것도 맞다.)

그래서, ‘개인 branch에서 테스트를 할 때 사용자에 따라 자동으로 토픽이 변경되도록 만들기’를 목표로 삼고 이번에 작업을 진행해보았었다.

빈 후처리기 도입해보기

현재 사내 프로젝트에서는 토픽에 대한 정보가 application.yml 파일에 정의되어 있어, 토픽에 대한 정보를 받아올 때 다음과 같이 @Value 어노테이션을 사용하여 프로퍼티 정보를 읽어왔었다.

@Value("\${very.important.topic}")
val topic: String

그래서 처음 작업을 들어갈 때는 스프링의 @Value 어노테이션이 어떤 식으로 돌아가는지 살펴보고 싶어, @Value 어노테이션에 적혀 있는 주석을 먼저 읽어보았었다.

Note that actual processing of the @Value annotation is performed by a BeanPostProcessor which in turn means that you cannot use @Value within BeanPostProcessor or BeanFactoryPostProcessor types. Please consult the javadoc for the AutowiredAnnotationBeanPostProcessor class (which, by default, checks for the presence of this annotation)

위 내용을 보니, 실질적으로 @Value 어노테이션에 대한 처리는 BeanPostProcessor 에 의해서 수행이 된다고 써있는 것을 볼 수 있었으며, AutowiredAnnotationBeanPostProcessor 을 참고해보라는 내용이었다. 오호, 그러면 이 친구를 통해서 진행하겠다 싶어서 대충 내부 내용을 보았다.

public AutowiredAnnotationBeanPostProcessor() {
    this.autowiredAnnotationTypes.add(Autowired.class);
    this.autowiredAnnotationTypes.add(Value.class);
    ...
}

생성자에서 ‘autowiredAnnotationTypes’ 라는 필드에 @Value 어노테이션을 넣어두는 것을 볼 수 있었다.
그리고, 조금 더 파고 들다 보니 대충 다음과 같이 동작한다는 것을 파악하였다.

@Override
public PropertyValues postProcessProperties(PropertyValues pvs, Object bean, String beanName) {
    // 빈에 대한 메타데이터 조회하기
    InjectionMetadata metadata = findAutowiringMetadata(beanName, bean.getClass(), pvs);
    // 의존성 주입하기
    metadata.inject(bean, beanName, pvs);
    return pvs;
}

private InjectionMetadata findAutowiringMetadata(String beanName, Class<?> clazz, @Nullable PropertyValues pvs) {
    ...
    InjectionMetadata metadata = this.injectionMetadataCache.get(cacheKey);
    ...
    // 메타데이터 생성
    metadata = buildAutowiringMetadata(clazz);
}

private InjectionMetadata buildAutowiringMetadata(Class<?> clazz) {
    // @Value나 @Autowired 가 붙은 게 아니라면 패스
    if (!AnnotationUtils.isCandidateClass(clazz, this.autowiredAnnotationTypes)) {
        return InjectionMetadata.EMPTY;
    }

    ...

    List<InjectionMetadata.InjectedElement> elements = new ArrayList<>();

    final List<InjectionMetadata.InjectedElement> currElements = new ArrayList<>();

    // 어노테이션 찾아서 메타데이터 생성
    ReflectionUtils.doWithLocalFields(targetClass, field -> {
    MergedAnnotation<?> ann = findAutowiredAnnotation(field);
    if (ann != null) {
        if (Modifier.isStatic(field.getModifiers())) {
            if (logger.isInfoEnabled()) {
                logger.info("Autowired annotation is not supported on static fields: " + field);
            }
            return;
        }
        boolean required = determineRequiredStatus(ann);
        currElements.add(new AutowiredFieldElement(field, required));
    }
});

    ...

    return InjectionMetadata.forElements(elements, clazz);
}

- 특정 클래스에서 @Autowired가 붙은 필드와 메서드를 찾아내고, 해당 필드나 메서드가 의존성 주입을 받을 수 있도록 메타데이터를 구축한다.
- 구축된 메타데이터를 바탕으로 실제로 주입을 진행한다.
- 이것을 보고 대충 빈 후처리기를 활용하여 리플렉션을 통해 동적으로 필드 내용을 변경해줄 수 있을 것 같다는 생각이 들었다.

사용자 구분하기

그렇다면, 이번에는 사용자를 어떻게 식별하면 좋을지가 고민이 되었다.
실제로 개인 branch를 대상으로 애플리케이션이 띄워질 때 서버의 프로퍼티를 동적으로 주입해줄 수 있도록 만들어도 되지만, 인프라 레벨까지 무언가 수정을 하고 싶지 않아서 어떤 정보를 활용할 수 있을지 고민을 했었다.

그러다가 발견한 것이, 처음 스프링이 시작될 때 뜨는 문구였다.
처음 스프링이 시작되면 ‘Starting TestApplication using Java 17.0.10 on jwjw-1 with PID …‘ 와 같은 문구가 뜬다는 것을 보고, 여기에서 ‘jwjw-1’라는 이름은 어디에서 가져오는지 궁금해졌었다.

실제로 다른 개발자분들이 서버를 뜰 때 다 다른 이름이 노출되는 것을 보고, 이 이름을 사용하여 토픽의 postfix로 붙여준다면 딱 사용자 수만큼만 신규 토픽이 생성되니 괜찮을 것이라고 판단하였다.

그래서, 이 문구를 어디에서 찍어줄지 확인해보기 위해서 또 다시 하나씩 파고 들기 시작했다.
기본적으로 코틀린 + 스프링 부트를 사용한다면 main 함수에 다음과 같은 실행 함수가 있는 것을 볼 수 있다.

fun main(args: Array<String>) {
    runApplication<TestApplication>(*args)
}

inline fun <reified T : Any> runApplication(vararg args: String): ConfigurableApplicationContext =
    SpringApplication.run(T::class.java, *args)

여기에서 내부를 계속 파고 들어가다 보면, 다음과 같이 start messsage를 만드는 것을 볼 수 있는데, 여기에서 appendOn() 함수를 보면, 내부적으로 InetAddress.getLocalHost().getHostName() 를 통해서 받아오는 것을 알 수 있었다!

private CharSequence getStartingMessage() {
    StringBuilder message = new StringBuilder();
    message.append("Starting ");
    appendApplicationName(message);
    appendVersion(message, this.sourceClass);
    appendJavaVersion(message);
    // 여기!
    appendOn(message);
    appendPid(message);
    appendContext(message);
    return message;
}

private void appendOn(StringBuilder message) {
    long startTime = System.currentTimeMillis();
    append(message, "on ", () -> InetAddress.getLocalHost().getHostName());
    ...
}

호스트 이름을 활용하게 되면 개인 branch에서 작성한 내용이 나간 서버의 경우 해당 branch를 트리거한 사용자의 정보가 남기 때문에 이를 바탕으로 식별을 하면 좋을 것 같다고 판단하였다.

빈 후처리기를 활용한 초기 구성

어느 정도 윤곽이 잡혔으니, 실제로 코드를 작성해보자.
초기에는 `@ConvertTopic` 이라는 어노테이션을 만들어서, 해당 어노테이션이 붙어 있는 필드들에 대해 리플렉션으로 접근하여 객체를 다시 만들어주는 방법을 생각하였다.

@Target(AnnotationTarget.FIELD)
@Retention(AnnotationRetention.RUNTIME)
annotation class ConvertTopic(
    val topic: String
)

여기에서 필드로 가지고 있는 ‘topic’에 실제 토픽 정보를 담은 프로퍼티 이름을 담을 수 있도록 설정하였다.
이후, 빈 후처리기 함수의 인터페이스 중에서 스프링 빈이 생성된 이후, 초기화 콜백이 호출되기 이전에 호출될 수 있도록 postProcessBeforeInitialization() 함수를 활용하였다.

@Component
class ConvertTopicAnnotationBeanPostProcessor(
    private val environment: Environment,
    @Value("\${spring.profiles.active}")
    private val profile: String,
) : BeanPostProcessor {

    override fun postProcessBeforeInitialization(bean: Any, beanName: String): Any? {
        ReflectionUtils.doWithFields(bean::class.java, ConvertTopicCallback(bean, environment, profile))
        return bean
    }
}

다행히도 스프링에서는 ReflectionUtils 라는 고급 도구를 제공해주고 있기 때문에, 조금 더 간결하게 코드를 작성할 수 있었다.
두 번째 인자로 작성한 FieldCallback 을 통하여 특정 필드에 대해 해당 콜백 내부에서 조작해 첫 번째 인자로 받은 클래스를 원하는대로 바꿀 수 있게 된다.

class ConvertTopicCallback(
    private val bean: Any,
    private val environment: Environment,
    private val profile: String,
) : ReflectionUtils.FieldCallback {

    override fun doWith(field: Field) {
        // 원하는 profile이 아니면 조작 X
        if (profile != "...") {
            return
        }

        val targetAnnotation = field.getAnnotation(ConvertTopic::class.java) ?: return
        field.isAccessible = true

        // topic 필드에 담긴 프로퍼티 정보를 바탕으로 실제 값 가져오기
        val original = environment.getProperty(targetAnnotation.topic)

        // 바뀐 값
        val hostName = InetAddress.getLocalHost().hostName
        val new = original.plus(".$hostName")
        field.set(bean, new)
    }
}

그리고, 해당 어노테이션이 달려 있는 필드에 대해서만 동작할 수 있도록 간단한 검증 조건을 추가해주고, 흔한 리플렉션 코드에서 많이 볼 수 있는 isAccessible 처리를 통해 필드 값을 조작할 수 있게 해주었다. 실제로는 profile 별로 조금 더 컨버팅 하는 로직을 분리하였지만, 여기에서는 간략하게 호스트 이름을 불러온 프로퍼티에 추가하는 정도로만 작성해두었다.
굉장히 복잡해 보여도, 실제 코드를 보면 단순히 필드 값을 원하는대로 바꾸어서 셋팅해주는 정도이다.

정상적으로 기능이 동작하는지 테스트 코드를 통해 확인해보자.

@Component
class TestClass(
    @Value("\${test-topic1}")
    private val testTopic1: String
) {
    @ConvertTopic("test-topic2")
    private lateinit var testTopic2: String

    fun getTestTopic1(): String {
        return testTopic1
    }

    fun getTestTopic2(): String {
        return testTopic2
    }
}

먼저, 테스트 클래스를 하나 정의하여 만들어준 @ConvertTopic 어노테이션을 붙인 필드와 기본 @Value 를 통하여 정의한 필드를 각각 선언해주었다.

@Import(TestClass::class)
@TestPropertySource(
    properties = [
        "test-topic1=topic1",
        "test-topic2=topic2"
    ]
)
class ConvertTopicAnnotationBeanPostProcessorTest(
    private val testClass: TestClass,
) : BehaviorSpec({

    Given("토픽 치환 테스트") {
        When("@ConvertTopic 가 붙어 있지 않은 변수에 대해서") {
            Then("컨버팅을 진행하지 않는다.") {
                testClass.getTestTopic1() shouldBe "topic1"
            }
        }

        When("@ConvertTopic 가 붙은 변수에 대해서") {
            Then("컨버팅을 진행한다.") {
                testClass.getTestTopic2() shouldBe "topic2.test"
            }
        }
    }
})

그리고, @TestPropertySource 를 통해서 실제 테스트 클래스에서 사용할 테스트 프로퍼티를 정의해주었다. application-test.yml 등을 활용해도 좋지만, 해당 테스트 클래스에서만 유효하기를 바랬고, 무엇보다 명시적으로 테스트에 드러나기를 바랬다. (별도의 파일로 분리하게 되면 아무래도 해당 파일을 다시 들어가서 확인을 해봐야 하니까 불편하게 느껴질 수도 있겠다는 생각이 들었다,)

실제로 테스트를 돌려보면 의도대로 잘 동작을 하였으며, test-topic1의 경우 그대로 topic1 이라는 값으로, test-topic2의 경우 topic2가 아닌 topic2.test로 컨버팅이 잘 된 것을 볼 수 있었다!

그러나, 여기에서 한 가지 찜찜한 점이 있었다. 바로, TestClass에서도 볼 수 있는 것처럼 생성자 주입을 할 수 없었던 것이었다.
아무래도 클래스의 생성자 파라미터가 아닌 필드 파라미터를 접근하도록 하려고 하다 보니 그랬던 것 같았었다. 이를 해결하기 위해 다음과 같이 @Value + @ConvertTopic 을 함께 혼용하여 사용하고, 필드에 대한 콜백 로직을 살짝 수정해주었다.

override fun doWith(field: Field) {
    // 필드에 어노테이션이 존재하는지 확인
    if (field.isAnnotationPresent(ConvertTopic::class.java).not()) {
        return
    }

    // ...

    // bean 객체에 대해 field로 지정된 필드 값을 조회할 수 있도록 수정
    // 원본 값
    val original = field.get(bean).toString()

    // 바뀐 값
    val hostName = InetAddress.getLocalHost().hostName
    val new = original.plus(".$hostName")
    field.set(bean, new)
}

어노테이션의 필드로 주어졌던 값을 활용했던 것과 다르게, 이번에는 bean 객체의 field 값을 직접 접근하도록 만들었다. 이 코드가 잘 이해가 안 될 수 있는데, 아래 테스트 클래스의 예제를 바탕으로 알아보자.

@Component
class TestClass(
    @Value("\${test-topic1}")
    private val testTopic1: String,

    @ConvertTopic
    @Value("\${test-topic2}")
    private val testTopic2: String,
)

빈 후처리기의 경우 빈이 생성된 이후, 즉 스프링에서 프로퍼티에 대한 placeHolder 작업이 완료된 이후에 처리되기 때문에 testTopic2에는 @Value 로 부터 주입받은 ‘topic2’ 라는 값이 들어가 있게 된다.
이후, field.get(bean) 를 하게 되면 주입된 값인 ‘topic2’ 라는 값이 반환되기 때문에, environment에 대해서도 접근할 필요 없이 바로 해당 값을 original로 판단하여 호스트 이름을 postfix로 붙여주면 된다.

하지만 문제가 발생하였다

그러나, 항상 그렇듯이 이렇게 끝나면 참 좋았겠지만… 위의 로직에는 2가지 정도의 문제가 있었다.

☁︎ 처음 보면 이해하기 어려운 코드 + 리플렉션 사용으로 인한 거부감
☁︎ lazy 대리자에 대해서 제대로 작동되지 않음

먼저, 리플렉션의 경우 성능 저하가 발생할 수는 있으나, 어차피 처음에 빈이 띄워질 때 수정이 되는 것이라서 크게 우려되지 않았다. 그러나, 이것보다는 너무 스프링에 의존적인 코드이기 때문에 처음 보는 사람이 읽기 어려운 코드가 될 수 있겠다는 생각이 들었다.
또한, 사실상 실제 비즈니스 로직은 호스트 이름을 가져와서 프로퍼티에 붙여주기만 하면 되는 것인데, bean이나 ReflectionUtils 같은 것들이 들어가면서 왜인지 모를 거부감이 들 수 있겠다는 생각이 들었다.

사실, 위의 문제보다 그 아래 문제가 더 크게 걸리는 부분이었다. 이전 문제의 경우 팀원들에게 충분한 공유를 하고 사용할 수 있도록 리딩할 예정이었기에 괜찮았지만, 이는 아예 정상적으로 동작하지 않는 문제가 나타났던 것이었다.

사내 프로젝트에서는 다음과 같이 코틀린에서 제공하는 lazy 대리자를 활용하여 기본적인 기능들에 대해 추상화를 진행해두어 사용하고 있었다. 실제 코드를 발췌할 수 없기 때문에, 대략 이런 느낌으로 사용한다고만 생각해두자.

@Component
class ImportantHandler(
    @Value("\${very.important.topic}")
    topic: String,
    factory: Factory,
    ...
): Handler by factory.create(
    topic = topic
    ...
)

inline fun <reified T: ...> Factory.create(
    topic: String
    ...
): ConcurrentHandler<String, T> {
    ...
}

다만, 위의 상황에서 @ConvertTopic을 사용하면 어떻게 될까?

@Component
class ImportantHandler(
    @ConvertTopic
    @Value("\${very.important.topic}")
    topic: String,
    factory: Factory,
    ...
): Handler by factory.create(
    topic = topic
    ...
)

먼저, 위와 같이 사용하기 위해서는 @ConvertTopic의 타겟 타입에 value parameter도 추가해줘야 한다.

@Target(AnnotationTarget.FIELD, AnnotationTarget.VALUE_PARAMETER)
@Retention(AnnotationRetention.RUNTIME)
annotation class ConvertTopic

이러면, factory.create() 로 넘어가는 topic 값이 변화가 될 것이라 생각할 수 있지만 실제로는 그렇게 동작하지 않는다. 이는, 이 함수가 실제로 자바에서 어떻게 동작하는지 확인하면 알 수 있기에 디컴파일을 진행해보자.

public class ImportantHandler implements Handler {
    private final ConcurrentHandler $$delegate_0;

    public ImportantHandler(@ConvertTopic @Value("\${very.important.topic}") @NotNull String topic, ...) {
    Intrinsics.checkNotNullParameter(topic, "topic");
    ...
    String[] var12 = new String[]{topic};
    this.$$delegate_0 = DefaultImpls.create$default(var12, ...)
}

    // 실제 비즈니스 로직을 담은 함수. 대리자에 의해 다음과 같이 수행된다.
    public void run() {
        this.$$delegate_0.run();
    }
}

위임을 위해 ImportantHandler의 필드로 ConcurrentHandler 를 가지고, 생성자 내부에서 delegate 필드가 채워지는 것을 볼 수 있다. 앞서 말했던 것처럼, 빈 후처리기의 초기화 과정은 빈이 생성된 이후 = 즉, 객체가 생성된 이후에 진행된다. delegate 필드가 초기화되는 시점에서 topic 필드는 아직 컨버팅이 되기 이전의 값이기 때문에, 컨버팅이 되기 이전의 값으로 데이터가 초기화가 되면서 정상적으로 동작하지 않게 되는 것이다.

이후 빈 후처리기 과정에서 topic이 초기화가 되더라도, 이미 delegate 필드가 가지고 있는 속성은 초기화가 완료가 된 상태이기 때문에 변화되지 않는다. 그래서 비즈니스 로직으로 인해 run() 메서드가 수행이 되더라도 topic 값이 변하지 않은 속성을 가진 delegate.run()이 수행이 되기 때문에 의도대로 동작하지 않는 것이다.

그래서, 위의 문제를 해결하기 위해 처음에는 lazy 대리자를 사용하지 않고 다음과 같이 직접 위임을 하는 것은 어떨지 생각해보았다.

@Component
class ImportantHandler(
    @ConvertTopic
    @Value("\${very.important.topic}")
    topic: String,
    factory: Factory,
    ...
): Handler {

    private lateinit var delegate: ConcurrentHandler

    @PostConsturct
    fun init() {
        delegate = factory.create(topic, ..)
    }

    override fun run() {
        delegate.run()
    }

    // ...
}

이때, @PostConsturct 를 통해서 빈 후처리기가 동작한 이후에 delegate 필드가 초기화가 될 수 있도록 만들었다. 이러면 컨버팅이 된 topic 값을 통해 delegate 객체가 생성되기 때문에 의도대로 잘 동작은 하였다.

그러나, override를 통해 모든 메서드들을 다시 재정의하는 것도 너무 번거롭고, 코틀린 언어의 장점을 하나도 사용하지 못하는 코드인 것 같았다. 코드의 길이 역시 이전보다 훨씬 길어지기 때문에 위와 같은 방식을 사용하는 것은 팀원들의 동의를 얻는 것도 어려울 것 같다는 생각이 들었다.

SpEL 활용하기

그러던 중, 공식 문서에서 SpEL 이라는 친구를 발견하게 되었다. SpEL은 ‘런타임’에 객체 그래프를 쿼리하고 조작할 수 있는 강력한 표현식 언어로, @Value 어노테이션을 활용하여 런타임에 조작이 가능하다는 것이었다!
실제로 공식 문서를 보면, 다음과 같이 함께 사용할 수 있는 예제를 보여주고 있다.

Using @Value :: Spring Framework

A default lenient embedded value resolver is provided by Spring. It will try to resolve the property value and if it cannot be resolved, the property name (for example ${catalog.name}) will be injected as the value. If you want to maintain strict control o

docs.spring.io

@Component
class MovieRecommender(
    @Value("#{systemProperties['user.catalog'] + 'Catalog' }") private val catalog: String
)

위의 예제처럼 작성하고 싶은 표현식을 #{} 내부에 작성하게 되면, 내부적으로 컨버팅을 진행해준다.

적용 방법은 완전 쉬우니, 한 번 이전 코드에 적용을 해보자.
기존에 작성하였던 콜백 로직을 조금 더 적합한 이름의 클래스로 추출을 진행해주었다. 또한, 이제는 이 클래스 자체를 빈으로 등록하면 되기 때문에 다른 빈에 대해 주입도 받을 수 있어서 더 편리하게 사용이 가능해졌다.

@Component
class TopicConverter(
    private val environment: Environment,
    private val profile: String,
) {

    fun execute(property: String): String {
        // ... 기존의 로직 작성
        return original.plus(".$hostName")
    }
}

함수의 인자로는 변경을 원하는 프로퍼티의 키를, 함수의 반환 값으로는 컨버팅된 값을 반환하도록 만들어주었다.
그리고, 실제로 사용할 때는 다음과 같이 사용해주면 된다.

@Value("#{topicConverter.execute('very.important.topic')}")
topic: String,

더 이상 별도의 어노테이션도 필요하지 않고, 기존 @Value 내부에서 함수를 호출하는 것처럼 만들면 되기 때문에 사용성 역시 훨씬 편리해졌다! 또한, intellij 기능 덕분인지, 하이라이팅도 해주기 때문에 코드를 따라가기도 쉬워져서 더 마음에 들었다.

그래서 최종적으로는 위와 같이 기존 코드에 모두 적용을 완료하였으며, 덕분에 개인 branch 작업물에 대해 개발자마다 트래픽을 제어할 수 있도록 쉽게 핸들링이 가능해졌다.

마무리

꽤나 여러 가지로 삽질을 했었지만, 덕분에 공식 문서를 꼭 봐야겠다는 생각이 들었던 시간이었다. (사실, 처음에 @Value 어노테이션의 설명에서도 다음과 같이 나와있었기 때문에 제대로 읽지 않은 내 문제도 컸었다... ㅎㅎ

A common use case is to inject values using #{systemProperties. myProp} style SpEL (Spring Expression Language) expressions. Alternatively, values may be injected using ${my. app. myProp} style property placeholders.

처음에는 내가 직면한 문제를 spEL이랑 엮어봐야겠다는 생각조차 못했었다가 나중에 공식 문서 스터디를 진행하면서 spEL에 대한 정보를 알게 되고 그때 눈에 띄었던 것 같다. 사람들이 이래서 공식 문서를 읽으라고 하는 건가... 하면서 많이 배웠던 시간이었다.

사실 정말 이 방법이 올바른 방법이 되는지는 잘 모르겠다. 보통의 사람들이라면 테스트 코드로 잘 검증할 수 있는게 맞지 않나요? 라고 충분히 반박할 수도 있다고 생각이 든다.

아직까지는 E2E 테스트를 완전히 믿고 신뢰할 수 있을 만큼 내가 정교하게 작성하지 못한 탓도 큰 것 같다. 실제로 메인 비즈니스 로직에 대한 통합 테스트 코드는 작성이 되어 있으나, 해당 테스트 코드를 돌리고 항상 개발 앱 환경에서 다시 한 번 테스트를 돌려보는 내 모습을 바라보면서 아직은 많이 부족하다는 생각이 들었다. 개발에는 정답이 없는 것이니까... 우선은 현 자리에서 최대한 열심히 노력해봐야겠다. ㅎㅎ

아무튼, 오랜만에 글을 쓰다 보니 길어진 것 같다.
쓰고 싶은 글은 많은데 게으름으로 인해 글을 많이 못 쓰고 있는 것 같다… 종종 생각날 때 조금씩 써야겠다… 끝!

[Spring] 통합 테스트 환경에서 로직의 일부를 stubbing 하기

dolmeng2 — Sun, 16 Jun 2024 19:27:50 +0900

들어가기 전

통합 테스트를 하다 보면, 실제 빈 중에 일부만 stubbing을 하고 싶은 상황이 생긴다.
예를 들어, 외부 API를 통신하거나 외부 시스템을 활용하게 되면 테스트에서 그대로 활용하기 어려운데, 해당 부분에 대해서만 우리가 원하는 시나리오를 제공하여 우리 애플리케이션이 잘 동작하는지 확인하고 싶을 수 있다. 하지만, 보통 Spring Context에서는 동일한 이름을 가진 빈을 그대로 등록하게 되면 오류가 발생하기 때문에, 몇 가지 특별한 조치를 해주어야 하는데 한 번 살펴보자.

☁︎ 테스트 시나리오

- 사용자가 상품을 구매하게 되면, 외부 API를 호출하여 재고가 존재하는지 확인한다.
- 만약 재고가 존재하면 외부 API는 ‘SUCCESS’라는 응답을, 재고가 존재하지 않으면 ‘FAIL’이라는 응답을 반환한다.
- 우리는 여기에서 ‘외부 API가 SUCCESS 혹은 FAIL’이라는 응답을 반환하는 부분에 대해서 stubbing을 진행할 것이다.

위의 시나리오를 만들기 위한 간단한 코드를 작성해보자.
본 글에서는 아키텍처나 세부 코드에 대한 구현은 중요하지 않기 때문에 가장 기본적인 코드로 작성하였다.

✔️ 기본 코드

@RestController
class OrderController(
    private val orderService: OrderService,
) {

    @PostMapping("/order")
    fun order(
        @RequestBody request: OrderRequest
    ) {
        orderService.order(request.productId)
    }
}

data class OrderRequest(
    val productId: Long,
)

@Service
class OrderService(
    private val externalStockCheckApi: ExternalStockCheckApi
) {

    fun order(productId: Long) {
        val result = externalStockCheckApi.check(productId)
        if (result == StockStatus.FAIL) {
            throw OutOfStockException("재고가 없습니다.")
        }
        otherLogic()
    }

    private fun otherLogic() {
        // do something...
    }
}

class OutOfStockException(
    override val message: String
) : RuntimeException(message) {
}

여기에서 otherLogic의 경우 매우 복잡한 비즈니스 로직을 담는다고 가정한다.

실패의 케이스에 대해서도 복잡한 경우가 포함되지만, 여기에서는 간단하게 예외만 발생시키도록 제어를 해두었다.

@Component
class ExternalStockCheckApi {
    fun check(productId: Long): StockStatus {
        return callExternalApi(productId)
    }

    private fun callExternalApi(productId: Long): StockStatus {
        // call external api...
        if (Random().nextInt() % 2 == 0) {
            return StockStatus.SUCCESS
        }
        return StockStatus.FAIL
    }
}

enum class StockStatus {
    SUCCESS,
    FAIL
}

ExternalStockCheckApi 의 경우, 실제로는 외부 API와 통신하는 구간이다.

현재 우리의 코드에서는 해당 부분은 중요하지 않기 때문에 제외하고, 그냥 랜덤한 값에 따라서 성공과 실패에 대해서 반환하도록 수정하였다.

우리는 위와 같은 코드가 있을 때, `ExternalStockCheckApi`의 결과를 제어하여 우리의 애플리케이션이 의도하는대로 잘 동작하는지를 확인해볼 예정이다. 또한, 단위 테스트가 아닌 통합 테스트를 활용할 예정이다. 물론, 테스트의 방법에는 여러 가지가 있고, 단위 테스트를 활용해서 우리의 애플리케이션을 검증하는 것도 가능하다.

그러나, 실제로 복잡한 비즈니스를 가지고 있는 경우에는 상당히 많은 빈들이 서로 협력하여 동작하게 된다. 모든 빈에 대해서 단위 테스트를 작성하여 각각의 컴포넌트들에 대한 정상적인 동작을 판단할 수도 있지만, 해당 컴포넌트들의 단위 테스트가 작성되지 않은 상황이거나 각 컴포넌트들간의 정상적인 협력 관계가 잘 동작하고 있는지 판단하고 싶을 때는 통합 테스트가 좋은 방법이 될 수 있다.

그렇다면, ‘테스트 환경에서도 실제 외부 API를 호출하면 되지 않는가?’ 라고 생각할 수 있다. 그러나, 만약 외부 API가 일시적으로 장애가 발생했어서 늘 통과하던 테스트가 갑자기 통과하지 않는다면 어떻게 될까? 테스트의 경우 늘 일관적인 시나리오로 동작해야 하기 때문에 이에 대해 위배하게 된다. (FIRST 원칙, 물론 이는 단위 테스트에 대한 원칙이지만 그래도 살짝 인용하자면 그렇다.)

또한, 사업적인 관점으로 봤을 때 외부 API에 대한 호출 비용을 받는 곳이라면? 테스트 할 때마다 비용 지출이 발생할 수 있기 때문에 어느 정도의 stubbing은 필요한 상황이다. (실제로 사내에서 동일한 케이스가 있어서, 테스트 환경에서는 아예 dummy 값을 내려주도록 처리하는 부분도 존재한다.)

아무튼, 위의 시나리오를 판단하기 위한 간단한 테스트 코드를 작성해보자. RestAssured를 활용하여 작성해주었다.

테스트 설정 방법에 대해서는 다음 포스팅에서 조금 더 다루어보고자 한다.

@SpringBootTest(webEnvironment = SpringBootTest.WebEnvironment.RANDOM_PORT)
@TestInstance(TestInstance.Lifecycle.PER_CLASS)
@TestConstructor(autowireMode = TestConstructor.AutowireMode.ALL)
class OrderControllerTest() {

    @LocalServerPort
    private var port: Int = 0

    @BeforeAll
    fun setUp() {
        RestAssured.port = port
    }

    @Test
    fun `재고가 존재하는 경우에는 정상 응답을 반환한다`() {
        val result = callOrderApi(1L)
        assertThat(result.statusCode())
            .isEqualTo(HttpStatus.OK.value())
    }

    @Test
    fun `재고가 존재하지 않는 경우 오류 응답을 반환한다`() {
        val result = callOrderApi(2L)
        assertThat(result.statusCode())
            .isEqualTo(HttpStatus.INTERNAL_SERVER_ERROR.value())
    }

    private fun callOrderApi(
        productId: Long
    ): ExtractableResponse<Response> {
        return RestAssured.given()
            .given().log().all()
            .contentType("application/json")
            .body(
                mapOf("productId" to productId)
            )
            .`when`()
            .post("/order")
            .then().log().all().extract()
    }
}

우리가 원하는 시나리오는 위와 같은 2가지 상황을 테스트 할 수 있다.
- 재고가 존재하는 경우 아무 오류도 발생하지 않음
- 재고가 존재하지 않는 경우 예외가 발생함

당연히 현재의 테스트 코드는 깨지는 것이 맞다.

@MockBean을 활용하여 재정의하기

☁︎ @MockBean이 무엇일까?

먼저, 첫 번째 방법으로는 @MockBean을 활용하여 `ExternalStockCheckApi` 에 대해 재정의를 할 수 있다.

@MockBean의 경우 Spring 1.4에서 추가된 테스트 서포팅용 어노테이션으로, 스프링의 ApplicationContext에 mocking 된 객체를 추가하는데 사용하는 어노테이션이다. 빈의 타입이나 이름으로 등록이 가능하며, 기존의 컨텍스트에서 일치하는 빈에 대해서 mock 빈으로 대체하게 만들어준다. 만약 기존에 빈이 존재하지 않는다면 새로운 빈으로 추가하여 등록해준다.

Junit4를 사용한다면 `@RunWith(SpringRunner.class)`와 함께, Junit5를 사용한다면 `@ExtendWith(SpringExtension.class)` 와 함께 사용할 수 있다. 나는 @SpringBootTest 어노테이션을 사용할 예정이기 때문에 따로 붙여주지는 않았다.

참고로, 이러한 @MockBean의 경우 `MockitoTestExecutionListener` 에 의해서 처리되고 있다.

`MockitoTestExecutionListener` 의 경우 `AbstractTestExecutionListener` 을 상속받았으며, 테스트 컨텍스트를 활용하여 테스트 코드 수행 시 어떤 전처리 / 후처리를 진행할지 정해줄 수 있다.

public class MockitoTestExecutionListener extends AbstractTestExecutionListener {

    @Override
    public void prepareTestInstance(TestContext testContext) throws Exception {
        closeMocks(testContext);
        initMocks(testContext);
        injectFields(testContext);
    }
}

private void initMocks(TestContext testContext) {
    if (hasMockitoAnnotations(testContext)) {
        testContext.setAttribute(MOCKS_ATTRIBUTE_NAME, MockitoAnnotations.openMocks(testContext.getTestInstance()));
    }
}

private void injectFields(TestContext testContext) {
    postProcessFields(testContext, (mockitoField, postProcessor) -> postProcessor.inject(mockitoField.field,
    mockitoField.target, mockitoField.definition));
}

private void postProcessFields(TestContext testContext, BiConsumer<MockitoField, MockitoPostProcessor> consumer) {
    DefinitionsParser parser = new DefinitionsParser();
    parser.parse(testContext.getTestClass());

    if (!parser.getDefinitions().isEmpty()) {
        MockitoPostProcessor postProcessor = testContext.getApplicationContext()
            .getBean(MockitoPostProcessor.class);

        for (Definition definition : parser.getDefinitions()) {
            Field field = parser.getField(definition);
            if (field != null) {
                consumer.accept(new MockitoField(field, testContext.getTestInstance(), definition), postProcessor);
            }
        }
    }
}

testContext를 활용하면 테스트 코드에 선언된 어노테이션 정보를 읽어올 수 있기 때문에, mockito 기반 어노테이션들을 찾아서 mock field로 주입해주는 것을 확인할 수 있다.

☁︎ 실제로 적용해보기

@SpringBootTest(webEnvironment = SpringBootTest.WebEnvironment.RANDOM_PORT)
@TestInstance(TestInstance.Lifecycle.PER_CLASS)
@TestConstructor(autowireMode = TestConstructor.AutowireMode.ALL)
class OrderControllerTest(
    @MockBean
    private val externalStockCheckApi: ExternalStockCheckApi
) {

    @Test
    fun `재고가 존재하는 경우에는 정상 응답을 반환한다`() {
        Mockito.`when`(
            externalStockCheckApi.check(anyLong())
        ).thenReturn(StockStatus.SUCCESS)

        val result = callOrderApi(1L)
        assertThat(result.statusCode())
            .isEqualTo(HttpStatus.OK.value())
    }

    @Test
    fun `재고가 존재하지 않는 경우 오류 응답을 반환한다`() {
        Mockito.`when`(
            externalStockCheckApi.check(anyLong())
        ).thenReturn(StockStatus.FAIL)

        val result = callOrderApi(2L)
        assertThat(result.statusCode())
            .isEqualTo(HttpStatus.INTERNAL_SERVER_ERROR.value())
    }
}

Mockito.when().thenReturn()을 사용하면 mockBean으로 등록된 mock 객체에 대해서 쉽게 stubbing을 진행할 수 있다.

when절에는 우리가 스터빙을 진행하고 싶은 메서드를 입력하고, then 절에는 해당 상황에서 어떤 값을 반환하면 좋을지 작성해주면 된다. thenReturn 외에도 thenThrow, thenAnswer 등으로 더 유연한 테스트 코드를 작성할 수 있다.

☁︎ 단점은 없을까?

아쉽게도, @MockBean을 활용하게 되면 스프링 컨텍스트를 재사용할 수 없는 문제가 발생한다.

우선, @MockBean을 사용하게 되면 테스트 클래스를 수행할 때마다 Spring Context에 대해 refresh를 진행하는데, 이는 위에 첨부해둔 `postProcessFields()` 함수의 다음과 같은 부분을 살펴보면 알 수 있다.

// postProcessFields 
if (!parser.getDefinitions().isEmpty()) {
    MockitoPostProcessor postProcessor = testContext.getApplicationContext()
        .getBean(MockitoPostProcessor.class);
}

// DefaultTestContext.getApplicationContext
@Override
public ApplicationContext getApplicationContext() {
    ApplicationContext context = this.cacheAwareContextLoaderDelegate.loadContext(this.mergedConfig);
    ...
}

// DefaultCacheAwareContextLoaderDelegate.loadContext
@Override
public ApplicationContext loadContext(MergedContextConfiguration mergedConfig) {
    ...
    synchronized (this.contextCache) {
        ApplicationContext context = this.contextCache.get(mergedConfig);
        ...
        context = loadContextInternal(mergedConfig);
        ...
    }


    protected ApplicationContext loadContextInternal(MergedContextConfiguration mergedConfig) throws Exception {
        ContextLoader contextLoader = getContextLoader(mergedConfig);
        if (contextLoader instanceof SmartContextLoader smartContextLoader) {
            return smartContextLoader.loadContext(mergedConfig);
        }
        ...
    }

    // SpringBootContextLoader.loadContext
    private ApplicationContext loadContext(MergedContextConfiguration mergedConfig, Mode mode,
        ApplicationContextInitializer<ConfigurableApplicationContext> initializer) throws Exception {
        ...
        return hook.run(() -> application.run(args));
    }

    // SpringApplication.run
    public ConfigurableApplicationContext run(String... args) {
    refreshContext(context);
}

여기에서 테스트 컨텍스트 내에 있는 applicationContext를 꺼내오는 것을 알 수 있는데, 내부로 타고 들어가게 되면 context에 대해 refresh를 하는 것을 볼 수 있다.
코드의 중간 부분을 보면 스프링에서는 최대한 캐시된 테스트 컨텍스트를 사용하려고 하지만 (contextCache 같은 필드들이 존재하는 걸 볼 수 있다), @MockBean을 사용하게 되면 해당 빈 뿐만 아니라 해당 빈을 사용하는 다른 친구들도 모두 교체해줘야 하기 때문에 캐시를 하지 않고 아예 refresh를 해주는 것을 볼 수 있다.

class A(val b: B) 와 같은 코드가 있을 때, B가 mockBean이라면 자연스럽게 B를 의존하고 있는 A 역시 mocking된 B를 사용할 수 있도록 교체 작업이 필요해진다. 만약 빈끼리 더 복잡한 의존 관계를 가지고 있다면 자연스럽게 더 많은 빈들에 대해서 교체하는 작업이 필요해질 것이다.

참고로, 기본적으로 스프링의 context caching의 경우 다음과 같은 상황에 대해서 발생한다.
- 동일한 bean의 조합을 사용했을 때
- 이전의 테스트에서 applicationContext가 오염되지 않은 경우
- @DirtyContext 를 활용하지 않는 경우

@Profile 설정을 통해서 테스트용 빈을 분리하기

만약, 위와 같은 spring context refresh가 싫다면, 테스트에서 사용할 프로파일을 지정해주고 해당 프로파일에서는 다른 동작을 하도록 만들어 줄 수 있다. 하지만, 스프링에서는 기본적으로 동일한 이름을 가진 빈을 2개 띄울 수 없다. 이를 위해 `ExternalStockCheckApi`를 인터페이스로 분리해주는 작업을 진행해주자. 인터페이스의 경우 구체적인 행위가 들어나지 않도록, 재고를 확인하는 용도의 기능 정도만 나타내 줄 수 있도록 만들었다.

interface CheckStockPort {
    fun check(productId: Long): StockStatus
}

그리고, @Profile 어노테이션을 활용하여 profile 별로 다른 코드가 동작할 수 있도록 만들어주자.

@Component
@Profile("!test")
class ExternalStockCheckApi: CheckStockPort {
    override fun check(productId: Long): StockStatus {
        return callExternalApi(productId)
    }
}

@Component
@Profile("test")
class TestStockCheckApi: CheckStockPort {
    override fun check(productId: Long): StockStatus {
        if (productId == 1L) {
            return StockStatus.SUCCESS
        }
        return StockStatus.FAIL
    }
}

기존의 ExternalStockCheckApi 에 대해서 CheckStockPort 을 오버라이드 하도록 만들고, 특정 Test 프로파일에 대해서는 TestStockCheckApi 가 동작하도록 만들었다.

그리고, 우리의 테스트 시나리오에 맞춰 productId 별로 다른 결과가 나타날 수 있도록 만들었다.

기존에 ExternalStockApi를 의존하던 서비스 코드 역시 인터페이스를 의존하도록 변경해주자.

@Service
class OrderService(
    private val checkStockPort: CheckStockPort,
) {

    fun order(productId: Long) {
        val result = checkStockPort.check(productId)
        ...
    }
}

그리고, 다시 테스트 코드로 돌아가서 ‘test’라는 profile을 가질 수 있도록 @ActiveProfiles 어노테이션을 추가해주도록 하자.

@SpringBootTest(webEnvironment = SpringBootTest.WebEnvironment.RANDOM_PORT)
@TestInstance(TestInstance.Lifecycle.PER_CLASS)
@TestConstructor(autowireMode = TestConstructor.AutowireMode.ALL)
@ActiveProfiles("test")
class OrderControllerTestV2 {

    @Test
    fun `재고가 존재하는 경우에는 정상 응답을 반환한다`() {
        val result = callOrderApi(1L)
        assertThat(result.statusCode())
            .isEqualTo(HttpStatus.OK.value())
    }

    @Test
    fun `재고가 존재하지 않는 경우 오류 응답을 반환한다`() {
        val result = callOrderApi(2L)
        assertThat(result.statusCode())
            .isEqualTo(HttpStatus.INTERNAL_SERVER_ERROR.value())
    }
}

이러면 @MockBean을 사용하지 않더라도 깔끔하게 테스트 코드를 작성할 수 있으며, 테스트 시나리오에 따라서 테스트용 빈이 어떤 행위를 수행할지 설정해준다면 동일한 컨텍스트를 가지도록 재사용도 할 수 있기 때문에 테스트 성능 역시 올릴 수 있다.

@TestConfiguration 활용해주기

위와 같이 Profile 어노테이션을 활용하는 방법도 있지만, @TestConfiguration 을 활용해서도 다른 빈을 사용하도록 제어할 수 있게 된다. 만약, 운영 코드와 테스트 코드를 완전히 분리하고 싶다면 테스트용 빈을 등록해주도록 하자.

기존의 코드의 경우 운영 코드에서 컴포넌트 스캔으로 인해서 `TestStockCheckApi` 가 빈으로 등록이 되었었는데, 테스트 컨텍스트 내에서만 빈으로 등록하도록 만들어보자. 먼저, @TestConfiguration을 활용하여 테스트용 빈을 선언해주자.

@TestConfiguration
class TestConfig {

    @Bean
    fun checkStockPort() : CheckStockPort {
        return TestStockCheckApi()
    }
}

class TestStockCheckApi: CheckStockPort {
    override fun check(productId: Long): StockStatus {
        if (productId == 1L) {
            return StockStatus.SUCCESS
        }
        return StockStatus.FAIL
    }
}

만약 동일한 타입의 빈을 등록해줄 일이 있다면 @Primary를 활용하여 적절하게 조절하자.

그리고, 테스트 코드에서 @Import를 통해서 (혹은 @ContextConfiguration을 활용해도 된다) 해당 Configuration 에 대해 로드를 해준다.

@SpringBootTest(webEnvironment = SpringBootTest.WebEnvironment.RANDOM_PORT)
@TestInstance(TestInstance.Lifecycle.PER_CLASS)
@TestConstructor(autowireMode = TestConstructor.AutowireMode.ALL)
//@ContextConfiguration(classes = [TestConfig::class])
@Import(TestConfig::class)
class OrderControllerTestV3 {

    @Test
    fun `재고가 존재하는 경우에는 정상 응답을 반환한다`() {
        val result = callOrderApi(1L)
        assertThat(result.statusCode())
            .isEqualTo(HttpStatus.OK.value())
    }

    @Test
    fun `재고가 존재하지 않는 경우 오류 응답을 반환한다`() {
        val result = callOrderApi(2L)
        assertThat(result.statusCode())
            .isEqualTo(HttpStatus.INTERNAL_SERVER_ERROR.value())
    }
}

이렇게 하면 @Profile 어노테이션과 동일하게 테스트용 checkStockPort 을 사용할 수 있게 된다.

☁︎ @ConditionalOnProperty 활용하기

또한, @TestConfiguration과 @ConditionalOnProperty 2가지의 어노테이션을 조합해서 다음과 같이 코드를 구성해볼 수도 있다. 대신 조금 더 복잡도가 높아지기 때문에 그냥 이런 방법도 있다는 정도만 넘어가도 될 것 같다.
먼저, 운영 코드에서 다음과 같이 `@ConditionalOnProperty` 를 활용하여 특정 프로퍼티가 존재할 때 해당 빈을 사용할 수 있도록 수정해주자.

@Component
@ConditionalOnProperty(name = ["check-stock.test"], havingValue = "false")
class ExternalStockCheckApi: CheckStockPort {
    override fun check(productId: Long): StockStatus {
        return callExternalApi(productId)
    }
}

여기에서는 `check-stock.test` 라는 프로퍼티가 false인 경우에 운영 코드가 동작할 수 있도록 설정해주었다.

그리고, 테스트 코드를 조금 수정해주자. 우선, 프로퍼티 값을 사용하는 김에 해당 프로퍼티 값에 따라서 success를 응답하는 외부 API와 fail을 응답하는 외부 API 빈으로 분리하고자 한다. 이를 위해 Conditional 인터페이스를 활용해줄 수 있다.

class CheckStockSuccessCondition : Condition {
    override fun matches(context: ConditionContext, metadata: AnnotatedTypeMetadata): Boolean {
        val environment = context.environment
        val checkStockTest = environment.getProperty("check-stock.test") == "true"
        val checkStockResultSuccess = environment.getProperty("check-stock.result-success") == "true"
        return checkStockTest && checkStockResultSuccess
    }
}

class CheckStockFailCondition : Condition {
    override fun matches(context: ConditionContext, metadata: AnnotatedTypeMetadata): Boolean {
        val environment = context.environment
        val checkStockTest = environment.getProperty("check-stock.test") == "true"
        val checkStockResultFailure = environment.getProperty("check-stock.result-success") == "false"
        return checkStockTest && checkStockResultFailure
    }
}

`check-stock.test` 프로퍼티가 true이면서, `check-stock.result-success` 프로퍼티가 true인지 false인지에 따라서 Condition을 검증하는 로직이다. 그리고, 다음과 같이 빈을 등록해주자.

@TestConfiguration
class TestConfigV2 {

    @Bean(name = ["checkStockPort"])
    @Conditional(CheckStockSuccessCondition::class)
    fun checkStockPortReturnSuccess(
        environment: Environment
    ): CheckStockPort {
        return object : CheckStockPort {
            override fun check(productId: Long): StockStatus {
                return StockStatus.SUCCESS
            }
        }
    }

    @Bean(name = ["checkStockPort"])
    @Conditional(CheckStockFailCondition::class)
    fun checkStockPortReturnFail(
        environment: Environment
    ): CheckStockPort {
        return object : CheckStockPort {
            override fun check(productId: Long): StockStatus {
                return StockStatus.FAIL
            }
        }
    }
}

둘 다 ‘checkStockPort’ 라는 이름으로 빈 등록이 될 수 있게 네임 지정을 해주고, 각각의 조건이 true일 때 해당 빈을 활용할 수 있도록 @Conditional 어노테이션을 활용해주었다.

마지막으로, 테스트에서 해당 빈 정보를 활용할 수 있도록 import 하고, 프로퍼티를 주입해주자. 프로퍼티 주입을 위해서 여러 방법이 있겠지만, 나는 @SpringBootTest가 제공하는 프로퍼티 속성을 활용하여 주입해주었다.

다만, 이러다 보니까 실패와 성공 케이스에 대해 각각 테스트 클래스를 분리하였다. 이런 방법도 있을 뿐이지, 실제로 활용하기에는 효용이 좋을지는 잘 모르겠다. (정말 이런 방법이 있기만 하다는 것 정도만 인지하자!)

@SpringBootTest(
    webEnvironment = SpringBootTest.WebEnvironment.RANDOM_PORT,
    properties = ["check-stock.test=true", "check-stock.result-success=true"]
)
@TestInstance(TestInstance.Lifecycle.PER_CLASS)
@TestConstructor(autowireMode = TestConstructor.AutowireMode.ALL)
@Import(TestConfigV2::class)
class OrderControllerTestV4_success {

    @Test
    fun `재고가 존재하는 경우에는 정상 응답을 반환한다`() {
        val result = callOrderApi(1L)
        assertThat(result.statusCode())
            .isEqualTo(HttpStatus.OK.value())
    }
}

@SpringBootTest(
    webEnvironment = SpringBootTest.WebEnvironment.RANDOM_PORT,
    properties = ["check-stock.test=true", "check-stock.result-success=false"]
)
@TestInstance(TestInstance.Lifecycle.PER_CLASS)
@TestConstructor(autowireMode = TestConstructor.AutowireMode.ALL)
@Import(TestConfigV2::class)
class OrderControllerTestV4_fail {
    ...
}

mock 객체를 활용하기

다음으로, 만약 테스트 상황에 따라 여러 시나리오를 반환하고 싶을 때 사용할 수 있는 방법이 있다.

이때는 테스트용 빈을 등록할 때 테스트 클래스가 아닌, mock 객체를 반환해주면 된다.

@TestConfiguration
class TestConfigV3 {

    @Bean
    fun checkStockPort() : CheckStockPort {
        return Mockito.mock(CheckStockPort::class.java)
    }
}

만약 kotest를 활용한다면 mockk<CheckStockPort> 를 활용하여 반환해줄 수 있다.
그리고, 테스트 코드에서 checkStockPort를 주입해주자. 이러면 위에서 선언한 mock 객체가 반환된다.

@SpringBootTest(
    webEnvironment = SpringBootTest.WebEnvironment.RANDOM_PORT,
)
@TestInstance(TestInstance.Lifecycle.PER_CLASS)
@TestConstructor(autowireMode = TestConstructor.AutowireMode.ALL)
@Import(TestConfigV3::class)
class OrderControllerTestV5(
    private val checkStockPort: CheckStockPort,
) {

}

이 상황에서 그냥 테스트를 돌리면 어떻게 될까?

mocking된 객체에 대해서 하는 일을 지정해주지 않았기 때문에 결과로 null을 반환하게 되며, 당연하게도 테스트도 실패한다.
이를 위해, 각 테스트 시나리오에 맞춰 어떤 행위를 할지 지정해주도록 하자.

@Test
fun `재고가 존재하는 경우에는 정상 응답을 반환한다`() {
    Mockito.`when`(
        checkStockPort.check(Mockito.anyLong())
    ).thenReturn(StockStatus.SUCCESS)

    val result = callOrderApi(1L)
    assertThat(result.statusCode())
        .isEqualTo(HttpStatus.OK.value())
}

@Test
fun `재고가 존재하지 않는 경우 오류 응답을 반환한다`() {
    Mockito.`when`(
        checkStockPort.check(Mockito.anyLong())
    ).thenReturn(StockStatus.FAIL)

    val result = callOrderApi(2L)
    assertThat(result.statusCode())
        .isEqualTo(HttpStatus.INTERNAL_SERVER_ERROR.value())
}

Mockito의 When, ThenReturn 절을 활용하면 어떤 행위를 할지 지정해줄 수 있으며, 만약 kotest를 사용 중이라면 every - returns를 사용하여 해주면 된다.

마무리

요즘 회사에서 통합 테스트를 자주 짜려고 노력 중인데, 한 번 구축하고 나니까 다음 번에 테스트를 짤 때 더 금방 짤 수 있는 것 같다.
개인적으로는 위 4가지 방법 중에서 2번과 4번을 많이 쓰고 있다.
2번은 슬랙 메시지나 금원 지급, 외부 API를 호출해야 하는 상황 등등, 테스트에서 반드시 호출이 되지 않을 필요가 있거나 고정된 특정한 응답이 필요한 경우 사용하고, 4번은 외부 API이지만 해당 API가 어떤 응답을 내려주는지에 따라서 핵심 비즈니스 로직이 달라지는 경우 시나리오별로 정의하기 위해서 사용하고 있다.

요즘 테스트 속도에 대해서도 고민이 많아서, 아예 테스트용 빈을 관리하는 @TestConfiguration 클래스를 생성한 다음에, 모든 클래스에서 재사용할 수 있도록 만들어서 속도를 개선해볼까도 고민 중이다. 또한, 개인적으로는 kotest를 선호하는 편이라서 mockk와 함께 조합해서 많이 사용하고 있다.

오랜만에 블로그 글을 작성해서 어색한데, 얼른 다른 글도 작성할 수 있도록 노력해야겠다... 끝!

[MySQL] Replication을 활용하여 Master-Slave DB 분리하기 (1)

dolmeng2 — Wed, 15 May 2024 18:29:54 +0900

들어가기 전

회사 들어가고 블로그가 너무 뜸해진 것 같아서, 이전에 쓰려다가 못 쓴 글을 작성하고자 한다 (무한의 임시 저장...)

사내에서 Replication을 활용하고 있다는 건 알고 있는데, 구체적으로 어떤 식으로 동작하는지는 제대로 이해하지 못하고 있었던 것 같아서 간단 하게 MySQL을 활용하여 Replication이 어떤 식으로 동작하는지 구축해보았다.

구체적인 부분은 더 공부하면 좋겠지만, 학습 용도로 작성하는 글!

복제란 무엇일까?

복제는 기본적으로 master 노드에서 데이터가 변경되었을 때 slave 노드에도 변경된 내용을 적용시키는 것을 의미하며, MySQL에서는 기본적으로 비동기 복제 방식을 활용하여 둘 사이의 데이터 정합성을 맞추고 있다.

여기서 말하는 비동기 복제 방식이 무엇일까? 동작 방식을 흐름으로만 간단하게 이해하고 넘어가도록 하자.

0. 클라이언트가 커밋을 진행한다. (데이터베이스에 데이터 저장 요청)
1. Connection Thread는 스토리지 엔진에게 해당 트랜잭션에 대한 Prepare를 진행한다.
- 해당 단계는 Commit 을 실제로 진행하는 단계가 아닌, ‘준비’를 하는 단계이다. (2PC, 2 Phase Commit)
- 이 시점에 (InnoDB의 경우) Redo Log를 기록하게 된다.
- 만약 이 단계에서 서버가 다운되면, 복구할 때 해당 트랜잭션은 롤백된다.

2. Commit 을 진행하기 전, 바이너리 로그에 변경사항을 기록한다.
3. 스토리지 엔진은 변경 사항에 대해 커밋을 완료한다.
- 이 시점까지 정상적으로 완료되면, 트랜잭션은 커밋이 완료되어 바이너리 로그와 (InnoDB라면) 리두 로그까지 존재하게 된다.
4-5. Master Thread는 비동기적으로 바이너리 로그를 읽어서, Slave로 전송한다.
6. Slave의 I/O 스레드는 수신한 변경 데이터를 릴레이 로그에 기록한다.
7-8. Slave의 SQL 스레드는 릴레이 로그에 기록된 데이터를 읽어서 스토리지 엔진에 기록한다.

실습 준비 - 마스터 서버 구축하기

간단하게 실습을 진행하기 위해, docker를 활용하여 mySQL 서버를 띄워주었다.

가장 먼저 master 서버를 띄워주게 될 건데, mySQL의 설정 파일을 수정할 필요가 있기 때문에 my.cnf 라는 파일을 생성하여 다음과 같이 작성해두자.

[mysqld]
log-bin=mysql-bin    
server-id=1          
binlog-do-db=practice  
authentication_policy=mysql_native_password

- [mysqld]: MySQL 서버의 프로퍼티를 지정하기 위한 시작 prefix 값
- log-bin : 바이너리 로깅을 활성화하고, 로그 파일의 이름을 지정하는 것. 테이블에 대한 모든 변경사항을 로그 파일로 기록하게 된다.

기본적으로 mySQL 에서 replication을 진행할 때 바이너리 로그 파일에 대한 내용을 기준으로 복제를 진행하기 때문에 로깅을 활성화하게 된다.
- server-id: MySQL 서버에 대한 고유 아이디 값으로, 추후 구축할 slave 용 서버와 꼭 다르게 설정을 해줘야 하는 값이다. 복제된 프로세스들 사이에서 각 mySQL 서버 프로세스를 구분하는데 사용하는 값이다.
- binlog-do-db: 바이너리 로깅을 특정한 데이터베이스에서만 사용할 수 있도록 지정하는 것이다. 여기에서는 추후 만들 ‘practice’ 라는 데이터베이스에 대해서만 로깅을 허용하도록 지정해주었다.
- authentication_policy : MySQL 8.0부터는 SHA-256 Hashing을 구현하기 위하여 2가지의 플러그인을 제공하고 있는데, 기본적으로 caching_sha2_password 라는 캐싱을 활용한 플러그인을 활용하고 있다. 이때 이를 사용하기 위해서 SSL 보안 연결이나 RSA 보안을 적용해야 하는데, 꽤나 번거롭기 때문에 구버전 플러그인인 mysql_native_password을 사용하도록 설정하는 것이다. (이 부분을 빼먹으면 나중에 통신이 안 된다…)

이러한 파일을 생성해주었다면, 설정 파일을 적용한 Dockerfile을 만들어 주자.

FROM mysql:8.0

COPY ./my.cnf /etc/my.cnf

mySQL 8.0 버전을 사용하였으며, 위에서 만들었던 my.cnf 파일을 설정 파일로 활용하도록 만들기 위해 COPY를 통해 내부 설정 파일을 덮어씌우도록 만들어주었다.

그리고, 만든 Dockerfile을 활용하여 도커 인스턴스를 띄울 수 있도록 docker-compose를 작성해주도록 하자.

version: '3'
services:
  mysql:
    build: .
    container_name: mysql
    environment:
      MYSQL_DATABASE: practice
      MYSQL_ROOT_PASSWORD: test
    ports:
      - 3306:3306 # HOST:CONTAINER
    volumes:
      - ./mysql/data:/var/lib/mysql
    networks:
      - practice-net

networks:
  practice-net:
    driver: bridge

- image 대신에 build를 활용하여 현재 디렉터리 (.)에 있는 Dockerfile을 활용하여 빌드할 수 있돌고 설정해주었다.
- 또한, slave와 동일한 네트워크를 사용하도록 만들어줘야 하기 때문에 커스텀하게 네트워크를 정의해주었다. (요것도 설정 안 해주면 나중에 통신이 안 된다… 꼭 설정해두도록 하자.)
- 참고로, 네트워크 이름은 현재 위치한 {패키지 이름_설정한 이름} 과 같이 만들어지기 때문에, 나의 경우 네트워크 이름이 master-practice-net으로 만들어졌다.

다 만들었다면, 컨테이너를 띄워주자. -d를 통해 백그라운드로 띄울 수 있도록 만들었다.

docker-compose -f docker-compose.yml up -d

정상적으로 되었는지 확인하기 위해, 컨테이너 내부로 접속하여 설정 파일이 잘 적용되었는지 확인해보자.

docker exec -it {containerID} bash

mySQL 버전에 따라 다를 테지만, 나의 경우 /etc 하위에 설정 파일이 기본적으로 존재하였으며, 파일 내용이 위와 같이 잘 변경되어 있는 것을 확인할 수 있었다.

참고로, 나의 경우 이것저것 삽질하면서 시간을 많이 보냈었는데 혹시나 설정을 잘못하여 my.cnf 파일을 수정해야 하는 일이 발생했다면, 꼭 빌드 시 no-cache 옵션을 설정해두도록 하자. 아니면 캐시로 인해서 적용이 늦게 되었는데 왜 안 되지? 라며 시간을 보내는 일이 생길 수도 있다...

docker-compose build --no-cache

실습 준비 - 슬레이브 서버 구축하기

- 비슷한 방법으로 슬레이브 서버도 구축하고자 한다. 설정 파일은 다음과 같다.

[mysqld]
log-bin=mysql-bin    
server-id=2  
relay_log=/var/lib/mysql/mysql-relay-bin
log_replica_updates='ON'
read_only='ON'
authentication_policy=mysql_native_password

- 앞서 말했던 것처럼, server-id의 값은 꼭 마스터 서버와 다르게 설정해줘야 한다.
- relay_log: 릴레이 로그의 위치를 지정한다.
- log_replica_updates: 릴레이 로그를 활용하여 자신의 데이터베이스에 적용하는 모든 변경 사항을 바이너리 로그에도 기록한다.
- read_only: 슬레이브 서버는 읽기 전용으로 설정한다. (마스터 서버에서만 쓰기 연산이 발생하도록 만들기 위해 설정해준다.)
- 참고로, super 권한을 가진 사용자에 대해서는 적용되지 않는다!

다음으로 docker-compose 도 만들어주자. 포트와 컨테이너 이름은 다르게, 그리고 네트워크 정보는 꼭 동일하게 설정해주자.

version: '3'
services:
  mysql:
    build: .
    container_name: mysql-slave
    environment:
      MYSQL_DATABASE: practice
      MYSQL_ROOT_PASSWORD: test
    ports:
      - 3307:3306 # HOST:CONTAINER
    volumes:
      - ./mysql/data:/var/lib/mysql
    networks:
      - practice-net

networks:
  practice-net:
    external: true
    name: master_practice-net

그리고, 컨테이너에 접속한 다음 실제로 read_only 같은 옵션이 잘 설정되었는지 확인해보자.

show global variables like '%read_only%';

연동하기

✔️ 마스터 서버에 슬레이브 서버를 위한 계정 만들기

Replication 에서는 Slave Thread가 Master Thread 쪽으로 접속을 요청하기 때문에, Slave가 일종의 클라이언트이고, Master가 서버라고 볼 수 있다. 이때 Master에는 Slave가 로그인을 하기 위한 계정과 권한 (Replication Slave)가 필요하다. 마스터 서버에 접속하여 아래와 같이 계정을 생성하고 권한을 부여해주자.

mysql -u root -p
create user 'test-replication'@'%' identified by 'test';
grant replication slave on *.* to 'test-replication'@'%';
flush privileges;

권한이 정상적으로 잘 부여되었는지 한 번 확인하고 넘어가주자.

use mysql;
select user, host from user;
show grants for 'test-replication'@'%';

위와 같이 slave 권한이 잘 부여된 것을 확인할 수 있다.

본격적인 연동을 위하여 마스터 서버의 바이너리 로깅 상태를 확인해보자.

show master status;

- File: 현재 사용 중인 바이너리 로그 파일의 이름이다.
- Position: 바이너리 로그 파일 내의 오프셋이며, 마지막으로 복제를 완료한 지점에 대해 나타낸다.
- Binlog_Do_DB: 바이너리 로깅이 활성화된 데이터베이스이다. 우리가 앞서 마스터 서버를 구축해주었을 때 practice 데이터베이스에 대해 지정했던 것이 여기에 반영된 것이다.
- Binlog_Ignore_DB: 바이너리 로깅에서 제외된 데이터베이스이다.
- Executed_Gtid_set: GTID (Global Transaction Identifier), 해당 서버에서 실행된 모든 트렌잭션의 GTID를 의미한다. 커밋된 트랜잭션들이 가지게 되는 고유한 식별자이다. (마스터-슬레이브 모두 동일하게 사용)

-> 기본적으로 트랜잭션이 커밋되면 GTID를 할당받아 마스터의 바이너리 로그에 기록이 된다. 이때, 슬레이브가 바이너리 로그에 있던 내용을 릴레이 로그에 저장하면, GTID 정보를 토대로 해당 트랜잭션이 아직 미반영된 상태라면 반영하게 된다. 그리고 슬레이브의 바이너리 로그에도 기록하게 된다.

✔️ 연동하기 - 마스터 서버의 IP 주소 알아내기

여기까지 진행했다면 이제 두 서버에 대해 연결을 해줄 차례이다. 먼저, 마스터 서버의 컨테이너 IP 주소를 확인해야 한다.

이는, 슬레이브 서버가 마스터 서버에 접속하기 위한 정보를 얻기 위한 과정이라고 보면 된다.

우리는 도커를 사용하고 있기 때문에, 도커 컨테이너가 어떤 네트워크를 사용하고 있는지 확인하기 위해 아래와 같이 메시지를 입력하자.

docker inspect {container_name} | grep Network

만약 위의 캡쳐 화면처럼 마스터 서버와 슬레이브 서버의 네트워크 정보가 다르다면, 아래와 같은 방법으로 수정해줄 수 있다. (물론 재생성을 해도 괜찮다)

// mysql-slave 컨테이너에 대해 slave_default 네트워크 끊어주기
docker network disconnect slave_default mysql-slave

// 대신 master_default 네트워크를 연결해주기
docker network connect master_default mysql-slave

그럼 위와 같이 master 컨테이너와 동일한 네트워크 아이디를 할당받은 것을 볼 수 있다.

위에서 확인한 네트워크 아이디를 바탕으로, 전체 docker 네트워크 목록을 확인하여 어떤 네트워크에 연결되어 있는지 체크하자.

docker network ls

앞서 봤던 네트워크 아이디가 95dc~ 로 시작한 것을 볼 수 있으니, 현재 연결된 네트워크 이름이 ‘master_default’ 인 것을 확인할 수 있었다. 해당 네트워크의 IP 주소를 알아보기 위해 아래와 같이 다시 입력해주자.

docker inspect {network_name} | grep IPv4Address

✔️ 연동하기 - 슬레이브 서버에서 접속하기

이제 IP 주소도 알게 되었으니, 슬레이브 서버에 접속하여 아래와 같은 명령어를 입력해주자.

CHANGE MASTER TO MASTER_HOST='172.29.0.2', MASTER_PORT=3306, MASTER_USER='test-replication', MASTER_PASSWORD='test', MASTER_LOG_FILE='mysql-bin.000003', MASTER_LOG_POS=880, GET_MASTER_PUBLIC_KEY=1;

- MASTER_HOST / MASTER_PORT: 마스터 서버의 IP 주소 / Port로, 슬레이브 서버가 마스터 서버에 접속하기 위해 알아야 하는 IP 정보와 포트 정보이다.

- MASTER_USER / MASTER_PASSWORD: 이전에 마스터 서버에서 생성했던 슬레이브 서버용 계정 정보이다.

- MASTER_LOG_FILE / MASTER_LOG_POST: 앞서 마스터 서버의 바이너리 로그 파일 정보에서 봤던 파일 이름과 오프셋 정보이다. (어디서부터 읽어올 것인지 정하는 것)
- GET_MASTER_PUBLIC_KEY=1 : 슬레이브가 마스터 서버에 연결할 때 마스터의 공개키를 자동으로 요청하게 된다.

연동을 시작해주기 위해 start slave를 입력해주자.

재구성하고 싶을 때는 stop replica > reset slave;를 활용해주면 된다.

start slave;

마지막으로 연동을 확인하기 위해 아래의 명령어를 입력해보자.

 show slave status\G

여기에서 Slave_IO_Running, Slave_SQL_Running의 값이 모두 Yes로 표시가 되어야 한다.

만약 Slave_IO_Running가 Connecting으로 뜬다면, 아래로 내려 Last_IO_Error 항목을 보자.

나 같은 경우는 초기에 network 설정을 제대로 안 해줘서 이렇게 통신이 실패했었다.

혹은, 이런 식으로 Authentication 오류가 발생했다면, 초기에 mysql 설정 파일에서 default_authentication_plugin 값을 지정해주지 않았을 확률이 높다… 왜 안 되는지 나도 알고 싶지 않았지만 이 2가지 오류 때문에 시간을 많이 썼다.

슬레이브 서버에서 마스터 서버 연동 시 GET_MASTER_PUBLIC_KEY 이 옵션을 빼먹었을 확률도 있다…! 잘 확인해보자.

최종적으로 제대로 되었다면 아래와 같이 둘 다 Yes로 뜰 것이다.
호스트 주소가 이전과 다른 이유는 오류가 꽤 여러 번 떴었어서 다시 만드느라 바뀌었다.

마스터에서도 슬레이브의 접속 정보를 확인할 수 있는데, 아래와 같이 입력해보자.

show processlist\G

가장 아래에 우리가 연동했던 test-replication 이라는 친구에 대해 State로 ‘source가 모든 binlog를 replication을 보냈다’ 라는 문구를 확인할 수 있다!

복제 테스트 해보기

마스터 서버에 접속하여 더미 데이터를 집어 넣고 한 번 확인해보자.

use practice;

create table test(
    id bigint not null primary key,
    name varchar(100)
) engine = 'INNODB';

insert into test (id, name) values (1, 'test');

insert 후 마스터 서버의 모습이다.

그리고, 슬레이브 서버에 접속하여 해당 데이터가 잘 복제되었는지 확인해보자.

위와 같이 잘 복제가 된 것을 확인할 수 있다!

(데이터 값이 똑같아서 아닌 것처럼 보이지만, 실제로 슬레이브 서버에 접속했을 때 나온 결과이다!

마무리

이번 포스팅에서는 mySQL을 활용하여 간단하게 master <-> slave 간 replication 을 만들어보았다.

실무에서는 고려해야 하는 점들이 훨씬 더 많겠지만, master의 내용이 알아서 slave로 복제되는 모습을 직접 보니까 굉장히 신기했다.

이렇게 간단하게 만드는 것도 엄청 시간이 오래 걸렸는데, 실제로는 훨씬 복잡하게 동작할 것 같다는 고민도 들엇다.

실제로 일을 하면서 이런 것까지 제대로 고찰해보지 못했었는데, 앞으로는 이런 식으로 간단하게 만들어 볼 수 있는 것들은 실습해보는 식으로 공부해봐야겠다는 생각이 들었다.

다음 포스팅이 언제가 될지 모르겠지만... 시간 내서 2편도 작성해봐야겠다. 끝!

[Intellij] 안전한 리팩터링 진행하기 - Intellij를 활용한 점진적 리팩터링

dolmeng2 — Sun, 25 Feb 2024 16:04:58 +0900

들어가기 전

나는 평소에 마우스는 사용하지 않지만, 맥북 터치패드를 정말 많이 사용하는 편이었어서 개발할 때 단축키를 많이 사용하지 않는 편이었다. 그러다 보니 자동으로 개발할 때 미묘하게 속도 차이가 났었는데, 이번에 단축키도 공부할겸, 리팩터링 시 어떻게 하면 Intellij 를 최대한 활용할 수 있는지 스터디 하는 시간을 가졌다. (갓나니개발자님 덕분에 많이 배울 수 있는 시간이었다 ㅎ_ㅎ)

이번 포스팅에서 사용된 샘플 코드는 백명석 님의 깃허브를 가면 확인할 수 있는데, 나는 사내에서 코틀린을 사용하고 있다 보니까 해당 코드를 코틀린 + Kotest로 변환하여 연습을 해보았다.

어떤 식으로 리팩터링을 했는지는 아래의 레파지토리에 커밋별로 나타내었다.

GitHub - Cl8D/kotlin-expense: rafactoring practice

rafactoring practice. Contribute to Cl8D/kotlin-expense development by creating an account on GitHub.

github.com

main 브랜치의 경우 리팩터링 이전의 코드이고, refactoring 브랜치를 가면 점진적 리팩터링 과정을 참고할 수 있으니 혹시 필요한 분이 계시다면 참고하면 좋을 것 같다.

원본 코드의 문제점

우선, 리팩터링이 되기 이전의 샘플 코드이다.

class Expense(
    var type: Type,
    var amount: Int
) {
    enum class Type {
        DINNER,
        BREAKFAST,
        CAR_RENTAL
    }
}

interface ReportPrinter {
    fun print(text: String?)
}

class ExpenseReport {
    private val expenses: MutableList<Expense> = ArrayList()
    private val date: String
        get() = "9/12/2002"
    
    fun printReport(printer: ReportPrinter) {
        var total = 0
        var mealExpenses = 0
        printer.print("Expenses " + date + "\\n")

        for (expense in expenses) {
            if (expense.type == Expense.Type.BREAKFAST || expense.type == Expense.Type.DINNER) {
                mealExpenses += expense.amount
            }
            var name = "TILT"

            when (expense.type) {
                Expense.Type.DINNER -> name = "Dinner"
                Expense.Type.BREAKFAST -> name = "Breakfast"
                Expense.Type.CAR_RENTAL -> name = "Car Rental"
            }

            printer.print(
                String.format(
                    "%s\\t%s\\t$%.02f\\n",
                    if (expense.type == Expense.Type.DINNER
                        && expense.amount > 5000
                        || expense.type === Expense.Type.BREAKFAST
                        && expense.amount > 1000) "X" else " ",
                    name, expense.amount / 100.0
                )
            )
            total += expense.amount
        }
        printer.print(String.format("\\nMeal expenses $%.02f", mealExpenses / 100.0))
        printer.print(String.format("\\nTotal $%.02f", total / 100.0))
    }

    fun addExpense(expense: Expense) {
        expenses.add(expense)
    }
}

앞으로 위의 코드가 우리가 원하는 시나리오대로 잘 동작하는지 검증할 수 있도록, 아래의 테스트 코드를 사용할 것이다.

모든 리팩터링의 시작은, ‘우리가 코드를 수정하더라도 정상적으로 작동하는 것을 보장받을 수 있는가?’로부터 시작하는 것 같다. 실무에서는 테스트 코드가 작성되어 있지 않다면 어렵겠지만, 웬만하면 리팩터링을 진행할 때 테스트 코드를 함께 동반하는 것이 좋은 것 같다.

class MockReportPrinter : ReportPrinter {
    private var printedText = ""

    override fun print(text: String?) {
        printedText += text

    }

    fun getText(): String {
        return printedText
    }
}

internal class ExpenseReportTest : StringSpec({
    lateinit var report: ExpenseReport
    lateinit var printer: MockReportPrinter

    beforeTest {
        report = ExpenseReport()
        printer = MockReportPrinter()
    }

    "printEmpty" {
        report.printReport(printer)

        printer.getText() shouldBe """
            Expenses 9/12/2002

            Meal expenses $0.00
            Total $0.00
        """.trimIndent()
    }

    "printOneDinner" {
        report.addExpense(Expense(Expense.Type.DINNER, 1678))
        report.printReport(printer)

        printer.getText() shouldBe """
            Expenses 9/12/2002
             	Dinner	$16.78

            Meal expenses $16.78
            Total $16.78
        """.trimIndent()
    }

    "twoMeals" {
        report.addExpense(Expense(Expense.Type.DINNER, 1000))
        report.addExpense(Expense(Expense.Type.BREAKFAST, 500))
        report.printReport(printer)

        printer.getText() shouldBe """
            Expenses 9/12/2002
             	Dinner	$10.00
             	Breakfast	$5.00

            Meal expenses $15.00
            Total $15.00
        """.trimIndent()
    }

    "twoMealsAndCarRental" {
        report.addExpense(Expense(Expense.Type.DINNER, 1000))
        report.addExpense(Expense(Expense.Type.BREAKFAST, 500))
        report.addExpense(Expense(Expense.Type.CAR_RENTAL, 50000))
        report.printReport(printer)

        printer.getText() shouldBe """
            Expenses 9/12/2002
             	Dinner	$10.00
             	Breakfast	$5.00
             	Car Rental	$500.00

            Meal expenses $15.00
            Total $515.00
        """.trimIndent()
    }

    "overages" {
        report.addExpense(Expense(Expense.Type.BREAKFAST, 1000))
        report.addExpense(Expense(Expense.Type.BREAKFAST, 1001))
        report.addExpense(Expense(Expense.Type.DINNER, 5000))
        report.addExpense(Expense(Expense.Type.DINNER, 5001))
        report.printReport(printer)

        printer.getText() shouldBe """
            Expenses 9/12/2002
             	Breakfast	$10.00
            X	Breakfast	$10.01
             	Dinner	$50.00
            X	Dinner	$50.01

            Meal expenses $120.02
            Total $120.02
        """.trimIndent()
    }
})

기존의 코드의 경우 다음과 같은 문제점이 존재한다.

1. ExpenseReport 가 하고 있는 일이 너무 많음
2. 비용에 대한 계산을 하는 함수와 출력에 대한 함수가 합쳐져 있어서 기능 자체의 결합도가 높음
3. 비용에 대한 변수의 스코프가 printReport() 함수의 지역 변수로 선언되어 있어, 개발자가 인지하기가 어려움.
4. 비용에 대한 타입이 추가되었을 때 확장하기가 어려움

그래서 우리는 위의 문제점을 최대한 수정할 수 있도록 점진적인 리팩터링을 진행할 것이다.

Step1 - 가장 간단한 부분에 대해서 함수로 분리하기

fun printReport(printer: ReportPrinter) {
    var total = 0
    var mealExpenses = 0
    printer.print("Expenses " + date + "\\n")

    for (expense in expenses) {
        if (expense.type == Expense.Type.BREAKFAST || expense.type == Expense.Type.DINNER) {
            mealExpenses += expense.amount
        }
        var name = "TILT"

        when (expense.type) {
            Expense.Type.DINNER -> name = "Dinner"
            Expense.Type.BREAKFAST -> name = "Breakfast"
            Expense.Type.CAR_RENTAL -> name = "Car Rental"
        }

        printer.print(
            String.format(
                "%s\\t%s\\t$%.02f\\n",
                if (expense.type == Expense.Type.DINNER
                    && expense.amount > 5000
                    || expense.type === Expense.Type.BREAKFAST
                    && expense.amount > 1000) "X" else " ",
                name, expense.amount / 100.0
            )
        )
        total += expense.amount
    }
    printer.print(String.format("\\nMeal expenses $%.02f", mealExpenses / 100.0))
    printer.print(String.format("\\nTotal $%.02f", total / 100.0))
}

먼저, 위 함수에서 분리할 수 있는 부분을 최대한 추출하여 함수로 만들어보자.

우리는 위의 함수를 크게 3가지 부분으로 분리할 수 있다.

1. 헤더 정보 출력하기
2. 비용을 계산하고 중간 계산 결과를 출력하기
3. 최종 비용을 출력하기

비교적 복잡한 2번 내용을 우선 배제하고, 1번과 3번 내용을 추출하기 위해 다음과 같이 함수로 추출하자.

이때, 1번 내용에서 total, mealExpenses 는 헤더 정보를 출력하기 위해 사용되는 정보는 아니기 때문에 선언된 변수를 2번 부분에게 내릴 수 있으며, 3번 부분의 경우 파라미터를 통해 total, mealExpenses를 넘겨주면 되기 때문에 크게 무리가 없다.

command + option + m (extract method) 을 통해 각각을 함수로 분리하자.

그럼 아래와 같이 분리가 되었을 텐데, 테스트 코드를 통해서 아직 기능이 잘 작동하는지 체크하자.

fun printReport(printer: ReportPrinter) {
    printHeader(printer)
    var total = 0
    var mealExpenses = 0

    for (expense in expenses) {
        if (expense.type == Expense.Type.BREAKFAST || expense.type == Expense.Type.DINNER) {
            mealExpenses += expense.amount
        }
        var name = "TILT"

        when (expense.type) {
            Expense.Type.DINNER -> name = "Dinner"
            Expense.Type.BREAKFAST -> name = "Breakfast"
            Expense.Type.CAR_RENTAL -> name = "Car Rental"
        }

        printer.print(
            String.format(
                "%s\\t%s\\t$%.02f\\n",
                if (expense.type == Expense.Type.DINNER
                    && expense.amount > 5000
                    || expense.type === Expense.Type.BREAKFAST
                    && expense.amount > 1000) "X" else " ",
                name, expense.amount / 100.0
            )
        )
        total += expense.amount
    }
    printTotal(printer, mealExpenses, total)
}

private fun printTotal(printer: ReportPrinter, mealExpenses: Int, total: Int) {
    printer.print(String.format("\\nMeal expenses $%.02f", mealExpenses / 100.0))
    printer.print(String.format("\\nTotal $%.02f", total / 100.0))
}

private fun printHeader(printer: ReportPrinter) {
    printer.print("Expenses " + date + "\\n")
}

테스트가 정상적으로 통과한다면, 안심하고 다음 스텝으로 넘어가보자.

Step 2 - 비즈니스 로직과 출력을 분리하자

이 다음에는 2번 부분을 뿌실 차례이다. 해당 부분은 출력과 계산이 함께 혼합되어 있기 때문에 분리하기가 현재로서는 어려우니, 반복문을 2개로 분리하여 출력과 계산을 분리해보자.

마찬가지로 분리 후에도 테스트 코드를 실행해보자. 잘 통과하는 모습을 볼 수 있을 것이다.

참고로, 코드 블록을 선택할 때 option + 방향키 윗키를 누르게 되면 블록별로 한 번에 select를 할 수 있다.

터치패드나 마우스를 쓰지 않고도 블록을 선택할 수 있는 좋은 키이다.

fun printReport(printer: ReportPrinter) {
    printHeader(printer)
    var total = 0
    var mealExpenses = 0

    for (expense in expenses) {
        if (expense.type == Expense.Type.BREAKFAST || expense.type == Expense.Type.DINNER) {
            mealExpenses += expense.amount
        }
        total += expense.amount
    }

    for (expense in expenses) {
        var name = "TILT"

        when (expense.type) {
            Expense.Type.DINNER -> name = "Dinner"
            Expense.Type.BREAKFAST -> name = "Breakfast"
            Expense.Type.CAR_RENTAL -> name = "Car Rental"
        }

        printer.print(
            String.format(
                "%s\\t%s\\t$%.02f\\n",
                if (expense.type == Expense.Type.DINNER
                    && expense.amount > 5000
                    || expense.type === Expense.Type.BREAKFAST
                    && expense.amount > 1000) "X" else " ",
                name, expense.amount / 100.0
            )
        )
    }

    printTotal(printer, mealExpenses, total)
}

그렇다면, 이제 비용을 계산하는 부분에 대해서 함수로 분리해보자.

이때, Intellij의 도움을 받는다면 꽤나 이상한 형태로 분리를 해주는 모습을 볼 수 있다.

private fun calculateExpense(): Pair<Int, Int> {
    var total = 0
    var mealExpenses = 0

    for (expense in expenses) {
        if (expense.type == Expense.Type.BREAKFAST || expense.type == Expense.Type.DINNER) {
            mealExpenses += expense.amount
        }
        total += expense.amount
    }
    return Pair(total, mealExpenses)
}

위와 같이 Pair를 통해서 분리를 해주려고 한다. Pair의 경우 first, second 를 통해서 각각의 변수에 접근할 수 있지만, 읽는 사람의 입장에서 각 변수가 무엇을 뜻하는지 인지하기가 어려워진다.

그래서, 이 방법 대신에 total, mealExpenses의 변수를 클래스의 변수로 옮겨서, 실질적으로 해당 함수에는 클래스의 변수를 접근하여 값을 계산할 수 있도록 만들어보자.

이때, 자바에서는 해당 변수에 커서를 대고 command + option + F (extract field)를 누르게 되면, 아래와 같이 해당 변수를 어디로 옮길지 선택할 수 있는 창이 뜨게 된다.

하지만, 코틀린에서는 var 변수의 경우 잘 동작하지 않아서 수동으로 옮겨주었다. (val 변수면 괜찮을 것 같은데, var 변수여서 잘 적용이 안 된 것 같아서 아쉽다.)

class ExpenseReport {  
    private var total = 0
    private var mealExpenses = 0
		....
}

이제, 비즈니스 로직에 대해서 함수로 분리를 해보자. 비용에 대한 계산을 진행하고 있으니, calculateExpense 라는 이름을 붙였다.

private fun calculateExpenses() {
    for (expense in expenses) {
        if (expense.type == Expense.Type.BREAKFAST || expense.type == Expense.Type.DINNER) {
            mealExpenses += expense.amount
        }
        total += expense.amount
    }
}

이 함수는 현재 if문이 하는 일을 정확하게 알기 어려우니, 해당 부분도 함수로 분리해보자.

비용의 타입이 아침이나 저녁인 경우 mealExpenses를 더하고 있으니, 간단하게 isMeal 이라는 네이밍을 붙여주었다.

private fun calculateExpenses() {
    for (expense in expenses) {
        if (isMeal(expense)) {
            mealExpenses += expense.amount
        }
        total += expense.amount
    }
}

private fun isMeal(expense: Expense) = expense.type == Expense.Type.BREAKFAST || expense.type == Expense.Type.DINNER

여전히 함수가 2 depth 여서 알아보기가 어렵다. 한 번 더 분리를 해주자.

private fun calculateExpenses() {
    for (expense in expenses) {
        addTotal(expense)
    }
}

private fun addTotal(expense: Expense) {
    if (isMeal(expense)) {
        mealExpenses += expense.amount
    }
    total += expense.amount
}

마찬가지로, 출력에 대한 부분도 함수로 분리해보자.

private fun printExpenses(printer: ReportPrinter) {
    for (expense in expenses) {
        var name = "TILT"

        when (expense.type) {
            Expense.Type.DINNER -> name = "Dinner"
            Expense.Type.BREAKFAST -> name = "Breakfast"
            Expense.Type.CAR_RENTAL -> name = "Car Rental"
        }

        printer.print(
            String.format(
                "%s\t%s\t$%.02f\n",
                if (expense.type == Expense.Type.DINNER
                    && expense.amount > 5000
                    || expense.type === Expense.Type.BREAKFAST
                    && expense.amount > 1000
                ) "X" else " ",
                name, expense.amount / 100.0
            )
        )
    }
}

위 함수에서도 크게 2가지로 분리할 수 있게 된다.

1. 비용에 대한 이름을 계산하기
2. 실질적으로 비용에 대한 이름을 출력하기

이에 따라서 함수를 또 2개로 분리하였다.

이때, name의 경우 함수로부터 얻어오게 되기 때문에 더 이상 var 로 있을 필요가 없기 때문에 val로 변경해주었다.

private fun printExpenses(printer: ReportPrinter) {
    for (expense in expenses) {
        val name = getName(expense)

        printer.print(
            String.format(
                "%s\\t%s\\t$%.02f\\n",
                if (expense.type == Expense.Type.DINNER
                    && expense.amount > 5000
                    || expense.type === Expense.Type.BREAKFAST
                    && expense.amount > 1000
                ) "X" else " ",
                name, expense.amount / 100.0
            )
        )
    }
}

private fun getName(expense: Expense): String {
    var name = "TILT"

    when (expense.type) {
        Expense.Type.DINNER -> name = "Dinner"
        Expense.Type.BREAKFAST -> name = "Breakfast"
        Expense.Type.CAR_RENTAL -> name = "Car Rental"
    }
    return name
}

여기까지 진행하고, 마찬가지로 테스트 코드를 통해 중간중간 체크를 진행해주자.

Step3 - 불필요한 메서드 파라미터 제거하기

Step 1, 2를 진행하면서 가장 메인이 되면 public 함수인 printReport() 가 간결해진 것을 확인할 수 있다.

class ExpenseReport {
    private val expenses: MutableList<Expense> = ArrayList()
    private val date: String
        get() = "9/12/2002"

    private var total = 0
    private var mealExpenses = 0

    fun printReport(printer: ReportPrinter) {
        printHeader(printer)
        calculateExpenses()
        printExpenses(printer)
        printTotal(printer, mealExpenses, total)
    }

    private fun printExpenses(printer: ReportPrinter) {
        for (expense in expenses) {
            val name = getName(expense)

            printer.print(
                String.format(
                    "%s\t%s\t$%.02f\n",
                    if (expense.type == Expense.Type.DINNER
                        && expense.amount > 5000
                        || expense.type === Expense.Type.BREAKFAST
                        && expense.amount > 1000
                    ) "X" else " ",
                    name, expense.amount / 100.0
                )
            )
        }
    }

    private fun getName(expense: Expense): String {
        var name = "TILT"

        when (expense.type) {
            Expense.Type.DINNER -> name = "Dinner"
            Expense.Type.BREAKFAST -> name = "Breakfast"
            Expense.Type.CAR_RENTAL -> name = "Car Rental"
        }
        return name
    }

    private fun calculateExpenses() {
        for (expense in expenses) {
            addTotal(expense)
        }
    }

    private fun addTotal(expense: Expense) {
        if (isMeal(expense)) {
            mealExpenses += expense.amount
        }
        total += expense.amount
    }

    private fun isMeal(expense: Expense) = expense.type == Expense.Type.BREAKFAST || expense.type == Expense.Type.DINNER

    private fun printTotal(printer: ReportPrinter, mealExpenses: Int, total: Int) {
        printer.print(String.format("\nMeal expenses $%.02f", mealExpenses / 100.0))
        printer.print(String.format("\nTotal $%.02f", total / 100.0))
    }

    private fun printHeader(printer: ReportPrinter) {
        printer.print("Expenses " + date + "\n")
    }

    fun addExpense(expense: Expense) {
        expenses.add(expense)
    }
}

크게 헤더를 출력하기 / 비용을 계산하기 / 비용을 출력하기 / 총 합계를 출력하기, 이렇게 4가지로 분리되었다.

그러나, 함수로 추출하면서 parameter drilling 으로 인해 필요가 없음에도 인자로 계속 넘겨주는 부분들이 눈에 들어올 것이다.

이번 단계에서는 해당 부분에 대해 제거해보고자 한다.

가장 눈에 띄는 것은 ReportPrinter 가 계속해서 인자로 넘어가고 있다는 점이다.

해당 부분을 제거하기 위해, 마찬가지로 ReportPrinter에 대해 클래스의 변수로 승격시키는 작업을 진행해보자.

마찬가지로 자바 코드였다면 command + option + F 를 통해서 잘 추출이 되지만, 코틀린이기 때문에 우선 수기로 추출을 진행해주었다. 이때, printer의 경우 NPE 방지를 위해서 lateinit 을 통해 지연 초기화가 가능하도록 설정해주었다.

private lateinit var printer: ReportPrinter

fun printReport(printer: ReportPrinter) {
    this.printer = printer
    printHeader(printer)
    calculateExpenses()
    printExpenses(printer)
    printTotal(printer, mealExpenses, total)
}

이러면, 클래스의 필드 레벨에서 printer가 선언이 되어 있기 때문에 더 이상 인자로 계속 넘겨줄 필요가 없어진다.

자바라면 대상이 되는 함수에서 command + option + n (Inline Parameter) 을 누르면 위와 같이 클래스의 변수로 선언된 값을 사용하도록 쉽게 리팩터링이 가능하다.

하지만, 코틀린이라서 그런지 잘 동작하지 않아 command + F6 (Change Signature) 를 통해서 인자로 넘어온 printer 를 제거해주었다. printer를 인자로 받는 함수들에 대해서 모두 적용해보도록 하자.

참고로 내부적으로 지울 때는 command + backspace를 활용하고 command + enter를 누르면 변경된 내용이 적용된다. (이런 부분에 대해서도 터치패드를 사용하지 않는 노력을 하는 것이 좋을 것 같다.)

이 과정에서 conflict view가 나오면 continue로 타겟을 옮긴 다음 space를 눌려주면 적용된다!

그럼 여기까지 했을 때 아래와 같은 모습이 나올 것이며, 한 번 더 테스트 코드를 돌려 체크해주자.

cf) 테스트 코드를 실행할 때도 control + r (바로 이전의 실행 내역 재실행) 을 하거나, control + option + r을 통해서 실행 내역 중에서 원하는 것을 실행할 수 있도록 해보자.

class ExpenseReport {
    private val expenses: MutableList<Expense> = ArrayList()
    private val date: String
        get() = "9/12/2002"

    private var total = 0
    private var mealExpenses = 0
    private lateinit var printer: ReportPrinter

    fun printReport(printer: ReportPrinter) {
        this.printer = printer
        printHeader()
        calculateExpenses()
        printExpenses()
        printTotal()
    }

    private fun printExpenses() {
        for (expense in expenses) {
            val name = getName(expense)

            printer.print(
                String.format(
                    "%s\t%s\t$%.02f\n",
                    if (expense.type == Expense.Type.DINNER
                        && expense.amount > 5000
                        || expense.type === Expense.Type.BREAKFAST
                        && expense.amount > 1000
                    ) "X" else " ",
                    name, expense.amount / 100.0
                )
            )
        }
    }

    private fun getName(expense: Expense): String {
        var name = "TILT"

        when (expense.type) {
            Expense.Type.DINNER -> name = "Dinner"
            Expense.Type.BREAKFAST -> name = "Breakfast"
            Expense.Type.CAR_RENTAL -> name = "Car Rental"
        }
        return name
    }

    private fun calculateExpenses() {
        for (expense in expenses) {
            addTotal(expense)
        }
    }

    private fun addTotal(expense: Expense) {
        if (isMeal(expense)) {
            mealExpenses += expense.amount
        }
        total += expense.amount
    }

    private fun isMeal(expense: Expense) = expense.type == Expense.Type.BREAKFAST || expense.type == Expense.Type.DINNER

    private fun printTotal() {
        printer.print(String.format("\nMeal expenses $%.02f", mealExpenses / 100.0))
        printer.print(String.format("\nTotal $%.02f", total / 100.0))
    }

    private fun printHeader() {
        printer.print("Expenses " + date + "\n")
    }

    fun addExpense(expense: Expense) {
        expenses.add(expense)
    }
}

여기에서, printReport()의 함수를 한 번 더 분리하여 완전하게 계산과 출력에 대한 부분으로 나누자.

fun printReport(printer: ReportPrinter) {
    this.printer = printer
    calculateExpenses()
    printExpensesAndTotal()
}

private fun printExpensesAndTotal() {
    printHeader()
    printExpenses()
    printTotal()
}

printExpenses() 역시 함수가 2 depth 를 넘어가니 알아보기 어려운 것 같다. 한 번 더 분리해주자.

private fun printExpenses() {
    for (expense in expenses) {
        printExpense(expense)
    }
}

private fun printExpense(expense: Expense) {
    val name = getName(expense)

    printer.print(
        String.format(
            "%s\t%s\t$%.02f\n",
            if (expense.type == Expense.Type.DINNER
                && expense.amount > 5000
                || expense.type === Expense.Type.BREAKFAST
                && expense.amount > 1000
            ) "X" else " ",
            name, expense.amount / 100.0
        )
    )
}

printExpense() 내부에서 name 이 한 곳에서만 쓰이고 있으니 inline 을 통해서 조금 더 줄여줄 수 있다.

private fun printExpense(expense: Expense) {
    printer.print(
        String.format(
            "%s\t%s\t$%.02f\n",
            if (expense.type == Expense.Type.DINNER
                && expense.amount > 5000
                || expense.type === Expense.Type.BREAKFAST
                && expense.amount > 1000
            ) "X" else " ",
            getName(expense), expense.amount / 100.0
        )
    )
}

추가적으로 값을 포맷팅 하는 부분의 가독성을 위해 if문을 한 번 더 함수로 분리해주자.

private fun printExpense(expense: Expense) {
    printer.print(
        String.format(
            "%s\t%s\t$%.02f\n",
            if (isOverage(expense)) "X" else " ",
            getName(expense), expense.amount / 100.0
        )
    )
}

private fun isOverage(expense: Expense) = (expense.type == Expense.Type.DINNER
        && expense.amount > 5000
        || expense.type === Expense.Type.BREAKFAST
        && expense.amount > 1000)

마지막으로, 기존 코드에서는 100으로 나누는 부분들이 상당히 겹치는 것을 볼 수 있었다. 이 부분에 대해서 함수로 추출해보자.

이때, 현재 상태에서 단순하게 함수로 추출하게 되면 겹치는 부분들에 대해 intellij 가 추천을 해주지 않기 때문에, 1차적으로 지역변수로 분리를 해보자. (어차피 사라질 변수들이기 때문에 이름을 대충 지었다.)

private fun printExpense(expense: Expense) {
    val amount = expense.amount
    printer.print(
        String.format(
            "%s\\t%s\\t$%.02f\\n",
            if (isOverage(expense)) "X" else " ",
            getName(expense), amount / 100.0
        )
    )
}

private fun printTotal() {
    val tempMealExpense = mealExpenses
    val tempTotal = total
    printer.print(String.format("\\nMeal expenses $%.02f", tempMealExpense / 100.0))
    printer.print(String.format("\\nTotal $%.02f", tempTotal / 100.0))
}

이 상태에서 extract method 를 하게 되면, 함수의 시그니처가 Int → Double 로 고정되기 때문에 사용되는 모든 부분에 대해서 전부 교체가 가능해진다.

private fun printExpense(expense: Expense) {
    val amount = expense.amount
    printer.print(
        String.format(
            "%s\t%s\t$%.02f\n",
            if (isOverage(expense)) "X" else " ",
            getName(expense), getRate(amount)
        )
    )
}

private fun printTotal() {
    val tempMealExpense = mealExpenses
    val tempTotal = total
    printer.print(String.format("\nMeal expenses $%.02f", getRate(tempMealExpense)))
    printer.print(String.format("\nTotal $%.02f", getRate(tempTotal)))
}

private fun getRate(amount: Int) = amount / 100.0

마지막으로 inline variable 을 통해서 임시 변수를 제거해주자.

그럼 최종적으로 우리가 원하는 형태로 잘 수정된 것을 볼 수 있다.

private fun printExpense(expense: Expense) {
    printer.print(
        String.format(
            "%s\t%s\t$%.02f\n",
            if (isOverage(expense)) "X" else " ",
            getName(expense), getRate(expense.amount)
        )
    )
}

private fun printTotal() {
    printer.print(String.format("\nMeal expenses $%.02f", getRate(mealExpenses)))
    printer.print(String.format("\nTotal $%.02f", getRate(total)))
}

private fun getRate(amount: Int) = amount / 100.0

Step4 - 도메인의 응집도를 높여보자

여기까지 하고 나면 전체적인 클래스에 대해 읽기 쉬운 코드가 되어 있을 것이다.

하지만, 핵심 도메인인 Expense 가 하는 일이 굉장히 빈약하게 느껴진다.

출력과 클래스의 전역 변수와 관련없이 수행되고 있는 ‘비용의 이름에 대해서 가져오는 기능’과 ‘meal인지 판단하는 기능’, ‘평균인지 계산하는 기능’은 도메인에게 넘겨줄 수 있지 않을까?

f6을 눌러 (Move Method) 도메인에게 해당 기능을 위임해보자.

참고로, 코틀린에서는 기본적으로 이 기능이 꺼져 있기 때문에 별도의 설정이 필요하다.

아래의 글에서 설정하는 방법을 바탕으로 미리 해두면 좋다. (갓망규)

[Kotlin] 인텔리제이(IntelliJ)에서 코틀린 move instance method(다른 클래스로 메소드 옮기기) 리팩토링

1. 코틀린에서 move instance method 리팩토링 기능 활성화하기 [ move instance method 리팩토링 기능 소개 ] 예를 들어 신용카드를 발급하는 유스케이스가 있고, 신용카드 발급을 위해서는 기본적으로 사용

mangkyu.tistory.com

그러면 아래와 같이 도메인에게 해당 기능들이 잘 넘어간 것을 볼 수 있다.

class Expense(
    var type: Type,
    var amount: Int
) {
    enum class Type {
        DINNER,
        BREAKFAST,
        CAR_RENTAL
    }

    fun getName(): String {
        var name = "TILT"

        when (this.type) {
            Type.DINNER -> name = "Dinner"
            Type.BREAKFAST -> name = "Breakfast"
            Type.CAR_RENTAL -> name = "Car Rental"
        }
        return name
    }

    fun isMeal() = this.type == Type.BREAKFAST || this.type == Type.DINNER

    fun isOverage() = (this.type == Type.DINNER
        && this.amount > 5000
        || this.type === Type.BREAKFAST
        && this.amount > 1000)
}

Step5 - 출력하는 부분에 대해서 분리해보자

여전히 출력과 비즈니스 로직이 합쳐져 있다는 부분이 마음에 걸린다.

그래서, 우리는 비용을 계산하는 부분과 출력을 담당하는 부분을 별도의 클래스로 분리하여 기능별 응집도를 높여보도록 할 것이다.

그러나… 자바에는 control + t → extract delegate 를 선택하면 쉽게 분리가 가능하지만, 코틀린에는 존재하지 않는다. (가장 아쉽다)

그래서, extract delegate 대신 extract superclass를 활용하여 약간의 꼼수로 클래스를 분리해보고자 한다.

먼저, 기존의 클래스의 이름을 ExpenseReporter 로 변경하여 출력에 대한 기능들만 남길 수 있도록 의미를 부여해주었다. (Shift + F6 - Rename)

그리고, extract superclass를 통해서 비용을 계산하는 부분을 추출해주자.

함수를 선택하다 보면 위와 같이 !가 떠있는 것을 볼 수 있는데, 이는 같이 옮겨야 깨지지 않는 친구들을 Intellj 가 감지하여 알려준다.

!가 뜬 친구들까지 함께 체크하여 선택해준다.

그럼 아래와 같이 ExpenseReport 라는 친구가 생기게 된다. 우리는 SuperClass로 어쩔 수 없이 생성했기 때문에 open class가 되었는데, 해당 클래스를 일반 클래스로 바꾸어주고, 외부에서 호출할 수 있도록 함수 역시 public 으로 열어두도록 하자.

// AS-IS
open class ExpenseReport {
    protected val expenses: MutableList<Expense> = ArrayList()
    protected var total = 0
    protected var mealExpenses = 0
    protected fun calculateExpenses() {
        for (expense in expenses) {
            addTotal(expense)
        }
    }

    private fun addTotal(expense: Expense) {
        if (expense.isMeal()) {
            mealExpenses += expense.amount
        }
        total += expense.amount
    }

    fun addExpense(expense: Expense) {
        expenses.add(expense)
    }
}

// TO-BE
class ExpenseReport {
     val expenses: MutableList<Expense> = ArrayList()
     var total = 0
     var mealExpenses = 0

     fun calculateExpenses() {
        for (expense in expenses) {
            addTotal(expense)
        }
    }

    private fun addTotal(expense: Expense) {
        if (expense.isMeal()) {
            mealExpenses += expense.amount
        }
        total += expense.amount
    }

    fun addExpense(expense: Expense) {
        expenses.add(expense)
    }
}

또한, 기존 클래스도 깨져있을 테니까 수정이 필요하다. Report에 대해 전역 변수를 선언해준 다음, F2를 눌러 오류 부분을 찾아가며 수정해주자. (addExpense의 경우 테스트 코드를 최대한 덜 깨지게 하기 위해서 다시 만들어 두었다.)

class ExpenseReporter {
    private val date: String
        get() = "9/12/2002"

    private lateinit var printer: ReportPrinter
    private val expenseReport = ExpenseReport()

    fun printReport(printer: ReportPrinter) {
        this.printer = printer
        expenseReport.calculateExpenses()
        printExpensesAndTotal()
    }

    private fun printExpensesAndTotal() {
        printHeader()
        printExpenses()
        printTotal()
    }

    private fun printExpenses() {
        for (expense in expenseReport.expenses) {
            printExpense(expense)
        }
    }

    private fun printExpense(expense: Expense) {
        printer.print(
            String.format(
                "%s\t%s\t$%.02f\n",
                if (isOverage(expense)) "X" else " ",
                expense.getName(), expense.amount / 100.0
            )
        )
    }

    private fun isOverage(expense: Expense) = (expense.type == Expense.Type.DINNER
            && expense.amount > 5000
            || expense.type === Expense.Type.BREAKFAST
            && expense.amount > 1000)

    private fun printTotal() {
        printer.print(String.format("\nMeal expenses $%.02f", expenseReport.mealExpenses / 100.0))
        printer.print(String.format("\nTotal $%.02f", expenseReport.total / 100.0))
    }

    private fun printHeader() {
        printer.print("Expenses " + date + "\n")
    }

    fun addExpense(expense: Expense) {
        expenseReport.expenses.add(expense)
    }
}

Step6 - OCP를 개선해보자

여기까지 잘 실행했다면 클래스가 꽤나 간결해진 것을 볼 수 있을 것이다.

// 출력을 담당하는 클래스
class ExpenseReporter {
    private val date: String
        get() = "9/12/2002"
    private lateinit var printer: ReportPrinter
    private val expenseReport: ExpenseReport = ExpenseReport()

    fun printReport(printer: ReportPrinter) {
        this.printer = printer
        expenseReport.calculateExpenses()
        printExpensesAndTotal()
    }

    private fun printExpensesAndTotal() {
        printHeader()
        printExpenses()
        printTotal()
    }

    private fun printExpenses() {
        for (expense in expenseReport.expenses) {
            printExpense(expense)
        }
    }

    private fun printExpense(expense: Expense) {
        printer.print(
            String.format(
                "%s\t%s\t$%.02f\n",
                if (expense.isOverage()) "X" else " ",
                expense.getName(), getRate(expense.amount)
            )
        )
    }

    private fun printTotal() {
        printer.print(String.format("\nMeal expenses $%.02f", getRate(expenseReport.mealExpenses)))
        printer.print(String.format("\nTotal $%.02f", getRate(expenseReport.total)))
    }

    private fun getRate(amount: Int) = amount / 100.0

    private fun printHeader() {
        printer.print("Expenses " + date + "\n")
    }

    fun addExpense(expense: Expense) {
        expenseReport.addExpense(expense)
    }
}

// 계산을 담당하는 클래스
class ExpenseReport {
    val expenses: MutableList<Expense> = ArrayList()
    var total = 0
    var mealExpenses = 0

    fun calculateExpenses() {
        for (expense in expenses) {
            addTotal(expense)
        }
    }

    private fun addTotal(expense: Expense) {
        if (expense.isMeal()) {
            mealExpenses += expense.amount
        }
        total += expense.amount
    }

    fun addExpense(expense: Expense) {
        expenses.add(expense)
    }
}

// 비용에 대한 도메인
class Expense(
    var type: Type,
    var amount: Int
) {
    enum class Type {
        DINNER,
        BREAKFAST,
        CAR_RENTAL
    }

    fun getName(): String {
        var name = "TILT"

        when (this.type) {
            Type.DINNER -> name = "Dinner"
            Type.BREAKFAST -> name = "Breakfast"
            Type.CAR_RENTAL -> name = "Car Rental"
        }
        return name
    }

    fun isMeal() = this.type == Type.BREAKFAST || this.type == Type.DINNER

    fun isOverage() = (this.type == Type.DINNER
            && this.amount > 5000
            || this.type === Type.BREAKFAST
            && this.amount > 1000)
}

우리는 이제 마지막으로, 새로운 Expense의 타입이 추가되었을 때 유연하게 확장할 수 있도록 각각에 대해 클래스로 분리하는 작업을 진행할 것이다.

먼저, 원활한 작업을 위해서 Expense의 클래스를 미리 abstract class로 바꾸어두자. (이렇게 하지 않으면, 아래에서 세부 클래스들을 만들 때 단축키를 사용할 수 없다.)

abstract class Expense(
    var type: Type,
    var amount: Int
)

그리고, 테스트 코드를 수정하는 작업을 진행해보자.

기존의 테스트 코드에서 비용 객체를 생성하기 위해 Dinner 타입을 넘겨준 부분을, 저녁에 대한 비용을 나타내는 새로운 클래스를 만들어주기 위해 새롭게 생성해준다.

// AS-IS
"printOneDinner" {
    report.addExpense(Expense(Expense.Type.DINNER, 1678))
    report.printReport(printer)

    printer.getText() shouldBe """
        Expenses 9/12/2002
         	Dinner	$16.78

        Meal expenses $16.78
        Total $16.78
    """.trimIndent()
}

// TO-BE
"printOneDinner" {
    report.addExpense(DinnerExpense(1678))
    report.printReport(printer)

    printer.getText() shouldBe """
        Expenses 9/12/2002
         	Dinner	$16.78

        Meal expenses $16.78
        Total $16.78
    """.trimIndent()
}

그럼, 우리는 이 테스트를 깨지지 않도록 만드는 것이 가장 중요하다. DinnerExpense라는 클래스를 새롭게 만들어주자.

(마치 TDD를 하는 것처럼, 테스트를 중점으로 하여 리팩터링을 진행하는 것이다.)

option + enter를 누르면 위와 같이 create class를 통해 만들어줄 수 있다.

같은 방법으로 나머지 타입에 대한 클래스도 만들어주자.

이미 클래스에서 어떤 타입인지 드러나고 있어, 인자로 type 조건을 넘겨주는 것이 어색하기 때문에 클래스 생성 후 change Signature를 통해 일괄적으로 제거해주었다.

class DinnerExpense(amount: Int) : Expense(Type.DINNER, amount) 

class BreakfastExpense(amount: Int) : Expense(Type.BREAKFAST, amount)

class CarRentalExpense(amount: Int) : Expense(Type.CAR_RENTAL, amount)

그럼, 테스트 코드 역시 아래와 같이 바뀌었을 것이다.

internal class ExpenseReportTest : StringSpec({
    lateinit var report: ExpenseReporter
    lateinit var printer: MockReportPrinter

    beforeTest {
        report = ExpenseReporter()
        printer = MockReportPrinter()
    }

    "printEmpty" {
        report.printReport(printer)

        printer.getText() shouldBe """
            Expenses 9/12/2002

            Meal expenses $0.00
            Total $0.00
        """.trimIndent()
    }

    "printOneDinner" {
        report.addExpense(DinnerExpense(1678))
        report.printReport(printer)

        printer.getText() shouldBe """
            Expenses 9/12/2002
             	Dinner	$16.78

            Meal expenses $16.78
            Total $16.78
        """.trimIndent()
    }

    "twoMeals" {
        report.addExpense(DinnerExpense(1000))
        report.addExpense(BreakfastExpense(500))
        report.printReport(printer)

        printer.getText() shouldBe """
            Expenses 9/12/2002
             	Dinner	$10.00
             	Breakfast	$5.00

            Meal expenses $15.00
            Total $15.00
        """.trimIndent()
    }

    "twoMealsAndCarRental" {
        report.addExpense(DinnerExpense(1000))
        report.addExpense(BreakfastExpense(500))
        report.addExpense(CarRentalExpense(50000))
        report.printReport(printer)

        printer.getText() shouldBe """
            Expenses 9/12/2002
             	Dinner	$10.00
             	Breakfast	$5.00
             	Car Rental	$500.00

            Meal expenses $15.00
            Total $515.00
        """.trimIndent()
    }

    "overages" {
        report.addExpense(BreakfastExpense(1000))
        report.addExpense(BreakfastExpense(1001))
        report.addExpense(DinnerExpense(5000))
        report.addExpense(DinnerExpense(5001))
        report.printReport(printer)

        printer.getText() shouldBe """
            Expenses 9/12/2002
             	Breakfast	$10.00
            X	Breakfast	$10.01
             	Dinner	$50.00
            X	Dinner	$50.01

            Meal expenses $120.02
            Total $120.02
        """.trimIndent()
    }
})

Step7 - 자식 클래스들에게 책임을 분리하자

각 클래스들을 만들어주었지만, 깡통 클래스이기 때문에 굉장히 부실하다.

우리의 Expense 클래스를 되돌아보자. 여기에서 각 함수들은 자식 클래스들로 내려가기에 좋아 보인다.

abstract class Expense(
    var type: Type,
    var amount: Int
) {
    enum class Type {
        DINNER,
        BREAKFAST,
        CAR_RENTAL
    }

    fun getName(): String {
        var name = "TILT"

        when (this.type) {
            Type.DINNER -> name = "Dinner"
            Type.BREAKFAST -> name = "Breakfast"
            Type.CAR_RENTAL -> name = "Car Rental"
        }
        return name
    }

    fun isMeal() = this.type == Type.BREAKFAST || this.type == Type.DINNER
    fun isOverage() = (this.type == Type.DINNER
            && this.amount > 5000
            || this.type === Type.BREAKFAST
            && this.amount > 1000)
}

이를 위해서, 각각의 함수를 자식 클래스들에게 넘겨주기 위해 control + t → push member down을 눌러주자.

그러면, 아래와 같이 Expense 클래스의 각 메서드들이 abstract 클래스로 변하게 된다.

abstract class Expense(
    var type: Type,
    var amount: Int
) {
    enum class Type {
        DINNER,
        BREAKFAST,
        CAR_RENTAL
    }

    abstract fun getName(): String
    abstract fun isMeal(): Boolean
    abstract fun isOverage(): Boolean
}

이제, 각각의 클래스들에게 가서 어울리는 행동을 할 수 있도록 수정해주자.

// AS-IS
class BreakfastExpense(amount: Int) : Expense(Type.BREAKFAST, amount) {
    override fun getName(): String {
        var name = "TILT"

        when (this.type) {
            Type.DINNER -> name = "Dinner"
            Type.BREAKFAST -> name = "Breakfast"
            Type.CAR_RENTAL -> name = "Car Rental"
        }
        return name
    }

    override fun isMeal() = this.type == Type.BREAKFAST || this.type == Type.DINNER
    override fun isOverage() = (this.type == Type.DINNER
            && this.amount > 5000
            || this.type === Type.BREAKFAST
            && this.amount > 1000)

}

// TO-BE
class BreakfastExpense(amount: Int) : Expense(Type.BREAKFAST, amount) {
    override fun getName(): String = "Breakfast"
    override fun isMeal() = true
    override fun isOverage() = this.amount > 1000
}

// 나머지도 동일하게 변경
class CarRentalExpense(amount: Int) : Expense(Type.CAR_RENTAL, amount) {
    override fun getName(): String = "Car Rental"
    override fun isMeal() = false
    override fun isOverage() = false
}

class DinnerExpense(amount: Int) : Expense(Type.DINNER, amount) {
    override fun getName(): String = "Dinner"
    override fun isMeal() = true
    override fun isOverage() = this.amount > 5000
}

또한, 여기에서 기존에 정의해주었던 Expense 클래스 내부의 Type이라는 enum class는 getName을 위해서 사용되었던 클래스이기 때문에 제거해도 무리가 없다. 지워주도록 하자. 마찬가지로 이전에 사용했던 command + F6 (Change Signature)를 사용하자. 이렇게 하면 자식 클래스에 가서 직접 제거해줄 필요가 없이 편하게 지울 수 있다.

여기까지 와서 테스트 코드를 한 번 돌려보도록 하자. 다 돌아갔다면 성공이다.

마무리

최종적으로 위와 같은 관계도를 가지는 것을 볼 수 있으며, 이전과 비교했을 때 코드 역시 훨씬 읽기 좋고 깔끔한 코드로 변경되었다.

뿌듯!

글이 굉장히 길어졌기도 하고, 실제로 리팩터링을 진행하는데도 꽤 오래 걸렸다.

이번 리팩터링의 핵심은, 어떻게 하면 안전하게 리팩터링을 할 수 있는지가 중점이 되었다.

처음에 원본 코드를 보았을 때는 코드의 설계 관점만 생각해서 수기로 클래스를 만들고 분리하는 일들을 많이 했었는데, 이번 리팩터링을 각 단계마다 천천히 진행하면서 느꼈던 건 Intellij 에서 생각보다 많은 기능을 지원해주고 있었다는 점이었다.

또한, 실무에서 리팩터링을 하다 보면 정말 많은 클래스에 대해서 반복적으로 같은 작업을 하는 것들이 많아서 복사 붙여넣기를 하느라 시간을 엄청 썼었는데, 앞으로는 기본으로 제공하는 기능을 먼저 찾아보고 써야겠다는 생각이 들었다. (잃어버린 내 시간들...)

그리고 무엇보다 중요한 건, 기능을 수정했을 때 불안하지 않도록 테스트 코드를 꼭 작성해야 한다는 점이다.

일을 진행하면서 코드 대신에 직접 수기로 QA를 하던 날들이 많았는데, 앞으로는 리팩터링 할 때 최대한 테스트 코드에 의존하여 수정하도록 습관을 들여야겠다. 단축키 연습도 열심히 해서 앞으로는 키보드로만 개발할 수 있도록... 노력해야겠다

[객체지향의사실과오해] 06 - 객체 지도

dolmeng2 — Sat, 20 Jan 2024 10:00:25 +0900

✔️ 객체 지도

프로그래머의 가장 큰 숙제는 '변화하는 요구사항에 얼마나 더 잘 대응할 수 있는가?' 이다.

예를 들어보자. 고양이 스낵바에 새로운 신입 셰프냥이 들어왔다. 신입 셰프냥은 아직 메뉴 숙지에 미숙해서 레시피를 다 외우지 못했다.

이때 손님냥이 알바냥에게 딸기라떼를 주문했고, 알바냥은 신입 셰프냥에게 딸기라떼를 만들라고 지시했다.

하지만 신입 셰프냥은 딸기라떼 레시피를 몰라서 어떻게 해야 할지 고민 중인 상황이라면, 어떤 행위를 할 수 있을까?

1. 수석 셰프냥에게 딸기라떼 만드는 방법 물어보기
2. 레시피 북을 참고하여 딸기라떼 만들기

먼저, 첫 번째 방법의 경우, 만약 딸기라떼의 레시피를 얻을 수는 있지만, 변화하는 요구사항에 대응할 수 없다.

만약 손님이 추가적으로 ‘엇, 근데 딸기라떼에 들어가는 우유를 두유로 바꿔주실 수 있을까요?’ 라고 말을 했을 때

신입 셰프냥은 또 다시 멘붕에 빠져 수석 셰프냥을 귀찮게 할지도 모른다.

반면에, 레시피 북을 보게 된다면 여러 가지 상황에 대비할 수 있다.

우유가 아닌 두유를 넣을 때의 비율, 딸기 시럽의 비율 등 더 정확한 정보를 담고 있기 때문이다.

이와 같이, 사용자의 요구사항은 변할 수밖에 없기 때문에 ‘딸기라떼를 만들어달라’는 기능 자체에 집중하는 것이 아닌, ‘다양한 재료들로 여러 메뉴를 만들 수 있는’ 구조 중심의 개발을 진행하는 것이 좋다.

✔️ 기능 설계 vs 구조 설계

사용자의 요구사항은 기능을 기반으로 하기 때문에 훌륭한 소프트웨어를 만들기 위한 충분 조건이 될 수 있다.

그러나, 훌륭한 구조는 훌륭한 소프트웨어를 만들기 위한 필요 조건이다.

탄탄한 구조를 가지고 있으면, 자연스럽게 새로운 기능을 안정적으로 빠르게 개발할 수 있기 때문이다.

(진흙탕에서 개발하는 게 쉬울까, 아니면 싱그러운 풀밭에서 개발하는 게 쉬울까?)

기능 기반으로 설계하게 되면, 각 기능들이 서로 밀접하게 관련이 있기 때문에

요구사항에 따라서 하나의 기능이 바뀌면 다른 기능들까지 영향을 받게 된다.

개발자는 늘 변화하는 요구사항에 대해 우리는 최대한 적은 비용으로 대응할 수 있도록 만드는 것이 숙명이다.

그리고 이를 위해서는 안정적인 구조가 꼭 필요하다.

✔️ 객체지향 세계 구축하기

먼저, 사용자에게 제공할 기능과, 기능을 담기 위한 구조를 준비해야 한다.
여기서 기능이란, 사용자의 목표를 만족시키기 위해 책임을 수행하는 시스템의 행위를 의미하며 대표적으로 '유스케이스 모델링' 이라는 기법을 사용할 수 있다.

반대로, 구조는 사용자나 이해 관계자들이 도메인에 대해 생각하는 개념과, 개념들과의 관계로 표현하는 것을 의미하며, 대표적으로 '도메인 모델링' 이라는 기법을 사용할 수 있다.

안정적인 재료 파밍하기 - 구조 설계

앞서 '도메인 모델링'이라는 말을 했는데, 도메인 모델링이라는 것이 뭘 의미하는 것일까?

이는 사용자가 프로그램을 사용하는 대상 영역에 관한 지식을 선택적으로 단순화하고 의식적으로 구조화한 형태를 말한다.

한마디로 정의하자면, '멘탈 모델'이라고도 할 수 있다.

정말 쉽게 예를 들어보자. 우리는 다음과 같은 문장들을 접했다고 생각해보자.

- 물건을 살 수 있다.
- 물건을 팔 수 있다.
- 물건을 팔면 돈을 벌 수 있다.
- 물건을 사기 위해서는 돈이 필요하다.
...

우리는 앞서 제시된 4가지의 문장을 보면, 자연스럽게 '상점' 과 같은 두루뭉실한 것들을 머릿속에 떠올릴 수 있다.

대상에 대해서 우리의 뇌는 구조화를 하여 생각을 한 것이며, 하나의 멘탈 모델을 그렸다고 볼 수 있다.

멘탈 모델은 크게 사용자 모델 / 디자인 모델 / 시스템 이미지 3가지를 포괄하도록 추상화한 소프트웨어 모델이다.

디자이너와 사용자는 직접 교류하지 않고, 오직 시스템을 통해서 서로 소통하게 된다.

우리가 객체지향을 사용하면 사용자들이 이해하고 있는 도메인의 구조와 최대한 유사하게 코드를 구조화할 수 있다.
물론, 이 말이 현실의 구조를 그대로 따라가야 한다는 것은 아니다. ‘모방’하는 것이 아닌, ‘은유’를 통해서 재창조를 진행하는 것이며,

현실 객체가 할 수 없는 행동이나 가지지 않는 특성들을 가질 수도 있다. (= 이를 ‘표현적 차이’, ‘의미적 차이’라고도 한다)

예를 들어, 우리가 코드를 설계할 때 '커피'라는 객체에게 무료인지 판단하는 기능을 부여해줄 수 있다.

class Coffee(
    val price: Int
) {

    fun isFree(): Boolean {
        return price == 0 
    }
}

하지만 실세계에서 커피가 무료인지 행동할 수 있는가? 없다. 우리는 객체지향 세계에서만 이를 재창조한 것이다.

즉, 우리는 사용자가 이해하고 있는 도메인의 모델을 은유하여 코드에 나타내는 것이 목표이며,

이러한 사용자 모델의 경우 비교적 변경될 가능성이 적기 때문에 도메인 모델로 나타냈을 때 안정적인 구조를 설계할 수 있게 된다.

(우리가 이해하고 있는 '커피'라는 개념이 갑자기 '치킨'으로 바뀌지 않는 것처럼.)

불완전한 재료 파밍하기 - 기능 설계

사용자들은 시스템을 통해서 달성하고 싶은 목표가 존재하며, 시스템은 이에 대한 기능들을 제공해야 한다.

이는 곧 사용자와 시스템 간의 상호작용을 만들며, 이러한 상호작용을 텍스트로 정리한 것이 바로 ‘유스케이스’이다.

사용자의 목표가 곧 유스케이스의 핵심이며, 유스케이스는 공통의 사용자 목표를 통해 강하게 연관된 시나리오의 집합이다.
- 마틴 파울로

위 문장을 보면, 왜 유스케이스가 '사용자 액터 다이어그램'이라고 불리는지 이해할 수 있을 것이다.

유스케이스의 가장 큰 핵심은 '사용자가 달성하고 싶은 목표'를 나타내는 것이기 때문이다.

유스케이스는 크게 다음과 같은 특징들을 가지고 있다.

1. 유스케이스는 사용자와 시스템 간의 상호작용을 보여주는 ‘텍스트’일 뿐이다.

2. 여러 시나리오들의 집합으로 구성될 수 있다.

3. 단순한 기능의 집합이 아닌, 문맥을 통해 어떠한 이야기를 제공해야 한다.

4. 사용자 인터페이스와 관련된 세부 정보를 포함하지 않는다. (자주 변경되는 요소를 제외하고, 행위에만 집중)

비슷하게, 내부 설계에 대한 정보 역시 드러내지 않는다.

유스케이스를 기반으로 객체를 변환하는 것은 창조일 뿐이며, 유스케이스를 통해 객체의 변화가 더 쉬워지는 것은 아니다.

유스케이스는 객체에 대해 어떠한 정보도 제공하지 않는다. 그저 도메인 모델에 대한 힌트 정도일 뿐이다.

✔️ 재료를 모아모아 - 기능과 구조를 통합하기

우리는 안정적인 구조를 도메인 모델로, 불안정한 기능을 유스케이스로 나타내는 방법을 알았다.

이제는 코드로서 객체들의 책임으로 분리를 해야 한다.

시스템은 사용자의 목표를 만족시키기 위해 협력하는 커다란 객체로 볼 수 있으며, 그 내부에는 더 작은 객체들로 쪼개질 수 있다.

시스템에 할당된 큰 책임이 작은 단위의 책임들로 분리되고, 필요한 메시지에 대해 식별해나가면서 객체들에게 책임을 할당할 수 있게 된다.

그리고, 이러한 객체들을 구현하기 위해 클래스를 추가하고, 속성과 함께 메서드를 추가하게 되면

시스템의 기능이 완성되어 나가는 모습을 볼 수 있을 것이다.

객체 설계는 요구사항을 식별하고 도메인 모델을 생성한 후,
소프트웨어 클래스에 메서드들을 추가하고,
요구사항을 충족시키기 위해 객체들 간의 메시지 전송을 정의하는 것이다.
- Larman (2001)

이러한 책임 주도 설계를 통해 유스케이스로부터 메시지와 사용자가 달성하려는 목표를,

도메인 모델로부터 안정적인 구조를 제공받아서 협력하는 객체들의 공동체를 만들어내게 된다.

앞서 얘기했던 내용에 대해 큰 그림을 그려보자면 다음과 같다.

도메인 모델을 중심으로 객체 구조를 설계하고, 유스케이스의 기능을 객체의 책임으로 분배하는 것이다.

그렇다면, 왜 도메인 모델을 기반으로 객체의 구조를 설계할까?

앞서 커피 예시를 들었던 것처럼, 도메인 모델을 구성하는 개념은 (정말 완전히 뒤엎는 게 아닌 이상) 안정적으로 유지되기 때문이다.

안정적으로 유지되는 이유는, 도메인 모델을 구성하는 개념들 사이의 관계는 비즈니스 규칙을 기반으로 하고 있기 때문이다.

시스템의 비즈니스 정책이 정말 크게 변하지 않는 한, 비교적 안정적으로 유지되기 때문에 전체적인 구조가 한 번에 흔들리지 않는다.

그리고, 우리는 이러한 것들을 객체지향을 사용하여 코드로서 잘 녹여내게 된다면,

코드의 변경으로서 역으로 도메인의 변경도 유추할 수 있기 때문에 (가역성, reversibility)

협업의 관점으로서, 그리고 유지 보수의 관점으로서도 큰 장점을 얻어갈 수 있게 된다.

[객체지향의사실과오해] 05 - 책임과 메시지

dolmeng2 — Wed, 10 Jan 2024 20:08:52 +0900

옛날에 책 읽으면서 작성했던 건데 오랜만에 글 올릴 겸... 시리즈 마무리는 하면 좋을 것 같아서 올리려고 한다 :D

✔️ 자율적으로 행동하는 객체

앞선 챕터에서 늘 강조했던 것처럼, 객체는 자율적으로 행동이 가능하다.

이때, 객체가 행동하는 유일한 이유는, 다른 객체로부터 요청을 수신했기 때문이다.

여기서 요청을 처리하기 위해 객체가 수행하는 행동을 ‘책임’이라고 하며, 자율적인 객체란 스스로의 의지와 판단에 따라서 각자 맡은 책임을 수행하는 객체를 의미한다. 객체가 자신에 의지에 따라서 책임을 자율적으로 수행한다는 게 무엇을 의미하는 걸까?

쉽게 생각하기 위해 다시 고양이 스낵바 예제를 꺼내보자.

고양이 스낵바의 인기가 폭발하면서 아침부터 많은 음료 제조 요청이 들어왔다.

이때 알바냥에 셰프냥에게 ‘카페라떼 10잔, 아메리카노 10잔’을 제조를 지시한 상황을 생각해보자.
셰프냥이 카페라떼를 먼저 만들고 아메리카노를 만들든, 아메리카노를 만들고 카페라떼를 만들든 상관이 없어진다. 그저 어떻게든 단순히 주문한 목록에 대해서 수행을 완료하기만 하면 되는 것이다.

하지만, 너무나도 바쁜 아침에 주문이 많이 들어온 알바냥이 잔뜩 심술이 난 나머지, 셰프냥에게 아메리카노 3잔을 만들고 카페라떼 5잔을 만든 다음에, 다시 아메리카노 7잔을 만들고 카페라떼 5잔을 만들어 달라고 했다 생각해보자.
이러한 요청은 셰프냥에 선택할 수 있는 자유를 지나치게 제한한 것이며, 자율적으로 책임을 수행할 수 없도록 만든 것이다.

물론, 역으로 너무 추상적이어도 좋지 않다.

손님냥이 주문한 아메리카노, 카페라떼 10잔씩을 단순히 커피 20잔을 만들어달라고 했다 생각해보자.

셰프냥은 수많은 커피 메뉴 중에서 어떤 커피를 만들어야 하는지 전혀 알 수 없게 된다.

즉, 우리는 어느 정도의 자율성을 보장할 수 있는 추상적인 책임을 주면서, 동시에 의도를 알 수 있도록 충분히 구체적이어야 한다.

이와 같은 자율적인 책임은 객체가 수행할 행위를 ‘어떻게’ 할지 지정하는 것이 아닌, ‘무엇’을 할지 지정해야 한다는 것이다.

객체는 다른 객체로부터 전송된 요청을 ‘수신’해야만 행동을 시작하며, 결국 외부로부터 어떠한 자극이 전달되면 본인에게 할당된 책임을 수행하기 시작하는 것이다. 우리는 이러한 자극을 ‘메시지’라고 부르며, 메시지는 객체가 행동할 수 있도록 만드는 유일한 방법이다.

✔️ 메시지와 메서드

하나의 객체는 메시지를 전송하여 다른 객체에 접근하며, 이때 메시지의 argument를 통해 처리를 위한 추가 정보를 제공할 수 있다.
즉, 하나의 메시지 전송은 메시지의 이름과 인자, 그리고 수신자의 조합이 된다.

메시지를 전달받았다면, 수신자는 본인이 책임질 수 있는 행동인지 확인한다.

해당 메시지에 대해서 어떻게 행동할지는 송신자도 알 수 없으며, 외부에 공개된 것은 단순히 메시지 자체일 뿐이다.

우리가 앞에서 이야기 했던 내용을 정리해보자면 다음과 같다.

1. 송신자는 메시지를 전송한다.
2. 수신자는 메시지를 받아 처리할 방법을 자율적으로 선택한다.

여기서, 수신자가 내부적으로 메시지를 처리하기 위해 선택하는 방법이 ‘메서드’이다.

기본적으로 객체는 본인이 처리할 수 있는지에 대한 여부를 확인하고, 처리가 가능하다면 어떤 식으로 처리할지 메서드를 선택하게 된다.

✔️ 다형성

다형성이란, 서로 다른 객체가 동일한 메시지에 대해서 다르게 반응하는 것을 의미한다. 이는 수신자가 메시지를 자유롭게 처리할 수 있기 때문에 (어떻게 처리할지 정해져 있지 않기 때문에) 생기는 특성이라고 볼 수도 있다.

예를 들어, 알바냥이 ‘아메리카노 10잔, 카페라떼 10잔’을 만들라는 주문을 전달했을 때 주방에서는 무슨 일이 일어날까?

수석 셰프냥은 뛰어난 실력으로 인해 커피를 만들 때 늘 아메리카노를 먼저 만들고, 라떼아트를 가득 담은 카페라떼를 만든다.
하지만, 신참 셰프냥은 그저 열심히 아메리카노랑 카페라떼를 만든다.

우리가 카페를 갔을 때를 생각해보자. 카페라떼에 라떼아트가 있든 말든, 그저 카페라떼는 카페라떼로 받아들일 것이다.

알바냥 입장에서도, 어떤 방법으로 커피를 만들든 그저 아메리카노 10잔과 카페라떼 10잔을 받으면 되는 것이다.

다형성의 개념에 대해서 다시 생각해보자.

다형성은, 동일한 역할을 수행할 수 있는 객체 사이의 ‘대체 가능성’을 의미하기도 한다.

예를 들어, 수석 셰프냥이 아파서 알바냥의 주문을 받지 못한다면?

신참 셰프냥이 나와서 충분히 커피 주문을 처리할 수 있게 되는 것이다.

어떤 셰프냥이든, 그저 커피만 만들 줄 알면 되는 것이니까!

이러한 다형성의 이점은, 수신자의 종류를 캡슐화를 할 수 있다는 것이다.

알바냥의 입장에서는 내부적으로 어떤 셰프냥이 요리를 하든 그저 ‘커피를 만들 줄 아는’ 고양이라면 충분히 협력할 수 있으며, 셰프냥이 아니더라도 점장냥이 나와서 커피를 만들어 낼 수도 있는 것이다. (물론, 고양이가 아니어도 된다. 그저 커피를 만들 줄만 알면 되는 것이다!)

다형성을 잘 활용하게 된다면 메시지에 대한 결합도를 낮출 수 있기 때문에,

유연하고 확장성과 재사용성이 높은 객체 지향의 특징을 만족할 수 있게 될 것이다.

✔️ 메시지의 힘

앞서 다형성이 모든 걸 책임지는 것처럼 말했지만, 실질적으로는 메시지가 송-수신자 사이의 결합도를 낮추기 때문에 만들어진 마법이었다.

생각해보자, 우리는 '커피를 만들어 줘' 라는 메시지를 통해서 두 고양이들이 소통한 것을 확인할 수 있었다.

송신자는 오직 메시지만 바라보고, 수신자 역시 메시지만 바라보며 유연하고 확장 가능하면서 재사용이 용이하도록 만드는 것이다.

기본적으로 코드를 작성할 때 많이 하는 실수가, 데이터를 위주로 생각하면서 협력이 아닌 객체 내부의 데이터 구조를 먼저 생각하고, 데이터 조작에 필요한 연산들을 나중에 고려하는 것이다. (필자는 이 대목에서 굉장히 찔렸다. 필요한 기능을 먼저 나열하고, 해당 기능에 짜맞추면서 코드를 작성하는 경우가 굉장히 많았으니까.)

이렇게 데이터 중심으로 설계를 하게 되면, 객체의 자율성을 저해시킨다. 내부, 외부에서 자유롭게 쓰이는 필드나 메서드가 생기게 되고, 이로 인해 외부에서 자유롭게 해당 데이터를 사용하게 되면서 객체가 자신의 의지에 따라서 판단하기 어려워지기 때문이다.

우리는 협력 관계에서 다른 객체에게 어떤 것을 제공하고, 어떤 것을 얻을 수 있는지 판단할 때 좋은 객체 지향적 설계를 할 수 있다.

즉, 결과적으로 나무를 보는 게 아니라 ‘협력 관계’ 라는 숲을 바라봐야 하는 것이다.

✔️ 책임 주도 설계

객체가 본인에게 할당된 책임을 수행해야 하는데, 본인에게 없는 정보가 필요하다면 외부 객체에게 메시지를 전송하여 물어봐야 한다.

예를 들어, 손님냥이 알바냥에게 샌드위치 10개를 사고 싶다고 말했는데, 재고가 2개밖에 없는 상황이라면?

나머지 8개의 샌드위치를 손님냥에게 주기 위해서는 얼마나 기다려야 하는지 알바냥이 가지고 있는 정보로는 알 수 없다.

이때, 알바냥은 샌드위치를 만드는 셰프냥에게 얼마나 기다려야 하는지 물어볼 수 있다.

게임 이미지를 참고하자면... 셰프냥은 아마 샌드위치 1개 만드는데 4초가 걸릴 테니 총 32초 정도가 걸릴 것이다 (?)

각 객체들이 적절한 책임을 가지고 있다면, 이러한 상황에서 어떤 객체에게 질의를 해야 할지 쉽게 판단할 수 있게 된다.

결과적으로 책임 주도 설계는 객체들 간의 주고받는 메시지를 기반으로 적절한 역할과 책임, 협력을 발견하는 것이다.
이때, 도움이 필요한 객체는 메시지를 결정하고, 해당 메시지를 처리하기에 적합한 객체를 선택할 수 있다.
메시지는 수신자가 해야 하는 책임을 결정한다.

What / Who 사이클

앞서 언급한 책임 주도 설계를 잘 활용하기 위하여, What-Who 사이클을 사용할 수 있다.

이는 객체 사이의 협력 관계를 설계하기 위해, 어떤 행위 (what)를 수행해야 하는지 결정한 다음, 누가 (who) 그 행위를 수행할 것인지 결정하는 것이다. 여기서 what은 메시지, who는 이를 처리할 객체이다.

중요한 점은, what을 먼저 설정함으로서 어떤 객체가 어떤 기능을 가지고 있는지 먼저 판단하지 않는다는 것이다. 내가 필요한 행위를 생각하고, 이에 대해 처리할 수 있는 객체를 선택한다는 점이다. 위와 같은 사이클을 반복하게 되면, 객체의 인터페이스를 구성할 수 있게 된다.

만약, 알바냥이 손님냥에게 질문을 들었을 때 아무 생각 없이 ‘흠… 나보다 오래 알바한 선배 알바냥이 알겠지?’ 라는 생각으로 선배냥에게 여쭤봤다고 생각해보자. 이는 메시지를 먼저 생각하지 않고, 선배 알바냥 (Who)에게 먼저 물어봤기 때문에 What/Who 사이클을 위반하게 된 것이다. 항상 목적을 먼저 생각하고, 이에 대한 객체를 할당하자.

묻지 말고 시켜라! (= 디미터의 법칙)

What / Who 사이클에서 What을 결정했다면, 어떤 객체가 이를 수신할지 모르기 때문에 해당 객체에 대해서 물어볼 수가 없다. 그저 내가 보낸 메시지를 잘 처리하겠지? 라는 믿음으로 메시지를 전송하게 될 것이며, 이로 인해 객체는 스스로 처리하는 방법을 고안할 수 있으니 자율성이 더 높아지게 된다.

또한, 해당 객체에 대한 구체적인 정보를 알 수 없기 때문에 유연성과 확장 가능성 역시 증가한다.

우리는 그저 메시지를 처리할 수 있는 객체를 찾을 뿐이니까!

메시지가 어떻게 해야 하는지 지시하지 말고, 무엇을 해야 하는지 요청하라.
메시지를 믿게 되면 자율적인 책임도 함께 따라오게 된다.

✔️ 객체 인터페이스

일반적으로 인터페이스는 다음과 같은 특징을 가진다.

- 내부 구조나 동작은 알 필요 없이 겉으로 드러나는 사용법으로 쉽게 사용이 가능하다.
- 내부 구조나 작동 방식을 변경하더라도 사용자에게 영향을 주지 않는다.
- 구체화된 대상이 변경되더라도 동일한 인터페이스를 제공하면 아무런 문제 없이 상호작용이 가능하다.

객체의 인터페이스는 객체가 수신할 수 있는 메시지의 목록으로 구성되기 때문에, 객체가 어떤 메시지를 수신하는지에 따라서 달라진다.
여기서 말하는 인터페이스는 외부에서 접근 가능한 것과, 내부에서만 접근 가능한 것으로 나누어지며,

이 둘의 차이는 메시지를 보낸 주체가 다른 객체인지, 객체 자기 자신인지에 따라서 달라진다.

객체의 책임은 자율적이다. 스스로가 결졍해야 한다.
객체는 메시지를 통해 서로 소통하며, 메서드를 통해 메시지를 어떻게 수행할지 결정한다.
객체는 인터페이스를 통해 이러한 메시지를 받을 수 있다.

✔️ 인터페이스와 구현의 분리

인터페이스의 3가지 원칙은 다음과 같다.
- 인터페이스는 추상적이어야 한다.
- 외부에서 사용할 필요가 없다면 최대한 노출하지 말아야 한다.
- 객체의 내부와 외부를 구현해야 한다.

여기서 말하는 객체의 내부가 무엇일까?
이는, 객체를 구성하지만, 외부에 공개된 인터페이스 (=공용 인터페이스)에 포함되지 않는 모든 것을 의미한다. 이를 곧 ‘구현’이라고 한다.
쉽게 말하면, 캡슐화를 통해 객체의 인터페이스를 제공하여, 구현체를 숨기라는 의미이다.

구체적인 것에 의존하지 않게 되면 변경에 더 유연하게 대응이 가능하며, 내부에서 무엇을 변경하든 외부에는 영향이 끼치치 않기 때문에 우리는 변화하는 객체 세상 속에서 더 좋은 설계를 진행할 수 있게 된다.

✔️ 객체의 자율성은 왜 이렇게 중요할까?

객체의 책임이 자율적일수록 협력 관계는 이해하기 쉬워지고, 유연하게 변경할 수 있게 되며, 이는 협력에 대한 전체 품질을 결정한다.

객체에게 구체적인 것을 지시하는 순간, 해당 협력 관계도 곧 복잡해진다.

앞서 예시를 들었던 알바냥이 셰프냥에게 커피를 만드는 순서까지 제어했던 것처럼, 불필요한 책임까지 안게 되는 것이다.

또한, 셰프냥이 커피 만드는 순서를 변경하더라도, 알바냥에게 아메리카노 10잔을 만드는 사실은 변함이 없기 때문에 외부에 불필요하게 영향을 끼치지 않게 된다. 내부에서 무엇을 하든 협력 관계는 그대로 유지된다는 것이다.

만약 셰프냥이 휴가를 갔다면?

아메리카노 10잔을 만드는 주체가 셰프냥이 아니라 다른 주체여도 된다.

자율적인 책임으로 인해서, 해당 행위를 수행할 수 있기만 하면 되기 때문이다.

또한, 객체의 책임이 자율적이면 객체의 존재 이유도 명확하게 표현될 수 있다.
자율적으로 수행하게 되면, 이는 곧 객체의 목적을 달성하는데 집중을 하게 되고, 곧 객체 자체가 목적을 달성하기 위해, 강하게 연관된 책임으로만 구성이 될 수 있다. (= 객체의 응집도가 높아진다!)

말이 길었지만, 결과적으로 객체의 책임이 자율적이게 되면 우리는 다음과 같은 이점들을 얻게 된다.

- 응집도가 올라간다.

- 결합도가 낮아진다.

- 캡슐화가 잘 이루어지게 된다.

- 인터페이스와 구현이 명확하게 분리된다.

- 유연성과 재사용성이 향상된다.

[JPA] @Embedded 사용 시 주의할 점, 레거시 코드 리팩터링하기

dolmeng2 — Sat, 16 Dec 2023 10:00:31 +0900

들어가기 전

너무 오랜만에 작성하는 블로그 글...! 최근에 사내에서 매우 많이 쓰이는 도메인에 대해서 리팩터링을 진행했었는데, 거기서 만났던 이슈들과 간단한 생각 기록을 블로그에 남기면 좋을 것 같아서 작성하고자 한다. 이미 팀 내에서 공유도 했었고, 동기들에게도 공유한 내용이기도 하고, 사실 별거 아닌 거라 그냥 간단하게만 정리할 예정이다.

문제 상황

리팩터링을 진행하고자 한 도메인은 우리 팀에서 매우 중요한 비즈니스 도메인 객체 중 하나였고, 이미 안정적으로 잘 운영되고 있지만 굉장히 옛날부터 레거시로 내려오고 있던 객체였기 때문에 신규 입사자가 보기에 좋은 코드가 아니라는 생각이 들었다.
사내 도메인인 만큼 그대로 가져올 수는 없지만, 비슷한 느낌으로 아래와 같이 세팅을 진행해보았다.

CREATE TABLE `student_group` (
  `id` bigint NOT NULL AUTO_INCREMENT,
  `name` varchar(255) DEFAULT NULL,
  PRIMARY KEY (`id`)
) ENGINE=InnoDB AUTO_INCREMENT=2 DEFAULT CHARSET=utf8mb3


CREATE TABLE `student` (
   `id` bigint NOT NULL AUTO_INCREMENT,
   `city` varchar(255) DEFAULT NULL,
   `county` varchar(255) DEFAULT NULL,
   `district` varchar(255) DEFAULT NULL,
   `age` int NOT NULL,
   `name` varchar(255) DEFAULT NULL,
   `group_id` bigint NOT NULL,
   PRIMARY KEY (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb3

간단하게 생각하면 학생의 그룹과 학생에 대한 테이블이고, 이에 대한 엔티티 매핑은 아래와 같았다.

@Entity
class Student(
    val name: String,
    val age: Int,
    group: StudentGroup
) {

    @Id
    @GeneratedValue(strategy = GenerationType.IDENTITY)
    val id: Long = 0L

    @ManyToOne
    @JoinColumn(name = "group_id", insertable = false, updatable = false)
    val group: StudentGroup = group

    @Column(name = "group_id")
    val groupId: Long = group.id

    @Column
    val city: String? = null

    @Column
    val county: String? = null

    @Column
    val district: String? = null
}

실제 도메인에서는 30개가 넘는 필드들이 있었으며, 굉장히 많은 일들을 하고 있는 객체였기 때문에 파악하기 쉽지 않은 객체였다.
나는 위의 엔티티를 보고, 다음과 같은 2가지 포인트에 집중하였다.

1. group이라는 엔티티를 이미 의존하고 있는데, 꼭 groupId라는 필드를 따로 두어야 할까?
2. 맥락상으로 연관이 있는 필드들은 @Embedded로 묶어두면 가독성이 올라가지 않을까?

먼저, 1번의 경우 JPA에 대한 의존성을 최대한 낮추고 싶었다. 이미 @JoinColumn으로 엔티티 직접 참조를 통해 의존성을 가지고 있음에도, @Column을 통해 간접 참조까지 가지고 있는 게 처음 본 사람의 입장에서는 인지 오류를 줄 수 있는 포인트라고 생각했었다. (또한, 현재는 group_id만 있지만 실질적으로 엔티티 참조를 가지고 있던 객체들이 모두 위와 같이 별도로 Id를 위한 필드들이 존재하고 있었다.) 언뜻 보면 group_id라는 컬럼이 2번 있는 것인가? 라는 오류를 줄 수 있을 것 같았다.

2번의 경우, 현재 위의 엔티티를 실질적으로 도메인 객체로 사용하고 있다 보니 굉장히 많은 비즈니스 로직에서 사용되는 객체였다. 그러나 수많은 필드 및 메서드들이 주석 없이 단순 필드명으로, 혹은 테이블 스키마에 작성된 커멘트 내용을 보고 파악을 진행하는 게 까다로웠다. (사실 Persistence Layer에 있는 엔티티가 여러 곳에서 도메인 객체로 쓰이는 것부터가 굉장히 어색하지만, 레거시라는 게 생각처럼 쉽게 리팩터링이 되는 부분이 아니었기에 우선 해당 부분에 대해서는 다음 기회에 고쳐나가고자 했다.)

아무튼, 2가지 포인트를 바탕으로 아래와 같이 리팩터링을 진행하고자 했다.

@Entity
class Student(
    val name: String,
    val age: Int,
    group: StudentGroup
) {

    @Id
    @GeneratedValue(strategy = GenerationType.IDENTITY)
    val id: Long = 0L

    @ManyToOne
    @JoinColumn(name = "group_id", insertable = false, updatable = false)
    val group: StudentGroup = group
    
    @Embedded
    val address: Address = Address.init()
}

@Embeddable
class Address protected constructor() {

  @Column
  val city: String? = null

  @Column
  val county: String? = null

  @Column
  val district: String? = null

  companion object {
    fun init(): Address {
      return Address()
    }
  }
}

단순 코드상으로는 정말 간단하다. 엔티티를 참조하고 있는 경우 간접 참조를 위한 논리적 FK 값을 제거하고, '주소'라는 도메인에 맞춰 Address라는 새로운 클래스를 정의하여 @Embedded, @Embeddable를 통해 리팩터링을 진행하였다.

처음에는 비즈니스 로직의 수정 없이, 단순히 클래스를 추가한 부분이기 때문에 아무 문제가 없을 것이라고 생각했었다.
그러나, 실제로는 매우 큰 2가지의 문제점이 존재했었는데, 이는 테스트 케이스로 한 번 살펴보자.

Case 1 - JPA 사용 시 옵션을 제대로 보자

먼저, 정말 간단하게 저장 및 조회하는 서비스 코드가 아래와 같이 존재한다고 생각해보자.

@Service
class StudentService(
    private val studentRepository: StudentRepository,
    private val groupRepository: StudentGroupRepository
) {

    fun saveGroup(name: String) {
        val group = StudentGroup(name)
        groupRepository.save(group)
    }

    fun saveStudent(group: StudentGroup, name: String, age: Int): Student {
      val student = Student(name, age, group)
      return studentRepository.save(student)
    }
}

그리고, 그룹을 저장하고 해당 그룹에 대해 학생을 저장하는 코드를 테스트 코드로 작성해보자.

@SpringBootTest
@TestConstructor(autowireMode = TestConstructor.AutowireMode.ALL)
@ActiveProfiles("test")
class StudentServiceTest(
    private val studentService: StudentService
) {

    @Test
    fun test() {
      val group = studentService.saveGroup("그룹")
      studentService.saveStudent(group, "학생", 20)
    }
}

위의 테스트 결과는 어떻게 나올까? 언뜻 보면 성공할 것 같다.

하지만, 실제로는 위와 같이 Field 'group_id' doesn't have a default value 라는 오류가 발생한다.
현재 재현할 때는 위 사진처럼 어떤 쿼리가 발생했는지 오류 메시지로 함께 나왔지만, 당시에는 default value가 없다는 오류만 발생했었기 때문에 바로 인지하지 못했다. (또한, 위 테스트 코드의 경우 비즈니스 로직이 없기 때문에 당연히 이런 흐름이 잘 보이지만, 내가 부딪혔던 상황에서는 그 사이에 비즈니스 로직이 너무 많아서 파악하기가 어려웠다.)

그래서 나는 처음에는 student를 저장할 때 student group이 영속화 되지 않은 객체가 넘어와서 (혹은 객체가 아예 null로 넘어와서) group id가 null로 나오는 것인지 고민했었다. 그래서 디버깅을 통해 student가 저장되는 시점의 group을 체크하였다.

하지만, 사진을 보면 당연하게도 group 정보와 id 값이 잘 있는 것을 확인할 수 있다.
그렇다면 뭐가 문제였을까 한참을 고민하다가, 선언되어 있는 Entity를 주의 깊게 살펴보니 바로 알아챌 수 있었다.

@JoinColumn(name = "group_id", insertable = false, updatable = false)

바로, insertable = false 옵션으로 인해 오류가 발생했던 것이었다.
정확하게 말하면, 스키마 상으로는 group_id가 NOT NULL로 지정되어 있던 상태에서, insertable = false로 인해 insert 시에 해당 컬럼을 제외하고 쿼리가 발생했기 때문에 오류가 발생했던 것이다.

여기서 내가 초래했던 실수는 다음과 같다고 생각한다.

1. 개발자가 작성한 Entity가 테이블 형상과 그대로 일치할 것이라 생각하고 테이블 스키마를 주의깊게 살펴보지 않은 점
2. 기존 레거시 코드를 그대로 옮겨야 잘 동작한다고 생각하고, 옵션에 대해 주의 깊게 살펴보지 않은 점.

1번의 경우, 다르게 생각하면 Persistence Layer인 Entity가 DB의 형상과 다르게 유지되면서 (사내에서는 flyway 같은 마이그레이션 툴을 사용하지 않는다.) 발생된 인지 오류였다. 필드가 당연히 nullable 하게 선언되어 있을 것이라고 생각했다.
2번의 경우, 사실 개인적으로 리팩터링을 진행하면서 조금만 수정해도 예상과 다르게 동작했던 점이 여러 번 있다 보니 '최대한 기존 코드를 유지해야겠다!'라는 마음 가짐에서 했던 행동이었다. 주의깊게 봤더라면 처음부터 이상한 점을 알아챌 수 있었을 텐데 부끄러울 정도로 명확한 내 실수 그 자체였다.

그렇다면, 지금까지는 어떻게 insert가 되었던 것일까?

@ManyToOne
@JoinColumn(name = "group_id", insertable = false, updatable = false)
val group: StudentGroup = group

@Column(name = "group_id")
val groupId: Long = group.id

내가 리팩터링을 하려고 했던 그 groupId라는 필드를 통해서 insert가 정상적으로 진행이 되고 있던 상태였다.
아마 코드를 처음 작성하신 분의 의도로는 (확실하지는 않지만) Spring data JPA를 사용할 때 메서드명을 통해 select를 많이 하는데, group이라는 도메인 대신에 id를 통해서 바로 값을 가져올 수 있도록 하기 위해 따로 분리하신 게 아닐까 싶다.

Unable to build Hibernate SessionFactory; nested exception is org.hibernate.MappingException: Column 'group_id' is duplicated in mapping for entity

또한, 둘 다 insert가 가능한 상태라면 위와 같이 오류가 발생하기 때문에 엔티티에 대해서는 insertable=false로 막아두신 걸로 추측된다.

이전에 작성했던 엔티티를 다시 롤백한 다음 테스트 코드를 돌려보자.

바인딩 파라미터 옵션을 켜고 확인해보면, group_id에 아이디 값이 제대로 들어간 것을 확인할 수 있었다.
위 문제를 해결하기 위해서는 엔티티 직접 참조 유지 + insertable = false를 사용하거나, 기존 형상을 유지하면 된다.

Case 2 - 알 수 없는 하이버네이트

사실 위 문제의 경우 비즈니스 로직 수행 후 금방 잡힐 수 있는 케이스였지만, 이번 케이스는 조금 신기한 경우이다.

fun findStudent(id: Long): Student {
    return studentRepository.findById(id).orElseThrow()
}

위와 같이 조회를 위한 비즈니스가 추가되었고, 실질적으로 아래와 같은 로직이었다고 생각해보자.

@Test
fun test2() {
    val group = studentService.saveGroup("그룹")
    val student = studentService.saveStudent(group, "학생", 20)
    val findStudent = studentService.findStudent(student.id)
    // 학생의 address 정보를 다른 api로 전달한다고 가정
    callExternalApi(findStudent.address)
}

fun callExternalApi(address: Address) {
    // 대충 address의 각 요소에 대해서 접근하여 호출한다고 가정
    println("address.city = ${address.city}")
    println("address.county = ${address.county}")
    println("address.district = ${address.district}")
}

이때, 위 코드는 어떤 문제가 발생할까?
당시 내가 이해했던 흐름으로는, address의 경우 기본값으로 Address.init()을 통해 빈 객체를 할당해주었기 때문에 실질적으로 city, county, district 값이 null인 address가 할당이 되었을 것이라고 생각했었다.

하지만, 실제로 위 코드의 경우 NPE가 발생하게 된다.
코틀린 같은 언어에서 NPE가 발생한다는 건 굉장히 주의깊게 살펴봐야 하는 부분이라서, 처음에는 매우 당황했었다.
또한, 비즈니스 로직에서 무조건 발생하는 게 아니라 분기에 따라서 발생한 로직이었어서 잘못하면 인지하지 못하고 배포를 나갔을 수도 있던 부분이라서 한 편으로는 지금 잡혀서 다행이라고 생각했었다... ㅎㅎ

아무튼, 실제로 디버깅을 통해 확인해보아도 위와 같이 address에 null이 들어간 것을 확인할 수 있었다.
Address 객체 자체를 non-nullable한 타입으로 설정하였는데 어떻게 NPE가 발생한 것일까?
처음에는 디컴파일을 통해, 뭔가 JPA의 내가 모르는 기능으로 인해 nullable한 타입으로 선언된다고 생각했었다.

하지만, 필드와 getter에 대해 모두 @NotNull 어노테이션이 붙어있는 것을 확인할 수 있었다.

처음 오류를 봤을 때 나의 심정...

처음에는 내가 코틀린을 잘못 알고 있는 건가 싶어서 막 구글링을 하다가 아래와 같은 이슈를 발견하였다.

[HHH-7610] - Hibernate JIRA

hibernate.atlassian.net

When all of the values in an @Embedded object are NULL, Hibernate sets the field in the parent object to null.
This can lead to NullPointerExceptions if not handled correctly.

요약: Embedded 객체의 모든 필드가 null이면 해당 객체도 null로 하이버네이트가 세팅을 한다.

가만히 생각해보면 JPA의 경우 리플랙션을 통해 객체를 세팅하니까, NotNull로 세팅하더라도 충분히 null로 세팅이 가능할 것 같다는 생각이 들었다. (사실 이부분을 직접 재현해보려고 했는데 생각보다 공수가 더 들어가서 우선 패스...)

아무튼, 이를 해결하기 위해 hibernate의 릴리즈 노트를 봤는데 해결책이 있었다! (5.1 version)

spring.jpa.properties.hibernate.create_empty_composites.enabled=true

바로, 위의 옵션을 true로 지정해주면 되는 것이었다.
궁금해서 하이버네이트 쪽을 살짝 찾아봤는데 다음과 같이 구현되어 있다.

public ComponentMetamodel(Component component, MetadataBuildingOptions metadataBuildingOptions) {
    ...
    
    final ConfigurationService cs = component.getMetadata().getMetadataBuildingOptions().getServiceRegistry()
            .getService(ConfigurationService.class);

    this.createEmptyCompositesEnabled = ConfigurationHelper.getBoolean(
            Environment.CREATE_EMPTY_COMPOSITES_ENABLED,
            cs.getSettings(),
            false
    );
}

public ComponentType(TypeFactory.TypeScope typeScope, ComponentMetamodel metamodel) {
	...
    this.createEmptyCompositesEnabled = metamodel.isCreateEmptyCompositesEnabled();
}

이렇게 create_empty_composites.enabled에 대한 옵션 정보를 통해서 플래그를 지정해주고...!

// 객체의 값 비교 로직 중 일부
// null value and empty component are considered equivalent
Object[] xvalues = getPropertyValues( x, entityMode );
Object[] yvalues = getPropertyValues( y, entityMode );

잘은 모르겠지만 null value and empty component are considered equivalent 라는 주석도 있었다.
(내부적으로 null 과 빈 객체가 동일하다고 판단하기 위함인 것 같다)

// 프로퍼티 가져올 때
public Object getPropertyValue(Object component, int i)throws HibernateException {
    if (component == null) {
        component = new Object[propertySpan];
    }
    ...
}

// resolve 할 때
@Override
public Object resolve(Object value, SessionImplementor session, Object owner) throws HibernateException {

    if ( value != null ) {
        Object result = instantiate( owner, session );
        Object[] values = (Object[]) value;
        Object[] resolvedValues = new Object[values.length]; //only really need new array during semiresolve!
        for ( int i = 0; i < values.length; i++ ) {
            resolvedValues[i] = propertyTypes[i].resolve( values[i], session, owner );
        }
        setPropertyValues( result, resolvedValues, entityMode );
        return result;
    }
    
    // 여기서 아까 옵션이 활성화 되어 있는 경우 정상적으로 초기화하도록!
    else if ( isCreateEmptyCompositesEnabled() ) {
        return instantiate( owner, session );
    }
    else {
        return null;
    }
}

그리고 빈 객체에 대해서 초기화가 가능하도록 되어 있다. (else if 분기)
원래였으면 else 문으로 인해서 null이 반환되었을 텐데, 저 분기 덕분에 빈 객체로 초기화가 가능하게 된 것이다.

아무튼, 위의 옵션을 적용해보고 돌려보면 다음과 같이 빈 객체가 잘 할당되는 것을 확인할 수 있다!

간단 회고

사실 주요 도메인인 만큼 신중하게 리팩터링을 진행했어야 했는데, 간단한 작업이라 큰 영향이 없을 것이라고 생각한 것이 문제였던 것 같다.

1. 무조건 엔티티에 작성된 것만 보고 의존하지 말자.

지금까지 개인 프로젝트를 했을 때는 테이블 세팅부터 내가 진행했다 보니까 자연스럽게 JPA 엔티티가 테이블의 형상을 그대로 따라간다고 생각했던 것 같다. 하지만, 현업에서는 이미 테이블이 세팅되어 있고, 테이블의 스키마가 변함에도 불구하고 엔티티가 업데이트 되지 않는 경우가 많다. 앞으로는 테이블 스키마부터 먼저 체크를 해봐야겠다.

2. 레거시라고 무조건 따라가지 말기

앞서 신중하자고 했지만, 무엇보다 레거시 코드를 그대로 믿고 따라가는 건 다른 레거시를 또 낳는 행동인 것 같다.
신중하게 영향 범위를 잘 파악해서 조금씩 리팩터링을 진행하는 게 가장 중요한 것 같다.
사실 이번 리팩터링은 규모가 커서 다시 롤백했지만... 1월에 다시 한 번 시도해볼 예정이다.

3. JPA의 러닝커브 고민해보기

사실 우리 팀의 경우 JPA의 기능을 제대로 활용하지 않는다. 정말 CRUD를 편하게 해주는 도구 그 이상, 그 이하도 아니게 사용하는 느낌?
예전에는 JPA가 무조건 좋다고 생각했는데, 회사를 입사하고 든 가장 큰 생각은 모두가 생각하는 지향점과 러닝 커브가 새로운 기술을 도입하고 어떠한 것을 사용할 때 가장 중요하다는 생각이 들었다. 사용할 거면 제대로 알아보고, 팀원 모두가 해당 지식에 대해 완벽하게 싱크가 되어 있을 때 사용하는 것이 좋을 것 같다.

JPA의 러닝커브를 생각해보았을 때, @ManyToOne 같은 JPA 종속적인 어노테이션을 많이 사용해야 하는가? 라는 의문점도 들고... 아마 다음 리팩터링 때는 @ManyToOne 같은 어노테이션을 제거하는 방향도 한 번 고려해볼 것 같다.
이번 @Embedded 케이스도 사실 팀 내에서 가장 익숙한 사람이 나였어서, 다시 사용하지 않는 방향으로 나아가는 걸 고민 중이다. (모두가 편하게 사용하는 게 가장 중요하니까)

오랜만에 블로그 글을 작성하다 보니 생각보다 시간도 많이 쓰였지만, 발표까지 했던 주제(...) 였던 것 만큼 개인적으로 정리해보고 싶었다. 내년부터는 다시 조금씩 블로그 글도 열심히 작성해야겠다... 파이팅!

[Redis] Redis는 언제 활용할 수 있을까? 1편 - 분산락 구현하기 (2)

dolmeng2 — Tue, 17 Oct 2023 09:24:08 +0900

들어가기 전

지난 포스팅에서는 레디스를 활용해 분산락을 구현하는 다양한 방법들을 살펴보았다.

이번 포스팅에서는 조금 더 색다른 방법으로 레디스를 활용하여 분산락을 구현해보고자 한다.

✔ Case 4 - Lua Script 활용하기

Redis 2.6 버전에서 루아 스크립트 엔진이 추가되면서, 레디스 서버에서 루아 스크립트를 실행할 수 있게 되었다.

레디스 내부에서는 EVAL (혹은 EVALSHA)이라는 명령어를 통해 사용할 수 있다.

EVAL script numkeys [key [key ...]] [arg [arg ...]]

만약 스크립트가 길어지게 된다면 스크립트 전체를 EVAL로 전송하기에는 네트워크 대역의 비용이 발생할 수 있기 때문에, 레디스에서는 SCRIPT LOAD 명령어를 통해 스크립트를 서버 측에 캐싱한 다음에, 캐싱 후 반환된 키를 활용해 EVALSHA로 스크립트를 관리할 수 있다.

(물론 이것도 마냥 좋은 건 아니고, 레디스 노드가 많아진다면 캐싱도 전체 노드에서 해야 하기 때문에 문제가 있을 수 있다.)

루아(Lua)는 일종의 프로그래밍 언어로, 절차지향적 언어이다. 사실 C, C++와 사용하는 경우가 많지만, 레디스에서 사용하게 되면 사용자가 레디스 명령어를 직접 작성할 수 있으며, 해당 스크립트가 실행되는 동안에는 원자성을 보장하게 된다.

이는 마냥 좋은 점은 아닌 게, 스크립트에 대한 실행 요청이 들어왔을 때 다른 레디스 명령어들은 실행이 불가능하기 때문에 스크립트의 실행 시간이 반드시 고려되어야 한다. 하나의 스크립트에 여러 레디스 명령어를 사용하면서 원자성을 보장하고 싶을 때 주로 사용한다.

override fun executeScript(key: String, value: String, duration: String, script: RedisScript<Boolean>): Boolean {
    return redisTemplate.execute(script, listOf(key), value, duration)
}

redisTemplate는 스크립트를 실행할 수 있는 execute() 메서드를 제공하고 있으며, 실제로 내부 구현체를 살펴보면 eval()을 사용하는 것을 볼 수 있었다. 아래의 코드를 이해할 필요는 없고, 그냥 eval을 사용하고 있구나... 정도로만 넘어가자!

또한, key의 리스트와 내부 스크립트에서 사용할 변수들을 가변 인자로 (args) 받을 수 있는 것을 확인할 수 있다.

아무튼, 이에 맞춰서 한 번 비즈니스 로직을 생성해보자.

@PostMapping("/withdraw-lua")
fun withdrawUsingLuaScript(@RequestBody request: WithdrawRequest): ResponseEntity<BalanceResponse> {
    val result = accountService.withdrawUsingLuaScript(request)
    return ResponseEntity.ok(result)
}

@Transactional
fun withdrawUsingLuaScript(request: WithdrawRequest): BalanceResponse {
    val accountId = request.accountId
    val accountKey = keyGenerator.generateAccountKey(accountId)
    // 파일로 로드해도 되지만 직관적으로 여기에 넣었다.
    val script = """
        local key = KEYS[1]
        local value = ARGV[1]
        local expiration = tonumber(ARGV[2])

        local existingValue = redis.call('GET', key)
        if not existingValue then
            redis.call('SET', key, value, 'EX', expiration)
            return true
        else
            return false
        end
    """.trimIndent()
    val redisScript = RedisScript<Boolean>(script)

    while (!cacheService.executeScript(accountKey, "account-withdraw", "5", redisScript)) {
        Thread.sleep(1000)
    }

    val account = accountRepository.getAccountById(accountId)
    account.subtractBalance(request.amount)

    // 캐시 제거
    cacheService.delete(accountKey)
    return BalanceResponse(account.id, account.balance)
}

스크립트의 경우 파일로 관리해도 되지만, 그렇게 길지 않기 때문에 문자열을 사용하여 바로 로드하였다.

local key = KEYS[1]
local value = ARGV[1]
local expiration = tonumber(ARGV[2])

local existingValue = redis.call('GET', key)
if not existingValue then
    redis.call('SET', key, value, 'EX', expiration)
    return true
else
    return false
end

내부 스크립트를 한 번 살펴보자.

KEYS를 통해 listOf(key)로 넘겨준 키의 첫 번째 값을 받아오고, ARGV를 통해 각각 인자로 넘겨준 변수를 사용한다.

이때, 숫자값을 사용하기 위해서 tonumber()를 활용할 수 있다.

내부 로직의 경우 GET을 통해 받아오고, 만약 값이 존재하지 않으면 SET을 통해 값을 지정하고, 아니면 false를 반환하는 간단한 로직이다. 사실상 앞서 Case 2번의 애플리케이션 레벨에서 진행했던 행위를 루아 스크립트를 통해서 원자성을 보장하도록 만들어준 것이다.

@Test
fun 루아스크립트를_통한_동시_출금요청() {
    // given
    val accountId = 계좌_생성()
    초기_잔액_설정(accountId, 100)
    val requestCount = 2

    // when
    // 동시에 20씩 출금을 요청함
    val executor = Executors.newFixedThreadPool(requestCount)
    val latch = CountDownLatch(requestCount)
    repeat(requestCount) {
        executor.submit {
            루아스크립트를_통한_출금_요청(accountId, 20)
            latch.countDown()
        }
    }

    latch.await()

    // then
    val balanceResponse = 잔액_조회(accountId)

    // 락으로 인해서 순차적으로 처리되기 때문에 정상적으로 60 반환
    assertThat(balanceResponse.balance)
        .isEqualTo(60)
}

 private fun 루아스크립트를_통한_출금_요청(accountId: Long, amount: Int): BalanceResponse {
    val withdrawRequest = WithdrawRequest(accountId, amount)

    return RestAssured.given()
        .log().all()
        .contentType(MediaType.APPLICATION_JSON_VALUE)
        .`when`()
        .body(withdrawRequest)
        .post("/accounts/withdraw-lua")
        .then()
        .log().all()
        .extract()
        .`as`(object : TypeRef<BalanceResponse>() {})
}

테스트 코드를 돌려보면 역시 잘 동작하는 것을 확인할 수 있었다.

✔ Case 5 - 스핀락 대신 pub-sub 구조 활용하기 (Redisson)

하지만, 앞선 방식들은 모두 스핀락을 사용하다 보니 락을 얻기 위해서 레디스 서버로 계속 요청을 보내야 한다는 부담이 있다.

또한, 앞선 예제들에서는 키에 대해 TTL도 걸어주고, 명시적으로 delete도 지정해주었기 때문에 크게 문제가 되지 않았지만, 개발자가 직접 스핀락을 구현하다 보니 만약 TTL을 빼먹거나, 키에 대한 삭제 처리를 진행하지 않으면 계속 락을 점유하는 문제가 발생할 수도 있다.

그래서, Lettuce 대신에 Redission에서 제공하는 분산락을 사용하여 이를 해결해보자.

Redisson의 경우 기본적으로 Pub-Sub 기반의 구조이기 때문에 계속 연결을 시도하지 않는다.

Publish-Subscribe (Pub-Sub) 구조는 Publisher와 Subscriber가 서로 알지 못해도 통신이 가능하도록 만들어진 패턴이다.
Publisher는 Subscriber에게 직접적으로 메시지를 보내지 않고, Channel에 publish를 진행하게 된다.
Subscriber는 관심이 있는 채널을 필요에 따라 Subscribe를 통해 메시지를 수신할 수 있다.

해당 채널을 Subscribe를 하고 있는 스레드들이 Publish된 메시지를 받아야 락 점유를 시도하기 때문에 비교적 부하가 덜하다.

레디스에서는 다음과 같이 명령어를 제공하고 있다.

// order라는 채널에 대해서 new-order라는 메시지 발행 예제
PUBLISH order new-order

// order, delivery라는 채널에 대해서 메시지 구독 예제
SUBSCRIBE order, delivery

publish 시 채널과 발행할 메시지를 입력하고, subscribe 시 구독하고 싶은 채널 이름을 나열하면 된다.

publish 후 성공적으로 메시지를 발행하면 1을 반환하고, 만약 아무도 구독하고 있지 않는 채널에 발행을 하면 0을 반환한다.

이를 코드로 구현하기 위해 다음과 같은 의존성을 추가해주도록 하자.

implementation("org.redisson:redisson-spring-boot-starter:3.23.5")

그리고, 비즈니스 로직을 작성해보자.

@PostMapping("withdraw-redisson")
fun withdrawUsingRedisson(@RequestBody request: WithdrawRequest): ResponseEntity<BalanceResponse> {
    val result = accountService.withdrawUsingRedisson(request)
    return ResponseEntity.ok(result)
}

@Service
class AccountService(
    // RedissonClient에 대해 의존성 주입 필요
    private val redissonClient: RedissonClient,
    private val accountRepository: AccountRepository,
    private val keyGenerator: KeyGenerator
) {

    @Transactional
    fun withdrawUsingRedisson(request: WithdrawRequest): BalanceResponse {
        val accountId = request.accountId
        val accountKey = keyGenerator.generateAccountKey(accountId)

        // 락 획득
        val lock = redissonClient.getLock(accountKey)
        try {
            val canLock = lock.tryLock(3, 5, TimeUnit.SECONDS)
            if (canLock.not()) {
                throw RuntimeException("락 획득에 실패하였습니다.")
            }
            val account = accountRepository.getAccountById(accountId)
            account.subtractBalance(request.amount)
            return BalanceResponse(account.id, account.balance)
            
        } finally {
            // 락 해제
            lock.unlock()
        }
    }
}

redissionClient에서는 getLock()이라는 메서드를 통해 인자로 넘겨준 이름을 가진 Lock instance를 생성한다.

이때, 스레드가 락을 획득하는 순서를 보장하지 않는다. (non-fair locking이라고 하는데, 조금 더 정확하게는 특정 스레드가 먼저 들어와서 오랫동안 락을 대기하고 있을 때, 새로운 스레드가 와서 요청을 보내면 옛날 스레드가 아니라 새로운 스레드가 락을 점유할 수 있다는 의미인 것 같다. 참고 링크)

이후, 가져온 인스턴스가 락을 획득할 수 있는 상황이라면 (tryLock) 점유하고, 아니라면 예외를 발생하도록 만들었다.

항상 락에 대한 해제 로직은 돌아야 하기 때문에 try-finally 구문을 통해 unlock을 꼭 해주도록 하자.

한 번 테스트 코드로 확인해보자.

@Test
fun 레디슨을_통한_동시_출금요청() {
    // given
    val accountId = 계좌_생성()
    초기_잔액_설정(accountId, 100)
    val requestCount = 2

    // when
    // 동시에 20씩 출금을 요청함
    val executor = Executors.newFixedThreadPool(requestCount)
    val latch = CountDownLatch(requestCount)
    repeat(requestCount) {
        executor.submit {
            레디슨을_통한_출금_요청(accountId, 20)
            latch.countDown()
        }
    }

    latch.await()

    // then
    val balanceResponse = 잔액_조회(accountId)

    // 락으로 인해서 순차적으로 처리되기 때문에 정상적으로 60 반환
    assertThat(balanceResponse.balance)
        .isEqualTo(60)
}

private fun 레디슨을_통한_출금_요청(accountId: Long, amount: Int): BalanceResponse {
    val withdrawRequest = WithdrawRequest(accountId, amount)

    return RestAssured.given()
        .log().all()
        .contentType(MediaType.APPLICATION_JSON_VALUE)
        .`when`()
        .body(withdrawRequest)
        .post("/accounts/withdraw-redisson")
        .then()
        .log().all()
        .extract()
        .`as`(object : TypeRef<BalanceResponse>() {})
}

아주 잘 돌아가는 것을 확인할 수 있다.

이대로 끝내면 아쉽기 때문에, 내부적으로 어떻게 pub-sub 구조를 통해 락을 획득하는지 확인해보자.

boolean tryLock(long waitTime, long leaseTime, TimeUnit unit) throws InterruptedException;

먼저, tryLock의 경우 내부적으로 3개의 인자를 받는다.

waitTime은 락을 사용할 수 있을 때까지 대기하는 시간, leaseTime은 락을 점유하는 시간, unit은 시간에 대한 단위이다.

이는 즉, leaseTime이 지나게 되면 자동으로 락이 해제되며, 이미 락을 점유하고 있는 스레드가 존재할 때 다른 스레드가 요청을 보내면 waitTime까지 대기한다는 의미이다.

tryLock의 내부 로직을 살짝 살펴보면 한 가지 흥미로운 점을 발견할 수 있는데, 바로 루아 스크립트를 활용한다는 점이다.

위와 같이 키의 존재에 대한 여부 확인 및 해당 키의 값에 대한 증가는 루아스크립트를 통해 진행하고 있었다.

락이 존재하지 않는다면 락에 대한 키와 스레드 아이디를 기반으로 값을 1 증가시키고, TTL을 설정하는 로직이다.

그리고, tryLock 메서드의 하단으로 내려가보면 아래와 같이 락에 대해 대기하는 로직이 나온다.

이때, subscribe 내부 로직을 보면 세마포어를 활용하고 있다.

앞서 말했던 것처럼, 멀티 스레드 환경인 스프링부트가 싱글 스레드 기반인 레디스를 호출하게 되면 동시성 문제가 발생할 수 있기 때문에, 세마포어를 활용해서 항상 하나의 스레드만 접근이 가능하도록 만들고 있는 것을 확인할 수 있다.

subscribe를 실패하면 (예외가 발생하면) false를 반환하며 로직을 종료한다.

이후, while문을 돌면서 남아 있는 시간 동안 락을 획득하기 위해 재시도를 진행한다.

여기서 tryAcquire()에 의해 반환되는 ttl 값은 현재 스레드가 점유를 시도하고 있는 락이 다른 스레드에 의해 언제 해제될지 나타내는 값을 (= 락이 얼마나 더 유지될지) 의미하며, null이라면 락을 획득할 수 있는 상태이기 때문에 true를 반환하게 된다.

만약 락 획득에 실패했다면 time (waitTime을 나타내며, 대기 시간을 의미한다)의 값을 갱신해주고, 갱신된 값이 만료되었다면 락 획득에 실패했다고 간주하여 false를 반환하게 된다.

이후, 아직 대기 시간이 남아 있는 상태라면 현재 시간을 다시 갱신한다.

만약 ttl (락에 대해 남은 유효 시간)이 0보다 크거나 같으면서 time (남은 대기 시간)보다 작으면 ttl 시간 동안 다시 락 획득을 대기하며, 그게 아니라면 남은 대기 시간 동안 기다리게 된다. (= 그냥 획득을 ttl, time만큼 대기하며 시도한다고 생각하기)

최종적으로 대기 시간인 time을 갱신하고, 만료되었다면 락 획득에 실패했다고 간주하고 false를 반환하게 된다.

그리고 마지막으로 이러한 락 획득 시도가 종료되면 unsubscribe를 통해 구독을 해제한다.

마찬가지로 구독 해제 시에도 이렇게 세마포어를 활용하는 것을 볼 수 있다.

마무리

레디스 관련해서 계속 써야지, 써야지 했는데 어쩌다 보니 계속 미루다가 이제서야 작성하게 되었다.

10월에는 글 2개 정도는 올리도록 노력해봐야겠다... 나태해진 나 반성해...

+ 무조건 레디스를 통해 분산락을 도입해야 한다고는 생각하지 않는다.

모든 기술의 도입에는 이유가 있어야 한다고 생각하기 때문에... 레디스를 활용하지 않더라도 얼마든지 동시성 제어는 가능하다.

앞으로 도입을 하게 된다면 무작정 도입하지 않고, 이러한 점들에 대해 trade-off를 잘 고민해봐야겠다

[Redis] Redis는 언제 활용할 수 있을까? 1편 - 분산락 구현하기 (1)

dolmeng2 — Tue, 17 Oct 2023 09:23:18 +0900

들어가기 전

조금 오래되긴 했지만 이전 포스팅에서 네임드락을 통한 분산락 구현을 진행하였다. 마지막 포스팅에서 레디스를 활용한다고 말했었는데, 계속 미루다가 이번에 레디스 공부를 하면서 간단하게 구현을 진행해보았다. 분산락에 대한 개념은 이전 포스팅에서 다루었기 때문에, 레디스를 이용해서 바로 분산락을 구현해보자. 또한, 지난 포스팅에서는 Jmeter를 활용하였지만, 이번 포스팅에서는 E2E 테스트를 통해 직접 구현을 해보고자 한다.

구현 상황

정말 간단하게 잔액을 의미하는 'Balance'라는 값에, 2개의 요청이 동시에 들어왔을 때 레디스를 통한 분산락을 구현하여 제어해보자.
위의 결과에서 최악의 상황이라면 Request 1, 2번 모두 80이라는 값을 반환하여 정상적으로 잔액이 갱신되지 않을 수 있다.
우리는 아래와 같은 플로우를 구현할 예정이다.

1. 공유 자원을 표현할 수 있는 이름을 생성하여 락의 키를 결정하기
2. NX 옵션을 통해서 해당 키가 존재하지 않는 경우에만 락을 획득하기
3. 이미 락을 획득 한 경우 nil을 반환하여 프로세스 대기하기
4. 자원의 작업이 끝나면 DEL을 통해 락 제거하기

여기서 NX와 DEL은 레디스에서 사용하는 명령어다.
NX는 'IF NOT EXISTS SET'과 같이, 키가 존재하지 않을 경우에만 SET을 해준다. 싱글 스레드로 동작하는 레디스에서 키가 존재하는지 판단하기 위해서는 GET으로 확인 후 SET을 해야 한다. 하지만 멀티 스레드 환경인 스프링 같은 곳에서 사용할 때 정합성 문제가 발생할 수 있기 때문에, 한 번에 중복을 체크하고 삽입까지 진행할 수 있도록 만들어진 명령어라고 생각하면 이해하기 쉽다.
DEL의 경우 쉽게 예상할 수 있듯, 'DELETE'를 의미하는 키 삭제 기능을 의미한다.

우리는 스핀 락 (Spin Lock) 방식을 통해 락을 점유하고 있는지 계속 확인하면서, 락을 잡을 수 있다면 락을 잡고 아니면 대기하는 방식으로 구현하고자 한다. 락에 대한 키를 계속 점유하지 않도록 키는 임계 영역을 빠져나온 후 제거를 해줘야 하며, 키 설정 시 TTL도 함께 걸어주는 것이 좋다.

구현하기 - 환경 구축

하단에 나온 설정들은 앞으로 redis 관련 포스팅을 할 때 계속 사용할 예정이기 때문에, 이번 포스팅에서만 환경 구축에 대해 작성하고자 한다.

implementation("org.springframework.boot:spring-boot-starter-data-redis")
implementation("org.springframework.boot:spring-boot-starter-data-jpa")
runtimeOnly("com.h2database:h2")
testImplementation("io.rest-assured:rest-assured")

먼저, 기본 구현을 위해 필요한 dependency들이다. (언어는 Kotlin으로 작성할 예정이다.)
스프링에서 제공하는 redis 및 jpa, 테스트 환경 구축을 위한 h2와 RestAssured를 추가해주자.

@Configuration
class RedisConfig {

    @Bean
    fun redisConnectionFactory(): RedisConnectionFactory =
        LettuceConnectionFactory()

    @Bean
    fun redisTemplate(): RedisTemplate<String, String> {
        return RedisTemplate<String, String>().apply {
            connectionFactory = redisConnectionFactory()
            keySerializer = StringRedisSerializer()
            valueSerializer = StringRedisSerializer()
        }
    }
}

이번엔 레디스 관련 설정 클래스를 만들어주자.
레디스 클라이언트 중 자바 기반 환경에서 대표적으로 뽑히는 Lettuce를 사용하였으며, 레디스에 저장될 key, value는 현재 스펙에서 모두 String을 사용하면 되기 때문에 StringRedisSerializer()를 사용해주었다. 취향에 맞게 커스텀을 해주면 될 것 같다.

class RedisService(
    private val redisTemplate: RedisTemplate<String, String>
) : CacheService {
    override fun delete(key: String) {
        redisTemplate.delete(key)
    }
}

또한, 캐시의 키를 제거해주는 함수를 미리 작성해두었다. (자주 사용될 예정이라 제일 상단으로 빼두었다.)

구현하기 - 서비스 로직

먼저, 계좌 정보를 저장하기 위해 간단한 도메인 객체를 만들어보자.

@Entity
class Account(

    @Id
    val id: Long = 0L
) {
    var balance: Int = 0

    fun addBalance(amount: Int) {
        balance += amount
    }

    fun subtractBalance(amount: Int) {
        balance -= amount
    }
}

계좌의 잔액을 추가해주는 메서드와, 제거해주는 메서드 2가지를 만들었다.

import org.springframework.data.jpa.repository.JpaRepository

fun AccountRepository.getAccountById(id: Long): Account {
    return findAccountById(id) ?: throw IllegalArgumentException("존재하지 않는 계좌입니다")
}

interface AccountRepository : JpaRepository<Account, Long> {
    fun findAccountById(id: Long): Account?
}

그리고 간단하게 아이디를 통해 계좌를 조회해주는 확장 함수를 만들었다.

개인적으로 확장 함수를 활용해서 위와 같이 예외를 터트리는 방식을 선호하는데, 어떤 아키텍처를 사용하는지에 따라서 예외를 발생시키는 부분도 달라질 것 같다. (요즘은 생각이 바뀌어서, 아마 다르게 구현하지 않을까 싶다)

interface KeyGenerator {
    fun generateAccountKey(accountId: Long): String
}

@Component
class KeyGeneratorImpl : KeyGenerator {
    override fun generateAccountKey(accountId: Long): String {
        return "$accountId:account"
    }
}

다음으로, 레디스의 키를 생성해주는 메서드를 추가해주었다.

키는 겹치지 않는 것이 제일 중요한데, 여기서는 계좌에 대한 고유 아이디 (PK) 값과 'account'를 알려주는 String을 추가해서 만들어주었다. 실제로는 어떤 기능을 개발할지에 따라서 키를 만드는 방법도 다양하기 때문에 유의해야 된다.

@RestController
@RequestMapping("/accounts")
class AccountController(
    private val accountService: AccountService
) {

    @PostMapping("/create")
    fun createAccount(): ResponseEntity<AccountResponse> {
        val result = accountService.create()
        return ResponseEntity.ok(result)
    }

    @PostMapping("/deposit")
    fun deposit(@RequestBody request: DepositRequest): ResponseEntity<BalanceResponse> {
        val result = accountService.deposit(request)
        return ResponseEntity.ok(result)
    }

    @GetMapping("/balance/{accountId}")
    fun getBalance(@PathVariable accountId: Long): ResponseEntity<BalanceResponse> {
        val result = accountService.getBalance(accountId)
        return ResponseEntity.ok(result)
    }

    @PostMapping("/withdraw")
    fun withdraw(@RequestBody request: WithdrawRequest): ResponseEntity<BalanceResponse> {
        val result = accountService.withdraw(request)
        return ResponseEntity.ok(result)
    }
}

data class DepositRequest(
    val accountId: Long,
    val amount: Int
)

data class WithdrawRequest(
    val accountId: Long,
    val amount: Int
)

data class AccountResponse(
    val accountId: Long
)

data class BalanceResponse(
    val accountId: Long,
    val balance: Int
)

class AccountService(
    private val accountRepository: AccountRepository,
    private val keyGenerator: KeyGenerator,
    private val cacheService: CacheService
) {

    @Transactional
    fun create(): AccountResponse {
        val account = Account()
        val savedAccount = accountRepository.save(account)
        return AccountResponse(savedAccount.id)
    }

    @Transactional
    fun deposit(request: DepositRequest): BalanceResponse {
        val accountId = request.accountId
        val account = accountRepository.getAccountById(accountId)
        account.addBalance(request.amount)
        return BalanceResponse(account.id, account.balance)
    }

    @Transactional(readOnly = true)
    fun getBalance(accountId: Long): BalanceResponse {
        val account = accountRepository.getAccountById(accountId)
        return BalanceResponse(account.id, account.balance)
    }

    @Transactional
    fun withdraw(request: WithdrawRequest): BalanceResponse {
        val accountId = request.accountId
        val account = accountRepository.getAccountById(accountId)
        account.subtractBalance(request.amount)
        return BalanceResponse(account.id, account.balance)
    }
}

그렇다면, 실제 API 호출을 위해 간단한 컨트롤러 + 서비스 코드를 만들어주었다.

계좌를 생성하고, 입금하고, 출금하고, 조회하는 기능이다.

이 기본 코드를 바탕으로 분산락 없이 한 번 테스트 코드를 작성해보자.

✔ Case 1 - 아무 락도 걸지 않았을 때

class AccountControllerTest : IntegrationTestHelper() {

    @Test
    fun 락_없이_동시_출금요청() {
        // given
        val accountId = 계좌_생성()
        초기_잔액_설정(accountId, 100)
        val requestCount = 2

        // when
        // 동시에 20씩 출금을 요청함
        val executor = Executors.newFixedThreadPool(requestCount)
        val latch = CountDownLatch(requestCount)
        repeat(requestCount) {
            executor.submit {
                출금_요청(accountId, 20)
                latch.countDown()
            }
        }

        latch.await()

        // then
        val balanceResponse = 잔액_조회(accountId)

        // 원하는 결과는 60이겠지만, 다른 값이 나옴
        assertThat(balanceResponse.balance)
            .isNotEqualTo(60)
    }

    private fun 계좌_생성(): Long {
        return RestAssured.given()
            .log().all()
            .contentType(MediaType.APPLICATION_JSON_VALUE)
            .`when`()
            .post("/accounts/create")
            .then()
            .log().all()
            .extract()
            .`as`(object : TypeRef<AccountResponse>() {})
            .accountId
    }

    private fun 초기_잔액_설정(accountId: Long, amount: Int): BalanceResponse {
        val depositRequest = DepositRequest(accountId, amount)
        return RestAssured.given()
            .log().all()
            .contentType(MediaType.APPLICATION_JSON_VALUE)
            .`when`()
            .body(depositRequest)
            .post("/accounts/deposit")
            .then()
            .log().all()
            .extract()
            .`as`(object : TypeRef<BalanceResponse>() {})
    }

    private fun 출금_요청(accountId: Long, amount: Int): BalanceResponse {
        val withdrawRequest = WithdrawRequest(accountId, amount)

        return RestAssured.given()
            .log().all()
            .contentType(MediaType.APPLICATION_JSON_VALUE)
            .`when`()
            .body(withdrawRequest)
            .post("/accounts/withdraw")
            .then()
            .log().all()
            .extract()
            .`as`(object : TypeRef<BalanceResponse>() {})
    }

    private fun 잔액_조회(accountId: Long): BalanceResponse {
        return RestAssured.given()
            .log().all()
            .`when`()
            .get("/accounts/balance/$accountId")
            .then()
            .log().all()
            .extract()
            .`as`(object : TypeRef<BalanceResponse>() {})
    }
}

우선, 아무 락도 걸지 않은 상태로 요청을 한다면 어떻게 될까? 위 테스트 시나리오는 다음과 같다.

1. 초기 잔액을 100으로 세팅한다.
2. 2개의 요청이 동시에 20씩 출금 요청을 진행한다.
3. 잔액을 조회했을 때 100 - 20 - 20 = 60이 나오기를 기대한다.

2개의 요청이 동시에 오고 있으며, 테스트 코드가 먼저 끝나는 것을 방지하기 위해 모든 요청이 종료될 때까지 await()으로 대기할 수 있도록 만들었다. 하지만, 테스트 코드를 보면 isNotEqualTo(60)으로, 60이라는 값이 나오지 않은 것을 볼 수 있다.

이는, 동시성 문제로 인해서 '20 출금하라'라는 요청이 동시에 오면서 첫 번째 요청, 두 번째 요청 모두 100 -> 80으로 출금을 진행했기 때문에 발생한 문제였다.

✔ Case 2 - 레디스의 get - set 활용하기

그렇다면, 레디스를 활용해 보면 어떨까?

우리는 초기에 구현 시나리오에서 '키가 존재하지 않을 경우 락을 획득하고, 존재하면 락을 획득할 때까지 대기'하도록 플로우를 구성하고자 했다. 간단하게 레디스를 활용해서 키가 존재하는지 확인하기 위해 get으로 가져오고, 존재하지 않는 경우에 set을 통해 락을 획득하는 로직을 작성해보자.

interface KeyGenerator {
    fun generateAccountKey(accountId: Long): String
}

@Component
class KeyGeneratorImpl : KeyGenerator {
    override fun generateAccountKey(accountId: Long): String {
        return "$accountId:account"
    }
}

먼저, 레디스의 키를 생성해주는 메서드를 추가해주었다.
키는 겹치지 않는 것이 제일 중요한데, 여기서는 계좌에 대한 고유 아이디 (PK) 값과 'account'를 알려주는 String을 추가해서 만들어주었다. 실제로는 어떤 기능을 개발할지에 따라서 키를 만드는 방법도 다양하기 때문에 유의해야 된다.

@Component
class RedisService(
    private val redisTemplate: RedisTemplate<String, String>
) : CacheService {
    override fun get(key: String): String? {
        return redisTemplate.opsForValue().get(key)
    }

    override fun set(key: String, value: String, duration: Duration) {
        redisTemplate.opsForValue().set(key, value, duration)
    }
}

다음으로, redisTemplate을 활용하여 String 값을 조회하고 설정하는 함수를 추가하였다.

둘 모두 opsForValues().set()과 opsForValues().get()을 활용하면 간단하게 구현할 수 있다.

set의 경우 해당 키가 언제까지 유효하도록 만들지 TTL 값을 설정해줄 수 있는데, Duration을 사용하여 원하는 만큼 지정해줄 수 있다. 보통 오래 걸리는 로직이 아니라면 30초 ~ 1분 정도로 설정하는 경우를 많이 본 것 같다.

@PostMapping("/withdraw-non-atomic-lock")
fun withdrawUsingNonAtomicLock(@RequestBody request: WithdrawRequest): ResponseEntity<BalanceResponse> {
    val result = accountService.withdrawUsingNonAtomicLock(request)
    return ResponseEntity.ok(result)
}

@Transactional
fun withdrawUsingNonAtomicLock(request: WithdrawRequest): BalanceResponse? {
    val accountId = request.accountId
    val accountKey = keyGenerator.generateAccountKey(accountId)

    while (true) {
        if (cacheService.get(accountKey) == null) {
            cacheService.set(accountKey, "account-withdraw", Duration.ofSeconds(5))
            break;
        }
        Thread.sleep(1000)
    }

    val account = accountRepository.getAccountById(accountId)
    account.subtractBalance(request.amount)

    // 캐시 제거 - TTL을 짧게 잡기는 했지만 명시적으로 제거함
    cacheService.delete(accountKey)
    return BalanceResponse(account.id, account.balance)
}

그리고, 실질적인 비즈니스 코드를 작성해주었다.

먼저, get()을 통해서 키가 존재하는지 확인한 다음, 존재하지 않는다면 set을 해주고, 존재하는 경우 1초씩 대기하며 재시도를 진행한다.

참고로, set을 통해 세팅해주는 value 값은 자유롭게 설정해주어도 된다. (의미없는 String 값도 상관없다.)

중요한 건, 다른 비즈니스 로직과 키만 겹치지 않도록 만들어 주는 것이 중요하다.

추가적으로, Facade 패턴 등을 도입해서 락을 얻고 반환하는 로직은 추상화할 수 있다.
이번에는 레디스를 중심으로 적용하다 보니 이에 대해 따로 고려하지 않았지만, 지난 포스팅에서 퍼사드 패턴을 활용했기 때문에 해당 내용을 참고하여 리팩터링 해도 좋을 것 같다는 생각이 든다.

우리가 원하는 로직대로 작성했기 때문에, 이제 결과값으로 60이 나오지 않을까?

@Test
fun 단순_락을_이용한_동시_출금요청_원자성을보장하지않음() {
    // given
    val accountId = 계좌_생성()
    초기_잔액_설정(accountId, 100)
    val requestCount = 2

    // when
    // 동시에 20씩 출금을 요청함
    // 캐시를 사용하긴 했지만 완전히 원자성을 보장하지 않는 로직
    val executor = Executors.newFixedThreadPool(requestCount)
    val latch = CountDownLatch(requestCount)
    repeat(requestCount) {
        executor.submit {
            락을_통한_출금_요청(accountId, 20)
            latch.countDown()
        }
    }

    latch.await()

    // then
    val balanceResponse = 잔액_조회(accountId)

    // 마찬가지로 원하는 결과는 60이겠지만, 다른 값이 나옴
    assertThat(balanceResponse.balance)
        .isNotEqualTo(60)
}

private fun 락을_통한_출금_요청(accountId: Long, amount: Int): BalanceResponse {
    val withdrawRequest = WithdrawRequest(accountId, amount)

    return RestAssured.given()
        .log().all()
        .contentType(MediaType.APPLICATION_JSON_VALUE)
        .`when`()
        .body(withdrawRequest)
        .post("/accounts/withdraw-non-atomic-lock")
        .then()
        .log().all()
        .extract()
        .`as`(object : TypeRef<BalanceResponse>() {})
}

하지만, 예상과 다르게 여전히 isNotEqualTo()를 통해 60이 나오지 않은 것을 볼 수 있다. 왜 이럴까?

사실, 앞에서 이미 답을 냈다.

우리의 스프링 애플리케이션은 멀티 스레드 기반이기 때문에, 레디스가 싱글 스레드로 동작한다고 해도 하나의 스레드가 get - set을 하는 중간에 다른 스레드가 get을 충분히 할 수 있는 상황이 만들어졌기 때문이다.

그림으로 보면 다음과 같은 상황이다. 레디스 내부에서 싱글 스레드로 열심히 명령어를 처리하더라도, 애플리케이션 레벨에서 들어오는 요청들은 여러 스레드가 동시에 들어오기 때문에 20, 20씩 출금하라는 요청이 적용되지 않았던 것이다.

그렇다면, GET - SET을 동시에 하도록 = 원자성을 보장하도록 만들 수 없을까?

바로, 앞서 말했던 것처럼 NX을 사용하면 된다.

✔ Case 3 - 레디스의 NX 활용하기

override fun setNX(key: String, value: String, duration: Duration): Boolean {
    return redisTemplate.opsForValue().setIfAbsent(key, value, duration) ?: false
}

NX의 경우 redisTemplate에서 제공하는 setIfAbsent()를 사용하면 된다.

우리가 애플리케이션 레벨에서 GET을 통해 키가 존재하는지 확인하고, SET을 통해서 값을 세팅해주는 과정을 레디스 내에서 만든 명령어라고 생각하면 된다. 만약 키가 이미 존재해서 값을 세팅하지 못했다면 false를, 키가 존재하지 않아서 값을 세팅했다면 true를 반환한다.

@PostMapping("/withdraw-atomic-lock")
fun withdrawUsingAtomicLock(@RequestBody request: WithdrawRequest): ResponseEntity<BalanceResponse> {
    val result = accountService.withdrawUsingAtomicLock(request)
    return ResponseEntity.ok(result)
}

@Transactional
fun withdrawUsingAtomicLock(request: WithdrawRequest): BalanceResponse {
    val accountId = request.accountId
    val accountKey = keyGenerator.generateAccountKey(accountId)

    while (!cacheService.setNX(accountKey, "account-withdraw", Duration.ofSeconds(5))) {
        Thread.sleep(1000)
    }

    val account = accountRepository.getAccountById(accountId)
    account.subtractBalance(request.amount)

    // 캐시 제거
    cacheService.delete(accountKey)
    return BalanceResponse(account.id, account.balance)
}

실제 비즈니스 로직에 적용해보자. setNX를 통해 true, false 값을 반환하기 때문에 값을 세팅하지 못했을 경우 1초씩 대기하도록 while문을 통해 쉽게 제어할 수 있게 되었다.

그렇다면, 테스트 코드를 통해 결과를 확인해보자.

@Test
fun 분산락을_통한_동시_출금요청() {
    // given
    val accountId = 계좌_생성()
    초기_잔액_설정(accountId, 100)
    val requestCount = 2

    // when
    // 동시에 20씩 출금을 요청함
    val executor = Executors.newFixedThreadPool(requestCount)
    val latch = CountDownLatch(requestCount)
    repeat(requestCount) {
        executor.submit {
            분산락을_통한_출금_요청(accountId, 20)
            latch.countDown()
        }
    }

    latch.await()

    // then
    val balanceResponse = 잔액_조회(accountId)

    // 락으로 인해서 순차적으로 처리되기 때문에 정상적으로 60 반환
    assertThat(balanceResponse.balance)
        .isEqualTo(60)
}

private fun 분산락을_통한_출금_요청(accountId: Long, amount: Int): BalanceResponse {
    val withdrawRequest = WithdrawRequest(accountId, amount)

    return RestAssured.given()
        .log().all()
        .contentType(MediaType.APPLICATION_JSON_VALUE)
        .`when`()
        .body(withdrawRequest)
        .post("/accounts/withdraw-atomic-lock")
        .then()
        .log().all()
        .extract()
        .`as`(object : TypeRef<BalanceResponse>() {})
}

드디어 우리가 원하는대로 60을 반환하는 것을 확인할 수 있다!

하지만 이대로 끝내기에는 뭔가 아쉽기 때문에, 조금 더 귀찮은 방법으로 원자성을 보장하는 방법을 소개해보고자 한다.

글이 생각보다 너무 길어져서 1, 2부로 나누어서 작성하였습니다.

다음 포스팅: https://cl8d.tistory.com/125

[JPA] JPA Auditing과 em.merge()의 동작 원리 살펴보기 - 테스트에서 id 값을 주의하자

dolmeng2 — Sun, 10 Sep 2023 13:44:28 +0900

들어가기 전

옛날에 썼던 글인데, 요즘 블로그를 너무 안 쓴 것 같아서 오랜만에 올리는 글

혼자 공부할 겸 작성한 글이었어서 다소 설명이 부족합니다...!

엔티티 소개

@Entity
@EntityListeners(AuditingEntityListener.class)
public class User {

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

    @Column(nullable = false)
    @CreatedDate
    private LocalDateTime createdAt;

    @LastModifiedDate
    private LocalDateTime updatedAt;

User 클래스는 사용자에 대한 엔티티이며, id 전략은 IDENTITY이다.

이때, createdAt, updatedAt에 대해서 JPA auditing 기능을 사용한 것을 볼 수 있다.

우리는 사용자 엔티티에 대한 저장을 위해서 간단한 테스트 코드를 작성해볼 예정이다.

public class UserTest {
    public static final User JAVAJIGI = new User(1L, "javajigi", "password", "name", "javajigi@slipp.net");
    public static final User SANJIGI = new User("sanjigi", "password", "name", "sanjigi@slipp.net");
}

요 클래스는 테스트에서 사용할 간단한 픽스처이다.

여기서 JAVAJIGI에 대해서는 id 값이 초기화가 되어 있고, SANJIGI 변수에 대해서는 id 값이 초기화 되어 있지 않은 상태임을 유의하자.

문제 상황

@Test
@DisplayName("유저를 저장한다.")
void save1() {
	final User actualUser = userRepository.save(UserTest.JAVAJIGI);

	assertThat(actualUser).usingRecursiveComparison()
		.ignoringFields("id")
		.isEqualTo(UserTest.JAVAJIGI);
}

@Test
@DisplayName("유저를 저장한다.")
void save2() {
	final User actualUser = userRepository.save(UserTest.SANJIGI);

	assertThat(actualUser).usingRecursiveComparison()
		.ignoringFields("id")
		.isEqualTo(UserTest.SANJIGI);
}

사용자를 저장하는 2개의 테스트를 작성하였다.

단순히 사용자를 저장하는 테스트임에도, 첫 번째 메서드의 테스트에서는 아래와 같이 오류가 발생하였다.

오류 상황을 보면, User 엔티티의 createdAt, updatedAt의 값이 채워져 있지 않아 발생한 것을 볼 수 있다.
save()를 진행하게 되면 영속성 컨텍스트의 관리에 의해서 UserTest의 JAVAJIGI 변수와 actualUser가 같은 객체를 바라보고 있어서 auditing에 의해 User 엔티티의 값이 업데이트가 되면 JAVAJIGI 변수의 값도 업데이트가 될 줄 알았는데 그렇지 않았던 것이다.

JPA Auditing의 동작 원리 살펴보기

처음에는 Auditing에 대해 문제라고 생각이 들어서, 디버깅을 통해 언제 값이 채워지는지 살펴보기로 했다.

먼저, Auditing 시 동작하는 AuditingEntityListener 클래스의 touchForCreate() 메서드를 확인해보자.

위 메서드에서 인자로 target 값에 JAVAJIGI가 들어온 것을 볼 수 있다.

아직 auditing이 동작하지 않았기 때문에 createdAt, updatedAt 모두 null 값으로 채워진 것을 볼 수 있다.

object.markCreated() 메서드로 타고 들어가보자.

첫 번째 라인에서 target의 값으로 JAVAJIGI가 들어와서 어떠한 Wrapper 객체를 생성한 것을 볼 수 있다.

그리고, 날짜에 대한 auditing을 위해 touchDate() 메서드로 제어를 이동해서 살펴보자.

코드를 보면 touchAuditor를 통해 auditor에 대한 정보가 필요하면 채워넣게 되며 (@CreatedBy 같은 어노테이션을 사용할 때 동작하는 듯하다.) 우리 코드에서는 필요가 없기 때문에 바로 touchDate() 메서드로 한 번 이동해보자.

첫 번째 라인에서 현재 시간을 가져온 다음, wrapper::setCreatedDate, wrapper::setLastModifiedDate를 통해서 JAVAJIGI의 값을 채워넣는 것을 볼 수 있다!

실제로, target인 JAVAJIGI에 시간 관련 필드가 채워져 있는 것을 확인할 수 있었다.

JPA의 save는 어떻게 동작할까?

그렇다면 정말 이상하다. auditing까지 정상적으로 동작했음에도 불구하고 왜 createdAt, updatedAt이 null이었던 것일까?

이를 알아보기 위해서 JPA의 save() 메서드를 한 번 눈여겨 볼 필요가 있다.

기본적으로 userRepository.save() 메서드가 호출되면, isNew()라는 어떠한 메서드를 통해 새로운 객체인지 판단한다.

만약 새로운 객체라면 persist 후 기존의 엔티티를 반환하고, 그렇지 않으면 merge 후 "새로운 객체를 반환" 한다는 것이다.

여기서 힌트를 얻었다. 혹시 새로운 객체를 반환하면서 null로 된 것이 아닐까?

그래서, 새로운 객체를 판단하는 기준을 살펴보았다.

기본적으로 id (@Id 어노테이션이 붙어있는 필드)가 primitive 타입이 아니라면 null 여부를 통해 새로운 객체임을 판단하고,

primitive 타입 중 Number 타입이라면 값이 0L인지 체크하여 새로운 객체인지를 판단하게 된다.

@Entity
@EntityListeners(AuditingEntityListener.class)
public class User {

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

우리가 설계했던 엔티티는 어땠을까?

User 엔티티의 아이디는 Long이고, ReferenceType이기 때문에 null이 아닌 1L을 가지게 되면 isNew() 메서드에서 false를 반환하게 된다. 그렇기 때문에, DB에 데이터가 존재하든 말든 persist가 아닌 merge() 를 진행하게 된 것이었다!

실제로, em.merge() 메서드를 타고 들어가다 보면 아래와 같이 MergeEventListener에 대한 이벤트가 발생하는 것을 볼 수 있다.

여기서 MergeEventListener::onMerge 메서드를 타고 들어가다 보면, entityState 라는 변수에 ‘DETACHED’라는 값이 들어간다.
우리는 이전에 JAVAJIGI 엔티티를 저장하거나 하지 않았음에도 id를 지정했기 때문에 분리된 상태라고 판단하게 된 것이다.

그리고, entityIsDetached() 메서드를 또 타고 들어가면 위와 같은 부분을 만날 수 있다.

Transient한 상태의 엔티티를 저장하는 것처럼 보이는데, 내부적으로 파고 들어가보자.

그러면 위와 같이 callbackRegistry.preCreate() 라는 메서드를 호출하는 것을 볼 수 있다.

해당 메서드를 내부적으로 타고 들어가다 보면, 등록된 콜백 메서드에 대해서 순회하며 하나씩 콜백 메서드를 실행한다.

이때, 인자로 넘겨주는 bean의 경우 createdAt, updatedAt이 채워지지 않은 상태의 JAVAJIGI 객체 정보이다.

여기서 callback을 확인해보면 User 엔티티에서 설정했던 AuditingEntityListener가 실행된 것을 볼 수 있다.

또한, 콜백타입 역시 PRE_PERSIST로 설정이 되어 있는데, 이건 무엇을 뜻하는 것일까?

바로, 위에서 봤던 JPA Auditing 기능에서 존재했던 touchForUpdate() 메서드 위에 달려있던 어노테이션이었던 것이다.

즉, 정리하자면 save() → em.merge() 동작 → merge 이벤트 시 JPA Auditing 동작 → 필드 채워짐 순서로 동작하게 되는 것이다.

아니, 그래서 테스트는 왜 깨진 건데요?

다시 돌아가서, em.merge()가 수행될 때 호출되는 fireMerge() 메서드를 보자.

앞서 언급했지만, JPA에서 save 시 isNew()가 false라면 em.merge()가 수행된 결과값을 save에서 반환한다.

우리의 텍스트 픽스처 JAVAJIGI의 경우 id의 타입이 레퍼런스 타입인 Long이었으며, 1L로 채워져있기 때문에 isNew()에서 false가 반환되었던 상태이다.

이 메서드에서는 event.getResult() 라는 값이 반환되는데, result에서는 createdAt, updatedAt 값이 채워진 객체가 반환된다.

하지만, 여기서 중요한 건 원본 객체 (텍스트 픽스처인 JAVAJIGI)와 반환되는 객체가 아예 다른 객체라는 것이다.

original의 경우 User@8627이었으나, result의 경우 User@8631으로, 아예 다른 객체를 반환하고 있는 것을 볼 수 있다.

@Test
@DisplayName("유저를 저장한다.")
void save1() {
	final User actualUser = userRepository.save(UserTest.JAVAJIGI);

	assertThat(actualUser).usingRecursiveComparison()
		.ignoringFields("id")
		.isEqualTo(UserTest.JAVAJIGI);
}

우리의 테스트 코드에서는 save로 반환된 객체와 JAVAJIGI가 아예 다른 객체가 된 것이고, save로 인해 기존의 JAVAJIGI 엔티티의 값을 변경할 것이라는 예상과 다르게 '값이 채워진 상태의 새로운 객체를 만들어 반환'했기 때문에 오류가 발생한 것이다.

즉, JAVAJIGI의 createdAt, updatedAt은 그대로 null이고, auditing은 새로운 객체에서 진행하게 되어 값이 채워져 반환된 것이다.

@Test
@DisplayName("유저를 저장한다.")
void save1() {
	final User actualUser = userRepository.save(UserTest.JAVAJIGI);

	assertThat(entityManager.contains(UserTest.JAVAJIGI))
		.isFalse();

	assertThat(entityManager.contains(actualUser))
		.isTrue();
}

또한, 기존의 JAVAJIGI 객체는 영속성 컨텍스트에서 관리되지 않고 merge 이후 새롭게 반환받은 객체가 영속성 컨텍스트에서 관리되는 것을 확인할 수 있다.

그렇다면, save2()에서는 어떻게 동작했을까?

save2()에서 사용된 SANJIGI의 경우 id가 지정되지 않아 처음 save() 시 merge가 아닌 persist() 메서드가 호출된다.

em.persist() 메서드를 타고 들어가다 보면 아래와 같이 persist에 대한 이벤트가 발생하는 것을 확인할 수 있다.
여기서 메서드의 차이도 있는데, fireMerge()의 경우 event의 result 값을 반환했었지만 여기서는 메서드의 반환값이 void인 것을 볼 수 있다. 즉, 새로운 객체를 생성하는 것이 아닌 기존의 객체를 관리한다는 것을 추론할 수 있다.

PersistEventListener::onPersist를 타고 들어가다 보면 아래와 같이 entityState가 ‘TRANSIENT’ 상태인 것을 볼 수 있다.
이는 entityManager에 의해 관리되지 않는 순수한 상태를 의미한다.

위 메서드에서 entityIsTransient() 메서드를 타고 들어가다 보면, 위와 같은 상황을 만날 수 있다.

여기서 인자로 넘기는 entity에 대한 정보는 우리가 넘긴 SANJIGI 객체인 것이다!

saveWithGeneratedId()의 이후의 과정은 save1()의 예제에서 봤던 동작 원리랑 똑같다.

다만, createdAt, updatedAt에 대한 값이 실제 SANJIGI 객체에서 채워진다는 것이 큰 특징이다.

cf. 위에서 다루지 않은 것 같아 말하지만 Id 값 역시 이 메서드에서 채워진다!
어떤 제너레이터를 사용하는지에 따라 달라진다. (IdentifierGenerator 활용)

실제로 save 전후의 값을 살펴보면 동일한 엔티티에 대해서 (User@8547) 값이 채워져서 들어가는 것을 확인할 수 있다.

@Test
@DisplayName("유저를 저장한다.")
void save2() {
	final User actualUser = userRepository.save(UserTest.SANJIGI);

	assertThat(entityManager.contains(UserTest.SANJIGI))
		.isTrue();
	assertThat(entityManager.contains(actualUser))
		.isTrue();
}

또한, save2()에서는 save 이후 SANJIGI와 actualUser 모두 영속성 컨텍스트에서 관리하는 것이 특징이다.

em.merge() 시에 반환받은 엔티티만 사용하자

@Test
@DisplayName("유저를 저장한다.")
void save1_duplicated_save() {
	final User actualUser1 = userRepository.save(UserTest.JAVAJIGI);
	final User actualUser2 = userRepository.save(UserTest.JAVAJIGI);

	assertThat(actualUser1).usingRecursiveComparison()
		.ignoringFields("id", "createdAt", "updatedAt")
		.isEqualTo(UserTest.JAVAJIGI);

	assertThat(actualUser2).usingRecursiveComparison()
		.ignoringFields("id")
		.isEqualTo(UserTest.JAVAJIGI);
}

save1() 메서드에서 한 번 더 객체를 저장했을 때의 실험이다.
actualUser1의 경우 JAVAJIGI와 actualUser1이 다르게 관리되었기 때문에 두 값이 달랐었다. (createdAt, updatedAt이 채워짐)
하지만, 한 번 더 저장한 actualUser2의 경우 JAVAJIGI와 동일하게 createdAt, updatedAt이 null이 된다. 왜 그러는 것일까?

먼저, actualUser1의 형태는 위와 같이 createdAt, updatedAt이 채워져 있는 형태이다.

actualUser1이 저장되는 시점의 merge() 로직을 다시 한 번 보자.
첫 번째 save() 로직에서는 MergeEventListener::onMerge 메서드에서 (merge 이벤트 발생할 때) 내부를 따라가다보면 영속성 컨텍스트에서 동일한 키값으로 관리되는 엔티티가 있는지 확인한다. 처음 save()를 할 때는 저장된 엔티티가 없기 때문에 없다고 나온다.

또한, entityState가 null이었지만, getEntityState를 통해 DETACHED인 상태라고 판단하게 된다.

그리고, 처음 봤을 때처럼 entityState가 DETACHED여서 entityIsDetached() 메서드를 타게 된다.

하지만, 영속성 컨텍스트 내부에는 id = 1이면서 entityName이 User인 객체가 존재하지 않아 result 값이 null이 되어,

DETACHED 상태임에도 실제로는 영속화가 필요한 객체라고 판단하여 영속화를 진행하게 된다.

하지만, 두 번째 save() 시에는 로직이 달라진다.

em.merge()를 진행하게 되면 인자로 넘겨준 객체가 아닌, 반환받은 객체를 영속성 컨텍스트에서 관리한다고 하였다.

그렇기 때문에 첫 번째 save() 시에 반환된 actualUser1만 영속성 컨텍스트에서 관리하고, JAVAJIGI는 영속성 컨텍스트에서 관리하지 않게 된다. 하지만, 두 번째 save 시 id 값이 이미 1L로 채워진 객체가 인자로 들어왔고, 영속성 컨텍스트에는 id = 1L인 actualUser가 관리되고 있기 때문에 entry 값이 null이 아니게 된다.

실제로 entry 값이 위와 같이 createdAt, updatedAt이 채워진 actualUser1 객체임을 확인할 수 있다.

이후, entityState가 DETACHED여서 entityIsDetached() 메서드를 타게 된다.

내부를 보면 첫 번째 save와 다르게 id=1, entityName이 User인 actualUser1가 관리되고 있어 result가 존재하게 된다.

그래서 else 구문에 있는 새로운 로직이 실행되는 것을 볼 수 있다.

MergeContext.put()의 경우, 첫 번째 인자로 병합할 엔티티를, 두 번째 인자로 이미 관리되고 있는 엔티티를 받아서 병합한다.

실제 호출부를 보면 병합할 엔티티로 기존의 JAVAJIGI 객체가, 이미 관리되고 있는 엔티티로 영속성 컨텍스트에 의해 관리되던 actualUser1 값이 들어가는 것을 볼 수 있다.

이후 copyValues를 통해 JAVAJIGI 객체에 대한 정보를 바탕으로 actualUser1의 객체의 정보에 복사가 진행된다.

이로 인해 JAVAJIGI가 가진 createdAt, updatedAt의 null 값이 전파된 것이다!

최종적으로 결과를 세팅해주는 부분을 보면 null로 업데이트 되어서 result를 세팅해주는 것을 코드로 볼 수 있다.

그래서, actualUser2의 createdAt, updatedAt 값이 null이 되어서 JAVAJIGI랑 같은 값을 가지게 되는 것이다.

결론

- em.merge()는 파라미터로 넘어온 엔티티의 '식별자 값'으로 영속성 컨텍스트를 조회하고, 찾는 엔티티가 없으면 데이터베이스에서 조회한다.
- 만약 데이터베이스에서도 발견하지 못하면 새로운 엔티티를 생성하여 병합한다.
- 병합은 준영속 상태와 비영속 상태를 신경쓰지 않기 때문에, 식별자 값으로 엔티티를 조회할 수 있으면 조회하여 병합하고, 조회할 수 없으면 새로 생성하여 병합한다.
- 따라서 병합은 save or update 기능을 수행한다.
- em.merge를 사용할 때는 반환받은 객체만 영속성 컨텍스트에서 관리한다는 점을 유의하자!

옛날에 진행했던 트러블 슈팅이었는데 다시 정리하니까 새롭다.

JPA는 알다가도 정말 모르겠다 ㅎㅎ

[QueryDSL] QueryDSL 사용 시 NPE가 발생했을 때 해결하기

dolmeng2 — Mon, 14 Aug 2023 14:01:06 +0900

문제 상황

프로젝트를 진행하면서 동적 쿼리를 작성할 일이 많아 QueryDSL을 도입하게 되었는데, 이번에 색다른 오류를 발견하게 되었다.

java.lang.NullPointerException: Cannot read field "id" because "co.kirikiri.domain.goalroom.QGoalRoomMember.goalRoomMember.goalRoom.roadmapContent.roadmap" is null

NPE를 본 건 오랜만이어서 조금 삽질을 진행했다.

도메인 구조

지난 포스팅과 같은 프로젝트이기 때문에 도메인 구조는 거의 동일한데, 위 문제 상황을 이해하기 위한 추가적인 도메인 정보가 필요하다.

하나의 로드맵 본문(RoadmapContent) 정보에 대해서 여러 개의 골룸(GoalRoom)이 생성될 수 있고, 하나의 골룸에 대해서 여러 개의 골룸 대기 멤버(GoalRoomPendingMembers)가 생길 수 있다는 것이다.

위 문제를 발견하게 된 테스트 코드는 아래와 같다.

@Test
void 카테고리_조건_없이_주어진_로드맵_이전의_데이터를_참가중인_인원이_많은순으로_조회한다() {
    ...

    final Roadmap gameRoadmap1 = 노드_정보를_포함한_로드맵을_생성한다("게임 로드맵", creator, gameCategory);
    final Roadmap gameRoadmap2 = 노드_정보를_포함한_로드맵을_생성한다("게임 로드맵2", creator, gameCategory);
    final Roadmap travelRoadmap = 노드_정보를_포함한_로드맵을_생성한다("여행 로드맵", creator, travelCategory);
  
    final GoalRoom gameRoadmap1GoalRoom = 골룸을_생성한다(gameRoadmap1.getContents().getValues().get(0), creator);
    final GoalRoom gameRoadmap2GoalRoom = 골룸을_생성한다(gameRoadmap2.getContents().getValues().get(0), creator);
    final GoalRoom travelRoadmapGoalRoom = 골룸을_생성한다(travelRoadmap.getContents().getValues().get(0), creator);

    // gameRoadmap1 : 참가인원 0명
    // gameRoadmap2 : 참가인원 1명
    final List<GoalRoomMember> gameRoadmap2GoalRoomMembers = List.of(
            new GoalRoomMember(GoalRoomRole.LEADER, LocalDateTime.now(), gameRoadmap2GoalRoom, creator));
    goalRoomMemberRepository.saveAll(gameRoadmap2GoalRoomMembers);

    // travelRoadmap : 참가인원 2명
    final List<GoalRoomMember> travelRoadmapGoalRoomMembers = List.of(
            new GoalRoomMember(GoalRoomRole.LEADER, LocalDateTime.now(), travelRoadmapGoalRoom, creator),
            new GoalRoomMember(GoalRoomRole.FOLLOWER, LocalDateTime.now(), travelRoadmapGoalRoom, follower));
    goalRoomMemberRepository.saveAll(travelRoadmapGoalRoomMembers);

    final RoadmapCategory category = null;
    final RoadmapFilterType orderType = RoadmapFilterType.PARTICIPANT_COUNT;

    // when
    final List<Roadmap> firstRoadmapRequest = roadmapRepository.findRoadmapsByCategory(category, orderType,
            null, 2);
    final List<Roadmap> secondRoadmapRequest = roadmapRepository.findRoadmapsByCategory(category, orderType,
            gameRoadmap2.getId(), 10);

    ...
}

코드가 상당히 복잡하지만 별거없다. 그냥 로드맵을 생성하고, 로드맵에 대한 참가인원을 추가하는 코드이다.

해당 코드는 아래와 같이 구현이 되어 있다.

@Override
public List<Roadmap> findRoadmapsByCategory(final RoadmapCategory category, final RoadmapFilterType orderType,
                                            final Long lastId, final int pageSize) {

    return selectFrom(roadmap)
            ...
            .where(
                    lessThanLastId(lastId, orderType)
           	)
            .fetch();
}

private BooleanExpression lessThanLastId(final Long lastId, final RoadmapFilterType orderType) {
    ...
    final NumberPath<Long> goalRoomMemberRoadmapId = goalRoomMember.goalRoom.roadmapContent.roadmap.id;
    return participantCountCond(goalRoomMemberRoadmapId.eq(roadmap.id))
            .lt(participantCountCond(goalRoomMemberRoadmapId.eq(lastId)));
}

인자로 받은 lastId (현재는 로드맵의 PK 값이 들어오고 있다.)에 해당하는 로드맵의 참여자 수보다 더 적은 참여자 수를 구하는 로드맵을 구하는 쿼리이다.

NPE가 발생할 지점을 찾아보기

처음에 이 오류를 접했을 때는 아래와 같은 예외 메시지 중에서 단순하게 이 부분에만 집중을 했었다.

co.kirikiri.domain.goalroom.QGoalRoomMember.goalRoomMember.goalRoom.roadmapContent.roadmap is null.

음... roadmap이 null이구나

그래서 goalRoomMember를 저장한 후에 로드맵에 대한 정보가 제대로 저장이 안 되어 있나 싶어서 findAll로 찾아보았다.

final List<GoalRoomMember> goalRoomMembers = goalRoomMemberRepository.findAll();
assertThat(goalRoomMembers.get(0).getGoalRoom().getRoadmapContent().getRoadmap().getId()).isNotNull();
assertThat(goalRoomMembers.get(1).getGoalRoom().getRoadmapContent().getRoadmap().getId()).isNotNull();
assertThat(goalRoomMembers.get(2).getGoalRoom().getRoadmapContent().getRoadmap().getId()).isNotNull();

NPE니까 당연히 roadmap의 id 값이 Null이 되어서 테스트가 실패하겠지?라고 생각하였다.

하지만 테스트가 놀랍게도 성공한 것을 볼 수 있었다. 그래서 값 자체는 제대로 들어갔겠구나 싶어서 다른 방향을 탐색해보았다.

QueryDSL의 객체 그래프

final NumberPath<Long> goalRoomMemberRoadmapId = goalRoomMember.goalRoom.roadmapContent.roadmap.id;

문제가 발생했던 라인은 정확하게 위 라인이었다.

어떠한 값이 들어가고 말고의 문제를 떠나서, 객체 그래프를 탐색할 때 뭔가 문제가 있을 것 같다는 생각이 들었다.

그래서 열심히 구글링을 해본 결과, 아래와 같은 글을 발견하게 되었다.

NullPointerException on QueryDSL where clause

Using Query DSL with hibernate (Spring Data JPA) to build a query like so if( bankId != null ){ query.where( coopMember.personId.bankAccountId.isNotNull().and(

stackoverflow.com

그리고 답변 내용에서 말해 주신 공식 문서를 한 번 읽어보았다.

By default Querydsl initializes only reference properties of the first two levels.
In cases where longer initialization paths are required, these have to be annotated in the domain types via
com.mysema.query.annotations.QueryInit annotations.
QueryInit is used on properties where deep initializations are needed.

기본적으로 QueryDSL은 초기 2단계의 레벨에 있는 프로퍼티만 초기화하게 된다.

만약 그 이상의 path를 초기화하고 싶다면 @QueryInit 어노테이션을 통해서 직접 지정해줄 수 있다.

한 번 우리의 문제 상황에 적용해보자.

@QueryInit

@QueryInit의 경우 기본적으로 @Entity 어노테이션이 붙어 있는 클래스의 필드에 대해서 적용이 가능하다.

내부 인자로 초기화하고 싶은 path를 지정해줄 수 있으며, *을 통해 와일드카드를 통해서도 지정이 가능하다.

먼저, @QueryInit을 지정하지 않았을 때의 큐파일을 디버깅해보았다. (QGoalRoom)

확인해보면 GoalRoom에서 QRoadmapContent까지의 값은 잘 가져오지만, QRoadmap에 대해서는 정의가 되어 있지 않은 것을 볼 수 있다. 여기서 QRoadmap 값이 null로 정의되었기 때문에 탐색이 불가능했던 것이다.

public class GoalRoomMember {

   ...

    @ManyToOne(fetch = FetchType.LAZY)
    @JoinColumn(name = "goal_room_id", nullable = false)
    @QueryInit(value = {"roadmapContent.roadmap"})
    protected GoalRoom goalRoom;
}

그래서, 위와 같이 GoalRoomMember 엔티티가 GoalRoom 엔티티를 정의한 필드에 @QueryInit을 정의해주었다.

이렇게 되면 QGoalRoom이 초기화될 때 RoadmapContent와 Roadmap 정보까지 함께 초기화가 가능할 것이다.

참고로, 내부 value의 값은 goalRoom 엔티티가 참조하고 있는 실제 필드명으로 작성해야 한다.

이런 식으로 잘못된 필드 값을 입력하게 되면 컴파일 타임 때 오류가 발생한다.

goalRoom이 실제로 의존하고 있는 필드명으로 작성해야 한다.

@ManyToOne(fetch = FetchType.LAZY)
@JoinColumn(name = "goal_room_id", nullable = false)
@QueryInit(value = {"roadmapContent.*"})
protected GoalRoom goalRoom;

추가적으로, 이렇게 와일드카드로 명시해도 잘 동작한다.

수정 후에 다시 디버깅을 진행해보면 이번에는 roadmap에 대한 정보도 잘 채워진 것을 확인할 수 있다.

테스트도 성공!

+) 추가적으로, 이렇게 @QueryInit을 특정 필드에 적용하고 나면 기존에 잘 돌아가던 쿼리들이 안 돌아갈 수도 있다.

나 같은 경우에는 비슷한 다른 쿼리에서 오류가 발생했었는데, 2단계 레벨에 있는 필드에 대해서 NPE가 발생했었다.

비슷한 오류지만 goalRoomMember -> member -> identifier (VO여서 단계에 반영하지 않는 것 같다. 처음에는 3단계라고 생각했는데 공식문서에서 2단계라고 정확하게 명시했으니까...)에 대해서 오류가 발생한 것이었다.

@QueryInit을 달지 않았을 때는 3단계까지 잘 갔었는데, 명시적으로 어노테이션을 지정해주니까 이렇게 된 것 같다.

@ManyToOne(fetch = FetchType.LAZY)
@JoinColumn(name = "goal_room_id", nullable = false)
@QueryInit(value = {"roadmapContent.*"})
protected GoalRoom goalRoom;

@ManyToOne(fetch = FetchType.LAZY)
@JoinColumn(name = "member_id", nullable = false)
@QueryInit(value = {"identifier"})
protected Member member;

그래서 member 필드에 대해서는 이렇게 identifier에 대해서도 정의를 해주었다.

사실 해결 방법은 아주 간단했는데 처음 마주한 오류여서 해결하는 데 시간이 오래 걸렸다...!

토스 2023 NEXT 개발자 챌린지 Server Developer 최종 합격 후기

dolmeng2 — Thu, 10 Aug 2023 18:26:16 +0900

사실 발표가 난 지는 꽤 됐지만 블로그에 기록으로 남겨두면 좋을 것 같아서 쓰는 글

추후 2024 NEXT가 진행되었을 때 도움이 된 분들이 있었으면 좋겠다!

준비 여정

올해 6월 말 정도, 토스에서 2023 NEXT 개발자 챌린지를 통해서 3년 이하의 개발자를 채용한다는 공고를 냈다.

사실 우테코를 진행하면서 올해 안에는 본격적인 취업 준비를 할 생각이 없었어서, 그냥 경험 한 번 해보자는 생각으로 당당하게 지원했다.

Core Banking이랑 Server 중에 어떤 걸 할지 고민했는데, 금융 관련 도메인에 대한 이해도가 현저히 낮은지라 Server 쪽 직무로 지원하게 되었다. 분야별 어디 파트를 하고 싶은지도 처음에 넣을 수 있는데, 그때는 토스랑 토스뱅크를 넣었다.

코딩 테스트 > 직무 인터뷰 > 문화 적합성 인터뷰 > 레퍼런스 체크 > 최종합격 순으로 채용은 진행된다.

시험 진행 전에 그냥 코테 문제 조금 풀고, 서술형이 어렵다는 말이 많았어서 그냥 테크 유튜브들 쪼금 보고 봤다.

코딩 테스트

2시간 30분 동안 알고리즘 7문제랑 서술형 5문제를 풀어야 한다. 코테 문제는 4문제, 서술형은 2~3문제 정도 답을 써서 내고 나왔다.

사실 보고 나서 망했다는 생각밖에 안 들었어서 별 기대를 안 했었는데, (사람들은 알고리즘 쉬웠다고 하지만) 그렇게 쉽지는 않았던 것 같다. 근데 코테 문제 풀다 보면 만날 수 있는 유형들이었어서 평소에 코테를 많이 접했다면 쉽게 풀 수 있을 것 같았다.

또한, 문제 풀 때 테스트 케이스가 되게 많았어서 본인이 틀리게 풀었는지 점검이 가능한 점이 좋았던 것 같다.

서술형은 사실 2~3문제 중에서 제대로 쓴 건 2문제 정도여서 처참하다고 말할 수 있지만...ㅎ

1문제를 진짜 자세하게 썼다. 그냥 내가 아는 모든 걸 쓴다는 느낌으로 어어엄청 자세하게 썼다.

신입에게는 조금 어려울 수밖에 없는 수준이었지만, 아는 대로 다 쓴다는 느낌으로 썼었다... ㅋㅋㅋㅋ

작년 후기 글을 보면 가상 면접 사례로 보는 대규모 설계 (이름이 길어서 이게 맞는지 모르겠다) 책이 도움이 되었다고 했는데, 그 책을 읽어보지 않아서 좋은지는 모르겠지만 내 개인적 경험으로는 테크 유튜브들을 자주 챙겨보면 좋을 것 같다는 생각이 들었다.

테크 유튜브의 경우 실무에서 어떤 문제를 만났고, 어떤 식으로 문제를 해결해나가는지 정말 자세하게 알려주기 때문이다.

당연히 신입 수준에서는 어렵기 때문에 그냥 간단하게 훑어봐도 괜찮다. 다 이해하려고 하지 말고, 그냥 대략적으로 이렇게 할 수 있겠네~ 정도만 느껴도 충분히 좋을 것 같다 ㅎㅎ

직무 인터뷰

메일받고 나서 엥??? 할 정도로 당황했었다. 전혀 기대를 하지 않았기 때문에...

그래도 기회가 왔으니 잡아야겠다는 생각으로 조금씩 준비했다.

코테 합격 이후 이력서를 제출했어야 했다.

이력서의 경우 사실 이전에 작성을 해둔 게 있었는데, 너무 중구난방하다는 생각이 들어서 토스 지원할 때 싹 뜯어고쳤다.

노션을 통해 작성한 다음 PDF로 변형해서 제출했고, 약 2페이지 정도의 분량이 나왔다. (진짜 빈약한 편이기는 하다)

특히 대학교 다니면서 진행했던 프로젝트 경험은 싹 빼고, 그냥 우테코랑 진행했던 프로젝트 내용을 위주로 작성해서 냈다.

이력서의 분량보다는, 이력서 내의 내용을 본인이 얼마나 숙지하고 있는지가 가장 중요한 것 같아서, 7페이지 - 8페이지 정도의 질문 목록을 작성하고 외워서 갔다.

1. A가 뭔가요?
2. B도 있는데 왜 A를 쓰셨나요?
3. A를 쓰면서 뭐가 어려웠나요?
4. A를 쓸 때 ~~라는 상황이 발생할 수 있을 텐데, 이건 어떻게 해결할 수 있을 것 같나요?

대략 이런 흐름으로 질문을 정리했고, 추가적으로 서술형 문제 중에서 내가 답변했던 것들만 내가 왜 이런 식으로 썼었는지 머리에 넣어서 갔다. (이건 잘 준비해가면 더 좋을 것 같다!)

그리고 면접은... 약 1시간 30분 정도 진행이 되었었다.

하지만 끝나고 나서... 그냥 망했다는 생각밖에 안 들었었다.

나름 이력서의 내용을 숙지하고 갔다고 생각했는데 아니었다... ㅎㅎ 대답을 잘 못한 부분도 많았다.

그래도 준비한 부분에 대해서는 최선을 다해서 대답했었고, 잘 모르는 부분도 최대한 대답하려고 노력을 했었다.

이력서 내용은 100%가 아닌 200% 정도는 커버해서 준비하는 게 좋을 것 같다는 생각이 들었다.

그리고 마지막 20분 정도는 역질문을 할 수 있는데, 이 시간 동안 정말 꽉꽉 채워서 여쭤봤었다.

결과랑 관련없이 면접 분위기도 너무 좋았고 (대답을 잘하고 못하고를 떠나서 인터뷰어님들이 너무 좋았음) 인터뷰로도 충분히 배워갈 수 있는 시간이 들었어서 떨어져도 좋은 경험이 되겠네 ㅎㅎ 라는 생각으로 마무리했다.

지금 와서 생각해보면 잘 몰라도 대답할 때 엄청 열심히 노력했던 게 인터뷰어님들에게 보여서 좋은 결과를 받은 게 아닐까 싶다.

문화적합성 인터뷰

합격은 진짜 다음 날 전화로 바로 알려주셨다.

처음에 전화왔을 때 택배 시킨 거 연락온 줄 알고 아무 생각 없이 받았는데 토스에서 온 거여서 엄청 놀랐다...

그래서 이때 어떻게 대답했는지도 기억이 잘 안 난다.

컬쳐핏은 정말 뭐가 나올지 예상조차 못하겠어서, 토스피드와 토스 유튜브를 봤다.

토스피드에 글이 정말 많은데, 토스팀의 문화를 소개하는 부분은 그냥 전부 다 읽었다.

근데 읽으면서 정말 좋은 기업이구나, 가고 싶다... 라는 생각을 엄청 많이 들었다.

면접은 테크 리더님과 1:1로 1시간 정도 진행하였다.

나의 경우 토스의 문화랑 내가 평소에 생각하는 거랑 상당히 비슷하다 보니까 그냥 솔직하게 털어놔도 좋을 것 같다는 생각이 들어서 정말 대화하는 것처럼 이야기를 나눴다. 개발을 넘어서 자기 자신에 대해 평소에 잘 생각해둔다면 무리없이 진행할 수 있는 느낌? (평소에 자아성찰 많이 함) 오히려 그냥 대화하는 것 같아서 나는 면접이 꽤 재밌었던 것 같았다.

뭔갈 준비해서 된다기보단, 정말 토스의 문화에 본인이 얼마나 잘 녹아들 수 있는지 (만약 토스 문화를 보면서 본인과 잘 안 맞을 것 같다는 생각이 든다면 본인이 정말 토스에 가고 싶은지 고민하기!) 고민을 많이 해보면 좋을 것 같다.

회고

마찬가지로 합격은 바로 다음 날에 전화로 알려 주셨다.

사실 아직까지 안 믿기지만...! 좋은 결과를 얻어서 기쁘면서도 걱정도 되고, 묘하다.

추후 이 글을 보며 준비하시는 모든 분들도 잘 되었으면 좋겠다.

쌩신입인 만큼 가서 엄청 깨지고 부서지겠지만... 미래의 내가 잘 해낼 거라고 믿으면서...!

8월 한 달 동안 푹 쉬고 우테코도 잘 마무리해야겠다. (우테코를 끝까지 못한 게 정말 너무 아쉽다 ... 내 테코톡...)

축하해준 모든 분들에게 감사 인사 돌립니다 ‍♀️

[Spring] @SpringBootTest에서 지연 로딩 사용하기 - no Session 방지하기

dolmeng2 — Sun, 30 Jul 2023 14:23:01 +0900

들어가기 전

우리 팀의 경우 E2E 테스트 환경을 구축하기 위해서 @SpringBootTest를 통해 테스트 코드를 작성하고 있는데, 우리 팀의 팀원분이 아래와 같은 오류를 만나게 되었다.

failed to lazily initialize a collection of role: co.kirikiri.domain.roadmap.RoadmapContent.nodes.values: could not initialize proxy - no Session

상황은 아래와 같다. (추후 코드로 더 잘 살펴볼 예정이다.)

A라는 생성 API와 B라는 조회 API가 있을 때, 팀 내에서 기능을 세분화한 다음 각자 개발을 진행하다 보니 B를 개발하는 시점에 A라는 API가 없어, 통합 테스트 때 repository를 의존하여 직접 save를 하게 되었다.

하지만, save 후 반환된 엔티티의 객체를 조회할 때 지연 로딩을 사용하다 보니 트랜잭션이 필요하게 되었는데, 테스트 메서드에서는 repository를 호출하는 시점에서만 트랜잭션이 걸리고, 해당 객체를 사용하는 시점에는 트랜잭션이 없어 영속성 컨텍스트가 없는 상태가 된 것이다. 그러다 보니 세션 정보가 없어 지연 로딩을 사용할 수 없다는 오류가 발생하게 되었다.

당시 이 오류를 처음 접했을 때는 테스트 메서드의 트랜잭션이 없어서 발생한 문제니까, A api가 merge 된 이후에 작업하셔도 충분하실 것 같아요! 같은 답을 드렸지만, 곰곰이 생각해보니 이게 과연 옳은 해답인가? 라는 생각이 들었다. (물론 지금 우리 팀 상황에서는 빠르게 API 개발을 끝내야 하니까, 지금 작성해봤자 어차피 리팩터링을 해야 하니 이렇게 넘어간 것도 있다 )

앞으로도 이런 테스트 상황이 생길 텐데, 그럴 때마다 이럴 수는 없기 때문에 이번에 공부하면서 새로운 방법을 적용하게 되었다.

엔티티 소개

현 문제 상황에서 필요한 간단한 엔티티 다이어그램이다.

로드맵 (Roadmap)은 로드맵 내용들(RoadmapContents)에 대해서 1:N 관계를 맺고 있으며, 각 로드맵 내용(RoadmapContent)은 로드맵 노드들(RoadmapNodes)에 대해서 또 다시 1:N 관계를 가지고 있다.

이를 코드로 봤을 때는 대략적으로 아래와 같이 구성된다.

@Entity
@NoArgsConstructor(access = AccessLevel.PROTECTED)
@AllArgsConstructor
public class Roadmap extends BaseEntity {

    ...
    
    @Embedded
    private RoadmapContents contents = new RoadmapContents();
    
    ...
}

@Entity
@NoArgsConstructor(access = AccessLevel.PROTECTED)
@Getter
public class RoadmapContent extends BaseUpdatedTimeEntity {

    ...

    @Embedded
    private final RoadmapNodes nodes = new RoadmapNodes();

   ...

    public RoadmapNodes getNodes() {
        return nodes;
    }
}

@Embeddable
@NoArgsConstructor(access = AccessLevel.PROTECTED)
public class RoadmapNodes {

    @OneToMany(fetch = FetchType.LAZY, cascade = {CascadeType.PERSIST, CascadeType.MERGE}, mappedBy = "roadmapContent")
    private final List<RoadmapNode> values = new ArrayList<>();

    ...
    
    public List<RoadmapNode> getValues() {
        return new ArrayList<>(values);
    }
}

여기서 봐야하는 점은, 로드맵(Roadmap) - 로드맵 본문(RoadmapContent)과 로드맵 본문(RoadmapContent)과 로드맵 노드(RoadmapNode) 모두가 LAZY 전략을 사용하고 있다는 것이다.

문제 상황

아래의 테스트 코드는 @SpringBootTest(webEnvironment = SpringBootTest.WebEnvironment.RANDOM_PORT)을 통해서 통합 테스트 환경을 구축한 상태에서 진행된다.

@Test
void 테스트() throws JsonProcessingException {
    ...

    final Long 로드맵_아이디 = 로드맵을_생성한다(액세스_토큰, 카테고리.getId(), "로드맵 제목", "로드맵 소개글", "로드맵 본문",
            RoadmapDifficultyType.DIFFICULT, 30, List.of(노드1, 노드2));

    final RoadmapContent 로드맵_본문 = 로드맵으로부터_본문을_가져온다(로드맵_아이디);
    final List<RoadmapNode> 로드맵_노드들 = 로드맵_본문.getNodes().getValues(); // Here!
    ...
}

private RoadmapContent 로드맵으로부터_본문을_가져온다(final Long 로드맵_아이디) {
    final Roadmap 로드맵 = roadmapRepository.findById(로드맵_아이디).get();
    return roadmapContentRepository.findFirstByRoadmapOrderByCreatedAtDesc(로드맵).get();
}

코드의 첫 라인을 보면 로드맵을_생성한다(); 메서드를 통해 로드맵 아이디를 반환받고 있다. 여기서는 실제 API call을 진행하고 있기 때문에 실제로 생성된 로드맵의 아이디만을 반환받는다. 반환받은 아이디를 바탕으로 로드맵 엔티티를 얻어오기 위해 findById()를 통해 로드맵 엔티티를 조회해오며, 여기서 가장 최근에 생성된 로드맵 본문 엔티티를 가져오기 위해 한 번 더 조회를 진행한다.

물론, 로드맵 엔티티로부터 가장 최근의 로드맵 본문을 받아오는 방법도 있겠지만, 현 프로덕션 코드에서는 해당 부분이 필요하지 않았고, 만약 그렇게 코드를 작성했다면 본문을 가져오는 과정에서부터 오류가 발생했을 것이다.

또한, 현재 작성한 부분은 생성 API가 아직 만들어지지 않은 상태로 조회 API를 만들다 보니 생성을 위한 엔티티를 만드려고 '로드맵 노드들' 엔티티를 조회해온 코드여서 추후 생성 API가 만들어진다면 제거될 부분이긴 하다!

cf. findFirst~() 메서드에서는 트랜잭션이 어딨을까?

public interface RoadmapContentRepository extends JpaRepository<RoadmapContent, Long> {

    Optional<RoadmapContent> findFirstByRoadmapOrderByCreatedAtDesc(final Roadmap roadmap);
}

roadmapContentRepository의 경우 위와 같이 JpaRepository를 상속받고 있다.

이때, JpaRepository 인터페이스의 구현체인 SimpleJpaRepository 클래스를 가면 위와 같이 @Transactional이 붙어 있는 것을 볼 수 있다. 그렇기 때문에 해당 메서드가 호출하는 시점에 대해서만 트랜잭션이 걸려있게 되는 것이다.

기본적으로 스프링에서 영속성 컨텍스트는 트랜잭션과 생명주기가 동일하기 때문에, roadmapContentRepository로부터 조회해온 RoadmapContent는 트랜잭션이 종료되면서 영속성 컨텍스트의 관리 범위에서도 함께 벗어나게 된다. 현재 로드맵 본문 엔티티는 준영속 상태가 되었음을 기억하자.

final List<RoadmapNode> 로드맵_노드들 = 로드맵_본문.getNodes().getValues(); // Here!

다시 돌아와서, here! 이라고 특정된 부분을 보자. 해당 부분이 오류가 발생하는 지점이다.

로드맵 본문으로부터 노드에 대한 정보를 가져오려고 할 때 오류가 발생한 것이다.

public List<RoadmapNode> getValues() {
    return new ArrayList<>(values);
}

노드에서 getValues() 메서드를 호출하면 values()에 대한 접근이 일어나게 되는데, 이때 아래와 같은 일들이 발생한다.

read() 라는 메서드를 따라 들어가다 보면, 어떠한 초기화 작업이 처음에 발생하는 것을 볼 수 있다.

그리고, 지연 로딩 작업을 세션으로부터 컬렉션 정보를 초기화하는 것을 볼 수 있다.

상위의 주석을 잘 읽어보면, 초기화가 불가능할 때 LazyInitializationException이 발생함을 볼 수 있다.

그리고, 해당 메서드를 타고 들어가면 session 정보가 없을 때 외부의 트랜잭션을 사용할 수 있는지 판단하는데, 사용 불가능하기 때문에 (allowLoadOutsideTransaction=false) 하단의 else 구문으로 제어가 내려가게 되어 오류가 발생하게 된다.

참고로, allowLoadOutsideTransaction의 경우 제일 처음 세션 정보를 세팅해줄 때 위의 메서드에서 적용된다.

세션 정보로부터 지연 로딩임에도 트랜잭션을 사용할 수 있는지 정보를 받아오는 것 같다.

그렇다면 트랜잭션 정보가 있으면 되는 게 아닐까?

한 번 천천히 해결해나가보자.

그냥 @Transactional을 붙이면 되지 않나?

@Test
@Transactional // 트랜잭션!
void 테스트() throws JsonProcessingException {
    ...
	
    final RoadmapCategory 카테고리 = 로드맵_카테고리를_저장한다("여행");
    final Long 로드맵_아이디 = 로드맵을_생성한다(액세스_토큰, 카테고리.getId(), "로드맵 제목", "로드맵 소개글", "로드맵 본문",
            RoadmapDifficultyType.DIFFICULT, 30, List.of(노드1, 노드2));

    final RoadmapContent 로드맵_본문 = 로드맵으로부터_본문을_가져온다(로드맵_아이디);
    final List<RoadmapNode> 로드맵_노드들 = 로드맵_본문.getNodes().getValues(); 
    ...
}

 private RoadmapCategory 로드맵_카테고리를_저장한다(final String 카테고리_이름) {
    final RoadmapCategory 로드맵_카테고리 = new RoadmapCategory(카테고리_이름);
    return roadmapCategoryRepository.save(로드맵_카테고리);
}

트랜잭션이 없어서 생긴 문제라면, @Transactional을 붙이면 된다고 생각할 수 있다.

여기서 아까 예제와 다르게 로드맵에 대한 카테고리 생성 메서드가 추가된 것을 볼 수 있는데, 오류가 발생한 포인트이기 때문에 넣어두었다. 카테고리의 경우 생성하는 API가 없기 때문에 (나중에 admin 기능을 추가하면 넣을 예정이었다.) 위와 같이 직접 save를 해준다.

하지만, 정말 뜬금없이 NPE가 발생하는 것을 볼 수 있다. 이는, 응답값이 제대로 반환되지 않으면서 response header 값이 제대로 내려오지 않았기 때문이다.

실제로 해당 로그의 상단으로 올라가보면, 위와 같이 카테고리에 대한 Exception이 발생한 것을 볼 수 있다.

이는, 로드맵 생성 API가 호출되면서 create 하는 과정에 request body 값으로 받은 로드맵 카테고리 아이디에 대한 유효성을 검증하게 되고, 해당 로직에서 카테고리 정보가 존재하지 않아 발생한 오류이다.

분명 위에서 로드맵_카테고리를_저장한다() 메서드를 통해 저장을 했는데, 이게 어떻게 된 일일까?

이는, @SpringBootTest(webEnvironment = SpringBootTest.WebEnvironment.RANDOM_PORT) 때문이다.

이전에 테스트 컨텍스트에 대한 게시글을 작성한 적이 있는데, 그때 random_port 옵션에 대해 이와 같이 커멘트를 남겼다.

random_port 옵션을 지정하게 되면 별개의 스레드에서 컨테이너가 실행된다는 것이다.

= 즉, 프로덕션 코드에서 작성한 메서드의 스레드와 @SpringBootTest의 메서드의 스레드가 다르다는 의미이다.

기본적으로 @Transactional이 붙게 되면 작업 스레드는 커넥션 풀에서 Connection 객체를 가져와서 사용하게 되는데, 스레드가 달라지게 되면 사용하게 되는 Connection이 달라지게 된다. 즉, 트랜잭션이 아예 달라지게 되는 것이다.

그렇기 때문에 프로덕션 코드가 실행되는 로드맵 생성 API의 스레드 입장으로서는 테스트 메서드인 로드맵_카테고리를_생성한다() 스레드가 하는 일을 인식하지 못하기 때문에 카테고리에 대한 정보를 받아올 수 없는 것이다.

여기서 한 가지 삽질을 했는데, 콘솔상으로는 쿼리가 발생하길래 계속 insert가 된다고 생각했었다. (IDENTITY 전략으로 인해)

하지만, 실제로 DB에 가서 확인해보니 결과가 저장되지 않았었고, 아마 쿼리만 발생한 것 같다고 추측된다.

(트랜잭션 시작 후 커밋이 되지 않은 상태라고 보는 게 더 정확할 것 같다.)

@Transactional을 제거하면 위와 같이 레코드가 저장된다. (트랜잭션이 없으니 바로 DB에 저장)

그러면 이 문제를 어떻게 해결해야 할까?

RANDOM_PORT를 사용하지 않게 되면 E2E 테스트의 의미가 없고, API call로 대체할 수 없는 상황이다.

지연 로딩이 필요한 시점에서만 트랜잭션을 생성하기 - 메서드 분리하기

우리가 만났던 근본적인 문제는, 지연 로딩을 하는 시점에 트랜잭션이 존재하지 않아 조회를 해올 수 없었던 것이다.

그렇다면 조회하는 시점에 새로운 트랜잭션을 생성해주는 건은 어떨까?

@Test
void 테스트() throws JsonProcessingException {
    ...
	
    final RoadmapCategory 카테고리 = 로드맵_카테고리를_저장한다("여행");
    final List<RoadmapNode> 로드맵_노드들 = 로드맵_노드들을_반환한다(액세스_토큰, 카테고리, 노드1, 노드2);
    
    ...
}


@Transactional // 트랜잭션!
public List<RoadmapNode> 로드맵_노드들을_반환한다(final String 액세스_토큰, final RoadmapCategory 카테고리, final RoadmapNodeSaveRequest 노드1,
                                        final RoadmapNodeSaveRequest 노드2) {
    final Long 로드맵_아이디 = 로드맵을_생성한다(액세스_토큰, 카테고리.getId(), "로드맵 제목", "로드맵 소개글", "로드맵 본문",
            RoadmapDifficultyType.DIFFICULT, 30, List.of(노드1, 노드2));

    final RoadmapContent 로드맵_본문 = 로드맵으로부터_본문을_가져온다(로드맵_아이디);
    return 로드맵_본문.getNodes().getValues();
}

하지만, 위 코드는 동작하지 않는다. 이는 기본적으로 @Transactional은 Spring AOP를 사용하여 구현되기 때문이다.

이때 크게 2가지의 특징이 존재한다.

1. 타겟 클래스를 상속하여 프록시 객체를 생성하기 때문에 상속 자체가 불가능한 private 메서드에 대해서는 적용 불가

2. 동일한 클래스의 내부 메서드를 호출하게 되면 프록시를 호출하지 않고 대상 객체를 직접 호출하게 되어 적용 불가

위 코드에서는 2번의 경우, 내부 메서드를 사용했기 때문에 트랜잭션을 적용할 수 없는 것이다.

그렇다면, 내부 메서드 대신에 외부 클래스를 활용하면 되지 않을까?

지연 로딩이 필요한 시점에서만 트랜잭션을 생성하기 - 클래스 분리하기

@Component
@TestConstructor(autowireMode = AutowireMode.ALL)
public class RoadmapTestHelper {

    private final RoadmapRepository roadmapRepository;
    private final RoadmapContentRepository roadmapContentRepository;

    public RoadmapTestHelper(final RoadmapRepository roadmapRepository,
                             final RoadmapContentRepository roadmapContentRepository) {
        this.roadmapRepository = roadmapRepository;
        this.roadmapContentRepository = roadmapContentRepository;
    }

    @Transactional(readOnly = true)
    public List<RoadmapNode> 로드맵_노드들을_조회한다(final Long 로드맵_아이디) {
        final RoadmapContent 로드맵_본문 = 로드맵으로부터_본문을_가져온다(로드맵_아이디);
        return 로드맵_본문.getNodes().getValues();
    }

    private RoadmapContent 로드맵으로부터_본문을_가져온다(final Long 로드맵_아이디) {
        final Roadmap 로드맵 = roadmapRepository.findById(로드맵_아이디).get();
        return roadmapContentRepository.findFirstByRoadmapOrderByCreatedAtDesc(로드맵).get();
    }
}

로드맵 노드를 조회하기 위한 별도의 Helper 클래스를 생성해준다.

로드맵_본문 엔티티가 detached 상태가 되지 않도록 조회를 해오는 시점의 메서드부터 helper 클래스에 두었으며, 본문으로부터 노드 정보를 지연로딩을 통해 가져와서 반환하도록 만들었다.

@Test
void 테스트() throws JsonProcessingException {
    ...
	
    final RoadmapCategory 카테고리 = 로드맵_카테고리를_저장한다("여행");
    final Long 로드맵_아이디 = 로드맵을_생성한다(액세스_토큰, 카테고리.getId(), "로드맵 제목", "로드맵 소개글", "로드맵 본문",
            RoadmapDifficultyType.DIFFICULT, 30, List.of(노드1, 노드2));
    
    // Here!
    final List<RoadmapNode> 로드맵_노드들 = roadmapTestHelper.로드맵_노드들을_조회한다(로드맵_아이디);
    ...
}

그리고 기존의 테스트 코드에서 helper 클래스를 통해서 노드를 조회해왔다.

그러면 위와 같이 테스트 코드가 성공하는 것을 확인할 수 있다!

와 성공~!

하지만, 위 방법은 매우 찝찝하다. 지연로딩이 필요한 코드마다 이렇게 테스트 클래스로 분리해야 하기 때문이다.

만약 테스트하는 케이스가 정말 많아진다면 그럴 때마다 helper 클래스에 메스드가 엄청나게 늘어나게 될 것이다.

이는 전혀 개발자답지 못한 해결 방법이기 때문에 다른 방법을 모색할 필요가 있다.

지연 로딩이 필요한 시점에서만 트랜잭션을 생성하기 - 함수형 인터페이스 활용하기

필요할 때마다 helper 클래스의 메서드로 분리하는 게 아니라, 트랜잭션이 필요한 로직에 대해서만 외부 클래스에서 실행되도록 만들 수는 없을까? 즉, 메서드를 인자로 넘겨서 어떠한 곳에서 처리하고 싶은 것이다.

자바에서는 메서드를 파라미터로 전달하기 위해서 람다식을 활용할 수 있다.

우리는 인자로 넘긴 값으로 List<RoadmapNode>를 받아야 하기 때문에 T를 반환하는 시그니처를 가진 함수형 인터페이스를 하나 설정할 수 있다.

@FunctionalInterface
public interface TransactionalTask<T> {
    T execute();
}

함수형 인터페이스란?
오직 1개의 추상 메서드를 가지는 인터페이스.
여기서 추상 메서드란, 자식 클래스에서 반드시 오버라이딩 해야 사용할 수 있는 메서드이다.

그리고, 트랜잭션이 필요한 작업을 도와준다는 의미로 하나의 헬퍼 클래스를 생성하도록 하자.

@Component
public class TransactionHelper {

    @Transactional(readOnly = true)
    public <T> T getResult(final TransactionalTask<T> task) {
        return task.execute();
    }
}

헬퍼 클래스에서는 TransactionTask 타입의 어떠한 람다식을 받아서, 해당 람다식을 @Transactional이 걸린 상태로 실행해주는 역할을 진행한다. 이제 이 헬퍼 클래스를 활용하게 되면 아래와 같이 테스트 코드를 작성할 수 있다.

@Test
void 테스트() throws JsonProcessingException {
    ...
	
    final RoadmapCategory 카테고리 = 로드맵_카테고리를_저장한다("여행");
    final Long 로드맵_아이디 = 로드맵을_생성한다(액세스_토큰, 카테고리.getId(), "로드맵 제목", "로드맵 소개글", "로드맵 본문",
            RoadmapDifficultyType.DIFFICULT, 30, List.of(노드1, 노드2));
            
    final List<RoadmapNode> 로드맵_노드들 = transactionHelper.getResult(new TransactionalTask<List<RoadmapNode>>() {
            @Override
            public List<RoadmapNode> execute() {
                final RoadmapContent 로드맵_본문 = 로드맵으로부터_본문을_가져온다(로드맵_아이디);
                return 로드맵_본문.getNodes().getValues();
            }
        });
    ...
}

transactionHelper 클래스의 getResult() 메서드의 인자로 함수형 인터페이스의 추상 메서드인 execute()의 익명 클래스가 들어간다.

그리고, 해당 구현체에 로드맵 본문을 조회하여 로드맵 노드를 반환하는 로직을 넣었다.

익명 클래스
클래스의 선언과 인스턴스화를 동시에 진행할 수 있는 클래스로, 이름이 없는 클래스라 익명 클래스라고 부른다.

이때, 익명 클래스의 경우 람다로 축약할 수 있기 때문에 아래와 같이 더 간결하게 리팩터링을 진행할 수 있다.

@Test
void 테스트() throws JsonProcessingException {
    ...
	
    final RoadmapCategory 카테고리 = 로드맵_카테고리를_저장한다("여행");
    final Long 로드맵_아이디 = 로드맵을_생성한다(액세스_토큰, 카테고리.getId(), "로드맵 제목", "로드맵 소개글", "로드맵 본문",
            RoadmapDifficultyType.DIFFICULT, 30, List.of(노드1, 노드2));
            
    final List<RoadmapNode> 로드맵_노드들 = transactionHelper.getResult(() -> {
    	final RoadmapContent 로드맵_본문 = 로드맵으로부터_본문을_가져온다(로드맵_아이디);
    	return 로드맵_본문.getNodes().getValues();
    });
    
    ...
}

최종적으로 실행해보면 위와 같이 테스트 코드도 잘 실행되는 것을 볼 수 있다!

이제 테스트 코드에서 지연로딩이 필요한 부분에 대해 (then절 같이 응답값을 꺼내어 검증할 때) 이를 잘 사용하면 된다.

오랜만에 함수형 인터페이스 같은 개념을 보다 보니까 헷갈렸는데, 아무쪼록 잘 해결할 수 있어서 다행이다.

꽤 의미있는 트러블 슈팅을 한 것 같아서 재밌었다

+ 추가

갓말랑 선생님께서 더 좋은 방법을 제시해주셔서 공유!

@Autowird
private TransactionTemplate transactionTemplate;

@Test
void 테스트() throws JsonProcessingException {
    ...
	
    final RoadmapCategory 카테고리 = 로드맵_카테고리를_저장한다("여행");
    final Long 로드맵_아이디 = 로드맵을_생성한다(액세스_토큰, 카테고리.getId(), "로드맵 제목", "로드맵 소개글", "로드맵 본문",
            RoadmapDifficultyType.DIFFICULT, 30, List.of(노드1, 노드2));
    
    final List<RoadmapNode> 로드맵_노드들 = transactionTemplate.execute(new TransactionCallback<List<RoadmapNode>>() {
            @Override
            public List<RoadmapNode> doInTransaction(final TransactionStatus status) {
                final RoadmapContent 로드맵_본문 = 로드맵으로부터_본문을_가져온다(로드맵_아이디);
                return 로드맵_본문.getNodes().getValues();
            }
        });
    
    ...
}

스프링에서는 이미 TransactionTemplate 이라는 인터페이스를 통해서 제공을 해주고 있었다... ㅎㅎ (그냥 혼자 구현한 사람 됨)

위와 같이 반환값이 필요한 경우라면 TransactionCallback을 인자로 받으면 된다.

람다를 활용하면 더 축약이 가능하다.

@Autowird
private TransactionTemplate transactionTemplate;

@Test
void 테스트() throws JsonProcessingException {
    ...
	
    final RoadmapCategory 카테고리 = 로드맵_카테고리를_저장한다("여행");
    final Long 로드맵_아이디 = 로드맵을_생성한다(액세스_토큰, 카테고리.getId(), "로드맵 제목", "로드맵 소개글", "로드맵 본문",
            RoadmapDifficultyType.DIFFICULT, 30, List.of(노드1, 노드2));
    
    final List<RoadmapNode> 로드맵_노드들 = transactionTemplate.execute(status -> {
            final RoadmapContent 로드맵_본문 = 로드맵으로부터_본문을_가져온다(로드맵_아이디);
            return 로드맵_본문.getNodes().getValues();
    });
    
    ...
}

지금 보면 직접 만든 transactionHelper와 완전 동일하다고 봐도 무방하다. 그냥 요렇게 사용하는 게 더 좋을 것 같다.

만약, 반환값이 필요없다면 TransactionCallbackWithoutResult를 인자로 받으면 된다.

@Autowird
private TransactionTemplate transactionTemplate;

@Test
void 테스트() throws JsonProcessingException {
    ...
	
    final RoadmapCategory 카테고리 = 로드맵_카테고리를_저장한다("여행");
    final Long 로드맵_아이디 = 로드맵을_생성한다(액세스_토큰, 카테고리.getId(), "로드맵 제목", "로드맵 소개글", "로드맵 본문",
            RoadmapDifficultyType.DIFFICULT, 30, List.of(노드1, 노드2));
    
    transactionTemplate.execute(new TransactionCallbackWithoutResult() {
            @Override
            protected void doInTransactionWithoutResult(final TransactionStatus status) {
                final RoadmapContent 로드맵_본문 = 로드맵으로부터_본문을_가져온다(로드맵_아이디);
                로드맵_본문.getNodes().getValues();
            }
        });
        
    ...
}

좋은 방법 공유해준 말랑 선생님 고마워요 ‍♀️

[Gradle] Jacoco를 활용하여 테스트 커버리지 설정하기

dolmeng2 — Sun, 23 Jul 2023 16:29:29 +0900

들어가기 전

우리 팀은 CI 플로우 과정 중에서 Jacoco를 활용하여 테스트 리포트를 발행하고, 커버리지를 체크하고 있다.

(테스트를 정말 철저하게 하자는 취지인데, 팀원 모두가 테스트를 정말 꼼꼼하게 작성해 주셔서 좋다 )

CI에 대한 글은 다음에 완전하게 구축된 이후에 작성하는 게 좋을 것 같아서, 오늘은 Jacoco에 대해서만 가볍게 짚고 넘어가고자 한다.

Jacoco 설정하기

Jacoco는, 테스트 코드 커버리지를 분석해주는 자바의 무료 라이브러리이다.
Jacoco 플러그인에는 JacocoTestReport와 JacocoTestCoverageVerification Task 등이 존재한다. (여기서는 이 2가지를 위주로 알아보도록 하자.)
- JacocoTestReport: 커버리지 결과를 리포트로 저장하는 역할
- JacocoTestCoverageVerification: 원하는 커버리지 기준을 만족하는 확인하는 Task

build.gradle 설정해주기 - JacocoTestReport

plugins {
    id 'jacoco'
}

jacoco {
    toolVersion = "0.8.10" // https://www.jacoco.org/jacoco/trunk/doc/changes.html
}

jacocoTestReport {
    dependsOn test
    reports {
        html.required = true
        xml.required = true
    }

    // QueryDSL QDomain 제외시키기
    def QDomains = []

    for (qPattern in '**/QA'..'**/QZ') {
        QDomains.add(qPattern + '*')
    }
    afterEvaluate {
        classDirectories.setFrom(
                // 그 외의 매칭되는 클래스도 제외 대상
                files(classDirectories.files.collect {
                    fileTree(dir: it, excludes: [
                            "co.kirikiri.domain.**.**",
                            "**/*Application*",
                            "**/*Config*",
                            "**/*Dto*",
                            "**/*Request*",
                            "**/*Response*",
                            "**/*Interceptor*",
                            "**/*Exception*"
                    ] + QDomains)
                })
        )
    }
    // 리포트 생성 후 커버리지 체크
    finalizedBy jacocoTestCoverageVerification
}

jacocoTestCoverageVerification {
    // QueryDSL QDomain 제외시키기
    def QDomains = []
    // qPattern = "*.QA","*.QB","*.QC", ... "*.QZ"
    for (qPattern in '*.QA'..'*.QZ') {
        QDomains.add(qPattern + '*')
    }

    violationRules {
        rule {
            // rule 활성화
            enabled = true

            // 클래스 단위로 룰 체크
            element = 'CLASS'

            // 라인 커버리지를 최소 80% 만족
            limit {
                counter = 'LINE'
                value = 'COVEREDRATIO'
                minimum = 0.80
            }
						
            // 마찬가지로 제거 대상 지정
            excludes = [
                    "co.kirikiri.domain.**.**",
                    "**.*Application*",
                    "**.*Config*",
                    "**.*Dto*",
                    "**.*Request*",
                    "**.*Response*",
                    "**.*Interceptor*",
                    "**.*Exception*"
            ] + QDomains
        }
    }
}

tasks.named('test') {
    outputs.dir snippetsDir
    useJUnitPlatform()
    // test 수행 이후 리포트 생성
    finalizedBy jacocoTestReport
}

build.gradle 코드가 상당히 길기는 한데, 그렇게 어려운 내용은 아니다.

plugins {
    id 'jacoco'
}

jacoco {
    toolVersion = "0.8.10" // https://www.jacoco.org/jacoco/trunk/doc/changes.html
}

먼저, jacoco에 대한 플러그인을 설정해주는 부분이다.

현재 스냅샷 버전 제외 가장 최신 버전이 0.8.10이길래 이 버전으로 설치를 해주었다.

jacocoTestReport {
    reports {
        html.required = true
        xml.required = true
    }

    // QueryDSL QDomain 제외시키기
    def QDomains = []

    for (qPattern in '**/QA'..'**/QZ') {
        QDomains.add(qPattern + '*')
    }
    
    ...
}

tasks.named('test') {
    ...
    // test 수행 이후 리포트 생성
    finalizedBy jacocoTestReport
}

jacoco에서 제공하는 테스트 리포트 발행을 위해 사용하는 부분이다.

test가 실행된 다음에 리포트를 발행해야 하기 때문에 finalizedBy을 통해서 test 실행 이후 동작하도록 만들었다.

finalizedBy는 A task의 성공과 실패에 상관없이 A가 끝나야 B가 실행되기 때문에 주의해서 사용하도록 하자.

(성공해야 실행되도록 하려면 dependsOn을 사용한다. 테스트가 실패하더라도 리포트를 발행해야 하기 때문에 여기서는 finalizedBy를 활용하였다.)

이후, xml과 html에 모두에 대해서 리포트를 발행하도록 하였다.

사실 실제로는 html만 보는 경우가 많아서 꼭 xml까지 하지 않아도 된다고 생각한다.

    ...
    
    // QueryDSL QDomain 제외시키기
    def QDomains = []

    for (qPattern in '**/QA'..'**/QZ') {
        QDomains.add(qPattern + '*')
    }
    afterEvaluate {
        classDirectories.setFrom(
								// 그 외의 매칭되는 클래스도 제외 대상
                files(classDirectories.files.collect {
                    fileTree(dir: it, excludes: [
                            "co.kirikiri.domain.**.**",
                            "**/*Application*",
                            "**/*Config*",
                            "**/*Dto*",
                            "**/*Request*",
                            "**/*Response*",
                            "**/*Interceptor*",
                            "**/*Exception*"
                    ] + QDomains)
                })
        )
    }
    finalizedBy jacocoTestCoverageVerification
    
 }

우리팀은 현재 QueryDSL을 사용하고 있기 때문에 QueryDSL로 인해 생성된 QDomain이라는 것이 존재한다.

이 친구들이 테스트 커버리지에 들어가게 되면 50% 이하로 커버리지가 안 나오는 기이한 현상이 발생하기 때문에 qDomain은 패턴 매칭을 통해서 제외시켜주었다. 또한, Dto나 Config, Exception 같은 클래스는 테스트할 필요가 없다고 생각해서 제외해두었다.

위 코드에서는 도메인과 인터셉터까지 있는데, 인터셉터는 추후 제거할까 생각 중이다. (충분히 테스트가 가능하니까)

도메인의 경우 테스트를 짜고 있기는 하지만, 우리 팀은 공통으로 사용되는 도메인은 페어 프로그래밍을 통해 작성한 다음, 사전에 develop branch에 push를 해두고 분기 처리를 진행하고 있기 때문에 각자의 feature에서는 본인이 맡은 기능이 아니면 도메인에 대한 테스트를 작성하지 않게 된다. 그래서 도메인까지는 커버리지 범위에 두지 않았는데, 나중에 도메인 객체를 전부 작성하게 되면 추가할까 생각 중이다.

마지막으로 리포트를 발행하고 나면 커버리지를 설정할 수 있도록 태스크를 연결해두었다.

이렇게 완성된 리포트의 경우 기본적으로 build/reports/jacoco/test/html 하위에 생성된다.

여기서 jacoco-resources 밑쪽에 있는 index.html이랑 tests 쪽의 index.html 둘로 나뉘어져 있는데, 나오는 정보가 살짝 다르다.

상위에 있는 index.html이 jacoco에 의해서 생성된 리포트이고, 아래의 index.html은 gradle에서 자동으로 만들어주는 것으로 알고 있다.

상위의 index.html의 경우 위와 같이 어느 클래스에서 어떤 파일이 커버리지에 불충족하는지 나오게 된다.

하위의 테스트 리포트는 위와 같이 걸린 시간이나 몇 개의 테스트가 성공하고 실패한지 확인할 수 있다.

build.gradle 설정해주기 - JacocoTestCoverageVerification

jacocoTestCoverageVerification {
    // QueryDSL QDomain 제외시키기
    def QDomains = []
    // qPattern = "*.QA","*.QB","*.QC", ... "*.QZ"
    for (qPattern in '*.QA'..'*.QZ') {
        QDomains.add(qPattern + '*')
    }

   ...
}

이번에는 커버리지에 대한 설정 부분이다.

마찬가지로 QDomain에 대해서는 측정할 필요가 없기 때문에 제거하도록 한다.

 ...
 
 violationRules {
        rule {
            // rule 활성화
            enabled = true

            // 클래스 단위로 룰 체크
            element = 'CLASS'

            // 라인 커버리지를 최소 80% 만족
            limit {
                counter = 'LINE'
                value = 'COVEREDRATIO'
                minimum = 0.80
            }
						
            // 마찬가지로 제거 대상 지정
            excludes = [
                    "co.kirikiri.domain.**.**",
                    "**.*Application*",
                    "**.*Config*",
                    "**.*Dto*",
                    "**.*Request*",
                    "**.*Response*",
                    "**.*Interceptor*",
                    "**.*Exception*"
            ] + QDomains
        }
    }

다음으로는 세부적인 커버리지 룰에 대해서 지정하는 부분이다.

1. element: 커버리지를 체크할 기준 정하기

- BUNDLE: 프로젝트의 모든 파일을 합친 것 (디폴트)
- CLASS: 클래스
- GROUP: 논리적 번들 그룹
- METHOD: 메서드
- PACKAGE: 패키지
- SOURCEFILE: 소스 파일

나는 클래스 단위로 설정하기 위해 CLASS라고 지정해주었으며, 대부분 클래스 단위로 많이 보시는 것 같다.

좀 더 빡세게 하고 싶다면 METHOD로 해도 될 것 같은데, 그럼 너무 확인하기 힘들지 않을까 싶다.

2. counter: limit을 통해 지정할 수 있으며, 커버리지 측정을 위한 최소 단위. 자바 바이트 코드의 실행을 기준으로 측정된다.

- BRANCH: 조건문 등의 분기 수
- CLASS: 클래스 수, 내부 메서드가 한 번이라도 실행되었다면 실행된 것으로 간주한다
- COMPLEXITY: 복잡도
- INSTRUCTION: Java 바이트코드 명령의 수 (디폴트)
- METHOD: 메서드 수, 메서드가 한 번이라도 실행되었다면 실행된 것으로 간주
- LINE: 빈 줄을 제외한 실제 코드의 라인 수, 라인이 한 번이라도 실행되었다면 실행된 것으로 간주

여기서 몇 퍼센트의 커버리지를 가졌을 때 빌드 실패를 터트릴 것인지 설정할 수 있다.

나는 조금 더 빡세게 하고 싶어서 LINE 기준으로 80%의 기준을 잡았다.

조금 더 널널하게 하고 싶다면 METHOD로 해도 될 것 같은데, 어차피 모든 분기점에 대해 테스트를 작성하려면 라인으로 하는 게 가장 나을 것 같다고 생각했다.

3. value: limit을 통해 지정할 수 있으며, 측정한 커버리지를 어떠한 방식으로 보여줄 것인지 정한다.
- COVEREDCOUNT: 커버된 개수
- COVEREDRATIO: 커버된 비율, 0~1 사이의 수로 1이 100% (기본값)
- MISSEDCOUNT: 커버되지 않은 개수
- MISSEDRATIO: 커버되지 않은 비율, 0~1 사이의 수로 1이 100%
- TOTALCOUNT: 전체 개수

커버되지 않은 비율을 보여주는 것보다 커버된 비율을 보여주는 게 팀원들의 사기 충전에 도움이 될 것 같다고 생각했다.

(20%나 못했어요!보다는 80% 했으니까 100%까지 채워봐요~의 느낌이 더 좋은 것처럼?)

4. minimum: counter 값을 value에 맞게 표현하였을 때의 최소값, 이를 통해서 커버리지 판단의 성공 여부가 결정된다고 볼 수 있다.
- 기본적으로 표기한 자리수만큼 value가 출력되기 때문에 90%의 커버리지를 원한다면 0.9가 아닌 0.90으로 입력해줘야 한다. 아니면 0.9로 입력하면 0.9x 값을 모두 0.9로 인식한다!

나는 우선 80% 정도로 설정하였는데, 90%까지 올릴 생각은 있다.

이건 팀원들한테 의견을 물어보고 진행해보려고 한다

5. excludes: 커버리지 측정 시 제외할 클래스를 지정할 수 있다.

- 패키지 레벨의 경로로 지정해야 하며, 경로에는 *와 ?을 사용할 수 있다.

여기는 아까 테스트 리포트 발행했을 때의 경로랑 동일하게 지정해주면 된다.

실행해보기

Test 실행의 경우 ./gradlew test, ./gradlew clean build로도 실행이 가능하고, intellij를 사용하면 gradle 도구를 활용할 수도 있다!

결과를 보면, 아래와 같이 커버리지를 넘지 못했을 때 빌드 실패가 발생하게 된다.

이제 테스트 리포트 보면서 어디가 부족한지 보고 확인하면서 진행하면 된다 ㅎㅎ

참고로, Lombok의 어노테이션에 대한 코드 커버리지가 0%로 나오는 문제를 방지하기 위해서 lombok.config를 추가로 설정해주자.

lombok.addLombokGeneratedAnnotation = true

위와 같이 프로젝트의 최상단 경로에 적용해두어야 적용이 된다.
참고로 아직 메서드 단위로 측정을 패스하는 게 없어서, 커버리지 측정을 원하지 않는 클래스라면 패키지 단위로 묶어두는 게 좋다.

모두 테스트 파이팅

[JPA] @OneToMany 단방향 매핑 시 고려해야 하는 것들

dolmeng2 — Sun, 16 Jul 2023 20:13:50 +0900

들어가기 전

JPA에서 @OneToMany 단방향 매핑보다는 다대일 양방향 매핑을 권장한다는 말을 보았을 것이다.

하지만, 객체지향으로 코드를 설계하다 보면 다대일의 상황보다는 1인 엔티티를 기준으로 N인 엔티티를 조회하는 경우가 더 많고, (적어도 내 경험에서는 그랬다) N인 엔티티가 굳이 1인 엔티티에 대한 정보를 몰라도 됐던 적이 많았다. 그러다 보니 자연스럽게 일대다 단방향 매핑을 많이 사용했었는데, 왜 그랬던 것인지 궁금해서 나름대로 실험을 해보고자 한다.

(ex. 게시글과 게시글 이미지의 관계에서, 게시글 이미지를 기준으로 게시글 정보를 찾아오는 것보다는 게시글을 기준으로 게시글 이미지 정보를 가져오는 게 더 많았음)

기본 엔티티 설계하기

@Entity
class Board(
    @Id @GeneratedValue(strategy = GenerationType.IDENTITY)
    val id: Long = 0L,

    @Embedded
    val title: BoardTitle,

    @Embedded
    val content: BoardContent,

    @Embedded
    var boardTags: BoardTags = BoardTags(Collections.emptyList())
) {

    fun addTag(boardTag: BoardTag) {
        boardTags.addTag(boardTag)
        boardTags = BoardTags(boardTags.tags)
    }
}

하나의 게시글에 제목과 내용 정보가 존재하며, 게시글 태그에 대한 정보가 1:N으로 구성된 엔티티다.

BoardTitle과 BoardContent는 VO이기 때문에 별도로 첨부하지는 않겠다.

여기서 게시글 태그 엔티티에 대해서 어떤 식으로 설정하는지에 따라서 결과가 달라지게 된다.

조인 테이블을 생성하여 일대다 관계 구성하기

@Embeddable
class BoardTags(
    tags: MutableList<BoardTag> = Collections.emptyList()
) {

    @OneToMany(fetch = FetchType.LAZY)
    val tags: MutableList<BoardTag> = tags.toMutableList()

    fun addTag(boardTag: BoardTag) {
        tags.add(boardTag)
    }
}

단순히 @OneToMany 어노테이션만 달았을 때, 생성된 테이블 구조를 보면 board_tags라는 별도의 조인 테이블이 생성된다.

여기서 board_tags에는 board_id와 tags_id라는 필드가 추가되었다. 여기서 board_id의 네이밍은 BoardTags를 가지고 있는 엔티티 (board)의 이름 + _id를 합친 것이고, tags_id의 네이밍은 @OneToMany로 선언한 필드명 (tags) + _id를 붙인 형태이다.

✔️ 저장 테스트

@Test
@Rollback(false) // 테스트 환경에서 롤백되는 것을 방지 
fun save() { 
    val 태그1 = BoardTag(name = "태그1")
    val 태그2 = BoardTag(name = "태그2")
    boardTagRepository.save(태그1)
    boardTagRepository.save(태그2)

    val board = Board(
        title = BoardTitle("제목"), content = BoardContent("내용")
    )
    board.addTag(태그1)
    board.addTag(태그2)

    boardRepository.save(board)
}

가장 먼저, 게시글 태그와 게시글에 대해서 insert 하는 쿼리가 발생한다.
이때, 게시글 태그 저장 시 board_id에 대한 컬럼은 채워지지 않고 name, id에 대해서만 삽입된다.
cf) 키 전략이 IDENTITY이기 때문에 save 시 쿼리가 발생한다.

이후, flush 시점에서 조인 테이블에 위와 같이 insert 쿼리가 발생한다.
즉, 쿼리가 총 5번이나 나가게 되는 것이어서 상당히 비효율적이다.

✔️ 삭제 테스트

게시글에 대한 태그를 삭제하는 테스트이다.
이때, 게시글에 존재하는 태그 정보를 제거하고, 그 다음 게시글의 태그 정보를 제거한다.

@Test
@Rollback(false)
fun delete() {
    // 저장 로직
    val 태그1 = BoardTag(name = "태그1")
    val 태그2 = BoardTag(name = "태그2")
    boardTagRepository.save(태그1)
    boardTagRepository.save(태그2)

    val board = Board(title = BoardTitle("제목"), content = BoardContent("내용"))
    board.addTag(태그1)
    board.addTag(태그2)

    boardRepository.save(board)
    entityManager.flush()
		
		/** 제거 로직 */
    val savedBoard = boardRepository.findById(1L).get()
    savedBoard.boardTags.tags.removeAt(0) // 필수!
    boardTagRepository.deleteById(1L)
}

기본적으로 태그 정보를 제거하려면 deleteById를 사용해야 한다고 생각할 수 있다. 하지만, 바로 deleteById를 사용하게 되면 조인 테이블에 걸려 있는 외래키에 의해서 board_tag 테이블에 있는 필드를 바로 제거할 수 없다.
그래서 board에 존재하는 tag 리스트에서 removeAt을 통해 1차적으로 조인 테이블에 대해서 제거를 해야 한다. (savedBoard.boardTags.tags.removeAt(0))

쿼리를 보면, 우선 조인 테이블인 board_tags에 대해서 delete 쿼리가 발생한다. 이때, board_id를 기준으로 제거하기 때문에 board_tags에 저장된 2개의 레코드 모두가 제거된다. 이후, 제거되지 않은 남은 레코드에 대해 (tags_id = 2인 레코드) 다시 삽입하는 과정이 발생한다. 만약, board_id = 1인 레코드가 5개가 있었다면 5개 모두에 대해 제거하고, 4개에 대해서 추가적인 insert 쿼리가 발생하여 더 불필요한 쿼리가 발생하였을 것이다.

최종적으로 위의 과정이 끝나고 board_tag에 대해서 최종적인 태그 제거 쿼리가 발생한다.

결과적으로 insert 쿼리로 인해서 원하지 않는 쿼리가 엄청 나갈 수도 있다는 특징을 가진다.

조인 테이블을 없애보기

조인 테이블에 의해서 insert 쿼리가 발생한 것이라면, 조인 테이블 자체를 없애면 되지 않을까?

@Embeddable
class BoardTags(
    tags: MutableList<BoardTag> = Collections.emptyList()
) {

    @OneToMany(fetch = FetchType.LAZY)
		@JoinColumn(name = "board_id")
    val tags: MutableList<BoardTag> = tags.toMutableList()

    fun addTag(boardTag: BoardTag) {
        tags.add(boardTag)
    }
}

@JoinColumn을 통해서 board_tag에 명시적으로 board에 대한 아이디를 저장할 수 있는 필드를 지정해주면 된다.
1:N 관계에서 외래키는 항상 N 테이블에 걸리기 때문에 n쪽에서 column 정보를 지정해준다.

생성된 테이블을 보면, 이번에는 조인 테이블 대신 board_tag 테이블에 board 정보를 지정하기 위한 board_id 정보가 추가된 것을 볼 수 있다.

✔️ 저장 테스트

@Test
@Rollback(false) // 테스트 환경에서 롤백되는 것을 방지 
fun save() { 
    val 태그1 = BoardTag(name = "태그1")
    val 태그2 = BoardTag(name = "태그2")
    boardTagRepository.save(태그1)
    boardTagRepository.save(태그2)

    val board = Board(
        title = BoardTitle("제목"), content = BoardContent("내용")
    )
    board.addTag(태그1)
    board.addTag(태그2)

    boardRepository.save(board)
}

먼저, 태그 2개가 저장된 결과이다.
마찬가지로 name, id만 값이 채워져서 board_id에 대한 컬럼은 null 값을 가지게 된다.

그리고, 게시글에 대한 insert 쿼리가 발생한다.

하지만, 여기서 문제가 발생한다. board_tag에 대해 추가적으로 업데이트 쿼리가 발생한 것이다.

이는 처음에 board_tag를 저장할 때 board_id에 대한 정보가 없는 상태였기 때문에 flush 시점에 board.addTag()로 인해 추가된 정보를 바탕으로 업데이트를 하게 된 것이다.

위와 같이 @OneToMany 단방향에서는 데이터 저장 시 업데이트 쿼리가 발생할 수 있다는 단점이 있다.

✔️ 삭제 테스트

@Test
@Rollback(false)
fun delete() {
    // 저장 로직
    ...

    // 강제 flush -> update 쿼리 발생
    entityManager.flush()

    // 조회 -> 영속성 컨텍스트에서 발생
    val savedBoard = boardRepository.findById(1L).get()
	
   // 보드에 존재하는 보드 태그 제거
    savedBoard.boardTags.tags.removeAt(0)
    
   // 보드 태그 제거
    boardTagRepository.deleteById(1L)
}

entityManager.flush 이후의 로직에서 발생하는 쿼리이다.
저장 후 영속성 컨텍스트에서 게시글을 조회한 뒤, 해당 게시글에 연관된 태그를 제거하였다. removeAt(0)을 진행하게 되면 게시글 기준으로 ‘게시글의 첫 번째 태그 정보가 제거’ 된 것이기 때문에 id = 1인 board_tag에 존재하는 board_id를 null로 세팅하는 쿼리가 발생한다.

이는 사실 Hibernate의 flush 순서와 좀 더 가까운 문제이다. Hibernae에서 자식 엔티티를 FK 없이 저장하고 컬렉션에 대해 처리를 하게 되면 FK에 대한 update 쿼리가 발생하기 때문이다. 현재 테이블 구조 상 FK가 걸리지 않아서 FK가 없는 상태니까 update 연산이 먼저 발생하고 엔티티에 대한 delete가 발생한 것이다.

cf) 참고로, update - delete 모두 flush 시에 발생하며 실제로 board_tag를 제거하지 않는다면 (deleteById) 두 쿼리 모두 발생하지 않는다. delete 시에 추가로 update 쿼리가 발생하는 느낌이다.

Hibernate의 flush 순서는 다음과 같다.

1. OrphanRemovalAction
2. AbstractEntityInsertAction
3. EntityUpdateAction
4. QueuedOperationCollectionAction
5. CollectionRemoveAction
6. CollectionUpdateAction
7. CollectionRecreateAction
8. EntityDeleteAction

+ 무조건 '제거 행위'를 한다고 해서 update 쿼리가 발생하는 것은 아니다.

@Test
@Rollback(false)
fun delete() {
    // 저장 로직
    ...

    // 강제 flush -> update 쿼리 발생
    entityManager.flush()

    // 조회 -> 영속성 컨텍스트에서 발생
    val savedBoard = boardRepository.findById(1L).get()

    // 보드 태그 제거
    boardTagRepository.deleteById(1L)
}

하지만, removeAt()을 통해서 제거하지 않는다면 단순한 delete 쿼리만 발생한다.

단순히 boardTag의 id 값만을 참고하여 delete를 하기 때문에, board_id에 대한 정보가 딱히 없기 때문이다. (이전에는 게시글을 기준으로 태그 정보를 제거하였기 때문)

그래서 삭제 시에 update 쿼리가 무조건적으로 발생한다는 말은 틀린 말이다.

그렇다면, 일대다 단방향은 아예 쓰면 안 되는 걸까? - updatable = false 지정하기

그렇다면 우리는 항상 일대다 단방향을 사용하면 이렇게 update 쿼리를 봐야 하는 것일까?

update 쿼리를 없애고 싶을 것이다. 그렇다면, 추가적으로 board_id에 대한 업데이트가 진행되지 않도록 쿼리 자체에 updatable에 대한 조건을 false로 지정해보자.

@Embeddable
class BoardTags(
    tags: MutableList<BoardTag> = Collections.emptyList()
) {

    @OneToMany(fetch = FetchType.LAZY)
    @JoinColumn(name = "board_id", updatable = false)
    val tags: MutableList<BoardTag> = tags.toMutableList()

    ...
}

위와 같이 updatable=false를 지정하게 되면, board_tag 테이블에 존재하는 board_id 필드는 수정 불가능 상태가 된다.

즉, 한 번 지정된 연관관계를 다시 세팅하는 것이 불가능하게 된 것이다.

✔️ 저장 테스트

@Test
@Rollback(false)
fun save() {
    val 태그1 = BoardTag(name = "태그1")
    val 태그2 = BoardTag(name = "태그2")
    boardTagRepository.save(태그1)
    boardTagRepository.save(태그2)

    val board = Board(
        title = BoardTitle("제목"), content = BoardContent("내용")
    )
    board.addTag(태그1)
    board.addTag(태그2)

    boardRepository.save(board)
}

update 쿼리는 발생하지 않지만, 처음 board_tag를 삽입할 때 board_id에 대한 정보가 지정되지 않는 상태로 insert가 된 것을 볼 수 있다. 추후 board가 삽입되더라도 계속 board_tag의 board_id는 계속 null로 남게 되는 것이다.

✔️ 삭제 테스트

@Test
@Rollback(false)
fun delete() {
    // 저장 로직
    ...

    // 강제 flush -> update 쿼리 발생
    entityManager.flush()

    // 조회 -> 영속성 컨텍스트에서 발생
    val savedBoard = boardRepository.findById(1L).get()
		
    // 보드에 존재하는 보드 태그 제거
    savedBoard.boardTags.tags.removeAt(0)

    // 보드 태그 제거
    boardTagRepository.deleteById(1L)
}

하지만, 삭제 테스트에서는 보드에 존재하는 태그 정보를 removeAt으로 제거하더라도 update 쿼리가 발생하지 않는다!

insert 시 이미 board_id가 null이기 때문에 별도의 update 쿼리가 발생할 필요가 없어서 그냥 delete 쿼리만 나간 것이다.

board_id도 값이 채워졌으면 좋겠어! - nullable = false 지정해주기

하지만, 위의 방법은 연관관계가 세팅되지 않으니까 매우 찝찝하다.

board_id가 null인 것이 마음에 들지 않는 것이니까, 애초에 null 값이 들어오지 않도록 만들어보자.

@Embeddable
class BoardTags(
    tags: MutableList<BoardTag> = Collections.emptyList()
) {

    @OneToMany(fetch = FetchType.LAZY)
    @JoinColumn(name = "board_id", updatable = false, nullable = false)
    val tags: MutableList<BoardTag> = tags.toMutableList()
		...
}

✔️ 저장 테스트

@Test
@Rollback(false)
fun save() {
    val 태그1 = BoardTag(name = "태그1")
    val 태그2 = BoardTag(name = "태그2")
    boardTagRepository.save(태그1)
    boardTagRepository.save(태그2)

    val board = Board(
        title = BoardTitle("제목"), content = BoardContent("내용")
    )
    board.addTag(태그1)
    board.addTag(태그2)

    boardRepository.save(board)
}

null 값이 저장되지 않아 원하는 결과가 나올 것 같다고 예상했지만, 위와 같이 오류가 발생한 것을 볼 수 있다.

이는, board_tag에 태그 정보가 저장하는 시점에 board_id에 대한 정보가 들어가야 하는데 현재는 board에 대한 정보가 하나도 없으니 null 값이 들어가려다가 제약 조건 위반으로 인해 예외가 발생한 것이다.

태그 정보가 저장될 때 게시글 정보도 함께 저장할래! - CascadeType 지정하기

그렇다면, board_tag가 저장하는 시점에 board에 대한 정보를 알면 되는 것이 아닐까?
하지만, 우리는 board → board_tag로의 단방향 관계만 가지도록 만들고 싶기 때문에 board_tag가 board에 대한 정보를 알지 않기를 바란다. 이를 위해서는, board_tag를 알고 있는 board가 저장되는 시점에 태그에 대한 정보도 함께 저장되도록 만들 수 있다.

@Embeddable
class BoardTags(
    tags: MutableList<BoardTag> = Collections.emptyList()
) {

    @OneToMany(fetch = FetchType.LAZY, cascade = [CascadeType.PERSIST])
    @JoinColumn(name = "board_id", updatable = false, nullable = false)
    val tags: MutableList<BoardTag> = tags.toMutableList()

    ...
}

위와 같이 cascade 옵션을 활용하여 PERSIST로 지정해주자.
이러면 board가 저장되는 시점에 board_tag 정보도 함께 알게 된다.

✔️ 저장 테스트

기존의 저장 로직을 변경하여, board가 저장될 때 board_tag도 함께 지정하여 저장해보자.

@Test
@Rollback(false)
fun save_casacde() {
    val boardTags = mutableListOf(BoardTag(name = "태그1"), BoardTag(name = "태그2"))
    val board = Board(
        title = BoardTitle("제목"), content = BoardContent("내용"),
        boardTags = BoardTags(boardTags)
    )
    boardRepository.save(board)
}

먼저, board에 대한 정보가 저장되는 insert 쿼리가 발생하는 것을 볼 수 있다.

그리고, board_id가 1로 채워진 board_tag에 대한 insert 쿼리가 발생하는 것을 볼 수 있다.
즉, update 쿼리가 발생하지 않으면서 우리가 원하는대로 잘 동작하는 것이다.

@OneToMany 양방향

처음부터 양방향으로 설정하게 된다면 별도의 설정 필요 없이도 잘 동작한다.

그러나, 양방향 연관관계를 설정하기 위한 연관관계 편의 메서드가 존재해야 한다.

@Entity
class Board(
    @Id @GeneratedValue(strategy = GenerationType.IDENTITY)
    val id: Long = 0L,

    @Embedded
    val title: BoardTitle,

    @Embedded
    val content: BoardContent,

    @Embedded
    var boardTags: BoardTags = BoardTags(Collections.emptyList())
) {

    fun addTag(boardTag: BoardTag) {
        boardTag.board = this // here!
        boardTags.addTag(boardTag)
        boardTags = BoardTags(boardTags.tags)
    }
}

@Embeddable
class BoardTags(
    tags: MutableList<BoardTag> = Collections.emptyList()
) {

    @OneToMany(fetch = FetchType.LAZY, mappedBy = "board")
    val tags: MutableList<BoardTag> = tags.toMutableList()
    
    ...
}

@Entity
class BoardTag(

    @Id @GeneratedValue(strategy = GenerationType.IDENTITY)
    val id: Long = 0L,

    val name: String,

    @ManyToOne(fetch = FetchType.LAZY)
    var board: Board? = null
) {
	...
}

addTag() 메서드에서 연관관계를 세팅해주기 위해 boardTag.board = this라는 메서드를 추가해주었다.

✔️ 저장 테스트

@Test
@Rollback(false)
fun save() {
    val 태그1 = BoardTag(name = "태그1")
    val 태그2 = BoardTag(name = "태그2")

    val board = Board(
        title = BoardTitle("제목"), content = BoardContent("내용")
    )
    board.addTag(태그1)
    board.addTag(태그2)

    boardRepository.save(board)
    boardTagRepository.save(태그1)
    boardTagRepository.save(태그2)
}

양방향 연관관계가 설정되었기 때문에 태그를 먼저 저장하는 대신에, 게시글에 대해서 먼저 저장해준다.
이때 board.addTag() 시 board에 대한 연관관계도 설정되기 때문에 자연스럽게 boardTag가 저장되는 시점에 board에 대한 정보를 알게 되어 insert 시 업데이트 쿼리가 발생하지 않는다.

실제로 쿼리 정보를 보면, 먼저 게시글에 대한 insert 쿼리가 발생한다.

그리고, board_tag에 대해서 insert 쿼리가 발생할 때도 board_id에 대한 정보가 잘 채워져서 삽입되는 것을 볼 수 있다.

✔️ 삭제 테스트

@Test
@Rollback(false)
fun delete_bidirection() {
    // 저장 로직
    ...

    // 조회 -> 영속성 컨텍스트에서 발생
    val savedBoard = boardRepository.findById(1L).get()

    // 보드에 존재하는 보드 태그 제거
    savedBoard.boardTags.tags.removeAt(0)

    // 보드 태그 제거
    boardTagRepository.deleteById(1L)
}

이때도 단순히 board_tag에 대한 delete 쿼리 한 번만 발생하게 된다.
tags.removeAt(0)을 진행하더라도 외래키 제약조건으로 인해서 update 쿼리가 발생하지 않고 바로 엔티티에 대한 delete가 발생하게 된다.

결론

- @OneToMany 단방향 관계에서는 불필요한 update 쿼리가 발생할 수 있다.
- 이를 해결하기 위해서는 nullable = false, updatable = false를 지정해주고 부모 엔티티가 영속화될 때 자식 엔티티도 함께 영속화될 수 있도록 PERSIST 옵션을 지정하자.
- 그런 하위 관계가 아니라면 양방향 관계를 고려하자.

일대다 단방향은 부모 엔티티와 자식 엔티티의 생명주기가 같을 경우만 사용하도록 하자! (완전한 하위 관계일 때)

그게 아니라면 양방향으로 설정하거나, 아니면 그냥 엔티티끼리 연관관계를 가지는 게 아니라 단순히 id 값을 필드로 가지도록 만들 것 같다.

[Real MySQL 8.0] 인덱스와 B-Tree 알아보기

dolmeng2 — Mon, 10 Jul 2023 21:40:49 +0900

디스크 읽기 방식

HDD (하드 디스크 드라이브) / SSD (솔리드 스레이트 드라이브)

https://texit.tistory.com/15

메모리에 비해 실제 하드웨어 장치의 발전은 비교적 느리게 발전한다는 소리를 들은 적이 있을 것이다. 특히 HHD는 플래터(원판)을 돌려서 읽고나 쓰다 보니 성능이 매우 느릴 수밖에 없다. 이를 보완하기 위해 등장한 SSD의 경우 기존 하스크 드라이브에서 데이터 저장용 플래터(원판)을 제거하고 그 대신 플래시 메모리를 장착해서 빠르게 데이터를 읽고 쓸 수 있다. 플래시 메모리는 전원이 없어도 데이터가 삭제되지 않으며, 메모리보다는 느리지만 그래도 하드 디스크 드라이브보다는 훨씬 빠르다.

랜덤 I/O와 순차 I/O

디스크 읽기 연산에서 '랜덤 I/O'와 '순차 I/O'라는 말을 들은 적이 있을 것이다.

랜덤 I/O나 순차 I/O 모두 하드 디스크 드라이브 플래퍼(원판)을 돌려서, 읽어야 할 데이터가 저장된 위치로 디스크 헤더를 이동시킨 다음 다음 데이터를 읽는 것이다. 하지만, 순차 I/O의 경우 3개의 페이지를 기록할 때 1번의 시스템 콜을 사용하지만, 랜덤 I/O는 3번의 시스템 콜을 요청한다. 이는, 랜덤 I/O의 경우 읽어야 하는 데이터가 물리적으로 불연속한 위치에 존재하기 때문에 헤드를 이동시키고 시스템 콜을 호출하지만, 순차 I/O는 그대로 읽기만 하면 되기 때문에 1번이면 충분하기 때문이다. 즉, 순차 I/O가 랜덤 I/O보다 약 3배 빠르다는 것이다. 그래서 여러 번 쓰기나 읽기를 하는 랜덤 I/O 작업이 부하가 더 크다.

SSD의 경우 플래터가 없어서 별 차이가 없다고 생각할 수 있다.
하지만, SSD에서도 순차 I/O에 비해 랜덤 I/O의 throughout은 떨어진다고 한다.

기본적으로 디스크의 성능은 얼마나 많은 데이터를 한 번에 기록하느냐에 의해서 결정된다.
랜덤 I/O와 순차 I/O 모두 파일 쓰기 실행 시 동기화 작업 (flush or fsync) 작업이 필요한데, 순차 I/O의 경우 동기화 작업이 너무 빈번하면 랜덤 I/O처럼 비효율적으로 처리할 수 있어서 보통 RAID 컨트롤러의 캐시 메모리의 경우 효율적으로 순차 I/O를 처리할 수 있도록 도와주기도 한다.

보통 쿼리를 튜닝한다는 것은 랜덤 I/O를 어떻게 줄이는 것인지가 포인트이다.

밑에서 다루겠지만, 인덱스 레인지 스캔은 데이터를 읽을 때 랜덤 I/O를 사용하고 풀 테이블 스캔은 순차 I/O를 사용하는데, 오히려 테이블에 데이터가 굉장히 많고 해당 데이터의 대부분을 조회하는 경우에는 일부러 풀 테이블 스캔을 사용하여 역으로 순차 I/O를 통해 처리하는 경우도 존재한다. 순차 I/O의 경우 더 빠르고 많은 데이터를 읽을 수 있어서 OLTP (On-Line Transaction Processing) 성격의 서비스보다 통계 작업에서 자주 사용된고 한다.

- 클러스터링 인덱스를 활용해서 레인지 스캔을 하게 되면, 실제 물리적인 쿼리 위치가 정렬된 상태를 유지하기 때문에 "데이터를 순서대로 조회한다면" 랜덤 I/O가 아닌 순차 I/O를 진행하게 된다. 물론, 순서대로가 아닌 중간중간 몇 개씩만 데이터를 조회한다면 랜덤 I/O를 진행하게 될 것이다.

- 반대로, 세컨더리 인덱스를 사용하게 되면 클러스터링 인덱스를 가리키고 있고, 물리적인 위치가 정렬되지 않기 때문에 분산이 되어 있을 것이다. 그래서 순차 I/O에 비해서 랜덤 I/O를 사용하여 동작하게 될 것이다.

인덱스

인덱스란 컬럼의 값과 해당 레코드가 저장된 주소를 key-value로 삼아 만드는 것을 의미한다. 이때, 컬럼의 값은 주어진 순서대로 미리 정렬해서 보관하며, 인덱스가 많은 테이블은 CUD 작업은 느리지만, R에서 독보적인 성능을 보인다.

프라이머리 인덱스와 세컨더리 인덱스

프라이머리 인덱스는 레코드를 대표하는 컬럼의 값으로 만들어진 인덱스로, 테이블에서 레코드를 식별할 수 있는 기준값을 사용한다. 기본적으로 NULL과 중복을 허용하지 않는다. 반대로 세컨더리 인덱스는 PK를 제외한 나머지 필드로 인덱스를 만들었을 때 생성되는 것을 의미한다. 유니크 인덱스의 경우 대체 키라고도 하는데, 세컨더리 인덱스로 볼 때도 있고 그냥 아예 별도로 분리할 때도 있어서 알아만 두자.

B-Tree 인덱스 (Balanced Tree)

인덱스 구조 중에 가장 많이 사용하는 타입은 B-Tree이다. (AVL 등 다른 구조도 있지만, B-Tree가 블록 단위로 데이터에 대한 I/O 작업을 진행할 때 가장 효율적으로 사용할 수 있기 때문이다.) 인덱스는 페이지 단위로 저장되며, 인덱스 키를 기준으로 항상 정렬된 상태를 유지한다는 것이 특징이다.

왼쪽에 있는 부분이 B-Tree 인덱스라고 생각하면 되고 (루트 노드 생략), 오른쪽이 프라이머리 키 인덱스이다. (= 클러스터 인덱스)

최상위는 루트 노드, 중간은 브랜치 노드, 가장 하위는 리프 노드라고 말하는데, 루트와 브랜치는 본인의 하위 자식 노드의 주소를 가지고 있으며, 리프 노드의 경우 데이터 파일에 저장된 레코드 주소를 가지고 있다. 또한, 인덱스의 키 값은 항상 정렬되어 있지만 데이터 파일의 레코드는 정렬이 되어 있지 않아서 일반적인 DBMS에서는 INSERT 순서로 저장하는 것이 아닌 중간에 DELETE로 인해 비어있는 공간이 생기면 해당 위치에 삽입이 진행된다. (즉, 임의의 순서) 하지만, 특별하게 innoDB의 경우 레코드가 클러스터되기 때문에 PK 순서대로 정렬되어 저장되기 때문에 PK 자체가 ROWID (실제 레코드의 물리적인 주소) 역할을 하며, 이로 인해 PK가 '논리적인 주소'를 가진다고 말한다. (myISAM에서는 세컨더리 인덱스가 물리적인 주소를 가짐)

그래서 innoDB 테이블은 인덱스를 통해 데이터를 읽어도 바로 데이터 파일을 찾을 수 없으며, 인덱스 영역에 저장된 PK를 통해 PK 인덱스를 한 번 더 검색한 다음, PK 인덱스의 리프 페이지에 저장된 레코드를 읽는다. 즉, 모든 세컨더리 인덱스 검색에서 데이터 레코드를 읽으려면 PK를 저장하고 있는 B-Tree를 다시 검색해야 한다.

참고로, 기본적으로 PK로 레코드를 조회할 때 데이터 파일은 정렬되어 있지 않아서 PK 자체가 어느 페이지에 저장되어 있는지 알 수 없기 때문에 랜덤 I/O 발생 후, 해당 PK 값을 따라가서 리프 노드에 저장된 실제 레코드를 받아오게 되는 것이다.

B-Tree 인덱스 키 추가

B-tree에 새로운 키를 추가하기 위해서는 저장될 위치를 결정한 다음, 레코드의 키 값과 대상 레코드의 주소 정보를 B-Tree의 인덱스에 저장한다. 만약, 리프 노드가 꽉차면 해당 노드를 분리하는데, 이때 상위 브랜치 노드까지 처리 범위가 넓어져서 새로운 키를 추가하기 때문에 (부모로 승격하는 것) 해당 연산은 비용이 많이 드는 작업이다.

보통 레코드 추가 작업이 1이라면 테이블의 인덱스에 키를 추가하는 비용은 1.5 정도로 측정하며, 예를 들어 인덱스가 3개라면 1.5 * 3 + 1 = 5.5 정도를 비용으로 생각한다. innoDB에서는 체인지 버퍼를 활용하여 인덱스 키를 추가하는 작업을 지연시킬 수 있지만, PK, UK 같이 유니크 제약 조건이 걸려있을 경우 중복 체크를 해야 하기 때문에 즉시 B-Tree에 추가하거나 삭제하는 작업을 진행한다.

체인지 버퍼
체인지 버퍼는 특정 데이터 페이지가 버퍼 풀에 없을 때 세컨더리 인덱스 페이지에 대한 변경 사항을 캐시하는 데이터 구조이다,
인덱스 삽입 / 업데이트 시 디스크에 대한 랜덤 I/O 연산이 비용이 크기 때문에 변경이 필요한 인덱스 페이지가 버퍼 풀에 있으면 바로 업데이트를 하고, 디스크로부터 읽어와야 한다면 인서트 버퍼에 저장했다가 사용자에게 결과를 바로 반환하도록 최적화한다.
- 지연된 작업은 추후 다른 읽기 작업을 통해 버퍼 풀에서 페이지 로드 시 merge

- 사용자 쿼리 실행 -> 버퍼 풀에 변경 사항이 발생한 페이지 (B-Tree의 리프 노드) 있다면 즉시 변경 사항 반영 -> 버퍼 풀에 페이지 없으면 인서트 버퍼에 임시로 기록해두고 쿼리 실행 완료 -> 추후 인덱스 페이지를 읽을 때마다 인서트 버퍼에서 머지해야 하는 키값을 확인한 다음 병합 (B-Tree 인덱스 반영)

B-Tree 인덱스 키 삭제

인덱스 키 삭제 시 삭제할 키 값이 저장된 B-Tree의 리프 노드를 찾아서 삭제 마킹 처리를 진행한다. 마킹된 공간은 방치할 수도 있고, 재활용할 수도 있는데 마킹 작업 역시 디스크 I/O 작업이 필요해서 비용이 크다. 마찬가지로 MySQL 5.5 이상부터는 인덱스 추가처럼 지연 처리가 가능하다.

B-Tree 인덱스 키 변경

인덱스 키 값은 해당 값에 따라 저장될 리프 노드의 위치가 결정되기 때문에, B-Tree의 키 값이 변경되면 인덱스의 키 값만 변경하는 것은 불가능하다. 그래서 보통 먼저 키 값을 삭제한 뒤 새로운 키 값을 추가한다. 변경 역시 마찬가지로 지연 처리가 가능하다.

B-Tree 인덱스 키 검색

기본적으로 키 탐색 시 ‘트리 탐색’ 기법을 사용하여 조회한다.

100% 값이 일치하는지 찾는 equality 비교나 부등호 비교 조건, 혹은 like에서 앞부분만 일치하는 경우 (like%)에 대해서 인덱스가 걸린 필드를 사용하면 가능하지만, 인덱스 값을 변형한 다음에 사용한다면 빠른 검색을 활용할 수 없다.

또한, innoDB 테이블의 경우 검색 시 넥스트 키 락이나 레코드 락을 통해서 인덱스를 잠그고 테이블의 레코드를 잠그기 때문에, UPDATE / DELETE 시 테이블에 사용할만한 인덱스가 없으면 불필요하게 많은 레코드를 잠글 수 있기 때문에 인덱스 설계를 잘해야 한다. (테이블 전체에 락이 걸릴 수도 있으니 주의해야 함)

B-Tree 인덱스 사용 시 고려할 요소

B-Tree에서 인덱스를 사용할 때 인덱스를 구성하는 컬럼의 크기와 레코드 건수, 유니크한 인덱스 키 값의 개수 등을 잘 설정해야 한다.

인덱스 키 값의 크기

innoDB의 데이터 저장 시 가장 기본 단위를 페이지 or 블록이라고 한다. (버퍼 풀에서 데이터를 버퍼링하기 위한 기본 단위이기도 하다) 이때, 인덱스 역시 페이지 단위로 관리되며, 루트, 브랜치, 리프 노드를 구분하는 기준이 ‘페이지’이다. (기본은 16KB)

일반적으로 B-Tree 구조에서 자식 노드의 개수는 가변적이기 때문에 인덱스의 페이지 크기와 키 값의 크기에 따라서 결정된다.

위 그림을 기준으로 하면 하나의 인덱스 페이지에 총 16*1024/(16+12) = 585개의 키를 저장할 수 있으며, 자식 노드를 585개 가질 수 있는 B-Tree가 된다. (현재 키 값은 16바이트) 하지만, 인덱스 키 값이 32바이트로 늘어난다면 16*1024/(32+12) = 372개가 저장되며, 만약 한 번 SELECT 시 500개 이상의 데이터를 읽어야 한다면 두 번째 경우는 디스크를 2번 읽어야 해서 더 느려지게 된다.

즉, 인덱스 키 값이 길어지면 전체적인 인덱스의 크기도 커지기 때문에, 제한된 크기의 버퍼 풀에서 하나의 레코드를 위한 인덱스 크기가 커지면 메모리에 캐시할 수 있는 레코드의 수가 줄어들어 결국 효율성 역시 떨어지게 된다.

B-Tree 깊이

B-Tree의 깊이는 직접 제어가 불가능하다. 만약 B-Tree의 깊이가 3이라고 가정한다면 위의 예제에서 최대 2억 (585^3)을 가지지만, 인덱스 키 값이 32바이트라면 최대 5천만 (372^3)이라서 줄어들고, 결국 디스크 접근 횟수가 또 늘어나는 결과를 초래한다. 웬만하면 깊이는 작게 만들자.

선택도(Selectivity) = 기수성(Cardinality)

선택도란 모든 인덱스 키 값중 유니크한 값의 수를 의미한다. 만약 테이블의 레코드에서 중복값이 많아졌다면 기수성이 낮다고 볼 수 있고, 기수성이 낮으면 검색해야 하는 대상이 많아져서 속도가 느려지게 된다.

ex) 전체 레코드 수는 10000개일 때 쿼리 조건에 일치하는 레코드가 1개라면?
이때, 특정 컬럼 A에 대해 유니크한 값의 개수가 10개라면 9개를 더 읽게 되는 것이고, 유니크한 값의 개수가 1000개라면 999개를 더 읽은 것이 된다. 즉, 후자의 경우가 비효율적인 방식이 된다.

하지만, A 컬럼에 인덱스를 걸었다면 인덱스된 컬럼에 대해서 전체 레코드의 개수나 유니크한 값의 개수 등의 통계 정보를 가지고 있다. (인덱스별로 평균 몇 개의 레코드가 있는지 미리 계산하는 것) 이때 전자의 경우 10000 / 10 = 1000개를 미리 읽게 되어, 1개만 일치한다면 999개가 낭비된다. 반면, 후자의 경우 10000 / 1000 = 10개를 미리 읽게 되어, 9개가 낭비되기 때문에, 인덱스를 걸면 오히려 결과가 반대되는 것을 볼 수 있다. 그래서 인덱스의 경우 유니크한 값의 개수가 많을수록 더 효율적이다.

데이터를 몇 개나 읽어와야 할까?

일반적인 DBMS의 옵티마이저는 인덱스를 통해 레코드 1건을 읽는 게 직접 레코드에서 데이터를 읽는 것보다 4~5배 정도 비용이 많이 든다고 예측한다. 그래서 인덱스를 통해 읽을 레코드의 개수가 전체 테이블 레코드의 20~25%를 넘는다면 인덱스를 사용하지 않고 그냥 풀테이블 스캔 + 필터링이 더 효율적이다.

인덱스 레인지 스캔

검색해야 할 인덱스의 범위가 결정됐을 때 사용하는 방법이다. 루트 노드부터 비교를 시작해서 브랜치 노드를 거치고, 최종적으로 리프 노드까지 찾아 들어가야 필요한 레코드의 시작 지점을 찾을 수 있다. 시작 지점을 찾은 이후, 리프 노드의 데이터만 순서대로 읽으며, 하나의 리프 노드를 다 읽으면 다음 리프 노드로 이동해서 또 다시 스캔한다. 이때, 인덱스의 특성으로 인해 오름차순 / 내림차순으로 정렬된 상태로 데이터를 가져오게 된다. 그리고, 조건을 다 찾으면 반환 후 쿼리를 종료한다.

SELECT * FROM crew WHERE name BETWEEN Ice AND Journey

리프 노드 5번 페이지에 도달하기 위해서 루트 노드, 브랜치 노드에서 찾아들어간다. 이후 찾은 다음에는 쭉 레인지 스캔을 진행하며 ‘Journey’ 레코드를 찾을 때까지 쭉 스캔하다가 찾으면 반환하게 된다.

단, 인덱스의 리프 노드에서 검색 조건에 일치하는 것들의 레코드 주소 값을 바탕으로, 데이터 파일로부터 읽어와야 하기 때문에 (일치하는 개수만큼 디스크에서 처리해야 함) 랜덤 I/O 작업이 발생하여 비용이 상당히 크다.

인덱스 레인지 스캔 과정
1. 인덱스에서 조건을 만족하는 값이 저장된 위치를 찾는다. (index seek)
2. 탐색된 위치로부터 필요한 만큼 인덱스를 읽어나간다. (index scan)
3. 읽은 인덱스 키와 레코드 주소를 통해 데이터 페이지를 가져오고, 저장된 레코드를 읽어온다. (랜덤 I/O)
- 만약 커버링 인덱스를 사용한다면 디스크의 레코드를 읽어오지 않기 때문에 랜덤 읽기가 줄어들고 성능이 빨라진다.

커버링 인덱스란 쿼리를 충족시키기 위한 모든 데이터를 가지고 있는 인덱스로, where, order by, group by 등 조건절에 대해서 사용되는 모든 컬럼이 인덱스 컬럼에 포함되는 경우를 의미한다.

- index seek, index scan 과정은 mySQL에서 다음과 같은 쿼리로 알 수 있다.

SHOW STATUS LIKE 'handler_%';

- handler_read_key: index seek가 실행된 횟수

- handler_read_next, handler_read_prev: index scan에서 읽은 레코드 개수
handler_read_next: 인덱스 정순으로 읽은 레코드 개수 / handler_read_prev: 인덱스 역순으로 읽은 레코드 개수

- handler_read_first, handler_read_last: 인덱스의 첫 번째, 마지막 레코드를 읽은 횟수
보통 MIN(), MAX() 같이 값이 가장 작거나 큰 값을 읽을 때만 증가한다.

참고 - 여기서 모두 인덱스만 읽었는지, 인덱스로 테이블의 레코드만 읽었는지는 구분하지 않는다.

인덱스 풀 스캔

인덱스의 처음부터 끝까지 모두 읽는 방식으로, 조건절에 사용된 컬럼이 인덱스의 첫 번째 컬럼이 아니라면 보통 인덱스 풀 스캔이 발생한다.
ex) 인덱스가 A, B, C 순서지만 쿼리에서는 B, C 컬럼으로 검색하는 경우
인덱스 리프 노드의 제일 앞, 뒤로 이동한 다음, 처음부터 끝까지 스캔한다.

물론, 인덱스가 테이블 크기보다 작기 때문에 테이블 풀 스캔에 비해서는 좀 더 효율적이다.
- 당연히 쿼리에서 필요한 컬럼들이 인덱스에 존재해야 테이블 스캔이 안 일어난다. (다른 컬럼까지 필요하다면 테이블 스캔 발생)

루스 인덱스 스캔

레인지 스캔이랑 비슷하지만, 중간에 필요하지 않은 인덱스 키는 무시하고 다음으로 넘어가는 방식이다. GROUP BY, MIN(), MAX()에 대해 최적화를 하는 경우 사용한다.

SELECT name, MIN(age)
FROM crew
WHERE id BETWEEN 1 AND 100
GROUP BY id;

crew 테이블은 (id, age)로 인덱스가 생성되어 있고, 정렬까지 되어 있는 상태라고 가정해보자.
그렇다면 위의 쿼리를 처리할 때 id 그룹별로 첫 번째 레코드의 age 값만 읽으면 되기 때문에 조건에 만족하지 않는 레코드는 무시하고 스캔을 진행한다.

인덱스 스킵 스캔

ALTER TABLE crew ADD INDEX idx_gender_birth (gender, birth);

crew 테이블에 위와 같이 성별과 생일 정보를 가진 복합 인덱스를 만들어보자.
이때, 위의 인덱스를 사용하기 위해서는 gender에 대한 조건이 꼭 들어가야 했었다.

하지만, MySQL 8.0부터는 birth 컬럼으로도 인덱스 검색이 가능하게 해주는 ‘인덱스 스킵 스캔’ 최적화 기능이 도입되었다!
- explain으로 실행 계획을 보면 type에 range라고 떠있을 것이다.

- gender 컬럼에서 유니크한 값을 다 조회한 다음, 쿼리에 gender 컬럼을 내부적으로 알아서 추가해서 다시 실행하는 형태로 처리된다.

SELECT gender, birth FROM crew WHERE birth >= '2001-03-12'

# 내부적으로 아래와 같이 쿼리 생성 후 최적화
SELECT gender, birth FROM crew WHERE birth >= '2001-03-12' AND gender = 'W'
SELECT gender, birth FROM crew WHERE birth >= '2001-03-12' AND gender = 'M'

enum 값이 아니더라도 인덱스에 존재하는 모든 값을 먼저 추출하고, 이를 바탕으로 인덱스 스킵 스캔을 진행한다.
하지만, 위 기능을 사용하려면 ‘조건이 없는 인덱스의 컬럼의 유니크한 값의 개수가 적어야 하고’, ‘쿼리가 인덱스에 존재하는 컬럼만으로 처리가 가능해야 한다. (커버링 인덱스)’ 만약, 유니크한 값이 많아지면 스캔 시작 지점을 검색하는 작업도 많이 필요해질 것이다. 예를 들어 (gender, birth)라면 gender의 개수만큼 스캔 시작 지점이 생기게 되는 것이니까 유니크한 값이 적어야 한다는 것.

만약, 인덱스 외에 다른 컬럼이 필요하다면 풀 테이블 스캔을 통해서 실행 계획을 수립한다.

다중 컬럼 인덱스 (복합 인덱스)

여러 개의 컬럼을 포함하는 인덱스이다. 인덱스의 두 번째 컬럼은 첫 번째 컬럼에 의존해서 정렬되어 있기 때문에, 첫 번째 컬럼이 똑같은 레코드에 대해서만 유의미하므로, 각 컬럼의 순서는 상당히 중요한 포인트이다.

B-Tree 인덱스의 정렬과 스캔 방향

기본적으로 인덱스의 키 값은 항상 오름차순 / 내림차순으로 정렬된다.

인덱스의 정렬

mySQL 8.0부터는 정렬 순서를 혼합한 인덱스를 사용할 수 있다.

CREATE INDEX idx_name_age ON crew (name ASC, age DESC);

인덱스 스캔 방향

인덱스는 항상 오름차순으로 정렬되어 있지만, 최솟값부터 읽으면 오름차순으로 가져오고 최댓값부터 읽으면 내림차순으로 값을 가져올 수 있다. 즉, 쿼리가 인덱스를 사용하는 시점에 효율적인 방법을 선택하는 것이다.

SELECT * FROM crew 
WHERE name >= 'journey' 
ORDER BY name ASC
LIMIT 4;

이 쿼리의 경우 name의 인덱스를 통해 ‘journey’ 레코드를 찾은 다음, 정방향으로 인덱스를 읽으면서 4개를 가져오면 된다. (ASC)

SELECT * FROM crew 
ORDER BY name DESC
LIMIT 4;

반면에 이 쿼리의 경우 name 인덱스를 역순으로 읽어서 4개만 가져오면 된다. (DESC)

내림차순 인덱스

복합 인덱스에서 내림차순, 오름차순이 혼합되어 있다면 ‘내림차순 인덱스’의 사용도 고려해야 한다.
소량의 레코드를 대상으로 한다면 그냥 그대로 사용해도 되지만, 대량의 레코드를 대상으로 한다면 내림차순 인덱스가 더 효율적일 수 있다.

위 그림에서 4가지의 키워드를 얻어낼 수 있다.

- 오름차순 인덱스: 작은 값의 인덱스 키가 B-Tree의 왼쪽으로 정렬된 인덱스
- 내림차순 인덱스: 큰 값의 인덱스 키가 B-Tree의 왼쪽으로 정렬된 인덱스
- 인덱스 정방향 스캔: 인덱스 리프 노드의 왼쪽 → 오른쪽으로 스캔 (순서대로 읽는 것)
- 인덱스 역방향 스캔: 인덱스 리프 노드의 오른쪽 → 왼쪽으로 스캔 (반대 방향으로 읽는 것)

보통 인덱스 정방향 스캔이 좀 더 빠르게 이루어진다. 이는 페이지 잠금이 인덱스 정방향 스캔에 좀 더 적합하게 설계되었으며, 페이지 내의 인덱스 레코드가 단방향으로만 연결되어 있기 때문이다.

- 리프 노트의 페이지는 이중 연결 리스트로 되어 있는데, 페이지 락 과정에서 데드락 방지를 위해 락을 획득하는 게 정방향에서만 가능하고, 역방향에서는 좀 복잡하기 때문이다. 그래서 구조적으로 인덱스 스캔에는 정방향이 좀 더 적합한 느낌?

- 또한, 인덱스는 페이지 내부에서 4~8개 정도 묶어서 그룹을 만들어, 해당 그룹의 대표키를 뽑아 리스트로 관리한다. (= 페이지 디렉터리) 근데 이 디렉터리가 단방향으로 연결되어 있다 보니 역방향으로 접근이 안 되어서 더 느린 것.
ex) 오름차순 인덱스라면 키값이 오름차순으로 정렬되어 있어 정방향 스캔이 빠른데, 내림차순 인덱스라면 키값이 내림차순으로 정렬되어 있어 역방향 스캔이 좀 더 빠른 느낌... 인 것 같다.

그래서 역방향 스캔을 사용한다면 내림차순 인덱스를 고려해보자.

SELECT * FROM crew
WHERE id = ?
ORDER BY name DESC
LIMIT 10;

위의 쿼리에 대해서 소량이라면 오름차순, 대량이면 내림차순을 사용하는 게 좋다.
오름차순 인덱스: INDEX (id ASC, name ASC);
내림차순 인덱스: INDEX (id DESC, name DESC);

B-Tree 인덱스의 가용성과 효율성

비교 조건의 종류와 효율성

SELECT * FROM crew
WHERE course = 'Backend' and age >= 23;

위와 같은 쿼리에 아래와 같은 인덱스가 추가되었다고 생각해보자.

INDEX (course, age)
INDEX (age, course)

첫 번째 인덱스의 경우 course = 'Backend' and age >= 23인 레코드를 찾은 다음, course=’Backend’가 아닐 때까지 인덱스를 그냥 쭉 읽는다. 이때는 읽은 레코드가 모두 조건절에 해당하는 레코드가 된다.

하지만 두 번째 인덱스의 경우 age >= 23 and course = 'Backend'인 레코드를 찾고, 모든 레코드에 대해서 course=’Backend’인지 경우를 찾아야 한다. (필터링) 왜냐면 course의 경우 age를 기준으로 정렬이 되기 때문에 ‘course’라는 컬럼은 비교 작업을 좁히는데 도움을 주지 않기 때문이다. 단순히 해당 값이 일치하는지에만 사용된다.

여기서 첫 번째 인덱스의 course = 'Backend' and age >= 23을 작업 범위 결정 조건, 두 번째 인덱스의 course = 'Backend'를 체크 조건이라고 한다.

인덱스의 가용성

B-Tree 인덱스는 왼쪽 값을 기준으로 오른쪽 값이 정렬되어 있다. 그래서 왼쪽 부분이 없으면 인덱스 레인지 스캔이 안 된다.
단일 인덱스의 like 검색에서 위 상황을 볼 수 있다.

SELECT * FROM crew WHERE name like '%nez';

name 컬럼에 저장된 값을 한 글자씩 비교해가며 일치하는 레코드를 찾아야 하지만, 위와 같이 왼쪽 부분이 고정되지 않았다면 인덱스의 효과를 보기 어렵다.

또한, 복합 인덱스 인덱스의 경우 선행 컬럼이 없다면 문제가 발생한다.

SELECT * FROM crew WHERE age >= 20;

여기서 course 정보에 대한 조건절이 아닌, age에 대한 조건절이라면 효율적으로 인덱스를 사용할 수 없다.

가용성과 효율성 판단

다음과 같은 조건에서 B-Tree 인덱스를 사용할 수 없다. (작업 범위 결정 조건으로 사용이 불가능)

- NOT EQUAL 비교

WHERE name <> ‘journey’
WHERE name NOT IN (’journey’, ‘hello’)
WHERE age NOT BETWEEN 20 AND 23
WHERE name IS NOT NULL

- LIKE ‘%??’

WHERE name LIKE ‘%ney’
WHERE name LIKE ‘_ney’
WHERE name LIKE ‘%our%’

- 스토어드 함수나 다른 연산자로 인덱스 컬럼이 변형된 후 비교된 경우

WHERE SUBSTRING (name, 1, 1) = ‘J’
WHERE DAYOFMONTH(date) = 1

- NON-DETERMINISTIC 속성의 스토어드 함수가 비교 조건에 있을 경우

WHERE name = function()

- 데이터 타입이 서로 다른 비교

WHERE char_column = 20

- 문자열 데이터 타입의 콜레이션이 다른 경우

WHERE utf8_bin_char_column = euckr_bin_char_column

참고로, MySQL에서는 NULL도 인덱스에 저장된다.

다중 컬럼 인덱스는 아래와 같은 경우에 적용이 안 된다.

CREATE INDEX idx_example (col_1, col_2, col_3, ... col_n)

- col_1에 대한 비교 조건이 없는 경우
- col_1에 대한 비교 조건이 위에서 봤던 사용할 수 없는 경우에 속하는 경우

적용 가능한 경우는 다음과 같다. (i는 2 이상 n 미만)
- col_1 ~ col_(i-1)까지 동등 비교 형태일 때 (=이나 in)
- col_i에 대해 동등 비교 (=이나 in), 크고 작음 비교 (<, >), like로 좌측 일치 비교 (like ‘jour%’)
이때 col_1 ~ col_i는 작업 범위 결정 조건으로, col_i+1 ~ col_n은 체크 조건으로 사용된다.

[우테코 5기] 코끼리끼리팀 - 기획부터 1차 데모데이까지 회고

dolmeng2 — Sat, 8 Jul 2023 01:06:23 +0900

코끼리끼리팀 결성!

나름 열심히 만든 임시 로고 (?) 그림판으로 만들었다.

드디어 레벨 3이 시작하면서 본격적인 팀 프로젝트가 진행되었다.

앞서 레벨 2 회고 때 언급했던 것처럼, 운이 좋게도 내가 아이디어를 냈던 주제로 프로젝트를 진행할 수 있게 되었다.

두 달 동안 함께 할 크루는 두둠, 썬샷, 밀리, 우디, 네이브, 부엉이였다.

약 일주일 정도 함께 진행하면서, 우리 팀의 밸런스가 상당히 좋다는 생각이 자주 들었다.

기본적으로 다들 대화할 때 눈을 마주치고 경청을 잘해주시기도 하고, 그렇다고 말이 없는 것도 아니고 회의도 꽤 재밌게 진행되는 부분이 있어서 좋다. 적당히 내향적이면서 외향적인 사람들이 잘 만난 긍정적인 케이스를 보는 느낌....? 특히 토론할만한 주제에 대해서 20분, 30분도 심도있게 토론하는 시간들이 굉장히 좋았다. 앞으로도 계속 이런 분위기를 유지하면 좋겠다!

6월 27일 - 팀 이름 정하기

처음으로 만나서 간단하게 자기소개도 하고, 슬랙 채널, 피그잼도 만들었다!

그리고 내가 나름 기획자이기 때문에 어떤 의도로 기획을 했는지 간단하게 팀원들에게 소개하는 시간을 가졌다.

사실 이 과정에서 팀 이름을 정하기 위해 엄청 고민을 많이 했었는데... 거의 2시간은 팀 이름 정하는데 쓴 것 같다.

GPT의 도움도 받고, 열심히 짱돌을 굴렸다. 덕분에 아래와 같은 멋진 이름들이 나왔다 ^_^

개인적으로 1번도 좋았는데, 이미 존재하는 서비스의 이름을 빼다보니 저런 식으로 남게 되었다.

8번인 골골도 너무 마음에 들었는데, 재밌게도 투표 결과로 20번이 5표가 받게 되었다.

처음에는 장난처럼 느껴졌지만, '함께'라는 의미를 가진 두 단어인 'Co'와 '끼리끼리'가 만나 꽤 위트있다고 생각한다.

특히 '코끼리'라는 네이밍을 사용하다 보니 우리 서비스의 상징 로고를 정하기도 쉽고, 나름 입에도 잘 붙어서 매력적인 이름이라는 생각이 든다. 주변에서 상당히 놀렸지만, 지금 생각해보면 제일 잘 고른 듯!

이름을 정한 이후에는, 기획에 대해 서로의 멘탈 모델을 일치시키기 위한 토론 시간을 가졌다.

서비스의 방향성이 모호하다 보니 서로가 그리는 이미지가 상당히 달라서 토론이 꽤 길고 오래 걸렸었다

피그잼을 통해서 서로 서비스에서 생각하는 점에 대해 브레인스토밍을 진행하며 어떤 기능을 예상하는지 간단하게 작성했었다.

6월 28일 - 크루들에게 인터뷰 진행하기

첫 날 토론으로는 서로의 생각을 일치시키는 게 힘들 것 같아서, 사용자 시나리오 작성을 통한 고객 모델을 도출해나가기로 했다.

어떤 고객을 대상으로 타겟팅 할지 알아보면서 우리가 어떤 서비스를 제공하면 좋을지 고민하는 시간을 가졌다.

첫 기획 시에는 스터디를 위주로 생각하다 보니 '계획 + 일정 관리 + 스터디'를 위주로 방향성을 가졌었다.

팀원 모두 공부하는 학생들이다 보니 주변에서 가장 쉽게 볼 수 있고 이해하기 쉬운 '스터디 팀원'으로서의 경험을 생각하는 시간을 가졌다.

이후, 약 40분 간의 1:1 전담 인터뷰를 진행하였다.

20문항 정도의 질문을 준비해서 그런지, 한 명 한 명의 인터뷰가 꽤나 길었다.

또한, 정형화된 인터뷰 질문들이 아닌 개개인의 답변 스타일에 맞춰서 조금씩 질문 내용을 수정했었고, 웬만하면 '어떤 서비스가 필요하세요?' 같은 유도 질문보다는 개인의 특성으로 인해 어떠한 행동을 할 때 왜 그렇게 행동하는지, 어떤 점이 좋고 나쁜지를 물어보았다. 즉, 사용자 경험을 위주로 물어보면서 자연스럽게 어떤 서비스가 필요한지 도출해내도록 인터뷰를 신경써서 진행하였다.

인터뷰에 참여해 주신 모든 크루분들에게 감사를...

6월 29일 - 킥오프 미팅과 인터뷰 분석, 페르소나 작성하기

킥오프 미팅 때는 간단한 팀 문화를 정하였다. 우리는 매일 아침 10시 - 10시 30분에 데일리 회고를, 월요일은 1시 30분부터 3시까지 한 주를 여는 회의를, 금요일은 6시 - 6시 30분까지 한주를 마무리하기 위한 회고를 나누기로 하였다.

이후, 기존의 서비스를 사용하면서 불편했던 점들과 어떤 기능을 제공하면 좋을지,

그리고 우테코 크루들이 어떤 성향을 가지고 있는지 간단한 투표 시간을 가졌다. (잠실 캠퍼스 모든 크루들에게 부탁했다...)

투표를 하면서 생각보다 많은 사용자들이 '기존에 짜여있는, 잘 잡혀있는 커리큘럼'에 참여하고 싶다는 사실을 알게 되었고, 이를 바탕으로 단순한 스터디 플랫폼이 아닌 커리큘럼에 대한 정보는 온전히 '크리에이터'의 책임으로, 이에 대해서 팔로워 성향의 사용자들이 참여할 수 있는 플랫폼을 만들기로 결정하였다. 즉, 사용자 모델을 '크리에이터'와 '팔로워'로 나누게 되었던 계기이다.

극히 일부분만 가져옴

이후, 인터뷰의 모든 문항에 대해서 전부 취합하면서 직접 읽어보고, 핵심이 될만한 문장에 다 같이 형광펜을 그으면서 토론하였다.

2-3시간 정도 찐하게 토론을 진행한 다음에, 목적을 도출하는 단계를 가졌다.

'크리에이터 성향 특징 / 팔로워 성향 특징 / 추가되었으면 좋겠는 기능' 3가지로 나누어서 형광펜을 그은 부분을 전부 분류하였다.

발표 자료였지만 잘 정리된 것 같아서 올리는 ㅎㅎ

위에서 도출한 3가지를 바탕으로 5명의 페르소나를 추출하고, 각 사용자들에 맞는 Needs를 분석하는 시간을 가졌다.

3명의 팔로워와 2명의 크리에이터로 나누었으며, 팔로워의 경우 '취업 / 입시 / 취미' 정도로 나누고, 크리에이터의 경우 '지식 공유 / 공동체 생활 주도' 성향을 가지도록 설정하였다. 연령대가 너무 넓다고 느낄 수도 있겠지만, '무언가를 함께 하고 싶은 사람들이 계획을 공유하는 주체인지, 혹은 이에 대해 참여하는 성향인지'에 따라서 분리하였기 때문에 구체적으로 잘 잡았다는 생각이 들었다.

이후, 각 페르소나 별로 어떤 상황인지 묘사하고(GIVEN), 해당 상황에서 어떤 점이 필요한지(WHEN), 그리고 본 서비스를 통해 어떤 점들을 이룰 수 있는지(THEN) 작성하였다. 이 과정에서 각 사용자들이 어떤 기능을 필요로 할지 구체적으로 생각하면서 조금씩 멘탈 모델이 잡히기 시작했다.

지금까지 프로젝트를 진행하면서 페르소나를 잡거나 사용자 시나리오를 생각해본 적이 없었는데, 이런 식으로 진행하다 보니까 본 서비스의 사용자층에 대해서 잘 이해할 수 있었다. 특히, 해당 페르소나의 역할에 완전히 몰입하여 '실제로 이 사람이라면 이런 식으로 우리의 서비스를 사용하지 않을까? 그렇다면, 이 사람은 우리 서비스에서 이런 방향으로 더 잘 뚜렷한 목적을 보이지 않을까?' 같은 토론을 진행할 수 있엇다. 덕분에 단순히 크리에이터와 팔로워만 나누는 것이 아닌, 팔로워 중에서도 무리를 이끼는 것을 좋아하는 사용자인 '골룸 생성자' (우리는 페르소나에서 사용된 '황시진씨'의 이름인 '시진이'라고 내부적으로 많이 말했다.)라는 새로운 사용자 층을 이끌어낼 수 있었다!

가장 오래 걸리는 작업이었지만, 이 과정이 더 찐한 협업을 경험해볼 수 있던 시간을 주었다.

하루 종일 말만 하느라 목도 아프고 조금 힘들었지만, 오히려 토론하는 시간이 너무 재밌었다... 솔직히 시간 가는 줄 몰랐다 ㅎㅎ

6월 30일 - 그라운드 룰과 기획 고도화

이날은 그라운드룰을 정하기로 하였다.

'송파구에서 일을 더 잘하는 11가지 방법'을 바탕으로 만든 팀 그라운드 룰이다.

일주일이 지난 시점에서 6번과 9번은 정말 착실하게 지키고 있기 때문에 매우 마음에 드는 그라운드 룰이다.

깃 레파지토리도 생겨서 위키에다가 다 적어두었다 ✌

사실 무엇보다 8번이 가장 중요하다고 느낀다. 설득에 실패했다면 그 결과에 대한 책임도 내가 져야 한다는 게 얼마나 중요한 것인지, 앞으로 프로젝트를 진행하면서 절대 잊지 않을 항목 중에 하나인 것 같다. 우테코를 넘어서 사람 대 사람으로도 항상 어떤 일을 진행하든 늘 마음 속에 새기고 싶어서 노트에도 적어두었다. ㅋㅋㅋㅋ

커피 도장판도 만들고, 확인했을 때 다는 팀원별 이모지도 있다. (네이브가 만들어 주셨다)

벌써 도장판에 차곡차곡 쌓여가는 중 ^_^...

늘 3인칭으로 출퇴근을 공유하는 귀여운 팀원들 ^_^

이후 남은 시간 동안에는 또 다시 피그잼을 통해서 기획에 대한 회의를 진행하였다.

큰 MVP를 생성한 다음, 각 MVP 별 세부 기능을 간단하게 토론해보았다. 개발 리소스도 생각하면서 사용자 경험과 주어진 기간... 3가지를 모두 도출해내려고 회의를 진행하다 보니 기능 1개만 회의하는데도 거의 1시간이 넘게 걸렸었다.

그래서 이날은 많이 회의는 못했지만, 회의하면서 다시 한 번 우리 팀의 밸런스가 참 좋다고 느꼈다.

부끄럽지만 나는 지금까지 개발을 진행하면서 항상 사용자 경험보다 어떤 기능을 제공할 건지, '하나의 기능 구현'에 초점을 많이 맞췄었는데 그럴 때마다 팀원들이 '이러한 상황에서는 사용자 입장에서 불편하지 않을까요?' 같은 의문점들을 많이 던져주셔서 조금 더 사용자 경험으로서의 서비스 고도화를 진행할 수 있었다.

늘 짧게 게시판 기능이라면 제목 - 내용 - 사진 첨부 - 댓글 같은 정형화된 기능만 생각했던 나 자신에 대해 반성하면서, 하나의 기능을 만들더라도 사용자가 어느 정도의 상호작용을 진행할지, 어떤 상황에서 사용할지, 어떤 불편함을 겪을지 진지하게 고려해야겠다는 생각을 할 수 있던 유익한 시간이었다.

7월 3일 - 본격적인 기획 진행

월요일인 만큼 일주일 동안 할 내용들을 정하였다.

이번 주는 데모데이와 기획을 마무리하는 방향으로 정하였다 ✌

대략적으로 우리 서비스를 사용하기 위해서 어떤 기능이 필요한지 핵심 MVP를 정하고, 내부적으로 필요한 세부 기능을 정하였다.

(물론 저기에서 추후 고도화를 진행하면서 많이 삭제했다!)

월요일 하루종일 기획 회의를 진행하면서 정말 많은 대화를 나누었다.

그러면서 크리에이터는 '로드맵'을 생성하고, 팔로워는 '로드맵'을 따르기 위한 '골룸'이라는 것을 통해 다같이 목표를 이루어나가는 서비스로 방향을 잡을 수 있었다. 팔로워 중에서 조금 더 리드 성향을 가진 '시진이'가 골룸을 생성하는 사람을 맡으면서 시진이에게 어느 정도의 책임을 줘야 할지 많이 고민했다. 또한, 골룸에서 어떤 기능이 필요한지, 너무 CRUD를 위한 프로젝트가 되는 건 아닌지 주의하면서 기능을 설계하였다. 추후 스프린트 고도화를 진행하면서 조금씩 변화하지 않을까 싶다!

7월 4, 5일 - 커밋 컨벤션과 브랜치 전략, 기능 명세서 작성하기

깃 브랜치 전략과 커밋 컨벤션, 그리고 기능 명세서를 작성하는 시간을 가졌다.

하나의 레포지토리에 프론트, 백엔드가 같이 사용해야 하기 때문에 브랜치를 조금 더 세분화하여서 설정하였다.

커밋 메시지는 angularJS를 따르기로 하였다!

그리고 남은 날들은 기능 명세서를 작성하면서 대략적인 제약 조건을 설정하는 시간을 가졌다.

네이브가 좋은 기능 명세서 템플릿을 가지고 계신 덕분에 수월하게 작성할 수 있었다.

또 다시 이 과정에서 엄청 토론도 하고, 특히 골룸(Goal Room) 파트 정할 때 거의 1시간 넘게 얘기한 것 같다...!

특히 서로 종이에 그려가면서 직접 로드맵도 그려보고, 어떤 로드맵을 제공할 수 있을지 생각도 하고, 어떤 식으로 화면에서 표시될지 그려보면서 시간 가는 줄 모르고 왕창 이야기를 했었다.

기능 회의를 하면서 시간만 좀 더 넉넉했다면 더 고도화할 수 있을 텐데... 같은 생각이 계속 들었다.

지금도 기능을 이것저것 붙이면서 꽤 커진 느낌이라, 실제 개발에 들어가면 상당히 간략화하지 않을까 싶다

그래도 이틀 동안 왕창 얘기한 덕분에 꽤나 큰 산을 넘을 수 있었다.

7월 6일 - 데모데이 준비하기

이날은 데모데이 준비를 진행하였다. 사다리 타기로 인해 밀리가 발표를 맡게 되었다... ㅎㅎㅎ

대학 4년 내내 PPT 엄청 만들었던 경험을 바탕으로 엄청 열심히 만들었다.

1차 데모데이에서는 위와 같은 내용이 들어가도록 구성하였다.

사실 작년 기수분들의 데모데이는 모두 뷰까지 나온 상태여서 걱정을 많이 했는데, 다행히 아직 뷰까지 구성한 팀들이 많이 없었다. 우리는 조금 더 프로젝트 기획 부분과 사용자 시나리오에 집중을 하고, 핵심 기능 쪽은 변동 가능성이 있을 것 같아 최대한 간략하게 소개하였다.

개인적인 이야기지만, 옛날에는 백엔드에 대해 완전히 몰랐을 때 어떻게든 팀에 민폐 안 끼치려고 PPT라도 엄청 열심히 만들기 시작한 건데 지금은 재밌어서 만든 게 더 컸다. 내 마음대로 꾸미고, 어떻게 하면 좋은 전달력을 가질지 고민하면서 만들다 보니까 자연스럽게 발표자의 입장에서 생각하게 되고, 우리 서비스에 대한 이해도도 한 번 더 높일 수 있던 시간이었다.

무엇보다 하루만에 만든 PPT 치고 퀄이 상당히 마음에 들게 나왔다.

실제로 발표할 때도 PPT 칭찬해주셔서 뿌듯 ✌

7월 7일 - 1차 데모데이, 디자인 레퍼런스 공유하기

드디어 1차 데모데이 시간이 왔다! 내가 발표자도 아닌데 너무 떨렸었다.

나는 앞에서 ppt 넘겨주는 역할 + QnA 도우미로 갔다. ㅋㅋㅋ 다행히 유튜브에는 안 올라올 것 같다... ^^ ㅎㅎ

순서도 딱 중간인 3번째였어서 적당했는데, 아쉬웠던 건 발표장 분위기가 조금 소란스러웠다.

하지만 무엇보다 밀리가 발표도 너무 잘해주셨고, QnA도 나름 무리없이 잘 말한 것 같아서 만족스러웠다.

그래도 데모데이가 끝나고, 개발을 앞둔 시점에서 고민이 되는 몇 가지 부분들이 있다.

위 질문은 받았던 QnA 중 하나이다.

사실 2차 데모데이 때 구현하려고 했던 내용 중에 사용자 인증 / 인가가 있었는데, 이때 완전한 회원가입 플로우를 다 구축할 생각이었다. (소셜 로그인, 회원가입, 로그인, 비밀번호 암호화, 전화번호 인증... 등등) 하지만, 에자일을 이용하는 다른 팀의 발표를 들으면서 이런 식으로 구축하면 너무 waterfall에 가깝기도 하고, 2차 데모데이까지 우리가 보여줘야 하는 핵심 기능을 만들 수 없겠다는 생각이 들었다.

이전까지는 한 개의 기능을 완전히 구현하고 넘어가야 한다고 생각했는데, MVP를 만족할 수 있는 최소한의 기능을 만들고, 그 다음 고도화를 시켜나간다는 다른 팀의 발표를 듣고 나니까 우리도 조금 방향성을 바꾸는 게 좋겠다는 생각이 들었다. 데모데이가 끝나고 나서 잠깐 이야기 나누어 보았었는데, '한정된 기간 + 사용자의 피드백을 원활하게 받을 수 없는 환경에서도 에자일이 과연 좋은 개발 방법론인가?' 라는 다른 팀원의 의견을 듣고 나서 또 다시 머리에 혼란이 왔다. 생각해 보면 모두 에자일 하세요... 라는 말만 하지, 왜 해야 하는지, 그리고 모든 상황에서 완벽하게 적용되는 개발 방법론은 아님에도 꼭 해야 하는 건지... 그런 의문이 들었다. 물론 내가 에자일을 제대로 공부하지 않았기 때문에 드는 의문일 수도 있다. 그래서 관련해서 몇 가지 레퍼런스를 천천히 공부해보고자 한다.

우선 백엔드 크루들끼리는 회원가입 처리에서 인증 관련이나 소셜 관련은 제외하고, 로드맵 관련 부분, 골룸 관련 부분까지 병렬적으로 기능들을 할당받아서 스프린트를 진행하는 쪽으로 진행하고자 했다. 그리고 2차 대신, 3차 데모데이까지 핵심 MVP가 나올 수 있도록 목표를 세웠다. (아직 스프린트 시작도 안 했고, 얘기를 깊게 나누어 보지는 못했지만 ㅎㅎ 좀 더 고민해보지 않을까?)

아무튼! 끝나고 간단하게 남아서 디자인 관련 레퍼런스만 회의를 진행했다.

핵심 컬러 정도만 대충 잡아두었는데, 능력있는 프론트엔드 팀원분들 덕분에 든든하다... (한껏 기대중)

회고 마무리

이제 본격적인 개발에 들어가면서 일주일 단위로 회고글을 작성해보는 것이 목표이다!

트러블 슈팅도 쓰고... 팀 문화도 쓰고, 느낀점도 기록하고. 회고는 참 좋은 것 같다.

개인적으로 이번 주차에 토론을 많이 하면서 생각보다 이야기하는 과정이 재밌다는 걸 느꼈다.

지금까지는 많아야 4명이서 프로젝트를 했었는데, 7명이라는 많은 인원들과 진행하면서 생각의 차이도 있고, 서로 의견도 공유하다 보니 이게 진짜 진한 협업이구나... 라는 생각이 절로 들었다. 프로젝트에서 중요한 거는 단순 기능이 아닌 소프트 스킬이 정말 중요하다는 것을 또 한 번 느꼈다. 나중에 PM, 디자이너, 기획자까지 포함된다면 얼마나 커질까? 벌써 재밌을 것 같다...

근데 그 전에 말하는 연습부터 좀 해야겠다. 생각보다 내가 말을 많이 더듬으면서 하는 것 같다 ㅎㅎ ㅠ

아무튼 레벨 3 잘 마무리해서 멋진 완성본을 만들어냈으면 좋겠다

앞으로도 더 힘내봐야겠다!

회고 끝!

[JPA] @GeneratedType - 키 생성 전략 알아보기

dolmeng2 — Fri, 7 Jul 2023 17:16:31 +0900

JPA 기본 키 생성 전략

JPA에서 제공하는 기본 키 생성 전략은 크게 5가지로 나누어진다.
- TABLE, SEQUENCE, IDENTITY, UUID, AUTO

각 전략에 대해서 하나씩 알아보도록 하자.

TABLE

Indicates that the persistence provider must assign primary keys for the entity using an underlying database table to ensure uniqueness.

- 데이터베이스 테이블을 사용하여 엔티티에 기본 키를 할당해야 한다.

엔티티 설정

@Entity
class User(
    @Id @GeneratedValue(strategy = GenerationType.TABLE)
    val id: Long = 0L
)

- 가장 간단하게 설정하기 위해서 User 엔티티에 아이디에 대한 필드만 설정해두었다.

h2 database

h2에서는 먼저 user 테이블과 시퀀스를 관리하기 위한 hibernate_sequences 테이블을 만든다.

이때 내부적으로 시퀀스 값 자체를 관리하기 위한 next_val과 시퀀스 이름 필드인 sequence_name을 만들며, 생성하는 테이블 각각에 대해 시퀀스를 관리하게 된다.

이후, 가장 처음 시퀀스 값을 초기화하기 위해서 insert를 진행하며, 0으로 초기화를 해두었다.

mysql

mysql 역시 마찬가지로 user와 시퀀스를 관리하기 위한 테이블을 추가한다.

innoDB 스토리지 엔진을 사용한다는 점 빼고는 동일하다.

postgresql

postgresql에서도 완전히 동일하게 동작하기 때문에 생략하겠다.

insert 시 동작 과정

기본적으로 select를 통해서 현재 테이블에 저장되어 있는 시퀀스 값을 가져온다.

이때, select for update 구문을 활용하여 락을 걸고 있기 때문에 외부에서 해당 테이블에 값을 삽입할 수가 없어 데이터의 일관성은 만족된다. 이후, 가져온 값을 바탕으로 시퀀스 값을 update 해주고, 최종적으로 user 엔티티에 대해 insert를 진행한다.

위의 상황에서는 디폴트로 0이 저장되어 있고, update 시 1을 추가하여 0 + 1 = 1의 값을 가지고, insert 시 업데이트된 값을 통해서 id를 할당한 상황이라고 볼 수 있다.

@TableGenerator

@Entity
class User(
    @Id @GeneratedValue(strategy = GenerationType.TABLE, generator = "user_seq_generator")
    @TableGenerator(name = "user_seq_generator", table="user_sequence",
        pkColumnName = "name", pkColumnValue = "user_col", allocationSize = 50)
    val id: Long = 0L
)

테이블 전략의 경우 @TableGenerator 어노테이션과 함께 사용하면 시퀀스 테이블에 대한 정보를 커스텀할 수 있다.

- name: 생성하는 제너레이터의 이름 (@GeneratedValue의 인자로 제너레이터를 참조할 때 참조하는 이름이다.)
- table: 생성하는 제너레이터 테이블의 이름
- pkColumnName: 제너레이터 테이블에서 지정할 시퀀스 이름 필드명
- pkColumnValue: 시퀀스 이름 필드에 대해서 해당 테이블을 어떤 이름으로 관리할지 지정
- allocationSize: 사전에 정의한 시퀀스 사이즈. DB에서는 할당한 사이즈만큼 먼저 수를 증가시켜두고, 트랜잭션이 끝날 때마다 사이즈만큼 추가한다. (기본값이 50이기 때문에 필요하다면 1로 설정!)

위의 정보 외에도 다양한 설정값들을 세팅할 수 있다.

@Test
@Transactional
fun test() {
    userRepository.save(User())
}

실제로, allocationSize에 대해 테스트를 하기 위해 위와 같이 사용자 정보를 저장해보자.

우선, 앞서 봤던 것처럼 시퀀스 정보를 select 후 해당 값을 update 한 것을 볼 수 있다.

그리고 sequence 정보를 확인해보면, user 하나만 저장했음에도 할당한 크기(50)만큼 값이 추가된 것을 볼 수 있다.

만약, 다시 한 번 테스트 코드를 실행하게 된다면 다음 sequence는 어떻게 될까? (ddl는 update로 설정)

이때는 db에 next_val이 100으로 저장이 되어 있다. (기존 next_val 값 50 + allocationSize 50 = 100)

@Test
@Transactional
fun test() {
    // 한 번 더 실행했을 때의 결과
    val user = userRepository.save(User())
    assertThat(user.id).isEqualTo(2)
}

하지만, user의 pk 값은 2로 나오는 것을 확인할 수 있다. 이는 내부적으로 받아온 next_val의 값과 allocationSize 값을 바탕으로 pk를 계산한 값이다. 레코드 1개를 삽입할 때, 처음 select 시 얻어온 (next_val - allocation_size) + 1으로 할당된다.

SEQUENCE

Indicates that the persistence provider must assign primary keys for the entity using a database sequence.

데이터베이스에서 제공하는 시퀀스를 사용하여 엔티티의 기본 키를 할당해야 한다.

이때, 시퀀스를 지원하지 않는 DB라면 테이블 전략을 사용한다.

엔티티 설정

@Entity
class User(
    @Id @GeneratedValue(strategy = GenerationType.SEQUENCE)
    val id: Long = 0L
)

h2 database

h2의 경우 sequence를 지원하기 때문에 ‘create sequence’라는 것을 통해서 sequence 관리한다.
이때, 디폴트로 시퀀스 값은 1부터 시작하여 50씩 증가한다. 즉, 하나의 트랜잭션이 끝나면 50개 이하를 삽입하더라도 50씩 시퀀스 값이 증가하기 때문에 중간중간 비어있는 PK 값을 가질 수 있다는 것이 특징이다.

mysql

⭐️ 그러나, mysql에서는 sequence를 지원하지 않기 때문에 테이블 전략처럼 user_seq라는 테이블이 생성된다.
이때, 시퀀스 테이블에 대한 네이밍은 엔티티명 + _seq와 같은 형태로 동작한다.

postgresql

h2와 마찬가지로 postgresql 역시 sequence를 지원하기 때문에 create sequence를 통해서 시퀀스를 생성한다.

insert 시 동작 과정

먼저, 시퀀스로부터 다음 값을 받아오는 select 쿼리가 발생한다. ("next value for" = 1이라는 값을 받아온다.)

이전의 TABLE 전략과 다르게 '그 다음 insert 시 사용할 시퀀스 값'을 저장하기 때문에 시퀀스에 대한 별도의 update를 쿼리로 관리하는 것이 아닌 내부적으로 관리된다고 추측된다. (물론 MySQL이라면 테이블 전략이기 때문에 update 쿼리 발생)

또한, 추후 나올 IDENTITY 전략과 다르게 persist 시 insert를 하지 않아도 돼서 트랜잭션 커밋 시 insert가 이루어진다. (쓰기 지연 가능)

@SequenceGenerator

@Entity
class User(
    @Id @GeneratedValue(strategy = GenerationType.SEQUENCE, generator = "user_seq_generator")
    @SequenceGenerator(name = "user_seq_generator", sequenceName = "user_sequence",
        initialValue = 10, allocationSize = 50)
    val id: Long = 0L
)

@SequenceGenerator를 활용하면 시퀀스에 대한 정보를 설정해줄 수 있다.
- name: 생성하는 제너레이터의 이름 (@GeneratedValue의 인자로 제너레이터를 참조할 때 참조하는 이름이다.)
- sequenceName: 생성하는 시퀀스의 이름
- initialValue: 시퀀스의 초기값
- allocationSize: 사전에 정의한 시퀀스 사이즈. DB에서는 할당한 사이즈만큼 먼저 수를 증가시켜두고, 트랜잭션이 끝날 때마다 사이즈만큼 추가한다.
마찬가지로 위의 정보 외에도 다양한 설정값들을 세팅할 수 있다.

키 할당 전략은 table 때와 똑같이 (next_val - allocation_size) + 1와 같이 설정된다.

IDENTITY

Indicates that the persistence provider must assign primary keys for the entity using a database identity column.

- 데이터베이스의 auto-increment 열을 사용하여 엔티티에 기본 키를 할당해야 한다.
레코드가 새롭게 추가될 때마다 자동으로 고유값을 생성하고 증가시킨다.

엔티티 설정

@Entity
class User(
    @Id @GeneratedValue(strategy = GenerationType.IDENTITY)
    val id: Long = 0L
)

h2 database

별도의 시퀀스 테이블을 생성하지 않고, pk로 사용된 컬럼에 as identity라는 이름이 들어간다.

mysql

h2와 거의 비슷하지만 auto_increment가 pk 컬럼에 붙게 된다.

cf. 참고로 innoDB에서는 auto_increment를 위한 자동 증가 락이라는 것을 통해서 해당 값을 관리한다.

postgresql

postgresql의 경우 bigserial이라는 값을 통해서 관리한다.
이는 postgresql에서 사용하는 자동 증가 타입으로, 컬럼이 삽입될 때마다 1씩 증가된 값이 저장된다.

insert 시 동작 과정

앞서 본 테이블, 시퀀스 전략과 다르게 select 쿼리가 없이 바로 insert 쿼리가 발생한다.

이때, ()와 같이 빈 값이 들어가는 것을 볼 수 있는데, 이는 삽입하는 시점에는 id 값을 알 수 없기 때문에 빈값 (java라면 null)이 들어가는 것이다. 즉, 삽입 시점의 id 값을 애초에 모르니까 삽입 전에 select 쿼리를 날릴 수 없는 것이다.

IDENTITY 전략 사용 시 트랜잭션 커밋 시점이 아닌, persist 시점에 쿼리가 발생하여, 쓰기 지연이 불가능하다.

기본적으로 JPA의 영속성 컨텍스트에서 객체를 관리하기 위해서는 @Id 속성이 꼭 필요한데 auto_increment의 경우 DB에 직접 레코드를 insert를 한 뒤에 ID 값을 알 수 있기 때문에 persist() 시점에 insert를 진행하여 식별자를 미리 알아둔다. 이후, 알아본 값을 영속성 컨텍스트의 1차 캐시 내부에 저장한다.

IDENTITY with generator

두 속성을 같이 쓰면 어떻게 동작할지 궁금해서 실험해보았다.

@Entity
class User(
    @Id @GeneratedValue(strategy = GenerationType.IDENTITY, generator = "user_seq_generator")
    @SequenceGenerator(name = "user_seq_generator", sequenceName = "user_sequence",
        initialValue = 10, allocationSize = 50)
    val id: Long = 0L
)

확인 결과, 시퀀스 옵션이 더 우선으로 적용되는 것을 볼 수 있다.

참고로, 테이블 제너레이터를 사용하더라도 마찬가지로 우선 적용된다.

AUTO

Indicates that the persistence provider should pick an appropriate strategy for the particular database.
The AUTO generation strategy may expect a database resource to exist, or it may attempt to create one.
A vendor may provide documentation on how to create such resources in the event that it does not support schema generation or cannot create the schema resource at runtime.

특정 데이터베이스에 따른 적절한 전략을 선택하며, 벤더 사에 따라서 자동으로 결정된다.

엔티티 설정

@Entity
class User(
    @Id @GeneratedValue(strategy = GenerationType.AUTO)
    val id: Long = 0L
)

h2 database

h2의 경우 시퀀스를 지원하기 때문에 시퀀스 전략을 자동으로 채택한다.

mysql

시퀀스 전략을 지원하지 않는 mysql의 경우 테이블 전략을 사용한다.

postgresql

h2와 마찬가지로 시퀀스 전략을 사용한다.

SEQUENCE vs AUTO

여기까지만 봤다면 시퀀스 전략이나 auto나 별다른 게 없다고 생각이 들 것이다.
하지만, pk가 uuid인 ‘엔티티를 저장할 때’ 시퀀스 전략의 경우 오류가 발생하고, auto의 경우 정상적으로 동작한다.

이때, 단순히 테이블 생성 자체는 정상적으로 동작한다.

sequence

@Entity
class User(
    @Id @GeneratedValue(strategy = GenerationType.SEQUENCE)
    val id: UUID = UUID.randomUUID()
)

h2로 테스트를 진행했기 때문에 시퀀스 테이블을 생성하는 것을 볼 수 있다.

이때, user 테이블의 id가 uuid로 설정된 것을 볼 수 있다.

userRepository.save(User())

기본적으로 User 객체의 id에 기본값을 정의하였기 때문에 select 쿼리를 통해서 이미 객체가 존재하는지 확인한 다음, 존재하지 않으면 user_seq의 시퀀스 값으로부터 다음 값을 가져온다.

Unknown integral data type for ids: java.util.UUID

하지만, 이후 UUID 타입으로는 save가 되지 않는다는 오류가 발생한다.
이는, 초기 sequence 정의를 보면 1부터 시작하여 50씩 증가하는 디폴트 설정을 가지고 있지만, pk 값이 uuid로 되어 있다 보니 uuid에 대해 증가 연산을 할 수 없어 데이터 타입에 대한 오류가 발생한다.

auto

@Entity
class User(
    @Id @GeneratedValue(strategy = GenerationType.AUTO)
    val id: UUID = UUID.randomUUID()
)

시퀀스를 지원하는 h2임에도, 시퀀스를 생성하지 않고 단순히 pk가 UUID인 user 테이블을 생성하는 것을 볼 수 있다.

userRepository.save(User())

우선 아이디 값에 대해서 UUID.randomUUID()를 활용하여 기본값을 설정하게 되면, 이미 존재하는 레코드인지 확인하기 위해 저장 전에 select 쿼리가 발생하고 이후 insert 쿼리가 날라간다. 이때, 레코드 삽입 시 해당 PK 값을 증가시키면서 관리할 필요가 없기 때문에 오류가 발생하지 않고 잘 지정되는 것을 볼 수 있다.

identity (번외)

@Entity
class User(
    @Id @GeneratedValue(strategy = GenerationType.IDENTITY)
    val id: Long = 0L
)

참고로, identity로 설정했을 때는 save가 아닌 테이블을 생성하는 시점부터 오류가 발생한다.

uuid 자체를 자동 증가값으로 관리할 수 없기 때문에 발생하는 오류이다.

⭐️ 결과적으로 식별자 타입이 UUID면 UUID를 식별자로 사 용하고, 숫자면서 시퀀스를 지원하면 시퀀스로, 아니면 테이블로 사용한다고 생각하면 된다.

UUID

Indicates that the persistence provider must assign primary keys for the entity by generating an RFC 4122 Univerally Unique IDentifier.

- RFC 4122 Universally Unique Identifier를 통해서 엔티티의 기본 키를 할당할 수 있다.
PK 필드 자체를 UUID로 설정하고, AUTO 전략을 사용하는 것과 동일하게 동작한다.

엔티티 설정

@Entity
class User(
    @Id @GeneratedValue(strategy = GenerationType.UUID)
    val id: Long = 0L
)

h2 database

id 값의 타입으로 uuid가 설정되는 것을 볼 수 있다. 이때 별도의 시퀀스가 있다든지, 자동 증가 컬럼으로서 동작하지는 않는다.

mysql

mysql의 경우 binary라는 타입을 활용하여 필드가 생성이 된다.

마찬가지로 자동 증가로 관리되지 않고, 별도의 시퀀스 테이블이 생성되지 않는다.

postgresql

h2와 동일하게 uuid라는 필드값으로 생성된다.

@IdGeneratorType

@TableGenerator, @SequenceGenerator 외에도 범용적으로 사용할 수 있는 @GenericGenerator라는 어노테이션이 존재한다.
하지만, 공식 문서에서 @IdGeneratorType을 대신 사용하는 것을 권고하였기 때문에 사실상 deprecated 되었다고 생각한다.
@IdGeneratorType을 사용하면 어노테이션이 아닌 인터페이스를 활용하여 조금 더 세세하게 커스텀을 진행할 수 있다.

public class CustomSequenceGenerator implements IdentifierGenerator {

	public CustomSequenceGenerator(
			Sequence config,
			Member annotatedMember,
			CustomIdGeneratorCreationContext context) {
		//...
	}

	@Override
	public Object generate(
			SharedSessionContractImplementor session,
			Object object) {
		//...
}

@IdGeneratorType( CustomSequenceGenerator.class )
@Target({METHOD, FIELD})
@Retention(RUNTIME)
public @interface Sequence {
	String name();
	int startWith() default 1;
	int incrementBy() default 50;
	Class<? extends Optimizer> optimizer() default Optimizer.class;
}

사실 직접 사용할 일은 없을 것 같아서 그냥 Member 위에 @Sequence라는 커스텀 어노테이션이 적용되었을 경우를 보여주는 예제 코드를 가져왔다.

public class TableGenerator implements PersistentIdentifierGenerator {
	...
  @Override
  public Object generate(final SharedSessionContractImplementor session, final Object obj) {
    final SqlStatementLogger statementLogger = session.getFactory().getServiceRegistry()
            .getService( JdbcServices.class )
            .getSqlStatementLogger();
    final SessionEventListenerManager statsCollector = session.getEventListenerManager();

    return optimizer.generate(
            new AccessCallback() {
              @Override
              public IntegralDataTypeHolder getNextValue() {
                return session.getTransactionCoordinator().createIsolationDelegate().delegateWork(
                        new AbstractReturningWork<>() {
                          @Override
                          public IntegralDataTypeHolder execute(Connection connection) throws SQLException {
                            return nextValue( connection, statementLogger, statsCollector );
                          }
                        },
                        true
                );
              }

              @Override
              public String getTenantIdentifier() {
                return session.getTenantIdentifier();
              }
            }
    );
  }
}

실제로 @TableGenerator 역시 IdentifierGenerator 인터페이스를 활용하여 구현되어 있는 것을 확인할 수 있다.

아예 아무것도 붙이지 않는다면?

@Entity
class User(
    @Id
    val id: Long = 0L
)

@GenerateType을 아예 붙이지 않아도 되는지 궁금해서 실험해보았다.

h2 database

기본적으로 user table만 생성하고, id에도 auto_increment 같이 관리하는 조건이 들어가지 않는다.

이 상태로 삽입을 하게 되면 다음과 같다.

userRepository.save(User())

id에 대한 바인딩이 0으로 들어간 것을 볼 수 있다.

userRepository.save(User())
userRepository.save(User())

또한, save를 2번 호출하게 되면은 위와 같이 중복된 식별자를 사용한다는 오류가 발생한다. (PK는 unique 해야 하니까)

이는 PK 값에 대해 별도로 관리하는 방법을 지정하지 않았기 때문에 사용자가 직접 id를 넣어줘야 되면서 생긴 문제이다. 우선 엔티티 생성 시 아이디에 대한 기본값인 0L을 지정하면서 또 다시 '0L'이라는 동일한 키를 가진 엔티티가 삽입되면서 오류가 발생한 것이다.그래서 복합키 같은 특수 상황을 제외하면 웬만하면 생성 전략을 통해서 관리하는 게 좋다는 생각이 들었다.

mysql

작동 과정은 앞과 똑같기 때문에 별도로 설명하지 않고, 테이블 형식만 보겠다.

마찬가지로 단순히 테이블의 필드값으로 bigint만 존재하는 것을 볼 수 있다.

postgresql

h2와 동일하게 생성된 것을 볼 수 있다.

기본값을 할당해주지 않았다면?

여기서도 기본값을 어떻게 할당하는지에 따라서 결과가 달라진다. (generatedType을 지정하지 않았을 때의 결과)

@Entity
class User(
    @Id
    val id: Long = 0L
)

흔히 사용하는 Long 타입 id에 0L 같은 기본값으로 초기화하게 된다면, 엔티티 저장 시 단순히 하나의 insert 쿼리만 발생하게 된다. (Int 타입도 마찬가지)

하지만, 1L 같이 특정한 값으로 설정하게 되면 select 쿼리가 발생하고 그 다음 insert 쿼리가 발생한다.

이는 삽입 전에 이미 해당 레코드가 존재하는지 확인하고 (관리 전략을 설정해주지 않았으니까) insert를 날려서 존재하지 않는 것에 대해서만 insert를 하기 때문이다.

@Entity
class User(
    @Id @GeneratedValue(strategy = GenerationType.IDENTITY)
    val id: Long = 0L
)

같은 원리로 IDENTITY를 설정하게 되면 애초에 insert 시 아이디가 없으니까 애초에 검증할 값이 없으니 단순히 insert만 발생한다. (persist 시에 insert 쿼리 발생)

@Entity
class User(
    @Id 
    val id: String = ""
)

String의 경우 무조건 select가 발생한다. (애초에 String? 타입으로 설정 후 기본 값을 null로 지정하면 오류가 발생한다.)

이는, save() 시의 메서드를 보면 파악할 수 있다.

save() 시 메서드를 보면 엔티티가 새로우면 persist, 아니면 merge를 하게 되는 걸 볼 수 있다.

여기서 isNew() 메서드를 타고 들어가면 다음과 같다.

primitive 타입이 아니라면 null로 체크, Number 형이라면 0L으로 체크해서 이게 새로운 값인지 테스트하게 된다.

[JPA] CascadeType.REMOVE vs orphanRemoval=true 차이점 알아보기 - 2편

dolmeng2 — Fri, 30 Jun 2023 11:14:22 +0900

들어가기 전

지난 포스팅에서는 CascadeType.REMOVE에 대해서 중점적으로 알아봤었는데, 이번에는 orphanRemoval=true 옵션에 대해서 한 번 알아보자. 엔티티 세팅은 지난 번과 거의 동일하기 때문에 변화가 생긴 부분에 대해서만 따로 짚도록 하겠다.

엔티티 수정하기

이번에는 CascadeType.REMOVE 대신에 orphanRemoval=true를 적용하자.

@Entity
class Concert(
    @Id @GeneratedValue(strategy = GenerationType.IDENTITY)
    val id: Long = 0L,

    @Column(nullable = false)
    val name: String,

    @Column(nullable = false)
    val ticketLimit: Int,

    concertTickets: MutableList<ConcertTicket> = Collections.emptyList()
) {

    @OneToMany(
        fetch = FetchType.LAZY,
        mappedBy = "concert",
        cascade = [CascadeType.PERSIST],
        orphanRemoval = true // here!
    )
    val concertTickets: MutableList<ConcertTicket> = concertTickets.toMutableList()
}

orphanRemoval = true

부모 엔티티 제거하기 - 콘서트 엔티티 제거

@Test
@DisplayName("orphanRemoval=true 테스트 - 부모 엔티티 제거")
fun orphanRemoval_true_test_부모_엔티티_제거() {
    // given
    val 콘서트 = Concert(name = "인기 많은 콘서트", ticketLimit = 10)

    val 콘서트_티켓1 = ConcertTicket(userId = 1L, concert = 콘서트)
    val 콘서트_티켓2 = ConcertTicket(userId = 2L, concert = 콘서트)
    콘서트.addTicket(콘서트_티켓1)
    콘서트.addTicket(콘서트_티켓2)
    concertRepository.save(콘서트)

    val 저장된_콘서트들 = concertRepository.findAll()
    val 저장된_콘서트_티켓들 = concertTicketRepository.findAll()
    assertThat(저장된_콘서트들).hasSize(1)
    assertThat(저장된_콘서트_티켓들).hasSize(2)

    // when
    concertRepository.delete(콘서트)

    // then
    val 삭제_이후_저장된_콘서트들 = concertRepository.findAll()
    val 삭제_이후_저장된_콘서트_티켓들 = concertTicketRepository.findAll()

    assertThat(삭제_이후_저장된_콘서트들).hasSize(0)
    assertThat(삭제_이후_저장된_콘서트_티켓들).hasSize(0)
}

하나의 콘서트 엔티티에 대해 2개의 콘서트 티켓 엔티티가 존재하는 형태이다.

이때, 콘서트 엔티티를 제거하게 되면 CascadeType.REMOVE와 마찬가지로 부모와 연관된 자식 엔티티도 함께 제거되어 조회된 콘서트 티켓 엔티티의 개수가 0개인 것을 확인할 수 있다.

실제로 발생한 쿼리를 보더라도 콘서트 티켓 엔티티 2개에 대한 delete 쿼리와 콘서트 엔티티에 대한 1개의 delete 쿼리가 발생하여, 총 3개의 쿼리가 나간 것을 확인할 수 있다.

부모 엔티티와 자식 엔티티 연관관계 끊기

@Test
@DisplayName("orphanRemoval=true 테스트 - 부모 엔티티에서 자식 엔티티 제거")
fun orphanRemoval_true_test_부모_엔티티에서_자식_엔티티_제거() {
    // given
    val 콘서트 = Concert(name = "인기 많은 콘서트", ticketLimit = 10)

    val 콘서트_티켓1 = ConcertTicket(userId = 1L, concert = 콘서트)
    val 콘서트_티켓2 = ConcertTicket(userId = 2L, concert = 콘서트)
    콘서트.addTicket(콘서트_티켓1)
    콘서트.addTicket(콘서트_티켓2)
    concertRepository.save(콘서트)

    val 저장된_콘서트들 = concertRepository.findAll()
    val 저장된_콘서트_티켓들 = concertTicketRepository.findAll()
    assertThat(저장된_콘서트들).hasSize(1)
    assertThat(저장된_콘서트_티켓들).hasSize(2)

    // when
    콘서트.concertTickets.remove(콘서트_티켓1)
    콘서트.concertTickets.remove(콘서트_티켓2)

    // then
    val 삭제_이후_저장된_콘서트들 = concertRepository.findAll()
    val 삭제_이후_저장된_콘서트_티켓들 = concertTicketRepository.findAll()

    assertThat(삭제_이후_저장된_콘서트들).hasSize(1) // here!
    assertThat(삭제_이후_저장된_콘서트_티켓들).hasSize(0)
}

이번에는 고아 객체를 만든 결과이다.

하지만, CascadeType.REMOVE와 다르게 단순히 콘서트 엔티티와 콘서트 티켓 엔티티 사이의 관계를 끊어주니 콘서트 티켓 엔티티가 실제 DB에서 제거된 것을 확인할 수 있다. 즉, 부모 엔티티와 자식 엔티티의 관계가 끊어지게 되면 고아(orphan)가 되고, 고아 객체에 대해 delete 쿼리(remove)가 발생하는 것이다.

실제로 발생한 쿼리를 확인하면 콘서트 티켓 엔티티 2개에 대한 delete 쿼리가 발생한 것을 볼 수 있다.

CascadeType.REMOVE + orphanRemoval = true 함께 사용하기

@Entity
class Concert(
    @Id @GeneratedValue(strategy = GenerationType.IDENTITY)
    val id: Long = 0L,

    @Column(nullable = false)
    val name: String,

    @Column(nullable = false)
    val ticketLimit: Int,

    concertTickets: MutableList<ConcertTicket> = Collections.emptyList()
) {

    @OneToMany(
        fetch = FetchType.LAZY,
        mappedBy = "concert",
        cascade = [CascadeType.PERSIST, CascadeType.REMOVE],
        orphanRemoval = true
    )
    val concertTickets: MutableList<ConcertTicket> = concertTickets.toMutableList()
}

부모 엔티티 제거하기 - 콘서트 엔티티 제거

@Test
@DisplayName("CascadeType.REMOVE + orphanRemoval=true 테스트 - 부모 엔티티 제거")
fun cascadeType_remove_orphanRemoval_true_test_부모_엔티티_제거() {
    // given
    val 콘서트 = Concert(name = "인기 많은 콘서트", ticketLimit = 10)

    val 콘서트_티켓1 = ConcertTicket(userId = 1L, concert = 콘서트)
    val 콘서트_티켓2 = ConcertTicket(userId = 2L, concert = 콘서트)
    콘서트.addTicket(콘서트_티켓1)
    콘서트.addTicket(콘서트_티켓2)
    concertRepository.save(콘서트)

    val 저장된_콘서트들 = concertRepository.findAll()
    val 저장된_콘서트_티켓들 = concertTicketRepository.findAll()
    assertThat(저장된_콘서트들).hasSize(1)
    assertThat(저장된_콘서트_티켓들).hasSize(2)

    // when
    concertRepository.delete(콘서트)

    // then
    val 삭제_이후_저장된_콘서트들 = concertRepository.findAll()
    val 삭제_이후_저장된_콘서트_티켓들 = concertTicketRepository.findAll()

    assertThat(삭제_이후_저장된_콘서트들).hasSize(0)
    assertThat(삭제_이후_저장된_콘서트_티켓들).hasSize(0)
}

CascadeType.REMOVE나 orphanRemoval = true 옵션 모두 부모 엔티티를 제거하면 연관된 자식 엔티티도 함께 제거되기 때문에 당연하게 두 옵션을 함께 사용하면 똑같이 제거되는 것을 볼 수 있다.

부모 엔티티와 자식 엔티티 연관관계 끊기

@Test
@DisplayName("CascadeType.REMOVE + orphanRemoval=true - 부모 엔티티에서 자식 엔티티 제거")
fun cascadeType_remove_orphanRemoval_true_test_부모_엔티티에서_자식_엔티티_제거() {
    // given
    val 콘서트 = Concert(name = "인기 많은 콘서트", ticketLimit = 10)

    val 콘서트_티켓1 = ConcertTicket(userId = 1L, concert = 콘서트)
    val 콘서트_티켓2 = ConcertTicket(userId = 2L, concert = 콘서트)
    콘서트.addTicket(콘서트_티켓1)
    콘서트.addTicket(콘서트_티켓2)
    concertRepository.save(콘서트)

    val 저장된_콘서트들 = concertRepository.findAll()
    val 저장된_콘서트_티켓들 = concertTicketRepository.findAll()
    assertThat(저장된_콘서트들).hasSize(1)
    assertThat(저장된_콘서트_티켓들).hasSize(2)

    // when
    콘서트.concertTickets.remove(콘서트_티켓1)
    콘서트.concertTickets.remove(콘서트_티켓2)

    // then
    val 삭제_이후_저장된_콘서트들 = concertRepository.findAll()
    val 삭제_이후_저장된_콘서트_티켓들 = concertTicketRepository.findAll()

    assertThat(삭제_이후_저장된_콘서트들).hasSize(1)
    assertThat(삭제_이후_저장된_콘서트_티켓들).hasSize(0)
}

같은 이유로 부모 엔티티와 자식 엔티티의 연관관계를 끊더라도 orphanRemoval = true 옵션에 의해서 제거되는 것을 확인할 수 있다.

orphanRemoval = true는 언제 사용을 지양하는 게 좋을까?

@Entity
class Concert(
    @Id @GeneratedValue(strategy = GenerationType.IDENTITY)
    val id: Long = 0L,

    @Column(nullable = false)
    val name: String,

    @Column(nullable = false)
    val ticketLimit: Int,

    concertTickets: MutableList<ConcertTicket> = Collections.emptyList()
) {

    @OneToMany(
        fetch = FetchType.LAZY,
        mappedBy = "concert"
    )
    val concertTickets: MutableList<ConcertTicket> = concertTickets.toMutableList()
}

@Entity
class ConcertTicket(
    @Id @GeneratedValue(strategy = GenerationType.IDENTITY)
    val id: Long = 0L,

    @Column(nullable = false)
    val userId: Long,

    @ManyToOne(fetch = FetchType.LAZY)
    @JoinColumn(
        name = "concert_id",
        foreignKey = ForeignKey(name = "fk_ticket_concert_id")
    )
    var concert: Concert
)

@Entity
class User(
    @Id @GeneratedValue(strategy = GenerationType.IDENTITY)
    val id: Long = 0L,

    val name: String,

    concertTickets: MutableList<ConcertTicket> = Collections.emptyList()
) {

    @OneToMany(
        fetch = FetchType.LAZY,
        orphanRemoval = true
    )
    val concertTickets: MutableList<ConcertTicket> = concertTickets.toMutableList()
}

테스트를 위해서 사용자를 나타내는 'User' 엔티티를 만들고, 사용자 엔티티가 콘서트 티켓 엔티티를 자식으로 가지고 있는 상태로 만들었다. 즉, '콘서트 티켓 엔티티'에 대해서는 '콘서트'와 '사용자'라는 두 개의 부모 엔티티가 존재하는 형태인 것이다.

참고로, 콘서트 티켓 엔티티에 대해서는 사용자 엔티티에 대한 연관관계를 설정하지 않았다. (단방향) 또한, 기존 콘서트 엔티티의 CascadeType.PERSIST 옵션을 제거하고 사용자 엔티티가 가진 콘서트 티켓 엔티티에 대해서 orphanRemoval=true를 추가하였다.

@Test
@DisplayName("orphanRemoval=true - 다중 부모를 가지고 있는 경우, 하나의 부모 삭제")
fun orphanRemoval_true_multiple_parents_부모_엔티티_제거() {
    // given
    val 콘서트 = Concert(name = "인기 많은 콘서트", ticketLimit = 10)

    val 콘서트_티켓1 = ConcertTicket(userId = 1L, concert = 콘서트)
    val 콘서트_티켓2 = ConcertTicket(userId = 2L, concert = 콘서트)
    concertRepository.save(콘서트)
    concertTicketRepository.saveAll(listOf(콘서트_티켓1, 콘서트_티켓2))

    val 사용자 = User(name = "져니")
    userRepository.save(사용자)

    // when
    userRepository.delete(사용자)

    // then
    val 삭제_이후_저장된_콘서트들 = concertRepository.findAll()
    val 삭제_이후_저장된_콘서트_티켓들 = concertTicketRepository.findAll()
    val 모든_사용자들 = userRepository.findAll()

    assertThat(삭제_이후_저장된_콘서트들).hasSize(1)
    assertThat(삭제_이후_저장된_콘서트_티켓들).hasSize(2)
    assertThat(모든_사용자들).hasSize(0)
}

우선, PERSIST 없이 여러 부모가 있을 때 하나의 부모에 대해서 제거를 하게 되면 단순히 사용자에 대한 delete 쿼리만 발생한다.

@Entity
class User(
    @Id @GeneratedValue(strategy = GenerationType.IDENTITY)
    val id: Long = 0L,

    val name: String,

    concertTickets: List<ConcertTicket> = Collections.emptyList()
) {

    @OneToMany(
        fetch = FetchType.LAZY,
        cascade = [CascadeType.PERSIST],
        orphanRemoval = true
    )
    val concertTickets: MutableList<ConcertTicket> = concertTickets.toMutableList()
}

하지만, 사용자와 콘서트 엔티티에 대해서 cascade 옵션을 통해 PERSIST를 준다면 결과가 달라지게 된다.

부모 엔티티 제거하기 - 사용자 엔티티 제거 (다중 부모)

@Test
@DisplayName("orphanRemoval=true - 다중 부모를 가지고 있는 경우, 하나의 부모 삭제")
fun orphanRemoval_true_multiple_parents_부모_엔티티_제거() {
    // given
    val 콘서트 = Concert(name = "인기 많은 콘서트", ticketLimit = 10)

    val 콘서트_티켓1 = ConcertTicket(userId = 1L, concert = 콘서트)
    val 콘서트_티켓2 = ConcertTicket(userId = 2L, concert = 콘서트)
    concertRepository.save(콘서트)

    val 사용자 = User(name = "져니", concertTickets = mutableListOf(콘서트_티켓1, 콘서트_티켓2))
    userRepository.save(사용자)

    // when
    userRepository.delete(사용자)

    // then
    val 삭제_이후_저장된_콘서트들 = concertRepository.findAll()
    val 삭제_이후_저장된_콘서트_티켓들 = concertTicketRepository.findAll()
    val 모든_사용자들 = userRepository.findAll()

    assertThat(삭제_이후_저장된_콘서트들).hasSize(1)
    assertThat(삭제_이후_저장된_콘서트_티켓들).hasSize(0)
    assertThat(모든_사용자들).hasSize(0)
}

하지만, 사용자를 저장할 때 콘서트 티켓을 함께 저장하고 (PERSIST에 의해서 영속화 -> insert) 사용자 엔티티를 제거하게 되면 영속화된 콘서트 티켓 엔티티도 함께 제거된다. 즉, ⭐️ 가장 큰 포인트는 영속화를 통해서 부모와 자식의 생명주기를 동일하게 만드는 것이다.

만약 사용자에 대한 정보만 제거하고 싶고 콘서트 티켓에 대해서는 제거하고 싶지 않은 상황이 발생한다면 (물론, 이런 상황은 거의 없을 것이다. 대부분 자식의 생명주기는 부모에게 종속되는 것이 일반적이니까) orphanRemoval = true의 사용을 잘 고민해봐야 한다.

부모 엔티티와 자식 엔티티 연관관계 끊기

@Test
@DisplayName("orphanRemoval=true - 다중 부모를 가지고 있는 경우, 하나의 부모에서 자식 엔티티 제거")
fun orphanRemoval_true_multiple_parents_부모에서_자식_엔티티_제거() {
    // given
    val 콘서트 = Concert(name = "인기 많은 콘서트", ticketLimit = 10)
    concertRepository.save(콘서트)

    val 콘서트_티켓1 = ConcertTicket(userId = 1L, concert = 콘서트)
    val 콘서트_티켓2 = ConcertTicket(userId = 2L, concert = 콘서트)
    val 사용자 = User(name = "져니", concertTickets = mutableListOf(콘서트_티켓1, 콘서트_티켓2))
    userRepository.save(사용자)

    // when
    사용자.concertTickets.remove(콘서트_티켓1)
    사용자.concertTickets.remove(콘서트_티켓2)

    // then
    val 삭제_이후_저장된_콘서트들 = concertRepository.findAll()
    val 삭제_이후_저장된_콘서트_티켓들 = concertTicketRepository.findAll()
    val 모든_사용자들 = userRepository.findAll()

    assertThat(삭제_이후_저장된_콘서트들).hasSize(1)
    assertThat(삭제_이후_저장된_콘서트_티켓들).hasSize(0)
    assertThat(모든_사용자들[0].concertTickets).hasSize(0)
}

이번에는 영속성 전이 옵션을 설정한 부모 엔티티 (사용자)에서 자식 엔티티 (콘서트 티켓)에 대한 연관관계를 끊어보자. 콘서트 티켓 엔티티는 DB 상으로 콘서트와 연관관계가 있음에도 영속성 전이 옵션이 설정되어 있는 사용자와 콘서트 티켓 사이의 연관관계가 끊어지니 제거되는 것을 볼 수 있다.

결론

- 영속성 전이 옵션을(PERSIST) 통해서 부모와 자식의 생명주기가 맞춰져 있어야 한다.

CascadeType.REMOVE

@OneToMany

- 부모 엔티티 제거 시 부모와 자식 모두 실제 DB에서 제거된다.

- 부모 엔티티와 자식 엔티티의 연관관계가 끊어지더라도 실제 DB에서 제거되지 않는다.

@ManyToOne
- 부모 / 자식 엔티티 제거 시 연관된 부모, 자식 모두 실제 DB에서 제거된다.
- 이때, 자식 엔티티가 여러 개일 경우 외래키 제약 조건 위반으로 인해 예외가 발생할 수 있다.
- 부모 엔티티와 자식 엔티티의 연관관계가 끊어지더라도 실제 DB에서 제거되지 않는다.

orphanRemoval = true

- 부모 엔티티 제거 시 부모와 자식 모두 실제 DB에서 제거된다.
- 부모 엔티티와 자식 엔티티의 연관관계가 끊어지면 자식은 실제 DB에서 제거된다.

[JPA] CascadeType.REMOVE vs orphanRemoval=true 차이점 알아보기 - 1편

dolmeng2 — Thu, 29 Jun 2023 23:58:40 +0900

들어가기 전

JPA를 공부하면서 CascadeType.REMOVE와 orphanRemoval = true 옵션에 대해서 어떤 차이가 있는지 제대로 인지한 적이 없는 것 같아서, 이번에 공부할 겸 여러 가지 테스트를 진행해보며 두 옵션의 차이를 공부해보았다.

결과적으로 말하자면 Cascade 옵션은 부모 엔티티와 자식 엔티티의 영속 상태를 관리하는 것이고, orphanRemoval은 조금 더 세부적으로 고아 객체에 대한 관리라는 생각이 들었다. 지금부터 여러 케스트를 테스트하며 하나씩 알아보자.

엔티티 세팅하기

1:N 관계를 담당해줄 '콘서트' 엔티티와 '콘서트 티켓' 엔티티를 생성하였다.

둘 사이의 관계는 양방향으로 설정하였으며, 하나의 콘서트는 여러 개의 콘서트 티켓을 보유할 수 있도록 설계하였다.

<Concert>

@Entity
class Concert(
    @Id @GeneratedValue(strategy = GenerationType.IDENTITY)
    val id: Long = 0L,

    @Column(nullable = false)
    val name: String,

    @Column(nullable = false)
    val ticketLimit: Int,

    concertTickets: MutableList<ConcertTicket> = Collections.emptyList()
) {

    @OneToMany(fetch = FetchType.LAZY, mappedBy = "concert")
    val concertTickets: MutableList<ConcertTicket> = concertTickets.toMutableList()

    fun addTicket(concertTicket: ConcertTicket) {
        concertTickets.add(concertTicket)
    }
}

<ConcertTicket>

@Entity
class ConcertTicket(
    @Id @GeneratedValue(strategy = GenerationType.IDENTITY)
    val id: Long = 0L,

    @Column(nullable = false)
    val userId: Long,

    @ManyToOne(fetch = FetchType.LAZY)
    @JoinColumn(
        name = "concert_id",
        foreignKey = ForeignKey(name = "fk_ticket_concert_id")
    )
    var concert: Concert
)

콘서트 엔티티는 콘서트 티켓 엔티티를 추가할 수 있으며, 학습을 위해 외래키 제약 조건을 설정하였다.

테스트 환경 세팅하기

<application-test.yml>

spring:
  datasource:
    driver-class-name: org.h2.Driver
    url: jdbc:h2:mem:testdb;MODE=MySQL

  jpa:
    hibernate:
      ddl-auto: create-drop
    properties:
      hibernate:
        globally_quoted_identifiers: true
        format_sql: true
    show-sql: true

테스트 환경 세팅을 위해 application-test.yml 파일을 생성하였다.

이때 show-sql 옵션을 통해서 JPA에서 어떤 쿼리가 발생하는지 확인하자.

@DataJpaTest
@ActiveProfiles("test")
@TestConstructor(autowireMode = TestConstructor.AutowireMode.ALL)
class ConcertTest(
    private val concertRepository: ConcertRepository,
    private val concertTicketRepository: ConcertTicketRepository
) {
}

테스트에서 사용한 뼈대 코드이다.

@DataJpaTest를 통해서 JPA 환경을 테스트할 수 있도록 만들었으며, 활성 프로파일은 test로 주어서 application-test.yml의 정보를 읽을 수 있도록 만들었다. 또한, 생성자에서 바로 주입받을 수 있도록 autowireMode를 TestConstructor.AutowireMode.ALL로 설정하였다.

@OneToMany에서 CascadeType.REMOVE

@Entity
class Concert(
    @Id @GeneratedValue(strategy = GenerationType.IDENTITY)
    val id: Long = 0L,

    @Column(nullable = false)
    val name: String,

    @Column(nullable = false)
    val ticketLimit: Int,

    concertTickets: MutableList<ConcertTicket> = Collections.emptyList()
) {

    @OneToMany(
        fetch = FetchType.LAZY,
        mappedBy = "concert",
        cascade = [CascadeType.REMOVE, CascadeType.PERSIST] // Here!
    )
    val concertTickets: MutableList<ConcertTicket> = concertTickets.toMutableList()

테스트를 위해서 콘서트 티켓 엔티티에 대해서 CascadeType.REMOVE를 설정해주었다.

이때, 부모 엔티티 저장 시 자식 엔티티도 함께 저장되도록 만들기 위해서 CascadeType.PERSIST로 설정해주었다.

부모 엔티티 제거하기 - 콘서트 엔티티 제거

@Test
@DisplayName("@OneToMany: CascadeType.REMOVE 테스트 - 부모 엔티티 제거")
fun oneToMany_cascadeType_REMOVE_test_부모_엔티티_제거() {
    // given
    val 콘서트 = Concert(name = "인기 많은 콘서트", ticketLimit = 10)

    val 콘서트_티켓1 = ConcertTicket(userId = 1L, concert = 콘서트)
    val 콘서트_티켓2 = ConcertTicket(userId = 2L, concert = 콘서트)
    콘서트.addTicket(콘서트_티켓1)
    콘서트.addTicket(콘서트_티켓2)
    concertRepository.save(콘서트)

    val 저장된_콘서트들 = concertRepository.findAll()
    val 저장된_콘서트_티켓들 = concertTicketRepository.findAll()
    assertThat(저장된_콘서트들).hasSize(1)
    assertThat(저장된_콘서트_티켓들).hasSize(2)

    // when
    concertRepository.delete(콘서트)

    // then
    val 삭제_이후_저장된_콘서트들 = concertRepository.findAll()
    val 삭제_이후_저장된_콘서트_티켓들 = concertTicketRepository.findAll()

    assertThat(삭제_이후_저장된_콘서트들).hasSize(0)
    assertThat(삭제_이후_저장된_콘서트_티켓들).hasSize(0)
}

하나의 콘서트에 대해서 2개의 콘서트 티켓을 발급받고, 저장 직후 findAll을 통해 잘 저장되었는지 확인했다.

이후, 부모 엔티티인 '콘서트 엔티티'를 제거한 다음 조회를 해보면 콘서트 엔티티와 콘서트 티켓 엔티티 모두가 제거된 것을 확인할 수 있다.

실제로 발생한 쿼리를 확인해보면 콘서트 티켓 엔티티를 제거하기 위한 delete 쿼리가 2번, 콘서트 엔티티를 제거하기 위한 delete 쿼리가 1번 발생하여 총 3번의 쿼리가 나간 것을 볼 수 있다.

부모 엔티티와 자식 엔티티 연관관계 끊기

@Test
@DisplayName("@OneToMany: CascadeType.REMOVE 테스트 - 부모 엔티티에서 자식 엔티티 제거")
fun oneToMany_cascadeType_REMOVE_test_부모_엔티티에서_자식_엔티티_제거() {
    // given
    val 콘서트 = Concert(name = "인기 많은 콘서트", ticketLimit = 10)

    val 콘서트_티켓1 = ConcertTicket(userId = 1L, concert = 콘서트)
    val 콘서트_티켓2 = ConcertTicket(userId = 2L, concert = 콘서트)
    콘서트.addTicket(콘서트_티켓1)
    콘서트.addTicket(콘서트_티켓2)
    concertRepository.save(콘서트)

    val 저장된_콘서트들 = concertRepository.findAll()
    val 저장된_콘서트_티켓들 = concertTicketRepository.findAll()
    assertThat(저장된_콘서트들).hasSize(1)
    assertThat(저장된_콘서트_티켓들).hasSize(2)

    // when
    콘서트.concertTickets.remove(콘서트_티켓1)
    콘서트.concertTickets.remove(콘서트_티켓2)

    // then
    val 삭제_이후_저장된_콘서트들 = concertRepository.findAll()
    val 삭제_이후_저장된_콘서트_티켓들 = concertTicketRepository.findAll()

    assertThat(삭제_이후_저장된_콘서트들).hasSize(1)
    assertThat(삭제_이후_저장된_콘서트_티켓들).hasSize(2)
}

부모 엔티티인 콘서트 엔티티를 조회한 후, 해당 엔티티와 관련된 콘서트 티켓 엔티티에 대해 remove를 진행하여 부모와 자식간의 연관관계를 끊어주었다. 이때 콘서트 티켓 엔티티 2개는 '고아 객체'가 되었다고 판단하는데, CascadeType.REMOVE에서는 고아 객체가 발생하더라도 실제 DB에서 제거되지는 않는다.

@ManyToOne에서 CascadeType.REMOVE

cascadeType의 경우 @OneToMany뿐만 아니라 @ManyToOne에서도 지정할 수 있다.

@Entity
class Concert(
    @Id @GeneratedValue(strategy = GenerationType.IDENTITY)
    val id: Long = 0L,

    @Column(nullable = false)
    val name: String,

    @Column(nullable = false)
    val ticketLimit: Int,

    concertTickets: MutableList<ConcertTicket> = Collections.emptyList()
) {

    @OneToMany(
        fetch = FetchType.LAZY,
        mappedBy = "concert",
        cascade = [CascadeType.PERSIST] // here!
    )
    val concertTickets: MutableList<ConcertTicket> = concertTickets.toMutableList()
}

@Entity
class ConcertTicket(
    @Id @GeneratedValue(strategy = GenerationType.IDENTITY)
    val id: Long = 0L,

    @Column(nullable = false)
    val userId: Long,

    @ManyToOne(
        fetch = FetchType.LAZY,
        cascade = [CascadeType.REMOVE]
    )
    @JoinColumn(
        name = "concert_id",
        foreignKey = ForeignKey(name = "fk_ticket_concert_id")
    )
    var concert: Concert
)

기존 콘서트 엔티티에 적용하였던 CascadeType.REMOVE를 제거하고, 콘서트 티켓 엔티티에 대해서 적용하였다.

자식 엔티티 제거하기 - 콘서트 티켓 엔티티 제거

@Test
@DisplayName("@ManyToOne: CascadeType.REMOVE 테스트 - 자식 엔티티 제거")
fun manyToOne_cascadeType_REMOVE_test_자식_엔티티_제거() {
    // given
    val 콘서트 = Concert(name = "인기 많은 콘서트", ticketLimit = 10)
    val 콘서트_티켓1 = ConcertTicket(userId = 1L, concert = 콘서트)
    콘서트.addTicket(콘서트_티켓1)
    concertRepository.save(콘서트)

    val 저장된_콘서트들 = concertRepository.findAll()
    val 저장된_콘서트_티켓들 = concertTicketRepository.findAll()
    assertThat(저장된_콘서트들).hasSize(1)
    assertThat(저장된_콘서트_티켓들).hasSize(1)

    // when
    concertTicketRepository.delete(콘서트_티켓1);

    // then
    val 삭제_이후_저장된_콘서트들 = concertRepository.findAll()
    val 삭제_이후_저장된_콘서트_티켓들 = concertTicketRepository.findAll()

    assertThat(삭제_이후_저장된_콘서트들).hasSize(0)
    assertThat(삭제_이후_저장된_콘서트_티켓들).hasSize(0)
}

위 테스트의 경우, 콘서트 엔티티에 한 개의 콘서트 티켓 엔티티가 있는 경우이다. (자식이 1개만 있는 경우)

이때 자식 엔티티를 제거하게 된다면 해당 자식 엔티티와 연관된 부모 엔티티와 자식 엔티티 모두가 제거된다.

- 참고로, 여기서 연관이 되어 있다는 것은 단순히 'DB에서 FK로 연결이 되어 있다'라는 의미보다, 영속화가 되어 있는지를 확인한다. 영속화되지 않고 단순히 FK로만 연결이 되어 있다면 콘서트 티켓 엔티티를 제거하더라도 콘서트 엔티티까지 제거되지는 않는다.

그렇다면, 여러 개의 자식이 있을 때는 어떻게 될까?

@Test
@DisplayName("@ManyToOne: CascadeType.REMOVE 테스트 - 자식 엔티티 제거 : 자식이 여러 개일 경우")
fun manyToOne_cascadeType_REMOVE_test_자식_엔티티_제거_자식이_여러개일_경우() {
    // given
    val 콘서트 = Concert(name = "인기 많은 콘서트", ticketLimit = 10)
    val 콘서트_티켓1 = ConcertTicket(userId = 1L, concert = 콘서트)
    val 콘서트_티켓2 = ConcertTicket(userId = 2L, concert = 콘서트)
    콘서트.addTicket(콘서트_티켓1)
    콘서트.addTicket(콘서트_티켓2)
    concertRepository.save(콘서트)

    val 저장된_콘서트들 = concertRepository.findAll()
    val 저장된_콘서트_티켓들 = concertTicketRepository.findAll()
    assertThat(저장된_콘서트들).hasSize(1)
    assertThat(저장된_콘서트_티켓들).hasSize(2)

    // when
    concertTicketRepository.delete(콘서트_티켓1)

    // then
    assertThatThrownBy {
        concertRepository.findAll()
		// concertTicketRepository.findAll()
    }.isInstanceOf(DataIntegrityViolationException::class.java)
}

콘서트 엔티티에 2개의 콘서트 티켓 엔티티가 있고, 첫 번째 콘서트 티켓 엔티티에 대해서 제거한 상황이다.

이때, 콘서트에 대해 조회하는 시점에서 DataIntegrityViolationException이 발생한다.

- 참고로, 주석으로 concertTicketRepository.findAll()을 해두었는데, 콘서트든 콘서트 티켓 엔티티든 조회하는 쿼리를 발생시킬 때 오류가 발생하기 때문이다.

위의 테스트 코드를 돌리는 가장 처음 시점인 엔티티 저장 때 DB 상황은 아래와 같을 것이다.

[concert]

id	name	ticket_limit
1	인기 많은 콘서트	10

[concert_ticket]

id	user_id	concert_id
1	1	1
2	2	1

PK = 1인 콘서트 레코드가 저장되어 있고, 해당 레코드를 FK로 가지고 있는 PK = 1, 2인 콘서트 티켓 레코드가 저장되어 있는 형태이다.

하지만, 실제 생성된 쿼리를 보면 1개의 콘서트 티켓에 대해 제거하고, 바로 콘서트를 제거하는 쿼리가 발생한다.

concert_ticket 테이블의 PK=1인 첫 번째 레코드가 제거되고, concert 테이블의 PK=1인 첫 번째 레코드가 제거되는 상황이다. 하지만, concert 테이블의 레코드가 제거되려고 할 때 엔티티에 걸어두었던 외래키 제약 조건에 의해서 오류가 발생하게 된다.

@Entity
class ConcertTicket(
    ....
    @JoinColumn(
        name = "concert_id",
        foreignKey = ForeignKey(name = "fk_ticket_concert_id") // here
    )
    var concert: Concert
)

때문에 concert 테이블의 PK=1인 레코드를 제거하면, concert_ticket 테이블의 두 번째 레코드가 참조하고 있기 때문에 fk 값이 null이 될 수 없어 오류가 발생하는 것이다.

⭐️ 왜 delete하는 시점이 아닌, findAll()을 통해 조회하는 시점에 오류가 발생하는 걸까?

@Test
@DisplayName("@ManyToOne: CascadeType.REMOVE 테스트 - 자식 엔티티 제거 : 자식이 여러 개일 경우")
fun manyToOne_cascadeType_REMOVE_test_자식_엔티티_제거_자식이_여러개일_경우() {
    // given
    val 콘서트 = Concert(name = "인기 많은 콘서트", ticketLimit = 10)
    val 콘서트_티켓1 = ConcertTicket(userId = 1L, concert = 콘서트)
    val 콘서트_티켓2 = ConcertTicket(userId = 2L, concert = 콘서트)
    콘서트.addTicket(콘서트_티켓1)
    콘서트.addTicket(콘서트_티켓2)
    concertRepository.save(콘서트)

    val 저장된_콘서트들 = concertRepository.findAll()
    val 저장된_콘서트_티켓들 = concertTicketRepository.findAll()
    assertThat(저장된_콘서트들).hasSize(1)
    assertThat(저장된_콘서트_티켓들).hasSize(2)

    // when
    assertDoesNotThrow {
        concertTicketRepository.delete(콘서트_티켓1)
    }
}

실제로, 단순히 콘서트 티켓 레파지토리에서 delete를 한다고 해서 오류가 발생하는 것은 아니다.

애초에 조회하기 전까지 delete 쿼리가 발생하지도 않는다. (위의 select는 콘서트, 콘서트 티켓에 대한 findAll())

JPA의 영속성 컨텍스트를 생각하면 간단하게 답이 나올 것이다.

delete의 경우 실제 DB로 제거를 위한 쿼리를 발생시키는 것이 아닌, 단순히 '영속성 컨텍스트'에서 해당 엔티티를 '제거 처리'를 하는 것이기 때문이다.

@Override
@Transactional
@SuppressWarnings("unchecked")
public void delete(T entity) {

	Assert.notNull(entity, "Entity must not be null");

	if (entityInformation.isNew(entity)) {
		return;
	}

	Class<?> type = ProxyUtils.getUserClass(entity);

	T existing = (T) em.find(type, entityInformation.getId(entity));

	// if the entity to be deleted doesn't exist, delete is a NOOP
	if (existing == null) {
		return;
	}

	em.remove(em.contains(entity) ? entity : em.merge(entity));
}

실제로, 구현체를 슬쩍 보면 em.remove()를 통해서 entityManager에 존재하는 엔티티에 대해서 제거하는 것을 볼 수 있다.

그래서, 실제 DB에 제거 쿼리를 발생시키고 싶다면 아래와 같이 테스트를 수정해야 한다.

fun manyToOne_cascadeType_REMOVE_test_자식_엔티티_제거_자식이_여러개일_경우() {
    // given
    val 콘서트 = Concert(name = "인기 많은 콘서트", ticketLimit = 10)
    val 콘서트_티켓1 = ConcertTicket(userId = 1L, concert = 콘서트)
    val 콘서트_티켓2 = ConcertTicket(userId = 2L, concert = 콘서트)
    콘서트.addTicket(콘서트_티켓1)
    콘서트.addTicket(콘서트_티켓2)
    concertRepository.save(콘서트)

    val 저장된_콘서트들 = concertRepository.findAll()
    val 저장된_콘서트_티켓들 = concertTicketRepository.findAll()
    assertThat(저장된_콘서트들).hasSize(1)
    assertThat(저장된_콘서트_티켓들).hasSize(2)

    // when
    assertDoesNotThrow {
        concertTicketRepository.delete(콘서트_티켓1)
    }

    assertThatThrownBy {
        entityManager.flush()
    }.isInstanceOf(ConstraintViolationException::class.java)
}

entityManager에 대해 강제로 플러시를 해서, 영속성 컨텍스트의 내용을 DB에 반영시키는 것이다.

이렇게 되면 아까와 다르게 별도의 조회 쿼리를 발생시키지 않더라도 delete 쿼리가 발생한다. 다만, 외래키 제약 조건이 발생하기 때문에 똑같이 ConstraintViolationException은 생길 수밖에 없다.

DataIntegrityViolationException와 ConstraintViolationException은 모두 외래키 제약 조건 위반에 의해서 발생한다. 다만, ConstraintViolationException의 경우 스프링 프레임워크에서 제공하는 예외 클래스이고, ConstraintViolationException는 하이버네이트에서 제공하는 예외 클래스이다.

부모 엔티티와 자식 엔티티 연관관계 끊기

@Test
@DisplayName("@ManyToOne: CascadeType.REMOVE 테스트 - 부모 엔티티에서 자식 엔티티 제거")
fun manyToOne_cascadeType_REMOVE_test_부모_엔티티에서_자식_엔티티_제거() {
    // given
    val 콘서트 = Concert(name = "인기 많은 콘서트", ticketLimit = 10)

    val 콘서트_티켓1 = ConcertTicket(userId = 1L, concert = 콘서트)
    val 콘서트_티켓2 = ConcertTicket(userId = 2L, concert = 콘서트)
    콘서트.addTicket(콘서트_티켓1)
    콘서트.addTicket(콘서트_티켓2)
    concertRepository.save(콘서트)

    val 저장된_콘서트들 = concertRepository.findAll()
    val 저장된_콘서트_티켓들 = concertTicketRepository.findAll()
    assertThat(저장된_콘서트들).hasSize(1)
    assertThat(저장된_콘서트_티켓들).hasSize(2)

    // when
    콘서트.concertTickets.remove(콘서트_티켓1)
    콘서트.concertTickets.remove(콘서트_티켓2)

    // then
    val 삭제_이후_저장된_콘서트들 = concertRepository.findAll()
    val 삭제_이후_저장된_콘서트_티켓들 = concertTicketRepository.findAll()

    assertThat(삭제_이후_저장된_콘서트들).hasSize(1)
    assertThat(삭제_이후_저장된_콘서트_티켓들).hasSize(2)
}

이전의 @OneToMany의 경우, 부모 엔티티에서 자식 엔티티를 제거하더라도 아무 일도 발생하지 않았었다.

마찬가지로 @ManyToOne의 역시 고아 객체가 발생하더라도 실제 DB에 delete 쿼리가 발생하지 않아서 그대로 조회가 되는 것을 확인할 수 있다.

생각보다 글이 길어져서 orphanRemoval에 대한 내용은 2편에서 알아보도록 하자!

동시성 문제를 해결해보자! 분산락 구현하기 (네임드락 - Named Lock 활용하기)

dolmeng2 — Fri, 23 Jun 2023 17:39:08 +0900

들어가기 전

DB 공부하다가 '네임드락'에 대해서 알게 되었는데, 네임드락을 사용하면 분산락을 구현할 수 있다는 글을 보고 한 번 테스트해보고 싶어서 글을 작성해보고자 한다. 전체 소스코드는 여기에서 확인 가능하다. (뭔가 테스트용 레포 만들기 애매해서 그냥 안 쓰는 레포에다가 하려다 보니 코틀린으로 작성하게 되었다.)

분산락이란?

분산락이란 멀티 스레드 환경에서 공유 자원에 접근할 때, 데이터의 정합성을 지키기 위해 사용하는 기술이다.

여기서 여러 스레드가 공유 자원을 접근하며 경쟁하는 상황을 'Race Condition (경쟁 상태)'라고도 부르며, 자바에서는 'synchronized'라는 키워드를 통해서 하나의 스레드만 접근할 수 있도록 동기화 기능을 제공한다. 하지만, 스프링 웹 애플리케이션 환경에서 규모가 커진다면 서버 역시 여러 대로 띄울 확률이 높다. 이러한 다중 서버에서는 synchronized 만으로는 동시성 이슈를 해결할 수 없기 때문에 다른 방법을 사용해야 하는데, 분산락을 구현하는 다양한 기법들을 통해서 이를 해결할 수 있다.

도메인 설계

실시간 트래픽이 몰리는 환경에 대해서 고민해봤는데, '온라인 티켓팅 서비스'가 딱 떠올랐다.

그래서 간단하게 특정 콘서트에 대해서 티켓을 발행해주는 서비스를 만들기로 결정했다.

도메인이라고 할 것도 없지만, 분산락 테스트를 위해서 최대한 간결하게 설계하였다.

콘서트와 티켓은 1:N 관계를 가지고, 콘서트는 몇 좌석까지 가질 수 있는지에 대한 개수를 가지고 있는다. (ticketLimit)

@Entity
class Concert(
    @Id @GeneratedValue(strategy = GenerationType.IDENTITY)
    val id: Long = 0L,

    @Column(nullable = false)
    val name: String,

    @Column(nullable = false)
    val ticketLimit: Int,

    concertTickets: MutableList<ConcertTicket> = Collections.emptyList()
) {

    @OneToMany(fetch = FetchType.LAZY, mappedBy = "concert")
    val concertTickets: MutableList<ConcertTicket> = concertTickets.toMutableList()

    fun isFull(): Boolean {
        return concertTickets.size >= ticketLimit
    }
}

콘서트에는 정원이 가득 찼는지 확인하는 커스텀 메서드만 간단하게 추가해주었다.

@Entity
class ConcertTicket(
    @Id @GeneratedValue(strategy = GenerationType.IDENTITY)
    val id: Long = 0L,

    @Column(nullable = false)
    val userId: Long,

    @ManyToOne(fetch = FetchType.LAZY)
    @JoinColumn(
        name = "concert_id",
        foreignKey = ForeignKey(name = "fk_ticket_concert_id")
    )
    val concert: Concert
)

이거는 콘서트에 대한 티켓 도메인이다.

CREATE TABLE `concert_ticket` (
  `id` bigint NOT NULL AUTO_INCREMENT,
  `user_id` bigint NOT NULL,
  `concert_id` bigint NOT NULL,
  PRIMARY KEY (`id`),
  KEY `fk_ticket_concert_id` (`concert_id`),
  CONSTRAINT `fk_ticket_concert_id` FOREIGN KEY (`concert_id`) REFERENCES `concert` (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb3

CREATE TABLE `concert` (
  `id` bigint NOT NULL AUTO_INCREMENT,
  `name` varchar(255) NOT NULL,
  `ticket_limit` int NOT NULL,
  PRIMARY KEY (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb3

테이블은 위와 같이 JPA가 만들어 주었다.

코드 설계

Repository

fun ConcertRepository.getConcertById(id: Long): Concert {
    return findConcertById(id) ?: throw NotFoundException("콘서트 정보가 존재하지 않습니다.")
}

interface ConcertRepository : JpaRepository<Concert, Long> {
    fun findConcertById(id: Long): Concert?
}

fun ConcertTicketRepository.getConcertTicketById(id: Long): ConcertTicket {
    return findConcertTicketById(id) ?: throw NotFoundException("콘서트 티켓 정보가 존재하지 않습니다.")
}

interface ConcertTicketRepository : JpaRepository<ConcertTicket, Long> {
    fun findConcertTicketById(id: Long): ConcertTicket?
}

Service

@Service
@Transactional(readOnly = true)
class ConcertService(
    private val concertRepository: ConcertRepository,
    private val concertTicketRepository: ConcertTicketRepository
) {
    ...
    
    @Transactional
    fun createConcertTicket(
        concertId: Long,
        concertTicketCreateRequest: ConcertTicketCreateRequest
    ): Long {
        val concert = concertRepository.getConcertById(concertId)
        if (concert.isFull()) {
            throw ConcertFullException("정원이 가득 찼습니다.")
        }
        val concertTicket =
            ConcertTicket(userId = concertTicketCreateRequest.userId, concert = concert)
        val savedConcertTicket = concertTicketRepository.save(concertTicket)
        return savedConcertTicket.id
    }

    ...
}

여기서 중요한 메서드는 티켓에 대한 생성 메서드이기 때문에, 이 부분만 주목하자.

콘서트 티켓 생성 시 정원이 가득 차면 예외가 발생하도록 만들었다. 만약 요청이 여러 개가 오다가 정원이 가득차면 더 이상 insert는 진행되지 않을 것이다.

Controller

@RestController
@RequestMapping("/concerts")
class ConcertController(
    private val concertService: ConcertService
) {
    ...

    @PostMapping("/tickets/{concertId}")
    fun createConcertTicket(
        @PathVariable("concertId") concertId: Long,
        @RequestBody concertTicketCreateRequest: ConcertTicketCreateRequest
    ) {
        concertService.createConcertTicket(concertId, concertTicketCreateRequest)
    }

}

티켓을 생성하는 API이다. 콘서트나 티켓 조회 같은 간단한 API는 전체 소스코드에 남겨두었다.

JMeter 테스트

부하 테스트를 어떻게 진행할까 고민했는데, JMeter를 활용하면 좋을 것 같아서 진행해보았다.

java -jar -Dserver.port=8080 ticketService.jar
java -jar -Dserver.port=8081 ticketService.jar

먼저, 분산된 환경을 만들기 위해 8080, 8081 2개의 포트를 띄워서 진행하였다.

샘플 데이터로 콘서트 1번에 대한 데이터를 미리 삽입해두었다.

해당 콘서트의 제한 인원은 100명으로, 예상 시나리오라면 100명 이상이 자리잡았을 때 오류가 발생할 것이다.

200개의 스레드를 활용하여 2개의 프로세스에서 동시에 콘서트 티켓 발행 요청을 날렸다.

select count(*) from concert_ticket;

그 결과, 100명까지만 받아야 하는데도 불구하고 111개의 값이 들어간 것을 확인할 수 있다.

왜 이런 문제가 발생한 것일까?

여러 개의 스레드가 조회하는 시점에서는 분명 가득차있지 않았지만, 검증을 통과해버린 스레드가 동시에 여러 개가 발생하면서 insert 연산 역시 한 번에 진행되어 100개가 넘는 데이터가 삽입된 것이다.

Named Lock으로 분산락 구현하기

그렇다면, 위의 상황을 해결하기 위해서는 어떻게 해야 할까?

간단하다. 티켓을 저장하는 로직에 대해서 순차적으로 처리할 수 있도록 만들면 되는 것이다.

fun LockRepository.executeWithLock(
    lockName: String, timeout: String, action: () -> Unit) {
    try {
        getLock(lockName, timeout)
        action()
    } finally {
        releaseLock(lockName)
    }
}

interface LockRepository: JpaRepository<ConcertTicket, Long> {

    @Query("select get_lock(:name, :time)", nativeQuery = true)
    fun getLock(@Param(value = "name") name: String,
                @Param(value = "time") time: String)
                
    @Query("select release_lock(:name)", nativeQuery = true)
    fun releaseLock(@Param(value = "name") name: String)
}

네임드락을 정의해주기 위해서 위와 같이 락을 획득하는 getLock()과 락을 해제하는 releaseLock() 메서드를 선언하였다.

두 가지 모두 jpql이 아닌 native query를 사용해야 하기 때문에, nativeQuery 옵션을 true로 선언해주었다.

getLock의 경우 파라미터로 입력받은 name에 대해서, 입력받은 time 만큼 락을 획득하기를 시도한다.

만약 time 값으로 음수를 넣으면 락을 획득할 때까지 무한 대기하기 때문에 주의해야 한다.

나는 MySQL 8.0을 사용하고 있어서 name으로 60자 이내를 넣어야 한다.

releaseLock의 경우 입력받은 name에 대해서 획득한 락을 해제하는 역할을 한다.

⭐️ 명시적으로 락을 획득했다면 명시적으로 락을 꼭 해제해줘야 하기 때문에 알아두자.

또한, 람다를 통해서 원하는 메서드 전후로 락을 걸고 해제하도록 만들기 위해 executeWithLock() 메서드를 만들어 주었다.

락 해제의 경우 finally를 통해 예외가 발생하더라도 꼭 실행되도록 만들었다.

@Component
class ConcertServiceFacade(
    private val lockRepository: LockRepository,
    private val concertService: ConcertService
){
    @Transactional
    fun createConcertTicket(
        concertId: Long,
        concertTicketCreateRequest: ConcertTicketCreateRequest
    ) {
        val lockName = "concert_$concertId"
        val timeout = "3000"
        lockRepository.executeWithLock(lockName, timeout) {
            concertService.createConcertTicket(concertId, concertTicketCreateRequest)
        }
    }
}

그리고, facade 패턴을 사용하여 lockRepository에 대한 부분을 분리하였다.

비즈니스 로직과 DB 관련 로직을 분리하는 차원에서 별도의 서비스를 생성했다고 생각하면 된다.

lockName으로는 중복되지 않게 하게 위해서 concert_라는 prefix와 concertId를 생성해주었고, 타임아웃은 3초 정도 주었다.

@Transactional(propagation = Propagation.REQUIRES_NEW)
fun createConcertTicket(
    concertId: Long,
    concertTicketCreateRequest: ConcertTicketCreateRequest
) {
	...
}

그리고, ⭐️ 기존의 콘서트 티켓 발행 로직에서 트랜잭션 전파 속성을 변경해줘야 한다.

이는, 락을 제어하는 커넥션과 비즈니스 로직을 위한 커넥션을 분리하기 위해서이다.

만약 락을 제어하는 로직과 비즈니스 로직이 동일한 트랜잭션으로 묶여 있다면, 비즈니스 로직에서 쿼리가 날라가고 커밋이 되었을 때 커넥션이 반환될 때 락이 함께 반환되지 않을 수 있다. 또한, 비즈니스 로직이 수행하는 역할이 많다면 (위 상황은 아니지만, 외부 호출을 진행하거나, 로직 자체가 길거나) 트랜잭션이 길어지기 때문에 락에 대한 제어과 비즈니스 로직의 트랜잭션을 분리하는 것이 좋다.

@PostMapping("/tickets-lock/{concertId}")
fun createConcertTicketWithLock(
    @PathVariable("concertId") concertId: Long,
    @RequestBody concertTicketCreateRequest: ConcertTicketCreateRequest
) {
    concertServiceFacade.createConcertTicket(concertId, concertTicketCreateRequest)
}

이제, 만든 facade 클래스를 호출하는 간단한 end-point를 추가하여 호출해보자.

실행을 해보면 이런 식으로 락을 얻기 위해서 엄청난 호출이 일어난다.

2023-06-23T16:57:19.359+09:00 ERROR 81614 --- [o-8080-exec-289] o.a.c.c.C.[.[.[/].[dispatcherServlet] : Servlet.service() for servlet [dispatcherServlet] in context with path [] threw exception [Request processing failed: org.springframework.transaction.CannotCreateTransactionException: Could not open JPA EntityManager for transaction] with root cause java.sql.SQLTransientConnectionException: HikariPool-1 - Connection is not available, request timed out after 30005ms. at com.zaxxer.hikari.pool.HikariPool.createTimeoutException(HikariPool.java:696) ~[HikariCP-5.0.1.jar!/:na] at com.zaxxer.hikari.pool.HikariPool.getConnection(HikariPool.java:181) ~[HikariCP-5.0.1.jar!/:na] at com.zaxxer.hikari.pool.HikariPool.getConnection(HikariPool.java:146) ~[HikariCP-5.0.1.jar!/:na] at com.zaxxer.hikari.HikariDataSource.getConnection(HikariDataSource.java:128) ~[HikariCP-5.0.1.jar!/:na]

만약 타임아웃으로 설정한 시간 내에 락을 얻지 못하면 위와 같이 락을 얻지 못했다는 오류가 발생한다.

하지만, 성공적으로 락을 얻었다면 insert 쿼리 이후 락을 해제하게 된다.

즉, 순차적으로 락을 잡고, 락 이 잡혀있는 동안에는 또 다시 동일한 이름의 락을 걸 수 없기 때문에 해당 락이 풀릴 때까지 대기하게 된다.

최종적으로 실행 결과를 보면 위와 같이 딱 100개의 정원만 차게 된다.

Connection Pool Size 조절하기

spring:
  datasource:
    hikari:
      maximum-pool-size: 100

스레드를 200개로 했기 때문에 connection pool size를 조금 더 늘려서 테스트를 해봐도 괜찮지 않을까 생각이 들었다.

그래서 connection pool size를 100으로 설정하고 테스트를 진행해보았다. (default는 10이다)

Servlet.service() for servlet [dispatcherServlet] in context with path [] threw exception [Request processing failed: org.springframework.transaction.CannotCreateTransactionException: Could not open JPA EntityManager for transaction] with root cause java.sql.SQLNonTransientConnectionException: Data source rejected establishment of connection, message from server: "Too many connections" at com.mysql.cj.jdbc.exceptions.SQLError.createSQLException(SQLError.java:111) ~[mysql-connector-j-8.0.33.jar!/:8.0.33]

이전에 비해서 티켓 삽입에 대한 속도는 빨라졌지만, 위와 같이 'Too many connections' 오류가 발생하였다.

show variables like 'max_connections';

확인해보니, 기본적으로 mysql에서 제공하는 최대 커넥션 수는 151개이다.

2대의 서버에서 100개씩 점유하고, 총 200개의 요청이 오다 보니 위와 같이 오류가 발생한 것으로 파악되었다.

이런 상황에서는 mysql 서버의 max_connections 수를 충분히 늘리거나, 혹은 hikari pool size를 좀 더 줄이는 방향이 있다. 나는 hikari pool size를 줄이는 방향으로 진행했다. 75로 진행한다면 딱 151개니까 오류가 발생하지 않을 것이라고 예측했다. (1개는 아무 클라이언트가 연결되어 있지 않아도 기본적으로 점유하고 있다. 아마 MySQL 내부에서 사용하는 스레드가 아닐까 추측한다.)

show status where `variable_name` = 'Threads_connected';

실제로 2대의 서버를 띄운 다음, 연결된 스레드의 수를 보면 정확하게 151개를 점유한 것을 볼 수 있다.

티켓 생성 결과를 보니까 정확하게 100개만큼 차있는 것을 확인할 수 있다.

또한, grep을 통해 too many connections 오류가 발생했는지 확인했는데, 100개가 차는 동안 발생하지 않았다.

이번 포스팅에서는 간단하게 named lock을 통해서 분산락을 구현해보았다.

단일 서버가 아닌 다중 서버에서 동시성이 중요한 기능을 구축해야 할 때 redis 같은 외부 인프라 서비스 구축 비용이 부담된다면 이렇게 네임드락을 활용해서도 충분히 진행할 수 있다는 생각이 들었다. 다만, 네임드락에 대한 이해도 있어야 하기 때문에 락에 대한 모니터링을 철저하게 해야겠다는 생각이 들었다. 특히, 타임아웃을 적절하게 설정해서 꼭 점유한 락에 대해서 해제할 수 있도록 하는 게 중요하다는 걸 느꼈다. 또한, 지금은 엄청 작은 규모의 테스트였지만, 실제 운영에서 thread 수와 connection 수를 잘 설정해서 사용자의 요청을 처리해야겠다고 생각했다. 다음 포스팅에서는 redis를 활용해서 분산락을 구현해봐야겠다.

REFERENCE

https://hudi.blog/distributed-lock-with-redis/

https://sudal.site/namedLock/

[Spring] Kotlin에서 data class의 필드가 1개일 때 역직렬화가 안 되는 문제 (no delegate- or property-based Creator)

dolmeng2 — Fri, 23 Jun 2023 15:03:27 +0900

문제 상황

간단하게 테스트하고 싶은 내용이 생겨서 DTO용 data class를 생성하였는데, 아래와 같이 Jackson의 역직렬화 관련 오류가 발생하였다.

Resolved [org.springframework.http.converter.HttpMessageNotReadableException: JSON parse error: Cannot construct instance of `study.ticketService.domain.application.dto.ConcertTicketCreateRequest` (although at least one Creator exists): cannot deserialize from Object value (no delegate- or property-based Creator)]

대충 오류를 보면 역직렬화를 해야 하는데 기본 생성자가 없어서 할 수 없다는 내용이다.

data class ConcertTicketCreateRequest(
    @NotNull(message = "사용자 아이디는 비어있을 수 없습니다.")
    val userId: Long
)

문제가 된 data class는 위와 같다.

Jackson fails to deserialize 1 field POJO · Issue #3085 · FasterXML/jackson-databind

Describe the bug When trying to deserialize JSON to POJO it fails when POJO has only one field. Version information 2.11.4 To Reproduce POJO: @AllArgsConstructor //lombok, if i add constructor manu...

github.com

이 깃허브 이슈에 가면 친절하게 그 이유를 설명해준다.

필드가 1개인 경우 기본 생성자를 만드는 전략이 Delegating / Properties-based로 나뉘는데, 두 모드 중에서 어떤 것을 선택해야 할지 알 수 없어서 발생한 오류인 것이다.

위 이슈에서는 @JsonCreator 어노테이션을 통해서 명시적으로 모드를 지정해주는 방법을 소개하는데, data class에서 어떻게 기본 생성자를 만들 수 있을까?

해결 방법

결론부터 말하자면, 기본값을 명시적으로 지정하거나, 부생성자를 활용하거나, @JsonProperty를 사용하면 된다.

기본 값 지정하기

data class ConcertTicketCreateRequest(
    @NotNull(message = "사용자 아이디는 비어있을 수 없습니다.")
    val userId: Long = 0L
)

주생성자 자체에 기본 값을 지정해준다. id 값은 항상 빈 값이 들어오지 않기 때문에 어차피 대체될 값이라서 상관없다.

부생성자 사용하기

data class ConcertTicketCreateRequest(
    @NotNull(message = "사용자 아이디는 비어있을 수 없습니다.")
    val userId: Long
) {
    constructor() : this(0)
}

혹은, 부생성자를 활용해서 내부적으로 기본값을 초기화해준 생성자를 만들어줄 수 있다.

@JsonProperty 활용하기

data class ConcertTicketCreateRequest(
    @JsonProperty("userId")
    @NotNull(message = "사용자 아이디는 비어있을 수 없습니다.")
    val userId: Long
)

하지만, 기본값을 지정하거나 기본 생성자를 만들어둔다는 게 상당히 찝찝한 일처럼 느껴질 수 있다.

이때는 @JsonProperty를 통해서 명시적으로 json 값의 key와 해당 객체의 필드를 매칭시켜줄 수 있다.

해당 어노테이션에 대해서 좀 더 알고 싶다면 이 글을 참고해 주세요!

개인적으로는 1번 방법이 가장 깔끔해서 그냥 기본값을 지정해주는 걸로 만들었다.

오류 없이 잘 들어가는 것을 볼 수 있다.

[MySQL] 트랜잭션 격리 수준을 쿼리를 통해 직접 테스트해보기

dolmeng2 — Wed, 21 Jun 2023 17:53:35 +0900

들어가기 전

지난 리마큐 포스팅에서 그림으로 설명했던 'CREW' 테이블에 대해서 직접 코드 레벨로 작성해보고자 한다.

CREATE TABLE `CREW` (
  `id` bigint NOT NULL,
  `name` varchar(255) NOT NULL,
  PRIMARY KEY (`id`)
) ENGINE=InnoDB;

사전 설정을 위해서 스토리지 엔진을 innoDB로 설정한 'CREW' 테이블을 생성해준다.

SET AUTOCOMMIT = false;

⭐️ 그리고, autocommit 모드는 꼭 OFF로 설정해두고 진행하자.

나는 이번에 2개의 세션을 열어서 진행하였다.

READ UNCOMMITTED

SET SESSION TRANSACTION ISOLATION LEVEL READ UNCOMMITTED;

글로벌 설정으로 격리 수준을 변경하면 여파가 크기 때문에 각 세션에 대해서 위와 같이 READ UNCOMMITTED를 지정해주었다.

SELECT @@SESSION.transaction_isolation;

실제로 세션 정보를 확인해보면 위와 같이 READ-UNCOMMITTED로 변경된 것을 확인할 수 있다.

Dirty Read 확인해보기 - INSERT

START TRANSACTION;
INSERT INTO CREW (id, name) VALUES (1, 'hello');
commit;

그리고, 그림이랑 똑같이 만들기 위해서 우선 1번 레코드인 'hello'를 삽입해두자. (어떤 세션이든 상관 없다)

# 세션 1
START TRANSACTION;
INSERT INTO CREW (id, name) VALUES (2, 'journey');

이후, 세션 1에서 Commit 하지 않고 단순히 2번 레코드 'journey'를 삽입하자.

# 세션 2
select * from CREW;

세션 2에서 결과를 확인해보면, 세션 1에서 아직 커밋을 하지 않았음에도 삽입이 되어 있는 것을 확인할 수 있다. (Dirty Read)

그럼, 이 상태에서 세션 1을 롤백시키면 어떻게 될까?

# 세션 1
ROLLBACK;

롤백 사항이 반영되어 데이터가 나오지 않는 것을 볼 수 있다.

즉, 이전에는 값이 보였는데 다시 조회하니 값이 사라지는 현상이 발생할 수 있기 때문에 주의해야 한다.

Dirty Read 확인해보기 - UPDATE

⭐️ 위의 경우보다 update 시에 더 명확하게 드러나는 것 같아서 한 가지 더 테스트를 하고자 한다.

# 기본 데이터 삽입 후 커밋
START TRANSACTION;
INSERT INTO CREW (id, name) VALUES (1, 'hello');
COMMIT;

# 해당 데이터에 대해서 업데이트
START TRANSACTION;
UPDATE CREW SET name = 'hi' where id = 1;

아까처럼 hello라는 레코드가 삽입된 다음, 업데이트에 대한 트랜잭션을 시작하고 커밋을 하지 않은 상태이다.

# 세션 2
SELECT * FROM CREW;

하지만, READ UNCOMMITTED로 인해서 커밋되지 않은 사항에 대해서도 변경된 레코드 값이 조회되는 것을 볼 수 있다.

# 세션 1
ROLLBACK;

이 상태에서 세션 1에 대해 롤백을 한다면 hello라는 값을 받게 된다...!

READ COMMITTED

SET SESSION TRANSACTION ISOLATION LEVEL READ COMMITTED;

이번에는 트랜잭션 격리 레벨을 Read committed로 변경하고 살펴보자.

해결된 Dirty Read 현상 확인하기

START TRANSACTION;
INSERT INTO CREW (id, name) VALUES (1, 'hello');
INSERT INTO CREW (id, name) VALUES (2, 'journey');
COMMIT;

먼저, 그림과 같은 상황을 만들기 위해 2개의 레코드를 삽입해두자. (이전의 실험 결과는 TRUNCATE로 제거하였다.)

# 세션 1
START TRANSACTION;
UPDATE CREW SET name = 'hi' WHERE id = 1;

이후, 세션 1에서 1번 레코드 'hello'에 대해 hi로 업데이트하는 쿼리를 작성한다. 단, 커밋하지 않는다.

# 세션 2
SELECT * FROM CREW;

이때 세션 2에서 조회해보면 언두 영역에 있는 데이터를 읽어오기 때문에 hi가 아닌 hello로 보이는 것을 볼 수 있다.

⭐️ 이전의 read uncommitted 예제와 달라진 것을 확인할 수 있다. (dirty read 해결)

이후, 세션 1에서 커밋을 하고 나면 아래와 같이 변경 사항이 완전히 반영된다.

# 세션 1
COMMIT;

# 세션 2
SELECT * FROM CREW;

NON-REPEATABLE READ 확인하기

하지만, 여기서도 문제가 있다.

위와 같은 상황에서 세션 2의 조회 쿼리 2번이 하나의 트랜잭션에서 수행된다면 어떨까?

# 세션 1
START TRANSACTION;
UPDATE CREW SET name = 'hi' WHERE id = 1;

# 세션 2
START TRANSACTION;
SELECT * FROM CREW; # 1번 결과

# 세션 1
COMMIT;

# 세션 2
SELECT * FROM CREW; # 2번 결과

현재는 쿼리를 직접 날리고 있기 때문에 알아보기 어렵지만, 만약 스프링에서 개발을 진행하는 상황이라고 해보자.

하나의 트랜잭션으로 묶여 있고, 동일한 쿼리를 날렸음에도 위와 같이 다른 결과를 받아올 수 있는 문제가 발생할 수 있어 주의해야 한다. (non-repeatable read 발생)

REPEATABLE READ

SET SESSION TRANSACTION ISOLATION LEVEL REPEATABLE READ;

마찬가지로 이번에는 격리 수준을 repeatable read로 설정해준다.

해결된 NON-REPEATABLE READ 확인하기

START TRANSACTION;
INSERT INTO CREW (id, name) VALUES (1, 'hello');
INSERT INTO CREW (id, name) VALUES (2, 'journey');
COMMIT;

샘플 레코드도 삽입해둔다.

# 세션 2
SELECT * FROM CREW;

먼저, 세션 2에서 조회 쿼리를 날려두면 삽입한 2개의 레코드를 그대로 반환하는 것을 볼 수 있다.

# 세션 1
START TRANSACTION;
UPDATE CREW SET name = 'hi' where id = 1;

# 세션 2
SELECT * FROM CREW;

이 상태에서 세션 1이 1번 레코드에 대해 업데이트 쿼리를 날리고, 세션 2에서 조회하면 그대로 'hello'라는 레코드가 뜬다.

# 세션 1
COMMIT;

# 세션 2
SELECT * FROM CREW;

하지만, read committed와 다르게 세션 1에서 커밋을 했더라도 세션 2의 결과는 hi가 아닌 hello가 그대로 나오는 것을 볼 수 있다.

⭐️ 즉, 이전에 발생하였던 non-repeatable read를 해결한 것이다.

# 세션 2
COMMIT;

# 다시 조회
SELECT * FROM CREW;

이후, 세션 2가 시작하였던 트랜잭션을 커밋하고 다시 조회 쿼리를 날려보면 위와 같이 변경된 사항을 읽어오는 것을 확인할 수 있다.

PHANTOM READ 테스트하기

CREATE TABLE `ISAM_CREW` (
  `id` bigint NOT NULL,
  `name` varchar(255) NOT NULL,
  PRIMARY KEY (`id`)
) ENGINE=MyISAM;

우선, innoDB에서는 Phantom Read가 발생하지 않도록 하기 때문에 새로운 테이블을 만들자.

START TRANSACTION;
INSERT INTO ISAM_CREW (id, name) VALUES (1, 'hello');
INSERT INTO ISAM_CREW (id, name) VALUES (2, 'journey');
COMMIT;

그리고, 마찬가지로 샘플 데이터를 넣어두자.

# 세션 2
START TRANSACTION;
SELECT * FROM ISAM_CREW WHERE id >= 2 FOR UPDATE;

세션 2에서 SELECT FOR UPDATE 구문을 활용하여 레코드를 조회해보자. 현재 'journey' 레코드만 나오는 것을 볼 수 있다.

# 세션 1
START TRANSACTION;
INSERT INTO ISAM_CREW(id, name) VALUES (3, 'cat');
COMMIT;

이후, 세션 1에서 새로운 레코드를 삽입하고 커밋을 해보자.

# 세션 2
SELECT * FROM ISAM_CREW WHERE id >= 2 FOR UPDATE;

위와 같이 journey에 이어 cat이라는 3번 레코드가 추가된 것을 볼 수 있다.

같은 트랜잭션 내인데도 다른 결과가 나오는 'phantom read' 현상이 발생하게 된 것이다.

PHANTOM READ - innoDB에서는 정말 발생하지 않을까?

앞서 사용했던 innoDB 스토리지 엔진으로 생성된 'CREW' 테이블을 다시 한 번 가져오자.

위에서 진행했던 실험과 동일하게 샘플 레코드 삽입 후 SELECT FOR UPDATE를 진행해주자.

# 세션 2
START TRANSACTION;
SELECT * FROM CREW WHERE id >= 2 FOR UPDATE;

# 세션 1
START TRANSACTION;
INSERT INTO CREW(id, name) VALUES (3, 'cat'); # 삽입 대기

innoDB에서는 세션 2의 트랜잭션이 커밋되기 전까지 ⭐️ 넥스트 키락이 걸리기 때문에 삽입이 불가능하며, 타임아웃이 발생하게 된다.

# 세션 2
COMMIT;

타임아웃이 발생하기 전에 세션 2에서 커밋을 진행하게 되면 insert가 성공적으로 진행된다.

# 세션 1 - 이전에 작성하였던 insert query
START TRANSACTION;
INSERT INTO CREW(id, name) VALUES (3, 'cat');

# 이 트랜잭션에서 조회 진행
SELECT * FROM CREW;

# 세션 3 - 세션 1의 커밋 전에 조회 진행
SELECT * FROM CREW;

# 세션 1 커밋
COMMIT;

# 세션 3 재조회
SELECT * FROM CREW;

여기서 insert을 진행했던 트랜잭션에서 select를 작성하면 삽입이 된 모습을 볼 수 있다.

물론 commit 이전에는 다른 트랜잭션에서 값을 확인할 수 없기 때문에 commit 후에 확인이 가능하다.

PHANTOM READ - SELECT FOR UPDATE

하지만, innoDB를 사용하더라도 select for update를 사용하게 되면 데이터의 부정합이 발생할 수 있다.

마찬가지로 샘플 레코드 삽입 후 아래와 같이 진행해주자.

# 세션 2
START TRANSACTION;
SELECT * FROM CREW WHERE id >= 1;

# 세션 1
START TRANSACTION;
UPDATE CREW SET name = 'hi' where id = 1;
COMMIT

# 세션 2 (기존의 트랜잭션에서 진행)
SELECT * FROM CREW WHERE id >= 1 FOR UPDATE;

그럼 위와 같이 처음에는 hello, journey가 조회되다가 insert가 진행되자 undo 영역의 데이터가 아닌 원본 테이블의 내용을 읽어 hi, journey가 조회되는 것을 확인할 수 있다.

SERIALIZABLE

SET SESSION TRANSACTION ISOLATION LEVEL SERIALIZABLE;

가장 마지막으로 serializable에 대해서 알아보자.

# 세션 2
START TRANSACTION;
select * from CREW;

테이블에 아무것도 삽입하지 않은 상태에서, 세션 2가 조회 쿼리를 날렸다. 당연히 아무것도 조회되지 않는다.

# 세션 1
START TRANSACTION;
INSERT INTO CREW (id, name) VALUES (1, 'hello');

이후, 세션 1이 삽입 쿼리를 날리려고 하면 오른쪽과 같이 계속 대기 상태에 들어가는 것을 볼 수 있다. (쿼리 실행 16s)

세션 2가 커밋하지 않으면 계속 대기하다가 위와 같이 타임아웃이 발생한다.

즉, 세션 2는 단순히 조회 쿼리만 날렸는데도 세션 1이 삽입하지 못하기 때문에 읽기에 대해서도 락이 걸린다는 것을 확인할 수 있다.

이렇게 트랜잭션 격리 수준에 대해서 전부 테스트를 완료하였다.

한 번쯤 쿼리를 날려보며 직접 테스트해보고 싶던 내용이었는데, 이렇게 진행하니까 매우 재밌었다

종종 공부하면서 다시 복습해야겠다.

[Real MySQL 8.0] InnoDB의 인덱스와 락, 트랜잭션 격리 수준

dolmeng2 — Mon, 19 Jun 2023 00:51:00 +0900

들어가기 전

이번 포스팅에서는 InnoDB의 인덱스와 락의 상관관계와 트랜잭션 격리 수준에 대해서 알아보자.

인덱스와 락

지난 포스팅에서 레코드 락에 대해 정리할 때 다음과 같은 멘트를 남겼다.

innoDB의 경우 레코드 자체를 잠그는 것보다는, 인덱스의 레코드를 잠근다.

인덱스를 잠그기 때문에 레코드 검색 시 발견된 모든 레코드의 락을 걸게 된다.

예를 들어, crew 테이블에 age = 23인 사람이 100명이라고 생각해보자.
이때, age에는 인덱스가, name에는 인덱스가 걸려있지 않은 상태다.

SELECT COUNT(*) FROM crew WHERE age = 23;
# result: 100

하지만, age = 23이면서 name = 'journey'인 결과는 1개만 나온다고 가정해보자.

SELECT COUNT(*) FROM crew WHERE age = 23 and name = 'journey';
# result: 1

이때, age = 23이고 name = 'journey'인 레코드에 대해서 last_modified_at 레코드를 NOW()로 업데이트한다고 생각해보자.

UPDATE crew SET last_modified_at = NOW() WHERE age = 23 and name = 'journey';

위의 쿼리문을 실행하기 위해서 몇 개의 레코드에 락을 걸게 될까?

바로, age = 23의 결과로 나온 100개의 레코드에 대해서 모두 락이 걸리게 된다.
인덱스가 만약 하나도 없다면 테이블에 대해 전체 스캔 (full-scan)을 하면서 update를 진행하기 때문에 모든 레코드에 대해서 락을 걸게 될 것이고, 성능에 치명적인 문제가 발생할 것이다. 그렇기 때문에 인덱스를 잘 거는 것이 매우 중요하다!

MySQL 8.0부터는 락에 대한 정보를 performance_schema DB를 통해서 확인할 수 있다.

SELECT
    t1.trx_id waiting_trx_id,
    t1.trx_mysql_thread_id waiting_thread,
    t1.trx_query waiting_query,
    t2.trx_id blocking_trx_id,
    t2.trx_mysql_thread_id blocking_thread,
    t2.trx_query blocking_query
FROM performance_schema.data_lock_waits w
INNER JOIN information_schema.INNODB_TRX t1 ON t1.trx_id = w.REQUESTING_ENGINE_TRANSACTION_ID
INNER JOIN information_schema.INNODB_TRX t2 ON t2.trx_id = w.BLOCKING_ENGINE_TRANSACTION_ID

waiting_trx_id의 경우 대기하고 있는 트랜잭션의 아이디를, waiting_thread는 대기하고 있는 스레드의 번호를, waiting_query는 대기하고 있는 쿼리 정보를, blocking_trx_id는 블락킹 상태에 있는 트랜잭션의 아이디를, blocking_thread는 블락킹 상태에 있는 스레드를, blocking_query는 블락킹 상태에 있는 쿼리 정보를 의미한다.

여기서 대기 상태는 트랜잭션이 다른 트랜잭션의 작업이 완료되기를 기다리는 상태를, 블락킹 상태는 다른 트랜잭션이 이미 사용 중인 데이터나 락을 요청한 상태를 의미한다.
= 즉, waiting_trx_id가 blocking_trx_id를 기다리고 있는 상태를 한눈에 확인할 수 있게 된다.
락을 풀기 위해서는 blocking_trx_id가 가지고 있는 락을 해제하고, 그 뒤로 waiting_trx_id의 작업이 이루어져야 한다.

만약 더 상세한 정보를 확인하고 싶다면 data_locks의 테이블을 모두 확인해보자.

SELECT * FROM performance_schema.data_locks;

여기서 engine_transaction_id와 thread_id, 그리고 lock_type과 lock_mode을 확인해보면 어떤 트랜잭션이 어떤 스레드가 사용하고 있고, 어떤 락을 가지고 있는지까지 확인이 가능하다. 만약 결과에서 REC_NOT_GAP 이라는 lock_mode가 있다면 이는 레코드 락에서 갭이 포함되지 않은 순수한 락을 가지고 있음을 의미한다. (lock_mode의 결과로는 S[,GAP], X[,GAP], IS[,GAP], IX[,GAP], AUTO_INC 및 UNKNOWN가 나올 수 있다.)

만약, 특정 스레드가 락을 너무 오래 보유하고 있다면 아래와 같이 KILL을 해주자.

KILL thread_id

트랜잭션 격리 수준

트랜잭션 격리 수준은 여러 트랜잭션이 동시에 처리될 때 특정 트랜잭션이 다른 트랜잭션에서 변경하거나 조회하는 데이터를 볼 수 있도록 할지 말지 결정하는 것이다. 크게 4가지의 격리 수준이 존재하며, READ UNCOMMITTED / READ COMMITTED / REPEATABLE READ / SERIALIZABLE로 나뉜다. Read Uncommitted와 Serializable의 경우 보통 잘 사용되지 않는다.

	DIRTY-READ	NON-REPEATABLE READ	PHANTOM READ
READ UNCOMMITTED	O	O	O
READ COMMITTED	X	O	O
REPEATABLE READ	X	X	O (innoDB에서는 발생 X)
SERIALIZABLE	X	X	X

오라클에서는 Read Committed를 사용하며, MySQL에서는 Repeatable Read를 주로 사용한다.

READ UNCOMMITTED

기본적으로 커밋이나 롤백 여부에 상관없이 다른 트랜잭션에서 확인할 수 있는 격리 수준이다.

위 그림을 보면, 아직 'journey'라는 레코드가 커밋되지 않았는데도 사용자 B가 해당 내용을 read 할 수 있는 것을 볼 수 있다.

작업이 완료되지 않았는데도 다른 트랜잭션에서 볼 수 있는 현상을 'Dirty Read'라고 하며, 이런 경우엔 데이터가 나타났다가 사라졌다가 하는 현상을 초래하기 때문에 데이터의 정합성에 문제가 발생한다. 웬만하면 read uncommitted의 경우 사용하지 않는 것이 좋다.

READ COMMITTED

오라클에서 기본적으로 사용하는 격리 수준이며, Dirty Read가 해결된 격리 수준이다.
다른 트랜잭션에 의해 데이터가 변경되더라도 Commit이 완료된 데이터만 조회가 가능하다.

위 그림을 보면, 기존의 1번 레코드는 name = hello였고, 이에 대해서 'hi'라고 업데이트를 한 것을 볼 수 있다.
이때 사용자 B가 1번 레코드에 대해서 조회할 때, 테이블이 아닌 업데이트 시 언두 로그에 저장했던 값을 읽어서 반환하기 때문에 업데이트 되기 전 데이터가 반환되며, 추후 커밋이 되어야 완전하게 반영이 완료된다.

커밋된 데이터만 읽기 때문에 '작업이 완료되지 않은 데이터를 읽는다'는 Dirty Read는 해결되었지만, 하나의 트랜잭션에서 SELECT 시 항상 같은 결과를 반환하는 것이 아닌 UPDATE 이전의 데이터와 이후의 데이터가 다른 데이터가 반환되기 때문에 'Non-Repeatable Read'가 발생한다.

단순한 웹 서비스에서 이는 크게 문제가 되지 않지만, 하나의 트랜잭션에서 동일한 데이터를 여러 번 읽고 쓰는 작업이 금전 행위와 관련이 되면 문제가 발생할 수 있다. 특히, 입-출금 로직을 생각해보자. 처음에 10000원이 조회되어서 1000원을 추가하고 11000원이 나오길 기대했는데, 다시 조회하니 6000원으로 나온다면 매우 당혹스러울 것이다.

참고로, 트랜잭션 내부에서 실행되는 SELECT 문과 외부에서 실행되는 SELECT문의 차이는 없다.
하지만, Repeatable-Read에서는 SELECT까지 트랜잭션 범위 내에서만 작동하여 계속 동일한 결과만 보이도록 만들게 된다. 이에 대해서는 아래에서 확인해보자.

REPEATABLE READ

InnoDB에서 기본으로 사용하는 격리 수준으로, 바이너리 로그를 가진 MySQL 서버에서는 최소 Repeatable read 이상의 격리 수준을 가져야 한다. innoDB에서는 MVCC를 활용하여 변경 전 레코드를 언두 공간에 백업해두고, 실제 레코드 값을 변경하는데 이 MVCC를 활용하여 동일한 트랜잭션에서는 동일한 결과를 보여주도록 보장한다.
근데 앞서 봤던 Read Committed 역시 언두 로그에 있는 값을 보여줬었는데, repeatable read와 뭐가 다른 것일까?
이는, 언두 영역에 백업된 값 중 몇 번째 이전까지 찾아 들어가는지에 따라 달라진다.

언두 영역에는 기본적으로 변경을 발생시킨 트랜잭션의 번호도 함께 저장해둔다. innoDB는 불필요하다고 판단하는 시점에 과거의 언두 로그를 제거하는데, 이때 현재 실행 중인 트랜잭션 중 가장 오래된 트랜잭션 번호보다 앞선 언두 영역의 데이터는 제거가 불가능하다. 정확하게는, 특정 트랜잭션 구간 내에서 백업된 언두 데이터가 보존되어야 한다.

그림이 너무 아래로 길어져서 양옆으로 쪼갰다.
먼저, 사용자 B가 트랜잭션을 시작하기 전에 id = 1, name = hello인 레코드와 id = 2, name = journey인 레코드가 존재했다.
이때 select를 통해 조회했을 때 name = hello를 조회하였다.

이후, 트랜잭션 아이디 12번이 update를 통해서 id = 1의 레코드의 name을 hi로 변경하였고, 변경 전 사항에 대해 언두 로그에 기록하였다. 이때, 언두 로그에는 변경 전 트랜잭션 아이디인 6번도 함께 기록되어 있다.

사용자 B가 다시 id = 1에 대해 조회를 했을 때 언두 로그에 대한 정보를 확인하는데, 이때 사용자 B의 트랜잭션 아이디인 10보다 작은 언두 로그의 값을 확인하여 조회하게 된다. 덕분에 업데이트가 되든 안 되든 항상 같은 name = hello의 값을 읽어올 수 있게 된다.
위 경우는 예제를 단순화하기 위해서 언두 영역의 데이터가 하나지만, 당연히 여러 개의 데이터가 존재할 수 있다. 트랜잭션이 길어지면 길어질수록 언두 영역의 데이터 역시 계속 늘어날 수 있기 때문에 MySQL 서버 성능에도 영향을 끼친다는 것을 주의하자.

하지만, 이 역시 부정합이 발생할 수 있다.

처음 SELECT에서는 journey만 받아오지만, 두 번째 SELECT에서 journey와 cat을 받아왔다.
이렇게 다른 트랜잭션에 수행한 변경 작업에 의해 레코드가 보였다 안 보였다 하는 현상을 'Phantom Read' 라고 한다.

기본적으로 select ... for update는 쓰기 락을 걸어야 하는데, 언두 로그에는 락을 걸 수 없기 때문에 select ... for update나 select ... lock in share mode로 조회되는 레코드는 변경 전 데이터가 아닌 현재 레코드의 값을 가져오게 된다.
- select for update는 특정 레코드에 대해서 X-Lock을 거는 구문이고 (업데이트를 위해서 베타 락을 거는 느낌), select lock in share mode는 S-Lock을 거는 구문이다.

Non-Repeatable Read랑 똑같은 거 아닐까?
여기서 '결과의 집합이 다르게 나왔다'는 점에 포커스를 맞춰야 한다. non-repeatable read의 경우 1개의 결과가 나오지만, 업데이트로 인해서 hello, hi라는 2개의 결과가 나왔고, 여기에서는 journey와 journey, cat이라는 2개의 결과가 나왔다.
동일한 트랜잭션 내에서 동일한 쿼리를 실행하더라도 다른 결과를 얻는다는 게 non-repeatable read이고, 다른 결과 집합을 얻을 수 있다는 게 phantom-read이다. non-repeatable read의 경우 수정된 데이터에 대한 일관성 문제를, phantom read의 경우 삽입이나 삭제된 데이터에 대한 일관성 문제를 가진다.

InnoDB에서는 왜 Phantom Read가 발생하지 않을까?

지난 포스팅에서 봤듯이, innoDB에서 제공하는 락 중에서 '레코드 락'과 '갭 락'을 합친 '넥스트 키 락'을 제공한다는 것을 알 수 있다.

위와 같이 사용자 B의 트랜잭션이 커밋되기 전에 select 시 락을 잡고 있어서 계속 같은 결과를 반환하는 것을 볼 수 있다.

⭐️ 하지만, select 이후 select for update로 조회하게 된다면 언두 영역이 아닌 원본 테이블의 값을 받아오기 때문에 데이터의 부정합이 발생한다. 즉, innoDB에서 phantom read가 무조건 발생하지 않는 것은 아니다! select for update의 경우 발생할 수 있다.

SERIALIZABLE

가장 단순하면서도 엄격한 격리 수준이다. 그렇기 때문에 다른 격리 수준보다 동시성 작업이 떨어진다.
기본적으로 innoDB 테이블에서 순수한 select 작업은 락 없이도 수행되지만, serializable에서는 읽기에 대해서도 S-Lock을 걸어야 하며, 다른 트랜잭션에서는 해당 레코드를 변경할 수 없게 된다. 이 덕분에 Phantom read 현상이 발생하지는 않지만, innoDB에서는 Gap Lock과 Next Key Lock 덕분에 repeatable read에서도 phantom read가 발생하지 않아서 굳이 사용할 필요가 없다.

코드 레벨로 위 격리 수준을 확인하고 싶다면 아래 포스팅을 확인해 주세요
[MySQL] 트랜잭션 격리 수준을 쿼리를 통해 직접 테스트해보기

[Real MySQL 8.0] 트랜잭션과 MySQL / InnoDB의 락 (Lock)

dolmeng2 — Sun, 18 Jun 2023 17:50:32 +0900

들어가기 전

이번 포스팅에서는 트랜잭션에 대한 간단한 개념과, MySQL과 InnoDB 스토리지엔진에서 제공하는 락에 대해서 알아보자.

트랜잭션

트랜잭션은 하나의 논리적인 작업 셋에 완전히 적용(commit)되거나, 아무것도 적용되지 않음 (rollback)을 보장해야 한다.
InnoDB와 MyISAM 테이블은 트랜잭션 관점에서도 차이를 보이는데, 이를 확인해보자.
우선, 아래와 같이 myISAM과 innoDB를 사용한 2개의 테이블을 만들자.

CREATE TABLE tb_myisam (
    id INT NOT NULL,
    PRIMARY KEY (id)
) ENGINE=MYISAM;

CREATE TABLE tb_innodb (
    id INT NOT NULL,
    PRIMARY KEY (id)
) ENGINE=innodb;

그리고, 각각에 대해서 레코드를 1개씩 저장해보자.

insert into tb_myisam (id) values (3);
insert into tb_innodb (id) values (3);

이후, auto commit 모드를 활성화한 다음 다음과 같이 레코드를 추가해보자.

AUTO COMMIT이란?
사용자가 commit 명령어를 사용하지 않아도 SQL문이 성공적으로 실행되면 자동으로 커밋을, 문제가 발생하면 알아서 롤백을 해준다. 기본적으로는 활성화가 되어 있다.

set autocommit = on;

insert into tb_myisam (id) values (1), (2), (3);
insert into tb_innodb (id) values (1), (2), (3);

당연히 primary key로 설정된 컬럼에 동일한 값을 넣으려고 했기 때문에, 두 테이블 모두 오류가 발생한다.

하지만, 실제로 select 했을 때의 결과는 다음과 같다.

tb_myisam

tb_innodb

myISAM으로 생성한 테이블의 경우 1, 2, 3 모두가 그대로 삽입되어 있는 것이다.
이는, 롤백이 발생하지 않았다기보다는, 쿼리문에서 1, 2는 삽입 성공했지만 3을 삽입한 순간에 오류가 발생하여 3에 대해서만 삽입하지 않고 종료한 것이다. 반면에, innoDB의 경우 우리가 흔히 생각한 것처럼 1, 2, 3 모두를 삽입하는 쿼리에 대해서 롤백을 한다.
이런 현상을 'Partial Update'라고 하며, 데이터의 경합성을 맞추는 데 어려움을 주는 요소 중 하나이다.
왜 innoDB를 많이들 사용하는지 한 가지 이유를 더 알아간다

락 - MySQL

MySQL에서 락은 크게 스토리지 엔진 레벨과 MySQL 엔진 레벨로 나눌 수 있다.
MySQL 엔진 레벨의 락은 글로벌 락, 테이블 락, 메타데이터 락, 네임드 락을 제공한다.

글로벌 락

MySQL에서 제공하는 락 중에서 가장 범위가 큰 락이다.

FLUSH TABLES WITH READ LOCK

하나의 세션에서 글로벌 락을 획득하면 다른 세션에서 select를 제외한 대부분의 DDL / DML 문장 실행 시, 글로벌 락이 해제될 때까지 계속 대기 상태로 남게 된다. MySQL 서버 전체에 영향을 주기 때문에 작업 중인 테이블이나 데이터베이스를 넘어서 동일하게 영향을 준다.

만약, 글로벌 락이 실행되기 전에 쓰기 락이 걸린 SQL이 실행됐다면, 기존의 쓰기 락이 완전히 해제된 이후에 글로벌 락이 걸리게 된다. 즉, 현재 실행 중인 모든 쿼리가 완료되어야만 글로벌 락을 실행할 수 있는 것이다. 하지만, MySQL 8.0부터 Xtrabackup, Enterprise Backup 같이 '백업 락'이라는 조금 더 가벼운 락이 추가되었다.

# 백업 락
LOCK INSTANCE FOR BACKUP;

# 락 해제
UNLOCK INSTANCE;

백업 락의 경우 특정 세션에서 획득하면 모든 세션에서 아래와 같은 정보를 변경할 수 없다.

- 데이터베이스나 테이블 등, 모든 객체의 생성 및 변경, 삭제
- REPAIR TABLE / OPTIMIZE TABLE
- 사용자 관리 및 비밀번호 변경

하지만, 일반적인 테이블의 데이터 변경은 허용하기 때문에 이전의 글로벌 락보다 확실히 완화된 락을 사용할 수 있다.
기존의 글로벌 락을 사용했다면 복제용 서버 (레플리카 서버)에서 데이터의 복제가 일어나는 도중에 기존 서버에서 오류가 생겼다면 백업 역시 계속 지연 / 혹은 실패했을 것이다. 백업이라는 것은 상당히 오래 걸리는 작업이기 때문에 실패 시에 또 다시 엄청난 시간을 들여야 하고, 그러면 서비스 자체에도 영향이 크기 때문에 이러한 문제를 해결하기 위해서 '백업 락'이라는 것이 도입되었다.

테이블 락

테이블 락의 경우 테이블 단위로 설정하는 잠금이며, 명시적 (explicit) / 암시적 (implicit) 락을 획득할 수 있다.

# 락 획득
LOCK TABLES table_name [READ | WRITE]

# 락 해제
UNLOCK TABLES

락을 획득할 때 2개의 옵션을 줄 수 있는데, 하나는 READ, 하나는 WRITE이다.

READ
- 테이블에 대한 읽기 락 획득
- 다른 세션이 동시에 같은 테이블에 대한 읽기 락 획득 가능
- 테이블에 대한 내용은 읽을 수 있지만, 수정은 불가능
- 동시에 다른 세션이 해당 테이블에 대해서 쓰기 락 획득 불가능

WRITE
- 테이블에 대한 쓰기 락 획득
- 다른 세션이 동시에 같은 테이블에 대한 읽기 락, 쓰기 락 획득 불가능
- 쓰기 락을 획득한 세션은 테이블의 내용을 읽고 수정할 수 있음

명시적 락의 경우 위와 같이 쿼리를 통해서 직접적으로 선언하는 방법이며, 묵시적 락의 경우 테이블을 변경하는 쿼리를 실행했을 때 MySQL 서버가 해당 테이블에 락을 설정하고 데이터를 변경한 다음, 바로 락을 해제하는 형태로 사용된다. 자동으로 할당 및 해제가 일어나기 때문에 편리하지만, innoDB의 경우 레코드 기반 락을 제공하기 때문에 테이블 락이 실행되더라도 DML에서는 무시되고, DDL에서만 영향을 준다.

네임드 락

테이블, 레코드가 아닌 임의의 문자열에 대해 잠금을 획득할 수 있다. (일종의 변수 느낌?)
1대의 DB 서버에 여러 대의 웹 서버가 접속하였을 때 특정 정보를 동기화해야 하는 상황에서 네임드락을 사용할 수 있다.

# hello라는 문자열에 대해서 잠금 획득
# 이미 사용 중이라면 2초 대기 후 해제
SELECT GET LOCK('hello', 2);

# 잠금이 설정되어 있는지 확인
SELECT IS_FREE_LOCK('hello');

# hello라는 문자열에 대해 획득했던 잠금 해제
SELECT RELEASE_LOCK('hello');

3가지 쿼리 모두 select문의 결과로 락을 정상적으로 획득하거나 해제하면 1을, 아니라면 null이나 0을 반환한다.

# 동시에 락 걸기
SELECT GET_LOCK('hello1', 10);
SELECT GET_LOCK('hello2', 10);

# 모두 해제
SELECT RELEASE_ALL_LOCKS();

네임드 락의 경우 복잡한 조건으로 레코드를 한꺼번에 많이 변경할 때 사용하며, MySQL 8.0부터는 네임드 락을 중첩하여 사용하는 것을 가능하도록 만들었다.

메타데이터 락

테이블이나 뷰의 이름이나 구조를 변경하는 경우, 메타데이터 락을 획득한다.
명시적으로 획득하거나 해제가 안 되며 RENAME 등의 쿼리를 실행할 때 자동으로 획득하는 잠금이다.

# 이러면 tb_1, tb_2 모두에 대해서 잠금을 설정한다
RENAME TABLE tb_1 TO tb_2;

테이블의 이름을 변경할 때 혹시나 실서비스에서 '해당하는 테이블이 없습니다' 같은 경고 메시지가 뜨지 않도록 하기 위해서는, 하나의 rename table 쿼리에 여러 개의 조건을 넣어두면 된다.

RENAME TABLE tb_1 to tb_2, tb_3 to tb_1

이렇게 되면 tb_1에 대해서는 tb_2로 바꾸면서, 기존의 tb_3을 tb_1이라는 이름으로 바로 바꾸기 때문에 경고 메시지가 뜨지 않는다.

테이블 락 + 메타데이터 락

로그 정보를 저장하는 로그 테이블이 있다고 생각해보자. 단순히 사용자의 웹 요청에 대한 정보를 저장하기 때문에 INSERT만 진행되는 테이블이다. 하지만, 테이블의 구조를 변경해야 한다면 어떻게 해야 할까?
기본적으로 MySQL의 DDL을 사용한다면 단일 스레드로 동작하기 때문에 시간이 오래 걸릴 것이다.
보통 이런 경우에는 새로운 테이블을 생성하고, 비교적 최근 데이터를 제외하고 PK로 범위를 나눈 레코드들에 대해 여러 개의 스레드로 복사하는 게 일반적이다.

INSERT INTO tb_new SELECT * FROM tb_origin WHERE id >= 0 AND id <= 10000;

그리고, 남은 데이터에 대해서는 양이 적기 때문에 테이블 구조 변경이 용이해지며, 비교적 서비스에 덜 영향을 미치게 된다.

# auto commit 모드 끄기
SET autocommit = 0;

# 대상 테이블에 대해서 쓰기 락 획득 (테이블 락)
LOCK TABLES tb_origin WRITE, tb_new WRITE;

# 남아있는 데이터를 복사해주기
SELECT MAX(id) AS @max_id FROM tb_new;
INSERT INTO tb_new SELECT * FROM tb_origin WHERE id > @max_id;
COMMIT;

# 복사 완료 시 rename 진행 (메타데이터 락)
RENAME TABLE tb_origin TO tb_origin_old, tb_new to tb_origin;

# 임시 테이블 삭제
DROP TABLE tb_origin_old

이렇게 되면 테이블 락의 경우 20000~20100번째 레코드를 복사할 때만 걸리기 때문에, 기존 데이터를 tb_new로 복사할 때 최대한 많은 데이터를 복사해둬야 락을 점유하는 시간이 짧아진다.

락 - innoDB 스토리지 엔진

innoDB에서는 MySQL에서 제공하는 락과는 별도로 락을 제공하고 있다.
기본적으로 information_schema 테이블의 INNODB_TRX, INNODB_LOCKS, INNODB_LOCK_WAITS 테이블에 있는 정보들을 바탕으로 어떤 트랜잭션이 락을 점유하고 대기 중인지 알 수 있으며, 여러 모니터링 방법들을 통해서 스토리지 엔진에서 제공하는 락까지 효율적으로 관리할 수 있도록 돕고 있다.

innoDB에서는 총 8가지의 락을 제공하고 있으며, 이는 다음과 같다.

- Shared / Exclusive Lock
- Intention Lock
- Record Lock
- Gap Lock
- Next-Key Lock
- Insert Intention Lock
- Auto-increment Lock
- Predicate Lock for Spatial Indexes

Shared / Exclusive Lock (공유 락, 베타 락)

공유 락(S-Lock)과 배타 락(X-Lock)이라는 레코드 레벨의 락이며, 공유 락의 경우 해당 락을 보유한 트랜잭션이 해당 레코드를 읽을 수 있도록 하고, 배타 락의 경우 해당 잠금을 보유한 트랜잭션이 행을 업데이트하거나 삭제할 수 있도록 만드는 것이다.

앞서 말했던 테이블 락의 READ / WRITE 모드와 거의 비슷하다고 생각하면 된다.
트랜잭션 A가 S-Lock을 가지고 있을 때 트랜잭션 B는 S-Lock을 보유할 수 있지만, 트랜잭션 A가 X-Lock을 가지고 있다면 어떤 락 요청이든 허용되지 않고 계속 대기해야 한다.

Intention Lock (의도 락)

의도 락(Intention Lock)의 경우 테이블 락과 레코드 락이 공존할 수 있도록 만든다.
테이블의 특정 레코드에 대해서 추후 락을 걸겠다고 표현하는 것과 같다.
만약 WRITE 모드의 테이블 락을 걸었다면, innoDB에서는 2가지의 타입으로 의도 락을 수행한다.

Intention Shared Lock (IS)
- 트랜잭션이 테이블의 개별 레코드에 공유 락 설정

Intention Exclusive Lock (IX)
- 트랜잭션이 테이블의 개별 레코드에 베타 락 설정

만약 SELECT ... LOCK IN SHARE MODE을 실행한다면 해당 테이블에 대해서 먼저 IS 이상의 락을 걸고, 그 다음 레코드에 대해서 S-Lock이 걸리며, SELECT ... FOR UPDATE의 경우 해당 테이블에 대해서 먼저 IX 이상의 락을 걸고, 그 다음에 레코드에 X-Lock이 걸린다. 왜 이렇게 2번 거는 것일까?
- 이는, 트랜잭션 A에서 이미 테이블에 대해 락을 걸어두었기 때문에 다른 트랜잭션에서 해당 테이블의 레코드에 접근하여 락을 걸지 못하도록 하기 위해서이다. 쓰기 작업 시 이미 IX 락이 걸려 있기 때문에 다른 테이블에서 멋대로 데이터를 변경할 수가 없게 되는 것이다.

아래는 락 종류에 따른 다른 트랜잭션 접근 시 호환성에 대한 표이다.

	S	IS	X	IX
S	호환 가능	호환 가능	충돌	충돌
IS	호환 가능	호환 가능	충돌	호환 가능
X	충돌	충돌	충돌	충돌
IX	충돌	호환 가능	충돌	호환 가능

기본적으로 표를 보면 IS의 경우 X, IX의 경우 S, X을 제외하고 여러 트랜잭션에서 동시에 사용이 가능하다.

Record Lock (레코드 락)

레코드 락의 경우 레코드에 대해서 잠금을 거는 것이다.
innoDB의 경우 레코드 자체를 잠그는 것보다는, 인덱스의 레코드를 잠근다. 하지만, 인덱스가 없더라도 클러스터링 키를 내부적으로 생성해줬던 것처럼, 여기서도 클러스터 인덱스를 알아서 생성해주기 때문에 해당 인덱스를 레코드 잠금에 사용한다.

# id = 1인 레코드에 대해 S-Lock
SELECT id FROM tb_1 WHERE id = 1 LOCK IN SHARE MODE;

# id = 1인 레코드에 대해 X-Lock
SELECT id FROM tb_1 WHERE id = 1 FOR UPDATE;

레코드가 아닌 인덱스의 레코드에 대해 락을 거는 이유는 아래와 같다.

- innoDB의 B+ Tree 인덱스를 통해 데이터를 저장하거나 검색하는데, 이때 인덱스의 레코드를 탐색하여 특정 레코드를 찾아내기 때문에 인덱스의 레코드에 대한 접근이 필요하다.

- 또한, 인덱스에 대해서만 락을 걸기 때문에 다른 트랜잭션들이 접근하는 경우에도 충돌을 최소화하여 성능 자체에도 도움을 줄 수 있다.

Gap Lock (갭 락)

갭 락의 경우 레코드가 아닌 레코드와 인접한 다른 레코드 사이의 간격을 잠그는 것을 의미한다. 이때, 첫 번째와 마지막 레코드 앞(Negative Infinity) 뒤(Positive Infinity)에 가상의 레코드가 있다고 가정하고 생성하는 것도 가능하다. 이러한 가상 레코드를 'Supremum' 가상 레코드라고 한다.

갭 락을 사용하게 되면, 조회 쿼리를 두 번 실행했을 때 다른 트랜잭션에서 수정이 발생하더라도 같은 결과가 리턴되도록 보장할 수 있다. 즉, Phantom Read를 방지하는 효과를 가진다. 이는 갭 락이 레코드 사이에 새로운 레코드가 삽입되는 것을 제어하는 것이기 때문이다.

select * from tb_1 where id between 1 and 10;

위와 같은 쿼리가 있을 때 1~10 사이에 X락이 걸리는 것과 동일하기 때문에, 새로운 데이터가 삽입되려면 대기해야 된다.

또한, 동일한 갭에 대해서 서로 다른 트랜잭션에서 충돌하는 락을 가질 수도 있다. 즉, 트랜잭션 A가 Gap S-Lock을 가지고 있고, 트랜잭션 B가 동일한 갭에 대해서 Gap X-Lock을 가질 수 있다. 이는 특정 레코드가 제거되었을 때 서로 다른 트랜잭션에서 해당 레코드에 가지고 있던 갭 락을 병합해야 하기 때문에 충돌이 허용하는 것이다.

Where 절을 통해 데이터를 조회한 결과가 하나일 때, Record vs Gap 중 어떤 락이 사용될까?
- 기본적으로 컬럼에 unique index가 걸려 있다면 record lock이 사용된다.
- 인덱스가 없거나, unique 하지 않은 index라면 gap lock을 사용해야 한다.
: 인덱스가 있다면 쿼리 결과를 조회하기 위해 스캔한 인덱스 범위에 대해 gap lock이 적용되고, 인덱스가 없다면 테이블 전체를 스캔해야 하기 때문에 모든 레코드에 대해서 락이 걸린다.

Next-Key Lock (넥스트 키 락)

레코드 락과 갭 락을 합친 형태를 넥스트 키 락이라고 한다.
innoDB에서는 테이블 인덱스를 검색하거나 스캔할 때 실제 인덱스 레코드에 대해 S / X-Lock을 설정하여 레코드 단위 락을 걸게 된다. 하지만, 넥스트 키 락의 경우 해당 인덱스 레코드 이전의 갭에도 영향을 미치기 때문에 하나의 세션이 특정 레코드 1번에 S / X-Lock을 걸면 다른 세션은 1번 바로 앞의 갭에 새로운 레코드를 생성할 수 없게 된다.

예를 들어, 10, 11, 13, 20에 인덱스가 걸려 있다면 아래와 같은 구간에서 락이 생성된다.
- (Negative infinity, 10]
- (10, 11]
- (11, 13]
- (13, 20]
- (20, Positive infinity)

잘 이해가 되지 않을 수도 있으니, 예시를 들어보자. 아래는 crew 테이블에 대해 id가 100 이상인 레코드를 조회하는 쿼리이다.

SELECT * FROM crew WHERE id > 100 FOR UPDATE;

이때, id > 100을 만족하는 id = 101인 리코드를 발견하면, 해당 레코드 직전의 레코드와 그 사이 락이 걸린다. (50 ~ 101 사이 갭 락)
이후, id > 100을 만족하는 레코드에 대해서도 갭 락과 레코드 락이 걸리게 되며, 이때 id = 150이 최대이기 때문에 Positive Infinity Gap Lock이 걸리게 된다.

넥스트 키 락의 경우 바이너리 로그가 기록되는 쿼리가 레플리카 서버에서 실행될 때, 기존 서버에서 만들어낸 결과와 동일한 결과를 만들어내도록 보장하는 것이 주 목적이다. 로그 포맷의 경우 statement, row, mixed로 나누어지는데, 아래와 같은 특징을 가진다.

- statement: 가장 오래된 포맷, 데이터 변경으로부터 사용되는 모든 쿼리를 저장
- row : 변경된 모든 레코드에 대한 정보 기록
- mixed: statement + row를 혼합하여 사용하는 방법

기존에는 statement 포맷의 바이너리 로그를 사용하는 것이 보편적이었으나, 이 경우 repeatable-read 이상의 격리 수준을 사용해야 한다는 점과 (read-committed 사용 시 실행 시점마다 결과가 달라질 수 있어서) 쿼리의 실행마다 결과가 달라지는 경우 (사용자 정의 함수, 프로시저 사용 등) 해당 쿼리는 사용할 수 없었다는 단점이 있었다. 또한, 넥스트 키 락과 갭 락으로 인해 데드락이 발생할 수 있으니 바이너리 로그 포맷을 ROW 형태로 바꿔서 락 자체를 줄이는 것이 좋다. (MySQL 8.0부터는 ROW 포맷의 바이너리 로그가 기본이다.)

Insert Intention Lock (삽입 의도 락)

삽입 의도 락은 INSERT 구문이 실행될 때 묵시적으로 설정되는 일종의 갭 락이다.
여러 개의 트랜잭션이 갭 내부의 서로 다른 위치에 삽입을 진행하려고 할 때 대기 없이 실행되도록 하는 것이 목적이다. 기본적으로 삽입 의도 락들끼리는 충돌이 발생하지 않기 때문이다.

만약 id = 3, 7인 레코드가 있을 때 트랜잭션 A는 id = 5를, 트랜잭션 B는 id = 4을 삽입하는 상황을 가정해보자.

기본적인 갭 락을 걸었다면 트랜잭션 A가 5를 삽입하는 과정에서 이전 레코드인 3 ~ 5 사이에 갭 락이 걸릴 것이다. 이때, 트랜잭션 B가 id = 4을 삽입하려고 했을 때 이미 3~5 사이에 갭락이 걸려 있기 때문에 종료될 때까지 기다려야 해서 대기 시간이 존재한다.

반면에, 삽입 의도 락을 걸었다면 트랜잭션 A가 5를 삽입하는 과정에서 3 ~ 5 사이에 삽입 의도 락이 걸린다. 이때, 트랜잭션 B가 id = 4를 삽입하려고 할 때 삽입 의도 락은 충돌이 가능하기 때문에 대기 시간 없이 바로 삽입이 가능해진다.

삽입을 위한 X-Lock을 얻기 위해 삽입 의도 락을 통해서 묵시적으로 락을 걸어두게 된다.

Auto-increment Lock (자동 증가 락)

MySQL에서는 auto_increment라는 컬럼을 통해서 자동으로 증가하는 값을 관리할 수 있다.
auto_increment가 사용된 테이블에 여러 개의 레코드가 삽입되는 경우, auto_increment 역시 일관성있게 증가해야 한다. 이를 위해서 innoDB에서는 자동 증가 락을 통해 (테이블 레벨 락) 관리한다.

자동 증가 락의 경우 기본적으로 insert, replace 같이 새로운 레코드를 삽입하는 쿼리에서만 필요하며, auto_increment 값을 가져오는 순간에만 락이 걸렸다가 즉시 해제된다. 테이블당 단 1개만 존재하기 때문에, 2개의 insert문이 동시에 실행되는 경우 나머지 하나는 락이 해제될 때까지 기다려야 한다.

명시적으로 자동 증가 락은 획득하고 해제하는 방법은 없지만, 어차피 엄청 짧은 시간 동안 걸렸다가 해제하기 때문에 크게 영향은 없다. MySQL 5.1부터는 어떤 식으로 자동 증가 락을 설정할지 시스템 변수로 관리도 가능하다.

- innodb_autoinc_lock_mode = 0
모든 INSERT 문장은 자동 증가 락을 사용한다. 이때, 테이블 수준의 락을 적용한다.

- innodb_autoinc_lock_mode = 1 (MySQL 5.x 기본 값)
Bulk Inert 사용 시 테이블 레벨의 자동 증가 락을 사용하고, 명령문이 끝날 때까지 이를 유지하게 된다.
INSERT ... SELECT, REPLACE ... SELECT, LOAD DATA 같은 구문에서 사용한다.
하지만, 만약 삽입될 레코드의 수를 미리 알고 있다면, 래치 (뮤텍스) 제어 하에 필요한 수만큼의 자동 증가 값을 얻어서 수행되며, 테이블 레벨의 잠금을 방지한다.

레코드 건수를 정확하게 알 수 없는 경우에는 모든 자동 증가 값이 연속적인 값이 되기 때문에 안전하게 사용이 가능하다.
그러나, Mixed-mode insert의 경우 삽입할 행의 수보다 더 큰 자동 증가 값을 할당될 수 있음을 유의해야 한다.
ex) insert into tb_1 values (1, 'A'), (NULL, 'B')
- 이런 식으로 null 값이 혼합하여 들어가는 경우.

- innodb_autoinc_lock_mode = 2 (MySQL 8.0 기본값)
자동 증가 락을 절대 사용하지 않고 무조건 래치(뮤텍스)를 사용한다. auto_increment 값의 유니크성 / 단조 증가성을 보장한다.
대량의 삽입 쿼리가 실행될 때 다른 트랜잭션에서도 INSERT를 수행할 수 있기 때문에 동시 처리 성능은 높아진다. (여러 명령문이 동시에 숫자를 생성할 수 있음) 하지만, 단건 삽입의 경우 auto_increment 값 사이의 갭이 존재하지 않지만 여러 개가 삽입될 경우 갭이 존재할 수 있다.

이러한 자동 증가 락으로 인해 auto_increment의 값은 기본적으로 한 번 증가하면 절대 줄어들지 않는 것을 기본으로 한다.

Predicate Locks for Spatial Indexes의 경우 공간 인덱싱을 지원한다고 하는데, 이해하기 어려워서 우선 패스...!
내용이 어려워서 알듯말듯한 것 같다.

다음 포스팅에서는 인덱스와 락의 관계 + 격리 수준에 대해서 알아보도록 하자!

[Network] 서버의 패킷 수신 동작 알아보기

dolmeng2 — Sat, 17 Jun 2023 01:03:09 +0900

들어가기 전

드디어 기나긴 패킷 여행의 마지막이다.

이번 포스팅에서는 웹 서버측에서 어떤 식으로 패킷을 받아오는지 알아볼 것이다!

클라이언트에서 패킷을 전송하는 단계를 반대로 뒤집은 것과 동일하기 때문에 크게 어렵지 않을 것이다.

클라이언트가 보낸 패킷이 서버로 도착한 직후

다시 돌아와서, 클라이언트에서 보낸 패킷이 서버로 도착한 직후 어떤 일이 발생하는지 간단하게만 알아보자.

(이 부분은 크게 중요한 건 아니라서 간단하게 짚고 넘어가고자 한다.)

우선, 서버 측으로 들어온 패킷의 경우 사실 '전기 신호'의 형태로 들어온다.

전기 신호는 LAN 어댑터에서 수신되며, 여기서 1과 0의 디지털 데이터로 바뀌게 된다.

위 그림은 전기 신호에서 디지털 데이터로 변환되었을 때 패킷의 형태이다.

변경된 디지털 데이터에서 패킷의 가장 마지막단에 있는 FCS (Frame Check Sequence, 오류 검사용 데이터)를 통해 오류의 유무를 검사하게 되고, 데이터가 무결하다면 맨 앞에 있는 MAC 헤더에 있는 수신처의 MAC 주소를 확인해서 본인에게 온 데이터인지 체크한다.

이는, 전기 신호가 LAN 전체로 흘러가고 해당하는 것만 신호를 수신하기 때문에 다른 기기로 가야 하는 패킷이 들어올 수도 있기 때문이다.

이후 LAN 어댑터 내부의 버퍼에 저장해두고, 인터럽트를 통해서 CPU에게 패킷이 도착했음을 알린다.

그럼 CPU는 하던 작업을 중단하고 LAN 드라이버를 통해 LAN 어댑터의 버퍼 메모리에서 수신한 패킷을 추출하고, MAC 헤더의 타입 필드를 통해 프로토콜을 판별하고, 해당 프로토콜을 처리할 수 있는 소프트웨어를 호출한다.

보통 해당 타입 필드 값은 IP 프로토콜을 나타내는 값이기 때문에 TCP / IP의 프로토콜 스택을 호출 후 패킷을 건네준다.

프로토콜 스택과 IP 담당 부분

프로토콜 스택까지 패킷이 오게 되면 IP 담당 부분이 IP 헤더를 점검한다.

MAC 헤더와 마찬가지로 IP 헤더에서 수신처 IP 주소를 통해 본인에게 보내는 패킷인지 체크한다.

이는 OS 내부에서 패킷 중계 시 예상치 못하게 다른 패킷이 들어올 수도 있기 때문이다.

이후, 패킷이 잘 분할되었는지 체크하고 (IP 헤더의 플래그 값을 통해 확인) 분할된 패킷이 모두 도착할 때까지 메모리에 저장한다.

전부 도착하게 되면 재조립하여 원래의 패킷으로 복원을 하고, 프로토콜 번호 항목에 따라서 TCP or UDP or ICMP 담당 부분에게 패킷을 건네준다.

서버에서 소켓을 받는 과정 - 소켓 메서드로 분석하기

보통 서버와 클라이언트는 1:1로 접속하여 대화하는 것이 일반적이다. 보통 멀티스레드를 통해서 작동하게 되기 때문에, 클라이언트의 접속을 대기할 때 새로운 스레드를 생성하고 접속 시 새로 생성한 소켓을 건네주게 된다. 보통 운영체제의 커널 내부에 소켓을 관리하는 정보가 담겨있기 때문에, 해당 정보를 바탕으로 클라이언트에게 소켓 정보가 분배된다.

이전에 프로토콜 스택과 메시지 송신 과정에 관한 포스팅에서 클라이언트의 데이터 송-수신 과정을 다음과 같이 정의하였다.

1. 소켓 작성
2. 서버의 소켓과 파이프로 연결 (접속)
3. 데이터 송-수신
4. 파이프 분리 후 소켓 말소 (연결 끊기)

하지만, 서버의 입장에서는 조금 다르다.

1. 소켓 작성
2-1. 소켓을 접속 대기 상태로 만들기
2-2. 소켓 접속에 대해 접수
3. 데이터 송-수신
4. 파이프 분리 후 소켓 말소

구체적인 코드상으로 어떻게 동작하는지 살펴보자.

클라이언트의 소켓 연결 프로세스와 비슷하지만, 추가적으로 bind, listen, accept 같은 코드가 생긴 것을 볼 수 있다.

1. bind : 소켓에 주소를 할당하기

int bind(int sockfd, struct sockaddr *addr, socklen_t addrlen);

bind 메서드의 경우 총 3개의 인자를 받는다.

첫 번째 인자의 경우 socket()을 통해 받아오는 디스크립터이며, 두 번째 인자의 경우 IP 주소와 포트 번호를 담고 있는 구조체이다.

세 번째 인자의 경우 주소 정보를 담은 변수의 길이이며, 바인딩이 성공하면 0을, 실패하면 -1을 반환한다.

2. listen: 연결 요청을 대기하기

int listen(int sock, int backlog);

bind 메서드를 통해서 하나의 소켓에 ip 주소와 포트 번호를 할당했다.

이제, 클라이언트가 해당 소켓에 연결할 수 있도록 해당 요청을 대기하는 상태로 만들어줘야 한다.

listen이 호출된 이후부터 클라이언트는 connect를 통해서 서버로 연결을 요청할 수 있게 된다.

첫 번째 인자는 소켓 디스크립터의 번호를, 두 번째 인자는 연결 요청을 대기하고 있는 큐의 크기이다.

여기서 말하는 큐는, 클라이언트가 연결을 요청했을 때 요청이 온 순서대로 처리할 수 있도록 클라이언트를 큐에 담아두고 모아둔 곳이다.

3. accept: 연결 요청 수락하기

int accept(int sock, struct sockaddr*addr, socklen_t *addrlen);

대기 중인 클라이언트의 요청을 차례대로 수락할 수 있다.

첫 번째 인자는 기존의 디스크립터 번호, 두 번째 인자는 대기 큐에서 얻어온 클라이언트의 주소 정보, 세 번째 인자는 addr 변수의 크기를 의미한다. 만약, 대기 큐가 비어있다면 accept은 반환되지 않고 새로운 요청이 올 때까지 blocking 상태가 된다.

여기서 accept은 기존의 디스크립터가 아닌, 새로운 디스크립터를 (디스크립터 2) 반환한다.

앞에서 사용했던 디스크립터는 연결 요청에 대한 대기까지만 진행하고, accept을 통해 새롭게 할당받은 디스크립터를 통해 실제 클라이언트와 데이터 송-수신 과정을 진행할 수 있음을 의미한다.

기존에 사용했던 디스크립터의 경우 계속 접속 대기인 상태로 존재하게 된다. 만약, 새롭게 할당받은 디스크립터 대신 기존의 디스크립터를 사용하게 된다면 접속 대기 소켓이 사라지게 되어서 다음에 다른 클라이언트가 접속하게 된다면 이미 소켓이 연결된 상태니까 해당 요청을 처리할 수 없게 되어 곤란해진다. 그래서, 클라이언트의 요청이 올 때마다 새로운 소켓을 생성하여 해당 클라이언트의 통신과를 담당하도록 만든다고 이해하면 된다.

하지만, 새로운 소켓을 만들 때 포트 번호는 그대로 유지한다. 이는 접속 패킷을 보냈을 때 다른 포트 번호에서 답변이 돌아오는 일을 막기 위해서이다. 만약 다른 포트 번호로부터 답이 온다면, 접속 패킷을 보낸 상대로부터 온 것인지, 아니면 다른 상대로부터 온 것인지 알 수가 없기 때문이다.

근데 포트 번호를 그대로 유지하게 된다면 하나의 포트 번호에 여러 개의 소켓이 존재할 수도 있는 것이다. (접속 대기 용도 / 데이터 송-수신 용도) 클라이언트에서 패킷이 도착했을 때 단순히 포트 번호로 어떤 소켓이랑 대화하고 있는지 알 수 없기 때문에, 추가적으로 아래와 같은 정보들을 통해 소켓을 식별한다.

- 클라이언트의 IP 주소
- 클라이언트의 포트 번호
- 서버측의 IP 주소
- 서버측의 포트 번호

이 덕분에 서버측에 같은 포트 번호를 가진 소켓이 여러 개이더라도, 클라이언트 측은 모두 다른 포트 번호를 할당하기 때문에 각 소켓들이 충분히 식별된다. 하지만, 클라이언트와 서버의 포트 번호만 가지고 식별은 불가능하다. 왜냐하면, 여러 클라이언트가 접속하게 된다면 클라이언트의 포트 번호 역시 중복될 수 있기 때문이다. 그래서 추가적으로 클라이언트의 IP 주소까지 합하여 완전하게 소켓을 식별하게 된다!

그렇다면, 굳이 소켓 디스크립터라는 것을 사용할 필요가 있을까?

이는, 소켓을 만든 직후 접속 동작을 하기 전에는 클라이언트의 IP, 포트 번호를 알 수 없기 때문이다.

또한 4가지 정보보다는 디스크립터 하나로 식별하는 게 더 간단하고 (메모리 공간도 적게 차지하니까 성능 개선 가능), 표준 인터페이스인 만큼 프로그램과 OS 사이의 원활한 통신을 지원하게 된다.

서버에서 소켓을 받는 과정 - TCP 헤더의 관점에서 분석하기

바로 앞서 말한 내용과 비슷하지만, TCP 헤더가 하는 일을 위주로 되새겨보자.

소켓 접속 동작

기본적으로 TCP 헤더의 SYN 컨트롤 비트가 1로 패킷이 들어왔다면, 해당 패킷은 접속 동작의 패킷이 된다.

해당 패킷이 들어오면 패킷의 수신처 포트 번호를 조사하여 해당 번호와 같은 포트 번호를 할당한 접속 대기 상태의 소켓이 있는지 확인한다. 이 과정에서 존재하는 패킷이 없다면, 오류 통지 패킷을 반송한다.

해당하는 접속 대기 패킷이 있다면 복사하여 새로운 소켓을 만들고 (위에서 봤던 디스크립터2에 대한 부분) 송신처의 IP 주소, 포트 번호, 시퀀스 번호의 초기값, 윈도우 값 등의 정보를 기록한다. 또한, 송-수신 버퍼로 사용하는 메모리 영역을 확보한 다음, ACK 번호, 서버에서 클라이언트에 보내는 데이터에 대한 시퀀스 번호의 초기값, 클라이언트에서 서버로 보낸 데이터를 받기 위해 수신 버퍼의 빈 용량을 나타내는 윈도우 값 등을 기록한 TCP 헤더를 만들어서 IP 담당 부분에게 의뢰하여 클라이언트에게 반송한다.

결과적으로 해당 패킷이 클라이언트에게 도착하면, 클라이언트는 패킷을 받았다는 ACK를 보낼 것이구, 해당 패킷을 받게 되면 소켓의 접속 동작이 완료된다. accept을 통해 쉬고 있던 서버는 새로 만든 소켓의 디스크립터를 전달하여 다시 동작을 재개하게 된다.

1. TCP 헤더의 SYN 컨트롤 비트 확인
2. 수신처 포트 번호 조사
3. 해당 포트 번호와 동일한 번호를 가진 접속 대기 소켓 복사 후 새 소켓 생성
4. 송신처의 IP / 포트 번호 등 기록

데이터 송-수신 동작

접속이 완료되면 데이터 송-수신 단계를 들어갈 텐데, 먼저 도착한 패킷이 어느 소켓에 해당하는지 조사한다.

새로운 소켓이 복사되면서 동일한 포트 번호를 가진 소켓이 여러 개가 될 수 있기 때문에 송-수신처의 IP, 포트 번호 모두를 조합하여 소켓을 찾는다. 이후, 소켓에 기록된 시퀀스 번호나 이전에 온 데이터 조각의 길이로부터 다음 시퀀스 번호 값을 계산하여, TCP 헤더에 기록된 시퀀스 번호와 일치하는지 확인하여 도중에 유실된 패킷이 없는지 확인한다.

이때, 분할된 패킷을 원래로 복원하기 위해서 새로운 패킷이 도착할 때마다 데이터 조각들을 연결한다.

수신한 데이터를 수신 버퍼에 저장하면 응답용 TCP 헤더에 수신 패킷의 시퀀스 번호와 데이터 조각으로부터 계산한 ACK 번호를 기록한 뒤, IP 담당 부분에게 의뢰하여 클라이언트에게 다시 반송한다. 이후 애플리케이션의 필요에 따라서 버퍼에 저장된 데이터를 건네주게 된다.

1. 도착한 패킷의 송-수신처 IP / 포트 번호를 통해 소켓 식별
2. 데이터 조각들을 연결하여 수신 버퍼에 보관
3. 클라이언트에게 ACK 되돌려줌

접속 끊기 동작

클라이언트든 서버든 close 호출하고, FIN=1을 IP 담당 부분에게 의뢰한다.

이를 받은 수신측은 ACK 번호를 반송하고, 또 다시 FIN=1을 보내고, 다시 ACK를 보내고 연결이 끊긴다.

이후 연결이 끊기면 잠시 후 소켓이 말소하게 된다!

흔히 생각하는 4-way handshake 과정이기 때문에 자세한 내용은 생략하겠다.

이 포스팅에서 연결 끊기 동작에 대한 그림을 그려두었다

이렇게 대략적인 클라이언트 <-> 서버 간의 통신 과정을 알아보았다.

사실 중간중간 생략한 내용도 있고, 특히 리퀘스트 메시지 해석하는 부분은 책 한 권으로 쓰일 수 있을 만큼 내용이 많아서 따로 정리하지는 않았다. 정말 간단하게 줄인다면, 다음과 같다.

1. 리퀘스트 메시지를 파싱하여 액세스 제어에 따른 검증 절차 진행
2. 리퀘스트 메시지 처리
3. 응답 메시지 생성 후 클라이언트로 반송 (클라이언트가 받을 때는 다수의 패킷으로 받음)
4. 클라이언트를 이를 받아 전기 신호 -> 디지털 데이터 -> 분할된 패킷 모으기 -> 메시지로 변환 -> 브라우저에게 전송
5. 브라우저는 Content-Type 같은 헤더 값에 따라서 어떤 식으로 렌더링할지 정함

아무튼 끝!

나중에 한 번 더 공부해봐야겠다... 지금은 머리에 남은 게 없다

[우테코 5기] 레벨 2 레벨 인터뷰 정리 및 감정 회고

dolmeng2 — Fri, 16 Jun 2023 15:18:51 +0900

✔️ 레벨 로그

레벨 2 방학 시작한 지 조금 됐지만... ㅎㅎ 뒤늦게 회고를 작성해보고자 한다.

지난 레벨 1 인터뷰 때에 비해서 레벨 2의 인터뷰는 더 많은 인원이 진행했다. (하지만 임팩트룸에서 하다 보니 엄청 복작복작한 느낌이었당)

함께한 크루들은 성하, 박스터, 루카, 깃짱, 헙크, 이오, 두둠이고, 코치님은 브리였다.

저번에는 2일차에 인터뷰였어서 준비할 시간이 넉넉했는데, 이번에는 1일차에 걸린 바람에 준비할 시간도 별로 없었다 ㅎㅎㅎ

레벨 로그 / 레벨 인터뷰

직렬화와 역직렬화

www.notion.so

노션에 레벨 인터뷰를 준비하며 열심히 정리했었다.

레벨 2에서 배운 게 워낙 중구난방해서 그런가... 최대한 스프링에 대한 것만 공부하고 갔다.

블로그에 한 번 더 올리는 것보다는 노션이 더 깔끔할 것 같아서 링크만 첨부해야겠다

✔️ 레벨 인터뷰 후기

이번 인터뷰는 위와 같은 배치로 진행했었는데, 저 자리에 앉으면 굉장히 떨린다... ㅎ

8명이 나를 바라보고 있는 상황 + 인터뷰어의 눈을 마주치려고 하다 보니까 딱 앉았을 때 굉장히 떨렸다.

심지어 우리 팀의 가장 마지막 순서였어서 점심 먹을 때도 멍하니 먹었던 것 같다. ㅎㅎㅎ

체크인 점수 ;ㅅ;

인터뷰어로 느낀 점

레벨 1의 인터뷰와 다르게 이번에는 상대의 레벨 로그를 보지 못한 상태로 질문을 하다 보니, 최대한 인터뷰이가 대답한 내용에 대해서 꼬리질문을 하는 식으로 들어갔다. 또한, 질문할 때 최대한 인터뷰이의 눈을 마주치려고 노력했다. (물론 대답을 들을 때도 ㅎㅎ)

회의실에서 하다 보니 공간이 좁아서 그런가, 거의 아이컨택 수준으로 눈을 마주쳤지만... 상대가 대답할 때 고개도 끄덕이고, 최대한 리액션을 해주는 게 인터뷰이의 긴장도 풀어줄 수 있는 포인트가 된다고 생각했다.

무엇보다 인터뷰 해주신 분들이 열심히 준비한 게 티가 나서 그런가... 대답을 잘해주시는 거 보면 내가 더 뿌듯했다. ㅋㅋㅋㅋ

특히 질문의 의도 그대로 대답해주실 때마다 기분도 좋았다.

또한, 코치님이 중간중간 인터뷰이에게 질문할 때 나도 속으로 '저 질문을 받았다면 뭐라고 대답할까...'라는 생각을 많이 했었는데, 그럴 때마다 인터뷰이들이 대답했던 내용을 바탕으로 나의 개념을 다시 한 번 정리할 수 있던 시간이 되었다.

다시 한 번 느낀 거지만, 인터뷰는 인터뷰이가 최대한 말을 많이 말할 수 있도록 이끌어나가는 시간이지, 공격하는 시간이 아니라는 것을 깨달을 수 있었다.

옵저버로 느낀 점

오전의 3타임 연속으로 옵저버를 하다 보니 집중력에도 살짝 한계가 왔었지만... 중간중간 대답하는 센스가 좋은 인터뷰들의 매너를 많이 배웠다. 특히 개발자에게는 단순 지식보다는 소프트 스킬이 중요하다는 걸 다시 한 번 깨닫게 되는 순간이었다.

아, 중간에 자기소개를 해주셨던 크루도 있었는데 나중에 면접 보면 자기소개도 잘 준비해야겠다는 생각이 들었다. 자기소개가 별거 아닌 것 같아도, 듣는 사람의 입장에서는 굉장히 환기가 되는 멘트라는 게 느껴졌다.

그리고, 잘 모르는 주제가 나오더라도 최대한 자신이 대답할 수 있는 수준까지 인터뷰어에게 유도하는 게 중요하다는 것을 느꼈다...

정말 면접을 잘하는 크루들이 많다는 걸 다시 한 번 느꼈다.

인터뷰이로 느낀 점

앞서 말했던 것처럼 나는 가장 마지막 순서였다.

후반부로 갈수록 덜 떨릴 줄 알았는데, 마지막이라고 생각하니까 너무 떨렸다... ㅎㅎㅎ

이번 인터뷰를 하면서 꼭 지키고 싶었던 점은 목소리의 크기이다. 저번 인터뷰 때 피드백을 많이 받았던 부분이기 때문이다.

그리고, 원래 대화할 때 사람의 눈을 잘 안 보는데, 인터뷰 때는 최대한 인터뷰어를 쳐다보려고 노력했다.

덕분에 엄청 똘망똘망하게 쳐다본다는 피드백을 받았다. ㅋㅋㅋㅋ 좋다.

사실 질문의 경우 내가 거의 알고 있는 내용으로 나왔어서, 대답하는 것에는 어려움이 없었다.

특히 브리가 화이트보드에 작동 원리 같은 거 써보라고 시키실까봐 엄청 걱정했는데... 다행히도 배포 쪽을 말씀해주셨어서 금방 대답할 수 있었다. 마지막에 프로젝트 경험이 많은 게 보인다고 말씀해주셔서 뿌듯했다. (생각해보면 1개밖에 없는데... ) 앞으로도 이렇게만 공부하라고 말씀해 주셔서 너무... 좋았다 내가 잘못된 건 아니었구나...

아, 그리고 처음 질문 중에서 '이번 레벨 2 학습에서 목표가 뭐였냐'라는 게 있었는데, 나는 이전에 스프링을 공부한 적이 있어서 스프링 사용법보다는 객체지향적으로 코드를 작성하는 방법이나 CI / CD, 인증 / 인가 쪽을 더 공부했다고 말했다.

= 스프링 동작 원리 같은 거 물어보지 말아 주세요... 라는 느낌 ^_^

이 덕분에 스프링 관련해서 거의 안 물어보신 건가 싶기도 하다. ㅋㅋㅋㅋㅋ

다만 아쉬운 건 '최대한 이해하기 쉽게 설명하자!'라는 생각 때문에 처음부터 설명하려고 하다 보니, 인터뷰어의 질문 자체를 까먹어서 다시 되물었던 적이 있었다. 이거는 나의 불찰이었다. 두괄식으로 먼저 주제를 내 머릿속에 각인시키고 말을 했어야 했는데, 대답이 길어지면서 나까지 길을 잃어버리니 인터뷰가 지루하다고 느껴질만 했다 앞으로 고쳐나가야 할 방향이다.

아래는 레벨 인터뷰에 대한 피드백이다. 거의 좋은 피드백을 남겨 주셨다...!

이번 레벨 학습 측면에서 좋은 점과 부족한 점은?

- 처음에 자신있게 말한 것처럼, 학습에 대한 깊이가 깊은 것이 느껴졌다. 이미 많이 공부를 한 상황이라, 이번 레벨에 대한 학습에서는 이미 충분해서 별로 부족한 부분이 느껴지지 않았다. 인증 방식에 대해서도 자신만의 생각을 명확히 가지고 있었다. 에러 상황에 대한 대처도 당황하지 않고 잘 설명하는 것이 멋졌다.

- 처음에 자신있게 말한 것처럼, 학습에 대한 깊이가 깊은 것이 느껴졌다. 이미 많이 공부를 한 상황이라, 이번 레벨에 대한 학습에서는 이미 충분해서 별로 부족한 부분이 느껴지지 않았다. 인증 방식에 대해서도 자신만의 생각을 명확히 가지고 있었다. 에러 상황에 대한 대처도 당황하지 않고 잘 설명하는 것이 멋졌다.

- 본인이 어떤 부분을 고민해야 할 지 확실히 생각해보고 공부한 것으로 느껴졌다.

학습 측면에서 딱히 개선할 부분을 적어 주시지 않아서... 좋았다! 앞으로 더 열심히 공부해야겠다 ;ㅅ;

인터뷰, 말하기 측면에서 좋은 점과 개선할 부분은?

[좋은 점]
- 처음에 자신이 '스프링은 이미 알고 있어서, 객체지향에 대한 부분을 고민했다'라고 확실한 컨셉을 밝혀서, 자신이 잘 아는 쪽으로 질문을 이끈 것 같다. 질문자를 똘망똘망 잘 쳐다보는 모습이 보기 좋다.
- 아이 컨택도 좋고, 어조도 좋은 것 같다.
- 어조가 자연스럽고 목소리에 힘이 있다.
- 겪어보지 못한 문제에 대해서도 어떻게 할 것인지 고민해보고 대답하는 모습이 좋았음.
- 이해하지 못한 질문은 다시 한번 확실히 물어본 후에 답하는 모습이 신뢰감있게 느껴진다.

[개선할 부분]
- 너무 완벽하게 설명하려고 배경을 설명하다가 답변을 잊어버린다. 식별자로 id를 사용한다고 먼저 말하고 그렇게 생각한 근거를 뒤에 이야기하는 것이 더 좋을 것 같다.
- 개인적으로 손동작이 추가되어도 더 좋다고 생각한다.
- 몸이 계속 흔들린다. 제스처를 책상 밑에서 해서인것 같은데, 확실하게 책상 위로 보이게 하는 편이 더 좋을 것 같다.

이번에는 목소리 관련 피드백이 없다는 게 뿌듯했다! 목표 완료.

다만 의자에 비해 책상이 높다 보니까 (나만 그렇게 느꼈나...?) 제스처를 얼떨결에 책상 밑에서 많이 했었는데, 그러다 보니 자꾸 몸이 흔들린다는 피드백을 받았다. ㅋㅋㅋㅋㅋㅋ 말할 때는 의식을 못했었는데, 보는 사람 입장에서는 인형마냥 몸이 계속 움직이는 게 너무 웃기다고 했다. 앞으로는 주의해야겠다... ^^ ㅎㅎ

그리고 두괄식 표현도 꼭 지켜야겠다. 이건 말하기 스킬이 부족해서 그랬던 것 같은데, 앞으로 잘 늘려나갸야겠다...

정말 뿌듯하게 마무리한 인터뷰... 끝나자마자 크루들이랑 얘기 좀 하구, 집 가서 기획서 만들면서 쉬었다 ✌

다들 기획서 보자마자 '정말 귀여운 거 좋아하시네요...'라는 말을 많이 했다.

사실 기획서도 크게 고민하고 낸 게 아니라 뽑힐 줄 몰랐는데... 열심히 준비했다고 말씀해주셔서 뿌듯했다.

나... 미대 가야 했을지도?

✔️ 감정 회고

레벨 2 기간이 벌써 끝났다. 시간이 너무 빠르게 가서 당황스러울 정도다.

음... 돌아봤을 때 레벨 2 기간 동안 꽤 많이 지쳤던 것 같다. 오히려 레벨 1 보다 덜 열심히 했던 것 같은데 왜 그렇게 지쳤던 걸까... 잘 모르겠다. 근데 이런 감정을 나만 느낀 게 아니라 다른 크루분들도 요즘 하기 싫다는 말을 정말 많이 하셨다.

나만 힘든 게 아니었다는 생각이 들어서 조금은 안심이 되었다.

원래 레벨 2가 많이 지치는 기간이라고 하니까, 나도 좀 지쳤던 거겠지...?

그래서 이번 방학이 정말 마음이 편했다. 방학하고 푹 쉬고 있기 때문이다

레벨 2가 들어가기 전에 위와 같이 목표를 세웠었다. 나는 잘 지켰던 걸까?

객체지향적인 설계에 대해서 계속 고민했던 시간들이 떠오르는 거 보니, 헛되게 보낸 것 같지는 않다.

그리고 목표 중에 블로그 글 작성하기도 있었다.

마지막 미션 회고 글 빼고는 거의 밀리지 않고 작성했다. 앞으로도 이렇게 해야겠다.

또... 글도 많이 썼다. 딱 20개 정도 쓴 것 같다.

나는 내가 공부한 걸 public한 공간에 글을 작성하는 게 좋다.

다른 사람이 본다고 생각하니까 더 열심히 정리하기도 하고, 크루들이 글 잘 보고 있다고, 도움된다고 말해줄 때마다 엄청 뿌듯하기 때문이다. 레벨 1 때는 노션을 많이 썼었는데, 레벨 2 와서는 거의 안 썼다. 나만 보는 공간이라고 생각하니 열심히 안 쓰게 되고, 미루게 되는 게 크기 때문이다. 우테코 수료 쯤에는 글 200개 채우는 게 목표인데, 가능할까? ㅎㅎㅎ (이제 100개 씀) 모르겠다.

글 쓸 때 최대한 가득가득 내용을 담아서 쓰려고 하는데, 오히려 가독성이 떨어진다는 말도 들었어서 (너무 길어서 읽기 싫다는....?) 요건 좀 고민이다. 앞으로 좀 더 고민해봐야겠다.

소중한 데일리조 롤링 페이퍼 추억하고 싶어서 몰래 캡쳐해두었다. (익명이니까 아무도 모르겠지...?)

데일리조에서 나는 게임을 잘하는 이미지가 되어버렸다. + 소식...? 내가 왜 소식좌가 되었을까?...

우테코 하면서 나도 모르는 내 이미지가 만들어지는 것 같아서 신기하다. ㅋㅋㅋㅋ 게임 잘한다는 말 들어본 적 없었던 것 같은데 신기해

(tmi: 나는 게임하는 걸 그렇게 좋아하지 않는다. 그냥 심심하니까 하는 것일뿐...?)

뭔가 내가 생각하는 나와 다른 사람이 보는 나는 정말 다르다는 걸 느끼게 되는 것 같다.

좋게 봐주신다면야 너무 좋다 ~_~

이제! 남은 방학 기간도 잘 쉬어보려고 한다.

다만 코드를 안 쓰니 할 것도 없고 심심해서 고민 중이다... mysql 공부 좀 하고...

뭔가 개발하고 싶은데 방학이 너무 적게 남아서 고민이 되는 느낌...? 해커톤이라도 나갈걸 너무 심심하다 ㅠ...

프로젝트 잘 할 수 있을지도 걱정이다. 잘하고 싶은데... 잘하는 사람들이 너무 많다... ㅎㅎ ㅠ

JPA나 좀 공부할까 고민 중이다. 어차피 레벨 3 시작하면 쉬고 싶어도 못 쉴 테니까 ^_^...

아무튼 재충전 잘하고 레벨 3 힘내야겠다

수료까지 파이팅

취업도...

해야지

다들 파이팅!

[우테코 5기] 장바구니 협업 미션 회고

dolmeng2 — Fri, 16 Jun 2023 01:23:35 +0900

라온, 쥬니, 세인, 쵸파랑 진행했던 레벨 2 마지막 미션, 장바구니 협업 미션이다!

프론트 크루분들이랑도 함께 할 수 있었어서 너무 재밌었던 시간이었다

이번 미션은 저번에 진행했던 미션을 바탕으로 하다 보니까 코드적인 부분보다, 배포 쪽을 더 신경썼던 것 같다.

마지막 미션인 만큼 정말 많이 배웠던 시간이었다 ㅎㅎ

✔️ 작성한 코드

GitHub - Cl8D/jwp-shopping-order: 우아한테크코스 레벨 2 장바구니 협업 미션 레파지토리

우아한테크코스 레벨 2 장바구니 협업 미션 레파지토리. Contribute to Cl8D/jwp-shopping-order development by creating an account on GitHub.

github.com

✔️ PR

[2단계 - 주문 기능 구현] 져니(이지원) 미션 제출합니다. by Cl8D · Pull Request #19 · woowacourse/jwp-shoppi

안녕하세요, 찰리! 져니입니다 만나서 반가워요! ☃️ 벌써 레벨 2 마지막 미션이네요... 시간이 너무 빠른 것 같습니다 ㅎㅎ ㅠ 다음 주 월요일이 마지막 PR 요청인 거 보고 리뷰에 좀 더 집중

github.com

마지막 코드 리뷰라는 게 너무 슬프다...

✔️ 기능 요구사항

- AWS로 배포하기 (서버 배포용 인스턴스 / DB용 인스턴스)

: 이때, DB용 인스턴스는 외부 IP로 공개되지 않는다.

- 장바구니에 담은 상품을 주문할 수 있다.
- 상품 주문 시 현실 세계의 쇼핑 서비스가 제공하는 재화 관련 요소를 최소 1가지 이상 추가한다.
: 재화 관련 요소: 쿠폰, 포인트, 할인 등
ex) 5만원 이상 주문 시 전체 금액에서 10% 할인이 된다.
- 사용자 별로 주문 목록을 확인할 수 있다.
- 특정 주문의 상세 정보를 확인할 수 있다.

✔️ AWS 배포 및 협업 환경 구축하기

프론트엔드 크루분들과 협업한다는 생각에 신나서 배포 쪽을 열심히 다루었다.

거의 다 블로그로 올린 내용이어서 따로 설명하지는 않고 넘어가고자 한다.

1. HTTP -> HTTPS 적용하기 (SSL / Nginx로 리버스 프록시 적용하기)

[Infra] AWS 배포 후 도메인 연결 및 HTTPS 적용, nginx로 리버스 프록시 적용하기

들어가기 전 무과금으로 HTTPS 적용 프로젝트를 진행해보았다. 정석대로라면 가비아 + Route53 + ACM or 가비아 + nginx로만 진행하면 좋았겠지만... 여러 제약사항으로 인해서 색다른 방법으로 도메

cl8d.tistory.com

2. 젠킨스로 CI / CD 구축하기

[Jenkins] AWS 인스턴스를 젠킨스로 배포해보기 - 1편

들어가기 전 이번 미션에서 젠킨스를 통해 CI / CD를 구축해보고 싶어서 ⭐️베베 선생님⭐️의 힘을 빌려서 한 번 진행해보았다. 나는 t4g.micro를 사용하다 보니 램이 1기가밖에 안 되어서 swap

cl8d.tistory.com

[Jenkins] AWS 인스턴스를 젠킨스로 배포해보기 - 2편

들어가기 전 지난 포스팅은 젠킨스를 설치하고 필요한 플러그인을 설치하는 과정까지 진행하였다. 레파지토리 WebHook 등록하기 우리는 깃허브 레파지토리의 특정 브랜치에 push 이벤트가

cl8d.tistory.com

3. Logback으로 에러를 파일로 로깅하기

[Spring] 에러 로깅하기 - Logback을 사용해서 ERROR 레벨만 파일로 로그를 남겨보자!

들어가기 전 이번 장바구니 미션에서는 프론트 크루들과 협업을 해야 했기 때문에 앞으로 에러 로그를 볼 일이 많아질 것 같다고 생각했다. 배포 스크립트를 작성하면서 스프링이 띄워질 때

cl8d.tistory.com

기초 중에 기초지만, 내 손으로 직접 배포를 해본다는 게 너무 뿌듯하고 신기했던 경험이었다

다음 프로젝트 할 때는 서버만 있다면...! 더 멋있게 구축해야겠다 ㅎ_ㅎ

도메인 설계하기 - 인터페이스로 분리하기

이번 미션의 핵심 요구사항 중에 하나가 재화 정책을 결정하는 것이었다.

우리 팀은 '쿠폰'이라는 도메인을 선택하였고, 처음으로 가입했을 때와 처음으로 상품을 주문했을 때 발급받도록 진행하였다.

쿠폰 도메인을 더 활용하면 좋았을 것 같은데, 최대한 간결한 방향으로 진행하다 보니 이렇게 됐다

또한, 예제 코드와 비슷한 듯 다르게 도메인을 설계하였다.

그림으로 나타내니까 복잡해 보이는데, 쿠폰과 주문, 환불 정책 도메인이 추가된 거 빼고는 지난 미션과 거의 다를 게 없다.

환불 정책의 경우 지하철 미션에서 진행했던 정책 관리 클래스의 방법을 그대로 따랐다. 마음에 든다!

- 한 가지 아쉬운 건, 주문 도메인이 장바구니 아이템 도메인 대신에 별도의 주문 상품 도메인을 가지고 있던 게 더 어울리지 않았을까 싶다. 주문이 완료된 이후에 주문에 대해 조회를 해올 때 장바구니 아이템 도메인을 가지고 있다 보니 논리적으로 어색하다는 느낌이 들었기 때문이다... 물론 리뷰어님은 별다른 피드백을 주시지 않았지만, 개인적으로 다음에 구현한다면 분리할 포인트라고 느껴졌다.

도메인과 ID

또한, 도메인이 id를 가지고 있도록 만들었는데, 사실 처음에는 이 부분을 분리했다가 나중에 피드백을 받고 수정했다.

(몇몇 크루분들도 내가 설계한 것을 보고 말씀을 해주셨었는데, 최종적으로는 가지고 있는 구조로 만들었었다 ㅎㅎㅎ)

내가 너무 영속성 레이어의 값을 도메인 객체가 가지고 있는 것에 집착했었다는 게 느껴졌다... ㅎㅎ

JPA를 쓰다 보면 어차피 일어날 수밖에 없는 것이고, 오히려 분리함으로서 복잡도가 증가한 것이 사실이니까...

앞으로도 개발하면서 이렇게 분리하는 경우는 거의 없지 않을까 싶다. 또 다시 엔티티 객체에 대해서 고려해볼 수 있던 시간이었다 ㅎㅎ

인터페이스 활용하기

또 한 가지 특이한 점은 인터페이스로 풀어나간 점인데, 우선 사용자의 비밀번호부터 보자.

public interface MemberPassword {

    String getPassword();
}

위와 같이 사용자의 비밀번호에 대한 인터페이스를 선언해두었다.

이는, 사용자가 회원가입 시 입력하는 비밀번호에 대한 제약 조건에 의해 생성자에서 객체를 만들 때 검증하게 되는데, DB에서 조회해온 값 (암호화 적용)으로 도메인 객체를 만들게 되면 제약 조건이 필요없으니, 별도의 메서드를 만드는 게 꽤나 번거롭다고 느껴졌기 때문이다.

또한, 암호화가 되어 있는 비밀번호와 암호화가 되지 않은 비밀번호가 하나의 객체로서 표현되는 게 2개의 책임을 가지고 있다고 느껴졌기 때문에, 상태가 다른 객체로서 표현하는 게 좋다고 생각했다.

그래서 아래와 같이 각각에 대한 구현체를 분리하였다.

public class NaturalPassword implements MemberPassword {

    private final String password;

    ...

    public static NaturalPassword create(final String password) {
        validatePassword(password);
        return new NaturalPassword(password);
    }

    private static void validatePassword(final String password) {
        if (password.length() < PASSWORD_MIN_LENGTH || password.length() > PASSWORD_MAX_LENGTH) {
            throw new BadRequestException(MEMBER_PASSWORD_LENGTH);
        }
    }
}

이거는 사용자의 입력으로 들어온 비밀번호 객체이다. validatePassword 메서드를 통해 길이를 검증하였다.

public class EncryptedPassword implements MemberPassword {

    private final String password;

    ...
    
    public static EncryptedPassword create(final String password) {
        return new EncryptedPassword(password);
    }
}

반면에, 암호화된 비밀번호를 담는 객체이다. 별도의 검증 없이 바로 객체를 생성하도록 만들었다.

참고로, 비밀번호 암호화의 경우 SHA256을 통해서 진행하였다. (현재 우리 구조상 원본 비밀번호를 알 이유가 없기 때문에 복호화가 안 되는 알고리즘을 채택하였다.)

public static String encrypt(final String target) {
    try {
        final MessageDigest md = MessageDigest.getInstance("SHA-256");
        md.update(target.getBytes());
        return bytesToHex(md.digest());
    } catch (NoSuchAlgorithmException ignored) {
        throw new RuntimeException("암호화 중 오류가 발생하였습니다.");
    }
}

추가적으로 주문 역시 인터페이스로 구현하였는데, 사용자의 비밀번호와 같은 이유로 쿠폰을 사용한 주문과, 쿠폰을 사용하지 않은 주문으로 분리하였다.

public class CouponOrder implements Order {

    ...
    private final Coupon coupon;

    // 총 주문 금액을 계산하는 메서드
    private BigDecimal calculateTotalOrderPrice() {
        return OrderPriceCalculator.calculateTotalOrderPrice(cartItems);
    }
	
    // 쿠폰에 의해서 할인된 금액을 계산하는 메서드
    private BigDecimal calculateDiscountPrice() {
        final int discountRate = coupon.discountRate();
        final BigDecimal convertedDiscountRate = BigDecimal.valueOf(
            (PERCENTAGE - discountRate) * DECIMAL_CONVERSION);
        return totalPrice.multiply(convertedDiscountRate).setScale(0, RoundingMode.DOWN);
    }
}

쿠폰을 사용한 주문은 쿠폰 도메인에 대한 의존 관계를 추가적으로 가지고 있으며, 쿠폰에 의해 할인된 금액도 함께 관리한다.

다만, 주문에 대한 필드가 늘어나면서 인터페이스의 getter가 엄청 많아졌다는 단점은 있다.

이에 대해서 다르게 풀어나가고 싶었는데, 명시적인 연관관계를 인터페이스로 형성하지 않았다면 해결할 수 있었을까 싶긴 하다.

아니면, 공통되는 필드를 관리하는 OrderDetail 같은 객체를 만들어서 관리했으면 더 좋았을 것 같다.

예외 클래스 설계하기

사실 이전부터 나를 괴롭히던 주제 중에 하나였다. '예외에 관한 클래스에 어떤 정보까지 가지고 있어야 하는가?'

개인적으로 서버에서 던지는 예외 메시지는 사용자에게 출력되는 용도보다는, 클라이언트 개발자가 확인하는 메시지고, 클라이언트 개발자가 해당 메시지에 따라서 사용자에게 보여지는 메시지를 관리해야 한다고 생각했다.

하지만 리뷰어님은 오히려 2번을 더 선호하셨다.

생각해보면 내가 아직 큰 서비스를 경험해보지 못해서 1번을 더 선호하는 건가 싶기는 하지만...

위와 같은 상황이 주어졌을 때 사용자에게 '상품 ID 1번이 존재하지 않습니다' 같은 메시지는 적합하지 않다고 생각했다.

예전에 개발했을 때는 클라이언트에게 에러 코드 모음을 내려주는 전용 api가 있어서, 해당 api 정보를 바탕으로 클라이언트가 매칭시켜줬던 기억이 난다. 아마 이 부분은 클라이언트 개발자과 계속 협의하면서 바꾸어나가지 않을까 싶다

또한, 이번에 작성한 예외 클래스에서는 상태 코드를 함께 관리하도록 만들었다.

public class ForbiddenException extends RuntimeException {

    private static final HttpStatus httpStatus = HttpStatus.FORBIDDEN;
    private final ErrorCode errorCode;
    ...
}

덕분에 ExceptionHandler에서의 코드가 줄어서 마음에 든다. 지금까지는 왜 이런 생각을 못 했을까...!

앞으로도 이런 식으로 작성하지 않을까 싶다. (errorCode는 협의하는 거에 따라 달라질 것 같다!)

쿠폰 발행 - 도메인 이벤트 활용하기

전에 말랑의 테코톡 보고 이벤트 방식을 꼭 활용해보고 싶었는데, 쿠폰 발행에 대해서 이벤트 방식을 사용하면 좋을 것 같다는 생각이 들어서 바로 도입해보았다. 개인적으로 매우 뿌듯했다...

도메인 이벤트를 활용한 배경은 다음과 같다.

1. 쿠폰 발행의 경우 다양한 서비스에서 활용할 수 있는 비즈니스 로직이다.
다른 서비스에서 사용할 때마다 쿠폰에 대한 의존 관계가 뻗어나가는 것보다, 이벤트 방식을 통해 의존성을 역전시키는 게 더 깔끔할 것 같다고 생각했다.

2. 회원가입과 쿠폰 발행이 하나의 트랜잭션으로 묶여있을 때, 쿠폰 발행 중에 예외가 발생했다면 회원가입 로직까지 롤백이 될 것이다. 사용자의 입장에서 회원가입은 굉장히 번거로운 작업이고, 사용자가 가입하는 시점에서는 쿠폰이 발행된다는 것을 알지 못하기 때문에 쿠폰 때문에 회원가입 자체가 실패해버리면 다시 가입하지 않을 것이라는 생각이 들었다. 이를 위해 가입 로직과 쿠폰 발행 로직에 대한 트랜잭션을 분리할 필요성을 느꼈다.

그래서, 아래와 같이 회원 가입 시 쿠폰 발행을 진행하도록 이벤트를 발행하였다.

@Transactional
public long save(final MemberJoinRequest memberJoinRequest) {
    if (memberRepository.existByName(memberJoinRequest.getName())) {
        throw new BadRequestException(ErrorCode.MEMBER_DUPLICATE_NAME);
    }
    final Member member = convertMember(memberJoinRequest);
    final long savedMemberId = memberRepository.insert(member);
    applicationEventPublisher.publishEvent(new JoinMemberCouponEvent(savedMemberId));
    return savedMemberId;
}

그리고, 쿠폰 저장 로직은 아래와 같이 진행하였다.

@TransactionalEventListener
@Transactional(propagation = Propagation.REQUIRES_NEW)
public void saveJoinMemberCoupon(final JoinMemberCouponEvent joinMemberCouponEvent) {
    final Long memberId = joinMemberCouponEvent.getMemberId();
    final Coupon coupon = couponRepository.findByNameAndDiscountRate(JOIN_MEMBER_COUPON.getName(),
        JOIN_MEMBER_COUPON.getDiscountRate());

    final LocalDateTime issuedAt = LocalDateTime.now();
    validateAlreadyIssued(memberId, coupon.couponId());
    final MemberCoupon memberCoupon = convertMemberCoupon(coupon, issuedAt);
    memberCouponRepository.save(memberId, memberCoupon);
}

로직 자체는 쿠폰을 조회해서 이미 발생했는지 확인하고 저장한다.

@TransactionalEventListener란?
- phase 옵션을 통해서 트랜잭션에 따른 이벤트 처리 방법을 지원한다.
기본적으로는 'AFTER_COMMIT'으로 설정되어 있기 때문에 트랜잭션 커밋 시 이벤트를 실행한다.

하지만, 여기서 @Transactional(propagation = Propagation.REQUIRES_NEW)라는 옵션이 눈에 띌 것이다.

기존에는 전파 속성을 설정하지 않았었는데, 리뷰어님께 다음과 같은 피드백을 받았다.

왜 그럴까 고민을 했었는데, 나는 아래와 같이 이해했다.

1. JdbcTemplate의 경우 @transactional 어노테이션이 없어도 기본적으로 jdbcTemplate.update나 query() 메서드를 사용하는 시점에서 DB에 쿼리가 날라간다. (JPA와 다른 점)

2. 예외가 발생했을 때 롤백이 일어나기 위해서는 @transactional을 통해서 묶어줘야 한다. 아니면 JdbcTemplate에서 이미 save를 진행했기 때문에 이에 대해 롤백할 수 없다.

3. 기본적으로 @TransactionalEventListener는 시작된 트랜잭션 commit 후에 동작한다.

4. 하지만, 단순히 @transactional을 붙이면 기존 회원 가입에서 걸려있던 트랜잭션에 참여하게 된다. 그러나, 커밋된 트랜잭션에 대해서는 다시 커밋이 불가능하기 때문에 롤백이든, 다른 연산을 수행하더라도 무의미하다.
-> 그래서 만약 JPA 같이 삽입, 수정, 삭제 연산에서 @Transcational이 필요한 경우였다면 애초에 쿼리 자체가 날라가지 않았을 것이다. (물론 나의 가정이다)

5. ⭐️ 하지만, 지금은 jdbcTemplate을 사용했기 때문에 쿼리는 날라간다. 하지만, 예외 발생 시 롤백이 불가능하다.

6. 이를 해결하기 위해 기존의 트랜잭션과 다른 트랜잭션으로 분기시켜서 예외 발생 시 롤백이 되도록 만든다!

원래는 이미 커밋된 트랜잭션에 참여하기 때문에 수정이든 삭제든 불가능하지만 (JPA 같이 영속성 컨텍스트를 통해서 flush가 발생하는 경우), jdbcTemplate의 경우 트랜잭션 어노테이션에 상관없이 쿼리를 execute 하는 순간 DB에 쿼리가 날라가기 때문에 @Transactional 어노테이션이 없어도 저장 자체는 잘 되었다.

하지만, 예외가 발생했을 때 '이미 커밋된 트랜잭션'에 참여했기 때문에 롤백 역시 불가능하게 된 것이다.

그래서, 트랜잭션 전파 속성을 활용하여 별도의 트랜잭션으로 분기해주었다.

트랜잭션은 기본적으로 전파 속성이 'REQUIRED'로 설정되어 있기 때문에, 기존 트랜잭션이 있으면 해당 트랜잭션에 참여한다. (없으면 새로 생성) 반면에, REQUIRES_NEW를 사용하게 되면 항상 새로운 트랜잭션에서 실행된다.

두 트랜잭션이 분리되었기 때문에 B의 롤백이 A에는 영향을 끼치지 않게 되었으며, 덕분에 쿠폰 발행 도중 예외가 발생하더라도 회원가입 로직과 관계 없이 잘 롤백되는 것을 확인할 수 있었다.

아래는 이에 대한 테스트 코드이다.

회원 가입 시 이미 발행된 쿠폰이 있다면 예외가 발생하고, 해당 쿠폰에 대해서 다시 발급이 되는지 테스트한다.

@Test
@DisplayName("회원 가입 축하 쿠폰 발행 시 이미 발행이 완료되었다면 예외가 발생한다.")
void saveJoinMemberCoupon_already_issued() {
    // given
    final String 져니_이름 = "journey2";
    final Long 저장된_져니_아이디 = 사용자를_저장한다(져니_이름);
    final JoinMemberCouponEvent 회원_가입_쿠폰_발행_이벤트 = new JoinMemberCouponEvent(저장된_져니_아이디);
    memberCouponService.saveJoinMemberCoupon(회원_가입_쿠폰_발행_이벤트);

    // then
    assertThatThrownBy(() -> memberCouponService.saveJoinMemberCoupon(회원_가입_쿠폰_발행_이벤트))
        .isInstanceOf(BadRequestException.class)
        .extracting("errorCode")
        .isEqualTo(ErrorCode.COUPON_ALREADY_EXIST);

    // then
    final List<MemberCouponDto> 져니_쿠폰들 = memberCouponDao.findMyCouponsByName(져니_이름);
    assertThat(져니_쿠폰들)
        .hasSize(1);
}

예외 발생 후 쿠폰을 조회했을 때 이미 발행된 1장의 쿠폰만 존재하는 것을 확인할 수 있다.

주문 취소 정책 설계하기

사실 이거는 페어 프로그래밍으로 진행한 건 아니고, 내가 따로 만들고 싶어서 만든 api이다.

주문한 지 3일 이내라면 전액, 7일 이내라면 반액을 반환하도록 만들었다. 물론 그 이상은 환불 불가능하다.

사실 배송 정책이 있다면 배송 출발 같이 그런 것까지 고려하겠지만... 현재 서비스 특성상 거기까지 뻗어나가지 않았기 때문에 이것 역시 간결하게 구현하였다. (이번 미션을 하면서 제대로 된 쇼핑몰 사이트를 만들어보고 싶다는 생각이 들었다 )

// Before
public RefundPolicyComposite refundPolicyComposite(
    final RefundPolicy fullRefundPolicy, final RefundPolicy halfRefundPolicy) {
    return new RefundPolicyComposite(
        List.of(fullRefundPolicy, halfRefundPolicy)
    );
}

// After
public RefundPolicyComposite refundPolicyComposite(final List<RefundPolicy> refundPolicies) {
    return new RefundPolicyComposite(refundPolicies);
}

정책 관련 클래스를 빈으로 주입할 때 기존에는 RefundPolicy에 대해서 하나씩 집어넣었는데 매번 Config를 수정해야 한다는 단점이 존재해서 아래와 같이 List를 통해서 주입받도록 변경하였다.

이렇게 하면 컴포넌트 스캔 순서대로 등록이 되어서 (사전순으로 보인다) Full, Half가 빈으로 주입되었다. 스캔 순서에 따른 빈에 대한 순서 보장이 확실하지 않기 때문에 정책이 적용 가능한지 판단하는 메서드에 대해 경계값을 철저하게 검증하는 방향으로 변경하였다.

// Before - 50% 할인 시 3일 이상인지만 검증
@Override
public boolean isAvailable(final Order order, final LocalDateTime currentTime) {
    return currentTime.isBefore(order.getOrderedAt().plusDays(HALF_REFUND.getDay()));
}

// After - 3일 ~ 7일인지 검증
@Override
public boolean isAvailable(final Order order, final LocalDateTime currentTime) {
    final LocalDateTime orderedAt = order.getOrderedAt();
    return currentTime.isAfter(orderedAt.plusDays(FULL_REFUND.getDay())) &&
        currentTime.isBefore(orderedAt.plusDays(HALF_REFUND.getDay()));
}

또한, 금액의 경우 정밀한 계산을 해야 하기 때문에 BigDecimal을 사용하는 게 좋다고 들어서 요렇게 적용하였다.

@Override
public BigDecimal calculatePrice(final BigDecimal price) {
    final BigDecimal refundRate = BigDecimal.valueOf((PERCENTAGE - HALF_REFUND_RATE) * DECIMAL_CONVERSION);
    return price.multiply(refundRate).setScale(0, RoundingMode.DOWN);
}

setScale(0, RoundingMode.DOWN)을 통해서 소수점 이하의 값을 버리도록 만들었다. (아니면 값이 더러워진다!)

페이징 쿼리 작성하기

이 부분도 합의된 API는 아니고, 개인 학습용으로 작성했다.

항상 JPA로 만들었다가 쌩 쿼리로 작성해본 건 처음이었는데, 생각보다 어렵지 않았다.

@GetMapping("/pages")
public ResponseEntity<ProductPageResponse> getProductsByPage(@RequestParam("page") final int page,
                                                             @RequestParam("size") final int size) {
    return ResponseEntity.ok(productService.getProductsByPage(page, size));
}

상품 목록에 대한 페이징 API이다. 쿼리 파라미터로 조회할 페이지 번호와 한 페이지에 몇 개씩 받을 것인지 입력받았다.

public class ProductPageResponse {

    private final long totalPage;
    private final List<ProductResponse> productResponse;
    ...
}

반환 값으로는 총 페이지 수와 해당 페이지에 대한 상품 응답을 반환하였다.

public List<ProductEntity> getProductsByPage(final int page, final int size) {
    final int offset = calculateOffset(page, size);
    final String sql = "SELECT id, name, image_url, price, is_deleted FROM product "
        + "ORDER BY id LIMIT ? OFFSET ?";
    return jdbcTemplate.query(sql, productEntityRowMapper, size, offset);
}

나름 핵심이 되는 페이지 처리 쿼리다.

⭐️ LIMIT의 경우 결과 중에서 몇 개만 조회할 것인지 설정하고, OFFSET은 어디서부터 가져올지를 나타낸다.

SELECT * FROM table_name LIMIT 10 OFFSET 20;
= 20번째 (계산된 오프셋) 행부터 10개 (size) 조회
= 21번째 ~ 30번째 행까지 출력

여기서 offset을 계산하는 메서드를 호출했는데, 이는 다음과 같다.

private int calculateOffset(final int page, final int size) {
    if (page == 1) {
        return 0;
    }
    return (page - 1) * size;
}

클라이언트 개발자에게 1부터 값을 받는다고 가정하였다.

1이라면 첫 번째 페이지니까 offset을 0을, 그 이상이라면 (page - 1) * size만큼을 설정해주었다.

만약 page = 3, size = 10이라는 값이 들어왔다면 2 * 10 = 20번째 행부터 10개를 가져오게 되는 것이다.

총 페이지의 경우 다음과 같이 계산하였다.

private long calculateTotalPage(final int size, final long totalProductCount) {
    long totalPage = totalProductCount / size;

    if (totalProductCount % size > 0) {
        totalPage++;
    }
    return totalPage;
}

상품의 총 개수에서 한 페이지에 출력할 상품의 개수를 나눈 값을 총 페이지로 설정하였다.

이때, 총 개수에서 한 페이지에 출력할 상품의 개수의 나머지 값이 0보다 크면 1을 증가시켜주었다.

이는, 총 25개의 상품이 있을 때 10개씩 한 페이지에 출력한다면 총 페이지는 3개이기 때문에 남은 값들에 대해 페이지로 처리해주려고 위와 같이 설정해주었다.

사실 page랑 size에 대해서도 제약 조건을 걸어둬야 하고 (0 이상이라든지, 정해진 값으로 size를 받는다든지...)

반환 값에도 현재 페이지랑 사이즈 같이 조금 더 다양하게 내려줬어야 했는데 개인 학습용이라 간단하게 만들었다. ㅎㅎ

나름 재밌었던 경험이었다!

이번 미션은 확실히 기존 코드 리팩터링 + 인프라 구축에 신경을 많이 써서 그런가 크게 회고할 내용이 없었다.

하지만 목표했던 도메인 이벤트도 써보고, 여러 가지로 배운 점이 많았어서 그런가 뿌듯했던 시간이었다.

마지막 미션인 만큼 열심히 했던 것 같아서 좋다!

레벨 2 회고도 얼른 쓰고 방학 신나게 놀아야지

[Real MySQL 8.0] InnoDB 스토리지 엔진 알아보기 - 3편 (Buffer Pool - on disk structures)

dolmeng2 — Thu, 15 Jun 2023 13:52:59 +0900

들어가기 전

이번 포스팅에서는 InnoDB의 전반적인 아키텍처 중에서 디스크 영역에 대해서 알아보자.
마찬가지로 간단하게만 짚고 넘어가고자 한다.

저번 포스팅 그림 재탕...~

Tablespace

테이블 스페이스는 데이터를 저장하기 위해 사용되는 큰 논리적인 단위이며, Segment -> Extent -> Page -> Row와 같은 형태로 구성된다. MySQL에서 테이블 스페이스는 저장하는 데이터의 종류에 따라서 5가지로 분류가 가능한데, 이는 다음과 같다.

- System tablespace
- File-Per-Table tablespace
- General Tablespace
- Temporary Tablespace
- Undo Tablespace

System tablespace

System tablespace의 경우 MySQL에서 기본적으로 사용되는 Shared Tablespace이다.
체인지 버퍼가 있는 영역이며, 여기서 테이블을 생성하게 되면 테이블과 인덱스 데이터를 저장할 수 있다.
내부의 데이터 파일의 크기와 수는 innodb_data_file_path라는 시스템 환경변수로 설정이 가능하다.

File-Per-Table tablespace

하나의 테이블에 대한 데이터와 인덱스를 개별적인 파일로 관리하는 테이블 스페이스이다.
즉, 우리가 생성하는 테이블은 이 공간에 저장된다고 생각하면 된다.
inno_file_per_table 옵션으로 조절이 가능하며, 해당 옵션을 비활성화 하면 시스템 테이블스페이스에 새엇ㅇ된다.

- truncate / drop 연산 시 디스크 공간은 OS에게 반납된다. (테이블 삭제 시 버퍼 풀을 잠그고 스캔하기 때문에 버퍼 풀이 크다면 시간이 더 소요될 수 있다는 점 주의)
- 다른 MySQL 인스턴스에서 file-per-table 공간에 있는 테이블을 가져올 수 있다.

General tablespace

create tablespace로 만든 구문을 사용해서 만들 수 있으며, shared tablespace여서 여러 테이블의 데이터를 저장할 수 있다.
다른 테이블 스페이스를 general로 변경할 수 없으며, 임시 테이블을 지원하지 않는다.
file-per-table 테이블 스페이스와 다르게 truncate / drop 시에 데이터 파일에 비어있는 공간이 생기며, OS로 반환되지 않는다.

Temporary tablespace

내부적으로 2가지의 테이블 스페이스로 분리되는데, Session / Global Temporary tablespace로 나뉜다.

Session Temporary tablespace의 경우 사용자가 생성한 임시 테이블과 옵티마이저가 임시로 생성하는 임시 테이블의 내용을 저장한다.
이 공간은 커넥션이 종료되면 truncate 되어서 temp tablespace pool로 반환된다. 풀의 경우 서버가 시작되면 10개의 temporary tablespace를 생성하며, 필요에 따라서 풀에 더 추가된다.

Global Temporary tablespace의 경우 임시 테이블에 대한 롤백 세그먼트들을 저장한다. 데이터 파일의 상대 경로나 이름, 크기, 속성을 정의하며 (innodb_temp_data_file_path 변수로 지정) 값을 지정하지 않았다면 하나의 데이터 파일로 생성하게 된다. (innodb_data_home_dir 디렉터리에 생성)
마찬가지로 종료되거나 중단되면 제거되고, 서버가 재시작되면 다시 생성된다.

Undo Tablespace

Undo tablespace에는 클러스터링 인덱스에 대한 Undo Log 정보가 포함되어 있다. Undo 로그의 경우 롤백 세그먼트 내부에 포함된 언두 로그 세그먼트에 존재하며, 롤백 세그먼트의 경우 undo tablespace or global tempory tablespace 안에 있다.
기본적으로 2개의 undo tablespace가 생성되며, innodb_undo_directory 시스템 변수에 정의된 위치에 파일이 생성된다. (미지정 시 mysql data 디렉터리에 생성)
⭐️ 여기서 일반 테이블에 대한 트랜잭션은 Undo tablespace, 임시 테이블에 대한 트랜잭션은 Global temporary tablespace에 undo log가 할당된다.

Undo Log

InnoDB는 트랜잭션 (롤백 대비)과 격리 수준 보장을 위해 CUD 쿼리로 데이터가 변경되기 이전의 데이터를 별도로 백업하며, 이를 Undo Log라고 한다. 매우 중요한 역할을 하는 만큼 관리 비용도 상당하다.

만약, A라는 트랜잭션이 매우 길어서 그 사이에 여러 CUD 작업이 일어났다면, 사이에 발생한 작업의 트랜잭션이 끝나더라도 언두 로그는 계속해서 보존될 것이다. MySQL 5.5 이전에서는 한 번 증가한 언두 로그 공간이 다시 줄어들지 않았다. 이러다 보니 대용량의 데이터를 처리할 때 언두 로그의 양이 급격하게 증가되고, 조회 시마다 커진 언두 로그를 스캔하면서 성능이 나빠지게 되었다. 하지만 8.0으로 오면서 필요한 시점에 크기를 줄여주거나, 언두 로그를 돌아가면서 사용해서 디스크 공간이 크게 늘어나지 않도록 만들어두었다.

또한, 언두 로그가 얼마나 증가했는지 모니터링하는 기능도 추가되었다.

SHOW ENGINE INNODB STATUS \G

이런 식으로 나온다. 저기서 History List에 있는 숫자가 언두 로그의 건수이다. (딱히 작업한 게 없어서 0이다)

MySQL 8.0이라면 아래와 같이 좀 더 명시적으로 확인할 수 있다.

select count
from information_schema.INNODB_METRICS
where SUBSYSTEM='transaction'
and name = 'trx_rseg_history_len';

참고로, 언두 로그의 경우 최대 4개로 분리된다.

- 사용자 정의 테이블에 대한 INSERT
- 사용자 정의 테이블에 대한 UPDATE / DELETE
- 사용자 정의 임시 테이블에 대한 INSERT
- 사용자 정의 임시 테이블에 대한 UPDATE / DELETE

이는 UPDATE / DELETE 시 발생한 언두 로그는 MVCC, 데이터 복구에 모두 사용되지만 INSERT의 경우 데이터 복구에 대해서만 사용되기 때문에 위에서 사용했던 확인 방법으로는 UPDATE / DELETE로 인해 발생한 언두 로그 개수만 표시된다.

이러한 언두 로그는 MySQL 8.0부터 로그 파일을 통해서 기록된다.
이전에는 시스템 테이블스페이스에 저장됐었는데, 1~128개의 롤백 세크먼스를 가진다. (페이지 크기 / 16bytes개)
하나의 롤백 세그먼트 내에는 다시 1개 이상의 Undo 슬롯을 가지고 있으며, 하나의 트랜잭션은 최대 4개까지의 언두 슬롯을 사용한다. (일반적으로는 2개)
그래서, 동시에 처리할 수 있는 트랜잭션의 개수는 보통 (innoDB 페이지 크기) / 16 * (롤백 세그먼트 개수) * (언두 테이블스페이스 개수)로 구할 수 있다. 언두 로그 공간이 부족하면 트랜잭션을 시작할 수 없기 때문에, 언두 로그 관련 변수를 조절할 때는 동시에 처리할 수 있는 트랜잭션 개수에 따라서 테이블스페이스와 롤백 세그먼트 개수를 설정해야 한다.

MySQL 8.0부터는 create undo tablespace나 drop tablespace 등을 통해서 동적으로 테이블 스페이스를 추가하거나 삭제할 수 있다.

# undo log 관련 테이블스페이스 확인
select TABLESPACE_NAME, FILE_NAME
from information_schema.FILES
where FILE_TYPE like 'undo log'

Undo tablespace 공간 줄이기

만약 언두 테이블스페이스의 공간을 줄이고 싶다면, 2가지의 방법을 사용할 수 있다.
CUD 쿼리 작업 시 언두 로그로 기록되는데, 트랜잭션이 커밋되면 언두 로그에 복사된 값은 불필요하기 때문에 퍼지 스레드가 주기적으로 해당 값을 제거한다. 이때, innodb_undo_log_truncate 시스템 변수가 on이라면 퍼지 스레드가 주기적으로 사용하지 않는 공간을 OS에게 반납한다. (반납 주기는 innodb_purge_rseg_truncate_frequency 변수 조정)

혹은, 직접 비활성화 쿼리를 이용해서 퍼지 스레드가 비활성 상태인 테이블스페이스를 반납하도록 만들 수 있다. (이때는 테이블스페이스가 최소 3개 이상은 되어야 작동이 가능하다.)

# 비활성화
alter undo tablespace tablespace_name set inactive;

# 퍼지 스레드에 의해 언두 테이블스페이스 공간이 반납되면 재활성화
alter undo tablespace tablespace_name set active;

Double Write Buffer

리두 로그는 페이지의 변경된 부분만 기록하는데, 만약 더티 페이지 플러시 시 일부만 기록되는 문제가 발생한다면 해당 페이지 내용은 복구 불가능할 수도 있다. 이런 식으로 일부만 기록되는 것을 Partial-Page, 또는 Torn-Page라고한다.
이러한 문제를 막기 위해 InnoDB에서는 ' Double-Write'라는 공간을 통해, 버퍼 풀로부터 플러시된 페이지를 데이터 파일에 쓰기 전에 저장한다.

1. A~E까지의 더티 페이지 플러시
2. 디스크로 기록하기 전에 A~E까지의 데이터를 묶어서 Double Write Bufer에 기록
3. 더티 페이지를 적당한 위치에 랜덤으로 쓰기 작업 진행

만약 정상 기록 시 Double Write Buffer에 기록된 것은 제거되고, 비정상적으로 종료되었다면 해당 내용을 참조하여 복구한다.
데이터의 무결성이 중요한 서비스라면 사용하는 것이 좋다. (innodb_doublewrite 변수 사용)
- 참고로 innodb_flush_log_at_trx_commit 옵션을 (커밋 시 아무 작업도 X, 해당 옵션이 켜져 있다면 커밋 시 로그 버퍼에 데이터 쓰고 => 디스크에 데이터 쓰는 작업 진행) 성능상으로 껐다면 doublewrite도 끄자.

Redo Log

Redo Log는 비정상적으로 종료된 트랜잭션에 의해 변경된 데이터를 적용하기 위해서 사용한다. (복구 작업) 기본적으로 MySQL은 innoDB의 변경 내용을 바로 디스크에 저장하지 않고 버퍼 풀에 저장하기 때문에, 변경된 데이터가 디스크에 적용되지 않았다면 재시작 동작 중에 Redo 작업을 먼저 수행하게 된다.

- 참고로, 복구 작업은 다음과 같은 단계로 이루어진다.
테이블 스페이스 탐색하기 -> 리두 로그 적용하기 -> 완료되지 않은 트랜잭션 롤백하기 -> 체인지 버퍼 병합하기 -> 퍼지하기

기본적으로 버퍼 풀은 디스크에서 데이터를 읽은 상태로 전혀 변경되지 않은 Clean 페이지와, 변경되었지만 디스크에 아직 기록되지 않은 Dirty 페이지를 가지고 있는데, Dirty 페이지의 경우 디스크와 버퍼 풀 메모리에 적재된 데이터의 상태가 다르기 때문에 둘을 동기화해야 한다.

더티 페이지의 경우 사실상 버퍼풀에 임시로 유지되는 데이터 상태이기 때문에, innoDB에서는 이를 제거하기 위해 여러 가지 방법을 사용한다. 그리고, 이 방법 중 하나가 '활성 리두 로그 - Active Redo Log'를 사용하는 것이다.

활성 리두 로그의 경우 여러 파일로 구성되어 있으며, 데이터 변경이 발생할 때마다 새로운 로그 엔트리로 덮어씌우며 기록된 파일을 순차적으로 재사용하는 것이다. (쓰여진 리두 로그 자체) 재사용을 하기 때문에 리두 로그에서는 재사용이 가능한 공간과 재사용이 불가능한 공간으로 나누어지며, 이 중에서 활성 리두 로그의 경우 '재사용 불가능 공간'을 의미한다.

리두 로그는 순환하기 때문에 기존의 데이터는 계속 덮어 씌워지면서 없어진다. 하지만, 기록될 때마다 계속 증가하는 'LSN (Log Sequence Number)'이라는 값을 표시한다. LSN은 Redo Log에 기록된 작업의 시점을 가리킨다고 볼 수 있다.

InnoDB는 주기적으로 체크포인트를 통해 Redo 로그와 버퍼 풀의 Dirty 페이지를 디스크로 동기화한다.
이렇게 발생한 체크포인트 중에서 가장 최근 체크포인트 지점의 LSN이 활성 리두 로그 공간의 시작점이 된다.

CheckPoint
- 체크포인트가 발생하면 버퍼 풀 내의 변경된 페이지를 디스크로 동기화 작업을 진행한다.

Sharp CheckPoint
- 커밋된 트랜잭션의 모든 더티 페이지를 디스크에 플러시하고, 가장 최근에 커밋된 트랜잭션의 LSN을 기록함
- 정상 종료나 리두 로그 파일을 순환하여 재사용할 때 Sharp CheckPoint 활용

Fuzzy CheckPoint
- 더티 페이지를 조금씩 디스크로 플러시하고, 그 위치를 시작 - 종료 지점의 LSN을 기록하여 관리
- 마스터 스레드에 대해 1~10초마다 주기적으로 플러시 리스트 확인
- 프리 페이지의 여유 공간이 부족할 때 LRU 리스트의 더티 페이지 체크포인트
- 리두 로그 파일이 다 찼을 때 일부 페이지 강제 플러시 시 사용
- 더티 페이지가 너무 많을 때 체크포인트

또한, 가장 최근 지점의 LSN과 마지막 리두 로그 엔트리의 LSN 차이를 Checkpoint Age라고 하며, 해당 값이 클수록 아직 디스크에 반영되지 않은 변경사항이 많다는 것을 의미하기 때문에 체크포인트를 적절한 시점에 수행해주는 것이 중요하다.

결과적으로 버퍼 풀의 dirty 페이지는 특정 리두 로그 엔트리와 관계를 가지고, 체크포인트가 발생하면 체크포인트 LSN보다 작은 리두 로그 엔트리와 관련된 dirty 페이지, 리두 로그 엔트리는 모두 디스크로 동기화돼야 한다.

ex) 버퍼 풀이 100기가, 리두 로그 파일의 전체 크기는 100메가
- Checkpoint Age 역시 최대 100메가까지 허용된다. 리두 로그 엔트리가 평균적으로 4KB라면 100MB / 4KB = 25600개 정도의 dirty 페이지만 버퍼 풀에 보관할 수 있게 된다. 만약 데이터 페이지가 16KB라면 허용 가능한 전체 더티 페이지는 400MB 정도이다.
= 버퍼 풀은 매우 크지만, 실제 쓰기 버퍼링을 위한 효과는 거의 못 보는 상태이다.

ex) 버퍼 풀은 100메가, 리두 로그 파일은 100기가
- 위의 경우와 다르게 전체 더티 페이지는 최대 400기가 정도 가질 수 있게 된다. 하지만, 버퍼 풀의 크기가 100메가니까 허용 가능한 더티 페이지는 100메가 정도이다. 이 경우에는 버퍼 풀이 필요할 때 너무 많은 dirty 페이지를 한 번에 기록해야 될 수도 있어서 좋지는 않다.
= 리두 로그 파일은 매우 크지만, 버퍼 풀이 필요할 때 더티 페이지를 갑자기 엄청 써야 하는 일이 생길 수 있어서 부하가 생길 수도 있다.

두 예제 모두 상당히 극단적이다.
만약 버퍼 풀의 크기가 100기가 이하라면 대략 5~10기가 정도로만 선택하자.

Redo Log 동작 순서

1. 버퍼 풀에서 데이터가 변경되면 해당되는 페이지를 수정한 다음 Dirty 마킹 진행
2. 관련된 리두 로그 레코드를 Double Write Buffer에 저장
3. 리두 로그 레코드를 Log Buffer로 이동
4. 리두 로그 레코드를 Redo Log File로 플러시
5. 변경된 Dirty 페이지에 대해 체크포인트를 수행하여 System tablespace에 저장

- 중요한 점은 바로 디스크 영역인 System tablespace에 저장하는 게 아니라 Log Buffer에 들어가고, 한 번에 모아서 Redo Log File로 플러시한다는 게 중요하다.

Redo Log 파일의 전체 크기

리두 로그 파일의 전체 크기는 버퍼 풀의 효율성 을 결정할만큼 중요하다.
innodb_log_file_size 변수를 통해 리두 로그 파일의 크기를, innodb_log_files_in_group을 통해 리두 로그 파일의 개수를 설정할 수 있어, 결과적으로 두 값을 곱한 값이 로그 파일의 전체 크기가 된다. 로그 버퍼의 크기는 기본값이 16MB이며, 만약 큰 데이터를 자주 변경한다면 더 크게 설정하는 것이 좋다.

Redo Log 아카이빙

리두 로그의 경우 중요한 만큼, 로그를 계속 추적하면서 새로 추가된 리두 로그 엔트리를 복사하는 기능이 추가되었다. (MySQL 8.0 엔터프라이즈 버전) 이때, 데이터 변경이 많아서 리두 로그 내용이 복사되기도 전에 덮어씌워지더라도 리두 로그 아카이빙을 활용하면 백업이 실패하지 않게 된다. (innodb_redo_log_archive_start, nnodb_redo_log_archive_stop)

기본적으로 리두 로그는 항상 활성화되어 있는데, MySQL 8.0부터는 비활성화하도록 만들 수도 있다.
대용량 데이터를 복구하거나 한 번에 적재하는 경우에는 비활성화하여 적재 시간을 낮출 수 있다.

# 비활성화
ALTER INSTANCE DISABLE INNODB REDO_LOG

# 활성화
ALTER INSTANCE ENABLE INNODB REDO_LOG

물론, 비활성 후 데이터 적재 작업을 진행했다면 꼭 다시 활성화를 해줘야 한다. (비정상 종료에 늘 대비하기)

내용이 많아서 어지럽다...
나중에 다시 정리해봐야겠다 ㅎㅎ;

[Real MySQL 8.0] InnoDB 스토리지 엔진 알아보기 - 2편 (Buffer Pool - in memory structures)

dolmeng2 — Wed, 14 Jun 2023 21:48:29 +0900

들어가기 전

이번 포스팅에서는 InnoDB의 전반적인 아키텍처 중에서 메모리 영역에 대해서 알아보자.
상당히 복잡하기 때문에 대략적인 내용만 이해하고 넘어가도 충분하다고 생각한다.

InnoDB 버퍼 풀 (Buffer Pool)

위 그림은 MySQL 8.0 기준 InnoDB 구조를 나타낸 그림이다.
이중에서 버퍼 풀의 경우 InnoDB 스토리지 엔진의 가장 핵심적인 부분이다.
디스크의 데이터 파일, 인덱스 정보를 메모리에 캐시도 해둘 수 있고, 쓰기 작업을 지연시켜서 일괄 처리도 가능하다.

그렇다면 크기는 어느 정도로 설정해야 할까?
보통 OS 전체 메모리 공간이 8기가 이하라면 50% 정도만 버퍼 풀로 설정하고, 나머지는 다른 프로그램이 사용할 공간으로 남겨두는 것이 좋다. 만약 메모리 공간이 더 크다면 조금씩 늘려가면서 최적점을 찾아나가는 것이 좋다.
50기가 이상이라면 대략 15~30기가 정도만 제외하고 나머지는 버퍼풀에게 양보해주자.
공식 문서에서는 최대 80%가 할당된다고는 말하고 있다.

또한, 이미 늘어나있던 풀의 크기를 줄이는 건 영향이 매우 크기 때문에 주의해야 한다.

innoDB 버퍼 풀은 여러 개로 쪼개어 관리할 수 있게 되었는데, 쪼개진 각각을 '버퍼 풀 인스턴스'라고 부른다.
기본적으로 8개로 초기화되어 있지만, 만약 버퍼 풀의 크기가 1기가 미만이라면 1개만 생성된다.
보통 40기가 이하라면 8개, 그 이상이라면 인스턴스당 5기가 정도로 잡고 개수를 할당하는 것이 좋다.

show variables like '%innodb_buffer%'

궁금해서 나도 한 번 조회해봤는데 다음과 같았다.

위의 값을 1024로 2번 나눈 값이 메가바이트인데, 딱 128MB이다. (기본값)
참고로 이 값은 항상 innodb_buffer_pool_chunk_size * innodb_buffer_pool_instances과 같아야 한다.

확인해보면 현재 인스턴스가 1개여서 chunk_size 값이 그대로 size로 배정받은 것을 볼 수 있다.

버퍼 풀의 구조 - Free / Flush / LRU List

기본적으로 innoDB는 '버퍼 풀'이라는 거대한 메모리 공간을 페이지 크기 조각으로 쪼개서, 필요할 때 해당 데이터 페이지를 읽어 각 조각에 저장한다. 이때, 페이지 크기 조각을 관리하기 위해 LRU / Flush / Free List 3개의 자료 구조를 관리한다.

LRU 리스트는 LRU 정책에 의해서 교체된 페이지들의 목록을 관리하는데, 밑에서 자세하게 알아보자.

Flush 리스트

Flush 리스트는 디스크로 동기화되지 않은 데이터를 가진 데이터 페이지 (dirty page)의 변경 시점 기준의 페이지 목록을 관리한다. 만약, 디스크에서 읽은 상태에서 변화가 없다면 Flush 리스트에서 관리되지 않지만 특정 시점이 지나게 되면 디스크로 기록이 되어야 한다.
기본적으로 데이터가 변경되면 InnoDB는 Redo 로그에 기록하면서, 버퍼 풀의 데이터 페이지에도 해당 내용을 반영한다. 하지만, 항상 Redo 로그가 기록되었다고 데이터 페이지에도 반영되었음을 보장할 수 없기 때문에 '체크 포인트'를 발생시켜 두 상태를 동기화한다. 이때 동기화를 위해서 사용하는 게 Flush 리스트라고 생각하면 된다.

Free 리스트

Free 리스트는 버퍼 풀에서 실제 사용자 데이터로 채워지지 않은 비어 있는 페이지들의 목록으로, 사용자 쿼리가 새롭게 디스크의 데이터 페이지를 읽어와야 하는 경우에 사용된다.

LRU 리스트

가장 중요한 LRU 리스트에 대해서 자세히 알아보자.

LRU 리스트의 경우 LRU + MRU 리스트가 결합된 형태로, 위 그림에서 Old 서브 리스트 영역은 LRU, New 서브 리스트 영역은 MRU라고 생각하면 된다. 자주 접근되는 데이터 페이지를 New 서브리스트에 적재하고, 자주 접근되지 않는 데이터 페이지를 Old 서브리스트에 저장하는 것이다. 이는 한 번 디스크로부터 읽어온 페이지는 최대한 오랫동안 버퍼 풀이 관리하도록 해서 디스크로부터 다시 읽어오는 작업을 최소화하기 위해서이다.

LRU (Least Recently Used)
가장 오랜 시간 동안 참조되지 않은 페이지를 교체하는 정책

MRU (Most Recently Used)
가장 최근에 사용된 페이지를 교체하는 정책

여기서 New 서브 리스트의 Tail과 Old 서브 리스트의 head가 만나는 지점이 버퍼 풀 전체의 'MidPoint'라고 할 수 있으며, InnoDB가 새로운 데이터 페이지를 버퍼 풀로 읽어올 때 midPoint에 삽입하게 된다. (Old 서브리스트의 Head에 삽입)

만약 Old 서브리스트에 존재하는 페이지를 접근하면 해당 데이터 페이지는 'Young'이라고 판단되며, New 서브리스트의 head로 이동한다. 이때, 사용자가 작성한 쿼리나 실제로 필요해서 접근한 페이지는 바로 young이 되지만, read-ahead에 의해서 자동으로 읽어오는 데이터의 경우 young으로 판단되지 않는다.

Read-Ahead
사용될 것 같은 데이터 페이지에 대해 버퍼 풀로 동기화하는 I/O request를 의미한다. 이때, 비동기로 동작한다.
하나의 extent (64개의 페이지 그룹) 전체를 버퍼 풀에 prefetch 하게 되는데, 2개의 알고리즘을 사용한다.
- linear read-ahead / random read-ahead.
- 버퍼 풀 내에서 순차적으로 읽혀진 페이지의 개수로 판단하거나, 버퍼풀 내에 존재하는 페이지의 개수로 판단하거나.

이러한 과정을 반복하면서, 버퍼풀에 있는 데이터 중에서 자주 접근되지 않으면 young이 되는 페이지가 앞으로 이동하면서 자연스럽게 tail로 이동하게 된다. 또한, Old 서브리스트에 있는 페이지들은 새로운 페이지들이 계속 midPoint에 삽입되다 보니까 결국 tail 쪽으로 가까워지게 되고, 계속 접근되지 않으면 결국 삭제되는 것이다.

InnoDB에서 데이터 찾는 과정

1. 필요한 레코드가 저장된 페이지가 버퍼 풀에 존재하는지 검사한다.
- 어댑티브 해시 인덱스 / 테이블의 인덱스를 활용하여 버퍼 풀에서 페이지를 검색한다.
- 버퍼 풀에 이미 데이터 페이지가 존재한다면 해당 페이지의 포인터를 New 서브리스트 쪽으로 승급시킨다.

어댑티브 해시 인덱스 (Adaptive Hash Index)
자주 사용되는 컬럼을 해시로 정의하여 B-Tree를 타지 않고 바로 데이터로 접근할 수 있는 기능이다.
어댑티브 해시 인덱스의 경우 Innodb_buffer_pool_size의 1/64 정도의 크기로 초기화된다.

2. 디스크에서 필요한 데이터 페이지를 버퍼 풀에 적재하고, 적재된 페이지에 대한 포인터를 Old 서브리스트의 헤더 부분에 추가한다. (midPoint 삽입)

3. Old 서브리스트 헤더 부분에 적재된 데이터 페이지가 실제로 읽히면 New 서브리스트 헤더 부분으로 이동한다.
- 이때, 대량의 읽기 작업의 경우 데이터 페이지가 버퍼 풀에 적재는 되지만, 실제 쿼리상으로는 사용되지 않을 수 있기 때문에 New 서브 리스트의 헤더 부분으로 이동하지는 않는다.

4. 버퍼 풀에 상주하는 데이터 페이지는 사용자가 최근에 얼마나 접근했는지에 따라서 Age를 부여받으며, 쿼리에서 오랫동안 사용되지 않는다면 Age가 오래되기 때문에 (Aging) 버퍼 풀에서 제거된다. (Eviction)
- 만약, 버퍼 풀의 데이터 페이지가 쿼리에 의해서 사용되면 나이가 다시 초기화되기 때문에 New 서브리스트의 헤더 부분으로 옮겨진다.
- 결과적으로 최근에 얼마나 접근했는지에 따라서 Old / New 서브리스트로 이동하는 것이며, Old 서브리스트 끝으로 밀려난 데이터는 버퍼 풀에서 제거해서 새로운 데이터 페이지를 적재할 수 있는 빈 공간을 준비하게 된다.

5. 필요한 데이터가 자주 접근되는 데이터라면, 해당 페이지의 인덱스 키를 어댑티브 해시 인덱스에 추가한다.

결과적으로 처음에 한 번 읽힌 데이터 페이지가 자주 사용되면 New 서브리스트에서 계속 살아남게 되고, 거의 사용되지 않는다면 계속 밀려서 Old 서브리스트 끝으로 밀려나다가 버퍼 풀에서 제거된다.

Adaptive Hash Index (어댑티브 해시 인덱스)

https://tech.kakao.com/2016/04/07/innodb-adaptive-hash-index/

어댑티브 해시 인덱스는 사용자가 자주 요청하는 데이터에 대해서 자동으로 생성하는 인덱스이다.
자주 읽히는 데이터 페이지의 키 값을 이용해 해시 인덱스를 만들어서, 해당 인덱스를 기준으로 데이터 페이지를 바로 찾아가는 것이다.

해시 인덱스의 경우 인덱스 키 값과 인덱스 키 값이 저장된 데이터 페이지 주소의 쌍으로 관리되며, 인덱스 키 값은 B-Tree 인덱스의 고유 번호와 실제 값으로 이루어져 있다. 모든 B-Tree 인덱스에 대한 어댑티브 해시 인덱스는 하나의 해시 인덱스에 저장되어야 하기 때문에 B-Tree의 고유 번호를 통해 겹치지 않도록 만든 것이다.

버퍼 풀에 로딩된 페이지 주소를 사용하기 때문에 버퍼 풀에 올라간 데이터에 대해서만 관리된다.
그래서, 버퍼 풀에서 삭제되면 인덱스 정보 역시 함께 제거된다.
= 즉, 어댑티브 해시 인덱스는 버퍼풀에 올라간 데이터에 대해 더 빠르게 접근할 수 있도록 만든 것이다.

다음과 같은 상황에서 어댑티브 해시 인덱스는 도움이 된다.

- 디스크의 데이터가 innoDB 버퍼 풀의 크기와 비슷한 경우 (읽기 작업이 많지 않음)
- 동등 비교와 IN 연산을 통한 비교 작업이 많은 경우
- 쿼리가 일부 데이터만 집중되는 경우

하지만, 다음과 같은 경우에는 크게 의미있지 않기 때문에 잘 고려해서 사용하자.

- 디스크 읽기 작업이 많은 경우
- 특정 패턴의 쿼리가 많은 경우 (JOIN, LIKE 검색)
- 매우 큰 데이터를 가진 테이블의 레코드를 폭넓게 읽는 경우

⭐️ 어댑티브 해시 인덱스는 테이블을 삭제하거나 변경할 때 해당 테이블의 모든 데이터 페이지 내용을 어댑티브 해시 인덱스에서 제거해야 하다 보니 이럴 때는 CPU cost가 크다. 잘 고려해서 사용하자.

show engine innodb status;

위 사진은 innodb status를 확인했을 때의 결과이다. 현재는 별도의 작업을 하는 게 없어서 0으로 나오지만, 여기서 hash searches는 어댑티브 해시 인덱스를 사용한 결과를, non-hash searches는 사용하지 않은 결과이다.

(hash searches) / (hash searches + non-hash searches) * 100을 했을 때 100%에 가깝다면 어댑티브 해시 인덱스를 잘 사용하는 것이고, 낮다면 비활성화하는 것도 고려해보는 것이 좋다. 비활성화를 하게 되면 버퍼 풀은 더 많은 메모리를 사용할 수 있을 것이다.

# 어댑티브 해시 인덱스의 메모리 사용량
SELECT EVENT_NAME, CURRENT_NUMBER_OF_BYTES_USED
FROM performance_schema.memory_summary_global_by_event_name
WHERE EVENT_NAME='memory/innodb/adaptive hash index'

Change Buffer (체인지 버퍼)

체인지 버퍼는 특정 데이터 페이지가 버퍼 풀에 없을 때 secondary-index 페이지에 대한 변경 사항을 캐시하는 특수한 데이터 구조이다.

Secondary-index의 경우 유니크하지 않고, 임의의 순서로 삽입된다. insert, update 작업 시 데이터 파일뿐만 아니라 인덱스도 함께 업데이트하면서 랜덤하게 디스크를 읽어야 하기 때문에 비용이 많이 들게 된다. 이를 위해 변경해야 하는 인덱스 페이지가 버퍼 풀에 있으면 바로 업데이트를 수행하지만, 디스크로부터 읽어와서 업데이트해야 하다면 즉시 실행하지 않고 체인지 버퍼에 저장했다가 사용자에게 결과를 바로 반환하도록 최적화가 되어 있다.

⭐️ 단, 유니크 인덱스의 경우 중복 체크를 해야 하므로 체인지 버퍼를 사용할 수 없다.
체인지 버퍼에 저장된 인덱스 레코드는 백그라운드 스레드 중 '체인지 버퍼 머지 스레드 (Merge Thread)'에 의해서 병합된다.
innodb_change_buffering이라는 변수를 통해서 어떤 작업인지에 따라 체인지 버퍼를 활성화할 수 있다.

- all: 모든 인덱스 관련 작업 (inserts, deletes, purges) 버퍼링
- none: 버퍼링 X
- inserts: 새로운 아이템을 추가하는 작업만 버퍼링
- deletes: 기존 아이템을 삭제하는 작업만 버퍼링 (영구 삭제가 아닌, 삭제됐다고 마킹만 함)
- changes: inserts + deletes만 버퍼링
- purges: purges - 영구 삭제 작업만 버퍼링

체인지 버퍼의 경우 버퍼 풀의 25%~50%까지 사용할 수 있으며, 어느 정도 사용 중인지는 아래와 같이 확인할 수 있다.

select EVENT_NAME, CURRENT_NUMBER_OF_BYTES_USED
from performance_schema.memory_summary_global_by_event_name
where EVENT_NAME='memory/innodb/ibuf0ibuf';

Log Buffer (로그 버퍼)

로그 버퍼는 디스크의 로그 파일에 기록할 데이터를 보관하는 데이터 영역이다.
대부분의 데이터베이스 서버는 데이터의 변경 내용을 먼저 로그로 기록하는데, 이는 디스크에 바로 기록하는 것이 상당한 비용이 들기 때문이다. 또한, 리두 로그에 작성하면 비정상 종료 시 복구도 가능하기 때문에 상당히 중요하다.

흔히 비정상 종료된 이후, 일관되지 않은 데이터는 2종류로 나뉜다.
- 커밋은 됐지만 데이터 파일에 기록되지 않음
- 롤백은 됐지만 데이터 파일에 이미 기록이 되어버림

1번의 경우 리두 로그에 저장된 걸 기록하면 되고, 2번의 경우 변겨오디지 않은 데이터를 가져와서 기록해야 한다.
당연히 데이터의 일관성을 위해서라면 트랜잭션이 커밋될 때마다 리두 로그를 즉시 디스크에 기록하는 게 좋지만, 비용이 큰 디스크 작업 상 부하가 일어날 포인트이다. 이를 위해 innodb_flush_log_at_trx_commit 시스템 변수를 통해서 어느 정도 주기로 동기화할지 설정할 수 있다.

0: 1초에 한 번씩 리두 로그를 디스크로 기록 후 동기화
1: 트랜잭션이 커밋될 때마다 디스크로 기록 후 동기화 (기본값)
2: 트랜잭션이 커밋될 때마다 디스트 기록은 되지만, 동기화는 1초에 한 번씩

Log Buffer의 경우 디스크 영역에 있는 Redo Log와 밀접한 관계를 가지기 때문에 자세한 건 다음 포스팅에서 알아보자.

버퍼 풀 플러시

dirty page를 디스크에 동기화하는 것을 더티 페이지 플러시라고 한다.
InnoDB에서는 플러시 시 성능 문제를 고려하여 2가지의 방법을 제시하고 있는데, '플러시 리스트 플러시(Flush-List Flush)'와 'LRU 리스트 플러시 (LRU-List Flush)가 있다.

플러시 리스트 플러시

InnoDB는 리두 공간의 재활용을 위해서, 주기적으로 오래된 리두 로그 엔트리가 사용하는 공간을 비운다. 이때, 디스크로 동기화되는 작업이 꼭 선행되어야 하는데 Flush_List 함수를 호출해서 오래전에 변경된 데이터 페이지 순서대로 디스크에 동기화하는 작업을 수행한다. 해당 작업은 '클리너 스레드 (Cleaner Thread)'를 통해서 이루어진다.

이를 위해 다양한 시스템 변수들을 제공하는데, 이는 다음과 같다.

- innodb_page_cleaners
: 클리너 스레드의 개수를 조정한다. 버퍼 풀의 개수보다 많으면 innodb_buffer_pool_instances 값으로 변경된다.
더 적다면 하나의 클리너 스레드가 여러 개의 버퍼 풀을 처리하게 된다. (웬만하면 동일하게 하자.) 기본값은 4이다.

- innodb_max_dirty_pages_pct
: 버퍼 풀이 더티 페이지를 몇 퍼센트나 가지고 있을지 비율 설정 (클수록 여러 번의 디스크 쓰기를 한 번으로 최적화 가능)
최대 90%까지 가지고 있을 수 있다.

- innodb_max_dirty_pages_pct_lwm
: 디스크로 작성되는 페이지보다 버퍼 풀에 더 많은 더티 페이지가 존재하게 되면, 더티 페이지를 모두 디스크 페이지에 작성하기 위해서 디스크 쓰기 작업이 폭발할 수 있다. (즉, pages_pct로 정의한 임계값까지 도달하지 않도록 만드는 변수) 이를 막기 위해 일정 수 이상의 더티 페이지가 생기면 조금씩 디스크로 기록하는 '사전 플러시' 비율을 조정한다. 기본 값은 10%이다.

- innodb_io_capacity
: 일반적인 상황에서 어느 정도의 디스크 읽고 쓰기가 가능한지 설정. 여기서 말하는 디스크 작업은 '백그라운드 스레드'가 수행하는 작업이며, 대부분 더티 페이지의 쓰기 작업이 해당한다.

- innodb_io_capacity_max
: 최대의 성능을 발휘할 때 어느 정도의 디스크 읽고 쓰기가 가능한지 설정.

- innodb_flush_neighbors
: 디스크 기록 시 디스크에서 근접한 페이지에 더티 페이지가 있다면 함께 묶어서 기록하는 기능을 활성화할지 설정.
-이면 비활성화 (SSD 권장), 1이면 활성화 (HDD 권장), 2면 연속된 더티 페이지를 플러시하는 게 아닌, 그냥 하나만 플러시.

- innodb_lru_scan_depth
버퍼 풀 인스턴스마다 클리너 스레드가 더티 페이지 플러시를 위해 버퍼 풀 LRU 리스트를 얼마나 깊게 스캔할지 설정.
innodb_lru_scan_depth * innodb_buffer_pool_instances가 클리너 스레드가 1초에 수행하는 작업량을 정의한다.

- innodb_adaptive_flushing
: 어댑티브 플러시 활성화 여부 설정. 활성화 시 capacity, capacity_max 같은 시스템 변수 값을 의존하지 않고, 별도의 새로운 알고리즘을 사용하여 적절한 수의 더티 페이지가 버퍼 풀에 유지되도록 디스크 쓰기 작업을 수행한다.
버퍼 풀의 더티 페이지 수와 리두 로그 레코드의 생성 속도를 바탕으로 어느 정도의 더티 페이지를 플러시할지 알아서 결정한다.

- innodb_adaptive_flushing_lwm
: 활성 리두 공간이 n% 미만일 때 어댑티브 플러시를 활성화 할지 적용하는 값. 이 임계값을 넘게 되면 innodb_adaptive_flushing이 비활성화되어 있더라도 알아서 어댑티브 플러시를 적용하여 활성화한다.

LRU 리스트 플러시

LRU 리스트에서 사용 빈도가 낮으면 Old 서브리스트에서 밀려나다가 플러시되는 게 기억날 것이다. 이때 사용하는 게 LRU 리스트 플러시이며, innodb_lru_scan_depth 변수에 설정된 개수만큼 페이지를 스캔하며 더티 페이지를 디스크에 동기화한다.

플러시된 더티 페이지들의 프레임을 비운 다음, free 페이지로 만들어서 Free List에 삽입한다. 이때, 버퍼 풀 인스턴스별로 최대 설정한 개수만큼 스캔하기 때문에 innodb_buffer_pool_instances * innodb_lru_scan_depth 수만큼 수행된다.

버퍼 풀 상태 백업 및 복구

디스크의 데이터 버퍼 풀에 적재되어 있는 상태를 '워밍업'이라고 하는데, 잘 워밍업되어 있다면 당연히 쿼리 속도가 매우 증가한다.
하지만, 서버를 재시작하는 경우 적재되어 있는 게 없으니 처음에는 요청 속도가 매우 느리게 된다. 하지만, MySQL 5.6부터는 재시작 시 innodb_buffer_dump_now라는 변수를 통해서 현재의 버퍼 풀 상태를 백업할 수 있다. 백업 후 innodb_buffer_dump_load_now를 통해서 다시 복구가 가능하다!

# 백업하기
SET GLOBAL innodb_buffer_pool_dump_now = ON;
# 로드하기
SET GLOBAL innodb_buffer_pool_load_now = ON;

백업 시에는 적재된 데이터 페이지의 메타 정보만 가져와서 저장하기 때문에 실제 용량은 그렇게 크지 않으며 (ib_buffer_pool 파일 확인), 백업 속도도 빠르다. 하지만, 다시 로드할 때는 적재 작업을 재진행해야 하다 보니까 시간이 좀 걸릴 수 있다. 진행 상황을 확인하고 싶다면 아래와 같이 입력하자.

# 얼마나 복구되었는지 확인
SHOW STATUS LIKE 'Innodb_buffer_pool_dump_status'\G

만약 너무 오래 걸려서 참을 수 없다면 멈추자.

SET GLOBAL innodb_buffer_pool_load_abort = ON;

근데 이런 걸 수동으로 하는 건 쉽지 않다.
그래서 MySQL 서버가 셧다운 되기 전에 백업하고, 시작 시 자동으로 복구하도록 innodb_buffer_pool_dump_at_shutdown과 innodb_buffer_pool_load_at_startup을 설정 파일에 넣어두자. (기본적으로 활성화가 되어 있긴 하다 ㅎㅎ)

그렇다면, 버퍼 풀에는 어떤 내용이 적재되어 있을까?
아래는 테이블의 인덱스별로 데이터 페이지가 얼마나 innoDB 버퍼 풀에 적재되어 있는지를 나타낸다.

select
    it.NAME AS table_name,
    ii.NAME AS index_name,
    ici.N_CACHED_PAGES AS n_cached_pages
from information_schema.INNODB_TABLES it
inner join information_schema.INNODB_INDEXES ii on ii.TABLE_ID = it.TABLE_ID
inner join information_schema.INNODB_CACHED_INDEXES ici on ici.INDEX_ID = ii.INDEX_ID;

[Real MySQL 8.0] InnoDB 스토리지 엔진 알아보기 - 1편 (클러스터링 / 외래키 / MVCC)

dolmeng2 — Sun, 11 Jun 2023 16:32:44 +0900

InnoDB 스토리지 엔진 아키텍처

MySQL에서 가장 많이 사용하는 스토리지 엔진인 'InnoDB'에 대한 아키텍처를 알아보자.

그림이 복잡하기는 하지만, 왼쪽은 이전에 봤던 MySQL 엔진이고, 오른쪽이 InnoDB 스토리지 엔진의 구성도이다.
이번 포스팅에서는 innoDB 스토리지 엔진의 특징에 대해서 알아보도록 하자.

1. PK에 의한 클러스터링

기본적으로 InnoDB의 모든 테이블은 PK를 기준으로 클러스터링되어 저장된다.
여기서 클러스터링된다는 것은, PK 값이 비슷한 레코드끼리 묶어서 저장하는 것을 의미한다. PK 값이 레코드의 저장 위치를 결정하기 때문에 신중하게 결정해야 한다.
일반적인 DBMS에서 세컨더리 인덱스의 리프 노드에는 데이터의 실질적인 물리 주소가 들어가서, 해당 인덱스의 데이터를 바로 가지고 오지만 innoDB에서는 PK 값에 대한 주소를 가지고 있다. 그래서 사용 시 PK 값을 찾아나가게 된다. (세컨더리 인덱스 -> PK 값 -> 데이터)

세컨더리 인덱스란? (Secondary-Index)
PK 외의 정렬 기준이 필요할 때 사용되며, 하나의 테이블에 여러 개를 가질 수 있다.
순서를 가지지 않기 때문에 정렬되지 않아도 되며, unique 하지 않아도 된다는 점이 특징이다. (물론, 세컨더리 인덱스라고 했을 때 배표적인 예시로 유니크 키를 많이 뽑기는 한다.)
일종의 보조 역할을 하는 인덱스라고 생각하면 된다.

모든 세컨더리 인덱스가 PK 값을 가지고 있다고 생각하면 된다.
⭐️ 만약 innoDB 테이블을 생성할 때 PK를 지정하지 않으면 내부적으로 대체할 컬럼을 찾게 되는데, NOT NULL이면서 unique한 인덱스 중에서 첫 번째 것을 클러스터 키로 삼게 된다. (단, 내부적으로 관리되기 때문에 조회 불가)

반면에, MyISAM 스토리지 엔진에서는 클러스터링 키를 지원하지 않기 때문에 PK와 세컨더리 인덱스가 구조적으로 아무런 차이가 없다. 단지, PK는 unique하다는 조건이 추가된 세컨더리 인덱스와 동일해진다. 또한, MyISAM 테이블의 모든 인덱스는 물리적인 레코드 주소값 (ROW-ID)을 가지기 때문에, PK 값이 변한다고 해서 실제 데이터 레코드의 위치가 변하지 않는다.

2. 외래키 지원

MyISAM과 다르게 InnoDB의 경우 FK를 지원한다. 사실 실무에서는 외래키를 잘 걸지 않는다는 말을 많이 들어서 이게 큰 이점이 될지는 모르겠지만, 로컬 환경에서 개발할 때는 좋게 쓰일 것으로 생각된다.
만약 임시로 외래키 체크를 끄고 싶다면 다음 옵션을 사용하면 된다.

# 글로벌 설정
SET foreign_key_checks=OFF;

# 현재 작업을 진행하는 세션에 대해서만 끄기
SET SESSION foreign_key_checks=OFF;

해당 옵션을 끄게 되면 ON DELETE CASCADE, ON UPDATE CASCADE 같은 옵션은 사용할 수 없음을 유의하자.
참고로 외래키 옵션을 끈 뒤로 테이블에 대한 조작 작업을 했다면, 레코드 사이의 일관성이 깨지지 않았는지 잘 확인하고 다시 옵션을 켜야 한다.

3. MVCC (Multi Version Concurrency Control)

MVCC는 동시 접근을 허용하는 데이터베이스에서 동시성을 제어하기 위해 사용하는 방법 중 하나이다. 여기서 말하는 'Multi Version'의 경우 하나의 레코드에 대해서 여러 개의 버전을 동시에 관리한다는 의미이다. (레코드 접근 시점에 대한 스냅샷을 관리한다.)
일반적으로 레코드 레벨의 트랜잭션을 지원하는 DBMS가 지원하는 기능이며, 락을 사용하지 않으면서 일관된 값을 읽도록 만드는 것이 목적이다. InnoDB의 경우 Undo log를 활용하여 이 기능을 구현한다.

격리 수준이 READ_COMMITTED일 때 어떤 식으로 처리하는지 그림으로 알아보자.
⭐️ 참고로, InnoDB에서는 기본적으로 REPEATABLE_READ을 기본 격리 레벨로 사용한다.

READ_COMMITTED
특정 트랜잭션이 진행되는 동안 다른 트랜잭션은 해당 데이터에 접근할 수 없는 격리 레벨.
read 연산 시 실제 테이블 값을 가져오지 않고, Undo 영역의 백업된 레코드에서 값을 가져온다.
= 즉, 트랜잭션이 시작되기 전 데이터를 읽어오기 때문에 완전히 커밋된 데이터만 읽게 된다.
단, 커밋된 데이터만 읽기 때문에 동일한 select 쿼리를 날리더라도 같은 결과를 반환받지 못할 수도 있다.

CREATE TABLE `member` (
  `id` bigint NOT NULL AUTO_INCREMENT,
  `name` varchar(10) NOT NULL,
  `password` varchar(64) NOT NULL,
  PRIMARY KEY (`id`),
  INDEX KEY `name` (`name`)
) ENGINE=InnoDB;

위와 같이 간단하게 member에 대해 관리하는 테이블이 있다.
위 테이블에 다음과 같이 한 명의 멤버를 넣어보자.

insert into member(name, password) values ('journey', 'testpassword');

해당 레코드는 아래와 같이 관리된다.

PK와 name, password가 InnoDB 버퍼 풀과 디스크에 각각 저장된 것을 볼 수 있다.

만약, 해당 레코드에 업데이트가 일어났다면 어떻게 될까?

update member set password='realpassword' where id = 1;

update가 실행되면 변경 이전의 값을 undo 로그에 저장하고, 버퍼 풀에는 업데이트된 새로운 값으로 수정된다.
디스크의 경우 InnoDB의 백그라운드 스레드 중 쓰기 스레드 (Write)에 의해서 새로운 값으로 업데이트되며, 이때 ACID를 보장하기 때문에 일반적으로는 버퍼 풀과 데이터 파일이 동일하게 된다. (시점에 따라서 업데이트되기 전일수도 있지만)

그리고, 이 상태에서 select 쿼리를 날리게 되면 격리 레벨에 따라서 어디에 있는 데이터를 조회할지 달라진다. 만약 read_uncommitted라면 버퍼 풀에 있는 데이터를, read commmitted 이상의 레벨이라면 undo 로그에 있는 데이터를 읽게 된다.
이렇게 하나의 레코드에 대해서 여러 개의 버전 (버퍼 풀, 언두 로그)를 관리하기 때문에 'MVCC'라고 표현하며, 필요에 따라서 어떤 데이터가 보여질지 달라지게 됨을 의미한다.

이후 커밋이 일어나면, 해당 트랜잭션의 undo 로그가 더 이상 필요하지 않을 때 undo 로그를 제거하게 된다.
보통 undo 영역은 일정 크기로 유지되기 때문에 가장 오래된 undo 세그먼트는 제거되거나, 혹은 정책에 의해서 관리된다.

만약, 위 상황에서 롤백이 일어난다면 어떻게 될까?

위와 같이 undo 영역에 있는 값을 복구하고, undo 영역에 있는 값을 제거하게 된다.

4. 잠금 없는 일관된 읽기 (Non-Locking Consistent Read)

앞서 말한 MVCC 덕분에 InnoDB의 경우 락 없이도 일관된 읽기를 제공할 수 있다.
여기서 말하는 '일관된 읽기'란, 격리 레벨이 READ_UNCOMMITTED / READ_COMMITTED / REPEATABLE_READ일 때 순수한 읽기 작업은 다른 트랜잭션의 변경 작업과 관련 없이 undo 영역의 값을 읽으면서 바로 실행됨을 의미한다.

하지만, 이를 위해 undo 영역의 값을 바로 삭제하지 못하고 계속 유지해야 하기 때문에 트랜잭션의 범위가 커질수록 MySQL의 서버가 느려지거나 문제가 발생할 수 있어서 주의해야 한다. (트랜잭션은 가능한 짧게 가져가는 게 좋다.)

READ UNCOMMITTED
커밋, 롤백 여부와 상관없이 다른 트랜잭션의 값을 읽을 수 있는 격리 레벨.
이미 롤백이 되었는데도 해당 값을 읽을 수 있기 때문에 주의해야 한다. (Dirty read)

REPEATABLE_READ
트랜잭션마다 ID를 부여하여, 실행 중인 트랜잭션 ID보다 작은 ID를 가진 트랜잭션의 변경 사항만 읽는 격리 레벨.
Undo 영역에 백업된 모든 레코드는 변경을 발생시킨 트랜잭션의 번호를 추가로 관리하고, 특정 트랜잭션보다 앞 번호의 레코드에서만 변경된 내용을 읽도록 만든다.
그래서 실행 중인 트랜잭션 중에서 가장 오래된 트랜잭션 번호보다 앞에 있는 Undo 영역의 데이터는 삭제할 수 없다.
하지만, 다른 트랜잭션에 의해서 값이 삽입되거나 변경되었을 때 해당 쿼리 전후로 select한 조회 결과가 달라질 수 있다. (Phantom read) -> InnoDB에서는 Next Key Lock을 활용하여 발생하지 않도록 만들었다.

SERIALIZABLE
작업이 시작된 트랜잭션이 가지고 있는 레코드는 다른 트랜잭션에서 접근할 수 없는 격리 레벨.
읽기 작업에도 락이 필요하기 때문에 데이터의 정합성은 보장하지만, 처리 성능이 굉장히 떨어진다.

- 락에 대해서는 다음에 자세히 다룰 예정이니 이번에는 넘어가자

5. 자동 데드락 감지

InnoDB에서는 교착 상태 감지를 위해서 락에 대한 대기 목록을 그래프 (Wait-for List) 형태로 관리한다.
- 여기서 교착 상태(데드락)란, 서로 다른 트랜잭션이 서로 필요한 락을 가지고 있어서 서로 무한하게 대기하고 있는 상태.

교착 상태의 경우 트랜잭션이 여러 테이블의 행에 대해 락을 거는 경우 (update나 select for update 구문 등을 통해서) 발생할 수 있는데, 이때 테이블 수준의 락을 위해서 테이블에 대한 잠금 목록을 관리한다. 이때, 두 번째 트랜잭션이 해당 레코드를 업데이트하거나, 이미 락이 걸린 테이블에 대해 다시 락을 획득하려고 하면, InnoDB는 해당 레코드에 대한 락 요청을 대기 목록에 추가한다. 최종적으로 락을 얻기 위해서는 레코드에 걸려있는 모든 락이 제거되어야만 얻을 수 있게 된다.

아래와 같이 information_schema / performance_schema DB를 확인하게 되면 트랜잭션에 대한 상태를 확인할 수 있다.

# 트랜잭션 상태 확인
select * from information_schema.INNODB_TRX;

# 현재 실행 중인 트랜잭션에서 잠금을 획득한 데이터나 유형, 트랜잭션 정보 확인 (MySQL 8.0부터)
# 어떤 트랜잭션의 어떤 데이터가 락이 걸린 상태인지 확인 가능
select * from performance_schema.data_locks;

# 락 대기 요청 목록 확인 (MySQL 8.0부터)
# 어떤 트랜잭션이 다른 트랜잭션의 락을 대기 중인지 확인 가능
select * from performance_schema.data_lock_waits;

데드락을 줄이기 위해서는 테이블 자체에 락을 거는 것보다는 트랜잭션 자체를 작게 유지하는 것이 좋다. 여러 트랜잭션이나 여러 테이블이 동시에 레코드를 업데이트한다면, 최대한 해당 트랜잭션들이 변경하는 레코드의 순서들을 일관되게 (동일한 순서로 업데이트되도록) 만드는 것이 좋다.

데드락 감지 스레드

InnoDB의 경우 내부적으로 데드락 감지 스레드를 가지고 있으며, 해당 스레드는 그래프를 정기적으로 검사하여 교착 상태에 빠진 트랜잭션을 찾아 강제로 종료한다. 이때, Undo 로그의 양이 더 적은 트랜잭션을 롤백 대상으로 설정하게 된다.

참고로, InnoDB 스토리지 엔진이 아닌 MySQL 엔진 위에서 잠금된 테이블 (LOCK TABLES)은 볼 수가 없기 때문에 데드락에 대한 감지가 불확실할 수도 있지만, innodb_table_locks 변수를 활성화하면 레코드 락뿐만 아니라 테이블 락까지 감지가 가능해진다. (웬만하면 활성화하도록 하자.)

하지만, 만약 동시에 처리하는 스레드가 매우 많거나 하나의 트랜잭션에서 가지고 있는 락이 매우 많아진다면 데드락 감지 스레드 역시 느려진다. 이는 데드락 감지 스레드가 잠금 상태가 변경되지 않도록 잠금 목록이 저장되어 있는 테이블에 새로운 락을 걸고 스레드를 찾기 때문에, 데드락 감지 스레드가 느려지면 실제 비즈니스 로직을 처리하는 스레드 역시 락에 걸려서 계속 대기 상태에 빠질 수도 있다.

이를 위해서 MySQL 서버는 innodb_deadlock_detect라는 변수를 제공하고 있으며, 해당 변수를 OFF로 하면 데드락 감지 스레드가 더 이상 동작하지 않게 된다. 하지만, InnoDB 스토리지 엔진 내부에서 데드락이 발생하더라도 중재하는 스레드가 없으니 무한정 대기하기 때문에 innodb_lock_wait_timeout 변수를 활성화하여 일정 시간이 지나면 자동으로 요청이 실패하고 에러 메시지를 반환하도록 만들어야 한다. 즉, 데드락 감지 스레드 자체가 성능에 영향을 끼친다면 해당 스레드를 사용하지 않는 대신, 일종의 ttl을 통해 대기하도록 만드는 전략인 것이다. 기본값은 50초인데, 훨씬 더 낮은 시간을 사용하는 게 좋다.

6. 자동화된 장애 복구

InnoDB에는 손실이나 장애로부터 데이터를 보호하기 위한 매커니즘이 탑재되어 있다.
기본적으로 MySQL 서버가 시작될 때 항상 자동 복구를 수행하기 때문에, 복구 불가능한 손상이 있다면 자동 복구를 멈추고 MySQL 서버 자체를 종료해버린다. (이때는 innodb_force_recovery 변수를 통해서 서버를 재시작해야 한다.) 재시작 후 mysqldump를 통해 가능한 데이터를 백업하고 서버와 DB를 재생성하자.

아래는 innodb_force_recovery 변수값에 따른 복구 모드 전략이다.

- 1 (SRV_FORCE_IGNORE_CORRUPT)
테이블스페이스의 데이터나 인덱스 페이지에서 손상된 부분이 발견되어도 무시하고 재시작.
테이블의 데이터 파일이 손상됐다면 사용하자.

- 2 (SRV_FORCE_NO_BACKGROUND)
백그라운드 스레드 중 메인 스레드를 시작하지 않고 재시작.
이는 메인 스레드가 undo 영역을 주기적으로 비울 때 장애가 발생했다면 사용하자.

- 3 (SRV_FORCE_NO_TRX_UNDO)
커밋되지 않고 종료된 트랜잭션은 그대로 남아있도록 재시작.
innoDB에서는 트랜잭션 실행 시 롤백에 대비하여 변경 전의 데이터를 undo 영역에 기록하고, 서버 재시작 시 undo 영역의 데이터를 우선적으로 데이터 파일에 적용하는데 보통 커밋되지 않은 데이터는 롤백을 한다.
이때 롤백을 하지 않고 재시작을 하는 전략이다.

- 4 (SRV_FORCE_NO_IBUF_MERGE)
인서트 버퍼의 내용을 무시하고 강제로 재시작.
innoDB는 CUD 작업으로 인해 인덱스가 변경 작업을 바로 처리하거나 인서트 버퍼에 저장해두고 나중에 데이터 파일에 merge하거나, 둘 중 하나를 채택하는데 만약 인서트 버퍼가 손상되었다면 사용하는 전략이다.

- 5 (SRV_FORCE_NO_UNDO_LOG_SCAN)
undo 로그를 모두 무시하고 재시작.
innoDB에서는 MySQL 재시작 시 undo 영역에 있는 데이터를 이용하여 복구하고, redo 로그를 활용하여 종료 시점이나 장애 시점의 상태를 재현하며, 커밋되지 않은 트랜잭션에서 변경한 작업은 모두 롤백 처리되는데, 이러한 undo 로그가 손상되었을 때 사용하는 전략이다. 단, 이 전략을 사용하면 커밋되지 않은 작업도 모두 커밋된 것처럼 처리되기 때문에 주의해야 한다.

- 6 (SRV_FORCE_NO_LOG_REDO)
redo 로그를 모두 무시하고 재시작.
커밋되었거나 redo 로그에만 기록되고 데이터 파일에 기록되지 않은 데이터는 모두 무시되며, 마지막 체크포인트 시점에서의 데이터만 남게 된다.

다음 포스팅에서는 innoDB의 핵심 부분인 버퍼 풀에 대해서 알아보도록 하자.

[Real MySQL 8.0] MySQL 엔진과 스토리지 엔진, 쿼리 실행 처리 순서

dolmeng2 — Sun, 11 Jun 2023 00:30:27 +0900

MySQL 전체 구조

MySQL 서버는 크게 MySQL 엔진과 스토리지 엔진으로 나눌 수 있다.

MySQL 엔진의 경우 클라이언트로부터 접속하고, 쿼리 요청을 처리하는 커넥션 핸들러와 SQL 파서, 옵지마이저로 이루어져 있다.
쿼리 관련 처리는 이곳에서 하기 때문에, 거의 '두뇌'와 같은 역할을 하면 된다고 생각하자.

스토리지 엔진의 경우 데이터를 실제 디스크에 저장하거나, 혹은 디스크에 저장된 데이터를 읽어오는 작업을 하며 하나의 MySQL 서버는 여러 개의 스토리지 엔진을 사용할 수 있다.

MySQL 엔진과 스토리지 엔진은 서로 '핸들러 API'라는 것을 사용하여 데이터를 주고받으며, 어느 정도의 데이터 작업이 일어났는지 확인하고 싶다면 아래와 같이 명령어를 입력하면 된다.

show global status like 'handler%';

요렇게 다양한 핸들러 API들을 확인할 수 있다.

MySQL Thread

MySQL 서버는 기본적으로 스레드 기반으로 동작하며, Foreground / background 스레드로 나누어져 있다.
아래와 같이 입력하면 현재 실행 중인 스레드 목록을 확인할 수 있다.

select thread_id, name, type, processlist_user, processlist_host
from performance_schema.threads order by type, thread_id;

엄청 많기는 한데, 현재 나는 38개의 스레드가 실행 중인 것을 볼 수 있었다.
여기서 4, 5행을 보면 동일한 스레드 이름을 가진 것을 볼 수 있는데, 이는 여러 스레드가 동일한 작업을 병렬로 처리할 때 나온다.

특히 마지막 3개는 foreground로 동작하고 있으며, 이 중에서 thread/sql/one_connection이 실제로 사용자의 요청을 처리하는 foreground 스레드이다.

Foreground Thread

foreground thread의 경우 최소 MySQL에 접속된 클라이언트 수만큼 존재하며, 클라이언트가 요청하는 쿼리문을 수행한다.
데이터를 MySQL의 데이터 버퍼나 캐시로부터 가져오고, 없으면 직접 디스크에 있는 데이터를 가져오거나 인덱스 파일로부터 파일을 읽어온다. 이때, MyISAM 같은 스토리지 엔진은 디스크 쓰기 작업까지 foreground가 하지만, InnoDB의 경우 데이터 버퍼 / 캐시까지만 관리하고 디스크 쓰기는 background가 처리한다.

실행 후 커넥션 종료 시 해당 스레드는 스레드 캐시로 돌아가는데, 만약 스레드 캐시에 이미 일정 개수 이상의 대기 중인 스레드가 있으면 스레드 캐시에 넣지 않고 스레드 자체를 종료시켜서 스레드 캐시에 존재하는 스레드 수를 관리하는 역할도 한다.
보통, 해당 스레드 수는 thread_cache_size라는 시스템 변수로 컨트롤이 가능하다.

Background Thread

InnoDB 스토리지 엔진의 경우 백그라운드 스레드가 정말 여러 가지를 처리한다.

- 인서트 버퍼 (insert buffer) 병합
- ⭐️ 디스크에 로그 기록 (Log Thread)
- ⭐️ 버퍼 풀 (buffer pool)의 데이터를 디스크에 기록 (Write Thread)
- 데이터를 버퍼로 읽어오기
- 잠금, 데드락 모니터링

여기서 중요한 log / write thread의 경우 innodb_write_io_threads, innodb_read_io_threads 시스템 변수로 스레드 개수를 제어할 수 있다. 쓰기 스레드의 경우 2~4개, 별도의 스토리지 사용 시 디스크를 최적으로 사용할 만큼 설정하는 것이 좋다.

추가로, 데이터 쓰기 작업은 지연이 가능하지만 읽기 작업은 지연 처리가 안 되기 때문에 보통 DBMS에서 쓰기 작업은 버퍼링을 통해 일괄 처리하는 기능이 존재한다. 덕분에 CUD 쿼리 작성 시 디스크에 반영될 때까지 완전히 기다릴 필요가 없다. (InnoDB) 하지만, MyISAM에서는 포그라운드 스레드가 쓰기 작업까지 하다 보니까 쓰기 버퍼링 기능을 사용할 수 없다.

MySQL Memory Allocation

MySQL에서 사용하는 메모리 공간은 크게 글로벌 메모리 영역과 세션 메모리 영역 (=로컬 메모리 영역)으로 구분된다.

글로벌 메모리 영역의 경우 MySQL 서버가 시작되면서 OS로부터 할당되며, OS마다 조금씩 정책이 다르다. 글로벌 메모리 영역은 단 하나의 메모리 공간만 할당받으며, 모든 스레드에게 공유된다.

반면, 세션 메모리 영역의 경우 스레드당 하나씩 생성되며, 공유되지 않고 사용된다.
쿼리의 용도별로 공간이 할당되고, 필요하지 않으면 아예 메모리 공간 자체가 생성되지 않을 수도 있기 때문에 (정렬이나 조인 버퍼 같은 경우) 주의해야 한다.

MySQL에서의 쿼리 실행 과정

⭐️ SqL 파서 -> SQL 옵티마이저 -> SQL 실행기 -> 데이터의 읽기/쓰기 작업 -> 디스크

MySQL에서는 MySQL 엔진에 의해 SQL 실행기까지 실행되고, 마지막으로 디스크에 데이터를 읽거나 쓰는 작업은 스토리지 엔진이 처리한다. 어떤 스토리지 엔진을 사용하든 MySQL 엔진이 실행하는 부분은 대부분 비슷하며, 어떤 식으로 디스크에 데이터를 읽고 쓰는지가 스토리지 엔진별로 갈린다고 생각하면 된다. 이때, 데이터를 읽고 쓰는 작업은 대부분 1건의 레코드 단위로 처리된다.
이때, MySQL 엔진은 스토리지 엔진을 조정하기 위해 '핸들러'라는 것을 사용한다. (추후 다시 다룰 예정이다.)

SHOW ENGINES;

이거는 MySQL 서버에서 지원하는 스토리지 엔진의 목록이다. 여기서 support 컬럼에는 4가지의 옵션이 있는데, 다음과 같다.

- YES: MySQL 서버에 포함되어 있고, 사용 가능으로 활성화
- DEFAULT: YES와 동일한데 필수 스토리지 엔진임
- NO: MySQL 서버에 포함 X, 사용 시 재빌드 진행해야 함
- DISABLED: MySQL 서버에 포함은 되어 있는데 비활성화

또한, MySQL 서버에는 여러 플러그인도 있기 때문에 확인하고 싶다면 show plugins으로 확인하면 된다!
참고로, MySQL 8.0부터는 컴포넌트 아키텍처라는 것을 지원하는데, 이는 플러그인의 단점을 보완하기 위해 구현되었다.

- 플러그인은 오직 MySQL 서버와 인터페이스가 가능하고, 플러그인끼리는 통신이 불가능함
- MySQL 서버의 변수나 함수를 직접 호출하기 때문에 안전하지 않음
- 상호 의존 관계를 설정할 수 없어서 초기화가 어려움

설치된 컴포넌트는 아래와 같은 명령어로 확인이 가능하다.

select * from mysql.component;

MySQL Query Execution

MySQL에서 쿼리를 실행하는 구조이다. 차례로 따라가보자.

쿼리 파서 (SQL Parser)

사용자 요청으로 들어온 쿼리 문장을 Token으로 분리하여 트리 형태의 구조로 만들어내는 작업을 의미한다.
쿼리 문장의 기본적인 문법 오류는 이 단계에서 발생하며, 이 경우 오류 메시지가 사용자에게 나가게 된다.

전처리기

파서를 통해 나온 트리를 바탕으로 쿼리 문장에 구조적인 문제가 있는지 확인한다.
테이블 이름이나 컬럼 이름, 내장 함수 존재 여부, 객체의 접근 권한 등을 여기에서 확인한다.

옵티마이저

쿼리 문장을 가장 저렴한 비용으로 처리하기 위한 최적화를 진행한다. 매우 중요한 과정이다.

실행 엔진

핸들러에게 요청해서 받은 결과를 사용자나 또 다른 핸들러의 요청에 대한 입력으로 연결하는 역할을 수행한다.
핸들러는 실제로 일을 처리하는 역할을 수행하고, 실행 엔진이 옵티마이저와 실행기 사이에서 연결하는 역할을 한다.

ex) group by 처리 과정
실행 엔진이 핸들러에게 임시 테이블 생성 요청
-> 실행 엔진은 where절에 대한 레코드를 읽으라고 핸들러에게 요청
-> 읽어온 테이블을 임시 테이블에게 저장하라고 핸들러에게 요청
-> 생성된 임시테이블에 대해 필요한 방식으로 데이터를 읽어오라고 핸들러에게 요청
-> 최종 결과를 실행 엔진이 사용자나 다른 핸들러에게 넘긴다.

핸들러 (=스토리지 엔진)

실행 엔진의 요청에 따라서 데이터를 디스크로 저장하거나 디스크로부터 읽어오는 역할을 진행한다.
어떤 스토리지 엔진을 가진 테이블을 처리하는지에 따라서 InnoDB 엔진을 사용할지, MyISAM 엔진을 사용할지 (혹은 그외) 채택하게 된다.

쿼리 캐시

그림에는 없지만, MySQL의 쿼리 캐시는 SQL 실행 결과를 메모리에 캐시하고 동일한 쿼리가 실행되면 테이블을 읽는 대신에 메모리에 저장된 결과를 바로 반환하는 역할을 한다.
하지만, 테이블의 데이터가 변경되면 캐시도 함께 갱신되어야 하기 때문에 변경된 테이블에 관련된 내용은 전부 삭제했어야 했다. 전부 삭제하다 보니 성능상에도 치명적인 문제가 생겨, 8.0부터는 쿼리 캐시 기능 자체가 제거되었다.

스레드 풀

MySQL 엔터프라이즈 버전에서는 스레드 풀 기능을 지원한다. 여기서는 Percona Server에서 제공하는 스레드 풀 기능을 살펴보자.
스레드 풀의 경우 동시에 실행 중인 스레드를 CPU가 최대한 잘 처리할 수 있는 수준까지 줄여서 빠르게 처리하도록 만드는 기능이기 때문에, CPU 시간을 잘 확보하지 못한다면 오히려 쿼리 처리가 느려질 수도 있다.

thread_pool_size
Percona Server에서는 기본적으로 CPU 코어 수만큼 스레드 그룹을 생성하며, thread_pool_size 시스템 변수를 수정하여 조정이 가능하다.

thread_pool_oversubscribe
만약, 이미 스레드 풀이 처리하는 작업이 있으면 thread_pool_oversubscribe 변수를 통해 얼마나 더 추가로 처리할지 받아들일 수 있다. (물론, 무작정 늘려도 좋지 않다. 그만큼 스케줄링해야 하는 스레드 수가 많아진다.) 기본값은 3이다.

thread_pool_stall_limit
스레드 그룹 내의 모든 스레드가 일을 처리하고 있다면 해당 스레드 그룹에 새로운 Worker Thread를 추가할지, 아니면 기존 작업이 끝날 때까지 기다릴지 판단해야 한다. 스레드 풀 내의 타이머 스레드는 스레드 그룹의 상태를 주기적으로 체크하여 thread_pool_stall_limit 변수에 정의된 초만큼 작업 스레드가 처리 중인 작업이 끝나지 않았을 때 새로운 스레드를 생성해서 추가하도록 만든다. 당연하게도 이 수는 할당 가능한 전체 스레드 수 (thread_pool_max_threads)를 넘을 수 없다.

- 그렇다면, thread_pool_stall_limit을 0으로 생성해서 바로 스레드를 생성하도록 만드는 게 좋지 않을까?
이것은 아니다. 스레드 풀을 사용하는 의미 자체가 없어지는 것과 동일하다. (계속 새롭게 만드니 풀이 의미가 없어짐)

선순위 / 후순위 큐
Percona Server에서는 선순위 / 후순위 큐를 통해서 특정 트랜잭션이나 쿼리를 우선으로 처리하도록 만드는 기능도 있다. (thread_pool_high_prio_tickets)

이는 동시에 실행되는 쿼리의 수를 제한하며, 열려 있는 트랜잭션의 수를 낮추기 위해 사용한다.
새로운 커넥션이 생성될 때마다 '우선순위 티켓' 같은 것을 할당하여 선순위 큐에 들어갈 수 있도록 만들며, 기본적으로 이미 시작된 커넥션의 경우 선순위 큐에 들어가게 된다. 만약 모든 커넥션에 대해 이런 스케줄링을 사용하고 싶지 않다면, 변수 값을 0으로 할당하고, 값이 클수록 각각의 트랜잭션은 선순위 큐에 들어갈 기회를 더 많이 얻게 된다.

반대로, 모든 워크 스레드 수가 oversubscribe까지 도달하게 된다면 우선순위가 낮은 커넥션을 제한하여서 방지할 수 있다. 이미 시작된 트랜잭션을 우선으로 처리하고, 해당 트랜잭션이 처리될 때까지 새로운 트랜잭션을 시작하지 않아서 스레드 그룹이 과다하게 사용되는 것을 제한하는 것이다.

트랜잭션 지원 메타데이터

DB 서버에서 테이블의 구조 정보와 스토어드 프로그램 등의 정보를 데이터 딕셔너리 or 메타데이터라고 한다.
MySQL 5.7까지는 FRM 파일에 테이블의 구조 정보를 관리했으나, 이는 MySQL 서버가 비정상적으로 종료되거나 생성, 변경 시 트랜잭션을 지원하지 않아서 일관성이 자주 깨지는 현상이 발생하였다.
그래서 8.0부터는 모두 InnoDB 테이블에 저장되며, '시스템 테이블' 같은 형태로 관리된다.

show databases;

실제로, show databases를 입력했을 때 나오는 'mysql'이라는 DB에 저장되는 것을 확인할 수 있다.
(mysql.ibd라는 테이블스페이스에 저장되기 때문에 해당 파일에 대해 관리가 필요하다!)

여기서 의문인 점은, use tables를 통해 확인해도 실제 테이블의 구조가 저장된 테이블을 볼 수 없다는 것이다.
이는 사용자가 직접 임의로 수정할까봐 조회 불가능하게 만든 것이며, 이 대신에 information_schema DB를 통해서 확인하도록 만들었다.

select * from information_schema.tables;

실제로 이렇게 내가 생성했던 테이블의 정보를 조회할 수 있는 것을 확인할 수 있다.

select * from mysql.tables;

반면에, mysql DB를 통해서 테이블 목록을 확인하려고 보면 위와 같이 권한이 없다는 문구가 뜬다!

그렇다면, 이렇게 innoDB 테이블로 관리되면 어떤 것이 좋을까?
바로, '원자성'을 만족할 수 있다는 점이다.
테이블로 관리된다는 것은 설정정보가 테이블에 커밋되거나, 혹은 롤백 (Atomicity)되는 것을 보장할 수밖에 없기 때문에 기존처럼 파일로 관리했을 때와 다르게 데이터의 일관성이 깨지는 일이 발생하지 않는 것이다.
하지만, innoDB가 아닌 다른 스토리지 엔진을 사용하는 테이블의 경우, 여전히 메타 정보를 SDI 파일으로 관리하기 때문에 유의해야 한다.

다음 포스팅부터 InnoDB 스토리지 엔진에 대해서 알아보도록 하자.

[Spring] 에러 로깅하기 - Logback을 사용해서 ERROR 레벨만 파일로 로그를 남겨보자!

dolmeng2 — Mon, 5 Jun 2023 19:36:16 +0900

들어가기 전

이번 장바구니 미션에서는 프론트 크루들과 협업을 해야 했기 때문에 앞으로 에러 로그를 볼 일이 많아질 것 같다고 생각했다.

배포 스크립트를 작성하면서 스프링이 띄워질 때의 로그는 볼 수 있었지만, 에러에 대한 로그만 빠르게 확인하면 좋을 것 같아서 이번 미션에 나름의 삽질을 곁들여가며 적용해보았다

문제 상황

배포 스크립트를 작성하며 아래의 문장이 나를 혼란스럽게 했다.

nohup sudo java -jar $JAR_NAME >> $REPOSITORY/deploy.log 2> $REPOSITORY/deploy-err.log &

nohup : 터미널을 종료해도 계속 실행하기.

java -jar $JAR_NAME : jar 파일 실행하기.

>> : 출력 리다이렉션. jar의 실행 결과를 파일로 저장하고 싶어! (deploy.log 파일로 저장)

- 참고로, >>의 경우 기존의 파일에 내용을 추가하는 것이고 새롭게 덮어씌우고 싶다면 >을 사용하자.

⭐️ 2> : 표준 오류 출력 리다이렉션. jar의 실행 결과 중 '표준 오류'에 대해서 deploy-err.log 저장하기

& : 백그라운드로 실행하기. 기본적으로 쉘은 명령어가 종료될 때까지 계속 대기하기 때문에 백그라운드로 실행하여 다른 작업도 진행할 수 있도록 만들기.

나는 여기서 2> $REPOSITORY/deploy-err.log 이 친구 때문에 스프링에서 에러 로그가 발생하면 deploy-err.log로 저장될 것이라고 생각했다. 하지만... 아무리 해도 아무것도 저장이 되지 않아서 절망하고 있었다.

이는, 2>가 '표준 오류 출력'에 대해서 리다이렉션을 하는 것이기 때문이다.

표준 오류 출력이 뭘까?
보통 쉘에서 명령어를 실행하게 되면, 해당 명령어에 대한 출력은 표준 출력 (STDOUT)을 통해 나오게 된다.
하지만, 해당 명령어를 실행하는 도중에 발생하는 오류나 경고, 예외 메시지의 경우 표준 출력 (STDERR)을 통해 나오게 되는데, 예를 들어 파일을 찾을 수 없거나, 잘못된 명령어를 입력하는 것 같은, '명령어를 실행하는 도중'에 발생한 오류에 대해서 관리하게 된다.

나는 스프링에서 아래와 같이 에러에 대한 로그 핸들링을 하고 있었다.

@ControllerAdvice
public class ControllerExceptionHandler {

    private final Logger log = LoggerFactory.getLogger(getClass());

    @ExceptionHandler(Exception.class)
    public ResponseEntity<Void> exception(Exception e) {
        log.error(e.getMessage(), e);
        return ResponseEntity.status(HttpStatus.BAD_REQUEST).build();
    }
}

물론, 추후 기능을 개발하면서 고도화하겠지만 우선 모든 예외에 대해 로그 처리를 하기 위해서 이렇게 진행하였다.

여기서 log.error()를 사용하여 출력한 것은 단순히 로깅 라이브러리에서 제공하는 기능을 통해 오류 레벨의 로그를 기록하게 되며, 실제 출력 대상은 별도의 설정을 통해서 처리해줘야 하는 것이었다.

그래서, 만약 스프링에서 표준 에러로 출력하고 싶다면 아래와 같이 진행하면 된다.

@ControllerAdvice
public class ControllerExceptionHandler {

    private final Logger log = LoggerFactory.getLogger(getClass());

    @ExceptionHandler(Exception.class)
    public ResponseEntity<Void> exception(Exception e) {
        System.err.println(e);
        return ResponseEntity.status(HttpStatus.BAD_REQUEST).build();
    }
}

The "standard" error output stream.
This stream is already open and ready to accept output data.

err에 대해서 위와 같이 '표준 에러' 출력 스트림으로 지정한다고 되어 있다.

하지만... System.out.println을 통해서 로깅 처리를 안 하듯이, 에러 역시 저런 식으로 처리하는 것을 두고 볼 수 없다.

근데 왜 System.out.println을 쓰면 안 될까?

로깅 라이브러리는 로그 출력 레벨을 통해 개발 환경에 따른 로그 레벨을 적용할 수 있지만, System.out.println은 그런 게 안 된다.

모두 동일한 로그가 출력되다 보니 로컬 환경에서는 debug 레벨부터, 프로덕션 환경에서 warn 레벨부터 볼 수 있도록 조절할 수 없다는 것이다.

또한, 내부적으로 synchorized를 통해 멀티 스레드 환경에서는 락이 걸리기 때문에 성능적으로도 문제가 생긴다고 한다.

자세한 건 이 레퍼런스에서 더 참고해도 좋을 것 같다

그렇다면, 우리는 어떻게 에러에 대한 로깅을 진행해야 할까?

Logback 활용하기

바로, Logback이라는 친구를 활용하는 것이다.

Logback은 대표적인 로깅 프레임워크 중 하나로, Log4j를 대체하기 위해서 나왔다고 한다.

스프링부트의 경우 기본적으로 지원하고 있기 때문에 별도의 dependency를 설정해줄 필요가 없어서 간편하다.

기본적으로 Logback의 경우 Logger, Appender, Layout이라는 3가지의 클래스로 구성되어 있다.

Logger: 로그 메시지에 대한 일종의 컨텍스트로, 애플리케이션이 로그 메시지를 생성하기 위해 상호작용하는 클래스이다.

Appender: 로그 메시지를 배치하는 역할로, Logger는 둘 이상의 Appender를 가질 수 있다.

Layout: 출력될 메시지를 준비하며, 메시지 포매팅을 위한 클래스 생성을 지원한다.

또한, '로그 레벨'이라는 개념을 이해해야 하는데, Logback의 로그 레벨은 총 5단계로 구성되어 있다.

Trace - Debug - info - Warn - Error 순이며, 보통 다음과 같은 의미를 가진다.

TRACE: 애플리케이션 내부의 작은 단위 동작이나 메서드 호출, 변수 값 등에 대한 정보를 모두 포함한다. (엄청 방대한 양의 로그가 쌓이게 된다.) 로컬 개발 환경에서 많이 사용한다.

DEBUG: Trace보다 조금 더 상위 수준의 레벨이며, SQL에 대한 로깅을 진행할 수 있다. (경험상 로컬, 개발 서버까지 debug 레벨을 많이 사용하는 것 같다.)

INFO: 애플리케이션의 주요 동작이나 이벤트, 요청 처리 정보를 포함하여 스프링 부트에서는 디폴트로 INFO 레벨부터 보인다.

WARN: 경고 메시지를 기록하며, 서비스 운영 자체에는 영향이 없지만, 주의가 필요한 부분에 들어간다.

ERROR: 가장 심각한 단계이다. 즉시 조치를 취해야 하는 수준의 레벨이라고 한다.

사실 개인적으로 ExceptionHandler에서 처리하는 로깅은 어느 레벨에서 처리해야 할지 고민인데...

개인적으로 클라이언트와 계속 개발하는 단계에서는 ERROR로 핸들링해야 어떤 상황에서 오류가 발생했는지 클라이언트 개발자에게 전해주기 좋을 것 같아서 ExceptionHandler의 로깅 레벨을 ERROR로 설정하였다.

@ControllerAdvice
public class ControllerExceptionHandler {

    private final Logger log = LoggerFactory.getLogger(getClass());

    @ExceptionHandler(AuthenticationException.class)
    public ResponseEntity<Void> handlerAuthenticationException(AuthenticationException e) {
        log.error(e.getMessage(), e);
        return ResponseEntity.status(HttpStatus.UNAUTHORIZED).build();
    }

    @ExceptionHandler(CartItemException.IllegalMember.class)
    public ResponseEntity<Void> handleException(CartItemException.IllegalMember e) {
        log.error(e.getMessage(), e);
        return ResponseEntity.status(HttpStatus.FORBIDDEN).build();
    }

    @ExceptionHandler(Exception.class)
    public ResponseEntity<Void> exception(Exception e) {
        log.error(e.getMessage(), e);
        return ResponseEntity.status(HttpStatus.BAD_REQUEST).build();
    }
}

그래서 우선, 발생할 수 있는 모든 예외 상황에 대해서 log.error로 로깅 처리를 진행해주었다.

로그백을 활용해서 내가 하고 싶은 내용은 다음과 같다.

1. 기본적으로 info 하위 레벨의 로그는 console에 출력하기

2. ⭐️ 이때, error 레벨의 로그는 콘솔 및 별도의 파일에 함께 출력하기

3. error 레벨의 로그는 날짜별로 관리하기

Logback 분석하기

천천히 따라해보자.

src/resources 하위에 logback-spring.xml이라는 파일을 생성한다.

<configuration>
  <property resource="logback-variables.properties"/>

  <timestamp key="ToDay" datePattern="yyyy-MM-dd"/>

  <appender name="CONSOLE" class="ch.qos.logback.core.ConsoleAppender">
    <layout class="ch.qos.logback.classic.PatternLayout">
      <Pattern>
        ${LOG_PATTERN}
      </Pattern>
    </layout>
  </appender>

  <appender name="FILE" class="ch.qos.logback.core.rolling.RollingFileAppender">
    <filter class="ch.qos.logback.classic.filter.LevelFilter">
      <level>error</level>
      <onMatch>ACCEPT</onMatch>
      <onMismatch>DENY</onMismatch>
    </filter>

    <file>${LOG_PATH}/${ToDay}/${LOG_FILE_NAME}.log</file>
    <rollingPolicy class="ch.qos.logback.core.rolling.SizeAndTimeBasedRollingPolicy">
      <fileNamePattern>
        ${LOG_PATH}/%d{yyyy-MM-dd}/${LOG_FILE_NAME}_%i.log
      </fileNamePattern>
      <maxFileSize>10MB</maxFileSize>
      <maxHistory>30</maxHistory>
    </rollingPolicy>
    <encoder>
      <pattern>${LOG_PATTERN}</pattern>
    </encoder>
  </appender>

  <root level="INFO">
    <appender-ref ref="FILE"/>
    <appender-ref ref="CONSOLE"/>
  </root>

</configuration>

그리고, logback-variables.properties라는 파일을 생성한다.

LOG_PATH=./logs
LOG_FILE_NAME=jwp-shopping-order
LOG_PATTERN=%d{yyyy-MM-dd HH:mm:ss.SSS} [%level] [%thread] [%logger{36}] - %msg%n

전역적으로 관리하면 좋을 것 같은 부분에 대해 변수로 분리해두었다.

프로퍼티와 타임스탬프 선언해주기

코드가 길기 때문에 하나씩 분리해서 차례대로 파악해보자.

먼저 프로퍼티를 불러온 다음, 3번 조건 (날짜별로 로그 관리) 구현 시 사용하기 위해 날짜 패턴을 정의해두었다.

콘솔 출력을 위한 로깅 설정 진행하기

다음으로 콘솔 출력에 대한 appender를 정의하였다.

콘솔 출력 시 어떤 패턴을 사용하여 로깅을 할 것인지 정의한 것인데, 실제로 콘솔 출력과 비교해보면 다음과 같다.

발생 시간 - 로그 레벨 - 스레드 이름 - 로그 발생 주체의 이름 - 메시지

하나씩 떼어서 보니까 이해하기 쉽죠...?

파일 출력을 위한 로깅 설정 진행하기

여기는 꽤 길기 때문에 하나씩 파악해보자.

콘솔 때와 마찬가지로 appender를 정의해준다.

이때, 우리는 2번 조건 (error 레벨의 로그는 파일로 저장)을 만족하기 위해 별도의 filter를 정의해주었다.

만약 ERROR 레벨이라면 허용, 아니라면 거절하도록 만들어준 부분이다.

간단하게 생각하면 정의한 fileSize와 maxHistory에 따라서 새로운 로그 파일이 생성되도록 정의하는 부분이다.

그리고, 새로운 로그파일은 _0, _1이라는 postfix와 함께 계속 생성되게 된다.

여기서 file과 fileNamePattern을 왜 나누었나 싶을 것이다.

우선, rollingPolicy를 사용하기 위해서는 fileNamePattern 옵션을 꼭 넣어줘야 한다. (아니면 오류남)

하지만, fileNamePattern만 사용하게 되면 롤링 정책에 의해 새로운 로그 파일이 생성되기 전, 첫 번째 파일을 생성할 때 위와 같이 _0라는 postfix가 붙어서 예쁘지 않다.

예쁨 주도 개발을 해야 하기 때문에 참을 수 없다. (현재 개발 수준에서는 10MB가 채워지려면 엄청난 요청이 들어와야 하기 때문에 롤링 정책이 적용되는 건 거의 보지 못했다.)

그래서 전역적으로 첫 파일이 생성될 때는 _0을 제거시키기 위해 별도의 file 태그를 통해 정의해주었다.

아무튼, file로 설정해주면 새로운 로그 파일이 생성될 때 _0을 통해 로그 파일이 생성된다.

루트 로거에 설정해주기

All loggers are descendants of the predefined root logger

모든 로그의 경우 사전에 정의된 root logger의 자손이다.

우리가 위에서 열심히 정의한 정책을 사용하기 위해서는 루트 로거를 설정해야 된다는 것이다.

⭐️ 루트 로거의 경우 하나만 지정이 가능하며, 다중으로 설정하더라도 마지막에 선언한 것만 처리된다.

참고로, 이 설정을 빼면 스프링을 켤 때 아무것도 안 뜬다.

덩그러니... 나중에 다른 사람들한테 이걸로 몰래 카메라 해주고 싶다

아무튼! 최종적으로 이렇게 진행하고 나면, 다음과 같이 에러 레벨의 로깅에 대해서만 편하게 관리할 수 있게 된다.

이건 콘솔에서 INFO 레벨 이상의 로그가 출력되는 것이고!

요렇게 파일로도 확인이 가능하게 된다

꽤나 재밌었던 삽질이었다~~!

[Jenkins] AWS 인스턴스를 젠킨스로 배포해보기 - 2편

dolmeng2 — Tue, 30 May 2023 20:32:33 +0900

들어가기 전

지난 포스팅은 젠킨스를 설치하고 필요한 플러그인을 설치하는 과정까지 진행하였다.

레파지토리 WebHook 등록하기

우리는 깃허브 레파지토리의 특정 브랜치에 push 이벤트가 발생하면 자동으로 배포가 일어나게 만들 것이기 때문에, 해당 push 이벤트에 대해서 감지할 수 있도록 'webhook'이라는 친구를 등록해야 한다.

등록하고 싶은 레파지토리의 Settings > Webhooks > Add webhook을 클릭한다.

이런 식으로 payload URL과 content-type을 지정해준다.

aws 인스턴스로 띄웠다면 publicIP:8081과 같은 형태가 위 URL에 들어갈 것이다.

⭐️ 여기서 제일 중요한 거, 끝에 꼭 /github-webhook/ 붙여줘야 한다... 이거 때문에 1시간 넘게 삽질했다.

성공적으로 웹훅을 등록했다면 아래와 같이 목록에 뜨게 된다.

깃허브 토큰 발급받기

젠킨스에서 깃허브에 대한 접근 권한을 받기 위해서는 깃허브에서 키를 발급받아 젠킨스에게 설정해줘야 한다.

깃허브 계정에 대한 settings에 들어가준다. 그리고 왼쪽에 있는 'Developer Settings'에 들어간다.

Personal access tokens > Tokens (classic) > Generate new token > Generate new token (classic)을 클릭한다.

그리고 Select Scopes에서 repo, admin:org, admin:repo_hook 3가지에 대한 권한을 준다.

간단하게 설명하면 레파지토리에 대한 권한, orgnaization에 대한 권한, 레파지토리 훅(웹훅 같은)에 대한 권한을 주는 것이다.

Generate token을 클릭하면 토큰 정보가 나올 텐데, 잊어버리지 않게 다른 곳에 복사해두자.

젠킨스 와 깃허브 연동해주기 - 토큰 연동

먼저, 위에서 발급받은 깃허브 토큰 정보를 젠킨스에 등록해주는 과정을 진행해야 한다.

깃허브 대시보드에서 Manage Jenkins > 아래쪽의 Credentials 클릭!

Stores Scope to Jenkin에서 Domains의 (globals) 클릭. (전역적으로 설정을 등록해줘야 함)

Add Credentials 클릭. (1편부터 따라했다면 원래 여기에 ssh 키도 있어야 하는데, 이전에 캡쳐한 자료를 가져오느라 이렇게 됐다... ㅎㅎ)

이후 Username with password 지정 후, 깃허브 아이디와 위에서 발급받은 token 정보, 그리고 id를 지정해준다.

최종적으로 이런 모습으로 등록이 완료되었을 것이다.

여기서 secret-id는 지금 신경쓰지 않아도 된다. 바로 아래에서 진행할 예정이기 때문이다 ㅎㅎ

젠킨스 와 깃허브 연동해주기 - 깃허브 서버 연동

다시 젠킨스 대시보드에서 Manage Jenkins > System을 클릭한다.

내리다 보면 GitHub라는 게 있을 텐데, Name 지정 후 Credentials 밑에 있는 Add > Jenkins를 클릭해준다.

그럼 이런 식으로 또 다시 Credential을 등록하는 과정이 있을 텐데, 여기서 위에서 발급받은 깃허브 token을 또 다시 넣어준다.

앞서 웹훅 등록시, 깃허브 측에서 POST 요청으로 우리의 젠킨스 서버에 요청을 보낸다고 했었는데, 여기서 인증 정보를 등록하는 과정이라고 보면 된다.

Credentials에 위에서 지정한 id 값을 선택해주고, Test Connection이 성공하는지 확인한다.

젠킨스 잡 생성하기

다시 대시보드로 돌아와서, 이번에는 New Item을 클릭한다.

아이템 이름은 자유롭게 설정해주고, Pipeline을 선택한다.

Github project, Build Triggers > Github hook trigger for GITscm polling을 체크한다.

파이프라인 스크립트 작성하기

정말 마지막 단계이다. 파이프라인 스크립트를 작성해주면 된다.

우선, 현재 나의 EC2 저장소의 구조이다.

pipeline {
    agent any
    tools {
        gradle 'gradle'
    }
    stages {
        stage('Git Clone') {
            steps {
                git branch: '{branch_name}', credentialsId: 'secret-id-github', url: '{Git Repository URL}'
            }
        }
        stage('Build') {
            steps {
                sh "./gradlew clean build"
            }
        }
        stage('Deploy') {
            steps {
                sshagent(credentials: ['journey-shop-ec2']) {
                    sh '''
                        ssh -o StrictHostKeyChecking=no ${DEPLOY_HOST} uptime
                        scp build/libs/jwp-shopping-order.jar ${DEPLOY_HOST}:/home/ubuntu/jwp-shopping-order
                        ssh -t ${DEPLOY_HOST} /home/ubuntu/jwp-shopping-order/deploy.sh
                    '''
                }
            }
        }
    }
    environment {
        DEPLOY_HOST = '{EC2 접속 사용자 이름}@{EC2 private IP}'
    }
}

과정은 간단하다.

원하는 깃 레파지토리의 브랜치에서 clone을 한 다음, gradlew를 통해 빌드를 진행한다.

그리고 배포를 시작하는데, ssh agent를 사용한 덕분에 위와 같이 ssh 명령어를 사용할 수 있게 된다.

1. 원격 호스트에 대해서 SSH 연결 후 uptime을 통해 실행 시간 정보를 표시한다. 이때, 호스트의 공개 키를 검사하지 않고 SSH 연결을 진행한다.
2. 위에서 빌드된 build/libs/jwp-shopping-order.jar 파일을 지정한 경로로 복사한다.
3. ssh 연결 후 deploy.sh 스크립트를 실행한다. (배포)

⭐️ 이때, 원격 호스트 정보는 이미 젠킨스 자체가 EC2 위에 띄워져 있기 때문에 private IP로 접속해야 한다.

나의 경우 쉘 스크립트는 다음과 같이 작성하였다.

#!/bin/bash
REPOSITORY=/home/ubuntu/jwp-shopping-order
PROJECT_NAME=jwp-shopping-order
cd $REPOSITORY/$PROJECT_NAME/
echo "> 현재 구동중인 애플리케이션 pid 확인"
CURRENT_PID=$(sudo lsof -i tcp:8080 | awk 'NR!=1 {print$2}')
echo "현재 구동중인 애플리케이션pid: $CURRENT_PID"
if [ -z "$CURRENT_PID" ]; then
    echo "> 현재 구동중인 애플리케이션이 없으므로 종료하지 않습니다."
else
    echo "> kill -9 $CURRENT_PID"
    sudo kill -9 $CURRENT_PID
    sleep 5
fi
echo "> 새 애플리케이션 배포"
JAR_NAME=$(ls -tr $REPOSITORY/*.jar | tail -n 1)
echo "> JAR Name: $JAR_NAME"
rm -rf $REPOSITORY/deploy.log $REPOSITORY/deploy-err.log
nohup sudo java -jar $JAR_NAME --spring.profiles.active=prod --spring.config.location=$REPOSITORY/application.yml >> $REPOSITORY/deploy.log 2> $REPOSITORY/deploy-err.log &

그냥 이동하고, 8080으로 띄워진 애플리케이션 확인 후 기존에 돌아가는 것은 제거한다.

새롭게 빌드하면 기존의 로그 파일은 제거한 다음, cp로 인해 복사된 파일을 java-jar를 통해서 실행해준다 ㅎㅎ

config 정보의 경우 외부로 노출시키지 않기 위해서 인스턴스 내부에 저장해두고 사용하고 있다

아래는 젠킨스 사용 전 스크립트 파일인데, 혹시 도움이 될 수도 있으니 첨부해두겠다.

#!/bin/bash
REPOSITORY=/home/ubuntu/jwp-shopping-order
PROJECT_NAME=jwp-shopping-order
cd $REPOSITORY/$PROJECT_NAME/
echo "> Git Pull"
git pull origin step1
echo "> 현재 구동중인 애플리케이션 pid 확인"
CURRENT_PID=$(sudo lsof -i tcp:8080 | awk 'NR!=1 {print$2}')
echo "현재 구동중인 애플리케이션pid: $CURRENT_PID"
if [ -z "$CURRENT_PID" ]; then
    echo "> 현재 구동중인 애플리케이션이 없으므로 종료하지 않습니다."
else
    echo "> kill -9 $CURRENT_PID"
    sudo kill -9 $CURRENT_PID
    sleep 5
fi
echo "> 프로젝트 Build 시작"
./gradlew build -x test
echo "> Build 파일 복사"
cp $REPOSITORY/$PROJECT_NAME/build/libs/*.jar $REPOSITORY/
echo "> 새 애플리케이션 배포"
JAR_NAME=$(ls -tr $REPOSITORY/*.jar | tail -n 1)
echo "> JAR Name: $JAR_NAME"
rm -rf $REPOSITORY/deploy.log $REPOSITORY/deploy-err.log
nohup sudo java -jar --Dspring.profiles.active=prod $JAR_NAME --spring.config.location=$REPOSITORY/application.yml >> $REPOSITORY/deploy.log 2> $REPOSITORY/deploy-err.log &

최종적으로 브랜치에 push 이벤트가 발생하게 되면, 젠킨스 파이프라인이 돌면서 위의 스크립트를 실행하여 배포에 성공하게 된다!!

너무 감격이다...

많은 도움을 준 베베에게 다시 한 번 감사 인사 올립니다...

‍♀️

[Jenkins] AWS 인스턴스를 젠킨스로 배포해보기 - 1편

dolmeng2 — Tue, 30 May 2023 20:31:43 +0900

들어가기 전

이번 미션에서 젠킨스를 통해 CI / CD를 구축해보고 싶어서 ⭐️베베 선생님⭐️의 힘을 빌려서 한 번 진행해보았다.
나는 t4g.micro를 사용하다 보니 램이 1기가밖에 안 되어서 swap을 해주었어야 했는데,
⭐️ 중요한 건 swap 시 1~1.5기가 정도만 해야 한다는 것이었다.

나는 2기가로 해서 지금 Use가 95%로 간당간당하다.
원래 안 돼서 로컬로 실행하고 난리치다가 다시 시도했는데 되기는 했다...

죽어가는 친구

1.5기가로 만들고 싶다면 아래와 같이 실행해주면 된다.

# 기존에 존재하는 /swapfile을 비활성화하기
sudo swapoff /swapfile

# 크기가 1.5기가인 /swapfile 생성하기
sudo fallocate -l 1.5G /swapfile

# /swapfile에 대한 파일의 권한 변경하기
sudo chmod 600 /swapfile

# swapfile을 추가하기 위한 swap 공간을 생성한다.
sudo mkswap /swapfile

# swapfile을 swap 메모리에 추가한다.
sudo swapon /swapfile

# /esc/fstab 파일에 파일 시스템 마운트 시 필요한 구성 파일을 수정한다.
sudo vim /etc/fstab

# 파일의 맨 끝에 /swapfile을 스왑 영역으로 마운트하기 위한 옵션을 추가한다.
# 마운트할 파일의 경우 + 파일 시스템 유형 지정 (none) + 마운트할 파일의 유형 지정 (swap) + 마운트 옵션 (sw, 스왑 영역을 의미함)
# 0 (파일 시스템이 백업되어야 하는지 여부, 여기서는 백업 X) + 0 (파일 시스템의 검사 순서 지정) - 검사하지 않음
/swapfile none swap sw 0 0

# 시스템 재부팅
sudo reboot

이후 free를 통해 swap이 잘 되었는지 확인하도록 하자.

도커로 젠킨스 실행하기

참고로, 여기 아래에서 나오는 이미지들은 로컬 젠킨스로 시도했을 때 캡쳐했던 것들이어서 맥 환경입니다! (추후 EC2 환경에서 함)

먼저, 준비물로 도커가 필요하다.

sudo snap install docker
sudo apt install docker.io

docker.io를 실행할 때 경고 메시지가 떠도 괜찮다. 정상적으로 설치되었음을 의미한다.

잘 설치되었는지 체크하기 위해 도커 버전을 확인해주자.

docker --version

그리고, 젠킨스를 실행해주기 위한 docker-compose 파일을 작성해주자.

version: "3.9"
services:
  jenkins:
    image: jenkins/jenkins
    restart: always
    ports:
      - "8081:8080"

간단하게 진행하기 위해서 이미지와 포트 옵션 외에 별다른 것은 진행하지 않았다.

이때, 포트 옵션을 8081로 두었는데, EC2 인스턴스의 inbound rules에서 허용된 포트 주소여야 한다.

나는 여기서 사용할 수 있는 게 8081밖에 없는 상황이었어서 8081 포트로 진행하였다.

이후, docker-compose 파일을 실행하여 도커 컨테이너를 실행하자.

docker-compose up -d

참고로 나는 이미 이미지가 다운받아진 상태여서 이렇게만 뜨지만, 처음이라면 젠킨스 도커 이미지를 다운받느라 조금 걸릴 것이다.
(위에 뜨는 경고 메시지는 현재 실행하지 않는 도커 컨테이너가 있어서 뜬 오류인데, 신경쓰지 않아도 된다!)

docker ps -a

이후, 잘 실행되었는지 확인하기 위해 STATUS에 UP xx minutes가 뜨는지 확인하자.

EC2에서 진행하기 위해서는 매번 sudo를 입력하고 있다면, 번거로우니까 아래와 같이 docker 실행에 대한 권한을 주자.

sudo chmod 666 /var/run/docker.sock

이후 재시작을 하게 되면 sudo 없이 편하게 실행할 수 있을 것이다

도커로 젠킨스 접속하기

publicIP:8081로 접속했다면 위와 같은 창이 뜰 것이다.
가장 첫 접속이기 때문에 비밀번호를 입력해야 한다.

docker logs {container_id}

터미널에 docker logs + 젠킨스가 띄워진 도커 컨테이너의 아이디를 입력해보자. 그럼 아래와 같은 창이 뜰 것이다.

딱 봐도 비밀번호처럼 생긴 친구가 있다.
이 친구를 복사해서 위의 Administrator password에 입력해주자.

그럼 여기서 install suggested plugins를 눌러준다.

위와 같이 열심히 실행되고 있을 텐데, 설치에는 5~10분 정도 걸리기 때문에 여유롭게 기다리자!

이후, 어드민 계정으로 로그인하기 위한 정보를 입력해준다.

원래는 localhost가 아니라 EC2 Public IP:8081 같은 형태여야 한다. (옛날에 캡쳐함...)

Jenkins에 접속하기 위한 URL을 입력한다. (기본적으로 입력되어 있는 상태긴 하다 ㅎㅎ)

그럼 이렇게 Jenkins 화면이 멋지게 나타난다!

젠킨스 플러그인 설치하기 - gradle

우리는 gradle로 빌드를 진행할 예정이기 때문에 gradle 관련 플러그인이 필요하다.

Dashboard > Manage Jenkins > Tools 클릭!

Gradle Installations > Version 선택 후 Save 진행하기!
나 같은 경우는 최신이면서 가장 안정화된 gradle 8.1을 설치하였다.

젠킨스 플러그인 설치하기 - ssh agent

추후 나올 젠킨스 배포 스크립트에서 ssh를 통해 우리의 EC2 인스턴스에 접근을 할 것이다.
이를 위한 ssh agent라는 친구를 설치해보자.

Dashboard > Manage Jenkins > Plugins 클릭!

Available plugins > ssh agent 검색 > 설치 진행!

다시 깃허브 대시보드로 돌아간 다음, 왼쪽의 Manage Jenkins > 아래쪽의 Credentials 클릭!

Stores scoped To Jenkins > Domains > global 클릭!

Add Credentials 클릭!

SSH-Username with private key 선택 후, ID는 아무거나, Username은 EC2 호스트 네임을, Private key에는 EC2 인스턴스 접속을 위한 pem 키를 입력한다. (cat xx.pem을 통해 나온 내용을 복사 붙여넣기 해준다.)

추가가 완료되면 이런 식으로 목록에 뜬다.

생각보다 글이 길어져서 2개로 나누고자 한다.
다음 포스팅으로 깃허브 레파지토리 연동 + 젠킨스 배포 스크립트를 설정해보자!

[MySQL] Error 1093: You can't specify target table for update in FROM clause

dolmeng2 — Mon, 29 May 2023 13:53:14 +0900

문제 상황

사용자의 요청으로부터 받은 장바구니 아이디와 사용자의 아이디가 일치하는 경우에만 제거하기 위해 아래와 같은 쿼리를 작성했다.

DELETE FROM cart_item AS c
WHERE c.id
IN (
    SELECT ci.id FROM cart_item AS ci
    JOIN member AS m ON ci.member_id = m.id
    AND ci.id IN (6, 8) AND m.id = 1
);

하지만, 다음과 같이 target table (cart_item)의 c에 대해서 업데이트를 할 수 없다는 문구가 나왔다.

원인

MySQL에서는 update, delete 시에 자기 자신의 테이블 데이터를 바로 사용할 수 없었기 때문에 발생한 오류였다.

(참고로 H2 환경에서는 잘 돌아간다. 옛날에도 이런 오류가 났었는데... 기록하지 않은 자의 최후 )

해결 방법

IN 절 내부에 존재하는 서브 쿼리에 대해서 임시 테이블로 만든 다음에, 해당 테이블을 참조하도록 만들면 된다.

DELETE FROM cart_item AS c
WHERE c.id
IN (
    SELECT cart_item_temp.id
    FROM
    (
        SELECT ci.id AS id FROM cart_item AS ci
        JOIN member AS m ON ci.member_id = m.id
        AND ci.id IN (6, 8) AND m.id = 1
    ) cart_item_temp
);

코드가 복잡하기는 하지만, h2와 mysql 환경 모두에서 잘 동작하도록 만드려면 어쩔 수 없는 선택이었다.

DELETE c
FROM cart_item AS c
JOIN member AS m ON c.member_id = m.id
WHERE c.id IN (6, 8) AND m.id = 1;

단순하게 이렇게 조인을 해도 되지만, h2에서는 delete 절에 대해서 별칭을 지원하지 않기 때문에 사용할 수가 없었다...

h2 mode를 MySQL로 하더라도 이런 쿼리에 대해서는 완전 동일하게 동작하지는 않는 것 같다.

[Infra] AWS 배포 후 도메인 연결 및 HTTPS 적용, nginx로 리버스 프록시 적용하기

dolmeng2 — Sun, 28 May 2023 17:56:46 +0900

들어가기 전

무과금으로 HTTPS 적용 프로젝트를 진행해보았다.

정석대로라면 가비아 + Route53 + ACM or 가비아 + nginx로만 진행하면 좋았겠지만...

여러 제약사항으로 인해서 색다른 방법으로 도메인 연결 및 HTTPS 적용을 진행해보았다.

제약사항
- 무료 도메인 사용하기
- 서버 1대로 구축하기 (끊임없이 고통받는 t4g.micro)
- http 접속 시 https로 리다이렉트시키기

나중에 Route53 + ACM + ELB를 통해 도입했던 것도 포스팅으로 작성해보고자 한다. (이번 미션에서는 못 했지만 ㅠ)

도메인 구입하기

사실 가비아에서 구매했던 도메인이 있긴 하지만, 페어 프로그래밍을 하다 보니 나만의 도메인을 사용하기는 좀 그래서 다른 사이트를 찾아보았다. 그러다가 발견한 곳 = 내도메인.한국!

내도메인.한국 - 한글 무료 도메인 등록센터

한글 무료 도메인 내도메인.한국, 웹포워딩, DNS 등 무료 도메인 기능 제공

xn--220b31d95hq8o.xn--3e0b707e

굉장히 수상하게 생겼지만 속도도 빠르고, 적용하는 데에는 크게 무리가 없어서 여기서 구입하기로 결정하였다.

먼저 일반 도메인 검색창에 등록하고 싶은 도메인을 검색한다.

5번은 현재 내가 사용하고 있기 때문에 등록 불가로 뜬다 ㅎㅎ

처음에 구입하면 위와 같이 DNS 연결을 할 수 있는데, 우선 A 레코드에 AWS 인스턴스의 public IP를 작성한다.

여기서 A 레코드를 등록한다는 의미는, DNS 서버에 우리가 구매한 도메인과 IP를 연결한다는 의미인데,

journey-shop.kro.kr로 브라우저에서 접속하면 12.34.56.78 (IP)로 접속할 수 있도록 만든다는 뜻이다.

CNAME은 추후 설정할 예정이지만, 해당 도메인에 대한 별칭을 지정한다는 의미 정도로 생각하면 된다.

등록하고 journey-shop.kro.kr:8080/admin으로 접속하게 되면 위와 같이 멋진 창이 뜨게 된다.

더 이상 IP 주소로 접근하지 않고, 사람에게 익숙한 도메인명으로 사이트에 접속이 가능한 것이다.

HTTPS 연동하기

하지만, 위에서 진행한 과정은 IP 대신에 단순히 도메인명을 사용했을 뿐이다.

우리가 네이버에 접속할 때 naver.com:8080과 같이 접속하지 않는 것처럼, 포트 번호 없이, https 환경으로 접속하고 싶을 것이다.

(또한, 프론트엔드 서버가 배포 서버라면 https -> http는 CORS에 의해서 통신이 불가능하다 )

그래서 이번에는 간단하게 https를 적용해보고자 한다.

https는 암호화된 프로토콜이다. 그렇기 때문에 신뢰된 기관이 제공해주는 인증서가 필요하다.

처음에는 certbot을 사용하려고 했으나... 무료 도메인을 사용하다 보니 kro.kr로 요청이 너무 많이 들어와서 당장 처리할 수 없다는 오류가 발생하고 말았다.

too many certificates already issued for "kro.kr"

그래서 1시간 정도 처음에는 기다리려고 했지만, 바로 진행하고 싶어서 결국 포기...

혹시 하고 싶다면 아래와 같이 진행해주면 된다.

sudo apt update

# certbot 설치
sudo apt install certbot

# www의 경우 선택사항
sudo certbot certonly --standalone -d journey-shop.kro.kr -d www.journey-shop.kro.kr

# 인증서 파일 확인
sudo ls /etc/letsencrypt/live/journey-shop.kro.kr/
cert.pem  chain.pem  fullchain.pem  privkey.pem

아무튼, 어떤 방법을 사용할지 고민하다가 SSL for Free이라는 사이트를 발견하였다.

SSL For Free - Free SSL Certificates in Minutes

Wildcard SSL Certificates Wildcard certificates allow you to secure any sub-domains under a domain. If you want to secure any sub-domains of example.org that you have now or in the future you can make a wildcard certificate. To generate wildcard certificat

www.sslforfree.com

가입하고 나서 Domain 입력해주고, Validity에 90일, Auto-Generate CSR을 켜주면 된다.

그리고, 악의적인 사람이 내 도메인에 대해서 멋대로 접근할 수 있기 때문에 journey.kro.kr이 정말 SSL 발급자의 소유 도메인인지 확인하기 위해 3가지의 인증 방법이 주어진다. (메일 인증, DNS, HTTP File upload)

메일 인증의 경우 내도메인.한국을 사용했다 보니 kro.kr의 소유주의 이메일로 전송되기 때문에 사용할 수 없었다.

File upload의 경우 우리의 스프링 부트 서버에 ssl for free에서 지정해준 경로에 파일을 업로드 후 배포하여, 해당 url로 이 사이트가 GET 요청을 보내 health checking을 진행하는 방식인데, 프로덕션 코드가 더럽혀지는 게 싫어서 패스하였다.

그래서 마지막 방법으로, 이 사이트에서 지정한 CNAME을 우리의 도메인에 연결하여 소유권을 검증하는 방법을 채택하였다.

위에서 주어진 NAME, Point to를 각각 입력해주면 된다.

다 진행했다면 verify Domain을 클릭해주고, 아래와 같이 문제 없다고 뜬다면 성공이다.

그리고, Certificate 파일을 다운로드 받아야 하는데 'Ubuntu'으로 설정한 다음 다운로드 받았다.

그러면 3가지의 파일을 받을 수 있는데, ca_bundle.crt, certificate.crt, private.key를 얻게 된다.

ca_bundle.crt (= chain.pem)
: 인증 체인이나 중간 인증 기관의 인증서들을 포함한다.
인증 체인은 인증서 발급 기관에서 최상위 인증 기관까지 계층적 구조로 구성되며, 서버 인증서와 함께 제종되는 CA의 인증서 체인을 의미한다. 보통 클라이언트가 인증서를 검증할 때 사용한다.

certificate.crt (= fullchain.pem)
: 서버의 SSL / TLS 인증서를 포함하며, 웹 서버에 설치되는 인증서이다.
서버의 공개키와 서버 정보가 포함되어 있다.

private.key (= privkey.pem)
: 서버의 개인 키를 포함하며, 서버 측에서 인증서와 매칭되는 일종의 비밀 키이다.
SSL / TLS의 암복호화에서 사용되기 때문에 외부에 노출돼서는 안 된다.

하지만, 추후 nginx에서 인증서를 등록하기 위해서는 crt 파일 형식이 아닌 pem 키 형식이 필요하기 때문에 별도로 변환하는 작업이 필요하다.

openssl x509 -inform PEM -in certificate.crt > certificate.pem

그래서, 서버의 인증서를 openssl을 통해서 pem 형식으로 변환해주었다.

마지막으로 인증서와 키를 내 ec2 쪽으로 옮겨보자.

scp -i {EC2 접속을 위한 키} certificate.pem ubuntu@{EC2 public IP}:{이동할 path}
scp -i {EC2 접속을 위한 키} private.key ubuntu@{EC2 public IP}:{이동할 path}

요렇게 하면 사전 준비는 완료된다!

Nginx로 리버스 프록시 진행하기

리버스 프록시는 서버의 앞단에서 사용자의 요청을 받아 적절한 위치로 포워딩시키는 것을 말한다.

우리는 여기서 'nginx'라는 친구를 이용해서 http로 온 요청을 https로 바꾸는 작업을 진행해보고자 한다

sudo apt install nginx

먼저, nginx를 설치해준다.

sudo ufw enable
sudo ufw status

그리고, 방화벽에 대한 설정을 해줘야 하는데, 우분투는 ufw 방화벽을 사용한다.

기본적으로 비활성화되어 있기 때문에 enable을 통해서 활성화 시켜준다. 이러면 모든 포트가 자동적으로 막히게 된다.

status를 통해 현재 어떤 포트가 열려있는지 확인할 수 있다.

중간에 캡쳐한 거여서 몇몇이 열려있다.

sudo ufw allow ssh
sudo ufw allow 'Nginx Full'
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp
sudo ufw allow 8080/tcp

나는 다음과 같이 ssh, nginx Full (사실 이게 80이랑 443 열어주긴 함), 80, 443, 8080을 열어주었다.

sudo systemctl start nginx
sudo systemctl status nginx

그리고, 잘 가동되는지 확인하기 위해 restart 후 status를 확인한다.

요런 식으로 Active가 떴다면 성공이다.

나중에는 restart 옵션을 많이 사용할 텐데, status로 항상 상태를 함께 확인하는 것을 추천한다.

그리고, 이제 포워딩 옵션을 주기 위해서 /etc/nginx/site-enabled로 이동한다.

거기로 가면 'default'라는 파일이 있을 텐데, 해당 파일을 vi로 수정한다.

cd /etc/nginx/site-enabled
sudo vi default

server {
	listen 80 default_server;
	listen [::]:80 default_server;

	listen 443 ssl default_server;
	listen [::]:443 ssl default_server;

	root /var/www/html;

	index index.html index.htm index.nginx-debian.html;

	server_name journey-shop.kro.kr;
	ssl_certificate /home/ubuntu/certificate.pem;
	ssl_certificate_key /home/ubuntu/private.key;
	ssl_prefer_server_ciphers on;

	location / {
          proxy_pass http://localhost:8080;
          proxy_set_header X-Real_IP $remote_addr;
          proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
          proxy_set_header Host $http_host;
	}
}


server {
  listen 80;
  server_name journey-shop.kro.kr;
  return 301 https://$host$request_uri;
}

보기만 해도 어지럽기 때문에 하나씩 쪼개서 확인해보자.

Nginx 설정 파일 분석하기

여기서 default_server라는 친구를 확인할 수 있다.

nginx에서 어떤 포트로 요청이 들어왔을 때 지정한 server 블록을 기본으로 설정하겠다는 의미이며, 만약 지정하지 않은 경우 요청에 대해 가장 구체적인 서버 블록을 찾으려고 매칭을 시도한다.

⭐️ 여기서, 기본 서버 블록이라는 건 아무것도 매칭되지 않을 때 사용한다는 의미이다.

1. 요청한 호스트 이름과 일치하는 server_name 지시문이 있는 서버 블록 지정
2. 요청된 호스트 이름과 일치하는 와일드카드 server_name 지시문이 있는 서버 블록 지정
3. 기본 서버 블록 (default_server)

예를 들어서, journey-shop.kro.kr으로 요청이 들어온다면 다음과 같은 순서로 매칭된다.

server {
    listen 80;
    server_name *.journey-shop.kro.kr;
}

server {
    listen 80;
    server_name *.journey-shop.kro.kr;
}

server {
    listen 80 default_server;
}

이렇게 3개의 서버 블록이 있다면 가장 구체적인 첫 번째 블록이 선택될 것이며, 만약 첫 번째 블록이 잘못되었다면 두 번째 블록으로, 두 번째 블록도 잘못되었다면 default_server로 설정되어 있는 세 번째 블록이 선택된다.

사실 이 부분은 기본으로 제공하는 부분을 별도로 건들지 않았다.

root의 경우 정적 파일에 대한 기본 경로이기 때문에, journey-shop.kro.kr/index.html 요청이 들어온다면 /var/www/html/index.html에서 파일을 찾게 된다.

index의 경우, request에 아무 파일도 지정하지 않은 상태로 요청이 들어온다면 /var/www/html/index, /var/www/html/index.html, /var/www/html/index.htm, /var/www/html/index.nginx-debian.html 파일을 순서대로 찾으며 반환한다.

server_name에는 여러 도메인을 지정할 수 있다.

# 2개의 도메인에 대해서 처리
server_name journey-shop.kro.kr www.journey-shop.kro.kr

# .journey-shop.kro.kr과 동일하다. 서브도메인에 대한 요청을 처리할 수 있다.
server_name *.journey-shop.kro.kr

# 특정 이름으로 시작하는 도메인에 대한 요청을 처리할 수 있다.
server_name journey-shop.kro.kr.*

참고로, nginx의 경우 단순히 HTTP 헤더에 있는 이름을 통해 요청에 응답하기 때문에 도메인 이름이 유효한지는 알 수 없다.

그래서 유효하지 않은 도메인 이름을 server_name에 지정할 수도 있다. (물론 에러 페이지로 가겠지만?)

아까 crt를 통해 보냈던 인증서와 키를 여기에서 지정해준다.

가장 마지막 옵션의 경우 서버에서 지정한 암호화 알고리즘을 우선한다는 의미이며, off로 설정하면 외부에서 약화된 알고리즘을 사용하여 공격할 수 있기 때문에 웬만하면 키는 게 좋다.

참고로, ssl_protocols을 통해 프로토콜을 지정하거나 ssl_ciphers를 통해 알고리즘 지정도 가능하다.

여기서 proxy_pass를 통해 http, https로 들어온 요청에 대해서 우리가 스프링부트를 띄운 8080으로 포워딩되도록 설정하였다.

즉, 백엔드 서버로 요청을 보낸다고 생각하면 된다.

여기서 호스트 이름이 조금 헷갈렸었는데, 사용자가 journey-shop.kro.kr에 접속했을 때 남는 http 헤더의 host 값 = journey-shop.kro.kr을 프록시 헤더로 지정해주는 것이었다. 즉, 클라이언트가 어디로 요청을 보냈는지 기록하는 것이라고 볼 수 있다.

가장 마지막 블록이다!

위에서 설명했던 것처럼 journey-shop.kro.kr로 요청이 들어오면 가장 구체적인 server_name이 지정된 이 블록이 매칭된다.

나는 http 요청을 모두 https로 리다이렉트 시키기 위해서 위와 같이 만들어주었다.

host의 경우 클라이언트의 요청에서 Host 헤더 값을 의미하며, request_uri는 클라이언트가 요청한 URI이다.

nginx에서 자동으로 설정해주는 값이기 때문에 별도로 재정의할 필요는 없다.

참고로, URI의 경우 쿼리 파라미터도 포함한다.
ex) https://journey-shop.kro.kr/products?name='치킨'

host: https://journey-shop.kro.kr
request_uri: journey-shop.kro.kr/products?name='치킨'

다 끝났다! 이제 브라우저에서 journey-shop.kro.kr/admin로 들어가면 바로 https로 디라이렉트된다!

사실 캠퍼스에서 썼어야 했는데...

다 못 써서 뒤늦게 기억을 의존하여 작성하였다

캠퍼스 등교하면 www도 추가해야겠다 ^^...

[Network] CDN - 캐시 서버로 빠르게 로드하기

dolmeng2 — Thu, 25 May 2023 23:14:49 +0900

CDS (Content Delivery Service)

만약, 내가 배포한 서버가 한국에만 존재하지만 전세계 다양한 곳에서 액세스되고 있다고 생각해보자.

수많은 파일과 데이터에 대해 전세계에 응답해야 하는 상황에서, 멀리 있는 국가의 사용자와 대해서 전달해야 한다면?

한국 사용자에게는 빠르게 전달할 수 있지만, 멀리 있는 사용자의 요청을 받아서 한국에서 처리하고, 또 다시 데이터를 곳곳에 존재하는 사용자에게 전달해야 하기 때문에 어느 정도 지연이 발생할 수밖에 없다.

이러한 상황에서 다수의 캐시 서버를 여러 개의 지역에 배치하여 트래픽을 분산시키는 방법이 필요하다!

그렇다면 캐시 서버는 어디에 둬야 할까?

1. 웹 서버 직전에 두기

웹 서버 직전에 두게 되면 서버 자체의 부하는 줄어들게 되지만, 인터넷에서 흐르는 트래픽을 조절할 수 없다.

2. 클라이언트 측에 두기

1번의 경우와 달리, 인터넷에 흐르는 트레픽을 억제할 수 있다.

그래서 대용량 데이터를 포함하는 컨텐츠라면 클라이언트 측에 두는 것이 더 좋다.

하지만, 웹 서버 운영자가 제어 불가능하고, 클라이언트가 정말 캐시 서버를 가지고 있는지 단정할 수가 없다.

(보통 웹 서버 측에서는 클라이언트의 정보를 완전히 믿어서는 안 된다.)

3. 인터넷 주위에 두기

프로바이더와 계약하여 서버 운영자가 제어할 수 있는 캐시 서버를 프로바이더에 두는 것이다.

이렇게 되면 인터넷에서 흐르는 트래픽도 제어할 수 있으며, 서버 운영자가 캐시 서버를 제어할 수 있게 된다.

하지만, 서버 측에서는 인터넷의 어느 측에서 액세스하는지 알 수 없기 때문에 POP (point of presence, 인터넷 액세스 포인트) 전부에 캐시 서버를 설치해야 돼서 현실적으로 불가능하다. 이를 해결하기 위해서 보통은 중요한 프로바이더 위주로 캐시 서버를 두어 캐시 서버를 줄이는 방법을 사용한다.

이렇게 하면 할 수는 있지만, 비용적으로 많이 들기 때문에 캐시 서버를 설치하고 웹 서버 운영자에게 대출하는 서비스를 제공하는 운영자가 담당하게 되었는데, 이를 CDS (Content Delivery Service) - 콘텐츠 배포 서비스라고 한다.

CDSP (CDS를 제공하는 사업자)는 중요한 프로바이더와 계약하고, 그곳에 여러 개의 캐시 서버를 설치하면서, 동시에 웹 서버 운영자와도 계약하여 웹 서버와 캐시 서버 사이를 연결해주는 역할을 한다.

= 결과적으로 사용자의 요청에 대해서 실제 서버가 아닌 캐시 서버가 응답하도록 만드는 것!

ex) AWS의 CloudFront가 대표적인 제공 서비스 중 하나이다.

+ 보통은 'CDN'이라는 명칭을 많이 사용하기 때문에 아래에서도 그렇게 부르겠다.

CDN을 사용하면 무엇이 좋을까?
- 페이지 로드 시간 단축
- 대역폭 비용 절감 (원본 서버의 제공 데이터 양을 줄이게 되니까)
- 콘텐트 가용성 (더 많은 트래픽 처리 가능)
- 웹 사이트의 보안 강화 (DDoS 공격도 분산시키니 조금 더 강함)

보통 언제 사용할까?
- 빠르게 컨텐츠를 전송해야 할 때 (뉴스 같은...?)
- 실시간 스트리밍
- 동시 사용자가 많은 경우

기본적으로 CDN의 경우 사용자가 웹 브라우저에 요청을 보내면 (클라이언트의 요청이 서버로 오게 되면) 원본 서버로부터 컨텐츠를 가져와 유저에게 전송한 동시에 캐시 서버에 저장한다. 그리고, 이후에 발생한 요청의 경우 '가장 가까운' 캐시 서버에게 액세스하도록 만든다.

'가장 가까운 캐시 서버를 찾아내고, 그곳에 액세스한다'

이 말은 어디에서 들어본 것 같지 않은가? 바로 DNS 서버에서 IP 주소를 찾아내는 과정이다.

위의 그림을 보자. 위에 써있는 MAC, IP 같은 정보는 클라이언트의 조회 메시지이다.

클라이언트 측의 DNS 서버는 클라이언트와 같은 장소에, 라우팅 테이블을 입수한 라우터는 캐시 서버의 설치 장소에 있다고 가정해보자.

이때, 가장 가까운 캐시 서버를 찾아내기 위해서 먼저 서버 측의 DNS 서버는 캐시 서버에 있는 라우터로부터 라우팅 테이블을 받게 된다.

라우팅 테이블의 정보를 조합하다 보면 어떠한 라우터 A -> 프로바이더 X -> 프로바이더 Y -> 클라이언트 측 DNS 서버... 이런 식으로 경로에 대한 정보를 알 수 있기 때문에 대략적인 거리 정를 파악할 수 있게 된다.

서버 측 DNS 서버는라우터 개수만큼 라우터 테이블을 가지고 있게 되며, 이러한 경로 정보와 받은 송신처 IP 주소를 통해 캐시 서버와 클라이언트 측의 DNS 서버 사이의 거리를 조사하여 가장 가까운 캐시 서버의 IP 주소를 찾는다. (모든 라우터 정보에 대해 비교하여 가장 가까운 라우터 찾기)

리다이렉트 활용하기

가장 가까운 캐시 서버에 액세스하기 위해 또 다른 방법을 사용할 수 있는데, 'Location'이라는 HTTP 헤더를 사용하는 것이다.

Location 헤더에 담긴 리소스 위치로 이동하여 가까운 서버로 이동해나가는 것이다.

그리고, 이렇게 이동하는 과정을 '리다이렉트'라고 한다.

리다이렉트를 통해 가장 가까운 캐시 서버를 클라이언트에 통지할 때는 리다이렉트용 서버를 웹 서버측의 DNS 서버에 등록하게 되며, 클라이언트는 DNS 서버에 등록된 정보를 바탕으로 HTTP 리퀘스트를 보내게 된다.

그러면 리다이렉트 서버 역시 DNS 서버처럼 경로 정보를 모아 가장 가까운 캐시 서버를 찾게 된다.

해당 캐시 서버를 나타내는 경로를 Location 헤더에 넣어 응답을 전송해주면 클라이언트는 해당 정보를 바탕으로 캐시 서버에 액세스하게 된다. 또한, Location 헤더 외에도 패킷의 왕복 시간 같은 정보를 두어 시간 정보를 바탕으로 최적의 캐시 서버에 액세스 하도록 만들 수 있다.

사실 거의 비슷하지만, 첫 번째 방법은 가장 가까운 캐시 서버의 IP 주소를 반환해서 해당 캐시 서버에 접속하는 느낌이고...

두 번째 방법은 HTTP 메시지를 별도의 서버로 보내서 해당 서버에서 경로 정보를 계산하여 헤더 값으로 받는 느낌...?

첫 번째 방법은 http 이전 단계인 것 같고, 두 번째 방법은 http 메시지를 통해 얻는 것 같은데 헷갈린다.

캐시 정보는 언제 갱신하지?

캐시 관련 이야기에서 가장 중요한 점 중에 하나이다.

기존에는 한 번 액세스한 데이터를 두 번째 액세스 시 반환하도록 하는 방법이 있었는데 (ttl 고려) 이 역시 기존 데이터와의 정합성을 보장해줄 수 없기 때문에, 웹 서버에서 기존의 데이터를 갱신할 경우 캐시 서버와 동기화를 진행해야 한다.

이러면 항상 캐시 서버의 데이터가 최신이라는 것을 보장할 수 있으며, CDN의 캐시 서버는 이에 대한 방법이 내장되어 있다.

예를 들어, 앞서 말했던 AWS CloudFront의 경우 기본적으로 파일의 캐시가 24시간 정보 유지된다.

HTTP 헤더의 Cache-Control 헤더를 통해서 캐시의 유지 시간을 설정할 수 있지만, 개발자가 직접 캐시가 만료되기 전 파일 내용을 갱신할 수 있는 'Invalidation'이라는 기능을 제공하고 있다.

http://blog.a-cloud.co.kr/2020/01/23/invalidation%EC%9C%BC%EB%A1%9C-cloudfront-%EC%BD%98%ED%85%90%EC%B8%A0-%EA%B0%B1%EC%8B%A0%ED%95%98%EA%B8%B0cache-control/

또한, 캐시 규칙을 찾아보았는데 기본적으로 CDN의 캐시 정책은 HTTP에 따르는 것 같다.

Cache Rules_Content Delivery Network_User Guide_Domain Name Settings_Cache Settings_Huawei Cloud

You can configure the maximum age for one or more cached resources on CDN nodes. If the maximum age of a file cached on CDN nodes has reached, CDN requests the most recent content of the file from the origin server when a user requests the file. CDN return

support.huaweicloud.com

You can control cache aging by configuring the Cache-Control: max-age field in an HTTP response header. By leveraging cache rules, you can optimize cache periods for different services.

애초에 개발자가 캐싱에 대한 규칙을 정할 수 있는 것처럼 보인다.

퀴즈
Q. 현재 주류가 되어 있는 방화벽의 유형이 무엇일까?
A. 패킷 필터링형

Q. 방화벽에서 애플리케이션 종류를 지정할 때 점검하는 정보는?
A. 포트 번호

Q. 웹 서버의 부하를 막기 위해 액세스를 여러 대의 서버에 분배하는 장치는?
A. 로드 밸런서

Q. 서버 측에 설치하는 프록시는 무엇일까?
A. 리버스 프록시

Q. 인터넷에 다수의 캐시 서버를 설치하고, 웹 서버 운영자에게 대출하는 서비스는?
A. CDS

[우테코 5기] 지하철 미션 회고

dolmeng2 — Mon, 22 May 2023 22:47:06 +0900

가비와 진행한 레벨 2 세 번째 페어 프로그래밍 미션인 지하철 미션이다...!

우테코 하면서 진행했던 미션 중에서 가장 어려운 미션이 아니었나 싶다.

객체지향적인 코드를 작성하는 것과 단순 구현 그 사이에서 엄청 헤맸던 것 같다...

앞으로 개발할 때도 레벨 1에서 배웠던 것들을 정말 잊지 않아야겠다

✔️ 작성한 코드

GitHub - Cl8D/jwp-subway-path: 레벨 2 지하철 미션 레파지토리

레벨 2 지하철 미션 레파지토리. Contribute to Cl8D/jwp-subway-path development by creating an account on GitHub.

github.com

✔️ 1차 PR

[1단계 - 지하철 정보 관리 기능] 져니(이지원) 미션 제출합니다. by Cl8D · Pull Request #45 · woowacourse/

안녕하세요, 또링! 져니입니다 ‍♀️ 레벨 1의 첫 미션 리뷰어가 또링이었는데 벌써 레벨 2가 되었네요...! 다시 만나서 반가워요 이번 미션은 시간이 많이 부족해서 제가 봐도 코드가 너

github.com

✔️ 2차 PR

[2단계 - 경로 조회 기능] 져니(이지원) 미션 제출합니다. by Cl8D · Pull Request #111 · woowacourse/jwp-subwa

안녕하세요, 또링! 져니입니다! 지난 1단계 때 피드백을 빠르게 주신 덕분에 2단계도 금방 구현할 수 있었습니다~! 2단계 - 경로 조회 기능 (DB 설정, 경로 조회 API, 요금 조회 기능)에 해당하는 부

github.com

✔️ 기능 요구사항

- 지하철 노선에 역을 등록 / 제거하는 API 구현

- 하나의 역은 여러 노선에 등록될 수 있으며, 노선은 갈래길을 가질 수 없다.

- 최초 등록 시 두 역을 동시에 등록해야 한다.

- 이미 등록된 역 사이에 노선을 등록할 경우 거리 정보를 고려해야 한다.

- 노선 제거 시 기존 역 간 거리 정보를 업데이트 해줘야 한다.

- 노선에 2개만 역이 남았을 경우 모두 제거해야 한다.

- 노선 조회 시 등록된 역도 함께 조회되도록 API 구현

- 출발역에서 도착역까지 갈 수 있는 최단 경로 출력 및 요금 정보 조회 API 추가

- 노선에 대한 추가 요금 정책 및 연령별 요금 할인 정책 추가

이번에도 고민했던 부분들에 대해서 적어보고자 한다!

도메인 설계하기

페어랑 진행하면서 DB 위주가 아닌, 도메인 위주의 코드를 작성하고 싶어서 처음부터 도메인을 위주로 작성했었다.

노선과 지하철 역, 그리고 노선에 등록된 역 정보를 나타내기 위해 구간 정보를 나타내는 3개의 도메인을 메인으로 잡았다.

아마 대부분의 크루들이 이렇게 설계한 것 같았다.

Station

사실 말 그대로 지하철 역에 대한 정보를 가지고 있는 도메인이다.

지하철 이름 말고 특별한 정보가 없기 때문에 딱히 설명할 것이 없다 ㅎㅎ

Section

노선에 대한 각 구간 정보를 저장하는 도메인이다.

출발역과 도착역, 그리고 두 역 사이의 거리 정보를 관리하고 있다.

처음에는 역의 하행, 상행 정보를 알기 위해서 이에 대한 boolean 필드를 추가할까 고민했었는데, map을 사용해서 이는 해결할 수 있는 문제여서 추후 수정하게 되었다. (허브 갓 )

Line

노선 도메인의 경우 이름과 색상, 추가 요금, 그리고 노선에 대한 역 정보인 SubwayLine을 가지고 있도록 하였다.

Section에서 Line을 참조하는 식으로 설계를 하신 크루들도 몇몇 봤었는데, 테이블상에서는 Section 테이블이 Line 테이블을 참조하는 것이 자연스럽지만 실세계에서 '노선이 역을 가진다'라는 조건에 부합하지 않는다고 생각했다.

그래서 노선 도메인이 SubwayLine이라는 도메인을 가지도록 만들었고, 도메인 객체를 설계할 때 어떤 식으로 모델링하는 게 중요한지 알 수 있었던 시간인 것 같다. (내가 지금까지 정말 DB 주도 개발을 했었구나 다시금 생각할 수 있던 시간이었다...)

SubwayLine

SubwayLine이라는 도메인은 하나의 노선에 대한 구간 정보 리스트와 순서대로 정렬되어 있는 역 리스트를 가지고 있으며, Line

사실 DB와 가장 간극이 큰 도메인이 아닐까 싶다. (이 과정에서 객체지향적 설계를 정말 많이 고민했다.)

도메인이 할 수 있는 일은 사실 서비스에서도 충분히 DB 조회를 통해서 해결할 수 있는 일들이기 때문이다.

객체에게 책임을 주기 위해 DB에서 조회해온 도메인과 실제 연산을 통해 변경된 부분에 대해서 변경 감지 (프록시 객체를 이용하거나, 혹은 차집합을 이용하거나...)를 활용하여 업데이트를 한 크루들도 보였었는데, 오히려 프로그램의 복잡도가 너무 증가하는 것 같아서 실제 sections 정보가 업데이트 되더라도 도메인의 필드는 변경되지 않도록 했다.

대신, 새로운 구간 정보가 들어올 수 있는지에 대한 '검증 작업'을 위주로 도메인에게 책임을 전가하도록 설계하였다.

코드 부분을 대충 가져왔다. 이런 식으로 Line 도메인을 생성한 다음에, subwayLine을 뽑아냈다.

여기서 Line의 subwayLine을 뒤늦게 업데이트 하는 이유는 단순히 라인에 대한 조회 후, 라인과 연관된 섹션 정보를 따로 조회하기 때문이다.
findById를 통해서 요청받은 노선의 아이디가 유효한지 검증하고, 유효하다면 섹션 정보를 조회하는 식으로 구현하려고 하다 보니 저런 구조가 됐다. 또한, findById에서 굳이 여러 정보를 가져오려고 조합하는 것보다 단순히 line에 대한 정보만 조회되도록 만들고 싶었기 때문이다. findById는 비교적 가볍게 쓰이는 메서드라고 생각했기 때문이다... ㅎㅎ

그리고 validateSection을 통해서 요청받은 도메인에 대한 검증 작업을 진행한다.

그리고 내부적으로 요청받은 정보가 비어있는지, 혹은 이미 등록된 정보인지, 실제로 저장된 역 정보인지 확인하게 된다.

이런 식으로 도메인이 내부적으로 검증할 수 있는 내용은 검증하도록 만들면서 책임을 넘기고, 실제 DB에 삽입, 삭제, 수정해야 하는 부분은 서비스에게 책임을 넘겨 구현하였다.

또한, SubwayLine이 정렬된 역 정보에 대해서 필드로 관리하고 있는 게 약간 찝찝하기도 했었다.

sections 정보를 통해서 역 정보는 충분히 유추 가능한 정보이기 때문에, 사실 필드로 관리하지 않고 필요할 때마다 정렬해서 사용하는 방법도 있기 때문이다.

하지만... 굳이 처음 한 번 정렬하면 되는 정보를 조회할 때마다 정렬하고 싶지 않아서 그냥 위와 같이 필드로 두는 방향을 택했다.

리뷰어님도 다른 말씀 안 하셨기 때문에 나름 합리적인 구조가 아니었나 싶다.

private List<Station> sort(final List<Section> sections) {
    final Map<Station, Station> stationRelationShip = getStationRelationShip(sections);
    final Optional<Station> startStation = getStartStation(stationRelationShip);
    return startStation.map(station -> getSortedStations(stationRelationShip, station))
        .orElse(Collections.emptyList());
}

private Map<Station, Station> getStationRelationShip(final List<Section> sections) {
    return sections.stream()
        .collect(Collectors.toMap(Section::source, Section::target));
}

private Optional<Station> getStartStation(final Map<Station, Station> stationRelationShip) {
    return stationRelationShip.keySet().stream()
        .filter(station -> !stationRelationShip.containsValue(station))
        .findFirst();
}

private List<Station> getSortedStations(final Map<Station, Station> stationRelationShip,
                                        final Station startStation) {
    final List<Station> sortedStations = new ArrayList<>();
    Optional<Station> nextStation = Optional.ofNullable(startStation);
    while (nextStation.isPresent()) {
        sortedStations.add(nextStation.get());
        nextStation = Optional.ofNullable(stationRelationShip.get(nextStation.get()));
    }
    return sortedStations;
}

개인적으로 정렬 로직에 대해서 스트림을 적절히 활용한 것 같아 뿌듯하다

테이블 설계하기

테이블 구조는 아래와 같이 설계하였다.

CREATE TABLE IF NOT EXISTS station
(
    id bigint auto_increment NOT NULL,
    name VARCHAR(255) NOT NULL UNIQUE,
    PRIMARY KEY(id)
);

CREATE TABLE IF NOT EXISTS line
(
    id bigint auto_increment NOT NULL,
    name VARCHAR(255) NOT NULL UNIQUE,
    color VARCHAR(20) NOT NULL,
    extra_fare int NOT NULL,
    PRIMARY KEY(id)
);

CREATE TABLE IF NOT EXISTS section
(
    id bigint auto_increment NOT NULL,
    line_id bigint NOT NULL,
    source_station_id bigint NOT NULL,
    target_station_id bigint NOT NULL,
    distance int NOT NULL,
    PRIMARY KEY(id),
    FOREIGN KEY(line_id) REFERENCES line(id) ON DELETE CASCADE,
    FOREIGN KEY(source_station_id) REFERENCES station(id),
    FOREIGN KEY(target_station_id) REFERENCES station(id)
);

사실 외래키에 대해서도 정말 의견이 분분하게 나뉘는데, 개인적으로 이렇게 작은 규모라면 외래키를 걸어두는 게 더 좋을 것 같다.

물론 그만큼 테스트가 빡세지만... 테스트는 픽스처를 활용하여 어느 정도 해소할 수 있을 것 같다.

그리고, section 테이블의 필드에는 on delete cascade 옵션을 주었는데, 이는 부모 테이블의 row가 제거되었을 때 함께 제거되어 section의 고아 필드(?)가 남지 않도록 만들었다.

위에서도 말했던 것처럼 section의 경우 line의 정보와 연관되어 있는 정보이기 때문에, 노선이 제거된 이후에도 해당 노선의 구간 정보가 존재할 필요가 없다고 생각했기 때문이다.

그리고, 원래 구현할 때는 station 쪽에도 on delete cascade를 걸어두었었는데, 생각해보니까 역 정보가 제거된다고 해서 구간 정보를 바로 제거해버리면 기존 구간에 대한 거리 업데이트가 안 될 것 같아서 회고를 작성하며 간단하게 리팩터링을 해보았다.

public int deleteById(final Long id) {
    try {
        final String sql = "DELETE FROM station WHERE id = ?";
        return jdbcTemplate.update(sql, id);
    } catch (final DataIntegrityViolationException e) {
        throw new BadRequestException(ErrorCode.STATION_DELETE_IF_EXISTS_SECTION);
    }
}

그냥 이렇게 FK에 대한 오류가 발생하면 이미 구간에 대한 정보가 있기 때문에 역을 제거할 수 없다는 예외를 반환하도록 만들었다.

실행하면 요런 식으로 제거할 수 없도록 만들었다!

인터페이스로 의존성 역전시키기 (DIP)

이번 미션에서 가장 신경쓴 부분 중에 하나이다.

저번 장바구니 미션 회고 글을 작성하면서 마지막에 다음과 같은 커멘트를 남겼었다.

지난 미션의 의존성은 다음과 같은 구조였다.

서비스에서 바로 Dao를 참조하다 보니, Dao가 반환하는 값인 Entity와 의존 관계가 생기고, 이 정보를 바탕으로 도메인 객체를 생성하다 보니 서비스가 도메인까지 알게 되는 구조가 된 것이다.

그래서 이번 미션에서는 다음과 같이 구조를 변경하였다.

Repository 계층을 추가해서 서비스 레이어는 도메인만 바라보고, 도메인과 엔티티를 변환하는 작업을 Repository에게 위임한 것이다.

이 덕분에 기존의 순환 관계를 없앨 수 있었다.

하지만, DAO와 Repository는 Persistence layer에 존재하고 있다.

application layer가 Repository를 import 하면서 여전히 persistence layer를 의존하며 domain 패키지에 존재하는 도메인 객체와 모두 상호 참조하게된다는 단점이 존재했다.

⭐️ 이를 위해 Repository의 인터페이스는 도메인 레이어에 두고, 이에 대한 구현체를 persistence layer에 두어 의존 관계를 역전시키는 전략을 채택하였다! 덕분에 Application Layer에서는 도메인 계층의 패키지만 의존하게 되어서 더 이상 순환 참조가 발생하지 않았다.

실제로 서비스 레이어의 import를 보면 application, domain으로만 참조 관계가 형성된 것을 확인할 수 있다.

실제로 그림으로 설명하자면 이런 느낌이라고 볼 수 있다.

외부 라이브러리에 덜 의존적인 형태로 설계하기

최단 경로를 구하기 위하여 jgrapht 라이브러리를 사용했어야 했는데, 부끄럽지만 내 처음 제출 코드는 다음과 같았다.

// RouteService.java
private WeightedMultigraph<Station, DefaultWeightedEdge> getPossibleRouteGraph(
    final Map<Long, List<LineWithSectionRes>> sectionsByLineId) {
    final WeightedMultigraph<Station, DefaultWeightedEdge> routeGraph = new WeightedMultigraph<>(
        DefaultWeightedEdge.class);
    sectionsByLineId.values()
        .forEach(sectionRes -> addRouteBySectionRes(routeGraph, sectionRes));
    return routeGraph;
}

전체 코드를 가져오기 너무 길어 일부만 가져왔지만, 저런 식으로 외부 라이브러리가 제공하는 기능을 그대로 사용하고 있었다.

당연하게 리뷰어님에게도 같은 지적을 받아서 부끄러웠다

어떤 방법을 사용하면 좋을지 고민하다, 인터페이스를 활용하기로 결정하였다.

public interface GraphProvider {

    List<Station> getShortestPath(final List<SubwayLine> sections, final Station sourceStation,
                                  final Station targetStation);
}

도메인 계층에 다음과 같은 인터페이스를 만들고 (이름을 엄청 고민했었는데 나름... 괜찮나?), 인자로 출발역에서 도착역까지 갈 수 있는 모든 구간 정보와 출발역, 도착역 정보를 넘겨주었다.

그리고, 외부 서비스임을 나타내는 'infra' 패키지에 JgraphService를 추가하였다.

@Component
public class JgraphtService implements GraphProvider {

    @Override
    public List<Station> getShortestPath(final List<SubwayLine> sections,
                                         final Station sourceStation,
                                         final Station targetStation) {
        final WeightedMultigraph<Station, DefaultWeightedEdge> routeGraph = createRouteGraph(sections);
        validateRequestRoute(sourceStation, targetStation, routeGraph);
        return getShortestPath(sourceStation, targetStation, routeGraph);
    }
    ...
}

사실 내부는 그냥 최단 경로 구하는 코드여서 의미는 없을 것 같아 첨부하지 않았다.

인자로 넘겨주는 값이 많기는 하지만, 내부적으로 상태를 가지지 않게 하려면 최단 경로를 구하는 메서드에서 경로도 구하고, 입력값이 올바른 값인지에 대한 검증까지 다 해야 된다.

이렇게 설계한 덕분에 application layer에서는 도메인 계층의 GraphProvider 인터페이스만 바라보고 있어 추후 다른 라이브러리로 교체되더라도 application layer에 대한 변경사항은 없어 영향 범위를 최소화할 수 있게 되었다.

개인적으로 infra 패키지는 왜 항상 인터페이스를 사용하는 것일까 궁금했는데... 이렇게 직접 구성하면서 완전히 이해할 수 있었다.

요금 정책 효율적으로 적용하기

부끄럽게도 요금 정책 역시 처음에 짠 코드가 굉장히 별로다.

public Fare calculateFare(final TotalDistance distance) {
    if (distance.lessThan(EXTRA_FARE_SECTION_TEN)) {
        return BASIC_FARE;
    }
    if (distance.lessAndEqualsThan(EXTRA_FARE_SECTION_FIFTY)) {
        final TotalDistance extraDistance = distance.subtract(EXTRA_FARE_SECTION_TEN);
        return BASIC_FARE.add(calculateByDistance(extraDistance, FARE_SECTION_UNIT_FIVE));
    }
    final TotalDistance fareSectionDistance = EXTRA_FARE_SECTION_FIFTY.subtract(EXTRA_FARE_SECTION_TEN);
    final TotalDistance extraDistance = distance.subtract(EXTRA_FARE_SECTION_FIFTY);
    final Fare extraFare = calculateByDistance(fareSectionDistance, FARE_SECTION_UNIT_FIVE)
        .add(calculateByDistance(extraDistance, FARE_SECTION_UNIT_EIGHT));
    return BASIC_FARE.add(extraFare);
}

10km, 10~50km, 50km 이상에 대해 각각 분기문을 통해 처리하고 있다 보니 확장에 매우 취약한 구조가 된 것이다.

OCP를 위반하고 있어요. 어떻게 개선해볼수 있을까요? (Hint. 해당 구간에 판단하는지 여부와 요금을 계산하는 메서드가 공통적이네요)

요기서 리뷰어님이 굉장한 힌트를 주셨다. 구간을 판단하는 메서드와 요금을 계산하는 메서드를 나누라는 것이다.

그래서 아예 정책별로 클래스를 나누기로 결정하였다.

우선, 각 정책에 대해 공통적인 행위를 정의하는 인터페이스를 생성해두었다.

public interface FarePolicy {

    boolean isAvailable(final Distance distance);

    Fare calculateFare(final Distance distance);
}

isAvailable가 구간에 대해 정책 적용이 가능한지 판단하는 메서드이고, calculateFare가 실제로 요금을 계산하는 메서드이다.

그리고, 해당 인터페이스를 구현한 3개의 구체 정책 클래스를 생성하였다.

10km 이하에 대한 기본 정책은 BasicFarePolicy, 10~50km는 UnitFiveFarePolicy, 50km는 UnitEightFarePolicy로 설정했다.

이름이 좀 아쉽긴 한데... 5km당, 8km당 100원씩 추가된다는 게 더 중요한 것 같아서 저렇게 만들어두었다 ㅎㅎ

공통적으로 사용하는 필드 값은 enum을 통해서 정의해두었다. (한 번에 관리하기 위해서)

그리고, 중요한 점은 각 정책들을 'FarePolicyComposite'라는 클래스를 통해 한 번에 관리하고 있는 것이다.

public Fare getTotalFare(final Distance shortestDistance) {
    return farePolicies.stream()
        .filter(policy -> policy.isAvailable(shortestDistance))
        .map(policy -> policy.calculateFare(shortestDistance))
        .findFirst()
        .orElseThrow();
}

해당 컴포지트 클래스를 통해, 각 정책들을 하나씩 순회하면서 적용 가능한 정책인지 판단한 뒤, 적용 가능하다면 진행한다.

현재 설계상 구간 정보는 각 정책 중 하나의 범위에 무조건 들어가기 때문에 orElseThrow()로 던져질 위험이 없을 것이라 판단하였고, 이렇게 되면 60km 이상의 구간에서는 다른 정책을 추가해야 할 때 farePolices 리스트에 정책을 추가해주기만 하면 되기 때문에 확장에 열린 구조를 유지할 수 있었다.

단, 이 구조를 채택하기 위해서는 isAvailable의 조건 정보가 촘촘해야 된다는 점이다. 현재 구조는 촘촘하게 설계되어 괜찮지만!

그렇다면, 정책 리스트는 어디에서 추가해줄까?

각 정책들은 스프링 빈으로 관리되고 있기 때문에 @Configuration을 활용하면 쉽게 주입이 가능해진다.

@Configuration
public class FarePolicyConfig {

    @Bean
    public FarePolicyComposite farePolicies(
        final FarePolicy basicFarePolicy,
        final FarePolicy unitFiveFarePolicy,
        final FarePolicy unitEightFarePolicy
    ) {
        return new FarePolicyComposite(
            List.of(basicFarePolicy, unitFiveFarePolicy, unitEightFarePolicy)
        );
    }
}

이때 파라미터로 주입되는 클래스의 이름은 꼭 빈에 등록된 클래스의 이름과 맞춰줘야 한다.

스프링에서 기본적으로 파라미터의 타입을 기준으로 빈을 조회한다.
만약, 같은 타입의 빈이 여러 개 조회되면 추가적으로 필드나 파라미터 이름으로 빈을 조회한다.

위의 원리를 바탕으로 'FarePolicyComposite' 타입의 'farePolicies'라는 이름을 가진 빈을 등록했기 때문에, application layer에서도 다음과 같이 주입받아서 사용하면 된다.

@Service
public class RouteService {
    ...
    private final FarePolicyComposite farePolicies;
}

이를 바탕으로 추가 요금 정책도 동일하게 구현할 수 있었다 ㅎㅎ

나 같은 경우는 나이 정보를 따로 받지 않고, 그냥 할인된 가격도 함께 반환하도록 만들다 보니 가능했던 것 같다.

public DiscountFare getDiscountFares(final Fare totalFare) {
    final List<Fare> fares = discountFarePolicies.stream()
        .map(policy -> policy.calculateFare(totalFare))
        .collect(Collectors.toUnmodifiableList());
    return new DiscountFare(fares.get(0), fares.get(1));
}

단, 이때는 빈으로 등록된 순서에 따라서 영향을 받다보니까 조금 애매하다.

만약 나이를 입력받는다면 이렇게 map -> collect 대신에 요금 정책을 적용했던 것처럼 filter를 통해 받을 수 있을 것 같다.

쓸 내용이 별로 없을 것이라고 생각했는데 쓰다 보니까 오늘 하루가 다 가버렸다

이번 미션은 정신없던 것만큼 나름 많은 걸 얻어갔던 것 같다.

내일부터 새로운 미션 시작인데... 파이팅 해야겠다!

[Spring] Rest-docs 연동하기 (version 3.3.2)

dolmeng2 — Mon, 22 May 2023 13:56:57 +0900

들어가기 전

사실 rest-docs는 미션 요구사항은 아니었지만, 개인적인 욕심으로 한 번 직접 구축해보고 싶다는 생각이 들었어서 미션하는 김에 함께 진행하게 되었다. (어차피 추후 미션 진행하면서 프론트 크루와 협업하게 되면 세팅해야 하니까...)

RestDocs를 연동할 때 인수 테스트 레벨에서 진행할지 (RestAssured) 아니면 컨트롤러의 단위 테스트에서 진행할지 고민했었는데, RestAssured를 통해 사용하게 되면 BDD 스타일이라 더 직관적일 것 같긴 하지만 아무래도 속도가 느리다 보니까 그냥 컨트롤러 레이어에서 진행했다. (실제로도 컨트롤러 레벨에서 많이 진행하는 것 같다.)

✔️ Rest-docs가 어떤 거지?

Spring Rest Docs는 Restful 서비스에 대해 정확하고 읽기 쉬운 문서를 생성할 때 도움을 주는 문서 자동화 도구이다.

흔히 백엔드, 프론트엔드가 협업할 때 프론트엔드는 API endPoint를 알고 있어야 해당 API로 요청을 보내서 response를 받아 처리한다. 만약 백엔드 개발자가 API 문서를 수정했다면 프론트엔드 개발자한테 어떻게 알려야 할까?

직접 메신저로 ‍♀️ 'oo님, xxx endpoint의 쿼리 파라미터 요구사항이 변경되었어요' 라고 말할 수도 있겠지만, 이는 매우 번거롭다.

만약 프론트엔드 개발자가 당장 수정해야 하는 hotfix 요구사항임에도 메신저를 읽지 못했다면? 혹은, 원하는 시간에 서로 소통할 수 없다면? 하나의 정형화된 문서를 통해서 관리하는 게 훨씬 쉬울 것이다.

Swagger를 사용하는 경우도 있고, Rest docs를 사용하는 경우도 있을 텐데 각각의 장단점이 뚜렷하다.

https://jojoldu.tistory.com/31

Swagger의 경우 테스트 코드 작성에 부담이 없지만, 프로덕션 코드 자체에 문서에 대한 설정 내용이 어노테이션으로 들어가기 때문에 이 자체가 부담이 될 수 있다. Swagger에서 Rest docs로 전환해야 한다면 프로덕션 코드 자체를 전부 바꿔야 하기 때문이다.

하지만, Rest-docs보다는 비교적 적용하기가 쉬우며, 문서 자체는 우리가 직접 구축할 필요없이 알아서 만들어주고, 직접 테스트를 해볼 수 있는 화면을 제공하기 때문에 프론트엔드 개발자 입장에서는 조금 더 편할 수도 있다.

반면에 Rest-docs의 경우 테스트 코드를 기반으로 하기 때문에 프로덕션 코드에는 영향을 끼치지 않는다.

이 말은 곧, 테스트 코드가 정말 꼼꼼하게 짜여 있어야 한다는 것이다. 성공했을 때, 예외가 발생했을 때 등등... response 값이 변화하여 내려가는 경우에는 웬만하면 테스트 코드를 작성해야 한다. (그렇기 때문에 RestAssured보다 덜 무거운 MockMvc를 활용하는 게 더 낫다고 판단한 점도 있다.)

또한, 스웨거에 비해 구축이 어려운 편이다. 문서 구축 자체는 빌드된 adoc 파일을 직접 조립해야 하고, 프론트엔드 개발자가 직접 테스트해볼 수도 없다. 하지만, 직접 구축하기 때문에 문서 내부에 어떤 내용이 들어갈지 조금 더 세분화하여 개발자가 작성할 수 있다.

개인적으로 규모가 작다면 swagger를 사용해볼만 하다고 생각하지만, 프로덕션 코드 자체를 수정하는 게 찝찝하기 때문에 rest-docs를 조금 더 선호하는 편이다. (물론 그때부터 테스트 지옥이지만... ㅎ_ㅎ) 한 번 적용해두면 그뒤부터 응용은 쉽기 때문에 처음 러닝커브만 조금 견디면 된다!

✔️ SetUp - build.gradle

그전에, Rest Docs의 경우 기본적으로 'Asciidoctor'라는 친구를 사용하는데, 이 친구는 일반 텍스트를 처리하면서 HTM L 형태로 만들어주는 친구다. 이 친구의 개념 자체가 중요한 건 아니지만, HTML로 문서를 생성하기 위한 일종의 전처리 도구라고 생각하자.

또한, 각각의 테스트 코드가 성공하면 'snippet'이라는 친구가 생성되는데, 이러한 스니펫들을 조립하여 문서를 생성한다고 생각하자.

먼저, build.gradle에 다음과 같은 내용을 추가해야 한다.

plugins {
    id "org.asciidoctor.jvm.convert" version "3.3.2" 
}

configurations {
    asciidoctorExt 
}

ext {
    snippetsDir = file('build/generated-snippets') 
}

test {
    outputs.dir snippetsDir 
}

asciidoctor {
    inputs.dir snippetsDir 
    configurations 'asciidoctorExt' 
    dependsOn test 
    
    sources {
        include("**/index.adoc") 
    }

    baseDirFollowsSourceFile() 
}

asciidoctor.doFirst {
    delete file('src/main/resources/templates/docs') 
}

task copyDocument(type: Copy) { 
    dependsOn asciidoctor
    from file("build/docs/asciidoc")
    into file("src/main/resources/templates/docs")
}

build {
    dependsOn copyDocument 
}

dependencies {
    asciidoctorExt 'org.springframework.restdocs:spring-restdocs-asciidoctor'
    testImplementation 'org.springframework.restdocs:spring-restdocs-mockmvc' 
}

bootJar {
    dependsOn asciidoctor 
    from ("${asciidoctor.outputDir}/html5") { 
        into 'static/docs'
    }
}

생각보다 설정해줄 것이 굉장히 많기 때문에 조금씩 나눠서 보도록 하자.

plugins {
    id "org.asciidoctor.jvm.convert" version "3.3.2" (1)
}

configurations {
    asciidoctorExt (2) 
}

ext {
    snippetsDir = file('build/generated-snippets') (3)
}

tasks.named('test') {
    outputs.dir snippetsDir (4)
}

(1): Asciidoctor 플러그인을 적용한다.

(2): asciidoctorExt를 프로젝트의 configuration에 추가한다.

asciidoctorExt는 Asciidoctor를 사용하여 문서를 생성하고 포맷하는 데 사용하는 플러그인인데, 이를 이용하여 HTML 형식으로 출력할 수 있도록 만든다고 생각하면 된다.

(3): 생성된 스니펫들을 어느 위치에 저장할 것인지 지정하는 것이다. (디폴트로 build 폴더 밑에 생성하는 편)

(4): 저장한 스니펫 경로가 테스트 결과로 생성되는 디렉터리에 추가되도록 설정하는 것이다.

테스트가 실행될 때 스니펫이 생성되면, 해당 디렉터리에 저장되는 것이다.

asciidoctor { 
    inputs.dir snippetsDir (5)
    configurations 'asciidoctorExt' (6)
    dependsOn test (7)
    
    sources { 
        include("**/index.adoc") (8)
    }

    baseDirFollowsSourceFile() (9)
}

asciidoctor.doFirst {
    delete file('src/main/resources/templates/docs') (10)
}

(5) asciidoctor가 할 일을 정의하는 부분이다.

이전에 설정한 스니펫 저장 경로를 입력 디렉터리로 만들어서, asciidoctor가 문서를 생성할 때 어디를 참조할지 지정하는 것이다.

(6) ext에서 구성한 asciidoctorExt를 구성 파일로 사용하도록 만드는 것이다.

(asciidoctor의 configuration을 설정할 건데, 어떤 설정 정보를 참조할 것인지 확인하는 느낌?)

(7) 문서가 생성되기 전에 테스트가 실행될 수 있도록, test에 종속적이도록 만든다. (test 실행 -> 문서 생성 느낌!)

(8) rest-docs 문서의 경우, .adoc 파일을 바탕으로 생성하게 되는데 이때 source를 지정하게 되면 특정 adoc만 HTML로 만든다.

만약 모든 adoc에 대해 각각 html을 만들고 싶다면 해당 옵션은 제거해도 된다.

(9) 특정 .adoc에 다른 adoc을 include 하고 싶을 때 경로를 baseDir로 맞춰주는 역할이다.

나 같은 경우 index.adoc으로 세부 adoc을 로드하도록 만들었기 때문에 이 옵션을 활성화해주었다.

(10) static.docs 파일을 초기화하고 다시 만 들도록 설정 하는 것이다.

기본적으로는 static 하위에 두는 경우가 많은데, 미션에서 타임리프를 사용하다 보니 templates 폴더 하위로 설정하였다.

task copyDocument(type: Copy) { (11)
    dependsOn asciidoctor
    from file("build/docs/asciidoc")
    into file("src/main/resources/templates/docs")
}

build {
    dependsOn copyDocument (12)
}

dependencies { 
    asciidoctorExt 'org.springframework.restdocs:spring-restdocs-asciidoctor' (13)
    testImplementation 'org.springframework.restdocs:spring-restdocs-mockmvc' (14)
}

bootJar { 
    dependsOn asciidoctor (15)
    from ("${asciidoctor.outputDir}/html5") { 
        into 'templates/docs'
    }
}

(11) asciidoctor 작업한 이후 (dependsOn), build/docs/asciidoc을 보면 상단에서 설정해준 source 옵션에 따라 html이 생기게 된다. 나 같은 경우 프로덕션 코드에서 html에 접근할 수 있도록 하기 위해서 resources/templates/docs에 복사를 진행하였다.

(12) 빌드 작업이 copyDocument 이후에 진행되도록 설정한다.

(13) asciidoctorExt configuration을 사용하여 restdocs-asciidoctor 라이브러리에 대한 의존성을 설정한다.

이렇게 하면 .adoc 파일에서 빌드, 생성된 스니펫을 가리키도록 스니펫 속성이 자동으로 구성된다.

(14) MockMVC를 활용하여 rest-docs를 구성할 때 사용한다. (Rest-Assured를 사용하면 spring-restdocs-restassured 사용)

(15) 생성된 문서를 jar 파일에 패키징해서 정적 컨텐츠로 제공할 때 사용하는 것이다.

asciidoctor에 종속적이도록 만들어서, jar 파일을 빌드하기 전에 문서가 생성되었는지 체크한다.

이렇게 되면 jar 파일이 빌드되기 전에 문서가 생성되고, 생성된 문서는 jar 파일에 포함된다.

asciidoctor 진행 이후 문서를 templates/docs로 이동 시킨다.

그래서 결과적으로 ./gradlew clean build를 진행하게 되면 test -> asciidoctor -> copyDocument -> build 순으로 세팅이 진행된다.

✔️ 코드에 적용하기 (Junit5 기준)

우선, 테스트할 대상 클래스에 다음과 같은 셋업 작업을 진행해준다.

controller가 여러 개라면 공통적으로 사용할 부분은 빼는 것이 좋기 때문에, 나는 별도의 helper 클래스를 생성해두었다.

@ExtendWith(RestDocumentationExtension.class) (1)
public class RestDocsHelper {

    private MockMvc mockMvc;

    private RestDocumentationResultHandler documentationResultHandler;

    @BeforeEach
    void setUp(final WebApplicationContext webApplicationContext,
               final RestDocumentationContextProvider restDocumentationContextProvider) {
  
        this.documentationResultHandler = MockMvcRestDocumentation.document( 
                "{class-name}/{method-name}", (2)
                Preprocessors.preprocessRequest(Preprocessors.prettyPrint()), (3)
                Preprocessors.preprocessResponse(Preprocessors.prettyPrint()));

        this.mockMvc = MockMvcBuilders.webAppContextSetup(webApplicationContext) (4)
                .addFilter(new CharacterEncodingFilter("UTF-8", true)) (5)
                .alwaysDo(MockMvcResultHandlers.print()) (6)
                .alwaysDo(documentationResultHandler) (7)
                .apply(documentationConfiguration(restDocumentationContextProvider)) (8)
                .build();
    }
}

(1): Junit5에서 사용할 수 있으며, Spring Rest Docs의 RestDocumentationExtension 클래스를 사용하여 테스트를 확장시키는 것이다. 어렵게 생각할 필요없이, API 문서를 생성하기 위해 환경을 설정한다고 보면 된다.

(2): 문서의 세부 경로를 설정해주는 부분이다. build/generated-snippets 패키지 밑에, class-name 패키지, 그리고 method-name 패키지 하단에 각각의 스니펫이 생성되도록 만드는 설정이다.

- 사실 이 부분에 나중에 배포될 때를 대비하여 프로토콜 정보나 host 정보도 지정해줄 수 있다. (Preprocessors.modifyUris 활용)

(3) request, response에 대해서 전처리 작업을 해주는 것인데 요청, 응답에 대해 읽기 쉽도록 만들어준다.

(4): 각각의 테스트 메서드가 실행되기 전에 공통적으로 실행할 작업을 정의한다.

mockMvc에 대해서 설정하는 것을 볼 수 있는데, 이를 통해 Spring REST docs에서 생성된 컨텍스트를 사용하여 API를 테스트할 수 있도록 만들어주는 전초 작업이라고 볼 수 있다.

(5) 문서 생성 시 한글이 깨질 수 있기 때문에 이를 위해 인코딩 형식을 지정해주는 부분이다.

(6) 처리한 내용에 대해 항상 로깅 작업을 수행하도록 print를 해주는 부분이다.

(7) 위에서 설정한 정보들을 항상 적용하도록 만드는 것이다.

생각보다 글이 길어질 것 같아서, 실제로 코드에 어떤 식으로 적용되는지는 다음 포스팅에서 작성할 예정이다

[Network] 서버의 액세스가 증가할 때 어떻게 처리할까? - 캐시 서버와 포워드 프록시, 리버스 프록시

dolmeng2 — Mon, 22 May 2023 00:00:41 +0900

DNS 서버를 통해 다중 서버로 분산 처리하기

서버의 액세스가 증가한다면 단순히 회선을 빠르게 하는 것으로도 부족할 수 있다.

단일 서버의 한계를 극복하기 위해서는, 여러 대의 서버를 이용하여 처리를 분산시킬 수 있는데 이를 '분산 처리'라고 한다.

클라이언트의 리퀘스트를 어떻게 하면 여러 대의 서버로 분배할 수 있을까?

바로, DNS 서버를 통해 분배하는 것이다.

DNS 서버에 동일한 이름으로 여러 대의 웹 서버를 등록해둔다면, 조회가 있을 때마다 조회된 IP 서버를 차례로 반환한다.

이때, 라운드 로빈 방식을 통해 균등하게 액세스를 분산시킬 수 있도록 돕는다.

aaa.com이라는 도메인에 대해 192.0.2.60, 192.0.2.70, 192.0.2.80이 있다면 아래와 같은 순서로 반환한다.
- 192.0.2.60, 192.0.2.70, 192.0.2.80
- 192.0.2.70, 192.0.2.80, 192.0.2.60
- 192.0.2.80, 192.0.2.60, 192.0.2.70

하지만, 만약 이중 하나의 웹 서버가 오류가 발생하여 응답이 불가능한 상태라면 어떨까?

DNS 서버는 웹 서버가 고장났는지 확인할 수 없기 때문에 고장난 서버의 IP 주소를 반환해버릴수도 있다.

부하 분산 장치 / 로드 밸런서 사용하기

DNS 서버를 이용한 라운드 로빈 웹 서버 분배 방식의 단점을 극복하기 위해 별도의 부하 분산 장치를 사용할 수 있다.

DNS 서버에 웹 서버 자체가 아닌, 부하 분산 장치를 대신 등록한다.

그렇다면 클라이언트가 DNS 서버에서 IP 주소를 받아갈 때 부하 분산 장치의 IP 주소를 받아가기 때문에 부하 분산 장치 쪽으로 요청을 보내게 될 것이다.

부하 분산 장치는 웹 서버의 부하 상태를 판단하여 액세스를 위임하게 되는데, 기본적으로 웹 서버와 정기적으로 정보를 교환하여 CPU나 메모리 사용량 등을 수집하여 부하 상태를 확인한다. (혹은 패킷을 전송하여 응답 시간을 바탕으로 판단할 수도 있다.)

하지만, 만약 클라이언트의 요청과 서버의 요청이 연속되어 진행되어야 하는 상황이라면 어떻게 해야 할까?

ex) A라는 사용자가 상품을 주문 (주문 요청) -> 결제하고 (결제 요청) -> 결제 완료 창 띄워주기 (결제 완료 반환)

기본적으로 HTTP는 리퀘스트 메시지를 보내기 전에 TCP 접속 동작을 진행하고, 응답 메시지를 반환하면 연결을 끊는다.

이전 상태에 대한 정보가 없기 때문에 (stateless) 서로 관계있는 요청인지 알 수 없는 것이다.

이를 위해서 쿠키나 세션, 토큰 등의 인증 방식이 있는데 이에 대해서는 다른 포스팅에서 다루었기 때문에 패스하도록 하겠다

아래는 정리했던 내용이다 ㅎ_ㅎ

쿠키 / 세션 방식 정리

⭐️ JWT 인증 방식 정리

캐시 서버 이용하기

같은 기능의 여러 대의 서버를 설치하는 것은 아무래도 부담이 클 수 있다. (사실 뭐든 스케일 아웃이 가장 좋은 방법이긴 하니까...)

그래서 같은 기능의 서버를 설치하는 대신, 캐시 서버를 두어서 다른 역할을 주는 방법도 있다.

일반적으로 캐시 서버의 경우 '프록시'라는 구조를 사용하여 데이터를 캐시에 저장하게 된다.

이는 일종의 웹 서버와 클라이언트 사이의 액세스 동작에 대한 중개자 역할을 하는데, 클라이언트의 동일한 요청에 대해서 웹 서버에 조회한 이력이 있다면 다시 웹 서버를 들리지 않고 캐시 서버에서 바로 반환하는 역할을 할 수 있다. (이때 사용한 데이터가 '캐시')

물론, 캐시를 이용할 때는 데이터 정합성을 늘 고려해야 한다.

그래서 TTL 등을 통해 계속 데이터를 보관하는 대신, 일정 시간이 지나면 캐시 서버의 데이터를 초기화하는 경우가 많다.

캐시 서버도 마찬가지로 부하 분산 장치에 실제 웹 서버 대신에 DNS 서버에 등록된다.

그러면 사용자는 캐시 서버에 HTTP 리퀘스트 메시지를 보내게 된다.

만약, 캐시에 저장되어 있지 않다면 Via 헤더에 프록시 서버 정보를 추가하여 웹 서버에 리퀘스트를 전송한다.

이 정보는 그렇게 중요하지는 않으며, 단순히 웹 서버에게 프록시 서버를 경유했음을 알리기 위해 사용한다.

(참고로, 그림에서는 캐시 서버 -> 웹 서버에서만 Via가 추가되었는데 캐시 서버 -> 클라이언트로 갈 때도 추가한다!)

이때, 하나의 캐시를 여러 대의 서버에서 공유하고 있다면 리퀘스트 메시지의 내용에 따라서 웹 서버를 판단한다.

- 보통 리퀘스트의 URI를 바탕으로 서버를 결정하고는 한다. (⭐️ 사전에 설정해둔 웹 서버에만 전송할 수 있도록 지정하는 것.)

반대로, 캐시에 데이터가 저장되어 있었다면 웹 서버 측에게 데이터가 변경되었는지 조사하기 위해 If-Modified-Since라는 헤더 필드를 추가하여 웹 서버에 전송한다.

웹 서버는 If-modified-since 필드 값과 데이터의 최종 갱신 일시를 비교하여 변경이 없다면 변경이 없었다는 응답을 반환한다.

이때 데이터를 포함하지 않기 때문에 비교적 응답 메시지가 빠르게 전송된다.

캐시 서버는 변경사항이 없음을 파악했기 때문에 캐시 서버에 저장된 데이터를 반환하게 된다.

반면에, 수정된 사항이 있다면 수정된 리소스와 함께 반환하게 된다.

그리고 반환된 데이터는 다시 캐시 서버에 저장해두고, 클라이언트에게 반환한다!

참고로, If-Modified-Since 헤더의 경우 GET이나 HEAD 요청에서만 사용할 수 있다!

포워드 프록시 / 리버스 프록시 / 트랜스페어런트 프록시

포워드 프록시

앞서 말했던 내용은 웹 서버 측에 캐시 서버 두고 사용한 것이었는데, 클라이언트 측에도 캐시 서버를 둘 수 있다.

보통 클라이언트 측에 둔 프록시의 경우 방화벽처럼 원하는 패킷만 전송하도록 하는 것이었다.

패킷 필터링형 방화벽의 경우 IP 주소나 포트 번호 정보만 보지만, 프록시는 HTTP 리퀘스트 내용까지 함께 볼 수 있기 때문에 조금 더 세미하게 액세스 제한을 걸 수 있다는 것이다.

포워드 프록시를 하게 되면 URL의 내용에 관계 없이 클라이언트의 요청은 전부 프록시 쪽으로 전송된다.

- 클라이언트의 요청이 직접 인터넷에 가지 않는다.

또한, 기존에는 URI 정보만 리퀘스트 URI에 기록하지만, 포워드 프록시를 활용하면 URL 전부를 기록하게 된다.

그렇기 때문에 캐시 서버처럼 URI에 따라 전송할 웹 서버를 사전에 지정해줄 필요도 없이, 모든 웹 서버에서 전송할 수 있게 된다.

포워드 프록시는 보통 다음과 같은 상황에서 많이 사용한다.
- 접속 제한 회피 : 방화벽을 통해 제한된 액세스를 제공하는 사이트에 대해서 회피하여 이용 가능
- 특정 컨텐츠 제한: 특정 클라이언트가 특정 리소스에 접근하는 것을 막을 수 있음
- 캐싱: 요청의 응답값을 웹 서버까지 가지 않더라도 프록시에서 반환 가능
- IP 우회: 웹 서버 측은 클라이언트의 정보를 알지 못하고 프록시에 대한 정보만 받을 수 있게 된다.

리버스 프록시

하지만, 포워드 프록시의 경우 브라우저 설정이 꼭 필요하기 때문에, 이를 잘못 설정하게 되면 장애가 발생할 수도 있다.

리버스 프록시의 경우 웹 서버 / WAS 앞단에 위치하여, 클라이언트의 요청을 대신 받고, 웹 서버의 응답을 대신 반환해준다.

- 클라이언트의 요청이 인터넷까지는 가지만, 서버에서 받은 데이터를 리버스 프록시가 받아 전달해준다.

포워드 프록시 서버의 경우 서버가 클라이언트를 모른다는 점이 특징이었지만, 리버스 프록시의 경우 클라이언트가 실제 서버를 알 수 없다.

리버스 프록시는 보통 다음과 같은 상황에서 많이 사용한다.
- 로드 밸런싱: 리버스 프록시 서버를 단일 서버 앞에 두어, 특정 서버의 과부하를 막는 방법이다.
- 서버 보안: 서버의 IP 주소를 노출시키지 않기 때문에 DDos 공격 차단에 용이하다.
- 캐싱: 포워드 프록시의 캐싱과 유사하다. 마찬가지로 요청을 웹 서버까지 보내지 않고 바로 응답할 수 있다.

포워드 프록시와 리버스 프록시는 비슷한 듯 하지만 꽤 차이가 있다.

	포워드 프록시	리버스 프록시
어디에서?	클라이언트 앞단	웹 서버 / WAS 앞단
통신은?	클라이언트 <-> 프록시	프록시 <-> 웹 서버
실제 웹 요청은?	웹 서버	프록시 서버
감춰지는 정보는?	클라이언트 정보	서버 정보

포워드 프록시는 네트워크 내부에서 요청을 받아서 다른 곳으로 보내준다.

네트워크 안에 있는 컴퓨터가 인터넷에 접속하려고 할 때, 포워드 프록시는 컴퓨터의 요청을 받아서 대신 인터넷으로 보내준다.

그리고, 인터넷에서 받은 정보도 대신 포워드 프록시가 받아서 컴퓨터로 전달해준다. (네트워크 안에서 시작된 요청을 받아서 전달)

반대로 리버스 프록시의 경우, 네트워크 바깥에서 네트워크 내부로 들어오는 요청을 받아서 서버로 전달한다.

밖에서 들어온 요청을 리버스 프록시가 받아서 다시 서버로 보내주고, 요청을 처리한 뒤 응답 역시 리버스 프록시로 보내서 집 밖으로 전달해주는 역할을 해준다. (네트워크 바깥에서 안으로 들어오는 요청 중계)

트랜스페어런트 프록시

리퀘스트 메시지의 패킷 맨 앞에 기록된 수신처 IP 주소를 조사하여 액세스 대상 웹 서버를 판단하는 방법이 트랜스 페어런트 프록시이다.

브라우저에서 웹 서버로 흘러가는 메시지를 가로채서 인터넷으로 전달하는 방법이다.

마찬가지로 응답 역시 가로채서 사용자에게 전달하는 역할이며, 프록시의 존재를 사용자가 인지하지 못한다는 게 특징이다.

보통 리퀘스트 메시지가 한 개로 수렴하도록 네트워크를 구성하고, 수렴되는 곳에 트랜스페어런트 프록시를 설치한다. (혹은 액세스 회선에 설치하기도 한다.)

- 헷갈려서 찾아봤는데... 포워드 프록시는 사용자 컴퓨터에서 웹 서버 접속 시 프록시 서버를 통해 인터넷을 사용하라는 방식으로 설정해야 돼서 클라이언트마다 설정을 해줘야 한다.

하지만 트랜스페어런트 프락시는 '클라이언트 컴퓨터에서 인터넷을 사용하기 위해 반드시 지나가야 하는 게이트웨이'에서 웹 요청을 가로채며 동작하는 방식이라고 한다. (강제로 위임하는 느낌?)

[JPA] OSIV 찍먹하기 2편 - 준영속 상태 엔티티를 지연 로딩하기 (FetchType.EAGER와 N+1 문제, fetch join)

dolmeng2 — Sun, 21 May 2023 19:22:32 +0900

들어가기 전

지난 포스팅에서는 준영속 상태의 엔티티는 지연 로딩할 수 없다고 말했다.

이는, 지연 로딩을 위한 프록시 객체를 초기화하기 위해 영속성 컨텍스트가 필요한데, 준영속 상태의 엔티티는 영속성 컨텍스트의 관리 범위에서 벗어났기 때문이다.

그렇다면, 준영속 상태의 엔티티는 어떻게 처리해야 할까?

글로벌 페치 전략을 LAZY에서 EAGER로 수정하기

간단하게 말하면 지연 로딩을 사용하지 말고, 즉시 로딩을 사용하자는 것이다

@Entity
@Getter
@NoArgsConstructor(access = AccessLevel.PROTECTED)
public class Crew {

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

    @Column(nullable = false)
    private String name;

    @ManyToOne(fetch = FetchType.EAGER)
    @JoinColumn(name = "wootecho_id", nullable = false, foreignKey = @ForeignKey(ConstraintMode.NO_CONSTRAINT))
    private Wootecho wootecho;
}

크루 클래스의 fetch 전략을 EAGER로 설정하였다. (어차피 @ManyToOne의 디폴트 전략이 fetch이기 때문에 명시적으로 설정하지 않아도 똑같다.)

즉시 로딩을 사용하게 되면, Crew를 조회할 때 연관된 엔티티인 Wootecho 역시 함께 가져오게 된다.

실제로 쿼리를 확인해보자.

다음과 같이 Join을 통해 한 번에 가져온 것을 볼 수 있다.

join을 통해 가져오는 거면 더 좋은 거 아니야?

만약, crew 엔티티에 연관된 엔티티가 지금처럼 하나가 아니라 여러 개라면?

@Entity
@Getter
@NoArgsConstructor(access = AccessLevel.PROTECTED)
public class Crew {

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

    @Column(nullable = false)
    private String name;

    @ManyToOne(fetch = FetchType.EAGER)
    @JoinColumn(name = "wootecho_id", nullable = false, foreignKey = @ForeignKey(ConstraintMode.NO_CONSTRAINT))
    private Wootecho wootecho;

    @ManyToOne(fetch = FetchType.EAGER)
    @JoinColumn(name = "wootecho2_id", nullable = false, foreignKey = @ForeignKey(ConstraintMode.NO_CONSTRAINT))
    private Wootecho wootecho2;

    @ManyToOne(fetch = FetchType.EAGER)
    @JoinColumn(name = "wootecho3_id", nullable = false, foreignKey = @ForeignKey(ConstraintMode.NO_CONSTRAINT))
    private Wootecho wootecho3;
}

상당히 어지러운 쿼리가 나가는 것을 볼 수 있다. 심지어, 위 예제는 정말 간단한 예제인데도 여러 join이 걸리게 되는 것이다.

N+1 문제

이는 JPQL을 사용했을 때의 문제이다.

JPQL을 통해 JPA가 SQL을 사용하게 되면, 글로벌 페치 전략은 신경쓰지 않고 JPQL 자체 정보만 사용하기 때문에 연관된 엔티티에 대해서 join 대신 where 절로 묶인 다수 개의 쿼리가 나가게 된다.

이 문제를 재현하기 위해서는 OneToMany 관계를 살펴봐야 하기 때문에, 우테코를 기준으로 조회 API를 생성할 것이다.

우테코 엔티티를 다음과 같이 수정하자.

@Entity
@Getter
@NoArgsConstructor(access = AccessLevel.PROTECTED)
public class Wootecho {
    @Id
    @GeneratedValue(strategy = GenerationType.IDENTITY)
    private Long id;

    @Enumerated(EnumType.STRING)
    private Course course;

    @OneToMany(fetch = FetchType.EAGER, mappedBy = "wootecho")
    private List<Crew> crews;
}

crew에 대한 정보를 추가해주고, 연관관계의 주인을 Wootecho로 설정해주었다.

그리고, JPQL을 사용하기 위해서 위와 같이 커스텀 메서드를 생성해주었다.

public interface WootechoRepository extends JpaRepository<Wootecho, Long> {

    @Query("select w from Wootecho w")
    List<Wootecho> findWootechos();
}

서비스와 컨트롤러, DTO이다. 간단한 예제이기 때문에 추가 설명은 작성하지 않겠다.

// WootechoService.java
@Service
@RequiredArgsConstructor
public class WootechoService {
    private final WootechoRepository wootechoRepository;

    public List<Wootecho> getAll() {
        return wootechoRepository.findWootechos();
    }
}


// WootechoController.java
@RestController
@RequestMapping("/wootecho")
@RequiredArgsConstructor
public class WootechoController {
    private final WootechoService wootechoService;

    @GetMapping
    public ResponseEntity<List<WootechoResponse>> getAll() {
        final List<Wootecho> wootechos = wootechoService.getAll();
        final List<WootechoResponse> result = wootechos.stream()
            .map(WootechoResponse::of)
            .toList();
        return ResponseEntity.ok(result);
    }
}

새로운 WootechoService와 WootechoController를 생성하였다.

이제, 우테코 전체를 조회해보자. 현재 테이블에는 다음과 같이 데이터가 저장되어 있다.

Hibernate: 
    select
        w1_0.id,
        w1_0.course 
    from
        wootecho w1_0
Hibernate: 
    select
        c1_0.wootecho_id,
        c1_0.id,
        c1_0.name 
    from
        crew c1_0 
    where
        c1_0.wootecho_id=?
Hibernate: 
    select
        c1_0.wootecho_id,
        c1_0.id,
        c1_0.name 
    from
        crew c1_0 
    where
        c1_0.wootecho_id=?
Hibernate: 
    select
        c1_0.wootecho_id,
        c1_0.id,
        c1_0.name 
    from
        crew c1_0 
    where
        c1_0.wootecho_id=?

다음과 같이 굉장히 길어진 쿼리가 나간 것을 볼 수 있다. 하나씩 보자.

위와 같이 Wootecho만 조회하려고 했으나, 즉시 로딩으로 인해 Crew에 대한 정보도 가져오면서 1+N개의 쿼리가 발생한 것이다.

JPQL이 코드 분석 시 다음과 같은 절차를 밟으며 발생한 문제이다.

1. select w from Wootecho w를 보고 select * from wootecho 쿼리 생성
2. 생성된 쿼리를 바탕으로 List<Wootecho> 엔티티 생성
3. 쿼리가 생성된 이후, 즉시 로딩 전략으로 인해서 Wootecho와 연관된 Crew 엔티티 역시 함께 즉시 로딩
4. Wootecho 엔티티의 개수만큼 select * from crew where wootecho_id = ? 쿼리 발생

LAZY로 유지하면서 fetch join 사용하기

지연 로딩을 사용하면서, jpql을 호출하는 시점에 한 번에 가져오도록 최적화를 하는 전략이다.

public interface WootechoRepository extends JpaRepository<Wootecho, Long> {

    @Query("select w from Wootecho w join fetch w.crews")
    List<Wootecho> findWootechos();
}

위와 같이 jpql에 join fetch를 추가해주면 된다.

이 상태로 쿼리를 다시 살펴보자.

깔끔하게 join을 이용하여 한 번에 가져온 것을 확인할 수 있다

강제로 초기화하기 - Hibernate.initialize()

영속성 컨텍스트가 살아있을 때 프레젠테이션 계층에서 필요한 엔티티를 강제로 초기화하여 반환할 수 있다.

JPA는 기본적으로 관련 기능을 제공하지 않기 때문에, 하이버네이트에서 제공하는 Hibernate.initialize()를 사용할 수 있다.

우리가 이전 포스팅부터 고민했던 '크루를 조회할 때 우테코 엔티티를 함께 조회하는 경우'에 대해 적용해보자.

public class Crew {
	...
    
    @ManyToOne(fetch = FetchType.LAZY)
    @JoinColumn(name = "wootecho_id", nullable = false, foreignKey = @ForeignKey(ConstraintMode.NO_CONSTRAINT))
    private Wootecho wootecho;
}

다시 Crew 엔티티에서 Wootecho 엔티티의 페치 전략을 LAZY로 설정해준다. (마찬가지로 Wootecho 엔티티의 Crew 역시 LAZY로 설정해주었다.)

// CrewService.java
public Crew getById(final Long wootechoId) {
    final Crew findCrew = crewRepository.findById(wootechoId)
        .orElseThrow(() -> new IllegalArgumentException("존재하지 않는 아이디입니다."));
    Hibernate.initialize(findCrew.getWootecho());
    return findCrew;
}

그리고, 다음과 같이 getById() 메서드에 Hibernate.initialize()를 추가해주었다.

기존에는 no Session Exception이 터졌던 것과 다르게, 잘 조회되는 것을 볼 수 있다.

Hibernate 기술을 직접적으로 사용하는 것이 부담스럽다면, 영속성 컨텍스트가 살아있는 범위에서 프레젠테이션 계층이 사용할 데이터를 실제로 사용해버리는 방법도 있다.

// CrewService.java
public Crew getById(final Long wootechoId) {
    final Crew findCrew = crewRepository.findById(wootechoId)
        .orElseThrow(() -> new IllegalArgumentException("존재하지 않는 아이디입니다."));
    findCrew.getWootecho().getCourse(); // 실제 사용해버리기
    return findCrew;
}

이렇게 해도 위와 동일한 쿼리가 발생하게 된다.

하지만, 이렇게 프록시를 초기화하는 역할을 서비스 계층이 담당하면 뷰가 필요한 엔티티에 따라서 서비스 계층의 로직을 변경해야 한다.

만약 CrewResponse가 아닌 다른 DTO 객체가 생기고, 거기서는 course만 필요한 것이 아닌 name이나 다른 필드들의 값들이 필요하다면? 뷰의 변경사항이 서비스까지 함께 영향을 받기 때문에 유지보수 포인트가 증가하는 것이다.

이를 위해 서비스 계층에서 프레젠테이션 계층을 위한 프록시 초기화 역할을 분리해야 하며, FACADE 패턴을 활용할 수 있다.

서비스 앞단에서 Facade가 1차적으로 프레젠테이션 계층과 도메인 모델 사이의 논리적 의존성을 분리해줌으로서, 프레젠테이션 계층에서 필요한 프록시 객체를 초기화하는 역할을 담당하는 것이다.

@Component
@RequiredArgsConstructor
public class CrewFacade {

    private final CrewService crewService;
    
    public Crew getById(final Long crewId) {
        final Crew crew = crewService.getById(crewId);
        // 프록시 객체가 필요한 데이터 초기화
        crew.getWootecho().getCrews();
        return crew;
    }
}

// CrewController.java
@GetMapping("/{crewId}")
public ResponseEntity<CrewResponse> getById(@PathVariable Long crewId) {
    final Crew crew = crewFacade.getById(crewId);
    return ResponseEntity.ok(CrewResponse.of(crew));
}

하지만... 이런 식으로 중간 계층이 들어가면 결과적으로 개발자가 작성해야 하는 코드가 많아진다는 것이다.

또한, JPA에 대한 이해도가 없는 개발자와 협업을 하게 된다면 해당 코드에 대해 제대로 이해하지 못한 상태로 제거해버리는 상황이 발생할 수도 있다

결국 지금까지의 모든 문제는 '엔티티가 프레젠테이션 계층에서 준영속 상태이기 때문에' 발생했던 문제이다.

이런 원초적인 문제부터 해결을 해보자.

OSIV (Open session In View)

OSIV는 영속성 컨텍스트를 뷰까지 열어둔다는 의미이다. 뷰까지 컨텍스트가 열려 있기 때문에 자동으로 지연 로딩이 가능해지는 것이다.

cf. 참고로, OSIV는 하이버네이트에서 사용하는 용어여서 JPA에서는 OEIV (Open EntityManager In View)를 더 많이 사용하지만, OSIV가 더 익숙하기 때문에 OSIV라고 부르겠다.

OSIV는 여러 방식이 있는데, 클라이언트의 요청과 생명주기가 동일한 Transaction per request OSIV가 존재한다.

요청이 들어오자마자 서블릿 필터나 스프링 인터셉터에서 영속성 컨텍스트를 만들면서 트랜잭션을 시작하고, 요청이 끝날 때 컨텍스트와 트랜잭션을 함께 종료하는 방법이다. 이러면 영속성 컨텍스트가 끝까지 살아 있어서 어디서 조회하든 영속 상태가 되다.

지연 로딩 역시 자유롭게 가능하지만, 엔티티와 트랜잭션 생명주기가 너무 길기 때문에 프레젠테이션 영역에서 엔티티를 자유롭게 참조할 수 있다는 것이다. 엔티티는 코어한 영역이기 때문에 외부에서 쉽게 참조하는 건 좋지 않다. 도메인이 DTO를 참조하지 않는 것과 동일한 영역이라고 봐도 된다. ㅎㅎ

(개인적인 생각으로는 entity가 controller 영역까지 참조되는 걸 선호하지 않기 때문에 그러한 관점에서도 별로다)

그러면, 스프링에서는 어떤 OSIV 전략을 채택하고 있을까?

- 다양한 OSIV 클래스가 있기 때문에 이를 필터나 인터셉터가 등록하여 사용할 수 있다. (중요한 내용은 아니니 생략하겠다)

스프링 프레임워크가 제공하는 OSIV

OSIV를 사용하지만, 비즈니스 계층까지만 트랜잭션을 사용하는 전략이다.

클라이언트 요청이 들어오면 서블릿 필터나 스프링 필터에서 영속성 컨텍스트를 생성하지만, 트랜잭션은 시작하지 않는다.

이후, 서비스 계층에서 @Transactional을 시작할 때 초기에 생성한 영속성 컨텍스트를 바탕으로 트랜잭션을 시작한다.

서비스 계층이 종료되면 트랜잭션 커밋 후 영속성 컨텍스트를 플러시하고, 트랜잭션은 종료하지만 컨텍스트는 종료하지 않는다.

이렇게 되면 프레젠테이션 계층까지 영속성 컨텍스트가 살아있기 때문에 엔티티는 영속 상태를 유지하게 되고, 지연 로딩이 가능하게 된다!

이후 필터나 인터셉터로 요청이 다시 되돌아오면 컨텍스트를 종료해준다. (이때, 플러시를 호출하지 않는다!)

⭐️ 기존의 방법에 비해 프레젠테이션 계층에서는 트랜잭션이 없기 때문에 엔티티에 대한 변경이 불가능하다.

-> 정확하게는, 이미 서비스 계층에서 플러시까지 진행되었고 필터-인터셉터에서도 플러시를 호출하지 않기 때문에, 플러시를 호출하지 않아 엔티티의 변경사항에 대해 DB로 반영하지 않는 것이다.

-> 강제로 플러시하더라도 트랜잭션 범위 밖이라 수정할 수 없다는 예외가 발생한다. (TransactionRequiredException)

하지만, 지연 로딩을 통해서 엔티티를 조회해올 수 있기 때문에 단순히 조회는 가능하게 되는 것이다.

여기서 중요한 건, 영속성 컨텍스트가 살아있기 때문에 내부에 변경사항이 저장되어 있는 것이다.
프레젠테이션 레이어에서 @Transactional 포함한 비즈니스 로직을 호출하게 되면 해당 비즈니스 로직이 종료될 때 이미 이전에 저장되었던 변경사항을 함께 flush 해버리기 때문에 예기치 못한 버그가 발생할 수도 있다.
- 보통은 컨트롤러에서 서비스를 먼저 호출하기 때문에 이런 일은 거의 없겠지만...
플러시를 호출하지 않아서 변경사항을 반영하지 않는다는 점을 기억하자!

다시 돌고 돌아서...

스프링부트는 기본적으로 OSIV를 true로 설정해두었기 때문에 뷰까지 데이터를 참조한다.

하지만 개인적으로 OSIV 옵션은 끄고 사용하는 것이 좋다고 생각한다.

우선 DB 커넥션을 계속 잡고 있기 때문에 리소스의 낭비가 발생할 수 있기 때문이다.

(지연 로딩을 통해서 받아오려면 아무튼 커넥션이 살아 있어야 하니까)

또한, 스프링의 OSIV 전략은 프레젠테이션의 데이터 변경은 막지만, 애초에 프레젠테이션까지 엔티티가 참조 관계를 가지는 건 레이어의 단방향 흐름을 깬다고 생각하기 때문이다. (같은 의미로 DTO 역시 서비스 레이어에서 생성한 다음에 뷰로 반환하는 것을 선호한다.)

각 레이어간의 단방향 관계를 유지하기 위해서는 엔티티에 대한 조작은 서비스 레이어까지만 진행하고, 이후 뷰에 처리될 데이터는 DTO를 통해 연관관계를 끊은 상태로 조작하는 게 더 좋다는 것이 나의 의견이다

(그리고 성능 최적화 방법으로 Command-Query separation 이라는 것도 있던데, 핵심 로직과 뷰 관련 서비스 로직을 분리하는 것이다. 나중에 미션할 때 한 번 이걸로 적용해봐야겠다...)

[JPA] OSIV 찍먹하기 1편 - 프록시 객체와 준영속 상태 엔티티

dolmeng2 — Sun, 21 May 2023 16:44:21 +0900

금요일에 근로하면서 구구와 근로 크루들의 도움 덕분에 JPA를 다시금 공부하게 됐다

나도 완전하게 잘 아는 내용은 아닌지라 아는대로 정리해보고자 한다.

영속성 컨텍스트와 트랜잭션

영속성 컨텍스트란?
엔티티를 영속화시키는 환경. EntityManager를 통해 엔티티를 저장하거나 조회하면 영속성 컨텍스트에 보관된 엔티티 정보를 바탕으로 요청을 처리하게 된다. EntityManager 생성 시 1개가 만들어진다.

특징
- 식별자 값으로 엔티티를 구분한다.
- 트랜잭션 커밋 시점에 flush. (쓰기 지연 - 내부 쿼리 저장소에 SQL 저장 후 한 번에 플러시)
- 1차 캐시를 사용한다. (처음에 1차 캐시에서 엔티티 조회 > 없으면 DB 조회 > 1차 캐시에 저장하는 형태 = '영속화')
- 1차 캐시에 저장된 엔티티는 == 비교가 가능하다. (동일성 보장)
- 변경 감지 ('영속 상태의' 변경된 엔티티에 대해서 업데이트 쿼리 저장 > 플러시 > 트랜잭션 커밋)

트랜잭션이 시작되면 영속성 컨텍스트도 생성되고, 종료되면 컨텍스트도 함께 종료되는 것이다.

그리고, 동일한 트랜잭션 안에서는 항상 같은 영속성 컨텍스트에 접근하게 된다.

여기서 말하는 트랜잭션은 우리가 스프링을 개발하면서 사용한 @Transactional 어노테이션의 범위를 의미한다.

@Transactional이 붙어있으면 해당 메서드를 호출하기 전에 트랜잭션 AOP가 먼저 동작하는데 (이에 대해서는 추후 다루어 보겠다.) 간단하게 생각하면 해당 메서드를 호출하기 전에 트랜잭션을 시작하고, 정상적으로 종료되면 트랜잭션 커밋 후 종료하는 것이다.

이때, JPA에서는 영속성 컨텍스트를 플러시하여 변경 사항을 DB에 반영한 뒤, DB 트랜잭션을 커밋하게 된다.

흔히 우리는 관습적으로 개발할 때 @Transactional 어노테이션을 서비스 레이어에 붙이곤 한다.

그렇기 때문에 서비스 계층이 끝나는 시점에 트랜잭션이 종료되며 영속성 컨텍스트도 함께 종료되어, 서비스와 레파지토리 레이어에서는 영속 상태인 엔티티가 컨트롤러나 뷰 같은 presentation layer에서는 준영속 상태가 된다.

그래서 컨트롤러나 뷰 (혹은 DTO)에서 준영속 상태인 엔티티를 통해 지연 로딩을 시도하면 예외가 발생한다.

지연 로딩 (Lazy Loading)이란?
- 엔티티를 조회할 때 연관된 엔티티에 대해 실제 DB에서 바로 접근하지 않고, 연관된 엔티티를 실제로 사용하는 시점에 로딩하는 방법. 지연 로딩을 사용하기 위해서는 실제 엔티티 객체 대신에 데이터베이스 조회를 지연할 수 있는 가짜 객체가 필요하며, 이를 위해 프록시 객체를 사용한다.
- OneToMany, ManyToMany에서 디폴트로 사용하는 전략이다.

하지만, 스프링 부트를 활용하여 개발할 때는 다르다.

처음 스프링부트 애플리케이션을 활성화시키면 아래와 같은 문구가 뜨는 것을 볼 수 있을 것이다.

spring.jpa.open-in-view is enabled by default. Therefore, database queries may be performed during view rendering. Explicitly configure spring.jpa.open-in-view to disable this warning

기본적으로 스프링부트는 OSIV를 활성화하기 때문에 view rendering 시점까지 DB 쿼리의 영향을 받을 수 있다는 것이다.

이론만 보면 당연히 이해하기 힘들다. 간단한 클래스를 구성하여 직접 살펴보자.

(OSIV에 대해서는 다음 포스팅에서 더 자세히 다룰 예정이다.)

프록시 객체

JPA를 생각하면 뺄 수 없는 개념 중 하나가 프록시 객체이다.

코드를 보기 전에 간단하게 프록시 객체가 어떤 것인지 짚고 넘어가보자.

JPA에서 엔티티를 하나 조회할 때는 EntityManager.find()라는 메서드를 사용하는데, 이는 영속성 컨텍스트에 엔티티가 없으면 실제 DB를 조회하는 메서드이다. 하지만, 이런 식으로 직접 조회하게 되면 해당 엔티티의 사용 여부와 관계없이 무조건 DB를 조회하기 때문에 cost가 매우 높다. 만약 DB 조회를 실제 사용 시점까지 미루고 싶다면 EntityManager.getReference()를 사용하게 된다.

이는 DB 조회 대신에 이를 대체할 프록시 객체를 생성하게 된다.

이러한 프록시 객체를 생성하기 위해서는 '상속'을 사용하기 때문에 기본 생성자가 필요하다.

생성자가 아예 없는 상황이라면 컴파일러가 알아서 만들어주지만, 하나라도 다른 생성자가 있으면 만들어주지 않기 때문에 기본 생성자는 웬만하면 만들어줘야 한다.

프록시 객체는 실제 객체에 대한 참조값을 가지고 있다가, 프록시 객체의 메서드를 호출하면 실제 객체의 메서드를 호출해준다.

위의 상황에서 프록시 객체는 crew.getName()을 통해 직접 접근하게 되면 실제 DB를 조회하여 실제 엔티티를 생성하게 되는데, 이를 '프록시 객체의 초기화'라고 한다.

1. 프록시 객체의 crew.getName()을 호출하여 실제 데이터 조회하기
2. 실제 엔티티가 생성되지 않았다면, 영속성 컨텍스트에게 실제 엔티티의 생성 요청
3. 영속성 컨텍스트는 DB를 조회하여 실제 엔티티 객체 생성
4. 프록시 객체는 생성된 엔티티 객체의 참조를 보관
5. 보관한 참조값(crew)의 getName()을 호출하여 결과 반환

이러한 프록시 객체는 처음 사용될 때 딱 한 번만 초기화된다.

또한, 영속성 컨텍스트에 이미 엔티티가 있으면 DB를 조회할 필요가 없기 때문에 em.getReference()를 호출해도 프록시 객체 대신 실제 엔티티를 반환하게 된다!

자세한 내용은 차차 JPA 공부하면서 올릴 예정!

테이블 설계

✔️ Entity

@Entity
@Getter
@NoArgsConstructor(access = AccessLevel.PROTECTED)
public class Wootecho {

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

    @Enumerated(EnumType.STRING)
    private Course course;
}

우테코 클래스이다. Course라는 enum에는 백엔드, 프론트, 안드로이드라는 과정 정보가 들어가있다.

@Entity
@Getter
@NoArgsConstructor(access = AccessLevel.PROTECTED)
public class Crew {

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

    @Column(nullable = false)
    private String name;

    @ManyToOne(fetch = FetchType.LAZY)
    @JoinColumn(name = "wootecho_id", nullable = false, foreignKey = @ForeignKey(ConstraintMode.NO_CONSTRAINT))
    private Wootecho wootecho;
}

간단한 크루 클래스이다.

크루 클래스와 우테코 클래스는 N:1의 관계를 가지고 있으며, 이때 지연 로딩 전략을 채택하였다. (FetchType.LAZY)

또한, 외래키 제약 조건에 대한 설정을 지정해주지 않았다.

실제 테이블의 관계는 아래와 같이 맺어진다.

하지만, 이는 논리적인 연관관계일 뿐이며 실제로 테이블 스크립트를 보면 아래와 같이 외래키 제약조건이 설정되지 않은 것을 볼 수 있다.

CREATE TABLE `wootecho` (
  `id` bigint NOT NULL AUTO_INCREMENT,
  `course` varchar(255) DEFAULT NULL,
  PRIMARY KEY (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb3

CREATE TABLE `crew` (
  `id` bigint NOT NULL AUTO_INCREMENT,
  `name` varchar(255) NOT NULL,
  `wootecho_id` bigint NOT NULL,
  PRIMARY KEY (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb3

crew 테이블은 단순히 wootecho_id라는 필드를 가지고 있을 뿐이지, 외래키로 걸려있지 않다.

이는 다음과 같은 설정 때문이다.

@JoinColumn(... foreignKey = @ForeignKey(ConstraintMode.NO_CONSTRAINT))
private Wootecho wootecho;

여기서 foreignKey = @ForeignKey(ConstraintMode.NO_CONSTRAINT) 를 설정해주면, 물리적인 외래키를 맺지 않게 된다.

실제로 실무에서는 외래키를 걸지 않는 경우가 많다.

외래키를 걸면 데이터의 무결성은 보장할 수 있지만 (부모가 삭제되었을 때 고아로 남은 자식 필드가 남지 않도록 함)

자식 테이블의 INSERT 연산 시에 부모 테이블도 확인해야 하고, 변경 시에도 고려해야 할 점이 많고, 테스트하기도 어렵기 때문이다.

영한님은 이에 대해서 아래와 같이 답변을 남겨주신 적이 있다.

나 역시 개인적으로 외래키를 거는 걸 선호하지만... 아마 작은 도메인만 만져봤기 때문일 것 같다

아무튼, 이게 중요한 것은 아니다. 도메인을 위와 같이 설계했고, 레파지토리와 서비스, 컨트롤러는 다음과 같다.

✔️ Repository

public interface CrewRepository extends JpaRepository<Crew, Long> {

}

흔히 사용하는 Jpa를 사용한 레파지토리 구성이다.

✔️ Service

@Service
@Transactional(readOnly = true)
@AllArgsConstructor
public class CrewService {

    private final CrewRepository crewRepository;

    public Crew getById(final Long wootechoId) {
        final Crew findCrew = crewRepository.findById(wootechoId)
            .orElseThrow(() -> new IllegalArgumentException("존재하지 않는 아이디입니다."));
        return findCrew;
    }
}

서비스에서는 단순히 아이디를 통해 크루 엔티티를 조회해오는 로직만 있다.

✔️ Controller

@RestController
@RequestMapping("/crew")
@AllArgsConstructor
public class CrewController {

    private final CrewService crewService;

    @GetMapping("/{crewId}")
    public ResponseEntity<CrewResponse> getById(@PathVariable Long crewId) {
        final Crew crew = crewService.getById(crewId);
        return ResponseEntity.ok(CrewResponse.of(crew));
    }
}

컨트롤러이다. 여기서 주목할 점은 서비스에서 엔티티를 받아와서 dto로 변환하는 로직을 이곳에서 한다는 것이다.

✔️ Dto

@Getter
@AllArgsConstructor(access = AccessLevel.PRIVATE)
public class WootechoResponse {
    private final Long id;
    private final String course;

    public static WootechoResponse of(final Wootecho wootecho) {
        return new WootechoResponse(wootecho.getId(), wootecho.getCourse().name());
    }
}

@Getter
@AllArgsConstructor(access = AccessLevel.PRIVATE)
public class CrewResponse {

    private final Long id;
    private final String name;
    private final WootechoResponse wootechoResponse;

    public static CrewResponse of(final Crew crew) {
        return new CrewResponse(crew.getId(), crew.getName(), WootechoResponse.of(crew.getWootecho()));
    }
}

크루에 대한 응답 정보를 나타내기 위해서 crew 엔티티에 있는 값들과 연관된 엔티티인 wootecho 엔티티를 가져오고 있다.

정말 간단한 조회용 API가 완성되었다.

현재 도메인 구조는 이렇게 구성되어 있다.

준영속 상태와 지연 로딩

준영속 상태에서는 지연 로딩이 동작하지 않는다.

준영속 상태 엔티티란?
영속성 컨텍스트가 관리하던 영속 상태인 엔티티가 더 이상 영속성 컨텍스트에 의해 관리되지 않는 상태

지연 로딩을 사용하기 위해서는 프록시 객체를 설정해주고, 엔티티 조회 시 연관된 엔티티에 대해 프록시 객체를 조회한다.

하지만, 준영속 상태인 엔티티는 영속성 컨텍스트가 없기 때문에 지연 로딩 자체가 불가능해진다.

이를 실제로 확인해보자.

우선, 앞서 말했던 것처럼 스프링부트는 기본적으로 뷰까지 DB 쿼리가 날라가는 것을 허용하기 때문에 이 옵션을 꺼야 한다.

spring:
  jpa:
    open-in-view: false

application.yml에서 open-in-view 옵션을 false로 설정해준다.

그리고, 크루 1명을 조회하는 API 요청을 날려보자. 나는 '져니'라는 크루를 조회할 예정이다.

could not initialize proxy [com.example.study.osiv.Wootecho#1] - no Session

세션이 없기 때문에 proxy를 초기화할 수 없다고 나온다.

지연 로딩을 하기 위해서는 연관된 엔티티를 '프록시 객체'로서 만들어두고, 사용 시점에 쿼리를 날린다고 말했었다.

// CrewResponse.java
public static CrewResponse of(final Crew crew) {
    return new CrewResponse(crew.getId(), crew.getName(), WootechoResponse.of(crew.getWootecho()));
}

CrewResponse의 코드이다. 여기서 crew.getWootecho()를 통해 조회를 할 때에는 담겨있던 프록시 객체를 호출하게 된다.

실제로 보면, HibernateProxy라는 친구를 통해서 프록시 객체를 가져온 것을 볼 수 있다.

// WootechoResponse.java
public static WootechoResponse of(final Wootecho wootecho) {
    return new WootechoResponse(wootecho.getId(), wootecho.getCourse().name());
}

그리고, WootechoResponse에서 실제로 값을 채워넣으려고 할 때 프록시 객체를 초기화하면서 실제 값을 채워넣으려고 하자 오류가 발생한 것이다.

dto 변환을 controller = presentation layer에서 하면서, 그림과 같이 서비스 레이어를 지나 트랜잭션 범위가 끝나면서 영속성 컨텍스트도 함께 제거되었기 때문이다. no session이라는 것이 곧 EntityManager가 없어서 값을 가져올 수가 없던 것이다.

service 레이어에서 조회해온 Crew 엔티티는 '영속 상태'였으나, controller 레이어로 넘어오면서 영속성 컨텍스트가 제거되어 Crew 엔티티는 준영속 상태의 엔티티가 되었다.

사실 가장 좋은 방법은 컨트롤러에서 반환하지 않고, 그냥 서비스에서 DTO를 반환하도록 코드를 개선하는 것이다.

// CrewService.java
public CrewResponse getById(final Long wootechoId) {
    final Crew findCrew = crewRepository.findById(wootechoId)
        .orElseThrow(() -> new IllegalArgumentException("존재하지 않는 아이디입니다."));
    return CrewResponse.of(findCrew);
}

이렇게 되면 영속성 컨텍스트 범위가 살아있는 범위에서 프록시 객체 초기화가 가능하기 때문에 걱정할 필요가 없다.

하지만, 우리는 컨트롤러에서 엔티티를 dto로 변환하는 작업은 할 수 없는 것일까?

다음 포스팅에서 어떻게 하면 이를 개선할 수 있을지 살펴보자.

[Network] 방화벽의 패킷 필터링 과정 알아보기

dolmeng2 — Fri, 19 May 2023 00:42:25 +0900

들어가기 전

지난 포스팅까지는 클라이언트 측 LAN에서 라우터까지 어떻게 패킷이 흘렀는지 알아보았었다.

그 이후로도 전기 신호로 변환되고, 패킷이 중계되고, 통신 회선이나 프로바이더의 네트워크를 통해 서버 측으로 어떻게 이동하는지 그러한 과정이 있지만 내용이 너무 깊은 것 같아서 생략했다.

이번 포스팅에서는 웹 서버에서 어떤 식으로 요청이 처리되는지 알아보고자 한다.

웹 서버는 어디에 설치될까요?

과거에는 사내의 LAN에 서버를 설치한 다음, 인터넷에서 직접적으로 액세스했다.

이러면 패킷은 액세스 회선, 서버측 라우터를 경유해서 서버 머신에 도착하여 패킷이 흐르게 된다.

하지만, 이 방법은 서버와 클라이언트 모두에 글로벌 주소를 할당해야 돼서 IP 주소가 부족해진다.

또한, 서버가 직접적으로 노출되기 때문에 보안적으로도 좋지 않다.

그래서 요즘은 방화벽을 통해서 특정 서버에서 동작하는 특정 애플리케이션에 접근하는 패킷만 통과하고, 나머지 패킷은 차단시켜서 보안적 측면을 보완하였다.

혹은, 회사 내에 설치하지 않고 프로바이더가 운영하는 데이터센터 시설에 서버를 가지고 들어가서 설치하거나, 프로바이더가 소유하고 있는 서버를 빌려쓰는 형태로 운영하는 경우도 있다.

여기서 프로바이더는, 서비스를 제공하는 인터넷 통신사를 의미한다.

데이터센터는 대부분 프로바이더 중심 부분 쪽과 직결되어 있어 서버 설치 시 고속으로 액세스 가능하다는 장점이 있다. 설치 장소도 단순 회사보다 안전한 건물 내에 설치하는 경우가 많기 때문에 안전성이 높다.

아무튼 이 경우에는 인터넷 중심 부분에서 데이터 센터로 패킷이 흘러가고, 서버 머신에 도착하기 때문에 데이터 센터 쪽에 방화벽이 설치되어 있다면 1차적으로 걸러진 패킷에 대해서 패킷이 받게 된다.

두 경우 모두 라우터에서 중계되고, 최종적으로 서버에 도착한다는 것은 동일하다.

방화벽의 원리와 동작 과정

패킷 필터링

방화벽은 기본적으로 특정 서버와 해당 서버 내부의 특정 애플리케이션에 액세스하는 패킷만 통과시키고, 나머지는 차단시킨다.

여기서 어떤 기준으로 패킷을 통과시키고 거르는지는 다양한 방법이 있지만 (패킷 필터링, 애플리케이션 게이트웨이, 서킷 게이트웨이 등) 여기서는 패킷 필터링에 대해서 중점적으로 다루어보자.

궁금해서 간단하게 애플리케이션 게이트웨이와 서킷 게이트웨이에 대해서 찾아보았다.

- 애플리케이션 게이트웨이
OSI 7계층의 응용 레이어에서 동작하는 게이트웨이이다.
방화벽의 프록시를 이용하여 사용할 수 있으며, 서비스마다 다른 프록시 서버를 통해서 연결하는 방법이다.
패킷 필털이 방식보다 비교적 높은 보안성을 가지고 있지만, 하드웨어에 의존적이고 응용 계층에서 동작하다 보니 네트워크에 부하가 많이 든다.

- 서킷 게이트웨이
OSI 7계층에서 세션 레이어, 응용 레이어에서 사이에서 동작하는 게이트웨이이다.
서비스마다 프록시 서버가 있는 것이 아닌, 하나의 프록시를 통해 모든 서비스를 처리할 수 있도록 만들었다.

패킷 필터링의 조건에서는 아래와 같은 설정 정보들을 자주 사용한다.

헤더의 종류	조건 설정에 사용하는 항목	설명
MAC 헤더	송신처 MAC 주소	라우터는 패킷 중계 시 MAC 주소를 바꿔쓴다. - 중계 대상 라우터의 MAC 주소는 수신처 MAC 주소 항목에, 자신의 MAC 주소는 송신처 MAC 주소 항목에 기록한다. - 이때, 송신처 MAC 주소를 통해서 직전에 중계한 라우터의 MAC 주소를 알 수 있게 된다.
IP 헤더	송신처 IP 주소	패킷을 최초로 송신한 기기의 IP 주소. 패킷을 송신한 기기를 조건으로 설정하는 경우에 사용한다.
	수신처 IP 주소	패킷을 건네줄 대상의 IP 주소. 패킷이 갈 목적지를 조건으로 설정하는 경우에 사용한다.
	프로토콜 번호	주요 프로토콜 번호는 다음과 같다. - IP:0, ICMP:1, TCP:6, UDP:17, OSPF:89
TCP 헤더 or UDP 헤더	송신처 포트 번호	패킷을 송신한 프로그램에 할당된 포트번호. - 서버 프로그램에 할당된 포트 번호는 고정되기 때문에 서버 측에서 반송된 패킷에 적힌 포트 번호를 통해서 서버에 대한 판별이 가능하다. - 클라이언트 프로그램의 포트 번호는 랜덤으로 할당되기 때문에 판단하기 어렵다.
	수신처 포트 번호	패킷을 건네줄 대상의 프로그램에 할당된 포트 번호. - 마찬가지로 서버의 포트 번호는 조건 설정으로 많이 하는데, 클라이언트 포트 번호는 거의 하지 않는다.
	TCP 컨트롤 비트	TCP 프로토콜 제어 시 사용하는 정보이다. ACK: 유효함 (정확하게 도착) PSH: 송신 버퍼테 저장 없이 바로 송신 RST: 접속을 강제로 종료 SYN: 통신 개시 시 접속 동작에서 최초로 보낸 패킷의 SYN=1, ACK = 0 이때 이 패킷을 필터링 하면 그 뒤의 동작을 차단할 수 있다. FIN: 연결 끊음
	프레그먼트	IP 프로토콜의 조각 나누기 기능으로 패킷을 분할하고, 이 패킷이 두 번째 이후임을 나타낸다.
ICMP 메시지	ICMP 메시지 유형	ICMP 메시지는 패킷 배송 도중에 이상이 있거나, 통신 상대의 동작을 확인할 때 사용한다. 0: ping 명령으로 보내는 ICMP 에코 메시지에 응답하는 것. - 0과 8을 차단하면 ping 명령의 응답은 돌아오지 않는다. (어떤 기기가 네트워크에 존재하는지 ping 명령어로 찾을 때가 많은데 그런 걸 차단해버리는 거임) 8: ping 명령을 실행하면 ICMP 에코 메시지가 송싱되는데, 이를 ICMP 에코라고 한다.

공개용 서버를 설치한 LAN과 사내 LAN이 분리되어 있고, 웹 서버는 공개 서버용 LAN에 접속되어 있다고 생각해보자.

패킷 필터링 조건 설정 시 먼저, 송/수신처 IP 주소에 따라서 시작점과 종점을 판단한다.

인터넷에서 웹 서버로 패킷이 들어오다면 종점인 수신처 IP 주소가 실제 웹 서버의 IP 주소와 일치하는지 판단하여 패킷을 통과시키게 된다.

그리고 이러한 조건들을 위와 같이 작성해두어서 필터링을 진행하는 것이다.

첫 번째 행을 보자. 송신처 IP, 포트 번호는 어떤 것이든 상관없지만 수신처 IP / 포트번호가 일치해야 해당 요청이 들어오게 된다.

- 여기서 포트 번호까지 보는 것은 애플리케이션까지 한정시키려고 하는 것이다. 여기서는 웹 서버에서 흔히 사용하는 80번으로 고정시킨 사례를 보는 것이다.

하지만, 단순히 수신처로 패킷이 필터링되어 들어가는 것뿐만 아니라 수신처가 패킷을 잘 받았는지 다시 송신처에게 알려야 한다.

이 경우 반대로 수신처의 IP, 포트 번호는 상관 없이 송신처의 IP / 포트번호가 패킷을 보냈던 곳인지 판단해야 한다.

IP / 포트 번호만으로는 부족해!

사실 IP와 포트 번호를 통해서 어떤 웹 서버의 애플리케이션으로 패킷이 들어오게 할지는 정했다.

하지만, 웹 서버 측에서 인터넷 쪽으로 액세스하는 동작은 어떻게 컨트롤할 수 있을까?

단순히 웹 서버에서 인터넷으로 흐르는 패킷을 정지시키면 양방향 통신인 TCP 프로토콜에 의해 인터넷에서 웹 서버 측으로 흐르게 하는 것도 정지하게 된다.

이를 위해 TCP 헤더의 컨트롤 비트를 사용한다.

앞서 말한 것처럼 최초의 패킷만 SYN=1, ACK=0으로 설정되는데, 인터넷 -> 웹 서버로 보내는 이 값을 차단했다고 생각해보자.

그러면 최초의 패킷에 대해서 응답하는 경우가 없기 때문에 웹 서버 -> 인터넷 측으로 패킷이 흐르지 않게 된다.

그래서 인터넷에 액세스를 하려고 해도 접속 동작이 무조건 실패하게 된다.

반대로 인터넷 -> 웹 서버로 패킷이 흐를 때 최초의 패킷의 수신처는 '웹 서버'가 될 것이다.
그러면 표의 첫 번째 행이 일치해서 통과할 것이다.
이후, 두 번째 패킷은 송신처가 웹 서버가 될 것이지만, 최초의 패킷이 아니기 때문에 컨트롤 비트가 SYN=1, ACK=0이 아닐 것이다.

그래서 두 번째 행의 조건에 일치하지 않게 되면서 세 번째 조건으로 가게 되고, 패킷이 통과하게 될 것이다.

이런 식으로 이후에 인터넷 -> 웹 서버로 흐르는 패킷들은 모두 첫 번째나 세 번째 행을 통과하여 패킷 필터링이 통과하게 된다.

항상 완전하게 통과시키거나 차단시킬 수 있을까?

TCP가 아닌 UDP에서도 완전하게 위의 구조가 동작할까?

우리는 이전에 DNS 서버를 통해 IP 주소를 얻어오는 행위는 UDP 프로토콜을 사용한다고 배웠었다.

하지만, UDP의 경우 별도의 접속 단계가 없기 때문에 TCP처럼 컨트롤 비트를 통해 액세스 방향을 판별할 수 없다.

그래서 웹 서버 -> 인터넷은 허용하지만 인터넷 -> 웹 서버는 차단하도록 만들 수는 없다.

이때는 어느 정도의 위험성을 가지고 패킷을 전부 통과하거나, 전부 차단하는 방법을 선택해야 한다.

사내 LAN과 공개 서버 LAN

위에서 봤던 그림을 다시 보자.

지금까지는 인터넷 <-> 공개 서버용 LAN 패킷을 고려하였지만, 사실 사내 LAN <-> 인터넷 사이의 패킷 왕래도 고려해야 한다.

패킷 필터링형 방화벽은 패킷 통과 및 차단뿐만 아니라 주소 변환 기능도 가지고 있기 때문에, 인터넷 <-> 사내 LAN을 왕래하는 패킷 사이의 주소 변환 기능도 필요하다.

보통 인터넷 라우터의 라우팅 테이블에는 프라이빗 주소를 등록하지 않아서 프라이빗 주소로 갈 패킷을 중계하지 않고 버리기 때문에 주소 변환이 필요하다.

하지만, 방화벽에 내장되어 있는 라우터는 사용자가 스스로 설정할 수 있기 때문에 프라이빗 주소를 등록하면 프라이빗 주소 그대로 공개 서버용 LAN과 사내 LAN 사이에서 패킷을 중계할 수 있다. 그래서 별도로 공개 서버용 LAN과 사내 서버용 LAN을 왕래하는 패킷은 주소 변환을 할 필요가 없다!

방화벽은 패킷을 통과시키기 전에 출발지 IP 주소와 도착지 IP 주소를 확인하고 필요한 경우 주소 변환을 작업을 진행한다.

이때, 패킷 필터링형 방화벽의 경우 프라이빗 IP 주소와 글로벌 IP 주소 간의 대응을 자동으로 처리할 수 있다.

만약 내부 네트워크에서 출발한 패킷의 프라이빗 IP 주소를 방화벽이 감지하게 되면, 해당 주소를 인터넷에 접속하기 위해 할당된 글로벌 IP 주소로 변환하고 (주소 변환 테이블 참고), 변환된 패킷은 인터넷에 전송된다. 포트 번호 역시 마찬가지로 안 쓰는 포트로 변환하고, 나중에 원래의 포트로 변환하는 그런 작업을 진행한다. (이전 포스팅에서 설명했던 과정과 비슷하다.)

결과적으로 방화벽에 패킷이 도착하면, 조건에 해당하는지 판단하고 패킷을 중계한다.

패킷 중계 동작은 라우터와 거의 비슷하기 때문에 패킷이 통과하는지가 가장 중요하다.

(참고로, 패킷을 버리게 되면 버린 기록을 남기게 된다. 침입자 로그 확인용도...? 근데 라우터 자체를 방화벽으로 사용하게 되면 메모리가 적어서 보통 로그를 안 남긴다고 한다)

하지만, 방화벽으로 모든 공격을 막는 것은 당연히 안 된다.

방화벽은 단순히 시점과 종점만을 확인하기 때문에 패킷 사이에 특수한 데이터는 알 수가 없다.

그래서 패킷 내용을 조사해서 위험한 데이터가 들어있는지 판단해서 차단하는 장치나 그런 걸 준비하는 것이 중요하다.

패킷 필터링형 방화벽은 수신처 IP 주소, 송신처 IP 주소, 수신처 포트 번호, 송신처 포트 번호, 컨트롤 비트 등으로 패킷을 통과시킬지 판단한다.

[우테코 5기] 장바구니 미션 회고

dolmeng2 — Mon, 15 May 2023 16:24:29 +0900

헙크와 진행한 레벨 2 두 번째 페어 프로그래밍 미션인 장바구니 미션이다!

어쩌다 보니 레벨 1 데일리 조 팀원들과 한 번씩 페어 프로그래밍을 하는 느낌이다 ㅎ_ㅎ 재밌다!

이번 미션에서는 요구사항보다는 개인적으로 진행하고 싶은 부분들에 대해 구현하다 보니 되게 재밌게 구현했었다.

하지만... 지금 와서 코드를 보니 아직 많이 부족하다는 생각이 들었다 ... 어렵다!

✔️ 작성한 코드

GitHub - Cl8D/jwp-shopping-cart: 레벨 2 장바구니 미션 레파지토리

레벨 2 장바구니 미션 레파지토리. Contribute to Cl8D/jwp-shopping-cart development by creating an account on GitHub.

github.com

✔️ 1차 PR

[1단계 - 상품 관리 기능] 져니(이지원) 미션 제출합니다. by Cl8D · Pull Request #202 · woowacourse/jwp-shopp

안녕하세요, 코지! 백엔드 5기 크루 져니입니다 ‍♀️ 이번에 헙크와 레벨 2 두 번째 미션인 장바구니 기능을 구현해보았어요. 조금 더 이것저것 해보고 싶어서 상품에 대한 카테고리 필드

github.com

✔️ 2차 PR

[2단계 - 장바구니 기능] 져니(이지원) 미션 제출합니다. by Cl8D · Pull Request #270 · woowacourse/jwp-shoppi

안녕하세요, 코다! ‍♀️ 지난 1단계 미션 때 빠르게 피드백 해주셔서 2단계도 금방 진행할 수 있었어요. 감사드려요! 개인적인 욕심으로 여러 가지 기능을 더 구현하고 싶기는 했는데, 먼저

github.com

✔️ 기능 요구사항

- 상품 목록 페이지 연동하기 (Thymeleaf)

- 상품 관리 CRUD API 작성하기

- 관리자 도구 페이지 연동하기

- 상품 도메인 설계 (자유롭게, ID, 이름, 이미지 URL, 가격은 고정)

- 사용자 도메인 설계 (자유롭게, 이메일, 비밀번호는 고정)

- 사용자 설정 페이지 연동

- 장바구니 기능 구현 (상품 추가, 제거, 목록 조회, Basic 인증 방식)

나는 여기다가 사용자 추가, 상품 카테고리 기능, 관리자 기능, api 문서까지 적용해두었다.

rest-docs 관련해서는 추가적으로 글을 작성할 예정이다 ㅎ_ㅎ

늘 그랬듯이 고민했던 부분과 나름의 솔루션에 대해서 작성해보고자 한다.

Redirect가 무엇일까?

사실 이거는... 내가 리다이렉트에 대한 개념을 제대로 잡지 못해서 발생한 문제였다

@GetMapping
public String getProducts(final Model model) {
    final List<ProductDto> products = productService.getProducts();
    model.addAttribute("products", products);
    return "admin";
}

위와 같은 코드에서 뷰 이름을 반환하는 것은 리다이렉트로 봐야 하냐고 질문을 드렸었다.

리다이렉트는 요청한 리소스가 다른 위치에 있으니, 해당 리소스 위치를 반환할 때 사용하는 것이다.

-> 해당 리소스의 주소로 다시 요청을 날리는 것과 동일하다.

위와 같이 뷰 이름을 반환하는 것은 단순히 요청에 대한 렌더링을 해주는 것이기 때문에 리다이렉트로 보기는 어렵다.

이거는 추가적으로 JS 쪽 코드인데... 관련은 없지만 새롭게 안 거여서 정리해둔다.

	location.href	location.replace
기능	새로운 페이지로 이동	기존 페이지를 새로운 페이지로 변경
형태	속성	메서드
주소 히스토리	기록된다 (뒤로 가기 가능)	기록되지 않는다
예시	location.href=""	location.replace("")

유효성 검사는 어디에서 해야 하는가? - 도메인 vs DTO

public class ProductDto {

    @Length(min = 1, max = 25, message = "상품 이름의 길이는 {min} ~ {max}글자여야 합니다.")
    private final String name;

    private final String imageUrl;

    @NotNull(message = "상품 가격은 비어있을 수 없습니다.")
    @Range(min = 0, max = 10_000_000, message = "상품 가격은 {min} ~ {max}원까지 가능합니다.")
    private final Integer price;

    @NotNull(message = "상품 카테고리는 비어있을 수 없습니다.")
    private final ProductCategory category;
}

처음 코드를 작성했을 때는 위와 같이 DTO에서 이름, 가격에 대한 세부 조건들도 제어할 수 있도록 validation 어노테이션을 활용하였었다.

저는 개인적으로 유효성 검사도 여러가지 종류가 있다고 생각하는데요.
1. 비즈니스와 관련된 유효성 검사
2. 단순 유효성 검사
요렇게 나누어서 처리할 수 있는 레이어가 있다고 생각해요!

하지만 리뷰어님은 다음과 같이 유효성 검사를 하는 부분을 나눠보는 게 어떠냐고 이야기를 해주셨다.

당시에는 validation annotation에 굉장히 집착(?)을 하고 있었어서, 도메인에서 @Range, @Length 같은 어노테이션을 활용하여 검증하면 도메인에서 뷰에 출력할 문구를 의존하는 형태가 될 것 같아서 선뜻 그렇게 하기가 어려웠다. (지난번 미션 때 이 부분에 대해서 피드백을 들었어서 더 조심스러웠던 것도 있다 ㅎㅎ)

하지만...! 생각해보면 굳이 validation annotation을 사용할 필요는 없었다.

레벨 1 미션에서는 그냥 자바 코드로도 충분히 검증을 했었고, 만약 새로운 개발자가 와서 '상품 도메인에 필요한 필드들의 제약 사항은 어디에서 관리되지?'라고 생각했을 때 DTO보다는 도메인 클래스를 먼저 열어볼 것 같았다.

또한, 지금은 SSR이기 때문에 메시지 자체가 바로 뷰로 노출되지만, CSR 상황이라면 여기서 전파되는 메시지는 실사용자가 아닌 상대 개발자, 즉 클라이언트가 확인하는 메시지이기 때문에 '도메인이 뷰에 출력될 메시지를 관리한다'라는 관점과는 조금 떨어져 있다고 봐도 된다.

무엇보다 도메인 객체는 POJO로 관리되는 게 더 좋을 것 같아서, 아래와 같이 그냥 자바 코드를 통해 검증을 진행해주었다.

public class ProductName {

    private static final int NAME_MIN_LENGTH = 1, NAME_MAX_LENGTH = 25;

    private final String name;
	
    ...

    private static void validateNameLength(final String name) {
        if (name.length() < NAME_MIN_LENGTH || name.length() > NAME_MAX_LENGTH) {
            throw new GlobalException(PRODUCT_NAME_LENGTH);
        }
    }
}

그리고 DTO 쪽에는 단순히 유효성 검사를 진행해주었다.

public class ProductRequest {

    @NotBlank(message = "상품 이름은 비어있을 수 없습니다.")
    private final String name;

    @NotNull(message = "상품 가격은 비어있을 수 없습니다.")
    private final Integer price;

    @NotNull(message = "상품 카테고리는 비어있을 수 없습니다.")
    private final String category;
    ...
}

앞으로는 다음과 같은 기준을 통해서 유효성 검증을 해보고자 한다.

- DTO : 데이터 타입에 대한 검증
ex.
숫자값이 올바르게 들어오는가?
빈 값이 들어오는가?
전화번호 형태 (-로 구분된 13글자)인가?
이메일 형태 (@로 구분된 형태)인가?

- 도메인: 비즈니스 요구사항에 대한 검증
ex.
가격은 0원 ~ 10000원 이하의 값을 가지는가?
이름의 길이는 최소 1글자 이상인가?
이메일의 도메인이 특정 도메인만 사용하는가? (gmail, daum, naver... etc)

Dto <-> Entity 변환 로직은 어디에 있으면 좋을까?

public class ProductDto {
    public Product toEntity() {
        return new Product(name, imageUrl, price, category);
    }

    public static ProductDto fromEntity(final Product product) {
        return new ProductDto(product.getId(), product.getName(), product.getImageUrl(),
                product.getPrice(), product.getCategory());
    }
}

사실 이거는 정말 리뷰어님마다 정말 많이 갈리는 부분인 것 같다.

내 리뷰어님 같은 경우는 의존관계가 Controller -> Dto -> Entity와 같은 형태로 흐르게 된다면 컨트롤러에서 해당 Dto 클래스를 통해서 도메인에 대해 접근할 수 있는 여지가 생기는 게 아니냐고 말씀해 주셨다.

물론, 개발자의 이해도가 높다면 Dto에서 Entity로 변환하여 컨트롤러에서 코어한 도메인 계층의 객체를 침범하는 경우는 거의 없겠지만, 클린 아키텍처의 시작은 '~한 위험이 있지 않을까?'로 부터 시작된다고 생각하기 때문에 이런 위험성은 끊어주는 게 옳다고 생각했다.

그래서 리팩터링 시에는 service layer에서 private method를 통해 위와 같은 변환 로직을 처리하도록 만들었고, 추후 매핑하는 클래스들이 많아진다면 별도의 mapper class를 두어서 처리하는 것으로 생각하였다. (매퍼 클래스 역시 service와 같은 곳에 위치)

+) 의존 관계를 단방향으로 가져가려면 dto가 존재해야 하는 패키지는 service 쪽이어야 한다

아무 생각 없이 controller 쪽에 두었다가 controller -> service -> dto 같은 요상한 흐름 관계가 생겨버렸었다... ㅎ_ㅎ 유의하자!

엔티티와 도메인

아마 이번 미션에서 나를 가장 많이 괴롭혔던 주제인 것 같다 (여전히 결론을 확실하게 내리지 못한 상태이다)

사실 처음 페어 프로그래밍을 할 때는 엔티티와 도메인을 구분하지 않고, 그냥 엔티티 자체를 도메인이라 생각하고 코드를 작성했었다.

미션 요구사항이 CRUD이다 보니까 DB와 굉장히 밀접해지고, 테이블에 내용을 삽입하거나, 조회하거나 하는 로직만 있다 보니 별도의 비즈니스 로직이 없다고 생각되어 별도로 둘 필요성을 느끼지 못했기 때문이다. 또한, 엔티티의 경우 DB와 1:1로 값을 매핑하고, 별도의 로직 없이 단순히 값을 반환하는 역할만 해야 한다고 생각했었다.

하지만, 위에서 비즈니스 요구사항에 대한 검증을 진행하기 위해서는 도메인 클래스가 필요했다.

엔티티에서 검증을 진행하기에는, 엔티티가 비즈니스 로직을 가지는 것 같아서 하고 싶지 않았고, 그렇다고 도메인을 만들기에는 단순히 검증밖에 안 하기 때문에 굳이 만들어야 하나...? 라는 생각도 들었기 때문이다... (여기서 머리 터짐)

하지만, 리뷰어님이 다음과 같은 피드백을 남겨 주셨다.

저는 도메인은 항상 있어야 한다고 생각해요.
새로운 개발자가 도메인에 대한 요구사항을 확인하기 위해서는 어떤 클래스를 확인할까요?

이 말을 듣고 나름대로 도메인과 엔티티에 대한 정의를 내려 아래와 같이 답변을 했다.

말이 길지만 요약하자면, 비즈니스 로직을 표현하기 위한 객체는 도메인 객체며, 영속성 레이어와 강결합을 맺은, 도메인 객체를 표현하기 위한 데이터들을 저장하는 객체는 엔티티라고 생각했다. 그래서 도메인 / 엔티티를 따로 분리해서 코드를 작성했었다.

하지만, 이러한 정의에서도 결국 문제가 발생할 수밖에 없었다.

바로... Join을 통해서 조회해올 때는 어떻게 엔티티로 처리해야 하는지 결정할 수 없는 것이었다.

기존에는 조인을 진행하는 주 테이블에 대한 dao (CartDao)에서 아래와 같이 코드를 작성하였고, MemberProductEntity라는 객체를 생성하여 조회해온 결과를 담아오도록 만들었다.

public class MemberProductEntity {
    private final Long cartId;
    private final Long memberId;
    private final Long productId;
    private final String productName;
    private final String productImageUrl;
    private final int productPrice;
    private final String productCategory;
	
    ...
}

public List<MemberProductEntity> getProductByMemberId(final Long memberId) {
    final String query = "SELECT c.id, c.member_id, c.product_id, p.name, p.image_url, p.price, p.category " +
            "FROM cart c JOIN product p ON c.product_id = p.id WHERE c.member_id = ?";
    return jdbcTemplate.query(query, (result, count) ->
            new MemberProductEntity(result.getLong("id"), result.getLong("member_id"),
                    result.getLong("product_id"), result.getString("name"),
                    result.getString("image_url"), result.getInt("price"),
                    result.getString("category")), memberId);
}

-> 1줄 요약: SRP 위반 아닐까요? + 엔티티를 이런 식으로 써도 되나요? + 결국 도메인과 엔티티의 차이점이 뭐죠? (다시 원점)

당시에는 엔티티는 도메인으로서 역할을 할 수 있지만, 정보 전달에 가까운 객체라면 가능하다고 생각해서 저런 구조로 했다.

갓 리뷰어님은 이걸 보고 아래와 같이 피드백을 남겨주셨다.

도메인: 우리가 해결하고자 하는 문제 영역이자, 문제 영역을 클래스화 하여 코드로 옮긴 부분
엔티티: 식별자를 가지고 있는 객체
위 정의대로라면 도메인이 더 큰 범위이면서, 엔티티가 그 일부분으로 보일 텐데, 맞습니다!

도메인에는 VO, Entity, Domain Service 등 많은 것들이 포함되어 있으며, 문제 영역을 클래스화 한 것이라면 모두 도메인으로 바라본다고 하셨다. (이에 대해서 오늘 허브랑도 이야기를 나눴었는데, 허브의 리뷰어님도 비즈니스 로직에 대한 Service Layer를 도메인 쪽으로 바라본다고 말씀해 주셨다.) 그리고, 그 중에서 식별자가 있다면 엔티티가 된다.

여기서 식별자는 비즈니스 상으로 두 개의 객체를 분리할 수 있는 고유한 기준이다.

DB의 pk 값이라고 생각할 수 있겠지만, PK가 될 수도 있고 다른 필드 값이 될 수도 있다.

어떠한 객체를 구분하는 기준이기 때문에, 만약 비즈니스 로직 상 '이름'이라는 필드가 고유하게 존재한다면 해당 객체는 '이름'이라는 식별자를 가진 엔티티가 될 수도 있는 것이다. 별도의 식별자가 있는 도메인은 곧 엔티티라고 말할 수 있으며, 이 단계에서는 DB에 대한 정보를 고려하지 않게 된다.

마틴 파울러는 다음과 같이 각 개념들을 정의하였다.

- Entity: Objects that have a distinct identity that runs through time and different representations. You also hear these called "reference objects".

- Value Object: Objects that matter only as the combination of their attributes. Two value objects with the same values for all their attributes are considered equal. I also describe value objects in P of EAA.

- Service: A standalone operation within the context of your domain. A Service Object collects one or more services into an object. Typically you will have only one instance of each service object type within your execution context.

이전 미션을 하면서 Reference Object와 Value Object에 대해서 공부한 적이 있었는데 여기서 엔티티를 Reference Object로서 생각한다는 점을 보고 확실하게 이해하게 되었다. 식별자로 상태가 변하는 객체가 되는 것. 우선 나는 이 정도로 이해를 했다. 그래서 보통 엔티티는 식별자로 동일성을 정의할 수 있기 때문에 equals, hashcode를 일반적으로 정의하지 않는다.

아무튼, 다시 돌아와서... 엔티티를 데이터베이스 테이블에 해당하는 객체로 자주 사용하는 이유는 보통 PK를 이용해 식별이 되는 Reference Object이기 때문이다. 그래서 이번 레벨에서는 DB의 PK를 식별자로 사용하는 엔티티를 별도로 두었다.

그리고, 장바구니에 대한 CUD 로직은 다음과 같이 풀어나갔다.

- '장바구니 (Cart)' 라는 도메인은 Member와 List<Product>의 조합으로 만들기.
: 한 명의 사용자가 담은 물건 리스트를 관리하는 도메인 객체.

- 장바구니 상품 저장, 제거 시 식별자를 가진 엔티티인 CartEntity를 활용하면 바로 insert가 가능하기 때문에 (본 비즈니스 로직은 DB에 대한 연산이 위주임) 별도의 도메인 객체로 표현할 필요가 없을 것 같다고 판단. (어차피 엔티티도 문제를 해결하는 범위로 본다면 도메인 객체에 들어갈 수 있다.)

- 장바구니 상품 정보 반환 시 조인을 사용하다 보니 Entity보다는 DTO로 사용 (여러 값들을 조합해서 사용하고 있음)

말이 길지만 결과적으로 엔티티와 도메인을 분리했다.

대충 한 가지 예시 코드를 보여주자면 이런 식이었다.

public CartResponse getCartResponseByMemberEmail(final String memberEmail) {
    final MemberEntity memberEntity = getMemberEntity(memberEmail);
    final List<CartDto> cartDtos = cartDao.getProductsByMemberId(memberEntity.getId());
    final Cart cart = convertToCart(memberEntity, cartDtos);
    final List<ProductResponse> productResponses = convertToProductResponse(cart);
    final int productCount = cart.getProductCount();
    return new CartResponse(productCount, productResponses);
}

다만, 이 과정에서 entity -> domain으로 만드는 컨버팅 로직이 많아져서 코드가 약간 보기 힘들어졌다.

또한, 서비스 레이어에서 도메인, 엔티티를 둘 다 가지고 있으면서 service -> entity(persistence layer), service -> domain와 같은 순환참조 형태가 발생해서 단방향으로 데이터가 흐르지 않게 되었다.

이를 해결하기 위해서 다음 미션에서는 다른 방법을 적용했는데...! 이거는 지하철 미션 끝나고 포스팅 해보고자 한다.

다음 미션도 파이팅!

[Network] 라우터의 주소 변환과 패킷 필터링 기능

dolmeng2 — Mon, 15 May 2023 14:38:01 +0900

들어가기 전

지난 포스팅에서는 라우터의 패킷 중계 동작에 대해서 알아보았다.

이번 포스팅에서는 라우터의 주소 변환 기능과 패킷 필터링 기능에 대해서 알아보자!

주소 변환이 나온 이유

라우터는 다양한 일을 하지만, 그중 핵심은 주소 변환 및 패킷 필터링 기능이다.
주소 변환은 왜 나왔을까?

이전에는 IP주소를 관리 기관에 신청서를 내서 할당받았지만, 인터넷에 접속하는 기기가 많아지면서 할당해줄 주소가 부족해지는 현상이 발생했었다. 이를 해결하기 위해서 동일한 회사에서 사용하는 주소는 다른 회사의 주소와 동일할 수 있도록 만들었다.

이는 어차피 다른 회사의 패킷은 서로 왕래할 일이 없으며, 같은 회사에서끼리 별도의 사내망으로 통신하기 때문에 다른 회사와 겹쳐도 상관없는 것이다. 덕분에 같은 회사에 있는 모든 기기에게 다른 주소를 할당해줄 필요가 없어졌다.

다만, 무작정 할당할 수 없기 때문에 특정 주소만 사용하며, 이를 프라이빗 주소로 두고 이전에 사용했던 모든 기기의 고유한 주소를 글로벌 주소라고 부르기로 했다.

프라이빗 주소는 다음 범위로 한정한다.

10.0.0.0 ~ 10.255.255.255
127.16.0.0 ~ 172.31.255.255
192.168.0.0 ~ 192.168.255.255

이는 글로벌 주소에서 일부분을 프라이빗 주소로 사용하는 것이며, 단지 사내에서 사용한다고 규정한 것이기 때문에 관리 기관에 신청서를 낼 필요 없이 자유롭게 이용하면 된다. (동일한 회사 내에서만 중복을 피하면 됨)

하지만, 사내 네트워크가 외부랑 통신하는 일이 발생할 수도 있다.
그래서 사내 네트워크는 보통 인터넷에 공개된 서버를 접속하는 부분과 사내용 네트워크 2가지로 나눈다. 그리고 사내 네트워크에 할당된 프라이빗 주소는 외부랑 통신하지 않도록 만들기 때문에 외부랑 통신하기 위해서 특별한 구조를 사용하는데 이때 주소 변환을 사용한다.

그림으로 본다면 이런 느낌으로 동작한다고 생각할 수 있다.

사내 네트워크에서 사용하는 프라이빗 주소를 외부에서 사용하는 글로벌 주소로 바꾸거나, 글로벌 주소에서 들어온 패킷을 프라이빗 주소로 바꿔주는 동작을 진행한다.

주소 변환의 동작 알아보기

주소 변환은 패킷 중계 시 IP 헤더에 적힌 IP 주소와 포트 번호를 다르게 바꾸는 것이다.

먼저, TCP 접속 시 송신처의 IP 주소를 프라이빗 주소에서 글로벌 주소로 바꿔쓴다.
여기서 글로벌 주소는 라우터 (주소 변환 장치, 방화벽 같은 다른 것일수도 있으나 여기서는 라우터를 예시로 들음)의 인터넷 측의 포트에 할당된 주소이며, 포트 번호는 사용하지 않는 번호를 라우터가 알아서 선택하여 바꿔준다. 그리소 이전에 사용하던 프라이빗 주소와 포트번호, 바꿔쓴 글로벌 주소와 포트 번호를 라우팅 테이블에 저장해둔다.

이때, 포트 번호는 왜 바꿔쓰는 것일까?

만약 IP 주소만 바꿔쓰게 된다면, 프라이빗 주소와 글로벌 주소가 1:1로 매칭되어야 하기 때문에 글로벌 주소가 매우 많이 필요하다.
하지만, 사내 네트워크에 수백 대의 단말기가 존재한다면 수백 개의 글로벌 주소가 필요해진다.
이를 해결하기 위해서 포트 번호도 바꿔쓰며 각각의 단말기를 식별하고자 했고, 어차피 클라이언트 측의 포트 번호는 원래 비어있기 때문에 무작위로 선택해서 사용하므로 바꿔쓰더라도 문제가 발생하지 않는다.
결과적으로 한 개의 글로벌 주소를 수만 개의 프라이빗 주소에 매칭시켜 주소 고갈 문제를 해결했다.

주소 변환이 완료된 패킷은 인터넷에 송출되며, 이에 대한 회신 패킷은 라우터에게 되돌아온다.

돌아온 패킷은 라우팅 테이블에 저장된 정보를 바탕으로 다시 프라이빗 주소로 변경하고, 원래의 송신처로 이동하게 된다.

결과적으로 그뒤로 주고받을 때는 라우팅 테이블에 적힌 정보를 참고하게 되며, 데이터 송/수신 종료 후 접속 동작이 끝나게 되면 라우팅 테이블에 등록한 정보를 제거한다.

위에서는 주소 변환이 글로벌 <-> 프라이빗 주소 간 양방향으로 일어난다고 했다.
이때, 프라이빗 주소에서 글로벌 주소로 변환할 때는 라우팅 테이블에 정보가 등록되지 않았더라도 중계가 가능하다.
기본적으로 글로벌 주소는 라우터에 할당이 되어 있고, 포트 번호는 사실 비어있는 정보를 사용하면 되기 때문이다.

하지만, 프라이빗 주소로 변환할 때에는 라우팅 테이블의 정보가 없으면 내부에서 어떤 주소가 사용되는지 알 수 없기 때문에 꼭 필요하다.

그렇기 때문에 외부에서 액세스하지 않는 단말 기기에는 외부에서 패킷을 송신할 수 없으며, 액세스하더라도 실제로 통신에 사용하는 포트 번호가 아니라면 그쪽으로 패킷을 보낼 수 없다. 덕분에 부정 침입을 방지하는 효과를 가지게 된다.

만약, 외부에서 액세스하지 않더라도 그쪽으로 패킷을 송신하고 싶다면 직접 라우팅 테이블에 등록해두면 된다.

공개용 서버는 라우팅 밖의 영역에서 글로벌 주소를 할당하지만, 서버의 프라이빗 주소를 라우터에 등록해두면 외부로 해당 주소를 공개할 수 있게 된다. (DNS 서버에 등록할 때는 라우터에 등록한 글로벌 주소를 등록하면 된다)

라우터의 패킷 필터링 기능

패킷 필터링 시 MAC, IP, TCP 헤더에 기록된 내용을 조사하여 사전에 설정된 조건에 부합되면 패킷을 중계하거나, 혹은 폐기한다.

방화벽 같은 기기, 소프트웨어는 대부분 위와 같은 방식으로 동작한다.

이건 추후 챕터를 진행하면서 더 자세히 다루도록 하겠다.

퀴즈

Q. 입력 신호를 모든 포트에 출력하는 것은 스위칭 허브와 리피터 허브 중 어떤 것일까?
A. 리피터 허브

Q. 네트워크 번호와 호스트 번호의 비트 수를 결정하는 것은 무엇일까?
A. 넷마스크

Q. 큰 패킷을 분할하는 기능을 뭐라고 할까?
A. 조각 나누기

Q. 라우터의 경로표의 '넷마스크'에 0.0.0.0인 경로 정보는 무엇을 의미할까?
A. 기본 경로

깃허브 / 티스토리 닉네임의 의미

dolmeng2 — Sun, 14 May 2023 19:28:12 +0900

자꾸 깃허브 닉네임 볼 때마다 욕 아니냐는 의견을 들어서 작성하는 글...

나는 깃허브를 꽤 옛날에 가입했다.

2019년... 고3 졸업식을 앞두고, 대학교도 입학하기 전이다.

만들게 된 계기는 컴공 소프트웨어학부 입학을 앞두고 코딩의 코자도 모르는 사람의 불안감(?)으로 시작됐다.

네 바꿨어요

당시에 우리 과 19학번 카페가 만들어졌었는데, 의무적으로 자기소개를 하나씩 올렸어야 했다.

그렇게 다른 사람의 자기소개를 보다 보니 예상 외로 C언어에 대해 예습한다는 학우들이 많았던 것이다!

옛날부터 뒤처지는 건 정말 참을 수 없었기 때문에 뭔가라도 해보고 싶어서 야심차게 깃허브를 가입하려고 했다.

나는 다음, 네이버, 구글 웬만한 사이트들에 대해 아이디를 통일하고 비밀번호만 조금씩 다르게 사용하는 편인데,

이상하게 이날은 뭔가 다른 닉네임을 사용하고 싶었다.

XD, :P, :D, :)

이 이모티콘을 아시나요?

나무위키를 보면 다음과 같이 설명되어 있다.

"반시계 방향 혹은 시계 방향으로 90도 돌려봐야 이해할 수 있는 모양"

와! 이거 귀엽다

바로 써먹으려고 했는데...

누구신지 모르겠지만 안녕하세요?

그외에 나머지는 특수문자가 들어가있어서 할 수가 없었다.

그래서 뭐하지... 하고 고민하다가 나만의 이모티콘을 만들고 싶었다.

모자와 썬글라스를 쓰고 웃고 있는 사람을 만들자!

그래서 Cl8D라는 귀여운 닉네임이 만들어진 것이다.

(씨x 아님, C8 아님...)

참고로 티스토리의 경우 소문자로 들어가다 보니까 이렇게 됐는데, 이것도 매우 귀엽다.

요건 이제 모자와 선글라스를 쓰고 메롱하는 사람이 된 것이다!

아무튼... 더 이상 아무 오해도 없었으면

+) 그럼 티스토리는?

추가적으로 티스토리는 왜 돌멩이냐면...

그냥 돌멩이라는 단어를 좋아한다. 어감이 동글동글 귀엽다.

근데 한글로 돌멩이 하려고 하니까 안 돼서 영어로 dolmeng2라고 했다.

실제로 여러 곳에서 내 닉네임은 돌멩이다.

위는 왓챠 프로필.

요거는 구글 다른 프로필

요건 아이디어스...

등등 정말 여러 곳에서 사용하고 있다.

귀여우니까 ^_^

우테코 시작하고 져니로 바꾸고 싶었는데, 이미 있는지 적용이 안 된다.

그래서 그냥 돌멩이로 살고 있다.

가끔 돌멩이 블로그 잘 보고 있어요~라고 하면 기분이 좋다

+) 번외

그렇게 만든 첫 레파지토리(?)

당연히 비공개다

C언어에 기죽지 않겠다고 만든 건데 언어는 왜 HTML인지 모르겠다

(HTML이 프로그래밍 언어 아닌 거 앎 반박 시 당신 말이 다 맞아요)

이때까지만 해도 내가 백엔드 할지 정말 꿈에도 상상 못했지....

근데 저 레파지토리 두 번 커밋하고 버려짐

아무튼 다들 닉네임 보고 오해하지 않아주셨으면 좋겠다...

욕 아니에요

[Web] JWT를 통한 인증 과정 알아보기

dolmeng2 — Sun, 14 May 2023 18:48:01 +0900

들어가기 전

마찬가지로 테코톡에서 진행했던 발표 자료를 바탕으로 글을 작성하였습니다!

인증과 인가, 쿠키 / 세션 방식에 대해서는 이전 포스팅에서 작성하였습니다.

[Web] 인증과 인가란? - 쿠키와 세션에 대해서 알아보자!

들어가기 전 테코톡에서 진행한 인증과 인가 관련 자료들을 바탕으로 글을 작성하였습니다 :D 인증 (Authentication) 보호된 리소스에 접근하는 것을 허용하기 이전에, 등록된 유저의 신원을

cl8d.tistory.com

4. 효율적으로 인증하기

지난 포스팅에서는 세션을 통해서 안전하게 인증하는 방법을 알아보았다.

하지만, 세션 방식의 가장 큰 문제점은 서버도, 클라이언트도, 그리고 세션 스토리지까지 사용자의 정보를 관리하는 주체가 너무 다양하다는 것이다. 이러한 문제점을 해결하기 위해서, 상태를 관리하는 것을 따로 두지 않고 요청과 응답 내부에서 처리하는 것이 토큰 인증 방식이다.

+) 세션 기반 인증 방식에서 토큰 인증 방식이 나온 이유 중에 하나가 DB에 인증 정보를 저장하지 않아서 서버에 대한 부하를 줄이는 것도 있다고 많이들 말한다. 암호화된 인증 정보를 클라이언트가 관리함으로서 부하를 줄인다고는 하지만... 사실 보안 측면으로 보면 JWT 역시 DB를 사용하게 되다 보니까 이런 관점에서는 크게 좋은지 잘 모르겠다. (개인적인 의견)

토큰 방식으로는 대표적으로 'JWT (Json Web Token)'가 존재한다.

JWT는 정보를 Json 객체를 통해 안전하게 전송하기 위한 간결하고, 독립적인 방법을 정의하는 개방형 표준이다. (RFC 7519)

기본적으로 HMAC 알고리즘을 통해 암호화가 되어 있으며, RSA나 ECDSA를 사용하는 공개-개인키 쌍을 통해 서명할 수 있다.

JWT는 크게 헤더, 페이로드, 그리고 시그니처로 이루어져 있다.

Header

헤더는 일반적으로 토큰 유형과 서명 알고리즘 2가지가 포함되어 있다.

{
  "alg": "HS256",
  "typ": "JWT"
}

만약 이런 식으로 구성되어 있다면, 이는 현재 타입은 JWT, 서명 알고리즘으로 HS256을 사용했음을 나타낸다.

이 정보를 Base64로 인코딩하게 되면 JWT의 헤더 부분이 완성된다.

Payload

payload은 claim 정보가 포함되며, claim은 entity에 대한 내용이 들어간다. (사용자에 대한 정보)

인증에 필요한 정보가 보통 이곳에 들어가지만, 민감한 정보는 넣지 않는 것이 좋다.

{
  "sub": "1234567890",
  "name": "John Doe",
  "admin": true
}

마찬가지로 위에 대한 정보를 base64로 인코딩하면 payload에 대한 정보가 들어간다.

Signature

인코딩된 헤더 및 인코딩된 페이로드, secret (비밀 키 정보), 헤더에 지정된 알고리즘을 사용하여 서명할 수 있다.

만약 HMAC SHA256 알고리즘을 사용한다면 아래와 같이 서명이 가능하다.

HMACSHA256(
  base64UrlEncode(header) + "." +
  base64UrlEncode(payload),
  secret
)

시그니처 정보는 도중에 변경되지 않았는지 확인하는데 사용되며, 개인키로 서명된 토큰이라면 JWT의 발신자가 본인이 맞는지 확인하는데도 사용된다.

그래서 결과적으로 JWT는 .으로 구분된 3개의 Base64로 인코딩된 문자열의 합으로 이루어져 있다.

보통 우리가 코드에서 활용할 때에는 'Bearer' 라는 prefix를 사용하여 Authorization 헤더에 넣는 것이 일반적이다.

Authorization: Bearer <token>

참고로, 나중에 실제 클라이언트와 통신할 때 CORS 문제를 겪을 수 있기 때문에 서버측에서 exposedHeader 값으로 Authroization 헤더를 허용해줘야 한다. (이거는 다음에 포스팅을 따로 해보겠다 ㅎㅎ)

실제로 학습 테스트에서 살펴보았던 토큰 생성 코드를 확인해보자.

public String createToken(String payload) {
    Claims claims = Jwts.claims().setSubject(payload);
    Date now = new Date();
    Date validity = new Date(now.getTime() + validityInMilliseconds);

    return Jwts.builder()
            .setClaims(claims)
            .setIssuedAt(now)
            .setExpiration(validity)
            .signWith(SignatureAlgorithm.HS256, secretKey)
            .compact();
}

코드를 각각 분석해보면 위와 같이 claim을 통한 사용자 정보 지정 및 만료 시간, 그리고 시크릿키를 통한 암호화를 하는 것을 볼 수 있다.

그리고, 해당 토큰을 다시 해독할 때는 서버 내에서 관리하는 시크릿키를 통해서 해독한다.

public String getPayload(String token) {
    return Jwts.parser()
        .setSigningKey(secretKey)
        .parseClaimsJws(token)
        .getBody()
        .getSubject();
}

여기서 한 가지 주목할 점이 있다.
parseClaimsJws()라는 메서드를 사용하고 있는 걸 볼 수 있는데, 이거 대신에 parseClaimsJwt()를 사용하면 오류가 발생한다.
이는, 우리가 처음에 토큰을 생성할 때 signWith을 통해서 서명을 진행했기 때문에 복호화 시에도 서명에 대한 검증을 진행해야 하기 때문이다. (Jwt()의 경우 서명 검증 없이 단순히 헤더와 클레임만 추출함)
parseClaimsJwt()을 사용하고 싶다면 토큰 생성 시에 signWith을 통해서 서명에 대한 정보를 넘겨주지 않으면 된다.

동작 방식 알아보기

토큰 기반 인증 방식은 아래와 같이 동작할 수 있다.

클라이언트에게 생성된 토큰을 내려주는 방식은 다양한데, 나는 위와 같이 Authorization 헤더에 담아서 내려줬다.

클라이언트는 해당 값을 받아서 다음 요청 시 Authorization 헤더에 JWT 정보를 함께 넣어서 보내는데, 서버는 해당 키를 생성할 때 사용하였던 시크릿키 정보를 활용하여 다시 디코딩 후에 내부에 있는 사용자 정보를 바탕으로 인증을 진행한다.

장점 / 단점

토큰 기반 인증 방식의 경우 서버 측에서 따로 저장할 필요가 없으며, 클라이언트가 요청에 대해 헤더 값에 함께 포함시켜 보내주면 된다.

또한, MSA 같은 구조나 서버가 여러 대인 상황이라면 같은 토큰을 통해 여러 서버에서 인증이 가능하기 때문에 더 효율적이다.

(이전에 봤던 세션 인증 방식에서는 세션 스토리지 같은 것을 두었었는데, 이런 점에서는 좋다 ㅎㅎ)

하지만, JWT의 경우 탈취 당한다면 해당 사용자의 권한을 그대로 가지게 된다.

탈취당한 JWT의 경우 유효 기간이 지나기 전까지는 강제로 만료시킬 수 없기 때문에, 정보를 바로 제거할 수 있는 세션에 비해서는 보안적 측면에서는 떨어진다고 볼 수 있다. (물론, 해당 토큰의 claim 정보가 악성 사용자임을 확실하게 나타낼 수 있다면, 해당 사용자의 요청은 차단하는 형태로는 만들 수 있을 것 같다.) 그래서 은행 같은 보안이 중요한 시스템에서는 세션을 많이 사용하는 것으로 알고 있다. (뇌피셜)

Refresh Token

보통 탈취 문제로 인해서 JWT (이제는 'access token'이라고 부르겠다.)의 유효 기간을 짧게 가져가는 편이며 (30분 정도), 기한이 짧으면 요청에 대해서 새롭게 발급받아야 하는 횟수가 늘어나기 때문에 이를 방지하기 위해 'refresh token'이라는 것을 따로 두기도 한다.

access token에 대한 재발급 기능을 책임지는 token이며, 기본적으로 서버에 저장할 수 있고 (세션에 저장하거나 쿠키에 저장하는 방법도 있지만, in-memory db에 저장하는 것이 일반적), 탈취를 당하더라도 해당 사용자의 refresh token을 강제로 제거하여 보안에 대해서도 안정성이 높은 토큰이다.

보통 refresh token의 경우 유효 기간을 일주일~이주일 정도로 만들어둔다.

사실 이에 대해 어떻게 활용하는지는 개발자에 따라서 다르지만, 보통 이런 방식을 많이 사용한다. 위에서 작성한 그림과 이어진다고 생각하자.

여기서 받은 토큰 정보에 따라서 요청을 처리하는 스텝이 나누어지는데, 보통 아래와 같은 케이스들로 나뉜다.

물론 여기서 다른 방식으로 처리해도 무방하다.

로직이 상당히 복잡해졌지만, access token의 단점을 그나마 보완할 수 있기 때문에 많이 사용하는 방법이다.

짧은 access token의 유효시간에 대처하기 위한 다른 방법으로 sliding session이라는 친구도 있다.

사용자가 계속해서 서비스를 이용하고 있다면 (JS의 이벤트 핸들러로 감지) access token이 만료되기 전에 새로운 access token을 발급받아 자동으로 갱신한 토큰을 받아오는 것이다. 이건 구현해본 적이 없어서 잘 모르겠지만... 아무래도 클라이언트 측에서 계속 확인해야 할 것 같다.

[Spring] 스프링 테스트 - 테스트 컨텍스트 캐싱, @SpringBootTest, @WebMvcTest

dolmeng2 — Mon, 8 May 2023 00:50:12 +0900

들어가기 전

이전 포스팅과 마찬가지로 스터디에서 맡은 '테스트' 파트에 대해서 블로그에 정리해보고자 한다

테스트 쪽은 공식 문서도 생각보다 가독성이 너무 안 좋아서 최대한 간략하게만 훑어보았다.

아직 모르는 게 정말 많은 것 같다 ㅎㅎ

통합 테스트 vs 인수 테스트

통합 테스트는 특정 작업을 수행하기 위해, 외부 작업들과 연관되어 있다면 해당 외부 작업들을 포함하여 구성 요소가 잘 돌아가는지 테스트하는 방법으로, @SpringBootTest 어노테이션을 활용하여 진행하는 방법이 많다. (관련된 모든 빈을 가져와서 테스트 하는 느낌)

반면, 인수 테스트의 경우 사용자의 시나리오에 맞춰 수행하는 테스트이다.

인수 테스트의 방법론으로 E2E 테스트를 통해 주어진 시나리오에 따라 애플리케이션의 모든 계층이 서로 잘 동작하는지 확인할 수 있다.

RestAssured를 활용해서 테스트 코드를 작성하는 방식을 많이 보았다.

사실 인수 테스트와 E2E 테스트가 동일한 것이라고 생각했었는데, E2E 테스트가 조금 더 큰 범위라고 생각할 수 있을 것 같다.

인수 테스트는 사용자의 시나리오에 맞추기 때문에, 그게 단위 테스트이든, 통합 테스트이든 사용자의 요구사항에 맞춘다면 다 인수 테스트라고 할 수 있기 때문이다.

테스트 프레임워크

스프링은 테스트에 사용되는 애플리케이션 컨텍스트를 생성하고 관리하고, 테스트에 적용해주는 기능을 가진 ‘테스트 프레임워크’를 제공한다. 그리고 이를 ‘테스트 컨텍스트 프레임워크’라고 부른다.

테스트 대상 메서드에 @Test를 붙이면 해당 메서드가 속한 클래스는 ‘테스트 클래스’로서 동작하며, 각 메서드는 독립적인 테스트가 된다.
하지만, 테스트마다 테스트 컨텍스트를 매번 새로 생성하게 된다면 오버헤드가 크기 때문에 전체 테스트의 실행 속도가 느려져셔 개발자의 생산성이 떨어진다. 이때문에 테스트 컨텍스트는 자신이 담당하는 테스트 인스턴스에 대한 컨텍스트 관리 및 캐싱 기능을 제공한다!

그래서 테스트를 할 때 특정 애플리케이션 컨텍스트를 구성하고 싶다면, 클레스 레벨에 @ContextConfiguration 어노테이션을 선언함으로서 구성 정보를 주입해줄 수 있다.

페어가 @Import 어노테이션이랑 다른 거냐고 물어봤는데, 내부적으로 조금 까보니까 등록되는 빈이 조금 다르다.
@Import의 경우 importsCleanupPostProcessor라는 빈이 추가로 등록되는 거를 확인했다.
또한, @Import의 경우 기존 ApplicationContext에 해당 Component를 추가한다는 것이고, @ContextConfiguration의 경우는 어떤 애플리케이션 컨텍스트를 사용할지, 그리고 XML 같은 걸로 설정도 할 수 있다는 점이 있을 것 같다.
사실 명확하게 둘의 차이를 이해하기는 어렵지만... 유스케이스가 다른 것 같다.

컨텍스트 설정 정보 주입하기

@ExtendWith(SpringExtension.class) 
@ContextConfiguration(classes = {AppConfig.class, TestConfig.class}) 
class MyTest {

}

@ExtendWith 어노테이션의 경우 스프링 프레임워크와 Junit5를 연동해주는 역할으로서, @Test 같은 어노테이션을 사용하기 위해서는 붙여줘야 한다. (Junit4에서는 @RunWith(SpringRunner.class)을 사용했었음)

@ContextConfiguration 어노테이션을 활용하여 어떤 설정 정보 파일을 구성할지 설정할 수 있다.

여기서 classes 인자로 준 AppConfig.class와 TestConfig.class에 등록된 빈 정보를 바탕으로 ApplicationContext가 구성되며, 이때 각각의 Configuration 클래스의 경우 @Configuration 어노테이션 (스프링 부트라면 @TestConfiguration도 가능)이 붙어 있거나, @Component, @Service, @Repository 같은 스테레오 타입 어노테이션이 붙어있는 클래스면 가능하다.

@Configuration
public class Hello {
    @Bean
    public Nested nested() {
        return new Nested();
    }

    static class Nested {

    }
}

위와 같이 static nested class로 선언되어 있는 빈을 등록한다고 생각해보자.

@ExtendWith(SpringExtension.class)
@ContextConfiguration(classes = {Hello.class})
public class Sample {

    @Autowired
    private Nested nested;

    @Test
    void test() {

    }
}

그럼 위와 같이 Hello라는 설정 정보 클래스를 @ContextConfiguration으로 불러오게 되면, Hello라는 Configuration 클래스에 대한 정보를 읽어서 등록되어 있는 Nested라는 빈에 대해 의존관계를 주입받을 수 있게 된다.

만약, @ContextConfiguration 어노테이션을 제거하게 되면 아래와 같이 컴파일 오류가 발생한다.

지금까지 나는 컨텍스트 정보를 지정한 적이 없는데...?

하지만, 나는 지금까지 @ContextConfiguration이라는 친구를 한 번도 테스트 코드에서 사용한 적이 없었다.

근데 어떻게 테스트가 정상적으로 동작을 했었던 것일까?

Unable to find a @SpringBootConfiguration, you need to use @ContextConfiguration or @SpringBootTest(classes=...) with your test java.lang.IllegalStateException: Unable to find a @SpringBootConfiguration, you need to use @ContextConfiguration or @SpringBootTest(classes=...) with your test

기본적으로는 @ContextConfiguration이나 @SpringBootTest 어노테이션을 지정해달라는 오류가 발생한다.

하지만, 만약 ⭐️ 스프링 부트 ⭐️ 를 사용하고, @SpringBootApplication 어노테이션이 붙은 클래스가 존재하는 패키지의 하위 패키지에 테스트 클래스를 두었다면, 알아서 적절한 정보를 찾게 된다. (보통 최상단 패키지에 @SpringBootApplication을 두는 이유가 여기서 나온다)

Found @SpringBootConfiguration com.example.study.StudyApplication for test class com.example.study.hi.Sample

테스트 코드를 돌려보면 위와 같이 @SpringBootConfiguration이라는 어노테이션을 찾았다는 것을 볼 수 있는데, 이는 @SpringBootApplication 어노테이션이 존재하는 클래스를 찾으면서 내부적으로 중첩되어 있는 어노테이션인 @SpringBootConfiguration을 찾을 수 있었기 때문이다.

위와 같이 @SpringBootApplication 어노테이션의 경우 중첩으로 @SpringBootConfiguration이라는 어노테이션을 가지고 있다. (@Configuration 어노테이션이랑 거의 동일하게 동작한다고 생각하면 된다.) 덕분에 별도의 컨텍스트 정보를 지정하지 않더라도 알아서 해당 어노테이션이 붙은 클래스를 중심으로 하위 클래스들의 설정 정보를 자동으로 찾아서 등록하게 된다.

Context Caching

테스트 컨텍스트 프레임워크는 테스트에 대한 ApplicationContext를 로드하면, 해당 컨텍스트가 캐싱되어 동일한 테스트 컨텍스트 구성을 사용하게 되면 해당 컨텍스트를 재사용하게 된다. 보통 ApplicationContext의 경우 이를 로드하기 위한 configuration parameter의 조합을 통해 고유하게 식별이 가능하다.

configuration parameter로는 다음과 같은 정보들을 사용한다.

locations	@ContextConfiguration 어노테이션의 인자
classes	@ContextConfiguration 어노테이션의 인자
contextInitializerClasses	@ContextConfiguration 어노테이션의 인자
contextCustomizers	ContextCustomizerFactory로부터 로드
contextLoader	@ContextConfiguration 어노테이션의 인자
parent	@ContextHierarchy
activeProfiles	@ActiveProfile
propertySourceLocations	@TestPropertySource
propertySourceProperties	@TestPropertySource
resourceBasePath	@WebAppConfiguration

테스트 컨텍스트 프레임워크는 애플리케이션 컨텍스트를 정적 변수로 저장하며, 만약 테스트 자체가 별도의 프로세스에서 실행되는 경우 각 테스트 실행 사이의 정적 캐시가 지워지기 때문에 캐싱 작업 역시 함께 비활성화 된다.

기본적으로 컨텍스트 캐시의 크기는 32로 제한되어 있으며, 최대 크기에 도달하게 되면 LRU 알고리즘에 따라 가장 오래된 컨텍스트를 제거한다.

실제로 코드를 통해 확인해보자. 위에서 선언했던 Sample 클래스에 동일한 설정 정보를 가진 Sample2 클래스를 생성해주었다.

@ExtendWith(SpringExtension.class)
@ContextConfiguration(classes = {Hello.class})
public class Sample {

    @Autowired
    private Nested nested;

    @Autowired
    ApplicationContext ac;

    @Test
    void test() {
        System.out.println("test1 = " + ac);
    }
}

@ExtendWith(SpringExtension.class)
@ContextConfiguration(classes = {Hello.class})
public class Sample2 {

    @Autowired
    private Nested nested;

    @Autowired
    ApplicationContext ac;

    @Test
    void test() {
        System.out.println("test2 = " + ac);
    }
}

둘 다 GenericApplicationContext@75437611이라는 동일한 applicationContext 객체를 사용하는 것을 볼 수 있다.

@ContextConfiguration 어노테이션 대신에 @SpringBootTest를 사용하는 테스트 클래스를 하나 더 추가해보자.

@SpringBootTest
@ExtendWith(SpringExtension.class)
public class Sample3 {

    @Autowired
    private Nested nested;

    @Autowired
    ApplicationContext ac;

    @Test
    void test() {
        System.out.println("test3 = " + ac);
    }
}

확인해보면 @SpringBootTest를 사용한 test3만 다른 ApplicationContext 객체를 사용하는 것을 볼 수 있다.

만약 @SpringBootTest(webEnvironment = WebEnvironment.RANDOM_PORT)을 사용하게 된다면 실제 웹 환경이 구성되기 때문에 다른 컨텍스트 정보를 지정하게 되면 다른 웹 서버가 띄워지게 된다.

컨텍스트 강제 초기화하기 - @DirtiesContext

만약 강제로 컨텍스트를 제거하고 싶다면 클래스, 혹은 메서드 레벨에 @DirtiesContext 어노테이션을 추가하면 된다.

이러면 동일한 애플리케이션 컨텍스트를 사용하더라도 테스트 실행 전에 강제적으로 기존 컨텍스트를 제거하고 새로운 컨텍스트를 실행해준다.

새로운 스프링 컨테이너에서 테스트를 실행하고 싶은 경우

// 현재 테스트 클래스 이전에 컨텍스트를 더티 처리
@DirtiesContext(classMode = BEFORE_CLASS) 
class FreshContextTests {
}

// 각각의 테스트 메서드 전에 컨텍스트를 더티 처리
@DirtiesContext(classMode = BEFORE_EACH_TEST_METHOD)
class FreshContextTests {
}

// 현재 테스트 메서드 이전의 컨텍스트를 더티 처리
@DirtiesContext(methodMode = BEFORE_METHOD) 
@Test
void testProcessWhichRequiresFreshAppCtx() {
}

스프링 컨텍스트를 더럽히는 동작을 내부적으로 수행할 것 같을 때

// 현재 클래스 이후에 컨텍스트를 더티 처리
@DirtiesContext 
class ContextDirtyingTests {
}

// 각각의 테스트 메서드 후에 컨텍스트를 더티 처리
@DirtiesContext(classMode = AFTER_EACH_TEST_METHOD) 
class ContextDirtyingTests {
}

// 현재 테스트 메서드 이후의 컨텍스트를 더티 처리
@DirtiesContext 
@Test
void testProcessWhichDirtiesAppCtx() {
}

페어랑 얘기하면서 언제 @DirtiesContext를 사용할 수 있을지 이야기를 나누어보았다.

다른 분들은 데이터베이스 초기화를 위해서 사용하신다고 말씀하셨는데, 사실 @DirtiesContext의 경우 새로운 서버를 띄우면서 (기존의 서버를 닫고) 인메모리 데이터베이스를 새롭게 띄우게 되다 보니까 데이터베이스가 초기화된다고 생각했다. 그렇다면 만약 서버를 띄워도 초기화되지 않는 데이터베이스를 사용한다면 (프로파일별로 다른 DB를 사용할 경우...) @DirtiesContext을 사용하더라도 초기화가 안 될 것 같다고 생각했다.

벨덩 같은 글을 보면 싱글톤 빈이 상태를 가지고 있는 경우 내부적으로 해당 빈을 조작했을 때 applicationContext를 강제적으로 초기화하려면 사용하라는 말이 있었는데, 애초에 싱글톤 빈이 상태를 가지고 있는 것 자체가 잘못된 설계라는 생각도 들고... 어렵다 앞으로 사용할 일이 있을까?... 모르겠다.

스프링 부트와 테스트

사실 위에서 언급한 내용은 단순히 '스프링 프레임워크'를 사용했을 때의 일이다.

하지만, 스프링 부트에서는 애플리케이션 테스트 시 도움이 되는 다양한 유틸리티와 어노테이션을 지원한다.

특히, spring-boot-starter-test dependency를 사용하게 되면 Junit, AssertJ 같은 유용한 라이브러리들도 함께 사용할 수 있다!

@SpringBootTest

위에서 언급했던 스프링 프레임워크 표준 어노테이션인 @ContextConfiguration 대신 @SpringBootTest 어노테이션을 활용할 수 있다. @SpringBootTest 애노테이션의 경우 기본적으로는 서버를 시작하지 않지만, webEnvironment 옵션을 통해서 어떤 식으로 테스트 환경을 조성할지 설정할 수 있다.

MOCK (기본값)

: ApplicationContext을 로드라고 가짜 웹 환경을 구성한다. 내장 서버가 시작되지 않으며, mock-based의 웹 애플리케이션의 테스트를 하기 위해서 @AutoConfigureMockMvc 또는 @AutoConfigureWebTestClient와 함게 사용할 수 있다.

RANDOM_PORT

WebServerApplicationContext를 로드하고, 실제 웹 환경을 제공한다. 내장 서버가 실행되고, 임의의 포트에서 실행된다.

- 만약, 사용한 포트 정보가 궁금하다면 @LocalServerPort 어노테이션을 통해서 해당 포트 정보를 얻어올 수 있다. (@Value("${local.server.port}")와 완전히 동일한 역할을 한다.)

DEFINED_PORT

WebServerApplicationContext를 로드하고 실제 웹 환경을 제공하며, 내장 서버가 실행되지만 application.yml에 지정한 포트나 기본 포트인 8080을 사용한다.

NONE

ApplicationContext를 로드하지만 웹 환경을 구축하지 않는다.

⭐️ 만약, @Transactional을 테스트 메서드에 적용할 경우, 각 테스트 메서드가 끝날 때 롤백된다. 하지만 RANDOM_PORT, DEFINED_PORT를 통해 실제 웹 환경을 사용하게 되면 트랜잭션이 잡힌 테스트 메서드의 스레드와 웹 서버의 스레드가 다르기 때문에 별도의 트랜잭션에 실행되어 테스트 메서드에서 실행된 메서드의 경우 트랜잭션 롤백이 되지 않는다.

@WebMvcTest

Spring MVC 인프라를 자동을 구성하고, 웹 계층에서 사용하는 컴포넌트들을 스캔한다.

이때 스캔되는 컴포넌트는 @Controller, @ControllerAdvice, @JsonComponent, Converter, GenericConverter, Filter, HandlerInterceptor, WebMvcConfigurer, WebMvcRegistrations 및 HandlerMethodArgumentResolver 등이 사용되며, 우리가 흔히 사용하는 @Service, @Component, @Repository가 붙은 클래스들은 스캔 대상이 아니다.

이게 무슨 소리인지 이해하기 어려울 수 있다. 코드를 통해 확인해보자.

@Controller
public class SampleController {
    void test() {

    }
}

테스트용 컨트롤러이다. 그리고, 해당 컨트롤러를 테스트하기 위한 테스트용 메서드를 생성해보자.

@WebMvcTest
class SampleControllerTest {

    @Autowired
    private SampleController sampleController;

    @Test
    void test() {

    }
}

단순히 @WebMvcTest만 생성하고, @Autowired를 통해 주입받으면 아무 오류 없이 잘 동작한다.

하지만, SampleController 클래스의 어노테이션을 @Service로 만들어보자.

@Service
public class SampleController {

    void test() {

    }
}

Error creating bean with name 'com.example.study.SampleControllerTest': Unsatisfied dependency expressed through field 'sampleController': No qualifying bean of type 'com.example.study.SampleController' available: expected at least 1 bean which qualifies as autowire candidate. Dependency annotations: {@org.springframework.beans.factory.annotation.Autowired(required=true)}

그러면 위와 같이 적절한 빈이 없다는 오류 메시지가 나온다.

즉, @Service의 경우 스캔 대상이 아니기 때문에 빈으로 생성되지 않아 의존 관계를 주입받을 수 없는 것이다.

그래서 나는 위와 같은 경우에 보통 2가지 솔루션을 사용하였다.

1. 인자로 대상 클래스를 지정해주기

@WebMvcTest(SampleController.class)
class SampleControllerTest {

    @Autowired
    private SampleController sampleController;

    @Test
    void test() {
    }
}

2. Mock 객체로 선언해주기

@ExtendWith(MockitoExtension.class)
class SampleControllerTest {

    @InjectMocks
    private SampleController sampleController;

    @Test
    void test() {
    }
}

개인적으로 미션을 진행하면서 페어에게 @WebMvcTest의 경우 컨트롤러 계층을 테스트할 때 사용하는 게 좋을 것 같다는 이야기를 들었어서, 두 번째 방법으로 서비스 레이어를 테스트하곤 했다.

@JdbcTest

@JdbcTest 어노테이션의 경우 기본적으로 내당 데이터베이스 및 JdbcTemplate 빈을 구성한다.

DB 레이어를 테스트할 때 많이 사용하며, 내부적으로 @Transactional 어노테이션이 선언되어 있기 때문에 클래스 레벨에 붙이면 각 테스트 메서드가 종료될 때 함께 롤백된다.

여기서 @AutoConfigureJdbc 어노테이션을 통해서 Jdbc 와 관련된 빈들만 컨텍스트로 등록된다.

또한, @AutoConfigureTestDatabase 어노테이션 덕분에 인메모리 데이터베이스를 사용할 수 있게 된다.

참고로, 이 어노테이션의 경우 replace 옵션에 따라서 인메모리 데이터베이스를 사용할지 말지 결정할 수 있다.

@JdbcTest
@AutoConfigureTestDatabase
class SampleControllerTest {

    @Test
    void test() {
    }
}

간단하게 살펴보자. 해당 어노테이션을 사용한 결과이다. (사용하지 않은 경우에도 @JdbcTest에 의해서 지정된 것과 같은 효과)

- 참고로, Replace 옵션은 기본적으로 Any이다. Any의 경우 자동으로 구성된 정보를 사용하거나, 혹은 수동으로 구성된 정보를 사용한다.

확인해보면 다른 인메모리 데이터베이스를 사용하는 것을 볼 수 있다.

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

    @Test
    void test() {
    }
}

반면에, Replace를 NONE으로 해보자.

이때는 application.yml에 정의한 database를 사용하게 된다.

@DataJdbcTest

@DataJdbcTest의 경우 @JdbcTest와 거의 비슷하긴 하다.

하지만 딱 한 가지 다른 점이 있는데, @AutoConfigureDataJdbc라는 어노테이션이다.

이는 Spring Data JDBC repositories를 사용하는 테스트에서 사용한다.

사용해본 적이 없어서 좀 찾아봤는데, JPA랑 문법이 거의 비슷한 것 같다.

알아보고 싶다면 공식 문서를 보는 것도 좋을 것 같다.

테스트 쪽은 파고 팔수록 내용이 너무 많아서 자르기가 힘들다 ㅠ_ㅠ

그래도 기술 부채 중 하나였는데 가볍게 잘 보고 넘어가는 것 같다!

[Spring] IoC Container의 생명주기와 DI, 빈 스코프, 빈과 스태틱 메서드

dolmeng2 — Sun, 7 May 2023 18:19:40 +0900

들어가기 전

스터디에서 발표 자료로 준비했던 내용인데, 블로그에도 옮겨두면 좋을 것 같아서 정리하는 글

프롤로그 로드맵의 키워드 위주로 정리하였습니다!

DI (의존관계 주입)

✔️ 의존한다?

A가 B를 사용하고, B를 변경하면 A에 영향을 끼치는 관계.

의존관계 주입은 다음 세 가지 조건을 충족하는 작업을 의미한다.

- 클래스 모델이나 코드에는 런타임 시점의 의존관계가 드러나지 않도록, 인터페이스만 의존해야 한다.
- 런타임 시점의 의존관계는 컨테이너나 팩터리와 같은 제 3의 존재 (ex. IoC container)가 결정한다.
- 의존관계는 사용할 오브젝트에 대한 레퍼런스를 외부에서 제공해줌으로서 만들어진다.

✔️ DI를 사용하면 무엇이 좋은가?

- 객체간의 결합도 감소 → 재사용성, 유지보수성 증가

- 외부에서 주입이 가능하기 때문에 테스트 시 용이함

- 가독성 증가

의존성을 주입하는 방법에는 무엇이 있는가?

의존 관계 주입은 크게 4가지 방법으로 나누어진다.

⭐️ 스프링 컨테이너가 관리하는 스프링 빈이어야만 의존관계 주입이 동작한다. (컴파일 시점에 해당하는 타입이 없으면 오류가 발생한다)

생성자 주입

생성자를 통해서 의존 관계를 주입받는 방법. 생성자 호출 시점에 딱 1번만 호출된다.

만약 필드를 private final로 선언했다면 (일반적) 불변 및 생성에 대한 보장을 해줄 수 있다. (Spring 팀에서 권장하는 주입 방식)

컴파일 시점에 값이 설정되지 않았다면 오류가 발생해서 막아준다.

만약 생성자가 1개라면 자동으로 @Autowired가 붙은 것과 동일한 효과를 주기 때문에 생략이 가능하다.

⭐️ 기본적으로 스프링은 빈을 등록하는 단계와 의존관계를 주입하는 단계가 나누어져 있지만, 생성자 주입의 경우 빈을 등록하는 단계와 의존관계 주입이 동시에 일어난다.

이는 빈을 등록할 때 생성자를 호출해야 하기 때문에 의존 관계도 함께 주입되기 때문이며, 생성자 주입과 수정자 주입을 혼용하더라도 동시에 일어난다. (생성자 주입 이후 setter 주입 진행)

수정자 주입

setter를 통해 의존 관계를 세팅해주는 방법. 생성자 주입을 통해 의존 관계가 주입되었더라도, 변경하고 싶을 때 사용 가능

수정자에 @Autowired를 붙여서 주입할 수 있다.

⭐️ 몇몇 글에서는 수정자 주입, 필드 주입을 진행하면 순환참조 문제를 잡을 수 없다고 말하지만, 스프링 2.6부터는 순환 참조를 기본으로 안 되도록 변경했기 때문에 런타임 시점에 서버가 실행되지 않는다.

필드 주입

필드에 @Autowired를 선언하여 바로 주입하는 방법.

코드는 간결하지만, 외부에서 변경이 불가능하기 때문에 테스트하기 어려워진다.

DI 프레임워크에 의존적인 형태이다.

일반 메서드 주입

일반 메서드를 통해서 주입하는 방법.

수정자 주입처럼 setXXX의 형태여야 하지만, 수정자 주입과 다르게 여러 개의 파라미터를 넘길 수 있다.

일반적으로 잘 사용하지 않는 방법이다.

IoC (제어의 역전)

오브젝트의 생성과 관계 설정, 사용, 제거 등의 작업을 외부로 위임하는 것.

✔️ IoC container (Spring Container)

- 스프링 프레임워크에서 IoC를 통해 Object를 관리하기 위해 사용하는 개념

BeanFactory / ApplicationContext 인터페이스.

ApplicationContext가 BeanFactory를 상속받고 있기 때문에 일반적으로 더 많이 사용한다.

- IoC container에 등록된 Bean에 대해서 DI를 내부적으로 관리

이때, 컨테이너에 등록하기 위해 개발자가 제공하는 정보를 ‘metadata’라고 표현

XML 기반 / 어노테이션 기반 구성으로 나누어진다.

스프링 컨테이너의 라이프사이클은 어떻게 되는가?

⭐️ 생성과 초기화를 분리하는 것이 핵심 역할이다.

✔️ 빈이란?

Spring IoC 컨테이너에 의해서 인스턴스화 되고, 관리되는 객체이다.

1. 스프링 컨테이너 생성

말 그대로 스프링 컨테이너가 생성되는 과정이다.

2. 스프링 빈 생성

@Configuration + @Bean

개발자가 컨트롤할 수 없는 외부 라이브러리들을 Bean으로 등록할 때 사용

ex) ObjectMapper 클래스를 커스텀하고 싶을 때

// 이런 식으로 'RedisTemplate'이라는 클래스에 직접 접근할 수 없는 경우
@Bean
public RedisTemplate<String, Object> redisTemplate(RedisConnectionFactory redisConnectionFactory) {
    RedisTemplate<String, Object> redisTemplate = new RedisTemplate<>();
    redisTemplate.setConnectionFactory(redisConnectionFactory);
    redisTemplate.setKeySerializer(new StringRedisSerializer());
    redisTemplate.setValueSerializer(new StringRedisSerializer());
    return redisTemplate;
}

@Component

개발자가 컨트롤할 수 있는 클래스에 대해서 사용

Component의 경우 클래스에 대해서만 지정이 가능하다.

// 이런 식으로 직접 작성한 클래스에 대해서 선언하고 싶을 때 지정
@Component
public class RaceNumberGenerator implements NumberGenerator {
	...
}

- @ComponentScan 어노테이션에 의해서 @Component 및 스테레오 타입 (@Controller, @Service, @Repository) 어노테이션이 부여된 클래스들을 자동으로 스캔하여 빈으로 등록해준다.

- 기본적으로 빈의 이름은 클래스명을 사용하며, 가장 앞글자를 소문자로 사용한다.

- 어노테이션의 인자로 빈의 이름을 직접 지정해줄 수 있다.

3. 의존 관계 주입

생성자에 지정된 @Autowired를 보고, 스프링 컨테이너가 자동으로 빈을 찾아 조회한다.

의존 관계 주입 시 ‘타입이 같은 빈’을 찾아서 조회한다.

그래서 동일한 타입이 있다면 @Primary나 @Qualifier 어노테이션을 사용하여 어떤 빈을 우선으로 주입할지 지정해야 한다.

4. 초기화 콜백

빈 생성 및 의존 관계 주입이 끝나야 필요한 데이터를 사용할 수 있는 준비가 된다.

스프링은 의존관계 주입이 완료되면, 스프링 빈에게 콜백 메서드를 통해서 어떠한 초기화 기능을 할 수 있도록 제공한다.

InitializingBean

InitializingBean 인터페이스의 afterProperiesSet() 메서드를 통해 초기화를 지원할 수 있다.

스프링 전용 인터페이스이기 때문에, 스프링에 의존적인 형태가 된다. (잘 사용하지 않는 형태)

빈 설정 정보에 초기화 메서드 지정

@Bean(initMethod=””)을 통해서 초기화 메서드를 지정할 수 있다.

설정 정보를 활용하는 방법이기 때문에 수정할 수 없는 외부 라이브러리에 대해서도 초기화 메서드를 지정할 수 있다.

⭐️ @PostConstruct 사용

가장 권장하는 방법이다. 어노테이션 하나만 붙이면 돼서 간단하다.

자바 표준 기술이기 때문에 스프링에 종속적이지 않다.

외부 라이브러리에는 적용하지 못한다.

위의 방법들을 혼용하여 사용한다면, 다음과 같은 순서로 호출된다.
@PostConstruct → afterPropertiesSet() → @Bean(initMethod=””)

5. 실제로 사용하기

우리가 실제로 애플리케이션 내에서 비즈니스 로직을 구성하며 사용하는 단계이다.

6. 소멸 전 콜백

싱글톤 빈들은 스프링 컨테이너 종료 시 빈들도 함께 소멸하기 때문에, 소멸전 콜백이 발생한다.

DisposableBean 사용

DisposableBean 인터페이스의 destroy() 메서드를 통해 소멸을 지원할 수 있다.

빈 설정 정보에 소멸 메서드 지정

@Bean(destroyMethod=””)을 통해서 초기화 메서드를 지정할 수 있다.

설정 정보를 활용하는 방법이기 때문에 수정할 수 없는 외부 라이브러리에 대해서도 소멸 메서드를 지정할 수 있다.

참고로, 외부 라이브러리를 대부분 close, shutdown이라는 이름으로 종료 메서드를 사용하고 있다. destroyMethod는 내부적으로 추론 기능이 있기 때문에 스프링 빈으로 등록했다면 종료 메서드를 따로 작성하지 않아도 알아서 동작한다.

⭐️ @PreDestroy 사용

마찬가지로 권장하는 방법이다. 어노테이션 하나만 붙이면 돼서 간단하다.

자바 표준 기술이기 때문에 스프링에 종속적이지 않다.

외부 라이브러리에는 적용하지 못한다

위의 방법들을 혼용하여 사용한다면, 다음과 같은 순서로 호출된다.
@PreDestroy → destroy() → @Bean(destroyMethod=””)

7. 스프링 컨테이너 종료

빈 스코프란?

스코프는 ‘빈이 존재할 수 있는 범위’를 의미한다.

스프링에서는 총 6가지의 스코프를 제공하며, @Scope 어노테이션을 이용하여 지정할 수 있다.

싱글톤 스코프

스프링에서 기본적으로 사용하는 스코프이다.

스프링 컨테이너가 시작될 때 생성되어서, 종료될 때까지 유지한다. (가장 넓은 범위)

IoC 컨테이너에서 조회하게 되면 항상 같은 인스턴스의 빈을 반환한다.

프로토타입 스코프

IoC 컨테이너는 빈의 생성과 의존 관계, 초기화까지만 관여하고, 그 이상 관리하지 않는 스코프이다.

종료 콜백 메서드는 호출되지 않는다.

IoC 컨테이너에 조회 시 때 빈을 생성하고, 필요한 의존관계를 주입하기 때문에 매번 새로운 인스턴스를 반환한다.

⭐️ 싱글톤 스코프 with 프로토타입 스코프

싱글톤 스코프를 가진 빈은 컨테이너 생성 시점에 생성되고, 의존관계 주입이 발생한다.
만약 주입 시 필요한 빈이 프로토타입 빈이라면, 컨테이너는 이를 받아 새로운 인스턴스를 생성하여 반환한다.

그러면 싱글톤 빈은 여전히 프로토타입에 대한 빈의 의존 관계를 가지고 있기 때문에, 참조 관계를 보관하고 있다.
단, 과거에 주입이 끝난 상태로 반환받은 것이기 때문에 사용한다고 해서 새롭게 생성되는 것은 아니다.
만약, 싱글톤 빈을 사용할 때 내부적으로 프로토타입 빈을 사용하는 로직을 호출했다면 이미 주입이 끝난 시점이기 때문에 새로운 빈이 아닌 기존의 빈을 계속해서 사용하는 형태로 사용하게 된다. (=즉, 싱글톤 빈과 생명주기가 동일해진다)

이를 해결하기 위해서는 ObjectProvder를 사용할 수 있다. (컨테이너에서 조회하기 때문에 새로운 인스턴스를 생성하기 때문에 프로토타입의 기능을 사용할 수 있게 됨)

request 스코프

HTTP 요청과 동일한 생명주기는 스코프이다. HTTP 요청마다 인스턴스가 생성되고 관리되는 형태이다.

session 스코프

Http 세션과 동일한 생명주기를 가지는 스코프이다.

application 스코프

서블릿 컨텍스트와 동일한 생명주기를 가지는 스코프이다.

과거에는 스프링 컨테이너를 여러 개 띄웠기 때문에 각 컨테이너마다 관리되는 빈을 다르게 하기 위해서 사용했었다. (지금은 하나의 스프링 컨테이너를 사용해서 처리하는 것이 대부분이다.)

websocket 스코프

웹 소켓과 동일한 생명주기를 가지는 스코프이다.

⭐️ 싱글톤 스코프 with 웹 스코프

위의 4가지 경우를 웹 스코프라고 한다.
싱글톤 빈의 경우 스프링 컨테이너와 라이프 사이클이 동일하기 때문에 컨테이너 생성 시 같이 생성되지만, 웹 스코프의 경우 각각의 요청이 들어왔을 때 빈이 생성되기 때문에, 만약 싱글톤 빈이 웹 스코프 빈을 의존 관계로 가지고 있을 때 의존 관계 주입이 불가능해진다.

이를 위해서 2가지 방법을 사용할 수 있다.
1. ObjectProvider 사용하기
- getObject()를 호출하는 시점까지 웹 스코프 빈의 생성을 지연시키기

2. 프록시 사용하기
- @Scope 어노테이션의 인자로 proxyMode = ScopedProxyMode.TARGET_CLASS 지정하기 (클래스일 경우, 인터페이스라면 INTERFACES 사용)
- 이러면 가짜 프록시 객체를 주입해주기 때문에 상관이 없어진다. 가짜 프록시 객체의 경우, 요청이 왔을 때 진짜 빈으로 요청을 위임한다.

모든 객체를 스프링 빈으로 등록해도 괜찮을까?

기본적으로 ‘싱글톤’으로 관리하고 싶은 인스턴스에 대해서만 스프링 빈으로 등록하는 것이 올바른 방법이라고 생각한다.

하지만, 싱글톤 빈의 경우 항상 같은 인스턴스를 반환받는다. 만약 해당 인스턴스가 어떠한 상태를 가지고 있다면, 해당 상태는 유지되지 않기 때문에 예기치 못한 버그가 발생할 수 있다.

물론, 불가능한 건 아니다. 스코프를 프로토타입으로 만든다면 항상 새로운 인스턴스를 반환받도록 만들 수 있다. 하지만, 상태가 변경될 때마다 새로운 객체를 반환받아서 스프링 컨테이너가 관리하게 된다면 애플리케이션 성능상으로도 문제가 발생할 수 있다.

공식 문서에서는 아래와 같은 답변을 내두었다.

These bean definitions correspond to the actual objects that make up your application.
Typically, you define service layer objects, persistence layer objects such as repositories or data access objects (DAOs), presentation objects such as Web controllers, infrastructure objects such as a JPA EntityManagerFactory, JMS queues, and so forth.

Typically, one does not configure fine-grained domain objects in the container, because it is usually the responsibility of repositories and business logic to create and load domain objects.

빈에 대한 정의는 애플리케이션을 구성하는 객체들로 이루어져 있다.

일반적으로 service layer, 레포지토리나 DAO 같은 persistence layer, 컨트롤러 같은 presentation layer, 혹은 infrastructure layer 등에서 사용되는 객체를 정의한다.

하지만, 도메인 객체를 생성하고 로드하는 것은 ‘레파지토리 및 비즈니스 로직의 책임’이기 때문에 IoC 컨테이너에서 이를 구성하는 것은 일반적이지 않다고 하였다.

빈으로 등록하는 것 vs 스태틱 메서드를 사용하는 것

이전의 웹 스코프를 설명할 때 말했던 것처럼, 스프링 컨테이너를 여러 개를 띄우는 상황에서 전역적으로 관리하고 싶다면 static method를 사용해서 관리할 수 있을 것 같다. (다만, application scope가 있기 때문에 사실 이마저도 의미있는지 잘 모르겠다.)

static 메서드의 경우 인자가 동일하다면 항상 동일한 결과를 반환해야 하는데, 이를 지킬 수 없다면 POJO bean으로 만들라는 글이 있었다. 외부 자원을 의존하지 않으면서, 항상 동일한 결과만 반환함을 보증할 수 있다면 (util성 클래스) 굳이 빈으로 등록할 필요는 없을 것 같다.

추가적으로, 지금은 크게 상관없지만 static 메서드의 경우 공유 범위가 클래스 로더를 기준으로 하고, 싱글톤 빈의 경우 애플리케이션 컨텍스트를 기준으로 하기 때문에 앞서 말한 것처럼 컨테이너를 여러 개 띄우는 상황이라면 생명주기 차원에서도 static method를 사용할 수 있을 것 같다.