Mash-Up

[스프링팀] PK 숨기기

MASHUP — Fri, 18 Oct 2024 00:58:46 +0900

Mash-Up 스프링팀에서는 팀원들이 돌아가면서 본인의 Problem-Solving 경험이나 Deep Dive의 내용을 발표하는 자리를 갖습니다. 이번 14기 활동 때 발표한 내용중 하나인 PK 숨기기 에 대해 이번 포스팅에서 다뤄보겠습니다. 발표자는 프로젝트 개발 중 Front 개발자가 우리의 PK를 과연 외부에 노출해도 괜찮을까? 라는 질문에 대해 논의를 하다가 이 문제를 해결했다는데요. 문제를 해결하기 위해 어떤 고민을 했고 어떤 해결방법을 도출해냈는지 함께 알아봅시다.

PK 숨기기

개요

프로젝트 개발 중 무분별하게 노출되는 PK에 대해서 프론트 개발자와 PK 과연 외부에 노출해도 괜찮은것일까? 에 대해 논의를 하다가 나중에 구현해보자! 라고 생각하다 문득 생각이 나서 이 문제를 해결해보게 되었다.

PK 과연 외부에 노출해도 괜찮을까?

REST API 에서 pk를 외부에 노출하는 경우

요즘 개발을 한다고 하면 대부분이 REST 방식의 API를 구현하는 경우가 대부분이다. 그리고 리소스에 접근하는 방식이 대개 다음과 같은 방식으로 이루어진다.

GET /api/v1/posts/{postId} , GET /api/v1/comments/{commentId] 등 PK를 통해서 직접적으로 접근하는 경우가 대부분이다. 이 경우 PK가 AutoIncrement 형식의 Long 형 값이라면 공격자 입장에서 무분별하게 특정 리소스에 접근이 가능할 것이다. 만약 해당 리소스에 대해 특정 사용자만 접근이 가능하다고 할 때 서비스 내부적으로 특정 사용자가 아닌 경우에 대한 권한 처리를 제대로 하고 있다면 문제가 없을테지만 그렇지 않은 경우 원치 않은 사용자에게 리소스 정보가 넘어갈 수 있다.

심지어 그것이 AutoIncrement 형식의 PK 라면 리소스가 만들어진 순서에 따라 순차적으로 리소스에 접근할 수 있게 된다. 즉, 추측이나 인젝션 공격의 대상이 될 수 있다. 예를 들어 userId라는 식별자를 생각해봤을 때 GET /users/{userId} 요청으로 의도치 않게 타인의 마이페이지 접속 루트가 열리는 문제가 생길 수 있을 것이고. 특정 연속되는 값을 넣는다면 해당 서비스의 회원 수를 유추해 볼 수도 있다.

실제로 2020년 5월 특정 서비스에서 유저 아이디를 URL PATH로 사용해 유저의 거래 내역을 노출하는 GET API에 대해 URL 숫자 조작만으로 다른 이의 거래 내역을 손쉽게 드러낸 경우도 있다.

그렇다면 PK를 UUID로 변경하면 될까?

PK를 AutoIncrement가 아닌 UUID를 사용하는 경우

UUID를 사용하면 확실히 AutoIncrement PK에 비해 리소스에 무분별하게 접근할 수는 없을 것이다. 하지만 Auto Increment 보다 더 많은 공간을 차지하게 돼서 데이터베이스 인덱싱 및 스토리지에 오버헤드가 발생할 수 있다. 심지어 PK를 외부에 노출하지 않겠다고 모든 테이블 key 값을 UUID로 변경하는 것은 너무 과한 조치인 것 같다.

공통적인 문제

AutoIncrement PK, UUID PK 등 뭐든간에 PK를 외부에 노출하면 결국 데이터베이스의 구조와 공격자에게 도움이 될 만한 정보가 외부에 들어난다는 것이다. 그러면 UUID를 사용하지 않는 방법으로 이 문제를 해결해보자

요구사항

구현하기 앞서 다음과 같은 요구사항을 생각해보았다.

이 문제를 해결하기 위해 다른 의존성이 생기지 않았으면 한다.
최대한 핵심 로직을 건들지 않는 선에서 해결했으면 좋겠다.

해결 방법

PK 매핑

내부적으로는 AutoIncrement PK를 사용하고 외부로 노출되는 PK는 UUID를 사용해 원본 PK(AutoIncrement)와 UUID를 매핑하는 테이블을 만드는 것이다. 하지만 RDB가 아닌 다른 NoSQL 저장소를 쓴다고 해도 Persistence 부분에 의존성이 생기기 때문에 이 해결방법은 제외했다.

PK 암호화

서비스에 들어오고 나가는 PK에 대해 모두 암호화를 시켜주는 방식이다. Controller 부분에서 요청을 받고 응답을 줄 때 암호화를 해주면 되기에 핵심로직(Service)에 무리가 가지 않으며 의존성이 추가되진 않기에 이 해결방법을 채택했다.

아이디어

위의 요구사항 2번에 핵심 로직을 건들지 않는 선에서 해결하기 원했기에 극한으로 핵심 로직을 건들지 않게 실제로 요청을 받고 처리하는 부분에서는 내부적으로 사용하는 PK값을 온전히 전달받을 수 있게 구현하고자 했다. 이를 위해 사용한 기술은 다음과 같다.

ArgumentResolver
1. ArgumentResolver를 사용해 Parameter로 해당 pk가 들어온 경우 이를 추출해 Long 형 타입으로 바꿔주기 위해 사용했다
2. PathVariableArgumentResolver를 사용해 path에 pk를 담은 경우 이를 추출해 Long 형 타입으로 바꿔주기 위해 사용했다
AOP
1. Response 조차 Long형 타입에 간단히 어노테이션을 붙이는 것 만으로 자동으로 String으로 변경해서 외부로 내보낼 수 있게 하기 위해 사용하였다.
ByteBuddy
1. 클래스를 동적으로 생성하기 위한 라이브러리이다. AOP를 통해 Response를 외부로 내보낼 때 암호화 할 PK의 타입을 변경해 새로운 클래스를 만들기 위해 사용하였다.

구현

이 프로젝트는 Long 형 타입의 AutoIncrement PK를 사용하였다.

기본 서비스

SampleController

@RequestMapping("/api/v1/sample")
@RestController
@SecretTarget
class SampleController(private val sampleService: SampleService) {

    @PostMapping
    fun create(@RequestBody request: SampleRequest): Response<Any> {
        return Response.success(sampleService.create(request.email, request.nickname))
    }

    @GetMapping("/get")
    fun get1(@SecretPk id: Long): Response<Any> {
        return Response.success(data = sampleService.getById(id))
    }

    @GetMapping("/get/{id}")
    fun get2(@SecretPkPathVariable("id") id: Long): Response<Any> {
        return Response.success(data = sampleService.getById(id))
    }
}

SampleService

@Service
class SampleService {

    private val userMap = ConcurrentHashMap<Long, SampleResponse>()

    fun create(email: String, nickname: String): SampleResponse {
        val nextId = (userMap.map { it.key }.maxOrNull() ?: -1) + 1
        userMap[nextId] = SampleResponse(nextId, email, nickname)
        return userMap[nextId]!!
    }

    fun getById(id: Long): SampleResponse {
        return userMap[id] ?: throw IllegalArgumentException("cannot find user, userId: $id")
    }
}

Inmemeory 캐싱을 통해 SampleResponse를 주고 받는 간단한 서비스다.

Encryptor

실제로 PK를 암/복호화 해주는 Encryptor를 만들어보자

class SecretEncryptor(private val property: SecretPkProperty) {

    private val secretKey: SecretKey

    init {
        val keyBytes = property.secretKey.toByteArray()
        secretKey = SecretKeySpec(keyBytes, property.algorithm)
    }

    fun encryptLongToString(value: Long): String {
        val cipher = Cipher.getInstance(property.algorithm)
        cipher.init(Cipher.ENCRYPT_MODE, secretKey)

        val byteBuffer = ByteBuffer.allocate(8)
        byteBuffer.putLong(value)
        val longBytes = byteBuffer.array()
        val encryptedBytes = cipher.doFinal(longBytes)
        return Base64.getEncoder().encodeToString(encryptedBytes)
    }

    fun decryptStringToLong(encryptedString: String): Long {
        val cipher = Cipher.getInstance(property.algorithm)
        cipher.init(Cipher.DECRYPT_MODE, secretKey)

        val encryptedBytes = Base64.getDecoder().decode(encryptedString)
        val decryptedBytes = cipher.doFinal(encryptedBytes)
        return ByteBuffer.wrap(decryptedBytes).getLong()
    }
}

javax.crypto 를 사용해서 SecretPkProperty(algorithm, key) 를 입력받아 SecretKey를 생성한다.

SecretPkConfig

@Configuration
@EnableConfigurationProperties(SecretPkProperty::class)
class SecretPkConfig {
    @Bean
    fun secretEncryptor(property: SecretPkProperty): SecretEncryptor {
        return SecretEncryptor(property)
    }
}
@ConfigurationProperties(prefix = "secret.pk")
data class SecretPkProperty(val algorithm: String, val secretKey: String)

ArgumentResolver

이제 실제로 path나 parameter로 들어온 id 값을 추출해 복호화 한 후 Controller에 던져주자.

기본적으로 들어오는 형식은 다음과 같을 것이다.

/api/v1/sample/{sampleId} or /api/v1/sample?id={sampleId}

Parameter로 들어온 경우

SecretPkArgumentResolver

class SecretPkArgumentResolver(private val encryptor: SecretEncryptor) : HandlerMethodArgumentResolver {

    private val log: Logger = LoggerFactory.getLogger(SecretPkArgumentResolver::class.java)

    override fun supportsParameter(parameter: MethodParameter): Boolean {
        return parameter.hasParameterAnnotation(SecretPk::class.java)
                && parameter.parameter.type == Long::class.java
    }

    override fun resolveArgument(
        parameter: MethodParameter,
        mavContainer: ModelAndViewContainer?,
        webRequest: NativeWebRequest,
        binderFactory: WebDataBinderFactory?
    ): Any {
        val param = webRequest.parameterMap[parameter.parameterName]?.firstOrNull()
        log.info("parameter.parameter: ${parameter.parameter}, parameter: $parameter, param: $param")
        param ?: throw IllegalStateException("param must not be null")
        return encryptor.decryptStringToLong(param) // param을 입력받아 decrypt 작업 수행
    }
}

Path로 들어온 경우

SecretPkPathVariableArgumentResolver

class SecretPkPathVariableArgumentResolver(private val encryptor: SecretEncryptor) : HandlerMethodArgumentResolver {

    override fun supportsParameter(parameter: MethodParameter): Boolean {
        return parameter.hasParameterAnnotation(SecretPkPathVariable::class.java)
    }

    override fun resolveArgument(
        parameter: MethodParameter,
        mavContainer: ModelAndViewContainer?,
        webRequest: NativeWebRequest,
        binderFactory: WebDataBinderFactory?
    ): Any {
        val pathVariables = webRequest.getAttribute(
            HandlerMapping.URI_TEMPLATE_VARIABLES_ATTRIBUTE,
            NativeWebRequest.SCOPE_REQUEST
        ) as Map<*, *>

        val paramName = parameter.parameterName ?: throw IllegalArgumentException("Parameter name is null")
        val param = pathVariables[paramName] as? String ?: throw IllegalArgumentException("Parameter name is null")
        return encryptor.decryptStringToLong(param)
    }
}

실제 사용법

@GetMapping("/get")
fun get1(@SecretPk id: Long): Response<Any> {
    return Response.success(data = sampleService.getById(id))
}

@GetMapping("/get/{id}")
fun get2(@SecretPkPathVariable("id") id: Long): Response<Any> {
    return Response.success(data = sampleService.getById(id))
}

@SecretPk 어노테이션을 사용하면 SecretPkArgumentResolver를 통해 파라미터에 담긴 id를 decryp 해서 Long 형 타입으로 PK를 바로 받아올 수 있다.

@SecretPkPathVariable 어노테이션을 사용해 SecretPkPathArgumentResolver를 통해 path에 담긴 id를 복호화해서 바로 받아올 수 있다.

이를 통해 사용자는 id가 String이었는지 암호화가 어떻게 수행되는지 전혀 알 필요 없이 핵심 로직에만 집중할 수 있다.

SecretPkAspect

그러면 암호화는 어떻게 진행할까? 사실 가장 심플한 방법은 DTO에 String 타입의 id를 적어주면 된다. 다음과 같다.

data class SampleResponse(
    val id: String,
    val email: String,
    val nickname: String
)

하지만 이 또한 Response에 정보를 담으면서 id를 암호화 해줘야 하는 필요성이 있다. 핵심 로직에 집중하기 위해 id를 다음과 같이 변경해보자.

data class SampleResponse(
    @field:SecretPk val id: Long,
    val email: String,
    val nickname: String
)

이렇게 SecretPk가 달린 필드의 경우 AOP에서 알아서 String 형태로 변환한 후 암호화 해서 내보냈으면 하는 요구사항이 있었다. 어떻게 해결할 수 있을까?

Filter를 사용해보자

Filter는 Interceptor와는 다르게 Response 조작이 가능하다. 하지만 이는 Spring MVC 외부에 있기에 클래스 원형에 접근하기 어렵다. 왜냐하면 우리는 @SecretPk 가 붙은 함수 원형을 참조해야 하기 때문에 반환 타입의 정보가 필요하기 때문이다!

Spring AOP를 사용해보자

이 또한 작은 문제점이 존재한다. Controller 단의 반환 값을 변경하는 것이기 때문에 반환값은 결국 동일해야 한다. id를 Long → String으로 변경한다면 상속도 불가능하니 새로운 클래스가 필요한데 클래스를 정적이든 동적이든 변경한다면 반환 타입의 불일치의 문제가 생긴다. 이를 Wrapper를 둬서 어느정도 합의를 보았다.

fun get1(@SecretPk id: Long): Response<Any> {
    return Response.success(data = sampleService.getById(id))
}

Response를 반환해 안에 담길 data 타입이 변경 가능하도록 설정해줘야 했다. (가장 꼬롬함)

반환값을 단순히 String으로 변환해서 내려줄까? (objectMapper 이용해서) 아니면 동적으로 클래스를 새로 생성해서 반환할까? 고민을 많이 하다가 후자의 방식을 선택해 reflection 기술과 ByteBuddy 라는 라이브러리를 사용해 구현했다.

SecretPkAspect

var dynamicClassBuilder = byteBuddy
      .subclass(Any::class.java)
      .name(resultDataClassName + SUFFIX_DYNAMIC_CLASS_NAME)

우선 ByteBuddy를 통해 빈 껍데기 클래스를 만들어주자. 클래스 이름은 원본 클래스명 + _S(Secret)을 붙였다.

memberProperties.forEach { property ->
  val hasSecretPkAnnotation =
      property.javaField?.annotations?.firstOrNull()?.annotationClass == SecretPk::class
  dynamicClassBuilder = if (hasSecretPkAnnotation) {
      dynamicClassBuilder.defineField(property.name, String::class.java, Visibility.PUBLIC)
  } else {
      dynamicClassBuilder.defineField(
          property.name,
          property.returnType.jvmErasure.java,
          Visibility.PUBLIC
      )
  }
}

property를 돌면서 SecretPk 어노테이션이 붙은 필드의 경우 String으로 나머지는 본래 자신의 클래스를 따라가게 변경했다.

property.returnType.jvmErasure.java 를 통해서 자바 클래스에 접근해야 한다. property.javaClass 는 자바 클래스가 아니다 KPropery1을 포함한 자바 클래스다.

val newClass = dynamicClassBuilder
    .make()
    .load(SecretPkAspect::class.java.classLoader)
    .loaded

