マルチテナントコア

マルチテナントコアは、独立したリソースで多くの独立したクライアント（テナント）にサービスを提供するプラットフォーム/製品の基本層であり、保証された分離、管理された制限、安全なカスタマイズを提供します。よく設計されたコアは、TCOを削減し、オンボーディングを高速化し、リリースを簡素化し、すべてのテナントに予測可能な品質を提供します。

1）テナントモデルと分離境界

［定義］

テナント/組織/アカウント-独自のユーザー、データ、ポリシー、および制限を持つ論理的な組織。
分離：1つのテナントが別のテナントのデータ、パフォーマンス、セキュリティに影響を与えるのを防ぐ機能。

絶縁レベル

1.データ：個々のデータベース/スキーマ/テーブル、「テナントキー」による暗号化、'tenant_id'フィルタ。
2.計算：CPU/RAM/IOクォータ、テナントワーカーのプールまたは重み付けされたキュー。
3.ネットワーク：セグメンテーション、プライベートエンドポイント/VPN、テナントによる許可のリスト。
4.オペレーション：移行、バックアップ、DR、インパクトの境界を持つインシデント「テナントあたり」。

マルチテナンシーパターン

サイロ（ハードアイソレーション）：テナントごとの個々のクラスタ/データベース。最高の保証、高価格。
プール：論理的な分離を伴う共有インフラストラクチャ；「騒々しい隣人」のよりよい効率、より高い危険。
ブリッジ/ハイブリッド：ハイブリッド-VIP/規制された顧客のための共通制御平面+選択的に「サイロ」。

2）テナントリクエストの特定とルーティング

テナントの解決

ドメイン別： 'https：//{tenant} 。example。「コム」

途中で： '/t/{ tenant}/'……

タイトル： 「X-Tenant-Id」、 「X-Org」（署名検証）

トークン別： スタンプ'tenant_id'、 'org_id'、 'plan'、 'scopes'

ルーティング

L7ゲートウェイ（API ゲートウェイ/Ingress）は'tenant_id'を抽出し、コンテキスト（'plan'、 limits、 region）を強化し、trails/logsに書き込みます。
関数サービスは読み取り専用コンテキストを受け入れます。ルートと制限の決定は、ゲートウェイ/ポリシーエンジンによって行われます。

3）データとスキーマ： 戦略

ストレージオプション

共有スキーマ、行レベル：テーブルの1セット、'tenant_id'フィールド、厳密なRLS （Row-Level Security）。
Shared-DB、 per-schema： 1つのDBMS、テナントごとに個別のスキーム。制御性と絶縁性のバランス。
Per-DB/クラスタ：テナントごとに個別のデータベース/クラスタ。より高価で、より簡単に、主権者の主張のために。

キープラクティス

どこでも明示的に'tenant_id'を渡し、複合キー/インデックスに含めます。
RLS/DBMSレベルのアクセスポリシー+ダブルロックサービス検証。
暗号化：キー階層（ルートKMS→テナントごとのキーエンベロープ→オブジェクトごとのDEK）。
アーカイブ/保持と「忘れられる権利」は、テナントレベルのポリシーによって管理されます。

4）設定、機能、バージョン

テナント構成

テーブル/ストレージ'tenant_config'（プラン、クォータ、フィーチャーフラグ、ローカライズ、SLA）。
コンフィギュレーションの優先順位：デフォルト→プラン→テナント→環境→ユーザー。
短いTTLとイベントによる障害による設定キャッシュ。

フィーチャーフラグと互換性

機能ポイント（テナントごと/コホートごと）、カナリアロールを有効にします。
APIバージョン管理：ボーダーの安定したコントラクト+アダプタ（前後互換フォーマット）。

5）制限、クォータ、請求

消費ポリシー

料金制限：テナント/ルートごとに'requests/sec'、プランの優先順位を持つ「token-bucket」。
クォータ：ストレージ容量、オブジェクト数、メッセージ/分、ジョブ/時間。
公平性：キューの「加重スケジュール」+VIP用のワーカーの分離。

請求

'tenant_id'（使用メトリック）→→請求書アグリゲーターによるカウンター。
ボーダー上の使用状況スナップショット（idempotencyとイベント損失保護）。
モデル：固定プラン+消費、後払い/前払い、割引「階層」。

6）セキュリティとアクセス

認証/承認

マーク'tenant_id'、 'roles'、 'scopes'のOIDC/SAML。

RBAC/ABAC-テナントレベルの役割（所有者/管理者/リーダー）、プロジェクト/部門属性

mTLSと制限されたトークンによるサービス。

信頼境界

受諾ポリシーを要求する：ヘッダ署名検証、nonce/timestamp、ソースバインディング。
秘密と鍵：テナントごとの回転、個々のKMSコンテキスト、キー操作の監査。
マルチリージョンとデータレジデンシー：テナントを地域に固定し、クロスリージョナルフローを制御します。

7）「入居者の視認性」

トレースとメトリクス

