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

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

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

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 は、特定の要件に応じてプロビジョニングできます。

例 1: AWS でソーシャル ネットワーク ワークロードを実行する

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.09.417.5
平均挿入遅延時間 (ミリ秒)11.39.2-18.7
P99 挿入遅延 (ms)29.416.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_write60.771.517.8
QPS (K/秒)TPC-C23.930.527.6
平均レイテンシ(ミリ秒)システムベンチoltp_read_write4.53.8-15.6
平均レイテンシ(ミリ秒)TPC-C3.93.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

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

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

ディスク スループットの制限によって発生するボトルネックを軽減するには、RocksDB の圧縮レベルを上げてディスク スループットを下げることでパフォーマンスを向上させることができます。たとえば、次の例を参考にして、デフォルトのカラムファミリーのすべての圧縮レベルをzstdに上げることができます。

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

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 使用率を正常に削減できたことを示しています。

pd-server-cpu pd-server-metrics

このページは役に立ちましたか?

Playground
登録なしで TiDB の機能をワンストップでインタラクティブに体験できます。
製品
TiDB Dedicated
TiDB Serverless
TiDB
価格
PoC お問い合わせ
エコシステム
TiKV
TiFlash
OSS Insight
© 2024 PingCAP. All Rights Reserved.
Privacy Policy.