Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

db tech showcase 2019 SQL Database Hyperscale 徹底分析 - 最新アーキテクチャの特徴を理解する

234 views

Published on

SQL DB Hyperscale のアーキテクチャ概要

Published in: Data & Analytics
  • Be the first to comment

  • Be the first to like this

db tech showcase 2019 SQL Database Hyperscale 徹底分析 - 最新アーキテクチャの特徴を理解する

  1. 1. SQL Database Hyperscale徹底分析 最新アーキテクチャの特徴を理解する 小澤 真之 (@Masayuki_Ozawa) Microsoft MVP for Data Platform
  2. 2. 資料の入手先等  資料の入手先等はブログで公開する予定です  Azure の Data Platform を学習したいと思った方は、Microsoft Learn を活用!!  本スライドのリンク先から、ブログ / Microsoft Learn にアクセスできます 2 https://aka.ms/AA5zk55
  3. 3. 本セッションのゴール : 構成を把握し、情報を理解する 3 ポータルのデプロイ画面 Azure SQL ハイパースケール データベースに関する FAQ
  4. 4. SQL Database Hyperscale の特徴
  5. 5. 従来の SQL Database の構成  モノリシック構成  コンピューティングリソースとデータベースを内包した環境で構成  リモートストレージ (Azure Storage) を使用したデータベースの冗長構成 (Basic, Standard / General Purpose)  AlwaysOn 可用性グループをベースとした HADR 構成 (Premium / Business Critical)  読み取りセカンダリを作成した場合、セカンダリサーバー単位で DB のコピーが必要となる  非共有ストレージ型の構成  データ同期のためプライマリとセカンダリが密結合 (プライマリがセカンダリを認識) 5 SQL Server データベース データファイル ログファイル SQL Server データベース データファイル ログファイル
  6. 6. 従来の構成の課題 6 • Single Database モデルでは DB サイズは 1TB / 4TB が上限 DB のサイズに依存する処理 • 新規セカンダリサーバーの追加 • データ同期対象の追加をプライマリが認識する必要がある • スケールアップ / スケールダウン • 変更するサイズによっては、データベースをコピーした新しいレプリカを作成 • バックアップ / リストア • DB サイズの増加に伴うバックアップ / リストア時間の増加 • バックアップ中は SQL Server のコンピューティングリソースが使用される • モノリシック構成は、構成の一部に最新ハードウェアを適用することが難しい
  7. 7. SQL Database Hyperscale 7 • 最大で 100TB をサポート (MS Inspire では 200TB のデモも実施) DB のサイズに依存しない処理 • 共有ストレージ型により、セカンダリのデータベースコピーの必要性を改善 • セカンダリ追加時にプライマリがデータ同期対象を認識する必要がない • DB サイズに依存しないセカンダリレプリカ追加 / スケールアップ / スケールダウン • ストレージのスナップショット機能によるバックアップ/リストアの高速化 • バックアップ処理の効率化 / 高速化と処理負荷をストレージにオフロード • データベースの各機能を分散させたことで柔軟な拡張が可能 • コンピューティング / データ / ログの各処理を実行する環境をコンポーネント化
  8. 8. SQL Database Hyperscale を理解するために  Socrates: The New SQL Server in the Cloud  https://www.microsoft.com/en-us/research/publication/socrates-the-new-sql-server- in-the-cloud/  SQL Bits 2018 : Hyperscale for Azure SQL DB  https://sqlbits.com/Sessions/Event18/Hyperscale_for_Azure_SQL_DB  Introducing Azure SQL Database Hyperscale  https://msdn.microsoft.com/ja-jp/magazine/mt848637  New performance and scale enhancements for Azure SQL Database  https://myignite.techcommunity.microsoft.com/sessions/65798  Develop data application on a no-limits SQL data platform  https://mybuild.techcommunity.microsoft.com/sessions/76991?source=sessions  PASS Summit 2018 Day2 KEYNOTE  https://passstuff.com/collections/pass-summit-2018-session-recordings 8
  9. 9. Hyperscale Components 9 • Stateless, Local SSD Cache (RBPEX : コア数に応じたサイズ、Non Covering) • 階層化キャッシュ, Local SSD Cache • Stateless, Local SSD Cache (RBPEX : コンテンツ (データ) を完全にカバー) SQL Bits 2018 : Hyperscale for Azure SQL DB の内容を元に記載 https://sqlbits.com/Sessions/Event18/Hyperscale_for_Azure_SQL_DB • 高い信頼性を実現する Azure Storage • 二つの Azure Storage を用途に応じて使い分け • XStore : Azure Standard Storage : 安価で大容量なストレージ • XIO : Azure Premium Storage : 高性能だが高価なストレージ
  10. 10. SQL Database Hyperscale Overview 10 Local SSD RBPEX (Non Covering) Local SSD RBPEX (Non Covering) Local SSD RBPEX (Non Covering) Page Server Local SSD RBPEX (Covering) Page Server Local SSD RBPEX (Covering) Page Server Local SSD RBPEX (Covering) Landing Zone (Azure Premium Storage) Long term log storage for PITR (Azure Standard Storage) Log Service Local SSD Log Cache 最大 100 TB の Hyperscale サービス レベル https://docs.microsoft.com/ja-jp/azure/sql-database/sql-database-service-tier-
  11. 11. SQL Database Hyperscale の構成 11
  12. 12. Hyperscale Data Flow : Read/Write 12PASS Summit 2018 Day2 Keynote の内容を元に記載 Application Primary SQL Server RBPEX Xlog Service Secondary (Failover Targets) SQL Server RBPEX Application Azure Storage Page Server #1 SQL Server RBPEX Page Server #2 SQL Server RBPEX Page Server #N SQL Server RBPEX Azure Storage
  13. 13. Compute Node (Query Engine)  クエリエンジン ≒ Compute Node  Local SSD を使用した RBPEX の活用  Page Server のアクセスを抑えるため、 メモリ + ローカル SSD を Buffer Pool として活用  Compute の RBPEX はDB のすべてのデータはカバーできない  RBPEX のサイズは CPU コア数に応じて変化  初回データアクセス以外はローカルリソースの SSD キャッシュ (RBPEX) が効果的に利用される  ローカルリソースを使用したアクセスの方が高速  Local RBPEX : < 0.5 ms (ローカルアクセス)  Page Server : < 2 ms (リモートアクセス)  プライマリ/セカンダリで同一の Page Server を参照  共有ストレージ型のアーキテクチャを採用  新規セカンダリの追加時に DB のコピーが不要  プライマリとセカンダリは疎結合  プライマリは、セカンダリが何台存在するか把握しない 13 Local SSD RBPEX (Non Covering) Local SSD RBPEX (Non Covering) Local SSD RBPEX (Non Covering) Page Server Local SSD RBPEX (Covering) Page Server Local SSD RBPEX (Covering) Page Server Local SSD RBPEX (Covering)
  14. 14. Page Servers (Data File)  データファイル ≒ Page Server  Standard Storage のアクセスを可能な限り抑止  Standard Storage = 低速だが安価  自サーバーがホストする必要のある Data File をすべてを RBPEX に保持  Page Server の起動時にキャッシュさせる  データファイルの完全なコピーを保持している  冗長化されており、障害発生時も Standard Storage へのアクセ スを抑止できる  格納データの増加に合わせて Page Server を新規に追加  格納されているデータの増加に合わせて Page Server が自動的 に追加される (Compute では、Page Server が追加されると、データファイルが 追加されるように見える)  バックアップ処理を Storage のスナップショットで実現  Compute 層で CPU / IO コストをかけることなく、バックアップ処 理の負荷をストレージにオフロード  スナップショットを使用することで、DB サイズに依存せず、一定時 間でバックアップ/ リストアを可能 14 Page Server Local SSD RBPEX (Covering) Page Server Local SSD RBPEX (Covering) Page Server Local SSD RBPEX (Covering)
  15. 15. Log Service (Log File)  ログファイル ≒ Log Service  最初に Azure Premium Storage に保存 (Landing Zone)  Landing Zone の書き込み < 2.5 ms  今後 Ultra SSD になると < 0.5 ms に改善  トランザクションは、Landing Zone への書き込みが完了する ことで Commit 完了  Landing Zone の書き込み性能が、トランザクション性能に影響を 与える (今後 Ultra SSD による書き込み性能向上を計画)  Secondary/Page Server の適用は非同期で実施される  Single Database と異なる読み取り特性となる  Single Database のビジネスクリティカルの場合は、 AlwaysOn 可用性グループベース  Secondary のログの適用を待って、トランザクションが完了する  HS は非同期連携のため、読み取りのタイムラグが数 ms 発生  キャッシュされていないページのログレコードは反映しない  Hot Data がセカンダリにキャッシュされていない可能性を考慮 15 Landing Zone (Azure Premium Storage) Long term log storage for PITR (Azure Standard Storage) Log Service Local SSD Log Cache
  16. 16. Read IO 16 SQL Bits 2018 : Hyperscale for Azure SQL DB の内容を元に記載 https://sqlbits.com/Sessions/Event18/Hyperscale_for_Azure_SQL_DB Page Request Read Request Data File  ページサーバーインスタンスの 起動時に RBPEX を事前にビルド  起動時に Standard Storage の Data File の すべての内容をローカル SSD にキャッシュ  2 台のページサーバー レプリカが IO レイテンシ を保証  データアクセス性能  ローカル RBPEX : < 0.5 ms  ページサーバーの RBPEX : < 2ms  Compute 上の RBPEX のサイズは vCore 数に 比例  Compute の vCore 数は読み取り性能に影響を与 える要因となる  Hot データで動作する OLTP ワークロードに最 適化 Page Server RBPEX Compute RBPEX
  17. 17. Read IO - サービス階層の比較 17 Develop data application on a no-limits SQL data platform の内容を元に記載 https://mybuild.techcommunity.microsoft.com/sessions/76991?source=sessions Local Disk Remote Storage Local SSD Compute Node Local SSD Page Servers General Purpose Standard Basic Business Critical Premium Local SSD
  18. 18. Resilient Buffer Pool Extension (RBPEX) 18PASS Summit 2018 Day2 Keynote の内容を元に記載 (1) 0x0 (2) 0x2000 (3) 0x4000 (4) 0x8000 (5) 0xa000 (6) 0xc000 … (n) Buffer Pool File Control Block (FCB) Page Key Offset Time Status {5, 1, 0x1} 0x0 0x0 invalid {5, 1, 0x6} 0x2000 0x2f191 valid {5, 1, 0x99} 0x8000 0x25101 valid … … … … (3) (5) (6) (n) master DB {Page 100, Offset 300} {Page 10, Offset 800} {Page 18, Offset 840} {Page 31, Offset 10} {Page 32, Offset 18} {Page 9, Offset 20}
  19. 19. Write IO 19 Primary Compute SQL Bits 2018 : Hyperscale for Azure SQL DB の内容を元に記載 https://sqlbits.com/Sessions/Event18/Hyperscale_for_Azure_SQL_DB Secondar y Compute Landing Zone (Azure Premium Storage) Txcommit Page Server Page Server Page Server Data File Data File Data File  プライマリコンピューターが Landing Zone に ログ書き込み 遅延 : < 2.5 ms  Hyperscale は、Multi Master ではないため、書き込みは Primary からのみ実行される  LZ でログが強化された後に、トランザクションを コミット  強化 : Landing Zone 内で耐久性のあるログブロックと なった状態  Log Service はメモリキャッシュで新しい トランザクションをステージング  バッファキャッシュから Destage され、Long term log storage に送信  セカンダリコンピューターに、 非同期でログを適用  ページサーバーに非同期でログを適用  ページサーバーはチェックポイントでデータを データファイルに書き込み Long term log storage for PITR (Azure Standard Storage) Log Service Memory Cache SSD Cache
  20. 20. 参考) MSR 論文に記載されているログプロセス 20 Socrates: The New SQL Server in the Cloud より引用 https://www.microsoft.com/en-us/research/publication/socrates-the-new-sql-server-in-the-
  21. 21. SQL Server XLOG Service の階層型キャッシュ 21 Azure Premium Storage (Landing Zone) PASS Summit 2018 Day2 Keynote の内容を元に記載 Log Memory Cache Log SSD Cache Azure Premium Storage LOG LOG Log Broker Destage Secondary Computes Page Servers  メモリ / ディスクと同じ場所に、多くの Reader が あり、キャッシュが効果的に動作  キャッシュのサイズには制限があり、パフォーマンス に合わせて調整  XLOG プロセスが ログをローカル SSD Log Cache に移動し、Standard Storage に Destage して長期保存  GetLogBlock のフロー 1. Log Broker はメモリキャッシュを参照 2. SSD Log Cache を参照 3. Azure Premium Storage を参照 4. 最後に Standard Storage を参照
  22. 22. XLOG Service  XLOG は外部ログを管理  「無制限のログ」を抽象化して提供  単一の Producer がログブロックを書き込み  複数のリーダーが、ログブロックを消費  Page Server の読み取りフィルターオプション  DB ログの末尾  Primary Compute の書き込みポイント  トランザクションの永続コミットポイント  固定サイズのマルチブロック領域に分割 (SQL 仮想ログファイル / VLFs)  完全な VLF を長期保存ストレージへ Destage  30 日の保持期間 22PASS Summit 2018 Day2 Keynote の内容を元に記載
  23. 23. Page Servers RBPEX RBPEX RBPEX Log Service Azure Standard Storage Log Service Backup & Restore  バックアップはアプリケーションに影響を与えない  並列コピー (Metadata)  一定時間で PITR  Accelerated Database Recovery(AD) 23 Primary Compute SQL Bits 2018 : Hyperscale for Azure SQL DB の内容を元に記載 https://sqlbits.com/Sessions/Event18/Hyperscale_for_Azure_SQL_DB
  24. 24. 本セッションのゴール : 構成を把握し、情報を理解する 24 ポータルのデプロイ画面 Azure SQL ハイパースケール データベースに関する FAQ

×