일괄 쿼리 처리의 문제점과 해결 방법(1부)

거의 모든 최신 소프트웨어 제품은 여러 서비스로 구성됩니다. 종종 서비스 간 채널의 긴 응답 시간이 성능 문제의 원인이 됩니다. 이러한 종류의 문제에 대한 표준 솔루션은 여러 서비스 간 요청을 일괄 처리라고 하는 하나의 패키지로 묶는 것입니다.

일괄 처리를 사용하는 경우 성능이나 코드 명확성 측면에서 결과가 만족스럽지 않을 수 있습니다. 이 방법은 발신자에게 생각만큼 쉽지 않습니다. 다양한 목적과 상황에 따라 솔루션이 크게 달라질 수 있습니다. 구체적인 예를 사용하여 여러 접근 방식의 장단점을 보여 드리겠습니다.

실증 프로젝트

명확성을 위해 현재 작업 중인 애플리케이션의 서비스 중 하나의 예를 살펴보겠습니다.

예시에 대한 플랫폼 선택 설명성능 저하 문제는 매우 일반적이며 특정 언어나 플랫폼과 관련이 없습니다. 이 기사에서는 Spring + Kotlin 코드 예제를 사용하여 문제와 해결 방법을 보여줍니다. Kotlin은 Java 및 C# 개발자가 똑같이 이해하기 쉽습니다(또는 이해하기 어렵습니다). 또한 코드가 Java보다 더 간결하고 이해하기 쉽습니다. 순수 Java 개발자가 이해하기 쉽도록 Kotlin의 흑마술을 피하고 (Lombok의 정신으로) 백마법만 사용하겠습니다. 몇 가지 확장 메서드가 있지만 실제로는 모든 Java 프로그래머에게 정적 메서드로 친숙하므로 이는 요리의 맛을 망치지 않는 작은 설탕이 될 것입니다.
서류승인 서비스가 있습니다. 누군가 문서를 작성하여 토론을 위해 제출하는 동안 편집이 이루어지고 최종적으로 문서에 대한 합의가 이루어집니다. 승인 서비스 자체는 문서에 대해 아무것도 모릅니다. 여기서는 고려하지 않을 작은 추가 기능을 가진 승인자 간의 채팅일 뿐입니다.

따라서 미리 정의된 참가자 집합이 있는 채팅방(문서에 해당)이 있습니다. 일반 채팅과 마찬가지로 메시지에는 텍스트와 파일이 포함되어 있으며 답장이나 전달이 가능합니다.

data class ChatMessage(
  // nullable так как появляется только после persist
  val id: Long? = null,
  /** Ссылка на автора */
  val author: UserReference,
  /** Сообщение */
  val message: String,
  /** Ссылки на аттачи */
  // из-за особенностей связки JPA+СУБД проще поддерживать и null, и пустые списки
  val files: List<FileReference>? = null,
  /** Если является ответом, то здесь будет оригинал */
  val replyTo: ChatMessage? = null,
  /** Если является пересылкой, то здесь будет оригинал */
  val forwardFrom: ChatMessage? = null
)

파일 및 사용자 링크는 다른 도메인에 대한 링크입니다. 여기서 우리는 이렇게 살고 있습니다.

typealias FileReference = Long
typealias UserReference = Long

사용자 데이터는 Keycloak에 저장되고 REST를 통해 수신됩니다. 파일에도 마찬가지입니다. 파일과 그에 대한 메타정보는 별도의 파일 저장 서비스에 있습니다.

이 서비스에 대한 모든 호출은 무거운 요청. 이는 이러한 요청을 전송하는 데 드는 오버헤드가 타사 서비스에서 요청을 처리하는 데 걸리는 시간보다 훨씬 크다는 것을 의미합니다. 테스트 벤치에서 이러한 서비스의 일반적인 호출 시간은 100ms이므로 앞으로 이 숫자를 사용할 것입니다.

