Contenu connexe
Similaire à 第2回 ioDrive+MySQL勉強会 @外道父 ioDriveの世界へようこそ
Similaire à 第2回 ioDrive+MySQL勉強会 @外道父 ioDriveの世界へようこそ (20)
第2回 ioDrive+MySQL勉強会 @外道父 ioDriveの世界へようこそ
- 1. ioDriveの
世界へようこそ
2012/08/27
第2回 ioDrive+MySQL勉強会
外道父@GedowFather
Copyright © DRECOM Co., Ltd All Rights Reserved. 1
- 2. 自己紹介
Copyright © DRECOM Co., Ltd All Rights Reserved. 2
- 3. 自己紹介
■私は
外道父@GedowFather
■所属
ドリコム
■職種
インフラエンジニア
■ブログ
http://blog.father.gedow.net/
Copyright © DRECOM Co., Ltd All Rights Reserved.
3
- 4. 目 次
Copyright © DRECOM Co., Ltd All Rights Reserved. 4
- 5. 目次
1. ioDriveを使う理由
2. サーバ構成
3. キャパシティの計測
4. IOPSの次の敵
Copyright © DRECOM Co., Ltd All Rights Reserved.
5
- 6. WARNING !!
この資料にはioDriveを褒め称
える表現が多く含まれています
全て事実に基づくものであり、
ステマの類ではありません
Copyright © DRECOM Co., Ltd All Rights Reserved.
6
- 7. ioDriveを
使う理由
Copyright © DRECOM Co., Ltd All Rights Reserved. 7
- 9. ioDriveのおさらい
200,000 IOPS
Access Latency 26µs
速い
めっちゃ 全っ然
write 数TB / Day 壊れない
性能の割に Warranty 数十年
高くない
100~300万円
Copyright © DRECOM Co., Ltd All Rights Reserved.
9
- 10. IOPSが凄い!
Copyright © DRECOM Co., Ltd All Rights Reserved. 10
- 12. IOPSが凄い!
速い
UPDATE1,000 QPS
1,000 IOPS 200,000 IOPS
iowait 80% iowait 3%
Copyright © DRECOM Co., Ltd All Rights Reserved.
12
- 16. Access Latencyが凄い!
速い
2,000 QPS
3ms 30µs
iowait 15% iowait 2%以下
Copyright © DRECOM Co., Ltd All Rights Reserved.
16
- 18. 圧倒的パワー
圧倒的スピード
ザ・ワールド
世 界
ioDriveの世界へ入門
クエリが
止まって見えるぜ Copyright © DRECOM Co., Ltd All Rights Reserved.
18
- 19. 耐久年数が凄い!
Copyright © DRECOM Co., Ltd All Rights Reserved. 19
- 20. 壊れない 耐久年数が凄い!
ioDrive
160GB SLC
書き込み平均
75PB まで
write 10TB / Day
・・・?
耐久年数 20.5年
Copyright © DRECOM Co., Ltd All Rights Reserved.
20
- 21. 壊れない 耐久年数が凄い!
参照 平均
3,000 QPS
更新 平均
300 QPS
書き込み平均
10 MB/秒
Copyright © DRECOM Co., Ltd All Rights Reserved.
21
- 22. 壊れない 耐久年数が凄い!
書き込み平均
10MB × 86400秒
864GB / 日
耐久年数
75PB ÷ 864GB ÷ 365日
237年
ioDriveは砕けない
Copyright © DRECOM Co., Ltd All Rights Reserved.
22
- 23. 費用対効果が高い!
Copyright © DRECOM Co., Ltd All Rights Reserved. 23
- 24. 高くない 費用対効果が高い!
SAS 15,000 rpm 300GB
RAIDコントローラー
30~40万円
(1,000 IOPS)
ioDrive
100~300万円
(200,000 IOPS以上)
Copyright © DRECOM Co., Ltd All Rights Reserved.
24
- 25. 高くない 費用対効果が高い!
30~40万円 価格差 100~300万円
4~5倍
1,000 IOPS IOPS差 200,000 IOPS
200倍以上
Copyright © DRECOM Co., Ltd All Rights Reserved.
25
- 26. サーバ台数の削減
Copyright © DRECOM Co., Ltd All Rights Reserved. 26
- 27. サーバ台数の削減
1,000 IOPS IOPS差 200,000 IOPS
200倍以上
といっても、
実際にはどのくらいの
サーバ台数を削減できるのか?
Copyright © DRECOM Co., Ltd All Rights Reserved.
27
- 28. Before
Max CPU : 1,600%
Max IOPS : 1,000
1台当り
CPU : 500%
IOPS : 800
8台構成
合計
CPU : 4,000%
IOPS : 6,400
Copyright © DRECOM Co., Ltd All Rights Reserved.
28
- 29. After 必要合計スペック
CPU : 4,000%
IOPS : 6,400
Max CPU : 1,600%
Max IOPS : 200,000
CPU視点で必要な台数
4000% ÷ 1600%
3台
削
IOPS視点で 減
6,400 ÷ 200,000
1台
Copyright © DRECOM Co., Ltd All Rights Reserved.
29
- 30. After その他の要素
1台当り
CPU : 1,300%
3台構成 IOPS : 2,100
CPUとIOPSをメインで考えるが、さらに
CPUがギリギリ
記憶デバイスの容量
メモリ容量
可用性/負荷分散 構成
などを元に数ヶ月後を見据えた台数にする
Copyright © DRECOM Co., Ltd All Rights Reserved.
30
- 31. サーバ構成
Copyright © DRECOM Co., Ltd All Rights Reserved. 31
- 32. MySQLサーバ
MySQL Community Server
5.5.x
Percona Server with XtraDB
5.5.x
Copyright © DRECOM Co., Ltd All Rights Reserved.
32
- 33. Percona Server の特徴
MySQLのForkである
性能面/機能面で劣ることはない
マルチコアCPU・同時アクセスI/Oに配慮
効率的なバックアップ/その他周辺機能
本家に1~2ヶ月程度の遅れでリリース
マニュアルが整備されている
各種OS用のパッケージを配布
Copyright © DRECOM Co., Ltd All Rights Reserved.
33
- 34. Percona Server
Percona Server を
使わない理由がない
Copyright © DRECOM Co., Ltd All Rights Reserved.
34
- 35. 並列処理やI/Oの設定
~ my.cnf ~
Copyright © DRECOM Co., Ltd All Rights Reserved. 35
- 36. XtraDBです
default-storage-engine = InnoDB
表示上は今までどおり InnoDB ですが、
中身は XtraDB になっています。
mysql> SHOW ENGINES ¥G
********************** 9. row **********************
Engine : InnoDB
Support : DEFAULT
Comment : Percona-XtraDB, Supports transactions,
row-level locking, and foreign keys
Transactions : YES
XA : YES
Savepoints : YES
全テーブルをInnoDBにしてPerconaの恩恵を受けましょう
MyISAMがあるとバックアップでロックが入ってしまいます
Copyright © DRECOM Co., Ltd All Rights Reserved.
36
- 37. よく知られた設定
innodb_flush_method = O_DIRECT
OSによるバッファリングを抑制し、MySQLとOSによるダ
ブルバッファリング状態を防ぎ無駄を省きます
innodb_flush_log_at_trx_commit = 2
ログファイルへの書き出しをCOMMIT毎、データファイルへ
の書き出しを毎秒にすることでフラッシュ効率を上げます
よほど安全にしたいなら 1ですが遅いです
0 はリスクが上がる割に効果が薄いので使いません
Copyright © DRECOM Co., Ltd All Rights Reserved.
37
- 38. Disk I/O
innodb_io_capacity = 40000
デバイスのIOPS上限を設定できます
実運用では 10,000台がせいぜいですが、上限を設ける理由
もないので、それ以上にします
innodb_read_io_threads = 8
innodb_write_io_threads = 16
読み書きの同時スレッド数
ioDriveの24+1チャネル に合わせたが…
デフォルトはどちらも 4
Copyright © DRECOM Co., Ltd All Rights Reserved.
38
- 39. CPUスレッド
innodb_thread_concurrency = 0
並列処理するCPUのスレッド数です
0 は上限なしを意味します
1以上を指定するとそのスレッド数でしか動かないので、1ス
レッドは空けておきたい、という時に使えなくもないです
thread_concurrency = 16
Solaris特有のもの
5.6.1で廃止される
innodb_thread_concurrency を使いましょう
Copyright © DRECOM Co., Ltd All Rights Reserved.
39
- 40. ディスクフラッシュ – チェックポイント
innodb_adaptive_flushing = true
innodb_adaptive_flushing_method = keep_average
従来のInnoDBの場合、ログファイルからのフラッシュ間隔が
結構長くなります
そのため、ある程度まとめてデータを書き込むため瞬間的に高
いIOPSを必要とし、それが原因でiowaitが高騰します
keep_average にすると、0.1秒間隔となり、緩やかな
iowait になり、デメリットも見受けられません
主にSSDやioDrive用として追加されましたが、HDDでも使っ
てみてよいと思います
Copyright © DRECOM Co., Ltd All Rights Reserved.
40
- 41. ディスクフラッシュ – 隣接ページ
innodb_flush_neighbor_pages = none
デフォルトのareaの場合、フラッシュしようとするページの
隣接したページもある程度まとめて書き込もうとします
HDDの場合は効率が上がる可能性があります
ランダムアクセスのコストが小さいioDriveでは余計な機能と
なり、外したほうが効率が上がる可能性があります
Copyright © DRECOM Co., Ltd All Rights Reserved.
41
- 42. ログファイル
innodb_log_block_size = 4096
ioDriveを、MySQLにおいてパフォーマンスが良いとさ
れる4Kbyteでフォーマットした場合、合わせることで
性能が若干向上します
ただし雀の涙程度なので、途中から変えるほどではなく、
最初からできるならしておこう、程度です
Copyright © DRECOM Co., Ltd All Rights Reserved.
42
- 43. Atomic Write
Copyright © DRECOM Co., Ltd All Rights Reserved. 43
- 44. Atomic Write
新機能
絶賛開発中
Double Write の代替
2度書き込む必要が無いようにioDrive側で保証する
アクセス速度の向上、ioDrive寿命が倍
(参考資料)
Tuning For Speed: Percona Server and Fusion-io
http://www.slideshare.net/fusionio/tuning-for-speed-percona-server-and-fusionio
Copyright © DRECOM Co., Ltd All Rights Reserved.
44
- 45. バックアップ
Copyright © DRECOM Co., Ltd All Rights Reserved. 45
- 46. XtraBackupでバックアップ
別途パッケージでインストール
クエリベースではなくデータファイル丸ごとの形
デメリット メリット
InnoDBのみの場合、
mysqldumpよりバッ ロックを必要としない
クアップ容量が大きい 差分バックアップや
mysqldumpより取得 tarストリーミング出
に時間がかかる 力など多機能
リストアが速い
Copyright © DRECOM Co., Ltd All Rights Reserved.
46
- 47. レプリケーション
Copyright © DRECOM Co., Ltd All Rights Reserved. 47
- 48. Semi-Synchronous Replication
SLAVEでの relay-log 保存を
CLIENT
確定してからCOMMIT完了と
する例のアレ
ack
MASTER SLAVE
log
目的
信頼度の高いバックアップ
可用性担保のフェイルオーバー用
Copyright © DRECOM Co., Ltd All Rights Reserved.
48
- 49. Semi-Syncが遅くなる理由
MASTER ⇔ SLAVE のネットワーク往復
SLAVEでのログ保存 Disk I/O
IO_THREAD と SQL_THREAD の非分離
非同期の場合は別スレッドで動作する
Semi-Syncの場合は1スレッドで両方動作する
SLAVE I/O CPU SQL CPU
40% 100%
非同期
(Thread A) (Thread B)
30% 70%
Semi-Sync
(Thread A) (Thread A)
Copyright © DRECOM Co., Ltd All Rights Reserved.
49
- 50. Semi-Syncを採用できる理由
更新QPSは確実に低下するが・・・
ベンチマーク例
非同期 : 更新 12,000 QPS
Semi-Sync : 更新 7,000 QPS
約40%の性能低下 は問題ではない
更新 7,000 QPS が足りていればOK
Copyright © DRECOM Co., Ltd All Rights Reserved.
50
- 51. クラスタ構成
Copyright © DRECOM Co., Ltd All Rights Reserved. 51
- 52. turntable
①
User01 User02 User03 Other01
ioDrive ioDrive ioDrive ・・・ SAS ・・・
Active
MASTER MASTER MASTER ・・・ MASTER ・・・
②
Standby
SLAVE SLAVE SLAVE ・・・ SLAVE ・・・
③
予備
ioDrive SAS
① 垂直/水平分割へ接続
② MASTER障害時にSLAVEが自動昇格
③ SLAVE不在時に自動的にSLAVE化
Copyright © DRECOM Co., Ltd All Rights Reserved.
52
- 53. ① turntableで垂直/水平分割へ接続
Gussan
ドリコム所属
activerecord-turntable 製作者
(参考URL)
Github
https://github.com/drecom/activerecord-turntable
SlideShare
http://www.slideshare.net/drecom/activerecordturntable
Ruby on Rails の Active Record で利用できる
Shardingプラグイン
テーブルの垂直分割だけでなく、行条件での水平分散
ができる
Copyright © DRECOM Co., Ltd All Rights Reserved.
53
- 54. ② MASTER障害時にSLAVEが自動昇格
VIP
MASTER MASTER
VIP
SLAVE MASTER
MASTERのVIPに影響あるほどの障害 VIPが移動して接続先が
ローカル監視で障害と判断したら自動的 切り替わる
にVIPを放棄 フェイルバックは抑制
Copyright © DRECOM Co., Ltd All Rights Reserved.
54
- 55. ③ SLAVE不在時に自動的にSLAVE化
VIP VIP
MASTER MASTER
ioDrive SLAVE
MASTERが自身にSLAVEが無 予備機がバックアップファイル
いことを確認する からリストアする
予備機に対してSLAVE化を要請 MASTER に START SLAVE
※1クラスタに1予備機は無駄なので、ioDrive/SASそれぞれ1台ずつ用意
Copyright © DRECOM Co., Ltd All Rights Reserved.
55
- 56. その他の検討構成
Copyright © DRECOM Co., Ltd All Rights Reserved. 56
- 57. その他の検討構成
MySQL SPIDER
要件によっては間違いなく便利だが、当時は効率を考えた時にいく
つか不安になった
更新クエリのたびに全台にXAトランザクションが発行される
集約関数は一度行データを集めてから数えるので非効率
MySQL Cluster
期待した性能は出なかった
構築も運用も難しいため、エンジニア全員が
身に付けるには敷居が高い
MySQL Proxy
自動MASTER昇格や正しい参照分散ができる
LUAスクリプトを書いて楽しかった
小規模では有用だが・・・
Copyright © DRECOM Co., Ltd All Rights Reserved.
57
- 58. キャパシティの計測
Copyright © DRECOM Co., Ltd All Rights Reserved. 58
- 59. 計測条件
MySQLのベンチマークにおいて重要なこと
クエリの種類(参照/更新)
データの容量とメモリの容量
データの性質
4つの計測条件
参照クエリ データ容量 ≦ メモリ容量
更新クエリ データ容量 ≧ メモリ容量
本番データ/本番クエリだからとやみくもにベンチマークをとっても、
真のキャパシティは計測できません
Copyright © DRECOM Co., Ltd All Rights Reserved.
59
- 60. CPUとIOPS
Copyright © DRECOM Co., Ltd All Rights Reserved. 60
- 61. 参照/更新クエリの必要性能
データ容量 ≦ メモリ容量
全データがメモリに収まる状況において
参照クエリ : CPU
更新クエリ : IOPS
参照はIOPSを必要としない
更新はWEBアプリだと主キー更新
主体のためCPUは微量
Copyright © DRECOM Co., Ltd All Rights Reserved.
61
- 62. 先行するボトルネックを見極める
キャパシティ MAX My Limit
CPU 1,600% 800% 増設納期を
IOPS 1,000 500 考慮して半分
比較
現在値 ピークタイム あと何倍
CPU 200% 4倍 先に到達
IOPS 100 5倍
リクエストがあと4倍に増えたら増設手続きに
入るという判断
ioDriveの場合はIOPSの判断がほぼ不要になる
Copyright © DRECOM Co., Ltd All Rights Reserved.
62
- 63. メモリとデータ容量
Copyright © DRECOM Co., Ltd All Rights Reserved. 63
- 64. メモリの重要性 innodb_buffer_pool_size
write IOPS しか発生しない
データ 100 GB
メモリ 128 GB
参照 : 全てメモリから読み込まれる
更新 : フラッシュのみwrite IOPSが発生する
通常の write IOPS に加えて大量の read IOPS が発生
データ 200 GB
メモリ 128 GB 72 GB 不足
参照 : 72GB分はread IOPSが発生する
更新 : 同上+フラッシュ時にwrite IOPS
Copyright © DRECOM Co., Ltd All Rights Reserved.
64
- 65. LRUによるバッファプール管理
innodb_buffer_pool_size
よくアクセスするデータ メモリ破棄予備軍
YOUNG OLD
62% (5/8) 38% (3/8)
アクセスされると戻る
DISK
破棄
メモリになければ読み込まれ
read IOPS が発生する
Copyright © DRECOM Co., Ltd All Rights Reserved.
65
- 66. メモリとデータ容量にみる read IOPS
アクセス頻度が高いデータ
アクセス頻度が低いデータ
SAFE : 全データがメモリに格納されており read IOPS は発生しない
young old
disk data
WARNING : デバイスに read IOPS が発生し始める
young old
disk data
CRITICAL : デバイスに頻繁な read IOPS が発生し始める
young old
disk data
Copyright © DRECOM Co., Ltd All Rights Reserved.
66
- 67. データの性質とは
アクセス頻度が高いデータ
テーブルごとに考えてみる アクセス頻度が低いデータ
User Item History
例)アイテム数カウント 例)履歴データ
何年経過しても全データが対象 最新数十件しか必要ない
データ全体で考えてみる
頻繁に利用されるデータの割合が多いのか
disk data
古い不要データによって総容量が増加しているだけなのか
disk data
後者ならばメモリ不足が許容されるが、
この度合いを確実に知る術は無い
Copyright © DRECOM Co., Ltd All Rights Reserved.
67
- 68. メモリ管理とデバイスごとの対応
メモリからはみ出たデータの IOPS を
確実には読めなく、被害大の可能性がある
メモリの増設やサーバ分割により
常にメモリに収めるのが確実
メモリからはみ出たデータへのアクセスも
アプリに影響ない程度の速度で動作をする
場合が多い
それなりに放置しても大丈夫
メモリ管理の知識や緊張が薄くなる
酷いクエリ/インデックスでも動く
『ioDriveは甘え』の所以
Copyright © DRECOM Co., Ltd All Rights Reserved.
68
- 70. SQLの質
Copyright © DRECOM Co., Ltd All Rights Reserved. 70
- 71. ioDriveは甘え
IOPS限界が無い
read I/O が発生しても致命傷にならない
スキーマの質 確実に全て下がる
インデックスの質
クエリの質 開発力の低下
必要
開発ルールの整備
堕
自動的な質のチェック 落
Copyright © DRECOM Co., Ltd All Rights Reserved.
71
- 72. Generalistによる質の定量化
外道父が書いた1枚のPHPスクリプト
参照クエリ/更新クエリ/インデックスの
質を数値化
悪い順に並べたTSVデータ出力しエクセル
で閲覧したり、snmpd用値を出力
1時間に1度実行しておく
general.log を採取
クエリのユニーク化
SHOW や EXPLAIN で色々取得
外道父ルールで勝手に質を数値化
Copyright © DRECOM Co., Ltd All Rights Reserved.
72
- 73. Generalist の 参照クエリ診断
DQP(Dirty Query Points)が悪い順に解
決していけばOK
実際のクエリとEXPLAIN結果
悪いと評価した項目とその度合い
Copyright © DRECOM Co., Ltd All Rights Reserved.
73
- 74. Generalist の 更新クエリ診断
DUP(Dirty Update Points)が悪い順に
解決していけばOK
更新行数や更新カラムの対象となるイン
デックス数などから診断
Copyright © DRECOM Co., Ltd All Rights Reserved.
74
- 75. Generalist の インデックス診断
DIP(Dirty Index Points)が悪い順に
解決していけばOK
複合インデックスのCardinality効率など
から診断
Copyright © DRECOM Co., Ltd All Rights Reserved.
75
- 76. IOPSの次の敵
Copyright © DRECOM Co., Ltd All Rights Reserved. 76
- 77. IOPSの次の問題は?
IOPS
ioDriveの出現による 新時代の幕開け
CPU Network Software
Copyright © DRECOM Co., Ltd All Rights Reserved.
77
- 78. IPMI
Copyright © DRECOM Co., Ltd All Rights Reserved. 78
- 79. ioDriveは暴れん坊?
ioDrive搭載サーバで、サーバ起動時から
何もしていないのにSystemCPUが50%
50%
新しく入れたioDriveを疑うのだ!
ioDriveが悪いに決まってる!!
Copyright © DRECOM Co., Ltd All Rights Reserved.
79
- 80. 犯人はIPMIでした
ipmitool パッケージの ipmiモジュールを
削除したら解決しました(テヘペロ
ioDriveが悪いわけないじゃない
まだまだ信心が足りないわ!
Copyright © DRECOM Co., Ltd All Rights Reserved.
80
- 81. NUMA
Copyright © DRECOM Co., Ltd All Rights Reserved. 81
- 82. ioDriveは気まぐれ屋?
ioDrive搭載サーバで、iowaitが急増したり
グラフが虫食いになるほどの状態になる
20~80%
新しく入れたioDriveを疑うのだ!
ioDriveが悪いに決まってる!!
Copyright © DRECOM Co., Ltd All Rights Reserved.
82
- 83. あらゆる調査を行った
aio vmstat io_schedule
iostat strace pidstat
mpstat top lsof
netstat sysctl
ipcs meminfo slabinfo
sar ulimit
nsswitch.conf resolv.conf
nscd ldap
・・・問題発生時は
Disk I/O だけでなくメモリも遅いぞ!?
Copyright © DRECOM Co., Ltd All Rights Reserved.
83
- 84. 犯人はNUMAでした
NUMAを無効にしたら
全てが正常に動作しました(ゲッソリ
sysctl -w vm.zone_reclaim_mode=0
NUMAとは
多量マルチプロセッサにおいて効率的なメモリアクセスを
試みるアーキテクチャ ※kenerl >= v2.6.29
iowait には Disk I/O だけじゃなく
Memory I/O も含むのは常識よ!
せいぜいデュアルCPUのくせに
NUMAが有効なんておこがましいわ!
Copyright © DRECOM Co., Ltd All Rights Reserved.
84
- 85. query_cache
Copyright © DRECOM Co., Ltd All Rights Reserved. 85
- 87. 犯人はquery_cacheでした
query_cacheを無効にしたら
最大までCPUが稼働しました
query_cache_type=0
※query_cache_size=0 だけじゃダメ
キャッシュONで高負荷をかけると mutex lock の増加に
よって Software Interrupt や Context Switch が増加
してCPU利用率が上がらなくなる
キャッシュは効いてた方が良いなんて
人間の傲慢だわ
場合によりけりといってもOFFにし
た方が安定稼働が望めるよ
Copyright © DRECOM Co., Ltd All Rights Reserved.
87
- 88. その他の注意点
Copyright © DRECOM Co., Ltd All Rights Reserved. 88