↩ テクノロジークラウドコンピューティング非公開: クラウドコンピューティングにおけるシングルテナントとマルチテナントの理解

クラウドコンピューティングにおけるシングルテナントとマルチテナントの理解

クラウドコンピューティングでは、テナントという用語は、ストレージ、サーバー、アプリケーションなどのコンピューティングリソースの共有プールにアクセスできるグループまたは個々のユーザーを表します。リソースはクラウドサービスプロバイダーによって提供されます。

各テナントは他のテナントから分離されており、相互にデータやリソースにアクセスすることはできません。複数のテナントは、独自のプライバシーとセキュリティを維持しながら、同じインフラストラクチャを共有できます。テナントは、個人、組織、または組織内の部門になります。

リソースとインフラストラクチャが 1 つのテナントのみに専用である場合、そのようなアーキテクチャをシングルテナントと呼びます。複数の異なるテナントが同じリソースを共有する場合、これはマルチテナントアーキテクチャを表します。

ただし、シングルテナントアーキテクチャとマルチテナントアーキテクチャの違いは少し複雑です。たとえば、AWS をクラウドサービスプロバイダーとして使用して、マルチテナントアーキテクチャだけでなくシングルテナントアーキテクチャもセットアップできます。違いは細部にあります。どうぞ。

ここで、詳細に入る前に、両方のアーキテクチャの概要を見てみましょう。

特徴	シングルテナントアーキテクチャ	マルチテナントアーキテクチャ
リソースの共有	他の人とは共有されません	複数のお客様で共有
カスタマイズ	高度にカスタマイズ可能	限定的なカスタマイズ
料金	一般的にはより高価です	一般的には安価です
安全	セキュリティの強化	セキュリティレベルが低い
パフォーマンス	予測可能なパフォーマンス	スケーラビリティへの影響
メンテナンス	顧客がリソースを維持する	クラウドプロバイダーがメンテナンスを担当
コラボレーション	限定コラボ	より優れたコラボレーション
コンプライアンス	特定の規制へのコンプライアンスの向上	すべてのテナントの標準プロセス

コンテンツ 表示

シングルテナントアーキテクチャ

シングルテナントのクラウドアプリケーションは、単一の顧客または組織にサービスを提供し、他の顧客と共有されない専用のリソースを提供するように設計されています。

これは、単一の顧客またはテナントがクラウド内のサーバー、アプリケーション、またはインフラストラクチャに排他的にアクセスできるモデルです。このモデルでは、顧客はリソースを完全に制御でき、特定のニーズに合わせてリソースをカスタマイズできます。これは、クラウドリソースがその顧客専用であることを意味します。

この単一テナントは、特定のニーズに合わせてリソースをカスタマイズできます。これは、リソースに対する柔軟性と制御が向上することを意味します。

顧客のみが専用リソースの料金を支払うため、一般にマルチテナントアーキテクチャよりも高価になります。

以下は、AWS クラウドでエンドツーエンドのシングルテナントアーキテクチャを構築する方法の例です。

仮想プライベートネットワーク (VPC) を作成して、単一テナントのリソースを分離します。 VPC はネットワークの分離とセキュリティを提供します。
Identity and Access Management (IAM) を使用して、単一テナントのリソースへのアクセスを管理します。 IAM は、テナントがアクセスできるリソースを定義するポリシーを作成します。
Elastic Compute Cloud (EC2) を使用して、単一テナントに仮想マシンをプロビジョニングします。 EC2 は、特定の構成でインスタンスを作成し、リソースを完全に制御します。
Elastic Block Store (EBS) を使用して、仮想マシンにブロックレベルのストレージを提供します。
リレーショナルデータベースサービス (RDS) を使用して、単一テナントにマネージドデータベースサービスを提供します。テナント用に別のデータベースインスタンスを作成して、分離とセキュリティを提供できます。
Amazon S3 を使用して、画像、ビデオ、ドキュメントなどの静的資産を保存します。テナントのみがアクセスできる、テナント用の別のバケットを作成できます。
Elastic Load Balancer (ELB) を使用して、アプリケーションの複数のインスタンス間でトラフィックを分散し、すべてテナント専用のリソース内に分散します。

クラウドアプリケーションの例

ここでは、シングルテナントアーキテクチャに使用できる最もよく知られているクラウドアプリケーションをいくつか紹介します。

Workday は、顧客にシングルテナントアーキテクチャを提供するクラウドベースの人事および財務管理ソフトウェアです。
SAP HANA クラウドベースのプラットフォーム。
Oracle Cloudのアーキテクチャ。
他の顧客と共有されない専用リソースを備えた IBM Cloud Dended。
ラックスペースプライベートクラウド。

シングルテナントクラウドアーキテクチャの利点

シングルテナントのクラウドアーキテクチャには、マルチテナントアーキテクチャに比べていくつかの利点があります。

