300万テーブルのスケーリング：TiDBがAtlassian ForgeのSaaSプラットフォームをどのように支えているか

※このブログは2025年5月2日に公開された英語ブログ「Scaling 3 Million Tables: How TiDB Powers Atlassian Forge’s SaaS Platform」の拙訳です。

プロジェクト管理とチームコラボレーションにおけるグローバルリーダーであるAtlassian社は、Jira、Confluence、Forgeといった広く採用されている製品を提供しています。同社のSaaSプラットフォームがスケールするにつれて、数百万ものデータベーステーブルを効率的かつコスト効率よくスケールするなど、そのデータインフラストラクチャのニーズも増大しています。そこでTiDBが登場します。

このブログでは、TiDBがAtlassian社のForgeプラットフォームをどのように支援し、300万を超えるテーブルを持つ大規模なマルチテナントアーキテクチャを単一のクラスター内でサポートしているのかを探ります。同社が直面した技術的な課題、TiDBが導入したイノベーション、そしてその結果として得られたパフォーマンスの飛躍的向上について詳しく解説します。

課題：数百万テーブルのスケーリング

Atlassianは、そのSaaS製品向けに「テナントごとに1スキーマ (データベース＝スキーマ) 」モデルを採用しています。これは、顧客ごとに数十から数百のテーブルを持つ独自のスキーマが割り当てられることを意味します。顧客基盤が拡大するにつれて、テーブルの数は数千万にまで膨れ上がり、これは従来のシングルノードデータベースでは処理が困難な規模です。一部のアプリケーションは年間30〜40%の成長を遂げ、アプリケーションあたり150万から3000万のテーブルのサポートを必要としています。.

Atlassianは、事業拡大の過程で以下の主要な問題に直面しました。

• 急増するコスト：従来のシングルノードデータベースを使用して数百万ものテーブルをスケールするには、数千ものインスタンスをデプロイする必要がありました。これは高コストであると同時に非効率的でした。
• 運用上の複雑さ：このようなインフラの拡大は、構成、スケーリング、バックアップ、アップグレードにおける困難をもたらしました。これにより、SLAを維持し、稼働時間を確保することが困難になりました。

これらの問題を克服するために、AtlassianはまずForgeプラットフォームからTiDBの導入を開始しました。

TiDBをテストする：単一クラスタでの数百万テーブルのスケーリング

Atlassian Forgeは、TiDBを大規模に実装した最初のアプリケーションとなりました。その目標は、300万ものテーブルを単一のTiDBクラスターでホストすることであり、それは容易なことではありませんでした。

以下のセクションでは、いくつかの主要な領域における主要な課題と最適化の実践について説明します。

DDLパフォーマンス：数日を数分に変える

スキーマ変更は非常に遅く、100万個のテーブルの作成に2日、10万個のテーブルの変更に6時間以上かかっていました。

根本原因と最適化は以下の通りです。

• 非効率的なDDLタスクのスケジューリング：DDLタスクが順番に処理され、不要なスケジューリングのオーバーヘッドが発生していました。
• 遅いデータベース/テーブルの存在チェック：スキーマ検証が、より遅いフォールバックメカニズムに依存する場合がありました。
• コンピューティングリソースの未活用：TiDBノードが並行実行のために十分に活用されていませんでした。
• 非効率的なブロードキャストメカニズム：スキーマ変更がノード間で非効率的に伝播し、遅延を引き起こしていました。
• DDLフレームワークのリファクタリング：無制限のスケーラビリティ。

Atlassianは、最適化を実装した後、以下のパフォーマンス向上を達成しました。

比較項目	最適化前	最適化後
10万テーブルの作成	3時間49分	4分 (50倍速)
300万テーブルの作成	6日以上	4時間30分 (50倍速)
10万個のデータベースの作成	8時間27分	15分 (32倍速)
10万テーブルにカラムの追加	6時間11分	32分 (11倍速)
300万テーブルのシナリオで、10,000行のテーブルに単一列インデックスの追加	20分	3秒 (400倍速)

DDLのパフォーマンスに関する詳細は、この件に関する最新のブログ記事をご覧ください。

DMLの効率化：読み書きの高速化

非効率的なメタデータキャッシュにより、DMLステートメントは実行中にデータベースとテーブルの情報を繰り返し取得する必要がありました。データベースとテーブルの数が増えるにつれて、パフォーマンスは低下し、1秒あたりのクエリ数 (QPS) が減少し、レイテンシが増加しました。

さらに、テーブル数が多かったため、インポートまたはバックアップの復旧中に多くの空のリージョンが発生しました。これらのリージョンのマージ処理によりリソースが消費され、オンラインQPSに影響を与えました。

根本原因は以下の通りです。

