こんにちは！ 開発部基幹SREチームの廣瀬です。 2019年11月4日から8日にかけてシアトルでPASS Summit 2019が開催され、参加してきました。 初めての海外カンファレンスで少し緊張しましたが、得るものはとても多かったため、その内容をレポートしたいと思います！
PASS Summit 2019
PASSとは「Professional Association for SQL Server」の略です。 SQL Serverに限らず、Microsoftのデータプラットフォームを使っているプロフェッショナルのための世界的なコミュニティのことをいいます。 PASS Summitは、毎年秋に開催される、Microsoftのデータプラットフォーム分野における世界最大級のカンファレンスです。 MicrosoftのエンジニアやMicrosoft MVP、及びPASSのコミュニティメンバー等が登壇し、合計約260セッションの中から興味があるセッションを聴くことができます。
11月5日のレセプションパーティと、6日から8日の3日間が本カンファレンスなのですが、4日と5日にプレカンファレンスというものが同時開催されます。こちらは約8時間のセッションを1日1つ受講する、というものです。 1つのテーマについて、一般セッションよりも深い話を聞くことができます。そのため、私はプレカンファレンスも合わせて丸々5日間参加してきました。
公式ページによると、PASSは1999年に設立された、約20年の歴史があるコミュニティみたいです。 そのためか、カンファレンスの運営がとてもしっかりしており、初参加の人にも優しいカンファレンスであると感じました。
PASS Summitのここが素敵
公式アプリが充実
全日程のイベントやセッションのスケジュール、会場の情報等がアプリに集約されており、自分の興味があるスケジュールだけをピックアップしたMy Schedule作成機能があります。
私は事前に気になるセッションをMy Scheduleへ複数登録しておき、直前にどのセッションを受講するか決めて参加していました。
関連セッションを複数に束ねて紹介する「Learning Pathways」
参加者の興味分野に応じて全部で10種類のラーニングパスが用意されていました。これは例えば「AIについて学びたいなら、この3セッションを順番に受講するといいよ」というガイドです。 今年から導入された制度のようですが、受講セッションの選択時にとても参考になりました。
参加者同士の交流を促す仕組み
参加者同士の交流を促す仕組みが豊富だと感じました。 例えば、カンファレンス初参加者が集まって交流する「Fisrt-Timer Event」では6人1組でクイズに挑戦しました。 他にはアジア圏やヨーロッパ圏など、同じ地域の参加者同士で交流できる「PASS Community Zone」が用意されていました。
気になったセッション
全部で14セッションに参加してきたので、その中で特に気になったセッションをピックアップし、レポートしたいと思います。
Session：Bigger Hardware or Better Code and Design?
Microsoft SQL Server 2012 Internalsの著者の一人であるJonathan Kehayias氏によるセッションでした。 SQL Server観点で最適化を実施するために気をつけるべき点や使えるツールについて、8時間ほどの充実したセッションでした。
ハードウェアのパワーで解決できない問題はたくさんある
冒頭でのこの問いかけは、自分の考えと一致し、一気に話に引き付けられました。 インデックス不足や、遅いクエリの書き方、DBの設定不備などがあるとハードウェアをスケールアップさせても解決できないか、解決できたとしても金額面で折り合いがつきません。 これはクラウドのPaaSでSQL Serverを使ったとしても生じる問題であり、SQL Serverレイヤーでの最適化が必要、という主張は大いに納得できるものでした。
「Matching the Design to the Problem」
これは本当に名言だと思いました。 この考えは、アーキテクティングのレイヤーでも言えることだと思いますし、SQL Serverのレイヤーでも言えることだと思います。 SQL Serverの強力な機能であるIn-memory OLTPやColumnstore Indexにも一長一短あります。 そのため適用したい箇所の性質を把握していないと成功しないよ、という主張には大いに納得しました。 RDBMSに限らず、「問題を正確に把握すること」は、問題解決における基本であり最も重要なことではないでしょうか。
RBAR Processing を避ける
行単位での読み込みが大量発生するような処理をRBAR(row-by-agonizing-row) Processingというそうです。 日本だとミック本における「ぐるぐる系」でおなじみの概念かと思います。 カーソルを使って1行ずつ処理する方式はRBAR Processingの代表格ですが、他にもScalar UDFや相関サブクエリもRBARにあたるそうです。 「カーソルを使わずに一括で更新処理を行うべき」という講演者の主張に対し、「それってブロッキング起きませんか？」という会場からの鋭い質問が。 回答は聞き取れませんでしたが、「ロックエスカレーションが起きない程度のバッチサイズ（500行など）でループして処理」がプロダクション環境における現実的な対応策かと思います。
sp_WhoIsActiveが人気
sp_WhoIsActiveとは、デフォルトで用意されているsp_whoやsp_who2といったプロシージャの上位互換といったイメージのもので、無償公開されています。 こちらに使い方が紹介されていますが、海外だとみんな使っているようです。 以前から知っていたものの使っていなかったのですが、コミュニティ内で信頼を得ていることが分かり、改めて使ってみようと思えました。
拡張イベント使用時の注意点
拡張イベントは軽量なことで有名ですが、query_post_execution_showplanというイベントだけは、プロダクション環境で収集すべきではないとのことでした。 秒間1万バッチ実行中の環境でquery_post_execution_showplanイベントを収集開始した途端、バッチ実行数が半減するデモは興味深かったです。
みんなオーバーヘッドを気にしている
これは本セッションに限ったことではないのですが、情報取得に伴う負荷について気にする質問が多く飛び交っていました。 「overhead?」と何回聞いたか分かりません。このセッションでは、クエリストアと拡張イベントに関する話のときに負荷についての質問が飛んでいました。 プロダクション環境での情報取得の細かさとサーバー負荷はトレードオフの関係にあるため、ここは全DBAが気にするところなのだなと感じました。
ヒント句は基本使わず、オプティマイザに任せる
スピーカーのこの主張は同意です。
skewed data
selectivityが一定でない性質をもつカラムを「skewed data」というそうです。 例えば、とあるステータスを持ったカラムがあり、100万レコード中10レコードだけがステータス=1で、それ以外は2であるような場合を考えます。 この場合、where句でステータス=1で絞り込んだ時と2で絞り込んだ時では最適な実行プランが違ってきます。 このような状況は日本でもみんな把握しているとは思うのですが、用語としては存在していない印象です。「skewed data」だけで伝わるのは良いなと思いました。
Session：パフォーマンス関連
パフォーマンスに関するセッションを複数受けまして、内容に重複があったので1つにまとめてレポートします。
- Query Optimization Statistics: Driving Force Behind Performance
- Azure SQL Database: Maximizing Cloud Performance and Availability
- Query Store In-Depth
- Performance Tuning Azure SQL Database
SQL Server 2019の新機能
2019の新機能は、普段DBAが遭遇する問題をきちんと捉えているなと感じました。 Microsoftの開発チームは、そうした問題の起きない世界をつくろうというヴィジョンを持っているのだと思います。
Memory Grand Feedback(MGF)
ワークスペースメモリ確保の過不足があったときに、初回実行のあとに同様のクエリに対してメモリ確保量を調整してくれる機能です。 特定のクエリが必要以上にワークスペースメモリを確保してしまい、そのクエリが複数同時実行されることでRESOURCE_SEMAPHORE待ちが大量発生するというのはDBAあるあるかと思います。 これを自動で防ぐ機能がMGFになります。これは素直に強力な新機能だなと思いました。
Batch Mode On Row Store
解析系クエリにおけるCPUバウンドなクエリで、（作成におけるオーバーヘッドが大きすぎる等の理由で）カラムストアインデックスを作れない場合に有効な手段だそうです。 OLTPと解析系クエリが混在するサーバーで有効な機能だと理解しました。
Interleaved Execution for MSTVFs
今まではMSTVFs(Multi-Statement Table-valued functions)がクエリに入っていると、必ず基数推定が100行となっていました。 そのため実際の行数との乖離が大きい場合に遅い実行プランが生成されてしまう場合がありました。 2019では、MSTVFsの正確な行数を最適化のときに使用するため、基数推定精度が改善しているそうです。 つまりは、あるべき実行プランへと近づきやすくなっているということです。
Batch Mode Adaptive Joins (AJ)
skewed dataがあるときに、駆動表のselectivityが分かるまで、hash join/innner joinの決定を遅延できる仕組み。 この機能があることで、nested loop＋大量のキー参照によってCPU高負荷な実行プランが生成される、という問題を未然に防ぐことが期待できるのではと感じました。
最適化には非常にわずかなCPUおよび時間しか使えないため、基数を推定するしかありません。 この「推定」と「実際」のズレによるパフォーマンスへの影響をどれだけ柔軟に吸収できるかという観点での進化を感じました。
クラウド（SQL Database）におけるパフォーマンスチューニング
SQL ServerでもSQL Databaseでも、起こりうる問題と調査手法、特定した原因の解決方法については王道が整理されている印象を受けました。 複数セッションで同じようなことを話されていたので、業界の主流を知れてよかったです。
SQL ServerおよびSQL Databaseのパフォーマンスチューニングやトラブルシューティングに使える機能として以下の5つを紹介されていました。
- DMV
- XEvents
- QueryStore
- AutomaticTuning
- IntelligentInsights
クラウド、オンプレで手法はほとんど変わらないが、IntelligentInsightsはAzure限定とのことでした。 使うツールも大事ですが、普段からbaselineを取得しておくことも大事だと話されていて、基本的なことですが重要だなと改めて思いました。
sys.dm_exec_session_wait_statsというDMVがあり、セッション単位で待ち事象の内訳が取れるためとても便利だなと思いました。使いたい。。！
セッション中に「performance tuning skills = immediate cost savings in the cloud」という名言が出ました。 クラウドを使えば容易にスケールアップやスケールアウトできるためチューニングの必要性が薄れるというイメージもあるかもしれませんが、まったくそんなことはありません。 むしろ、クライドを使っている環境においては、チューニングスキルはより直接的に金銭的なコストカットというメリットをもたらす武器になると感じました。
Query Store
2016で導入されたクエリストアですが、解析におけるデフォルトの選択肢になっているようです。 私自身は拡張イベントに頼りがちなのですが、クエリストアについてのスキルも上げていきたいなと思いました。
クエリストアと拡張イベント、どちらを使うべきかという質問に対しては、「状況による」という回答でした。 ただし、「実行プランがいつ変わったか」という問いに答えられるのはクエリストアだそうで、これは確かにと思いました。
クエリストアのlimitationとしては、
- ログイン名、ホスト名、アプリケーション名は記録されない
- 集約された情報だけで、個別クエリの詳細は省かれる
- 実際の行数といった、実行時の情報は記録されない といった点があげられます。
クエリストアに限った話ではなく、DMVやXEventsにも一長一短があるため、状況に応じてうまく組み合わせて調査することが大事なのだなと理解しました。 そしてそのためには、各ツールの長所短所をもっと理解する必要があると感じました。
Session：Relational Data Modeling Trends for Transactional Applications
Microsoft MVPのIke Ellis氏によるとても挑戦的なセッションでした。
データモデリングに関するセッションはほぼ無かったので、こちらのセッションを受講しました。 パフォーマンスチューニングの知識やその上位レイヤーのアーキテクティングの知識も大事ですが、その間に位置づけられるモデリングの知識も大事だなと最近感じています。
「EF Codd's ideas are bit outdated」
EF Coddの考えは今日では少し古くなりつつある、という発言にはっとしました。 スピーカーによると、EF Coddの考えは例えば「ディスクはとても高価である」という当時の状況に基づいています。 そのため、正規化を実施することでデータの重複を防ぎ、ディスク容量を抑える狙いもあった、とのことでした。 それが今日ではディスクはとても安価であり、状況が異なれば最適な設計もまた違ってくるということだそうです。
他にも、「DBは全アプリケーションの中心にあるもの」という当時主流だった思想にも影響を受けているそうです。 今日ではこの思想に基づく設計は、1つのアプリを変更した影響が他のアプリへと波及していまうというデメリットをはらんでいます。 最後に、「DBにデータの正確性の責任を持たせる」という思想もあったそうです。 この思想の問題点としては、ビジネスロジックがDBの中に入り込んでしまう点です。 SQL Serverの中にビジネスロジックが入り込んでしまうと、（ユーザ定義関数などで）その分リソースを使うため、結果的にライセンス料の高騰につながるという問題があります。
ビジネスロジックをストアドプロシージャやトリガーに入れ込んでしまうとテスト、リファクタリング、読解がしづらい状況となってしまいます。 代わりに、アプリ側でビジネスロジックを管理するほうが読みやすくテストもしやすいとの主張は、今日における主流の考え方なのかなと思いました。
こうしたEF Coddの時代と現代の状況を比較した上で、スピーカーはデータモデリングにおける3つの重要な要素を主張していました。
それは①データのクオリティを高める、②スキーマ変更のしやすさ、③microservices method(one application to one database/他アプリからの直接のデータアクセスは失礼という思想)というものです。
Optimize for reads
EF Coddは（ディスクが高価であった状況等を踏まえて）書き込みに最適なモデリング手法を提唱しましたが、現在の大多数のアプリケーションはread heavyな性質を持っています。 そのため、読み取り最適化を意識することが重要と話されていました。 この思想だと、例えばRDBMSの顧客テーブルに「現在処理中の注文リストをもったJSONカラム」があっても良いじゃないか！という主張でした。 この主張は名著SQLアンチパターンに掲載されているアンチパターンですが、スピーカーの思想に基づけば合理的な判断だなとも思いました。
データの一貫性については、DBの責務ではなく、アプリ側の責務という考え方も興味深かったです。 「注文合計金額」といったカラムの更新漏れチェックはアプリ側のテストに盛り込むべきと主張されていました。 Optimize for readsの思想にのっとって、非正規化を恐れない。そして、冗長なデータの更新責務はアプリとアプリ開発者が背負うべきとのことでした。
microserviceについては初心者向けの本を1冊読んだ程度でしたが、もっとこの思想について学ぶ必要があると痛感したセッションでした。
Optimize for network
「create schema for the network, not for the disk」という主張に拍手が沸き起こっていました。 昨今のモダンな設計におけるボトルネックはディスクよりもネットワークにあるため、ネットワーク最適化を意識したスキーマデザインが必要であるとのことでした。 ここも自分にとって新鮮すぎる考え方だったため勉強にはなったのですが、知識不足で具体的なイメージまでは湧きませんでした。
アツい質問
「モノリシックな大きいシステムをクラウドにもっていくのは金銭的なコストがかかるのでは？」という質問がでました。 「コストは問題じゃない。クラウドのほうがオンプレよりもはるかにテクノロジーの進歩が速く、それらを常に使える状態になるほうが経営上のメリットがある」との回答に拍手が起きました。 これは自分でも実感がありまして、オンプレ環境だと2019をプロダクション環境で使えるのは数年に1度のシステム更改時となります。 そのため、強力な機能が存在するのにバージョンの都合で使えないのはもったいないと感じました。（※弊社にはクラウド環境もオンプレ環境も存在しています。）
Session：Into the Future with In-memory OLTP
SQL Server界隈で超有名なKalen Delaney氏によるIn-memory OLTPに関するセッション。 30年以上SQL Serverに関わっているレジェンドらしいのですが、Microsoftで働き始めたのは半年ほど前から、という謎の経歴の持ち主でした。 セッションの詳細は割愛しますが、「プロダクション環境でIn-memory OLTPを使っている人？」という問いに対して挙手したのが会場全体の1％程度だったのがかなり印象的でした。 In-memory OLTPは、効果は絶大なものの制約が多く、使いどころが非常に難しいイメージがありました。 世界中から集まったDBA達の中でも、やはりプロダクション環境での使用例は少なく、実装のハードルは高いようです。
Session：Hash Match, the Operator
Hash Matchの話題だけで2.5時間という超絶マニアックなセッションでした。PASS Summit 2019で唯一のLevel=500(最上級)ということもあり、せっかくなので受講してきました。 ドキュメント化されている情報ではなく、スピーカーが実験の結果たどり着いた結論だそうで、実験の複雑さに圧倒されました。
Call For Speakers 落選理由の分析
PASS Summit 2019に、私も「Trouble Shooting And Performance Tuning On High Traffic EC Site」というタイトルで応募したのですが、落選しました。 そもそも私の英語力ではセッション途中のQ&Aなどに対応することが難しく、現状では無理な挑戦であったなと感じています。 ただ、なぜ落選したのかについては、現地でセッションを受ける中でわりと明確になってきたので、書いておこうと思います。
理由1. PASS Summitの文脈を理解していなかった
どういった内容のセッションが多いかは、カンファレンスごとに違うと思います。 PASS SummitはSQL Serverの特定機能についての洞察や、クエリチューニングに特化したセッションなど、1トピックに対して深堀するセッションが多いように感じました。 そして、それは受講者にとっても大変聴きごたえのあるものでした。 一方で、私が応募した内容は、SQL Serverの複数の機能を使って特定の問題を解決した、という事例紹介でした。 したがって、PASS Summitではウケの良くない内容だったなと感じました。
理由2. PASSコミュニティへの貢献がまったく無かった
応募の際は、最低でも3回の登壇経験を求められます。 PASSコミュニティでは、「SQLSaturday」という小規模な勉強会も定期開催されています。 SQLSaturdayの登壇経験を積んだ後、PASS Summitで話すという流れの人もいるようでした。 「PASS Summit is a large SQLSaturday」といわれており、コミュニティの小さなイベントとPASS Summitは一続きになっている印象を受けました。 積極的にSQLSaturdayで登壇している人は、PASSコミュニティでウケる内容も自然と理解でき、採択されやすかったのではと思います。 ということで、SQLSaturdayで早速登壇したいと思ったのですが、日本のローカルコミュニティが無いようです。。！自分で作るしか。。ないかな。。！
以上2つの理由が、私が落選した理由だと分析しました。 内容的には初心者向けのセッションもあり、「いかにコミュニティへ貢献できる人物と内容か」ということが大事なのかなと思います。 来年再挑戦するかは迷うところではありますが、いずれ登壇したい、という大きな目標が一つできたことは良かったです。
カンファレンス参加の意義
国内外に関係なく、自分の興味分野における最先端、最大規模のカンファレンスであれば、参加する価値は十分にあると思います。 コミュニティの中に自分を置き、熱量を肌で感じ取り、数日間インプットだけに集中できるのも、セッション動画を見るのではなく直接参加することのメリットだと感じました。 コミュニティのレベルが上がると、自分のレベルも引き上げられます。そして学んだことをコミュニティに還元することで、さらにコミュニティが強くなっていきます。 PASSはこの正のサイクルがうまく回っているコミュニティだと強く感じました。 今までは、Qiitaの記事や会社のテックブログ、勉強会での発信をなんとなく大事だとは思っていたので継続していました。 ただ、カンファレンスに参加したことで、アウトプットは巡り巡って自分のためにもなるという確信を持つことができました。 この変化が、自分にとっては一番大きな成果物だったかもしれません。とても良い経験をすることができました。
あわせて、普段と違う環境で大量のインプットをすることで、新しいことを学ぶだけでなく、新しい行動を起こしたくなるというのもメリットかと思います。 例えば、私の場合は「コミュニティ」が新しいキーワードとなりました。 ベンダに関係なく、RDBMSやデータストレージに関するエンジニア達がお互いの知識を共有し合い学び合えるコミュニティが日本にあればいいのに、と強く思いました。 思うだけでなく、実際に自分でつくるところまでつなげていきたいと思っています。
最後に
カンファレンス参加に関わる渡航費・宿泊費などは全て会社に負担していただきました。 自分で希望すれば参加する機会をいただけるZOZOテクノロジーズという会社には本当に感謝です！ エンジニアの成長を全力で応援してくれる姿勢を、この支援制度からも感じ取ることができました。
ZOZOテクノロジーズでは、一緒にサービスを作り上げてくれる仲間を募集中です。ご興味のある方は、以下のリンクからぜひご応募ください！
