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などの話
本日のお話の補足資料

では
はじめます

● GREEのサービスは歴史が古い
● 古いサービスはコードが密結合な部分がある
● むかしから動いてるMySQLのサーバは、かなり sharding されていた
● 2000年代、GREEは SAS HDD 146GB 15krpm * 4本使ったRAID10の前提で、
データベースを設計してるところが多かった
● そういうストレージでも動くように、データベースのサイズは100-200GB以下のものが
多かった
● わたしが入社した2010年のころはよくサービスささっていて、各エンジニア
が協力して改善してた
● アプリケーションレイヤーでがんばってもらったり、力の限りsharding したり
● わたしは、 ganglia で問題切り分けて、チューニングなどに力いれた
背景

● わたしが入社する前からノウハウがあって、ガンガンshardingして
master切り替えてたそうで
● 具体的には次のように
● 先ずはサービス無停止で master 切換する方法から説明します
どんなふうに sharding していたかというと

Master切り替え前

Master切り替え（参照切り替え）
※DNSないし設定ファイルなどで切り替え

Master切り替え（auto_increment更新）

Master切り替え（更新切り替え）

● 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更新する理由

DBの分割は次のように
--replicate-do-table でもOK

TRIGGERで可能性が広がる
SBRでTRIGGERを実行させ、新しいtableへの更新はRBRで複製

● 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 は後からでもできる

● サーバを並べることによって、むかしより安定稼働するようにはなったんだ
けど
● SSDを導入して活用したいという機運があった
● 個人的には、MySQLのボトルネックを、 CPU とメモリの問題にできるようにしていきたい
気持ちがあった。ストレージ速くなったし、Xeon は Core の数増え続けてたし、MySQL
はバージョン上がるごとに、CPUスケーラビリティを改善し続けていたので。
そんな感じで、サービスとしては改善したんだけど

● 「MySQLのバージョンが上がってN倍性能が良くなった」というのは
● （ほとんどの場合）MySQLがたくさんのCPUを活用できるようになって、ス
ループットが改善していってるという話だと
● InnoDB Adaptive Flushing などの改善もありますけどね
● MySQL5.5あたりから強く意識するようになった
● それまでは、とにかくHDDが圧倒的に遅かったけど
● SSDの登場により、CPUとメモリがボトルネックになるケースを、強く意識し
始めた
強く意識したのは、 MySQL5.5 あたりから

● Fusion-IO 流行し始めたころ、調達できたのは ioDrive MLC 320GB
● 先ずは KVS に投入したり、 sharding が困難だったDBに投入したけど
● ほとんどのDBはHDDでも動くように sharding したり、アプリケーション
工夫したりしていたから、 320GB という容量は使いドコロが難しかった
● また、当時はHDDのサーバが大量にあったので、 ioDrive に依存した設
計にしてしまうと、今後どれだけリプレースすればいいの、という恐れもあっ
た
● 他社のワークロードとGREEのワークロード違うから、他社の事例は参考
にしにくかった
先ずは ioDrive 導入した

● 当時、GREEで使ってたHDDのサーバと比較して、 ioDrive のサーバは
コスト的に三倍くらいだったので、三倍以上の成果を挙げさせたいという前
提のもと
● 他のサーバの三倍以上のqueryを受けさせるために
● GREEのDBサーバに求められる要件を分析し、考えていった
三倍の仕事をさせるために

そして
ひらめいた

● GREEのアプリケーションサーバはコネクションプーリングをしておらず、リ
クエストが来るごとにコネクションを張り、レスポンスを返すごとにコネクショ
ン切っていて
● これは当時そこまで珍しくない実装だと思うけど
● 不幸なことに、共通系のDBなるものが存在して
● 特定のサービスでDBがささると、共通系のDBへのコネクションが溜まって
いって、 too many connections が発生し
● 他のサービスが巻き込まれてしまうという負の連鎖
密結合ゆえの問題を軽減しよう

（とてもざっくり）図にするとこう

● too many connections を避けるため、HDDのサーバをたくさん並べ
て、たくさんの connection 受けられるようにするとか
● 重要なサービスと内製ゲームで、slaveのクラスタを分けるとかして
● 数の暴力で解決してたんだけど
かつては富豪的に解決してた

例えば、次のように分けていた

この状況を
ioDriveの低latencyで
なんとかする