클래스 정의를 다 하고 나면 부모 객체의 ClassLoader를 통해 클래스를 로드 시켜줘야한다.

make 함수를 통해 바이트 코드를 생성한다.

val newClassInstance = newClass.getDeclaredConstructor().newInstance()

만들어진 클래스를 바탕으로 새로운 인스턴스를 만든 후

memberProperties.forEach { property ->
    val hasSecretPkAnnotation =
        property.javaField?.annotations?.firstOrNull()?.annotationClass == SecretPk::class
    if (hasSecretPkAnnotation) {
        val encrypted = (getPropertyValue(data, property.name) as? Long)
            ?.let { encryptor.encryptLongToString(it) }
            ?: throw IllegalStateException("@SecretPk fields must be Long")
        newClass.getField(property.name).set(newClassInstance, encrypted)
    } else {
        val value = getPropertyValue(data, property.name)
        newClass.getField(property.name).set(newClassInstance, value)
    }
}

다시 프로퍼티를 돌면서 실제 값을 넣어주자! SecretPk 어노테이션이 붙어있는 경우는 encryptLongToString을 통해 Long형 PK를 암호화 해서 넣어주고 아닌 경우는 실제 값을 그대로 넣어준다.

SecretPkAspect 사용법

@RequestMapping("/api/v1/sample")
@RestController
@SecretTarget
class SampleController(private val sampleService: SampleService) {

    @PostMapping
    fun create(@RequestBody request: SampleRequest): Response<Any> {
        return Response.success(sampleService.create(request.email, request.nickname))
    }

    @GetMapping("/get")
    fun get1(@SecretPk id: Long): Response<Any> {
        return Response.success(data = sampleService.getById(id))
    }

    @GetMapping("/get/{id}")
    fun get2(@SecretPkPathVariable("id") id: Long): Response<Any> {
        return Response.success(data = sampleService.getById(id))
    }
}

@SecretTarget 을 통해 JoinPoint를 설정해주고 암호화할 요청은 @SecretPk or @SecretPkPathVariable 를 통해 설정해주고 응답의 경우

data class SampleResponse(
    @field:SecretPk val id: Long,
    val email: String,
    val nickname: String
)

data class field 단에 SecretPk 어노테이션을 달아주면 알아서 AOP가 동작한다!

결과

create

get(Path)

get(Parameter)

[스프링팀] Coroutine 찍어먹기

MASHUP — Fri, 18 Oct 2024 00:44:03 +0900

요즘 비동기 프로그래밍에 대한 논의는 앱이나 웹과 같은 프론트 사이드의 진영뿐 아니라 서버 진영에서도 심심치 않게 들리는 화두가 되었습니다. 일례로 Java 21 버전에서 소개된 Virtual Thread와 같이 최신 기술 트렌드에 비동기 프로그래밍은 항상 뜨거운 감자와도 같은 주제입니다. 이번 포스팅에서는 스프링 팀에서 비동기 프로그래밍 방법 중 신흥 강자로 소개되고 있는 Kotlin Corouine이 왜 경량 스레드라고 소개되고 있는지 어떠한 컨셉을 갖고 있는지에 대해 다뤄보고자 합니다.

Why Coroutine?

비동기 프로그래밍이란?

동기(Synchronous)

현재 작업의 응답이 끝남과 동시에 다음 작업이 요청된다.
함수를 호출하는 곳에서 호출되는 함수가 결과를 반환할 때까지 기다린다.
작업 완료 여부를 계속해서 확인한다.

비동기(Asynchronous)

현재 작업의 응답이 끝나지 않은 상태에서 다음 작업이 요청된다.
함수를 호출하는 곳에서 결과를 기다리지 않고, 다른 함수(callback)에서 결과를 기다린다.
작업 완료 여부를 확인하지 않는다.

비동기 프로그래밍 방식 소개

연속적인 두 개의 함수를 처리하는 코드를 각기 다른 비동기 프로그래밍 스타일로 작성해보자.

Callback

interface Callback {
    fun onSuccess()
    fun onFailure()
}

private val dispatcher: ExecutorService = Executors
.newCachedThreadPool { runnable ->
    Thread(runnable).apply {
          isDaemon = true
    }
}

fun doHardWork(callback: Callback): Disposable {
    // .. do Hard Work ..
    return dispatcher.submit {
        if(isSuccess) {
            callback.onSuccess()
        } else {
            callback.onFailure()
        }
    }.asDisposable()
}

fun doNextWork(callback: Callback): Disposable {
        return dispatcher.submit {
            if(isSuccess) {
                callback.onSuccess()
            } else {
                callback.onFailure()
            }
        }.asDisposable()
}

