영암사는 승경이네

1. 개요

 Redis를 활용하여 사전순으로 조회되는 자동완성 기능을 구현했으나 검색빈도에 따라 자동완성 리스트를 뿌려주는 것이 사용자 입장에서 유용할 것 같다는 생각이 들었다. 또한 사용자 검색한 새로운 키워드도 데이터 셋에 추가해야 트렌드에 맞는 자동완성 리스트를 제공할 수 있을 것 같아 이를 적용하는 작업을 진행하였다.

2. 분석

 현재 redis에 들어가 있는 자동완성 데이터는 Score가 모두 0인 Sorted Set 형식이다. 또한 사용자가 검색한 단어를 prefix로 갖고 있는 완성된 단어를 뿌려주기 위해 필자가 정한 규칙에 맞게 데이터가 들어가 있는 상황이다. 예를들어 '대', '대한', '대한민', '대한민국' 이라는 키워드 입력시 자동완성 리스트에 '대한민국' 이라는 단어가 나오도록 하기 위해 score를 모두 0으로하여  '대', '대한', '대한민', '대한민국', '대한민국*' 값을 sorted Set 형식의 데이터 셋에 저장시킨 상태이다.

 비지니스 로직은 다음과 아래와 같이 구현되어 있다.

 1) 검색어와 일치하는 단어의 index 조회(zrank 명령어 사용) 

 2) index 번째부터 index + 100번째까지의 데이터 조회(zrange 명령어 사용)

 3) '*' 문자를 포함하는 완전한 단어를 필터링

 4) 검색어의 prefix와 일치하는 완전한 단어를 필터링 및 limit

위에 대한 자세한 내용은 이전 포스팅에 기재되어있다.

https://tlatmsrud.tistory.com/106

 어쨌든 검색빈도 순으로 조회시키기 위해서는 반드시 검색횟수를 관리하는 데이터셋이 필요했다. 먼저 기존 데이터셋을 활용하는 쪽으로 시도하였으나 실패했다.

3. 기존 테이터 셋 활용

 기존 데이터 셋의 score를 활용할 경우 사용자가 단어를 입력 후 '검색' API를 호출했을 때 검색한 단어가 데이터 셋에 추가되어야 하고, score가 1이 올라가야 한다. 이때 두가지 케이스로 나눌 수 있는데, 검색한 단어에 대해서만 score를 올리는 케이스, 검색한 단어와 연관된 데이터들의 score를 올리는 케이스이다.

3.1. 검색한 단어에 대해서만 Score 증가

 전자의 경우 score가 올라가는 완성된 단어들은 데이터셋의 하단부에 위치하게 되고, 나머지 데이터들은 상단부에 위치하게 된다. 원래 나머지 데이터들은 자동완성 단어를 index 기반으로 빠르게 조회하기 위해서 사용했었으나, 자동완성 단어의 score가 올라가며 index 규칙이 깨지게 되었다.

 아까 말한대로 자동완성들은 하단부, 나머지 데이터는 상단부에 위치하게 되니 결국 index부터 끝까지 모든 값을 조회해야하는 상황이 발생했다. 지금은 데이터 셋이 적어서 큰 문제가 되지 않을테지만, 시간 복잡도에 따라 데이터 양이 증가할수록 속도가 느려질 것이다. (zrange의 시간복잡도는 O(log(n)+m)이다. m은 반환된 결과의 수이다.) 아래는 그 예이다.

AS-IS의 경우 '대'에 대한 zrange 시 index 기준 +4에 대한민국*이 위치한다. 즉, 가까운 곳에 자동완성 단어들이 위치하고 있기 때문에 굳이 데이터셋의 끝까지 조회할 필요가 없다. 필자의 경우 가중치를 두어 index ~ index+1000 까지만 조회하도록 했다.

TO-BE의 경우 '대'에 대한 zrange 시 index와 먼 곳에 자동완성 단어들이 위치한다. 데이터 셋의 끝까지 조회해야 할 필요성이 느껴진다.

3.1. 검색한 단어와 연관된 데이터들의 Score 증가

 후자의 경우는 자동완성 단어 누락을 야기할수 있다. '대만'이라는 데이터를 추가하여 예를 들어보겠다. 

score가 0일때는 위와 같이 사전순으로 정렬된다. 사용자가 '대한민국'이라는 검색 API를 통해 검색하는 순간 관련된 데이터인 '대', '대한', '대한민', '대한민국', '대한민국*'의 score가 1씩 올라갈것이다. 그리고 데이터는 아래와 같이 조회된다.

이때 '대'에 대한 자동완성 단어들은 index 기준 앞, 뒤에 위치해있다. 기존에는 자동완성 단어들을 찾기위해 한쪽 방향으로 조회했다면, 이제는 양쪽 방향으로 조회하며 찾아야한다.

 또한 새로운 단어들이 추가될 경우 score에 따라 데이터들이 뒤죽박죽 섞여버린다. 섞여버린 데이터들에서 자동완성 단어를 찾으려면 무조건 처음부터 끝까지 풀서치를 할수밖에 없는 상황이 되었다.

결국 기존 데이터셋은 그대로 유지하고, 검색 횟수를 관리하는 새로운 데이터셋을 추가하기로 했다.

4. 새로운 데이터 셋 도입

 검색 단어들을 관리하는 새로운 데이터 셋을 만들었다. value는 검색어, score는 검색횟수이다. 기존 데이터셋은 자동완성 데이터를 조회하기 위해 기존과 동일하게 사용하고, 새로운 데이터셋은 기존 데이터셋에서 조회한 자동완성 단어에 대해 score(검색횟수)를 조회하는 용도로 사용했다. 이후 비지니스 로직을 통해 score 기준으로 내림차순 정렬처리 하였다.

