サイボウズのマルチテナント指向のデータベースプラットフォーム

サイボウズのマルチテナント指向の データベースプラットフォーム 2026.09.30 1

発表者について クラウド基盤本部 Datastore 部 DBRE チーム 飯塚 翔 データを持っているミドルウェアを担当する部署で、 データベースを見ているチームに所属しています 2

サイボウズが提供する SaaS (cybozu.com) について 「チームワークあふれる社会を創る」という企業理念のもと、チームワークを支援するための 製品を提供しています 契約社数（≒ テナント数） 71,000 社 3

DBRE チームの役割 この規模のマルチテナント SaaS のためのデータベースプラットフォームを 提供しています MySQL をオンプレミスのプライベートクラウドの Kubernetes 上で運用 運用自動化のためのコントローラー MOCO を開発し、OSS で公開 https://github.com/cybozu -go/moco データベースをセットアップするだけで終わらず、 マルチテナント SaaS のための付加機能をつけて提供しています 4

1 cybozu.com のデータパーティショニングモデル 2 テナントプロビジョニングのリアーキテクト 3 B2B SaaS としてのインシデントコミュニケーション 5

1. cybozu.com の データパーティショニングモデル 6

データベースのパーティショニングモデルの分類 database tenant_id col1 col2 … tenant_1 tenant_2 database (tenant_1) tenant_1 database (tenant_2) tenant_1 1. アイテムレベルの分離 2. スキーマレベルの分離 3. インスタンスレベルの分離 7

cybozu.com ではスキーマレベルの分離を採用 サイボウズはもともとパッケージ製品の会社 1 • お客様が社内のオンプレサーバーのインストールして利用 • マルチテナント前提で作られていない製品に、あとから tenant_id を 追加して SQL を全て修正するのは困難が伴う サイボウズの事業のターゲットを考慮 2 • SMB のお客様を中心にして事業が成長してきた • インスタンスレベルの分離はインフラコストが高価で、 テナントあたりの単価を高めに設定しないといけなくなってしまう 8

さらにシャーディングモデルを採用 テナント1 テナント2 テナント3 テナント4 テナント5 テナント6 テナント7 テナント8 テナント9 • ひとつのインスタンスに全テナントを収容するのは不可能 • データ量、CPU 、… • 数百インスタンス に分散して収容するための MySQL のリソースプールを運用 9

SaaS のビジネスモデルとシャーディングモデルの相性 テナントごとに お支払いいただける料金 テナント数 SaaS の事業成長はテナント数とテナントあたりの単価の2つの軸がある。 テナント数の増加に対してはシャーディングモデルはリニアにスケールアウトできる。 10

NewSQL などスケーラブルな技術を使う？ 数百インスタンスの運用は大変なので、正直うらやましい部分はある ただし、スケールアウトを実現するために払っている追加のコストとして… • 性能あたりのインフラコスト • 分散して整合性をとるのに生じるレイテンシ などのネガティブ要素もある。 シャーディングモデルはインスタンスレベルのスケールアウトに制限がある代わりに、 インフラコストやレイテンシはリーズナブル 11

シャーディングモデルに対する苦言 “これは理想的なモデルとはほど遠く、SaaS 環境に複雑さと余計な手間を加える ことになります。ただし、ワークロードやビジネス要件によっては、これを合理的 なトレードオフとみなすことができるため、ここで紹介しました。” マルチテナントSaaS アーキテクチャの構築 (2025) p.205 確かに、 • 新しいテナントをどのシャードに配置するのか？ • あるテナントはどのシャードに収容されているのか？ といった複雑さが持ち込まれている 次のチャプターへ 12

2. テナントプロビジョニングの リアーキテクト 13

SaaS 固有のコンポーネント 書籍「マルチテナントSaaS アーキテクチャの構築」 (2025) による指摘 • アプリケーションプレーン： 顧客が使う SaaS アプリケーションそのもの • コントロールプレーン： SaaS プロバイダーの管理アプリケーション • テナントのライフサイクル管理（作成、削除） • 請求 テナントの作成処理（プロビジョニング）では以下のような処理が必要 • データベースのスキーマを作成する、ユーザーを作成して権限を付与する、CREATE TABLE 、…… • ほかのミドルウェアやマイクロサービスにも同様の初期化が必要なことも 14

プロビジョニングの旧実装 あるチームが全製品のプロビジョニング処理をすべて担当するスクリプトを書いていた データベース オブジェクトストレージ init-app 依存マイクロサービス① 依存マイクロサービス② 長年このやり方で頑張ってきたが、事業拡大についていけないということでリアーキテクト 15

各プロダクトのプロビジョニングをサポートするコンポーネントの開発 • プロダクトごとのプロビジョニングの詳細は各プロダクトチームに委譲する • DBRE チームからは、データベースの初期化処理をサポートするコンポーネント (mysql - tenant - service ) を開発して提供 CreateTenant 数百インスタンスある MySQL のリソースプールから空いているインスタンスを 探してきてスキーマ作成、ユーザー作成、権限付与 Resolve あるテナントがどのインスタンスに収容されているのか返す ListTenants あるインスタンスに収容されているテナントの一覧を返す リソースプランニングへの影響 新しいテナントにどのインスタンスに収容するのか振り分けるバランシングのロジックは、 リソースプランニングの重要な要素。 DBRE チームに集約してコスト最適化を図りたい 16

3. B2B SaaS としての インシデント・コミュニケーション 17

シャーディングモデルでの障害の起こり方 シャーディングモデルでは、障害はインスタンス単位で発生することが多い テナント1 テナント3 テナント2 テナント4 テナント5 テナント6 テナント7 テナント8 テナント9 • 爆発半径 (Blast Radius) が小さいのはメリット • 誰が影響を受けているのか分かりにくいのが課題 18

cybozu.com 稼働状況サイトの提供 cybozu.com が使えなかったらこのページをご覧いただき、 ご自身のテナントで障害が発生していないかご確認いただく使い方を想定 19

DBRE チームの監視と稼働状況サイトの連携 VictoriaMetrics GET /metrics monitor read/write Alertmanager オンコール担当 20

DBRE チームの監視と稼働状況サイトの連携 VictoriaMetrics GET /metrics monitor read/write Alertmanager Webhook オンコール担当 稼働状況サイト ListTenants mysql-tenant-service 21

まとめ 1. cybozu.com のデータパーティショニングモデル • スキーマ分離を採用 • シャーディングモデルは現状の事業にとっては合理的な選択と考えている 2. テナントプロビジョニングのリアーキテクト • mysql -tenant -service の提供によってシャーディングモデルがもたらす複雑さを吸収 3. B2B SaaS としてのインシデントコミュニケーション • 監視を DBRE チームだけに閉じず、顧客向けの稼働情報サイト向けとも連携 22