MySQLで高トラフィックに立ち向かう

Slide 1

Slide 1 text

MySQLで高トラフィックに立ち向かう LT大会#2 Takashi Abe Mynet Inc. 01/15 2015

Slide 2

Slide 2 text

前提 InnoDB MySQL以外の話もちょっとします特定のサービス特性にフォーカスするものではありませんが、ソーシャルゲームをベースにして話します

Slide 3

Slide 3 text

DBサーバへのトラフィック参照系クエリ select 更新系クエリ insert, update, delete

Slide 4

Slide 4 text

よくある最小構成

Slide 5

Slide 5 text

参照系への負荷対策

Slide 6

Slide 6 text

スケールアップ金の弾丸 ioDrive

Slide 7

Slide 7 text

スケールアウトスレーブの追加 MySQLのレプリケーション機能でマスタのデータを複製するキャッシュレイヤの追加 memcached, RedisなどのKVSを利用する参照性能はRDBに比べて桁違いに良い参照頻度の高いデータをメインにキャッシュに乗せるカードステータスなどのマスタデータユーザのニックネーム

Slide 8

Slide 8 text

スケールアウトした構成

Slide 9

Slide 9 text

更新系への負荷対策

Slide 10

Slide 10 text

スケールアップ金の弾丸 ioDrive メモリガン積みインメモリならioDriveと同等以上の性能が出る Amazon RDSの場合最大244GBまで拡張可能

Slide 11

Slide 11 text

スケールアウトマスタの分割 DB、テーブルを複数サーバに分割し、クエリに応じて動的に問合せ先サーバを選択する分割方式より垂直分割/水平分割があるアプリケーション側での実装が多い

Slide 12

Slide 12 text

垂直分割

Slide 13

Slide 13 text

垂直分割関係性の薄いデータをそれぞれ異なるDBに分散接続先DBを変えるだけなので大して実装コストはそれほどない、はず (例) ユーザデータ系ログ系マスタデータ系

Slide 14

Slide 14 text

垂直分割イメージ

Slide 15

Slide 15 text

水平分割

Slide 16

Slide 16 text

水平分割複数サーバで同じDBを用意し、キーとなるデータによって格納先を分割する DB名から一意に格納先のテーブルを特定出来ないのでサーバ振り分けの実装が重くなりがちキーの余剰、ハッシュ値などによって分割を行う

Slide 17

Slide 17 text

水平分割分割例 userテーブル、user_idをキーにして分割する user_idを100で割った余剰をテーブル名のサフィックスにする user_00 ~ user_99のテーブルに分割可能サーバA: user_00 ~ user_49 サーバB: user_50 ~ user_99

Slide 18

Slide 18 text

水平分割イメージ

Slide 19

Slide 19 text

スケールアウトした構成

Slide 20

Slide 20 text

分割するタイミング設計、制約がきついため途中から分割しようとするのはつらいスモールスタートする場合、最初から分割しておいて分割された各DBを1台に格納しておく戦略もアリ分割されてさえいれば、後から別サーバに乗せることも容易になる

Slide 21

Slide 21 text

注意点異なるDBに格納されるのでjoinが使えなくなる水平分割の場合分割すればするほどパフォーマンス低下串刺しで検索したい時などトランザクションが煩雑になる

Slide 22

Slide 22 text

まとめ

Slide 23

Slide 23 text

参照系マスタスレーブ+KVSの鉄板構成後からでもスケールアウトは比較的容易更新系垂直、水平分割でマスタへのトラフィックを分散させる後からスケールアウトするのがつらいのでプロジェクトの始めに方針を検討する