必要なタグは'tenant_id'、 'plan'、 'region'、 'endpoint'、 'status'です。
テナントごとのSLI/SLO： 'availability'、 'p95 latency'、 'error budget'。
セグメント別のダッシュボードとアラート（VIP/規制/新規）。

ログと監査

アクティビティログ（who/what/when/where）は、テナントポリシーに従って変更不能なストレージと保持があります。
安価なストレージ、詳細の復元のためのイベントの事前集計「クリックで」。

8）性能および「騒々しい隣人」

アンチノイズ対策

キュー/ワーカー、CPUシェア、テナントあたりのIO比率のレベルの制限。
キャッシュ分離：キー接頭辞のテナント：{id}：……"、計画によるTTL、"キャッシュ・スタンピード"に対する保護。
'tenant_id'の選択性に基づいたインデックスとクエリ計画。

コールドスタートと「暖かい」プール

VIP/ピークウィンドウ用の事前ウォームアップ。
メトリック信号（バックプレッシャー/オートスケーリング）に基づくワーカーの弾性プール。

9）ダウンタイムのないアップグレードと移行

ストラテジー

下位互換性のある移行（展開→移行→契約）。
「テナントによる」移行：特定の'tenant_id'の進捗管理、「pause/rollback」のバッチ。
テナントのサブセットでのサンプリングと「カナリア」移行。

DRとインシデント

テナントごとのRTO/RPOのDR計画；グローバルダウンタイムなしの部分的な「読み取り専用モード」。
インシデントの分離：'tenant_id'によって融合し、「hot」テナントを消去することは残りには影響しません。

10） APIとプロトコル

REST/gRPCと必須テナントコンテキスト（スタンプ/ヘッダー内）。
イベント（event-driven）：サブスクリプションのために'tenant。 {id} 。event'、フィルタ、ACLを命名したトピック。
グローバルなエントリーポイント：L7ゲートウェイはコンテキストを検証し、制限を適用し、テナントのポリシーに従ってPIIを暗号化します。

11）テナントのライフサイクル

1.プロビジョニング：テナントレコードの作成、キー/コンフィギュレーションの生成、リージョンのリンク。
2.アクティベーション：OIDC/SAMLクライアントのリリース、役割/ポリシーの作成、プライマリクォータ。
3.操作：監視、請求、フラグ/計画の更新。
4.サスペンド/スロットリング：データ保持/エクスポートでフリーズします。
5.削除/エクスポート：リテンション、mothballedバックアップ、crypto-shredding。

12）ミニリファレンスアーキテクチャ（言語スキーム）

エッジ（APIゲートウェイ）：TLS/mTLS、抽出'tenant_id'、制限、監査。
コントロールプレーン：テナントのカタログ、構成、フィーチャーフラグ、請求書、政治。
データプレーン（サービス）：ステートレスサービス、キュー、クォータワーカー。Redis/kvはテナントに接頭辞を付けた。
ストレージ：RLS-DB/個別 スキーム/DB；テナントごとのキーのKMS；エンベロープ暗号化を使用したオブジェクトストレージ。
観測性：タグ'tenant_id'を持つトレース/メトリック/ログ、計画ごとのアラート。
管理者：テナントのサブセット上で隔離された操作（移行/バックアップ）。

13）売り上げ前のチェックリスト

• 国境やサービスでtenant_idを定義する単一の方法。
• RLS/ACLポリシーはテストと「ネガティブスクリプト」でテストされます。
• クォータ/リミット/請求は実際の負荷で検証されます。「請求値下げ」に対する保護があります。
• テナントあたりの可視性とSLO；VIP/規制対象のアラート。
• 移行は互換性があり、部分的なロールバックとローナーバッチがあります。
• テナントごとのRTO/RPOとDRシナリオと定期的な演習。
• テナントキー暗号化、キー回転、キー監査。
• API契約/イベントおよびバージョン管理ポリシーのドキュメント。

14）典型的なエラー

問題のあるテナントを停止することなく「、1つで」グローバルな移行がスループしました。
cache/queues→data leakage/queue crossingの'tenant_id'への非表示の依存関係。
コンテキストミキシング（'tenant_id'なしで誤って管理操作）。
「ダブルロック」がない：データベースにRLSがないサービスチェックのみ。
クラスタ全体のための単一のリミッター→「noisy neighbor」とSLO違反。
idempotencyおよび監査証跡のない非透明的な請求。

15）クイック戦略の選択

厳密な分離/規制：サイロ（独立したデータベース/クラスタ）、リージョンロック。
バランスの取れた効率：スキーマごとの共有DB+RLS、テナントごとのキー。
高いリアルタイムトラフィック：VIP用の「重み付け」クォータと専用ワーカーを持つ一般的なキュー。
多くのカスタマイズ：feature flags+API adapter、 configsを優先的に格納します。

結論

マルチテナントコアは、エンジニアリング境界の分野です。'tenant_id'の明示的な定義、すべてのレイヤーでの厳密な分離、管理されたクォータと透明な請求、およびオブザビリティとリリースの互換性。以下のパターンを使用すると、各テナントの安全性、品質、変更のスピードを犠牲にすることなく製品をスケールすることができます。