DBREの行くdb tech showcase 2024レポート

こんにちは、技術本部 SRE部 基幹プラットフォームSREチームの斉藤です。普段はZOZOの持っている倉庫システムやブランド様が触る管理ページなどのサービスのオンプレミスとクラウドの構築・運用に携わっています。またDBREとしてZOZOTOWNのデータベース全般の運用・保守も兼務しております。

7月11日、12日に行われた「db tech showcase 2024」に、DBREから5名のエンジニアが参加しました。この記事では会場の様子と印象に残ったセッションについてご紹介します！

• db tech showcaseとは
• 会場の様子
• セッションレポート
• おわりに

db tech showcaseとは

国内最大規模のデータとデータベース関連のカンファレンスです。このイベントでは、データベースの専門家やエンジニア、IT業界のリーダーたちが一堂に会し、新しい技術やソリューション、事例、ノウハウを共有します。

db tech showcaseの主な内容には以下のようなものがあります。

• 講演：データベース技術の最新トレンド、事例や実践的なアプローチについての講演が行われます。
• 展示：企業やベンダーが最新の製品やサービスを展示し、デモンストレーションします。
• ネットワーキング：業界の専門家や同僚と交流する機会が提供され、情報共有やビジネスの機会が広がります。

www.youtube.com

会場の様子

入口

db tech showcase 2024はTKP市ヶ谷カンファレンスセンターで開催されました。受付を終えるとパスが発行され、イベントのパンフレットが配布されました。

EXPO

データベースに関連する企業のブースが並んでいました。セッションの間で立ち寄ったOracle社のブースではHeatWaveの話題で盛り上がり、セッションさながらの事例や最新情報を熱弁頂きました。他にも、休憩スペースでセッションの感想で盛り上がってる人達がいたり、ミニセッションも開催されていたりしました。EXPOエリアではこうした交流が盛んに行われいて会場全体に活気がありました。

セッション

2日間で75以上のセッションが行われました。

db tech showcase 2024セッションスケジュール

その他

企業の各ブースでは魅力的なグッズを配布していました。

セッションレポート

DBREのメンバーが気になったセッションを紹介します。

• MySQLアプリケーション開発を爆速にする最新手法
• Amazon Bedrockで検証！データベース移行時のクエリ修正を簡素化するLLMの活用法
• 爆速成長中のFindyがぶつかった課題と解決に向けた実践手法
• 【出光興産様事例紹介】SAP DB運用の課題と今後の計画
• SQL Server 技術支援のための動作の調査 - dbts2024 版 -

MySQLアプリケーション開発を爆速にする最新手法

基幹プラットフォームSREチームの斉藤です。ZOZOのメインデータベースはSQL Serverを使用していますが、マイクロサービス化が進んでいるシステムではAurora MySQLを採用しています。MySQLの最新情報や運用に使用できるツールの事例などをキャッチアップすべく本セッションに参加させていただきました。

MySQLとVS Codeの統合

VS Codeで利用できるオープンソースの拡張機能として、MySQL Shell for VS Codeが提供されています。MySQL WorkbenchのEOLが迫っている中で後継となるもので、MySQLの運用には欠かせない機能になっていくのではないだろうかと思います。MySQL WorkbenchからはSQLエディタやスキーマの確認・データの検索結果の表示など主要な機能は全て継承されていると思われます。さらに「MySQL Shell for VS Code」はただのMySQL Workbenchの代わりではなく、VS Codeを使用してきた開発者とMySQL Workbenchを使用してきた管理者が共通して使用できるIDEとして設計されています。NotebookというエディタからはSQLだけではなくJavaScriptやTypeScriptを実行し結果をグラフで表示できます。これらの機能を使用してシステム開発が効率化されていると感じました。

MySQL Shell for VS Codeついては公式ドキュメント「MySQL Shell GUI / MySQL Shell for VS Code」を参照してください。

MySQLのJavaScriptサポート

MySQL Enterprise Editionの機能でストアドプロシージャや関数をJavaScriptで作成し実行できます。そのストアドプロシージャや関数は実行するSQL上でも呼び出すことができ、処理の幅が広くなりました。

MySQLでJavaScriptを使用するできるメリットは次の通りです。

• 高い表現力
• JavaScriptアプリケーション開発者向けの大規模なツールのエコシステム
• サードパーティライブラリの充実
• 人気のある開発言語の1つで、1300万人もの開発者が存在する

MySQLのJavaScriptサポートついての情報はThe Oracle MySQL Japan Blogの「MySQLのJavaScriptサポートについて」で詳しく紹介されております。

