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