マルチテナント化で知っておきたいデータベースのこと

© 2022, Amazon Web Services, Inc. or its Affiliates. All rights reserved.
アマゾンウェブサービスジャパン合同会社
2022/01/07
内⼭義夫
マルチテナント化で知っておき
たいデータベースのこと

アジェンダ
• データベースにおけるSaaSパーティショニングモデル
• データベースエンジン毎の構成イメージ
• マルチテナント化に向けた考慮点
• まとめ

データベースにおける
SaaSパーティショニングモデル

クラウドにおける SaaS 化のフェーズ
フェーズ0. クラウドリフト
クラウド上でのサーバ稼働
フェーズ1. シングルテナント移⾏
サイロ化モデル
フェーズ2. ⼀部マルチテナント移⾏
データ層共通化
フェーズ3. 完全マルチテナント移⾏
アプリ/データ層共通化
フェーズ4. クラウド最適化
コンテナ化・サーバレス化
運⽤コスト減

クラウドにおける SaaS 化のフェーズ
フェーズ0. クラウドリフト
クラウド上でのサーバ稼働
フェーズ1. シングルテナント移⾏
サイロ化モデル
フェーズ2. ⼀部マルチテナント移⾏
データ層共通化
フェーズ3. 完全マルチテナント移⾏
アプリ/データ層共通化
フェーズ4. クラウド最適化
コンテナ化・サーバレス化
テナント分離

テナント分離の考え⽅
サイロモデル分離
Service
Service
Service
Service
Service
Service
Service
Service
Service
Service
Service
Service
Service
Service
プールモデル分離
シングルテナント例マルチテナント例
テナント1 テナント2 テナント1 テナント2 テナント3

データベースにおけるSaaSパーティショニングモデル
ブリッジモデルプールモデル
Tenant 1 84049-49 True
Tenant 2 82-84-949 False
Tenant 1 Bob Smith
Tenant 2 Lisa Johnson
テナントIDによる⾏の特定
テナント1
データベース
テナント2
データベース
サイロモデル
テナント1
スキーマ
テナント2
スキーマ
データベース

• メリット
• コンプライアンス適⽤
• 環境分離
• テナント間影響
• テナント固有チューニング
• テナントレベル可⽤性
• デメリット
• コスト⾼
• アジリティ
• 管理複雑化
• デプロイ
• 分析測定収集
SaaSパーティショニングモデルのメリット・デメリット
• メリット
• アジリティ
• コスト最適化
• 集中管理
• 適⽤簡素化
• 分析測定収集
• デメリット
• テナント間影響
• コンプライアンス
• オール・オア・ナッシング可
⽤性
サイロモデルプールモデル
ブリッジモデル

サイロモデル
• 概要
• １つのデータベース上に１つのテナントデータを作
成
• 同⼀構成のデータベースが複数存在
• OSリソースはCPU、メモリ、ディスクが他のテナン
トから分離
• メリット
• あるテナントのアクティビティが他のテナントに影
響を与えない
• テナント固有にスケールアップ等のチューニングが
可能
• 可⽤性をテナントレベルで管理可能
• データベース障害時の影響を極⼩化
• 既存構成からの移⾏が容易
• デメリット
• テナント数が多い場合、メンテナンス効率が悪い
• コストが⾼くなる傾向
テナント1
データベース
テナント2
データベース

ブリッジモデル（スキーマ分離）
• 概要
• １つのデータベース上にテナント毎のスキーマを作成
• 同⼀構成のスキーマが複数存在
• CPU、メモリ、ディスクは他のテナントと共有
• メリット
• サイロモデルと⽐較して新規のテナント作成が容易
• CPU、メモリ、ディスクの監視と管理がシンプル
• 既存のシングルテナント・ソリューションの移⾏が⽐較
的容易
• サイロモデルと⽐べてコスト削減
• デメリット
• テナント数に⽐例してテーブル数も増加（テナントの増
加に⽐例してテーブルのオープン数も増加する為、
キャッシュ上限に達してパフォーマンスが極端に劣化す
るケースがある）
• ノイジーネイバーによるパフォーマンスの影響
• 障害発⽣時、全テナントが停⽌
テナント1
スキーマ
テナント2
スキーマ
データベース