검색 횟수 데이터셋이 추가됨에 따라 기존 로직에서 아래 빨간 부분에 대한 로직을 추가하였다.

 1) 검색어와 일치하는 단어의 index 조회(zrank 명령어 사용)

 2) index 번째부터 index + 100번째까지의 데이터 조회(zrange 명령어 사용)

 3) '*' 문자를 포함하는 완전한 단어를 필터링

 4) 검색어의 prefix와 일치하는 완전한 단어를 필터링 및 limit

 5) 필터링된 데이터의 score 조회 (zscore)

 6) score를 기준으로 정렬

* 참고로 zscore를 사용한 이유는 시간복잡도가 O(1)이기 때문이다. 시간이 지날수록 데이터 양이 많아지는 데이터 특성 상 처리 속도를 일정하게 유지하는 것이 효율적이라고 판단하여 이 방식을 채택했다.

이제 실제로 구현해보자.

5. 구현

5.1. AutocompleteController.kt

@RestController
@RequestMapping("/api/autocomplete")
class AutocompleteController (
    private val autocompleteService : AutocompleteService
){

    @GetMapping("/{searchWord}")
    @ResponseBody
    fun getAutocompleteList(@PathVariable searchWord : String) : ResponseEntity<AutocompleteResponse> {

        return ResponseEntity.ok(autocompleteService.getAutocomplete(searchWord))
    }
}

 기존과 동일하다.

5.2. AutocompleteService.kt

@Service
class AutocompleteService (
    private val redisTemplate : RedisTemplate<String, String>,
    @Value("\${autocomplete.limit}") private val limit: Long,
    @Value("\${autocomplete.suffix}") private val suffix : String,
    @Value("\${autocomplete.key}") private val key : String,
    @Value("\${autocomplete.score-key}") private val scoreKey : String
){
    fun getAutocomplete(searchWord : String) : AutocompleteResponse {

        val autocompleteList = getAutoCompleteListFromRedis(searchWord)
        return sortAutocompleteListByScore(autocompleteList)
    }

    fun addAutocomplete(searchWord : String ){

        val zSetOperations = redisTemplate.opsForZSet()
        zSetOperations.incrementScore(scoreKey, searchWord, 1.0)

        zSetOperations.score(key, searchWord)?:let {
            for(i in 1..searchWord.length){
                zSetOperations.add(key, searchWord.substring(0,i),0.0)
            }
            zSetOperations.add(key, searchWord+suffix,0.0)
        }

    }

    fun getAutoCompleteListFromRedis(searchWord : String) : List<String> {

        val zSetOperations = redisTemplate.opsForZSet()
        var autocompleteList = emptyList<String>()

        zSetOperations.rank(key, searchWord)?.let {
            val rangeList = zSetOperations.range(key, it, it + 1000) as Set<String> // 가중치 1000
            autocompleteList = rangeList.stream()
                .filter { value -> value.endsWith(suffix) && value.startsWith(searchWord) }
                .map { value -> StringUtils.removeEnd(value, suffix) }
                .limit(limit)
                .toList()
        }

        return autocompleteList
    }

    fun sortAutocompleteListByScore(autocompleteList : List<String>) : AutocompleteResponse{
        val zSetOperations = redisTemplate.opsForZSet()

        val list = arrayListOf<AutocompleteResponse.Data>()
        autocompleteList.forEach{word ->
                zSetOperations.score(scoreKey, word)?.let {
                    list.add(AutocompleteResponse.Data(word, it))
                }
        }
        list.sortByDescending { it.score }
        return AutocompleteResponse(list)

    }
}

1) getAutoCompleteListFromRedis 메서드를 통해 Redis의 자동완성 데이터셋에서 자동완성 데이터를 가져온다. 가중치는 1000, limit는 10으로 설정하였다. 

2) sortAutocompleteListByScore 메서드를 통해 검색횟수 데이터 셋에 값이 있는지 확인한다. 값이 있을 경우 score 가져와 list에 추가하고, sortByDescending 메서드를 사용해 score 기준으로 내림차순 정렬한다.

3) addAutocomplete는 검색 로직에서 사용하는 메서드로, 자동완성 데이터셋에 검색어가 없을 경우 규칙에 맞게 추가하고, 검색횟수 데이터 셋에 score를 추가 및 증가시킨다.

 * 참고로 검색횟수 데이터 셋 score를 증가시킬 때 사용한 incrementScore는 데이터 셋에 값이 없을경우 자동으로 값을 추가해준다.

5.3. SearchService.kt

    fun searchProductList(searchWord: String, pageable: Pageable): ProductListResponse? {
        autocompleteService.addAutocomplete(searchWord)
        return productRepository.selectProductListBySearchWord(searchWord,pageable)
    }

 검색관련 비지니스 로직이다.(자동완성 로직이 아니다.) 여기서 autocompleteService를 DI받아 addAutocomplete를 호출하고 있다. 

5.4. AutocompleteResponse.kt

data class AutocompleteResponse(
    val list : List<Data>
){
    data class Data(
        val value: String,
        val score: Double
    )
}

 자동완성 응답 DTO 클래스이다.

6. 테스트

 게임 기종 관련하여 자동완성 데이터셋과 검색횟수 데이터셋을 생성한 후 테스트를 진행하였다.

6.1. 자동완성 리스트 조회

 '닌'이라는 단어를 입력했을 때 조회되는 자동완성 리스트들이다. value에는 자동완성 단어, score에는 검색횟수가 조회되고 있다.

