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とかの話 後編

37,106 views

Published on

MySQLやSSDとかの話です

前編はこちら http://www.slideshare.net/takanorisejima/mysqlssd
後日談はこちら http://www.slideshare.net/takanorisejima/mysqlssd-70162609

Published in: Technology
  • Be the first to comment

MySQLやSSDとかの話 後編

  1. 1. Copyright © GREE, Inc. All Rights Reserved. MySQLやSSDとかの話 後編 Takanori Sejima
  2. 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. 3. Copyright © GREE, Inc. All Rights Reserved. ● 古いサーバを、新しくてスペックの良いサーバに置き換えていく際、いろい ろ工夫して集約していっているのですが ● そのあたりの背景や取り組みなどについて、本日はお話しようと思います ● オンプレミス環境の話になっちゃうんですが ● 一部は、オンプレミス環境じゃなくても応用が効くと思います ● あと、いろいろ変なことやってますが、わたしはだいたい考えただけで ● 実働部隊は優秀な若者たちがいて、細かいところは彼らががんばってくれ てます 本日のお話
  4. 4. Copyright © GREE, Inc. All Rights Reserved. ● 最近の HW や InnoDB の I/O 周りについて考えつつ、取り組んでおり まして ● さいきん、そのあたりを資料にまとめて slideshare で公開しております ● 後日、あわせて読んでいただけると、よりわかりやすいかと思います ● 参考: ● 5.6以前の InnoDB Flushing ● CPUに関する話 ● EthernetやCPUなどの話 本日のお話の補足資料
  5. 5. Copyright © GREE, Inc. All Rights Reserved. では後編を はじめます
  6. 6. Copyright © GREE, Inc. All Rights Reserved. ● ioDrive の実績上がってきたし ● サービス無停止で master 統合の目処も立ったから ● 大容量のSSD導入して、ガンガンDB統合していこうと思ってたんだけど
  7. 7. Copyright © GREE, Inc. All Rights Reserved. 次の課題とは?
  8. 8. Copyright © GREE, Inc. All Rights Reserved. それは
  9. 9. Copyright © GREE, Inc. All Rights Reserved. バックアップ どうしよう?
  10. 10. Copyright © GREE, Inc. All Rights Reserved. ● DBのバックアップをどうやって取得しよう? ● HDDのころは、masterとslaveは146GBのHDD*4でRAID10だった が、 バックアップファイルを取るためのslaveはHDD*6とかHDD*8とか で、データベース用の領域と、バックアップファイルを書き出すための領域 を確保できるようにしてた ● 具体的には、 mysqld 止めて datadir を tar ball で固めてた ● つまり、masterのサーバとバックアップファイルを取るためのサーバは、 ストレージの容量が等しくなかった 次の課題
  11. 11. Copyright © GREE, Inc. All Rights Reserved. ● バックアップサーバとmasterで同じ容量のSSD使うと、バックアップを取 ることができない ● DBで800GB使いきっちゃうと、 tar ball とれない ● 数TBの大容量 PCI-e SSD をバックアップサーバ用に使う? ● それはリッチすぎるコストパフォーマンスが悪い ● HDDだとI/Oの性能が追いつかない ● DBを統合するということは、それだけ更新が増えるということでもある ● SSDをRAIDコントローラで束ねる? ● そうするとRAIDコントローラがボトルネックになるケースも出てくる ● かつては、RAIDコントローラ経由だと SMARTがとれないという課題もあった 一番容量のでかいSATA SSDを使いたい
  12. 12. Copyright © GREE, Inc. All Rights Reserved. ● HDDもSSDも、ブロックデバイスは、一つのI/Oコントローラに対して read と write を同時に発行すると遅い ● read only ないし write only のときに最大のスループットがでる ● RAIDで束ねたHDD上で tar ball 取得するの、データベースが大きくな るに連れて、無視できない遅さになってきていた ● SSDに移行したとしても、このままだといつか遅くなって困るんじゃない? 大容量のSSDを使う前から、課題意識はあった
  13. 13. Copyright © GREE, Inc. All Rights Reserved. 五時間くらい 考えた
  14. 14. Copyright © GREE, Inc. All Rights Reserved. そうだ
  15. 15. Copyright © GREE, Inc. All Rights Reserved. バックアップの取り方 を変えよう
  16. 16. Copyright © GREE, Inc. All Rights Reserved. ● master/slave/バックアップサーバをぜんぶ 800GB のSSDにする ● バックアップサーバは ssh 経由で、同じラックにある SATA HDDの RAID6なストレージサーバに tar ball を書き出す ● $ tar cvf - ${datadir} | pigz | ssh ${storage_server} “cat - >backup. tar.gz” ● SSDなので tar するときの read は速い ● pigzでCPUのcoreぜんぶ使いきって圧縮するので、帯域制限にもなるし、 通信量もへる。まぁ、ラックをまたがないので、全力で転送しても困らない ● HDDは sequential write only になるので、書き込むのは充分速い ● 運用や監視も、既存の方法と比べて大きくは変えなくて良い 方法を変える、許容できる範囲内で
  17. 17. Copyright © GREE, Inc. All Rights Reserved. ● データが巨大になると、DB再構築するのに時間がかかるようになる ● 今までN+1の構成だったところはN+2にする ● slaveは一台多めにしておく。一台故障したら、もう一台故障する前にじっくり再構築 ● ストレージサーバは RAID6 にする。 SATA HDD の故障率を考慮して ● ストレージサーバはTB単位のデータを持っているため、電源などが故障したときのダメー ジがでかいので、二台構成にする。 ● バックアップサーバから書き出す先は現行系のストレージサーバにして、待機系は cron で rsync してコピーする ● ストレージサーバはSATA HDDにしたから大容量にできたので、ストレージサーバ一台 に対して、書き込むバックアップサーバは複数台にする。それならば、ストレージサーバを 二台構成にしてもコスト的にペイする ● 最終的に、トータルで台数減ればそれでいい 破綻しないよう、考えながら集約する
  18. 18. Copyright © GREE, Inc. All Rights Reserved. 図にするとこう
  19. 19. Copyright © GREE, Inc. All Rights Reserved. ● Google の Warehouse-Scale Computer ほど大きい粒度ではなく、4 本以上のラックを一つの単位として考える ● replication の traffic は、これらのラックに閉じ込めてしまう。 ● RAID5がパリティを複数のディスクに分散させるように、masterやバック アップ用のサーバを複数のラックに分散させる ● 万が一、ラックごと落ちたとしても、影響を受けるmaster の数を限定的にできる ● master -> slave 間の replication の traffic が、ラックごとに偏りにくくなる ● アプリケーションサーバ <-> slave の traffic が多かったとしても、ラックごとに偏りに くくなる ● バックアップサーバを分散配置することで、ストレージサーバのディスク使用量を、ラック ごとに偏らせないようにする 複数のラックをグルーピングし、RAID5の様に扱う
  20. 20. Copyright © GREE, Inc. All Rights Reserved. ● 現状のHWの特性や、今後のHWを想定している ● サーバのNICの帯域が増えても、これらのラックの集合の中でその性能が活かせる ● 弊社の場合、KVSの replication の traffic が大変多いのだが、 KVSやMySQLの replication の traffic を特定のラックに集約できると、運用上楽になる ● pigz でバックアップファイルを圧縮するので、DBの集約度が上がってDBのサイズが増 えても、CPUのコアが増えれば、バックアップの取得時間を稼ぐことができる ● SSDの消費電力の少なさを活かして、一ラックあたりの集積度を上げていける ● SSDは消費電力が少なく熱にも強いから、そのぶんCPU で TurboBoost 使って、熱 出しつつ性能を引き出す方向で行ける ● TurboBoost 使うことで、NICの帯域が増えても、CPUがパケットさばけるようにする ● 現状はSATAのHDDをバックアップ用のストレージに割り当てているけど、SSDのバイト 単価が十分下がっていけば、別にSSD でもかまわない このラックの使い方には、いろいろな思惑がある
  21. 21. Copyright © GREE, Inc. All Rights Reserved. ● 最近は、 ioMemory や 800GBのエンタープライズグレードの SATA SSD を使い分けてたりする ● SATAのSSDはコストパフォーマンスが良い。でも、GREE的には Fusion-IOの方が実績がある ● サービスの品質を担保しつつ、使い比べて、適切に使い分けていきたいの で ● latencyの要件厳しくないところから、SATAのSSDにしていっている いろいろ考えたので導入してる
  22. 22. Copyright © GREE, Inc. All Rights Reserved. ● 書き込み寿命の短いものも、積極的に使うようにしている ● かつて、 ioDrive MLC 320GB は書き込み寿命が 4PBW だったけど ● ioMemory SX1300 は、 1250GB の容量で、4PBW ● 容量あたりの書き込み寿命短い製品の方が安いので、積極的に書き込み を減らす工夫をしている ● こちらの資料 で double write buffer など調査してる理由の一つは、書 き込みを減らして安価な NAND Flash を使ってコストダウンしたいがため ● あと、 NAND Flash は微細化が進むに連れて書き込み寿命が短くなる 性質なので、ハードウェアの変化に備えるために ただ、 ioMemory でも
  23. 23. Copyright © GREE, Inc. All Rights Reserved. ● ファイルシステムの discard option 有効にして SATA SSD を使おうと すると、巨大なファイルの削除が遅い傾向にある。(最近の kernel だとな おってるかもしれないが)、Linux は TRIMの最適化がいまいち ● 例外的に、Fusion-IO は discard 指定して mount しても、あまり性能 劣化しない傾向なので、 Fusion-IO 使うときだけ discard 指定してる ● MySQLでは、 binary log を purge したり、 DROP TABLE などでファ イルを削除する場合があるので、ファイル削除が遅いのはつらい ● SATA SSD 使うときは discard 指定しないようにしてる。 TRIM に期待 するより、InnoDB をチューニングして I/O 減らす方がいい LinuxのTRIMサポートにはあまり期待していない
  24. 24. Copyright © GREE, Inc. All Rights Reserved. ● MySQL5.6を使って ● 5.7の本格導入はこれから ● double write buffer は無効化 ● innodb_io_capacity=100 ● いろいろやってたら、このバグ踏むことは確かにあった ● default の 200 ならそんなに困らないんだけど、それでも、 innodb_adaptive_flushing_lwm までredo logがたまらないのはもったいない ● 夜中などオフピークの時間帯は、 redo logをためずに書いてしまうことがある ● redo logが溜まってきたら、 innodb_adaptive_flushing_lwm や innodb_io_capacity_max に応じて書き込むので、 innodb_adaptive_flushing_lwm まではログをためてもいいという判断 SSDで書き込みを減らすための、最近の取り組み
  25. 25. Copyright © GREE, Inc. All Rights Reserved. ● 一つは、安価なNAND Flashを使えるようにして、ランニングコストを下げ ること ● もう一つは、故障率を下げる試みとして ● 経験上、たくさん書き込んでる NAND Flash ほど、故障しやすいので ● Facebook の論文(A Large-Scale Study of Flash Memory Failures in the Field) でも、たくさん書き込んでると、 uncorrectable な error が発生しやすいとのこ となので ● 故障率を下げて、よりサービスを安定稼働させたい ● AWS で EBS 酷使するとしても、 iops 減らせるほうが最終的には便利 だし、コストダウンに繋がる 書き込みを減らしたいのは、幾つかの理由から
  26. 26. Copyright © GREE, Inc. All Rights Reserved. ● SSD で集約して、一部のサーバのCPU使用率は上げられるようになって きたけど、もっとCPUを活用していきたい ● 今後もCPUはCoreの数増え続けるだろうし ● というわけで、性能上問題がないところは InnoDB の圧縮機能を使って、 CPUを活用し、さらに集約度を上げていってる ● 秘伝のタレである my.cnf 見なおしたり ● DB の設計によっては、 mutex が課題になるケースもある ● TurboBoost 使ってCPUの性能を引き出すために、CPUの温度などもさ いきんは取り始めた ● バックアップの取り方を、さらに見直すなどもした 他にもやってる取り組み
  27. 27. Copyright © GREE, Inc. All Rights Reserved. ● mysqld を止めて tar ball を取る場合、 mysqld を止めている間に master がクラッシュすると、その間のbinlog取り損なって残念 ● そこで、mysqlbinlog で --read-from-remote-server --stop- never --raw を使って、 tar ball とってる間も binlog を取り続けるよう にして、いざというときはその binlog を使えるようにしておく ● XtraBackup などでオンラインバックアップを取る運用に変えれば、 mysqld 止めなくてもいいから、binlog欠損しないんだけど、運用を変え ないでいいというのは、導入が容易というメリットがある MySQL5.6以降のmysqlbinlogを活用
  28. 28. Copyright © GREE, Inc. All Rights Reserved. ● mysqlbinlog のコードを読んでいて、とても残念な気持ちになった ● --raw の場合、 fwrite(3) でログを出力していて、masterからbinlogを 受け取ったとしても、それが直ちにファイルに書き込まれるわけではない。 その状態で kill すると、最後に受け取ったbinlogのイベントが欠損する ● これは mysqlbinlog の main loop が今ひとつなので、いっそ書き換えようかと思った ● いつでも SIGTERM を送ってカジュアルにプロセス終了させたい 一つだけ工夫
  29. 29. Copyright © GREE, Inc. All Rights Reserved. 一時間ほど 考えた
  30. 30. Copyright © GREE, Inc. All Rights Reserved. ● mysqlbinlog は master とのコネクション切れると、 fclose(3)して ロ グを flush してから終了してくれるので、 nc を間に挟むことにした ● > nc -l -s 127.0.0.1 -p 13306 -w 3600 -c "/bin/nc ${Master_Host} 3306" & > mysqlbinlog --host=127.0.0.1 --port=13306 --read- from-remote-server --raw --stop-never ${Relay_Master_Log_File} & ● これで、 nc に SIGTERM 送れば、 mysqlbinlog は受け取ったログを すべて出力してから終了してくれる netcatをはさむ
  31. 31. Copyright © GREE, Inc. All Rights Reserved. ● master統合する前に、統合後の書き込みの負荷がどれくらいになるのか をテストしたかったので ● 次のワンライナーを実行すると、 mysqlbinlog が io_thread、 mysql client が sql_thread 相当の仕事をしてくれるので、レプリケーションし ながらこれで query を流し込めばいい ● trickle -s -d ${適当な値} mysqlbinlog --host=${MASTER_HOST} -- verify-binlog-checksum --read-from-remote-server --stop-never ${MASTER_LOG} 2>${LOGFILE}_log.err | tee ${LOGFILE}_log.txt | mysql --binary-mode -vv > ${LOGFILE}_client.txt 2>${LOGFILE} _client.err mysqlbinlog でもう一つ ただし、この方法は各自の責任で試してください!
  32. 32. Copyright © GREE, Inc. All Rights Reserved. ● 5.6 で fix されたけど、それ以前の mysql client は、 mysqlbinlog が生成した query をうまく処理できないケースがあった ● なので、前のページで書いた方法は、 5.6 以降の mysqlbinlog と mysql client の組み合わせで試すべき ● あと、今後 MySQL の version が上がったときに、 binlog の format が変わらない保証はない ● 自分で試すときは、最初に、使う可能性があるすべてのversion の mysql で binlog 周りのコードを読んでからにした ● 当時、わたしは MySQL5.7 を待つ堪え性がなかっただけなので ● いまは 5.7で multi source replication 使うほうが無難かも mysqlbinlog と mysql client の相性問題
  33. 33. Copyright © GREE, Inc. All Rights Reserved. ● インフラエンジニアが、お客様に対して還元できることは ● サービスの安定性を向上することと ● ランニングコストを削減することくらいなので ● サービスの安定性を確保しつつ、ランニングコストを削減できれば、そのぶ ん、サービスの改善に活かせるはず なぜこんなことをやるかというと
  34. 34. Copyright © GREE, Inc. All Rights Reserved. ● サーバを構成するハードウェア、CPU/メモリ/ストレージ/ネットワークのう ち ● この五年間でもっとも進化したのは、ストレージ ● SSDになって、性能向上して、容量増えて、消費電力さがって ● 書き込み寿命という概念がもたらされた ● ストレージの変化に合わせて、許容できる範囲内でシステムを見なおして ● サービスの安定性を向上させつつ、ランニングコストの削減を図って ● お客様に還元しようと思った 過去五年間を振り返って考えると
  35. 35. Copyright © GREE, Inc. All Rights Reserved. ● 一つのサービスを5年以上続けていると、ハードウェアなど、周囲の環境 が変わってくる ● さいきん立ち上がったサービスは、最初からSSDやAWSが当たり前なの で、それに最適な設計で始められるので、コスト面で優位に立てる可能性 が高い ● 古くからあるサービスも、現代の状況に合わせてあるていど変化させない と、コストパフォーマンスが悪いままで、競争で不利になる。古いサービス は先行者利益があるだけではない ● 時代の変化に追随して、現代のハードウェアに対して最適な構成に変更 し、競争力を維持するよう努める 時代の変化に追随する
  36. 36. Copyright © GREE, Inc. All Rights Reserved. ● 最近は、次にどんなハードウェアが進化するのか、どの構成要素の進化が 著しいのかを考えていて ● それに合わせて、許容できる範囲内でシステムを見なおしてるところです ● 個人的には、オンプレミスとかパブリッククラウドとかこだわりはなくって、 何をどう使うのが、最終的に一番メリットあるのか考えてたりします ● 現状、オンプレミス環境は、次の2つのメリットがあるので推奨してますが、 これらも時代とともにうつろうのだろうと考えてます ● サーバだけでなく、ネットワーク機材のメンテナンスもあるていどスケジューリングできる ので、他社向けのサービスに対し、影響の少ない時間帯にメンテナンス作業ができる ● I/Oの性能がよい そういうわけで
  37. 37. Copyright © GREE, Inc. All Rights Reserved. おわり

×