ブリッジモデル（テーブル分離）
• 概要
• １つのデータベース上に１つのスキーマを作成
• テーブルをテナント毎に作成
• メリット
• スキーマ分離と同じ
• デメリット
• スキーマ分離と同じ
• テーブルの管理が煩雑
• テナント毎にテーブル名を変更する必要がある
• 既存のアプリケーションからの移⾏の場合、ア
プリケーションの回収が必要
テナント2テーブル
テナント1テーブル
データベース
スキーマ

プールモデル
• 概要
• 全てのテナントデータを１つのスキーマで共有
• テナントデータへのアクセスを制御するためのIDで管理
• メリット
• テーブル構成変更や機能拡張などのメンテナンスが容易
• 複数データベース、スキーマによるデータの冗⻑性が削減
• 新規のテナント作成はテナントのID作成
• テナントごとのポリシー管理が不要
• CPU、メモリ、ディスクの監視と管理がシンプル
• サイロモデルと⽐べてコスト削減
• デメリット
• 既存アプリケーションの改修が必要
• 別テナントの情報が表⽰されてしまうリスク
• ノイジーネイバーによるパフォーマンスの影響
Tenant 1 Bob Smith

ハイブリッドモデル
• 概要
• プールモデルがベース
• サイロモデルを必要とするテナント⽤に
別データベースを作成
• データアクセスレイヤーによって抽象化
• メリット
• 可⽤性要件やセキュリティ要件、性能要
件など、顧客の要件に合わせて選択可能
• デメリット
• 既存アプリケーションの改修が必要
• アプリケーションが複雑化しやすい
Data Access Layer
テナント3
テナント4
テナント1
データベース
テナント2
データベース
Tenant 3 Bob Smith

SaaSパーティショニングモデルの選択
ハイブリッドモデル
プールモデル
運⽤/メンテナンス
⼯数やコスト削減
を重視
はい
いいえ
はい
いいえ
アプリケーション
の改修可能
サイロモデル
はい
はい
はい
ブリッジモデル
特定顧客向けに
データベースの
分割が必要
いいえ
特定顧客向けに
データベースの
分割が必要
はい
いいえ

データベースエンジン毎の
構成イメージ

Oracleの場合
データベース
サイロモデル
CDB
PDB
ユーザー
データベース
CDB
PDB
ユーザー1 ユーザー2
データベース
CDB
PDB
ユーザー
データベース
CDB
PDB
ユーザー

Oracle(EE+Multitenant)の場合
CDB
PDB
ユーザー
データベース
CDB
PDB1
ユーザー
PDB2
ユーザー
CDB
PDB
ユーザー
データベース
CDB
PDB
ユーザー
サイロモデル
データベースデータベース

マルチテナント化での注意点（Oracle）
PDB採⽤のポイント
→クエリにユーザー名を指定している場合、アプリケーションの改修が発⽣す
る可能性がある
→データベース管理者ユーザーをテナント毎に分けたい
OracleのMultitenant使⽤時の注意
→OracleのMultitenantを使⽤する場合、Oracle EE+Multitenantオプション
が必要
スケールアップ時の注意
→スケールアップでCPU数が増加する場合、追加でライセンス購⼊が必要
（BYOL）

SQL Server/PostgreSQLの場合
データベース
スキーマ
インスタンス
データベース
スキーマ1
データベース
スキーマ
インスタンス
データベース
スキーマ
スキーマ2
サイロモデル
インスタンスインスタンス

SQL Server/PostgreSQLの場合（データベース分離）
データベース
スキーマ
インスタンス
データベース1
スキーマ
データベース
スキーマ
インスタンス
データベース
スキーマ
データベース2
スキーマ
サイロモデル

マルチテナント化での注意点（SQL Server/PostgreSQL）
データベース分離採⽤のポイント
→クエリにスキーマ名が指定されている場合、スキーマ分離だとアプリケー
ションの改修が発⽣する可能性がある
→バックアップをテナント単位で取得したい場合、データベース毎に分離

MySQLの場合
データベース
インスタンス
データベース1
データベース
インスタンス
データベース
データベース2
サイロモデル

マルチテナント化に向けた考慮点

マルチテナント化に向けた考慮点
• マルチテナント（プールモデル）採⽤に向けて必要な考慮点
• セキュリティ
• パフォーマンス向上
• 運⽤管理

セキュリティ

セキュリティ
• RDSにおけるデータベースセキュリティ
• VPC対応
• アクセス制御
• 暗号化
• マルチテナントにおけるセキュリティ

