重要

このページは英語版のページを機械翻訳しています。原文はこちらからご覧ください。

パブリッククラウドにおける TiDB のベストプラクティス

パブリッククラウドインフラストラクチャは、TiDB の導入と管理の選択肢としてますます人気が高まっています。ただし、パブリッククラウドに TiDB を導入するには、パフォーマンスチューニング、コストの最適化、信頼性、スケーラビリティなど、いくつかの重要な要素を慎重に考慮する必要があります。

このドキュメントでは、KV RocksDB での圧縮 I/O フローの削減、 Raft Engine専用のディスクの使用、AZ 間トラフィックのコストの最適化、Google Cloud ライブマイグレーションイベントの緩和、大規模クラスタでの PDサーバーの微調整など、パブリッククラウドに TiDB をデプロイするためのさまざまな重要なベストプラクティスについて説明します。これらのベストプラクティスに従うことで、パブリッククラウドでの TiDB デプロイのパフォーマンス、コスト効率、信頼性、スケーラビリティを最大限に高めることができます。

KV RocksDB の圧縮 I/O フローを削減

TiKV のstorageエンジンとして、ロックスDBユーザーデータの保存に使用されます。クラウド EBS にプロビジョニングされた IO スループットは、通常、コスト上の理由から制限されるため、RocksDB は高い書き込み増幅を示し、ディスクスループットがワークロードのボトルネックになる可能性があります。その結果、保留中の圧縮バイトの総数は時間の経過とともに増加し、フロー制御がトリガーされます。これは、TiKV がフォアグラウンド書き込みフローに対応するのに十分なディスク帯域幅を持っていないことを示しています。

ディスクスループットの制限によって生じるボトルネックを軽減するには、パフォーマンスをTitanを有効にする向上させることができます。平均行サイズが 512 バイト未満の場合、Titan は適用できません。この場合、パフォーマンスをすべての圧縮レベルを上げる向上させることができます。

タイタンを有効にする

タイタンは、キーと値の分離のための高性能なロックスDBプラグインであり、大きな値が使用される場合に RocksDB での書き込み増幅を減らすことができます。

平均行サイズが 512 バイトより大きい場合は、次のようにmin-blob-size "512B"または"1KB"に設定し、 blob-file-compression "zstd"に設定して、Titan を有効にして圧縮 I/O フローを削減できます。

[rocksdb.titan]
enabled = true
[rocksdb.defaultcf.titan]
min-blob-size = "1KB"
blob-file-compression = "zstd"

注記：
Titan を有効にすると、主キーの範囲スキャンのパフォーマンスが若干低下する可能性があります。詳細については、 min-blob-sizeがパフォーマンスに与える影響参照してください。

すべての圧縮レベルを上げる

平均行サイズが 512 バイトより小さい場合は、次のようにして、デフォルトのカラムファミリーのすべての圧縮レベルを"zstd"に増やすことができます。

[rocksdb.defaultcf]
compression-per-level = ["zstd", "zstd", "zstd", "zstd", "zstd", "zstd", "zstd"]

Raft Engine専用のディスクを使用する

TiKV のRaft Engineは、従来のデータベースの先行書き込みログ (WAL) と同様の重要な役割を果たします。最適なパフォーマンスと安定性を実現するには、パブリッククラウドに TiDB を展開するときに、 Raft Engine専用のディスクを割り当てることが重要です。次のiostat 、書き込み負荷の高いワークロードを持つ TiKV ノードの I/O 特性を示しています。

Device            r/s     rkB/s       w/s     wkB/s      f/s  aqu-sz  %util
sdb           1649.00 209030.67   1293.33 304644.00    13.33    5.09  48.37
sdd           1033.00   4132.00   1141.33  31685.33   571.00    0.94 100.00

デバイスsdbは KV RocksDB に使用され、 sdd Raft Engineログの復元に使用されます。5 には、デバイスの 1 秒あたりに完了したフラッシュ要求の数を表すsdd f/s値が大幅に高いことに注意してください。Raft Raft Engineでは、バッチ内の書き込みが同期としてマークされている場合、バッチリーダーは書き込み後にfdatasync()呼び出し、バッファリングされたデータがstorageにフラッシュされることを保証します。Raft Raft Engine専用のディスクを使用することで、TiKV は要求の平均キュー長を短縮し、最適で安定した書き込みレイテンシーを保証します。

クラウドプロバイダーによって、IOPS や MBPS などのパフォーマンス特性が異なるさまざまなディスクタイプが提供されています。したがって、ワークロードに基づいて適切なクラウドプロバイダー、ディスクタイプ、ディスクサイズを選択することが重要です。

パブリッククラウド上のRaft Engineに適したディスクを選択する

このセクションでは、さまざまなパブリッククラウド上のRaft Engineに適したディスクを選択するためのベストプラクティスについて説明します。パフォーマンス要件に応じて、2 種類の推奨ディスクが利用可能です。

ミドルレンジディスク