6.2. 검색 후 자동완성 리스트 조회

 이제 제일 하단에 조회되는 '닌텐도 DS'라는 단어를 검색 API를 통해 검색한 후 '닌'에 대한 자동완성 리스트를 다시 조회해보자. 아래와 같이 닌텐도 DS라는 단어가 최상단에 조회됨을 확인할 수 있다.

6.3. 새로운 단어 검색 후 조회

 검색 API를 통해 '닌텐도 new 3DS'라는 새로운 단어를 두번 검색 후 다시 조회해보자. 아래와 같이 '닌텐도 new 3DS' 새로 추가됨과 동시에 최상단에 위치해있는 걸 확인할 수 있다.

7. 회고

 기존 데이터셋을 활용하는게 메모리적와 속도면에서 훨씬 효율적일 것 같아 여러 시도를 해보았지만, 결국 새로운 데이터셋을 추가하는 쪽으로 구현하게 되었다.

 새로운 데이터 셋 추가를 꺼려했던 이유는 속도 때문이었다. 처음엔 메모리도 신경쓰였으나 이 경우 기존 데이터셋보다 10분의 1도 안될 것이었기때문에 큰 걱정은 되지 않았다. 하지만 Redis를 한번 더 거쳐야 하고, 거기서 많은 자원을 사용하는 로직이 포함될 경우 처리 속도가 너무 느려지지 않을까하는 걱정이 앞섰다.

 때문에 redis 문법에 대한 처리 속도와 redis 라이브러리에서 제공하는 여러 메서드들을 하나하나 찾아가며 어떤게 더 효율적일지를 고민하게 되었고, 값에 대한 score를 조회한 후 비지니스 로직에서 정렬하는 방식을 채택하게 되었다.

 score 조회 명령어의 시간복잡도와, 비지니스 로직에서 정렬하는 데이터의 개수(10개)를 고려했을 때 처리속도에 큰 영향을 끼칠만큼의 복잡도가 아니라고 생각했기 때문이다.

 글로 남기지 않은 많은 시행착오가 있었지만 결국 나름 괜찮은(?) 자동완성 API를 구현하게 된것 같다. 혹시 포스팅 관련하여 수정할 내용이나 피드백이 있다면 꼭! 꼭! 알려주시길 바란다 :)

8. 참고

1) RedisTemplate 공식문서 - https://docs.spring.io/spring-data/redis/docs/current/api/org/springframework/data/redis/core/RedisTemplate.html

2) Redis 명령어 - http://redisgate.kr/redis/command/zrange.php

1. 개요

 Redis를 활용하여 자동완성 기능을 구현해보았다.

2. Redis를 선택한 이유

2.1. 속도

 Redis는 인 메모리에 데이터를 저장하고 조회하기 때문에 디스크에 저장하는 DB보다 훨씬 빠르다. 속도가 중요한 이유는 사용자가 단어를 한글자씩 입력할때마다 자동완성 값을 빠르게 뿌려줘야 하기 때문이다.

 네이버에서 '가, 나, 다, 라' 단어를 입력하면 아래와 같이 '가, 가나, 가나다, 가나다라'에 대한 자동완성 조회 API로 통신한다. 프론트에 값이 미리 저장되어 있는 것처럼 즉시적으로 나오는데 서버 응답 값이다. 속도가 빠를수록 자동완성 리스트를 더 빨리 제공할 수 있으며, 조회의 성격이 강한 데이터이므로 Redis를 선택했다.

 여담으로 네이버의 경우 입력한 검색어를 한번 더 입력할 경우 서버와 통신하지 않고 자동응답 값을 가져오고 있다. 서버에서 값을 조회했을 때 해당 검색어와 응답 데이터셋을 프론트에 저장해두고 가져다 쓰는 것 같다.

2.2. Sorted Set

 Redis는 데이터를 저장하기 위한 다양한 자료구조를 제공한다. 그 중 Sorted Set은 문자열을 Score와 함께 관리하고, Score로 정렬되는 자료구조인데, 동일한 점수를 갖는 경우 '사전순'으로 정렬한다. 

Redis 정렬 세트는 연관된 점수로 정렬된 고유한 문자열(구성원)의 모음입니다. 둘 이상의 문자열이 동일한 점수를 갖는 경우 문자열은 사전순으로 정렬됩니다. - https://redis.io/docs/data-types/sorted-sets/

 일반적으로 검색어와 prefix가 일치하는 단어들을 자동완성 리스트로 뿌려야하는데, 사전순으로 정렬이 되어있다면 prefix가 일치하는 단어들은 검색어보다 뒤에 위치한다. 즉, 검색어의 index를 안다면 prefix가 일치하는 리스트를 뽑아낼 수 있다. 그리고 이 리스트가 자동완성 단어가 된다. 이러한 성격을 활용하면 어렵지 않게 자동완성 기능을 구현할 수 있다.

3. 관련 명령어

 Sorted Set을 사용하기 위한 주요 Redis 명령어들이다. 이해를 위해 아래 명령어는 숙지하는 게 좋다.

3.1. ZADD

 데이터 셋에 데이터를 Score와 함께 추가한다.

 [ZADD key score value]

 요청 > ZADD mydataset 1 한국

 요청 > ZADD mydataset 2 미국

 요청 > ZADD mydataset 3 러시아

 요청 > ZADD mydataset 4 프랑스

 요청 > ZADD mydataset 4 북한

 요청 > ZADD mydataset 4 가나

3.2. ZRANGE

  주어진 범위 내에 데이터 셋을 반환한다. Score가 적은 것부터 조회하며, 동일한 Score를 가진 데이터가 여러개 있을 경우 사전순으로 조회된다.

 [ZRANGE key startIndex endIndex]

 요청 > ZRANGE mydataset 0 -1

 응답 >

 1) 한국

 2) 미국

 3) 러시아

 4) 가나

 5) 북한

 6) 프랑스

