MySQLやSSDとかの話 前編

MySQLやSSDとかの話です

Transcript

1. Copyright © GREE, Inc. All Rights Reserved. MySQLやSSDとかの話 前編 Takanori Sejima
2. Copyright © GREE, Inc. All Rights Reserved. 自己紹介 • わりとMySQLのひと • 3.23.58 から使ってる • むかしは Resource Monitoring も力入れてやってた • ganglia & rrdcached の（たぶん）ヘビーユーザ • 5年くらい前から使い始めた • gmond は素のまま使ってる • gmetad は欲しい機能がなかったので patch 書いた • webfrontend はほぼ書き直した • あとはひたすら python module 書いた • ganglia じゃなくても良かったんだけど、とにかく rrdcached を使いたかった • というわけで、自分は Monitoring を大事にする • 一時期は Flare という OSS の bugfix などもやってた
3. Copyright © GREE, Inc. All Rights Reserved. • 古いサーバを、新しくて性能の良いサーバに置き換えていく際、いろいろ工 夫して集約していっているのですが • そのあたりの背景や取り組みなどについて、本日はお話しようと思います • オンプレミス環境の話になっちゃうんですが • 一部は、オンプレミス環境じゃなくても応用が効くと思います • あと、いろいろ変なことやってますが、わたしはだいたい考えただけで • 実働部隊は優秀な若者たちがいて、細かいところは彼らががんばってくれ てます 本日のお話
4. Copyright © GREE, Inc. All Rights Reserved. • 最近の HW や InnoDB の I/O 周りについて考えつつ、取り組んでおり まして • さいきん、そのあたりを資料にまとめて slideshare で公開しております • 後日、あわせて読んでいただけると、よりわかりやすいかと思います • 参考： • 5.6以前の InnoDB Flushing • CPUに関する話 • EthernetやCPUなどの話 本日のお話の補足資料
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の前提で、 データベースを設計してるところが多かった • そういうストレージでも動くように、データベースのサイズは 100-200GB以下のものが多 かった • わたしが入社した2010年のころはよくサービスささっていて、各エンジニア が協力して改善してた • アプリケーションレイヤーでがんばってもらったり、力の限り sharding したり • わたしは、 ganglia で問題切り分けて、チューニングなどに力いれた 背景
7. Copyright © GREE, Inc. All Rights Reserved. • わたしが入社する前からノウハウがあって、ガンガンshardingして master切り替えてたそうで • 具体的には次のように • 先ずはサービス無停止で master 切換する方法から説明します どんなふうに sharding していたかというと
8. Copyright © GREE, Inc. All Rights Reserved. Master切り替え前
9. Copyright © GREE, Inc. All Rights Reserved. Master切り替え（参照切り替え） ※DNSないし設定ファイルなどで切り替え
10. Copyright © GREE, Inc. All Rights Reserved. Master切り替え（auto_increment更新）
11. Copyright © GREE, Inc. All Rights Reserved. Master切り替え（更新切り替え）
12. Copyright © GREE, Inc. All Rights Reserved. • masterを切り替えた後に、古いmasterに対してINSERTが実行されたと きのための対策 • 例えば、次のような状態になっていれば、auto_increment の値は duplicate しない • 旧master にINSERTすると、auto_increment のカラムは101以降の値を発番する • 新master にINSERTすると、auto_increment のカラムは131以降の値を発番する • 新masterには、master切り替えが完了するまでの間、 auto_incrementの値がduplicateしない程度の値を、 INSERT&DELETEし、 auto_increment の値を更新しておく • master切り替えの間、更新を完全にブロックできるなら、やらなくてもいい auto_increment更新する理由
13. Copyright © GREE, Inc. All Rights Reserved. DBの分割は次のように --replicate-do-table でもOK
14. Copyright © GREE, Inc. All Rights Reserved. TRIGGERで可能性が広がる SBRでTRIGGERを実行させ、新しいtableへの更新はRBRで複製
15. Copyright © GREE, Inc. All Rights Reserved. • database や table を最初からある程度分割しておいたほうが、 -- replicate-do-db や --replicate-do-table で簡単に分割できるけど • TRIGGER 使って table を分割することもできる • binlog_format=’STATEMENT’ だと、 TRIGGER によって発生した bi は binary log に落ちないけど、 binlog_format=’ROW’ だと binary log に落ち る。それらを組み合わせることによって、 TRIGGER によって更新された table だけ replication することが可能 • サービス無停止で column の追加や削除などにも対応できるので、 statement-based replication （＆ --log-slave-updates）＆ TRIGGER の組み合わせは、切り札として有用 sharding は後からでもできる
16. Copyright © GREE, Inc. All Rights Reserved. • サーバを並べることによって、むかしより安定稼働するようにはなったんだ けど • SSDを導入して活用したいという機運があった • 個人的には、MySQLのボトルネックを、 CPU とメモリの問題にできるようにしていきたい 気持ちがあった。ストレージ速くなったし、 Xeon は Core の数増え続けてたし、MySQL はバージョン上がるごとに、CPUスケーラビリティを改善し続けていたので。 そんな感じで、サービスとしては改善したんだけど
17. Copyright © GREE, Inc. All Rights Reserved. • 「MySQLのバージョンが上がってN倍性能が良くなった」というのは • （ほとんどの場合）MySQLがたくさんのCPUを活用できるようになって、ス ループットが改善していってるという話だと • InnoDB Adaptive Flushing などの改善もありますけどね • MySQL5.5あたりから強く意識するようになった • それまでは、とにかくHDDが圧倒的に遅かったけど • SSDの登場により、CPUとメモリがボトルネックになるケースを、強く意識し 始めた 強く意識したのは、 MySQL5.5 あたりから
18. Copyright © GREE, Inc. All Rights Reserved. • Fusion-IO 流行し始めたころ、調達できたのは ioDrive MLC 320GB • 先ずは KVS に投入したり、 sharding が困難だったDBに投入したけど • ほとんどのDBはHDDでも動くように sharding したり、アプリケーション 工夫したりしていたから、 320GB という容量は使いドコロが難しかった • また、当時はHDDのサーバが大量にあったので、 ioDrive に依存した設 計にしてしまうと、今後どれだけリプレースすればいいの、という恐れもあっ た • 他社のワークロードとGREEのワークロード違うから、他社の事例は参考 にしにくかった 先ずは ioDrive 導入した
19. Copyright © GREE, Inc. All Rights Reserved. • 当時、GREEで使ってたHDDのサーバと比較して、 ioDrive のサーバは コスト的に三倍くらいだったので、三倍以上の成果を挙げさせたいという前 提のもと • 他のサーバの三倍以上のqueryを受けさせるために • GREEのDBサーバに求められる要件を分析し、考えていった 三倍の仕事をさせるために
20. Copyright © GREE, Inc. All Rights Reserved. そして ひらめいた
21. Copyright © GREE, Inc. All Rights Reserved. • GREEのアプリケーションサーバはコネクションプーリングをしておらず、リ クエストが来るごとにコネクションを張り、レスポンスを返すごとにコネクショ ン切っていて • これは当時そこまで珍しくない実装だと思うけど • 不幸なことに、共通系のDBなるものが存在して • 特定のサービスでDBがささると、共通系のDBへのコネクションが溜まって いって、 too many connections が発生し • 他のサービスが巻き込まれてしまうという負の連鎖 密結合ゆえの問題を軽減しよう
22. Copyright © GREE, Inc. All Rights Reserved. （とてもざっくり）図にするとこう
23. Copyright © GREE, Inc. All Rights Reserved. • too many connections を避けるため、HDDのサーバをたくさん並べ て、たくさんの connection 受けられるようにするとか • 重要なサービスと内製ゲームで、slaveのクラスタを分けるとかして • 数の暴力で解決してたんだけど かつては富豪的に解決してた
24. Copyright © GREE, Inc. All Rights Reserved. 例えば、次のように分けていた
25. Copyright © GREE, Inc. All Rights Reserved. この状況を ioDriveの低latencyで なんとかする
26. Copyright © GREE, Inc. All Rights Reserved. • ioDrive や一般的な PCI-e SSD は、 latency が異常によい • これは現代においても言える、オンプレミス環境のメリット • ストレージというより、「ちょっと遅いメモリ」と考える • ちょっと遅いメモリなので、 buffer pool のヒット率を少し下げても大丈夫 • ピークタイムに、ユーザのデータの大半がヒットするなら、性能あまり変わらない • buffer pool の割当を意図的に減らして、そのぶん max_connections を増やす。具体的にはHDDのサーバの三倍以上に上げる • （高価だから）それほど多くないDRAM、 latency のすぐれた ioDrive と いう組み合わせで、HDDのサーバの三倍以上のqueryを受けさせて、 MySQLのCPU利用率引き上げる buffer pool のヒット率をうまく下げる
27. Copyright © GREE, Inc. All Rights Reserved. • slave は O_DIRECT 使えばメモリあけられるけど • master は binlog が page cache に乗り続けてしまう • そこで、 buffer pool の割当減らしてる master では、 cron で posix_fadvise(2) たたいて、古い binlog は page cache からちょっ とずつ落とすようにしてます。 • （言語はなんでもいいんですけど） いまのところ ruby で IO#advise つ かって :dontneed 叩いてます。 ちょっと一工夫
28. Copyright © GREE, Inc. All Rights Reserved. • ioDriveのサーバ１台と、HDDのサーバ三台程度を等価交換できるように した • どうしても I/O の性能が必要になった場合、 ioDrive のサーバを、大量 にある HDD のサーバ三台で置き換えることによって確保できるように • むかしからあるHDDなサーバの在庫も活用できるように • これで、 ioDrive のサーバの稼働台数を増やすことが可能になった • ioDrive たくさん使うことによって、どんなふうに故障するのかがわかって きた • ハードウェアは故障するまで使わないと、次のステージに踏み込めない HDDのサーバとの互換性
29. Copyright © GREE, Inc. All Rights Reserved. よし、壊したから、 次のことを考えよう
30. Copyright © GREE, Inc. All Rights Reserved. • 時は流れ、NAND Flash の価格が下がり、大容量化が進んでいった • 800GB以上のエンタープライズ仕様のSSDが普通に買えるようになった • これは使いたい • 当時、容量大きいSSD使ってる他社事例それほど多くは聞かなかったので、使ってやり たい • いまは珍しく無いと思いますけど • 他社が活用できてないものを活用することによって、サービスの競争力を向上させる • かつて、masterはHDD、slaveは一台の物理サーバに複数mysqld起 動してSSDで集約するという他社事例あったけど、それだと運用の手間が 増えるし、 Monitoring が難しくなるなと思った NAND Flash の価格が下がってきた
31. Copyright © GREE, Inc. All Rights Reserved. • 高い random I/O 性能というのもあるけれど • HDDと比べて消費電力が低く、熱にも強い • 消費電力が少ないので、それだけ一つのラックにたくさんのサーバ積める ようになるし • TurboBoost 使って clock あげて、CPUぶん回してやることもやりやすく なる • かつてHDDのために使っていた電力を、より多くのCPUのために使う • ラック単位で電力を考えたとき、ストレージよりもCPUに多くの電力を回す ようにする そもそも、NAND Flash は何がうれしいか
32. Copyright © GREE, Inc. All Rights Reserved. • GREEは力の限り sharding してしまっている • SSDにリプレースしなくても動かせるDBが大量にある • 100-200GB程度しかないDBでは、800GBのSSDは無用の長物ではな かろうか？ だがしかし
33. Copyright © GREE, Inc. All Rights Reserved. こんなことも あろうかと
34. Copyright © GREE, Inc. All Rights Reserved. ずいぶん 前から
35. Copyright © GREE, Inc. All Rights Reserved. 考えていたこと があった
36. Copyright © GREE, Inc. All Rights Reserved. そうだ
37. Copyright © GREE, Inc. All Rights Reserved. サービス無停止で master統合しよう
38. Copyright © GREE, Inc. All Rights Reserved. • DBが100-200GB程度しかないなら、統合して400GB以上にしてしまえ ばいい • 具体的には次のように master切り替えの手法を踏まえて
39. Copyright © GREE, Inc. All Rights Reserved. Master統合
40. Copyright © GREE, Inc. All Rights Reserved. Master統合
41. Copyright © GREE, Inc. All Rights Reserved. Master統合
42. Copyright © GREE, Inc. All Rights Reserved. Master統合
43. Copyright © GREE, Inc. All Rights Reserved. Master統合
44. Copyright © GREE, Inc. All Rights Reserved. Master統合
45. Copyright © GREE, Inc. All Rights Reserved. Master統合
46. Copyright © GREE, Inc. All Rights Reserved. Master統合
47. Copyright © GREE, Inc. All Rights Reserved. • New Master -> New Slave 間で、全力で binary log が転送されて しまうケースがあった。ネットワークの帯域を圧迫するのがコワイ • いろいろ改善策はあると思うけど • slave_compressed_protocol がお手軽でいいかも • いつもは有効にしたくないなら、 dump 流しこむときだけ有効にしても良 い • 動的に変更できるので便利 mysqldump の結果を流しこむときに
48. Copyright © GREE, Inc. All Rights Reserved. • change master したあとに start slave すると、一気に binary log 転送され、一気に binary log を SQL_Thread が処理してしまうので • ここで書いたスクリプト 使って、ちょっとずつ binary log 転送して、ちょっ とずつ binary log を適用させるように • あと、 binary log は大き過ぎない方が良い感じ • 弊社の場合は 200MB 程度にしてます ちょっとだけ工夫
49. Copyright © GREE, Inc. All Rights Reserved. • 次の課題が見えてきた これでいいかと思いきや
50. Copyright © GREE, Inc. All Rights Reserved. 続きは 後編で
51. Copyright © GREE, Inc. All Rights Reserved. つづく