事業拡大への対応：TiDBはいかにしてペタバイト級のデータ量を拡張するか

※このブログは2024年12月18日に公開された英語ブログ「Navigating Business Growth: How TiDB Scales Petabyte-Level Data Volumes」の拙訳です。

事業の成長は、より多くのユーザー、トランザクション、そしてイノベーションの機会をもたらす、エキサイティングな指標です。しかし、成長には以下のような重大な技術的課題が伴います。

• データ量の爆発的な増加：急速なユーザーアクティビティは、効率的に保存・管理しなければならないテラバイト (TB) からペタバイト (PB) 規模のデータを生成します。
• 複雑性の増大：アプリケーションは、新しい機能によってエクスペリエンスが向上し、進化する要求に応える必要があると同時に、より多くのユーザーをサポートするように拡張する必要があります。
• 運用上の負担：従来のデータベースソリューションは、大規模なデータ増加に対応するのに苦労し、ダウンタイム、遅延、そしてコストのかかる運用上のオーバーヘッドにつながります。

このブログでは、オープンソースの分散SQLデータベースであるTiDBが、これらの事業成長の課題にどのように対処するかを探ります。また、Bolt社やFlipkart社などの企業による実際の事例も紹介します。

Bolt社：急成長を遂げるモビリティ企業

例として、Bolt社はヨーロッパで急成長しているモビリティ企業であり、500以上の都市で1億人以上のユーザーを抱えています。同社はパンデミック以降、400％の成長を遂げています。Bolt社は長年MySQLをバックエンドデータベースとして使用してきました。成長に伴い同社が経験した技術的な課題をいくつかご紹介します (詳細はBolt社のHTAP Summit 2023セッションをご覧ください)。

• 数百TBから1PBのデータ量を管理
• 毎日100以上のサービスをデプロイ
• 毎週100以上のデータベース変更を実施
• 毎月5〜10TBの新しいデータを生成
• 単一のMySQLインスタンスのサイズ制限に達しました。最大のMySQLインスタンスは8TBのデータを持っていました。このような大規模なMySQLインスタンスのバックアップとリストアには数時間かかり、アプリケーションにとっては許容できません。
• スキーマ変更には、MySQL用のgh-ost/pt-online-schema-changeを使用しても最大2週間かかりました。これにより、テーブル削除時にデータベースが数秒間フリーズしました。
• MySQLのマスター切り替えはアップグレード時にダウンタイムを引き起こしました。これにより、QPSの急増時に接続処理が適切に行われなくなり、アプリケーションの可用性に影響を与えました。

急速な事業成長に対応する従来型ソリューション：データベースシャーディング

データ増加の課題に直面した場合、最も伝統的な解決策はバックエンドデータベースをシャーディングすることです。この解決策を用いると、より多くの接続ユーザーに対応するために、より多くのアプリケーションサーバーがデプロイされます。そして、バックエンドデータベースには複数のデータベースインスタンスが存在することになります。さらに、大規模なテーブルは複数のサブテーブルに分割され、これらの複数のデータベースインスタンスに分散されます。

しかし、データベースシャーディングには多くの欠点があります。

• アプリケーションコードの書き換えが必要：一部のデータベースプロキシは、シャーディングの複雑さをアプリケーション層から隠蔽しようとします。しかし、これらのプロキシは、リシャーディング、スキーマ変更時のサブテーブル間の不整合、クロスシャードJOINのサポート不足、クロスシャードクエリの不整合といった運用上の複雑さに直面します。
• JOINなどの一部のSQL機能が損なわれる：データが複数のデータベースインスタンスにまたがる複数のシャードに分割されるため、JOINを含むクエリの実行には時間がかかります。
• データ量が増加するにつれて、シャードの分割やデータのリシャーディングが悩みの種となります。
• 異なるシャード間でスキーマの一貫性を維持することが困難です。
• 障害復旧は複雑な作業であり、一貫性のあるデータベーススナップショットへのバックアップには特別な労力が必要です。

急速なビジネス成長に対応するためにスケーラブルな分散SQLデータベースが必要な理由

