マルチテナントアーキテクチャおさらい

マルチテナントアーキテクチャとはどのようなものか、について、「複数のユーザーが共通のシステムやプラットフォームを利用する仕組み」と紹介しました。ここでは具体的にイメージしやすいよう、身近なもの、例えば住居に例えてみます。「シングルテナント：一戸建て」と「マルチテナント：集合住宅」と、イメージしてみると、それぞれの良い点、留意点はどのようなところでしょうか。

※わかりやすさのために一戸建てと集合住宅とを取り上げましたが、それぞれ優れている点があります。いずれかを否定するものではありませんのでご了承ください。

◆ マルチテナント：集合住宅 の良い点

マルチテナントは準備されたひとつのリソースを共有するといえますので、マンションのような集合住宅と考えてみます。

• すぐに入居できる。ひととおりのものが揃っている。
• 共用部が充実している。セキュリティ安心。
• 継続的にメンテナンスや改良がされる。

集合住宅の場合はあらかじめ設計・施工されていて、準備されている環境があり、すぐに入居できることはよい点と言えそうです。共用の玄関やインターネットの設備なども、自分で準備せずとも利用できます。監視カメラ、管理人さんなどのセキュリティもあると安心です。設備の維持には継続的なメンテナンスが必要ですが、管理会社が維持管理してくれるので利用者は気にしないでも大丈夫そう。

◆ マルチテナント：集合住宅 の留意点

良い点が多くあるマルチテナントですが、留意すべき点はないでしょうか。同じように集合住宅に照らしてみると、このような点には気を付けたほうがよさそうです。

• 利用にあたってのルールがある。
• 管理費・修繕積立金がかかる。
• カスタマイズできる範囲が決められている。

共用サービスの利用には費用がかかりますし、利用にあたっては定められたルールを守る必要があります。みんな共同で利用しますので、好き勝手に、とはいかないですね。部屋の間取りも決まっていますし、リフォーム（カスタマイズ）できる範囲は限定的、となりそうです。

Salesforceに置き換えてみると、「標準機能が充実している」「セキュリティ機能が提供される」「すぐに利用できる（Sandboxなどの開発環境もすぐに利用できます！）」という良い点がある一方で、「ガバナ制限を守らないといけない」「カスタマイズできる範囲や方法が決められている」という留意点があります。
私は、良い点をたくさん享受して、留意点とうまく付き合っていくには、仕組みを知っておくことが助けになると考えています。

マルチテナントを実現するプラットフォームの仕組み

マルチテナントを実現するためのプラットフォームの仕組みはどのようになっているのでしょうか。データベース、アプリケーションとそれぞれ工夫がなされています。ここではデータベースに着目してみます。

◆ 一般的なデータベースの場合

一般的なデータベースではデータを格納するために、テーブル、項目、主キー、インデックス（索引）、外部キー（参照整合性）、といった要素を準備します。

• テーブルを作成すると、テーブルごとに物理的な領域が割り当てられます。
• 項目ごとに、文字型・80桁、数値型・8桁などと、型や大きさ、精度を決めます。
• 項目の中で、レコードを一意に識別する項目を決め、主キーとして割り当てます。
• 検索するときにデータを絞り込む項目、および項目の組み合わせを検討し、インデックス（索引）を作成します。
• 複数のテーブルの間で関連がある場合には、外部キーを定義します（参照整合性）

Salesforceの場合も、テーブルに似たものとしてオブジェクトを作りますし、オブジェクトには項目も定義します。それぞれ似ているように思いますが、どんな点が異なるのでしょうか。順に見ていきましょう。

◆ Salesforceのアーキテクチャの場合

１．オブジェクト・項目の作成
Salesforceのオブジェクトは、データベースのテーブルに似ています。
一般的なデータベースでは、テーブルを作成すると物理的な領域が確保されたのですが、Salesforceではメタデータが作成される点が異なります。
メタデータとは、メタ的なデータ、すなわちデータについてのデータを意味します。具体的には、オブジェクトの名前やAPI参照名など、「オブジェクトについてのデータ」が情報として登録されます。
項目も同様で、項目の名前、API参照名、型、大きさなど、「項目についてのデータ」が情報として登録されます。

では、Salesforceの場合は実際のデータはどこに格納されるのでしょうか。
Salesforceの場合は、データを格納するためのテーブルがあらかじめ用意されています。汎用的に設計されており、ひとつのテーブルに様々なオブジェクトが格納できるように工夫されています。例として、このような項目があらかじめ用意されています。

• データ（行）を一意に識別するための内部キー項目
• 組織を識別する項目（組織ID）
• 作成日時・作成者、更新日時・更新者などの監査項目
• データを格納する汎用の項目が数百個。文字・数値・日付をいずれも格納できる。この項目が実際にはどのような型・大きさか、は、「項目についてのデータ」すなわちメタデータで定義されます

これをみると、込み入った仕組みとなっているように思えてしまいます。なぜこのような方法がとられているのでしょうか。私はこれが、Salesforceが画面でオブジェクトを作成したり、項目を追加・変更したりできる秘密なのだろうと思っています。
一般的なデータベースのような、物理的な領域の割り当てには一定の時間がかかりますし、変更する場合にはすでにあるものをロックする必要も出てきます。Salesforceでは物理的な領域を準備することなく、論理的な設定（メタデータ）で定義することから、柔軟な対応ができるのです。

２．インデックス（索引）の作成
では次に、検索用のインデックス（索引）を作成する場合をみてみます。
一般的なデータベースでは任意の項目にインデックスを作成することができます。Salesforceではあらかじめインデックス（索引）が作成される項目が決まっています。主要な項目は以下のとおりです。

• 各オブジェクトの主キーである、SalesforceレコードID
• 外部キーリレーション（参照関係、主従関係を設定する項目）
• 外部ID項目
• Name項目
• 作成日時
• 最終更新日時

これ以外のインデックスは自由に作ることはできません。インデックスが必要な場合は、カスタムインデックスの作成をSalesforce社に依頼することになります。

作成されるインデックスも独自の形式です。Salesforceの場合はマルチテナント、すなわち複数の組織、複数のオブジェクトのレコードが同じテーブルに登録されますので、単純にデータベースのインデックスを作成することはできません。そのため、該当の項目をコピーした、インデックス用のデータが作成されます。

このように、マルチテナントで利用できるためのさまざまな工夫がなされています。 柔軟性、信頼性、セキュリティが得られる一方で、そのための内部での処理も必要となりますので、その特性を理解して活用することをお勧めします。

おわりに

今回の記事で紹介したSalesforceのプラットフォームの仕組みには、 Salesforce Architects のサイトで Platform Multitenant Architectureとして紹介されています。今回は取り上げられなかったアプリケーションレイヤについても触れられています（英語です）
また、7月に開催されるSalesforce World Tour Tokyo（2023/7/20-21） では、Trailblazer Forestのシアターで、今回紹介したマルチテナントの仕組みについても紹介します。ぜひ会場でお会いしましょう。

2023年7月20日（木）Day 1 セッション番号 1-TFT-12
ガバナ制限でつまずかないために！マルチテナントの仕組みをのぞいてみよう

JSOLはSalesforce World Tour Tokyo のブレイクアウトセッションスポンサーです。
シチズンマシナリー様とSalesforce World Tour Tokyo 2023 に登壇！