マルチテナンシーのためのシャーディング

# マルチテナンシーのためのシャーディング ## 定義マルチテナンシーのためのシャーディングとは、SaaS製品やクラウドサービスにおいて各テナント(顧客)のデータセットを分離するために、シャーディングの単位をテナント境界と一致させる設計手法である。各テナントに専用のシャードを割り当てるか、複数の小さなテナントをまとめて1つの大きなシャードに配置する。これらのシャードは物理的に別々のデータベースの場合もあれば、大きな論理データベース内の個別管理可能な部分の場合もある。[[@2026__OReilly__Designing Data-Intensive Applications 2E - Chapter 7 Sharding]]がこの用途を体系的に整理している。 ## セル型アーキテクチャ(cell-based architecture) シャーディングはストレージ層だけでなく、アプリケーションコードを実行するサービス層にも適用できる。特定のテナント群のサービスとストレージを自己完結した*セル*にまとめ、異なるセルが互いにほぼ独立に動作するように構成する方式をセル型アーキテクチャと呼ぶ。あるセルの障害はそのセルに限定され、他のセルのテナントに影響しない(*障害分離*、fault isolation)。(Source: [[@2026__OReilly__Designing Data-Intensive Applications 2E - Chapter 7 Sharding]] "Sharding for Multitenancy") ## 利点 | 利点 | 内容 | |---|---| | リソース分離 | あるテナントの高負荷な処理が他テナントの性能に影響しにくい | | 権限分離 | アクセス制御ロジックのバグがあっても、物理的に分離されたデータセット間では他テナントへのアクセス漏洩が起きにくい | | セル型アーキテクチャ | サービス+ストレージをセル単位でまとめ、障害を1セルに限定する | | テナント単位のバックアップ/リストア | あるテナントの誤削除・上書きから、他テナントに影響を与えずに復元できる | | 規制遵守 | GDPR・CCPA等の個人データのアクセス/削除要求を、対象テナントのシャードに対する単純なエクスポート/削除操作に落とし込める | | データ主権(data residence) | 特定テナントのデータを特定法域に配置する要件をリージョン対応データベースで満たせる | | 段階的スキーマロールアウト | スキーマ移行をテナント単位で段階的に展開し、影響範囲を限定しながらリスクを下げられる(ただしトランザクショナルに行うのは難しい) | ## 課題 - 個々のテナントが単一ノードに収まらないほど大きい場合、そのテナント内部でさらにシャーディングが必要になり、通常のスケーラビリティ目的のシャーディングの問題に帰着する。 - 小さなテナントが多数ある場合、テナントごとに専用シャードを作るとオーバーヘッドが過大になる。複数の小テナントを1シャードにまとめる場合、テナントが成長したときにシャード間を移動させる仕組みが別途必要になる。 - テナントをまたぐ機能(クロステナント集計など)を提供する場合、複数シャードにまたがるデータ結合が必要になり実装が難しくなる。 (Source: [[@2026__OReilly__Designing Data-Intensive Applications 2E - Chapter 7 Sharding]] "Sharding for Multitenancy") ## 横断的知見 - **DNS ベースのドメイン単位シャーディング(ロードバランサー層)は、テナント境界とシャード境界を一致させるという同じ目標を、DDIA の「データベース層でのテナントシャーディング」とは異なるレイヤーで実現する**: [[@2021__OReillyJapan__SREの探求 - Chapter 25 スクリプタブルロードバランサー]]が示す「DNS を用いたリクエストのルーティング」は、マルチテナントアプリケーション(ドメイン名でシャード分割できるデータモデル)を対象に、シャードごとに一意のドメインを与え DNS 解決で正しいシャードへ導く。これは DDIA 第7章が述べる「テナントごとに専用シャードを割り当てる」設計と目的は同じだが、判断が行われる場所が DNS/ロードバランサー層かデータベース層かで異なる。SRE の探求はこの DNS 方式の弱点として、ルーティング情報の変更が収束するまでの時間が予測できない点と、シャード識別方法がドメイン名のみに制約される点を挙げ、この制約を克服する解として「シャードのルーティングロジックをロードバランシング層に完全に移す」[[スクリプタブルロードバランサー]]方式を提示する。これは DDIA が論じない「テナント識別をどのレイヤーでどう解決するか」という実装上の選択肢を補う。(Source: [[@2026__OReilly__Designing Data-Intensive Applications 2E - Chapter 7 Sharding]] "Sharding for Multitenancy", [[@2021__OReillyJapan__SREの探求 - Chapter 25 スクリプタブルロードバランサー]] ch.25 §25.2.1.1, §25.2.1.4) - **セル型アーキテクチャの「障害分離」目的と、スクリプタブルロードバランサーによるシャードルーティングの「抽象化の漏れの除去」目的は補完関係にある**: DDIA のセル型アーキテクチャはサービス+ストレージをテナント群単位で自己完結させ、あるセルの障害を他セルのテナントに波及させない。SRE の探求のスクリプタブルロードバランサー方式は、シャード分割という関心事をアプリケーションから完全に隠蔽し、シャード分割ロジックを複数アプリケーション間で再利用可能にする(Google Slicer が例)。両者を組み合わせると、ロードバランサー層がテナント/シャード解決を担い、解決されたリクエストの転送先がセル単位で障害分離される、という2層構成が構想できるが、両ソースともこの組み合わせ自体は論じていない。(Source: [[@2026__OReilly__Designing Data-Intensive Applications 2E - Chapter 7 Sharding]] "Sharding for Multitenancy", [[@2021__OReillyJapan__SREの探求 - Chapter 25 スクリプタブルロードバランサー]] ch.25 §25.2.1.4) ## 未解決の問い - セル型アーキテクチャの「セル」の粒度(1テナント1セルか、複数テナントで1セルか)をどう決定するかについて、DDIA第7章は具体的な指針を示していない。AWSのWell-Architectedホワイトペーパー(章の脚注が参照する Oliveira 2023)はどの程度の定量的指針を与えているか。 - 小テナントの動的な再配置(成長に応じたシャード間移動)を無停止で行う一般的な手法は、通常のスケーラビリティ目的のリバランシングと同じ機構を流用できるか、それともテナント特有の追加設計が必要か。 - クロステナント機能(集計・検索等)の実装は、[[二次インデックスのシャーディング戦略]]のグローバルセカンダリインデックスと同じアプローチで解決できるか、それともテナント分離の要件(権限分離)と衝突するか。 - ロードバランサー層でのテナント/シャード解決(SRE の探求)とデータベース層でのテナントシャーディング(DDIA)を併用する場合、テナント境界の定義がどちらの層でも一致していることをどう保証するか。設定のドリフト(ロードバランサーのルーティングルールとデータベースのシャードマップの不整合)はどう検知するか。 ## 関連 - ソース: [[@2026__OReilly__Designing Data-Intensive Applications 2E - Chapter 7 Sharding]] / [[@2021__OReillyJapan__SREの探求 - Chapter 25 スクリプタブルロードバランサー]] - 概念: [[データパーティショニング]] / [[二次インデックスのシャーディング戦略]] / [[シェアードナッシング]] / [[スクリプタブルロードバランサー]] ## 出典 - [[@2026__OReilly__Designing Data-Intensive Applications 2E - Chapter 7 Sharding]] "Sharding for Multitenancy" - [[@2021__OReillyJapan__SREの探求 - Chapter 25 スクリプタブルロードバランサー]] ch.25 §25.2.1.1, §25.2.1.4(DNSベースのドメイン単位シャーディングとその限界、ロードバランサー層への解決の移動)