性能問題を起こしにくい信頼されるクラウド RDB のつくりかた

性能問題を起こしにくい
信頼されるクラウド RDB のつくりかた
太田智行
#mstsjp18 #DA08
NECソリューションイノベータ株式会社
サポートサービス事業部データベースプロフェッショナルサービス部
DA08

© 2018 NEC Solution Innovators, Ltd. All rights reserved.
自己紹介
太田智行（おおたともゆき）
これまで：リレーショナルデータベースひと筋１５年超
PostgreSQL 8年、 SQL Server 8年、Oracleちょこちょこ、MySQL 甘噛み程度
現在：Data Platform 全般で活動中
WebでSQL Server技術記事をゆるやかに連載中
https://enterprisezine.jp/dbonline/detail/9626
データエンジニアの会
https://data-engineer.connpass.com/
Microsoft MVP for Data Platform（2018.2～）
https://mvp.microsoft.com/ja-jp/PublicProfile/5002980?fullName=Tomoyuki%20%20Oota

IaaS PaaS
Microsoft Azure
SQL Database
SQL Data
Warehouse
SQL Server
on
IaaS
Managed Instance Single Database Elastic Pool
データウェアハウス用途汎用、オンライントランザクション用途
+ Other Clouds

 改善フェーズ
➢ ５．チューニング
➢ ６．リソース拡張
本セッションのスコープ外

 リレーショナルデータベース管理者（DBA）
➢ 初～中級DBA
• DB構築時のチェックリストとして
➢ 上級DBA
• 頭の中にある過去経験の棚卸として

構築フェーズ
１．ストレージ構成の最適化

ストレージ
ディスク
ストレージ
コントローラ
ストレージ
ネットワーク
ホストバス
アダプタ
ストレージ
システム
最大性能
バランス
良
ストレージ
ディスク
ストレージ
コントローラ
ストレージ
ネットワーク
ホストバス
アダプタ
ストレージ
システム
最大性能
バランス
悪
CPU
CPU

 ディスクを束ねて必要I/O性能を構成する
 Azureリソース内のI/O性能
SQL Server on IaaS

Maneged Disk サイズ IOPS スループット MB/s
Standard HDD 32GB～32TB 500～2,000 60～500
Standard SSD 128GB～32TB 500～1,300 60～300
Premium SSD 32GB～16TB 120～15,000 25～750
Ultra SSD (preview) 4GB～64TB 1,200～160,000 300～2,000

0 500 1000 1500 2000
x1
x2
x3
x4
ディスクのストライピング本数と IOPS実測値
• ディスク
✓ S4（Managed Standard
HDD、Max 500 IOPS）
✓ Storage Spaceでストライピング
• VM
✓ Standard_D2s_v3
✓ ホストキャッシュ無し

 Azureリソースそれぞれにスループット上限あり
➢ ① ディスク
• ディスク種類とレベルに応じる（ex. Prm SSD P10：500 IOPS, 100 MB/s）
➢ ② ストレージアカウント ※. Unmanaged Diskが対象。Managed Diskはストレージアカウントの制約を受けない
• Standard：アカウントあたり 20,000 IOPS
• Premium：アカウントあたり 50 Gbps
➢ ③ VM
• VMレベルに応じる（ex. Std_DS2_v2：6,400 IOPS, 96 MB/s, 8Disks）
ディスク
ストレージ
アカウント
VM システムI/O性能

 ディスクを束ねて必要I/O性能を構成する
 Azureリソース内のI/O性能
SQL Database Managed Instance（General Purpose）

 DB作成するとDBファイルごと単一プレミアムディスクが割当たる
➢ データベースファイルごと排他的にスループットが保証される
１．ディスクのチョイスはAzureにおまかせ
Azure
Storage
Managed
Instance
(General Purpose)
ユーザ
DB
CREATE
DATABASE

 割当たるディスクはDBファイルのサイズに応じて自動決定
