« Filter::SQL でデータベースを叩くワンライナーを簡単に書く方法 | メイン | ウェブサービスにおけるダメージコントロール (MySQL のスロークエリを自動的に kill する方法) »

2008年10月28日

ウェブサービスにおける SSD 導入にむけて〜検索サービスの可能性

実際に試してみた結果については、ウェブサービスの SSD 化について話してきましたをご参照ください。

検索エンジンや小さな行が多いデータベース等で使用する目的での SSD (Intel X25-M) のベンチマーク結果については、Kazuho at Work: Benchmarking SSD for MySQL をご覧ください (InnoDB の話をしていますが、Senna / Tritonn でも基本的に同じ)

 Sun が SSD 製品の投入を表明 (マイコミジャーナル) したり、Google が Intel の製品をテスト (The Register) したりと、クライアントサイドに続きサーバサイドへもソリッドステートドライブ (SSD) の波が押し寄せてきつつあります。パストラックでも SSD を使いたいなぁという思いはあったので、ちょっと導入を検討してみることにしました。

1. SSD がむいている箇所

 HDD に比較した場合 SSD のメリットは、その圧倒的なランダムリード性能にあります。一方で、シーケンシャルアクセスの場合は大差ありませんし、書き込み性能や信頼性の点ではまたまだ不安も多いです。では、一体どういうところで SSD を使うべきなのでしょう。今回は、Tritonn (MySQL+Senna) のストレージとしての SSD の使用を検討することにしました。全文検索アルゴリズムは一般にランダムリードが頻発するため、索引をメモリにキャッシュして運用することが多い (参考: [Senna-dev 661] Re: インデックスをキャッシュに保持する方法について) 一方で、一般にスレーブとして運用されるため、故障しても大きな問題にならないためです。現にパストラックでも Tritonn をスレーブとして使い、全文索引をメインメモリに載せています。が、検索回数はそれほどでもないので、CPU はほとんど遊んでしまっています。これを、メインメモリほど高速ではないが、バイト単価が大幅に安い SSD で置き換えることができないか、というわけです。

2. 簡易ベンチマーク

 というわけで、手元のサーバでパストラックのテストデータ (実際のデータから特定時期のみを切り出したもの) を使ってベンチマークをとってみました。環境は以下のとおりです。比較対象として SSD を買うのは面倒だったので、一般的な USB メモリを利用しています。ここからどうやって内蔵型の SSD のパフォーマンスを予測するかは、追って説明します。

表1. 環境
OS linux 2.6.18 (i386)
CPU Pentium 4 (3GHz)
メインメモリ 2GB 注1
HDD HDT725050VLA360
USB メモリ RUF2-J8GS-BK注2
検索データサイズ 847MB注3

 この環境に対して、2000個のキーワードに合致する上位20件のデータを要求するクエリを2並列で実行し、その所要時間を測定したところ、以下のようになりました。また、この際に iostat を用いて観測した I/O トランザクションのサイズは、平均 10〜15KB 程度でした。

表2. ベンチマーク
ストレージ 所要時間 (秒) I/O スループット (概算)
メインメモリ 4.7秒 -
USB メモリ 35秒 7〜8MB/秒
HDD 128秒 2〜3MB/秒

3. 結論

 ベンチマークから明らかなように、検索データのストレージとして読み込み専用で使うのであれば、一般的な USB メモリでも HDD より数倍高速であることがわかります。また、メインメモリにキャッシュさせた時の速度が USB メモリにアクセスした時の 10 倍弱であることから、10KB台のサイズでのランダムリード性能が数十MB/秒クラスの SSD を用意できれば、一昔前のサーバにオンメモリで索引を置いた場合に近い速度が発揮できそうです。最近だと Intel の X25-M のように、10万円以下、100GB 以上、20MB/sec 以上、という性能をもつ SSD も発売になっています。

 検索サービスを運用しようと思うと、従来は、メインメモリへキャッシュすることを前提に考える必要があったため、検索データ 1GB あたり1万円以上の投資が必要でした。しかし、SSD をうまく使えば、その 1/10 程度のコストでサービスを構築できそうに思えます。これから数年は、また、検索サービス関連が盛り上がるかもしれませんね。

注1: メインメモリにキャッシュした状態のベンチマーク以外は、swapoff -a, swappiness=0 等に設定してキャッシュメモリを 180KB 程度に抑制
注2: 試験環境でのシーケンシャルリードは 15MB/sec. 程度、ライトは 800KB/sec. 程度
注3: SEN* ファイルの合計サイズ

投稿者 kazuho : 2008年10月28日 20:28 このエントリーを含むはてなブックマーク このエントリーを含むはてなブックマーク

トラックバック

このエントリーのトラックバックURL:
http://labs.cybozu.co.jp/cgi-bin/mt-admin/mt-tbp.cgi/2045