第2回 ioDrive+MySQL勉強会 @外道父 ioDriveの世界へようこそ

ioDriveの
世界へようこそ
2012/08/27
第2回 ioDrive+MySQL勉強会

外道父@GedowFather
Copyright © DRECOM Co., Ltd All Rights Reserved. 1

自己紹介


自己紹介

■私は
外道父@GedowFather
■所属
ドリコム
■職種
インフラエンジニア
■ブログ
http://blog.father.gedow.net/
Copyright © DRECOM Co., Ltd All Rights Reserved.
3

目次

1. ioDriveを使う理由
2. サーバ構成
3. キャパシティの計測
4. IOPSの次の敵
5

WARNING !!

この資料にはioDriveを褒め称
える表現が多く含まれています

全て事実に基づくものであり、
ステマの類ではありません

6

ioDriveを
使う理由


ioDriveの基本性能や運用について

ブログに書いてあります
http://blog.father.gedow.net/category/hardware/iodrive/

8

ioDriveのおさらい
200,000 IOPS
Access Latency 26µs

速い
めっちゃ全っ然

write 数TB / Day 壊れない
性能の割に Warranty 数十年

高くない
100～300万円
9

IOPSが凄い！


IOPSが凄い！
速い
SAS 15,000 rpm × 6
RAID10
1,000 IOPS

ioDrive
200,000 IOPS
以上
11

IOPSが凄い！
速い
UPDATE1,000 QPS
1,000 IOPS 200,000 IOPS

iowait 80% iowait 3%

12

IOPSが凄い！
速い

圧倒的パワー
IOPS限界を
解決することで

iowaitを激減！
13

Access Latencyが凄い！


速い

3ms

その差100 倍

30µs
15

速い
2,000 QPS
3ms 30µs

iowait 15% iowait 2%以下

16

速い

圧倒的スピード
CPUとの往復時間を
短くすることで

常時
iowaitを激減！
17

圧倒的パワー
圧倒的スピード
ザ・ワールド

世界
ioDriveの世界へ入門
クエリが
止まって見えるぜ Copyright © DRECOM Co., Ltd All Rights Reserved.
18

耐久年数が凄い！


壊れない耐久年数が凄い！

ioDrive
160GB SLC
書き込み平均
75PB まで
write 10TB / Day
・・・？
耐久年数 20.5年
20


参照平均
3,000 QPS
更新平均
300 QPS

書き込み平均
10 MB/秒
21


書き込み平均
10MB × 86400秒

864GB / 日
耐久年数
75PB ÷ 864GB ÷ 365日

237年
ioDriveは砕けない
22

費用対効果が高い！


高くない費用対効果が高い！

SAS 15,000 rpm 300GB
RAIDコントローラー
30～40万円
（1,000 IOPS）

ioDrive
100～300万円
（200,000 IOPS以上）
24

高くない費用対効果が高い！

30～40万円価格差 100～300万円

４～５倍

1,000 IOPS IOPS差 200,000 IOPS

200倍以上
25

サーバ台数の削減


サーバ台数の削減

1,000 IOPS IOPS差 200,000 IOPS

200倍以上

といっても、

実際にはどのくらいの
サーバ台数を削減できるのか？
27

Before
Max CPU : 1,600%
Max IOPS : 1,000
1台当り
CPU : 500%
IOPS : 800
8台構成
合計
CPU : 4,000%
IOPS : 6,400
28

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台
29

After その他の要素

1台当り
CPU : 1,300%
3台構成 IOPS : 2,100

CPUとIOPSをメインで考えるが、さらに
 CPUがギリギリ
 記憶デバイスの容量
 メモリ容量
 可用性／負荷分散構成
などを元に数ヶ月後を見据えた台数にする
30

サーバ構成


MySQLサーバ

MySQL Community Server
5.5.x

Percona Server with XtraDB
5.5.x

32

Percona Server の特徴

 MySQLのForkである
 性能面／機能面で劣ることはない
 マルチコアCPU・同時アクセスI/Oに配慮
 効率的なバックアップ／その他周辺機能
 本家に１～２ヶ月程度の遅れでリリース
 マニュアルが整備されている
 各種OS用のパッケージを配布
33

Percona Server

Percona Server を
使わない理由がない

34

並列処理やI/Oの設定
～ my.cnf ～


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があるとバックアップでロックが入ってしまいます