• メタデータキャッシュ内のデータベースとテーブルのメタデータをtidb-serverが検索する際の時間計算量が O(n) でした。これにより、データベースとテーブルの数が増えるにつれて、検索時間が長くなりました。
• 空のリージョンをマージするための現在のロジックは、TiKV Ingestプロセスに従っていました。これにより、多数の空のリージョンをマージする際に、かなりのリソースが必要となりました。

その結果、以下の最適化が行われました。

• メタデータキャッシュのストレージ構造を最適化し、検索の時間計算量を O(1) に削減しました。これにより、数百万のテーブルをスケーリングするシナリオでのDML操作中のメタデータクエリの効率が向上しました。
• Ingestプロセスを使用する代わりに、空のリージョンのマージのためにKVデータを直接書き込むようにしました。これにより、空のリージョンマージの効率が向上しました。

Atlassianは、最適化後に大幅なパフォーマンス向上を実感しました。これには以下が含まれます。

比較項目	最適化前	最適化後
QPS	5,000	40,000
P99レイテンシー	62.5ミリ秒	3.91ミリ秒
250万のリージョンマージにかかる時間	20時間	2時間

メタデータ管理：メモリーの管理

TiDBは当初、起動時にすべてのスキーマメタデータをメモリにロードしていました。これにより、起動時間が長くなり、メモリ枯渇を引き起こしていました。数百万ものテーブルをスケールする場合、これは高いメモリ使用量と潜在的なOOM (Out Of Memory) の問題につながる可能性があります。

根本原因は以下の通りです。

• TiDBは、その行ストレージ層であるTiKVにメタデータを「Meta Maps」として格納していましたが、各TiDBインスタンスはインメモリのInfoschema Cacheを保持していました。DDL操作はTiKVのメタデータを更新し、新しいスキーマバージョンをPDにプッシュしました。他のTiDBノードはこのバージョンを取得し、TiKVから対応するSchema Diff (差分) を適用して自身のキャッシュを更新していました。

• DML、統計情報、外部キー 、TTL (Time To Live)、およびTiFlashはInfoschema Cacheを使用していました。多くのコンポーネントが ListTables を呼び出してすべてのメタデータをロードしていましたが、実際にアクセスされるテーブルはごくわずかでした。大規模なシナリオでは、この全ロードはメモリを浪費し、OOMのリスクを高めていました。

この問題に対し、以下の最適化が行われました。

• メモリ使用量を制限し、アクセスされたオブジェクトのメタデータのみをキャッシュするtidb_schema_cache_sizeパラメータを導入しました。このパラメータはLRU (Least Recently Used) アルゴリズムを使用して、未使用のメタデータを削除します。
• すべてのスキーマメタデータを一度にロードすることを避け、TiDBの起動時間とOOMのリスクを低減しました。

これらの最適化の結果、100万のデータベースと300万のテーブルを持つシナリオで、Atlassianは以下のことを達成できました。

• プリペアドステートメントなしで、30万のアクティブなテーブル (アクティブなテナント比率1:10) に対する読み取り/書き込み負荷をシミュレートしました。
• デフォルトのtidb_schema_cache_size (512 MiB) で、キャッシュヒット率は99.5%に達し、P99レイテンシは6.3ミリ秒となり、パフォーマンスを犠牲にすることなくメモリ使用量が大幅に削減されました。

クエリオプティマイザー：よりスマートに、よりリーンに、より速く

数百万ものテーブルが存在する場合、統計情報の初期化に10分以上かかり、テーブルごとの収集が遅れていました。さらに悪いことに、統計情報とプランキャッシュが大量のメモリを消費し、Out Of Memory (OOM) のリスクを高めていました。

根本原因は以下の通りです。

• 低い並行性での収集：TiDB 8.4より前のバージョンでは、自動統計情報収集に単一のgoroutineしかサポートしておらず、スループットが低くなっていました。
• 時間のかかる優先度付きキューの構築：TiDB 8.5より前は、各統計情報タスクで新しい優先度付きキューを構築する必要があり、多くの場合、TiKVから大量のメタデータをロードする必要があり、大きな遅延を引き起こしていました。
• 過剰な統計情報のロード：SQL実行時に、すべてのテーブルの列とインデックスの完全な統計情報のロードが実行され、メモリ使用量を押し上げていました。

これらの根本原因に対し、以下の最適化が行われました。