急速なビジネスとデータの成長に正面から立ち向かうには、以下の機能を備えたスケーラブルな分散型SQLデータベースが有効です。

• 水平スケーラビリティ：データとQPSの増加に対応するために、データベースにノードを追加できる能力。
• 低い運用複雑性：スケーラブルな分散SQLデータベースでは、アプリケーション層のコードを変更したり、JOINなどのSQL構文を妥協したりする必要はありませんすぐに使えるスキーマ変更、バックアップ、変更データキャプチャ (CDC)、データロードを実行できます。
• 大量のデータでも低い読み書きテールレイテンシ：スケーラブルな分散SQLデータベースは、数百TBのデータがあっても、p99で1桁ミリ秒のレイテンシを実現します。
• 高可用性：スケーラブルな分散SQLデータベースは99.99%以上の可用性を持ち、AZレベルの障害にも耐えることができます。

この10年間、私たちはまさにそのようなスケーラブルな分散SQLデータベースの構築に注力してきました。

TiDB：急速なビジネス成長に対応する、スケーラブルなオープンソース分散SQLデータベース

TiDBは、オープンソースでクラウドネイティブな、伸縮自在に拡張可能な分散SQLデータベースであり、MySQL互換でもあります。TiDBは、無制限に拡張可能なMySQLデータベースでありながら、分散データ集約やデータ分析などの機能も追加されていると考えることができます。アプリケーションはMySQLプロトコルを使用してTiDBのコンピューティング層に接続し、ワークロードとデータは異なるノード間で自動的にバランスされます。

MySQLやPostgreSQLとは異なり、TiDBは最初からクラウドネイティブな分散システムとして機能します。この選択により、TiDBの拡張性の上限は高くなります。下の図に示すように、TiDBは分離されたコンピューティング層とストレージ層を持つアーキテクチャを採用しています。これにより、コンピューティング層とストレージ層を独立して拡張できるため、効率が向上します。

TiDBは100万QPSまでスケール可能

Flipkart社はインド最大のeコマース企業です。400以上のアプリケーション、数千のマイクロサービス、そして700以上のMySQLサーバーで実行される無数のエンドツーエンドのeコマース運用により、Flipkart社はインド最大のMySQLサーバー群の1つを運営しています。

年次イベントであるBig Billion Days (BBD) のアクティビティからの大量のリクエストスループットに対応するため、Flipkart社はスケーラブルなSQLデータベースを必要としていました。このデータベースは、複数のMySQLインスタンスを1つのSQLデータベースに統合して運用コストを削減しながら、低いレイテンシでそのような高いスループットを処理する必要がありました。2020年、Flipkart社はTiDBを発見し、TiDBは2021年初頭に初めてデプロイされました。

Flipkart社はTiDBのスケーラビリティを検証するために、100万QPSのテストをTiDBで実行しました。その結果、同社は32個のTiDBノード全体で1桁ミリ秒のテールレイテンシで100万QPSを達成しました。一方、TiDBの圧縮効率の高いデータストレージのおかげで、Flipkart社のデータフットプリントはMySQLと比較して82％削減されました。

TiDBは40TBのテーブルに1時間でインデックスを追加可能

Bolt社の事例で前述したように、アプリケーションの進化に合わせてテーブルスキーマを変更することは非常に一般的です。Bolt社は毎週100回以上のスキーマ変更を行う必要がありました。つまり、インデックスの追加は同社が最も頻繁に行うスキーマ変更の一つでした。大規模なSQLデータベースとして、TiDBは標準でオンラインスキーマ変更をサポートしており、スキーマ変更がフォアグラウンドリクエストをブロックすることはありません。その一方で、TiDBでのインデックス追加は非常に高速です。

下の図は、TiDBが分散実行フレームワークを通じてインデックスを迅速に追加する方法を示しています。このフレームワークでは、各TiDBノードがジョブの一部を担当し、対応するデータ範囲をスキャンし、SSTファイルを生成し、それらのファイルをTiDBのストレージ層に取り込みます。その間、このテーブルの新しい書き込み (つまり、挿入/更新/削除) が追跡および記録されます。

