顧客データをどう管理する？マルチテナントDBの設計パターン完全ガイド

複数の顧客向けにSaaSアプリケーションを開発していますか？

そうなら、必ず直面する問題があります。
データベースをどう設計するかという問題です。

顧客ごとに別々のデータベースを用意するか。
それとも一つのデータベースで全顧客のデータを管理するか。
この選択は、アプリケーションの将来を大きく左右します。

私も過去に同じ悩みを抱えました。
不動産管理システムを開発した際、最初は顧客ごとに個別のインスタンスを立ち上げていました。
しかし、顧客が増えるにつれて、このアプローチの限界が見えてきたのです。

なぜこの選択が重要なのか

データベース設計の選択は、後から変更するのが非常に困難です。

一度決めた方針を変更するには、大規模なデータ移行が必要になります。
そして、コードの書き換えも避けられません。

さらに、この選択は多くの要素に影響を与えます。

開発の複雑さはどうなるか。
運用コストはどれくらいかかるか。
セキュリティレベルは十分か。
パフォーマンスは維持できるか。

そして、将来的なスケーラビリティは確保できるか。
これらすべてが、データベース設計の選択によって大きく変わってきます。

単一データベース方式の実際

単一データベースアプローチは、すべての顧客データを一つのデータベースに格納します。
各レコードにはtenant_idというフィールドを追加します。
これによって、どの顧客のデータかを識別するのです。

このアプローチの最大のメリットは、シンプルさです。
データベースの管理が一元化されます。
バックアップや監視も簡単になります。

# 単一データベースでのクエリ例
def get_user_properties(tenant_id, user_id):
    return db.query(
        "SELECT * FROM properties WHERE tenant_id = ? AND user_id = ?",
        [tenant_id, user_id]
    )

しかし、注意すべき点もあります。
すべてのクエリにtenant_idを含める必要があるのです。
一つでも忘れると、データ漏洩のリスクが生じます。

私の経験では、フレームワークレベルでこの問題を解決するのが効果的でした。
たとえば、LaravelやDoctrine ORMを使えば、自動的にtenant_idフィルタを適用できます。

複数データベース方式の実際

複数データベースアプローチでは、顧客ごとに独立したデータベースを作成します。
データの分離が物理的に保証されます。
これは、セキュリティ面で大きな利点となります。

# 複数データベースでの接続切り替え例
def get_tenant_connection(tenant_id):
    db_config = get_tenant_db_config(tenant_id)
    return create_connection(db_config)

def get_user_properties(tenant_id, user_id):
    conn = get_tenant_connection(tenant_id)
    return conn.query("SELECT * FROM properties WHERE user_id = ?", [user_id])

このアプローチの利点は明確です。
データが完全に分離されているため、誤って他の顧客のデータにアクセスすることはありません。
また、特定の顧客のデータベースだけをスケールアップすることも可能です。

しかし、運用面での課題もあります。
データベースのマイグレーションを各データベースに対して実行する必要があるのです。
その管理は複雑になります。

実践的な選択基準

では、どちらを選ぶべきでしょうか？
以下の基準で判断することをお勧めします。

単一データベースを選ぶべき場合：
顧客数が多い場合（数千以上）。
各顧客のデータ量が比較的少ない場合。
全顧客に対する集計レポートが必要な場合。
そして、開発リソースが限られている場合です。

複数データベースを選ぶべき場合：
顧客数が少ない場合（数百程度）。
各顧客のデータ量が多い場合。
契約上、データの完全な分離が要求される場合。
また、顧客ごとに異なるデータベース構造が必要な場合です。

ハイブリッドアプローチ

実は、第三の選択肢もあります。
単一のデータベースサーバー内で、複数のスキーマを使用する方法です。

PostgreSQLやMySQLでは、一つのデータベースサーバー内に複数のスキーマを作成できます。
MySQLの場合は、これを「データベース」と呼びます。

これにより、データの論理的な分離を保てます。
同時に、管理の簡素化も実現できるのです。

-- PostgreSQLでのスキーマ分離例
CREATE SCHEMA tenant_001;
CREATE SCHEMA tenant_002;

-- 各スキーマに同じテーブル構造を作成
CREATE TABLE tenant_001.properties (...);
CREATE TABLE tenant_002.properties (...);

このアプローチは、両方の利点を併せ持ちます。
データは論理的に分離されます。
かつ、単一のデータベースサーバーで管理できるのです。

パフォーマンスとスケーラビリティ

パフォーマンスの観点では、どちらのアプローチも適切に実装すれば問題ありません。

単一データベースの場合、インデックスの設計が重要になります。
すべてのインデックスにtenant_idを含める必要があるのです。
これによりインデックスサイズが増加します。

しかし、現代のデータベースエンジンは優秀です。
適切にインデックスされた数百万レコードも効率的に処理できます。

複数データベースの場合、各データベースのサイズが小さくなります。
そのため、個々のクエリは高速になります。
ただし、クロステナントの集計処理は複雑になってしまいます。

移行とメンテナンス

データベースのマイグレーションは、複数データベース方式では大きな課題となります。

私が経験した中で最も効果的だった方法があります。
それは、段階的なロールアウトです。

まずテスト用の顧客データベースに適用します。
問題がなければ、小規模な顧客から順次適用していく方法です。

# 段階的マイグレーションの例
def migrate_tenants(migration_script):
    test_tenants = get_test_tenants()
    for tenant in test_tenants:
        apply_migration(tenant, migration_script)
        verify_migration(tenant)

    if all_tests_passed():
        production_tenants = get_production_tenants_by_size()
        for tenant in production_tenants:
            apply_migration(tenant, migration_script)
            monitor_health(tenant)