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

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Viewers also liked

Viewers also liked (20)

Similar to MySQLやSSDとかの話　前編

Similar to MySQLやSSDとかの話　前編 (20)