さいきんのMySQLに関する取り組み（仮）

Copyright © GREE, Inc. All Rights Reserved.
さいきんの
MySQL に関する
取り組み（仮）
Takanori Sejima

自己紹介
● わりと MySQL のひと
● 3.23.58 から使ってる
● むかしは Resource Monitoring も力入れてやってた
● ganglia & rrdcached の（たぶん）ヘビーユーザ
● というわけで、自分は Monitoring を大事にする
● 一時期は Flare という OSS の bugfix などもやってた
● さいきんは、ハードウェアの評価をしている時間が長かった
● たまに Linux の TCP プロトコルスタックについて調べたりもする
2

● 弊社は、古くからオンプレミス環境で、 MySQL をヘビーに使ってきまし
た。
● 過去に、一部のサービスを AWS に移行した際、マネージドサービスだけ
でなく、 EC2 でも MySQL を使う構成にしまして、ここ数年でいくらかノウ
ハウが溜まってきた気もします。
● また、数年先を見据えて取り組んでいることもあります。
● 今回は、そういったあたり、お話させていただければと思います。
● わたしはいろいろ変なこと考えてますが、オンプレおじさんなので
● パブリッククラウドでは、若手たちが創意工夫して頑張ってくれてます。
本日のお話
3

● MySQL の話をする際、 InnoDB の話を避けるのが難しいので
● まだ読まれたことのない方は
● 次の資料もあわせて読んでいただけると、よりわかりやすいかと思います
● さいきんの InnoDB Adaptive Flushing （仮）
● できればこちらひととおり読んでいただけると、より理解が深まるかと思います
● https://www.slideshare.net/takanorisejima/
本日のお話の補足資料
4

● はじめに
● 弊社の環境など
● EC2 で MySQL を使うメリット
● MySQL の EC2 向けパラメータチューニング
● EC2 で MySQL 動かす上での Monitoring
● さいきん取り組んでいること
● こんご取り組んでいきたいこと
Agenda
5

はじめに
6

● GREE のサービスは歴史が古い
● むかしから動いてる MySQL のサーバは、かなり sharding されていた
● 2000年代、GREE は SAS HDD 146GB 15krpm * 4本使った RAID10 の前提
で、データベースを設計してるところが多かった
● そういう HDD でも動くように、データベースのサイズは100-200GB 以下のものが多
かった
● ４年くらい前までは、 MySQL 含め、ほとんど HDD で動いていた
● ioDrive ないこともなかったが、全体の数％だった
● かつてほとんど HDD で動いていたことを考えると、最近の block
device は桁違いに性能が良くて、性能面ではとても楽。
むかしの GREE のサーバ
7

● ここ数年かけて、ほぼ SATA SSD の環境になった。
● いくらか ioMemory 残っているけど、 Endurance 的には、 1DWPD から 3DWPD
程度の SSD がほとんど。
● ストレージの appliance は使っていない。SSD は SATA直結。
● disk I/O のためにネットワークの traffic が発生しないので、ネットワーク機器が安く上
がる。
● private cloud はやっていない。すべてベアメタル。
● 仮想化しないと、ハードウェアから、kernel - TCP プロトコルスタック - MySQL までの
各レイヤーに対して、調査がしやすい。
● 日本では、ランニングコストのうち、電気代の比率が高い。如何にして消費
電力効率を最適化するか、という戦略を取っている。
● NVMe ではなく SATA の SSD 使っているのも、消費電力が低いから。
さいきんの弊社のオンプレミス環境
8

● 新しいサービスは、パブリッククラウドで立ち上げている。海外展開がしや
すかったり、インスタンスの数を柔軟に調整しやすいなどのメリットが有る。
● その他、かつてオンプレで動いていたサービスの大部分、台数にして
2000台以上のサーバを、 AWS に移行してから数年が経った。
● 計画停止しにくいものをオンプレで安定稼働させつつ、計画停止できるものを、パブリック
クラウドに移行した。
● オンプレから移行してきたサービスは、マネージドサービスも活用している
が、 EC2 で MySQL を立てて運用しているところが多い。
● MySQL を failover させる仕組みは、パブリッククラウドを使う前から内製していたの
で、 failover をマネージドサービスに任せなくても運用できる。
パブリッククラウドの利用状況
9