リソースが単一の顧客専用であるため、セキュリティが強化されます。顧客はリソースのセキュリティを完全に制御できます。マルチテナント環境で発生する可能性のあるデータ漏洩や不正アクセスのリスクを排除します。
カスタマイズ性が高いことも利点です。リソースをカスタマイズして特定のニーズを満たすことができるため、パフォーマンスと効率が向上します。また、ソフトウェアとハードウェアの選択に関してもより柔軟になります。
リソースが単一の顧客専用であるため、パフォーマンスが予測可能です。一貫したパフォーマンス負荷が期待できます。これは、高レベルのパフォーマンスと信頼性を必要とするアプリケーションにとって重要です。
リソースは 1 つのテナントのみに使用されるため、特定の規制や標準への準拠が向上します。
お客様は必要に応じてリソースをスケールアップまたはスケールダウンできるため、スケーラビリティが向上します。

ただし、シングルテナントアーキテクチャは一般にマルチテナントアーキテクチャよりも高価であるため、すべての組織にとって最適な選択であるとは限りません。

シングルテナントクラウドアーキテクチャの実世界のユースケース

シングルテナントアーキテクチャの最適な使用例をいくつか示します。

医療機関は、高レベルのセキュリティとプライバシーを必要とする HIPAA などの厳格な規制に準拠する必要があります。シングルテナントアーキテクチャにより、医療機関はリソースを完全に制御し、患者とスタッフのニーズに合わせたセキュリティ対策を実装できます。
金融機関はPCI DSSなどの厳しい規制に準拠することが求められています。したがって、シングルテナントアーキテクチャは優れたソリューションです。
政府機関は FISMA などの厳格な規制に準拠する必要があり、やはり高レベルのセキュリティとコンプライアンスが要求されます。
研究組織は多くの場合、リソースに対して高度なカスタマイズとパフォーマンスを必要とします。
電子商取引組織は、シングルテナントアーキテクチャのもう 1 つの使用例です。顧客の変化するニーズに合わせて、必要に応じてリソースをスケールアップまたはスケールダウンできます。

マルチテナントアーキテクチャ

SaaS-マルチテナント-サーバーレス — 出典: aws.amazon.com

マルチテナントアーキテクチャは、多くの場合、高度なセキュリティやカスタマイズのニーズよりもコスト削減、拡張性、コラボレーションを優先する組織にとって最適なソリューションです。

複数の顧客がクラウド内の同じリソースを共有します。これは、リソースが特定の顧客専用ではなく、すべての顧客間で共有されることを意味します。
マルチテナントアーキテクチャは、単に共有リソースの性質により、一般的にシングルテナントアーキテクチャよりも安価です。
実行できるカスタマイズには制限があります。これは、高度にカスタマイズされたリソースを必要とする顧客にとっては不利になる可能性があります。

以下は、AWS クラウドでエンドツーエンドのマルチテナントアーキテクチャを構築する方法の例です。

VPC を作成して、各テナントのリソースを分離します。各テナントは独自の VPC を持ち、ネットワークの分離とセキュリティを提供します。
IAM を使用して、各テナントのリソースへのアクセスを管理します。 IAM は、ポリシーと各テナントがアクセスできるリソースを定義します。テナントごとに異なるポリシーを適用できます。
ELB を使用して、アプリケーションの複数のインスタンスにトラフィックを分散します。どのトラフィックがどのテナントに送信されるかを制御します。
RDS を使用して、各テナントにマネージドデータベースサービスを提供します。個別のデータベース権限とデータコンテンツを使用して、テナントごとに個別のデータベースインスタンスを作成します。同じデータベースクラスターを使用できます。これにより、テナントに隔離とセキュリティが与えられます。
Amazon S3 を使用して、画像、ビデオ、ドキュメントなどの静的資産を保存します。テナントのバケットへのアクセスを制御できます。複数のアカウント間で共有したり、必要に応じて分離したりできます。
CloudFront を使用して静的アセットをユーザーに配布します。テナントごとに個別のディストリビューションを作成すると、分離性とセキュリティが確保されます。

クラウドアプリケーションの例

マルチテナントクラウドアプリケーションの実例をいくつか示します。

Salesforce は、データを分離して安全に保ちながら、複数の組織が同じインフラストラクチャを使用できるようにするクラウドベースの顧客関係管理 (CRM) プラットフォームです。
Dropbox は、複数のユーザーが同じファイルで共同作業できるようにするクラウドベースのファイルストレージおよび共有サービスです。
Microsoft Office 365 は、複数のユーザーが同じドキュメント、スプレッドシート、プレゼンテーションで共同作業できるようにするクラウドベースの生産性スイートです。
Google Workspace は、Microsoft のものと同様のクラウドベースの生産性スイートです。
AWS は、データを分離して安全に保ちながら、複数の組織が同じインフラストラクチャを使用できるようにするクラウドベースのインフラストラクチャプラットフォームです。