36

よく知られた設定

 innodb_flush_method = O_DIRECT

OSによるバッファリングを抑制し、MySQLとOSによるダ
ブルバッファリング状態を防ぎ無駄を省きます

 innodb_flush_log_at_trx_commit = 2

 ログファイルへの書き出しをCOMMIT毎、データファイルへ
の書き出しを毎秒にすることでフラッシュ効率を上げます
 よほど安全にしたいなら 1ですが遅いです
 0 はリスクが上がる割に効果が薄いので使いません

37

Disk I/O

 innodb_io_capacity = 40000
 デバイスのIOPS上限を設定できます
 実運用では 10,000台がせいぜいですが、上限を設ける理由
もないので、それ以上にします

 innodb_read_io_threads = 8
 innodb_write_io_threads = 16
 読み書きの同時スレッド数
 ioDriveの24＋1チャネルに合わせたが…
 デフォルトはどちらも 4

38

CPUスレッド

 innodb_thread_concurrency = 0

 並列処理するCPUのスレッド数です
 0 は上限なしを意味します
 1以上を指定するとそのスレッド数でしか動かないので、1ス
レッドは空けておきたい、という時に使えなくもないです

 thread_concurrency = 16

 Solaris特有のもの
 5.6.1で廃止される
 innodb_thread_concurrency を使いましょう

39

ディスクフラッシュ – チェックポイント
 innodb_adaptive_flushing = true
 innodb_adaptive_flushing_method = keep_average

 従来のInnoDBの場合、ログファイルからのフラッシュ間隔が
結構長くなります
 そのため、ある程度まとめてデータを書き込むため瞬間的に高
いIOPSを必要とし、それが原因でiowaitが高騰します
 keep_average にすると、0.1秒間隔となり、緩やかな
iowait になり、デメリットも見受けられません
 主にSSDやioDrive用として追加されましたが、HDDでも使っ
てみてよいと思います

40

ディスクフラッシュ – 隣接ページ

 innodb_flush_neighbor_pages = none

 デフォルトのareaの場合、フラッシュしようとするページの
隣接したページもある程度まとめて書き込もうとします
 HDDの場合は効率が上がる可能性があります
 ランダムアクセスのコストが小さいioDriveでは余計な機能と
なり、外したほうが効率が上がる可能性があります

41

ログファイル

 innodb_log_block_size = 4096

 ioDriveを、MySQLにおいてパフォーマンスが良いとさ
れる４Kbyteでフォーマットした場合、合わせることで
性能が若干向上します
 ただし雀の涙程度なので、途中から変えるほどではなく、
最初からできるならしておこう、程度です

42

Atomic Write


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

44

バックアップ


XtraBackupでバックアップ

 別途パッケージでインストール
 クエリベースではなくデータファイル丸ごとの形

デメリットメリット

 InnoDBのみの場合、
 mysqldumpよりバッロックを必要としない
クアップ容量が大きい  差分バックアップや
 mysqldumpより取得 tarストリーミング出
に時間がかかる力など多機能
 リストアが速い

46

レプリケーション


Semi-Synchronous Replication

SLAVEでの relay-log 保存を
CLIENT
確定してからCOMMIT完了と
する例のアレ
ack
MASTER SLAVE
log

目的
 信頼度の高いバックアップ
 可用性担保のフェイルオーバー用

48

Semi-Syncが遅くなる理由

 MASTER ⇔ SLAVE のネットワーク往復
 SLAVEでのログ保存 Disk I/O
 IO_THREAD と SQL_THREAD の非分離
 非同期の場合は別スレッドで動作する
 Semi-Syncの場合は１スレッドで両方動作する

SLAVE I/O CPU SQL CPU
40% 100%
非同期
(Thread A) (Thread B)
30% 70%
Semi-Sync
(Thread A) (Thread A)
49

Semi-Syncを採用できる理由
更新QPSは確実に低下するが・・・

ベンチマーク例

非同期 : 更新 12,000 QPS
Semi-Sync : 更新 7,000 QPS

 約40%の性能低下は問題ではない
 更新 7,000 QPS が足りていればOK
50

クラスタ構成


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化
52

① 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プラグイン
 テーブルの垂直分割だけでなく、行条件での水平分散
ができる
53

② MASTER障害時にSLAVEが自動昇格

VIP

MASTER MASTER

