20131113_mysql_on_分散fsセミナー資料

MySQL on 分散FS
〜NOSQLで構築したファイルシステム上でMySQLを動かす

Kobe Digital Labo, Inc.
　　　　　　　　　岩瀬高博
Twitter:　@okuyamaoo
Mail:　iwase@kdl.co.jp

http://okuyama-project.com/

自己紹介
・岩瀬高博(@okuyamaoo)
　> (株)　神戸デジタル・ラボ所属

業務及び活動
>大規模e-コマースサイトのチューニング、運用
>分散処理、データベースの研究及び適応
>(独)情報通信研究機構　特別研究員
　　　　　研究領域:大規模Webアーカイブ

>分散KVS okuyama、CEP Setsuna の開発
　　>OSS、Java、DB、車が好き

今日のお話し
1.ファイルシステム？
2.NOSQLファイルシステム
3.MySQLを動かす

ファイルシステムとは？

ファイルシステム?
・そもそもファイルシステムとは？
・内蔵のHDDやSSD、外付けディスク、ネットワーク上の
ストレージ(NFS等)などの記憶デバイスを等価的に扱う仕組み。

Wikipediaより

ファイルシステムが利用する機器
・ファイルシステムが利用しているハードは？
・HDD
最も主流な記憶装置。
内臓する円盤に磁気を散布してそこにデータを記憶。
それを磁気ヘッドと言われる目のようなもので読み込む。

・SSD
徐々に浸透してきている記憶装置
HDDの様に円盤やヘッドなどの稼働部を持たず、
フラッシュメモリにデータを記憶。

・ioDrive
最近特に注目度の高い超高速デバイス。
NANDフラッシュメモリを記憶部に持ち、接続方式を
PCIeとすることでSSDを超える速度を発揮する。

ファイルシステムの動き
・どのようにデータを格納しているか？
・ではアプリケーションから書き出されたデータは
どのように格納されているか？

・どのようにデータを保存しているか？
・すごくおおざっぱに表現すると巨大な配列として
保存されている。

全てバイトデータとして扱い、先頭からあらかじめ決められた
サイズ分だけ塊として分割しつつ、配列のように保存していく。

このサイズは最近では4096byteが主流

・どのようにデータを取り出すか？
・先ほどの配列に対して位置を指定して取り出す。
例えば先ほどのファイルの1バイトから2048バイトを取り出す場
合

ここのデータを取り出す
5000バイトから12000バイトを取り出す場合は?

この2つを取り出す

ファイルシステムが遅い時
・よくHDDが遅いといわれる原因は？
このように円盤上にデータが
保存されている。
連続してデータを取り出す場合は、
先頭から順にデータを取り出せば
よいので、高速に取り出せる。

ではこのように離れた場所のデータを
読み込みたい場合はどうするか？
円盤とヘッドが動いてデータの場所まで
移動しないといけない。
この移動に時間がかかる

ファイルシステムが遅い時
・SSDはなぜ速い？

SSDはHDDと違い円盤にデータを保存しない。
データを取り出す際に物理的な位置を意識した
移動などの時間をともなわず、データが保存さて
いる記憶素子上から即取り出せるため高速。
つまり1つのデータの塊に
アクセスするのが凄く速い

分散ファイルシステム
・分散ファイルシステムとは？
・各筐体の持つファイルシステムを束ねて1つの
ファイルシステムに見せる仕組み。負荷分散、容量拡大が出来る
利用
分散FS

NOSQLの特性
・NOSQL 特にKVSの特性は？
・KVSは1つのデータへのアクセスが速い。

NOSQLの特性
・例えば分散KVSのokuyamaの性能
・okuyamaは分散しスケールアウトが可能なKVS
ストレージにメモリ、圧縮メモリ、ディスクなどが選べる
サーバ2台で
10万QPS

okuyamaはメモリストレージを利用
メモリで合ってもWALログでデータは永続化される。

NOSQLの特性
・NOSQL特にKVSの特性は？
・これは先ほどのSSDの良いところに似てませんか？

NOSQLの特性
・KVSは1つのデータの取り出しが高速
・これは先ほどのSSDの良いところに似てませんか？

そこで、okuyamaを記憶装置として利用できる
ファイルシステムを作ってみました

okuyamaとは？
・okuyamaはJavaで実装されたNOSQLの一種

okuyamaとは？
・どのような機能をもっているか？

okuyamaとは？
分散KVS
・OSS
・完全冗長化（SPOFなし）
・無停止でのスケールアウト
・100台以上のサーバ規模での
稼働実績

ストレージ特性
・非永続型 or 永続型(WALログ方式)
・メモリ or ディスク or メモリ+ディスク　
特性別ストレージ
・ストレージ間の互換性
・仮想メモリ機能
・独自圧縮機能
・パーティション機能

アクセス
・独自プロトコル(Ascii)
Java、PHP、Ruby用が存在
・memcached互換
・CAS、加減算、Multi系も対応
・バックアップ等のクライアントも有り
・Hadoop連携

データ構造
・Key-Value構造
・Tagの付与
・有効期限付きデータ
・全文検索用Index