3.3. ZRANK

 정렬된 기준이 오름차순이라고 가정하고 검색한 데이터의 index를 반환한다.

 [ZRANK key value]

 요청 > ZRANK mydataset 한국

 응답 > 0

 요청 > ZRANK mydataset 미국

 응답 > 1

4. 분석

 이제 Reids의 Sorted Set을 활용해 어떻게 구현할지 분석해보자.

4.1. 자동완성 단어 조회 매커니즘

 기본적인 매커니즘은 어떤 값을 조회하면, 그 값을 prefix로 갖는 단어들을 조회하는 것이다. 

 '안' 이라는 값을 입력하면 '안경', '안경점'을 포함하는 리스트가 조회되어야 한다.

 '안경' 이라는 값을 입력하면 '안경', '안경점'을 포함하는 리스트가 조회되어야 한다.

 Sorted Set을 활용하면 이러한 구조를 쉽게 구현할 수 있다. 먼저 zadd를 통해 데이터 셋을 추가해주는데, '안경점' 이라는 문자를 추가하고자 할 경우, 이를 구성하는 [안, 안경] 이라는 문자열도 데이터 셋에 추가해줘야한다. 

요청 > zadd mylist 0 안경점

요청 > zadd mylist 0 안경

요청 > zadd mylist 0 안

안경점 이라는 자동완성 단어를 추가하기 위해 Sorted Set에 0 Score로 '안경점', '안경', '안' 을 zadd 하였다. range mylist 0 -1로 모든 리스트를 조회하면 아래와 같이 사전순으로 '안', '안경', '안경점'이 조회된다.

요청 > zrange mylist 0 -1

응답 >

1) 안

2) 안경

3) 안경점

 여기서 앞서 언급했던 매커니즘을 예시에 적용하면 ['안'을 조회하면, '안'을 prefix로 갖는 단어들이 조회되어야 한다.]이다. 그런데 사전순으로 정렬되어 있다보니 '안'을 prefix로 갖는 단어들은 '안'의 index를 포함하여 아래 위치한 값들이 된다. 마찬가지로 '안경'을 조회하면 '안경'을 prefix로 갖는 단어들은 '안경'이 갖는 index를 포함하여 아래 위치한 값들이다. 결국 검색어에 대한 index를 찾는다면 자동완성 단어를 추출할 수 있다. 이 index는 zrank 명령어로 찾으면 된다.

 정리하면 zadd를 통해 자동완성 단어에 대한 데이터 셋을 만들고,  zrank를 사용해 검색어에 대한 index를 찾고, zrange를 통해 index 부터 조회하여 연관 단어를 찾는 것이다.

4.2. 완전한 단어

 '플레이스테이션' 이라는 단어로 예를 더 들어보겠다. 이 단어를 자동완성 단어로 사용하기  '플', '플레', '플레이' ... '플레이스테이션' 데이터들을 추가했다.

요청 > zadd mylist 0 플

요청 > zadd mylist 0 플레

요청 > zadd mylist 0 플레이

요청 > zadd mylist 0 플레이스

요청 > zadd mylist 0 플레이스테

요청 > zadd mylist 0 플레이스테이

요청 > zadd mylist 0 플레이스테이션

그리고 '플레이' 라는 단어에 입력했다고 가정하고 index를 구했다.

요청 > zrank mylist 플레이

응답 > 2

마지막으로 prefix를 가진 값들을 조회하기 index 부터 값을 조회했다.

요청 > zrange mylist 2 - 0

응답 >

1) 플레이

2) 플레이스

3) 플레이스테

4) 플레이스테이

5) 플레이스테이션

여기서 플레이스, 플레이스테, 플레이스테이와 같은 완전한 단어가 아니다. 이러한 값들은 자동완성 단어에 적합하지 않다. 하지만 없어서는 안된다. index를 찾아야만 완전한 단어를 검색할 수 있기 때문이다.

 결국, 완전한 단어를 나타내는 데이터와 그 단어를 검색하기 위한 데이터를 구분해야한다. 이는 완전한 단어의 suffix에 '*'와 같은 구분자를 붙어주면 된다.

요청 > zadd mylist 0 플레이스테이션*

이 상태에서 다시 zrange를 하게 된다면 아래와 같이 값들이 조회될것이다.

요청 > zrange mylist 2 - 0

응답 >

1) 플레이

2) 플레이스

3) 플레이스테

4) 플레이스테이

5) 플레이스테이션

6) 플레이스테이션*

 여기서 자동완성에 쓸 데이터는 완전한 단어인 '*'가 붙은 문자열들만 추출한 후 사용하면 된다. 이렇게 될 경우 플레이, 플레이스, 플레이스테이, 플레이스테이션을 검색해도 자동완성 리스트에 조회되는 결과는 플레이스테이션이라는 완전한 단어만이 조회될 것이다.

 '*' 문자를 포함하는 데이터만을 추출하는 작업은 redis에서 지원하는 문법이 없는 관계로 비지니스 로직에서 처리하면 된다.

