MySQLやSSDとかの話・後編

GREE Tech Talk #09「MySQL」での登壇資料です
http://techtalk.labs.gree.jp/

Transcript

1. MySQLやSSDとかの話 後編 Takanori Sejima
2. 自己紹介 • わりとMySQLのひと • 3.23.58 から使ってる • むかしは Resource Monitoring も力入れてやってた • ganglia & rrdcached の（たぶん）ヘビーユーザ • 5年くらい前から使い始めた • gmond は素のまま使ってる • gmetad は欲しい機能がなかったので patch 書いた • webfrontend はほぼ書き直した • あとはひたすら python module 書いた • ganglia じゃなくても良かったんだけど、とにかく rrdcached を使いたかった • というわけで、自分は Monitoring を大事にする • 一時期は Flare という OSS の bugfix などもやってた
3. • 古いサーバを、新しくてスペックの良いサーバに置き換えていく際、 いろいろ工夫して集約していっているのですが • そのあたりの背景や取り組みなどについて、本日はお話しようと思 います • オンプレミス環境の話になっちゃうんですが • 一部は、オンプレミス環境じゃなくても応用が効くと思います • あと、いろいろ変なことやってますが、わたしはだいたい考えただ けで • 実働部隊は優秀な若者たちがいて、細かいところは彼らががんばっ てくれてます 本日のお話
4. • 最近の HW や InnoDB の I/O 周りについて考えつつ、取り組んで おりまして • さいきん、そのあたりを資料にまとめて slideshare で公開しており ます • 後日、あわせて読んでいただけると、よりわかりやすいかと思いま す • 参考： • 5.6以前の InnoDB Flushing • CPUに関する話 • EthernetやCPUなどの話 本日のお話の補足資料
5. では後編を はじめます
6. • ioDrive の実績上がってきたし • サービス無停止で master 統合の目処も立ったから • 大容量のSSD導入して、ガンガンDB統合していこうと思ってたんだ けど
7. 次の課題とは？
8. それは
9. バックアップ どうしよう？
10. • DBのバックアップをどうやって取得しよう？ • HDDのころは、masterとslaveは146GBのHDD*4でRAID10だっ たが、 バックアップファイルを取るためのslaveはHDD*6とか HDD*8とかで、データベース用の領域と、バックアップファイルを 書き出すための領域を確保できるようにしてた • 具体的には、 mysqld 止めて datadir を tar ball で固めてた • つまり、masterのサーバとバックアップファイルを取るためのサー バは、ストレージの容量が等しくなかった 次の課題
11. • バックアップサーバとmasterで同じ容量のSSD使うと、バックアッ プを取ることができない • DBで800GB使いきっちゃうと、 tar ball とれない • 数TBの大容量 PCI-e SSD をバックアップサーバ用に使う？ • それはリッチすぎるコストパフォーマンスが悪い • HDDだとI/Oの性能が追いつかない • DBを統合するということは、それだけ更新が増えるということでもある • SSDをRAIDコントローラで束ねる？ • そうするとRAIDコントローラがボトルネックになるケースも出てくる • かつては、RAIDコントローラ経由だとSMARTがとれないという課題もあった 一番容量のでかいSATA SSDを使いたい
12. • HDDもSSDも、ブロックデバイスは、一つのI/Oコントローラに対 して read と write を同時に発行すると遅い • read only ないし write only のときに最大のスループットがでる • RAIDで束ねたHDD上で tar ball 取得するの、データベースが大き くなるに連れて、無視できない遅さになってきていた • SSDに移行したとしても、このままだといつか遅くなって困るんじ ゃない？ 大容量のSSDを使う前から、課題意識はあった
13. 五時間くらい 考えた
14. そうだ
15. バックアップの取り 方を変えよう
16. • 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. • データが巨大になると、DB再構築するのに時間がかかるようになる • 今までN+1の構成だったところはN+2にする • slaveは一台多めにしておく。一台故障したら、もう一台故障する前にじっくり 再構築 • ストレージサーバは RAID6 にする。 SATA HDD の故障率を考慮して • ストレージサーバはTB単位のデータを持っているため、電源などが故障したとき のダメージがでかいので、二台構成にする。 • バックアップサーバから書き出す先は現行系のストレージサーバにして、待機系は cron で rsync してコピーする • ストレージサーバはSATA HDDにしたから大容量にできたので、ストレージサー バ一台に対して、書き込むバックアップサーバは複数台にする。それならば、ス トレージサーバを二台構成にしてもコスト的にペイする • 最終的に、トータルで台数減ればそれでいい 破綻しないよう、考えながら集約する
18. 図にするとこう
19. • Google の Warehouse-Scale Computer ほど大きい粒度ではなく、 ４本以上のラックを一つの単位として考える • replication の traffic は、これらのラックに閉じ込めてしまう。 • RAID5がパリティを複数のディスクに分散させるように、masterや バックアップ用のサーバを複数のラックに分散させる • 万が一、ラックごと落ちたとしても、影響を受ける master の数を限定的にでき る • master -> slave 間の replication の traffic が、ラックごとに偏りにくくなる • アプリケーションサーバ <-> slave の traffic が多かったとしても、ラックごと に偏りにくくなる • バックアップサーバを分散配置することで、ストレージサーバのディスク使用量 を、ラックごとに偏らせないようにする 複数のラックをグルーピングし、RAID5の様に 扱う
20. • 現状の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. • 最近は、 ioMemory や 800GBのエンタープライズグレードの SATA SSD を使い分けてたりする • SATAのSSDはコストパフォーマンスが良い。でも、GREE的には Fusion-IOの方が実績がある • サービスの品質を担保しつつ、使い比べて、適切に使い分けていき たいので • latencyの要件厳しくないところから、SATAのSSDにしていってい る いろいろ考えたので導入してる
22. • 書き込み寿命の短いものも、積極的に使うようにしている • かつて、 ioDrive MLC 320GB は書き込み寿命が 4PBW だったけ ど • ioMemory SX1300 は、 1250GB の容量で、4PBW • 容量あたりの書き込み寿命短い製品の方が安いので、積極的に書き 込みを減らす工夫をしている • こちらの資料 で double write buffer など調査してる理由の一つは、 書き込みを減らして安価な NAND Flash を使ってコストダウンした いがため • あと、 NAND Flash は微細化が進むに連れて書き込み寿命が短くな る性質なので、ハードウェアの変化に備えるために ただ、 ioMemory でも
23. • ファイルシステムの 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. • 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. • 一つは、安価なNAND Flashを使えるようにして、ランニングコスト を下げること • もう一つは、故障率を下げる試みとして • 経験上、たくさん書き込んでる NAND Flash ほど、故障しやすいので • Facebook の論文(A Large-Scale Study of Flash Memory Failures in the Field) でも、たくさん書き込んでると、 uncorrectable な error が発生しやす いとのことなので • 故障率を下げて、よりサービスを安定稼働させたい • AWS で EBS 酷使するとしても、 iops 減らせるほうが最終的には 便利だし、コストダウンに繋がる 書き込みを減らしたいのは、幾つかの理由から
26. • SSD で集約して、一部のサーバのCPU使用率は上げられるようにな ってきたけど、もっとCPUを活用していきたい • 今後もCPUはCoreの数増え続けるだろうし • というわけで、性能上問題がないところは InnoDB の圧縮機能を使 って、CPUを活用し、さらに集約度を上げていってる • 秘伝のタレである my.cnf 見なおしたり • DB の設計によっては、 mutex が課題になるケースもある • TurboBoost 使ってCPUの性能を引き出すために、CPUの温度など もさいきんは取り始めた • バックアップの取り方を、さらに見直すなどもした 他にもやってる取り組み
27. • 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. • mysqlbinlog のコードを読んでいて、とても残念な気持ちになった • --raw の場合、 fwrite(3) でログを出力していて、masterから binlogを受け取ったとしても、それが直ちにファイルに書き込まれ るわけではない。その状態で kill すると、最後に受け取ったbinlog のイベントが欠損する • これは mysqlbinlog の main loop が今ひとつなので、いっそ書き換えようかと 思った • いつでも SIGTERM を送ってカジュアルにプロセス終了させたい 一つだけ工夫
29. 一時間ほど 考えた
30. • 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. • 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. • 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. • インフラエンジニアが、お客様に対して還元できることは • サービスの安定性を向上することと • ランニングコストを削減することくらいなので • サービスの安定性を確保しつつ、ランニングコストを削減できれば、 そのぶん、サービスの改善に活かせるはず なぜこんなことをやるかというと
34. • サーバを構成するハードウェア、CPU/メモリ/ストレージ/ネットワ ークのうち • この五年間でもっとも進化したのは、ストレージ • SSDになって、性能向上して、容量増えて、消費電力さがって • 書き込み寿命という概念がもたらされた • ストレージの変化に合わせて、許容できる範囲内でシステムを見な おして • サービスの安定性を向上させつつ、ランニングコストの削減を図っ て • お客様に還元しようと思った 過去五年間を振り返って考えると
35. • 一つのサービスを５年以上続けていると、ハードウェアなど、周囲 の環境が変わってくる • さいきん立ち上がったサービスは、最初からSSDやAWSが当たり前 なので、それに最適な設計で始められるので、コスト面で優位に立 てる可能性が高い • 古くからあるサービスも、現代の状況に合わせてあるていど変化さ せないと、コストパフォーマンスが悪いままで、競争で不利になる。 古いサービスは先行者利益があるだけではない • 時代の変化に追随して、現代のハードウェアに対して最適な構成に 変更し、競争力を維持するよう努める 時代の変化に追随する
36. • 最近は、次にどんなハードウェアが進化するのか、どの構成要素の 進化が著しいのかを考えていて • それに合わせて、許容できる範囲内でシステムを見なおしてるとこ ろです • 個人的には、オンプレミスとかパブリッククラウドとかこだわりは なくって、何をどう使うのが、最終的に一番メリットあるのか考え てたりします • 現状、オンプレミス環境は、次の２つのメリットがあるので推奨し てますが、これらも時代とともにうつろうのだろうと考えてます • サーバだけでなく、ネットワーク機材のメンテナンスもあるていどスケジューリ ングできるので、他社向けのサービスに対し、影響の少ない時間帯にメンテナン ス作業ができる • I/Oの性能がよい そういうわけで
37. おわり