SlideShare a Scribd company logo

さいきんのMySQLに関する取り組み(仮)

さいきんのMySQLに関する取り組みです

1 of 63
Download to read offline
Copyright © GREE, Inc. All Rights Reserved.
さいきんの
MySQL に関する
取り組み(仮)
Takanori Sejima
Copyright © GREE, Inc. All Rights Reserved.
自己紹介
● わりと MySQL のひと
● 3.23.58 から使ってる
● むかしは Resource Monitoring も力入れてやってた
● ganglia & rrdcached の(たぶん)ヘビーユーザ
● というわけで、自分は Monitoring を大事にする
● 一時期は Flare という OSS の bugfix などもやってた
● さいきんは、ハードウェアの評価をしている時間が長かった
● たまに Linux の TCP プロトコルスタックについて調べたりもする
2
Copyright © GREE, Inc. All Rights Reserved.
● 弊社は、古くからオンプレミス環境で、 MySQL をヘビーに使ってきまし
た。
● 過去に、一部のサービスを AWS に移行した際、マネージドサービスだけ
でなく、 EC2 でも MySQL を使う構成にしまして、ここ数年でいくらかノウ
ハウが溜まってきた気もします。
● また、数年先を見据えて取り組んでいることもあります。
● 今回は、そういったあたり、お話させていただければと思います。
● わたしはいろいろ変なこと考えてますが、オンプレおじさんなので
● パブリッククラウドでは、若手たちが創意工夫して頑張ってくれてます。
本日のお話
3
Copyright © GREE, Inc. All Rights Reserved.
● MySQL の話をする際、 InnoDB の話を避けるのが難しいので
● まだ読まれたことのない方は
● 次の資料もあわせて読んでいただけると、よりわかりやすいかと思います
● さいきんの InnoDB Adaptive Flushing (仮)
● できればこちらひととおり読んでいただけると、より理解が深まるかと思います
● https://www.slideshare.net/takanorisejima/
本日のお話の補足資料
4
Copyright © GREE, Inc. All Rights Reserved.
● はじめに
● 弊社の環境など
● EC2 で MySQL を使うメリット
● MySQL の EC2 向けパラメータチューニング
● EC2 で MySQL 動かす上での Monitoring
● さいきん取り組んでいること
● こんご取り組んでいきたいこと
Agenda
5
Copyright © GREE, Inc. All Rights Reserved.
はじめに
6
Copyright © GREE, Inc. All Rights Reserved.
● GREE のサービスは歴史が古い
● むかしから動いてる MySQL のサーバは、かなり sharding されていた
● 2000年代、GREE は SAS HDD 146GB 15krpm * 4本使った RAID10 の前提
で、データベースを設計してるところが多かった
● そういう HDD でも動くように、データベースのサイズは100-200GB 以下のものが多
かった
● 4年くらい前までは、 MySQL 含め、ほとんど HDD で動いていた
● ioDrive ないこともなかったが、全体の数%だった
● かつてほとんど HDD で動いていたことを考えると、最近の block
device は桁違いに性能が良くて、性能面ではとても楽。
むかしの GREE のサーバ
7
Copyright © GREE, Inc. All Rights Reserved.
● ここ数年かけて、ほぼ SATA SSD の環境になった。
● いくらか ioMemory 残っているけど、 Endurance 的には、 1DWPD から 3DWPD
程度の SSD がほとんど。
● ストレージの appliance は使っていない。SSD は SATA直結。
● disk I/O のためにネットワークの traffic が発生しないので、ネットワーク機器が安く上
がる。
● private cloud はやっていない。すべてベアメタル。
● 仮想化しないと、ハードウェアから、kernel - TCP プロトコルスタック - MySQL までの
各レイヤーに対して、調査がしやすい。
● 日本では、ランニングコストのうち、電気代の比率が高い。如何にして消費
電力効率を最適化するか、という戦略を取っている。
● NVMe ではなく SATA の SSD 使っているのも、消費電力が低いから。
さいきんの弊社のオンプレミス環境
8
Copyright © GREE, Inc. All Rights Reserved.
● 新しいサービスは、パブリッククラウドで立ち上げている。海外展開がしや
すかったり、インスタンスの数を柔軟に調整しやすいなどのメリットが有る。
● その他、かつてオンプレで動いていたサービスの大部分、台数にして
2000台以上のサーバを、 AWS に移行してから数年が経った。
● 計画停止しにくいものをオンプレで安定稼働させつつ、計画停止できるものを、パブリック
クラウドに移行した。
● オンプレから移行してきたサービスは、マネージドサービスも活用している
が、 EC2 で MySQL を立てて運用しているところが多い。
● MySQL を failover させる仕組みは、パブリッククラウドを使う前から内製していたの
で、 failover をマネージドサービスに任せなくても運用できる。
パブリッククラウドの利用状況
9
Copyright © GREE, Inc. All Rights Reserved.
● 現状、MySQL 5.6 か 5.7 を使っている。大部分が 5.7。
● MySQL 8.0 は検証中。
● MySQL の Extended Support の期間を意識して新しいバージョンに
移行するというより、可能であれば新しいメジャーバージョンに移行してい
きたいと考えている。
● MySQL のメジャーバージョンは、 Extended Support が終了するまでの間、 GA が
出てからだいたい8年くらいは、 security update がリリースされる。
弊社のMySQL利用状況
10
Copyright © GREE, Inc. All Rights Reserved.
● 次のようなものが挙げられる
● Multi Source Replication など、コスト削減につながる機能が追加される。
● Multi Source Replication のおかげで、 DB の統合がとても楽になった。
● バージョンを追うごとに、 InnoDB が mutex の競合に強くなっている。メジャーバー
ジョンアップにより、 InnoDB をより堅牢強固にすることができる
● アプリケーションの不具合や障害などで、意図せず InnoDB が高負荷状態になってしまうこ
とがたまにある。しかし、さいきんの InnoDB は、 innodb_thread_concurrency などを
適切にチューニングしておけば、それでもなんとか持ちこたえてくれたりする。
● ある程度バージョンアップに追随しておけば、security update や大きい bug fix 来
たときなどに、対応しやすい。
● 環境の変化に追随しやすくする
● 現状、GTID や Group Replication がなくても運用できているが、将来はあった方が便利
だろうし
MySQL をバージョンアップする理由
11
Copyright © GREE, Inc. All Rights Reserved.
EC2 で MySQL を
使うメリット
12
Copyright © GREE, Inc. All Rights Reserved.
● MySQL は portability が高い。
● オンプレから EC2 に移行できたのも、 portability が高かったから。
● 引き続き EC2 でも素の MySQL を運用するならば、今後の状況に応じて、いろいろな
選択肢を残すことができる。
● MySQL は、時代の変化を見据えつつ、機能や性能を改善している。
● かつて私が入社した頃は、オンプレではHDD で MySQL が動いていて、 MyISAM で
動作しているサーバが、今よりも遥かに多かった。
● それから、 InnoDB やレプリケーションなどが改善された結果、最近のHW の性能を
活かせるように進化してきたので、MySQL 一台あたりの性能が改善し、むかしより集約
して台数を減らしやすくなった。
EC2 で素の MySQL を使うメリット・その1
13
Copyright © GREE, Inc. All Rights Reserved.
● MySQL は、 Extended Support の期間や、開発のサイクルが明示さ
れている。
● これは重要。何気に超重要。
● パブリッククラウドといえど、 CPU の世代が新しくなると、 kernel や OS を新しくしたく
なる。古い kernel で新しい CPU 使うと、追加された拡張命令で不具合ふんだりするこ
ともある。
● 長年運用しているサービスで新しいOS に移行するのは、工数がかかる。OS の移行
スケジュールと併せて、 MySQL などのアップデートスケジュールを考えていきたい。
● 長期運用しているサービスであれば、OS 入れ替えたりするロードマップなどはちゃんと
考えていきたいので、ライフサイクルがわかりやすいMySQL は、とてもありがたい存
在。
● MySQL は一つのメジャーバージョンに対して8年くらいはメンテンナンスが続く。長期運
用しているサービスとしては、非常に助かる存在。
EC2 で素の MySQL を使うメリット・その2
14
Copyright © GREE, Inc. All Rights Reserved.
● MyISAM など InnoDB 以外を使っていても、そのまま動かせる。
● MySQL 5.1 以前からやってるサービスでは、古いバックアップデータをたくさん保存す
るために、 ARCHIVE engine の DB が残っていたりする。
● マネージドサービスと異なり、何かあったらソースコードを読めばいい。
● MySQL で気になることがあれば、 MySQL のソースコードや WorkLog 読むし
● TCP 的によくわからないことがあれば、RFC や Linux の kernel 読むし
● OS まるごとチューニングしたり、調査できる余地があるので、何かあった
ときに対応の選択肢が多い。
● マイナーバージョンアップなどの決定権を、自分たちで持てる。
● バージョンアップのスケジュールを、自分たちで管理できるのは楽でいい。
EC2 で素の MySQL を使うメリット・その3
15
Copyright © GREE, Inc. All Rights Reserved.
● slave だけ先行して新しいバージョンを試しやすい。
● 例えば、 MySQL 5.6 の master に 5.7 の slave をぶら下げて、参照を 5.7 の
slave に向けるような対応がやりやすい。
● DB の統合がやりやすい。
● instance のスケールアップをしつつ、 DB を統合して台数を削減したいとき、MySQL
5.7 の Multi Source Replication がとても使いやすい。
● 何か気になることあったとしても、マネージドサービスと違ってソースコード読めるので、安
心して使える。仮に DB 統合して、想定より高負荷になったとしても、ソースコード読めば
いい。
EC2 で素の MySQL を使うメリット・その4
16
Copyright © GREE, Inc. All Rights Reserved.
このように、
様々なメリットが
あったのだが・・・
17
Copyright © GREE, Inc. All Rights Reserved.
● 弊社の一部のサービスは、 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
Copyright © GREE, Inc. All Rights Reserved.
● もともと、 MySQL の replication は、ネットワークの断に強いという認識
があった。
● master <-> slave 間の replication の接続切れたとしても、自動で再接続できるの
で
● AZ 内で大規模ネットワーク障害が発生しても、ほとんどのreplication は自動で復旧
できるという想定だった。
● かつて、何度か予期せぬ瞬断などは経験したが、 replication は自動復旧できていた。
● しかし、大規模な EBS 障害は、厳しいものだった
● datadir をおいている volume がハングアップすると、 mysqld は使い物にならなくな
る
● 複数の AZ でレプリケーションしていたし、定期的にS3 にバックアップしてたので、いち
おう復旧はできたのだが
MySQL は、断に強いと期待していた
19
Copyright © GREE, Inc. All Rights Reserved.
現状、
EC2 で MySQL を
運用する上での構成など、
見直しているところです。
20
Copyright © GREE, Inc. All Rights Reserved.
そして
話は戻って
21
Copyright © GREE, Inc. All Rights Reserved.
いちおう
お題目通り
22
Copyright © GREE, Inc. All Rights Reserved.
MySQL の EC2 向け
パラメータチューニング
23
Copyright © GREE, Inc. All Rights Reserved.
まずは、EC2 向けに
InnoDB の IO を最適化する理由から
24
Copyright © GREE, Inc. All Rights Reserved.
● 弊社は 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を最適化する・その1
25
Copyright © GREE, Inc. All Rights Reserved.
● 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
Copyright © GREE, Inc. All Rights Reserved.
次に、gp2 で
InnoDB 動かす上での
チューニングについて
27
Copyright © GREE, Inc. All Rights Reserved.
● volume size に比例して I/O の性能が変わる
● 1000GiB 未満の場合、 Credit balance 使い切ると I/O の性能が劣
化する
● EBS は、物理サーバに内蔵されているエンタープライズ向け SSD と比べ
ると、 latency などが不安定になることもある。
● volume size が小さくても Credit balance 残ってれば 3000IOPS で
るので、ピークタイムに Credit balance 使い切らなければ良い。
まずは gp2 について振り返る
28
Copyright © GREE, Inc. All Rights Reserved.
● IOPS だけでなく、以下のメトリックなども取得する
● VolumeQueueLength, VolumeTotalWriteTime, VolumeTotalReadTime,
BurstBalance
● I/O が重くなって高負荷状態なサーバがあった場合、 I/O クレジット使い
切っているのか、 I/O にかかっている時間が異常なのかを切り分けられ
るようにする
● read/write にかかっている時間が想定よりも長いのであれば、そのサー
バは諦めてサービスから切り離すなどする
● また、 I/O クレジット使い切りそうなサーバがあるならば、 VolumeSize
の見直しなど行う
そして、 gp2 の monitoring をカッチリやる
29
Copyright © GREE, Inc. All Rights Reserved.
● 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
Copyright © GREE, Inc. All Rights Reserved.
● とにかくちょっとでも 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
Copyright © GREE, Inc. All Rights Reserved.
というように、
InnoDB で
I/O 周りの最適化は
できていたのですが
32
Copyright © GREE, Inc. All Rights Reserved.
現状、そんなことよりも
如何にして
EBS の障害への耐性を
改善するかの方が
重要になってきました。
33
Copyright © GREE, Inc. All Rights Reserved.
● 古い DB で InnoDB 以外の storage engine も使っていたりするの
で、EC2 で MySQL を使うメリットは、引き続きありますし。
● EBS snapshot で MySQL のバックアップを取るというのは、有効な手
法だと思うので、おそらく今後も使う気がしていますが。
● MySQL の耐障害性をさらに改善することについて、取り組んでいく必要
性を感じています。
● 現時点でも、 master の DB が稼働しているのとは別の AZ に slave 置いて、 S3 に
バックアップ取るようにするなどしていますが
● 中途半端にハングアップしている(アクセスできなくなっている)EBS が大量発生した場
合、なかなか対応が難しい、クラッシュリカバリで救うことも難しそうなので
● じっくり対応を考えていきたいと思っています。
● MySQL は portability が高く、考えられる余地も多いですし。
EBS 障害を受けて、今後の取り組み
34
Copyright © GREE, Inc. All Rights Reserved.
話はもどって
35
Copyright © GREE, Inc. All Rights Reserved.
EC2 で
MySQL 動かす上での
Monitoring
36
Copyright © GREE, Inc. All Rights Reserved.
● volume size から baseline performance を求められるので、IOPS
の複合グラフを描くとき、 baseline performance の補助線を引いてい
てもらってます。
gp2 の monitoring
37
Copyright © GREE, Inc. All Rights Reserved.
● 弊社は、オンプレでは CPU の clock を P0 state で固定して使ってい
る。
● アプリケーションの response time 改善のため、 clock を落としたくない。
● しかし、パブリッククラウドでは、ホストごと専有しない限り、 CPU の clock
を固定することは難しい。
● そのため、パブリッククラウドでも CPU の clock をメトリックとして保存す
るようにしていたのだが。
● ある日、特定の MySQL の slave だけ CPU の clock がやたら下がっ
てしまい、過負荷になってしまったことがあった。
● それ以来、 CPU の clock が明らかに低いインスタンスがあれば、 alert
を上げるようにしてもらっている。
CPU の clock を監視する
38
Copyright © GREE, Inc. All Rights Reserved.
● オンプレと比べて、パブリッククラウドでは、どうしてもパケットの再送など
が増えてしまう。
● アプリケーションサーバだけでなく、 MySQL でも、 /proc/net/netstat
における、例えば以下のような metric は注視している
● ListenOverflows
● TCPFastRetrans
● TCPTimeouts
● TCPTimeWaitOverflow
● TCPSynRetrans
TCP のメトリック
39
Copyright © GREE, Inc. All Rights Reserved.
そして
40
Copyright © GREE, Inc. All Rights Reserved.
さいきん取り組んでること
41
Copyright © GREE, Inc. All Rights Reserved.
● 弊社は、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
Copyright © GREE, Inc. All Rights Reserved.
● ドキュメントには、次のような記述があります。
○ 5.2.4.2 バイナリログ形式の設定
■ レプリケーションの進行中にマスター上のバイナリロギング形式を変更したり、スレーブ上で
それを変更しなかったりすると、予期しない結果を招いたり、レプリケーションの失敗を招くこ
とがあります。
● といったことを踏まえると、安定して binlog_format=ROW にするので
あれば
SBR から RBR への移行
43
Copyright © GREE, Inc. All Rights Reserved.
新 master を用意して切り替えるのが無難?
44
Copyright © GREE, Inc. All Rights Reserved.
だがしかし
45
Copyright © GREE, Inc. All Rights Reserved.
弊社の環境は
台数が多いので
大変すぎる!!
46
Copyright © GREE, Inc. All Rights Reserved.
そうだ
47
Copyright © GREE, Inc. All Rights Reserved.
MySQL は OSS なので、
ソースコードを読んで
わたしが挙動を把握できれば
良いのでは?
48
Copyright © GREE, Inc. All Rights Reserved.
そして、
ソースコードと WorkLog 、
bugs.mysql.com などを
読み漁った
49
Copyright © GREE, Inc. All Rights Reserved.
概ねわかった
(気がする)
50
Copyright © GREE, Inc. All Rights Reserved.
● 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
Copyright © GREE, Inc. All Rights Reserved.
● だいぶ真面目に調べたので、この話だけでも 40分では足りません。
● 今日のところは、ソースコード以外で読んだ blog, WorkLog,
bugs.mysql.com のチケット等を列挙しておきます。
● 詳しくは後日、ソースコード交えつつ別のかたちでご紹介したいと思いま
す。
詳しくは
52
Copyright © GREE, Inc. All Rights Reserved.
● 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/worklog/task/?id=5404
○ https://bugs.mysql.com/bug.php?id=23051
○ https://dev.mysql.com/worklog/task/?id=3339
○ https://dev.mysql.com/worklog/task/?id=3303
○ 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://bugs.mysql.com/bug.php?id=85371
○ https://dev.mysql.com/doc/internals/en/event-data-for-specific-event-types.html
○ https://dev.mysql.com/worklog/task/?id=5092
○ https://dev.mysql.com/worklog/task/?id=3915
○ https://dev.mysql.com/doc/internals/en/table-map-event.html
RBRに関する資料の一部
53
Copyright © GREE, Inc. All Rights Reserved.
● 弊社は、サービス無停止で、master 切り替えも行わず
● 稼働中の MySQL に SET GLOBAL binlog_format=ROW を実施し
て
● だいたいの DB が、 SBR から RBR への移行を完了しました。
● 一部の DB は、未だ binlog_format=STATEMENT だったりします
が、今後、じっくり取り組んでいきたいと思います
○ 例:
■ 古いシステムで、 binlog_format=STATEMENT の binlog を監査に使っているものがあ
るので、そういったところは別途対応が必要
その結果
54
Copyright © GREE, Inc. All Rights Reserved.
こんご
取り組んでいきたいこと
55
Copyright © GREE, Inc. All Rights Reserved.
1. statement-based replication から row-based replication への移
行
2. MySQL 8.0 への移行
3. GTID への移行
4. Group Replication の導入(時間の都合上、ここだけ補足します)
今後の展望
56
Copyright © GREE, Inc. All Rights Reserved.
● 現時点において、(個人的に)Group Replication に期待しているところ
大なので、いつか移行したいと思ってます。
● 現在、 MySQL を failover させるためのソフトウェアを社内で内製してい
るのですが、 Group Replication へ移行することで、そのメンテナンスコ
ストを減らせないかな?という期待があります。
● また、 Group Replication を導入したいという、とても大きな理由が一つ
あります。
Group Replication の導入
57
Copyright © GREE, Inc. All Rights Reserved.
それはなにか?
58
Copyright © GREE, Inc. All Rights Reserved.
host 側のメンテナンス
あるいは
セキュリティアップデート
59
Copyright © GREE, Inc. All Rights Reserved.
● IaaS を使っていると、host 側のメンテナンス、あるいはセキュリティアッ
プデートで、パブリッククラウド事業者から reboot を求められることがあり
ます。
● IaaS で動いている mysqld の台数が多いと、その対応コストが看過でき
ないものになります。
● アプリケーションサーバは auto scaling のついでに入れ替えたりできますが、
mysqld のようにデータを永続化するものでは、そうもいきません。
● オンプレでも security update のために kernel update することはあります。しか
し、余裕を持って reboot のスケジュールを自社で考えることが、パブリッククラウドでは
できないこともあります。
● 弊社では、 master の mysqld がメンテナンス対象になった場合、サー
ビス無停止で切り替えたい場合、切り替え先の master & slave のセッ
トを、まるごと新規に構築しています。
scheduled reboot の対応コスト削減
60
Copyright © GREE, Inc. All Rights Reserved.
● 最近の 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
Copyright © GREE, Inc. All Rights Reserved.
● 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
Copyright © GREE, Inc. All Rights Reserved.
おわり