➢ 運用によるDBファイルのサイズ変動に応じてディスクレベルも自動調整
データベースファイルのサイズ割り当たるプレミアムディスク(Premium SSD)
(*) ～ 128GB P10（128 GB、500 IOPS、100 MB/s）
128GB ～ 256GB P15（256 GB、1100 IOPS、125 MB/s）
256GB ～ 512GB P20（512 GB、2300 IOPS、150 MB/s）
512GB ～ 1TB P30（1 TB、5000 IOPS、200 MB/s）
1TB ～ 2TB P40（2 TB、7500 IOPS、250 MB/s）
2TB ～ 4TB P50（4 TB、7500 IOPS、250 MB/s）
(*) 小さいDBファイルで
あってもP10未満が
アサインされることは
ない

 Gereral PurposeではTEMPDB に限りローカルSSD
➢ Business Critical（preview）は全DBファイルがローカルSSD
TEMPDB
Managed
Instance
(General Purpose)
ユーザDB
Azure
Storage
Local
SSD

 複数ファイル構成は従来通り SQL Server がストライプI/O
➢ あとから追加だとデータの装填に偏りが生じるので当初のサイジングは大事
• リバランス操作で偏り解消は可能ではあるが。
Azure
Storage
Managed
Instance
(General Purpose)
ユーザ
DB

データベースファイルのサイズ割り当たるプレミアムディスク(Premium SSD)
128GB ～ 256GB P15（256 GB、1100 IOPS、125 MB/s）
DBファイルのサイズとプレミアムディスクのサイズは一致しないため、それぞれに上限設定がある

WITH DatabaseFile AS(
SELECT database_id AS DatabaseID,
CAST(size * 8. / 1024 / 1024 AS decimal(12,4)) AS FileSizeGB
FROM sys.master_files )
SELECT
SUM(FileSizeGB) AS FileSizeGB,
SUM( IIF(
DatabaseID <> 2,
CASE WHEN FileSizeGB <= 128 THEN 128
WHEN FileSizeGB > 128 AND FileSizeGB <= 256 THEN 256
ELSE 8192
END, 0 ) ) AS BlobSizeGB
FROM DatabaseFile;
Managed Instanceデプロイ時に
指定したサイズ 32GB～8TB が上限
ストレージアカウントに設定
された 35TBが上限

 すべてAzureにおまかせ（DBファイルも意識しない）
SQL Database Single Database / Elastic Pool
SQL Data Warehouse

Azure IaaS Azure PaaSOn-Premises
SQL Server
SQL Server
on IaaS
Managed Instance
ネットワーク
ストレージ
サーバー
ホスト OS
仮想化
ゲスト OS
SQL Server インスタンス
データベース
データ
ネットワーク
ストレージ
サーバー
ホスト OS
仮想化
ゲスト OS
データベース
データ
ネットワーク
ストレージ
サーバー
ホスト OS
仮想化
ゲスト OS
データベース
データ
ネットワーク
ストレージ
サーバー
ホスト OS
仮想化
ゲスト OS
データベース
データ
Single Database / Elastic Pool
SQL Data Warehouse
Azure 管理利用者管理

CREATE DATABASE [DEMO_DB]
ON PRIMARY (
NAME=N'DEMO_DB',FILENAME=N'data.mdf')
LOG ON (
NAME=N'DEMO_DB_log',FILENAME=N'log.ldf')
GO
CREATE DATABASE 処理が
足回りを意識する

SELECT 氏名, 年齢, 住所
FROM 社員
WHERE 社員ID = ログインID
SELECT売上年度, SUM(売上)
FROM 売上明細
GROUP BY 売上年度

局所的なデータアクセス
✓物理配置の影響は受けにくい
など広範囲なデータアクセス
✓欲しいデータが物理的に近接していることが望ましい

コントロールノード
ユーザーからの接続
コンピュートとストレージの調整
コンピュートノード
クエリ実行
スケールアウト / イン可能
不要なときは停止可能
ストレージノード
データ保存
60分散のリモートストレージ
DW100
60分散固定
リモートストレージ

コントロールノード
ユーザーからの接続
コンピュートとストレージの調整
コンピュートノード
クエリ実行
スケールアウト / イン可能
不要なときは停止可能
ストレージノード
データ保存
60分散のリモートストレージ
DW600
60分散固定
リモートストレージ

 リモートストレージ間のデータ移動は大きな性能ペナルティ