5. 데이터 셋 만들기

 결국 위 내용에 따라 자동완성 데이터 셋들을 만들어야 한다. '플레이스테이션'이라는 단어에 대해서는 8개의 데이터를 redis에 넣어줘야한다. 엥? 필자는 많은 단어들을 넣어야하는데... 생각해보니 너무 오래걸릴 것 같아서 이 부분은 넘어가도록 하겠다.

 는 대학생 과제 제출 시 마인드였고, 미래를 생각했을때 데이터 셋을 자동으로 생성해주는 뭔가가 있지 않을까 해서 구글링을 하였다. 마침 AWS 공식 블로그에서 Redis 자동완성 관련 내용을 다룬 게시글이 있었고 파이썬으로 데이터 셋을 만들어 redis에 넣는 코드가 있었다.

 코드 내용을 분석하여 나에게 맞게 수정한 후 웹에서 파이썬 코드를 컴파일할 수 있는 https://replit.com/ 사이트에서 코드를 실행하였다. 여기 접속해서 아래 아래 코드를 실행시키면 Redis 서버로 위와 같은 데이터셋을 추가할 수 있다.

https://replit.com/ 

아래 코드에서 host, port을 입력하고 완전한 단어들이 들어있는 autocomplete.txt 파일을 생성해준다. text 파일은 왼쪽 파이썬 코드와 같은 레벨에 생성해주면 된다.

#-*- coding:utf-8 -*-
import redis

r = redis.StrictRedis(host='host 입력', port=port입력, db=0)

f = open("autocomplete.txt","rt", encoding="utf-8")
for line in f:
  n = line.strip()
  for l in range(len(n)+1):
    prefix = n[0:l]
    print(prefix)
    r.zadd('autocomplete2',{prefix : 0})
  r.zadd('autocomplete2',{n+"*" : 0})
  print(n+"*")
else:
  exit

여기서 또 여담하나 풀도록...(엣헴)

위 코드를 실행하고 redis에 들어간 데이터를 redis-cli로 확인해봤더니 아래와 같이 한글이 깨져서 들어갔다.

 닌텐도와 닌텐도 DS라는 단어였는데 영어는 잘들어가고 한글은 깨져서 들어갔다. 이왕 사용할거 코드가 간단하기도 하고 스프링 기반으로 내가 직접 만들어보자라는 생각에 파이썬 코드를 분석하여 스프링 기반으로 만들었다.

 나중에 알고보니 저렇게 깨지는건 필자가 언젠가 Redis 설정을 건들면서 발생한 문제로 한글이 깨져 보였던 것이었고, 재설치하니 잘 조회되더라. 참고로 저렇게 보여도 잘 들어간게 맞았습니다... (네?)

 그렇다고 뻘짓을 한건 절대 아니다. 웹 사이트에서 실행 시 redis로 데이터가 들어가는 속도가 많이 느렸기 때문이다. git 잔디도 심었으니 오히려좋아... 

6. 구현

 코틀린 기반으로 로직을 구현했다. 설정 관련 코드와 주요 비지니스 로직이 담긴 Service 코드만 설명하겠다.

6.1. RedisConfig.kt

@Configuration
class RedisConfig(
    @Value("\${spring.redis.port}") private val port: Int,
    @Value("\${spring.redis.host}") private val host: String,
) {

    @Bean
    fun redisConnectionFactory(): RedisConnectionFactory? {
        return LettuceConnectionFactory(host, port)
    }
    @Bean
    fun redisTemplate(): RedisTemplate<String, String> {
        val template = RedisTemplate<String, String>()
        redisConnectionFactory()?.let { template.setConnectionFactory(it) }
        template.keySerializer = StringRedisSerializer()
        template.valueSerializer = StringRedisSerializer()
        return template
    }
}

 keySerializer와 valueSerializer를 모두 StringRedisSerializer로 설정하였다. 객체 형태의 value 값을 관리할 때에는 valueSerializer를 GenericJackson2JsonRedisSerializer 형식으로 설정하는데, 자동완성에 적용하니 큰따옴표(")로 인한 이슈가 발생했다.

'닌텐도', '닌텐도 DS' 문자로 데이터 셋을 만들면 위와 같이 문자열이 생성되는데 GenericJackson2JsonRedisSerializer 이 설정된 상태로 Redis에 데이터를 넣게 된다면 문자열마다 큰따옴표가 들어가게 된다. 아래와 같이 말이다.

의도했던 정렬 순서로

[닌, 닌텐, 닌텐도, 닌텐도*, 닌텐도(공백), 닌텐도 D, 닌텐도 DS, 닌텐도 DS*] 가 되어야 하는데 저 큰따옴표가 들어가는 바람에 사전순으로 정렬할 시 (공백)문자보다 큰따옴표를 나타내는 \" 문자가 뒤로 밀려

[닌, 닌텐, 닌텐도(공백), 닌텐도 D, 닌텐도 DS, 닌텐도 DS*, 닌텐도, 닌텐도*] 순으로 정렬이 되버렸다.

 이 상태에서 '닌텐도 DS'를 검색한다면 '닌텐도 DS'와 '닌텐도' 가 조회되게 된다. 이 이슈로 인해 영향도를 분석 후 valueSerializer를  GenericJackson2JsonRedisSerializer 에서 StringRedisSerializer로 변경하였고, 큰따옴표로 인한 문제는 해결되었다.

 그런데 또다른 문제가 발생했다. 이번에는 완전한 단어를 나타내기 위해 넣었던 '*' 로 인해 발생했다. 현재 정렬되는 데이터 순서는 [닌, 닌텐, 닌텐도, 닌텐도(공백), 닌텐도 D, 닌텐도 DS, 닌텐도 DS*, 닌텐도*] 였기 때문에 '닌텐도 DS'를 검색한다면 위와 마찬가지로 '닌텐도 DS'와 '닌텐도'가 여전히 조회된다.

이에 대해 총 두가지 방법을 생각해냈다. 첫번째 방법은 검색어가 redis에서 추출한 데이터의 시작부분에 포함되어 있는지를 비지니스 로직에서 확인하는 것이고, 두번째 방법은 완전한 단어를 나타내는 문자 앞에 공백을 추가하여 '*'에서 ' *'로 변경하는 방법이었다.

 결국은 첫번째 방법을 선택했는데, 그 이유는 이 과정이 필수적으로 들어가야 했기 때문이다. 플레이스테이션1, 플레이스테이션2 에대한 데이터 셋이 있을 때 '플레이스테이션'을 검색할 경우 [플레이스테이션1, 플레이스테이션2] 가 조회되어 정상으로 보이지만, '플레이스테이션1'을 검색할 경우 [플레이스테이션1] 뿐 아니라 [플레이스테이션 2]도 같이 조회되게 된다. 이 이유는 아래와 같이 플레이스테이션1보다 플레이스테이션2가 가나다 순으로 더 뒤에 위치하기 때문이다. 

1)플

