TiDB性能チューニングの概要

このドキュメントでは、ユーザー応答時間、スループット、データベース時間などのパフォーマンスチューニングの基本的な概念を紹介し、パフォーマンスチューニングの一般的なプロセスについても説明します。

ユーザー応答時間とデータベース時間

ユーザー応答時間

ユーザー応答時間とは、アプリケーションがリクエストの結果をユーザーに返すまでにかかる時間を指します。以下のシーケンシャルタイミング図からわかるように、典型的なユーザーリクエストの時間には、以下の要素が含まれます。

ユーザーとアプリケーション間のネットワークレイテンシー
申請の処理時間
アプリケーションとデータベース間のやり取り中のネットワークレイテンシー
データベースのサービス時間

ユーザー応答時間は、ネットワークのレイテンシーや帯域幅、同時ユーザーの数やリクエストの種類、サーバーのCPUやI/Oリソースの使用率など、リクエストチェーン上の様々なサブシステムの影響を受けます。システム全体を効果的に最適化するには、まずユーザー応答時間のボトルネックを特定する必要があります。

指定された時間範囲（ ΔT ）内のユーザー応答時間の合計を取得するには、次の数式を使用します。

ΔTでの合計ユーザー応答時間 = 平均 TPS (1 秒あたりのトランザクション数) x 平均ユーザー応答時間 x ΔT 。

user_response_time

データベース時間

データベース時間は、データベースが提供するサービス時間の合計を示します。1 ΔTデータベース時間は、データベースがすべてのアプリケーション要求を同時に処理するのにかかる時間の合計です。

データベースの時間を取得するには、次のいずれかの方法を使用できます。

方法1：平均クエリレイテンシーにQPSとΔTを掛け合わせると、 DB Time in ΔT = QPS × avg latency × ΔT
方法2: アクティブセッションの平均数にΔTを掛ける（つまりDB Time in ΔT = avg active connections × ΔT
方法3: TiDB内部のPrometheusメトリックtidb_server_tokensに基づいて時間を計算しますΔT DB Time = rate(tidb_server_tokens) × ΔT

ユーザー応答時間とシステムスループットの関係

ユーザー応答時間は、サービス時間、キュー時間、およびユーザー要求を完了するための同時待機時間で構成されます。

User Response time = Service time + Queuing delay + Coherency delay

サービス時間: リクエストを処理するときにシステムが特定のリソースに消費する時間。たとえば、データベースが SQL リクエストを完了するために消費する CPU 時間など。
キューイング遅延: システムが要求を処理するときに、特定のリソースのサービスをキューで待機する時間。
一貫性遅延: システムがリクエストを処理するときに共有リソースにアクセスできるように、他の同時タスクと通信して連携する時間。

システムスループットとは、システムが1秒間に処理できるリクエストの数を指します。ユーザー応答時間とスループットは通常、反比例関係にあります。スループットが増加すると、システムリソースの使用率と、要求されたサービスのキューイングレイテンシーもそれに応じて増加します。リソース使用率が一定の変曲点を超えると、キューイングレイテンシーは劇的に増加します。

例えば、OLTP負荷を実行しているデータベースシステムでは、CPU使用率が65%を超えると、CPUキューイングとスケジューリングのレイテンシーが大幅に増加します。これは、システムの同時リクエストが完全に独立していないため、これらのリクエストが連携して共有リソースを奪い合う可能性があるためです。例えば、異なるユーザーからのリクエストが、同じデータに対して相互に排他的なロック操作を実行する場合があります。リソース使用率が増加すると、キューイングとスケジューリングのレイテンシーも増加し、共有リソースが時間内に解放されず、他のタスクによる共有リソースの待機時間が長くなります。

パフォーマンスチューニングプロセス

パフォーマンスチューニングプロセスは、次の 6 つのステップで構成されます。

チューニング目標を定義します。
パフォーマンスベースラインを確立します。
ユーザー応答時間のボトルネックを特定します。
チューニングソリューションを提案し、各ソリューションの利点、リスク、コストを評価します。
チューニングソリューションを実装します。
チューニング結果を評価します。

パフォーマンスチューニングプロジェクトのチューニング目標を達成するには、通常、手順 2 から手順 6 を複数回繰り返す必要があります。

ステップ1. チューニング目標を定義する

システムの種類によって、チューニングの目的も異なります。例えば、金融コアのOLTPシステムの場合、チューニングの目的はトランザクションのロングテールレイテンシーの削減となるでしょう。一方、金融決済システムの場合、チューニングの目的はハードウェアリソースの有効活用とバッチ決済タスクの時間の短縮となるでしょう。

適切なチューニング目標は、簡単に定量化できるものでなければなりません。例えば、

適切なチューニング目標: 午前 9 時から午前 10 時までの営業時間のピーク時に、転送トランザクションの p99レイテンシーが200 ミリ秒未満である必要があります。
チューニング目標が不十分: システムの応答が遅すぎるため、最適化する必要があります。

