オフラインとしては 2019/5/18 の松江以来、オンラインを含めると 2021/4/2 の自分の登壇回以来の中国地方 DB 勉強会参加でした。
前日
広島まで新幹線で移動し、在来線に乗り換えよう…と思ったら、急病人対応で遅延。
昨晩は山陽線が遅れてヒヤヒヤしながら岩国着（ホテルのチェックインには間に合った）。
— hmatsu47(まつ) (@hmatsu47) 2024年5月25日
なので写真はなし。
なんとか間に合いました。
錦川鉄道の旅
無料提供の朝食のパンとサラダを少しだけ食べて、6:30 過ぎにホテルを出発。
JR 岩国駅の改札を通り過ぎて、0 番線ホームへ。
そして本日は錦川鉄道へ。 pic.twitter.com/NuU7QK5fNK
— hmatsu47(まつ) (@hmatsu47) 2024年5月25日
岩国〜川西間は JR 岩徳線なので別料金、というわけで。
結果的に割引にはならないけどフリーきっぷを購入。 pic.twitter.com/vvNLOqkQCW
— hmatsu47(まつ) (@hmatsu47) 2024年5月25日
普通に川西〜錦町間を往復するより 40 円ほど高くなりますが、記念のため 1 日フリーきっぷを購入しました。
錦川鉄道はその名のとおりほぼ全線錦川沿いを進みます。
車窓風景。 pic.twitter.com/KSOvVX66pv
— hmatsu47(まつ) (@hmatsu47) 2024年5月25日
錦町に到着しました。
錦町駅に到着。 pic.twitter.com/0WHY4WMEL6
— hmatsu47(まつ) (@hmatsu47) 2024年5月25日
この日は駅併設の観光・鉄道資料館が休みで、周辺の「まちぐるみ博物館」も開いていそうな雰囲気ではなかったので、地域のマイクロバスで中学校前まで移動し、そこから平瀬ダムまで徒歩で移動しました。
最近できた平瀬ダムに向かう。
— hmatsu47(まつ) (@hmatsu47) 2024年5月25日
ちょうど地域のバスがあったので途中までバスで。
その後は徒歩。 pic.twitter.com/FAQeBaRN9e
途中の分かれ道でダムの右岸（近いけど細い山道）を行くか左岸（遠いけど途中まで広い国道）を行くか迷いながら、熊が出たら嫌なので左岸を行って正解でした（右岸はダム下で管理事務所まで遠かった）。
9時までダム観察（？） pic.twitter.com/4eXSPP7BQg
— hmatsu47(まつ) (@hmatsu47) 2024年5月25日
9 時過ぎにダムカードをもらって駅まで引き返しました。
時間は掛かりましたが歩ける距離でした。駅から歩ける距離にあるのにこれだけ大きなダムは珍しい気がします。
↑からバスと特殊な鉄道路線を除くと 1/3 くらいまで減りますね。
駅に戻る。
— hmatsu47(まつ) (@hmatsu47) 2024年5月25日
残念ながら待合室の売店は10時まで開かない模様。
そのまま列車に乗る。 pic.twitter.com/hvMwq3stb2
川西まで戻って錦帯橋へ。
時間がないので橋だけ往復。
時間がないので橋を渡って戻るだけ。 pic.twitter.com/jjEnvpl2rC
— hmatsu47(まつ) (@hmatsu47) 2024年5月25日
橋の下から。 pic.twitter.com/FOJqnB1geG
— hmatsu47(まつ) (@hmatsu47) 2024年5月25日
少しだけ腹ごしらえした後、高速バスと市電を乗り継いで広島の勉強会会場に向かいました。
第 34 回 中国地方 DB 勉強会 in 広島（セッション編）
Amazon RDS / Amazon Aurora パフォーマンスチューニングとモニタリング（藤原さん）
このセッションを聞いたからといってすぐにチューニングができるわけではないですが、「Performance Insights を使ってみよう」というきっかけ作りにちょうど良いお話でした。
DBがいっぱい。#ChugokuDB pic.twitter.com/neq9Pxtj62
— hmatsu47(まつ) (@hmatsu47) 2024年5月25日
このラインナップのうちの一番左が今回の対象です。
MySQLの場合ロックの「犯人」がPerformance Insightsではわからない（巻き込まれた側しかわからない）、って話を先日のMySQLアンカンファレンスでやってたな。#ChugokuDB
— hmatsu47(まつ) (@hmatsu47) 2024年5月25日
RDBMS にもよりますが、MySQL にはこんな罠があるので Performance Insights 以外を組み合わせて使う必要がありますね。
むかしこのへん↓の話を中の人にしたら、その後改良されて対象の数を増やしてくれた。https://t.co/nxsYi26DKS#ChugokuDB
— hmatsu47(まつ) (@hmatsu47) 2024年5月25日
このあたりは「順位の低いものを頑張って表現しても価値が低い」という割り切りでしょうね。
SQLにコメントを書いておくとPerformance Insights のSQLにも載ってくるので、便利.
— ikkitang (@ikkitang) 2024年5月25日
（例えば、こういうControllerから呼ばれてるとか）#ChugokuDB
SQL 文の本体が長すぎる場合は、後ろのほうが切られてしまって結局表示されないこともありますね…。
PostgreSQLならRLS使ってくれ案件。#ChugokuDB pic.twitter.com/10hqjinfhL
— hmatsu47(まつ) (@hmatsu47) 2024年5月25日
「知らないから無邪気にやっちゃう」というのはどんな技術でもありがち。
OR マッパを使ってる場合の監視とパフォーマンスチューニング（三戸さん）
つぎは三戸さん。
— hmatsu47(まつ) (@hmatsu47) 2024年5月25日
ORMやクエリビルダー使ってると実行されたSQLとの突き合わせ大変そう。#ChugokuDB pic.twitter.com/xVtMmtF1Qq
古の Hibernate（当時は SQL ライクな HQL はあったがクエリビルダーはなかったはず）を使っていた勢としては「そこは ORM じゃなくてクエリビルダーと表現して欲しかった」とか言っちゃうと老害認定されそうなのでやめておきました（まあ今の ORM はクエリビルダーで O/R マッピングするのが普通でしょうしね）。
2024/5/30 追記：
確かに ORM 特有の事情（クエリビルダーを使う ORM かどうかに関わらず、書いたコードと発行される SQL 文が必ずしも 1:1 で対応するわけではない点が調査の難しさを助長する）の話も含むので「ORM 前提の話」、という意図だったかも。
型安全にしたい。
— hmatsu47(まつ) (@hmatsu47) 2024年5月25日
MySQLさん「わかりました（わかってない）」#ChugokuDB pic.twitter.com/K0Qce6shgh
MySQL さん、余計なことをするw
「クエリビルドがフロントエンド側に寄る」
— かえる㌠ (@gho4d76g) 2024年5月25日
そういう考え方があるのかぁ #ChugokuDB
React Server Components / Server Actions で、フロントエンドに寄る流れが加速しそうな一方で GraphQL の採用のほうは一段落しそうです。
MySQL 5.7以降で死ぬやつだ。#ChugokuDB pic.twitter.com/4gDQIjl5dh
— hmatsu47(まつ) (@hmatsu47) 2024年5月25日
見たくないやつw
でもSQLがリストアップされてコードと突合できたとして、SQL書けない（読めない）人に果たしてチューニングはできるのか…？#ChugokuDB
— hmatsu47(まつ) (@hmatsu47) 2024年5月25日
最大の疑問点はこれ。
若い人がいくら SQL を避けても、結局やっているうちに嫌でも覚えそう（書かないにしても）。
（なお、ﾍｰｼｬでは若手もみな SQL 文を書いてます）
Why DBRE?（tomo さん）
あえて（通常とは違い）PdM からのルートで DBRE を極める話でした（解釈が間違っていなければ…）。
あなたのSREはどこから？という問いがまず必要なんだぬ #ChugokuDB
— かえる㌠ (@gho4d76g) 2024年5月25日
風邪薬っぽいですがその話ではありません。
SRE 憲章を作るのが大事。
— chanyou (@chanyou0311) 2024年5月25日
リソースは有限なので、何を成し遂げるために、どんなことに注力して実施するのかをまとめるべき。#ChugokuDB
先日SRE NEXTのCfPの駆け込みで出したとき、SREのプラクティス的なことには一切言及しなかったんだけど（事業目的に合わせた取り組みが大事ということで）、にしても「なんでこれがSREの話？」という表現が完全に欠けてたのでたぶん何も伝わらないCfPになっちゃってた…（来年頑張る）#ChugokuDB pic.twitter.com/6crVdyxajt
— hmatsu47(まつ) (@hmatsu47) 2024年5月25日
事業「目的」と書きましたが「目標」でした（「目的」からの「目標」、を端折ってしまった）。
個人的には、勉強会やカンファレンスで「SRE のプラクティスや文化」として一般に認知されているものがあまりにも先行し過ぎてしまい、事業の目的やそこから導き出された（特定時点や期間における）事業目標（≠ SLO）が置き去りにされている（ように見える）ことに違和感を覚え続けてはや◯年、みたいな気持ちになっていました。
対応する各分野の担当者が全部自分だと全部スムーズに行っちゃう（から組織にナレッジ共有されなくてダメ）。#ChugokuDB pic.twitter.com/mke9IXfgjR
— hmatsu47(まつ) (@hmatsu47) 2024年5月25日
さりとて目先の事業目標を達成するために「全部俺」をやっちゃダメ。
サービス信頼性をあげていくのはSREとかじゃなくて、何を作るかを考えるPdMから入っていくのがいいんじゃないか→PdMになる。（なるほど） #ChugokuDB
— 3kyo (@t3qyo) 2024年5月25日
個人的にはそこで PdM は目指さず「地道にチームメンバーを側方支援して育成」のほうを選んだわけですが。
（後編に続く）
