Flashcache
ドキュメントとコードを眺めただけで、実機で動かせてはいない。
Facebookが開発したフラッシュを使ったキャッシュ機構、というと漠としすぎか。第一報を聞いたときにMySQLを高速化するための、なんて枕が付いていたのでスルーしていたのだけど機構としては汎用ブロックデバイスに対するキャッシュなので、どんなアプリケーションにも応用可能。どれほど効果があるかは調べてみないと分らないが。
実装はLinuxのカーネルモジュールとして作られており、device mapperの仕組みを使ってあるブロックデバイスへのキャッシュとして別のブロックデバイスを指定するという形をとる。つまりHDDの前にSSDのような高速なブロックデバイスを挟むことで、キャッシュとして使うというもの。
3つ管理コマンド(作成、組込み、破棄)と1つのカーネルモジュールのみというシンプルだけど、既存のdevice mapperの仕組みを使うことで効率的に実現しているように見えた。知らなかったのだがdevice mapperには元々kcopydというデバイス間のデータコピーを非同期に行う仕組みがあって、Flashcacheもこれを使っていた。
ブロックデバイスのキャッシュは通常主記憶の空きを使っておこなうが、データベースなどの同期書き込みを必須とするような処理ではそのレイヤでのキャッシュが効かない。そこでこの仕組みでは不揮発性のブロックデバイスをキャッシュに使うことで、同期書き込みであってもライトバックを可能にするのが肝。BBU付きRAIDカードならば同じようにライトバック動作となるが、カードによるが512MB程度のものが多くデータベースのI/Oを支えるには容量が足りない。
実際の性能は以下のサイトで評価した結果がある。
FlashCache: first experiments - Percona Database Performance Blog
理屈の上ではHDDよりも高速なSSDを使う場合
SSDをそのまま使う > Flashcacheを使う > RAID構成+BBU付きのHDD
となるのは理解できるが、あとは性能がベアのSSDを使うときに近いのかHDDを変わらない程度なのかが気になるところ。上記サイトの結果では、ベアのSSDを使う場合に非常に近い性能がでるとあった。
評価ではSSDの違いと許容するダーティデータの違いで幾つかデータがあるが、ベアドライブで使うよりもSSDの性能に強く依存するようだ。2nd GenのIntel SSDと組み合わせたときは許容度20%にしてもかなり高性能なのが注目される。
余談だが、Intel SSDの1st Genと2nd Genで大きく性能差があるならば、ベアドライブで使ったときの性能でもっと差がでてもいいような気がする。このテスト環境ではドライブの性能以外にボトルネックがあるのではないだろうか。
閑話休題
キャッシュの管理方式はLRUとFIFOが選択でき、セットアソシアティブで管理されている連想度はデフォルト512。CPUキャッシュのラインに相当するブロックはページサイズに合わせるのがいいのだろうが、XFS+InnoDBのO_DIRECTで使う場合は16KBにしておくのがいいと有る。InnoDBのページサイズが標準では16KBなのでそれに合わせての値だろう。
こういう実験的なモジュールのわりには設定項目が非常に多くてドキュメントも充実しているのは、Facebookの現場で使われているソフトウェアだからだろうか。ソースは公開しているしパッチはwelcomeみたいだけど、公開開始時点からリポジトリの中身は1bitも更新されていなかった
全データをSSDに置ける程度のデータならば、通常通りSSDを使うのでいいのだろう。Facebookは十分なインフラ予算で運用しているのだろうが、それ以上にデータ量が膨大であるために今回のような方式を採用したのではないだろうか。このカーネルモジュールの信頼性をどう見るかに依るが、必ずしも全データを搭載可能なSSDでなくとも効果があり導入についての敷居が低いので個人的にはかなり流行るのではないかと思う
