※このブログは2024年6月27日に公開された英語ブログ「Multi-Tenant Architecture: Enhancing Database Scalability with TiDB 」の拙訳です。
クラウドコンピューティングとサービスとしてのソフトウェア (SaaS) が普及する中、データベースリソースの利用とスケーラビリティの最適化はますます重要になっています。マルチテナントアーキテクチャは、単一のデータベースインスタンスが複数の顧客 (テナント) に効率的にサービスを提供することで、これらの要件を満たします。このアプローチにより、各テナントのデータが適切に分離され、安全に管理されるため、コスト効率が向上し、運用管理が簡素化され、さらにスケーラビリティが強化されます。これにより、IT企業はリソースを最適化し、迅速な拡張や変化に対応することが可能になります。
このブログでは、データベースにおけるマルチテナントの核心となる原則、実装モデル、そして重要な検討事項について探り下げます。また、オープンソースの分散型SQLデータベースであるTiDBが、論理的なマルチテナント機能を活用して、堅牢なデータの分離、リソースの最適化、スケーラビリティをどのように提供しているかについても検証します。SaaSプラットフォームの最適化やエンタープライズデータベース管理の効率化を目指している方々にとって、マルチテナントを習得することはシステムの大きな潜在能力を引き出す鍵となります。それでは、詳しく見ていきましょう。
データベースにおけるマルチテナント・アーキテクチャとは？
データベースにおけるマルチテナントは、単一のデータベースインスタンスが複数の顧客 (テナント) にサービスを提供するアーキテクチャです。各顧客 (テナント) は独立して運用され、共有された物理インフラストラクチャ内で自らのデータにアクセスし、管理します。
リソースを共有するにもかかわらず、論理的な分離により、各テナントのデータは他のテナントから分離された安全な状態に保たれます。このアーキテクチャはクラウド・コンピューティングやSaaSモデルで特に顕著で、プロバイダーとユーザーの双方にコスト効率、拡張性、管理の簡素化を提供します。
データベースのマルチテナントにおける4つの基本原則
- 論理的な分離：複数のテナントが同じデータベースインフラを共有しているにもかかわらず、各テナントのデータは論理的に分離されています。これにより、一方のテナントが他方のテナントのデータにアクセスできないようにし、プライバシーとセキュリティを維持します。
- リソースの共有： マルチテナントにより、ハードウェア、ストレージ、管理コストなどのリソースを共有することで、リソースの使用が最適化されます。これにより、サービスプロバイダーとテナントの双方にコスト削減が実現します。
- スケーラビリティ：マルチテナントデータベースは水平スケーリングが可能であり、増加するワークロードに対応するためにリソースを追加しても、個々のテナントに影響を与えることなく性能を維持できます。これにより、テナント数の増加にも一貫したパフォーマンスが確保されます。
- カスタマイズと柔軟性：各テナントは、共通のデータベースインフラを共有しながら、自身の特定のニーズに合わせたカスタム設定やスキーマ定義を行うことができます。これにより、柔軟な運用が可能になります。
マルチテナント・システムを設計する際の5つのポイント
- アイソレーション： 各テナントのデータを分離し、無許可のアクセスを防ぐことが重要です。これには、行レベルのセキュリティやアクセス制御の実装が含まれます。
- スケーラビリティ：システムは、テナント数やそのデータが増加してもパフォーマンスを低下させることなく処理できる必要があります。効率的なリソース管理とスケーリング戦略が求められます。
- セキュリティ：テナントデータを外部の侵害から保護するためには、強固なセキュリティ対策が不可欠です。これには、暗号化、アクセス制御、定期的なセキュリティ監査が含まれます。
- パフォーマンス：マルチテナントシステムは、一つのテナントのパフォーマンスが他のテナントに悪影響を及ぼさないことを保証する必要があります。これには、リソースクォータの設定やロードバランシングの実装が求められます。
- コスト効率： テナント間でリソースを共有することで、独立した環境に比べてコストが削減されるため、プロバイダーとテナントの双方にとってコスト効率の良いソリューションとなります。
マルチテナント・アーキテクチャの使用例
マルチテナントは、コスト効率、スケーラビリティ、リソース最適化を提供する強力なアーキテクチャです。従来の利用ケースを超え、さまざまなシナリオで特に価値を発揮します。ここでは、マルチテナントアーキテクチャの主要な3つの応用例を掘り下げて説明します。SaaS、クラウドサービスプロバイダー、エンタープライズアプリケーションです。これらの例では、異なるコンテキストでマルチテナントを活用し、利点を最大限に引き出す方法をご案内します。
SaaS (サービスとしてのソフトウェア)
SaaSアプリケーションは、単一のソフトウェアインスタンスを通じて複数の顧客にサービスを提供するように設計されています。各顧客 (テナント) はインターネットを介してソフトウェアにアクセスし、共有インフラストラクチャの利点を活用します。
利点
- コスト効率：複数のテナント間でリソースを共有することで、SaaSプロバイダーは運用コストを削減し、競争力のある価格を顧客に提供できます。
- スケーラビリティ：顧客ベースの拡大に伴い、SaaSプラットフォームは水平スケーリングし、リソースを追加することで一貫したパフォーマンスを確保します。
- 管理の容易さ：変更はソフトウェアの単一のインスタンスに適用され、すべてのテナントに同時に反映されるため、更新とメンテナンスが合理化されます。
ケーススタディ
顧客関係管理 (CRM) プラットフォームは、マルチテナントを使用して、さまざまなビジネスに対応できます。各企業 (テナント) は同じソフトウェア・インスタンスにアクセスしますが、データと設定は他のテナントから分離されています。これにより、CRMプロバイダーは単一のアプリケーションを管理しながら、さまざまなニーズを持つ複数のビジネスをサポートすることができます。
クラウドサービス・プロバイダー
クラウドサービスプロバイダーは、さまざまなクライアントに対してインフラストラクチャ、プラットフォーム、およびSaaSを提供します。マルチテナントにより、リソースの利用効率と効率性を最大化することが可能になります。
利点
- リソース最適化：共有インフラストラクチャにより、クラウドプロバイダーはハードウェアをより効果的に活用でき、コスト削減とリソース管理の向上が実現します。
- 分離とセキュリティ：リソースは共有されますが、各テナントのデータやワークロードは分離されており、セキュリティとプライバシーが確保されています。
- カスタマイズ可能なサービス：プロバイダーは、さまざまなサービスやカスタマイズオプションを提供できるため、クライアントの多様なニーズに応じることができます。
ケーススタディ
AWSやAzureのようなクラウドプロバイダーは、同一の物理サーバー上で異なるクライアント向けに複数の仮想マシンやコンテナをホスティングできます。各クライアントの環境は論理的に分離されており、パフォーマンスとセキュリティが確保されています。これにより、プロバイダーはリソースを一元的かつ効率的に運用できる体制を構築しています。
エンタープライズ向けアプリケーション
大規模な企業は、複数の部門、子会社、さらには外部パートナーにアプリケーションを提供する必要があります。マルチテナントは、このプロセスを効率化するのに役立ちます。
利点
- 集中管理：企業は、単一のアプリケーションインスタンスを管理しながら、さまざまな内部および外部ユーザーにアクセスを提供できるため、アップデートやメンテナンスが簡素化されます。
- コスト削減：共通のインフラストラクチャを共有することで、冗長なシステムを必要とせず、ハードウェア、ソフトウェア、メンテナンスコストの削減が可能になります。
- スケーラビリティと柔軟性：企業は、新しい部門やパートナーをサポートするためにアプリケーションを拡張することができ、それぞれに個別のインスタンスを導入する必要はありません。
ケーススタディ
多国籍企業は、さまざまな子会社を世界中でサポートするために、マルチテナントのエンタープライズリソースプランニング (ERP) システムを利用することがあります。各子会社は、ERPシステム内で独立して運営され、ローカライズされた設定やデータを持ちながら、コアインフラストラクチャとアプリケーションは中央で管理されます。この構成により、企業は一貫性とコントロールを維持しつつ、多様な運用ニーズに対応することができます。
可能性の拡大
これらのユースケースを理解することで、さまざまなコンテキストにおけるマルチテナントの多様性と強力さが浮き彫りになります。SaaSアプリケーションの提供、クラウドリソースの最適化、エンタープライズソフトウェアの管理において、マルチテナントは複雑な課題に対する強固なソリューションを提供します。これらの例を検討することで、マルチテナントの原則を新しいシナリオに適用し、リソースの最適化、セキュリティの強化、スケーラビリティの向上を図る革新的な方法を発見する可能性があります。
TiDBがマルチテナントアーキテクチャに対応する方法
TiDBは、その堅牢な機能、スケーラビリティ、強力な一貫性により、マルチテナントアーキテクチャに適しています。論理的な分離を活用することで、各テナントのデータが安全に隔離されながら、効率のために共通のリソースを共有します。また、TiDBでは｢スキーマ｣と｢データベース｣が同義として扱われるため、マルチテナントの実装方法に影響を与えます。これにより、テナントごとのデータ管理が容易になり、柔軟な運用が可能となります。
このセクションでは、TiDBがマルチテナントをどのように扱っているかを探り、主なモデルを検討します：
- 共有データベース、共有テーブル
- 別データベース、別テーブル
- 別データベース、共有テーブル
また、TiDBにおけるマルチテナントの実装に関する重要な検討事項についても説明し、その機能やパフォーマンス、セキュリティ、スケーラビリティを最適化するためのベストプラクティスを包括的に理解できるようにします。
共有データベース、共有テーブル
shared database, shared tablesモデルでは、すべてのテナントが同じデータベースとテーブルを共有します。テナントのデータは、各テーブルのテナント識別子カラムを使用して区別されます。
長所
- リソースの効率化：すべてのテナントデータを単一のテーブルに統合することで、リソースの利用を最大化します。
- 管理の簡素化：管理するテーブルが1セットのみなので、管理タスクを簡素化することが可能です。
課題
- データの分離：アクセス制御を慎重に実装する必要があるため、強力なデータの分離とセキュリティの確保は複雑になる場合があります。
- パフォーマンスへの影響：テナントのアクティビティが高い場合、クエリの最適化とリソース管理を慎重に行う必要があり、競合やパフォーマンスのボトルネックにつながる可能性があります。
ケーススタディ
あるSaaSプロバイダーは、TiDBを使用して単一のアプリケーションを複数のビジネスに提供しています。各企業のデータにはテナント識別子カラムが含まれており、データの分離を確保しつつ、共有インフラストラクチャの利点を利用しています。
別データベース、別テーブル
separate databases, separate tablesモデルでは、すべてのテナントが独自のデータベースと、そのデータベース内に個別のテーブルのセットを持つという特徴があります。
長所
- データの分離：共有テーブルモデルと比較して、データの論理的な分離が向上します。
- セキュリティ：テーブルレベルの権限を適用しやすく、セキュリティが強化されます。
課題
- 管理の複雑さ：複数のテーブルのセットを管理することは、特にテナント数が増えるにつれて複雑になる可能性があります。
- スケーラビリティの限界：単一のデータベースが効率的に処理できるテーブルの数には、実際には限界があるかもしれません。
ケーススタディ
企業は、TiDBを使用してさまざまな部門をサポートしており、各部門には独自のテーブルセットがあります。この構成により、各部門のデータが分離されると同時に、共通のデータベースインフラを活用することができます。
別データベース、共有テーブル
個別のデータベースを使用する場合、各テナントは専用のTiDBクラスタまたはデータベースインスタンスを持ちますが、テナントはそれぞれのデータベース内でテーブルを共有できます。
長所
- 強力な分離：各テナントのデータが完全に分離されているため、最高レベルのデータ分離を実現します。
- カスタマイズ：テナントごとの特定のカスタマイズやパフォーマンス調整が可能で、他のテナントに影響を与えることなく実施できます。
課題
- 運用コスト：複数のTiDBデータベースを管理することは、リソースを多く消費し、複雑になる可能性があります。
- コストの増大：各テナントのために別々のインスタンスを維持することで、運用コストやインフラコストが増加します。
ケーススタディ
クラウドサービスプロバイダーは、各クライアントに専用のTiDBデータベースを提供し、各クライアントのデータとパフォーマンスが分離され、カスタマイズ可能であることを保証します。各クライアントは、異なるアプリケーションやユースケースのために、専用データベース内で共有テーブルを持つことができます。
TiDBにおけるマルチテナント設計：知っておくべきこと
TiDBにおけるマルチテナントアーキテクチャの設計には、セキュリティ、パフォーマンス、スケーラビリティを確保するためのいくつかの重要な要素があります。これらの考慮事項に慎重に対処することで、多様な要件を満たしつつ、堅牢な運用効率を維持するためのマルチテナント環境を最適化できます。TiDBでマルチテナントを実装する際に考慮すべき重要な側面をご説明します。
アイソレーション
- Data Isolation (データ・アイソレーション)：厳格なアクセス制御を実施し、テナントが自分のデータにのみアクセスできるようにします。ここでは、TiDBのユーザーおよびロール管理機能が重要な役割を果たします。
- Performance Isolation (パフォーマンス・アイソレーション)：リソース管理の手法を使用して、あるテナントのワークロードが他のテナントに影響を与えないようにします。これには、クォータの設定やTiDBのリソース割り当て機能を使用することができます。
スケーラビリティ
TiDBの horizontal scalability (水平スケーラビリティ) は大きなメリットです。 テナントの数が増加するにつれて、クラスタにノードを追加することでパフォーマンスを維持し、負荷の増加に対応することができます。
セキュリティ
保存時と通信時の両方で、暗号化などの堅牢なセキュリティ対策を導入しています。TiDBのセキュリティツールとの統合を利用して、データの監視と保護を行うことができます。
カスタマイゼーション
テナント独自の設定やカスタマイズを可能にします。TiDBはスキーマレベルのカスタマイズをサポートしており、テナントはニーズに合わせて環境をカスタマイズできます。
コストパフォーマンス
適切なマルチテナントモデルを選択することで、リソースの利用効率を最適化します。共有モデルはコスト削減を図れる一方、別々のデータベースは高額な料金を支払うテナント向けにプレミアムサービスを提供します。
TiDBでマルチテナント・アーキテクチャを実装するための最初のステップ
TiDBにおけるマルチテナントアーキテクチャの実装には、効率的で安全かつスケーラブルな運用を確保するためのいくつかの実践的なステップが必要です。このセクションでは、スキーマ設計、アクセス制御、リソース管理、監視とメンテナンス、バックアップとリカバリという重要な分野について説明します。
スキーマの設計
スキーマ設計は、マルチテナントのデータをどのように構造化し、分離するかを決定します。TiDBは、共有スキーマ、個別スキーマ、または専用データベースをサポートする柔軟なスキーマ管理を提供し、さまざまなユースケースに最適な論理的分離を可能にします。
アプローチ
共有スキーマ：すべてのテナントに対して単一のスキーマを使用し、テナント識別子カラムを使用してデータを分離します。
- 長所：管理が簡素化され、リソースの効率が最大化されます。
- 短所：テナントの分離を確保するために、慎重なクエリ設計が必要です。
スキーマの分離: 同じデータベース内に各テナントごとに固有のスキーマを作成します。
- 長所：論理的なデータ分離が向上し、アクセス制御が簡素化されます。
- 短所：テナント数が増えるにつれて、管理が複雑になる可能性があります。
データベースの分離：テナントごとに個別のデータベースまたはクラスタを割り当てます。
- 長所：最高レベルのアイソレーションとカスタマイズを実現します。
- 短所：運用コストと手間が増加します。
ベストプラクティス
- 一貫した命名規則：テーブルやスキーマに対して体系的な命名規則を使用し、管理を簡素化します。
- テナント識別子：共有スキーマの場合、すべてのテーブルにテナント識別子のカラムを含め、その使用をすべてのクエリで強制します。
アクセスコントロール
アクセス制御により、各テナントが自分のデータにしかアクセスできないようにし、セキュリティとプライバシーを維持します。TiDBのロールベースのアクセス制御 (RBAC：Role-Based Access Control) とスキーマレベルのアクセス許可は、論理的なマルチテナント戦略に不可欠です。
アプローチ
- Role-Based Access Control (RBAC)：TiDBに組み込まれているRBAC機能を使ってロールを作成し、特定の権限を持つテナントに割り当てます。
- Schema-Level Permissions：個別のスキーマに対して、スキーマレベルのアクセス許可を設定し、テナント固有のデータへのアクセスを制限します。
ベストプラクティス
- 最小権限の原則：テナントには、業務に必要な最小限の権限のみを付与します。
- 定期的な監査：アクセス制御の定期監査を実施し、権限が正しく設定され、維持されていることを確認します。
リソース・マネジメント
リソースマネジメントは、リソースの競合を防ぎ、テナント間の公平なリソース分配を確保します。
アプローチ
- クォータ管理：CPU、メモリ、ストレージのクォータを設定し、単一のテナントが消費できるリソースを制限します。
- レート制限：特定の期間内にテナントが行えるリクエストの数を制御するために、レート制限を実装します。
ベストプラクティス
- リソース監視：リソースの使用状況を継続的に監視し、潜在的なボトルネックを特定して軽減します。
- 動的割り当て：TiDBの動的リソース割り当て機能を利用して、テナントの需要に応じてリソースを調整します。
モニタリング＆メンテナンス
効果的なモニタリングとメンテナンスにより、マルチテナント環境のスムーズな運用と高いパフォーマンスを確保します。
アプローチ
- パフォーマンス監視：TiDBの監視ツールを使用して、クエリのレイテンシ、スループット、リソース利用率などの重要なパフォーマンス指標を追跡します。
- ヘルスチェック：定期的にヘルスチェックを実施し、問題を事前に検出して解決します。
ベストプラクティス
- 中央集中型ダッシュボード：システムのパフォーマンスやテナントの活動を包括的に把握するために、中央集中型の監視ダッシュボードを利用します。
- 自動アラート：重要なパフォーマンス閾値や異常に対する自動アラートを設定します。
バックアップとリカバリー
バックアップとリカバリープロセスは、テナントのデータを損失から守り、ビジネスの継続性を確保します。
アプローチ
- 定期的なバックアップ：マルチテナントモデルに応じて、全データベースまたは個別のスキーマの定期的なバックアップをスケジュールします。
- ポイントインタイムリカバリ (PiTR) を可能にして、障害時のデータ損失を最小限に抑えます。
ベストプラクティス
- テナント特有のバックアップ：別々のスキーマやデータベースに対して、テナントのニーズに基づいたバックアップ頻度や保持期間を調整するためのテナント特有のバックアップポリシーを設定します。
- 災害復旧計画：主要な障害から迅速かつ効率的に復旧するための包括的な災害復旧計画を策定し、テストします。
まとめ
マルチテナントアーキテクチャは、単一のデータベースインスタンスが複数の顧客にサービスを提供し、各顧客が論理的にデータを分離して独立して運営できることを可能にします。このアプローチは、リソースの利用を最適化し、スケーラビリティを向上させ、管理を簡素化するため、SaaSアプリケーション、クラウドサービスプロバイダー、エンタープライズアプリケーションに最適です。
TiDBは、共有データベース・共有スキーマ、共有データベース・分離スキーマ、分離データベースといったさまざまなモデルを通じて、効果的にマルチテナントをサポートします。スキーマ設計、アクセス制御、リソース管理、監視、バックアップとリカバリといった重要な領域に焦点を当てることで、TiDBは効率的で安全かつスケーラブルなマルチテナント環境を実現します。
データベース管理を変革する準備は整いましたか？以下の包括的なガイドをぜひご覧いただき、これまでにない効率性とスケーラビリティのために、組織内でマルチテナントの導入をご検討ください。
TiDB Cloud Dedicated
TiDB Cloudのエンタープライズ版。
専用VPC上に構築された専有DBaaSでAWSとGoogle Cloudで利用可能。
TiDB Cloud Serverless
TiDB Cloudのライト版。
TiDBの機能をフルマネージド環境で使用でき無料かつお客様の裁量で利用開始。