● ioDrive や一般的な PCI-e SSD は、 latency が異常によい
● これは現代においても言える、オンプレミス環境のメリット
● ストレージというより、「ちょっと遅いメモリ」と考える
● ちょっと遅いメモリなので、 buffer pool のヒット率を少し下げても大丈夫
● ピークタイムに、ユーザのデータの大半がヒットするなら、性能あまり変わらない
● buffer pool の割当を意図的に減らして、そのぶん max_connections
を増やす。具体的にはHDDのサーバの三倍以上に上げる
● （高価だから）それほど多くないDRAM、 latency のすぐれた ioDrive と
いう組み合わせで、HDDのサーバの三倍以上のqueryを受けさせて、
MySQLのCPU利用率引き上げる
buffer pool のヒット率をうまく下げる

● slave は O_DIRECT 使えばメモリあけられるけど
● master は binlog が page cache に乗り続けてしまう
● そこで、 buffer pool の割当減らしてる master では、 cron で
posix_fadvise(2) たたいて、古い binlog は page cache からちょっ
とずつ落とすようにしてます。
● （言語はなんでもいいんですけど）いまのところ ruby で IO#advise つ
かって :dontneed 叩いてます。
ちょっと一工夫

● ioDriveのサーバ１台と、HDDのサーバ三台程度を等価交換できるように
した
● どうしても I/O の性能が必要になった場合、 ioDrive のサーバを、大量
にある HDD のサーバ三台で置き換えることによって確保できるように
● むかしからあるHDDなサーバの在庫も活用できるように
● これで、 ioDrive のサーバの稼働台数を増やすことが可能になった
● ioDrive たくさん使うことによって、どんなふうに故障するのかがわかって
きた
● ハードウェアは故障するまで使わないと、次のステージに踏み込めない
HDDのサーバとの互換性

よし、壊したから、
次のことを考えよう

● 時は流れ、NAND Flash の価格が下がり、大容量化が進んでいった
● 800GB以上のエンタープライズ仕様のSSDが普通に買えるようになった
● これは使いたい
● 当時、容量大きいSSD使ってる他社事例それほど多くは聞かなかったので、使ってやり
たい
● いまは珍しく無いと思いますけど
● 他社が活用できてないものを活用することによって、サービスの競争力を向上させる
● かつて、masterはHDD、slaveは一台の物理サーバに複数mysqld起
動してSSDで集約するという他社事例あったけど、それだと運用の手間が
増えるし、 Monitoring が難しくなるなと思った
NAND Flash の価格が下がってきた

● 高い random I/O 性能というのもあるけれど
● HDDと比べて消費電力が低く、熱にも強い
● 消費電力が少ないので、それだけ一つのラックにたくさんのサーバ積める
ようになるし
● TurboBoost 使って clock あげて、CPUぶん回してやることもやりやすく
なる
● かつてHDDのために使っていた電力を、より多くのCPUのために使う
● ラック単位で電力を考えたとき、ストレージよりもCPUに多くの電力を回す
ようにする
そもそも、NAND Flash は何がうれしいか

● GREEは力の限り sharding してしまっている
● SSDにリプレースしなくても動かせるDBが大量にある
● 100-200GB程度しかないDBでは、800GBのSSDは無用の長物ではな
かろうか？
だがしかし

こんなことも
あろうかと

ずいぶん
前から

考えていたこと
があった

そうだ

サービス無停止で
master統合しよう

● DBが100-200GB程度しかないなら、統合して400GB以上にしてしまえ
ばいい
● 具体的には次のように
master切り替えの手法を踏まえて

Master統合

● New Master -> New Slave 間で、全力で binary log が転送されて
しまうケースがあった。ネットワークの帯域を圧迫するのがコワイ
● いろいろ改善策はあると思うけど
● slave_compressed_protocol がお手軽でいいかも
● いつもは有効にしたくないなら、 dump 流しこむときだけ有効にしても良
い
● 動的に変更できるので便利
mysqldump の結果を流しこむときに

● change master したあとに start slave すると、一気に binary log
転送され、一気に binary log を SQL_Thread が処理してしまうので
● ここで書いたスクリプト使って、ちょっとずつ binary log 転送して、ちょっ
とずつ binary log を適用させるように
● あと、 binary log は大き過ぎない方が良い感じ
● 弊社の場合は 200MB 程度にしてます
ちょっとだけ工夫

● 次の課題が見えてきた
これでいいかと思いきや

続きは
後編で

つづく

MySQLやSSDとかの話 前編

More Related Content

What's hot

Viewers also liked

Similar to MySQLやSSDとかの話 前編

More from Takanori Sejima