目次を表示する

共通基盤の設計軸 2026 ─ 抽象・責務・非機能要件を設計する 15 章

マルチテナンシー ─ Hot tenant 対策と Quota

マルチテナンシー ─ Hot tenant 対策と Quota

共通基盤の多くは マルチテナント。1 つのインスタンスが多数の tenant を抱える。1 tenant の異常な使い方が他 tenant に波及する のを防ぐのが、この章の主題。

前作 DB 設計の軸 2026 ch16 で 判断 4：Hot Tenant 対策 を扱った。本章ではこれを基盤全体に拡張する。

Noisy Neighbor 問題

Microsoft Azure Architecture Center “Noisy Neighbor antipattern” が定義：

1 tenant の重い workload（大量 import、複雑 query、batch 処理）が 共有の CPU / メモリ / I/O を不釣り合いに消費し、同じインフラ上の他 tenant の性能を劣化させる。

graph TB
  subgraph "Shared Infra"
    R[CPU / Memory / I/O]
  end

  T1[Tenant A: 通常使用] --> R
  T2[Tenant B: 通常使用] --> R
  T3[Tenant C: 暴走 90% を消費] --> R

  R -. 残り 10% で A B が苦しむ .-> T1
  R -. 残り 10% で A B が苦しむ .-> T2

  style T3 fill:#ffe1e1

これを防ぐのが Tenant Isolation の役割。

2026 年の Isolation 技術トレンド

Kubernetes が標準

ほぼ全ての SaaS が Kubernetes で動いている。Tenant Isolation の道具：

  • Namespace: tenant ごと
  • ResourceQuota: tenant の resource 上限
  • NetworkPolicy: tenant 間の通信制御
  • PodDisruptionBudget: tenant 別の availability

Hardened Container Runtime（2026 年トレンド）

伝統的な container は 同じ kernel を共有しているため、kernel exploit で全 tenant に影響しうる。これを解決するのが Hardened runtime：

Runtime仕組み
Kata Containers軽量 VM で各 container をラップ、独立 kernel
Edera Runtime2026 年に台頭、より軽量な VM-based isolation
gVisoruser-space kernel で system call を中継
FirecrackerAWS Lambda が使う micro-VM

2026 年の傾向：「container は便利だが kernel 共有が怖い」と認識され、multi-tenant SaaS は hardened runtime に移行中。

Memory が CPU より noisy

2025 WJARR study（前章のリサーチで触れた）：

Memory-intensive workload は CPU-bound workload より tenant 間干渉を引き起こす。

理由：

  • Memory bandwidth は共有（CPU はコア分離可）
  • Cache の汚染（1 tenant が L3 cache を埋めると他 tenant が遅くなる）
  • NUMA（メモリのトポロジーが性能に直結）

CPU 制限だけでなく、Memory bandwidth / cache も意識した設計が要る。

4 段階の Isolation 戦略

graph TB
  L1[L1: 論理分離<br/>Row-level filtering / tenant_id]
  L2[L2: Schema 分離<br/>Schema-per-tenant]
  L3[L3: DB / コンテナ分離<br/>DB-per-tenant / Pod-per-tenant]
  L4[L4: 物理分離<br/>Cluster-per-tenant / VM-per-tenant]

  L1 --> L2 --> L3 --> L4

  Note1[下に行くほど分離強い、コスト高]

  style L1 fill:#fff4e1
  style L4 fill:#ffe1e1

戦略の選び方

Tier推奨分離コスト
FreeL1（論理）最安
ProL1-L2低
EnterpriseL2-L3中
Critical（金融・規制）L3-L4高

ティア別に分離度を変える のが現実的。Stripe / GitHub / Slack は基本 L1-L2、Enterprise だけ L3。

Quota と Rate Limit

Isolation の 行動制限 側として Quota と Rate Limit。

Quota（累積上限）

# Tenant の上限
storage_bytes: 10_000_000_000  # 10GB
api_calls_per_month: 1_000_000
concurrent_connections: 100

累積で超えるとエラー にする。Free tier の上限を作ったり、課金プランの境界に使う。

Rate Limit（時間あたり上限）

