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

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

• 1.
  © 2022, AmazonWeb Services, Inc. or its Affiliates. All rights reserved. アマゾンウェブサービスジャパン合同会社 2022/01/07 内⼭ 義夫 マルチテナント化で知っておき たいデータベースのこと
• 2.
  © 2022, AmazonWeb Services, Inc. or its Affiliates. All rights reserved. アジェンダ • データベースにおけるSaaSパーティショニングモデル • データベースエンジン毎の構成イメージ • マルチテナント化に向けた考慮点 • まとめ
• 3.
  © 2022, AmazonWeb Services, Inc. or its Affiliates. All rights reserved. データベースにおける SaaSパーティショニングモデル
• 4.
  © 2022, AmazonWeb Services, Inc. or its Affiliates. All rights reserved. クラウドにおける SaaS 化のフェーズ フェーズ0. クラウドリフト クラウド上でのサーバ稼働 フェーズ1. シングルテナント移⾏ サイロ化モデル フェーズ2. ⼀部マルチテナント移⾏ データ層共通化 フェーズ3. 完全マルチテナント移⾏ アプリ/データ層共通化 フェーズ4. クラウド最適化 コンテナ化・サーバレス化 運⽤コスト減
• 5.
  © 2022, AmazonWeb Services, Inc. or its Affiliates. All rights reserved. クラウドにおける SaaS 化のフェーズ フェーズ0. クラウドリフト クラウド上でのサーバ稼働 フェーズ1. シングルテナント移⾏ サイロ化モデル フェーズ2. ⼀部マルチテナント移⾏ データ層共通化 フェーズ3. 完全マルチテナント移⾏ アプリ/データ層共通化 フェーズ4. クラウド最適化 コンテナ化・サーバレス化 テナント分離
• 6.
  © 2022, AmazonWeb 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, AmazonWeb 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, AmazonWeb Services, Inc. or its Affiliates. All rights reserved. • メリット • コンプライアンス適⽤ • 環境分離 • テナント間影響 • テナント固有チューニング • テナントレベル可⽤性 • デメリット • コスト⾼ • アジリティ • 管理複雑化 • デプロイ • 分析測定収集 SaaSパーティショニングモデルのメリット・デメリット • メリット • アジリティ • コスト最適化 • 集中管理 • 適⽤簡素化 • 分析測定収集 • デメリット • テナント間影響 • コンプライアンス • オール・オア・ナッシング可 ⽤性 サイロモデル プールモデル ブリッジモデル
• 9.
  © 2022, AmazonWeb Services, Inc. or its Affiliates. All rights reserved. サイロモデル • 概要 • １つのデータベース上に１つのテナントデータを作 成 • 同⼀構成のデータベースが複数存在 • OSリソースはCPU、メモリ、ディスクが他のテナン トから分離 • メリット • あるテナントのアクティビティが他のテナントに影 響を与えない • テナント固有にスケールアップ等のチューニングが 可能 • 可⽤性をテナントレベルで管理可能 • データベース障害時の影響を極⼩化 • 既存構成からの移⾏が容易 • デメリット • テナント数が多い場合、メンテナンス効率が悪い • コストが⾼くなる傾向 テナント1 データベース テナント2 データベース
• 10.
  © 2022, AmazonWeb Services, Inc. or its Affiliates. All rights reserved. ブリッジモデル（スキーマ分離） • 概要 • １つのデータベース上にテナント毎のスキーマを作成 • 同⼀構成のスキーマが複数存在 • CPU、メモリ、ディスクは他のテナントと共有 • メリット • サイロモデルと⽐較して新規のテナント作成が容易 • CPU、メモリ、ディスクの監視と管理がシンプル • 既存のシングルテナント・ソリューションの移⾏が⽐較 的容易 • サイロモデルと⽐べてコスト削減 • デメリット • テナント数に⽐例してテーブル数も増加（テナントの増 加に⽐例してテーブルのオープン数も増加する為、 キャッシュ上限に達してパフォーマンスが極端に劣化す るケースがある） • ノイジーネイバーによるパフォーマンスの影響 • 障害発⽣時、全テナントが停⽌ テナント1 スキーマ テナント2 スキーマ データベース