複数のインデックス追加テスト

40TBのテーブルに対して、複数のインデックス追加テストを実施しました。下の表に示すように、シングルノードモードでインデックス追加を実行した場合、ジョブ全体の完了までに約14時間かかりました。しかし、分散モードで実行したところ、このクラスタには14個のTiDBノードがあるため、水平方向にスケールしてわずか1時間で完了しました。次に、この40TBのテーブルに対して4つのインデックスを追加する単一のステートメントを実行したところ、これらの4つのインデックスが手順中に同じスキャン結果を再利用したため、わずか1時間27分しかかかりませんでした。

40TB	Nodes	CPU	Memory
TiDB	14	15 cores	28GB
TiKV	20	8 cores	28GB
PD	3	2 cores	5GB

TiDB DXF (分散実行フレームワーク)	ALTER TABLE item ADD INDEX idx(`product_id`);	59分46秒
TiDB DXF	ALTER TABLE item ADD INDEX idx_pid(`product_id`), ADD INDEX idx_mid(`merchant_id`), ADD INDEX idx_ct(`created_time`), ADD INDEX idx_miid_misid(`merchant_item_id`, `merchant_item_set_id`);	1時間27分09秒
TiDB DXF	ALTER TABLE item ADD UNIQUE INDEX idx(merchant_id, item_primary_key);	1時間6分9.11秒
TiDB Local (シングルノードモード)	ALTER TABLE item ADD INDEX idx(`product_id`);	14時間38分09秒

TiDB は 300 TB のクラスタを 1 時間でバックアップ可能

バックアップは、深刻な災害後にデータを復旧できることを保証するための必須要件です。デフォルトでは、TiDBはアプリケーションのデータバックエンドとして、高いデータ耐久性と可用性を実現するために、複数のノード間でデータをレプリケーションします。

TiDBは、スナップショットフルバックアップと増分変更ログバックアップの2種類のバックアップもサポートしています。フルスナップショットバックアップは、クラスタ全体、指定されたデータベース、またはテーブルの一貫性のあるスナップショットをダンプします。そこから、バックアップをリモートストレージ (Amazon S3など) にアップロードします。各TiDBストレージノードは、データを並列SSTファイルの形式でアップロードします。

100TBと309TBを含む2つの異なるTiDBクラスタに対して、2つのテストを実行しました。最初の100TBのバックアップには45分かかり、309TBのバックアップには1時間4分かかりました。309TBのクラスタは最初のクラスタに比べてデータサイズが3倍ですが、総バックアップ時間は最初のクラスタよりもわずかに長くなっただけです。これは、各ストレージノードに含まれるデータ量によるものです。309TBのクラスタでは、各ストレージノードには3.1TBが含まれており、これは最初のクラスタよりもわずかに大きくなっています。

クラスタサイズ	100TB	309TB
ストレージノードの数	42	100
ノードあたりのデータ量	2.6TB	3.1TB
合計時間	45分	1時間4分

まとめ

ビジネスが成長するにつれて、大量のデータ量を管理し、アプリケーションを拡張することが重要な課題となります。データベースシャーディングのような従来型のソリューションは、複雑さ、運用上のオーバーヘッド、そして機能的な制限をもたらします。しかし、これまで説明してきたように、TiDBはこれらの課題を解消する、最新の、スケーラブルで、回復力のある分散SQLデータベースを提供します。

ペタバイト規模のデータ、毎秒数百万件のトランザクション、そして複雑な運用要求を処理してきた実績のあるTiDBは、高い可用性とパフォーマンスを維持しながら、企業が効率的に拡張することを可能にします。急速な成長に対応している企業にとって、TiDBはスケーリング、大量のデータ、そして進化するビジネスニーズに対応する、将来性のあるソリューションを提供します。

TiDBについてさらに深く知りたいですか？TiDBについて紹介したアーカイブ動画をご覧になり、金融サービス、eコマース、ゲーム、SaaSなど、さまざまな業界における主要なユースケースについて詳しく学んでください。