➢ データ移動は主に結合や集計を行うクエリで発生する
• 結合する値がこのディストリビューション内に存在しない
• 集計がこのディストリビューション内で完結できない

 データ移動なし
 データ移動あり
コスト
0.00216
BROADCAST_MOVE
（
コスト
38400.00216

どのように分散配置するかによって制御
リモートストレージ間のデータ移動は大きな性能ペナルティ

ハッシュ分散ラウンドロビン分散（既定）レプリケート
分散キーのHush値で分散ランダム均等分散全てのストレージへコピー
CREATE TABLE (…)
WITH DISTRIBUTION=HASH(UserID)
CREATE TABLE (…)
WITH DISTRIBUTION=ROUND_ROBIN
CREATE TABLE (…)
WITH DISTRIBUTION = REPLICATE

ハッシュ分散ラウンドロビン分散（既定）レプリケート
分散キーのHush値で分散ランダム均等分散全てのストレージへコピー

➢ そのためにチョイスするべきキー列
• JOIN, GROUP BY, DISTINCT, HAVING で使用される列
✓Ex）ともにorder_idで分散したorders表とtransaction表をorder_idで
結合する場合はデータの移動が不要となる
✓注）JOINキーのデータ型は一致していないとダメ
• WHERE 句で使われていない列
✓ Ex）日付型はWhereでよく使われる

➢ そのためにチョイスするべきキー列
データスキュー状態の場合、並列クエリ実行時の各ディストリビューションの作業量も不均衡となり、
結果として全体の性能が最も処理が遅いディストリビューションの性能に引きずられる。

HASH([ProductKey]) HASH([ProductKey])

HASH([ProductKey])HASH([ProductKey])

ROUND_ROBINHASH([ProductKey])

HASH([ProductKey])
INT
HASH([ProductKey])
BIGINT

構築フェーズ
２．アクセスパスの最適化

Why
テーブルスキャン
インデックスシーク
＋
テーブルルックアップ
VS
1
3
2
4
6
5
7
9
8
1
2
3 5
4
テーブルインデックステーブル

Why
テーブルスキャン
インデックスシーク
＋
テーブルルックアップ
VS
1
3
2
4
6
5
7
9
8
1
2
3
9
8
7
6
5
10
4
テーブルインデックステーブル

 適切なインデックスを定義する
 正しくクエリを書く
 統計情報の高い鮮度と精度を保つ（詳細は4章で）

 インデックス利用が正解とは限らない。
➢ 小さいテーブル
➢ 広範囲のスキャン
 インデックス構造を踏まえた適切なインデックスを利用する
➢ B-Tree（非クラスタ化、クラスタ化、付加列）、列ストア
• ビットマップ、ハッシュは無し。
1
2
3
9
8
7
6
5
10
4

 インデックスはあればあっただけ良いというものではない
➢ 使われないインデックスは百害あって一利なし。
+システム性能向上
本の目次は
固定だけど。

 作りっぱなしはだめ
➢ 定期メンテナンスが必要（詳細は4章で）
インデックスも
デフラグ必要

注文ID 商品ID 日付売上
101 52 201801 100
・・・・・・・・・・・・
110 23 201812 300
集
計
処
理
101 52 201801 100
・・・・・・・・・・・・
110 23 201212 300
バッファプール
101 52 201801 100
・・・・・・・・・・・・
110 23 201212 300
集計に不要な列
もI/Oされる
もキャッシュされる
注文ID 商品ID 日付売上
101 52 201801 100
・・・・・・・・・・・・
110 23 201812 300
集
計
処
理
100
・・・
300
バッファプール
100
・・・
300
はI/Oされない
行ストア
列ストア
行ストア
列ストア
集計に不要
な列はキャッ
シュされない
同じ属性なので
圧縮効果も高い

