専門用語なしで分かるマルチテナント：創業者のための手引き

ソフトウェア製品を作るどこかの段階で、開発者はあなたに「マルチテナント」という言葉を口にし、あなたの顔を見て、理解したものと思い込みます。おそらくあなたはうなずいたでしょう。多くの創業者がそうします。しかしこれは、どれだけ速く成長できるか、どれだけ安く運用できるか、そして万一顧客が自分のものでないデータを目にしたときどれだけ悪化しうるかを、静かに決めてしまう初期の判断の一つです。後から見直すのは非常に高くつくため、いま10分の注意を払う価値があります。

私は多くの非エンジニアの創業者と向き合ってきました。SaaS製品の鋭いアイデアを持ち、データベースには特に関心のない方々です。良い知らせは、この判断を正しく下すためにプログラミングを学ぶ必要はないということです。必要なのは明快な思考の枠組みと、短い質問のリストです。本稿はまさにそれです。流行り言葉も、二度と見返さない設計図もなく、最初の一行を書く前に理解しておいてほしいと開発者が願うことだけをお伝えします。

もし一つだけ持ち帰るなら、これにしてください。マルチテナントは、後から足す機能ではありません。それは土台です。家は塗り直せますが、壁が立った後でその上に建っている基礎を簡単に変えることはできません。

「マルチテナント」が実際に意味すること

集合住宅を思い浮かべてください。入居者はそれぞれ自分の住戸を持ちます。自分の鍵、自分の家具、自分の玄関です。しかし全員が同じ構造を共有します。基礎、配管、屋根、エレベーターです。大家は50軒の別々の家ではなく、一つの建物を維持します。だからこそ家賃が手頃になります。マルチテナントソフトウェアもまったく同じように動きます。一つのアプリケーションが多数の顧客、すなわち「テナント」を支え、その下では全員が同じ共有システム上で動いているにもかかわらず、各自が自分専用の空間として体験します。

対照的なやり方がシングルテナントです。顧客ごとにソフトウェアの別々のコピーを与えるもので、一人ひとりに新築の一戸建てを建てるようなものです。よりプライベートで、より細かくカスタマイズできますが、構築・運用・更新は劇的に高くつきます。一つの建物ではなく50軒の家を維持することになるからです。

あなたが日々使うほぼすべての製品はマルチテナントです。メール、会計ツール、予約システム、営業チームが入り浸るCRM。あなたと他の千社が同じ基盤ソフトウェアを共有していますが、互いの姿を見ることはありません。この見えなさ、この清潔な分離こそが、マルチテナントの技そのものです。

なぜこの判断が事業全体に関わるのか

これを「開発者が扱う技術的な細部」として片付けたくなります。しかし選んだモデルは、あなたが実際に気にかける事業の部分へまっすぐ波及します。毎月のホスティング費、新機能を全員へどれだけ速く届けられるか、神経質な大企業の買い手に何を約束できるか、そして一つの不具合がどれだけの被害を生みうるかです。

よく作られたマルチテナント製品で不具合を直したり機能を出したりすると、すべての顧客が一度にそれを受け取ります。単一の更新からです。シングルテナントの世界では、その変更を50の別々のインストールへ展開することになり、それぞれが今やわずかに異なっているかもしれません。一方は火曜の午後の作業です。もう一方はプロジェクトです。これを何年もの更新にわたって掛け合わせれば、SaaS業界がマルチテナントの上で回っている理由が分かります。

裏を返せば、インフラを共有することは分離の重みを高めます。集合住宅では配管の不具合が複数の住戸に影響しえます。マルチテナントソフトウェアでは、テナントを分ける仕組みのミスが一人の顧客に不便を与えるだけでなく、全員のデータを一度にさらしうるのです。これはマルチテナントを避ける理由ではありません。これを過去にやり遂げた人と組んで、きちんと作る理由です。

テナントを分ける3つの方法

