寓話
同じ建物の中の多くの商号
老算盤楼は当初、一軒の呉服店だけにサービスを提供していた。帳簿、カウンター、店員、倉庫はすべて同じ店主のもので、どう配置しても混線しなかった。
後に楼主は同じ会計サービス一式を十数社の商店に販売しました。皆がホール、使い走りの木偶、レポートエンジン、バックアップ倉庫を共有しましたが、それぞれに顧客、価格、契約、支払期日がありました。
最初の週、手間を省くため、管理者は各商店に異なる色のフォルダを割り当てた。木偶は色ごとに処理し、一見整然としていた。
まもなく、ある茶商の更新報告に布荘の顧客名が現れた。原因はハッカーではなく、レポートテンプレートが前の商号のフィルター条件をキャッシュしていたことだった。
楼主はまず店員に色を確認させた。共有できるものは多すぎた。検索インデックス、流水、キュー、一時メモ、課金表、一時ファイル、どこか一つでも商号の印を付け忘れれば混ざってしまう。
新しいアーキテクトは建物全体を再番号付けしました。各リクエストは入る時にテナント ID を伴い、データ、設定、権限、クォータ、ログ、キャッシュ、タスクキューはすべてテナントごとに線引きされます。共有ケイパビリティは共用できますが、境界は省略できません。商号が増えるほど、楼主は境界が追加の装飾ではないことを理解しました。テナント ID は印のように、毎回のデータ取得、記帳、作業割り当て、課金に伴わなければならず、背後で同じ職人たちを共有していても、部屋の鍵を混ぜてはなりません。
使い走りの木偶が茶商人の仕事をするとき、茶商人の空間しか見ることができない。ツールの呼び出し、ナレッジベースの検索、流水の記録、課金は、すべて同じテナントマークを携帯する。アーキテクトはさらに演習を用意した。彼はわざと使い走りの木偶に茶商人の鍵を持たせて布荘の戸棚を開けさせ、システムはこれを拒否しなければならない。帳票を二つの商号間で切り替えさせ、キャッシュは必ず再クリアされなければならない。
建物内は依然として一つのプラットフォームで、維持コストは十数システムにはならなかった。だが各商号は自分の部屋に住むように、自分の鍵、請求、規則を持つ。楼主は理解した。マルチテナントの難点は多くの者に一棟を共用させることではなく、共用しながらも各自が安全な小楼を所有しているようにすることだ。