MySQLやSSDとかの話　後編

Copyright © GREE, Inc. All Rights Reserved.
MySQLやSSDとかの話
後編
Takanori Sejima

自己紹介
● わりとMySQLのひと
● 3.23.58 から使ってる
● むかしは Resource Monitoring も力入れてやってた
● ganglia & rrdcached の（たぶん）ヘビーユーザ
● 5年くらい前から使い始めた
● gmond は素のまま使ってる
● gmetad は欲しい機能がなかったので patch 書いた
● webfrontend はほぼ書き直した
● あとはひたすら python module 書いた
● ganglia じゃなくても良かったんだけど、とにかく rrdcached を使いたかった
● というわけで、自分は Monitoring を大事にする
● 一時期は Flare という OSS の bugfix などもやってた

● 古いサーバを、新しくてスペックの良いサーバに置き換えていく際、いろい
ろ工夫して集約していっているのですが
● そのあたりの背景や取り組みなどについて、本日はお話しようと思います
● オンプレミス環境の話になっちゃうんですが
● 一部は、オンプレミス環境じゃなくても応用が効くと思います
● あと、いろいろ変なことやってますが、わたしはだいたい考えただけで
● 実働部隊は優秀な若者たちがいて、細かいところは彼らががんばってくれ
てます
本日のお話

● 最近の HW や InnoDB の I/O 周りについて考えつつ、取り組んでおり
まして
● さいきん、そのあたりを資料にまとめて slideshare で公開しております
● 後日、あわせて読んでいただけると、よりわかりやすいかと思います
● 参考：
● 5.6以前の InnoDB Flushing
● CPUに関する話
● EthernetやCPUなどの話
本日のお話の補足資料

では後編を
はじめます

● ioDrive の実績上がってきたし
● サービス無停止で master 統合の目処も立ったから
● 大容量のSSD導入して、ガンガンDB統合していこうと思ってたんだけど

次の課題とは？

それは

バックアップ
どうしよう？

● DBのバックアップをどうやって取得しよう？
● HDDのころは、masterとslaveは146GBのHDD*4でRAID10だった
が、バックアップファイルを取るためのslaveはHDD*6とかHDD*8とか
で、データベース用の領域と、バックアップファイルを書き出すための領域
を確保できるようにしてた
● 具体的には、 mysqld 止めて datadir を tar ball で固めてた
● つまり、masterのサーバとバックアップファイルを取るためのサーバは、
ストレージの容量が等しくなかった
次の課題

● バックアップサーバとmasterで同じ容量のSSD使うと、バックアップを取
ることができない
● DBで800GB使いきっちゃうと、 tar ball とれない
● 数TBの大容量 PCI-e SSD をバックアップサーバ用に使う？
● それはリッチすぎるコストパフォーマンスが悪い
● HDDだとI/Oの性能が追いつかない
● DBを統合するということは、それだけ更新が増えるということでもある
● SSDをRAIDコントローラで束ねる？
● そうするとRAIDコントローラがボトルネックになるケースも出てくる
● かつては、RAIDコントローラ経由だと SMARTがとれないという課題もあった
一番容量のでかいSATA SSDを使いたい

● HDDもSSDも、ブロックデバイスは、一つのI/Oコントローラに対して
read と write を同時に発行すると遅い
● read only ないし write only のときに最大のスループットがでる
● RAIDで束ねたHDD上で tar ball 取得するの、データベースが大きくな
るに連れて、無視できない遅さになってきていた
● SSDに移行したとしても、このままだといつか遅くなって困るんじゃない？
大容量のSSDを使う前から、課題意識はあった

五時間くらい
考えた

そうだ

バックアップの取り方
を変えよう

● 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 になるので、書き込むのは充分速い
● 運用や監視も、既存の方法と比べて大きくは変えなくて良い
方法を変える、許容できる範囲内で