// Token Bucket（Redis で実装）
async function checkRateLimit(tenantId: string, capacity: number, refillRate: number) {
  const key = `rl:${tenantId}`;
  // ... bucket logic
  if (tokens < 1) {
    return { allowed: false, retry_after: timeUntilRefill };
  }
  return { allowed: true };
}

急激な burst を吸収 + 持続的な過負荷を抑える。

Tier 別の Limit

free_tier:
  rate_limit: 60/min
  burst: 100
pro_tier:
  rate_limit: 600/min
  burst: 1000
enterprise:
  rate_limit: unlimited
  burst: 10000

Limit 超過時の挙動

HTTP/1.1 429 Too Many Requests
Retry-After: 30
X-RateLimit-Limit: 60
X-RateLimit-Remaining: 0
X-RateLimit-Reset: 1715234430

利用者が どれくらい待てばいいか 機械可読で伝える。

Hot Tenant の早期検知

Per-tenant の Metrics

// 各 tenant の使用量を観測
const counter = meter.createCounter('platform_requests', {
  attributes: { tenant_id: tenantId }
});

ダッシュボードで 使用量 top 10 tenant を表示し、異常を早期検知する：

Tenant A: 50,000 req/min  ← 突如急増
Tenant B: 10,000 req/min
...

異常 → 自動アラート → 手動 / 自動で intervene。

Auto-scaling vs Throttling

異常な tenant を発見したら：

対応いつ
Auto-scale全体の負荷増、tenant 全員が忙しい
Throttle1 tenant が異常、他に影響を与えている
Quarantine攻撃が疑われる tenant を隔離

すべてが auto-scale で解決するわけではない。特定 tenant の throttling が選択肢として必要。

Per-tenant の専用 worker

優先度が高い tenant には 専用 worker を割り当てる：

# Enterprise tenant 用
enterprise_worker_pool:
  size: 50
  tenants: [t-001, t-002, ...]

# 共有 worker pool
shared_worker_pool:
  size: 200
  tenants: <all others>

Bulkhead パターンの組織化。SLA を保証したい tenant を物理的に隔離する。

Tenant の “重み” を調整する

すべての tenant が等価ではない。重み付け で公平性を担保：

// 課金プランで weight を分ける
const weights = {
  free: 1,
  pro: 10,
  enterprise: 100,
};

// 重みに比例して resource を割り当て
const cpuShare = baseCpu * weights[tenant.plan];

K8s の request / limit がこれを実装。

Multi-tenant の Trade-off

graph TB
  Cost[コスト効率]
  Isolation[Isolation の強さ]

  Cost <-->|Trade-off| Isolation

  Note1[完全 isolation = コスト 10x<br/>完全共有 = noisy neighbor リスク]

  style Cost fill:#e1f5ff
  style Isolation fill:#fff4e1

ティア / プランで使い分ける。全 tenant に最強 isolation を提供しない。

マルチテナンシーのチェックリスト

graph TB
  Q1[Isolation tier 戦略] --> Q2[Quota 設定]
  Q2 --> Q3[Rate Limit per tier]
  Q3 --> Q4[Per-tenant Metrics]
  Q4 --> Q5[Hot tenant 検知 + 対応]
  Q5 --> Q6[Bulkhead で組織化]
  Q6 --> OK[多 tenant の安定運用]

  style OK fill:#e1ffe1

この章の要点

  • Noisy Neighbor 問題：1 tenant の workload が他 tenant の性能を劣化
  • 2026 トレンド：Hardened runtime（Kata, Edera）への移行、memory bandwidth 重視
  • Isolation 戦略 4 段階：論理 / Schema / DB / 物理。tier で使い分け
  • Quota（累積）+ Rate Limit（時間）の組み合わせ
  • 429 レスポンスは Retry-After 等で機械可読
  • Hot tenant 検知は per-tenant metrics、対応は throttle / quarantine / scale
  • Enterprise tier は専用 worker pool で Bulkhead

次章への問いかけ

ここまでは「いま動かす」の話。基盤は 進化 しなければならない。

次章で進化と保守 ── Versioning、Deprecation、Migration の作法。