MySQL REST Service

MySQL REST ServiceはMySQL Routerの拡張機能として提供されています。RESTを使ってHTTP経由でMySQLのデータを参照、更新ができます。MySQL Shell for VS Code上から設定し運用します。

基本的なアーキテクチャ
画像引用元: The Oracle MySQL Japan Blog「MySQL REST Serviceの紹介」

MySQL REST Serviceついての情報はThe Oracle MySQL Japan Blogの「MySQL REST Serviceの紹介」で詳しく紹介されております。

感想

MySQLは「MySQL Shell for VS Code」やJavaScriptサポート、「MySQL REST Service」などの最新機能により、開発効率と運用性が大幅に向上し、現代のアプリケーション開発に重要なソリューションへと進化を続けていると感じました。

Amazon Bedrockで検証！データベース移行時のクエリ修正を簡素化するLLMの活用法

カート決済SREの遠藤です。

DBのバージョンアップや異なるDBへリプレースする際、クエリの互換性が課題になることがあります。この課題に対し、昨今注目されるLLM（大規模言語モデル）を活用してクエリの修正工数を減らせるかの検証デモが行われました。

現在、ZOZOTOWNで利用しているSQL Serverのサーバー分離とバージョンアップを担当しており、LLMを使ったクエリ修正に興味がありこのセッションに参加しました。

内容

異なるDBMS製品への移行や、バージョンアップに伴うクエリ修正の例が5つほど紹介されました。まず、何も工夫をせずLLMに対してクエリ修正を指示した場合、半分以上が間違った回答でした。こうしたハルシネーション（生成AIの嘘）を防止するために、よくある工夫をプロンプトに取り入れることで精度が向上しました。

• クエリ互換性に関する内容であることの記述
• 専門家としての視点の強調
• 思考の連鎖を促す指示（step by step）
• 事例の提供（Few-Shotプロンプティング）

また、RAG（検索拡張生成）としてAmazon Bedrockを使い、DBMS製品の公式リリースノートをナレッジベースとすることでさらに精度が向上しました。

Bedrockの場合、ナレッジベースをS3に格納するのですが、以下のような加工をすることでさらに精度が向上しました。

• リリースノートからSQLの互換性に関係のない記述を削除
• Markdown形式に変換

最終的に、5つのデモ全てにおいてクエリを正しく修正できていました。100％の精度は保証されないものの、LLMはSQL変換タスクにも有用であり、修正工数を大幅に減らすことができそうです。

感想

ChatGPTをはじめとしたLLMはすでに業務で活用していますが、ここまで具体的にDB移行業務に活用できる例を見ることができ、新たな発見がありました。LLMでは100％正しい回答が得られるとは限らないため、人力でのチェックは必須です。そこでRAGを利用することにより、ナレッジベースを元に回答の根拠も示してくれるため、ハルシネーションが発生しても比較的簡単に正当性を判断できそうです。

今回のセッションではOracleDBからPostgreSQLへの移行でしたが、弊社ではSQL ServerやMySQLを採用することが多いためそちらでも試してみたいと思いました。また、弊社ではテーブル設計ガイドラインを作成し、日常的にDBREがテーブル設計レビューを行っています。ガイドラインをナレッジベース化することで、テーブルのCREATE文を元に一次レビューを自動化できるかもしれません。

アプリケーション開発ではGitHub CopilotをはじめとしたLLMによる開発のサポートが既に充実しています。しかし、今後SQLの開発にも同様のことが行えるようになり、DBA/DBREの働き方も大きく変わってくると感じました。

爆速成長中のFindyがぶつかった課題と解決に向けた実践手法

基幹システム本部・物流開発部の黒岩です。

普段はZOZO社内で使用している基幹システムのリプレイスをする傍ら、DBREとしても活動しています。db tech showcaseは今回初めての参加でしたが、どの発表も内容が幅広く、興味深いセッションが多かったです。

私はファンディ株式会社 @gessy0129 げっしーさんの「爆速成長中のFindyがぶつかった課題と解決に向けた実践手法」というセッションについて紹介します。

DB面での課題と解決方法

サービスが急成長し、多くのユーザーに使われていく中で直面したDB面での課題とその解決方法が紹介されました。

性能問題	解決方法
DB負荷が高まり、CPU使用率が上昇	RDSからAuroraに移行してリソース利用を効率化
	AuroraをARMベースのインスタンスに変更し、同じ性能をより低コストで実現
