NVMFS 使ってみたとか 言っちゃって

マジカジュアルな奴!

桑野　章弘

自己紹介

•桑野　章弘 •サイバーエージェント •サーバサイドエンジニア •Twitter: @kuwa_tw •Blog: http://d.hatena.ne.jp/akuwano/

自己紹介

•桑野　章弘 •サイバーエージェント •サーバサイドエンジニア •Twitter: @kuwa_tw •Blog: http://d.hatena.ne.jp/akuwano/

みんなカジュアルとかわかってるんですか

本当にカジュアルな 奴です

MongoDBの方から来ました

今日の話

NVMFS試してみた

DB構成

•MySQL 5.5 •垂直分散メイン+レプリケーション分割

メイン系 イベント系 ヒストリ系 アバター系

レプリの更新テーブルを分散

Master

Slave

通常の フルレプリ

（昇格、バックアップ）

現環境の問題点

•DB容量肥大化による容量問題 •マスタ更新過多によるスレーブ遅延解消のためテーブル分散レプリ

•運用負荷の増大（NEW！）

解決策

•ハードウェアのスペックアップ •NVMFS+Page Compressionの検討

スペックアップ

•当たり前だがお金を使えば解決 •メニーマニー •メニーマニー

だと話が終わるので

NVMFS検討

•先ほど説明がありましたが •データアクセスとデータ圧縮をiodrive側のAtomicWriteとTrimを使って透過的に行う

•速度と容量圧縮の良いところ取り（！）

NVMFSの導入

•サービスへの一部サーバとして導入 •MySQL単体試験 •スレーブへの導入

導入箇所

•Percona-Server 5.6 •マスタへのフルレプリとして導入

メイン系 イベント系 ヒストリ系

レプリの更新テーブルを分散

Master

Slave

通常の フルレプリ

フルレプリで テスト導入

比較

mysql> show create table t1\G *************************** 1. row *************************** Table: t1 Create Table: CREATE TABLE `t1` ( `id` int(10) unsigned NOT NULL AUTO_INCREMENT, `k` int(10) unsigned NOT NULL DEFAULT '0', `c` char(120) NOT NULL DEFAULT '', `pad` char(60) NOT NULL DEFAULT '', PRIMARY KEY (`id`), KEY `k` (`k`) ) ENGINE=InnoDB AUTO_INCREMENT=50000001 DEFAULT CHARSET=utf8 ROW_FORMAT=PAGE_COMPRESSION !

!

結果比較／考察

•単純性能比較 •サービス導入検討比較

単純比較

•トランザクション数比較 •トランザクション数による圧縮率の低下確認

RWは8割、ROだと6～7割弱

LAは圧縮伸張で高くなる

書き込み回数で徐々に断片化

サービス導入比較

•圧縮率 •書き込み時CPU負荷確認 • ioDriveへのWrite比較

圧縮率

•カッとなってサービスで使ってる実データ圧縮した

[root@sx300-dbm101 sbtest]# ls -lh * | grep ibd -rw-rw---- 1 root root 12G 12月 12 18:00 2014 t1.ibd !

!

[root@sx300-dbm101 sbtest]# du -sh * | grep ibd 1.5G t1.ibd !

45%

圧縮率•1GB以上のテーブルを圧縮した結果 •圧縮したテーブルの容量比較 •217G •484G •45%

CPU負荷

•CPU負荷の比較

User 約2倍

CPUおかわり

•よりCPUバウンドによるこのとおり。 Userが頭打ちに

CPU負荷

•でもただでさえCPUバウンドなのに、よりCPUバウンドに寄っちゃう

ioDriveへの書込

つかいかた•データ量は増えていく事が期待されるテーブル

•クエリは多すぎない方が好ましい •ヒストリログとかDWHとか •バックアップサーバとか

まとめ

まとめ

うそですすいません((((；ﾟДﾟ))))

まとめ•CPUバウンドな処理な所には入れづらいっす

•でも容量は欲しいけどアクセスが頻繁じゃないものには有用です

•試験しつつ模索中 •引き続き検証していきます