필요한 모든 정보가 포함된 마지막 N개 메시지를 수신하려면 간단한 REST 컨트롤러를 만들어야 합니다. 즉, 우리는 프론트엔드의 메시지 모델이 거의 동일하며 모든 데이터를 전송해야 한다고 믿습니다. 프런트엔드 모델의 차이점은 파일과 사용자가 링크를 만들려면 약간 해독된 형식으로 표시되어야 한다는 것입니다.

/** В таком виде отдаются ссылки на сущности для фронта */
data class ReferenceUI(
  /** Идентификатор для url */
  val ref: String,
  /** Видимое пользователю название ссылки */
  val name: String
)
data class ChatMessageUI(
  val id: Long,
  /** Ссылка на автора */
  val author: ReferenceUI,
  /** Сообщение */
  val message: String,
  /** Ссылки на аттачи */
  val files: List<ReferenceUI>,
  /** Если являтся ответом, то здесь будет оригинал */
  val replyTo: ChatMessageUI? = null,
  /** Если являтся пересылкой, то здесь будет оригинал */
  val forwardFrom: ChatMessageUI? = null
)

우리는 다음을 구현해야 합니다:

interface ChatRestApi {
  fun getLast(n: Int): List<ChatMessageUI>
}

Postfix UI는 프런트엔드용 DTO 모델, 즉 REST를 통해 제공해야 하는 모델을 의미합니다.

여기서 놀라운 점은 채팅 식별자를 전달하지 않고 ChatMessage/ChatMessageUI 모델에도 아무 것도 전달하지 않는다는 것입니다. 나는 예제의 코드를 복잡하게 하지 않기 위해 의도적으로 이렇게 했습니다(채팅은 분리되어 있으므로 하나만 있다고 가정할 수 있습니다).

철학적 여담ChatMessageUI 클래스와 ChatRestApi.getLast 메소드 모두 실제로는 순서가 지정된 Set인 List 데이터 유형을 사용합니다. JDK에서는 이것이 모두 좋지 않으므로 인터페이스 수준에서 요소 순서를 선언하는 것(추가 및 검색 시 순서 유지)은 작동하지 않습니다. 따라서 순서가 지정된 Set이 필요한 경우 List를 사용하는 것이 일반적인 관행이 되었습니다(LinkedHashSet도 있지만 이는 인터페이스가 아닙니다).
중요한 제한사항: 우리는 긴 응답이나 전송 체인이 없다고 가정합니다. 즉, 존재하지만 길이가 XNUMX개 메시지를 초과하지 않습니다. 전체 메시지 체인이 프런트엔드로 전송되어야 합니다.

외부 서비스로부터 데이터를 수신하려면 다음 API가 있습니다.

interface ChatMessageRepository {
  fun findLast(n: Int): List<ChatMessage>
}
data class FileHeadRemote(
  val id: FileReference,
  val name: String
)
interface FileRemoteApi {
  fun getHeadById(id: FileReference): FileHeadRemote
  fun getHeadsByIds(id: Set<FileReference>): Set<FileHeadRemote>
  fun getHeadsByIds(id: List<FileReference>): List<FileHeadRemote>
  fun getHeadsByChat(): List<FileHeadRemote>
}
data class UserRemote(
  val id: UserReference,
  val name: String
)
interface UserRemoteApi {
  fun getUserById(id: UserReference): UserRemote
  fun getUsersByIds(id: Set<UserReference>): Set<UserRemote>
  fun getUsersByIds(id: List<UserReference>): List<UserRemote>
}

외부 서비스는 처음에 일괄 처리를 제공하고 두 변형 모두에서 Set(요소 순서를 유지하지 않고 고유 키 사용)과 List(중복이 있을 수 있음 - 순서가 유지됨)를 통해 제공되는 것을 볼 수 있습니다.

간단한 구현

순진한 구현

REST 컨트롤러의 첫 번째 순진한 구현은 대부분의 경우 다음과 같습니다.