カラムストア (既定) ヒープ
クラスタ化インデックス
非クラスタ化インデックス
✓ 大きなテーブル（パーティショ
ン当たりの行数は 100 万
行以上に保つ）
✓ 列単位 I/O、高圧縮率
✓ ヒープと比較してデータロード
は低速
✓ ロード用ステージングテーブル
✓ 1 億行未満の小さなルック
アップテーブル
✓ 一時テーブル（ローカルスト
レージに配置された
tempdb）を使うことでさら
にロードを高速化
✓ 極めて少数の行の検索が
優先となるテーブル
✓ 非クラスタ化インデックスは
セカンダリインデックスとして
利用可能

 インデックスが使われないかもしれないケース例

運用フェーズ
３．パフォーマンスの監視

可視化
分析&処方
自動対処

➢ Azure Monitor
➢ Azure SQL DW Monitor
➢ Azure Advisor
➢ Azure VM Perf Diagnostics(preview)
➢ Azure SQL DB Query Perf Insights
➢ Azure SQL DB Intelligent Insights
➢ Automatic Tuning
for Azure SQL DB
可視化
分析&処方
自動対処

➢ Perfmon 消
➢ Activity Monitor 消
➢ Dara Collector 消
➢ Azure Monitor
➢ Azure Advisor
for Azure SQL DB
可視化
分析&処方
自動対処

アボートするワーカーが
増えています

ロックウェイトの多発が
性能に影響しています。
下記はロックチェーンの
先頭にいるクエリ一覧
です。

ユーザからの負荷が増大し
積みあがっています。
CPU,IO,LOGの負荷は限
界に達しています

リソース使用率が増加したクエリの数
は3です。その中で最大の原因は最近
データベースに登場した新しいクエリ
（0x34CFCB2D40A683FD）です。

検出された性能問題のパターンは
「ワークロードの増加」

✓ リソースの上限に到達 ✓ 待機の増加
✓ ワークロードの増加 ✓ TempDB の競合
✓ メモリ不足 ✓ エラスティックプールの DTU 不足
✓ 過剰ロック ✓ プランの変動
✓ 過剰並列化処理 ✓ データベーススコープの構成値の変更
✓ ページラッチの競合 ✓ 処理速度が低いクライアント
✓ インデックスの不足 ✓ 価格レベルのダウングレード
✓ 新しいクエリの検出

➢ Perfmon 消
, SQL Trace 消
➢ Azure Monitor
➢ Database Engine Tuning Advisor 消
➢ Azure Advisor
for Azure SQL DB
可視化
分析&処方
自動対処

➢ Perfmon 消
➢ XEvent, SQL Trace 消
➢ Query Store 消
➢ Azure Monitor
➢ Database Engine Tuning Advisor 消
➢ Azure Advisor
➢ Automatic Tuning 可視化
分析&処方
自動対処

✓ 接続を監視する
✓ クエリ実行を監視する
✓ 待機クエリを監視する
✓ tempdb を監視する
✓ メモリを監視する
✓ トランザクションログのサイズを監視する
✓ トランザクションログのロールバックを監視する
参考）https://docs.microsoft.com/ja-jp/azure/sql-data-warehouse/sql-data-warehouse-manage-monitor

運用フェーズ
４．メンテナンス

統計情報の定期メンテナンス
 統計情報のメンテナンス挙動把握が大事。
➢ 作成されるタイミング
• Indexが作成された列WHERE句やJOIN句の条件となった列に対し
て自動作成（手動作成も可）
➢ 更新されるタイミング
• ざっくり目安としてレコード数の20%に相当するレコードが変更さ
れたタイミングで自動更新（レコード数増加に応じて20％閾値は自
動調整される）。
統計情報の精度・鮮度は性能に直結

参考：統計情報の自動更新の詳細
① クエリプラン
キャッシュの検索
.
② 関連する統計情報
のロード
成功
③b 古い統計情報
はあるか
Yes
No
③a 更新が必要な統計情報すべてを更新
④ クエリプラン生成とリコンパイル閾値の設定
⑤ クエリプランのテスト（スキーマチェック）
⑥ スキーマは
有効か
Yes
⑦ 新しい統計情報
を使用できるか
⑧ 古い統計情報は
あるか
⑨ クエリ
実行
Yes Yes
No No
⑩ リコンパイル
No
失敗
.
S E
クエリ
実行開始
クエリ
実行終了