明確なチューニング目標を定義すると、後続のパフォーマンスチューニング手順のガイドに役立ちます。

ステップ2. パフォーマンスのベースラインを確立する

パフォーマンスを効率的にチューニングするには、現在のパフォーマンスデータを取得してパフォーマンスのベースラインを確立する必要があります。取得するパフォーマンスデータには通常、以下のものが含まれます。

ユーザー応答時間の平均値とロングテール値、およびアプリケーションのスループット
データベース時間、クエリのレイテンシー、QPSなどのデータベースパフォーマンスデータ
TiDB 継続的なパフォーマンスプロファイリング、スロークエリログといった様々な次元でパフォーマンスデータを徹底的に測定・保存します。さらに、Prometheusに保存されたタイミングメトリクスデータの履歴交通ビジュアライザー遡って比較することTop SQL可能です。
CPU、IO、ネットワークなどのリソース使用率
アプリケーション構成、データベース構成、オペレーティングシステム構成などのコンフィグレーション情報

ステップ3. ユーザー応答時間のボトルネックを特定する

パフォーマンスベースラインのデータに基づいて、ユーザー応答時間のボトルネックを特定または推測します。

アプリケーションは通常、ユーザーリクエストの完全なチェーンを測定および記録しないため、アプリケーション全体でユーザー応答時間を上から下まで効果的に細分化することはできません。

一方、データベースには、クエリのレイテンシーやスループットといったパフォーマンス指標の完全な記録が存在します。データベース時間に基づいて、ユーザー応答時間のボトルネックがデータベースにあるかどうかを判断できます。

ボトルネックがデータベースにない場合は、データベース外で収集されたリソース使用率に頼るか、アプリケーションのプロファイリングを行ってデータベース外のボトルネックを特定する必要があります。一般的なシナリオとしては、アプリケーションまたはプロキシサーバーのリソース不足、アプリケーション内のシリアルポイントに起因するハードウェアリソースの使用不足などが挙げられます。
ボトルネックがデータベースにある場合は、包括的なチューニングツールを使用してデータベースのパフォーマンスを分析・診断できます。一般的なシナリオとしては、低速なSQL、アプリケーションによるデータベースの不適切な使用、データベースの読み取りおよび書き込みのホットスポットの存在などが挙げられます。

分析および診断方法とツールの詳細については、パフォーマンス分析とチューニング参照してください。

ステップ4. チューニングソリューションを提案し、各ソリューションの利点、リスク、コストを評価する

パフォーマンス分析を通じてシステムのボトルネックを特定した後、実際の状況に基づいて、コスト効率が高く、リスクが低く、最大のメリットをもたらすチューニングソリューションを提案できます。

アムダールの法則によると、パフォーマンスチューニングによる最大の効果は、システム全体における最適化された部分の割合に依存します。したがって、パフォーマンスデータに基づいてシステムのボトルネックとその割合を特定し、ボトルネックを解決または最適化した後の効果を予測する必要があります。

たとえ最大のボトルネックを調整することで最大の潜在的メリットが得られるソリューションであっても、そのソリューションのリスクとコストを評価する必要があることに注意してください。例えば、

リソースが過負荷になっているシステムに対する最も簡単なチューニング目標ソリューションは、システムの容量を拡張することですが、実際には、拡張ソリューションはコストがかかりすぎて採用できない可能性があります。
ビジネスモジュール内の低速クエリが原因でモジュール全体のレスポンスが遅くなる場合、データベースを新しいバージョンにアップグレードすることで低速クエリの問題を解決できますが、これまでこの問題が発生していなかったモジュールにも影響が及ぶ可能性があります。そのため、この解決策は潜在的に高いリスクを伴う可能性があります。リスクの低い解決策としては、データベースのバージョンアップグレードを省略し、既存の低速クエリを現在のデータベースバージョンに合わせて書き換えることが挙げられます。

ステップ5. チューニングソリューションを実装する

メリット、リスク、コストを考慮し、実装するチューニングソリューションを1つ以上選択してください。実装プロセスでは、本番システムへの変更について綿密な準備を行い、変更内容を詳細に記録する必要があります。

チューニングソリューションのリスクを軽減し、そのメリットを検証するためには、テスト環境とステージング環境の両方で変更の検証と回帰テストを実施することをお勧めします。例えば、遅いクエリのチューニングソリューションとして、クエリアクセスパスを最適化するための新しいインデックスを作成する場合、新しいインデックスによって既存のデータ挿入ワークロードに明らかな書き込みホットスポットが生じず、他のモジュールの速度低下を招かないようにする必要があります。

ステップ6. チューニング結果を評価する

チューニングソリューションを適用した後、結果を評価する必要があります。

チューニング目標が達成されると、チューニングプロジェクト全体が正常に完了します。
チューニング目標が達成されない場合は、チューニング目標が達成されるまで、このドキュメントの手順 2 から手順 6 を繰り返す必要があります。

チューニングの目標を達成した後、ビジネスの成長に合わせてシステム容量をさらに計画する必要がある場合があります。