開発部基幹SREチームの廣瀬です。2019が開催され、参加してきました。Server」の略です。Serverに限らず、Microsoftのデータプラットフォームを使っているプロフェッショナルのための世界的なコミュニティのことをいいます。Summitは、毎年秋に開催される、Microsoftのデータプラットフォーム分野における世界最大級のカンファレンスです。MVP、及びPASSのコミュニティメンバー等が登壇し、合計約260セッションの中から興味があるセッションを聴くことができます。11月5日のレセプションパーティと、6日から8日の3日間が本カンファレンスなのですが、4日と5日にプレカンファレンスというものが同時開催されます。こちらは約8時間のセッションを1日1つ受講する、というものです。1つのテーマについて、一般セッションよりも深い話を聞くことができます。そのため、私はプレカンファレンスも合わせて丸々5日間参加してきました。公式ページによると、PASSは1999年に設立された、約20年の歴史があるコミュニティみたいです。そのためか、カンファレンスの運営がとてもしっかりしており、初参加の人にも優しいカンファレンスであると感じました。Schedule作成機能があります。Scheduleへ複数登録しておき、直前にどのセッションを受講するか決めて参加していました。参加者の興味分野に応じて全部で10種類のラーニングパスが用意されていました。これは例えば「AIについて学びたいなら、この3セッションを順番に受講するといいよ」というガイドです。今年から導入された制度のようですが、受講セッションの選択時にとても参考になりました。参加者同士の交流を促す仕組み参加者同士の交流を促す仕組みが豊富だと感じました。Event」では6人1組でクイズに挑戦しました。Zone」が用意されていました。気になったセッション全部で14セッションに参加してきたので、その中で特に気になったセッションをピックアップし、レポートしたいと思います。Kehayias氏によるセッションでした。Server観点で最適化を実施するために気をつけるべき点や使えるツールについて、8時間ほどの充実したセッションでした。ハードウェアのパワーで解決できない問題はたくさんある冒頭でのこの問いかけは、自分の考えと一致し、一気に話に引き付けられました。インデックス不足や、遅いクエリの書き方、DBの設定不備などがあるとハードウェアをスケールアップさせても解決できないか、解決できたとしても金額面で折り合いがつきません。Serverレイヤーでの最適化が必要、という主張は大いに納得できるものでした。Problem」これは本当に名言だと思いました。Serverのレイヤーでも言えることだと思います。Indexにも一長一短あります。そのため適用したい箇所の性質を把握していないと成功しないよ、という主張には大いに納得しました。RDBMSに限らず、「問題を正確に把握すること」は、問題解決における基本であり最も重要なことではないでしょうか。Processingというそうです。日本だとミック本における「ぐるぐる系」でおなじみの概念かと思います。UDFや相関サブクエリもRBARにあたるそうです。「カーソルを使わずに一括で更新処理を行うべき」という講演者の主張に対し、「それってブロッキング起きませんか?」という会場からの鋭い質問が。回答は聞き取れませんでしたが、「ロックエスカレーションが起きない程度のバッチサイズ(500行など)でループして処理」がプロダクション環境における現実的な対応策かと思います。sp_WhoIsActiveが人気sp_WhoIsActiveとは、デフォルトで用意されているsp_whoやsp_who2といったプロシージャの上位互換といったイメージのもので、無償公開されています。こちらに使い方が紹介されていますが、海外だとみんな使っているようです。以前から知っていたものの使っていなかったのですが、コミュニティ内で信頼を得ていることが分かり、改めて使ってみようと思えました。拡張イベントは軽量なことで有名ですが、query_post_execution_showplanというイベントだけは、プロダクション環境で収集すべきではないとのことでした。秒間1万バッチ実行中の環境でquery_post_execution_showplanイベントを収集開始した途端、バッチ実行数が半減するデモは興味深かったです。みんなオーバーヘッドを気にしているこれは本セッションに限ったことではないのですが、情報取得に伴う負荷について気にする質問が多く飛び交っていました。「overhead?」と何回聞いたか分かりません。このセッションでは、クエリストアと拡張イベントに関する話のときに負荷についての質問が飛んでいました。プロダクション環境での情報取得の細かさとサーバー負荷はトレードオフの関係にあるため、ここは全DBAが気にするところなのだなと感じました。ヒント句は基本使わず、オプティマイザに任せるスピーカーのこの主張は同意です。data」というそうです。とあるステータスを持ったカラムがあり、100万レコード中10レコードだけがステータス=1で、それ以外は2であるような場合を考えます。この場合、where句でステータス=1で絞り込んだ時と2で絞り込んだ時では最適な実行プランが違ってきます。このような状況は日本でもみんな把握しているとは思うのですが、用語としては存在していない印象です。data」だけで伝わるのは良いなと思いました。Session:パフォーマンス関連パフォーマンスに関するセッションを複数受けまして、内容に重複があったので1つにまとめてレポートします。2019の新機能2019の新機能は、普段DBAが遭遇する問題をきちんと捉えているなと感じました。Microsoftの開発チームは、そうした問題の起きない世界をつくろうというヴィジョンを持っているのだと思います。Feedback(MGF)ワークスペースメモリ確保の過不足があったときに、初回実行のあとに同様のクエリに対してメモリ確保量を調整してくれる機能です。特定のクエリが必要以上にワークスペースメモリを確保してしまい、そのクエリが複数同時実行されることでRESOURCE_SEMAPHORE待ちが大量発生するというのはDBAあるあるかと思います。これを自動で防ぐ機能がMGFになります。これは素直に強力な新機能だなと思いました。Store解析系クエリにおけるCPUバウンドなクエリで、(作成におけるオーバーヘッドが大きすぎる等の理由で)カラムストアインデックスを作れない場合に有効な手段だそうです。OLTPと解析系クエリが混在するサーバーで有効な機能だと理解しました。functions)がクエリに入っていると、必ず基数推定が100行となっていました。そのため実際の行数との乖離が大きい場合に遅い実行プランが生成されてしまう場合がありました。2019では、MSTVFsの正確な行数を最適化のときに使用するため、基数推定精度が改善しているそうです。あるべき実行プランへと近づきやすくなっているということです。joinの決定を遅延できる仕組み。loop+大量のキー参照によってCPU高負荷な実行プランが生成される、という問題を未然に防ぐことが期待できるのではと感じました。最適化には非常にわずかなCPUおよび時間しか使えないため、基数を推定するしかありません。この「推定」と「実際」のズレによるパフォーマンスへの影響をどれだけ柔軟に吸収できるかという観点での進化を感じました。Databaseでも、起こりうる問題と調査手法、特定した原因の解決方法については王道が整理されている印象を受けました。複数セッションで同じようなことを話されていたので、業界の主流を知れてよかったです。Databaseのパフォーマンスチューニングやトラブルシューティングに使える機能として以下の5つを紹介されていました。DMVXEventsQueryStoreAutomaticTuningIntelligentInsightsクラウド、オンプレで手法はほとんど変わらないが、IntelligentInsightsはAzure限定とのことでした。使うツールも大事ですが、普段からbaselineを取得しておくことも大事だと話されていて、基本的なことですが重要だなと改めて思いました。sys.dm_exec_session_wait_statsというDMVがあり、セッション単位で待ち事象の内訳が取れるためとても便利だなと思いました。cloud」という名言が出ました。クラウドを使えば容易にスケールアップやスケールアウトできるためチューニングの必要性が薄れるというイメージもあるかもしれませんが、まったくそんなことはありません。クライドを使っている環境においては、チューニングスキルはより直接的に金銭的なコストカットというメリットをもたらす武器になると感じました。Store2016で導入されたクエリストアですが、解析におけるデフォルトの選択肢になっているようです。私自身は拡張イベントに頼りがちなのですが、クエリストアについてのスキルも上げていきたいなと思いました。クエリストアと拡張イベント、どちらを使うべきかという質問に対しては、「状況による」という回答でした。「実行プランがいつ変わったか」という問いに答えられるのはクエリストアだそうで、これは確かにと思いました。いった点があげられます。クエリストアに限った話ではなく、DMVやXEventsにも一長一短があるため、状況に応じてうまく組み合わせて調査することが大事なのだなと理解しました。そのためには、各ツールの長所短所をもっと理解する必要があると感じました。Ellis氏によるとても挑戦的なセッションでした。データモデリングに関するセッションはほぼ無かったので、こちらのセッションを受講しました。パフォーマンスチューニングの知識やその上位レイヤーのアーキテクティングの知識も大事ですが、その間に位置づけられるモデリングの知識も大事だなと最近感じています。Coddの考えは今日では少し古くなりつつある、という発言にはっとしました。Coddの考えは例えば「ディスクはとても高価である」という当時の状況に基づいています。そのため、正規化を実施することでデータの重複を防ぎ、ディスク容量を抑える狙いもあった、とのことでした。それが今日ではディスクはとても安価であり、状況が異なれば最適な設計もまた違ってくるということだそうです。他にも、「DBは全アプリケーションの中心にあるもの」という当時主流だった思想にも影響を受けているそうです。今日ではこの思想に基づく設計は、1つのアプリを変更した影響が他のアプリへと波及していまうというデメリットをはらんでいます。最後に、「DBにデータの正確性の責任を持たせる」という思想もあったそうです。この思想の問題点としては、ビジネスロジックがDBの中に入り込んでしまう点です。Serverの中にビジネスロジックが入り込んでしまうと、(ユーザ定義関数などで)その分リソースを使うため、結果的にライセンス料の高騰につながるという問題があります。ビジネスロジックをストアドプロシージャやトリガーに入れ込んでしまうとテスト、リファクタリング、読解がしづらい状況となってしまいます。代わりに、アプリ側でビジネスロジックを管理するほうが読みやすくテストもしやすいとの主張は、今日における主流の考え方なのかなと思いました。Coddの時代と現代の状況を比較した上で、スピーカーはデータモデリングにおける3つの重要な要素を主張していました。database/他アプリからの直接のデータアクセスは失礼という思想)というものです。heavyな性質を持っています。そのため、読み取り最適化を意識することが重要と話されていました。この思想だと、例えばRDBMSの顧客テーブルに「現在処理中の注文リストをもったJSONカラム」があっても良いじゃないか!という主張でした。この主張は名著SQLアンチパターンに掲載されているアンチパターンですが、スピーカーの思想に基づけば合理的な判断だなとも思いました。データの一貫性については、DBの責務ではなく、アプリ側の責務という考え方も興味深かったです。「注文合計金額」といったカラムの更新漏れチェックはアプリ側のテストに盛り込むべきと主張されていました。readsの思想にのっとって、非正規化を恐れない。冗長なデータの更新責務はアプリとアプリ開発者が背負うべきとのことでした。microserviceについては初心者向けの本を1冊読んだ程度でしたが、もっとこの思想について学ぶ必要があると痛感したセッションでした。disk」という主張に拍手が沸き起こっていました。昨今のモダンな設計におけるボトルネックはディスクよりもネットワークにあるため、ネットワーク最適化を意識したスキーマデザインが必要であるとのことでした。ここも自分にとって新鮮すぎる考え方だったため勉強にはなったのですが、知識不足で具体的なイメージまでは湧きませんでした。「モノリシックな大きいシステムをクラウドにもっていくのは金銭的なコストがかかるのでは?」という質問がでました。「コストは問題じゃない。クラウドのほうがオンプレよりもはるかにテクノロジーの進歩が速く、それらを常に使える状態になるほうが経営上のメリットがある」との回答に拍手が起きました。これは自分でも実感がありまして、オンプレ環境だと2019をプロダクション環境で使えるのは数年に1度のシステム更改時となります。そのため、強力な機能が存在するのにバージョンの都合で使えないのはもったいないと感じました。(※弊社にはクラウド環境もオンプレ環境も存在しています。OLTPに関するセッション。Serverに関わっているレジェンドらしいのですが、Microsoftで働き始めたのは半年ほど前から、という謎の経歴の持ち主でした。OLTPを使っている人?」という問いに対して挙手したのが会場全体の1%程度だったのがかなり印象的でした。OLTPは、効果は絶大なものの制約が多く、使いどころが非常に難しいイメージがありました。世界中から集まったDBA達の中でも、やはりプロダクション環境での使用例は少なく、実装のハードルは高いようです。Matchの話題だけで2.5時間という超絶マニアックなセッションでした。2019で唯一のLevel=500(最上級)ということもあり、せっかくなので受講してきました。ドキュメント化されている情報ではなく、スピーカーが実験の結果たどり着いた結論だそうで、実験の複雑さに圧倒されました。Site」というタイトルで応募したのですが、落選しました。そもそも私の英語力ではセッション途中のQ&Aなどに対応することが難しく、現状では無理な挑戦であったなと感じています。落選したのかについては、現地でセッションを受ける中でわりと明確になってきたので、書いておこうと思います。Summitの文脈を理解していなかったどういった内容のセッションが多いかは、カンファレンスごとに違うと思います。Serverの特定機能についての洞察や、クエリチューニングに特化したセッションなど、1トピックに対して深堀するセッションが多いように感じました。それは受講者にとっても大変聴きごたえのあるものでした。Serverの複数の機能を使って特定の問題を解決した、という事例紹介でした。Summitではウケの良くない内容だったなと感じました。PASSコミュニティへの貢献がまったく無かった応募の際は、最低でも3回の登壇経験を求められます。PASSコミュニティでは、「SQLSaturday」という小規模な勉強会も定期開催されています。Summitで話すという流れの人もいるようでした。Summitは一続きになっている印象を受けました。積極的にSQLSaturdayで登壇している人は、PASSコミュニティでウケる内容も自然と理解でき、採択されやすかったのではと思います。いうことで、SQLSaturdayで早速登壇したいと思ったのですが、日本のローカルコミュニティが無いようです。