先日、ぺんぺん師匠が Azure sql database 入門 2014年10月版 で
[slideshare id=39862630&doc=azuresqldatabase-141004001720-conversion-gate01]
sys.resource_stats を Web/Business で使用すると、S2 を基準とした使用率を表示してくれるという情報をお話しされていてお～と思ったので試してみました。
# 現状、Web / Business の場合は S2 を基本としているという記載は sys.resource_stats の英語版の情報のみ記載されているようですね。
Azure SQL Database introduces new near real-time performance metrics
Azure SQL Database に新たなほぼリアルタイムのパフォーマンス指標を追加
に書かれていたようなのですが下の方は全く読んでいませんでした。
やはり、SQL Database についてはぺんぺん師匠と No.1 にぶん投げるのがよさそうです。
sys.resource_stats は 5 分間隔に集計されたデータが格納されます。
情報の取得間隔を眺めていたところ、取得できる情報は 5 分間隔なのですが、1 時間に一度ぐらいの頻度でデータ生成が行われているようで、検証した結果を取得するためには、1 時間程度時間を置いてから確認をするとよいかと思います。
# 使用されていない時間帯の情報は収集されないようなので、時間が抜けている場合は SQL Database が使用されていなかった可能性があります。
Web / Business で現状取得できる情報としては、以下のようになるようです。
# いくつかの項目は 0 になったままとなっていました。
| 項目 | 内容 |
| start_time | パフォーマンス統計情報の取得開始日時 |
| end_time | パフォーマンス統計情報の取得終了日時 (開始～終了が 5 分間隔となる) |
| database_name | データベース名 |
| sku | Web / Business / Basic / Standard / Premium |
| usage_in_seconds | CPU が使用されていた時間 |
| storage_in_megabytes | データベースの使用量 |
| active_session_count | アクティブなセッション数 |
| active_worker_count | アクティブなワーカースレッド数 |
| avg_cpu_percent | 平均 CPU リソース使用率 |
| avg_physical_data_read_percent | 平均物理ディスク読み取りリソース率 |
| avg_log_write_percent | 平均ログ書き込みリソース使用率 |
Web / Business で関連する情報は以下のようなクエリで取得ができます。
# master データベースに接続した状態で実行する必要があるのと、集計が行われるのが 1 時間間隔程度のようですので、その点を注意していただく必要があるかと。
select
start_time,end_time,database_name,sku,
usage_in_seconds,storage_in_megabytes ,
active_session_count,active_worker_count,
avg_cpu_percent,avg_physical_data_read_percent,
avg_log_write_percent
from sys.resource_stats
where sku IN ('Web', 'Business')
order by start_time desc
それでは、移行先の対応についてみていきたいと思います。
基本的な情報については Azure SQL Database Service Tiers and Performance Levels を確認するとよいかと思います。
# 日本語の情報は少し古いので英語版の情報を見るのがよいです。
データベースのサイズですがサービス層によって最大のサイズが異なります。
storage_in_megabytes を元に使用しているデータベースのサイズが賄えるサービス層を選択する必要があります。
廃止のエディションの限界は 150GB までで、Standard になると 250GB までは対応できますが 100GB を超えるとそれなりに性能が求められてくるかと思いますので、Premium になってくるのかな～と個人的な感想が。
| サービス層 | 最大サイズ |
| Web | 100MB 1GB 5GB |
| Business | 10GB 20GB 30GB 40GB 50GB 100GB 150GB |
| Basic | 100MB 500MB 1GB 2GB |
| Standard | 100MB 500MB 1GB 2GB 5GB 10GB 20GB 30GB 40GB 50GB 100GB 150GB 200GB 250GB |
| Premium | 100MB 500MB 1GB 2GB 5GB 10GB 20GB 30GB 40GB 50GB 100GB 150GB 200GB 250GB 300GB 400GB 500GB |
新しいサービス層では最大接続と最大ワーカースレッド数も異なってきます。
# Web / Business では最大のワーカースレッドは 180 だったかと。Azure SQL データベース リソース統制
こちらについても移行先でどの程度必要になるかは検討する必要があります。
| サービス層 | 最大接続数 | 最大ワーカースレッド数 |
| Basic | 300 | 30 |
| Standard S0 | 600 | 60 |
| Standard S1 | 900 | 90 |
| Standard S2 | 1,200 | 120 |
| Premium P1 | 2,400 | 200 |
| Premium P2 | 4,800 | 400 |
| Premium P3 | 19,200 | 1,600 |
avg_cpu_percent / avg_physical_data_read_percent / avg_log_write_percent については S2 を基準としての値となりますので、何倍になっているかを考慮してサービス層を検討する必要があるかと。
がつがつと負荷をかけてみたときには以下のようになりました。
各対応をざっくり取得する多場合のクエリは以下のような内容になりますでしょうか。
Web / Business を使用している場合、一度情報を取得してみて今後の検討をするのが大切なポイントとなりそうですね。
負荷状況によっては、負荷がかかっている個所のリソース使用率を低くする対応をして移行する必要があるかもしれませんし。
select
start_time,end_time,database_name,sku,
usage_in_seconds,storage_in_megabytes ,
CASE
WHEN storage_in_megabytes <= 2048 THEN 'Basic'
WHEN storage_in_megabytes <= 102400 THEN 'Standard'
ELSE 'Premium'
END AS size_service_tier ,
active_session_count,
CASE
WHEN active_session_count <= 300 THEN 'Basic'
WHEN active_session_count <= 600 THEN 'Standard/S0'
WHEN active_session_count <= 900 THEN 'Standard/S1'
WHEN active_session_count <= 1200 THEN 'Standard/S2'
WHEN active_session_count <= 2400 THEN 'Premium/P1'
WHEN active_session_count <= 4800 THEN 'Premium/P2'
WHEN active_session_count <= 19200 THEN 'Premium/P31'
END AS session_service_tier,
active_worker_count,
CASE
WHEN active_worker_count <= 30 THEN 'Basic'
WHEN active_worker_count <= 60 THEN 'Standard/S0'
WHEN active_worker_count <= 90 THEN 'Standard/S1'
WHEN active_worker_count <= 100 THEN 'Standard/S2'
WHEN active_worker_count <= 200 THEN 'Premium/P1'
WHEN active_worker_count <= 400 THEN 'Premium/P2'
WHEN active_worker_count <= 1600 THEN 'Premium/P31'
END AS worker_service_tier,
avg_cpu_percent,
CASE
WHEN avg_cpu_percent <= 10 THEN 'Basic'
WHEN avg_cpu_percent <= 20 THEN 'Standard/S0'
WHEN avg_cpu_percent <= 50 THEN 'Standard/S1'
WHEN avg_cpu_percent <= 100 THEN 'Standard/S2'
WHEN avg_cpu_percent <= 200 THEN 'Premium/P1'
WHEN avg_cpu_percent <= 400 THEN 'Premium/P2'
WHEN avg_cpu_percent <= 1600 THEN 'Premium/P3'
END AS cpu_service_tier,
avg_physical_data_read_percent,
CASE
WHEN avg_physical_data_read_percent <= 10 THEN 'Basic'
WHEN avg_physical_data_read_percent <= 20 THEN 'Standard/S0'
WHEN avg_physical_data_read_percent <= 50 THEN 'Standard/S1'
WHEN avg_physical_data_read_percent <= 100 THEN 'Standard/S2'
WHEN avg_physical_data_read_percent <= 200 THEN 'Premium/P1'
WHEN avg_physical_data_read_percent <= 400 THEN 'Premium/P2'
WHEN avg_physical_data_read_percent <= 1600 THEN 'Premium/P3'
END AS data_read_service_tier,
avg_log_write_percent,
CASE
WHEN avg_log_write_percent <= 10 THEN 'Basic'
WHEN avg_log_write_percent <= 20 THEN 'Standard/S0'
WHEN avg_log_write_percent <= 50 THEN 'Standard/S1'
WHEN avg_log_write_percent <= 100 THEN 'Standard/S2'
WHEN avg_log_write_percent <= 200 THEN 'Premium/P1'
WHEN avg_log_write_percent <= 400 THEN 'Premium/P2'
WHEN avg_log_write_percent <= 1600 THEN 'Premium/P3'
END AS log_write_service_tier
from sys.resource_stats
where sku IN ('Web', 'Business')
order by start_time desc
[…] sys.resource_stats を使用した Web/Business エディションの移行先検討 […]
Azure SQL Database の Web / Business は 2015年9月で提供終了。そろそろ移行の準備をはじめましょう。 - 雲のごとく - Site Home - MSDN Blogs
23 6月 15 at 11:54