● 現状、MySQL 5.6 か 5.7 を使っている。大部分が 5.7。
● MySQL 8.0 は検証中。
● MySQL の Extended Support の期間を意識して新しいバージョンに
移行するというより、可能であれば新しいメジャーバージョンに移行してい
きたいと考えている。
● MySQL のメジャーバージョンは、 Extended Support が終了するまでの間、 GA が
出てからだいたい８年くらいは、 security update がリリースされる。
弊社のMySQL利用状況
10

● 次のようなものが挙げられる
● Multi Source Replication など、コスト削減につながる機能が追加される。
● Multi Source Replication のおかげで、 DB の統合がとても楽になった。
● バージョンを追うごとに、 InnoDB が mutex の競合に強くなっている。メジャーバー
ジョンアップにより、 InnoDB をより堅牢強固にすることができる
● アプリケーションの不具合や障害などで、意図せず InnoDB が高負荷状態になってしまうこ
とがたまにある。しかし、さいきんの InnoDB は、 innodb_thread_concurrency などを
適切にチューニングしておけば、それでもなんとか持ちこたえてくれたりする。
● ある程度バージョンアップに追随しておけば、security update や大きい bug fix 来
たときなどに、対応しやすい。
● 環境の変化に追随しやすくする
● 現状、GTID や Group Replication がなくても運用できているが、将来はあった方が便利
だろうし
MySQL をバージョンアップする理由
11

EC2 で MySQL を
使うメリット
12

● MySQL は portability が高い。
● オンプレから EC2 に移行できたのも、 portability が高かったから。
● 引き続き EC2 でも素の MySQL を運用するならば、今後の状況に応じて、いろいろな
選択肢を残すことができる。
● MySQL は、時代の変化を見据えつつ、機能や性能を改善している。
● かつて私が入社した頃は、オンプレではHDD で MySQL が動いていて、 MyISAM で
動作しているサーバが、今よりも遥かに多かった。
● それから、 InnoDB やレプリケーションなどが改善された結果、最近のHW の性能を
活かせるように進化してきたので、MySQL 一台あたりの性能が改善し、むかしより集約
して台数を減らしやすくなった。
EC2 で素の MySQL を使うメリット・その１
13

● MySQL は、 Extended Support の期間や、開発のサイクルが明示さ
れている。
● これは重要。何気に超重要。
● パブリッククラウドといえど、 CPU の世代が新しくなると、 kernel や OS を新しくしたく
なる。古い kernel で新しい CPU 使うと、追加された拡張命令で不具合ふんだりするこ
ともある。
● 長年運用しているサービスで新しいOS に移行するのは、工数がかかる。OS の移行
スケジュールと併せて、 MySQL などのアップデートスケジュールを考えていきたい。
● 長期運用しているサービスであれば、OS 入れ替えたりするロードマップなどはちゃんと
考えていきたいので、ライフサイクルがわかりやすいMySQL は、とてもありがたい存
在。
● MySQL は一つのメジャーバージョンに対して８年くらいはメンテンナンスが続く。長期運
用しているサービスとしては、非常に助かる存在。
EC2 で素の MySQL を使うメリット・その２
14

● MyISAM など InnoDB 以外を使っていても、そのまま動かせる。
● MySQL 5.1 以前からやってるサービスでは、古いバックアップデータをたくさん保存す
るために、 ARCHIVE engine の DB が残っていたりする。
● マネージドサービスと異なり、何かあったらソースコードを読めばいい。
● MySQL で気になることがあれば、 MySQL のソースコードや WorkLog 読むし
● TCP 的によくわからないことがあれば、RFC や Linux の kernel 読むし
● OS まるごとチューニングしたり、調査できる余地があるので、何かあった
ときに対応の選択肢が多い。
● マイナーバージョンアップなどの決定権を、自分たちで持てる。
● バージョンアップのスケジュールを、自分たちで管理できるのは楽でいい。
EC2 で素の MySQL を使うメリット・その３
15

