どうも、ムッシュこと小澤です。
ムッシュ こと Microsoft MVP 小澤 真之 氏より、Azure SQL DatabaseとOfficeアプリケーションとの連携など、可能性をご紹介いただきました！ #decode17 #DI02 pic.twitter.com/I2SgwKZQOc
— Microsoft Tech (@msdevjp) May 23, 2017
既にデモ環境で使用したスクリプトの公開などで少し投稿させていただきましたが、de:code 2017 の、まかせて! Azure SQL Database で登壇をさせていただきました。
de:code は 2015 年から登壇させていただいており、今回で 3 回目の登壇となりました。
今回の登壇では、日本マイクロソフトの山本さん と共同登壇をさせていただきました。
↓ はリハーサルの風景 
セッション内では、Azure の Database の新しいサービスである、「Azure SQL Database Migration Services (DMS) 」を山本さんにデモ付きで紹介していただいたのですが、DMS が画面込みで紹介されたの日本初だったと思います。
日本初ということをアピールしきれず、山本さんには大変申し訳なく…。
ということで、セッションのフォロー投稿を軽く。
ちなみに、デモ環境のスクリプトの格納場所等を twitter でつぶやくように Microsoft Flow で仕込んでおいたのですが、つぶやきの内容が 140 文字を超えていて Flow の実行が失敗していました…。
／(^o^)＼ ナンテコッタイ。
デモ環境で使用した環境については、
をご確認ください。
■セッションの内容
SQL Database には、どんどん新機能が追加されています。
その中には、データベースの運用を支援する機能もたくさんあり、本セッションでは、新機能の紹介を含め「SQL Database をこれから使う方にも安心して使っていただくことができるための支援機能の紹介」や、「SQL Server で情報を取得する際に使用していた方法が SQL Database ではどのような手法で確認ができるか」を主軸にして内容を組み立ててみました。
キーノートで、「Azure Relational Database の Database Services Platform の構成要素」として、
- Intelligent : Advisor / Tuning / Monitoring
- Flexible : On-demands scalling / Resource Governance
- Trusted : HA/DR / Backup, Restore / Security / Audit / Isolation
が紹介されていました。
私の担当分では、「Intelligent」の「Advisor」「Tuning」「Monitoring」について、現状の SQL Database ではどのような機能を使用することができるのかをご紹介させていただいたのですが、これから利用される方や、すでに利用されている方が、一つでも新しい情報をお持ち帰りできたようでしたら幸いです。
■リソース使用状況のモニタリング
SQL Database では DTU という単位で性能指標が表現され、DTU サイズが高ければ性能が高いということになります。
DTU の使用状況の取得については、ポータルや DMV から取得することができますが、それ以外の方法でリソースの使用状況の取得方法を確認する方法は、情報が少ないのではと思い、今回は「sys.dm_os_performance_counters」を使用したリソースの使用状況をご紹介させていただきました。
今回は「Single Database (単一データベース)」を想定しての情報の取得を行っています。
セッション内では触れられなかったのですが、「Elastic Database Pool」に関しては、今回の方法では情報の見方が少し異なってくるのですが、基本的な仕組みとしては利用できるのかなと。
データの可視化については、Power BI を使用していましたが、これは時系列データが格納/可視化できるものであれば何でもよいかと。
情報の取得については、usp_LiveMonitor というストアドプロシージャーから実施していたのですが、こちらについて軽く補足を。
今回は 1 行で取得しているようにしていますが、これは好みの問題なので、行単位で項目を取得してもよいかなと。
■ cntr_type = 272696576 のデータの扱い
この種類については、累計データが値として取得されているため、特定の時間帯の情報を取得したい場合は「2 点間で情報を取得して、経過時間で割る」というような算出をする必要があります。
今回のストアドでは、クエリを 2 回実行し、各回の間は「WAITFOR DELAY ’00:00:01’」で WAIT を発生させ、1 秒程度の間隔で発生した情報を取得するようにしています。
そのため、WAIT が発生するクエリですので実行には、必ず 1 秒以上実行に時間がかかりますが。
■ Base と Ratio が存在している情報の扱い
CPU 使用率やキャッシュヒット率については Ratio / Base で実施する必要がありますので、比率を算出する必要があるものに関してはそのような形で計算をしています。
■ CPU 使用状況等の取得
Box の SQL Server であれば、OS 関連のパフォーマンスモニターを取得することで情報を確認できますが、SQL Database では OS 関連のパフォーマンスモニターは取得できないため、「Resource Pool Stats」のカテゴリの情報を DMV から取得して加工しています。
この情報は「リソースガバナー」の機能の情報がベースとなっているのですが、インスタンス名としては「(instance_name LIKE ‘SloPool%’ OR instance_name LIKE ‘SloSharedPool%’)」で取得しています。
これは、サービスレベルによって、使用されているプールの名称が異なっているようなので、使用しているサービスレベルの影響を受けないための対応となっています。
パフォーマンスについては、Standard と Premium の違いについても触れさせていただきました。
Standard と Premium の境である S3 : 100 / P1 : 125 は、数字上は 25 の違いではありますが「ディスクパフォーマンス」に関しては大きく異なっています。
セッション内では「DATA IO」ということで、データファイルの DTU 性能について紹介しましたが、実際にはデータファイルだけでなく「トランザクションログ IO」についても大きな性能差が出ますので、この辺も意識しておいていただくとよいかと。
リソースのボトルネックが解消すると、他の個所に負荷がかけられる (かかる) ようになるため、リソース使用状況のトレンドが、サービスレベルを変更する前と異なることがありますので、この辺は「正しく状況を把握して情報を読み取る」という点を意識していただけるとよいかと。
■SQL Database の新機能
Build 2017 でいくつかの新機能が発表されました。
- Automatic tuning for Query Plans
- Graph Table
- Adaptive Query Processing
SQL Database での対応については、現状アナウンス段階のため、これらについてを確認したい場合には、SQL Server 2017 CTP を使用して確認をしていただくとよいかと。
■チューニングのための情報取得
■自動チューニング
チューニングの機能としては
- Query Performance Insight とクエリストア
- Index Advisor と自動チューニング
について紹介をさせていただきました。
どちらも、GA して時間が経っているので使われた方は多いのではないでしょうか。
今回は TPC-H のデータベースをインデックスを設定しない状態で作成し、TPC-H のクエリを継続して実行することで、インデックスの推奨事項と自動チューニングを実施させていました。
TPC-H のデータ作成については https://github.com/Azure/Azure-DataFactory/tree/master/Samples/TPCHTools でData Factory の検証を実施するためのリポジトリで dbgen が公開されていますので、ここから入手していただくとよいかと。
現状の自動チューニング機能については、一日程度でアドバイス情報が上がってくるはずですので、推奨事項があれば翌日には確認できるのかなと思います。
自動チューニングのデモとしては、以下のようなクエリの実行プランを紹介させていただきました。
このデータベースでは自動チューニングが有効な状態にしており、最初は実行に時間がかかっていたのですが、以下の図の部分のように途中で大きく実行時間が減少しているのが確認できるかと思います。
これは、自動チューニングによって自動的にインデックスが作成され効率的にクエリが実行できるようになったためです。
今の SSMS では、「クエリの実行プランの比較」を実施することができ、クエリストアで複数のプランを選択した状態でもこの機能は使用することが可能です。
最新の SSMS であれば、「プラン表示の分析」の機能を使用することができますので、これと組み合わせてもらうと、変更箇所もわかりやすくなるのではないでしょうか。
■拡張イベントを使用したクエリトレース
デモの中では拡張イベントを使用して、SQL Server Profiler ではないクエリトレースの仕組みを紹介させていただきました。
Event File ターゲットを使用することで、BLOB ストレージ上にログを出力することが可能ですが、リアルタイムで見るのであれば、Ring Buffer ターゲットでも可能なので、今回は Ring Buffer を使用しています。
直近 1000 程度のクエリになりますが以下にサンプルを公開していますので、ご利用いただければと。
https://github.com/MasayukiOzawa/SQLDatabase-Util/tree/master/Query%20Trace
■セキュリティ機能
Build のタイミングで「脅威検出 (Threat Detection)」の機能が GA しましたので、本セッションでも紹介させていただきました。
脅威検出ですが、連続した検出の通知は実施されないようで、一度検出が行われると 1 日は間隔をあけないと再度メール等の通知が行われないようだったので、当日にデモをするにはなかなか悩ましい機能でした。
(セッション中にチャレンジしてみたのですが不発だったため、過去の検知を紹介しました)
ここについてはデモでポータルベースで紹介させていただいたのですが、これ以外に、
- メール
- 拡張イベントのファイル
からも確認することができます。
メールについては公開スライドに添付していますので、そこを見ていただければよいかと思いますが、拡張イベントについては紹介できていなかったのでここで捕捉を。
以前からセキュリティの機能として「監査」がありました。
当初から監査機能を使用していた方は、ログの確認は、Table からデータを読み込む Excel を使っていたのではないでしょうか。
監査と脅威検出のログの最新の出力形式については、出力先を BLOB に指定した拡張イベント形式となっており、日単位でストレージに保存されています。
BLOB ストレージに出力されている拡張イベントファイルに関しては、sys.fn_get_audit_file で確認することもできます。
確認用のクエリのサンプルについては https://github.com/MasayukiOzawa/SQLDatabase-Util/tree/master/Audit%20Log で公開しましたのでこちらから確認いただければ。
補足しておいた方がよさそうかなと思った内容はこの辺でしょうか。
Build から de:code までの期間は短く、最新の情報を含めるのが中々にしんどかったりはしますが、ひとまず登壇が完了して一息というところですね。