class ChatRestController(
  private val messageRepository: ChatMessageRepository,
  private val userRepository: UserRemoteApi,
  private val fileRepository: FileRemoteApi
) : ChatRestApi {
  override fun getLast(n: Int) =
    messageRepository.findLast(n)
      .map { it.toFrontModel() }
  
  private fun ChatMessage.toFrontModel(): ChatMessageUI =
    ChatMessageUI(
      id = id ?: throw IllegalStateException("$this must be persisted"),
      author = userRepository.getUserById(author).toFrontReference(),
      message = message,
      files = files?.let { files ->
        fileRepository.getHeadsByIds(files)
          .map { it.toFrontReference() }
      } ?: listOf(),
      forwardFrom = forwardFrom?.toFrontModel(),
      replyTo = replyTo?.toFrontModel()
    )
}

모든 것이 매우 명확하며 이는 큰 장점입니다.

우리는 일괄 처리를 사용하고 일괄적으로 외부 서비스로부터 데이터를 받습니다. 그런데 우리의 생산성에는 무슨 일이 일어나고 있는 걸까요?

각 메시지에 대해 UserRemoteApi를 한 번 호출하여 작성자 필드의 데이터를 가져오고 FileRemoteApi를 한 번 호출하여 모든 첨부 파일을 가져옵니다. 그런 것 같습니다. 불필요한 호출이 필요하지 않은 방식으로 ChatMessage의 전달 및 응답 필드가 획득되었다고 가정해 보겠습니다. 그러나 이를 ChatMessageUI로 바꾸면 재귀가 발생합니다. 즉, 통화 카운터가 크게 늘어날 수 있습니다. 앞서 언급했듯이 중첩이 많지 않고 체인이 메시지 XNUMX개로 제한되어 있다고 가정해 보겠습니다.

결과적으로 메시지당 외부 서비스에 대한 2~1개의 호출과 전체 메시지 패키지에 대한 6개의 JPA 호출을 받게 됩니다. 총 호출 수는 1*N+20에서 4*N+10까지 다양합니다. 실제 단위로 얼마인가요? 한 페이지를 렌더링하는 데 500개의 메시지가 필요하다고 가정해 보겠습니다. 그것을 얻으려면 XNUMX 초에서 XNUMX 초가 필요합니다. 끔찍한! XNUMXms 이내로 유지하고 싶습니다. 그리고 프런트엔드에서 원활한 스크롤을 원했기 때문에 이 엔드포인트에 대한 성능 요구 사항이 두 배로 늘어날 수 있습니다.

장점 :

1. 코드는 간결하고 자체 문서화됩니다(지원 팀의 꿈).
2. 코드가 간단해서 발에 총을 쏠 기회가 거의 없습니다.
3. 일괄 처리는 이질적인 것처럼 보이지 않으며 논리에 유기적으로 통합되어 있습니다.
4. 논리 변경은 쉽게 수행할 수 있으며 로컬에서 수행됩니다.

빼기 :

매우 작은 패킷으로 인해 성능이 저하됩니다.

이러한 접근 방식은 간단한 서비스나 프로토타입에서 자주 볼 수 있습니다. 변경 속도가 중요하다면 시스템을 복잡하게 만들 가치가 거의 없습니다. 동시에, 매우 간단한 서비스의 경우 성능이 형편없기 때문에 이 접근 방식의 적용 범위가 매우 좁습니다.

순진한 병렬 처리

모든 메시지 처리를 병렬로 시작할 수 있습니다. 이렇게 하면 메시지 수에 따른 선형적인 시간 증가를 없앨 수 있습니다. 이는 외부 서비스에 큰 최대 부하를 초래하므로 특별히 좋은 경로는 아닙니다.

병렬 처리를 구현하는 것은 매우 간단합니다.

override fun getLast(n: Int) =
  messageRepository.findLast(n).parallelStream()
    .map { it.toFrontModel() }
    .collect(toList())