● slave だけ先行して新しいバージョンを試しやすい。
● 例えば、 MySQL 5.6 の master に 5.7 の slave をぶら下げて、参照を 5.7 の
slave に向けるような対応がやりやすい。
● DB の統合がやりやすい。
● instance のスケールアップをしつつ、 DB を統合して台数を削減したいとき、MySQL
5.7 の Multi Source Replication がとても使いやすい。
● 何か気になることあったとしても、マネージドサービスと違ってソースコード読めるので、安
心して使える。仮に DB 統合して、想定より高負荷になったとしても、ソースコード読めば
いい。
EC2 で素の MySQL を使うメリット・その４
16

このように、
様々なメリットが
あったのだが・・・
17

● 弊社の一部のサービスは、 EC2 で MySQL を運用していたので、かなり
影響を受けてしまった。
● EC2 で MySQL を使っているところは、 EBS に MySQL の datadir をおいて運用し
ているところがほとんどだったので、多くがEBS の障害に巻き込まれた。
● root volume 、あるいは datadir の volume のいずれかの EBS がハングアップす
ると、そのインスタンスは切り捨てるしかなかった。半死のmysqld が同時に多数発生し
た。
● OS再起動かかったインスタンスもあった。応答しなくなる mysqld もあった。zombie
process になってしまう mysqld もでた。障害が長時間に及んだので、 failover した先の
インスタンスで、 EBS が再びハングアップしてしまうこともあった。
2019-08-23 の東京リージョン大規模障害
18

● もともと、 MySQL の replication は、ネットワークの断に強いという認識
があった。
● master <-> slave 間の replication の接続切れたとしても、自動で再接続できるの
で
● AZ 内で大規模ネットワーク障害が発生しても、ほとんどのreplication は自動で復旧
できるという想定だった。
● かつて、何度か予期せぬ瞬断などは経験したが、 replication は自動復旧できていた。
● しかし、大規模な EBS 障害は、厳しいものだった
● datadir をおいている volume がハングアップすると、 mysqld は使い物にならなくな
る
● 複数の AZ でレプリケーションしていたし、定期的にS3 にバックアップしてたので、いち
おう復旧はできたのだが
MySQL は、断に強いと期待していた
19

現状、
EC2 で MySQL を
運用する上での構成など、
見直しているところです。
20

そして
話は戻って
21

いちおう
お題目通り
22

MySQL の EC2 向け
パラメータチューニング
23

まずは、EC2 向けに
InnoDB の IO を最適化する理由から
24

● 弊社は AWS で MySQL を使うとき、ほとんど EBS は gp2 で運用して
いる。
● たまに I3 インスタンス使っているところもあるが
● baseline で 1000IOPS 出なくても動く DB は、少なからずある
● かつてオンプレでは HDD で動いていた DB を、 EC2 で Multi Source Replication
で統合していったわけで。 gp2 でも HDD よりは性能が良いので。
● gp2 で動かせると、 IO 課金発生しないので、コスト削減に繋がる。
● gp2 は volume size に比例して、ある程度 IO の性能は向上するが、 volume size
は、なるべく必要最小限なままに留めている。その方が安いから。
EC2向けにInnoDBのIOを最適化する・その１
25

● MySQL の master も slave も EBS で動かせると、datadir の
snapshot とるのが楽になる。
● 弊社は伝統的に、アプリケーションサーバから参照されないslave を配置している。
MySQL のバックアップ取るときは、アプリケーションサーバから参照されないslave で
mysqld を停止して、 datadir を tar ball に固めていた。
● EBS であれば、tar ball 取る代わりに、 datadir の volume をまるごと snapshot 取れ
ばいい。
● EBS snapshot は S3 にバックアップされるので、（ S3 は少なくとも3つの AZ でデータが
保存されるから）信頼性も高い。
● slave 構築する際は、その snapshot から datadir 復元できる。
● EBS snapshot で datadir の snapshot 取る仕組みであれば、 snapshot 取るた
めの instance は、とても安価な instance で動かしても良い。
● 具体的には、使えるところは T 系ファミリーの instance を使っている。
● このあたり、若者たちが創意工夫して頑張ってくれました。
EC2向けにInnoDBのIOを最適化する・その2
26