● データが巨大になると、DB再構築するのに時間がかかるようになる
● 今までN+1の構成だったところはN+2にする
● slaveは一台多めにしておく。一台故障したら、もう一台故障する前にじっくり再構築
● ストレージサーバは RAID6 にする。 SATA HDD の故障率を考慮して
● ストレージサーバはTB単位のデータを持っているため、電源などが故障したときのダメー
ジがでかいので、二台構成にする。
● バックアップサーバから書き出す先は現行系のストレージサーバにして、待機系は cron で
rsync してコピーする
● ストレージサーバはSATA HDDにしたから大容量にできたので、ストレージサーバ一台
に対して、書き込むバックアップサーバは複数台にする。それならば、ストレージサーバを
二台構成にしてもコスト的にペイする
● 最終的に、トータルで台数減ればそれでいい
破綻しないよう、考えながら集約する

図にするとこう

● Google の Warehouse-Scale Computer ほど大きい粒度ではなく、４
本以上のラックを一つの単位として考える
● replication の traffic は、これらのラックに閉じ込めてしまう。
● RAID5がパリティを複数のディスクに分散させるように、masterやバック
アップ用のサーバを複数のラックに分散させる
● 万が一、ラックごと落ちたとしても、影響を受けるmaster の数を限定的にできる
● master -> slave 間の replication の traffic が、ラックごとに偏りにくくなる
● アプリケーションサーバ <-> slave の traffic が多かったとしても、ラックごとに偏りに
くくなる
● バックアップサーバを分散配置することで、ストレージサーバのディスク使用量を、ラック
ごとに偏らせないようにする
複数のラックをグルーピングし、RAID5の様に扱う

● 現状の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 でもかまわない
このラックの使い方には、いろいろな思惑がある

● 最近は、 ioMemory や 800GBのエンタープライズグレードの SATA
SSD を使い分けてたりする
● SATAのSSDはコストパフォーマンスが良い。でも、GREE的には
Fusion-IOの方が実績がある
● サービスの品質を担保しつつ、使い比べて、適切に使い分けていきたいの
で
● latencyの要件厳しくないところから、SATAのSSDにしていっている
いろいろ考えたので導入してる

● 書き込み寿命の短いものも、積極的に使うようにしている
● かつて、 ioDrive MLC 320GB は書き込み寿命が 4PBW だったけど
● ioMemory SX1300 は、 1250GB の容量で、4PBW
● 容量あたりの書き込み寿命短い製品の方が安いので、積極的に書き込み
を減らす工夫をしている
● こちらの資料で double write buffer など調査してる理由の一つは、書
き込みを減らして安価な NAND Flash を使ってコストダウンしたいがため
● あと、 NAND Flash は微細化が進むに連れて書き込み寿命が短くなる
性質なので、ハードウェアの変化に備えるために
ただ、 ioMemory でも

● ファイルシステムの 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サポートにはあまり期待していない

● 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で書き込みを減らすための、最近の取り組み

● 一つは、安価なNAND Flashを使えるようにして、ランニングコストを下げ
ること
● もう一つは、故障率を下げる試みとして
● 経験上、たくさん書き込んでる NAND Flash ほど、故障しやすいので
● Facebook の論文(A Large-Scale Study of Flash Memory Failures in the
Field) でも、たくさん書き込んでると、 uncorrectable な error が発生しやすいとのこ
となので
● 故障率を下げて、よりサービスを安定稼働させたい
● AWS で EBS 酷使するとしても、 iops 減らせるほうが最終的には便利
だし、コストダウンに繋がる
書き込みを減らしたいのは、幾つかの理由から

● SSD で集約して、一部のサーバのCPU使用率は上げられるようになって
きたけど、もっとCPUを活用していきたい
● 今後もCPUはCoreの数増え続けるだろうし
● というわけで、性能上問題がないところは InnoDB の圧縮機能を使って、
CPUを活用し、さらに集約度を上げていってる
● 秘伝のタレである my.cnf 見なおしたり
● DB の設計によっては、 mutex が課題になるケースもある
● TurboBoost 使ってCPUの性能を引き出すために、CPUの温度などもさ
いきんは取り始めた
● バックアップの取り方を、さらに見直すなどもした
他にもやってる取り組み