Private subnet
VPC対応
VPC内部の任意のサブネットで起動可能
• 起動先のサブネットをDBサブネットグループで事前に定義
• リージョン内で少なくとも2つのAZにサブネットが必要
https://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/UserGuide/USER_VPC.html
Client Your Firewall
VPC
security group

アクセス制御
デフォルトではDBインスタンスに対する
ネットワークアクセスはオフになっている
セキュリティグループによりアクセスを制御
IPアドレス範囲もしくはセキュリティグループを
ソースとして、アクセスを許可するポートを指定
• 例）RDS MySQLのTCPポート3306へのアクセスを許可
https://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/UserGuide/Overview.RDSSecurityGroups.html
security group
security group

DBインスタンスの暗号化
保管時のインスタンスとスナップショットの暗号化が可能
• DBインスタンス、⾃動バックアップ、リードレプリカ、スナップショットが対象
• AES-256暗号化アルゴリズムを使⽤しながらパフォーマンス影響を最⼩限に抑える
• データアクセスと復号の認証を透過的に処理（クライアントアプリケーションの変更は不要）
• AWS KMSで鍵管理が可能
• リードレプリカも同じ鍵で暗号化される
• インスタンス作成時にのみ設定可能
• スナップショットのコピーを暗号化して
リストアすることは可能
• 暗号化されたDBインスタンスを変更して
暗号化を無効にすることはできない
対応インスタンスタイプ
• ほとんどの DB インスタンスクラスで使⽤
• RDS 暗号化をサポートしない DB インスタンス
• db.m1.small / medium / large / xlarge
• db.m2.xlarge / 2xlarge / 4xlarge
• db.t2.micro
https://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/UserGuide/Overview.Encryption.html

DBエンジン毎の暗号化⽅式
DBエンジン
インスタンス暗号化
(AWS KMSによる鍵管理)
TDEによる
暗号化
AWS Classic
CloudHSM
による鍵管理
Oracle ○ ○ (※1) ○
SQL Server ○ ○ (※2)
MySQL
MariaDB
Aurora
○
PostgreSQL ○
(※1) Oracle は Enterprise Edition で使⽤可能な Oracle Advanced Security オプションで Transparent
Data Encryption(TDE) をサポート
(※2) SQL ServerはEnterprise EditionでTransparent Data Encryption (TDE) をサポート

インスタンス
データベース
スキーマ
マルチテナントにおけるセキュリティの課題(1/2)
テナント2
ユーザー
SELECT user_id,username
FROM users
WHERE tenant_id = ʻtenant2ʼ;
tenant_id user_id username
tenant1 1 Suzuki
tenant1 2 Sato
tenant2 1 Nakamura
tenant2 2 Takahashi
tenant3 1 Yamada
user_id username
1 Yamada
user_id username
1 Nakamura
2 Takahashi
テナント3
ユーザー
FROM users
• 該当のテナントIDを必ず指定する必要がある
テナント1
ユーザー
user_id username
1 Suzuki
2 Sato
FROM users

インスタンス
データベース
スキーマ
マルチテナントにおけるセキュリティの課題(2/2)
テナント2
ユーザー
tenant1 1 Suzuki
tenant1 2 Sato
tenant2 1 Nakamura
tenant2 2 Takahashi
tenant3 1 Yamada
テナント3
ユーザー
FROM users;
• 誤ったテナントIDの指定やテナントIDが指定されない場合の影響が甚⼤
user_id username
1 Suzuki
2 Sato
user_id username
1 Suzuki
2 Sato
1 Nakamura
2 Takahashi
1 Yamada
FROM users
テナント1
ユーザー
user_id username
1 Suzuki
2 Sato
FROM users

インスタンス
データベース
スキーマ
Row Level Security(RLS)による制御
テナント1
ユーザー
テナント2
ユーザー
tenant1 1 Suzuki
tenant1 2 Sato
tenant2 1 Nakamura
tenant2 2 Takahashi
tenant3 1 Yamada
テナント3
ユーザー
FROM users;
• Row Level Securityを使⽤して、該当のテナントIDのみの結果を取得
• アプリケーションの改修コストやテスト⼯数の削減
user_id username
user_id username
1 Yamada
user_id username
1 Suzuki
2 Sato
FROM users
FROM users
※PostgreSQL 9.5以降
Oracle RAS（EEのみ）
SQL Server 2016(13.x)以降