次に、gp2 で
InnoDB 動かす上での
チューニングについて
27

● volume size に比例して I/O の性能が変わる
● 1000GiB 未満の場合、 Credit balance 使い切ると I/O の性能が劣
化する
● EBS は、物理サーバに内蔵されているエンタープライズ向け SSD と比べ
ると、 latency などが不安定になることもある。
● volume size が小さくても Credit balance 残ってれば 3000IOPS で
るので、ピークタイムに Credit balance 使い切らなければ良い。
まずは gp2 について振り返る
28

● IOPS だけでなく、以下のメトリックなども取得する
● VolumeQueueLength, VolumeTotalWriteTime, VolumeTotalReadTime,
BurstBalance
● I/O が重くなって高負荷状態なサーバがあった場合、 I/O クレジット使い
切っているのか、 I/O にかかっている時間が異常なのかを切り分けられ
るようにする
● read/write にかかっている時間が想定よりも長いのであれば、そのサー
バは諦めてサービスから切り離すなどする
● また、 I/O クレジット使い切りそうなサーバがあるならば、 VolumeSize
の見直しなど行う
そして、 gp2 の monitoring をカッチリやる
29

● I/O を削減する方向で、InnoDB のチューニングを行う
● 例：
● innodb_log_file_size=1G
● innodb_io_capacity=100
● innodb_flush_log_at_trx_commit=2
● innodb_flush_neighbors=0
● skip_innodb_doublewrite=1
● サービスに投入する master や slave は、InnoDB のクラッシュリカバ
リに期待しない。台数を並べて冗長性を持たせる。
● EBS で障害が発生すると、そもそもクラッシュリカバリも実施できないから、台数を並べ
て、耐障害性を確保する。
● また、 MySQL 側だけでなく、アプリケーションサーバ側の log を収集しておくなど、別の手
段を担保しておくべきである。
● いずれにせよ、アプリケーションサーバの log は、サポート業務や Analytics のために収
集する必要があるし。
gp2 の I/O クレジットを節約するために
30

● とにかくちょっとでも I/O の burst を避けるために、
innodb_adaptive_flushing_lwm を下げて、ちょっとずつ flush させ
る。
● 例： innodb_adaptive_flushing_lwm=5
● InnoDB Adaptive Flushing で dirty page の flush がはじまって
も、innodb_adaptive_flushing_lwm を下げていると、一秒間に
flush される page の数を減らすことができる。
● innodb_adaptive_flushing_lwm を下げると、 write combining が
効きにくくなるかもしれないが、それは innodb_log_file_size を増やせ
ば良いだけのこと。
● 実際に I/O の burst が発生したとき、 gp2 だと高負荷になってしまう
ケースが有ったので、それの対策で lwm 変えた。
さらに I/O を節約
31

というように、
InnoDB で
I/O 周りの最適化は
できていたのですが
32

現状、そんなことよりも
如何にして
EBS の障害への耐性を
改善するかの方が
重要になってきました。
33

● 古い DB で InnoDB 以外の storage engine も使っていたりするの
で、EC2 で MySQL を使うメリットは、引き続きありますし。
● EBS snapshot で MySQL のバックアップを取るというのは、有効な手
法だと思うので、おそらく今後も使う気がしていますが。
● MySQL の耐障害性をさらに改善することについて、取り組んでいく必要
性を感じています。
● 現時点でも、 master の DB が稼働しているのとは別の AZ に slave 置いて、 S3 に
バックアップ取るようにするなどしていますが
● 中途半端にハングアップしている（アクセスできなくなっている）EBS が大量発生した場
合、なかなか対応が難しい、クラッシュリカバリで救うことも難しそうなので
● じっくり対応を考えていきたいと思っています。
● MySQL は portability が高く、考えられる余地も多いですし。
EBS 障害を受けて、今後の取り組み
34

話はもどって
35