• 並列性の向上：TiDB 8.4では、tidb_auto_analyze_concurrencyシステム変数が導入され、ユーザーは並列性を高めて統計情報収集のスループットを向上させることが可能になりました。
• 優先度付きキュー構築ロジックの最適化：統計キューは起動時に一度だけ構築され、その後は段階的に更新されるようになり、繰り返しのメタデータロードが削減されました。
• 統計情報ロードの削減：SQL実行中にロードされるのは、関連する列とインデックスのみになりました。TiDB 8.5では、デフォルトの統計キャッシュメモリクォータも50%から20%に削減されました。
• インスタンスレベルの共有実行プランキャッシュ：tidb_enable_instance_plan_cacheシステム変数を導入し、TiDBインスタンス内のすべてのセッションが実行プランキャッシュを共有できるようになり、メモリ使用効率が向上しました。

これらの多くの最適化の結果、Atlassianは以下の効果を実感しました。

• 統計収集効率の向上：統計情報取得スループットが80倍に向上しました (毎分20テーブルから1,600テーブルへ) 。
• メモリ使用量の削減：最適化後、10万テーブルに対してIndexRangeScan演算子を含む単純なSQLクエリは、約4GBのメモリしか消費せず、メモリ使用量が大幅に削減されました。
• リソース消費量の削減：100万テーブルを持つアイドル状態のクラスタにおいて、自動統計情報収集のCPU消費量は230%から130%に減少し、メモリ消費量は2.4GBから0になりました。

プレースメント・ドライバー (PD)：数百万のハートビートを処理する

数百万ものデータベースとテーブルが、大量のリージョンを生成しました。これらのリージョンは定期的にTiDBのプレースメント・ドライバー (PD) にハートビートを送信するため、PDサービスに負荷をかける大量のハートビートリクエストが発生します。これにより、リージョンルーティングモジュールが利用不可能になる可能性があります。

根本原因は以下の通りです。

• リージョンハートビートには、メタデータ (例：リージョンの場所、ピア情報) と統計情報 (例：アクセス状況) が含まれています。これらの処理ロジックは混在しており、同期的に処理されていました。メタデータの更新には書き込みロックの保持が必要であり、ルーティング情報の読み取りにも同じロックが必要でした。これにより、大量のハートビートの処理が非効率になり、深刻なロック競合が発生し、リージョンルーティングモジュールやPDサービス全体が利用不可能になる可能性がありました。

これに対し、以下の最適化が行われました。

• リージョンメタデータと統計情報のストレージ構造を分離し、それぞれの処理ロジックを複数の非同期タスクに分割することで、ロック保持時間を短縮しました。

この最適化後、リージョンハートビート処理のP99値は100ミリ秒から2ミリ秒に低下し、1000万リージョンを容易にサポートできるようになりました。

クラスタメンテナンスの高速化

300万テーブルのシナリオでは、TiDBノードの再起動に30分かかっていました。さらに、数百万のデータベースとテーブルが存在するシナリオでは、TiDBノードでOOM (Out Of Memory) が発生する可能性がありました。たとえば、50万テーブルを持つアイドル状態のクラスタなどです。

根本原因は以下の通りです。

• TiDBノードは、すべてのデータベースとテーブルのメタデータと統計情報をキャッシュしていました。再起動中、このデータを再構築して再ロードする必要があり、時間がかかっていました。たとえば、23万テーブルの統計情報をロードするのに6分かかりました。

その結果、以下の最適化が行われました。

• TiDBの再起動時に必要な統計情報のみをロードするlite-init-stats変数を導入し、ヒストグラム、TopN、Count-Min Sketch情報のロードを回避しました。詳細な情報は、必要に応じて非同期にロードされます。
• 新しいメタデータ管理メカニズムにより、TiDBノードはデータベース/テーブルのメタデータの一部をキャッシュし、再起動中に必要なものだけをロードできるようになりました。
• TiDB 8.1では、統計データの並行初期化のためのconcurrently-init-stats機能が追加され、起動速度が大幅に向上しました。

Atlassianは、これらの最適化を実装した後、以下の表に示すように、大幅なパフォーマンス向上を実感しました。

比較項目	最適化前	最適化後
TiDBのメタデータ管理	70万ものテーブルがInfoSchemaにフルロードされた状態でテーブルを作成しようとしたところ、64GBのメモリを使用し、OOM (Out Of Memory) が発生しました。	テーブル作成時にInfoSchema全体がロードされることがなくなったため、安定したリソース使用率が確保され、TiDBのOOM (Out Of Memory) を防ぐことができます。
TiDB再起動時間	300万テーブルのシナリオでは、TiDBの再起動時間は約30分でした。	TiDBの再起動時間は30分から3分に短縮され、90%の時間短縮となりました。

バックアップとリストア (BR)：規模に応じた効率性

100万テーブルのバックアップには、当初12時間を要していました。BRによるフルリストアも数百万のRegionを生成し、TiDBがそれらを維持するために追加のリソースを必要としました。加えて、数百万の空のRegionのマージには10時間以上を要しました。

根本原因は以下の通りです。

