バッチクエリ処理の問題点とその解決策（前編）

ほとんどすべての最新のソフトウェア製品は、複数のサービスで構成されています。 多くの場合、サービス間チャネルの長い応答時間はパフォーマンスの問題の原因になります。 この種の問題に対する標準的な解決策は、複数のサービス間リクエストを XNUMX つのパッケージにパックすることであり、これはバッチ処理と呼ばれます。

バッチ処理を使用する場合、パフォーマンスやコードの明瞭さの点で結果に満足できない場合があります。 この方法は、呼び出し側にとっては思ったほど簡単ではありません。 目的や状況が異なれば、ソリューションは大きく異なります。 具体的な例を使用して、いくつかのアプローチの長所と短所を示します。

実証プロジェクト

わかりやすくするために、現在取り組んでいるアプリケーションのサービスの XNUMX つの例を見てみましょう。

プラットフォーム選定例の説明パフォーマンスの低下の問題は非常に一般的なものであり、特定の言語やプラットフォームには影響しません。 この記事では、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経由で取得されます。 ファイルについても同様です。ファイルとそのメタ情報は、別のファイル ストレージ サービスに存在します。

これらのサービスへのすべての呼び出しは、 重いリクエスト。 これは、これらのリクエストの転送にかかるオーバーヘッドが、サードパーティ サービスによるリクエストの処理にかかる時間よりもはるかに大きいことを意味します。 私たちのテストベンチでは、このようなサービスの一般的な呼び出し時間は 100 ミリ秒であるため、将来的にはこれらの数値を使用する予定です。

必要な情報をすべて含む最後の 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>
}

UI 接尾語は、フロントエンドの DTO モデル、つまり REST 経由で提供すべきものを意味します。

ここで驚くべきことは、チャット ID を渡しておらず、ChatMessage/ChatMessageUI モデルですらチャット ID を持たないことです。 サンプルのコードが乱雑にならないように、これは意図的に行いました (チャットは分離されているため、チャットは XNUMX つだけであると想定できます)。

哲学的な余談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 が XNUMX 回呼び出され、すべての添付ファイルを取得するために FileRemoteApi が XNUMX 回呼び出されます。 それだけのようです。 ChatMessage の forwardFrom フィールドと ReplyTo フィールドが、不必要な呼び出しを必要としない方法で取得されたとします。 ただし、それらを ChatMessageUI に変えると再帰が発生し、呼び出しカウンターが大幅に増加する可能性があります。 前に述べたように、ネストがあまりなく、チェーンが XNUMX つのメッセージに制限されていると仮定しましょう。

その結果、メッセージごとに外部サービスへの呼び出しが 2 ～ 1 回発生し、メッセージのパッケージ全体で JPA 呼び出しが 6 回発生します。 呼び出しの合計数は、1*N+20 から 4*N+10 まで変化します。 これは実際の単位ではいくらですか? ページをレンダリングするのに 500 個のメッセージが必要だとします。 受信には XNUMX 秒から XNUMX 秒かかります。 ひどい！ XNUMXms以内に抑えたいです。 そして、フロントエンドでシームレスなスクロールを実現することを夢見ていたため、このエンドポイントのパフォーマンス要件は XNUMX 倍になる可能性があります。

長所：

1. コードは簡潔で自己文書化されています (サポート チームの夢です)。
2. コードはシンプルなので、足を撃たれる機会はほとんどありません。
3. バッチ処理は異物のようには見えず、ロジックに有機的に統合されています。
4. ロジックの変更は簡単に行われ、ローカルで行われます。

マイナス：

パケットが非常に小さいため、パフォーマンスが低下します。

このアプローチは、単純なサービスやプロトタイプでよく見られます。 変更の速度が重要である場合、システムを複雑にする価値はほとんどありません。 同時に、私たちの非常に単純なサービスのパフォーマンスはひどいものであるため、このアプローチの適用範囲は非常に狭いです。

単純な並列処理