fun main() {
    doHardWork( object: Callback {
            override fun onSuccess() {
                ...
                doNextWork(object: Callback {
                    override fun onSuccess() {
                        ...
                    }

                    override fun onFailure() {
                        ...
                    }
                }
            }

            override fun onFailure() {
                // print error log
            }
        }
    )
}

Rx

fun doHardWork(): Single<Boolean> =    Single.create { emitter -> 
        // .. do hard thing ..
        emitter.onSuccess(isSuccess)
}.subscribeOn(Schedulers.IO)
fun doNextWork(): Single<Boolean> = Single.create { emitter -> 
        // ..do next work ..
        emitter.onSuccess(isSuccess)
}.subscribeOn(Schedulers.IO)

fun main() {
    doHardWork()
        .flatMap { isSuccess -> 
            if(isSuccess) {
                doNextWork()
            } else {
                Single.error("Failed to do hard wrok")
            }
        .doOnError { // Print error log }
        .observeOn(Schedulers.MAIN)
        .subscribe { isSuccess ->
            println("is it success? $isSuccess")
        }
}

Callback 방식과 Rx 방식 비교

Callback 방식의 경우 연쇄적인 함수를 호출할 경우 Callback 지옥에 빠질 수 있다
Rx 방식에서는 비동기 작업의 수행 스레드와 결과 처리 스레드 지정을 손쉽게 설정할 수 있다
Rx 방식에서는 작업 간의 관계 및 스레드 지정이 Chaining 방식으로 작성 가능하여 가독성이 더 좋아진다. (다만, Rx가 제공하는 일련의 Operator를 능숙하게 사용하는 경우에만 가독성의 장점을 챙길 수 있다.)
- exampledata 제어 : map, filter, distinct ..
- event 처리 : doOnError, doOnSubscribe, doOnSuccess, doOnDispose ..
- stream 변경 : flatMap, concatMap, switchMap, compose, switchIfEmpty, …
또한 체인에 예외나 취소에 대한 핸들링이 용이하다
But, Rx 체인의 디버깅은 아직 어렵다. doOn… 등의 operator를 사용해서 디버깅 하는 수준

Coroutine

suspend fun doHardWork(): Boolean {
    // .. do hard work ..
    return isSuccess
}
suspend fun doNextWork(): Boolean {
    return isSuccess
}

fun main() = runBlocking {
    launch(Dispatchers.IO) {
        if(doHardWork()) {
            doNextWork()
        }
    }
}

Callback 및 Rx 방식과 코루틴 방식 비교

코루틴 역시 Rx 처럼 작업 수행 스레드와 결과 처리 스레드를 지정하기 용이하다
코루틴에서 원하는 로직을 수행할 때 스레드 지정 및 로직을 처리하는 과정이 일반 동기 프로그래밍 방식과 흡사하다. (가독성이 높고, 학습 하기 쉽다)
코루틴 역시 작업의 취소 및 에러 핸들링에 용이하다 (취소 및 에러에 관한 부분이 조금 어려운편..)
디버깅에 용이하다

Coroutine 기본 이해

fun main(args: Array<String>) {
    GlobalScope.launch {
        delay(1000L)
        println("World!")
    }
    println("Hello,")
    Thread.sleep(2000L) // for blocking main thread
}

Hello,
World!

delay() 함수는 코루틴 내에서 사용할 수 있는 중단 함수. 즉, GlobalScope.launch {} 는 코루틴 빌더이다.
Thread.sleep(2000L) 를 통해 MainThread를 2초간 Block 하여, 메인함수의 종료를 지연시킨다. 좀 더 자연스러운 스타일로 바꿔보자

fun main(args: Array<String>) = runBlocking {
    GlobalScope.launch {
        delay(1000L)
        println("World!")
    }
    println("Hello,")
    delay(2000L)
}

runBlocking{} 블록은 주어진 블록이 완료될 때까지 현재 스레드를 멈추는 코루틴 빌더이다

이렇게 임의의 시간 (2초) 를 가지고 메인 스레드를 Block하는 것은 좋은 로직이 아니다. 부모 코루틴(runBlocking block = main function)은 자식 코루틴 (GlobalScope.launch{}) 의 작업이 완료되고 종료되는데 까지 얼마나 걸리는지 예측할 수 없기 때문이다.

fun main(args: Array<String>) = runBlocking {
    val job = GlobalScope.launch {
        delay(1000L)
        println("World!")
    }
    println("Hello,")
    job.join()
}

이 또한, 모든 자식 코루틴이 실행될 때마다 Job 객체를 참조하여 join을 호출하는 방식은 매우 불편하다.

모든 코루틴들은 각자의 스코프를 갖는다. 부모 코루틴과 자식 코루틴이 같은 코루틴 스코프 내에 위치하면 부모 코루틴은 알아서 자식 코루틴이 종료되길 기다린다.

fun main(args: Array<String>) = runBlocking { // this -> runBlock's coroutineScope
    launch {
        delay(1000L)
        println("World!")
    }
    println("Hello,")
}

launch 함수는 CoroutineScope.launch() 로 CoroutineScope의 확장 함수이다. runBlocking 블록에서 this 참조로 runBlocking의 coroutineScope에 접근이 가능하며, 위의 코드는 부모 코루틴과 자식 코루틴의 코루틴 스코프가 일치한 모습이다.

CoroutineScope

fun main(args: Array<String>) = runBlocking {
    launch {
        delay(200L)
        println("1")
    }

    coroutineScope {
        launch {
            delay(500L)
            println("2")
        }
        delay(100L)
        println("3")
    }
    println("4")
}

실행결과runBlocking과 coroutineScope의 차이는 runBlocking은 자식 코루틴이 종료되길 기다리면서 현재 스레드를 블락하고 coroutineScope은 그렇지 않다는 차이가 있다.
3 1 2 4

중단 함수

fun main(args: Array<String>) = runBlocking {
    val job = launch {
        doWorld()
    }
        val deferred = async {
            doWorld2()
        }
        deferred.await()
    println("Hello,")
}

suspend fun doWorld() {
    delay(1000L)
    println("World!")
}

가벼움

fun main(args: Array<String>) = runBlocking {
    repeat(100_000) {
        launch {
            delay(1000L)
            print(".")
        }
    }
}

Global 코루틴은 deamon thread 처럼 동작한다

fun main(args: Array<String>) = runBlocking {
    GlobalScope.launch {
        repeat(1000) { i ->
            println("I'm sleeping $i ...")
            delay(500L)
        }
    }
    delay(1300L)
}

I’m sleeping 0 …
I’m sleeping 1 …
I’m sleeping 2 …

Coroutine Context란?

public interface CoroutineContext {
  public operator fun <E : Element> get(key: Key<E>): E?
  public fun <R> fold(initial: R, operation: (R, Element) -> R): R
  public operator fun plus(context: CoroutineContext): CoroutineContext = ...impl...
  public fun minusKey(key: Key<*>): CoroutineContext
}
public interface Key<E : Element>
public interface Element : CoroutineContext {
  public val key: Key<*>
  ...overrides...
}

get() : 연산자 함수로써 주어진 key 에 해당하는 컨텍스트 요소를 반환한다
fold() : 초기값을 시작으로 제공된 병합 함수를 이용하여 대상 컨텍스트 요소들을 병합한 후 결과를 반환한다
plus() : 현재 컨텍스트와 파라미터로 주어진 다른 컨텍스트가 갖는 요소들을 모두 포함하는 컨텍스트를 반환한다. 중복을 포함하지 않는다
minusKey() : 현재 컨텍스트에서 주어진 키를 갖는 요소들을 제외한 새로운 컨텍스트를 반환한다

Element 는 CoroutineContext 를 상속하며 key 를 멤버 속성으로 갖는다. CoroutineContext 를 구성하는 Element 들의 예를 들어보면 CoroutineId, CoroutineName, CoroutineDispatcher, ContinuationInterceptor, CoroutineExceptionHandler 등이 있다.

즉, 코루틴 컨텍스트에는 코루틴 컨텍스트를 상속한 Element 들이 등록될 수 있고, 각 Element들이 등록 될때는 Element의 고유한 Key를 기반으로 등록된다는 것

launch() {} // Only CoroutineId

// CoroutineId + Continuation Interceptor
launch(Dispatchers.IO) {}

// CoroutineId + CoroutineName + Continuation Interceptor
launch(Dispatchers.IO + CoroutineName("SampleCoroutine")){} 

// CoroutineId + CoroutineName + Coroutine ExcpetionHandler + Continuation Interceptor
launch(Dispatchers.IO + CoroutineName("SampleCoroutine") + CoroutineExceptionHandler()){}

‘+’ 연산자를 이용해 Element 들 (CoroutineContext) 를 병합해 CombinedContext를 만들어 낸다.

즉, CoroutineContext는 코루틴의 실행환경에 대한 정보라고 생각하면 쉽다!

CoroutineScope이란?

public interface CoroutineScope {
    public val coroutineContext: CoroutineContext
}

CoroutineScope은 단순히 CoroutineContext를 갖고 있을 뿐이다.

public fun CoroutineScope.launch(
    context: CoroutineContext = EmptyCoroutineContext,
    start: CoroutineStart = CoroutineStart.DEFAULT,
    block: suspend CoroutineScope.() -> Unit
): Job {
    val newContext = newCoroutineContext(context)
    val coroutine = if (start.isLazy)
        LazyStandaloneCoroutine(newContext, block) else
        StandaloneCoroutine(newContext, active = true)
    coroutine.start(start, coroutine, block)
    return coroutine
}

우리가 위에서 살펴본 launch 와 같은 코루틴 빌더들은 CoroutineScope의 확장함수이며, launch 블록으로 생성된 코루틴들은 CoroutineScope의 CoroutineContext 환경을 그대로 상속한다.

@ExperimentalCoroutinesApi
public actual fun CoroutineScope.newCoroutineContext(context: CoroutineContext): CoroutineContext {
    val combined = coroutineContext.foldCopiesForChildCoroutine() + context
    val debug = if (DEBUG) combined + CoroutineId(COROUTINE_ID.incrementAndGet()) else combined
    return if (combined !== Dispatchers.Default && combined[ContinuationInterceptor] == null)
        debug + Dispatchers.Default else debug
}

combined를 자세히 보면 현재 CoroutineScope의 coroutineContext와 새로 입력받은 context를 병합한 모습. default 로 EmptyCoroutineContext가 지정되어있는데 이건 뭘까?

public object EmptyCoroutineContext : CoroutineContext, Serializable {
    private const val serialVersionUID: Long = 0
    private fun readResolve(): Any = EmptyCoroutineContext

    public override fun <E : Element> get(key: Key<E>): E? = null
    public override fun <R> fold(initial: R, operation: (R, Element) -> R): R = initial
    public override fun plus(context: CoroutineContext): CoroutineContext = context
    public override fun minusKey(key: Key<*>): CoroutineContext = this
    public override fun hashCode(): Int = 0
    public override fun toString(): String = "EmptyCoroutineContext"
}

위의 코드를 보면 newCoroutineContext에서 ‘+’ 연산자로 coroutineContext.foldCopiesForChildCoroutine() + context를 해봐도 EmptyCoroutineContext는 무시됨을 알 수 있다.

object GlobalScope : CoroutineScope {
    override val coroutineContext: CoroutineContext
        get() = EmptyCoroutineContext
}

우리가 사용한 GlobalScope은 Singleton object로 coroutineContext로 EmptyCoroutineContext를 가지고 있다.

왜 Coroutine을 경량화된 Thread라고 할까?

Coroutine은 Thread가 아니다

코루틴이 하나 생성된다고 해서 Thread가 하나 생성되는 것이 아니다. Coroutine은 스케쥴링 가능한 코드 블록 혹은 코드 블록의 집합이다.

launch { } 와 같이 코루틴 빌더를 실행했을 경우 넘긴 코드 블록은 Continuation이라는 단위로 만들어진다. 여기서 말하는 Continuation은 CPS(Continuation Passing Style)에서 이야기하는 Continuation 개념의 구현체이다.

어떤 일을 수행하기 위한 일련의 함수들의 연결을 각 함수의 반환값을 이용하지 않고 Continuation 이라는 추가 파라미터(Callback)를 두어 연결하는 방식으로 Continuation 단위로 dispatcher 를 변경한다거나 실행을 유예한다거나 하는 플로우 컨트롤이 용이해지는 이점이 있다.

Continuation 단위로 변경이 된 코드는 처음, suspended 상태로 대기하고 있다가 resume() 요청으로 resumed 상태로 전환되어 실행되고 추가적인 중단 함수를 만나면 suspended 상태로 전환되었다가 하는 등 suspended, resumed 상태를 번갈아가며 코드가 진행된다.

이 때 resume() 요청을 할 때마다 dispatcher에게 dispatch(스레드 전환)이 필요한지 묻는 isDispatchNeeded() 함수를 통해 확인 후 필요한 경우 적합한 스레드로 전달되어 실행된다.

즉, 스레드 전환이 필요하지 않으면 전환하지 않는다!!

fun main(args: Array<String>) = runBlocking {
    repeat(100_000) {
        launch(Dispatchers.IO) {
            delay(1000L)
            print(".")
        }
    }
}

위에서 본 이 코드에서 OOM이 발생하지 않는 이유이다! launch 빌더에서 Dispatcher를 재정의 하지 않았기 때문에 runBlocking의 dispatcher를 함께 사용한다. runBlocking 빌더는 내부적으로 GlobalScope을 사용하며 Dispatcher 는 BlockingEventLoop 을 사용해 이벤트 루프 기반으로 10만번의 이벤트를 발생하여 점을 출력하게 되며 스레드 부하는 없으므로 OOM을 피할 수 있게 된다.

[스프링] SpringBoot이 ObjectMapper를 구성하는 방법

MASHUP — Wed, 16 Oct 2024 00:15:56 +0900

Spring 프로젝트에서는 객체를 Serialize 및 Deserialize 하는 동작들이 프레임워크 내부 동작에서 많이 활용되어지고 있습니다. Spring 을 어느정도 활용해 본 사람이라면 알고 있을 ObjectMapper 를 사용해 객체의 Serialization및 Deserialization을 수행하고 있는데요. 여러 곳에서 사용하다보니 임의로 ObjectMapper 및 ObjectMapperBuilder 를 재정의 하는 경우를 종종 볼 수 있습니다. 이러한 방식으로 이 객체들을 재정의 해도 문제가 없을지, 문제가 있다면 어떠한 문제가 있을 수 있을지 구현 코드를 보고 해당 객체들이 어떤 방식으로 구성되는지 알아보겠습니다.

아래에 작성하는 코드는 ObjectMapperLearning 에서 확인 가능합니다.

ObjectMapper 주입 관계 도식화

우리가 Spring Framework 내에서 사용하는 ObjectMapper 는 여러 설정 객체의 정보들을 내려받아 최종적으로 Jackson2ObjectMapperBuilder의 build() 함수에 의해 생성됩니다. 각 설정 객체의 구현 코드를 확인해보기 전에 아래의 도식화를 보시면 이해에 도움이 될 것입니다.

ObjectMapper의 구성 정보를 담은 Builder 객체

먼저 ObjectMapper가 어떤 코드에서 주입 되었는지 확인해보면 아래와 같은 코드를 만날 수 있습니다.

@Bean
@Primary
@ConditionalOnMissingBean
ObjectMapper jacksonObjectMapper(Jackson2ObjectMapperBuilder builder) {
  return builder.createXmlMapper(false).build();
}

위의 코드는 JacksonAutoConfiguration.java의 코드이며, JacksonAutoConfiguration의 JacksonObjectMapperConfiguration 이라는 static으로 생성된 Configuration 객체가 ObjectMapper를 @Bean을 통해 주입하고 있습니다. 또한 이 메서드는 Jackson2ObjectMapperBuilder 를 주입 받아 ObjectMapper를 생성하고 있습니다. 그럼 Jackson2ObjectMapperBuilder 는 어디서 생성하고 주입하고 있는 걸까요?

같은 파일 내에서 Jackson2ObjectMapperBuilderConfiguration 객체를 살펴보겠습니다.

@Configuration(proxyBeanMethods = false)
@ConditionalOnClass({Jackson2ObjectMapperBuilder.class})
static class JacksonObjectMapperBuilderConfiguration {
    ...
    @Bean
    @Scope("prototype")
    @ConditionalOnMissingBean
    Jackson2ObjectMapperBuilder jacksonObjectMapperBuilder(
        ApplicationContext applicationContext, 
        List<Jackson2ObjectMapperBuilderCustomizer> customizers
    ) {
        Jackson2ObjectMapperBuilder builder = new Jackson2ObjectMapperBuilder();
        builder.applicationContext(applicationContext);
        this.customize(builder, customizers);
        return builder;
    }
    ...
}

이 코드를 살펴보니 Jackson2ObjectMapperBuilder는 또 Jackson2ObjectMapperBuilderCustomizer List를 주입받아 customize 라는 함수를 호출해주고 있습니다. 우리는 Spring을 학습하면서 같은 타입의 Bean이 여러개 주입될 경우 List 자료구조로 주입 된 Bean을 전부 가져올 수 있다는걸 알고 있습니다. 그럼 여기서 주입받은 customizers는 어디에서 주입되는 것일까요?

또, 같은 파일에서 Jackson2ObjectMapperBuilderCustomizerConfiguration을 살펴보겠습니다.

@Configuration(
    proxyBeanMethods = false
)
@ConditionalOnClass({Jackson2ObjectMapperBuilder.class})
@EnableConfigurationProperties({JacksonProperties.class})
static class Jackson2ObjectMapperBuilderCustomizerConfiguration {
        ...
        @Bean
        StandardJackson2ObjectMapperBuilderCustomizer standardJacksonObjectMapperBuilderCustomizer(
            JacksonProperties jacksonProperties, 
            ObjectProvider<Module> modules
        ) {
            return new StandardJackson2ObjectMapperBuilderCustomizer(jacksonProperties, modules.stream().toList());
        }
        ...
}

StandardJackson2ObjectMapperBuilderCustomizer를 주입하는 것을 볼 수 있는데 이 Customizer는 yml 파일 등에서 주입된 설정정보를 입력받아 JacksonProperties 라는 객체에 정보를 담아 StandardJackson2ObjectMapperBuilderCustomizer에게 전달하고 있습니다.

@ConfigurationProperties(
    prefix = "spring.jackson"
)
public class JacksonProperties { ... }

JacksonProperties는 prefix로 spring.jackson을 사용하고 dateFormat, timeZone, naming-strategy 등 과 같은 부분을 설정할 수 있습니다. 사용자는 application.yml 등과 같은 설정 파일에서 Jackson 관련 설정을 추가할 수 있습니다.

더불어 StandardJackson2ObjectMapperBuilderCustomizer는 Module의 형식으로 의존 주입된 객체들을 찾아 ObjectMapper를 구성하기 위한 설정 정보로 사용합니다. 그리고 Module Bean 주입으로 ObjectMapper를 커스텀하는 방법은 Spring이 권장하는 방법 중 하나입니다. 그렇다면 이 Module이란 무엇일까요?

Module을 이용한 커스터마이징 및 확장

Jackson 라이브러리에서 Module의 역할은 커스터마이징과 기능 확장을 위한 플러그인의 역할을 합니다. Jackson이 ObjectMapper를 구성하는 방법에 대해서 이해하기 위해서 설정을 구성하는 주된 요소인 Module에 대해 이해해야 합니다. 이를 위해 Module의 구현 코드를 먼저 살펴보겠습니다.

public abstract class Module implements Versioned {
    public Module() {
    }

    public abstract String getModuleName();

    public abstract Version version();

    public Object getTypeId() {
        return this.getClass().getName();
    }

    public abstract void setupModule(SetupContext var1);

    public Iterable<? extends Module> getDependencies() {
        return Collections.emptyList();
    }

    public interface SetupContext {
        Version getMapperVersion();
        <C extends ObjectCodec> C getOwner();
        TypeFactory getTypeFactory()

        ...

        boolean isEnabled(MapperFeature var1);
        void addDeserializers(Deserializers var1);
        void addSerializers(Serializers var1);
        void insertAnnotationIntrospector(AnnotationIntrospector var1);
        void appendAnnotationIntrospector(AnnotationIntrospector var1);
        void setMixInAnnotations(Class<?> var1, Class<?> var2);
        ...
    }
}

위 코드는 Module.java 파일에 있는 코드입니다. Module은 단순히 Version을 통해 모듈 버저닝 및 의존성을 위한 기능만 제공할 뿐 부가적인 기능들은 SetupContext를 통해 이뤄진다는 것을 알 수 있습니다. 그럼 SetupContext에 해당하는 부분은 어디에서 구현이 될까요? 바로 ObjectMapper에서 수행하게 됩니다. 이를 확인하기 위해 위에서 참고한 StandardJackson2ObjectMapperBuilderCustomizer를 customize 하는 코드를 확인해보겠습니다.

static final class StandardJackson2ObjectMapperBuilderCustomizer
                implements Jackson2ObjectMapperBuilderCustomizer, Ordered {

            private final JacksonProperties jacksonProperties;

            private final Collection<Module> modules;

            StandardJackson2ObjectMapperBuilderCustomizer(
                JacksonProperties jacksonProperties,
                Collection<Module> modules
            ) {
                this.jacksonProperties = jacksonProperties;
                this.modules = modules;
            }
            ...
            @Override
            public void customize(Jackson2ObjectMapperBuilder builder) {
                if (this.jacksonProperties.getDefaultPropertyInclusion() != null) {
                    builder.serializationInclusion(this.jacksonProperties.getDefaultPropertyInclusion());
                }
                if (this.jacksonProperties.getTimeZone() != null) {
                    builder.timeZone(this.jacksonProperties.getTimeZone());
                }
                configureFeatures(builder, FEATURE_DEFAULTS);
                configureVisibility(builder, this.jacksonProperties.getVisibility());
                configureFeatures(builder, this.jacksonProperties.getDeserialization());
                configureFeatures(builder, this.jacksonProperties.getSerialization());
                configureFeatures(builder, this.jacksonProperties.getMapper());
                configureFeatures(builder, this.jacksonProperties.getParser());
                configureFeatures(builder, this.jacksonProperties.getGenerator());
                configureFeatures(builder, this.jacksonProperties.getDatatype().getEnum());
                configureFeatures(builder, this.jacksonProperties.getDatatype().getJsonNode());
                configureDateFormat(builder);
                configurePropertyNamingStrategy(builder);
                configureModules(builder); // configModules 호출
                configureLocale(builder);
                configureDefaultLeniency(builder);
                configureConstructorDetector(builder);
            }
            ...
}

위의 코드는 JacksonAutoConfigration.java 파일 내에서 StandardJackson2ObjectMapperBuilderCustomizer가 customize 하는 로직을 나타낸 것입니다. customize 함수 내에서 builder를 인자로 받아 configureModules를 호출하고 있습니다.

private void configureModules(Jackson2ObjectMapperBuilder builder) {
        builder.modulesToInstall(this.modules.toArray(new Module[0]));
}

configureModules를 통해 builder에 Bean을 통해 주입된 모든 Module을 Install 하는 역할을 수행합니다. 이렇게 Install 받은 Module들은 어떻게 ObjectMapper에 전달이 될까요? 이를 이해하기 위해서는 ObjectMapperBuilder가 ObjectMapper를 build하는 과정을 살펴봐야 합니다.

public <T extends ObjectMapper> T build() {
    ObjectMapper mapper;
    if (this.createXmlMapper) {
        mapper = (this.defaultUseWrapper != null ?
                new XmlObjectMapperInitializer().create(this.defaultUseWrapper, this.factory) :
                new XmlObjectMapperInitializer().create(this.factory));
    }
    else {
        mapper = (this.factory != null ? new ObjectMapper(this.factory) : new ObjectMapper());
    }
    configure(mapper);
    return (T) mapper;
}

위의 코드는 JacksonObjectMapperBuilder가 build() 를 통해 ObjectMapper를 생성하는 코드입니다. ObjectMapper를 생성한 후 configure() 를 호출합니다.

public void configure(ObjectMapper objectMapper) {
    ...

    MultiValueMap<Object, Module> modulesToRegister = new LinkedMultiValueMap<>();
    if (this.findModulesViaServiceLoader) {
        ObjectMapper.findModules(this.moduleClassLoader).forEach(module -> registerModule(module, modulesToRegister));
    }
    else if (this.findWellKnownModules) {
        registerWellKnownModulesIfAvailable(modulesToRegister);
    }

    if (this.modules != null) {
        this.modules.forEach(module -> registerModule(module, modulesToRegister));
    }
    if (this.moduleClasses != null) {
        for (Class<? extends Module> moduleClass : this.moduleClasses) {
            registerModule(BeanUtils.instantiateClass(moduleClass), modulesToRegister);
        }
    }
    List<Module> modules = new ArrayList<>();
    for (List<Module> nestedModules : modulesToRegister.values()) {
        modules.addAll(nestedModules);
    }
    objectMapper.registerModules(modules);
    ...
}

configure() 함수 내에서 modules를 탐색 후 objectMapper.registerModules()를 실행합니다.

public ObjectMapper registerModule(Module module)
{
    //     ... (중략) ...
    // And then call registration
    module.setupModule(new Module.SetupContext()
    {
      ...
        @SuppressWarnings("unchecked")
        @Override
        public <C extends ObjectCodec> C getOwner() {
            // why do we need the cast here?!?
            return (C) ObjectMapper.this;
        }

        @Override
        public TypeFactory getTypeFactory() {
            return _typeFactory;
        }

        @Override
        public boolean isEnabled(MapperFeature f) {
            return ObjectMapper.this.isEnabled(f);
        }

        // ... (중략) ...

        // // // Methods for registering handlers: deserializers

        @Override
        public void addDeserializers(Deserializers d) {
            DeserializerFactory df = _deserializationContext._factory.withAdditionalDeserializers(d);
            _deserializationContext = _deserializationContext.with(df);
        }

        @Override
        public void addSerializers(Serializers s) {
            _serializerFactory = _serializerFactory.withAdditionalSerializers(s);
        }

        @Override
        public void insertAnnotationIntrospector(AnnotationIntrospector ai) {
            _deserializationConfig = _deserializationConfig.withInsertedAnnotationIntrospector(ai);
            _serializationConfig = _serializationConfig.withInsertedAnnotationIntrospector(ai);
        }

        @Override
        public void appendAnnotationIntrospector(AnnotationIntrospector ai) {
            _deserializationConfig = _deserializationConfig.withAppendedAnnotationIntrospector(ai);
            _serializationConfig = _serializationConfig.withAppendedAnnotationIntrospector(ai);
        }

        @Override
        public void setMixInAnnotations(Class<?> target, Class<?> mixinSource) {
            addMixIn(target, mixinSource);
        }
        ...
    });

    return this;
}

objectMapper는 registerModules() 함수 내에서 module를 순차적으로 돌며 module의 setupModule를 실행합니다.

즉, setupModule() 이라는 메서드는 Module과 ObjectMapper를 연결해주는 브릿지 역할을 수행합니다. 우리는 이 메서드 안에서 우리가 필요한 동작들(Serializer 등록, Deserializer 등록 등)을 수행할 수 있습니다. SetupContext의 역할을 조금 살펴보자면 다음 4가지 정도의 역할을 꼽아볼 수 있습니다.

addSerializers(): Module에서 제공하는 Serializer를 추가하는 작업을 수행합니다.
addDeserializers(): Module에서 제공하는 Deserializer를 추가하는 작업을 수행합니다.
insertAnnotationIntrospector(), appendAnnotationIntrospector(): 어노테이션 기반 커스터마이징 된 Serialization, Deserialization을 수행하는 AnnotationIntrospector를 추가합니다.
setMixInAnnotations(): 원본 클래스를 대체한 믹스인을 만들어 원본 클래스에 적용할 Jackson 어노테이션을 추가합니다.

이런식으로 Spring은 Jackson의 기본 제공 클래스(ObjectMapper, ObjectMapperBuilder 등)을 건들지 않고 Module을 추가하는 방식으로 대부분의 Jackson 설정 정보를 커스터마이징 할 수 있습니다. 이는 Spring에서 제공하는 기본 동작을 방해하지 않고 독립적인 환경에서 커스터마이징함으로써 캡슐화의 이점을 갖을 수 있습니다.

그렇다면 StandardJackson2ObjectMapperBuilderCustomizer를 주입받을 때 AutoConfiguration에 의해 자동 주입된 Module 들은 어떤 것이 있을까요?

Spring Boot이 기본으로 제공하는 Jackson Module

JsonComponentModule

JsonComponentModule은 JacksonAutoConfiguration에서 자동 설정을 통해 주입되고 있으며 @JsonComponent 어노테이션을 통해 등록된 Bean 객체를 주입받아 JsonComponentModule의 Serializer 및 Deserializer로 등록합니다.

@AutoConfiguration
@ConditionalOnClass({ObjectMapper.class})
public class JacksonAutoConfiguration {
    ...
    @Bean
    public JsonComponentModule jsonComponentModule() {
        return new JsonComponentModule();
    }
    ...
}

위의 코드는 JacksonAutoConfiguration.java 파일 내에서 JsonComponentModule 객체를 Bean 등록하는 코드입니다.

JsonComponentModule은 코드에서 살펴보시다시피 JacksonAutoConfiguration에서 자동 설정을 통해 주입되고 있으며 @JsonComponent 어노테이션을 통해 등록된 Configuration 객체를 주입받아 JsonComponentModule의 Serializer 및 Deserializer를 등록합니다. Bean 객체의 주입 대상은 @JsonComponent 어노테이션의 대상이 된 객체 뿐 아니라 해당 클래스 내에 존재하는 inner class 또한 등록 대상이 됩니다.

ParameterNamesModule

@Configuration(proxyBeanMethods = false)
@ConditionalOnClass(ParameterNamesModule.class)
static class ParameterNamesModuleConfiguration {

        @Bean
        @ConditionalOnMissingBean
        ParameterNamesModule parameterNamesModule() {
            return new ParameterNamesModule(JsonCreator.Mode.DEFAULT);
        }

}

ParameterNamesModule 또한 JacksonAutoConfiguration.java에서 Bean 등록을 수행합니다. ParameterNamesModule은 기본적인 Serializer, Deserializer를 추가하지 않고 클래스의 메서드 및 생성자의 파라미터 이름을 사용하여 Serialization, Deserialization을 지원합니다. 여기서 사용한 JsonCreator.Mode.DEFAULT는 기본 모드로, 주 생성자가 아닌 생성자에 대해서도 파라미터 이름을 사용하여 Deserialization을 지원합니다.

JsonMixinModule

@Configuration(proxyBeanMethods = false)
static class JacksonMixinConfiguration {

        @Bean
        static JsonMixinModuleEntries jsonMixinModuleEntries(ApplicationContext context) {
            List<String> packages = AutoConfigurationPackages.has(context) ? AutoConfigurationPackages.get(context)
                    : Collections.emptyList();
            return JsonMixinModuleEntries.scan(context, packages);
        }

        @Bean
        JsonMixinModule jsonMixinModule(ApplicationContext context, JsonMixinModuleEntries entries) {
            JsonMixinModule jsonMixinModule = new JsonMixinModule();
            jsonMixinModule.registerEntries(entries, context.getClassLoader());
            return jsonMixinModule;
        }

}

JsonMixinModule 또한 동일하게 JacksonAutoConfiguration에 의해 자동 설정 시 Bean 등록을 수행합니다. JsonMixinModule은 기본적으로 ApplicationContext 내에서 지정된 패키지를 스캔하여 @JsonMixin 이라는 어노테이션이 지정된 믹스인 클래스를 찾아 JsonMixinModule에 등록합니다.

이처럼 Spring Boot에서는 properties 파일 및 기본적으로 제공하는 Module 들에 의해 ObjectMapper가 생성됩니다. 그래서 ObjectMapper를 임의로 재정의할 때에는 이러한 기본 동작이 제대로 이뤄지지 않을 수 있음을 알고 Jackson 설정을 커스터마이징 해야 합니다. 그럼 이러한 기본 동작을 방해하지 않는 선에서 JacksonObjectMapperBuilder 및 Serializer, Deserializer를 커스터마이징 하는 방법에 대해 알아보겠습니다.

Jackson2ObjectMapperBuilder 직접 커스터마이징

@Configuration(proxyBeanMethods = false)
@ConditionalOnClass({Jackson2ObjectMapperBuilder.class})
static class JacksonObjectMapperBuilderConfiguration {
    ...
    @Bean
    @Scope("prototype")
    @ConditionalOnMissingBean
    Jackson2ObjectMapperBuilder jacksonObjectMapperBuilder(
        ApplicationContext applicationContext, 
        List<Jackson2ObjectMapperBuilderCustomizer> customizers
    ) {
        Jackson2ObjectMapperBuilder builder = new Jackson2ObjectMapperBuilder();
        builder.applicationContext(applicationContext);
        this.customize(builder, customizers);
        return builder;
    }
    ...
}

Jackson2ObjectMapperBuilder는 다음과 같이 주입된 customizers를 customize 하는 동작을 내포하고 있습니다. Jackson2ObjectMapperBuilder를 기본적인 동작을 해치지 않고 재정의 하기 위해서는 위의 코드와 동일하게 기본적으로 제공하는 customizers를 customize() 하는 작업이 필요합니다. 예시 코드는 다음과 같습니다.

@Configuration
class JacksonConfig {

    @Bean
    fun jackson2ObjectMapperBuilder(customizers: List<Jackson2ObjectMapperBuilderCustomizer>): Jackson2ObjectMapperBuilder {
        val builder = Jackson2ObjectMapperBuilder()
            .featuresToDisable(SerializationFeature.WRITE_DATES_AS_TIMESTAMPS)
            .featuresToDisable(DeserializationFeature.FAIL_ON_UNKNOWN_PROPERTIES)
            .serializerByType(LocalDateTime::class.java, LocalDateTimeSerializer(DateTimeFormatter.ISO_LOCAL_DATE_TIME))
            .serializerByType(LocalDate::class.java, LocalDateSerializer(DateTimeFormatter.ISO_LOCAL_DATE))
            .serializerByType(LocalTime::class.java, LocalTimeSerializer(DateTimeFormatter.ISO_LOCAL_TIME))
        customizers.forEach { customizer -> customizer.customize(builder) }
        return builder
    }
}

위의 코드는 Jackson2ObjectMapperBuilder의 필요 없는 기본 설정을 비활성화 하고 특정 타입에 대한 Serializer를 추가하는 코드입니다.

featuresToDisable(SerializationFeature.WRITE_DATES_AS_TIMESTAMPS) : Jackson은 기본적으로 날짜 정보를 Timestamp로 표시합니다. 이를 비활성화 합니다.
featuresToDisable(DeserializationFeature.FAIL_ON_UNKNOWN_PROPERTIES) : JSON에 매핑되지 않은 알 수 없는 속성이 존재해도 오류를 발생시키지 않도록 설정합니다.
serializerByType(): 날짜 및 시간 타입의 객체를 com.fasterxml.jackson.datatype.jsr310.ser 에서 제공하는 Serializer들로 대체합니다.
customizer.customize(builder) : Customizer를 순회하면서 Customizer의 설정 정보들을 내려받습니다. StandardJackson2ObjectMapperBuilderCustomizer 가 그 중 하나이며 해당 Customizer가 포함하는 JacksonProperties 및 기본 제공 Module의 설정 정보를 주입합니다.

Jackson2ObjectMapperBuilderCustomizer 주입

사실 위와 같이 설정하는건 Jackson2ObjectMapperBuilder에 Customizer를 어떻게 주입 시켜야 하는지 알고 있어야 채택할 수 있는 방법이죠. 더불어 위의 로직은 Jackson2ObjectMapperBuilder를 자동으로 주입하는 로직에 포함된 로직이니 중복이라 할 수 있습니다. Spring Framework는 이를 위해 Jackson2ObjectMapperBuilderCustomizer를 주입하는 방식으로 Jackson2ObjectMapperBuilder를 커스터마이징 할 수 있는 방법을 제공합니다.

Customizer들을 customize 하는 로직을 중복으로 작성하지 않아도 되니 위의 방식보다 더 우아한 방식이라고 생각합니다.

class SimpleObjectMapperBuilderCustomizer : Jackson2ObjectMapperBuilderCustomizer {
    override fun customize(jacksonObjectMapperBuilder: Jackson2ObjectMapperBuilder) {
        jacksonObjectMapperBuilder.featuresToDisable(SerializationFeature.WRITE_DATES_AS_TIMESTAMPS)
            .featuresToDisable(DeserializationFeature.FAIL_ON_UNKNOWN_PROPERTIES)
            .serializerByType(LocalDateTime::class.java, LocalDateTimeSerializer(DateTimeFormatter.ISO_LOCAL_DATE_TIME))
            .serializerByType(LocalDate::class.java, LocalDateSerializer(DateTimeFormatter.ISO_LOCAL_DATE))
            .serializerByType(LocalTime::class.java, LocalTimeSerializer(DateTimeFormatter.ISO_LOCAL_TIME))
    }
}

@TestConfiguration
class ObjectMapperBuilderCustomizerConfiguration {

    @Bean
    fun objectMapperBuilderCustomizer(): SimpleObjectMapperBuilderCustomizer {
        return SimpleObjectMapperBuilderCustomizer()
    }
      ...
}

Serializer, Deserializer를 커스터마이징 하는 방법

기본으로 제공하는 Module 사용

Serializer 및 Deserializer를 추가하는 방법은 매우 다양합니다. 기본 제공 Module인 JsonComponentModule, JsonMixinModule을 사용해서 Json 관련 어노테이션을 사용해서 Serializer 및 Deserializer를 추가할 수 있습니다. 하지만 본문에서는 Module을 통한 커스터마이징 방법에 대해 기술하겠습니다.

Module 구현 및 빈 주입

가장 간단한 방법은 SimpleModule이라고 하는 간편화된 Module 객체를 상속하는 방법입니다.

아래의 예제는 기본적인 User 데이터 클래스의 Serializer, Deserializer를 추가하는 예제입니다.

data class User(
    val id: Int,
    val name: String,
    val password: String
)

이제 User에 대한 Serializer를 구현합니다.

import com.fasterxml.jackson.core.JsonGenerator
import com.fasterxml.jackson.databind.JsonSerializer
import com.fasterxml.jackson.databind.SerializerProvider

class UserSerializer : JsonSerializer<User>() {
    override fun serialize(user: User, gen: JsonGenerator, serializers: SerializerProvider) {
        gen.writeStartObject()
        gen.writeNumberField("user_id", user.id)
        gen.writeStringField("name", user.name)
        // Password 필드는 직렬화하지 않음
        gen.writeEndObject()
    }
}

다음 User에 대한 Deserializer를 구현합니다.

import com.fasterxml.jackson.core.JsonParser
import com.fasterxml.jackson.databind.DeserializationContext
import com.fasterxml.jackson.databind.JsonDeserializer

class UserDeserializer : JsonDeserializer<User>() {
    override fun deserialize(p: JsonParser, ctxt: DeserializationContext): User {
        val node = p.codec.readTree<com.fasterxml.jackson.databind.node.ObjectNode>(p)
        val id = node.get("user_id").asInt()
        val name = node.get("name").asText()
        // 역직렬화할 때 패스워드 필드는 기본 값으로 설정
        return User(id, name, "")
    }
}

마지막으로 위에서 구현한 UserSerializer, UserDeserializer를 포함하는 Module를 구현합니다.

import com.fasterxml.jackson.databind.module.SimpleModule

class UserModule : SimpleModule() {
    init {
        addSerializer(User::class.java, UserSerializer())
        addDeserializer(User::class.java, UserDeserializer())
    }
}

SimpleModule을 사용하면 구태여 setupModule() 을 오버라이딩 해서 context에 직접 접근해 addSerializer() 및 addDeserializer()를 추가할 필요없이 바로 추가가 가능합니다.

이렇게 만들어진 UserModule을 단순히 Bean 으로 주입해주면 알아서 Module들이 ObjectMapper에 Install 되어 실행될 것입니다.

import com.fasterxml.jackson.databind.ObjectMapper
import org.springframework.context.annotation.Bean
import org.springframework.context.annotation.Configuration

@Configuration
class JacksonConfig {

    @Bean
    fun userModule(): UserModule {
            return UserModule()
    }
}

테스트

위의 설정 방법대로 설정 할 경우 제대로 동작을 하는지 확인 하기 위해 테스트 코드를 작성해보겠습니다.

우리가 중점적으로 테스트 해야할 부분은 다음과 같습니다.

커스터마이징한 Jackson2ObjectMapperBuilder의 설정 정보가 제대로 주입되는가?
yml에 작성한 jackson 설정 정보가 제대로 주입되는가?
UserModule이 제대로 주입되는가?

yml이 제대로 설정 정보에 주입되는지 확인하기 위해 yml 설정을 추가하겠습니다.

spring:
  jackson:
    property-naming-strategy: SNAKE_CASE

ObjectMapperBuilder를 직접 생성한 경우

우선 ObjectMapperBuilder를 직접 생성한 경우에 대한 테스트를 진행해보겠습니다.

@TestConfiguration
class PlainObjectMapperBuilderConfiguration {

    @Bean
    fun objectMapperBuilder(): Jackson2ObjectMapperBuilder {
        return Jackson2ObjectMapperBuilder()
            .featuresToDisable(SerializationFeature.WRITE_DATES_AS_TIMESTAMPS)
            .featuresToDisable(DeserializationFeature.FAIL_ON_UNKNOWN_PROPERTIES)
            .serializerByType(LocalDateTime::class.java, LocalDateTimeSerializer(DateTimeFormatter.ISO_LOCAL_DATE_TIME))
            .serializerByType(LocalDate::class.java, LocalDateSerializer(DateTimeFormatter.ISO_LOCAL_DATE))
            .serializerByType(LocalTime::class.java, LocalTimeSerializer(DateTimeFormatter.ISO_LOCAL_TIME))
    }

    @Bean
    fun userModule(): UserModule {
        return UserModule()
    }
}

@SpringBootTest
@Import(PlainObjectMapperBuilderConfiguration::class)
class PlainObjectMapperTest {

    @Autowired
    private lateinit var objectMapper: ObjectMapper

    @DisplayName("Customized ObjectMapperBuilder 의 주입을 통해 Customized 설정 정보가 제대로 설정된다.")
    @Test
    fun testObjectMapperBuilderCustomizerSettings() {
        assertThat(objectMapper.serializationConfig.isEnabled(SerializationFeature.WRITE_DATES_AS_TIMESTAMPS)).isFalse()
        assertThat(objectMapper.deserializationConfig.isEnabled(DeserializationFeature.FAIL_ON_UNKNOWN_PROPERTIES)).isFalse()

        // Verify LocalDateTime serializer
        val dateTime = LocalDateTime.of(2020, 1, 1, 12, 0)
        val dateTimeJson = objectMapper.writeValueAsString(dateTime)
        assertThat(dateTimeJson).isEqualTo("\"2020-01-01T12:00:00\"")

        // Verify LocalDate serializer
        val date = LocalDate.of(2020, 1, 1)
        val dateJson = objectMapper.writeValueAsString(date)
        assertThat(dateJson).isEqualTo("\"2020-01-01\"")

        // Verify LocalTime serializer
        val time = LocalTime.of(12, 0)
        val timeJson = objectMapper.writeValueAsString(time)
        assertThat(timeJson).isEqualTo("\"12:00:00\"")
    }

    @DisplayName("ObjectMapperBuilder를 직접 생성하면 yml 세팅을 무시한다.")
    @Test
    fun testPlainObjectMapperCreationIgnoresYmlSettings() {
        assertThat(objectMapper.propertyNamingStrategy).isNull()
    }

    @DisplayName("ObjectMapperBuilder를 직접 생성하면 직접 주입한 Module의 Serializer를 Instsall 할 수 없다.")
    @Test
    fun testPlainObjectMapperBuilderCreationDoesNotInstallInjectedModuleSerializers() {
        val user = User(1, "John Doe", "secret")
        val json = objectMapper.writeValueAsString(user)

        val expectedJson = """{"user_id":1,"name":"John Doe"}"""
        assertThat(expectedJson).isNotEqualTo(json)
    }

    @DisplayName("ObjectMapperBuilder를 직접 생성하면 직접 주입한 Module의 Deserializer를 Instsall 할 수 없다.")
    @Test
    fun testPlainObjectMapperBuilderCreationDoesNotInstallInjectedModuleDeserializers() {
        val json = """{"user_id":1,"name":"John Doe","password":""}"""

        val user: User = objectMapper.readValue(json)

        val expectedUser = User(1, "John Doe", "")
        assertThat(expectedUser).isNotEqualTo(user)
        assertThat(expectedUser.id).isNotEqualTo(user.id)
    }
}

테스트의 결과는 다음과 같습니다.

Customizing 한 Jackson2ObjectMapperBuilder의 설정 정보가 제대로 주입되는가? -> Yes

yml에 작성한 jackson 설정 정보가 제대로 주입되는가? -> No

User Module이 제대로 주입되는가? -> No

위와 같이 설정을 하면 Jackson2ObjectMapperBuilder를 직접 생성해 작성한 설정 정보는 제대로 주입되지만 JacksonAutoConfiguration이 제공해주는 기본 yml 세팅 및 주입된 Module Install 작업이 생략된 것을 확인할 수 있습니다.

ObjectMapperBuilder와 주입된 customizers를 직접 세팅한 경우

@TestConfiguration
class CustomizedObjectMapperBuilderConfiguration {

    @Bean
    fun objectMapperBuilder(customizers: List<Jackson2ObjectMapperBuilderCustomizer>): Jackson2ObjectMapperBuilder {
        val builder = Jackson2ObjectMapperBuilder()
            .featuresToDisable(SerializationFeature.WRITE_DATES_AS_TIMESTAMPS)
            .featuresToDisable(DeserializationFeature.FAIL_ON_UNKNOWN_PROPERTIES)
            .serializerByType(LocalDateTime::class.java, LocalDateTimeSerializer(DateTimeFormatter.ISO_LOCAL_DATE_TIME))
            .serializerByType(LocalDate::class.java, LocalDateSerializer(DateTimeFormatter.ISO_LOCAL_DATE))
            .serializerByType(LocalTime::class.java, LocalTimeSerializer(DateTimeFormatter.ISO_LOCAL_TIME))
        customizers.forEach { customizer -> customizer.customize(builder) }
        return builder
    }

    @Bean
    fun userModule(): UserModule {
        return UserModule()
    }
}

@Import(CustomizedObjectMapperBuilderConfiguration::class)
@SpringBootTest
class CustomizedObjectMapperBuilderTest {

    @Autowired
    private lateinit var objectMapper: ObjectMapper

    @DisplayName("Customized ObjectMapperBuilder 의 주입을 통해 Customized 설정 정보가 제대로 설정된다.")
    @Test
    fun testObjectMapperBuilderCustomizerSettings() {
        assertThat(objectMapper.serializationConfig.isEnabled(SerializationFeature.WRITE_DATES_AS_TIMESTAMPS)).isFalse()
        assertThat(objectMapper.deserializationConfig.isEnabled(DeserializationFeature.FAIL_ON_UNKNOWN_PROPERTIES)).isFalse()

        // Verify LocalDateTime serializer
        val dateTime = LocalDateTime.of(2020, 1, 1, 12, 0)
        val dateTimeJson = objectMapper.writeValueAsString(dateTime)
        assertThat(dateTimeJson).isEqualTo("\"2020-01-01T12:00:00\"")

        // Verify LocalDate serializer
        val date = LocalDate.of(2020, 1, 1)
        val dateJson = objectMapper.writeValueAsString(date)
        assertThat(dateJson).isEqualTo("\"2020-01-01\"")

        // Verify LocalTime serializer
        val time = LocalTime.of(12, 0)
        val timeJson = objectMapper.writeValueAsString(time)
        assertThat(timeJson).isEqualTo("\"12:00:00\"")
    }

    @DisplayName("customizers를 customize 하면 yml의 세팅값을 그대로 적용할 수 있다.")
    @Test
    fun testYmlSettingsAppliedWithCustomizedCustomizers() {
        assertThat(objectMapper.propertyNamingStrategy).isEqualTo(PropertyNamingStrategies.SNAKE_CASE)
    }

    @DisplayName("customizers를 customize 하면 Bean으로 등록된 Module의 Serializer가 자동으로 Install 된다.")
    @Test
    fun testBeanRegisteredModuleSerializersAutoInstallWithCustomizedCustomizers() {
        val user = User(1, "John Doe", "secret")
        val json = objectMapper.writeValueAsString(user)

        val expectedJson = """{"user_id":1,"name":"John Doe"}"""
        assertThat(expectedJson).isEqualTo(json)
    }

    @DisplayName("customizers를 customize 하면 Bean으로 등록된 Module의 Deserializer가 자동으로 Install 된다.")
    @Test
    fun testBeanRegisteredModuleDeserializersAutoInstallWithCustomizedCustomizers() {
        val json = """{"user_id":1,"name":"John Doe"}"""
        val user: User = objectMapper.readValue(json)

        val expectedUser = User(1, "John Doe", "")
        assertThat(expectedUser).isEqualTo(user)
    }
}

테스트의 결과는 다음과 같습니다.

Customizing 한 Jackson2ObjectMapperBuilder의 설정 정보가 제대로 주입되는가? -> Yes
yml에 작성한 jackson 설정 정보가 제대로 주입되는가? -> Yes
User Module이 제대로 주입되는가? -> Yes

위와 같이 작성한 경우 바라던 대로 제대로 설정이 이루어지는 것을 확인할 수 있습니다. 다만, ObjectMapperBuilder를 주입하는 코드에서 customizers를 주입받아 customize() 과정을 거쳐야 한다는 단점이 존재합니다. Customizers를 customize() 하는 로직은 사실 ObjectMapperBuilder를 커스터마이징 할 때 알기에는 과한 관심사로 보입니다.

ObjectMapperBuilderCustomizer를 주입하는 경우

ObjectMapperBuilder를 커스터마이징 할 때 가장 깔끔한 방법은 Jackson2ObjectMapperBuilderCustomizer를 직접 구현해 ObJectMapperBuilder 커스터마이징만 하는 것입니다.

class SimpleObjectMapperBuilderCustomizer : Jackson2ObjectMapperBuilderCustomizer {
    override fun customize(jacksonObjectMapperBuilder: Jackson2ObjectMapperBuilder) {
        jacksonObjectMapperBuilder.featuresToDisable(SerializationFeature.WRITE_DATES_AS_TIMESTAMPS)
            .featuresToDisable(DeserializationFeature.FAIL_ON_UNKNOWN_PROPERTIES)
            .serializerByType(LocalDateTime::class.java, LocalDateTimeSerializer(DateTimeFormatter.ISO_LOCAL_DATE_TIME))
            .serializerByType(LocalDate::class.java, LocalDateSerializer(DateTimeFormatter.ISO_LOCAL_DATE))
            .serializerByType(LocalTime::class.java, LocalTimeSerializer(DateTimeFormatter.ISO_LOCAL_TIME))
    }
}

@TestConfiguration
class ObjectMapperBuilderCustomizerConfiguration {

    @Bean
    fun objectMapperBuilderCustomizer(): SimpleObjectMapperBuilderCustomizer {
        return SimpleObjectMapperBuilderCustomizer()
    }

    @Bean
    fun userModule(): UserModule {
        return UserModule()
    }
}

@Import(ObjectMapperBuilderCustomizerConfiguration::class)
@SpringBootTest
class ObjectMapperBuilderCustomizerTest {
    @Autowired
    private lateinit var objectMapper: ObjectMapper

    @DisplayName("customized ObjectMapperBuilderCustomizer의 주입을 통해 Customized 설정 정보가 제대로 설정된다.")
    @Test
    fun testObjectMapperBuilderCustomizerSettings() {
        assertThat(objectMapper.serializationConfig.isEnabled(SerializationFeature.WRITE_DATES_AS_TIMESTAMPS)).isFalse()
        assertThat(objectMapper.deserializationConfig.isEnabled(DeserializationFeature.FAIL_ON_UNKNOWN_PROPERTIES)).isFalse()

        // Verify LocalDateTime serializer
        val dateTime = LocalDateTime.of(2020, 1, 1, 12, 0)
        val dateTimeJson = objectMapper.writeValueAsString(dateTime)
        assertThat(dateTimeJson).isEqualTo("\"2020-01-01T12:00:00\"")

        // Verify LocalDate serializer
        val date = LocalDate.of(2020, 1, 1)
        val dateJson = objectMapper.writeValueAsString(date)
        assertThat(dateJson).isEqualTo("\"2020-01-01\"")

        // Verify LocalTime serializer
        val time = LocalTime.of(12, 0)
        val timeJson = objectMapper.writeValueAsString(time)
        assertThat(timeJson).isEqualTo("\"12:00:00\"")
    }

    @DisplayName("customized ObjectMapperBuilderCustomizer를 주입하면 yml의 세팅값을 그대로 적용할 수 있다.")
    @Test
    fun testYmlSettingsAppliedWithCustomizedCustomizers() {
        assertThat(objectMapper.propertyNamingStrategy).isEqualTo(PropertyNamingStrategies.SNAKE_CASE)
    }

    @DisplayName("customized ObjectMapperBuilderCustomizer를 주입하면 Bean으로 등록된 Module의 Serializer가 자동으로 Install 된다.")
    @Test
    fun testBeanRegisteredModuleSerializersAutoInstallWithCustomizedCustomizers() {
        val user = User(1, "John Doe", "secret")
        val json = objectMapper.writeValueAsString(user)

        val expectedJson = """{"user_id":1,"name":"John Doe"}"""
        assertThat(expectedJson).isEqualTo(json)
    }

    @DisplayName("customized ObjectMapperBuilderCustomizer를 주입하면 Bean으로 등록된 Module의 Deserializer가 자동으로 Install 된다.")
    @Test
    fun testBeanRegisteredModuleDeserializersAutoInstallWithCustomizedCustomizers() {
        val json = """{"user_id":1,"name":"John Doe"}"""
        val user: User = objectMapper.readValue(json)

        val expectedUser = User(1, "John Doe", "")
        assertThat(expectedUser).isEqualTo(user)
    }
}

테스트의 결과는 다음과 같습니다.

위의 방식으로 작성할 때 비로소 Configuration 하는 로직이 매우 간단해졌으며 불필요한 관심에 대해 자유로워졌습니다.

즉, Jackson2ObjectMapperBuilder를 커스터마이징 할 때는 Jackson2ObjectMapperBuilderCustomizer를 구현한 Bean을 주입하고 새로운 Serializer 및 Deserializer를 추가할 때에는 Module을 구현한 Bean을 주입하면 JacksonAutoConfiguration 에서 제공하는 기본 기능은 물론 커스터마이징 또한 자유롭게 할 수 있을것입니다.

마무리

이렇게 해서 Spring Boot 에서 Jackson이 AutoConfiguration을 통해 ObjectMapper를 어떻게 구성하는지에 대해 알아보았습니다. Spring Boot이 기본적으로 제공하는 Module들의 자세한 구현부는 추후 다른 포스트에서 구술하도록 하겠습니다.

Spring Boot은 이렇게 생성한 ObjectMapper를 REST API 내에서 ResponseBody로 들어온 Json 객체를 Deserialization 하거나 응답 값을 Serialization 하는 등의 역할을 수행하게 됩니다. 추후에 Spring 에서 RequestBody를 ObjectMapper를 통해 Deserialize 하는 방법에 대해 기술하도록 하겠습니다.

감사합니다.

[스프링팀] gRPC

MASHUP — Tue, 15 Oct 2024 21:42:56 +0900

gRPC란 무엇인가요?

gRPC는 Google에서 개발한 원격 프로시저 호출(Remote Procedure Call, RPC) 시스템입니다. 간단히 말해, gRPC는 서버와 클라이언트 간의 통신을 쉽게 할 수 있게 도와주는 프레임워크입니다.

클라이언트가 서버에게 데이터를 요청할 때, 마치 서버 안에 있는 함수나 메서드를 직접 호출하는 것처럼 요청을 보낼 수 있습니다. 실제로는 네트워크를 통해 요청이 전달되지만, gRPC를 사용하면 서버에 메서드를 호출하는 것처럼 프로그래밍할 수 있습니다.

gRPC는 HTTP/2 프로토콜을 기반으로 하여 고성능, 저지연 네트워크 통신을 지원합니다. HTTP/2는 기존의 HTTP/1.1과 비교하여 멀티플렉싱(Multiplexing), 헤더 압축(Header Compression) 등의 최적화 기능을 도입함으로써 대역폭 효율성을 극대화하고 전송 지연(Latency)을 최소화합니다.

gRPC에서 지원하는 통신 방식

Unary RPC
클라이언트가 하나의 요청을 보내고 서버는 하나의 응답을 반환하는 가장 일반적인 형태의 통신 방식입니다.
Server Streaming RPC
클라이언트가 하나의 요청을 보내면 서버는 여러 개의 응답을 스트리밍으로 보냅니다.
Client Streaming RPC
클라이언트가 여러 요청을 스트리밍 방식으로 보내고 서버는 하나의 응답을 반환합니다.
Bidirectional Streaming RPC
클라이언트와 서버가 양방향으로 여러 요청과 응답을 스트리밍 방식으로 주고받을 수 있습니다.

Protocol Buffers(Protobuf)란 무엇인가요?

Protocol Buffers(Protobuf)는 gRPC에서 사용하는 데이터 직렬화 방식으로, 데이터를 작고 빠르게 전송하기 위해 바이너리 형식으로 압축하여 전달합니다. JSON이나 XML처럼 사람이 읽기 쉬운 텍스트 형식과는 달리, Protobuf는 더 작은 파일 크기와 더 빠른 처리 속도를 제공하여 네트워크 효율성을 극대화합니다.

Protobuf가 더 빠른 이유는 데이터를 바이너리 형식으로 직렬화하여 전송량을 줄이고, 파싱 오버헤드를 최소화하며, 작고 효율적인 데이터 구조 덕분에 더 빠른 처리 속도를 제공하기 때문입니다. Protobuf는 텍스트 기반의 JSON이나 XML과 달리 태그나 공백 같은 불필요한 데이터를 포함하지 않으며, 숫자로 정의된 필드 번호를 사용해 데이터를 효율적으로 구분합니다. 또한, 메타데이터 오버헤드를 줄여 데이터가 더 컴팩트해지며, 사전 정의된 데이터 구조로 인해 파싱 과정이 단순화되어 빠른 데이터 접근이 가능합니다.

IDL(Interface Definition Language)이란 무엇인가요?

IDL(인터페이스 정의 언어)은 클라이언트와 서버가 어떤 데이터 구조로 통신할지, 어떤 서비스를 제공할지 미리 정의해주는 언어입니다. gRPC에서는 Protocol Buffers(proto 파일)를 IDL로 사용합니다.

proto 파일에서, 클라이언트와 서버가 통신하는 규칙을 정의하면, 이 파일을 바탕으로 코드를 생성할 수 있습니다. 즉, 서버와 클라이언트가 어떤 형식의 데이터를 주고받을지 사전에 약속을 정해두는 것이라고 이해할 수 있습니다.

Protocol Buffers (proto) 예시

Protocol Buffers 파일(.proto 파일)은 gRPC에서 서비스의 인터페이스와 데이터 구조를 정의하는 파일입니다. 예시로, 아래는 간단한 gRPC 서비스와 데이터 구조를 정의한 .proto 파일입니다.

syntax = "proto3";

service UserService {
  rpc GetUser (UserRequest) returns (UserResponse);
}

message UserRequest {
  int32 user_id = 1;
}

message UserResponse {
  string name = 1;
  string email = 2;
}

service UserService:
- UserService라는 이름의 gRPC 서비스를 정의합니다.
rpc GetUser (UserRequest) returns (UserResponse):
- GetUser라는 Unary RPC 메서드를 정의합니다. 클라이언트가 UserRequest 메시지를 서버에 보내면, 서버는 UserResponse 메시지로 응답을 반환합니다.
message UserRequest:
- 클라이언트가 서버로 보낼 요청 데이터 구조입니다. 여기에는 user_id라는 필드가 포함되어 있습니다.
message UserResponse:
- 서버가 클라이언트에게 보낼 응답 데이터 구조입니다. 여기에는 name과 email이라는 필드가 포함됩니다.

JSON과 gRPC 비교 성능 테스트

성능 테스트

nGrinder 30대 → java-service(JSON / gRPC) c5.large, 12대

JSON

JSON
Vusers	TPS	Time	JAVA CPU
600	29,116.2	19.94 ms	80% 후반
900	30,800.0	28.46 ms	80% 후반

gRPC
Vusers	TPS	Time	JAVA CPU
600	59,373.2	10.07 ms	80% 중반
900	62,308.7	14.40 ms	80% 후반

nGrinder 30대 → php-service( c5.4xlarge, 13대 → java-service(JSON / gRPC) c5.large, 12대

JSON
Vusers	TPS	Time	PHP CPU	JAVA CPU
600	4,761.5	117.22 ms	30% 초반	20% 중반
900	5,928.3	137.21 ms	30% 초반	20% 중반

gRPC
Vusers	TPS	Time	PHP CPU	JAVA CPU
600	14,588.4	40.27 ms	70% 초반	30% 중반
900	15,497.2	56.9 ms	80% 초반	30% 중반

커넥션 재사용 테스트

nGrinder → java-service(gRPC)

gRPC
비율	ActiveConnection 82.94%
	NewConnection 17.06%

nGrinder → php-service → java-service(gRPC)

gRPC
비율	ActiveConnection 78.82%
	NewConnection 21.98%
gRPC(force_new)
비율	ActiveConnection 0.74%
	NewConnection 99.26%
JSON
비율	ActiveConnection 0.31%
	NewConnection 99.69%

테스트 결과

TPS와 CPU 사용률

gRPC는 동일한 CPU 사용률(80%대)에서 JSON 대비 약 2배 이상의 TPS를 처리할 수 있습니다.
예: 600 Vusers 기준으로 gRPC는 59,373 TPS, JSON은 29,116 TPS를 기록했습니다.

응답 시간

gRPC의 응답 시간은 JSON보다 절반 이하로 짧습니다.
예: 600 Vusers 기준으로 gRPC는 10.07ms, JSON은 19.94ms입니다.

커넥션 재사용

gRPC는 활성 커넥션의 82.94%를 재사용하며, 새 연결 생성이 매우 적습니다.
JSON은 커넥션 재사용률이 거의 없고, 요청마다 새 연결을 99.69% 생성합니다.

결론: gRPC는 TPS 처리량과 응답 시간에서 JSON보다 훨씬 우수하며, 커넥션 재사용 측면에서도 더 효율적입니다.

테스트 결과 분석

PHP + JSON 병목 지점

직렬화/역직렬화의 오버헤드

JSON은 텍스트 기반으로, 직렬화 및 역직렬화에 상대적으로 많은 시간이 소요됩니다. 이는 JSON을 처리할 때, 네트워크 오버헤드나 데이터 전송 지연을 발생시키며, TPS를 저하시킬 수 있습니다.

네트워크 대역폭 병목

JSON은 데이터가 커지고, 이를 전송하는 데 더 많은 대역폭이 필요합니다. 특히 트래픽이 증가하면 네트워크 전송 속도가 저하되고 병목 현상이 발생할 수 있습니다.
gRPC와 JSON의 요청당 크기를 비교했을 때, JSON 요청이 약 1278 bytes이고, gRPC 요청이 약 866 bytes로, 약 47% 차이가 있습니다.

커넥션 재생성으로 인한 병목

HTTP/1.1 Keep-Alive가 활성화되어 있어도, 요청이 순차적으로 처리되기 때문에 동시 요청을 처리하지 못합니다. 이로인해 동시 요청이 많은 경우, 대기 중인 요청을 처리하기 위해 커넥션이 자주 생성되며, 커넥션 재사용율이 매우 낮습니다. 실제로 JSON 서버와 통신할 때 커넥션 재사용율이 1% 이하로 나타났습니다.
커넥션을 매번 새로 생성하거나 직렬적으로 처리함에 따라 네트워크 레이턴시가 증가하고, 네트워크 연결 설정과 해제의 반복이 성능 병목을 일으킵니다.

PHP 는 프로세스 기반인데, 커넥션 재사용이 가능할까요?

PHP-FPM과 프로세스 재사용

PHP-FPM은 PHP의 요청 처리 방식을 최적화하기 위해 FastCGI 프로토콜을 사용합니다.
중요한 점은 새로운 요청마다 프로세스를 생성하는 것이 아니라, 기존 프로세스를 재사용한다는 것입니다.
따라서, 동일한 프로세스가 여러 번의 요청을 처리할 수 있습니다.

PHP-FPM can reuse worker processes repeatedly instead of having to create and terminate them for every single PHP request. Although the cost of starting and terminating a new web server process for each request is relatively small, the overall expense quickly increases as the web server begins to handle increasing amounts of traffic. PHP-FPM can serve more traffic than traditional PHP handlers while creating greater resource efficiency.

PHP에서 gRPC 커넥션 재사용

gRPC 채널은 서버와 클라이언트가 연결되는 통신 통로입니다. gRPC는 이러한 채널을 통해 클라이언트가 서버에 요청을 보냅니다.
gRPC는 효율성을 위해 채널을 재사용할 수 있는 메커니즘을 갖추고 있습니다. 새로 생성하는 대신, 기존에 생성된 채널을 재사용하는 방식입니다.

gRPC 커넥션 재사용 방법

Persistent List에 저장된 채널 재사용 (Persistent Channel)

PHP는 gRPC 채널을 처음 생성할 때, 이 채널을 Persistent List에 저장합니다.
다음 요청에서 동일한 채널이 필요하면, 새로 생성하는 대신 Persistent List에 저장된 채널을 재사용합니다. 이렇게 하면 불필요한 자원 낭비를 줄일 수 있습니다.

Channel 객체 생성 및 Persistent List 재사용 로직

PHP에서 gRPC 채널을 사용할 때, 다음 절차에 따라 채널을 재사용할 수 있습니다:

채널이 이미 존재하는지 확인: 요청에서 사용할 채널이 Persistent List에 이미 저장되어 있는지 확인합니다.
채널이 없으면 새로 생성: 채널이 없으면, 새로운 gRPC 채널을 생성하여 Persistent List에 저장합니다.
채널이 있으면 재사용: 이미 같은 조건으로 만들어진 채널이 있으면, 새로운 채널을 만들지 않고 기존 채널을 재사용합니다.

extern HashTable grpc_persistent_list;

if (!(PHP_GRPC_PERSISTENT_LIST_FIND(&grpc_persistent_list, key, key_len, rsrc))) {
    // 채널이 없으면 새로 생성해서 Persistent List에 저장
    create_and_add_channel_to_persistent_list(
        channel, target, args, creds, key, key_len, target_upper_bound TSRMLS_CC);
} else {
    // 채널이 존재하면 이를 재사용
    channel_persistent_le_t *le = (channel_persistent_le_t *)rsrc->ptr;
    if (strcmp(target, le->channel->target) != 0 ||
        strcmp(sha1str, le->channel->args_hashstr) != 0 ||
        (creds != NULL && creds->hashstr != NULL &&
         strcmp(creds->hashstr, le->channel->creds_hashstr) != 0)) {
      // 해시 충돌이 발생하거나 조건이 맞지 않으면 새로 생성
      create_and_add_channel_to_persistent_list(
          channel, target, args, creds, key, key_len, target_upper_bound TSRMLS_CC);
    } else {
      // 기존 채널 재사용
      efree(args.args);
      free_grpc_channel_wrapper(channel->wrapper, false);
      gpr_mu_destroy(&channel->wrapper->mu);
      free(channel->wrapper);
      channel->wrapper = NULL;
      channel->wrapper = le->channel;
      php_grpc_channel_ref(channel->wrapper);
      update_and_get_target_upper_bound(target, target_upper_bound);
    }
}

새로운 채널 생성 조건

채널을 무조건 재사용하지는 않으며, 특정 상황에서는 새로운 채널을 생성해야 합니다:

강제 새로운 채널 생성: force_new 옵션을 사용하면 기존의 채널을 재사용하지 않고 항상 새로운 채널을 생성합니다.
서버 주소나 인증 정보가 변경되는 경우: 요청에서 사용된 서버나 인증 정보가 변경되면, 기존 채널을 사용할 수 없으므로 새로운 채널을 생성해야 합니다.

if (force_new || (creds != NULL && creds->has_call_creds)) {
    // force_new 옵션이 있거나 채널 크리덴셜에 call 크리덴셜이 있는 경우 재사용하지 않고 새로운 채널을 생성
    create_channel(channel, target, args, creds);
} else if (!(PHP_GRPC_PERSISTENT_LIST_FIND(&grpc_persistent_list, key, key_len, rsrc))) {
    // force_new가 없으면 재사용 가능한 채널을 찾고, 없으면 새로 생성
    create_and_add_channel_to_persistent_list(
        channel, target, args, creds, key, key_len, target_upper_bound TSRMLS_CC);
}

FYI; https://github.com/grpc/grpc/blob/df0b1dfed8f3b61ca625b2e4a43b29425ed2236b/src/php/ext/grpc/channel.c#L49

[스프링팀] Druid

MASHUP — Thu, 31 Aug 2023 17:50:08 +0900

Druid 란?

Druid 공식 문서: https://druid.apache.org/docs/latest/design/

대규모 데이터에 대한 빠른 OLAP 쿼리를 위해 설계된 실시간 분석 데이터베이스, interactive한 분석을 가능하게 함
짧은 시간(3초 이내)에 대용량 데이터에 대해 interactive한 분석을 가능하게 함
OLAP란
- 대용량 업무 데이터베이스를 구성하고 BI(Business Intelligence)를 지원하기 위해 사용되는 기술
- 데이터 웨어하우스나 데이터 마트와 같은 대규모 데이터에 대해 최종 사용자가 정보에 직접 접근하여 대화식으로 정보를 분석하고 의사결정에 활용할 수 있는 실시간 분석처리

Druid 사용례

웹 및 모바일 분석을 포함한 클릭스트림 분석
네트워크 성능 모니터링을 포함한 네트워크 원격 측정 분석
서버 메트릭 스토리지
제조 지표를 포함한 공급망 분석
애플리케이션 성능 지표
디지털 마케팅/광고 분석
비즈니스 인텔리전스/OLAP

특징

Columar 로 데이터를 저장(mysql 등 일반 저장소는 row기반)
확장 가능한 분산 시스템. 일반적인 Druid 배포는 수십에서 수백 개의 서버에 클러스터링 하여 배포.
- 초당 수백만개의 레코드 속도로 데이터를 수집하는 동시에 수조 개의 레코드를 유지하고 쿼리 대기 시간을 1초 미만에서 몇 초까지 유지
대규모 병렬 처리
- Druid는 전체 클러스터에서 각 쿼리를 병렬로 처리할 수 있음
실시간 또는 일괄 처리
- Druid는 데이터를 실시간 또는 일괄 처리할 수 있고, 수집된 데이터는 쿼리에 즉시 사용할 수 있음
시간 기반 파티셔닝
- Druid는 먼저 데이터를 시간별로 분할합니다. 선택적으로 다른 필드를 기반으로 추가 파티셔닝을 구현할 수 있습니다. 시간 기반 쿼리는 쿼리의 시간 범위와 일치하는 파티션에만 액세스하므로 성능이 크게 향상됩니다.
approximate 알고리즘
- Druid에는 approximate dinstinct count, approximate rank등의 계산을 위한 알고리즘이 포함되어 있습니다. 이러한 알고리즘은 적은 메모리 사용을 제공하며 정확한 계산보다 훨씬 빠름
- hyperloglog 알고리즘 사용

Druid 구조

Coordinatiors: 클러스터의 데이터 가용성을 관리 (세그먼트 로드, 세그먼트 삭제, 세그먼트 레플리케이션 …)
Overlord: 데이터 수집 워크로드 할당을 제어
Brokers: 외부 클라이언트의 쿼리를 처리
Routers: 선택 사항입니다. broker, coordinator, overload 에게 요청을 라우팅
Historical: 쿼리 가능한 데이터를 저장
MiddleManager: 데이터를 수집

Druid 실습 w.Turnilo

본 실습은 Mac OS 환경에서 수행되었으며, Druid의 Cluster 구조가 아닌 Standalone 모드로 수행되었습니다. 실제 서비스 환경에서는 Cluster 환경으로 구축하여 사용하시는 것을 추천드립니다.

1. Druid 다운로드 및 실행

wget https://dlcdn.apache.org/druid/25.0.0/apache-druid-25.0.0-bin.tar.gz

tar -xzf apache-druid-25.0.0-bin.tar.gz
cd apache-druid-25.0.0

./bin/start-druid

2. Druid UI 접속

http://localhost:8888

3. Load Data에서 원하는 저장소 선택

- 실습에서는 batch classic -> example data 선택 (위키피디아 사전 데이터)

4. Parse Data, Parse Time, Submit

각 필드들을 정의, 시간에 대한 필드 정의 후 Submit 하여 ingestion을 수행함.

최종 ingestion spec은 json 형식으로 제출되어 ingestion이 수행됨.

5. Query

SQL 쿼리를 통해 ingestion 된 데이터를 질의

Druid는 Columar 형식으로 저장하므로, dimension(필드) 기준으로 group by 연산하는 것에 빠른 속도를 보여줌

6. 추가적으로 실제 데이터, Turnilo 활용한 실습

1) Kaggle에서 적합한 데이터를 찾아 다운

본 실습에서는 ecommerce 데이터를 활용

https://www.kaggle.com/datasets/mkechinov/ecommerce-events-history-in-cosmetics-shop

eCommerce Events History in Cosmetics Shop

This dataset contains 20M users' events from eCommerce website

www.kaggle.com

2) ingestion_spec 정의 후 submit

크게 '파일의 위치', 'dimension(필드들)', metrics, granularity(묶는 시간 단위)를 정의

{
  "type": "index_parallel",
  "spec": {
    "ioConfig": {
      "type": "index_parallel",
      "inputSource": {
        "type": "local",
        "baseDir": "/Users/user/Desktop/data",
        "filter": "*.csv"
      },
      "inputFormat": {
        "type": "csv",
        "findColumnsFromHeader": true
      }
    },
    "tuningConfig": {
      "type": "index_parallel",
      "partitionsSpec": {
        "type": "dynamic"
      }
    },
    "dataSchema": {
      "dataSource": "shopping",
      "timestampSpec": {
        "column": "event_time",
        "format": "auto"
      },
      "dimensionsSpec": {
        "dimensions": [
          "event_type",
          "product_id",
          "category_id",
          "category_code",
          "brand",
          {
            "type": "double",
            "name": "price"
          },
          "user_id",
          "user_session"
        ]
      },
      "metricsSpec": [
        {
          "type": "hyperUnique",
          "name": "user_id_uv",
          "fieldName": "user_id",
          "isInputHyperUnique": false,
          "round": false
        },
        {
          "type": "hyperUnique",
          "name": "user_session_uv",
          "fieldName": "user_session",
          "isInputHyperUnique": false,
          "round": false
        }
      ],
      "granularitySpec": {
        "queryGranularity": "HOUR",
        "rollup": true
      }
    }
  }
}

3) turnilo 설치

brew install node

npm install -g turnilo
turnilo connect-druid http://localhost:8888

http://localhost:9090 접속후, UI 로 데이터 분석

- UI로 pivot table처럼 분석이 가능하여 쿼리를 모르는 기획자, 마케터들도 손쉽게 데이터를 분석하고 이를 레포트에 활용 가능

전날 발생한 브랜드별 매출

시간대별 브랜드별 매출 분석

시간대별로 발생한 쇼핑 이벤트 추이 분석

Mash-Up 13기 최종발표

MASHUP — Thu, 31 Aug 2023 00:53:28 +0900

안녕하세요 Mash-Up입니다   8월 12일엔 약 5개월간 각 프로젝트 팀들이 함께 달려온 프로젝트를 발표하는날이었어요~! 과연 어떤팀이 1등을 했을까요? 두구두구두구

정말 쟁쟁한 서비스들이 많이 나왔는데요, 매쉬업은 기수가 늘어날수록 정말 만들어지는 서비스의 퀄리티가 좋아지는게 느껴져요! 구성원들뿐만 아니라 동아리 자체가 함께 앞으로 나아가며 성장하고 있다는 느낌이 듭니다

이번 13기가 기록을 갱신한것들이 많지만 대표적인것을 두 가지만 꼽아보자면 매쉬업 창설 이후 최초로 모든 팀 배포 성공이라는 업적을 이루어냈습니다 정말 대단합니다
나머지 한가지는 역대급 시상 금액입니다! 지난 해커톤때 소개드린 DEVCRA의 후원으로 총 상금 155만원이라는 동아리에서는 정말 큰 금액이 상금으로 주어졌습니다. 1등팀은 무려 70만원의 상금을 받아갔어요 이번에도 감사합니다 DEVCRA!!

그리고 이번 최종발표도 지난 9차 세미나때처럼 캐치카페에서 공간을 지원주셨는데 아주 쾌적하게 진행 할 수 있도록 해주신 캐치도 감사합니다‍!!️

마지막으로 3월부터 서비스 MVP 기획, 디자인, 개발하느라 고생하신 Mash-Up 13기 구성원분들도 정말 감사합니다!!
Thank You Mash-Up 13th Crews!! ️️

Mash-Up 13기 9차 세미나

MASHUP — Thu, 31 Aug 2023 00:51:53 +0900

안녕하세요 Mash-Up입니다   7월 15일엔 드디어 해커톤 직전 지금까지 만들어온 프로젝트를 매쉬업 구성원들과 공유하고 점검하는 시간을 가졌습니다 :)