SQLのレスポンスが悪化	Performance Insighsを活用してクエリパフォーマンスを把握し、ボトルネック箇所を可視化
	クエリの実行計画を分析して足りないインデックスを特定、インデックスを追加
	インデックスが使われないクエリの形を修正（例：IN句の中に大量のデータが入っている、LIMITの数が適切でない場合など）

DBエンジニアとアプリケーションエンジニアの協力

セッションで印象に残ったのは、スピーカーのげっしーさんが言った「性能試験は総合格闘技」という言葉でした。この言葉通り、DBエンジニアだけで解決するのではなく、アプリケーションエンジニアと密に連携して問題解決に取り組んだ例が紹介されていました。具体的には、以下2つの取り組みが印象的でした。

ReaderとWriterのインスタンスノードの振り分け

AuroraのReaderインスタンスが有効に活用されていない課題に対して、DBエンジニアとアプリケーションエンジニアがペアプロしながら解決した事例です。DBエンジニアがReaderインスタンスの役割や性能向上の仕組みを説明し、アプリケーションエンジニアがその知識をもとにアプリケーションコードを改修して、書き込み操作時にはWriterインスタンス、読み込み操作時にはReaderインスタンスへ分けるようにしたそうです。これにより、読み込み処理時にReaderインスタンスが使われるようになり、効率的な負荷分散を実現したとのことでした。この取り組みでは、両者がそれぞれの専門知識を共有し、リアルタイムでコードの変更とその効果を確認しながら進めたことが成功の鍵となったそうです。

アプリケーションコード内のクエリ最適化

もう1つの課題として、より複雑な処理をクエリで一括処理するか、データを分割して取得した上で、アプリケーション側で処理するかという課題があったそうです。ここでも相互にペアプロなどで検証しながら性能を検証し、例えば「MySQLが苦手とする集計処理」について、クエリで一括処理していた部分を一部アプリケーション側で処理することで、DBの負荷を軽減した例が紹介されていました。

感想と今後の取り組み

このセッションを通じて、DBエンジニアとアプリケーションエンジニアの協力がDBの負荷軽減において非常に重要であることを再認識しました。現在、弊社でも基幹DBの負荷軽減を図るためにクエリチューニングを進めていますが、この取り組みはまだ効果が限定的です。今回のセッションで学んだように、DBの性能課題に真摯に向き合い、基幹システムに関わるチーム全体で性能問題解決に取り組む姿勢を大切にし、今後もさらなる協力と改善を進めていきたいと思います。

【出光興産様事例紹介】SAP DB運用の課題と今後の計画

基幹システム本部・データ連携ブロックの馬場です。現在ZOZOTOWNの基幹システムで使用しているデータベースの性能改善を課題としています。

社内システム統合時に発生したデータベースのスローダウンに対し、どのようなツールを利用し課題対応しているか、という事例紹介のセッションに参加しました。

MaxGauge

スローダウンが発生しているボトルネッククエリを調査すべく、データベース監視ツールである「MaxGauge」が紹介されました。「MaxGauge」はデータベースサーバにエージェントを導入することで、リアルタイムにSQLのトラッキングを行い、蓄積されたトラッキングデータにより、パフォーマンス低下対象の事後分析が可能です。

弊社ではDPMツールとして「Datadog」を導入していますが、情報収集に掛かるデータベース側への負荷や、クエリの取得間隔等を比較してみたいです。

MAJESTY

次にデータベース開発支援ツールの「MAJESTY」の紹介です。パフォーマンスが低下しているクエリに対し、最適なインデックス設計をアドバイスしてくれることで効率的に性能分析・改善が可能です。最大の特徴は「アクセスパターン分析」を実装しており、テーブルへのアクセスをパターン化し、最適なアクセスパスを分析することです。これにより、SQL単体を分析する手法よりも大幅にコストを抑えた性能改善が実現可能です。

感想

今回の事例ではSQL Serverを利用し、基幹システムに性能問題を抱えている境遇が弊社と似ているため参考になるセッションでした。

チューニングを行うにはデータベースに対し一定の習熟度が必要になりますが、社内のエンジニア全員が同じ習熟度を保つことは難しいです。本セッションで紹介されたツールを導入することにより、誰もが同じ視点で性能改善を実施し、日々の性能改善コストが大幅に削減できる環境が作れると良いと思います。

SQL Server 技術支援のための動作の調査 - dbts2024 版 -

技術本部SRE部カート決済SREブロックの伊藤です。

こちらのセッションはMicrosoft MVPの小澤さんが、SQL Serverの挙動について、実演を交えて調査方法を紹介してくれるセッションとなっていました。例えば、クエリストアや拡張イベントを有効化する場合にクエリのスループットにどの程度影響が出るかをどのように調べるか、といった内容です。