VIP
SLAVE MASTER

 MASTERのVIPに影響あるほどの障害  VIPが移動して接続先が
 ローカル監視で障害と判断したら自動的切り替わる
にVIPを放棄  フェイルバックは抑制

54

③ SLAVE不在時に自動的にSLAVE化

VIP VIP

MASTER MASTER

ioDrive SLAVE

 MASTERが自身にSLAVEが無  予備機がバックアップファイル
いことを確認するからリストアする
 予備機に対してSLAVE化を要請  MASTER に START SLAVE

※１クラスタに１予備機は無駄なので、ioDrive／SASそれぞれ１台ずつ用意

55

その他の検討構成


その他の検討構成
MySQL SPIDER
要件によっては間違いなく便利だが、当時は効率を考えた時にいく
つか不安になった
 更新クエリのたびに全台にXAトランザクションが発行される
 集約関数は一度行データを集めてから数えるので非効率

MySQL Cluster
 期待した性能は出なかった
 構築も運用も難しいため、エンジニア全員が
身に付けるには敷居が高い

MySQL Proxy
 自動MASTER昇格や正しい参照分散ができる
LUAスクリプトを書いて楽しかった
 小規模では有用だが・・・

57

キャパシティの計測


計測条件

MySQLのベンチマークにおいて重要なこと
 クエリの種類（参照／更新）
 データの容量とメモリの容量
 データの性質
4つの計測条件
参照クエリデータ容量 ≦ メモリ容量
更新クエリデータ容量 ≧ メモリ容量
本番データ／本番クエリだからとやみくもにベンチマークをとっても、
真のキャパシティは計測できません
59

CPUとIOPS


参照／更新クエリの必要性能

データ容量 ≦ メモリ容量
全データがメモリに収まる状況において

参照クエリ : CPU
更新クエリ : IOPS

 参照はIOPSを必要としない
 更新はWEBアプリだと主キー更新
主体のためCPUは微量

61

先行するボトルネックを見極める

キャパシティ MAX My Limit
CPU 1,600% 800% 増設納期を
IOPS 1,000 500 考慮して半分
比較
現在値ピークタイムあと何倍
CPU 200% 4倍先に到達
IOPS 100 5倍

 リクエストがあと４倍に増えたら増設手続きに
入るという判断
 ioDriveの場合はIOPSの判断がほぼ不要になる

62

メモリとデータ容量


メモリの重要性 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
64

LRUによるバッファプール管理

innodb_buffer_pool_size

よくアクセスするデータメモリ破棄予備軍

YOUNG OLD
62% (5/8) 38% (3/8)
アクセスされると戻る

DISK
破棄
メモリになければ読み込まれ
read IOPS が発生する
65

メモリとデータ容量にみる read IOPS
アクセス頻度が高いデータ
アクセス頻度が低いデータ

SAFE : 全データがメモリに格納されており read IOPS は発生しない
young old
disk data

WARNING : デバイスに read IOPS が発生し始める
young old
disk data

CRITICAL : デバイスに頻繁な read IOPS が発生し始める
young old
disk data

66

データの性質とは
アクセス頻度が高いデータ
テーブルごとに考えてみるアクセス頻度が低いデータ

User Item History
例）アイテム数カウント例）履歴データ
何年経過しても全データが対象最新数十件しか必要ない

データ全体で考えてみる
頻繁に利用されるデータの割合が多いのか
disk data
古い不要データによって総容量が増加しているだけなのか
disk data

後者ならばメモリ不足が許容されるが、
この度合いを確実に知る術は無い
67

メモリ管理とデバイスごとの対応
メモリからはみ出たデータの IOPS を
確実には読めなく、被害大の可能性がある
メモリの増設やサーバ分割により
常にメモリに収めるのが確実

メモリからはみ出たデータへのアクセスも
アプリに影響ない程度の速度で動作をする
場合が多い
 それなりに放置しても大丈夫
 メモリ管理の知識や緊張が薄くなる
 酷いクエリ／インデックスでも動く

『ioDriveは甘え』の所以
68

暖機運転
MySQLの起動直後はいっさいメモリに載っていないため
メモリに載るまでレスポンスが遅くなる
young old
disk data 最初は全てdiskから

HTTPを再開する前に
主要テーブルに全参照をかけて
暖機運転をする必要がある

diskアクセスでもHTTPが許容範囲で
動作するほど速いため暖機運転は必要ない

