[프로젝트] Busy Waiting 어떻게 개선해볼 수 있을까?

 

문제점

현재 Redis의 List를 이용해서 Queue 방식으로 사용자의 정답 제출 데이터를 입력 받고 있다.

그리고 게임 엔진 서비스는 Redis Queue에 들어온 데이터를 하나씩 꺼내보면서, 정답인지 아닌지 판단하고 결과를 응답해주고 있다.

 

이 과정에서 게임 엔진 서비스는 Queue에 데이터가 있는지 없는지 확인하기 위해 while 문을 돌면서 데이터가 존재하지는지 확인하고 있다.

비효율적으로 Queue 데이터를 가져오는 모습

. . . 생략

while (checkTimeIn(startTime) && notExistWinner) {
    logger.info { "[WARN] busy waiting..." }
    gameAnswerQueueService.poll(roomId, quiz.id)
        ?.takeIf { it.answer == quiz.answer }
        ?.let { result ->
            updateScore(ranking, result.playerId)
            nicknames[result.playerId] = result.nickname
            broadcastResult(destination, result)
            broadcastRanking(ranking, nicknames, destination)
            notExistWinner = false
        }
}

. . . 생략

 

Redis에 데이터가 있는지 매번 조회하는 것은 CPU를 낭비하게 되므로 비효율적일것이라고 생각이 드는데, 다른 방법이 없을지 고민해보았다.

 

 

 

고민1. BLPOP/BRPOP 사용하기

기존에는 Redis의 LPOP, RPOP을 사용해서 Queue 연산을 수해했었다.

이번에는 앞에 B(Blocking)가 붙은 BLPOP, BRPOP으로 바꿔볼 건데, 이름 그대로 블럭킹을 하는것이다.

블럭킹 방식을 사용하면 큐에 데이터가 들어올때까지 대기하다가, 데이터가 들어오면 그때 작업을 수행하게 된다.

이때 대기하는동안에는 CPU를 점유하지 않기 때문에 Busy Wating 방식보다 효율적이다.

 

선착순 처리 - O

Redis가 죽지 않는 이상, 메세지 신뢰성 보장 - O

 

 

 

고민2. PUB/SUB

Redis에서 pub/sub은 메세지를 발생했을 때, 여러명의 subscriber(구독자)가 메세지를 전달받을 수 있다.

Redis pub/sub

 

또한 메세지를 발행한 시점에 해당 메세지 발행 토픽을 구독한 구독자가 없다면, 해당메세지는 사라지게 된다.

Redis pub/sub

 

현재 퀴즈 애플리케이션의 서비스를 생각했을 때, 정답 데이터가 들오면 특정 RoodId의 게임을 담당하는 GameEngineService가 데이터를 전달받게 된다.

 

메세지 발생했을 때 구독한 구독자는 1명(1개의 스레드)이 담당하게 될텐데, pub/sub 구조의 특징이 필요하지는 않을 것 같다.

또한 메세지가 사라질 수 있다는 점에서 Blocking Queue보다 안정성이 떨어질 것 같다고 생각된다.

 

 

 

 

 

최종적으로 Blocking Queue 를 사용한다면 데이터를 pub/sub보다 안정적으로 저장될 수 있을 것 같고, 게임 진행 후 일정시간이 초과후에는 TTL 설정을 통해 삭제할 수 있도록 하면 자원을 효율적으로 사용할 수 있을 것이라고 생각된다.

 

 

개선 후 결과를 확인해 보았는데 아래와 같다.

[]

 

 

느낀점

현재 Redis를 Queue 자료구조 형태로 사용하고 있었고, 비효율적인 코드(Busy Waiting)을 Redis에서 지원해주는 연산만으로 개선해볼 수 있었다.

 

또한 개선되었는지 결과를 간단하게 나마 측정해보았고, 이런 개선점을 찾으며 고민해본 과정과 개선 결과를 확인하려고 한 점에서 좋은 경험이었다고 생각된다.

 

마지막으로 Redis의 데이터를 삽입/삭제하는 연산은 infrastructure 계층을 통해서 인터페이스와 구현체로 분리해놨기 때문에, LPOP 연산을 BLPOP연산으로 교체하는데에 큰 어려움이 들지 않았다.