Percona LIVE 2019に参加してきました。 前回の続きで初日(Tutorial Day)から Session Day 1, 2の3日間のうち2日目(Session Day 1)の内容です。
おそらく発表のスライドが公開されることと思いますが、全体が非公開になるものや非公開になるページがあるかもしれないので、ここではあえて概要だけと会場の雰囲気や僕の感想を書こうと思います。
また、英語の聞き取り能力が高くないため、勘違いした内容を書いている可能性が多分にあります。あくまで参考程度に読んでください。
各発表ごとのサブタイトルは発表中のものもあれば、メモを忘れて僕が勝手に書いたものもあります。
(メモからの校生も面倒なので、ここで丁寧語は終了です)
Session Day 1 (2日目)
1日目のスケジュール -> https://www.percona.com/live/19/schedule/day-1-grid
本セッションの1日目。 一般的なカンファレンスと同じく部屋ごとに大まかな分類がされている。 今回の会場で一番大きい部屋(Texas1)ではMySQL(のcore関連)、その他の部屋ではPostgreSQL, MariaDB, Facebook(MySQL at Facebook), TiDB ...というふうに別れていた。
MySQL core関連, Facebookの2つの部屋でめちゃくちゃ迷った結果、Facebook部屋を中心に聞くことにした。
MySQL core関連の部屋はOracleやPerconaの大御所の人たちの発表で、公式の内容のおさらいだったり、案外日本に来て発表してくれたりするんじゃないか？(もしくはYoutubeなどで上がりそう)という予想と期待から生で大御所の発表を聞くのは諦めて、他では聞けなさそうなFacebookの発表を優先した。(Keynoteの話しぶりから8.0.17やそれ以降の情報を公開したりしなさそうと判断して、これで正解だったように思う)
というわけで、午前から順番に以下のセッションを聞いた。
- MySQL Technology Evolutions at Facebook
- Managing MySQL at Scale in Facebook
- MySQL Replication and HA at Facebook - Part 1
- The MySQL Query Optimizer Explained Through Optimizer Trace
- Facebook's MySQL Client Stack
- MySQL and ZFS
正直Facebookの発表は異次元だった。 最適化するためにMySQLに手を入れるのは当然だし、ストレージエンジン(MyRocks)を始めとしてKernel levelでも, ネットワークパケットにまで手を入れていて、たぶん会場で「あーあーなるよね、わかるー」ってなる人はいなかったのではないだろうか。。。
午前1 MySQL Technology Evolutions at Facebook
初っ端から松信さん(MySQL Tech Lead)のセッション！！
MyRocksの説明以外はこの日のFBの発表全体の導入・紹介という感じだったように思う。
最初にチームに関する紹介から、MySQLチームにはPE, とSEの2チームがある
- PE: Production Engineering team
- いわゆるオペレーションとオペレーションに関連するツールの開発
- Menlo Park(US)とLondon(UK)にチームあるらしい (話には出なかったが時差を利用した対応も余裕そう、深夜対応のない世界うらやま)
- SWE: Software Engineering team
FacebokのMySQLバージョンの歴史
- 2013~2014で5.1 -> 5.6
- 現在は5.6
- これから5.7を飛ばして8.0
MyRocksを作るためにMariaDBと働いたり、8.0のパッチを送るためにPerconaと働いたり、official MySQLにパッチを送るためにOracleと働いたりしている。
- InnoDBのOnline Defragmentationのために新しいCommandを追加した
- 20%のspace削減
- torn-pageを検知するだけというinnodb_doublewrite=2の追加
- InnoDBのfull table scanの改善
- full table scanをする際にPKの順番でscanするけど、実際にページはディスク上に連続して並んでいるわけではない
- それを先に読み出すpageをリストして(?)、それらをシーケンシャルに読むように変更
- その他いろいろ
- async client
- アクティブスレッドの数に応じたquery throttling
- etc..
MySQL周辺のソフトウェア
- Binlog server
- Maxscaleやrippleのようなやつ
- binlogのみを保持する
- MasterとSlaveの間において、MasterへのAckを高速に返す。semi-sync repliなので、Masterが早くなる
- binlog serverをlogical copyとすることで、1 region (datacenter?) にmaster-slaveのセットを置かない(Single copy per region)構成をとっている
- region間ではnetwork的な遅延が大きいので、semi-sync replicationは使えない
MyRocks
- Open Source
- ストレージエンジンとしてRocksDBを使える
- LSM Compaction Algorithmによって圧縮
- InnoDBのcompressionを使った場合、fragmentationにより無駄な領域が大きくなってしまう問題がきっかけ
- Facebook製のzstandard dictionary compressionをサポート
- MyRocks, RocksDBはBuffered I/Oを基本にしていて、swapが発生することがあり、direct I/Oに対応
Future
- MySQL 8.0
- 効率化
- CPU利用の効率化
- ほとんどのデータがmemoryに乗る場合のrange scanの効率化
- より汎用的なDBにする
- Gap lockの実装(今ないのか?)
- Foreign key
- online, fast schema change
午前2 Managing MySQL at Scale in Facebook
2つめのセッションはFacebookでMySQLをどのように運用しているかについて。
最初にTerminology(用語の紹介)があり、Facebookにおけるinstance, shard, replica setのが説明された。
- Instance(インスタンス): MySQLプロセスのこと、1つのOS上でport番号等を変えて複数のMySQLを運用しているっぽい図が出てた
- Shard(シャード): MySQL databaseそのもののこと (schema.tableに見えるもののことを指しているっぽい)
- Replicaset(レプリカセット): レプリケーションを組んでいるMySQL Instanceの集合。同じデータを持っている, regionを超えてレプリケーションをしているので、どこに書き込むかは自前のservice discoveryシステムに問い合わせて確認する
説明はなかったけど、この図を見ると負荷分散や垂直シャーディングもしやすいようにShardっていう概念で接続先をコントロールできるようにしているように見える。
Lifecycle of an instance
インスタンス群をproductionからspare, spare deallocated, spare allocatedなどなど(紹介されたのは簡略化されたものらしい)のラベル付けをし、Lifecycleに従ってデータ移行や復旧, resizingなどを自動化している。
Clone instance
- Allocation
- Setup
- Migration
- Replication
- Validation
- Registration
と新インスタンスを導入するまで段階を整理して手順を説明。
MyRocksであればmyrocks_hotbackup(公開されている？)を使ってphysical backupを取る。
Validationでのデータの確認はtableごとにchecksumをとって比較。
一般的な内容だったと思うけど、整理されていてわかりやすかった。
Balancing
インスタンスごとに必要なディスクサイズがバラバラな状態でサーバに詰めていく作業を考える。
このスライドだと、400GB * 1, 200GB * 3のインスタンスを500GBまで許容できるサーバに詰めていく。
普通に考えたら↓ これだとfree spaceができてしまっている
Facebookではshardingして(すでにしている?)、size的にfitしやすく分散している。
個々のshardingごとにアクセスの偏りがあってもそれを分散することもできる。
かなり抽象的な説明だけで、実際どういうふうに分割しているのかなどの説明はなし。
QAでこの辺について質問が出ていたようだけど、答えられないという返答だったと思う(QAコーナーの会話の聞き取りに自信ない。。。)
Test
デプロイや運用を自動化するソフトウェアのテスト、およびその自動化についての説明。 具体的な話はなかったので、特に目新しいことはない。
- 機能ごとののUnitテストなど基本的なこともしている
- productionと別の環境を作っている
- canary packageとして変更を加えたシステムをテストする
- virtual machineからsnapshotをとって、dev環境でテスト
アプリケーションのテストもこれと同じ仕組みを利用しているっぽい。
午後1 MySQL Replication and HA at Facebook - Part 1
HA structure
LBU: Logical Backup Unit, Logtailer, binlogサーバなどと呼ばれる。
binlogを書いてackだけ返す。DB全体は保持しない
flush_log_at_trx_commit != 1 だそう。
別のリージョンにmasterになりうるslave(Master-capable region)がいる wormholeと呼ばれるpub-subシステムにbinlogの内容を送って他のシステムにも適用している(MySQLチームとは別のチームがやっているらしい。他に説明はないがおそらく分析用だろう)
Live Master Promotion, 500ms以下、実際は大体200~300msでMasterになっているサーバを変えられるとのこと。基本的にはbinlogを十分にcatch upしているslaveを選択して、masterでread-onlyを設定して、サービスディスカバリシステムにpromotion先のslaveをmasterに設定することで切り替える。
ここまでの説明だと1リージョンに1 masterしかいない状況でこれが可能なのか疑問。リージョンに関する言及はなかったので、Live Master Promotionはリージョン内でやっているのだろうか？
Dead master promotion, masterが死んだ場合は基本的にはLBUを停止して、最新のbinlogまで追いついたslaveにpromotionする。基本的な流れはLive Master Promotionと同じ。
最大30secかかるが頻繁に起こることではない。
Replication improvements
MySQLのレプリケーションはMasterは並列に書き込みができるけど、Slaveはシリアル。MTS(Multi-threaded slave)の有効化で改善できるけど、それでもdatabase内部の理由で追いつかない。
- Masterと同じ速度でSlaveに適用できるか？
- RBR(Row based replication)ではRW/WWコンフリクトを見つけるためのすべてのデータが入っている。
- conflictをDAGに書き換えて、コンフリクトがないものは部分的にであっても(例ではrowレベルで分解して競合しない部分を並列化していた)すぐに適用する
- 最終的には適用でCommit orderingが保持されるようにしている
- この方法でコンフリクトが少ない環境ではsysbenchのoltp_write_onlyのシナリオで最大4~5倍の性能改善
- ABS(Async Behind Semisync slave)
- すべてのsemisync slaveにbinlogを送ってしまうとフェイルオーバー時に一番masterに追いついているslaveを探さないといけない。
- Async slaveへのbinlogの送信はsemisyncのAckが帰ってきてからにする
- (semisync slaveを予めquorumから絞っておく、みたいなことをいってた。絞ったもの以外がAsync slaveということだと思われ)
- レプリケーションパケットのDSCPのタグ機能を使うように修正
- binlog_row_imageに
COMPLETEimage formatを追加- MINIMALとFULLの間のサイズで変更したカラムの情報だけを送る
午後2 The MySQL Query Optimizer Explained Through Optimizer Trace
Sun/OracleでMySQL optimizer teamに10年いて、現在Alibaba Cloudで働いているØystein Grøvlen 氏の発表。 名前の文字はコピペでしか入力できないし、発音も全く聞き取れなかった。
Optimizerの内部の挙動の紹介と8.0で入った最適化についての話。 説明書くの大変なので、発表時の資料を見てほしい。。。
https://www.percona.com/live/19/sessions/the-mysql-query-optimizer-explained-through-optimizer-trace
内容はすごく良くて、Øystein Grøvlen氏の資料あさらないと思った。
午後3 Facebook's MySQL Client Stack
完全に英語nativeの人の発表という感じで、早口だし、単語の区切り目が分かりづらくて、厳しかった。。。
Facebook内で使われている言語ごとのクライアントライブラリから認証系、MySQLへの接続をProxyするミドルウェアのアーキテクチャを紹介していた。
- DBSonar
- Proxy
- X regionの接続を管理
- Client-sideのpoolingを効率的に行う
- コネクション確率のCPU時間をここで受け持つ
- 中央集権でトラフィックを管理する(メトリクスやログを集計する)
- Async クライアント
- connection poolingをサポート
- timeoutしたクエリのkill
- connectionのparameterをキャッシュする
スライドはあっさりめで高等での説明が多かったように思う。
朝からいろいろな発音の英語を聞きすぎて、疲れて眠かった。
午後4 MySQL and ZFS
ZFSとZFS上でMySQLを動かすときの注意点やSettingのTips的な内容。 なんかトラブルがあったようで、序盤にグダってしまったように見えた。
終始、MySQL on ZFSでDouble write無効にしたときにパフォーマンス・運用にどれくらいProsConsあるの?? って思ったまま終わった。
発表も終盤に入り、時差ボケの眠気とひたすら戦っていた。。。
あとから聞いた話で、Perconaのブログにパフォーマンスに関しても書いているとのことだったので、いくつかggってみた。
だれかがまとめてくれることを祈って、ここにメモしておく m(_ _ )m
- https://www.percona.com/blog/2018/05/15/about-zfs-performance/
- https://www.percona.com/blog/2017/12/07/hands-look-zfs-with-mysql/
- https://www.percona.com/blog/2018/02/16/why-zfs-affects-mysql-performance/
- http://download.nust.na/pub6/mysql/tech-resources/articles/mysql-zfs.html
時差ボケの中、ここまでの1session 50分程度の超濃密な発表をガンガン聞いて体力的に限界になったw(ここまで飛ばさずに読んだ人はいるだろうか？？？)
この日の最後のセッションは聞けずにベッドに倒れ込んだ。
Session day 1まとめ
めったに聞けないであろうFacebookのcrazyな規模のMySQL運用の話、そして元Optimizerチームの方の「optimizer詳解」って感じの発表とでテンション上がりまくりでめちゃくちゃExciting!!! だった。
発表中では明示的に言うことはなかったと思うけど、Facebookの発表はその規模感もあってか、物理Server確保やコストとの戦いなんだろうなと感じた。
F8みたいなビジネス方面の発表は見るけど、FacebookのtechnicalなカンファレンスがあるならDB周辺のインフラ含めた内情を聞いてみたいと思った。あまり意識したことはなかったけど、あるのだろうか。
FacebookのMySQL運用技術は最強か?
FacebookのMySQL運用がいろいろなレイヤーで手を入れていて、ちょっと理解できないくらい最適化されていることに衝撃をうけた一方で、松信さんの発表で、たしか Hardend replication も考えていく、みたいことを言われていたのが気になった。
たしかにMyRocksの開発・運用はほとんどの会社で真似できないレベルの技術だけど、Cloud serviceを提供するためにより汎用的な方法として最適化を図っているAWSのAuroraやAlibabaのAliSQLのほうが、MySQL(といえるか怪しいけど)運用のための手の入れ方としては、先を行っているのかもしれない。
ちょっと規模感が違いすぎるので良くわからないが、MySQLの運用業務を続けていくだけでこういう世界にたどり着ける気はしないので、RDBMSやトランザクション処理そのものの技術に関する勉強もして行きたい。
これで参加2日目の内容は終わりです。
次回はSession Day 2(3日目)の記事です。
日数が経ち過ぎないようにできるだけ早くまとめておきたい。。。