すべてのメッセージの処理を並行して開始できます。これにより、メッセージの数に応じた時間の直線的な増加を避けることができます。 これは外部サービスに大きなピーク負荷をもたらすため、特に良いパスではありません。

並列処理の実装は非常に簡単です。

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

並列メッセージ処理を使用すると、理想的には 300 ～ 700 ミリ秒が得られます。これは単純な実装よりもはるかに優れていますが、それでも十分な速度ではありません。

このアプローチでは、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 ～ 400 ミリ秒が得られますが、これはすでに予想に近い値です。

残念ながら、そのような優れた並列化は存在せず、支払わなければならない代償は非常に残酷です。同時に少数のユーザーだけが作業していると、大量のリクエストがサービスに降りかかり、いずれにしても並列処理されません。悲しい4時代に戻ってしまいます。

このようなサービスを使用した場合の結果は、1300 個のメッセージを処理するのに 1700 ～ 20 ミリ秒でした。 これは最初の実装よりも高速ですが、それでも問題は解決されません。

並列クエリの別の使用法サードパーティのサービスがバッチ処理を提供していない場合はどうなりますか? たとえば、インターフェイス メソッド内のバッチ処理実装の欠如を隠すことができます。

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. サードパーティのサービスの負荷が増加します。

適用範囲は単純なアプローチとほぼ同じであることがわかります。 他者の容赦ない悪用によりサービスのパフォーマンスを数倍向上させたい場合は、並列リクエスト方式を使用するのが合理的です。 この例では、パフォーマンスが 2,5 倍向上しましたが、これでは明らかに十分ではありません。

キャッシング

外部サービスの JPA の精神に基づいてキャッシュを実行できます。つまり、受信したオブジェクトを (バッチ処理中を含む) 再度受信しないようにセッション内に格納します。 このようなキャッシュは自分で作成することも、@Cacheable を備えた Spring を使用することもでき、さらに EhCache のような既製のキャッシュをいつでも手動で使用することもできます。

よくある問題は、キャッシュがヒットした場合にのみ役立つことです。 この場合、作成者フィールドにはヒットする可能性が非常に高くなります (たとえば 50%) が、ファイルにはまったくヒットしません。 このアプローチにより多少の改善は得られますが、パフォーマンスが根本的に変わるわけではありません (ブレークスルーが必要です)。

セッション間 (長い) キャッシュには、複雑な無効化ロジックが必要です。 一般に、セッション間キャッシュを使用してパフォーマンスの問題を解決するのは遅ければ遅いほど良いでしょう。

長所：

1. コードを変更せずにキャッシュを実装します。
2. 生産性が数倍向上しました（場合によっては）。

短所：

1. 誤って使用するとパフォーマンスが低下する可能性があります。
2. 特に長いキャッシュの場合、メモリのオーバーヘッドが大きくなります。
3. 複雑な無効化。実行時に再現が困難な問題を引き起こすエラー。

多くの場合、キャッシュは設計上の問題を迅速に解決するためだけに使用されます。 これは、それらを使用してはいけないという意味ではありません。 ただし、それらを常に慎重に扱い、最初に結果として得られるパフォーマンスの向上を評価してから、決定を下す必要があります。

この例では、キャッシュによりパフォーマンスが約 25% 向上します。 同時に、キャッシュには非常に多くの欠点があるため、ここでは使用しません。

結果

そこで、バッチ処理を使用するサービスの単純な実装と、それを高速化するいくつかの簡単な方法を検討しました。

これらすべての方法の主な利点はその単純さであり、そこから多くの楽しい結果が得られます。

これらの方法に共通する問題は、主にパケットのサイズが原因でパフォーマンスが低下することです。 したがって、これらの解決策があなたに合わない場合は、より根本的な方法を検討する価値があります。

解決策を探すには、主に XNUMX つの方向があります。

• データの非同期作業 (パラダイム シフトが必要なため、この記事では説明しません)。
• 同期処理を維持しながらバッチを拡大します。

バッチを拡大すると、外部呼び出しの数が大幅に減り、同時にコードの同期が維持されます。 記事の次の部分では、このトピックについて説明します。

出所： habr.com