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

1. SQL Database Hyperscale徹底分析
最新アーキテクチャの特徴を理解する
小澤 真之 (@Masayuki_Ozawa)
Microsoft MVP for Data Platform

2. 資料の入手先等
 資料の入手先等はブログで公開する予定です
 Azure の Data Platform を学習したいと思った方は、Microsoft Learn を活用！！
 本スライドのリンク先から、ブログ / Microsoft Learn にアクセスできます
2
https://aka.ms/AA5zk55

3. 本セッションのゴール : 構成を把握し、情報を理解する
3
ポータルのデプロイ画面
Azure SQL ハイパースケール データベースに関する FAQ

4. SQL Database Hyperscale の特徴

5. 従来の SQL Database の構成
 モノリシック構成
 コンピューティングリソースとデータベースを内包した環境で構成
 リモートストレージ (Azure Storage) を使用したデータベースの冗長構成 (Basic, Standard / General Purpose)
 AlwaysOn 可用性グループをベースとした HADR 構成 (Premium / Business Critical)
 読み取りセカンダリを作成した場合、セカンダリサーバー単位で DB のコピーが必要となる
 非共有ストレージ型の構成
 データ同期のためプライマリとセカンダリが密結合 (プライマリがセカンダリを認識)
5
SQL Server
データベース
データファイル
ログファイル
SQL Server
データベース
データファイル
ログファイル

6. 従来の構成の課題
6
• Single Database モデルでは DB サイズは 1TB / 4TB が上限
DB のサイズに依存する処理
• 新規セカンダリサーバーの追加
• データ同期対象の追加をプライマリが認識する必要がある
• スケールアップ / スケールダウン
• 変更するサイズによっては、データベースをコピーした新しいレプリカを作成
• バックアップ / リストア
• DB サイズの増加に伴うバックアップ / リストア時間の増加
• バックアップ中は SQL Server のコンピューティングリソースが使用される
• モノリシック構成は、構成の一部に最新ハードウェアを適用することが難しい

7. SQL Database Hyperscale
7
• 最大で 100TB をサポート (MS Inspire では 200TB のデモも実施)
DB のサイズに依存しない処理
• 共有ストレージ型により、セカンダリのデータベースコピーの必要性を改善
• セカンダリ追加時にプライマリがデータ同期対象を認識する必要がない
• DB サイズに依存しないセカンダリレプリカ追加 / スケールアップ / スケールダウン
• ストレージのスナップショット機能によるバックアップ/リストアの高速化
• バックアップ処理の効率化 / 高速化と処理負荷をストレージにオフロード
• データベースの各機能を分散させたことで柔軟な拡張が可能
• コンピューティング / データ / ログの各処理を実行する環境をコンポーネント化

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. 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. 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. SQL Database Hyperscale の構成
11

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. 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. 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. 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. 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. 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. 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. 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. 参考) 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. 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. XLOG Service
 XLOG は外部ログを管理
 「無制限のログ」を抽象化して提供
 単一の Producer がログブロックを書き込み
 複数のリーダーが、ログブロックを消費
 Page Server の読み取りフィルターオプション
 DB ログの末尾
 Primary Compute の書き込みポイント
 トランザクションの永続コミットポイント
 固定サイズのマルチブロック領域に分割
(SQL 仮想ログファイル / VLFs)
 完全な VLF を長期保存ストレージへ Destage
 30 日の保持期間
22PASS Summit 2018 Day2 Keynote の内容を元に記載

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
ポータルのデプロイ画面
Azure SQL ハイパースケール データベースに関する FAQ