Recommended

PostgreSQLのロール管理とその注意点(Open Source Conference 2022 Online/Osaka 発表資料)
PostgreSQLのロール管理とその注意点(Open Source Conference 2022 Online/Osaka 発表資料)PostgreSQLのロール管理とその注意点(Open Source Conference 2022 Online/Osaka 発表資料)
PostgreSQLのロール管理とその注意点(Open Source Conference 2022 Online/Osaka 発表資料)NTT DATA Technology & Innovation
 
PGOを用いたPostgreSQL on Kubernetes入門(PostgreSQL Conference Japan 2022 発表資料)
PGOを用いたPostgreSQL on Kubernetes入門(PostgreSQL Conference Japan 2022 発表資料)PGOを用いたPostgreSQL on Kubernetes入門(PostgreSQL Conference Japan 2022 発表資料)
PGOを用いたPostgreSQL on Kubernetes入門(PostgreSQL Conference Japan 2022 発表資料)NTT DATA Technology & Innovation
 
コンテナネットワーキング(CNI)最前線
コンテナネットワーキング(CNI)最前線コンテナネットワーキング(CNI)最前線
コンテナネットワーキング(CNI)最前線Motonori Shindo
 
Linux女子部 systemd徹底入門
Linux女子部 systemd徹底入門Linux女子部 systemd徹底入門
Linux女子部 systemd徹底入門Etsuji Nakai
 
