SlideShare a Scribd company logo

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

•
•
Amazon Web Services Japan
Amazon Web Services Japan

データベースにおけるSaaSパーティショニングモデル、データベースエンジン毎の構成イメージ、マルチテナント化に向けた考慮点について解説しています。

1 of 55
© 2022, Amazon Web Services, Inc. or its Affiliates. All rights reserved. アマゾンウェブサービスジャパン合同会社 2022/01/07 内⼭ 義夫 マルチテナント化で知っておき たいデータベースのこと
© 2022, Amazon Web Services, Inc. or its Affiliates. All rights reserved. アジェンダ • データベースにおけるSaaSパーティショニングモデル • データベースエンジン毎の構成イメージ • マルチテナント化に向けた考慮点 • まとめ
© 2022, Amazon Web Services, Inc. or its Affiliates. All rights reserved. データベースにおける SaaSパーティショニングモデル
© 2022, Amazon Web Services, Inc. or its Affiliates. All rights reserved. クラウドにおける SaaS 化のフェーズ フェーズ0. クラウドリフト クラウド上でのサーバ稼働 フェーズ1. シングルテナント移⾏ サイロ化モデル フェーズ2. ⼀部マルチテナント移⾏ データ層共通化 フェーズ3. 完全マルチテナント移⾏ アプリ/データ層共通化 フェーズ4. クラウド最適化 コンテナ化・サーバレス化 運⽤コスト減
© 2022, Amazon Web Services, Inc. or its Affiliates. All rights reserved. クラウドにおける SaaS 化のフェーズ フェーズ0. クラウドリフト クラウド上でのサーバ稼働 フェーズ1. シングルテナント移⾏ サイロ化モデル フェーズ2. ⼀部マルチテナント移⾏ データ層共通化 フェーズ3. 完全マルチテナント移⾏ アプリ/データ層共通化 フェーズ4. クラウド最適化 コンテナ化・サーバレス化 テナント分離
© 2022, Amazon Web Services, Inc. or its Affiliates. All rights reserved. テナント分離の考え⽅ サイロモデル分離 Service Service Service Service Service Service Service Service Service Service Service Service Service Service プールモデル分離 シングルテナント例 マルチテナント例 テナント1 テナント2 テナント1 テナント2 テナント3
© 2022, Amazon Web Services, Inc. or its Affiliates. All rights reserved. データベースにおける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 スキーマ データベース
© 2022, Amazon Web Services, Inc. or its Affiliates. All rights reserved. • メリット • コンプライアンス適⽤ • 環境分離 • テナント間影響 • テナント固有チューニング • テナントレベル可⽤性 • デメリット • コスト⾼ • アジリティ • 管理複雑化 • デプロイ • 分析測定収集 SaaSパーティショニングモデルのメリット・デメリット • メリット • アジリティ • コスト最適化 • 集中管理 • 適⽤簡素化 • 分析測定収集 • デメリット • テナント間影響 • コンプライアンス • オール・オア・ナッシング可 ⽤性 サイロモデル プールモデル ブリッジモデル
© 2022, Amazon Web Services, Inc. or its Affiliates. All rights reserved. サイロモデル • 概要 • １つのデータベース上に１つのテナントデータを作 成 • 同⼀構成のデータベースが複数存在 • OSリソースはCPU、メモリ、ディスクが他のテナン トから分離 • メリット • あるテナントのアクティビティが他のテナントに影 響を与えない • テナント固有にスケールアップ等のチューニングが 可能 • 可⽤性をテナントレベルで管理可能 • データベース障害時の影響を極⼩化 • 既存構成からの移⾏が容易 • デメリット • テナント数が多い場合、メンテナンス効率が悪い • コストが⾼くなる傾向 テナント1 データベース テナント2 データベース
© 2022, Amazon Web Services, Inc. or its Affiliates. All rights reserved. ブリッジモデル（スキーマ分離） • 概要 • １つのデータベース上にテナント毎のスキーマを作成 • 同⼀構成のスキーマが複数存在 • CPU、メモリ、ディスクは他のテナントと共有 • メリット • サイロモデルと⽐較して新規のテナント作成が容易 • CPU、メモリ、ディスクの監視と管理がシンプル • 既存のシングルテナント・ソリューションの移⾏が⽐較 的容易 • サイロモデルと⽐べてコスト削減 • デメリット • テナント数に⽐例してテーブル数も増加（テナントの増 加に⽐例してテーブルのオープン数も増加する為、 キャッシュ上限に達してパフォーマンスが極端に劣化す るケースがある） • ノイジーネイバーによるパフォーマンスの影響 • 障害発⽣時、全テナントが停⽌ テナント1 スキーマ テナント2 スキーマ データベース
© 2022, Amazon Web Services, Inc. or its Affiliates. All rights reserved. ブリッジモデル（テーブル分離） • 概要 • １つのデータベース上に１つのスキーマを作成 • テーブルをテナント毎に作成 • CPU、メモリ、ディスクは他のテナントと共有 • メリット • スキーマ分離と同じ • デメリット • スキーマ分離と同じ • テーブルの管理が煩雑 • テナント毎にテーブル名を変更する必要がある • 既存のアプリケーションからの移⾏の場合、ア プリケーションの回収が必要 • 障害発⽣時、全テナントが停⽌ テナント2テーブル テナント1テーブル データベース スキーマ
© 2022, Amazon Web Services, Inc. or its Affiliates. All rights reserved. プールモデル • 概要 • 全てのテナントデータを１つのスキーマで共有 • テナントデータへのアクセスを制御するためのIDで管理 • CPU、メモリ、ディスクは他のテナントと共有 • メリット • テーブル構成変更や機能拡張などのメンテナンスが容易 • 複数データベース、スキーマによるデータの冗⻑性が削減 • 新規のテナント作成はテナントのID作成 • テナントごとのポリシー管理が不要 • CPU、メモリ、ディスクの監視と管理がシンプル • サイロモデルと⽐べてコスト削減 • デメリット • 既存アプリケーションの改修が必要 • 別テナントの情報が表⽰されてしまうリスク • ノイジーネイバーによるパフォーマンスの影響 • 障害発⽣時、全テナントが停⽌ Tenant 1 84049-49 True Tenant 2 82-84-949 False Tenant 1 Bob Smith Tenant 2 Lisa Johnson テナントIDによる⾏の特定
© 2022, Amazon Web Services, Inc. or its Affiliates. All rights reserved. ハイブリッドモデル • 概要 • プールモデルがベース • サイロモデルを必要とするテナント⽤に 別データベースを作成 • データアクセスレイヤーによって抽象化 • メリット • 可⽤性要件やセキュリティ要件、性能要 件など、顧客の要件に合わせて選択可能 • デメリット • 既存アプリケーションの改修が必要 • アプリケーションが複雑化しやすい Data Access Layer ���ナント3 テナント4 テナント1 データベース テナント2 データベース Tenant 3 84049-49 True Tenant 4 82-84-949 False Tenant 3 Bob Smith Tenant 4 Lisa Johnson テナントIDによる⾏の特定
© 2022, Amazon Web Services, Inc. or its Affiliates. All rights reserved. SaaSパーティショニングモデルの選択 ハイブリッドモデル プールモデル 運⽤/メンテナンス ⼯数やコスト削減 を重視 はい いいえ はい いいえ アプリケーション の改修可能 サイロモデル はい はい はい ブリッジモデル 特定顧客向けに データベースの 分割が必要 いいえ 特定顧客向けに データベースの 分割が必要 はい いいえ
© 2022, Amazon Web Services, Inc. or its Affiliates. All rights reserved. データベースエンジン毎の 構成イメージ
© 2022, Amazon Web Services, Inc. or its Affiliates. All rights reserved. Oracleの場合 ブリッジモデル プールモデル データベース サイロモデル CDB PDB ユーザー データベース CDB PDB ユーザー1 ユーザー2 データベース CDB PDB ユーザー データベース CDB PDB ユーザー
© 2022, Amazon Web Services, Inc. or its Affiliates. All rights reserved. Oracle(EE+Multitenant)の場合 CDB PDB ユーザー データベース CDB PDB1 ユーザー PDB2 ユーザー CDB PDB ユーザー データベース CDB PDB ユーザー ブリッジモデル プールモデル サイロモデル データベース データベース
© 2022, Amazon Web Services, Inc. or its Affiliates. All rights reserved. マルチテナント化での注意点（Oracle） PDB採⽤のポイント →クエリにユーザー名を指定している場合、アプリケーションの改修が発⽣す る可能性がある →データベース管理者ユーザーをテナント毎に分けたい OracleのMultitenant使⽤時の注意 →OracleのMultitenantを使⽤する場合、Oracle EE+Multitenantオプション が必要 スケールアップ時の注意 →スケールアップでCPU数が増加する場合、追加でライセンス購⼊が必要 （BYOL）
© 2022, Amazon Web Services, Inc. or its Affiliates. All rights reserved. SQL Server/PostgreSQLの場合 データベース スキーマ インスタンス データベース スキーマ1 データベース スキーマ インスタンス データベース スキーマ スキーマ2 ブリッジモデル プールモデル サイロモデル インスタンス インスタンス
© 2022, Amazon Web Services, Inc. or its Affiliates. All rights reserved. SQL Server/PostgreSQLの場合（データベース分離） データベース スキーマ インスタンス データベース1 スキーマ データベース スキーマ インスタンス データベース スキーマ データベース2 スキーマ ブリッジモデル プールモデル サイロモデル インスタンス インスタンス
© 2022, Amazon Web Services, Inc. or its Affiliates. All rights reserved. マルチテナント化での注意点（SQL Server/PostgreSQL） データベース分離採⽤のポイント →クエリにスキーマ名が指定されている場合、スキーマ分離だとアプリケー ションの改修が発⽣する可能性がある →バックアップをテナント単位で取得したい場合、データベース毎に分離
© 2022, Amazon Web Services, Inc. or its Affiliates. All rights reserved. MySQLの場合 データベース インスタンス データベース1 データベース インスタンス データベース データベース2 ブリッジモデル プールモデル サイロモデル インスタンス インスタンス
© 2022, Amazon Web Services, Inc. or its Affiliates. All rights reserved. マルチテナント化に向けた考慮点
© 2022, Amazon Web Services, Inc. or its Affiliates. All rights reserved. マルチテナント化に向けた考慮点 • マルチテナント（プールモデル）採⽤に向けて必要な考慮点 • セキュリティ • パフォーマンス向上 • 運⽤管理
© 2022, Amazon Web Services, Inc. or its Affiliates. All rights reserved. セキュリティ
© 2022, Amazon Web Services, Inc. or its Affiliates. All rights reserved. セキュリティ • RDSにおけるデータベースセキュリティ • VPC対応 • アクセス制御 • 暗号化 • マルチテナントにおけるセキュリティ
© 2022, Amazon Web Services, Inc. or its Affiliates. All rights reserved. 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
© 2022, Amazon Web Services, Inc. or its Affiliates. All rights reserved. アクセス制御 デフォルトではDBインスタンスに対する ネットワークアクセスはオフになっている セキュリティグループによりアクセスを制御 IPアドレス範囲もしくはセキュリティグループを ソースとして、アクセスを許可するポートを指定 • 例）RDS MySQLのTCPポート3306へのアクセスを許可 https://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/UserGuide/Overview.RDSSecurityGroups.html security group security group
© 2022, Amazon Web Services, Inc. or its Affiliates. All rights reserved. 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
© 2022, Amazon Web Services, Inc. or its Affiliates. All rights reserved. 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) をサポート
© 2022, Amazon Web Services, Inc. or its Affiliates. All rights reserved. インスタンス データベース スキーマ マルチテナントにおけるセキュリティの課題(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 ユーザー SELECT user_id,username FROM users WHERE tenant_id = ʻtenant3ʼ; • 該当のテナントIDを必ず指定する必要がある テナント1 ユーザー user_id username 1 Suzuki 2 Sato SELECT user_id,username FROM users WHERE tenant_id = ʻtenant1ʼ;
© 2022, Amazon Web Services, Inc. or its Affiliates. All rights reserved. インスタンス データベース スキーマ マルチテナントにおけるセキュリティの課題(2/2) テナント2 ユーザー tenant_id user_id username tenant1 1 Suzuki tenant1 2 Sato tenant2 1 Nakamura tenant2 2 Takahashi tenant3 1 Yamada テナント3 ユーザー SELECT user_id,username FROM users; • 誤ったテナントIDの指定やテナントIDが指定されない場合の影響が甚⼤ user_id username 1 Suzuki 2 Sato user_id username 1 Suzuki 2 Sato 1 Nakamura 2 Takahashi 1 Yamada SELECT user_id,username FROM users WHERE tenant_id = ʻtenant1ʼ; テナント1 ユーザー user_id username 1 Suzuki 2 Sato SELECT user_id,username FROM users WHERE tenant_id = ʻtenant1ʼ;
© 2022, Amazon Web Services, Inc. or its Affiliates. All rights reserved. インスタンス データベース スキーマ Row Level Security(RLS)による制御 テナント1 ユーザー テナント2 ユーザー tenant_id user_id username tenant1 1 Suzuki tenant1 2 Sato tenant2 1 Nakamura tenant2 2 Takahashi tenant3 1 Yamada テナント3 ユーザー SELECT user_id,username FROM users; • Row Level Securityを使⽤して、該当のテナントIDのみの結果を取得 • アプリケーションの改修コストやテスト⼯数の削減 user_id username user_id username 1 Yamada user_id username 1 Suzuki 2 Sato SELECT user_id,username FROM users WHERE tenant_id = ʻtenant1ʼ; SELECT user_id,username FROM users WHERE tenant_id = ʻtenant1ʼ; ※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 -- tenant2でログイン mydb=> select user_id,username from users where tenant_id = ‘tenant1’; user_id | username ---------+----------- -- tenant3でログイン mydb=> select user_id,username from users; user_id | username ---------+---------- 1 | Yamada Select実⾏ Amazon Aurora PostgreSQLのRLS
© 2022, Amazon Web Services, Inc. or its Affiliates. All rights reserved. パフォーマンス向上
© 2022, Amazon Web Services, Inc. or its Affiliates. All rights reserved. パフォーマンス向上 • RDSにおけるパフォーマンス向上 • インスタンスタイプ変更によるスケールアップ/ダウン • Read Replicaによるスケールアウト/イン • マルチテナント におけるRead Replica
© 2022, Amazon Web Services, Inc. or its Affiliates. All rights reserved. スケールアップ • マネージメントコンソールや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 スケールアップ
© 2022, Amazon Web Services, Inc. or its Affiliates. All rights reserved. RDSのリードレプリカ（RR） 同期レプリケーション ⾃動フェイルオーバー S3 Availability Zone A Availability Zone B スナップ ショット (⾃動/⼿動) Binlog (トランザクションログ) 5分に1回保存 バックアップ ⾮同期レプリケーション Binlog リードレプリカ
© 2022, Amazon Web Services, Inc. or its Affiliates. All rights reserved. リードレプリカ（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のみ使⽤可能です。
© 2022, Amazon Web Services, Inc. or its Affiliates. All rights reserved. • 処理によって接続先を変更 マルチテナントにおける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台
© 2022, Amazon Web Services, Inc. or its Affiliates. All rights reserved. • 読み取りエンドポイントに接続 • Read Replicaへの接続はラウンドロビン • 最⼤15台まで追加可能 Amazon Aurora のRead Replica テナント1 ユーザー テナント2 ユーザー テナント11 ユーザー テナント21 ユーザー 読み取り エンドポイント リアルタイムではない参照処理
© 2022, Amazon Web Services, Inc. or its Affiliates. All rights reserved. 運⽤管理
© 2022, Amazon Web Services, Inc. or its Affiliates. All rights reserved. 運⽤管理 • RDSにおける運⽤管理 • CloudWatch • 拡張モニタリング（RDS） • Performance Insights（RDS） • Query Plan Management • マルチテナントにおける運⽤管理
© 2022, Amazon Web Services, Inc. or its Affiliates. All rights reserved. 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
© 2022, Amazon Web Services, Inc. or its Affiliates. All rights reserved. 拡張モニタリング • 50種類以上のOSメトリクス • プロセス⼀覧 • 1秒〜60秒間隔で取得 • 特定メトリクスのアラーム • CloudWatch Logsへの出⼒ • 3rd party ツール連携 https://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/UserGuide/USER_Monitoring.OS.html
© 2022, Amazon Web Services, Inc. or its Affiliates. All rights reserved. 拡張モニタリング（OSメトリクス）
© 2022, Amazon Web Services, Inc. or its Affiliates. All rights reserved. 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 - ホスト - ユーザー
© 2022, Amazon Web Services, Inc. or its Affiliates. All rights reserved. Performance Insights ダッシュボード Database Loadチャート Top N Dimensionテーブル
© 2022, Amazon Web Services, Inc. or its Affiliates. All rights reserved. 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)
© 2022, Amazon Web Services, Inc. or its Affiliates. All rights reserved. マルチテナントにおける運⽤管理の課題 パフォーマンス問題発⽣時にOSリソースだけだと原因特定が困難 どのテナントで負荷が ⾼いかわからない
© 2022, Amazon Web Services, Inc. or its Affiliates. All rights reserved. Performance Insightsによる可視化 Performance Insights テナント毎（接続 ユーザー毎）の 状態を確認可能
© 2022, Amazon Web Services, Inc. or its Affiliates. All rights reserved. 該当テナントのSQL特定 該当テナントで実⾏ されているSQLの ⼀覧 →SQLチューニング検討 • 負荷の⾼いテナントを選択し、実⾏されているSQLを特定
© 2022, Amazon Web Services, Inc. or its Affiliates. All rights reserved. まとめ
© 2022, Amazon Web Services, Inc. or its Affiliates. All rights reserved. まとめ • SaaSパーティショニングモデル毎のメリットデメリットの把握 • 要件に合わせてモデルを選択 • マルチテナント化が必要な場合、考慮すべきポイントを抑えておく
© 2022, Amazon Web Services, Inc. or its Affiliates. All rights reserved. Thank you!