EC2 で
MySQL 動かす上での
Monitoring
36

● volume size から baseline performance を求められるので、IOPS
の複合グラフを描くとき、 baseline performance の補助線を引いてい
てもらってます。
gp2 の monitoring
37

● 弊社は、オンプレでは CPU の clock を P0 state で固定して使ってい
る。
● アプリケーションの response time 改善のため、 clock を落としたくない。
● しかし、パブリッククラウドでは、ホストごと専有しない限り、 CPU の clock
を固定することは難しい。
● そのため、パブリッククラウドでも CPU の clock をメトリックとして保存す
るようにしていたのだが。
● ある日、特定の MySQL の slave だけ CPU の clock がやたら下がっ
てしまい、過負荷になってしまったことがあった。
● それ以来、 CPU の clock が明らかに低いインスタンスがあれば、 alert
を上げるようにしてもらっている。
CPU の clock を監視する
38

● オンプレと比べて、パブリッククラウドでは、どうしてもパケットの再送など
が増えてしまう。
● アプリケーションサーバだけでなく、 MySQL でも、 /proc/net/netstat
における、例えば以下のような metric は注視している
● ListenOverflows
● TCPFastRetrans
● TCPTimeouts
● TCPTimeWaitOverflow
● TCPSynRetrans
TCP のメトリック
39

そして
40

さいきん取り組んでること
41

● 弊社は、MySQL5.1のころから binlog_format=ROW 使っているサー
ビスもあるんですが、ほとんどは binlog_format=STATEMENT でし
た。
● binlog_format=STATEMENT だと、 TRIGGER で online schema change やり
やすいので
● binlog_format=STATEMENT で困っているかというと、そんなに困って
ないんですが
● ただ、さいきんの MySQL は Online DDL が改善されてきましたし、む
かしほど、サービス無停止で online schema change する必要性もなく
なってきているので
● 中長期的に考えて、 statement-based replication（SBR）から
row-based replicaton（RBR）への移行を進めています。
将来を見据えて
42

● ドキュメントには、次のような記述があります。
○ 5.2.4.2 バイナリログ形式の設定
■ レプリケーションの進行中にマスター上のバイナリロギング形式を変更したり、スレーブ上で
それを変更しなかったりすると、予期しない結果を招いたり、レプリケーションの失敗を招くこ
とがあります。
● といったことを踏まえると、安定して binlog_format=ROW にするので
あれば
SBR から RBR への移行
43

新 master を用意して切り替えるのが無難？
44

だがしかし
45

弊社の環境は
台数が多いので
大変すぎる！！
46

そうだ
47

MySQL は OSS なので、
ソースコードを読んで
わたしが挙動を把握できれば
良いのでは？
48

そして、
ソースコードと WorkLog 、
bugs.mysql.com などを
読み漁った
49

概ねわかった
（気がする）
50

● binlog_format=ROW が導入された歴史的経緯
● binlog_format が起因で replication が止まるのはどのような場合か、
また、ソースコード的にはどのあたりでエラーになるのか
● binlog_format=ROW のとき、 binlog event はどのようにしてbinlog
に出力されるのか。
● binlog_format=ROW のとき、 online schema change はどのよう
に対応すればよいか
● binlog_format=ROW のとき、 master と slave で column の型が
異なる場合は、ソースコード的にどのように対処されているか
● binlog_row_image についてくわしく
● などなど
事前に調べたこと
51

● だいぶ真面目に調べたので、この話だけでも 40分では足りません。
● 今日のところは、ソースコード以外で読んだ blog, WorkLog,
bugs.mysql.com のチケット等を列挙しておきます。
● 詳しくは後日、ソースコード交えつつ別のかたちでご紹介したいと思いま
す。
詳しくは
52

● References
○ http://mysqlmusings.blogspot.com/2012/06/binary-log-group-commit-in-mysql-56.html
○ https://bugs.mysql.com/bug.php?id=50935
○ https://dev.mysql.com/worklog/task/?id=4033
○ https://dev.mysql.com/doc/relnotes/mysql/5.7/en/news-5-7-5.html
○ https://dev.mysql.com/doc/relnotes/mysql/5.6/en/news-5-6-20.html
○ https://dev.mysql.com/doc/internals/en/event-data-for-specific-event-types.html
○ https://dev.mysql.com/doc/internals/en/table-map-event.html
RBRに関する資料の一部
53