아직 해커톤 전인데도 정말 톡톡 튀는 아이디어를 가진 쟁쟁한 서비스들을 볼 수 있었던 시간이었어요

이번 모임은 매쉬업 후원사인 캐치에서 운영중인 캐치카페 서울대입구점에서 진행되었어요~ 정말 올때마다 쾌적하고 좋은곳이라는 생각이 듭니다 사실 열정만 가지고는 이렇게 모여서 단체 활동을 하며 성장을 도모하는것이 쉽지 않은일인데 IT 동아리, 취준생 등을 위해 후원을 아끼지 않는 캐치 정말 멋있습니다

이제 13기가 약 한 달 남았는데 남은 기간동안 매쉬업의 멋진 행보를 지켜봐주세요

Mash-Up 13기 플랫폼 작업모임

MASHUP — Tue, 20 Jun 2023 00:00:47 +0900

안녕하세요 Mash-Up입니다   6월 3일에는 Mash-Up 플랫폼 작업모임이 진행되었어요~ 프로젝트의 박차를 가하기 위해서 낮부터 모여서 하루종일 작업을 진행했답니다~

장소는 캐치카페에서 대관을 지원해주셨습니다~ 너무 넓고 쾌적했어요~ 게대가 1인 1음료까지 제공되니 너무 좋은 장소 같아요:)
대학생 혹은 취준생이라면 누구나 무료로 방문할 수 있고 음료도 제공받을 수 있다고 하니, 대학생 혹은 취준생이라면 혜택을 꼭 받아보세요:)