2) 플레

3) 플레이

...

x) 플레이스테이션1*

x+1) 플레이스테이션2

x+2) 플레이스테이션2*

6.2. AutocompleteService.kt

@Service
class AutocompleteService (
    private val redisTemplate : RedisTemplate<String, String>,
    @Value("\${autocomplete.limit}") private val limit: Long,
    @Value("\${autocomplete.suffix}") private val suffix : String,
    @Value("\${autocomplete.key}") private val key : String
){
    fun getAutocomplete(searchWord : String) : AutocompleteResponse {
        val zSetOperations = redisTemplate.opsForZSet()
        var autoCompleteList  = emptyList<String>()

        zSetOperations.rank(key, searchWord)?.let {

            val rangeList = zSetOperations.range(key, it, it+1000) as Set<String>

            autoCompleteList =  rangeList.stream()
                .filter { value -> value.endsWith(suffix) && value.startWith(searchWord)}
                .map { value -> StringUtils.removeEnd(value,suffix) }
                .limit(limit)
                .toList()
        }
        return AutocompleteResponse(autoCompleteList)
    }
}

sortedSet에 대한 작업을 수행할 수 있는 zSetOperation 객체를 생성하고, 위 매커니즘에서 언급했던 작업들을 구현하였다.

1) zSetOperations.rank(key, searchWord)?.ley{} : zrank를 명령어를 통해 검색어(searchWord) 데이터의 index를 구한다.

2) zSetOperations.range(key, it, it+1000) : zrange 명령어를 통해 index ~ index+1000 까지의 데이터를 조회한다. 사전순으로 정렬되어 있으니 index 와 가까운 위치에 자동완성 데이터가 존재할 것이기 때문이다. 이에 대한 가중치를 1000으로 설정하였기에 it+1000까지 조회하였다.

3) filter{value -> value.endsWith(suffix) && value.startWith(searchWord)} : 조회된 문자열 중 마지막이 suffix(=='*')로 끝나고,  검색어로 시작하는값들을 필터링한다.

4) map{ value -> StringUtils.removeEnd(value,suffix) } : 필터링 된 데이터들에 포함된 suffix를 제거한다.

5) limit(limit).toString() : 최대 limit개로 제한하여 리스트로 만든다.

7. 테스트

 원하는 값들이 정상적으로 나옴을 확인할 수 있다. 지금은 URL에 일일이 입력하여 처리하고 있지만, 프론트 단에서는 검색란에 값을 입력하는 순간 위 API를 태우도록 구현하면 된다.

8. 회고

 Sorted Set의 자료구조와 Redis 명령어들을 이해하기 위해 공식문서 위주로 보며 실습을 진행하였다. 어느정도 정리가 되니 어떻게 구현 방법을 계획했고, 실행에 옮겼다. 물론 이 과정에서 value 직렬화나, Redis 한글깨짐, 의도하지 않은 정렬 등 여러 이슈들을 마주했지만 그것들이 발생한 원인을 분석하고 해결해나가면서 배운 것들이 매우 의미있다고 생각한다.

 지금은 정렬된 순서 그대로 자동완성 단어들을 뽑아내고 있지만, 단어의 검색 량에 따라 조회되는 우선순위를 달리하여 자동완성 단어들을 뽑아낼 수 있도록 수정해도 좋을 것 같다.

9. 참고

Redis Sorted Set - https://redis.io/docs/data-types/sorted-sets/

Redis Autocomplete - https://aws.amazon.com/ko/blogs/database/creating-a-simple-autocompletion-service-with-redis-part-one-of-two/

Redis Command - http://redisgate.kr/redis/command/zrange.php

1. 개요

 국토 교통부에서 제공하는 법정동 코드를 다운받아 DB 테이블에 밀어 넣고, JPA를 통해 주소를 검색하는 API를 구현하였다. 하지만 데이터의 양이 많아 응답까지 1초 ~ 3초정도가 소요되는 것을 보고 Redis의 캐싱 기능을 도입하게 되었다. 그 과정을 정리한다.

2. Cache 설정

2.1. RedisCacheConfig.kt

@Configuration
@EnableCaching
class RedisCacheConfig {

    @Bean
    fun redisCacheManager(cf: RedisConnectionFactory?): CacheManager? {
        val redisCacheConfiguration = RedisCacheConfiguration.defaultCacheConfig()
            .serializeKeysWith(RedisSerializationContext.SerializationPair.fromSerializer(StringRedisSerializer()))
            .serializeValuesWith(
                RedisSerializationContext.SerializationPair.fromSerializer(
                    GenericJackson2JsonRedisSerializer()
                )
            )
            .entryTtl(Duration.ofDays(1))
        return RedisCacheManager.RedisCacheManagerBuilder.fromConnectionFactory(cf!!)
            .cacheDefaults(redisCacheConfiguration).build()
    }
}

 TTL은 하루로 설정하였고, 직렬화 방식은 key는 String, value는 GenericJackson2JsonRedisSerializer를 사용했다. 이 형식을 사용한 이유는 캐싱할 value 값이 List<Object> 형태였기 때문이다.