okuyamaとは？
分散構成を作ることが可能
分散KVS
・OSS
・完全冗長化（SPOFなし）
・無停止でのスケールアウト
・100台以上のサーバ規模での
稼働実績

ストレージ特性
・非永続型 or 永続型(WALログ方式)
・メモリ or ディスク or メモリ+ディスク　
特性別ストレージ
・ストレージ間の互換性
・仮想メモリ機能
・独自圧縮機能
・パーティション機能

アクセス
・独自プロトコル(Ascii)
Java、PHP、Ruby用が存在
・memcached互換
・CAS、加減算、Multi系も対応
・バックアップ等のクライアントも有り
・Hadoop連携

データ構造
・Key-Value構造
・Tagの付与
・有効期限付きデータ
・全文検索用Index

okuyamaを利用した分散FS
・分散ファイルシステムとして利用する
ファイルシステムとしてokuyamaをマウント出来る仕組みを開発
mount

okuyamaFuse
・FUSEを利用してデータ格納先をokuyamaへ
FUSEとはLinux系のファイルシステムを
ユーザプロセスで自由に作成できる仕組み。
okuyamaFs

データは全てokuyamaに
格納され、ファイルのメタ
情報なども全て格納される。

MySQL on okuyamaFuse
・Fuseで実装したファイルシステムは
一般的なファイルシステムとして利用可能

okuyamaFuse上でMySQLを動かす

mount

・目的は？
・ランダムなアクセスが得意なKVS-FS上で
MySQLを動かした場合の性能を検証。
・検証結果からMySQLのディスクへの
　アクセスプランに最適なFSの検討

テスト内容
・テスト環境
MySQL稼働環境
・CentOS6.4(64bit)
・MySQL5.5
　> InnoDB
　>O_DIRECTオプション利用
　・Intel(R) Xeon(R) CPU E5-2620 0 @ 2.00GHz ✕ 2
※物理6Core 仮想 12コア ✕　2

　・メモリ64GB
・SATA-7200rpm ✕1 / SSD(Intel DC S3700 Series) ✕ 1

テスト内容
・テスト環境
okuyama稼働環境(3台)
・CentOS6.4(64bit)
　・Intel(R) Xeon(R) CPU E5-2620 0 @ 2.00GHz ✕ 2
※物理6Core 仮想 12コア　✕ 2

　・メモリ64GB
・SATA-7200rpm ✕1

　これら全てインテル株式会社様、
クリエーションライン株式会社様に
検証用としてご提供頂きました!!

テスト内容
・テスト内容
・sysbenchを用いてOLTPテスト(トランザクション回数)
※OLTPテストとは参照系/更新系両方の混在テスト

・MySQLへの同時接続数を2〜100に増やしながら、
　　1分間当たりのトランザクション回数を測定
・MySQLの”datadir”をSATA、SSD、okuyamaFuseに
それぞれに変更し検証
　

sysbench version 0.4.12を利用
　テスト用データは100万件とした

サーバ構成
MySQL on SATA/SSD


ローカルディスクを見ない

テスト結果
トランザクション/秒

SATAに比べると圧倒的に速い。
SSDに比べると約65%程度の性能

同時接続数

考察
・結果から実際にokuyamaFuseをデバッグ
　 IOを全てロギング特性を見る
14:38:28.619: read:/mysqldata/ibdata1 offset:109363200 buf.limit:16384
1行がMySQLからのI/O
14:38:28.669: write path:/mysqldata/ib_logfile0 offset:3025920 isWritepage:false buf.limit:1024
14:38:28.677: fsync
14:38:28.744: fsync

考察
・結果から実際にokuyamaFuseをデバッグ

Readが圧倒的に多い


offsetがバラバラ
14:38:28.648: read:/mysqldata/ibdata1 offset:168755200 buf.limit:16384 ※offsetは読み込み開始位置
14:38:28.677: fsync
14:38:28.744: fsync

まとめ
・okuyamaをファイルシステムにしてみた結果
・ランダムな書き込み、読み込みが発生する場合は
SATAよりも高い性能が見込めることはわかった
okuyamaサーバが複数台のためIO分散されている。
・データベースのIOを細かく調査出来るため、
利用シーンに合わせてチューニング出来る可能性がある
※今回のテストではReadが多いため、okuyama側の
Readチューニングが効果的など
　・NOSQL(分散KVS)を余すこと無く利用するこんな構成も

こんな構成も？？
AP
サーバ

okuyamaFuseをマウントし構築
ローカルディスクレスなども

mount

アプリケーション
キャッシュ
APキャッシュとしてMemcached等の
代わりにokuyamaをそのまま利用

最後に
・Information
Weｂ
　 http://okuyama-project.com/
Development
http://sourceforge.jp/projects/okuyama/

Facebook
http://www.facebook.com/okuyama.jp
okuyamaとokuyamaFuseは全てオープンソースで公開しています

20131113_mysql_on_分散fsセミナー資料

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to 20131113_mysql_on_分散fsセミナー資料

Similar to 20131113_mysql_on_分散fsセミナー資料 (20)

More from Takahiro Iwase

More from Takahiro Iwase (10)

20131113_mysql_on_分散fsセミナー資料