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やSSDとかの話・前編

3,271 views

Published on

瀬島 貴則(グリー株式会社)「MySQLやSSDとかの話・前編」

MySQL User Conference Tokyo 2015での登壇資料です
https://www.mysql.com/news-and-events/events/mysql-user-conference-tokyo-2015/

Published in: Technology
  • Be the first to comment

MySQLやSSDとかの話・前編

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

×