2.2. Applicatoin.kt

@SpringBootApplication
@EnableCaching
class Application

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

 캐시를 사용하기 위해 Application 실행파일에 @EnableCaching을 추가하였다.

2.3. Service.kt

@Service
class AddressService (
    private val addressRepository: AddressRepository
){

    @Cacheable(value = ["Address"], key = "#searchWord", cacheManager = "redisCacheManager")
    fun searchAddress(searchWord : String) : List<AddressResponse> {
        return addressRepository.findBySearchWordLike(searchWord)
    }

}

 캐시를 적용하고자 하는 메서드에 @Cacheable 을 설정한다. [value]는 redis에 저장되는 Key의 prefix, [key]는 suffix 이다. 만약 동일한 키를 가진 캐싱 데이터가 있을 경우 cache hit가 발생하여 캐싱된 데이터를 조회하고, 없을 경우 cache miss가 발생하여 DB에서 데이터를 조회한 후 데이터를 캐싱할 것이다.

 cacheManage에는 RedisCacheConfig 에서 생성한 Bean 이름을 넣어준다.

2.4. Controller.kt

@Controller
@RequestMapping("/api/address")
class AddressController (
  private val addressService : AddressService
) {
...
    @GetMapping("/search")
    fun searchAddress(@RequestParam("searchWord") searchWord : String) : ResponseEntity<List<AddressResponse>> {

        val list = addressService.searchAddress(searchWord)
        return ResponseEntity.ok(list)
    }
...
}

 Controller에서 캐싱 메서드를 호출한다.

3. 테스트

3.1. 최초 검색

 최초 검색시 cache miss가 발생함에 따라 DB 조회 및 redis 에 데이터를 캐싱하는 과정을 거치게 된다. IDE에 찍힌 로그를 보면 JPA 쿼리 결과가 조회되는데, 이는 DB를 조회하여 데이터를 가져왔다는 사실을 알수있다.

 캐싱된 데이터는 redis-cli 를 실행 후 keys, get 명령어를 통해 확인할 수 있다. 시간은 1400ms가 소요되었다.

3.2. 두번째 요청

  동일한 값으로 요청하니 cache hit가 발생하여 DB를 조회하지 않고 캐싱된 데이터를 조회하고 있다. DB를 조회했다면 JPA 쿼리 결과가 콘솔에 찍힐테지만, 아무 로그도 찍히지 않고 있다. 시간은 72ms가 소요되었다.

3.3. 새로운 키워드로 요청

 캐싱된 값이 없으니 cache miss가 발생하고 3.1. 최초검색과 비슷한 시간이 소요됨을 확인하였다.

4. 문제

4.1. 건당 Redis 메모리 사용량

redis-cli 의 info memory 명령어를 통해 redis 메모리 사용량을 확인할 수 있다. 확인해보니 시, 도 별로 검색할 경우 한 건당 메모리가 약 1M 정도 사용되었다. 결코 적은 양이 아니다. 만약 시, 도별 다른 키워드로 검색을 한다면 cache miss가 발생하여 데이터를 캐싱할 것이고, 1M 정도가 추가로 사용될 것이었다.

 TTL을 하루로 설정하였기에 RAM 용량이 8GB라면 각기 다른 키워드로 8000번 호출 시 redis 서버가 다운될 가능성이 있다.

4.2. 주소 검색의 특성

주소 검색 특성상 많은 사람들이 똑같은 키워드보다는 본인이 사는 동이나, 지번으로 검색할 확률이 높다. 새로운 키워드가 들어올 확률이 높다는 것이다. cache miss가 빈번하게 발생할 것이고, 응답 시간은 DB를 단독으로 사용하는 것보다 느린 케이스도 빈번할 것이다. redis 메모리 사용량도 빠르게 늘어날 것이다.

5. 개선

 주소 검색 시 선 작업으로 모든 주소를 조회하는 로직을 추가하였다. 그 후 조회한 리스트에서 검색어에 대한 주소 값을 추출하는 방식을 채택했다.

 캐싱은 모든 주소를 조회하는 부분에 적용하였다. cache hit시 리스트에서 필터링하는 시간과 비용만 소비하면 된다. 물론, 첫번째 방식 사용 시보다 응답 속도가 느린 케이스도 있다. TTL이 만료되는 24시간 후 cache miss가 발생할 때 데이터를 가져올때나 동일 키워드로 여러번 검색할때이다. 일단 개선 로직 구현 후 이에 대한 트레이드 오프를 분석할 예정이다.

5.1. 개선 AddressController.kt

...
    @GetMapping("/search")
    fun searchAddress(@MemberAuthentication authenticationAttributes: AuthenticationAttributes
                      , @RequestParam("searchWord") searchWord : String) : ResponseEntity<List<AddressResponse>> {
        val allAddressList = addressService.searchAllAddress()
        val findAddressList = addressService.searchAddress(allAddressList, searchWord)

        return ResponseEntity.ok(findAddressList)
    }
...

 addressService.searchAllAddress() 메서드를 통해 캐싱되어있는 모든 주소리스트를 조회하고, searchAddress() 메서드를 통해 키워드를 포함하는 요소를 찾아 리턴한다.

 searchAddress() 메서드 안에서 searchAllAddress()를 호출할 수 도 있지만, AOP를 사용하는 캐싱 메서드의 특성 상 Self-invocation 이슈가 있어 Controller에서 따로 호출하였다.

