メタデータ同期に潜んでいた問題 〜 Cache Stampede 時の Cycle Wait を⾒つけた話

2026年2月24日に開催された「YugabyteDB Japan Meetup #7」での発表資料です。

Transcript

1. © LY Corporation メタデータ同期に潜んでいた問題 ～ Cache Stampede 時の Cycle Wait を見つけた話 YugabyteDB Japan Meetup #7 LT 24th February 2026 TAKAMI Torao
2. 自己紹介 (About Me) 1 鷹見虎男 TAKAMI Torao LINE 開発 :: Messaging Platform 開発 :: Platform Storage :: Storage Lab Software Engineer ◆ 専門: ソフトウェア設計・開発 ◆ 経歴: 元金融系SI開発, JavaPress 特集, Web系開発, 分散処理基盤, ブロックチェーン開発 ◆ 興味: (構造的|確率的|分散|暗号) アルゴリズム, 認知行動科学 ◆ 趣味: 旅行, ドライブ, 映画, 文房具, コーヒー, Rust, Scala
3. ALTER TABLE … GRANT ALL PRIVILEGES ON … メタ情報更新 (DDL/DCL) YugabyteDB 検証中の出来事 高負荷トラフィック × メタデータ変更 → 全ノード沈黙 YCSB Benchmark 2 各ノード ysql_max_connections=1500 に拡張 (デフォルト 50-300) 想定接続数: 1000 接続/ノード [検証の目的] 一般に、大量のデータと高トラフィックの状況下 でテーブルのスキーマ変更を行うと、かなりの時 間がかかることがある。YugabyteDB ではどう か? [予期しない結果] クラスタ内のすべてのノードが応答を返さなくな り、復旧は TServer の再起動しかないという挙動 が確認された。 [発生状況の整理] • 高負荷下でのメタデータ (テーブルスキーマ、 ユーザ権限など) の変更によって比較的高い再 現性で発生する。 • 単一ノード (yugabyted) でも発生する。 • 1 ノードあたりの接続数が 1000 を超えるあた りから発生しやすくなる。 継続的な トラフィック YugabyteDB Cluster … … … … …
4. YB-Master YB-TServer オンラインDDL実行「後」の裏側 PostgreSQL backend から YB-Master へのメタデータキャッシュ同期メカニズム Client Query Layer (YSQL) PostgreSQL-fork SQL parsing, Planning, and Execution postmaster backend (session 1) backend (session 2) … backend (session 𝑁) 1 クライアント接続 1 プロセス (PostgreSQLと同じ) 𝑁 = ysql_max_connections (default: 50-300) PgGate YBClient 𝑀 = rpc_workers_limit (default: 1024) SysCatalog PostgreSQL -compatible SQL 3 Storage Layer (DocDB) YB-TServer Process Sharding, Replication (Raft), and Transaction (2PC) PgTableCache rpc_thread_pool Thread 2 Thread 1 Thread 3 …Thread 𝑀 OpenTable (local RPC) GetTableSchema (async remote RPC) • 各セッションは現在のカタログバージョンを認 識している。 • クエリーの実行過程でそれらが変わったことを 検知するとメタデータを再読み込みする。
5. YB-Master YB-TServer Client Query Layer (YSQL) postmaster backend (session 1) backend (session 2) … backend (session 𝑁) 高負荷状態で何が起きたか? キャッシュ更新要求の殺到によるスレッドプールの占有と相互ブロック Storage Layer (DocDB) PgClientService PgTableCache rpc_thread_pool SysCatalog GetTableSchema (async remote RPC) 4 Thread 2 Thread 1 Thread 3 OpenTable (local RPC) queue • 実行中のスレッドはすべてキャッシュ更新待ち。 • キャッシュを更新する処理はスレッドの空き待ち。
6. 5 1024個中、1023個のス レッドが同じ場所で止 まっている。 TServer の Web UI 最先発のスレッド?
7. 調査プロセスと提案 最終的な解決策 normal_thread_pool_ 問題解消: コールバックスレッドの分離 メタ情報更新コールバックの High-Priority 実行による Cyclic Wait の解消 6 rpc_thread_pool Thread 2 Thread 1 Thread 3 queue high_priority_thread_pool_ Thread 2 Thread 1 Thread 3 queue (主にコンセンサスサービス用) 停止位置の特定 • gdb や Web UI でスレッド状況 ➢ GetTableSchema RPC 内でデッドロック? • YB-Master, YB-TServer のログ調査 ➢ 応答は成功している。しかしコールバックが実行 されていない? (invoke_callback_time: -inf) 仮説の検証 (PoC) 1. スレッドプールのサイズを小さくするとすぐ再現 2.キャッシュ更新待機にタイムアウト設定 (コード修正) → 時間はかかるが回復した 提案 1. ysql_max_connections < rpc_workers_limit を強制 2. キャッシュ更新待機の上限時間設定 3. キャッシュ更新待機数のスロットリング 4. コールバック処理のスレッド分離 5. キャッシュ更新スレッドの同期化 報告 #26909、修正 8eb99ac, ee32946, 6e24f3f。 2024.2.4, 2025.1.0 以降で対応済み。 GetTableSchema の コールバック 優先度「高」で実行 (実は2つのスレッドプールを内包している)
8. 7 状況分析と仮説検証 複雑な事象もログとアーキテ クチャの分析から仮説を立て、 PoCで検証を実施。結果とし て主因の特定と具体的な改善 案を伴う、実効性の高い問題 報告に繋がりました。 迅速かつ抜本的な対応 即座に priority:high でトリ アージされました。表面的な 対処ではなく、アーキテク チャレベルの抜本的な改修が 速やかに行われた Yugabyte チームの対応に感謝します。 難題に挑む仲間を募集 内部アーキテクチャに踏み込 んだ課題解決を通じ、大規模 分散ストレージ基盤の構築を 進めています。分散システム の深い理解と実践に興味のあ る方を歓迎します。 一ノ矢は避けられない。しかし二ノ矢は打ち落とさなければならない。 ～ サンユッタ・ニカーヤ「矢の経」～ LY00093 www.lycorp.co.jp/ja/recruit/career/job-categories/ly00093/