Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
MySQLで高トラフィックに立ち向かう
Search
takashabe
January 15, 2015
Technology
0
1.8k
MySQLで高トラフィックに立ち向かう
社内LT大会#2で話した内容です。
takashabe
January 15, 2015
Tweet
Share
More Decks by takashabe
See All by takashabe
より良いターミナルでの生活を求めて
takashabe
0
41
OpenCensusでcustom context propagationとexporterを書いた話 / OpenCensus with custom context propagation and exporter
takashabe
0
1.6k
pubsub with concurrent
takashabe
1
870
社内ISUCONを開催した話
takashabe
0
1.6k
ISUCON大反省会
takashabe
0
1.8k
gitのブランチ戦略
takashabe
8
5.8k
サルでもわかるgit
takashabe
0
1.4k
playで複数DBする
takashabe
0
1.6k
GitHubの良さ
takashabe
2
2.2k
Other Decks in Technology
See All in Technology
銀行でDevOpsを進める理由と実践例 / 20250317 Masaki Iwama
shift_evolve
1
110
3/26 クラウド食堂LT #2 GenU案件を通して学んだ教訓 登壇資料
ymae
1
200
新卒エンジニア研修の試行錯誤と工夫/nikkei-tech-talk-31
nishiuma
0
200
ソフトウェア開発現代史: なぜ日本のソフトウェア開発は「滝」なのか?製造業の成功体験とのギャップ #jassttokyo
takabow
2
1.5k
SSH公開鍵認証による接続 / Connecting with SSH Public Key Authentication
kaityo256
PRO
2
220
アプリケーション固有の「ロジックの脆弱性」を防ぐ開発者のためのセキュリティ観点
flatt_security
25
9.3k
空が堕ち、大地が割れ、海が涸れた日~もしも愛用しているフレームワークが開発停止したら?~ #phperkaigi 2025
77web
2
1k
Tirez profit de Messenger pour améliorer votre architecture
tucksaun
1
140
Dapr For Java Developers SouJava 25
salaboy
1
130
【5分でわかる】セーフィー エンジニア向け会社紹介
safie_recruit
0
20k
Cloud Native PG 使ってみて気づいたことと最新機能の紹介 - 第52回PostgreSQLアンカンファレンス
seinoyu
1
190
Engineering Managementのグローバルトレンド #emoasis / Engineering Management Global Trend
kyonmm
PRO
6
990
Featured
See All Featured
The Cost Of JavaScript in 2023
addyosmani
48
7.6k
Why You Should Never Use an ORM
jnunemaker
PRO
55
9.3k
The Success of Rails: Ensuring Growth for the Next 100 Years
eileencodes
44
7.1k
Responsive Adventures: Dirty Tricks From The Dark Corners of Front-End
smashingmag
251
21k
A Philosophy of Restraint
colly
203
16k
Designing Dashboards & Data Visualisations in Web Apps
destraynor
231
53k
4 Signs Your Business is Dying
shpigford
183
22k
Docker and Python
trallard
44
3.3k
Mobile First: as difficult as doing things right
swwweet
223
9.5k
Site-Speed That Sticks
csswizardry
4
450
The Web Performance Landscape in 2024 [PerfNow 2024]
tammyeverts
4
490
Improving Core Web Vitals using Speculation Rules API
sergeychernyshev
11
610
Transcript
MySQLで高トラフィックに立ち向かう LT大会#2 Takashi Abe Mynet Inc. 01/15 2015
前提 InnoDB MySQL以外の話もちょっとします 特定のサービス特性にフォーカスするものではありま せんが、ソーシャルゲームをベースにして話します
DBサーバへのトラフィック 参照系クエリ select 更新系クエリ insert, update, delete
よくある最小構成
参照系への負荷対策
スケールアップ 金の弾丸 ioDrive
スケールアウト スレーブの追加 MySQLのレプリケーション機能でマスタのデータを複製する キャッシュレイヤの追加 memcached, RedisなどのKVSを利用する 参照性能はRDBに比べて桁違いに良い 参照頻度の高いデータをメインにキャッシュに乗せる カードステータスなどのマスタデータ ユーザのニックネーム
スケールアウトした構成
更新系への負荷対策
スケールアップ 金の弾丸 ioDrive メモリガン積み インメモリならioDriveと同等以上の性能が出る Amazon RDSの場合最大244GBまで拡張可能
スケールアウト マスタの分割 DB、テーブルを複数サーバに分割し、クエリに応じて 動的に問合せ先サーバを選択する 分割方式より垂直分割/水平分割がある アプリケーション側での実装が多い
垂直分割
垂直分割 関係性の薄いデータをそれぞれ異なるDBに分散 接続先DBを変えるだけなので大して実装コストはそれ ほどない、はず (例) ユーザデータ系 ログ系 マスタデータ系
垂直分割イメージ
水平分割
水平分割 複数サーバで同じDBを用意し、キーとなるデータによっ て格納先を分割する DB名から一意に格納先のテーブルを特定出来ないの でサーバ振り分けの実装が重くなりがち キーの余剰、ハッシュ値などによって分割を行う
水平分割 分割例 userテーブル、user_idをキーにして分割する user_idを100で割った余剰をテーブル名のサフィック スにする user_00 ~ user_99のテーブルに分割可能 サーバA: user_00
~ user_49 サーバB: user_50 ~ user_99
水平分割イメージ
スケールアウトした構成
分割するタイミング 設計、制約がきついため途中から分割しようとするのは つらい スモールスタートする場合、最初から分割しておいて分 割された各DBを1台に格納しておく戦略もアリ 分割されてさえいれば、後から別サーバに乗せること も容易になる
注意点 異なるDBに格納されるのでjoinが使えなくなる 水平分割の場合 分割すればするほどパフォーマンス低下 串刺しで検索したい時など トランザクションが煩雑になる
まとめ
参照系 マスタスレーブ+KVSの鉄板構成 後からでもスケールアウトは比較的容易 更新系 垂直、水平分割でマスタへのトラフィックを分散させる 後からスケールアウトするのがつらいのでプロジェク トの始めに方針を検討する