• 11.
  © 2022, AmazonWeb Services, Inc. or its Affiliates. All rights reserved. ブリッジモデル（テーブル分離） • 概要 • １つのデータベース上に１つのスキーマを作成 • テーブルをテナント毎に作成 • CPU、メモリ、ディスクは他のテナントと共有 • メリット • スキーマ分離と同じ • デメリット • スキーマ分離と同じ • テーブルの管理が煩雑 • テナント毎にテーブル名を変更する必要がある • 既存のアプリケーションからの移⾏の場合、ア プリケーションの回収が必要 • 障害発⽣時、全テナントが停⽌ テナント2テーブル テナント1テーブル データベース スキーマ
• 12.
  © 2022, AmazonWeb 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, AmazonWeb 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, AmazonWeb Services, Inc. or its Affiliates. All rights reserved. SaaSパーティショニングモデルの選択 ハイブリッドモデル プールモデル 運⽤/メンテナンス ⼯数やコスト削減 を重視 はい いいえ はい いいえ アプリケーション の改修可能 サイロモデル はい はい はい ブリッジモデル 特定顧客向けに データベースの 分割が必要 いいえ 特定顧客向けに データベースの 分割が必要 はい いいえ
• 15.
  © 2022, AmazonWeb Services, Inc. or its Affiliates. All rights reserved. データベースエンジン毎の 構成イメージ
• 16.
  © 2022, AmazonWeb Services, Inc. or its Affiliates. All rights reserved. Oracleの場合 ブリッジモデル プールモデル データベース サイロモデル CDB PDB ユーザー データベース CDB PDB ユーザー1 ユーザー2 データベース CDB PDB ユーザー データベース CDB PDB ユーザー
• 17.
  © 2022, AmazonWeb Services, Inc. or its Affiliates. All rights reserved. Oracle(EE+Multitenant)の場合 CDB PDB ユーザー データベース CDB PDB1 ユーザー PDB2 ユーザー CDB PDB ユーザー データベース CDB PDB ユーザー ブリッジモデル プールモデル サイロモデル データベース データベース
• 18.
  © 2022, AmazonWeb Services, Inc. or its Affiliates. All rights reserved. マルチテナント化での注意点（Oracle） PDB採⽤のポイント →クエリにユーザー名を指定している場合、アプリケーションの改修が発⽣す る可能性がある →データベース管理者ユーザーをテナント毎に分けたい OracleのMultitenant使⽤時の注意 →OracleのMultitenantを使⽤する場合、Oracle EE+Multitenantオプション が必要 スケールアップ時の注意 →スケールアップでCPU数が増加する場合、追加でライセンス購⼊が必要 （BYOL）
• 19.
  © 2022, AmazonWeb Services, Inc. or its Affiliates. All rights reserved. SQL Server/PostgreSQLの場合 データベース スキーマ インスタンス データベース スキーマ1 データベース スキーマ インスタンス データベース スキーマ スキーマ2 ブリッジモデル プールモデル サイロモデル インスタンス インスタンス
• 20.
  © 2022, AmazonWeb Services, Inc. or its Affiliates. All rights reserved. SQL Server/PostgreSQLの場合（データベース分離） データベース スキーマ インスタンス データベース1 スキーマ データベース スキーマ インスタンス データベース スキーマ データベース2 スキーマ ブリッジモデル プールモデル サイロモデル インスタンス インスタンス
• 21.
  © 2022, AmazonWeb Services, Inc. or its Affiliates. All rights reserved. マルチテナント化での注意点（SQL Server/PostgreSQL） データベース分離採⽤のポイント →クエリにスキーマ名が指定されている場合、スキーマ分離だとアプリケー ションの改修が発⽣する可能性がある →バックアップをテナント単位で取得したい場合、データベース毎に分離
• 22.
  © 2022, AmazonWeb Services, Inc. or its Affiliates. All rights reserved. MySQLの場合 データベース インスタンス データベース1 データベース インスタンス データベース データベース2 ブリッジモデル プールモデル サイロモデル インスタンス インスタンス
• 23.
  © 2022, AmazonWeb Services, Inc. or its Affiliates. All rights reserved. マルチテナント化に向けた考慮点