병렬 메시지 처리를 사용하면 이상적으로는 300~700ms를 얻을 수 있습니다. 이는 순진한 구현보다 훨씬 낫지만 여전히 충분히 빠르지는 않습니다.

이 접근 방식을 사용하면 userRepository 및 fileRepository에 대한 요청이 동기적으로 실행되므로 그다지 효율적이지 않습니다. 이 문제를 해결하려면 호출 논리를 상당히 많이 변경해야 합니다. 예를 들어 CompletionStage(CompletableFuture라고도 함)를 통해 다음을 수행합니다.

private fun ChatMessage.toFrontModel(): ChatMessageUI =
  CompletableFuture.supplyAsync {
    userRepository.getUserById(author).toFrontReference()
  }.thenCombine(
    files?.let {
      CompletableFuture.supplyAsync {
        fileRepository.getHeadsByIds(files).map { it.toFrontReference() }
      }
    } ?: CompletableFuture.completedFuture(listOf())
  ) { author, files ->
    ChatMessageUI(
      id = id ?: throw IllegalStateException("$this must be persisted"),
      author = author,
      message = message,
      files = files,
      forwardFrom = forwardFrom?.toFrontModel(),
      replyTo = replyTo?.toFrontModel()
    )
  }.get()!!

처음에는 단순했던 매핑 코드가 이해하기 어려워진 것을 볼 수 있습니다. 결과가 사용되는 곳과 외부 서비스에 대한 호출을 분리해야 했기 때문입니다. 이것 자체는 나쁘지 않습니다. 그러나 통화 결합은 특별히 우아해 보이지 않으며 일반적인 반응형 "국수"와 유사합니다.

코루틴을 사용하면 모든 것이 더 괜찮아 보일 것입니다.

private fun ChatMessage.toFrontModel(): ChatMessageUI =
  join(
    { userRepository.getUserById(author).toFrontReference() },
    { files?.let { fileRepository.getHeadsByIds(files)
      .map { it.toFrontReference() } } ?: listOf() }
  ).let { (author, files) ->
    ChatMessageUI(
      id = id ?: throw IllegalStateException("$this must be persisted"),
      author = author,
      message = message,
      files = files,
      forwardFrom = forwardFrom?.toFrontModel(),
      replyTo = replyTo?.toFrontModel()
    )
  }

장소 :

fun <A, B> join(a: () -> A, b: () -> B) =
  runBlocking(IO) {
    awaitAll(async { a() }, async { b() })
  }.let {
    it[0] as A to it[1] as B
  }

이론적으로 이러한 병렬 처리를 사용하면 200~400ms를 얻을 수 있으며 이는 이미 기대치에 가깝습니다.

불행하게도 이러한 좋은 병렬화는 이루어지지 않으며 지불해야 할 대가는 매우 잔인합니다. 동시에 작업하는 사용자가 소수에 불과하면 서비스에 요청이 너무 많아서 병렬로 처리되지 않을 수 있습니다. 우리의 슬픈 4s로 돌아갈 것이다.

이러한 서비스를 사용할 때의 결과는 1300개의 메시지를 처리하는 데 1700~20ms입니다. 이는 첫 번째 구현보다 빠르지만 여전히 문제가 해결되지는 않습니다.

병렬 쿼리의 대체 용도타사 서비스가 일괄 처리를 제공하지 않으면 어떻게 되나요? 예를 들어, 인터페이스 메소드 내에서 일괄 처리 구현 부족을 숨길 수 있습니다.

interface UserRemoteApi {
  fun getUserById(id: UserReference): UserRemote
  fun getUsersByIds(id: Set<UserReference>): Set<UserRemote> =
    id.parallelStream()
      .map { getUserById(it) }.collect(toSet())
  fun getUsersByIds(id: List<UserReference>): List<UserRemote> =
    id.parallelStream()
      .map { getUserById(it) }.collect(toList())
}

