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