Yahoo! JAPANのプライベートRDBクラウドとマルチライター型 MySQL #dbts2017 #dbtsOSS
1.2K Views
June 19, 17
スライド概要
Yahoo! JAPANのプライベートRDBクラウドとマルチライター型 MySQL
2023年10月からSpeaker Deckに移行しました。最新情報はこちらをご覧ください。 https://speakerdeck.com/lycorptech_jp
関連スライド
各ページのテキスト
Yahoo! JAPANのプライベートRDBクラウドと マルチライター型 MySQL 2017年6月19日 db tech showcase OSS 2017 1 Copyright © 2017 Yahoo Japan Corporation. All Rights Reserved
本日の内容 1. 2. 3. 4. 5. 6. Yahoo! JAPAN の概要 Yahoo! JAPAN のMySQLの歴史と課題 プライベートRDBクラウドの構成 マルチライター型 MySQL PXCの特徴 PXC vs Group Replication まとめ – Q&A
自己紹介 • 三谷 智史（@mita2） • ヤフー（株） • 3 データ&サイエンスソリューション統括本部 データプラットフォーム本部 MySQL • 第６代黒帯 ～RDB～ • MySQLとの関わり • 2002年～ 主に利用して開発 • 2010年～ 主に運用・管理する立場
本日の内容 1. 2. 3. 4. 5. 6. Yahoo! JAPAN の概要 Yahoo! JAPAN のMySQLの歴史と課題 プライベートRDBクラウドの構成 マルチライター型 MySQL PXCの特徴 PXC vs Group Replication まとめ – Q&A
Yahoo! JAPAN 利用者数 1日 5 9,000万 ユニーク ブラウザ ※出所：Yahoo! JAPAN社内データ（2016年4月-6月の平均）
提供サービス Media Search Video Answer Mail C2C EC B2C EC Local US JP Membership US JP 6 C2C Payment
巨大なデータプラットフォーム 1200 1000+ 1500 300,000 DBs nodes nodes Query/day NoSQL Object Storage RDB Hadoop 7 DWH 6000 node 150 PB
巨大なデータプラットフォーム 1000 1000+ 1500 300,000 MySQL nodes nodes Query/day NoSQL Object Storage RDB Hadoop 8 DWH 6000 node 150 PB
本日の内容 1. 2. 3. 4. 5. 6. Yahoo! JAPAN の概要 Yahoo! JAPAN のMySQLの歴史と課題 プライベートRDBクラウドの構成 マルチライター型 MySQL PXCの特徴 PXC vs Group Replication まとめ – Q&A
歴史 本番データベース数 1000 800 600 400 200 MySQLの 統合管理スタート 0 10 V1 DBaaS
統合環境 初代構成 • マスターは 共有ストレージのHA スレーブやクライアント mysqld Failover mysqld mysqld • 1サーバに複数mysqld • Oracle Clusterware 11 アクティブ サーバ クラスタ リング スタンバイ サーバ z 共有ストレージ
共有ストレージ 採用理由 1. データロストが許容できない • loss-less semi-sync replication は 当時、未登場 2. 同様のアーキテクチャによる Oracle databaseの運用ノウハウ 12
集約することで解決できた課題 1. DB構築時間の短縮 2. 運用レベルの統一 3. HA、冗長性の確保 4. 集約管理によるコスト削減 13
新たな課題 14
課題 メンテやリプレイスの負担が大きい 15
課題 メンテやリプレイスの負担が大きい 16
メンテナンス • 計画停止メンテナンス • 数分程度の更新停止を伴う 一斉メンテナンスを年に１～２回 実施 17 • セキュリティパッチ当てなど • 約200DB / 年 が対象
もっとメンテナンスしたい • 設定・SWバージョンの統一 • チューニング等の試行錯誤 • 障害の予行演習としてのメンテ 18
課題 メンテやリプレイスの負担が大きい 19
リプレイス • 20 SW/HWのEOLにあわせて実施 • ３～５年に１度 • 約200DB / 年 • 旧→新でレプリ、サービス停止、接続先を切り替え • 正味の「寿命」は、もっと短い • 複数DB 利用サービスは負担大
もっとリプレイスしたい • HW構成の統一 • DCラックの有効活用 • 長く使うのはコスト増 • × できるだけ長く使う • ○ 最新のHW/SW を常に利用する 21
本日の内容 1. 2. 3. 4. 5. 6. Yahoo! JAPAN の概要 Yahoo! JAPAN のMySQLの歴史と課題 プライベートRDBクラウドの構成 マルチライター型 MySQL PXCの特徴 PXC vs Group Replication まとめ – Q&A
解決策 本番データベース数 1000 800 600 400 200 0 23 V1 DBaaS 第2世代 （DBaaS）
解決策 マルチライター型 MySQL
解決策 マルチライター型 MySQL
OpenStack とは • OSSクラウドコンピューティングPJ https://www.openstack.org/software/
ヤフーにおける豊富な運用実績 25 20 vCPU (x10k) 15 Memory (x10TB) 10 Block (x1PB) 5 27 0 1 year ago Half year… Today
OpenStack Trove • Database As A Service コンポーネント • Tesora Inc, を中心に 開発されている 28
OpenStack Trove • 機能・API • • • • • • • 対応しているデータストア • 29 DBインスタンスの作成 DBアカウントの管理 DBの起動・停止 リサイズ（VMスペック変更） バックアップ取得 etc… MySQL, MariaDB, Percona, Redis, Cassandra…
OpenStackの導入意図 1. APIによる自動化のしやすさ • • 構成情報、ステータス、起動や停止 抽象化、自動化の役割分担 2. VMイメージによる構成管理 30
解決策 マルチライター型 MySQL
Percona XtraDB Cluster • マルチライター型 高可用性ソリューション • Percona Server for MySQL • • MySQL の fork • MySQL との高い互換性 Percna XtraDB Cluster • さらにマルチライター対応したもの
Multi Master , Multi Writer ? Client Client マルチマスター マルチライター
マルチマスター • 従来のレプリケーションは非同期 • 同時書込すると・・・ • レプリケーション停止 • データ不整合 34
不整合の具体例 マスター２ マスター１ COMMIT UPDATE col1 = COMMIT UPDATE テーブル 変更 1 col1 = Binlog 追記 テーブル 変更 2 Binlog 追記 OK OK relaylog 追記 col1=1 col1=2 ログ適用 ログ適用 35 時間 relaylog 追記 不整合
マルチライター • 同時に書き込み可 • 楽観的ロックによる不整合回避 （後述） 36
Multi Master , Multi Writer ? Client • • 不整合の考慮が必要 片方にのみ書込、Active/Standby Client • 同時更新で不整合は起こらない • 容易に高可用性構成が組める
解決後 デプロイ メンテ例 38
ゴールデンイメージ準備 1. 新しいゴールデンイメージ準備 イメージ作成用VM $ nova create-image snapshot $ yum update イメージ ファイル $ mysql –e ‘select * from hoge’ 39 自動テスト実行
無風化 2. 無風化する ロードバランサ mysql> UPDATE clutercheck SET status = ‘DISABLED’ WHERE node = ‘node1’ I’m offline httpd node1 40 httpd node2 httpd node3
OSから入れ替え 3. OS再インストール イメージ ファイル $ nova rebuild OpenStackのOS再インストールAPIを実行 41 node2 node3
データの自動同期 4. データを同期 node1 42 node2 node3
以上をローリングで繰り返す node1 43 node2 node3
デモ デモ用 スクリプト SELECT イメージ ファイル member-1 44 member-2 member-3
頻繁にメンテを実行 • １５０本番DB/月に対して実行 • 9ヶ月の実績 • 全自動 • SW構成は４パターンに集約 • v5.6 / v5.7 x 新旧イメージ 45
課題 メンテやリプレイスの負担が大きい 46
本日の内容 1. 2. 3. 4. 5. 6. Yahoo! JAPAN の概要 Yahoo! JAPAN のMySQLの歴史と課題 プライベートRDBクラウドの構成 マルチライター型 MySQL PXCの特徴 PXC vs Group Replication まとめ – Q&A
PXCの特徴 • Percona XtraDB Cluster の特徴 1. 2. 3. 4. 5. 概要 ロック データ同期遅延とFlow Control リカバリの仕組み（SST/IST） 制限事項
PXC 概要 • マルチライターのMySQL • 用途 • • • • 49 ビルドイン 高可用性 Read Scalability Disaster Recovery スレーブも追加可 async slave async slave
PXCの特徴 • Percona XtraDB Cluster の特徴 1. 2. 3. 4. 5. 概要 ロック データ同期遅延とFlow Control リカバリの仕組み（SST/IST） 制限事項
いつものロック
いつものロック • ロックが競合した場合、後続は「待つ」
PXCのロック
時間
行の値
トランザクション１ on ノード1
T1
-
mysql> BEGIN;
Query OK, 0 rows affected (0.00 sec)
トランザクション２ on ノード2
mysql> UPDATE grplt.tbl SET col1 = 10,
who_update = ‘A' WHERE pk = 1;
Query OK, 1 row affected (0.00 sec)
Rows matched: 1 Changed: 1 Warnings: 0
T2
-
mysql> BEGIN;
Query OK, 0 rows affected (0.00 sec)
mysql> UPDATE grplt.tbl SET col1 = 10,
who_update = ‘B' WHERE pk = 1;
Query OK, 1 row affected (0.00 sec)
Rows matched: 1 Changed: 1 Warnings: 0
T3
A
T4
A
53
mysql> COMMIT;
Query OK, 0 rows affected (0.00 sec)
(ノード１の更新内容が伝わってくる）
mysql> COMMIT;
ERROR 1213 (40001): Deadlock found when
trying to get lock; try restarting transaction
PXCのロック
時間
行の値
トランザクション１ on ノード1
T1
-
mysql> BEGIN;
Query OK, 0 rows affected (0.00 sec)
トランザクション２ on ノード2
• 異なるノードでロックが競合した場合、「先勝ち」
mysql> UPDATE grplt.tbl SET col1 = 10,
who_update = ‘A' WHERE pk = 1;
Query OK, 1 row affected (0.00 sec)
Rows matched: 1 Changed: 1 Warnings: 0
mysql> BEGIN;
• T2デッドロックは必要に応じてリトライ
Query OK, 0 rows affected (0.00 sec)
mysql> UPDATE grplt.tbl SET col1 = 10,
who_update = ‘B' WHERE pk = 1;
Query OK, 1 row affected (0.00 sec)
Rows matched: 1 Changed: 1 Warnings: 0
• LBをSingle-Primaryで運用すれば、従来と同じ挙動に
T3
A
T4
A
54
mysql> COMMIT;
Query OK, 0 rows affected (0.00 sec)
(ノード１の更新内容が伝わってくる）
mysql> COMMIT;
ERROR 1213 (40001): Deadlock found when
trying to get lock; try restarting transaction
マルチライター型 MySQLの特徴 • Percona XtraDB Cluster の特徴 1. 2. 3. 4. 5. 概要 ロック データ同期遅延とFlow Control リカバリの仕組み（SST/IST） 制限事項
Galera Replication • PXCはバイナリログとは違う仕組みで レプリケーションする • Write Sets • トランザクション • 更新内容をPKを使って表したもの • Write Sets を伝播することで データ同期する http://galeracluster.com/documentation-webpages/certificationbasedreplication.html 56
データ同期遅延 • • クライアントがCOMMITを実行した ノードと、他のノードの間で同期遅延 が発生する 2 1 COMMIT Replicate 大きなトランザクションだと顕著 Certification Certification commit finalized Apply OK 遅延 57 commit finalized
flow control • 遅れたノードがほかのノードに 「更新をこれ以上受け付けない で」と「待った」をかける • 遅延が拡大するのを防ぐ 58
flow control を回避するには？ • 大きすぎるトランザクションを避ける • 遅延を許容し、閾値を引き上げる • gcs.fc_limit • 遅延もFCも許容できない場合は Single-Primary 運用 59
flow control • ステータスでFCの状況が確認可 • wsrep_flow_control_paused_ns • • wsrep_flow_control_sent • • • FC命令を発した累積回数 遅れているノードでカウントアップ wsrep_flow_control_recv • 60 FCで待たされた累積秒数（ナノ秒） FC命令を受信した累積回数
マルチライター型 MySQLの特徴 • Percona XtraDB Cluster の特徴 1. 2. 3. 4. 5. 6. 概要 Galera Replication ロック データ同期遅延とFlow Control リカバリの仕組み（SST/IST） 制限事項
リカバリの仕組み • Incremental State Transfer • State Snapshot Transfer 62
Incremental State Transfer • 差分同期 • 「gcache」というファイルに履歴を保存 • 63 gcache.size パラメータでサイズ指定可能 1 2 差分適用 gcache gcache
State Snapshot Transfer • • 全データのコピーを行う • ヤフーではHVに10GbEx2 UPLINK 40GbE を採用 • 100GB / 10min（並列は試してない） 発生タイミング • • 64 新規ノード追加、長期間停止後、異常終了後 同期完了するまで該当ノードは接続を受付ない
マルチライター型 MySQLの特徴 • Percona XtraDB Cluster の特徴 1. ロック 2. データ同期の仕組み（SST/IST） 3. データ同期遅延とFlow Control 4. 制限事項
PXC 制限事項 • InnoDB のみ利用可 • LOCK TABLESは未サポート • • • ALTER TABLEは全更新をブロックする • 66 ノード間でロック情報は共有されない mysqldump –skip-lock pt-osc ツール や RollingSchemaUpgrade で回避
本日の内容 1. 2. 3. 4. 5. 6. Yahoo! JAPAN の概要 Yahoo! JAPAN のMySQLの歴史と課題 プライベートRDBクラウドの構成 マルチライター型 MySQL PXCの特徴 PXC vs Group Replication まとめ – Q&A
MySQL Group Replication • Oracle 純正 • MySQL 5.7.17 (201612) でリリース • PXCとだいたいと同じことができる • Windows な人も大丈夫！
GR vs PXC (1) Group Replication PXC (galera family) 通常のマスター昇格 対応 対応 非対応 1 マルチライター 2 データ同期の仕組み GTID Replication base Galera / wsrepl GTID or 非GTID 3 バイナリログ 必須 必須ではない 必須 4 Flow Control 有り Certifier / Applier 有り Applier のみ閾値設定可 無し 4 ストレージエンジン InnoDB のみ InnoDB のみ 制限なし 5 ノード間の ロック仕組み 楽観的ロック / 独立したエ ラーコード (First Commit Wins) 楽観的ロック / デッドロック 競合しない としてエラーが返る ※ マルチライターでは (First Commit Wins) ない 6 DDLロック 対象テーブルのみ 全体ロック 69 オンラインDDL
GR vs PXC (2) Group Replication PXC (galera family) 通常のマスター昇格 ○ 自動 ○ 自動 - 7 AutoIncr 衝突回避 8 クラスタリングや ビルドイン(XCom) フェイルオーバ機構 ビルドイン (GCS) ビルドインされない ※ 自分で用意 9 自動リカバリ(差分) ○ GTID Replication ○ (IST) ○ レプリケーション 10 自動リカバリ(全体) × ○ (SST) × 11 SplitBrain 対応 ○ 対応 ただし、クエリ受付可 ○ 対応 × 非常に難しい 12 ステータス確認 performance_schema GLOBAL STATUS performance_schema or SHOW 13 提供形態 ○ プラグイン Windows も可 △ 別製品。互換性はあ り。Linux のみ。 - 70
本日の内容 1. 2. 3. 4. 5. 6. Yahoo! JAPAN の概要 Yahoo! JAPAN のMySQLの歴史と課題 プライベートRDBクラウドの構成 マルチライター型 MySQL PXCの特徴 PXC vs Group Replication まとめ – Q&A
まとめ 72
まとめ マルチライターとIaaSで、DBでも 「Immutable Infrastructure」できました GR登場でマルチライター時代到来！？ 73
Questions ? 74
Thank you