• 24.
  © 2022, AmazonWeb Services, Inc. or its Affiliates. All rights reserved. マルチテナント化に向けた考慮点 • マルチテナント（プールモデル）採⽤に向けて必要な考慮点 • セキュリティ • パフォーマンス向上 • 運⽤管理
• 25.
  © 2022, AmazonWeb Services, Inc. or its Affiliates. All rights reserved. セキュリティ
• 26.
  © 2022, AmazonWeb Services, Inc. or its Affiliates. All rights reserved. セキュリティ • RDSにおけるデータベースセキュリティ • VPC対応 • アクセス制御 • 暗号化 • マルチテナントにおけるセキュリティ
• 27.
  © 2022, AmazonWeb 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, AmazonWeb 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, AmazonWeb 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, AmazonWeb 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, AmazonWeb 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, AmazonWeb 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, AmazonWeb 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 MM 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, AmazonWeb Services, Inc. or its Affiliates. All rights reserved. パフォーマンス向上
• 36.
  © 2022, AmazonWeb Services, Inc. or its Affiliates. All rights reserved. パフォーマンス向上 • RDSにおけるパフォーマンス向上 • インスタンスタイプ変更によるスケールアップ/ダウン • Read Replicaによるスケールアウト/イン • マルチテナント におけるRead Replica
• 37.
  © 2022, AmazonWeb 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, AmazonWeb Services, Inc. or its Affiliates. All rights reserved. RDSのリードレプリカ（RR） 同期レプリケーション ⾃動フェイルオーバー S3 Availability Zone A Availability Zone B スナップ ショット (⾃動/⼿動) Binlog (トランザクションログ) 5分に1回保存 バックアップ ⾮同期レプリケーション Binlog リードレプリカ
• 39.
  © 2022, AmazonWeb 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, AmazonWeb 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, AmazonWeb Services, Inc. or its Affiliates. All rights reserved. • 読み取りエンドポイントに接続 • Read Replicaへの接続はラウンドロビン • 最⼤15台まで追加可能 Amazon Aurora のRead Replica テナント1 ユーザー テナント2 ユーザー テナント11 ユーザー テナント21 ユーザー 読み取り エンドポイント リアルタイムではない参照処理
• 42.
  © 2022, AmazonWeb Services, Inc. or its Affiliates. All rights reserved. 運⽤管理
• 43.
  © 2022, AmazonWeb Services, Inc. or its Affiliates. All rights reserved. 運⽤管理 • RDSにおける運⽤管理 • CloudWatch • 拡張モニタリング（RDS） • Performance Insights（RDS） • Query Plan Management • マルチテナントにおける運⽤管理
• 44.
  © 2022, AmazonWeb 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, AmazonWeb 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, AmazonWeb Services, Inc. or its Affiliates. All rights reserved. 拡張モニタリング（OSメトリクス）
• 47.
  © 2022, AmazonWeb 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, AmazonWeb Services, Inc. or its Affiliates. All rights reserved. Performance Insights ダッシュボード Database Loadチャート Top N Dimensionテーブル
• 49.
  © 2022, AmazonWeb 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, AmazonWeb Services, Inc. or its Affiliates. All rights reserved. マルチテナントにおける運⽤管理の課題 パフォーマンス問題発⽣時にOSリソースだけだと原因特定が困難 どのテナントで負荷が ⾼いかわからない
• 51.
  © 2022, AmazonWeb Services, Inc. or its Affiliates. All rights reserved. Performance Insightsによる可視化 Performance Insights テナント毎（接続 ユーザー毎）の 状態を確認可能
• 52.
  © 2022, AmazonWeb Services, Inc. or its Affiliates. All rights reserved. 該当テナントのSQL特定 該当テナントで実⾏ されているSQLの ⼀覧 →SQLチューニング検討 • 負荷の⾼いテナントを選択し、実⾏されているSQLを特定
• 53.
  © 2022, AmazonWeb Services, Inc. or its Affiliates. All rights reserved. まとめ
• 54.
  © 2022, AmazonWeb Services, Inc. or its Affiliates. All rights reserved. まとめ • SaaSパーティショニングモデル毎のメリットデメリットの把握 • 要件に合わせてモデルを選択 • マルチテナント化が必要な場合、考慮すべきポイントを抑えておく
• 55.
  © 2022, AmazonWeb Services, Inc. or its Affiliates. All rights reserved. Thank you!