弊社の一部のサービスでも絶賛活躍中のFusion-io社のioDrive。
Fusion-io ioDriveとFusion-io ioDrive Duoではどちらも、最小容量のモデルはSLC型、そのほかはMLC型を使っているが、Fusion ioDriveの読み込み速度は735〜770MB/s、書き込み速度は510〜750MB/sだ。Fusion ioDrive Duoに至っては、読み込み速度は1.0〜1.5GB/s、書き込み速度は一律1.5GB/sという数値をたたき出す。
＠IT Special PR：Fusion-ioのクールな技術を使いこなせ！
今日はデルさん主催の下記セミナーにて、このFusion-ioに関するDELL社の検証結果紹介や、DeNA松信さんによるMySQL環境でのFusion-io検証結果およびDeNAでの利用に関するお話が聞けるとのことだったので、途中からの参加で恐縮だったのですが、お邪魔させてもらいました。
後半の2セッションだけ参加してきたのですが、おそらく全4セッションのうちの前半の3セッション分は資料が公開されそうなので、最後のDeNA松信さんのセッションのメモを以下に残しておきます。
数字的な検証結果も興味深いところですが、ディスクやファイルシステムの特性、MySQLの仕様、I/O種別などを理解した上での適材適所な設計をすることでDBパフォーマンスは大きく変わってくるんだと改めて再認識しました。めちゃめちゃ参考になりました！松信さんありがとうございました！
※ 尚、聞きながら、急ぎ足でメモを取ったので、内容・数字に誤りがある場合があるかもしれませんが、ご了承ください。
講演者
- 「MySQL環境におけるFusion-io検証結果とDeNAにおける活用価値」
- 松信 嘉範 氏
- 株式会社ディー・エヌ・エー
- システム統括本部 IT基盤部
- インフラ担当プリンシパルアーキテクト MySQLエバンジェリスト
DBサーバにおいてSSDがなぜ必要か
- SSD化によって、IOPSが桁違いに向上する
- ほとんどのデータベースアクセスはランダムI/Oになる
- 通常のSAS HDDでは、1ドライブあたり200IOPS程度
- HDDがボトルネックになるケースが多い
- SATA SSDのIOPSは、2000+ (write) / 5000+ (read)
- PCI-E SSDになると、数万単位のIOPSを実現できる
SSDによるパフォーマンス向上と、1台あたりの処理量が大きくなることによるサーバの台数削減が可能
ハードウェアの検討事項
- SSDかHDDか
- ストレージのインタフェース
- 瞬断への保護機構
- バッテリー付き、ライトキャッシュ無しなど
- RAID
- ネットワーク
- メモリ
- CPU
その他、考えること
- 複製
- ファイルシステム
- ファイルの置き場所
- SSD特有の問題
- 書き込み性能の段階的な低下
- 書き込み寿命
検証に使ったストレージ
- HDD: (すいません、メモれなかった・・・)
- SSD: Intel X25-E(SATA, 30G, SLC)
- PCI-E SSD: Fusion-IO(160GB, SLC)
ランダムリード性能
| 1スレッド | 100スレッド | |
|---|---|---|
| HDD | 196 reads/s | 443 reads/s |
| SSD | 3508 reads/s | 14538 reads/s |
| Fusion-io | 10526 reads/s | 41379 reads/s |
- シングルスレッドでは、X25-EはHDDの16倍、Fusion-ioはHDDの25倍
- ストレージの遅延を緩和する上で効果的
- SSDは並列性でも優れている
PCI-Express SSDのよさ
- 長所
- インタフェースの速度がはやい (PCI-E x8 で2GB/s)
- 短所
- ほとんどのマザーボードで、搭載可能なPCI-Eスロット数が少ない
- ホットスワップができない
ランダムライト性能
- xfsでベンチマーク
- HDDは並列性は無い(パフォーマンスが変わらない)が、Fusion-ioは並列性が高い(スレッド数を増やせばパフォーマンスアップ、1.8倍に伸びた)
書き込み性能の段階的な低下
- 処理開始時点では、性能は高い
- 大量の書き込みが発生すると、書き込みIOPSは徐々に悪化
- 予備領域を増やすと、書き込みIOPSの最低ラインは上がる
- 書き込み処理が緩くなると、書き込みIOPSは徐々に回復する
- RAID0で書き込みを分散させることと、下落を緩和できる
シーケンシャルIO
- データベースにもシーケンシャル処理はある
- フルテーブルスキャン、REDOログ書き込み、バックアップ
- シーケンシャルリード性能は優れているが、劇的ではない
- 4本でRAIDを組んだHDDであれば十分
fsync()の速度
- トランザクションのコミットで呼ばれる
- HDDに比べてさほどアドバンテージはない
- HDDのシーケンシャルライトは高速
- バッテリーバックアップ付ライトキャッシュを使えば、REDOログへのコミット等のシーケンシャルな書き込みを大きく高速化できる
ファイルシステムの違い
- ext3は同一ファイルへの書き込みが、同時に1スレッドしかできない(ext4も同様)
- xfsはrawデバイスに近い並列性(複数スレッドでの同時書き込み可)
- Fusion-ioで使うならxfs
I/Oブロックサイズの影響
- Fusion-ioクラスのSSDでは、IO転送量そのものがIOPSに大きな影響を与える
- ブロックサイズが小さいほうが、SSDがより高速
RAID
- PCI-E SSDには複数枚でハードウェアRAIDを組む手段がない
- Fusion-io自体が、内部的にRAID5相当の機構を持っている
- I/OコントローラやPCI-EボードがSPOFになる
- ソフトウェアRAID1のレスポンスタイムは、ディスクへの書き込み時間の遅い方のディスクに引っ張られる
- ソフトウェアRAID1では、RAIDなしの場合に比べてIOPSが悪化、でも10000IOPSは超えているので、十分
ランダムリード性能
- 理論上は2倍以上の伸び、ピークでも73%のパフォーマンス向上
ソフトウェアRAID0
- SSDの故障率はHDDより低い
- Fusion-ioはホットスワップができないので、RAID1やRAID5による恩恵はそれほど大きくない
- ドライブあたりの書き込み頻度が下がるので、書き込み速度の遅延が緩和
- 実際に測定した結果、追加の予備領域をとらなくてもランダムライト性能が落ちなかった
Fusion-io+MySQLのベンチマーク
- DBT-2(ディスクIOバウンドのベンチマーク)
- Intel Xeon Nehalem 8core
- SUSE Enterprise Linux 11, xfs
- MySQL 5.5.2M2
HDD vs Intel SSD vs Fusion-io
| Buffer Pool | HDD | Intel SSD | Fusion-io |
|---|---|---|---|
| 1GB | 1125.44 | 5709.6 | 15122.75 |
| 2GB | 1863.19 | 7536.55 | 20096.33 |
| 5GB | 4385.18 | 12892.56 | 30846.34 |
| 30GB | 36784.76 | - | 57441.64 |
(※単位はトランザクション/秒)
- メモリを増やすことでキャッシュされるので、ランダムリードが減る
- そこそこの容量のメモリ＋Fusion-IOは結構優秀(Buffer pool 5GBあたりのラインが良さそう)
MySQLの保存場所
- Fusion-ioはランダムリード性能がきわめて優秀、ランダムライト性能も優秀
- HDDはシーケンシャルR/W
- ランダムライト型
- データファイル(*.ibd)
- UNDOセグメント、Insert buffer
- シーケンシャルライト型
- Doublewrite buffer
- バイナリログ
- REDOログ
- バックアップファイル
- ibdata1とib_logfile*をHDDに移すと性能向上(10〜20%程度)
- MySQL5.5系を利用するとさらに10〜20%向上
- ディスクI/Oバウンドの処理性能は向上
- innodbまわりの処理改善
CPUの影響はどの程度か
- Nehalem
- メモリがCPUに直結しているので、インメモリの処理が高速
- CPUとノースブリッジ間の帯域幅が2.5倍
- Fusion-ioで、x5470(Harpertown) vs x5570(Nehalem)
- Nahalemの方が、26(Buffer pool 30GB)〜43%(Buffer pool 1GB)向上
- Opteron vs Nahalem
- IO単位が16KBのときは、Opteronも優秀
- が、8KBにすると、かなり差が出る
- PCI-E 〜 CPU間のレイテンシの格差が顕在化(RAIDを組むとさらに顕在化する予想)
冗長化のオーバヘッド
- Fusion-io+HDDで
- RAID1だと、RAID無しと比べて約20%の性能低下
- RAID5(x4)も低下
- DRBDによる高可用化
- heartbeat+DRBD+MySQL
- ネットワークがボトルネックになりやすい
- 1Gbps環境で、42〜69%の低下
- 10Gbps環境で、6〜37%の低下
DeNAの活用に向けて
- 現在は検証段階
- アプリケーション要件と価格/容量のバランス
- 今後の容量の増加に期待
- MLCは怖い
- L2キャッシュとして使うのはどうか？
- ZFSL2ARC, Facebook FlashCache(Linuxカーネルモジュールとして動作、アプリ非依存), Oracle Smart Flash Cache(Oracle依存)
- 性能検証結果は、良くなかったので、現状魅力はそれほどない。今後に期待
- 2次キャッシュに過ぎないがSPOFになる
- 10万IOPSクラスを必要とするアプリは限られている
- 一台で複数アプリの運用を視野に
- マスタよりスレーブの方が導入リスクは低い
- 特にスレーブのSQLスレッドはシングルスレッド
仮想化用途
- KVM+Fusion-io
- ランダムリード性能が30分の1
- HDDでの仮想化は、そこまで深刻ではない
- 今後の最適化に期待
複数スレーブを集約
- 複数台のMySQLスレーブを、Fusion-ioの1台に集約
- 但し、複数インスタンスでの構成は複雑に
アプリケーションデザインの調整
- ボトルネックがディスクからCPUに移ることで、今まで問題にならなかったことが顕在化
- 高頻度なSQLはNoSQLへ移行
- 都度接続からパーシステント・コネクションへ
- SSD向きのテーブルとHDD向きのテーブルを区別する
- MySQLの制約条件をある程度ふまえたテーブル設計をする
- 巨大なテーブルをハッシュパーティション化する
- 現在のMySQL5.1では、1インスタンスでは、PCI-E SSDのスループットを完全に引き出すことはできない
- 5.5以上であればスループットがあがる
将来的な運用面での対策
- 1系統あたり3台のみの準備(マスタ、スレーブ兼バックアップ、DR用バックアップ)
- クラッシュ時に再構築ではなく差分修復を実現する
- リカバリ時間の短縮
- そのためにはMySQL本体の回収が必要
- マスタでは、すべてのトランザクション処理を同期書き込みする
- 準同期レプリケーションを使用する
- バイナリログをcrash-safeにする
- スレーブでは、障害時にマスタのバイナリログの位置情報を特定できるようにする
以上
おまけ
最後の抽選会で「DJスピーカーベア」が当たりました！ありがとうございました！
参考
(追記)一緒に行ったお二方のエントリ。DELLさんの検証結果などの話もまとめられています。