● 弊社は、サービス無停止で、master 切り替えも行わず
● 稼働中の MySQL に SET GLOBAL binlog_format=ROW を実施し
て
● だいたいの DB が、 SBR から RBR への移行を完了しました。
● 一部の DB は、未だ binlog_format=STATEMENT だったりします
が、今後、じっくり取り組んでいきたいと思います
○ 例：
■ 古いシステムで、 binlog_format=STATEMENT の binlog を監査に使っているものがあ
るので、そういったところは別途対応が必要
その結果
54

こんご
取り組んでいきたいこと
55

1. statement-based replication から row-based replication への移
行
2. MySQL 8.0 への移行
3. GTID への移行
4. Group Replication の導入（時間の都合上、ここだけ補足します）
今後の展望
56

● 現時点において、（個人的に）Group Replication に期待しているところ
大なので、いつか移行したいと思ってます。
● 現在、 MySQL を failover させるためのソフトウェアを社内で内製してい
るのですが、 Group Replication へ移行することで、そのメンテナンスコ
ストを減らせないかな？という期待があります。
● また、 Group Replication を導入したいという、とても大きな理由が一つ
あります。
Group Replication の導入
57

それはなにか？
58

host 側のメンテナンス
あるいは
セキュリティアップデート
59

● IaaS を使っていると、host 側のメンテナンス、あるいはセキュリティアッ
プデートで、パブリッククラウド事業者から reboot を求められることがあり
ます。
● IaaS で動いている mysqld の台数が多いと、その対応コストが看過でき
ないものになります。
● アプリケーションサーバは auto scaling のついでに入れ替えたりできますが、
mysqld のようにデータを永続化するものでは、そうもいきません。
● オンプレでも security update のために kernel update することはあります。しか
し、余裕を持って reboot のスケジュールを自社で考えることが、パブリッククラウドでは
できないこともあります。
● 弊社では、 master の mysqld がメンテナンス対象になった場合、サー
ビス無停止で切り替えたい場合、切り替え先の master & slave のセッ
トを、まるごと新規に構築しています。
scheduled reboot の対応コスト削減
60

● 最近の MySQL の Group Replication は、 Single-Primary Mode
と Multi-Primary Mode を、動的に切り替えられるようになりました
● 普段は Single-Primary Mode で運用して
● primary server がメンテナンス対象になったときだけ、一時的に
Multi-Primary Mode に切り替えて、 primary server を Group
Replication から外せばいいかな、と
● これができると、 IaaS で mysqld 運用するのがグッと楽になるかと
● Group Replication は今後も継続的に改善されていく機能でしょうから、
じっくり腰を据えて取り組んでいければ、と考えています
Group Replication に期待すること
61

● EBS snapshot で datadir のバックアップを取るついでに、 instance
の stop & start ができないか
● scheduled reboot の対象になっても、自動的に対応できるようになるから
● i3 や i3en などのインスタンスを、もっと活用できないか
● いままでは gp2 で安価に運用してきたが、 EBS 障害への耐性を上げたいので
● NVMe 一本専有できるインスタンスを使って、MySQL の datadir をそちらに置けない
かと。
● root volume も datadir も EBS だと、どちらか一方がハングアップしただけで使えな
くなる。しかし、 datadir が local の storage だと、root volume がハングアップしな
い限りは、 EBS の障害に耐えられるようになる。
● また、i3 の NVMe はかなり高性能なので、 Multi-Threaded slave と組み合わせつ
つ、台数を集約できそうな余地はある。
その他、EC2でやっていきたいこと
62

おわり

さいきんのMySQLに関する取り組み（仮）

More Related Content

What's hot

Similar to さいきんのMySQLに関する取り組み（仮）

More from Takanori Sejima

Recently uploaded

さいきんのMySQLに関する取り組み（仮）