오늘의 모임을 통해서 작업이 많이 진행된 것 같은데요 ㅎㅎ 이번 기수 탄생할 서비스도 매우 기대가 됩니다:)

HMM팀의 취문취답 서비스, 친친을 소개합니다

huijiny — Fri, 30 Sep 2022 22:42:53 +0900

안녕하세요 여러분~

안드로이드 팀에서 10기부터 활동중인 유희진입니다!

저는 이번 12기에 HMM팀에 속해서 취향으로 묻고 취향으로 답하는 취문 취답 서비스 친친!!을 만들었습니다!

친친 서비스에 대해서..

여러분들은 평소에 가깝게 지내는 지인들의 취향을 얼마나 알고계신가요?

- 아 매쉬업에서 만난 혜진언니가 이번에 생일인데.. 분명히 어떤 와인 종류 좋아하는지 얘기했던것같은데...!!

- 대리님이 곧 출산예정일인데 아기 선물은 뭐해줘야하지? 아가 이름을 들었던것같은데....

분명히 들었던 것 같은 그들의 취향, 하지만 꼭 선물을 줘야할 시기엔 가물가물해집니다.

네. 친친은 "내 주변에 꼭 함께 하고싶은 내 바운더리의 사람들을 잘 관리하고 싶다" 에서 시작했어요.