• 各バックアップラウンドにおいて、BRはテーブルレベルの並列度に基づいてTiKVにバックアップタスクを分散させていました。タスクの分散が不均一であったため、各バックアップラウンドの時間は最も遅いTiKVの実行時間に律速され、他のTiKVのCPUリソースはアイドル状態となり、全体的なバックアップ時間を長期化させていました。この問題は、特に数百万テーブルを扱うシナリオで顕著でした。
• BRのリストア時、多数のRegionがテーブルに基づいて事前に分割され、TiKVノード全体に分散されていました。多くのSaaSシナリオでは、多数のテーブルが小さく、データサイズがTiDBのRegionサイズよりもはるかに小さいものでした。そのような場合、複数のテーブルを単一のRegionにマージすることが可能です。

これらの問題を最適に解決するため、以下の最適化が実装されました。

• 全てのレンジに対するバックアップリクエストを全てのTiKVノードに送信し、TiKVのバックアップスレッドを最大限に活用してバックアップ速度を制御します。これにより、ロングテールレイテンシーとバックアップ時間が大幅に削減されます。
• BRの事前スプリット時、テーブルのデータサイズに基づいて小さなテーブルを単一のRegionにマージし、数百万テーブルのシナリオで大量のRegionが作成されるのを回避します。

これらの最適化後、Atlassianでは以下の表に示す通り、大幅な改善が見られました。

比較項目	最適化前	最適化後	改善点
100万テーブルをバックアップする時間	4時間	1時間	75％の時間短縮
100万テーブルをリストアする時	12時間	9時間	25％の時間短縮
バックアップ/リストア時に生成される空のRegionの数	数百万	100未満	空のRegionを99％以上削減

数百万テーブルのスケーリング：Atlassianのビジネス価値

技術的なパフォーマンスに加え、TiDBはAtlassianに大きなビジネス価値をもたらしています。レガシーシステムの拡張性と運用上のボトルネックを解決することで、TiDBはAtlassianがSaaSアーキテクチャを合理化し、コストを削減し、サービス信頼性を向上させることを可能にしました。実現された主なメリットは以下の通りです。

• 大幅なコスト削減：AtlassianはすでにForgeをサポートするためにTiDBを採用しています。より多くのアプリケーションがTiDBに移行するにつれて、データベースインスタンスの数を当初の予測の100分の1に削減でき、インフラストラクチャと運用コストを大幅に削減します。
• 開発と運用の簡素化：単一のTiDBクラスターで300万テーブルをサポートできるため、中規模のSaaSアプリケーションをテナントIDに基づく複雑なシャーディングなしに、1つのTiDBクラスターだけでサポートできます。さらに、TiDBのロックフリーなオンラインDDL機能により、スキーマ変更のためにサードパーティツールや低負荷の時間帯を必要とせず、開発コストをさらに削減します。
• ゼロダウンタイムでの迅速なビジネス成長：TiDBの分散アーキテクチャはシームレスな水平スケーリングをサポートし、高QPSと大量のデータを容易に処理します。そのオンラインスケーリング機能はトラフィックの急増に柔軟に対応し、数百万テーブルに対するローリングリスタートと高速バックアップリカバリは、SaaSサービスの可用性とSLAを大幅に向上させます。

これらの利点により、TiDBが単なる高性能データベースにとどまらず、AtlassianのSaaS成長のための戦略的な基盤となっていることがわかります。インフラストラクチャを統合し、複雑さを軽減し、信頼性を高めることで、TiDBはAtlassianがより迅速にスケールし、より自由に革新し、世界中の顧客により良い体験を提供することを可能にします。

まとめ

AtlassianのTiDB導入事例は、データインフラストラクチャの再考が、現代のSaaSプラットフォームにとって前例のない規模、パフォーマンス、効率性をいかに引き出すことができるかを示しています。数百万テーブルのスケーリングという技術的課題を解決することで、TiDBはForgeを真にスケーラブルなマルチテナントの強力な基盤へと変革しました。

パフォーマンス向上にとどまらず、TiDBはAtlassianがアーキテクチャを簡素化し、運用負担を軽減し、顧客の要求が増大するにつれてプラットフォームの将来性を確保することを可能にします。TiDBを中核に据えることで、Atlassianは成長に追随するだけでなく、それを牽引しています。

SaaS業界全体でデータ量とアプリケーションの複雑さが増大し続ける中、AtlassianのTiDBでの成功は、イノベーションが適切な技術基盤と出会ったときに何が可能になるかを示す強力な事例となっています。

妥協することなくSaaSプラットフォームをスケールする準備はできていますか？当社のデータベース専門家にご連絡いただき、お客様の未来を築くお手伝いをどのようにできるかご確認ください