5.2. 개선 AddressService.kt

@Service
class AddressService (
    private val addressRepository: AddressRepository
){
    ...

    @Cacheable(value = ["AllAddress"], key = "", cacheManager = "redisCacheManager")
    fun searchAllAddress() : List<AddressResponse> {
        val list = addressRepository.findAll()
        return list.stream()
            .map { e -> AddressResponse(e.id, e.addr) }
            .collect(Collectors.toList())

    }

    fun searchAddress(list : List<AddressResponse>, searchWord: String): List<AddressResponse> {
        return list.stream()
            .filter { address -> address.name.contains(searchWord) }
            .collect(Collectors.toList())
    }
}

 searchAllAddress() 메서드는 DB에서 모든 주소 값을 읽어와 List<AddressResponse> 형태로 리턴하며 캐싱한다. cache miss가 발생 시 시간이 다소 소요된다. searchAddress는 list에 대해 필터링하는 메서드이다.

6. 개선 테스트

6.1. 최초 검색

 1차 테스트와 동일한 검색어로 검색한 결과 cache miss 발생 시 응답속도가 1400 ms 에서 2170 ms로 0.67초 느려진 것을 확인하였다. 모든 주소 값을 읽고, 캐싱하는 부분으로 인한 시간이라 생각한다.

6.2. 두번째 검색

 동일한 키워드로 두번째 검색을 하였다. 전자의 경우 '시'라는 키워드에 대한 결과가 미리 캐싱되어있었기에 소요되는 시간이 조금 더 걸릴것으로 예상했으나, 72ms에서 92ms로 생각보다 시간 차이가 얼마 나지 않음을 알 수 있었다. 몇번 더 테스트해봐도 100ms 안밖이었다.

 cache miss가 발생하지 않았기에 사용되는 메모리는 증가하지 않았다. 참고로 약 9MB 정도를 사용중이다. 이제 다른 키워드로 검색해보자.

6.3. 새로운 키워드로 검색

 서울, 강원 등 여러 키워드로 검색해보았다. 그 결과 걸린 시간은 모두 100ms 안팎임을 확인하였다. 메모리 사용량도 변함이 없다.

7. 장단점

 개선 방식으로의 변경을 통해 확인한 장단점을 정리해보았고, 트레이드 오프를 고려했을 때 개선된 방식이 훨씬 더 효율적이라는 결론을 내렸다.

* 장점

 1. Redis 메모리 부족 위험에 대해 완전히 벗어날 수 있다.

 2. 새로운 키워드로 검색해도 cache miss가 발생하지 않아 속도가 빠르다. (1400 ms > 100ms로 개선)

 3. 동일한 키워드로 검색해도 이전 방식과 속도차이가 거의 나지 않는다. (약 20ms 차이)

* 단점

 1. cache miss 발생 시 이전보다 더 많은 시간이 소요된다. (1400 ms > 2170 ms 로 증가)

 2. 데이터 정합성 문제 발생 확률이 이전보다는 높다. (하지만 쓰기 작업을 연마다 하는 특성 상 큰 문제는 되지 않을 것이라 판단하였다)

8. 회고

 데이터 수정이 없는 주소 데이터 특성에 의해 무작정 캐싱 도입을 하였으나, 큰 성능향상은 얻지 못했고, 오히려 Redis 메모리에 대한 잠재적인 문제와, cache miss 시 속도문제를 안게 되었다. 이건 캐싱에 대한 이해도가 부족해 발생한 것이라 생각하여 개념, 용어, 방법, 전략들을 공부하였다.

 전략을 선택할 때 가장 중요한 건 캐싱할 데이터의 성격을 분석하는 것이라 생각한다. 메모리 용량은 많아봤자 32GB로 제한적이다. 많은 데이터를 캐싱할 수록 메모리의 부담은 커지고, 메모리 부담을 덜기 위해 무작정 TTL을 낮춘다면, 잦은 DB 혹은 API 통신으로 시간이 더 걸릴 수 있다. 만약 특정 키워드로 반복적인 읽기가 많은 작업이었다면 캐싱을 적용하기 전보다 성능이 낮아질수도 있다.

 조회 작업이 많은지, 쓰기 작업이 많은지, 쓰기 작업 없진 않는지, 있다면 그 빈도는 어떤지, 조회만 하는지 등을 분석하여 메모리 사용량을 낮추고, 속도는 비교적 높일 수 있는 캐싱 전략을 세워야 하는데, 이는 캐싱 데이터의 성격에 따라 달라진다.

 주소 검색의 경우 쓰기 전략을 Write Around를, 읽기 전략은 Look Aside로 설정하고 코드를 개선해나갔다. 주로 읽기 작업이고, 쓰기작업은 연 주기로 공공기관을 통해 데이터를 다운받아 DB에 밀어넣는 것 하나이기 때문이다. 또한 쓰기 작업이 되어 새로 등록된 주소는 cache miss가 발생할 때 조회해도 서비스 운영에는 큰 문제가 발생하지 않고, 즉시 조회를 해야 한다고 해도 캐시를 수동으로 만료시키는 방안도 있었다.

 이렇게 데이터의 성격을 파악하고 전략을 수립한 상태에서 리팩토링을 하니 속도와 메모리 효용성을 향상시킬 수 있는 방법을 구상하고 적용할 수 있게 되었다. 캐싱을 적용하는 것은 어렵지 않다. 다만 데이터의 성격을 분석하여 캐싱을 왜 적용하는지, 어느 부분에 적용해야 좋은지, 적용을 통해 얻을 수 있는 장단점은 어떻고, 적절한 트레이드 오프인지를 생각하는 것이 중요하다고 생각한다.