어렵게만 느껴졌던 인맥관리를 조금 더 재미있게 취문취답으로 풀어보고 싶었답니다 :)

아래 세 가지 니즈가 있으시다면 친친이 필요한 분입니다.

1. 서로의 취향을 부담없이 물어보고 싶은 사람

2. 지인들에 대해 알아가고 좋은 인맥을 이어가고 싶은 사람

3. 지인의 경조사에 어떤 선물을 해야할지 고민인 사람

친친's Solution

질문을 통해 알아가보세요!

쉽게 물어보기 어려웠던 질문들을 취향 질문지를 만들어 보내보세요! 그 과정에서 내가 예상 답변을 작성할수도 있어요.

가물가물한 친구가 좋아하는 향수 향을 한 번 물어봐볼까요?

Q: 희진이가 좋아하는 향수 브랜드는? 그리고 향은?

A: 음... 내가 들었던건 산타마리아노벨라 프리지아인데 꽃향기 좋아했던것같아!!! 맞나?

여기서 꿀팁을 하나 드리면요, 싫어하는걸 질문지로 구성하는 것도 방법이에요.

그 친구 선물로 꼭 그건 피할 수 있으니까요!

Q: 희진이가 싫어하는 향수 향은?

A: 머스크향은 머리가 아팠다고 했던 것 같아!! 맞나?

