Actian PSQL を使用した マルチテナント アプリケーションの作成 Actian PSQL ホワイト ペーパー 2013 年 5 月 このホワイト ペーパーは、Software-as-a-Service (SaaS: サービスとしてのソフトウェア) のすべての要件を、Actian PSQL により簡単に実現する方法を説明する一連のホワイト ペーパーの 1 つです。その他のホワイト ペーパー『VMware vFabric SQLFire を利用し たデータ ストアとしての Actian PSQL の使用』では、キャッシュ エンジンと VMware SQLFire を使用した PSQL の水平方向への拡張について説明します。このホワイト ペー パーは AGBP 会員限定サイトから入手できます。 マルチテナントと Actian PSQL の最適な組み合わせ クラウド コンピューティングとそのサブタイプである Software-as-a-Service (SaaS) のコ ンポーネントは、アナリストによって異なりますが、どの場合でも名前が挙がるのがマ ルチテナントです。 "マルチテナント" とは、サーバー上で実行されるソフトウェアのインスタンスが 1 つ だけにもかかわらず、そのインスタンスで複数のテナントに対応できるソフトウェア アーキテクチャのことです。これは、各部屋に異なる住人が住み、すべての住人が共同 設備を共有しながらも、それぞれのプライバシーを確保できる下宿に似ています。 マルチテナントは比較的新しい概念であるため、データベース ソフトウェア会社は、 テナント間で 1 つのアプリケーションを共有しながらも各テナントのデータを分離する ための最適な方法を確立しようと先を争っています。PSQL は、他のデータベースでは 必要な再設計を行わずにマルチテナントを実現できるよう、独自に構築されました。さ らに、PSQL では、常にマルチテナントがアーキテクチャの一部として含まれてきたの で、他のデータベースの場合とは異なり、データの分離を行う作業にコストがかかりま せん。PSQL を使用すると、予想よりも低いコストで容易に SaaS の準備を行うことが できます。 マルチテナントへの一般的なアプローチ SaaS では、マルチテナントへのアプローチは 2 つの大まかなカテゴリに分類されます。 1 つは、共有インフラストラクチャ内の専用リソースへの依存と、もう 1 つは、メタ データの使用による共有スキーマ内での操作です。PSQL はこの両方のアプローチをサ ポートすると同時に、それぞれの欠点のいくつかを回避する方法も提供しています。 専用リソース 専用リソースのアプローチとは、テナントごとに 1 つの独立したデータベース (物理ま たは仮想) を使用する方法です。これにより、各テナントのアクセスが特定のリソース だけに制限されます。テナント間でコンピューティング リソースとアプリケーション コードを共有しつつ、各テナントのデータは論理的に分離され、メタデータによってテ ナントに接続されます。制限事項には、ハードウェア コストがより高いことが挙げら れます。各サーバーでサポートできるテナントの数に限りがあるためです。また、保守 やバックアップにもより高いコストがかかります。 ©2013 Actian Corporation. All rights reserved. Printed in the U.S.A. Actian は、米国およびその他の国における Actian Corporation の商標 です。本書に記載されているその他の商標、商品名、サービス マーク、およびロゴは、各社の商標です。 2 共有スキーマ 一方、共有スキーマのアプローチでは、すべてのテナントに対し単一のデータベースを 使用します。この方法にはいくつかあります。各テナントに同じデータベース スキー マ内の別々のテーブル セットを割り当てることも、すべてのテナントで同じテーブル を共有することも可能です。後者の場合、テーブルには各レコードのオーナーを識別す るための列が別途必要になります。テーブルに依存する共有スキーマの方法は、明らか にリレーショナル データベース モデルの産物です。また、そのモデルに依存するデー タベース エンジンにとっては、ハードウェア コストを抑える効果があるため、これが 最もコスト効率の高いアプローチとなることが考えられます。ただし、単一テナントか らマルチテナントへのアプリケーションの再設計が必要になります。また、データの分 離性とセキュリティが低下します。障害が発生した場合、一部のテーブルや一部のレ コードのみを復元するプロセスに時間と労力がかかる可能性があり、保守が複雑になり ます。 共有スキーマの方法は、テナントの数や各テナントのデータ サイズに応じて異なる手 段で展開できます。1 つのデータベースではすべてのテナントをサポートするのに不十 分な場合、追加データベースでスキーマのレプリケーションを行うことになります。追 加データベースでレプリケーションを行う論理的拡張は、各データベースを個別に構成 することであり、共有スキーマの方法と専用リソースの方法の中間点を目指すものです。 マルチテナントの方法 専用 リソース 共有 スキーマ データの分離性は向上するが、 ハードウェア コストが増大する テナント 1 テナント 2 テナント 3 ©2013 Actian Corporation. All rights reserved. Printed in the U.S.A. Actian は、米国およびその他の国における Actian Corporation の商標 です。本書に記載されているその他の商標、商品名、サービス マーク、およびロゴは、各社の商標です。 3 マルチテナントに向けた PSQL のアプローチ PSQL には、その他のオプションも用意されています。これは、PSQL が、リレーショ ナル データベースだけでなく、トランザクショナル NoSQL ストレージ エンジンであ る MicroKernel Database エンジン (MKDE) へのインターフェイスも提供しているからで す。MKDE のアーキテクチャで独自にマルチテナントを実現し、データの分離性を犠 牲にしたりハードウェア コストの増加を招くこともないので、リレーショナル データ ベースでの作業を好むアプリケーション開発者にとっても有用です。 MKDE では、サーバー上の特定のディレクトリ内に格納されている複数のファイルに データが整理されます。複数のテナントに対応するには、複数のテーブルや同じテーブ ル内の複数のテナント ID ではなく、複数のディレクトリが必要になります。最初の ディレクトリのファイル レコード レイアウトは、追加テナントごとに別のディレクト リ内に重複して配置できます。アプリケーション開発者が Btrieve API ではなく SQL を 使用してデータにアクセスすることを好む場合は、テナントごとにセキュリティで保護 された個別のリレーショナル データベースを作成できます。 このアプローチによって以下のような利点が得られます。 アプリケーションの再設計にかかるコストを回避できます。各テナントは元のレ コード レイアウトを使用します。 データの分離性を確保できます。各テナントのデータは、共有スキーマではなく個 別のディレクトリ内に配置されます。 一意の Btrieve オーナー ネームとそのネームがスタンプされたファイルの割り当て によって、あるいはリレーショナル レベルでのデータベース セキュリティの確立に よって、各テナントのプライバシーを保証できます。 バックアップ プロセスと復元プロセスを簡略化できます。各ディレクトリのバック アップと復元は個別に完全に行うことができ、その他のテナントのデータや処理に 一切影響しません。 Btrieve API を使用するアプリケーション開発者は、Btrieve への直接アクセスによっ てより高速かつ直接的にデータを操作できます。 ©2013 Actian Corporation. All rights reserved. Printed in the U.S.A. Actian は、米国およびその他の国における Actian Corporation の商標 です。本書に記載されているその他の商標、商品名、サービス マーク、およびロゴは、各社の商標です。 4 マルチテナントに向けた PSQL のアプローチ: トランザクショナル テナント 1 テナント 2 テナント 3 tenant1 ディレクトリ tenant1 ディレクトリ tenant1 ディレクトリ datafile1 datafile1 datafile1 datafile2 datafile2 datafile2 datafile3 datafile3 datafile3 tenant2 ディレクトリ tenant2 ディレクトリ datafile1 datafile1 datafile2 datafile2 datafile3 datafile3 tenant3 ディレクトリ datafile1 datafile2 datafile3 上の図のように、テナント 1 のデータはサーバー上にデータ ファイルのディレクトリ の形式で存在します。各データ ファイルには、テナント 1 の一意の Btrieve ネームがス タンプされています。テナント 1 が SaaS プロバイダーのソフトウェア アプリケーショ ンにアクセスしてそのアプリケーションを使用する場合、テナント 1 は tenant1 ディレ クトリ内のデータを操作します。テナント 2 が同じアプリケーションをサブスクライブ すると、プロバイダーはテナント 2 のデータ用に異なるディレクトリを作成します。テ ナント 2 には一意の Btrieve ネームが割り当てられ、テナント 2 のディレクトリに含ま れるデータ ファイルには、テナント 2 の一意の Btrieve ネームがスタンプされます。こ のプロセスは、後続のテナントが同じサービスをサブスクライブするたびに繰り返され ます。各テナントには、個別のディレクトリと一意の Btrieve ネームが割り当てられ、 各テナントのディレクトリに含まれるすべてのファイルにその Btrieve ネームがスタン プされます。 ©2013 Actian Corporation. All rights reserved. Printed in the U.S.A. Actian は、米国およびその他の国における Actian Corporation の商標 です。本書に記載されているその他の商標、商品名、サービス マーク、およびロゴは、各社の商標です。 5 アプリケーション開発者が SQL を使用してデータにアクセスすることを好む場合につ いては、次の図でそのプロセスを示します。 マルチテナントに向けた PSQL のアプローチ: リレーショナル Tenant1 データベース Tenant1 データベース Tenant1 データベース テーブル 1 テーブル 2 テーブル 3 テーブル 1 テーブル 2 テーブル 3 Tenant2 データベース テーブル 1 テーブル 2 テーブル 3 テーブル 1 テーブル 2 テーブル 3 Tenant2 データベース テーブル 1 テーブル 2 テーブル 3 Tenant2 データベース テーブル 1 テーブル 2 テーブル 3 テナント 1 が SaaS プロバイダーのソフトウェア アプリケーションにアクセスしてその アプリケーションを使用する場合、テナント 1 は Tenant1 データベース内のデータを操 作します。セキュリティで保護されたログイン プロセスにより、テナント 1 だけがそ のデータベース全体にアクセスできるようになります。テナント 2 には別のデータベー スが提供され、同様にデータベース レベルでロックされます。このプロセスは、テナ ントが追加されるたびに繰り返されます。 ©2013 Actian Corporation. All rights reserved. Printed in the U.S.A. Actian は、米国およびその他の国における Actian Corporation の商標 です。本書に記載されているその他の商標、商品名、サービス マーク、およびロゴは、各社の商標です。 6 結論 このような SaaS への流れを利用したくても、ソフトウェアの再設計にかかるコストや データの分離に対する顧客のニーズを考えて行動をためらっている ISV や OEM にとっ て、PSQL はコストとセキュリティの両面をカバーするソリューションとなります。既 存のアプリケーションで社内の部門や場所ごとにデータが分離されている場合、PSQL に既に搭載されたマルチテナント機能により、予想以上に SaaS への準備が進むでしょ う。そのアーキテクチャのストレージ エンジン レベルにアクセスできるので、リレー ショナル スキーマの共有に関する問題を回避できます。また、その固有のディレクト リ構造により、複数のデータベースの提供と保守にかかるコストや、レコード レイア ウトの再設計にかかるコストを生じさせずに、データの分離性を確保できます。 ©2013 Actian Corporation. All rights reserved. Printed in the U.S.A. Actian は、米国およびその他の国における Actian Corporation の商標 です。本書に記載されているその他の商標、商品名、サービス マーク、およびロゴは、各社の商標です。 7
© Copyright 2024 Paperzz
