驚異的な速さのクラスタ復旧：TiDB 8.1が大規模データ復元を再定義する

※このブログは2025年01月31日に公開された英語ブログ「Blazing-Fast Cluster Recovery: How TiDB 8.1 Redefines Large-Scale Data Restoration」の拙訳です。

バックアップとリストアは事業継続性を確保するために不可欠であり、リストアのパフォーマンスを評価するための重要な指標として、目標復旧時間 (RTO) があります。スケーラビリティで人気が高まっているTiDBでは、多くのユーザーが数百テラバイト (TB) に及ぶデータセットを保有しています。そのため、このような大規模なクラスタで高速なRTOを確保するという課題は、ますます複雑になっています。しかし、TiDB 8.1 LTSから、これほどの規模のクラスタを1時間以内に復旧することが現実のものとなりました。このブログでは、パフォーマンスの向上、克服した課題、そしてTiDB 8.1を大規模クラスタ復旧のリーダーたらしめるイノベーションについて詳しく解説します。

TiDB 8.1によるクラスタ復旧パフォーマンスの革命

TiDB 8.1は、ハードウェア機能を最大限に活用することで、クラスタ全体のリストアパフォーマンスを新たなレベルに引き上げます。各TiKVノードは、~1.2 GB/秒のディスクスループット制限を一貫して達成し、ノードを追加する際にスムーズで線形的なスケーラビリティを確保します。この革新は、ディスクとネットワークのスループットにおける一般的なボトルネックを解消し、企業が最大のデータセットでも自信を持って処理できるようにします。

クラスタ復旧パフォーマンスの概要

• リストア速度は、合計データサイズを合計リストア時間で割って計算され、プロセスのすべての段階を含みます。
• 重要なダウンロードと取り込みの段階では、システムは一貫してTiKVノードあたり約1.2 GB/秒のハードウェアスループット制限に達し、現在のハードウェアで達成可能な最大のパフォーマンスを示しています。
• TiDB 8.1以降、クラスタ全体のリストアは、水平方向と垂直方向の両方で並外れたスケーラビリティを示し、TiDB 7.5と比較してリストアのスループットが平均で3～4倍以上向上しているケースもあります。

データセット	TiKVノード	TiDB 7.5パフォーマンス	TiDB 8.1パフォーマンス
110TB	50	100MB/s per TiKV (6.4時間)	1.15GB/s per TiKV (41分)
300TB	90	274MB/s per TiKV (3.5時間)	1.02GB/s per TiKV (56分)

今回の結果をもたらした主な強化点

• ハードウェアの活用：TiKVノードは、ディスクスループットの限界である約1.2GB/秒を一貫して達成するようになり、ノードを追加する際の最適なスケーリングを保証します。
• リストアフェーズの革新：効率的なリージョンスプリットと強化された取り込みワークフローにより、ハードウェアとネットワークの活用を最大化します。
• スケーラビリティの向上：TiDB 8.1は一般的なボトルネックを克服し、大規模なデータセットの場合でもリストアのパフォーマンスが予測どおりにスケーリングされるようにします。
• 将来の最適化の可能性：TiKVノードあたりのデータセットが小さい場合は、まだ十分に活用されていない可能性があり、これはさらなる改善の余地があることを示しています。

これらの進歩は、最も要求の厳しいワークロードにおいても、TiDB 8.1が信頼性の高いスケーラビリティと予測可能なパフォーマンスを提供できる能力を際立たせています。

クラスタ復旧のスケーラビリティにおける障壁の打破

TiDB 8.1より前は、リストアプロセスは厳格なパイプラインアプローチに従っており、リソース利用率を最大化するために3つの主要な段階を相互に織り交ぜていました。

1. テーブル作成：SSTファイルの特定とテーブルの作成は、非常に遅いプロセスでした。30万個のテーブルを作成するには最大60時間かかり、リストア全体のタイムラインが停滞していました。
2. リージョンの分割と分散：新しく作成された複数のテーブルごとに、リージョンの分割と分散が必要でした。これらのタスクが単一ノードに集中すると、非効率性が生じる場合がありました。
3. データのダウンロードと取り込み：データファイルがダウンロードされ、それぞれのリージョンに取り込まれ、各バッチのパイプラインが完了しました。

このパイプラインは、もともとはテーブル作成などの遅い段階を待機している間にリソースをビジー状態に保つために必要でした。しかし、TiDB 7.6でテーブル作成が高速化され (30万個のテーブルの作成時間がわずか30分に短縮) 、この硬直的なパイプラインがボトルネックとなりました。パイプラインの単一の並行処理パラメータは、システムを2つの主要な点で制限していました。

• 低い並行処理 (例：128以下)：データが遅れて到着するため、TiKVノードが十分に活用されず、CPUとネットワークの利用効率が低下しました。
• 高い並行処理 (例：2048以上)：リージョンの分割と分散が追いつかず、単一の競合点が発生しました。これにより、データを取り込むよりもリージョンのバランス調整に過度の時間が費やされ、リソースを追加しても期待されるパフォーマンス向上がえられませんでした。

TiDB 8.1の革新性

TiDB 8.1は、これらのボトルネックに対処するために、段階的なリストアモデルを採用しています。

• 高速なテーブル作成：最適化により、30万個のテーブルの作成時間がわずか30分に短縮され、ボトルネックが解消されました。
• 効率的なリージョンの分割と分散
  • 粗分割：境界キーのサブセットを選択してリージョンを分割し、TiKVノード全体に分散させて早期にワークロードのバランスを取ります。
  • 詳細分割：リージョンの分散をさらに調整し、均一なリソース使用率を確保し、ホットスポットの発生を防ぎます。