最近のOpenStackを振り返ってみよう
最近のOpenStackを振り返ってみよう最近のOpenStackを振り返ってみよう
最近のOpenStackを振り返ってみようTakashi Kajinami
 
OpenStackで始めるクラウド環境構築入門
OpenStackで始めるクラウド環境構築入門OpenStackで始めるクラウド環境構築入門
OpenStackで始めるクラウド環境構築入門VirtualTech Japan Inc.
 
コンテナを止めるな! PacemakerによるコンテナHAクラスタリングとKubernetesとの違いとは
コンテナを止めるな!  PacemakerによるコンテナHAクラスタリングとKubernetesとの違いとはコンテナを止めるな!  PacemakerによるコンテナHAクラスタリングとKubernetesとの違いとは
コンテナを止めるな! PacemakerによるコンテナHAクラスタリングとKubernetesとの違いとはksk_ha
 

More Related Content

What's hot

PostgreSQLのリカバリ超入門(もしくはWAL、CHECKPOINT、オンラインバックアップの仕組み)
PostgreSQLのリカバリ超入門(もしくはWAL、CHECKPOINT、オンラインバックアップの仕組み)PostgreSQLのリカバリ超入門(もしくはWAL、CHECKPOINT、オンラインバックアップの仕組み)
PostgreSQLのリカバリ超入門(もしくはWAL、CHECKPOINT、オンラインバックアップの仕組み)Hironobu Suzuki
 
TIME_WAITに関する話
TIME_WAITに関する話TIME_WAITに関する話
TIME_WAITに関する話Takanori Sejima
 
レプリケーション遅延の監視について(第40回PostgreSQLアンカンファレンス@オンライン 発表資料)
レプリケーション遅延の監視について(第40回PostgreSQLアンカンファレンス@オンライン 発表資料)レプリケーション遅延の監視について(第40回PostgreSQLアンカンファレンス@オンライン 発表資料)
レプリケーション遅延の監視について(第40回PostgreSQLアンカンファレンス@オンライン 発表資料)NTT DATA Technology & Innovation
 
PG-REXで学ぶPacemaker運用の実例
PG-REXで学ぶPacemaker運用の実例PG-REXで学ぶPacemaker運用の実例
PG-REXで学ぶPacemaker運用の実例kazuhcurry
 
InnoDBのすゝめ(仮)
InnoDBのすゝめ(仮)InnoDBのすゝめ(仮)
InnoDBのすゝめ(仮)Takanori Sejima
 
アーキテクチャから理解するPostgreSQLのレプリケーション
アーキテクチャから理解するPostgreSQLのレプリケーションアーキテクチャから理解するPostgreSQLのレプリケーション
アーキテクチャから理解するPostgreSQLのレプリケーションMasahiko Sawada
 
PostgreSQL16新機能紹介 - libpq接続ロード・バランシング(第41回PostgreSQLアンカンファレンス@オンライン 発表資料)
PostgreSQL16新機能紹介 - libpq接続ロード・バランシング(第41回PostgreSQLアンカンファレンス@オンライン 発表資料)PostgreSQL16新機能紹介 - libpq接続ロード・バランシング(第41回PostgreSQLアンカンファレンス@オンライン 発表資料)
PostgreSQL16新機能紹介 - libpq接続ロード・バランシング(第41回PostgreSQLアンカンファレンス@オンライン 発表資料)NTT DATA Technology & Innovation
 