More Related Content

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

  • 1. © 2022, Amazon Web Services, Inc. or its Affiliates. All rights reserved. アマゾンウェブサービスジャパン合同会社 2022/01/07 内⼭ 義夫 マルチテナント化で知っておき たいデータベースのこと
  • 2. © 2022, Amazon Web Services, Inc. or its Affiliates. All rights reserved. アジェンダ • データベースにおけるSaaSパーティショニングモデル • データベースエンジン毎の構成イメージ • マルチテナント化に向けた考慮点 • まとめ
  • 3. © 2022, Amazon Web Services, Inc. or its Affiliates. All rights reserved. データベースにおける SaaSパーティショニングモデル
  • 4. © 2022, Amazon Web Services, Inc. or its Affiliates. All rights reserved. クラウドにおける SaaS 化のフェーズ フェーズ0. クラウドリフト クラウド上でのサーバ稼働 フェーズ1. シングルテナント移⾏ サイロ化モデル フェーズ2. ⼀部マルチテナント移⾏ データ層共通化 フェーズ3. 完全マルチテナント移⾏ アプリ/データ層共通化 フェーズ4. クラウド最適化 コンテナ化・サーバレス化 運⽤コスト減
  • 5. © 2022, Amazon Web Services, Inc. or its Affiliates. All rights reserved. クラウドにおける SaaS 化のフェーズ フェーズ0. クラウドリフト クラウド上でのサーバ稼働 フェーズ1. シングルテナント移⾏ サイロ化モデル フェーズ2. ⼀部マルチテナント移⾏ データ層共通化 フェーズ3. 完全マルチテナント移⾏ アプリ/データ層共通化 フェーズ4. クラウド最適化 コンテナ化・サーバレス化 テナント分離
  • 6. © 2022, Amazon Web Services, Inc. or its Affiliates. All rights reserved. テナント分離の考え⽅ サイロモデル分離 Service Service Service Service Service Service Service Service Service Service Service Service Service Service プールモデル分離 シングルテナント例 マルチテナント例 テナント1 テナント2 テナント1 テナント2 テナント3
  • 7. © 2022, Amazon Web Services, Inc. or its Affiliates. All rights reserved. データベースにおける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 スキーマ データベース
  • 8. © 2022, Amazon Web Services, Inc. or its Affiliates. All rights reserved. • メリット • コンプライアンス適⽤ • 環境分離 • テナント間影響 • テナント固有チューニング • テナントレベル可⽤性 • デメリット • コスト⾼ • アジリティ • 管理複雑化 • デプロイ • 分析測定収集 SaaSパーティショニングモデルのメリット・デメリット • メリット • アジリティ • コスト最適化 • 集中管理 • 適⽤簡素化 • 分析測定収集 • デメリット • テナント間影響 • コンプライアンス • オール・オア・ナッシング可 ⽤性 サイロモデル プールモデル ブリッジモデル
  • 9. © 2022, Amazon Web Services, Inc. or its Affiliates. All rights reserved. サイロモデル • 概要 • １つのデータベース上に１つのテナントデータを作 成 • 同⼀構成のデータベースが複数存在 • OSリソースはCPU、メモリ、ディスクが他のテナン トから分離 • メリット • あるテナントのアクティビティが他のテナントに影 響を与えない • テナント固有にスケールアップ等のチューニングが 可能 • 可⽤性をテナントレベルで管理可能 • データベース障害時の影響を極⼩化 • 既存構成からの移⾏が容易 • デメリット • テナント数が多い場合、メンテナンス効率が悪い • コストが⾼くなる傾向 テナント1 データベース テナント2 データベース
  • 10. © 2022, Amazon Web Services, Inc. or its Affiliates. All rights reserved. ブリッジモデル（スキーマ分離） • 概要 • １つのデータベース上にテナント毎のスキーマを作成 • 同⼀構成のスキーマが複数存在 • CPU、メモリ、ディスクは他のテナントと共有 • メリット • サイロモデルと⽐較して新規のテナント作成が容易 • CPU、メモリ、ディスクの監視と管理がシンプル • 既存のシングルテナント・ソリューションの移⾏が⽐較 的容易 • サイロモデルと⽐べてコスト削減 • デメリット • テナント数に⽐例してテーブル数も増加（テナントの増 加に⽐例してテーブルのオープン数も増加する為、 キャッシュ上限に達してパフォーマンスが極端に劣化す るケースがある） • ノイジーネイバーによるパフォーマンスの影響 • 障害発⽣時、全テナントが停⽌ テナント1 スキーマ テナント2 スキーマ データベース
  • 11. © 2022, Amazon Web Services, Inc. or its Affiliates. All rights reserved. ブリッジモデル（テーブル分離） • 概要 • １つのデータベース上に１つのスキーマを作成 • テーブルをテナント毎に作成 • CPU、メモリ、ディスクは他のテナントと共有 • メリット • スキーマ分離と同じ • デメリット • スキーマ分離と同じ • テーブルの管理が煩雑 • テナント毎にテーブル名を変更する必要がある • 既存のアプリケーションからの移⾏の場合、ア プリケーションの回収が必要 • 障害発⽣時、全テナントが停⽌ テナント2テーブル テナント1テーブル データベース スキーマ
  • 12. © 2022, Amazon Web Services, Inc. or its Affiliates. All rights reserved. プールモデル • 概要 • 全てのテナントデータを１つのスキーマで共有 • テナントデータへのアクセスを制御するためのIDで管理 • CPU、メモリ、ディスクは他のテナントと共有 • メリット • テーブル構成変更や機能拡張などのメンテナンスが容易 • 複数データベース、スキーマによるデータの冗⻑性が削減 • 新規のテナント作成はテナントのID作成 • テナントごとのポリシー管理が不要 • CPU、メモリ、ディスクの監視と管理がシンプル • サイロモデルと⽐べてコスト削減 • デメリット • 既存アプリケーションの改修が必要 • 別テナントの情報が表⽰されてしまうリスク • ノイジーネイバーによるパフォーマンスの影響 • 障害発⽣時、全テナントが停⽌ Tenant 1 84049-49 True Tenant 2 82-84-949 False Tenant 1 Bob Smith Tenant 2 Lisa Johnson テナントIDによる⾏の特定
  • 13. © 2022, Amazon Web Services, Inc. or its Affiliates. All rights reserved. ハイブリッドモデル • 概要 • プールモデルがベース • サイロモデルを必要とするテナント⽤に 別データベースを作成 • データアクセスレイヤーによって抽象化 • メリット • 可⽤性要件やセキュリティ要件、性能要 件など、顧客の要件に合わせて選択可能 • デメリット • 既存アプリケーションの改修が必要 • アプリケーションが複雑化しやすい Data Access Layer テナント3 テナント4 テナント1 データベース テナント2 データベース Tenant 3 84049-49 True Tenant 4 82-84-949 False Tenant 3 Bob Smith Tenant 4 Lisa Johnson テナントIDによる⾏の特定
  • 14. © 2022, Amazon Web Services, Inc. or its Affiliates. All rights reserved. SaaSパーティショニングモデルの選択 ハイブリッドモデル プールモデル 運⽤/メンテナンス ⼯数やコスト削減 を重視 はい いいえ はい いいえ アプリケーション の改修可能 サイロモデル はい はい はい ブリッジモデル 特定顧客向けに データベースの 分割が必要 いいえ 特定顧客向けに データベースの 分割が必要 はい いいえ
  • 15. © 2022, Amazon Web Services, Inc. or its Affiliates. All rights reserved. データベースエンジン毎の 構成イメージ
  • 16. © 2022, Amazon Web Services, Inc. or its Affiliates. All rights reserved. Oracleの場合 ブリッジモデル プールモデル データベース サイロモデル CDB PDB ユーザー データベース CDB PDB ユーザー1 ユーザー2 データベース CDB PDB ユーザー データベース CDB PDB ユーザー
  • 17. © 2022, Amazon Web Services, Inc. or its Affiliates. All rights reserved. Oracle(EE+Multitenant)の場合 CDB PDB ユーザー データベース CDB PDB1 ユーザー PDB2 ユーザー CDB PDB ユーザー データベース CDB PDB ユーザー ブリッジモデル プールモデル サイロモデル データベース データベース
  • 18. © 2022, Amazon Web Services, Inc. or its Affiliates. All rights reserved. マルチテナント化での注意点（Oracle） PDB採⽤のポイント →クエリにユーザー名を指定している場合、アプリケーションの改修が発⽣す る可能性がある →データベース管理者ユーザーをテナント毎に分けたい OracleのMultitenant使⽤時の注意 →OracleのMultitenantを使⽤する場合、Oracle EE+Multitenantオプション が必要 スケールアップ時の注意 →スケールアップでCPU数が増加する場合、追加でライセンス購⼊が必要 （BYOL）
  • 19. © 2022, Amazon Web Services, Inc. or its Affiliates. All rights reserved. SQL Server/PostgreSQLの場合 データベース スキーマ インスタンス データベース スキーマ1 データベース スキーマ インスタンス データベース スキーマ スキーマ2 ブリッジモデル プールモデル サイロモデル インスタンス インスタンス
  • 20. © 2022, Amazon Web Services, Inc. or its Affiliates. All rights reserved. SQL Server/PostgreSQLの場合（データベース分離） データベース スキーマ インスタンス データベース1 スキーマ データベース スキーマ インスタンス データベース スキーマ データベース2 スキーマ ブリッジモデル プールモデル サイロモデル インスタンス インスタンス
  • 21. © 2022, Amazon Web Services, Inc. or its Affiliates. All rights reserved. マルチテナント化での注意点（SQL Server/PostgreSQL） データベース分離採⽤のポイント →クエリにスキーマ名が指定されている場合、スキーマ分離だとアプリケー ションの改修が発⽣する可能性がある →バックアップをテナント単位で取得したい場合、データベース毎に分離
  • 22. © 2022, Amazon Web Services, Inc. or its Affiliates. All rights reserved. MySQLの場合 データベース インスタンス データベース1 データベース インスタンス データベース データベース2 ブリッジモデル プールモデル サイロモデル インスタンス インスタンス
  • 23. © 2022, Amazon Web Services, Inc. or its Affiliates. All rights reserved. マルチテナント化に向けた考慮点
  • 24. © 2022, Amazon Web Services, Inc. or its Affiliates. All rights reserved. マルチテナント化に向けた考慮点 • マルチテナント（プールモデル）採⽤に向けて必要な考慮点 • セキュリティ • パフォーマンス向上 • 運⽤管理
  • 25. © 2022, Amazon Web Services, Inc. or its Affiliates. All rights reserved. セキュリティ
  • 26. © 2022, Amazon Web Services, Inc. or its Affiliates. All rights reserved. セキュリティ • RDSにおけるデータベースセキュリティ • VPC対応 • アクセス制御 • 暗号化 • マルチテナントにおけるセキュリティ
  • 27. © 2022, Amazon Web Services, Inc. or its Affiliates. All rights reserved. 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
  • 28. © 2022, Amazon Web Services, Inc. or its Affiliates. All rights reserved. アクセス制御 デフォルトではDBインスタンスに対する ネットワークアクセスはオフになっている セキュリティグループによりアクセスを制御 IPアドレス範囲もしくはセキュリティグループを ソースとして、アクセスを許可するポートを指定 • 例）RDS MySQLのTCPポート3306へのアクセスを許可 https://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/UserGuide/Overview.RDSSecurityGroups.html security group security group
  • 29. © 2022, Amazon Web Services, Inc. or its Affiliates. All rights reserved. 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
  • 30. © 2022, Amazon Web Services, Inc. or its Affiliates. All rights reserved. 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) をサポート
  • 31. © 2022, Amazon Web Services, Inc. or its Affiliates. All rights reserved. インスタンス データベース スキーマ マルチテナントにおけるセキュリティの課題(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 ユーザー SELECT user_id,username FROM users WHERE tenant_id = ʻtenant3ʼ; • 該当のテナントIDを必ず指定する必要がある テナント1 ユーザー user_id username 1 Suzuki 2 Sato SELECT user_id,username FROM users WHERE tenant_id = ʻtenant1ʼ;
  • 32. © 2022, Amazon Web Services, Inc. or its Affiliates. All rights reserved. インスタンス データベース スキーマ マルチテナントにおけるセキュリティの課題(2/2) テナント2 ユーザー tenant_id user_id username tenant1 1 Suzuki tenant1 2 Sato tenant2 1 Nakamura tenant2 2 Takahashi tenant3 1 Yamada テナント3 ユーザー SELECT user_id,username FROM users; • 誤ったテナントIDの指定やテナントIDが指定されない場合の影響が甚⼤ user_id username 1 Suzuki 2 Sato user_id username 1 Suzuki 2 Sato 1 Nakamura 2 Takahashi 1 Yamada SELECT user_id,username FROM users WHERE tenant_id = ʻtenant1ʼ; テナント1 ユーザー user_id username 1 Suzuki 2 Sato SELECT user_id,username FROM users WHERE tenant_id = ʻtenant1ʼ;
  • 33. © 2022, Amazon Web Services, Inc. or its Affiliates. All rights reserved. インスタンス データベース スキーマ Row Level Security(RLS)による制御 テナント1 ユーザー テナント2 ユーザー tenant_id user_id username tenant1 1 Suzuki tenant1 2 Sato tenant2 1 Nakamura tenant2 2 Takahashi tenant3 1 Yamada テナント3 ユーザー SELECT user_id,username FROM users; • Row Level Securityを使⽤して、該当のテナントIDのみの結果を取得 • アプリケーションの改修コストやテスト⼯数の削減 user_id username user_id username 1 Yamada user_id username 1 Suzuki 2 Sato SELECT user_id,username FROM users WHERE tenant_id = ʻtenant1ʼ; SELECT user_id,username FROM users WHERE tenant_id = ʻtenant1ʼ; ※PostgreSQL 9.5以降 Oracle RAS（EEのみ） SQL Server 2016(13.x)以降
  • 34. 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 -- tenant2でログイン mydb=> select user_id,username from users where tenant_id = ‘tenant1’; user_id | username ---------+----------- -- tenant3でログイン mydb=> select user_id,username from users; user_id | username ---------+---------- 1 | Yamada Select実⾏ Amazon Aurora PostgreSQLのRLS
  • 35. © 2022, Amazon Web Services, Inc. or its Affiliates. All rights reserved. パフォーマンス向上
  • 36. © 2022, Amazon Web Services, Inc. or its Affiliates. All rights reserved. パフォーマンス向上 • RDSにおけるパフォーマンス向上 • インスタンスタイプ変更によるスケールアップ/ダウン • Read Replicaによるスケールアウト/イン • マルチテナント におけるRead Replica
  • 37. © 2022, Amazon Web Services, Inc. or its Affiliates. All rights reserved. スケールアップ • マネージメントコンソールや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 スケールアップ
  • 38. © 2022, Amazon Web Services, Inc. or its Affiliates. All rights reserved. RDSのリードレプリカ（RR） 同期レプリケーション ⾃動フェイルオーバー S3 Availability Zone A Availability Zone B スナップ ショット (⾃動/⼿動) Binlog (トランザクションログ) 5分に1回保存 バックアップ ⾮同期レプリケーション Binlog リードレプリカ
  • 39. © 2022, Amazon Web Services, Inc. or its Affiliates. All rights reserved. リードレプリカ（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のみ使⽤可能です。
  • 40. © 2022, Amazon Web Services, Inc. or its Affiliates. All rights reserved. • 処理���よって接続先を変更 マルチテナントにおける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台
  • 41. © 2022, Amazon Web Services, Inc. or its Affiliates. All rights reserved. • 読み取りエンドポイントに接続 • Read Replicaへの接続はラウンドロビン • 最⼤15台まで追加可能 Amazon Aurora のRead Replica テナント1 ユーザー テナント2 ユーザー テナント11 ユーザー テナント21 ユーザー 読み取り エンドポイント リアルタイムではない参照処理
  • 42. © 2022, Amazon Web Services, Inc. or its Affiliates. All rights reserved. 運⽤管理
  • 43. © 2022, Amazon Web Services, Inc. or its Affiliates. All rights reserved. 運⽤管理 • RDSにおける運⽤管理 • CloudWatch • 拡張モニタリング（RDS） • Performance Insights（RDS） • Query Plan Management • マルチテナントにおける運⽤管理
  • 44. © 2022, Amazon Web Services, Inc. or its Affiliates. All rights reserved. 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
  • 45. © 2022, Amazon Web Services, Inc. or its Affiliates. All rights reserved. 拡張モニタリング • 50種類以上のOSメトリクス • プロセス⼀覧 • 1秒〜60秒間隔で取得 • 特定メトリクスのアラーム • CloudWatch Logsへの出⼒ • 3rd party ツール連携 https://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/UserGuide/USER_Monitoring.OS.html
  • 46. © 2022, Amazon Web Services, Inc. or its Affiliates. All rights reserved. 拡張モニタリング（OSメトリクス）
  • 47. © 2022, Amazon Web Services, Inc. or its Affiliates. All rights reserved. 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 - ホスト - ユーザー
  • 48. © 2022, Amazon Web Services, Inc. or its Affiliates. All rights reserved. Performance Insights ダッシュボード Database Loadチャート Top N Dimensionテーブル
  • 49. © 2022, Amazon Web Services, Inc. or its Affiliates. All rights reserved. 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)
  • 50. © 2022, Amazon Web Services, Inc. or its Affiliates. All rights reserved. マルチテナントにおける運⽤管理の課題 パフォーマンス問題発⽣時にOSリソースだけだと原因特定が困難 どのテナントで負荷が ⾼いかわからない
  • 51. © 2022, Amazon Web Services, Inc. or its Affiliates. All rights reserved. Performance Insightsによる可視化 Performance Insights テナント毎（接続 ユーザー毎）の 状態を確認可能
  • 52. © 2022, Amazon Web Services, Inc. or its Affiliates. All rights reserved. 該当テナントのSQL特定 該当テナントで実⾏ されているSQLの ⼀覧 →SQLチューニング検討 • 負荷の⾼いテナントを選択し、実⾏されているSQLを特定
  • 53. © 2022, Amazon Web Services, Inc. or its Affiliates. All rights reserved. まとめ
  • 54. © 2022, Amazon Web Services, Inc. or its Affiliates. All rights reserved. まとめ • SaaSパーティショニングモデル毎のメリットデメリットの把握 • 要件に合わせてモデルを選択 • マルチテナント化が必要な場合、考慮すべきポイントを抑えておく
  • 55. © 2022, Amazon Web Services, Inc. or its Affiliates. All rights reserved. Thank you!