향후 버전에서 일괄 처리를 원할 경우 이는 의미가 있습니다.
장점 :

1. 메시지 기반 병렬 처리를 쉽게 구현합니다.
2. 확장성이 좋습니다.

단점 :

1. 다양한 서비스에 대한 요청을 병렬로 처리할 때 데이터 수집과 처리를 분리해야 합니다.
2. 타사 서비스에 대한 부하가 증가했습니다.

적용 범위는 naive 접근 방식과 거의 동일함을 알 수 있다. 타인의 무자비한 착취로 인해 서비스 성능을 여러 번 높이려면 병렬 요청 방법을 사용하는 것이 좋습니다. 이 예에서는 생산성이 2,5배 증가했지만 이것만으로는 충분하지 않습니다.

캐싱

외부 서비스에 대해 JPA 정신으로 캐싱을 수행할 수 있습니다. 즉, 수신된 객체를 다시 수신하지 않도록(일괄 처리 중 포함) 세션 내에 저장하는 것입니다. 이러한 캐시를 직접 만들 수 있고 @Cacheable과 함께 Spring을 사용할 수 있으며 EhCache와 같은 미리 만들어진 캐시를 항상 수동으로 사용할 수 있습니다.

일반적인 문제는 캐시가 히트가 있는 경우에만 유용하다는 것입니다. 우리의 경우 작성자 필드에 대한 조회가 발생할 가능성이 매우 높지만(가령 50%) 파일에 대한 조회는 전혀 없습니다. 이 접근 방식은 일부 개선을 제공하지만 생산성을 근본적으로 변화시키지는 않습니다(그리고 획기적인 발전이 필요합니다).

세션 간(긴) 캐시에는 복잡한 무효화 논리가 필요합니다. 일반적으로 세션 간 캐시를 사용하여 성능 문제를 나중에 해결할수록 좋습니다.

장점 :

1. 코드를 변경하지 않고 캐싱을 구현합니다.
2. 생산성이 여러 번 향상되었습니다(경우에 따라).

단점 :

1. 잘못 사용하면 성능이 저하될 가능성이 있습니다.
2. 특히 긴 캐시의 경우 메모리 오버헤드가 큽니다.
3. 복잡한 무효화, 런타임 시 재현하기 어려운 문제로 이어지는 오류입니다.

캐시는 설계 문제를 신속하게 해결하는 데에만 사용되는 경우가 많습니다. 그렇다고해서 사용해서는 안된다는 의미는 아닙니다. 그러나 항상 주의해서 다루어야 하며 먼저 결과적인 성능 향상을 평가한 다음 결정을 내려야 합니다.

이 예에서 캐시는 약 25%의 성능 향상을 제공합니다. 동시에 캐시에는 단점이 많이 있으므로 여기서는 사용하지 않겠습니다.

결과

그래서 우리는 일괄 처리를 사용하는 서비스의 단순한 구현과 속도를 높이는 몇 가지 간단한 방법을 살펴보았습니다.

이 모든 방법의 가장 큰 장점은 단순성이며 이로 인해 많은 즐거운 결과가 발생합니다.

이러한 방법의 일반적인 문제는 주로 패킷 크기와 관련된 성능 저하입니다. 따라서 이러한 솔루션이 귀하에게 적합하지 않다면보다 근본적인 방법을 고려해 볼 가치가 있습니다.

솔루션을 찾을 수 있는 두 가지 주요 방향은 다음과 같습니다.

• 데이터를 사용한 비동기 작업(패러다임 전환이 필요하므로 이 기사에서는 논의하지 않음)
• 동기 처리를 유지하면서 배치를 확대합니다.

배치를 확대하면 외부 호출 수가 크게 줄어들고 동시에 코드 동기가 유지됩니다. 기사의 다음 부분은 이 주제에 대해 다룰 것입니다.

출처 : habr.com