オンライン物理バックアップの排他モードと非排他モードについて ~PostgreSQLバージョン15対応版~(第34回PostgreSQLアンカンファレンス...
オンライン物理バックアップの排他モードと非排他モードについて ~PostgreSQLバージョン15対応版~(第34回PostgreSQLアンカンファレンス...オンライン物理バックアップの排他モードと非排他モードについて ~PostgreSQLバージョン15対応版~(第34回PostgreSQLアンカンファレンス...
オンライン物理バックアップの排他モードと非排他モードについて ~PostgreSQLバージョン15対応版~(第34回PostgreSQLアンカンファレンス...NTT DATA Technology & Innovation
 
Kubernetesのしくみ やさしく学ぶ 内部構造とアーキテクチャー
Kubernetesのしくみ やさしく学ぶ 内部構造とアーキテクチャーKubernetesのしくみ やさしく学ぶ 内部構造とアーキテクチャー
Kubernetesのしくみ やさしく学ぶ 内部構造とアーキテクチャーToru Makabe
 
PostgreSQL 15 開発最新情報
PostgreSQL 15 開発最新情報PostgreSQL 15 開発最新情報
PostgreSQL 15 開発最新情報Masahiko Sawada
 
AlmaLinux と Rocky Linux の誕生経緯&比較
AlmaLinux と Rocky Linux の誕生経緯&比較AlmaLinux と Rocky Linux の誕生経緯&比較
AlmaLinux と Rocky Linux の誕生経緯&比較beyond Co., Ltd.
 
OpenStackをさらに”使う”技術 概要と基礎操作
OpenStackをさらに”使う”技術 概要と基礎操作OpenStackをさらに”使う”技術 概要と基礎操作
OpenStackをさらに”使う”技術 概要と基礎操作irix_jp
 
分散システムについて語らせてくれ
分散システムについて語らせてくれ分散システムについて語らせてくれ
分散システムについて語らせてくれKumazaki Hiroki
 
速習!論理レプリケーション ~基礎から最新動向まで~(PostgreSQL Conference Japan 2022 発表資料)
速習!論理レプリケーション ~基礎から最新動向まで~(PostgreSQL Conference Japan 2022 発表資料)速習!論理レプリケーション ~基礎から最新動向まで~(PostgreSQL Conference Japan 2022 発表資料)
速習!論理レプリケーション ~基礎から最新動向まで~(PostgreSQL Conference Japan 2022 発表資料)NTT DATA Technology & Innovation
 
オンライン物理バックアップの排他モードと非排他モードについて(第15回PostgreSQLアンカンファレンス@オンライン 発表資料)
オンライン物理バックアップの排他モードと非排他モードについて(第15回PostgreSQLアンカンファレンス@オンライン 発表資料)オンライン物理バックアップの排他モードと非排他モードについて(第15回PostgreSQLアンカンファレンス@オンライン 発表資料)
オンライン物理バックアップの排他モードと非排他モードについて(第15回PostgreSQLアンカンファレンス@オンライン 発表資料)NTT DATA Technology & Innovation
 
本当は恐ろしい分散システムの話
本当は恐ろしい分散システムの話本当は恐ろしい分散システムの話
本当は恐ろしい分散システムの話Kumazaki Hiroki
 

What's hot (20)

PostgreSQLのリカバリ超入門(もしくはWAL、CHECKPOINT、オンラインバックアップの仕組み)
PostgreSQLのリカバリ超入門(もしくはWAL、CHECKPOINT、オンラインバックアップの仕組み)PostgreSQLのリカバリ超入門(もしくはWAL、CHECKPOINT、オンラインバックアップの仕組み)
PostgreSQLのリカバリ超入門(もしくはWAL、CHECKPOINT、オンラインバックアップの仕組み)
 
TIME_WAITに関する話
TIME_WAITに関する話TIME_WAITに関する話
TIME_WAITに関する話
 
レプリケーション遅延の監視について(第40回PostgreSQLアンカンファレンス@オンライン 発表資料)
レプリケーション遅延の監視について(第40回PostgreSQLアンカンファレンス@オンライン 発表資料)レプリケーション遅延の監視について(第40回PostgreSQLアンカンファレンス@オンライン 発表資料)
レプリケーション遅延の監視について(第40回PostgreSQLアンカンファレンス@オンライン 発表資料)
 
ゼロからはじめるKVM超入門
ゼロからはじめるKVM超入門ゼロからはじめるKVM超入門
ゼロからはじめるKVM超入門
 
PG-REXで学ぶPacemaker運用の実例
PG-REXで学ぶPacemaker運用の実例PG-REXで学ぶPacemaker運用の実例
PG-REXで学ぶPacemaker運用の実例
 
InnoDBのすゝめ(仮)
InnoDBのすゝめ(仮)InnoDBのすゝめ(仮)
InnoDBのすゝめ(仮)
 
アーキテクチャから理解するPostgreSQLのレプリケーション
アーキテクチャから理解するPostgreSQLのレプリケーションアーキテクチャから理解するPostgreSQLのレプリケーション
アーキテクチャから理解するPostgreSQLのレプリケーション
 
PostgreSQL16新機能紹介 - libpq接続ロード・バランシング(第41回PostgreSQLアンカンファレンス@オンライン 発表資料)
PostgreSQL16新機能紹介 - libpq接続ロード・バランシング(第41回PostgreSQLアンカンファレンス@オンライン 発表資料)PostgreSQL16新機能紹介 - libpq接続ロード・バランシング(第41回PostgreSQLアンカンファレンス@オンライン 発表資料)
PostgreSQL16新機能紹介 - libpq接続ロード・バランシング(第41回PostgreSQLアンカンファレンス@オンライン 発表資料)
 
オンライン物理バックアップの排他モードと非排他モードについて ~PostgreSQLバージョン15対応版~(第34回PostgreSQLアンカンファレンス...
オンライン物理バックアップの排他モードと非排他モードについて ~PostgreSQLバージョン15対応版~(第34回PostgreSQLアンカンファレンス...オンライン物理バックアップの排他モードと非排他モードについて ~PostgreSQLバージョン15対応版~(第34回PostgreSQLアンカンファレンス...
オンライン物理バックアップの排他モードと非排他モードについて ~PostgreSQLバージョン15対応版~(第34回PostgreSQLアンカンファレンス...
 
Kubernetesのしくみ やさしく学ぶ 内部構造とアーキテクチャー
Kubernetesのしくみ やさしく学ぶ 内部構造とアーキテクチャーKubernetesのしくみ やさしく学ぶ 内部構造とアーキテクチャー
Kubernetesのしくみ やさしく学ぶ 内部構造とアーキテクチャー
 
PostgreSQL 15 開発最新情報
PostgreSQL 15 開発最新情報PostgreSQL 15 開発最新情報
PostgreSQL 15 開発最新情報
 
AlmaLinux と Rocky Linux の誕生経緯&比較
AlmaLinux と Rocky Linux の誕生経緯&比較AlmaLinux と Rocky Linux の誕生経緯&比較
AlmaLinux と Rocky Linux の誕生経緯&比較
 
PostgreSQLレプリケーション徹底紹介
PostgreSQLレプリケーション徹底紹介PostgreSQLレプリケーション徹底紹介
PostgreSQLレプリケーション徹底紹介
 
TripleO Deep Dive
TripleO Deep DiveTripleO Deep Dive
TripleO Deep Dive
 
OpenStackをさらに”使う”技術 概要と基礎操作
OpenStackをさらに”使う”技術 概要と基礎操作OpenStackをさらに”使う”技術 概要と基礎操作
OpenStackをさらに”使う”技術 概要と基礎操作
 
分散システムについて語らせてくれ
分散システムについて語らせてくれ分散システムについて語らせてくれ
分散システムについて語らせてくれ
 
PostgreSQLの運用・監視にまつわるエトセトラ
PostgreSQLの運用・監視にまつわるエトセトラPostgreSQLの運用・監視にまつわるエトセトラ
PostgreSQLの運用・監視にまつわるエトセトラ
 
速習!論理レプリケーション ~基礎から最新動向まで~(PostgreSQL Conference Japan 2022 発表資料)
速習!論理レプリケーション ~基礎から最新動向まで~(PostgreSQL Conference Japan 2022 発表資料)速習!論理レプリケーション ~基礎から最新動向まで~(PostgreSQL Conference Japan 2022 発表資料)
速習!論理レプリケーション ~基礎から最新動向まで~(PostgreSQL Conference Japan 2022 発表資料)
 
オンライン物理バックアップの排他モードと非排他モードについて(第15回PostgreSQLアンカンファレンス@オンライン 発表資料)
オンライン物理バックアップの排他モードと非排他モードについて(第15回PostgreSQLアンカンファレンス@オンライン 発表資料)オンライン物理バックアップの排他モードと非排他モードについて(第15回PostgreSQLアンカンファレンス@オンライン 発表資料)
オンライン物理バックアップの排他モードと非排他モードについて(第15回PostgreSQLアンカンファレンス@オンライン 発表資料)
 
本当は恐ろしい分散システムの話
本当は恐ろしい分散システムの話本当は恐ろしい分散システムの話
本当は恐ろしい分散システムの話
 

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

MySQLやSSDとかの話 前編
MySQLやSSDとかの話 前編MySQLやSSDとかの話 前編
MySQLやSSDとかの話 前編Takanori Sejima
 
GAE + Spannerで目指せ No (Uncomfortable) Ops
GAE + Spannerで目指せ No (Uncomfortable) OpsGAE + Spannerで目指せ No (Uncomfortable) Ops
GAE + Spannerで目指せ No (Uncomfortable) OpsMiniascape
 
Osc 2021 fall_tis_変化に強いチーム育成のための取り組み紹介
Osc 2021 fall_tis_変化に強いチーム育成のための取り組み紹介Osc 2021 fall_tis_変化に強いチーム育成のための取り組み紹介
Osc 2021 fall_tis_変化に強いチーム育成のための取り組み紹介Daisuke Ikeda
 
MySQLやSSDとかの話 その後
MySQLやSSDとかの話 その後MySQLやSSDとかの話 その後
MySQLやSSDとかの話 その後Takanori Sejima
 
AWS re:invent振り返りServerlessでサーバコスト以外もいろいろ削減
AWS re:invent振り返りServerlessでサーバコスト以外もいろいろ削減AWS re:invent振り返りServerlessでサーバコスト以外もいろいろ削減
AWS re:invent振り返りServerlessでサーバコスト以外もいろいろ削減gree_tech
 
Jenkins+Gitによる検証済みマージ(30分版)
Jenkins+Gitによる検証済みマージ(30分版)Jenkins+Gitによる検証済みマージ(30分版)
Jenkins+Gitによる検証済みマージ(30分版)Kohsuke Kawaguchi
 
[Aws]database migration seminar_20191008
[Aws]database migration seminar_20191008[Aws]database migration seminar_20191008
[Aws]database migration seminar_20191008Toru Kimura
 
MySQLやSSDとかの話 後編
MySQLやSSDとかの話 後編MySQLやSSDとかの話 後編
MySQLやSSDとかの話 後編Takanori Sejima
 
ゲームのインフラをAwsで実戦tips全て見せます
ゲームのインフラをAwsで実戦tips全て見せますゲームのインフラをAwsで実戦tips全て見せます
ゲームのインフラをAwsで実戦tips全て見せますinfinite_loop
 
sysloadや監視などの話(仮)
sysloadや監視などの話(仮)sysloadや監視などの話(仮)
sysloadや監視などの話(仮)Takanori Sejima
 
今、改めて考えるPostgreSQLプラットフォーム - マルチクラウドとポータビリティ -(PostgreSQL Conference Japan 20...
今、改めて考えるPostgreSQLプラットフォーム - マルチクラウドとポータビリティ -(PostgreSQL Conference Japan 20...今、改めて考えるPostgreSQLプラットフォーム - マルチクラウドとポータビリティ -(PostgreSQL Conference Japan 20...
今、改めて考えるPostgreSQLプラットフォーム - マルチクラウドとポータビリティ -(PostgreSQL Conference Japan 20...NTT DATA Technology & Innovation
 
[A31]AWS上でOracleを利用するためのはじめの一歩!by Masatoshi Yoshida
[A31]AWS上でOracleを利用するためのはじめの一歩!by Masatoshi Yoshida[A31]AWS上でOracleを利用するためのはじめの一歩!by Masatoshi Yoshida
[A31]AWS上でOracleを利用するためのはじめの一歩!by Masatoshi YoshidaInsight Technology, Inc.
 
Drソリューション(ナレッジコミュニケーション)
Drソリューション(ナレッジコミュニケーション)Drソリューション(ナレッジコミュニケーション)
Drソリューション(ナレッジコミュニケーション)nao-k
 
MySQLやSSDとかの話・後編
MySQLやSSDとかの話・後編MySQLやSSDとかの話・後編
MySQLやSSDとかの話・後編gree_tech
 
スマートフォン×Cassandraによるハイパフォーマンス基盤の構築事例
スマートフォン×Cassandraによるハイパフォーマンス基盤の構築事例スマートフォン×Cassandraによるハイパフォーマンス基盤の構築事例
スマートフォン×Cassandraによるハイパフォーマンス基盤の構築事例terurou
 
20171109 Amazon EC2 GPUインスタンス最新動向 P3 instance
20171109 Amazon EC2 GPUインスタンス最新動向 P3 instance20171109 Amazon EC2 GPUインスタンス最新動向 P3 instance
20171109 Amazon EC2 GPUインスタンス最新動向 P3 instanceAmazon Web Services Japan
 
インフラエンジニアデイ Sousousha20100520 01
インフラエンジニアデイ Sousousha20100520 01インフラエンジニアデイ Sousousha20100520 01
インフラエンジニアデイ Sousousha20100520 01真一 藤川
 
Lv1から始めるWebサービスのインフラ構築
Lv1から始めるWebサービスのインフラ構築Lv1から始めるWebサービスのインフラ構築
Lv1から始めるWebサービスのインフラ構築伊藤 祐策
 

Similar to さいきんのMySQLに関する取り組み(仮) (20)

MySQLやSSDとかの話 前編
MySQLやSSDとかの話 前編MySQLやSSDとかの話 前編
MySQLやSSDとかの話 前編
 
GAE + Spannerで目指せ No (Uncomfortable) Ops
GAE + Spannerで目指せ No (Uncomfortable) OpsGAE + Spannerで目指せ No (Uncomfortable) Ops
GAE + Spannerで目指せ No (Uncomfortable) Ops
 
Osc 2021 fall_tis_変化に強いチーム育成のための取り組み紹介
Osc 2021 fall_tis_変化に強いチーム育成のための取り組み紹介Osc 2021 fall_tis_変化に強いチーム育成のための取り組み紹介
Osc 2021 fall_tis_変化に強いチーム育成のための取り組み紹介
 
MySQLやSSDとかの話 その後
MySQLやSSDとかの話 その後MySQLやSSDとかの話 その後
MySQLやSSDとかの話 その後
 
Reinvent2017 recap-overview-pdf
Reinvent2017 recap-overview-pdfReinvent2017 recap-overview-pdf
Reinvent2017 recap-overview-pdf
 
AWS re:invent振り返りServerlessでサーバコスト以外もいろいろ削減
AWS re:invent振り返りServerlessでサーバコスト以外もいろいろ削減AWS re:invent振り返りServerlessでサーバコスト以外もいろいろ削減
AWS re:invent振り返りServerlessでサーバコスト以外もいろいろ削減
 
Jenkins+Gitによる検証済みマージ(30分版)
Jenkins+Gitによる検証済みマージ(30分版)Jenkins+Gitによる検証済みマージ(30分版)
Jenkins+Gitによる検証済みマージ(30分版)
 
[Aws]database migration seminar_20191008
[Aws]database migration seminar_20191008[Aws]database migration seminar_20191008
[Aws]database migration seminar_20191008
 
MySQLやSSDとかの話 後編
MySQLやSSDとかの話 後編MySQLやSSDとかの話 後編
MySQLやSSDとかの話 後編
 
ゲームのインフラをAwsで実戦tips全て見せます
ゲームのインフラをAwsで実戦tips全て見せますゲームのインフラをAwsで実戦tips全て見せます
ゲームのインフラをAwsで実戦tips全て見せます
 
sysloadや監視などの話(仮)
sysloadや監視などの話(仮)sysloadや監視などの話(仮)
sysloadや監視などの話(仮)
 
今、改めて考えるPostgreSQLプラットフォーム - マルチクラウドとポータビリティ -(PostgreSQL Conference Japan 20...
今、改めて考えるPostgreSQLプラットフォーム - マルチクラウドとポータビリティ -(PostgreSQL Conference Japan 20...今、改めて考えるPostgreSQLプラットフォーム - マルチクラウドとポータビリティ -(PostgreSQL Conference Japan 20...
今、改めて考えるPostgreSQLプラットフォーム - マルチクラウドとポータビリティ -(PostgreSQL Conference Japan 20...
 
[A31]AWS上でOracleを利用するためのはじめの一歩!by Masatoshi Yoshida
[A31]AWS上でOracleを利用するためのはじめの一歩!by Masatoshi Yoshida[A31]AWS上でOracleを利用するためのはじめの一歩!by Masatoshi Yoshida
[A31]AWS上でOracleを利用するためのはじめの一歩!by Masatoshi Yoshida
 
Drソリューション(ナレッジコミュニケーション)
Drソリューション(ナレッジコミュニケーション)Drソリューション(ナレッジコミュニケーション)
Drソリューション(ナレッジコミュニケーション)
 
MySQLやSSDとかの話・後編
MySQLやSSDとかの話・後編MySQLやSSDとかの話・後編
MySQLやSSDとかの話・後編
 
スマートフォン×Cassandraによるハイパフォーマンス基盤の構築事例
スマートフォン×Cassandraによるハイパフォーマンス基盤の構築事例スマートフォン×Cassandraによるハイパフォーマンス基盤の構築事例
スマートフォン×Cassandraによるハイパフォーマンス基盤の構築事例
 
Docomo Cloud Package
Docomo Cloud PackageDocomo Cloud Package
Docomo Cloud Package
 
20171109 Amazon EC2 GPUインスタンス最新動向 P3 instance
20171109 Amazon EC2 GPUインスタンス最新動向 P3 instance20171109 Amazon EC2 GPUインスタンス最新動向 P3 instance
20171109 Amazon EC2 GPUインスタンス最新動向 P3 instance
 
インフラエンジニアデイ Sousousha20100520 01
インフラエンジニアデイ Sousousha20100520 01インフラエンジニアデイ Sousousha20100520 01
インフラエンジニアデイ Sousousha20100520 01
 
Lv1から始めるWebサービスのインフラ構築
Lv1から始めるWebサービスのインフラ構築Lv1から始めるWebサービスのインフラ構築
Lv1から始めるWebサービスのインフラ構築
 

More from Takanori Sejima

NAND Flash から InnoDB にかけての話(仮)
NAND Flash から InnoDB にかけての話(仮)NAND Flash から InnoDB にかけての話(仮)
NAND Flash から InnoDB にかけての話(仮)Takanori Sejima
 
さいきんの InnoDB Adaptive Flushing (仮)
さいきんの InnoDB Adaptive Flushing (仮)さいきんの InnoDB Adaptive Flushing (仮)
さいきんの InnoDB Adaptive Flushing (仮)Takanori Sejima
 
binary log と 2PC と Group Commit
binary log と 2PC と Group Commitbinary log と 2PC と Group Commit
binary log と 2PC と Group CommitTakanori Sejima
 
MySQL5.7 GA の Multi-threaded slave
MySQL5.7 GA の Multi-threaded slaveMySQL5.7 GA の Multi-threaded slave
MySQL5.7 GA の Multi-threaded slaveTakanori Sejima
 
InnoDB Table Compression
InnoDB Table CompressionInnoDB Table Compression
InnoDB Table CompressionTakanori Sejima
 
EthernetやCPUなどの話
EthernetやCPUなどの話EthernetやCPUなどの話
EthernetやCPUなどの話Takanori Sejima
 
5.6 以前の InnoDB Flushing
5.6 以前の InnoDB Flushing5.6 以前の InnoDB Flushing
5.6 以前の InnoDB FlushingTakanori Sejima
 

More from Takanori Sejima (8)

NAND Flash から InnoDB にかけての話(仮)
NAND Flash から InnoDB にかけての話(仮)NAND Flash から InnoDB にかけての話(仮)
NAND Flash から InnoDB にかけての話(仮)
 
さいきんの InnoDB Adaptive Flushing (仮)
さいきんの InnoDB Adaptive Flushing (仮)さいきんの InnoDB Adaptive Flushing (仮)
さいきんの InnoDB Adaptive Flushing (仮)
 
binary log と 2PC と Group Commit
binary log と 2PC と Group Commitbinary log と 2PC と Group Commit
binary log と 2PC と Group Commit
 
MySQL5.7 GA の Multi-threaded slave
MySQL5.7 GA の Multi-threaded slaveMySQL5.7 GA の Multi-threaded slave
MySQL5.7 GA の Multi-threaded slave
 
InnoDB Table Compression
InnoDB Table CompressionInnoDB Table Compression
InnoDB Table Compression
 
EthernetやCPUなどの話
EthernetやCPUなどの話EthernetやCPUなどの話
EthernetやCPUなどの話
 
CPUに関する話
CPUに関する話CPUに関する話
CPUに関する話
 
5.6 以前の InnoDB Flushing
5.6 以前の InnoDB Flushing5.6 以前の InnoDB Flushing
5.6 以前の InnoDB Flushing
 

Recently uploaded

BusTimeTable by Edge Runtime - 公共交通オープンデータ最前線2024 -
BusTimeTable by Edge Runtime - 公共交通オープンデータ最前線2024 -BusTimeTable by Edge Runtime - 公共交通オープンデータ最前線2024 -
BusTimeTable by Edge Runtime - 公共交通オープンデータ最前線2024 -yuutahatano
 
00001_test_automation_portfolio_20240227
00001_test_automation_portfolio_2024022700001_test_automation_portfolio_20240227
00001_test_automation_portfolio_20240227ssuserf8ea02
 
COPY FROMで異常データをスキップできるようになった話(第45回 PostgreSQLアンカンファレンス@オンライン 発表資料)
COPY FROMで異常データをスキップできるようになった話(第45回 PostgreSQLアンカンファレンス@オンライン 発表資料)COPY FROMで異常データをスキップできるようになった話(第45回 PostgreSQLアンカンファレンス@オンライン 発表資料)
COPY FROMで異常データをスキップできるようになった話(第45回 PostgreSQLアンカンファレンス@オンライン 発表資料)NTT DATA Technology & Innovation
 
20240227 完全に理解した LT 「mise いいよ mise」 / morishin
20240227 完全に理解した LT 「mise いいよ mise」 / morishin20240227 完全に理解した LT 「mise いいよ mise」 / morishin
20240227 完全に理解した LT 「mise いいよ mise」 / morishinMakoto Mori
 
Kubernetes環境のアプリケーションバックアップソフトウェアKasten K10ご紹介
Kubernetes環境のアプリケーションバックアップソフトウェアKasten K10ご紹介Kubernetes環境のアプリケーションバックアップソフトウェアKasten K10ご紹介
Kubernetes環境のアプリケーションバックアップソフトウェアKasten K10ご紹介FumieNakayama
 
20240227_IoTLT_vol108____kitazaki_v1.pdf
20240227_IoTLT_vol108____kitazaki_v1.pdf20240227_IoTLT_vol108____kitazaki_v1.pdf
20240227_IoTLT_vol108____kitazaki_v1.pdfAyachika Kitazaki
 

Recently uploaded (6)

BusTimeTable by Edge Runtime - 公共交通オープンデータ最前線2024 -
BusTimeTable by Edge Runtime - 公共交通オープンデータ最前線2024 -BusTimeTable by Edge Runtime - 公共交通オープンデータ最前線2024 -
BusTimeTable by Edge Runtime - 公共交通オープンデータ最前線2024 -
 
00001_test_automation_portfolio_20240227
00001_test_automation_portfolio_2024022700001_test_automation_portfolio_20240227
00001_test_automation_portfolio_20240227
 
COPY FROMで異常データをスキップできるようになった話(第45回 PostgreSQLアンカンファレンス@オンライン 発表資料)
COPY FROMで異常データをスキップできるようになった話(第45回 PostgreSQLアンカンファレンス@オンライン 発表資料)COPY FROMで異常データをスキップできるようになった話(第45回 PostgreSQLアンカンファレンス@オンライン 発表資料)
COPY FROMで異常データをスキップできるようになった話(第45回 PostgreSQLアンカンファレンス@オンライン 発表資料)
 
20240227 完全に理解した LT 「mise いいよ mise」 / morishin
20240227 完全に理解した LT 「mise いいよ mise」 / morishin20240227 完全に理解した LT 「mise いいよ mise」 / morishin
20240227 完全に理解した LT 「mise いいよ mise」 / morishin
 
Kubernetes環境のアプリケーションバックアップソフトウェアKasten K10ご紹介
Kubernetes環境のアプリケーションバックアップソフトウェアKasten K10ご紹介Kubernetes環境のアプリケーションバックアップソフトウェアKasten K10ご紹介
Kubernetes環境のアプリケーションバックアップソフトウェアKasten K10ご紹介
 
20240227_IoTLT_vol108____kitazaki_v1.pdf
20240227_IoTLT_vol108____kitazaki_v1.pdf20240227_IoTLT_vol108____kitazaki_v1.pdf
20240227_IoTLT_vol108____kitazaki_v1.pdf
 

さいきんのMySQLに関する取り組み(仮)

  • 1. Copyright © GREE, Inc. All Rights Reserved. さいきんの MySQL に関する 取り組み(仮) Takanori Sejima
  • 2. Copyright © GREE, Inc. All Rights Reserved. 自己紹介 ● わりと MySQL のひと ● 3.23.58 から使ってる ● むかしは Resource Monitoring も力入れてやってた ● ganglia & rrdcached の(たぶん)ヘビーユーザ ● というわけで、自分は Monitoring を大事にする ● 一時期は Flare という OSS の bugfix などもやってた ● さいきんは、ハードウェアの評価をしている時間が長かった ● たまに Linux の TCP プロトコルスタックについて調べたりもする 2
  • 3. Copyright © GREE, Inc. All Rights Reserved. ● 弊社は、古くからオンプレミス環境で、 MySQL をヘビーに使ってきまし た。 ● 過去に、一部のサービスを AWS に移行した際、マネージドサービスだけ でなく、 EC2 でも MySQL を使う構成にしまして、ここ数年でいくらかノウ ハウが溜まってきた気もします。 ● また、数年先を見据えて取り組んでいることもあります。 ● 今回は、そういったあたり、お話させていただければと思います。 ● わたしはいろいろ変なこと考えてますが、オンプレおじさんなので ● パブリッククラウドでは、若手たちが創意工夫して頑張ってくれてます。 本日のお話 3
  • 4. Copyright © GREE, Inc. All Rights Reserved. ● MySQL の話をする際、 InnoDB の話を避けるのが難しいので ● まだ読まれたことのない方は ● 次の資料もあわせて読んでいただけると、よりわかりやすいかと思います ● さいきんの InnoDB Adaptive Flushing (仮) ● できればこちらひととおり読んでいただけると、より理解が深まるかと思います ● https://www.slideshare.net/takanorisejima/ 本日のお話の補足資料 4
  • 5. Copyright © GREE, Inc. All Rights Reserved. ● はじめに ● 弊社の環境など ● EC2 で MySQL を使うメリット ● MySQL の EC2 向けパラメータチューニング ● EC2 で MySQL 動かす上での Monitoring ● さいきん取り組んでいること ● こんご取り組んでいきたいこと Agenda 5
  • 6. Copyright © GREE, Inc. All Rights Reserved. はじめに 6
  • 7. Copyright © GREE, Inc. All Rights Reserved. ● GREE のサービスは歴史が古い ● むかしから動いてる MySQL のサーバは、かなり sharding されていた ● 2000年代、GREE は SAS HDD 146GB 15krpm * 4本使った RAID10 の前提 で、データベースを設計してるところが多かった ● そういう HDD でも動くように、データベースのサイズは100-200GB 以下のものが多 かった ● 4年くらい前までは、 MySQL 含め、ほとんど HDD で動いていた ● ioDrive ないこともなかったが、全体の数%だった ● かつてほとんど HDD で動いていたことを考えると、最近の block device は桁違いに性能が良くて、性能面ではとても楽。 むかしの GREE のサーバ 7
  • 8. Copyright © GREE, Inc. All Rights Reserved. ● ここ数年かけて、ほぼ SATA SSD の環境になった。 ● いくらか ioMemory 残っているけど、 Endurance 的には、 1DWPD から 3DWPD 程度の SSD がほとんど。 ● ストレージの appliance は使っていない。SSD は SATA直結。 ● disk I/O のためにネットワークの traffic が発生しないので、ネットワーク機器が安く上 がる。 ● private cloud はやっていない。すべてベアメタル。 ● 仮想化しないと、ハードウェアから、kernel - TCP プロトコルスタック - MySQL までの 各レイヤーに対して、調査がしやすい。 ● 日本では、ランニングコストのうち、電気代の比率が高い。如何にして消費 電力効率を最適化するか、という戦略を取っている。 ● NVMe ではなく SATA の SSD 使っているのも、消費電力が低いから。 さいきんの弊社のオンプレミス環境 8
  • 9. Copyright © GREE, Inc. All Rights Reserved. ● 新しいサービスは、パブリッククラウドで立ち上げている。海外展開がしや すかったり、インスタンスの数を柔軟に調整しやすいなどのメリットが有る。 ● その他、かつてオンプレで動いていたサービスの大部分、台数にして 2000台以上のサーバを、 AWS に移行してから数年が経った。 ● 計画停止しにくいものをオンプレで安定稼働させつつ、計画停止できるものを、パブリック クラウドに移行した。 ● オンプレから移行してきたサービスは、マネージドサービスも活用している が、 EC2 で MySQL を立てて運用しているところが多い。 ● MySQL を failover させる仕組みは、パブリッククラウドを使う前から内製していたの で、 failover をマネージドサービスに任せなくても運用できる。 パブリッククラウドの利用状況 9
  • 10. Copyright © GREE, Inc. All Rights Reserved. ● 現状、MySQL 5.6 か 5.7 を使っている。大部分が 5.7。 ● MySQL 8.0 は検証中。 ● MySQL の Extended Support の期間を意識して新しいバージョンに 移行するというより、可能であれば新しいメジャーバージョンに移行してい きたいと考えている。 ● MySQL のメジャーバージョンは、 Extended Support が終了するまでの間、 GA が 出てからだいたい8年くらいは、 security update がリリースされる。 弊社のMySQL利用状況 10
  • 11. Copyright © GREE, Inc. All Rights Reserved. ● 次のようなものが挙げられる ● Multi Source Replication など、コスト削減につながる機能が追加される。 ● Multi Source Replication のおかげで、 DB の統合がとても楽になった。 ● バージョンを追うごとに、 InnoDB が mutex の競合に強くなっている。メジャーバー ジョンアップにより、 InnoDB をより堅牢強固にすることができる ● アプリケーションの不具合や障害などで、意図せず InnoDB が高負荷状態になってしまうこ とがたまにある。しかし、さいきんの InnoDB は、 innodb_thread_concurrency などを 適切にチューニングしておけば、それでもなんとか持ちこたえてくれたりする。 ● ある程度バージョンアップに追随しておけば、security update や大きい bug fix 来 たときなどに、対応しやすい。 ● 環境の変化に追随しやすくする ● 現状、GTID や Group Replication がなくても運用できているが、将来はあった方が便利 だろうし MySQL をバージョンアップする理由 11
  • 12. Copyright © GREE, Inc. All Rights Reserved. EC2 で MySQL を 使うメリット 12
  • 13. Copyright © GREE, Inc. All Rights Reserved. ● MySQL は portability が高い。 ● オンプレから EC2 に移行できたのも、 portability が高かったから。 ● 引き続き EC2 でも素の MySQL を運用するならば、今後の状況に応じて、いろいろな 選択肢を残すことができる。 ● MySQL は、時代の変化を見据えつつ、機能や性能を改善している。 ● かつて私が入社した頃は、オンプレではHDD で MySQL が動いていて、 MyISAM で 動作しているサーバが、今よりも遥かに多かった。 ● それから、 InnoDB やレプリケーションなどが改善された結果、最近のHW の性能を 活かせるように進化してきたので、MySQL 一台あたりの性能が改善し、むかしより集約 して台数を減らしやすくなった。 EC2 で素の MySQL を使うメリット・その1 13
  • 14. Copyright © GREE, Inc. All Rights Reserved. ● MySQL は、 Extended Support の期間や、開発のサイクルが明示さ れている。 ● これは重要。何気に超重要。 ● パブリッククラウドといえど、 CPU の世代が新しくなると、 kernel や OS を新しくしたく なる。古い kernel で新しい CPU 使うと、追加された拡張命令で不具合ふんだりするこ ともある。 ● 長年運用しているサービスで新しいOS に移行するのは、工数がかかる。OS の移行 スケジュールと併せて、 MySQL などのアップデートスケジュールを考えていきたい。 ● 長期運用しているサービスであれば、OS 入れ替えたりするロードマップなどはちゃんと 考えていきたいので、ライフサイクルがわかりやすいMySQL は、とてもありがたい存 在。 ● MySQL は一つのメジャーバージョンに対して8年くらいはメンテンナンスが続く。長期運 用しているサービスとしては、非常に助かる存在。 EC2 で素の MySQL を使うメリット・その2 14
  • 15. Copyright © GREE, Inc. All Rights Reserved. ● MyISAM など InnoDB 以外を使っていても、そのまま動かせる。 ● MySQL 5.1 以前からやってるサービスでは、古いバックアップデータをたくさん保存す るために、 ARCHIVE engine の DB が残っていたりする。 ● マネージドサービスと異なり、何かあったらソースコードを読めばいい。 ● MySQL で気になることがあれば、 MySQL のソースコードや WorkLog 読むし ● TCP 的によくわからないことがあれば、RFC や Linux の kernel 読むし ● OS まるごとチューニングしたり、調査できる余地があるので、何かあった ときに対応の選択肢が多い。 ● マイナーバージョンアップなどの決定権を、自分たちで持てる。 ● バージョンアップのスケジュールを、自分たちで管理できるのは楽でいい。 EC2 で素の MySQL を使うメリット・その3 15
  • 16. Copyright © GREE, Inc. All Rights Reserved. ● slave だけ先行して新しいバージョンを試しやすい。 ● 例えば、 MySQL 5.6 の master に 5.7 の slave をぶら下げて、参照を 5.7 の slave に向けるような対応がやりやすい。 ● DB の統合がやりやすい。 ● instance のスケールアップをしつつ、 DB を統合して台数を削減したいとき、MySQL 5.7 の Multi Source Replication がとても使いやすい。 ● 何か気になることあったとしても、マネージドサービスと違ってソースコード読めるので、安 心して使える。仮に DB 統合して、想定より高負荷になったとしても、ソースコード読めば いい。 EC2 で素の MySQL を使うメリット・その4 16
  • 17. Copyright © GREE, Inc. All Rights Reserved. このように、 様々なメリットが あったのだが・・・ 17
  • 18. Copyright © GREE, Inc. All Rights Reserved. ● 弊社の一部のサービスは、 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
  • 19. Copyright © GREE, Inc. All Rights Reserved. ● もともと、 MySQL の replication は、ネットワークの断に強いという認識 があった。 ● master <-> slave 間の replication の接続切れたとしても、自動で再接続できるの で ● AZ 内で大規模ネットワーク障害が発生しても、ほとんどのreplication は自動で復旧 できるという想定だった。 ● かつて、何度か予期せぬ瞬断などは経験したが、 replication は自動復旧できていた。 ● しかし、大規模な EBS 障害は、厳しいものだった ● datadir をおいている volume がハングアップすると、 mysqld は使い物にならなくな る ● 複数の AZ でレプリケーションしていたし、定期的にS3 にバックアップしてたので、いち おう復旧はできたのだが MySQL は、断に強いと期待していた 19
  • 20. Copyright © GREE, Inc. All Rights Reserved. 現状、 EC2 で MySQL を 運用する上での構成など、 見直しているところです。 20
  • 21. Copyright © GREE, Inc. All Rights Reserved. そして 話は戻って 21
  • 22. Copyright © GREE, Inc. All Rights Reserved. いちおう お題目通り 22
  • 23. Copyright © GREE, Inc. All Rights Reserved. MySQL の EC2 向け パラメータチューニング 23
  • 24. Copyright © GREE, Inc. All Rights Reserved. まずは、EC2 向けに InnoDB の IO を最適化する理由から 24
  • 25. Copyright © GREE, Inc. All Rights Reserved. ● 弊社は 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を最適化する・その1 25
  • 26. Copyright © GREE, Inc. All Rights Reserved. ● 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
  • 27. Copyright © GREE, Inc. All Rights Reserved. 次に、gp2 で InnoDB 動かす上での チューニングについて 27
  • 28. Copyright © GREE, Inc. All Rights Reserved. ● volume size に比例して I/O の性能が変わる ● 1000GiB 未満の場合、 Credit balance 使い切ると I/O の性能が劣 化する ● EBS は、物理サーバに内蔵されているエンタープライズ向け SSD と比べ ると、 latency などが不安定になることもある。 ● volume size が小さくても Credit balance 残ってれば 3000IOPS で るので、ピークタイムに Credit balance 使い切らなければ良い。 まずは gp2 について振り返る 28
  • 29. Copyright © GREE, Inc. All Rights Reserved. ● IOPS だけでなく、以下のメトリックなども取得する ● VolumeQueueLength, VolumeTotalWriteTime, VolumeTotalReadTime, BurstBalance ● I/O が重くなって高負荷状態なサーバがあった場合、 I/O クレジット使い 切っているのか、 I/O にかかっている時間が異常なのかを切り分けられ るようにする ● read/write にかかっている時間が想定よりも長いのであれば、そのサー バは諦めてサービスから切り離すなどする ● また、 I/O クレジット使い切りそうなサーバがあるならば、 VolumeSize の見直しなど行う そして、 gp2 の monitoring をカッチリやる 29
  • 30. Copyright © GREE, Inc. All Rights Reserved. ● 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
  • 31. Copyright © GREE, Inc. All Rights Reserved. ● とにかくちょっとでも 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
  • 32. Copyright © GREE, Inc. All Rights Reserved. というように、 InnoDB で I/O 周りの最適化は できていたのですが 32
  • 33. Copyright © GREE, Inc. All Rights Reserved. 現状、そんなことよりも 如何にして EBS の障害への耐性を 改善するかの方が 重要になってきました。 33
  • 34. Copyright © GREE, Inc. All Rights Reserved. ● 古い DB で InnoDB 以外の storage engine も使っていたりするの で、EC2 で MySQL を使うメリットは、引き続きありますし。 ● EBS snapshot で MySQL のバックアップを取るというのは、有効な手 法だと思うので、おそらく今後も使う気がしていますが。 ● MySQL の耐障害性をさらに改善することについて、取り組んでいく必要 性を感じています。 ● 現時点でも、 master の DB が稼働しているのとは別の AZ に slave 置いて、 S3 に バックアップ取るようにするなどしていますが ● 中途半端にハングアップしている(アクセスできなくなっている)EBS が大量発生した場 合、なかなか対応が難しい、クラッシュリカバリで救うことも難しそうなので ● じっくり対応を考えていきたいと思っています。 ● MySQL は portability が高く、考えられる余地も多いですし。 EBS 障害を受けて、今後の取り組み 34
  • 35. Copyright © GREE, Inc. All Rights Reserved. 話はもどって 35
  • 36. Copyright © GREE, Inc. All Rights Reserved. EC2 で MySQL 動かす上での Monitoring 36
  • 37. Copyright © GREE, Inc. All Rights Reserved. ● volume size から baseline performance を求められるので、IOPS の複合グラフを描くとき、 baseline performance の補助線を引いてい てもらってます。 gp2 の monitoring 37
  • 38. Copyright © GREE, Inc. All Rights Reserved. ● 弊社は、オンプレでは CPU の clock を P0 state で固定して使ってい る。 ● アプリケーションの response time 改善のため、 clock を落としたくない。 ● しかし、パブリッククラウドでは、ホストごと専有しない限り、 CPU の clock を固定することは難しい。 ● そのため、パブリッククラウドでも CPU の clock をメトリックとして保存す るようにしていたのだが。 ● ある日、特定の MySQL の slave だけ CPU の clock がやたら下がっ てしまい、過負荷になってしまったことがあった。 ● それ以来、 CPU の clock が明らかに低いインスタンスがあれば、 alert を上げるようにしてもらっている。 CPU の clock を監視する 38
  • 39. Copyright © GREE, Inc. All Rights Reserved. ● オンプレと比べて、パブリッククラウドでは、どうしてもパケットの再送など が増えてしまう。 ● アプリケーションサーバだけでなく、 MySQL でも、 /proc/net/netstat における、例えば以下のような metric は注視している ● ListenOverflows ● TCPFastRetrans ● TCPTimeouts ● TCPTimeWaitOverflow ● TCPSynRetrans TCP のメトリック 39
  • 40. Copyright © GREE, Inc. All Rights Reserved. そして 40
  • 41. Copyright © GREE, Inc. All Rights Reserved. さいきん取り組んでること 41
  • 42. Copyright © GREE, Inc. All Rights Reserved. ● 弊社は、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
  • 43. Copyright © GREE, Inc. All Rights Reserved. ● ドキュメントには、次のような記述があります。 ○ 5.2.4.2 バイナリログ形式の設定 ■ レプリケーションの進行中にマスター上のバイナリロギング形式を変更したり、スレーブ上で それを変更しなかったりすると、予期しない結果を招いたり、レプリケーションの失敗を招くこ とがあります。 ● といったことを踏まえると、安定して binlog_format=ROW にするので あれば SBR から RBR への移行 43
  • 44. Copyright © GREE, Inc. All Rights Reserved. 新 master を用意して切り替えるのが無難? 44
  • 45. Copyright © GREE, Inc. All Rights Reserved. だがしかし 45
  • 46. Copyright © GREE, Inc. All Rights Reserved. 弊社の環境は 台数が多いので 大変すぎる!! 46
  • 47. Copyright © GREE, Inc. All Rights Reserved. そうだ 47
  • 48. Copyright © GREE, Inc. All Rights Reserved. MySQL は OSS なので、 ソースコードを読んで わたしが挙動を把握できれば 良いのでは? 48
  • 49. Copyright © GREE, Inc. All Rights Reserved. そして、 ソースコードと WorkLog 、 bugs.mysql.com などを 読み漁った 49
  • 50. Copyright © GREE, Inc. All Rights Reserved. 概ねわかった (気がする) 50
  • 51. Copyright © GREE, Inc. All Rights Reserved. ● 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
  • 52. Copyright © GREE, Inc. All Rights Reserved. ● だいぶ真面目に調べたので、この話だけでも 40分では足りません。 ● 今日のところは、ソースコード以外で読んだ blog, WorkLog, bugs.mysql.com のチケット等を列挙しておきます。 ● 詳しくは後日、ソースコード交えつつ別のかたちでご紹介したいと思いま す。 詳しくは 52
  • 53. Copyright © GREE, Inc. All Rights Reserved. ● 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/worklog/task/?id=5404 ○ https://bugs.mysql.com/bug.php?id=23051 ○ https://dev.mysql.com/worklog/task/?id=3339 ○ https://dev.mysql.com/worklog/task/?id=3303 ○ 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://bugs.mysql.com/bug.php?id=85371 ○ https://dev.mysql.com/doc/internals/en/event-data-for-specific-event-types.html ○ https://dev.mysql.com/worklog/task/?id=5092 ○ https://dev.mysql.com/worklog/task/?id=3915 ○ https://dev.mysql.com/doc/internals/en/table-map-event.html RBRに関する資料の一部 53
  • 54. Copyright © GREE, Inc. All Rights Reserved. ● 弊社は、サービス無停止で、master 切り替えも行わず ● 稼働中の MySQL に SET GLOBAL binlog_format=ROW を実施し て ● だいたいの DB が、 SBR から RBR への移行を完了しました。 ● 一部の DB は、未だ binlog_format=STATEMENT だったりします が、今後、じっくり取り組んでいきたいと思います ○ 例: ■ 古いシステムで、 binlog_format=STATEMENT の binlog を監査に使っているものがあ るので、そういったところは別途対応が必要 その結果 54
  • 55. Copyright © GREE, Inc. All Rights Reserved. こんご 取り組んでいきたいこと 55
  • 56. Copyright © GREE, Inc. All Rights Reserved. 1. statement-based replication から row-based replication への移 行 2. MySQL 8.0 への移行 3. GTID への移行 4. Group Replication の導入(時間の都合上、ここだけ補足します) 今後の展望 56
  • 57. Copyright © GREE, Inc. All Rights Reserved. ● 現時点において、(個人的に)Group Replication に期待しているところ 大なので、いつか移行したいと思ってます。 ● 現在、 MySQL を failover させるためのソフトウェアを社内で内製してい るのですが、 Group Replication へ移行することで、そのメンテナンスコ ストを減らせないかな?という期待があります。 ● また、 Group Replication を導入したいという、とても大きな理由が一つ あります。 Group Replication の導入 57
  • 58. Copyright © GREE, Inc. All Rights Reserved. それはなにか? 58
  • 59. Copyright © GREE, Inc. All Rights Reserved. host 側のメンテナンス あるいは セキュリティアップデート 59
  • 60. Copyright © GREE, Inc. All Rights Reserved. ● IaaS を使っていると、host 側のメンテナンス、あるいはセキュリティアッ プデートで、パブリッククラウド事業者から reboot を求められることがあり ます。 ● IaaS で動いている mysqld の台数が多いと、その対応コストが看過でき ないものになります。 ● アプリケーションサーバは auto scaling のついでに入れ替えたりできますが、 mysqld のようにデータを永続化するものでは、そうもいきません。 ● オンプレでも security update のために kernel update することはあります。しか し、余裕を持って reboot のスケジュールを自社で考えることが、パブリッククラウドでは できないこともあります。 ● 弊社では、 master の mysqld がメンテナンス対象になった場合、サー ビス無停止で切り替えたい場合、切り替え先の master & slave のセッ トを、まるごと新規に構築しています。 scheduled reboot の対応コスト削減 60
  • 61. Copyright © GREE, Inc. All Rights Reserved. ● 最近の 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
  • 62. Copyright © GREE, Inc. All Rights Reserved. ● 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
  • 63. Copyright © GREE, Inc. All Rights Reserved. おわり