さまざまなパブリッククラウドに推奨されるミドルレンジディスクは次のとおりです。

AWS では、 GP3 の推奨されます。gp3 ボリュームは、ボリュームサイズに関係なく、3000 IOPS と 125 MB/秒のスループットの無料割り当てを提供し、通常はRaft Engineには十分です。
Google Cloud では、 pd-ssd推奨されています。IOPS と MBPS は、割り当てられたディスクサイズによって異なります。パフォーマンス要件を満たすには、 Raft Engineに 200 GB を割り当てることをお勧めします。Raft Raft Engine はそれほど大きなスペースを必要としませんが、最適なパフォーマンスを保証します。
Azure では、プレミアム SSD v2推奨されます。AWS gp3 と同様に、Premium SSD v2 はボリュームサイズに関係なく、3000 IOPS と 125 MB/秒のスループットの無料割り当てを提供し、通常はRaft Engineには十分です。

ハイエンドディスク

Raft Engineのレイテンシーをさらに低くしたい場合は、ハイエンドディスクの使用を検討してください。以下は、さまざまなパブリッククラウドに推奨されるハイエンドディスクです。

AWS ではio2推奨されます。ディスクサイズと IOPS は、特定の要件に応じてプロビジョニングできます。
Google Cloud では、 pd-エクストリーム推奨されます。ディスクサイズ、IOPS、MBPS をプロビジョニングできますが、64 個を超える CPU コアを持つインスタンスでのみ使用できます。
Azure では、ウルトラディスク推奨されます。ディスクサイズ、IOPS、および MBPS は、特定の要件に応じてプロビジョニングできます。

AWS は、20 GB GP3 のボリュームに対して 3000 IOPS と 125 MBPS/秒を提供します。

書き込み集中型のソーシャルネットワークアプリケーションワークロードに AWS 上の専用の 20 GB GP3 の Raft Engineディスクを使用すると、次のような改善が見られますが、推定コストはわずか 0.4% しか増加しません。

QPS（1秒あたりのクエリ数）が17.5%増加
挿入文の平均レイテンシーが18.7%減少
挿入ステートメントの p99レイテンシーが 45.6% 減少しました。

メトリック	共有Raft Engineディスク	専用Raft Engineディスク	違い（％）
QPS (K/秒)	8.0	9.4	17.5
平均挿入遅延時間 (ミリ秒)	11.3	9.2	-18.7
P99 挿入遅延 (ms)	29.4	16.0	-45.6

例 2: Azure で TPC-C/Sysbench ワークロードを実行する

Azure 上のRaft Engineに専用の 32 GB ウルトラディスク使用すると、次の改善が見られます。

Sysbench oltp_read_writeワークロード: QPS が 17.8% 増加し、平均レイテンシーが 15.6% 減少しました。
TPC-C ワークロード: QPS が 27.6% 増加し、平均レイテンシーが 23.1% 減少しました。

メトリック	作業負荷	共有Raft Engineディスク	専用Raft Engineディスク	違い（％）
QPS (K/秒)	システムベンチ`oltp_read_write`	60.7	71.5	17.8
QPS (K/秒)	TPC-C	23.9	30.5	27.6
平均レイテンシ（ミリ秒）	システムベンチ`oltp_read_write`	4.5	3.8	-15.6
平均レイテンシ（ミリ秒）	TPC-C	3.9	3.0	-23.1

例 3: TiKV マニフェストのRaft Engine用に Google Cloud に専用の pd-ssd ディスクを接続する

次の TiKV 構成例は、 TiDB Operatorによってデプロイされた Google Cloud 上のクラスタに追加の 512 GB pd-ssdディスクを接続し、この特定のディスクにRaft Engineログを保存するようにraft-engine.dir構成する方法を示しています。

tikv:
    config: |
      [raft-engine]
        dir = "/var/lib/raft-pv-ssd/raft-engine"
        enable = true
        enable-log-recycle = true
    requests:
      storage: 4Ti
    storageClassName: pd-ssd
    storageVolumes:
    - mountPath: /var/lib/raft-pv-ssd
      name: raft-pv-ssd
      storageSize: 512Gi

AZ間ネットワークトラフィックのコストを最適化する

複数のアベイラビリティゾーン (AZ) にわたって TiDB を展開すると、AZ 間のデータ転送料金によりコストが増加する可能性があります。コストを最適化するには、AZ 間のネットワークトラフィックを削減することが重要です。

AZ 間の読み取りトラフィックを削減するには、 Follower Read機能を有効にします。これにより、TiDB は同じアベイラビリティーゾーン内のレプリカの選択を優先できます。この機能を有効にするには、 tidb_replica_read変数をclosest-replicasまたはclosest-adaptiveに設定します。

TiKV インスタンスの AZ 間書き込みトラフィックを削減するには、データをネットワーク経由で送信する前に圧縮する gRPC 圧縮機能を有効にします。次の設定例は、TiKV で gzip gRPC 圧縮を有効にする方法を示しています。

