毎年恒例の db tech showcase に今年も参加してきました。 DB界隈のみなさんと情報交換できて非常に有意義でした！
以下、参加したセッションのメモ。書き間違いとかニュアンスの違いあったらごめんなさい。
1. Spanner 内部シャーディング 徹底解剖 2025
Spanner の最新情報
Spanner はRelational モデルだけでなく複数のデータモデルに対応してきた
全文検索もできるようになりました！
分散DBにとってシャードとは
分散DBはテーブルを分割し、複製する
- 分割 → 性能向上
- 複製 → 可用性と耐障害性のため
シャーディング（分割）と複製（レプリカ）はあらゆる場面で使われきた
- 伝統的なデータベース(MySQL/PostgreSQL/Oracle etc)でも
分散DB と従来の「シャーディング＋レプリカ」の違い
- 単一エンドポイント
- 完全同期レプリケーション（強整合）
Tablet, Shard, Partition, Region, Range, Chunk など内部的なシャードの名称はいろいろ
- Spanner では Split と呼ぶ
Spanner の Split の基礎
Split ごとに同期レプリケーション（Paxos ベース）をしている
- Leader は異なるゾーン（AZ) に分散配置され、耐障害性が確保されている
Spanner の「サーバ」とは
- Spannerを1ノード増やすと3サーバ追加される
- サーバはVMではなく軽量なコンテナ
- Splitはサーバに割り当てられる、1つのサーバは1つ以上の Split の面倒を見る
Split はサーバ間を移動可能
- 負荷の高いサーバから低いサーバへ割り当てが変更される
- SplitはColossus(共有ストレージ)に置かれる、サーバに直接保存されるわけではない
- 実際にデータが移動するわけではない
Split とは何か？
テーブルのデータは Primary Key の辞書順で並んでいる
- Split は テーブルの特定のレンジを切り出したもの
- Split のレンジは均一ではない
分割する境界を Split Point と呼ぶ
スプリットはテーブル単位でできる？
- No
- DB内の全てのテーブルを結合したものを分割する
- テーブルとテーブルをまたがった Split が出来ることもある
- 作りたてのテーブルには分割点がないため、複数テーブルであってもSplit は 1つ
Split の変化の契機
SQLプロファイルの並列数から Split 数が推定できるウラワザがある
Split の 移動
- Split とサーバの割り当ての変更
- 軽めの処理
Split の 分割
- いわゆるリシャード
- 比較的 重い処理
- ロックを一瞬取って、分割する
- Tail latency が若干高くなる
- 自動リトライでカバーされるため、エラーにはならない
- 自動分割
- 負荷ベース
- 手動分割
- 初期ローンチ時などあらかじめ負荷のため Split を細かく分割しておきたい場合に利用
Split 統計
- 各 Split の負荷（スコア）が見れる画面
- スコア50以上は分割される候補
- 単一スプリット
- ホットスポットが生じていて 1 行だけの Split となった状態
手動分割
- 1ノードあたり、20個を目安に事前に分けておくと良い
Split の 結合
- Split の有効期限 は 2日
- 再結合可能になる期限
- 必ず結合されるとは限らない
手動の大量分割・移動には時間かかる
- Spannerはゆるやかに Split を分割処理しようとする
- ドキュメントでは 7日~12時間前までに実行開始しましょう と書かれている
感想
@takabow さんのセッション。いつもどおり、わかりやすく、スッと入ってくる説明でした。Spannerは非常に賢く Split を管理していて、もしもホットスポットが発生するような設計をしてしまっても、それなりの規模までなら耐えられてしまう印象を受けました。このあたりの肌感覚を得られたのは大きかったです。
2. Amazon Aurora DSQLの仕組みと特徴
事実上無制限のスケーラビリティ
- コンピュート / コミット / ストレージ は個別に拡張できる
コンピュートの READ / WRITE の比率も動的に変更できる
DSQLのエンドポイントはVPC の外にある
- VPC のNW制限をケアする必要なし
認証はIAM認証のみ
インフラ管理の排除
- エンドポイントしか見えない
- インスタンスを管理する必要はない
アーキテクチャ
- フロントエンド
- クライアントからの接続を終端するレイヤー
- クエリープロセッサー
- PostgreSQL に由来し、クエリーを処理するイヤー
- ADJUDICATOR
- トランザクション間競合を検知するレイヤー
- ジャーナル
- トランザクションログを管理するレイヤー
- クロスバー
- ストレージ
- 読み取りに最適化されたストレージエンジンレイヤー
書き込み時の動作
COMMIT を打つと ADJUDICATOR へ情報が連携される
- 競合の検知
- 競合したらCOMMITがABORTする
ジャーナルに書き込んだら、クライアントにCOMMIT OKが返る
- ストレージに書き込む前に、クライアントにOKが返る
読み取りの動作
クエリープロセッサーが直接ストレージを読む
- ADJUDICATOR,ジャーナル,クロスバーは読み取りの際は利用されない
ジャーナル にしかない（ストレージにまだ書かれてない）データは抜けるのでは？
- 対策がしてある
- ストレージは今どこまでトランザクションが適用されているか知っている
- 必要に応じてジャーナルから書き込まれるのをごく一瞬待ってから、応答する
ビジネス継続性 - 可用性
- アクティブ・アクティブのマルチリージョン構成も可能
シングルリージョン構成の場合も、マルチAZ構成で高い冗長性
バックアップ
- AWSバックアップサービスでバックアップする
メジャーバージョンアップ
- 方法は未定だが、ダウンタイムは発生しない
- メジャーアップのタイミングはコントロールできる
分散データベースとしての性能最適化やトランザクションの特徴
トランザクション開始〜コミット直前までは、リージョン内/AZ内の通信で完結する
- COMMITされたら、リージョン間で通信して整合性をとる
読み取りはローカルコピーから読み込まれる、リージョンやAZをまたがない
トランザクション分離レベル Snapshot Isolation (PostgreSQLのRepeatable Read相当) をサポート
- たとえ、Read Commited にしたとしてもDSQLにおいては恩恵はない
料金
- DPU (Distributed Processng Unit)
- 机上での見積もりが難しい...
- 1行70byteの単表に対してワークロードを流した料金：
- 5000 PK SELECT/sec, 50 q/sec * {INSERT,UPDATE,DELETE}
- 24h で $26 @ 東京リージョン
- Storage (GB-month)
- Data transfer / Backup and Restore
トランザクション管理
OCC (楽観的同時実行制御)
- UPDATEやINSERTでロック待ちは発生しない一方
- COMMIT 時点で ABORT が発生する
カタログキャッシュ
感想
新久保さんのセッション。初めてDSQLの詳しい話をききました。アーキテクチャの詳細が知れて非常に参考になりました。 アーキテクチャの違いが既存の分散DBと比較したときに、どのような差として現れてくるのか、今後、より調査してみたいところです。 本題からはずれるんですが、「DSQLはIAM認証のみをサポート」というのを聞いて、今後、IAM認証を標準的に利用していく必要性を感じました。
3. 河合塾が抱えていたDB運用におけるジレンマの改善 〜DBの可視化で何が変わったのか？〜
データベースの運用課題
統合DBに負荷が集中
- 受付、塾生ポータル、校舎業務系...
2022/04月から慢性的にCPU負荷が高い状態に...
負荷対応に工数・時間がかかってしまう
- AWRレポートの発行だったり、ログ取りといった、煩雑な手動作業
課題に対するアプローチの検討
現状課題：トラブルシュートの手間を減らしたい
- ありたい姿： ログの収集や保全を自動的に行える
現状課題： 一部ログやメモリ上のデータなどは情報が一定期間で消失してしまう。過去の運用情報が把握できない。
- ありたい姿： 長期間データを保全できる仕組み
現状課題：時間解像度が低い
- ありたい姿：高頻度に情報を収集したい
比較検討
- Oracle Diag Pack、 Oracle Stats Pack
- 可視化のIFがない
Database Performance Analyzer
- SQLで取れる情報しか扱えない
-
- 時間解像度が高い（秒単位）
- メモリから直接情報を収集 (Direct Memory Access)
- 買い切りライセンスモデル
MaxGaugeを導入して解決した課題
稼働状態が時系列で見える化できた
- 前回との比較、先月との比較、といった傾向分析もできるようになった
感想
わかりやすい説明で、可視化の重要性を再認識できました。 メモリから直接情報を収集できるのはすごい (Oracleはソースコードが公開されてないのに、どうやって実現しているんでしょう！？）。 プロセスがハングアップしてても情報収集できるとか。
4. Aurora Audit Log 深掘り実践 〜Insight SQL Testing を通じた運用改善への道〜
Aurora 3.0 バージョンアップ対応
150クラスターのv2→v3のバージョンアップを完了
バージョンアップを支えた内製ツール
- DB Catalog
- Schema などの情報をためているレポジトリ
- カスタムアップグレードチェッカー
- mysqlsh の upgrade_checker をベースに自社独自の視点を追加
- DB Catalog
アップグレードチェッカーをプロダクトサイトに提供
- DBREはあくまでもリアクティブに対応する方針で進めていた
プロダクトサイドからは専門家（DBRE）により踏み込んだチェックをしてほしという要求があった
- クエリリプレイのソリューションを検討した
Insight SQL Testing
Audit Log をリプレイするソリューション
移行元と移行先、両方にクエリを投げて比較してくれる
- エラー検知
- パフォーマンス劣化の検知
3.3億行をリプレイした
- 問題があると検知されたクエリ：486万クエリ
減ったとはいえ 486万クエリもある
対応が必要なクエリを絞り込む作業をした
Aurora Audit Log とは
- Aurora Audit Log は MariaDB Audit Plugin ベース
- メリット
- Aurora 標準機能で機能利用に追加コストなし
- AWS Console 、 IaC で管理できる
- セキュリティ監査への対応
デメリット
- クエリ全文が記録されることによる個人情報リスク
- ログの保管コスト
活用例
- Retcode
- 0 以外を検索してトラブルシュートに活用
- Connection ID
- その時間のセッション数を類推できる
- 該当セッションの継続時間
- Retcode
Audit Log の出力順序は保証されない
- QUERY, CONNECT, DISCONNECT みたいな矛盾した順番で出てくることもある
- パースするときに注意が必要
Insight SQL Testing への連携方法
- S3 へ 時間指定して export
- SQL Testing に取り込める形式（CSV)に変換するツールが提供されている
- ログの境目で CONNECT/DISCONNECT がぬけてるケースもちゃんとハンドリングされている
Audit Log を活用した内製ツール
Audit Log に向き合ってみて、普段の運用にも活用できそうだと思った。
Audit Log をパースして MySQL に入れるツールを作成
- 分析ができるようになった
利用例
- 1本あたりのクエリのコストを見積もるのも出来そう
正確な情報を把握する重要性
- プロアクティブな活動をするためにも必要
感想
@_awache さんのセッション。あわっちさんの人柄あふれる内容で、自分も「プロアクティブにプロダクト側を支援していかなかくては。」と感じさせる内容でした。
5. Aurora から Spanner へ Time Tree
移行の背景
- データ量の継続的な増加
Aurora の様々な上限に達しそう
利用状況
- 65 Million User, 27 Billion Records
将来を考えるとさまざまな上限が不十分
プロジェクトのタイムライン
- 2018: 課題認識
- 2019: チーム内で課題共有
- 2021/06: クリティカルな課題して社内共有
- 2023/01: プロジェクト稼働開始
- 2024/01: 移行作業開始
- 2025/01: 移行完了
Spanner に決めた理由
- フルマネージド
- Google での運用実績
- オートスケーリング
- 他の Google Cloud サービスとの連携
- Google Workspace との連携
- Google WorkspaceのIDでSpannerへのアクセス管理ができる
Pre マイグレーション
MySQL アップデート (Aurora v2 → v3）
スキーマ整理
- Spannerでインターリーブを利用予定だったので、親子関係を設定できるようにカラム追加
クレンジング
- 移行に向けて不要なデータの整理
マイグレーション
spanner-migration-tool (SMT) を利用した
自動的にデータ移行のパイプラインが作成される
- DataStream -> Cloud Storage -> PubSub -> ComputeEngine -> Spanner
SMTのカスタムロジック
MySQLのAUTO_INCREMENTを利用していた
- Spanner へ移行するにあたり、 AUTO_INCREMENT に Bit Reverse Seq を適用する必要があった
- SMTで用意されているDataflowにカスタムロジックを入れた
しかし、SMTでは親子関係が考慮されずにエラーに
- → Google から改良バージョンが提供されて解決
SMTの新バージョンに不具合があり、実際は従来のバージョンで移行した
- SMTの新バージョンに問題があった場合に備えていた
- 従来のSMTを読み解いて、親子関係を考慮したものをバックアッププランとして事前準備
移行後
運用コスト
- ゼロになった
- バージョンアップも自動で勝手にやってくれる
- オートスケール
サービス開発コスト
- 学習コストが増
金銭的コスト
- 若干増加したが、運用コストを考えるとトータルコストは削減できた
セキュリティ
- Google ID との連携により改善
パフォーマンス
- Spanner のシャーディングによるレイテンシ劣化は影響なかった
タイミング
- サービスで様々な企画が進められる前に実行できてよかった
社内文化への影響
- SpannerはGraph や 全文検索など様々な検索ができる
- Spannerの勉強会を実施し、結果的にエンジニアがより積極的にサービス改善に関わる文化が情勢されてきた
感想
Time Tree 金井 さんのセッション。 プロジェクトマネージメントやステイクホルダーとの目線合わせなど、技術的な部分以外の重要性も認識させてくれる内容でした。
LT
DBA/DBREしくじり先生 ～やっちゃったな実録集～
@tomomo1015 さんの過去のやらかしの振り返りLT。１つ１つの事例をサクッと説明されてたんですが、実際はもっといろいろあったんだろうな... と感じるLTでした。どこかでもっと詳しく話してほしい（笑）
DBのスキルで生き残る技術 - AI時代におけるテーブル設計の勘所
@soudai1025 さんの説明はいつも、心に刺さるんですよね。ということで、ワールドトリガーを読み始めました（おい）
