技術記事
Omnitech CRMにおけるフェイルクローズ方式のモデル層分離と、IMFlow360における行単位のテナンシー——同じ問いに対する、二つの有効な答え。
あらゆるマルチテナントSaaSプラットフォームは、同じ問い——単一の共有コードベース上で、あるテナントのデータを他のテナントからどのように分離しておくか——に答えなければなりませんが、正しい答えはプラットフォームのリスクプロファイルによって異なります。Omnitech CRMとIMFlow360という二つのプラットフォームは、この問いにそれぞれ異なる形で答えており、どちらの答えも、それぞれのプラットフォームが必要とするものに対しては正しい答えです。
実績の読み方
マルチテナントプラットフォームは一般に、テナントごとに別々のデータベースを用意する、テナントごとに別々のスキーマを用意する、あるいはアプリケーション層でテナント識別子によってスコープされた共有テーブルを用いる、といったいくつかの層のいずれかでテナントを分離します。それぞれコストも障害モードも異なり、これらの戦略間のトレードオフについてはAWSのSaaSテナント分離に関するガイダンスが有用な公開参考資料となります(後述の出典を参照)。Omnitech CRMとIMFlow360はいずれも共有テーブル・アプリケーション層強制型の分離を採用していますが、その強制の仕方は異なります。
実績の読み方
Omnitech CRMは、キューイングされたバックグラウンド処理を含め、モデル層およびクエリ層においてフェイルクローズ方式でテナント分離を強制しています。クエリにテナントスコープが欠落している場合、テナント間漏えいのリスクを冒すのではなく、リクエストそのものを失敗させます。22のビジネスモジュールにまたがる126の権限からなる中央権限レジストリは、この分離層とは意図的に切り離されており、テナントを分離する役割を担うコードパスには一切触れることなく、ロールごとの権限を広げたり狭めたりできます。
実績の読み方
IMFlow360は、関連はするものの異なるアプローチを採っています。行単位のマルチテナンシーによってすべてのレコードがビジネスと支店単位でスコープされる一方、コードベースを分岐させるのではなくbusiness_typeフィールドによって、小売、飲食、美容/サロン/スパ、予約制ビジネスのカタログ、注文、ワークフローの挙動を差別化しています。これら4つの業種はすべて、約146テーブルからなる一つの共有スキーマ上で稼働します。分離の境界線自体はOmnitech CRMと同じ共有テーブル方式ですが、違いは、IMFlow360がテナントデータを分離するためだけでなく、ビジネスの挙動を差別化するためにも同じスコープ機構を利用している点にあります。
実績の読み方
アイソレーション戦略は、プラットフォームのリスクプロファイルに応じて早期に一度だけ下される基盤的な決定であり、その上に重ねられる権限システムとは別の決定です。どちらのプラットフォームも、共有テーブルに対してアプリケーション層でアイソレーションを強制しています。テナント境界のみに厳密に限定したフェイルクローズ型の強制と、テナントごとの挙動の違いも担う行単位のスコーピングとの違いは、各プラットフォームがそのスコーピング機構にアイソレーションそのものを超えて何を求めていたかによって決まります。
リファレンス
Written by
AI/MLアーキテクチャ、技術戦略、プラットフォームアーキテクチャ、エンジニアリングリーダーシップ、システムインテグレーション、セルフホスト型AI。
同じような課題を抱えていますか？
プラットフォームの変更が遅く、危険になってきたSaaS創業者・エンジニアリング責任者向け。
アセスメントを依頼するLet's build what's next
アイデアの段階でも、既存プラットフォームの刷新でも、システムの拡張でも、まずはご相談ください。
Better Technology.
Brighter Possibilities.