S U M M I T © 2019, Amazon Web Services, Inc. or its affiliates. All rights reserved.
環境作成
-- Create Table
CREATE TABLE users(
tenant_id VARCHAR(20),
user_id INT,
username VARCHAR(20),
PRIMARY KEY(tenant_id,user_id));
-- Insert Data
INSERT INTO users VALUES('tenant1',1,'Suzuki’);
INSERT INTO users VALUES('tenant1',2,'Sato’);
INSERT INTO users VALUES('tenant2',1,'Nakamura’);
INSERT INTO users VALUES('tenant2',2,'Takahashi’);
INSERT INTO users VALUES('tenant3',1,'Yamada’);
-- Create Policy
CREATE POLICY tenant_isolation_policy ON users
USING (tenant_id = current_user);
ALTER TABLE users ENABLE ROW LEVEL SECURITY;
34
-- tenant1でログイン
mydb=> select user_id,username from users where
tenant_id = ‘tenant1’;
user_id | username
---------+----------
1 | Suzuki
2 | Sato
mydb=> select user_id,username from users where
tenant_id = ‘tenant1’;
user_id | username
---------+-----------
mydb=> select user_id,username from users;
user_id | username
---------+----------
1 | Yamada
Select実⾏
Amazon Aurora PostgreSQLのRLS

パフォーマンス向上

パフォーマンス向上
• RDSにおけるパフォーマンス向上
• インスタンスタイプ変更によるスケールアップ/ダウン
• Read Replicaによるスケールアウト/イン
• マルチテナントにおけるRead Replica

スケールアップ
• マネージメントコンソールやAPIからスケールアップ可能
• インスタンスタイプ変更時はインスタンス再起動で機能停⽌する（マルチAZで軽減可能）
• コマンドライン (AWS CLI) からも可能
• スケールダウンも可能
• ⼀時的にインスタンスタイプを⼤きくして、その後戻すことも可能
• 開発DBを⽇中だけ⼤きくして、使わない夜間は⼩さくする etc..
• ストレージサイズは、拡張はできるが縮⼩はできない
• インスタンスタイプを変更すると、CPUとメモリだけでなく
ディスクI/O帯域やネットワーク帯域も変更される
$ aws rds modify-db-instance
--db-instance-identifier test-db --db-instance-class db.m3.2xlarge
--apply-immediately
https://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/UserGuide/Concepts.DBInstanceClass.html
スケールアップ

RDSのリードレプリカ（RR）
同期レプリケーション
⾃動フェイルオーバー
S3 Availability Zone A Availability Zone B
スナップ
ショット
(⾃動/⼿動)
Binlog
(トランザクションログ)
5分に1回保存
バックアップ
⾮同期レプリケーション
Binlog
リードレプリカ

リードレプリカ（RR）とは︖
レプリカDBで読み取り処理をスケールアウト
• RRは5台（Auroraは15台）まで増設できる
• マルチAZとの併⽤やクロスリージョン対応も可能
• インスタンスやストレージをマスタと異なるタイプに
設定できる
• RRはスタンドアロンのDBインスタンスに昇格でき、
MySQL, MariaDBではパラメータ設定で書き込みも可能
• DDLの⾼速化、シャーディング、リカバリに活⽤
MySQL, MariaDB, PostgreSQL, Oracle (※1) , SQL
Server（※2）、Auroraに対応
https://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/UserGuide/USER_ReadRepl.html
リードレプリカ
APP APP
読み書き
ワークロード
読み取り
ワークロード
(※1) Oracle Database の RR は、Oracle Database Enterprise Edition で BYOL を使⽤しており、
Active Data Guard Option のライセンスを取得している RDS Oracle のお客様を対象としています。
(※2) SQL Server のRRは、Enterprise Editionのみ使⽤可能です。

• 処理によって接続先を変更
マルチテナントにおけるRead Replica
40
テナント1
ユーザー
テナント2
ユーザー
テナント11
ユーザー
テナント
1-10用RR
テナント
11-20用RR
テナント
21-30用RR
テナント21
ユーザー
更新処理/リアルタイムな参照処理
テナント1
ユーザー
テナント2
ユーザー
テナント11
ユーザー
テナント
1-10用RR
テナント
11-20用RR
テナント
21-30用RR
テナント21
ユーザー
リアルタイムではない参照処理
※RRの最⼤数
- Aurora MySQL/PostgreSQL:15台
- Oracle,SQL Server,MySQL,PostgreSQL,MySQL,MariaDB:5台

• 読み取りエンドポイントに接続
• Read Replicaへの接続はラウンドロビン
• 最⼤15台まで追加可能
Amazon Aurora のRead Replica
テナント1
ユーザー
テナント2
ユーザー
テナント11
ユーザー
テナント21
ユーザー
読み取り
エンドポイント
リアルタイムではない参照処理

運⽤管理

運⽤管理
• RDSにおける運⽤管理
• CloudWatch
• 拡張モニタリング（RDS）
• Performance Insights（RDS）
• Query Plan Management
• マルチテナントにおける運⽤管理

CloudWatch
各種メトリクスを60秒間隔で取得・確認可能
• ホスト層のメトリクス
• CPU使⽤率
• メモリ使⽤量 etc..
• ストレージのメトリクス
• IOPS
• Queue Depth etc..
• ネットワークのメトリクス
• 受信スループット
• 送信スループット etc..
https://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/UserGuide/CHAP_Monitoring.html
https://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/UserGuide/MonitoringOverview.html#monitoring-cloudwatch

拡張モニタリング
• 50種類以上のOSメトリクス
• プロセス⼀覧
• 1秒〜60秒間隔で取得
• 特定メトリクスのアラーム
• CloudWatch Logsへの出⼒
• 3rd party ツール連携
https://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/UserGuide/USER_Monitoring.OS.html

拡張モニタリング（OSメトリクス）

Amazon RDS Performance Insights
p 対応エンジン
ü Aurora PostgreSQL
ü Aurora MySQL 5.6 1.17.3+, 5.7 2.04.2+
ü RDS PostgreSQL 10、11
ü RDS MySQL 5.6.41+、5.7.22+ (5.5, 8.0以外)
ü RDS MariaDB 10.2+ (10.0, 10.1, 10.3以外)
ü RDS Oracle
ü RDS SQL Server (SQL Server 2008以外)
p 主要な機能
ü データベースロードチャート
ü カウンターメトリクスチャート
ü Top N Dimensionテーブル
ü 7⽇間のデータ保持期間(デフォルト)
• 2年間の⻑期保持も選択可能
p CloudWatchアラーム / API / SDK
Performance Measure
- データベースロード (Average Active Sessions)
Dimension
- 待機イベント
- SQL
- ホスト
- ユーザー

Performance Insights ダッシュボード
Database Loadチャート
Top N Dimensionテーブル

Aurora PostgreSQL: Query Plan Management
apg_plan_mgmt.use_plan_baselines = true
ü ⼿動/⾃動でプランのキャプチャー
ü ベースライン内のプランを使⽤
ü プランの承認/拒否
ü プランの測定/⽐較
ü pg_hint_planを使ったプランの修正
ü プランの削除
ü プランのエクスポート/インポート
dba_plansビュー
ベースライン内のプランを使⽤
サポートバージョン
機能概要統計情報の変化環境(パラメータ)の変化バインド変数の変化アップグレード
プランの安定化
ü Aurora PostgreSQL 2.1.0以降
(PostgreSQL 10.5互換)
ベースライン
(承認済み)
* デフォルトで32⽇以上未使⽤のプランは⾃動削除
(apg_plan_mgmt.plan_retention_period)
* デフォルトで最⼤1,000個のプランをキャプチャー
(apg_plan_mgmt.max_plans)

マルチテナントにおける運⽤管理の課題
パフォーマンス問題発⽣時にOSリソースだけだと原因特定が困難
どのテナントで負荷が
⾼いかわからない

Performance Insightsによる可視化
Performance Insights
テナント毎（接続
ユーザー毎）の
状態を確認可能

該当テナントのSQL特定
該当テナントで実⾏
されているSQLの
⼀覧
→SQLチューニング検討
• 負荷の⾼いテナントを選択し、実⾏されているSQLを特定

まとめ

まとめ
• SaaSパーティショニングモデル毎のメリットデメリットの把握
• 要件に合わせてモデルを選択
• マルチテナント化が必要な場合、考慮すべきポイントを抑えておく

Thank you!

マルチテナント化で知っておきたいデータベースのこと

マルチテナント化で知っておきたいデータベースのこと

Recomendados

Más contenido relacionado

Was ist angesagt?

Was ist angesagt?(20)

Similar a マルチテナント化で知っておきたいデータベースのこと

Similar a マルチテナント化で知っておきたいデータベースのこと(20)

Más de Amazon Web Services Japan

Más de Amazon Web Services Japan(20)

マルチテナント化で知っておきたいデータベースのこと