マルチテナントアーキテクチャの利点

マルチテナントクラウドアーキテクチャには、次のような特有の利点があります。

このアーキテクチャは通常、シングルテナントアーキテクチャよりも安価です。複数の顧客がリソースを共有します。
スケーラビリティへの影響が大きくなります。リソースは、顧客がリソースを共有する際に変化するニーズを満たすために、必要に応じてスケールアップまたはスケールダウンします。すべて同時にスケーリングされます。
このアーキテクチャでは、必要なメンテナンスが少なくなります。クラウドプロバイダーは、すべてのテナントで同じリソースを維持する責任があります。したがって、メンテナンスは 1 回だけ実行します。
顧客は同じリソースを共有しているため、顧客間のコラボレーションが強化されます。顧客はプロジェクトで共同作業し、より効率的にデータを共有できます。
このアーキテクチャは標準化を促進します。クラウドプロバイダーは、標準のプロセスと手順を実装し、それらをすべてのテナントに同時に適用できます。

ただし、組織が高レベルのセキュリティ、コンプライアンス、またはカスタマイズを必要とする場合、マルチテナントアーキテクチャは最良の選択ではない可能性があります。共有リソースにより、これらすべての機会が減少しています。

マルチテナントアーキテクチャの実世界の使用例

マルチテナントアーキテクチャの最良の使用例をいくつか示します。

中小企業 (SMB) は予算やリソースが限られていることが多いため、マルチテナントアーキテクチャが魅力的な選択肢となっています。
Software as a Service (SaaS) プロバイダーは、マルチテナントアーキテクチャを使用して複数の顧客にサービスを提供します。
ソーシャルメディアプラットフォームには、高レベルの拡張性とコラボレーションが必要です。マルチテナントアーキテクチャにより、ソーシャルメディアプラットフォームは、ユーザーの変化するニーズを満たすために、必要に応じてリソースをスケールアップまたはスケールダウンできます。
教育機関は多くの場合、IT インフラストラクチャに対してコスト効率の高いソリューションを必要とします。マルチテナントアーキテクチャにより、教育機関はリソースのコストを他の機関と共有できるため、コストが削減されます。
パブリッククラウドプロバイダーは、マルチテナントアーキテクチャを使用して、複数の顧客にサービスを提供します。

AWS クラウドはどこに適合しますか?

上で述べたように、AWS はシングルテナントアーキテクチャとしてもマルチテナントアーキテクチャとしてもセットアップできます。

単一の顧客または組織専用のインフラストラクチャを作成できます。たとえば、AWS には、単一の顧客専用の物理サーバーを提供する EC2 専用ホストがあります。これにより、顧客は基盤となるハードウェアを完全に制御できるようになります。

AWS には、顧客が AWS クラウド内に分離された仮想ネットワークを作成できる Virtual Private Cloud (VPC) もあります。

ただし、AWS は、共有インフラストラクチャの作成に使用できるさまざまなサービスを提供します。たとえば、AWS は、複数の顧客が共有できる仮想サーバーを提供する EC2 インスタンス (専用ではありません) を提供しています。その後、独自のプライバシーとセキュリティを維持しながら、同じ基盤となるハードウェアとインフラストラクチャを共有します。

または、複数の顧客間で同じストレージを共有できる Amazon S3 などのサービスを使用することもできます。顧客は共有環境でデータを保存および取得できます。

AWS の RDS データベースに関しても、さまざまな方法でセットアップするオプションがあります。テナントごとに個別のデータベースインスタンスを作成することもできます。単一テナント用に専用のデータベースクラスターとインスタンスを作成することもできます。

最後に、RDS を使用して、複数のテナント用の共有データベースサービスを作成できます。その場合、そのようなデータベースインスタンスは複数のテナントをサポートし、最終的にはそのカスタマイズレベルやパフォーマンスが制限されます。

これは、プラットフォームがシングルテナントアーキテクチャかマルチテナントアーキテクチャかを決定するものではないことを意味します。それよりも、プラットフォームをどのように構成してセットアップするかが重要です。

最後の言葉

シングルテナントアーキテクチャとマルチテナントアーキテクチャのどちらを選択するかは、顧客の特定のニーズによって異なります。一般に、シングルテナントアーキテクチャは、高レベルのセキュリティ、コンプライアンス、カスタマイズを必要とする組織に適しています。マルチテナントアーキテクチャは、コスト削減と拡張性を優先する組織に適しています。

たとえば AWS のようなクラウドプラットフォームは、時間の経過とともに考えを変える可能性を提供します。これらを使用して、各ケースが独自の場所を持ち、適切に連携するハイブリッド環境を作成することもできます。

次に、クラウドコンピューティングにおけるマルチテナントについて説明します。