그리고 친구에게 전송 슝~ 하면 친구에게 도착하고 수정할 수 있게 되어요~

Q: 희진이가 좋아하는 향수 브랜드는? 그리고 향은?

A: 산타마리아노벨라 프리지아! 꽃향기 좋아해! :)

Q. 희진이가 싫어하는 향수향은?

A: 머스크향! 머리아프기도하고 나랑 안어울려.

이렇게 물어보는거죠!

간단한 저희 앱의 취문취답 플로우 아래 이미지에서 확인해보시면 좋을 것 같아요

서로의 답변을 비교해봐요!

또 한 가지 재밌는 부분은! 나의 예상 답변과 친구의 답변을 비교해볼 수 있다는 점이에요~

친구와의 티키타카 한 번 확인해보면서

"아 맞닼ㅋㅋㅋㅋㅋㅋㅋ" 하면서 기억도 되살리고

"뭐야 이걸 싫어한다고? 이건 못참는데" 하면서 ~~친구 관계를 다시한번 고민~~ 친구의 의외의 취향도 알아갈 수 있다는 사쉴~

그룹핑과 Easy한 친구 등록

가장 기본적인 기능이 될 것 같아요.

아무래도 인맥관리는 그룹핑이 필요할 것 같아서 제공하게 되었습니다. 앱의 가장 메인에서 그룹들을 확인하고, 친구를 추가할 수 있어요!

친구는 친친을 사용하지 않는 미가입자 친구도 기록용으로 등록할 수 있고,

추후에 카카오톡 친구 찾기 권한동의만 한다면 손쉽게 카카오톡의 친구 목록을 불러오고 친구를 추가할 수 있어요! 일일이 친구를 등록하는것에 어려움을 겪기 싫어서 추가한 기획입니다 :)

귀염둥이 친친바라

여러분... 그런데 꼭 눈에띄는 캐릭터가 하나 있어요...

바로바로 요 귀염둥이 친친바라에요~~!! 뀨 ㅇㅅㅇ

카피바라는 다른 동물들과 친화력이 짱 좋은 동물이래요!

그래서 저희 친친서비스의 캐릭터로 해야겠다 마음을 먹었어요!

근데 예상치 못한 난관이 있었으니...

카피바라의 정면모습이 생각보다 별 특징이 없다는 점... 흠....

하지만 저희 디자인팀은 바로 능력자들이었어요.

거기서 특징을 열심히 집어내서!!!!

아래처럼 많은 스케치 과정을 거쳐~~~~~(저도 한 번 그려봤었답니다 ㅋ.ㅋ 참고로 전 똥손 안드로이드개발자)~~

귀염둥이 친친바라가 만들어졌어요~!! 짱귀엽죠? 저희 발표날에 사실 서비스보다 친친바라 칭찬이 더 많았음..ㅎ; 서비스도 알아주라구..

꺄 !! 서비스 소개 끝이에요! 어떠세요!!!?

만들면서 내가 꼭 써봐야지! 재밌겠다! 하면서 만들었답니다! :)

여러분도 꼭 친친 사용해보세요!

아 맞다! 친친은 안드로이드만 제공되고 있어요 ㅠ_ㅠ

아래서 다운받아 사용해보세요 !! XD

https://play.google.com/store/apps/details?id=com.mashup.chinchin

친친 - Google Play 앱

친한 친구의 취향을 알아보자

play.google.com

즐거웠던 HMM모먼트 몇 개만 보여드리면서 마무리 하도록 할게요~

기획 열심히 하는 것 처럼 보이지만 2차해커톤 방잡는중.. 아니 이것도 열심히하긴했어..

다들 열일중~ 머쪄 모야모야~!!!!

연중팀장님 손가락 덕분에 우리팀 노래맞추기 1등했다.

귀여워ㅡㅡ!!!

UI그만.. api 붙이고싶어요.. 나 거북목왤케심해..

3차 해커톤 밤 산책~

피자 냠냐미~ 안먹는다해놓고 계속먹는중~ 으휴~

3차 해커톤 후 꼬질꼬질 상태..는 작게..~

그럼 안뇽~~~~~~~~~~~~~~~~~~~~~~

[스프링팀] 검색 기술의 원리 발표 세션

판교가고싶어요 — Wed, 14 Sep 2022 22:11:43 +0900

안녕하세요, 스프링팀 김경환입니다. 지난 6월 11일 삼성역 하이퍼커넥트 사옥에서 매시업 전체 5차 세미나를 진행했습니다!

매시업 전체 세미나에서는 매 기수마다 모든 팀이 각각 두 세션 씩 주제를 정해서 발표를 하는데요,

12기 스프링팀에서는 개발자의 사실과 오해를 다룬 개발자 밈을 소개하는 세션과, 검색 기술의 원리를 소개하는 세션을 진행했습니다.

이번 세미나에서는 약 100명에 가까운 매시업 크루원분들이 참석해주셔서 그 어느때보다 더 활기찼는데요! 스프링팀 발표 세션에 뜨거운 호응 보내주신 점 감사드립니다!

스프링팀 세션 중 제가 발표한 검색 기술의 원리를 소개하는 세션 내용을 정리해서 공유하고자 합니다.

검색이란?

이미지출처:https://www.overpopulationatlas.com/post/where-s-wally

검색 기술을 소개하기 앞서, 윌리를 같이 찾아볼까요?

"윌리를 찾아라"는 수많은 사람들로 가득찬 큰 그림 속에서 청바지에 빨간색 줄무늬 스웨터와 모자를 쓴 윌리를 찾는 게임입니다!

여러분은 윌리를 찾을 때 어디서부터 찾으시나요?

눈을 가까이 대고 위에서부터 아래로, 혹은 왼쪽에서 오른쪽으로 한명 한명 들여다보며 찾기도 하고, 멀리 떨어져서 윌리가 있을 법한 장소를 물색해 그 부분을 자세히 들여다 보기도 합니다.

큰 그림 속 수많은 사람들 중에서 윌리를 찾는 일은 쉬운 일이 아닌데요, 혹시 찾으셨나요?

실제로 세미나에서 100명에 가까운 매시업 크루들이 같이 찾아봤지만 윌리를 찾는데는 꽤 오랜 시간이 걸렸습니다.

윌리와 상관 없는 많은 사람들 속에서 우리가 원하는 사람인 윌리를 찾는 것과 검색은 꽤나 유사한 면이 있는데요,

맛있는 식당을 찾기란 쉽지 않다

우리는 흔히 처음 가는 장소를 찾을 때나 맛집을 찾을 때 검색합니다. 가야할 장소와 상관 없는 수많은 건물 중 우리가 원하는 건물이 어디있는 지 검색하고, 수많은 음식점과 카페 중 맛집만을 가려내기 위해 검색합니다. 이처럼 검색이란 "많은 정보 중 원하는 정보만 찾아내는 것"으로 정의할 수 있습니다. 많은 사람들 중 윌리를 찾고, 많은 음식점 중 맛집만을 찾는것처럼요.

그렇다면 검색을 어떻게 해야하지?

수많은 정보 중에서 우리가 원하는 정보를 어떻게 찾을 수 있을까요?

간단한 예시를 들어봅시다. 매시업 전체 5차 세미나는 삼성역 아셈타워에 있는 하이퍼커넥트에서 진행됐는데요,

하이퍼커넥트에 오기 위해 수많은 건물 중 아셈타워를 어떻게 찾을 수 있을까요?

아셈타워를 찾기 위해서는 많은 건물 이름 중 "아셈"이라는 글자가 들어간 건물을 찾아야 합니다.

컴퓨터는 아셈을 찾기 위해 하나하나씩 비교를 해볼 수 밖에 없습니다.