計画的な手動更新が必要となる場合もある
一定のデータ量手動更新不要
一貫した増加傾向基本的には自動更新に任せておけばよい
一定間隔の増減反復バッチ処理のような大量更新を行う場合は手動更新
とセットで実施（初回クエリが犠牲にならないように）
データの分布変化自動更新しきい値未満でもデータ分布に影響を与える
変更を行う場合は手動更新をセットで実施
新しいデータの参照新しいデータのみ参照したい場合は手動更新をセット
で実施

インデックスの定期メンテナンス
✓ データの変更に伴いデータが断片化
✓ → I/O量やインストラクション増大
✓ → 性能劣化
性能劣化予防のために定期的にデフラグする
キーポインタ
10 ・・・
20 ・・・
30 ・・・
40 ・・・
50 ・・・
60 ・・・
キーポインタ
10 ・・・
20 ・・・
21 ・・・
30 ・・・
キーポインタ
40 ・・・
50 ・・・
60 ・・・
INSERT
キー = 21

 内部断片化
➢ ページ内のデータの装填率（密度）を示す
➢ 未使用領域分の余計なI/Oによるアクセス効率低下
• FILLFACTORで装填率をコントロールしているケースも
断片化の種類とその影響
同じデータ量に対して装填率100%
と50%ではI/Oページ量が2倍になる装填率
100%
装填率
50%
vs

 外部断片化
➢ インデックス論理順とファイル内物理順の不一致度合いを示す
➢ データ順が不連続状態になることでのアクセス効率低下
10
- 11
index
record
11
10 20
index
record
12
p n
index
record
13
p n
index
record
14
p n
index
record
15
26 16
index
record
16
15 17
index
record
17
16 18
index
record
18
p n
index
record
19
p n
index
record
20
11 23
index
record
21
p n
index
record
22
p n
index
record
23
20 24
index
record
24
23 15
index
record
25
p n
index
record
～
ファイル内の物理番地 →
インデックスの論理順 →
インデックスAの断片
（大きさ=2）
（大きさ=3）
（大きさ=1）
インデックスAの断片化率＝＝３７．５％
３（赤線ホップ数）
８（総ページ数）
（大きさ=2）

 B-Treeインデックスの深さ
➢ B-Treeの階層の数を示す
➢ 欲しいデータの番地を得るまでに辿らねばならないインデックス
ページが増えることでのアクセス効率低下
1階
4階
3階
2階
最上階から1階まで下るコストを
4階建と3階建で比較すると単純計算
で1.3倍強になる（3階までなら階段で
上がってもいいけど4階となると…）。
vs

まとめ

S
Thank you!

Information
「Ask The Speaker」
各ブレイクアウトセッション終了後の休憩時間に、
登壇したスピーカーに直接ご質問いただけるコーナーを
B2F 「Ask The Speaker」 Room に用意
しています。セッション内容のより深い理解のため、
ぜひお役立てください。
（※ハンズオンラーニング、シアターセッション、ビジネストラック
及び一部のセッションを除きます）
EXPO
AREA 1
EXPO
AREA 2
Room
B

セッションアンケートにご協力ください。
公式イベントアプリで、「Microsoft Tech Summit 2018 参加者アンケート（必須）」と
「各セッションアンケート（ 5 つ以上）」、合わせて 6 つ以上のアンケートにご回答ください。
もれなくオリジナルグッズを贈呈いたします。
Information
Twitter のご案内
本セッションに関するご質問やご感想は、 #mstsjp18 とセッション ID の
ハッシュタグで、ご投稿をお願いします。
#mstsjp18

性能問題を起こしにくい信頼されるクラウド RDB のつくりかた

More Related Content

What's hot

Similar to 性能問題を起こしにくい信頼されるクラウド RDB のつくりかた

More from Tomoyuki Oota

性能問題を起こしにくい信頼されるクラウド RDB のつくりかた