開発者がマルチテナントを巡って議論するとき、たいていは各テナントのデータをどれだけ分離するかを争っています。一般的なやり方は3つあり、「最大限の共有・最低コスト」から「最大限の分離・最高コスト」まで連続した目盛りの上に並びます。あなた自身が選ぶ必要はありませんが、開発者があなたに代わって下している判断のトレードオフは理解しておくべきです。

1. 共有データベース、共有テーブル

全員のデータが同じデータベースの同じテーブルにあり、どの行が誰のものかを示す隠れた目印、すなわち「テナントID」が付いています。ソフトウェアは常にその目印で絞り込む責任を負い、顧客Aは顧客Aの行だけを見ます。これは最も安く、最も拡張しやすいモデルで、多くの初期SaaS製品が使います。落とし穴は、分離がコードの中に宿るため、一度の絞り込み漏れがデータ漏えいになることです。注意深く規律ある開発が求められます。

2. 共有データベース、別々の区画

一つのデータベースですが、各テナントがその中に自分専用の囲われた区画を持ちます（開発者はこれを「スキーマ」と呼びます）。最初のモデルより分離が強く、それでもまずまず効率的で、たとえば一顧客のデータをきれいに書き出したり削除したりするのも容易です。トレードオフは、数百・数千のテナントへ成長するにつれ管理すべき可動部が増えることです。

3. テナントごとに別々のデータベース

顧客ごとに専用のデータベースを与えます。アプリケーションは共有しつつ、各自にプライベートな家を与えるのに最も近いやり方です。これは最も強い分離であり、セキュリティに敏感な大企業の買い手に説明しやすい筋書きです。同時に運用・運営は最も高くつくため、価値の高い顧客、規制業界、あるいはデータの取り違えが致命的になる製品に限られる傾向があります。

決して間違えてはいけない部分：分離

心配の種を一つに注ぐべき場所があるとすれば、ここです。テナント分離とは、顧客Aがいかなる状況でも、顧客Bのデータを見たり、編集したり、その存在を感じ取ったりすら決してできない、という保証です。当たり前に聞こえます。しかしこれは、マルチテナント製品における深刻な不具合の最も多い原因でもあります。失敗が静かだからです。誰かがレポートを開いて見知らぬ他人の顧客が映るその日まで、すべては問題なく見えます。

これが起きる理由は構造的です。最も安いモデルでは、一つひとつのデータベース要求がテナントで絞り込むことを覚えていなければなりません。一万回正しくやっても一度誤れば、漏えいです。だから経験あるチームは開発者の記憶に頼りません。分離を土台に組み込み、忘れることが単に起こりにくいのではなく不可能になるようにします。あなたはそのやり方を理解する必要はありません。そうしているかを尋ねる必要があるのです。

この問題には、より静かな親戚もいます。「うるさい隣人」です。テナントがインフラを共有するため、ある顧客が重いこと、たとえば巨大な取り込みや暴走したレポートを行うと、他の全員のためにシステムが遅くなります。一つの住戸が蛇口を全部開けると建物全体の水圧が落ちるのと同じです。良いマルチテナント設計は、上限と公平な配分でこれに備えます。とりわけ非常に大きな顧客が数社見込まれるなら、尋ねる価値があります。

シングルテナントが実は正解になるとき

マルチテナントはSaaSの既定ですが、宗教ではありません。顧客に専用のコピーを与える正当な理由はあり、良い助言者は、すべてを共有モデルに押し込まず、そうした場面に行き当たったときに教えてくれます。

• 規制業界の顧客（医療・金融・行政など）で、コンプライアンス上、データが証明可能なほど分離された場所に置かれることが事実上求められる場合。
• 専用構成に見合うだけ支払う大口顧客一社で、他の全員の体験に漏れ出させたくない深いカスタマイズを求める場合。
• テナント間漏えいの代償が事業を終わらせるほど機微なデータで、最大限の分離が追加費用に値する場合。
• ソフトウェアがあなたのクラウドではなく顧客自身の壁の内側で動かなければならない、オンプレミスの要件。