『ioDriveの恩恵』でOK
69

SQLの質


ioDriveは甘え

 IOPS限界が無い
 read I/O が発生しても致命傷にならない

 スキーマの質確実に全て下がる
 インデックスの質
 クエリの質開発力の低下
必要
 開発ルールの整備
堕
 自動的な質のチェック落
71

Generalistによる質の定量化
 外道父が書いた１枚のPHPスクリプト
 参照クエリ／更新クエリ／インデックスの
質を数値化
 悪い順に並べたTSVデータ出力しエクセル
で閲覧したり、snmpd用値を出力

 1時間に1度実行しておく
 general.log を採取
 クエリのユニーク化
 SHOW や EXPLAIN で色々取得
 外道父ルールで勝手に質を数値化
72

Generalist の参照クエリ診断

 DQP（Dirty Query Points）が悪い順に解
決していけばOK
 実際のクエリとEXPLAIN結果
 悪いと評価した項目とその度合い
73

Generalist の更新クエリ診断

 DUP（Dirty Update Points）が悪い順に
解決していけばOK
 更新行数や更新カラムの対象となるイン
デックス数などから診断

74

Generalist のインデックス診断

 DIP（Dirty Index Points）が悪い順に
解決していけばOK
 複合インデックスのCardinality効率など
から診断

75

IOPSの次の敵


IOPSの次の問題は？
IOPS

ioDriveの出現による新時代の幕開け

CPU Network Software
77

IPMI


ioDriveは暴れん坊？
ioDrive搭載サーバで、サーバ起動時から
何もしていないのにSystemCPUが50%

50%

新しく入れたioDriveを疑うのだ！
ioDriveが悪いに決まってる！！
79

犯人はIPMIでした
ipmitool パッケージの ipmiモジュールを
削除したら解決しました（テヘペロ

ioDriveが悪いわけないじゃない
まだまだ信心が足りないわ！

80

NUMA


ioDriveは気まぐれ屋？
ioDrive搭載サーバで、iowaitが急増したり
グラフが虫食いになるほどの状態になる

20～80%

82

あらゆる調査を行った
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 だけでなくメモリも遅いぞ！？
83

犯人はNUMAでした
NUMAを無効にしたら
全てが正常に動作しました（ゲッソリ
sysctl -w vm.zone_reclaim_mode=0

NUMAとは
多量マルチプロセッサにおいて効率的なメモリアクセスを
試みるアーキテクチャ ※kenerl >= v2.6.29

 iowait には Disk I/O だけじゃなく
Memory I/O も含むのは常識よ！
 せいぜいデュアルCPUのくせに
NUMAが有効なんておこがましいわ！
84

query_cache


ioDriveの副作用？
ioDrive入れたからベンチマークとってみたけど
全然性能でないし、なんかCPU詰まってる！

キャパシティ : 1600%
ベンチマーク : 350% まで

86

犯人はquery_cacheでした
query_cacheを無効にしたら
最大までCPUが稼働しました
query_cache_type=0
※query_cache_size=0 だけじゃダメ

キャッシュONで高負荷をかけると mutex lock の増加に
よって Software Interrupt や Context Switch が増加
してCPU利用率が上がらなくなる

 キャッシュは効いてた方が良いなんて
人間の傲慢だわ
 場合によりけりといってもOFFにし
た方が安定稼働が望めるよ
87

その他の注意点


経験の少ない領域へ
何年も悩んできたIOPS周り
あまりにその問題に注力してきたために
ioDriveの導入によって
未経験の問題が襲い掛かることでしょう

MySQL OS ハードウェア
CPU
my.cnf ファイル
メモリ
トランザクションメモリ
データ容量
レプリケーションネットワーク
ネットワーク

89

導入後も
ioDriveに甘えず
精進せよ！

fin

第2回 ioDrive+MySQL勉強会 @外道父 ioDriveの世界へようこそ

Recomendados

Recomendados

Más contenido relacionado

La actualidad más candente

La actualidad más candente (20)

Similar a 第2回 ioDrive+MySQL勉強会 @外道父 ioDriveの世界へようこそ

Similar a 第2回 ioDrive+MySQL勉強会 @外道父 ioDriveの世界へようこそ (20)

第2回 ioDrive+MySQL勉強会 @外道父 ioDriveの世界へようこそ