먼저 "남산"과 "아셈"이 일치하는지 확인하고, 다음 두글자인 "산전"과 "아셈"이 일치하는 지 확인하는 과정을 반복해 아셈타워를 찾을 수 있습니다.

이번 예제에서는 “남산”, “산전”, “전망”, “망대”, “아셈” 순으로 총 5번의 비교연산을 통해 아셈타워를 찾을 수 있겠지만 실제로 적용이 가능할까요?

만약 건물 개수가 1000만개라면 최소 1000만번 이상의 비교 연산을 수행해야 하고, 건물 이름이 길다면 그 길이의 배수만큼 더 연산이 필요할 것입니다. 문자열 매칭 알고리즘을 사용한다면 (건물이름의 평균 길이 * 건물 개수) 만큼의 시간이 필요합니다.

매시업 세미나에 가기 위해 아셈타워를 검색하더라도 검색 결과가 나온 시간이 세미나가 끝난 시간이라면 검색은 의미가 없겠죠.

이처럼 검색은 데이터를 조회할 때 많은 연산이 필요합니다.

그렇다면 검색할 때마다 찾지 않고 데이터를 쓸 때 미리 찾아놓는 것은 어떨까요?

“검색될 데이터를 미리 찾아놓는다”는 말이 다소 모순적으로 들리는데요, 물론 미래에 사용자가 어떤 키워드로 검색을 할 지는 모릅니다!

대신 “검색이 될만한 문자열”로 미리 분리해놓을 수는 있습니다. 앞서 살펴본 예제에서 “남산전망대”라는 키워드에 “아셈”이 들어있는 지 확인할 때 “산전”, “망대”와 같이 의미없는 부분 문자열과도 비교 연산을 수행하는 것을 볼 수 있었습니다. “남산전망대” 라는 단어는 “남산” 과 “전망대”라는 명사가 합쳐진 단어입니다. 따라서 사용자는 “남산전망대”를 찾기 위해 주로 “남산” 혹은 “전망대”라는 키워드로 검색할 것이라고 추론할 수 있습니다. 이제 “남산전망대”라는 단어를 “남산”과 “전망대”라는 단어로 분리하여 각각 저장하고, 각 단어들이 “남산전망대”라는 원본 문서를 가르키도록 하면 어떨까요?

이처럼 데이터를 찾기 위해 추가적인 자료구조를 사용하는 것을 색인이라고 합니다.

검색에서 사용되는 색인은 데이터의 식별자를 사용하여 데이터를 찾는 일반적인 색인과 달리 데이터를 사용하여 데이터의 식별자를 찾는, 반대로된 색인이기 때문에 역색인(Inverted Index)라고 부릅니다.

앞선 예제를 역색인 구조로 나타낸 표는 다음과 같습니다. “아셈타워”가 “아셈”과 “타워”로, “롯데월드타워”는 “롯데월드”와 “타워”로 분리된 모습을 볼 수 있습니다.

좌측:역색인 구조 우측:원본 문서

마찬가지로 검색어를 사용해 검색이 될만한 문자열을 찾아야 하기 때문에 검색어 또한 검색이 될만한 문자열로 분리하는 과정이 필요합니다.

예를 들어 “포스코타워”로 검색한다면 “포스코” 와 “타워”로 검색어가 분리되고, “타워”라는 문자열과 일치해 검색어와 비슷한 “롯데월드타워”와 “아셈타워”를 찾을 수 있습니다.

잠깐 용어 정리를 하자면, 검색이 될만한 문자열을 짧게 줄여서 토큰이라고 부릅니다.

문자열을 토큰으로 만드는 과정을 토크나이징이라고 하고, 검색어가 토큰으로 분리되어 저장되는 과정을 인덱싱이라고 부릅니다. 주목해야할 점은 토큰은 원본 데이터를 검색이 될만한 문자열로 이기 때문에 검색어 토큰과 단순히 일치하는지만 확인한다는 점입니다.

따라서 토큰을 사전순으로 정렬하여 저장한다면 이진탐색을 활용해 특정 토큰을 빠르게 찾을 수 있습니다.

⭐️토크나이징 방법

앞서 살펴본 것처럼 데이터를 검색하기 위해서는 검색이 될만한 문자열로 분리하는 과정이 필수적입니다.

그렇다면 원본 데이터를 어떻게 분리해야 할까요? “남산전망대”의 예시처럼 여러개의 단어로 이루어진 명사의 경우 각 명사를 단위로 “남산”과 “전망대”로 쪼갤 수 있었습니다.

같은 원리로 “성장의 즐거움을 아는 친구들, IT 개발 동아리 매시업 블로그 입니다.” 라는 문자열을 쪼개면 조사나 마침표 등 문법적인 구성 요소를 제외하고, 명사나 동사만을 분리해 “성장”, “즐거움”, “알다”, “친구”, “IT”, “개발”, “동아리”, “매시업”, “블로그” 등으로 분리할 수 있습니다.

이처럼 문장을 구성하는 명사, 동사, 조사 등 각 단어의 형태소와 품사 정보를 활용해 문자열을 분리하는 규칙을 정할 수 있습니다.

하지만 단점또한 존재합니다. “아버지가방에들어셨다”와 같은 문장을 토크나이징하기 위해서는 상당히 애매모호한 부분이 존재합니다.

“아버지가방”에서 “가”를 조사로 인식해 “아버지” “방”으로 분리할 지, 혹은 “가방”으로 인식해 “아버지” 와 “가방”으로 분리할 지 결정해야 합니다.

규칙 기반 토크나이징의 모호함을 보완하기 위해 통계적인 방법을 활용해 토크나이징을 수행할 수도 있습니다.

하나의 문장을 데이터의 연결 관계(상태 변화)로 해석하여, 학습된 데이터 연결 관계를 활용해 현재 데이터가 다음 어떤 데이터로 변화(전이)할 지 추론하는 방법입니다.

쉽게 정리하자면 다음과 같습니다.

일반적으로 문장에서 첫 단어는 명사(주어)일 확률이 높고, 그 다음은 조사, 다음은 명사(목적어), 다시 조사, 마지막으로 동사(서술어)가 나올 확률이 높습니다.

“아버지가방에들어가셨다”라는 예시를 다시 보겠습니다.

“아버지”는 문장의 첫 단어이니 명사, “가”는 조사, “방”은 명사, “들어가다”는 동사로 토크나이징 하는게 확률적으로 더 올바른 토크나이징일것이라 추론할 수 있습니다.

토크나이징은 검색 품질에 많은 영향을 주는 동시에 상당히 까다로운 부분이기도 합니다.

언어별로 언어의 특성이 다르고 언어 활용 패턴도 달라 모든 문장에 적용할 수 있는 토크나이징 알고리즘은 찾기가 어렵습니다.

토크나이징은 국문학과 딥러닝을 활용하여 자연어처리 분야에서 활발하게 연구되는 분야입니다.

역색인의 저장

지금까지 역색인 구조와 역색인 구조를 만들기 위한 토크나이징까지 알아봤습니다.

토크나이징 과정을 거쳐 역색인 구조를 만들수 있었지만 역색인 데이터를 실제로 저장하기 위해서는 여러 난관을 거쳐야 합니다.

앞서 “성장의 즐거움을 아는 친구들, IT 개발 동아리 매시업 블로그 입니다.” 라는 문자열을 역색인 구조로 만들기 위해 토크나이징하면 “성장”, “즐거움”, “알다”, “친구”, “IT”, “개발”, “동아리”, “매시업”, “블로그” 총 9개의 토큰으로 분리됐습니다.

즉 하나의 원본데이터를 인덱싱하기 위해서는 역색인 구조에 아홉번 쓰기를 해야합니다. 방금 예시로 든 문장은 30자 정도의 짧은 문장이었지만, 신문기사, 블로그글처럼 아주 긴 문자열을 토크나이징 할 경우 수백개 이상의 토큰으로 분리될 수 있습니다.

따라서 역색인 구조를 저장하기 위해서는 쓰기에 강한 자료구조가 필요합니다.

애플리케이션에 적합한 자료구조를 설계하기 위해서는 부하에 대한 가정이 필요합니다. 부하란 “읽기 대 쓰기의 비율”, “단위 시간 당 읽기/쓰기 처리량”과 같이 구체적이고 정량적으로 서술됩니다.

일반적인 애플리케이션에서 데이터 구조는 SNS에 글을 올리는 빈도보다 SNS를 조회하는 빈도가 훨씬 많는 것 처럼 쓰기보다 읽기 처리가 더 많을것이라는 가정으로 설계됐습니다.

이미지 출처:&amp;amp;amp;amp;amp;amp;amp;nbsp;https://benjamincongdon.me/blog/2021/08/17/B-Trees-More-Than-I-Thought-Id-Want-to-Know/

위 그림은 일반적으로 사용되는 색인 구조인 B+Tree입니다. 한눈에 데이터 구조가 복잡하다는 것을 파악할 수 있습니다.

데이터 구조와 구조를 변경하기 위한 규칙이 복잡하다는 것은 그만큼 찾으려는 데이터가 어디에 있고, 어떻게 접근할 수 있는지에 대해 더 많은 정보를 담고 있다는 것을 의미합니다.

따라서 읽기 시 데이터가 어떻게 저장되어 있는지에 대한 정보가 전혀 없이 탐색하는 선형탐색보다 훨씬 효율적으로 탐색할 수 있습니다. 약 250테라바이트 정도의 데이터에서 원하는 데이터를 4번정도의 접근을 통해 찾을 수 있을 정도로 빠릅니다.

하지만 쓰기 시에는 정반대로 많은 연산이 필요한데요, 특히 데이터 하나의 쓰기를 위한 연산의 수는 저장되어 있는 데이터 양에 비례해 크게 증가하는 경향을 보입니다.

예를들어 10건의 데이터가 저장되어 있을 때 새로운 데이터 하나를 저장하기 위해서는 기존 데이터를 변경하는 연산이 2번 필요했다면,

100건의 데이터가 저장되어 있을때는 새로운 데이터 하나를 저장하기 위해 기존 데이터를 변경하는 연산이 20번 필요할 수도 있습니다.

이를 쓰기 증폭이라고 하며, 한번 쓴 데이터가 미래에도 계속 쓰기를 유발하는 현상을 의미합니다.

정리하자면 색인에 복잡한 데이터 구조를 사용한다면 장점으로는 읽기 질의를 효율적으로 처리할 수 있지만

단점으로는 쓰기 비용의 증가와 쓰기 증폭으로 인한 IO 대역 증가 문제가 있습니다.

그렇다면 데이터 저장 구조를 아주 단순하게 구성하는 것은 어떨까요? 색인 데이터를 저장할 때 단순히 데이터를 입력된 순서대로 순차적으로 나열하기만 한다면 쓰기 비용을 크게 줄일 수 있습니다.

하지만 데이터를 읽을 때 중복되는(덮여쓰여진)데이터가 존재하고, 무작위 순서대로 저장되어 있기 때문에 모든 데이터를 순차적으로 읽어야하는 문제가 다시 발생합니다.

이 문제를 해결하기 위해 첫번째로 역색인을 해시테이블 형태로 구성하는 방법을 고려해볼 수 있습니다.

해시키를 토큰으로, 해시값을 토큰이 들어있는 문서 번호로 저장한다면 읽기시 빠르게 접근할 수 있고, 쓰기 연산 또한 단순해진다는 장점이 있으나

저장되어야 하는 토큰의 수가 많아 해시테이블을 디스크에 저장해야 하고, 해시 엔트리의 주소로 사용되는 토큰의 해시값이 무작위적이기 때문에 쓰기 시에 디스크 랜덤 액세스로 인해 성능이 크게 떨어지는 단점이 있습니다.

두번째로 역색인 구조를 순차적으로 저장하는 방식과 B+트리와 같이 복잡한 데이터 구조를 사용하는 방식 사이에서 균형점을 찾는 방식을 고려할 수 있습니다.

핵심 아이디어는 전체 데이터를 정렬한 상태를 유지하기 보다는 “부분적으로만 정렬된 상태를 유지하자”는 것입니다. 중복을 포함하여 1000개의 토큰이 순서대로 저장되는 상황을 가정해봅시다.

먼저 순서대로 토큰을 메모리 상에서 정렬하여 저장합니다.

전체 데이터가 아닌 일부 데이터만 정렬 상태를 유지하는 것이므로 데이터 크기가 작아 메모리에 저장할 수 있고, 메모리에 저장된다면 복잡한 데이터 구조라도 디스크보다 훨씬 빠르게 정렬된 상태를 유지할 수 있습니다. 다음으로 메모리에 저장된 토큰의 수가 일정 개수 이상이 되거나, 어느정도의 시간이 지났다면 정렬된 순서를 유지하면서 디스크에 파일로 순차적으로 저장합니다.

Segment는 하나의 파일이다. 이미지출처:&amp;amp;amp;nbsp;https://yetanotherdevblog.com/lsm/

일정 개수를 100개로 가정한다면 디스크에는 100개씩 데이터가 담긴 파일 10개가 생성되고, 각 파일 내에서는 데이터가 정렬된 상태를 유지하고 있습니다. 데이터 검색 요청이 들어올 때, 저장된 10개의 파일을 순차적으로 읽습니다.

파일 내에서는 데이터가 정렬되어 있기 때문에 이진탐색을 활용하여 데이터를 효율적으로 찾을 수 있습니다. 모든 파일에서 데이터를 읽은 결과를 종합하여 중복을 제거하는 과정을 거쳐 검색 결과를 반환할 수 있습니다.

시간이 지남에 따라 데이터가 점점 더 많아져 파일 개수가 많아지고, 중복되는 데이터가 많아진다면 읽기의 효율성 또한 점점 감소하게 됩니다. 따라서 여러개의 파일을 하나로 합치고 덮여쓰여진 데이터를 삭제하면서 정렬해 새로운 파일을 만드는 작업을 주기적으로 실행해야 합니다.

이 과정은 각 파일이 정렬되어 있기 때문에 빠르게 수행할 수 있습니다. 예를들어 한 파일에는 데이터 1, 3, 5가, 다른 파일에는 1’, 2, 4, 5가 저장되어 있다면 (1’은 데이터 1이 새로 쓰여진 데이터) 두 개의 포인터를 활용하여 덮어쓰여진 데이터를 지우고 새로운 파일로 두 파일의 데이터를 모두 정렬하여 저장하고 기존의 두 파일은 삭제하면 데이터를 효율적으로 저장할 수 있고, 새롭게 생성된 파일은 더 많은 데이터가 정렬된 상태로 저장되어 있어 읽기 성능을 유지할 수 있습니다.

이와 같은 구조를 LSM 트리(Log Structure Merge Tree)라고 합니다. LSM 트리 구조는 검색엔진 외에도 높은 쓰기 처리량을 지원하는 데이터베이스에도 흔히 사용되며, 대표적으로 HBase, Cassandra가 있습니다.

추가적으로 데이터를 메모리에 임시적으로 저장하기 때문에 데이터의 보존을 위해 쓰기 요청 시 변경 로그를 디스크에 기록해야할 필요성이 있습니다. 변경 로그는 데이터가 디스크에 최종적으로 반영되기 전 장애 발생 시 복구를 위해 사용됩니다.

정리

지금까지 검색 기술을 지탱하는 원리에 대해 살펴봤습니다.

검색이란 “많은 데이터 중에서 원하는 데이터를 찾는 것”으로 정의할 수 있었습니다. 검색을 효율적으로 수행하기 위해 토크나이징으로 역색인 구조를 구성할 수 있었습니다.

토크나이징 방법으로는 규칙 기반과 통계 기반 토크나이징 방법이 있었으며 역색인 구조를 저장하기 위해 쓰기 처리에 강한 LSM 트리 구조를 사용함을 알 수 있었습니다.

감사합니다.