型に注目してください。シングルテナントは意図して手を伸ばす例外であり、通常は特定の価値の高い顧客のためであって、事業全体を築く既定ではありません。開発者が初日からあなたの標準製品にシングルテナントを提案するなら、理由を順を追って説明してもらってください。たいていは運用コストの大幅な増加と更新の遅さを意味し、それが偶然ではなく選択であってほしいはずです。

誰かがコードを書く前に尋ねるべき質問

あなたが設計をする必要はありません。設計する人が正しいことを考え抜いているかを確かめる必要があります。これは、非エンジニアの創業者に最初の打ち合わせへ持参してほしい短いリストです。印刷し、尋ね、どれだけ自信を持って答えられるかを見てください。

1. 1
   テナントのデータをどう分離して保ちますか。

   「気をつけます」ではなく、システムが担保するという構造的な答えを聞き取ってください。これは譲れない一点です。
2. 2
   どのモデルを使い、なぜですか。

   共有テーブル、別々の区画、テナントごとのDB。間違った答えはありませんが、あなたの顧客と予算に合う理由があるべきです。
3. 3
   後で大口顧客に専用の分離を提供できますか。

   完全な共有から始めても、作り直しなしで一社の大規模または規制対象の顧客により強い分離を与える余地を設計が残すべきです。
4. 4
   一顧客が巨大になったら何が起きますか。

   重いテナント一社が他の全員を遅くするのをシステムはどう防ぎますか。うるさい隣人の場面が考慮されていたと聞きたいところです。
5. 5
   一顧客のデータをどうきれいに書き出し・削除しますか。

   顧客は去り、プライバシー法は要請に応じたデータ削除を求めます。これは慌てる事態ではなく、単純でよく理解された操作であるべきです。

あなたは答えの技術的な細部を採点しているのではありません。これらの質問のどれもが不意打ちにならないかを確かめているのです。マルチテナントソフトウェアを以前作ったチームなら、五つすべてに歯切れよく、ほとんど退屈そうに答えます。一つ目や三つ目でのためらいは、速度を落として掘り下げる合図です。

短く、現実味のある実例

ある創業者が、小規模クリニック向けのスケジューリングツールの動くプロトタイプを携えて来ました。すでに有料顧客が三社いて、そして静かな問題を抱えていました。早く市場に出すため、最初の開発者は各クリニックにアプリの別々のコピーを与えていたのです。三顧客、三インストール、わずかに異なる三つのバージョン。それぞれが途中で小さな手直しを頼んだからです。

三社では見事に動いていました。創業者の悪夢は三十社という想像でした。不具合修正のたびに三カ所へログインです。新機能のたびに三回の展開と三つのテスト対象です。新しいクリニックは手作業で立ち上げるのに週の大半を要しました。彼らを立ち上げまで連れてきたモデルが、いまや成長の上限になっていたのです。まさに本稿全体が扱う土台の問題です。

私たちは劇的な書き直しですべてを引き剥がしたわけではありません。中核を、システムレベルで分離を担保する共有マルチテナントの土台へ作り替え、クリニックごとのカスタマイズは別々のコードベースではなく設定可能な項目として残し、既存の三クリニックを並行して一つずつ移行し、誰も怖い切り替えの日を迎えずに済むようにしました。新しいクリニックの導入は、一週間の手作業からセルフサービスの申し込みへと変わりました。新機能はいまや単一のリリースからすべての顧客に届きます。

ここでの数字は例示であって約束ではありません。製品ごとに違います。しかし形は典型的です。作り直しには実際の費用と数カ月がかかり、指一本動かさず突然受け入れられるようになった最初のひと握りの新規顧客の中で元を取りました。創業者が持ち帰った教訓は、より安いものでした。最初に五つの質問をしていれば、作り直すものは何もなかった、ということです。

よくある質問