• バランスの取れたデータ復元
  • トークンバケットメカニズム：gRPCリクエストレートを動的に制御してノードの過負荷を防ぎ、安定したパフォーマンスを維持します。
  • ダウンロードと取り込みのための独立したストリーム：これらの操作を分離することで、リソース割り当てを改善し、スケーラビリティを向上させます。

これらの進歩により、TiDBはリストア中にリニアなスケーリングを実現し、100TBのクラスタをわずか1時間でリストアすることが可能になりました。

技術的な詳細：クラスタ復旧の最適化

リージョン管理を効率化するために、TiDB 8.1では2段階のアプローチが導入されました。それは、粗分割と詳細分割です。巨大なデータセットを、それぞれ特定のストレージノードに割り当てられた小さなチャンクに分割して管理していると想像してみてください。粗分割は最初のパスとして機能し、ソートされたキーに基づいてデータセットを広いセクションに分割し、TiKVノード全体に均等に分散します。このステップにより、準備のオーバーヘッドが削減され、単一ノードに過負荷がかかることがなくなります。データの大まかなバランスが取れたら、詳細分割により、これらの広いセクションをより小さく、より正確なチャンクに分割することで、この分散を調整します。これにより、リソースが完全に活用され、操作を遅らせる可能性のあるホットスポットの発生を防ぎます。

• 粗分割：データを広いセクションに分割し、TiKVノード全体に均等に分散することで、準備のオーバーヘッドを削減し、ワークロードのバランスをとります。
• 詳細分割：広いセクションをより小さく、より正確なチャンクに分割することで分散を調整し、リソースの完全な活用とホットスポットの排除を実現します。

トークンバケットによるワークロードのバランス調整

TiDB 8.1は、トークンバケットメカニズムを使用してワークロード分散を管理します。これは、データベースでリクエストの流れを調整するためによく使用される方法です。各ノードを、入ってくるタスクを処理する作業者と考えてください。トークンは許可証として機能し、タスクが制御されたペースで進行できるようにします。各リクエストが処理されると、トークンが消費されます。トークンは一定の間隔で自動的に補充され、システムがスムーズに動作し続けるようにします。このアプローチにより、リソースのボトルネックを防ぎ、安定した予測可能なスループットを確保します。

• 動的なレート制御：リソースのボトルネックを防ぐためにgRPCリクエストを制限します。
• 自動補充：トークンは定期的に補充され、手動介入なしでスムーズな処理を保証します。

独立したリクエストストリーム

TiDB 8.1では、リソース使用量を最適化するために、ダウンロードと取り込みの操作が個別に処理されます。まずストレージからデータを取得し (ダウンロード)、次に処理して最終的な場所に保存する (取り込み) システムを想像してみてください。これらのタスクを分離することで、システムは効率を最大化できます。ダウンロードストリームは、すべてのノードにデータ取得を均等に分散し、ネットワークリソースが完全に活用されるようにします。一方、取り込みストリームは、リーダーピア内でのこのデータの処理に焦点を当て、特定のノードに過負荷がかかるのを回避し、クラスタ全体でスムーズかつ効率的な運用を保証します。

• ダウンロードストリーム：ネットワーク利用率を最大化するために、ノード全体にデータ取得を均等に分散します。
• 取り込みストリーム：リーダーピアでデータ取り込みを処理し、特定のノードへの過負荷を回避します。

大規模リストアにおけるベストプラクティス

TiDB 8.1でリストアのパフォーマンスを最大限にするためには、以下のベストプラクティスを参考にしてください。

• 十分なvCPUリソースを割り当てる：計算能力をフル活用するために、import.num-threads をTiKV vCPUコアの約60%に設定します。たとえば、16コアのTiKVインスタンスには10スレッドを割り当てます。
• ハードウェアのボトルネックを回避する：安定性と一貫性を維持するために、ハードウェアスループットの90%で運用します。
• BRに十分なメモリを使用する：スナップショットリストア中のガベージコレクションを最小限に抑えるために、十分なメモリを割り当てます。
• 新規クラスタを使用する：テーブルIDの書き換え中にパフォーマンスの問題が発生しないように、データベースが削除された再利用クラスタではなく、真新しいクラスタを使用します。

将来の機能拡張

TiDBのロードマップには、リストアのパフォーマンスをさらに向上させるための魅力的な機能が含まれています。

• PITR最適化：ポイントインタイムリカバリ (PITR) のスループットを3倍向上させ、迅速なイベントベースの復旧を可能にします。
• 粒度の細かいリストア制御：クラスタレベルの最適化をテーブルレベルのリストアに適用し、リソース分離とSLA遵守を向上させた並列タスクを可能にします。

まとめ

TiDB 8.1は、比類なきパフォーマンスとスケーラビリティを実現する革新により、大規模データ復元を再定義します。テーブル作成、リージョン分割、データ取り込みにおけるボトルネックに対処することで、TiDBは企業が記録的な速さで巨大なデータセットを復元することを可能にします。将来の機能強化も見据え、TiDBはデータベースイノベーションをリードし続け、企業が最も要求の厳しい復旧目標にも自信を持って対応できるようにします。

TiDBのクラスタ復旧機能についてご質問がある場合は、Twitter、LinkedIn、またはSlackチャンネルでお気軽にお問い合わせください。