内容が濃密なこともあり、事例全てを紹介していただくことは時間の都合上できませんでしたが、会場を巻き込んで挙手制でアンケートを取りながら紹介事例を選ぶ姿は、オフラインイベント感を感じる一幕でした。

事例の中で私が最も印象に残ったのは「オンラインでのインデックス再構築による同時実行性の低下の有無」です。

オンライン再構築による同時実行性の低下の有無

SQL Serverではオンラインでのインデックス操作に対応しています。

ONLINE オプションは、このようなインデックス操作中に基になるテーブルまたはクラスター化インデックス データ、ならびに関連付けられた任意の非クラスター化インデックスへ同時ユーザー アクセスを可能にします。 たとえば、あるユーザーがクラスター化インデックスを再構築している最中に、そのユーザーと他のユーザーが基になるデータの更新やクエリを続行できます。

引用元: オンラインでのインデックス操作の実行

この時に、ロックは一切かからないのかを解説交えながら検証の実演が行われました。具体的には以下のような手順です。

1. 長時間かかるようなSELECT文を実行する
   • SSMSから実行するときには結果を出力しないようにクエリオプションで破棄する設定にしておく
     • 
   • この時sys.dm_tran_locksなどでロックの状況を確認すると共有ロックがかかっている状態が見られる
2. バックグラウンドでSELECTを大量に実行しておく
   • Ostressを使うことで並列に大量のクエリを流し続けておくことができる
3. REBUILD INDEX WITH(ONLINE=ON)を実行する
   • 最終段階でSch-Mのロックが必要になるため1の処理と競合してロックの解放待ち状態となる
   • この時に2で実行していたクエリをブロックする可能性がある
     • 発生の有無はロックパーティションの状態次第
     • CPUのコア数で挙動が変わる部分でもある
   • ロックタイムアウトの活用でブロッキングの連鎖は防ぐことができる

後日実際に自分の環境でも試してみた

上記の内容を改めて実際に試してみました。これは過去にオンラインでインデックス作成が行われた際にブロッキングの発生を観測したことがあり、ユーザーに影響するものなので対策含めて運用ドキュメントに取り入れていきたいという思いがあったからです。

実際に流したクエリは以下の通りです。

-- 長時間かかるSELECT文
SELECT a.SampleColumn FROM _testTable AS a
CROSS JOIN _testTable AS b

-- Ostressから実行したバックグラウンドで動かすSELECT文
SELECT TOP(1) * FROM [dbo].[_TestTable] tablesample(1 percent) WITH(NOLOCK)

-- インデックスのリビルド
ALTER INDEX [IX__TestTable_SampleIndex] ON  [dbo].[_TestTable] REBUILD
WITH(ONLINE=ON)
GO

上記のクエリをそれぞれ流したところ、インデックスリビルドの最終段階でSch-Mのロック要求が発生していることを確認できました。

sys.dm_tran_locksから確認したロック情報

Datadogが入っている検証環境ということもあり、Datadogからも確認したところ、ブロッキングが連鎖してOstressで流していたクエリも巻き込まれていることが確認できました。

Datadog Database MonitoringのBlocking Queriesからのキャプチャ

これに対し、インデックスリビルド時に SET LOCK_TIMEOUT を付けて同様に再現したところロック要求のタイムアウトの発生を確認できました。インデックスのリビルドは失敗するため、改めて実施する必要はありますが、これでユーザー影響を抑えることができます。

-- 1秒ロックが取れなかったらインデックスのリビルドを中断する
SET LOCK_TIMEOUT 1000;
ALTER INDEX [IX__TestTable_SampleIndex] ON  [dbo].[_TestTable] REBUILD
WITH(ONLINE=ON)
GO

エラーメッセージが出力されて処理が中断

実演を見た上で自分でも試してみて、インデックス操作時の挙動及び調査方法への理解を深められました。インデックス操作時の SET LOCK_TIMEOUT指定の必須化などは弊社内での運用にも取り入れていこうと思います。

おわりに

今回のセッションを通じて多くの知見を得ることができました。セッション以外にも、企業ブースや他社のエンジニアとの交流を通じて、多くの学びと刺激を受けました。実際に現地に足を運ぶことで得られるものは非常に大きかったです。

db tech showcase 2024で学んだことをZOZOのデータベースシステムの向上に活かしていこうと思います。

ZOZOでは、一緒にサービスを作り上げてくれる仲間を募集中です。ご興味のある方は、以下のリンクからぜひご応募ください！

corp.zozo.com