残念ながら、この用語にはロシア語で適切な類似語がありません。ウィキペディアが提供する 「マルチテナント、マルチテナント」これは「複数所有権」と呼ばれることもあります。この主題は本質的に賃貸や所有に関連していないため、これらの用語はやや混乱する可能性があります。これはソフトウェアのアーキテクチャとその運用の組織に関する問題です。そして後者も同様に重要です。
私たちは、1C:Enterprise におけるクラウド (サービス) 作業モデルへのアプローチの設計を開始すると同時に、マルチテナンシーについての理解を明確にし始めました。これは数年前のことです。それ以来、私たちの理解は継続的に拡大してきました。私たちは、この主題の新しい側面 (長所、短所、困難、特徴など) を常に発見しています。
開発者は、マルチテナントを非常に単純なテーマとして理解することがあります。「複数の組織のデータを 1 つのデータベースに保存するには、組織識別子を含む列をすべてのテーブルに追加し、それにフィルターを設定する必要がある」ということです。もちろん、私たちもこの瞬間からこの問題の研究を始めました。しかし、彼らはすぐに、これが単なるクリアリングにすぎないことに気づきました（ちなみに、これも簡単ではありません）。一般に、これは「国全体」です。
マルチテナントの基本的な考え方は次のように説明できます。典型的な用途は、インフラストラクチャー (壁、屋根、給水、暖房など) を使用する、1 家族を収容するように設計されたコテージです。マルチテナント アプリケーションはアパートの建物です。そこでは、各家族が同じインフラストラクチャを使用しますが、インフラストラクチャ自体は家全体に実装されます。
マルチテナンシーのアプローチは良いのでしょうか、それとも悪いでしょうか?これについては非常に異なる意見を見つけることができます。 「良い・悪い」というものは全く無いようです。解決する特定のタスクのコンテキストで長所と短所を比較する必要があります。しかし、これは別のトピックです...
最も単純な意味で、マルチテナンシーの目標は、インフラストラクチャ コストを「ソーシャル化」することでアプリケーションの維持コストを削減することです。これは、「注文に応じて」アプリケーションを作成するのではなく、運用ソリューション (おそらくカスタマイズや変更を伴う) を使用してアプリケーションのコストを削減するのと同じ動きです。開発が社会化されるのは1つの場合のみであり、もう1つの場合は搾取です。
また、繰り返しになりますが、販売方法とは直接の関係はございません。マルチテナント アーキテクチャを企業または部門の IT インフラストラクチャで使用して、多数の同様の支店や持株会社を自動化することもできます。
マルチテナンシーは、単にデータ ストレージを整理するだけの問題ではないと言えます。これは、アプリケーションが全体としてどのように動作するかを示すモデルです (アーキテクチャ、展開モデル、保守組織の重要な部分を含む)。
マルチテナンシー モデルで最も難しく、そして興味深い点は、アプリケーションの本質が「分岐」していることだと私たちには思われます。機能の一部は特定のデータ領域 (アパート) で動作し、他のアパートに居住者がいるという事実には「関心がありません」。そして、家を全体として認識し、住人全員のために同時に働く人もいます。同時に、後者は、これらが結局のところ別々のアパートであるという事実を無視することはできず、必要なレベルの粒度とセキュリティを確保する必要があります。
1C:Enterprise では、マルチテナンシー モデルがいくつかのテクノロジーのレベルで実装されています。これらは 1C:Enterprise プラットフォームのメカニズム、"そして""、メカニズム (標準サブシステムのライブラリ)。
これらの各項目は、マンションの建物全体のインフラストラクチャの構築に貢献します。これが、たとえばプラットフォームなどの 1 つのテクノロジではなく、複数のテクノロジで実装されているのはなぜですか?まず第一に、私たちの意見では、メカニズムの一部は特定の展開オプションに合わせて変更するのが非常に適切であるためです。しかし、一般に、これは難しい問題であり、マルチテナンシーのこの側面またはその側面をどのレベルで実装するのがより良いかという選択に常に直面しています。
明らかに、メカニズムの基本部分をプラットフォームに実装する必要がありました。たとえば、実際のデータの分離です。通常、人々はここからマルチテナントについて話し始めます。しかし最終的には、マルチテナント モデルはプラットフォームのメカニズムの重要な部分を「移動」し、改良が必要になり、場合によっては再考が必要になりました。
プラットフォーム レベルでは、基本的なメカニズムを正確に実装しました。これらを使用すると、マルチテナンシー モデルで実行されるアプリケーションを作成できます。しかし、このようなモデルでアプリケーションが「生きて働く」ためには、アプリケーションの「生命活動」を管理するシステムが必要です。 1cFresh テクノロジーと BSP レベルの統合ビジネス ロジック層がこれを担当します。アパートの建物のインフラストラクチャが住民に必要なものをすべて提供するのと同じように、1cFresh テクノロジーはマルチテナンシー モデルで実行されるアプリケーションに必要なものをすべて提供します。そして、アプリケーションが (大幅な変更を加えることなく) このインフラストラクチャと対話できるように、対応する「コネクタ」が BSP サブシステムの形式でアプリケーションに配置されます。
プラットフォームのメカニズムの観点から見ると、経験を積んでクラウド ユース ケース「1C:Enterprise」を開発するにつれて、このアーキテクチャに関与するメカニズムの構成が拡大していることに気づきやすいでしょう。一例を挙げてみましょう。マルチテナンシー モデルでは、アプリケーション サービス参加者の役割が大幅に変化します。アプリケーションを運用する責任者の役割（責任のレベル）が大幅に増加します。より強力なアプリケーション制御ツールが必要になりました。なぜなら、アプリケーションのユーザー (居住者) は、まず自分が利用するプロバイダーを信頼するからです。これを行うために、新しい機能を実装しました。 。このメカニズムにより、プロバイダー管理者は、アプリケーション開発者の自由を必要なセキュリティ レベルに制限することができます。つまり、特定のサンドボックス内のテナントごとにアプリケーションの操作を分離することができます。
同様に興味深いのは、マルチテナント モードで動作するアプリケーションを管理するためのアーキテクチャ (1cFresh および BSP テクノロジで実装されているもの) です。ここでは、従来の導入モデルと比較して、管理プロセスの自動化の要件が大幅に増加しています。新しいデータ領域 (「アパートメント」) の作成、アプリケーションの更新、規制情報の更新、バックアップなど、そのようなプロセスは数多くあります。そして、当然ながら、信頼性と可用性のレベルに対する要件は増加しています。たとえば、アプリケーションと制御システム コンポーネント間の信頼性の高い対話を確保するために、配信が保証された非同期呼び出しシステム テクノロジを実装しました。
非常に微妙な点は、データとプロセスをソーシャル化する方法です。一見しただけでは、（誰かにそう思われる場合は）単純に見えます。最大の課題は、データとプロセスの集中化と分散化の間のバランスです。一方で、一元化によりコスト (ディスク容量、プロセッサリソース、管理者の労力など) を削減できます。一方で、「入居者」の自由も制限されます。これはまさにアプリケーションの「分岐」の瞬間の 1 つであり、開発者は狭い意味 (1 つの「アパート」にサービスを提供する) と広義のアプリケーション (すべての「テナント」に同時にサービスを提供する) について同時に考える必要があります。 。
このような「ジレンマ」の例として、規制情報や参考情報が挙げられます。もちろん、それを家のすべての「入居者」に共通にしたいという大きな誘惑があります。これにより、1 つのコピーに保存し、全員が同時に更新できるようになります。しかし、一部の住民が特定の変更を必要とする場合があります。奇妙なことに、実際には、規制当局（政府機関）によって指定された情報であっても、これが発生します。これは難しい質問であることがわかります。社交するべきか、社交しないべきでしょうか?もちろん、情報を誰にとっても一般的なものにし、それを望む人には非公開にしておきたいという誘惑に駆られます。そして、これはすでに非常に困難な実装につながっています。しかし、私たちはこれに取り組んでいます...
別の例は、定期的なプロセス (スケジュールに従って実行される、制御システムによって開始されるなど) の実装の設計です。一方で、これらはデータ領域ごとに個別に実装できます。より簡単で便利です。しかし一方で、このような粒度の細かさはシステムに大きな負荷を与えます。負荷を軽減するには、ソーシャル化されたプロセスを実装する必要があります。しかし、より慎重な研究が必要です。
もちろん、これは非常に重要な疑問を引き起こします。アプリケーション開発者はどのようにしてマルチテナンシーを確保できるでしょうか?そのために彼らは何をする必要があるのでしょうか?もちろん、技術的およびインフラストラクチャの問題の負担は提供されるテクノロジーの肩にできる限り負わされ、アプリケーション開発者はビジネス ロジック タスクの観点からのみ考えるように努めます。ただし、他の重要なアーキテクチャの問題と同様、アプリケーション開発者はマルチテナント モデルでの作業についてある程度の理解を持っている必要があり、アプリケーションの開発時にはある程度の労力が必要になります。なぜ？データのセマンティクスを考慮せずにテクノロジーが自動的に提供できない点があるためです。たとえば、情報社会化の境界についても同じ定義です。しかし、私たちはこうした困難を小さく抑えるよう努めています。このようなアプリケーションの実装例はすでにあります。
1C:Enterprise でマルチテナントを実装する場合の重要な点は、XNUMX つのアプリケーションがマルチテナント モードと通常モードの両方で動作できるハイブリッド モデルを作成していることです。これは非常に難しい作業であるため、別途議論する必要があります。
出所： habr.com