● mysqld を止めて tar ball を取る場合、 mysqld を止めている間に
master がクラッシュすると、その間のbinlog取り損なって残念
● そこで、mysqlbinlog で --read-from-remote-server --stop-
never --raw を使って、 tar ball とってる間も binlog を取り続けるよう
にして、いざというときはその binlog を使えるようにしておく
● XtraBackup などでオンラインバックアップを取る運用に変えれば、
mysqld 止めなくてもいいから、binlog欠損しないんだけど、運用を変え
ないでいいというのは、導入が容易というメリットがある
MySQL5.6以降のmysqlbinlogを活用

● mysqlbinlog のコードを読んでいて、とても残念な気持ちになった
● --raw の場合、 fwrite(3) でログを出力していて、masterからbinlogを
受け取ったとしても、それが直ちにファイルに書き込まれるわけではない。
その状態で kill すると、最後に受け取ったbinlogのイベントが欠損する
● これは mysqlbinlog の main loop が今ひとつなので、いっそ書き換えようかと思った
● いつでも SIGTERM を送ってカジュアルにプロセス終了させたい
一つだけ工夫

一時間ほど
考えた

● 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をはさむ

● 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 でもう一つ
ただし、この方法は各自の責任で試してください！

● 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 の相性問題

● インフラエンジニアが、お客様に対して還元できることは
● サービスの安定性を向上することと
● ランニングコストを削減することくらいなので
● サービスの安定性を確保しつつ、ランニングコストを削減できれば、そのぶ
ん、サービスの改善に活かせるはず
なぜこんなことをやるかというと

● サーバを構成するハードウェア、CPU/メモリ/ストレージ/ネットワークのう
ち
● この五年間でもっとも進化したのは、ストレージ
● SSDになって、性能向上して、容量増えて、消費電力さがって
● 書き込み寿命という概念がもたらされた
● ストレージの変化に合わせて、許容できる範囲内でシステムを見なおして
● サービスの安定性を向上させつつ、ランニングコストの削減を図って
● お客様に還元しようと思った
過去五年間を振り返って考えると

● 一つのサービスを５年以上続けていると、ハードウェアなど、周囲の環境
が変わってくる
● さいきん立ち上がったサービスは、最初からSSDやAWSが当たり前なの
で、それに最適な設計で始められるので、コスト面で優位に立てる可能性
が高い
● 古くからあるサービスも、現代の状況に合わせてあるていど変化させない
と、コストパフォーマンスが悪いままで、競争で不利になる。古いサービス
は先行者利益があるだけではない
● 時代の変化に追随して、現代のハードウェアに対して最適な構成に変更
し、競争力を維持するよう努める
時代の変化に追随する

● 最近は、次にどんなハードウェアが進化するのか、どの構成要素の進化が
著しいのかを考えていて
● それに合わせて、許容できる範囲内でシステムを見なおしてるところです
● 個人的には、オンプレミスとかパブリッククラウドとかこだわりはなくって、
何をどう使うのが、最終的に一番メリットあるのか考えてたりします
● 現状、オンプレミス環境は、次の２つのメリットがあるので推奨してますが、
これらも時代とともにうつろうのだろうと考えてます
● サーバだけでなく、ネットワーク機材のメンテナンスもあるていどスケジューリングできる
ので、他社向けのサービスに対し、影響の少ない時間帯にメンテナンス作業ができる
● I/Oの性能がよい
そういうわけで

おわり

MySQLやSSDとかの話　後編

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (20)

En vedette

En vedette (20)

Similaire à MySQLやSSDとかの話　後編

Similaire à MySQLやSSDとかの話　後編 (20)

Dernier

Dernier (10)