AWSにおけるシングルテナントとマルチテナントの違い
大規模な組織やパブリッククラウドにおいて、複数のユーザー向けにソフトウェアを展開するには、さまざまなアプローチがあります。どのアプローチやソフトウェア展開アーキテクチャを選択するかは、さまざまな要因によって異なります。そのため、シングルテナントとマルチテナントというアーキテクチャタイプの違いを理解しておくことは有益です。このブログ記事では、これら2つのタイプを比較し、クラウドベースのバックアップサービスの枠組みの中でマルチテナントをどのように活用できるかについて解説します。
シングルテナントとは？
シングルテナントとは、各クライアント／顧客または組織が、アプリケーションの個別の独立したインスタンスを保有するソフトウェアアーキテクチャの一種です。つまり、各顧客は専用のサーバーまたはインフラストラクチャを保有しており、それらはその顧客のみが排他的に使用し、他の顧客とは共有されません。
シングルテナントのユースケース
シングルテナントアーキテクチャの最も一般的なユースケースについて、以下で説明します。
- シングルテナントは通常、組織がアプリケーションに対して高度なセキュリティ、プライバシー、およびカスタマイズを必要とする状況で使用されます。金融、医療、政府機関など、機密データを扱う業界でよく利用されています。
- また、シングルテナントは、カスタマイズされたソフトウェアソリューションを必要とする、複雑なIT環境を持つ大規模な組織でも一般的に利用されています。こうした組織では、独自のワークフロー、データ構造、またはビジネスプロセスがあり、アプリケーションの専用インスタンスによって最も適切に処理される場合があります。
- 中小企業であっても、共有型やマルチテナント型のソリューションでは満たせない、ソフトウェアアプリケーションに対する特定の要件がある場合は、シングルテナントを採用することがあります。
総じて、シングルテナントは、ソフトウェアアプリケーションに対して高度なカスタマイズ、セキュリティ、および制御を必要とする組織に適しています。こうした組織は、独自の専用インフラストラクチャを管理・維持するために必要なリソースを投入する用意があります。
AWSにおけるシングルテナントの例
組織が環境やリソースを完全に制御する必要がある場合、AWSでシングルテナントアーキテクチャを採用することを選択する可能性があります。このシナリオでは、組織は独自の仮想プライベートクラウド(VPC)を作成し、専用リソースセットにアプリケーションをデプロイします。 組織は、リソースやデータの設定、セキュリティ、管理を完全に制御できます。例えば、この組織はAWS上のシングルテナントアーキテクチャを利用して、高度にカスタマイズされた安全なeコマースプラットフォームや、機密性の高い顧客データを扱うバックアップソフトウェアをホストすることができます。
シングルテナントの利点
シングルテナントアプローチの利点は以下の通りです:
- 高いセキュリティレベル アプリケーションの各インスタンスが、独自の専用インフラストラクチャとリソース上で実行されるためです。 これにより、各顧客のデータとアプリケーションが互いに完全に分離され、データ漏洩やその他のセキュリティ上の問題が発生するリスクが低減されます。
- カスタマイズ性の向上 各顧客が独自のアプリケーションインスタンスを保有できるようになり、それぞれの具体的なニーズや要件に合わせてカスタマイズが可能です。すべての顧客が同じアプリケーションインスタンスを共有するマルチテナントアーキテクチャでは、このレベルのカスタマイズは不可能です。
- 柔軟性の向上 顧客は、共有環境やマルチテナント環境のポリシーや制約に縛られることなく、自身のデータやアプリケーションを独立して管理できます。
- リソース管理の強化 顧客に専用のインフラストラクチャを提供することで、アプリケーションのインスタンスに割り当てられたリソースを完全に制御できます。これにより、組織はインフラストラクチャの利用を最適化し、リソース競合の問題を回避できます。
- パフォーマンスとスケーラビリティの向上 アプリケーションの各インスタンスに割り当てられたリソースは専用であり、他の顧客と共有されないため、マルチテナントアーキテクチャと比較して優れたパフォーマンスとスケーラビリティが得られます。
- コンプライアンスの容易化 各顧客が自身のデータを完全に管理し、独立して運用できるため、規制要件への準拠が容易になります。
それでは、シングルテナントとマルチテナントのアプローチの違いを理解するために、マルチテナントについて見ていきましょう。
マルチテナントとは？
マルチテナントとは、テナント間の分離を実現するアーキテクチャであり、サーバーにインストールされた 1 つの共有ソフトウェアアプリケーションインスタンスが、複数の顧客(この場合はテナントと呼ばれる)にサービスを提供することができます。標準的なシングルテナントアーキテクチャでは、テナントごとにアプリケーションインスタンスをインストールする必要があります。 マルチテナント方式では、テナント同士を論理的に分離することができます。テナントは、分離された環境内でアプリケーションの設定をカスタマイズできますが、アプリケーション自体はアプリケーションの所有者(マスター管理者)によって管理されます。
簡単に言えば、マルチテナントは、それぞれ固有の鍵で保護された複数のアパートがある建物に例えることができます。各アパートの所有者(または賃借人)は、自分専用の鍵を持っており、それを使って自分のアパートにのみアクセスすることができます。 各住戸は同じ建物内にあるにもかかわらず、住人たちは他の住戸やその住人、そしてその中にあるものについて何も知らない。
建物の所有者は、各住戸が個別に通信インフラを整備するのではなく、建物全体向けの通信回線(インターネットや電話回線など)を設置し、各住戸に分配している。 各住戸の居住者は、電気、水道、ガスなどを契約し、必要に応じて利用し、利用した分について建物の所有者に料金を支払います。
同様に、テナントは マネージド・サービス・プロバイダー(MSP) から必要なサービスを契約し、自身のニーズに応じて利用することができます。マルチテナント方式の利用によって、どのようなメリットが得られるのかを見ていきましょう。
マルチテナントの利用事例
マルチテナント型ソフトウェアのアプローチは、次のようなシナリオで利用できます。
- マルチテナントは、複数の顧客が同じアプリケーションと基盤となるインフラストラクチャを共有する、SaaS(Software-as-a-Service)ソリューションを提供する組織で一般的に利用されています。
- また、マルチテナントのアプローチは、複数の顧客が同じコンピューティングリソースのプールを共有できるクラウドコンピューティング環境でも採用されています。
- マルチテナントは、組織が複数の顧客間でリソースを共有することで、リソースの利用率を最大化し、コストを削減したい場合に利用されます。
- このアプローチは、顧客ごとにリソースの使用量が比較的少ない場合や変動が大きい場合に特に有用です。例えば、顧客ごとに利用パターンやリソース要件が異なるSaaSソリューションなどが挙げられます。
- マルチテナントアーキテクチャは、組織が規模の経済を実現し、顧客ごとに個別のインフラストラクチャを管理・維持することに伴う運用コストを削減できる場合に採用されます。
マルチテナントの事例
マルチテナントは、異なる部門をテナントとする大企業でも採用されることがあります。 しかし、マルチテナントの最も興味深いユースケースは、AWSなどのクラウド環境におけるマネージドサービスプロバイダー(MSP)によるものです。顧客がこのようにクラウドベースのMSPを通じてITニーズを満たそうとする理由はいくつかあります。
場合によっては、中小企業には専任のIT専門家が在籍していないことがあります。そのような企業では、必要なITインフラの技術的なセットアップ、設定、および保守に困難をきたすことになります。 一部のお客様は、自社環境での物理サーバーの導入やソフトウェアの設定に伴う技術的(および金銭的)な問題を単に避けたいだけなのです。
さらに、クラウドでは、利用者は実際に使用した分のみを支払います。例えば、企業で大規模なプロジェクトが完了すると、そのプロジェクトのために稼働していた仮想マシン(VM)のリソースは解放され、それらのVMは不要になります。 顧客がマネージドサービスを利用している場合、これらのVM(またはAmazon EC2インスタンス)を単に削除するだけで済み、未使用のリソースに対する料金を支払う必要がなくなります。 物理サーバー (仮想マシンを実行しているものであっても)を使用している場合、このような選択肢はなく、サーバーのリソースの一部が遊休状態のままとなり、コストの無駄が生じます。これが、顧客がMSPが提供するクラウドベースのサービスの利用を開始することを選択する最も一般的な理由の一つです。
こうしたサービスの中で最も一般的なものは、インフラストラクチャ・アズ・ア・サービス(IaaS)、プラットフォーム・アズ・ア・サービス(PaaS)、ソフトウェア・アズ・ア・サービス(SaaS)として知られています。このブログ記事では、バックアップ・アズ・ア・サービス(BaaS)、レプリケーション・アズ・ア・サービス(RaaS)、ディザスタ・リカバリ・アズ・ア・サービス(DRaaS)といったSaaSの要素について取り上げます。
MSPは、ハードウェアリソース、財務リソース、人的リソースの活用を最適化することに関心を持っています。そのため、マルチテナント方式はMSPにとって理想的なアプローチです。MSPは、AWSクラウド上のサーバーにマルチテナント対応のソフトウェアを1インスタンス設定し、これを利用して、個別のアカウントを持つ複数の顧客にサービスを提供することができます。 ユーザーごとに個別のソフトウェアインスタンスをセットアップする必要はありません。
MSPにとってのマルチテナントの利点
マルチテナントを活用するMSPにとっての利点は以下の通りです:
- メンテナンスとアップグレードの容易化 。マルチテナント方式を採用することで、MSPがアップグレードやサポートを行う必要のあるソフトウェアインスタンスの数が減少します。一度更新されれば、そのソフトウェア製品はすべてのテナント(顧客)が利用できるようになります。 もしシングルテナント型のSaaS製品を管理していた場合、技術担当者は顧客ごとに個別にインスタンスの更新やアップグレードを行わなければなりません。
- リソースの効率的な活用 。マルチテナント方式によるソフトウェアのサポートでは、必要な技術担当者の数が減り、サーバーに必要なハードウェアリソースも削減されます。これは、維持管理すべきソフトウェアのインスタンス数が少なく、すべてのテナントが同じリソースとインフラストラクチャを共有するためです。
- 費用対効果と時間の節約 。 先ほど説明した機能のおかげで、マルチテナントに対応したソフトウェアは、時間とコストの節約につながります。長期的には、マルチテナントアーキテクチャを採用することで投資コストを削減でき、これがこのアプローチの重要なメリットの一つです。これは、同じアプリケーションを利用するテナント間でリソースが共有されるため、保守やサポートにかかるコストが削減されるからです。MSPがコスト削減につながるマルチテナント製品を採用すれば、その節約分を顧客に還元し、より手頃な価格でサービスを提供することが可能になります。 その結果、MSPはより多くの顧客を惹きつけ、提供するサービスを購入してもらうことができます。
- 高いスケーラビリティ 。MSPが新しいサーバー、仮想マシン、またはアプリケーションインスタンスを追加する必要がないため、新規ユーザーの追加がはるかに簡単かつ便利になります。1台のサーバー上で実行される同じインスタンスによって、複数のテナントがサポートされます。マルチテナントソフトウェアのスケーラビリティにより、プロバイダーはビジネスの拡大に合わせて提供サービスを拡充することができます。
- 顧客サービスの向上 。 マルチテナントアーキテクチャにより、MSPは システムの利用状況を監視する。的確な分析により、収集した情報を活用して提供するサービスを評価・改善することができます。MSPは、分析結果に基づいてインフラストラクチャのアップグレードや再編成を行うほか、ソフトウェア製品のサブスクリプションを変更することも可能です。
顧客にとってのマルチテナントクラウドサービスの利点
マルチテナントソリューションにより、顧客は、メンテナンスやサポートへの投資を必要とする高価なインフラストラクチャを独自に保有する必要がなくなります。 例えば、Amazon AWS などを利用して、サーバーをクラウド上の仮想マシンとして稼働させることができます。顧客は、高価な物理ハードウェアを購入することなく、 Amazonクラウドへのバックアップを実行する を利用でき、 テープライブラリを行う必要もありません。IT インフラについて心配することなく、本業に集中することができます。
顧客は、提供されるサービスとして利用されるソフトウェアを更新またはアップグレードする必要はありません。実際、NAKIVO Backup & Replication のマルチテナントソリューションのユーザーは、ソフトウェアをインストールする必要すらありません。その作業は MSP が行います。 ソフトウェアはMSPによって定期的に更新され、顧客はニーズに合わせて環境をカスタマイズできます。
マルチテナントサービスの利用は安全です。テナント同士が互いの仮想環境にアクセスすることはできません。
シングルテナント対マルチテナント
最後に、マネージドサービスプロバイダーやクラウドプロバイダーによる利用という観点から、シングルテナントとマルチテナントを比較した要約表を見てみましょう。
| 基準 | シングルテナント | マルチテナント |
| カスタマイズ | 高
アプリケーションの各インスタンスは、1つの顧客専用です。 |
限定的
すべての顧客がアプリケーションの同じインスタンスを共有します。 |
| セキュリティ | 高
アプリケーションの各インスタンスは、他の顧客から完全に隔離されています。 |
低
すべての顧客がアプリケーションおよびインフラストラクチャの同じインスタンスを共有します。1つの顧客のデータが侵害された場合、他のすべての顧客に影響が及ぶ可能性があります。 |
| コスト | 高い
各顧客には、専用のインフラストラクチャとリソースが必要です。 |
費用対効果が高い
リソースは複数の顧客間で共有されるため、リソースをより効率的に活用できます。 |
| スケーラビリティ | 限定的
各顧客には、専用のリソースが必要です。 |
高い
リソースは複数の顧客間で共有できるため、リソースをより効率的に活用できます。 |
| メンテナンス | 複雑
アプリケーションの各インスタンスを管理・保守するための専用リソースと専門知識が必要です。 |
簡単
すべての顧客がアプリケーションの同じインスタンスを共有するため、リソースをより効率的に活用できます。 |
| 複雑度 | 高 | 低 |
| デプロイ時間 | 長い
アプリケーションの各インスタンスを、顧客ごとに個別にカスタマイズおよび設定する必要があります。 |
短い
すべての顧客がアプリケーションの同じインスタンスを共有します。 |
| リソース制御 | 高
アプリケーションの各インスタンスには専用のリソースが割り当てられています。 |
低
リソースは複数の顧客間で共有されるため、パフォーマンスの問題やリソースの競合が発生する可能性があります。 |
| リソース利用率 | 低
インスタンスがアイドル状態の場合、専用のインフラストラクチャが使用されているため、他のタスクに空きリソースを割り当てることはできません。 |
高
共有リソースが使用されており、テナントのインスタンスがアイドル状態の場合、空きリソースを効果的に再配分することが可能です。 |
| リソースの分離 | 完全 分離 | 共有リソース |
| コラボレーション | 制限あり
アプリケーションの各インスタンスは、他の顧客から完全に分離されています。 |
柔軟性
すべての顧客が、アプリケーションおよびインフラストラクチャの同一インスタンスを共有します。 |
| 規制への準拠 | 容易
各顧客は自身のデータを完全に管理でき、独立して管理することができます。 |
より困難
各顧客のデータが適切に分離され、保護されていることを保証するのは難しい場合があります。 |
シングルテナントとマルチテナントのアプローチのどちらを選択するかは、組織の具体的なニーズや要件によって異なります。シングルテナントアーキテクチャは、カスタマイズ性、セキュリティ、およびリソースに対する制御性が高い一方で、コストが高くなり、管理が複雑になる可能性があります。マルチテナントアーキテクチャは、スケーラビリティが高く、メンテナンスが容易ですが、カスタマイズ性やセキュリティのレベルはシングルテナントほど高くない場合があります。組織は、各アプローチの長所と短所を慎重に評価し、自社に最適なものを決定する必要があります。
BaaS、RaaS、およびDRaaS
バックアップ・アズ・ア・サービス(BaaS)、レプリケーション・アズ・ア・サービス(RaaS)、ディザスタ・リカバリ・アズ・ア・サービス(DRaaS)の観点から、マルチテナントがどのように活用できるかを見ていきましょう。
クラウド技術や仮想化の普及に伴い、仮想化環境におけるデータ保護は極めて重要になっています。 ビジネスに不可欠なデータのバックアップは、データをオンプレミスで保管しているか、パブリッククラウドやプライベートクラウドで保管しているかに関わらず、企業にとって必須の要件です。 3-2-1バックアップルールによると、ベストプラクティスでは、データのコピーを3つ用意し、そのうち2つは異なるデバイスに保存し、少なくとも1つはオフサイトに保存することが推奨されています。
クラウド上で稼働している仮想マシンを、自社のオフィスにある物理デバイスにバックアップすることも可能です。 自社でインフラを保有していない場合は、クラウド環境からリモートサイトへバックアップしたり、別のクラウド(例えば、Amazonクラウドの別の地理的リージョン内など)にバックアップを保存したりすることができます。同様に、オンプレミスの物理サーバー上で稼働している仮想マシン(VM)を、クラウドにバックアップすることも可能です(通常はMSPを利用します)。 バックアップ・アズ・ア・サービス(BaaS)は、クラウドからの、あるいはクラウドへのVMバックアップを必要とする企業に適したソリューションです。
MSPは、高い信頼性と可用性を求める顧客のニーズを満たすことを目指しています。 通常、これらのプロバイダーはBaaSだけにとどまらず、レプリケーション・アズ・ア・サービス(RaaS)やディザスタ・リカバリ・アズ・ア・サービス(DRaaS)もBaaSと併せて提供しています。この拡張ソリューションは、オンプレミスやクラウド上のVMを問わず、ローカルVMおよびクラウド上のVMのバックアップ、レプリケーション、リカバリにおいて高い需要があります。 顧客に最高のサービスを提供するため、MSPは定期的にインフラをアップグレードし、ユーザーフレンドリーなインターフェースを備えた信頼性の高いマルチテナント型ソフトウェアを導入しています。
クラウドビジネスの成長を促進するには、MSPは導入や管理にかかるコストを削減できる、容易に拡張可能なソリューションを必要としています。そのようなソリューションは、セキュリティが確保され、高いパフォーマンスを発揮し、リソースの利用率が最適化されている必要があります。理想的には、バックアップ、レプリケーション、災害復旧を単一の管理画面から管理できることが望ましいです。 仮想環境を扱う場合、選択するソフトウェアはエージェントレスであることが望ましい。
マルチテナント型データ保護ソリューションの選定:NAKIVO Backup & Replication
NBRは、MSPとその顧客双方の経験を踏まえて開発された、汎用的なデータ保護ソリューションである。 このソリューションは、 マルチテナントモード で BaaS、RaaS、DRaaS を提供するために使用でき、仮想環境(VMware vSphere、Microsoft Hyper-V、Nutanix AHV VM、および Amazon EC2 インスタンス)をサポートしています。
NAKIVO ソリューションは、シングルテナントモードとマルチテナントモードの両方で展開可能です。 NAKIVOソリューションを利用するメリット MSP 向けのマルチテナントモードの利点には以下が含まれます:
- Amazon AWS 対応 。 NBRは、Amazon AWSクラウドに(事前構成済みのAMIとして)迅速かつ簡単に導入できます。
- その他の柔軟な導入オプション には、Windows、Linux、NAS、仮想マシン(VA)などが含まれます。
- MSPコンソール。 MSPは、一元化されたWebインターフェースからすべてのクライアントを管理できます。クライアントのインフラストラクチャを追加して、包括的なデータ保護サービスを提供することが可能です。また、MSPは、NBR上に独自の環境(シングルテナントモード)を展開しているクライアントを追加し、管理およびサポートサービスを提供することもできます。
- 顧客向けセルフサービスポータル 。 独自のNBRインスタンスを持たないMSPクライアントの場合、MSP管理者はソリューション内の ロールベースのアクセス制御 を使用して、バックアップおよびリカバリタスクの一部をクライアントに委譲できます。各顧客(テナント)は、隔離されたダッシュボードにアクセスすることで、自身のバックアップ、レプリケーション、およびリカバリジョブを管理できます。あるテナントのジョブやインベントリは、他のテナントからは表示されません。
- 個別のブランディング 。MSPは、NBRインターフェースのブランディングをカスタマイズし、顧客にシームレスな体験を提供できます。 サービスプロバイダーは、自社が使用しブランド化している他の製品に合わせて製品の外観を標準化することができ、提供するすべてのサービスにおいて一貫した企業スタイルを確保できます。
- ライセンス 。MSP向けNBRは、ワークロード単位で月単位または年単位のライセンスが提供されます。 MSPは、毎月必要なワークロード分のみを支払うことも、より大きなコスト削減を図るために年間ライセンスを契約することも可能です。
マルチテナントモードを備えたNBRは、BaaS、RaaS、DRaaSの提供を目指すMSPにとって強力なソリューションです。この製品は、オンプレミスのインフラが一切なくても、Amazon AWSなどのクラウド環境で利用可能であり、MSPとエンドユーザーの双方のニーズを満たす優れた手段となります。
