Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

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

3,161 views

Published on

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

Published in: Technology
  • Be the first to comment

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

  1. 1. Copyright © GREE, Inc. All Rights Reserved. さいきんの MySQL に関する 取り組み(仮) Takanori Sejima
  2. 2. Copyright © GREE, Inc. All Rights Reserved. 自己紹介 ● わりと MySQL のひと ● 3.23.58 から使ってる ● むかしは Resource Monitoring も力入れてやってた ● ganglia & rrdcached の(たぶん)ヘビーユーザ ● というわけで、自分は Monitoring を大事にする ● 一時期は Flare という OSS の bugfix などもやってた ● さいきんは、ハードウェアの評価をしている時間が長かった ● たまに Linux の TCP プロトコルスタックについて調べたりもする 2
  3. 3. Copyright © GREE, Inc. All Rights Reserved. ● 弊社は、古くからオンプレミス環境で、 MySQL をヘビーに使ってきまし た。 ● 過去に、一部のサービスを AWS に移行した際、マネージドサービスだけ でなく、 EC2 でも MySQL を使う構成にしまして、ここ数年でいくらかノウ ハウが溜まってきた気もします。 ● また、数年先を見据えて取り組んでいることもあります。 ● 今回は、そういったあたり、お話させていただければと思います。 ● わたしはいろいろ変なこと考えてますが、オンプレおじさんなので ● パブリッククラウドでは、若手たちが創意工夫して頑張ってくれてます。 本日のお話 3
  4. 4. Copyright © GREE, Inc. All Rights Reserved. ● MySQL の話をする際、 InnoDB の話を避けるのが難しいので ● まだ読まれたことのない方は ● 次の資料もあわせて読んでいただけると、よりわかりやすいかと思います ● さいきんの InnoDB Adaptive Flushing (仮) ● できればこちらひととおり読んでいただけると、より理解が深まるかと思います ● https://www.slideshare.net/takanorisejima/ 本日のお話の補足資料 4
  5. 5. Copyright © GREE, Inc. All Rights Reserved. ● はじめに ● 弊社の環境など ● EC2 で MySQL を使うメリット ● MySQL の EC2 向けパラメータチューニング ● EC2 で MySQL 動かす上での Monitoring ● さいきん取り組んでいること ● こんご取り組んでいきたいこと Agenda 5
  6. 6. Copyright © GREE, Inc. All Rights Reserved. はじめに 6
  7. 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. 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. 9. Copyright © GREE, Inc. All Rights Reserved. ● 新しいサービスは、パブリッククラウドで立ち上げている。海外展開がしや すかったり、インスタンスの数を柔軟に調整しやすいなどのメリットが有る。 ● その他、かつてオンプレで動いていたサービスの大部分、台数にして 2000台以上のサーバを、 AWS に移行してから数年が経った。 ● 計画停止しにくいものをオンプレで安定稼働させつつ、計画停止できるものを、パブリック クラウドに移行した。 ● オンプレから移行してきたサービスは、マネージドサービスも活用している が、 EC2 で MySQL を立てて運用しているところが多い。 ● MySQL を failover させる仕組みは、パブリッククラウドを使う前から内製していたの で、 failover をマネージドサービスに任せなくても運用できる。 パブリッククラウドの利用状況 9
  10. 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. 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. 12. Copyright © GREE, Inc. All Rights Reserved. EC2 で MySQL を 使うメリット 12
  13. 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. 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. 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. 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. 17. Copyright © GREE, Inc. All Rights Reserved. このように、 様々なメリットが あったのだが・・・ 17
  18. 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. 19. Copyright © GREE, Inc. All Rights Reserved. ● もともと、 MySQL の replication は、ネットワークの断に強いという認識 があった。 ● master <-> slave 間の replication の接続切れたとしても、自動で再接続できるの で ● AZ 内で大規模ネットワーク障害が発生しても、ほとんどのreplication は自動で復旧 できるという想定だった。 ● かつて、何度か予期せぬ瞬断などは経験したが、 replication は自動復旧できていた。 ● しかし、大規模な EBS 障害は、厳しいものだった ● datadir をおいている volume がハングアップすると、 mysqld は使い物にならなくな る ● 複数の AZ でレプリケーションしていたし、定期的にS3 にバックアップしてたので、いち おう復旧はできたのだが MySQL は、断に強いと期待していた 19
  20. 20. Copyright © GREE, Inc. All Rights Reserved. 現状、 EC2 で MySQL を 運用する上での構成など、 見直しているところです。 20
  21. 21. Copyright © GREE, Inc. All Rights Reserved. そして 話は戻って 21
  22. 22. Copyright © GREE, Inc. All Rights Reserved. いちおう お題目通り 22
  23. 23. Copyright © GREE, Inc. All Rights Reserved. MySQL の EC2 向け パラメータチューニング 23
  24. 24. Copyright © GREE, Inc. All Rights Reserved. まずは、EC2 向けに InnoDB の IO を最適化する理由から 24
  25. 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. 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. 27. Copyright © GREE, Inc. All Rights Reserved. 次に、gp2 で InnoDB 動かす上での チューニングについて 27
  28. 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. 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. 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. 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. 32. Copyright © GREE, Inc. All Rights Reserved. というように、 InnoDB で I/O 周りの最適化は できていたのですが 32
  33. 33. Copyright © GREE, Inc. All Rights Reserved. 現状、そんなことよりも 如何にして EBS の障害への耐性を 改善するかの方が 重要になってきました。 33
  34. 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. 35. Copyright © GREE, Inc. All Rights Reserved. 話はもどって 35
  36. 36. Copyright © GREE, Inc. All Rights Reserved. EC2 で MySQL 動かす上での Monitoring 36
  37. 37. Copyright © GREE, Inc. All Rights Reserved. ● volume size から baseline performance を求められるので、IOPS の複合グラフを描くとき、 baseline performance の補助線を引いてい てもらってます。 gp2 の monitoring 37
  38. 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. 39. Copyright © GREE, Inc. All Rights Reserved. ● オンプレと比べて、パブリッククラウドでは、どうしてもパケットの再送など が増えてしまう。 ● アプリケーションサーバだけでなく、 MySQL でも、 /proc/net/netstat における、例えば以下のような metric は注視している ● ListenOverflows ● TCPFastRetrans ● TCPTimeouts ● TCPTimeWaitOverflow ● TCPSynRetrans TCP のメトリック 39
  40. 40. Copyright © GREE, Inc. All Rights Reserved. そして 40
  41. 41. Copyright © GREE, Inc. All Rights Reserved. さいきん取り組んでること 41
  42. 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. 43. Copyright © GREE, Inc. All Rights Reserved. ● ドキュメントには、次のような記述があります。 ○ 5.2.4.2 バイナリログ形式の設定 ■ レプリケーションの進行中にマスター上のバイナリロギング形式を変更したり、スレーブ上で それを変更しなかったりすると、予期しない結果を招いたり、レプリケーションの失敗を招くこ とがあります。 ● といったことを踏まえると、安定して binlog_format=ROW にするので あれば SBR から RBR への移行 43
  44. 44. Copyright © GREE, Inc. All Rights Reserved. 新 master を用意して切り替えるのが無難? 44
  45. 45. Copyright © GREE, Inc. All Rights Reserved. だがしかし 45
  46. 46. Copyright © GREE, Inc. All Rights Reserved. 弊社の環境は 台数が多いので 大変すぎる!! 46
  47. 47. Copyright © GREE, Inc. All Rights Reserved. そうだ 47
  48. 48. Copyright © GREE, Inc. All Rights Reserved. MySQL は OSS なので、 ソースコードを読んで わたしが挙動を把握できれば 良いのでは? 48
  49. 49. Copyright © GREE, Inc. All Rights Reserved. そして、 ソースコードと WorkLog 、 bugs.mysql.com などを 読み漁った 49
  50. 50. Copyright © GREE, Inc. All Rights Reserved. 概ねわかった (気がする) 50
  51. 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. 52. Copyright © GREE, Inc. All Rights Reserved. ● だいぶ真面目に調べたので、この話だけでも 40分では足りません。 ● 今日のところは、ソースコード以外で読んだ blog, WorkLog, bugs.mysql.com のチケット等を列挙しておきます。 ● 詳しくは後日、ソースコード交えつつ別のかたちでご紹介したいと思いま す。 詳しくは 52
  53. 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. 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. 55. Copyright © GREE, Inc. All Rights Reserved. こんご 取り組んでいきたいこと 55
  56. 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. 57. Copyright © GREE, Inc. All Rights Reserved. ● 現時点において、(個人的に)Group Replication に期待しているところ 大なので、いつか移行したいと思ってます。 ● 現在、 MySQL を failover させるためのソフトウェアを社内で内製してい るのですが、 Group Replication へ移行することで、そのメンテナンスコ ストを減らせないかな?という期待があります。 ● また、 Group Replication を導入したいという、とても大きな理由が一つ あります。 Group Replication の導入 57
  58. 58. Copyright © GREE, Inc. All Rights Reserved. それはなにか? 58
  59. 59. Copyright © GREE, Inc. All Rights Reserved. host 側のメンテナンス あるいは セキュリティアップデート 59
  60. 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. 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. 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. 63. Copyright © GREE, Inc. All Rights Reserved. おわり

×