server_configs:
  tikv:
    server.grpc-compression-type: gzip

TiFlash MPP タスクのデータシャッフルによって発生するネットワークトラフィックを削減するには、同じアベイラビリティゾーン (AZ) に複数のTiFlashインスタンスをデプロイすることをお勧めします。v6.6.0 以降では、デフォルトで圧縮交換有効になっており、MPP データシャッフルによって発生するネットワークトラフィックが削減されます。

Google Cloud でのライブマイグレーションメンテナンスイベントを軽減する

Google Cloud のライブマイグレーション機能使用すると、ダウンタイムを発生させることなく、ホスト間で VM をシームレスに移行できます。ただし、これらの移行イベントは、頻度は低いものの、TiDB クラスタで実行されている VM を含む VM のパフォーマンスに大きな影響を与える可能性があります。このようなイベントが発生すると、影響を受ける VM のパフォーマンスが低下し、TiDB クラスタでのクエリ処理時間が長くなる可能性があります。

Google Cloud によって開始されたライブマイグレーションイベントを検出し、これらのイベントによるパフォーマンスへの影響を軽減するために、TiDB は Google のメタデータ例に基づいたスクリプトを見る提供します。このスクリプトを TiDB、TiKV、PD ノードにデプロイして、メンテナンスイベントを検出できます。メンテナンスイベントが検出されると、中断を最小限に抑え、クラスタの動作を最適化するために、次のように適切なアクションが自動的に実行されます。

TiDB: TiDB ノードをオフラインにし、TiDB ポッドを削除します。これは、TiDB インスタンスのノードプールが自動スケールに設定され、TiDB 専用になっていることを前提としています。ノードで実行されている他のポッドで中断が発生する可能性があり、閉鎖されたノードは自動スケーラーによって再利用されることが予想されます。
TiKV: メンテナンス中に影響を受ける TiKV ストアのリーダーを削除します。
PD: 現在の PD インスタンスが PD リーダーである場合、リーダーを辞任します。

この監視スクリプトは、Kubernetes 環境での TiDB の強化された管理機能を提供するTiDB Operator使用してデプロイされた TiDB クラスター用に特別に設計されていることに注意することが重要です。

監視スクリプトを活用し、メンテナンスイベント中に必要なアクションを実行することで、TiDB クラスタは Google Cloud 上のライブマイグレーションイベントをより適切に処理し、クエリ処理と応答時間への影響を最小限に抑えながら、よりスムーズな操作を実現できます。

高QPSの大規模TiDBクラスタのPDをチューニングする

TiDB クラスターでは、TSO (Timestamp Oracle) の提供やリクエストの処理などの重要なタスクを処理するために、単一のアクティブな Placement Driver (PD)サーバーが使用されます。ただし、単一のアクティブな PDサーバーに依存すると、TiDB クラスターのスケーラビリティが制限される可能性があります。

PD制限の症状

次の図は、それぞれ 56 個の CPU を搭載した 3 台の PD サーバーで構成された大規模 TiDB クラスターの症状を示しています。これらの図から、1 秒あたりのクエリ (QPS) が 100 万を超え、1 秒あたりの TSO (Timestamp Oracle) リクエストが 162,000 を超えると、CPU 使用率が約 4,600% に達することがわかります。この高い CPU 使用率は、PD リーダーに大きな負荷がかかっており、利用可能な CPU リソースが不足していることを示しています。

pd-server-cpu pd-server-metrics

PDパフォーマンスの調整

PDサーバーでの CPU 使用率が高い問題を解決するには、次のチューニング調整を行うことができます。

PD設定を調整する

tso-update-physical-interval : このパラメータは、PDサーバーが物理 TSO バッチを更新する間隔を制御します。間隔を短くすると、PDサーバーはTSO バッチをより頻繁に割り当てることができ、次の割り当ての待機時間を短縮できます。

tso-update-physical-interval = "10ms" # default: 50ms

TiDBグローバル変数を調整する

PD 構成に加えて、TSO クライアントバッチ待機機能を有効にすると、TSO クライアントの動作をさらに最適化できます。この機能を有効にするには、グローバル変数tidb_tso_client_batch_max_wait_timeゼロ以外の値に設定します。

set global tidb_tso_client_batch_max_wait_time = 2; # default: 0

TiKV設定を調整する

リージョンの数を減らし、システムのハートビートのオーバーヘッドを軽減するには、TiKV 構成のリージョンサイズを96MBから256MBに増やすことをお勧めします。

[coprocessor]
  region-split-size = "256MB"

チューニング後

チューニング後、次の効果が見られます。

1 秒あたりの TSO リクエストは 64,800 に減少します。
CPU 使用率は約 4,600% から 1,400% に大幅に削減されます。
P999 値PD server TSO handle timeが 2ms から 0.5ms に減少します。

これらの改善は、チューニング調整によって、安定した TSO 処理パフォーマンスを維持しながら、PDサーバーの CPU 使用率を正常に削減できたことを示しています。