Loading article…
ソフトウェアのマルチテナンシーとは、単一のソフトウェアインスタンスがサーバー上で実行され、複数のテナントにサービスを提供するソフトウェアアーキテクチャです。このように設計されたシステムは「共有」であり（「専用」または「分離」ではありません）、テナントとは、ソフトウェアインスタンスへの特定の権限を持つ共通アクセスを共有するユーザーのグループです。マルチテナントアーキテクチャでは、ソフトウェアアプリケーションは、データ、構成、ユーザー管理、テナント固有の機能、および非機能プロパティを含むインスタンスの専用シェアを各テナントに提供するように設計されています。マルチテナンシーは、異なるテナントのために別々のソフトウェアインスタンスが動作するマルチインスタンスアーキテクチャとは対照的です。[ 1 ]一部の評論家は、マルチテナンシーをクラウドコンピューティングの重要な機能とみなしています。[ 2 ] [ 3 ]
マルチテナントアプリケーションは、以下の3種類のサービスから発展し、それらの特徴の一部を組み合わせている。
マルチテナント環境では、複数の顧客が同じアプリケーションを共有し、同じオペレーティングシステム、同じハードウェア、同じデータストレージメカニズム上で動作します。顧客間の区別はアプリケーション設計段階で行われるため、顧客同士が互いのデータを共有したり、閲覧したりすることはありません。
これは仮想化とは対照的である。仮想化では、コンポーネントが変換され、各顧客アプリケーションが個別の仮想マシン上で実行されているように見える。
しかしながら、仮想化は、大幅なアーキテクチャ変更を回避しながらマルチテナントを実現する代替手段を提供します。つまり、単一のインスタンスから複数のテナントにサービスを提供するようにアプリケーションを再設計するのではなく、プロバイダは仮想化技術を使用して、1つまたは複数のサーバー上でアプリケーションの複数の独立したインスタンスをホストできます。マルチテナント向けにアプリケーションを再設計するにはコストがかかるため、これは魅力的な方法です。特に、オンプレミスのシングルテナント版製品も引き続き提供し、そうでなければ2つの異なる製品を維持しなければならないソフトウェアベンダーにとってはなおさらです。アプリケーションを仮想アプライアンスとして再パッケージ化すると、同じアプライアンスイメージをISVがホストする場所、オンプレミス、または信頼できるサードパーティの場所に展開でき、時間の経過とともに展開サイトを移行できます。
マルチテナンシーでは、IT リソースを単一の運用に統合することで得られる基本的な規模の経済に加えて、コスト削減が可能になります。 [ 3 ]アプリケーション インスタンスは通常、一定量のメモリと処理のオーバーヘッドを伴いますが、顧客数が多い場合、特に顧客数が小さい場合は、このオーバーヘッドは相当なものになる可能性があります。マルチテナンシーでは、このオーバーヘッドを多くの顧客に分散することで削減します。さらに、基盤となるソフトウェア (オペレーティングシステムやデータベース管理システムなど) のライセンス費用からもコスト削減が見込めます。簡単に言えば、すべてを単一のソフトウェア インスタンスで実行できる場合、ソフトウェア ライセンスは1 つだけ購入すればよいということです。ただし、需要の増加に伴い単一インスタンスを拡張することが困難であるため、コスト削減効果は相殺される可能性があります。単一サーバー上のインスタンスのパフォーマンスを向上させるには、高速な CPU、より多くのメモリ、高速なディスク システムなどのより高速なハードウェアを購入するしかなく、通常、これらのコストは、ほぼ同じ総容量を持つ複数のサーバーに負荷を分散する場合よりも急速に増加します。[ 5 ]さらに、マルチテナントシステムの開発[ 5 ]は、複数の顧客のデータが混在するため、より複雑で、セキュリティテストもより厳格になります。
カスタマイズの複雑さが増し、テナントごとのメタデータを維持する必要があるため、マルチテナントアプリケーションはより大きな開発労力を必要とします。テナントデータの分割方法、テナントごとのスキーマ拡張の保存方法、共有リソースの分離方法などの考慮事項を考慮する必要があります。[ 6 ]
マルチテナント方式は、リリース管理プロセスを簡素化します。従来のリリース管理プロセスでは、コードやデータベースの変更を含むパッケージがクライアントのデスクトップやサーバーマシンに配布されます。シングルインスタンスの場合、顧客ごとにサーバーマシンが1台必要になります。そして、これらのパッケージを各マシンに個別にインストールする必要があります。マルチテナントモデルでは、通常、パッケージは1台のサーバーにのみインストールすれば済みます。これにより、リリース管理プロセスが大幅に簡素化され、規模が顧客数に依存しなくなります。
同時に、マルチテナント環境では、新しいリリースバージョンの適用に伴うリスクと影響が増大します。単一のソフトウェアインスタンスが複数のテナントにサービスを提供しているため、たとえアップデートが1つのテナントのみに要求され、有用であったとしても、このインスタンスのアップデートによってすべてのテナントがダウンタイムに見舞われる可能性があります。また、新しいリリースの適用によって発生したバグや問題が、他のテナントのアプリケーションのパーソナライズされたビューにも現れる可能性があります。ダウンタイムが発生する可能性があるため、リリースを適用するタイミングは、複数のテナントの時間利用スケジュールに応じて制限される場合があります。
マルチテナントアプリケーションにおける中心的な設計上の決定事項は、各テナントのデータが共有ストレージ内でどのように分離されるかです。一般的に、3つのアプローチが説明されています。[ 7 ]
デプロイメントレベルでは、テナントへのリソースの割り当て方法は、Amazon Web Servicesの SaaS アーキテクチャ ガイダンスから抽出した 3 つのパターンを使用して一般的に説明されます。[ 8 ]
テナントがコンピューティング、ストレージ、またはネットワークのリソースを共有する場合、1つのテナントが過剰な負荷を発生させると、他のテナントのパフォーマンスが低下する可能性があります。これは「ノイジーネイバー」問題として知られています。対策としては、テナントごとのレート制限、リソース割り当て、高負荷のテナントを専用リソースに隔離することなどが挙げられます。
Marc Brooker 氏によると、マルチテナントアーキテクチャでは、関連性のないワークロードや相関関係のないワークロードはグループ化する必要があるとのことです。これは、異なるニーズやパターンを持つ異なるワークロードを混在させると、各ワークロードのパターンが隠されてしまうためです。ワークロードをグループ化することで、システム全体のピーク対平均比率が低下します。個々のワークロードは、システム全体のコスト構造を大幅に増加させることなく、ピーク時により多くのリソースを利用できるため、結果としてコスト効率が向上します。なお、同じアプリケーション、顧客、または業界からの複数のワークロードは、単一のワークロードのように動作する傾向があります。[ 9 ]
マルチテナントアプリケーションでは、各対象組織のニーズをサポートするために、高度なカスタマイズ機能が求められるのが一般的です。カスタマイズには通常、以下の側面が含まれます。
マルチテナントアプリケーションは、マルチインスタンスアプリケーションの場合、アプリケーションの下位レイヤーによって提供される、複数のテナント間の十分なセキュリティ、堅牢性、パフォーマンス[ 10 ]を提供することが期待されています。
マルチテナンシー。トップからボトムまでインフラストラクチャ全体の単一のプールされた運用インスタンスを共有することは、単なるベンダーの利便性以上のものです。それは、クラウドの規模を真に実現する唯一の方法です。
データサービス、DNSサービス、仮想マシン用ハードウェア、ロードバランサー、ID管理などがこれに該当します。